uild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 25159 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/7b21c6e5/attachment-0001.gz>
Signed-off-by: Christian Gmeiner
---
etnaviv/etnaviv_pipe.c | 2 +-
etnaviv/etnaviv_priv.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/etnaviv/etnaviv_pipe.c b/etnaviv/etnaviv_pipe.c
index 6951362..94c5d37 100644
--- a/etnaviv/etnaviv_pipe.c
+++ b/etnaviv/etnaviv_pipe.c
We can make use of etna_pipe_wait_ns(..).
Signed-off-by: Christian Gmeiner
---
etnaviv/etnaviv_pipe.c | 21 +
etnaviv/etnaviv_priv.h | 9 -
2 files changed, 1 insertion(+), 29 deletions(-)
diff --git a/etnaviv/etnaviv_pipe.c b/etnaviv/etnaviv_pipe.c
index f2e417f..6
We need to pass through a timeout parameter to implement
pipe->fence_finish() properly. The new fxn accepts a timeout
in nanoseconds.
Signed-off-by: Christian Gmeiner
---
etnaviv/etnaviv-symbol-check | 1 +
etnaviv/etnaviv_drmif.h | 1 +
etnaviv/etnaviv_pipe.c | 24 +
Add an API to pass the timeout value (ns) from pipe->fence_finish(..)
to the kernel. The current API accepts ms and special handling is needed
for PIPE_TIMEOUT_INFINITE.
The idea is not to break old mesa (out-of-tree) + new libdrm. It may be
possible to break etnaviv's ABI as the gallium driver is
Please ignore... v2 is coming.
thanks
--
Christian Gmeiner, MSc
https://soundcloud.com/christian-gmeiner
2016-11-22 22:54 GMT+01:00 Christian Gmeiner :
> We need to pass through a timeout parameter to implement
> pipe->fence_finish() properly. The new fxn accepts a timeout
> in nanoseconds.
>
>
We need to pass through a timeout parameter to implement
pipe->fence_finish() properly. The new fxn accepts a timeout
in nanoseconds.
Signed-off-by: Christian Gmeiner
---
etnaviv/etnaviv-symbol-check | 1 +
etnaviv/etnaviv_drmif.h | 1 +
etnaviv/etnaviv_pipe.c | 24 +
ts.freedesktop.org/archives/dri-devel/attachments/20161122/0ef9451f/attachment.html>
>Â I don't think we should be using numa distance to reverse engineer a
> certain allocation behavior. The latency data should be truthful, but
>Â you're right we'll need a mechanism to keep general purpose
>Â allocations out of that range by default.Â
Just to clarify: Do you propose/thinking
On Tue, Nov 22, 2016 at 9:35 PM, Serguei Sagalovitch
wrote:
>
> On 2016-11-22 03:10 PM, Daniel Vetter wrote:
>>
>> On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams
>> wrote:
>>>
>>> On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch
>>> wrote:
I personally like "device-DAX" idea but my
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/524c6590/attachment.html>
/lists.freedesktop.org/archives/dri-devel/attachments/20161122/14a7a8ee/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/7ce641d5/attachment.html>
L:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/376c56b6/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/ab5dab8e/attachment.html>
On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
wrote:
> This is RFC patch for adding a connector link-status property
> and making it atomic by adding it to the drm_connector_state.
> This is to make sure its wired properly in drm_atomic_connector_set_property
> and drm_atomic_connector_get_proper
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/2f4934a8/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/3124095d/attachment-0001.html>
aybe this is more random than i think before.
--
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/20161122/f90da7eb/attachment.html>
On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams
wrote:
> On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch
> wrote:
>> I personally like "device-DAX" idea but my concerns are:
>>
>> - How well it will co-exists with the DRM infrastructure / implementations
>>in part dealing with CPU poin
On 22/11/2016 19:54, Eric Blake wrote:
>>> >> DRM DRIVER FOR BOCHS VIRTUAL GPU
>>> >> M: Gerd Hoffmann
>>> >> -S: Odd Fixes
>>> >> +L: qemu-devel at nongnu.org
>> >
>> > qemu-devel list already has very high traffic - not sure whether it
>> > makes much sense to route even more
Hi Sudeep,
On Tuesday 22 November 2016 04:23 PM, Sudeep Holla wrote:
>
>
> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>> Add a function allowing to retrieve the compatible string of the root
>> node of the device tree.
>>
>
> Rob has queued [1] and it's in -next today. You can reuse that if
/amdgpu_pm_info to verify the clocks at
runtime.
--
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/20161122/9da1ca43/attachment.html>
Hi John,
(CC'ing Daniel)
On Tuesday 22 Nov 2016 10:07:53 John Stultz wrote:
> On Tue, Nov 22, 2016 at 9:38 AM, John Stultz
> wrote:
> > Interestingly, without the msleep added in this patch, removing the
> > wait_event_interruptible_timeout() method in adv7511_wait_for_edid()
> > and using the
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/fe3442c8/attachment.html>
On Tue, Nov 22, 2016 at 12:35:53PM -0500, Rob Clark wrote:
> On Tue, Nov 22, 2016 at 12:31 PM, Ville Syrjälä
> wrote:
> > On Tue, Nov 22, 2016 at 12:23:59PM -0500, Rob Clark wrote:
> >> On Tue, Nov 22, 2016 at 11:50 AM, Ville Syrjälä
> >> wrote:
> >> > On Tue, Nov 22, 2016 at 04:41:06PM +
Hi John,
On Tuesday 22 Nov 2016 09:25:22 John Stultz wrote:
> On Tue, Nov 22, 2016 at 12:14 AM, Laurent Pinchart wrote:
> > On Monday 21 Nov 2016 16:37:30 John Stultz wrote:
> @@ -545,24 +554,13 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
> >> unsigned int count;
> >>
>
On Tue, Nov 22, 2016 at 12:23:59PM -0500, Rob Clark wrote:
> On Tue, Nov 22, 2016 at 11:50 AM, Ville Syrjälä
> wrote:
> > On Tue, Nov 22, 2016 at 04:41:06PM +, Liviu Dudau wrote:
> >> drm_get_format_name() de-references the buf parameter without checking
> >> if the pointer was not NULL. Giv
We should wait for the last frame to complete before shutting things
down also on LCDC rev 1.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 34 +-
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 1 +
2 files changed, 18 insertions(+), 17 deletions(-
Load palette at the end of mode_set_nofb() and only if the palette has
not been loaded since last runtime resume. Moving the palette loading
to mode_set_nofb() saves us from storing and restoring of LCDC dma
addresses that were just recently updated.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm
We need to use complete_all() to indicate completed palette loading in
stead of plain complete() if we want to test if the palette has
already been loaded with completion_done().
indicated with.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertio
The palette loading does not work reliably without LCDC SW reset
before it. The AM335x TRM suggests this [1] after L3 clock domain has
been shut down. We have no knowledge of such events so we do it
always. The software reset will clear all the frame information in the
FIFO. Upon a restart, the L3
Add timeout wait for palette load-ind to complete. We do not want to
hang forever if palette loaded interrupt does not arrive for some
reason.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/d
The LCDC revision 2 documentation also mentions the mandatory palette
for true color modes. Even if the rev 2 LCDC appears to work just fine
without the palette being loaded loading it helps in testing the
feature.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 85 +
Set LCDC_PALETTE_LOAD_MODE bit-field with new tilcdc_write_mask()
instead of tilcdc_set(). Setting a bit-fields with tilcdc_set() is
fundamentally broken.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dri
Add tilcdc_write_mask() for handling register field wider than one bit
and mask values for those fields.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
b/drivers/gpu/drm/t
Failed tilcdc_crtc_create() error handling was broken, this patch
should fix it.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 12 +++-
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 11 ---
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 +-
3 files changed, 12 insertio
From: Bartosz Golaszewski
Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).
Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.
Signed-off-by: Bartos
Revision 1 LCDC support also sync lost errors and can benefit from
sync lost recovery routine.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 33 +
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 1 +
2 files changed, 18 insertions(+), 16 deletions(-
The git branch bellow is updated.
Changes since v2:
- Add: "drm/tilcdc: Fix load mode bit-field setting in tilcdc_crtc_enable()"
- Drop: "drm/tilcdc: Free palette dma memory in tilcdc_crtc_destroy()"
- Add: "drm/tilcdc: Add timeout wait for palette loading to complete"
- Add: "drm/tilcdc: Call res
On Tue, Nov 22, 2016 at 04:41:06PM +, Liviu Dudau wrote:
> drm_get_format_name() de-references the buf parameter without checking
> if the pointer was not NULL. Given that the function is EXPORT-ed, lets
> sanitise the parameters before proceeding.
>
> Fixes: b3c11ac267d461d3d5 ("drm: move all
On Tue, Nov 22, 2016 at 12:23:59PM -0500, Rob Clark wrote:
> On Tue, Nov 22, 2016 at 11:50 AM, Ville Syrjälä
> wrote:
> > On Tue, Nov 22, 2016 at 04:41:06PM +, Liviu Dudau wrote:
> >> drm_get_format_name() de-references the buf parameter without checking
> >> if the pointer was not NULL. Giv
On Tue, Nov 22, 2016 at 01:15:08PM -0500, Sean Paul wrote:
> On Tue, Nov 22, 2016 at 1:06 PM, Ville Syrjälä
> wrote:
> > On Tue, Nov 22, 2016 at 12:35:53PM -0500, Rob Clark wrote:
> >> On Tue, Nov 22, 2016 at 12:31 PM, Ville Syrjälä
> >> wrote:
> >> > On Tue, Nov 22, 2016 at 12:23:59PM -0500,
Am Freitag, den 11.11.2016, 17:57 +0100 schrieb Wladimir J. van der
Laan:
> Vivante GPUs with HALTI0 feature support a DRAW_INSTANCED command in the
> command stream to draw a number of instances of the same geometry.
>
> The information that has been figured out about the command can be found
> h
On Tuesday 22 November 2016 04:36 PM, Sudeep Holla wrote:
>
>
> On 22/11/16 10:57, Bartosz Golaszewski wrote:
>> 2016-11-22 11:53 GMT+01:00 Sudeep Holla :
>>>
>>>
>>> On 22/11/16 10:41, Bartosz Golaszewski wrote:
Add a function allowing to retrieve the compatible string of the root
From: Michel Dänzer
Fixes the vblank interrupt being disabled when it should be on, which
can cause at least the following symptoms:
* Hangs when running 'xset dpms force off' in a GNOME session with
gnome-shell using DRI2.
* RandR 1.4 slave outputs freezing with garbage displayed using
xf8
This is RFC patch for adding a connector link-status property
and making it atomic by adding it to the drm_connector_state.
This is to make sure its wired properly in drm_atomic_connector_set_property
and drm_atomic_connector_get_property functions.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Sy
On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> > > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 18, 2016 at 09:4
Adds drm bride support for attaching drm bridge drivers to tilcdc. The
decision whether a video port leads to an external encoder or bridge
is made simply based on remote device's compatible string. The code
has been tested with BeagleBone-Black with and without BeagleBone
DVI-D Cape Rev A3 using t
Add very basic ti-tfp410 DVI transmitter driver. The only feature
separating this from a completely dummy bridge is the EDID read
support trough DDC I2C. Even that functionality should be in a
separate generic connector driver. However, because of missing DRM
infrastructure support the connector is
Move "ti,tfp410.txt" from display/ti to display/bridge before adding
generic (non omapdrm/dss specific) implementation and new features.
Signed-off-by: Jyri Sarha
---
.../bindings/display/bridge/ti,tfp410.txt | 41 ++
.../devicetree/bindings/display/ti/ti,tfp410.txt
Recover from sync lost error flood by resetting the LCDC instead of
turning off the SYNC_LOST error IRQ. When LCDC starves on limited
memory bandwidth it may sometimes result an error situation when the
picture may have shifted couple of pixels to right and SYNC_LOST
interrupt is generated on every
Changes since v3:
- "drm/tilcdc: Enable sync lost error and recovery handling for rev 1 LCDC"
- Fix broken irq enable/disble code for LCDC rev 1
- Add: "dt-bindings: Move "ti,tfp410.txt" from display/ti to display/bridge"
- "drm/bridge: Add ti-tfp410 DVI transmitter driver"
- Don't fail if eith
edded Linux and Kernel engineering
http://free-electrons.com
-- 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/20161122/a28ed215/attachment.sig>
On Tue, Nov 22, 2016 at 1:47 PM, Liviu Dudau wrote:
> On Tue, Nov 22, 2016 at 01:15:08PM -0500, Sean Paul wrote:
>> On Tue, Nov 22, 2016 at 1:06 PM, Ville Syrjälä
>> wrote:
>> > On Tue, Nov 22, 2016 at 12:35:53PM -0500, Rob Clark wrote:
>> >> On Tue, Nov 22, 2016 at 12:31 PM, Ville Syrjälä
>>
drm_get_format_name() de-references the buf parameter without checking
if the pointer was not NULL. Given that the function is EXPORT-ed, lets
sanitise the parameters before proceeding.
Fixes: b3c11ac267d461d3d5 ("drm: move allocation out of drm_get_format_name())
Cc: Eric Engestrom
Cc: Rob Clark
On Tue, Nov 22, 2016 at 03:34:19PM +0100, Arnd Bergmann wrote:
> We now pass the device to the debug messages, but on non-x86,
> this is an invalid pointer in vga_arb_device_init:
>
> drivers/gpu/vga/vgaarb.c: In function 'vga_arb_device_init':
> drivers/gpu/vga/vgaarb.c:1467:4: error: 'dev' may b
he display engine by default would be better?
> At least simplefb still works.
Yep, that works for me.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- 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/20161122/65608cd9/attachment.sig>
On Tue, Nov 22, 2016 at 02:09:08PM +, Robert Bragg wrote:
> On Tue, Nov 22, 2016 at 1:34 PM, Daniel Vetter wrote:
>
> > On Tue, Nov 08, 2016 at 12:51:48PM +, Robert Bragg wrote:
> > > This v2 patch bumps the command parser version so it can be referenced in
> > > corresponding i-g-t gem_e
On Tue, Nov 22, 2016 at 02:02:38PM +, Robert Bragg wrote:
> On Tue, Nov 22, 2016 at 1:31 PM, Daniel Vetter wrote:
>
> > On Tue, Nov 22, 2016 at 02:29:18PM +0100, Daniel Vetter wrote:
> > > On Wed, Nov 09, 2016 at 08:00:06PM +, Matthew Auld wrote:
> > > > On 7 November 2016 at 19:49, Rober
On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
> controller drivers to da850.dtsi.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> v1 -> v2:
> - moved the priority controller node above the cfgchip node
> - renamed added nodes to
pose the vram range as a
> very special numa node that happens to be far away and not hold any
> cpu cores.
> -Daniel
One additional item to consider: it is not only "plain" numa case where
we could have different performance for access but also possibility that
we will not have access at all (or write only access) particular if PCIe
devices belong to different root complex. I must admit that I do not know
how to detect reliably such cases in the kernel.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/ebe9550a/attachment-0001.html>
From: Ville Syrjälä
drm_framebuffer_init() will start to check that fb->dev is already
populated, so let's do that manually since vmwgfx isn't using
drm_helper_mode_fill_fb_struct().
v2: s/to/do/ (Sinclair)
Cc: linux-graphics-maintainer at vmware.com
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Si
From: Guenter Roeck
If the driver is in suspended mode, the dp block may be disabled, and
chip registers may not be accessible. Yet, the worker may be triggered
in this situation by an extcon event. If that happens, the following crash
will be seen.
cdn-dp fec0.dp: [drm:cdn_dp_pd_event_work]
From: Guenter Roeck
If no monitor is connected, suspend/resume cycles result in firmware
load errors because the driver attempts to load the firmware while
the system is in suspend state. This results in a kernel warning and
traceback.
Loading the firmware during boot fixes the problem. Note tha
From: Chris Zhong
Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware f
This series adds support for the CDN DP controller to the rockchip drm
driver. This version of includes the version we merged into the
chromium.org repo plus ~15 fixes squashed on top. Notable fixes include:
- Fixed races between hotplug/extcon worker and modeset
- Greater support f
On Mon, Nov 21, 2016 at 11:51:21AM +, Liviu Dudau wrote:
> On Fri, Nov 18, 2016 at 09:52:45PM +0200, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > Add a local 'fb' variable to a few places to get rid of the
> > 'crtc->primary->fb' stuff. Looks neater and helps m
Hi Sekhar,
On 22/11/16 15:06, Sekhar Nori wrote:
> Hi Sudeep,
>
> On Tuesday 22 November 2016 04:23 PM, Sudeep Holla wrote:
>>
>>
>> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>> Add a function allowing to retrieve the compatible string of the root
>>> node of the device tree.
>>>
>>
>> Rob ha
From: Ville Syrjälä
Allow drivers to return a custom drm_format_info structure for special
fb layouts. We'll use this for the compression control surface in i915.
v2: Fix drm_get_format_info() kernel doc (Laurent)
Don't pass 'dev' to the new hook (Laurent)
Cc: Laurent Pinchart
Cc: Ben Wi
On 2016-11-22 03:10 PM, Daniel Vetter wrote:
> On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams
> wrote:
>> On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch
>> wrote:
>>> I personally like "device-DAX" idea but my concerns are:
>>>
>>> - How well it will co-exists with the DRM infrastructu
We now pass the device to the debug messages, but on non-x86,
this is an invalid pointer in vga_arb_device_init:
drivers/gpu/vga/vgaarb.c: In function 'vga_arb_device_init':
drivers/gpu/vga/vgaarb.c:1467:4: error: 'dev' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
Thi
Hi Thierry,
On Tuesday 22 Nov 2016 12:02:41 Thierry Reding wrote:
> On Sat, Nov 19, 2016 at 05:28:02AM +0200, Laurent Pinchart wrote:
> > LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> > Multiple incompatible data link layers have been used over time to
> > transmit image
Hi Thierry,
On Tuesday 22 Nov 2016 12:14:57 Thierry Reding wrote:
> On Sat, Nov 19, 2016 at 05:28:06AM +0200, Laurent Pinchart wrote:
> > This driver supports LVDS panels that don't require device-specific
> > handling of power supplies or control signals. It implements automatic
> > backlight han
Hi Thierry,
On Tuesday 22 Nov 2016 12:05:48 Thierry Reding wrote:
> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
> > Document properties common to several display panels in a central
> > location that can be referenced by the panel device tree bindings.
> >
> > Signed-off-by:
On Tue, Nov 22, 2016 at 5:05 AM, Thierry Reding
wrote:
> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
>> Document properties common to several display panels in a central
>> location that can be referenced by the panel device tree bindings.
>>
>> Signed-off-by: Laurent Pinchar
On Tue, Nov 22, 2016 at 03:48:50PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 21, 2016 at 11:51:21AM +, Liviu Dudau wrote:
> > On Fri, Nov 18, 2016 at 09:52:45PM +0200, ville.syrjala at linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Add a local 'fb' variable to a few pla
On Tue, Nov 22, 2016 at 01:50:53PM +, Brian Starkey wrote:
> On Tue, Nov 22, 2016 at 02:12:59PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
> > > On Tue, Nov 22, 2016 at 12:10:52PM +, Chris Wilson wrote:
> > > > On Tue, Nov 22, 2016 at 11:5
Hi Dave,
No critial patch but it make sure to unmap the region
if HDMI probing failed, and it includes two trivial fixups.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit c2ee69d83b2b14d68ad7ee1773fc1d40e97f201d:
Merge tag 'drm-
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/2e401b09/attachment-0001.sig>
On Mon, Nov 07, 2016 at 07:49:57PM +, Robert Bragg wrote:
> In particular this tries to capture for posterity some of the early
> challenges we had with using the core perf infrastructure in case we
> ever want to revisit adapting perf for device metrics.
>
> Cc: Chris Wilson
> Signed-off-by:
On Tue, Nov 08, 2016 at 12:51:48PM +, Robert Bragg wrote:
> This v2 patch bumps the command parser version so it can be referenced in
> corresponding i-g-t gem_exec_parse changes.
>
> --- >8 ---
Scissors cut everything below, not everything above, hence next time
around pls switch around your
On Tue, Nov 22, 2016 at 02:29:18PM +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 08:00:06PM +, Matthew Auld wrote:
> > On 7 November 2016 at 19:49, Robert Bragg wrote:
> > > Adds base i915 perf infrastructure for Gen performance metrics.
> > >
> > > This adds a DRM_IOCTL_I915_PERF_OPEN
On Wed, Nov 09, 2016 at 08:00:06PM +, Matthew Auld wrote:
> On 7 November 2016 at 19:49, Robert Bragg wrote:
> > 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
On 21 November 2016 at 19:55, Alex Deucher wrote:
> On Sun, Nov 20, 2016 at 1:25 PM, Grazvydas Ignotas
> wrote:
>> Just some trivial boring typo fixes all over the tree.
>> READMEs and comments only.
>>
>> Signed-off-by: Grazvydas Ignotas
>
> Reviewed-by: Alex Deucher
>
Thanks gents. Just push
On 16 November 2016 at 11:14, Nicolai Hähnle wrote:
> On 10.11.2016 18:43, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> The original version considered only card devices, while this will pick
>> the device/node name regardless - card, control, renderD, other...
>>
>> Current implementation
Hi David,
A late issue discovered by Russell King while testing his setup on Juno.
I would be really happy if it goes into v4.9-rc7 as it fixes a reference
counting problem with the pixelclock clock, but if it is too late for that
then I guess it can go into drm-next.
The following changes since
On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
> On Tue, Nov 22, 2016 at 12:10:52PM +, Chris Wilson wrote:
> > On Tue, Nov 22, 2016 at 11:54:57AM +, Brian Starkey wrote:
> > > On Tue, Nov 22, 2016 at 11:06:00AM +, Chris Wilson wrote:
> > > >On Tue, Nov 22, 2016 at 10:53:
if (cmd >= batch_end) {
> > DRM_DEBUG_DRIVER("CMD: Got to the end of the buffer w/o a
> BBE cmd!\n");
> > ret = -EINVAL;
> > @@ -1336,6 +1302,8 @@ int i915_cmd_parser_get_version(struct
> drm_i915_private *dev_priv)
> >* 8. Don't report cmd_check() failures as EINVAL errors to
> userspace;
> >*rely on the HW to NOOP disallowed commands as it would
> without
> >*the parser enabled.
> > + * 9. Don't whitelist or handle oacontrol specially, as ownership
> > + *for oacontrol state is moving to i915-perf.
> >*/
> > - return 8;
> > + return 9;
> > }
> > --
> > 2.10.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/c29c546c/attachment.html>
On Tue, Nov 22, 2016 at 02:56:49PM +0100, Daniel Vetter wrote:
>On Tue, Nov 22, 2016 at 01:50:53PM +, Brian Starkey wrote:
>> On Tue, Nov 22, 2016 at 02:12:59PM +0100, Daniel Vetter wrote:
>> > On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
>> > > On Tue, Nov 22, 2016 at 12:10:5
to be fixed, too.
>
> Another nitpick for the future: Enabling new features first and then
> fixing up the fallout is the wrong way round, if someone bisects over this
> range mesa might blow up in really bad ways.
>
> Oh well, this has been out there for way too long, so meh.
>
Fwiw I'm aware of this, and think I've ordered the patches correctly to
avoid bisect problems in Mesa / userspace. This infrastructure patch should
have no fallout to fix for userspace. The command parser changes that
affect userspace were done before adding oacontrol usage to i915-perf and
the cmd parser's EINVAL reporting for access failures was changed *before*
removing oacontrol from the whitelist.
Did I overlook something in particular?
- Robert
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/a04d5653/attachment.html>
t this is done via an interface separate
> from the existing gpu and storage device. For example it would require
> a /dev/dax instance alongside a /dev/nvme interface, but I don't see
> that as a significant blocking concern.
>
> [1]: https://lists.01.org/pipermail/linux-nvdimm/2016-October/007496.html
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/4e8561c9/attachment.html>
In order to avoid a section mismatch use a locally implemented routine
instead of of_flat_dt_get_machine_name() when printing the error
message.
Signed-off-by: Bartosz Golaszewski
---
drivers/memory/da8xx-ddrctl.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
dif
In order to avoid a section mismatch use a locally implemented routine
instead of of_flat_dt_get_machine_name() when printing the error
message.
Signed-off-by: Bartosz Golaszewski
---
drivers/bus/da8xx-mstpri.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff -
Sekhar noticed there's a section mismatch in the da8xx-mstpri and
da8xx-ddrctl drivers. This is caused by calling
of_flat_dt_get_machine_name() which has an __init annotation.
This series addresses this issue by open coding routines that return
the machine compatible string in both drivers. Once a
On Tue, Nov 22, 2016 at 02:12:59PM +0100, Daniel Vetter wrote:
>On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
>> On Tue, Nov 22, 2016 at 12:10:52PM +, Chris Wilson wrote:
>> > On Tue, Nov 22, 2016 at 11:54:57AM +, Brian Starkey wrote:
>> > > On Tue, Nov 22, 2016 at 11:06:00
The intel_dp_autotest_video_pattern() function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color v
Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
include/drm/drm_dp_helper.h | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
From: Jim Bride
For DP compliance we need to be able to control the output color
type for the pipe associated with the DP port. When a specific DP
compliance test is requested with specific BPC value, we read the BPC
value from the DPCD register and store it in the intel_dp structure.
If this BPC
This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte
Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
1 - 100 of 176 matches
Mail list logo