..
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/3eb139d6/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/f9710cd3/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/ebcb6c99/attachment.html>
This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_oa_hsw.c | 483 -
1 file changed, 482 insertions(+), 1 deletion(-)
diff --git a/d
The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.
Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.
Signed-off-by: Robert Br
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_dr
Each metric set is given a sysfs entry like:
/sys/class/drm/card0/metrics//id
This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN.
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
Signed-off-by: Zhenyu
Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is autogenerated from an internal XML
description of metric sets.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_drv.h| 14
drivers/gpu
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL vi
check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.
The distinction makes the difference between allowing the buffer to be
executed
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h| 2 +-
2 files chang
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl()
Hopefully covers the last issues raised by Chris and addresses the open issue I
had with removing OACONTROL from the command parser whitelist.
- Robert
Robert Bragg (10):
drm/i915: Add i915 perf infrastructure
drm/i915: rename OACONTROL GEN7_OACONTROL
drm/i915: return EACCES for check_cmd()
s scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/fc204e1c/attachment-0001.html>
On Fri, Apr 29, 2016 at 3:48 AM, Daniel Stone wrote:
> Hi,
>
> On 28 April 2016 at 23:28, Rob Clark wrote:
>> On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter wrote:
>>> On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote:
A (per-CRTC?) array of fences would be more flexible. And e
of that. I
don't like how DRM and fbdev gets mixed...
I offer a beer to anyone who does that =).
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/4c609073/attachment.sig>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/50c4815d/attachment-0001.html>
On Thu, Apr 28, 2016 at 10:46:47AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> This patchset sits on top of Sync ABI Rework v13:
>
> https://www.spinics.net/lists/dri-devel/msg105667.html
>
> The first eight clean up and prepare sync_file for de-staging. The last four
> p
Adding David, forgot that before hitting send.
-Daniel
On Fri, Apr 29, 2016 at 5:36 PM, Daniel Vetter wrote:
> On Fri, Apr 29, 2016 at 06:00:18PM +0300, Tomi Valkeinen wrote:
>>
>> On 29/04/16 17:55, Daniel Vetter wrote:
>>
>> >> Who's calling {write,fillrect,copyarea,imageblit} in an atomic cont
On Fri, Apr 29, 2016 at 06:00:18PM +0300, Tomi Valkeinen wrote:
>
> On 29/04/16 17:55, Daniel Vetter wrote:
>
> >> Who's calling {write,fillrect,copyarea,imageblit} in an atomic context?
> >> That sounds like a very bad idea to me...
> >>
> >> If this is only for accumulating changes, I think it
p-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/ca9134ae/attachment-0001.sig>
On Thu, Apr 28, 2016 at 05:18:30PM +0200, Noralf Trønnes wrote:
> This patchset adds fbdev deferred io support to drm_fb_helper and
> drm_fb_cma_helper.
>
> It channels fbdev mmap and fb_{write,fillrect,copyarea,imageblit} damage
> through the (struct drm_framebuffer_funcs)->dirty callback on the
On Fri, Apr 29, 2016 at 03:50:40PM +0300, Tomi Valkeinen wrote:
> Hi,
>
> On 28/04/16 18:18, Noralf Trønnes wrote:
> > This adds deferred io support to drm_fb_helper.
> > The fbdev framebuffer changes are flushed using the callback
> > (struct drm_framebuffer *)->funcs->dirty() by a dedicated wor
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160429/fd069c17/attachment.html>
|--- |FIXED
--
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/20160429/0c562666/attachment.html>
Den 29.04.2016 14:50, skrev Tomi Valkeinen:
> Hi,
>
> On 28/04/16 18:18, Noralf Trønnes wrote:
>> This adds deferred io support to drm_fb_helper.
>> The fbdev framebuffer changes are flushed using the callback
>> (struct drm_framebuffer *)->funcs->dirty() by a dedicated worker
>> ensuring that it
bbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/b4038ce9/attachment.html>
Hi Dave,
v3:
This driver should only work on arm64 system.
So add ARM64 depends on to the Kconfig in this commit:
23e7b2ab9a8f drm/hisilicon: Add hisilicon kirin drm master driver
The 32-bit system compilation warnings and errors should not be existed.
Please help to try and let me know if there
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/9c747932/attachment.html>
On Thursday 28 April 2016 07:49 PM, Alexey Brodkin wrote:
> Even though for AXS101 (which sorts ARC770 CPU) IOC is not
> an option for a sake of keeping one DT description for the
> base-board (axs10x_mb.dtsi) we're still defining reserved
> memory location in the very end of DDR.
>
> Signed-off-b
---
Still happening in Ubuntu 16.04 LTS which ships Mesa 11.2.0.
--
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/20160429/6cd3c
From: Hans Verkuil
The vivid driver has been extended to provide CEC adapters for the HDMI
input and HDMI outputs in order to test CEC applications.
This CEC emulation is faithful to the CEC timings (i.e., it all at a
snail's pace).
Signed-off-by: Hans Verkuil
---
Documentation/video4linux/vi
From: Kamil Debski
Add CEC interface driver present in the Samsung Exynos range of
SoCs.
The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
.../devicetree/bindings/media/s5p-cec.txt
From: Hans Verkuil
Add CEC support to the adv7511 driver.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/Kconfig | 9 +
drivers/media/i2c/adv7511.
From: Hans Verkuil
Add CEC support to the adv7842 driver.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/Kconfig | 9 ++
drivers/media/i2c/adv7842.c | 368
2 files changed, 314 insertions(+), 63 deletions(-)
diff --git a/drivers/media/i2c/Kc
From: Hans Verkuil
Add CEC support to the adv7604 driver.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
[k.debski at samsung.com: add missing methods cec/io_write_and_or]
[k.debski at samsung.com: change adv7604 to adv76xx in adde
From: Hans Verkuil
Add DocBook documentation for the CEC API.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: add documentation for passthrough mode]
[k.debski at samsung.com: minor fixes and change of reserved field sizes]
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
Do
From: Hans Verkuil
Document the new HDMI CEC framework.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: add DocBook documentation by Hans Verkuil, with
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
Documentation/cec.txt | 267 ++
From: Hans Verkuil
The CEC ioctls didn't have compat32 support, so they returned -ENOTTY
when used in a 32 bit application on a 64 bit kernel.
Since all the CEC ioctls are 32-bit compatible adding support for this
API is trivial.
Signed-off-by: Hans Verkuil
---
fs/compat_ioctl.c | 12
From: Hans Verkuil
Explain why cec.c is still in staging.
Signed-off-by: Hans Verkuil
---
drivers/staging/media/cec/TODO | 13 +
1 file changed, 13 insertions(+)
create mode 100644 drivers/staging/media/cec/TODO
diff --git a/drivers/staging/media/cec/TODO b/drivers/staging/media/
From: Hans Verkuil
The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.
Besides the cec module itself it also adds a cec-edid module that
contains helper functions to find and manipulate the CEC physical
address inside an EDID. Even if the CEC support itself is
From: Kamil Debski
Add handling of remote control events coming from the HDMI CEC bus.
This patch includes a new keymap that maps values found in the CEC
messages to the keys pressed and released. Also, a new protocol has
been added to the core.
Signed-off-by: Kamil Debski
Signed-off-by: Hans V
From: Kamil Debski
Add HDMI CEC specific keycodes to the keycodes definition.
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
Acked-by: Dmitry Torokhov
---
include/uapi/linux/input-event-codes.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/inclu
From: Hans Verkuil
Inputs can come in over the HDMI CEC bus, so add a new type for this.
Signed-off-by: Hans Verkuil
Acked-by: Dmitry Torokhov
---
include/uapi/linux/input.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 01113
From: Hans Verkuil
Hi all,
The sixteenth version of this patchset does some final cleanup and
I'll post a pull request on the linux-media list for this patch series.
At first I didn't want to post a v16 at all, but there were just a bit
too many changes, even though each change itself was trivi
umulate.
But, of course, this is a helper, so if all the drivers use this kind of
accumulation, it makes sense =).
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/60a28cd0/attachment.sig>
After async atomic_commit callback, drm_atomic_clean_old_fb will
cleanup all old fb, but because async, the old fb may be also on
the vop hardware, dma will access the old fb buffer, clean old
fb will cause iommu page fault.
Fix the problem by reference the fb and unreference it when the fb
actual
It seems trigger cannot be configured too early, otherwise it does not work in
case of panel. The patch fixes also trigger flag logic, previously HW-TRIGGER
flag was cleared in case of panel - as a result panel used always software
trigger.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos
Software trigger should not be used if hardware trigger is configured.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exyn
vblank should be signaled to userspace after reading framebuffers not before,
signaling it in TE interrupt looks wrong. TE triggers reading framebuffers
so it is the worst moment. Tearing is not observable because hardware prevents
it, but there are frequently skipped vblank events.
Signed-off-by:
There is a path that use vskiplines with non-initialize.
That would cause vop abnormal behavior.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160429/1db464cc/attachment-0001.html>
The MDP4 driver tries to request and set voltages for regulators required
by the DSI PLLs.
Firstly, the MDP4 driver shouldn't manage the DSI regulators, this should
be handled in the DSI driver. Secondly, it shouldn't try to set a fixed
voltage for regulators. Voltage constraints should be specifi
The eDP driver tries to set a fixed voltage for one of its regulators(vdda)
before enabling it. This shouldn't be done by the driver, the voltage
constraints should be specified on the regulator via DT and managed by
the regulator core. A driver should call regulator_set_voltage only if
it needs to
The voltage changing code in this driver is broken and should be
removed. The driver sets a single, exact voltage on probe. Unless
there is a very good reason for this (which should be documented in
comments) constraints like this need to be set via the machine
constraints, voltage setting in a d
The MSM KMS driver calls regulator_set_voltage to set a fixed voltage in a
few places. This isn't correct API usage as explained in the commit message
of Mark Brown's original patch:
http://www.spinics.net/lists/dri-devel/msg103714.html
This patchset drops all the regultor_set_voltage calls. The
...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/324a5467/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/8e0ef851/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/5b845965/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/dd15435a/attachment.html>
From: Damien Lespiau
This patch adds support for blending modes involving
color.
V2: Add support for primary plane.
Separate out plane alpha disable functionality from per pixel
drop_alpha blend function and add another blend function case for
disabling plane alpha.
Signed-off-by: Damien Lespia
From: Damien Lespiau
Add blend color property and update the
documentation for the same
V2: Add blend color support in get property.
Signed-off-by: Damien Lespiau
Signed-off-by: vandita kulkarni
---
Documentation/DocBook/gpu.tmpl | 11 +--
drivers/gpu/drm/drm_atomic.c | 4
dr
From: Damien Lespiau
In the hope of expressing colors in the KMS API in a consitant want,
let's introduce a ARGB 16161616 color and a few convinience macros
around it.
Signed-off-by: Damien Lespiau
---
include/uapi/drm/drm_mode.h | 34 ++
1 file changed, 34 inse
From: Damien Lespiau
This patch adds the blend functions, and as per the
blend function, updates the plane control register values
V2: Add blend support for all RGB formats
Fix the reg writes on plane_ctl_alpha bits.
V3: Add support support for primary and cursor planes.
fix an issue where
From: Damien Lespiau
We'd like to be able to program the blending modes of display planes.
Ville suggested to use something similar to the GL blend states, which
does seem like a good idea.
For now, we only consider blend factors, but room is left for
extensions: blend equation, separate rgb/alp
From: vandita kulkarni
The below patches support plane and pixel blending
by adding two properties blend_func and blend_color.
As per Damien's initial patches, this design based on
OpenGL's blend equations is suggested by Ville.
All the below patches are tested on BXT android platform.
V2: Squa
https://bugzilla.kernel.org/show_bug.cgi?id=117171
--- Comment #3 from Erik Brangs ---
The problem might be related to DPMS: I haven't seen any freezes after
deactivating DPMS in xscreensaver.
When I use DPMS with "Standby" in xscreensaver and set the times for "Suspend"
and "Off" to a high valu
>
> V2 has fixed the module compilation error and warnings in this commit:
> 3d76c7e5bbdd drm/hisilicon: Add designware dsi encoder driver
>
> Please help to try and let me know if there is any problem.
I'm still seeing the bit cast warning, it's due to using MASK(32),
this is pretty much
undefine
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/95a30b1c/attachment.html>
On 04/26/2016 11:39 PM, Daniel Vetter wrote:
>> A (per-CRTC?) array of fences would be more flexible. And even in the cases
>> where you could make a 1-to-1 mapping between planes and fences, it's not
>> that much more work for userspace to assemble those fences into an array
>> anyway.
>
> I'm ok
MS_HELPER
> select DRM_KMS_FB_HELPER
> select FB_SYS_FILLRECT
>
Thanks, queued for 4.7.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL
es
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/b7fabc03/attachment.sig>
On Fri, Apr 29, 2016 at 04:27:08AM +0200, Florian Zumbiehl wrote:
> Hi,
>
> > The Bugzilla at https://bugs.freedesktop.org is our tool of choice for
> > tracking bugs in drm/i915. It's your choice to not create an account
> > there, but please, don't expect us to work as a proxy between you and
>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/a1dd260c/attachment-0001.html>
On Fri, Apr 29, 2016 at 02:59:13PM +0530, Vandita Kulkarni wrote:
> From: Damien Lespiau
>
> We'd like to be able to program the blending modes of display planes.
> Ville suggested to use something similar to the GL blend states, which
> does seem like a good idea.
>
> For now, we only consider
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/180e0a79/attachment.html>
This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50.
There is apparently something amiss with the way the TTM code handles
DMA buffers, which the above commit was attempting to work around for
arm64 systems with non-coherent PCI. Unfortunately, this completely
breaks systems *with* cohere
On Async atomic_commit callback, drm_atomic_clean_old_fb will
clean all old fb, but because async, the old fb may be also on
the vop hardware, dma will access the old fb buffer, clean old
fb will cause iommu page fault.
Reference the fb and unreference it when the fb actuall swap out
from vop hard
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/b5b58f88/attachment-0001.html>
From: Hans Verkuil
As long as there is a valid physical address in the EDID and the omap
CEC support is enabled, then we keep ls_oe_gpio on to ensure the CEC
signal is passed through the tpd12s015.
Signed-off-by: Hans Verkuil
Suggested-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/displays/e
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
arch/arm/boot/dts/omap4-panda-a4.dts | 2 +-
arch/arm/boot/dts/omap4-panda-es.dts | 2 +-
arch/arm/boot/dts/omap4.dtsi | 5 +-
drivers/gpu/drm/omapdrm/dss/Kconfig| 8 +
drivers/gpu/drm/omapdrm/dss/Makefile | 3 +
d
From: Tomi Valkeinen
hdmi_core_powerdown_disable() is supposed to disable HDMI core's
power-down mode. However, the function sets the power-down bit to 0,
which means "enable power-down".
This hasn't caused any issues as the PD seems to affect only interrupts
from HDMI core, and none of those in
From: Hans Verkuil
This patch series sits on top of my earlier HDMI CEC framework:
http://www.spinics.net/lists/linux-media/msg99847.html
It is an RFC patch for now as I want to clean up hdmi_cec a bit more
and do a bit more testing.
Many thanks to Tomi for finding obscure problems in the omap
Hi Dave,
Please pull this mini-series that allows ARC PGU to use
dedicated memory location as framebuffer backing storage.
v2 of that series was reviewed here
https://lists.freedesktop.org/archives/dri-devel/2016-April/106279.html
It is based on top of today's drm-next branch.
Best regards,
Ale
Finally all the core gem and a lot of drivers are entirely free of
dev->struct_mutex depencies, and we can start to have an entirely
lockless unref path.
To make sure that no one who touches the core code accidentally breaks
existing drivers which still require dev->struct_mutex I've made the
migh
Some rockchip vop not support iommu, need use non-iommu
buffer for it. And if we get iommu issues, we can compare
the issues with non-iommu path, the would help the debug.
Signed-off-by: Mark Yao
---
Changes in v3
- fix conflict with other iommu patch.
Changes in v2
Advised by Heiko Stuebner
- us
On Thu, Apr 28, 2016 at 04:42:28PM -0700, Stefan Agner wrote:
> Hi Dave,
>
> This adds very rudimentary TCON (timing controller for raw LCD displays)
> support to enable the bypass mode in order to use the DCU controller on
> Freescale/NXP Vybrid SoC's.
>
> Additionally the register clock and pix
On Fri, Apr 29, 2016 at 12:02:15AM +0300, Sergei Shtylyov wrote:
> TCON (Timing Controller) usually means a chip that drives a LCD panel.
> In our case, such controller is a part of the Renesas R-Car SoCs. Add
> the TCON encoder/connector #define's to be used by the TCON support code
> in the
Am Donnerstag, den 28.04.2016, 15:37 +0100 schrieb Russell King - ARM
Linux:
> On Thu, Apr 28, 2016 at 04:04:58PM +0200, Lucas Stach wrote:
> > The observation was that the common code in iommu_map() rightfully
> > rejected to map things, as mapping something unaligned to the page size
> > is total
the output I see from failing followed by working with above commit
reverted.
--
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/20
Hi Dave,
- prep work for struct_mutex-less gem_free_object
- more invasive/tricky mst fixes from Lyude for broken hw. I discussed
this with Ville/Jani and we all agreed more soaking in -next would be
real good this late in the -rc cycle. They're cc: stable too to make
sure they're not gettin
lt;https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/4534e92b/attachment-0001.html>
On Mi, 2016-04-27 at 20:16 +0200, Noralf Trønnes wrote:
> I have also added patches that converts qxl and udl to use this
> deferred io support. I have only compile tested it, no functional
> testing.
> I know that qxl is purely a software thing so I could actually test
> it, but
> I have never us
Hi Dave,
drm-intel-next-2016-04-25:
- more userptr cornercase fixes from Chris
- clean up and tune forcewake handling (Tvrtko)
- more underrun fixes from Ville, mostly for ilk to appeas CI
- fix unclaimed register warnings on vlv/chv and enable the debug code to catch
them by default (Ville)
- s
Hi,
On 28 April 2016 at 23:28, Rob Clark wrote:
> On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter wrote:
>> On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote:
>>> A (per-CRTC?) array of fences would be more flexible. And even in the cases
>>> where you could make a 1-to-1 mapping bet
Am Donnerstag, den 28.04.2016, 16:48 -0500 schrieb Rob Herring:
> On Wed, Apr 27, 2016 at 04:23:34PM -0400, Akshay Bhat wrote:
> > Document the ddc-i2c-bus property used by imx-ldb driver to read EDID
> > information via I2C interface.
> >
> > Signed-off-by: Akshay Bhat
> > ---
> >
> > v3:
> > N
On Thu, Apr 28, 2016 at 11:52 PM, Laurent Pinchart
wrote:
>> > I thought turning the plane off was done by setting
>> > the framebuffer to NULL (in which case the src and crtc coordinates must
>> > of course be ignored) ?
>>
>> That's another way. However setting the fb to 0 is a bit different, as
___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/1a899f57/attachment-0001.sig>
On Fri, Apr 29, 2016 at 1:32 AM, Vinay Simha wrote:
> hi,
>
> In nx7, backlight brightness control is controlled by dcs commands of
> MIPI_DCS_SET_DISPLAY_BRIGHTNESS.
> there is no PWM going to panel interface directly as we have in ifc6410/nx5
afaiu it is not uncommon to need to control backligh
1 - 100 of 108 matches
Mail list logo
