Re: [PULL] drm-misc-next
On Tue, Mar 6, 2018 at 8:20 PM, Sean Paul wrote: > On Tue, Mar 06, 2018 at 09:07:52PM +0200, Ville Syrjälä wrote: >> On Tue, Mar 06, 2018 at 02:01:21PM -0500, Sean Paul wrote: >> > On Tue, Mar 06, 2018 at 07:42:53AM +0100, Daniel Vetter wrote: >> > > On Tue, Mar 6, 2018 at 12:20 AM, Sean Paul wrote: >> > > > On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter wrote: >> > > >> On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote: >> > > >>> On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul >> > > >>> wrote: >> > > >>> > >> > > >>> > Hi Dave, >> > > >>> > Here's this weeks pull, relatively small when you pull out the >> > > >>> > trivial fixes. >> > > >>> > >> > > >>> > drm-misc-next-2018-02-28: >> > > >>> > drm-misc-next for 4.17: >> > > >>> > >> > > >>> > UAPI Changes: >> > > >>> > Fix drm_color_ctm matrix docs to match usage and change the type >> > > >>> > to >> > > >>> > __u64 make it obvious (Ville) >> > > >>> >> > > >>> Hi Dave, >> > > >>> Could you please hold off on pulling this? I'd like to sort out this >> > > >>> change a bit more. We're already using the __s64 in chrome, and not >> > > >>> explicitly sign-magnitude. I think it would be prudent to hash this >> > > >>> out a little more. >> > > >>> >> > > >>> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?l=161 >> > > >> >> > > >> That code seems to be doing the exact same fun s.u63 math. This all >> > > >> looks >> > > >> consistent to me. >> > > > >> > > > Hmm, yeah, I skimmed too quickly last week. >> > > > >> > > >> >> > > >> Now in hindsight ofc we've screwed up the uapi, but well can't fix >> > > >> that >> > > >> now again ... >> > > > >> > > > Yeah, I'm not convinced we should be changing the type. It's great to >> > > > clarify the documentation to let userspace know it's sign-magnitude, >> > > > but changing the type in-flight with users seems wrong. >> > > >> > > But everyone must do unsigned bit ops to get this right, the s64 is >> > > completely meaningless at best, and very likely will confuse someone. >> > >> > It's definitely a good change to clarify the usage of the field, I'm not >> > arguing >> > against that. >> > >> > > What do we benefit by not changing it? >> > >> > In the kernel, nothing. However changing uapi structs out from under >> > userspace >> > requires userspace updates. In order for that to happen, they need to be >> > aware of the change and coordinate its rollout kernel/libdrm/compositor. At >> > least in CrOS, Chrome people don't follow kernel changes, so they'll >> > discover >> > this with a compiler warning (hopefully) and have to backtrack what >> > happened. >> > >> > Given that everybody seems to be using this struct correctly, what do we >> > benefit >> > from changing it? Wouldn't a comment be sufficient? Perhaps a union of >> > __s64/__u64 would be less disruptive. >> >> Umm. What exactly broke? The code behind your link even casts the final >> value to unsigned. So now the struct actually matches the code. > > We haven't pulled the change back, so nothing has changed in cros. You're > right > that the code already does the right thing. So perhaps I'm just tilting at > windmills here, but this type of churn seemed unsettling to me. Yeah I'm not seeing any issue you want to prevent by rolling out this header change to userspace first. There's two cases: - Observed uapi or uabi actually changes. "Observed" here means any of the existing open source users would change behaviour in a way that could be noticed by users, testsuites. If that's the case we can't do it, a coordinated roll-out wont help. Extending a struct size isn't such a thing, assuming all our padding code works. Changing the layout is, just as an example. - Observed uapi behaviour doesn't change. If it doesn't change it also doesn't matter which version userspace is using for compilation. And there's no need at all for a coordinated roll-out. s64 vs. u64 only affects sign extension and wrap-around behavior (it's undefined on signed ints). Because our only existing userspace does none of that (in the uapi struct itself), there's no observable behaviour difference possible, and the change is safe. Agree with that? If so, please tell Dave to unblock this pull request. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/pl111: Enable device-specific assigned memory
The Versatile Express has 8 MB of dedicated video RAM (VRAM)
on the motherboard, which is what we should be using for the
PL111 if available. On this platform, the memory backplane
is constructed so that only this memory will work properly
with the CLCD on the motherboard, using any other memory
region just gives random snow on the display.
The CA9 Versatile Express also has a PL111 instance on its
core tile. This is OK, it has been tested with the motherboard
VRAM and that works just as fine as regular CMA memory.
The memory is assigned to the device using the memory-region
device tree property and a "shared-dma-pool" reserved
memory pool like this:
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
vram: vram@4800 {
compatible = "shared-dma-pool";
reg = <0x4800 0x0080>;
no-map;
};
};
clcd@1f000 {
compatible = "arm,pl111", "arm,primecell";
(...)
memory-region = <&vram>;
}·;
Cc: Liviu Dudau
Cc: Mali DP Maintainers
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/pl111_drv.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index b469aa317d9d..e301f2a719a3 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -60,6 +60,7 @@
#include
#include
#include
+#include
#include
#include
@@ -262,6 +263,10 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
drm->dev_private = priv;
priv->variant = variant;
+ ret = of_reserved_mem_device_init(dev);
+ if (!ret)
+ dev_info(dev, "using device-specific reserved memory\n");
+
if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
&priv->memory_bw)) {
dev_info(dev, "no max memory bandwidth specified, assume
unlimited\n");
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] omapdrm changes for v4.17
Hi Dave, Please pull omapdrm changes for v4.17. Tomi The following changes since commit f073d78eeb8efd85718e611c15f9a78647751dea: Merge tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-03-01 14:07:22 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/omapdrm-4.17 for you to fetch changes up to c39bbb903ce337a3f6a7fe0ac8d30e0876699fc2: drm: omapdrm: displays: panel-dsi-cm: Fix field access before set (2018-03-02 15:11:07 +0200) omapdrm patches for v4.17 * Fix sparse warnings from omapdrm * HPD support for DVI connector * Big cleanup to remove static variables Benoit Parrot (2): drm/omap: dispc: disp_wb_setup to check return code drm/omap: Add pclk setting case when channel is DSS_WB Jyri Sarha (1): drm/omap: Allow HDMI audio setup even if we do not have video configured Laurent Pinchart (46): drm: omapdrm: Use kernel integer types drm: omapdrm: Use unsigned int type drm: omapdrm: connector-analog-tv: Remove tvc_of_match forward declaration drm: omapdrm: displays: Remove OF node check in connector drivers drm: omapdrm: displays: Remove OF node check in encoder drivers drm: omapdrm: displays: Remove OF node check in panel drivers drm: omapdrm: displays: Get connector source at connect time drm: omapdrm: displays: Get panel source at connect time drm: omapdrm: displays: Get encoder source at connect time drm: omapdrm: dss: Make omapdss_default_get_timings static drm: omapdrm: dss: Don't export functions internal to omapdss-base drm: omapdrm: dss: Move initialization code from component bind to probe drm: omapdrm: dss: Remove dss_get_hdmi_venc_clk_source() function drm: omapdrm: dss: Remove unused functions prototypes drm: omapdrm: dsi: Make wait_for_bit_change() return a status drm: omapdrm: Split init and cleanup from probe and remove functions drm: omapdrm: dss: Expose DSS data in a dss_device structure drm: omapdrm: dss: Pass DSS private structure to runtime PM functions drm: omapdrm: dss: Pass PLL pointer to dss_ctrl_pll_enable() drm: omapdrm: dss: Pass DSS pointer to dss_sdi_*() functions drm: omapdrm: dss: Pass DSS pointer to dss_ops operations drm: omapdrm: dss: Pass DSS pointer to dss_get_*_clk_source() drm: omapdrm: dss: Pass DSS pointer to dss clock functions drm: omapdrm: dss: Pass DSS pointer to remaining dss functions drm: omapdrm: dss: Allocate the DSS private data structure dynamically drm: omapdrm: dss: Support passing private data to debugfs show handlers drm: omapdrm: dss: Store the registered plls array in struct dss_device drm: omapdrm: dss: Store the debugfs root directory in struct dss_device drm: omapdrm: dss: Don't unnecessarily cast to dev to pdev and back drm: omapdrm: dsi: Pass the dsi_data pointer to internal functions drm: omapdrm: dsi: Combine two commonly used inline functions drm: omapdrm: dsi: Use dev pointer directly in dsi_bind() function drm: omapdrm: dsi: Store the struct device pointer in struct dsi_data drm: omapdrm: dsi: Don't pass channel to dispc init/uninit functions drm: omapdrm: dss: Pass omap_dss_device pointer to dss_mgr_*() functions drm: omapdrm: dss: Pass omap_drm_private pointer to dss_mgr_ops drm: omapdrm: dss: Store DSS device pointer in the omapdrm private data drm: omapdrm: dss: Store dispc ops in dss_device structure drm: omapdrm: dispc: Pass DISPC pointer to dispc_ops operations drm: omapdrm: dispc: Pass DISPC pointer to remaining dispc API functions drm: omapdrm: dispc: Allocate the dispc private data structure dynamically drm: omapdrm: hdmi4: Allocate the omap_hdmi data structure dynamically drm: omapdrm: hdmi5: Allocate the omap_hdmi data structure dynamically drm: omapdrm: sdi: Allocate the sdi private data structure dynamically drm: omapdrm: venc: Allocate the venc private data structure dynamically drm: omapdrm: displays: panel-dsi-cm: Fix field access before set Peter Ujfalusi (1): drm/omap: Init fbdev emulation only when we have displays Tomi Valkeinen (17): drm/omap: reorganize locking in mgr_fld_write drm/omap: acx565akm: use __be32 when reading status drm/omap: fbdev: use 'screen_buffer' field drm/omap: fbdev: avoid double initializer entry drm/omap: fix omap_fbdev_free() when omap_fbdev_create() wasn't called drm/omap: cleanup fbdev init/free drm/omap: add HPD support to connector-dvi dt-bindings: display: add HPD gpio to DVI connector drm/omap: remove leftover enums drm/omap: set WB channel-in in wb_setup() drm/omap:
Re: [PATCH] drm/bridge: sii902x: Retry status read after DDI I2C
On Mon, Mar 5, 2018 at 5:05 PM, Liviu Dudau wrote: >> Cc: Ville Syrjälä >> Cc: Liviu Dudau > > I don't have a suitable configuration to test this, but looks goot to me. > > Reviewed-by: Liviu Dudau Thanks! > BTW, Linus, could it be that your DVI-to-VGA connector doesn't wire > correctly the EDID pin? Very possible. I also suspect signal levels or something like that, possibly no proper pull-up resistor on the line. Or anything similar... it now falls back nicely to default EDID modes though. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: New KFD ioctls: taking the skeletons out of the closet
Am 07.03.2018 um 00:09 schrieb Dave Airlie: On 7 March 2018 at 08:44, Felix Kuehling wrote: Hi all, Christian raised two potential issues in a recent KFD upstreaming code review that are related to the KFD ioctl APIs: 1. behaviour of -ERESTARTSYS 2. transactional nature of KFD ioctl definitions, or lack thereof I appreciate constructive feedback, but I also want to encourage an open-minded rather than a dogmatic approach to API definitions. So let me take all the skeletons out of my closet and get these APIs reviewed in the appropriate forum before we commit to them upstream. See the end of this email for reference. The controversial part at this point is kfd_ioctl_map_memory_to_gpu. If any of the other APIs raise concerns or questions, please ask. Because of the HSA programming model, KFD memory management APIs are synchronous. There is no pipelining. Command submission to GPUs through user mode queues does not involve KFD. This means KFD doesn't know what memory is used by the GPUs and when it's used. That means, when the map_memory_to_gpu ioctl returns to user mode, all memory mapping operations are complete and the memory can be used by the CPUs or GPUs immediately. I've got a few opinions, but first up I still dislike user-mode queues and everything they entail. I still feel they are solving a Windows problem and not a Linux problem, and it would be nice if we had some Linux numbers on what they gain us over a dispatch ioctl, because they sure bring a lot of memory management issues. Well user-mode queues are a problem as long as you don't have recoverable page faults on the GPU. As soon as you got recoverable page faults and push the memory management towards things like HMM I don't see an advantage of using a IOCTL based command submission any more. So I would say that this is a problem which is slowly going away as the hardware improves. That said amdkfd is here. The first question you should ask (which you haven't asked here at all) is what should userspace do with the ioctl result. HSA also uses a shared virtual memory model, so typically memory gets mapped on multiple GPUs and CPUs at the same virtual address. The point of contention seems to be the ability to map memory to multiple GPUs in a single ioctl and the behaviour in failure cases. I'll discuss two main failure cases: 1: Failure after all mappings have been dispatched via SDMA, but a signal interrupts the wait for completion and we return -ERESTARTSYS. Documentation/kernel-hacking/hacking.rst only says "[...] you should be prepared to process the restart, e.g. if you're in the middle of manipulating some data structure." I think we do that by ensuring that memory that's already mapped won't be mapped again. So the restart will become a no-op and just end up waiting for all the previous mappings to complete. -ERESTARTSYS at that late stage points to a badly synchronous API, I'd have said you should have two ioctls, one that returns a fence after starting the processes, and one that waits for the fence separately. That is exactly what I suggested as well, but also exactly what Felix tries to avoid :) The overhead of ioctls isn't your enemy until you've measured it and proven it's a problem. Christian has a stricter requirement, and I'd like to know where that comes from: "An interrupted IOCTL should never have a visible effect." Christian might be taking things a bit further but synchronous gpu access APIs are bad, but I don't think undoing a bunch of work is a good plan either just because you got ERESTARTSYS. If you get ERESTARTSYS can you handle it, if I've fired off 5 SDMAs and wait for them will I fire off 5 more? will I wait for the original SDMAs if I reenter? Well it's not only the waiting for the SDMAs. If I understood it correctly the IOCTL proposed by Felix allows adding multiple mappings of buffer objects on multiple devices with just one IOCTL. Now the problem is without a lot of redesign of the driver this can fail at any place in between those operations. E.g. we could run out of memory or hit a permission restriction or an invalid handle etc.. etc... What would happen is that we end up with a halve complete IOCTL. A possible solution might be that we could maybe add some kind of feedback noting which operations are already complete and then only retrying the one which failed. 2: Failure to map on some but not all GPUs. This comes down to the question, do all ioctl APIs or system calls in general need to be transactional? As a counter example I'd give incomplete read or write system calls that return how much was actually read or written. Our current implementation of map_memory_to_gpu doesn't do this, but it could be modified to return to user mode how many of the mappings, or which mappings specifically failed or succeeded. What should userspace do? if it only get mappings on 3 of the gpus instead of say 4? Is there a sane resolution other than calling the ioctl a
Re: New KFD ioctls: taking the skeletons out of the closet
Am 07.03.2018 um 00:34 schrieb Jerome Glisse: On Tue, Mar 06, 2018 at 05:44:41PM -0500, Felix Kuehling wrote: Hi all, Christian raised two potential issues in a recent KFD upstreaming code review that are related to the KFD ioctl APIs: 1. behaviour of -ERESTARTSYS 2. transactional nature of KFD ioctl definitions, or lack thereof I appreciate constructive feedback, but I also want to encourage an open-minded rather than a dogmatic approach to API definitions. So let me take all the skeletons out of my closet and get these APIs reviewed in the appropriate forum before we commit to them upstream. See the end of this email for reference. The controversial part at this point is kfd_ioctl_map_memory_to_gpu. If any of the other APIs raise concerns or questions, please ask. Because of the HSA programming model, KFD memory management APIs are synchronous. There is no pipelining. Command submission to GPUs through user mode queues does not involve KFD. This means KFD doesn't know what memory is used by the GPUs and when it's used. That means, when the map_memory_to_gpu ioctl returns to user mode, all memory mapping operations are complete and the memory can be used by the CPUs or GPUs immediately. HSA also uses a shared virtual memory model, so typically memory gets mapped on multiple GPUs and CPUs at the same virtual address. Does this means that GPU memory get pin ? Or system memory for that matter too. This was discuss previously but this really goes against kernel mantra ie kernel no longer manage resources but userspace can hog GPU memory or even system memory. This is bad ! Fortunately this time it is not about pinning. All BOs which are part of the VM become a fence object when an user space queue is created. Now when TTM needs to evict those buffer object it will try to wait for this fence object which in turn will unmap the user space queue from the hardware and wait for running work to finish. After that TTM can move the BO around just like any normal GFX BO. Regards, Christian. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4 v4] drm/pl111: Use max memory bandwidth for resolution
We were previously selecting 1024x768 and 32BPP as the default
set-up for the PL111 consumers.
This does not work on elder systems: the device tree bindings
support a property "max-memory-bandwidth" in bytes/second that
states that if you exceed this the memory bus will saturate.
The result is flickering and unstable images.
Parse the "max-memory-bandwidth" and respect it when
intializing the driver. On the RealView PB11MP, Versatile and
Integrator/CP we get a nice console as default with this code.
Reviewed-by: Eric Anholt
Signed-off-by: Linus Walleij
---
ChangeLog v3->v4:
- Switch the noisy DRM_INFO for DRM_DEBUG_KMS
- Collect Eric's review tag
ChangeLog v2->v3:
- Account for the case where there is no bandwidth limitation
so priv->memory_bw is zero. Then just accept any modes.
ChangeLog v1->v2:
- Exploit the new .mode_valid() callback we added to the
simple KMS helper.
- Use the hardcoded bits per pixel per variant instead of
trying to be heuristic about this setting for now.
---
drivers/gpu/drm/pl111/pl111_display.c | 36 +++
drivers/gpu/drm/pl111/pl111_drm.h | 1 +
drivers/gpu/drm/pl111/pl111_drv.c | 6 ++
3 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index d75923896609..72e85397611a 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -50,6 +50,41 @@ irqreturn_t pl111_irq(int irq, void *data)
return status;
}
+static enum drm_mode_status
+pl111_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+ struct drm_device *drm = crtc->dev;
+ struct pl111_drm_dev_private *priv = drm->dev_private;
+ u32 cpp = priv->variant->fb_bpp / 8;
+ u64 bw;
+
+ /*
+* We use the pixelclock to also account for interlaced modes, the
+* resulting bandwidth is in bytes per second.
+*/
+ bw = mode->clock * 1000; /* In Hz */
+ bw = bw * mode->hdisplay * mode->vdisplay * cpp;
+ bw = div_u64(bw, mode->htotal * mode->vtotal);
+
+ /*
+* If no bandwidth constraints, anything goes, else
+* check if we are too fast.
+*/
+ if (priv->memory_bw && (bw > priv->memory_bw)) {
+ DRM_DEBUG_KMS("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
+ mode->hdisplay, mode->vdisplay,
+ mode->clock * 1000, cpp, bw);
+
+ return MODE_BAD;
+ }
+ DRM_DEBUG_KMS("%d x %d @ %d Hz, %d cpp, bw %llu bytes/s OK\n",
+ mode->hdisplay, mode->vdisplay,
+ mode->clock * 1000, cpp, bw);
+
+ return MODE_OK;
+}
+
static int pl111_display_check(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *pstate,
struct drm_crtc_state *cstate)
@@ -344,6 +379,7 @@ static int pl111_display_prepare_fb(struct
drm_simple_display_pipe *pipe,
}
static const struct drm_simple_display_pipe_funcs pl111_display_funcs = {
+ .mode_valid = pl111_mode_valid,
.check = pl111_display_check,
.enable = pl111_display_enable,
.disable = pl111_display_disable,
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h
b/drivers/gpu/drm/pl111/pl111_drm.h
index 360fbdd2203c..70b092670c04 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -65,6 +65,7 @@ struct pl111_drm_dev_private {
struct drm_simple_display_pipe pipe;
void *regs;
+ u32 memory_bw;
u32 ienb;
u32 ctrl;
/* The pixel clock (a reference to our clock divider off of CLCDCLK). */
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index 73d252351438..b469aa317d9d 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -262,6 +262,12 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
drm->dev_private = priv;
priv->variant = variant;
+ if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
+&priv->memory_bw)) {
+ dev_info(dev, "no max memory bandwidth specified, assume
unlimited\n");
+ priv->memory_bw = 0;
+ }
+
/* The two variants swap this register */
if (variant->is_pl110) {
priv->ienb = CLCD_PL110_IENB;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] freedreno: add missing symbols to symbol-check
2018-03-06 16:37 GMT+01:00 Eric Engestrom : > Fixes: 1384c081233751569473 "freedreno: add interface to get buffer address" > Signed-off-by: Eric Engestrom Reviewed-by: Christian Gmeiner > --- > freedreno/freedreno-symbol-check | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/freedreno/freedreno-symbol-check > b/freedreno/freedreno-symbol-check > index 56e3d3eeace6f9deb280..3b119528c6cfbfd9d4a0 100755 > --- a/freedreno/freedreno-symbol-check > +++ b/freedreno/freedreno-symbol-check > @@ -18,10 +18,12 @@ fd_bo_from_dmabuf > fd_bo_from_fbdev > fd_bo_from_handle > fd_bo_from_name > +fd_bo_get_iova > fd_bo_get_name > fd_bo_handle > fd_bo_map > fd_bo_new > +fd_bo_put_iova > fd_bo_ref > fd_bo_size > fd_device_del > -- > Cheers, > Eric > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104549] [radeonsi] [wine] [apitrace] Silent Hunter 3 2D texture artifacts / corrupted 3D redering on Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=104549 _archuser_ changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from _archuser_ --- Kernel update (4.15.6-1 -> 4.15.7-1) fixed the issue, was a possible drm driver issue/regression. -- 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 105369] HP HP ENVY x360, amdgpu, Call Trace tgn10_lock at startup, VMC page fault during runtime
https://bugs.freedesktop.org/show_bug.cgi?id=105369 --- Comment #3 from cd --- Full demesg see in dmesg2 attachment --snip [3.139563] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2! --snip [3.190734] [drm] Initialized amdgpu 3.23.0 20150101 for :04:00.0 on minor 0 [3.217577] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 1us * 100 tries - tgn10_lock line:566 --snip [3.217682] Hardware name: HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.13 11/10/2017 [3.217711] RIP: 0010:generic_reg_wait+0xee/0x120 [amdgpu] [3.217712] RSP: 0018:a4030192fa38 EFLAGS: 00010297 [3.217713] RAX: 0001 RBX: 0065 RCX: 0001 [3.217713] RDX: RSI: baeaa34a RDI: [3.217714] RBP: 0001 R08: ba49c4f0 R09: 03ff [3.217715] R10: 0002 R11: bb5c1f2d R12: 924545a78400 [3.217715] R13: 504d R14: 0100 R15: 0001 [3.217717] FS: 7f8e35de1740() GS:92455ecc() knlGS: [3.217717] CS: 0010 DS: ES: CR0: 80050033 [3.217718] CR2: 7f8e3568010f CR3: 000205a76000 CR4: 003406e0 [3.217719] Call Trace: [3.217754] tgn10_lock+0x9e/0xb0 [amdgpu] [3.217785] program_all_pipe_in_tree+0x1387/0x1440 [amdgpu] [3.217817] dcn10_apply_ctx_for_surface+0x4a0/0x510 [amdgpu] [3.217845] dc_commit_state+0x281/0x4b0 [amdgpu] [3.217878] amdgpu_dm_atomic_commit_tail+0x2ab/0x9a0 [amdgpu] [3.217901] ? amdgpu_bo_pin_restricted+0x1ac/0x290 [amdgpu] [3.217904] ? kmem_cache_alloc_trace+0x1a9/0x1c0 [3.217934] ? dm_plane_helper_prepare_fb+0x1d1/0x240 [amdgpu] [3.217942] commit_tail+0x3d/0x70 [drm_kms_helper] [3.217947] drm_atomic_helper_commit+0xfc/0x110 [drm_kms_helper] [3.217952] restore_fbdev_mode_atomic+0x181/0x1f0 [drm_kms_helper] [3.217957] drm_fb_helper_restore_fbdev_mode_unlocked.part.25+0x23/0x70 [drm_kms_helper] [3.217980] amdgpu_fbdev_restore_mode+0x1b/0x40 [amdgpu] [3.218002] amdgpu_driver_lastclose_kms+0xe/0x20 [amdgpu] [3.218011] drm_lastclose+0x37/0xf0 [drm] [3.218018] drm_release+0x2c5/0x380 [drm] [3.218021] __fput+0x9d/0x1e0 [3.218025] task_work_run+0x84/0xa0 [3.218028] exit_to_usermode_loop+0x96/0xa0 [3.218029] do_syscall_64+0x18a/0x190 [3.218033] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [3.218034] RIP: 0033:0x7f8e359f89f4 [3.218035] RSP: 002b:7ffc2dd7f588 EFLAGS: 0246 ORIG_RAX: 0003 [3.218036] RAX: RBX: 7ffc2dd7f680 RCX: 7f8e359f89f4 [3.218037] RDX: 7ffc2dd7f5a0 RSI: c04064a0 RDI: 0004 [3.218037] RBP: R08: 0001 R09: [3.218038] R10: 0133 R11: 0246 R12: 7ffc2dd7f5a0 [3.218038] R13: 0001 R14: 0001 R15: 0004 [3.218039] Code: 48 c7 c7 42 8d 10 c1 52 4c 8b 4c 24 58 48 c7 c2 e8 12 10 c1 44 8b 44 24 50 e8 ef e1 9b ff 41 83 7c 24 20 01 58 8b 44 24 08 74 02 <0f> 0b 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 c7 44 24 0c [3.218061] ---[ end trace e459452396c96ef1 ]--- --snip [ 190.230953] Hardware name: HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.13 11/10/2017 [ 190.230996] RIP: 0010:generic_reg_wait+0xee/0x120 [amdgpu] [ 190.230998] RSP: 0018:a40303f7f898 EFLAGS: 00010297 [ 190.231000] RAX: 0001 RBX: 0065 RCX: 0001 [ 190.231001] RDX: RSI: baeaa34a RDI: [ 190.231002] RBP: 0001 R08: ba49c4f0 R09: 043f [ 190.231003] R10: 0002 R11: bb5c1f2d R12: 924545a78400 [ 190.231003] R13: 504d R14: 0100 R15: 0001 [ 190.231005] FS: 7f94d9f22940() GS:92455ec4() knlGS: [ 190.231006] CS: 0010 DS: ES: CR0: 80050033 [ 190.231007] CR2: 7f94c010 CR3: 000208392000 CR4: 003406e0 [ 190.231008] Call Trace: [ 190.231060] tgn10_lock+0x9e/0xb0 [amdgpu] [ 190.231108] program_all_pipe_in_tree+0x1387/0x1440 [amdgpu] [ 190.231114] ? __mod_zone_page_state+0x66/0xa0 [ 190.231160] dcn10_apply_ctx_for_surface+0x4a0/0x510 [amdgpu] [ 190.231211] ? generic_reg_get+0x21/0x30 [amdgpu] [ 190.231272] dc_commit_state+0x281/0x4b0 [amdgpu] [ 190.231342] amdgpu_dm_atomic_commit_tail+0x2ab/0x9a0 [amdgpu] [ 190.231347] ? preempt_count_add+0x68/0xa0 [ 190.231351] ? _raw_spin_lock_irq+0x1a/0x40 [ 190.231353] ? _raw_spin_unlock_irq+0x1d/0x30 [ 190.231356] ? wait_for_common+0x151/0x180 [ 190.231358] ? _raw_spin_unlock_irq+0x1d/0x30 [ 190.231361] ? wait_for_common+0x151/0x180 [ 190.231374] commit_tail+0x3d/0x70 [drm_kms_helper] [ 190.231385] drm_ato
[Bug 105369] HP HP ENVY x360, amdgpu, Call Trace tgn10_lock at startup, VMC page fault during runtime
https://bugs.freedesktop.org/show_bug.cgi?id=105369 --- Comment #4 from cd --- Created attachment 137848 --> https://bugs.freedesktop.org/attachment.cgi?id=137848&action=edit dmesg2 -- 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 6/6] drm/amdgpu: explicit give BO type to amdgpu_bo_create
Am 06.03.2018 um 22:29 schrieb Felix Kuehling:
NAK.
For KFD we need the ability to create a BO from an SG list that doesn't
come from another BO. We use this for mapping pages from the doorbell
aperture into GPUVM for GPU self-dispatch.
You can still do this, see amdgpu_gem_prime_import_sg_table.
Just set the BO type to SG and then setting the SG table after creating it:
ret = amdgpu_bo_create(adev, attach->dmabuf->size, PAGE_SIZE,
AMDGPU_GEM_DOMAIN_CPU, 0, ttm_bo_type_sg,
resv, &bo);
if (ret)
goto error;
bo->tbo.sg = sg;
bo->tbo.ttm->sg = sg;
Then validate the result into the GTT domain to actually use the SG table.
BTW: How do you create an SG table for the doorbell?
Regards,
Christian.
If you remove this now, I'll need to add it back in some form in a month
or two when I get to that part of upstreaming KFD.
There may be other ways to implement this. Currently we need to create a
BO for anything we want to map into a GPUVM page table, because the
amdgpu_vm code is based around BOs. If there was a way to map physical
addresses into GPUVM without creating a buffer object, that would work too.
Regards,
Felix
On 2018-03-06 09:43 AM, Christian König wrote:
Drop the "kernel" and sg parameter and give the BO type to create
explicit to amdgpu_bo_create instead of figuring it out from the
parameters.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 5 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 8 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 7 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 46 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 11 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 7 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 11 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 8 ++---
11 files changed, 58 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 292c7e72820c..b1116b773516 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -441,7 +441,7 @@ struct amdgpu_sa_bo {
void amdgpu_gem_force_release(struct amdgpu_device *adev);
int amdgpu_gem_object_create(struct amdgpu_device *adev, unsigned long size,
int alignment, u32 initial_domain,
-u64 flags, bool kernel,
+u64 flags, enum ttm_bo_type type,
struct reservation_object *resv,
struct drm_gem_object **obj);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 450426dbed92..7f096ed6e83d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -215,8 +215,9 @@ int alloc_gtt_mem(struct kgd_dev *kgd, size_t size,
if ((*mem) == NULL)
return -ENOMEM;
- r = amdgpu_bo_create(adev, size, PAGE_SIZE, true, AMDGPU_GEM_DOMAIN_GTT,
-AMDGPU_GEM_CREATE_CPU_GTT_USWC, NULL, NULL,
&(*mem)->bo);
+ r = amdgpu_bo_create(adev, size, PAGE_SIZE, AMDGPU_GEM_DOMAIN_GTT,
+AMDGPU_GEM_CREATE_CPU_GTT_USWC, ttm_bo_type_kernel,
+NULL, &(*mem)->bo);
if (r) {
dev_err(adev->dev,
"failed to allocate BO for amdkfd (%d)\n", r);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
index 2fb299afc12b..02b849be083b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
@@ -80,8 +80,8 @@ static void amdgpu_benchmark_move(struct amdgpu_device *adev,
unsigned size,
int time;
n = AMDGPU_BENCHMARK_ITERATIONS;
- r = amdgpu_bo_create(adev, size, PAGE_SIZE, true, sdomain, 0, NULL,
-NULL, &sobj);
+ r = amdgpu_bo_create(adev, size, PAGE_SIZE,sdomain, 0,
+ttm_bo_type_kernel, NULL, &sobj);
if (r) {
goto out_cleanup;
}
@@ -93,8 +93,8 @@ static void amdgpu_benchmark_move(struct amdgpu_device *adev,
unsigned size,
if (r) {
goto out_cleanup;
}
- r = amdgpu_bo_create(adev, size, PAGE_SIZE, true, ddomain, 0, NULL,
-NULL, &dobj);
+ r = amdgpu_bo_create(adev, size, PAGE_SIZE, ddomain, 0,
+ttm_bo_type_kernel, NULL, &dobj);
if (r) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
Re: [PATCH v4 0/6] drm: zpos normalization cleanup and omapdrm to use it
Hi, On 2018-02-06 14:05, Peter Ujfalusi wrote: > Hi, > > Changes since v3: > - Moved the new normalize_zpos bool to be around another bools > - Extended the commit message for sti that the drm_atomic_helper_check() is > going to ask for async_update due to the legacy cursor usage. I think I have addressed all comments for the v4 and got Acked-by from Tomi as well. The series should apply cleanly on drm-next, but I can rebase and resend if it is required. Thanks, - Péter > Changes since v2: > - Fixed commit messages (s/drm_device/drm_mode_config) > - Added ack from Benjamin Gaignard to drm/sti patch > > Changes since v1: > - normalize_zpos flag moved to drm_mode_config > - Added comment to note the side effect of normalization and updated the > comment > for normalized_zpos in the header file as well. > - Added Acked-by from Daniel to patch 2-6 but not for patch 1 as I'm not sure > if > the comments I have added matches with what is expected to be. > > The first patch is adding a flag to drm_device that drivers can set if they > want > the zpos to be normalized. > > Then convert exynos, tegra, sti and rcar-du to use this flag instead of > re-implementing the drm_atomic_helper_check() locally just to add the call to > drm_atomic_normalize_zpos(). > > The last patch is moving omapdrm to use the zpos normalization as well to > comply > with the UAPI documentation regarding to zpos. > > Laurent's note in an earlier thread: > https://marc.info/?l=dri-devel&m=151567355225029&w=2 > > "The problem is that zpos normalization requires accessing the state of all > enabled planes for a CRTC in order to compute (and store) the normalized zpos > values. This thus forces all planes to be added to the commit state, even > when > the commit doesn't touch the zpos property. I assume this caused issues > (possibly performance issues) in drivers that then performed hardware setup > of > all planes as a result." > > can be addressed later in the core for all users of > drm_atomic_normalize_zpos() > > Regards, > Peter > --- > Peter Ujfalusi (6): > drm: Add drm_mode_config->normalize_zpos boolean > drm/exynos: Let core take care of normalizing the zpos > drm/tegra: Let core take care of normalizing the zpos > drm/sti: Let core take care of normalizing the zpos > drm: rcar-du: Let core take care of normalizing the zpos > drm/omap: Use normalized zpos for plane placement > > drivers/gpu/drm/drm_atomic_helper.c | 11 +++ > drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 > drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 - > drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 +++- > drivers/gpu/drm/omapdrm/omap_drv.c | 3 +++ > drivers/gpu/drm/omapdrm/omap_plane.c| 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 11 ++- > drivers/gpu/drm/sti/sti_drv.c | 24 +++- > drivers/gpu/drm/tegra/drm.c | 27 +++ > include/drm/drm_mode_config.h | 8 > include/drm/drm_plane.h | 4 ++-- > 11 files changed, 36 insertions(+), 79 deletions(-) > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105379] The Witcher: Enhanced Edition under Wine fails to launch
https://bugs.freedesktop.org/show_bug.cgi?id=105379 Bug ID: 105379 Summary: The Witcher: Enhanced Edition under Wine fails to launch Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: asheldo...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 137850 --> https://bugs.freedesktop.org/attachment.cgi?id=137850&action=edit Wine log with Mesa git The Witcher run under Wine fails to launch. Essentially, it hangs indefinitely before any video output but the game can be closed with Ctrl-C, and no ill effects are seen otherwise. Reverting commit b650fc09c3a35ca624aad5fe4b5c34867708f116 in Mesa works around the issue. The game also works fine with a Nvidia 980ti and 390.25 binary drivers. Hardware: Radeon RX 550 Software: 4.15.6 kernel [DC=0], Mesa git, Wine 3.3 Commit message: commit b650fc09c3a35ca624aad5fe4b5c34867708f116 Author: Nicolai Hähnle Date: Sun Oct 22 17:38:42 2017 +0200 radeonsi: fix potential use-after-free of debug callbacks Found by inspection. Reviewed-by: Marek Olšák -- 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 105379] The Witcher: Enhanced Edition under Wine fails to launch
https://bugs.freedesktop.org/show_bug.cgi?id=105379 --- Comment #1 from Andrew Sheldon --- Created attachment 137851 --> https://bugs.freedesktop.org/attachment.cgi?id=137851&action=edit Wine log with mesa git and reverted commit -- 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 104854] smu7_populate_single_firmware_entry fails to load powerplay firmware.
https://bugs.freedesktop.org/show_bug.cgi?id=104854
--- Comment #1 from José Pekkarinen ---
I believe the issue is actually shown before, these are the lines prior
to the error:
Mar 4 22:00:16 bee kernel: [ 35.741939] amdgpu: [powerplay] Failed to notify
smc display settings!
Mar 4 22:00:16 bee laptop-mode[9581]: Failed to re-set power saving mode for
wireless card
Mar 4 22:00:21 bee kernel: [ 40.847050] [drm:atom_op_jump [amdgpu]] *ERROR*
atombios stuck in loop for more than 5secs aborting
Mar 4 22:00:21 bee kernel: [ 40.847078]
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck
executing 7424 (len 272, WS 0, PS 4) @ 0x746D
Mar 4 22:00:21 bee kernel: [ 40.847102]
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck
executing 606A (len 70, WS 0, PS 8) @ 0x6090
Mar 4 22:00:21 bee kernel: [ 40.847117] [drm:amdgpu_device_resume [amdgpu]]
*ERROR* amdgpu asic init failed
Mar 4 22:00:21 bee kernel: [ 41.200534] amdgpu :01:00.0: Wait for MC
idle timedout !
Mar 4 22:00:22 bee kernel: [ 41.553970] amdgpu :01:00.0: Wait for MC
idle timedout !
Mar 4 22:00:22 bee kernel: [ 41.563727] [drm] PCIE GART of 256M enabled
(table at 0x00F40004).
Mar 4 22:00:22 bee kernel: [ 41.566759] amdgpu: [powerplay] smu not running,
upload firmware again
...
I believe the error is that the following function is trying to send a message
to a display, when the vga is not tied to any:
static int smu7_notify_smc_display(struct pp_hwmgr *hwmgr)
{
struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
if (hwmgr->feature_mask & PP_VBI_TIME_SUPPORT_MASK)
smum_send_msg_to_smc_with_parameter(hwmgr,
(PPSMC_Msg)PPSMC_MSG_SetVBITimeout,
data->frame_time_x2);
return (smum_send_msg_to_smc(hwmgr, (PPSMC_Msg)PPSMC_HasDisplay) == 0)
? 0 : -EINVAL;
}
Is there any way to check if there is a display from hwmgr?
--
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 57496] Artefacts when playing OpenGL games
https://bugs.freedesktop.org/show_bug.cgi?id=57496 Timothy Arceri changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Other |Drivers/DRI/i915 --- Comment #2 from Timothy Arceri --- Please let us know if this is fixed. Reassigning to the correct driver. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave, Only a few sun4i fixes this week. Please pull. Regards, Gustavo drm-misc-fixes-2018-03-07: sun4i fixes on clk, division by zero and LVDS. The following changes since commit 9a191b114906457c4b2494c474f58ae4142d4e67: virtio-gpu: fix ioctl and expose the fixed status to userspace. (2018-02-27 08:37:58 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-03-07 for you to fetch changes up to fd00c4ee76f0b509ce79ffbc1f5a682fbdd84efd: drm/sun4i: crtc: Call drm_crtc_vblank_on / drm_crtc_vblank_off (2018-03-06 16:27:54 +0100) sun4i fixes on clk, division by zero and LVDS. Giulio Benetti (1): drm/sun4i: Fix dclk_set_phase Jernej Skrabec (1): drm/sun4i: Release exclusive clock lock when disabling TCON Maxime Ripard (3): drm/sun4i: tcon: Reduce the scope of the LVDS error a bit drm/sun4i: rgb: Fix potential division by zero drm/sun4i: crtc: Call drm_crtc_vblank_on / drm_crtc_vblank_off drivers/gpu/drm/sun4i/sun4i_crtc.c | 4 ++ drivers/gpu/drm/sun4i/sun4i_dotclock.c | 5 +- drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 + drivers/gpu/drm/sun4i/sun4i_tcon.c | 92 ++ drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + 5 files changed, 60 insertions(+), 44 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #33 from letha...@gmail.com --- After trying the channel-count patch. The different formats tested advertise correctly to my receiver (tried dts-hdma and dolby trued hd). But the sound is even more "garbled" in those format than previous ones. Where a "stress -m2" was enough high cpu load to get a good sound, it now improves the garbling, but not enough anymore. So It is better, HBR formats are now passing by, yeay! :) But bug https://bugzilla.kernel.org/show_bug.cgi?id=86351 is still killing my sound. -- 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 105324] R9 285 weston hangs since drm/amd/pp: Fix bug that dpm level was not really locked
https://bugs.freedesktop.org/show_bug.cgi?id=105324 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andy Furniss --- OK with current drm-next-4.17-wip. -- 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 104064] (DC 4.15-rc2) WARNING: CPU: 4 PID: 75 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:601 dm_suspend+0x4e/0x60 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=104064 --- Comment #28 from taij...@posteo.de --- Created attachment 137852 --> https://bugs.freedesktop.org/attachment.cgi?id=137852&action=edit dmesg with 4.17-wip-4ac51159819d and dc=1 And here is my daily testing report (do you guys actually read them anymore?). Build 4ac51159819d seems to ba a clear regression: dc=1 does not even boot - after enetring my LUKS passphrase, the screen just freezes, and that is that. dc=0 does boot and does not crash when running DRI_PRIME=1 glxgears, however, glxgears is no longer synced to my monitors refresh rate, for some reason (48 vs 60 FPS). Also pm still does not work wrt powering down the dGPU. -- 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 v5 0/6] dt-bindings: add bindings for USB physical connector
Hi Chanwoo, Archit, On 07.03.2018 05:48, Chanwoo Choi wrote: > On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >> Hi Rob and Andrzej, >> >> On 2018년 03월 06일 21:53, Andrzej Hajda wrote: >>> Hi Rob, Chanwoo, Krzysztof, >>> >>> >>> On 27.02.2018 08:11, Andrzej Hajda wrote: Hi, Thanks for reviews of previous iterations. This patchset introduces USB physical connector bindings, together with working example. I have removed RFC prefix - the patchset seems to be heading to a happy end :) v5: fixed extra parenthesis in dts, renamed extcon function. v4: improved binding descriptions, added missing reg in dts. v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C example. v2: I have addressed comments by Rob and Laurent, thanks Changes in datail are described in the patches. Regards Andrzej Andrzej Hajda (5): dt-bindings: add bindings for USB physical connector dt-bindings: add bindings for Samsung micro-USB 11-pin connector arm64: dts: exynos: add micro-USB connector node to TM2 platforms arm64: dts: exynos: add OF graph between MHL and USB connector extcon: add possibility to get extcon device by OF node Maciej Purski (1): drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL >>> It looks like all patches received R-B or acks (I forgot add Krzysztof's >>> acks for dts part). >>> Now I have a question how to merge them. >>> The only functional dependency is between bridge and extcon, and from >>> the formal PoV bindings should be merged 1st. >>> I can merge it: >>> 1. All patches via drm-misc tree. >>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via >>> samsung-soc tree. >>> >>> Is it OK, for all? Better ideas? >> Krzysztof picked the dts patches. I'll make the immutable branch based on >> v4.16-rc1 >> and apply them except for dts patchs. And I'll send the immutable branch to >> Rob and Andrzej. >> >> > I made the immutable branch[1] as following: If you agree, I'll send pull > request. > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17 > > Or you can make the immutable branch and send pull request to Rob and me. > It seems you took v5 instead of v6 version of extcon patch. Beside it I am OK with your immutable branch, Archit is it OK to do it this way in drm-misc? Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector
On Wed, Mar 7, 2018 at 12:13 PM, Andrzej Hajda wrote: > Hi Chanwoo, Archit, > > On 07.03.2018 05:48, Chanwoo Choi wrote: >> On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >>> Hi Rob and Andrzej, >>> >>> On 2018년 03월 06일 21:53, Andrzej Hajda wrote: Hi Rob, Chanwoo, Krzysztof, On 27.02.2018 08:11, Andrzej Hajda wrote: > Hi, > > Thanks for reviews of previous iterations. > > This patchset introduces USB physical connector bindings, together with > working example. > I have removed RFC prefix - the patchset seems to be heading > to a happy end :) > > v5: fixed extra parenthesis in dts, renamed extcon function. > v4: improved binding descriptions, added missing reg in dts. > v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C > example. > v2: I have addressed comments by Rob and Laurent, thanks > > Changes in datail are described in the patches. > > Regards > Andrzej > > > Andrzej Hajda (5): > dt-bindings: add bindings for USB physical connector > dt-bindings: add bindings for Samsung micro-USB 11-pin connector > arm64: dts: exynos: add micro-USB connector node to TM2 platforms > arm64: dts: exynos: add OF graph between MHL and USB connector > extcon: add possibility to get extcon device by OF node > > Maciej Purski (1): > drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL It looks like all patches received R-B or acks (I forgot add Krzysztof's acks for dts part). Now I have a question how to merge them. The only functional dependency is between bridge and extcon, and from the formal PoV bindings should be merged 1st. I can merge it: 1. All patches via drm-misc tree. 2. All patches except dts via drm-misc, and Krzysztof will merge dts via samsung-soc tree. Is it OK, for all? Better ideas? >>> Krzysztof picked the dts patches. I'll make the immutable branch based on >>> v4.16-rc1 >>> and apply them except for dts patchs. And I'll send the immutable branch to >>> Rob and Andrzej. >>> >>> >> I made the immutable branch[1] as following: If you agree, I'll send pull >> request. >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17 >> >> Or you can make the immutable branch and send pull request to Rob and me. >> > > It seems you took v5 instead of v6 version of extcon patch. I also took v5: https://patchwork.kernel.org/patch/10244407/ https://patchwork.kernel.org/patch/10244431/ There was no v6 in samsung-soc patchwork. Is it a problem for DTS? BR, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/mali-dp: Fix malidp_atomic_commit_hw_done() for event sending.
On Mon, Mar 05, 2018 at 06:03:16PM +, Liviu Dudau wrote:
> Mali DP hardware has a 'go' bit (config_valid) for making the new scene
> parameters active at the next page flip. The problem with the current
> code is that the driver first sets this bit and then proceeds to wait
> for confirmation from the hardware that the configuration has been
> updated before arming the vblank event. As config_valid is actually
> asserted by the hardware after the vblank event, during the prefetch
> phase, when we get to arming the vblank event we are going to send it
> at the next vblank, in effect halving the vblank rate from the userspace
> perspective.
>
> Fix it by sending the userspace event from the IRQ handler, when we
> handle the config_valid interrupt, which syncs with the time when the
> hardware is active with the new parameters.
>
> v2: Brian reminded me that interrupts won't fire when CRTC is off,
> so we need to do the sending ourselves.
>
> v3: crtc->enabled is the wrong flag to use here, as when we get an
> atomic commit that turns off the CRTC it will still be enabled until
> after the commit is done. Use the crtc->state->active for test.
>
> Reported-by: Alexandru-Cosmin Gheorghe
> Signed-off-by: Liviu Dudau
Tested this with Mali DP-650, modetest is able to do page flipping at the
expected frequency. Also, I didn't observe any regressions in the
driver unit tests.
Tested-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 32 +---
> drivers/gpu/drm/arm/malidp_drv.h | 1 +
> drivers/gpu/drm/arm/malidp_hw.c | 12 +---
> 3 files changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index d88a3b9d59cc..3c628e43bf25 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -185,25 +185,29 @@ static int malidp_set_and_wait_config_valid(struct
> drm_device *drm)
>
> static void malidp_atomic_commit_hw_done(struct drm_atomic_state *state)
> {
> - struct drm_pending_vblank_event *event;
> struct drm_device *drm = state->dev;
> struct malidp_drm *malidp = drm->dev_private;
>
> - if (malidp->crtc.enabled) {
> - /* only set config_valid if the CRTC is enabled */
> - if (malidp_set_and_wait_config_valid(drm))
> - DRM_DEBUG_DRIVER("timed out waiting for updated
> configuration\n");
> - }
> + malidp->event = malidp->crtc.state->event;
> + malidp->crtc.state->event = NULL;
>
> - event = malidp->crtc.state->event;
> - if (event) {
> - malidp->crtc.state->event = NULL;
> + if (malidp->crtc.state->active) {
> + /*
> + * if we have an event to deliver to userspace, make sure
> + * the vblank is enabled as we are sending it from the IRQ
> + * handler.
> + */
> + if (malidp->event)
> + drm_crtc_vblank_get(&malidp->crtc);
>
> + /* only set config_valid if the CRTC is enabled */
> + if (malidp_set_and_wait_config_valid(drm) < 0)
> + DRM_DEBUG_DRIVER("timed out waiting for updated
> configuration\n");
> + } else if (malidp->event) {
> + /* CRTC inactive means vblank IRQ is disabled, send event
> directly */
> spin_lock_irq(&drm->event_lock);
> - if (drm_crtc_vblank_get(&malidp->crtc) == 0)
> - drm_crtc_arm_vblank_event(&malidp->crtc, event);
> - else
> - drm_crtc_send_vblank_event(&malidp->crtc, event);
> + drm_crtc_send_vblank_event(&malidp->crtc, malidp->event);
> + malidp->event = NULL;
> spin_unlock_irq(&drm->event_lock);
> }
> drm_atomic_helper_commit_hw_done(state);
> @@ -232,8 +236,6 @@ static void malidp_atomic_commit_tail(struct
> drm_atomic_state *state)
>
> malidp_atomic_commit_hw_done(state);
>
> - drm_atomic_helper_wait_for_vblanks(drm, state);
> -
> pm_runtime_put(drm->dev);
>
> drm_atomic_helper_cleanup_planes(drm, state);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.h
> b/drivers/gpu/drm/arm/malidp_drv.h
> index e0d12c9fc6b8..c2375bb49619 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.h
> +++ b/drivers/gpu/drm/arm/malidp_drv.h
> @@ -22,6 +22,7 @@ struct malidp_drm {
> struct malidp_hw_device *dev;
> struct drm_crtc crtc;
> wait_queue_head_t wq;
> + struct drm_pending_vblank_event *event;
> atomic_t config_valid;
> u32 core_id;
> };
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 2bfb542135ac..8abd335ec313 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -782,9 +782,15 @@ static irqreturn_t malidp_de_irq(int irq, void *arg)
> /* first handle the config valid IRQ */
> dc_status = malidp
[Bug 105359] kms_frontbuffer_tracking - FBC disabled
https://bugs.freedesktop.org/show_bug.cgi?id=105359
--- Comment #6 from Marta Löfstedt ---
I now found this to be even stranger than anticipated:
checking the i915_FBC_state while running kms tests I have ended up way to many
states for this to be sane:
After reboot:
FBC enabled
Compressing: yes
after killing lightdm:
FBC disabled: framebuffer not tiled or fenced
after running some kms tests:
FBC disabled: frontbuffer write
or
FBC disabled: no suitable CRTC for FBC
or
FBC disabled: FBC enabled (active or scheduled)
FBC worker scheduled on vblank 154675, now 154675
My recent idea was to set a warn on disabled:
+ if (strstr(buf, "FBC disabled: "))
+ {
+ igt_warn("%s\n", buf);
+ igt_assert(true);
+ }
This would result in the WARN result if FBC was disabled. This would not save
any runtime, but it should stop the confusion if the test failed due to timeout
or if due to FBC being disable.
However, when testing above on a SKL NUCi5 system I always end up with WARN on
all tests.
--
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 v5 0/6] dt-bindings: add bindings for USB physical connector
On 07.03.2018 12:22, Krzysztof Kozlowski wrote: > On Wed, Mar 7, 2018 at 12:13 PM, Andrzej Hajda wrote: >> Hi Chanwoo, Archit, >> >> On 07.03.2018 05:48, Chanwoo Choi wrote: >>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote: Hi Rob and Andrzej, On 2018년 03월 06일 21:53, Andrzej Hajda wrote: > Hi Rob, Chanwoo, Krzysztof, > > > On 27.02.2018 08:11, Andrzej Hajda wrote: >> Hi, >> >> Thanks for reviews of previous iterations. >> >> This patchset introduces USB physical connector bindings, together with >> working example. >> I have removed RFC prefix - the patchset seems to be heading >> to a happy end :) >> >> v5: fixed extra parenthesis in dts, renamed extcon function. >> v4: improved binding descriptions, added missing reg in dts. >> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C >> example. >> v2: I have addressed comments by Rob and Laurent, thanks >> >> Changes in datail are described in the patches. >> >> Regards >> Andrzej >> >> >> Andrzej Hajda (5): >> dt-bindings: add bindings for USB physical connector >> dt-bindings: add bindings for Samsung micro-USB 11-pin connector >> arm64: dts: exynos: add micro-USB connector node to TM2 platforms >> arm64: dts: exynos: add OF graph between MHL and USB connector >> extcon: add possibility to get extcon device by OF node >> >> Maciej Purski (1): >> drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL > It looks like all patches received R-B or acks (I forgot add Krzysztof's > acks for dts part). > Now I have a question how to merge them. > The only functional dependency is between bridge and extcon, and from > the formal PoV bindings should be merged 1st. > I can merge it: > 1. All patches via drm-misc tree. > 2. All patches except dts via drm-misc, and Krzysztof will merge dts via > samsung-soc tree. > > Is it OK, for all? Better ideas? Krzysztof picked the dts patches. I'll make the immutable branch based on v4.16-rc1 and apply them except for dts patchs. And I'll send the immutable branch to Rob and Andrzej. >>> I made the immutable branch[1] as following: If you agree, I'll send pull >>> request. >>> [1] >>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17 >>> >>> Or you can make the immutable branch and send pull request to Rob and me. >>> >> It seems you took v5 instead of v6 version of extcon patch. > I also took v5: > https://patchwork.kernel.org/patch/10244407/ > https://patchwork.kernel.org/patch/10244431/ > > There was no v6 in samsung-soc patchwork. Is it a problem for DTS? No, v6 was only typo fix in comment, and only extcon patch has v6. Regards Andrzej > > BR, > Krzysztof > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland
https://bugs.freedesktop.org/show_bug.cgi?id=99353 Bong Cosca changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED -- 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
[PATCH libdrm] drm/atomic: Refuse to add invalid objects to requests
Object and property IDs cannot be zero. Prevent them from being added to
the request stream at all, rather than breaking at commit time.
Signed-off-by: Daniel Stone
---
xf86drmMode.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 15957ffc..bd59ef25 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -1313,6 +1313,9 @@ int drmModeAtomicAddProperty(drmModeAtomicReqPtr req,
if (!req)
return -EINVAL;
+ if (object_id == 0 || property_id == 0)
+ return -EINVAL;
+
if (req->cursor >= req->size_items) {
drmModeAtomicReqItemPtr new;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Aspirant for GSOC 2018 for Nouveau Vulkan driver
Hi Anusha, Sorry, I was under the expectation that userspace developers would answer you after your first message, and I missed your second one! My sincere apologies. Generally, the process is that the student should research the topic by first asking questions to developers about the effort, then they would make their own plan. Then you would present this plan while looking for a mentor. Of course, you can expect help from the community in order to better understand what needs to be done, but don't expect to be given a detailed plan, just pointers. Sorry again for my lack of feedback, Martin On 07/03/18 05:53, Anusha Srivastava wrote: > Hi, > > I am not been able to contact with mentor of this project. > Can someone else from the community help me with this ? > > > Regards, > Anusha Srivastava > > > On 3 March 2018 at 11:16, Anusha Srivastava wrote: >> Hi Martin, >> >> Any update on this ? >> Regards, >> Anusha Srivastava >> >> >> On 28 February 2018 at 23:37, Anusha Srivastava >> wrote: >>> Hi, >>> >>> I would like to participate in GSOC 2018 with Xorg to contribute to >>> project "Initial Nouveau Vulkan driver' >>> I would need some help in how to get started with the same. >>> >>> Regards, >>> Anusha Srivastava ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42941] Resume from suspend to memory leaves display blank on Lenovo Ideapad U455
https://bugzilla.kernel.org/show_bug.cgi?id=42941 roman (cool...@gmx.at) changed: What|Removed |Added CC||cool...@gmx.at --- Comment #3 from roman (cool...@gmx.at) --- Does this still happen?? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().
On Sunday, February 04, 2018 09:18:03 AM Peter Malone wrote: > Hi folks, Hi, > CVE-2018-6412 has been created for this. Is it possible for you to add > a note indicating the CVE number when merging the patch? > > I received the CVE number after the patch was created and ack'd, which > is why I didn't include it in the commit message. I queued the patch (with Mathieu's ACK and CVE number added to the patch description) for v4.16, thanks. > On Wed, Jan 31, 2018 at 10:49 AM, Mathieu Malaterre wrote: > > Hi Peter, > > > > On Wed, Jan 31, 2018 at 3:57 PM, Peter Malone > > wrote: > >> Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in > >> sbusfb_ioctl_helper(). > >> > >> 'index' is defined as an int in sbusfb_ioctl_helper(). > >> We retrieve this from the user: > >> if (get_user(index, &c->index) || > >> __get_user(count, &c->count) || > >> __get_user(ured, &c->red) || > >> __get_user(ugreen, &c->green) || > >> __get_user(ublue, &c->blue)) > >>return -EFAULT; > >> > >> and then we use 'index' in the following way: > >> red = cmap->red[index + i] >> 8; > >> green = cmap->green[index + i] >> 8; > >> blue = cmap->blue[index + i] >> 8; > >> > >> This is a classic information leak vulnerability. 'index' should be > >> an unsigned int, given its usage above. > >> > >> This patch is straight-forward; it changes 'index' to unsigned int > >> in two switch-cases: FBIOGETCMAP_SPARC && FBIOPUTCMAP_SPARC. > >> > >> Signed-off-by: Peter Malone > >> --- > > > > much better :) > > > >> v2: fixed formatting > >> > >> drivers/video/fbdev/sbuslib.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c > >> index af6fc97f4ba4..a436d44f1b7f 100644 > >> --- a/drivers/video/fbdev/sbuslib.c > >> +++ b/drivers/video/fbdev/sbuslib.c > >> @@ -122,7 +122,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned > >> long arg, > >> unsigned char __user *ured; > >> unsigned char __user *ugreen; > >> unsigned char __user *ublue; > >> - int index, count, i; > >> + unsigned int index, count, i; > >> > >> if (get_user(index, &c->index) || > >> __get_user(count, &c->count) || > >> @@ -161,7 +161,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned > >> long arg, > >> unsigned char __user *ugreen; > >> unsigned char __user *ublue; > >> struct fb_cmap *cmap = &info->cmap; > >> - int index, count, i; > >> + unsigned int index, count, i; > >> u8 red, green, blue; > >> > >> if (get_user(index, &c->index) || > >> -- > >> 2.14.3 > >> > > > > By just looking at the code and commit message: > > > > Acked-by: Mathieu Malaterre Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199047] New: [amdgpu CARRIZO] disabled backlight after S3 resume
https://bugzilla.kernel.org/show_bug.cgi?id=199047 Bug ID: 199047 Summary: [amdgpu CARRIZO] disabled backlight after S3 resume Product: Drivers Version: 2.5 Kernel Version: 4.16-rc1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: johannes.hi...@datenkhaos.de Regression: No After S3 resume, the backlight stays disabled. Re-enabling is possible with brightness-hotkeys. The regression was introduced with: commit 4ec6ecf48c64d1da82a008f6fb0be86c4044287d (refs/bisect/bad) Author: Alex Deucher Date: Tue Dec 12 15:20:22 2017 -0500 drm/amdgpu: drop scratch regs save and restore from S3/S4 handling The expectation is that the base driver doesn't mess with these. Some components interact with these directly so let the components handle these directly. Reviewed-by: Harry Wentland Acked-by: Christian König Signed-off-by: Alex Deucher lspci: 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1576 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 1577 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Carrizo (rev c5) 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Kabini HDMI/DP Audio 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 157b 00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 157c 00:02.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 157c 00:02.5 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 157c 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 157b 00:08.0 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 1578 00:09.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 157d 00:09.2 Audio device: Advanced Micro Devices, Inc. [AMD] Device 157a 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 20) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 49) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 49) 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 4a) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1570 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1571 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1572 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1573 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1574 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1575 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 02:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] libdrm: gralloc_handle.h: Fix build issue with Android
Hey John, Yeah, the return type should be changed. robher: Do you have any preferences? Rob. On 03/06/2018 09:28 PM, John Stultz wrote: In trying to integrate the new gralloc_handle.h with the drm_hwcomposer, I started seeing the following compilation errors: In file included from external/drm_hwcomposer/platformdrmgeneric.cpp:28: external/libdrm/android/gralloc_handle.h:108:9: error: cannot initialize return object of type 'native_handle_t *' (aka 'native_handle *') with an lvalue of type 'struct gralloc_handle_t *' return handle; ^~ 1 error generated. This seems to be due to the gralloc_handle_create() definition claiming to return a native_handle_t * type, rather then a gralloc_handle_t *, which is what the code actually returns. This function isn't actually used in the current drm_hwcomposer, so I'm not totally sure that this fix is correct (rather then returning the gralloc_handle_t's embadedded native_handle_t ptr). But it seems something like this is needed. Cc: Robert Foss Cc: Rob Herring Signed-off-by: John Stultz --- android/gralloc_handle.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/android/gralloc_handle.h b/android/gralloc_handle.h index 9cb5a5d..6e925c9 100644 --- a/android/gralloc_handle.h +++ b/android/gralloc_handle.h @@ -84,7 +84,7 @@ static inline struct gralloc_handle_t *gralloc_handle(buffer_handle_t handle) /** * Create a buffer handle. */ -static inline native_handle_t *gralloc_handle_create(int32_t width, +static inline gralloc_handle_t *gralloc_handle_create(int32_t width, int32_t height, int32_t hal_format, int32_t usage) @@ -107,5 +107,4 @@ static inline native_handle_t *gralloc_handle_create(int32_t width, return handle; } - #endif ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 00/60] omapdrm: Reverse direction of DSS device (dis)connect operations
Hi, On 07/03/18 02:24, Laurent Pinchart wrote: > Hello, > > This patch series is a first step towards moving the omapdrm driver away from > the custom bridge and panel drivers to drm_bridge and drm_panel. > > The main blocker to transition to drm_bridge and drm_panel is the direction of > the bridge operations. While the omapdrm driver manages its components from > sink to source (panel to DSS output), the drm_bridge API is manages bridges in > the source to sink direction. This makes the two models incompatible, and > requires reversing the direction of operations inside omapdrm. > > Don't rejoice too fast, we're still far from a complete transition, but this > first step paves the way by reworking the driver's internals to make source to > sink order possible. It then transitions the connect and disconnect operations > (the omapdrm equivalent of the drm_bridge attach and detach operations) to the > new direction. > > I've sent the patches as an RFC as I might not be aware of all the > consequences of the numerous changes to the driver's internals, even if I took > care to analyze the code flows to the best of my abilities. > > The series contains patches previously posted by Jyri and Peter that I have > found helpful. Please see the individual patches for changes compared to the > original versions (trivial conflict resolutions caused by a rebase are not > mentioned). > > The patches are based on top of a merge between Tomi's omapdrm-next branch and > the drm-misc/drm-misc-next branch for the "drm: fix drm_get_max_iomem type > mismatch" compilation fix. They can be found at > > git://linuxtv.org/pinchartl/media.git omapdrm/bridge > > The series has been tested on a Pandaboard with the HDMI and DVI outputs. All > patches have been at least compile-tested individually. I'll now go through > the process of making sure each of them gets tested on hardware as well. Thanks, nice work! I did a read-the-descs-review, and looks good to me. My only comments are what I already mentioned in the chat: AM5 EVM doesn't work LCD (panel-dpi broken, perhaps?) (AM5 EVM was the only board I tested), and patch 7 it not correct, as the infoframe is set from omap_encoder. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2.1 5/7] cec-pin: add error injection support
Implement all the error injection commands.
The state machine gets new states for the various error situations,
helper functions are added to detect whether an error injection is
active and the actual error injections are implemented.
Signed-off-by: Hans Verkuil
---
Changes since v2:
- Fix wrong arg_idx condition (must be >= 0)
- Fix tx_no_eom and tx_early_eom: don't call this for every byte, only
for the byte it applies to. Otherwise command will be cleared in the 'once'
mode.
---
drivers/media/cec/cec-pin-priv.h | 38 ++-
drivers/media/cec/cec-pin.c | 545 +++
2 files changed, 524 insertions(+), 59 deletions(-)
diff --git a/drivers/media/cec/cec-pin-priv.h b/drivers/media/cec/cec-pin-priv.h
index 779384f18689..c9349f68e554 100644
--- a/drivers/media/cec/cec-pin-priv.h
+++ b/drivers/media/cec/cec-pin-priv.h
@@ -28,14 +28,30 @@ enum cec_pin_state {
CEC_ST_TX_START_BIT_LOW,
/* Drive CEC high for the start bit */
CEC_ST_TX_START_BIT_HIGH,
+ /* Generate a start bit period that is too short */
+ CEC_ST_TX_START_BIT_HIGH_SHORT,
+ /* Generate a start bit period that is too long */
+ CEC_ST_TX_START_BIT_HIGH_LONG,
+ /* Drive CEC low for the start bit using the custom timing */
+ CEC_ST_TX_START_BIT_LOW_CUSTOM,
+ /* Drive CEC high for the start bit using the custom timing */
+ CEC_ST_TX_START_BIT_HIGH_CUSTOM,
/* Drive CEC low for the 0 bit */
CEC_ST_TX_DATA_BIT_0_LOW,
/* Drive CEC high for the 0 bit */
CEC_ST_TX_DATA_BIT_0_HIGH,
+ /* Generate a bit period that is too short */
+ CEC_ST_TX_DATA_BIT_0_HIGH_SHORT,
+ /* Generate a bit period that is too long */
+ CEC_ST_TX_DATA_BIT_0_HIGH_LONG,
/* Drive CEC low for the 1 bit */
CEC_ST_TX_DATA_BIT_1_LOW,
/* Drive CEC high for the 1 bit */
CEC_ST_TX_DATA_BIT_1_HIGH,
+ /* Generate a bit period that is too short */
+ CEC_ST_TX_DATA_BIT_1_HIGH_SHORT,
+ /* Generate a bit period that is too long */
+ CEC_ST_TX_DATA_BIT_1_HIGH_LONG,
/*
* Wait for start of sample time to check for Ack bit or first
* four initiator bits to check for Arbitration Lost.
@@ -43,6 +59,20 @@ enum cec_pin_state {
CEC_ST_TX_DATA_BIT_1_HIGH_PRE_SAMPLE,
/* Wait for end of bit period after sampling */
CEC_ST_TX_DATA_BIT_1_HIGH_POST_SAMPLE,
+ /* Generate a bit period that is too short */
+ CEC_ST_TX_DATA_BIT_1_HIGH_POST_SAMPLE_SHORT,
+ /* Generate a bit period that is too long */
+ CEC_ST_TX_DATA_BIT_1_HIGH_POST_SAMPLE_LONG,
+ /* Drive CEC low for a data bit using the custom timing */
+ CEC_ST_TX_DATA_BIT_LOW_CUSTOM,
+ /* Drive CEC high for a data bit using the custom timing */
+ CEC_ST_TX_DATA_BIT_HIGH_CUSTOM,
+ /* Drive CEC low for a standalone pulse using the custom timing */
+ CEC_ST_TX_PULSE_LOW_CUSTOM,
+ /* Drive CEC high for a standalone pulse using the custom timing */
+ CEC_ST_TX_PULSE_HIGH_CUSTOM,
+ /* Start low drive */
+ CEC_ST_TX_LOW_DRIVE,
/* Rx states */
@@ -54,8 +84,8 @@ enum cec_pin_state {
CEC_ST_RX_DATA_SAMPLE,
/* Wait for earliest end of bit period after sampling */
CEC_ST_RX_DATA_POST_SAMPLE,
- /* Wait for CEC to go high (i.e. end of bit period */
- CEC_ST_RX_DATA_HIGH,
+ /* Wait for CEC to go low (i.e. end of bit period) */
+ CEC_ST_RX_DATA_WAIT_FOR_LOW,
/* Drive CEC low to send 0 Ack bit */
CEC_ST_RX_ACK_LOW,
/* End of 0 Ack time, wait for earliest end of bit period */
@@ -64,9 +94,9 @@ enum cec_pin_state {
CEC_ST_RX_ACK_HIGH_POST,
/* Wait for earliest end of bit period and end of message */
CEC_ST_RX_ACK_FINISH,
-
/* Start low drive */
- CEC_ST_LOW_DRIVE,
+ CEC_ST_RX_LOW_DRIVE,
+
/* Monitor pin using interrupts */
CEC_ST_RX_IRQ,
diff --git a/drivers/media/cec/cec-pin.c b/drivers/media/cec/cec-pin.c
index 7920ea1c940b..c450145ef67a 100644
--- a/drivers/media/cec/cec-pin.c
+++ b/drivers/media/cec/cec-pin.c
@@ -39,11 +39,29 @@
#define CEC_TIM_IDLE_SAMPLE1000
/* when processing the start bit, sample twice per millisecond */
#define CEC_TIM_START_BIT_SAMPLE 500
-/* when polling for a state change, sample once every 50 micoseconds */
+/* when polling for a state change, sample once every 50 microseconds */
#define CEC_TIM_SAMPLE 50
#define CEC_TIM_LOW_DRIVE_ERROR(1.5 * CEC_TIM_DATA_BIT_TOTAL)
+/*
+ * Total data bit time that is too short/long for a valid bit,
+ * used for error injection.
+ */
+#define CEC_TIM_DATA_BIT_TOTAL_SHORT 1800
+#define CEC_TIM_DATA_BIT_TOTAL_LONG2900
+
+/*
+ * Total start bit time that is too short/long for a valid bit,
+ * used for error injection.
+ */
+#define CEC_TIM_START_BIT_TOTAL_SHORT 4100
+
[Bug 105144] Recent mesa makes GPU temperature too hot with GL/VDPAU/VAAPI
https://bugs.freedesktop.org/show_bug.cgi?id=105144 --- Comment #2 from K.Ohta --- Sorry for later. I don't use AMDGPU, (still) using RADEON kernel driver. But, this seems to same issue. I install fancontrol and set parameters of /etc/fancontrol , this issue seems to be fixed. Thanks for your advice. Regards, Ohta. # I'm using SAPPHIRE's RADEON HD7770 GPU board, and ASROCK 990FX Extreme4 mainboard. -- 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 105369] HP HP ENVY x360, amdgpu, Call Trace tgn10_lock at startup, VMC page fault during runtime
https://bugs.freedesktop.org/show_bug.cgi?id=105369 --- Comment #5 from Harry Wentland --- Can you see if this is fixed in the branch drm-next-4.17-wip of Alex's repo (https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next)? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/vc4: Check if plane requires background fill
On Tue, Mar 06, 2018 at 04:10:33PM -0800, Eric Anholt wrote:
> Ville Syrjälä writes:
>
> > On Tue, Mar 06, 2018 at 02:48:38AM +0100, Stefan Schake wrote:
> >> Considering a single plane only, we have to enable background color
> >> when the plane has an alpha format and could be blending from the
> >> background or when it doesn't cover the entire screen.
> >>
> >> Signed-off-by: Stefan Schake
> >> ---
> >> drivers/gpu/drm/vc4/vc4_drv.h | 6 ++
> >> drivers/gpu/drm/vc4/vc4_plane.c | 15 ++-
> >> 2 files changed, 20 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> >> index fefa166..7cc6390 100644
> >> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> >> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> >> @@ -302,6 +302,12 @@ struct vc4_hvs {
> >>
> >> struct vc4_plane {
> >>struct drm_plane base;
> >> +
> >> + /* Set when the plane has per-pixel alpha content or does not cover
> >> + * the entire screen. This is a hint to the CRTC that it might need
> >> + * to enable background color fill.
> >> + */
> >> + bool needs_bg_fill;
> >
> > Looks to me like that should really be a bitmask (or something similar)
> > in the crtc state.
>
> Why?
>
> In particular, VC4 really doesn't have a fixed number of planes, and the
> fact that we're exposing just a handful so far is probably a bug.
The problem is that this seems to clobber the device state from the
.atomic_check() hook. So if you do a CHECK_ONLY atomic ioctl (or
some later check simply fails and the operation is aborted) you've
already modified the state of the device, and some later operation
may then end up doing the wrong thing.
I guess you could track this in the plane struct like here, but as
with the actual hardware state that shouldn't get modified until
we're sure the checked state is really meant to be commited to the
hardware.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/amdgpu: explicit give BO type to amdgpu_bo_create
On 2018-03-07 04:16 AM, Christian König wrote:
> Am 06.03.2018 um 22:29 schrieb Felix Kuehling:
>> NAK.
>>
>> For KFD we need the ability to create a BO from an SG list that doesn't
>> come from another BO. We use this for mapping pages from the doorbell
>> aperture into GPUVM for GPU self-dispatch.
> You can still do this, see amdgpu_gem_prime_import_sg_table.
>
> Just set the BO type to SG and then setting the SG table after
> creating it:
>> ret = amdgpu_bo_create(adev, attach->dmabuf->size, PAGE_SIZE,
>> AMDGPU_GEM_DOMAIN_CPU, 0, ttm_bo_type_sg,
>> resv, &bo);
>> if (ret)
>> goto error;
>> bo->tbo.sg = sg;
>> bo->tbo.ttm->sg = sg;
>
> Then validate the result into the GTT domain to actually use the SG
> table.
OK, I'll try implementing that before we merge your change.
>
> BTW: How do you create an SG table for the doorbell?
KFD manages the doorbell aperture and assigns one or two pages of
doorbells to each process. KFD knows the bus address of the doorbells
and passes it to amdgpu, which creates the SG like this:
static struct sg_table *create_doorbell_sg(uint64_t addr, uint32_t size)
{
struct sg_table *sg = kmalloc(sizeof(*sg), GFP_KERNEL);
if (!sg)
return NULL;
if (sg_alloc_table(sg, 1, GFP_KERNEL)) {
kfree(sg);
return NULL;
}
sg->sgl->dma_address = addr;
sg->sgl->length = size;
#ifdef CONFIG_NEED_SG_DMA_LENGTH
sg->sgl->dma_length = size;
#endif
return sg;
}
Regards,
Felix
>
> Regards,
> Christian.
>
>>
>> If you remove this now, I'll need to add it back in some form in a month
>> or two when I get to that part of upstreaming KFD.
>>
>> There may be other ways to implement this. Currently we need to create a
>> BO for anything we want to map into a GPUVM page table, because the
>> amdgpu_vm code is based around BOs. If there was a way to map physical
>> addresses into GPUVM without creating a buffer object, that would
>> work too.
>>
>> Regards,
>> Felix
>>
>>
>> On 2018-03-06 09:43 AM, Christian König wrote:
>>> Drop the "kernel" and sg parameter and give the BO type to create
>>> explicit to amdgpu_bo_create instead of figuring it out from the
>>> parameters.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 5 +--
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 8 ++---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 7 ++--
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++--
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 46
>>> +++
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 11 +++
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 7 ++--
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 11 +++
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
>>> 11 files changed, 58 insertions(+), 64 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> index 292c7e72820c..b1116b773516 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> @@ -441,7 +441,7 @@ struct amdgpu_sa_bo {
>>> void amdgpu_gem_force_release(struct amdgpu_device *adev);
>>> int amdgpu_gem_object_create(struct amdgpu_device *adev, unsigned
>>> long size,
>>> int alignment, u32 initial_domain,
>>> - u64 flags, bool kernel,
>>> + u64 flags, enum ttm_bo_type type,
>>> struct reservation_object *resv,
>>> struct drm_gem_object **obj);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>>> index 450426dbed92..7f096ed6e83d 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
>>> @@ -215,8 +215,9 @@ int alloc_gtt_mem(struct kgd_dev *kgd, size_t size,
>>> if ((*mem) == NULL)
>>> return -ENOMEM;
>>> - r = amdgpu_bo_create(adev, size, PAGE_SIZE, true,
>>> AMDGPU_GEM_DOMAIN_GTT,
>>> - AMDGPU_GEM_CREATE_CPU_GTT_USWC, NULL, NULL,
>>> &(*mem)->bo);
>>> + r = amdgpu_bo_create(adev, size, PAGE_SIZE, AMDGPU_GEM_DOMAIN_GTT,
>>> + AMDGPU_GEM_CREATE_CPU_GTT_USWC, ttm_bo_type_kernel,
>>> + NULL, &(*mem)->bo);
>>> if (r) {
>>> dev_err(adev->dev,
>>> "failed to allocate BO for amdkfd (%d)\n", r);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
>>> index 2fb299afc12b..02b849be083b 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
>>> @@ -80,8 +80,8 @@ stati
Re: [PATCH 0/3] Analogix DP fixes for Chromebook2 Peach-Pit (Exynos5420)
On 05.03.2018 09:57, Marek Szyprowski wrote: > Hi! > > Last week I was asked to comment a patch "[PATCH v3 05/43] drm/bridge: > analogix_dp: Don't power bridge in analogix_dp_bind": > https://patchwork.kernel.org/patch/10193493/ > > That patch does almost the opposite to my initial fix "[PATCH v2] > drm/bridge: analogix_dp: Keep PHY powered between driver bind/unbind": > https://patchwork.kernel.org/patch/10242493/ > > I did some further investigation based on the proposed "[PATCH v3 00/43] DRM > Rockchip rk3399 (Kevin)" patchset: > https://lists.freedesktop.org/archives/dri-devel/2018-March/167775.html > > Those patches seems to solve also some issues with analogix_dp driver on > Exynos5420 based Chromebook2 Peach-PIT board. > > I didn't get any reply for my comments and unfortunately the mail of > Thierry Escande, who submitted that patchset is no longer valid, so I > decided to resend the minimal patchset that fixes the issue with > Chromebook2 Peach-Pit board, which was broken since v4.10 kernel release. > > If possible, please apply them as fixes for v4.16-rc. > > This patchset replaces my previous fix: > https://patchwork.kernel.org/patch/10242493/ > > Best regards > Marek Szyprowski > Samsung R&D Institute Poland > > > Patch summary: > > Marek Szyprowski (2): > drm/bridge: analogix_dp: Postpone enabling runtime power management > drm/bridge: analogix_dp: Don't create useless connectors > > zain wang (1): > drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind Applied to drm-misc-next. Could not apply to drm-misc-fixes since patchset depends on patches from drm-misc-next. Regards Andrzej > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 45 > +- > drivers/gpu/drm/exynos/exynos_dp.c | 1 + > include/drm/bridge/analogix_dp.h | 1 + > 3 files changed, 21 insertions(+), 26 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/vc4: Check if plane requires background fill
Ville Syrjälä writes:
> On Tue, Mar 06, 2018 at 04:10:33PM -0800, Eric Anholt wrote:
>> Ville Syrjälä writes:
>>
>> > On Tue, Mar 06, 2018 at 02:48:38AM +0100, Stefan Schake wrote:
>> >> Considering a single plane only, we have to enable background color
>> >> when the plane has an alpha format and could be blending from the
>> >> background or when it doesn't cover the entire screen.
>> >>
>> >> Signed-off-by: Stefan Schake
>> >> ---
>> >> drivers/gpu/drm/vc4/vc4_drv.h | 6 ++
>> >> drivers/gpu/drm/vc4/vc4_plane.c | 15 ++-
>> >> 2 files changed, 20 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
>> >> index fefa166..7cc6390 100644
>> >> --- a/drivers/gpu/drm/vc4/vc4_drv.h
>> >> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
>> >> @@ -302,6 +302,12 @@ struct vc4_hvs {
>> >>
>> >> struct vc4_plane {
>> >> struct drm_plane base;
>> >> +
>> >> + /* Set when the plane has per-pixel alpha content or does not cover
>> >> + * the entire screen. This is a hint to the CRTC that it might need
>> >> + * to enable background color fill.
>> >> + */
>> >> + bool needs_bg_fill;
>> >
>> > Looks to me like that should really be a bitmask (or something similar)
>> > in the crtc state.
>>
>> Why?
>>
>> In particular, VC4 really doesn't have a fixed number of planes, and the
>> fact that we're exposing just a handful so far is probably a bug.
>
> The problem is that this seems to clobber the device state from the
> .atomic_check() hook. So if you do a CHECK_ONLY atomic ioctl (or
> some later check simply fails and the operation is aborted) you've
> already modified the state of the device, and some later operation
> may then end up doing the wrong thing.
>
> I guess you could track this in the plane struct like here, but as
> with the actual hardware state that shouldn't get modified until
> we're sure the checked state is really meant to be commited to the
> hardware.
Oh, I hadn't noticed it was in vc4_plane, not vc4_plane_state. Yeah, it
should be in the plane state.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, Fixes for 2 regressions that got captured by CI. Here goes drm-intel-fixes-2018-03-07: - 2 fixes: 1 for perf and 1 execlist submission race. Thanks, Rodrigo. The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1: Linux 4.16-rc4 (2018-03-04 14:54:11 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-03-07 for you to fetch changes up to 88d3dfb6a69042381161290c7ce19e1f53fc2a66: drm/i915: Suspend submission tasklets around wedging (2018-03-05 16:08:31 -0800) - 2 fixes: 1 for perf and 1 execlist submission race. Chris Wilson (1): drm/i915: Suspend submission tasklets around wedging Lionel Landwerlin (1): drm/i915/perf: fix perf stream opening lock drivers/gpu/drm/i915/i915_gem.c | 6 +- drivers/gpu/drm/i915/i915_perf.c | 40 +--- drivers/gpu/drm/i915/intel_lrc.c | 5 + 3 files changed, 23 insertions(+), 28 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info
On Tue, Mar 06, 2018 at 01:32:21PM -0500, Harry Wentland wrote:
>
>
> On 2018-03-06 12:13 PM, Daniel Vetter wrote:
> > On Tue, Mar 06, 2018 at 11:23:23AM -0500, Harry Wentland wrote:
> >> On 2018-03-06 07:18 AM, Ville Syrj??l?? wrote:
> >>> On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote:
> On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote:
> > From: Ville Syrj??l??
> >
> > edid and display_info are protected by mode_config.mutex. Add lockdep
> > asserts to make sure we're not accessing things w/o the lock.
> >
> > FIXME: pretty sure this will blow up with amdgpu as they seem
> > to be doing edid updates even from the modeset path. Need to figure
> > out what to do about that. Maybe protect the edid/display info with
> > with connection_mutex instead of mode_config.mutex?
>
> Imo not doing EDID udpates from the modeset path is the right fix. I
> can't
> think of any reasonable reason to do that at least. Can you point me at
> the relevant amdgpu code pls (I'm lazy, sry)?
> >>>
> >>> It was some MST thing I believe... (should have written it down)
> >>>
> >>> amdgpu_dm_atomic_check() -> dm_update_crtcs_state() ->
> >>> create_stream_for_sink() -> dm_dp_mst_dc_sink_create() ->
> >>> get_edid/update_edid_property
> >>>
> >>
> >> Yeah, it's because the dc_sink carries the EDID and is only created at
> >> this point for us. It's bugged me ever since we did this. Might be time
> >> to think of a solution to it now.
> >
> > But how does this work? Userspace won't do a modeset without the EDID
> > present and the modes listed, which means you'll never ever end up in
> > atomic check. This really sounds rather wrong.
> >
>
> Not sure if this works correctly with atomic userspace.
>
> I think with legacy userspace we might rely on the get_connector call
> doing .fill_modes > drm_helper_probe_single_connector_modes > .get_modes
> > dm_dp_mst_get_modes > drm_dp_mst_get_edid
Atomic userspace users the exact same ioctls for connector probing, no
change there.
That leaves me wondering why exactly you're doing this in atomic_check.
Just nuke it?
-Daniel
>
> Harry
>
>
> > Only idea I can come up with is that you're abusing the regular pageflip
> > request as a worker thread, but that's some seriously backwards design.
> > -Daniel
> >
> >>
> >> Harry
> >>
>
> Otherwise I think this is a real good patch.
>
> Thanks, Daniel
>
> >
> > Cc: Keith Packard
> > Cc: Daniel Vetter
> > Cc: Harry Wentland
> > Signed-off-by: Ville Syrj??l??
> > ---
> > drivers/gpu/drm/drm_connector.c| 4
> > drivers/gpu/drm/drm_edid.c | 2 ++
> > drivers/gpu/drm/drm_probe_helper.c | 2 +-
> > 3 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 122060792b6f..a9f3536f4e94 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1374,6 +1374,8 @@ int
> > drm_mode_connector_update_edid_property(struct drm_connector *connector,
> > size_t size = 0;
> > int ret;
> >
> > + lockdep_assert_held(&dev->mode_config.mutex);
> > +
> > /* ignore requests to set edid when overridden */
> > if (connector->override_edid)
> > return 0;
> > @@ -1770,6 +1772,8 @@ void drm_connector_reset_display_info(struct
> > drm_connector *connector)
> > {
> > struct drm_display_info *info = &connector->display_info;
> >
> > + lockdep_assert_held(&connector->dev->mode_config.mutex);
> > +
> > memset(info, 0, sizeof(*info));
> > }
> > EXPORT_SYMBOL_GPL(drm_connector_reset_display_info);
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 618093c4a039..7f9e9236114b 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4440,6 +4440,8 @@ u32 drm_add_display_info(struct drm_connector
> > *connector, const struct edid *edi
> > struct drm_display_info *info = &connector->display_info;
> > u32 quirks = edid_get_quirks(edid);
> >
> > + lockdep_assert_held(&connector->dev->mode_config.mutex);
> > +
> > info->width_mm = edid->width_cm * 10;
> > info->height_mm = edid->height_cm * 10;
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 7dc7e635d7e4..2a2afcf72788 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -400,7 +400,7 @@ int drm_helper_probe_single_connector_modes(struct
> > drm_connector *connector,
> > enum drm_connector_status old_status;
> > struct drm_m
Re: [PATCH libdrm] omap: add Android build support
On 03/02/2018 12:51 PM, Emil Velikov wrote: > On 28 February 2018 at 18:54, Andrew F. Davis wrote: >> From: Gowtham Tammana >> >> Add Android.mk file to build libdrm_omap library. >> > Zero objections on my end, but can we have the use case mentioned in > the commit message. > Years ago I was looking for users of the library and I could not find any. > We use it in some older versions of our hardware composer for Android and our user-space graphics stack, but the goal will be to reduce or eliminate our dependence on the libdrm_omap specifics if we can. So I don't have any public users right now. Andrew > -Emil > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: New KFD ioctls: taking the skeletons out of the closet
On Wed, Mar 07, 2018 at 09:38:03AM +0100, Christian K??nig wrote: > Am 07.03.2018 um 00:09 schrieb Dave Airlie: > > On 7 March 2018 at 08:44, Felix Kuehling wrote: > > > Hi all, > > > > > > Christian raised two potential issues in a recent KFD upstreaming code > > > review that are related to the KFD ioctl APIs: > > > > > > 1. behaviour of -ERESTARTSYS > > > 2. transactional nature of KFD ioctl definitions, or lack thereof > > > > > > I appreciate constructive feedback, but I also want to encourage an > > > open-minded rather than a dogmatic approach to API definitions. So let > > > me take all the skeletons out of my closet and get these APIs reviewed > > > in the appropriate forum before we commit to them upstream. See the end > > > of this email for reference. > > > > > > The controversial part at this point is kfd_ioctl_map_memory_to_gpu. If > > > any of the other APIs raise concerns or questions, please ask. > > > > > > Because of the HSA programming model, KFD memory management APIs are > > > synchronous. There is no pipelining. Command submission to GPUs through > > > user mode queues does not involve KFD. This means KFD doesn't know what > > > memory is used by the GPUs and when it's used. That means, when the > > > map_memory_to_gpu ioctl returns to user mode, all memory mapping > > > operations are complete and the memory can be used by the CPUs or GPUs > > > immediately. > > I've got a few opinions, but first up I still dislike user-mode queues > > and everything > > they entail. I still feel they are solving a Windows problem and not a > > Linux problem, > > and it would be nice if we had some Linux numbers on what they gain us over > > a dispatch ioctl, because they sure bring a lot of memory management issues. > > Well user-mode queues are a problem as long as you don't have recoverable > page faults on the GPU. > > As soon as you got recoverable page faults and push the memory management > towards things like HMM I don't see an advantage of using a IOCTL based > command submission any more. > > So I would say that this is a problem which is slowly going away as the > hardware improves. Yeah, but up to the point where the hw actually works (instead of promises that maybe it'll work next generation, trust us, for like a few generations) it's much easier to hack up an ioctl with workarounds than intercepting an mmap write fault all the time (those are slower than ioctls). I think userspace queues are fine once we have known-working hw. Before that I'm kinda agreeing with Dave and not seeing the point. At least to my knowledge we still haven't arrived in the wonderful promised land of hw recoverable (well, restartable really) page faults on any vendors platform ... > > That said amdkfd is here. > > > > The first question you should ask (which you haven't asked here at all) is > > what should userspace do with the ioctl result. > > > > > HSA also uses a shared virtual memory model, so typically memory gets > > > mapped on multiple GPUs and CPUs at the same virtual address. > > > > > > The point of contention seems to be the ability to map memory to > > > multiple GPUs in a single ioctl and the behaviour in failure cases. I'll > > > discuss two main failure cases: > > > > > > 1: Failure after all mappings have been dispatched via SDMA, but a > > > signal interrupts the wait for completion and we return -ERESTARTSYS. > > > Documentation/kernel-hacking/hacking.rst only says "[...] you should be > > > prepared to process the restart, e.g. if you're in the middle of > > > manipulating some data structure." I think we do that by ensuring that > > > memory that's already mapped won't be mapped again. So the restart will > > > become a no-op and just end up waiting for all the previous mappings to > > > complete. > > -ERESTARTSYS at that late stage points to a badly synchronous API, > > I'd have said you should have two ioctls, one that returns a fence after > > starting the processes, and one that waits for the fence separately. > > That is exactly what I suggested as well, but also exactly what Felix tries > to avoid :) > > > The overhead of ioctls isn't your enemy until you've measured it and > > proven it's a problem. > > > > > Christian has a stricter requirement, and I'd like to know where that > > > comes from: "An interrupted IOCTL should never have a visible effect." > > Christian might be taking things a bit further but synchronous gpu access > > APIs are bad, but I don't think undoing a bunch of work is a good plan > > either > > just because you got ERESTARTSYS. If you get ERESTARTSYS can you > > handle it, if I've fired off 5 SDMAs and wait for them will I fire off 5 > > more? > > will I wait for the original SDMAs if I reenter? > > Well it's not only the waiting for the SDMAs. If I understood it correctly > the IOCTL proposed by Felix allows adding multiple mappings of buffer > objects on multiple devices with just one IOCTL. > > Now the problem is without a lot o
Re: [PATCH libdrm] drm/atomic: Refuse to add invalid objects to requests
On Wed, Mar 07, 2018 at 12:42:15PM +, Daniel Stone wrote:
> Object and property IDs cannot be zero. Prevent them from being added to
> the request stream at all, rather than breaking at commit time.
>
> Signed-off-by: Daniel Stone
> ---
> xf86drmMode.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 15957ffc..bd59ef25 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -1313,6 +1313,9 @@ int drmModeAtomicAddProperty(drmModeAtomicReqPtr req,
> if (!req)
> return -EINVAL;
>
> + if (object_id == 0 || property_id == 0)
> + return -EINVAL;
Reviewed-by: Daniel Vetter
... and gives us a perfect spot to gdb into a backtrace and figure out wtf
is going on with drm_hwc :-)
-Daniel
> +
> if (req->cursor >= req->size_items) {
> drmModeAtomicReqItemPtr new;
>
> --
> 2.14.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105369] HP HP ENVY x360, amdgpu, Call Trace tgn10_lock at startup, VMC page fault during runtime
https://bugs.freedesktop.org/show_bug.cgi?id=105369 --- Comment #6 from cd --- Created attachment 137867 --> https://bugs.freedesktop.org/attachment.cgi?id=137867&action=edit journalctl-amd-drm-staging.txt I hope I took the correct version, 4.16.0-rc1-085145ebf0e9 The screen freezes with the boot log, no further output is shown and gdm is constantly trying to launch. I enclosed the complete journalctl -b -1, only removed the constant retry of gdm. -- 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 105369] HP HP ENVY x360, amdgpu, Call Trace tgn10_lock at startup, VMC page fault during runtime
https://bugs.freedesktop.org/show_bug.cgi?id=105369 --- Comment #7 from Alex Deucher --- It looks like you built the driver without DC or DCN support. Please make sure the following are set in your .config: CONFIG_DRM_AMD_DC=y CONFIG_DRM_AMD_DC_DCN1_0=y -- 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
[PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node
The #sound-dai-cells DT property is required to describe link between
the HDMI IP block and the SoC's audio subsystem.
Signed-off-by: Sylwester Nawrocki
---
Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
index 8715ff06c457..6b2a526ec586 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
@@ -50,6 +50,9 @@ Required properties for Exynos 5433:
- clock-names: aliases for above clock specfiers.
- samsung,sysreg: handle to syscon used to control the system registers.
+Optional properties for Exynos 4210, 4212, 5420 and 5433:
+ - #sound-dai-cells: should be 0.
+
Example:
hdmi {
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] DT: display: renesas, du: document R8A77970 bindings
Hi Sergei, Thank you for the patch. On Thursday, 18 January 2018 23:05:58 EET Sergei Shtylyov wrote: > Document the R-Car V3M (R8A77970) SoC in the R-Car DU bindings. > > Signed-off-by: Sergei Shtylyov Reviewed-by: Laurent Pinchart and applied to my tree with the subject prefixed changed per Rob's request. > --- > Changes in version 2: > - documented R8A77970 DU ports; > - patch split from the main R8A77970 DU support patch. > > Documentation/devicetree/bindings/display/renesas,du.txt |2 ++ > 1 file changed, 2 insertions(+) > > Index: linux/Documentation/devicetree/bindings/display/renesas,du.txt > === > --- linux.orig/Documentation/devicetree/bindings/display/renesas,du.txt > +++ linux/Documentation/devicetree/bindings/display/renesas,du.txt > @@ -13,6 +13,7 @@ Required Properties: > - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU > - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU > - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU > +- "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU > >- reg: A list of base address and length of each memory resource, one for > each entry in the reg-names property. > @@ -63,6 +64,7 @@ corresponding to each DU output. > R8A7794 (R-Car E2) DPAD 0 DPAD 1 - - > R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0 > R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 - > + R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - - > > > Example: R8A7795 (R-Car H3) ES2.0 DU -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: rcar-du: add R8A77970 support
Hi Sergei,
Thank you for the patch.
On Thursday, 18 January 2018 23:05:59 EET Sergei Shtylyov wrote:
> Add support for the R-Car V3M (R8A77970) SoC to the R-Car DU driver.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Laurent Pinchart
and applied to my tree.
> ---
> Changes in version 2:
> - removed the 'model' and 'dpll_ch' field initializers;
> - fixed up the DU port numbers;
> - split the DU bindings and the LVDS driver updates into a separate patches;
> - removed the check before the DPTSR write (to be done in a separate
> patch).
>
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 +
> 1 file changed, 21 insertions(+)
>
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -249,6 +249,26 @@ static const struct rcar_du_device_info
> .dpll_ch = BIT(1),
> };
>
> +static const struct rcar_du_device_info rcar_du_r8a77970_info = {
> + .gen = 3,
> + .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> + | RCAR_DU_FEATURE_EXT_CTRL_REGS
> + | RCAR_DU_FEATURE_VSP1_SOURCE,
> + .num_crtcs = 1,
> + .routes = {
> + /* R8A77970 has one RGB output and one LVDS output. */
> + [RCAR_DU_OUTPUT_DPAD0] = {
> + .possible_crtcs = BIT(0),
> + .port = 0,
> + },
> + [RCAR_DU_OUTPUT_LVDS0] = {
> + .possible_crtcs = BIT(0),
> + .port = 1,
> + },
> + },
> + .num_lvds = 1,
> +};
> +
> static const struct of_device_id rcar_du_of_table[] = {
> { .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
> { .compatible = "renesas,du-r8a7745", .data = &rzg1_du_r8a7745_info },
> @@ -260,6 +280,7 @@ static const struct of_device_id rcar_du
> { .compatible = "renesas,du-r8a7794", .data = &rcar_du_r8a7794_info },
> { .compatible = "renesas,du-r8a7795", .data = &rcar_du_r8a7795_info },
> { .compatible = "renesas,du-r8a7796", .data = &rcar_du_r8a7796_info },
> + { .compatible = "renesas,du-r8a77970", .data = &rcar_du_r8a77970_info },
> { }
> };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] Aspirant for GSOC 2018 for Nouveau Vulkan driver
I would be willing to be a mentor for this project. On Wed, Mar 7, 2018 at 1:45 PM, Martin Peres wrote: > Hi Anusha, > > Sorry, I was under the expectation that userspace developers would > answer you after your first message, and I missed your second one! My > sincere apologies. > > Generally, the process is that the student should research the topic by > first asking questions to developers about the effort, then they would > make their own plan. Then you would present this plan while looking for > a mentor. > > Of course, you can expect help from the community in order to better > understand what needs to be done, but don't expect to be given a > detailed plan, just pointers. > > Sorry again for my lack of feedback, > Martin > > On 07/03/18 05:53, Anusha Srivastava wrote: >> Hi, >> >> I am not been able to contact with mentor of this project. >> Can someone else from the community help me with this ? >> >> >> Regards, >> Anusha Srivastava >> >> >> On 3 March 2018 at 11:16, Anusha Srivastava wrote: >>> Hi Martin, >>> >>> Any update on this ? >>> Regards, >>> Anusha Srivastava >>> >>> >>> On 28 February 2018 at 23:37, Anusha Srivastava >>> wrote: Hi, I would like to participate in GSOC 2018 with Xorg to contribute to project "Initial Nouveau Vulkan driver' I would need some help in how to get started with the same. Regards, Anusha Srivastava > > ___ > Nouveau mailing list > nouv...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] drm/atomic: Refuse to add invalid objects to requests
On 7 March 2018 at 16:42, Daniel Vetter wrote: > On Wed, Mar 07, 2018 at 12:42:15PM +, Daniel Stone wrote: >> Object and property IDs cannot be zero. Prevent them from being added to >> the request stream at all, rather than breaking at commit time. > > Reviewed-by: Daniel Vetter > > ... and gives us a perfect spot to gdb into a backtrace and figure out wtf > is going on with drm_hwc :-) Heh, and pushed now. Thanks Daniel! Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces
On Thu, Feb 22, 2018 at 04:16:52PM -0500, Alex Deucher wrote: > On Thu, Feb 22, 2018 at 1:49 PM, Bas Nieuwenhuizen > wrote: > > On Thu, Feb 22, 2018 at 7:04 PM, Kristian H??gsberg > > wrote: > >> On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher wrote: > >> > >>> On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace > >> wrote: > >>> > On Thu 21 Dec 2017, Daniel Vetter wrote: > >>> >> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen < > >> hoegsb...@google.com> wrote: > >>> >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico < > >> mvicom...@nvidia.com> wrote: > >>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian H??gsberg < > >> hoegsb...@gmail.com> wrote: > >>> > I'd like to see concrete examples of actual display controllers > >>> > supporting more format layouts than what can be specified with a 64 > >>> > bit modifier. > >>> > >>> The main problem is our tiling and other metadata parameters can't > >>> generally fit in a modifier, so we find passing a blob of metadata a > >>> more suitable mechanism. > >>> >>> > >>> >>> I understand that you may have n knobs with a total of more than a > >> total of > >>> >>> 56 bits that configure your tiling/swizzling for color buffers. What > >> I don't > >>> >>> buy is that you need all those combinations when passing buffers > >> around > >>> >>> between codecs, cameras and display controllers. Even if you're > >> sharing > >>> >>> between the same 3D drivers in different processes, I expect just > >> locking > >>> >>> down, say, 64 different combinations (you can add more over time) and > >>> >>> assigning each a modifier would be sufficient. I doubt you'd extract > >>> >>> meaningful performance gains from going all the way to a blob. > >>> > > >>> > I agree with Kristian above. In my opinion, choosing to encode in > >>> > modifiers a precise description of every possible tiling/compression > >>> > layout is not technically incorrect, but I believe it misses the point. > >>> > The intention behind modifiers is not to exhaustively describe all > >>> > possibilites. > >>> > > >>> > I summarized this opinion in VK_EXT_image_drm_format_modifier, > >>> > where I wrote an "introdution to modifiers" section. Here's an excerpt: > >>> > > >>> > One goal of modifiers in the Linux ecosystem is to enumerate for > >> each > >>> > vendor a reasonably sized set of tiling formats that are > >> appropriate for > >>> > images shared across processes, APIs, and/or devices, where each > >>> > participating component may possibly be from different vendors. > >>> > A non-goal is to enumerate all tiling formats supported by all > >> vendors. > >>> > Some tiling formats used internally by vendors are inappropriate for > >>> > sharing; no modifiers should be assigned to such tiling formats. > >> > >>> Where it gets tricky is how to select that subset? Our tiling mode > >>> are defined more by the asic specific constraints than the tiling mode > >>> itself. At a high level we have basically 3 tiling modes (out of 16 > >>> possible) that would be the minimum we'd want to expose for gfx6-8. > >>> gfx9 uses a completely new scheme. > >>> 1. Linear (per asic stride requirements, not usable by many hw blocks) > >>> 2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick) > >>> 3. 2D Thin (1D tiling constraints, plus pipe config (18 possible), > >>> tile split (7 possible), sample split (4 possible), num banks (4 > >>> possible), bank width (4 possible), bank height (4 possible), macro > >>> tile aspect (4 possible) all of which are asic config specific) > >> > >>> I guess we could do something like: > >>> AMD_GFX6_LINEAR_ALIGNED_64B > >>> AMD_GFX6_LINEAR_ALIGNED_256B > >>> AMD_GFX6_LINEAR_ALIGNED_512B > >>> AMD_GFX6_1D_THIN_DISPLAY > >>> AMD_GFX6_1D_THIN_DEPTH > >>> AMD_GFX6_1D_THIN_ROTATED > >>> AMD_GFX6_1D_THIN_THIN > >>> AMD_GFX6_1D_THIN_THICK > >> > >> AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > >> > >> AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > >> > >> AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > >> > >> AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > >> > >> AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > >> > >> AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > >> > >> AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1 > >> > >> AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_
[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume
https://bugzilla.kernel.org/show_bug.cgi?id=199047 --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Are you using DC? Please attach your dmesg output. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] R-Car DU changes for v4.17
Hi Dave, Please pull the R-Car DU changes for v4.17. This contains - Convert LVDS support to a drm_bridge driver - Add DT bindings for the R8A77995 SoC - Add DT bindings and driver support for the R8A77970 SoC Note that the LVDS conversion depends on a patch series from Frank Rowand that will make it upstream through Rob Herring's tree. Frank has provided a stable branch based on v4.16-rc1 with the patches, and both Rob and I have merged it into our trees. This should thus generate no conflict when reaching -next. The following changes since commit f073d78eeb8efd85718e611c15f9a78647751dea: Merge tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/ drm-intel into drm-next (2018-03-01 14:07:22 +1000) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git drm/next/du for you to fetch changes up to 77f59f895da2fe5526073181c74c3fb85a7c80d1: dt-bindings: display: renesas: lvds: Document r8a77995 bindings (2018-03-07 19:30:11 +0200) Frank Rowand (5): x86: devicetree: fix config option around x86_flattree_get_config() of: change overlay apply input data from unflattened to FDT of: Documentation: of_overlay_apply() replaced by of_overlay_fdt_apply() of: convert unittest overlay devicetree source to sugar syntax of: improve reporting invalid overlay target path Kieran Bingham (2): dt-bindings: display: renesas: du: Document r8a77995 bindings dt-bindings: display: renesas: lvds: Document r8a77995 bindings Laurent Pinchart (5): Merge tag 'overlay_apply_fdt_v7-for-4.17' of git://git.kernel.org/.../ frowand/linux into drm/next/du dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings drm: rcar-du: Fix legacy DT to create LVDS encoder nodes drm: rcar-du: Convert LVDS encoder code to bridge driver Sergei Shtylyov (4): dt-bindings: display: renesas: du: Document R8A77970 bindings dt-bindings: display: renesas: lvds: Document R8A77970 bindings drm: rcar-du: Add R8A77970 support drm: rcar-du: lvds: Add R8A77970 support .../devicetree/bindings/display/bridge/renesas,lvds.txt | 58 +++ .../devicetree/bindings/display/renesas,du.txt | 35 +- Documentation/devicetree/overlay-notes.txt | 4 +- MAINTAINERS | 1 + arch/x86/kernel/devicetree.c| 2 +- drivers/gpu/drm/rcar-du/Kconfig | 6 +- drivers/gpu/drm/rcar-du/Makefile| 10 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 42 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 - drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +--- drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 12 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 14 +- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 93 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 24 -- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 238 --- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 64 --- drivers/gpu/drm/rcar-du/rcar_du_of.c| 322 + drivers/gpu/drm/rcar-du/rcar_du_of.h| 20 + drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts | 76 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts | 50 +++ drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts | 50 +++ drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts | 50 +++ drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts | 50 +++ drivers/gpu/drm/rcar-du/rcar_lvds.c | 540 +++ drivers/of/Kconfig | 1 + drivers/of/overlay.c| 134 +- drivers/of/resolver.c | 6 - drivers/of/unittest-data/Makefile | 28 +- drivers/of/unittest-data/overlay.dts| 101 ++--- drivers/of/unittest-data/overlay_0.dts | 14 + drivers/of/unittest-data/overlay_1.dts | 14 + drivers/of/unittest-data/overlay_10.dts | 27 ++ drivers/of/unittest-data/overlay_11.dts | 28 ++ drivers/of/unittest-data/overlay_12.dts | 14 + drivers/of/unittest-data/overlay_13.dts | 14 + drivers/of/unittest-data/overlay_15.dts | 30 ++ drivers/of/unittest-data/overlay_2.dts | 9 + drivers/of/unittest-data/overlay_3.dts | 9 + drivers/of/unittest-data/overlay_4.dts | 18 + drivers/of/unittest-data/overlay_5.dts | 9 + drivers/of/unittest-data/overlay_6.dts | 10 + drivers/
[Bug 104932] Hang when running X11/Wayland on GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's DC-Patches-Jan-31-2018.mbox applied)
https://bugs.freedesktop.org/show_bug.cgi?id=104932 Robin Kauffman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Robin Kauffman --- Hi Again- Well, after (repeatedly) breaking the Law of Sysadminning (changing more than one thing at a time), and upgrading userland (including, but sadly not limited to, the 3D stack) as well as the kernel, I have a working desktop, and what little I can divine from where I ended up is that it may well *not* have been RadeonSI/libdrm/AMDGPU at fault to begin with (almost labeled the resolution NOTOURBUG, but the probability that there might have been some slight issue with things actually pertaining to the RadeonSI/AMDGPU graphics driver is to my mind nonzero, even if scant). I unfortunately neglected to bisect the kernel driver (or parts of userland) to see if I could get things working by going back in time and seeing if there was some commit somewhere that broke things (at least for my already-rickety userland). Such a commit may well exist, but going back to try to find it would be a lengthy endeavor, and given that things more-or-less work for me now, the motivation for doing so has all but dried up. If someone wants to follow-up with a likely cause for the kernel complaint I *did* see earlier, by all means do so, but I have a sneaking suspicion that I likely made things Not Work by having a haphazard and semi-out-of-date userland (in this case, *outside* of libdrm/LLVM/Clang/Mesa/etc). Thanks, and apologies for any time sunk on anyone else's behalf trying to suss this one out. -Robin K. -- 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 105386] Request for a new fd.o account
https://bugs.freedesktop.org/show_bug.cgi?id=105386 Bug ID: 105386 Summary: Request for a new fd.o account Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: antonio.argenzi...@intel.com Created attachment 137868 --> https://bugs.freedesktop.org/attachment.cgi?id=137868&action=edit PGP & SSH PUBLIC KEY Request for a new account for: Name: Antonio Argenziano email addr: antonio.argenzi...@intel.com preferred account name: aargenzi Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/pl111: Enable device-specific assigned memory
Linus Walleij writes:
> The Versatile Express has 8 MB of dedicated video RAM (VRAM)
> on the motherboard, which is what we should be using for the
> PL111 if available. On this platform, the memory backplane
> is constructed so that only this memory will work properly
> with the CLCD on the motherboard, using any other memory
> region just gives random snow on the display.
>
> The CA9 Versatile Express also has a PL111 instance on its
> core tile. This is OK, it has been tested with the motherboard
> VRAM and that works just as fine as regular CMA memory.
>
> The memory is assigned to the device using the memory-region
> device tree property and a "shared-dma-pool" reserved
> memory pool like this:
>
> reserved-memory {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> vram: vram@4800 {
> compatible = "shared-dma-pool";
> reg = <0x4800 0x0080>;
> no-map;
> };
> };
>
> clcd@1f000 {
> compatible = "arm,pl111", "arm,primecell";
> (...)
> memory-region = <&vram>;
> }·;
>
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Signed-off-by: Linus Walleij
> ---
> drivers/gpu/drm/pl111/pl111_drv.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
> b/drivers/gpu/drm/pl111/pl111_drv.c
> index b469aa317d9d..e301f2a719a3 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -60,6 +60,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -262,6 +263,10 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
> drm->dev_private = priv;
> priv->variant = variant;
>
> + ret = of_reserved_mem_device_init(dev);
> + if (!ret)
> + dev_info(dev, "using device-specific reserved memory\n");
> +
> if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
>&priv->memory_bw)) {
> dev_info(dev, "no max memory bandwidth specified, assume
> unlimited\n");
> --
> 2.14.3
It looks like you'll want a matching of_reserved_mem_device_release() at
remove / dev_unref time.
This will still allow BO imports from non-reserved memory, I think.
Should we just error out of import_sg_table() on this platform?
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 00/60] omapdrm: Reverse direction of DSS device (dis)connect operations
Hi Tomi,
On Wednesday, 7 March 2018 16:11:04 EET Tomi Valkeinen wrote:
> On 07/03/18 02:24, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch series is a first step towards moving the omapdrm driver away
> > from the custom bridge and panel drivers to drm_bridge and drm_panel.
> >
> > The main blocker to transition to drm_bridge and drm_panel is the
> > direction of the bridge operations. While the omapdrm driver manages its
> > components from sink to source (panel to DSS output), the drm_bridge API
> > is manages bridges in the source to sink direction. This makes the two
> > models incompatible, and requires reversing the direction of operations
> > inside omapdrm.
> >
> > Don't rejoice too fast, we're still far from a complete transition, but
> > this first step paves the way by reworking the driver's internals to make
> > source to sink order possible. It then transitions the connect and
> > disconnect operations (the omapdrm equivalent of the drm_bridge attach
> > and detach operations) to the new direction.
> >
> > I've sent the patches as an RFC as I might not be aware of all the
> > consequences of the numerous changes to the driver's internals, even if I
> > took care to analyze the code flows to the best of my abilities.
> >
> > The series contains patches previously posted by Jyri and Peter that I
> > have found helpful. Please see the individual patches for changes compared
> > to the original versions (trivial conflict resolutions caused by a rebase
> > are not mentioned).
> >
> > The patches are based on top of a merge between Tomi's omapdrm-next branch
> > and the drm-misc/drm-misc-next branch for the "drm: fix drm_get_max_iomem
> > type mismatch" compilation fix. They can be found at
> >
> > git://linuxtv.org/pinchartl/media.git omapdrm/bridge
> >
> > The series has been tested on a Pandaboard with the HDMI and DVI outputs.
> > All patches have been at least compile-tested individually. I'll now go
> > through the process of making sure each of them gets tested on hardware
> > as well.
>
> Thanks, nice work!
>
> I did a read-the-descs-review, and looks good to me. My only comments
> are what I already mentioned in the chat: AM5 EVM doesn't work LCD
> (panel-dpi broken, perhaps?) (AM5 EVM was the only board I tested),
I've now tested the AM5 EVM and the LCD panel worked out of the box. I tried
to load all modules before panel_dpi and the panel then stopped working. After
a bit of investigation it turns out that the dpi_init_port() and
sdi_init_port() functions can return probe deferral, but their return value is
ignored by the caller. The problem pre-exists this series, the patch below
fixes it. Surprisingly enough given the extent of the rework, it doesn't
conflict with this series, I'll thus place it towards the start of v2.
From 82798aa248b30199ab8c6dc3417e6478f1fca8c4 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart
Date: Wed, 7 Mar 2018 20:34:42 +0200
Subject: [PATCH] drm/omap: dss: Handle DPI and SDI port initialization
failures
The dpi_init_port() and sdi_init_port() functions can return errors but
their return value is ignored. This prevents both probe failures and
probe deferral from working correctly. Propagate the errors up the call
stack.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dss.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c b/drivers/gpu/drm/omapdrm/dss/
dss.c
index 5f7789cf43c7..841256c34d65 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1185,7 +1185,8 @@ static int dss_init_ports(struct dss_device *dss)
struct platform_device *pdev = dss->pdev;
struct device_node *parent = pdev->dev.of_node;
struct device_node *port;
- int i;
+ unsigned int i;
+ int r;
for (i = 0; i < dss->feat->num_ports; i++) {
port = of_graph_get_port_by_id(parent, i);
@@ -1194,11 +1195,17 @@ static int dss_init_ports(struct dss_device *dss)
switch (dss->feat->ports[i]) {
case OMAP_DISPLAY_TYPE_DPI:
- dpi_init_port(dss, pdev, port, dss->feat->model);
+ r = dpi_init_port(dss, pdev, port, dss->feat->model);
+ if (r)
+ return r;
break;
+
case OMAP_DISPLAY_TYPE_SDI:
- sdi_init_port(dss, pdev, port);
+ r = sdi_init_port(dss, pdev, port);
+ if (r)
+ return r;
break;
+
default:
break;
}
> and patch 7 it not correct, as the infoframe is set from omap_encoder.
You're right. I'll drop that patch.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:
Re: [PATCH 6/6] drm: Reject bad property flag combinations
On Tue, Mar 06, 2018 at 07:22:51PM +0100, Daniel Vetter wrote:
> On Tue, Mar 06, 2018 at 06:48:49PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Pimp drm_property_type_valid() to check for more fails with the
> > property flags. Also make the check before adding the property,
> > and bail out if things look bad.
> >
> > Since we're now chekcing for more than the type let's also
> > change the function name to drm_property_flags_valid().
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_property.c | 29 +++--
> > 1 file changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> > index 027a50e55e96..6ac6ee41a6a3 100644
> > --- a/drivers/gpu/drm/drm_property.c
> > +++ b/drivers/gpu/drm/drm_property.c
> > @@ -50,11 +50,27 @@
> > * IOCTL and in the get/set property IOCTL.
> > */
> >
> > -static bool drm_property_type_valid(struct drm_property *property)
> > +static bool drm_property_flags_valid(u32 flags)
> > {
> > - if (property->flags & DRM_MODE_PROP_EXTENDED_TYPE)
> > - return !(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
> > - return !!(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
> > + u32 legacy_type = flags & DRM_MODE_PROP_LEGACY_TYPE;
> > + u32 ext_type = flags & DRM_MODE_PROP_EXTENDED_TYPE;
> > +
> > + /* Reject undefined/deprecated flags */
> > + if (flags & ~(DRM_MODE_PROP_LEGACY_TYPE |
> > + DRM_MODE_PROP_EXTENDED_TYPE |
> > + DRM_MODE_PROP_IMMUTABLE |
> > + DRM_MODE_PROP_ATOMIC))
> > + return false;
> > +
> > + /* We want either a legacy type or an extended type, but not both */
> > + if (!legacy_type == !ext_type)
> > + return false;
> > +
> > + /* Only one legacy type at a time please */
> > + if (legacy_type && !is_power_of_2(legacy_type))
> > + return false;
> > +
> > + return true;
> > }
>
> I think this catches everything. Well except not-yet-assigned
> EXTENDED_TYPE defines, but really we can overdo this :-)
Hmm. Yeah, I guess that kind of a fail is fairly unlikely because the
defines won't be there. Would require the driver to basically pass in
utter garbage instead of just a bad combination of existing flags.
>
> Reviewed-by: Daniel Vetter
Thanks. Series pushed to drm-misc-next.
> >
> > /**
> > @@ -79,6 +95,9 @@ struct drm_property *drm_property_create(struct
> > drm_device *dev,
> > struct drm_property *property = NULL;
> > int ret;
> >
> > + if (WARN_ON(!drm_property_flags_valid(flags)))
> > + return NULL;
> > +
> > if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
> > return NULL;
> >
> > @@ -108,8 +127,6 @@ struct drm_property *drm_property_create(struct
> > drm_device *dev,
> >
> > list_add_tail(&property->head, &dev->mode_config.property_list);
> >
> > - WARN_ON(!drm_property_type_valid(property));
> > -
> > return property;
> > fail:
> > kfree(property->values);
> > --
> > 2.16.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #34 from Harry Wentland --- Created attachment 137870 --> https://bugs.freedesktop.org/attachment.cgi?id=137870&action=edit [PATCH] Add one to EDID's audio channel count when passing to DC Thanks everyone for the debug on this one and especially Andrew for the patch. DC seems to take channel_count/audio_count to refer to the actual number of channels whereas the CEA EDID extension and our HW represent it as the number of channels-1. So as not to break other uses of this count (such as check_audio_bandwidth_hdmi()) this patch adds 1 when we get the count from the EDID. Can someone give it a spin? It's based on the latest amd-staging-drm-next branch but should apply on other branches as well. -- 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 105021] suspend / rx550 / extremely slow after 2nd thaw
https://bugs.freedesktop.org/show_bug.cgi?id=105021 jam...@amd.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #30 from jam...@amd.com --- https://lists.freedesktop.org/archives/amd-gfx/2018-March/019801.html the above patch should solve this suspend/resume issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #35 from Direx --- (In reply to Harry Wentland from comment #34) > DC seems to take channel_count/audio_count to refer to the actual number of > channels whereas the CEA EDID extension and our HW represent it as the > number of channels-1. So as not to break other uses of this count (such as > check_audio_bandwidth_hdmi()) this patch adds 1 when we get the count from > the EDID. > > Can someone give it a spin? It's based on the latest amd-staging-drm-next > branch but should apply on other branches as well. Just tested it on a fresh amd-staging-drm-next and it is also working. All audio formats are working correctly. *thumbs up* Could this be backported to 4.15 / 4.16 as it actually is a simple bug fix? @lethalwp: I think your issue is unrelated to this one. I get that too occasionally, but it has nothing to do with the wrong channel count in this bug. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] dt-bindings: display: Add Allwinner MIPI-DSI bindings
On Tue, Mar 06, 2018 at 02:55:59PM +0100, Maxime Ripard wrote: > From: Maxime Ripard > > The Allwinner SoCs usually come with a DSI encoder. Add a binding for it. > > Signed-off-by: Maxime Ripard > --- > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 93 +++- > 1 file changed, 93 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/16] clk: sunxi-ng: h3: h5: export CLK_PLL_VIDEO
On Thu, Mar 01, 2018 at 10:34:30PM +0100, Jernej Skrabec wrote: > CLK_PLL_VIDEO needs to be referenced in HDMI DT entry as a possible > PHY clock parent. > > Export it so it can be used later in DT. > > Signed-off-by: Jernej Skrabec > --- > drivers/clk/sunxi-ng/ccu-sun8i-h3.h | 4 +++- > include/dt-bindings/clock/sun8i-h3-ccu.h | 2 ++ > 2 files changed, 5 insertions(+), 1 deletion(-) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/16] dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline
On Thu, Mar 01, 2018 at 10:34:31PM +0100, Jernej Skrabec wrote: > Add missing compatibles for H3 HDMI pipeline. These compatibles can also > be used with H5 SoC. > > Signed-off-by: Jernej Skrabec > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 6 ++ > 1 file changed, 6 insertions(+) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #37 from Harry Wentland --- ... pick it up for 4.15 is what I meant to say. -- 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 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #36 from Harry Wentland --- Thanks, Direx. I'll get it reviewed and intend to get it into 4.16 as well. Will send it to the stable tree as well, where GregKH can pick it up. -- 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 81689] Black screen in info-beamer
https://bugs.freedesktop.org/show_bug.cgi?id=81689 Sven Arvidsson changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #2 from Sven Arvidsson --- Retested with Mesa 17 on radeonsi and info-beamer from Debian (1.0pre3+Lua) everything seems to be working. Presumably fixed on the info-beamer side, so I'm closing this. -- 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: New KFD ioctls: taking the skeletons out of the closet
On Wed, Mar 7, 2018 at 11:38 AM, Daniel Vetter wrote: > On Wed, Mar 07, 2018 at 09:38:03AM +0100, Christian K??nig wrote: >> Am 07.03.2018 um 00:09 schrieb Dave Airlie: >> > On 7 March 2018 at 08:44, Felix Kuehling wrote: >> > > Hi all, >> > > >> > > Christian raised two potential issues in a recent KFD upstreaming code >> > > review that are related to the KFD ioctl APIs: >> > > >> > > 1. behaviour of -ERESTARTSYS >> > > 2. transactional nature of KFD ioctl definitions, or lack thereof >> > > >> > > I appreciate constructive feedback, but I also want to encourage an >> > > open-minded rather than a dogmatic approach to API definitions. So let >> > > me take all the skeletons out of my closet and get these APIs reviewed >> > > in the appropriate forum before we commit to them upstream. See the end >> > > of this email for reference. >> > > >> > > The controversial part at this point is kfd_ioctl_map_memory_to_gpu. If >> > > any of the other APIs raise concerns or questions, please ask. >> > > >> > > Because of the HSA programming model, KFD memory management APIs are >> > > synchronous. There is no pipelining. Command submission to GPUs through >> > > user mode queues does not involve KFD. This means KFD doesn't know what >> > > memory is used by the GPUs and when it's used. That means, when the >> > > map_memory_to_gpu ioctl returns to user mode, all memory mapping >> > > operations are complete and the memory can be used by the CPUs or GPUs >> > > immediately. >> > I've got a few opinions, but first up I still dislike user-mode queues >> > and everything >> > they entail. I still feel they are solving a Windows problem and not a >> > Linux problem, >> > and it would be nice if we had some Linux numbers on what they gain us over >> > a dispatch ioctl, because they sure bring a lot of memory management >> > issues. >> >> Well user-mode queues are a problem as long as you don't have recoverable >> page faults on the GPU. >> >> As soon as you got recoverable page faults and push the memory management >> towards things like HMM I don't see an advantage of using a IOCTL based >> command submission any more. >> >> So I would say that this is a problem which is slowly going away as the >> hardware improves. > > Yeah, but up to the point where the hw actually works (instead of promises > that maybe it'll work next generation, trust us, for like a few > generations) it's much easier to hack up an ioctl with workarounds than > intercepting an mmap write fault all the time (those are slower than > ioctls). > > I think userspace queues are fine once we have known-working hw. Before > that I'm kinda agreeing with Dave and not seeing the point. At least to my > knowledge we still haven't arrived in the wonderful promised land of hw > recoverable (well, restartable really) page faults on any vendors platform > ... I think user space queues are a bit of a distraction. The original point of KFD and HSA was to have a consistent programming model across CPU and other devices with relatively seamless access to the same memory pools. KFD was originally focused on APUs and when we have an IOMMUv2 with ATC available, we have support for recoverable page faults. It's been working for 3 generations of hw and has been expanded to GPUVM on newer hw which doesn't have the dependency on IOMMU and also support vram. We added support for KFD for older dGPUs that don't have this capability, but that is certainly not the only use case we need to consider. Alex > >> > That said amdkfd is here. >> > >> > The first question you should ask (which you haven't asked here at all) is >> > what should userspace do with the ioctl result. >> > >> > > HSA also uses a shared virtual memory model, so typically memory gets >> > > mapped on multiple GPUs and CPUs at the same virtual address. >> > > >> > > The point of contention seems to be the ability to map memory to >> > > multiple GPUs in a single ioctl and the behaviour in failure cases. I'll >> > > discuss two main failure cases: >> > > >> > > 1: Failure after all mappings have been dispatched via SDMA, but a >> > > signal interrupts the wait for completion and we return -ERESTARTSYS. >> > > Documentation/kernel-hacking/hacking.rst only says "[...] you should be >> > > prepared to process the restart, e.g. if you're in the middle of >> > > manipulating some data structure." I think we do that by ensuring that >> > > memory that's already mapped won't be mapped again. So the restart will >> > > become a no-op and just end up waiting for all the previous mappings to >> > > complete. >> > -ERESTARTSYS at that late stage points to a badly synchronous API, >> > I'd have said you should have two ioctls, one that returns a fence after >> > starting the processes, and one that waits for the fence separately. >> >> That is exactly what I suggested as well, but also exactly what Felix tries >> to avoid :) >> >> > The overhead of ioctls isn't your enemy until you've measured it and >> > proven
Re: [PATCH 01/21] vulkan: Add KHR_display extension using DRM
Jason Ekstrand writes: Thanks a million for the intense review. I've pushed 15 tiny patches that address individual questions in this message. If you want to look at those separately, that would be great. When we're done, I'll merge them back into the giant patch. Sorry for the delay in answering; you asked a hard question about GEM handles and reference counting which I think I've resolved by eliminating the ability to share the same fd for modesetting and rendering. Let me know if I've deleted too much context from your answers. > With the exception of NIR (which is a bit odd), we usually use ALL_CAPS for > enum values. Thanks, fixed. > Yes, this does seem like the only reasonable mode for now. I suppose you > could check to see if the platform supports ASYNC_FLIP and advertise > IMMEDIATE in that case. I know intel doesn't advertise it but I thought > amdgpu does. Ok, we'll put that on the wish list, along with MAILBOX (which applications actually want :-) > vk_outarray, though I suppose you've probably already made that > change. Yup, vk_outarray everywhere now. > I don't see use_prime_blit being set anywhere. Perhaps that comes in a > later patch? The line is obviously correct, so I'm fine with leaving > it. You're right -- this was a cult-n-paste error. I don't support prime at all, so I've removed this bit. > This will have to be updated for modifiers. I'm reasonably happy for it to > be the no-op update for now though KHR_display supporting real modifiers > would be nice. :-) Yeah, "patches welcome", of course. I don't have a requirement for them on Radeon at this point. >> + if (result != VK_SUCCESS) >> + return result; >> + >> + ret = drmPrimeFDToHandle(wsi->master_fd, image->base.fd, >> &image_handle); >> > > This opens up some interesting questions. GEM handles are not reference > counted by the kernel. If the driver that we're running on is using > master_fd, then we shouldn't close our handle because that would close the > handle for the driver as well. If it's not using master_fd, we should > close the handle to avoid leaking it. The later is only a worry in the > prime case but given that I saw a line above about use_prime_blit, you have > me scared. :-) Ok, as I mentioned in the header of this message, I've eliminated any code which talks about potentially sharing master_fd and render_fd. I removed render_fd from the wsi layer entirely as it is no longer used anywhere. In the drivers, when you request KHR_display, I attempt to open the related primary node and if that succeeds, I pass that to the wsi layer for use there. That fd is otherwise unused by the driver, and in fact the driver doesn't need to close it as the wsi layer will. Obviously having two FDs is "wasteful" at some level as we really don't need that, but that's what the acquire_xlib extension will have to do anyways. > One solution to this connundrum would be to simply never use the master FD > for the Vulkan driver itself and always open a render node. If handed a > master FD, you could check if it matches your render node and set > use_prime_blit accordingly. Then the driver and WSI would have separate > handle domains and this problem would be solved. You could also just open > the master FD twice, once for WSI and once for the driver. Yup, two FDs, one master, one render. That way, the kludge seen in this patch where it opens the master when you request the KHR_display extension works the same as the acquire_xlib code in the later patch. > You have the format in create_info. We could add some generic VkFormat > introspection or we can just handle the 2-4 cases we care about > directly. Given that this layer provides the list of valid surface formats which that image could contain, I've added depth/bpp information to that list and the image_init code walks over the list of possible formats to find the associated depth/bpp values. If the application provides an invalid format, I'm returning VK_ERROR_DEVICE_LOST as that is a valid error return and I couldn't find anything else that seemed like a better value. If we get here, the application made a mistake anyways. > What happens if we close the handle immediately after calling > drmModeAddFB? Does the FB become invalid? If so, then we probably want to > stash the handle so we can clean it up when we destroy the swapchain. > Unless, of course, we're willing to make the assumption (as stated above) > that the driver and WSI are always using the same FD. It looks like the FB ends up with a reference to the object, so it would should be safe to just close the handle at this point. However, to make it less dependent on the kernel behavior, I've changed the code to store the buffer_object handle in the image and then added code to free both the buffer object and the frame buffer in wsi_display_image_finish. Thanks for finding the leak. >> +/* call with wait_mutex held */ >> > > It might be worth a line in the comment to say that
Re: [Patch 1/4] dt-bindings: display/ti: Move common dispc bindings to omap-dss.txt
On Fri, Mar 02, 2018 at 07:48:01AM -0600, Benoit Parrot wrote: > Add common DISPC bindings into the top level bindings file. > Move common bindings here instead of having multiple copies of > the same information in all of the variant specific files. > > Signed-off-by: Benoit Parrot > --- > Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt | 5 - > Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt | 7 +++ > Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt | 4 > Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt | 4 > Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt | 4 > Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt | 4 > 6 files changed, 7 insertions(+), 21 deletions(-) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH 01/21] vulkan: Add KHR_display extension using DRM
Daniel Stone writes: > Or better, just use drmModeAddFB2 and pass the format directly. That > landed back in 3.2 or so, and I don't think there's anyone trying to > use Vulkan on a kernel from 2011. Yeah, that's probably a better plan. I've pushed a patch that does this on top of the long list of patches made in response to Jason's email. Once he's replied to that, I'll go ahead and smash the new patches back on top of the original series and re-publish that. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: New KFD ioctls: taking the skeletons out of the closet
Thanks for the feedback. I'm answering some of your questions inline. On 2018-03-06 06:09 PM, Dave Airlie wrote: > On 7 March 2018 at 08:44, Felix Kuehling wrote: >> Hi all, >> >> Christian raised two potential issues in a recent KFD upstreaming code >> review that are related to the KFD ioctl APIs: >> >> 1. behaviour of -ERESTARTSYS >> 2. transactional nature of KFD ioctl definitions, or lack thereof >> >> I appreciate constructive feedback, but I also want to encourage an >> open-minded rather than a dogmatic approach to API definitions. So let >> me take all the skeletons out of my closet and get these APIs reviewed >> in the appropriate forum before we commit to them upstream. See the end >> of this email for reference. >> >> The controversial part at this point is kfd_ioctl_map_memory_to_gpu. If >> any of the other APIs raise concerns or questions, please ask. >> >> Because of the HSA programming model, KFD memory management APIs are >> synchronous. There is no pipelining. Command submission to GPUs through >> user mode queues does not involve KFD. This means KFD doesn't know what >> memory is used by the GPUs and when it's used. That means, when the >> map_memory_to_gpu ioctl returns to user mode, all memory mapping >> operations are complete and the memory can be used by the CPUs or GPUs >> immediately. > I've got a few opinions, but first up I still dislike user-mode queues > and everything > they entail. I still feel they are solving a Windows problem and not a > Linux problem, > and it would be nice if we had some Linux numbers on what they gain us over > a dispatch ioctl, because they sure bring a lot of memory management issues. > > That said amdkfd is here. > > The first question you should ask (which you haven't asked here at all) is > what should userspace do with the ioctl result. > >> HSA also uses a shared virtual memory model, so typically memory gets >> mapped on multiple GPUs and CPUs at the same virtual address. >> >> The point of contention seems to be the ability to map memory to >> multiple GPUs in a single ioctl and the behaviour in failure cases. I'll >> discuss two main failure cases: >> >> 1: Failure after all mappings have been dispatched via SDMA, but a >> signal interrupts the wait for completion and we return -ERESTARTSYS. >> Documentation/kernel-hacking/hacking.rst only says "[...] you should be >> prepared to process the restart, e.g. if you're in the middle of >> manipulating some data structure." I think we do that by ensuring that >> memory that's already mapped won't be mapped again. So the restart will >> become a no-op and just end up waiting for all the previous mappings to >> complete. > -ERESTARTSYS at that late stage points to a badly synchronous API, > I'd have said you should have two ioctls, one that returns a fence after > starting the processes, and one that waits for the fence separately. > > The overhead of ioctls isn't your enemy until you've measured it and > proven it's a problem. > >> Christian has a stricter requirement, and I'd like to know where that >> comes from: "An interrupted IOCTL should never have a visible effect." > Christian might be taking things a bit further but synchronous gpu access > APIs are bad, but I don't think undoing a bunch of work is a good plan either > just because you got ERESTARTSYS. If you get ERESTARTSYS can you > handle it, if I've fired off 5 SDMAs and wait for them will I fire off 5 more? > will I wait for the original SDMAs if I reenter? It will wait for the original SDMAs to complete. > >> 2: Failure to map on some but not all GPUs. This comes down to the >> question, do all ioctl APIs or system calls in general need to be >> transactional? As a counter example I'd give incomplete read or write >> system calls that return how much was actually read or written. Our >> current implementation of map_memory_to_gpu doesn't do this, but it >> could be modified to return to user mode how many of the mappings, or >> which mappings specifically failed or succeeded. > What should userspace do? if it only get mappings on 3 of the gpus instead > of say 4? Is there a sane resolution other than calling the ioctl again with > the single GPU? Would it drop the GPU from the working set from that point on? > > Need more info to do what can come out of the API doing incomplete > operations. There are two typical use cases where this function is used. 1. During allocation 2. Changing access to an existing buffer There is no retry logic in either case. And given the likely failure conditions, a retry doesn't really make much sense. I think the most likely failure I've seen is a failure to validate the BO under heavy memory pressure. This will affect the first GPU trying to map the memory. Once it's mapped on one GPU, subsequent GPUs don't need to validate it again, so that's less likely to fail. Maybe if we're running out of space for the SDMA command buffers. If you're under that much memory pressure, it's unlikely that a
[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #38 from Direx --- Just for the record (it might not surprise you): The patch also works on 4.15, just tested it on the "old" kernel. -- 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 104285] Euro Truck Simulator 2 and American Truck Simulator artifacts (Mesa 17.3, AMD R9 280X)
https://bugs.freedesktop.org/show_bug.cgi?id=104285 --- Comment #9 from Gregor Münch --- (In reply to Alex Vorobyev from comment #8) > I think it's not the same bug. CS:GO works on my system as it should, while > SCS games still have broken shadows. So you also checked that specific map? Anyway, its either a bug which is already fixed in Mesa git or fixed in LLVM 6.0. In both cases devs will wait till users upgrade to mesa 18. So the only thing you can do is check things with current mesa git / LLVM 6.0 and see if the problem persists. -- 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 105386] Request for a new fd.o account
https://bugs.freedesktop.org/show_bug.cgi?id=105386 Daniel Vetter changed: What|Removed |Added Product|DRI |freedesktop.org Component|IGT |New Accounts Version|XOrg git|unspecified Assignee|dri-devel@lists.freedesktop |sitewranglers@lists.freedes |.org|ktop.org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105386] Request for a new fd.o account
https://bugs.freedesktop.org/show_bug.cgi?id=105386 --- Comment #1 from Daniel Vetter --- Ack from me, also from Petri and Arek (we discussed this all). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Add new reverse iterator over all plane state (V2)
On 2018-03-06 10:10 PM, Shirish S wrote: > Add reverse iterator for_each_oldnew_plane_in_state_reverse to > compliment the for_each_oldnew_plane_in_state way or reading plane > states. > > The plane states are required to be read in reverse order for > amd drivers, cause the z order convention followed in linux is > opposite to how the planes are supposed to be presented to DC > engine, which is in common to both windows and linux. > > V2: fix compile time errors due to -Werror flag. > > Signed-off-by: Shirish S > Signed-off-by: Pratik Vishwakarma > Reviewed-by: Daniel Vetter Merged to drm-misc-next. Harry > --- > include/drm/drm_atomic.h | 22 ++ > 1 file changed, 22 insertions(+) > > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h > index cf13842..3fe8dde 100644 > --- a/include/drm/drm_atomic.h > +++ b/include/drm/drm_atomic.h > @@ -754,6 +754,28 @@ void drm_state_dump(struct drm_device *dev, struct > drm_printer *p); > (new_plane_state) = > (__state)->planes[__i].new_state, 1)) > > /** > + * for_each_oldnew_plane_in_state_reverse - iterate over all planes in an > atomic > + * update in reverse order > + * @__state: &struct drm_atomic_state pointer > + * @plane: &struct drm_plane iteration cursor > + * @old_plane_state: &struct drm_plane_state iteration cursor for the old > state > + * @new_plane_state: &struct drm_plane_state iteration cursor for the new > state > + * @__i: int iteration cursor, for macro-internal use > + * > + * This iterates over all planes in an atomic update in reverse order, > + * tracking both old and new state. This is useful in places where the > + * state delta needs to be considered, for example in atomic check functions. > + */ > +#define for_each_oldnew_plane_in_state_reverse(__state, plane, > old_plane_state, new_plane_state, __i) \ > + for ((__i) = ((__state)->dev->mode_config.num_total_plane - 1); \ > + (__i) >= 0;\ > + (__i)--) \ > + for_each_if ((__state)->planes[__i].ptr && \ > + ((plane) = (__state)->planes[__i].ptr, \ > + (old_plane_state) = > (__state)->planes[__i].old_state,\ > + (new_plane_state) = > (__state)->planes[__i].new_state, 1)) > + > +/** > * for_each_old_plane_in_state - iterate over all planes in an atomic update > * @__state: &struct drm_atomic_state pointer > * @plane: &struct drm_plane iteration cursor > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105390] Requesting a new account for IGT
https://bugs.freedesktop.org/show_bug.cgi?id=105390 Bug ID: 105390 Summary: Requesting a new account for IGT Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: michal.winiar...@intel.com Created attachment 137876 --> https://bugs.freedesktop.org/attachment.cgi?id=137876&action=edit Keys Hi. I'd like to request a new account. Name: Michał Winiarski Email: michal.winiar...@intel.com Account_name: knr -- 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 104717] Rocket League: grass rendering broken with nir
https://bugs.freedesktop.org/show_bug.cgi?id=104717 Gregor Münch changed: What|Removed |Added CC||t_arc...@yahoo.com.au --- Comment #2 from Gregor Münch --- Looks like the assigning didnt work? Did that now, I hope you dont mind. Honestly I dont understand why Intel isnt affected. As far as I understood the old problem: mesa basically treats OpenGL spec right but nvidia was faster implementing it thus created a de-facto standard. Now porting companys agree its wrong but dont want to change treatment because 80% of their users using nvidia binary blob. To circumvent the problem, a override was created. Fixing the issue for radeon. I mean, I understand that the RadeonSI NIR port doesnt respect the dri override yet. But I dont understand that Intel isnt using the dri override at all. Which would mean that if Intel treats the opengl spec in the same way like RadeonSI did but doesnt make use of the override, the problems in those games still appear for Intel users. -- 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
[PATCH v5] drm/pl111: Use max memory bandwidth for resolution
We were previously selecting 1024x768 and 32BPP as the default
set-up for the PL111 consumers.
This does not work on elder systems: the device tree bindings
support a property "max-memory-bandwidth" in bytes/second that
states that if you exceed this the memory bus will saturate.
The result is flickering and unstable images.
Parse the "max-memory-bandwidth" and respect it when
intializing the driver. On the RealView PB11MP, Versatile and
Integrator/CP we get a nice console as default with this code.
Reviewed-by: Eric Anholt
Signed-off-by: Linus Walleij
---
ChangeLog v4->v5:
- Rebase on top of drm-next and resend so the patch
applies and produce a reasonable link. I have no clue
why patch does not apply, it looks like it should, but
the git moves in mysterious ways.
ChangeLog v3->v4:
- Switch the noisy DRM_INFO for DRM_DEBUG_KMS
- Collect Eric's review tag
ChangeLog v2->v3:
- Account for the case where there is no bandwidth limitation
so priv->memory_bw is zero. Then just accept any modes.
ChangeLog v1->v2:
- Exploit the new .mode_valid() callback we added to the
simple KMS helper.
- Use the hardcoded bits per pixel per variant instead of
trying to be heuristic about this setting for now.
---
drivers/gpu/drm/pl111/pl111_display.c | 36 +++
drivers/gpu/drm/pl111/pl111_drm.h | 1 +
drivers/gpu/drm/pl111/pl111_drv.c | 6 ++
3 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index 5b8368c76734..310646427907 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -50,6 +50,41 @@ irqreturn_t pl111_irq(int irq, void *data)
return status;
}
+static enum drm_mode_status
+pl111_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+ struct drm_device *drm = crtc->dev;
+ struct pl111_drm_dev_private *priv = drm->dev_private;
+ u32 cpp = priv->variant->fb_bpp / 8;
+ u64 bw;
+
+ /*
+* We use the pixelclock to also account for interlaced modes, the
+* resulting bandwidth is in bytes per second.
+*/
+ bw = mode->clock * 1000; /* In Hz */
+ bw = bw * mode->hdisplay * mode->vdisplay * cpp;
+ bw = div_u64(bw, mode->htotal * mode->vtotal);
+
+ /*
+* If no bandwidth constraints, anything goes, else
+* check if we are too fast.
+*/
+ if (priv->memory_bw && (bw > priv->memory_bw)) {
+ DRM_DEBUG_KMS("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
+ mode->hdisplay, mode->vdisplay,
+ mode->clock * 1000, cpp, bw);
+
+ return MODE_BAD;
+ }
+ DRM_DEBUG_KMS("%d x %d @ %d Hz, %d cpp, bw %llu bytes/s OK\n",
+ mode->hdisplay, mode->vdisplay,
+ mode->clock * 1000, cpp, bw);
+
+ return MODE_OK;
+}
+
static int pl111_display_check(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *pstate,
struct drm_crtc_state *cstate)
@@ -348,6 +383,7 @@ static int pl111_display_prepare_fb(struct
drm_simple_display_pipe *pipe,
}
static struct drm_simple_display_pipe_funcs pl111_display_funcs = {
+ .mode_valid = pl111_mode_valid,
.check = pl111_display_check,
.enable = pl111_display_enable,
.disable = pl111_display_disable,
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h
b/drivers/gpu/drm/pl111/pl111_drm.h
index 2a93e0134061..8639b2d4ddf7 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -65,6 +65,7 @@ struct pl111_drm_dev_private {
struct drm_simple_display_pipe pipe;
void *regs;
+ u32 memory_bw;
u32 ienb;
u32 ctrl;
/* The pixel clock (a reference to our clock divider off of CLCDCLK). */
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index e92a406c9ea9..4621259d5387 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -257,6 +257,12 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
drm->dev_private = priv;
priv->variant = variant;
+ if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
+&priv->memory_bw)) {
+ dev_info(dev, "no max memory bandwidth specified, assume
unlimited\n");
+ priv->memory_bw = 0;
+ }
+
/* The two variants swap this register */
if (variant->is_pl110) {
priv->ienb = CLCD_PL110_IENB;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
On Wed, Mar 07, 2018 at 02:13:21AM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote:
> > On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote:
> > >
> > >
> > >
> > > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com
> > > > wrote:
> > > > > From: Matt Atwood
> > > > >
> > > > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme from 8
> > > > > bits to 7 bits in DPCD 0x000e. The 8th bit describes a new feature,
> > > > > for
> > > > > panels that use this new feature, this would cause a wait interval for
> > > > > clock recovery of at least 512 ms, much higher then spec maximum of
> > > > > 16 ms.
> > > > > This behavior is described in table 2-158 of DP 1.4 spec address
> > > > > Eh.
> > > > > To avoid breaking panels
> > >
> > > See comment below:
> > >
> > > > that are not spec compliant we now warn on
> > > > > invalid values.
> > > > >
> > > > > V2: commit title/message, masking all 7 bits, warn on out of spec
> > > > > values.
> > > >
> > > > this approach is even better imho.
> > > >
> > > > >
> > > > > Signed-off-by: Matt Atwood
> > > >
> > > > Reviewed-by: Rodrigo Vivi
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/drm_dp_helper.c | 18 ++
> > > > > include/drm/drm_dp_helper.h | 1 +
> > > > > 2 files changed, 15 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > > index adf79be..a718ccc 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > > @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const
> > > > > u8 link_status[DP_LINK_STATUS_SI
> > > > > EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
> > > > >
> > > > > void drm_dp_link_train_clock_recovery_delay(const u8
> > > > > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > > > > - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > > > > + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > > > > DP_TRAINING_AUX_RD_MASK;
> > > > > +
> > > > > + if (rd_interval > 4)
> > > > > + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
> > > > > rd_interval);
> > >
> > > Some default for panels without a valid value?
> > > rd_interval = 4;
> > > "AUX read interval out of range, using max %d ms"
> > >
> >
> > The problem with setting the upper bound to 4 is that there are panels
> > that do not follow the spec and expect a longer than 16 ms delay. So
> > if we set the upper bound to 4 in those cases the panels might not work.
> >
> > So we decided to go with this approach where we tell the users that panel
> > is requesting
> > out of range AUX value but then set it to the value * 4 in the else part.
> >
>
> Thanks for the clarification. My concern is if the DPCD is advertizing
> an out of spec value, it might as well be advertizing a delay that the
> panel doesn't need. And I thought panel quirks were supposed to be used
> for working around things like this. To be clear, this is not a big
> enough concern to block this fix.
>
> Like I said in the other email, this patch refers to DP 1.4, shouldn't
> the clock recovery delay be updated too (in a separate patch)?
We clearly need more work here.
I can see here on DP-v1.2a_d11:
00h = 100us for the Main Link Clock Recovery phase 400us for the Main Link
Channel
Equalization phase and for FAUX training.
01h = 4ms all.
02h = 8ms all.
03h = 12ms all.
04h = 16ms all.
So probably the initial mask on this patch should be marked with /* XXX 1.2? */
because it clearly got introduced in some 1.2 minor release.
But even for DP 1.2 it doesn't seem we are doing it right on the 0 case.
It seems that we are using 100us for both channel eq and clock recovery, right?
or am I missing something?
Then DP 1.3 keeps same config.
But DP 1.4 change all values.
clock recovery is always 100us and channel eq is depending on this bit * 4 and
400us when bit is zeroed.
But limited to 4.
So we probably need 3 patches here:
1. - This one to protect against bad panels masking it and mentioning DP 1.2,
nor 1.3 or 1.4. Also limiting rd_interval to 4 as DK suggested. Panels
cannot
expect all drivers are using this value * 4 blindly since it is not on
spec.
2. - Fix channel eq for 0 case since 1.2. It should be 400us.
3. - For DP version >= 1.4 always use 100us for clock req or follow this
register for
channel eq.
Thoughts?
>
>
> > Manasi
> >
> > >
> > > > > +
> > > > > + if (rd_interval == 0)
> > > > > udelay(100);
> > > > > else
> > > > > - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> > > > > + mdelay(rd_interval * 4);
> > > > > }
> > > > > EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
> > > > >
> > > >
[pull] radeon and amdgpu drm-fixes-4.16
Hi Dave, Fixes for 4.16. A bit bigger than I would have liked, but most of that is DC fixes which Harry helped me pull together from the past few weeks. Highlights: - Fix DL DVI with DC - Various RV fixes for DC - Overlay fixes for DC - Fix HDMI2 handling on boards without HBR tables in the vbios - Fix crash with pass-through on SI on amdgpu - Fix RB harvesting on KV - Fix hibernation failures on UVD with certain cards The following changes since commit 93dfdf9fde9f20f1c46738bf184adeebc7d7d66e: Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2018-03-01 14:03:14 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.16 for you to fetch changes up to 4a53d9045ec31f3f97719c2e41cc8b2e7151a1fe: drm/amd/display: validate plane format on primary plane (2018-03-07 16:31:19 -0500) Alex Deucher (3): drm/amdgpu: used cached pcie gen info for SI (v2) drm/radeon: fix KV harvesting drm/amdgpu: fix KV harvesting Bhawanpreet Lakha (1): drm/amd/display: Fix takover from VGA mode Eric Yang (3): drm/amd/display: fix cursor related Pstate hang drm/amd/display: update infoframe after dig fe is turned on drm/amd/display: early return if not in vga mode in disable_vga Harry Wentland (11): drm/amd/display: Don't blow up if TG is NULL in dce110_vblank_set drm/amd/display: Default HDMI6G support to true. Log VBIOS table error. drm/amd/display: Move MAX_TMDS_CLOCK define to header drm/amd/display: Remove unnecessary fail labels in create_stream_for_sink drm/amd/display: Pass signal directly to enable_tmds_output drm/amd/display: Don't allow dual-link DVI on all ASICs. drm/amd/display: Don't block dual-link DVI modes drm/amd/display: Make create_stream_for_sink more consistent drm/amd/display: Call update_stream_signal directly from amdgpu_dm drm/amd/display: Use crtc enable/disable_vblank hooks drm/amd/display: Return success when enabling interrupt James Zhu (2): drm/amdgpu:Correct max uvd handles drm/amdgpu:Always save uvd vcpu_bo in VM Mode Jerry (Fangzhi) Zuo (2): drm/amd/display: Fix topology change issue in MST rehook drm/amd/display: Fixed non-native modes not lighting up Leo (Sunpeng) Li (1): drm/amd/display: Fix memleaks when atomic check fails. Michel Dänzer (1): drm/amdgpu/dce6: Use DRM_DEBUG instead of DRM_INFO for HPD IRQ info Mikita Lipski (1): drm/amd/display: Set irq state only on existing crtcs Rex Zhu (1): drm/amdgpu: Notify sbios device ready before send request Roman Li (3): drm/amd/display: Fix active dongle hotplug drm/amd/display: Fix FBC topology change drm/amd/display: fix boot-up on vega10 Shirish S (5): drm/amd/display: defer modeset check in dm_update_planes_state drm/amd/display: validate plane in dce110 for scaling drm/amd/display: update plane params before validation drm/amd/display: disable CRTCs with NULL FB on their primary plane (V2) drm/amd/display: validate plane format on primary plane Tom St Denis (1): drm/amd/amdgpu: Mask rptr as well in ring debugfs drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 13 +- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 30 +--- drivers/gpu/drm/amd/amdgpu/si.c| 22 ++- drivers/gpu/drm/amd/amdgpu/si_dpm.c| 50 ++- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 165 +++-- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 6 +- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 6 + drivers/gpu/drm/amd/display/dc/core/dc.c | 6 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 +- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 3 - drivers/gpu/drm/amd/display/dc/core/dc_stream.c| 76 +- drivers/gpu/drm/amd/display/dc/dc.h| 3 +- drivers/gpu/drm/amd/display/dc/dc_stream.h | 2 + drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h | 10 +- .../gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 38 +++-- .../gpu/drm/amd/display/dc/dce/dce_link_encoder.h | 3 +- .../drm/amd/display/dc/dce100/dce100_resource.c| 1 + .../amd/display/dc/dce110/dce110_hw_sequencer.c| 91 ++-- .../drm/amd/display/dc/dce110/dce110_resource.c| 18 +++ .../drm/amd/display/dc/dce112/dce112_resource.c| 2 + .../drm/amd/display/dc/dce120/dce120_resource.c| 2 + .../gpu/drm/amd/display/dc/dce80/dce80_resource.c | 1 + .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 65 +++- .../gpu/drm/amd/display/dc/inc/hw/link_encoder.h |
Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
On Wed, Mar 07, 2018 at 02:06:08PM -0800, Rodrigo Vivi wrote:
> On Wed, Mar 07, 2018 at 02:13:21AM +, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote:
> > > On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote:
> > > >
> > > >
> > > >
> > > > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > > > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com
> > > > > wrote:
> > > > > > From: Matt Atwood
> > > > > >
> > > > > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme
> > > > > > from 8
> > > > > > bits to 7 bits in DPCD 0x000e. The 8th bit describes a new feature,
> > > > > > for
> > > > > > panels that use this new feature, this would cause a wait interval
> > > > > > for
> > > > > > clock recovery of at least 512 ms, much higher then spec maximum of
> > > > > > 16 ms.
> > > > > > This behavior is described in table 2-158 of DP 1.4 spec address
> > > > > > Eh.
> > > > > > To avoid breaking panels
> > > >
> > > > See comment below:
> > > >
> > > > > that are not spec compliant we now warn on
> > > > > > invalid values.
> > > > > >
> > > > > > V2: commit title/message, masking all 7 bits, warn on out of spec
> > > > > > values.
> > > > >
> > > > > this approach is even better imho.
> > > > >
> > > > > >
> > > > > > Signed-off-by: Matt Atwood
> > > > >
> > > > > Reviewed-by: Rodrigo Vivi
> > > > >
> > > > > > ---
> > > > > > drivers/gpu/drm/drm_dp_helper.c | 18 ++
> > > > > > include/drm/drm_dp_helper.h | 1 +
> > > > > > 2 files changed, 15 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > > > index adf79be..a718ccc 100644
> > > > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > > > @@ -119,18 +119,28 @@ u8
> > > > > > drm_dp_get_adjust_request_pre_emphasis(const u8
> > > > > > link_status[DP_LINK_STATUS_SI
> > > > > > EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
> > > > > >
> > > > > > void drm_dp_link_train_clock_recovery_delay(const u8
> > > > > > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > > > > > - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > > > > > + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > > > > > DP_TRAINING_AUX_RD_MASK;
> > > > > > +
> > > > > > + if (rd_interval > 4)
> > > > > > + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
> > > > > > rd_interval);
> > > >
> > > > Some default for panels without a valid value?
> > > > rd_interval = 4;
> > > > "AUX read interval out of range, using max %d ms"
> > > >
> > >
> > > The problem with setting the upper bound to 4 is that there are panels
> > > that do not follow the spec and expect a longer than 16 ms delay. So
> > > if we set the upper bound to 4 in those cases the panels might not work.
> > >
> > > So we decided to go with this approach where we tell the users that panel
> > > is requesting
> > > out of range AUX value but then set it to the value * 4 in the else part.
> > >
> >
> > Thanks for the clarification. My concern is if the DPCD is advertizing
> > an out of spec value, it might as well be advertizing a delay that the
> > panel doesn't need. And I thought panel quirks were supposed to be used
> > for working around things like this. To be clear, this is not a big
> > enough concern to block this fix.
> >
> > Like I said in the other email, this patch refers to DP 1.4, shouldn't
> > the clock recovery delay be updated too (in a separate patch)?
>
> We clearly need more work here.
>
> I can see here on DP-v1.2a_d11:
>
> 00h = 100us for the Main Link Clock Recovery phase 400us for the Main Link
> Channel
> Equalization phase and for FAUX training.
> 01h = 4ms all.
> 02h = 8ms all.
> 03h = 12ms all.
> 04h = 16ms all.
>
> So probably the initial mask on this patch should be marked with /* XXX 1.2?
> */
> because it clearly got introduced in some 1.2 minor release.
>
> But even for DP 1.2 it doesn't seem we are doing it right on the 0 case.
> It seems that we are using 100us for both channel eq and clock recovery,
> right?
> or am I missing something?
>
> Then DP 1.3 keeps same config.
>
> But DP 1.4 change all values.
>
> clock recovery is always 100us and channel eq is depending on this bit * 4
> and 400us when bit is zeroed.
>
> But limited to 4.
>
> So we probably need 3 patches here:
> 1. - This one to protect against bad panels masking it and mentioning DP 1.2,
> nor 1.3 or 1.4. Also limiting rd_interval to 4 as DK suggested. Panels
> cannot
> expect all drivers are using this value * 4 blindly since it is not on
> spec.
So if some panels still expect a greater delay, those will fail link training.
But
yes if we want them to be DP compliant, just follow the spec, limit it to the
max value of 4 with
a warnin
[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference
https://bugs.freedesktop.org/show_bug.cgi?id=102553 --- Comment #7 from mercuriete --- Created attachment 137877 --> https://bugs.freedesktop.org/attachment.cgi?id=137877&action=edit very ugly patch LOL -- 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 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference
https://bugs.freedesktop.org/show_bug.cgi?id=102553 --- Comment #8 from mercuriete --- Thanks you for the response. I created a very ugly workaround that WORKS_FOR_ME I need to read the link that you provided me to learn how to debug that stack trace. I think in a few days I'll have more time to spend. Thank you very much. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon, amdgpu, ttm drm-next-4.17
Hi Dave, More stuff for 4.17. Highlights: - More fixes for "wattman" like functionality (fine grained clk/voltage control) - Add more power profile infrastucture (context based dpm) - SR-IOV fixes - Add iomem debugging interface for use with umr - Powerplay and cgs cleanups - DC fixes and cleanups - ttm improvements - Misc cleanups all over The following changes since commit 9aff8b2ae71dcf7f02443821a894a736f40e4919: Revert "drm/radeon/pm: autoswitch power state when in balanced mode" (2018-02-20 16:27:16 -0500) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.17 for you to fetch changes up to f6c3b601bd490eda08c27b03607448abd4b4841b: drm/amdgpu:Always save uvd vcpu_bo in VM Mode (2018-03-07 16:12:18 -0500) Alex Deucher (5): drm/amdgpu/powerplay/smu7: use proper dep table for mclk drm/amdgpu: fix module parameter descriptions drm/amdgpu: used cached pcie gen info for SI (v2) drm/radeon: fix KV harvesting drm/amdgpu: fix KV harvesting Amber Lin (1): drm/amdgpu: Map all visible VRAM at startup Arnd Bergmann (1): radeon: hide pointless #warning when compile testing Ben Crocker (1): drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE Bhawanpreet Lakha (2): drm/amd/display: Use MACROS instead of dm_logger drm/amd/display: define DC_LOGGER for logger Christian König (25): drm/ttm: set page mapping during allocation drm/amdgpu: use the TTM dummy page instead of allocating one drm/ttm: add default implementations for ttm_tt_(un)populate drm/virtio: remove ttm_pool_* wrappers drm/mgag200: remove ttm_pool_* wrappers drm/hisilicon: remove ttm_pool_* wrappers drm/ast: remove ttm_pool_* wrappers drm/qxl: remove ttm_pool_* wrappers drm/cirrus: remove ttm_pool_* wrappers drm/bochs: remove the default ttm_tt_populate callbacks staging: vboxvideo: remove ttm_pool_* wrappers drm/ttm: drop bo->glob drm/ttm: drop ttm->glob drm/ttm: drop ttm->dummy_read_page drm/ttm: drop persistent_swap_storage from ttm_bo_init and co drm/ttm: move ttm_tt_create into ttm_tt.c v2 drm/ttm: cleanup ttm_tt_create drm/amdgpu: move some functions into amdgpu_ttm.h drm/amdgpu: change amdgpu_ttm_set_active_vram_size drm/amdgpu: ignore changes of buffer function status because of GPU resets drm/amdgpu: use separate status for buffer funcs availability v2 drm/amd/pp: fix "Delete the wrapper layer of smu_allocate/free_memory" drm/amdgpu: add amdgpu_evict_gtt debugfs entry drm/amdgpu: drop gtt->adev drm/amdgpu: further mitigate workaround for i915 Corentin Labbe (2): drm/amd: remove inclusion of non-existing scheduler directory drm/amd: Remove inclusion of non-existing include directories Dmytro Laktyushkin (4): drm/amd/display: Update DCN OPTC registers drm/amd/display: add per pipe dppclk drm/amd/display: add diags clock programming drm/amd/display: fix dcn1 dppclk when min dispclk patch applies Emily Deng (2): drm/amdgpu: Correct sdma_v4 get_wptr(v2) drm/amdgpu: Clean sdma wptr register when only enable wptr polling Eric Bernstein (1): drm/amd/display: Fix DAL surface change test Eric Huang (2): drm/amd/powerplay: fix thermal interrupts on vega10 drm/amd/powerplay: fix power over limit on Fiji Eric Yang (2): drm/amd/display: fix missing az disable in reset backend drm/amd/display: update infoframe after dig fe is turned on Harry Wentland (6): drm/amd/display: Remove duplicate dm_pp_power_level enum drm/amd/display: Use crtc enable/disable_vblank hooks drm/amd/display: Return success when enabling interrupt drm/amd/display: Clean up formatting in irq_service_dce110.c drm/amd/display: Don't blow up if TG is NULL in dce110_vblank_set drm/amd/display: Default HDMI6G support to true. Log VBIOS table error. Hersen Wu (2): drm/amd/display: move MST branch initialize to before link training drm/amd/display: Check DCN PState ASSERT failure James Zhu (3): drm/amdgpu:Fixed wrong emit frame size for enc drm/amdgpu:Correct max uvd handles drm/amdgpu:Always save uvd vcpu_bo in VM Mode John Barberiz (1): drm/amd/display: Add passive dongle support for HPD Rearch Leo (Sunpeng) Li (2): drm/amd/display: Use 4096 lut entries drm/amd/display: Add regamma lut write mask to SOC base Matthias Kaehlcke (1): drm/radeon/mkregtable: Delete unused list functions and macros Michel Dänzer (1): drm/amdgpu/dce6: Use DRM_DEBUG instead of DRM_INFO for HPD IRQ info Monk Liu (15): drm/amdgpu: fix&cleanups for wb_clear drm/amdgpu: skip ECC for SRIOV in gmc late_init drm/amdgpu: only flush hotplug work without DC drm/amdgpu: cond_exec only f
[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume
https://bugzilla.kernel.org/show_bug.cgi?id=199047 --- Comment #2 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- (In reply to Alex Deucher from comment #1) > Are you using DC? Please attach your dmesg output. Not using DC. dmesg after a S3 suspend/resume cycle attached -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume
https://bugzilla.kernel.org/show_bug.cgi?id=199047 --- Comment #3 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- Created attachment 274617 --> https://bugzilla.kernel.org/attachment.cgi?id=274617&action=edit dmesg.log -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104717] Rocket League: grass rendering broken with nir
https://bugs.freedesktop.org/show_bug.cgi?id=104717 --- Comment #3 from Timothy Arceri --- This series should fix the regression. Thanks for reporting it. https://patchwork.freedesktop.org/series/39565/ -- 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 199047] [amdgpu CARRIZO] disabled backlight after S3 resume
https://bugzilla.kernel.org/show_bug.cgi?id=199047 --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- Does it work with DC enabled? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
From: Matt Atwood
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.
With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
To avoid breaking panels that are not spec compiant we now warn on
invalid values.
V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/drm_dp_helper.c | 18 ++
include/drm/drm_dp_helper.h | 4
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..671b823 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
rd_interval);
+
+ if(rd_interval == 0 || (dpcd[DP_DPCD_REV] & DP_REV_14))
udelay(100);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4)
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
rd_interval);
+
+ if (rd_interval == 0)
udelay(400);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4);
}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..5bac397 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,9 @@
/* AUX CH addresses */
/* DPCD */
#define DP_DPCD_REV 0x000
+# define DP_REV_12 0x012
+# define DP_REV_13 0x013
+# define DP_REV_14 0x014
#define DP_MAX_LINK_RATE0x001
@@ -118,6 +121,7 @@
# define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
#define DP_ADAPTER_CAP 0x00f /* 1.2 */
# define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
On Wed, Mar 7, 2018 at 6:44 PM, wrote:
> From: Matt Atwood
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
>
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
>
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
>
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/drm_dp_helper.c | 18 ++
> include/drm/drm_dp_helper.h | 4
> 2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..671b823 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
> rd_interval);
> +
> + if(rd_interval == 0 || (dpcd[DP_DPCD_REV] & DP_REV_14))
Was this meant to be dpcd[DP_DPCD_REV] >= DP_REV_14? It doesn't appear
to be a bitmask...
Also I think you're supposed to say "if (" rather than "if(".
-ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch 1/1] drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union initializer issue
From: Andrew Morton
Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union
initializer issue
gcc-4.4.4 has problems with initalizers of anon unions.
drivers/gpu/drm/i915/intel_guc_log.c: In function 'guc_log_control':
drivers/gpu/drm/i915/intel_guc_log.c:64: error: unknown field 'logging_enabled'
specified in initializer
Work around this.
Fixes: 35fe703c3161 ("drm/i915/guc: Change values for i915_guc_log_control")
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Andrew Morton
---
drivers/gpu/drm/i915/intel_guc_log.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff -puN
drivers/gpu/drm/i915/intel_guc_log.c~drivers-gpu-drm-i915-intel_guc_logc-work-around-gcc-444-union-initializer-issue
drivers/gpu/drm/i915/intel_guc_log.c
---
a/drivers/gpu/drm/i915/intel_guc_log.c~drivers-gpu-drm-i915-intel_guc_logc-work-around-gcc-444-union-initializer-issue
+++ a/drivers/gpu/drm/i915/intel_guc_log.c
@@ -61,8 +61,10 @@ static int guc_log_flush(struct intel_gu
static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity)
{
union guc_log_control control_val = {
- .logging_enabled = enable,
- .verbosity = verbosity,
+ {
+ .logging_enabled = enable,
+ .verbosity = verbosity,
+ },
};
u32 action[] = {
INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING,
_
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
On Wed, Mar 07, 2018 at 03:44:09PM -0800, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
>
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
>
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
>
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/drm_dp_helper.c | 18 ++
> include/drm/drm_dp_helper.h | 4
> 2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..671b823 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
> rd_interval);
I thought there were comments about setting this to a max of 4 if its greater
than 4.
> +
> + if(rd_interval == 0 || (dpcd[DP_DPCD_REV] & DP_REV_14))
^ space needed between if and open bracket
> udelay(100);
> else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4)
> }
> EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>
> void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
> rd_interval);
> +
> + if (rd_interval == 0)
> udelay(400);
> else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
> }
> EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..5bac397 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,9 @@
> /* AUX CH addresses */
> /* DPCD */
> #define DP_DPCD_REV 0x000
> +# define DP_REV_12 0x012
> +# define DP_REV_13 0x013
> +# define DP_REV_14 0x014
>
IMHO, if we are creating these #defines for revisions then we should
do it for all values so 0x10, 0x11.
Manasi
> #define DP_MAX_LINK_RATE0x001
>
> @@ -118,6 +121,7 @@
> # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher
> */
>
> #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
>
> #define DP_ADAPTER_CAP 0x00f /* 1.2 */
> # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
From: Matt Atwood
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.
With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
To avoid breaking panels that are not spec compiant we now warn on
invalid values.
V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/drm_dp_helper.c | 18 ++
include/drm/drm_dp_helper.h | 6 ++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..6985ff3 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
rd_interval);
+
+ if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
udelay(100);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4)
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
rd_interval);
+
+ if (rd_interval == 0)
udelay(400);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4);
}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..1269ef8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
/* AUX CH addresses */
/* DPCD */
#define DP_DPCD_REV 0x000
+# define DP_REV_10 0x10
+# define DP_REV_11 0x11
+# define DP_REV_12 0x12
+# define DP_REV_13 0x13
+# define DP_REV_14 0x14
#define DP_MAX_LINK_RATE0x001
@@ -118,6 +123,7 @@
# define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
#define DP_ADAPTER_CAP 0x00f /* 1.2 */
# define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104717] Rocket League: grass rendering broken with nir
https://bugs.freedesktop.org/show_bug.cgi?id=104717 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Timothy Arceri --- This should be fixed by: commit 0c90264da4139805d34f530485a678c53809932e Author: Timothy Arceri Date: Thu Mar 8 09:46:42 2018 +1100 ac/radeonsi: add emit_kill to the abi This should fix a regression with Rocket League grass rendering on the NIR backend. Reviewed-by: Marek Olšák Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104717 If you are still having problems feel free to reopen the bug. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
From: Matt Atwood
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.
With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
To avoid breaking panels that are not spec compiant we now warn on
invalid values.
V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/drm_dp_helper.c | 18 ++
include/drm/drm_dp_helper.h | 6 ++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..cdb04c9 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
rd_interval);
+
+ if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
udelay(100);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4);
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)",
rd_interval);
+
+ if (rd_interval == 0)
udelay(400);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4);
}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..1269ef8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
/* AUX CH addresses */
/* DPCD */
#define DP_DPCD_REV 0x000
+# define DP_REV_10 0x10
+# define DP_REV_11 0x11
+# define DP_REV_12 0x12
+# define DP_REV_13 0x13
+# define DP_REV_14 0x14
#define DP_MAX_LINK_RATE0x001
@@ -118,6 +123,7 @@
# define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
#define DP_ADAPTER_CAP 0x00f /* 1.2 */
# define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
