Re: [PATCH v2 00/10] Enable HDMI Stereoscopy
On Mon, Mar 27, 2017 at 05:57:57PM -0400, Alastair Bridgewater wrote: > HDMI 3D mode support, round two. Revisions include no longer dealing > with audio InfoFrames, passing infoframe data to NVKM as bags of bytes > rather than as data pre-packed for the hardware, more-normal return > value checking for drm_hdmi_*_infoframe_from_display_mode() results, > Frame-Packing mode support, more-principled logic for enabling stereo > mode support on a connector, and support for all four nv50+ DISPs. > Additionally, this patch set is being sent to the dri-devel list as > well as the nouveau list. Dropped in this version is the removal of > the "mandatory" 3D mode logic. After discussion, I'm still convinced > that it's wrong, but now I'm convinced that it's too conservative > rather than my original belief which was that it was too liberal. > > Thanks to Ilia Mirkin, Damien Lespiau, and Ben Skeggs for feedback on > the original patch set. If I have neglected to mention anyone, mea > culpa. > > The first patch perhaps isn't technically necessary, but simplifies > the later logic for fixing frame-packing mode timing. There may be > some effect from applying this, as drm_mode_set_crtcinfo() does > something with vscan which can affect the given CRTC timing. I'm > not sure what's going on there, if there's any behavioral change or > not, and if there is what to do about it (other than using > drm_mode_set_crtcinfo() twice, once with CRTC_NO_VSCAN and once > without). > > The second through eighth patches are all the InfoFrame logic again, > this time with support for all four DISP types. This does not appear > to cause regressions in HDMI audio on GT215, GF119, or GK104. I hope > that it doesn't cause a regression on G84, but haven't yet managed to > set up a test case for G84 and HDMI audio. > > The ninth patch is to fix up frame-packing mode timings and geometry. > As the patch comment says, there are clearly-correct parts, and there > are possibly-hacky parts. But it gets frame-packing modes working, > and we can revise from there if necessary. > > And the tenth patch enables stereo mode support... on HDMI and DPort > connectors on nv50+ hardware. HDMI connectors because obvious. DPort > connectors because of DPort to HDMI adaptors. Do you mean DP++ or actual protocol converters? DP++ is just HDMI with a some electrical tweaks, but IIRC proper DP defines 3D stereo quite differently than HDMI. I'm not sure if we should be able to push HDMI style 3D through DP->HDMI/DP++ adaptors. The specs are unfortunately very vague when it comes to such devices. > eDP connectors because > it shouldn't do any harm, and someone might have been maniac enough to > set up an eDP port to point to something with an HDMI 3D setup. And > nv50+ hardware only because while I'm not aware of any pre-nv50 cards > that have HDMI outputs, there could be a setup out there like the PS3 > that uses an external HDMI encoder on pre-nv50 hardware, at which > point none of the mode timing or InfoFrame support is in place for it. > > Alastair Bridgewater (10): > drm/nouveau: Use drm_mode_set_crtcinfo() to compensate for vscan / > ilace > drm/nouveau: Extend NVKM HDMI power control method to set InfoFrames > drm/nouveau: Pass mode-dependent AVI and Vendor HDMI InfoFrames to > NVKM > drm/nouveau: Add mechanism to convert HDMI InfoFrames to hardware > format > drm/nouveau: Use supplied HDMI InfoFrames on G84 hardware > drm/nouveau: Use supplied HDMI InfoFrames on GT215 hardware > drm/nouveau: Use supplied HDMI InfoFrames on GF119 hardware > drm/nouveau: Use supplied HDMI InfoFrames on GK104 hardware > drm/nouveau: Handle frame-packing mode geometry and timing effects > drm/nouveau: Enable stereoscopic 3D output over HDMI > > drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 4 +- > drivers/gpu/drm/nouveau/nouveau_connector.c| 10 +++ > drivers/gpu/drm/nouveau/nv50_display.c | 80 > -- > drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 + > .../drm/nouveau/nvkm/engine/disp/hdmi_infoframe.c | 66 ++ > drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmig84.c | 46 +++-- > .../gpu/drm/nouveau/nvkm/engine/disp/hdmigf119.c | 49 +++-- > .../gpu/drm/nouveau/nvkm/engine/disp/hdmigk104.c | 45 ++-- > .../gpu/drm/nouveau/nvkm/engine/disp/hdmigt215.c | 46 +++-- > drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.h| 11 +++ > 10 files changed, 307 insertions(+), 51 deletions(-) > create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmi_infoframe.c > > -- > 2.10.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinf
Re: [PATCHv3 00/30] drm/omap: miscallaneous improvements
Hi Tomi, On Tuesday 28 Mar 2017 16:07:46 Tomi Valkeinen wrote: > This is the third revision of this series. Note that this series depends on > "drm/atomic: Introduce drm_atomic_helper_shutdown" which has not yet been > merged to drm-next. I've reviewed all patches but the omapdss-base split. While it doesn't look bad to me, it's hard to judge whether the code is correctly architectured without seeing the omapdss6 driver. > The main changes in v3: > > - improve variable names in 'work-around for errata i886' > - drop 'Init fbdev emulation only when we have displays' > - drop 'Create fbdev emulation only for the first DRM connector' > - add 'use drm_atomic_helper_shutdown' > - change 'fix crash on module unload' based on drm_atomic_helper_shutdown > change. > > The main changes in v2: > > - Interrupt based HPD removed, as there's a race issue which needs to be > fixed > - Added patch to fix module unload crash, introduced in drm-next > - Drop changes affecting userspace APIs > > > Hemant Hariyani (1): > drm/omap: Add support for render nodes > > Peter Ujfalusi (6): > drm/omap: dss: Functions to check components in the display/output > list > drm/omap: dss: Support for detecting display stack readiness > drm/omap: Use omapdss_stack_is_ready() to check that the display stack > is up > drm/omap: display: Add displays in sorted order to the panel_list > drm/omap: poll only connectors where the connect/disconnect can be > checked > drm/omap: displays: panel-dpi: Support for handling backlight devices > > Tomi Valkeinen (23): > drm/omap: work-around for errata i886 > drm/omap: refactor CRTC HW property setup > drm/omap: remove divider constraint from hsdiv > drm/omap: decrease min width & height > drm/omap: improve DPI clock selection on DRA7xx > drm/omap: fix HDMI sync polarities > drm/omap: add omapdss-base.ko > drm/omap: move dss_initialized to omapdss-base > drm/omap: output: use dev_err instead of DSSERR > drm/omap: display: don't use dsi_get_pixel_size() > drm/omap: move display, dss-of, output to omapdss-base > drm/omap: move dispc related dss-feat funcs to dispc > drm/omap: add dispc_ops > drm/omap: fill dispc_ops > drm/omap: use dispc_ops > drm/omap: remove all EXPORT_SYMBOLs from dispc.c > drm/omap: remove unused dispc_wb_enable & dispc_wb_is_enabled > drm/omap: fix replication logic > drm/omap: fix plane update warning when crtc is disabled > drm/omap: dispc: improve debug print of display flags > drm/omap: fix display SYNC/DE flags > drm/omap: use drm_atomic_helper_shutdown() > drm/omap: fix crash on module unload > > drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 37 +- > drivers/gpu/drm/omapdrm/dss/Kconfig | 4 + > drivers/gpu/drm/omapdrm/dss/Makefile | 8 +- > drivers/gpu/drm/omapdrm/dss/base.c | 140 +++ > drivers/gpu/drm/omapdrm/dss/dispc.c | 165 +++- > drivers/gpu/drm/omapdrm/dss/display.c| 36 +- > drivers/gpu/drm/omapdrm/dss/dpi.c| 55 ++--- > drivers/gpu/drm/omapdrm/dss/dsi.c| 2 +- > drivers/gpu/drm/omapdrm/dss/dss-of.c | 3 +- > drivers/gpu/drm/omapdrm/dss/dss.c| 13 +-- > drivers/gpu/drm/omapdrm/dss/dss.h| 17 +-- > drivers/gpu/drm/omapdrm/dss/dss_features.c | 3 - > drivers/gpu/drm/omapdrm/dss/dss_features.h | 4 + > drivers/gpu/drm/omapdrm/dss/hdmi_wp.c| 12 +- > drivers/gpu/drm/omapdrm/dss/omapdss.h| 95 +-- > drivers/gpu/drm/omapdrm/dss/output.c | 27 - > drivers/gpu/drm/omapdrm/dss/pll.c| 17 +-- > drivers/gpu/drm/omapdrm/omap_connector.c | 12 +- > drivers/gpu/drm/omapdrm/omap_crtc.c | 87 ++ > drivers/gpu/drm/omapdrm/omap_drv.c | 45 +--- > drivers/gpu/drm/omapdrm/omap_drv.h | 2 + > drivers/gpu/drm/omapdrm/omap_irq.c | 47 +++- > drivers/gpu/drm/omapdrm/omap_plane.c | 20 +++- > 23 files changed, 588 insertions(+), 263 deletions(-) > create mode 100644 drivers/gpu/drm/omapdrm/dss/base.c -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 06/30] drm/omap: Add support for render nodes
Hi Tomi, (CC'ing Daniel and David) On Wednesday 29 Mar 2017 11:58:23 Tomi Valkeinen wrote: > On 29/03/17 11:22, Laurent Pinchart wrote: > > Hi Tomi, > > > > Thank you for the patch. > > > > On Tuesday 28 Mar 2017 16:07:52 Tomi Valkeinen wrote: > >> From: Hemant Hariyani > >> > >> Add support for render nodes in omap driver and allow required > >> ioctls to be accessible via render nodes. > > > > But the OMAP DSS doesn't perform rendering... This seems an abuse of > > render nodes, I think the API should instead be implemented by the GPU > > driver. > > I agree that the GPU use case described in the patch sounds a bit odd. > Why not allocate from the GPU driver instead. But here a particular > issue is that to get TILER buffers we need to ask them from the omapdrm. > Probably TILER should not be part of omapdrm, but then, where should it > be... > > We also have writeback in DSS, which can function as a memory to memory > or capture device. That's not supported in the mainline, but we have > support in the TI kernel. > > And how about a case where you have the privileged process as KMS > master, and another process wants to draw to a buffer with the CPU, and > then give the buffer to the privileged process for displaying. > > So, yes, DSS is not a renderer (well, WB is kind of rendering), but > isn't it a valid use case to allocate a buffer from omapdrm? It could be a valid use case, but it's still an API abuse. It starts sounding like a DRM core issue to me. The DRIVER_RENDER flag is not documented, so its exact meaning isn't defined. I thought it was supposed to flag the device as a renderer (GPU). commit 1793126fcebd7c18834f95d43b55e387a8803aa8 Author: David Herrmann Date: Sun Aug 25 18:29:00 2013 +0200 drm: implement experimental render nodes Render nodes provide an API for userspace to use non-privileged GPU commands without any running DRM-Master. It is useful for offscreen rendering, GPGPU clients, and normal render clients which do not perform modesetting. [...] You instead use the flag as a way to enable unprivileged clients to allocate buffers. If that's what the flag should mean, I wonder if there would be a use case for *not* setting it. > Also, where should a buffer be allocated from, generally? I usually > think that if a buffer is going to DSS, I allocate it from omapdrm. Then > again, getting it from the source sounds ok also, i.e. from a v4l2 > capture driver... But if we get it from the source, it may not be usable > by all the components in the processing pipeline (e.g, SGX requires 32 > pixel aligned buffers). -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/15] dt-bindings: display: sun4i: Add allwinner,tcon-channel property
On Tue, Mar 28, 2017 at 06:05:08PM +0800, Icenowy Zheng wrote: > > 2017年3月27日 上午5:11于 Maxime Ripard 写道： > > > > On Fri, Mar 17, 2017 at 11:34:45AM +0800, Chen-Yu Tsai wrote: > > > On Thu, Mar 16, 2017 at 1:37 AM, Rob Herring wrote: > > > > On Tue, Mar 07, 2017 at 09:56:26AM +0100, Maxime Ripard wrote: > > > >> The Allwinner Timings Controller has two, mutually exclusive, > > > >> channels. > > > >> When the binding has been introduced, it was assumed that there would > > > >> be > > > >> only a single user per channel in the system. > > > >> > > > >> While this is likely for the channel 0 which only connects to LCD > > > >> displays, > > > >> it turns out that the channel 1 can be connected to multiple > > > >> controllers in > > > >> the SoC (HDMI and TV encoders for example). And while the simultaneous > > > >> use > > > >> of HDMI and TV outputs cannot be achieved, switching from one to the > > > >> other > > > >> at runtime definitely sounds plausible. > > > >> > > > >> Add an extra property, allwinner,tcon-channel, to specify for a given > > > >> endpoint which TCON channel it is connected to, while falling back to > > > >> the > > > >> previous mechanism if that property is missing. > > > > > > > > I think perhaps TCON channels should have been ports rather than > > > > endpoints. The fact that the channels are mutually exclusive can be > > > > handled in the driver and doesn't really matter in the binding. How > > > > painful would it be to rework things to move TCON channel 1 from port > > > > 0, > > > > endpoint 1 to port 1? > > > > > > Having a separate output port for channel 1 was one option we discussed. > > > However it wouldn't work well with the kernel's of_graph based crtc > > > detection (drm_of_find_possible_crtcs / drm_of_find_possible_crtcs), > > > which has the crtcs bound via the output port. As the logic is used > > > by multiple drivers, I'm not sure it's easy to rework or test. > > > > Can't we use a different logic than drm_of_find_possible_crtcs to fill > > the same role? > > > > > Also, we still have to support old device trees using channel 1 from > > > output port 0 endpoint 1. This is the TV encoder on sun5i (A10s/A13/R8). > > And from A83T on we will face channel-1 only TCONs., which do not > have channel 0 at all in hardware. Yes, but those patches have not been merged yet, so we don't have to care about the backward compatibility. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93199] IGT: Couldn't map MMIO region
https://bugs.freedesktop.org/show_bug.cgi?id=93199 Jari Tahvanainen changed: What|Removed |Added Component|DRM/Intel |IGT Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Status|REOPENED|NEEDINFO --- Comment #23 from Jari Tahvanainen --- Moving this from DRM/Intel to IGT, since it seems to be problem with that. Sean, Jonathan, Dimitry and Rami - please check if this problem is still valid with the latest igt. -- 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: [PATCHv3 06/30] drm/omap: Add support for render nodes
Hi On Wed, Mar 29, 2017 at 2:20 PM, Laurent Pinchart wrote: > Hi Tomi, > > (CC'ing Daniel and David) > > On Wednesday 29 Mar 2017 11:58:23 Tomi Valkeinen wrote: >> On 29/03/17 11:22, Laurent Pinchart wrote: >> > Hi Tomi, >> > >> > Thank you for the patch. >> > >> > On Tuesday 28 Mar 2017 16:07:52 Tomi Valkeinen wrote: >> >> From: Hemant Hariyani >> >> >> >> Add support for render nodes in omap driver and allow required >> >> ioctls to be accessible via render nodes. >> > >> > But the OMAP DSS doesn't perform rendering... This seems an abuse of >> > render nodes, I think the API should instead be implemented by the GPU >> > driver. >> >> I agree that the GPU use case described in the patch sounds a bit odd. >> Why not allocate from the GPU driver instead. But here a particular >> issue is that to get TILER buffers we need to ask them from the omapdrm. >> Probably TILER should not be part of omapdrm, but then, where should it >> be... >> >> We also have writeback in DSS, which can function as a memory to memory >> or capture device. That's not supported in the mainline, but we have >> support in the TI kernel. >> >> And how about a case where you have the privileged process as KMS >> master, and another process wants to draw to a buffer with the CPU, and >> then give the buffer to the privileged process for displaying. >> >> So, yes, DSS is not a renderer (well, WB is kind of rendering), but >> isn't it a valid use case to allocate a buffer from omapdrm? > > It could be a valid use case, but it's still an API abuse. It starts sounding > like a DRM core issue to me. The DRIVER_RENDER flag is not documented, so its > exact meaning isn't defined. I thought it was supposed to flag the device as a > renderer (GPU). > > commit 1793126fcebd7c18834f95d43b55e387a8803aa8 > Author: David Herrmann > Date: Sun Aug 25 18:29:00 2013 +0200 > > drm: implement experimental render nodes > > Render nodes provide an API for userspace to use non-privileged GPU > commands without any running DRM-Master. It is useful for offscreen > rendering, GPGPU clients, and normal render clients which do not perform > modesetting. > > [...] > > You instead use the flag as a way to enable unprivileged clients to allocate > buffers. If that's what the flag should mean, I wonder if there would be a use > case for *not* setting it. Correct. You can (and should) enable all your sandboxed commands on render nodes. That is, if a command only affects the issuing client, then it is safe for render-nodes. If two clients have a file-context opened on the render node, they should be unable to affect each other (minus accounting, resource allocation, etc.). The name is historic (I did not come up with it either, but failed at renaming it..). The DRIVER_RENDER flag only controls whether the render-node is actually instantiated. I will not object doing that unconditionally. It will create some useless nodes for legacy drivers, but we should not care. Thanks David ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Fix IB va_start+ib_bytes range check on 32Bit systems
Am 29.03.2017 um 11:18 schrieb Jan Burgmeier:
Signed-off-by: Jan Burgmeier
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 99424cb8020b..583d22974e14 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -908,6 +908,7 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,
struct amdgpu_bo *aobj = NULL;
uint64_t offset;
uint8_t *kptr;
+ uint64_t it_last;
m = amdgpu_cs_find_mapping(parser, chunk_ib->va_start,
&aobj);
@@ -916,8 +917,9 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,
return -EINVAL;
}
+ it_last = m->it.last;
if ((chunk_ib->va_start + chunk_ib->ib_bytes) >
- (m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
+ (it_last + 1) * AMDGPU_GPU_PAGE_SIZE) {
Nice catch, but just adding a u64 case should do here as well. E.g:
if ((chunk_ib->va_start + chunk_ib->ib_bytes) >
(u64)(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
With that fixed the patch is Reviewed-by: Christian König
.
Regards,
Christian.
DRM_ERROR("IB va_start+ib_bytes is invalid\n");
return -EINVAL;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes.
On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote:
> mode_valid() and get_modes() called
> from drm_helper_probe_single_connector_modes()
> may need to look at connector->state because what a valid mode is may
> depend on connector properties being set. For example some HDMI modes
> might be rejected when a connector property forces the connector
> into DVI mode.
>
> Some implementations of detect() already lock all state,
> so we have to pass an acquire_ctx to them to prevent a deadlock.
>
> This means changing the function signature of detect() slightly,
> and passing the acquire_ctx for locking multiple crtc's.
> It might be NULL, in which case expensive operations should be avoided.
>
> intel_dp.c however ignores the force flag, so still lock
> connection_mutex there if needed.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Boris Brezillon
> Cc: Manasi Navare
Hm only noticed this now, but mixing up force with the acquire_ctx sounds
like very bad interface design. Yes, the only user of the new hook works
like that, but that's really accidental I think. I think just having the
ctx everywhere (for atomic drivers at least) would be a lot safer. This is
extremely surprising (and undocumented suprise at that).
> ---
> drivers/gpu/drm/drm_probe_helper.c | 41
> ++--
> drivers/gpu/drm/i915/intel_crt.c | 29 +
> drivers/gpu/drm/i915/intel_display.c | 25 +++---
> drivers/gpu/drm/i915/intel_dp.c | 22 ---
> drivers/gpu/drm/i915/intel_drv.h | 8 +++
> drivers/gpu/drm/i915/intel_hotplug.c | 6 +-
> drivers/gpu/drm/i915/intel_tv.c | 24 ++---
> include/drm/drm_connector.h | 5 +
> 8 files changed, 101 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 85005d57bde6..a48cff963871 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -169,11 +169,15 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
> EXPORT_SYMBOL(drm_kms_helper_poll_enable);
>
> static enum drm_connector_status
> -drm_connector_detect(struct drm_connector *connector, bool force)
> +drm_connector_detect(struct drm_connector *connector,
> + struct drm_modeset_acquire_ctx *ctx)
> {
> - return connector->funcs->detect ?
> - connector->funcs->detect(connector, force) :
> - connector_status_connected;
> + if (connector->funcs->detect_ctx)
> + return connector->funcs->detect_ctx(connector, ctx);
> + else if (connector->funcs->detect)
> + return connector->funcs->detect(connector, !!ctx);
> + else
> + return connector_status_connected;
> }
>
> /**
> @@ -239,15 +243,27 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> struct drm_display_mode *mode;
> const struct drm_connector_helper_funcs *connector_funcs =
> connector->helper_private;
> - int count = 0;
> + int count = 0, ret;
> int mode_flags = 0;
> bool verbose_prune = true;
> enum drm_connector_status old_status;
> + struct drm_modeset_acquire_ctx ctx;
>
> WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>
> + drm_modeset_acquire_init(&ctx, 0);
> +
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> connector->name);
> +
> +retry:
> + ret = drm_modeset_lock(&dev->mode_config.connection_mutex, &ctx);
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff(&ctx);
> + goto retry;
> + } else
> + WARN_ON(ret < 0);
> +
> /* set all old modes to the stale state */
> list_for_each_entry(mode, &connector->modes, head)
> mode->status = MODE_STALE;
> @@ -263,7 +279,15 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> if (connector->funcs->force)
> connector->funcs->force(connector);
> } else {
> - connector->status = drm_connector_detect(connector, true);
> + ret = drm_connector_detect(connector, &ctx);
> +
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff(&ctx);
> + goto retry;
> + } else if (WARN(ret < 0, "Invalid return value %i for connector
> detection\n", ret))
> + ret = connector_status_unknown;
> +
> + connector->status = ret;
> }
>
> /*
> @@ -355,6 +379,9 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> prune:
> drm_mode_prune_invalid(dev, &connector->modes, verbose_prune);
>
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +
> if (list_empty(&connector->modes))
> return 0;
>
> @@ -440,7 +467
Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes.
On Wed, 29 Mar 2017 15:26:45 +0200 Daniel Vetter wrote: > On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote: > > mode_valid() and get_modes() called > > from drm_helper_probe_single_connector_modes() > > may need to look at connector->state because what a valid mode is may > > depend on connector properties being set. For example some HDMI modes > > might be rejected when a connector property forces the connector > > into DVI mode. > > > > Some implementations of detect() already lock all state, > > so we have to pass an acquire_ctx to them to prevent a deadlock. > > > > This means changing the function signature of detect() slightly, > > and passing the acquire_ctx for locking multiple crtc's. > > It might be NULL, in which case expensive operations should be avoided. > > > > intel_dp.c however ignores the force flag, so still lock > > connection_mutex there if needed. > > > > Signed-off-by: Maarten Lankhorst > > Cc: Boris Brezillon > > Cc: Manasi Navare > > Hm only noticed this now, but mixing up force with the acquire_ctx sounds > like very bad interface design. Yes, the only user of the new hook works > like that, but that's really accidental I think. I think just having the > ctx everywhere (for atomic drivers at least) would be a lot safer. This is > extremely surprising (and undocumented suprise at that). Yes, I was about to say the same thing: the interface is not very clear, and I don't understand why ctx = NULL implies force = false. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/arcpgu: Get rid of "encoder-slave" property
On Wed, Mar 29, 2017 at 01:34:00PM +, Alexey Brodkin wrote:
> Hi Liviu, Rob,
Hi Alexey,
>
> On Fri, 2017-03-03 at 18:21 +, liviu.du...@arm.com wrote:
> > On Fri, Mar 03, 2017 at 05:48:19PM +, Alexey Brodkin wrote:
> > >
> > > Hi Liviu,
> > >
> > > On Fri, 2017-03-03 at 16:28 +, Liviu Dudau wrote:
> > > >
> > > > On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote:
> > > > >
> > > > >
> > > > > - /* find the encoder node and initialize it */
> > > > > - encoder_node = of_parse_phandle(drm->dev->of_node,
> > > > > "encoder-slave", 0);
> > > > > - if (encoder_node) {
> > > > > - ret = arcpgu_drm_hdmi_init(drm, encoder_node);
> > > > > - of_node_put(encoder_node);
> > > > > + /* There is only one output port inside each device, find it */
> > > > > + port = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
> > > > > +
> > > > > + if (port) {
> > > > > + if (of_device_is_available(port))
> > > > > + encoder = of_graph_get_remote_port_parent(port);
> > > > > + of_node_put(port);
> > > > > + }
> > > >
> > > > You must've been looking at some old version. Current version in -next
> > > > uses
> > > > of_graph_get_remote_node() to replace all those lines you have added
> > > > (see Rob
> > > > Herring's series to introduce of_graph_get_remote_node() function)
> > >
> > > Hm, I'm not on Linus' master tree [1] and so I thought I was quite up to
> > > date :)
> > > Still I made a check of linux-next and don't see any changes in
> > > "drivers/gpu/drm/arm" compared to Linus' tree.
> > >
> > > [1]
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_cgit_linux_kernel_git_torvalds_linux.git_commit_drivers_gpu_drm_arm-3Fid-3D
> > > e4563f6ba71792c77aeccb2092cc23149b44e642&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SI66ngnnXy33ncb8m5H4La2
> > > T1SzSEiiP7hc_XsRahEc&s=uaswjVXcjYDrUosOkO_UpTMqJMWTT-LLPrg5JE6-t-8&e=
> > > [2]
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_cgit_linux_kernel_git_next_linux-2Dnext.git_commit_drivers_gpu_drm_arm-3Fid
> > > -3De4563f6ba71792c77aeccb2092cc23149b44e642&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=SI66ngnnXy33ncb8m5H4
> > > La2T1SzSEiiP7hc_XsRahEc&s=hl9Y6s3K9LwLL1M2WnL3ODax_V-ZRh8k1iTiyctIqU4&e=
> > >
> > > Could you please clarify which exact tree did you mean?
> >
> > Sorry, I thought the series got pulled by one of the DRM trees, but it
> > looks like
> > I was wrong. I was carrying a private copy in my internal tree, waiting for
> > the
> > moment when it got pulled into drm-next or drm-misc-next.
> >
> > Rob, do you have an update on your series introducing
> > of_graph_get_remote_node() ?
>
> For some reason I cannot find any relevant commits in linux-next tree even
> today.
> Could you please point me to either any random git tree with mentioned above
> change or
> maybe just mailing list where this patch was sent?
Not sure why Rob hasn't added it to linux-next, but (according to Rob) this is
the latest version:
https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/log/?h=of-graph-helpers
Best regards,
Liviu
>
> I'd like to implement the same fix in ARCPGU and call it a day finally.
>
> -Alexey
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes.
Op 29-03-17 om 15:31 schreef Boris Brezillon: > On Wed, 29 Mar 2017 15:26:45 +0200 > Daniel Vetter wrote: > >> On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote: >>> mode_valid() and get_modes() called >>> from drm_helper_probe_single_connector_modes() >>> may need to look at connector->state because what a valid mode is may >>> depend on connector properties being set. For example some HDMI modes >>> might be rejected when a connector property forces the connector >>> into DVI mode. >>> >>> Some implementations of detect() already lock all state, >>> so we have to pass an acquire_ctx to them to prevent a deadlock. >>> >>> This means changing the function signature of detect() slightly, >>> and passing the acquire_ctx for locking multiple crtc's. >>> It might be NULL, in which case expensive operations should be avoided. >>> >>> intel_dp.c however ignores the force flag, so still lock >>> connection_mutex there if needed. >>> >>> Signed-off-by: Maarten Lankhorst >>> Cc: Boris Brezillon >>> Cc: Manasi Navare >> Hm only noticed this now, but mixing up force with the acquire_ctx sounds >> like very bad interface design. Yes, the only user of the new hook works >> like that, but that's really accidental I think. I think just having the >> ctx everywhere (for atomic drivers at least) would be a lot safer. This is >> extremely surprising (and undocumented suprise at that). > Yes, I was about to say the same thing: the interface is not very > clear, and I don't understand why ctx = NULL implies force = false. They're the same thing I fear. I could perhaps call it force_ctx instead, but non-zero ctx implies force, and other way around. Though I guess we could relax it, and have force = true imply ctx, but not the other way around. Would that be ok? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: don't link DP aux i2c adapter to the hardware device node
On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding wrote: > On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote: >> The i2c adapter on DP AUX is purely a software construct. Linking >> it to the device node of the parent device is wrong, as it leads to >> 2 devices sharing the same device node, which is bad practice, as > > Who says that two devices can't share the same device node? It's done > all the time. It's done *some of the time* and I would not consider it best practice. >> well as the i2c trying to populate children of the i2c adapter by >> looking at the child device nodes of the parent device. > > A set of patches landed in v4.9 to work around this issue in a better > way. See: > > 98b00488459e dt-bindings: i2c: Add support for 'i2c-bus' subnode > 7e4c224abfe8 i2c: core: Add support for 'i2c-bus' subnode What does this buy us? I don't see why this needs to be in DT either. Contrary to popular belief, DT is not the only way to instantiate devices, C code can still do it. Also, if this one line removal has no side effects, then how was it even needed? We can always add it back if there's some argument for why it is needed. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes.
On Wed, Mar 29, 2017 at 03:51:08PM +0200, Maarten Lankhorst wrote: > Op 29-03-17 om 15:31 schreef Boris Brezillon: > > On Wed, 29 Mar 2017 15:26:45 +0200 > > Daniel Vetter wrote: > > > >> On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote: > >>> mode_valid() and get_modes() called > >>> from drm_helper_probe_single_connector_modes() > >>> may need to look at connector->state because what a valid mode is may > >>> depend on connector properties being set. For example some HDMI modes > >>> might be rejected when a connector property forces the connector > >>> into DVI mode. > >>> > >>> Some implementations of detect() already lock all state, > >>> so we have to pass an acquire_ctx to them to prevent a deadlock. > >>> > >>> This means changing the function signature of detect() slightly, > >>> and passing the acquire_ctx for locking multiple crtc's. > >>> It might be NULL, in which case expensive operations should be avoided. > >>> > >>> intel_dp.c however ignores the force flag, so still lock > >>> connection_mutex there if needed. > >>> > >>> Signed-off-by: Maarten Lankhorst > >>> Cc: Boris Brezillon > >>> Cc: Manasi Navare > >> Hm only noticed this now, but mixing up force with the acquire_ctx sounds > >> like very bad interface design. Yes, the only user of the new hook works > >> like that, but that's really accidental I think. I think just having the > >> ctx everywhere (for atomic drivers at least) would be a lot safer. This is > >> extremely surprising (and undocumented suprise at that). > > Yes, I was about to say the same thing: the interface is not very > > clear, and I don't understand why ctx = NULL implies force = false. > > They're the same thing I fear. I could perhaps call it force_ctx instead, > but non-zero ctx implies force, and other way around. Though I guess we could > relax it, and have force = true imply ctx, but not the other way around. > > Would that be ok? Why can't we supply a ctx always? I didn't see any reason not to in the code ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] etnaviv-fixes for 4.11-rc5
Hi Dave, a single fix to keep fence seqnos of completed jobs monotonically increasing, as expected in various locations of the driver code. Also tagged for stable. Regards, Lucas The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: https://git.pengutronix.de/git/lst/linux etnaviv/fixes for you to fetch changes up to f3cd1b064f1179d9e6188c6d67297a2360880e10: drm/etnaviv: (re-)protect fence allocation with GPU mutex (2017-03-29 15:38:46 +0200) Lucas Stach (1): drm/etnaviv: (re-)protect fence allocation with GPU mutex drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 00/11] video/exynos/sti/cec: add CEC notifier & use in drivers
From: Hans Verkuil This patch series adds the CEC physical address notifier code, based on Russell's code: https://patchwork.kernel.org/patch/9277043/ It adds support for it to the exynos_hdmi drm driver, adds support for it to the CEC framework and finally adds support to the s5p-cec driver, which now can be moved out of staging. Also included is similar code for the STI platform, contributed by Benjamin Gaignard. Tested the exynos code with my Odroid U3 exynos4 devboard. After discussions with Daniel Vetter and Russell King I have removed the EDID/ELD/HPD connect/disconnect events from the notifier and now just use it to report the CEC physical address. This also means that it is now renamed to CEC notifier instead of HPD notifier and that it is now in drivers/media. The block_notifier was dropped as well and instead a simple callback is registered. This means that the relationship between HDMI and CEC is now 1:1 and no longer 1:n, but should this be needed in the future, then that can easily be added back. Daniel, regarding your suggestions here: http://www.spinics.net/lists/dri-devel/msg133907.html this patch series maps to your mail above as follows: struct cec_pin == struct cec_notifier cec_(un)register_pin == cec_notifier_get/put cec_set_address == cec_notifier_set_phys_addr cec_(un)register_callbacks == cec_notifier_(un)register Comments are welcome. I'd like to get this in for the 4.12 kernel as this is a missing piece needed to integrate CEC drivers. Regards, Hans Changes since v4: - Dropped EDID/ELD/connect/disconnect support. Instead, just report the CEC physical address (and use INVALID when disconnecting). - Since this is now completely CEC specific, move it to drivers/media and rename to cec-notifier. - Drop block_notifier. Instead just set a callback for the notifier. - Use 'hdmi-phandle' in the bindings for both exynos and sti. So no vendor prefix and 'hdmi-phandle' instead of 'hdmi-handle'. - Make struct cec_notifier opaque. Add a helper function to get the physical address from a cec_notifier struct. - Provide dummy functions in cec-notifier.h so it can be used when CONFIG_MEDIA_CEC_NOTIFIER is undefined. - Don't select the CEC notifier in the HDMI drivers. It should only be enabled by actual CEC drivers. Changes since v3: - Added the STI patches - Split the exynos4 binding patches in one for documentation and one for the dts change itself, also use the correct subject and CC to the correct mailinglists (I hope ) Changes since v2: - Split off the dts changes of the s5p-cec patch into a separate patch - Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name of the source. Changes since v1: Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is not HDMI specific, but is interesting for any video source that has to deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ). Only the use with CEC adapters is HDMI specific, but the HPD notifier is more generic. Benjamin Gaignard (4): sti: hdmi: add CEC notifier support stih-cec.txt: document new hdmi phandle stih-cec: add CEC notifier support arm: sti: update sti-cec for CEC notifier support Hans Verkuil (7): cec-edid: rename cec_get_edid_phys_addr media: add CEC notifier support cec: integrate CEC notifier support exynos_hdmi: add CEC notifier support ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi s5p-cec.txt: document the HDMI controller phandle s5p-cec: add cec-notifier support, move out of staging .../devicetree/bindings/media/s5p-cec.txt | 2 + .../devicetree/bindings/media/stih-cec.txt | 2 + MAINTAINERS| 4 +- arch/arm/boot/dts/exynos4.dtsi | 1 + arch/arm/boot/dts/stih407-family.dtsi | 12 --- arch/arm/boot/dts/stih410.dtsi | 13 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 20 +++- drivers/gpu/drm/sti/sti_hdmi.c | 11 ++ drivers/gpu/drm/sti/sti_hdmi.h | 3 + drivers/media/Kconfig | 3 + drivers/media/Makefile | 4 + drivers/media/cec-edid.c | 15 ++- drivers/media/cec-notifier.c | 116 + drivers/media/cec/cec-core.c | 21 drivers/media/i2c/adv7511.c| 5 +- drivers/media/i2c/adv7604.c| 3 +- drivers/media/i2c/adv7842.c| 2 +- drivers/media/platform/Kconfig | 28 + drivers/media/platform/Makefile| 2 + .../media => media/platform}/s5p-cec/Makefile | 0 .../platform}/s5p-cec/exynos_hdmi_cec.h| 0 .../platform}/s5p-cec/exynos_hdmi_cecctrl.c| 0 .../media => media/platform}/s5p-cec/regs-cec.h| 0 .../media => media/platform}/
[PATCHv5 02/11] media: add CEC notifier support
From: Hans Verkuil
Add support for CEC notifiers, which is used to convey CEC physical address
information from video drivers to their CEC counterpart driver(s).
Based on an earlier version from Russell King:
https://patchwork.kernel.org/patch/9277043/
The cec_notifier is a reference counted object containing the CEC physical
address
state of a video device.
When a new notifier is registered the current state will be reported to
that notifier at registration time.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
MAINTAINERS | 4 +-
drivers/media/Kconfig| 3 ++
drivers/media/Makefile | 4 ++
drivers/media/cec-notifier.c | 116 +++
include/media/cec-notifier.h | 93 ++
5 files changed, 219 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/cec-notifier.c
create mode 100644 include/media/cec-notifier.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 83a42ef1d1a7..cfb2670aa372 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3066,7 +3066,7 @@ F:drivers/net/ieee802154/cc2520.c
F: include/linux/spi/cc2520.h
F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt
-CEC DRIVER
+CEC FRAMEWORK
M: Hans Verkuil
L: linux-me...@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
@@ -3076,9 +3076,11 @@ F: Documentation/media/kapi/cec-core.rst
F: Documentation/media/uapi/cec
F: drivers/media/cec/
F: drivers/media/cec-edid.c
+F: drivers/media/cec-notifier.c
F: drivers/media/rc/keymaps/rc-cec.c
F: include/media/cec.h
F: include/media/cec-edid.h
+F: include/media/cec-notifier.h
F: include/uapi/linux/cec.h
F: include/uapi/linux/cec-funcs.h
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 3512316e7a46..799429f51d1a 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -99,6 +99,9 @@ config MEDIA_CEC_DEBUG
config MEDIA_CEC_EDID
bool
+config MEDIA_CEC_NOTIFIER
+ bool
+
#
# Media controller
# Selectable only for webcam/grabbers, as other drivers don't use it
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index d87ccb8eeabe..8b36a571d443 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -6,6 +6,10 @@ ifeq ($(CONFIG_MEDIA_CEC_EDID),y)
obj-$(CONFIG_MEDIA_SUPPORT) += cec-edid.o
endif
+ifeq ($(CONFIG_MEDIA_CEC_NOTIFIER),y)
+ obj-$(CONFIG_MEDIA_SUPPORT) += cec-notifier.o
+endif
+
ifeq ($(CONFIG_MEDIA_CEC_SUPPORT),y)
obj-$(CONFIG_MEDIA_SUPPORT) += cec/
endif
diff --git a/drivers/media/cec-notifier.c b/drivers/media/cec-notifier.c
new file mode 100644
index ..a5938c4d3ab4
--- /dev/null
+++ b/drivers/media/cec-notifier.c
@@ -0,0 +1,116 @@
+/*
+ * cec-notifier.c - notify CEC drivers of physical address changes
+ *
+ * Copyright 2016 Russell King
+ * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct cec_notifier {
+ struct mutex lock;
+ struct list_head head;
+ struct kref kref;
+ struct device *dev;
+ struct cec_adapter *cec_adap;
+ void (*callback)(struct cec_adapter *adap, u16 pa);
+
+ u16 phys_addr;
+};
+
+static LIST_HEAD(cec_notifiers);
+static DEFINE_MUTEX(cec_notifiers_lock);
+
+struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ struct cec_notifier *n;
+
+ mutex_lock(&cec_notifiers_lock);
+ list_for_each_entry(n, &cec_notifiers, head) {
+ if (n->dev == dev) {
+ mutex_unlock(&cec_notifiers_lock);
+ kref_get(&n->kref);
+ return n;
+ }
+ }
+ n = kzalloc(sizeof(*n), GFP_KERNEL);
+ if (!n)
+ goto unlock;
+ n->dev = dev;
+ n->phys_addr = CEC_PHYS_ADDR_INVALID;
+ mutex_init(&n->lock);
+ kref_init(&n->kref);
+ list_add_tail(&n->head, &cec_notifiers);
+unlock:
+ mutex_unlock(&cec_notifiers_lock);
+ return n;
+}
+EXPORT_SYMBOL_GPL(cec_notifier_get);
+
+static void cec_notifier_release(struct kref *kref)
+{
+ struct cec_notifier *n =
+
[PATCHv5 08/11] sti: hdmi: add CEC notifier support
From: Benjamin Gaignard
Implement the CEC notifier support to allow CEC drivers to
be informed when there is a new physical address.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/sti/sti_hdmi.c | 11 +++
drivers/gpu/drm/sti/sti_hdmi.h | 3 +++
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index ce2dcba679d5..345d3631cf50 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -771,6 +771,8 @@ static void sti_hdmi_disable(struct drm_bridge *bridge)
clk_disable_unprepare(hdmi->clk_pix);
hdmi->enabled = false;
+
+ cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
}
/**
@@ -973,6 +975,7 @@ static int sti_hdmi_connector_get_modes(struct
drm_connector *connector)
DRM_DEBUG_KMS("%s : %dx%d cm\n",
(hdmi->hdmi_monitor ? "hdmi monitor" : "dvi monitor"),
edid->width_cm, edid->height_cm);
+ cec_notifier_set_phys_addr(hdmi->notifier,
cec_get_edid_phys_addr(edid));
count = drm_add_edid_modes(connector, edid);
drm_mode_connector_update_edid_property(connector, edid);
@@ -1035,6 +1038,7 @@ sti_hdmi_connector_detect(struct drm_connector
*connector, bool force)
}
DRM_DEBUG_DRIVER("hdmi cable disconnected\n");
+ cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
return connector_status_disconnected;
}
@@ -1423,6 +1427,10 @@ static int sti_hdmi_probe(struct platform_device *pdev)
goto release_adapter;
}
+ hdmi->notifier = cec_notifier_get(&pdev->dev);
+ if (!hdmi->notifier)
+ goto release_adapter;
+
hdmi->reset = devm_reset_control_get(dev, "hdmi");
/* Take hdmi out of reset */
if (!IS_ERR(hdmi->reset))
@@ -1442,11 +1450,14 @@ static int sti_hdmi_remove(struct platform_device *pdev)
{
struct sti_hdmi *hdmi = dev_get_drvdata(&pdev->dev);
+ cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
+
i2c_put_adapter(hdmi->ddc_adapt);
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
component_del(&pdev->dev, &sti_hdmi_ops);
+ cec_notifier_put(hdmi->notifier);
return 0;
}
diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index 407012350f1a..c6469b56ce7e 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -11,6 +11,7 @@
#include
#include
+#include
#define HDMI_STA 0x0010
#define HDMI_STA_DLL_LCK BIT(5)
@@ -64,6 +65,7 @@ static const struct drm_prop_enum_list
colorspace_mode_names[] = {
* @audio_pdev: ASoC hdmi-codec platform device
* @audio: hdmi audio parameters.
* @drm_connector: hdmi connector
+ * @notifier: hotplug detect notifier
*/
struct sti_hdmi {
struct device dev;
@@ -89,6 +91,7 @@ struct sti_hdmi {
struct platform_device *audio_pdev;
struct hdmi_audio_params audio;
struct drm_connector *drm_connector;
+ struct cec_notifier *notifier;
};
u32 hdmi_read(struct sti_hdmi *hdmi, int offset);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 10/11] stih-cec: add CEC notifier support
From: Benjamin Gaignard
By using the CEC notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Hans Verkuil
CC: devicet...@vger.kernel.org
---
drivers/media/platform/Kconfig | 10 +++
drivers/media/platform/Makefile| 1 +
.../st-cec => media/platform/sti/cec}/Makefile | 0
.../st-cec => media/platform/sti/cec}/stih-cec.c | 31 +++---
drivers/staging/media/Kconfig | 2 --
drivers/staging/media/Makefile | 1 -
drivers/staging/media/st-cec/Kconfig | 8 --
drivers/staging/media/st-cec/TODO | 7 -
8 files changed, 39 insertions(+), 21 deletions(-)
rename drivers/{staging/media/st-cec => media/platform/sti/cec}/Makefile (100%)
rename drivers/{staging/media/st-cec => media/platform/sti/cec}/stih-cec.c
(93%)
delete mode 100644 drivers/staging/media/st-cec/Kconfig
delete mode 100644 drivers/staging/media/st-cec/TODO
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 2c449b88fc94..7321f6123659 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -476,6 +476,16 @@ config VIDEO_SAMSUNG_S5P_CEC
CEC bus is present in the HDMI connector and enables communication
between compatible devices.
+config VIDEO_STI_HDMI_CEC
+ tristate "STMicroelectronics STiH4xx HDMI CEC driver"
+ depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (ARCH_STI || COMPILE_TEST)
+ select MEDIA_CEC_NOTIFIER
+ ---help---
+ This is a driver for STIH4xx HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
endif #V4L_CEC_DRIVERS
menuconfig V4L_TEST_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 2f94d82afa4c..940724ab9b70 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC)+= exynos-gsc/
obj-$(CONFIG_VIDEO_STI_BDISP) += sti/bdisp/
obj-$(CONFIG_VIDEO_STI_HVA)+= sti/hva/
obj-$(CONFIG_DVB_C8SECTPFE)+= sti/c8sectpfe/
+obj-$(CONFIG_VIDEO_STI_HDMI_CEC) += sti/cec/
obj-$(CONFIG_VIDEO_STI_DELTA) += sti/delta/
diff --git a/drivers/staging/media/st-cec/Makefile
b/drivers/media/platform/sti/cec/Makefile
similarity index 100%
rename from drivers/staging/media/st-cec/Makefile
rename to drivers/media/platform/sti/cec/Makefile
diff --git a/drivers/staging/media/st-cec/stih-cec.c
b/drivers/media/platform/sti/cec/stih-cec.c
similarity index 93%
rename from drivers/staging/media/st-cec/stih-cec.c
rename to drivers/media/platform/sti/cec/stih-cec.c
index 3c25638a9610..636281c64c04 100644
--- a/drivers/staging/media/st-cec/stih-cec.c
+++ b/drivers/media/platform/sti/cec/stih-cec.c
@@ -1,6 +1,4 @@
/*
- * drivers/staging/media/st-cec/stih-cec.c
- *
* STIH4xx CEC driver
* Copyright (C) STMicroelectronic SA 2016
*
@@ -15,9 +13,11 @@
#include
#include
#include
+#include
#include
#include
+#include
#define CEC_NAME "stih-cec"
@@ -129,6 +129,7 @@ struct stih_cec {
void __iomem*regs;
int irq;
u32 irq_status;
+ struct cec_notifier *notifier;
};
static int stih_cec_adap_enable(struct cec_adapter *adap, bool enable)
@@ -303,12 +304,29 @@ static int stih_cec_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct resource *res;
struct stih_cec *cec;
+ struct device_node *np;
+ struct platform_device *hdmi_dev;
int ret;
cec = devm_kzalloc(dev, sizeof(*cec), GFP_KERNEL);
if (!cec)
return -ENOMEM;
+ np = of_parse_phandle(pdev->dev.of_node, "hdmi-phandle", 0);
+
+ if (!np) {
+ dev_err(&pdev->dev, "Failed to find hdmi node in device
tree\n");
+ return -ENODEV;
+ }
+
+ hdmi_dev = of_find_device_by_node(np);
+ if (!hdmi_dev)
+ return -EPROBE_DEFER;
+
+ cec->notifier = cec_notifier_get(&hdmi_dev->dev);
+ if (!cec->notifier)
+ return -ENOMEM;
+
cec->dev = dev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -335,7 +353,7 @@ static int stih_cec_probe(struct platform_device *pdev)
cec->adap = cec_allocate_adapter(&sti_cec_adap_ops, cec,
CEC_NAME,
CEC_CAP_LOG_ADDRS | CEC_CAP_PASSTHROUGH |
- CEC_CAP_PHYS_ADDR | CEC_CAP_TRANSMIT, 1);
+ CEC_CAP_TRANSMIT, 1);
ret
[PATCHv5 04/11] exynos_hdmi: add CEC notifier support
From: Hans Verkuil
Implement the CEC notifier support to allow CEC drivers to
be informed when there is a new physical address.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 88ccc0469316..2afc8b8052c2 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -43,6 +43,8 @@
#include
+#include
+
#include "exynos_drm_drv.h"
#include "exynos_drm_crtc.h"
@@ -119,6 +121,7 @@ struct hdmi_context {
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
+ struct cec_notifier *notifier;
const struct hdmi_driver_data *drv_data;
void __iomem*regs;
@@ -822,6 +825,7 @@ static enum drm_connector_status hdmi_detect(struct
drm_connector *connector,
if (gpiod_get_value(hdata->hpd_gpio))
return connector_status_connected;
+ cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
return connector_status_disconnected;
}
@@ -860,6 +864,8 @@ static int hdmi_get_modes(struct drm_connector *connector)
edid->width_cm, edid->height_cm);
drm_mode_connector_update_edid_property(connector, edid);
+ cec_notifier_set_phys_addr(hdata->notifier,
+ cec_get_edid_phys_addr(edid));
ret = drm_add_edid_modes(connector, edid);
@@ -1503,6 +1509,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
if (funcs && funcs->disable)
(*funcs->disable)(crtc);
+ cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
cancel_delayed_work(&hdata->hotplug_work);
hdmiphy_disable(hdata);
@@ -1878,15 +1885,22 @@ static int hdmi_probe(struct platform_device *pdev)
}
}
+ hdata->notifier = cec_notifier_get(&pdev->dev);
+ if (hdata->notifier == NULL) {
+ ret = -ENOMEM;
+ goto err_hdmiphy;
+ }
+
pm_runtime_enable(dev);
ret = component_add(&pdev->dev, &hdmi_component_ops);
if (ret)
- goto err_disable_pm_runtime;
+ goto err_notifier_put;
return ret;
-err_disable_pm_runtime:
+err_notifier_put:
+ cec_notifier_put(hdata->notifier);
pm_runtime_disable(dev);
err_hdmiphy:
@@ -1905,9 +1919,11 @@ static int hdmi_remove(struct platform_device *pdev)
struct hdmi_context *hdata = platform_get_drvdata(pdev);
cancel_delayed_work_sync(&hdata->hotplug_work);
+ cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
component_del(&pdev->dev, &hdmi_component_ops);
+ cec_notifier_put(hdata->notifier);
pm_runtime_disable(&pdev->dev);
if (!IS_ERR(hdata->reg_hdmi_en))
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 06/11] s5p-cec.txt: document the HDMI controller phandle
From: Hans Verkuil
Update the bindings documenting the new hdmi phandle.
Signed-off-by: Hans Verkuil
CC: linux-samsung-...@vger.kernel.org
CC: devicet...@vger.kernel.org
CC: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/media/s5p-cec.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt
b/Documentation/devicetree/bindings/media/s5p-cec.txt
index 925ab4d72eaa..4bb08d9d940b 100644
--- a/Documentation/devicetree/bindings/media/s5p-cec.txt
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -15,6 +15,7 @@ Required properties:
- clock-names : from common clock binding: must contain "hdmicec",
corresponding to entry in the clocks property.
- samsung,syscon-phandle - phandle to the PMU system controller
+ - hdmi-phandle - phandle to the HDMI controller
Example:
@@ -25,6 +26,7 @@ hdmicec: cec@100B {
clocks = <&clock CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <&pmu_system_controller>;
+ hdmi-phandle = <&hdmi>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_cec>;
status = "okay";
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 01/11] cec-edid: rename cec_get_edid_phys_addr
From: Hans Verkuil
Rename cec_get_edid_phys_addr to cec_get_raw_edid_phys_addr.
Add a new cec_get_edid_phys_addr function that takes a struct edid pointer.
This reflects the fact that some drivers have a struct edid pointer and
others a u8 pointer to the raw edid data.
Signed-off-by: Hans Verkuil
---
drivers/media/cec-edid.c | 15 +--
drivers/media/i2c/adv7511.c | 5 ++---
drivers/media/i2c/adv7604.c | 3 ++-
drivers/media/i2c/adv7842.c | 2 +-
drivers/media/platform/vivid/vivid-vid-cap.c | 3 ++-
include/media/cec-edid.h | 17 ++---
6 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/media/cec-edid.c b/drivers/media/cec-edid.c
index 5719b991e340..d7b369f53831 100644
--- a/drivers/media/cec-edid.c
+++ b/drivers/media/cec-edid.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
/*
* This EDID is expected to be a CEA-861 compliant, which means that there are
@@ -82,8 +83,8 @@ static unsigned int cec_get_edid_spa_location(const u8 *edid,
unsigned int size)
return 0;
}
-u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,
- unsigned int *offset)
+u16 cec_get_raw_edid_phys_addr(const u8 *edid, unsigned int size,
+ unsigned int *offset)
{
unsigned int loc = cec_get_edid_spa_location(edid, size);
@@ -93,6 +94,16 @@ u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,
return CEC_PHYS_ADDR_INVALID;
return (edid[loc] << 8) | edid[loc + 1];
}
+EXPORT_SYMBOL_GPL(cec_get_raw_edid_phys_addr);
+
+u16 cec_get_edid_phys_addr(const struct edid *edid)
+{
+ if (!edid || edid->extensions == 0)
+ return CEC_PHYS_ADDR_INVALID;
+
+ return cec_get_raw_edid_phys_addr((u8 *)edid,
+ EDID_LENGTH * (edid->extensions + 1), NULL);
+}
EXPORT_SYMBOL_GPL(cec_get_edid_phys_addr);
void cec_set_edid_phys_addr(u8 *edid, unsigned int size, u16 phys_addr)
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 8c9e28949ab1..4723e826804a 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -1712,9 +1712,8 @@ static bool adv7511_check_edid_status(struct v4l2_subdev
*sd)
v4l2_dbg(1, debug, sd, "%s: edid complete with %d
segment(s)\n", __func__, state->edid.segments);
state->edid.complete = true;
- ed.phys_addr = cec_get_edid_phys_addr(state->edid.data,
- state->edid.segments *
256,
- NULL);
+ ed.phys_addr = cec_get_raw_edid_phys_addr(state->edid.data,
+ state->edid.segments * 256, NULL);
/* report when we have all segments
but report only for segment 0
*/
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d8bf435db86d..ac60c9116f9c 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2305,7 +2305,8 @@ static int adv76xx_set_edid(struct v4l2_subdev *sd,
struct v4l2_edid *edid)
edid->blocks = 2;
return -E2BIG;
}
- pa = cec_get_edid_phys_addr(edid->edid, edid->blocks * 128, &spa_loc);
+ pa = cec_get_raw_edid_phys_addr(edid->edid,
+ edid->blocks * 128, &spa_loc);
err = cec_phys_addr_validate(pa, &pa, NULL);
if (err)
return err;
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 2d61f0cc2b5b..440870d1d988 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -802,7 +802,7 @@ static int edid_write_hdmi_segment(struct v4l2_subdev *sd,
u8 port)
if (!state->hdmi_edid.present)
return 0;
- pa = cec_get_edid_phys_addr(edid, 256, &spa_loc);
+ pa = cec_get_raw_edid_phys_addr(edid, 256, &spa_loc);
err = cec_phys_addr_validate(pa, &pa, NULL);
if (err)
return err;
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
b/drivers/media/platform/vivid/vivid-vid-cap.c
index 01419455e545..6a7310e212cf 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -1736,7 +1736,8 @@ int vidioc_s_edid(struct file *file, void *_fh,
edid->blocks = dev->edid_max_blocks;
return -E2BIG;
}
- phys_addr = cec_get_edid_phys_addr(edid->edid, edid->blocks * 128,
NULL);
+ phys_addr = cec_get_raw_edid_phys_addr(edid->edid,
+ edid->blocks * 128, NULL);
ret = cec_phys_addr_validate(phys_addr, &phys_addr, NULL);
if (ret)
return ret;
diff --git a/include/media/cec-edid.h b/include/media/ce
[PATCHv5 09/11] stih-cec.txt: document new hdmi phandle
From: Benjamin Gaignard
Update the bindings documentation with the new hdmi phandle.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Hans Verkuil
Acked-by: Rob Herring
CC: devicet...@vger.kernel.org
---
Documentation/devicetree/bindings/media/stih-cec.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt
b/Documentation/devicetree/bindings/media/stih-cec.txt
index 71c4b2f4bcef..289a08b33651 100644
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ b/Documentation/devicetree/bindings/media/stih-cec.txt
@@ -9,6 +9,7 @@ Required properties:
- pinctrl-names: Contains only one value - "default"
- pinctrl-0: Specifies the pin control groups used for CEC hardware.
- resets: Reference to a reset controller
+ - hdmi-phandle: Phandle to the HDMI controller
Example for STIH407:
@@ -22,4 +23,5 @@ sti-cec@094a087c {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cec0_default>;
resets = <&softreset STIH407_LPM_SOFTRESET>;
+ hdmi-phandle = <&hdmi>;
};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 07/11] s5p-cec: add cec-notifier support, move out of staging
From: Hans Verkuil
By using the CEC notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.
Update the bindings documenting the new hdmi phandle and
update exynos4.dtsi accordingly.
Tested with my Odroid U3.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
CC: linux-samsung-...@vger.kernel.org
CC: Krzysztof Kozlowski
---
drivers/media/platform/Kconfig | 18 +++
drivers/media/platform/Makefile| 1 +
.../media => media/platform}/s5p-cec/Makefile | 0
.../platform}/s5p-cec/exynos_hdmi_cec.h| 0
.../platform}/s5p-cec/exynos_hdmi_cecctrl.c| 0
.../media => media/platform}/s5p-cec/regs-cec.h| 0
.../media => media/platform}/s5p-cec/s5p_cec.c | 35 ++
.../media => media/platform}/s5p-cec/s5p_cec.h | 3 ++
drivers/staging/media/Kconfig | 2 --
drivers/staging/media/Makefile | 1 -
drivers/staging/media/s5p-cec/Kconfig | 9 --
drivers/staging/media/s5p-cec/TODO | 7 -
12 files changed, 52 insertions(+), 24 deletions(-)
rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
delete mode 100644 drivers/staging/media/s5p-cec/TODO
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ab0bb4879b54..2c449b88fc94 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -460,6 +460,24 @@ config VIDEO_TI_SC
config VIDEO_TI_CSC
tristate
+menuconfig V4L_CEC_DRIVERS
+ bool "Platform HDMI CEC drivers"
+ depends on MEDIA_CEC_SUPPORT
+
+if V4L_CEC_DRIVERS
+
+config VIDEO_SAMSUNG_S5P_CEC
+ tristate "Samsung S5P CEC driver"
+ depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (PLAT_S5P || ARCH_EXYNOS
|| COMPILE_TEST)
+ select MEDIA_CEC_NOTIFIER
+ ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
+endif #V4L_CEC_DRIVERS
+
menuconfig V4L_TEST_DRIVERS
bool "Media test drivers"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 8959f6e6692a..2f94d82afa4c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
obj-$(CONFIG_VIDEO_STI_BDISP) += sti/bdisp/
diff --git a/drivers/staging/media/s5p-cec/Makefile
b/drivers/media/platform/s5p-cec/Makefile
similarity index 100%
rename from drivers/staging/media/s5p-cec/Makefile
rename to drivers/media/platform/s5p-cec/Makefile
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
similarity index 100%
rename from drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
rename to drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c
b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
similarity index 100%
rename from drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c
rename to drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
diff --git a/drivers/staging/media/s5p-cec/regs-cec.h
b/drivers/media/platform/s5p-cec/regs-cec.h
similarity index 100%
rename from drivers/staging/media/s5p-cec/regs-cec.h
rename to drivers/media/platform/s5p-cec/regs-cec.h
diff --git a/drivers/staging/media/s5p-cec/s5p_cec.c
b/drivers/media/platform/s5p-cec/s5p_cec.c
similarity index 89%
rename from drivers/staging/media/s5p-cec/s5p_cec.c
rename to drivers/media/platform/s5p-cec/s5p_cec.c
index 2a07968b5ac6..f7adf61caaa8 100644
--- a/drivers/staging/media/s5p-cec/s5p_cec.c
+++ b/drivers/media/platform/s5p-cec/s5p_cec.c
@@ -19,11 +19,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
+#include
#include "exynos_hdmi_cec.h"
#include "regs-cec.h"
@@ -167,10 +170,22 @@ static const struct cec_adap_ops s5p_cec_adap_ops = {
static int s5p_cec_probe(s
[PATCHv5 05/11] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
From: Hans Verkuil Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the s5p-cec driver to initialize the CEC notifier framework. Tested with my Odroid U3. Signed-off-by: Hans Verkuil Tested-by: Marek Szyprowski CC: linux-samsung-...@vger.kernel.org CC: devicet...@vger.kernel.org CC: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 18def1c774d5..84fcdff140ae 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -771,6 +771,7 @@ clocks = <&clock CLK_HDMI_CEC>; clock-names = "hdmicec"; samsung,syscon-phandle = <&pmu_system_controller>; + hdmi-phandle = <&hdmi>; pinctrl-names = "default"; pinctrl-0 = <&hdmi_cec>; status = "disabled"; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 03/11] cec: integrate CEC notifier support
From: Hans Verkuil
Support the CEC notifier framework, simplifying drivers that
depend on this.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/media/cec/cec-core.c | 21 +
include/media/cec.h | 6 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 37217e205040..2bab6e00b663 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -195,6 +195,23 @@ static void cec_devnode_unregister(struct cec_devnode
*devnode)
put_device(&devnode->dev);
}
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+static void cec_cec_notify(struct cec_adapter *adap, u16 pa)
+{
+ cec_s_phys_addr(adap, pa, false);
+}
+
+void cec_register_cec_notifier(struct cec_adapter *adap,
+ struct cec_notifier *notifier)
+{
+ if (WARN_ON(!adap->devnode.registered))
+ return;
+
+ cec_notifier_register(adap->notifier, adap, cec_cec_notify);
+}
+EXPORT_SYMBOL_GPL(cec_register_cec_notifier);
+#endif
+
struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
void *priv, const char *name, u32 caps,
u8 available_las)
@@ -343,6 +360,10 @@ void cec_unregister_adapter(struct cec_adapter *adap)
adap->rc = NULL;
#endif
debugfs_remove_recursive(adap->cec_dir);
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+ if (adap->notifier)
+ cec_notifier_unregister(adap->notifier);
+#endif
cec_devnode_unregister(&adap->devnode);
}
EXPORT_SYMBOL_GPL(cec_unregister_adapter);
diff --git a/include/media/cec.h b/include/media/cec.h
index 96a0aa770d61..e6474b567a25 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/**
* struct cec_devnode - cec device node
@@ -213,6 +214,11 @@ void cec_transmit_done(struct cec_adapter *adap, u8
status, u8 arb_lost_cnt,
u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+void cec_register_cec_notifier(struct cec_adapter *adap,
+ struct cec_notifier *notifier);
+#endif
+
#else
static inline int cec_register_adapter(struct cec_adapter *adap,
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 11/11] arm: sti: update sti-cec for CEC notifier support
From: Benjamin Gaignard
To use CEC notifier sti CEC driver needs to get phandle
of the hdmi device.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Hans Verkuil
CC: devicet...@vger.kernel.org
---
arch/arm/boot/dts/stih407-family.dtsi | 12
arch/arm/boot/dts/stih410.dtsi| 13 +
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index d753ac36788f..044184580326 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -742,18 +742,6 @@
<&clk_s_c0_flexgen CLK_ETH_PHY>;
};
- cec: sti-cec@094a087c {
- compatible = "st,stih-cec";
- reg = <0x94a087c 0x64>;
- clocks = <&clk_sysin>;
- clock-names = "cec-clk";
- interrupts = ;
- interrupt-names = "cec-irq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_cec0_default>;
- resets = <&softreset STIH407_LPM_SOFTRESET>;
- };
-
rng10: rng@08a89000 {
compatible = "st,rng";
reg = <0x08a89000 0x1000>;
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 3c9672c5b09f..21fe72b183d8 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -281,5 +281,18 @@
<&clk_s_c0_flexgen CLK_ST231_DMU>,
<&clk_s_c0_flexgen CLK_FLASH_PROMIP>;
};
+
+ sti-cec@094a087c {
+ compatible = "st,stih-cec";
+ reg = <0x94a087c 0x64>;
+ clocks = <&clk_sysin>;
+ clock-names = "cec-clk";
+ interrupts = ;
+ interrupt-names = "cec-irq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_cec0_default>;
+ resets = <&softreset STIH407_LPM_SOFTRESET>;
+ hdmi-phandle = <&sti_hdmi>;
+ };
};
};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 00/30] drm/omap: miscallaneous improvements
On 29/03/17 15:09, Laurent Pinchart wrote: > Hi Tomi, > > On Tuesday 28 Mar 2017 16:07:46 Tomi Valkeinen wrote: >> This is the third revision of this series. Note that this series depends on >> "drm/atomic: Introduce drm_atomic_helper_shutdown" which has not yet been >> merged to drm-next. > > I've reviewed all patches but the omapdss-base split. While it doesn't look > bad to me, it's hard to judge whether the code is correctly architectured > without seeing the omapdss6 driver. Thanks. I think time will tell if it's correctly done, but I'm quite confident that it can't mess up much. It consists really of two parts: separating the common base stuff into a separate module, and the dispc_ops. While the common module could use some cleanup, I think it makes sense. The dispc_ops really just change from calling functions directly to use function pointers. You can find dss6 driver from https://git.ti.com/ti-linux-kernel/ti-linux-kernel/trees/ti-linux-4.9.y/drivers/gpu/drm/omapdrm/dss The dss6 and dispc6 files. But it's really just a smaller, cleaner (well, the driver is not clean yet) version of dss5. Conceptually the same, different registers. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes.
Op 29-03-17 om 16:06 schreef Daniel Vetter: > On Wed, Mar 29, 2017 at 03:51:08PM +0200, Maarten Lankhorst wrote: >> Op 29-03-17 om 15:31 schreef Boris Brezillon: >>> On Wed, 29 Mar 2017 15:26:45 +0200 >>> Daniel Vetter wrote: >>> On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote: > mode_valid() and get_modes() called > from drm_helper_probe_single_connector_modes() > may need to look at connector->state because what a valid mode is may > depend on connector properties being set. For example some HDMI modes > might be rejected when a connector property forces the connector > into DVI mode. > > Some implementations of detect() already lock all state, > so we have to pass an acquire_ctx to them to prevent a deadlock. > > This means changing the function signature of detect() slightly, > and passing the acquire_ctx for locking multiple crtc's. > It might be NULL, in which case expensive operations should be avoided. > > intel_dp.c however ignores the force flag, so still lock > connection_mutex there if needed. > > Signed-off-by: Maarten Lankhorst > Cc: Boris Brezillon > Cc: Manasi Navare Hm only noticed this now, but mixing up force with the acquire_ctx sounds like very bad interface design. Yes, the only user of the new hook works like that, but that's really accidental I think. I think just having the ctx everywhere (for atomic drivers at least) would be a lot safer. This is extremely surprising (and undocumented suprise at that). >>> Yes, I was about to say the same thing: the interface is not very >>> clear, and I don't understand why ctx = NULL implies force = false. >> They're the same thing I fear. I could perhaps call it force_ctx instead, >> but non-zero ctx implies force, and other way around. Though I guess we could >> relax it, and have force = true imply ctx, but not the other way around. >> >> Would that be ok? > Why can't we supply a ctx always? I didn't see any reason not to in the > code ... > -Daniel Then drm_helper_hpd_irq_event and intel_hpd_irq_event have to do -EDEADLK handling too, it could be done but nothing would return -EDEADLK so it's unused code. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] drm/etnaviv: return GPU fence through the submit structure
The next patch will need the complete dma_fence, instead of just the seqno,
to create the sync_file in etnaviv_ioctl_gem_submit, in case an
out_fence_fd is requested.
The submit needs to hold a reference to the dma_fence, to avoid raceing
with the GPU completing the fence.
Signed-off-by: Lucas Stach
Tested-by: Philipp Zabel
---
New patch in v3.
---
drivers/gpu/drm/etnaviv/etnaviv_gem.h| 3 ++-
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 3 ++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 4 ++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index 120410d67eb5..c4a091e87426 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -20,6 +20,7 @@
#include
#include "etnaviv_drv.h"
+struct dma_fence;
struct etnaviv_gem_ops;
struct etnaviv_gem_object;
@@ -104,7 +105,7 @@ struct etnaviv_gem_submit {
struct drm_device *dev;
struct etnaviv_gpu *gpu;
struct ww_acquire_ctx ticket;
- u32 fence;
+ struct dma_fence *fence;
unsigned int nr_bos;
struct etnaviv_gem_submit_bo bos[0];
u32 flags;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index fb8d5befbf4f..1b6f9b843815 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -294,6 +294,7 @@ static void submit_cleanup(struct etnaviv_gem_submit
*submit)
}
ww_acquire_fini(&submit->ticket);
+ dma_fence_put(submit->fence);
kfree(submit);
}
@@ -435,7 +436,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
if (ret == 0)
cmdbuf = NULL;
- args->fence = submit->fence;
+ args->fence = submit->fence->seqno;
out:
submit_unpin_objects(submit);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index ed3fdeb8b5e6..4f587058a3aa 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1337,8 +1337,8 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
}
gpu->event[event].fence = fence;
- submit->fence = fence->seqno;
- gpu->active_fence = submit->fence;
+ submit->fence = dma_fence_get(fence);
+ gpu->active_fence = submit->fence->seqno;
if (gpu->lastctx != cmdbuf->ctx) {
gpu->mmu->need_flush = true;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/etnaviv: submit support for out-fences
From: Philipp Zabel
Based on commit 4cd0945901a6 ("drm/msm: submit support for out-fences").
We increment the minor driver version so userspace can detect explicit
fence support.
Signed-off-by: Philipp Zabel
Signed-off-by: Lucas Stach
---
v3: Changed to work with fence returned from GPU submit.
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 28
include/uapi/drm/etnaviv_drm.h | 6 --
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 289a9f8c6671..5255278dde56 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -512,7 +512,7 @@ static struct drm_driver etnaviv_drm_driver = {
.desc = "etnaviv DRM",
.date = "20151214",
.major = 1,
- .minor = 0,
+ .minor = 1,
};
/*
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 1b6f9b843815..e1909429837e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -309,6 +309,8 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
struct etnaviv_cmdbuf *cmdbuf;
struct etnaviv_gpu *gpu;
struct dma_fence *in_fence = NULL;
+ struct sync_file *sync_file = NULL;
+ int out_fence_fd = -1;
void *stream;
int ret;
@@ -376,6 +378,14 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
goto err_submit_cmds;
}
+ if (args->flags & ETNA_SUBMIT_FENCE_FD_OUT) {
+ out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
+ if (out_fence_fd < 0) {
+ ret = out_fence_fd;
+ goto err_submit_cmds;
+ }
+ }
+
submit = submit_create(dev, gpu, args->nr_bos);
if (!submit) {
ret = -ENOMEM;
@@ -436,6 +446,22 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
if (ret == 0)
cmdbuf = NULL;
+ if (args->flags & ETNA_SUBMIT_FENCE_FD_OUT) {
+ /*
+* This can be improved: ideally we want to allocate the sync
+* file before kicking off the GPU job and just attach the
+* fence to the sync file here, eliminating the ENOMEM
+* possibility at this stage.
+*/
+ sync_file = sync_file_create(submit->fence);
+ if (!sync_file) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ fd_install(out_fence_fd, sync_file->file);
+ }
+
+ args->fence_fd = out_fence_fd;
args->fence = submit->fence->seqno;
out:
@@ -455,6 +481,8 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
submit_cleanup(submit);
err_submit_cmds:
+ if (ret && (out_fence_fd >= 0))
+ put_unused_fd(out_fence_fd);
/* if we still own the cmdbuf */
if (cmdbuf)
etnaviv_cmdbuf_free(cmdbuf);
diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
index e9c388a1d8eb..76f6f78a352b 100644
--- a/include/uapi/drm/etnaviv_drm.h
+++ b/include/uapi/drm/etnaviv_drm.h
@@ -156,8 +156,10 @@ struct drm_etnaviv_gem_submit_bo {
*/
#define ETNA_SUBMIT_NO_IMPLICIT 0x0001
#define ETNA_SUBMIT_FENCE_FD_IN 0x0002
+#define ETNA_SUBMIT_FENCE_FD_OUT0x0004
#define ETNA_SUBMIT_FLAGS (ETNA_SUBMIT_NO_IMPLICIT | \
-ETNA_SUBMIT_FENCE_FD_IN)
+ETNA_SUBMIT_FENCE_FD_IN | \
+ETNA_SUBMIT_FENCE_FD_OUT)
#define ETNA_PIPE_3D 0x00
#define ETNA_PIPE_2D 0x01
#define ETNA_PIPE_VG 0x02
@@ -172,7 +174,7 @@ struct drm_etnaviv_gem_submit {
__u64 relocs; /* in, ptr to array of submit_reloc's */
__u64 stream; /* in, ptr to cmdstream */
__u32 flags; /* in, mask of ETNA_SUBMIT_x */
- __s32 fence_fd; /* in, fence fd (see ETNA_SUBMIT_FENCE_FD_IN) */
+ __s32 fence_fd; /* in/out, fence fd (see ETNA_SUBMIT_FENCE_FD_x)
*/
};
/* The normal way to synchronize with the GPU is just to CPU_PREP on
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/etnaviv: submit support for in-fences
From: Philipp Zabel
Loosely based on commit f0a42bb5423a ("drm/msm: submit support for
in-fences"). Unfortunately, struct drm_etnaviv_gem_submit doesn't have
a flags field yet, so we have to extend the structure and trust that
drm_ioctl will clear the flags for us if an older userspace only submits
part of the struct.
Signed-off-by: Philipp Zabel
Reviewed-by: Gustavo Padovan
Reviewed-by: Sumit Semwal
Reviewed-by: Lucas Stach
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/Kconfig | 1 +
drivers/gpu/drm/etnaviv/etnaviv_gem.h| 1 +
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 34 +++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 5 +++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 2 +-
include/uapi/drm/etnaviv_drm.h | 6 +
6 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
index cc1731c5289c..71cee4e9fefb 100644
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -5,6 +5,7 @@ config DRM_ETNAVIV
depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST)
depends on MMU
select SHMEM
+ select SYNC_FILE
select TMPFS
select IOMMU_API
select IOMMU_SUPPORT
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index e63ff116a3b3..120410d67eb5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -107,6 +107,7 @@ struct etnaviv_gem_submit {
u32 fence;
unsigned int nr_bos;
struct etnaviv_gem_submit_bo bos[0];
+ u32 flags;
};
int etnaviv_gem_wait_bo(struct etnaviv_gpu *gpu, struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 726090d7a6ac..fb8d5befbf4f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -14,7 +14,9 @@
* this program. If not, see
Re: [PATCH v2 00/10] Enable HDMI Stereoscopy
On Wed, Mar 29, 2017 at 10:24:05AM -0400, Alastair Bridgewater wrote: > On Wed, Mar 29, 2017 at 8:02 AM, Ville Syrjälä < > ville.syrj...@linux.intel.com> wrote: > > > > On Mon, Mar 27, 2017 at 05:57:57PM -0400, Alastair Bridgewater wrote: > > > And the tenth patch enables stereo mode support... on HDMI and DPort > > > connectors on nv50+ hardware. HDMI connectors because obvious. DPort > > > connectors because of DPort to HDMI adaptors. > > > > Do you mean DP++ or actual protocol converters? DP++ is just HDMI with > > a some electrical tweaks, but IIRC proper DP defines 3D stereo quite > > differently than HDMI. I'm not sure if we should be able to push HDMI > > style 3D through DP->HDMI/DP++ adaptors. The specs are unfortunately > > very vague when it comes to such devices. > > DP++. Good point about the protocol converters, though I don't recall > seeing any way to distinguish between a DP and a DP++ connector in > nouveau, nor do I know if nVidia actually made any boards with DP that > isn't DP++. I guess I have some digging to do in that direction. Thank > you. In i915 we register both a HDMI and a DP connector for the same physical DP connector, and a sink attached via a DP++ dongle/cable will appear on the HDMI connector instead of the DP connector. But I don't know if nouveau follows this same pattern or not. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/11] drm/fb-helper: Improve code readability
From: Thierry Reding
Add a couple of temporary variables and use shorter names for existing
variables in drm_fb_helper_add_one_connector() for better readability.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1581305c1053..673a47445d61 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -109,31 +109,38 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
for (({ lockdep_assert_held(&(fbh)->dev->mode_config.mutex); }), \
i__ = 0; i__ < (fbh)->connector_count; i__++)
-int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
drm_connector *connector)
+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
+ struct drm_connector *connector)
{
+ struct drm_fb_helper_connector *fb_conn;
struct drm_fb_helper_connector **temp;
- struct drm_fb_helper_connector *fb_helper_connector;
+ unsigned int count;
if (!drm_fbdev_emulation)
return 0;
WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));
- if (fb_helper->connector_count + 1 >
fb_helper->connector_info_alloc_count) {
- temp = krealloc(fb_helper->connector_info, sizeof(struct
drm_fb_helper_connector *) * (fb_helper->connector_count + 1), GFP_KERNEL);
+
+ count = fb_helper->connector_count + 1;
+
+ if (count > fb_helper->connector_info_alloc_count) {
+ size_t size = count * sizeof(fb_conn);
+
+ temp = krealloc(fb_helper->connector_info, size, GFP_KERNEL);
if (!temp)
return -ENOMEM;
- fb_helper->connector_info_alloc_count =
fb_helper->connector_count + 1;
+ fb_helper->connector_info_alloc_count = count;
fb_helper->connector_info = temp;
}
- fb_helper_connector = kzalloc(sizeof(struct drm_fb_helper_connector),
GFP_KERNEL);
- if (!fb_helper_connector)
+ fb_conn = kzalloc(sizeof(*fb_conn), GFP_KERNEL);
+ if (!fb_conn)
return -ENOMEM;
drm_connector_get(connector);
- fb_helper_connector->connector = connector;
- fb_helper->connector_info[fb_helper->connector_count++] =
fb_helper_connector;
+ fb_conn->connector = connector;
+ fb_helper->connector_info[fb_helper->connector_count++] = fb_conn;
return 0;
}
EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 01/11] drm/fb-helper: Cleanup checkpatch warnings
From: Thierry Reding
Fix up a couple of checkpatch warnings, such as whitespace or coding
style issues.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 54 -
1 file changed, 32 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e65becd964a1..d06027a1b9fa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -213,9 +213,9 @@ int drm_fb_helper_remove_one_connector(struct drm_fb_helper
*fb_helper,
fb_helper_connector = fb_helper->connector_info[i];
drm_connector_put(fb_helper_connector->connector);
- for (j = i + 1; j < fb_helper->connector_count; j++) {
+ for (j = i + 1; j < fb_helper->connector_count; j++)
fb_helper->connector_info[j - 1] = fb_helper->connector_info[j];
- }
+
fb_helper->connector_count--;
kfree(fb_helper_connector);
@@ -316,6 +316,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
for (i = 0; i < helper->crtc_count; i++) {
struct drm_mode_set *mode_set = &helper->crtc_info[i].mode_set;
+
crtc = mode_set->crtc;
funcs = crtc->helper_private;
fb = drm_mode_config_fb(crtc);
@@ -346,7 +347,7 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper)
struct drm_plane *plane;
struct drm_atomic_state *state;
int i, ret;
- unsigned plane_mask;
+ unsigned int plane_mask;
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -378,7 +379,7 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper)
goto fail;
}
- for(i = 0; i < fb_helper->crtc_count; i++) {
+ for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set =
&fb_helper->crtc_info[i].mode_set;
ret = __drm_atomic_helper_set_config(mode_set, state);
@@ -488,8 +489,10 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper
*fb_helper)
struct drm_crtc *crtc;
int bound = 0, crtcs_bound = 0;
- /* Sometimes user space wants everything disabled, so don't steal the
-* display if there's a master. */
+ /*
+* Sometimes user space wants everything disabled, so don't steal the
+* display if there's a master.
+*/
if (READ_ONCE(dev->master))
return false;
@@ -537,6 +540,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
static void drm_fb_helper_restore_work_fn(struct work_struct *ignored)
{
bool ret;
+
ret = drm_fb_helper_force_kernel_mode();
if (ret == true)
DRM_ERROR("Failed to restore crtc configuration\n");
@@ -870,9 +874,8 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
mutex_lock(&kernel_fb_helper_lock);
if (!list_empty(&fb_helper->kernel_fb_list)) {
list_del(&fb_helper->kernel_fb_list);
- if (list_empty(&kernel_fb_helper_list)) {
+ if (list_empty(&kernel_fb_helper_list))
unregister_sysrq_key('v',
&sysrq_drm_fb_helper_restore_op);
- }
}
mutex_unlock(&kernel_fb_helper_lock);
@@ -1165,6 +1168,7 @@ static int setcolreg(struct drm_crtc *crtc, u16 red, u16
green,
(blue << info->var.blue.offset);
if (info->var.transp.length > 0) {
u32 mask = (1 << info->var.transp.length) - 1;
+
mask <<= info->var.transp.offset;
value |= mask;
}
@@ -1447,7 +1451,7 @@ static int pan_display_atomic(struct fb_var_screeninfo
*var,
struct drm_atomic_state *state;
struct drm_plane *plane;
int i, ret;
- unsigned plane_mask;
+ unsigned int plane_mask;
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -1456,7 +1460,7 @@ static int pan_display_atomic(struct fb_var_screeninfo
*var,
state->acquire_ctx = dev->mode_config.acquire_ctx;
retry:
plane_mask = 0;
- for(i = 0; i < fb_helper->crtc_count; i++) {
+ for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set;
mode_set = &fb_helper->crtc_info[i].mode_set;
@@ -1561,11 +1565,10 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
memset(&sizes, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
sizes.surface_bpp = 32;
- sizes.fb_width = (unsigned)-1;
- sizes.fb_height = (unsigned)-1;
+ sizes.fb_width = (u32)-1;
+ sizes.fb_height = (u32)-1;
- /* if driver picks 8 or 16 by default use that
- for both depth/bpp */
+ /* if driver picks 8 or 16 by default use that f
[PATCH v4 11/11] drm/rockchip: Remove unnecessary NULL check
From: Thierry Reding
The expression &private->fbdev_helper can never be NULL, so the check is
completely unnecessary.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 81f9548672b0..df6bceabeca8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -168,10 +168,8 @@ rockchip_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
static void rockchip_drm_output_poll_changed(struct drm_device *dev)
{
struct rockchip_drm_private *private = dev->dev_private;
- struct drm_fb_helper *fb_helper = &private->fbdev_helper;
- if (fb_helper)
- drm_fb_helper_hotplug_event(fb_helper);
+ drm_fb_helper_hotplug_event(&private->fbdev_helper);
}
static void
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 05/11] drm/fb-helper: Add top-level lock
From: Thierry Reding
Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 26 +-
include/drm/drm_fb_helper.h | 12
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 18105cbe9810..860be51d92f6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -119,6 +119,7 @@ static int __drm_fb_helper_add_one_connector(struct
drm_fb_helper *fb_helper,
if (!drm_fbdev_emulation)
return 0;
+ WARN_ON(!mutex_is_locked(&fb_helper->lock));
WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));
count = fb_helper->connector_count + 1;
@@ -150,11 +151,13 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper
*fb_helper,
{
int err;
+ mutex_lock(&fb_helper->lock);
mutex_lock(&fb_helper->dev->mode_config.mutex);
err = __drm_fb_helper_add_one_connector(fb_helper, connector);
mutex_unlock(&fb_helper->dev->mode_config.mutex);
+ mutex_unlock(&fb_helper->lock);
return err;
}
@@ -184,6 +187,7 @@ int drm_fb_helper_single_add_all_connectors(struct
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return 0;
+ mutex_lock(&fb_helper->lock);
mutex_lock(&dev->mode_config.mutex);
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
@@ -207,6 +211,7 @@ int drm_fb_helper_single_add_all_connectors(struct
drm_fb_helper *fb_helper)
out:
drm_connector_list_iter_end(&conn_iter);
mutex_unlock(&dev->mode_config.mutex);
+ mutex_unlock(&fb_helper->lock);
return ret;
}
@@ -221,6 +226,7 @@ static int __drm_fb_helper_remove_one_connector(struct
drm_fb_helper *fb_helper,
if (!drm_fbdev_emulation)
return 0;
+ WARN_ON(!mutex_is_locked(&fb_helper->lock));
WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));
for (i = 0; i < fb_helper->connector_count; i++) {
@@ -247,11 +253,13 @@ int drm_fb_helper_remove_one_connector(struct
drm_fb_helper *fb_helper,
{
int err;
+ mutex_lock(&fb_helper->lock);
mutex_lock(&fb_helper->dev->mode_config.mutex);
err = __drm_fb_helper_remove_one_connector(fb_helper, connector);
mutex_unlock(&fb_helper->dev->mode_config.mutex);
+ mutex_unlock(&fb_helper->lock);
return err;
}
@@ -503,16 +511,21 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return -ENODEV;
+ mutex_lock(&fb_helper->lock);
drm_modeset_lock_all(dev);
+
ret = restore_fbdev_mode(fb_helper);
do_delayed = fb_helper->delayed_hotplug;
if (do_delayed)
fb_helper->delayed_hotplug = false;
+
drm_modeset_unlock_all(dev);
+ mutex_unlock(&fb_helper->lock);
if (do_delayed)
drm_fb_helper_hotplug_event(fb_helper);
+
return ret;
}
EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
@@ -748,6 +761,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
drm_fb_helper *helper,
INIT_WORK(&helper->resume_work, drm_fb_helper_resume_worker);
INIT_WORK(&helper->dirty_work, drm_fb_helper_dirty_work);
helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
+ mutex_init(&helper->lock);
helper->funcs = funcs;
helper->dev = dev;
}
@@ -913,6 +927,7 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
}
mutex_unlock(&kernel_fb_helper_lock);
+ mutex_destroy(&fb_helper->lock);
drm_fb_helper_crtc_free(fb_helper);
}
@@ -2422,25 +2437,34 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
+ int err = 0;
if (!drm_fbdev_emulation)
return 0;
+ mutex_lock(&fb_helper->lock);
mutex_lock(&dev->mode_config.mutex);
+
if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) {
fb_helper->delayed_hotplug = true;
mutex_unlock(&dev->mode_config.mutex);
- return 0;
+ goto unlock;
}
+
DRM_DEBUG_KMS("\n");
drm_setup_crtcs(fb_helper, fb_helper->fb->width, fb_helper->fb->height);
mutex_unlock(&dev->mode_config.mutex);
+ mutex_unlock(&fb_helper->lock);
drm_fb_helper_set_par(fb_helper->fbdev);
return 0;
+
+unlock:
+ mutex_unlock(&fb_helper->lock);
+ return err;
}
EXPOR
[PATCH v4 10/11] drm/atmel-hlcdc: Remove unnecessary NULL check
From: Thierry Reding
drm_fbdev_cma_hotplug_event() already checks for NULL pointers before
dereferencing, so callers don't need to do that.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index f4a3065f7f51..31443402b9a9 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -450,8 +450,7 @@ static void atmel_hlcdc_fb_output_poll_changed(struct
drm_device *dev)
{
struct atmel_hlcdc_dc *dc = dev->dev_private;
- if (dc->fbdev)
- drm_fbdev_cma_hotplug_event(dc->fbdev);
+ drm_fbdev_cma_hotplug_event(dc->fbdev);
}
struct atmel_hlcdc_dc_commit {
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 07/11] drm/fb-helper: Support deferred setup
From: Thierry Reding
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.
The fallback is in place because VGA connectors can happen to report an
unknown connection status even when they are in fact connected.
Some drivers have custom solutions in place to defer FB helper setup
until at least one output is connected. But the logic behind these
solutions is always the same and there is nothing driver-specific about
it, so a better alterative is to fix the FB helper core and add support
for all drivers automatically.
This patch adds support for deferred FB helper setup. It checks all the
connectors for their connection status, and if all of them report to be
disconnected marks the FB helper as needing deferred setup. Whet setup
is deferred, the FB helper core will automatically retry setup after a
hotplug event, and it will keep trying until it succeeds.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 53 +
include/drm/drm_fb_helper.h | 23 ++
2 files changed, 71 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 21a90322531c..e9fe47d218e1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -505,6 +505,9 @@ __drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
WARN_ON(!mutex_is_locked(&fb_helper->lock));
+ if (fb_helper->deferred_setup)
+ return 0;
+
drm_modeset_lock_all(dev);
ret = restore_fbdev_mode(fb_helper);
@@ -1611,6 +1614,23 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
*var,
}
EXPORT_SYMBOL(drm_fb_helper_pan_display);
+static bool drm_fb_helper_maybe_connected(struct drm_fb_helper *helper)
+{
+ bool connected = false;
+ unsigned int i;
+
+ for (i = 0; i < helper->connector_count; i++) {
+ struct drm_fb_helper_connector *fb = helper->connector_info[i];
+
+ if (fb->connector->status != connector_status_disconnected) {
+ connected = true;
+ break;
+ }
+ }
+
+ return connected;
+}
+
/*
* Allocates the backing storage and sets up the fbdev info structure through
* the ->fb_probe callback and then registers the fbdev and sets up the panic
@@ -2268,8 +2288,6 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper,
int i;
DRM_DEBUG_KMS("\n");
- if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0)
- DRM_DEBUG_KMS("No connectors reported connected with modes\n");
/* prevent concurrent modification of connector_count by hotplug */
lockdep_assert_held(&fb_helper->dev->mode_config.mutex);
@@ -2351,6 +2369,7 @@ static int __drm_fb_helper_initial_config(struct
drm_fb_helper *fb_helper,
int bpp_sel)
{
struct drm_device *dev = fb_helper->dev;
+ unsigned int width, height;
struct fb_info *info;
int ret;
@@ -2360,14 +2379,34 @@ static int __drm_fb_helper_initial_config(struct
drm_fb_helper *fb_helper,
WARN_ON(!mutex_is_locked(&fb_helper->lock));
mutex_lock(&dev->mode_config.mutex);
- drm_setup_crtcs(fb_helper,
- dev->mode_config.max_width,
- dev->mode_config.max_height);
+
+ width = dev->mode_config.max_width;
+ height = dev->mode_config.max_height;
+
+ if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0)
+ DRM_DEBUG_KMS("No connectors reported connected with modes\n");
+
+ /*
+* If everything's disconnected, there's no use in attempting to set
+* up fbdev.
+*/
+ if (!drm_fb_helper_maybe_connected(fb_helper)) {
+ DRM_INFO("No outputs connected, deferring setup\n");
+ fb_helper->preferred_bpp = bpp_sel;
+ fb_helper->deferred_setup = true;
+ mutex_unlock(&dev->mode_config.mutex);
+ return 0;
+ }
+
+ drm_setup_crtcs(fb_helper, width, height);
+
ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
mutex_unlock(&dev->mode_config.mutex);
if (ret)
return ret;
+ fb_helper->deferred_setup = false;
+
info = fb_helper->fbdev;
info->var.pixclock = 0;
ret = register_framebuffer(info);
@@ -2451,6 +2490,10 @@ static int __drm_fb_helper_hotplug_event(struct
drm_fb_helper *fb_helper)
WARN_ON(!mutex_is_locked(&fb_helper->lock));
+ if (fb_helper->deferred_setup)
+ return __drm_fb_helper_i
[PATCH v4 06/11] drm/fb-helper: Make top-level lock more robust
From: Thierry Reding
The existing drm_fb_helper_hotplug_event() function needs to take the
top-level fb-helper lock. However, the function can also be called from
code that has already taken this lock. Introduce an unlocked variant of
this function that can be used in the latter case.
This function calls drm_fb_helper_restore_fbdev_mode_unlocked(), via
drm_fb_helper_set_par(), so we also need to introduce an unlocked copy
of that to avoid recursive locking issues.
Similarly, the drm_fb_helper_initial_config() function ends up calling
drm_fb_helper_set_par(), via register_framebuffer(), and needs an
unlocked variant to avoid recursive locking.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 167 +---
1 file changed, 104 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 860be51d92f6..21a90322531c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -491,18 +491,10 @@ static int restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
return 0;
}
-/**
- * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
- * @fb_helper: fbcon to restore
- *
- * This should be called from driver's drm &drm_driver.lastclose callback
- * when implementing an fbcon on top of kms using this helper. This ensures
that
- * the user isn't greeted with a black screen when e.g. X dies.
- *
- * RETURNS:
- * Zero if everything went ok, negative error code otherwise.
- */
-int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
+static int __drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
+
+static int
+__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
bool do_delayed;
@@ -511,7 +503,8 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return -ENODEV;
- mutex_lock(&fb_helper->lock);
+ WARN_ON(!mutex_is_locked(&fb_helper->lock));
+
drm_modeset_lock_all(dev);
ret = restore_fbdev_mode(fb_helper);
@@ -521,10 +514,31 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
fb_helper->delayed_hotplug = false;
drm_modeset_unlock_all(dev);
- mutex_unlock(&fb_helper->lock);
if (do_delayed)
- drm_fb_helper_hotplug_event(fb_helper);
+ __drm_fb_helper_hotplug_event(fb_helper);
+
+ return ret;
+}
+
+/**
+ * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
+ * @fb_helper: fbcon to restore
+ *
+ * This should be called from driver's drm &drm_driver.lastclose callback
+ * when implementing an fbcon on top of kms using this helper. This ensures
that
+ * the user isn't greeted with a black screen when e.g. X dies.
+ *
+ * RETURNS:
+ * Zero if everything went ok, negative error code otherwise.
+ */
+int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
+{
+ int ret;
+
+ mutex_lock(&fb_helper->lock);
+ ret = __drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
+ mutex_unlock(&fb_helper->lock);
return ret;
}
@@ -1486,7 +1500,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
return -EINVAL;
}
- drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
+ __drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
return 0;
}
@@ -2333,6 +2347,46 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper,
kfree(enabled);
}
+static int __drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper,
+ int bpp_sel)
+{
+ struct drm_device *dev = fb_helper->dev;
+ struct fb_info *info;
+ int ret;
+
+ if (!drm_fbdev_emulation)
+ return 0;
+
+ WARN_ON(!mutex_is_locked(&fb_helper->lock));
+
+ mutex_lock(&dev->mode_config.mutex);
+ drm_setup_crtcs(fb_helper,
+ dev->mode_config.max_width,
+ dev->mode_config.max_height);
+ ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
+ mutex_unlock(&dev->mode_config.mutex);
+ if (ret)
+ return ret;
+
+ info = fb_helper->fbdev;
+ info->var.pixclock = 0;
+ ret = register_framebuffer(info);
+ if (ret < 0)
+ return ret;
+
+ dev_info(dev->dev, "fb%d: %s frame buffer device\n",
+info->node, info->fix.id);
+
+ mutex_lock(&kernel_fb_helper_lock);
+ if (list_empty(&kernel_fb_helper_list))
+ register_sysrq_key('v', &sysrq_drm_fb_helper_restore_op);
+
+ list_add(&fb_helper->kernel_fb_list, &kernel_fb_helper_list);
+ mutex_unlock(&kernel_fb_helper_lock);
+
+ return 0;
+}
+
/**
* drm_fb_helper_initial_
[PATCH v4 00/11] drm/fb-helper: Deferred setup support
From: Thierry Reding This set of patches adds support for deferring FB helper setup, which is useful to obtain a sane configuration even when no outputs are available during probe. One example is HDMI, where fbdev will currently fallback to a 1024x786 resolution if no monitor is connected, and will then forever stay that way. With these patches, the FB helpers will take note that it doesn't make sense to setup fbdev yet and will defer until a monitor is connected, at which point the preferred mode will be selected. Thierry Changes in v4: - use fb_conn for variables of type struct drm_fb_helper_connector * for consistency - make top-level FB helper lock more robust - improve kerneldoc Changes in v3: - fix kerneldoc for top-level FB helper lock - drop some patches that no longer apply - add Tested-by from John Stultz - add cleanup patches Changes in v2: - now with locking Thierry Reding (11): drm/fb-helper: Cleanup checkpatch warnings drm/fb-helper: Reshuffle code for subsequent patches drm/fb-helper: Improve code readability drm/fb-helper: Push down modeset lock into FB helpers drm/fb-helper: Add top-level lock drm/fb-helper: Make top-level lock more robust drm/fb-helper: Support deferred setup drm/exynos: Remove custom FB helper deferred setup drm/hisilicon: Remove custom FB helper deferred setup drm/atmel-hlcdc: Remove unnecessary NULL check drm/rockchip: Remove unnecessary NULL check drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 3 +- drivers/gpu/drm/drm_fb_helper.c | 376 +--- drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 23 -- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 21 +- drivers/gpu/drm/i915/intel_dp_mst.c | 3 - drivers/gpu/drm/radeon/radeon_dp_mst.c | 7 - drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 4 +- include/drm/drm_fb_helper.h | 35 +++ 9 files changed, 316 insertions(+), 162 deletions(-) -- 2.12.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 02/11] drm/fb-helper: Reshuffle code for subsequent patches
From: Thierry Reding
An unlocked version of the drm_fb_helper_add_one_connector() function
will be added in a subsequent patch. Reshuffle the code separately to
make the diff more readable later on.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 59 -
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d06027a1b9fa..1581305c1053 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -109,6 +109,35 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
for (({ lockdep_assert_held(&(fbh)->dev->mode_config.mutex); }), \
i__ = 0; i__ < (fbh)->connector_count; i__++)
+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
drm_connector *connector)
+{
+ struct drm_fb_helper_connector **temp;
+ struct drm_fb_helper_connector *fb_helper_connector;
+
+ if (!drm_fbdev_emulation)
+ return 0;
+
+ WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));
+ if (fb_helper->connector_count + 1 >
fb_helper->connector_info_alloc_count) {
+ temp = krealloc(fb_helper->connector_info, sizeof(struct
drm_fb_helper_connector *) * (fb_helper->connector_count + 1), GFP_KERNEL);
+ if (!temp)
+ return -ENOMEM;
+
+ fb_helper->connector_info_alloc_count =
fb_helper->connector_count + 1;
+ fb_helper->connector_info = temp;
+ }
+
+ fb_helper_connector = kzalloc(sizeof(struct drm_fb_helper_connector),
GFP_KERNEL);
+ if (!fb_helper_connector)
+ return -ENOMEM;
+
+ drm_connector_get(connector);
+ fb_helper_connector->connector = connector;
+ fb_helper->connector_info[fb_helper->connector_count++] =
fb_helper_connector;
+ return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
+
/**
* drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
*emulation helper
@@ -162,36 +191,6 @@ int drm_fb_helper_single_add_all_connectors(struct
drm_fb_helper *fb_helper)
}
EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
-int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
drm_connector *connector)
-{
- struct drm_fb_helper_connector **temp;
- struct drm_fb_helper_connector *fb_helper_connector;
-
- if (!drm_fbdev_emulation)
- return 0;
-
- WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));
- if (fb_helper->connector_count + 1 >
fb_helper->connector_info_alloc_count) {
- temp = krealloc(fb_helper->connector_info, sizeof(struct
drm_fb_helper_connector *) * (fb_helper->connector_count + 1), GFP_KERNEL);
- if (!temp)
- return -ENOMEM;
-
- fb_helper->connector_info_alloc_count =
fb_helper->connector_count + 1;
- fb_helper->connector_info = temp;
- }
-
-
- fb_helper_connector = kzalloc(sizeof(struct drm_fb_helper_connector),
GFP_KERNEL);
- if (!fb_helper_connector)
- return -ENOMEM;
-
- drm_connector_get(connector);
- fb_helper_connector->connector = connector;
- fb_helper->connector_info[fb_helper->connector_count++] =
fb_helper_connector;
- return 0;
-}
-EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
-
int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
struct drm_connector *connector)
{
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/11] drm/hisilicon: Remove custom FB helper deferred setup
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index df4f50713e54..408c7cfc180c 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -55,14 +55,7 @@ static void kirin_fbdev_output_poll_changed(struct
drm_device *dev)
{
struct kirin_drm_private *priv = dev->dev_private;
- if (priv->fbdev) {
- drm_fbdev_cma_hotplug_event(priv->fbdev);
- } else {
- priv->fbdev = drm_fbdev_cma_init(dev, 32,
-
dev->mode_config.num_connector);
- if (IS_ERR(priv->fbdev))
- priv->fbdev = NULL;
- }
+ drm_fbdev_cma_hotplug_event(priv->fbdev);
}
#endif
@@ -129,11 +122,19 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
- /* force detection after connectors init */
- (void)drm_helper_hpd_irq_event(dev);
+ priv->fbdev = drm_fbdev_cma_init(dev, 32,
+dev->mode_config.num_connector);
+ if (IS_ERR(priv->fbdev)) {
+ DRM_ERROR("failed to initialize fbdev.\n");
+ ret = PTR_ERR(priv->fbdev);
+ goto err_cleanup_poll;
+ }
return 0;
+err_cleanup_poll:
+ drm_kms_helper_poll_fini(dev);
+ drm_vblank_cleanup(dev);
err_unbind_all:
component_unbind_all(dev->dev, dev);
err_dc_cleanup:
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 08/11] drm/exynos: Remove custom FB helper deferred setup
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 --
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 23 ---
2 files changed, 4 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 09d3c4c3c858..08f9533ddbe8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -399,8 +399,9 @@ static int exynos_drm_bind(struct device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(drm);
- /* force connectors detection */
- drm_helper_hpd_irq_event(drm);
+ ret = exynos_drm_fbdev_init(drm);
+ if (ret)
+ goto err_cleanup_poll;
/* register the DRM device */
ret = drm_dev_register(drm, 0);
@@ -411,6 +412,7 @@ static int exynos_drm_bind(struct device *dev)
err_cleanup_fbdev:
exynos_drm_fbdev_fini(drm);
+err_cleanup_poll:
drm_kms_helper_poll_fini(drm);
exynos_drm_device_subdrv_remove(drm);
err_cleanup_vblank:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 641531243e04..e64a1041dd29 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -183,24 +183,6 @@ static const struct drm_fb_helper_funcs
exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
};
-static bool exynos_drm_fbdev_is_anything_connected(struct drm_device *dev)
-{
- struct drm_connector *connector;
- bool ret = false;
-
- mutex_lock(&dev->mode_config.mutex);
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- if (connector->status != connector_status_connected)
- continue;
-
- ret = true;
- break;
- }
- mutex_unlock(&dev->mode_config.mutex);
-
- return ret;
-}
-
int exynos_drm_fbdev_init(struct drm_device *dev)
{
struct exynos_drm_fbdev *fbdev;
@@ -211,9 +193,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
if (!dev->mode_config.num_crtc || !dev->mode_config.num_connector)
return 0;
- if (!exynos_drm_fbdev_is_anything_connected(dev))
- return 0;
-
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (!fbdev)
return -ENOMEM;
@@ -306,6 +285,4 @@ void exynos_drm_output_poll_changed(struct drm_device *dev)
if (fb_helper)
drm_fb_helper_hotplug_event(fb_helper);
- else
- exynos_drm_fbdev_init(dev);
}
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/11] drm/fb-helper: Push down modeset lock into FB helpers
From: Thierry Reding
Move the modeset locking from drivers into FB helpers.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c| 40 +-
drivers/gpu/drm/i915/intel_dp_mst.c| 3 ---
drivers/gpu/drm/radeon/radeon_dp_mst.c | 7 --
3 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 673a47445d61..18105cbe9810 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -109,8 +109,8 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
for (({ lockdep_assert_held(&(fbh)->dev->mode_config.mutex); }), \
i__ = 0; i__ < (fbh)->connector_count; i__++)
-int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
- struct drm_connector *connector)
+static int __drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
+struct drm_connector *connector)
{
struct drm_fb_helper_connector *fb_conn;
struct drm_fb_helper_connector **temp;
@@ -141,8 +141,23 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper
*fb_helper,
drm_connector_get(connector);
fb_conn->connector = connector;
fb_helper->connector_info[fb_helper->connector_count++] = fb_conn;
+
return 0;
}
+
+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
+ struct drm_connector *connector)
+{
+ int err;
+
+ mutex_lock(&fb_helper->dev->mode_config.mutex);
+
+ err = __drm_fb_helper_add_one_connector(fb_helper, connector);
+
+ mutex_unlock(&fb_helper->dev->mode_config.mutex);
+
+ return err;
+}
EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
/**
@@ -172,8 +187,7 @@ int drm_fb_helper_single_add_all_connectors(struct
drm_fb_helper *fb_helper)
mutex_lock(&dev->mode_config.mutex);
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
- ret = drm_fb_helper_add_one_connector(fb_helper, connector);
-
+ ret = __drm_fb_helper_add_one_connector(fb_helper, connector);
if (ret)
goto fail;
}
@@ -198,8 +212,8 @@ int drm_fb_helper_single_add_all_connectors(struct
drm_fb_helper *fb_helper)
}
EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
-int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
- struct drm_connector *connector)
+static int __drm_fb_helper_remove_one_connector(struct drm_fb_helper
*fb_helper,
+ struct drm_connector *connector)
{
struct drm_fb_helper_connector *fb_helper_connector;
int i, j;
@@ -227,6 +241,20 @@ int drm_fb_helper_remove_one_connector(struct
drm_fb_helper *fb_helper,
return 0;
}
+
+int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
+ struct drm_connector *connector)
+{
+ int err;
+
+ mutex_lock(&fb_helper->dev->mode_config.mutex);
+
+ err = __drm_fb_helper_remove_one_connector(fb_helper, connector);
+
+ mutex_unlock(&fb_helper->dev->mode_config.mutex);
+
+ return err;
+}
EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
static void drm_fb_helper_save_lut_atomic(struct drm_crtc *crtc, struct
drm_fb_helper *helper)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c1f62eb07c07..1e3ee32a9acb 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -484,15 +484,12 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
- struct drm_device *dev = connector->dev;
drm_connector_unregister(connector);
/* need to nuke the connector */
- drm_modeset_lock_all(dev);
intel_connector_remove_from_fbdev(intel_connector);
intel_connector->mst_port = NULL;
- drm_modeset_unlock_all(dev);
drm_connector_unreference(&intel_connector->base);
DRM_DEBUG_KMS("\n");
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index 6598306dca9b..ebdf1b859cb6 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -300,9 +300,7 @@ static void radeon_dp_register_mst_connector(struct
drm_connector *connector)
struct drm_device *dev = connector->dev;
struct radeon_device *rdev = dev->dev_private;
- drm_modeset_lock_all(dev);
radeon_fb_add_connector(rdev, connector);
- drm_modeset_unlo
Re: [Nouveau] [PATCH v2 00/10] Enable HDMI Stereoscopy
On Wed, Mar 29, 2017 at 10:24 AM, Alastair Bridgewater wrote: > On Wed, Mar 29, 2017 at 8:02 AM, Ville Syrjälä > wrote: >> >> On Mon, Mar 27, 2017 at 05:57:57PM -0400, Alastair Bridgewater wrote: >> > And the tenth patch enables stereo mode support... on HDMI and DPort >> > connectors on nv50+ hardware. HDMI connectors because obvious. DPort >> > connectors because of DPort to HDMI adaptors. >> >> Do you mean DP++ or actual protocol converters? DP++ is just HDMI with >> a some electrical tweaks, but IIRC proper DP defines 3D stereo quite >> differently than HDMI. I'm not sure if we should be able to push HDMI >> style 3D through DP->HDMI/DP++ adaptors. The specs are unfortunately >> very vague when it comes to such devices. > > DP++. Good point about the protocol converters, though I don't recall > seeing any way to distinguish between a DP and a DP++ connector in > nouveau, nor do I know if nVidia actually made any boards with DP that > isn't DP++. I guess I have some digging to do in that direction. Thank > you. I wouldn't be surprised if the externally-encodered G200 DP connectors didn't support DP++. I do think that the vast majority of DP ports are actually DP++ (on NVIDIA, and probably everywhere). However since this is (edge case)^2 [G200 DP, 3D DP], I wouldn't spend too much time worrying about it. I doubt it's documented anywhere, and equally doubtful any such sinks exist. Should be able to find a VBIOS with the external DP encoders though, and you can check the DCB specs that NVIDIA published at ftp://download.nvidia.com/open-gpu-doc/DCB/2/DCB-4.x-Specification.html. (Looks like there is something there under "DFP Specific Information" -> HDMI, not 100% sure where in nouveau it's decoded though.) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 06/11] drm/fb-helper: Make top-level lock more robust
On Wed, Mar 29, 2017 at 04:43:56PM +0200, Thierry Reding wrote: > From: Thierry Reding > > The existing drm_fb_helper_hotplug_event() function needs to take the > top-level fb-helper lock. However, the function can also be called from > code that has already taken this lock. Introduce an unlocked variant of > this function that can be used in the latter case. > > This function calls drm_fb_helper_restore_fbdev_mode_unlocked(), via > drm_fb_helper_set_par(), so we also need to introduce an unlocked copy > of that to avoid recursive locking issues. > > Similarly, the drm_fb_helper_initial_config() function ends up calling > drm_fb_helper_set_par(), via register_framebuffer(), and needs an > unlocked variant to avoid recursive locking. > > Signed-off-by: Thierry Reding > --- > drivers/gpu/drm/drm_fb_helper.c | 167 > +--- > 1 file changed, 104 insertions(+), 63 deletions(-) Note that this could probably be squashed into 05/11, but I left it separate for easier review since it's the only new patch in the series. Also I had originally split this into three separate patches, but the recursive call stack for the drm_fb_helper_hotplug_event() function and drm_fb_helper_restore_fbdev_mode_unlocked() made it impossible to keep bisectibility across the series. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Fix IB va_start+ib_bytes range check on 32Bit systems
On 29/03/17 10:22 PM, Christian König wrote:
> Am 29.03.2017 um 11:18 schrieb Jan Burgmeier:
>> Signed-off-by: Jan Burgmeier
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> index 99424cb8020b..583d22974e14 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> @@ -908,6 +908,7 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device
>> *adev,
>> struct amdgpu_bo *aobj = NULL;
>> uint64_t offset;
>> uint8_t *kptr;
>> +uint64_t it_last;
>> m = amdgpu_cs_find_mapping(parser, chunk_ib->va_start,
>> &aobj);
>> @@ -916,8 +917,9 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device
>> *adev,
>> return -EINVAL;
>> }
>> +it_last = m->it.last;
>> if ((chunk_ib->va_start + chunk_ib->ib_bytes) >
>> -(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
>> +(it_last + 1) * AMDGPU_GPU_PAGE_SIZE) {
>
> Nice catch, but just adding a u64 case should do here as well. E.g:
>
> if ((chunk_ib->va_start + chunk_ib->ib_bytes) >
> (u64)(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
That won't work correctly if m->it.last == 0x ? Or is that not
possible?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Fix IB va_start+ib_bytes range check on 32Bit systems
Am 29.03.2017 um 16:54 schrieb Michel Dänzer:
On 29/03/17 10:22 PM, Christian König wrote:
Am 29.03.2017 um 11:18 schrieb Jan Burgmeier:
Signed-off-by: Jan Burgmeier
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 99424cb8020b..583d22974e14 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -908,6 +908,7 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device
*adev,
struct amdgpu_bo *aobj = NULL;
uint64_t offset;
uint8_t *kptr;
+uint64_t it_last;
m = amdgpu_cs_find_mapping(parser, chunk_ib->va_start,
&aobj);
@@ -916,8 +917,9 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device
*adev,
return -EINVAL;
}
+it_last = m->it.last;
if ((chunk_ib->va_start + chunk_ib->ib_bytes) >
-(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
+(it_last + 1) * AMDGPU_GPU_PAGE_SIZE) {
Nice catch, but just adding a u64 case should do here as well. E.g:
if ((chunk_ib->va_start + chunk_ib->ib_bytes) >
(u64)(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
That won't work correctly if m->it.last == 0x ? Or is that not
possible?
Hui, why? is it.last signed?
And even then m->it.last probably won't ever become 0x on a
32bit system.
BTW: We need to fix using the 64bit R/B tree instead of the long sized
tree for Vega10 here anyway.
Regards,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-nightly 1077/1091] drivers/gpu/drm/drm_irq.c:341:6: error: call to '__cmpxchg_called_with_bad_pointer' declared with attribute error: Bad argument size for cmpxchg
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: 2f9f22b419350cafb06ba7e5342bc461fcb0afca commit: 43dc7fe2b2118c76fbc2808dec0c57b3158e6dc0 [1077/1091] drm: Mark up accesses of vblank->enabled outside of its spinlock config: tile-tilegx_defconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 43dc7fe2b2118c76fbc2808dec0c57b3158e6dc0 # save the attached .config to linux build tree make.cross ARCH=tile All errors (new ones prefixed by >>): drivers/gpu/drm/drm_irq.c: In function 'vblank_disable_and_save': drivers/gpu/drm/drm_irq.c:341:5: warning: '__x' may be used uninitialized in this function [-Wuninitialized] >> drivers/gpu/drm/drm_irq.c:341:6: error: call to >> '__cmpxchg_called_with_bad_pointer' declared with attribute error: Bad >> argument size for cmpxchg vim +/__cmpxchg_called_with_bad_pointer +341 drivers/gpu/drm/drm_irq.c 335 336 /* 337 * Only disable vblank interrupts if they're enabled. This avoids 338 * calling the ->disable_vblank() operation in atomic context with the 339 * hardware potentially runtime suspended. 340 */ > 341 if (cmpxchg_relaxed(&vblank->enabled, true, false)) 342 __disable_vblank(dev, pipe); 343 344 /* --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5.1 03/11] cec: integrate CEC notifier support
Support the CEC notifier framework, simplifying drivers that
depend on this.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
Accidentally removed adap->notifier causing this to fail. Fixed this
stupid mistake.
---
drivers/media/cec/cec-core.c | 22 ++
include/media/cec.h | 10 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 37217e205040..e5070b374276 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -195,6 +195,24 @@ static void cec_devnode_unregister(struct cec_devnode
*devnode)
put_device(&devnode->dev);
}
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+static void cec_cec_notify(struct cec_adapter *adap, u16 pa)
+{
+ cec_s_phys_addr(adap, pa, false);
+}
+
+void cec_register_cec_notifier(struct cec_adapter *adap,
+ struct cec_notifier *notifier)
+{
+ if (WARN_ON(!adap->devnode.registered))
+ return;
+
+ adap->notifier = notifier;
+ cec_notifier_register(adap->notifier, adap, cec_cec_notify);
+}
+EXPORT_SYMBOL_GPL(cec_register_cec_notifier);
+#endif
+
struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
void *priv, const char *name, u32 caps,
u8 available_las)
@@ -343,6 +361,10 @@ void cec_unregister_adapter(struct cec_adapter *adap)
adap->rc = NULL;
#endif
debugfs_remove_recursive(adap->cec_dir);
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+ if (adap->notifier)
+ cec_notifier_unregister(adap->notifier);
+#endif
cec_devnode_unregister(&adap->devnode);
}
EXPORT_SYMBOL_GPL(cec_unregister_adapter);
diff --git a/include/media/cec.h b/include/media/cec.h
index 96a0aa770d61..307f5dcaf034 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/**
* struct cec_devnode - cec device node
@@ -173,6 +174,10 @@ struct cec_adapter {
bool passthrough;
struct cec_log_addrs log_addrs;
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+ struct cec_notifier *notifier;
+#endif
+
struct dentry *cec_dir;
struct dentry *status_file;
@@ -213,6 +218,11 @@ void cec_transmit_done(struct cec_adapter *adap, u8
status, u8 arb_lost_cnt,
u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+void cec_register_cec_notifier(struct cec_adapter *adap,
+ struct cec_notifier *notifier);
+#endif
+
#else
static inline int cec_register_adapter(struct cec_adapter *adap,
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5 00/11] video/exynos/sti/cec: add CEC notifier & use in drivers
2017-03-29 16:15 GMT+02:00 Hans Verkuil : > From: Hans Verkuil > > This patch series adds the CEC physical address notifier code, based on > Russell's code: > > https://patchwork.kernel.org/patch/9277043/ > > It adds support for it to the exynos_hdmi drm driver, adds support for > it to the CEC framework and finally adds support to the s5p-cec driver, > which now can be moved out of staging. > > Also included is similar code for the STI platform, contributed by > Benjamin Gaignard. > > Tested the exynos code with my Odroid U3 exynos4 devboard. > > After discussions with Daniel Vetter and Russell King I have removed > the EDID/ELD/HPD connect/disconnect events from the notifier and now > just use it to report the CEC physical address. This also means that > it is now renamed to CEC notifier instead of HPD notifier and that > it is now in drivers/media. The block_notifier was dropped as well > and instead a simple callback is registered. This means that the > relationship between HDMI and CEC is now 1:1 and no longer 1:n, but > should this be needed in the future, then that can easily be added > back. > > Daniel, regarding your suggestions here: > > http://www.spinics.net/lists/dri-devel/msg133907.html > > this patch series maps to your mail above as follows: > > struct cec_pin == struct cec_notifier > cec_(un)register_pin == cec_notifier_get/put > cec_set_address == cec_notifier_set_phys_addr > cec_(un)register_callbacks == cec_notifier_(un)register > > Comments are welcome. I'd like to get this in for the 4.12 kernel as > this is a missing piece needed to integrate CEC drivers. I have been able to compile and test sti cec driver so you can add my tested-by on this serie. Thanks, Benjamin > > Regards, > > Hans > > Changes since v4: > - Dropped EDID/ELD/connect/disconnect support. Instead, just report the > CEC physical address (and use INVALID when disconnecting). > - Since this is now completely CEC specific, move it to drivers/media > and rename to cec-notifier. > - Drop block_notifier. Instead just set a callback for the notifier. > - Use 'hdmi-phandle' in the bindings for both exynos and sti. So no > vendor prefix and 'hdmi-phandle' instead of 'hdmi-handle'. > - Make struct cec_notifier opaque. Add a helper function to get the > physical address from a cec_notifier struct. > - Provide dummy functions in cec-notifier.h so it can be used when > CONFIG_MEDIA_CEC_NOTIFIER is undefined. > - Don't select the CEC notifier in the HDMI drivers. It should only > be enabled by actual CEC drivers. > > Changes since v3: > - Added the STI patches > - Split the exynos4 binding patches in one for documentation and one > for the dts change itself, also use the correct subject and CC to > the correct mailinglists (I hope ) > > Changes since v2: > - Split off the dts changes of the s5p-cec patch into a separate patch > - Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name > of the source. > > Changes since v1: > > Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is > not HDMI specific, but is interesting for any video source that has to > deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ). > Only the use with CEC adapters is HDMI specific, but the HPD notifier > is more generic. > > > > > Benjamin Gaignard (4): > sti: hdmi: add CEC notifier support > stih-cec.txt: document new hdmi phandle > stih-cec: add CEC notifier support > arm: sti: update sti-cec for CEC notifier support > > Hans Verkuil (7): > cec-edid: rename cec_get_edid_phys_addr > media: add CEC notifier support > cec: integrate CEC notifier support > exynos_hdmi: add CEC notifier support > ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi > s5p-cec.txt: document the HDMI controller phandle > s5p-cec: add cec-notifier support, move out of staging > > .../devicetree/bindings/media/s5p-cec.txt | 2 + > .../devicetree/bindings/media/stih-cec.txt | 2 + > MAINTAINERS| 4 +- > arch/arm/boot/dts/exynos4.dtsi | 1 + > arch/arm/boot/dts/stih407-family.dtsi | 12 --- > arch/arm/boot/dts/stih410.dtsi | 13 +++ > drivers/gpu/drm/exynos/exynos_hdmi.c | 20 +++- > drivers/gpu/drm/sti/sti_hdmi.c | 11 ++ > drivers/gpu/drm/sti/sti_hdmi.h | 3 + > drivers/media/Kconfig | 3 + > drivers/media/Makefile | 4 + > drivers/media/cec-edid.c | 15 ++- > drivers/media/cec-notifier.c | 116 > + > drivers/media/cec/cec-core.c | 21 > drivers/media/i2c/adv7511.c| 5 +- > drivers/media/i2c/adv7604.c| 3 +- > drivers/media/i2c/adv7842.c| 2 +- > drivers/media/platfo
[pull] radeon drm-fixes-4.11
Hi Dave, One small fix for radeon. The following changes since commit d64a04720b0e64c1cd0726a3a27b360822fbee22: Merge branch 'drm-fixes-4.11' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-03-24 11:05:06 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.11 for you to fetch changes up to ce4b4f228e51219b0b79588caf73225b08b5b779: drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags (2017-03-27 16:17:30 -0400) Michel Dänzer (1): drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"
On 29.03.2017 11:36, Michel Dänzer wrote: On 29/03/17 06:07 PM, Christian König wrote: Am 29.03.2017 um 10:59 schrieb Michel Dänzer: On 28/03/17 08:00 PM, Julien Isorce wrote: On 28 March 2017 at 10:36, Michel Dänzer mailto:mic...@daenzer.net>> wrote: On 28/03/17 05:24 PM, Julien Isorce wrote: > Hi Michel, > > About the hard lockup, I noticed that I cannot have it with the > following conditions: > > 1. soft lockup fix (the 0->i change which avoids infinite loop) > 2. Your suggestion: (!(rbo->flags & RADEON_GEM_CPU_ACCESS) > 3. radeon.gartsize=512 radeon.vramlimit=1024 (any other values above do > not help, for example (1024, 1024) or (1024, 2048)) > > Without 1 and 2, but with 3, our test reproduces the soft lockup (just > discovered few days ago). > Without 3 (and with or without 1., 2.), our test reproduces the hard > lockup which one does not give any info in kern.log (sometimes some NUL > ^@ characters but not always). What exactly does "hard lockup" mean? What are the symptoms? Screens are frozen, cannot ssh, no mouse/keyboard, no kernel panic. Requires hard reboot. After reboot, nothing in /var/crash, nothing in /sys/fs/pstore, nothing in kern.log except sometimes some nul characters ^@. Does it still respond to ping when it's hung? Using a serial console did not show additional debug messages. kgdb was not useful but probably worth another attempt. Right. Anyway, I'm afraid it sounds like it's probably not directly related to the issue I was thinking of for my previous test patch or other similar ones I was thinking of writing. Yeah, agree. Additional to that a complete crash where you don't even get anything over serial console is rather unlikely to be cause by something an application can do directly. Possible causes are more likely power management or completely messing up a bus system. Have you tried disabling dpm as well? Might also be worth trying the amdgpu kernel driver instead of radeon, not sure how well the former currently works with Cape Verde though. I've recently used it to experiment with the sparse buffer support. It worked well enough for that :) Cheers, Nicolai -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fixup failure paths in drm_atomic_helper_set_config
I've screwed this up when removing the legacy backoff hack.
Fixes: 38b6441e4e75 ("drm/atomic-helper: Remove the backoff hack from
set_config")
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9dc67b52b905..d5915317e7d3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2294,10 +2294,11 @@ int drm_atomic_helper_set_config(struct drm_mode_set
*set,
state->acquire_ctx = ctx;
ret = __drm_atomic_helper_set_config(set, state);
if (ret != 0)
- return ret;
+ goto fail;
ret = drm_atomic_commit(state);
+fail:
drm_atomic_state_put(state);
return ret;
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/ttm: add TTM_PL_FLAG_CONTIGUOUS
From: Christian König This allows drivers to specify if they need a contiguous allocation or not. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c| 4 +++- include/drm/ttm/ttm_placement.h | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 96b1450..35c12c7 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1062,7 +1062,9 @@ static bool ttm_bo_places_compat(const struct ttm_place *places, *new_flags = heap->flags; if ((*new_flags & mem->placement & TTM_PL_MASK_CACHING) && - (*new_flags & mem->placement & TTM_PL_MASK_MEM)) + (*new_flags & mem->placement & TTM_PL_MASK_MEM) && + (!(*new_flags & TTM_PL_FLAG_CONTIGUOUS) || +(mem->placement & TTM_PL_FLAG_CONTIGUOUS))) return true; } return false; diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h index 932be0c..40f947f 100644 --- a/include/drm/ttm/ttm_placement.h +++ b/include/drm/ttm/ttm_placement.h @@ -63,6 +63,7 @@ #define TTM_PL_FLAG_CACHED (1 << 16) #define TTM_PL_FLAG_UNCACHED(1 << 17) #define TTM_PL_FLAG_WC (1 << 18) +#define TTM_PL_FLAG_CONTIGUOUS (1 << 19) #define TTM_PL_FLAG_NO_EVICT(1 << 21) #define TTM_PL_FLAG_TOPDOWN (1 << 22) -- 2.5.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/ttm: cleanup and optimize ttm_bo_mem_compat
From: Christian König
No need to implement the same logic twice. Also check if the busy placements
are identical to the already scanned placements before checking them.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 45
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 989b98b..96b1450 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1046,29 +1046,17 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object
*bo,
return ret;
}
-bool ttm_bo_mem_compat(struct ttm_placement *placement,
- struct ttm_mem_reg *mem,
- uint32_t *new_flags)
+static bool ttm_bo_places_compat(const struct ttm_place *places,
+unsigned num_placement,
+struct ttm_mem_reg *mem,
+uint32_t *new_flags)
{
- int i;
+ unsigned i;
- for (i = 0; i < placement->num_placement; i++) {
- const struct ttm_place *heap = &placement->placement[i];
- if (mem->mm_node &&
- (mem->start < heap->fpfn ||
-(heap->lpfn != 0 && (mem->start + mem->num_pages) >
heap->lpfn)))
- continue;
+ for (i = 0; i < num_placement; i++) {
+ const struct ttm_place *heap = &places[i];
- *new_flags = heap->flags;
- if ((*new_flags & mem->placement & TTM_PL_MASK_CACHING) &&
- (*new_flags & mem->placement & TTM_PL_MASK_MEM))
- return true;
- }
-
- for (i = 0; i < placement->num_busy_placement; i++) {
- const struct ttm_place *heap = &placement->busy_placement[i];
- if (mem->mm_node &&
- (mem->start < heap->fpfn ||
+ if (mem->mm_node && (mem->start < heap->fpfn ||
(heap->lpfn != 0 && (mem->start + mem->num_pages) >
heap->lpfn)))
continue;
@@ -1077,6 +1065,23 @@ bool ttm_bo_mem_compat(struct ttm_placement *placement,
(*new_flags & mem->placement & TTM_PL_MASK_MEM))
return true;
}
+ return false;
+}
+
+bool ttm_bo_mem_compat(struct ttm_placement *placement,
+ struct ttm_mem_reg *mem,
+ uint32_t *new_flags)
+{
+ if (ttm_bo_places_compat(placement->placement, placement->num_placement,
+mem, new_flags))
+ return true;
+
+ if ((placement->busy_placement != placement->placement ||
+placement->num_busy_placement != placement->num_placement) &&
+ ttm_bo_places_compat(placement->busy_placement,
+placement->num_busy_placement,
+mem, new_flags))
+ return true;
return false;
}
--
2.5.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/ttm: add io_mem_pfn callback
From: Christian König
This allows the driver to handle io_mem mappings on their own.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 +
drivers/gpu/drm/ast/ast_ttm.c | 1 +
drivers/gpu/drm/bochs/bochs_mm.c| 1 +
drivers/gpu/drm/cirrus/cirrus_ttm.c | 1 +
drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.c| 1 +
drivers/gpu/drm/qxl/qxl_ttm.c | 1 +
drivers/gpu/drm/radeon/radeon_ttm.c | 1 +
drivers/gpu/drm/ttm/ttm_bo_vm.c | 10 +-
drivers/gpu/drm/virtio/virtgpu_ttm.c| 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 1 +
include/drm/ttm/ttm_bo_api.h| 11 +++
include/drm/ttm/ttm_bo_driver.h | 9 +
13 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 21876ee..7bf5ba7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1089,6 +1089,7 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.fault_reserve_notify = &amdgpu_bo_fault_reserve_notify,
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_free = &amdgpu_ttm_io_mem_free,
+ .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int amdgpu_ttm_init(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 50c910e..e879496 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -236,6 +236,7 @@ struct ttm_bo_driver ast_bo_driver = {
.verify_access = ast_bo_verify_access,
.io_mem_reserve = &ast_ttm_io_mem_reserve,
.io_mem_free = &ast_ttm_io_mem_free,
+ .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int ast_mm_init(struct ast_private *ast)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index e4c1125..804afbc 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -205,6 +205,7 @@ struct ttm_bo_driver bochs_bo_driver = {
.verify_access = bochs_bo_verify_access,
.io_mem_reserve = &bochs_ttm_io_mem_reserve,
.io_mem_free = &bochs_ttm_io_mem_free,
+ .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int bochs_mm_init(struct bochs_device *bochs)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index f53aa8f..93dbcd3 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -236,6 +236,7 @@ struct ttm_bo_driver cirrus_bo_driver = {
.verify_access = cirrus_bo_verify_access,
.io_mem_reserve = &cirrus_ttm_io_mem_reserve,
.io_mem_free = &cirrus_ttm_io_mem_free,
+ .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int cirrus_mm_init(struct cirrus_device *cirrus)
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 657598b..565a217 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -236,6 +236,7 @@ struct ttm_bo_driver mgag200_bo_driver = {
.verify_access = mgag200_bo_verify_access,
.io_mem_reserve = &mgag200_ttm_io_mem_reserve,
.io_mem_free = &mgag200_ttm_io_mem_free,
+ .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int mgag200_mm_init(struct mga_device *mdev)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 3949a74..978a5e7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1570,6 +1570,7 @@ struct ttm_bo_driver nouveau_bo_driver = {
.fault_reserve_notify = &nouveau_ttm_fault_reserve_notify,
.io_mem_reserve = &nouveau_ttm_io_mem_reserve,
.io_mem_free = &nouveau_ttm_io_mem_free,
+ .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
struct nvkm_vma *
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 2955f91..28fa56e 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -394,6 +394,7 @@ static struct ttm_bo_driver qxl_bo_driver = {
.verify_access = &qxl_verify_access,
.io_mem_reserve = &qxl_ttm_io_mem_reserve,
.io_mem_free = &qxl_ttm_io_mem_free,
+ .io_mem_pfn = ttm_bo_default_io_mem_pfn,
.move_notify = &qxl_bo_move_notify,
};
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 6571384..d07ff84 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -873,6 +873,7 @@ static struct ttm_bo_driver radeon_bo_driver = {
.fault_reserve_notify = &radeon_bo_fault_reserve_notify,
.io_mem_reserve = &radeon_ttm_io_mem_reserve,
.io_mem_free = &radeon_ttm_io_mem_free,
+ .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int radeon_ttm_init(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
[PATCH 6/6] drm/amdgpu: handle CPU access for split VRAM buffers
From: Christian König
This avoids merging them together on page fault.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 16
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 387d190..10237a8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -927,8 +927,7 @@ int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object
*bo)
size = bo->mem.num_pages << PAGE_SHIFT;
offset = bo->mem.start << PAGE_SHIFT;
/* TODO: figure out how to map scattered VRAM to the CPU */
- if ((offset + size) <= adev->mc.visible_vram_size &&
- (abo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS))
+ if ((offset + size) <= adev->mc.visible_vram_size)
return 0;
/* Can't move a pinned BO to visible VRAM */
@@ -936,7 +935,6 @@ int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object
*bo)
return -EINVAL;
/* hurrah the memory is not visible ! */
- abo->flags |= AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS;
amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM);
lpfn = adev->mc.visible_vram_size >> PAGE_SHIFT;
for (i = 0; i < abo->placement.num_placement; i++) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 524abca..10b793a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -529,9 +529,6 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_mem_
case TTM_PL_TT:
break;
case TTM_PL_VRAM:
- if (mem->start == AMDGPU_BO_INVALID_OFFSET)
- return -EINVAL;
-
mem->bus.offset = mem->start << PAGE_SHIFT;
/* check if it's visible */
if ((mem->bus.offset + mem->bus.size) >
adev->mc.visible_vram_size)
@@ -549,6 +546,17 @@ static void amdgpu_ttm_io_mem_free(struct ttm_bo_device
*bdev, struct ttm_mem_re
{
}
+static unsigned long amdgpu_ttm_io_mem_pfn(struct ttm_buffer_object *bo,
+ unsigned long page_offset)
+{
+ struct drm_mm_node *mm = bo->mem.mm_node;
+ uint64_t size = mm->size;
+
+ mm += page_offset / size;
+ page_offset %= size;
+ return (bo->mem.bus.base >> PAGE_SHIFT) + mm->start + page_offset;
+}
+
/*
* TTM backend functions.
*/
@@ -1064,7 +1072,7 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.fault_reserve_notify = &amdgpu_bo_fault_reserve_notify,
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_free = &amdgpu_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
+ .io_mem_pfn = amdgpu_ttm_io_mem_pfn,
};
int amdgpu_ttm_init(struct amdgpu_device *adev)
--
2.5.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/amdgpu: use TTM_PL_FLAG_CONTIGUOUS
From: Christian König
Implement AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS using TTM_PL_FLAG_CONTIGUOUS
instead of a placement limit. That allows us to better handle CPU
accessible placements.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 14 ++
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index d6b2de9..387d190 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -122,20 +122,19 @@ static void amdgpu_ttm_placement_init(struct
amdgpu_device *adev,
if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
unsigned visible_pfn = adev->mc.visible_vram_size >> PAGE_SHIFT;
- unsigned lpfn = 0;
-
- /* This forces a reallocation if the flag wasn't set before */
- if (flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS)
- lpfn = adev->mc.real_vram_size >> PAGE_SHIFT;
places[c].fpfn = 0;
- places[c].lpfn = lpfn;
+ places[c].lpfn = 0;
places[c].flags = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_VRAM;
+
if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)
places[c].lpfn = visible_pfn;
else
places[c].flags |= TTM_PL_FLAG_TOPDOWN;
+
+ if (flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS)
+ places[c].flags |= TTM_PL_FLAG_CONTIGUOUS;
c++;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index d710226..af2d172 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -93,7 +93,6 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
const struct ttm_place *place,
struct ttm_mem_reg *mem)
{
- struct amdgpu_bo *bo = container_of(tbo, struct amdgpu_bo, tbo);
struct amdgpu_vram_mgr *mgr = man->priv;
struct drm_mm *mm = &mgr->mm;
struct drm_mm_node *nodes;
@@ -107,8 +106,8 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
if (!lpfn)
lpfn = man->size;
- if (bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS ||
- place->lpfn || amdgpu_vram_page_split == -1) {
+ if (place->flags & TTM_PL_FLAG_CONTIGUOUS ||
+ amdgpu_vram_page_split == -1) {
pages_per_node = ~0ul;
num_nodes = 1;
} else {
@@ -126,12 +125,14 @@ static int amdgpu_vram_mgr_new(struct
ttm_mem_type_manager *man,
aflags = DRM_MM_CREATE_TOP;
}
+ mem->start = 0;
pages_left = mem->num_pages;
spin_lock(&mgr->lock);
for (i = 0; i < num_nodes; ++i) {
unsigned long pages = min(pages_left, pages_per_node);
uint32_t alignment = mem->page_alignment;
+ unsigned long start;
if (pages == pages_per_node)
alignment = pages_per_node;
@@ -145,11 +146,16 @@ static int amdgpu_vram_mgr_new(struct
ttm_mem_type_manager *man,
if (unlikely(r))
goto error;
+ /*
+* Calculate a virtual BO start address to easily check if
+* everything is CPU accessible.
+*/
+ start = nodes[i].start + nodes[i].size - mem->num_pages;
+ mem->start = max(mem->start, start);
pages_left -= pages;
}
spin_unlock(&mgr->lock);
- mem->start = num_nodes == 1 ? nodes[0].start : AMDGPU_BO_INVALID_OFFSET;
mem->mm_node = nodes;
return 0;
--
2.5.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/amdgpu: drop alpha support
From: Christian König We will probably never see this combination. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 25 - 1 file changed, 25 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 7bf5ba7..524abca 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -538,31 +538,6 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_ return -EINVAL; mem->bus.base = adev->mc.aper_base; mem->bus.is_iomem = true; -#ifdef __alpha__ - /* -* Alpha: use bus.addr to hold the ioremap() return, -* so we can modify bus.base below. -*/ - if (mem->placement & TTM_PL_FLAG_WC) - mem->bus.addr = - ioremap_wc(mem->bus.base + mem->bus.offset, - mem->bus.size); - else - mem->bus.addr = - ioremap_nocache(mem->bus.base + mem->bus.offset, - mem->bus.size); - if (!mem->bus.addr) - return -ENOMEM; - - /* -* Alpha: Use just the bus offset plus -* the hose/domain memory base for bus.base. -* It then can be used to build PTEs for VRAM -* access, as done in ttm_bo_vm_fault(). -*/ - mem->bus.base = (mem->bus.base & 0x0UL) + - adev->ddev->hose->dense_mem_base; -#endif break; default: return -EINVAL; -- 2.5.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5 00/11] video/exynos/sti/cec: add CEC notifier & use in drivers
On Wed, Mar 29, 2017 at 04:15:32PM +0200, Hans Verkuil wrote: > From: Hans Verkuil > > This patch series adds the CEC physical address notifier code, based on > Russell's code: > > https://patchwork.kernel.org/patch/9277043/ > > It adds support for it to the exynos_hdmi drm driver, adds support for > it to the CEC framework and finally adds support to the s5p-cec driver, > which now can be moved out of staging. > > Also included is similar code for the STI platform, contributed by > Benjamin Gaignard. > > Tested the exynos code with my Odroid U3 exynos4 devboard. > > After discussions with Daniel Vetter and Russell King I have removed > the EDID/ELD/HPD connect/disconnect events from the notifier and now > just use it to report the CEC physical address. This also means that > it is now renamed to CEC notifier instead of HPD notifier and that > it is now in drivers/media. The block_notifier was dropped as well > and instead a simple callback is registered. This means that the > relationship between HDMI and CEC is now 1:1 and no longer 1:n, but > should this be needed in the future, then that can easily be added > back. > > Daniel, regarding your suggestions here: > > http://www.spinics.net/lists/dri-devel/msg133907.html > > this patch series maps to your mail above as follows: > > struct cec_pin == struct cec_notifier > cec_(un)register_pin == cec_notifier_get/put > cec_set_address == cec_notifier_set_phys_addr > cec_(un)register_callbacks == cec_notifier_(un)register > > Comments are welcome. I'd like to get this in for the 4.12 kernel as > this is a missing piece needed to integrate CEC drivers. > > Regards, > > Hans > > Changes since v4: > - Dropped EDID/ELD/connect/disconnect support. Instead, just report the > CEC physical address (and use INVALID when disconnecting). > - Since this is now completely CEC specific, move it to drivers/media > and rename to cec-notifier. > - Drop block_notifier. Instead just set a callback for the notifier. > - Use 'hdmi-phandle' in the bindings for both exynos and sti. So no > vendor prefix and 'hdmi-phandle' instead of 'hdmi-handle'. > - Make struct cec_notifier opaque. Add a helper function to get the > physical address from a cec_notifier struct. > - Provide dummy functions in cec-notifier.h so it can be used when > CONFIG_MEDIA_CEC_NOTIFIER is undefined. > - Don't select the CEC notifier in the HDMI drivers. It should only > be enabled by actual CEC drivers. I just quickly scaned through it, but this seems to address all my concerns fully. Thanks for respinning. On the entire pile (or just the core cec notifier bits): Acked-by: Daniel Vetter > > Changes since v3: > - Added the STI patches > - Split the exynos4 binding patches in one for documentation and one > for the dts change itself, also use the correct subject and CC to > the correct mailinglists (I hope ) > > Changes since v2: > - Split off the dts changes of the s5p-cec patch into a separate patch > - Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name > of the source. > > Changes since v1: > > Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is > not HDMI specific, but is interesting for any video source that has to > deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ). > Only the use with CEC adapters is HDMI specific, but the HPD notifier > is more generic. > > > > > Benjamin Gaignard (4): > sti: hdmi: add CEC notifier support > stih-cec.txt: document new hdmi phandle > stih-cec: add CEC notifier support > arm: sti: update sti-cec for CEC notifier support > > Hans Verkuil (7): > cec-edid: rename cec_get_edid_phys_addr > media: add CEC notifier support > cec: integrate CEC notifier support > exynos_hdmi: add CEC notifier support > ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi > s5p-cec.txt: document the HDMI controller phandle > s5p-cec: add cec-notifier support, move out of staging > > .../devicetree/bindings/media/s5p-cec.txt | 2 + > .../devicetree/bindings/media/stih-cec.txt | 2 + > MAINTAINERS| 4 +- > arch/arm/boot/dts/exynos4.dtsi | 1 + > arch/arm/boot/dts/stih407-family.dtsi | 12 --- > arch/arm/boot/dts/stih410.dtsi | 13 +++ > drivers/gpu/drm/exynos/exynos_hdmi.c | 20 +++- > drivers/gpu/drm/sti/sti_hdmi.c | 11 ++ > drivers/gpu/drm/sti/sti_hdmi.h | 3 + > drivers/media/Kconfig | 3 + > drivers/media/Makefile | 4 + > drivers/media/cec-edid.c | 15 ++- > drivers/media/cec-notifier.c | 116 > + > drivers/media/cec/cec-core.c | 21 > drivers/media/i2c/adv7511.c| 5 +- > drivers/media/i2c/adv7604.c
Re: [Intel-gfx] [PATCH v4 08/11] drm/exynos: Remove custom FB helper deferred setup
On Wed, Mar 29, 2017 at 04:43:58PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The FB helper core now supports deferred setup, so the driver's custom
> implementation can be removed.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 --
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 23 ---
> 2 files changed, 4 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 09d3c4c3c858..08f9533ddbe8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -399,8 +399,9 @@ static int exynos_drm_bind(struct device *dev)
> /* init kms poll for handling hpd */
> drm_kms_helper_poll_init(drm);
>
> - /* force connectors detection */
> - drm_helper_hpd_irq_event(drm);
> + ret = exynos_drm_fbdev_init(drm);
> + if (ret)
> + goto err_cleanup_poll;
>
> /* register the DRM device */
> ret = drm_dev_register(drm, 0);
> @@ -411,6 +412,7 @@ static int exynos_drm_bind(struct device *dev)
>
> err_cleanup_fbdev:
> exynos_drm_fbdev_fini(drm);
> +err_cleanup_poll:
> drm_kms_helper_poll_fini(drm);
> exynos_drm_device_subdrv_remove(drm);
> err_cleanup_vblank:
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 641531243e04..e64a1041dd29 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -183,24 +183,6 @@ static const struct drm_fb_helper_funcs
> exynos_drm_fb_helper_funcs = {
> .fb_probe = exynos_drm_fbdev_create,
> };
>
> -static bool exynos_drm_fbdev_is_anything_connected(struct drm_device *dev)
> -{
> - struct drm_connector *connector;
> - bool ret = false;
> -
> - mutex_lock(&dev->mode_config.mutex);
> - list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> - if (connector->status != connector_status_connected)
> - continue;
> -
> - ret = true;
> - break;
> - }
> - mutex_unlock(&dev->mode_config.mutex);
> -
> - return ret;
> -}
> -
> int exynos_drm_fbdev_init(struct drm_device *dev)
> {
> struct exynos_drm_fbdev *fbdev;
> @@ -211,9 +193,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
> if (!dev->mode_config.num_crtc || !dev->mode_config.num_connector)
> return 0;
>
> - if (!exynos_drm_fbdev_is_anything_connected(dev))
> - return 0;
> -
> fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
> if (!fbdev)
> return -ENOMEM;
> @@ -306,6 +285,4 @@ void exynos_drm_output_poll_changed(struct drm_device
> *dev)
>
> if (fb_helper)
> drm_fb_helper_hotplug_event(fb_helper);
Tiny nit: I think you can remove the above NULL check too. With that:
Reviewed-by: Daniel Vetter
> - else
> - exynos_drm_fbdev_init(dev);
> }
> --
> 2.12.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] radeon drm-fixes-4.11
On Wed, Mar 29, 2017 at 1:53 PM, Panariti, David wrote: > Hi, > > I'm still new to this stuff. > Is this informational or some action items? It's a request to Dave (drm maintainer), to pull fixes into the next 4.11 rc kernel. Unless you are Dave, it's largely informational. Alex > > thanks, > davep > >> -Original Message- >> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf >> Of Alex Deucher >> Sent: Wednesday, March 29, 2017 12:55 PM >> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; >> airl...@gmail.com >> Cc: Deucher, Alexander >> Subject: [pull] radeon drm-fixes-4.11 >> >> Hi Dave, >> >> One small fix for radeon. >> >> The following changes since commit >> d64a04720b0e64c1cd0726a3a27b360822fbee22: >> >> Merge branch 'drm-fixes-4.11' of git://people.freedesktop.org/~agd5f/linux >> into drm-fixes (2017-03-24 11:05:06 +1000) >> >> are available in the git repository at: >> >> git://people.freedesktop.org/~agd5f/linux drm-fixes-4.11 >> >> for you to fetch changes up to >> ce4b4f228e51219b0b79588caf73225b08b5b779: >> >> drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags >> (2017-03-27 16:17:30 -0400) >> >> >> Michel Dänzer (1): >> drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags >> >> drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> ___ >> amd-gfx mailing list >> amd-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.76
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 libdrm 2.4.76 has been released. This release is required for upcoming Radeon Vega GPUs. Adam Jackson (1): configure: Explicitly check for pkg-config at the top level Alex Xie (3): amdgpu: Free/uninit vamgr_32 in theoretically correct order amdgpu: vamgr_32 can be a struct instead of a pointer amdgpu: vamgr can be a struct instead of a pointer Chris Wilson (3): intel: Move is_softpin to obj->kflags intel: Move 48b support to bo_gem->kflags intel: Add handle to hashtable before freeing along an error path Christian König (1): amdgpu: stop reading CC_RB_BACKEND_DISABLE on Vega10 Emil Velikov (2): Remove unused tests/drmstat.c headers: add explicit note against local changes in the README Eric Engestrom (2): autogen.sh: don't print old git-config values autogen.sh: run git commands in the (potentially) git dir Huang Rui (2): amdgpu: don't read registers not present on Vega10 tests/amdgpu: fix the count number for vega10 Junwei Zhang (1): tests/amdgpu: add Polaris12 support for cs test Leo Liu (3): tests/amdgpu: add uvd unit test support for vega10 tests/amdgpu: add vce unit test support for vega10 amdgpu_drm: add AMDGPU_HW_IP_UVD_ENC Marek Olšák (3): amdgpu: sync amdgpu_drm.h with kernel 4.11-rc2 amdgpu: update amdgpu_drm.h for Vega10 configure.ac: bump version for release Rob Clark (3): freedreno: fix potential use-after-free on a5xx+ freedreno: valgrind support freedreno: fix device close issues Thomas Hindoe Paaboel Andersen (1): intel: avoid null pointer dereference git tag: libdrm-2.4.76 http://dri.freedesktop.org/libdrm/libdrm-2.4.76.tar.bz2 MD5: 7a28eedd84459ac97017f1aa437237ac libdrm-2.4.76.tar.bz2 SHA1: dc96f064472d3ca58a7004f3219949d749219400 libdrm-2.4.76.tar.bz2 SHA256: 7cdfb83ea77def453299dd95332aa9257c9f3534ff5844f5c0ce87265c275f3a libdrm-2.4.76.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.76.tar.gz MD5: 3c01deb06d6fd5989141092b88e3d991 libdrm-2.4.76.tar.gz SHA1: 832826f2bdcfb66e59f99aed51a61ee76fb9b722 libdrm-2.4.76.tar.gz SHA256: 6e3fb50d7500acf06f7eed44d5b1d33cda26aef7f5ae6667ddcc626b435c2531 libdrm-2.4.76.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJY2/o4AAoJEP3RXVrO8PKxGeAIAMQT3VSMqRAv+DKBfMbAVDSZ L2JY4atiekKVmCqdLYwYJpgmbpyhxs/gldKD2OPGlOoHAPTIvvQBnmJUfS/oCK6y BnxQMfeGsBzNcz3w+scuva5nKT7YoWIaaAVgOuoMEzhFyQ4AKXQeRFtwgaE2EBJg wALzjkUvAYalXAdKX2Sn23J152csuxjDKErmxG19YE19TvN9XS/gb8vGa5WoQlDf 2Zhe32Ryw6ypzUfmm3qPy6dsZwNBbKho24zTA/0u5M0yTCvs3OqNUqswt6HUV3Sq k9PAoN+9PdLoH7NTtNj/TQCEl4f1C3PNsuhQD4kc+sJ8aghYLC5MpoIthQbkfXc= =6LIa -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fixup failure paths in drm_atomic_helper_set_config
Of course. I totally missed that.
Reviewed-by: Harry Wentland
Harry
On 2017-03-29 01:41 PM, Daniel Vetter wrote:
I've screwed this up when removing the legacy backoff hack.
Fixes: 38b6441e4e75 ("drm/atomic-helper: Remove the backoff hack from
set_config")
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9dc67b52b905..d5915317e7d3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2294,10 +2294,11 @@ int drm_atomic_helper_set_config(struct drm_mode_set
*set,
state->acquire_ctx = ctx;
ret = __drm_atomic_helper_set_config(set, state);
if (ret != 0)
- return ret;
+ goto fail;
ret = drm_atomic_commit(state);
+fail:
drm_atomic_state_put(state);
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge
Similar to the previous commit, convert drivers open coding OF graph
parsing to use drm_of_find_panel_or_bridge instead.
This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.
Signed-off-by: Rob Herring
Reviewed-by: Archit Taneja
Tested-by: Philipp Zabel
Acked-by: Maxime Ripard
---
Sean,
I fixed the compile error on FSL DCU. Let me know if you want me to
send the whole series again.
Rob
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 73 ++-
drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
drivers/gpu/drm/bridge/parade-ps8622.c | 16 ++---
drivers/gpu/drm/bridge/tc358767.c| 27 +--
drivers/gpu/drm/exynos/exynos_dp.c | 35 -
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 44
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
drivers/gpu/drm/imx/parallel-display.c | 36 ++
drivers/gpu/drm/mediatek/mtk_dsi.c | 23 ++
drivers/gpu/drm/mxsfb/mxsfb_out.c| 40 ++-
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 26 ++-
drivers/gpu/drm/sun4i/sun4i_rgb.c| 11 +--
drivers/gpu/drm/sun4i/sun4i_tcon.c | 90 ++--
14 files changed, 95 insertions(+), 396 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index e7799b6ee829..f987b4572d4a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -22,7 +22,7 @@
#include
#include
-#include
+#include
#include "atmel_hlcdc_dc.h"
@@ -152,29 +152,11 @@ static const struct drm_connector_funcs
atmel_hlcdc_panel_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
-static int atmel_hlcdc_check_endpoint(struct drm_device *dev,
- const struct of_endpoint *ep)
-{
- struct device_node *np;
- void *obj;
-
- np = of_graph_get_remote_port_parent(ep->local_node);
-
- obj = of_drm_find_panel(np);
- if (!obj)
- obj = of_drm_find_bridge(np);
-
- of_node_put(np);
-
- return obj ? 0 : -EPROBE_DEFER;
-}
-
static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
- const struct of_endpoint *ep)
+ const struct device_node *np)
{
struct atmel_hlcdc_dc *dc = dev->dev_private;
struct atmel_hlcdc_rgb_output *output;
- struct device_node *np;
struct drm_panel *panel;
struct drm_bridge *bridge;
int ret;
@@ -195,13 +177,11 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
*dev,
output->encoder.possible_crtcs = 0x1;
- np = of_graph_get_remote_port_parent(ep->local_node);
-
- ret = -EPROBE_DEFER;
+ ret = drm_of_find_panel_or_bridge(np, 0, 0, &panel, &bridge);
+ if (ret)
+ return ret;
- panel = of_drm_find_panel(np);
if (panel) {
- of_node_put(np);
output->connector.dpms = DRM_MODE_DPMS_OFF;
output->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
drm_connector_helper_add(&output->connector,
@@ -226,9 +206,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
*dev,
return 0;
}
- bridge = of_drm_find_bridge(np);
- of_node_put(np);
-
if (bridge) {
ret = drm_bridge_attach(&output->encoder, bridge, NULL);
if (!ret)
@@ -243,31 +220,23 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
*dev,
int atmel_hlcdc_create_outputs(struct drm_device *dev)
{
- struct device_node *ep_np = NULL;
- struct of_endpoint ep;
- int ret;
-
- for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
- ret = of_graph_parse_endpoint(ep_np, &ep);
- if (!ret)
- ret = atmel_hlcdc_check_endpoint(dev, &ep);
-
- if (ret) {
- of_node_put(ep_np);
- return ret;
- }
- }
-
- for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
- ret = of_graph_parse_endpoint(ep_np, &ep);
- if (!ret)
- ret = atmel_hlcdc_attach_endpoint(dev, &ep);
-
- if (ret) {
- of_node_put(ep_np);
+ struct device_node *remote;
+ int ret, endpoint = 0;
+
+ while (true) {
+ /* Loop thru possible multiple connections to the output */
+ remote = of_graph_get_remote_node(dev->dev->of_node, 0,
[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted
https://bugs.freedesktop.org/show_bug.cgi?id=100306 MirceaKitsune changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from MirceaKitsune --- I'm happy to announce that since xorg-x11-server 1.19.3 and / or xf86-video-ati 7.9.0 the issue appears to have been remedied. I now have over 5 days of uptime, with not a single GPU freeze caused by the desktop. If by chance the problem returns, I'll definitely post an update and let everyone know. It would be very appreciated if in the future, the Xorg team and driver developers could please consider more in-depth testing for GPU lockups, to prevent this sort of thing from repeating. I imagine this issue can be marked as resolved. I will reopen it if I see the problem happening again. Feel free to otherwise reopen it if anyone believes there's still something to investigate. -- 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: [PATCHv5 00/11] video/exynos/sti/cec: add CEC notifier & use in drivers
Hi Daniel, On 29/03/17 19:47, Daniel Vetter wrote: > On Wed, Mar 29, 2017 at 04:15:32PM +0200, Hans Verkuil wrote: >> From: Hans Verkuil >> >> This patch series adds the CEC physical address notifier code, based on >> Russell's code: >> >> https://patchwork.kernel.org/patch/9277043/ >> >> It adds support for it to the exynos_hdmi drm driver, adds support for >> it to the CEC framework and finally adds support to the s5p-cec driver, >> which now can be moved out of staging. >> >> Also included is similar code for the STI platform, contributed by >> Benjamin Gaignard. >> >> Tested the exynos code with my Odroid U3 exynos4 devboard. >> >> After discussions with Daniel Vetter and Russell King I have removed >> the EDID/ELD/HPD connect/disconnect events from the notifier and now >> just use it to report the CEC physical address. This also means that >> it is now renamed to CEC notifier instead of HPD notifier and that >> it is now in drivers/media. The block_notifier was dropped as well >> and instead a simple callback is registered. This means that the >> relationship between HDMI and CEC is now 1:1 and no longer 1:n, but >> should this be needed in the future, then that can easily be added >> back. >> >> Daniel, regarding your suggestions here: >> >> http://www.spinics.net/lists/dri-devel/msg133907.html >> >> this patch series maps to your mail above as follows: >> >> struct cec_pin == struct cec_notifier >> cec_(un)register_pin == cec_notifier_get/put >> cec_set_address == cec_notifier_set_phys_addr >> cec_(un)register_callbacks == cec_notifier_(un)register >> >> Comments are welcome. I'd like to get this in for the 4.12 kernel as >> this is a missing piece needed to integrate CEC drivers. >> >> Regards, >> >> Hans >> >> Changes since v4: >> - Dropped EDID/ELD/connect/disconnect support. Instead, just report the >> CEC physical address (and use INVALID when disconnecting). >> - Since this is now completely CEC specific, move it to drivers/media >> and rename to cec-notifier. >> - Drop block_notifier. Instead just set a callback for the notifier. >> - Use 'hdmi-phandle' in the bindings for both exynos and sti. So no >> vendor prefix and 'hdmi-phandle' instead of 'hdmi-handle'. >> - Make struct cec_notifier opaque. Add a helper function to get the >> physical address from a cec_notifier struct. >> - Provide dummy functions in cec-notifier.h so it can be used when >> CONFIG_MEDIA_CEC_NOTIFIER is undefined. >> - Don't select the CEC notifier in the HDMI drivers. It should only >> be enabled by actual CEC drivers. > > I just quickly scaned through it, but this seems to address all my > concerns fully. Thanks for respinning. On the entire pile (or just the > core cec notifier bits): > > Acked-by: Daniel Vetter Fantastic! Thank you very much for your comments. One last question: the patches for drivers/gpu/drm: can they go through the media subsystem or do you want to take them? They do depend on the first two patches of this series (cec-edid and cec-notifier), so it is a bit more coordination if they have to go through the drm subsystem. Regards, Hans > >> >> Changes since v3: >> - Added the STI patches >> - Split the exynos4 binding patches in one for documentation and one >> for the dts change itself, also use the correct subject and CC to >> the correct mailinglists (I hope ) >> >> Changes since v2: >> - Split off the dts changes of the s5p-cec patch into a separate patch >> - Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name >> of the source. >> >> Changes since v1: >> >> Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is >> not HDMI specific, but is interesting for any video source that has to >> deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ). >> Only the use with CEC adapters is HDMI specific, but the HPD notifier >> is more generic. >> >> >> >> >> Benjamin Gaignard (4): >> sti: hdmi: add CEC notifier support >> stih-cec.txt: document new hdmi phandle >> stih-cec: add CEC notifier support >> arm: sti: update sti-cec for CEC notifier support >> >> Hans Verkuil (7): >> cec-edid: rename cec_get_edid_phys_addr >> media: add CEC notifier support >> cec: integrate CEC notifier support >> exynos_hdmi: add CEC notifier support >> ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi >> s5p-cec.txt: document the HDMI controller phandle >> s5p-cec: add cec-notifier support, move out of staging >> >> .../devicetree/bindings/media/s5p-cec.txt | 2 + >> .../devicetree/bindings/media/stih-cec.txt | 2 + >> MAINTAINERS| 4 +- >> arch/arm/boot/dts/exynos4.dtsi | 1 + >> arch/arm/boot/dts/stih407-family.dtsi | 12 --- >> arch/arm/boot/dts/stih410.dtsi | 13 +++ >> drivers/gpu/drm/exynos/exynos_hdmi.c | 20 +++- >> drivers/gpu/drm/sti/sti_hdmi.c
Re: [PATCH 1/3] drm/i915: Use LINEAR modifier instead of NONE
On Fri, Mar 24, 2017 at 02:29:48PM -0700, Ben Widawsky wrote:
> They're the same, so use the one which makes more sense.
>
> Signed-off-by: Ben Widawsky
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9a28a8917dc1..696d106461f8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1997,7 +1997,7 @@ intel_tile_width_bytes(const struct drm_framebuffer
> *fb, int plane)
> unsigned int cpp = fb->format->cpp[plane];
>
> switch (fb->modifier) {
> - case DRM_FORMAT_MOD_NONE:
> + case DRM_FORMAT_MOD_LINEAR:
> return cpp;
> case I915_FORMAT_MOD_X_TILED:
> if (IS_GEN2(dev_priv))
> @@ -2033,7 +2033,7 @@ intel_tile_width_bytes(const struct drm_framebuffer
> *fb, int plane)
> static unsigned int
> intel_tile_height(const struct drm_framebuffer *fb, int plane)
> {
> - if (fb->modifier == DRM_FORMAT_MOD_NONE)
> + if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
> return 1;
> else
> return intel_tile_size(to_i915(fb->dev)) /
> @@ -2107,7 +2107,7 @@ static unsigned int intel_surf_alignment(const struct
> drm_framebuffer *fb,
> return 4096;
>
> switch (fb->modifier) {
> - case DRM_FORMAT_MOD_NONE:
> + case DRM_FORMAT_MOD_LINEAR:
> return intel_linear_alignment(dev_priv);
> case I915_FORMAT_MOD_X_TILED:
> if (INTEL_GEN(dev_priv) >= 9)
> @@ -2290,7 +2290,7 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
>
> WARN_ON(new_offset > old_offset);
>
> - if (fb->modifier != DRM_FORMAT_MOD_NONE) {
> + if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
> unsigned int tile_size, tile_width, tile_height;
> unsigned int pitch_tiles;
>
> @@ -2345,7 +2345,7 @@ static u32 _intel_compute_tile_offset(const struct
> drm_i915_private *dev_priv,
> if (alignment)
> alignment--;
>
> - if (fb_modifier != DRM_FORMAT_MOD_NONE) {
> + if (fb_modifier != DRM_FORMAT_MOD_LINEAR) {
> unsigned int tile_size, tile_width, tile_height;
> unsigned int tile_rows, tiles, pitch_tiles;
>
> @@ -2471,7 +2471,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
> DRM_ROTATE_0, tile_size);
> offset /= tile_size;
>
> - if (fb->modifier != DRM_FORMAT_MOD_NONE) {
> + if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
> unsigned int tile_width, tile_height;
> unsigned int pitch_tiles;
> struct drm_rect r;
> @@ -2803,7 +2803,7 @@ static int skl_max_plane_width(const struct
> drm_framebuffer *fb, int plane,
> int cpp = fb->format->cpp[plane];
>
> switch (fb->modifier) {
> - case DRM_FORMAT_MOD_NONE:
> + case DRM_FORMAT_MOD_LINEAR:
> case I915_FORMAT_MOD_X_TILED:
> switch (cpp) {
> case 8:
> @@ -3199,7 +3199,7 @@ static void ironlake_update_primary_plane(struct
> drm_plane *primary,
> static u32
> intel_fb_stride_alignment(const struct drm_framebuffer *fb, int plane)
> {
> - if (fb->modifier == DRM_FORMAT_MOD_NONE)
> + if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
> return 64;
> else
> return intel_tile_width_bytes(fb, plane);
> @@ -3298,7 +3298,7 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
> static u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
> {
> switch (fb_modifier) {
> - case DRM_FORMAT_MOD_NONE:
> + case DRM_FORMAT_MOD_LINEAR:
> break;
> case I915_FORMAT_MOD_X_TILED:
> return PLANE_CTL_TILED_X;
> @@ -8426,7 +8426,7 @@ skylake_get_initial_plane_config(struct intel_crtc
> *crtc,
> tiling = val & PLANE_CTL_TILED_MASK;
> switch (tiling) {
> case PLANE_CTL_TILED_LINEAR:
> - fb->modifier = DRM_FORMAT_MOD_NONE;
> + fb->modifier = DRM_FORMAT_MOD_LINEAR;
> break;
> case PLANE_CTL_TILED_X:
> plane_config->tiling = I915_TILING_X;
> @@ -10399,7 +10399,7 @@ static void skl_do_mmio_flip(struct intel_crtc
> *intel_crtc,
> ctl = I915_READ(PLANE_CTL(pipe, 0));
> ctl &= ~PLANE_CTL_TILED_MASK;
> switch (fb->modifier) {
> - case DRM_FORMAT_MOD_NONE:
> + case DRM_FORMAT_MOD_LINEAR:
> break;
> case I915_FORMAT_MOD_X_TILED:
> ctl |= PLANE_CTL_TILED_X;
> @@ -13756,7 +13756,7 @@ intel_check_cursor_plane(struct drm_plane *plane,
> return -ENOMEM;
> }
>
> - if (fb->modifier != DRM_FORMAT_MOD_NONE) {
> + if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
> DRM_DEBUG_KMS("cursor
[Bug 100437] IO_PAGE_FAULT is spammed in dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=100437 Christian Lanig changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Christian Lanig --- This issue is gone after I updated my OS - don't know if it is related. I can't reproduce it anymore, tried with several reboots. However, the powerplay issue stays so it's definitely unrelated. -- 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
amdgpu fixes for display watermark calculations.
Hi, attached two patches for amdgpu to improve the accuracy of display wm calculations, and to avoid some overflow and divide-by-zero errors which can cause the driver to die. Both are tested for the DCE-10 code path with a AMD R9 380 Tonga Pro on two different panels and their various modes. They prevent a driver crash that happened for the "ASUS ROG PG 279" gaming panel when trying to set a 2560x1440 video mode at 165 Hz video refresh, due to division by zero errors in the driver. Probably material for stable, given it prevents crashes? That said, while the driver no longer crashes, and sets 2560x1440 modes at 24, 60, 85, 100 and 120 Hz over DisplayPort just fine on that panel, i so far failed to make it work with 144 Hz or 165 Hz. Modesetting seems to succeed in that xrandr reports the mode being set, and no error or warning messages or anything suspicious in the XOrg or kernel dmesg log or in drm.debug output at high debug settings. The display however goes black and the onscreen display reports "DisplayPort: No Signal!". Tested on Linux 4.9/10/drm-next. The amdgpu-pro 16.50 driver under DC/DAL has no problems setting a working 144 Hz / 165 Hz mode, whereas the same failure happens if i boot it with amdgpu.dc=0 to go back to the old modesetting. Any clues on how to debug the black panel much appreciated. Thanks, -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/amdgpu: Make display watermark calculations more accurate
Avoid big roundoff errors in scanline/hactive durations for
high pixel clocks, especially for >= 500 Mhz, and thereby
program more accurate display fifo watermarks.
Implemented here for DCE 6,8,10,11.
Successfully tested on DCE 10 with AMD R9 380 Tonga.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 10 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 10 +-
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 10 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 10 +-
4 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index d4452d8..d3db921 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1214,14 +1214,14 @@ static void dce_v10_0_program_watermarks(struct
amdgpu_device *adev,
{
struct drm_display_mode *mode = &amdgpu_crtc->base.mode;
struct dce10_wm_params wm_low, wm_high;
- u32 pixel_period;
+ u32 active_time;
u32 line_time = 0;
u32 latency_watermark_a = 0, latency_watermark_b = 0;
u32 tmp, wm_mask, lb_vblank_lead_lines = 0;
if (amdgpu_crtc->base.enabled && num_heads && mode) {
- pixel_period = 100 / (u32)mode->clock;
- line_time = min((u32)mode->crtc_htotal * pixel_period,
(u32)65535);
+ active_time = 100UL * (u32)mode->crtc_hdisplay /
(u32)mode->clock;
+ line_time = min((u32) (100UL * (u32)mode->crtc_htotal /
(u32)mode->clock), (u32)65535);
/* watermark for high clocks */
if (adev->pm.dpm_enabled) {
@@ -1236,7 +1236,7 @@ static void dce_v10_0_program_watermarks(struct
amdgpu_device *adev,
wm_high.disp_clk = mode->clock;
wm_high.src_width = mode->crtc_hdisplay;
- wm_high.active_time = mode->crtc_hdisplay * pixel_period;
+ wm_high.active_time = active_time;
wm_high.blank_time = line_time - wm_high.active_time;
wm_high.interlaced = false;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -1275,7 +1275,7 @@ static void dce_v10_0_program_watermarks(struct
amdgpu_device *adev,
wm_low.disp_clk = mode->clock;
wm_low.src_width = mode->crtc_hdisplay;
- wm_low.active_time = mode->crtc_hdisplay * pixel_period;
+ wm_low.active_time = active_time;
wm_low.blank_time = line_time - wm_low.active_time;
wm_low.interlaced = false;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 5b24e89..15ee8eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1183,14 +1183,14 @@ static void dce_v11_0_program_watermarks(struct
amdgpu_device *adev,
{
struct drm_display_mode *mode = &amdgpu_crtc->base.mode;
struct dce10_wm_params wm_low, wm_high;
- u32 pixel_period;
+ u32 active_time;
u32 line_time = 0;
u32 latency_watermark_a = 0, latency_watermark_b = 0;
u32 tmp, wm_mask, lb_vblank_lead_lines = 0;
if (amdgpu_crtc->base.enabled && num_heads && mode) {
- pixel_period = 100 / (u32)mode->clock;
- line_time = min((u32)mode->crtc_htotal * pixel_period,
(u32)65535);
+ active_time = 100UL * (u32)mode->crtc_hdisplay /
(u32)mode->clock;
+ line_time = min((u32) (100UL * (u32)mode->crtc_htotal /
(u32)mode->clock), (u32)65535);
/* watermark for high clocks */
if (adev->pm.dpm_enabled) {
@@ -1205,7 +1205,7 @@ static void dce_v11_0_program_watermarks(struct
amdgpu_device *adev,
wm_high.disp_clk = mode->clock;
wm_high.src_width = mode->crtc_hdisplay;
- wm_high.active_time = mode->crtc_hdisplay * pixel_period;
+ wm_high.active_time = active_time;
wm_high.blank_time = line_time - wm_high.active_time;
wm_high.interlaced = false;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -1244,7 +1244,7 @@ static void dce_v11_0_program_watermarks(struct
amdgpu_device *adev,
wm_low.disp_clk = mode->clock;
wm_low.src_width = mode->crtc_hdisplay;
- wm_low.active_time = mode->crtc_hdisplay * pixel_period;
+ wm_low.active_time = active_time;
wm_low.blank_time = line_time - wm_low.active_time;
wm_low.interlaced = false;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index 809aa94..cb9158b 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -986,7 +986,7 @
[PATCH 2/2] drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark calculations.
At dot clocks > approx. 250 Mhz, some of these calcs will overflow and
cause miscalculation of latency watermarks, and for some overflows also
divide-by-zero driver crash ("divide error: [#1] PREEMPT SMP" in
"dce_v10_0_latency_watermark+0x12d/0x190").
This zero-divide happened, e.g., on AMD Tonga Pro under DCE-10,
on a Displayport panel when trying to set a video mode of 2560x1440
at 165 Hz vrefresh with a dot clock of 635.540 Mhz.
Refine calculations to avoid the overflows.
Tested for DCE-10 with R9 380 Tonga + ASUS ROG PG279 panel.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 19 +++
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 19 +++
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 19 +++
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 19 +++
4 files changed, 12 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index d3db921..33541ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1090,23 +1090,10 @@ static u32 dce_v10_0_latency_watermark(struct
dce10_wm_params *wm)
a.full = dfixed_const(available_bandwidth);
b.full = dfixed_const(wm->num_heads);
a.full = dfixed_div(a, b);
+ tmp = div_u64((u64) dmif_size * (u64) wm->disp_clk, mc_latency + 512);
+ tmp = min(dfixed_trunc(a), tmp);
- b.full = dfixed_const(mc_latency + 512);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(b, c);
-
- c.full = dfixed_const(dmif_size);
- b.full = dfixed_div(c, b);
-
- tmp = min(dfixed_trunc(a), dfixed_trunc(b));
-
- b.full = dfixed_const(1000);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(c, b);
- c.full = dfixed_const(wm->bytes_per_pixel);
- b.full = dfixed_mul(b, c);
-
- lb_fill_bw = min(tmp, dfixed_trunc(b));
+ lb_fill_bw = min(tmp, wm->disp_clk * wm->bytes_per_pixel / 1000);
a.full = dfixed_const(max_src_lines_per_dst_line * wm->src_width *
wm->bytes_per_pixel);
b.full = dfixed_const(1000);
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 15ee8eb..1388f8a 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1059,23 +1059,10 @@ static u32 dce_v11_0_latency_watermark(struct
dce10_wm_params *wm)
a.full = dfixed_const(available_bandwidth);
b.full = dfixed_const(wm->num_heads);
a.full = dfixed_div(a, b);
+ tmp = div_u64((u64) dmif_size * (u64) wm->disp_clk, mc_latency + 512);
+ tmp = min(dfixed_trunc(a), tmp);
- b.full = dfixed_const(mc_latency + 512);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(b, c);
-
- c.full = dfixed_const(dmif_size);
- b.full = dfixed_div(c, b);
-
- tmp = min(dfixed_trunc(a), dfixed_trunc(b));
-
- b.full = dfixed_const(1000);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(c, b);
- c.full = dfixed_const(wm->bytes_per_pixel);
- b.full = dfixed_mul(b, c);
-
- lb_fill_bw = min(tmp, dfixed_trunc(b));
+ lb_fill_bw = min(tmp, wm->disp_clk * wm->bytes_per_pixel / 1000);
a.full = dfixed_const(max_src_lines_per_dst_line * wm->src_width *
wm->bytes_per_pixel);
b.full = dfixed_const(1000);
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index cb9158b..bad52c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -861,23 +861,10 @@ static u32 dce_v6_0_latency_watermark(struct
dce6_wm_params *wm)
a.full = dfixed_const(available_bandwidth);
b.full = dfixed_const(wm->num_heads);
a.full = dfixed_div(a, b);
+ tmp = div_u64((u64) dmif_size * (u64) wm->disp_clk, mc_latency + 512);
+ tmp = min(dfixed_trunc(a), tmp);
- b.full = dfixed_const(mc_latency + 512);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(b, c);
-
- c.full = dfixed_const(dmif_size);
- b.full = dfixed_div(c, b);
-
- tmp = min(dfixed_trunc(a), dfixed_trunc(b));
-
- b.full = dfixed_const(1000);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(c, b);
- c.full = dfixed_const(wm->bytes_per_pixel);
- b.full = dfixed_mul(b, c);
-
- lb_fill_bw = min(tmp, dfixed_trunc(b));
+ lb_fill_bw = min(tmp, wm->disp_clk * wm->bytes_per_pixel / 1000);
a.full = dfixed_const(max_src_lines_per_dst_line * wm->src_width *
wm->bytes_per_pixel);
b.full = dfixed_const(1000);
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index d547bcf..e52fc92 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -974,23 +974,10 @@ static
Re: [PATCH 3/3] drm/i915: Add format modifiers for Intel
On Fri, Mar 24, 2017 at 02:29:50PM -0700, Ben Widawsky wrote:
> This was based on a patch originally by Kristian. It has been modified
> pretty heavily to use the new callbacks from the previous patch.
>
> v2:
> - Add LINEAR and Yf modifiers to list (Ville)
> - Combine i8xx and i965 into one list of formats (Ville)
> - Allow 1010102 formats for Y/Yf tiled (Ville)
>
> v3:
> - Handle cursor formats (Ville)
> - Put handling for LINEAR in the mod_support functions (Ville)
>
> Cc: Ville Syrjälä
> Cc: Kristian H. Kristensen
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_display.c | 112
> +--
> drivers/gpu/drm/i915/intel_sprite.c | 25 +++-
> 2 files changed, 131 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 802a8449c5d3..bb559a116fda 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
> DRM_FORMAT_XBGR2101010,
> };
>
> +static const uint64_t i9xx_format_modifiers[] = {
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static const uint32_t skl_primary_formats[] = {
> DRM_FORMAT_C8,
> DRM_FORMAT_RGB565,
> @@ -87,6 +93,14 @@ static const uint32_t skl_primary_formats[] = {
> DRM_FORMAT_VYUY,
> };
>
> +static const uint64_t skl_format_modifiers[] = {
> + I915_FORMAT_MOD_Yf_TILED,
> + I915_FORMAT_MOD_Y_TILED,
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> /* Cursor formats */
> static const uint32_t intel_cursor_formats[] = {
> DRM_FORMAT_ARGB,
> @@ -13453,6 +13467,83 @@ void intel_plane_destroy(struct drm_plane *plane)
> kfree(to_intel_plane(plane));
> }
>
> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_XRGB:
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + modifier == I915_FORMAT_MOD_X_TILED;
> + default:
> + return false;
> + }
> +}
> +
> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + modifier == I915_FORMAT_MOD_X_TILED;
> + default:
> + return false;
> + }
> +}
> +
> +static bool skl_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + (modifier >= I915_FORMAT_MOD_X_TILED &&
> + modifier < I915_FORMAT_MOD_Yf_TILED);
The >= stuff makes this harder to parse than it should be IMO.
I'd just list each modifier explicitly.
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + (modifier >= I915_FORMAT_MOD_X_TILED &&
> + modifier <= I915_FORMAT_MOD_Yf_TILED);
ditto. At first I couldn't even spot the difference between this and
the C8 case.
> + case DRM_FORMAT_YUYV:
> + case DRM_FORMAT_YVYU:
> + case DRM_FORMAT_UYVY:
> + case DRM_FORMAT_VYUY:
> + return modifier == DRM_FORMAT_MOD_LINEAR;
Any modifier will do for these formats.
> + default:
> + return false;
> + }
> +
> +}
> +
> +static bool intel_plane_format_mod_supported(struct drm_plane *plane,
> + uint32_t format,
> + uint64_t modifier)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +
> + if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> + return false;
> +
> + if (INTEL_GEN(dev_priv) >= 9)
> + return skl_mod_supported(format, modifier);
> + else if (INTEL_GEN(dev_priv) >= 4)
> + return i965_mod_supported(format, modifier);
> + else
> + return i8xx_mod_supported(format, modifier);
> +
> + return false;
> +}
I'd also like to see .format_mod_supported() + modifiers[] for
cursors as well. Those should only accept LINEAR+ARGB.
Apart from those issues, I think this is looking pretty good.
> +
> const struct drm_plane_funcs intel_plane_funcs = {
> .update_plane = drm
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 Christian Lanig changed: What|Removed |Added Attachment #130529|0 |1 is obsolete|| --- Comment #1 from Christian Lanig --- Created attachment 130551 --> https://bugs.freedesktop.org/attachment.cgi?id=130551&action=edit DMESG_NEW The IO- Errors have gone after I upgraded my OS. I updated the DMESG- file. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use LINEAR modifier instead of NONE
On Wed, Mar 29, 2017 at 11:03:40PM +0300, Ville Syrjälä wrote:
> On Fri, Mar 24, 2017 at 02:29:48PM -0700, Ben Widawsky wrote:
> > They're the same, so use the one which makes more sense.
> >
> > Signed-off-by: Ben Widawsky
>
> Reviewed-by: Ville Syrjälä
And pushed to dinq immediately. Thanks for the patch.
>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 28 ++--
> > 1 file changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 9a28a8917dc1..696d106461f8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -1997,7 +1997,7 @@ intel_tile_width_bytes(const struct drm_framebuffer
> > *fb, int plane)
> > unsigned int cpp = fb->format->cpp[plane];
> >
> > switch (fb->modifier) {
> > - case DRM_FORMAT_MOD_NONE:
> > + case DRM_FORMAT_MOD_LINEAR:
> > return cpp;
> > case I915_FORMAT_MOD_X_TILED:
> > if (IS_GEN2(dev_priv))
> > @@ -2033,7 +2033,7 @@ intel_tile_width_bytes(const struct drm_framebuffer
> > *fb, int plane)
> > static unsigned int
> > intel_tile_height(const struct drm_framebuffer *fb, int plane)
> > {
> > - if (fb->modifier == DRM_FORMAT_MOD_NONE)
> > + if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
> > return 1;
> > else
> > return intel_tile_size(to_i915(fb->dev)) /
> > @@ -2107,7 +2107,7 @@ static unsigned int intel_surf_alignment(const struct
> > drm_framebuffer *fb,
> > return 4096;
> >
> > switch (fb->modifier) {
> > - case DRM_FORMAT_MOD_NONE:
> > + case DRM_FORMAT_MOD_LINEAR:
> > return intel_linear_alignment(dev_priv);
> > case I915_FORMAT_MOD_X_TILED:
> > if (INTEL_GEN(dev_priv) >= 9)
> > @@ -2290,7 +2290,7 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
> >
> > WARN_ON(new_offset > old_offset);
> >
> > - if (fb->modifier != DRM_FORMAT_MOD_NONE) {
> > + if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
> > unsigned int tile_size, tile_width, tile_height;
> > unsigned int pitch_tiles;
> >
> > @@ -2345,7 +2345,7 @@ static u32 _intel_compute_tile_offset(const struct
> > drm_i915_private *dev_priv,
> > if (alignment)
> > alignment--;
> >
> > - if (fb_modifier != DRM_FORMAT_MOD_NONE) {
> > + if (fb_modifier != DRM_FORMAT_MOD_LINEAR) {
> > unsigned int tile_size, tile_width, tile_height;
> > unsigned int tile_rows, tiles, pitch_tiles;
> >
> > @@ -2471,7 +2471,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
> > DRM_ROTATE_0, tile_size);
> > offset /= tile_size;
> >
> > - if (fb->modifier != DRM_FORMAT_MOD_NONE) {
> > + if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
> > unsigned int tile_width, tile_height;
> > unsigned int pitch_tiles;
> > struct drm_rect r;
> > @@ -2803,7 +2803,7 @@ static int skl_max_plane_width(const struct
> > drm_framebuffer *fb, int plane,
> > int cpp = fb->format->cpp[plane];
> >
> > switch (fb->modifier) {
> > - case DRM_FORMAT_MOD_NONE:
> > + case DRM_FORMAT_MOD_LINEAR:
> > case I915_FORMAT_MOD_X_TILED:
> > switch (cpp) {
> > case 8:
> > @@ -3199,7 +3199,7 @@ static void ironlake_update_primary_plane(struct
> > drm_plane *primary,
> > static u32
> > intel_fb_stride_alignment(const struct drm_framebuffer *fb, int plane)
> > {
> > - if (fb->modifier == DRM_FORMAT_MOD_NONE)
> > + if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
> > return 64;
> > else
> > return intel_tile_width_bytes(fb, plane);
> > @@ -3298,7 +3298,7 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
> > static u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
> > {
> > switch (fb_modifier) {
> > - case DRM_FORMAT_MOD_NONE:
> > + case DRM_FORMAT_MOD_LINEAR:
> > break;
> > case I915_FORMAT_MOD_X_TILED:
> > return PLANE_CTL_TILED_X;
> > @@ -8426,7 +8426,7 @@ skylake_get_initial_plane_config(struct intel_crtc
> > *crtc,
> > tiling = val & PLANE_CTL_TILED_MASK;
> > switch (tiling) {
> > case PLANE_CTL_TILED_LINEAR:
> > - fb->modifier = DRM_FORMAT_MOD_NONE;
> > + fb->modifier = DRM_FORMAT_MOD_LINEAR;
> > break;
> > case PLANE_CTL_TILED_X:
> > plane_config->tiling = I915_TILING_X;
> > @@ -10399,7 +10399,7 @@ static void skl_do_mmio_flip(struct intel_crtc
> > *intel_crtc,
> > ctl = I915_READ(PLANE_CTL(pipe, 0));
> > ctl &= ~PLANE_CTL_TILED_MASK;
> > switch (fb->modifier) {
> > - case DRM_FORMAT_MOD_NONE:
> > + case DRM_FORMAT_MOD_LINEAR:
> > break;
> > case I915_FORMAT_MOD_X_TILED:
> > ctl |= PLANE_CTL_TILED_X;
> > @@ -13756,7 +13756,7 @@ intel_check_
[drm-intel:drm-intel-nightly 1066/1091] drivers/gpu/drm/drm_plane.c:933:48-49: ERROR: reference preceded by free on line 926 (fwd)
The kfree on line 926 would only be a problem for the references to e on
lines 933 and 937 if the return value of drm_event_reserve_init can be
-EDEADLK.
julia
-- Forwarded message --
Date: Thu, 30 Mar 2017 00:48:54 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: [drm-intel:drm-intel-nightly 1066/1091]
drivers/gpu/drm/drm_plane.c:933:48-49: ERROR: reference preceded by free on
line 926
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 2f9f22b419350cafb06ba7e5342bc461fcb0afca
commit: 29dc0d1de18239cf3ef8bab578b8321ed340d81c [1066/1091] drm: Roll out
acquire context for the page_flip ioctl
:: branch date: 4 hours ago
:: commit date: 9 hours ago
>> drivers/gpu/drm/drm_plane.c:933:48-49: ERROR: reference preceded by free on
>> line 926
drivers/gpu/drm/drm_plane.c:937:41-42: ERROR: reference preceded by free on
line 926
git remote add drm-intel git://anongit.freedesktop.org/drm-intel
git remote update drm-intel
git checkout 29dc0d1de18239cf3ef8bab578b8321ed340d81c
vim +933 drivers/gpu/drm/drm_plane.c
43968d7b Daniel Vetter 2016-09-21 920 }
43968d7b Daniel Vetter 2016-09-21 921 e->event.base.type =
DRM_EVENT_FLIP_COMPLETE;
43968d7b Daniel Vetter 2016-09-21 922 e->event.base.length =
sizeof(e->event);
43968d7b Daniel Vetter 2016-09-21 923 e->event.user_data =
page_flip->user_data;
43968d7b Daniel Vetter 2016-09-21 924 ret =
drm_event_reserve_init(dev, file_priv, &e->base, &e->event.base);
43968d7b Daniel Vetter 2016-09-21 925 if (ret) {
43968d7b Daniel Vetter 2016-09-21 @926 kfree(e);
43968d7b Daniel Vetter 2016-09-21 927 goto out;
43968d7b Daniel Vetter 2016-09-21 928 }
43968d7b Daniel Vetter 2016-09-21 929 }
43968d7b Daniel Vetter 2016-09-21 930
43968d7b Daniel Vetter 2016-09-21 931 crtc->primary->old_fb =
crtc->primary->fb;
43968d7b Daniel Vetter 2016-09-21 932 if
(crtc->funcs->page_flip_target)
43968d7b Daniel Vetter 2016-09-21 @933 ret =
crtc->funcs->page_flip_target(crtc, fb, e,
43968d7b Daniel Vetter 2016-09-21 934
page_flip->flags,
43968d7b Daniel Vetter 2016-09-21 935
target_vblank);
43968d7b Daniel Vetter 2016-09-21 936 else
:: The code at line 933 was first introduced by commit
:: 43968d7b806d7a7e021261294c583a216fddf0e5 drm: Extract drm_plane.[hc]
:: TO: Daniel Vetter
:: CC: Sean Paul
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #2 from Christian Lanig --- Created attachment 130553 --> https://bugs.freedesktop.org/attachment.cgi?id=130553&action=edit Bios values I verified my bios against another one from the Internet and had a look at the powerplay tables but I can quite likely eliminate a broken bios as a cause. -- 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 1/6] virtio: wrap find_vqs
We are going to add more parameters to find_vqs, let's wrap the call so
we don't need to tweak all drivers every time.
Signed-off-by: Michael S. Tsirkin
---
drivers/block/virtio_blk.c | 3 +--
drivers/char/virtio_console.c | 6 +++---
drivers/crypto/virtio/virtio_crypto_core.c | 3 +--
drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +--
drivers/net/caif/caif_virtio.c | 3 +--
drivers/net/virtio_net.c | 3 +--
drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
drivers/scsi/virtio_scsi.c | 3 +--
drivers/virtio/virtio_balloon.c| 3 +--
drivers/virtio/virtio_input.c | 3 +--
include/linux/virtio_config.h | 9 +
net/vmw_vsock/virtio_transport.c | 6 +++---
12 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 1d4c9f8..c08c30c 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -455,8 +455,7 @@ static int init_vq(struct virtio_blk *vblk)
}
/* Discover virtqueues and write information to configuration. */
- err = vdev->config->find_vqs(vdev, num_vqs, vqs, callbacks, names,
- &desc);
+ err = virtio_find_vqs(vdev, num_vqs, vqs, callbacks, names, &desc);
if (err)
goto out;
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index e9b7e0b..5da4c8e 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1945,9 +1945,9 @@ static int init_vqs(struct ports_device *portdev)
}
}
/* Find the queues. */
- err = portdev->vdev->config->find_vqs(portdev->vdev, nr_queues, vqs,
- io_callbacks,
- (const char **)io_names, NULL);
+ err = virtio_find_vqs(portdev->vdev, nr_queues, vqs,
+ io_callbacks,
+ (const char **)io_names, NULL);
if (err)
goto free;
diff --git a/drivers/crypto/virtio/virtio_crypto_core.c
b/drivers/crypto/virtio/virtio_crypto_core.c
index 21472e4..a111cd72 100644
--- a/drivers/crypto/virtio/virtio_crypto_core.c
+++ b/drivers/crypto/virtio/virtio_crypto_core.c
@@ -119,8 +119,7 @@ static int virtcrypto_find_vqs(struct virtio_crypto *vi)
names[i] = vi->data_vq[i].name;
}
- ret = vi->vdev->config->find_vqs(vi->vdev, total_vqs, vqs, callbacks,
-names, NULL);
+ ret = virtio_find_vqs(vi->vdev, total_vqs, vqs, callbacks, names, NULL);
if (ret)
goto err_find;
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 4918668..1e1c90b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -175,8 +175,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned
long flags)
DRM_INFO("virgl 3d acceleration not supported by guest\n");
#endif
- ret = vgdev->vdev->config->find_vqs(vgdev->vdev, 2, vqs,
- callbacks, names, NULL);
+ ret = virtio_find_vqs(vgdev->vdev, 2, vqs, callbacks, names, NULL);
if (ret) {
DRM_ERROR("failed to find virt queues\n");
goto err_vqs;
diff --git a/drivers/net/caif/caif_virtio.c b/drivers/net/caif/caif_virtio.c
index bc0eb47..6122768 100644
--- a/drivers/net/caif/caif_virtio.c
+++ b/drivers/net/caif/caif_virtio.c
@@ -679,8 +679,7 @@ static int cfv_probe(struct virtio_device *vdev)
goto err;
/* Get the TX virtio ring. This is a "guest side vring". */
- err = vdev->config->find_vqs(vdev, 1, &cfv->vq_tx, &vq_cbs, &names,
- NULL);
+ err = virtio_find_vqs(vdev, 1, &cfv->vq_tx, &vq_cbs, &names, NULL);
if (err)
goto err;
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index ea9890d..6802169 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2079,8 +2079,7 @@ static int virtnet_find_vqs(struct virtnet_info *vi)
names[txq2vq(i)] = vi->sq[i].name;
}
- ret = vi->vdev->config->find_vqs(vi->vdev, total_vqs, vqs, callbacks,
-names, NULL);
+ ret = virtio_find_vqs(vi->vdev, total_vqs, vqs, callbacks, names, NULL);
if (ret)
goto err_find;
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 5e66e08..f7cade0 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -869,7 +869,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
init_waitqueue_head(&vrp->sendq);
/* We expect two virtqueues, rx and tx (and in this order) */
- err = vdev->config->find_vqs(
Re: [PATCH 10/11] drm/vmwgfx: Switch over to internal atomic API for STDU
Hi Daniel,
On Tue, Mar 28, 2017 at 09:49:38AM +0200, Daniel Vetter wrote:
> On Mon, Mar 27, 2017 at 03:01:03PM -0700, Sinclair Yeh wrote:
> > Switch over to using internal atomic API for mode set.
> >
> > This removes the legacy set_config API, replacing it with
> > drm_atomic_helper_set_config(). The DRM helper will use various
> > vmwgfx-specific atomic functions to set a mode.
> >
> > DRIVER_ATOMIC capability flag is not yet set, so the user mode
> > will still use the legacy mode set IOCTL.
> >
> > v2:
> > * Avoid a clash between page-flip pinning and setcrtc pinning, modify
> > the page-flip code to use the page-flip helper and the atomic callbacks.
> > To enable this, we will need to add a wrapper around atomic_commit.
> >
> > * Add vmw_kms_set_config() to work around vmwgfx xorg driver bug
> >
> > Signed-off-by: Sinclair Yeh
> > Signed-off-by: Thomas Hellstrom
> > Reviewed-by: Thomas Hellstrom
> > ---
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 20 +++
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 1 +
> > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 325
> > ---
> > 3 files changed, 51 insertions(+), 295 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > index 6b593aaf..7104796 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > @@ -2923,3 +2923,23 @@ vmw_kms_create_implicit_placement_property(struct
> > vmw_private *dev_priv,
> > "implicit_placement", 0, 1);
> >
> > }
> > +
> > +
> > +/**
> > + * vmw_kms_set_config - Wrapper around drm_atomic_helper_set_config
> > + *
> > + * @set: The configuration to set.
> > + *
> > + * The vmwgfx Xorg driver doesn't assign the mode::type member, which
> > + * when drm_mode_set_crtcinfo is called as part of the configuration
> > setting
> > + * causes it to return incorrect crtc dimensions causing severe problems in
> > + * the vmwgfx modesetting. So explicitly clear that member before calling
> > + * into drm_atomic_helper_set_config.
> > + */
> > +int vmw_kms_set_config(struct drm_mode_set *set)
> > +{
> > + if (set && set->mode)
> > + set->mode->type = 0;
>
> ugh :( Looking at set_crtcinfo the only thing I can see it look at ->type
> is to check for built-in modes. Not a single driver is using that afaics,
> we might as well remove this and and void the vmw special case here too.
Do you mean remove drm_display_mode->type field altogether or just
the check in drm_mode_set_crtcinfo?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings
On Fri, Mar 24, 2017 at 08:51:31AM +0800, Chris Zhong wrote: > The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and > connected to DSI using four lanes. > > Signed-off-by: Chris Zhong > Reviewed-by: Brian Norris > --- > > Changes in v4: None > Changes in v3: None > Changes in v2: None > > .../bindings/display/panel/innolux,p079zca.txt | 23 > ++ > 1 file changed, 23 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 06/30] drm/omap: Add support for render nodes
Hi David, On Wednesday 29 Mar 2017 14:51:48 David Herrmann wrote: > On Wed, Mar 29, 2017 at 2:20 PM, Laurent Pinchart wrote: > > On Wednesday 29 Mar 2017 11:58:23 Tomi Valkeinen wrote: > >> On 29/03/17 11:22, Laurent Pinchart wrote: > >>> On Tuesday 28 Mar 2017 16:07:52 Tomi Valkeinen wrote: > From: Hemant Hariyani > > Add support for render nodes in omap driver and allow required > ioctls to be accessible via render nodes. > >>> > >>> But the OMAP DSS doesn't perform rendering... This seems an abuse of > >>> render nodes, I think the API should instead be implemented by the GPU > >>> driver. > >> > >> I agree that the GPU use case described in the patch sounds a bit odd. > >> Why not allocate from the GPU driver instead. But here a particular > >> issue is that to get TILER buffers we need to ask them from the omapdrm. > >> Probably TILER should not be part of omapdrm, but then, where should it > >> be... > >> > >> We also have writeback in DSS, which can function as a memory to memory > >> or capture device. That's not supported in the mainline, but we have > >> support in the TI kernel. > >> > >> And how about a case where you have the privileged process as KMS > >> master, and another process wants to draw to a buffer with the CPU, and > >> then give the buffer to the privileged process for displaying. > >> > >> So, yes, DSS is not a renderer (well, WB is kind of rendering), but > >> isn't it a valid use case to allocate a buffer from omapdrm? > > > > It could be a valid use case, but it's still an API abuse. It starts > > sounding like a DRM core issue to me. The DRIVER_RENDER flag is not > > documented, so its exact meaning isn't defined. I thought it was supposed > > to flag the device as a renderer (GPU). > > > > commit 1793126fcebd7c18834f95d43b55e387a8803aa8 > > Author: David Herrmann > > Date: Sun Aug 25 18:29:00 2013 +0200 > > > > drm: implement experimental render nodes > > > > Render nodes provide an API for userspace to use non-privileged GPU > > commands without any running DRM-Master. It is useful for offscreen > > rendering, GPGPU clients, and normal render clients which do not > > perform > > modesetting. > > > > [...] > > > > You instead use the flag as a way to enable unprivileged clients to > > allocate buffers. If that's what the flag should mean, I wonder if there > > would be a use case for *not* setting it. > > Correct. You can (and should) enable all your sandboxed commands on > render nodes. That is, if a command only affects the issuing client, > then it is safe for render-nodes. If two clients have a file-context > opened on the render node, they should be unable to affect each other > (minus accounting, resource allocation, etc.). > > The name is historic (I did not come up with it either, but failed at > renaming it..). The DRIVER_RENDER flag only controls whether the > render-node is actually instantiated. I will not object doing that > unconditionally. It will create some useless nodes for legacy drivers, > but we should not care. Couldn't we achieve the same effect without render nodes, by allowing GEM object allocation on the main DRM node by unauthenticated clients ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)
On Wed, Mar 29, 2017 at 2:07 AM, Michel Dänzer wrote:
> On 29/03/17 01:02 PM, r...@ubuntu.com wrote:
>> From: Christopher James Halse Rogers
>>
>> Any use of the framebuffer will migrate it to VRAM, which is not sensible for
>> an imported dma-buf.
>>
>> v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg.
>>
>> Signed-off-by: Christopher James Halse Rogers
>>
>> CC: amd-...@lists.freedesktop.org
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>> index 39fc388f222a..2f2e9b5c8a6a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>> @@ -612,6 +612,12 @@ amdgpu_user_framebuffer_create(struct drm_device *dev,
>> return ERR_PTR(-ENOENT);
>> }
>>
>> + /* Handle is imported dma-buf, so cannot be migrated to VRAM for
>> scanout */
>> + if (obj->import_attach) {
>> + DRM_DEBUG_KMS("Cannot create framebuffer from imported
>> dma_buf\n");
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
>> if (amdgpu_fb == NULL) {
>> drm_gem_object_unreference_unlocked(obj);
>>
>
> This patch and v2 of patch 5 are
>
> Reviewed-by: Michel Dänzer
Applied these two. Thanks!
Alex
>
>
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100395] DC, Powerplay, Tonga, top screen flicker with current amd-staging-4.9
https://bugs.freedesktop.org/show_bug.cgi?id=100395 --- Comment #5 from Andy Furniss --- Seems, I've found it. Many skips to work around vega build issues, but I got past them and got a bad then good. Further skips then due to startx hangs with dmesg logging ring test fails on 3 to 8. Fortunately it then worked and only gave two choices one vega and - possible first bad commit: [91561a39fa74e79b88e0e9d70f3072501c8df2ce] drm/amdgpu: get display info from DC when DC enabled. This cleanly reverts from head - and the issue is gone with it reverted. # skip: [4513c8c07e243b77a36192a3c49845f85a656cea] drm/amd/display: Remove DCE12 guards git bisect skip 4513c8c07e243b77a36192a3c49845f85a656cea # bad: [76cfd18b173dd61d24de2c28fa92443fcfe165d8] drm/amdgpu: gart fixes for vega10 git bisect bad 76cfd18b173dd61d24de2c28fa92443fcfe165d8 # good: [6c59cf82dac54970284b3126ff9a15b6b0de6108] drm/amdgpu: add vega10 chip name git bisect good 6c59cf82dac54970284b3126ff9a15b6b0de6108 # skip: [9a493aa52c3a5176acd7b8ec32b66dc58bded8b2] drm/amdgpu: use atomfirmware interfaces for scratch reg save/restore git bisect skip 9a493aa52c3a5176acd7b8ec32b66dc58bded8b2 # skip: [d0a2e62fca3e502951bd1eb392e5331ad80dc88c] drm/amdgpu: add IV trace point git bisect skip d0a2e62fca3e502951bd1eb392e5331ad80dc88c # skip: [40610a13a747afacb17fa2b9decfa8e5455671b4] drm/amdgpu: add 64bit doorbell assignments git bisect skip 40610a13a747afacb17fa2b9decfa8e5455671b4 # good: [d9693ee35fd55106b70bbd1dae9ce71b578ab3e9] drm/amdgpu: add psp firmware header info git bisect good d9693ee35fd55106b70bbd1dae9ce71b578ab3e9 # only skipped commits left to test # possible first bad commit: [76cfd18b173dd61d24de2c28fa92443fcfe165d8] drm/amdgpu: gart fixes for vega10 # possible first bad commit: [91561a39fa74e79b88e0e9d70f3072501c8df2ce] drm/amdgpu: get display info from DC when DC enabled. -- 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: drivers/gpu/drm/radeon/r100.c:3303]: (style) Redundant condition
On Mon, Mar 27, 2017 at 6:07 AM, David Binderman wrote:
>
> Hello there,
>
> linux-4.11-rc4/drivers/gpu/drm/radeon/r100.c:3303]: (style) Redundant
> condition: If 'EXPR == 11', the comparison 'EXPR <= 12' is always true.
>
> Source code is
>
> } else if (rdev->family == CHIP_RV350 ||
>rdev->family <= CHIP_RV380) {
>
Fixed in the attached patch.
> Also in the same file:
>
> [drivers/gpu/drm/radeon/r100.c:2550]: (style) Variable 'tmp' is assigned a
> value
> that is never used.
> [drivers/gpu/drm/radeon/r100.c:2875]: (style) Variable 'tmp' is assigned a
> value
> that is never used.
These are intended. The registers are read back to to post the previous write.
Alex
From bc02be56efa4c147622c69cfc2772b9a116ab5f9 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 29 Mar 2017 18:03:27 -0400
Subject: [PATCH] drm/radeon: fix typo in bandwidth calculation
The RV3xx settings were getting applied to all older asics
rather than just RV3xx.
Reported-by: David Binderman
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index e339931..8344945 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3301,7 +3301,7 @@ void r100_bandwidth_update(struct radeon_device *rdev)
mem_trp = ((temp >> 8) & 0x7) + 1;
mem_tras = ((temp >> 11) & 0xf) + 4;
} else if (rdev->family == CHIP_RV350 ||
- rdev->family <= CHIP_RV380) {
+ rdev->family == CHIP_RV380) {
/* rv3x0 */
mem_trcd = (temp & 0x7) + 3;
mem_trp = ((temp >> 8) & 0x7) + 3;
--
2.5.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/i915: Add format modifiers for Intel
On 17-03-29 23:17:13, Ville Syrjälä wrote:
On Fri, Mar 24, 2017 at 02:29:50PM -0700, Ben Widawsky wrote:
This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.
v2:
- Add LINEAR and Yf modifiers to list (Ville)
- Combine i8xx and i965 into one list of formats (Ville)
- Allow 1010102 formats for Y/Yf tiled (Ville)
v3:
- Handle cursor formats (Ville)
- Put handling for LINEAR in the mod_support functions (Ville)
Cc: Ville Syrjälä
Cc: Kristian H. Kristensen
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_display.c | 112 +--
drivers/gpu/drm/i915/intel_sprite.c | 25 +++-
2 files changed, 131 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 802a8449c5d3..bb559a116fda 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
};
+static const uint64_t i9xx_format_modifiers[] = {
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -87,6 +93,14 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
};
+static const uint64_t skl_format_modifiers[] = {
+ I915_FORMAT_MOD_Yf_TILED,
+ I915_FORMAT_MOD_Y_TILED,
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
/* Cursor formats */
static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13453,6 +13467,83 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
}
+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+ switch (format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_XRGB1555:
+ case DRM_FORMAT_XRGB:
+ return modifier == DRM_FORMAT_MOD_LINEAR ||
+ modifier == I915_FORMAT_MOD_X_TILED;
+ default:
+ return false;
+ }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+ switch (format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_XRGB2101010:
+ case DRM_FORMAT_XBGR2101010:
+ return modifier == DRM_FORMAT_MOD_LINEAR ||
+ modifier == I915_FORMAT_MOD_X_TILED;
+ default:
+ return false;
+ }
+}
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+ switch (format) {
+ case DRM_FORMAT_C8:
+ return modifier == DRM_FORMAT_MOD_LINEAR ||
+ (modifier >= I915_FORMAT_MOD_X_TILED &&
+modifier < I915_FORMAT_MOD_Yf_TILED);
The >= stuff makes this harder to parse than it should be IMO.
I'd just list each modifier explicitly.
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_ABGR:
+ case DRM_FORMAT_XRGB2101010:
+ case DRM_FORMAT_XBGR2101010:
+ return modifier == DRM_FORMAT_MOD_LINEAR ||
+ (modifier >= I915_FORMAT_MOD_X_TILED &&
+ modifier <= I915_FORMAT_MOD_Yf_TILED);
ditto. At first I couldn't even spot the difference between this and
the C8 case.
Okay, got those both. I think for now it's just:
switch (format) {
case DRM_FORMAT_C8:
switch (modifier) {
case DRM_FORMAT_MOD_LINEAR:
case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
return true;
default:
return false;
}
case DRM_FORMAT_RGB565:
case DRM_FORMAT_XRGB:
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
case DRM_FORMAT_XRGB2101010:
case DRM_FORMAT_XBGR2101010:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
/* All i915 modifiers are fine */
switch (modifier) {
case DRM_FORMAT_MOD_LINEAR:
case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return true;
default:
return false;
}
default:
return false;
}
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_YVYU:
+ case DRM_FORMAT_UYVY:
+ case DRM_FORMAT_VYUY:
+
[Bug 100398] [agd5f] New errors when tonga card powers up
https://bugs.freedesktop.org/show_bug.cgi?id=100398 --- Comment #3 from Alex Deucher --- Can you try the latest drm-next-4.12-wip branch? -- 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 1/2] tests/tegra: add openclose test to check-target
This makes the test run under the 'make check'-taget. Signed-off-by: Erik Faye-Lund --- tests/tegra/Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am index 8e625c8f..f8e2a146 100644 --- a/tests/tegra/Makefile.am +++ b/tests/tegra/Makefile.am @@ -9,5 +9,7 @@ LDADD = \ ../../tegra/libdrm_tegra.la \ ../../libdrm.la -noinst_PROGRAMS = \ +TESTS = \ openclose + +check_PROGRAMS = $(TESTS) -- 2.12.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/2] tegra: update symbol-check
I get a few more symbols in my build tegra-libraries, so let's
include these in the whitelist as well.
While we're at it, update the comment at the top.
Signed-off-by: Erik Faye-Lund
---
tegra/tegra-symbol-check | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tegra/tegra-symbol-check b/tegra/tegra-symbol-check
index 40208311..420469f4 100755
--- a/tegra/tegra-symbol-check
+++ b/tegra/tegra-symbol-check
@@ -1,11 +1,14 @@
#!/bin/bash
-# The following symbols (past the first five) are taken from the public
headers.
-# A list of the latter should be available
Makefile.sources/LIBDRM_FREEDRENO_H_FILES
+# The following symbols (past the first nine) are taken from tegra.h.
FUNCS=$(nm -D --format=bsd --defined-only ${1-.libs/libdrm_tegra.so} | awk
'{print $3}'| while read func; do
( grep -q "^$func$" || echo $func )
[Bug 100398] [agd5f] New errors when tonga card powers up
https://bugs.freedesktop.org/show_bug.cgi?id=100398 --- Comment #4 from Mike Lothian --- I still get errors but they're slightly different this time: [9.641782] [drm] PCIE GART of 4096M enabled (table at 0x0004). [9.691719] [drm] ring test on 0 succeeded in 11 usecs [9.693744] [drm] ring test on 9 succeeded in 3 usecs [9.695366] [drm] ring test on 1 succeeded in 44 usecs [9.697032] [drm] ring test on 2 succeeded in 30 usecs [9.698691] [drm] ring test on 3 succeeded in 37 usecs [9.700281] [drm] ring test on 4 succeeded in 45 usecs [9.701869] [drm] ring test on 5 succeeded in 23 usecs [9.703452] [drm] ring test on 6 succeeded in 51 usecs [9.704944] [drm] ring test on 7 succeeded in 29 usecs [9.706528] [drm] ring test on 8 succeeded in 31 usecs [9.707917] [drm] ring test on 10 succeeded in 5 usecs [9.709369] [drm] ring test on 11 succeeded in 6 usecs [9.759220] [drm] ring test on 12 succeeded in 1 usecs [9.760550] [drm] UVD initialized successfully. [9.974226] [drm] ring test on 13 succeeded in 0 usecs [9.975629] [drm] ring test on 14 succeeded in 2 usecs [9.977047] [drm] ring test on 15 succeeded in 3 usecs [9.978340] [drm] VCE initialized successfully. [ 15.836977] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 16.291409] amdgpu :01:00.0: GPU pci config reset [ 21.034387] wlan0: authenticate with 78:3e:53:c0:2e:03 [ 21.077809] wlan0: send auth to 78:3e:53:c0:2e:03 (try 1/3) [ 21.078758] wlan0: authenticated [ 21.080481] wlan0: associate with 78:3e:53:c0:2e:03 (try 1/3) [ 21.083555] wlan0: RX AssocResp from 78:3e:53:c0:2e:03 (capab=0x11 status=0 aid=3) [ 21.086443] wlan0: associated [ 21.086455] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 21.088115] ath: EEPROM regdomain: 0x833a [ 21.088116] ath: EEPROM indicates we should expect a country code [ 21.088118] ath: doing EEPROM country->regdmn map search [ 21.088119] ath: country maps to regdmn code: 0x37 [ 21.088120] ath: Country alpha2 being used: GB [ 21.088121] ath: Regpair used: 0x37 [ 21.088122] ath: regdomain 0x833a dynamically updated by country IE [ 21.241486] wlan0: Limiting TX power to 23 (23 - 0) dBm as advertised by 78:3e:53:c0:2e:03 [ 40.917223] [drm] PCIE GART of 4096M enabled (table at 0x0004). [ 40.966588] [drm] ring test on 0 succeeded in 11 usecs [ 40.966966] [drm] ring test on 9 succeeded in 1 usecs [ 41.181390] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 1 test failed (scratch(0xC040)=0xCAFEDEAD) [ 41.340367] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 2 test failed (scratch(0xC040)=0xCAFEDEAD) [ 41.499547] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 3 test failed (scratch(0xC040)=0xCAFEDEAD) [ 41.657396] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 4 test failed (scratch(0xC040)=0xCAFEDEAD) [ 41.816496] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 5 test failed (scratch(0xC040)=0xCAFEDEAD) [ 41.976375] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 6 test failed (scratch(0xC040)=0xCAFEDEAD) [ 42.139328] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 7 test failed (scratch(0xC040)=0xCAFEDEAD) [ 42.296842] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 8 test failed (scratch(0xC040)=0xCAFEDEAD) [ 42.296845] [drm:amdgpu_resume] *ERROR* resume of IP block failed -22 [ 42.296847] [drm:amdgpu_device_resume] *ERROR* amdgpu_resume failed (-22). [ 42.304956] [drm:amdgpu_fill_buffer] *ERROR* Trying to clear memory with ring turned off. [ 42.304974] [drm:amdgpu_fill_buffer] *ERROR* Trying to clear memory with ring turned off. -- 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 100460] AMDGPU system hang with Slic3r Prusa Edition
https://bugs.freedesktop.org/show_bug.cgi?id=100460 Bug ID: 100460 Summary: AMDGPU system hang with Slic3r Prusa Edition Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: g...@chown.ath.cx The 3D printing software Slic3r Prusa Edition uses OpenGL to render 3D views of objects and a preview of the tool path. The tool path preview causes system hangs for me with AMDGPU and RadeonSI, with the latest mainline code of all components involved (Linux 4.11rc4, Mesa git, LLVM svn). It seems to be memory management related. It looks like there may be a deadlock of some sort. Here's how to reproduce. I wasn't able to record a working trace. 1. Download Slic3r Prusa Edition 1.33.8 from https://github.com/prusa3d/Slic3r/releases/tag/version_1.33.8 (AppImage is the easy choice) 2. Get the model "LASER CAT - Voronoi Style" from http://www.thingiverse.com/thing:179266/#files (e.g. Laser_Cat_-_Voronoi_coarse.stl) 3. Start Slic3r, abort setup wizard. Default settings are fine. 4. Press "Add..." and select the .stl file 5. Press "Slice now" in the right panel 6. Select "Preview" in the bottom tab list This results in a hanging system. The kernel's hang detection is triggered after a while: 66929.634087] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [perl5.22.0:21405] [66929.634087] Modules linked in: ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c ccm nvram f71882fg arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib mac80211 cfg80211 input_leds joydev pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc nls_iso8859_1 edac_mce_amd edac_core kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_seq_midi pcbc snd_seq_midi_event snd_rawmidi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_seq snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep aesni_intel aes_x86_64 crypto_simd glue_helper cryptd snd_pcm fam15h_power k10temp snd_seq_device i2c_piix4 snd_timer snd soundcore shpchp tpm_infineon mac_hid cpuid msr parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq hid_generic usbhid hid uas usb_storage amdkfd [66929.634087] amd_iommu_v2 amdgpu i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci r8169 libahci mii wmi fjes video [66929.634087] CPU: 1 PID: 21405 Comm: perl5.22.0 Tainted: G OE 4.11.0-041100rc1-generic #201703051731 [66929.634087] Hardware name: MSI MS-7721/A68HM-P33 (MS-7721), BIOS V34.4 12/15/2014 [66929.634087] task: a0f8eb574380 task.stack: b6f146c1c000 [66929.634087] RIP: 0010:_raw_spin_unlock_irqrestore+0x15/0x20 [66929.634087] RSP: 0018:b6f146c1f780 EFLAGS: 0282 ORIG_RAX: ff10 [66929.634087] RAX: 0002 RBX: RCX: [66929.634087] RDX: RSI: 0282 RDI: 0282 [66929.634087] RBP: b6f146c1f780 R08: R09: a0f8cd1bd380 [66929.634087] R10: b6f14571e628 R11: 0001ef18 R12: 0001 [66929.634087] R13: a0f8cd1bd380 R14: a0f8eb512940 R15: 0001 [66929.634087] FS: 7f6b3c771700() GS:a0f8fec8() knlGS: [66929.634087] CS: 0010 DS: ES: CR0: 80050033 [66929.634087] CR2: 7f69a3195000 CR3: 0003d9548000 CR4: 000406e0 [66929.634087] Call Trace: [66929.634087] alloc_iova+0x21c/0x240 [66929.634087] alloc_iova_fast+0xa6/0x200 [66929.634087] dma_ops_alloc_iova.isra.23+0x6b/0x80 [66929.634087] __map_single.isra.24+0x49/0x1b0 [66929.634087] map_page+0x64/0x80 [66929.634087] amdgpu_ttm_tt_populate+0xe9/0x270 [amdgpu] [66929.634087] ttm_tt_bind+0x2b/0x60 [ttm] [66929.634087] ttm_bo_handle_move_mem+0x535/0x5b0 [ttm] [66929.634087] ? shmem_alloc_inode+0x1a/0x30 [66929.634087] ttm_bo_validate+0x13e/0x150 [ttm] [66929.634087] ttm_bo_init+0x243/0x430 [ttm] [66929.634087] amdgpu_bo_create_restricted+0x4ae/0x5b0 [amdgpu] [66929.634087] ? amdgpu_update_memory_usage+0xe0/0xe0 [amdgpu] [66929.634087] amdgpu_bo_create+0xed/0x1f0 [amdgpu] [66929.634087] amdgpu_gem_object_create+0xba/0x150 [amdgpu] [66929.634087] amdgpu_gem_create_ioctl+0xa4/0x130 [amdgpu] [66929.634087] drm_ioctl+0x209/0x4c0 [drm] [66929.634087] ? amdgpu_gem_object_close+0x130/0x130 [amdgpu] [66929.634087] ? __handle_mm_fault+0x953/0x10e0 [66929.634087] ? do_mmap+0x445/0x510 [66929.634087] ? common_mmap+0x45/0x50 [66929.634087] amdgpu_drm_ioctl+0x4f/0x90 [amdgpu] [66929.634087] do_vfs_ioctl+0xa3/0x600 [66929.634087] ? handle_mm_fault+0xd0/0x240 [66929.634087] ? __check_object_size+0x100/0x19d [66929.634087] SyS_ioctl+0x79/0x90 [66929.634087] entry_SYSCALL_64_fastpath+0x1e/0xad [66929.634087] RIP: 0033:0x7f6b3b31e357 [66929.63
Re: [pull] radeon drm-fixes-4.11
This is a request for Dave to pull changes from Alex's tree into Dave's "drm-fixes" tree, which is the last step before it gets sent to Linus. Dave is the drm subsystem maintainer, and drm-next / drm-fixes branches are where code from multiple GPU driver maintainers comes together. Dave would get similar requests from Intel, Nouveau developers etc... From: amd-gfx on behalf of Panariti, David Sent: March 29, 2017 1:53 PM To: Alex Deucher; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; airl...@gmail.com Cc: Deucher, Alexander Subject: RE: [pull] radeon drm-fixes-4.11 Hi, I'm still new to this stuff. Is this informational or some action items? thanks, davep > -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Alex Deucher > Sent: Wednesday, March 29, 2017 12:55 PM > To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > airl...@gmail.com > Cc: Deucher, Alexander > Subject: [pull] radeon drm-fixes-4.11 > > Hi Dave, > > One small fix for radeon. > > The following changes since commit > d64a04720b0e64c1cd0726a3a27b360822fbee22: > > Merge branch 'drm-fixes-4.11' of git://people.freedesktop.org/~agd5f/linux > into drm-fixes (2017-03-24 11:05:06 +1000) > > are available in the git repository at: > > git://people.freedesktop.org/~agd5f/linux drm-fixes-4.11 > > for you to fetch changes up to > ce4b4f228e51219b0b79588caf73225b08b5b779: > > drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags > (2017-03-27 16:17:30 -0400) > > > Michel Dänzer (1): > drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags > > drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/11] ARM: dts: sun8i: add DE2 nodes for V3s SoC
From: Icenowy Zheng
Allwinner V3s SoC features a "Display Engine 2.0" with only one TCON
which have RGB LCD output.
Add device nodes for it as well as the TCON.
Signed-off-by: Icenowy Zheng
---
Changes in v3:
- Change the size of de2_clocks regs according to the binding example.
arch/arm/boot/dts/sun8i-v3s.dtsi | 87
1 file changed, 87 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 71075969e5e6..ae23746731a8 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -41,6 +41,10 @@
*/
#include
+#include
+#include
+#include
+#include
/ {
#address-cells = <1>;
@@ -59,6 +63,12 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-v3s-display-engine";
+ allwinner,pipelines = <&de2_mixer0>;
+ status = "disabled";
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -93,6 +103,83 @@
#size-cells = <1>;
ranges;
+ de2_clocks: clock@0100 {
+ compatible = "allwinner,sun50i-h5-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ de2_mixer0: mixer@0110 {
+ compatible = "allwinner,sun8i-v3s-de2-mixer";
+ reg = <0x0110 0x10>;
+ clocks = <&de2_clocks CLK_MIXER0>,
+<&de2_clocks CLK_BUS_MIXER0>;
+ clock-names = "mod",
+ "bus";
+ resets = <&de2_clocks RST_MIXER0>;
+ assigned-clocks = <&de2_clocks CLK_MIXER0>;
+ assigned-clock-rates = <15000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer0_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ tcon0: lcd-controller@01c0c000 {
+ compatible = "allwinner,sun8i-v3s-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON0>,
+<&ccu CLK_TCON0>;
+ clock-names = "ahb",
+ "tcon-ch0";
+ clock-output-names = "tcon-pixel-clock";
+ resets = <&ccu RST_BUS_TCON0>;
+ reset-names = "lcd";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_mixer0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drivers/gpu/drm/radeon/r100.c:3303]: (style) Redundant condition
Hello there,
linux-4.11-rc4/drivers/gpu/drm/radeon/r100.c:3303]: (style) Redundant
condition: If 'EXPR == 11', the comparison 'EXPR <= 12' is always true.
Source code is
} else if (rdev->family == CHIP_RV350 ||
rdev->family <= CHIP_RV380) {
Also in the same file:
[drivers/gpu/drm/radeon/r100.c:2550]: (style) Variable 'tmp' is assigned a value
that is never used.
[drivers/gpu/drm/radeon/r100.c:2875]: (style) Variable 'tmp' is assigned a value
that is never used.
Regards
David Binderman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: fix build error without CONFIG_BACKLIGHT_CLASS_DEVICE
With CONFIG_ACPI=n and CONFIG_BACKLIGHT_CLASS_DEVICE=n we see the following link error in the i915 driver: drivers/built-in.o: In function 'intel_backlight_device_register': (.text+0x2a921d): undefined reference to 'backlight_device_register' Fix this by removing the condition on ACPI from the appropriate select statement. Signed-off-by: Tobias Regnery --- drivers/gpu/drm/i915/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index a5cd5dacf055..532df4bb9283 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -15,7 +15,7 @@ config DRM_I915 # i915 depends on ACPI_VIDEO when ACPI is enabled # but for select to work, need to select ACPI_VIDEO's dependencies, ick select BACKLIGHT_LCD_SUPPORT if ACPI - select BACKLIGHT_CLASS_DEVICE if ACPI + select BACKLIGHT_CLASS_DEVICE select INPUT if ACPI select ACPI_VIDEO if ACPI select ACPI_BUTTON if ACPI -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/11] dt-bindings: add binding for the Allwinner DE2 CCU
From: Icenowy Zheng
Allwinner "Display Engine 2.0" contains some clock controls in it.
In order to add them as clock drivers, we need a device tree binding.
Add the binding here.
Signed-off-by: Icenowy Zheng
---
Changes in v3:
- Fill the address space length of DE2 CCU to 0x10, just reach the start of
mixer0.
.../devicetree/bindings/clock/sun8i-de2.txt| 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt
b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
new file mode 100644
index ..34cf79c05f13
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
@@ -0,0 +1,31 @@
+Allwinner Display Engine 2.0 Clock Control Binding
+--
+
+Required properties :
+- compatible: must contain one of the following compatibles:
+ - "allwinner,sun8i-a83t-de2-clk"
+ - "allwinner,sun50i-a64-de2-clk"
+ - "allwinner,sun50i-h5-de2-clk"
+
+- reg: Must contain the registers base address and length
+- clocks: phandle to the clocks feeding the display engine subsystem.
+ Three are needed:
+ - "mod": the display engine module clock
+ - "bus": the bus clock for the whole display engine subsystem
+- clock-names: Must contain the clock names described just above
+- resets: phandle to the reset control for the display engine subsystem.
+- #clock-cells : must contain 1
+- #reset-cells : must contain 1
+
+Example:
+de2_clocks: clock@0100 {
+ compatible = "allwinner,sun50i-a64-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+};
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/11] drm/sun4i: add support for Allwinner DE2 mixers
Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
with mixers to do graphic processing and feed data to TCON, like the old
backends and frontends.
Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
Currently a lot of functions are still missing -- more investigations
are needed to gain enough information for them.
Signed-off-by: Icenowy Zheng
---
Refactored patch in v3.
drivers/gpu/drm/sun4i/Kconfig | 10 +
drivers/gpu/drm/sun4i/Makefile | 4 +
drivers/gpu/drm/sun4i/sun8i_layer.c | 156 +++
drivers/gpu/drm/sun4i/sun8i_layer.h | 35
drivers/gpu/drm/sun4i/sun8i_mixer.c | 386
drivers/gpu/drm/sun4i/sun8i_mixer.h | 131
6 files changed, 722 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 5a8227f37cc4..15557484520d 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
original Allwinner Display Engine, which has a backend to
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+
+config DRM_SUN4I_SUN8I_MIXER
+ tristate "Support for Allwinner Display Engine 2.0 Mixer"
+ depends on DRM_SUN4I
+ default MACH_SUN8I
+ help
+ Choose this option if you have an Allwinner SoC with the
+ Allwinner Display Engine 2.0, which has a mixer to do some
+ graphics mixture and feed graphics to TCON, If M is
+ selected the module will be called sun8i-mixer.
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 1db1068b9be1..7625c2dad1bb 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,7 +9,11 @@ sun4i-tcon-y += sun4i_crtc.o
sun4i-backend-y += sun4i_layer.o
sun4i-backend-y += sun4i_backend.o
+sun8i-mixer-y += sun8i_layer.o
+sun8i-mixer-y += sun8i_mixer.o
+
obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
+obj-$(CONFIG_DRM_SUN4I_SUN8I_MIXER) += sun8i-mixer.o
obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
new file mode 100644
index ..5cc4a7f8a7ae
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) Icenowy Zheng
+ *
+ * Based on sun4i_layer.h, which is:
+ * Copyright (C) 2015 Free Electrons
+ * Copyright (C) 2015 NextThing Co
+ *
+ * Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "sun4i_crtc.h"
+#include "sun8i_layer.h"
+#include "sun8i_mixer.h"
+#include "sunxi_layer.h"
+
+struct sun8i_plane_desc {
+ enum drm_plane_type type;
+ const uint32_t *formats;
+ uint32_tnformats;
+};
+
+static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ return 0;
+}
+
+static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
+ struct drm_plane_state
*old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_layer_enable(mixer, layer->id, false);
+}
+
+static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
+ sun8i_mixer_layer_enable(mixer, layer->id, true);
+}
+
+static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
+ .atomic_check = sun8i_mixer_layer_atomic_check,
+ .atomic_disable = sun8i_mixer_layer_atomic_disable,
+ .atomic_update = sun8i_mixer_layer_atomic_update,
+};
+
+static const struct drm_plane_funcs sun8i_mixer_layer_funcs = {
+ .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+ .atomic_duplicate_state = drm_atomic
[PATCH RESEND] drm: use .hword to represent 16-bit numbers
The size of .word is the size of a word in the given platform, which for intel systems is 16-bits but other architectures use different sizes. However, .hword emits 16-bit numbers regardless of the platform (and despite the name). The quantities specified in EDID are platform independent, so they should work in spite of the default target of the cc you are using, so use .hword where EDID specifies 16-bit numbers. Cc: Carsten Emde Cc: David Airlie Signed-off-by: Javi Merino --- Documentation/EDID/edid.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/EDID/edid.S b/Documentation/EDID/edid.S index 7ac0327..ef082dc 100644 --- a/Documentation/EDID/edid.S +++ b/Documentation/EDID/edid.S @@ -59,9 +59,9 @@ /* Fixed header pattern */ header:.byte 0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00 -mfg_id:.word swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3)) +mfg_id:.hword swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3)) -prod_code: .word 0 +prod_code: .hword 0 /* Serial number. 32 bits, little endian. */ serial_number: .long SERIAL @@ -177,7 +177,7 @@ std_vres: .byte (XY_RATIO<<6)+VFREQ-60 descriptor1: /* Pixel clock in 10 kHz units. (0.-655.35 MHz, little-endian) */ -clock: .word CLOCK/10 +clock: .hword CLOCK/10 /* Horizontal active pixels 8 lsbits (0-4095) */ x_act_lsb: .byte XPIX&0xff -- 2.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ARM: dts: sun5i: Add interrupt for display backend
On Wed, Mar 29, 2017 at 3:13 PM, Maxime Ripard wrote: > On Mon, Mar 27, 2017 at 10:38:47PM +0800, Chen-Yu Tsai wrote: >> The display backend on sun5i shares the same interrupt line as the >> display frontend. Add it. >> >> Signed-off-by: Chen-Yu Tsai > > And ideally, patches prefix shouldn't have dts here too. I've dropped > it and applied, thanks! Seems like this was a recent policy change? Or almost everyone was getting it wrong in the past. >> This won't directly apply to old releases. We may want to backport >> them though? > > Yep, probably. Do you want to send it to stable? It won't apply, due to the recent sun5i merger. We could wait until it lands in Linus' tree, then send a backport patch to stable, to keep the noise to a minimum. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/10] Enable HDMI Stereoscopy
On Wed, Mar 29, 2017 at 8:02 AM, Ville Syrjälä < ville.syrj...@linux.intel.com> wrote: > > On Mon, Mar 27, 2017 at 05:57:57PM -0400, Alastair Bridgewater wrote: > > And the tenth patch enables stereo mode support... on HDMI and DPort > > connectors on nv50+ hardware. HDMI connectors because obvious. DPort > > connectors because of DPort to HDMI adaptors. > > Do you mean DP++ or actual protocol converters? DP++ is just HDMI with > a some electrical tweaks, but IIRC proper DP defines 3D stereo quite > differently than HDMI. I'm not sure if we should be able to push HDMI > style 3D through DP->HDMI/DP++ adaptors. The specs are unfortunately > very vague when it comes to such devices. DP++. Good point about the protocol converters, though I don't recall seeing any way to distinguish between a DP and a DP++ connector in nouveau, nor do I know if nVidia actually made any boards with DP that isn't DP++. I guess I have some digging to do in that direction. Thank you. > > eDP connectors because > > it shouldn't do any harm, and someone might have been maniac enough to > > set up an eDP port to point to something with an HDMI 3D setup. And > > nv50+ hardware only because while I'm not aware of any pre-nv50 cards > > that have HDMI outputs, there could be a setup out there like the PS3 > > that uses an external HDMI encoder on pre-nv50 hardware, at which > > point none of the mode timing or InfoFrame support is in place for it. -- Alastair Bridgewater ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
