[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #25 from Robert Strube --- acpi=off is the only parameter necessary to get the eGPU up and running. Setting this parameter allows the Thunderbolt PCI bridge to correctly have it's resources allocated. This incidentally also completely disables the Vega M (even with Vanilla kernel that does not have the device IDs commented out). I'm wondering where I can report the Thunderbolt Controller / Bridge bug? Perhaps you fine folks can point me in the right direction? -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #24 from Robert Strube --- Created attachment 142209 --> https://bugs.freedesktop.org/attachment.cgi?id=142209=edit dmesg log booting system with PM *DISABLED* and *WITH* eGPU -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #23 from Robert Strube --- Edit: taking a closer look at the dmesg I see that disabling the PM did indeed eliminate the PCI resource issues. So for some reason having PM enabled affects the PCI resource allocation for the Thunderbolt PCI bridges! -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #22 from Robert Strube --- OK! My hunch about the PM was right! The card is fully initialized now, so the issue doesn't appear to be a PCI resource issue! I took the brute force approach, compiled my own custom kernel that completely disabled the Vega M (by commenting out it's device IDs). I then passed in the following kernel boot parameters: acpi=off apm=off amdgpu.dpm=0 amdgpu.aspm=0 amdgpu.runpm=0 amdgpu.bapm=0 Rebooted the machine and *BAM* the eGPU was initialized! I'm attaching the new dmesg! I'm just super excited that I was able to get the eGPU initialized! xrandr even sees it! xrandr --listproviders Providers: number : 2 Provider 0: id: 0x74 cap: 0x9, Source Output, Sink Offload crtcs: 3 outputs: 7 associated providers: 1 name:modesetting Provider 1: id: 0x4a cap: 0x6, Sink Output, Source Offload crtcs: 6 outputs: 5 associated providers: 1 name:Radeon RX 580 Series @ pci::09:00.0 -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #21 from Robert Strube --- Hi guys, Apologies for the deluge of posts here, I've been trying really hard to investigate this issue! So I took a closer look at the PCI resource issues that you mentioned, I've also been looking and thunderbolt driver issues in general, and I've noticed that this type of log message is quite common. Here's what I'm wondering: These four devices correspond to the TB to PCI bridges in the system :04:00.0 :05:01.0 :05:02.0 :05:04.0 04:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=04, secondary=05, subordinate=6e, sec-latency=0 Memory behind bridge: bc00-ea0f Prefetchable memory behind bridge: 002fb000-002ff9ff Capabilities: [80] Power Management version 3 Capabilities: [88] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [ac] Subsystem: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] Capabilities: [c0] Express Upstream Port, MSI 00 Capabilities: [100] Device Serial Number b7-de-04-b0-a6-c9-a0-00 Capabilities: [200] Advanced Error Reporting Capabilities: [300] Virtual Channel Capabilities: [400] Power Budgeting Capabilities: [500] Vendor Specific Information: ID=1234 Rev=1 Len=0d8 Capabilities: [600] Latency Tolerance Reporting Capabilities: [700] #19 Kernel driver in use: pcieport 05:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=05, secondary=06, subordinate=06, sec-latency=0 Memory behind bridge: ea00-ea0f Capabilities: [80] Power Management version 3 Capabilities: [88] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [ac] Subsystem: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] Capabilities: [c0] Express Downstream Port (Slot+), MSI 00 Capabilities: [100] Device Serial Number b7-de-04-b0-a6-c9-a0-00 Capabilities: [200] Advanced Error Reporting Capabilities: [300] Virtual Channel Capabilities: [400] Power Budgeting Capabilities: [500] Vendor Specific Information: ID=1234 Rev=1 Len=0d8 Capabilities: [700] #19 Kernel driver in use: pcieport 05:01.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 17 Bus: primary=05, secondary=07, subordinate=39, sec-latency=0 Memory behind bridge: bc00-d3ef Prefetchable memory behind bridge: 002fb000-002fcfff Capabilities: [80] Power Management version 3 Capabilities: [88] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [ac] Subsystem: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] Capabilities: [c0] Express Downstream Port (Slot+), MSI 00 Capabilities: [100] Device Serial Number b7-de-04-b0-a6-c9-a0-00 Capabilities: [200] Advanced Error Reporting Capabilities: [300] Virtual Channel Capabilities: [400] Power Budgeting Capabilities: [500] Vendor Specific Information: ID=1234 Rev=1 Len=0d8 Capabilities: [700] #19 Kernel driver in use: pcieport 05:02.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 18 Bus: primary=05, secondary=3a, subordinate=3a, sec-latency=0 Memory behind bridge: d3f0-d3ff Capabilities: [80] Power Management version 3 Capabilities: [88] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [ac] Subsystem: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] Capabilities: [c0] Express Downstream Port (Slot+), MSI 00 Capabilities: [100] Device Serial Number b7-de-04-b0-a6-c9-a0-00 Capabilities: [200] Advanced Error Reporting Capabilities: [300] Virtual Channel Capabilities: [400] Power Budgeting Capabilities: [500] Vendor Specific Information: ID=1234 Rev=1 Len=0d8 Capabilities: [700] #19 Kernel driver in use: pcieport 05:04.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=05, secondary=3b, subordinate=6e, sec-latency=0 Memory behind bridge:
RE: [igt-dev] [PATCH] RFC: Make igts for cross-driver stuff mandatory?
Make igt for cross-driver, I think you should rename it first, not an intel specific. NO company wants their employee working on other company stuff. You can rename it to DGT(drm graphics test), and published following libdrm, or directly merge to libdrm, then everyone can use it and develop it in same page, which is only my personal opinion. Regards, David > -Original Message- > From: dri-devel On Behalf Of Eric > Anholt > Sent: Friday, October 26, 2018 12:36 AM > To: Sean Paul ; Daniel Vetter > Cc: IGT development ; Intel Graphics > Development ; DRI Development de...@lists.freedesktop.org>; amd-...@lists.freedesktop.org > Subject: Re: [igt-dev] [PATCH] RFC: Make igts for cross-driver stuff > mandatory? > > Sean Paul writes: > > > On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote: > >> Hi all, > >> > >> This is just to collect feedback on this idea, and see whether the > >> overall dri-devel community stands on all this. I think the past few > >> cross-vendor uapi extensions all came with igts attached, and > >> personally I think there's lots of value in having them: A > >> cross-vendor interface isn't useful if every driver implements it > >> slightly differently. > >> > >> I think there's 2 questions here: > >> > >> - Do we want to make such testcases mandatory? > >> > > > > Yes, more testing == better code. > > > > > >> - If yes, are we there yet, or is there something crucially missing > >> still? > > > > In my experience, no. Last week while trying to replicate an intel-gfx > > CI failure, I tried compiling igt for one of my (intel) chromebooks. > > It seems like cross-compilation (or, in my case, just specifying > > prefix/ld_library_path/sbin_path) is broken on igt. If we want to > > impose restrictions across the entire subsystem, we need to make sure > > that everyone can build and deploy igt easily. > > > > I managed to hack around everything and get it working, but I still > > haven't tried switching out the toolchain. Once we have some GitLab CI > > to validate cross-compilation, then we can consider making IGT mandatory. > > > > It's possible that I'm just a meson n00b and didn't use the right > > incantation, so maybe it already works, but then we need better > documentation. > > > > I've pasted my horrible hacks below, I also didn't have libunwind, so > > removed its usage. > > I've also had to cut out libunwind for cross-compiling on many occasions. > Worst library. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108096] [amd-staging-drm-next] SDDM screen corruption (not usable) with RX580, amdgpu, dc=1 (of course), regression - [bisected]
https://bugs.freedesktop.org/show_bug.cgi?id=108096 Dieter Nützel changed: What|Removed |Added Summary|[amd-staging-drm-next] SDDM |[amd-staging-drm-next] SDDM |screen corruption (not |screen corruption (not |usable) with RX580, amdgpu, |usable) with RX580, amdgpu, |dc=1 (of course), |dc=1 (of course), |regression |regression - [bisected] --- Comment #13 from Dieter Nützel --- DONE - amd-staging-drm-next 964d0fbf6301d3dc8dfad19ffab5a06d002d27f1 is the first bad commit commit 964d0fbf6301d3dc8dfad19ffab5a06d002d27f1 Author: Andrey Grodzovsky Date: Fri Jul 6 14:16:54 2018 -0400 drm/amdgpu: Allow to create BO lists in CS ioctl v3 This change is to support MESA performace optimization. Modify CS IOCTL to allow its input as command buffer and an array of buffer handles to create a temporay bo list and then destroy it when IOCTL completes. This saves on calling for BO_LIST create and destry IOCTLs in MESA and by this improves performance. v2: Avoid inserting the temp list into idr struct. v3: Remove idr alloation from amdgpu_bo_list_create. Remove useless argument from amdgpu_cs_parser_fini Minor cosmetic stuff. v4: Revert amdgpu_bo_list_destroy back to static Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König Reviewed-by: Chunming Zhou Signed-off-by: Alex Deucher :04 04 d621cc2fb523ffcaa877faa8ae682878c268478e 6a758c959d69df05023339fa981b067fa027875c M drivers :04 04 7f32e65fd49cb9305b5c7440b161771f429aad09 9137d92f44e0b34512b3104141412595da64ce96 M include But 'git revert 964d0fbf6301' do NOT work on amd-staging-drm-next: error: Konnte "revert" nicht auf 964d0fbf6301... (drm/amdgpu: Allow to create BO lists in CS ioctl v3) ausführen Hinweis: nach Auflösung der Konflikte markieren Sie die korrigierten Pfade Hinweis: mit 'git add ' oder 'git rm ' und tragen Sie das Ergebnis mit Hinweis: 'git commit' ein SOURCE/amd-staging-drm-next> git status Auf Branch amd-staging-drm-next Ihr Branch ist auf demselben Stand wie 'origin/amd-staging-drm-next'. Sie sind gerade an einem Revert von Commit '964d0fbf6301'. (beheben Sie die Konflikte und führen Sie dann "git revert --continue" aus) (benutzen Sie "git revert --abort", um die Revert-Operation abzubrechen) zum Commit vorgemerkte Änderungen: (benutzen Sie "git reset HEAD ..." zum Entfernen aus der Staging-Area) geändert: drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c geändert: include/uapi/drm/amdgpu_drm.h Nicht zusammengeführte Pfade: (benutzen Sie "git reset HEAD ..." zum Entfernen aus der Staging-Area) (benutzen Sie "git add/rm ...", um die Auflösung zu markieren) von beiden geändert:drivers/gpu/drm/amd/amdgpu/amdgpu.h von beiden geändert:drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c von beiden geändert:drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c -- 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
[pull] amdgpu drm-next-4.20
Hi Dave, Fixes for 4.20: - Powerplay updates for vega20 - Powerplay fixes - DC fix for CZ and ST - GPUVM fix - SR-IOV fix The following changes since commit f2bfc71aee75feff33ca659322b72ffeed5a243d: Merge tag 'drm-intel-next-fixes-2018-10-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-10-19 14:28:11 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.20 for you to fetch changes up to 0af5c656fdb797f74ee57414e0c07cd57406d0c3: drm/amdgpu: fix amdgpu_vm_fini (2018-10-25 14:04:40 -0500) Christian König (1): drm/amdgpu: fix amdgpu_vm_fini David Francis (2): powerplay: Respect units on max dcfclk watermark drm/amd/display: Disable 4k 60 HDMI on DCE11 Emily Deng (1): drm/amdgpu: Fix null pointer amdgpu_device_fw_loading Evan Quan (6): drm/amd/powerplay: error out when force clock level under auto dpm mode V2 drm/amd/powerplay: drop highest UCLK setting after display configuration change drm/amd/powerplay: bump the PPtable version supported drm/amd/powerplay: commit get_performance_level API as DAL needed drm/amd/powerplay: correct the clocks for DAL to be Khz unit drm/amd/powerplay: commonize the API for retrieving current clocks Joseph Greathouse (1): drm/amd/pp: enable power limit increase in OD mode Rex Zhu (2): drm/amd/display: Fix Null point error if smu ip was disabled drm/amdgpu: Fix null point error drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 15 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +- drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c| 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 6 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 16 ++-- .../drm/amd/display/dc/dce110/dce110_resource.c| 2 +- drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 27 +-- drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 2 +- drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 8 ++ drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 85 -- .../amd/powerplay/hwmgr/vega20_processpptables.c | 46 +--- .../gpu/drm/amd/powerplay/inc/smu11_driver_if.h| 2 +- 15 files changed, 131 insertions(+), 94 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107536] gfx_v8_0_priv_reg_irq [amdgpu]] *ERROR* Illegal register access in command stream
https://bugs.freedesktop.org/show_bug.cgi?id=107536 --- Comment #3 from Alex Deucher --- Is this reproducible or was it a one time event? -- 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: tinydrm driver for adafruit PiTFT 3.5" touchscreen
Noralf Trønnes writes: > Den 25.10.2018 18.29, skrev Eric Anholt: >> Eric Anholt writes: >> >>> I was going to start working on making the vc4 driver work with >>> tinydrm panels, but it turned out tinydrm didn't have the panel I had >>> previously bought. So, last night I ported the fbtft staging >>> driver over to DRM. >>> >>> It seems to work (with DT at >>> https://github.com/anholt/linux/commits/drm-misc-next-hx8357d) -- >>> fbdev works great including rotated, and so does modetest. However, >>> when X11 comes up at 16bpp, I get: >>> >>> https://photos.app.goo.gl/8tuhzPFFoDGamEfk8 >>> >>> If I have tinydrm set a preferred bpp of 24, X looks great. Noralf, >>> any ideas? >> Also, with these patches and the format modifier patch I just sent, mesa >> with vc4 is now working with this driver on this branch: >> >> https://gitlab.freedesktop.org/anholt/mesa/commits/kmsro > > Ah, nice to see this happening! > Getting hw rendering was one of the advantages I saw DRM could provide > over fbdev on these displays. Little did I know how complicated graphics > was outside fbdev, so I was unable to realise this myself. > > The current solution to get hw rendering is to have a userspace process > that continously copies the framebuffer: > https://github.com/tasanakorn/rpi-fbcp > > It's used by some of the small DIY handheld game consoles that run > emulators which requires hw rendering. > >> Now I wonder how we can improve performance of the SPI updates. > > At what SPI speed are you running? The datasheet for most of these > display controllers list the max speed as 10MHz, but almost all of them > can go faster. Some are reported going as high as 70-80MHz. That's for > the pixel data transfer, not the commands. tinydrm/mipi-dbi.c sends > commands at 10MHz and pixels at full speed (mipi_dbi_spi_cmd_max_speed()). > Most panels I have run at 32MHz or 48MHz. I copied the DT from the adafruit tree, which has it at 32mhz. System performance seems to be limited by the copy and format conversion I think -- in particular, I wonder if we shouldn't be doing our dirty copies in our own workqueue. I haven't managed to get any really good profiling data yet, though. glxgears at 128x128 is nice and smooth, and at 480x320 it's 6fps. That's not filling 32mhz of SPI. On the other hand, I would have expected the uncached reads for the 4-to-2 swapped conversion to be able to go faster than 3.5mb/sec. If it's the uncached reads, we could at least use NEON for the copy to cached, and probably even do the whole conversion in NEON with a bit more thought. Another option: use a vc4 RCL to do RGBA to RGB565, since that will be less pressure on the bus. But then, I suppose I should just figure out what's going on that makes X11 at RGBA break, and fix that so we don't even have to do that conversion. I keep hoping there's some way we could feed output from the DISPSLAVE HVS register directly to the SPI master -- FIFO32 gets us close (two 16-bit pixels packed next to each other, leftmost in the lower 2 bytes), but the need for byte swapping (as opposed to R/B swapping) I think makes it impossible. > Almost all the time is spent in the SPI transfer, so every hz counts. On > the Pi there's byte swapping because the DMA capable SPI controller can't > do 16-bit (tinydrm_swab16()). If I remember correctly this has negligible > impact on performance. > > The SPI controller/driver on the Pi has some restrictions on the speeds > to choose from because the divisor has to be a multiple of two > (bcm2835_spi_transfer_one()). That's weird. My specs say CDIV must be a *power* of two, with lower values rounded down. I guess that means we might be running things fast, not slow, though (and at 32mhz out of 250, we should be getting the same CDIV). signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/plane: Export drm_plane_check_pixel_format()
i915 will make use of this to fail early during framebuffer creation. Suggested-by: Ville Syrjälä Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjälä Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_plane.c | 1 + include/drm/drm_plane.h | 11 +++ 2 files changed, 12 insertions(+) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 1fa98bd12003..e834788619d1 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -589,6 +589,7 @@ int drm_plane_check_pixel_format(struct drm_plane *plane, return 0; } +EXPORT_SYMBOL(drm_plane_check_pixel_format); static int __setplane_check(struct drm_plane *plane, struct drm_crtc *crtc, diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index 0a0834bef8bd..8637b5239eb3 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -763,6 +763,17 @@ static inline struct drm_plane *drm_plane_find(struct drm_device *dev, return mo ? obj_to_plane(mo) : NULL; } +/** + * drm_plane_check_pixel_format - check format and modifier support. + * @plane: plane to check support against. + * @format: pixel format to check support for. + * @modifier: format modifier to check support for. + * + * Returns 0 on success or negative error code on failure. + */ +int drm_plane_check_pixel_format(struct drm_plane *plane, +u32 format, u64 modifier); + /** * drm_for_each_plane_mask - iterate over planes specified by bitmask * @plane: the loop cursor -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0044, dig 0x0044, pins 0x00a0
[1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN
5 - cnt: 0
[1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN
7 - cnt: 0
[1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status
updated from unknown to disconnected
[1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7)
received hotplug event.
[1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status
0x71450085
[1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by detecting short IRQ
storms using a separate threshold and count, one that is much higher
then the threshold for long IRQs. We default to a threshold of 50 short
pulses within the timespan of a second, which should amount to about
100ms of constant pulsing. This should be a good middle ground between
avoiding detecting false IRQ storms, while still catching short IRQ
storms quickly enough to minimize the amount of time we'll stutter every
time hotplugging gets re-enabled and immediately disabled by another
short IRQ storm.
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 89 +++-
drivers/gpu/drm/i915/i915_drv.h | 15 +++--
drivers/gpu/drm/i915/i915_irq.c | 14 -
drivers/gpu/drm/i915/intel_hotplug.c | 84 --
4 files changed, 150 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b4744a68cd88..84e89fbd55fb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4566,21 +4566,24 @@ static const struct file_operations i915_forcewake_fops
= {
.release = i915_forcewake_release,
};
-static int i915_hpd_storm_ctl_show(struct seq_file *m, void *data)
+static int i915_hpd_storm_show(struct seq_file *m, bool long_hpd)
{
struct drm_i915_private *dev_priv = m->private;
struct i915_hotplug *hotplug = _priv->hotplug;
+ const unsigned int threshold = long_hpd ?
+ hotplug->long_hpd_storm_threshold :
+ hotplug->short_hpd_storm_threshold;
- seq_printf(m, "Threshold: %d\n", hotplug->hpd_storm_threshold);
+ seq_printf(m, "Threshold: %d\n", threshold);
seq_printf(m, "Detected: %s\n",
yesno(delayed_work_pending(>reenable_work)));
[PATCH 1/2] drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:
[ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
00ec
[ 332.340906] PGD 0 P4D 0
[ 332.342750] Oops: [#1] SMP PTI
[ 332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G
O 4.18.0-rc3short-hpd-storm+ #2
[ 332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35
) 09/14/2018
[ 332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915]
[ 332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86
[i915]
[ 332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73
62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39 80
ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41
[ 332.354286] RSP: 0018:c9147e48 EFLAGS: 00010006
[ 332.356344] RAX: 0005 RBX: 8802c226c9d4 RCX: 0006
[ 332.358404] RDX: RSI: 0082 RDI: 88032dc95570
[ 332.360466] RBP: 0005 R08: R09: 88031b3dc840
[ 332.362528] R10: R11: 00031a069602 R12: 8802c226ca20
[ 332.364575] R13: 8802c2268000 R14: 880310661000 R15: 000a
[ 332.366615] FS: () GS:88032dc8()
knlGS:
[ 332.368658] CS: 0010 DS: ES: CR0: 80050033
[ 332.370690] CR2: 00ec CR3: 0200a003 CR4: 003606e0
[ 332.372724] DR0: DR1: DR2:
[ 332.374773] DR3: DR6: fffe0ff0 DR7: 0400
[ 332.376798] Call Trace:
[ 332.378809] process_one_work+0x1a1/0x350
[ 332.380806] worker_thread+0x30/0x380
[ 332.382777] ? wq_update_unbound_numa+0x10/0x10
[ 332.384772] kthread+0x112/0x130
[ 332.386740] ? kthread_create_worker_on_cpu+0x70/0x70
[ 332.388706] ret_from_fork+0x35/0x40
[ 332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm
btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper
intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp
fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich
mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video
crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded: i915]
[ 332.394963] CR2: 00ec
This appears to be due to the fact that with an MST topology, not all
intel_connector structs will have ->encoder set. So, fix this by
skipping connectors without encoders in
intel_hpd_irq_storm_reenable_work().
For those wondering, this bug was found on accident while simulating HPD
storms using a Chamelium connected to a ThinkPad T450s (Broadwell).
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_hotplug.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 648a13c6043c..7d21aac10d16 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -228,7 +228,8 @@ static void intel_hpd_irq_storm_reenable_work(struct
work_struct *work)
drm_for_each_connector_iter(connector, _iter) {
struct intel_connector *intel_connector =
to_intel_connector(connector);
- if (intel_connector->encoder->hpd_pin == pin) {
+ if (intel_connector->encoder &&
+ intel_connector->encoder->hpd_pin == pin) {
if (connector->polled !=
intel_connector->polled)
DRM_DEBUG_DRIVER("Reenabling HPD on
connector %s\n",
connector->name);
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/i915: HPD IRQ storm detection fixes
IMPORTANT - As a note: I have not had the customer who this second patch is for test this yet, I'm sending this ahead of time to make sure this is something that isn't too crazy for upstream to accept. I'm not planning on pushing this after review until I've verified this actually fixes their problems. This series contains a fix for a problem which is very difficult to reproduce under normal circumstances without specialized testing hardware, along with a fix that seems to be required for some especially rebellious GM45 laptops. Lyude Paul (2): drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST drm/i915: Add short HPD IRQ storm detection for non-MST systems drivers/gpu/drm/i915/i915_debugfs.c | 89 +++- drivers/gpu/drm/i915/i915_drv.h | 15 +++-- drivers/gpu/drm/i915/i915_irq.c | 14 - drivers/gpu/drm/i915/intel_hotplug.c | 87 --- 4 files changed, 152 insertions(+), 53 deletions(-) -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
Hi,
On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
>
> On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> > As far as I can tell the panel that was added in commit da50bd4258db
> > ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> > wasn't actually an Innolux TV123WAM but was actually an Innolux
> > P120ZDG-BF1.
> >
> > As far as I can tell the Innolux TV123WAM isn't a real panel and but
> > it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> > Let's unmosh.
> >
> > Here's my evidence:
> >
> > * Searching for TV123WAM on the Internet turns up a TI panel. While
> > it's possible that an Innolux panel has the same model number as the
> > TI Panel, it seems a little doubtful. Looking up the datasheet from
> > the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
> >
> > * As far as I know, the patch adding the Innolux Panel was supposed to
> > be for the board that's sitting in front of me as I type this
> > (support for that board is not yet upstream). On the back of that
> > panel I see Innolux P120ZDZ-EZ1 rev B1.
> >
> > * Someone pointed me at a datasheet that's supposed to be for the
> > panel in front of me (sorry, I can't share the datasheet). That
> > datasheet has the string "p120zdg-bf1"
> >
> > * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> > that are 2160x1440. They don't have datasheets, but the fact that
> > the resolution matches is a good sign.
> >
> > In any case, let's update the name and also the physical size to match
> > the correct panel.
> >
> > Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver
> > support")
> > Signed-off-by: Douglas Anderson
> > Cc: Sandeep Panda
> > ---
> >
> > drivers/gpu/drm/panel/panel-simple.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 937e97490c30..7ee1abc5d81b 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1370,7 +1370,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
> > },
> > };
> >
> > -static const struct drm_display_mode innolux_tv123wam_mode = {
> > +static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
> > .clock = 206016,
> > .hdisplay = 2160,
> > .hsync_start = 2160 + 48,
> > @@ -1384,13 +1384,13 @@ static const struct drm_display_mode
> > innolux_tv123wam_mode = {
> > .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> > };
> >
> > -static const struct panel_desc innolux_tv123wam = {
> > - .modes = _tv123wam_mode,
> > +static const struct panel_desc innolux_p120zdg_bf1 = {
> > + .modes = _p120zdg_bf1_mode,
> > .num_modes = 1,
> > .bpc = 8,
> > .size = {
> > - .width = 259,
> > - .height = 173,
> > + .width = 254,
> > + .height = 169,
> > },
> > .delay = {
> > .prepare = 200,
> > @@ -2454,8 +2454,8 @@ static const struct of_device_id platform_of_match[]
> > = {
> > .compatible = "innolux,n156bge-l21",
> > .data = _n156bge_l21,
> > }, {
> > - .compatible = "innolux,tv123wam",
>
> I think we should update the struct, but we might want to keep this around.
> Given the tv123wam panel is TI, we're likely not going to have a collision on
> innolux,...
>
> That said, I'll defer to robh on this one, I'm not sure if changing names is
> cool once the bindings have hit mainline.
Rob gave the bindings patch a Reviewed-by tag, so I'm assuming he's
cool with it. v2 still doesn't keep the "innolux,tv123wam" around.
If you disagree then let me know and I'll do a v3.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Remove the mystery delay
Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
reason we needed that mystery delay is that we weren't paying
attention to HPD.
Looking at the datasheet for the same panel that was tested for the
original commit, I see there's a timing "t3" that times from power on
to the aux channel being operational. This time is specced as 0 - 200
ms. The datasheet says that the aux channel is operational at exactly
the same time that HPD is asserted.
Scoping the signals on this board showed that HPD was asserted 84 ms
after power was asserted. That very closely matches the magic 70 ms
delay that we had. ...and actually, in my testing the 70 ms wasn't
quite enough of a delay and some percentage of the time the display
didn't come up until I bumped it to 100 ms (presumably 84 ms would
have worked too).
To solve this, we tried to hook up the HPD signal in the bridge.
...but in doing so we found that that the bridge didn't report that
HPD was asserted until ~280 ms after we powered it (!). This is
explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD
(Hot Plug/Unplug Detection)". Reading there we see that the bridge
isn't even intended to report HPD until 100 ms after it's asserted.
...but that would have left us at 184 ms. The extra 100 ms
(presumably) comes from this part in the datasheet:
> The HPD state machine operates off an internal ring oscillator. The
> ring oscillator frequency will vary [ ... ]. The min/max range in
> the HPD State Diagram refers to the possible times based off
> variation in the ring oscillator frequency.
Given that the 280 ms we'll end up delaying if we hook up HPD is
_slower_ than the 200 ms we could just hardcode, for now we'll solve
the problem by just hardcoding a 200 ms delay in the panel driver
using the patch in this series ("drm/panel: simple: Support panels
with HPD where HPD isn't connected").
If we later find a panel that needs to use this bridge where we need
HPD then we'll have to come up with some new code to handle it. Given
the silly debouncing in the bridge chip, though, it seems unlikely.
One last note is that I tried to solve this through another way: In
ti_sn_bridge_enable() I tried to use various combinations of
dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel
was up. In theory that would let me detect _exactly_ when I could
continue and do link training. Unfortunately even if I did an aux
transfer w/out waiting I couldn't see any errors. Possibly I could
keep looping over link training until it came back with success, but
that seemed a little overly hacky to me.
Signed-off-by: Douglas Anderson
Reviewed-by: Sean Paul
---
Changes in v2: None
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 29 +++
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index f8a931cf3665..680566d97adc 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -458,18 +458,6 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
unsigned int val;
int ret;
- /*
-* FIXME:
-* This 70ms was found necessary by experimentation. If it's not
-* present, link training fails. It seems like it can go anywhere from
-* pre_enable() up to semi-auto link training initiation below.
-*
-* Neither the datasheet for the bridge nor the panel tested mention a
-* delay of this magnitude in the timing requirements. So for now, add
-* the mystery delay until someone figures out a better fix.
-*/
- msleep(70);
-
/* DSI_A lane config */
val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
@@ -536,7 +524,22 @@ static void ti_sn_bridge_pre_enable(struct drm_bridge
*bridge)
/* configure bridge ref_clk */
ti_sn_bridge_set_refclk_freq(pdata);
- /* in case drm_panel is connected then HPD is not supported */
+ /*
+* HPD on this bridge chip is a bit useless. This is an eDP bridge
+* so the HPD is an internal signal that's only there to signal that
+* the panel is done powering up. ...but the bridge chip debounces
+* this signal by between 100 ms and 400 ms (depending on process,
+* voltage, and temperate--I measured it at about 200 ms). One
+* particular panel asserted HPD 84 ms after it was powered on meaning
+* that we saw HPD 284 ms after power on. ...but the same panel said
+* that instead of looking at HPD you could just hardcode a delay of
+* 200 ms. We'll assume that the panel driver will have the hardcoded
+* delay in its prepare and always disable HPD.
+*
+* If HPD somehow makes sense on some future panel we'll have to
+* change this
[PATCH v2 2/6] drm/panel: simple: Support panels with HPD where HPD isn't connected
Some eDP panels that are designed to be always connected to a board
use their HPD signal to signal that they've finished powering on and
they're ready to be talked to.
However, for various reasons it's possible that the HPD signal from
the panel isn't actually hooked up. In the case where the HPD isn't
hooked up you can look at the timing diagram on the panel datasheet
and insert a delay for the maximum amount of time that the HPD might
take to come up.
Let's add support in simple-panel for this concept.
At the moment we will co-opt the existing "prepare" delay to keep
track of the delay and we'll use a boolean to specify that a given
panel should only apply the delay if the "no-hpd" property was
specified.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Use "hpd_absent_delay" property instead of a bool + prepare delay
drivers/gpu/drm/panel/panel-simple.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 97964f7f2ace..687fd087b9fc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -56,6 +56,8 @@ struct panel_desc {
/**
* @prepare: the time (in milliseconds) that it takes for the panel to
* become ready and start receiving video data
+* @hpd_absent_delay: Add this to the prepare delay if we know Hot
+*Plug Detect isn't used.
* @enable: the time (in milliseconds) that it takes for the panel to
* display the first valid frame after starting to receive
* video data
@@ -66,6 +68,7 @@ struct panel_desc {
*/
struct {
unsigned int prepare;
+ unsigned int hpd_absent_delay;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
@@ -79,6 +82,7 @@ struct panel_simple {
struct drm_panel base;
bool prepared;
bool enabled;
+ bool no_hpd;
const struct panel_desc *desc;
@@ -202,6 +206,7 @@ static int panel_simple_unprepare(struct drm_panel *panel)
static int panel_simple_prepare(struct drm_panel *panel)
{
struct panel_simple *p = to_panel_simple(panel);
+ unsigned int delay;
int err;
if (p->prepared)
@@ -215,8 +220,11 @@ static int panel_simple_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(p->enable_gpio, 1);
- if (p->desc->delay.prepare)
- msleep(p->desc->delay.prepare);
+ delay = p->desc->delay.prepare;
+ if (p->no_hpd)
+ delay += p->desc->delay.hpd_absent_delay;
+ if (delay)
+ msleep(delay);
p->prepared = true;
@@ -305,6 +313,8 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
panel->prepared = false;
panel->desc = desc;
+ panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
+
panel->supply = devm_regulator_get(dev, "power");
if (IS_ERR(panel->supply))
return PTR_ERR(panel->supply);
--
2.19.1.568.g152ad8e336-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
As far as I can tell the bindings that were added in commit
9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
bindings") weren't actually for Innolux TV123WAM but were actually for
Innolux P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
Let's unmosh.
Here's my evidence:
* Searching for TV123WAM on the Internet turns up a TI panel. While
it's possible that an Innolux panel has the same model number as the
TI Panel, it seems a little doubtful. Looking up the datasheet from
the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
* As far as I know, the patch adding the Innolux Panel was supposed to
be for the board that's sitting in front of me as I type this
(support for that board is not yet upstream). On the back of that
panel I see Innolux P120ZDZ-EZ1 rev B1.
* Someone pointed me at a datasheet that's supposed to be for the
panel in front of me (sorry, I can't share the datasheet). That
datasheet has the string "p120zdg-bf1"
* If I search for "P120ZDG-BF1" on the Internet I get hits for panels
that are 2160x1440. They don't have datasheets, but the fact that
the resolution matches is a good sign.
While we doing the rename, also mention that no-hpd can be used with
this panel. See the previous patch in this series ("drm/panel:
simple: Add "no-hpd" delay for Innolux TV123WAM").
Fixes: 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
bindings")
Signed-off-by: Douglas Anderson
Reviewed-by: Rob Herring
Cc: Sandeep Panda
---
Changes in v2: None
.../{innolux,tv123wam.txt => innolux,p120zdg-bf1.txt} | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
rename Documentation/devicetree/bindings/display/panel/{innolux,tv123wam.txt
=> innolux,p120zdg-bf1.txt} (70%)
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
similarity index 70%
rename from Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
rename to
Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
index a9b35265fa13..513f03466aba 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
@@ -1,20 +1,22 @@
-Innolux TV123WAM 12.3 inch eDP 2K display panel
+Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.
Required properties:
-- compatible: should be "innolux,tv123wam"
+- compatible: should be "innolux,p120zdg-bf1"
- power-supply: regulator to provide the supply voltage
Optional properties:
- enable-gpios: GPIO pin to enable or disable the panel
- backlight: phandle of the backlight device attached to the panel
+- no-hpd: If HPD isn't hooked up; add this property.
Example:
panel_edp: panel-edp {
- compatible = "innolux,tv123wam";
+ compatible = "innolux,p120zdg-bf1";
enable-gpios = < 31 GPIO_ACTIVE_LOW>;
power-supply = <_l2>;
backlight = <>;
+ no-hpd;
};
--
2.19.1.568.g152ad8e336-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] dt-bindings: drm/panel: simple: Add no-hpd property
Some eDP panels that are designed to be always connected to a board use their HPD signal to signal that they've finished powering on and they're ready to be talked to. However, for various reasons it's possible that the HPD signal from the panel isn't actually hooked up. In the case where the HPD isn't hooked up you can look at the timing diagram on the panel datasheet and insert a delay for the maximum amount of time that the HPD might take to come up. Let's add a property in the device tree for this concept. Signed-off-by: Douglas Anderson Reviewed-by: Sean Paul Reviewed-by: Rob Herring --- Changes in v2: None .../devicetree/bindings/display/panel/simple-panel.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt index 45a457ad38f0..b2b872c710f2 100644 --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt @@ -11,6 +11,9 @@ Optional properties: - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - enable-gpios: GPIO pin to enable or disable the panel - backlight: phandle of the backlight device attached to the panel +- no-hpd: This panel is supposed to communicate that it's ready via HPD + (hot plug detect) signal, but the signal isn't hooked up so we should + hardcode the max delay from the panel spec when powering up the panel. Example: -- 2.19.1.568.g152ad8e336-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
As far as I can tell the panel that was added in commit da50bd4258db
("drm/panel: simple: Add Innolux TV123WAM panel driver support")
wasn't actually an Innolux TV123WAM but was actually an Innolux
P120ZDG-BF1.
As far as I can tell the Innolux TV123WAM isn't a real panel and but
it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
Let's unmosh.
Here's my evidence:
* Searching for TV123WAM on the Internet turns up a TI panel. While
it's possible that an Innolux panel has the same model number as the
TI Panel, it seems a little doubtful. Looking up the datasheet from
the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
* As far as I know, the patch adding the Innolux Panel was supposed to
be for the board that's sitting in front of me as I type this
(support for that board is not yet upstream). On the back of that
panel I see Innolux P120ZDZ-EZ1 rev B1.
* Someone pointed me at a datasheet that's supposed to be for the
panel in front of me (sorry, I can't share the datasheet). That
datasheet has the string "p120zdg-bf1"
* If I search for "P120ZDG-BF1" on the Internet I get hits for panels
that are 2160x1440. They don't have datasheets, but the fact that
the resolution matches is a good sign.
In any case, let's update the name and also the physical size to match
the correct panel.
Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver
support")
Signed-off-by: Douglas Anderson
Reviewed-by: Abhinav Kumar
Cc: Sandeep Panda
---
Changes in v2: None
drivers/gpu/drm/panel/panel-simple.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 88592f9a0018..a04ffb3b2174 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1373,7 +1373,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
},
};
-static const struct drm_display_mode innolux_tv123wam_mode = {
+static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
.clock = 206016,
.hdisplay = 2160,
.hsync_start = 2160 + 48,
@@ -1387,13 +1387,13 @@ static const struct drm_display_mode
innolux_tv123wam_mode = {
.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
};
-static const struct panel_desc innolux_tv123wam = {
- .modes = _tv123wam_mode,
+static const struct panel_desc innolux_p120zdg_bf1 = {
+ .modes = _p120zdg_bf1_mode,
.num_modes = 1,
.bpc = 8,
.size = {
- .width = 259,
- .height = 173,
+ .width = 254,
+ .height = 169,
},
.delay = {
.hpd_absent_delay = 200,
@@ -2456,8 +2456,8 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,n156bge-l21",
.data = _n156bge_l21,
}, {
- .compatible = "innolux,tv123wam",
- .data = _tv123wam,
+ .compatible = "innolux,p120zdg-bf1",
+ .data = _p120zdg_bf1,
}, {
.compatible = "innolux,zj070na-01p",
.data = _zj070na_01p,
--
2.19.1.568.g152ad8e336-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM
If the HPD signal isn't hooked up to this panel we need a 200 ms
delay. In the datasheet this is shown as the maximum time that HPD
will take to be asserted after power is given to the panel.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Use "hpd_absent_delay" property instead of a bool + prepare delay
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 687fd087b9fc..88592f9a0018 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1396,6 +1396,7 @@ static const struct panel_desc innolux_tv123wam = {
.height = 173,
},
.delay = {
+ .hpd_absent_delay = 200,
.unprepare = 500,
},
};
--
2.19.1.568.g152ad8e336-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: tinydrm driver for adafruit PiTFT 3.5" touchscreen
Den 25.10.2018 18.29, skrev Eric Anholt: Eric Anholt writes: I was going to start working on making the vc4 driver work with tinydrm panels, but it turned out tinydrm didn't have the panel I had previously bought. So, last night I ported the fbtft staging driver over to DRM. It seems to work (with DT at https://github.com/anholt/linux/commits/drm-misc-next-hx8357d) -- fbdev works great including rotated, and so does modetest. However, when X11 comes up at 16bpp, I get: https://photos.app.goo.gl/8tuhzPFFoDGamEfk8 If I have tinydrm set a preferred bpp of 24, X looks great. Noralf, any ideas? Also, with these patches and the format modifier patch I just sent, mesa with vc4 is now working with this driver on this branch: https://gitlab.freedesktop.org/anholt/mesa/commits/kmsro Ah, nice to see this happening! Getting hw rendering was one of the advantages I saw DRM could provide over fbdev on these displays. Little did I know how complicated graphics was outside fbdev, so I was unable to realise this myself. The current solution to get hw rendering is to have a userspace process that continously copies the framebuffer: https://github.com/tasanakorn/rpi-fbcp It's used by some of the small DIY handheld game consoles that run emulators which requires hw rendering. Now I wonder how we can improve performance of the SPI updates. At what SPI speed are you running? The datasheet for most of these display controllers list the max speed as 10MHz, but almost all of them can go faster. Some are reported going as high as 70-80MHz. That's for the pixel data transfer, not the commands. tinydrm/mipi-dbi.c sends commands at 10MHz and pixels at full speed (mipi_dbi_spi_cmd_max_speed()). Most panels I have run at 32MHz or 48MHz. Almost all the time is spent in the SPI transfer, so every hz counts. On the Pi there's byte swapping because the DMA capable SPI controller can't do 16-bit (tinydrm_swab16()). If I remember correctly this has negligible impact on performance. The SPI controller/driver on the Pi has some restrictions on the speeds to choose from because the divisor has to be a multiple of two (bcm2835_spi_transfer_one()). A full update on a 320x480 RGB565 panel is 262.5kB, so it's a lot to push over SPI. A 2.8" 320x240 panel is more suitable for video fps, because of the lower resolution. I'll look at the patches during the weekend. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: new binding for Himax HX8357D display panels
On Wed, Oct 24, 2018 at 11:43:11AM -0700, Eric Anholt wrote:
> This adds a new binding for Himax HX8357D display panels. It includes
> a compatible string for one display (more can be added in the future).
>
> The YX350HV15 panel[1] is found in the Adafruit PiTFT 3.5" Touch
> Screen for Raspberry Pi.
>
> [1]
> https://learn.adafruit.com/adafruit-pitft-3-dot-5-touch-screen-for-raspberry-pi/downloads
>
> This binding is closely modeled after the ili9341 binding, for a
> similar product from adafruit. The primary difference is that the
> hx8367d doesn't have a reset line that I can find in the schematics.
>
> Signed-off-by: Eric Anholt
> ---
> .../bindings/display/himax,hx8357d.txt| 25 +++
> 1 file changed, 25 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/himax,hx8357d.txt
>
> diff --git a/Documentation/devicetree/bindings/display/himax,hx8357d.txt
> b/Documentation/devicetree/bindings/display/himax,hx8357d.txt
> new file mode 100644
> index ..48586e570be0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/himax,hx8357d.txt
> @@ -0,0 +1,25 @@
> +Himax HX8357D display panels
> +
> +This binding is for display panels using a Himax HX8357D controller in SPI
> +mode, such as the Adafruit 3.5" TFT for Raspberry Pi.
> +
> +Required properties:
> +- compatible:"adafruit,yx350hv15", "himax,hx8357d"
> +- dc-gpios: D/C pin
You forgot reg. Otherwise,
Reviewed-by: Rob Herring
> +
> +The node for this driver must be a child node of a SPI controller, hence
> +all mandatory properties described in ../spi/spi-bus.txt must be specified.
> +
> +Optional properties:
> +- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> + display@0{
> + compatible = "adafruit,yx350hv15", "himax,hx8357d";
> + reg = <0>;
> + spi-max-frequency = <3200>;
> + dc-gpios = < 25 GPIO_ACTIVE_HIGH>;
> + rotation = <90>;
> + backlight = <>;
> + };
> --
> 2.19.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
Re: [PATCH v10 1/2] drm/panel: Add support for Truly NT35597 panel driver
On Fri, Oct 05, 2018 at 05:52:18PM -0700, Abhinav Kumar wrote:
> Add support for Truly NT35597 panel driver used in MSM reference
> platforms. This panel driver supports both single DSI and dual
> DSI modes.
>
> However, this patch series adds support only for dual DSI mode.
>
> Changes in v10:
> - None
>
> Reviewed-by: Sean Paul
> Signed-off-by: Archit Taneja
> Signed-off-by: Abhinav Kumar
Thanks for keeping up with these patches, I've applied both to drm-misc-next.
Sean
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 675
>
> 3 files changed, 683 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6020c30..073ffa0 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -186,4 +186,11 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TRULY_NT35597_WQXGA
> + tristate "Truly WQXGA"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> DSI
> + Video Mode panel
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 5ccaaa9..80fd19f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> new file mode 100644
> index 000..fc2a66c
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> @@ -0,0 +1,675 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static const char * const regulator_names[] = {
> + "vdda",
> + "vdispp",
> + "vdispn",
> +};
> +
> +static unsigned long const regulator_enable_loads[] = {
> + 62000,
> + 10,
> + 10,
> +};
> +
> +static unsigned long const regulator_disable_loads[] = {
> + 80,
> + 100,
> + 100,
> +};
> +
> +struct cmd_set {
> + u8 commands[4];
> + u8 size;
> +};
> +
> +struct nt35597_config {
> + u32 width_mm;
> + u32 height_mm;
> + const char *panel_name;
> + const struct cmd_set *panel_on_cmds;
> + u32 num_on_cmds;
> + const struct drm_display_mode *dm;
> +};
> +
> +struct truly_nt35597 {
> + struct device *dev;
> + struct drm_panel panel;
> +
> + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *mode_gpio;
> +
> + struct backlight_device *backlight;
> +
> + struct mipi_dsi_device *dsi[2];
> +
> + const struct nt35597_config *config;
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline struct truly_nt35597 *panel_to_ctx(struct drm_panel *panel)
> +{
> + return container_of(panel, struct truly_nt35597, panel);
> +}
> +
> +static const struct cmd_set qcom_2k_panel_magic_cmds[] = {
> + /* CMD2_P0 */
> + { { 0xff, 0x20 }, 2 },
> + { { 0xfb, 0x01 }, 2 },
> + { { 0x00, 0x01 }, 2 },
> + { { 0x01, 0x55 }, 2 },
> + { { 0x02, 0x45 }, 2 },
> + { { 0x05, 0x40 }, 2 },
> + { { 0x06, 0x19 }, 2 },
> + { { 0x07, 0x1e }, 2 },
> + { { 0x0b, 0x73 }, 2 },
> + { { 0x0c, 0x73 }, 2 },
> + { { 0x0e, 0xb0 }, 2 },
> + { { 0x0f, 0xae }, 2 },
> + { { 0x11, 0xb8 }, 2 },
> + { { 0x13, 0x00 }, 2 },
> + { { 0x58, 0x80 }, 2 },
> + { { 0x59, 0x01 }, 2 },
> + { { 0x5a, 0x00 }, 2 },
> + { { 0x5b, 0x01 }, 2 },
> + { { 0x5c, 0x80 }, 2 },
> + { { 0x5d, 0x81 }, 2 },
> + { { 0x5e, 0x00 }, 2 },
> + { { 0x5f, 0x01 }, 2 },
> + { { 0x72, 0x11 }, 2 },
> + { { 0x68, 0x03 }, 2 },
> + /* CMD2_P4 */
> + { { 0xFF, 0x24 }, 2 },
> + { { 0xFB, 0x01 }, 2 },
> + { { 0x00, 0x1C }, 2 },
> + { { 0x01, 0x0B }, 2 },
> + { { 0x02, 0x0C }, 2 },
> + { { 0x03, 0x01 }, 2 },
> + { { 0x04, 0x0F }, 2 },
> + { { 0x05, 0x10 }, 2 },
> + { { 0x06, 0x10 }, 2 },
> + { { 0x07, 0x10 }, 2 },
> + { { 0x08, 0x89 }, 2 },
> + { { 0x09, 0x8A }, 2 },
> + { { 0x0A, 0x13 }, 2 },
> + { { 0x0B, 0x13 }, 2
Re: [PATCH 1/8] dma-buf: remove shared fence staging in reservation object
Quoting Chris Wilson (2018-10-25 21:20:21) > Quoting Chris Wilson (2018-10-25 21:15:17) > > Quoting Christian König (2018-10-04 14:12:43) > > > No need for that any more. Just replace the list when there isn't enough > > > room any more for the additional fence. > > > > Just a heads up. After this series landed, we started hitting a > > use-after-free when iterating the shared list. > > > > <4> [109.613162] general protection fault: [#1] PREEMPT SMP PTI > > <4> [109.613177] CPU: 1 PID: 1357 Comm: gem_busy Tainted: G U > > 4.19.0-rc8-CI-CI_DRM_5035+ #1 > > <4> [109.613189] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 > > 10/17/2011 > > <4> [109.613252] RIP: 0010:i915_gem_busy_ioctl+0x146/0x380 [i915] > > <4> [109.613261] Code: 0b 43 04 49 83 c6 08 4d 39 e6 89 43 04 74 6d 4d 8b > > 3e e8 5d 54 f4 e0 85 c0 74 0d 80 3d 08 71 1d 00 00 0f 84 bb 00 00 00 31 c0 > > <49> 81 7f 08 20 3a 2c a0 75 cc 41 8b 97 50 02 00 00 49 8b 8f a8 00 > > <4> [109.613283] RSP: 0018:c944bcf8 EFLAGS: 00010246 > > <4> [109.613292] RAX: RBX: c944bdc0 RCX: > > 0001 > > <4> [109.613302] RDX: RSI: RDI: > > 822474a0 > > <4> [109.613311] RBP: c944bd28 R08: 88021e158680 R09: > > 0001 > > <4> [109.613321] R10: 0040 R11: R12: > > 88021e1641b8 > > <4> [109.613331] R13: 0003 R14: 88021e1641b0 R15: > > 6b6b6b6b6b6b6b6b > > <4> [109.613341] FS: 7f9c9fc84980() GS:880227a4() > > knlGS: > > <4> [109.613352] CS: 0010 DS: ES: CR0: 80050033 > > <4> [109.613360] CR2: 7f9c9fcb8000 CR3: 0002247d4005 CR4: > > 000606e0 > > First guess would be > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c > index 5fb4fd461908..833698a0d548 100644 > --- a/drivers/dma-buf/reservation.c > +++ b/drivers/dma-buf/reservation.c > @@ -169,7 +169,6 @@ void reservation_object_add_shared_fence(struct > reservation_object *obj, > } > > BUG_ON(fobj->shared_count >= fobj->shared_max); > - fobj->shared_count++; > > replace: > /* > @@ -177,6 +176,8 @@ void reservation_object_add_shared_fence(struct > reservation_object *obj, > * fobj->shared_count is protected by this lock too > */ > RCU_INIT_POINTER(fobj->shared[i], fence); > + if (i == fobj->shared_count) > + fobj->shared_count++; > write_seqcount_end(>seq); > preempt_enable(); > } > > Strictly, perhaps WRITE_ONCE(fobj->shared_count, i + 1); ? Updating shared_count after setting the fence does the trick. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 1/2] drm/panel: Add support for Armadeus ST0700 Adapt
On Wed, 24 Oct 2018 14:54:56 +0200, =?UTF-8?q?S=C3=A9bastien=20Szymanski?= wrote: > This patch adds support for the Armadeus ST0700 Adapt. It comes with a > Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so > that it can be connected on the TFT header of Armadeus Dev boards. > > Signed-off-by: Sébastien Szymanski > --- > .../display/panel/armadeus,st0700-adapt.txt| 9 +++ > drivers/gpu/drm/panel/panel-simple.c | 29 > ++ > 2 files changed, 38 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/9] drm/atmel-hlcdc: Use drm_fbdev_generic_setup()
On Thu, 25 Oct 2018 22:13:37 +0200
Noralf Trønnes wrote:
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
> now handled by the emulation code. Additionally fbdev unregister happens
> automatically on drm_dev_unregister().
>
> The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
> driver. This is done to highlight the fact that fbdev emulation is an
> internal client that makes use of the driver, it is not part of the
> driver as such. If fbdev setup fails, an error is printed, but the driver
> succeeds probing.
>
> Cc: Boris Brezillon
> Signed-off-by: Noralf Trønnes
> Acked-by: Sam Ravnborg
Acked-by: Boris Brezillon
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index fedbfa333bb0..034a91112098 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -556,7 +556,6 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device
> *dev,
>
> static const struct drm_mode_config_funcs mode_config_funcs = {
> .fb_create = atmel_hlcdc_fb_create,
> - .output_poll_changed = drm_fb_helper_output_poll_changed,
> .atomic_check = drm_atomic_helper_check,
> .atomic_commit = atmel_hlcdc_dc_atomic_commit,
> };
> @@ -658,8 +657,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
>
> platform_set_drvdata(pdev, dev);
>
> - drm_fb_cma_fbdev_init(dev, 24, 0);
> -
> drm_kms_helper_poll_init(dev);
>
> return 0;
> @@ -678,7 +675,6 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
> {
> struct atmel_hlcdc_dc *dc = dev->dev_private;
>
> - drm_fb_cma_fbdev_fini(dev);
> flush_workqueue(dc->wq);
> drm_kms_helper_poll_fini(dev);
> drm_atomic_helper_shutdown(dev);
> @@ -727,7 +723,6 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
> .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
> DRIVER_MODESET | DRIVER_PRIME |
> DRIVER_ATOMIC,
> - .lastclose = drm_fb_helper_lastclose,
> .irq_handler = atmel_hlcdc_dc_irq_handler,
> .irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
> .irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
> @@ -769,6 +764,8 @@ static int atmel_hlcdc_dc_drm_probe(struct
> platform_device *pdev)
> if (ret)
> goto err_unload;
>
> + drm_fbdev_generic_setup(ddev, 24);
> +
> return 0;
>
> err_unload:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] dma-buf: remove shared fence staging in reservation object
Quoting Chris Wilson (2018-10-25 21:15:17) > Quoting Christian König (2018-10-04 14:12:43) > > No need for that any more. Just replace the list when there isn't enough > > room any more for the additional fence. > > Just a heads up. After this series landed, we started hitting a > use-after-free when iterating the shared list. > > <4> [109.613162] general protection fault: [#1] PREEMPT SMP PTI > <4> [109.613177] CPU: 1 PID: 1357 Comm: gem_busy Tainted: G U > 4.19.0-rc8-CI-CI_DRM_5035+ #1 > <4> [109.613189] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 > 10/17/2011 > <4> [109.613252] RIP: 0010:i915_gem_busy_ioctl+0x146/0x380 [i915] > <4> [109.613261] Code: 0b 43 04 49 83 c6 08 4d 39 e6 89 43 04 74 6d 4d 8b 3e > e8 5d 54 f4 e0 85 c0 74 0d 80 3d 08 71 1d 00 00 0f 84 bb 00 00 00 31 c0 <49> > 81 7f 08 20 3a 2c a0 75 cc 41 8b 97 50 02 00 00 49 8b 8f a8 00 > <4> [109.613283] RSP: 0018:c944bcf8 EFLAGS: 00010246 > <4> [109.613292] RAX: RBX: c944bdc0 RCX: > 0001 > <4> [109.613302] RDX: RSI: RDI: > 822474a0 > <4> [109.613311] RBP: c944bd28 R08: 88021e158680 R09: > 0001 > <4> [109.613321] R10: 0040 R11: R12: > 88021e1641b8 > <4> [109.613331] R13: 0003 R14: 88021e1641b0 R15: > 6b6b6b6b6b6b6b6b > <4> [109.613341] FS: 7f9c9fc84980() GS:880227a4() > knlGS: > <4> [109.613352] CS: 0010 DS: ES: CR0: 80050033 > <4> [109.613360] CR2: 7f9c9fcb8000 CR3: 0002247d4005 CR4: > 000606e0 First guess would be diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c index 5fb4fd461908..833698a0d548 100644 --- a/drivers/dma-buf/reservation.c +++ b/drivers/dma-buf/reservation.c @@ -169,7 +169,6 @@ void reservation_object_add_shared_fence(struct reservation_object *obj, } BUG_ON(fobj->shared_count >= fobj->shared_max); - fobj->shared_count++; replace: /* @@ -177,6 +176,8 @@ void reservation_object_add_shared_fence(struct reservation_object *obj, * fobj->shared_count is protected by this lock too */ RCU_INIT_POINTER(fobj->shared[i], fence); + if (i == fobj->shared_count) + fobj->shared_count++; write_seqcount_end(>seq); preempt_enable(); } Strictly, perhaps WRITE_ONCE(fobj->shared_count, i + 1); ? -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] dma-buf: remove shared fence staging in reservation object
Quoting Christian König (2018-10-04 14:12:43) > No need for that any more. Just replace the list when there isn't enough > room any more for the additional fence. Just a heads up. After this series landed, we started hitting a use-after-free when iterating the shared list. <4> [109.613162] general protection fault: [#1] PREEMPT SMP PTI <4> [109.613177] CPU: 1 PID: 1357 Comm: gem_busy Tainted: G U 4.19.0-rc8-CI-CI_DRM_5035+ #1 <4> [109.613189] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 10/17/2011 <4> [109.613252] RIP: 0010:i915_gem_busy_ioctl+0x146/0x380 [i915] <4> [109.613261] Code: 0b 43 04 49 83 c6 08 4d 39 e6 89 43 04 74 6d 4d 8b 3e e8 5d 54 f4 e0 85 c0 74 0d 80 3d 08 71 1d 00 00 0f 84 bb 00 00 00 31 c0 <49> 81 7f 08 20 3a 2c a0 75 cc 41 8b 97 50 02 00 00 49 8b 8f a8 00 <4> [109.613283] RSP: 0018:c944bcf8 EFLAGS: 00010246 <4> [109.613292] RAX: RBX: c944bdc0 RCX: 0001 <4> [109.613302] RDX: RSI: RDI: 822474a0 <4> [109.613311] RBP: c944bd28 R08: 88021e158680 R09: 0001 <4> [109.613321] R10: 0040 R11: R12: 88021e1641b8 <4> [109.613331] R13: 0003 R14: 88021e1641b0 R15: 6b6b6b6b6b6b6b6b <4> [109.613341] FS: 7f9c9fc84980() GS:880227a4() knlGS: <4> [109.613352] CS: 0010 DS: ES: CR0: 80050033 <4> [109.613360] CR2: 7f9c9fcb8000 CR3: 0002247d4005 CR4: 000606e0 -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 8/9] drm/tilcdc: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 33e533268488..3dac08b24140 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -140,7 +140,6 @@ static int tilcdc_commit(struct drm_device *dev,
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = tilcdc_fb_create,
- .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = tilcdc_atomic_check,
.atomic_commit = tilcdc_commit,
};
@@ -191,9 +190,6 @@ static void tilcdc_fini(struct drm_device *dev)
drm_dev_unregister(dev);
drm_kms_helper_poll_fini(dev);
-
- drm_fb_cma_fbdev_fini(dev);
-
drm_irq_uninstall(dev);
drm_mode_config_cleanup(dev);
tilcdc_remove_external_device(dev);
@@ -396,16 +392,14 @@ static int tilcdc_init(struct drm_driver *ddrv, struct
device *dev)
drm_mode_config_reset(ddev);
- ret = drm_fb_cma_fbdev_init(ddev, bpp, 0);
- if (ret)
- goto init_failed;
-
drm_kms_helper_poll_init(ddev);
ret = drm_dev_register(ddev, 0);
if (ret)
goto init_failed;
+ drm_fbdev_generic_setup(ddev, bpp);
+
priv->is_registered = true;
return 0;
@@ -519,7 +513,6 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
static struct drm_driver tilcdc_driver = {
.driver_features= (DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET |
DRIVER_PRIME | DRIVER_ATOMIC),
- .lastclose = drm_fb_helper_lastclose,
.irq_handler= tilcdc_irq,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_print_info = drm_gem_cma_print_info,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/9] drm/atmel-hlcdc: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Boris Brezillon
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index fedbfa333bb0..034a91112098 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -556,7 +556,6 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device
*dev,
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = atmel_hlcdc_fb_create,
- .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = atmel_hlcdc_dc_atomic_commit,
};
@@ -658,8 +657,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
platform_set_drvdata(pdev, dev);
- drm_fb_cma_fbdev_init(dev, 24, 0);
-
drm_kms_helper_poll_init(dev);
return 0;
@@ -678,7 +675,6 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
{
struct atmel_hlcdc_dc *dc = dev->dev_private;
- drm_fb_cma_fbdev_fini(dev);
flush_workqueue(dc->wq);
drm_kms_helper_poll_fini(dev);
drm_atomic_helper_shutdown(dev);
@@ -727,7 +723,6 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
.driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
DRIVER_MODESET | DRIVER_PRIME |
DRIVER_ATOMIC,
- .lastclose = drm_fb_helper_lastclose,
.irq_handler = atmel_hlcdc_dc_irq_handler,
.irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
.irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
@@ -769,6 +764,8 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device
*pdev)
if (ret)
goto err_unload;
+ drm_fbdev_generic_setup(ddev, 24);
+
return 0;
err_unload:
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/9] drm/rcar-du: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
---
Changes since version 1:
- Rebased on: drm/rcar-du: Convert drm_atomic_helper_suspend/resume()
Laurent, do you want to take this through your tree, or do you want me to
apply it to drm-misc-next?
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 15 ---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 -
3 files changed, 4 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 7015974c247a..27bfccd5b136 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -21,7 +21,9 @@
#include
#include
#include
+#include
#include
+#include
#include "rcar_du_drv.h"
#include "rcar_du_kms.h"
@@ -363,19 +365,11 @@ MODULE_DEVICE_TABLE(of, rcar_du_of_table);
* DRM operations
*/
-static void rcar_du_lastclose(struct drm_device *dev)
-{
- struct rcar_du_device *rcdu = dev->dev_private;
-
- drm_fbdev_cma_restore_mode(rcdu->fbdev);
-}
-
DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
static struct drm_driver rcar_du_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
| DRIVER_ATOMIC,
- .lastclose = rcar_du_lastclose,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
@@ -431,9 +425,6 @@ static int rcar_du_remove(struct platform_device *pdev)
drm_dev_unregister(ddev);
- if (rcdu->fbdev)
- drm_fbdev_cma_fini(rcdu->fbdev);
-
drm_kms_helper_poll_fini(ddev);
drm_mode_config_cleanup(ddev);
@@ -493,6 +484,8 @@ static int rcar_du_probe(struct platform_device *pdev)
DRM_INFO("Device %s probed\n", dev_name(>dev));
+ drm_fbdev_generic_setup(ddev, 32);
+
return 0;
error:
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 9f5563296c5a..a68da79b424e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -20,7 +20,6 @@
struct clk;
struct device;
struct drm_device;
-struct drm_fbdev_cma;
struct rcar_du_device;
#define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK BIT(0) /* Per-CRTC IRQ and clock */
@@ -78,7 +77,6 @@ struct rcar_du_device {
void __iomem *mmio;
struct drm_device *ddev;
- struct drm_fbdev_cma *fbdev;
struct rcar_du_crtc crtcs[RCAR_DU_MAX_CRTCS];
unsigned int num_crtcs;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 4ebd61ecbee1..6562871aa706 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -255,13 +255,6 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
-static void rcar_du_output_poll_changed(struct drm_device *dev)
-{
- struct rcar_du_device *rcdu = dev->dev_private;
-
- drm_fbdev_cma_hotplug_event(rcdu->fbdev);
-}
-
/*
-
* Atomic Check and Update
*/
@@ -308,7 +301,6 @@ static const struct drm_mode_config_helper_funcs
rcar_du_mode_config_helper = {
static const struct drm_mode_config_funcs rcar_du_mode_config_funcs = {
.fb_create = rcar_du_fb_create,
- .output_poll_changed = rcar_du_output_poll_changed,
.atomic_check = rcar_du_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -543,7 +535,6 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
struct drm_device *dev = rcdu->ddev;
struct drm_encoder *encoder;
- struct drm_fbdev_cma *fbdev;
unsigned int dpad0_sources;
unsigned int num_encoders;
unsigned int num_groups;
@@ -682,17 +673,5 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
[PATCH v2 7/9] drm/sun4i: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Maxime Ripard
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 12 +++-
drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 12 +---
drivers/gpu/drm/sun4i/sun4i_framebuffer.h | 3 +--
3 files changed, 5 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 1e41c3f5fd6d..ef773d36baf0 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -34,7 +34,6 @@ static struct drm_driver sun4i_drv_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
DRIVER_ATOMIC,
/* Generic Operations */
- .lastclose = drm_fb_helper_lastclose,
.fops = _drv_fops,
.name = "sun4i-drm",
.desc = "Allwinner sun4i Display Engine",
@@ -105,12 +104,7 @@ static int sun4i_drv_bind(struct device *dev)
/* Remove early framebuffers (ie. simplefb) */
drm_fb_helper_remove_conflicting_framebuffers(NULL, "sun4i-drm-fb",
false);
- /* Create our framebuffer */
- ret = sun4i_framebuffer_init(drm);
- if (ret) {
- dev_err(drm->dev, "Couldn't create our framebuffer\n");
- goto cleanup_mode_config;
- }
+ sun4i_framebuffer_init(drm);
/* Enable connectors polling */
drm_kms_helper_poll_init(drm);
@@ -119,11 +113,12 @@ static int sun4i_drv_bind(struct device *dev)
if (ret)
goto finish_poll;
+ drm_fbdev_generic_setup(drm, 32);
+
return 0;
finish_poll:
drm_kms_helper_poll_fini(drm);
- sun4i_framebuffer_free(drm);
cleanup_mode_config:
drm_mode_config_cleanup(drm);
of_reserved_mem_device_release(dev);
@@ -138,7 +133,6 @@ static void sun4i_drv_unbind(struct device *dev)
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
- sun4i_framebuffer_free(drm);
drm_mode_config_cleanup(drm);
of_reserved_mem_device_release(dev);
drm_dev_put(drm);
diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
index 5f29850ef8ac..cb828028ae06 100644
--- a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
@@ -12,8 +12,6 @@
#include
#include
-#include
-#include
#include
#include
@@ -37,7 +35,6 @@ static int sun4i_de_atomic_check(struct drm_device *dev,
}
static const struct drm_mode_config_funcs sun4i_de_mode_config_funcs = {
- .output_poll_changed= drm_fb_helper_output_poll_changed,
.atomic_check = sun4i_de_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
.fb_create = drm_gem_fb_create,
@@ -47,7 +44,7 @@ static struct drm_mode_config_helper_funcs
sun4i_de_mode_config_helpers = {
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
};
-int sun4i_framebuffer_init(struct drm_device *drm)
+void sun4i_framebuffer_init(struct drm_device *drm)
{
drm_mode_config_reset(drm);
@@ -56,11 +53,4 @@ int sun4i_framebuffer_init(struct drm_device *drm)
drm->mode_config.funcs = _de_mode_config_funcs;
drm->mode_config.helper_private = _de_mode_config_helpers;
-
- return drm_fb_cma_fbdev_init(drm, 32, 0);
-}
-
-void sun4i_framebuffer_free(struct drm_device *drm)
-{
- drm_fb_cma_fbdev_fini(drm);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.h
b/drivers/gpu/drm/sun4i/sun4i_framebuffer.h
index 7ef0aed8384c..6fe5bd8c4026 100644
--- a/drivers/gpu/drm/sun4i/sun4i_framebuffer.h
+++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.h
@@ -13,7 +13,6 @@
#ifndef _SUN4I_FRAMEBUFFER_H_
#define _SUN4I_FRAMEBUFFER_H_
-int sun4i_framebuffer_init(struct drm_device *drm);
-void sun4i_framebuffer_free(struct drm_device *drm);
+void sun4i_framebuffer_init(struct drm_device *drm);
#endif /* _SUN4I_FRAMEBUFFER_H_ */
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 9/9] drm/cma-helper: Remove unused fbdev code
CMA helper drivers have been converted to drm_fbdev_generic_setup()
so the fbdev code can be removed.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
Changes since version 1:
- Rebased
drivers/gpu/drm/Kconfig | 4 --
drivers/gpu/drm/drm_fb_cma_helper.c | 130
include/drm/drm_fb_cma_helper.h | 22 --
3 files changed, 156 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4385f00e1d05..bd943a71756c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -170,10 +170,6 @@ config DRM_KMS_CMA_HELPER
bool
depends on DRM
select DRM_GEM_CMA_HELPER
- select DRM_KMS_FB_HELPER
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
help
Choose this if you need the KMS CMA helper functions
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index fc2b42dd3dc6..0ddf9c65e5ab 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -18,8 +18,6 @@
*/
#include
-#include
-#include
#include
#include
#include
@@ -27,10 +25,6 @@
#include
#include
-struct drm_fbdev_cma {
- struct drm_fb_helperfb_helper;
-};
-
/**
* DOC: framebuffer cma helper functions
*
@@ -39,16 +33,8 @@ struct drm_fbdev_cma {
*
* drm_gem_fb_create() is used in the _mode_config_funcs.fb_create
* callback function to create a cma backed framebuffer.
- *
- * An fbdev framebuffer backed by cma is also available by calling
- * drm_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down.
*/
-static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
-{
- return container_of(helper, struct drm_fbdev_cma, fb_helper);
-}
-
/**
* drm_fb_cma_get_gem_obj() - Get CMA GEM object for framebuffer
* @fb: The framebuffer
@@ -105,119 +91,3 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
return paddr;
}
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
-
-/**
- * drm_fb_cma_fbdev_init() - Allocate and initialize fbdev emulation
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device.
- * @dev->mode_config.preferred_depth is used if this is zero.
- * @max_conn_count: Maximum number of connectors.
- * @dev->mode_config.num_connector is used if this is zero.
- *
- * Returns:
- * Zero on success or negative error code on failure.
- */
-int drm_fb_cma_fbdev_init(struct drm_device *dev, unsigned int preferred_bpp,
- unsigned int max_conn_count)
-{
- struct drm_fbdev_cma *fbdev_cma;
-
- /* dev->fb_helper will indirectly point to fbdev_cma after this call */
- fbdev_cma = drm_fbdev_cma_init(dev, preferred_bpp, max_conn_count);
- return PTR_ERR_OR_ZERO(fbdev_cma);
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_init);
-
-/**
- * drm_fb_cma_fbdev_fini() - Teardown fbdev emulation
- * @dev: DRM device
- */
-void drm_fb_cma_fbdev_fini(struct drm_device *dev)
-{
- if (dev->fb_helper)
- drm_fbdev_cma_fini(to_fbdev_cma(dev->fb_helper));
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_fini);
-
-static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
- .fb_probe = drm_fb_helper_generic_probe,
-};
-
-/**
- * drm_fbdev_cma_init() - Allocate and initializes a drm_fbdev_cma struct
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device
- * @max_conn_count: Maximum number of connectors
- *
- * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
- */
-struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
- unsigned int preferred_bpp, unsigned int max_conn_count)
-{
- struct drm_fbdev_cma *fbdev_cma;
- struct drm_fb_helper *fb_helper;
- int ret;
-
- fbdev_cma = kzalloc(sizeof(*fbdev_cma), GFP_KERNEL);
- if (!fbdev_cma)
- return ERR_PTR(-ENOMEM);
-
- fb_helper = _cma->fb_helper;
-
- ret = drm_client_new(dev, _helper->client, "fbdev", NULL);
- if (ret)
- goto err_free;
-
- ret = drm_fb_helper_fbdev_setup(dev, fb_helper,
_fb_cma_helper_funcs,
- preferred_bpp, max_conn_count);
- if (ret)
- goto err_client_put;
-
- return fbdev_cma;
-
-err_client_put:
- drm_client_release(_helper->client);
-err_free:
- kfree(fbdev_cma);
-
- return ERR_PTR(ret);
-}
-EXPORT_SYMBOL_GPL(drm_fbdev_cma_init);
-
-/**
- * drm_fbdev_cma_fini() - Free drm_fbdev_cma struct
- * @fbdev_cma: The drm_fbdev_cma struct
- */
-void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma)
-{
- drm_fb_helper_unregister_fbi(_cma->fb_helper);
- /* All resources have now been freed by drm_fbdev_fb_destroy() */
-}
-EXPORT_SYMBOL_GPL(drm_fbdev_cma_fini);
-
-/**
- * drm_fbdev_cma_restore_mode() - Restores
[PATCH v2 2/9] drm/fsl-dcu: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Stefan Agner
Cc: Alison Wang
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
Acked-by: Stefan Agner
---
Changes since version 1:
- Rebased
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 +++--
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 1 -
2 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 0496be5212e1..ceddc3e29258 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -89,20 +90,11 @@ static int fsl_dcu_load(struct drm_device *dev, unsigned
long flags)
"Invalid legacyfb_depth. Defaulting to 24bpp\n");
legacyfb_depth = 24;
}
- fsl_dev->fbdev = drm_fbdev_cma_init(dev, legacyfb_depth, 1);
- if (IS_ERR(fsl_dev->fbdev)) {
- ret = PTR_ERR(fsl_dev->fbdev);
- fsl_dev->fbdev = NULL;
- goto done;
- }
return 0;
done:
drm_kms_helper_poll_fini(dev);
- if (fsl_dev->fbdev)
- drm_fbdev_cma_fini(fsl_dev->fbdev);
-
drm_mode_config_cleanup(dev);
drm_irq_uninstall(dev);
dev->dev_private = NULL;
@@ -112,14 +104,9 @@ static int fsl_dcu_load(struct drm_device *dev, unsigned
long flags)
static void fsl_dcu_unload(struct drm_device *dev)
{
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
-
drm_atomic_helper_shutdown(dev);
drm_kms_helper_poll_fini(dev);
- if (fsl_dev->fbdev)
- drm_fbdev_cma_fini(fsl_dev->fbdev);
-
drm_mode_config_cleanup(dev);
drm_irq_uninstall(dev);
@@ -147,19 +134,11 @@ static irqreturn_t fsl_dcu_drm_irq(int irq, void *arg)
return IRQ_HANDLED;
}
-static void fsl_dcu_drm_lastclose(struct drm_device *dev)
-{
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
-
- drm_fbdev_cma_restore_mode(fsl_dev->fbdev);
-}
-
DEFINE_DRM_GEM_CMA_FOPS(fsl_dcu_drm_fops);
static struct drm_driver fsl_dcu_drm_driver = {
.driver_features= DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET
| DRIVER_PRIME | DRIVER_ATOMIC,
- .lastclose = fsl_dcu_drm_lastclose,
.load = fsl_dcu_load,
.unload = fsl_dcu_unload,
.irq_handler= fsl_dcu_drm_irq,
@@ -355,6 +334,8 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
if (ret < 0)
goto put;
+ drm_fbdev_generic_setup(drm, legacyfb_depth);
+
return 0;
put:
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
index 93bfb98012d4..cb87bb74cb87 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
@@ -191,7 +191,6 @@ struct fsl_dcu_drm_device {
/*protects hardware register*/
spinlock_t irq_lock;
struct drm_device *drm;
- struct drm_fbdev_cma *fbdev;
struct drm_crtc crtc;
struct drm_encoder encoder;
struct fsl_dcu_drm_connector connector;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/9] drm/hisilicon/kirin: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
struct kirin_drm_private can be removed now that driver doesn't have to
store the fbdev pointer.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38 ++---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 4 ---
2 files changed, 3 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index e6a62d5a00a3..15e32e5d9101 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -33,32 +34,15 @@ static struct kirin_dc_ops *dc_ops;
static int kirin_drm_kms_cleanup(struct drm_device *dev)
{
- struct kirin_drm_private *priv = dev->dev_private;
-
- if (priv->fbdev) {
- drm_fbdev_cma_fini(priv->fbdev);
- priv->fbdev = NULL;
- }
-
drm_kms_helper_poll_fini(dev);
dc_ops->cleanup(to_platform_device(dev->dev));
drm_mode_config_cleanup(dev);
- devm_kfree(dev->dev, priv);
- dev->dev_private = NULL;
return 0;
}
-static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
-{
- struct kirin_drm_private *priv = dev->dev_private;
-
- drm_fbdev_cma_hotplug_event(priv->fbdev);
-}
-
static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
- .output_poll_changed = kirin_fbdev_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -76,14 +60,8 @@ static void kirin_drm_mode_config_init(struct drm_device
*dev)
static int kirin_drm_kms_init(struct drm_device *dev)
{
- struct kirin_drm_private *priv;
int ret;
- priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
-
- dev->dev_private = priv;
dev_set_drvdata(dev->dev, dev);
/* dev->mode_config initialization */
@@ -117,26 +95,14 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
- priv->fbdev = drm_fbdev_cma_init(dev, 32,
-dev->mode_config.num_connector);
-
- if (IS_ERR(priv->fbdev)) {
- DRM_ERROR("failed to initialize fbdev.\n");
- ret = PTR_ERR(priv->fbdev);
- goto err_cleanup_poll;
- }
return 0;
-err_cleanup_poll:
- drm_kms_helper_poll_fini(dev);
err_unbind_all:
component_unbind_all(dev->dev, dev);
err_dc_cleanup:
dc_ops->cleanup(to_platform_device(dev->dev));
err_mode_config_cleanup:
drm_mode_config_cleanup(dev);
- devm_kfree(dev->dev, priv);
- dev->dev_private = NULL;
return ret;
}
@@ -199,6 +165,8 @@ static int kirin_drm_bind(struct device *dev)
if (ret)
goto err_kms_cleanup;
+ drm_fbdev_generic_setup(drm_dev, 32);
+
return 0;
err_kms_cleanup:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 56cb62df065c..ad027d1cc826 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -19,10 +19,6 @@ struct kirin_dc_ops {
void (*cleanup)(struct platform_device *pdev);
};
-struct kirin_drm_private {
- struct drm_fbdev_cma *fbdev;
-};
-
extern const struct kirin_dc_ops ade_dc_ops;
#endif /* __KIRIN_DRM_DRV_H__ */
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/9] drm/mxsfb: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Marek Vasut
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 26 ++
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 1 -
2 files changed, 2 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 2393e6d16ffd..3a8cc4226a4b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -263,23 +263,12 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
drm_kms_helper_poll_init(drm);
- mxsfb->fbdev = drm_fbdev_cma_init(drm, 32,
- drm->mode_config.num_connector);
- if (IS_ERR(mxsfb->fbdev)) {
- ret = PTR_ERR(mxsfb->fbdev);
- mxsfb->fbdev = NULL;
- dev_err(drm->dev, "Failed to init FB CMA area\n");
- goto err_cma;
- }
-
platform_set_drvdata(pdev, drm);
drm_helper_hpd_irq_event(drm);
return 0;
-err_cma:
- drm_irq_uninstall(drm);
err_irq:
drm_panel_detach(mxsfb->panel);
err_vblank:
@@ -290,11 +279,6 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
static void mxsfb_unload(struct drm_device *drm)
{
- struct mxsfb_drm_private *mxsfb = drm->dev_private;
-
- if (mxsfb->fbdev)
- drm_fbdev_cma_fini(mxsfb->fbdev);
-
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
@@ -307,13 +291,6 @@ static void mxsfb_unload(struct drm_device *drm)
pm_runtime_disable(drm->dev);
}
-static void mxsfb_lastclose(struct drm_device *drm)
-{
- struct mxsfb_drm_private *mxsfb = drm->dev_private;
-
- drm_fbdev_cma_restore_mode(mxsfb->fbdev);
-}
-
static void mxsfb_irq_preinstall(struct drm_device *drm)
{
struct mxsfb_drm_private *mxsfb = drm->dev_private;
@@ -347,7 +324,6 @@ static struct drm_driver mxsfb_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET |
DRIVER_PRIME | DRIVER_ATOMIC |
DRIVER_HAVE_IRQ,
- .lastclose = mxsfb_lastclose,
.irq_handler= mxsfb_irq_handler,
.irq_preinstall = mxsfb_irq_preinstall,
.irq_uninstall = mxsfb_irq_preinstall,
@@ -412,6 +388,8 @@ static int mxsfb_probe(struct platform_device *pdev)
if (ret)
goto err_unload;
+ drm_fbdev_generic_setup(drm, 32);
+
return 0;
err_unload:
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index 5d0883fc805b..bedd6801edca 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -37,7 +37,6 @@ struct mxsfb_drm_private {
struct drm_simple_display_pipe pipe;
struct drm_connectorconnector;
struct drm_panel*panel;
- struct drm_fbdev_cma*fbdev;
};
int mxsfb_setup_crtc(struct drm_device *dev);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/9] drm/cma-helper drivers: Use drm_fbdev_generic_setup()
This patchset moves the drivers using the CMA helper fully over to the generic fbdev emulation. These are the remaining patches that didn't get a driver maintainer ack or has been rebased. For context, this is part 1 of the generic fbdev emulation: drm: Add generic fbdev emulation https://patchwork.freedesktop.org/series/45848/ Noralf. Cc: Alexey Brodkin Cc: Stefan Agner Cc: Xinliang Liu Cc: Rongrong Zou Cc: Xinwei Kong Cc: Chen Feng Cc: Marek Vasut Cc: Laurent Pinchart Cc: Boris Brezillon Cc: Maxime Ripard Cc: Jyri Sarha Cc: Tomi Valkeinen Noralf Trønnes (9): drm/arc: Use drm_fbdev_generic_setup() drm/fsl-dcu: Use drm_fbdev_generic_setup() drm/hisilicon/kirin: Use drm_fbdev_generic_setup() drm/mxsfb: Use drm_fbdev_generic_setup() drm/rcar-du: Use drm_fbdev_generic_setup() drm/atmel-hlcdc: Use drm_fbdev_generic_setup() drm/sun4i: Use drm_fbdev_generic_setup() drm/tilcdc: Use drm_fbdev_generic_setup() drm/cma-helper: Remove unused fbdev code drivers/gpu/drm/Kconfig | 4 - drivers/gpu/drm/arc/arcpgu.h| 4 - drivers/gpu/drm/arc/arcpgu_drv.c| 33 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 7 +- drivers/gpu/drm/drm_fb_cma_helper.c | 130 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 1 - drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38 +-- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 4 - drivers/gpu/drm/mxsfb/mxsfb_drv.c | 26 + drivers/gpu/drm/mxsfb/mxsfb_drv.h | 1 - drivers/gpu/drm/rcar-du/rcar_du_drv.c | 15 +-- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 drivers/gpu/drm/sun4i/sun4i_drv.c | 12 +-- drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 12 +-- drivers/gpu/drm/sun4i/sun4i_framebuffer.h | 3 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 11 +- include/drm/drm_fb_cma_helper.h | 22 19 files changed, 24 insertions(+), 347 deletions(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/9] drm/arc: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Alexey Brodkin
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
Acked-by: Alexey Brodkin
---
Changes since version 1:
- Rebased
drivers/gpu/drm/arc/arcpgu.h | 4
drivers/gpu/drm/arc/arcpgu_drv.c | 33 +++--
2 files changed, 3 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index e8fcf3ab1d9a..90ef76b19f8a 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -20,7 +20,6 @@
struct arcpgu_drm_private {
void __iomem*regs;
struct clk *clk;
- struct drm_fbdev_cma*fbdev;
struct drm_framebuffer *fb;
struct drm_crtc crtc;
struct drm_plane*plane;
@@ -43,8 +42,5 @@ static inline u32 arc_pgu_read(struct arcpgu_drm_private
*arcpgu,
int arc_pgu_setup_crtc(struct drm_device *dev);
int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np);
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
-struct drm_fbdev_cma *arcpgu_fbdev_cma_init(struct drm_device *dev,
- unsigned int preferred_bpp, unsigned int num_crtc,
- unsigned int max_conn_count);
#endif
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index e85e3a349f24..2af847ebca34 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,16 +26,8 @@
#include "arcpgu.h"
#include "arcpgu_regs.h"
-static void arcpgu_fb_output_poll_changed(struct drm_device *dev)
-{
- struct arcpgu_drm_private *arcpgu = dev->dev_private;
-
- drm_fbdev_cma_hotplug_event(arcpgu->fbdev);
-}
-
static const struct drm_mode_config_funcs arcpgu_drm_modecfg_funcs = {
.fb_create = drm_gem_fb_create,
- .output_poll_changed = arcpgu_fb_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -51,13 +44,6 @@ static void arcpgu_setup_mode_config(struct drm_device *drm)
DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops);
-static void arcpgu_lastclose(struct drm_device *drm)
-{
- struct arcpgu_drm_private *arcpgu = drm->dev_private;
-
- drm_fbdev_cma_restore_mode(arcpgu->fbdev);
-}
-
static int arcpgu_load(struct drm_device *drm)
{
struct platform_device *pdev = to_platform_device(drm->dev);
@@ -113,26 +99,12 @@ static int arcpgu_load(struct drm_device *drm)
drm_mode_config_reset(drm);
drm_kms_helper_poll_init(drm);
- arcpgu->fbdev = drm_fbdev_cma_init(drm, 16,
- drm->mode_config.num_connector);
- if (IS_ERR(arcpgu->fbdev)) {
- ret = PTR_ERR(arcpgu->fbdev);
- arcpgu->fbdev = NULL;
- return -ENODEV;
- }
-
platform_set_drvdata(pdev, drm);
return 0;
}
static int arcpgu_unload(struct drm_device *drm)
{
- struct arcpgu_drm_private *arcpgu = drm->dev_private;
-
- if (arcpgu->fbdev) {
- drm_fbdev_cma_fini(arcpgu->fbdev);
- arcpgu->fbdev = NULL;
- }
drm_kms_helper_poll_fini(drm);
drm_atomic_helper_shutdown(drm);
drm_mode_config_cleanup(drm);
@@ -168,7 +140,6 @@ static int arcpgu_debugfs_init(struct drm_minor *minor)
static struct drm_driver arcpgu_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
DRIVER_ATOMIC,
- .lastclose = arcpgu_lastclose,
.name = "arcpgu",
.desc = "ARC PGU Controller",
.date = "20160219",
@@ -211,6 +182,8 @@ static int arcpgu_probe(struct platform_device *pdev)
if (ret)
goto err_unload;
+ drm_fbdev_generic_setup(drm, 16);
+
return 0;
err_unload:
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 27/28] drm/i915/dsc: Add Per connector debugfs node for DSC support/enable
On Wed, Oct 24, 2018 at 06:28:02PM -0400, Lyude Paul wrote:
> On Wed, 2018-10-24 at 15:28 -0700, Manasi Navare wrote:
> > DSC can be supported per DP connector. This patch adds a per connector
> > debugfs node to expose DSC support capability by the kernel.
> > The same node can be used from userspace to force DSC enable.
> >
> > v2:
> > * Use kstrtobool_from_user to avoid explicit error checking (Lyude)
> > * Rebase on drm-tip (Manasi)
> >
> > Cc: Rodrigo Vivi
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Lyude Paul
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Lyude Paul
>
> (just making a note to anyone passing by this: my R-B here is still valid!)
> (also thanks for the patch :)
Thanks Lyude for thsi note and the initial review feedback! Appreciate your
time and inputs.
Manasi
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 71 -
> > drivers/gpu/drm/i915/intel_dp.c | 1 +
> > drivers/gpu/drm/i915/intel_drv.h| 3 ++
> > 3 files changed, 74 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 5cadfcd03ea9..6e631f08dd4b 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -4999,6 +4999,72 @@ static int i915_hdcp_sink_capability_show(struct
> > seq_file *m, void *data)
> > }
> > DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
> >
> > +static int i915_dsc_support_show(struct seq_file *m, void *data)
> > +{
> > + struct drm_connector *connector = m->private;
> > + struct intel_encoder *encoder = intel_attached_encoder(connector);
> > + struct intel_dp *intel_dp =
> > + enc_to_intel_dp(>base);
> > + struct intel_crtc *crtc;
> > + struct intel_crtc_state *crtc_state;
> > +
> > + crtc = to_intel_crtc(encoder->base.crtc);
> > + crtc_state = to_intel_crtc_state(crtc->base.state);
> > + drm_modeset_lock(>base.mutex, NULL);
> > + seq_printf(m, "Enabled: %s\n",
> > + yesno(crtc_state->dsc_params.compression_enable));
> > + seq_printf(m, "Supported: %s\n",
> > + yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
> > + drm_modeset_unlock(>base.mutex);
> > +
> > + return 0;
> > +}
> > +
> > +static ssize_t i915_dsc_support_write(struct file *file,
> > + const char __user *ubuf,
> > + size_t len, loff_t *offp)
> > +{
> > + bool dsc_enable = false;
> > + int ret;
> > + struct drm_connector *connector =
> > + ((struct seq_file *)file->private_data)->private;
> > + struct intel_encoder *encoder = intel_attached_encoder(connector);
> > + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > +
> > + if (len == 0)
> > + return 0;
> > +
> > + DRM_DEBUG_DRIVER("Copied %d bytes from user to force DSC\n",
> > +(unsigned int)len);
> > +
> > + ret = kstrtobool_from_user(ubuf, len, _enable);
> > + if (ret < 0)
> > + return ret;
> > +
> > + DRM_DEBUG_DRIVER("Got %s for DSC Enable\n",
> > +(dsc_enable) ? "true" : "false");
> > + intel_dp->force_dsc_en = dsc_enable;
> > +
> > + *offp += len;
> > + return len;
> > +}
> > +
> > +static int i915_dsc_support_open(struct inode *inode,
> > +struct file *file)
> > +{
> > + return single_open(file, i915_dsc_support_show,
> > + inode->i_private);
> > +}
> > +
> > +static const struct file_operations i915_dsc_support_fops = {
> > + .owner = THIS_MODULE,
> > + .open = i915_dsc_support_open,
> > + .read = seq_read,
> > + .llseek = seq_lseek,
> > + .release = single_release,
> > + .write = i915_dsc_support_write
> > +};
> > +
> > /**
> > * i915_debugfs_connector_add - add i915 specific connector debugfs files
> > * @connector: pointer to a registered drm_connector
> > @@ -5017,9 +5083,12 @@ int i915_debugfs_connector_add(struct drm_connector
> > *connector)
> > return -ENODEV;
> >
> > if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > - connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> > + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> > debugfs_create_file("i915_dpcd", S_IRUGO, root,
> > connector, _dpcd_fops);
> > + debugfs_create_file("i915_dsc_support", S_IRUGO, root,
> > + connector, _dsc_support_fops);
> > + }
> >
> > if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> > debugfs_create_file("i915_panel_timings", S_IRUGO, root,
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 72e6605f0ed7..0b5939992c2b 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2287,6 +2287,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> >
Re: [PATCH v6 18/28] drm/i915/dp: Enable/Disable DSC in DP Sink
On Thu, Oct 25, 2018 at 05:03:06PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:30PM -0700, Manasi Navare wrote:
> > From: Gaurav K Singh
> >
> > This patch enables decompression support in sink device
> > before link training and disables the same during the
> > DDI disabling.
> >
> > v2:(From Manasi)
> > * Change the enable/disable function to take crtc_state
> > instead of intel_dp as an argument (Manasi)
> > * Use the compression_enable flag as part of crtc_state (Manasi)
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Gaurav K Singh
> > Signed-off-by: Gaurav K Singh
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 5 +
> > drivers/gpu/drm/i915/intel_dp.c | 15 +++
> > drivers/gpu/drm/i915/intel_drv.h | 3 +++
> > 3 files changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index e40a8c97d34b..1de0a3917d7f 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2930,6 +2930,8 @@ static void intel_ddi_pre_enable_dp(struct
> > intel_encoder *encoder,
> > intel_ddi_init_dp_buf_reg(encoder);
> > if (!is_mst)
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > + intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> > + DP_DECOMPRESSION_EN);
> > intel_dp_start_link_train(intel_dp);
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> > @@ -3272,6 +3274,9 @@ static void intel_disable_ddi_dp(struct intel_encoder
> > *encoder,
> > intel_edp_drrs_disable(intel_dp, old_crtc_state);
> > intel_psr_disable(intel_dp, old_crtc_state);
> > intel_edp_backlight_off(old_conn_state);
> > + /* Disable the decompression in DP Sink */
> > + intel_dp_sink_set_decompression_state(intel_dp, old_crtc_state,
> > + ~DP_DECOMPRESSION_EN);
>
> That looks suspicious.
>
> I can't figure out what value you're actually passing here since I
> can't find the definiiton of DP_DECOMPRESSION_EN anywhere.
This is defined in /include/drm/drm_dp_helper.h
Manasi
>
> > }
> >
> > static void intel_disable_ddi_hdmi(struct intel_encoder *encoder,
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 35162c3bc811..72e6605f0ed7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3005,6 +3005,21 @@ static bool downstream_hpd_needs_d0(struct intel_dp
> > *intel_dp)
> > intel_dp->downstream_ports[0] & DP_DS_PORT_HPD;
> > }
> >
> > +void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
> > + const struct intel_crtc_state
> > *crtc_state,
> > + int state)
> > +{
> > + int ret;
> > +
> > + if (!crtc_state->dsc_params.compression_enable)
> > + return;
> > +
> > + ret = drm_dp_dpcd_writeb(_dp->aux, DP_DSC_ENABLE, state);
> > + if (ret < 0)
> > + DRM_DEBUG_KMS("Failed to %s sink decompression state\n",
> > + state == DP_DECOMPRESSION_EN ? "enable" :
> > "disable");
> > +}
> > +
> > /* If the sink supports it, try to set the power state appropriately */
> > void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> > {
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index c4be4ba7adac..4f5d17bcd54e 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1786,6 +1786,9 @@ void intel_dp_stop_link_train(struct intel_dp
> > *intel_dp);
> > int intel_dp_retrain_link(struct intel_encoder *encoder,
> > struct drm_modeset_acquire_ctx *ctx);
> > void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> > +void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
> > + const struct intel_crtc_state
> > *crtc_state,
> > + int state);
> > void intel_dp_encoder_reset(struct drm_encoder *encoder);
> > void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
> > void intel_dp_encoder_destroy(struct drm_encoder *encoder);
> > --
> > 2.18.0
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #20 from Robert Strube --- One more thing I thought of. Would it help if I posted my dmesg log with the GTX 1060 connected as an eGPU? As I mentioned previously this card *is* working with nouveau. I haven't tested with the proprietary nvidia drivers. I'd imagine that PCI resource issues you pointed out are still there, so I'm surprised that the nvidia card is able to work. Perhaps they have some hacks in their drivers to work around issues like this? I also have a friend that has an older RX 290, should I give that a shot as well? It might take me a while to get a hold of that card. I don't doubt that this is most likely a BIOS bug, but I've noticed people on the windows side of the fence getting the XPS 9575 working with eGPUs, and presumably they have the same BIOS as me. -- 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 v6 22/28] drm/i915/dp: Populate DSC PPS SDP and send PPS infoframes
On Thu, Oct 25, 2018 at 05:09:42PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:34PM -0700, Manasi Navare wrote:
> > DSC PPS secondary data packet infoframes are filled with
> > DSC picure parameter set metadata according to the DSC standard.
> > These infoframes are sent to the sink device and used during DSC
> > decoding.
> >
> > v2:
> > * Rebase ond drm-tip
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/intel_vdsc.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> > b/drivers/gpu/drm/i915/intel_vdsc.c
> > index b0fc716bbbfd..4b4b812d68f3 100644
> > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > @@ -988,6 +988,25 @@ static void intel_configure_pps_for_dsc_encoder(struct
> > intel_encoder *encoder,
> > }
> > }
> >
> > +static void intel_dp_send_dsc_pps_sdp(struct intel_encoder *encoder,
> > + struct intel_crtc_state *crtc_state)
>
> const crtc_state
Yes wil make this a const
>
> s/send/write/ ?
Hmm in terms of VDSC, the SDP packet is the one that gets sent to the sink from
source
after we write the infoframe.
So I named it as _send_dsc_pps_sdp, but I am okay changing that to
write_dsc_pps_sdp
since all we are doing is writing an infoframe that gets sent out.
Manasi
>
> > +{
> > + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > + struct drm_dsc_config *vdsc_cfg = _state->dp_dsc_cfg;
> > + struct drm_dsc_pps_infoframe dp_dsc_pps_sdp;
> > +
> > + /* Prepare DP SDP PPS header as per DP 1.4 spec, Table 2-123 */
> > + drm_dsc_dp_pps_header_init(_dsc_pps_sdp);
> > +
> > + /* Fill the PPS payload bytes as per DSC spec 1.2 Table 4-1 */
> > + drm_dsc_pps_infoframe_pack(_dsc_pps_sdp, vdsc_cfg);
> > +
> > + intel_dig_port->write_infoframe(encoder, crtc_state,
> > + DP_SDP_PPS, _dsc_pps_sdp,
> > + sizeof(dp_dsc_pps_sdp));
> > +}
> > +
> > void intel_dsc_enable(struct intel_encoder *encoder,
> > struct intel_crtc_state *crtc_state)
> > {
> > @@ -997,5 +1016,7 @@ void intel_dsc_enable(struct intel_encoder *encoder,
> >
> > intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
> >
> > + intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
> > +
> > return;
> > }
> > --
> > 2.18.0
>
> --
> Ville Syrjälä
> Intel
> ___
> 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 v6 24/28] drm/i915/dp: Configure Display stream splitter registers during DSC enable
On Thu, Oct 25, 2018 at 05:15:34PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:36PM -0700, Manasi Navare wrote:
> > Display Stream Splitter registers need to be programmed to enable
> > the joiner if two DSC engines are used and also to enable
> > the left and the right DSC engines. This happens as part of
> > the DSC enabling routine in the source in atomic commit.
> >
> > v3:
> > * Use cpu_transcoder instead of encoder->type (Ville)
> > v2:
> > * Rebase (Manasi)
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/intel_vdsc.c | 22 ++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> > b/drivers/gpu/drm/i915/intel_vdsc.c
> > index 4b4b812d68f3..8b46619aae15 100644
> > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > @@ -1010,6 +1010,12 @@ static void intel_dp_send_dsc_pps_sdp(struct
> > intel_encoder *encoder,
> > void intel_dsc_enable(struct intel_encoder *encoder,
> > struct intel_crtc_state *crtc_state)
> > {
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > + enum pipe pipe = crtc->pipe;
> > + i915_reg_t dss_ctl1_reg, dss_ctl2_reg;
> > + u32 dss_ctl1_val = 0;
> > + u32 dss_ctl2_val = 0;
> >
> > if (!crtc_state->dsc_params.compression_enable)
> > return;
> > @@ -1018,5 +1024,21 @@ void intel_dsc_enable(struct intel_encoder *encoder,
> >
> > intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
> >
> > + /* Configure DSS_CTL registers for DSC */
>
> This comment seems redundant.
Yes, might have added this during the early development cycles. Will remove it
now
that it follows the functions that actually do it.
Thanks for pointing it out.
>
> > + if (crtc_state->cpu_transcoder == TRANSCODER_EDP) {
> > + dss_ctl1_reg = DSS_CTL1;
> > + dss_ctl2_reg = DSS_CTL2;
> > + } else {
> > + dss_ctl1_reg = ICL_PIPE_DSS_CTL1(pipe);
> > + dss_ctl2_reg = ICL_PIPE_DSS_CTL2(pipe);
>
> Shouldn't these be cpu_transcoder too? Yeah, it's the same thing
> essentially, but I think it's better to use the thing that
> actually matches the hardware.
But if you look at the spec def of PIPE_DSS_CTL1 and 2, it actually
has a set of registers for Pipe B and different for Pipe C.
So in case of external DP VDSC engines are tied to per pipe
on ICL as well.
Only for eDP, it is tied to transcoder EDP and hence I look at the
transcoder eDP and use DSS_CTL1 or 2 else use PIPE_DSS_CTL1/2.
>
> I wonder if it would even make sense to do the trans==EDP check
> in the macro as well. Would avoid cluttering the code with
> details like this. The macro wouldn't be the prettiest thing
> ever, but that more or less holds for all reg macros.
>
So add a macro something like this:
#define IS_TRANSCODER_EDP(crtc-state) crtc_state->cpu_transcoder ==
TRANSCODER_EDP;
Is this what you are suggesting?
MAnasi
> > + }
> > + dss_ctl2_val |= LEFT_BRANCH_VDSC_ENABLE;
> > + if (crtc_state->dsc_params.dsc_split) {
> > + dss_ctl2_val |= RIGHT_BRANCH_VDSC_ENABLE;
> > + dss_ctl1_val |= JOINER_ENABLE;
> > + }
> > + I915_WRITE(dss_ctl1_reg, dss_ctl1_val);
> > + I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
> > +
> > return;
> > }
> > --
> > 2.18.0
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 25/28] drm/i915/dp: Disable DSC in source by disabling DSS CTL bits
On Thu, Oct 25, 2018 at 05:16:58PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:37PM -0700, Manasi Navare wrote:
> > 1. Disable Left/right VDSC branch in DSS Ctrl reg
> > depending on the number of VDSC engines being used
> > 2. Disable joiner in DSS Ctrl reg
> >
> > v3 (From Manasi):
> > * Add Disable PG2 for VDSC on eDP
> > v2 (From Manasi):
> > * Use old_crtc_state to find dsc params
> > * Add a condition to disable only if
> > dsc state compression is enabled
> > * Use correct DSS CTL regs
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Signed-off-by: Manasi Navare
> > Signed-off-by: Gaurav K Singh
> > Reviewed-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > drivers/gpu/drm/i915/intel_display.c | 13 +++
> > drivers/gpu/drm/i915/intel_vdsc.c| 33
> > 3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 16e6bb98eb1b..e31f19a688bc 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3489,6 +3489,8 @@ extern bool intel_set_memory_cxsr(struct
> > drm_i915_private *dev_priv,
> > bool enable);
> > extern void intel_dsc_enable(struct intel_encoder *encoder,
> > struct intel_crtc_state *crtc_state);
> > +extern void intel_dsc_disable(struct intel_encoder *encoder,
> > + struct intel_crtc_state *crtc_state);
> >
> > int i915_reg_read_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 023a9baef101..3d9d70d3314e 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5853,6 +5853,9 @@ static void haswell_crtc_disable(struct
> > intel_crtc_state *old_crtc_state,
> > struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
> > + struct drm_connector_state *conn_state;
> > + struct drm_connector *conn;
> > + int i;
> >
> > intel_encoders_disable(crtc, old_crtc_state, old_state);
> >
> > @@ -5869,6 +5872,16 @@ static void haswell_crtc_disable(struct
> > intel_crtc_state *old_crtc_state,
> > if (!transcoder_is_dsi(cpu_transcoder))
> > intel_ddi_disable_transcoder_func(old_crtc_state);
> >
> > + for_each_new_connector_in_state(old_state, conn, conn_state, i) {
> > + struct intel_encoder *encoder =
> > + to_intel_encoder(conn_state->best_encoder);
> > +
> > + if (conn_state->crtc != crtc)
> > + continue;
> > +
> > + intel_dsc_disable(encoder, old_crtc_state);
> > + }
>
> Can't we do this from the encodr hooks? /me didn't check the modeset
> sequence docs...
Hmm yes it could be made part of intel_encoders_post_disable(). The spec is not
clear in terms of where in the sequence shd this be disabled.
Do you think intel_encoders_post_disable() is the right place?
Manasi
>
> > +
> > if (INTEL_GEN(dev_priv) >= 9)
> > skylake_scaler_disable(intel_crtc);
> > else
> > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> > b/drivers/gpu/drm/i915/intel_vdsc.c
> > index 8b46619aae15..5e76b4a44d90 100644
> > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > @@ -1042,3 +1042,36 @@ void intel_dsc_enable(struct intel_encoder *encoder,
> >
> > return;
> > }
> > +
> > +void intel_dsc_disable(struct intel_encoder *encoder,
> > + struct intel_crtc_state *old_crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > + enum pipe pipe = crtc->pipe;
> > + i915_reg_t dss_ctl1_reg, dss_ctl2_reg;
> > + u32 dss_ctl1_val = 0, dss_ctl2_val = 0;
> > +
> > + if (!old_crtc_state->dsc_params.compression_enable)
> > + return;
> > +
> > + if (encoder->type == INTEL_OUTPUT_EDP) {
> > + dss_ctl1_reg = DSS_CTL1;
> > + dss_ctl2_reg = DSS_CTL2;
> > + } else {
> > + dss_ctl1_reg = ICL_PIPE_DSS_CTL1(pipe);
> > + dss_ctl2_reg = ICL_PIPE_DSS_CTL2(pipe);
> > + }
> > + dss_ctl1_val = I915_READ(dss_ctl1_reg);
> > + if (dss_ctl1_val & JOINER_ENABLE)
> > + dss_ctl1_val &= ~JOINER_ENABLE;
> > + I915_WRITE(dss_ctl1_reg, dss_ctl1_val);
> > +
> > + dss_ctl2_val = I915_READ(dss_ctl2_reg);
> > + if (dss_ctl2_val & LEFT_BRANCH_VDSC_ENABLE ||
> > + dss_ctl2_val & RIGHT_BRANCH_VDSC_ENABLE)
> > + dss_ctl2_val &= ~(LEFT_BRANCH_VDSC_ENABLE |
> > + RIGHT_BRANCH_VDSC_ENABLE);
> > +
Re: [PATCH 6/6] dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
On Mon, 22 Oct 2018 13:46:39 -0700, Douglas Anderson wrote:
> As far as I can tell the bindings that were added in commit
> 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> bindings") weren't actually for Innolux TV123WAM but were actually for
> Innolux P120ZDG-BF1.
>
> As far as I can tell the Innolux TV123WAM isn't a real panel and but
> it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> Let's unmosh.
>
> Here's my evidence:
>
> * Searching for TV123WAM on the Internet turns up a TI panel. While
> it's possible that an Innolux panel has the same model number as the
> TI Panel, it seems a little doubtful. Looking up the datasheet from
> the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
>
> * As far as I know, the patch adding the Innolux Panel was supposed to
> be for the board that's sitting in front of me as I type this
> (support for that board is not yet upstream). On the back of that
> panel I see Innolux P120ZDZ-EZ1 rev B1.
>
> * Someone pointed me at a datasheet that's supposed to be for the
> panel in front of me (sorry, I can't share the datasheet). That
> datasheet has the string "p120zdg-bf1"
>
> * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> that are 2160x1440. They don't have datasheets, but the fact that
> the resolution matches is a good sign.
>
> While we doing the rename, also mention that no-hpd can be used with
> this panel. See the previous patch in this series ("drm/panel:
> simple: Add "no-hpd" delay for Innolux TV123WAM").
>
> Fixes: 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> bindings")
> Signed-off-by: Douglas Anderson
> Cc: Sandeep Panda
> ---
>
> .../{innolux,tv123wam.txt => innolux,p120zdg-bf1.txt} | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
> rename Documentation/devicetree/bindings/display/panel/{innolux,tv123wam.txt
> => innolux,p120zdg-bf1.txt} (70%)
>
Reviewed-by: Rob Herring
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 26/28] drm/i915/dsc: Enable and disable appropriate power wells for VDSC
On Thu, Oct 25, 2018 at 05:22:18PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:38PM -0700, Manasi Navare wrote:
> > A separate power well 2 (PG2) is required for VDSC on eDP transcoder
> > whereas all other transcoders use the power wells associated with the
> > transcoders for VDSC.
> > This patch adds a helper to obtain correct power domain depending on
> > transcoder being used and enables/disables the power wells during
> > VDSC enabling/disabling.
> >
> > v2:
> > * Fix tabs, const crtc_state, fix comments (Ville)
> >
> > Suggested-by: Ville Syrjala
> > Cc: Ville Syrjala
> > Cc: Imre Deak
> > Cc: Rodrigo Vivi
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_vdsc.c | 26 ++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> > b/drivers/gpu/drm/i915/intel_vdsc.c
> > index 5e76b4a44d90..0fed36e2491a 100644
> > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > @@ -581,6 +581,24 @@ int intel_dp_compute_dsc_params(struct intel_dp
> > *intel_dp,
> > return 0;
> > }
> >
> > +static enum intel_display_power_domain
> > +intel_dsc_get_power_domains(const struct intel_crtc_state *crtc_state)
>
> intel_dsc_power_domain() or something like that to match
> the naming convention introduced by intel_ddi_main_link_aux_domain()?
Ok i can rename to use intel_dsc_power_domain() but it should still live
in intel_vdsc.c right?
>
> Oh, and we'll need to update intel_ddi_get_power_domains() as well.
We would need to add this power domain here so that its obtained during
the intel_modeset_setup_hw_state()..?
Manasi
>
> > +{
> > + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > +
> > + /*
> > +* On ICL VDSC/joining for eDP transcoder uses a separate power well PW2
> > +* This requires POWER_DOMAIN_TRANSCODER_EDP_VDSC power domain.
> > +* For any other transcoder, VDSC/joining uses the power well associated
> > +* with the pipe/transcoder in use. Hence another reference on the
> > +* transcoder power domain will suffice.
> > +*/
> > + if (cpu_transcoder == TRANSCODER_EDP)
> > + return POWER_DOMAIN_TRANSCODER_EDP_VDSC;
> > + else
> > + return POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> > +}
> > +
> > static void intel_configure_pps_for_dsc_encoder(struct intel_encoder
> > *encoder,
> > struct intel_crtc_state
> > *crtc_state)
> > {
> > @@ -1020,6 +1038,10 @@ void intel_dsc_enable(struct intel_encoder *encoder,
> > if (!crtc_state->dsc_params.compression_enable)
> > return;
> >
> > + /* Enable Power wells for VDSC/joining */
> > + intel_display_power_get(dev_priv,
> > + intel_dsc_get_power_domains(crtc_state));
> > +
> > intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
> >
> > intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
> > @@ -1074,4 +1096,8 @@ void intel_dsc_disable(struct intel_encoder *encoder,
> > RIGHT_BRANCH_VDSC_ENABLE);
> > I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
> >
> > + /* Disable Power wells for VDSC/joining */
> > + intel_display_power_put(dev_priv,
> > + intel_dsc_get_power_domains(old_crtc_state));
> > +
>
> Bogus newline here.
>
> > }
> > --
> > 2.18.0
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108542] hdmi issues with kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=108542 --- Comment #4 from Nicholas Kazlauskas --- (In reply to davide26079 from comment #3) > (In reply to Nicholas Kazlauskas from comment #1) > > Thanks for the bisection. > > > > Would you mind posting a full dmesg log for your 4.18.8 kernel? > > done. Dunno if that's what you asked for, I am just a newbie... > > I did start bisecting the second issue as well, but my free time is limited. > I think I'll finish this weekend though. > > May I hope to get things fixed in a few weeks? The log you posted should be sufficient. I'm not sure about a timeline for a fix, however. -- 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 1/6] dt-bindings: drm/panel: simple: Add no-hpd property
On Mon, Oct 22, 2018 at 01:46:34PM -0700, Douglas Anderson wrote: > Some eDP panels that are designed to be always connected to a board > use their HPD signal to signal that they've finished powering on and > they're ready to be talked to. > > However, for various reasons it's possible that the HPD signal from > the panel isn't actually hooked up. In the case where the HPD isn't > hooked up you can look at the timing diagram on the panel datasheet > and insert a delay for the maximum amount of time that the HPD might > take to come up. > > Let's add a property in the device tree for this concept. > > Signed-off-by: Douglas Anderson > --- > > .../devicetree/bindings/display/panel/simple-panel.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt > b/Documentation/devicetree/bindings/display/panel/simple-panel.txt > index 45a457ad38f0..b2b872c710f2 100644 > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt > @@ -11,6 +11,9 @@ Optional properties: > - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > - enable-gpios: GPIO pin to enable or disable the panel > - backlight: phandle of the backlight device attached to the panel > +- no-hpd: This panel is supposed to communicate that it's ready via HPD > + (hot plug detect) signal, but the signal isn't hooked up so we should > + hardcode the max delay from the panel spec when powering up the panel. If we have this here, then we should also have hpd-gpios defined here as where we describe a connection we should also describe no connection. Now, hpd-gpios is a bit of a mess being defined in both connector nodes and bridge (HDMI/DP) nodes. I think that is just history pre-dating connector nodes. Connector nodes are now the preferred place. Connector nodes and panel nodes are essentially the same thing (the endpoint of display pipeline). That being said, this patch is fine as is. Reviewed-by: Rob Herring Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108542] hdmi issues with kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=108542 --- Comment #3 from davide26...@gmail.com --- (In reply to Nicholas Kazlauskas from comment #1) > Thanks for the bisection. > > Would you mind posting a full dmesg log for your 4.18.8 kernel? done. Dunno if that's what you asked for, I am just a newbie... I did start bisecting the second issue as well, but my free time is limited. I think I'll finish this weekend though. May I hope to get things fixed in a few weeks? -- 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 108542] hdmi issues with kernel 4.18
https://bugs.freedesktop.org/show_bug.cgi?id=108542 --- Comment #2 from davide26...@gmail.com --- Created attachment 142207 --> https://bugs.freedesktop.org/attachment.cgi?id=142207=edit dmesg -- 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 5/6] drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
On 2018-10-25 11:45, Doug Anderson wrote:
Hi,
On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> As far as I can tell the panel that was added in commit da50bd4258db
> ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> wasn't actually an Innolux TV123WAM but was actually an Innolux
> P120ZDG-BF1.
>
> As far as I can tell the Innolux TV123WAM isn't a real panel and but
> it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> Let's unmosh.
>
> Here's my evidence:
>
> * Searching for TV123WAM on the Internet turns up a TI panel. While
> it's possible that an Innolux panel has the same model number as the
> TI Panel, it seems a little doubtful. Looking up the datasheet from
> the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
>
> * As far as I know, the patch adding the Innolux Panel was supposed to
> be for the board that's sitting in front of me as I type this
> (support for that board is not yet upstream). On the back of that
> panel I see Innolux P120ZDZ-EZ1 rev B1.
>
> * Someone pointed me at a datasheet that's supposed to be for the
> panel in front of me (sorry, I can't share the datasheet). That
> datasheet has the string "p120zdg-bf1"
>
> * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> that are 2160x1440. They don't have datasheets, but the fact that
> the resolution matches is a good sign.
>
> In any case, let's update the name and also the physical size to match
> the correct panel.
>
> Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver
support")
> Signed-off-by: Douglas Anderson
> Cc: Sandeep Panda
> ---
If Rob is onboard with this binding change, please feel free to add
Reviewed-by: Abhinav Kumar
>
> drivers/gpu/drm/panel/panel-simple.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
> index 937e97490c30..7ee1abc5d81b 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1370,7 +1370,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
> },
> };
>
> -static const struct drm_display_mode innolux_tv123wam_mode = {
> +static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
> .clock = 206016,
> .hdisplay = 2160,
> .hsync_start = 2160 + 48,
> @@ -1384,13 +1384,13 @@ static const struct drm_display_mode
innolux_tv123wam_mode = {
> .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> };
>
> -static const struct panel_desc innolux_tv123wam = {
> - .modes = _tv123wam_mode,
> +static const struct panel_desc innolux_p120zdg_bf1 = {
> + .modes = _p120zdg_bf1_mode,
> .num_modes = 1,
> .bpc = 8,
> .size = {
> - .width = 259,
> - .height = 173,
> + .width = 254,
> + .height = 169,
> },
> .delay = {
> .prepare = 200,
> @@ -2454,8 +2454,8 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "innolux,n156bge-l21",
> .data = _n156bge_l21,
> }, {
> - .compatible = "innolux,tv123wam",
I think we should update the struct, but we might want to keep this
around.
Given the tv123wam panel is TI, we're likely not going to have a
collision on
innolux,...
That said, I'll defer to robh on this one, I'm not sure if changing
names is
cool once the bindings have hit mainline.
Whoops, I missed Rob on this patch--just had him on the bindings one.
...generally I believe Rob seems to be OK with wiping out backward
compatibility for things like this when the previous binding is super
new and there's no evidence that anyone ever used it (like if it was
added for a specific board and that board doesn't have a fully
functional DT anyway).
In this particular case I'm 99.% certain nobody is using the
existing binding. If someone crawls out of the woodwork and says this
patch broke them, it would be trivially easy to add the backward
compatible string later.
Obviously Rob can feel free to correct me if I'm wrong.
I purposely put this patch at the end of the series so we can land the
earlier ones and we can sit on this one for a little while if desired.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
Hi,
On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
>
> On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> > As far as I can tell the panel that was added in commit da50bd4258db
> > ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> > wasn't actually an Innolux TV123WAM but was actually an Innolux
> > P120ZDG-BF1.
> >
> > As far as I can tell the Innolux TV123WAM isn't a real panel and but
> > it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> > Let's unmosh.
> >
> > Here's my evidence:
> >
> > * Searching for TV123WAM on the Internet turns up a TI panel. While
> > it's possible that an Innolux panel has the same model number as the
> > TI Panel, it seems a little doubtful. Looking up the datasheet from
> > the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
> >
> > * As far as I know, the patch adding the Innolux Panel was supposed to
> > be for the board that's sitting in front of me as I type this
> > (support for that board is not yet upstream). On the back of that
> > panel I see Innolux P120ZDZ-EZ1 rev B1.
> >
> > * Someone pointed me at a datasheet that's supposed to be for the
> > panel in front of me (sorry, I can't share the datasheet). That
> > datasheet has the string "p120zdg-bf1"
> >
> > * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> > that are 2160x1440. They don't have datasheets, but the fact that
> > the resolution matches is a good sign.
> >
> > In any case, let's update the name and also the physical size to match
> > the correct panel.
> >
> > Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver
> > support")
> > Signed-off-by: Douglas Anderson
> > Cc: Sandeep Panda
> > ---
> >
> > drivers/gpu/drm/panel/panel-simple.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 937e97490c30..7ee1abc5d81b 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1370,7 +1370,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
> > },
> > };
> >
> > -static const struct drm_display_mode innolux_tv123wam_mode = {
> > +static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
> > .clock = 206016,
> > .hdisplay = 2160,
> > .hsync_start = 2160 + 48,
> > @@ -1384,13 +1384,13 @@ static const struct drm_display_mode
> > innolux_tv123wam_mode = {
> > .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> > };
> >
> > -static const struct panel_desc innolux_tv123wam = {
> > - .modes = _tv123wam_mode,
> > +static const struct panel_desc innolux_p120zdg_bf1 = {
> > + .modes = _p120zdg_bf1_mode,
> > .num_modes = 1,
> > .bpc = 8,
> > .size = {
> > - .width = 259,
> > - .height = 173,
> > + .width = 254,
> > + .height = 169,
> > },
> > .delay = {
> > .prepare = 200,
> > @@ -2454,8 +2454,8 @@ static const struct of_device_id platform_of_match[]
> > = {
> > .compatible = "innolux,n156bge-l21",
> > .data = _n156bge_l21,
> > }, {
> > - .compatible = "innolux,tv123wam",
>
> I think we should update the struct, but we might want to keep this around.
> Given the tv123wam panel is TI, we're likely not going to have a collision on
> innolux,...
>
> That said, I'll defer to robh on this one, I'm not sure if changing names is
> cool once the bindings have hit mainline.
Whoops, I missed Rob on this patch--just had him on the bindings one.
...generally I believe Rob seems to be OK with wiping out backward
compatibility for things like this when the previous binding is super
new and there's no evidence that anyone ever used it (like if it was
added for a specific board and that board doesn't have a fully
functional DT anyway).
In this particular case I'm 99.% certain nobody is using the
existing binding. If someone crawls out of the woodwork and says this
patch broke them, it would be trivially easy to add the backward
compatible string later.
Obviously Rob can feel free to correct me if I'm wrong.
I purposely put this patch at the end of the series so we can land the
earlier ones and we can sit on this one for a little while if desired.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/virtio: add in-fences support for explicit synchronization
From: Gustavo Padovan
When the execbuf call receives an in-fence it will get the dma_fence
related to that fence fd and wait on it before submitting the draw call.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
Suggested-by: Rob Herring
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 43 --
1 file changed, 34 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 1af289b28fc4..0368195966aa 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "virtgpu_drv.h"
@@ -114,6 +115,8 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
struct ttm_validate_buffer *buflist = NULL;
int i;
struct ww_acquire_ctx ticket;
+ struct dma_fence *in_fence = NULL;
+ int in_fence_fd = exbuf->fence_fd;
void *buf;
exbuf->fence_fd = -1;
@@ -124,6 +127,22 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
if ((exbuf->flags & ~VIRTGPU_EXECBUF_FLAGS))
return -EINVAL;
+ if (exbuf->flags & VIRTGPU_EXECBUF_FENCE_FD_IN) {
+ in_fence = sync_file_get_fence(in_fence_fd);
+ if (!in_fence)
+ return -EINVAL;
+
+ /*
+* Wait if the fence is from a foreign context, or if the fence
+* array contains any fence from a foreign context.
+*/
+ if (!dma_fence_match_context(in_fence,
vgdev->fence_drv.context)) {
+ ret = dma_fence_wait(in_fence, true);
+ if (ret)
+ return ret;
+ }
+ }
+
INIT_LIST_HEAD(_list);
if (exbuf->num_bo_handles) {
@@ -133,26 +152,22 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
sizeof(struct ttm_validate_buffer),
GFP_KERNEL | __GFP_ZERO);
if (!bo_handles || !buflist) {
- kvfree(bo_handles);
- kvfree(buflist);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out_in_fence;
}
user_bo_handles = (void __user *)(uintptr_t)exbuf->bo_handles;
if (copy_from_user(bo_handles, user_bo_handles,
exbuf->num_bo_handles * sizeof(uint32_t))) {
ret = -EFAULT;
- kvfree(bo_handles);
- kvfree(buflist);
- return ret;
+ goto out_in_fence;
}
for (i = 0; i < exbuf->num_bo_handles; i++) {
gobj = drm_gem_object_lookup(drm_file, bo_handles[i]);
if (!gobj) {
- kvfree(bo_handles);
- kvfree(buflist);
- return -ENOENT;
+ ret = -ENOENT;
+ goto out_in_fence;
}
qobj = gem_to_virtio_gpu_obj(gobj);
@@ -161,6 +176,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
list_add([i].head, _list);
}
kvfree(bo_handles);
+ bo_handles = NULL;
}
ret = virtio_gpu_object_list_validate(, _list);
@@ -180,6 +196,12 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
ret = -ENOMEM;
goto out_unresv;
}
+
+ if (in_fence) {
+ dma_fence_put(in_fence);
+ in_fence = NULL;
+ }
+
virtio_gpu_cmd_submit(vgdev, buf, exbuf->size,
vfpriv->ctx_id, fence);
@@ -195,7 +217,10 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
ttm_eu_backoff_reservation(, _list);
out_free:
virtio_gpu_unref_list(_list);
+out_in_fence:
+ kvfree(bo_handles);
kvfree(buflist);
+ dma_fence_put(in_fence);
return ret;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/virtio: add virtio_gpu_alloc_fence()
From: Gustavo Padovan
Refactor fence creation to remove the potential allocation failure from
the cmd_submit and atomic_commit paths. Now the fence should be allocated
first and just after we should proceed with the rest of the execution.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
Suggested-by: Rob Herring
---
Changes since v2:
- Forward ported to upstream/master (4.20)
drivers/gpu/drm/virtio/virtgpu_drv.h | 18 ++
drivers/gpu/drm/virtio/virtgpu_fence.c | 41 ---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 38 +
drivers/gpu/drm/virtio/virtgpu_plane.c | 46 +++---
drivers/gpu/drm/virtio/virtgpu_vq.c| 16 -
5 files changed, 121 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 65605e207bbe..e8d2a67d8049 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -127,6 +127,7 @@ struct virtio_gpu_framebuffer {
int x1, y1, x2, y2; /* dirty rect */
spinlock_t dirty_lock;
uint32_t hw_res_handle;
+ struct virtio_gpu_fence *fence;
};
#define to_virtio_gpu_framebuffer(x) \
container_of(x, struct virtio_gpu_framebuffer, base)
@@ -263,7 +264,7 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct
virtio_gpu_device *vgdev,
uint32_t resource_id, uint64_t offset,
__le32 width, __le32 height,
__le32 x, __le32 y,
- struct virtio_gpu_fence **fence);
+ struct virtio_gpu_fence *fence);
void virtio_gpu_cmd_resource_flush(struct virtio_gpu_device *vgdev,
uint32_t resource_id,
uint32_t x, uint32_t y,
@@ -275,7 +276,7 @@ void virtio_gpu_cmd_set_scanout(struct virtio_gpu_device
*vgdev,
int virtio_gpu_object_attach(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object *obj,
uint32_t resource_id,
-struct virtio_gpu_fence **fence);
+struct virtio_gpu_fence *fence);
int virtio_gpu_attach_status_page(struct virtio_gpu_device *vgdev);
int virtio_gpu_detach_status_page(struct virtio_gpu_device *vgdev);
void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev,
@@ -299,21 +300,21 @@ void virtio_gpu_cmd_context_detach_resource(struct
virtio_gpu_device *vgdev,
uint32_t resource_id);
void virtio_gpu_cmd_submit(struct virtio_gpu_device *vgdev,
void *data, uint32_t data_size,
- uint32_t ctx_id, struct virtio_gpu_fence **fence);
+ uint32_t ctx_id, struct virtio_gpu_fence *fence);
void virtio_gpu_cmd_transfer_from_host_3d(struct virtio_gpu_device *vgdev,
uint32_t resource_id, uint32_t ctx_id,
uint64_t offset, uint32_t level,
struct virtio_gpu_box *box,
- struct virtio_gpu_fence **fence);
+ struct virtio_gpu_fence *fence);
void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev,
uint32_t resource_id, uint32_t ctx_id,
uint64_t offset, uint32_t level,
struct virtio_gpu_box *box,
- struct virtio_gpu_fence **fence);
+ struct virtio_gpu_fence *fence);
void
virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device *vgdev,
struct virtio_gpu_resource_create_3d *rc_3d,
- struct virtio_gpu_fence **fence);
+ struct virtio_gpu_fence *fence);
void virtio_gpu_ctrl_ack(struct virtqueue *vq);
void virtio_gpu_cursor_ack(struct virtqueue *vq);
void virtio_gpu_fence_ack(struct virtqueue *vq);
@@ -341,9 +342,12 @@ void virtio_gpu_ttm_fini(struct virtio_gpu_device *vgdev);
int virtio_gpu_mmap(struct file *filp, struct vm_area_struct *vma);
/* virtio_gpu_fence.c */
+struct virtio_gpu_fence *virtio_gpu_fence_alloc(
+ struct virtio_gpu_device *vgdev);
+void virtio_gpu_fence_cleanup(struct virtio_gpu_fence *fence);
int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
struct virtio_gpu_ctrl_hdr *cmd_hdr,
- struct virtio_gpu_fence **fence);
+ struct virtio_gpu_fence *fence);
void virtio_gpu_fence_event_process(struct virtio_gpu_device *vdev,
u64 last_seq);
diff --git
[PATCH 5/5] drm/virtio: bump driver version after explicit synchronization addition
From: Gustavo Padovan To reflect the (backward compatible) changes in the uabi we are bumping the driver's version. Signed-off-by: Gustavo Padovan Signed-off-by: Robert Foss --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index e8d2a67d8049..a26483b5016e 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -46,8 +46,8 @@ #define DRIVER_DATE "0" #define DRIVER_MAJOR 0 -#define DRIVER_MINOR 0 -#define DRIVER_PATCHLEVEL 1 +#define DRIVER_MINOR 1 +#define DRIVER_PATCHLEVEL 0 /* virtgpu_drm_bus.c */ int drm_virtio_init(struct drm_driver *driver, struct virtio_device *vdev); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/virtio: add out-fences support for explicit synchronization
From: Gustavo Padovan
On the out-fence side we get fence returned by the submitted draw call
and attach it to a sync_file and send the sync_file fd to userspace. On
error -1 is returned to userspace.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
Suggested-by: Rob Herring
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 50 +++---
1 file changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 0368195966aa..32e714a1c753 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -106,7 +106,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv = drm_file->driver_priv;
struct drm_gem_object *gobj;
- struct virtio_gpu_fence *fence;
+ struct virtio_gpu_fence *out_fence;
struct virtio_gpu_object *qobj;
int ret;
uint32_t *bo_handles = NULL;
@@ -116,7 +116,9 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
int i;
struct ww_acquire_ctx ticket;
struct dma_fence *in_fence = NULL;
+ struct sync_file *sync_file;
int in_fence_fd = exbuf->fence_fd;
+ int out_fence_fd = -1;
void *buf;
exbuf->fence_fd = -1;
@@ -143,6 +145,14 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
}
}
+ if (exbuf->flags & VIRTGPU_EXECBUF_FENCE_FD_OUT) {
+ out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
+ if (out_fence_fd < 0) {
+ ret = out_fence_fd;
+ goto out_in_fence;
+ }
+ }
+
INIT_LIST_HEAD(_list);
if (exbuf->num_bo_handles) {
@@ -153,21 +163,21 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
GFP_KERNEL | __GFP_ZERO);
if (!bo_handles || !buflist) {
ret = -ENOMEM;
- goto out_in_fence;
+ goto out_unused_fd;
}
user_bo_handles = (void __user *)(uintptr_t)exbuf->bo_handles;
if (copy_from_user(bo_handles, user_bo_handles,
exbuf->num_bo_handles * sizeof(uint32_t))) {
ret = -EFAULT;
- goto out_in_fence;
+ goto out_unused_fd;
}
for (i = 0; i < exbuf->num_bo_handles; i++) {
gobj = drm_gem_object_lookup(drm_file, bo_handles[i]);
if (!gobj) {
ret = -ENOENT;
- goto out_in_fence;
+ goto out_unused_fd;
}
qobj = gem_to_virtio_gpu_obj(gobj);
@@ -190,11 +200,22 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
goto out_unresv;
}
- fence = virtio_gpu_fence_alloc(vgdev);
- if (!fence) {
- kfree(buf);
+ out_fence = virtio_gpu_fence_alloc(vgdev);
+ if(!out_fence) {
ret = -ENOMEM;
- goto out_unresv;
+ goto out_memdup;
+ }
+
+ if (out_fence_fd >= 0) {
+ sync_file = sync_file_create(_fence->f);
+ if (!sync_file) {
+ dma_fence_put(_fence->f);
+ ret = -ENOMEM;
+ goto out_memdup;
+ }
+
+ exbuf->fence_fd = out_fence_fd;
+ fd_install(out_fence_fd, sync_file->file);
}
if (in_fence) {
@@ -203,23 +224,28 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
}
virtio_gpu_cmd_submit(vgdev, buf, exbuf->size,
- vfpriv->ctx_id, fence);
+ vfpriv->ctx_id, out_fence);
- ttm_eu_fence_buffer_objects(, _list, >f);
+ ttm_eu_fence_buffer_objects(, _list, _fence->f);
/* fence the command bo */
virtio_gpu_unref_list(_list);
kvfree(buflist);
- dma_fence_put(>f);
return 0;
+out_memdup:
+ kfree(buf);
out_unresv:
ttm_eu_backoff_reservation(, _list);
out_free:
virtio_gpu_unref_list(_list);
-out_in_fence:
+out_unused_fd:
kvfree(bo_handles);
kvfree(buflist);
+
+ if (out_fence_fd >= 0)
+ put_unused_fd(out_fence_fd);
+out_in_fence:
dma_fence_put(in_fence);
return ret;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] virgl: fence fd support
This series implements fence support for drm/virtio and has been tested using qemu, kmscube and the below branches. Rob Herring solved a reference counting issue and suggested a context check for the execbuf ioctl, his changes have been included in the below commits to keep the tree working at all commits. The linux series can be found here: https://gitlab.collabora.com/robertfoss/linux/commits/virtio_fences_v3 As for mesa, the branch can be found here: https://gitlab.collabora.com/robertfoss/mesa/commits/virtio_fences_v3 Changes since v2: - drm/virtio: add virtio_gpu_alloc_fence() - Forward port and fix compilation issues - drm/virtio: add uapi for in and out explicit fences - Check exbuf->flags for unsupported flags Gustavo Padovan (4): drm/virtio: add virtio_gpu_alloc_fence() drm/virtio: add in-fences support for explicit synchronization drm/virtio: add out-fences support for explicit synchronization drm/virtio: bump driver version after explicit synchronization addition Robert Foss (1): drm/virtio: add uapi for in and out explicit fences drivers/gpu/drm/virtio/virtgpu_drv.h | 22 +++-- drivers/gpu/drm/virtio/virtgpu_fence.c | 41 ++--- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 118 + drivers/gpu/drm/virtio/virtgpu_plane.c | 46 -- drivers/gpu/drm/virtio/virtgpu_vq.c| 16 ++-- include/uapi/drm/virtgpu_drm.h | 13 ++- 6 files changed, 201 insertions(+), 55 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/virtio: add uapi for in and out explicit fences
Add a new field called fence_fd that will be used by userspace to send
in-fences to the kernel and receive out-fences created by the kernel.
This uapi enables virtio to take advantage of explicit synchronization of
dma-bufs.
There are two new flags:
* VIRTGPU_EXECBUF_FENCE_FD_IN to be used when passing an in-fence fd.
* VIRTGPU_EXECBUF_FENCE_FD_OUT to be used when requesting an out-fence fd
The execbuffer IOCTL is now read-write to allow the userspace to read the
out-fence.
On error -1 should be returned in the fence_fd field.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
Changes since v2:
- Since exbuf-flags is a new flag, check that unsupported
flags aren't set.
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +
include/uapi/drm/virtgpu_drm.h | 13 ++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index d01a9ed100d1..1af289b28fc4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -116,9 +116,14 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
struct ww_acquire_ctx ticket;
void *buf;
+ exbuf->fence_fd = -1;
+
if (vgdev->has_virgl_3d == false)
return -ENOSYS;
+ if ((exbuf->flags & ~VIRTGPU_EXECBUF_FLAGS))
+ return -EINVAL;
+
INIT_LIST_HEAD(_list);
if (exbuf->num_bo_handles) {
diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h
index 9a781f0611df..91062f4ac7c5 100644
--- a/include/uapi/drm/virtgpu_drm.h
+++ b/include/uapi/drm/virtgpu_drm.h
@@ -47,6 +47,13 @@ extern "C" {
#define DRM_VIRTGPU_WAIT 0x08
#define DRM_VIRTGPU_GET_CAPS 0x09
+#define VIRTGPU_EXECBUF_FENCE_FD_IN0x01
+#define VIRTGPU_EXECBUF_FENCE_FD_OUT 0x02
+#define VIRTGPU_EXECBUF_FLAGS (\
+ VIRTGPU_EXECBUF_FENCE_FD_IN |\
+ VIRTGPU_EXECBUF_FENCE_FD_OUT |\
+ 0)
+
struct drm_virtgpu_map {
__u64 offset; /* use for mmap system call */
__u32 handle;
@@ -54,12 +61,12 @@ struct drm_virtgpu_map {
};
struct drm_virtgpu_execbuffer {
- __u32 flags; /* for future use */
+ __u32 flags;
__u32 size;
__u64 command; /* void* */
__u64 bo_handles;
__u32 num_bo_handles;
- __u32 pad;
+ __s32 fence_fd;
};
#define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */
@@ -137,7 +144,7 @@ struct drm_virtgpu_get_caps {
DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_MAP, struct drm_virtgpu_map)
#define DRM_IOCTL_VIRTGPU_EXECBUFFER \
- DRM_IOW(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
+ DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
struct drm_virtgpu_execbuffer)
#define DRM_IOCTL_VIRTGPU_GETPARAM \
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108513] Request for new account
https://bugs.freedesktop.org/show_bug.cgi?id=108513 Daniel Vetter changed: What|Removed |Added Version|DRI git |unspecified Status|NEW |ASSIGNED Product|DRI |freedesktop.org Component|DRM/other |New Accounts Assignee|dri-devel@lists.freedesktop |sitewranglers@lists.freedes |.org|ktop.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 108513] Request for new account
https://bugs.freedesktop.org/show_bug.cgi?id=108513 --- Comment #2 from Daniel Vetter --- ack -- 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 4/9] dt-bindings: Add ANX6345 DP/eDP transmitter binding
On Thu, Oct 18, 2018 at 08:40:11PM +0800, Icenowy Zheng wrote: > 在 2018-10-18四的 14:23 +0300，Laurent Pinchart写道： > > Hi Icenowy, > > > > On Thursday, 18 October 2018 13:00:05 EEST Icenowy Zheng wrote: > > > 在 2018-10-18四的 11:53 +0300，Laurent Pinchart写道： > > > > On Thursday, 18 October 2018 10:33:22 EEST Icenowy Zheng wrote: > > > > > The ANX6345 is an ultra-low power DisplayPort/eDP transmitter > > > > > designed > > > > > for portable devices. > > > > > > > > > > Add a binding document for it. > > > > > > > > > > Signed-off-by: Icenowy Zheng > > > > > --- > > > > > > > > > > .../bindings/display/bridge/anx6345.txt | 39 > > > > > +++ > > > > > > > > > > 1 file changed, 39 insertions(+) > > > > > create mode 100644 > > > > > > > > > > Documentation/devicetree/bindings/display/bridge/anx6345.txt > > > > > > > > > > diff --git > > > > > a/Documentation/devicetree/bindings/display/bridge/anx6345.txt > > > > > b/Documentation/devicetree/bindings/display/bridge/anx6345.txt > > > > > new > > > > > file > > > > > mode 100644 > > > > > index ..0689d4eb5f65 > > > > > --- /dev/null > > > > > +++ > > > > > b/Documentation/devicetree/bindings/display/bridge/anx6345.txt > > > > > @@ -0,0 +1,39 @@ > > > > > +Analogix ANX6345 eDP Transmitter > > > > > + > > > > > + > > > > > +The ANX6345 is an ultra-low power Full-HD eDP transmitter > > > > > designed > > > > > for > > > > > +portable devices. > > > > > + > > > > > +Required properties: > > > > > + > > > > > + - compatible: "analogix,anx6345" > > > > > + - reg : I2C address of the device > > > > > + - reset-gpios : Which GPIO to use for reset > > > > > + > > > > > +Optional properties: > > > > > + > > > > > + - dvdd12-supply : Regulator for 1.2V digital core > > > > > power. > > > > > + - dvdd25-supply : Regulator for 2.5V digital core > > > > > power. > > > > > > > > Shouldn't these to supplies be mandatory ? > > > > > > Yes they should. > > > > > > > > + - panel-supply : Regulator for the power of > > > > > the panel. > > > > > > > > Shouldn't the panel supply for specified in the DT node of the > > > > panel > > > > ? > > > > > > However, eDP panel can be probed, may vary on the same device, and > > > we > > > don't have a generic binding for it... > > > > Shouldn't we fix that ? :-) > > Maybe we should create a connector binding instead of a panel binding? There's not any such thing as a standard eDP connector, is there? Otherwise, that's just creating a generic panel binding in disguise. Maybe if eDP interface is standardized enough in terms of power control, control lines, EDID at least sometimes present, etc., then we could have some sort of generic eDP panel/connector binding. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/powerplay: remove duplicated includes
On Sun, Oct 21, 2018 at 11:32 PM YueHaibing wrote: > > Remove some duplicated include. > > Signed-off-by: YueHaibing Applied. Thanks! Alex > --- > drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 - > drivers/gpu/drm/amd/powerplay/inc/smu7_common.h | 4 > drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 1 - > drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c | 1 - > drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 1 - > 5 files changed, 8 deletions(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > index e5a60aa..07d180ce 100644 > --- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > +++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > @@ -28,7 +28,6 @@ > #include "hardwaremanager.h" > #include "hwmgr_ppt.h" > #include "ppatomctrl.h" > -#include "hwmgr_ppt.h" > #include "power_state.h" > #include "smu_helper.h" > > diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h > b/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h > index 65eb630..94bf7b6 100644 > --- a/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h > +++ b/drivers/gpu/drm/amd/powerplay/inc/smu7_common.h > @@ -40,10 +40,6 @@ > #include "bif/bif_5_0_d.h" > #include "bif/bif_5_0_sh_mask.h" > > - > -#include "bif/bif_5_0_d.h" > -#include "bif/bif_5_0_sh_mask.h" > - > #include "dce/dce_10_0_d.h" > #include "dce/dce_10_0_sh_mask.h" > > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c > b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c > index 872d382..2b2c266 100644 > --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c > @@ -44,7 +44,6 @@ > > #include "smu7_hwmgr.h" > #include "hardwaremanager.h" > -#include "ppatomctrl.h" > #include "atombios.h" > #include "pppcielanes.h" > > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c > b/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c > index d0eb8ab..d111dd4 100644 > --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c > @@ -29,7 +29,6 @@ > #include "rv_ppsmc.h" > #include "smu10_driver_if.h" > #include "smu10.h" > -#include "ppatomctrl.h" > #include "pp_debug.h" > > > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c > b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c > index 9f71512..1e69300 100644 > --- a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c > @@ -40,7 +40,6 @@ > > #include "smu7_hwmgr.h" > #include "hardwaremanager.h" > -#include "ppatomctrl.h" > #include "atombios.h" > #include "pppcielanes.h" > > -- > 1.8.3.1 > > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/radeon/kms: remove set but not used variable 'pll'
On Sun, Oct 21, 2018 at 11:32 PM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/radeon/radeon_legacy_tv.c: In function
> 'radeon_legacy_tv_init_restarts':
> drivers/gpu/drm/radeon/radeon_legacy_tv.c:435:21: warning:
> variable 'pll' set but not used [-Wunused-but-set-variable]
> struct radeon_pll *pll;
>
> It never used since introduction in commit
> 4ce001abafaf ("drm/radeon/kms: add initial radeon tv-out support.")
> Also remove related variables 'dev, rdev, radeon_crtc'
>
> Signed-off-by: YueHaibing
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_legacy_tv.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
> b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
> index 4278272..3dae2c4 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
> @@ -421,24 +421,14 @@ static void radeon_legacy_write_tv_restarts(struct
> radeon_encoder *radeon_encode
>
> static bool radeon_legacy_tv_init_restarts(struct drm_encoder *encoder)
> {
> - struct drm_device *dev = encoder->dev;
> - struct radeon_device *rdev = dev->dev_private;
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> struct radeon_encoder_tv_dac *tv_dac = radeon_encoder->enc_priv;
> - struct radeon_crtc *radeon_crtc;
> int restart;
> unsigned int h_total, v_total, f_total;
> int v_offset, h_offset;
> u16 p1, p2, h_inc;
> bool h_changed;
> const struct radeon_tv_mode_constants *const_ptr;
> - struct radeon_pll *pll;
> -
> - radeon_crtc = to_radeon_crtc(radeon_encoder->base.crtc);
> - if (radeon_crtc->crtc_id == 1)
> - pll = >clock.p2pll;
> - else
> - pll = >clock.p1pll;
>
> const_ptr = radeon_legacy_tv_get_std_mode(radeon_encoder, NULL);
> if (!const_ptr)
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/4] drm/amdgpu: Set FreeSync state using drm VRR properties
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Support for AMDGPU specific FreeSync properties and ioctls are dropped
> from amdgpu_dm in favor of supporting drm variable refresh rate
> properties.
>
> The notify_freesync and set_freesync_property functions are dropped
> from amdgpu_display_funcs.
>
> The drm vrr_capable property is now attached to any DP/HDMI connector.
> Its value is updated accordingly to the connector's FreeSync capabiltiy.
>
> The freesync_enable logic and ioctl control has has been dropped in
> favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
> fine grained atomic control over which CRTCs should support variable
> refresh rate.
>
> To handle state changes for vrr_enabled it was easiest to drop the
> forced modeset on freesync_enabled change. This patch now performs the
> required stream updates when planes are flipped.
>
> This is done for a few reasons:
>
> (1) VRR stream updates can be done in the fast update path
>
> (2) amdgpu_dm_atomic_check would need to be hacked apart to check
> desired variable refresh state and capability before the CRTC
> disable pass.
>
> (3) Performing VRR stream updates on-flip is needed for enabling BTR
> support.
>
> VRR packets and timing adjustments are now tracked and compared to
> previous values sent to the hardware.
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 7 -
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 255 +-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +-
> 3 files changed, 138 insertions(+), 131 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index b9e9e8b02fb7..0cbe867ec375 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -295,13 +295,6 @@ struct amdgpu_display_funcs {
> uint16_t connector_object_id,
> struct amdgpu_hpd *hpd,
> struct amdgpu_router *router);
> - /* it is used to enter or exit into free sync mode */
> - int (*notify_freesync)(struct drm_device *dev, void *data,
> -struct drm_file *filp);
> - /* it is used to allow enablement of freesync mode */
> - int (*set_freesync_property)(struct drm_connector *connector,
> - struct drm_property *property,
> - uint64_t val);
>
>
> };
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index e224f23e2215..f6af388cc32d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1802,72 +1802,6 @@ static void dm_bandwidth_update(struct amdgpu_device
> *adev)
> /* TODO: implement later */
> }
>
> -static int amdgpu_notify_freesync(struct drm_device *dev, void *data,
> - struct drm_file *filp)
> -{
> - struct drm_atomic_state *state;
> - struct drm_modeset_acquire_ctx ctx;
> - struct drm_crtc *crtc;
> - struct drm_connector *connector;
> - struct drm_connector_state *old_con_state, *new_con_state;
> - int ret = 0;
> - uint8_t i;
> - bool enable = false;
> -
> - drm_modeset_acquire_init(, 0);
> -
> - state = drm_atomic_state_alloc(dev);
> - if (!state) {
> - ret = -ENOMEM;
> - goto out;
> - }
> - state->acquire_ctx =
> -
> -retry:
> - drm_for_each_crtc(crtc, dev) {
> - ret = drm_atomic_add_affected_connectors(state, crtc);
> - if (ret)
> - goto fail;
> -
> - /* TODO rework amdgpu_dm_commit_planes so we don't need this */
> - ret = drm_atomic_add_affected_planes(state, crtc);
> - if (ret)
> - goto fail;
> - }
> -
> - for_each_oldnew_connector_in_state(state, connector, old_con_state,
> new_con_state, i) {
> - struct dm_connector_state *dm_new_con_state =
> to_dm_connector_state(new_con_state);
> - struct drm_crtc_state *new_crtc_state;
> - struct amdgpu_crtc *acrtc =
> to_amdgpu_crtc(dm_new_con_state->base.crtc);
> - struct dm_crtc_state *dm_new_crtc_state;
> -
> - if (!acrtc) {
> - ASSERT(0);
> - continue;
> - }
> -
> - new_crtc_state = drm_atomic_get_new_crtc_state(state,
> >base);
> - dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
> -
> - dm_new_crtc_state->freesync_enabled = enable;
> - }
> -
> - ret = drm_atomic_commit(state);
> -
> -fail:
> - if (ret == -EDEADLK) {
> - drm_atomic_state_clear(state);
> - drm_modeset_backoff();
> -
Re: [PATCH 6/6] dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
On Mon, Oct 22, 2018 at 01:46:39PM -0700, Douglas Anderson wrote:
> As far as I can tell the bindings that were added in commit
> 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> bindings") weren't actually for Innolux TV123WAM but were actually for
> Innolux P120ZDG-BF1.
>
> As far as I can tell the Innolux TV123WAM isn't a real panel and but
> it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> Let's unmosh.
>
> Here's my evidence:
>
> * Searching for TV123WAM on the Internet turns up a TI panel. While
> it's possible that an Innolux panel has the same model number as the
> TI Panel, it seems a little doubtful. Looking up the datasheet from
> the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
>
> * As far as I know, the patch adding the Innolux Panel was supposed to
> be for the board that's sitting in front of me as I type this
> (support for that board is not yet upstream). On the back of that
> panel I see Innolux P120ZDZ-EZ1 rev B1.
>
> * Someone pointed me at a datasheet that's supposed to be for the
> panel in front of me (sorry, I can't share the datasheet). That
> datasheet has the string "p120zdg-bf1"
>
> * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> that are 2160x1440. They don't have datasheets, but the fact that
> the resolution matches is a good sign.
>
> While we doing the rename, also mention that no-hpd can be used with
> this panel. See the previous patch in this series ("drm/panel:
> simple: Add "no-hpd" delay for Innolux TV123WAM").
>
> Fixes: 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> bindings")
> Signed-off-by: Douglas Anderson
> Cc: Sandeep Panda
> ---
>
> .../{innolux,tv123wam.txt => innolux,p120zdg-bf1.txt} | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
> rename Documentation/devicetree/bindings/display/panel/{innolux,tv123wam.txt
> => innolux,p120zdg-bf1.txt} (70%)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
> b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
> similarity index 70%
> rename from
> Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
> rename to
> Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
Same concerns here, you might consider leaving a breadcrumb here to point to
p120zdg-bf1 (noting that the old compatible string will continue to work).
Again, if robh is Ok with wiping innolux,tv123wam from existance, please ignore
:)
Sean
> index a9b35265fa13..513f03466aba 100644
> --- a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
> +++ b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt
> @@ -1,20 +1,22 @@
> -Innolux TV123WAM 12.3 inch eDP 2K display panel
> +Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel
>
> This binding is compatible with the simple-panel binding, which is specified
> in simple-panel.txt in this directory.
>
> Required properties:
> -- compatible: should be "innolux,tv123wam"
> +- compatible: should be "innolux,p120zdg-bf1"
> - power-supply: regulator to provide the supply voltage
>
> Optional properties:
> - enable-gpios: GPIO pin to enable or disable the panel
> - backlight: phandle of the backlight device attached to the panel
> +- no-hpd: If HPD isn't hooked up; add this property.
>
> Example:
> panel_edp: panel-edp {
> - compatible = "innolux,tv123wam";
> + compatible = "innolux,p120zdg-bf1";
> enable-gpios = < 31 GPIO_ACTIVE_LOW>;
> power-supply = <_l2>;
> backlight = <>;
> + no-hpd;
> };
> --
> 2.19.1.568.g152ad8e336-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> As far as I can tell the panel that was added in commit da50bd4258db
> ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> wasn't actually an Innolux TV123WAM but was actually an Innolux
> P120ZDG-BF1.
>
> As far as I can tell the Innolux TV123WAM isn't a real panel and but
> it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1.
> Let's unmosh.
>
> Here's my evidence:
>
> * Searching for TV123WAM on the Internet turns up a TI panel. While
> it's possible that an Innolux panel has the same model number as the
> TI Panel, it seems a little doubtful. Looking up the datasheet from
> the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm.
>
> * As far as I know, the patch adding the Innolux Panel was supposed to
> be for the board that's sitting in front of me as I type this
> (support for that board is not yet upstream). On the back of that
> panel I see Innolux P120ZDZ-EZ1 rev B1.
>
> * Someone pointed me at a datasheet that's supposed to be for the
> panel in front of me (sorry, I can't share the datasheet). That
> datasheet has the string "p120zdg-bf1"
>
> * If I search for "P120ZDG-BF1" on the Internet I get hits for panels
> that are 2160x1440. They don't have datasheets, but the fact that
> the resolution matches is a good sign.
>
> In any case, let's update the name and also the physical size to match
> the correct panel.
>
> Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver
> support")
> Signed-off-by: Douglas Anderson
> Cc: Sandeep Panda
> ---
>
> drivers/gpu/drm/panel/panel-simple.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 937e97490c30..7ee1abc5d81b 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1370,7 +1370,7 @@ static const struct panel_desc innolux_n156bge_l21 = {
> },
> };
>
> -static const struct drm_display_mode innolux_tv123wam_mode = {
> +static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
> .clock = 206016,
> .hdisplay = 2160,
> .hsync_start = 2160 + 48,
> @@ -1384,13 +1384,13 @@ static const struct drm_display_mode
> innolux_tv123wam_mode = {
> .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> };
>
> -static const struct panel_desc innolux_tv123wam = {
> - .modes = _tv123wam_mode,
> +static const struct panel_desc innolux_p120zdg_bf1 = {
> + .modes = _p120zdg_bf1_mode,
> .num_modes = 1,
> .bpc = 8,
> .size = {
> - .width = 259,
> - .height = 173,
> + .width = 254,
> + .height = 169,
> },
> .delay = {
> .prepare = 200,
> @@ -2454,8 +2454,8 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "innolux,n156bge-l21",
> .data = _n156bge_l21,
> }, {
> - .compatible = "innolux,tv123wam",
I think we should update the struct, but we might want to keep this around.
Given the tv123wam panel is TI, we're likely not going to have a collision on
innolux,...
That said, I'll defer to robh on this one, I'm not sure if changing names is
cool once the bindings have hit mainline.
> - .data = _tv123wam,
> + .compatible = "innolux,p120zdg-bf1",
> + .data = _p120zdg_bf1,
> }, {
> .compatible = "innolux,zj070na-01p",
> .data = _zj070na_01p,
> --
> 2.19.1.568.g152ad8e336-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/4] drm: Document variable refresh properties
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote: > These include the drm_connector 'vrr_capable' and the drm_crtc > 'vrr_enabled' properties. > > Signed-off-by: Nicholas Kazlauskas > --- > Documentation/gpu/drm-kms.rst | 7 +++ > drivers/gpu/drm/drm_connector.c | 22 ++ > 2 files changed, 29 insertions(+) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index 4b1501b4835b..8da2a178cf85 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -575,6 +575,13 @@ Explicit Fencing Properties > .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c > :doc: explicit fencing properties > > + > +Variable Refresh Properties > +--- > + > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c > + :doc: Variable refresh properties > + > Existing KMS Properties > --- > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index f0deeb7298d0..2a12853ca917 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1254,6 +1254,28 @@ int drm_mode_create_scaling_mode_property(struct > drm_device *dev) > } > EXPORT_SYMBOL(drm_mode_create_scaling_mode_property); > > +/** > + * DOC: Variable refresh properties > + * > + * Variable refresh rate control is supported via properties on the > + * _connector and _crtc objects. > + * > + * "vrr_capable": > + * Optional _connector boolean property that drivers should attach > + * with drm_connector_attach_vrr_capable_property() on connectors that > + * could support variable refresh rates. Drivers should update the > + * property value by calling drm_connector_set_vrr_capable_property(). > + * > + * Absence of the property should indicate absence of support. > + * > + * "vrr_enabled": > + * Default _crtc boolean property that notifies the driver that the > + * variable refresh rate adjustment should be enabled for the CRTC. > + * > + * Support for variable refresh rate will depend on the "vrr_capable" > + * property exposed on the _connector object. We probably want to make it clear that this is a content hint. Maybe something like: * "vrr_enabled": * Default _crtc boolean property that notifies the driver that the * content on the CRTC is suitable for variable refresh presentation. * The driver will take that as a hint to enable variable refresh rate * if the receiver supports it, i.e. the "vrr_capable" property on the * _connector_object is true. Harry > + */ > + > /** > * drm_connector_attach_vrr_capable_property - creates the > * vrr_capable property > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/bridge: ti-sn65dsi86: Remove the mystery delay
On Mon, Oct 22, 2018 at 01:46:37PM -0700, Douglas Anderson wrote:
> Let's solve the mystery of commit bf1178c98930 ("drm/bridge:
> ti-sn65dsi86: Add mystery delay to enable()"). Specifically the
> reason we needed that mystery delay is that we weren't paying
> attention to HPD.
>
> Looking at the datasheet for the same panel that was tested for the
> original commit, I see there's a timing "t3" that times from power on
> to the aux channel being operational. This time is specced as 0 - 200
> ms. The datasheet says that the aux channel is operational at exactly
> the same time that HPD is asserted.
>
> Scoping the signals on this board showed that HPD was asserted 84 ms
> after power was asserted. That very closely matches the magic 70 ms
> delay that we had. ...and actually, in my testing the 70 ms wasn't
> quite enough of a delay and some percentage of the time the display
> didn't come up until I bumped it to 100 ms (presumably 84 ms would
> have worked too).
>
> To solve this, we tried to hook up the HPD signal in the bridge.
> ...but in doing so we found that that the bridge didn't report that
> HPD was asserted until ~280 ms after we powered it (!). This is
> explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD
> (Hot Plug/Unplug Detection)". Reading there we see that the bridge
> isn't even intended to report HPD until 100 ms after it's asserted.
> ...but that would have left us at 184 ms. The extra 100 ms
> (presumably) comes from this part in the datasheet:
>
> > The HPD state machine operates off an internal ring oscillator. The
> > ring oscillator frequency will vary [ ... ]. The min/max range in
> > the HPD State Diagram refers to the possible times based off
> > variation in the ring oscillator frequency.
>
> Given that the 280 ms we'll end up delaying if we hook up HPD is
> _slower_ than the 200 ms we could just hardcode, for now we'll solve
> the problem by just hardcoding a 200 ms delay in the panel driver
> using the patch in this series ("drm/panel: simple: Support panels
> with HPD where HPD isn't connected").
>
> If we later find a panel that needs to use this bridge where we need
> HPD then we'll have to come up with some new code to handle it. Given
> the silly debouncing in the bridge chip, though, it seems unlikely.
>
> One last note is that I tried to solve this through another way: In
> ti_sn_bridge_enable() I tried to use various combinations of
> dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel
> was up. In theory that would let me detect _exactly_ when I could
> continue and do link training. Unfortunately even if I did an aux
> transfer w/out waiting I couldn't see any errors. Possibly I could
> keep looping over link training until it came back with success, but
> that seemed a little overly hacky to me.
>
> Signed-off-by: Douglas Anderson
Awesome commit message and comment, thanks for solving the mystery!
Reviewed-by: Sean Paul
> ---
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 29 +++
> 1 file changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index f8a931cf3665..680566d97adc 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -458,18 +458,6 @@ static void ti_sn_bridge_enable(struct drm_bridge
> *bridge)
> unsigned int val;
> int ret;
>
> - /*
> - * FIXME:
> - * This 70ms was found necessary by experimentation. If it's not
> - * present, link training fails. It seems like it can go anywhere from
> - * pre_enable() up to semi-auto link training initiation below.
> - *
> - * Neither the datasheet for the bridge nor the panel tested mention a
> - * delay of this magnitude in the timing requirements. So for now, add
> - * the mystery delay until someone figures out a better fix.
> - */
> - msleep(70);
> -
> /* DSI_A lane config */
> val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
> regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
> @@ -536,7 +524,22 @@ static void ti_sn_bridge_pre_enable(struct drm_bridge
> *bridge)
> /* configure bridge ref_clk */
> ti_sn_bridge_set_refclk_freq(pdata);
>
> - /* in case drm_panel is connected then HPD is not supported */
> + /*
> + * HPD on this bridge chip is a bit useless. This is an eDP bridge
> + * so the HPD is an internal signal that's only there to signal that
> + * the panel is done powering up. ...but the bridge chip debounces
> + * this signal by between 100 ms and 400 ms (depending on process,
> + * voltage, and temperate--I measured it at about 200 ms). One
> + * particular panel asserted HPD 84 ms after it was powered on meaning
> + * that we saw HPD 284 ms after power on. ...but the same panel said
> + * that instead of looking at HPD you could just
Re: [PATCH v5 2/4] drm: Add vrr_enabled property to drm CRTC
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> This patch introduces the 'vrr_enabled' CRTC property to allow
> dynamic control over variable refresh rate support for a CRTC.
>
> This property should be treated like a content hint to the driver -
> if the hardware or driver is not capable of driving variable refresh
> timings then this is not considered an error.
>
> Capability for variable refresh rate support should be determined
> by querying the vrr_capable drm connector property.
>
> It is worth noting that while the property is intended for atomic use
> it isn't filtered from legacy userspace queries. This allows for Xorg
> userspace drivers to implement support.
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_crtc.c| 2 ++
> drivers/gpu/drm/drm_mode_config.c | 6 ++
> include/drm/drm_crtc.h| 9 +
> include/drm/drm_mode_config.h | 5 +
> 5 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..eec396a57b88 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -433,6 +433,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
> drm_property_blob_put(mode);
> return ret;
> + } else if (property == config->prop_vrr_enabled) {
> + state->vrr_enabled = val;
> } else if (property == config->degamma_lut_property) {
> ret = drm_atomic_replace_property_blob_from_id(dev,
> >degamma_lut,
> @@ -491,6 +493,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = state->active;
> else if (property == config->prop_mode_id)
> *val = (state->mode_blob) ? state->mode_blob->base.id : 0;
> + else if (property == config->prop_vrr_enabled)
> + *val = state->vrr_enabled;
> else if (property == config->degamma_lut_property)
> *val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
> else if (property == config->ctm_property)
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 5f488aa80bcd..e4eb2c897ff4 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -340,6 +340,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> struct drm_crtc *crtc,
> drm_object_attach_property(>base, config->prop_mode_id,
> 0);
> drm_object_attach_property(>base,
> config->prop_out_fence_ptr, 0);
> + drm_object_attach_property(>base,
> +config->prop_vrr_enabled, 0);
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index ee80788f2c40..5670c67f28d4 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -310,6 +310,12 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.prop_mode_id = prop;
>
> + prop = drm_property_create_bool(dev, 0,
> + "VRR_ENABLED");
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_vrr_enabled = prop;
> +
> prop = drm_property_create(dev,
> DRM_MODE_PROP_BLOB,
> "DEGAMMA_LUT", 0);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b21437bc95bf..39c3900aab3c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -290,6 +290,15 @@ struct drm_crtc_state {
>*/
> u32 pageflip_flags;
>
> + /**
> + * @vrr_enabled:
> + *
> + * Indicates if variable refresh rate should be enabled for the CRTC.
> + * Support for the requested vrr state will depend on driver and
> + * hardware capabiltiy - lacking support is not treated as failure.
> + */
> + bool vrr_enabled;
> +
> /**
>* @event:
>*
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 928e4172a0bb..49f2fcfdb5fc 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -639,6 +639,11 @@ struct drm_mode_config {
>* connectors must be of and active must be set to disabled, too.
>*/
> struct drm_property *prop_mode_id;
> + /**
> + * @prop_vrr_enabled: Default atomic CRTC property to indicate
> + * whether variable refresh rate should be enabled on the CRTC.
> + */
> + struct drm_property *prop_vrr_enabled;
>
> /**
>* @dvi_i_subconnector_property: Optional DVI-I property to
>
Re: [PATCH 2/6] drm/panel: simple: Support panels with HPD where HPD isn't connected
On Mon, Oct 22, 2018 at 01:46:35PM -0700, Douglas Anderson wrote:
> Some eDP panels that are designed to be always connected to a board
> use their HPD signal to signal that they've finished powering on and
> they're ready to be talked to.
>
> However, for various reasons it's possible that the HPD signal from
> the panel isn't actually hooked up. In the case where the HPD isn't
> hooked up you can look at the timing diagram on the panel datasheet
> and insert a delay for the maximum amount of time that the HPD might
> take to come up.
>
> Let's add support in simple-panel for this concept.
>
> At the moment we will co-opt the existing "prepare" delay to keep
> track of the delay and we'll use a boolean to specify that a given
> panel should only apply the delay if the "no-hpd" property was
> specified.
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/panel/panel-simple.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 97964f7f2ace..38c646fb55fd 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -63,12 +63,15 @@ struct panel_desc {
>* turn the display off (no content is visible)
>* @unprepare: the time (in milliseconds) that it takes for the panel
>* to power itself down completely
> + * @prepare_delay_only_if_no_hpd: The prepare delay should only be done
> + *if we know Hot Plug Detect isn't used.
I think it'd be more clear if we just had a new 'hpd_absent_delay' which is
added to prepare if no_hpd is true.
Sean
>*/
> struct {
> unsigned int prepare;
> unsigned int enable;
> unsigned int disable;
> unsigned int unprepare;
> + bool prepare_delay_only_if_no_hpd;
> } delay;
>
> u32 bus_format;
> @@ -79,6 +82,7 @@ struct panel_simple {
> struct drm_panel base;
> bool prepared;
> bool enabled;
> + bool no_hpd;
>
> const struct panel_desc *desc;
>
> @@ -215,7 +219,8 @@ static int panel_simple_prepare(struct drm_panel *panel)
>
> gpiod_set_value_cansleep(p->enable_gpio, 1);
>
> - if (p->desc->delay.prepare)
> + if (p->desc->delay.prepare &&
> + (!p->desc->delay.prepare_delay_only_if_no_hpd || p->no_hpd))
> msleep(p->desc->delay.prepare);
>
> p->prepared = true;
> @@ -305,6 +310,8 @@ static int panel_simple_probe(struct device *dev, const
> struct panel_desc *desc)
> panel->prepared = false;
> panel->desc = desc;
>
> + panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
> +
> panel->supply = devm_regulator_get(dev, "power");
> if (IS_ERR(panel->supply))
> return PTR_ERR(panel->supply);
> --
> 2.19.1.568.g152ad8e336-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] dt-bindings: drm/panel: simple: Add no-hpd property
On Mon, Oct 22, 2018 at 01:46:34PM -0700, Douglas Anderson wrote: > Some eDP panels that are designed to be always connected to a board > use their HPD signal to signal that they've finished powering on and > they're ready to be talked to. > > However, for various reasons it's possible that the HPD signal from > the panel isn't actually hooked up. In the case where the HPD isn't > hooked up you can look at the timing diagram on the panel datasheet > and insert a delay for the maximum amount of time that the HPD might > take to come up. > > Let's add a property in the device tree for this concept. > > Signed-off-by: Douglas Anderson Reviewed-by: Sean Paul > --- > > .../devicetree/bindings/display/panel/simple-panel.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt > b/Documentation/devicetree/bindings/display/panel/simple-panel.txt > index 45a457ad38f0..b2b872c710f2 100644 > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt > @@ -11,6 +11,9 @@ Optional properties: > - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > - enable-gpios: GPIO pin to enable or disable the panel > - backlight: phandle of the backlight device attached to the panel > +- no-hpd: This panel is supposed to communicate that it's ready via HPD > + (hot plug detect) signal, but the signal isn't hooked up so we should > + hardcode the max delay from the panel spec when powering up the panel. > > Example: > > -- > 2.19.1.568.g152ad8e336-goog > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/4] drm: Add vrr_capable property to the drm connector
On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces the "vrr_capable" property on the connector to
> allow userspace to query support for variable refresh rates.
>
> Atomic drivers should attach this property to connectors that are
> capable of driving variable refresh rates using
> drm_connector_attach_vrr_capable_property().
>
> The value should be updated based on driver and hardware capabiltiy
> by using drm_connector_set_vrr_capable_property().
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_connector.c | 49 +
> include/drm/drm_connector.h | 15 ++
> 2 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1e40e5decbe9..f0deeb7298d0 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1254,6 +1254,37 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev)
> }
> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>
> +/**
> + * drm_connector_attach_vrr_capable_property - creates the
> + * vrr_capable property
> + * @connector: connector to create the vrr_capable property on.
> + *
> + * This is used by atomic drivers to add support for querying
> + * variable refresh rate capability for a connector.
> + *
> + * Returns:
> + * Zero on success, negative errono on failure.
> + */
> +int drm_connector_attach_vrr_capable_property(
> + struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> +
> + if (!connector->vrr_capable_property) {
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE,
> + "vrr_capable");
> + if (!prop)
> + return -ENOMEM;
> +
> + connector->vrr_capable_property = prop;
> + drm_object_attach_property(>base, prop, 0);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_vrr_capable_property);
> +
> /**
> * drm_connector_attach_scaling_mode_property - attach atomic scaling mode
> property
> * @connector: connector to attach scaling mode property on.
> @@ -1582,6 +1613,24 @@ void drm_connector_set_link_status_property(struct
> drm_connector *connector,
> }
> EXPORT_SYMBOL(drm_connector_set_link_status_property);
>
> +/**
> + * drm_connector_set_vrr_capable_property - sets the variable refresh rate
> + * capable property for a connector
> + * @connector: drm connector
> + * @capable: True if the connector is variable refresh rate capable
> + *
> + * Should be used by atomic drivers to update the indicated support for
> + * variable refresh rate over a connector.
> + */
> +void drm_connector_set_vrr_capable_property(
> + struct drm_connector *connector, bool capable)
> +{
> + drm_object_property_set_value(>base,
> + connector->vrr_capable_property,
> + capable);
> +}
> +EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> +
> /**
> * drm_connector_init_panel_orientation_property -
> * initialize the connecters panel_orientation property
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 91a877fa00cb..b2263005234a 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -910,6 +910,17 @@ struct drm_connector {
>*/
> struct drm_property *scaling_mode_property;
>
> + /**
> + * @vrr_capable_property: Optional property to help userspace
> + * query hardware support for variable refresh rate on a connector.
> + * connector. Drivers can add the property to a connector by
> + * calling drm_connector_attach_vrr_capable_property().
> + *
> + * This should be updated only by calling
> + * drm_connector_set_vrr_capable_property().
> + */
> + struct drm_property *vrr_capable_property;
> +
> /**
>* @content_protection_property: DRM ENUM property for content
>* protection. See drm_connector_attach_content_protection_property().
> @@ -1183,6 +1194,8 @@ int drm_mode_create_scaling_mode_property(struct
> drm_device *dev);
> int drm_connector_attach_content_type_property(struct drm_connector *dev);
> int drm_connector_attach_scaling_mode_property(struct drm_connector
> *connector,
> u32 scaling_mode_mask);
> +int drm_connector_attach_vrr_capable_property(
> + struct drm_connector *connector);
> int drm_connector_attach_content_protection_property(
> struct drm_connector *connector);
> int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> @@ -1199,6 +1212,8 @@ int drm_connector_update_edid_property(struct
> drm_connector *connector,
>
Re: [PATCH] drm: fix call_kern.cocci warnings v3
Op 25-10-18 om 14:01 schreef Chunming Zhou:
>
> 在 2018/10/25 18:36, Maarten Lankhorst 写道:
>> Op 25-10-18 om 12:21 schreef Chunming Zhou:
>>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>>> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
>>> 389 but uses GFP_KERNEL
>>>
>>>Find functions that refer to GFP_KERNEL but are called with locks held.
>>>
>>> Generated by: scripts/coccinelle/locks/call_kern.cocci
>>>
>>> v2:
>>> syncobj->timeline still needs protect.
>>>
>>> v3:
>>> use a global signaled fence instead of re-allocation.
>>>
>>> Signed-off-by: Chunming Zhou
>>> Cc: Maarten Lankhorst
>>> Cc: intel-...@lists.freedesktop.org
>>> Cc: Christian König
>>> ---
>>> drivers/gpu/drm/drm_drv.c | 2 ++
>>> drivers/gpu/drm/drm_syncobj.c | 52 +--
>>> include/drm/drm_syncobj.h | 1 +
>>> 3 files changed, 34 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>>> index 36e8e9cbec52..0a6f1023d6c3 100644
>>> --- a/drivers/gpu/drm/drm_drv.c
>>> +++ b/drivers/gpu/drm/drm_drv.c
>>> @@ -37,6 +37,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "drm_crtc_internal.h"
>>> #include "drm_legacy.h"
>>> @@ -1003,6 +1004,7 @@ static int __init drm_core_init(void)
>>> if (ret < 0)
>>> goto error;
>>>
>>> + drm_syncobj_stub_fence_init();
>>> drm_core_init_complete = true;
>>>
>>> DRM_DEBUG("Initialized\n");
>>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>>> index b7eaa603f368..6b3f5a06e4d3 100644
>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>> @@ -80,6 +80,27 @@ struct drm_syncobj_signal_pt {
>>> struct list_head list;
>>> };
>>>
>>> +static struct drm_syncobj_stub_fence stub_signaled_fence;
>>> +static void global_stub_fence_release(struct dma_fence *fence)
>>> +{
>>> + /* it is impossible to come here */
>>> + BUG();
>>> +}
>> WARN_ON_ONCE(1)? No need to halt the machine.
>>
>>> +static const struct dma_fence_ops global_stub_fence_ops = {
>>> + .get_driver_name = drm_syncobj_stub_fence_get_name,
>>> + .get_timeline_name = drm_syncobj_stub_fence_get_name,
>>> + .release = global_stub_fence_release,
>>> +};
>>> +
>>> +void drm_syncobj_stub_fence_init(void)
>>> +{
>>> + spin_lock_init(_signaled_fence.lock);
>>> + dma_fence_init(_signaled_fence.base,
>>> + _stub_fence_ops,
>>> + _signaled_fence.lock,
>>> + 0, 0);
>>> + dma_fence_signal(_signaled_fence.base);
>>> +}
>>> /**
>>>* drm_syncobj_find - lookup and reference a sync object.
>>>* @file_private: drm file private pointer
>>> @@ -111,24 +132,14 @@ static struct dma_fence
>>> uint64_t point)
>>> {
>>> struct drm_syncobj_signal_pt *signal_pt;
>>> + struct dma_fence *f = NULL;
>>>
>>> + spin_lock(>pt_lock);
>>> if ((syncobj->type == DRM_SYNCOBJ_TYPE_TIMELINE) &&
>>> (point <= syncobj->timeline)) {
>>> - struct drm_syncobj_stub_fence *fence =
>>> - kzalloc(sizeof(struct drm_syncobj_stub_fence),
>>> - GFP_KERNEL);
>>> -
>>> - if (!fence)
>>> - return NULL;
>>> - spin_lock_init(>lock);
>>> - dma_fence_init(>base,
>>> - _syncobj_stub_fence_ops,
>>> - >lock,
>>> - syncobj->timeline_context,
>>> - point);
>>> -
>>> - dma_fence_signal(>base);
>>> - return >base;
>>> + dma_fence_get(_signaled_fence.base);
>>> + spin_unlock(>pt_lock);
>>> + return _signaled_fence.base;
>>> }
>>>
>>> list_for_each_entry(signal_pt, >signal_pt_list, list) {
>>> @@ -137,9 +148,12 @@ static struct dma_fence
>>> if ((syncobj->type == DRM_SYNCOBJ_TYPE_BINARY) &&
>>> (point != signal_pt->value))
>>> continue;
>>> - return dma_fence_get(_pt->fence_array->base);
>>> + f = dma_fence_get(_pt->fence_array->base);
>>> + break;
>>> }
>>> - return NULL;
>>> + spin_unlock(>pt_lock);
>>> +
>>> + return f;
>>> }
>>>
>>> static void drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
>>> @@ -166,9 +180,7 @@ static void
>>> drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
>>> }
>>>
>>> mutex_lock(>cb_mutex);
>>> - spin_lock(>pt_lock);
>>> *fence = drm_syncobj_find_signal_pt_for_point(syncobj, pt_value);
>>> - spin_unlock(>pt_lock);
>>> if (!*fence)
>>> drm_syncobj_add_callback_locked(syncobj, cb, func);
>>> mutex_unlock(>cb_mutex);
>>> @@ -379,11 +391,9 @@ drm_syncobj_point_get(struct drm_syncobj *syncobj, u64
>>> point, u64 flags,
>>> if (ret < 0)
>>>
Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support
On 2018-10-12 4:31 a.m., Koenig, Christian wrote: > Am 12.10.2018 um 10:26 schrieb Michel Dänzer: >> On 2018-10-11 9:44 p.m., Harry Wentland wrote: >>> On 2018-10-03 04:25 AM, Mike Lothian wrote: I'm curious to know whether this will/could work over PRIME >>> I don't see why this shouldn't work over PRIME as long as the >>> presenting GPU supports the new variable refresh rate API, but I know >>> very little about prime, so maybe someone else can chime in and give >>> a better opinion. >> It won't work for displays connected to a secondary GPU, because those >> aren't hooked up to the Present extension directly. >> >> It can theoretically work with render offloading, if the primary GPU can >> scan out directly from the shared pixmap. This is only possible with >> current AMD APUs which support scatter/gather scanout (Carrizo and >> newer?). > > Actually only Carizzo and Stoney at the moment because this is buggy on > Raven. Not sure if that is a pure software or a hardware problem. > > Christian. > >> One gotcha is that xf86-video-amdgpu currently doesn't allow >> flipping between buffers with different tiling parameters (BTW Harry, >> does that work with DC?), but that should be easy to fix. > Not currently. Fixable, but unfortunately not as easy as I'd hope. The good news is that I'm planning to rework that code so it would be easy to fix or should just happen on a per-flip basis. Harry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 00/14] kunit: introduce KUnit, the Linux kernel unit testing framework
On 10/23/2018 05:57 PM, Brendan Higgins wrote: > This patch set proposes KUnit, a lightweight unit testing and mocking > framework for the Linux kernel. > > Unlike Autotest and kselftest, KUnit is a true unit testing framework; > it does not require installing the kernel on a test machine or in a VM > and does not require tests to be written in userspace running on a host > kernel. Additionally, KUnit is fast: From invocation to completion KUnit > can run several dozen tests in under a second. Currently, the entire > KUnit test suite for KUnit runs in under a second from the initial > invocation (build time excluded). > > KUnit is heavily inspired by JUnit, Python's unittest.mock, and > Googletest/Googlemock for C++. KUnit provides facilities for defining > unit test cases, grouping related test cases into test suites, providing > common infrastructure for running tests, mocking, spying, and much more. > > ## What's so special about unit testing? > > A unit test is supposed to test a single unit of code in isolation, > hence the name. There should be no dependencies outside the control of > the test; this means no external dependencies, which makes tests orders > of magnitudes faster. Likewise, since there are no external dependencies, > there are no hoops to jump through to run the tests. Additionally, this > makes unit tests deterministic: a failing unit test always indicates a > problem. Finally, because unit tests necessarily have finer granularity, > they are able to test all code paths easily solving the classic problem > of difficulty in exercising error handling code. > > ## Is KUnit trying to replace other testing frameworks for the kernel? > > No. Most existing tests for the Linux kernel are end-to-end tests, which > have their place. A well tested system has lots of unit tests, a > reasonable number of integration tests, and some end-to-end tests. KUnit > is just trying to address the unit test space which is currently not > being addressed. > > ## More information on KUnit > > There is a bunch of documentation near the end of this patch set that > describes how to use KUnit and best practices for writing unit tests. > For convenience I am hosting the compiled docs here: > https://google.github.io/kunit-docs/third_party/kernel/docs/ > > ## Changes Since Last Version > > - Updated patchset to apply cleanly on 4.19. > - Stripped down patchset to focus on just the core features (I dropped >mocking, spying, and the MMIO stuff for now; you can find these >patches here: https://kunit-review.googlesource.com/c/linux/+/1132), >as suggested by Rob. > - Cleaned up some of the commit messages and tweaked commit order a >bit based on suggestions. > I am a bit behind on reviewing this patch series. Just a quick note that I will start looking at these early next week. thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v1 1/1] imx-drm: match ipu_di_signal_cfg's clk_pol with its observed behaviour.
On Thu, Oct 25, 2018 at 12:17:11PM -0400, thesve...@gmail.com wrote: > From: Sven Van Asbroeck > > We used an oscilloscope to observe the actual polarity of the > DI's pixel clock, and saw the following: > > DI_GENERAL bit 17 is SET: > pixel data is stable on the pixel clock's FALLING edge > DI_GENERAL bit 17 is CLEAR: > pixel data is stable on the pixel clock's RISING edge > > However, the current driver configures the exact opposite of the > behaviour documented in video/imx-ipu-v3.h: > unsigned clk_pol:1; /* true = rising edge */ The definition in the manual is: 17 DI0 Output Clock's polarity di0_polarity_ This bits define the polarity of the DI0's clock. disp_clk1The output clock is active high 0The output clock is active low but what does that mean... There's the hint in IMX6SDLCEC that when the clock is active high, it's expected that the panel will latch data on the _falling_ edge: IPP_DISP_CLK latches data into the panel on its negative edge (when positive polarity is selected). In active mode, IPP_DISP_CLK runs continuously. That seems to imply that when DI_GEN_POLARITY_DISP_CLK is set, it is expected that the panel latches data on the _falling_ edge, not on the positive edge. What this actually means as far as the output signal is not defined very well beyond what I've quoted above in any of the IMX6 manuals that I've checked so far. Now, the interpretation of the comment "/* true = rising edge */" is ambiguous, because it doesn't state what "rising edge" refers to - is that referring to the edge that the data changes, or the edge that the panel is supposed to latch the data. Given what's in the documentation, I'd opt for it describing the edge that the output data changes, not the latch edge. With that interpretation, the existing code is correct. In any case, I suspect if we were to change this as per your patch, we'd end up breaking stuff that works today, thereby causing regressions. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [igt-dev] [PATCH] RFC: Make igts for cross-driver stuff mandatory?
Sean Paul writes: > On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote: >> Hi all, >> >> This is just to collect feedback on this idea, and see whether the >> overall dri-devel community stands on all this. I think the past few >> cross-vendor uapi extensions all came with igts attached, and >> personally I think there's lots of value in having them: A >> cross-vendor interface isn't useful if every driver implements it >> slightly differently. >> >> I think there's 2 questions here: >> >> - Do we want to make such testcases mandatory? >> > > Yes, more testing == better code. > > >> - If yes, are we there yet, or is there something crucially missing >> still? > > In my experience, no. Last week while trying to replicate an intel-gfx CI > failure, I tried compiling igt for one of my (intel) chromebooks. It seems > like > cross-compilation (or, in my case, just specifying > prefix/ld_library_path/sbin_path) is broken on igt. If we want to impose > restrictions across the entire subsystem, we need to make sure that everyone > can > build and deploy igt easily. > > I managed to hack around everything and get it working, but I still haven't > tried switching out the toolchain. Once we have some GitLab CI to validate > cross-compilation, then we can consider making IGT mandatory. > > It's possible that I'm just a meson n00b and didn't use the right incantation, > so maybe it already works, but then we need better documentation. > > I've pasted my horrible hacks below, I also didn't have libunwind, so removed > its usage. I've also had to cut out libunwind for cross-compiling on many occasions. Worst library. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock
Quoting Chunming Zhou (2018-10-25 16:08:31) > drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function > drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line > 389 but uses GFP_KERNEL > > Find functions that refer to GFP_KERNEL but are called with locks held. > > Generated by: scripts/coccinelle/locks/call_kern.cocci > > v2: > syncobj->timeline still needs protect. > > v3: > use a global signaled fence instead of re-allocation. > > v4: > Don't need moving lock. > Don't expose func. > > Tested by: syncobj_wait and ./deqp-vk -n dEQP-VK.*semaphore* with > lock debug kernel options enabled. > > Signed-off-by: Chunming Zhou > Cc: Maarten Lankhorst > Cc: intel-...@lists.freedesktop.org > Cc: Christian König > Cc: Chris Wilson > CC: Julia Lawall > --- > - return NULL; > +out: > + return f; As it reduced to just a return, I'd probably have gone with multiple returns in this instance. Still the compiler should have done the equivalent and jumped to a single ret. Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: tinydrm driver for adafruit PiTFT 3.5" touchscreen
Eric Anholt writes: > I was going to start working on making the vc4 driver work with > tinydrm panels, but it turned out tinydrm didn't have the panel I had > previously bought. So, last night I ported the fbtft staging > driver over to DRM. > > It seems to work (with DT at > https://github.com/anholt/linux/commits/drm-misc-next-hx8357d) -- > fbdev works great including rotated, and so does modetest. However, > when X11 comes up at 16bpp, I get: > > https://photos.app.goo.gl/8tuhzPFFoDGamEfk8 > > If I have tinydrm set a preferred bpp of 24, X looks great. Noralf, > any ideas? Also, with these patches and the format modifier patch I just sent, mesa with vc4 is now working with this driver on this branch: https://gitlab.freedesktop.org/anholt/mesa/commits/kmsro Now I wonder how we can improve performance of the SPI updates. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tinydrm: Advertise that we can do only DRM_FORMAT_MOD_LINEAR.
Without this, the xserver relies on what the 3D driver exposes and
assumes that the display can handle it, and then the DRM driver
happily tries to scan out a tiled format.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_simple_kms_helper.c | 8
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 1 +
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 6 +-
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 51fa978f0d23..917812448d1b 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -190,6 +190,13 @@ static void drm_simple_kms_plane_cleanup_fb(struct
drm_plane *plane,
pipe->funcs->cleanup_fb(pipe, state);
}
+static bool drm_simple_kms_format_mod_supported(struct drm_plane *plane,
+ uint32_t format,
+ uint64_t modifier)
+{
+ return modifier == DRM_FORMAT_MOD_LINEAR;
+}
+
static const struct drm_plane_helper_funcs drm_simple_kms_plane_helper_funcs =
{
.prepare_fb = drm_simple_kms_plane_prepare_fb,
.cleanup_fb = drm_simple_kms_plane_cleanup_fb,
@@ -204,6 +211,7 @@ static const struct drm_plane_funcs
drm_simple_kms_plane_funcs = {
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+ .format_mod_supported = drm_simple_kms_format_mod_supported,
};
/**
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 255341ee4eb9..9af51d982a33 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -146,6 +146,7 @@ static int tinydrm_init(struct device *parent, struct
tinydrm_device *tdev,
drm->dev_private = tdev;
drm_mode_config_init(drm);
drm->mode_config.funcs = _mode_config_funcs;
+ drm->mode_config.allow_fb_modifiers = true;
return 0;
}
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index 7e8e24d0b7a7..eacfc0ec8ff1 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -184,6 +184,10 @@ tinydrm_display_pipe_init(struct tinydrm_device *tdev,
struct drm_display_mode mode_copy;
struct drm_connector *connector;
int ret;
+ static const uint64_t modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+ };
drm_mode_copy(_copy, mode);
ret = tinydrm_rotate_mode(_copy, rotation);
@@ -202,6 +206,6 @@ tinydrm_display_pipe_init(struct tinydrm_device *tdev,
return PTR_ERR(connector);
return drm_simple_display_pipe_init(drm, >pipe, funcs, formats,
- format_count, NULL, connector);
+ format_count, modifiers, connector);
}
EXPORT_SYMBOL(tinydrm_display_pipe_init);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/2] xf86drm: fallback to DRIVER uevent entry when OF_FULLNAME fails
Am Do., 25. Okt. 2018 um 15:35 Uhr schrieb Emil Velikov : > > On Thu, 18 Oct 2018 at 21:07, Christian Gmeiner > wrote: > > > > Signed-off-by: Christian Gmeiner > > --- > > xf86drm.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/xf86drm.c b/xf86drm.c > > index 10df682b..4ee1337b 100644 > > --- a/xf86drm.c > > +++ b/xf86drm.c > > @@ -3516,6 +3516,8 @@ static int drmParsePlatformBusInfo(int maj, int min, > > drmPlatformBusInfoPtr info) > > snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min); > > > > name = sysfs_uevent_get(path, "OF_FULLNAME"); > > +if (!name) > > +name = sysfs_uevent_get(path, "DRIVER"); > > This workaround will work for etnaviv, but not for all platform devices. > Personally, I'd recommend reverting the Mesa patch for now... I'm > checking with some kernel-savvy people how we can resolve thing > properly. I am fine with that - will prepare a revert patch. -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 4/4] ARM: dts: ccimx6ulsbcpro: Add support for Goodix touch controller
On Thu, Oct 25, 2018 at 12:10 PM Alex Gonzalez wrote: > > The ConnectCore 6UL SBC Pro has an AUO/Goodix LCD accessory kit that is > connected on the LVDS interface through an on-board LVDS transceiver. > > This change adds support for the touch interface. > > Signed-off-by: Alex Gonzalez Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/4] ARM: dts: ccimx6ulsbcpro: Enable AUO G101EVN010 lcdif panel
On Thu, Oct 25, 2018 at 12:11 PM Alex Gonzalez wrote:
>
> This change adds support for the AUO G101EVN010 lcdif panel for the
> mxsfb DRM driver.
>
> Signed-off-by: Alex Gonzalez
> ---
> arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> b/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> index 11966d12af76..f6e6b2cf780b 100644
> --- a/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> +++ b/arch/arm/boot/dts/imx6ul-ccimx6ulsbcpro.dts
> @@ -24,6 +24,18 @@
> status = "okay";
> };
>
> + panel {
> + compatible = "auo,g101evn010", "simple-panel";
The "simple-panel" string could be dropped.
Reviewed-by: Fabio Estevam
> + power-supply = <_ext>;
> + backlight = <_backlight>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +
> reg_usb_otg1_vbus: regulator-usb-otg1 {
> compatible = "regulator-fixed";
> regulator-name = "usb_otg1_vbus";
> @@ -112,6 +124,12 @@
> _lcdif_hvsync>;
> lcd-supply = <_ext>; /* BU90T82 LVDS bridge power */
> status = "okay";
> +
> + port {
> + display_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> };
>
> _ext {
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/4] ARM: imx_v6_v7_defconfig: Select TOUCHSCREEN_GOODIX
On Thu, Oct 25, 2018 at 12:11 PM Alex Gonzalez wrote: > > Select CONFIG_TOUCHSCREEN_GOODIX so that we can have functional touch > screen by default on Digi International's AUO/Goodix LCD accessory kit used > with the ConnectCore 6UL SBC Pro (ccimx6ulsbcpro) board. > > Signed-off-by: Alex Gonzalez Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108554] In kernel 4.14.59, monitor resolution is detected correctly. In kernels after that, they are not detected correctly.
https://bugs.freedesktop.org/show_bug.cgi?id=108554 Alex Deucher changed: What|Removed |Added CC||harry.wentl...@amd.com --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. Can you bisect? -- 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 108554] In kernel 4.14.59, monitor resolution is detected correctly. In kernels after that, they are not detected correctly.
https://bugs.freedesktop.org/show_bug.cgi?id=108554 Bug ID: 108554 Summary: In kernel 4.14.59, monitor resolution is detected correctly. In kernels after that, they are not detected correctly. Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: carav...@gmail.com Hello, Open bug in launchpad.net https://bugs.launchpad.net/bugs/1799613 "Booting from GRUB into 4.14.59 allows my two monitors to run at their native resolution, 2560x1440. Any newer kernel does not allow my two monitors to run at their native resolution, only allowing up to 1920x1200." Best regards, -- Cristian Aravena Romero (caravena) -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 Robert Strube changed: What|Removed |Added Attachment #142205|fresh dmesg log booting |fresh dmesg log booting description|system *wite* eGPU |system *with* eGPU |connected at boot |connected at boot -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #19 from Robert Strube --- Created attachment 142205 --> https://bugs.freedesktop.org/attachment.cgi?id=142205=edit fresh dmesg log booting system *wite* eGPU connected at boot -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #18 from Robert Strube --- Created attachment 142204 --> https://bugs.freedesktop.org/attachment.cgi?id=142204=edit sudo cat /proc/iomem *with* eGPU connected at boot -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #17 from Robert Strube --- Created attachment 142203 --> https://bugs.freedesktop.org/attachment.cgi?id=142203=edit lspci *with* eGPU attached at boot -- 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 14/20] drm/stm: Use drm_fbdev_generic_setup()
Den 27.09.2018 13.45, skrev Yannick FERTRE:
Hi Noralf,
many thanks for your patch.
Acked-by: Yannick Fertré
Applied to drm-misc-next, thanks.
Noralf.
On 09/08/2018 03:46 PM, Noralf Trønnes wrote:
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.
Cc: Yannick Fertre
Cc: Philippe Cornu
Cc: Benjamin Gaignard
Cc: Vincent Abriou
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/stm/drv.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index f2021b23554d..97eee8660014 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -26,7 +26,6 @@
static const struct drm_mode_config_funcs drv_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
- .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -52,7 +51,6 @@ DEFINE_DRM_GEM_CMA_FOPS(drv_driver_fops);
static struct drm_driver drv_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
DRIVER_ATOMIC,
- .lastclose = drm_fb_helper_lastclose,
.name = "stm",
.desc = "STMicroelectronics SoC DRM",
.date = "20170330",
@@ -108,12 +106,6 @@ static int drv_load(struct drm_device *ddev)
drm_mode_config_reset(ddev);
drm_kms_helper_poll_init(ddev);
- if (ddev->mode_config.num_connector) {
- ret = drm_fb_cma_fbdev_init(ddev, 16, 0);
- if (ret)
- DRM_DEBUG("Warning: fails to create fbdev\n");
- }
-
platform_set_drvdata(pdev, ddev);
return 0;
@@ -126,7 +118,6 @@ static void drv_unload(struct drm_device *ddev)
{
DRM_DEBUG("%s\n", __func__);
- drm_fb_cma_fbdev_fini(ddev);
drm_kms_helper_poll_fini(ddev);
ltdc_unload(ddev);
drm_mode_config_cleanup(ddev);
@@ -154,6 +145,8 @@ static int stm_drm_platform_probe(struct platform_device
*pdev)
if (ret)
goto err_put;
+ drm_fbdev_generic_setup(ddev, 16);
+
return 0;
err_put:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
Den 03.10.2018 21.24, skrev Neil Armstrong:
Hi Noralf,
Le 08/09/2018 15:46, Noralf Trønnes a écrit :
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Neil Armstrong
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/meson/meson_drv.c | 19 ++-
drivers/gpu/drm/meson/meson_drv.h | 1 -
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index d3443125e661..348b5a198b9d 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -68,15 +68,7 @@
* - Powering Up HDMI controller and PHY
*/
-static void meson_fb_output_poll_changed(struct drm_device *dev)
-{
- struct meson_drm *priv = dev->dev_private;
-
- drm_fbdev_cma_hotplug_event(priv->fbdev);
-}
-
static const struct drm_mode_config_funcs meson_mode_config_funcs = {
- .output_poll_changed = meson_fb_output_poll_changed,
.atomic_check= drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
.fb_create = drm_gem_fb_create,
@@ -282,13 +274,6 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
drm_mode_config_reset(drm);
- priv->fbdev = drm_fbdev_cma_init(drm, 32,
-drm->mode_config.num_connector);
- if (IS_ERR(priv->fbdev)) {
- ret = PTR_ERR(priv->fbdev);
- goto free_drm;
- }
-
drm_kms_helper_poll_init(drm);
platform_set_drvdata(pdev, priv);
@@ -297,6 +282,8 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
if (ret)
goto free_drm;
+ drm_fbdev_generic_setup(drm, 32);
+
return 0;
free_drm:
@@ -313,11 +300,9 @@ static int meson_drv_bind(struct device *dev)
static void meson_drv_unbind(struct device *dev)
{
struct drm_device *drm = dev_get_drvdata(dev);
- struct meson_drm *priv = drm->dev_private;
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
- drm_fbdev_cma_fini(priv->fbdev);
drm_mode_config_cleanup(drm);
drm_dev_put(drm);
diff --git a/drivers/gpu/drm/meson/meson_drv.h b/drivers/gpu/drm/meson/meson_drv.h
index 8450d6ac8c9b..aab96260da9f 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -33,7 +33,6 @@ struct meson_drm {
struct drm_device *drm;
struct drm_crtc *crtc;
- struct drm_fbdev_cma *fbdev;
struct drm_plane *primary_plane;
/* Components Data */
A little bit late to get this in 4.20 (or 5.0) and get rid of the old fbdev
code,
but at least we have a (dirty) workaround in place for the Mali fbdev blob...
Glad you found a solution for that!
Acked-by: Neil Armstrong
Thanks for pushing the fbdev emulation on the right path !
Applied to drm-misc-next, thanks.
Noralf.
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock
drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389
but uses GFP_KERNEL
Find functions that refer to GFP_KERNEL but are called with locks held.
Generated by: scripts/coccinelle/locks/call_kern.cocci
v2:
syncobj->timeline still needs protect.
v3:
use a global signaled fence instead of re-allocation.
v4:
Don't need moving lock.
Don't expose func.
Tested by: syncobj_wait and ./deqp-vk -n dEQP-VK.*semaphore* with
lock debug kernel options enabled.
Signed-off-by: Chunming Zhou
Cc: Maarten Lankhorst
Cc: intel-...@lists.freedesktop.org
Cc: Christian König
Cc: Chris Wilson
CC: Julia Lawall
---
drivers/gpu/drm/drm_syncobj.c | 41 ---
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index b7eaa603f368..fab0a2cf672e 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -80,6 +80,23 @@ struct drm_syncobj_signal_pt {
struct list_head list;
};
+static DEFINE_SPINLOCK(signaled_fence_lock);
+static struct dma_fence signaled_fence;
+
+static struct dma_fence *drm_syncobj_signaled_fence_get(void)
+{
+ spin_lock(_fence_lock);
+ if (!signaled_fence.ops) {
+ dma_fence_init(_fence,
+ _syncobj_stub_fence_ops,
+ _fence_lock,
+ 0, 0);
+ dma_fence_signal_locked(_fence);
+ }
+ spin_unlock(_fence_lock);
+
+ return dma_fence_get(_fence);
+}
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -111,24 +128,12 @@ static struct dma_fence
uint64_t point)
{
struct drm_syncobj_signal_pt *signal_pt;
+ struct dma_fence *f = NULL;
if ((syncobj->type == DRM_SYNCOBJ_TYPE_TIMELINE) &&
(point <= syncobj->timeline)) {
- struct drm_syncobj_stub_fence *fence =
- kzalloc(sizeof(struct drm_syncobj_stub_fence),
- GFP_KERNEL);
-
- if (!fence)
- return NULL;
- spin_lock_init(>lock);
- dma_fence_init(>base,
- _syncobj_stub_fence_ops,
- >lock,
- syncobj->timeline_context,
- point);
-
- dma_fence_signal(>base);
- return >base;
+ f = drm_syncobj_signaled_fence_get();
+ goto out;
}
list_for_each_entry(signal_pt, >signal_pt_list, list) {
@@ -137,9 +142,11 @@ static struct dma_fence
if ((syncobj->type == DRM_SYNCOBJ_TYPE_BINARY) &&
(point != signal_pt->value))
continue;
- return dma_fence_get(_pt->fence_array->base);
+ f = dma_fence_get(_pt->fence_array->base);
+ goto out;
}
- return NULL;
+out:
+ return f;
}
static void drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #16 from Robert Strube --- Created attachment 142202 --> https://bugs.freedesktop.org/attachment.cgi?id=142202=edit fresh dmesg log booting system *without* eGPU -- 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 201505] Resume from suspend does not power up the display
https://bugzilla.kernel.org/show_bug.cgi?id=201505 --- Comment #5 from Jan Ziak (http://atom-symbol.net) (0xe2.0x9a.0...@gmail.com) --- Created attachment 279151 --> https://bugzilla.kernel.org/attachment.cgi?id=279151=edit bisect.log I bisected the issue but encountered some inconsistencies along the way: - The bisected commit ends up with a white display after resume-from-suspend, while I was expecting a blank display. - I started bisecting with v4.18 good and v4.19 bad. The bisected commit has date 25 may 2018, while 4.18 has been released on 12 aug 2018. -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 Robert Strube changed: What|Removed |Added Attachment #142200|lspci (no eGPU) |lspci with eGPU *not* description||connected. -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #15 from Robert Strube --- Created attachment 142201 --> https://bugs.freedesktop.org/attachment.cgi?id=142201=edit sudo cat /proc/iomem when eGPU *not* connected sudo cat /proc/iomem when eGPU *not* connected -- 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 108521] RX 580 as eGPU amdgpu: gpu post error!
https://bugs.freedesktop.org/show_bug.cgi?id=108521 --- Comment #14 from Robert Strube --- Created attachment 142200 --> https://bugs.freedesktop.org/attachment.cgi?id=142200=edit lspci (no eGPU) lspci -t -nn -v output when the eGPU is *not* connected. -- 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 108318] [Polaris] Glitches in New Super Mario Brothers U in Cemu on Polaris and Tahiti (maybe more)
https://bugs.freedesktop.org/show_bug.cgi?id=108318 --- Comment #9 from John Galt --- R600_DEBUG=nir works around this issue. If requested, I can provide apidoc of this rendering issue. -- 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
