[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings

Hi Bjorn, On Monday 05 Dec 2016 13:11:51 Bjorn Andersson wrote: > On Tue 29 Nov 01:11 PST 2016, Laurent Pinchart wrote: > > On Tuesday 29 Nov 2016 13:41:33 Archit Taneja wrote: > >> On 11/29/2016 12:03 PM, Laurent Pinchart wrote: > >>> On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote: >

[Powerpc] Sam460ex Canyonlands issue -Kernel 4.4.36

> -Original Message- > From: Julian Margetson [mailto:runaway at candw.ms] > Sent: Monday, December 05, 2016 4:59 PM > To: Maling list - DRI developers > Cc: Deucher, Alexander; Daenzer, Michel; daniel.vetter at ffwll.ch > Subject: [Powerpc] Sam460ex Canyonlands issue -Kernel 4.4.36 > >

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

e down will be appreciated. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/94170e17/attachment.html>

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

the files as opposed to symlinks. The latter can cause issues in many scenarios. Thanks -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attach

[PATCH 0/8] Host1x IOMMU support + VIC support

On 12/05/2016 09:51 PM, Thierry Reding wrote: > On Thu, Nov 10, 2016 at 08:23:37PM +0200, Mikko Perttunen wrote: >> This series adds IOMMU support to Host1x and TegraDRM >> and adds support for the VIC host1x client so that >> host1x can be tested on modern Tegra platforms. >> It depends on the

[PATCH] drm/amdgpu: don't add files at control minor debugfs directory

Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a struct drm_device's ->control member is always NULL. In the case of CONFIG_DEBUG_FS=y, amdgpu_debugfs_add_files() accesses ->control->debugfs_root though. This results in a NULL pointer dereference. Fix this by omitting the

[PATCH v10 13/13] drm/mediatek: add support for Mediatek SoC MT2701

On Wed, 2016-11-30 at 15:03 +0100, Matthias Brugger wrote: > > On 25/11/16 11:34, YT Shen wrote: > > > static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = { > > + { .compatible = "mediatek,mt2701-disp-rdma", > > + .data = _rdma_driver_data}, > > { .compatible =

[PATCH v2] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

On Fri, Dec 02, 2016 at 03:29:04PM +0100, Hans de Goede wrote: > On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading > i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. > Once the i915 driver has successfully loaded, the panel can be disabled / >

[PATCH 0/8] Host1x IOMMU support + VIC support

Tegra124 we should also have a userspace test program to exercise it. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/aef4b768/attachment.sig>

[PATCH v10 02/13] drm/mediatek: add *driver_data for different hardware settings

Hi Daniel, On Wed, 2016-11-30 at 14:42 +0800, Daniel Kurtz wrote: > Hi YT, > > > On Fri, Nov 25, 2016 at 6:34 PM, YT Shen wrote: > > > > There are some hardware settings changed, between MT8173 & MT2701: > > DISP_OVL address offset changed, color format definition changed. > > DISP_RDMA fifo

[PATCH 5/8] gpu: host1x: Add IOMMU support

tterlist *sg; > + struct iova *alloc; > + unsigned long shift; > + int j; There should be no blank line between blocks of variable declarations. Also, make j an unsigned int. > + > g->bo = host1x_bo_get(g->bo); > - if (!g->bo) > + if (!g->bo) { > + err = -EINVAL; > goto unpin; > + } > > phys_addr = host1x_bo_pin(g->bo, ); > - if (!phys_addr) > + if (!phys_addr) { > + err = -EINVAL; > goto unpin; > + } > + > + if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && host->domain) { > + for_each_sg(sgt->sgl, sg, sgt->nents, j) { > + gather_size += sg->length; > + } No need for curly brackets here. > + gather_size = iova_align(>iova, gather_size); > + > + shift = iova_shift(>iova); > + alloc = alloc_iova( > + >iova, gather_size >> shift, > + host->domain->geometry.aperture_end >> shift, > + true); This could be made a little more compact as well. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/59910d4a/attachment.sig>

[PATCH v10 12/13] drm/mediatek: update DSI sub driver flow for sending commands to panel

Hi CK, On Wed, 2016-11-30 at 15:58 +0800, CK Hu wrote: > Hi, YT: > > some comments inline. > > On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote: > > This patch update enable/disable flow of DSI module. > > Original flow works on there is a bridge chip: DSI -> bridge -> panel. > > In this case:

[PATCH v2] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

Hi, On 05-12-16 19:52, Ville Syrjälä wrote: > On Fri, Dec 02, 2016 at 03:29:04PM +0100, Hans de Goede wrote: >> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading >> i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. >> Once the i915 driver has

[PATCH 4/8] drm/tegra: Add VIC support

> + vic->regs = devm_ioremap_resource(dev, regs); > + if (IS_ERR(vic->regs)) > + return PTR_ERR(vic->regs); > + > + vic->clk = devm_clk_get(dev, NULL); > + if (IS_ERR(vic->clk)) { > + dev_err(>dev, "failed to get clock\n"); > + return PTR_ERR(vic->clk); > + } > + > + platform_set_drvdata(pdev, vic); > + > + INIT_LIST_HEAD(>client.base.list); > + vic->client.base.ops = _client_ops; > + vic->client.base.dev = dev; > + vic->client.base.class = HOST1X_CLASS_VIC; > + vic->client.base.syncpts = syncpts; > + vic->client.base.num_syncpts = 1; > + vic->dev = dev; > + vic->config = vic_config; > + > + INIT_LIST_HEAD(>client.list); > + vic->client.ops = _ops; > + > + err = host1x_client_register(>client.base); > + if (err < 0) { > + dev_err(dev, "failed to register host1x client: %d\n", err); > + platform_set_drvdata(pdev, NULL); > + return err; > + } > + > + pm_runtime_enable(>dev); > + if (!pm_runtime_enabled(>dev)) { > + err = vic_runtime_resume(>dev); > + if (err < 0) > + goto unregister_client; > + } That's a slightly ugly construct, but I can't think of an easy way to get rid of it (other than to depend on PM, which actually might be the right thing to do here, it's already selected by ARCH_TEGRA on 64-bit ARM). I can't think of a scenario where we'd want to run without runtime PM. > + > + dev_info(>dev, "initialized"); Again, no need for this. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/f141df14/attachment-0001.sig>

[PATCH] drm/amdgpu: don't add files at control minor debugfs directory

> -Original Message- > From: Nicolai Stange [mailto:nicstange at gmail.com] > Sent: Monday, December 05, 2016 3:30 PM > To: Daniel Vetter > Cc: Deucher, Alexander; Koenig, Christian; Michel Dänzer; linux- > kernel at vger.kernel.org; dri-devel at lists.freedesktop.org; Nicolai Stange >

[PATCH 3/8] drm/tegra: Add falcon helper library

t; +#define FALCON_DMATRFMOFFS 0x1114 > + > +#define FALCON_DMATRFCMD 0x1118 > +#define FALCON_DMATRFCMD_IDLE(1 << 1) > +#define FALCON_DMATRFCMD_IMEM(1 << 4) > +#define FALCON_DMATRFCMD_SIZE_256B (6 << 8) > + > +#define FALCON_DMATRFFBOFFS 0x111c > + > +struct falcon_firmware_bin_header_v1 { > + u32 bin_magic; /* 0x10de */ > + u32 bin_ver;/* cya, versioning of bin format (1) */ Not sure everyone understands what cya means, here. Perhaps just drop it? > + u32 bin_size; /* entire image size including this header */ > + u32 os_bin_header_offset; > + u32 os_bin_data_offset; > + u32 os_bin_size; > +}; > + > +struct falcon_firmware_os_app_v1 { > + u32 offset; > + u32 size; > +}; > + > +struct falcon_firmware_os_header_v1 { > + u32 os_code_offset; > + u32 os_code_size; > + u32 os_data_offset; > + u32 os_data_size; > + u32 num_apps; > + struct falcon_firmware_os_app_v1 *app_code; > + struct falcon_firmware_os_app_v1 *app_data; The above two seem to be completel unused. Should we drop them? > + u32 *os_ovl_offset; > + u32 *os_ovl_size; > +}; Can we in general sanitize the names of these a little? It's redundent to add a os_ prefix in a structure that contains an _os_ infix. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/30b6599a/attachment.sig>

[PATCH 2/8] drm/tegra: Allocate BOs from lower 4G when without IOMMU

- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/ebea832e/attachment.sig>

[PATCH 1/8] drm/tegra: Add Tegra DRM allocation API

} > + > + shift = iova_shift(>iova); > + alloc = alloc_iova(>iova, size >> shift, > +tegra->domain->geometry.aperture_end >> shift, true); This is fairly cumbersome to use. Maybe a drm_mm would be easier in this case? If not, could we at least store the upper limit of the carveout so that we don't have to use the really long expression above? Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/090b6341/attachment.sig>

[Bug 98505] [radeon, amdgpu] Regression introduced in 4.8-rc3

Tahvanainen --- Closing resolved+Fixed. Verified by Reporter. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/67d73

[Bug 98993] dosbox artefacts when using opengl

://packages.debian.org/sid/dosbox https://packages.debian.org/sid/rtcw -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161

[Powerpc] Sam460ex Canyonlands issue -Kernel 4.4.36

[ea84df40] [c000ade4] ret_from_kernel_thread+0x5c/0x64 >> [5.332230] Instruction dump: >> [5.332241] 7c0803a6 4bb7c1ec 9421ffa0 7c0802a6 bdc10018 90010064 >> 894313d0 2f8a >> [5.332251] 40be001c 3c60c0c7 38631c16 483ea6c5 <0fe0> 3860ffea >> 480009ac 89431aa8 >> [5.332274] ---[ end trace 3fbb08226210324a ]--- >> [5.413526] Console: switching to colour frame buffer device 240x67 -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/b58b1493/attachment.html>

[PATCH libdrm 5/5] tests/drmdevice: use drmGetDevice[s]2

On 03/12/16 01:32 AM, Emil Velikov wrote: > From: Emil Velikov > > Pass along DRM_DEVICE_GET_PCI_REVISION only when the individual nodes > are opened and update the printed messages accordingly. > > v2: Attribute for the flag rename, call drmGetDevices2 w/o the flag. > > Signed-off-by: Emil

[Bug 98993] dosbox artefacts when using opengl

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/03e72bed/attachment-0001.html>

[PATCH v3 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings

On Thu, Dec 01, 2016 at 10:05:59AM +0100, Neil Armstrong wrote: > Reviewed-by: Laurent Pinchart > Signed-off-by: Neil Armstrong > --- > .../bindings/display/amlogic,meson-vpu.txt | 112 > + > 1 file changed, 112 insertions(+) > create mode 100644 >

[PATCH v2 2/3] drm/edid: Implement SCDC support detection

On Mon, Dec 05, 2016 at 05:21:24PM +0100, Daniel Vetter wrote: > On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote: > > On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote: > > > On Mon, Dec 05, 2016 at 08:57:43AM +0100, Thierry Reding wrote: > > > > On Sat, Dec 03, 2016 at

[PATCH] drm/radeon: don't add files at control minor debugfs directory

On 05/12/16 05:48 PM, Christian König wrote: > Am 05.12.2016 um 09:39 schrieb Nicolai Stange:>> >> I'll send compile-only tested patches either tonight or tomorrow. Shall >> they cover the oopses only or the dead code as well? > > Please start with the ops, cause we certainly will get complains

tilcdc: vblank wait timed out

2016-12-05 12:01 GMT+01:00 Bartosz Golaszewski : > Hi Jyri, > > I pulled your recent tilcdc pull request on top of v4.9 and Sekhar's > davinci branch (+ vga dac DT)[1]. > > I'm getting "vblank wait timed out" errors when running simple modetest[2]. > > This error happened before with the

[PATCH] drm: parse hf-vsdb

ore the additional formats in the edid_hdmi_dc_modes field? > + > + /** >* @cea_rev: CEA revision of the HDMI sink. >*/ > u8 cea_rev; > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h > index 38eabf6..5df8b9c 100644 > --- a/include/drm

[Powerpc] Sam460ex Canyonlands issue -Kernel 4.4.36

Following appears with kernel 4.4.36 . Maybe as a result of following patch ? drm/radeon: Ensure vblank interrupt is enabled on DPMS transition to on [5.331666] Can't enable IRQ/MSI because no handler is installed [5.331842] [ cut here ] [5.331847] WARNING:

[PATCH libdrm v2 5/5] xf86drm: implement an OpenBSD specific drmGetDevice2

On 1 December 2016 at 04:18, Jonathan Gray wrote: > DRI devices on OpenBSD are not in their own directory. They reside in > /dev with a large number of statically generated /dev nodes. > > Avoid stat'ing all of /dev on OpenBSD by implementing this custom path. > > v2: >- use drmGetMinorType

[RESEND PATCH v2 4/7] drm/vc4: Add support for the VEC (Video Encoder) IP

On 12/02/2016 05:48 AM, Boris Brezillon wrote: > The VEC IP is a TV DAC, providing support for PAL and NTSC standards. > > Signed-off-by: Boris Brezillon > --- > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c > new file mode 100644 > index ..2d4256fcc6f2

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

xt part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/0dae8e12/attachment.sig>

[PATCH] drm/atomic: doc: remove old comment about nonblocking commits

On Mon, Dec 05, 2016 at 12:03:46PM -0200, Gustavo Padovan wrote: > From: Gustavo Padovan > > We now support nonblocking commits on drm_atomic_helper_commit() > so the comment is not valid anymore. > > Signed-off-by: Gustavo Padovan Oops. Reviewed-by: Daniel Vetter > --- >

[RFC] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

On Mon, Dec 05, 2016 at 11:24:44AM +, Robert Bragg wrote: > Forgot to send to dri-devel when I first sent this out... > > The few times I've looked at using DRM_DEBUG messages, I haven't found > them very helpful considering how noisy some of the categories are. More > than once now I've

[PATCH v2 2/3] drm/edid: Implement SCDC support detection

On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote: > On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote: > > On Mon, Dec 05, 2016 at 08:57:43AM +0100, Thierry Reding wrote: > > > On Sat, Dec 03, 2016 at 04:35:24AM +, Sharma, Shashank wrote: > > > > Hi Thierry, > > > >

[PATCH v2] drm: allow changing DPMS mode

On Mon, Dec 05, 2016 at 02:04:08PM +0200, Marta Lofstedt wrote: > The drm_atomic_helper_connector_dpms > will set the connector back the old DPMS state > before returning. This makes it impossible to change > DPMS state of the connector. > > Fixes: 0853695c3ba46f97dfc0b5885f7b7e640ca212dd > v2:

[RFC 4/4] drm/i915: Creating guc log file in drmfs instead of debugfs

From: Sourab Gupta In the current scenario, the relay API fit well only with debugfs, due to availability of parent dentry. Any other existing filesystem was not feasible for holding guc logs, due to incompatibility with relay. But this makes the guc_log file

[RFC 3/4] drm: Create driver specific root directory inside drmfs

From: Sourab Gupta A driver specific directory is created inside drmfs root, and dentry of this directory is saved for subsequent use by the driver (e.g. i915). The driver can then create files/directories inside this root directory directly. In case of i915 driver, the

[RFC 2/4] drm: Register drmfs filesystem from drm init

From: Sourab Gupta The drmfs filesystem will not be registered standalone during kernel init time, instead it is intended to be initialized/registered during drm initialization. Signed-off-by: Sourab Gupta Signed-off-by: Swati Dhingra --- drivers/gpu/drm/drm_drv.c | 6

[RFC 1/4] drm: Introduce drmfs pseudo filesystem interfaces

From: Sourab Gupta The patch introduces a new pseudo filesystem type, named 'drmfs' which is intended to house the files for the data generated by drm subsystem that cannot be accommodated by any of the existing filesystems. The filesystem is modelled on the lines of

[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

From: Swati Dhingra Currently, we don't have a stable ABI which can be used for the purpose of providing output debug/loggging/crc and other such data from DRM. The ABI in current use (filesystems, ioctls, et al.) have their own constraints and are intended to output a

[PATCH 4/4] drm/i915: Implement Link Rate fallback on Link training failure

If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the

[PATCH 3/4] drm/i915: Find fallback link rate/lane count

If link training fails, then we need to fallback to lower link rate first and if link training fails at RBR, then fallback to lower lane count. This function finds the next lower link rate/lane count value after link training failure and limits the max link_rate and lane_count values to these

[PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug

Sink's capabilities are advertised through DPCD registers and get updated only on hotplug. So they should be computed only once in the long pulse handler and saved off in intel_dp structure for the use later. For this reason two new fields max_sink_lane_count and max_sink_link_bw are added to

[PATCH 1/4] drm: Add a new connector atomic property for link status

At the time userspace does setcrtc, we've already promised the mode would work. The promise is based on the theoretical capabilities of the link, but it's possible we can't reach this in practice. The DP spec describes how the link should be reduced, but we can't reduce the link below the

[PATCH 0/4] Link Training failure handling by sending Hotplug Uevent

This patch series is a final revision of previous patch series for handling link training failure. This has been polished in terms of the kernel documentation based on review feedback. One more patch is added to move sink's max link rate and lane count to intel_dp and compute it at hotplug and

[PATCH 2/2] drm/sti: do not post HQVDP command if no update

Do not process update requests with unmodified parameters. Since the HQVDP command queue is limited to 2, we shall take care of not posting unneeded commands, which would abusively fill the command queue leading to frame update skip. This typically happens when the driver is called with legacy

[PATCH 1/2] drm/sti: load XP70 firmware only once

When a plane is enabled, after having been disabled, do not reload XP70 firmware again, but only register VTG again Signed-off-by: Fabien Dessenne --- drivers/gpu/drm/sti/sti_hqvdp.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c

[PATCH 0/2] drm/sti: HQVDP plane improvements

These patches fix HQVDP plane performance issues - [PATCH 1/2] drm/sti: load XP70 firmware only once - [PATCH 2/2] drm/sti: do not post HQVDP command if no update Fabien

[Bug 98987] [RS690] BUG: soft lockup when radeon modesetting

attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/544f6240/attachment.html>

[PATCH v2 2/3] drm/edid: Implement SCDC support detection

On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote: > On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote: > > On Mon, Dec 05, 2016 at 08:57:43AM +0100, Thierry Reding wrote: > > > On Sat, Dec 03, 2016 at 04:35:24AM +, Sharma, Shashank wrote: > > > > Hi Thierry, > > > >

[PATCH v2 1/3] drm: Add SCDC helpers

On Mon, Dec 05, 2016 at 12:16:52PM +0100, Thierry Reding wrote: > On Mon, Dec 05, 2016 at 10:12:39AM +, Jose Abreu wrote: > > On 02-12-2016 19:24, Thierry Reding wrote: > [...] > > > +/** > > > + * drm_scdc_write - write a block of data to SCDC > > > + * @adapter: I2C controller > > > + *

[PATCH 0/8] Host1x IOMMU support + VIC support

Bump On 10.11.2016 20:23, Mikko Perttunen wrote: > This series adds IOMMU support to Host1x and TegraDRM > and adds support for the VIC host1x client so that > host1x can be tested on modern Tegra platforms. > It depends on the previous fix series. The whole thing > (modulo patch order) is

[PATCH] drm/amdgpu: don't add files at control minor debugfs directory

Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a struct drm_device's ->control member is always NULL. In the case of CONFIG_DEBUG_FS=y, amdgpu_debugfs_add_files() accesses ->control->debugfs_root though. This results in the following Oops: [9.627636] BUG: unable to handle kernel

[PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node

}; It's a bit difficult to follow this as there's been so many patches going around. But I take the above is the LCDC node in the base da850 dtsi file? In that case, what is the display_in supposed to present? It's the first node in the "display chain", so it has no input. Also

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

Hi Jose, On Monday 05 Dec 2016 12:31:30 Jose Abreu wrote: > On 05-12-2016 11:32, Laurent Pinchart wrote: > > On Monday 05 Dec 2016 10:50:19 Jose Abreu wrote: > >> On 02-12-2016 15:43, Laurent Pinchart wrote: > >>> On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote: > On Fri, Dec

[PATCH 1/2] pwm: lpss: Make builtin and add lookup-table so that i915 can find the pwm_backlight

Hi, On 05-12-16 11:59, Thierry Reding wrote: > On Mon, Dec 05, 2016 at 09:18:03AM +0100, Hans de Goede wrote: >> Hi, >> >> On 05-12-16 08:46, Thierry Reding wrote: >>> On Fri, Dec 02, 2016 at 11:17:35AM +0100, Hans de Goede wrote: The primary consumer of the lpss pwm is the i915 kms driver,

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

Hi Thierry, On 05-12-2016 11:14, Thierry Reding wrote: > On Mon, Dec 05, 2016 at 11:06:15AM +, Jose Abreu wrote: >> Hi Thierry, >> >> >> Do you think while you are at it you could implement a >> set_scrambling() callback? It should be pretty straight forward: >> you read the SCDC_TMDS_CONFIG

[PATCH v2 1/3] drm: Add SCDC helpers

Hi, On 05-12-2016 13:31, Ville Syrjälä wrote: > On Mon, Dec 05, 2016 at 12:16:52PM +0100, Thierry Reding wrote: >> On Mon, Dec 05, 2016 at 10:12:39AM +, Jose Abreu wrote: >>> On 02-12-2016 19:24, Thierry Reding wrote: >> [...] +/** + * drm_scdc_write - write a block of data to

[PATCH v2] drm: allow changing DPMS mode

The drm_atomic_helper_connector_dpms will set the connector back the old DPMS state before returning. This makes it impossible to change DPMS state of the connector. Fixes: 0853695c3ba46f97dfc0b5885f7b7e640ca212dd v2: edit of commit message Cc: Chris Wilson Cc: Daniel Vetter Cc: Eric Engestrom

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

Hello, On Friday 02 Dec 2016 18:45:46 Laurent Pinchart wrote: > On Friday 02 Dec 2016 16:08:17 Russell King - ARM Linux wrote: > > On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote: > >> DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that. > >> > >> Do you know why this

[Bug 98357] [amdgpu] Topaz fails to boot with error in powerplay initialization

|RESOLVED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/d25b20e1/attachment.html>

[Bug 98505] [radeon, amdgpu] Regression introduced in 4.8-rc3

tps://lists.freedesktop.org/archives/dri-devel/attachments/20161205/28b599f3/attachment-0001.html>

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

Hi Jose, On Monday 05 Dec 2016 10:50:19 Jose Abreu wrote: > On 02-12-2016 15:43, Laurent Pinchart wrote: > > On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote: > >> On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote: > >>> From: Kieran Bingham

[PATCH v4 2/2] drm/bridge: adv7511: Initialize regulators

Maintain a table of regulator names expect by ADV7511 and ADV7533. Use regulator_bulk_* api to configure these. Initialize and enable the regulators during probe itself. Controlling these dynamically is left for later. Reviewed-by: Laurent Pinchart Signed-off-by: Archit Taneja ---

[PATCH v4 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings

Add the regulator supply properties needed by ADV7511 and ADV7533. Cc: devicetree at vger.kernel.org Acked-by: Laurent Pinchart Signed-off-by: Archit Taneja --- Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 8 1 file changed, 8 insertions(+) diff --git

[PATCH v4 0/2] drm/bridge: adv7511: Enable regulators

The patch below added regulator supplies to the ADV533 HDMI bridge on the DB410c, but the corresponding DT binding doc wasn't updated to list them: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=28546b09551190c727c94d1c5c96ca609065beb2 The first patch adds the

[PATCH 1/1] gpu: drm: qxl: fix use of uninitialized variable

On Sat, Dec 3, 2016 at 10:11 AM, Pan Bian wrote: > In function qxl_release_alloc(), when kmalloc() returns a NULL pointer, > it returns value 0 and parameter *ret is uninitialized. 0 means no error > to the callers of qxl_release_alloc(). The callers keep going and will > try to reference the

[PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings

On Tue 29 Nov 01:11 PST 2016, Laurent Pinchart wrote: > Hi Archit, > > (CC'ing Mark Brown) > > On Tuesday 29 Nov 2016 13:41:33 Archit Taneja wrote: > > On 11/29/2016 12:03 PM, Laurent Pinchart wrote: > > > On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote: > > >> Add the regulator supply

Enabling peer to peer device transactions for PCIe devices

On 05/12/16 12:46 PM, Jason Gunthorpe wrote: > NVMe might have to deal with pci-e hot-unplug, which is a similar > problem-class to the GPU case.. Sure, but if the NVMe device gets hot-unplugged it means that all the CMB mappings are useless and need to be torn down. This probably means

Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 05, 2016 at 12:27:20PM -0700, Logan Gunthorpe wrote: > > > On 05/12/16 12:14 PM, Jason Gunthorpe wrote: > >But CMB sounds much more like the GPU case where there is a > >specialized allocator handing out the BAR to consumers, so I'm not > >sure a general purpose chardev makes a lot

[Intel-gfx] [PATCH 1/3] drm: Add a new connector atomic property for link status

On Fri, Dec 02, 2016 at 05:26:35PM +0100, Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote: > > At the time userspace does setcrtc, we've already promised the mode > > would work. The promise is based on the theoretical capabilities of > > the link, but it's

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

Hi Laurent, On 05-12-2016 11:32, Laurent Pinchart wrote: > Hi Jose, > > On Monday 05 Dec 2016 10:50:19 Jose Abreu wrote: >> On 02-12-2016 15:43, Laurent Pinchart wrote: >>> On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote: On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent

[PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions

On Sun, Dec 4, 2016 at 10:13 PM, Archit Taneja wrote: > > > On 12/02/2016 09:33 PM, Sean Paul wrote: >> >> On Thu, Dec 1, 2016 at 10:54 PM, Archit Taneja >> wrote: >>> >>> Hi, >>> >>> On 12/02/2016 08:02 AM, zain wang wrote: We will ignored PSR setting if panel not support it.

Enabling peer to peer device transactions for PCIe devices

On 05/12/16 12:14 PM, Jason Gunthorpe wrote: > But CMB sounds much more like the GPU case where there is a > specialized allocator handing out the BAR to consumers, so I'm not > sure a general purpose chardev makes a lot of sense? I don't think it will ever need to be as complicated as the GPU

[PATCH v2 1/3] drm: Add SCDC helpers

ooks as if the above should work, but it's probably best to test it a little more widely to make sure we're not running into cases where it breaks. Have you by any chance verified that it works on your hardware? Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/25f08c7f/attachment.sig>

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

; > enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code); > > bool drm_detect_hdmi_monitor(struct edid *edid); > > bool drm_detect_hdmi_scdc(struct edid *edid); > > +bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid); > > bool drm_detect_monitor_audio(struct edid *edid); > > bool drm_rgb_quant_range_selectable(struct edid *edid); > > int drm_add_modes_noedid(struct drm_connector *connector, > -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/fc80b324/attachment.sig>

Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 05, 2016 at 10:48:58AM -0800, Dan Williams wrote: > On Mon, Dec 5, 2016 at 10:39 AM, Logan Gunthorpe > wrote: > > On 05/12/16 11:08 AM, Dan Williams wrote: > >> > >> I've already recommended that iopmem not be a block device and instead > >> be a device-dax instance. I also don't

[PATCH v2 2/3] drm/edid: Implement SCDC support detection

did *edid); > > > +bool drm_detect_hdmi_scdc(struct edid *edid); > > > bool drm_detect_monitor_audio(struct edid *edid); bool > > > drm_rgb_quant_range_selectable(struct edid *edid); int > > > drm_add_modes_noedid(struct drm_connector *connector, diff --git > > > a/include/linux/hdmi.h b/include/linux/hdmi.h index > > > edbb4fc674ed..d271ff23984f 100644 > > > --- a/include/linux/hdmi.h > > > +++ b/include/linux/hdmi.h > > > @@ -35,6 +35,7 @@ enum hdmi_infoframe_type { }; > > > > > > #define HDMI_IEEE_OUI 0x000c03 > > > +#define HDMI_FORUM_IEEE_OUI 0xc45dd8 > > > #define HDMI_INFOFRAME_HEADER_SIZE 4 > > > #define HDMI_AVI_INFOFRAME_SIZE13 > > > #define HDMI_SPD_INFOFRAME_SIZE25 > > > -- > > > 2.10.2 > > > > > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/0e84bba0/attachment-0001.sig>

[PATCH 12/12] drm/msm: gpu: Use the zap shader on 5XX if we can

On Mon 05 Dec 11:57 PST 2016, Bjorn Andersson wrote: [..] > You should rather add a struct device zap_dev to your adreno context, do > minimal initialization (name and a parent I think is enough), call > device_register(_dev);, of_reserved_mem_device_init() and then use > that for your dma

Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 05, 2016 at 12:46:14PM -0700, Jason Gunthorpe wrote: > In any event the allocator still needs to track which regions are in > use and be able to hook 'free' from userspace. That does suggest it > should be integrated into the nvme driver and not a bolt on driver.. Two totally

[PATCH] drm/atomic: doc: remove old comment about nonblocking commits

From: Gustavo Padovan We now support nonblocking commits on drm_atomic_helper_commit() so the comment is not valid anymore. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/drm_atomic_helper.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[GIT PULL] imx-drm: fix plane atomic_update regression

Hi Dave, this tag fixes a regression in the imx-drm YUV plane support [1] that was introduced in v4.9-rc4, as well as an error returned when changing U/V offsets of an active plane to otherwise valid values. [1] https://lkml.org/lkml/2016/11/17/133 Both commits are already contained in

tilcdc: vblank wait timed out

Hi Jyri, I pulled your recent tilcdc pull request on top of v4.9 and Sekhar's davinci branch (+ vga dac DT)[1]. I'm getting "vblank wait timed out" errors when running simple modetest[2]. This error happened before with the drm_bridge series[3], but went away at one of the subsequent patch

[PATCH 1/2] pwm: lpss: Make builtin and add lookup-table so that i915 can find the pwm_backlight

used for. Obfuscating this by turning the name into something unrecognizable such as pwm_lpss0 isn't going to change any of the above. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/fe3da6c5/attachment.sig>

[PATCH 11/12] drm/msm: Add a quick and dirty PIL loader

On Mon 28 Nov 11:28 PST 2016, Jordan Crouse wrote: > In order to switch the GPU out of secure mode on most systems we > need to load a zap shader into memory and get it authenticated > and into the secure world. All the bits and pieces to do > the load are scattered throughout the kernel, but we

[PATCH 12/12] drm/msm: gpu: Use the zap shader on 5XX if we can

On Mon 28 Nov 11:28 PST 2016, Jordan Crouse wrote: > The A5XX GPU powers on in "secure" mode. In secure mode the GPU can > only render to buffers that are marked as secure and inaccessible > to the kernel and user through a series of hardware protections. In > practice secure mode is used to draw

[Bug 98915] NULL pointer dereference on boot - amdgpu_debugfs_add_files

chives/dri-devel/attachments/20161205/80396acc/attachment.html>

Enabling peer to peer device transactions for PCIe devices

On 05/12/16 11:08 AM, Dan Williams wrote: > I've already recommended that iopmem not be a block device and instead > be a device-dax instance. I also don't think it should claim the PCI > ID, rather the driver that wants to map one of its bars this way can > register the memory region with the

[RFC] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

Forgot to send to dri-devel when I first sent this out... The few times I've looked at using DRM_DEBUG messages, I haven't found them very helpful considering how noisy some of the categories are. More than once now I've preferred to go in and modify individual files to affect what messages I see

[Bug 98996] Counter Strike: Global Offensive performance

seems extreme. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/959ee195/attachment.html>

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

Hi Thierry, Do you think while you are at it you could implement a set_scrambling() callback? It should be pretty straight forward: you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it again. I think this is an important feature that we should have. Best regards, Jose Miguel

[Bug 98996] Counter Strike: Global Offensive performance

URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/37dc8bcf/attachment.html>

Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 05, 2016 at 09:40:38AM -0800, Dan Williams wrote: > > If it is kernel only with physical addresess we don't need a uAPI for > > it, so I'm not sure #1 is at all related to iopmem. > > > > Most people who want #1 probably can just mmap > > /sys/../pci/../resourceX to get a user handle

[PATCH] drm/radeon: don't add files at control minor debugfs directory

On Mon, Dec 05, 2016 at 09:48:02AM +0100, Christian König wrote: > Am 05.12.2016 um 09:39 schrieb Nicolai Stange: > > Christian König writes: > > > > > Am 05.12.2016 um 08:27 schrieb Daniel Vetter: > > > > On Sat, Dec 03, 2016 at 03:47:00PM +0100, Nicolai Stange wrote: > > > > > Since commit

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

Hi Laurent, On 02-12-2016 15:43, Laurent Pinchart wrote: > Hi Russell, > > On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote: >> On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote: >>> From: Kieran Bingham >>> >>> The dw-hdmi

Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 5, 2016 at 10:39 AM, Logan Gunthorpe wrote: > On 05/12/16 11:08 AM, Dan Williams wrote: >> >> I've already recommended that iopmem not be a block device and instead >> be a device-dax instance. I also don't think it should claim the PCI >> ID, rather the driver that wants to map one

[PATCH] drm/i915/gvt: fix deadlock in dispatch_workload()'s error path

e.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/9b21b23d/attachment.sig>

Enabling peer to peer device transactions for PCIe devices

On Sun, Dec 04, 2016 at 07:23:00AM -0600, Stephen Bates wrote: > Hi All > > This has been a great thread (thanks to Alex for kicking it off) and I > wanted to jump in and maybe try and put some summary around the > discussion. I also wanted to propose we include this as a topic for LFS/MM >

[PATCH v2 1/3] drm: Add SCDC helpers

Hi Thierry, On 02-12-2016 19:24, Thierry Reding wrote: > From: Thierry Reding > > SCDC is a mechanism defined in the HDMI 2.0 specification that allows > the source and sink devices to communicate. > > This commit introduces helpers to access the SCDC and provides the > symbolic names for the

  1   2   >