[Bug 105880] [dc] No support for LVDS or VGA connectors (Cannot find any crtc or sizes)
https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #45 from Pontus Gråskæg --- Created attachment 143261 --> https://bugs.freedesktop.org/attachment.cgi?id=143261&action=edit dmesg 5.0.0-rc4 dc=1 -- 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 105880] [dc] No support for LVDS or VGA connectors (Cannot find any crtc or sizes)
https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #44 from Pontus Gråskæg --- Created attachment 143260 --> https://bugs.freedesktop.org/attachment.cgi?id=143260&action=edit dmesg 5.0.0-rc4 dc=0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105880] [dc] No support for LVDS or VGA connectors (Cannot find any crtc or sizes)
https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #43 from Pontus Gråskæg --- (In reply to Przemek from comment #42) > Good news, > on amd-staging-drm-next (5.0.0-rc1+) vga connector works without a hitch. I > don't have dvi connector on my netbook so I am unable to test this one. > > Thanks, > Przemek. I *think* that is because it defaults to Radeon code on Kaveri. On my Lenovo Z50-75 laptop with kernel 5.0.0-rc4 I get the following behaviour - with kernel parameter amdgpu.dc=0 the VGA connector works (case (a) below) and with amdgpu.dc=1 it does not, although the built in LCD display on the laptop does (case (b) below). I believe this is known to AMD, but resource prioritisation means that it is unlikely to be changed in the near future if at all. graaskaeg a) with kernel boot parameters "amdgpu.cik_support=1 radeon.cik_support=0 amdgpu.dc=0 amdgpu.dc_log=0 drm.debug=0x00 vt.handoff=1" - note the amdgpu.dc=0 My ***Highlight*** added below [2.200714] [drm] amdgpu kernel modesetting enabled. [2.201557] [drm] initializing kernel modesetting (KAVERI 0x1002:0x130A 0x17AA:0x3988 0x00). [2.220715] [drm] register mmio base: 0xF0B0 [2.220724] [drm] register mmio size: 262144 [2.220730] [drm] add ip block number 0 [2.220733] [drm] add ip block number 1 [2.220735] [drm] add ip block number 2 [2.220738] [drm] add ip block number 3 [2.220741] [drm] add ip block number 4 [2.220743] [drm] add ip block number 5 ***[2.220746] [drm] add ip block number 6 *** [2.220749] [drm] add ip block number 7 [2.220751] [drm] add ip block number 8 [2.245495] [drm] BIOS signature incorrect 0 0 ... [2.246594] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [2.246597] [drm] Driver supports precise vblank timestamp query. [2.247632] [drm] Internal thermal controller without fan control [2.247640] [drm] amdgpu: dpm initialized [2.252827] [drm] amdgpu atom DIG backlight initialized [2.252831] [drm] AMDGPU Display Connectors [2.252833] [drm] Connector 0: [2.252835] [drm] VGA-1 [2.252836] [drm] HPD2 [2.252839] [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 [2.252841] [drm] Encoders: [2.252843] [drm] CRT1: INTERNAL_UNIPHY2 [2.252845] [drm] CRT1: NUTMEG [2.252846] [drm] Connector 1: [2.252848] [drm] HDMI-A-1 [2.252849] [drm] HPD3 [2.252851] [drm] DDC: 0x1954 0x1954 0x1955 0x1955 0x1956 0x1956 0x1957 0x1957 [2.252854] [drm] Encoders: [2.252855] [drm] DFP1: INTERNAL_UNIPHY2 [2.252857] [drm] Connector 2: [2.252858] [drm] eDP-1 [2.252860] [drm] HPD1 [2.252862] [drm] DDC: 0x194c 0x194c 0x194d 0x194d 0x194e 0x194e 0x194f 0x194f [2.252864] [drm] Encoders: [2.252866] [drm] LCD1: INTERNAL_UNIPHY [2.252995] [drm] Found UVD firmware Version: 1.55 Family ID: 9 [2.253586] [drm] Found VCE firmware Version: 50.10 Binary ID: 2 [2.376639] [drm] UVD initialized successfully. [2.486808] [drm] VCE initialized successfully. b) with kernel boot parameters "amdgpu.cik_support=1 radeon.cik_support=0 amdgpu.dc=1 amdgpu.dc_log=0 drm.debug=0x00 vt.handoff=1" - note the amdgpu.dc=1 My ***Highlight*** added below [2.234786] [drm] amdgpu kernel modesetting enabled. [2.235605] [drm] initializing kernel modesetting (KAVERI 0x1002:0x130A 0x17AA:0x3988 0x00). [2.248333] [drm] register mmio base: 0xF0B0 [2.248343] [drm] register mmio size: 262144 [2.248348] [drm] add ip block number 0 [2.248351] [drm] add ip block number 1 [2.248354] [drm] add ip block number 2 [2.248356] [drm] add ip block number 3 [2.248359] [drm] add ip block number 4 [2.248361] [drm] add ip block number 5 ***[2.248365] [drm] add ip block number 6 *** [2.248367] [drm] add ip block number 7 [2.248370] [drm] add ip block number 8 [2.273900] [drm] BIOS signature incorrect 0 0 ... [2.275855] [drm] Internal thermal controller without fan control [2.275866] [drm] amdgpu: dpm initialized [2.275999] [drm] Found UVD firmware Version: 1.55 Family ID: 9 [2.276402] [drm] Found VCE firmware Version: 50.10 Binary ID: 2 [2.285995] [drm:dm_pp_get_static_clocks [amdgpu]] *ERROR* DM_PPLIB: invalid powerlevel state: 0! [2.286092] [drm] Unsupported Connector type:5! [2.286207] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:3! type 0 expected 3 [2.286313] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:4! type 0 expected 3 [2.286391] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:5! type 0 expected 3 [2.286469] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:6! type 0 expected 3 [2.2
Re: [PATCH v2 1/6] drm/virtio: move virtio_gpu_object_{attach, detach} calls.
Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> Drop the dummy ttm backend implementation, add a real one for
> TTM_PL_FLAG_TT objects. The bin/unbind callbacks will call
> virtio_gpu_object_{attach,detach}, to update the object state
> on the host side, instead of invoking those calls from the
> move_notify() callback.
>
> With that in place the move and move_notify callbacks are not
> needed any more, so drop them.
>
> Signed-off-by: Gerd Hoffmann
> ---
Acked-by: Noralf Trønnes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user
The function was unconditionally returning 0, and a caller would have to
rely on the returned fence pointer being NULL to detect errors. However,
the function vmw_execbuf_copy_fence_user() would expect a non-zero error
code in that case and would BUG otherwise.
So make sure we return a proper non-zero error code if the fence pointer
returned is NULL.
Fixes: ae2a104058e2: ("vmwgfx: Implement fence objects")
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index f2d13a72c05d..88b8178d4687 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3570,7 +3570,7 @@ int vmw_execbuf_fence_commands(struct drm_file *file_priv,
*p_fence = NULL;
}
- return 0;
+ return ret;
}
/**
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/vmwgfx: Fix an uninitialized fence handle value
if vmw_execbuf_fence_commands() fails, The handle value will be
uninitialized and a bogus fence handle might be copied to user-space.
Fixes: 2724b2d54cda: ("drm/vmwgfx: Use new validation interface for the
modesetting code v2")
Reported-by: Dan Carpenter
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul #v1
Reviewed-by: Sinclair Yeh #v1
---
v2: Also initialize the ret local variable, to silence compilatior warnings.
Call vmw_execbuf_copy_fence_user regardless of the value of ret, to propagate
the correct error code to user-space.
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index b351fb5214d3..5e257a600cea 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2554,8 +2554,8 @@ void vmw_kms_helper_validation_finish(struct vmw_private
*dev_priv,
user_fence_rep)
{
struct vmw_fence_obj *fence = NULL;
- uint32_t handle;
- int ret;
+ uint32_t handle = 0;
+ int ret = 0;
if (file_priv || user_fence_rep || vmw_validation_has_bos(ctx) ||
out_fence)
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108889] [CI][SHARDS] igt@sw_sync@sync_busy_fork_unixsocket - incomplete - __igt_fork_helper: Assertion `!proc->running' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=108889 Chris Wilson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Chris Wilson --- commit 93c6b1ca84866fabe4601b1e93145209e4df1177 Author: Chris Wilson Date: Wed Jan 30 22:16:39 2019 + sw_sync: Initialise struct before use sw_sync: ../lib/igt_core.c:1592: __igt_fork_helper: Assertion `!proc->running' Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108889 Signed-off-by: Chris Wilson Reviewed-by: Jani Nikula -- 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 109493] [CI][DRMTIP] igt@gem_cpu_reloc@forked - fail - igt_skip: Assertion `!test_child' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=109493 Chris Wilson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Chris Wilson --- commit 4049adf01014af077df2174def4fadf7cecb066e (HEAD, upstream/master) Author: Chris Wilson Date: Wed Jan 30 16:18:58 2019 + i915/gem_cpu_reloc: Do the can-store-dword check at start igt doesn't handle skipping from inside igt_fork very gracefully and crashes instead of reporting the lack of requirements. One solution would be to fix igt, but far easier is to just move the requirement checking around to do it before we even fork. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109493 Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin -- 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 105880] [dc] No support for LVDS or VGA connectors (Cannot find any crtc or sizes)
https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #42 from Przemek --- Good news, on amd-staging-drm-next (5.0.0-rc1+) vga connector works without a hitch. I don't have dvi connector on my netbook so I am unable to test this one. Thanks, Przemek. -- 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
[PATCHv2 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index a8db758..c9e207f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -221,26 +221,13 @@ static int rockchip_drm_gem_object_mmap_iommu(struct
drm_gem_object *obj,
struct vm_area_struct *vma)
{
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
- unsigned int i, count = obj->size >> PAGE_SHIFT;
+ unsigned int count = obj->size >> PAGE_SHIFT;
unsigned long user_count = vma_pages(vma);
- unsigned long uaddr = vma->vm_start;
- unsigned long offset = vma->vm_pgoff;
- unsigned long end = user_count + offset;
- int ret;
if (user_count == 0)
return -ENXIO;
- if (end > count)
- return -ENXIO;
- for (i = offset; i < end; i++) {
- ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
- if (ret)
- return ret;
- uaddr += PAGE_SIZE;
- }
-
- return 0;
+ return vm_insert_range(vma, rk_obj->pages, count);
}
static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 01:00:02PM -0700, Logan Gunthorpe wrote: > We never changed SGLs. We still use them to pass p2pdma pages, only we > need to be a bit careful where we send the entire SGL. I see no reason > why we can't continue to be careful once their in userspace if there's > something in GUP to deny them. > > It would be nice to have heterogeneous SGLs and it is something we > should work toward but in practice they aren't really necessary at the > moment. RDMA generally cannot cope well with an API that requires homogeneous SGLs.. User space can construct complex MRs (particularly with the proposed SGL MR flow) and we must marshal that into a single SGL or the drivers fall apart. Jerome explained that GPU is worse, a single VMA may have a random mix of CPU or device pages.. This is a pretty big blocker that would have to somehow be fixed. > That doesn't even necessarily need to be the case. For HMM, I > understand, struct pages may not point to any accessible memory and the > memory that backs it (or not) may change over the life time of it. So > they don't have to be strictly tied to BARs addresses. p2pdma pages are > strictly tied to BAR addresses though. No idea, but at least for this case I don't think we need magic HMM pages to make simple VMA ops p2p_map/umap work.. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
vm_insert_range() is the API which could be used to mapped
kernel memory/pages in drivers which has considered vm_pgoff
vm_insert_range_buggy() is the API which could be used to map
range of kernel memory/pages in drivers which has not considered
vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
We _could_ then at a later "fix" these drivers which are using
vm_insert_range_buggy() to behave according to the normal vm_pgoff
offsetting simply by removing the _buggy suffix on the function
name and if that causes regressions, it gives us an easy way to revert.
Signed-off-by: Souptick Joarder
Suggested-by: Russell King
Suggested-by: Matthew Wilcox
---
include/linux/mm.h | 4 +++
mm/memory.c| 81 ++
mm/nommu.c | 14 ++
3 files changed, 99 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 80bb640..25752b0 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2565,6 +2565,10 @@ unsigned long change_prot_numa(struct vm_area_struct
*vma,
int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t);
int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
+int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num);
+int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num);
vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn);
vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index e11ca9d..0a4bf57 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1520,6 +1520,87 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned
long addr,
}
EXPORT_SYMBOL(vm_insert_page);
+/**
+ * __vm_insert_range - insert range of kernel pages into user vma
+ * @vma: user vma to map to
+ * @pages: pointer to array of source kernel pages
+ * @num: number of pages in page array
+ * @offset: user's requested vm_pgoff
+ *
+ * This allows drivers to insert range of kernel pages they've allocated
+ * into a user vma.
+ *
+ * If we fail to insert any page into the vma, the function will return
+ * immediately leaving any previously inserted pages present. Callers
+ * from the mmap handler may immediately return the error as their caller
+ * will destroy the vma, removing any successfully inserted pages. Other
+ * callers should make their own arrangements for calling unmap_region().
+ *
+ * Context: Process context.
+ * Return: 0 on success and error code otherwise.
+ */
+static int __vm_insert_range(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num, unsigned long offset)
+{
+ unsigned long count = vma_pages(vma);
+ unsigned long uaddr = vma->vm_start;
+ int ret, i;
+
+ /* Fail if the user requested offset is beyond the end of the object */
+ if (offset > num)
+ return -ENXIO;
+
+ /* Fail if the user requested size exceeds available object size */
+ if (count > num - offset)
+ return -ENXIO;
+
+ for (i = 0; i < count; i++) {
+ ret = vm_insert_page(vma, uaddr, pages[offset + i]);
+ if (ret < 0)
+ return ret;
+ uaddr += PAGE_SIZE;
+ }
+
+ return 0;
+}
+
+/**
+ * vm_insert_range - insert range of kernel pages starts with non zero offset
+ * @vma: user vma to map to
+ * @pages: pointer to array of source kernel pages
+ * @num: number of pages in page array
+ *
+ * Maps an object consisting of `num' `pages', catering for the user's
+ * requested vm_pgoff
+ *
+ * Context: Process context. Called by mmap handlers.
+ * Return: 0 on success and error code otherwise.
+ */
+int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num)
+{
+ return __vm_insert_range(vma, pages, num, vma->vm_pgoff);
+}
+EXPORT_SYMBOL(vm_insert_range);
+
+/**
+ * vm_insert_range_buggy - insert range of kernel pages starts with zero offset
+ * @vma: user vma to map to
+ * @pages: pointer to array of source kernel pages
+ * @num: number of pages in page array
+ *
+ * Maps a set of pages, always starting at page[0]
+ *
+ * Context: Process context. Called by mmap handlers.
+ * Return: 0 on success and error code otherwise.
+ */
+int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
+ unsigned long num)
+{
Re: [PATCH] drm/bridge/panel: Remove duplicate header
On Wed, Jan 30, 2019 at 8:07 PM Brajeswar Ghosh
wrote:
>
> On Wed, Dec 26, 2018 at 3:09 PM Laurent Pinchart
> wrote:
> >
> > Hi Brajeswar,
> >
> > Thank you for the patch.
> >
> > On Monday, 24 December 2018 16:32:18 EET Brajeswar Ghosh wrote:
> > > Remove drm/drm_panel.h which is included more than once
> > >
> > > Signed-off-by: Brajeswar Ghosh
> > > ---
> > > drivers/gpu/drm/bridge/panel.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/panel.c
> > > b/drivers/gpu/drm/bridge/panel.c
> > > index 7cbaba213ef6..402b318eeeb2 100644
> > > --- a/drivers/gpu/drm/bridge/panel.c
> > > +++ b/drivers/gpu/drm/bridge/panel.c
> > > @@ -15,7 +15,6 @@
> > > #include
> > > #include
> > > #include
> > > -#include
> >
> > While at it, how about sorting headers alphabetically to make sure this
> > won't
> > happen again ?
> >
> > With that change,
> >
> > Reviewed-by: Laurent Pinchart
>
> If no further comment, can we get this patch in queue for 5.1 ?
You already got a feedback from Laurent.
>
> >
> > > struct panel_bridge {
> > > struct drm_bridge bridge;
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
> >
> >
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On 2019-01-30 10:26 a.m., Christoph Hellwig wrote: > On Wed, Jan 30, 2019 at 10:55:43AM -0500, Jerome Glisse wrote: >> Even outside GPU driver, device driver like RDMA just want to share their >> doorbell to other device and they do not want to see those doorbell page >> use in direct I/O or anything similar AFAICT. > > At least Mellanox HCA support and inline data feature where you > can copy data directly into the BAR. For something like a usrspace > NVMe target it might be very useful to do direct I/O straight into > the BAR for that. Yup, these are things we definitely want to be able to do, and have done with hacky garbage code: Direct I/O from NVMe to P2P BAR, then we could Direct I/O to another drive or map it as an MR and send it over an RNIC. We'd definitely like to move in that direction. And a world where such userspace mappings are gimpped by the fact that they are only some special feature of userspace VMAs that can only be used in specialized userspace interfaces is not useful to us. Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 5/9] drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 28bc501..b72cf11 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -224,8 +224,7 @@ struct drm_gem_object *
static int gem_mmap_obj(struct xen_gem_object *xen_obj,
struct vm_area_struct *vma)
{
- unsigned long addr = vma->vm_start;
- int i;
+ int ret;
/*
* clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
@@ -246,18 +245,11 @@ static int gem_mmap_obj(struct xen_gem_object *xen_obj,
* FIXME: as we insert all the pages now then no .fault handler must
* be called, so don't provide one
*/
- for (i = 0; i < xen_obj->num_pages; i++) {
- int ret;
-
- ret = vm_insert_page(vma, addr, xen_obj->pages[i]);
- if (ret < 0) {
- DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
- return ret;
- }
+ ret = vm_insert_range(vma, xen_obj->pages, xen_obj->num_pages);
+ if (ret < 0)
+ DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
- addr += PAGE_SIZE;
- }
- return 0;
+ return ret;
}
int xen_drm_front_gem_mmap(struct file *filp, struct vm_area_struct *vma)
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 11:13:11AM -0700, Logan Gunthorpe wrote: > > > On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote: > > I don't see why a special case with a VMA is really that different. > > Well one *really* big difference is the VMA changes necessarily expose > specialized new functionality to userspace which has to be supported > forever and may be difficult to change. The only user change here is that more things will succeed when creating RDMA MRs (and vice versa to GPU). I don't think this restricts the kernel implementation at all, unless we intend to remove P2P entirely.. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: prefix header search paths with $(srctree)/
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada
---
I put all gpu/drm changes into a single patch because
they are trivial conversion.
Please let me know if I need to split this into per-driver patches.
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/lib/Makefile| 2 +-
drivers/gpu/drm/i915/gvt/Makefile | 2 +-
drivers/gpu/drm/msm/Makefile| 6 +++---
drivers/gpu/drm/nouveau/Kbuild | 8
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
index f76bcb9..b21ebb0 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -23,7 +23,7 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-FULL_AMD_PATH=$(src)/..
+FULL_AMD_PATH=$(srctree)/$(src)/..
DISPLAY_FOLDER_NAME=display
FULL_AMD_DISPLAY_PATH = $(FULL_AMD_PATH)/$(DISPLAY_FOLDER_NAME)
diff --git a/drivers/gpu/drm/amd/lib/Makefile b/drivers/gpu/drm/amd/lib/Makefile
index 6902430..d534992 100644
--- a/drivers/gpu/drm/amd/lib/Makefile
+++ b/drivers/gpu/drm/amd/lib/Makefile
@@ -27,6 +27,6 @@
# driver components or later moved to kernel/lib for sharing with
# other drivers.
-ccflags-y := -I$(src)/../include
+ccflags-y := -I $(srctree)/$(src)/../include
obj-$(CONFIG_CHASH) += chash.o
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index b016dc7..a4a5a96 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -5,6 +5,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o
trace_points.o firmware.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o
debugfs.o \
fb_decoder.o dmabuf.o page_track.o
-ccflags-y += -I$(src) -I$(src)/$(GVT_DIR)
+ccflags-y += -I $(srctree)/$(src) -I
$(srctree)/$(src)/$(GVT_DIR)/
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
obj-$(CONFIG_DRM_I915_GVT_KVMGT) += $(GVT_DIR)/kvmgt.o
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 56a70c7..b7b1ebd 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
-ccflags-y := -Idrivers/gpu/drm/msm
-ccflags-y += -Idrivers/gpu/drm/msm/disp/dpu1
-ccflags-$(CONFIG_DRM_MSM_DSI) += -Idrivers/gpu/drm/msm/dsi
+ccflags-y := -I $(srctree)/$(src)
+ccflags-y += -I $(srctree)/$(src)/disp/dpu1
+ccflags-$(CONFIG_DRM_MSM_DSI) += -I $(srctree)/$(src)/dsi
msm-y := \
adreno/adreno_device.o \
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index b17843d..b4bc88ad 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -1,7 +1,7 @@
-ccflags-y += -I$(src)/include
-ccflags-y += -I$(src)/include/nvkm
-ccflags-y += -I$(src)/nvkm
-ccflags-y += -I$(src)
+ccflags-y += -I $(srctree)/$(src)/include
+ccflags-y += -I $(srctree)/$(src)/include/nvkm
+ccflags-y += -I $(srctree)/$(src)/nvkm
+ccflags-y += -I $(srctree)/$(src)
# NVKM - HW resource manager
#- code also used by various userspace tools/tests
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Use struct_size() in kzalloc()
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/vc4/vc4_perfmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c
b/drivers/gpu/drm/vc4/vc4_perfmon.c
index 437e7a27f21d..495150415020 100644
--- a/drivers/gpu/drm/vc4/vc4_perfmon.c
+++ b/drivers/gpu/drm/vc4/vc4_perfmon.c
@@ -117,7 +117,7 @@ int vc4_perfmon_create_ioctl(struct drm_device *dev, void
*data,
return -EINVAL;
}
- perfmon = kzalloc(sizeof(*perfmon) + (req->ncounters * sizeof(u64)),
+ perfmon = kzalloc(struct_size(perfmon, counters, req->ncounters),
GFP_KERNEL);
if (!perfmon)
return -ENOMEM;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On 2019-01-30 12:38 p.m., Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 02:22:34PM -0500, Jerome Glisse wrote: > >> For GPU it would not work, GPU might want to use main memory (because >> it is running out of BAR space) it is a lot easier if the p2p_map >> callback calls the right dma map function (for page or io) rather than >> having to define some format that would pass down the information. > > This is already sort of built into the sgl, you are supposed to use > is_pci_p2pdma_page() and pci_p2pdma_map_sg() and somehow it is supposed > to work out - but I think this is also fairly incomplete. > ie the current APIs seem to assume the SGL is homogeneous :( We never changed SGLs. We still use them to pass p2pdma pages, only we need to be a bit careful where we send the entire SGL. I see no reason why we can't continue to be careful once their in userspace if there's something in GUP to deny them. It would be nice to have heterogeneous SGLs and it is something we should work toward but in practice they aren't really necessary at the moment. >>> Worry about optimizing away the struct page overhead later? >> >> Struct page do not fit well for GPU as the BAR address can be reprogram >> to point to any page inside the device memory (think 256M BAR versus >> 16GB device memory). > > The struct page only points to the BAR - it is not related to the > actual GPU memory in any way. The struct page is just an alternative > way to specify the physical address of the BAR page. That doesn't even necessarily need to be the case. For HMM, I understand, struct pages may not point to any accessible memory and the memory that backs it (or not) may change over the life time of it. So they don't have to be strictly tied to BARs addresses. p2pdma pages are strictly tied to BAR addresses though. Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On 2019-01-30 12:59 p.m., Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 12:45:46PM -0700, Logan Gunthorpe wrote: >> >> >> On 2019-01-30 12:06 p.m., Jason Gunthorpe wrote: Way less problems than not having struct page for doing anything non-trivial. If you map the BAR to userspace with remap_pfn_range and friends the mapping is indeed very simple. But any operation that expects a page structure, which is at least everything using get_user_pages won't work. >>> >>> GUP doesn't work anyhow today, and won't work with BAR struct pages in >>> the forseeable future (Logan has sent attempts on this before). >> >> I don't recall ever attempting that... But patching GUP for special >> pages or VMAS; or working around by not calling it in some cases seems >> like the thing that's going to need to be done one way or another. > > Remember, the long discussion we had about how to get the IOMEM > annotation into SGL? That is a necessary pre-condition to doing > anything with GUP in DMA using drivers as GUP -> SGL -> DMA map is > pretty much the standard flow. Yes, but that was unrelated to GUP even if that might have been the eventual direction. And I feel the GUP->SGL->DMA flow should still be what we are aiming for. Even if we need a special GUP for special pages, and a special DMA map; and the SGL still has to be homogenous > So, I see Jerome solving the GUP problem by replacing GUP entirely > using an API that is more suited to what these sorts of drivers > actually need. Yes, this is what I'm expecting and what I want. Not bypassing the whole thing by doing special things with VMAs. Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote: > Every attempt to give BAR memory to struct page has run into major > trouble, IMHO, so I like that this approach avoids that. > > And if you don't have struct page then the only kernel object left to > hang meta data off is the VMA itself. > > It seems very similar to the existing P2P work between in-kernel > consumers, just that VMA is now mediating a general user space driven > discovery process instead of being hard wired into a driver. But the kernel now has P2P bars backed by struct pages and it works well. And that's what we are doing in-kernel. We even have a hacky out-of-tree module which exposes these pages and it also works (but would need Jerome's solution for denying those pages in GUP, etc). So why do something completely different in userspace so they can't share any of the DMA map infrastructure? Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/4] drm/dp: fix link probing for devices supporting DP 1.4+
From: Quentin Schulz
DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
"true capabilities" of DPRX device.
Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
might falsely return lower capabilities to "avoid interoperability
issues with some of the existing DP Source devices that malfunction
when they discover the higher capabilities within those three
registers.".
Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was reserved
and read 0 so it's safe to check against it even if DP revision is
<1.4
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
Reviewed-by: Andrzej Hajda
Reviewed-by: Manasi Navare
---
drivers/gpu/drm/drm_dp_helper.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 54120b6319e7..4e36d708fdce 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -372,10 +372,38 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
drm_dp_link *link)
{
u8 values[3];
int err;
+ unsigned int addr;
memset(link, 0, sizeof(*link));
- err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
+ /*
+* DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
+* DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
+* DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
+* DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
+* DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
+* "true capabilities" of DPRX device.
+*
+* Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
+* might falsely return lower capabilities to "avoid interoperability
+* issues with some of the existing DP Source devices that malfunction
+* when they discover the higher capabilities within those three
+* registers.".
+*
+* Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was
+* reserved and read 0 so it's safe to check against it even if
+* DP revision is <1.4
+*/
+ err = drm_dp_dpcd_readb(aux, DP_TRAINING_AUX_RD_INTERVAL, values);
+ if (err < 0)
+ return err;
+
+ if (values[0] & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)
+ addr = DP_DP13_DPCD_REV;
+ else
+ addr = DP_DPCD_REV;
+
+ err = drm_dp_dpcd_read(aux, addr, values, sizeof(values));
if (err < 0)
return err;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 09:00:06AM +0100, Christoph Hellwig wrote: > On Wed, Jan 30, 2019 at 04:18:48AM +, Jason Gunthorpe wrote: > > Every attempt to give BAR memory to struct page has run into major > > trouble, IMHO, so I like that this approach avoids that. > > Way less problems than not having struct page for doing anything > non-trivial. If you map the BAR to userspace with remap_pfn_range > and friends the mapping is indeed very simple. But any operation > that expects a page structure, which is at least everything using > get_user_pages won't work. GUP doesn't work anyhow today, and won't work with BAR struct pages in the forseeable future (Logan has sent attempts on this before). So nothing seems lost.. > So you can't do direct I/O to your remapped BAR, you can't create MRs > on it, etc, etc. Jerome made the HMM mirror API use this flow, so afer his patch to switch the ODP MR to use HMM, and to switch GPU drivers, it will work for those cases. Which is more than the zero cases than we have today :) Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API
On Thu, Jan 31, 2019 at 08:38:12AM +0530, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized by creating new functions and use it across
> the drivers.
>
> vm_insert_range() is the API which could be used to mapped
> kernel memory/pages in drivers which has considered vm_pgoff
>
> vm_insert_range_buggy() is the API which could be used to map
> range of kernel memory/pages in drivers which has not considered
> vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
>
> We _could_ then at a later "fix" these drivers which are using
> vm_insert_range_buggy() to behave according to the normal vm_pgoff
> offsetting simply by removing the _buggy suffix on the function
> name and if that causes regressions, it gives us an easy way to revert.
>
> Signed-off-by: Souptick Joarder
> Suggested-by: Russell King
> Suggested-by: Matthew Wilcox
> ---
> include/linux/mm.h | 4 +++
> mm/memory.c| 81
> ++
> mm/nommu.c | 14 ++
> 3 files changed, 99 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 80bb640..25752b0 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2565,6 +2565,10 @@ unsigned long change_prot_numa(struct vm_area_struct
> *vma,
> int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
> unsigned long pfn, unsigned long size, pgprot_t);
> int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page
> *);
> +int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num);
> +int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num);
> vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> unsigned long pfn);
> vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long
> addr,
> diff --git a/mm/memory.c b/mm/memory.c
> index e11ca9d..0a4bf57 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1520,6 +1520,87 @@ int vm_insert_page(struct vm_area_struct *vma,
> unsigned long addr,
> }
> EXPORT_SYMBOL(vm_insert_page);
>
> +/**
> + * __vm_insert_range - insert range of kernel pages into user vma
> + * @vma: user vma to map to
> + * @pages: pointer to array of source kernel pages
> + * @num: number of pages in page array
> + * @offset: user's requested vm_pgoff
> + *
> + * This allows drivers to insert range of kernel pages they've allocated
> + * into a user vma.
> + *
> + * If we fail to insert any page into the vma, the function will return
> + * immediately leaving any previously inserted pages present. Callers
> + * from the mmap handler may immediately return the error as their caller
> + * will destroy the vma, removing any successfully inserted pages. Other
> + * callers should make their own arrangements for calling unmap_region().
> + *
> + * Context: Process context.
> + * Return: 0 on success and error code otherwise.
> + */
> +static int __vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num, unsigned long offset)
> +{
> + unsigned long count = vma_pages(vma);
> + unsigned long uaddr = vma->vm_start;
> + int ret, i;
> +
> + /* Fail if the user requested offset is beyond the end of the object */
> + if (offset > num)
> + return -ENXIO;
> +
> + /* Fail if the user requested size exceeds available object size */
> + if (count > num - offset)
> + return -ENXIO;
> +
> + for (i = 0; i < count; i++) {
> + ret = vm_insert_page(vma, uaddr, pages[offset + i]);
> + if (ret < 0)
> + return ret;
> + uaddr += PAGE_SIZE;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * vm_insert_range - insert range of kernel pages starts with non zero offset
> + * @vma: user vma to map to
> + * @pages: pointer to array of source kernel pages
> + * @num: number of pages in page array
> + *
> + * Maps an object consisting of `num' `pages', catering for the user's
> + * requested vm_pgoff
> + *
The elaborate description you've added to __vm_insert_range() is better put
here, as this is the "public" function.
> + * Context: Process context. Called by mmap handlers.
> + * Return: 0 on success and error code otherwise.
> + */
> +int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num)
> +{
> + return __vm_insert_range(vma, pages, num, vma->vm_pgoff);
> +}
> +EXPORT_SYMBOL(vm_insert_range);
> +
> +/**
> + * vm_insert_range_buggy - insert range of kernel pages starts with zero
> offset
> + * @vma: user vma to map to
> +
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 05:47:05PM -0500, Jerome Glisse wrote: > On Wed, Jan 30, 2019 at 10:33:04PM +, Jason Gunthorpe wrote: > > On Wed, Jan 30, 2019 at 05:30:27PM -0500, Jerome Glisse wrote: > > > > > > What is the problem in the HMM mirror that it needs this restriction? > > > > > > No restriction at all here. I think i just wasn't understood. > > > > Are you are talking about from the exporting side - where the thing > > creating the VMA can really only put one distinct object into it? > > The message i was trying to get accross is that HMM mirror will > always succeed for everything* except for special vma ie mmap of > device file. For those it can only succeed if a p2p_map() call > succeed. > > So any user of HMM mirror might to know why the mirroring fail ie > was it because something exceptional is happening ? Or is it because > i was trying to map a special vma which can be forbiden. > > Hence why i assume that you might want to know about such p2p_map > failure at the time you create the umem odp object as it might be > some failure you might want to report differently and handle > differently. If you do not care about differentiating OOM or > exceptional failure from p2p_map failure than you have nothing to > worry about you will get the same error from HMM for both. I think my hope here was that we could have some kind of 'trial' interface where very eary users can call 'hmm_mirror_is_maybe_supported(dev, user_ptr, len)' and get a failure indication. We probably wouldn't call this on the full address space though Beyond that it is just inevitable there can be problems faulting if the memory map is messed with after MR is created. And here again, I don't want to worry about any particular VMA boundaries.. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 02:01:35PM -0700, Logan Gunthorpe wrote: > And I feel the GUP->SGL->DMA flow should still be what we are aiming > for. Even if we need a special GUP for special pages, and a special DMA > map; and the SGL still has to be homogenous *shrug* so what if the special GUP called a VMA op instead of traversing the VMA PTEs today? Why does it really matter? It could easily change to a struct page flow tomorrow.. > > So, I see Jerome solving the GUP problem by replacing GUP entirely > > using an API that is more suited to what these sorts of drivers > > actually need. > > Yes, this is what I'm expecting and what I want. Not bypassing the whole > thing by doing special things with VMAs. IMHO struct page is a big pain for this application, and if we can build flows that don't actually need it then we shouldn't require it just because the old flows needed it. HMM mirror is a new flow that doesn't need struct page. Would you feel better if this also came along with a: struct dma_sg_table *sgl_dma_map_user(struct device *dma_device, void __user *prt, size_t len) flow which returns a *DMA MAPPED* sgl that does not have struct page pointers as another interface? We can certainly call an API like this from RDMA for non-ODP MRs. Eliminating the page pointers also eliminates the __iomem problem. However this sgl object is not copyable or accessible from the CPU, so the caller must be sure it doesn't need CPU access when using this API. For RDMA I'd include some flag in the struct ib_device if the driver requires CPU accessible SGLs and call the right API. Maybe the block layer could do the same trick for O_DIRECT? This would also directly solve the P2P problem with hfi1/qib/rxe, as I'd likely also say that pci_p2pdma_map_sg() returns the same DMA only sgl thing. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 09:02:08AM +0100, Christoph Hellwig wrote: > On Tue, Jan 29, 2019 at 08:58:35PM +, Jason Gunthorpe wrote: > > On Tue, Jan 29, 2019 at 01:39:49PM -0700, Logan Gunthorpe wrote: > > > > > implement the mapping. And I don't think we should have 'special' vma's > > > for this (though we may need something to ensure we don't get mapping > > > requests mixed with different types of pages...). > > > > I think Jerome explained the point here is to have a 'special vma' > > rather than a 'special struct page' as, really, we don't need a > > struct page at all to make this work. > > > > If I recall your earlier attempts at adding struct page for BAR > > memory, it ran aground on issues related to O_DIRECT/sgls, etc, etc. > > Struct page is what makes O_DIRECT work, using sgls or biovecs, etc on > it work. Without struct page none of the above can work at all. That > is why we use struct page for backing BARs in the existing P2P code. > Not that I'm a particular fan of creating struct page for this device > memory, but without major invasive surgery to large parts of the kernel > it is the only way to make it work. I don't think anyone is interested in O_DIRECT/etc for RDMA doorbell pages. .. and again, I recall Logan already attempted to mix non-CPU memory into sgls and it was a disaster. You pointed out that one cannot just put iomem addressed into a SGL without auditing basically the entire block stack to prove that nothing uses iomem without an iomem accessor. I recall that proposal veered into a direction where the block layer would just fail very early if there was iomem in the sgl, so generally no O_DIRECT support anyhow. We already accepted the P2P stuff from Logan as essentially a giant special case - it only works with RDMA and only because RDMA MR was hacked up with a special p2p callback. I don't see why a special case with a VMA is really that different. If someone figures out the struct page path down the road it can obviously be harmonized with this VMA approach pretty easily. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 03:43:32PM -0500, Jerome Glisse wrote: > On Wed, Jan 30, 2019 at 08:11:19PM +, Jason Gunthorpe wrote: > > On Wed, Jan 30, 2019 at 01:00:02PM -0700, Logan Gunthorpe wrote: > > > > > We never changed SGLs. We still use them to pass p2pdma pages, only we > > > need to be a bit careful where we send the entire SGL. I see no reason > > > why we can't continue to be careful once their in userspace if there's > > > something in GUP to deny them. > > > > > > It would be nice to have heterogeneous SGLs and it is something we > > > should work toward but in practice they aren't really necessary at the > > > moment. > > > > RDMA generally cannot cope well with an API that requires homogeneous > > SGLs.. User space can construct complex MRs (particularly with the > > proposed SGL MR flow) and we must marshal that into a single SGL or > > the drivers fall apart. > > > > Jerome explained that GPU is worse, a single VMA may have a random mix > > of CPU or device pages.. > > > > This is a pretty big blocker that would have to somehow be fixed. > > Note that HMM takes care of that RDMA ODP with my ODP to HMM patch, > so what you get for an ODP umem is just a list of dma address you > can program your device to. The aim is to avoid the driver to care > about that. The access policy when the UMEM object is created by > userspace through verbs API should however ascertain that for mmap > of device file it is only creating a UMEM that is fully covered by > one and only one vma. GPU device driver will have one vma per logical > GPU object. I expect other kind of device do that same so that they > can match a vma to a unique object in their driver. A one VMA rule is not really workable. With ODP VMA boundaries can move around across the lifetime of the MR and we have no obvious way to fail anything if userpace puts a VMA boundary in the middle of an existing ODP MR address range. I think the HMM mirror API really needs to deal with this for the driver somehow. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/armada: add mmp2 support
Heavily based on the Armada 510 (Dove) support.
Tested to work well with Display 1 and Display 2 clocks driving the internal
panel on the OLPC XO 1.75 laptop. Some tweaking might be required if anyone
wants to use it with a MIPI or HDMI encoder.
The data sheet is not available, but James Cameron of OLPC kindly
provided some details about the LCD_SCLK_DIV register.
Link: https://lists.freedesktop.org/archives/dri-devel/2018-December/201021.html
Signed-off-by: Lubomir Rintel
---
Applies on top of "drm-armada-devel" branch of
git://git.armlinux.org.uk/~rmk/linux-arm.git
Changes since v1:
- Aligned with more recent Armada 510 support: using the same clock
names and allowing for more flexible pixel clock source selection.
drivers/gpu/drm/armada/Makefile | 1 +
drivers/gpu/drm/armada/armada_610.c | 143 +++
drivers/gpu/drm/armada/armada_crtc.c | 4 +
drivers/gpu/drm/armada/armada_drm.h | 1 +
drivers/gpu/drm/armada/armada_hw.h | 10 ++
5 files changed, 159 insertions(+)
create mode 100644 drivers/gpu/drm/armada/armada_610.c
diff --git a/drivers/gpu/drm/armada/Makefile b/drivers/gpu/drm/armada/Makefile
index 9bc3c3213724..5bbf86324cda 100644
--- a/drivers/gpu/drm/armada/Makefile
+++ b/drivers/gpu/drm/armada/Makefile
@@ -2,6 +2,7 @@
armada-y := armada_crtc.o armada_drv.o armada_fb.o armada_fbdev.o \
armada_gem.o armada_overlay.o armada_plane.o armada_trace.o
armada-y += armada_510.o
+armada-y += armada_610.o
armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o
obj-$(CONFIG_DRM_ARMADA) := armada.o
diff --git a/drivers/gpu/drm/armada/armada_610.c
b/drivers/gpu/drm/armada/armada_610.c
new file mode 100644
index ..586965fca907
--- /dev/null
+++ b/drivers/gpu/drm/armada/armada_610.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2012 Russell King
+ * Copyright (C) 2018,2019 Lubomir Rintel
+ * Largely based on Armada 510 support
+ *
+ * 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.
+ *
+ * Armada MMP2 variant support
+ */
+#include
+#include
+#include
+#include "armada_crtc.h"
+#include "armada_drm.h"
+#include "armada_hw.h"
+
+struct armada610_variant_data {
+ struct clk *clks[4];
+ struct clk *sel_clk;
+};
+
+static int armada610_crtc_init(struct armada_crtc *dcrtc, struct device *dev)
+{
+ struct armada610_variant_data *v;
+ struct property *prop;
+ struct clk *clk;
+ const char *s;
+ int idx;
+
+ v = devm_kzalloc(dev, sizeof(*v), GFP_KERNEL);
+ if (!v)
+ return -ENOMEM;
+
+ dcrtc->variant_data = v;
+
+ of_property_for_each_string(dev->of_node, "clock-names", prop, s) {
+ if (!strcmp(s, "ext_ref_clk0"))
+ idx = 0;
+ else if (!strcmp(s, "ext_ref_clk1"))
+ idx = 1;
+ else if (!strcmp(s, "plldivider"))
+ idx = 2;
+ else if (!strcmp(s, "axibus"))
+ idx = 3;
+ else
+ continue;
+
+ clk = devm_clk_get(dev, s);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk) == -ENOENT ? -EPROBE_DEFER :
+ PTR_ERR(clk);
+ v->clks[idx] = clk;
+ }
+
+ return 0;
+}
+
+static const u32 armada610_clk_sels[] = {
+ SCLK_610_DISP0,
+ SCLK_610_DISP1,
+ SCLK_610_PLL,
+ SCLK_610_AXI,
+};
+
+static const struct armada_clocking_params armada610_clocking = {
+ /* HDMI requires -0.6%..+0.5% */
+ .permillage_min = 0,
+ .permillage_max = 2000,
+ .settable = BIT(0) | BIT(1),
+ .div_max = SCLK_610_INT_DIV_MASK,
+};
+
+/*
+ * This gets called with sclk = NULL to test whether the mode is
+ * supportable, and again with sclk != NULL to set the clocks up for
+ * that. The former can return an error, but the latter is expected
+ * not to.
+ */
+static int armada610_crtc_compute_clock(struct armada_crtc *dcrtc,
+ const struct drm_display_mode *mode, uint32_t *sclk)
+{
+ struct armada610_variant_data *v = dcrtc->variant_data;
+ unsigned long desired_khz = mode->crtc_clock;
+ struct armada_clk_result res;
+ int ret, idx;
+
+ idx = armada_crtc_select_clock(dcrtc, &res, &armada610_clocking,
+ v->clks, ARRAY_SIZE(v->clks),
+ desired_khz);
+ if (idx < 0)
+ return idx;
+
+ ret = clk_prepare_enable(res.clk);
+ if (ret)
+ return ret;
+
+ if (sclk) {
+ clk_set_rate(res.clk, res.desired_clk_hz);
+
+ *sclk = 0x1000; /* No idea */
+ *sclk |= 1 << 8;/* MIPI clock bypass */
+
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 12:45:46PM -0700, Logan Gunthorpe wrote: > > > On 2019-01-30 12:06 p.m., Jason Gunthorpe wrote: > >> Way less problems than not having struct page for doing anything > >> non-trivial. If you map the BAR to userspace with remap_pfn_range > >> and friends the mapping is indeed very simple. But any operation > >> that expects a page structure, which is at least everything using > >> get_user_pages won't work. > > > > GUP doesn't work anyhow today, and won't work with BAR struct pages in > > the forseeable future (Logan has sent attempts on this before). > > I don't recall ever attempting that... But patching GUP for special > pages or VMAS; or working around by not calling it in some cases seems > like the thing that's going to need to be done one way or another. Remember, the long discussion we had about how to get the IOMEM annotation into SGL? That is a necessary pre-condition to doing anything with GUP in DMA using drivers as GUP -> SGL -> DMA map is pretty much the standard flow. > > Jerome made the HMM mirror API use this flow, so afer his patch to > > switch the ODP MR to use HMM, and to switch GPU drivers, it will work > > for those cases. Which is more than the zero cases than we have today > > :) > > But we're getting the same bait and switch here... If you are using HMM > you are using struct pages, but we're told we need this special VMA hack > for cases that don't use HMM and thus don't have struct pages... Well, I don't know much about HMM, but the HMM mirror API looks like a version of MMU notifiers that offloads a bunch of dreck to the HMM code core instead of drivers. The RDMA code got hundreds of lines shorter by using it. Some of that dreck is obtaining a DMA address for the user VMAs, including using multiple paths to get them. A driver using HMM mirror doesn't seem to call GUP at all, HMM mirror handles that, along with various special cases, including calling out to these new VMA ops. I don't really know how mirror relates to other parts of HMM, like the bits that use struct pages. Maybe it also knows about more special cases created by other parts of HMM? So, I see Jerome solving the GUP problem by replacing GUP entirely using an API that is more suited to what these sorts of drivers actually need. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 03:52:13PM -0700, Logan Gunthorpe wrote: > > > On 2019-01-30 2:50 p.m., Jason Gunthorpe wrote: > > On Wed, Jan 30, 2019 at 02:01:35PM -0700, Logan Gunthorpe wrote: > > > >> And I feel the GUP->SGL->DMA flow should still be what we are aiming > >> for. Even if we need a special GUP for special pages, and a special DMA > >> map; and the SGL still has to be homogenous > > > > *shrug* so what if the special GUP called a VMA op instead of > > traversing the VMA PTEs today? Why does it really matter? It could > > easily change to a struct page flow tomorrow.. > > Well it's so that it's composable. We want the SGL->DMA side to work for > APIs from kernel space and not have to run a completely different flow > for kernel drivers than from userspace memory. If we want to have these DMA-only SGLs anyhow, then the kernel flow can use them too. In the kernel it easier because the 'exporter' already knows it is working with BAR memory, so it can just do something like this: struct dma_sg_table *sgl_dma_map_pci_bar(struct pci_device *from, struct device *to, unsigned long bar_ptr, size_t length) And then it falls down the same DMA-SGL-only kind of flow that would exist to support the user side. ie it is the kernel version of the API I described below. > For GUP to do a special VMA traversal it would now need to return > something besides struct pages which means no SGL and it means a > completely different DMA mapping call. GUP cannot support BAR memory because it must only return CPU memory - I think too many callers make this assumption for it to be possible to change it.. (see below) A new-GUP can return DMA addresses - so it doesn't have this problem. > > Would you feel better if this also came along with a: > > > > struct dma_sg_table *sgl_dma_map_user(struct device *dma_device, > > void __user *prt, size_t len) > > That seems like a nice API. But certainly the implementation would need > to use existing dma_map or pci_p2pdma_map calls, or whatever as part of > it... I wonder how Jerome worked the translation, I haven't looked yet.. > We actually stopped caring about the __iomem problem. We are working > under the assumption that pages returned by devm_memremap_pages() can be > accessed as normal RAM and does not need the __iomem designation. As far as CPU mapped uncached BAR memory goes, this is broadly not true. s390x for instance requires dedicated CPU instructions to access BAR memory. x86 will fault if you attempt to use a SSE algorithm on uncached BAR memory. The kernel has many SSE accelerated algorithsm so you can never pass these special p2p SGL's through to them either. (think parity or encryption transformations through the block stack) Many platforms have limitations on alignment and access size for BAR memory - you can't just blindly call memcpy and expect it to work. (TPM is actually struggling with this now, confusingly different versions of memcpy are giving different results on some x86 io memory) Other platforms might fault or corrupt if an unaligned access is attempted to BAR memory. In short - I don't see a way to avoid knowing about __iomem in the sgl. There are too many real use cases that require this knowledge, and too many places that touch the SGL pages with the CPU. I think we must have 'DMA only' SGLs and code paths that are known DMA-only clean to make it work properly with BAR memory. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] linux-firmware: update firmware for mhdp8546
Updated firmware for Cadence MHDP8546 DP bridge.
Release version: 1.2.15
---
cadence/mhdp8546.bin | Bin 131072 -> 131072 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/cadence/mhdp8546.bin b/cadence/mhdp8546.bin
index
01a31f6775e1c4d8d889216e78ef90e62888c487..40097e0ec908ab5c4b54803f4b99519ced7a5e3d
100755
GIT binary patch
delta 20442
zcmbun30PCt)-b$JCXgHz6r)0b5C}M+0$R0*1p=l_wnAH4r(PL?L)EIawOTcUmZGIC
zK)IL14hT|{RHGuc5ZkNLA`l5OD26Cbm7H&#puO++-2eOk=lOmf_St7o
zYp=ETT6?d(_C8T6J(Wt&VqaEyX^EhS#qB?t!2XPNGK&2LmlyAiBJo3n#Z$~%I~ql9
z{)*`Lobt+92_3g$BptWR7ok}~IAI`nlzS<69ps0nS_vU93AKTGK54r
zu6PE-Oqd5@4uqMIH=T|x8uAEjn%=#IqnRfzS;w#zCF~;%+Zm5%&~cmH`98pl}}!C3OO5kfn`W9UXTe1zJe{yr#=AIU~}-UwxmKx`B#
zARh3S1n%>v3f=Rlb7|hlTDcD$hoGxYU~@afLTHZw)lSG?1ziwNaiJm^UY?Fd
zXf8BBfplEyyC`ziMxY4<>rp1K>r)h&3?Y3litGf|HI9P%AEU@?5I%(9xeM~uC^B{j
zii`(Xk?%tci2Vkt&_0=tdus|EmmUf-0PpR9w9*5R^#oc$b~x`LMdVs&bQ%hhpb`Sz
zNQRIO;SqG?4Q0DWg8)D$NQ{6O=m5eV$a63qL!Gtot^|EU=03hJ)aO9D9rEYy1|k5#
zLP&=~-4zf%fp-zq!6Dp-I)%G~P~^vuc>*dIKwJo{`4iq}K_Om%A}0_dMom?SfN@Kf
z=yXbGwssrv1H#$OC{j2Uc;Jg74@1ZUCa;(dA_l511U2^r5}F_%F)9xs58B29%_|@v
z7$6)%^+rA_2D#r1dBux?OeQRW@rO_ddD>+lXG`c;<3vk=7Z6r`i6V_qsD#4p5Q-o$
zWyKJ;vw%)`7eS+P2sIG)LH-GdBMza+@=``h5L$MKaE%hY!TAbBmT~}>kxV8s3L$+P
zSlbO?fX|V$RY>)^Yrdo16RBPsjsqM}k)=gGi(FBQT#;R4y+tVDRhJ+XHE~e(E3S>N
z5UWSeRkV9%$GbMhyHxS6k^~o-;9A9dV~1zNi!IqvCZ{oe@V0rrRVFgc$QN5=Taef2-d(H;9A
z1;J|Z5D3BleY{Kvk5{e##z_63eNmC{aB
zjy>oVF%&gr2%iwmt|wmc6?y~=WeA5J&RM~3q^bO%wbA&=eR3swT7us@_zZJgy*<_VZRYI;}&5?VuV19)esSa
z&#`?(onSe(gP1seGq!^GeEfK9DRFGP3Y&Lw(u5)myH0#RF$QZm>6kbNgIbgP-xlWo
zWvq*=u8h={MP^;G#g}j1aA9-tip`?#&H8MD^0#1-#A>0P_3#O?DBykJ10D+u0chX`C9q9EW4?NKg
z(BWPW$P-T_12mO5T6--)+dim$^u99@w2M4nXXt
z$xi`x2(}CQ3c)^teuJd;4!WL2u6iPGa*r~j9{LSWO4dIyTWNDdoY?$SJy}u3G8P)u
zs}+)KAfUQ526d>HM(JMnD9Jl%3A)6>I!|iEF&vKW(Z+9xrm$7mr^JilA()z29-ipE
z=@HJCzlElGW%YX0c#!Lf>hNh;E^#A#c~;t^DvrDv;hZYAy$R_TJd&pE3~=BhsTP`=
z5+^U@bq8;Mn)O%Tx2IXMf6|w|cvW;2r=Hgl`{;s4_o!fz23JWl4PDee
zHoZWUOqz#<5tk>0V?ttZQl!7nBfA+@aU~{H#j_hx6OO3Xo&PY!&c
z=V2B1)F``MCTsrFFd?}*YK-&#yVqlosax`2C0}o^*=qt{Yp&4`Y94@3bAj>d#uqO
z#E7ZkSkcL-sjp)ry*$drH6eJq@vPSVfY3x30%+cL7amY3jvQF=*fa9RH`iIyIL|aj
z#U-+*1^NHQs}UbQbYV;tr@hffa*J0kzAy&o!@KVB$wSjRG3*aQIU|1Zss{_X!RsDm
ztb3qlp|lqcPa1gVK`VQc6lt`|t5z#MU3Q^l{p8-5s6Vz7>{^AYNq1xU=`n9M3-}Gc>a|Y
z+#h4Q1_lQojV@O)U^@l|9cPLo>$LX0^nhb<>uB4rk1ovEI*Q+TaRyEWILJGLxWD8(
zT4f)s@cgs3#+SNqO|A>
zFLKd@cp^M{(v05*Df4~%3{=IMo2{FH8WYK12PHF5@cBVzf>l`t_moVGy2dJ3rRgto
zHZ~ADqs7=Mf{gZ`WEgBV3|=p(z_VKJSBD|Isln(X;V4T
z867hI>%oc4mv5d)57c-{{J{m-oWCg#*S6f*eS*i7}lK_X-5lu6Fg{uZD_*s>>L>jhFLH0i3QLv{GiFVmoW?X;^G6N0x{ev2D!$>;efbXB
zv|tc;(R;ndEfwY5jzmH=s}tK!BS$@UM~AK
z`n}9GN#VcpW&*3qSr^YA!wi`*dU#e|#v;7K9$uIor
zhmQ$xKyClZF#qpyF(p42;D{Y*mYg$4%)#H>%klD*nx9s&8tM#k%Vm!JXF6-!2%F@r
zRbrmn-`;A>I^qdNkpzljM@r0eR;7npa@Hv^uPJ<|@RP6CL77})F=_7M>*Pi{tA(qP
zG*FUrl>Aa<8Tt7=jr^RU;gP(S&Whm}B=(VzJ535qRvMF(bK`+4Za{%+BTlcQE-AxA?$XEn)NA
z^KJ)<;9thbL8pyc-)?KhNA^}yEooH4WkNiE7Iu?(bAH6CTOip>t#>f;-%bOyzWT>z
zd~|JP1b?`m9l5I5^_URX-GI)kxCWCqymxXLCgLy$%Iw|w_wpM<^_b1%{ZTW;Wikp0VS-;un)K{tm_siP!DKQ~HOpzZlD79_wdW4Q
zrB;U4gwgT~L&JQ&0%+(e+
z$+s{=FvjEwxt>e1oMx>OpWlHw@gTz$pj78vzuLNfjr|Bs4h`Ud5adZDM`*QHxySdi
zM-?aP>VW>?Kr34}k1lEmJ1ELops3>5Nm|B%6``ID;B=*c3S`P*MF0^MLSXE^sJ;Q5
zt5&d4LhpbZZ7zdD1vfJhMRg5m*x?j=lAvsqsM44fGg2^Ol!hIq-!qUytzRK-&Tbo+
zGBxW(jzPQkG7ro=YYNq%1^87Q$-(F3=#Fy9e-G%d4yY;y%%n1N)#}VuYjh2H=%kIiQ25d_V%vya780kvRi$
zcxDes;Q5aM9UGBv56I!UY{1S!_WGsPfQ#F{Bp_n5QbNQ+HlZ@UNoY*;$d@RGHIIS&>1#qo~+ekAa@p
ziBOps(-AMrf-yO@YU^G}H;x4S&cCm&}q^h*Ppjo;{AKm9^j5Gl(A9lCjMW
zc^mAU45nnf$bJKcAmbMz>*Z--KRfVG?bm720E>*$dD@whW<#eDYJKvnw>Yo9Wz2lWHbyrA-A6vVho^Eb-szAa^=ye>Cuw
zl3!_Zivypk`-L`bbCBB{#DV0%U`Zpb-{c_Qb3hIGC7N92z~?Ov)-}*LJL2QjQREt8
zY)YJBnZtgL_MaIUx%o{(ubS*odn$`c$%W9FnVg`D<&tp@$`>eHaX4sDF5uh)OLC=R55Gq^URKho=zS1LtIa
za#y4-#$jvevo}BI-wXV=Wb$f=_S6XJmb)TNv9ZkOV4?b&OnjjRR_jq*@Ubk_Rlq>G
zEu1R0{?1)|nH_fzprrhHzJWT8Q~<(f4i%<-o-z+Eet(1Bq!Kzy#e6l
zuXh2yx}kXQ9<}Gr%E^sy0r*elBK7S6b4sdiB?=BrM-VOf=4?idf6a
znh|(rfFq&)?#p8anJI*sP*rtzOX>iiApFHX+zA_vQ+M^J?uN(Me$@OSlmgHn@1EB*
zsfLG
zu&(68e!P;(U8%`k1?GpI&g%6ty-$3eA;H)7^Vc4W$WM5uKjTm0OvYA)q?*HkVJD&9TJPW!4(?N@>~M3co=x7q18a!nOAg5S?K^m^d_Sk;w>t`oTCb&=anH&!cU8Ac
z;hrVo{gh4!1wy>C%rIH8Jw|)nySm!9z0Rk)Qe^no=;}&uW2HzR)Ncyvhj)Eozp>IA
zUZ~aJBhg%EsTU*NCaj8O-+(d1fyFo)4}dL&pg&{d9pSZ&WBb#8&d~`Y<{pjc(PaCi
zG_S}}M@Flov%Ob$B&@l!Eq{|>r}V5cb*6HQw>m_T;MK3b@bti3R>4&CSbv=?@gO$6
zwts}~1Xk2i#ge>4c)vbXkzlK!&0#M&wRa;5)wv4C7Vq{(Z`c{+Cz$hJs`s+orG<|T
zS6Bu<7BQpx@h)es!txmQh4vP}Q>ViOEsx2wcW{3>qVXxFGj~MQn*pFT?4?3ddWD7W
z!ACpu6P)?d;w>V;%$cN8Cn?)oy{-8#skQx5oiI5*tr@UwI7_7~!FYb;s>krtnZJ8v
zo@-w6I=EckK|k
z2>O@o1+?B)IKy6YJoe4{*PD+>;V7I>F1n+EZsIo=?`tm00C`H;ZA(!)Q$DtaB{Ve+
zT2oZ!umt0U1apd-3QM3;b{SF%)L}1Gag>D|b;>999ay8EEQkd*p1(we;r@6k&|9#A
z>2DV%*n5=<-HCrB$zutoWI~o2%NJB;kVUsOp*!_2-qDt+Yfr)YVz~4m>!VEl>^trh
zAj7ZAI=+USc}M4unWBbSWzz}UJO9I{X2}AY)ZPZ#C6SEd`3sO39*LPgU_h(hCnmhP
zK;e7G945Ug^tN4L*?v*lMk)FISv!{t(v}0Zhvb_WY+r?DG6`UdUowrj6R})waq)s_
z5@VPu55o%eYT%xb8NE%Ipw0NK}Jf*3PiQ)0Uf@@I8}s^>KQ*35|F@`FdzDM}c^
zDlQDQeTl1zW6#9|2U8jT%2yK8-ttp;Pz_D?9WH)t)*rKkr!=_=oNu}70_Lv71WW4h
z(v
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote: > I don't see why a special case with a VMA is really that different. Well one *really* big difference is the VMA changes necessarily expose specialized new functionality to userspace which has to be supported forever and may be difficult to change. The p2pdma code is largely in-kernel and we can rework and change the interfaces all we want as we improve our struct page infrastructure. I'd also argue that p2pdma isn't nearly as specialized as this VMA thing and can be used pretty generically to do other things. Though, the other ideas we've talked about doing are pretty far off and may have other challenges. Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/4] drm: bridge: add support for Cadence MHDP DPI/DP bridge
From: Quentin Schulz
This adds support for Cadence MHDP DPI to DP bridge.
Basically, it takes a DPI stream as input and output it encoded in DP
format. It supports SST and MST modes.
Changes made in the low level driver (cdn-dp-reg.*):
- moved it to from drivers/gpu/drm/rockchip to
drivers/gpu/drm/bridge/cdns-mhdp-common.c and
include/drm/bridge/cdns-mhdp-common.h
- functions for sending/receiving commands are now public
- added functions for reading registers and link training
adjustment
Changes made in RK's driver (cdn-dp-core.*):
- Moved audio_info and audio_pdev fields from cdn_dp_device to
cdns_mhdp_device structure.
Signed-off-by: Quentin Schulz
Signed-off-by: Piotr Sroka
Signed-off-by: Damian Kos
---
drivers/gpu/drm/bridge/Kconfig|9 +
drivers/gpu/drm/bridge/Makefile |3 +
.../cdns-mhdp-common.c} | 186 ++-
drivers/gpu/drm/bridge/cdns-mhdp-mst.c| 549 +++
drivers/gpu/drm/bridge/cdns-mhdp.c| 1349 +
drivers/gpu/drm/bridge/cdns-mhdp.h| 209 +++
drivers/gpu/drm/rockchip/Kconfig |4 +-
drivers/gpu/drm/rockchip/Makefile |2 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c| 34 +-
drivers/gpu/drm/rockchip/cdn-dp-core.h|5 +-
include/drm/bridge/cdns-mhdp-cbs.h| 29 +
.../drm/bridge/cdns-mhdp-common.h | 68 +-
12 files changed, 2384 insertions(+), 63 deletions(-)
rename drivers/gpu/drm/{rockchip/cdn-dp-reg.c => bridge/cdns-mhdp-common.c}
(85%)
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-mst.c
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.h
create mode 100644 include/drm/bridge/cdns-mhdp-cbs.h
rename drivers/gpu/drm/rockchip/cdn-dp-reg.h =>
include/drm/bridge/cdns-mhdp-common.h (91%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..2b7c568756fb 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -35,6 +35,15 @@ config DRM_CDNS_DSI
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+config DRM_CDNS_MHDP
+ tristate "Cadence DPI/DP bridge"
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ depends on OF
+ help
+ Support Cadence DPI to DP bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+
config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..b80f3d6ed2a6 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -16,4 +16,7 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-$(CONFIG_DRM_CDNS_MHDP) += mhdp8546.o
obj-y += synopsys/
+
+mhdp8546-objs := cdns-mhdp-common.o cdns-mhdp.o cdns-mhdp-mst.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
similarity index 85%
rename from drivers/gpu/drm/rockchip/cdn-dp-reg.c
rename to drivers/gpu/drm/bridge/cdns-mhdp-common.c
index a32ee26fd36b..f0160df52aed 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
* Author: Chris Zhong
@@ -13,14 +14,17 @@
*/
#include
-#include
#include
+#include
#include
#include
#include
-#include "cdn-dp-core.h"
-#include "cdn-dp-reg.h"
+#include
+
+#include
+#include
+#include
#define CDNS_DP_SPDIF_CLK 2
#define FW_ALIVE_TIMEOUT_US100
@@ -29,10 +33,27 @@
#define LINK_TRAINING_RETRY_MS 20
#define LINK_TRAINING_TIMEOUT_MS 500
+static inline u32 get_unaligned_be24(const void *p)
+{
+ const u8 *_p = p;
+
+ return _p[0] << 16 | _p[1] << 8 | _p[2];
+}
+
+static inline void put_unaligned_be24(u32 val, void *p)
+{
+ u8 *_p = p;
+
+ _p[0] = val >> 16;
+ _p[1] = val >> 8;
+ _p[2] = val;
+}
+
void cdns_mhdp_set_fw_clk(struct cdns_mhdp_device *mhdp, unsigned long clk)
{
writel(clk / 100, mhdp->regs + SW_CLK_H);
}
+EXPORT_SYMBOL(cdns_mhdp_set_fw_clk);
void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
{
@@ -82,6 +103,7 @@ void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
/* enable Mailbox and PIF interrupt */
writel(0, mhdp->regs + APB_INT_MASK);
}
+EXPORT_SYMBOL(cdns_mhdp_clock_reset);
static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
{
@@ -128,7 +150,7 @@ static int cdns_mhdp_mailbox_validate_receive(struct
cdns_mhdp_device *mhdp,
hea
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 06:26:53PM +0100, Christoph Hellwig wrote: > On Wed, Jan 30, 2019 at 10:55:43AM -0500, Jerome Glisse wrote: > > Even outside GPU driver, device driver like RDMA just want to share their > > doorbell to other device and they do not want to see those doorbell page > > use in direct I/O or anything similar AFAICT. > > At least Mellanox HCA support and inline data feature where you > can copy data directly into the BAR. For something like a usrspace > NVMe target it might be very useful to do direct I/O straight into > the BAR for that. It doesn't really work like that. The PCI-E TLP sequence to trigger this feature is very precise, and the data requires the right headers/etc. Mixing that with O_DIRECT seems very unlikely. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/savage: mark expected switch fall-throughs
On 1/30/19 10:35 AM, Daniel Vetter wrote: > On Tue, Jan 29, 2019 at 02:20:06PM -0600, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> This patch fixes the following warnings: >> >> drivers/gpu/drm/savage/savage_state.c:301:8: warning: this statement may >> fall through [-Wimplicit-fallthrough=] >> drivers/gpu/drm/savage/savage_state.c:438:8: warning: this statement may >> fall through [-Wimplicit-fallthrough=] >> drivers/gpu/drm/savage/savage_state.c:559:8: warning: this statement may >> fall through [-Wimplicit-fallthrough=] >> drivers/gpu/drm/savage/savage_state.c:697:8: warning: this statement may >> fall through [-Wimplicit-fallthrough=] >> >> Warning level 3 was used: -Wimplicit-fallthrough=3 >> >> This patch is part of the ongoing efforts to enabling >> -Wimplicit-fallthrough. >> >> Signed-off-by: Gustavo A. R. Silva > > This and the via patch merged to drm-misc-next, thanks. > -Daniel > Daniel, I wonder if you can take this one too: https://lore.kernel.org/patchwork/patch/1001180/ Thanks -- Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On 2019-01-30 2:50 p.m., Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 02:01:35PM -0700, Logan Gunthorpe wrote: > >> And I feel the GUP->SGL->DMA flow should still be what we are aiming >> for. Even if we need a special GUP for special pages, and a special DMA >> map; and the SGL still has to be homogenous > > *shrug* so what if the special GUP called a VMA op instead of > traversing the VMA PTEs today? Why does it really matter? It could > easily change to a struct page flow tomorrow.. Well it's so that it's composable. We want the SGL->DMA side to work for APIs from kernel space and not have to run a completely different flow for kernel drivers than from userspace memory. For GUP to do a special VMA traversal it would now need to return something besides struct pages which means no SGL and it means a completely different DMA mapping call. > Would you feel better if this also came along with a: > > struct dma_sg_table *sgl_dma_map_user(struct device *dma_device, > void __user *prt, size_t len) That seems like a nice API. But certainly the implementation would need to use existing dma_map or pci_p2pdma_map calls, or whatever as part of it... , > flow which returns a *DMA MAPPED* sgl that does not have struct page > pointers as another interface? > > We can certainly call an API like this from RDMA for non-ODP MRs. > > Eliminating the page pointers also eliminates the __iomem > problem. However this sgl object is not copyable or accessible from > the CPU, so the caller must be sure it doesn't need CPU access when > using this API. We actually stopped caring about the __iomem problem. We are working under the assumption that pages returned by devm_memremap_pages() can be accessed as normal RAM and does not need the __iomem designation. The main problem now is that code paths need to know to use pci_p2pdma_map or not. And in theory this could be pushed into regular dma_map implementations but we'd have to get it into all of them which is a pain. Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 3/4] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings
From: Quentin Schulz
Document the bindings used for the Cadence MHDP DPI/DP bridge.
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/cdns,mhdp.txt | 47 +++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
new file mode 100644
index ..df2a00163ccf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
@@ -0,0 +1,47 @@
+Cadence MHDP bridge
+==
+
+The Cadence MHDP bridge is a DPI to DP bridge.
+
+Required properties:
+- compatible: should be "cdns,mhdp8546",
+- reg: physical base address and length of the controller's registers,
+- clocks: DP bridge clock, it's used by the IP to know how to translate
+ a number of clock cycles into a time (which is used to comply
+ with DP standard timings and delays),
+- phys: see the Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
+- phy-names: must be "dpphy"
+
+Required subnodes:
+- ports: Ports as described in Documentation/devictree/bindings/graph.txt
+ Port 0 - input port representing the DP bridge input
+ Port 1 - output port representing the DP bridge output
+
+Example:
+
+ mhdp: dp-bridge@f0fb00 {
+ compatible = "cdns,mhdp8546";
+ reg = <0xf0 0xfb00 0x0 0x100>;
+ clocks = <&mhdp_clock>;
+ phys = <&dp_phy>;
+ phy-names = "dpphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dp_bridge_input: endpoint {
+ remote-endpoint = <&xxx_dpi_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dp_bridge_output: endpoint {
+ remote-endpoint =
<&xxx_dp_connector_input>;
+ };
+ };
+ };
+ };
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On 2019-01-30 12:22 p.m., Jerome Glisse wrote: > On Wed, Jan 30, 2019 at 06:56:59PM +, Jason Gunthorpe wrote: >> On Wed, Jan 30, 2019 at 10:17:27AM -0700, Logan Gunthorpe wrote: >>> >>> >>> On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote: Every attempt to give BAR memory to struct page has run into major trouble, IMHO, so I like that this approach avoids that. And if you don't have struct page then the only kernel object left to hang meta data off is the VMA itself. It seems very similar to the existing P2P work between in-kernel consumers, just that VMA is now mediating a general user space driven discovery process instead of being hard wired into a driver. >>> >>> But the kernel now has P2P bars backed by struct pages and it works >>> well. >> >> I don't think it works that well.. >> >> We ended up with a 'sgl' that is not really a sgl, and doesn't work >> with many of the common SGL patterns. sg_copy_buffer doesn't work, >> dma_map, doesn't work, sg_page doesn't work quite right, etc. >> >> Only nvme and rdma got the special hacks to make them understand these >> p2p-sgls, and I'm still not convinced some of the RDMA drivers that >> want access to CPU addresses from the SGL (rxe, usnic, hfi, qib) don't >> break in this scenario. >> >> Since the SGLs become broken, it pretty much means there is no path to >> make GUP work generically, we have to go through and make everything >> safe to use with p2p-sgls before allowing GUP. Which, frankly, sounds >> impossible with all the competing objections. >> >> But GPU seems to have a problem unrelated to this - what Jerome wants >> is to have two faulting domains for VMA's - visible-to-cpu and >> visible-to-dma. The new op is essentially faulting the pages into the >> visible-to-dma category and leaving them invisible-to-cpu. >> >> So that duality would still have to exists, and I think p2p_map/unmap >> is a much simpler implementation than trying to create some kind of >> special PTE in the VMA.. >> >> At least for RDMA, struct page or not doesn't really matter. >> >> We can make struct pages for the BAR the same way NVMe does. GPU is >> probably the same, just with more mememory at stake? >> >> And maybe this should be the first implementation. The p2p_map VMA >> operation should return a SGL and the caller should do the existing >> pci_p2pdma_map_sg() flow.. > > For GPU it would not work, GPU might want to use main memory (because > it is running out of BAR space) it is a lot easier if the p2p_map > callback calls the right dma map function (for page or io) rather than > having to define some format that would pass down the information. >> >> Worry about optimizing away the struct page overhead later? > > Struct page do not fit well for GPU as the BAR address can be reprogram > to point to any page inside the device memory (think 256M BAR versus > 16GB device memory). Forcing struct page on GPU driver would require > major surgery to the GPU driver inner working and there is no benefit > to have from the struct page. So it is hard to justify this. I think we have to consider the struct pages to track the address space, not what backs it (essentially what HMM is doing). If we need to add operations for the driver to map the address space/struct pages back to physical memory then do that. Creating a whole new idea that's tied to userspace VMAs still seems wrong to me. Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: Remove duplicate header
On Fri, Dec 21, 2018 at 6:06 PM Souptick Joarder wrote: > > On Fri, Dec 21, 2018 at 2:49 PM Brajeswar Ghosh > wrote: > > > > Remove hwmgr_ppt.h which is included more than once > > > > Signed-off-by: Brajeswar Ghosh > > --- > Acked-by: Souptick Joarder If no further comment, can we get this patch in queue for 5.1 ? > > > drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > > b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > > index e5a60aa44b5d..07d180ce4d18 100644 > > --- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > > +++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h > > @@ -28,7 +28,6 @@ > > #include "hardwaremanager.h" > > #include "hwmgr_ppt.h" > > #include "ppatomctrl.h" > > -#include "hwmgr_ppt.h" > > #include "power_state.h" > > #include "smu_helper.h" > > > > -- > > 2.17.1 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 12:48:33PM -0700, Logan Gunthorpe wrote: > > > On 2019-01-30 12:19 p.m., Jason Gunthorpe wrote: > > On Wed, Jan 30, 2019 at 11:13:11AM -0700, Logan Gunthorpe wrote: > >> > >> > >> On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote: > >>> I don't see why a special case with a VMA is really that different. > >> > >> Well one *really* big difference is the VMA changes necessarily expose > >> specialized new functionality to userspace which has to be supported > >> forever and may be difficult to change. > > > > The only user change here is that more things will succeed when > > creating RDMA MRs (and vice versa to GPU). I don't think this > > restricts the kernel implementation at all, unless we intend to > > remove P2P entirely.. > > Well for MRs I'd expect you are using struct pages to track the memory > some how Not really, for MRs most drivers care about DMA addresses only. The only reason struct page ever gets involved is because it is part of the GUP, SGL and dma_map family of APIs. > VMAs that aren't backed by pages and use this special interface must > therefore be creating new special interfaces that can call > p2p_[un]map... Well, those are kernel internal interfaces, so they can be changed No matter what we do, code that wants to DMA to user BAR pages must take *some kind* of special care - either it needs to use a special GUP and SGL flow, or a mixed GUP, SGL and p2p_map flow. I don't really see why one is better than the other at this point, or why doing one means we can't do the other some day later. They are fairly similar. O_DIRECT seems to be the justification for struct page, but nobody is signing up to make O_DIRECT have the required special GUP/SGL/P2P flow that would be needed to *actually* make that work - so it really isn't a justification today. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On 2019-01-30 12:06 p.m., Jason Gunthorpe wrote: >> Way less problems than not having struct page for doing anything >> non-trivial. If you map the BAR to userspace with remap_pfn_range >> and friends the mapping is indeed very simple. But any operation >> that expects a page structure, which is at least everything using >> get_user_pages won't work. > > GUP doesn't work anyhow today, and won't work with BAR struct pages in > the forseeable future (Logan has sent attempts on this before). I don't recall ever attempting that... But patching GUP for special pages or VMAS; or working around by not calling it in some cases seems like the thing that's going to need to be done one way or another. > Jerome made the HMM mirror API use this flow, so afer his patch to > switch the ODP MR to use HMM, and to switch GPU drivers, it will work > for those cases. Which is more than the zero cases than we have today > :) But we're getting the same bait and switch here... If you are using HMM you are using struct pages, but we're told we need this special VMA hack for cases that don't use HMM and thus don't have struct pages... Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/4] drm: add support for Cadence MHDP DPI/DP bridge.
Hello!
This is the series of patches that will add support for the Cadence's DPI/DP
bridge. Please note that this is a preliminary version of the driver and there
will be more patches in the future with updates, fixes and improvements.
Please keep that in mind when looking at FIXME/TODO/XXX comments.
Initially, MHDP driver was developed as a DRM bridge driver and was planed to
be placed in drivers/gpu/drm/bridge/mhdp.c. However, there was already
a driver for Cadence's DP controller developed by RockChip, but that driver
uses the different DRM framework and looks like a part of a bigger system.
Both controllers (including firmware) are quite different internally
(MST/FEC/DSC support, link training done by driver, additional commands, IRQ's
etc.) but they have similar register map, except for Framer/Streamer (which is
noticeably different), so they appear similar.
The following patches contain:
- Moving common code to drivers/gpu/drm/bridge/cdns-mhdp-common.* and
modifying it a bit (mostly new prefixes for functions and data types) so it
can be used by two, higher level, drivers.
- Modifying existing RockChip's DP driver to use the common code after changes
made to it (use the new cdns_mhdp_device structure and new function names).
- Modifying DRM helpers a bit. Some are required for new driver, some are
updates from DP 1.2 to 1.3 or 1.4.
- Adding documentation for device tree bindings.
- Adding preliminary Cadence DPI/DP bridge driver.
Some of the things that will be added later on include (but are not limited
to):
- DSC support
- FEC support
- HDCP support
Changes in v7:
- Overal code cleanup
- Patched memory leak after EDID read
- Fixed SPDX-License-Identifier tags
- Sorted includes
- In patch 4/6:
Cleanup and fix in mhdp_transfer
Replaced byteshifts with {put|get}_unaligned_be{32|24|16} (added 24bit one)
- In patch 5/6:
Removed cdns_mhdp_mst_set_threshold (not needed anymore as HW does that)
Updated cdns_mhdp_mst_set_rate_governing
Replaced request_irq with devm_request_irq
And then merged with 4/6 (as many changes in this patch altered the SST part)
- In patch 6/6:
Fix in checking devm_phy_get result
Updated bindings doc
And then merged with 4/6 (as this should be in the driver in the first place)
Changes in v6:
- Added Reviewed-bys for already reviewed patches
- Dropped patch v5-0003 (that made dp_get_lane_status helper public)
- Added patch with MST support
- Added patch with Cadence SD0801 PHY init
Changes in v5:
- Fixed Kconfig in drm/rockchip again
- Moved cdn-dp-reg.h (cdns-mhdp-common.h) to include/drm/bridge instead of
drivers/gpu/drm/bridge/
- Updated the mhdp_validate_cr function
Changes in v4:
- Fixed Kconfig in drm/rockchip
- Fixed Signed-offs
- dp_link_status() is no longer public since it's used only in drm_dp_helper.c
- Replaced EXTRA_CFLAGS with ccflags-y in drm/rockchip Makefile
Changes in v3:
- Corrected dt-bindings document
- Enabled some clocks at startup (since FW doesn't do that anymore).
- Changed Firmware file name to match the file on Linux Firmware repo.
- Added SST audio support
- Made common functions (in cdns-mhdp-common.*) public.
Changes in v2:
- Added actual description of what the patch contains, what is it for and
what's going on here in general.
- New structure. Now we have one common low level driver + two high level
drivers - one for RockChip with minimum changes and one, more general, for
Cadence.
- Dropped some changes made to DRM helpers.
- Updated the device tree bindings document.
Damian Kos (1):
drm/rockchip: prepare common code for cdns and rk dpi/dp driver
Quentin Schulz (3):
drm/dp: fix link probing for devices supporting DP 1.4+
dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings
drm: bridge: add support for Cadence MHDP DPI/DP bridge
.../bindings/display/bridge/cdns,mhdp.txt | 47 +
drivers/gpu/drm/bridge/Kconfig|9 +
drivers/gpu/drm/bridge/Makefile |3 +
drivers/gpu/drm/bridge/cdns-mhdp-common.c | 1103 ++
drivers/gpu/drm/bridge/cdns-mhdp-mst.c| 549 +++
drivers/gpu/drm/bridge/cdns-mhdp.c| 1349 +
drivers/gpu/drm/bridge/cdns-mhdp.h| 209 +++
drivers/gpu/drm/drm_dp_helper.c | 30 +-
drivers/gpu/drm/rockchip/Kconfig |4 +-
drivers/gpu/drm/rockchip/Makefile |2 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c| 234 +--
drivers/gpu/drm/rockchip/cdn-dp-core.h| 43 +-
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 969
include/drm/bridge/cdns-mhdp-cbs.h| 29 +
.../drm/bridge/cdns-mhdp-common.h | 176 ++-
15 files changed, 3606 insertions(+), 1150 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-common.c
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-mst.c
create mode 100
[PATCH v7 1/4] drm/rockchip: prepare common code for cdns and rk dpi/dp driver
- Extracted common fields from cdn_dp_device to a new cdns_mhdp_device
structure which will be used by two separate drivers later on.
- Moved some datatypes (audio_format, audio_info, vic_pxl_encoding_format,
video_info) from cdn-dp-core.c to cdn-dp-reg.h.
- Changed prefixes from cdn_dp to cdns_mhdp
cdn -> cdns to match the other Cadence's drivers
dp -> mhdp to distinguish it from a "just a DP" as the IP underneath
this registers map can be a HDMI (which is internally different,
but the interface for commands, events is pretty much the same).
- Modified cdn-dp-core.c to use the new driver structure and new function
names.
Signed-off-by: Damian Kos
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 220 +++--
drivers/gpu/drm/rockchip/cdn-dp-core.h | 40 +--
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 428 +
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 114 +--
4 files changed, 431 insertions(+), 371 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index f7b9d45aa1d6..2026bc7ffcce 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -31,11 +31,10 @@
#include
#include "cdn-dp-core.h"
-#include "cdn-dp-reg.h"
#include "rockchip_drm_vop.h"
#define connector_to_dp(c) \
- container_of(c, struct cdn_dp_device, connector)
+ container_of(c, struct cdn_dp_device, mhdp.connector)
#define encoder_to_dp(c) \
container_of(c, struct cdn_dp_device, encoder)
@@ -70,17 +69,18 @@ MODULE_DEVICE_TABLE(of, cdn_dp_dt_ids);
static int cdn_dp_grf_write(struct cdn_dp_device *dp,
unsigned int reg, unsigned int val)
{
+ struct device *dev = dp->mhdp.dev;
int ret;
ret = clk_prepare_enable(dp->grf_clk);
if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to prepare_enable grf clock\n");
+ DRM_DEV_ERROR(dev, "Failed to prepare_enable grf clock\n");
return ret;
}
ret = regmap_write(dp->grf, reg, val);
if (ret) {
- DRM_DEV_ERROR(dp->dev, "Could not write to GRF: %d\n", ret);
+ DRM_DEV_ERROR(dev, "Could not write to GRF: %d\n", ret);
return ret;
}
@@ -91,24 +91,25 @@ static int cdn_dp_grf_write(struct cdn_dp_device *dp,
static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
{
+ struct device *dev = dp->mhdp.dev;
int ret;
unsigned long rate;
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot enable dp pclk %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot enable dp pclk %d\n", ret);
goto err_pclk;
}
ret = clk_prepare_enable(dp->core_clk);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot enable core_clk %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot enable core_clk %d\n", ret);
goto err_core_clk;
}
- ret = pm_runtime_get_sync(dp->dev);
+ ret = pm_runtime_get_sync(dev);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot get pm runtime %d\n", ret);
goto err_pm_runtime_get;
}
@@ -121,18 +122,18 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
rate = clk_get_rate(dp->core_clk);
if (!rate) {
- DRM_DEV_ERROR(dp->dev, "get clk rate failed\n");
+ DRM_DEV_ERROR(dev, "get clk rate failed\n");
ret = -EINVAL;
goto err_set_rate;
}
- cdn_dp_set_fw_clk(dp, rate);
- cdn_dp_clock_reset(dp);
+ cdns_mhdp_set_fw_clk(&dp->mhdp, rate);
+ cdns_mhdp_clock_reset(&dp->mhdp);
return 0;
err_set_rate:
- pm_runtime_put(dp->dev);
+ pm_runtime_put(dev);
err_pm_runtime_get:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
@@ -143,7 +144,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
static void cdn_dp_clk_disable(struct cdn_dp_device *dp)
{
- pm_runtime_put_sync(dp->dev);
+ pm_runtime_put_sync(dp->mhdp.dev);
clk_disable_unprepare(dp->pclk);
clk_disable_unprepare(dp->core_clk);
}
@@ -176,7 +177,7 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp,
u8 *sink_count)
u8 value;
*sink_count = 0;
- ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, &value, 1);
+ ret = cdns_mhdp_dpcd_read(&dp->mhdp, DP_SINK_COUNT, &value, 1);
if (ret)
return ret;
@@ -200,12 +201,13 @@ static struct cdn_dp_port *cdn_dp_connected_port(struct
cdn_dp_device *dp)
static bool cdn_dp_check_sink_connection(struct cdn_dp_device *dp)
{
+ struct device *dev = dp->mhdp.dev;
unsigned long timeout = jiffies + msecs_t
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 10:17:27AM -0700, Logan Gunthorpe wrote: > > > On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote: > > Every attempt to give BAR memory to struct page has run into major > > trouble, IMHO, so I like that this approach avoids that. > > > > And if you don't have struct page then the only kernel object left to > > hang meta data off is the VMA itself. > > > > It seems very similar to the existing P2P work between in-kernel > > consumers, just that VMA is now mediating a general user space driven > > discovery process instead of being hard wired into a driver. > > But the kernel now has P2P bars backed by struct pages and it works > well. I don't think it works that well.. We ended up with a 'sgl' that is not really a sgl, and doesn't work with many of the common SGL patterns. sg_copy_buffer doesn't work, dma_map, doesn't work, sg_page doesn't work quite right, etc. Only nvme and rdma got the special hacks to make them understand these p2p-sgls, and I'm still not convinced some of the RDMA drivers that want access to CPU addresses from the SGL (rxe, usnic, hfi, qib) don't break in this scenario. Since the SGLs become broken, it pretty much means there is no path to make GUP work generically, we have to go through and make everything safe to use with p2p-sgls before allowing GUP. Which, frankly, sounds impossible with all the competing objections. But GPU seems to have a problem unrelated to this - what Jerome wants is to have two faulting domains for VMA's - visible-to-cpu and visible-to-dma. The new op is essentially faulting the pages into the visible-to-dma category and leaving them invisible-to-cpu. So that duality would still have to exists, and I think p2p_map/unmap is a much simpler implementation than trying to create some kind of special PTE in the VMA.. At least for RDMA, struct page or not doesn't really matter. We can make struct pages for the BAR the same way NVMe does. GPU is probably the same, just with more mememory at stake? And maybe this should be the first implementation. The p2p_map VMA operation should return a SGL and the caller should do the existing pci_p2pdma_map_sg() flow.. Worry about optimizing away the struct page overhead later? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 04:45:25PM -0500, Jerome Glisse wrote: > On Wed, Jan 30, 2019 at 08:50:00PM +, Jason Gunthorpe wrote: > > On Wed, Jan 30, 2019 at 03:43:32PM -0500, Jerome Glisse wrote: > > > On Wed, Jan 30, 2019 at 08:11:19PM +, Jason Gunthorpe wrote: > > > > On Wed, Jan 30, 2019 at 01:00:02PM -0700, Logan Gunthorpe wrote: > > > > > > > > > We never changed SGLs. We still use them to pass p2pdma pages, only we > > > > > need to be a bit careful where we send the entire SGL. I see no reason > > > > > why we can't continue to be careful once their in userspace if there's > > > > > something in GUP to deny them. > > > > > > > > > > It would be nice to have heterogeneous SGLs and it is something we > > > > > should work toward but in practice they aren't really necessary at the > > > > > moment. > > > > > > > > RDMA generally cannot cope well with an API that requires homogeneous > > > > SGLs.. User space can construct complex MRs (particularly with the > > > > proposed SGL MR flow) and we must marshal that into a single SGL or > > > > the drivers fall apart. > > > > > > > > Jerome explained that GPU is worse, a single VMA may have a random mix > > > > of CPU or device pages.. > > > > > > > > This is a pretty big blocker that would have to somehow be fixed. > > > > > > Note that HMM takes care of that RDMA ODP with my ODP to HMM patch, > > > so what you get for an ODP umem is just a list of dma address you > > > can program your device to. The aim is to avoid the driver to care > > > about that. The access policy when the UMEM object is created by > > > userspace through verbs API should however ascertain that for mmap > > > of device file it is only creating a UMEM that is fully covered by > > > one and only one vma. GPU device driver will have one vma per logical > > > GPU object. I expect other kind of device do that same so that they > > > can match a vma to a unique object in their driver. > > > > A one VMA rule is not really workable. > > > > With ODP VMA boundaries can move around across the lifetime of the MR > > and we have no obvious way to fail anything if userpace puts a VMA > > boundary in the middle of an existing ODP MR address range. > > This is true only for vma that are not mmap of a device file. This is > what i was trying to get accross. An mmap of a file is never merge > so it can only get split/butcher by munmap/mremap but when that happen > you also need to reflect the virtual address space change to the > device ie any access to a now invalid range must trigger error. Why is it invalid? The address range still has valid process memory? What is the problem in the HMM mirror that it needs this restriction? There is also the situation where we create an ODP MR that spans 0 -> U64_MAX in the process address space. In this case there are lots of different VMAs it covers and we expect it to fully track all changes to all VMAs. So we have to spin up dedicated umem_odps that carefully span single VMAs, and somehow track changes to VMA ? mlx5 odp does some of this already.. But yikes, this needs some pretty careful testing in all these situations. > > I think the HMM mirror API really needs to deal with this for the > > driver somehow. > > Yes the HMM does deal with this for you, you do not have to worry about > it. Sorry if that was not clear. I just wanted to stress that vma that > are mmap of a file do not behave like other vma hence when you create > the UMEM you can check for those if you feel the need. What properties do we get from HMM mirror? Will it tell us when to create more umems to cover VMA seams or will it just cause undesired no-mapped failures in some cases? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 05:30:27PM -0500, Jerome Glisse wrote: > > What is the problem in the HMM mirror that it needs this restriction? > > No restriction at all here. I think i just wasn't understood. Are you are talking about from the exporting side - where the thing creating the VMA can really only put one distinct object into it? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/panel: Remove duplicate header
On Wed, Dec 26, 2018 at 3:09 PM Laurent Pinchart
wrote:
>
> Hi Brajeswar,
>
> Thank you for the patch.
>
> On Monday, 24 December 2018 16:32:18 EET Brajeswar Ghosh wrote:
> > Remove drm/drm_panel.h which is included more than once
> >
> > Signed-off-by: Brajeswar Ghosh
> > ---
> > drivers/gpu/drm/bridge/panel.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> > index 7cbaba213ef6..402b318eeeb2 100644
> > --- a/drivers/gpu/drm/bridge/panel.c
> > +++ b/drivers/gpu/drm/bridge/panel.c
> > @@ -15,7 +15,6 @@
> > #include
> > #include
> > #include
> > -#include
>
> While at it, how about sorting headers alphabetically to make sure this won't
> happen again ?
>
> With that change,
>
> Reviewed-by: Laurent Pinchart
If no further comment, can we get this patch in queue for 5.1 ?
>
> > struct panel_bridge {
> > struct drm_bridge bridge;
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls
Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not
paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves
the DSS clocks enabled when the display is blanked wasting about extra
5mW of power while idle.
Let's fix this by setting a dsi->disconnect_lanes flag and making
the current dsi_pll_uninit() into dsi_pll_disable(). This way we can
just call dss_pll_disable() from dsi_display_uninit_dsi() and the
code becomes a bit easier to follow.
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -339,6 +339,7 @@ struct dsi_data {
int irq;
bool is_enabled;
+ unsigned int disconnect_lanes:1;
struct clk *dss_clk;
struct regmap *syscon;
@@ -1382,10 +1383,12 @@ static int dsi_pll_enable(struct dss_pll *pll)
return r;
}
-static void dsi_pll_uninit(struct dsi_data *dsi, bool disconnect_lanes)
+static void dsi_pll_disable(struct dss_pll *pll)
{
+ struct dsi_data *dsi = container_of(pll, struct dsi_data, pll);
+
dsi_pll_power(dsi, DSI_PLL_POWER_OFF);
- if (disconnect_lanes) {
+ if (dsi->disconnect_lanes) {
WARN_ON(!dsi->vdds_dsi_enabled);
regulator_disable(dsi->vdds_dsi_reg);
dsi->vdds_dsi_enabled = false;
@@ -1397,13 +1400,6 @@ static void dsi_pll_uninit(struct dsi_data *dsi, bool
disconnect_lanes)
DSSDBG("PLL uninit done\n");
}
-static void dsi_pll_disable(struct dss_pll *pll)
-{
- struct dsi_data *dsi = container_of(pll, struct dsi_data, pll);
-
- dsi_pll_uninit(dsi, true);
-}
-
static int dsi_dump_dsi_clocks(struct seq_file *s, void *p)
{
struct dsi_data *dsi = p;
@@ -4158,7 +4154,9 @@ static void dsi_display_uninit_dsi(struct dsi_data *dsi,
bool disconnect_lanes,
dss_select_dsi_clk_source(dsi->dss, dsi->module_id, DSS_CLK_SRC_FCK);
dsi_cio_uninit(dsi);
- dsi_pll_uninit(dsi, disconnect_lanes);
+
+ dsi->disconnect_lanes = disconnect_lanes;
+ dss_pll_disable(&dsi->pll);
}
static int dsi_display_enable(struct omap_dss_device *dssdev)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On 2019-01-30 12:19 p.m., Jason Gunthorpe wrote: > On Wed, Jan 30, 2019 at 11:13:11AM -0700, Logan Gunthorpe wrote: >> >> >> On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote: >>> I don't see why a special case with a VMA is really that different. >> >> Well one *really* big difference is the VMA changes necessarily expose >> specialized new functionality to userspace which has to be supported >> forever and may be difficult to change. > > The only user change here is that more things will succeed when > creating RDMA MRs (and vice versa to GPU). I don't think this > restricts the kernel implementation at all, unless we intend to > remove P2P entirely.. Well for MRs I'd expect you are using struct pages to track the memory some how VMAs that aren't backed by pages and use this special interface must therefore be creating new special interfaces that can call p2p_[un]map... I'd much rather see special cases around struct page so we can find ways to generalize it in the future than create special cases tied to random userspace interfaces. Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 0/9] Use vm_insert_range and vm_insert_range_buggy
Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating new functions and use it across the drivers. vm_insert_range() is the API which could be used to mapped kernel memory/pages in drivers which has considered vm_pgoff vm_insert_range_buggy() is the API which could be used to map range of kernel memory/pages in drivers which has not considered vm_pgoff. vm_pgoff is passed default as 0 for those drivers. We _could_ then at a later "fix" these drivers which are using vm_insert_range_buggy() to behave according to the normal vm_pgoff offsetting simply by removing the _buggy suffix on the function name and if that causes regressions, it gives us an easy way to revert. v1 -> v2: Few Reviewed-by. Updated the change log in [8/9] In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer, not as a in-buffer offset by design and it always want to mmap a whole buffer from its beginning. Added additional changes after discussing with Marek and vm_insert_range could be used instead of vm_insert_range_buggy. Souptick Joarder (9): mm: Introduce new vm_insert_range and vm_insert_range_buggy API arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range drivers/firewire/core-iso.c: Convert to use vm_insert_range_buggy drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range iommu/dma-iommu.c: Convert to use vm_insert_range videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range xen/gntdev.c: Convert to use vm_insert_range xen/privcmd-buf.c: Convert to use vm_insert_range_buggy arch/arm/mm/dma-mapping.c | 22 ++ drivers/firewire/core-iso.c| 15 +--- drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 17 + drivers/gpu/drm/xen/xen_drm_front_gem.c| 18 ++--- drivers/iommu/dma-iommu.c | 12 +--- drivers/media/common/videobuf2/videobuf2-core.c| 7 ++ .../media/common/videobuf2/videobuf2-dma-contig.c | 6 -- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++ drivers/xen/gntdev.c | 16 ++--- drivers/xen/privcmd-buf.c | 8 +-- include/linux/mm.h | 4 ++ mm/memory.c| 81 ++ mm/nommu.c | 14 13 files changed, 136 insertions(+), 106 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Wed, Jan 30, 2019 at 02:22:34PM -0500, Jerome Glisse wrote: > For GPU it would not work, GPU might want to use main memory (because > it is running out of BAR space) it is a lot easier if the p2p_map > callback calls the right dma map function (for page or io) rather than > having to define some format that would pass down the information. This is already sort of built into the sgl, you are supposed to use is_pci_p2pdma_page() and pci_p2pdma_map_sg() and somehow it is supposed to work out - but I think this is also fairly incomplete. ie the current APIs seem to assume the SGL is homogeneous :( > > Worry about optimizing away the struct page overhead later? > > Struct page do not fit well for GPU as the BAR address can be reprogram > to point to any page inside the device memory (think 256M BAR versus > 16GB device memory). The struct page only points to the BAR - it is not related to the actual GPU memory in any way. The struct page is just an alternative way to specify the physical address of the BAR page. I think this boils down to one call to setup the entire BAR, like nvme does, and then using the struct page in the p2p_map SGL?? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 01/40] components: multiple components for a device
On Thu, Jan 31, 2019 at 09:12:45AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 31, 2019 at 09:00:30AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 31, 2019 at 08:50:20AM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> > > > +void component_match_add_typed(struct device *master,
> > > > + struct component_match **matchptr,
> > > > + int (*compare_typed)(struct device *, int, void *), void
> > > > *compare_data)
> > > > +{
> > > > + __component_match_add(master, matchptr, NULL, NULL,
> > > > compare_typed,
> > > > + compare_data);
> > > > +}
> > > > +EXPORT_SYMBOL(component_match_add_typed);
> > >
> > > No comment at all as to what this new global function does?
> > >
> > > > +int component_add_typed(struct device *dev, const struct component_ops
> > > > *ops,
> > > > + int subcomponent)
> > > > +{
> > > > + if (WARN_ON(subcomponent == 0))
> > > > + return -EINVAL;
> > > > +
> > > > + return __component_add(dev, ops, subcomponent);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(component_add_typed);
> > >
> > > Same here, no comments at all?
> > >
> > > Please at the very least, document new things that you add, I thought I
> > > asked for this the last time this patch was posted :(
> >
> > I replied and asked whether you insist on the docs for this or not, since
> > nothing has docs (and documenting these two alone is not going to explain
> > anything frankly). It's also defacto the drm component thing, other
> > subsystems didn't push their own solution into the core ...
>
> I thought I responded that I would love to have something for the new
> stuff at the very least.
Didn't see anything fly by ...
> And it's not nice to create new global functions without a single line
> of comment for them as to what they are supposed to be used for. So I'm
> going to insist on that happening here at the very least.
I'll type the entire thing then. I get the "new stuff at least" drill to
fill gaps (use it plenty myself), but just doesn't make sense here at all
...
Cheers, Daniel
--
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 v10 37/40] drm/i915: Commit CP without modeset
On Thu, Jan 31, 2019 at 12:29:53PM +0530, Ramalingam C wrote:
> Commits the content protection change of a connector,
> without crtc modeset. This improves the user experience.
>
> Originally proposed by Sean Paul at v3 of HDCP1.4 framework
> https://patchwork.freedesktop.org/patch/191759/. For some
> reason this was dropped, but needed for the proper functionality
> of HDCP encryption.
>
> Signed-off-by: Ramalingam C
> Suggested-by: Sean Paul
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 7 ---
> drivers/gpu/drm/i915/intel_display.c | 10 ++
> drivers/gpu/drm/i915/intel_drv.h | 5 +
> drivers/gpu/drm/i915/intel_hdcp.c| 32
> 4 files changed, 43 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ca705546a0ab..9cb03c1b0abc 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3495,11 +3495,6 @@ static void intel_enable_ddi(struct intel_encoder
> *encoder,
> intel_enable_ddi_hdmi(encoder, crtc_state, conn_state);
> else
> intel_enable_ddi_dp(encoder, crtc_state, conn_state);
> -
> - /* Enable hdcp if it's desired */
> - if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(to_intel_connector(conn_state->connector));
> }
>
> static void intel_disable_ddi_dp(struct intel_encoder *encoder,
> @@ -3542,8 +3537,6 @@ static void intel_disable_ddi(struct intel_encoder
> *encoder,
> const struct intel_crtc_state *old_crtc_state,
> const struct drm_connector_state *old_conn_state)
> {
> - intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
> -
> if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
> intel_disable_ddi_hdmi(encoder, old_crtc_state, old_conn_state);
> else
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a025efb1d7c6..9b964dabb57c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13034,6 +13034,8 @@ static void intel_atomic_commit_tail(struct
> drm_atomic_state *state)
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> struct intel_crtc_state *new_intel_crtc_state, *old_intel_crtc_state;
> + struct drm_connector_state *old_conn_state, *new_conn_state;
> + struct drm_connector *connector;
> struct drm_crtc *crtc;
> struct intel_crtc *intel_crtc;
> u64 put_domains[I915_MAX_PIPES] = {};
> @@ -13128,9 +13130,17 @@ static void intel_atomic_commit_tail(struct
> drm_atomic_state *state)
> }
> }
>
> + for_each_oldnew_connector_in_state(state, connector, old_conn_state,
> +new_conn_state, i)
> + intel_hdcp_atomic_pre_commit(connector, old_conn_state,
> + new_conn_state);
> +
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> dev_priv->display.update_crtcs(state);
>
> + for_each_new_connector_in_state(state, connector, new_conn_state, i)
> + intel_hdcp_atomic_commit(connector, new_conn_state);
So this is kinda awkward, having these one-use callbacks for hdcp.
"changing connector state without a full modeset" is a generic problem,
and Hans has added a new intel_encoder->update_pipe callback for this
stuff. The way to use it:
- Keep the enable/disable calls where they currently are, we still need
them for full modesets.
- Add a new update_pipe callback, which is for the !needs_modeset case for
both hdmi and dp, and adjust hdcp state there.
- Adjust compute_config to only flag update_pipe, not a full modeset in
compute_config (in atomic_check).
This should fit a lot neater into the overall infrastructure for fastset
and all that stuff.
For validation the problem is that we're now adding two paths, so need to
make sure the content protection test copes. We need to make sure that
we're enabling content protection both with a modeset and without,
probably the simplest trick to get there is to add a new subtest which
does a dpms off->on once content protection is on, and checks that it
stays on.
Also we need CI results without this patch so I can start merging. Rough
merge plan:
- needs ack to merge component.c through drm-intel
- merge all the i915 patches
- topic branch for mei, shared with mei subsystem
- make sure that CI has mei enabled and that tests aren't on fire
- merge this one here
Cheers, Daniel
> +
> /* FIXME: We should call drm_atomic_helper_commit_hw_done() here
>* already, but still need the state for the delayed optimization. To
>* fix this:
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
[Bug 107990] Got Dying Light working in Arch by changing Mesa's compile steps, how to get it working Out Of the Box?
https://bugs.freedesktop.org/show_bug.cgi?id=107990 --- Comment #9 from Timothy Arceri --- Thanks for investigating. The brute force fix is to finish implementing EXT_direct_state_access. I have a partial implementation here which is able to run Doom and Wolfenstein with this extension enabled[1]. Implementing the feature in Mesa shouldn't be all that difficult. The hardest part will be writing all the piglit tests before this will be accepted in Mesa. Currently I don't see myself working on this anytime in the near future, so anyone is free to try pick this up. [1] https://gitlab.freedesktop.org/tarceri/mesa/commits/EXT_direct_state_access -- 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 v10 36/40] misc/mei/hdcp: Component framework for I915 Interface
On Thu, Jan 31, 2019 at 12:29:52PM +0530, Ramalingam C wrote:
> Mei hdcp driver is designed as component slave for the I915 component
> master.
>
> v2: Rebased.
> v3:
> Notifier chain is adopted for cldev state update [Tomas]
> v4:
> Made static dummy functions as inline in mei_hdcp.h
> API for polling client device status
> IS_ENABLED used in header, for config status for mei_hdcp.
> v5:
> Replacing the notifier with component framework. [Daniel]
> v6:
> Rebased on the I915 comp master redesign.
> v7:
> mei_hdcp_component_registered is made static [Uma]
> Need for global static variable mei_cldev is removed.
> v8:
> master comp is added to be matched with i915 subcomponent [daniel]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
Pretty sure v8 has nothing to do with what Uma originally reviewed. If you
keep an r-b with substantial changes pls add an indicator about which old
version this was for. But for completely rewritten patches like this one
here it's best to outright drop it.
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 90
> +++-
> drivers/misc/mei/hdcp/mei_hdcp.h | 5 +++
> 2 files changed, 93 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index edfc70fb0617..be2ce12ca460 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -692,8 +693,7 @@ mei_close_hdcp_session(struct device *dev, struct
> hdcp_port_data *data)
> return 0;
> }
>
> -static __attribute__((unused))
> -struct i915_hdcp_component_ops mei_hdcp_ops = {
> +static struct i915_hdcp_component_ops mei_hdcp_ops = {
> .owner = THIS_MODULE,
> .initiate_hdcp2_session = mei_initiate_hdcp2_session,
> .verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
> @@ -708,20 +708,106 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .close_hdcp_session = mei_close_hdcp_session,
> };
>
> +static int mei_component_master_bind(struct device *dev)
> +{
> + struct mei_cl_device *cldev = to_mei_cl_device(dev);
> + struct mei_hdcp_drv_data *drv_data = mei_cldev_get_drvdata(cldev);
> + int ret;
> +
> + dev_info(dev, "%s\n", __func__);
> + drv_data->comp_master->ops = &mei_hdcp_ops;
> + drv_data->comp_master->mei_dev = dev;
> + ret = component_bind_all(dev, drv_data->comp_master);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static void mei_component_master_unbind(struct device *dev)
> +{
> + struct mei_cl_device *cldev = to_mei_cl_device(dev);
> + struct mei_hdcp_drv_data *drv_data = mei_cldev_get_drvdata(cldev);
> +
> + dev_info(dev, "%s\n", __func__);
> + component_unbind_all(dev, drv_data->comp_master);
> +}
> +
> +static const struct component_master_ops mei_component_master_ops = {
> + .bind = mei_component_master_bind,
> + .unbind = mei_component_master_unbind,
> +};
> +
> +static int mei_hdcp_component_match(struct device *dev, int subcomponent,
> + void *data)
> +{
> + return !strcmp(dev->driver->name, "i915") &&
> +subcomponent == I915_COMPONENT_HDCP;
> +}
> +
> static int mei_hdcp_probe(struct mei_cl_device *cldev,
> const struct mei_cl_device_id *id)
> {
> + struct mei_hdcp_drv_data *drv_data;
> int ret;
>
> ret = mei_cldev_enable(cldev);
> if (ret < 0)
> dev_err(&cldev->dev, "mei_cldev_enable Failed. %d\n", ret);
>
> + drv_data = kzalloc(sizeof(*drv_data), GFP_KERNEL);
> + if (!drv_data) {
> + ret = -ENOMEM;
> + goto drv_data_exit;
> + }
> +
> + drv_data->comp_master = kzalloc(sizeof(*drv_data->comp_master),
> + GFP_KERNEL);
> + if (!drv_data->comp_master) {
> + ret = -ENOMEM;
> + goto comp_master_exit;
> + }
> +
> + drv_data->master_match = NULL;
> + component_match_add_typed(&cldev->dev, &drv_data->master_match,
> + mei_hdcp_component_match,
> + drv_data->comp_master);
> + if (IS_ERR_OR_NULL(drv_data->master_match)) {
> + ret = -ENOMEM;
> + goto match_add_exit;
> + }
> +
> + mei_cldev_set_drvdata(cldev, drv_data);
> + ret = component_master_add_with_match(&cldev->dev,
> + &mei_component_master_ops,
> + drv_data->master_match);
> + if (ret < 0) {
> + dev_err(&cldev->dev, "Master comp add failed %d\n", ret);
> + mei_cldev_set_drvdata(cldev, NULL);
> + goto match_add_exit;
> + }
> +
> + return 0;
> +
> +match_add_exit:
> + kfree(drv_data->comp_master);
> +c
Re: [PATCH v10 06/40] drm/i915: MEI interface definition
On Thu, Jan 31, 2019 at 12:29:22PM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> v2:
> Adjust to the new interface changes. [Tomas]
> Added further debug logs for the failures at MEI i/f.
> port in hdcp_port data is equipped to handle -ve values.
> v3:
> mei comp is matched for global i915 comp master. [Daniel]
> In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
> mei wrappers are adjusted as per the i/f change [Daniel]
> v4:
> port initialization is done only at hdcp2_init only [Danvet]
> v5:
> I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
When you make substantial changes to a patch (like here) and decide to
keep the r-b, then please indicate that it was for an earlier version. I
most definitely didn't review this one that re-adds all the locking :-)
What's missing here is the component_del. Not exactly sure why this
doesn't blow up. Luckily we don't need a component_del_typed because
component_del already takes the (dev, ops) pair, and that's unique.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 7 +
> drivers/gpu/drm/i915/intel_drv.h | 5 +
> drivers/gpu/drm/i915/intel_hdcp.c | 378
> +-
> include/drm/i915_component.h | 3 +
> 5 files changed, 393 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a7aaa1ac4c99..75aff907ba69 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -904,6 +904,7 @@ static int i915_driver_init_early(struct drm_i915_private
> *dev_priv)
> mutex_init(&dev_priv->av_mutex);
> mutex_init(&dev_priv->wm.wm_mutex);
> mutex_init(&dev_priv->pps_mutex);
> + mutex_init(&dev_priv->hdcp_comp_mutex);
>
> i915_memcpy_init_early(dev_priv);
> intel_runtime_pm_init_early(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 22da9df1f0a7..d9a0771af4d1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -55,6 +55,7 @@
> #include
> #include
> #include
> +#include
>
> #include "i915_fixed.h"
> #include "i915_params.h"
> @@ -2043,6 +2044,12 @@ struct drm_i915_private {
>
> struct i915_pmu pmu;
>
> + struct i915_hdcp_comp_master *hdcp_master;
> + bool hdcp_comp_added;
> +
> + /* Mutex to protect the above hdcp component related values. */
> + struct mutex hdcp_comp_mutex;
> +
> /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0ac870feb5e9..63e009286d5f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> struct drm_printer;
> @@ -385,6 +386,9 @@ struct intel_hdcp_shim {
> /* Detects panel's hdcp capability. This is optional for HDMI. */
> int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
> bool *hdcp_capable);
> +
> + /* HDCP adaptation(DP/HDMI) required on the port */
> + enum hdcp_wired_protocol protocol;
> };
>
> struct intel_hdcp {
> @@ -405,6 +409,7 @@ struct intel_hdcp {
>* content can flow only through a link protected by HDCP2.2.
>*/
> u8 content_type;
> + struct hdcp_port_data port_data;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 1a85dc46692d..e0bb5f32ba90 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -7,8 +7,10 @@
> */
>
> #include
> +#include
> #include
> #include
> +#include
>
> #include "intel_drv.h"
> #include "i915_reg.h"
> @@ -832,6 +834,348 @@ bool is_hdcp_supported(struct drm_i915_private
> *dev_priv, enum port port)
> return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
> }
>
> +static __attribute__((unused)) int
> +hdcp2_prepare_ake_init(struct intel_connector *connector,
> +struct hdcp2_ake_init *ake_data)
> +{
> + struct hdcp_port_data *data = &connector->hdcp.port_data;
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct i915_hdcp_comp_master *comp;
> + int ret;
> +
> + mutex_lock(&dev_priv->hdcp_comp_mutex);
> + comp = dev_priv->hdcp_master;
> +
> + if (!comp || !comp->ops) {
> + mutex_unlock(&dev_priv->hdcp_comp_mutex);
> + return -EINVAL;
> + }
> +
> + ret = comp->ops->initiate_hdcp2_session(comp->mei_dev, data, ake_data);
> + if (ret)
> +
Re: [PATCH v10 01/40] components: multiple components for a device
On Thu, Jan 31, 2019 at 09:00:30AM +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2019 at 08:50:20AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> > > +void component_match_add_typed(struct device *master,
> > > + struct component_match **matchptr,
> > > + int (*compare_typed)(struct device *, int, void *), void *compare_data)
> > > +{
> > > + __component_match_add(master, matchptr, NULL, NULL, compare_typed,
> > > + compare_data);
> > > +}
> > > +EXPORT_SYMBOL(component_match_add_typed);
> >
> > No comment at all as to what this new global function does?
> >
> > > +int component_add_typed(struct device *dev, const struct component_ops
> > > *ops,
> > > + int subcomponent)
> > > +{
> > > + if (WARN_ON(subcomponent == 0))
> > > + return -EINVAL;
> > > +
> > > + return __component_add(dev, ops, subcomponent);
> > > +}
> > > +EXPORT_SYMBOL_GPL(component_add_typed);
> >
> > Same here, no comments at all?
> >
> > Please at the very least, document new things that you add, I thought I
> > asked for this the last time this patch was posted :(
>
> I replied and asked whether you insist on the docs for this or not, since
> nothing has docs (and documenting these two alone is not going to explain
> anything frankly). It's also defacto the drm component thing, other
> subsystems didn't push their own solution into the core ...
I thought I responded that I would love to have something for the new
stuff at the very least.
And it's not nice to create new global functions without a single line
of comment for them as to what they are supposed to be used for. So I'm
going to insist on that happening here at the very least.
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 18/40] drm/i915: CP_IRQ handling for DP HDCP2.2 msgs
On Thu, Jan 31, 2019 at 12:29:34PM +0530, Ramalingam C wrote:
> Implements the
> Waitqueue is created to wait for CP_IRQ
> Signaling the CP_IRQ arrival through atomic variable.
> For applicable DP HDCP2.2 msgs read wait for CP_IRQ.
>
> As per HDCP2.2 spec "HDCP Transmitters must process CP_IRQ interrupts
> when they are received from HDCP Receivers"
>
> Without CP_IRQ processing, DP HDCP2.2 H_Prime msg was getting corrupted
> while reading it based on corresponding status bit. This creates the
> random failures in reading the DP HDCP2.2 msgs.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_dp.c | 33 +
> drivers/gpu/drm/i915/intel_drv.h | 7 +++
> drivers/gpu/drm/i915/intel_hdcp.c | 6 ++
> 3 files changed, 38 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b13c41220ce0..4e36df266ab3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5619,6 +5619,24 @@ void intel_dp_encoder_suspend(struct intel_encoder
> *intel_encoder)
> edp_panel_vdd_off_sync(intel_dp);
> }
>
> +static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
> + int timeout)
> +{
> + long ret;
> +
> + /* Reinit */
> + atomic_set(&hdcp->cp_irq_recved, 0);
This is still fundamentally racy. The way it's usually done is through a
counter, i.e. the wait function samples the atomic counter, and the wait
condition is then that the counter has increased.
The interrupt handler on the other hand just does an atomic_inc. That way
you never have the problem that the interrupt handler has set 1 before we
clear it to 0 here.
That still leaves the race that it has incremented _before_ we sampled in
this function here. There the counter sampling needs to be moved out
(probably before we send out the message to the sink), and passed into
this function as a parameter.
Finally there's the wrapping problem, so best to just have a condition
like sampled_counter != current_counter.
I assume this won't matter for correctness if we miss the interrupt, we
just time out and at that point the next message should be available. But
it's less confusing to have more correct code.
Cheers, Daniel
> +
> +#define C (atomic_read(&hdcp->cp_irq_recved) > 0)
> + ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
> +msecs_to_jiffies(timeout));
> +
> + if (ret > 0)
> + atomic_set(&hdcp->cp_irq_recved, 0);
> + else if (!ret)
> + DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
> +}
> +
> static
> int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> u8 *an)
> @@ -5963,14 +5981,13 @@ intel_dp_hdcp2_wait_for_msg(struct intel_digital_port
> *intel_dig_port,
> mdelay(timeout);
> ret = 0;
> } else {
> - /* TODO: In case if you need to wait on CP_IRQ, do it here */
> - ret = __wait_for(ret =
> - hdcp2_detect_msg_availability(intel_dig_port,
> -msg_id,
> -&msg_ready),
> - !ret && msg_ready, timeout * 1000,
> - 1000, 5 * 1000);
> -
> + /*
> + * Ignoring the return of the intel_dp_hdcp_wait_for_cp_irq,
> + * Just to detect the msg availability before failing it.
> + */
> + intel_dp_hdcp_wait_for_cp_irq(hdcp, timeout);
> + ret = hdcp2_detect_msg_availability(intel_dig_port,
> + msg_id, &msg_ready);
> if (!msg_ready)
> ret = -ETIMEDOUT;
> }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 747fe7361287..1901d12bacc4 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -464,6 +464,13 @@ struct intel_hdcp {
>* over re-Auth has to be triggered.
>*/
> u32 seq_num_m;
> +
> + /*
> + * Work queue to signal the CP_IRQ. Used for the waiters to read the
> + * available information from HDCP DP sink.
> + */
> + wait_queue_head_t cp_irq_queue;
> + atomic_t cp_irq_recved;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 7ff29fb0aa2f..f38feeadb363 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -1805,6 +1805,9 @@ int intel_hdcp_init(struct intel_connector *connector,
> if (hdcp2_supported)
> intel_hdcp2_init(connector);
>
> + atomic_set(&hdcp->cp_irq_recved, 0);
> + in
Re: [PATCH v10 15/40] drm: removing the DP Errata msg and its msg id
On Thu, Jan 31, 2019 at 12:29:31PM +0530, Ramalingam C wrote:
> Since DP ERRATA message is not defined at spec, those structure
> definition is removed from drm_hdcp.h
>
> Signed-off-by: Ramalingam C
> Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_hdcp.h | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index d4e98b11b4aa..f243408ecf26 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -69,7 +69,6 @@
> #define HDCP_2_2_REP_SEND_ACK15
> #define HDCP_2_2_REP_STREAM_MANAGE 16
> #define HDCP_2_2_REP_STREAM_READY17
> -#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
>
> #define HDCP_2_2_RTX_LEN 8
> #define HDCP_2_2_RRX_LEN 8
> @@ -220,11 +219,6 @@ struct hdcp2_rep_stream_ready {
> u8 m_prime[HDCP_2_2_MPRIME_LEN];
> } __packed;
>
> -struct hdcp2_dp_errata_stream_type {
> - u8 msg_id;
> - u8 stream_type;
> -} __packed;
> -
> /* HDCP2.2 TIMEOUTs in mSec */
> #define HDCP_2_2_CERT_TIMEOUT_MS 100
> #define HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS 1000
> --
> 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 v10 01/40] components: multiple components for a device
On Thu, Jan 31, 2019 at 08:50:20AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> > +void component_match_add_typed(struct device *master,
> > + struct component_match **matchptr,
> > + int (*compare_typed)(struct device *, int, void *), void *compare_data)
> > +{
> > + __component_match_add(master, matchptr, NULL, NULL, compare_typed,
> > + compare_data);
> > +}
> > +EXPORT_SYMBOL(component_match_add_typed);
>
> No comment at all as to what this new global function does?
>
> > +int component_add_typed(struct device *dev, const struct component_ops
> > *ops,
> > + int subcomponent)
> > +{
> > + if (WARN_ON(subcomponent == 0))
> > + return -EINVAL;
> > +
> > + return __component_add(dev, ops, subcomponent);
> > +}
> > +EXPORT_SYMBOL_GPL(component_add_typed);
>
> Same here, no comments at all?
>
> Please at the very least, document new things that you add, I thought I
> asked for this the last time this patch was posted :(
I replied and asked whether you insist on the docs for this or not, since
nothing has docs (and documenting these two alone is not going to explain
anything frankly). It's also defacto the drm component thing, other
subsystems didn't push their own solution into the core ...
There's also the bikeshed question for what exactly we should call these,
I'm not happy with the _typed suffix. Lockdep uses _class for this, but
kinda doesn't make, _subcomponent is a bit redundant and _sub also doesn't
convey much meaning.
Russell, any better ideas?
Thanks, Daniel
--
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
