Re: [PATCH 0/8] xen: dma-buf support for grant device
On 05/31/2018 11:25 PM, Boris Ostrovsky wrote:
On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote:
On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
Oleksandr Andrushchenko (8):
xen/grant-table: Make set/clear page private code shared
xen/balloon: Move common memory reservation routines to a module
xen/grant-table: Allow allocating buffers suitable for DMA
xen/gntdev: Allow mappings for DMA buffers
xen/gntdev: Add initial support for dma-buf UAPI
xen/gntdev: Implement dma-buf export functionality
xen/gntdev: Implement dma-buf import functionality
xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
drivers/xen/Kconfig | 23 +
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 71 +--
drivers/xen/gntdev.c | 1025
-
I think this calls for gntdev_dma.c.
I assume you mean as a separate file (part of gntdev driver)?
I only had a quick look over gntdev changes but they very much are
concentrated in dma-specific routines.
I tried to do that, but there are some dependencies between the
gntdev.c and gntdev_dma.c,
so finally I decided to put it all together.
You essentially only share file_operations entry points with
original gntdev code, right?
fops + mappings done by gntdev (struct grant_map) and I need to
release map on dma_buf .release
callback which makes some cross-dependencies between modules which
seemed to be not cute
(gntdev keeps its all structs and functions inside, so I cannot
easily access those w/o
helpers).
But I'll try one more time and move all DMA specific stuff into
gntdev_dma.c
Could you please take a quick look at the way I re-structured the
sources here [1]?
If this is what you meant.
I looked at final gntdev.c code and I think at least one of the chunks
there ("DMA buffer export support. ") can also be moved out. It still
have a bit too many ifdefs but it looks better to my eye than jamming
everything into a single file (and I think more code can be moved out,
but we can talk about it when you post the patches so that we can see
context).
Sure, will send v2 after I re-check all the patches
and run some smoke tests again
BTW, I believe it won't build with !CONFIG_XEN_GNTDEV_DMABUF ---
gntdev_remove_map() is defined under this option and is referenced later
without it.
Will check, thank you
-boris
Thank you,
Oleksandr
-boris
Thank you,
Oleksandr
drivers/xen/grant-table.c | 176 +-
drivers/xen/mem-reservation.c | 134 +
include/uapi/xen/gntdev.h | 106
include/xen/grant_dev.h | 37 ++
include/xen/grant_table.h | 28 +
include/xen/mem_reservation.h | 29 +
10 files changed, 1527 insertions(+), 103 deletions(-)
create mode 100644 drivers/xen/mem-reservation.c
create mode 100644 include/xen/grant_dev.h
create mode 100644 include/xen/mem_reservation.h
[1]
https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
On Fri, Jun 1, 2018 at 2:04 AM, Keith Packard wrote: > Eric Anholt writes: > >> Just wait for all tasks to complete when any object is freed? That's >> going to be bad for performance. Or are you saying that you already >> have the connection between the task and its objects (and, if so, why >> aren't you just doing refcounting correctly through that path?) > > How about wait on close of the DRM device? Yeah, that's what this patch for: get preclose back and do task wait in it before free buffers. I still think this is best way in my case (and may be other drivers). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
On Fri, Jun 1, 2018 at 1:51 AM, Eric Anholt wrote: > Qiang Yu writes: > It is OK if evil user free/unmap the buffer when task is not done in my implementation. It will generate a MMU fault in that case and kernel driver will do recovery. So does the Ctrl+C case, if don't deal with it, just get some noisy MMU fault warning and a HW reset recovery. >>> >>> How about an app rendering to shared buffers, which glFlush()es and >>> exits cleanly but doesn't close the DRI screen? What would cause that >>> app's rendering to get completed succesfully instead of faulting to >>> death? >> Do you mean the same case as Ctrl+C when an app exit without waiting >> all task finished in userspace? > > Basically the same, but I'm saying that the app is doing everything > right and terminating successfully, rather than being interrupted (which > you might otherwise use to justify its rendering failing) I won't justify Ctrl+C. In fact I think it's also a good case which should not get a MMU fault and GPU reset because it happens even user sapce driver is right. I only think when user driver is not right deserve a MMU fault like bug/evil code which free/unmap bo before task done. I think this is also the difference of user free bo and drm close free bo in my case. > >>> You really do need to refcount the buffers used in a rendering job so >>> they don't get freed early. >> Do you mean refcount the buffers in kernel space job? This is OK but >> not necessary, I can wait task complete in gem_close_object which >> will be called by drm_release for each buffer too (I still think better >> waiting in preclose at once but it's gone). > > Just wait for all tasks to complete when any object is freed? That's > going to be bad for performance. In my case this doesn't affect performance. My implementation is user space driver will record task buffers and free them when task done. So in normal usage when the buffer is freed, there should be no task from this process using it. Wait should only happen when Ctrl+C and not close screen case. > Or are you saying that you already > have the connection between the task and its objects (and, if so, why > aren't you just doing refcounting correctly through that path?) This is by the reservation object of the buffer, I can wait on the fences in the reservation object for task done when buffer free. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106763] thunderbolt 3-way split corruption using OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=106763 Carlos Licea changed: What|Removed |Added Summary|thunderbolt 3-way split |thunderbolt 3-way split |corruption |corruption using OpenGL -- 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 106763] thunderbolt 3-way split corruption
https://bugs.freedesktop.org/show_bug.cgi?id=106763 Bug ID: 106763 Summary: thunderbolt 3-way split corruption Product: Mesa Version: 18.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 Assignee: dri-devel@lists.freedesktop.org Reporter: c...@carloslicea.com QA Contact: dri-devel@lists.freedesktop.org Pluging a 3rd monitor using a thunderbolt to Dual DisplayPort adapter https://www.amazon.com/gp/product/B01DYFI1OE It works well on XRender but when I try to enable OpenGL support (either 3.1 or 2.0) it mirrors and corrupts all displays. I'm using manjaro. Here's a quick hardware dump: ''' $ inxi -Fxzc0 System:Host: io Kernel: 4.14.44-1-MANJARO x86_64 bits: 64 compiler: gcc v: 8.1.0 Desktop: KDE Plasma 5.12.5 tk: Qt 5.10.1 Distro: Manjaro Linux 17.1.10 Hakoila Machine: Type: Laptop System: Dell product: XPS 15 9560 v: N/A serial: N/A Mobo: Dell model: 05FFDN v: A00 serial: N/A UEFI: Dell v: 1.6.2 date: 11/12/2017 Battery: ID-1: BAT0 charge: 88.1 Wh condition: 88.1/97.0 Wh (91%) model: SMP DELL GPM0365 status: Full CPU: Topology: Quad Core model: Intel Core i7-7700HQ bits: 64 type: MT MCP arch: Skylake rev: 9 L2 cache: 6144 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 44944 Speed: 3339 MHz min/max: 800/3800 MHz Core speeds (MHz): 1: 3373 2: 3400 3: 3400 4: 3400 5: 3400 6: 3400 7: 3400 8: 3400 Graphics: Card-1: Intel driver: i915 v: kernel bus ID: 00:02.0 Card-2: NVIDIA GP107M [GeForce GTX 1050 Mobile] driver: N/A bus ID: 01:00.0 Display: x11 server: X.Org 1.19.6 driver: intel unloaded: fbdev,modesetting,vesa resolution: 3840x2160~60Hz, 3840x2160~60Hz OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 4.5 Mesa 18.0.4 direct render: Yes Audio: Card-1: Intel CM238 HD Audio driver: snd_hda_intel v: kernel bus ID: 00:1f.3 Sound Server: ALSA v: k4.14.44-1-MANJARO Network: Card-1: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter driver: ath10k_pci v: kernel bus ID: 02:00.0 IF: wlp2s0 state: up mac: Card-2: Qualcomm Atheros type: USB driver: btusb bus ID: 1:2 IF-ID-1: br-abd3c2b482b1 state: down mac: IF-ID-2: br-b7b4ade7beae state: down mac: IF-ID-3: br-ca990f09811e state: down mac: IF-ID-4: docker0 state: down mac: Drives:HDD Total Size: 592.63 GiB used: 179.60 GiB (30.3%) ID-1: /dev/nvme0n1 model: KXG50ZNV512G NVMe TOSHIBA 512GB size: 476.94 GiB ID-2: /dev/sda type: USB vendor: SanDisk model: Ultra Fit size: 115.69 GiB Partition: ID-1: / size: 451.35 GiB used: 135.05 GiB (29.9%) fs: ext4 dev: /dev/dm-0 ID-2: swap-1 size: 17.07 GiB used: 57.6 MiB (0.3%) fs: swap dev: /dev/dm-1 Sensors: System Temperatures: cpu: 66.0 C mobo: 50.0 C Fan Speeds (RPM): cpu: 3220 Info: Processes: 222 Uptime: 22h 49m Memory: 15.52 GiB used: 4.58 GiB (29.5%) Init: systemd Compilers: gcc: 8.1.0 Shell: bash v: 4.4.19 inxi: 3.0.08 ''' This problem is reproducible with KWin and Gnome Shell (this later using X11 and Wayland). Initial thread on Manjaro https://bugs.kde.org/show_bug.cgi?id=394900 Bug against KWin https://bugs.kde.org/show_bug.cgi?id=394900 Please let me know what information may I provide to reproduce this error. -- 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 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g
https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #31 from Francisco Pina Martins --- I have used [this PKGBUILD](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux-amd-staging-drm-next-git) to build the kernel. Albeit considering the version number it looks more like linux-4.17 than 4.16. The commit I checked out was 46c04bb3e028217255b578cc6101823e9fbc11bc. I will investigate further and try checking out at commit a0f282dcdb1775cbcc0a151570fc01c0aae5ca0f and see if there is any other difference in the build. The fact that you did not require the patch makes me think I'm doing something fundamentally different from you. -- 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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #76 from MirceaKitsune --- (In reply to iive from comment #75) That's what I feared too: I know Mesa depends on a lot of other libraries (including LLVM) and you can't mix old and new versions between them. This is my primary desktop on which I do all my activities, so I can't risk breaking it nor downgrade the whole OS to an ancient version. A live DVD would solve this however. Unfortunately I don't know how far I can still find those for openSUSE, nor what the last openSUSE release was that came with Mesa 13 instead of 17. Does anyone else have this information? As a side note, I should mention that I'm now in the process of trying to obtain a new video card: This couldn't be investigated in several months and I can't wait much longer. Once I get a new card, I might not be able to continue this test any more. I may still ask a friend to try my video card in Windows, just so we at least know if this was a combination of bad hardware or the devs should still be on the lookout for an obscure driver bug. -- 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][next] drm/amdgpu/df: fix potential array out-of-bounds read
On Wed, May 30, 2018 at 12:41 PM, Colin King wrote:
> From: Colin Ian King
>
> The comparison with the number of elements in array df_v3_7_channel_number
> is off-by-one and can produce an array out-of-bounds read if
> fb_channel_number is equal to the number of elements of the array. Fix
> this by changing the comparison to >= instead of >.
>
> Detected by CoverityScan, CID#1469489 ("Out-of-bounds read")
>
> Fixes: 13b581502d51 ("drm/amdgpu/df: implement df v3_6 callback functions
> (v2)")
> Signed-off-by: Colin Ian King
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
> b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
> index 60608b3df881..d5ebe566809b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
> +++ b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
> @@ -64,7 +64,7 @@ static u32 df_v3_6_get_hbm_channel_number(struct
> amdgpu_device *adev)
> int fb_channel_number;
>
> fb_channel_number = adev->df_funcs->get_fb_channel_number(adev);
> - if (fb_channel_number > ARRAY_SIZE(df_v3_6_channel_number))
> + if (fb_channel_number >= ARRAY_SIZE(df_v3_6_channel_number))
> fb_channel_number = 0;
>
> return df_v3_6_channel_number[fb_channel_number];
> --
> 2.17.0
>
> ___
> 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
[pull] amdgpu and scheduler drm-next-4.18
Hi Dave, Fixes for 4.18. Highlights: - Improve DC/powerplay interface to allow additional power savings on vega - DP 1.4 compliance fixes - Various vega20 fixes - Fix for DC scale ratios - Per vm bo fixes - Scheduler dependency corner case fix - Misc bug fixes The following changes since commit dd41fb8547c2422f3a3a75e7226525e8bba9381c: Merge branch 'drm-next-4.18' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-05-25 10:28:33 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.18 for you to fetch changes up to 7ba01f9e12bb3f088f617cf69b589ea37bd5d6ed: drm/amdgpu: Fix NULL pointer when load kfd driver with PP block is disabled (2018-05-31 14:08:54 -0500) Alex Deucher (1): drm/amdgpu/display: check if ppfuncs exists before using it Charlene Liu (1): drm/amd/display: add register offset != 0 check. Chunming Zhou (1): drm/amdgpu: gds bo must not be per-vm-bo Deepak Sharma (2): drm/amdgpu: Use GTT for dumb buffer if sg display enabled (v2) drm/amdgpu: Add helper function to get buffer domain Dmytro Laktyushkin (1): drm/amd/display: fix dscl_manual_ratio_init Emily Deng (1): drm/amdgpu: To get gds, gws and oa from adev->gds (v2) Eric Bernstein (2): drm/amd/display: DP component depth 16 bpc drm/amd/display: Set TMZ and DCC for secondary surface Evan Quan (3): drm/amdgpu: correct SMU11 SYSPLL0 clock id values drm/amd/powerplay: bug fixs for getsmuclockinfo drm/amdgpu: typo fix for vega20 cg flags Feifei Xu (1): drm/gfx9: Update gc goldensetting for vega20. Harry Wentland (2): drm/amd/display: Implement dm_pp_get_clock_levels_by_type_with_latency drm/amd/display: Fix wrong latency assignment for VEGA clock levels Leo (Sunpeng) Li (2): drm/amd/display: Destroy connector state on reset drm/amd/display: Fix BUG_ON during CRTC atomic check update Leo Liu (1): drm/amdgpu: remove unnecessary scheduler entity for VCN Mikita Lipski (5): drm/amd/pp: Add cases for getting phys and disp clks for SMU10 drm/amd/display: Do not limit color depth to 8bpc drm/amd/display: Release fake sink drm/amd/display: Do not program interrupt status on disabled crtc drm/amd/pp: Connect display_clock_voltage_request to a function pointer Nayan Deshmukh (1): drm/scheduler: fix a corner case in dependency optimization Nikola Cornij (2): drm/amd/display: Read DPCD link caps up to and including DP_ADAPTER_CAP drm/amd/display: Read DP_SINK_COUNT_ESI range on HPD for DP 1.4 Rex Zhu (1): drm/amd/pp: Allow underclocking when od table is empty in vbios Roman Li (2): drm/amd/display: replace msleep with udelay in fbc path drm/amd/display: check if audio clk enable is applicable Shaoyun Liu (1): drm/amdgpu: Fix NULL pointer when load kfd driver with PP block is disabled kbuild test robot (1): drm/amdgpu: vcn_v1_0_is_idle() can be static drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 18 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 38 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 15 - drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 17 -- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 51 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h| 2 - drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 + drivers/gpu/drm/amd/amdgpu/soc15.c | 1 + drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 4 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 56 + .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 3 + .../drm/amd/display/amdgpu_dm/amdgpu_dm_services.c | 45 +- drivers/gpu/drm/amd/display/dc/basics/fixpt31_32.c | 5 ++ drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 37 ++-- .../drm/amd/display/dc/dce/dce_stream_encoder.c| 6 +- .../drm/amd/display/dc/dce110/dce110_compressor.c | 8 +-- .../amd/display/dc/dce110/dce110_hw_sequencer.c| 2 +- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c | 3 +- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h | 6 +- .../gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c | 8 +-- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c | 14 +++-- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.h | 8 +++ .../amd/display/dc/dcn10/dcn10_stream_encoder.c| 4 ++ drivers/gpu/drm/amd/display/include/fixed31_32.h | 2 + drivers/gpu/drm/amd/include/atomfirmware.h | 12 ++-- drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c | 4 +- .../amd/powerplay/hwmgr/process_pptables_v1_0.c| 6 -- .../gpu/drm/amd/powerplay/hwmgr/processpptables.c | 6 -- drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 70 --
[pull] amdgpu drm-fixes-4.17
Hi Dave, Two last minute DC fixes for 4.17. A fix for underscan on fiji and a fix for gamma settings getting after dpms. The following changes since commit 0e333751cff1dd7383be15372960a1be6e2b4e47: Merge tag 'drm-misc-fixes-2018-05-30' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2018-05-31 08:35:47 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.17 for you to fetch changes up to bc13f2f88eae63af943ab967cb14bb602f8f2eeb: drm/amd/display: Update color props when modeset is required (2018-05-31 13:08:26 -0500) David Francis (1): drm/amd/display: Make atomic-check validate underscan changes Leo (Sunpeng) Li (1): drm/amd/display: Update color props when modeset is required drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 31 --- 1 file changed, 22 insertions(+), 9 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
Eric Anholt writes: > Just wait for all tasks to complete when any object is freed? That's > going to be bad for performance. Or are you saying that you already > have the connection between the task and its objects (and, if so, why > aren't you just doing refcounting correctly through that path?) How about wait on close of the DRM device? -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
On 30/05/18 15:06, Thierry Reding wrote:
From: Thierry Reding
Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that transparently uses
the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
backed buffers (a special bit in the GPU's MMU page tables indicates the
memory path to take: via the SMMU or directly to the memory controller).
Transparently backing DMA memory with an IOMMU prevents Nouveau from
properly handling such memory accesses and causes memory access faults.
As a side-note: buffers other than those allocated in instance memory
don't need to be physically contiguous from the GPU's perspective since
the GPU can map them into contiguous buffers using its own MMU. Mapping
these buffers through the IOMMU is unnecessary and will even lead to
performance degradation because of the additional translation. One
exception to this are compressible buffers which need large pages. In
order to enable these large pages, multiple small pages will have to be
combined into one large (I/O virtually contiguous) mapping via the
IOMMU. However, that is a topic outside the scope of this fix and isn't
currently supported. An implementation will want to explicitly create
these large pages in the Nouveau driver, so detaching from a DMA/IOMMU
mapping would still be required.
Signed-off-by: Thierry Reding
---
Changes in v4:
- use existing APIs to detach from a DMA/IOMMU mapping
Changes in v3:
- clarify the use of IOMMU mapping for compressible buffers
- squash multiple patches into this
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index 78597da6313a..0e372a190d3f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -23,6 +23,10 @@
#ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
#include "priv.h"
+#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
+#include
+#endif
+
static int
nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
{
@@ -105,6 +109,15 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
unsigned long pgsize_bitmap;
int ret;
+#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
+ if (dev->archdata.mapping) {
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
Nit: there's arguably little point using the helper here after you've
already shattered the illusion by poking dev->archdata.mapping directly,
but I guess this disappears again anyway once the refcounting gets
sorted out and the mapping releases itself properly, so:
Reviewed-by: Robin Murphy
+
+ arm_iommu_detach_device(dev);
+ arm_iommu_release_mapping(mapping);
+ }
+#endif
+
if (!tdev->func->iommu_bit)
return;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()
On 30/05/18 15:06, Thierry Reding wrote:
From: Thierry Reding
Instead of setting the DMA ops pointer to NULL, set the correct,
non-IOMMU ops depending on the device's coherency setting.
It looks like it's probably been 4 or 5 years since that became subtly
wrong by virtue of the landscape changing around it, but it's clearly
not enough of a problem to consider stable backports :)
Reviewed-by: Robin Murphy
Signed-off-by: Thierry Reding
---
Changes in v4:
- new patch to fix existing arm_iommu_detach_device() to do what we need
arch/arm/mm/dma-mapping.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index af27f1c22d93..87a0037574e4 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1151,6 +1151,11 @@ int arm_dma_supported(struct device *dev, u64 mask)
return __dma_supported(dev, mask, false);
}
+static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
+{
+ return coherent ? _coherent_dma_ops : _dma_ops;
+}
+
#ifdef CONFIG_ARM_DMA_USE_IOMMU
static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs)
@@ -2296,7 +2301,7 @@ void arm_iommu_detach_device(struct device *dev)
iommu_detach_device(mapping->domain, dev);
kref_put(>kref, release_iommu_mapping);
to_dma_iommu_mapping(dev) = NULL;
- set_dma_ops(dev, NULL);
+ set_dma_ops(dev, arm_get_dma_map_ops(dev->archdata.dma_coherent));
pr_debug("Detached IOMMU controller from %s device.\n", dev_name(dev));
}
@@ -2357,11 +2362,6 @@ static void arm_teardown_iommu_dma_ops(struct device
*dev) { }
#endif /* CONFIG_ARM_DMA_USE_IOMMU */
-static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
-{
- return coherent ? _coherent_dma_ops : _dma_ops;
-}
-
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
const struct iommu_ops *iommu, bool coherent)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
Qiang Yu writes: >>> >>> It is OK if evil user free/unmap the buffer when task is not done >>> in my implementation. It will generate a MMU fault in that case and kernel >>> driver will do recovery. >>> >>> So does the Ctrl+C case, if don't deal with it, just get some noisy MMU >>> fault warning and a HW reset recovery. >> >> How about an app rendering to shared buffers, which glFlush()es and >> exits cleanly but doesn't close the DRI screen? What would cause that >> app's rendering to get completed succesfully instead of faulting to >> death? > Do you mean the same case as Ctrl+C when an app exit without waiting > all task finished in userspace? Basically the same, but I'm saying that the app is doing everything right and terminating successfully, rather than being interrupted (which you might otherwise use to justify its rendering failing) >> You really do need to refcount the buffers used in a rendering job so >> they don't get freed early. > Do you mean refcount the buffers in kernel space job? This is OK but > not necessary, I can wait task complete in gem_close_object which > will be called by drm_release for each buffer too (I still think better > waiting in preclose at once but it's gone). Just wait for all tasks to complete when any object is freed? That's going to be bad for performance. Or are you saying that you already have the connection between the task and its objects (and, if so, why aren't you just doing refcounting correctly through that path?) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 86351] HDMI audio garbled output on Radeon R9 280X
https://bugzilla.kernel.org/show_bug.cgi?id=86351 --- Comment #33 from Christian Birchinger (jo...@netswarm.net) --- Seems like the issue was only gone because i've also played a video. With only the desktop open on the HDMI screen audio is still broken. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/doc: Add a label for the PRIME Buffer Sharing chapter
From: Michel Dänzer So that it can be referenced from e.g. DOC comments. Signed-off-by: Michel Dänzer --- Documentation/gpu/drm-mm.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 96ebcc2a7b41..21b6b72a9ba8 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -395,6 +395,8 @@ VMA Offset Manager .. kernel-doc:: drivers/gpu/drm/drm_vma_manager.c :export: +.. _prime_buffer_sharing: + PRIME Buffer Sharing -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/amdgpu: Add documentation for PRIME related code
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
Documentation/gpu/amdgpu.rst | 14 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 119 ++
2 files changed, 133 insertions(+)
diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
index 41a14e4aa4ac..f557866f6788 100644
--- a/Documentation/gpu/amdgpu.rst
+++ b/Documentation/gpu/amdgpu.rst
@@ -4,3 +4,17 @@
The drm/amdgpu driver supports all AMD Radeon GPUs based on the Graphics Core
Next (GCN) architecture.
+
+Core Driver Infrastructure
+==
+
+This section covers core driver infrastructure.
+
+PRIME Buffer Sharing
+
+
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+ :doc: PRIME Buffer Sharing
+
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+ :internal:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 4683626b065f..d1f05489595b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -23,6 +23,14 @@
*
* Authors: Alex Deucher
*/
+
+/**
+ * DOC: PRIME Buffer Sharing
+ *
+ * The following callback implementations are used for :ref:`sharing GEM buffer
+ * objects between different devices via PRIME `.
+ */
+
#include
#include "amdgpu.h"
@@ -32,6 +40,14 @@
static const struct dma_buf_ops amdgpu_dmabuf_ops;
+/**
+ * amdgpu_gem_prime_get_sg_table - _driver.gem_prime_get_sg_table
+ * implementation
+ * @obj: GEM buffer object
+ *
+ * Returns:
+ * A scatter/gather table for the pinned pages of the buffer object's memory.
+ */
struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
{
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
@@ -40,6 +56,15 @@ struct sg_table *amdgpu_gem_prime_get_sg_table(struct
drm_gem_object *obj)
return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
}
+/**
+ * amdgpu_gem_prime_vmap - _buf_ops.vmap implementation
+ * @obj: GEM buffer object
+ *
+ * Sets up an in-kernel virtual mapping of the buffer object's memory.
+ *
+ * Returns:
+ * The virtual address of the mapping or an error pointer.
+ */
void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj)
{
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
@@ -53,6 +78,13 @@ void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj)
return bo->dma_buf_vmap.virtual;
}
+/**
+ * amdgpu_gem_prime_vunmap - _buf_ops.vunmap implementation
+ * @obj: GEM buffer object
+ * @vaddr: virtual address (unused)
+ *
+ * Tears down the in-kernel virtual mapping of the buffer object's memory.
+ */
void amdgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
{
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
@@ -60,6 +92,17 @@ void amdgpu_gem_prime_vunmap(struct drm_gem_object *obj,
void *vaddr)
ttm_bo_kunmap(>dma_buf_vmap);
}
+/**
+ * amdgpu_gem_prime_mmap - _driver.gem_prime_mmap implementation
+ * @obj: GEM buffer object
+ * @vma: virtual memory area
+ *
+ * Sets up a userspace mapping of the buffer object's memory in the given
+ * virtual memory area.
+ *
+ * Returns:
+ * 0 on success or negative error code.
+ */
int amdgpu_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct
*vma)
{
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
@@ -94,6 +137,19 @@ int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma
return ret;
}
+/**
+ * amdgpu_gem_prime_import_sg_table - _driver.gem_prime_import_sg_table
+ * implementation
+ * @dev: DRM device
+ * @attach: DMA-buf attachment
+ * @sg: Scatter/gather table
+ *
+ * Import shared DMA buffer memory exported by another device.
+ *
+ * Returns:
+ * A new GEM buffer object of the given DRM device, representing the memory
+ * described by the given DMA-buf attachment and scatter/gather table.
+ */
struct drm_gem_object *
amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
@@ -132,6 +188,19 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
}
+/**
+ * amdgpu_gem_map_attach - _buf_ops.attach implementation
+ * @dma_buf: shared DMA buffer
+ * @target_dev: target device
+ * @attach: DMA-buf attachment
+ *
+ * Makes sure that the shared DMA buffer can be accessed by the target device.
+ * For now, simply pins it to the GTT domain, where it should be accessible by
+ * all DMA devices.
+ *
+ * Returns:
+ * 0 on success or negative error code.
+ */
static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
struct device *target_dev,
struct dma_buf_attachment *attach)
@@ -181,6 +250,14 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
return r;
}
+/**
+ * amdgpu_gem_map_detach - _buf_ops.detach implementation
+ * @dma_buf: shared DMA buffer
+ * @attach: DMA-buf attachment
+ *
+ * This is called
[PATCH 2/3] drm/doc: Add initial amdgpu driver documentation
From: Michel Dänzer Signed-off-by: Michel Dänzer --- Documentation/gpu/amdgpu.rst | 6 ++ Documentation/gpu/drivers.rst | 1 + 2 files changed, 7 insertions(+) create mode 100644 Documentation/gpu/amdgpu.rst diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst new file mode 100644 index ..41a14e4aa4ac --- /dev/null +++ b/Documentation/gpu/amdgpu.rst @@ -0,0 +1,6 @@ += + drm/amdgpu AMDgpu driver += + +The drm/amdgpu driver supports all AMD Radeon GPUs based on the Graphics Core +Next (GCN) architecture. diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index e8c84419a2a1..604b6d6975af 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -4,6 +4,7 @@ GPU Driver Documentation .. toctree:: + amdgpu i915 meson pl111 -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
> +#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
> + if (dev->archdata.mapping) {
> + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> +
> + arm_iommu_detach_device(dev);
> + arm_iommu_release_mapping(mapping);
> + }
> +#endif
Having this hidden in a helper would be nicer, but anything that
doesn't directly expose the dma_map_ops to a driver is fine with me.
So from the dma-mapping POV:
Acked-by: Christoph Hellwig
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/blend: Add per-plane pixel blend mode property
Hi Lowry, Small drive-by suggestion. Haven't checked if others have pointed it out previously :-\ On 30 May 2018 at 12:23, Lowry Li wrote: > +/** > + * drm_plane_create_blend_mode_property - create a new blend mode property > + * @plane: drm plane > + * @supported_modes: bitmask of supported modes, must include > + * BIT(DRM_MODE_BLEND_PREMULTI) > + * There are two possible blend modes (ignoring 'none'), yet premult must be supported. What if the hardware can do only "coverage"? One-liner explaining why things are as-is would be a great move. HTH Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] xen: dma-buf support for grant device
On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote: On 05/31/2018 04:46 AM, Boris Ostrovsky wrote: On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: Oleksandr Andrushchenko (8): xen/grant-table: Make set/clear page private code shared xen/balloon: Move common memory reservation routines to a module xen/grant-table: Allow allocating buffers suitable for DMA xen/gntdev: Allow mappings for DMA buffers xen/gntdev: Add initial support for dma-buf UAPI xen/gntdev: Implement dma-buf export functionality xen/gntdev: Implement dma-buf import functionality xen/gntdev: Expose gntdev's dma-buf API for in-kernel use drivers/xen/Kconfig | 23 + drivers/xen/Makefile | 1 + drivers/xen/balloon.c | 71 +-- drivers/xen/gntdev.c | 1025 - I think this calls for gntdev_dma.c. I assume you mean as a separate file (part of gntdev driver)? I only had a quick look over gntdev changes but they very much are concentrated in dma-specific routines. I tried to do that, but there are some dependencies between the gntdev.c and gntdev_dma.c, so finally I decided to put it all together. You essentially only share file_operations entry points with original gntdev code, right? fops + mappings done by gntdev (struct grant_map) and I need to release map on dma_buf .release callback which makes some cross-dependencies between modules which seemed to be not cute (gntdev keeps its all structs and functions inside, so I cannot easily access those w/o helpers). But I'll try one more time and move all DMA specific stuff into gntdev_dma.c Could you please take a quick look at the way I re-structured the sources here [1]? If this is what you meant. Thank you, Oleksandr -boris Thank you, Oleksandr drivers/xen/grant-table.c | 176 +- drivers/xen/mem-reservation.c | 134 + include/uapi/xen/gntdev.h | 106 include/xen/grant_dev.h | 37 ++ include/xen/grant_table.h | 28 + include/xen/mem_reservation.h | 29 + 10 files changed, 1527 insertions(+), 103 deletions(-) create mode 100644 drivers/xen/mem-reservation.c create mode 100644 include/xen/grant_dev.h create mode 100644 include/xen/mem_reservation.h [1] https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] xen/gntdev: Implement dma-buf export functionality
On 05/31/2018 08:55 AM, Oleksandr Andrushchenko wrote:
On 05/31/2018 02:10 AM, Dongwon Kim wrote:
On Fri, May 25, 2018 at 06:33:29PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
corresponding dma_alloc_xxx API.
Export the resulting buffer as a new dma-buf.
2. Implement waiting for the dma-buf to be released: block until the
dma-buf with the file descriptor provided is released.
If within the time-out provided the buffer is not released then
-ETIMEDOUT error is returned. If the buffer with the file
descriptor
does not exist or has already been released, then -ENOENT is
returned.
For valid file descriptors this must not be treated as error.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c | 478
++-
1 file changed, 476 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 9e450622af1a..52abc6cd5846 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -4,6 +4,8 @@
* Device for accessing (in user-space) pages that have been
granted by other
* domains.
*
+ * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
+ *
* Copyright (c) 2006-2007, D G Murray.
* (c) 2009 Gerd Hoffmann
* (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
@@ -41,6 +43,9 @@
#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
#include
#endif
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+#include
+#endif
#include
#include
@@ -81,6 +86,17 @@ struct gntdev_priv {
/* Device for which DMA memory is allocated. */
struct device *dma_dev;
#endif
+
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ /* Private data of the hyper DMA buffers. */
+
+ /* List of exported DMA buffers. */
+ struct list_head dmabuf_exp_list;
+ /* List of wait objects. */
+ struct list_head dmabuf_exp_wait_list;
+ /* This is the lock which protects dma_buf_xxx lists. */
+ struct mutex dmabuf_lock;
+#endif
};
struct unmap_notify {
@@ -125,12 +141,38 @@ struct grant_map {
#ifdef CONFIG_XEN_GNTDEV_DMABUF
struct xen_dmabuf {
+ struct gntdev_priv *priv;
+ struct dma_buf *dmabuf;
+ struct list_head next;
+ int fd;
+
union {
+ struct {
+ /* Exported buffers are reference counted. */
+ struct kref refcount;
+ struct grant_map *map;
+ } exp;
struct {
/* Granted references of the imported buffer. */
grant_ref_t *refs;
} imp;
} u;
+
+ /* Number of pages this buffer has. */
+ int nr_pages;
+ /* Pages of this buffer. */
+ struct page **pages;
+};
+
+struct xen_dmabuf_wait_obj {
+ struct list_head next;
+ struct xen_dmabuf *xen_dmabuf;
+ struct completion completion;
+};
+
+struct xen_dmabuf_attachment {
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
};
#endif
@@ -320,6 +362,16 @@ static void gntdev_put_map(struct gntdev_priv
*priv, struct grant_map *map)
gntdev_free_map(map);
}
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+static void gntdev_remove_map(struct gntdev_priv *priv, struct
grant_map *map)
+{
+ mutex_lock(>lock);
+ list_del(>next);
+ gntdev_put_map(NULL /* already removed */, map);
+ mutex_unlock(>lock);
+}
+#endif
+
/*
-- */
static int find_grant_ptes(pte_t *pte, pgtable_t token,
@@ -628,6 +680,12 @@ static int gntdev_open(struct inode *inode,
struct file *flip)
INIT_LIST_HEAD(>freeable_maps);
mutex_init(>lock);
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ mutex_init(>dmabuf_lock);
+ INIT_LIST_HEAD(>dmabuf_exp_list);
+ INIT_LIST_HEAD(>dmabuf_exp_wait_list);
+#endif
+
if (use_ptemod) {
priv->mm = get_task_mm(current);
if (!priv->mm) {
@@ -1053,17 +,433 @@ static long gntdev_ioctl_grant_copy(struct
gntdev_priv *priv, void __user *u)
/* DMA buffer export
support. */
/*
-- */
+/*
-- */
+/* Implementation of wait for exported DMA buffer to be
released. */
+/*
-- */
+
+static void dmabuf_exp_release(struct kref *kref);
+
+static struct xen_dmabuf_wait_obj *
+dmabuf_exp_wait_obj_new(struct gntdev_priv *priv,
+ struct xen_dmabuf *xen_dmabuf)
+{
+ struct xen_dmabuf_wait_obj *obj;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ init_completion(>completion);
+ obj->xen_dmabuf =
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/31/2018 10:51 AM, Oleksandr Andrushchenko wrote:
On 05/30/2018 10:24 PM, Boris Ostrovsky wrote:
On 05/30/2018 01:46 PM, Oleksandr Andrushchenko wrote:
On 05/30/2018 06:54 PM, Boris Ostrovsky wrote:
BTW, I also think you can further simplify
xenmem_reservation_va_mapping_* routines by bailing out right away if
xen_feature(XENFEAT_auto_translated_physmap). In fact, you might even
make them inlines, along the lines of
inline void xenmem_reservation_va_mapping_reset(unsigned long count,
struct page **pages)
{
#ifdef CONFIG_XEN_HAVE_PVMMU
if (!xen_feature(XENFEAT_auto_translated_physmap))
__xenmem_reservation_va_mapping_reset(...)
#endif
}
How about:
#ifdef CONFIG_XEN_HAVE_PVMMU
static inline __xenmem_reservation_va_mapping_reset(struct page *page)
{
[...]
}
#endif
and
void xenmem_reservation_va_mapping_reset(unsigned long count,
struct page **pages)
{
#ifdef CONFIG_XEN_HAVE_PVMMU
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
int i;
for (i = 0; i < count; i++)
__xenmem_reservation_va_mapping_reset(pages[i]);
}
#endif
}
This way I can use __xenmem_reservation_va_mapping_reset(page);
instead of xenmem_reservation_va_mapping_reset(1, );
Sure, this also works.
Could you please take look at the patch attached if this is what we want?
Please ignore it, it is ugly ;)
I have implemented this as you suggested:
static inline void
xenmem_reservation_va_mapping_update(unsigned long count,
struct page **pages,
xen_pfn_t *frames)
{
#ifdef CONFIG_XEN_HAVE_PVMMU
if (!xen_feature(XENFEAT_auto_translated_physmap))
__xenmem_reservation_va_mapping_update(count, pages, frames);
#endif
}
-boris
Thank you,
Oleksandr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Add OUT_RING64() helper macro
On Thu, May 31, 2018 at 04:01:51PM +0530, Sharat Masetty wrote:
> This patch adds a simple helper function to help write 64 bit payloads
> to the ringbuffer.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12
> drivers/gpu/drm/msm/adreno/a5xx_power.c | 3 +--
> drivers/gpu/drm/msm/msm_ringbuffer.h| 6 ++
> 3 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 5cdf104..7a58a01 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -223,8 +223,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
>
> /* Set the save preemption record for the ring/command */
> OUT_PKT4(ring, REG_A5XX_CP_CONTEXT_SWITCH_SAVE_ADDR_LO, 2);
> - OUT_RING(ring, lower_32_bits(a5xx_gpu->preempt_iova[submit->ring->id]));
> - OUT_RING(ring, upper_32_bits(a5xx_gpu->preempt_iova[submit->ring->id]));
> + OUT_RING64(ring, a5xx_gpu->preempt_iova[submit->ring->id]);
>
> /* Turn back on protected mode */
> OUT_PKT7(ring, CP_SET_PROTECTED_MODE, 1);
> @@ -248,8 +247,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> break;
> case MSM_SUBMIT_CMD_BUF:
> OUT_PKT7(ring, CP_INDIRECT_BUFFER_PFE, 3);
> - OUT_RING(ring, lower_32_bits(submit->cmd[i].iova));
> - OUT_RING(ring, upper_32_bits(submit->cmd[i].iova));
> + OUT_RING64(ring, submit->cmd[i].iova);
> OUT_RING(ring, submit->cmd[i].size);
> ibs++;
> break;
> @@ -282,8 +280,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
>*/
> OUT_PKT7(ring, CP_EVENT_WRITE, 4);
> OUT_RING(ring, CACHE_FLUSH_TS | (1 << 31));
> - OUT_RING(ring, lower_32_bits(rbmemptr(ring, fence)));
> - OUT_RING(ring, upper_32_bits(rbmemptr(ring, fence)));
> + OUT_RING64(ring, rbmemptr(ring, fence));
> OUT_RING(ring, submit->seqno);
>
> /* Yield the floor on command completion */
> @@ -469,8 +466,7 @@ static int a5xx_preempt_start(struct msm_gpu *gpu)
>
> /* Set the save preemption record for the ring/command */
> OUT_PKT4(ring, REG_A5XX_CP_CONTEXT_SWITCH_SAVE_ADDR_LO, 2);
> - OUT_RING(ring, lower_32_bits(a5xx_gpu->preempt_iova[ring->id]));
> - OUT_RING(ring, upper_32_bits(a5xx_gpu->preempt_iova[ring->id]));
> + OUT_RING64(ring, a5xx_gpu->preempt_iova[ring->id]);
>
> /* Turn back on protected mode */
> OUT_PKT7(ring, CP_SET_PROTECTED_MODE, 1);
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c
> b/drivers/gpu/drm/msm/adreno/a5xx_power.c
> index e9c0e56..ea5bfa5 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
> @@ -190,8 +190,7 @@ static int a5xx_gpmu_init(struct msm_gpu *gpu)
>
> /* Kick off the IB to load the GPMU microcode */
> OUT_PKT7(ring, CP_INDIRECT_BUFFER_PFE, 3);
> - OUT_RING(ring, lower_32_bits(a5xx_gpu->gpmu_iova));
> - OUT_RING(ring, upper_32_bits(a5xx_gpu->gpmu_iova));
> + OUT_RING64(ring, a5xx_gpu->gpmu_iova);
> OUT_RING(ring, a5xx_gpu->gpmu_dwords);
>
> /* Turn back on protected mode */
> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h
> b/drivers/gpu/drm/msm/msm_ringbuffer.h
> index cffce09..ea8fc39 100644
> --- a/drivers/gpu/drm/msm/msm_ringbuffer.h
> +++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
> @@ -61,4 +61,10 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
> *gpu, int id,
> *(ring->next++) = data;
> }
>
> +static inline void
> +OUT_RING64(struct msm_ringbuffer *ring, uint64_t data)
I prefer u64 instead of uint64_t for code.
> +{
> + OUT_RING(ring, lower_32_bits(data));
> + OUT_RING(ring, upper_32_bits(data));
> +}
> #endif /* __MSM_RINGBUFFER_H__ */
> --
> 1.9.1
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/msm: move suspend/resume devfreq to their own functions
On Thu, May 31, 2018 at 12:52:03PM +0530, Sharat Masetty wrote:
> This is needed for hardware revisions which do not rely on the generic
> suspend, resume handlers for power management.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 23 +++
> drivers/gpu/drm/msm/msm_gpu.h | 2 ++
> 2 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index d7586f2..c5d4627 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -203,6 +203,19 @@ static int disable_axi(struct msm_gpu *gpu)
> return 0;
> }
>
> +void msm_gpu_resume_devfreq(struct msm_gpu *gpu)
> +{
> + gpu->devfreq.busy_cycles = 0;
> + gpu->devfreq.time = ktime_get();
> +
> + devfreq_resume_device(gpu->devfreq.devfreq);
> +}
I'm on the fence about this - it isn't strictly needed because it would be fine
for the 6xx code to duplicate three lines of code but it does make it easier to
update the statistics in one place. If others feel more strongly, chime in.
> +void msm_gpu_suspend_devfreq(struct msm_gpu *gpu)
> +{
> + devfreq_suspend_device(gpu->devfreq.devfreq);
> +}
This on the other hand is entirely not needed. When 6xx does its thing it can
just call devfreq_suspend_device directly. It is doubtful we will ever need
anything more than this one line to stop devfreq.
> int msm_gpu_pm_resume(struct msm_gpu *gpu)
> {
> int ret;
> @@ -221,12 +234,7 @@ int msm_gpu_pm_resume(struct msm_gpu *gpu)
> if (ret)
> return ret;
>
> - if (gpu->devfreq.devfreq) {
> - gpu->devfreq.busy_cycles = 0;
> - gpu->devfreq.time = ktime_get();
> -
> - devfreq_resume_device(gpu->devfreq.devfreq);
> - }
> + msm_gpu_resume_devfreq(gpu);
>
> gpu->needs_hw_init = true;
>
> @@ -239,8 +247,7 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
>
> DBG("%s", gpu->name);
>
> - if (gpu->devfreq.devfreq)
> - devfreq_suspend_device(gpu->devfreq.devfreq);
> + msm_gpu_suspend_devfreq(gpu);
>
> ret = disable_axi(gpu);
> if (ret)
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index b824117..1876b81 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -226,6 +226,8 @@ static inline void gpu_write64(struct msm_gpu *gpu, u32
> lo, u32 hi, u64 val)
>
> int msm_gpu_pm_suspend(struct msm_gpu *gpu);
> int msm_gpu_pm_resume(struct msm_gpu *gpu);
> +void msm_gpu_resume_devfreq(struct msm_gpu *gpu);
> +void msm_gpu_suspend_devfreq(struct msm_gpu *gpu);
>
> int msm_gpu_hw_init(struct msm_gpu *gpu);
>
> --
> 1.9.1
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
>> >> It is OK if evil user free/unmap the buffer when task is not done >> in my implementation. It will generate a MMU fault in that case and kernel >> driver will do recovery. >> >> So does the Ctrl+C case, if don't deal with it, just get some noisy MMU >> fault warning and a HW reset recovery. > > How about an app rendering to shared buffers, which glFlush()es and > exits cleanly but doesn't close the DRI screen? What would cause that > app's rendering to get completed succesfully instead of faulting to > death? Do you mean the same case as Ctrl+C when an app exit without waiting all task finished in userspace? > > You really do need to refcount the buffers used in a rendering job so > they don't get freed early. Do you mean refcount the buffers in kernel space job? This is OK but not necessary, I can wait task complete in gem_close_object which will be called by drm_release for each buffer too (I still think better waiting in preclose at once but it's gone). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106757] Qt's QOpenGLWidget renders a blank screen under XWayland
https://bugs.freedesktop.org/show_bug.cgi?id=106757 --- Comment #2 from Michael Arnold --- Created attachment 139888 --> https://bugs.freedesktop.org/attachment.cgi?id=139888=edit Qt Application renders correctly under Wayland -- 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 106757] Qt's QOpenGLWidget renders a blank screen under XWayland
https://bugs.freedesktop.org/show_bug.cgi?id=106757 --- Comment #1 from Michael Arnold --- Created attachment 139887 --> https://bugs.freedesktop.org/attachment.cgi?id=139887=edit Qt Application renders incorrectly under XWayland -- 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 106757] Qt's QOpenGLWidget renders a blank screen under XWayland
https://bugs.freedesktop.org/show_bug.cgi?id=106757 Bug ID: 106757 Summary: Qt's QOpenGLWidget renders a blank screen under XWayland Product: Mesa Version: 18.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 Assignee: dri-devel@lists.freedesktop.org Reporter: myk...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 139886 --> https://bugs.freedesktop.org/attachment.cgi?id=139886=edit Qt Application renders correctly using MESA software rendering With intel integrated graphics, the Qt Surface example, that uses QOpenGLWidget, on Fedora 28 under an wayland session and then run under xwayland by starting the Qt application using the command: ./surface -platform xcb results in the Qt application being displayed correctly, but the 3D data visualization is shown incorrectly as blank panel (see attached). The same Qt application in a Wayland session with MESA software rendering also under xwayland as follows: LIBGL_ALWAYS_SOFTWARE=1 ./surface -platform xcb results in the application and 3D data visualization being displayed correctly (see attached). The same Qt application in a XOrg session results in the application and 3D data visualization being displayed correctly. The same Qt application in a Wayland session run under wayland results in the application and 3D data visualization being displayed correctly. This issue is logged as a Qt defect here: https://bugreports.qt.io/browse/QTBUG-68263 A similar issue is described for GNU Octave here: https://savannah.gnu.org/bugs/?51442 -- 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: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 31/05/2018 01:26, Rodrigo Vivi wrote:
> On Wed, May 30, 2018 at 06:29:36PM +0300, Ville Syrjälä wrote:
>> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
>>> This patchs adds the cec_notifier feature to the intel_hdmi part
>>> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
>>> between each HDMI ports.
>>> The changes will allow the i915 HDMI code to notify EDID and HPD changes
>>> to an eventual CEC adapter.
>>>
>>> Signed-off-by: Neil Armstrong
>>> Reviewed-by: Hans Verkuil
>>> ---
>>> drivers/gpu/drm/i915/Kconfig | 1 +
>>> drivers/gpu/drm/i915/intel_display.h | 20
>>> drivers/gpu/drm/i915/intel_drv.h | 2 ++
>>> drivers/gpu/drm/i915/intel_hdmi.c| 13 +
>>> 4 files changed, 36 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>>> index dfd9588..2d65d56 100644
>>> --- a/drivers/gpu/drm/i915/Kconfig
>>> +++ b/drivers/gpu/drm/i915/Kconfig
>>> @@ -23,6 +23,7 @@ config DRM_I915
>>> select SYNC_FILE
>>> select IOSF_MBI
>>> select CRC32
>>> + select CEC_CORE if CEC_NOTIFIER
>>> help
>>> Choose this option if you have a system that has "Intel Graphics
>>> Media Accelerator" or "HD Graphics" integrated graphics,
>>> diff --git a/drivers/gpu/drm/i915/intel_display.h
>>> b/drivers/gpu/drm/i915/intel_display.h
>>> index 4e7418b..c68d1c8 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.h
>>> +++ b/drivers/gpu/drm/i915/intel_display.h
>>> @@ -126,6 +126,26 @@ enum port {
>>>
>>> #define port_name(p) ((p) + 'A')
>>>
>>> +static inline const char *port_identifier(enum port port)
>>> +{
>>> + switch (port) {
>>> + case PORT_A:
>>> + return "Port A";
>>> + case PORT_B:
>>> + return "Port B";
>>> + case PORT_C:
>>> + return "Port C";
>>> + case PORT_D:
>>> + return "Port D";
>>> + case PORT_E:
>>> + return "Port E";
>>> + case PORT_F:
>>> + return "Port F";
>>> + default:
>>> + return "";
>>> + }
>>> +}
>>
>> Could use a comment to make it clear that this identifier is
>> expected to remain stable since it's referenced from other drivers.
>>
>>> +
>>> enum dpio_channel {
>>> DPIO_CH0,
>>> DPIO_CH1
>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index d436858..b50e51b 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -39,6 +39,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> /**
>>> * __wait_for - magic wait macro
>>> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
>>> bool has_audio;
>>> bool rgb_quant_range_selectable;
>>> struct intel_connector *attached_connector;
>>> + struct cec_notifier *notifier;
>>
>> "notifier" seems a bit too generic a name. "cec_notifier" would be
>> better.
>>
>> Apart from that this seems OK to me
>> Reviewed-by: Ville Syrjälä
>
> It seems that you will need to push this to other trees right?
> Feel free to use:
>
> Acked-by: Rodrigo Vivi
You are right, it will useful, thanks !
Neil
>
>>
>>> };
>>>
>>> struct intel_dp_mst_encoder;
>>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>>> b/drivers/gpu/drm/i915/intel_hdmi.c
>>> index 1baef4a..d522b5b 100644
>>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>>> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>>> connected = true;
>>> }
>>>
>>> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
>>> +
>>> return connected;
>>> }
>>>
>>> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector,
>>> bool force)
>>> {
>>> enum drm_connector_status status;
>>> struct drm_i915_private *dev_priv = to_i915(connector->dev);
>>> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>>>
>>> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>>> connector->base.id, connector->name);
>>> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector,
>>> bool force)
>>>
>>> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>>>
>>> + if (status != connector_status_connected)
>>> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
>>> +
>>> return status;
>>> }
>>>
>>> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
>>> *encoder,
>>>
>>> static void intel_hdmi_destroy(struct drm_connector *connector)
>>> {
>>> + if (intel_attached_hdmi(connector)->notifier)
>>> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>>> kfree(to_intel_connector(connector)->detect_edid);
>>> drm_connector_cleanup(connector);
>>> kfree(connector);
>>> @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct
>>> intel_digital_port *intel_dig_port,
>>> u32 temp =
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 30/05/2018 17:29, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
>> This patchs adds the cec_notifier feature to the intel_hdmi part
>> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
>> between each HDMI ports.
>> The changes will allow the i915 HDMI code to notify EDID and HPD changes
>> to an eventual CEC adapter.
>>
>> Signed-off-by: Neil Armstrong
>> Reviewed-by: Hans Verkuil
>> ---
>> drivers/gpu/drm/i915/Kconfig | 1 +
>> drivers/gpu/drm/i915/intel_display.h | 20
>> drivers/gpu/drm/i915/intel_drv.h | 2 ++
>> drivers/gpu/drm/i915/intel_hdmi.c| 13 +
>> 4 files changed, 36 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index dfd9588..2d65d56 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -23,6 +23,7 @@ config DRM_I915
>> select SYNC_FILE
>> select IOSF_MBI
>> select CRC32
>> +select CEC_CORE if CEC_NOTIFIER
>> help
>>Choose this option if you have a system that has "Intel Graphics
>>Media Accelerator" or "HD Graphics" integrated graphics,
>> diff --git a/drivers/gpu/drm/i915/intel_display.h
>> b/drivers/gpu/drm/i915/intel_display.h
>> index 4e7418b..c68d1c8 100644
>> --- a/drivers/gpu/drm/i915/intel_display.h
>> +++ b/drivers/gpu/drm/i915/intel_display.h
>> @@ -126,6 +126,26 @@ enum port {
>>
>> #define port_name(p) ((p) + 'A')
>>
>> +static inline const char *port_identifier(enum port port)
>> +{
>> +switch (port) {
>> +case PORT_A:
>> +return "Port A";
>> +case PORT_B:
>> +return "Port B";
>> +case PORT_C:
>> +return "Port C";
>> +case PORT_D:
>> +return "Port D";
>> +case PORT_E:
>> +return "Port E";
>> +case PORT_F:
>> +return "Port F";
>> +default:
>> +return "";
>> +}
>> +}
>
> Could use a comment to make it clear that this identifier is
> expected to remain stable since it's referenced from other drivers.
>
>> +
>> enum dpio_channel {
>> DPIO_CH0,
>> DPIO_CH1
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index d436858..b50e51b 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -39,6 +39,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /**
>> * __wait_for - magic wait macro
>> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
>> bool has_audio;
>> bool rgb_quant_range_selectable;
>> struct intel_connector *attached_connector;
>> +struct cec_notifier *notifier;
>
> "notifier" seems a bit too generic a name. "cec_notifier" would be
> better.
OK
>
> Apart from that this seems OK to me
> Reviewed-by: Ville Syrjälä
Thanks for the review !
Neil
>
>> };
>>
>> struct intel_dp_mst_encoder;
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 1baef4a..d522b5b 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>> connected = true;
>> }
>>
>> +cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
>> +
>> return connected;
>> }
>>
>> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector,
>> bool force)
>> {
>> enum drm_connector_status status;
>> struct drm_i915_private *dev_priv = to_i915(connector->dev);
>> +struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>>
>> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>>connector->base.id, connector->name);
>> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector,
>> bool force)
>>
>> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>>
>> +if (status != connector_status_connected)
>> +cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
>> +
>> return status;
>> }
>>
>> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
>> *encoder,
>>
>> static void intel_hdmi_destroy(struct drm_connector *connector)
>> {
>> +if (intel_attached_hdmi(connector)->notifier)
>> +cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>> kfree(to_intel_connector(connector)->detect_edid);
>> drm_connector_cleanup(connector);
>> kfree(connector);
>> @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct
>> intel_digital_port *intel_dig_port,
>> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
>> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
>> }
>> +
>> +intel_hdmi->notifier = cec_notifier_get_conn(dev->dev,
>> + port_identifier(port));
>> +if (!intel_hdmi->notifier)
>> +
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #19 from Alex Deucher --- on the kernel command line in grub. -- 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 report] drm/sun4i: backend: Check for the number of alpha planes
Hello Maxime Ripard,
The patch 65f7fa3a3fcb: "drm/sun4i: backend: Check for the number of
alpha planes" from Jun 26, 2017, leads to the following static
checker warning:
drivers/gpu/drm/sun4i/sun4i_backend.c:486 sun4i_backend_atomic_check()
error: 'plane_state' dereferencing possible ERR_PTR()
drivers/gpu/drm/sun4i/sun4i_backend.c
462 static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
463struct drm_crtc_state *crtc_state)
464 {
465 struct drm_plane_state *plane_states[SUN4I_BACKEND_NUM_LAYERS]
= { 0 };
466 struct drm_atomic_state *state = crtc_state->state;
467 struct drm_device *drm = state->dev;
468 struct drm_plane *plane;
469 unsigned int num_planes = 0;
470 unsigned int num_alpha_planes = 0;
471 unsigned int num_frontend_planes = 0;
472 unsigned int num_yuv_planes = 0;
473 unsigned int current_pipe = 0;
474 unsigned int i;
475
476 DRM_DEBUG_DRIVER("Starting checking our planes\n");
477
478 if (!crtc_state->planes_changed)
479 return 0;
480
481 drm_for_each_plane_mask(plane, drm, crtc_state->plane_mask) {
482 struct drm_plane_state *plane_state =
483 drm_atomic_get_plane_state(state, plane);
Not checked for failure.
484 struct sun4i_layer_state *layer_state =
485 state_to_sun4i_layer_state(plane_state);
486 struct drm_framebuffer *fb = plane_state->fb;
487 struct drm_format_name_buf format_name;
488
489 if (sun4i_backend_plane_uses_frontend(plane_state)) {
490 DRM_DEBUG_DRIVER("Using the frontend for plane
%d\n",
491 plane->index);
492
493 layer_state->uses_frontend = true;
494 num_frontend_planes++;
495 } else {
496 layer_state->uses_frontend = false;
497 }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106446] Stutter at higher refresh rates ( 75 Hz) and artifacts on desktop
https://bugs.freedesktop.org/show_bug.cgi?id=106446 --- Comment #3 from tempel.jul...@gmail.com --- Maybe the artifacts with 75Hz are related to my problem I have with 75Hz WQHD via DL-DVI? https://bugs.freedesktop.org/show_bug.cgi?id=105300 However, with 72Hz and amdgpu.dc=0, my desktop is always 100% free of stutter artifacts (without heavy load on CPU and GPU) with my RX 560. -- 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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #75 from i...@yahoo.com --- (In reply to MirceaKitsune from comment #73) > (In reply to iive from comment #72) > > I've thought about testing an older version of Mesa too. Especially since, > from what I can vaguely remember, certain system instabilities were > introduced roughly two years ago (autumn of 2016) when I switched from Mesa > 13 to 17. I doubt that's related after so long but figured I'd still mention. > > The only issue is that I'm not sure how far I can downgrade my Mesa version > without it asking for old dependencies, potentially rendering my system > unusable due to library conflicts. On the other hand, I remember there was > once a way to run games against a custom version of Mesa, by separately > compiling a .so library and using an environment variable to point to it. > > Is it possible to download a Mesa 13.x library from any repository? And what > was the environment variable to point an executable to it when running a > game? (In reply to MirceaKitsune from comment #74) > pcie_aspm=off makes no difference. In addition, I tried booting back to the > radeon module (instead of amdgpu) and disabling the SI scheduler: This seems > to have slightly mitigated the problem in some cases (eg: Blender) but made > no difference in others (eg: Xonotic). > > As for suspending to RAM: I haven't used Standby mode in ages. I never > suspend my computer to RAM, so this could not be an issue. No easy solutions... If you are sure that mesa 13.x works for you, then you must try it, again. I can't help you with packages, but you should be able to download the old packages manually and install them manually too. It might be PITA as it seems that OpenSUSE breaks Mesa on multiple packages, like mesa, mesa-drm, mesa-libva, mesa-libgl1, mesa-libd3d... https://software.opensuse.org/package/Mesa Most packages should be forward compatible, so you don't have to downgrade stuff like libdrm. However the tricky moment here is LLVM. Most likely only Mesa depends on LLVM, so you have to downgrade both at the same time (and nothing else). Theoretically it might still be possible to compile your own mesa-13.x from source, if there are still some issue with the other dependencies. LLVM might be the tricky part here, you might need matching older version. Are there live cd's with OpenSuse? Something you can start without installing it?. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/7] sunxi: Add DT representation for the MBUS controller
On Mon, Apr 09, 2018 at 11:22:29AM +0200, Maxime Ripard wrote: > Hi Rob, > > On Tue, Apr 03, 2018 at 11:03:30AM -0500, Rob Herring wrote: > > On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard > > wrote: > > > Hi, > > > > > > We've had for quite some time to hack around in our drivers to take into > > > account the fact that our DMA accesses are not done through the parent > > > node, but through another bus with a different mapping than the CPU for > > > the > > > RAM (0 instead of 0x4000 for most SoCs). > > > > > > After some discussion after the submission of a camera device suffering of > > > the same hacks, I've decided to put together a serie that introduce a > > > property called dma-parent that allows to express the DMA relationship > > > between a master and its bus, even if they are not direct parents in the > > > DT. > > > > Reading thru v6 of the camera driver, it seems like having > > intermediate buses would solve the problem in your case? > > I guess it would yes, but I guess it wouldn't model the hardware > properly since this seems to be really a bus only meant to do DMA, and > you're not accessing the registers of the device through that bus. > > And as far as I know, the DT implies that the topology is the one of > the "control" side of the devices. > > We'll also need eventually to have retrieve the MBUS endpoints ID to > be able to support perf and PM QoS properly. > > > As Arnd mentioned in that thread, something new needs to address all > > the deficiencies with dma-ranges and describing DMA bus topologies. > > This doesn't address the needs of describing bus interconnects. > > There's been some efforts by the QCom folks with an interconnect > > binding. They've mostly punted (for now at least) to not describing > > the whole interconnect in DT and keeping the details in a driver. > > Is it that patch serie? https://lkml.org/lkml/2018/3/9/856 > > > On the flip side, this does mirror the established pattern used by > > interrupts, so maybe it's okay on it's own. I'll wait for others to > > comment. > > We'll see how it turns out then :) Ping? How should we move forward on this? Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/6] drm/tidss: new display driver for TI's DSS6
On 31/05/18 15:41, Tomi Valkeinen wrote: > Hi, > > This is a new DRM driver for Texas Instruments' Keystone K2G SoC. K2G has DSS6 > IP, which is related to the OMAP DSS IPs handled by the omapdrm driver. While > on higher level the DSS6 resembles the older DSS versions, the registers and > the internal pipelines differ a lot. > > DSS6 IP on K2G is a "ultra-light" version, and has only a single plane and a > single output. The driver will also support future DSS versions, like DSS7 on > AM6 SoC, which supports multiple planes and outputs, so the driver already has > support for those. This is also the reason for the dispc abstraction layer. > > The series is an RFC, as I want to include the DSS7 driver in the final > version. I hope that's ready in a week or two. I'm looking for comments on the > overall architecture. Aand I forgot to give credit to Laurent, as I did look at his rcar-du driver a lot when writing this. There's also a lot of code adapted from omapdrm. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 5/6] ARM: dts: keystone-k2g: add DSS node
Add DSS node to k2g.dtsi.
Signed-off-by: Tomi Valkeinen
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/keystone-k2g.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi
b/arch/arm/boot/dts/keystone-k2g.dtsi
index da78c0034427..d761fe7d46e7 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -609,5 +609,26 @@
reg = <0x2101 0x200>;
interrupts = ;
};
+
+ dss: dss@0254 {
+ compatible = "ti,k2g-dss";
+
+ reg = <0x0254 0x400>,
+ <0x0255 0x1000>,
+ <0x02557000 0x1000>,
+ <0x0255a800 0x100>,
+ <0x0255ac00 0x100>;
+
+ reg-names = "cfg", "common", "vid1", "ovr1", "vp1";
+
+ clocks = <_clks 0x2 0>, <_clks 0x2 1>;
+ clock-names = "fck", "vp1";
+
+ power-domains = <_pds 0x2>;
+
+ interrupts = ;
+
+ status = "disabled";
+ };
};
};
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 3/6] drm/tidss: add new driver for TI Keystone platforms
This patch adds a new DRM driver for Texas Instruments DSS6 IP used on Texas Instruments Keystone K2G SoC. The DSS6 IP is a major change to the older DSS IP versions, which are supported by the omapdrm driver, and while on higher level the DSS6 resembles the older DSS versions, the registers and the internal pipelines differ a lot. DSS6 IP on K2G is a "ultra-light" version, and has only a single plane and a single output. The driver will also support future DSS versions, which support multiple planes and outputs, so the driver already has support for those. Signed-off-by: Tomi Valkeinen --- MAINTAINERS |8 + drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/tidss/Kconfig | 10 + drivers/gpu/drm/tidss/Makefile| 11 + drivers/gpu/drm/tidss/tidss_crtc.c| 464 +++ drivers/gpu/drm/tidss/tidss_crtc.h| 50 + drivers/gpu/drm/tidss/tidss_dispc.h | 146 +++ drivers/gpu/drm/tidss/tidss_dispc6.c | 1397 + drivers/gpu/drm/tidss/tidss_dispc6.h | 12 + drivers/gpu/drm/tidss/tidss_dispc6_regs.h | 109 ++ drivers/gpu/drm/tidss/tidss_drv.c | 331 + drivers/gpu/drm/tidss/tidss_drv.h | 41 + drivers/gpu/drm/tidss/tidss_encoder.c | 101 ++ drivers/gpu/drm/tidss/tidss_encoder.h | 22 + drivers/gpu/drm/tidss/tidss_irq.c | 193 +++ drivers/gpu/drm/tidss/tidss_irq.h | 25 + drivers/gpu/drm/tidss/tidss_kms.c | 85 ++ drivers/gpu/drm/tidss/tidss_kms.h | 14 + drivers/gpu/drm/tidss/tidss_plane.c | 187 +++ drivers/gpu/drm/tidss/tidss_plane.h | 25 + 21 files changed, 3234 insertions(+) create mode 100644 drivers/gpu/drm/tidss/Kconfig create mode 100644 drivers/gpu/drm/tidss/Makefile create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.c create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.h create mode 100644 drivers/gpu/drm/tidss/tidss_dispc.h create mode 100644 drivers/gpu/drm/tidss/tidss_dispc6.c create mode 100644 drivers/gpu/drm/tidss/tidss_dispc6.h create mode 100644 drivers/gpu/drm/tidss/tidss_dispc6_regs.h create mode 100644 drivers/gpu/drm/tidss/tidss_drv.c create mode 100644 drivers/gpu/drm/tidss/tidss_drv.h create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.c create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.h create mode 100644 drivers/gpu/drm/tidss/tidss_irq.c create mode 100644 drivers/gpu/drm/tidss/tidss_irq.h create mode 100644 drivers/gpu/drm/tidss/tidss_kms.c create mode 100644 drivers/gpu/drm/tidss/tidss_kms.h create mode 100644 drivers/gpu/drm/tidss/tidss_plane.c create mode 100644 drivers/gpu/drm/tidss/tidss_plane.h diff --git a/MAINTAINERS b/MAINTAINERS index ca4afd68530c..b9de8b54cc67 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4780,6 +4780,14 @@ S: Maintained F: drivers/gpu/drm/omapdrm/ F: Documentation/devicetree/bindings/display/ti/ +DRM DRIVERS FOR TI KEYSTONE +M: Tomi Valkeinen +R: Jyri Sarha +L: dri-devel@lists.freedesktop.org +S: Maintained +F: drivers/gpu/drm/tidss/ +F: Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt + DRM DRIVERS FOR VC4 M: Eric Anholt T: git git://github.com/anholt/linux diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index deeefa7a1773..b8b6c28a6800 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig" source "drivers/gpu/drm/tve200/Kconfig" +source "drivers/gpu/drm/tidss/Kconfig" + # Keep legacy drivers last menuconfig DRM_LEGACY diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 50093ff4479b..3aa032fbb11a 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB) += mxsfb/ obj-$(CONFIG_DRM_TINYDRM) += tinydrm/ obj-$(CONFIG_DRM_PL111) += pl111/ obj-$(CONFIG_DRM_TVE200) += tve200/ +obj-$(CONFIG_DRM_TIDSS) += tidss/ diff --git a/drivers/gpu/drm/tidss/Kconfig b/drivers/gpu/drm/tidss/Kconfig new file mode 100644 index ..818666db08a4 --- /dev/null +++ b/drivers/gpu/drm/tidss/Kconfig @@ -0,0 +1,10 @@ +config DRM_TIDSS + tristate "DRM Support for TI Keystone" + depends on DRM && OF + depends on ARM || ARM64 || COMPILE_TEST + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + select VIDEOMODE_HELPERS + help + TI Keystone diff --git a/drivers/gpu/drm/tidss/Makefile b/drivers/gpu/drm/tidss/Makefile new file mode 100644 index ..ee6b24db0441 --- /dev/null +++ b/drivers/gpu/drm/tidss/Makefile @@ -0,0 +1,11 @@ +# SPDX-License-Identifier: GPL-2.0 + +tidss-y := tidss_drv.o \ + tidss_kms.o \ + tidss_crtc.o \ + tidss_plane.o \ + tidss_encoder.o \ + tidss_dispc6.o \ + tidss_irq.o + +obj-$(CONFIG_DRM_TIDSS)
[RFC PATCH 0/6] drm/tidss: new display driver for TI's DSS6
Hi, This is a new DRM driver for Texas Instruments' Keystone K2G SoC. K2G has DSS6 IP, which is related to the OMAP DSS IPs handled by the omapdrm driver. While on higher level the DSS6 resembles the older DSS versions, the registers and the internal pipelines differ a lot. DSS6 IP on K2G is a "ultra-light" version, and has only a single plane and a single output. The driver will also support future DSS versions, like DSS7 on AM6 SoC, which supports multiple planes and outputs, so the driver already has support for those. This is also the reason for the dispc abstraction layer. The series is an RFC, as I want to include the DSS7 driver in the final version. I hope that's ready in a week or two. I'm looking for comments on the overall architecture. Tomi Peter Ujfalusi (1): drm: Add support for extracting sync signal drive edge from videomode Tomi Valkeinen (5): dt-bindings: display/ti: add k2g-dss bindings drm/tidss: add new driver for TI Keystone platforms drm/panel: simple: add newhaven,nhd-4.3-480272ef-atxl LCD ARM: dts: keystone-k2g: add DSS node ARM: dts: keystone-k2g-evm: add LCD and HDMI displays .../panel/newhaven,nhd-4.3-480272ef-atxl.txt |7 + .../bindings/display/ti/ti,k2g-dss.txt| 15 + MAINTAINERS |8 + arch/arm/boot/dts/Makefile|1 + arch/arm/boot/dts/keystone-k2g-evm-lcd.dts| 80 + arch/arm/boot/dts/keystone-k2g-evm.dts| 91 ++ arch/arm/boot/dts/keystone-k2g.dtsi | 21 + drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/drm_modes.c | 15 +- drivers/gpu/drm/panel/panel-simple.c | 29 + drivers/gpu/drm/tidss/Kconfig | 10 + drivers/gpu/drm/tidss/Makefile| 11 + drivers/gpu/drm/tidss/tidss_crtc.c| 464 ++ drivers/gpu/drm/tidss/tidss_crtc.h| 50 + drivers/gpu/drm/tidss/tidss_dispc.h | 146 ++ drivers/gpu/drm/tidss/tidss_dispc6.c | 1397 + drivers/gpu/drm/tidss/tidss_dispc6.h | 12 + drivers/gpu/drm/tidss/tidss_dispc6_regs.h | 109 ++ drivers/gpu/drm/tidss/tidss_drv.c | 331 drivers/gpu/drm/tidss/tidss_drv.h | 41 + drivers/gpu/drm/tidss/tidss_encoder.c | 101 ++ drivers/gpu/drm/tidss/tidss_encoder.h | 22 + drivers/gpu/drm/tidss/tidss_irq.c | 193 +++ drivers/gpu/drm/tidss/tidss_irq.h | 25 + drivers/gpu/drm/tidss/tidss_kms.c | 85 + drivers/gpu/drm/tidss/tidss_kms.h | 14 + drivers/gpu/drm/tidss/tidss_plane.c | 187 +++ drivers/gpu/drm/tidss/tidss_plane.h | 25 + include/drm/drm_connector.h |4 + 30 files changed, 3493 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/newhaven,nhd-4.3-480272ef-atxl.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt create mode 100644 arch/arm/boot/dts/keystone-k2g-evm-lcd.dts create mode 100644 drivers/gpu/drm/tidss/Kconfig create mode 100644 drivers/gpu/drm/tidss/Makefile create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.c create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.h create mode 100644 drivers/gpu/drm/tidss/tidss_dispc.h create mode 100644 drivers/gpu/drm/tidss/tidss_dispc6.c create mode 100644 drivers/gpu/drm/tidss/tidss_dispc6.h create mode 100644 drivers/gpu/drm/tidss/tidss_dispc6_regs.h create mode 100644 drivers/gpu/drm/tidss/tidss_drv.c create mode 100644 drivers/gpu/drm/tidss/tidss_drv.h create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.c create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.h create mode 100644 drivers/gpu/drm/tidss/tidss_irq.c create mode 100644 drivers/gpu/drm/tidss/tidss_irq.h create mode 100644 drivers/gpu/drm/tidss/tidss_kms.c create mode 100644 drivers/gpu/drm/tidss/tidss_kms.h create mode 100644 drivers/gpu/drm/tidss/tidss_plane.c create mode 100644 drivers/gpu/drm/tidss/tidss_plane.h -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/6] drm: Add support for extracting sync signal drive edge from videomode
From: Peter Ujfalusi
The sync in some panels needs to be driven by different edge of the pixel
clock compared to data. This is reflected by the
DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in videmode flags.
Add similar similar definitions for bus_flags and convert the sync drive
edge via drm_bus_flags_from_videomode().
Signed-off-by: Peter Ujfalusi
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/drm_modes.c | 15 +++
include/drm/drm_connector.h | 4
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e82b61e08f8c..1661bfc55687 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -659,10 +659,12 @@ EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
* drm_bus_flags_from_videomode - extract information about pixelclk and
* DE polarity from videomode and store it in a separate variable
* @vm: videomode structure to use
- * @bus_flags: information about pixelclk and DE polarity will be stored here
+ * @bus_flags: information about pixelclk, sync and DE polarity will be stored
+ * here
*
- * Sets DRM_BUS_FLAG_DE_(LOW|HIGH) and DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE
- * in @bus_flags according to DISPLAY_FLAGS found in @vm
+ * Sets DRM_BUS_FLAG_DE_(LOW|HIGH), DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and
+ * DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in @bus_flags according to DISPLAY_FLAGS
+ * found in @vm
*/
void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags)
{
@@ -672,6 +674,11 @@ void drm_bus_flags_from_videomode(const struct videomode
*vm, u32 *bus_flags)
if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
*bus_flags |= DRM_BUS_FLAG_PIXDATA_NEGEDGE;
+ if (vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE)
+ *bus_flags |= DRM_BUS_FLAG_SYNC_POSEDGE;
+ if (vm->flags & DISPLAY_FLAGS_SYNC_NEGEDGE)
+ *bus_flags |= DRM_BUS_FLAG_SYNC_NEGEDGE;
+
if (vm->flags & DISPLAY_FLAGS_DE_LOW)
*bus_flags |= DRM_BUS_FLAG_DE_LOW;
if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
@@ -684,7 +691,7 @@ EXPORT_SYMBOL_GPL(drm_bus_flags_from_videomode);
* of_get_drm_display_mode - get a drm_display_mode from devicetree
* @np: device_node with the timing specification
* @dmode: will be set to the return value
- * @bus_flags: information about pixelclk and DE polarity
+ * @bus_flags: information about pixelclk, sync and DE polarity
* @index: index into the list of display timings in devicetree
*
* This function is expensive and should only be used, if only one mode is to
be
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 675cc3f8cf85..8fa901637f00 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -290,6 +290,10 @@ struct drm_display_info {
#define DRM_BUS_FLAG_DATA_MSB_TO_LSB (1<<4)
/* data is transmitted LSB to MSB on the bus */
#define DRM_BUS_FLAG_DATA_LSB_TO_MSB (1<<5)
+/* drive sync on pos. edge */
+#define DRM_BUS_FLAG_SYNC_POSEDGE (1<<6)
+/* drive sync on neg. edge */
+#define DRM_BUS_FLAG_SYNC_NEGEDGE (1<<7)
/**
* @bus_flags: Additional information (like pixel signal polarity) for
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 6/6] ARM: dts: keystone-k2g-evm: add LCD and HDMI displays
K2G EVM has an SiI902x HDMI encoder on the board, and a separately
purchasable LCD which can be attached to the board. Only one of these
displays can be used at a time, and two dip-switches need to be changed
when switching to another display.
The HDMI support is added to the base k2g-evm.dts file, and the LCD
support is added as a separate k2g-evm-lcd.dts file. The user must
choose one of the dtbs, depending on which display he wants to use.
Signed-off-by: Tomi Valkeinen
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/keystone-k2g-evm-lcd.dts | 80 +++
arch/arm/boot/dts/keystone-k2g-evm.dts | 91 ++
3 files changed, 172 insertions(+)
create mode 100644 arch/arm/boot/dts/keystone-k2g-evm-lcd.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..11bb3ba22bdf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -222,6 +222,7 @@ dtb-$(CONFIG_ARCH_KEYSTONE) += \
keystone-k2l-evm.dtb \
keystone-k2e-evm.dtb \
keystone-k2g-evm.dtb \
+ keystone-k2g-evm-lcd.dtb \
keystone-k2g-ice.dtb
dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-b3.dtb \
diff --git a/arch/arm/boot/dts/keystone-k2g-evm-lcd.dts
b/arch/arm/boot/dts/keystone-k2g-evm-lcd.dts
new file mode 100644
index ..be0498010e71
--- /dev/null
+++ b/arch/arm/boot/dts/keystone-k2g-evm-lcd.dts
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for K2G EVM with LCD Display
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include "keystone-k2g-evm.dts"
+#include
+
+/ {
+ lcd0: display {
+ compatible = "newhaven,nhd-4.3-480272ef-atxl", "panel-dpi";
+ label = "lcd";
+
+ backlight = <_bl>;
+
+ panel-timing {
+ clock-frequency = <900>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <2>;
+ hback-porch = <2>;
+ hsync-len = <41>;
+ vfront-porch = <2>;
+ vback-porch = <2>;
+ vsync-len = <10>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ lcd_bl: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 32 64 96 128 160 192 224 255>;
+ default-brightness-level = <8>;
+ };
+};
+
+ {
+ edt-ft5306@38 {
+ status = "okay";
+ compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
+ reg = <0x38>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_ft5306_ts_pins>;
+
+ interrupt-parent = <>;
+ interrupts = <42 IRQ_TYPE_EDGE_FALLING>;
+
+ touchscreen-size-x = <480>;
+ touchscreen-size-y = <272>;
+ };
+};
+
+_pinctrl {
+ edt_ft5306_ts_pins: edt_ft5306_ts_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1364) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE3) /* pr1_pru1_gpo16.gpio1_42 */
+ >;
+ };
+};
+
+_out {
+ remote-endpoint = <_in>;
+};
+
+ {
+ status = "disabled";
+};
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 6a4657799b99..e94be4a1bbd3 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -81,6 +81,13 @@
>;
};
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1384) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* i2c1_scl.i2c1_scl */
+ K2G_CORE_IOPAD(0x1388) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* i2c1_sda.i2c1_sda */
+ >;
+ };
+
ecap0_pins: ecap0_pins {
pinctrl-single,pins = <
K2G_CORE_IOPAD(0x1374) (BUFFER_CLASS_B | MUX_MODE4)
/* pr1_mdio_data.ecap0_in_apwm0_out */
@@ -114,6 +121,46 @@
K2G_CORE_IOPAD(0x11f0) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE0) /* uart2_txd.uart2_txd */
>;
};
+
+ vout_pins: pinmux_vout_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1078) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* dssdata23.dssdata23 */
+
[RFC PATCH 4/6] drm/panel: simple: add newhaven, nhd-4.3-480272ef-atxl LCD
Add support for newhaven,nhd-4.3-480272ef-atxl to panel-simple.
Signed-off-by: Tomi Valkeinen
Cc: Thierry Reding
---
.../panel/newhaven,nhd-4.3-480272ef-atxl.txt | 7 +
drivers/gpu/drm/panel/panel-simple.c | 29 +++
2 files changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/newhaven,nhd-4.3-480272ef-atxl.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/newhaven,nhd-4.3-480272ef-atxl.txt
b/Documentation/devicetree/bindings/display/panel/newhaven,nhd-4.3-480272ef-atxl.txt
new file mode 100644
index ..e78292b1a131
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/newhaven,nhd-4.3-480272ef-atxl.txt
@@ -0,0 +1,7 @@
+Newhaven Display International 480 x 272 TFT LCD panel
+
+Required properties:
+- compatible: should be "newhaven,nhd-4.3-480272ef-atxl"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..5d00c7d403b3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2069,6 +2069,32 @@ static const struct panel_desc winstar_wf35ltiacd = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct drm_display_mode newhaven_nhd_43_480272ef_atxl_mode = {
+ .clock = 9000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 2,
+ .hsync_end = 480 + 2 + 41,
+ .htotal = 480 + 2 + 41 + 2,
+ .vdisplay = 272,
+ .vsync_start = 272 + 2,
+ .vsync_end = 272 + 2 + 10,
+ .vtotal = 272 + 2 + 10 + 2,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc newhaven_nhd_43_480272ef_atxl = {
+ .modes = _nhd_43_480272ef_atxl_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 95,
+ .height = 54,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE |
DRM_BUS_FLAG_SYNC_POSEDGE,
+};
+
static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am-480272h3tmqw-t01h",
@@ -2286,6 +2312,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "winstar,wf35ltiacd",
.data = _wf35ltiacd,
+ }, {
+ .compatible = "newhaven,nhd-4.3-480272ef-atxl",
+ .data = _nhd_43_480272ef_atxl,
}, {
/* sentinel */
}
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 2/6] dt-bindings: display/ti: add k2g-dss bindings
Add DT bindings for Texas Instruments K2G SoC Display Subsystem. The DSS is quite simple, with a single plane and a single output. Signed-off-by: Tomi Valkeinen Cc: devicet...@vger.kernel.org --- .../devicetree/bindings/display/ti/ti,k2g-dss.txt | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt diff --git a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt new file mode 100644 index ..1af11425eda3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt @@ -0,0 +1,15 @@ +Texas Instruments K2G Display Subsystem +=== + +Required properties: +- compatible: "ti,k2g-dss" +- reg: address and length of the register spaces for DSS submodules +- reg-names: "cfg", "common", "vid1", "ovr1", "vp1" +- clocks: phandle to fclk and vp1 clocks +- clock-names: "fck", "vp1" +- interrupts: phandle to the DISPC interrupt + +The DSS outputs are described using the device graphs as documented in +Documentation/devicetree/bindings/graph.txt. K2G DSS has a single DPI output as +port 0. + -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 10/11] drm/msm/dpu: correct dpu_io_util.h include path
On 2018-05-30 22:00, Jordan Crouse wrote: On Wed, May 30, 2018 at 08:19:47PM +0530, Rajesh Yadav wrote: dpu_io_util.h is moved from standard include path to driver folder, correct the include path in code. Signed-off-by: Rajesh Yadav If the previous patch doesn't compile without this fix you should squash them. Hi Jordan, Yeah you are right, will squash it in v2. We are trying to keep msm core and dpu changes in separate patches for better squashing when they are pulled by Sean in dpu-staging tree but for this instance can't break compilation so yeah I'll squash it with previous one. Thanks, Rajesh --- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c index 24c3274..f997bd9 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c @@ -20,7 +20,6 @@ #include #include #include -#include #include "dpu_power_handle.h" #include "dpu_trace.h" diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h index 9a6d4b9..193f468 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h @@ -21,7 +21,7 @@ #define DPU_POWER_HANDLE_ENABLE_BUS_IB_QUOTA 16 #define DPU_POWER_HANDLE_DISABLE_BUS_IB_QUOTA 0 -#include +#include "dpu_io_util.h" /* event will be triggered before power handler disable */ #define DPU_POWER_EVENT_PRE_DISABLE0x1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Add OUT_RING64() helper macro
This patch adds a simple helper function to help write 64 bit payloads
to the ringbuffer.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12
drivers/gpu/drm/msm/adreno/a5xx_power.c | 3 +--
drivers/gpu/drm/msm/msm_ringbuffer.h| 6 ++
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 5cdf104..7a58a01 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -223,8 +223,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit,
/* Set the save preemption record for the ring/command */
OUT_PKT4(ring, REG_A5XX_CP_CONTEXT_SWITCH_SAVE_ADDR_LO, 2);
- OUT_RING(ring, lower_32_bits(a5xx_gpu->preempt_iova[submit->ring->id]));
- OUT_RING(ring, upper_32_bits(a5xx_gpu->preempt_iova[submit->ring->id]));
+ OUT_RING64(ring, a5xx_gpu->preempt_iova[submit->ring->id]);
/* Turn back on protected mode */
OUT_PKT7(ring, CP_SET_PROTECTED_MODE, 1);
@@ -248,8 +247,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit,
break;
case MSM_SUBMIT_CMD_BUF:
OUT_PKT7(ring, CP_INDIRECT_BUFFER_PFE, 3);
- OUT_RING(ring, lower_32_bits(submit->cmd[i].iova));
- OUT_RING(ring, upper_32_bits(submit->cmd[i].iova));
+ OUT_RING64(ring, submit->cmd[i].iova);
OUT_RING(ring, submit->cmd[i].size);
ibs++;
break;
@@ -282,8 +280,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit,
*/
OUT_PKT7(ring, CP_EVENT_WRITE, 4);
OUT_RING(ring, CACHE_FLUSH_TS | (1 << 31));
- OUT_RING(ring, lower_32_bits(rbmemptr(ring, fence)));
- OUT_RING(ring, upper_32_bits(rbmemptr(ring, fence)));
+ OUT_RING64(ring, rbmemptr(ring, fence));
OUT_RING(ring, submit->seqno);
/* Yield the floor on command completion */
@@ -469,8 +466,7 @@ static int a5xx_preempt_start(struct msm_gpu *gpu)
/* Set the save preemption record for the ring/command */
OUT_PKT4(ring, REG_A5XX_CP_CONTEXT_SWITCH_SAVE_ADDR_LO, 2);
- OUT_RING(ring, lower_32_bits(a5xx_gpu->preempt_iova[ring->id]));
- OUT_RING(ring, upper_32_bits(a5xx_gpu->preempt_iova[ring->id]));
+ OUT_RING64(ring, a5xx_gpu->preempt_iova[ring->id]);
/* Turn back on protected mode */
OUT_PKT7(ring, CP_SET_PROTECTED_MODE, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c
b/drivers/gpu/drm/msm/adreno/a5xx_power.c
index e9c0e56..ea5bfa5 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
@@ -190,8 +190,7 @@ static int a5xx_gpmu_init(struct msm_gpu *gpu)
/* Kick off the IB to load the GPMU microcode */
OUT_PKT7(ring, CP_INDIRECT_BUFFER_PFE, 3);
- OUT_RING(ring, lower_32_bits(a5xx_gpu->gpmu_iova));
- OUT_RING(ring, upper_32_bits(a5xx_gpu->gpmu_iova));
+ OUT_RING64(ring, a5xx_gpu->gpmu_iova);
OUT_RING(ring, a5xx_gpu->gpmu_dwords);
/* Turn back on protected mode */
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h
b/drivers/gpu/drm/msm/msm_ringbuffer.h
index cffce09..ea8fc39 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.h
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
@@ -61,4 +61,10 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
*gpu, int id,
*(ring->next++) = data;
}
+static inline void
+OUT_RING64(struct msm_ringbuffer *ring, uint64_t data)
+{
+ OUT_RING(ring, lower_32_bits(data));
+ OUT_RING(ring, upper_32_bits(data));
+}
#endif /* __MSM_RINGBUFFER_H__ */
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] drm/blend: Add per-plane pixel blend mode property
On Wed, May 30, 2018 at 10:40:40AM -0400, Sean Paul wrote: > On Wed, May 30, 2018 at 07:23:52PM +0800, Lowry Li wrote: > > Hi, > > > > This serie aims at adding the support for pixel blend modes represent the > > alpha blending equation selection in the driver. It also introduces to use > > it in the malidp driver. > > > > Let me know what you think, > > Hi Lowry, > Thank you for doing this work. I know this is something that is missing for > proper Android support, so it's most welcome. > > Do you have userspace patches using this property? > > Sean > > Hi Sean, Thanks a lot for the reply. Yes, we have userspace patches, which is on the way. Will let you know once it's ready. Thanks, Lowry > > Lowry > > > > Changes for v2: > > - Moves the blending equation into the DOC comment > > - Refines the comments of drm_plane_create_blend_mode_property to not > >enumerate the #defines, but instead the string values > > - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha > > - Introduces to use it in the malidp driver, which depends on the plane > >alpha patch > > > > Changes from v1: > > - v1 is just the core changes to request for commments > > - Adds a pixel_blend_mode to drm_plane_state and a blend_mode_property to > >drm_plane, and related support functions > > - Defines three blend modes in drm_blend.h > > - Rebased on current drm-next > > > > Lowry Li (2): > > drm/blend: Add per-plane pixel blend mode property > > drm/mali-dp: Implement plane alpha and pixel blend on malidp > > > > drivers/gpu/drm/arm/malidp_planes.c | 76 ++--- > > drivers/gpu/drm/drm_atomic.c| 4 ++ > > drivers/gpu/drm/drm_atomic_helper.c | 1 + > > drivers/gpu/drm/drm_blend.c | 110 > > > > include/drm/drm_blend.h | 6 ++ > > include/drm/drm_plane.h | 6 ++ > > 6 files changed, 171 insertions(+), 32 deletions(-) > > > > -- > > 1.9.1 > > > > -- > Sean Paul, Software Engineer, Google / Chromium OS -- Regards, Lowry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/mali-dp: Implement plane alpha and pixel blend on malidp
On Wed, May 30, 2018 at 02:34:33PM +0100, Brian Starkey wrote:
> Hi Lowry,
>
> On Wed, May 30, 2018 at 07:23:54PM +0800, Lowry Li wrote:
> >Check the pixel blending mode and plane alpha value when
> >do the plane_check. Mali DP supports blending the current plane
> >with the background either based on the pixel alpha blending
> >mode or by using the layer's alpha value, but not both at the
> >same time. If both case, plane_check will return failed.
> >
> >Set the HW when doing plane_update accordingly. If plane alpha
> >is the 0x, set the PREM bit accordingly. If not we'd set
> >ALPHA bit as zero and layer alpha value.
>
> The code looks correct - but the description of the PREM bit seems
> wrong here. Did you mean "set the pixel blending bits accordingly"?
>
> With that fixed:
>
> Reviewed-by: Brian Starkey
>
Hi Brian,
PREM bit is PREMULTI bit to be set premulti or coverage bit
accordingly. But yes, I think I'd change to use "set pixel blending
bits accordingly" to make it entirety :)
Thanks for the review.
> >
> >Signed-off-by: Lowry Li
> >---
> >drivers/gpu/drm/arm/malidp_planes.c | 76
> >+
> >1 file changed, 44 insertions(+), 32 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> >b/drivers/gpu/drm/arm/malidp_planes.c
> >index 7a44897..daa3f4f 100644
> >--- a/drivers/gpu/drm/arm/malidp_planes.c
> >+++ b/drivers/gpu/drm/arm/malidp_planes.c
> >@@ -35,6 +35,7 @@
> >#define LAYER_COMP_MASK(0x3 << 12)
> >#define LAYER_COMP_PIXEL (0x3 << 12)
> >#define LAYER_COMP_PLANE (0x2 << 12)
> >+#define LAYER_PMUL_ENABLE (0x1 << 14)
> >#define LAYER_ALPHA_OFFSET (16)
> >#define LAYER_ALPHA_MASK (0xff)
> >#define LAYER_ALPHA(x) (((x) & LAYER_ALPHA_MASK) <<
> >LAYER_ALPHA_OFFSET)
> >@@ -182,6 +183,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
> > struct malidp_plane_state *ms = to_malidp_plane_state(state);
> > bool rotated = state->rotation & MALIDP_ROTATED_MASK;
> > struct drm_framebuffer *fb;
> >+u16 pixel_alpha = state->pixel_blend_mode;
> > int i, ret;
> >
> > if (!state->crtc || !state->fb)
> >@@ -244,6 +246,11 @@ static int malidp_de_plane_check(struct drm_plane
> >*plane,
> > ms->rotmem_size = val;
> > }
> >
> >+/* HW can't support plane + pixel blending */
> >+if ((state->alpha != DRM_BLEND_ALPHA_OPAQUE) &&
> >+(pixel_alpha != DRM_MODE_BLEND_PIXEL_NONE))
> >+return -EINVAL;
> >+
> > return 0;
> >}
> >
> >@@ -325,31 +332,33 @@ static void malidp_de_plane_update(struct drm_plane
> >*plane,
> >{
> > struct malidp_plane *mp;
> > struct malidp_plane_state *ms = to_malidp_plane_state(plane->state);
> >+struct drm_plane_state *state = plane->state;
> >+u16 pixel_alpha = state->pixel_blend_mode;
> >+u8 plane_alpha = state->alpha >> 8;
> > u32 src_w, src_h, dest_w, dest_h, val;
> > int i;
> >-bool format_has_alpha = plane->state->fb->format->has_alpha;
> >
> > mp = to_malidp_plane(plane);
> >
> > /* convert src values from Q16 fixed point to integer */
> >-src_w = plane->state->src_w >> 16;
> >-src_h = plane->state->src_h >> 16;
> >-dest_w = plane->state->crtc_w;
> >-dest_h = plane->state->crtc_h;
> >+src_w = state->src_w >> 16;
> >+src_h = state->src_h >> 16;
> >+dest_w = state->crtc_w;
> >+dest_h = state->crtc_h;
> >
> > malidp_hw_write(mp->hwdev, ms->format, mp->layer->base);
> >
> > for (i = 0; i < ms->n_planes; i++) {
> > /* calculate the offset for the layer's plane registers */
> > u16 ptr = mp->layer->ptr + (i << 4);
> >-dma_addr_t fb_addr = drm_fb_cma_get_gem_addr(plane->state->fb,
> >- plane->state, i);
> >+dma_addr_t fb_addr = drm_fb_cma_get_gem_addr(state->fb,
> >+ state, i);
> >
> > malidp_hw_write(mp->hwdev, lower_32_bits(fb_addr), ptr);
> > malidp_hw_write(mp->hwdev, upper_32_bits(fb_addr), ptr + 4);
> > }
> > malidp_de_set_plane_pitches(mp, ms->n_planes,
> >-plane->state->fb->pitches);
> >+state->fb->pitches);
> >
> > if ((plane->state->color_encoding != old_state->color_encoding) ||
> > (plane->state->color_range != old_state->color_range))
> >@@ -362,8 +371,8 @@ static void malidp_de_plane_update(struct drm_plane
> >*plane,
> > malidp_hw_write(mp->hwdev, LAYER_H_VAL(dest_w) | LAYER_V_VAL(dest_h),
> > mp->layer->base + MALIDP_LAYER_COMP_SIZE);
> >
> >-malidp_hw_write(mp->hwdev, LAYER_H_VAL(plane->state->crtc_x) |
> >-LAYER_V_VAL(plane->state->crtc_y),
> >+malidp_hw_write(mp->hwdev, LAYER_H_VAL(state->crtc_x) |
> >+LAYER_V_VAL(state->crtc_y),
> >
Re: [PATCH v2 1/2] drm/blend: Add per-plane pixel blend mode property
On Thu, May 31, 2018 at 11:36:47AM +0200, Maarten Lankhorst wrote: > Hey, > > Op 30-05-18 om 13:23 schreef Lowry Li: > > Pixel blend modes represent the alpha blending equation > > selection, describing how the pixels from the current > > plane are composited with the background. > > > > Add a pixel_blend_mode to drm_plane_state and a > > blend_mode_property to drm_plane, and related support > > functions. > > > > Defines three blend modes in drm_blend.h. > > > > Signed-off-by: Lowry Li > > --- > > drivers/gpu/drm/drm_atomic.c| 4 ++ > > drivers/gpu/drm/drm_atomic_helper.c | 1 + > > drivers/gpu/drm/drm_blend.c | 110 > > > > include/drm/drm_blend.h | 6 ++ > > include/drm/drm_plane.h | 6 ++ > > 5 files changed, 127 insertions(+) > Can you rebase this on top of a kernel with alpha property support? Getting > some nasty conflicts otherwise.. > > ~Maarten Dear Maarten, Yes, I will rebase this on top of drm-misc-next branch with alpha property support. -- Regards, Lowry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Set current atomic state in drm_private_state
Hi, Thank you for the review. On Wed, May 30, 2018 at 11:22:27PM +0300, Ville Syrjälä wrote: > On Wed, May 30, 2018 at 06:30:52PM +0100, Alexandru Gheorghe wrote: > > drm_private_state has a back pointer to the drm_atomic_state, > > however that was not initialized in drm_atomic_get_private_obj_state > > after duplication, as it is the case for other drm atomic getters > > > > Signed-off-by: Alexandru Gheorghe > > --- > > drivers/gpu/drm/drm_atomic.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > > index 7d25c42..249aaf8 100644 > > --- a/drivers/gpu/drm/drm_atomic.c > > +++ b/drivers/gpu/drm/drm_atomic.c > > @@ -1108,6 +1108,7 @@ drm_atomic_get_private_obj_state(struct > > drm_atomic_state *state, > > state->private_objs[index].old_state = obj->state; > > state->private_objs[index].new_state = obj_state; > > state->private_objs[index].ptr = obj; > > + obj_state->state = state; > > Reviewed-by: Ville Syrjälä > > I guess no one ever used that pointer. Should we add some WARNs > to drm_atomic_helper_swap_state() to make sure these are correct? That would've caught this, but I'm not sure if it's not to late for a warning, we just got lucky nobody ever tried to access that pointer yet. > > I think in general life might be nicer if we didn't even have these > pointers at all. As it stands it's pretty easy to accidentally > use them when you're not supposed to (eg. after swap_state() try > to use the new_state->state). But there's tons of code that would > need to be touched to eliminate them so not a very pleasant project. I agree easy to accidentally use them after swap, but I suppose is to late to eliminate them or if we should. > > > > > state->num_private_objs = num_objs; > > > > -- > > 2.7.4 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Ville Syrjälä > Intel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] drm/msm: re-factor devfreq code
devfreq framework requires the drivers to provide busy time estimations.
The GPU driver relies on the hardware performance counters for the busy time
estimations, but different hardware revisions have counters which can be
sourced from different clocks. So the busy time estimation will be target
dependent. Additionally on targets where the clocks are completely controlled
by the on chip microcontroller, fetching and setting the current GPU frequency
will be different. This patch aims to embrace these differences by re-factoring
the devfreq code a bit.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16
drivers/gpu/drm/msm/msm_gpu.c | 23 ++-
drivers/gpu/drm/msm/msm_gpu.h | 4 +++-
3 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d39400e..5cdf104 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1219,12 +1219,20 @@ static struct msm_ringbuffer *a5xx_active_ring(struct
msm_gpu *gpu)
return a5xx_gpu->cur_ring;
}
-static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t *value)
+static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
{
- *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
- REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+ u64 busy_cycles;
+ unsigned long busy_time;
- return 0;
+ busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
+ REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+
+ busy_time = (busy_cycles - gpu->devfreq.busy_cycles) /
+ (clk_get_rate(gpu->core_clk) / 100);
+
+ gpu->devfreq.busy_cycles = busy_cycles;
+
+ return busy_time;
}
static const struct adreno_gpu_funcs funcs = {
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index c5d4627..43e36d7 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -40,7 +40,11 @@ static int msm_devfreq_target(struct device *dev, unsigned
long *freq,
if (IS_ERR(opp))
return PTR_ERR(opp);
- clk_set_rate(gpu->core_clk, *freq);
+ if (gpu->funcs->gpu_set_freq)
+ gpu->funcs->gpu_set_freq(gpu, *freq);
+ else
+ clk_set_rate(gpu->core_clk, *freq);
+
dev_pm_opp_put(opp);
return 0;
@@ -50,16 +54,14 @@ static int msm_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *status)
{
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
- u64 cycles;
- u32 freq = ((u32) status->current_frequency) / 100;
ktime_t time;
- status->current_frequency = (unsigned long) clk_get_rate(gpu->core_clk);
- gpu->funcs->gpu_busy(gpu, );
-
- status->busy_time = ((u32) (cycles - gpu->devfreq.busy_cycles)) / freq;
+ if (gpu->funcs->gpu_get_freq)
+ status->current_frequency = gpu->funcs->gpu_get_freq(gpu);
+ else
+ status->current_frequency = clk_get_rate(gpu->core_clk);
- gpu->devfreq.busy_cycles = cycles;
+ status->busy_time = gpu->funcs->gpu_busy(gpu);
time = ktime_get();
status->total_time = ktime_us_delta(time, gpu->devfreq.time);
@@ -72,7 +74,10 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
unsigned long *freq)
{
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
- *freq = (unsigned long) clk_get_rate(gpu->core_clk);
+ if (gpu->funcs->gpu_get_freq)
+ *freq = gpu->funcs->gpu_get_freq(gpu);
+ else
+ *freq = clk_get_rate(gpu->core_clk);
return 0;
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 1876b81..000aae7 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -68,7 +68,9 @@ struct msm_gpu_funcs {
/* for generation specific debugfs: */
int (*debugfs_init)(struct msm_gpu *gpu, struct drm_minor *minor);
#endif
- int (*gpu_busy)(struct msm_gpu *gpu, uint64_t *value);
+ unsigned long (*gpu_busy)(struct msm_gpu *gpu);
+ unsigned long (*gpu_get_freq)(struct msm_gpu *gpu);
+ int (*gpu_set_freq)(struct msm_gpu *gpu, unsigned long freq);
};
struct msm_gpu {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] drm/msm: move suspend/resume devfreq to their own functions
This is needed for hardware revisions which do not rely on the generic
suspend, resume handlers for power management.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/msm_gpu.c | 23 +++
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index d7586f2..c5d4627 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -203,6 +203,19 @@ static int disable_axi(struct msm_gpu *gpu)
return 0;
}
+void msm_gpu_resume_devfreq(struct msm_gpu *gpu)
+{
+ gpu->devfreq.busy_cycles = 0;
+ gpu->devfreq.time = ktime_get();
+
+ devfreq_resume_device(gpu->devfreq.devfreq);
+}
+
+void msm_gpu_suspend_devfreq(struct msm_gpu *gpu)
+{
+ devfreq_suspend_device(gpu->devfreq.devfreq);
+}
+
int msm_gpu_pm_resume(struct msm_gpu *gpu)
{
int ret;
@@ -221,12 +234,7 @@ int msm_gpu_pm_resume(struct msm_gpu *gpu)
if (ret)
return ret;
- if (gpu->devfreq.devfreq) {
- gpu->devfreq.busy_cycles = 0;
- gpu->devfreq.time = ktime_get();
-
- devfreq_resume_device(gpu->devfreq.devfreq);
- }
+ msm_gpu_resume_devfreq(gpu);
gpu->needs_hw_init = true;
@@ -239,8 +247,7 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
DBG("%s", gpu->name);
- if (gpu->devfreq.devfreq)
- devfreq_suspend_device(gpu->devfreq.devfreq);
+ msm_gpu_suspend_devfreq(gpu);
ret = disable_axi(gpu);
if (ret)
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index b824117..1876b81 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -226,6 +226,8 @@ static inline void gpu_write64(struct msm_gpu *gpu, u32 lo,
u32 hi, u64 val)
int msm_gpu_pm_suspend(struct msm_gpu *gpu);
int msm_gpu_pm_resume(struct msm_gpu *gpu);
+void msm_gpu_resume_devfreq(struct msm_gpu *gpu);
+void msm_gpu_suspend_devfreq(struct msm_gpu *gpu);
int msm_gpu_hw_init(struct msm_gpu *gpu);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/4] drm/msm: unregister devfreq upon clean up
Call the devfreq_remove_device() API to remove the GPU devfreq instance
during GPU driver cleanup.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/msm_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 43e36d7..ef9987b 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -896,6 +896,8 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
WARN_ON(!list_empty(>active_list));
+ devfreq_remove_device(gpu->devfreq.devfreq);
+
for (i = 0; i < ARRAY_SIZE(gpu->rb); i++) {
msm_ringbuffer_destroy(gpu->rb[i]);
gpu->rb[i] = NULL;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm/msm: suspend devfreq on init
Devfreq turns on and starts recommending power level as soon as it is initialized. The GPU is still not powered on by the time the devfreq init happens and this leads to problems on GPU's where register access is needed to get/set power levels. So we start suspended and only restart devfreq when GPU is powered on. Signed-off-by: Sharat Masetty --- drivers/gpu/drm/msm/msm_gpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index 1c09acf..d7586f2 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -104,6 +104,8 @@ static void msm_devfreq_init(struct msm_gpu *gpu) dev_err(>pdev->dev, "Couldn't initialize GPU devfreq\n"); gpu->devfreq.devfreq = NULL; } + + devfreq_suspend_device(gpu->devfreq.devfreq); } static int enable_pwrrail(struct msm_gpu *gpu) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/4] re-factor devfreq common code
This series re-factors the devfreq code a bit in preparation for the upcoming A6x related devfreq changes. The code applies cleanly on 4.17 and has been verified on DB820C. V2: Addressed code review comments from Jordan Crouse. V3: Added a new patch for devfreq cleanup. Sharat Masetty (4): drm/msm: suspend devfreq on init drm/msm: move suspend/resume devfreq to their own functions drm/msm: re-factor devfreq code drm/msm: unregister devfreq upon clean up drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 --- drivers/gpu/drm/msm/msm_gpu.c | 50 +++ drivers/gpu/drm/msm/msm_gpu.h | 6 - 3 files changed, 50 insertions(+), 22 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/blend: Add per-plane pixel blend mode property
Hey, Op 30-05-18 om 13:23 schreef Lowry Li: > Pixel blend modes represent the alpha blending equation > selection, describing how the pixels from the current > plane are composited with the background. > > Add a pixel_blend_mode to drm_plane_state and a > blend_mode_property to drm_plane, and related support > functions. > > Defines three blend modes in drm_blend.h. > > Signed-off-by: Lowry Li > --- > drivers/gpu/drm/drm_atomic.c| 4 ++ > drivers/gpu/drm/drm_atomic_helper.c | 1 + > drivers/gpu/drm/drm_blend.c | 110 > > include/drm/drm_blend.h | 6 ++ > include/drm/drm_plane.h | 6 ++ > 5 files changed, 127 insertions(+) Can you rebase this on top of a kernel with alpha property support? Getting some nasty conflicts otherwise.. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> >> > > + if (tcon->quirks->needs_tcon_top) {
> >> > > + struct device_node *np;
> >> > > +
> >> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top", 0);
> >> > > + if (np) {
> >> > > + struct platform_device *pdev;
> >> > > +
> >> > > + pdev = of_find_device_by_node(np);
> >> > > + if (pdev)
> >> > > + tcon->tcon_top = platform_get_drvdata(pdev);
> >> > > + of_node_put(np);
> >> > > +
> >> > > + if (!tcon->tcon_top)
> >> > > + return -EPROBE_DEFER;
> >> > > + }
> >> > > + }
> >> > > +
> >> >
> >> > I might have missed it, but I've not seen the bindings additions for
> >> > that property. This shouldn't really be done that way anyway, instead
> >> > of using a direct phandle, you should be using the of-graph, with the
> >> > TCON-top sitting where it belongs in the flow of data.
> >>
> >> Just to answer to the first question, it did describe it in "[PATCH 07/15]
> >> dt-
> >> bindings: display: sun4i-drm: Add R40 HDMI pipeline".
> >>
> >> As why I designed it that way - HW representation could be described that
> >> way
> >> (ASCII art makes sense when fixed width font is used to view it):
> >>
> >> / LCD0/LVDS0
> >> / TCON-LCD0
> >> | \ MIPI DSI
> >> mixer0 |
> >>\/ TCON-LCD1 - LCD1/LVDS1
> >> TCON-TOP
> >>/\ TCON-TV0 - TVE0/RGB
> >> mixer1 | \
> >> | TCON-TOP - HDMI
> >> | /
> >> \ TCON-TV1 - TVE1/RGB
> >>
> >> This is a bit simplified, since there is also TVE-TOP, which is responsible
> >> for sharing 4 DACs between both TVE encoders. You can have two TV outs
> >> (PAL/
> >> NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even seems that
> >> you
> >> can arbitrarly choose which DAC is responsible for which signal, so there
> >> is a
> >> ton of possible end combinations, but I'm not 100% sure.
> >>
> >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
> >> suggest more possibilities, although some of them seem wrong, like RGB
> >> feeding
> >> from LCD TCON. That is confirmed to be wrong when checking BSP code.
> >>
> >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and LCD1
> >> for
> >> pin muxing, although I'm not sure why is that needed at all, since
> >> according
> >> to R40 datasheet, TVE0 and TVE1 pins are dedicated and not on PORT D and
> >> PORT
> >> H, respectively, as TCON-TOP documentation suggest. However, HSYNC and
> >> PSYNC
> >> lines might be shared between TVE (when it works in RGB mode) and LCD. But
> >> that is just my guess since I'm not really familiar with RGB and LCD
> >> interfaces.
> >>
> >> I'm really not sure what would be the best representation in OF-graph. Can
> >> you
> >> suggest one?
> >
> > Rob might disagree on this one, but I don't see anything wrong with
> > having loops in the graph. If the TCON-TOP can be both the input and
> > output of the TCONs, then so be it, and have it described that way in
> > the graph.
> >
> > The code is already able to filter out nodes that have already been
> > added to the list of devices we need to wait for in the component
> > framework, so that should work as well.
> >
> > And we'd need to describe TVE-TOP as well, even though we don't have a
> > driver for it yet. That will simplify the backward compatibility later
> > on.
>
> I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer that
> binds everything together, and provides signal routing, kind of like
> DE-TOP on A64. So the signal mux controls that were originally found
> in TCON0 and TVE0 were moved out.
>
> The driver needs to know about that, but the graph about doesn't make
> much sense directly. Without looking at the manual, I understand it to
> likely be one mux between the mixers and TCONs, and one between the
> TCON-TVs and HDMI. Would it make more sense to just have the graph
> connections between the muxed components, and remove TCON-TOP from
> it, like we had in the past? A phandle could be used to reference
> the TCON-TOP for mux controls, in addition to the clocks and resets.
>
> For TVE, we would need something to represent each of the output pins,
> so the device tree can actually describe what kind of signal, be it
> each component of RGB/YUV or composite video, is wanted on each pin,
> if any. This is also needed on the A20 for the Cubietruck, so we can
> describe which pins are tied to the VGA connector, and which one does
> R, G, or B.
I guess we'll see how the DT maintainers feel about this, but my
impression is that the OF graph should model the flow of data between
the devices. If there's a mux somewhere, then the data is definitely
going
Re: [PATCH 2/2] drm/etnaviv: properly implement mmaping of imported buffers
Am Dienstag, den 29.05.2018, 14:34 +0200 schrieb Daniel Vetter: > On Tue, May 29, 2018 at 11:08 AM, Lucas Stach wrote: > > Am Dienstag, den 29.05.2018, 10:20 +0200 schrieb Daniel Vetter: > > > On Fri, May 25, 2018 at 03:42:54PM +0200, Lucas Stach wrote: > > > > The intention of the existing code was to deflect the actual work > > > > of mmaping a dma-buf to the exporter, as that one probably knows best > > > > how to handle the buffer. Unfortunately the call to drm_gem_mmap did > > > > more than what etnaviv needs in this case by actually setting up the > > > > mapping. > > > > > > > > Move mapping setup to the shm buffer type mmap implementation so we > > > > only need to look up the BO and call the buffer type mmap function > > > > from the handler. > > > > > > > > Fixes mmap behavior with dma-buf imported and userptr buffers. > > > > > > You allow mmap on userptr buffers? That sounds really nasty ... > > > > No, we don't because that's obviously crazy, even more so on ARM with > > it's special rules about aliasing mappings. The current code is buggy > > in that it first sets up the mapping and then tells userspace the mmap > > failed. After this patch we properly reject userptr mmap outright. > > Ah, I didn't realize that. It sounded more like making userptr mmap > work, not rejecting it. Can't you instead just never register the mmap > offset for userptr objects? That would catch the invalid request even > earlier, and make it more obvious that mmap is not ok for userptr. > Would also remove the need to hand-roll an etnaviv version of > drm_gem_obj_mmap. Makes sense for userptr, not so much for imported dma-bufs, see below. > > > Also not really thrilled about dma-buf mmap forwarding either, since you > > > don't seem to forward the begin/end_cpu_access stuff either. > > > > Yeah, that's still missing, but IMHO more of a correctness fix (which > > can be done in a follow on patch), distinct of the bugfix in this > > patch. > > Yeah drm_gem_obj_mmap should check for obj->import_attach imo and > scream. Maybe we should even have that check when allocating the mmap > offset, since having an mmap offset for something you can never mmap > is silly. And obj->import_attach isn't allowed to change over the > lifetime of an object. Agreed for drm_gem_obj_mmap, but I don't follow why we would reject mmap of an imported dma-buf. This seems to be a feature we want today for drivers that need to talk to multiple DRM devices, like Etnaviv, Tegra and VC4 in some cases. Making the mmap look uniform by allowing the mmap on one device and internally deflecting to the exporter is a big pro from the userspace driver writer PoV. Also if you think about stuff like ION (not that I would agree that ION is a good idea in general, but whatever), a lot of buffers end up being allocated by ION. I don't want driver writers to care where a buffer was allocated, but rather call the usual mmap on the device they are working with and do the right thing in the kernel. Maybe we can just generalize the deflecting to the exporter and implement it in the DRM core, rather than rolling our own version in etnaviv. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #18 from Pixie --- Where would I enter that? -- 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] drm-misc-next-fixes
Hi Dave, Finally got my send-mail script sorted out. A few bugfixes for drm-next. drm-misc-next-fixes-2018-05-31: drm-misc-next-fixes for v4.18: Driver changes: - Plug small memory leak in vc4. (anholt) - Depend on MMU in v3d. (arnd) The following changes since commit 2045b22461c07a88dc3d2bab3cbfc6dc0c602fd4: Merge tag 'drm-misc-next-2018-05-15' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-05-15 19:25:07 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-05-31 for you to fetch changes up to fbecef131676c1d18e8e6b42c04e10dc49725e96: drm/v3d: add CONFIG_MMU dependency (2018-05-30 12:15:18 -0700) drm-misc-next-fixes for v4.18: Driver changes: - Plug small memory leak in vc4. (anholt) - Depend on MMU in v3d. (arnd) Arnd Bergmann (1): drm/v3d: add CONFIG_MMU dependency Eric Anholt (1): drm/vc4: Fix leak of the file_priv that stored the perfmon. drivers/gpu/drm/v3d/Kconfig | 1 + drivers/gpu/drm/vc4/vc4_drv.c | 1 + 2 files changed, 2 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106735] [amdgpu] all displays reconnect after failed EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=106735 Michel Dänzer changed: What|Removed |Added Attachment #139861|text/x-log |text/plain mime type|| -- 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 106735] [amdgpu] all displays reconnect after failed EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=106735 Michel Dänzer changed: What|Removed |Added Attachment #139862|text/x-log |text/plain mime type|| -- 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 v2] drm: Add checks for NULL drm_*_helper_funcs
On Wed, May 30, 2018 at 03:42:59AM +0300, Haneen Mohammed wrote:
> This patch add checks for NULL drm_[connector/crtc/plane]_helper_funcs
> pointers before derefrencing the variable to avoid NULL pointer
> dereference and make the helper functions optional in the following
> cases:
>
> 1) when using drm_helper_probe_single_connector_modes for fill_modes
> callback in the drm_connector_funcs.
> 2) using drm_atomic_helper_[check/commit] for atomic_[check/commit]
> callbacks in the drm_mode_config_funcs.
>
> The dependency is as follow:
>
> drm_connector_funcs:
> * fill_modes = drm_helper_probe_single_connector_modes
> b) drm_helper_probe_detect -> drm_connector_helper_funcs
>
> drm_mode_config_funcs:
> * atomic_check = drm_atomic_helper_check
> a) drm_atomic_helper_check_modeset -> drm_connector helper_funcs
> a) handle_conflicting_encoders -> drm_connector_helper_funcs
> b) mode_fixup -> drm_crtc_helper_funcs
> c) update_connector_routing -> drm_connectot_helper_funcs
>
> * atomic_commit = drm_atomic_helper_commit
> a) drm_atomic_helper_prepare_planes -> drm_plane_helper_funcs
> b) drm_atomic_helper_cleanup_planes -> drm_plane_helper_funcs
>
> Signed-off-by: Haneen Mohammed
Ok, I think making drm_connector_helper_funcs optional makes some sense -
->best_connector has a default implemenation that works for almost
everyone, and if you don't have a way to detect the output it's silly to
have a default implementation that does nothing.
But making the plane/crtc funcs optional gives you a driver which does
exactly nothing, and that's not terribly useful.
I think respinning this to just make drm_connector_helper_funcs optional
is reasonable, and for all others we need to start making vkms functional
:-)
Cheers, Daniel
> ---
> Chanes in v2:
> - add the least amount of checks to make the helpers optional for vkms
>
> drivers/gpu/drm/drm_atomic_helper.c | 16
> drivers/gpu/drm/drm_probe_helper.c | 5 +++--
> 2 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2a7ceca82b9e..ff3684c4a83c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -112,9 +112,9 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state,
> if (!new_conn_state->crtc)
> continue;
>
> - if (funcs->atomic_best_encoder)
> + if (funcs && funcs->atomic_best_encoder)
> new_encoder = funcs->atomic_best_encoder(connector,
> new_conn_state);
> - else if (funcs->best_encoder)
> + else if (funcs && funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> else
> new_encoder = drm_atomic_helper_best_encoder(connector);
> @@ -308,10 +308,10 @@ update_connector_routing(struct drm_atomic_state *state,
>
> funcs = connector->helper_private;
>
> - if (funcs->atomic_best_encoder)
> + if (funcs && funcs->atomic_best_encoder)
> new_encoder = funcs->atomic_best_encoder(connector,
>new_connector_state);
> - else if (funcs->best_encoder)
> + else if (funcs && funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> else
> new_encoder = drm_atomic_helper_best_encoder(connector);
> @@ -438,7 +438,7 @@ mode_fixup(struct drm_atomic_state *state)
> continue;
>
> funcs = crtc->helper_private;
> - if (!funcs->mode_fixup)
> + if (!funcs || !funcs->mode_fixup)
> continue;
>
> ret = funcs->mode_fixup(crtc, _crtc_state->mode,
> @@ -639,7 +639,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> new_crtc_state->connectors_changed = true;
> }
>
> - if (funcs->atomic_check)
> + if (funcs && funcs->atomic_check)
> ret = funcs->atomic_check(connector,
> new_connector_state);
> if (ret)
> return ret;
> @@ -2117,7 +2117,7 @@ int drm_atomic_helper_prepare_planes(struct drm_device
> *dev,
>
> funcs = plane->helper_private;
>
> - if (funcs->prepare_fb) {
> + if (funcs && funcs->prepare_fb) {
> ret = funcs->prepare_fb(plane, new_plane_state);
> if (ret)
> goto fail;
> @@ -2412,7 +2412,7 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
> *dev,
>
> funcs = plane->helper_private;
>
> - if (funcs->cleanup_fb)
> + if (funcs && funcs->cleanup_fb)
> funcs->cleanup_fb(plane, plane_state);
> }
> }
> diff --git
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/30/2018 10:24 PM, Boris Ostrovsky wrote:
On 05/30/2018 01:46 PM, Oleksandr Andrushchenko wrote:
On 05/30/2018 06:54 PM, Boris Ostrovsky wrote:
BTW, I also think you can further simplify
xenmem_reservation_va_mapping_* routines by bailing out right away if
xen_feature(XENFEAT_auto_translated_physmap). In fact, you might even
make them inlines, along the lines of
inline void xenmem_reservation_va_mapping_reset(unsigned long count,
struct page **pages)
{
#ifdef CONFIG_XEN_HAVE_PVMMU
if (!xen_feature(XENFEAT_auto_translated_physmap))
__xenmem_reservation_va_mapping_reset(...)
#endif
}
How about:
#ifdef CONFIG_XEN_HAVE_PVMMU
static inline __xenmem_reservation_va_mapping_reset(struct page *page)
{
[...]
}
#endif
and
void xenmem_reservation_va_mapping_reset(unsigned long count,
struct page **pages)
{
#ifdef CONFIG_XEN_HAVE_PVMMU
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
int i;
for (i = 0; i < count; i++)
__xenmem_reservation_va_mapping_reset(pages[i]);
}
#endif
}
This way I can use __xenmem_reservation_va_mapping_reset(page);
instead of xenmem_reservation_va_mapping_reset(1, );
Sure, this also works.
Could you please take look at the patch attached if this is what we want?
-boris
Thank you,
Oleksandr
>From d41751068ac80ca5a375909d6c01cb25716a4975 Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko
Date: Wed, 23 May 2018 16:52:45 +0300
Subject: [PATCH] xen/balloon: Share common memory reservation routines
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated file for the shared code and export corresponding
symbols for other kernel modules.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 71 ++---
drivers/xen/mem-reservation.c | 78 +++
include/xen/mem-reservation.h | 114 ++
4 files changed, 199 insertions(+), 65 deletions(-)
create mode 100644 drivers/xen/mem-reservation.c
create mode 100644 include/xen/mem-reservation.h
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 451e833f5931..3c87b0c3aca6 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
obj-$(CONFIG_X86) += fallback.o
obj-y += grant-table.o features.o balloon.o manage.o preempt.o time.o
+obj-y += mem-reservation.o
obj-y += events/
obj-y += xenbus/
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 065f0b607373..1789be76e9c5 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -71,6 +71,7 @@
#include
#include
#include
+#include
static int xen_hotplug_unpopulated;
@@ -157,13 +158,6 @@ static DECLARE_DELAYED_WORK(balloon_worker, balloon_process);
#define GFP_BALLOON \
(GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC)
-static void scrub_page(struct page *page)
-{
-#ifdef CONFIG_XEN_SCRUB_PAGES
- clear_highpage(page);
-#endif
-}
-
/* balloon_append: add the given page to the balloon. */
static void __balloon_append(struct page *page)
{
@@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
int rc;
unsigned long i;
struct page *page;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid= DOMID_SELF
- };
if (nr_pages > ARRAY_SIZE(frame_list))
nr_pages = ARRAY_SIZE(frame_list);
@@ -486,9 +475,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
page = balloon_next_page(page);
}
- set_xen_guest_handle(reservation.extent_start, frame_list);
- reservation.nr_extents = nr_pages;
- rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, );
+ rc = xenmem_reservation_increase(nr_pages, frame_list);
if (rc <= 0)
return BP_EAGAIN;
@@ -496,29 +483,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
page = balloon_retrieve(false);
BUG_ON(page == NULL);
-#ifdef CONFIG_XEN_HAVE_PVMMU
- /*
- * We don't support PV MMU when Linux and Xen is using
- * different page granularity.
- */
- BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
-
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- unsigned long pfn = page_to_pfn(page);
-
- set_phys_to_machine(pfn, frame_list[i]);
-
- /* Link back into the page tables if not highmem. */
- if (!PageHighMem(page)) {
-int ret;
-ret = HYPERVISOR_update_va_mapping(
- (unsigned long)__va(pfn << PAGE_SHIFT),
- mfn_pte(frame_list[i], PAGE_KERNEL),
- 0);
-BUG_ON(ret);
- }
- }
-#endif
+ __xenmem_reservation_va_mapping_update(page, frame_list[i]);
/* Relinquish the page back to the allocator. */
free_reserved_page(page);
@@ -535,11 +500,6 @@ static
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 Michel Dänzer changed: What|Removed |Added CC||harry.wentl...@amd.com --- Comment #17 from Michel Dänzer --- Does amdgpu.dc=0 on the kernel command line work around the problem? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix possible race conditions while unplugging DRM device
On 05/29/2018 10:49 AM, Daniel Vetter wrote:
On Tue, May 29, 2018 at 10:09:57AM +0300, Oleksandr Andrushchenko wrote:
On 05/29/2018 10:02 AM, Daniel Vetter wrote:
On Tue, May 22, 2018 at 05:13:04PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
When unplugging a hotpluggable DRM device we first unregister it
with drm_dev_unregister and then set drm_device.unplugged flag which
is used to mark device critical sections with drm_dev_enter()/
drm_dev_exit() preventing access to device resources that are not
available after the device is gone.
But drm_dev_unregister may lead to hotplug uevent(s) fired to
user-space on card and/or connector removal, thus making it possible
for user-space to try accessing a disconnected device.
Fix this by first making sure device is properly marked as
disconnected and only then unregister it.
Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged")
Signed-off-by: Oleksandr Andrushchenko
Reported-by: Andrii Chepurnyi
Cc: "Noralf Trønnes"
Nice catch.
Reviewed-by: Daniel Vetter
I think you need to push this to drm-misc-next-fixes to make sure it's on
the 4.17 train.
Sure, after I have r-b from Noralf
Noralf's occasionally occupied with other things and doesn't have time to
look at patches. I think it's ok to just push after a few more days, even
if he doesn't respond. Same holds for other people really.
-Daniel
Applied to drm-misc-next-fixes
-Daniel
---
drivers/gpu/drm/drm_drv.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b553a6f2ff0e..7af748ed1c58 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -369,13 +369,6 @@ EXPORT_SYMBOL(drm_dev_exit);
*/
void drm_dev_unplug(struct drm_device *dev)
{
- drm_dev_unregister(dev);
-
- mutex_lock(_global_mutex);
- if (dev->open_count == 0)
- drm_dev_put(dev);
- mutex_unlock(_global_mutex);
-
/*
* After synchronizing any critical read section is guaranteed to see
* the new value of ->unplugged, and any critical section which might
@@ -384,6 +377,13 @@ void drm_dev_unplug(struct drm_device *dev)
*/
dev->unplugged = true;
synchronize_srcu(_unplug_srcu);
+
+ drm_dev_unregister(dev);
+
+ mutex_lock(_global_mutex);
+ if (dev->open_count == 0)
+ drm_dev_put(dev);
+ mutex_unlock(_global_mutex);
}
EXPORT_SYMBOL(drm_dev_unplug);
--
2.17.0
___
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add checks for NULL drm_*_helper_funcs
On Tue, May 29, 2018 at 12:03:24PM +0300, Haneen Mohammed wrote: > On Tue, May 29, 2018 at 10:03:53AM +0200, Daniel Vetter wrote: > > On Fri, May 25, 2018 at 05:20:08AM +0300, Haneen Mohammed wrote: > > > This patch add checks for NULL drm_[connector/crtc/plane]_helper_funcs > > > pointers before derefrencing the variable to avoid NULL pointer > > > dereference and make the helper functions as optional as possible. > > > > > > Signed-off-by: Haneen Mohammed > > > > I started reviewing this, and then realized it's a bit a can of worms. > > E.g. connector->funcs->detect shouldn't be there, it's a helper callback > > really (but placed in the wrong function table). So connector->funcs isn't > > optional, but connector->funcs->detect maybe should be optional. > > > > So I'm not sure anymore whether doing this holesale is a good idea. Do we > > still need this for vkms? If yes, then a more focused patch to just make > > the things optional that vkms does not (yet) provide might be better. > > Including an explanation of what exactly blows up in vkms. > > > > hm only for running the igt tests & modetest in libdrm. > > It was easier to add check for all the funcs, but I will check again the > least amount of checks needed for vkms. To clarify what I'm looking for: I think a more specific approach like "vkms doesn have funcs for $object, and that makes sense because $reason." I think making some of the funcs optional might not make any sense at all, since any working driver needs them. vkms atm is special, since it just absolutely nothing right now (but that will change). The goal here is to make driver writing easier by only requiring what's really needed, not mislead them by not requiring stuff that really should be there for a working driver :-) -Daniel > > Thank you! > Haneen > > > Thanks, Daniel > > > --- > > > drivers/gpu/drm/drm_atomic_helper.c | 42 +++-- > > > drivers/gpu/drm/drm_probe_helper.c | 11 > > > 2 files changed, 28 insertions(+), 25 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > > b/drivers/gpu/drm/drm_atomic_helper.c > > > index c35654591c12..52092deb741d 100644 > > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > > @@ -112,9 +112,9 @@ static int handle_conflicting_encoders(struct > > > drm_atomic_state *state, > > > if (!new_conn_state->crtc) > > > continue; > > > > > > - if (funcs->atomic_best_encoder) > > > + if (funcs && funcs->atomic_best_encoder) > > > new_encoder = funcs->atomic_best_encoder(connector, > > > new_conn_state); > > > - else if (funcs->best_encoder) > > > + else if (funcs && funcs->best_encoder) > > > new_encoder = funcs->best_encoder(connector); > > > else > > > new_encoder = drm_atomic_helper_best_encoder(connector); > > > @@ -308,10 +308,10 @@ update_connector_routing(struct drm_atomic_state > > > *state, > > > > > > funcs = connector->helper_private; > > > > > > - if (funcs->atomic_best_encoder) > > > + if (funcs && funcs->atomic_best_encoder) > > > new_encoder = funcs->atomic_best_encoder(connector, > > >new_connector_state); > > > - else if (funcs->best_encoder) > > > + else if (funcs && funcs->best_encoder) > > > new_encoder = funcs->best_encoder(connector); > > > else > > > new_encoder = drm_atomic_helper_best_encoder(connector); > > > @@ -438,7 +438,7 @@ mode_fixup(struct drm_atomic_state *state) > > > continue; > > > > > > funcs = crtc->helper_private; > > > - if (!funcs->mode_fixup) > > > + if (!funcs || !funcs->mode_fixup) > > > continue; > > > > > > ret = funcs->mode_fixup(crtc, _crtc_state->mode, > > > @@ -639,7 +639,7 @@ drm_atomic_helper_check_modeset(struct drm_device > > > *dev, > > > new_crtc_state->connectors_changed = true; > > > } > > > > > > - if (funcs->atomic_check) > > > + if (funcs && funcs->atomic_check) > > > ret = funcs->atomic_check(connector, > > > new_connector_state); > > > if (ret) > > > return ret; > > > @@ -681,7 +681,7 @@ drm_atomic_helper_check_modeset(struct drm_device > > > *dev, > > > if (connectors_mask & BIT(i)) > > > continue; > > > > > > - if (funcs->atomic_check) > > > + if (funcs && funcs->atomic_check) > > > ret = funcs->atomic_check(connector, > > > new_connector_state); > > > if (ret) > > > return ret; > > > @@ -972,14 +972,16 @@ disable_outputs(struct drm_device *dev, struct > > > drm_atomic_state *old_state) > > > > > > > > > /* Right function depends upon target state. */ > > > - if
[PATCH v2 01/10] drm/exynos: rename "bridge_node" to "mic_bridge_node"
When adding support for peripheral out bridges, the "bridge" name
becomes imprecise as it refers to a different device than the
"out_bridge".
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index eae44fd..9599e6b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -279,7 +279,7 @@ struct exynos_dsi {
struct list_head transfer_list;
const struct exynos_dsi_driver_data *driver_data;
- struct device_node *bridge_node;
+ struct device_node *mic_bridge_node;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
- dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
+ dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
return 0;
}
@@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
struct drm_encoder *encoder = dev_get_drvdata(dev);
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
struct drm_device *drm_dev = data;
- struct drm_bridge *bridge;
+ struct drm_bridge *mic_bridge;
int ret;
drm_encoder_init(drm_dev, encoder, _dsi_encoder_funcs,
@@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
return ret;
}
- if (dsi->bridge_node) {
- bridge = of_drm_find_bridge(dsi->bridge_node);
- if (bridge)
- drm_bridge_attach(encoder, bridge, NULL);
+ if (dsi->mic_bridge_node) {
+ mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
+ if (mic_bridge)
+ drm_bridge_attach(encoder, mic_bridge, NULL);
}
return mipi_dsi_host_register(>dsi_host);
@@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device *pdev)
{
struct exynos_dsi *dsi = platform_get_drvdata(pdev);
- of_node_put(dsi->bridge_node);
+ of_node_put(dsi->mic_bridge_node);
pm_runtime_disable(>dev);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/10] Add TOSHIBA TC358764 DSI/LVDS bridge driver
Hi all, this patchset is a next attempt to add the tc358764 driver. The previous one can be found here: https://lists.freedesktop.org/archives/dri-devel/2014-February/053705.html Back then, TC358764 was added as a panel driver. The bridge is supposed to be a DSI peripheral. Currently exynos_dsi accepts only panels as its peripherals. Therefore, some logic in exynos_dsi had to be ammended. That is implemented in first 4 patches. Apart from the driver this patchset adds support for BOE HV070WSA-100 panel, which is used by TC358764 and dts nodes to exynos5250.dtsi and exynos5250-arndale.dtsi. Best regards, Maciej Purski --- Changes in v2: - fix commits authorship - don't call pm_runtime_put_sync() in exyons_dsi_disable(), if pm_runtime_get_sync() has not been called - squash dts commits - merge some redundant regulators in tc358764 bindings and in DTS - fix kbuild robot errors Andrzej Hajda (6): panel/hv070wsa-100: add DT bindings drm/panel: add support for BOE HV070WSA-100 panel to simple-panel dt-bindings: tc358754: add DT bindings drm/bridge: tc358764: Add DSI to LVDS bridge driver ARM: dts: exynos5250: add DSI node ARM: dts: exynos5250-arndale: add DSI and panel nodes Maciej Purski (4): drm/exynos: rename "bridge_node" to "mic_bridge_node" drm/exynos: move pm_runtime_get_sync() to exynos_dsi_init() drm/exynos: move connector creation to attach callback drm/exynos: add non-panel path to exynos_dsi_enable() .../bindings/display/bridge/toshiba,tc358764.txt | 37 ++ .../bindings/display/panel/boe,hv070wsa-100.txt| 7 + arch/arm/boot/dts/exynos5250-arndale.dts | 61 +++ arch/arm/boot/dts/exynos5250.dtsi | 21 + drivers/gpu/drm/bridge/Kconfig | 9 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/tc358764.c | 547 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 88 ++-- drivers/gpu/drm/panel/panel-simple.c | 25 + 9 files changed, 755 insertions(+), 41 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt create mode 100644 Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt create mode 100644 drivers/gpu/drm/bridge/tc358764.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/10] ARM: dts: exynos5250-arndale: add DSI and panel nodes
From: Andrzej Hajda
The patch adds bridge and panel nodes.
It adds also DSI properties specific for arndale board and
regulators required by the bridge.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
arch/arm/boot/dts/exynos5250-arndale.dts | 61
1 file changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 7a8a5c5..816d89d 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -71,6 +71,17 @@
};
};
+ panel: panel {
+ compatible = "boe,hv070wsa-100";
+ power-supply = <_3v3_reg>;
+ enable-gpios = < 3 GPIO_ACTIVE_HIGH>;
+ port {
+ panel_ep: endpoint {
+ remote-endpoint = <_out_ep>;
+ };
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -97,6 +108,30 @@
reg = <2>;
regulator-name = "hdmi-en";
};
+
+ vcc_1v2_reg: regulator@3 {
+ compatible = "regulator-fixed";
+ reg = <3>;
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ };
+
+ vcc_1v8_reg: regulator@4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ vcc_3v3_reg: regulator@5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
};
fixed-rate-clocks {
@@ -119,6 +154,32 @@
cpu0-supply = <_reg>;
};
+_0 {
+ vddcore-supply = <_reg>;
+ vddio-supply = <_reg>;
+ samsung,pll-clock-frequency = <2400>;
+ samsung,burst-clock-frequency = <32000>;
+ samsung,esc-clock-frequency = <1000>;
+ status = "okay";
+
+ bridge@0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <_1v2_reg>;
+ vddio-supply = <_1v8_reg>;
+ vddlvds-supply = <_3v3_reg>;
+ reset-gpios = < 6 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+ bridge_out_ep: endpoint {
+ remote-endpoint = <_ep>;
+ };
+ };
+ };
+};
+
{
status = "okay";
samsung,color-space = <0>;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 39/41] drm/i915: Implement the HDCP2.2 support for HDMI
On Mon, May 21, 2018 at 06:23:58PM +0530, Ramalingam C wrote:
> Implements the HDMI adaptation specific HDCP2.2 operations.
>
> Basically these are DDC read and write for authenticating through
> HDCP2.2 messages.
>
> v2:
> Rebased.
> v3:
> No Changes.
> v4:
> No more special handling of Gmbus burst read for AKE_SEND_CERT.
> Style fixed with few naming. [Uma]
> %s/PARING/PAIRING
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 186
> ++
> 1 file changed, 186 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index a5cc73101acb..042205e57e42 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1106,6 +1107,186 @@ bool intel_hdmi_hdcp_check_link(struct
> intel_digital_port *intel_dig_port)
> return true;
> }
>
> +static
> +int intel_hdmi_hdcp2_read_rx_status(struct intel_digital_port
> *intel_dig_port,
> + uint8_t *rx_status)
> +{
> + return intel_hdmi_hdcp_read(intel_dig_port,
> + HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET,
> + rx_status,
> + HDCP_2_2_HDMI_RXSTATUS_LEN);
> +}
> +
> +static inline
> +int intel_hdmi_hdcp2_timeout_for_msg(uint8_t msg_id, bool is_paired)
So at a glance this is the same timeout stuff as for dp. I think this
should be moved out of the low-level callbacks into commont code. Maybe
wrap the low-level callbacks for read/write into small helper functions,
which then also do the timeout handling?
And I think the timeouts and availability checks should be done in the
hdcp flow directly, instead of far away from where the register read/write
is issue. Just to keep the entire register i/o closely together.
-Daniel
> +{
> + int timeout;
> +
> + switch (msg_id) {
> + case HDCP_2_2_AKE_SEND_CERT:
> + timeout = HDCP_2_2_CERT_TIMEOUT;
> + break;
> + case HDCP_2_2_AKE_SEND_HPRIME:
> + if (is_paired)
> + timeout = HDCP_2_2_HPRIME_PAIRED_TIMEOUT;
> + else
> + timeout = HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT;
> + break;
> + case HDCP_2_2_AKE_SEND_PAIRING_INFO:
> + timeout = HDCP_2_2_PAIRING_TIMEOUT;
> + break;
> + case HDCP_2_2_LC_SEND_LPRIME:
> + timeout = HDCP_2_2_HDMI_LPRIME_TIMEOUT;
> + break;
> + case HDCP_2_2_REP_SEND_RECVID_LIST:
> + timeout = HDCP_2_2_RECVID_LIST_TIMEOUT;
> + break;
> + case HDCP_2_2_REP_STREAM_READY:
> + timeout = HDCP_2_2_STREAM_READY_TIMEOUT;
> + break;
> + default:
> + timeout = -EINVAL;
> + DRM_ERROR("Unsupported msg_id: %d\n", (int)msg_id);
> + }
> +
> + return timeout;
> +}
> +
> +static inline
> +int hdcp2_detect_msg_availability(struct intel_digital_port
> *intel_digital_port,
> + uint8_t msg_id, bool *msg_ready,
> + ssize_t *msg_sz)
> +{
> + uint8_t rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
> + int ret;
> +
> + ret = intel_hdmi_hdcp2_read_rx_status(intel_digital_port, rx_status);
> + if (ret < 0) {
> + DRM_DEBUG_KMS("rx_status read failed. Err %d\n", ret);
> + return ret;
> + }
> +
> + *msg_sz = ((HDCP_2_2_HDMI_RXSTATUS_MSG_SZ_HI(rx_status[1]) << 8) |
> + rx_status[0]);
> +
> + if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST)
> + *msg_ready = (HDCP_2_2_HDMI_RXSTATUS_READY(rx_status[1]) &&
> + *msg_sz);
> + else
> + *msg_ready = *msg_sz;
> +
> + return 0;
> +}
> +
> +static ssize_t
> +intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
> + uint8_t msg_id, bool paired)
> +{
> + bool msg_ready = false;
> + int timeout, ret;
> + ssize_t msg_sz;
> +
> + timeout = intel_hdmi_hdcp2_timeout_for_msg(msg_id, paired);
> + if (timeout < 0)
> + return timeout;
> +
> + ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
> + msg_id, _ready, _sz),
> + !ret && msg_ready && msg_sz, timeout * 1000,
> + 1000, 5 * 1000);
> + if (ret)
> + DRM_ERROR("msg_id: %d, ret: %d, timeout: %d\n",
> + msg_id, ret, timeout);
> +
> + return ret ? ret : msg_sz;
> +}
> +
> +static
> +int intel_hdmi_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
> +void *buf, size_t size)
> +{
> + unsigned int offset;
> +
> + offset = HDCP_2_2_HDMI_REG_WR_MSG_OFFSET;
> + return intel_hdmi_hdcp_write(intel_dig_port,
[PATCH v2 3/3] drm/msm: re-factor devfreq code
devfreq framework requires the drivers to provide busy time estimations.
The GPU driver relies on the hardware performance counters for the busy time
estimations, but different hardware revisions have counters which can be
sourced from different clocks. So the busy time estimation will be target
dependent. Additionally on targets where the clocks are completely controlled
by the on chip microcontroller, fetching and setting the current GPU frequency
will be different. This patch aims to embrace these differences by re-factoring
the devfreq code a bit.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16
drivers/gpu/drm/msm/msm_gpu.c | 23 ++-
drivers/gpu/drm/msm/msm_gpu.h | 4 +++-
3 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d39400e..5cdf104 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1219,12 +1219,20 @@ static struct msm_ringbuffer *a5xx_active_ring(struct
msm_gpu *gpu)
return a5xx_gpu->cur_ring;
}
-static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t *value)
+static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
{
- *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
- REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+ u64 busy_cycles;
+ unsigned long busy_time;
- return 0;
+ busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
+ REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+
+ busy_time = (busy_cycles - gpu->devfreq.busy_cycles) /
+ (clk_get_rate(gpu->core_clk) / 100);
+
+ gpu->devfreq.busy_cycles = busy_cycles;
+
+ return busy_time;
}
static const struct adreno_gpu_funcs funcs = {
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index c5d4627..43e36d7 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -40,7 +40,11 @@ static int msm_devfreq_target(struct device *dev, unsigned
long *freq,
if (IS_ERR(opp))
return PTR_ERR(opp);
- clk_set_rate(gpu->core_clk, *freq);
+ if (gpu->funcs->gpu_set_freq)
+ gpu->funcs->gpu_set_freq(gpu, *freq);
+ else
+ clk_set_rate(gpu->core_clk, *freq);
+
dev_pm_opp_put(opp);
return 0;
@@ -50,16 +54,14 @@ static int msm_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *status)
{
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
- u64 cycles;
- u32 freq = ((u32) status->current_frequency) / 100;
ktime_t time;
- status->current_frequency = (unsigned long) clk_get_rate(gpu->core_clk);
- gpu->funcs->gpu_busy(gpu, );
-
- status->busy_time = ((u32) (cycles - gpu->devfreq.busy_cycles)) / freq;
+ if (gpu->funcs->gpu_get_freq)
+ status->current_frequency = gpu->funcs->gpu_get_freq(gpu);
+ else
+ status->current_frequency = clk_get_rate(gpu->core_clk);
- gpu->devfreq.busy_cycles = cycles;
+ status->busy_time = gpu->funcs->gpu_busy(gpu);
time = ktime_get();
status->total_time = ktime_us_delta(time, gpu->devfreq.time);
@@ -72,7 +74,10 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
unsigned long *freq)
{
struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
- *freq = (unsigned long) clk_get_rate(gpu->core_clk);
+ if (gpu->funcs->gpu_get_freq)
+ *freq = gpu->funcs->gpu_get_freq(gpu);
+ else
+ *freq = clk_get_rate(gpu->core_clk);
return 0;
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 1876b81..000aae7 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -68,7 +68,9 @@ struct msm_gpu_funcs {
/* for generation specific debugfs: */
int (*debugfs_init)(struct msm_gpu *gpu, struct drm_minor *minor);
#endif
- int (*gpu_busy)(struct msm_gpu *gpu, uint64_t *value);
+ unsigned long (*gpu_busy)(struct msm_gpu *gpu);
+ unsigned long (*gpu_get_freq)(struct msm_gpu *gpu);
+ int (*gpu_set_freq)(struct msm_gpu *gpu, unsigned long freq);
};
struct msm_gpu {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] drm/rockchip: try to fix vblank hang resulting from iommu irq change
On Mon, 2018-05-28 at 15:20 +0200, Heiko Stuebner wrote: > This still tries to address the hang seen by Ezequiel Garcia on rk3288. > > As Tomasz noted, trying to count enablement can run into concurrency > issues, so instead we'll just check if the vop is runtime-enabled > to see if it could be the source of the irq and then just do our > own clk_enable in the isr to bridge the possible gap between > pm_runtime_enable and clk_enable in the core vop_enable() function. > > Display tested to still work on rk3328 and rk3399, but as I don't see > the hang from Ezequiel I hope that this fixes it. > Yup, this series fixes the issue I reported. Thanks for fixing so quickly. Tested-by: Ezequiel Garcia BTW, don't the patches need some stable tags as well? Regards, Eze ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/30/2018 01:46 PM, Oleksandr Andrushchenko wrote:
> On 05/30/2018 06:54 PM, Boris Ostrovsky wrote:
>>
>>
>> BTW, I also think you can further simplify
>> xenmem_reservation_va_mapping_* routines by bailing out right away if
>> xen_feature(XENFEAT_auto_translated_physmap). In fact, you might even
>> make them inlines, along the lines of
>>
>> inline void xenmem_reservation_va_mapping_reset(unsigned long count,
>> struct page **pages)
>> {
>> #ifdef CONFIG_XEN_HAVE_PVMMU
>> if (!xen_feature(XENFEAT_auto_translated_physmap))
>> __xenmem_reservation_va_mapping_reset(...)
>> #endif
>> }
> How about:
>
> #ifdef CONFIG_XEN_HAVE_PVMMU
> static inline __xenmem_reservation_va_mapping_reset(struct page *page)
> {
> [...]
> }
> #endif
>
> and
>
> void xenmem_reservation_va_mapping_reset(unsigned long count,
> struct page **pages)
> {
> #ifdef CONFIG_XEN_HAVE_PVMMU
> if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> int i;
>
> for (i = 0; i < count; i++)
> __xenmem_reservation_va_mapping_reset(pages[i]);
> }
> #endif
> }
>
> This way I can use __xenmem_reservation_va_mapping_reset(page);
> instead of xenmem_reservation_va_mapping_reset(1, );
Sure, this also works.
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA
On 05/30/2018 02:34 AM, Oleksandr Andrushchenko wrote:
> On 05/29/2018 10:10 PM, Boris Ostrovsky wrote:
>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>> +/**
>> + * gnttab_dma_free_pages - free DMAable pages
>> + * @args: arguments to the function
>> + */
>> +int gnttab_dma_free_pages(struct gnttab_dma_alloc_args *args)
>> +{
>> + xen_pfn_t *frames;
>> + size_t size;
>> + int i, ret;
>> +
>> + gnttab_pages_clear_private(args->nr_pages, args->pages);
>> +
>> + frames = kcalloc(args->nr_pages, sizeof(*frames), GFP_KERNEL);
>>
>> Any way you can do it without allocating memory? One possibility is to
>> keep allocated frames from gnttab_dma_alloc_pages(). (Not sure I like
>> that either but it's the only thing I can think of).
> Yes, I was also thinking about storing the allocated frames array from
> gnttab_dma_alloc_pages(), but that seemed not to be clear enough as
> the caller of the gnttab_dma_alloc_pages will need to store those frames
> in some context, so we can pass them on free. But the caller doesn't
> really
> need the frames which might confuse, so I decided to make those
> allocations
> on the fly.
> But I can still rework that to store the frames if you insist: please
> let me know.
I would prefer not to allocate anything in the release path. Yes, I
realize that dragging frames array around is not necessary but IMO it's
better than potentially failing an allocation during a teardown. A
comment in the struct definition could explain the reason for having
this field.
>>
>>
>>> + if (!frames)
>>> + return -ENOMEM;
>>> +
>>> + for (i = 0; i < args->nr_pages; i++)
>>> + frames[i] = page_to_xen_pfn(args->pages[i]);
>>
>> Not xen_page_to_gfn()?
> Well, according to [1] it should be :
> /* XENMEM_populate_physmap requires a PFN based on Xen
> * granularity.
> */
> frame_list[i] = page_to_xen_pfn(page);
Ah, yes. I was looking at decrease_reservation and automatically assumed
the same parameter type.
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/10] dt-bindings: tc358754: add DT bindings
From: Andrzej Hajda
The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
Bindings describe power supplies, reset gpio and video interfaces.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
.../bindings/display/bridge/toshiba,tc358764.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
new file mode 100644
index 000..6eda14f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
@@ -0,0 +1,37 @@
+TC358764 MIPI-DSI to LVDS panel bridge
+
+Required properties:
+ - compatible: "toshiba,tc358764"
+ - reg: the virtual channel number of a DSI peripheral
+ - vddc-supply: core voltage supply, 1.2V
+ - vddio-supply: I/O voltage supply, 1.8V or 3.3V
+ - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
+ - reset-gpios: a GPIO spec for the reset pin
+
+The device node can contain zero to two 'port' child nodes, each with one
+child 'endpoint' node, according to the bindings defined in [1].
+The following are properties specific to those nodes.
+
+port:
+ - reg: (required) can be 0 for DSI port or 1 for LVDS port;
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ bridge@0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <_1v2_reg>;
+ vddio-supply = <_1v8_reg>;
+ vddlvds-supply = <_3v3_reg>;
+ reset-gpios = < 6 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+ lvds_ep: endpoint {
+ remote-endpoint = <_ep>;
+ };
+ };
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] xen: dma-buf support for grant device
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: Oleksandr Andrushchenko (8): xen/grant-table: Make set/clear page private code shared xen/balloon: Move common memory reservation routines to a module xen/grant-table: Allow allocating buffers suitable for DMA xen/gntdev: Allow mappings for DMA buffers xen/gntdev: Add initial support for dma-buf UAPI xen/gntdev: Implement dma-buf export functionality xen/gntdev: Implement dma-buf import functionality xen/gntdev: Expose gntdev's dma-buf API for in-kernel use drivers/xen/Kconfig | 23 + drivers/xen/Makefile |1 + drivers/xen/balloon.c | 71 +-- drivers/xen/gntdev.c | 1025 - I think this calls for gntdev_dma.c. I only had a quick look over gntdev changes but they very much are concentrated in dma-specific routines. You essentially only share file_operations entry points with original gntdev code, right? -boris drivers/xen/grant-table.c | 176 +- drivers/xen/mem-reservation.c | 134 + include/uapi/xen/gntdev.h | 106 include/xen/grant_dev.h | 37 ++ include/xen/grant_table.h | 28 + include/xen/mem_reservation.h | 29 + 10 files changed, 1527 insertions(+), 103 deletions(-) create mode 100644 drivers/xen/mem-reservation.c create mode 100644 include/xen/grant_dev.h create mode 100644 include/xen/mem_reservation.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/msm: suspend devfreq on init
Devfreq turns on and starts recommending power level as soon as it is initialized. The GPU is still not powered on by the time the devfreq init happens and this leads to problems on GPU's where register access is needed to get/set power levels. So we start suspended and only restart devfreq when GPU is powered on. Signed-off-by: Sharat Masetty --- drivers/gpu/drm/msm/msm_gpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index 1c09acf..d7586f2 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -104,6 +104,8 @@ static void msm_devfreq_init(struct msm_gpu *gpu) dev_err(>pdev->dev, "Couldn't initialize GPU devfreq\n"); gpu->devfreq.devfreq = NULL; } + + devfreq_suspend_device(gpu->devfreq.devfreq); } static int enable_pwrrail(struct msm_gpu *gpu) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/10] drm/exynos: move pm_runtime_get_sync() to exynos_dsi_init()
In order to allow bridge drivers to use DSI transfers in their
pre_enable callbacks, pm_runtime_get_sync() should be performed before
exynos_dsi_enable(). DSIM_STATE_ENABLED flag now should not guard
from calling dsi_host_transfer() before enabling.
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 9599e6b..85eb2262 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1312,6 +1312,7 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
{
const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
+ pm_runtime_get_sync(dsi->dev);
exynos_dsi_reset(dsi);
exynos_dsi_enable_irq(dsi);
@@ -1388,7 +1389,6 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
ret = drm_panel_prepare(dsi->panel);
if (ret < 0) {
dsi->state &= ~DSIM_STATE_ENABLED;
- pm_runtime_put_sync(dsi->dev);
return;
}
@@ -1400,7 +1400,6 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
dsi->state &= ~DSIM_STATE_ENABLED;
exynos_dsi_set_display_enable(dsi, false);
drm_panel_unprepare(dsi->panel);
- pm_runtime_put_sync(dsi->dev);
return;
}
@@ -1422,7 +1421,10 @@ static void exynos_dsi_disable(struct drm_encoder
*encoder)
dsi->state &= ~DSIM_STATE_ENABLED;
- pm_runtime_put_sync(dsi->dev);
+ if (dsi->state & DSIM_STATE_INITIALIZED) {
+ pm_runtime_put_sync(dsi->dev);
+ dsi->state &= ~DSIM_STATE_INITIALIZED;
+ }
}
static enum drm_connector_status
@@ -1566,9 +1568,6 @@ static ssize_t exynos_dsi_host_transfer(struct
mipi_dsi_host *host,
struct exynos_dsi_transfer xfer;
int ret;
- if (!(dsi->state & DSIM_STATE_ENABLED))
- return -EINVAL;
-
if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
ret = exynos_dsi_init(dsi);
if (ret)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/10] ARM: dts: exynos5250: add DSI node
From: Andrzej Hajda
The patch adds common part of DSI node for Exynos5250 platforms
and a required mipi-phy node.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
arch/arm/boot/dts/exynos5250.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 2daf505..9965eca 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -733,6 +733,27 @@
#phy-cells = <0>;
};
+ mipi_phy: video-phy@10040710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10040710 0x100>;
+ #phy-cells = <1>;
+ syscon = <_system_controller>;
+ };
+
+ dsi_0: dsi@1450 {
+ compatible = "samsung,exynos4210-mipi-dsi";
+ reg = <0x1450 0x1>;
+ interrupts = ;
+ samsung,power-domain = <_disp1>;
+ phys = <_phy 3>;
+ phy-names = "dsim";
+ clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI1>;
+ clock-names = "bus_clk", "sclk_mipi";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
adc: adc@12d1 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D1 0x100>;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: ttm: Adding new return type vm_fault_t
On Thu, May 24, 2018 at 12:25 AM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Previously vm_insert_{mixed,pfn} returns err which driver
> mapped into VM_FAULT_* type. The new function
> vmf_insert_{mixed,pfn} will replace this inefficiency by
> returning VM_FAULT_* type.
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 45
> -
> 1 file changed, 22 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 8eba95b..2d13f03 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -43,10 +43,11 @@
>
> #define TTM_BO_VM_NUM_PREFAULT 16
>
> -static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
> +static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
> struct vm_fault *vmf)
> {
> - int ret = 0;
> + int err = 0;
> + vm_fault_t ret = 0;
>
> if (likely(!bo->moving))
> goto out_unlock;
> @@ -77,9 +78,9 @@ static int ttm_bo_vm_fault_idle(struct ttm_buffer_object
> *bo,
> /*
> * Ordinary wait.
> */
> - ret = dma_fence_wait(bo->moving, true);
> - if (unlikely(ret != 0)) {
> - ret = (ret != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
> + err = dma_fence_wait(bo->moving, true);
> + if (unlikely(err != 0)) {
> + ret = (err != -ERESTARTSYS) ? VM_FAULT_SIGBUS :
> VM_FAULT_NOPAGE;
> goto out_unlock;
> }
> @@ -104,7 +105,7 @@ static unsigned long ttm_bo_io_mem_pfn(struct
> ttm_buffer_object *bo,
> + page_offset;
> }
>
> -static int ttm_bo_vm_fault(struct vm_fault *vmf)
> +static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
> @@ -115,8 +116,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> unsigned long pfn;
> struct ttm_tt *ttm = NULL;
> struct page *page;
> - int ret;
> + int err;
> int i;
> + vm_fault_t ret = VM_FAULT_NOPAGE;
> unsigned long address = vmf->address;
> struct ttm_mem_type_manager *man =
> >man[bo->mem.mem_type];
> @@ -128,9 +130,9 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> * for reserve, and if it fails, retry the fault after waiting
> * for the buffer to become unreserved.
> */
> - ret = ttm_bo_reserve(bo, true, true, NULL);
> - if (unlikely(ret != 0)) {
> - if (ret != -EBUSY)
> + err = ttm_bo_reserve(bo, true, true, NULL);
> + if (unlikely(err != 0)) {
> + if (err != -EBUSY)
> return VM_FAULT_NOPAGE;
>
> if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> @@ -162,8 +164,8 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> }
>
> if (bdev->driver->fault_reserve_notify) {
> - ret = bdev->driver->fault_reserve_notify(bo);
> - switch (ret) {
> + err = bdev->driver->fault_reserve_notify(bo);
> + switch (err) {
> case 0:
> break;
> case -EBUSY:
> @@ -191,13 +193,13 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> goto out_unlock;
> }
>
> - ret = ttm_mem_io_lock(man, true);
> - if (unlikely(ret != 0)) {
> + err = ttm_mem_io_lock(man, true);
> + if (unlikely(err != 0)) {
> ret = VM_FAULT_NOPAGE;
> goto out_unlock;
> }
> - ret = ttm_mem_io_reserve_vm(bo);
> - if (unlikely(ret != 0)) {
> + err = ttm_mem_io_reserve_vm(bo);
> + if (unlikely(err != 0)) {
> ret = VM_FAULT_SIGBUS;
> goto out_io_unlock;
> }
> @@ -265,23 +267,20 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> }
>
> if (vma->vm_flags & VM_MIXEDMAP)
> - ret = vm_insert_mixed(, address,
> + ret = vmf_insert_mixed(, address,
> __pfn_to_pfn_t(pfn, PFN_DEV));
> else
> - ret = vm_insert_pfn(, address, pfn);
> + ret = vmf_insert_pfn(, address, pfn);
>
> /*
> * Somebody beat us to this PTE or prefaulting to
> * an already populated PTE, or prefaulting error.
> */
>
> - if (unlikely((ret == -EBUSY) || (ret != 0 && i
[PATCH v2 03/10] drm/exynos: move connector creation to attach callback
The current implementation assumes that the only possible peripheral
device for DSIM is a panel. Using an output bridge should also be
possible.
If an output bridge in available, don't create a new connector.
Instead add bridge to DSIM encdoer in dsi_host_attach().
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 35 +
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 85eb2262..7b50bad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1501,7 +1501,28 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
struct mipi_dsi_device *device)
{
struct exynos_dsi *dsi = host_to_dsi(host);
- struct drm_device *drm = dsi->connector.dev;
+ struct drm_encoder *encoder = >encoder;
+ struct drm_device *drm = encoder->dev;
+ struct drm_bridge *out_bridge;
+
+ out_bridge = of_drm_find_bridge(device->dev.of_node);
+ if (out_bridge) {
+ drm_bridge_attach(encoder, out_bridge, NULL);
+ } else {
+ int ret = exynos_dsi_create_connector(encoder);
+
+ if (ret) {
+ DRM_ERROR("failed to create connector ret = %d\n", ret);
+ drm_encoder_cleanup(encoder);
+ return ret;
+ }
+
+ dsi->panel = of_drm_find_panel(device->dev.of_node);
+ if (dsi->panel) {
+ drm_panel_attach(dsi->panel, >connector);
+ dsi->connector.status = connector_status_connected;
+ }
+ }
/*
* This is a temporary solution and should be made by more generic way.
@@ -1520,11 +1541,6 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->panel = of_drm_find_panel(device->dev.of_node);
- if (dsi->panel) {
- drm_panel_attach(dsi->panel, >connector);
- dsi->connector.status = connector_status_connected;
- }
exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
@@ -1653,13 +1669,6 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
if (ret < 0)
return ret;
- ret = exynos_dsi_create_connector(encoder);
- if (ret) {
- DRM_ERROR("failed to create connector ret = %d\n", ret);
- drm_encoder_cleanup(encoder);
- return ret;
- }
-
if (dsi->mic_bridge_node) {
mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
if (mic_bridge)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA
On 05/30/2018 01:49 PM, Oleksandr Andrushchenko wrote:
> On 05/30/2018 06:20 PM, Boris Ostrovsky wrote:
>> On 05/30/2018 02:34 AM, Oleksandr Andrushchenko wrote:
>>> On 05/29/2018 10:10 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
+/**
+ * gnttab_dma_free_pages - free DMAable pages
+ * @args: arguments to the function
+ */
+int gnttab_dma_free_pages(struct gnttab_dma_alloc_args *args)
+{
+ xen_pfn_t *frames;
+ size_t size;
+ int i, ret;
+
+ gnttab_pages_clear_private(args->nr_pages, args->pages);
+
+ frames = kcalloc(args->nr_pages, sizeof(*frames), GFP_KERNEL);
Any way you can do it without allocating memory? One possibility is to
keep allocated frames from gnttab_dma_alloc_pages(). (Not sure I like
that either but it's the only thing I can think of).
>>> Yes, I was also thinking about storing the allocated frames array from
>>> gnttab_dma_alloc_pages(), but that seemed not to be clear enough as
>>> the caller of the gnttab_dma_alloc_pages will need to store those
>>> frames
>>> in some context, so we can pass them on free. But the caller doesn't
>>> really
>>> need the frames which might confuse, so I decided to make those
>>> allocations
>>> on the fly.
>>> But I can still rework that to store the frames if you insist: please
>>> let me know.
>>
>> I would prefer not to allocate anything in the release path. Yes, I
>> realize that dragging frames array around is not necessary but IMO it's
>> better than potentially failing an allocation during a teardown. A
>> comment in the struct definition could explain the reason for having
>> this field.
> Then I would suggest we have it this way: current API requires that
> struct page **pages are allocated from outside. So, let's allocate
> the frames from outside as well. This way the caller is responsible for
> both pages and frames arrays and API looks consistent.
Yes, that works too.
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm/msm: re-factor devfreq common code
This series re-factors the devfreq code a bit in preparation for the upcoming A6x related devfreq changes. The code applies cleanly on 4.17 and has been verified on DB820C. V2: Addressed code review comments from Jordan Crouse. Sharat Masetty (3): drm/msm: suspend devfreq on init drm/msm: move suspend/resume devfreq to their own functions drm/msm: re-factor devfreq code drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 +--- drivers/gpu/drm/msm/msm_gpu.c | 48 ++- drivers/gpu/drm/msm/msm_gpu.h | 6 - 3 files changed, 48 insertions(+), 22 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/10] drm/exynos: add non-panel path to exynos_dsi_enable()
As DSIM can now have a bridge connected as a peripheral, it should be
possible to successfully enable exynos_dsi, when there is no panel
provided.
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7b50bad..7f6a0b1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1382,27 +1382,25 @@ static void exynos_dsi_enable(struct drm_encoder
*encoder)
if (dsi->state & DSIM_STATE_ENABLED)
return;
- pm_runtime_get_sync(dsi->dev);
-
- dsi->state |= DSIM_STATE_ENABLED;
-
- ret = drm_panel_prepare(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- return;
+ if (dsi->panel) {
+ ret = drm_panel_prepare(dsi->panel);
+ if (ret < 0)
+ return;
}
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);
- ret = drm_panel_enable(dsi->panel);
- if (ret < 0) {
- dsi->state &= ~DSIM_STATE_ENABLED;
- exynos_dsi_set_display_enable(dsi, false);
- drm_panel_unprepare(dsi->panel);
- return;
+ if (dsi->panel) {
+ ret = drm_panel_enable(dsi->panel);
+ if (ret < 0) {
+ exynos_dsi_set_display_enable(dsi, false);
+ drm_panel_unprepare(dsi->panel);
+ return;
+ }
}
+ dsi->state |= DSIM_STATE_ENABLED;
dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/msm: move suspend/resume devfreq to their own functions
This is needed for hardware revisions which do not rely on the generic
suspend, resume handlers for power management.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/msm_gpu.c | 23 +++
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index d7586f2..c5d4627 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -203,6 +203,19 @@ static int disable_axi(struct msm_gpu *gpu)
return 0;
}
+void msm_gpu_resume_devfreq(struct msm_gpu *gpu)
+{
+ gpu->devfreq.busy_cycles = 0;
+ gpu->devfreq.time = ktime_get();
+
+ devfreq_resume_device(gpu->devfreq.devfreq);
+}
+
+void msm_gpu_suspend_devfreq(struct msm_gpu *gpu)
+{
+ devfreq_suspend_device(gpu->devfreq.devfreq);
+}
+
int msm_gpu_pm_resume(struct msm_gpu *gpu)
{
int ret;
@@ -221,12 +234,7 @@ int msm_gpu_pm_resume(struct msm_gpu *gpu)
if (ret)
return ret;
- if (gpu->devfreq.devfreq) {
- gpu->devfreq.busy_cycles = 0;
- gpu->devfreq.time = ktime_get();
-
- devfreq_resume_device(gpu->devfreq.devfreq);
- }
+ msm_gpu_resume_devfreq(gpu);
gpu->needs_hw_init = true;
@@ -239,8 +247,7 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
DBG("%s", gpu->name);
- if (gpu->devfreq.devfreq)
- devfreq_suspend_device(gpu->devfreq.devfreq);
+ msm_gpu_suspend_devfreq(gpu);
ret = disable_axi(gpu);
if (ret)
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index b824117..1876b81 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -226,6 +226,8 @@ static inline void gpu_write64(struct msm_gpu *gpu, u32 lo,
u32 hi, u64 val)
int msm_gpu_pm_suspend(struct msm_gpu *gpu);
int msm_gpu_pm_resume(struct msm_gpu *gpu);
+void msm_gpu_resume_devfreq(struct msm_gpu *gpu);
+void msm_gpu_suspend_devfreq(struct msm_gpu *gpu);
int msm_gpu_hw_init(struct msm_gpu *gpu);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/10] panel/hv070wsa-100: add DT bindings
From: Andrzej Hajda The patch adds bindings to BOE HV070-WSA WSVGA panel. Bindings are compatible with simple panel bindings. Signed-off-by: Andrzej Hajda Signed-off-by: Maciej Purski --- .../devicetree/bindings/display/panel/boe,hv070wsa-100.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt diff --git a/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt new file mode 100644 index 000..bfc20ac --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt @@ -0,0 +1,7 @@ +BOE HV070WSA-100 7.01" WSVGA TFT LCD panel + +Required properties: +- compatible: should be "boe,hv070wsa-100" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/30/2018 04:29 AM, Oleksandr Andrushchenko wrote:
> On 05/29/2018 11:03 PM, Boris Ostrovsky wrote:
>> On 05/29/2018 02:22 PM, Oleksandr Andrushchenko wrote:
>>> On 05/29/2018 09:04 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
@@ -463,11 +457,6 @@ static enum bp_state
increase_reservation(unsigned long nr_pages)
int rc;
unsigned long i;
struct page *page;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid = DOMID_SELF
- };
if (nr_pages > ARRAY_SIZE(frame_list))
nr_pages = ARRAY_SIZE(frame_list);
@@ -486,9 +475,7 @@ static enum bp_state
increase_reservation(unsigned long nr_pages)
page = balloon_next_page(page);
}
- set_xen_guest_handle(reservation.extent_start, frame_list);
- reservation.nr_extents = nr_pages;
- rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, );
+ rc = xenmem_reservation_increase(nr_pages, frame_list);
if (rc <= 0)
return BP_EAGAIN;
@@ -496,29 +483,7 @@ static enum bp_state
increase_reservation(unsigned long nr_pages)
page = balloon_retrieve(false);
BUG_ON(page == NULL);
-#ifdef CONFIG_XEN_HAVE_PVMMU
- /*
- * We don't support PV MMU when Linux and Xen is using
- * different page granularity.
- */
- BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
-
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- unsigned long pfn = page_to_pfn(page);
-
- set_phys_to_machine(pfn, frame_list[i]);
-
- /* Link back into the page tables if not highmem. */
- if (!PageHighMem(page)) {
- int ret;
- ret = HYPERVISOR_update_va_mapping(
- (unsigned long)__va(pfn << PAGE_SHIFT),
- mfn_pte(frame_list[i], PAGE_KERNEL),
- 0);
- BUG_ON(ret);
- }
- }
-#endif
+ xenmem_reservation_va_mapping_update(1, ,
_list[i]);
Can you make a single call to xenmem_reservation_va_mapping_update(rc,
...)? You need to keep track of pages but presumable they can be put
into an array (or a list). In fact, perhaps we can have
balloon_retrieve() return a set of pages.
>>> This is actually how it is used later on for dma-buf, but I just
>>> didn't want
>>> to alter original balloon code too much, but this can be done, in
>>> order of simplicity:
>>>
>>> 1. Similar to frame_list, e.g. static array of struct page* of size
>>> ARRAY_SIZE(frame_list):
>>> more static memory is used, but no allocations
>>>
>>> 2. Allocated at run-time with kcalloc: allocation can fail
>>
>> If this is called in freeing DMA buffer code path or in error path then
>> we shouldn't do it.
>>
>>
>>> 3. Make balloon_retrieve() return a set of pages: will require
>>> list/array allocation
>>> and handling, allocation may fail, balloon_retrieve prototype change
>>
>> balloon pages are strung on the lru list. Can we keep have
>> balloon_retrieve return a list of pages on that list?
> First of all, before we go deep in details, I will highlight
> the goal of the requested change: for balloon driver we call
> xenmem_reservation_va_mapping_update(*1*, , _list[i]);
> from increase_reservation
> and
> xenmem_reservation_va_mapping_reset(*1*, );
> from decrease_reservation and it seems to be not elegant because of
> that one page/frame passed while we might have multiple pages/frames
> passed at once.
>
> In the balloon driver the producer of pages for increase_reservation
> is balloon_retrieve(false) and for decrease_reservation it is
> alloc_page(gfp).
> In case of decrease_reservation the page is added on the list:
> LIST_HEAD(pages);
> [...]
> list_add(>lru, );
>
> and in case of increase_reservation it is retrieved page by page
> and can be put on a list as well with the same code from
> decrease_reservation, e.g.
> LIST_HEAD(pages);
> [...]
> list_add(>lru, );
>
> Thus, both decrease_reservation and increase_reservation may hold
> their pages on a list before calling
> xenmem_reservation_va_mapping_{update|reset}.
>
> For that we need a prototype change:
> xenmem_reservation_va_mapping_reset(, );
> But for xenmem_reservation_va_mapping_update it will look like:
> xenmem_reservation_va_mapping_update(, ,
> )
> which seems to be inconsistent. Converting entries of the static
> frame_list array
> into corresponding list doesn't seem to be cute as well.
>
> For dma-buf use-case arrays are more preferable as dma-buf constructs
> scatter-gather
> tables from array of pages etc. and if page list is passed then it
> needs to
[PATCH v2 06/10] drm/panel: add support for BOE HV070WSA-100 panel to simple-panel
From: Andrzej Hajda
The patch adds support for BOE HV070WSA-100 WSVGA 7.01 inch panel
in panel-simple driver. The panel is used in Exynos5250-arndale boards.
Signed-off-by: Andrzej Hajda
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/panel/panel-simple.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab4..d5da58d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode boe_hv070wsa_mode = {
+ .clock = 40800,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 90,
+ .hsync_end = 1024 + 90 + 90,
+ .htotal = 1024 + 90 + 90 + 90,
+ .vdisplay = 600,
+ .vsync_start = 600 + 3,
+ .vsync_end = 600 + 3 + 4,
+ .vtotal = 600 + 3 + 4 + 3,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc boe_hv070wsa = {
+ .modes = _hv070wsa_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 154,
+ .height = 90,
+ },
+};
+
static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2113,6 +2135,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+ .compatible = "boe,hv070wsa-100",
+ .data = _hv070wsa
+ }, {
.compatible = "boe,nv101wxmn51",
.data = _nv101wxmn51,
}, {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/10] drm/bridge: tc358764: Add DSI to LVDS bridge driver
From: Andrzej Hajda Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge. Signed-off-by: Andrzej Hajda Signed-off-by: Maciej Purski --- drivers/gpu/drm/bridge/Kconfig| 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358764.c | 547 ++ 3 files changed, 557 insertions(+) create mode 100644 drivers/gpu/drm/bridge/tc358764.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index fa2c799..9bd3eb8 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -110,6 +110,15 @@ config DRM_THINE_THC63LVD1024 ---help--- Thine THC63LVD1024 LVDS/parallel converter driver. +config DRM_TOSHIBA_TC358764 + tristate "TC358764 DSI/LVDS bridge" + depends on DRM && DRM_PANEL + depends on OF + select DRM_MIPI_DSI + select VIDEOMODE_HELPERS + help + Toshiba TC358764 DSI/LVDS bridge driver + config DRM_TOSHIBA_TC358767 tristate "Toshiba TC358767 eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 35f88d4..bf7c0ce 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o obj-$(CONFIG_DRM_SII902X) += sii902x.o obj-$(CONFIG_DRM_SII9234) += sii9234.o obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o +obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c new file mode 100644 index 000..3109eba --- /dev/null +++ b/drivers/gpu/drm/bridge/tc358764.c @@ -0,0 +1,547 @@ +/* + * Copyright (C) 2018 Samsung Electronics Co., Ltd + * + * Authors: + * Andrzej Hajda + * Maciej Purski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. + * + */ + +#include + +#include +#include +#include + +#include +#include + +#include +#include +#include + +#include +#include +#include + +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << (end)) +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end)) + +/* PPI layer registers */ +#define PPI_STARTPPI 0x0104 /* START control bit */ +#define PPI_LPTXTIMECNT0x0114 /* LPTX timing signal */ +#define PPI_LANEENABLE 0x0134 /* Enables each lane */ +#define PPI_TX_RX_TA 0x013C /* BTA timing parameters */ +#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */ +#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */ +#define PPI_D2S_CLRSIPOCOUNT 0x016C /* Assertion timer for Lane 2 */ +#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */ +#define PPI_START_FUNCTION 1 + +/* DSI layer registers */ +#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */ +#define DSI_LANEENABLE 0x0210 /* Enables each lane */ +#define DSI_RX_START 1 + +/* Video path registers */ +#define VP_CTRL0x0450 /* Video Path Control */ +#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in RGB666 */ +#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */ +#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */ +#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */ +#define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */ +#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */ +#define VP_CTRL_DEPOL BIT(18) /* Polarity of DE signal */ +#define VP_CTRL_VSPOL BIT(19) /* Polarity of VSYNC signal */ +#define VP_HTIM1 0x0454 /* Horizontal Timing Control 1 */ +#define VP_HTIM1_HBP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM1_HSYNC(v) FLD_VAL(v, 8, 0) +#define VP_HTIM2 0x0458 /* Horizontal Timing Control 2 */ +#define VP_HTIM2_HFP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM2_HACT(v) FLD_VAL(v, 10, 0) +#define VP_VTIM1 0x045C /* Vertical Timing Control 1 */ +#define VP_VTIM1_VBP(v)FLD_VAL(v, 23, 16) +#define VP_VTIM1_VSYNC(v) FLD_VAL(v, 7, 0) +#define VP_VTIM2 0x0460 /* Vertical Timing Control 2 */ +#define VP_VTIM2_VFP(v)FLD_VAL(v, 23, 16)
Re: [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
On Mon, May 21, 2018 at 06:23:57PM +0530, Ramalingam C wrote:
> Implements the DP adaptation specific HDCP2.2 functions.
>
> These functions perform the DPCD read and write for communicating the
> HDCP2.2 auth message back and forth.
>
> Note: Chris Wilson suggested alternate method for waiting for CP_IRQ,
> than completions concept. WIP to understand and implement that,
> if needed. Just to unblock the review of other changes, v2 still
> continues with completions.
>
> v2:
> wait for cp_irq is merged with this patch. Rebased.
> v3:
> wait_queue is used for wait for cp_irq [Chris Wilson]
> v4:
> Style fixed.
> %s/PARING/PAIRING
> Few style fixes [Uma]
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_dp.c | 358
> ++
> drivers/gpu/drm/i915/intel_drv.h | 7 +
> drivers/gpu/drm/i915/intel_hdcp.c | 5 +
> 3 files changed, 370 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 528407d608c8..ee71a26ec23f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -5057,6 +5058,28 @@ void intel_dp_encoder_suspend(struct intel_encoder
> *intel_encoder)
> pps_unlock(intel_dp);
> }
>
> +static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
> + int timeout)
> +{
> + long ret;
> +
> + /* Reinit */
> + atomic_set(>cp_irq_recved, 0);
> +
> +#define C (atomic_read(>cp_irq_recved) > 0)
> + ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
> +msecs_to_jiffies(timeout));
> +
> + if (ret > 0) {
> + atomic_set(>cp_irq_recved, 0);
> + return 0;
> + } else if (!ret) {
> + return -ETIMEDOUT;
> + }
> + return (int)ret;
> +}
> +
> +
> static
> int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> u8 *an)
> @@ -5275,6 +5298,335 @@ int intel_dp_hdcp_capable(struct intel_digital_port
> *intel_dig_port,
> return 0;
> }
>
> +static
> +int intel_dpcd_offset_for_hdcp2_msgid(uint8_t byte, unsigned int *offset)
Ugh, this is annoying that we have to map things around like that. But
looking at the numbers the standards really don't seem to match at all.
Instead of open-coding this I suggested you use a table with a struct
like:
const static struct hdcp_dp {
int hdcp_msg;
int dpcd_offset;
int timeout;
/* whatever else you might need */
} hdcp_2_dp_table[] = {
{ HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, ... },
...
};
Then just search that table in the code instead of the huge switch table
below.
> +{
> + switch (byte) {
> + case HDCP_2_2_AKE_INIT:
> + *offset = DP_HDCP_2_2_AKE_INIT_OFFSET;
> + break;
> + case HDCP_2_2_AKE_SEND_CERT:
> + *offset = DP_HDCP_2_2_AKE_SEND_CERT_OFFSET;
> + break;
> + case HDCP_2_2_AKE_NO_STORED_KM:
> + *offset = DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET;
> + break;
> + case HDCP_2_2_AKE_STORED_KM:
> + *offset = DP_HDCP_2_2_AKE_STORED_KM_OFFSET;
> + break;
> + case HDCP_2_2_AKE_SEND_HPRIME:
> + *offset = DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET;
> + break;
> + case HDCP_2_2_AKE_SEND_PAIRING_INFO:
> + *offset = DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET;
> + break;
> + case HDCP_2_2_LC_INIT:
> + *offset = DP_HDCP_2_2_LC_INIT_OFFSET;
> + break;
> + case HDCP_2_2_LC_SEND_LPRIME:
> + *offset = DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET;
> + break;
> + case HDCP_2_2_SKE_SEND_EKS:
> + *offset = DP_HDCP_2_2_SKE_SEND_EKS_OFFSET;
> + break;
> + case HDCP_2_2_REP_SEND_RECVID_LIST:
> + *offset = DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET;
> + break;
> + case HDCP_2_2_REP_SEND_ACK:
> + *offset = DP_HDCP_2_2_REP_SEND_ACK_OFFSET;
> + break;
> + case HDCP_2_2_REP_STREAM_MANAGE:
> + *offset = DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET;
> + break;
> + case HDCP_2_2_REP_STREAM_READY:
> + *offset = DP_HDCP_2_2_REP_STREAM_READY_OFFSET;
> + break;
> + case HDCP_2_2_ERRATA_DP_STREAM_TYPE:
> + *offset = DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET;
> + break;
> + default:
> + DRM_ERROR("Unrecognized Msg ID\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static inline
> +int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
> + uint8_t *rx_status)
> +{
> + ssize_t ret;
> +
> + ret =
Re: [PATCH 1/2] drm/scheduler: Avoid using wait_event_killable for dying process.
Am 30.05.2018 um 21:54 schrieb Andrey Grodzovsky:
Dying process might be blocked from receiving any more signals
so avoid using it.
Also retire enity->fini_status and just check the SW queue,
if it's not empty do the fallback cleanup.
Also handle entity->last_scheduled == NULL use case which
happens when HW ring is already hangged whem a new entity
tried to enqeue jobs.
Signed-off-by: Andrey Grodzovsky
Would be nice to have to split that patch up further, but not sure if
that is actually doable.
Additional to that a few more nitpicks below.
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 47 ++-
include/drm/gpu_scheduler.h | 1 -
2 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 44d4807..4d038f9 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -135,7 +135,6 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
entity->rq = rq;
entity->sched = sched;
entity->guilty = guilty;
- entity->fini_status = 0;
entity->last_scheduled = NULL;
spin_lock_init(>rq_lock);
@@ -173,7 +172,8 @@ static bool drm_sched_entity_is_initialized(struct
drm_gpu_scheduler *sched,
static bool drm_sched_entity_is_idle(struct drm_sched_entity *entity)
{
rmb();
- if (spsc_queue_peek(>job_queue) == NULL)
+
+ if (entity->rq == NULL || spsc_queue_peek(>job_queue) == NULL)
Usual kernel coding style is more to use "!entity->rq" instead of
"entity->rq == NULL".
return true;
return false;
@@ -227,12 +227,16 @@ void drm_sched_entity_do_release(struct drm_gpu_scheduler
*sched,
* The client will not queue more IBs during this fini, consume existing
* queued IBs or discard them on SIGKILL
*/
- if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL)
- entity->fini_status = -ERESTARTSYS;
+ if ((current->flags & PF_EXITING))
+ wait_event_timeout(sched->job_scheduled,
+ drm_sched_entity_is_idle(entity),
msecs_to_jiffies(1000));
Mhm, making the timeout a parameter or at least use a define would be
nice to have.
Additional to that it might be a good idea to return the remaining
timeout and use that as parameter for the next call.
E.g. this way when we need to cleanup multiple queues we don't wait for
1000 ms each, but rather only 1000 ms in total.
else
- entity->fini_status = wait_event_killable(sched->job_scheduled,
- drm_sched_entity_is_idle(entity));
- drm_sched_entity_set_rq(entity, NULL);
+ wait_event_killable(sched->job_scheduled,
drm_sched_entity_is_idle(entity));
+
+
+ /* For killed process disable any more IBs enqueue right now */
+ if ((current->flags & PF_EXITING) && (current->exit_code == SIGKILL))
+ drm_sched_entity_set_rq(entity, NULL);
}
EXPORT_SYMBOL(drm_sched_entity_do_release);
@@ -247,7 +251,13 @@ EXPORT_SYMBOL(drm_sched_entity_do_release);
void drm_sched_entity_cleanup(struct drm_gpu_scheduler *sched,
struct drm_sched_entity *entity)
{
- if (entity->fini_status) {
+
+ drm_sched_entity_set_rq(entity, NULL);
+
+ /* Consumption of existing IBs wasn't completed. Forcefully
+* remove them here.
+*/
+ if (spsc_queue_peek(>job_queue)) {
struct drm_sched_job *job;
int r;
@@ -267,12 +277,22 @@ void drm_sched_entity_cleanup(struct drm_gpu_scheduler *sched,
struct drm_sched_fence *s_fence = job->s_fence;
drm_sched_fence_scheduled(s_fence);
dma_fence_set_error(_fence->finished, -ESRCH);
- r = dma_fence_add_callback(entity->last_scheduled,
>finish_cb,
-
drm_sched_entity_kill_jobs_cb);
- if (r == -ENOENT)
+
+ /*
+* When pipe is hanged by older entity, new entity might
+* not even have chance to submit it's first job to HW
+* and so entity->last_scheduled will remain NULL
+*/
+ if (!entity->last_scheduled)
drm_sched_entity_kill_jobs_cb(NULL,
>finish_cb);
- else if (r)
- DRM_ERROR("fence add callback failed (%d)\n",
r);
+ else {
Coding style nit pick when one side of an else has { or } the other side
should have it as well.
+ r = dma_fence_add_callback(entity->last_scheduled,
>finish_cb,
+
[Bug 86351] HDMI audio garbled output on Radeon R9 280X
https://bugzilla.kernel.org/show_bug.cgi?id=86351 --- Comment #32 from letha...@gmail.com --- It's still not ok for me with rx550 on a core2duo. The HBR audio now starts playing to the audio receiver thanks to the fix. But the sound is "flickering", it improves a lot by maximizing the audio buffer, and even more by putting load on the cpu(vm), but it's still not usable. Couldn't reproduce this issue on a rx550+4770k. So it could be linked to older motherboards/cpus slower scheduling or something? Iirc, i also tried an rxvega on the core2duo, couldn't reproduce it either. I still have tests to do: retry it with another linux distro on the old computer. I really don't understand what or why anymore. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 25/41] drm/i915: Enable and Disable HDCP2.2 port encryption
On Mon, May 21, 2018 at 06:23:44PM +0530, Ramalingam C wrote:
> Implements the enable and disable functions for HDCP2.2 encryption
> of the PORT.
>
> v2:
> intel_wait_for_register is used instead of wait_for. [Chris Wilson]
> v3:
> No Changes.
> v4:
> Debug msg is added for timeout at Disable of Encryption [Uma]
> %s/HDCP2_CTL/HDCP2_CTL
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 57
> +++
> 1 file changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index bd0bfcfd5b8f..0386a67c3e32 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -19,6 +19,7 @@
>(enum hdcp_physical_port) (port))
> #define KEY_LOAD_TRIES 5
> #define HDCP2_LC_RETRY_CNT 3
> +#define TIME_FOR_ENCRYPT_STATUS_CHANGE 32
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> const struct intel_hdcp_shim *shim)
> @@ -1397,3 +1398,59 @@ static int hdcp2_authenticate_sink(struct
> intel_connector *connector)
>
> return ret;
> }
> +
> +static int hdcp2_enable_encryption(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_hdcp *hdcp = >hdcp;
> + enum port port = connector->encoder->port;
> + int ret;
> +
> + if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)
> + return 0;
Relying on hw status for state decisions is in my experience bad - it
papers over bugs in our state handling. We should know what the expected
state of the hardware is.
If you want to write a bit more robust code, then keep these checks, but
wrap them in a WARN_ON. That way we'll know if there's a regression in the
code (e.g. unbalanced enable/disable) right away, instead of these checks
silently papering over them.
> +
> + if (hdcp->hdcp_shim->toggle_signalling)
> + hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
> +
> + if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
Same for this check here. In general control flow that depends upon
register values which can change at runtime is very suspect from a design
robustness point of view.
-Daniel
> +
> + /* Link is Authenticated. Now set for Encryption */
> + I915_WRITE(HDCP2_CTL_DDI(port),
> +I915_READ(HDCP2_CTL_DDI(port)) |
> +CTL_LINK_ENCRYPTION_REQ);
> + }
> +
> + ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
> + LINK_ENCRYPTION_STATUS,
> + LINK_ENCRYPTION_STATUS,
> + TIME_FOR_ENCRYPT_STATUS_CHANGE);
> +
> + return ret;
> +}
> +
> +static int hdcp2_disable_encryption(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_hdcp *hdcp = >hdcp;
> + enum port port = connector->encoder->port;
> + int ret;
> +
> + if (!(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS))
> + return 0;
> +
> + I915_WRITE(HDCP2_CTL_DDI(port),
> +I915_READ(HDCP2_CTL_DDI(port)) & ~CTL_LINK_ENCRYPTION_REQ);
> +
> + ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
> + LINK_ENCRYPTION_STATUS, 0x0,
> + TIME_FOR_ENCRYPT_STATUS_CHANGE);
> + if (ret == -ETIMEDOUT)
> + DRM_DEBUG_KMS("Disable Encryption Timedout");
> +
> + if (hdcp->hdcp_shim->toggle_signalling)
> + hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
> +
> + return ret;
> +}
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 22/41] drm/i915: Wrappers for mei HDCP2.2 services
On Mon, May 21, 2018 at 06:23:41PM +0530, Ramalingam C wrote:
> Adds the wrapper for all mei hdcp2.2 service functions.
>
> v2:
> Rebased.
> v3:
> cldev is moved from mei_hdcp_data to hdcp.
> v4:
> %s/hdcp2_store_paring_info/hdcp2_store_pairing_info
>
> Signed-off-by: Ramalingam C
This is a bit a style nit, but I'm not convinced of the value of these
wrappers. They just do basic sanity checking (and with the component
stuff, cldev should never be NULL before we get here), and those checks
that are still needed could be done just once when we start a hdcp2
operation.
Personally I'd drop these all and directly call the mei_ functions in the
later patches (plus put just 1 set of the sanity checks at the beginning
of a hdcp flow). More direct code is generally easier to read later on.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 194
> ++
> 1 file changed, 194 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index c7d0fa319c01..57c380c91cd0 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -10,10 +10,13 @@
> #include
> #include
> #include
> +#include
>
> #include "intel_drv.h"
> #include "i915_reg.h"
>
> +#define GET_MEI_DDI_INDEX(port) (((port) == PORT_A) ? DDI_A : \
> + (enum hdcp_physical_port) (port))
> #define KEY_LOAD_TRIES 5
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> @@ -896,3 +899,194 @@ int intel_hdcp_check_link(struct intel_connector
> *connector)
> mutex_unlock(>hdcp_mutex);
> return ret;
> }
> +
> +static int
> +hdcp2_prepare_ake_init(struct intel_hdcp *hdcp, struct hdcp2_ake_init
> *ake_data)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + struct intel_connector *connector = container_of(hdcp,
> + struct intel_connector,
> + hdcp);
> +
> + if (!hdcp->cldev)
> + return -EINVAL;
> +
> + if (data->port == INVALID_PORT && connector->encoder)
> + data->port = GET_MEI_DDI_INDEX(connector->encoder->port);
> +
> + /* Clear ME FW instance for the port, just incase */
> + mei_close_hdcp_session(hdcp->cldev, data);
> +
> + return mei_initiate_hdcp2_session(hdcp->cldev, data, ake_data);
> +}
> +
> +static int hdcp2_close_mei_session(struct intel_hdcp *hdcp)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> +
> + if (!hdcp->cldev || data->port == INVALID_PORT)
> + return -EINVAL;
> +
> + return mei_close_hdcp_session(hdcp->cldev, data);
> +}
> +
> +static int
> +hdcp2_verify_rx_cert_prepare_km(struct intel_hdcp *hdcp,
> + struct hdcp2_ake_send_cert *rx_cert,
> + bool *paired,
> + struct hdcp2_ake_no_stored_km *ek_pub_km,
> + size_t *msg_sz)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + int ret;
> +
> + if (!hdcp->cldev)
> + return -EINVAL;
> +
> + ret = mei_verify_receiver_cert_prepare_km(hdcp->cldev, data, rx_cert,
> + paired, ek_pub_km, msg_sz);
> + if (ret < 0)
> + mei_close_hdcp_session(hdcp->cldev, data);
> +
> + return ret;
> +}
> +
> +static int hdcp2_verify_hprime(struct intel_hdcp *hdcp,
> +struct hdcp2_ake_send_hprime *rx_hprime)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + int ret;
> +
> + if (!hdcp->cldev)
> + return -EINVAL;
> +
> + ret = mei_verify_hprime(hdcp->cldev, data, rx_hprime);
> + if (ret < 0)
> + mei_close_hdcp_session(hdcp->cldev, data);
> +
> + return ret;
> +}
> +
> +static int
> +hdcp2_store_pairing_info(struct intel_hdcp *hdcp,
> + struct hdcp2_ake_send_pairing_info *pairing_info)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + int ret;
> +
> + if (!hdcp->cldev)
> + return -EINVAL;
> +
> + ret = mei_store_pairing_info(hdcp->cldev, data, pairing_info);
> + if (ret < 0)
> + mei_close_hdcp_session(hdcp->cldev, data);
> +
> + return ret;
> +}
> +
> +static int
> +hdcp2_prepare_lc_init(struct intel_hdcp *hdcp, struct hdcp2_lc_init *lc_init)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + int ret;
> +
> + if (!hdcp->cldev)
> + return -EINVAL;
> +
> + ret = mei_initiate_locality_check(hdcp->cldev, data, lc_init);
> + if (ret < 0)
> + mei_close_hdcp_session(hdcp->cldev, data);
> +
> + return ret;
> +}
> +
> +static int
> +hdcp2_verify_lprime(struct intel_hdcp *hdcp,
> + struct hdcp2_lc_send_lprime *rx_lprime)
> +{
> + struct mei_hdcp_data *data = >mei_data;
> + int ret;
> +
> +
Re: [PATCH v2 08/10] drm/bridge: tc358764: Add DSI to LVDS bridge driver
Hi, On Wednesday 30 May 2018 05:45 PM, Maciej Purski wrote: From: Andrzej Hajda Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge. Signed-off-by: Andrzej Hajda Signed-off-by: Maciej Purski --- drivers/gpu/drm/bridge/Kconfig| 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358764.c | 547 ++ 3 files changed, 557 insertions(+) create mode 100644 drivers/gpu/drm/bridge/tc358764.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index fa2c799..9bd3eb8 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -110,6 +110,15 @@ config DRM_THINE_THC63LVD1024 ---help--- Thine THC63LVD1024 LVDS/parallel converter driver. +config DRM_TOSHIBA_TC358764 + tristate "TC358764 DSI/LVDS bridge" + depends on DRM && DRM_PANEL + depends on OF + select DRM_MIPI_DSI + select VIDEOMODE_HELPERS I don't see videomode usage in the driver, can we drop this if it isn't used? + help + Toshiba TC358764 DSI/LVDS bridge driver + config DRM_TOSHIBA_TC358767 tristate "Toshiba TC358767 eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 35f88d4..bf7c0ce 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o obj-$(CONFIG_DRM_SII902X) += sii902x.o obj-$(CONFIG_DRM_SII9234) += sii9234.o obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o +obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c new file mode 100644 index 000..3109eba --- /dev/null +++ b/drivers/gpu/drm/bridge/tc358764.c @@ -0,0 +1,547 @@ We'd need a SPDX license here? +/* + * Copyright (C) 2018 Samsung Electronics Co., Ltd + * + * Authors: + * Andrzej Hajda + * Maciej Purski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. + * + */ + +#include + +#include +#include +#include + +#include +#include + +#include +#include +#include + +#include +#include +#include + +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << (end)) +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end)) + +/* PPI layer registers */ +#define PPI_STARTPPI 0x0104 /* START control bit */ +#define PPI_LPTXTIMECNT0x0114 /* LPTX timing signal */ +#define PPI_LANEENABLE 0x0134 /* Enables each lane */ +#define PPI_TX_RX_TA 0x013C /* BTA timing parameters */ +#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */ +#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */ +#define PPI_D2S_CLRSIPOCOUNT 0x016C /* Assertion timer for Lane 2 */ +#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */ +#define PPI_START_FUNCTION 1 + +/* DSI layer registers */ +#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */ +#define DSI_LANEENABLE 0x0210 /* Enables each lane */ +#define DSI_RX_START 1 + +/* Video path registers */ +#define VP_CTRL0x0450 /* Video Path Control */ +#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in RGB666 */ +#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */ +#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */ +#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */ +#define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */ +#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */ +#define VP_CTRL_DEPOL BIT(18) /* Polarity of DE signal */ +#define VP_CTRL_VSPOL BIT(19) /* Polarity of VSYNC signal */ +#define VP_HTIM1 0x0454 /* Horizontal Timing Control 1 */ +#define VP_HTIM1_HBP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM1_HSYNC(v) FLD_VAL(v, 8, 0) +#define VP_HTIM2 0x0458 /* Horizontal Timing Control 2 */ +#define VP_HTIM2_HFP(v)FLD_VAL(v, 24, 16) +#define VP_HTIM2_HACT(v) FLD_VAL(v, 10, 0) +#define VP_VTIM1 0x045C /* Vertical Timing Control 1 */ +#define VP_VTIM1_VBP(v)FLD_VAL(v,
[PATCH] drm/omap: Implement workaround for DRA7 errata ID:i932
From: Venkateswara Rao Mandela
Description of DRA7 Errata i932:
In rare circumstances DPLL_VIDEO1 and DPLL_VIDEO2 PLL's may not lock on
the first attempt during DSS initialization. When this occurs, a
subsequent attempt to relock the PLL will result in PLL successfully
locking.
This patch does the following as per the errata recommendation:
- retries locking the PLL upto 20 times.
- The time to wait for a PLL lock set to 1000 REFCLK cycles. We use
usleep_range to wait for 1000 REFCLK cycles in the us range. This tight
constraint is imposed as a lock later than 1000 REFCLK cycles may have
high jitter.
- Criteria for PLL lock is extended from check on just the PLL_LOCK bit
to check on 6 PLL_STATUS bits.
Silicon Versions Impacted:
DRA71, DRA72, DRA74, DRA76 - All silicon revisions
AM57x - All silicon revisions
OMAP4/5 are not impacted by this errata
Signed-off-by: Venkateswara Rao Mandela
[tomi.valkei...@ti.com: ported to v4.14]
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dss.h | 3 +
drivers/gpu/drm/omapdrm/dss/pll.c | 73 +
drivers/gpu/drm/omapdrm/dss/video-pll.c | 1 +
3 files changed, 67 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 847c78ade024..9f9a700bb6d5 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -180,6 +180,9 @@ struct dss_pll_hw {
/* DRA7 errata i886: use high N & M to avoid jitter */
bool errata_i886;
+
+ /* DRA7 errata i932: retry pll lock on failure */
+ bool errata_i932;
};
struct dss_pll {
diff --git a/drivers/gpu/drm/omapdrm/dss/pll.c
b/drivers/gpu/drm/omapdrm/dss/pll.c
index 078b0e8216c3..ff362b38bf0d 100644
--- a/drivers/gpu/drm/omapdrm/dss/pll.c
+++ b/drivers/gpu/drm/omapdrm/dss/pll.c
@@ -16,6 +16,7 @@
#define DSS_SUBSYS_NAME "PLL"
+#include
#include
#include
#include
@@ -381,6 +382,22 @@ static int dss_wait_hsdiv_ack(struct dss_pll *pll, u32
hsdiv_ack_mask)
return -ETIMEDOUT;
}
+static bool pll_is_locked(u32 stat)
+{
+ /*
+* Required value for each bitfield listed below
+*
+* PLL_STATUS[6] = 0 PLL_BYPASS
+* PLL_STATUS[5] = 0 PLL_HIGHJITTER
+*
+* PLL_STATUS[3] = 0 PLL_LOSSREF
+* PLL_STATUS[2] = 0 PLL_RECAL
+* PLL_STATUS[1] = 1 PLL_LOCK
+* PLL_STATUS[0] = 1 PLL_CTRL_RESET_DONE
+*/
+ return ((stat & 0x6f) == 0x3);
+}
+
int dss_pll_write_config_type_a(struct dss_pll *pll,
const struct dss_pll_clock_info *cinfo)
{
@@ -436,18 +453,54 @@ int dss_pll_write_config_type_a(struct dss_pll *pll,
l = FLD_MOD(l, 0, 25, 25); /* M7_CLOCK_EN */
writel_relaxed(l, base + PLL_CONFIGURATION2);
- writel_relaxed(1, base + PLL_GO); /* PLL_GO */
+ if (hw->errata_i932) {
+ int cnt = 0;
+ u32 sleep_time;
+ const u32 max_lock_retries = 20;
- if (wait_for_bit_change(base + PLL_GO, 0, 0) != 0) {
- DSSERR("DSS DPLL GO bit not going down.\n");
- r = -EIO;
- goto err;
- }
+ /*
+* Calculate wait time for PLL LOCK
+* 1000 REFCLK cycles in us.
+*/
+ sleep_time = DIV_ROUND_UP(1000*1000*1000, cinfo->fint);
- if (wait_for_bit_change(base + PLL_STATUS, 1, 1) != 1) {
- DSSERR("cannot lock DSS DPLL\n");
- r = -EIO;
- goto err;
+ for (cnt = 0; cnt < max_lock_retries; cnt++) {
+ writel_relaxed(1, base + PLL_GO); /* PLL_GO */
+
+ /**
+* read the register back to ensure the write is
+* flushed
+*/
+ readl_relaxed(base + PLL_GO);
+
+ usleep_range(sleep_time, sleep_time + 5);
+ l = readl_relaxed(base + PLL_STATUS);
+
+ if (pll_is_locked(l) &&
+ !(readl_relaxed(base + PLL_GO) & 0x1))
+ break;
+
+ }
+
+ if (cnt == max_lock_retries) {
+ DSSERR("cannot lock PLL\n");
+ r = -EIO;
+ goto err;
+ }
+ } else {
+ writel_relaxed(1, base + PLL_GO); /* PLL_GO */
+
+ if (wait_for_bit_change(base + PLL_GO, 0, 0) != 0) {
+ DSSERR("DSS DPLL GO bit not going down.\n");
+ r = -EIO;
+ goto err;
+ }
+
+ if (wait_for_bit_change(base + PLL_STATUS, 1, 1) != 1) {
+ DSSERR("cannot lock DSS DPLL\n");
+ r = -EIO;
+ goto err;
+ }
}
Re: [PATCH] fb_omap: add gpiolib dependency
On Thu, May 31, 2018 at 12:49 AM, Arnd Bergmann wrote: > drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c: In function 'hdmi_probe_of': > drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c:584:2: error: implicit > declaration of function 'of_node_put'; did you mean 'node_set'? > [-Werror=implicit-function-declaration] > drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c: In function 'hdmi_probe_of': > drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:554:2: error: implicit > declaration of function 'of_node_put'; did you mean 'node_set'? > [-Werror=implicit-function-declaration] > Rather than fixing up each one individually, this just marks all of it > as depending on GPIOLIB. Hmm... But the OF stuff is not part of GPIOLIB. -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong
Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is located at:
Documentation/devicetree/bindings/display/altr,vip-fb2.txt
Signed-off-by: Ong Hean Loong
---
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/ivip/Kconfig | 14 +++
drivers/gpu/drm/ivip/Makefile |9 ++
drivers/gpu/drm/ivip/intel_vip_conn.c | 95
drivers/gpu/drm/ivip/intel_vip_core.c | 163
drivers/gpu/drm/ivip/intel_vip_drv.h | 52 +
drivers/gpu/drm/ivip/intel_vip_of.c | 193 +
8 files changed, 529 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index deeefa7..cdc8e1a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -204,6 +204,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
source "drivers/gpu/drm/i915/Kconfig"
+source "drivers/gpu/drm/ivip/Kconfig"
+
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff..c0fba1d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
obj-$(CONFIG_DRM_MGA) += mga/
obj-$(CONFIG_DRM_I810) += i810/
obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
obj-$(CONFIG_DRM_MGAG200) += mgag200/
obj-$(CONFIG_DRM_VC4) += vc4/
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..1d08b90
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,14 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM && OF
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+ Choose this option if you have an Intel FPGA Arria 10 system
+ and above with an Intel Display Port IP. This does not support
+ legacy Intel FPGA Cyclone V display port. Currently only
single
+ frame buffer is supported. Note that ACPI and X_86
architecture
+ is not supported for Arria10. If M is selected the module
will be
+ called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..cc55b04
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver. This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+ intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..46bb04c
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,95 @@
+/*
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
+ .reset = drm_atomic_helper_connector_reset,
+ .detect
[PATCHv8 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 371fca4..21d8d2b 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -112,6 +112,11 @@ CONFIG_MFD_ALTERA_A10SR=y CONFIG_MFD_STMPE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_DRM=m +CONFIG_DRM_IVIP=m +CONFIG_DRM_IVIP_OF=m +CONFIG_FB=y +CONFIG_FB_SIMPLE=y CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
