[Bug 108015] Enabling pp_od_clk_voltage causes the gpu to be locked to lowest power level until some value is written to pp_od_clk_voltage and then the pp_od_clk_voltage is reset.
https://bugs.freedesktop.org/show_bug.cgi?id=108015 Bug ID: 108015 Summary: Enabling pp_od_clk_voltage causes the gpu to be locked to lowest power level until some value is written to pp_od_clk_voltage and then the pp_od_clk_voltage is reset. Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: igo95...@yandex.ru After enabling the overclocking by adding amdgpu.ppfeaturemask=0x kernel boot parameter I noticed that my GPU works very slow. I noticed by reading /sys/kernel/debug/dri/1/amdgpu_pm_info that the card fails to go to higher power states. Here are the screenshots and the way I found to temporarily fix it. I am using Witcher 3 on Steam Proton 3.7.6 as a performance measurement: https://i.imgur.com/HI6iakk.jpg 1). Initial state. The game is running around 15-20 frames. The pp_od_clk_voltage table seems correct but the power consumption stays around 15 Watts and the clock is stuck at 300 MHz https://i.imgur.com/LInHonF.jpg 2). Trying to reset it straight away is not helping. https://i.imgur.com/klkGSoA.jpg 3). Writing a value in to that is already on the table of pp_od_clk_voltage is also not helping. https://i.imgur.com/BH8ZwIr.jpg 4). Setting a value slightly different than will actually allow the GPU to change its power state to a higher level. However, it is still not fully powered as it would be without overclocking enabled. The frame rate is only 20-30 and the power is around 80 Watts. https://i.imgur.com/x1Mipja.jpg 5). Resetting the values now will fully enable the card. Frame rate goes to 100 frames per second and power consumption to 100 Watts. Here are more information that might be useful: GPU: Sapphire AMD RX480 Nitro Kernel: 4.18 ZEN Thank you for your work on the AMDGPU driver. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RFE: DRM_IOCTL_MODE_EXPOSE_LEASE
Goal: simplify multiseat support. A new parameter was added to the Xorg server to make it use a passed file descriptor instead of /dev/dri/card*. This enables one to start the Xorg server with leased FD. Although it is possible to organize multiseat using this approach, it does not integrate well with existing seat infrastructure (udev, logind). It would be great to have a way to expose a DRM Lessee as /dev/dri/card* node and relevant /sys nodes etc., which would enable one to write an udev rule to create a new seat. This new node should represent leased resources and *should support DRM_IOCTL_SET_MASTER/DRM_IOCTL_DROP_MASTER* as if it were a "real" device. Interface: DRM_IOCTL_MODE_EXPOSE_LEASE ioctl request to DRM Lessor with lease FD as the ioctl parameter. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #12 from michael.mans...@gmail.com --- This fixes the issue for me as well. Its great to finally have a work-around! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Suppress keypresses from ACPI_VIDEO events
Currently we return NOTIFY_DONE for any event which we don't think is
ours. However, many laptops will send more then just an ATIF event and
will also send an ACPI_VIDEO_NOTIFY_PROBE event as well. Since we don't
check for this, we return NOTIFY_DONE which causes a keypress for the
ACPI event to be propogated to userspace. This is the equivalent of
someone pressing the display key on a laptop every time there's a
hotplug event.
So, check for ACPI_VIDEO_NOTIFY_PROBE events and suppress keypresses
from them.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 353993218f21..f008804f0b97 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -358,7 +358,9 @@ static int amdgpu_atif_get_sbios_requests(struct
amdgpu_atif *atif,
*
* Checks the acpi event and if it matches an atif event,
* handles it.
- * Returns NOTIFY code
+ *
+ * Returns:
+ * NOTIFY_BAD or NOTIFY_DONE, depending on the event.
*/
static int amdgpu_atif_handler(struct amdgpu_device *adev,
struct acpi_bus_event *event)
@@ -372,11 +374,16 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
if (strcmp(event->device_class, ACPI_VIDEO_CLASS) != 0)
return NOTIFY_DONE;
+ /* Is this actually our event? */
if (!atif ||
!atif->notification_cfg.enabled ||
- event->type != atif->notification_cfg.command_code)
- /* Not our event */
- return NOTIFY_DONE;
+ event->type != atif->notification_cfg.command_code) {
+ /* These events will generate keypresses otherwise */
+ if (event->type == ACPI_VIDEO_NOTIFY_PROBE)
+ return NOTIFY_BAD;
+ else
+ return NOTIFY_DONE;
+ }
if (atif->functions.sbios_requests) {
struct atif_sbios_requests req;
@@ -385,7 +392,7 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
count = amdgpu_atif_get_sbios_requests(atif, );
if (count <= 0)
- return NOTIFY_DONE;
+ return NOTIFY_BAD;
DRM_DEBUG_DRIVER("ATIF: %d pending SBIOS requests\n", count);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201201] New: [amdgpu] Can't raise power limit on Vega
https://bugzilla.kernel.org/show_bug.cgi?id=201201 Bug ID: 201201 Summary: [amdgpu] Can't raise power limit on Vega Product: Drivers Version: 2.5 Kernel Version: 4.19-rc4 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: mezin.alexan...@gmail.com Regression: No On Windows I can increase the power limit to +50% (150%) in wattman. On Linux for some reason I can only set it lower than the stock value. Any attempts to write a value that's bigger than the stock one into power1_cap fail with "Invalid argument": # echo 32000 >power1_cap -bash: echo: write error: Invalid argument -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108014] AMD WX4150 - MST is entirely nonfunctional, spams dmesg with errors
https://bugs.freedesktop.org/show_bug.cgi?id=108014 Bug ID: 108014 Summary: AMD WX4150 - MST is entirely nonfunctional, spams dmesg with errors Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ly...@redhat.com On the HP Zbook I've got here with an AMD WX4150 GPU, DP MST is entirely nonfunctional. The only part of MST that works is the first modeset. Every single modeset afterwards fails while spamming this in dmesg: [ 77.797646] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:927 [ 77.797698] WARNING: CPU: 7 PID: 55 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] [ 77.797698] Modules linked in: fuse vfat fat arc4 rtsx_pci_sdmmc mmc_core mei_wdt rtsx_pci_ms intel_rapl memstick iTCO_wdt iTCO_vendor_support hp_wmi intel_wmi_thunderbolt wmi_bmof sparse_keymap x86_pkg_temp_thermal intel_powerclamp coretemp iwlmvm kvm mac80211 snd_hda_codec_conexant snd_hda_codec_generic snd_hda_codec_hdmi irqbypass crct10dif_pclmul crc32_pclmul snd_hda_intel snd_usb_audio snd_hda_codec ghash_clmulni_intel intel_cstate btusb snd_hda_core btrtl snd_usbmidi_lib iwlwifi intel_uncore snd_rawmidi snd_hwdep snd_seq btbcm intel_rapl_perf btintel snd_seq_device snd_pcm uvcvideo bluetooth cfg80211 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common joydev videodev thunderbolt snd_timer snd media mei_me ecdh_generic i2c_i801 rtsx_pci rfkill mei soundcore intel_pch_thermal wmi [ 77.797719] acpi_pad hp_accel lis3lv02d input_polldev hp_wireless pcc_cpufreq amdgpu i915 chash gpu_sched i2c_algo_bit drm_kms_helper tg3 ttm drm serio_raw libphy e1000e crc32c_intel video [ 77.797727] CPU: 7 PID: 55 Comm: kworker/7:0 Tainted: GW 4.18.8-200.fc28.x86_64 #1 [ 77.797728] Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.22 05/17/2018 [ 77.797738] Workqueue: events drm_mode_rmfb_work_fn [drm] [ 77.797766] RIP: 0010:generic_reg_wait+0xe7/0x160 [amdgpu] [ 77.797766] Code: 44 24 58 8b 54 24 48 89 de 44 89 4c 24 08 48 8b 4c 24 50 48 c7 c7 80 72 a3 c0 e8 64 5f b5 ff 83 7d 20 01 44 8b 4c 24 08 74 02 <0f> 0b 48 83 c4 10 44 89 c8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 0f [ 77.797782] RSP: 0018:9c4f81aeba10 EFLAGS: 00010297 [ 77.797783] RAX: RBX: 000a RCX: [ 77.797783] RDX: RSI: 8ddf2f5d6938 RDI: 8ddf2f5d6938 [ 77.797784] RBP: 8ddf14c09b80 R08: 0005 R09: 00010200 [ 77.797784] R10: R11: 969a11ed R12: 0bb9 [ 77.797785] R13: 4ea4 R14: 0001 R15: [ 77.797786] FS: () GS:8ddf2f5c() knlGS: [ 77.797786] CS: 0010 DS: ES: CR0: 80050033 [ 77.797787] CR2: 7f2ec5105020 CR3: 00044820a003 CR4: 003606e0 [ 77.797787] DR0: DR1: DR2: [ 77.797788] DR3: DR6: fffe0ff0 DR7: 0400 [ 77.797788] Call Trace: [ 77.797820] dce110_stream_encoder_dp_blank+0x12c/0x1a0 [amdgpu] [ 77.797848] core_link_disable_stream+0x54/0x220 [amdgpu] [ 77.797875] dce110_reset_hw_ctx_wrap+0xc1/0x1e0 [amdgpu] [ 77.797902] dce110_apply_ctx_to_hw+0x52/0xa30 [amdgpu] [ 77.797931] ? dce_pipe_control_lock+0x1da/0x1f0 [amdgpu] [ 77.797976] dc_commit_state+0x2e7/0x580 [amdgpu] [ 77.798020] amdgpu_dm_atomic_commit_tail+0x37c/0xd70 [amdgpu] [ 77.798023] ? _cond_resched+0x15/0x30 [ 77.798024] ? wait_for_completion_timeout+0x3a/0x190 [ 77.798025] ? wait_for_completion_interruptible+0x35/0x1d0 [ 77.798053] ? dm_plane_helper_cleanup_fb+0x120/0x120 [amdgpu] [ 77.798058] commit_tail+0x3d/0x70 [drm_kms_helper] [ 77.798062] drm_atomic_helper_commit+0x103/0x110 [drm_kms_helper] [ 77.798069] drm_framebuffer_remove+0x2cc/0x3e0 [drm] [ 77.798076] drm_mode_rmfb_work_fn+0x4f/0x60 [drm] [ 77.798079] process_one_work+0x1a1/0x350 [ 77.798080] worker_thread+0x30/0x380 [ 77.798082] ? pwq_unbound_release_workfn+0xd0/0xd0 [ 77.798083] kthread+0x112/0x130 [ 77.798084] ? kthread_create_worker_on_cpu+0x70/0x70 [ 77.798086] ret_from_fork+0x35/0x40 [ 77.798087] ---[ end trace db8425ba857d73a8 ]--- [ 77.922892] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:927 [ 77.922946] WARNING: CPU: 5 PID: 76 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] [ 77.922947] Modules linked in: fuse vfat fat arc4 rtsx_pci_sdmmc mmc_core mei_wdt rtsx_pci_ms intel_rapl memstick
[Bug 108014] AMD WX4150 - MST is entirely nonfunctional, spams dmesg with errors
https://bugs.freedesktop.org/show_bug.cgi?id=108014 Lyude Paul changed: What|Removed |Added Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2 00/13] hide library symbols by default
On Thu, Sep 20, 2018 at 01:16:09PM +0100, Emil Velikov wrote: > On 14 September 2018 at 00:57, Lucas De Marchi > wrote: > > Rely on -fvisibility=hidden to hide the symbols. Previous version of > > this series applying only to drm_intel.so is > > > > Reviewed-by: Eric Engestrom > > > > but it's not included here since I changed the approach for the build > > system change. > > > > drm_private can also be removed from other symbols but it proved to be > > a lot of manual work to re-align all the fields, so I decided to leave > > it to be done on top as a cleanup. > > > Did you read through the reasoning behind > 0f8da82500ec542e269092c0718479e25eaff5f6? In v1 (https://lists.freedesktop.org/archives/dri-devel/2018-September/189639.html) I had this: From git log archeology and mention in another thread we used to pass -fvisibility=hidden, but reverted to the contrary due to bug in obscure toolchain some years ago (see 0f8da82500ec542e269092c0718479e25eaff5f6). I think it's time to revisit that decision: we have plenty of other projects doing that nowadays without problem. It looks like for some reason this was not part of the coverletter in v2, sorry. > > Alternatively you do not care too much about compat in said cases, > which is fine. > My only request is - keep it only for the Intel bits. this is not only for Intel bits, it's improving all the libdrm as a whole. A decision/commit made 3 year can be revisited, we don't have to carry it forever. Do we have a problem with it *today*? If we do, then we may have another decision like working it around for the sad said compiler rather than for everybody. Default visibility hidden is a sane default adopted by multiple open source libraries as it avoids unwanted results that can't be taken back (like exporting a symbol that shouldn't have been) and reduces maintenance (just look at the custom scripts we have to keep checking the exported symbols). Lucas De Marchi > > Thanks > Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead
On Fri, 2018-09-21 at 11:27 +0200, Daniel Vetter wrote:
> On Tue, Sep 18, 2018 at 07:06:19PM -0400, Lyude Paul wrote:
> > Currently we set intel_connector->mst_port to NULL to signify that the
> > MST port has been removed from the system so that we can prevent further
> > action on the port such as connector probes, mode probing, etc.
> > However, we're going to need access to intel_connector->mst_port in
> > order to fixup ->best_encoder() so that it can always return the correct
> > encoder for an MST port to prevent legacy DPMS prop changes from
> > failing. This should be safe, so instead keep intel_connector->mst_port
> > always set and instead add intel_connector->mst_port_gone in order to
> > signify whether or not the connector has disappeared from the system.
> >
> > Signed-off-by: Lyude Paul
> > Cc: sta...@vger.kernel.org
>
> Hm, how exactly do legacy DPMS setprop blow up here? Or at least I can't
> come up with a scenario that's specific to legacy props, atomic should be
> equally affected. By the time we land in this code, the core code already
> remapping it to be purely an atomic update.
So, what I've been seeing with X that's been blowing this up:
* Hotplug event gets received, X does reprobe
* Notices MST connectors are now disconnected, sets DPMS from on->off
* During atomic_check, drm_atomic_helper_check_modeset() is called
* update_connector_routing() gets called
* funcs->best_encoder() returns NULL for the encoder
* update_connector_routing() fails atomic commit with "No suitable encoder
found", line 320 of drm_atomic_helper
>
> Another thought: Should we handle at least some of this in the probe
> helpers? I.e. once you unplugged a drm_connector, it always shows
> disconnected and mode list is gone, instead of duplicating this over all
> drivers. We could just check connector->registered.
oooh, good idea! I will certainly go do that
>
> Thanks, Daniel
> > ---
> > drivers/gpu/drm/i915/intel_dp_mst.c | 14 +++---
> > drivers/gpu/drm/i915/intel_drv.h| 1 +
> > 2 files changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 4ecd65375603..fcb9b87b9339 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -311,9 +311,8 @@ static int intel_dp_mst_get_ddc_modes(struct
> > drm_connector *connector)
> > struct edid *edid;
> > int ret;
> >
> > - if (!intel_dp) {
> > + if (intel_connector->mst_port_gone)
> > return intel_connector_update_modes(connector, NULL);
> > - }
> >
> > edid = drm_dp_mst_get_edid(connector, _dp->mst_mgr,
> > intel_connector->port);
> > ret = intel_connector_update_modes(connector, edid);
> > @@ -328,9 +327,10 @@ intel_dp_mst_detect(struct drm_connector *connector,
> > bool force)
> > struct intel_connector *intel_connector =
> > to_intel_connector(connector);
> > struct intel_dp *intel_dp = intel_connector->mst_port;
> >
> > - if (!intel_dp)
> > + if (intel_connector->mst_port_gone)
> > return connector_status_disconnected;
> > - return drm_dp_mst_detect_port(connector, _dp->mst_mgr,
> > intel_connector->port);
> > + return drm_dp_mst_detect_port(connector, _dp->mst_mgr,
> > + intel_connector->port);
> > }
> >
> > static void
> > @@ -370,7 +370,7 @@ intel_dp_mst_mode_valid(struct drm_connector
> > *connector,
> > int bpp = 24; /* MST uses fixed bpp */
> > int max_rate, mode_rate, max_lanes, max_link_clock;
> >
> > - if (!intel_dp)
> > + if (intel_connector->mst_port_gone)
> > return MODE_ERROR;
> >
> > if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > @@ -402,7 +402,7 @@ static struct drm_encoder
> > *intel_mst_atomic_best_encoder(struct drm_connector *c
> > struct intel_dp *intel_dp = intel_connector->mst_port;
> > struct intel_crtc *crtc = to_intel_crtc(state->crtc);
> >
> > - if (!intel_dp)
> > + if (intel_connector->mst_port_gone)
> > return NULL;
> > return _dp->mst_encoders[crtc->pipe]->base.base;
> > }
> > @@ -514,7 +514,7 @@ static void intel_dp_destroy_mst_connector(struct
> > drm_dp_mst_topology_mgr *mgr,
> >connector);
> > /* prevent race with the check in ->detect */
> > drm_modeset_lock(>dev->mode_config.connection_mutex, NULL);
> > - intel_connector->mst_port = NULL;
> > + intel_connector->mst_port_gone = true;
> > drm_modeset_unlock(>dev->mode_config.connection_mutex);
> >
> > drm_connector_put(connector);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 8fc61e96754f..87ce772ae7f8 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -409,6 +409,7 @@ struct intel_connector {
> > void *port; /* store this opaque as its illegal to dereference it */
> >
> >
[GIT PULL] etnaviv-fixes for 4.19
Hi Dave, one fix to get a proper DMA configuration in place for the etnaviv virtual device. I'm sending this as a fix, as a dma-mapping change at the ARC architecture side during the 4.19 cycle broke etnaviv on this platform, which gets remedied with this patch, but it also enables ARM64. If you don't feel like pulling this slightly larger fix this late in the cycle, please pull it for drm-next instead. Rgeards, Lucas The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the Git repository at: https://git.pengutronix.de/git/lst/linux etnaviv/fixes for you to fetch changes up to 1a866306e0fbf3caab168c1389e4497702749441: drm/etnaviv: add DMA configuration for etnaviv platform device (2018-09-14 18:46:10 +0200) Lucas Stach (1): drm/etnaviv: add DMA configuration for etnaviv platform device drivers/gpu/drm/etnaviv/etnaviv_drv.c | 27 +-- 1 file changed, 21 insertions(+), 6 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: Grab runtime PM ref in nv50_mstc_detect()
Reviewed-by: Karol Herbst
On Fri, Sep 14, 2018 at 10:44 PM, Lyude Paul wrote:
> While we currently grab a runtime PM ref in nouveau's normal connector
> detection code, we apparently don't do this for MST. This means if we're
> in a scenario where the GPU is suspended and userspace attempts to do a
> connector probe on an MSTC connector, the probe will fail entirely due
> to the DP aux channel and GPU not being woken up:
>
> [ 316.633489] nouveau :01:00.0: i2c: aux 000a: begin idle timeout
>
> [ 316.635713] nouveau :01:00.0: i2c: aux 000a: begin idle timeout
>
> [ 316.637785] nouveau :01:00.0: i2c: aux 000a: begin idle timeout
>
> ...
>
> So, grab a runtime PM ref here.
>
> Signed-off-by: Lyude Paul
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index c94b7f42d62d..9da0bdfe1e1c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -938,9 +938,22 @@ static enum drm_connector_status
> nv50_mstc_detect(struct drm_connector *connector, bool force)
> {
> struct nv50_mstc *mstc = nv50_mstc(connector);
> + enum drm_connector_status conn_status;
> + int ret;
> +
> if (!mstc->port)
> return connector_status_disconnected;
> - return drm_dp_mst_detect_port(connector, mstc->port->mgr, mstc->port);
> +
> + ret = pm_runtime_get_sync(connector->dev->dev);
> + if (ret < 0 && ret != -EACCES)
> + return connector_status_disconnected;
> +
> + conn_status = drm_dp_mst_detect_port(connector, mstc->port->mgr,
> +mstc->port);
> +
> + pm_runtime_mark_last_busy(connector->dev->dev);
> + pm_runtime_put_autosuspend(connector->dev->dev);
> + return conn_status;
> }
>
> static void
> --
> 2.17.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH 0/2] drm/nouveau: Allow parsing vbios.rom with nvbios from debugfs
Both patches are Reviewed-by: Karol Herbst On Wed, Sep 19, 2018 at 7:13 PM, Lyude Paul wrote: > This is a small patch series that adds a strap_peek file into our > debugfs, and sets the size of the vbios.rom debugfs file so that nvbios > can easily be used to parse the vbios even on systems where the normal > BIOS retrieval methods (for example, laptops that need ACPI to access > the vbios for the nvidia GPU) won't work. This should make it a little > easier to collect vbioses. > > Lyude Paul (2): > drm/nouveau: Add strap_peek to debugfs > drm/nouveau: Add size to vbios.rom file in debugfs > > drivers/gpu/drm/nouveau/nouveau_debugfs.c | 46 --- > 1 file changed, 41 insertions(+), 5 deletions(-) > > -- > 2.17.1 > > ___ > Nouveau mailing list > nouv...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107607] Problems with MST display (REG_WAIT takes a while or times out)
https://bugs.freedesktop.org/show_bug.cgi?id=107607 --- Comment #6 from Jerry Zuo --- I got it. Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/scheduler: remove timeout work_struct from drm_sched_job
having a delayed work item per job is redundant as we only need one
per scheduler to track the time out the currently executing job.
v2: the first element of the ring mirror list is the currently
executing job so we don't need a additional variable for it
Signed-off-by: Nayan Deshmukh
Suggested-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 28 +++-
include/drm/gpu_scheduler.h| 6 +++---
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 9ca741f3a0bc..88f6cff136f2 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -197,19 +197,16 @@ static void drm_sched_job_finish(struct work_struct *work)
* manages to find this job as the next job in the list, the fence
* signaled check below will prevent the timeout to be restarted.
*/
- cancel_delayed_work_sync(_job->work_tdr);
+ cancel_delayed_work_sync(>work_tdr);
spin_lock(>job_list_lock);
/* queue TDR for next job */
+ list_del(_job->node);
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
- !list_is_last(_job->node, >ring_mirror_list)) {
- struct drm_sched_job *next = list_next_entry(s_job, node);
-
- if (!dma_fence_is_signaled(>s_fence->finished))
- schedule_delayed_work(>work_tdr, sched->timeout);
+ !list_empty(>ring_mirror_list)) {
+ schedule_delayed_work(>work_tdr, sched->timeout);
}
/* remove job from ring_mirror_list */
- list_del(_job->node);
spin_unlock(>job_list_lock);
dma_fence_put(_job->s_fence->finished);
@@ -236,16 +233,21 @@ static void drm_sched_job_begin(struct drm_sched_job
*s_job)
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
list_first_entry_or_null(>ring_mirror_list,
struct drm_sched_job, node) == s_job)
- schedule_delayed_work(_job->work_tdr, sched->timeout);
+ schedule_delayed_work(>work_tdr, sched->timeout);
spin_unlock(>job_list_lock);
}
static void drm_sched_job_timedout(struct work_struct *work)
{
- struct drm_sched_job *job = container_of(work, struct drm_sched_job,
-work_tdr.work);
+ struct drm_gpu_scheduler *sched;
+ struct drm_sched_job *job;
+
+ sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
+ job = list_first_entry_or_null(>ring_mirror_list,
+ struct drm_sched_job, node);
- job->sched->ops->timedout_job(job);
+ if (job)
+ job->sched->ops->timedout_job(job);
}
/**
@@ -315,7 +317,7 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler *sched)
s_job = list_first_entry_or_null(>ring_mirror_list,
struct drm_sched_job, node);
if (s_job && sched->timeout != MAX_SCHEDULE_TIMEOUT)
- schedule_delayed_work(_job->work_tdr, sched->timeout);
+ schedule_delayed_work(>work_tdr, sched->timeout);
list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
struct drm_sched_fence *s_fence = s_job->s_fence;
@@ -384,7 +386,6 @@ int drm_sched_job_init(struct drm_sched_job *job,
INIT_WORK(>finish_work, drm_sched_job_finish);
INIT_LIST_HEAD(>node);
- INIT_DELAYED_WORK(>work_tdr, drm_sched_job_timedout);
return 0;
}
@@ -575,6 +576,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
INIT_LIST_HEAD(>ring_mirror_list);
spin_lock_init(>job_list_lock);
atomic_set(>hw_rq_count, 0);
+ INIT_DELAYED_WORK(>work_tdr, drm_sched_job_timedout);
atomic_set(>num_jobs, 0);
atomic64_set(>job_id_count, 0);
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index daec50f887b3..d87b268f1781 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -175,8 +175,6 @@ struct drm_sched_fence *to_drm_sched_fence(struct dma_fence
*f);
* finished to remove the job from the
* @drm_gpu_scheduler.ring_mirror_list.
* @node: used to append this struct to the
@drm_gpu_scheduler.ring_mirror_list.
- * @work_tdr: schedules a delayed call to @drm_sched_job_timedout after the
timeout
- *interval is over.
* @id: a unique id assigned to each job scheduled on the scheduler.
* @karma: increment on every hang caused by this job. If this exceeds the hang
* limit of the scheduler then the job is marked guilty and will not
@@ -195,7 +193,6 @@ struct drm_sched_job {
struct dma_fence_cb finish_cb;
struct work_struct finish_work;
struct list_headnode;
- struct delayed_work
Re: [PATCH] drm/virtio: pass virtio_gpu_object to virtio_gpu_cmd_transfer_to_host_{2d,3d}
On 09/20/2018 11:53 PM, Jiandi An wrote:
>
>
> On 09/20/2018 01:29 AM, Gerd Hoffmann wrote:
>> Pass virtio_gpu_object down to virtio_gpu_cmd_transfer_to_host_2d and
>> virtio_gpu_cmd_transfer_to_host_3d functions, instead of passing just
>> the virtio resource handle.
>>
>> This is needed to lookup the scatter list of the object, for dma sync.
>>
>> Signed-off-by: Gerd Hoffmann
>
> Tested-by: Jiandi An
Reviewed-by: Jiandi An
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> ---
>> drivers/gpu/drm/virtio/virtgpu_drv.h | 6 --
>> drivers/gpu/drm/virtio/virtgpu_fb.c| 2 +-
>> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
>> drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++--
>> drivers/gpu/drm/virtio/virtgpu_vq.c| 20
>> 5 files changed, 17 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
>> b/drivers/gpu/drm/virtio/virtgpu_drv.h
>> index a2d79e18bd..253fcf018d 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
>> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
>> @@ -270,7 +270,8 @@ void virtio_gpu_cmd_create_resource(struct
>> virtio_gpu_device *vgdev,
>> void virtio_gpu_cmd_unref_resource(struct virtio_gpu_device *vgdev,
>> uint32_t resource_id);
>> void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev,
>> -uint32_t resource_id, uint64_t offset,
>> +struct virtio_gpu_object *bo,
>> +uint64_t offset,
>> __le32 width, __le32 height,
>> __le32 x, __le32 y,
>> struct virtio_gpu_fence **fence);
>> @@ -316,7 +317,8 @@ void virtio_gpu_cmd_transfer_from_host_3d(struct
>> virtio_gpu_device *vgdev,
>>struct virtio_gpu_box *box,
>>struct virtio_gpu_fence **fence);
>> void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev,
>> -uint32_t resource_id, uint32_t ctx_id,
>> +struct virtio_gpu_object *bo,
>> +uint32_t ctx_id,
>> uint64_t offset, uint32_t level,
>> struct virtio_gpu_box *box,
>> struct virtio_gpu_fence **fence);
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c
>> b/drivers/gpu/drm/virtio/virtgpu_fb.c
>> index b9678c4082..3364b0970d 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_fb.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
>> @@ -95,7 +95,7 @@ static int virtio_gpu_dirty_update(struct
>> virtio_gpu_framebuffer *fb,
>>
>> offset = (y * fb->base.pitches[0]) + x * bpp;
>>
>> -virtio_gpu_cmd_transfer_to_host_2d(vgdev, obj->hw_res_handle,
>> +virtio_gpu_cmd_transfer_to_host_2d(vgdev, obj,
>> offset,
>> cpu_to_le32(w),
>> cpu_to_le32(h),
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
>> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
>> index 7bdf6f0e58..f16b875d6a 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
>> @@ -429,11 +429,11 @@ static int virtio_gpu_transfer_to_host_ioctl(struct
>> drm_device *dev, void *data,
>> convert_to_hw_box(, >box);
>> if (!vgdev->has_virgl_3d) {
>> virtio_gpu_cmd_transfer_to_host_2d
>> -(vgdev, qobj->hw_res_handle, offset,
>> +(vgdev, qobj, offset,
>> box.w, box.h, box.x, box.y, NULL);
>> } else {
>> virtio_gpu_cmd_transfer_to_host_3d
>> -(vgdev, qobj->hw_res_handle,
>> +(vgdev, qobj,
>> vfpriv ? vfpriv->ctx_id : 0, offset,
>> args->level, , );
>> reservation_object_add_excl_fence(qobj->tbo.resv,
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
>> b/drivers/gpu/drm/virtio/virtgpu_plane.c
>> index 88f2fb8c61..682a977d68 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
>> @@ -158,7 +158,7 @@ static void virtio_gpu_primary_plane_update(struct
>> drm_plane *plane,
>> handle = bo->hw_res_handle;
>> if (bo->dumb) {
>> virtio_gpu_cmd_transfer_to_host_2d
>> -(vgdev, handle, 0,
>> +
Re: [PATCH v2] libdrm: headers: Sync with drm-next
Hi Ayan, On 21 September 2018 at 17:00, Ayan Kumar Halder wrote: > radeon: > - Removed RADEON_TILING_R600_NO_SCANOUT > > sis: > - Changed the data type of some structure members from 'int' to 'long'. > > via: > - Removed inclusion of 'via_drmclient.h'. These three need to be fixed properly. Having a look at the radeon case - the define is used in mesa, so we should really add it to the kernel copy. Haven't looked closely at the rest. Personally I'd omit touching those files for now. With that, the patch is Reviewed-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 2/3] drm/gem: Add drm_gem_object_funcs
This adds an optional function table on GEM objects.
The main benefit is for drivers that support more than one type of
memory (shmem,vram,cma) for their buffers depending on the hardware it
runs on. With the callbacks attached to the GEM object itself, it is
easier to have core helpers for the the various buffer types. The driver
only has to make the decision about buffer type on GEM object creation
and all other callbacks can be handled by the chosen helper.
drm_driver->gem_prime_res_obj has not been added since there's a todo to
put a reservation_object into drm_gem_object.
The individual drm_driver callbacks take priority over the GEM attached
callbacks.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 12 ++--
drivers/gpu/drm/drm_fb_helper.c | 8 ++-
drivers/gpu/drm/drm_gem.c | 108 +--
drivers/gpu/drm/drm_prime.c | 40 ++--
include/drm/drm_gem.h | 138
5 files changed, 272 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 17d9a64e885e..eca7331762e4 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -80,8 +80,7 @@ int drm_client_new(struct drm_device *dev, struct
drm_client_dev *client,
{
int ret;
- if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
- !dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
+ if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
!dev->driver->dumb_create)
return -EOPNOTSUPP;
if (funcs && !try_module_get(funcs->owner))
@@ -212,8 +211,7 @@ static void drm_client_buffer_delete(struct
drm_client_buffer *buffer)
{
struct drm_device *dev = buffer->client->dev;
- if (buffer->vaddr && dev->driver->gem_prime_vunmap)
- dev->driver->gem_prime_vunmap(buffer->gem, buffer->vaddr);
+ drm_gem_vunmap(buffer->gem, buffer->vaddr);
if (buffer->gem)
drm_gem_object_put_unlocked(buffer->gem);
@@ -266,9 +264,9 @@ drm_client_buffer_create(struct drm_client_dev *client, u32
width, u32 height, u
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- vaddr = dev->driver->gem_prime_vmap(obj);
- if (!vaddr) {
- ret = -ENOMEM;
+ vaddr = drm_gem_vmap(obj);
+ if (IS_ERR(vaddr)) {
+ ret = PTR_ERR(vaddr);
goto err_delete;
}
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8e95d0f7c71d..66969f0facbb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -3010,9 +3011,12 @@ static void drm_fbdev_fb_destroy(struct fb_info *info)
static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
struct drm_fb_helper *fb_helper = info->par;
+ struct drm_gem_object *obj = fb_helper->buffer->gem;
- if (fb_helper->dev->driver->gem_prime_mmap)
- return
fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
+ if (obj->dev->driver->gem_prime_mmap)
+ return obj->dev->driver->gem_prime_mmap(obj, vma);
+ else if (obj->funcs && obj->funcs->mmap)
+ return drm_gem_mmap_obj(obj, obj->size, vma);
else
return -ENODEV;
}
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 512078ebd97b..7da2549667ce 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -259,6 +259,8 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, file_priv);
+ else if (obj->funcs && obj->funcs->close)
+ obj->funcs->close(obj, file_priv);
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_gem_remove_prime_handles(obj, file_priv);
@@ -414,6 +416,10 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
ret = dev->driver->gem_open_object(obj, file_priv);
if (ret)
goto err_revoke;
+ } else if (obj->funcs && obj->funcs->open) {
+ ret = obj->funcs->open(obj, file_priv);
+ if (ret)
+ goto err_revoke;
}
*handlep = handle;
@@ -841,6 +847,8 @@ drm_gem_object_free(struct kref *kref)
WARN_ON(!mutex_is_locked(>struct_mutex));
dev->driver->gem_free_object(obj);
+ } else if (obj->funcs) {
+ obj->funcs->free(obj);
}
}
EXPORT_SYMBOL(drm_gem_object_free);
@@ -864,13 +872,13 @@ drm_gem_object_put_unlocked(struct drm_gem_object *obj)
dev = obj->dev;
- if
[RFC 0/3] drm/gem: Add drm_gem_object_funcs
Hi, I've found it odd that the GEM object has its callbacks on drm_driver and not a vtable of its own. But something being odd isn't enough to make a change (me thinks). After working on the GEM shmem helper I saw that a few drivers have runtime support for 2 memory types for their buffers (shmem,vram,cma). I have realised that if the shmem helper was self contained wrt the callbacks, it would be easier for these types of drivers to use the helper. All they needed to do was to determine the buffer type on GEM object creation time and let the helper handle the rest of the callbacks. No sure if this makes sense or if the approach is to simplistic. Hence the RFC. I've added a patch to give an example of how this would look for the CMA helper and vc4 (I'm not volunteering to refactor the CMA helper and drivers). Noralf. Noralf Trønnes (3): drm/driver: Add defaults for .gem_prime_export/import callbacks drm/gem: Add drm_gem_object_funcs drm/cma: Use drm_gem_object_funcs Documentation/gpu/todo.rst | 7 ++ drivers/gpu/drm/drm_client.c | 12 ++- drivers/gpu/drm/drm_fb_helper.c | 8 +- drivers/gpu/drm/drm_gem.c| 108 +-- drivers/gpu/drm/drm_gem_cma_helper.c | 99 + drivers/gpu/drm/drm_prime.c | 50 +++-- drivers/gpu/drm/vc4/vc4_bo.c | 46 ++-- drivers/gpu/drm/vc4/vc4_drv.c| 26 +-- drivers/gpu/drm/vc4/vc4_drv.h| 6 +- include/drm/drm_drv.h| 4 + include/drm/drm_gem.h| 138 +++ include/drm/drm_gem_cma_helper.h | 17 + 12 files changed, 350 insertions(+), 171 deletions(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 3/3] drm/cma: Use drm_gem_object_funcs
This is just a showcase for the drm/gem patch, not to be applied.
vc4 has it's own mmap function so I just bundled it in for a quick hack.
The drivers that use the CMA helper should in theory be able to drop it's
drm_driver GEM callbacks (not dumb_create and import) and use the GEM
attached vtable.
There might be driver quirks like for vc4 that results in breakage, so
there's most likely problems lurking here wrt converting the CMA helper.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_gem_cma_helper.c | 99 +---
drivers/gpu/drm/vc4/vc4_bo.c | 46 -
drivers/gpu/drm/vc4/vc4_drv.c| 26 +-
drivers/gpu/drm/vc4/vc4_drv.h| 6 +--
include/drm/drm_gem_cma_helper.h | 17 +--
5 files changed, 59 insertions(+), 135 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 1d2ced882b66..950ebf9fb482 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -40,6 +40,36 @@
* display drivers that are unable to map scattered buffers via an IOMMU.
*/
+static int drm_gem_cma_mmap(struct drm_gem_object *obj, struct vm_area_struct
*vma)
+{
+ struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
+ int ret;
+
+ /*
+* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
+* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to map
+* the whole buffer.
+*/
+ vma->vm_flags &= ~VM_PFNMAP;
+ vma->vm_pgoff = 0;
+
+ ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
+ cma_obj->paddr, vma->vm_end - vma->vm_start);
+ if (ret)
+ drm_gem_vm_close(vma);
+
+ return ret;
+}
+
+static const struct drm_gem_object_funcs drm_gem_cma_funcs = {
+ .free = drm_gem_cma_free_object,
+ .print_info = drm_gem_cma_print_info,
+ .get_sg_table = drm_gem_cma_prime_get_sg_table,
+ .vmap = drm_gem_cma_prime_vmap,
+ .mmap = drm_gem_cma_mmap,
+ .vm_ops = _gem_cma_vm_ops,
+};
+
/**
* __drm_gem_cma_create - Create a GEM CMA object without allocating memory
* @drm: DRM device
@@ -67,6 +97,9 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
return ERR_PTR(-ENOMEM);
cma_obj = container_of(gem_obj, struct drm_gem_cma_object, base);
+ if (!gem_obj->funcs)
+ gem_obj->funcs = _gem_cma_funcs;
+
ret = drm_gem_object_init(drm, gem_obj, size);
if (ret)
goto error;
@@ -270,62 +303,6 @@ const struct vm_operations_struct drm_gem_cma_vm_ops = {
};
EXPORT_SYMBOL_GPL(drm_gem_cma_vm_ops);
-static int drm_gem_cma_mmap_obj(struct drm_gem_cma_object *cma_obj,
- struct vm_area_struct *vma)
-{
- int ret;
-
- /*
-* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
-* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to map
-* the whole buffer.
-*/
- vma->vm_flags &= ~VM_PFNMAP;
- vma->vm_pgoff = 0;
-
- ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
- cma_obj->paddr, vma->vm_end - vma->vm_start);
- if (ret)
- drm_gem_vm_close(vma);
-
- return ret;
-}
-
-/**
- * drm_gem_cma_mmap - memory-map a CMA GEM object
- * @filp: file object
- * @vma: VMA for the area to be mapped
- *
- * This function implements an augmented version of the GEM DRM file mmap
- * operation for CMA objects: In addition to the usual GEM VMA setup it
- * immediately faults in the entire object instead of using on-demaind
- * faulting. Drivers which employ the CMA helpers should use this function
- * as their ->mmap() handler in the DRM device file's file_operations
- * structure.
- *
- * Instead of directly referencing this function, drivers should use the
- * DEFINE_DRM_GEM_CMA_FOPS().macro.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- */
-int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma)
-{
- struct drm_gem_cma_object *cma_obj;
- struct drm_gem_object *gem_obj;
- int ret;
-
- ret = drm_gem_mmap(filp, vma);
- if (ret)
- return ret;
-
- gem_obj = vma->vm_private_data;
- cma_obj = to_drm_gem_cma_obj(gem_obj);
-
- return drm_gem_cma_mmap_obj(cma_obj, vma);
-}
-EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
-
#ifndef CONFIG_MMU
/**
* drm_gem_cma_get_unmapped_area - propose address for mapping in noMMU cases
@@ -525,15 +502,7 @@ EXPORT_SYMBOL_GPL(drm_gem_cma_prime_import_sg_table);
int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
- struct drm_gem_cma_object *cma_obj;
- int ret;
-
- ret = drm_gem_mmap_obj(obj, obj->size, vma);
- if (ret < 0)
-
[RFC 1/3] drm/driver: Add defaults for .gem_prime_export/import callbacks
The majority of drivers use drm_gem_prime_export() and
drm_gem_prime_import() for these callbacks so let's make them the
default.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/todo.rst | 7 +++
drivers/gpu/drm/drm_prime.c | 10 --
include/drm/drm_drv.h | 4
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 77c2b3c25565..39748e22dea8 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -234,6 +234,13 @@ efficient.
Contact: Daniel Vetter
+Defaults for .gem_prime_import and export
+-
+
+Most drivers don't need to set drm_driver->gem_prime_import and
+->gem_prime_export now that drm_gem_prime_import() and drm_gem_prime_export()
+are the default.
+
Core refactorings
=
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 3f0205fc0a1a..6721571749ff 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -559,7 +559,10 @@ static struct dma_buf *export_and_register_object(struct
drm_device *dev,
return dmabuf;
}
- dmabuf = dev->driver->gem_prime_export(dev, obj, flags);
+ if (dev->driver->gem_prime_export)
+ dmabuf = dev->driver->gem_prime_export(dev, obj, flags);
+ else
+ dmabuf = drm_gem_prime_export(dev, obj, flags);
if (IS_ERR(dmabuf)) {
/* normally the created dma-buf takes ownership of the ref,
* but if that fails then drop the ref
@@ -792,7 +795,10 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
/* never seen this one, need to import */
mutex_lock(>object_name_lock);
- obj = dev->driver->gem_prime_import(dev, dma_buf);
+ if (dev->driver->gem_prime_import)
+ obj = dev->driver->gem_prime_import(dev, dma_buf);
+ else
+ obj = drm_gem_prime_import(dev, dma_buf);
if (IS_ERR(obj)) {
ret = PTR_ERR(obj);
goto out_unlock;
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 8830e3de3a86..1162145f7f68 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -471,6 +471,8 @@ struct drm_driver {
* @gem_prime_export:
*
* export GEM -> dmabuf
+*
+* This defaults to drm_gem_prime_export() if not set.
*/
struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
struct drm_gem_object *obj, int flags);
@@ -478,6 +480,8 @@ struct drm_driver {
* @gem_prime_import:
*
* import dmabuf -> GEM
+*
+* This defaults to drm_gem_prime_import() if not set.
*/
struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev,
struct dma_buf *dma_buf);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107607] Problems with MST display (REG_WAIT takes a while or times out)
https://bugs.freedesktop.org/show_bug.cgi?id=107607 --- Comment #5 from Jerry Zuo --- Thank you. You connect both HDMI and DP to UP3214 with DP1.2 enabled, switch back and forth, and the warning is showing up. When the warning is observed, a delay is also observed. Am I right? -- 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 v2] libdrm: headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 2dc7bad71cd310dc94d1c9907909324dd2b0618f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added client capabilities for ASPECT_RATIO and WRITEBACK_CONNECTORS
- Added Arm AFBC modifiers
- Added BROADCOM's SAND and UIF modifiers
- Added Qualcomm's modifiers
- Added some picture aspect ratio and content type options
- Added some drm mode flags
- Added writeback connector id
amdgpu:
- Added GEM domain mask
- Added some GEM flags
- Added some hardware ip flags
- Added chunk id and IB fence.
- Added some query ids
i915:
-Added an IOCTL (I915_PARAM_MMAP_GTT_COHERENT)
qxl:
- Minor changes
radeon:
- Removed RADEON_TILING_R600_NO_SCANOUT
sis:
- Changed the data type of some structure members from 'int' to 'long'.
tegra:
- Added some comments about struct drm_tegra* members
- Modified DRM_IOCTL_TEGRA_CLOSE_CHANNEL
vc4:
- Added some members for 'struct drm_vc4_submit_cl'
via:
- Removed inclusion of 'via_drmclient.h'.
vmwgfx:
- Added some DRM_VMW_* macros
- Renamed some structures like 'drm_vmw_dmabuf_rep' to 'drm_vmw_bo_rep', etc
- Added some new DRM_VMW_GB_SURFACE related structures and unions
Changes in v2:
- Mentioned 'libdrm' in the commit header.
Signed-off-by: Ayan Kumar halder
---
include/drm/amdgpu_drm.h | 47 -
include/drm/drm.h| 16 ++
include/drm/drm_fourcc.h | 215 +
include/drm/drm_mode.h | 35 +++-
include/drm/i915_drm.h | 22 +++
include/drm/qxl_drm.h| 2 -
include/drm/radeon_drm.h | 1 -
include/drm/sis_drm.h| 8 +-
include/drm/tegra_drm.h | 492 ++-
include/drm/vc4_drm.h| 13 +-
include/drm/via_drm.h| 1 -
include/drm/vmwgfx_drm.h | 166
12 files changed, 957 insertions(+), 61 deletions(-)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index c363b67..1ceec56 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -72,12 +72,41 @@ extern "C" {
#define DRM_IOCTL_AMDGPU_FENCE_TO_HANDLE DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_FENCE_TO_HANDLE, union drm_amdgpu_fence_to_handle)
#define DRM_IOCTL_AMDGPU_SCHED DRM_IOW(DRM_COMMAND_BASE +
DRM_AMDGPU_SCHED, union drm_amdgpu_sched)
+/**
+ * DOC: memory domains
+ *
+ * %AMDGPU_GEM_DOMAIN_CPU System memory that is not GPU accessible.
+ * Memory in this pool could be swapped out to disk if there is pressure.
+ *
+ * %AMDGPU_GEM_DOMAIN_GTT GPU accessible system memory, mapped into the
+ * GPU's virtual address space via gart. Gart memory linearizes non-contiguous
+ * pages of system memory, allows GPU access system memory in a linezrized
+ * fashion.
+ *
+ * %AMDGPU_GEM_DOMAIN_VRAM Local video memory. For APUs, it is memory
+ * carved out by the BIOS.
+ *
+ * %AMDGPU_GEM_DOMAIN_GDS Global on-chip data storage used to share data
+ * across shader threads.
+ *
+ * %AMDGPU_GEM_DOMAIN_GWS Global wave sync, used to synchronize the
+ * execution of all the waves on a device.
+ *
+ * %AMDGPU_GEM_DOMAIN_OA Ordered append, used by 3D or Compute engines
+ * for appending data.
+ */
#define AMDGPU_GEM_DOMAIN_CPU 0x1
#define AMDGPU_GEM_DOMAIN_GTT 0x2
#define AMDGPU_GEM_DOMAIN_VRAM 0x4
#define AMDGPU_GEM_DOMAIN_GDS 0x8
#define AMDGPU_GEM_DOMAIN_GWS 0x10
#define AMDGPU_GEM_DOMAIN_OA 0x20
+#define AMDGPU_GEM_DOMAIN_MASK (AMDGPU_GEM_DOMAIN_CPU | \
+AMDGPU_GEM_DOMAIN_GTT | \
+AMDGPU_GEM_DOMAIN_VRAM | \
+AMDGPU_GEM_DOMAIN_GDS | \
+AMDGPU_GEM_DOMAIN_GWS | \
+AMDGPU_GEM_DOMAIN_OA)
/* Flag that CPU access will be required for the case of VRAM domain */
#define AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED (1 << 0)
@@ -95,6 +124,10 @@ extern "C" {
#define AMDGPU_GEM_CREATE_VM_ALWAYS_VALID (1 << 6)
/* Flag that BO sharing will be explicitly synchronized */
#define AMDGPU_GEM_CREATE_EXPLICIT_SYNC(1 << 7)
+/* Flag that indicates allocating MQD gart on GFX9, where the mtype
+ * for the second page onward should be set to NC.
+ */
+#define AMDGPU_GEM_CREATE_MQD_GFX9 (1 << 8)
struct drm_amdgpu_gem_create_in {
/** the requested memory size */
@@ -473,7 +506,8 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_HW_IP_UVD_ENC 5
#define AMDGPU_HW_IP_VCN_DEC 6
#define AMDGPU_HW_IP_VCN_ENC 7
-#define AMDGPU_HW_IP_NUM 8
+#define AMDGPU_HW_IP_VCN_JPEG 8
+#define AMDGPU_HW_IP_NUM 9
#define AMDGPU_HW_IP_INSTANCE_MAX_COUNT 1
@@ -482,6 +516,7 @@ struct drm_amdgpu_gem_va {
#define
[PATCH v2] drm/arm/malidp: Validate rotations for compressed/uncompressed framebuffers for each layer
From: Ayan Kumar Halder
Add support for compressed framebuffers that are described using
the framebuffer's modifier field. Mali DP uses the rotation memory for
the decompressor of the format, so we need to check for space when
the modifiers are present.
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Brian Starkey
[re-worded commit, rebased, cleaned up duplicated checks for
RGB888 and BGR888 and removed additional parameter for
rotmem_required function hook]
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 28 -
drivers/gpu/drm/arm/malidp_hw.c | 38 -
drivers/gpu/drm/arm/malidp_hw.h | 7 ++
drivers/gpu/drm/arm/malidp_planes.c | 19 +++
4 files changed, 53 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index ef44202fb43f8..e1b72782848c3 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -348,19 +348,20 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
/*
* check if there is enough rotation memory available for planes
-* that need 90° and 270° rotation. Each plane has set its required
-* memory size in the ->plane_check() callback, here we only make
-* sure that the sums are less that the total usable memory.
+* that need 90° and 270° rotion or planes that are compressed.
+* Each plane has set its required memory size in the ->plane_check()
+* callback, here we only make sure that the sums are less that the
+* total usable memory.
*
* The rotation memory allocation algorithm (for each plane):
-* a. If no more rotated planes exist, all remaining rotate
-* memory in the bank is available for use by the plane.
-* b. If other rotated planes exist, and plane's layer ID is
-* DE_VIDEO1, it can use all the memory from first bank if
-* secondary rotation memory bank is available, otherwise it can
+* a. If no more rotated or compressed planes exist, all remaining
+* rotate memory in the bank is available for use by the plane.
+* b. If other rotated or compressed planes exist, and plane's
+* layer ID is DE_VIDEO1, it can use all the memory from first bank
+* if secondary rotation memory bank is available, otherwise it can
* use up to half the bank's memory.
-* c. If other rotated planes exist, and plane's layer ID is not
-* DE_VIDEO1, it can use half of the available memory
+* c. If other rotated or compressed planes exist, and plane's layer ID
+* is not DE_VIDEO1, it can use half of the available memory.
*
* Note: this algorithm assumes that the order in which the planes are
* checked always has DE_VIDEO1 plane first in the list if it is
@@ -372,7 +373,9 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
/* first count the number of rotated planes */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
- if (pstate->rotation & MALIDP_ROTATED_MASK)
+ struct drm_framebuffer *fb = pstate->fb;
+
+ if ((pstate->rotation & MALIDP_ROTATED_MASK) || fb->modifier)
rotated_planes++;
}
@@ -388,8 +391,9 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
struct malidp_plane *mp = to_malidp_plane(plane);
struct malidp_plane_state *ms = to_malidp_plane_state(pstate);
+ struct drm_framebuffer *fb = pstate->fb;
- if (pstate->rotation & MALIDP_ROTATED_MASK) {
+ if ((pstate->rotation & MALIDP_ROTATED_MASK) || fb->modifier) {
/* process current plane */
rotated_planes--;
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b33000634a4ee..5549092e6c36a 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -85,41 +85,43 @@ static const struct malidp_format_id malidp550_de_formats[]
= {
static const struct malidp_layer malidp500_layers[] = {
/* id, base address, fb pointer address base, stride offset,
- yuv2rgb matrix offset, mmu control register offset */
+ yuv2rgb matrix offset, mmu control register offset,
rotation_features */
{ DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0 },
+ MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
{ DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0 },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
{
[PATCH libdrm] meson: honor -Detnaviv=auto
We support that value so it should work as expected. This does not make
'auto' the default since the API is still marked as experimental.
---
meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 75c7bdff..8001a9cc 100644
--- a/meson.build
+++ b/meson.build
@@ -142,11 +142,11 @@ endif
with_etnaviv = false
_etnaviv = get_option('etnaviv')
-if _etnaviv == 'true'
+if _etnaviv != 'false'
if not with_atomics
error('libdrm_etnaviv requires atomics.')
endif
- with_etnaviv = true
+ with_etnaviv = _etnaviv == 'true' or ['arm',
'aarch64'].contains(host_machine.cpu_family())
endif
with_exynos = get_option('exynos') == 'true'
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] dt-bindings: Add Truly NT35597 panel driver bindings
On Wed, Sep 19, 2018 at 7:55 PM Abhinav Kumar wrote: > From: "abhin...@codeaurora.org" > > Add the device tree bindings for Truly NT35597 panel driver. > This panel driver supports both single DSI and dual DSI. > > However, this patch series supports only dual DSI. > > Changes in v7: > - Change the compatible string to indicate only the > panel driver string and the resolution > - Indicate reset GPIO is ACTIVE_LOW This works for me. Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/18] video/hdmi: Handle the NTSC VBI infoframe
From: Ville Syrjälä
Add the code to deal with the NTSC VBI infoframe.
I decided against parsing the PES_data_field and just leave
it as an opaque blob, just dumping it out as hex in the log.
Blindly typed from the spec, and totally untested.
v2: Rebase
Cc: Thierry Reding
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c | 208 +++
include/linux/hdmi.h | 18 +
2 files changed, 226 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 6f39b9ae56b9..b14202fc5854 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -831,6 +831,139 @@ ssize_t hdmi_mpeg_source_infoframe_pack(struct
hdmi_mpeg_source_infoframe *frame
}
EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack);
+/**
+ * hdmi_ntsc_vbi_infoframe_init() - initialize an HDMI NTSC VBI infoframe
+ * @frame: HDMI NTSC VBI infoframe
+ * @pes_data_field: ANSI/SCTE 127 PES_data_field
+ * @length: ANSI/SCTE 127 PES_data_field length
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_ntsc_vbi_infoframe_init(struct hdmi_ntsc_vbi_infoframe *frame,
+const void *pes_data_field,
+size_t length)
+{
+ if (length < 1 || length > 27)
+ return -EINVAL;
+
+ memset(frame, 0, sizeof(*frame));
+
+ frame->type = HDMI_INFOFRAME_TYPE_NTSC_VBI;
+ frame->version = 1;
+ frame->length = length;
+
+ memcpy(frame->pes_data_field, pes_data_field, length);
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_init);
+
+static int hdmi_ntsc_vbi_infoframe_check_only(const struct
hdmi_ntsc_vbi_infoframe *frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_NTSC_VBI ||
+ frame->version != 1 ||
+ frame->length < 1 || frame->length > 27)
+ return -EINVAL;
+
+ if (frame->pes_data_field[0] != 0x99)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * hdmi_ntsc_vbi_infoframe_check() - Check and check a HDMI NTSC VBI infoframe
+ * @frame: HDMI NTSC VBI infoframe
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_ntsc_vbi_infoframe_check(struct hdmi_ntsc_vbi_infoframe *frame)
+{
+ return hdmi_ntsc_vbi_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_check);
+
+/**
+ * hdmi_ntsc_vbi_infoframe_pack_only() - write HDMI NTSC VBI infoframe to
binary buffer
+ * @frame: HDMI NTSC VBI infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_ntsc_vbi_infoframe_pack_only(const struct hdmi_ntsc_vbi_infoframe
*frame,
+ void *buffer, size_t size)
+{
+ u8 *ptr = buffer;
+ size_t length;
+ int ret;
+
+ ret = hdmi_ntsc_vbi_infoframe_check_only(frame);
+ if (ret)
+ return ret;
+
+ length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(buffer, 0, size);
+
+ ptr[0] = frame->type;
+ ptr[1] = frame->version;
+ ptr[2] = frame->length;
+ ptr[3] = 0; /* checksum */
+
+ /* start infoframe payload */
+ ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+ memcpy(ptr, frame->pes_data_field, frame->length);
+
+ hdmi_infoframe_set_checksum(buffer, length);
+
+ return length;
+}
+EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_pack_only);
+
+/**
+ * hdmi_ntsc_vbi_infoframe_pack() - check a HDMI NTSC VBI infoframe,
+ * and write it to binary buffer
+ * @frame: HDMI NTSC VBI infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields, after which packs the information
+ * contained in the @frame structure into a binary representation that
+ * can be written into the corresponding controller registers. This function
+ * also computes the checksum as required by section 5.3.5 of the HDMI 1.4
+ * specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_ntsc_vbi_infoframe_pack(struct hdmi_ntsc_vbi_infoframe *frame,
+void *buffer, size_t size)
+{
+ int ret;
+
+ ret = hdmi_ntsc_vbi_infoframe_check(frame);
+ if (ret)
+ return
[PATCH v2 06/18] video/hdmi: Handle the MPEG Source infoframe
From: Ville Syrjälä
Add the code to deal with the MPEG source infoframe.
Blindly typed from the spec, and totally untested.
v2: Rebase
Cc: Thierry Reding
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c | 229 +++
include/linux/hdmi.h | 27 ++
2 files changed, 256 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 08d94ab00467..6f39b9ae56b9 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -706,6 +706,131 @@ hdmi_vendor_any_infoframe_pack(union
hdmi_vendor_any_infoframe *frame,
return hdmi_vendor_any_infoframe_pack_only(frame, buffer, size);
}
+/**
+ * hdmi_mpeg_source_infoframe_init() - initialize an HDMI MPEG Source infoframe
+ * @frame: HDMI MPEG Source infoframe
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_mpeg_source_infoframe_init(struct hdmi_mpeg_source_infoframe *frame)
+{
+ memset(frame, 0, sizeof(*frame));
+
+ frame->type = HDMI_INFOFRAME_TYPE_MPEG_SOURCE;
+ frame->version = 1;
+ frame->length = HDMI_MPEG_SOURCE_INFOFRAME_SIZE;
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_init);
+
+static int hdmi_mpeg_source_infoframe_check_only(const struct
hdmi_mpeg_source_infoframe *frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_MPEG_SOURCE ||
+ frame->version != 1 ||
+ frame->length != HDMI_MPEG_SOURCE_INFOFRAME_SIZE)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * hdmi_mpeg_source_infoframe_check() - check a HDMI MPEG Source infoframe
+ * @frame: HDMI MPEG Source infoframe
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_mpeg_source_infoframe_check(struct hdmi_mpeg_source_infoframe *frame)
+{
+ return hdmi_mpeg_source_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_check);
+
+/**
+ * hdmi_mpeg_source_infoframe_pack_only() - write HDMI MPEG Source infoframe
to binary buffer
+ * @frame: HDMI MPEG Source infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_mpeg_source_infoframe_pack_only(const struct
hdmi_mpeg_source_infoframe *frame,
+void *buffer, size_t size)
+{
+ u8 *ptr = buffer;
+ size_t length;
+ int ret;
+
+ ret = hdmi_mpeg_source_infoframe_check_only(frame);
+ if (ret)
+ return ret;
+
+ length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(buffer, 0, size);
+
+ ptr[0] = frame->type;
+ ptr[1] = frame->version;
+ ptr[2] = frame->length;
+ ptr[3] = 0; /* checksum */
+
+ /* start infoframe payload */
+ ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+ ptr[0] = frame->mpeg_bit_rate >> 0;
+ ptr[1] = frame->mpeg_bit_rate >> 8;
+ ptr[2] = frame->mpeg_bit_rate >> 16;
+ ptr[3] = frame->mpeg_bit_rate >> 24;
+ ptr[4] = (frame->field_repeat << 4) | frame->mpeg_frame;
+
+ hdmi_infoframe_set_checksum(buffer, length);
+
+ return length;
+}
+EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack_only);
+
+/**
+ * hdmi_mpeg_source_infoframe_pack() - check a HDMI MPEG Source infoframe,
+ * and write it to binary buffer
+ * @frame: HDMI MPEG Source infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields, after which packs the information
+ * contained in the @frame structure into a binary representation that
+ * can be written into the corresponding controller registers. This function
+ * also computes the checksum as required by section 5.3.5 of the HDMI 1.4
+ * specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_mpeg_source_infoframe_pack(struct hdmi_mpeg_source_infoframe
*frame,
+ void *buffer, size_t size)
+{
+ int ret;
+
+ ret = hdmi_mpeg_source_infoframe_check(frame);
+ if (ret)
+ return ret;
+
+ return hdmi_mpeg_source_infoframe_pack_only(frame, buffer, size);
+}
+EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack);
+
/**
* hdmi_infoframe_check() - check a HDMI infoframe
* @frame: HDMI infoframe
@@
[Bug 107607] Problems with MST display (REG_WAIT takes a while or times out)
https://bugs.freedesktop.org/show_bug.cgi?id=107607 --- Comment #4 from Paul Menzel --- (In reply to Jerry Zuo from comment #3) > Hi Paul, can you please explain what you did by "when switching the inputs > of the monitor (two systems are connected)"? The monitor has several inputs. Over the OSD (on-screen display) you can tell the monitor what input signal it should display (or the monitor auto-senses it itself). Hopefully, that makes sense. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
On Fri, Sep 21, 2018 at 04:12:36PM +0200, Hans Verkuil wrote:
> On 09/21/18 16:01, Ville Syrjälä wrote:
> > On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
> >> On 09/20/18 20:51, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> We'll be wanting to send more than just infoframes over HDMI. So add an
> >>> enum for other packet types.
> >>>
> >>> TODO: Maybe just include the infoframe types in the packet type enum
> >>> and get rid of the infoframe type enum?
> >>
> >> I think that's better, IMHO. With a comment that the types starting with
> >> 0x81 are defined in CTA-861-G.
> >>
> >> It's really the same byte that is being checked, so having two enums is
> >> a bit misleading. The main difference is really which standard defines
> >> the packet types.
> >
> > Right. The only slight annoyance is that we'll get a bunch of warnings
> > from the compiler if we don't handle all the enum valus in the switch
> > statements. If we want to avoid that I guess I could limit this
> > to just the null, gcp and gamut metadata packets initially and try to
> > write some actual code for them. Those three are the only ones we
> > care about in i915 at the moment.
>
> Note that I don't have a terribly strong opinion on this, so if using
> one enum instead of two causes more problems than it is worth, then
> that's fine with me as well.
>
> But you asked, and given a choice with all other things being equal,
> then one enum has my preference.
I do agree that it would seem nicer.
But I'm a bit busy with other things at the moment so I might want
to leave it like this for now and revisit the topic in the
hopefully-not-too-distant future.
>
> Regards,
>
> Hans
>
> >
> >>
> >> Regards,
> >>
> >>Hans
> >>
> >>>
> >>> Cc: Thierry Reding
> >>> Cc: Hans Verkuil
> >>> Cc: linux-me...@vger.kernel.org
> >>> Signed-off-by: Ville Syrjälä
> >>> ---
> >>> include/linux/hdmi.h | 15 +++
> >>> 1 file changed, 15 insertions(+)
> >>>
> >>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> >>> index c76b50a48e48..80521d9591a1 100644
> >>> --- a/include/linux/hdmi.h
> >>> +++ b/include/linux/hdmi.h
> >>> @@ -27,6 +27,21 @@
> >>> #include
> >>> #include
> >>>
> >>> +enum hdmi_packet_type {
> >>> + HDMI_PACKET_TYPE_NULL = 0x00,
> >>> + HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
> >>> + HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
> >>> + HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
> >>> + HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
> >>> + HDMI_PACKET_TYPE_ISRC1 = 0x05,
> >>> + HDMI_PACKET_TYPE_ISRC2 = 0x06,
> >>> + HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
> >>> + HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
> >>> + HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
> >>> + HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
> >>> + /* + enum hdmi_infoframe_type */
> >>> +};
> >>> +
> >>> enum hdmi_infoframe_type {
> >>> HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
> >>> HDMI_INFOFRAME_TYPE_AVI = 0x82,
> >>>
> >
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/18] drm/i915: Pass intel_encoder to infoframe functions
On Fri, Sep 21, 2018 at 03:59:06PM +0200, Daniel Vetter wrote:
> On Thu, Sep 20, 2018 at 09:51:36PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life simpler by passing around intel_encoder instead of
> > drm_encoder.
> >
> > @r1@
> > identifier F =~ "infoframe";
> > identifier I, M;
> > @@
> > F(
> > - struct drm_encoder *I
> > + struct intel_encoder *I
> > , ...)
> > {
> > <...
> > (
> > - I->M
> > + I->base.M
> > |
> > - I
> > + >base
> > )
> > ...>
> > }
> >
> > @r2@
> > identifier F =~ "infoframe";
> > identifier I;
> > type T, ST;
> > @@
> > ST {
> > ...
> > T (*F)(
> > - struct drm_encoder *I
> > + struct intel_encoder *encoder
> >, ...);
> > ...
> > };
> >
> > @@
> > identifier r1.F;
> > expression E;
> > @@
> > F(
> > - E
> > + to_intel_encoder(E)
> > ,...)
> >
> > @@
> > identifier r2.F;
> > expression E, X;
> > @@
> > (
> > X.F(
> > - E
> > + to_intel_encoder(E)
> > ,...)
> > |
> > X->F(
> > -E
> > +to_intel_encoder(E)
> > ,...)
> > )
> >
> > @@
> > expression E;
> > @@
> > (
> > - to_intel_encoder(>base)
> > + E
> > |
> > - to_intel_encoder(>base.base)
> > + >base
> > )
> >
> > @@
> > identifier D, M;
> > expression E;
> > @@
> > D = enc_to_dig_port(>base)
> > <...
> > (
> > - D->base.M
> > + E->M
> > |
> > - >base
> > + E
> > )
> > ...>
> >
> > @@
> > identifier D;
> > expression E;
> > type T;
> > @@
> > - T D = enc_to_dig_port(E);
> > ... when != D
>
> Someone knows a lot more cocci than I do, impressive. How do you figure
> this stuff out? Read the source?
A combination of reading the docs, looking at other cocci scripts,
cursing, and lost hair. And every time I repeat the process
because I've forgotten what I learned last time around.
>
> Also seems to have some manual fixups below, so I just looked at the diff.
> That looks fine.
I might have accidentally tweaked things when I rebased this. Should
have re-run the cocci script actually. Would be nice if git rebase
did that for you automagically.
I just re-ran spatch and that highlighted five occurances of the
following manual change I had made "accidentally" while rebasing:
++<<< HEAD
+ struct drm_device *dev = encoder->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
++===
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
++>>> 8cdf27dd7e50... drm/i915: Pass intel_encoder to infoframe functions
Nothing else had been tweaked apparently.
>
> Acked-by: Daniel Vetter
Thanks.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107607] Problems with MST display (REG_WAIT takes a while or times out)
https://bugs.freedesktop.org/show_bug.cgi?id=107607 --- Comment #3 from Jerry Zuo --- Hi Paul, can you please explain what you did by "when switching the inputs of the monitor (two systems are connected)"? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/18] video/hdmi: Constify infoframe passed to the pack functions
From: Ville Syrjälä
Let's make the infoframe pack functions usable with a const infoframe
structure. This allows us to precompute the infoframe earlier, and still
pack it later when we're no longer allowed to modify the structure.
So now we end up with a _check()+_pack_only() or _pack() functions
depending on whether you want to precompute the infoframes or not.
The names aren't great but I was lazy and didn't want to change all the
drivers.
v2: Deal with exynos churn
Actually export the new funcs
v3: Fix various documentation fails (Hans)
Cc: Thierry Reding
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c | 425 +++
include/linux/hdmi.h | 19 ++-
2 files changed, 416 insertions(+), 28 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 53e7ee2c83fc..08d94ab00467 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -68,8 +68,36 @@ int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe *frame)
}
EXPORT_SYMBOL(hdmi_avi_infoframe_init);
+static int hdmi_avi_infoframe_check_only(const struct hdmi_avi_infoframe
*frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_AVI ||
+ frame->version != 2 ||
+ frame->length != HDMI_AVI_INFOFRAME_SIZE)
+ return -EINVAL;
+
+ if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
+ return -EINVAL;
+
+ return 0;
+}
+
/**
- * hdmi_avi_infoframe_pack() - write HDMI AVI infoframe to binary buffer
+ * hdmi_avi_infoframe_check() - check a HDMI AVI infoframe
+ * @frame: HDMI AVI infoframe
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame)
+{
+ return hdmi_avi_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_avi_infoframe_check);
+
+/**
+ * hdmi_avi_infoframe_pack_only() - write HDMI AVI infoframe to binary buffer
* @frame: HDMI AVI infoframe
* @buffer: destination buffer
* @size: size of buffer
@@ -82,20 +110,22 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_init);
* Returns the number of bytes packed into the binary buffer or a negative
* error code on failure.
*/
-ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void *buffer,
- size_t size)
+ssize_t hdmi_avi_infoframe_pack_only(const struct hdmi_avi_infoframe *frame,
+void *buffer, size_t size)
{
u8 *ptr = buffer;
size_t length;
+ int ret;
+
+ ret = hdmi_avi_infoframe_check_only(frame);
+ if (ret)
+ return ret;
length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
if (size < length)
return -ENOSPC;
- if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
- return -EINVAL;
-
memset(buffer, 0, size);
ptr[0] = frame->type;
@@ -152,6 +182,36 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe
*frame, void *buffer,
return length;
}
+EXPORT_SYMBOL(hdmi_avi_infoframe_pack_only);
+
+/**
+ * hdmi_avi_infoframe_pack() - check a HDMI AVI infoframe,
+ * and write it to binary buffer
+ * @frame: HDMI AVI infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields, after which it packs the information
+ * contained in the @frame structure into a binary representation that
+ * can be written into the corresponding controller registers. This function
+ * also computes the checksum as required by section 5.3.5 of the HDMI 1.4
+ * specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
+ void *buffer, size_t size)
+{
+ int ret;
+
+ ret = hdmi_avi_infoframe_check(frame);
+ if (ret)
+ return ret;
+
+ return hdmi_avi_infoframe_pack_only(frame, buffer, size);
+}
EXPORT_SYMBOL(hdmi_avi_infoframe_pack);
/**
@@ -178,8 +238,33 @@ int hdmi_spd_infoframe_init(struct hdmi_spd_infoframe
*frame,
}
EXPORT_SYMBOL(hdmi_spd_infoframe_init);
+static int hdmi_spd_infoframe_check_only(const struct hdmi_spd_infoframe
*frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_SPD ||
+ frame->version != 1 ||
+ frame->length != HDMI_SPD_INFOFRAME_SIZE)
+ return -EINVAL;
+
+ return 0;
+}
+
/**
- * hdmi_spd_infoframe_pack() - write HDMI SPD infoframe to binary buffer
+ * hdmi_spd_infoframe_check() - check a HDMI SPD infoframe
+ * @frame: HDMI SPD infoframe
+ *
+ * Validates that the infoframe is consistent and updates derived
Re: [PATCH 04/18] video/hdmi: Constify infoframe passed to the pack functions
On Fri, Sep 21, 2018 at 10:24:25AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's make the infoframe pack functions usable with a const infoframe
> > structure. This allows us to precompute the infoframe earlier, and still
> > pack it later when we're no longer allowed to modify the structure.
> > So now we end up with a _check()+_pack_only() or _pack() functions
> > depending on whether you want to precompute the infoframes or not.
> > The names aren't greate but I was lazy and didn't want to change all the
>
> greate -> great
Thanks for reading through it. Fixed up all the crap you spotted.
>
> > drivers.
> >
> > v2: Deal with exynos churn
> > Actually export the new funcs
> >
> > Cc: Thierry Reding
> > Cc: Hans Verkuil
> > Cc: linux-me...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/video/hdmi.c | 425
> > +++
> > include/linux/hdmi.h | 19 ++-
> > 2 files changed, 416 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 53e7ee2c83fc..9507f668a569 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -68,8 +68,36 @@ int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe
> > *frame)
> > }
> > EXPORT_SYMBOL(hdmi_avi_infoframe_init);
> >
> > +static int hdmi_avi_infoframe_check_only(const struct hdmi_avi_infoframe
> > *frame)
> > +{
> > + if (frame->type != HDMI_INFOFRAME_TYPE_AVI ||
> > + frame->version != 2 ||
> > + frame->length != HDMI_AVI_INFOFRAME_SIZE)
> > + return -EINVAL;
> > +
> > + if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > /**
> > - * hdmi_avi_infoframe_pack() - write HDMI AVI infoframe to binary buffer
> > + * hdmi_avi_infoframe_check() - Check and check a HDMI AVI infoframe
>
> "Check and check"? This is repeated elsewhere as well (clearly
> copy-and-paste).
>
> > + * @frame: HDMI AVI infoframe
> > + *
> > + * Validates that the infoframe is consistent and updates derived fields
> > + * (eg. length) based on other fields.
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame)
> > +{
> > + return hdmi_avi_infoframe_check_only(frame);
> > +}
> > +EXPORT_SYMBOL(hdmi_avi_infoframe_check);
> > +
> > +/**
> > + * hdmi_avi_infoframe_pack_only() - write HDMI AVI infoframe to binary
> > buffer
> > * @frame: HDMI AVI infoframe
> > * @buffer: destination buffer
> > * @size: size of buffer
> > @@ -82,20 +110,22 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_init);
> > * Returns the number of bytes packed into the binary buffer or a negative
> > * error code on failure.
> > */
> > -ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void
> > *buffer,
> > - size_t size)
> > +ssize_t hdmi_avi_infoframe_pack_only(const struct hdmi_avi_infoframe
> > *frame,
> > +void *buffer, size_t size)
> > {
> > u8 *ptr = buffer;
> > size_t length;
> > + int ret;
> > +
> > + ret = hdmi_avi_infoframe_check_only(frame);
> > + if (ret)
> > + return ret;
> >
> > length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> >
> > if (size < length)
> > return -ENOSPC;
> >
> > - if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
> > - return -EINVAL;
> > -
> > memset(buffer, 0, size);
> >
> > ptr[0] = frame->type;
> > @@ -152,6 +182,36 @@ ssize_t hdmi_avi_infoframe_pack(struct
> > hdmi_avi_infoframe *frame, void *buffer,
> >
> > return length;
> > }
> > +EXPORT_SYMBOL(hdmi_avi_infoframe_pack_only);
> > +
> > +/**
> > + * hdmi_avi_infoframe_pack() - Check and check a HDMI AVI infoframe,
> > + * and write it to binary buffer
> > + * @frame: HDMI AVI infoframe
> > + * @buffer: destination buffer
> > + * @size: size of buffer
> > + *
> > + * Validates that the infoframe is consistent and updates derived fields
> > + * (eg. length) based on other fields, after which packs the information
>
> which packs -> which it packs
>
> Ditto elsewhere.
>
> > + * contained in the @frame structure into a binary representation that
> > + * can be written into the corresponding controller registers. Also
>
> Also -> This function also
>
> Ditto elsewhere.
>
> > + * computes the checksum as required by section 5.3.5 of the HDMI 1.4
> > + * specification.
> > + *
> > + * Returns the number of bytes packed into the binary buffer or a negative
> > + * error code on failure.
> > + */
> > +ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
> > + void *buffer, size_t size)
> > +{
> > + int ret;
> > +
> > + ret = hdmi_avi_infoframe_check(frame);
> > + if (ret)
> > + return ret;
> >
Re: Bug report: HiBMC crash
Quoting John Garry (2018-09-21 09:11:19)
> On 21/09/2018 06:49, Liuxinliang (Matthew Liu) wrote:
> > Hi John,
> > Thank you for reporting bug.
> > I am now using 4.18.7. I haven't found this issue yet.
> > I will try linux-next and figure out what's wrong with it.
> >
> > Thanks,
> > Xinliang
> >
> >
>
> As mentioned in internal mail, the issue may be that the surface
> depth/bpp we were using the in the driver was previously invalid, but
> code has since been added in v4.19 to reject this. Specifically it looks
> like this patch:
>
> commit 70109354fed232dfce8fb2c7cadf635acbe03e19
> Author: Chris Wilson
> Date: Wed Sep 5 16:31:16 2018 +0100
>
> drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index b92595c477ef..f3e7f41e6781 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -71,7 +71,6 @@ static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
DRM_DEBUG_DRIVER("surface width(%d), height(%d) and bpp(%d)\n",
sizes->surface_width, sizes->surface_height,
sizes->surface_bpp);
- sizes->surface_depth = 32;
bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
@@ -192,7 +191,6 @@ int hibmc_fbdev_init(struct hibmc_drm_private *priv)
return -ENOMEM;
}
- priv->fbdev = hifbdev;
drm_fb_helper_prepare(priv->dev, >helper,
_fbdev_helper_funcs);
@@ -246,6 +244,7 @@ int hibmc_fbdev_init(struct hibmc_drm_private *priv)
fix->ypanstep, fix->ywrapstep, fix->line_length,
fix->accel, fix->capabilities);
+ priv->fbdev = hifbdev;
return 0;
fini:
Apply chunks 2&3 first to confirm they fix the GPF.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Revert "drm/sun4i: Remove R40 display pipeline compatibles"
This reverts commit 3510e7a7f91088159bfc67e8abdc9f9e77d28870.
During the 4.19 merge window for drm-misc, two patches critical to
supporting the display pipeline on the Allwinner R40 SoC were missed.
They were applied later but missed the merge window deadline. As a
result 4.19-rc1 kernel would crash on the R40 when it couldn't parse
the new device tree structure. We ended up removing support for the
R40 display pipeline for 4.19.
Since the missing patches are already merged for 4.20, we can now
revert the commit that removed support.
Signed-off-by: Chen-Yu Tsai
---
drm-misc-fixes, which contains the patch to be reverted, should be
merged into drm-misc-next before tihs patch is applied.
Also, checkpatch.pl is complaining that the R40 mixer compatibles are
missing from the device tree bindings. It seems the patch adding them
never made it in. Please apply if possible:
https://patchwork.kernel.org/patch/10485815/
Thanks
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
drivers/gpu/drm/sun4i/sun8i_mixer.c| 24
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 1 +
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 9027ddde4262..1e41c3f5fd6d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -402,6 +402,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun8i-a33-display-engine" },
{ .compatible = "allwinner,sun8i-a83t-display-engine" },
{ .compatible = "allwinner,sun8i-h3-display-engine" },
+ { .compatible = "allwinner,sun8i-r40-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ .compatible = "allwinner,sun9i-a80-display-engine" },
{ .compatible = "allwinner,sun50i-a64-display-engine" },
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 091f6cf40353..8b3d02b146b7 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -545,6 +545,22 @@ static const struct sun8i_mixer_cfg sun8i_h3_mixer0_cfg = {
.vi_num = 1,
};
+static const struct sun8i_mixer_cfg sun8i_r40_mixer0_cfg = {
+ .ccsc = 0,
+ .mod_rate = 29700,
+ .scaler_mask= 0xf,
+ .ui_num = 3,
+ .vi_num = 1,
+};
+
+static const struct sun8i_mixer_cfg sun8i_r40_mixer1_cfg = {
+ .ccsc = 1,
+ .mod_rate = 29700,
+ .scaler_mask= 0x3,
+ .ui_num = 1,
+ .vi_num = 1,
+};
+
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -582,6 +598,14 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-h3-de2-mixer-0",
.data = _h3_mixer0_cfg,
},
+ {
+ .compatible = "allwinner,sun8i-r40-de2-mixer-0",
+ .data = _r40_mixer0_cfg,
+ },
+ {
+ .compatible = "allwinner,sun8i-r40-de2-mixer-1",
+ .data = _r40_mixer1_cfg,
+ },
{
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = _v3s_mixer_cfg,
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index 9831a9fe2cf4..3040a79f298f 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -252,6 +252,7 @@ static int sun8i_tcon_top_remove(struct platform_device
*pdev)
/* sun4i_drv uses this list to check if a device node is a TCON TOP */
const struct of_device_id sun8i_tcon_top_of_table[] = {
+ { .compatible = "allwinner,sun8i-r40-tcon-top" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun8i_tcon_top_of_table);
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/10] phy: Add configuration interface
On Wed, Sep 19, 2018 at 02:14:36PM +0200, Maxime Ripard wrote: > > I'm sorry but I'm not convinced a consumer driver should have all the > > details > > that are added in phy_configure_opts_mipi_dphy. > > If it can convince you, here is the parameters that are needed by all > the MIPI-DSI drivers currently in Linux to configure their PHY: > > - cdns-dsi (drivers/gpu/drm/bridge/cdns-dsi.c) > - hs_clk_rate > - lanes > - videomode > > - kirin (drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c) > - hs_exit > - hs_prepare > - hs_trail > - hs_zero > - lpx > - ta_get > - ta_go > - wakeup > > - msm (drivers/gpu/drm/msm/dsi/*) > - clk_post > - clk_pre > - clk_prepare > - clk_trail > - clk_zero > - hs_clk_rate > - hs_exit > - hs_prepare > - hs_trail > - hs_zero > - lp_clk_rate > - ta_get > - ta_go > - ta_sure > > - mtk (drivers/gpu/drm/mediatek/mtk_dsi.c) > - hs_clk_rate > - hs_exit > - hs_prepare > - hs_trail > - hs_zero > - lpx > > - sun4i (drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c) > - clk_post > - clk_pre > - clk_prepare > - clk_zero > - hs_prepare > - hs_trail > - lanes > - lp_clk_rate > > - tegra (drivers/gpu/drm/tegra/dsi.c) > - clk_post > - clk_pre > - clk_prepare > - clk_trail > - clk_zero > - hs_exit > - hs_prepare > - hs_trail > - hs_zero > - lpx > - ta_get > - ta_go > - ta_sure > > - vc4 (drivers/gpu/drm/vc4/vc4_dsi.c) > - hs_clk_rate > - lanes > > Now, for MIPI-CSI receivers: > > - marvell-ccic (drivers/media/platform/marvell-ccic/mcam-core.c) > - clk_term_en > - clk_settle > - d_term_en > - hs_settle > - lp_clk_rate > > - omap4iss (drivers/staging/media/omap4iss/iss_csiphy.c) > - clk_miss > - clk_settle > - clk_term > - hs_settle > - hs_term > - lanes > > - rcar-vin (drivers/media/platform/rcar-vin/rcar-csi2.c) > - hs_clk_rate > - lanes > > - ti-vpe (drivers/media/platform/ti-vpe/cal.c) > - clk_term_en > - d_term_en > - hs_settle > - hs_term > > So the timings expressed in the structure are the set of all the ones > currently used in the tree by DSI and CSI drivers. I would consider > that a good proof that it would be useful. > > Note that at least cdns-dsi, exynos4-is > (drivers/media/platform/exynos4-is/mipi-csis.c), kirin, sun4i, msm, > mtk, omap4iss, plus the v4l2 drivers cdns-csi2tx and cdns-csi2rx I > want to convert, have already either a driver for their DPHY using the > phy framework plus a configuration function, or a design very similar > that could be migrated to such an API. There's also a patch set currently being submitted that uses a phy driver + custom functions: https://lore.kernel.org/patchwork/cover/988959/ Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 10/18] drm/i915: Add the missing HDMI gamut metadata packet stuff
On Thu, Sep 20, 2018 at 09:51:37PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have definitions and low level code for everything except the gamut
> metadata HDMI packet. Add the missing bits.
>
> Signed-off-by: Ville Syrjälä
Online Bspec seems to have dropped pre-cpt/snb stuff, but I found some old
copies
still :-)
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 +++-
> drivers/gpu/drm/i915/intel_hdmi.c | 12
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4948b352bf4c..c07fd394ca1d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4577,6 +4577,7 @@ enum {
> #define VIDEO_DIP_ENABLE_SPD (8 << 21)
> #define VIDEO_DIP_SELECT_AVI (0 << 19)
> #define VIDEO_DIP_SELECT_VENDOR(1 << 19)
> +#define VIDEO_DIP_SELECT_GAMUT (2 << 19)
> #define VIDEO_DIP_SELECT_SPD (3 << 19)
> #define VIDEO_DIP_SELECT_MASK (3 << 19)
> #define VIDEO_DIP_FREQ_ONCE(0 << 16)
> @@ -7948,10 +7949,11 @@ enum {
> #define _ICL_VIDEO_DIP_PPS_ECC_B 0x613D4
>
> #define HSW_TVIDEO_DIP_CTL(trans)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_CTL_A)
> +#define HSW_TVIDEO_DIP_GCP(trans)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_GCP_A)
> #define HSW_TVIDEO_DIP_AVI_DATA(trans, i)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_AVI_DATA_A + (i) * 4)
> #define HSW_TVIDEO_DIP_VS_DATA(trans, i) _MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_VS_DATA_A + (i) * 4)
> #define HSW_TVIDEO_DIP_SPD_DATA(trans, i)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
> -#define HSW_TVIDEO_DIP_GCP(trans)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_GCP_A)
> +#define HSW_TVIDEO_DIP_GMP_DATA(trans, i)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
> #define HSW_TVIDEO_DIP_VSC_DATA(trans, i)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
> #define ICL_VIDEO_DIP_PPS_DATA(trans, i) _MMIO_TRANS2(trans,
> _ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
> #define ICL_VIDEO_DIP_PPS_ECC(trans, i) _MMIO_TRANS2(trans,
> _ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 454f570275e9..c3c2a638d062 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -83,6 +83,8 @@ static struct intel_hdmi *intel_attached_hdmi(struct
> drm_connector *connector)
> static u32 g4x_infoframe_index(unsigned int type)
> {
> switch (type) {
> + case HDMI_PACKET_TYPE_GAMUT_METADATA:
> + return VIDEO_DIP_SELECT_GAMUT;
> case HDMI_INFOFRAME_TYPE_AVI:
> return VIDEO_DIP_SELECT_AVI;
> case HDMI_INFOFRAME_TYPE_SPD:
> @@ -98,6 +100,10 @@ static u32 g4x_infoframe_index(unsigned int type)
> static u32 g4x_infoframe_enable(unsigned int type)
> {
> switch (type) {
> + case HDMI_PACKET_TYPE_GENERAL_CONTROL:
> + return VIDEO_DIP_ENABLE_GCP;
> + case HDMI_PACKET_TYPE_GAMUT_METADATA:
> + return VIDEO_DIP_ENABLE_GAMUT;
> case HDMI_INFOFRAME_TYPE_AVI:
> return VIDEO_DIP_ENABLE_AVI;
> case HDMI_INFOFRAME_TYPE_SPD:
> @@ -113,6 +119,10 @@ static u32 g4x_infoframe_enable(unsigned int type)
> static u32 hsw_infoframe_enable(unsigned int type)
> {
> switch (type) {
> + case HDMI_PACKET_TYPE_GENERAL_CONTROL:
> + return VIDEO_DIP_ENABLE_GCP_HSW;
> + case HDMI_PACKET_TYPE_GAMUT_METADATA:
> + return VIDEO_DIP_ENABLE_GMP_HSW;
> case DP_SDP_VSC:
> return VIDEO_DIP_ENABLE_VSC_HSW;
> case HDMI_INFOFRAME_TYPE_AVI:
> @@ -134,6 +144,8 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
>int i)
> {
> switch (type) {
> + case HDMI_PACKET_TYPE_GAMUT_METADATA:
> + return HSW_TVIDEO_DIP_GMP_DATA(cpu_transcoder, i);
> case DP_SDP_VSC:
> return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
> case HDMI_INFOFRAME_TYPE_AVI:
> --
> 2.16.4
>
> ___
> 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: [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
On 09/21/18 16:01, Ville Syrjälä wrote:
> On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
>> On 09/20/18 20:51, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> We'll be wanting to send more than just infoframes over HDMI. So add an
>>> enum for other packet types.
>>>
>>> TODO: Maybe just include the infoframe types in the packet type enum
>>> and get rid of the infoframe type enum?
>>
>> I think that's better, IMHO. With a comment that the types starting with
>> 0x81 are defined in CTA-861-G.
>>
>> It's really the same byte that is being checked, so having two enums is
>> a bit misleading. The main difference is really which standard defines
>> the packet types.
>
> Right. The only slight annoyance is that we'll get a bunch of warnings
> from the compiler if we don't handle all the enum valus in the switch
> statements. If we want to avoid that I guess I could limit this
> to just the null, gcp and gamut metadata packets initially and try to
> write some actual code for them. Those three are the only ones we
> care about in i915 at the moment.
Note that I don't have a terribly strong opinion on this, so if using
one enum instead of two causes more problems than it is worth, then
that's fine with me as well.
But you asked, and given a choice with all other things being equal,
then one enum has my preference.
Regards,
Hans
>
>>
>> Regards,
>>
>> Hans
>>
>>>
>>> Cc: Thierry Reding
>>> Cc: Hans Verkuil
>>> Cc: linux-me...@vger.kernel.org
>>> Signed-off-by: Ville Syrjälä
>>> ---
>>> include/linux/hdmi.h | 15 +++
>>> 1 file changed, 15 insertions(+)
>>>
>>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
>>> index c76b50a48e48..80521d9591a1 100644
>>> --- a/include/linux/hdmi.h
>>> +++ b/include/linux/hdmi.h
>>> @@ -27,6 +27,21 @@
>>> #include
>>> #include
>>>
>>> +enum hdmi_packet_type {
>>> + HDMI_PACKET_TYPE_NULL = 0x00,
>>> + HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
>>> + HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
>>> + HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
>>> + HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
>>> + HDMI_PACKET_TYPE_ISRC1 = 0x05,
>>> + HDMI_PACKET_TYPE_ISRC2 = 0x06,
>>> + HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
>>> + HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
>>> + HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
>>> + HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
>>> + /* + enum hdmi_infoframe_type */
>>> +};
>>> +
>>> enum hdmi_infoframe_type {
>>> HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
>>> HDMI_INFOFRAME_TYPE_AVI = 0x82,
>>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb_helper: Allow leaking fbdev smem_start
Hi, On Thu, Sep 20, 2018 at 03:04:12PM +0200, Neil Armstrong wrote: > Since "drm/fb: Stop leaking physical address", the default behaviour of > the DRM fbdev emulation is to set the smem_base to 0 and pass the new > FBINFO_HIDE_SMEM_START flag. > > The main reason is to avoid leaking physical addresse to user-space, and > it follows a general move over the kernel code to avoid user-space to > manipulate physical addresses and then use some other mechanisms like > dma-buf to transfer physical buffer handles over multiple subsystems. > > But, a lot of devices depends on closed sources binaries to enable > OpenGL hardware acceleration that uses this smem_start value to > pass physical addresses to out-of-tree modules in order to render > into these physical adresses. These should use dma-buf buffers allocated > from the DRM display device instead and stop relying on fbdev overallocation > to gather DMA memory (some HW vendors delivers GBM and Wayland capable > binaries, but older unsupported devices won't have these new binaries > and are doomed until an Open Source solution like Lima finalizes). > > Since these devices heavily depends on this kind of software and because > the smem_start population was available for years, it's a breakage to > stop leaking smem_start without any alternative solutions. > > This patch adds a Kconfig depending on the EXPERT config and an unsafe > kernel module parameter tainting the kernel when enabled. > > A clear comment and Kconfig help text was added to clarify why and when > this patch should be reverted, but in the meantime it's a necessary > feature to keep. > > Cc: Dave Airlie > Cc: Daniel Vetter > Cc: Bartlomiej Zolnierkiewicz > Cc: Noralf Trønnes > Cc: Maxime Ripard > Cc: Eric Anholt > Cc: Lucas Stach > Cc: Rob Clark > Cc: Ben Skeggs > Cc: Christian König > Signed-off-by: Neil Armstrong > --- > drivers/gpu/drm/Kconfig | 15 +++ > drivers/gpu/drm/drm_fb_helper.c | 33 +++-- > 2 files changed, 46 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 8871b3f..b07c298 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -110,6 +110,21 @@ config DRM_FBDEV_OVERALLOC > is 100. Typical values for double buffering will be 200, > triple buffering 300. > > +config DRM_FBDEV_LEAK_PHYS_SMEM > + bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)" > + depends on DRM_FBDEV_EMULATION && EXPERT > + default n > + help > + In order to keep user-space compatibility, we want in certain > + use-cases to keep leaking the fbdev physical address to the > + user-space program handling the fbdev buffer. > + This option is a shame and should be removed as soon as possible > + and be considered as a broken and legacy behaviour from a modern > + fbdev device driver. > + > + If in doubt, say "N" or spread the word to your closed source > + library vendor. > + > config DRM_LOAD_EDID_FIRMWARE > bool "Allow to specify an EDID data set instead of probing for it" > depends on DRM > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index bf2190c..a354944 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -56,6 +56,25 @@ MODULE_PARM_DESC(drm_fbdev_overalloc, >"Overallocation of the fbdev buffer (%) [default=" >__MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]"); > > +/* > + * In order to keep user-space compatibility, we want in certain use-cases > + * to keep leaking the fbdev physical address to the user-space program > + * handling the fbdev buffer. > + * This is a bad habit essentially kept into closed source opengl driver > + * that should really be moved into open-source upstream projects instead > + * of using legacy physical addresses in user space to communicate with > + * other out-of-tree kernel modules. > + * > + * This module_param *should* be removed as soon as possible and be > + * considered as a broken and legacy behaviour from a modern fbdev device. > + */ > +#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM) > +static bool drm_leak_fbdev_smem = false; > +module_param_unsafe(drm_leak_fbdev_smem, bool, 0600); > +MODULE_PARM_DESC(fbdev_emulation, > + "Allow unsafe leaking fbdev physical smem address > [default=false]"); > +#endif > + > static LIST_HEAD(kernel_fb_helper_list); > static DEFINE_MUTEX(kernel_fb_helper_lock); > > @@ -2673,8 +2692,12 @@ __drm_fb_helper_initial_config_and_unlock(struct > drm_fb_helper *fb_helper, > > info = fb_helper->fbdev; > info->var.pixclock = 0; > - /* don't leak any physical addresses to userspace */ > - info->flags |= FBINFO_HIDE_SMEM_START; > + /* Shamelessly allow physical address leaking to userspace */ > +#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM) > +
Re: [PATCH v4 5/5] drm: bridge: add support for Cadence MHDP DPI/DP bridge
On Thu, Sep 20, 2018 at 03:54:40PM +0100, Damian Kos wrote:
> From: Quentin Schulz
>
> This adds basic support for Cadence MHDP DPI to DP bridge.
>
> Basically, it takes a DPI stream as input and output it encoded in DP
> format. It's missing proper HPD, HDCP and currently supports only
> SST mode.
>
> Changes made in the low level driver (cdn-dp-reg.*):
> - moved it to from drivers/gpu/drm/rockchip to
> drivers/gpu/drm/bridge/cdns-mhdp-common.*
> - functions for sending/receiving commands are now public
> - added functions for reading registers and link training
> adjustment
>
> Changes made in RK's driver (cdn-dp-core.*):
> - Moved audio_info and audio_pdev fields from cdn_dp_device to
> cdns_mhdp_device structure.
>
> Signed-off-by: Quentin Schulz
> Signed-off-by: Damian Kos
> ---
> drivers/gpu/drm/bridge/Kconfig|9 +
> drivers/gpu/drm/bridge/Makefile |3 +
> .../cdns-mhdp-common.c} | 137 +-
> .../cdns-mhdp-common.h} | 21 +-
> drivers/gpu/drm/bridge/cdns-mhdp.c| 1308 +
> drivers/gpu/drm/rockchip/Kconfig |4 +-
> drivers/gpu/drm/rockchip/Makefile |4 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c| 16 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h|4 +-
> 9 files changed, 1486 insertions(+), 20 deletions(-)
> rename drivers/gpu/drm/{rockchip/cdn-dp-reg.c => bridge/cdns-mhdp-common.c}
> (87%)
> rename drivers/gpu/drm/{rockchip/cdn-dp-reg.h => bridge/cdns-mhdp-common.h}
> (95%)
> create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 9eeb8ef0b174..90a4810a8c96 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -35,6 +35,15 @@ config DRM_CDNS_DSI
> Support Cadence DPI to DSI bridge. This is an internal
> bridge and is meant to be directly embedded in a SoC.
>
> +config DRM_CDNS_MHDP
> + tristate "Cadence DPI/DP bridge"
> + select DRM_KMS_HELPER
> + select DRM_PANEL_BRIDGE
> + depends on OF
> + help
> + Support Cadence DPI to DP bridge. This is an internal
> + bridge and is meant to be directly embedded in a SoC.
> +
> config DRM_DUMB_VGA_DAC
> tristate "Dumb VGA DAC Bridge support"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf5a6f8..e802fdb85750 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -16,4 +16,7 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-$(CONFIG_DRM_CDNS_MHDP) += mhdp8546.o
> obj-y += synopsys/
> +
> +mhdp8546-objs := cdns-mhdp-common.o cdns-mhdp.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
> similarity index 87%
> rename from drivers/gpu/drm/rockchip/cdn-dp-reg.c
> rename to drivers/gpu/drm/bridge/cdns-mhdp-common.c
> index c1a76e6fff88..88cb248b9de4 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
> @@ -19,8 +19,10 @@
> #include
> #include
>
> -#include "cdn-dp-core.h"
> -#include "cdn-dp-reg.h"
> +#include
> +#include
> +
> +#include "cdns-mhdp-common.h"
>
> #define CDNS_DP_SPDIF_CLK2
> #define FW_ALIVE_TIMEOUT_US 100
> @@ -33,6 +35,7 @@ void cdns_mhdp_set_fw_clk(struct cdns_mhdp_device *mhdp,
> unsigned long clk)
> {
> writel(clk / 100, mhdp->regs + SW_CLK_H);
> }
> +EXPORT_SYMBOL(cdns_mhdp_set_fw_clk);
>
> void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
> {
> @@ -82,6 +85,7 @@ void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
> /* enable Mailbox and PIF interrupt */
> writel(0, mhdp->regs + APB_INT_MASK);
> }
> +EXPORT_SYMBOL(cdns_mhdp_clock_reset);
>
> static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
> {
> @@ -189,7 +193,56 @@ static int cdns_mhdp_mailbox_send(struct
> cdns_mhdp_device *mhdp, u8 module_id,
> return 0;
> }
>
> -static int cdns_mhdp_reg_write(struct cdns_mhdp_device *mhdp, u16 addr, u32
> val)
> +int cdns_mhdp_reg_read(struct cdns_mhdp_device *mhdp, u32 addr, u32 *value)
> +{
> + u8 msg[4], resp[8];
> + int ret;
> +
> + if (addr == 0) {
> + ret = -EINVAL;
> + goto err_reg_read;
> + }
> +
> + msg[0] = (u8)(addr >> 24);
> + msg[1] = (u8)(addr >> 16);
> + msg[2] = (u8)(addr >> 8);
> + msg[3] = (u8)addr;
> +
> + ret = cdns_mhdp_mailbox_send(mhdp, MB_MODULE_ID_GENERAL,
> + GENERAL_REGISTER_READ,
> + sizeof(msg), msg);
> + if (ret)
> + goto err_reg_read;
> +
> + ret =
Re: [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We'll be wanting to send more than just infoframes over HDMI. So add an
> > enum for other packet types.
> >
> > TODO: Maybe just include the infoframe types in the packet type enum
> > and get rid of the infoframe type enum?
>
> I think that's better, IMHO. With a comment that the types starting with
> 0x81 are defined in CTA-861-G.
>
> It's really the same byte that is being checked, so having two enums is
> a bit misleading. The main difference is really which standard defines
> the packet types.
Right. The only slight annoyance is that we'll get a bunch of warnings
from the compiler if we don't handle all the enum valus in the switch
statements. If we want to avoid that I guess I could limit this
to just the null, gcp and gamut metadata packets initially and try to
write some actual code for them. Those three are the only ones we
care about in i915 at the moment.
>
> Regards,
>
> Hans
>
> >
> > Cc: Thierry Reding
> > Cc: Hans Verkuil
> > Cc: linux-me...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > include/linux/hdmi.h | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> > index c76b50a48e48..80521d9591a1 100644
> > --- a/include/linux/hdmi.h
> > +++ b/include/linux/hdmi.h
> > @@ -27,6 +27,21 @@
> > #include
> > #include
> >
> > +enum hdmi_packet_type {
> > + HDMI_PACKET_TYPE_NULL = 0x00,
> > + HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
> > + HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
> > + HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
> > + HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
> > + HDMI_PACKET_TYPE_ISRC1 = 0x05,
> > + HDMI_PACKET_TYPE_ISRC2 = 0x06,
> > + HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
> > + HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
> > + HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
> > + HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
> > + /* + enum hdmi_infoframe_type */
> > +};
> > +
> > enum hdmi_infoframe_type {
> > HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
> > HDMI_INFOFRAME_TYPE_AVI = 0x82,
> >
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/18] drm/i915: Pass intel_encoder to infoframe functions
On Thu, Sep 20, 2018 at 09:51:36PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make life simpler by passing around intel_encoder instead of
> drm_encoder.
>
> @r1@
> identifier F =~ "infoframe";
> identifier I, M;
> @@
> F(
> - struct drm_encoder *I
> + struct intel_encoder *I
> , ...)
> {
> <...
> (
> - I->M
> + I->base.M
> |
> - I
> + >base
> )
> ...>
> }
>
> @r2@
> identifier F =~ "infoframe";
> identifier I;
> type T, ST;
> @@
> ST {
> ...
> T (*F)(
> -struct drm_encoder *I
> +struct intel_encoder *encoder
> , ...);
> ...
> };
>
> @@
> identifier r1.F;
> expression E;
> @@
> F(
> - E
> + to_intel_encoder(E)
> ,...)
>
> @@
> identifier r2.F;
> expression E, X;
> @@
> (
> X.F(
> - E
> + to_intel_encoder(E)
> ,...)
> |
> X->F(
> -E
> +to_intel_encoder(E)
> ,...)
> )
>
> @@
> expression E;
> @@
> (
> - to_intel_encoder(>base)
> + E
> |
> - to_intel_encoder(>base.base)
> + >base
> )
>
> @@
> identifier D, M;
> expression E;
> @@
> D = enc_to_dig_port(>base)
> <...
> (
> - D->base.M
> + E->M
> |
> - >base
> + E
> )
> ...>
>
> @@
> identifier D;
> expression E;
> type T;
> @@
> - T D = enc_to_dig_port(E);
> ... when != D
Someone knows a lot more cocci than I do, impressive. How do you figure
this stuff out? Read the source?
Also seems to have some manual fixups below, so I just looked at the diff.
That looks fine.
Acked-by: Daniel Vetter
I'll trust the compiler more here :-)
Cheers, Daniel
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +-
> drivers/gpu/drm/i915/intel_drv.h | 6 +-
> drivers/gpu/drm/i915/intel_hdmi.c | 129
> +++---
> drivers/gpu/drm/i915/intel_psr.c | 3 +-
> 4 files changed, 71 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b6910c8b4e08..086e3f940586 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2947,7 +2947,7 @@ static void intel_ddi_pre_enable_hdmi(struct
> intel_encoder *encoder,
>
> intel_ddi_enable_pipe_clock(crtc_state);
>
> - intel_dig_port->set_infoframes(>base,
> + intel_dig_port->set_infoframes(encoder,
> crtc_state->has_infoframe,
> crtc_state, conn_state);
> }
> @@ -3046,7 +3046,7 @@ static void intel_ddi_post_disable_hdmi(struct
> intel_encoder *encoder,
> struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> struct intel_hdmi *intel_hdmi = _port->hdmi;
>
> - dig_port->set_infoframes(>base, false,
> + dig_port->set_infoframes(encoder, false,
>old_crtc_state, old_conn_state);
>
> intel_ddi_disable_pipe_clock(old_crtc_state);
> @@ -3390,7 +3390,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
> pipe_config->has_hdmi_sink = true;
> intel_dig_port = enc_to_dig_port(>base);
>
> - if (intel_dig_port->infoframe_enabled(>base,
> pipe_config))
> + if (intel_dig_port->infoframe_enabled(encoder, pipe_config))
> pipe_config->has_infoframe = true;
>
> if ((temp & TRANS_DDI_HDMI_SCRAMBLING_MASK) ==
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index bf1c38728a59..e0f3a79fc75e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1173,15 +1173,15 @@ struct intel_digital_port {
> enum intel_display_power_domain ddi_io_power_domain;
> enum tc_port_type tc_type;
>
> - void (*write_infoframe)(struct drm_encoder *encoder,
> + void (*write_infoframe)(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state,
> unsigned int type,
> const void *frame, ssize_t len);
> - void (*set_infoframes)(struct drm_encoder *encoder,
> + void (*set_infoframes)(struct intel_encoder *encoder,
> bool enable,
> const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state);
> - bool (*infoframe_enabled)(struct drm_encoder *encoder,
> + bool (*infoframe_enabled)(struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config);
> };
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 3b56ab253171..454f570275e9 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -148,14 +148,13 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
> }
> }
>
> -static void g4x_write_infoframe(struct drm_encoder *encoder,
> +static void g4x_write_infoframe(struct intel_encoder *encoder,
>
Re: [PATCH 07/18] video/hdmi: Handle the NTSC VBI infoframe
On Fri, Sep 21, 2018 at 10:30:16AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add the code to deal with the NTSC VBI infoframe.
> >
> > I decided against parsing the PES_data_field and just leave
> > it as an opaque blob, just dumping it out as hex in the log.
> >
> > Blindly typed from the spec, and totally untested.
>
> Do we have any driver that uses this? I would prefer to wait until someone
> actually need this.
No users that I know of. So totally fine with me to leave it out.
>
> Regards,
>
> Hans
>
> >
> > Cc: Thierry Reding
> > Cc: Hans Verkuil
> > Cc: linux-me...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/video/hdmi.c | 208
> > +++
> > include/linux/hdmi.h | 18 +
> > 2 files changed, 226 insertions(+)
> >
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 3d24c7746c51..3c320d69fa0a 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -831,6 +831,139 @@ ssize_t hdmi_mpeg_source_infoframe_pack(struct
> > hdmi_mpeg_source_infoframe *frame
> > }
> > EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack);
> >
> > +/**
> > + * hdmi_ntsc_vbi_infoframe_init() - initialize an HDMI NTSC VBI infoframe
> > + * @frame: HDMI NTSC VBI infoframe
> > + * @pes_data_field: ANSI/SCTE 127 PES_data_field
> > + * @length: ANSI/SCTE 127 PES_data_field length
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_ntsc_vbi_infoframe_init(struct hdmi_ntsc_vbi_infoframe *frame,
> > +const void *pes_data_field,
> > +size_t length)
> > +{
> > + if (length < 1 || length > 27)
> > + return -EINVAL;
> > +
> > + memset(frame, 0, sizeof(*frame));
> > +
> > + frame->type = HDMI_INFOFRAME_TYPE_NTSC_VBI;
> > + frame->version = 1;
> > + frame->length = length;
> > +
> > + memcpy(frame->pes_data_field, pes_data_field, length);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_init);
> > +
> > +static int hdmi_ntsc_vbi_infoframe_check_only(const struct
> > hdmi_ntsc_vbi_infoframe *frame)
> > +{
> > + if (frame->type != HDMI_INFOFRAME_TYPE_NTSC_VBI ||
> > + frame->version != 1 ||
> > + frame->length < 1 || frame->length > 27)
> > + return -EINVAL;
> > +
> > + if (frame->pes_data_field[0] != 0x99)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * hdmi_ntsc_vbi_infoframe_check() - Check and check a HDMI NTSC VBI
> > infoframe
> > + * @frame: HDMI NTSC VBI infoframe
> > + *
> > + * Validates that the infoframe is consistent and updates derived fields
> > + * (eg. length) based on other fields.
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_ntsc_vbi_infoframe_check(struct hdmi_ntsc_vbi_infoframe *frame)
> > +{
> > + return hdmi_ntsc_vbi_infoframe_check_only(frame);
> > +}
> > +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_check);
> > +
> > +/**
> > + * hdmi_ntsc_vbi_infoframe_pack_only() - write HDMI NTSC VBI infoframe to
> > binary buffer
> > + * @frame: HDMI NTSC VBI infoframe
> > + * @buffer: destination buffer
> > + * @size: size of buffer
> > + *
> > + * Packs the information contained in the @frame structure into a binary
> > + * representation that can be written into the corresponding controller
> > + * registers. Also computes the checksum as required by section 5.3.5 of
> > + * the HDMI 1.4 specification.
> > + *
> > + * Returns the number of bytes packed into the binary buffer or a negative
> > + * error code on failure.
> > + */
> > +ssize_t hdmi_ntsc_vbi_infoframe_pack_only(const struct
> > hdmi_ntsc_vbi_infoframe *frame,
> > + void *buffer, size_t size)
> > +{
> > + u8 *ptr = buffer;
> > + size_t length;
> > + int ret;
> > +
> > + ret = hdmi_ntsc_vbi_infoframe_check_only(frame);
> > + if (ret)
> > + return ret;
> > +
> > + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> > +
> > + if (size < length)
> > + return -ENOSPC;
> > +
> > + memset(buffer, 0, size);
> > +
> > + ptr[0] = frame->type;
> > + ptr[1] = frame->version;
> > + ptr[2] = frame->length;
> > + ptr[3] = 0; /* checksum */
> > +
> > + /* start infoframe payload */
> > + ptr += HDMI_INFOFRAME_HEADER_SIZE;
> > +
> > + memcpy(ptr, frame->pes_data_field, frame->length);
> > +
> > + hdmi_infoframe_set_checksum(buffer, length);
> > +
> > + return length;
> > +}
> > +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_pack_only);
> > +
> > +/**
> > + * hdmi_ntsc_vbi_infoframe_pack() - Check and check a HDMI NTSC VBI
> > infoframe,
> > + * and write it to binary buffer
> > + * @frame: HDMI NTSC VBI infoframe
> > + * @buffer: destination buffer
> > + * @size: size of buffer
> > + *
> > + * Validates that the
Re: [PATCH 06/18] video/hdmi: Handle the MPEG Source infoframe
On Fri, Sep 21, 2018 at 10:28:09AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add the code to deal with the MPEG source infoframe.
> >
> > Blindly typed from the spec, and totally untested.
>
> I'm not sure this patch should be added at all. The CTA-861-G spec (section
> 6.7)
> says that the implementation of this infoframe is not recommended due to
> unresolved
> issues.
>
> I don't think I've ever seen it either.
>
> It obviously doesn't hurt to have this code, but I prefer to wait until there
> are devices that actively set/use this infoframe.
Sure. I'm totally fine with leaving it out. Just figured I'd send it out
in case anyone has some use for it.
>
> Regards,
>
> Hans
>
> >
> > Cc: Thierry Reding
> > Cc: Hans Verkuil
> > Cc: linux-me...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/video/hdmi.c | 229
> > +++
> > include/linux/hdmi.h | 27 ++
> > 2 files changed, 256 insertions(+)
> >
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 9507f668a569..3d24c7746c51 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -706,6 +706,131 @@ hdmi_vendor_any_infoframe_pack(union
> > hdmi_vendor_any_infoframe *frame,
> > return hdmi_vendor_any_infoframe_pack_only(frame, buffer, size);
> > }
> >
> > +/**
> > + * hdmi_mpeg_source_infoframe_init() - initialize an HDMI MPEG Source
> > infoframe
> > + * @frame: HDMI MPEG Source infoframe
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_mpeg_source_infoframe_init(struct hdmi_mpeg_source_infoframe
> > *frame)
> > +{
> > + memset(frame, 0, sizeof(*frame));
> > +
> > + frame->type = HDMI_INFOFRAME_TYPE_MPEG_SOURCE;
> > + frame->version = 1;
> > + frame->length = HDMI_MPEG_SOURCE_INFOFRAME_SIZE;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_init);
> > +
> > +static int hdmi_mpeg_source_infoframe_check_only(const struct
> > hdmi_mpeg_source_infoframe *frame)
> > +{
> > + if (frame->type != HDMI_INFOFRAME_TYPE_MPEG_SOURCE ||
> > + frame->version != 1 ||
> > + frame->length != HDMI_MPEG_SOURCE_INFOFRAME_SIZE)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * hdmi_mpeg_source_infoframe_check() - Check and check a HDMI MPEG Source
> > infoframe
> > + * @frame: HDMI MPEG Source infoframe
> > + *
> > + * Validates that the infoframe is consistent and updates derived fields
> > + * (eg. length) based on other fields.
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_mpeg_source_infoframe_check(struct hdmi_mpeg_source_infoframe
> > *frame)
> > +{
> > + return hdmi_mpeg_source_infoframe_check_only(frame);
> > +}
> > +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_check);
> > +
> > +/**
> > + * hdmi_mpeg_source_infoframe_pack_only() - write HDMI MPEG Source
> > infoframe to binary buffer
> > + * @frame: HDMI MPEG Source infoframe
> > + * @buffer: destination buffer
> > + * @size: size of buffer
> > + *
> > + * Packs the information contained in the @frame structure into a binary
> > + * representation that can be written into the corresponding controller
> > + * registers. Also computes the checksum as required by section 5.3.5 of
> > + * the HDMI 1.4 specification.
> > + *
> > + * Returns the number of bytes packed into the binary buffer or a negative
> > + * error code on failure.
> > + */
> > +ssize_t hdmi_mpeg_source_infoframe_pack_only(const struct
> > hdmi_mpeg_source_infoframe *frame,
> > +void *buffer, size_t size)
> > +{
> > + u8 *ptr = buffer;
> > + size_t length;
> > + int ret;
> > +
> > + ret = hdmi_mpeg_source_infoframe_check_only(frame);
> > + if (ret)
> > + return ret;
> > +
> > + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> > +
> > + if (size < length)
> > + return -ENOSPC;
> > +
> > + memset(buffer, 0, size);
> > +
> > + ptr[0] = frame->type;
> > + ptr[1] = frame->version;
> > + ptr[2] = frame->length;
> > + ptr[3] = 0; /* checksum */
> > +
> > + /* start infoframe payload */
> > + ptr += HDMI_INFOFRAME_HEADER_SIZE;
> > +
> > + ptr[0] = frame->mpeg_bit_rate >> 0;
> > + ptr[1] = frame->mpeg_bit_rate >> 8;
> > + ptr[2] = frame->mpeg_bit_rate >> 16;
> > + ptr[3] = frame->mpeg_bit_rate >> 24;
> > + ptr[4] = (frame->field_repeat << 4) | frame->mpeg_frame;
> > +
> > + hdmi_infoframe_set_checksum(buffer, length);
> > +
> > + return length;
> > +}
> > +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack_only);
> > +
> > +/**
> > + * hdmi_mpeg_source_infoframe_pack() - Check and check a HDMI MPEG Source
> > infoframe,
> > + * and write it to binary buffer
> > + * @frame: HDMI MPEG Source infoframe
> > + * @buffer: destination buffer
> > + *
Re: [Intel-gfx] [PATCH 08/18] drm/i915: Use memmove() for punching the hole into infoframes
On Thu, Sep 20, 2018 at 09:51:35PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Replace the hand rolled memmove() with the real thing. > > Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_hdmi.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index a2dab0b6bde6..3b56ab253171 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -457,9 +457,7 @@ static void intel_write_infoframe(struct drm_encoder > *encoder, > return; > > /* Insert the 'hole' (see big comment above) at position 3 */ > - buffer[0] = buffer[1]; > - buffer[1] = buffer[2]; > - buffer[2] = buffer[3]; > + memmove([0], [1], 3); > buffer[3] = 0; > len++; > > -- > 2.16.4 > > ___ > 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
[PATCH v4 5/6] drm/virtio: fix DRM_FORMAT_* handling
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a different mapping on bigendian machines is wrong.
It's there because of broken drm_mode_addfb() behavior. So with
drm_mode_addfb() being fixed we can fix this too.
While wading through the code I've noticed we have a little issue in
virtio: We attach a format to the bo when it is created
(DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer
(DRM_IOCTL_MODE_ADDFB). Easy way out: Support a single format only.
Pick DRM_FORMAT_HOST_XRGB, it is the only one actually used in
practice. Drop unused mappings in virtio_gpu_translate_format().
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the virtio-gpu.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++
drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_gem.c | 7 +++--
drivers/gpu/drm/virtio/virtgpu_plane.c | 54 ++--
4 files changed, 13 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 0379d68976..8f8fed471e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -307,6 +307,10 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
struct virtio_gpu_framebuffer *virtio_gpu_fb;
int ret;
+ if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB &&
+ mode_cmd->pixel_format != DRM_FORMAT_HOST_ARGB)
+ return ERR_PTR(-ENOENT);
+
/* lookup object associated with res handle */
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
if (!obj)
@@ -355,6 +359,7 @@ int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev)
int i;
drm_mode_config_init(vgdev->ddev);
+ vgdev->ddev->mode_config.quirk_addfb_prefer_host_byte_order = true;
vgdev->ddev->mode_config.funcs = _gpu_mode_funcs;
vgdev->ddev->mode_config.helper_private = _mode_config_helpers;
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c
b/drivers/gpu/drm/virtio/virtgpu_fb.c
index b9678c4082..abc4ec4c62 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -226,7 +226,7 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
mode_cmd.pitches[0] = mode_cmd.width * 4;
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(32, 24);
+ mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
format = virtio_gpu_translate_format(mode_cmd.pixel_format);
if (format == 0)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 0f2768eaca..82c817f37c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -90,7 +90,10 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
uint32_t resid;
uint32_t format;
- pitch = args->width * ((args->bpp + 1) / 8);
+ if (args->bpp != 32)
+ return -EINVAL;
+
+ pitch = args->width * 4;
args->size = pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
@@ -99,7 +102,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
if (ret)
goto fail;
- format = virtio_gpu_translate_format(DRM_FORMAT_XRGB);
+ format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB);
virtio_gpu_resource_id_get(vgdev, );
virtio_gpu_cmd_create_resource(vgdev, resid, format,
args->width, args->height);
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 88f2fb8c61..a84ff56507 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -28,22 +28,11 @@
#include
static const uint32_t virtio_gpu_formats[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_BGRX,
- DRM_FORMAT_BGRA,
- DRM_FORMAT_RGBX,
- DRM_FORMAT_RGBA,
- DRM_FORMAT_XBGR,
- DRM_FORMAT_ABGR,
+ DRM_FORMAT_HOST_XRGB,
};
static const uint32_t virtio_gpu_cursor_formats[] = {
-#ifdef __BIG_ENDIAN
- DRM_FORMAT_BGRA,
-#else
- DRM_FORMAT_ARGB,
-#endif
+ DRM_FORMAT_HOST_ARGB,
};
uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc)
@@ -51,32 +40,6 @@
[PATCH v4 3/6] drm/bochs: fix DRM_FORMAT_* handling for big endian machines.
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the default created by drm_crtc_init(). That way the plane
format list is correct on bigendian machines.
Also re-add the framebuffer format check dropped by "df2052cc92 bochs:
convert to drm_fb_helper_fbdev_setup/teardown".
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the bochs-drm.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_fbdev.c | 17 +
drivers/gpu/drm/bochs/bochs_kms.c | 34 +-
2 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 8f4d6c052f..c46fdae44e 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -63,9 +63,8 @@ static int bochsfb_create(struct drm_fb_helper *helper,
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
- mode_cmd.pitches[0] = mode_cmd.width * ((sizes->surface_bpp + 7) / 8);
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
- sizes->surface_depth);
+ mode_cmd.pitches[0] = sizes->surface_width * 4;
+ mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
size = mode_cmd.pitches[0] * mode_cmd.height;
/* alloc, pin & map bo */
@@ -137,8 +136,18 @@ static const struct drm_fb_helper_funcs
bochs_fb_helper_funcs = {
.fb_probe = bochsfb_create,
};
+static struct drm_framebuffer *
+bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB)
+ return ERR_PTR(-EINVAL);
+
+ return drm_gem_fb_create(dev, file, mode_cmd);
+}
+
const struct drm_mode_config_funcs bochs_mode_funcs = {
- .fb_create = drm_gem_fb_create,
+ .fb_create = bochs_gem_fb_create,
};
int bochs_fbdev_init(struct bochs_device *bochs)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index ea9a43d31b..f3fdaf9456 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -126,12 +126,43 @@ static const struct drm_crtc_helper_funcs
bochs_helper_funcs = {
.commit = bochs_crtc_commit,
};
+static const uint32_t bochs_formats[] = {
+ DRM_FORMAT_HOST_XRGB,
+};
+
+static struct drm_plane *bochs_primary_plane(struct drm_device *dev)
+{
+ struct drm_plane *primary;
+ int ret;
+
+ primary = kzalloc(sizeof(*primary), GFP_KERNEL);
+ if (primary == NULL) {
+ DRM_DEBUG_KMS("Failed to allocate primary plane\n");
+ return NULL;
+ }
+
+ ret = drm_universal_plane_init(dev, primary, 0,
+ _primary_helper_funcs,
+ bochs_formats,
+ ARRAY_SIZE(bochs_formats),
+ NULL,
+ DRM_PLANE_TYPE_PRIMARY, NULL);
+ if (ret) {
+ kfree(primary);
+ primary = NULL;
+ }
+
+ return primary;
+}
+
static void bochs_crtc_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
struct drm_crtc *crtc = >crtc;
+ struct drm_plane *primary = bochs_primary_plane(dev);
- drm_crtc_init(dev, crtc, _crtc_funcs);
+ drm_crtc_init_with_planes(dev, crtc, primary, NULL,
+ _crtc_funcs, NULL);
drm_crtc_helper_add(crtc, _helper_funcs);
}
@@ -250,6 +281,7 @@ int bochs_kms_init(struct bochs_device *bochs)
bochs->dev->mode_config.fb_base = bochs->fb_base;
bochs->dev->mode_config.preferred_depth = 24;
bochs->dev->mode_config.prefer_shadow = 0;
+ bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
bochs->dev->mode_config.funcs = _mode_funcs;
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/6] drm: use drm_driver_legacy_fb_format in drm_gem_fbdev_fb_create
Creating framebuffers for fbdev emulation should use the correct format code too, so switch drm_gem_fbdev_fb_create() over to use the new drm_driver_legacy_fb_format() function. Signed-off-by: Gerd Hoffmann Acked-by: Daniel Vetter --- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c b/drivers/gpu/drm/drm_gem_framebuffer_helper.c index 7607f9cd6f..ded7a379ac 100644 --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c @@ -316,8 +316,8 @@ drm_gem_fbdev_fb_create(struct drm_device *dev, if (pitch_align) mode_cmd.pitches[0] = roundup(mode_cmd.pitches[0], pitch_align); - mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, - sizes->surface_depth); + mode_cmd.pixel_format = drm_driver_legacy_fb_format(dev, sizes->surface_bpp, + sizes->surface_depth); if (obj->size < mode_cmd.pitches[0] * mode_cmd.height) return ERR_PTR(-EINVAL); -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/6] drm: move native byte order quirk to new drm_driver_legacy_fb_format function
Turns out we need the pixel format fixup not only for the addfb ioctl,
but also for fbdev emulation code.
Ideally we would place it in drm_mode_legacy_fb_format(). That would
create alot of churn though, and most drivers don't care because they
never ever run on a big endian platform. So add a new
drm_driver_legacy_fb_format() function instead which looks at the
mode_config->quirk_addfb_prefer_host_byte_order flag.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
include/drm/drm_fourcc.h | 2 ++
drivers/gpu/drm/drm_fourcc.c | 30 ++
drivers/gpu/drm/drm_framebuffer.c | 13 +
3 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index fac831c401..865ef60c17 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -88,6 +88,8 @@ const struct drm_format_info *
drm_get_format_info(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd);
uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
+uint32_t drm_driver_legacy_fb_format(struct drm_device *dev,
+uint32_t bpp, uint32_t depth);
int drm_format_num_planes(uint32_t format);
int drm_format_plane_cpp(uint32_t format, int plane);
int drm_format_horz_chroma_subsampling(uint32_t format);
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index be1d6aaef6..7c6d3922ed 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -96,6 +96,36 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t
depth)
EXPORT_SYMBOL(drm_mode_legacy_fb_format);
/**
+ * drm_driver_legacy_fb_format - compute drm fourcc code from legacy
description
+ * @bpp: bits per pixels
+ * @depth: bit depth per pixel
+ * @native: use host native byte order
+ *
+ * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
+ * Unlike drm_mode_legacy_fb_format() this looks at the drivers mode_config,
+ * and depending on the quirk_addfb_prefer_host_byte_order flag it returns
+ * little endian byte order or host byte order framebuffer formats.
+ */
+uint32_t drm_driver_legacy_fb_format(struct drm_device *dev,
+uint32_t bpp, uint32_t depth)
+{
+ uint32_t fmt = drm_mode_legacy_fb_format(bpp, depth);
+
+ if (dev->mode_config.quirk_addfb_prefer_host_byte_order) {
+ if (fmt == DRM_FORMAT_XRGB)
+ fmt = DRM_FORMAT_HOST_XRGB;
+ if (fmt == DRM_FORMAT_ARGB)
+ fmt = DRM_FORMAT_HOST_ARGB;
+ if (fmt == DRM_FORMAT_RGB565)
+ fmt = DRM_FORMAT_HOST_RGB565;
+ if (fmt == DRM_FORMAT_XRGB1555)
+ fmt = DRM_FORMAT_HOST_XRGB1555;
+ }
+ return fmt;
+}
+EXPORT_SYMBOL(drm_driver_legacy_fb_format);
+
+/**
* drm_get_format_name - fill a string with a drm fourcc format's name
* @format: format to compute name of
* @buf: caller-supplied buffer
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 1ee3d6b442..1e2126101c 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -116,7 +116,7 @@ int drm_mode_addfb(struct drm_device *dev, struct
drm_mode_fb_cmd *or,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
- r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
+ r.pixel_format = drm_driver_legacy_fb_format(dev, or->bpp, or->depth);
if (r.pixel_format == DRM_FORMAT_INVALID) {
DRM_DEBUG("bad {bpp:%d, depth:%d}\n", or->bpp, or->depth);
return -EINVAL;
@@ -133,17 +133,6 @@ int drm_mode_addfb(struct drm_device *dev, struct
drm_mode_fb_cmd *or,
r.pixel_format == DRM_FORMAT_XRGB2101010)
r.pixel_format = DRM_FORMAT_XBGR2101010;
- if (dev->mode_config.quirk_addfb_prefer_host_byte_order) {
- if (r.pixel_format == DRM_FORMAT_XRGB)
- r.pixel_format = DRM_FORMAT_HOST_XRGB;
- if (r.pixel_format == DRM_FORMAT_ARGB)
- r.pixel_format = DRM_FORMAT_HOST_ARGB;
- if (r.pixel_format == DRM_FORMAT_RGB565)
- r.pixel_format = DRM_FORMAT_HOST_RGB565;
- if (r.pixel_format == DRM_FORMAT_XRGB1555)
- r.pixel_format = DRM_FORMAT_HOST_XRGB1555;
- }
-
ret = drm_mode_addfb2(dev, , file_priv);
if (ret)
return ret;
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/6] drm/bochs: support changing byteorder at mode set time
Add bochs_hw_set_*_endian() helper functions, to set the framebuffer
byteorder at mode set time. Support both DRM_FORMAT_XRGB and
DRM_FORMAT_BGRX framebuffer formats, no matter what the native
machine byte order is.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs.h | 4 ++-
drivers/gpu/drm/bochs/bochs_fbdev.c | 3 +-
drivers/gpu/drm/bochs/bochs_hw.c| 64 +
drivers/gpu/drm/bochs/bochs_kms.c | 8 +++--
4 files changed, 61 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index b4f6bb5219..e7a69077e4 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -58,6 +58,7 @@ struct bochs_device {
void __iomem *fb_map;
unsigned long fb_base;
unsigned long fb_size;
+ unsigned long qext_size;
/* mode */
u16 xres;
@@ -121,7 +122,8 @@ int bochs_hw_init(struct drm_device *dev);
void bochs_hw_fini(struct drm_device *dev);
void bochs_hw_setmode(struct bochs_device *bochs,
- struct drm_display_mode *mode);
+ struct drm_display_mode *mode,
+ const struct drm_format_info *format);
void bochs_hw_setbase(struct bochs_device *bochs,
int x, int y, u64 addr);
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index c46fdae44e..dd3c7df267 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -140,7 +140,8 @@ static struct drm_framebuffer *
bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB)
+ if (mode_cmd->pixel_format != DRM_FORMAT_XRGB &&
+ mode_cmd->pixel_format != DRM_FORMAT_BGRX)
return ERR_PTR(-EINVAL);
return drm_gem_fb_create(dev, file, mode_cmd);
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index 16e4f1cacc..cacff73a64 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -47,11 +47,33 @@ static void bochs_dispi_write(struct bochs_device *bochs,
u16 reg, u16 val)
}
}
+static void bochs_hw_set_big_endian(struct bochs_device *bochs)
+{
+ if (bochs->qext_size < 8)
+ return;
+
+ writel(0xbebebebe, bochs->mmio + 0x604);
+}
+
+static void bochs_hw_set_little_endian(struct bochs_device *bochs)
+{
+ if (bochs->qext_size < 8)
+ return;
+
+ writel(0x1e1e1e1e, bochs->mmio + 0x604);
+}
+
+#ifdef __BIG_ENDIAN
+#define bochs_hw_set_native_endian(_b) bochs_hw_set_big_endian(_b)
+#else
+#define bochs_hw_set_native_endian(_b) bochs_hw_set_little_endian(_b)
+#endif
+
int bochs_hw_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
struct pci_dev *pdev = dev->pdev;
- unsigned long addr, size, mem, ioaddr, iosize, qext_size;
+ unsigned long addr, size, mem, ioaddr, iosize;
u16 id;
if (pdev->resource[2].flags & IORESOURCE_MEM) {
@@ -117,19 +139,14 @@ int bochs_hw_init(struct drm_device *dev)
ioaddr);
if (bochs->mmio && pdev->revision >= 2) {
- qext_size = readl(bochs->mmio + 0x600);
- if (qext_size < 4 || qext_size > iosize)
+ bochs->qext_size = readl(bochs->mmio + 0x600);
+ if (bochs->qext_size < 4 || bochs->qext_size > iosize) {
+ bochs->qext_size = 0;
goto noext;
- DRM_DEBUG("Found qemu ext regs, size %ld\n", qext_size);
- if (qext_size >= 8) {
-#ifdef __BIG_ENDIAN
- writel(0xbebebebe, bochs->mmio + 0x604);
-#else
- writel(0x1e1e1e1e, bochs->mmio + 0x604);
-#endif
- DRM_DEBUG(" qext endian: 0x%x\n",
- readl(bochs->mmio + 0x604));
}
+ DRM_DEBUG("Found qemu ext regs, size %ld\n",
+ bochs->qext_size);
+ bochs_hw_set_native_endian(bochs);
}
noext:
@@ -150,7 +167,8 @@ void bochs_hw_fini(struct drm_device *dev)
}
void bochs_hw_setmode(struct bochs_device *bochs,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ const struct drm_format_info *format)
{
bochs->xres = mode->hdisplay;
bochs->yres = mode->vdisplay;
@@ -158,8 +176,12 @@ void bochs_hw_setmode(struct bochs_device *bochs,
bochs->stride = mode->hdisplay * (bochs->bpp / 8);
bochs->yres_virtual = bochs->fb_size / bochs->stride;
- DRM_DEBUG_DRIVER("%dx%d @ %d bpp, vy %d\n",
+ DRM_DEBUG_DRIVER("%dx%d @ %d bpp, format %c%c%c%c, vy %d\n",
[PATCH v4 6/6] drm: move quirk_addfb_prefer_xbgr_30bpp handling to drm_driver_legacy_fb_format too
Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/drm_fourcc.c | 5 + drivers/gpu/drm/drm_framebuffer.c | 4 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c index 7c6d3922ed..90a1c846fc 100644 --- a/drivers/gpu/drm/drm_fourcc.c +++ b/drivers/gpu/drm/drm_fourcc.c @@ -121,6 +121,11 @@ uint32_t drm_driver_legacy_fb_format(struct drm_device *dev, if (fmt == DRM_FORMAT_XRGB1555) fmt = DRM_FORMAT_HOST_XRGB1555; } + + if (dev->mode_config.quirk_addfb_prefer_xbgr_30bpp && + fmt == DRM_FORMAT_XRGB2101010) + fmt = DRM_FORMAT_XBGR2101010; + return fmt; } EXPORT_SYMBOL(drm_driver_legacy_fb_format); diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index 1e2126101c..3bf729d0aa 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -129,10 +129,6 @@ int drm_mode_addfb(struct drm_device *dev, struct drm_mode_fb_cmd *or, r.pitches[0] = or->pitch; r.handles[0] = or->handle; - if (dev->mode_config.quirk_addfb_prefer_xbgr_30bpp && - r.pixel_format == DRM_FORMAT_XRGB2101010) - r.pixel_format = DRM_FORMAT_XBGR2101010; - ret = drm_mode_addfb2(dev, , file_priv); if (ret) return ret; -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Fri, Sep 21, 2018 at 01:34:00AM -0700, Manasi Navare wrote:
> On Wed, Sep 19, 2018 at 01:57:00PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 18, 2018 at 02:10:17PM -0700, Manasi Navare wrote:
> > > On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > > > > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > > > > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > > > > > Thanks Imre for your review comments. Please find the comments
> > > > > > > below:
> > > > > > >
> > > > > > > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > > > > > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > > > > > > On Icelake, a separate power well PG2 is created for
> > > > > > > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > > > > > > display power domain for Power well 2.
> > > > > > > > >
> > > > > > > > > Cc: Rodrigo Vivi
> > > > > > > > > Cc: Imre Deak
> > > > > > > > > Signed-off-by: Manasi Navare
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > > > > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > > > > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > > > > > > POWER_DOMAIN_MODESET,
> > > > > > > > > POWER_DOMAIN_GT_IRQ,
> > > > > > > > > POWER_DOMAIN_INIT,
> > > > > > > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > > > > > > >
> > > > > > > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > > > > > > functionality which could be on separate power wells in the
> > > > > > > > future.
> > > > > > > >
> > > > > > >
> > > > > > > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on
> > > > > > > Pipe A
> > > > > > > will use this VDSC power well.
> > > > > > > I will change this in the next revision.
> > > > > >
> > > > > > Isn't the VDSC in the transcoder for now though? And I guess it's
> > > > > > moving to the pipe later?
> > > > >
> > > > > VDSC engine is attached to the eDP/DSI transcoders and this gets used
> > > > > for eDP/DSI VDSC on Pipe A.
> > > >
> > > > And what happens when I want to use pipe B instead?
> > >
> > > DP VDSC on Pipe B uses the VDSC engine on Pipe B. Same for Pipe C
> >
> > There are no VDSCs in pipe B or C. There are VDSCs in transcoder B
> > and C. But that's not the same thing at all. The mux is between the
> > pipe and transcoder.
> >
>
> As per the display overview for Gen 11, the VDSC engine is present on Pipe B
> And C.
On transcoder B and C, not pipe B and C.
> But for Pipe A only, it uses VDSC engine attached to transcoder eDP/DSI.
>
> > > Can we have a situation where eDP uses Pipe B?
> >
> > Sure. 'xrandr --output eDP --crtc 1', or whatever.
> >
>
> I guess even in this case, if its eDP/DSI, it will still use the VDSC engine
> on transcoder eDP so will need to enable this power well 2.
>
> Manasi
>
> > > Because in case of VDSC
> > > in case of eDP, it will always use the VDSC on transcoder eDP which will
> > > require this power well.
> > >
> > > Manasi
> > >
> > > >
> > > > > So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
> > > > > will use this power well. But may be we should add a comment that
> > > > > this is only for eDP/DSI on Pipe A since ICL does not support
> > > > > VDSC on DP on Pipe A
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Manasi
> > > > >
> > > > > >
> > > > > > If we call it PIPE_A then it's going to a bit confusing when we
> > > > > > use it with pipe B or C. Needs at least clear comments in the code
> > > > > > why we're doing something that looks like nonsense of the first
> > > > > > glance.
> > > > > >
> > > > > > --
> > > > > > Ville Syrjälä
> > > > > > Intel
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/6] drm: more byteorder fixes
Fix fbdev emulation. Fix bochs-drm and virtio-gpu drivers. Gerd Hoffmann (6): drm: move native byte order quirk to new drm_driver_legacy_fb_format function drm: use drm_driver_legacy_fb_format in drm_gem_fbdev_fb_create drm/bochs: fix DRM_FORMAT_* handling for big endian machines. drm/bochs: support changing byteorder at mode set time drm/virtio: fix DRM_FORMAT_* handling drm: move quirk_addfb_prefer_xbgr_30bpp handling to drm_driver_legacy_fb_format too drivers/gpu/drm/bochs/bochs.h| 4 +- include/drm/drm_fourcc.h | 2 + drivers/gpu/drm/bochs/bochs_fbdev.c | 18 ++-- drivers/gpu/drm/bochs/bochs_hw.c | 64 ++-- drivers/gpu/drm/bochs/bochs_kms.c| 40 - drivers/gpu/drm/drm_fourcc.c | 35 +++ drivers/gpu/drm/drm_framebuffer.c| 17 +--- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 +- drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++ drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +- drivers/gpu/drm/virtio/virtgpu_gem.c | 7 ++- drivers/gpu/drm/virtio/virtgpu_plane.c | 54 +-- 12 files changed, 158 insertions(+), 94 deletions(-) -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107956] [CI][SHARDS] igt@kms_busy@extended_*_render-[abc] - dmesg-warn - Asynchronous wait on fence i915:kms_busy\[\d+\]/0:1 timed out \(hint:intel_atomic_commit_ready
https://bugs.freedesktop.org/show_bug.cgi?id=107956 --- Comment #4 from Martin Peres --- https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_114/fi-ilk-650/igt@kms_b...@extended-pageflip-hang-newfb-render-b.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_113/fi-byt-clapper/igt@kms_b...@extended-pageflip-hang-newfb-render-b.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_114/fi-byt-n2820/igt@kms_b...@extended-pageflip-hang-newfb-render-a.html [618.939579] Asynchronous wait on fence i915:rcs0:9599 timed out (hint:intel_atomic_commit_ready+0x0/0x4c [i915]) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/2] dt-bindings: Add Truly NT35597 panel driver bindings
On Thu, Sep 20, 2018 at 03:52:37PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add the device tree bindings for Truly NT35597 panel driver.
> This panel driver supports both single DSI and dual DSI.
>
> However, this patch series supports only dual DSI.
>
> Changes in v8:
> - None
>
> Signed-off-by: Abhinav Kumar
Cc: robh...@kernel.org
> ---
> .../devicetree/bindings/display/truly,nt35597.txt | 60
> ++
> 1 file changed, 60 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/truly,nt35597.txt
>
> diff --git a/Documentation/devicetree/bindings/display/truly,nt35597.txt
> b/Documentation/devicetree/bindings/display/truly,nt35597.txt
> new file mode 100644
> index 000..46b29eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/truly,nt35597.txt
> @@ -0,0 +1,60 @@
> +Truly model NT35597 DSI display driver
> +
> +The Truly NT35597 is a generic display driver, currently only configured
> +for use in the 2K display on the Qualcomm SDM845.
> +
> +Required properties:
> +- compatible: should be "truly,nt35597-2K-display"
> +- vdda-supply: phandle of the regulator that provides the supply voltage
> + Power IC supply
> +- vdispp-supply: phandle of the regulator that provides the supply voltage
> + for positive LCD bias
> +- vdispn-supply: phandle of the regulator that provides the supply voltage
> + for negative LCD bias
> +- reset-gpios: phandle of gpio for reset line
> + This should be 8mA, gpio can be configured using mux, pinctrl,
> pinctrl-names
> + (active low)
> +- mode-gpios: phandle of the gpio for choosing the mode of the display
> + for single DSI or Dual DSI
> + (active high)
> + This should be low for dual DSI and high for single DSI mode
> +- ports: This device has two video ports driven by two DSIs. Their
> connections
> + are modelled using the OF graph bindings specified in
> + Documentation/devicetree/bindings/graph.txt.
> + - port@0: DSI input port driven by master DSI
> + - port@1: DSI input port driven by secondary DSI
> +
> +Example:
> +
> + dsi@ae94000 {
> + panel@0 {
> + compatible = "truly,nt35597-2K-display";
> + reg = <0>;
> + vdda-supply = <_l14>;
> + vdispp-supply = <_regulator>;
> + vdispn-supply = <_regulator>;
> + pinctrl-names = "default", "suspend";
> + pinctrl-0 = <_dsi_active>;
> + pinctrl-1 = <_dsi_suspend>;
> +
> + reset-gpios = < 6 GPIO_ACTIVE_LOW>;
> + mode-gpios = < 52 GPIO_ACTIVE_HIGH>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + panel1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> + };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] drm/panel: Add support for Truly NT35597 panel driver
On Thu, Sep 20, 2018 at 03:52:36PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add support for Truly NT35597 panel driver used
> in MSM reference platforms.
>
> This panel driver supports both single DSI and dual DSI
> modes.
>
> However, this patch series adds support only for
> dual DSI mode.
>
> Changes in v8:
> - Remove video mode config and headers
> - Remove unused macros
> - Try to avoid multi-lines wherever possible
> - Fix comments locations and make it concise
> - Fix return points in probe function
>
> Signed-off-by: Archit Taneja
> Signed-off-by: Abhinav Kumar
Adding Cc: robh...@kernel.org so Rob sees it in his patchwork queue.
Sean
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 676
>
> 3 files changed, 684 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6020c30..073ffa0 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -186,4 +186,11 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TRULY_NT35597_WQXGA
> + tristate "Truly WQXGA"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> DSI
> + Video Mode panel
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 5ccaaa9..80fd19f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> new file mode 100644
> index 000..c9e09e2
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> @@ -0,0 +1,676 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const char * const regulator_names[] = {
> + "vdda",
> + "vdispp",
> + "vdispn",
> +};
> +
> +static unsigned long const regulator_enable_loads[] = {
> + 62000,
> + 10,
> + 10,
> +};
> +
> +static unsigned long const regulator_disable_loads[] = {
> + 80,
> + 100,
> + 100,
> +};
> +
> +struct nt35597_config {
> + u32 width_mm;
> + u32 height_mm;
> + const char *panel_name;
> + const void *panel_on_cmds;
> + u32 num_on_cmds;
> + const struct drm_display_mode *dm;
> +};
> +
> +struct truly_nt35597 {
> + struct device *dev;
> + struct drm_panel panel;
> +
> + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *mode_gpio;
> +
> + struct backlight_device *backlight;
> +
> + struct mipi_dsi_device *dsi[2];
> +
> + const struct nt35597_config *config;
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline struct truly_nt35597 *panel_to_ctx(struct drm_panel *panel)
> +{
> + return container_of(panel, struct truly_nt35597, panel);
> +}
> +
> +struct cmd_set {
> + u8 commands[4];
> + u8 size;
> +};
> +
> +static struct cmd_set qcom_2k_panel_magic_cmds[] = {
> + /* CMD2_P0 */
> + { { 0xff, 0x20 }, 2 },
> + { { 0xfb, 0x01 }, 2 },
> + { { 0x00, 0x01 }, 2 },
> + { { 0x01, 0x55 }, 2 },
> + { { 0x02, 0x45 }, 2 },
> + { { 0x05, 0x40 }, 2 },
> + { { 0x06, 0x19 }, 2 },
> + { { 0x07, 0x1e }, 2 },
> + { { 0x0b, 0x73 }, 2 },
> + { { 0x0c, 0x73 }, 2 },
> + { { 0x0e, 0xb0 }, 2 },
> + { { 0x0f, 0xae }, 2 },
> + { { 0x11, 0xb8 }, 2 },
> + { { 0x13, 0x00 }, 2 },
> + { { 0x58, 0x80 }, 2 },
> + { { 0x59, 0x01 }, 2 },
> + { { 0x5a, 0x00 }, 2 },
> + { { 0x5b, 0x01 }, 2 },
> + { { 0x5c, 0x80 }, 2 },
> + { { 0x5d, 0x81 }, 2 },
> + { { 0x5e, 0x00 }, 2 },
> + { { 0x5f, 0x01 }, 2 },
> + { { 0x72, 0x11 }, 2 },
> + { { 0x68, 0x03 }, 2 },
> + /* CMD2_P4 */
> + { { 0xFF, 0x24 }, 2 },
> + { { 0xFB, 0x01 }, 2 },
> + { { 0x00, 0x1C }, 2 },
> + { { 0x01, 0x0B }, 2 },
> + { { 0x02, 0x0C }, 2 },
> + { { 0x03, 0x01 }, 2 },
> + { { 0x04, 0x0F }, 2 },
> + { { 0x05, 0x10 }, 2
Re: [PATCH v8 2/2] dt-bindings: Add Truly NT35597 panel driver bindings
On Thu, Sep 20, 2018 at 03:52:37PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
JFYI, this is going to munge your Author name. This can be fixed up when the
patch is applied, so probably not worth a v9.
Reviewed-by: Sean Paul
>
> Add the device tree bindings for Truly NT35597 panel driver.
> This panel driver supports both single DSI and dual DSI.
>
> However, this patch series supports only dual DSI.
>
> Changes in v8:
> - None
>
> Signed-off-by: Abhinav Kumar
> ---
> .../devicetree/bindings/display/truly,nt35597.txt | 60
> ++
> 1 file changed, 60 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/truly,nt35597.txt
>
> diff --git a/Documentation/devicetree/bindings/display/truly,nt35597.txt
> b/Documentation/devicetree/bindings/display/truly,nt35597.txt
> new file mode 100644
> index 000..46b29eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/truly,nt35597.txt
> @@ -0,0 +1,60 @@
> +Truly model NT35597 DSI display driver
> +
> +The Truly NT35597 is a generic display driver, currently only configured
> +for use in the 2K display on the Qualcomm SDM845.
> +
> +Required properties:
> +- compatible: should be "truly,nt35597-2K-display"
> +- vdda-supply: phandle of the regulator that provides the supply voltage
> + Power IC supply
> +- vdispp-supply: phandle of the regulator that provides the supply voltage
> + for positive LCD bias
> +- vdispn-supply: phandle of the regulator that provides the supply voltage
> + for negative LCD bias
> +- reset-gpios: phandle of gpio for reset line
> + This should be 8mA, gpio can be configured using mux, pinctrl,
> pinctrl-names
> + (active low)
> +- mode-gpios: phandle of the gpio for choosing the mode of the display
> + for single DSI or Dual DSI
> + (active high)
> + This should be low for dual DSI and high for single DSI mode
> +- ports: This device has two video ports driven by two DSIs. Their
> connections
> + are modelled using the OF graph bindings specified in
> + Documentation/devicetree/bindings/graph.txt.
> + - port@0: DSI input port driven by master DSI
> + - port@1: DSI input port driven by secondary DSI
> +
> +Example:
> +
> + dsi@ae94000 {
> + panel@0 {
> + compatible = "truly,nt35597-2K-display";
> + reg = <0>;
> + vdda-supply = <_l14>;
> + vdispp-supply = <_regulator>;
> + vdispn-supply = <_regulator>;
> + pinctrl-names = "default", "suspend";
> + pinctrl-0 = <_dsi_active>;
> + pinctrl-1 = <_dsi_suspend>;
> +
> + reset-gpios = < 6 GPIO_ACTIVE_LOW>;
> + mode-gpios = < 52 GPIO_ACTIVE_HIGH>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + panel1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> + };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] drm/panel: Add support for Truly NT35597 panel driver
On Thu, Sep 20, 2018 at 03:52:36PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add support for Truly NT35597 panel driver used
> in MSM reference platforms.
>
> This panel driver supports both single DSI and dual DSI
> modes.
>
> However, this patch series adds support only for
> dual DSI mode.
>
> Changes in v8:
> - Remove video mode config and headers
> - Remove unused macros
> - Try to avoid multi-lines wherever possible
> - Fix comments locations and make it concise
> - Fix return points in probe function
Thanks for revising!
Reviewed-by: Sean Paul
>
> Signed-off-by: Archit Taneja
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 676
>
> 3 files changed, 684 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6020c30..073ffa0 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -186,4 +186,11 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TRULY_NT35597_WQXGA
> + tristate "Truly WQXGA"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> DSI
> + Video Mode panel
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 5ccaaa9..80fd19f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> new file mode 100644
> index 000..c9e09e2
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> @@ -0,0 +1,676 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const char * const regulator_names[] = {
> + "vdda",
> + "vdispp",
> + "vdispn",
> +};
> +
> +static unsigned long const regulator_enable_loads[] = {
> + 62000,
> + 10,
> + 10,
> +};
> +
> +static unsigned long const regulator_disable_loads[] = {
> + 80,
> + 100,
> + 100,
> +};
> +
> +struct nt35597_config {
> + u32 width_mm;
> + u32 height_mm;
> + const char *panel_name;
> + const void *panel_on_cmds;
> + u32 num_on_cmds;
> + const struct drm_display_mode *dm;
> +};
> +
> +struct truly_nt35597 {
> + struct device *dev;
> + struct drm_panel panel;
> +
> + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *mode_gpio;
> +
> + struct backlight_device *backlight;
> +
> + struct mipi_dsi_device *dsi[2];
> +
> + const struct nt35597_config *config;
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline struct truly_nt35597 *panel_to_ctx(struct drm_panel *panel)
> +{
> + return container_of(panel, struct truly_nt35597, panel);
> +}
> +
> +struct cmd_set {
> + u8 commands[4];
> + u8 size;
> +};
> +
> +static struct cmd_set qcom_2k_panel_magic_cmds[] = {
> + /* CMD2_P0 */
> + { { 0xff, 0x20 }, 2 },
> + { { 0xfb, 0x01 }, 2 },
> + { { 0x00, 0x01 }, 2 },
> + { { 0x01, 0x55 }, 2 },
> + { { 0x02, 0x45 }, 2 },
> + { { 0x05, 0x40 }, 2 },
> + { { 0x06, 0x19 }, 2 },
> + { { 0x07, 0x1e }, 2 },
> + { { 0x0b, 0x73 }, 2 },
> + { { 0x0c, 0x73 }, 2 },
> + { { 0x0e, 0xb0 }, 2 },
> + { { 0x0f, 0xae }, 2 },
> + { { 0x11, 0xb8 }, 2 },
> + { { 0x13, 0x00 }, 2 },
> + { { 0x58, 0x80 }, 2 },
> + { { 0x59, 0x01 }, 2 },
> + { { 0x5a, 0x00 }, 2 },
> + { { 0x5b, 0x01 }, 2 },
> + { { 0x5c, 0x80 }, 2 },
> + { { 0x5d, 0x81 }, 2 },
> + { { 0x5e, 0x00 }, 2 },
> + { { 0x5f, 0x01 }, 2 },
> + { { 0x72, 0x11 }, 2 },
> + { { 0x68, 0x03 }, 2 },
> + /* CMD2_P4 */
> + { { 0xFF, 0x24 }, 2 },
> + { { 0xFB, 0x01 }, 2 },
> + { { 0x00, 0x1C }, 2 },
> + { { 0x01, 0x0B }, 2 },
> + { { 0x02, 0x0C }, 2 },
> + { { 0x03, 0x01 }, 2 },
> + { { 0x04, 0x0F }, 2 },
> + { { 0x05, 0x10 }, 2 },
> + { { 0x06, 0x10 },
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #11 from Jason Playne --- (In reply to Jason Playne from comment #10) > (In reply to Timothy Arceri from comment #9) > > I'm not sure why yet but both the black triangles and the incorrect > > rendering behind the chinese emperor on the loading screen go away when I > > run the trace on the NIR backend. > > > > Until we figure out what is going on here you can try running the game with > > the following environment variable: > > > > R600_DEBUG=nir > > Can confirm! The initial red+black triangles in the game seem to have > disappeared using the nir backend. > > (I may be a little excited!) After a couple of hours of game time, I have not seen the triangles. nir solves the problem Thanks Timothy! -- 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
[GIT PULL] mali-dp fixes
Hi Dave, I have managed to push the fixes to the public tree without sending the pull request until today when I did a clean checkout of drm-fixes and realised my mistake. I've now rebased the tree on your latest drm-fixes branch. At your convenience, please pull these two patches. Many thanks, Liviu The following changes since commit 4fcb7f8be829d21bcbb24eef2204fb6b34ed1f80: Merge branch 'drm-fixes-4.19' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2018-09-21 09:52:27 +1000) are available in the Git repository at: git://linux-arm.org/linux-ld.git for-upstream/malidp-fixes for you to fetch changes up to 89578d04b52c872aef6b1257b5f6caf6bcc35abe: drm/malidp: Fix writeback in NV12 (2018-09-21 10:55:00 +0100) Alexandru Gheorghe (2): drm: mali-dp: Call drm_crtc_vblank_reset on device init drm/malidp: Fix writeback in NV12 drivers/gpu/drm/arm/malidp_drv.c | 1 + drivers/gpu/drm/arm/malidp_hw.c | 25 +++-- drivers/gpu/drm/arm/malidp_hw.h | 3 ++- drivers/gpu/drm/arm/malidp_mw.c | 25 + drivers/gpu/drm/arm/malidp_regs.h | 2 ++ 5 files changed, 49 insertions(+), 7 deletions(-) -- | 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
[PATCH v2] drm/exynos: simplify DMA mapping
Moving DMA mapping creation to drm_iommu_attach_device allows to avoid
looping through all components and maintaining DMA device flags.
v2: take care of configurations without IOMMU
Signed-off-by: Andrzej Hajda
---
Hi Inki,
In the 2nd version I took care of non-iommu case, thanks to Marek.
Regards
Andrzej
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 71 +++
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 +
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_scaler.c| 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
11 files changed, 37 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 94529aa82339..b0d80e17ab85 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -578,7 +578,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
decon_clear_channels(ctx->crtc);
- return drm_iommu_attach_device(drm_dev, dev);
+ return exynos_drm_register_dma(drm_dev, dev);
}
static void decon_unbind(struct device *dev, struct device *master, void *data)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 88cbd000eb09..e78978eea5cb 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -133,7 +133,7 @@ static int decon_ctx_initialize(struct decon_context *ctx,
decon_clear_channels(ctx->crtc);
- return drm_iommu_attach_device(drm_dev, ctx->dev);
+ return exynos_drm_register_dma(drm_dev, ctx->dev);
}
static void decon_ctx_remove(struct decon_context *ctx)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b599f74692e5..bc20fb1b26e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -45,6 +45,27 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 1
+int exynos_drm_register_dma(struct drm_device *drm, struct device *dev)
+{
+ struct exynos_drm_private *priv = drm->dev_private;
+ int ret;
+
+ if (!priv->dma_dev) {
+ priv->dma_dev = dev;
+ DRM_INFO("Exynos DRM: using %s device for DMA mapping
operations\n",
+dev_name(dev));
+ /* create common IOMMU mapping for all Exynos DRM devices */
+ ret = drm_create_iommu_mapping(drm);
+ if (ret < 0) {
+ priv->dma_dev = NULL;
+ DRM_ERROR("failed to create iommu mapping.\n");
+ return -EINVAL;
+ }
+ }
+
+ return drm_iommu_attach_device(drm, dev);
+}
+
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
@@ -197,8 +218,7 @@ struct exynos_drm_driver_info {
#define DRM_COMPONENT_DRIVER BIT(0) /* supports component framework */
#define DRM_VIRTUAL_DEVICE BIT(1) /* create virtual platform device */
-#define DRM_DMA_DEVICE BIT(2) /* can be used for dma allocations */
-#define DRM_FIMC_DEVICEBIT(3) /* devices shared with V4L2
subsystem */
+#define DRM_FIMC_DEVICEBIT(2) /* devices shared with V4L2
subsystem */
#define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? : NULL)
@@ -209,16 +229,16 @@ struct exynos_drm_driver_info {
static struct exynos_drm_driver_info exynos_drm_drivers[] = {
{
DRV_PTR(fimd_driver, CONFIG_DRM_EXYNOS_FIMD),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(exynos5433_decon_driver, CONFIG_DRM_EXYNOS5433_DECON),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(decon_driver, CONFIG_DRM_EXYNOS7_DECON),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
DRM_COMPONENT_DRIVER
@@ -289,27 +309,6 @@ static struct component_match *exynos_drm_match_add(struct
device *dev)
return match ?: ERR_PTR(-ENODEV);
}
-static struct device *exynos_drm_get_dma_device(void)
-{
- int i;
-
- for (i = 0; i <
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #10 from Jason Playne --- (In reply to Timothy Arceri from comment #9) > I'm not sure why yet but both the black triangles and the incorrect > rendering behind the chinese emperor on the loading screen go away when I > run the trace on the NIR backend. > > Until we figure out what is going on here you can try running the game with > the following environment variable: > > R600_DEBUG=nir Can confirm! The initial red+black triangles in the game seem to have disappeared using the nir backend. (I may be a little excited!) -- 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/5] drm/tegra: dc: Do not register DC without primary plane
From: Thierry Reding
Tegra194 contains a fourth display controller that does not own any
windows. Therefore, we cannot currently assign a primary plane to it
which causes KMS to eventually crash. Do not register the display
controller if it owns no windows to work around this.
Note that we still have to enable and probe the display controller
because for some reason all display controllers need to be powered
(and/or clocked) before any registers can be accessed in any of the
display controllers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 965088afcfad..7e36ca204cbb 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1988,6 +1988,28 @@ static int tegra_dc_init(struct host1x_client *client)
struct drm_plane *cursor = NULL;
int err;
+ /*
+* XXX do not register DCs with no window groups because we cannot
+* assign a primary plane to them, which in turn will cause KMS to
+* crash.
+*/
+ if (dc->soc->wgrps) {
+ bool has_wgrps = false;
+ unsigned int i;
+
+ for (i = 0; i < dc->soc->num_wgrps; i++) {
+ const struct tegra_windowgroup_soc *wgrp =
>soc->wgrps[i];
+
+ if (wgrp->dc == dc->pipe && wgrp->num_windows > 0) {
+ has_wgrps = true;
+ break;
+ }
+ }
+
+ if (!has_wgrps)
+ return 0;
+ }
+
dc->syncpt = host1x_syncpt_request(client, flags);
if (!dc->syncpt)
dev_warn(dc->dev, "failed to allocate syncpoint\n");
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/tegra: dpaux: Add Tegra194 support
From: Thierry Reding
The DPAUX controller found on Tegra194 is almost identical to its
predecessor from Tegra186.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dpaux.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index d84e81ff36ad..b96817b0130d 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -639,6 +639,7 @@ static const struct dev_pm_ops tegra_dpaux_pm_ops = {
};
static const struct of_device_id tegra_dpaux_of_match[] = {
+ { .compatible = "nvidia,tegra194-dpaux", },
{ .compatible = "nvidia,tegra186-dpaux", },
{ .compatible = "nvidia,tegra210-dpaux", },
{ .compatible = "nvidia,tegra124-dpaux", },
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/tegra: dc: Add Tegra194 support
From: Thierry Reding
The display controllers found on Tegra194 are almost identical to those
found on Tegra186.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 51 +
drivers/gpu/drm/tegra/dc.h | 2 +-
drivers/gpu/drm/tegra/drm.c | 1 +
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 7e36ca204cbb..f80e82e16475 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2256,8 +2256,59 @@ static const struct tegra_dc_soc_info
tegra186_dc_soc_info = {
.num_wgrps = ARRAY_SIZE(tegra186_dc_wgrps),
};
+static const struct tegra_windowgroup_soc tegra194_dc_wgrps[] = {
+ {
+ .index = 0,
+ .dc = 0,
+ .windows = (const unsigned int[]) { 0 },
+ .num_windows = 1,
+ }, {
+ .index = 1,
+ .dc = 1,
+ .windows = (const unsigned int[]) { 1 },
+ .num_windows = 1,
+ }, {
+ .index = 2,
+ .dc = 1,
+ .windows = (const unsigned int[]) { 2 },
+ .num_windows = 1,
+ }, {
+ .index = 3,
+ .dc = 2,
+ .windows = (const unsigned int[]) { 3 },
+ .num_windows = 1,
+ }, {
+ .index = 4,
+ .dc = 2,
+ .windows = (const unsigned int[]) { 4 },
+ .num_windows = 1,
+ }, {
+ .index = 5,
+ .dc = 2,
+ .windows = (const unsigned int[]) { 5 },
+ .num_windows = 1,
+ },
+};
+
+static const struct tegra_dc_soc_info tegra194_dc_soc_info = {
+ .supports_background_color = true,
+ .supports_interlacing = true,
+ .supports_cursor = true,
+ .supports_block_linear = true,
+ .has_legacy_blending = false,
+ .pitch_align = 64,
+ .has_powergate = false,
+ .coupled_pm = false,
+ .has_nvdisplay = true,
+ .wgrps = tegra194_dc_wgrps,
+ .num_wgrps = ARRAY_SIZE(tegra194_dc_wgrps),
+};
+
static const struct of_device_id tegra_dc_of_match[] = {
{
+ .compatible = "nvidia,tegra194-dc",
+ .data = _dc_soc_info,
+ }, {
.compatible = "nvidia,tegra186-dc",
.data = _dc_soc_info,
}, {
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index e96f582ca692..1256dfb6b2f5 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -300,7 +300,7 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
#define SOR1_TIMING_CYA(1 << 27)
#define CURSOR_ENABLE (1 << 16)
-#define SOR_ENABLE(x) (1 << (25 + (x)))
+#define SOR_ENABLE(x) (1 << (25 + (((x) > 1) ? ((x) + 1) : (x
#define DC_DISP_DISP_MEM_HIGH_PRIORITY 0x403
#define CURSOR_THRESHOLD(x) (((x) & 0x03) << 24)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index b31dcf5c9524..395b048447b2 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1276,6 +1276,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra186-sor1", },
{ .compatible = "nvidia,tegra186-vic", },
{ .compatible = "nvidia,tegra194-display", },
+ { .compatible = "nvidia,tegra194-dc", },
{ /* sentinel */ }
};
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/tegra: sor: Add Tegra194 support
From: Thierry Reding
The SOR implemented in Tegra194 is subtly different from its predecessor
found in Tegra186. Most notably some registers have been moved around so
it is no longer compatible.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/tegra/sor.c | 110
2 files changed, 111 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 395b048447b2..67a7cffe89fc 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1277,6 +1277,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra186-vic", },
{ .compatible = "nvidia,tegra194-display", },
{ .compatible = "nvidia,tegra194-dc", },
+ { .compatible = "nvidia,tegra194-sor", },
{ /* sentinel */ }
};
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index d7fe9f15def1..b129da2e5afd 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -282,6 +282,85 @@ static const struct tegra_sor_hdmi_settings
tegra186_sor_hdmi_defaults[] = {
}
};
+static const struct tegra_sor_hdmi_settings tegra194_sor_hdmi_defaults[] = {
+ {
+ .frequency = 5400,
+ .vcocap = 0,
+ .filter = 5,
+ .ichpmp = 5,
+ .loadadj = 3,
+ .tmds_termadj = 0xf,
+ .tx_pu_value = 0,
+ .bg_temp_coef = 3,
+ .bg_vref_level = 8,
+ .avdd10_level = 4,
+ .avdd14_level = 4,
+ .sparepll = 0x54,
+ .drive_current = { 0x3a, 0x3a, 0x3a, 0x33 },
+ .preemphasis = { 0x00, 0x00, 0x00, 0x00 },
+ }, {
+ .frequency = 7500,
+ .vcocap = 1,
+ .filter = 5,
+ .ichpmp = 5,
+ .loadadj = 3,
+ .tmds_termadj = 0xf,
+ .tx_pu_value = 0,
+ .bg_temp_coef = 3,
+ .bg_vref_level = 8,
+ .avdd10_level = 4,
+ .avdd14_level = 4,
+ .sparepll = 0x44,
+ .drive_current = { 0x3a, 0x3a, 0x3a, 0x33 },
+ .preemphasis = { 0x00, 0x00, 0x00, 0x00 },
+ }, {
+ .frequency = 15000,
+ .vcocap = 3,
+ .filter = 5,
+ .ichpmp = 5,
+ .loadadj = 3,
+ .tmds_termadj = 15,
+ .tx_pu_value = 0x66 /* 0 */,
+ .bg_temp_coef = 3,
+ .bg_vref_level = 8,
+ .avdd10_level = 4,
+ .avdd14_level = 4,
+ .sparepll = 0x00, /* 0x34 */
+ .drive_current = { 0x3a, 0x3a, 0x3a, 0x37 },
+ .preemphasis = { 0x00, 0x00, 0x00, 0x00 },
+ }, {
+ .frequency = 3,
+ .vcocap = 3,
+ .filter = 5,
+ .ichpmp = 5,
+ .loadadj = 3,
+ .tmds_termadj = 15,
+ .tx_pu_value = 64,
+ .bg_temp_coef = 3,
+ .bg_vref_level = 8,
+ .avdd10_level = 4,
+ .avdd14_level = 4,
+ .sparepll = 0x34,
+ .drive_current = { 0x3d, 0x3d, 0x3d, 0x33 },
+ .preemphasis = { 0x00, 0x00, 0x00, 0x00 },
+ }, {
+ .frequency = 6,
+ .vcocap = 3,
+ .filter = 5,
+ .ichpmp = 5,
+ .loadadj = 3,
+ .tmds_termadj = 12,
+ .tx_pu_value = 96,
+ .bg_temp_coef = 3,
+ .bg_vref_level = 8,
+ .avdd10_level = 4,
+ .avdd14_level = 4,
+ .sparepll = 0x34,
+ .drive_current = { 0x3d, 0x3d, 0x3d, 0x33 },
+ .preemphasis = { 0x00, 0x00, 0x00, 0x00 },
+ }
+};
+
struct tegra_sor_regs {
unsigned int head_state0;
unsigned int head_state1;
@@ -2894,7 +2973,38 @@ static const struct tegra_sor_soc tegra186_sor1 = {
.xbar_cfg = tegra124_sor_xbar_cfg,
};
+static const struct tegra_sor_regs tegra194_sor_regs = {
+ .head_state0 = 0x151,
+ .head_state1 = 0x155,
+ .head_state2 = 0x159,
+ .head_state3 = 0x15d,
+ .head_state4 = 0x161,
+ .head_state5 = 0x165,
+ .pll0 = 0x169,
+ .pll1 = 0x16a,
+ .pll2 = 0x16b,
+ .pll3 = 0x16c,
+ .dp_padctl0 = 0x16e,
+ .dp_padctl2 = 0x16f,
+};
+
+static const struct tegra_sor_soc tegra194_sor = {
+ .supports_edp = true,
+ .supports_lvds = false,
+ .supports_hdmi = true,
+ .supports_dp = true,
+
+ .regs = _sor_regs,
+ .has_nvdisplay = true,
+
+ .num_settings = ARRAY_SIZE(tegra194_sor_hdmi_defaults),
+ .settings = tegra194_sor_hdmi_defaults,
+
+ .xbar_cfg = tegra210_sor_xbar_cfg,
+};
+
static const struct
[PATCH 2/5] drm/tegra: hub: Add Tegra194 support
From: Thierry Reding
The display hub integrated into Tegra194 is almost identical to the one
found on Tegra186. However, it doesn't support DSC (display stream
compression) so it isn't fully compatible.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/tegra/hub.c | 19 +++
drivers/gpu/drm/tegra/hub.h | 1 +
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index b424bc911b95..b31dcf5c9524 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1275,6 +1275,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra186-sor", },
{ .compatible = "nvidia,tegra186-sor1", },
{ .compatible = "nvidia,tegra186-vic", },
+ { .compatible = "nvidia,tegra194-display", },
{ /* sentinel */ }
};
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 8f4fcbb515fb..6112d9042979 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -758,10 +758,12 @@ static int tegra_display_hub_probe(struct platform_device
*pdev)
return err;
}
- hub->clk_dsc = devm_clk_get(>dev, "dsc");
- if (IS_ERR(hub->clk_dsc)) {
- err = PTR_ERR(hub->clk_dsc);
- return err;
+ if (hub->soc->supports_dsc) {
+ hub->clk_dsc = devm_clk_get(>dev, "dsc");
+ if (IS_ERR(hub->clk_dsc)) {
+ err = PTR_ERR(hub->clk_dsc);
+ return err;
+ }
}
hub->clk_hub = devm_clk_get(>dev, "hub");
@@ -890,10 +892,19 @@ static const struct dev_pm_ops tegra_display_hub_pm_ops =
{
static const struct tegra_display_hub_soc tegra186_display_hub = {
.num_wgrps = 6,
+ .supports_dsc = true,
+};
+
+static const struct tegra_display_hub_soc tegra194_display_hub = {
+ .num_wgrps = 6,
+ .supports_dsc = false,
};
static const struct of_device_id tegra_display_hub_of_match[] = {
{
+ .compatible = "nvidia,tegra194-display",
+ .data = _display_hub
+ }, {
.compatible = "nvidia,tegra186-display",
.data = _display_hub
}, {
diff --git a/drivers/gpu/drm/tegra/hub.h b/drivers/gpu/drm/tegra/hub.h
index 85b8bf41a395..6696a85fc1f2 100644
--- a/drivers/gpu/drm/tegra/hub.h
+++ b/drivers/gpu/drm/tegra/hub.h
@@ -38,6 +38,7 @@ to_tegra_shared_plane(struct drm_plane *plane)
struct tegra_display_hub_soc {
unsigned int num_wgrps;
+ bool supports_dsc;
};
struct tegra_display_hub {
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/12] drm/mediatek: add hdmi driver for MT2701 and MT7623
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> This patch adds hdmi dirver suppot for both MT2701 and MT7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/Makefile | 3 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c| 9 +-
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 3 +
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 +
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 234
> +
> 5 files changed, 248 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index 61cf0d2ab28a..82ae49c64221 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -19,7 +19,8 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
> mediatek-drm-hdmi-objs := mtk_cec.o \
> mtk_hdmi.o \
> mtk_hdmi_ddc.o \
> + mtk_mt2701_hdmi_phy.o \
> mtk_mt8173_hdmi_phy.o \
> mtk_hdmi_phy.o
>
> -obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> \ No newline at end of file
> +obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index d62e685cec73..11e3644da79a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -241,8 +241,13 @@ static void mtk_hdmi_hw_make_reg_writable(struct
> mtk_hdmi *hdmi, bool enable)
>* The ARM trusted firmware provides an API for the HDMI driver to set
>* this control bit to enable HDMI output in supervisor mode.
>*/
> - arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904, 0x8000,
> - 0, 0, 0, 0, 0, );
> + if (hdmi_phy->conf && hdmi_phy->conf->tz_disabled)
> + regmap_update_bits(hdmi->sys_regmap,
> +hdmi->sys_offset + HDMI_SYS_CFG20,
> +0x80008005, enable ? 0x8005 : 0x8000);
> + else
> + arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904,
> + 0x8000, 0, 0, 0, 0, 0, );
>
> regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
> HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index d2dc50db1feb..52d314deacdc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -192,6 +192,9 @@ static int mtk_hdmi_phy_probe(struct platform_device
> *pdev)
> }
>
> static const struct of_device_id mtk_hdmi_phy_match[] = {
> + { .compatible = "mediatek,mt2701-hdmi-phy",
> + .data = _hdmi_phy_2701_conf,
> + },
> { .compatible = "mediatek,mt8173-hdmi-phy",
> .data = _hdmi_phy_8173_conf,
> },
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index e346fe319621..a6577c8fdf83 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -20,6 +20,7 @@
> struct mtk_hdmi_phy;
>
> struct mtk_hdmi_phy_conf {
> + bool tz_disabled;
> const struct clk_ops *hdmi_phy_clk_ops;
> void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> @@ -50,5 +51,6 @@ struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
>
> extern struct platform_driver mtk_hdmi_phy_driver;
> extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
> +extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
>
> #endif /* _MTK_HDMI_PHY_H */
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> new file mode 100644
> index ..41f5dcc24c4e
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -0,0 +1,234 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Chunhui Dai
> + */
> +
> +#include "mtk_hdmi_phy.h"
> +
> +#define HDMI_CON00x00
> +#define RG_HDMITX_DRV_IBIAS 0
> +#define RG_HDMITX_DRV_IBIAS_MASK (0x3f << 0)
> +#define RG_HDMITX_EN_SER 12
> +#define RG_HDMITX_EN_SER_MASK(0x0f << 12)
> +#define RG_HDMITX_EN_SLDO16
> +#define RG_HDMITX_EN_SLDO_MASK (0x0f << 16)
> +#define RG_HDMITX_EN_PRED20
> +#define RG_HDMITX_EN_PRED_MASK (0x0f << 20)
> +#define RG_HDMITX_EN_IMP 24
> +#define RG_HDMITX_EN_IMP_MASK(0x0f << 24)
> +#define
Re: [PATCH] drm/exynos: simplify DMA mapping
Hi Andrzej,
On 2018-09-21 10:58, Andrzej Hajda wrote:
> Moving DMA mapping creation to drm_iommu_attach_device allows to avoid
> looping through all components and maintaining DMA device flags.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 50 +++
> drivers/gpu/drm/exynos/exynos_drm_iommu.c | 13 +-
I like simplification, but this one is a bit too invasive. It breaks
Exynos DRM when IOMMU support is disabled (dma_dev won't be set in such
case).
> 2 files changed, 17 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index b599f74692e5..c83437d8a595 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -197,8 +197,7 @@ struct exynos_drm_driver_info {
>
> #define DRM_COMPONENT_DRIVERBIT(0) /* supports component framework
> */
> #define DRM_VIRTUAL_DEVICE BIT(1) /* create virtual platform device */
> -#define DRM_DMA_DEVICE BIT(2) /* can be used for dma
> allocations */
> -#define DRM_FIMC_DEVICE BIT(3) /* devices shared with V4L2
> subsystem */
> +#define DRM_FIMC_DEVICE BIT(2) /* devices shared with V4L2
> subsystem */
>
> #define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? : NULL)
>
> @@ -209,16 +208,16 @@ struct exynos_drm_driver_info {
> static struct exynos_drm_driver_info exynos_drm_drivers[] = {
> {
> DRV_PTR(fimd_driver, CONFIG_DRM_EXYNOS_FIMD),
> - DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
> + DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(exynos5433_decon_driver, CONFIG_DRM_EXYNOS5433_DECON),
> - DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
> + DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(decon_driver, CONFIG_DRM_EXYNOS7_DECON),
> - DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
> + DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
> - DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
> + DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
> DRM_COMPONENT_DRIVER
> @@ -289,27 +288,6 @@ static struct component_match
> *exynos_drm_match_add(struct device *dev)
> return match ?: ERR_PTR(-ENODEV);
> }
>
> -static struct device *exynos_drm_get_dma_device(void)
> -{
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) {
> - struct exynos_drm_driver_info *info = _drm_drivers[i];
> - struct device *dev;
> -
> - if (!info->driver || !(info->flags & DRM_DMA_DEVICE))
> - continue;
> -
> - while ((dev = bus_find_device(_bus_type, NULL,
> - >driver->driver,
> - (void *)platform_bus_type.match))) {
> - put_device(dev);
> - return dev;
> - }
> - }
> - return NULL;
> -}
> -
> static int exynos_drm_bind(struct device *dev)
> {
> struct exynos_drm_private *private;
> @@ -334,23 +312,6 @@ static int exynos_drm_bind(struct device *dev)
> dev_set_drvdata(dev, drm);
> drm->dev_private = (void *)private;
>
> - /* the first real CRTC device is used for all dma mapping operations */
> - private->dma_dev = exynos_drm_get_dma_device();
> - if (!private->dma_dev) {
> - DRM_ERROR("no device found for DMA mapping operations.\n");
> - ret = -ENODEV;
> - goto err_free_private;
> - }
> - DRM_INFO("Exynos DRM: using %s device for DMA mapping operations\n",
> - dev_name(private->dma_dev));
> -
> - /* create common IOMMU mapping for all devices attached to Exynos DRM */
> - ret = drm_create_iommu_mapping(drm);
> - if (ret < 0) {
> - DRM_ERROR("failed to create iommu mapping.\n");
> - goto err_free_private;
> - }
> -
> drm_mode_config_init(drm);
>
> exynos_drm_mode_config_init(drm);
> @@ -408,7 +369,6 @@ static int exynos_drm_bind(struct device *dev)
> err_mode_config_cleanup:
> drm_mode_config_cleanup(drm);
> drm_release_iommu_mapping(drm);
> -err_free_private:
> kfree(private);
> err_free_drm:
> drm_dev_put(drm);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> index 0f373702414e..bb8b800a9fba 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> @@ -75,7 +75,18 @@ int drm_iommu_attach_device(struct drm_device *drm_dev,
> struct exynos_drm_private *priv = drm_dev->dev_private;
> int ret;
>
> - if (get_dma_ops(priv->dma_dev) != get_dma_ops(subdrv_dev)) {
> + if (!priv->dma_dev) {
> +
Re: [PATCH v3 06/12] drm/mediatek: add dpi driver for mt2701 and mt7623
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> This patch adds dpi dirver suppot for both mt2701 and mt7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
>
Reviewed-by: CK Hu
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 7a4868a0afec..a9d8231a0a9e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -688,11 +688,29 @@ static unsigned int mt8173_calculate_factor(int clock)
> return 3 << 1;
> }
>
> +static unsigned int mt2701_calculate_factor(int clock)
> +{
> + if (clock <= 64000)
> + return 16;
> + else if (clock <= 128000)
> + return 8;
> + else if (clock <= 256000)
> + return 4;
> + else
> + return 2;
> +}
> +
> static const struct mtk_dpi_conf mt8173_conf = {
> .cal_factor = mt8173_calculate_factor,
> .reg_h_fre_con = 0xe0,
> };
>
> +static const struct mtk_dpi_conf mt2701_conf = {
> + .cal_factor = mt2701_calculate_factor,
> + .reg_h_fre_con = 0xb0,
> + .edge_sel_en = true,
> +};
> +
> static int mtk_dpi_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -784,6 +802,9 @@ static int mtk_dpi_remove(struct platform_device *pdev)
> }
>
> static const struct of_device_id mtk_dpi_of_ids[] = {
> + { .compatible = "mediatek,mt2701-dpi",
> + .data = _conf,
> + },
> { .compatible = "mediatek,mt8173-dpi",
> .data = _conf,
> },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 39721119713b..d961112fa2f5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -424,6 +424,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dsi",
> .data = (void *)MTK_DSI },
> + { .compatible = "mediatek,mt2701-dpi",
> + .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt8173-dpi",
> .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt2701-disp-mutex",
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/mediatek: convert dpi driver to use drm_of_find_panel_or_bridge
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> Convert dpi driver to use drm_of_find_panel_or_bridge.
> 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.
> related links:
> [1] https://lkml.org/lkml/2017/2/3/716
> [2] https://lkml.org/lkml/2017/2/3/719
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 022ccec49cea..7a4868a0afec 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -697,7 +698,6 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> struct device *dev = >dev;
> struct mtk_dpi *dpi;
> struct resource *mem;
> - struct device_node *bridge_node;
> int comp_id;
> int ret;
>
> @@ -743,16 +743,14 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - bridge_node = of_graph_get_remote_node(dev->of_node, 0, 0);
> - if (!bridge_node)
> - return -ENODEV;
> -
> - dev_info(dev, "Found bridge node: %pOF\n", bridge_node);
> -
> - dpi->bridge = of_drm_find_bridge(bridge_node);
> - of_node_put(bridge_node);
> - if (!dpi->bridge)
> + ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> + NULL, >bridge);
> + if (ret) {
> + dev_err(dev, "Failed to find panel or bridge: %d\n", ret);
> return -EPROBE_DEFER;
I've traced into drm_of_find_panel_or_bridge(), it may return -ENODEV
when device tree has error, why do you treat this error to
-EPROBE_DEFER? I think you may modify this as
if (ret)
return ret;
Regards,
CK
> + }
> +
> + dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
>
> comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
> if (comp_id < 0) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/5] drm: more byteorder fixes
On Wed, Sep 19, 2018 at 01:12:47PM +0200, Gerd Hoffmann wrote: > Fix fbdev emulation. > Fix bochs-drm and virtio-gpu drivers. > > Gerd Hoffmann (5): > drm: move native byte order quirk to new drm_mode_legacy_fb_format2 > function > drm: use drm_mode_legacy_fb_format2 in drm_gem_fbdev_fb_create > drm/bochs: fix DRM_FORMAT_* handling for big endian machines. > drm/bochs: support changing byteorder at mode set time > drm/virtio: fix DRM_FORMAT_* handling Aside from the "naming is hard" nit, series looks good. With the naming figured out somehow, Acked-by: Daniel Vetter on the entire series. -Daniel > > drivers/gpu/drm/bochs/bochs.h| 4 +- > include/drm/drm_fourcc.h | 2 + > drivers/gpu/drm/bochs/bochs_fbdev.c | 18 ++-- > drivers/gpu/drm/bochs/bochs_hw.c | 64 > ++-- > drivers/gpu/drm/bochs/bochs_kms.c| 40 - > drivers/gpu/drm/drm_fourcc.c | 28 > drivers/gpu/drm/drm_framebuffer.c| 15 ++- > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 ++- > drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++ > drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +- > drivers/gpu/drm/virtio/virtgpu_gem.c | 7 ++- > drivers/gpu/drm/virtio/virtgpu_plane.c | 54 +-- > 12 files changed, 155 insertions(+), 90 deletions(-) > > -- > 2.9.3 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/5] drm: move native byte order quirk to new drm_mode_legacy_fb_format2 function
On Wed, Sep 19, 2018 at 01:12:48PM +0200, Gerd Hoffmann wrote:
> Turns out we need the pixel format fixup not only for the addfb ioctl,
> but also for fbdev emulation code.
>
> Ideally we would place it in drm_mode_legacy_fb_format(). That would
> create alot of churn though, and most drivers don't care because they
> never ever run on a big endian platform. So add a new
> drm_mode_legacy_fb_format2() function instead.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_fourcc.h | 2 ++
> drivers/gpu/drm/drm_fourcc.c | 28
> drivers/gpu/drm/drm_framebuffer.c | 15 +++
> 3 files changed, 33 insertions(+), 12 deletions(-)
>
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index fac831c401..4b82bb6576 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -88,6 +88,8 @@ const struct drm_format_info *
> drm_get_format_info(struct drm_device *dev,
> const struct drm_mode_fb_cmd2 *mode_cmd);
> uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
> +uint32_t drm_mode_legacy_fb_format2(uint32_t bpp, uint32_t depth,
> + bool native);
> int drm_format_num_planes(uint32_t format);
> int drm_format_plane_cpp(uint32_t format, int plane);
> int drm_format_horz_chroma_subsampling(uint32_t format);
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index be1d6aaef6..1c1aaa8b23 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -96,6 +96,34 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t
> depth)
> EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>
> /**
> + * drm_mode_legacy_fb_format2 - compute drm fourcc code from legacy
> description
> + * @bpp: bits per pixels
> + * @depth: bit depth per pixel
> + * @native: use host native byte order
> + *
> + * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
> + * Useful in fbdev emulation code, since that deals in those values.
> + */
> +uint32_t drm_mode_legacy_fb_format2(uint32_t bpp, uint32_t depth,
> + bool native)
A _2 function is a bit meh imo. What about legacy_fb_format_native()
instead, which unconditionally gives you the native format, and then
pulling the if (native) out?
Or slightly more future proof (given that we have the nouveau hack too):
drm_device_legacy_fb_format(drm_device *dev, bpp, depth);
to make it clear that this is the device-specific conversion function.
-Daniel
> +{
> + uint32_t fmt = drm_mode_legacy_fb_format(bpp, depth);
> +
> + if (native) {
> + if (fmt == DRM_FORMAT_XRGB)
> + fmt = DRM_FORMAT_HOST_XRGB;
> + if (fmt == DRM_FORMAT_ARGB)
> + fmt = DRM_FORMAT_HOST_ARGB;
> + if (fmt == DRM_FORMAT_RGB565)
> + fmt = DRM_FORMAT_HOST_RGB565;
> + if (fmt == DRM_FORMAT_XRGB1555)
> + fmt = DRM_FORMAT_HOST_XRGB1555;
> + }
> + return fmt;
> +}
> +EXPORT_SYMBOL(drm_mode_legacy_fb_format2);
> +
> +/**
> * drm_get_format_name - fill a string with a drm fourcc format's name
> * @format: format to compute name of
> * @buf: caller-supplied buffer
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index 1ee3d6b442..f72e3dffc7 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -111,12 +111,14 @@ int drm_mode_addfb(struct drm_device *dev, struct
> drm_mode_fb_cmd *or,
> struct drm_file *file_priv)
> {
> struct drm_mode_fb_cmd2 r = {};
> + bool native = dev->mode_config.quirk_addfb_prefer_host_byte_order;
> int ret;
>
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> return -EOPNOTSUPP;
>
> - r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
> + r.pixel_format = drm_mode_legacy_fb_format2(or->bpp, or->depth,
> + native);
> if (r.pixel_format == DRM_FORMAT_INVALID) {
> DRM_DEBUG("bad {bpp:%d, depth:%d}\n", or->bpp, or->depth);
> return -EINVAL;
> @@ -133,17 +135,6 @@ int drm_mode_addfb(struct drm_device *dev, struct
> drm_mode_fb_cmd *or,
> r.pixel_format == DRM_FORMAT_XRGB2101010)
> r.pixel_format = DRM_FORMAT_XBGR2101010;
>
> - if (dev->mode_config.quirk_addfb_prefer_host_byte_order) {
> - if (r.pixel_format == DRM_FORMAT_XRGB)
> - r.pixel_format = DRM_FORMAT_HOST_XRGB;
> - if (r.pixel_format == DRM_FORMAT_ARGB)
> - r.pixel_format = DRM_FORMAT_HOST_ARGB;
> - if (r.pixel_format == DRM_FORMAT_RGB565)
> - r.pixel_format = DRM_FORMAT_HOST_RGB565;
> - if (r.pixel_format == DRM_FORMAT_XRGB1555)
> -
Re: [Intel-gfx] [PATCH 2/2] drm: Fix syncobj handing of schedule() returning 0
Quoting Daniel Vetter (2018-09-21 10:15:41) > On Tue, Sep 18, 2018 at 11:07:20AM +0100, Chris Wilson wrote: > > After schedule() returns 0, we must do one last check of COND to > > determine the reason for the wakeup with 0 jiffies remaining before > > reporting the timeout -- otherwise we may lose the signal due to > > scheduler delays. > > Ah classic! > > Reviewed-by: Daniel Vetter Indeed, thanks for the reviews, pushed to drm-misc-next. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: set i915 driver probe to asynchronous
On Wed, Sep 19, 2018 at 03:37:12PM +0800, ning.a.zh...@intel.com wrote:
> From: Zhang Ning
>
> when i915 is built in module, and system has built-in display, eg. eDP,
> i915 will detect and active it during driver probe. it will take long
> time.
>
> set i915 driver probe to asynchrous can save kernel initial time.
>
> Signed-off-by: Zhang Ning
Last time around this was proposed there was a very long discussion around
how this breaks the sound driver. Was this resolved? Definitely needs to
add this context to the commit message, and all people involved back then
added to the Cc: list. Searching for PROBE_PREFER_ASYNCHRONOUS in the
archives should dig it all up.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 6a4d1388ad2d..0f57d71d0abb 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -738,6 +738,7 @@ static struct pci_driver i915_pci_driver = {
> .probe = i915_pci_probe,
> .remove = i915_pci_remove,
> .driver.pm = _pm_ops,
> + .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> };
>
> static int __init i915_init(void)
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead
On Tue, Sep 18, 2018 at 07:06:19PM -0400, Lyude Paul wrote:
> Currently we set intel_connector->mst_port to NULL to signify that the
> MST port has been removed from the system so that we can prevent further
> action on the port such as connector probes, mode probing, etc.
> However, we're going to need access to intel_connector->mst_port in
> order to fixup ->best_encoder() so that it can always return the correct
> encoder for an MST port to prevent legacy DPMS prop changes from
> failing. This should be safe, so instead keep intel_connector->mst_port
> always set and instead add intel_connector->mst_port_gone in order to
> signify whether or not the connector has disappeared from the system.
>
> Signed-off-by: Lyude Paul
> Cc: sta...@vger.kernel.org
Hm, how exactly do legacy DPMS setprop blow up here? Or at least I can't
come up with a scenario that's specific to legacy props, atomic should be
equally affected. By the time we land in this code, the core code already
remapping it to be purely an atomic update.
Another thought: Should we handle at least some of this in the probe
helpers? I.e. once you unplugged a drm_connector, it always shows
disconnected and mode list is gone, instead of duplicating this over all
drivers. We could just check connector->registered.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_dp_mst.c | 14 +++---
> drivers/gpu/drm/i915/intel_drv.h| 1 +
> 2 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 4ecd65375603..fcb9b87b9339 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -311,9 +311,8 @@ static int intel_dp_mst_get_ddc_modes(struct
> drm_connector *connector)
> struct edid *edid;
> int ret;
>
> - if (!intel_dp) {
> + if (intel_connector->mst_port_gone)
> return intel_connector_update_modes(connector, NULL);
> - }
>
> edid = drm_dp_mst_get_edid(connector, _dp->mst_mgr,
> intel_connector->port);
> ret = intel_connector_update_modes(connector, edid);
> @@ -328,9 +327,10 @@ intel_dp_mst_detect(struct drm_connector *connector,
> bool force)
> struct intel_connector *intel_connector = to_intel_connector(connector);
> struct intel_dp *intel_dp = intel_connector->mst_port;
>
> - if (!intel_dp)
> + if (intel_connector->mst_port_gone)
> return connector_status_disconnected;
> - return drm_dp_mst_detect_port(connector, _dp->mst_mgr,
> intel_connector->port);
> + return drm_dp_mst_detect_port(connector, _dp->mst_mgr,
> + intel_connector->port);
> }
>
> static void
> @@ -370,7 +370,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> int bpp = 24; /* MST uses fixed bpp */
> int max_rate, mode_rate, max_lanes, max_link_clock;
>
> - if (!intel_dp)
> + if (intel_connector->mst_port_gone)
> return MODE_ERROR;
>
> if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> @@ -402,7 +402,7 @@ static struct drm_encoder
> *intel_mst_atomic_best_encoder(struct drm_connector *c
> struct intel_dp *intel_dp = intel_connector->mst_port;
> struct intel_crtc *crtc = to_intel_crtc(state->crtc);
>
> - if (!intel_dp)
> + if (intel_connector->mst_port_gone)
> return NULL;
> return _dp->mst_encoders[crtc->pipe]->base.base;
> }
> @@ -514,7 +514,7 @@ static void intel_dp_destroy_mst_connector(struct
> drm_dp_mst_topology_mgr *mgr,
> connector);
> /* prevent race with the check in ->detect */
> drm_modeset_lock(>dev->mode_config.connection_mutex, NULL);
> - intel_connector->mst_port = NULL;
> + intel_connector->mst_port_gone = true;
> drm_modeset_unlock(>dev->mode_config.connection_mutex);
>
> drm_connector_put(connector);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 8fc61e96754f..87ce772ae7f8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -409,6 +409,7 @@ struct intel_connector {
> void *port; /* store this opaque as its illegal to dereference it */
>
> struct intel_dp *mst_port;
> + bool mst_port_gone;
>
> /* Work struct to schedule a uevent on link train failure */
> struct work_struct modeset_retry_work;
> --
> 2.17.1
>
> ___
> 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: [Intel-gfx] [PATCH v3] drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS
On Tue, Sep 18, 2018 at 09:02:04PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 10:48:09AM -0700, José Roberto de Souza wrote:
> > All DRM_CLIENT capabilities are tied to KMS support, so returning
> > -EOPNOTSUPP when KMS is not supported.
> >
> > v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
> > in uapi) instead of -ENOTSUPP
> >
> > v3: adding comments about the feature requirement about capabilities
> >
> > Cc: Chris Wilson
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_ioctl.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index 60dfbfae6a02..94bd872d56c4 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -306,6 +306,12 @@ drm_setclientcap(struct drm_device *dev, void *data,
> > struct drm_file *file_priv)
> > {
> > struct drm_set_client_cap *req = data;
> >
> > + /* No render-only settable capabilities for now */
> > +
> > + /* Below caps that only works with KMS drivers */
>
> That doesn't seem quite English.
Looks close enough to me, so applied. Ime if you want to polish English,
it's best to just suggest a different wording, but then we don't have a
whole lot of professional English editors around here :-)
Thanks for the patch.
-Daniel
>
> > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > + return -EOPNOTSUPP;
> > +
> > switch (req->capability) {
> > case DRM_CLIENT_CAP_STEREO_3D:
> > if (req->value > 1)
> > --
> > 2.19.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
> ___
> 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: [PATCH 1/2] drm/fourcc: rename Intel modifiers to follow the naming convention
On Tue, Sep 18, 2018 at 06:21:59PM +0100, Eric Engestrom wrote:
> All the other vendors use the format
> DRM_FORMAT_MOD_{SAMSUNG,QCOM,VIVANTE,NVIDIA,BROADCOM,ARM}_* for their
> modifiers, except Intel.
>
> Suggested-by: Gerd Hoffmann
> Signed-off-by: Eric Engestrom
I think it'd be good to add why you want this (easier to parse in tooling,
or something like that was what you said on irc). With that addressed,
Reviewed-by: Daniel Vetter on both patches.
Probably best if you get i915 maintainers to merge both through drm-intel.
-Daniel
> ---
> include/uapi/drm/drm_fourcc.h | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 139632b871816f9e3dad..170a562223387687592a 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -271,7 +271,8 @@ extern "C" {
> * sharing. It exists since on a given platform it does uniquely identify the
> * layout in a simple way for i915-specific userspace.
> */
> -#define I915_FORMAT_MOD_X_TILED fourcc_mod_code(INTEL, 1)
> +#define DRM_FORMAT_MOD_INTEL_X_TILED fourcc_mod_code(INTEL, 1)
> +#define I915_FORMAT_MOD_X_TILED DRM_FORMAT_MOD_INTEL_X_TILED
>
> /*
> * Intel Y-tiling layout
> @@ -286,7 +287,8 @@ extern "C" {
> * sharing. It exists since on a given platform it does uniquely identify the
> * layout in a simple way for i915-specific userspace.
> */
> -#define I915_FORMAT_MOD_Y_TILED fourcc_mod_code(INTEL, 2)
> +#define DRM_FORMAT_MOD_INTEL_Y_TILED fourcc_mod_code(INTEL, 2)
> +#define I915_FORMAT_MOD_Y_TILED DRM_FORMAT_MOD_INTEL_Y_TILED
>
> /*
> * Intel Yf-tiling layout
> @@ -301,7 +303,8 @@ extern "C" {
> * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the
> width
> * in pixel depends on the pixel depth.
> */
> -#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
> +#define DRM_FORMAT_MOD_INTEL_Yf_TILED fourcc_mod_code(INTEL, 3)
> +#define I915_FORMAT_MOD_Yf_TILED DRM_FORMAT_MOD_INTEL_Yf_TILED
>
> /*
> * Intel color control surface (CCS) for render compression
> @@ -320,8 +323,10 @@ extern "C" {
> * But that fact is not relevant unless the memory is accessed
> * directly.
> */
> -#define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
> -#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
> +#define DRM_FORMAT_MOD_INTEL_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
> +#define I915_FORMAT_MOD_Y_TILED_CCS DRM_FORMAT_MOD_INTEL_Y_TILED_CCS
> +#define DRM_FORMAT_MOD_INTEL_Yf_TILED_CCSfourcc_mod_code(INTEL, 5)
> +#define I915_FORMAT_MOD_Yf_TILED_CCS DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS
>
> /*
> * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> --
> Cheers,
> Eric
>
--
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: [Intel-gfx] [PATCH 2/2] drm: Fix syncobj handing of schedule() returning 0
On Tue, Sep 18, 2018 at 11:07:20AM +0100, Chris Wilson wrote:
> After schedule() returns 0, we must do one last check of COND to
> determine the reason for the wakeup with 0 jiffies remaining before
> reporting the timeout -- otherwise we may lose the signal due to
> scheduler delays.
Ah classic!
Reviewed-by: Daniel Vetter
> References: https://bugs.freedesktop.org/show_bug.cgi?id=106690
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_syncobj.c | 41 +--
> 1 file changed, 15 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index e254f97fed7d..5bcb3ef9b256 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -672,7 +672,6 @@ static signed long drm_syncobj_array_wait_timeout(struct
> drm_syncobj **syncobjs,
> {
> struct syncobj_wait_entry *entries;
> struct dma_fence *fence;
> - signed long ret;
> uint32_t signaled_count, i;
>
> entries = kcalloc(count, sizeof(*entries), GFP_KERNEL);
> @@ -692,7 +691,7 @@ static signed long drm_syncobj_array_wait_timeout(struct
> drm_syncobj **syncobjs,
> if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
> continue;
> } else {
> - ret = -EINVAL;
> + timeout = -EINVAL;
> goto cleanup_entries;
> }
> }
> @@ -704,12 +703,6 @@ static signed long drm_syncobj_array_wait_timeout(struct
> drm_syncobj **syncobjs,
> }
> }
>
> - /* Initialize ret to the max of timeout and 1. That way, the
> - * default return value indicates a successful wait and not a
> - * timeout.
> - */
> - ret = max_t(signed long, timeout, 1);
> -
> if (signaled_count == count ||
> (signaled_count > 0 &&
>!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL)))
> @@ -760,18 +753,17 @@ static signed long
> drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
> goto done_waiting;
>
> if (timeout == 0) {
> - /* If we are doing a 0 timeout wait and we got
> - * here, then we just timed out.
> - */
> - ret = 0;
> + timeout = -ETIME;
> goto done_waiting;
> }
>
> - ret = schedule_timeout(ret);
> + if (signal_pending(current)) {
> + timeout = -ERESTARTSYS;
> + goto done_waiting;
> + }
>
> - if (ret > 0 && signal_pending(current))
> - ret = -ERESTARTSYS;
> - } while (ret > 0);
> + timeout = schedule_timeout(timeout);
> + } while (1);
>
> done_waiting:
> __set_current_state(TASK_RUNNING);
> @@ -788,7 +780,7 @@ static signed long drm_syncobj_array_wait_timeout(struct
> drm_syncobj **syncobjs,
> }
> kfree(entries);
>
> - return ret;
> + return timeout;
> }
>
> /**
> @@ -829,19 +821,16 @@ static int drm_syncobj_array_wait(struct drm_device
> *dev,
> struct drm_syncobj **syncobjs)
> {
> signed long timeout = drm_timeout_abs_to_jiffies(wait->timeout_nsec);
> - signed long ret = 0;
> uint32_t first = ~0;
>
> - ret = drm_syncobj_array_wait_timeout(syncobjs,
> - wait->count_handles,
> - wait->flags,
> - timeout, );
> - if (ret < 0)
> - return ret;
> + timeout = drm_syncobj_array_wait_timeout(syncobjs,
> + wait->count_handles,
> + wait->flags,
> + timeout, );
> + if (timeout < 0)
> + return timeout;
>
> wait->first_signaled = first;
> - if (ret == 0)
> - return -ETIME;
> return 0;
> }
>
> --
> 2.19.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: [PATCH v3 04/12] drm/mediatek: add clock factor for different IC
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> different IC has different clock designed in HDMI, the factor for
> calculate clock should be different. Usinng the data in of_node
> to find this factor.
>
Reviewed-by: CK Hu
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 1e7369e0d91c..022ccec49cea 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -120,6 +120,7 @@ struct mtk_dpi_yc_limit {
> };
>
> struct mtk_dpi_conf {
> + unsigned int (*cal_factor)(int clock);
> u32 reg_h_fre_con;
> bool edge_sel_en;
> };
> @@ -460,15 +461,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> unsigned int factor;
>
> /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
> -
> - if (mode->clock <= 27000)
> - factor = 3 << 4;
> - else if (mode->clock <= 84000)
> - factor = 3 << 3;
> - else if (mode->clock <= 167000)
> - factor = 3 << 2;
> - else
> - factor = 3 << 1;
> + factor = dpi->conf->cal_factor(mode->clock);
> drm_display_mode_to_videomode(mode, );
> pll_rate = vm.pixelclock * factor;
>
> @@ -682,7 +675,20 @@ static const struct component_ops mtk_dpi_component_ops
> = {
> .unbind = mtk_dpi_unbind,
> };
>
> +static unsigned int mt8173_calculate_factor(int clock)
> +{
> + if (clock <= 27000)
> + return 3 << 4;
> + else if (clock <= 84000)
> + return 3 << 3;
> + else if (clock <= 167000)
> + return 3 << 2;
> + else
> + return 3 << 1;
> +}
> +
> static const struct mtk_dpi_conf mt8173_conf = {
> + .cal_factor = mt8173_calculate_factor,
> .reg_h_fre_con = 0xe0,
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Use default dma_fence hooks where possible for null syncobj
On Tue, Sep 18, 2018 at 11:07:19AM +0100, Chris Wilson wrote:
> Both the .enable_signaling and .release of the null syncobj fence
> can be replaced by the default callbacks for a small reduction in code
> size.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_syncobj.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 497729202bfe..e254f97fed7d 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -66,20 +66,9 @@ static const char *drm_syncobj_stub_fence_get_name(struct
> dma_fence *fence)
> return "syncobjstub";
> }
>
> -static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
> -{
> -return !dma_fence_is_signaled(fence);
> -}
> -
> -static void drm_syncobj_stub_fence_release(struct dma_fence *f)
> -{
> - kfree(f);
> -}
> static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
> .get_driver_name = drm_syncobj_stub_fence_get_name,
> .get_timeline_name = drm_syncobj_stub_fence_get_name,
> - .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
> - .release = drm_syncobj_stub_fence_release,
> };
>
>
> --
> 2.19.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/probe_helper: Don't bother probing when connectors are forced off
On Mon, Sep 17, 2018 at 05:12:04PM -0400, Lyude Paul wrote:
> On Mon, 2018-09-17 at 21:16 +0300, Ville Syrjälä wrote:
> > On Mon, Sep 17, 2018 at 02:10:02PM -0400, Lyude Paul wrote:
> > > On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> > > > On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> > > > > Userspace asked them to be forced off, so why would we care about
> > > > > what a
> > > > > probe tells us?
> > > >
> > > > I believe there should be force checks in the callers already.
> > > > Or are we missing some?
> > >
> > > JFYI, what triggered me to send this patch are these error messages that
> > > come
> > > from nouveau when a hotplug happens on a port that we've forced off:
> > >
> > > [ 1903.918104] nouveau :01:00.0: DRM: DDC responded, but no EDID for
> > > DP-
> > > 2
> > > [ 1903.918123] [drm:drm_helper_hpd_irq_event [drm_kms_helper]]
> > > [CONNECTOR:61:DP-2] status updated from disconnected to disconnected
> > >
> > > That being said; I'm sure there are probably some checks missing, but I
> > > don't
> > > really see the purpose in calling the driver's probe functions at all if
> > > they're
> > > just supposed to return the status we forced.
> >
> > Digging through my cobweb ridden local git repository I found this:
> >
> > commit bbd17813a7c7d0210c619365707044d0fb29e3f0
> > Author: Ville Syrjälä
> > Date: Mon Jun 10 15:28:55 2013 +0300
> >
> > drm: Ignore forced connectors in drm_helper_hpd_irq_event()
> >
> > drm_helper_hpd_irq_event() calls the connector's .detect() function
> > even for forced connectors. If the returned status doesn't match the
> > forced status, we will send the hotplug event, causing userspace to
> > re-probe all the connectors. Eventually we should end up back where
> > we started when drm_helper_probe_single_connector_modes() overwrites
> > the connector status with the forced status.
> >
> > We can avoid all that pointles work if we just skip forced connectors
> > in drm_helper_hpd_irq_event().
> >
> > Signed-off-by: Ville Syrjälä
> >
> > diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> > b/drivers/gpu/drm/drm_crtc_helper.c
> > index ed1334e27c33..4fc2ad76c107 100644
> > --- a/drivers/gpu/drm/drm_crtc_helper.c
> > +++ b/drivers/gpu/drm/drm_crtc_helper.c
> > @@ -1086,6 +1086,10 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
> > mutex_lock(>mode_config.mutex);
> > list_for_each_entry(connector, >mode_config.connector_list, head) {
> >
> > + /* Ignore forced connectors. */
> > + if (connector->force)
> > + continue;
> > +
> > /* Only handle HPD capable connectors. */
> > if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
> > continue;
> >
> >
> > I guess I never sent it out.
>
> Ahhh, to be honest though this patch isn't really enough.
> drm_helper_hpd_irq_event() isn't going to be used by all drivers (I may remove
> some usage of it in nouveau in the near future, even) so I still think it
> would
> be a better idea to just add this into drm_helper_probe_detect() and
> drm_helper_probe_detect_ctx() so everything gets covered
Atm all connector->force handling is outside of drm_helper_probe_detect. I
guess we could try to push (some) of it into this helper, if that's
useful. There seems to be some duplication already. But adding a redundant
check like you do here feels a bit funky. Maybe makes more sense in
context of the nouveau stuff you're working on?
-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
[PATCH] drm/exynos: simplify DMA mapping
Moving DMA mapping creation to drm_iommu_attach_device allows to avoid
looping through all components and maintaining DMA device flags.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 50 +++
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 13 +-
2 files changed, 17 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b599f74692e5..c83437d8a595 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -197,8 +197,7 @@ struct exynos_drm_driver_info {
#define DRM_COMPONENT_DRIVER BIT(0) /* supports component framework */
#define DRM_VIRTUAL_DEVICE BIT(1) /* create virtual platform device */
-#define DRM_DMA_DEVICE BIT(2) /* can be used for dma allocations */
-#define DRM_FIMC_DEVICEBIT(3) /* devices shared with V4L2
subsystem */
+#define DRM_FIMC_DEVICEBIT(2) /* devices shared with V4L2
subsystem */
#define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? : NULL)
@@ -209,16 +208,16 @@ struct exynos_drm_driver_info {
static struct exynos_drm_driver_info exynos_drm_drivers[] = {
{
DRV_PTR(fimd_driver, CONFIG_DRM_EXYNOS_FIMD),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(exynos5433_decon_driver, CONFIG_DRM_EXYNOS5433_DECON),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(decon_driver, CONFIG_DRM_EXYNOS7_DECON),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
DRM_COMPONENT_DRIVER
@@ -289,27 +288,6 @@ static struct component_match *exynos_drm_match_add(struct
device *dev)
return match ?: ERR_PTR(-ENODEV);
}
-static struct device *exynos_drm_get_dma_device(void)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) {
- struct exynos_drm_driver_info *info = _drm_drivers[i];
- struct device *dev;
-
- if (!info->driver || !(info->flags & DRM_DMA_DEVICE))
- continue;
-
- while ((dev = bus_find_device(_bus_type, NULL,
- >driver->driver,
- (void *)platform_bus_type.match))) {
- put_device(dev);
- return dev;
- }
- }
- return NULL;
-}
-
static int exynos_drm_bind(struct device *dev)
{
struct exynos_drm_private *private;
@@ -334,23 +312,6 @@ static int exynos_drm_bind(struct device *dev)
dev_set_drvdata(dev, drm);
drm->dev_private = (void *)private;
- /* the first real CRTC device is used for all dma mapping operations */
- private->dma_dev = exynos_drm_get_dma_device();
- if (!private->dma_dev) {
- DRM_ERROR("no device found for DMA mapping operations.\n");
- ret = -ENODEV;
- goto err_free_private;
- }
- DRM_INFO("Exynos DRM: using %s device for DMA mapping operations\n",
-dev_name(private->dma_dev));
-
- /* create common IOMMU mapping for all devices attached to Exynos DRM */
- ret = drm_create_iommu_mapping(drm);
- if (ret < 0) {
- DRM_ERROR("failed to create iommu mapping.\n");
- goto err_free_private;
- }
-
drm_mode_config_init(drm);
exynos_drm_mode_config_init(drm);
@@ -408,7 +369,6 @@ static int exynos_drm_bind(struct device *dev)
err_mode_config_cleanup:
drm_mode_config_cleanup(drm);
drm_release_iommu_mapping(drm);
-err_free_private:
kfree(private);
err_free_drm:
drm_dev_put(drm);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
index 0f373702414e..bb8b800a9fba 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
@@ -75,7 +75,18 @@ int drm_iommu_attach_device(struct drm_device *drm_dev,
struct exynos_drm_private *priv = drm_dev->dev_private;
int ret;
- if (get_dma_ops(priv->dma_dev) != get_dma_ops(subdrv_dev)) {
+ if (!priv->dma_dev) {
+ priv->dma_dev = subdrv_dev;
+ DRM_INFO("Exynos DRM: using %s device for DMA mapping
operations\n",
+dev_name(subdrv_dev));
+ /* create common IOMMU mapping for all Exynos DRM devices */
+ ret = drm_create_iommu_mapping(drm_dev);
+ if (ret < 0) {
+
Re: [PATCH] drm: fix use of freed memory in drm_mode_setcrtc
On Mon, Sep 17, 2018 at 02:00:54PM +0300, Tomi Valkeinen wrote: > drm_mode_setcrtc() retries modesetting in case one of the functions it > calls returns -EDEADLK. connector_set, mode and fb are freed before > retrying, but they are not set to NULL. This can cause > drm_mode_setcrtc() to use those variables. > > For example: On the first try __drm_mode_set_config_internal() returns > -EDEADLK. connector_set, mode and fb are freed. Next retry starts, and > drm_modeset_lock_all_ctx() returns -EDEADLK, and we jump to 'out'. The > code will happily try to release all three again. > > This leads to crashes of different kinds, depending on the sequence the > EDEADLKs happen. > > Fix this by setting the three variables to NULL at the start of the > retry loop. > > Signed-off-by: Tomi Valkeinen > Cc: sta...@vger.kernel.org > --- > drivers/gpu/drm/drm_crtc.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 2f6c877299e4..2ad14593fb23 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -570,9 +570,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, > struct drm_mode_crtc *crtc_req = data; > struct drm_crtc *crtc; > struct drm_plane *plane; > - struct drm_connector **connector_set = NULL, *connector; > - struct drm_framebuffer *fb = NULL; > - struct drm_display_mode *mode = NULL; > + struct drm_connector **connector_set, *connector; > + struct drm_framebuffer *fb; > + struct drm_display_mode *mode; > struct drm_mode_set set; > uint32_t __user *set_connectors_ptr; > struct drm_modeset_acquire_ctx ctx; > @@ -601,6 +601,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, > mutex_lock(>dev->mode_config.mutex); > drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE); > retry: > + connector_set = NULL; > + fb = NULL; > + mode = NULL; Bit a bikeshed, but I'd reset the pointers right after we release/free them, in the out: block. Avoids accidental leaking. But it's fine either way. And I agree with Ville, I don't think we need a cc: stable here. Reviewed-by: Daniel Vetter > + > ret = drm_modeset_lock_all_ctx(crtc->dev, ); > if (ret) > goto out; > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/vkms: Fix possible memory leak in _vkms_get_crc()
On Sat, Sep 15, 2018 at 01:53:19AM +, Wei Yongjun wrote:
> 'vaddr_out' is malloced in _vkms_get_crc() and should be freed before
> leaving from the error handling cases, otherwise it will cause memory
> leak.
>
> Fixes: db7f419c06d7 ("drm/vkms: Compute CRC with Cursor Plane")
> Signed-off-by: Wei Yongjun
Applied, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/vkms/vkms_crc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index 0a27456..9d9e814 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -125,6 +125,7 @@ static uint32_t _vkms_get_crc(struct vkms_crc_data
> *primary_crc,
> mutex_lock(_obj->pages_lock);
> if (WARN_ON(!vkms_obj->vaddr)) {
> mutex_unlock(_obj->pages_lock);
> + kfree(vaddr_out);
> return crc;
> }
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Revert "drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying the logic"
On Mon, Sep 17, 2018 at 01:25:49PM +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi Kieran,
>
> On Mon, Sep 17, 2018 at 11:56:23AM +0100, Kieran Bingham wrote:
> > Hi Alexandru,
> >
> > On 17/09/18 10:10, Alexandru-Cosmin Gheorghe wrote:
> > > Hi Kieran,
> > >
> > > Sorry for that and thanks for getting to the bottom of it.
> >
> > No worries,
> >
> >
> > > On Fri, Sep 14, 2018 at 11:28:05PM +0100, Kieran Bingham wrote:
> > >> Hi Laurent,
> > >>
> > >> I've looked through a bit further to try to understand this issue and I
> > >> think I have identified a possible/probable cause.
> > >>
> > >> Before commit 161ad653d6c9, we *always* set the plane->state->alpha as
> > >> DRM_BLEND_ALPHA_OPAQUE. (0x)
> > >>
> > >> After this commit, the __drm_atomic_helper_plane_reset() call will only
> > >> set state->alpha to 0x if the alpha_property is set:
> > >>
> > >> if (plane->alpha_property)
> > >> state->alpha = plane->alpha_property->values[1];
> > >>
> > >> Then the state->alpha value is always referenced in
> > >> rcar_du_vsp_plane_setup() and passed to the VSP for that layer.
> > >>
> > >>
> > >> We can see in rcar_du_planes_init(), that all OVERLAY planes are
> > >> configured to have this propery with a call to
> > >> drm_plane_create_alpha_property(>plane); however - the PRIMARY
> > >> plane is skipped over before setting this.
> > >>
> > >>
> > >> I believe I recall seeing that the kms-test-planeposition.py
> > >> successfully showed other planes which were not the back one (I'm now
> > >> going from hazy memory of this afternoon - but I am fairly sure I saw
> > >> this)
> > >>
> > >>
> > >> This implies that the primary planes are being incorrectly configured -
> > >> but the overlay planes are still functioning as expected.
> > >>
> > >> So I believe we could move the call to create the alpha property:
> > >> drm_plane_create_alpha_property(>plane);
> > >>
> > >> to occur before the if (type == DRM_PLANE_TYPE_PRIMARY) continue;
> > >> statement.
> > >>
> > >
> > > I don't see any reson why the primary plane shouldn't advertise an
> > > alpha as well.
> >
> >
> > OK - so I think we perhaps should make sure that we enable alpha for our
> > primary plane in rcar-du.
> >
> >
> > >> It may or may not make sense to have alpha blending support on the
> > >> PRIMARY plane. At the risk of sounding silly - can we have anything else
> > >> behind the PRIMARY plane ? (I doubt this, I don't think we have any
> > >> extra layers hiding anywhere)
> > >
> > > I think the same question could apply to situations where PRIMARY is
> > > disabled and you have just one OVERLAY plane enabled.
> > >
> > >>
> > >> Otherwise, I think we would need to intercept the configuration of the
> > >> alpha blending and make sure that all PRIMARY planes are configured to
> > >> be fully opaque in our layers. I think this is happening in
> > >> rcar_du_vsp_plane_setup().
> > >>
> > >> But rather than put in a conditional in there, I think I'd rather just
> > >> initialise the plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE in our
> > >> rcar_du_vsp_plane_reset() call and be done with it.
> > >
> > > I think you could do more and just go in
> > > __drm_atomic_helper_plane_reset and always initializes plane->alpha
> > > with DRM_BLEND_ALPHA_OPAQUE, this way nobody else hits this problem.
> >
> > I think this sounds like a good thing too.
> >
> > Is DRM_BLEND_ALPHA_OPAQUE a suitable initial value for all of the other
> > users of the helper ?
> >
> > I suspect the answer is yes, but I'll try to do a bit of digging through
> > the other drivers tomorrow.
> >
>
> Yes, but it doesn't hurt for another pair of eyes to have a look.
Just hard-code init alpha to OPAQUE is imo the correct fix. The current is
not matching the general style we use for state parameters at all, and I
don't see a reason why it's different. The comment is what the code should
actually do I think.
-Daniel
>
> > I presume we could then just remove the conditional check and always
> > initialise to OPAQUE ...
> >
> > Or otherwise perhaps maybe initialising as an 'else' if no alpha
> > property is provided.
> >
> > --
> > Regards
> >
> > Kieran
> >
> >
> >
> >
> >
> >
> > >>
> > >> Anyway - just some musings and thoughts at this stage, we can
> > >> investigate in more detail next week.
> > >>
> > >> --
> > >> Regards
> > >>
> > >> Kieran
> > >>
> > >>
> > >> On 14/09/18 21:09, Kieran Bingham wrote:
> > >>> Commit: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
> > >>> instead of copying the logic") causes a regression in the R-Car DU
> > >>> display driver, and prevents any output from being displayed.
> > >>>
> > >>> The display appears to function correctly but only a black screen is
> > >>> ever visible.
> > >>>
> > >>> Revert the commit.
> > >>>
> > >>> Signed-off-by: Kieran Bingham
> > >>>
> > >>> ---
> > >>>
> > >>> Looking through the code, the reason for this issue isn't particularly
> > >>>
Re: [PATCH v4 5/5] drm: bridge: add support for Cadence MHDP DPI/DP bridge
Hi Damian, Am Donnerstag, 20. September 2018, 16:54:40 CEST schrieb Damian Kos: > From: Quentin Schulz > > This adds basic support for Cadence MHDP DPI to DP bridge. > > Basically, it takes a DPI stream as input and output it encoded in DP > format. It's missing proper HPD, HDCP and currently supports only > SST mode. > > Changes made in the low level driver (cdn-dp-reg.*): > - moved it to from drivers/gpu/drm/rockchip to > drivers/gpu/drm/bridge/cdns-mhdp-common.* > - functions for sending/receiving commands are now public > - added functions for reading registers and link training > adjustment > > Changes made in RK's driver (cdn-dp-core.*): > - Moved audio_info and audio_pdev fields from cdn_dp_device to > cdns_mhdp_device structure. > > Signed-off-by: Quentin Schulz > Signed-off-by: Damian Kos [...] > diff --git a/drivers/gpu/drm/rockchip/Kconfig > b/drivers/gpu/drm/rockchip/Kconfig > index 0ccc76217ee4..129b0529f3e1 100644 > --- a/drivers/gpu/drm/rockchip/Kconfig > +++ b/drivers/gpu/drm/rockchip/Kconfig > @@ -27,7 +27,9 @@ config ROCKCHIP_ANALOGIX_DP > > config ROCKCHIP_CDN_DP > bool "Rockchip cdn DP" > - depends on EXTCON=y || (EXTCON=m && DRM_ROCKCHIP=m) > + depends on DRM_ROCKCHIP=m Sorry, I wasn't fast enough in my reply to you mail to catch that before your v4, but I don't think this is necessary. Instead I do guess, the select below should do the right thing by making EXTCON=y if DRM_ROCKCHIP=y. Somewhat clumsily verified by making EXTCON=m in my defconfig and seeing get changed to y upon build, which I guess comes from a different "select" in the config. > + select EXTCON > + select DRM_CDNS_MHDP > help > This selects support for Rockchip SoC specific extensions > for the cdn DP driver. If you want to enable Dp on > diff --git a/drivers/gpu/drm/rockchip/Makefile > b/drivers/gpu/drm/rockchip/Makefile > index a314e2109e76..16ba61ffca39 100644 > --- a/drivers/gpu/drm/rockchip/Makefile > +++ b/drivers/gpu/drm/rockchip/Makefile > @@ -3,13 +3,15 @@ > # Makefile for the drm device driver. This driver provides support for the > # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > +ccflags-y += -I$(src)/../bridge hmm, instead of adding an include path, the shared header should probably just live in /include/drm/bridge/... in the kernel source? Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We'll be wanting to send more than just infoframes over HDMI. So add an
> enum for other packet types.
>
> TODO: Maybe just include the infoframe types in the packet type enum
> and get rid of the infoframe type enum?
I think that's better, IMHO. With a comment that the types starting with
0x81 are defined in CTA-861-G.
It's really the same byte that is being checked, so having two enums is
a bit misleading. The main difference is really which standard defines
the packet types.
Regards,
Hans
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> include/linux/hdmi.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index c76b50a48e48..80521d9591a1 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -27,6 +27,21 @@
> #include
> #include
>
> +enum hdmi_packet_type {
> + HDMI_PACKET_TYPE_NULL = 0x00,
> + HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
> + HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
> + HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
> + HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
> + HDMI_PACKET_TYPE_ISRC1 = 0x05,
> + HDMI_PACKET_TYPE_ISRC2 = 0x06,
> + HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
> + HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
> + HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
> + HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
> + /* + enum hdmi_infoframe_type */
> +};
> +
> enum hdmi_infoframe_type {
> HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
> HDMI_INFOFRAME_TYPE_AVI = 0x82,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
Hi Simon,
On Friday, 21 September 2018 10:16:44 EEST Simon Horman wrote:
> On Wed, Sep 19, 2018 at 04:11:36PM +0300, Laurent Pinchart wrote:
> > On Wednesday, 19 September 2018 11:35:07 EEST Simon Horman wrote:
> >> On Mon, Sep 17, 2018 at 11:59:32AM +0300, Laurent Pinchart wrote:
> >>> On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote:
> On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote:
> > On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote:
> >> On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote:
> >>> On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> The R8A77990 (E3) platform has one RGB output and two LVDS
> outputs connected to the DU. Add the DT nodes for the DU, LVDS
> encoders and supporting VSP and FCP.
>
> Signed-off-by: Laurent Pinchart
>
> Tested-by: Jacopo Mondi
> ---
>
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 +
> 1 file changed, 167 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index
> abb14af76c0e..600074ca3ee5 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >
> > [snip]
> >
> +lvds0: lvds-encoder@feb9 {
> +compatible = "renesas,r8a77990-lvds";
> +reg = <0 0xfeb9 0 0x20>;
> +clocks = < CPG_MOD 727>;
> +power-domains = < R8A77990_PD_ALWAYS_ON>;
> +resets = < 727>;
> +status = "disabled";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +lvds0_in: endpoint {
> +remote-endpoint =
> <_out_lvds0>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +lvds0_out: endpoint {
> +};
> +};
> +};
> +};
> +
> +lvds1: lvds-encoder@feb90100 {
> +compatible = "renesas,r8a77990-lvds";
> +reg = <0 0xfeb90100 0 0x20>;
> +clocks = < CPG_MOD 727>;
> +power-domains = < R8A77990_PD_ALWAYS_ON>;
> +resets = < 726>;
> >>
> >> Also, is the missmatch between the index for the clock and reset
> >> intentional?
> >
> > It is. According to the datasheet, the two LVDS encoders have
> > different module stop bits, but share the same reset (lovely
> > hardware design, it will be fun to support that in the driver :-S).
>
> Sorry, I got it wrong. it's bit 725 that is shared between the two
> LVDS encoders, to reset the two LVDS PLLs together. The encoders
> themselves still have independent reset bits. I'll fix this.
> >>>
> >>> And of course it's the clock you were commenting on, not the reset.
> >>> *sigh*
> >>>
> >>> According to the datasheets the two LVDS encoders share one MSTP.
> >>> Whether that's a mistake in the documentation or not I can't tell yet,
> >>> as I have only tested LVDS0.
> >>
> >> Could we follow-up with the HW team?
> >> I'm not opposed to taking the patch with this portion as-is
> >> but it would be good to clarify this somehow.
> >
> > I tried setting the clock to MSTP 726, and I then get vblank interrupt
> > timeouts. Furthermore I've now tested the LVDS1 output with a display
> > panel, and while I still can't get the backlight to work, the panel
> > displays the correct image with MSTP 727. I thus conclude that the above
> > is correct.
>
> Thanks for the follow-up, that sounds reasonable to me.
>
> Am I correct in thinking a v3 of this patchset is on its way regardless?
Yes, you're correct.
> +status = "disabled";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Wed, Sep 19, 2018 at 01:57:00PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 02:10:17PM -0700, Manasi Navare wrote:
> > On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > > > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > > > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > > > > Thanks Imre for your review comments. Please find the comments
> > > > > > below:
> > > > > >
> > > > > > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > > > > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > > > > > On Icelake, a separate power well PG2 is created for
> > > > > > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > > > > > display power domain for Power well 2.
> > > > > > > >
> > > > > > > > Cc: Rodrigo Vivi
> > > > > > > > Cc: Imre Deak
> > > > > > > > Signed-off-by: Manasi Navare
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > > > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > > > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > > > > > POWER_DOMAIN_MODESET,
> > > > > > > > POWER_DOMAIN_GT_IRQ,
> > > > > > > > POWER_DOMAIN_INIT,
> > > > > > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > > > > > >
> > > > > > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > > > > > functionality which could be on separate power wells in the
> > > > > > > future.
> > > > > > >
> > > > > >
> > > > > > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe
> > > > > > A
> > > > > > will use this VDSC power well.
> > > > > > I will change this in the next revision.
> > > > >
> > > > > Isn't the VDSC in the transcoder for now though? And I guess it's
> > > > > moving to the pipe later?
> > > >
> > > > VDSC engine is attached to the eDP/DSI transcoders and this gets used
> > > > for eDP/DSI VDSC on Pipe A.
> > >
> > > And what happens when I want to use pipe B instead?
> >
> > DP VDSC on Pipe B uses the VDSC engine on Pipe B. Same for Pipe C
>
> There are no VDSCs in pipe B or C. There are VDSCs in transcoder B
> and C. But that's not the same thing at all. The mux is between the
> pipe and transcoder.
>
As per the display overview for Gen 11, the VDSC engine is present on Pipe B
And C.
But for Pipe A only, it uses VDSC engine attached to transcoder eDP/DSI.
> > Can we have a situation where eDP uses Pipe B?
>
> Sure. 'xrandr --output eDP --crtc 1', or whatever.
>
I guess even in this case, if its eDP/DSI, it will still use the VDSC engine
on transcoder eDP so will need to enable this power well 2.
Manasi
> > Because in case of VDSC
> > in case of eDP, it will always use the VDSC on transcoder eDP which will
> > require this power well.
> >
> > Manasi
> >
> > >
> > > > So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
> > > > will use this power well. But may be we should add a comment that
> > > > this is only for eDP/DSI on Pipe A since ICL does not support
> > > > VDSC on DP on Pipe A
> > > >
> > > > What do you think?
> > > >
> > > > Manasi
> > > >
> > > > >
> > > > > If we call it PIPE_A then it's going to a bit confusing when we
> > > > > use it with pipe B or C. Needs at least clear comments in the code
> > > > > why we're doing something that looks like nonsense of the first
> > > > > glance.
> > > > >
> > > > > --
> > > > > Ville Syrjälä
> > > > > Intel
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/18] video/hdmi: Handle the NTSC VBI infoframe
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the code to deal with the NTSC VBI infoframe.
>
> I decided against parsing the PES_data_field and just leave
> it as an opaque blob, just dumping it out as hex in the log.
>
> Blindly typed from the spec, and totally untested.
Do we have any driver that uses this? I would prefer to wait until someone
actually need this.
Regards,
Hans
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 208
> +++
> include/linux/hdmi.h | 18 +
> 2 files changed, 226 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 3d24c7746c51..3c320d69fa0a 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -831,6 +831,139 @@ ssize_t hdmi_mpeg_source_infoframe_pack(struct
> hdmi_mpeg_source_infoframe *frame
> }
> EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack);
>
> +/**
> + * hdmi_ntsc_vbi_infoframe_init() - initialize an HDMI NTSC VBI infoframe
> + * @frame: HDMI NTSC VBI infoframe
> + * @pes_data_field: ANSI/SCTE 127 PES_data_field
> + * @length: ANSI/SCTE 127 PES_data_field length
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_ntsc_vbi_infoframe_init(struct hdmi_ntsc_vbi_infoframe *frame,
> + const void *pes_data_field,
> + size_t length)
> +{
> + if (length < 1 || length > 27)
> + return -EINVAL;
> +
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_NTSC_VBI;
> + frame->version = 1;
> + frame->length = length;
> +
> + memcpy(frame->pes_data_field, pes_data_field, length);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_init);
> +
> +static int hdmi_ntsc_vbi_infoframe_check_only(const struct
> hdmi_ntsc_vbi_infoframe *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_NTSC_VBI ||
> + frame->version != 1 ||
> + frame->length < 1 || frame->length > 27)
> + return -EINVAL;
> +
> + if (frame->pes_data_field[0] != 0x99)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
> + * hdmi_ntsc_vbi_infoframe_check() - Check and check a HDMI NTSC VBI
> infoframe
> + * @frame: HDMI NTSC VBI infoframe
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_ntsc_vbi_infoframe_check(struct hdmi_ntsc_vbi_infoframe *frame)
> +{
> + return hdmi_ntsc_vbi_infoframe_check_only(frame);
> +}
> +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_check);
> +
> +/**
> + * hdmi_ntsc_vbi_infoframe_pack_only() - write HDMI NTSC VBI infoframe to
> binary buffer
> + * @frame: HDMI NTSC VBI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.4 specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_ntsc_vbi_infoframe_pack_only(const struct
> hdmi_ntsc_vbi_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + u8 *ptr = buffer;
> + size_t length;
> + int ret;
> +
> + ret = hdmi_ntsc_vbi_infoframe_check_only(frame);
> + if (ret)
> + return ret;
> +
> + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> +
> + if (size < length)
> + return -ENOSPC;
> +
> + memset(buffer, 0, size);
> +
> + ptr[0] = frame->type;
> + ptr[1] = frame->version;
> + ptr[2] = frame->length;
> + ptr[3] = 0; /* checksum */
> +
> + /* start infoframe payload */
> + ptr += HDMI_INFOFRAME_HEADER_SIZE;
> +
> + memcpy(ptr, frame->pes_data_field, frame->length);
> +
> + hdmi_infoframe_set_checksum(buffer, length);
> +
> + return length;
> +}
> +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_pack_only);
> +
> +/**
> + * hdmi_ntsc_vbi_infoframe_pack() - Check and check a HDMI NTSC VBI
> infoframe,
> + * and write it to binary buffer
> + * @frame: HDMI NTSC VBI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields, after which packs the information
> + * contained in the @frame structure into a binary representation that
> + * can be written into the corresponding controller registers. Also
> + * computes the checksum as required by section 5.3.5 of the HDMI 1.4
> + * specification.
Re: [PATCH 06/18] video/hdmi: Handle the MPEG Source infoframe
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the code to deal with the MPEG source infoframe.
>
> Blindly typed from the spec, and totally untested.
I'm not sure this patch should be added at all. The CTA-861-G spec (section 6.7)
says that the implementation of this infoframe is not recommended due to
unresolved
issues.
I don't think I've ever seen it either.
It obviously doesn't hurt to have this code, but I prefer to wait until there
are devices that actively set/use this infoframe.
Regards,
Hans
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 229
> +++
> include/linux/hdmi.h | 27 ++
> 2 files changed, 256 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 9507f668a569..3d24c7746c51 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -706,6 +706,131 @@ hdmi_vendor_any_infoframe_pack(union
> hdmi_vendor_any_infoframe *frame,
> return hdmi_vendor_any_infoframe_pack_only(frame, buffer, size);
> }
>
> +/**
> + * hdmi_mpeg_source_infoframe_init() - initialize an HDMI MPEG Source
> infoframe
> + * @frame: HDMI MPEG Source infoframe
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_mpeg_source_infoframe_init(struct hdmi_mpeg_source_infoframe *frame)
> +{
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_MPEG_SOURCE;
> + frame->version = 1;
> + frame->length = HDMI_MPEG_SOURCE_INFOFRAME_SIZE;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_init);
> +
> +static int hdmi_mpeg_source_infoframe_check_only(const struct
> hdmi_mpeg_source_infoframe *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_MPEG_SOURCE ||
> + frame->version != 1 ||
> + frame->length != HDMI_MPEG_SOURCE_INFOFRAME_SIZE)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
> + * hdmi_mpeg_source_infoframe_check() - Check and check a HDMI MPEG Source
> infoframe
> + * @frame: HDMI MPEG Source infoframe
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_mpeg_source_infoframe_check(struct hdmi_mpeg_source_infoframe
> *frame)
> +{
> + return hdmi_mpeg_source_infoframe_check_only(frame);
> +}
> +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_check);
> +
> +/**
> + * hdmi_mpeg_source_infoframe_pack_only() - write HDMI MPEG Source infoframe
> to binary buffer
> + * @frame: HDMI MPEG Source infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.4 specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_mpeg_source_infoframe_pack_only(const struct
> hdmi_mpeg_source_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + u8 *ptr = buffer;
> + size_t length;
> + int ret;
> +
> + ret = hdmi_mpeg_source_infoframe_check_only(frame);
> + if (ret)
> + return ret;
> +
> + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> +
> + if (size < length)
> + return -ENOSPC;
> +
> + memset(buffer, 0, size);
> +
> + ptr[0] = frame->type;
> + ptr[1] = frame->version;
> + ptr[2] = frame->length;
> + ptr[3] = 0; /* checksum */
> +
> + /* start infoframe payload */
> + ptr += HDMI_INFOFRAME_HEADER_SIZE;
> +
> + ptr[0] = frame->mpeg_bit_rate >> 0;
> + ptr[1] = frame->mpeg_bit_rate >> 8;
> + ptr[2] = frame->mpeg_bit_rate >> 16;
> + ptr[3] = frame->mpeg_bit_rate >> 24;
> + ptr[4] = (frame->field_repeat << 4) | frame->mpeg_frame;
> +
> + hdmi_infoframe_set_checksum(buffer, length);
> +
> + return length;
> +}
> +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack_only);
> +
> +/**
> + * hdmi_mpeg_source_infoframe_pack() - Check and check a HDMI MPEG Source
> infoframe,
> + * and write it to binary buffer
> + * @frame: HDMI MPEG Source infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields, after which packs the information
> + * contained in the @frame structure into a binary representation that
> + * can be written into the corresponding controller registers. Also
> + * computes the checksum as required by section 5.3.5 of the HDMI 1.4
> + *
Re: [PATCH 04/18] video/hdmi: Constify infoframe passed to the pack functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's make the infoframe pack functions usable with a const infoframe
> structure. This allows us to precompute the infoframe earlier, and still
> pack it later when we're no longer allowed to modify the structure.
> So now we end up with a _check()+_pack_only() or _pack() functions
> depending on whether you want to precompute the infoframes or not.
> The names aren't greate but I was lazy and didn't want to change all the
greate -> great
> drivers.
>
> v2: Deal with exynos churn
> Actually export the new funcs
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 425
> +++
> include/linux/hdmi.h | 19 ++-
> 2 files changed, 416 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 53e7ee2c83fc..9507f668a569 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -68,8 +68,36 @@ int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe
> *frame)
> }
> EXPORT_SYMBOL(hdmi_avi_infoframe_init);
>
> +static int hdmi_avi_infoframe_check_only(const struct hdmi_avi_infoframe
> *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_AVI ||
> + frame->version != 2 ||
> + frame->length != HDMI_AVI_INFOFRAME_SIZE)
> + return -EINVAL;
> +
> + if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> /**
> - * hdmi_avi_infoframe_pack() - write HDMI AVI infoframe to binary buffer
> + * hdmi_avi_infoframe_check() - Check and check a HDMI AVI infoframe
"Check and check"? This is repeated elsewhere as well (clearly copy-and-paste).
> + * @frame: HDMI AVI infoframe
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame)
> +{
> + return hdmi_avi_infoframe_check_only(frame);
> +}
> +EXPORT_SYMBOL(hdmi_avi_infoframe_check);
> +
> +/**
> + * hdmi_avi_infoframe_pack_only() - write HDMI AVI infoframe to binary buffer
> * @frame: HDMI AVI infoframe
> * @buffer: destination buffer
> * @size: size of buffer
> @@ -82,20 +110,22 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_init);
> * Returns the number of bytes packed into the binary buffer or a negative
> * error code on failure.
> */
> -ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void
> *buffer,
> - size_t size)
> +ssize_t hdmi_avi_infoframe_pack_only(const struct hdmi_avi_infoframe *frame,
> + void *buffer, size_t size)
> {
> u8 *ptr = buffer;
> size_t length;
> + int ret;
> +
> + ret = hdmi_avi_infoframe_check_only(frame);
> + if (ret)
> + return ret;
>
> length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
>
> if (size < length)
> return -ENOSPC;
>
> - if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
> - return -EINVAL;
> -
> memset(buffer, 0, size);
>
> ptr[0] = frame->type;
> @@ -152,6 +182,36 @@ ssize_t hdmi_avi_infoframe_pack(struct
> hdmi_avi_infoframe *frame, void *buffer,
>
> return length;
> }
> +EXPORT_SYMBOL(hdmi_avi_infoframe_pack_only);
> +
> +/**
> + * hdmi_avi_infoframe_pack() - Check and check a HDMI AVI infoframe,
> + * and write it to binary buffer
> + * @frame: HDMI AVI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields, after which packs the information
which packs -> which it packs
Ditto elsewhere.
> + * contained in the @frame structure into a binary representation that
> + * can be written into the corresponding controller registers. Also
Also -> This function also
Ditto elsewhere.
> + * computes the checksum as required by section 5.3.5 of the HDMI 1.4
> + * specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + int ret;
> +
> + ret = hdmi_avi_infoframe_check(frame);
> + if (ret)
> + return ret;
> +
> + return hdmi_avi_infoframe_pack_only(frame, buffer, size);
> +}
> EXPORT_SYMBOL(hdmi_avi_infoframe_pack);
>
> /**
> @@ -178,8 +238,33 @@ int hdmi_spd_infoframe_init(struct hdmi_spd_infoframe
> *frame,
> }
> EXPORT_SYMBOL(hdmi_spd_infoframe_init);
>
> +static int hdmi_spd_infoframe_check_only(const struct hdmi_spd_infoframe
> *frame)
> +{
> + if
Re: [PATCH 2/3] drm/exynos: scaler: Add support for tiled formats
Hi Inki,
On 2018-09-21 05:20, Inki Dae wrote:
> There are several warnings,
> WARNING: line over 80 characters
> #276: FILE: drivers/gpu/drm/exynos/exynos_drm_scaler.c:182:
> + struct drm_exynos_ipp_task_rect *src_pos, const struct scaler_format
> *fmt)
>
> WARNING: line over 80 characters
> #297: FILE: drivers/gpu/drm/exynos/exynos_drm_scaler.c:363:
> + const struct scaler_format *src_fmt =
> scaler_get_format(task->src.buf.fourcc);
>
> WARNING: line over 80 characters
> #301: FILE: drivers/gpu/drm/exynos/exynos_drm_scaler.c:366:
> + const struct scaler_format *dst_fmt =
> scaler_get_format(task->dst.buf.fourcc);
>
> total: 0 errors, 3 warnings, 192 lines checked
>
>
> And comment below.
>
>
> On 2018년 08월 10일 22:29, Marek Szyprowski wrote:
>> From: Andrzej Pietrasiewicz
>>
>> Add support for 16x16 tiled formats: NV12/NV21, YUYV and YUV420.
>>
>> Signed-off-by: Andrzej Pietrasiewicz
>> Signed-off-by: Marek Szyprowski
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 133 -
>> 1 file changed, 75 insertions(+), 58 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
>> b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
>> index 0ddb6eec7b11..8e761ef63eac 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
>> @@ -49,56 +49,46 @@ struct scaler_context {
>> const struct scaler_data*scaler_data;
>> };
>>
>> -static u32 scaler_get_format(u32 drm_fmt)
>> +struct scaler_format {
>> +u32 drm_fmt;
>> +u32 internal_fmt;
>> +u32 chroma_tile_w;
>> +u32 chroma_tile_h;
>> +};
>> +
>> +static const struct scaler_format scaler_formats[] = {
>> +{ DRM_FORMAT_NV12, SCALER_YUV420_2P_UV, 8, 8 },
>> +{ DRM_FORMAT_NV21, SCALER_YUV420_2P_VU, 8, 8 },
>> +{ DRM_FORMAT_YUV420, SCALER_YUV420_3P, 8, 8 },
>> +{ DRM_FORMAT_YUYV, SCALER_YUV422_1P_YUYV, 16, 16 },
>> +{ DRM_FORMAT_UYVY, SCALER_YUV422_1P_UYVY, 16, 16 },
>> +{ DRM_FORMAT_YVYU, SCALER_YUV422_1P_YVYU, 16, 16 },
>> +{ DRM_FORMAT_NV16, SCALER_YUV422_2P_UV, 8, 16 },
>> +{ DRM_FORMAT_NV61, SCALER_YUV422_2P_VU, 8, 16 },
>> +{ DRM_FORMAT_YUV422, SCALER_YUV422_3P, 8, 16 },
>> +{ DRM_FORMAT_NV24, SCALER_YUV444_2P_UV, 16, 16 },
>> +{ DRM_FORMAT_NV42, SCALER_YUV444_2P_VU, 16, 16 },
>> +{ DRM_FORMAT_YUV444, SCALER_YUV444_3P, 16, 16 },
>> +{ DRM_FORMAT_RGB565, SCALER_RGB_565, 0, 0 },
>> +{ DRM_FORMAT_XRGB1555, SCALER_ARGB1555, 0, 0 },
>> +{ DRM_FORMAT_ARGB1555, SCALER_ARGB1555, 0, 0 },
>> +{ DRM_FORMAT_XRGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_ARGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_XRGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_ARGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_RGBX, SCALER_RGBA, 0, 0 },
>> +{ DRM_FORMAT_RGBA, SCALER_RGBA, 0, 0 },
>> +};
>> +
>> +static const struct scaler_format *scaler_get_format(u32 drm_fmt)
>> {
>> -switch (drm_fmt) {
>> -case DRM_FORMAT_NV12:
>> -return SCALER_YUV420_2P_UV;
>> -case DRM_FORMAT_NV21:
>> -return SCALER_YUV420_2P_VU;
>> -case DRM_FORMAT_YUV420:
>> -return SCALER_YUV420_3P;
>> -case DRM_FORMAT_YUYV:
>> -return SCALER_YUV422_1P_YUYV;
>> -case DRM_FORMAT_UYVY:
>> -return SCALER_YUV422_1P_UYVY;
>> -case DRM_FORMAT_YVYU:
>> -return SCALER_YUV422_1P_YVYU;
>> -case DRM_FORMAT_NV16:
>> -return SCALER_YUV422_2P_UV;
>> -case DRM_FORMAT_NV61:
>> -return SCALER_YUV422_2P_VU;
>> -case DRM_FORMAT_YUV422:
>> -return SCALER_YUV422_3P;
>> -case DRM_FORMAT_NV24:
>> -return SCALER_YUV444_2P_UV;
>> -case DRM_FORMAT_NV42:
>> -return SCALER_YUV444_2P_VU;
>> -case DRM_FORMAT_YUV444:
>> -return SCALER_YUV444_3P;
>> -case DRM_FORMAT_RGB565:
>> -return SCALER_RGB_565;
>> -case DRM_FORMAT_XRGB1555:
>> -return SCALER_ARGB1555;
>> -case DRM_FORMAT_ARGB1555:
>> -return SCALER_ARGB1555;
>> -case DRM_FORMAT_XRGB:
>> -return SCALER_ARGB;
>> -case DRM_FORMAT_ARGB:
>> -return SCALER_ARGB;
>> -case DRM_FORMAT_XRGB:
>> -return SCALER_ARGB;
>> -case DRM_FORMAT_ARGB:
>> -return SCALER_ARGB;
>> -case DRM_FORMAT_RGBX:
>> -return SCALER_RGBA;
>> -case DRM_FORMAT_RGBA:
>> -return SCALER_RGBA;
>> -default:
>> -break;
>> -}
>> +int i;
>>
>> -return 0;
>> +for (i = 0; i < ARRAY_SIZE(scaler_formats); i++)
>> +if (scaler_formats[i].drm_fmt == drm_fmt)
>> +return _formats[i];
>> +
>> +return NULL;
>> }
>>
>> static inline int scaler_reset(struct scaler_context *scaler)
>> @@ -152,11 +142,11 @@ static inline void
Re: [PATCH 01/18] video/hdmi: Constify 'buffer' to the unpack functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The unpack functions just read from the passed in buffer,
> so make it const.
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks!
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 23 ---
> include/linux/hdmi.h | 3 ++-
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 38716eb50408..65b915ea4936 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -31,7 +31,7 @@
>
> #define hdmi_log(fmt, ...) dev_printk(level, dev, fmt, ##__VA_ARGS__)
>
> -static u8 hdmi_infoframe_checksum(u8 *ptr, size_t size)
> +static u8 hdmi_infoframe_checksum(const u8 *ptr, size_t size)
> {
> u8 csum = 0;
> size_t i;
> @@ -1016,9 +1016,9 @@ EXPORT_SYMBOL(hdmi_infoframe_log);
> * Returns 0 on success or a negative error code on failure.
> */
> static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame,
> - void *buffer)
> + const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> int ret;
>
> if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI ||
> @@ -1079,9 +1079,9 @@ static int hdmi_avi_infoframe_unpack(struct
> hdmi_avi_infoframe *frame,
> * Returns 0 on success or a negative error code on failure.
> */
> static int hdmi_spd_infoframe_unpack(struct hdmi_spd_infoframe *frame,
> - void *buffer)
> + const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> int ret;
>
> if (ptr[0] != HDMI_INFOFRAME_TYPE_SPD ||
> @@ -1117,9 +1117,9 @@ static int hdmi_spd_infoframe_unpack(struct
> hdmi_spd_infoframe *frame,
> * Returns 0 on success or a negative error code on failure.
> */
> static int hdmi_audio_infoframe_unpack(struct hdmi_audio_infoframe *frame,
> -void *buffer)
> +const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> int ret;
>
> if (ptr[0] != HDMI_INFOFRAME_TYPE_AUDIO ||
> @@ -1163,9 +1163,9 @@ static int hdmi_audio_infoframe_unpack(struct
> hdmi_audio_infoframe *frame,
> */
> static int
> hdmi_vendor_any_infoframe_unpack(union hdmi_vendor_any_infoframe *frame,
> - void *buffer)
> + const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> size_t length;
> int ret;
> u8 hdmi_video_format;
> @@ -1234,10 +1234,11 @@ hdmi_vendor_any_infoframe_unpack(union
> hdmi_vendor_any_infoframe *frame,
> *
> * Returns 0 on success or a negative error code on failure.
> */
> -int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer)
> +int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> + const void *buffer)
> {
> int ret;
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
>
> switch (ptr[0]) {
> case HDMI_INFOFRAME_TYPE_AVI:
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index d271ff23984f..d3816170c062 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -332,7 +332,8 @@ union hdmi_infoframe {
>
> ssize_t
> hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer, size_t size);
> -int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer);
> +int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> + const void *buffer);
> void hdmi_infoframe_log(const char *level, struct device *dev,
> union hdmi_infoframe *frame);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/18] video/hdmi: Pass buffer size to infoframe unpack functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make sure the infoframe unpack functions don't end up examining
> stack garbage or oopsing, let's pass in the size of the buffer.
>
> v2: Convert tda1997x.c as well (kbuild test robot)
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks,
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/media/i2c/adv7511.c | 2 +-
> drivers/media/i2c/adv7604.c | 2 +-
> drivers/media/i2c/adv7842.c | 2 +-
> drivers/media/i2c/tc358743.c | 2 +-
> drivers/media/i2c/tda1997x.c | 4 ++--
> drivers/video/hdmi.c | 51
>
> include/linux/hdmi.h | 2 +-
> 7 files changed, 44 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
> index 55c2ea0720d9..b85b181bbb6c 100644
> --- a/drivers/media/i2c/adv7511.c
> +++ b/drivers/media/i2c/adv7511.c
> @@ -550,7 +550,7 @@ static void log_infoframe(struct v4l2_subdev *sd, const
> struct adv7511_cfg_read_
> buffer[3] = 0;
> buffer[3] = hdmi_infoframe_checksum(buffer, len + 4);
>
> - if (hdmi_infoframe_unpack(, buffer) < 0) {
> + if (hdmi_infoframe_unpack(, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
> cri->desc);
> return;
> }
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 668be2bca57a..2e7a28dbad4e 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -2418,7 +2418,7 @@ static int adv76xx_read_infoframe(struct v4l2_subdev
> *sd, int index,
> buffer[i + 3] = infoframe_read(sd,
> adv76xx_cri[index].payload_addr + i);
>
> - if (hdmi_infoframe_unpack(frame, buffer) < 0) {
> + if (hdmi_infoframe_unpack(frame, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
>adv76xx_cri[index].desc);
> return -ENOENT;
> diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
> index 4f8fbdd00e35..2cfd03f929b2 100644
> --- a/drivers/media/i2c/adv7842.c
> +++ b/drivers/media/i2c/adv7842.c
> @@ -2563,7 +2563,7 @@ static void log_infoframe(struct v4l2_subdev *sd,
> struct adv7842_cfg_read_infofr
> for (i = 0; i < len; i++)
> buffer[i + 3] = infoframe_read(sd, cri->payload_addr + i);
>
> - if (hdmi_infoframe_unpack(, buffer) < 0) {
> + if (hdmi_infoframe_unpack(, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
> cri->desc);
> return;
> }
> diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
> index 44c41933415a..519bf92508d5 100644
> --- a/drivers/media/i2c/tc358743.c
> +++ b/drivers/media/i2c/tc358743.c
> @@ -444,7 +444,7 @@ static void print_avi_infoframe(struct v4l2_subdev *sd)
>
> i2c_rd(sd, PK_AVI_0HEAD, buffer, HDMI_INFOFRAME_SIZE(AVI));
>
> - if (hdmi_infoframe_unpack(, buffer) < 0) {
> + if (hdmi_infoframe_unpack(, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of AVI infoframe failed\n", __func__);
> return;
> }
> diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
> index d114ac5243ec..195a1fc74ee8 100644
> --- a/drivers/media/i2c/tda1997x.c
> +++ b/drivers/media/i2c/tda1997x.c
> @@ -1253,7 +1253,7 @@ tda1997x_parse_infoframe(struct tda1997x_state *state,
> u16 addr)
>
> /* read data */
> len = io_readn(sd, addr, sizeof(buffer), buffer);
> - err = hdmi_infoframe_unpack(, buffer);
> + err = hdmi_infoframe_unpack(, buffer, sizeof(buffer));
> if (err) {
> v4l_err(state->client,
> "failed parsing %d byte infoframe: 0x%04x/0x%02x\n",
> @@ -1928,7 +1928,7 @@ static int tda1997x_log_infoframe(struct v4l2_subdev
> *sd, int addr)
> /* read data */
> len = io_readn(sd, addr, sizeof(buffer), buffer);
> v4l2_dbg(1, debug, sd, "infoframe: addr=%d len=%d\n", addr, len);
> - err = hdmi_infoframe_unpack(, buffer);
> + err = hdmi_infoframe_unpack(, buffer, sizeof(buffer));
> if (err) {
> v4l_err(state->client,
> "failed parsing %d byte infoframe: 0x%04x/0x%02x\n",
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 65b915ea4936..b5d491014b0b 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -1005,8 +1005,9 @@ EXPORT_SYMBOL(hdmi_infoframe_log);
>
> /**
> * hdmi_avi_infoframe_unpack() - unpack binary buffer to a HDMI AVI infoframe
> - * @buffer: source buffer
> * @frame: HDMI AVI infoframe
> + * @buffer: source buffer
> + * @size: size of buffer
> *
> * Unpacks the information contained in binary @buffer into a structured
> *
Re: [PATCH 03/18] video/hdmi: Constify infoframe passed to the log functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The log functions don't modify the passed in infoframe so make it const.
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks,
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 22 +++---
> include/linux/hdmi.h | 2 +-
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index b5d491014b0b..53e7ee2c83fc 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -471,7 +471,7 @@ static const char *hdmi_infoframe_type_get_name(enum
> hdmi_infoframe_type type)
>
> static void hdmi_infoframe_log_header(const char *level,
> struct device *dev,
> - struct hdmi_any_infoframe *frame)
> + const struct hdmi_any_infoframe *frame)
> {
> hdmi_log("HDMI infoframe: %s, version %u, length %u\n",
> hdmi_infoframe_type_get_name(frame->type),
> @@ -673,10 +673,10 @@ hdmi_content_type_get_name(enum hdmi_content_type
> content_type)
> */
> static void hdmi_avi_infoframe_log(const char *level,
> struct device *dev,
> -struct hdmi_avi_infoframe *frame)
> +const struct hdmi_avi_infoframe *frame)
> {
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> hdmi_log("colorspace: %s\n",
> hdmi_colorspace_get_name(frame->colorspace));
> @@ -750,12 +750,12 @@ static const char *hdmi_spd_sdi_get_name(enum
> hdmi_spd_sdi sdi)
> */
> static void hdmi_spd_infoframe_log(const char *level,
> struct device *dev,
> -struct hdmi_spd_infoframe *frame)
> +const struct hdmi_spd_infoframe *frame)
> {
> u8 buf[17];
>
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> memset(buf, 0, sizeof(buf));
>
> @@ -886,10 +886,10 @@ hdmi_audio_coding_type_ext_get_name(enum
> hdmi_audio_coding_type_ext ctx)
> */
> static void hdmi_audio_infoframe_log(const char *level,
>struct device *dev,
> - struct hdmi_audio_infoframe *frame)
> + const struct hdmi_audio_infoframe *frame)
> {
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> if (frame->channels)
> hdmi_log("channels: %u\n", frame->channels - 1);
> @@ -949,12 +949,12 @@ hdmi_3d_structure_get_name(enum hdmi_3d_structure
> s3d_struct)
> static void
> hdmi_vendor_any_infoframe_log(const char *level,
> struct device *dev,
> - union hdmi_vendor_any_infoframe *frame)
> + const union hdmi_vendor_any_infoframe *frame)
> {
> - struct hdmi_vendor_infoframe *hvf = >hdmi;
> + const struct hdmi_vendor_infoframe *hvf = >hdmi;
>
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> if (frame->any.oui != HDMI_IEEE_OUI) {
> hdmi_log("not a HDMI vendor infoframe\n");
> @@ -984,7 +984,7 @@ hdmi_vendor_any_infoframe_log(const char *level,
> */
> void hdmi_infoframe_log(const char *level,
> struct device *dev,
> - union hdmi_infoframe *frame)
> + const union hdmi_infoframe *frame)
> {
> switch (frame->any.type) {
> case HDMI_INFOFRAME_TYPE_AVI:
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index a577d4ae2570..bce1abb1fe57 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -335,6 +335,6 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void
> *buffer, size_t size);
> int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> const void *buffer, size_t size);
> void hdmi_infoframe_log(const char *level, struct device *dev,
> - union hdmi_infoframe *frame);
> + const union hdmi_infoframe *frame);
>
> #endif /* _DRM_HDMI_H */
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/5] drm/dp: fix link probing for devices supporting DP 1.4+
Thanks for the patch. Verified with the DP 1.4 spec and looks good to me.
Also look at the related patch that makes use of the correct extended
capabilities:
https://patchwork.freedesktop.org/patch/249400/
Reviewed-by: Manasi Navare
Manasi
On Thu, Sep 20, 2018 at 03:54:37PM +0100, Damian Kos wrote:
> From: Quentin Schulz
>
> DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
> DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
> DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
> DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
> DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
> "true capabilities" of DPRX device.
>
> Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
> might falsely return lower capabilities to "avoid interoperability
> issues with some of the existing DP Source devices that malfunction
> when they discover the higher capabilities within those three
> registers.".
>
> Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was reserved
> and read 0 so it's safe to check against it even if DP revision is
> <1.4
>
> Signed-off-by: Quentin Schulz
> Signed-off-by: Damian Kos
> ---
> drivers/gpu/drm/drm_dp_helper.c | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 8c6b9fd89f8a..735ebde5c2f0 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -370,10 +370,38 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
> drm_dp_link *link)
> {
> u8 values[3];
> int err;
> + unsigned int addr;
>
> memset(link, 0, sizeof(*link));
>
> - err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
> + /*
> + * DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
> + * DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
> + * DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
> + * DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
> + * DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
> + * "true capabilities" of DPRX device.
> + *
> + * Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
> + * might falsely return lower capabilities to "avoid interoperability
> + * issues with some of the existing DP Source devices that malfunction
> + * when they discover the higher capabilities within those three
> + * registers.".
> + *
> + * Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was
> reserved
> + * and read 0 so it's safe to check against it even if DP revision is
> + * <1.4
> + */
> + err = drm_dp_dpcd_readb(aux, DP_TRAINING_AUX_RD_INTERVAL, values);
> + if (err < 0)
> + return err;
> +
> + if (values[0] & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)
> + addr = DP_DP13_DPCD_REV;
> + else
> + addr = DP_DPCD_REV;
> +
> + err = drm_dp_dpcd_read(aux, addr, values, sizeof(values));
> if (err < 0)
> return err;
>
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 3/3] radeon: add missing drm_public exports
On 2018-09-20 8:31 p.m., Eric Engestrom wrote:
> On Thursday, 2018-09-20 18:21:41 +0100, Eric Engestrom wrote:
>> On Thursday, 2018-09-20 18:09:41 +0200, Michel Dänzer wrote:
>>> On 2018-09-20 5:58 p.m., Eric Engestrom wrote:
Fixes: 9f45264815eff6ebeba3 "radeon: annotate public functions"
Cc: Lucas De Marchi
Cc: Mark Janes
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108006
Signed-off-by: Eric Engestrom
---
radeon/radeon_bo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/radeon/radeon_bo.c b/radeon/radeon_bo.c
index cd06c26ee152d68f893d..91929532d5bf6e0daca8 100644
--- a/radeon/radeon_bo.c
+++ b/radeon/radeon_bo.c
@@ -67,13 +67,13 @@ drm_public struct radeon_bo *radeon_bo_unref(struct
radeon_bo *bo)
return boi->bom->funcs->bo_unref(boi);
}
-int radeon_bo_map(struct radeon_bo *bo, int write)
+drm_public int radeon_bo_map(struct radeon_bo *bo, int write)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
return boi->bom->funcs->bo_map(boi, write);
}
-int radeon_bo_unmap(struct radeon_bo *bo)
+drm_public int radeon_bo_unmap(struct radeon_bo *bo)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
return boi->bom->funcs->bo_unmap(boi);
>>>
>>> Reviewed-by: Michel Dänzer
>>> Tested-by: Michel Dänzer
>>
>> Thanks!
>>
>> radeon_cs_space_check was also missing, but my grep didn't catch it
>> because radeon_cs_space_check_with_bo matched my weak grep skills...
>>
>> I added drm_public to it too, can I still apply your tags, or do you
>> want a v2?
>
> I ended up pushing it with your r-b and t-b, because I'm going home and
> would rather not have left it like that too long :)
Good catch and good call, thanks again.
--
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: [git pull] drm fixes for 4.19-rc5
On Fri, Sep 21, 2018 at 10:06:58AM +1000, Dave Airlie wrote: > Hey Greg, > > Looks like a pretty run of the mill set of fixes for this stage, > > core: fix debugfs for atomic, fix the check for atomic for > non-modesetting drivers > amdgpu: adds a new PCI id, some kfd fixes and a sdma fix > i915: a bunch of GVT fixes. > vc4: scaling fix > vmwgfx: modesetting fixes and a old buffer eviction fix > udl: framebuffer destruction fix > sun4i: disable on R40 fix until next kernel > pl111: NULL termination on table fix Now pulled, thanks. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
