Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_pm.c
between commit:
344df9809f45 ("drm/i915/skl: Disable coarse power gating up until F0")
from Linus' tree and commit:
06e668ac91c9 ("drm/i915: Apply broader WaRsDisableCoarsePowerGati
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/c27f4005/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/009ea31b/attachment.html>
Hi
I want to push these patches in a couple of days, So just Ping if
anyone interested or have some doubt on it.
Thanks.
-Mark
On 2015å¹´12æ17æ¥ 11:37, Mark Yao wrote:
> This series of patches add rk3036 vop support.
>
> RK3036 registers layout is quite difference with rk3288 layout,
> T
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/0a084e05/attachment.html>
On Mon, Dec 21, 2015 at 06:08:44PM -0800, Eric Anholt wrote:
> I've tested and confirmed that it doesn't actually work. We'll need
> to sort out how to do this properly later, but for now just remove it
> since it also caused build breakage due to using CONFIG_PM_SLEEP
> functions without our Kcon
would be Pitcarin/GCN. Don't know
if that makes a difference.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/a3b98779/attachment-0001.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/8b6d74cd/attachment.html>
trace or some shared Gallium
/ Mesa code rather than in the radeonsi driver.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/5d7d7d30/attachment.html>
Add support for Synopsys DesignWare MIPI DSI controller which is
embedded in the rk3288 SoCs.
Signed-off-by: Chris Zhong
---
Changes in v6.2:
- Remove the atomic feature check (Mark Yao)
Changes in v6.1:
- Add atomic API support (Heiko Stübne)
Changes in v6:
- Do not use bridge driver (Thierr
achments/20151222/b0d9d9eb/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/01f4897a/attachment.html>
ives/dri-devel/attachments/20151222/9e4df887/attachment.html>
I could try to reproduce it by looping the replay over, if
needed.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/201
rubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/f5491fbd/attachment.html>
Op 19-12-15 om 02:27 schreef Matt Roper:
> pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the
> legacy FB fields (plane->fb and plane->old_fb). However it was building
> the plane mask to pass to this function incorrectly (the bitwise OR was
> using plane indices rather than plan
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/6c329a26/attachment-0001.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/c72e0e75/attachment.html>
Will try now with llvmpipe
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/312c0cb5/attachment.html>
be missing GL_EXT_texture_compression_s3tc. Do you have
libtxc-dxtn(-s2tc) packages installed?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/arc
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151222/6dcabd6a/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/a58bd638/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/1a94599a/attachment.html>
Hi Dave,
Final 4.5 feature pull for drm/i915!
drm-intel-next-2015-12-18:
- fix atomic watermark recomputation logic (Maarten)
- modeset sequence fixes for LPT (Ville)
- more kbl enabling&prep work (Rodrigo, Wayne)
- first bits for mst audio
- page dirty tracking fixes from Dave Gordon
- new get_e
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/f50e1fcb/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/1df529f0/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151222/83c49326/attachment.html>
On Wednesday, December 16, 2015 12:26 PM, Yakir Yang wrote:
>
> Fix some obvious alignment problems, like alignment and line
> over 80 characters problems, make this easy to be maintained
> later.
>
> Signed-off-by: Yakir Yang
> Reviewed-by: Krzysztof Kozlowski
> Tested-by: Javier Martinez Cani
On Wednesday, December 16, 2015 12:28 PM, Yakir Yang wrote:
>
> link_rate and lane_count already configured in analogix_dp_set_link_train(),
> so we don't need to config those repeatly after training finished, just
> remove them out.
>
> Beside Display Port 1.2 already support 5.4Gbps link rate,
On Wednesday, December 16, 2015 12:35 PM, Yakir Yang wrote:
>
> After exynos_dp have been split the common IP code into analogix_dp driver,
> the analogix_dp driver have deprecated some Samsung platform properties which
> could be dynamically parsed from EDID/MODE/DPCD message, so this is an updat
On Wednesday, December 16, 2015 12:41 PM, Yakir Yang wrote:
>
> Add phy driver for the Rockchip DisplayPort PHY module. This
> is required to get DisplayPort working in Rockchip SoCs.
>
> Signed-off-by: Yakir Yang
> Reviewed-by: Heiko Stuebner
> ---
> Changes in v11: None
> Changes in v10:
> -
On Wednesday, December 16, 2015 12:58 PM, Yakir Yang wrote:
>
> After test on rockchiop platform, i found sometims driver would failed
> at reading EDID message. After debugging more, i found that it's okay
> to read_a byte from i2c, but it would failed at AUX transcation if we
> try to ready mult
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/1edcbe78/attachment.html>
On Tue, Dec 22, 2015 at 11:37:18AM +0100, Daniel Vetter wrote:
> Hi Dave,
>
> Final 4.5 feature pull for drm/i915!
>
> drm-intel-next-2015-12-18:
> - fix atomic watermark recomputation logic (Maarten)
> - modeset sequence fixes for LPT (Ville)
> - more kbl enabling&prep work (Rodrigo, Wayne)
> -
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/4d7366bf/attachment-0001.html>
On Tue, Dec 22, 2015 at 03:05:14PM +0100, Daniel Vetter wrote:
> On Tue, Dec 22, 2015 at 11:37:18AM +0100, Daniel Vetter wrote:
> > Hi Dave,
> >
> > Final 4.5 feature pull for drm/i915!
> >
> > drm-intel-next-2015-12-18:
> > - fix atomic watermark recomputation logic (Maarten)
> > - modeset seque
On 22/12/15 14:31, Chris Wilson wrote:
> On Tue, Dec 22, 2015 at 03:05:14PM +0100, Daniel Vetter wrote:
>> On Tue, Dec 22, 2015 at 11:37:18AM +0100, Daniel Vetter wrote:
>>> Hi Dave,
>>>
>>> Final 4.5 feature pull for drm/i915!
>>>
>>> drm-intel-next-2015-12-18:
>>> - fix atomic watermark recomput
David,
Please incorporate the latest Armada DRM development updates development
updates, which can be found at:
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-devel
with SHA1 0b8ebeacf5ef43a467c7ec5400ccc1ffc3fbdfba.
These are the patches from Daniel Vetter, getting rid of struct_mu
David,
Please incorporate the latest TDA998x I2C driver development updates,
which can be found at:
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-tda998x-devel
with SHA1 9736e988d32807d5a186c722928a97f37346fec8.
These changes from Liviu add support for atomic mode setting, add the
TMDS cl
On Thu, Dec 03, 2015 at 04:56:07PM +, Russell King - ARM Linux wrote:
> On Thu, Dec 03, 2015 at 10:40:45AM +, Liviu Dudau wrote:
> > This series depends on Sudeep Holla's SCPI driver (now in mainline) and on
> > the tda998x patches that have been queued on Russell's patch system here
> > [
On Fri, Nov 20, 2015 at 02:22:03PM +, Liviu Dudau wrote:
> Hello,
>
> This is v2 of the patchset trying to make drm_of_component_probe() cope with
> finding
> both local crtc ports and remote encoder ones. Heiko Stübner was nice enough
> to test
> an earlier version that was patched followi
ARM's Juno board has two HDLCD controllers, each linked to an NXP
TDA19988 HDMI transmitter that provides output encoding. Add them
to the device tree.
Signed-off-by: Liviu Dudau
Acked-by: Sudeep Holla
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 46 +++---
1 file ch
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
Acked-by: Rob Herring
---
.../devicetree/bindings/display/arm,hdlcd.txt | 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display
This series adds support for ARM's HDLCD display controller found in Juno
and ARM TC2 Coretile. The HDLCD outputs an RGB stream that feeds into a
single digital encoder (DVI or HDMI).
A few days after sending the v6 series and a timid pull request I've discovered
that the changes piled in linux-ne
Update MAINTAINERS file for HDLCD driver.
Cc: Greg KH
Cc: Andrew Morton
Cc: Mauro Carvalho Chehab
Cc: David S. Miller
Signed-off-by: Liviu Dudau
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9a68ea9..050bbf2 100644
--- a/MAINTAINER
The HDLCD controller is a display controller that supports resolutions
up to 4096x4096 pixels. It is present on various development boards
produced by ARM Ltd and emulated by the latest Fast Models from the
company.
Cc: David Airlie
Cc: Robin Murphy
Signed-off-by: Liviu Dudau
Acked-by: Daniel
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/46c52f8c/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/b1a9d573/attachment.html>
r.
Should I do something else? And is there a way to make the card work at its
normal frequencies?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dr
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/0c4e3c73/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/6ebf0f5f/attachment.html>
hut down
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/1a9c3fe5/attachment.html>
On Fri, Dec 18, 2015 at 05:19:24PM -0200, Tiago Vignatti wrote:
> On 12/18/2015 05:02 PM, Tiago Vignatti wrote:
> >On 12/17/2015 06:01 AM, Chris Wilson wrote:
> >>On Wed, Dec 16, 2015 at 08:25:36PM -0200, Tiago Vignatti wrote:
> >>>This function is meant to be used with dma-buf mmap, when finishing
Hey back,
Thank you Daniel, Chris, Alex and Thomas for reviewing the last series. I
think I addressed most of the comments now in version 7, including:
- being even more wording in the doc about sync usage.
- pass .write = false always in i915 end_cpu_access.
- add sync invalid flags test (i
From: Daniel Thompson
Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.
It is trivial to relax the restriction and permit read/write a
This patch removes range-based information used for optimizations in
begin_cpu_access and end_cpu_access.
We don't have any user nor implementation using range-based flush. It seems a
consensus that if we ever want something like that again (or even more robust
using 2D, 3D sub-range regions) we c
From: Daniel Vetter
The userspace might need some sort of cache coherency management e.g. when CPU
and GPU domains are being accessed through dma-buf at the same time. To
circumvent this problem there are begin/end coherency markers, that forward
directly to existing dma-buf device drivers vfunc
This function is meant to be used with dma-buf mmap, when finishing the CPU
access of the mapped pointer.
The error case should be rare to happen though, requiring the buffer become
active during the sync period and for the end_cpu_access to be interrupted. So
we use a uninterruptible mutex_lock t
Userspace is the one in charge of flush CPU by wrapping mmap with
begin{,end}_cpu_access.
v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix return
before transferring ownership when mmap fails.
v3: Fix return values.
v4: !obj->base.filp is user triggerable, so removed the WA
This patch moves userptr definitions and helpers implementation that were
locally in gem_userptr_benchmark and gem_userptr_blits to the library, so other
tests can make use of them as well. There's no functional changes.
v2: added __ function to differentiate when errors want to be handled back in
From: Rob Bradford
This test has the following subtests:
- test_correct for correctness of the data
- test_map_unmap checks for mapping idempotency
- test_reprime checks for dma-buf creation idempotency
- test_forked checks for multiprocess access
- test_refcounting checks for buffer referen
This patch adds test_correct_cpu_write, which maps the texture buffer through a
prime fd and then writes directly to it using the CPU. It stresses the driver
to guarantee cache synchronization among the different domains.
This test also adds test_forked_cpu_write, which creates the GEM bo in one
p
This patch adds dma-buf mmap synchronization ioctls that can be used by tests
for cache coherency management e.g. when CPU and GPU domains are being accessed
through dma-buf at the same time.
v7: add sync invalid flags test.
Signed-off-by: Tiago Vignatti
---
lib/ioctl_wrappers.c | 26 ++
This program can be used to detect when CPU writes in the dma-buf mapped object
don't land in scanout due cache incoherency.
Although this seems a problem inherently of non-LCC machines ("Atom"), this
particular test catches a cache dirt on scanout on LLC machines as well. It's
inspired in Ville's
Different than kms_mmap_write_crc that captures the coherency issues within the
scanout mapped buffer, this one is meant for test dma-buf mmap on !llc
platforms mostly and provoke coherency bugs so we know where we need the sync
ioctls.
I tested this with !llc and llc platforms, BTY and IVY respec
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/f90b1d0b/attachment.html>
lt;http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/1feeb0e3/attachment.html>
Hi Dave,
Sorry if you get this several times, I've been having trouble with
git-send-email and gmail the last couple of days.
Radeon and amdgpu changes for drm-next. Big changes:
- Drop UMS support in radeon
- Support vbios fetch directly from rom on dGPU
- Support for EDC init on CZ
- DP audio
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151222/f1f6c46b/attachment.html>
69 matches
Mail list logo
