Hi all,
I have replaced the distro kernel on openSUSE 11.3 with custom compiled
2.6.37-rc3 and now all glx application are crashing with these kind of kernel
errors:
[ 312.028728] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0
10476800 385024 too big
[ 312.028732] radeon
Hi all,
On a AMD G-T56N (Radeon HD 6310) box connected to the monitor via DisplayPort
monitor does not come on after re-plugging the display cable but claims to be
in power save.
At the same time, according to xrandr it is connected and displaying.
Stopping Xorg and monitor comes back up
There is a more recent APU stepping with a new PCI ID
shipping in the same board by Fujitsu which needs the
same quirk to correctly mark the back plane connectors.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk
---
radeon_atombios.c |2 +-
1 file changed, 1 insertion(+), 1
gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
Looks OK to me. We could bikeshed it to only use swiotlb_max_segment()
which I think was the intention when that API was added but can leave
that for the future.
Reviewed-by: Tvrtko Ursulin <tvrtko.u
the request (signaled via -EIO in
> SYNC_IOC_FILE_INFO).
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/
On 03/01/2017 11:46, Chris Wilson wrote:
> On Tue, Jan 03, 2017 at 11:34:45AM +0000, Tvrtko Ursulin wrote:
>>
>> On 03/01/2017 11:05, Chris Wilson wrote:
>>> The struct dma_fence carries a status field exposed to userspace by
>>> sync_file. This is inspected af
On 03/01/2017 12:13, Chris Wilson wrote:
> On Tue, Jan 03, 2017 at 11:57:44AM +0000, Tvrtko Ursulin wrote:
>>
>> On 03/01/2017 11:46, Chris Wilson wrote:
>>> On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
>>>>
>>>> On 03/01/
On 03/01/2017 12:38, Chris Wilson wrote:
> On Tue, Jan 03, 2017 at 12:34:16PM +0000, Tvrtko Ursulin wrote:
>>
>> On 03/01/2017 12:13, Chris Wilson wrote:
>>> On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
>>>>
>>>> On 03/01/2017
0UL;
> + fence->status = 0;
>
> trace_dma_fence_init(fence);
> }
>
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
On 04/01/2017 18:42, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS) which
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Purpose is to enable drivers to print out just the mode
string with their own formatting.
Existing drm_mode_debug_printmodeline calls the new
helper and the format is unchanged in this patch.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vett
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Instead of a long string full of zeros in various forms
print out "---" for more tidy appearace in the logs.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Debug logging in this function does not provide any information
apart that the userspace is calling an ioctl on the connector.
There is not any info on the connector provided at all and
since there are other ioctls userspace typically calls
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
The debug logging here can be very verbose in the kernel logs
and provides no information which userspace doesn't have the
access to already. Turn it off so kernel logs become more
manageable.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vett
On 27/04/16 13:35, Jani Nikula wrote:
> On Wed, 27 Apr 2016, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin
>>
>> Purpose is to enable drivers to print out just the mode
>> string with their own formatting.
>
> Some alternatives that preserve the use of a si
Hi Dave, Daniel,
We had this i915 series with a single DRM core patch (reviewed) ready
for a while - just waiting for an ack to merge it via i915 trees.
Can we proceed with merging it?
Regards,
Tvrtko
On 18/08/16 18:17, Dave Gordon wrote:
> We had only DRM_INFO() and DRM_ERROR(), whereas
Hi,
On 18/11/2016 19:53, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> By providing our own format information for the CCS formats, we should
> be able to make framebuffer_check() do the right thing for the CCS
> surface as well.
>
> Note that we'll return the same format
On 21/11/2016 13:27, Ville Syrjälä wrote:
> On Mon, Nov 21, 2016 at 08:42:13AM +0000, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 18/11/2016 19:53, ville.syrjala at linux.intel.com wrote:
>>> From: Ville Syrjälä
>>>
>>> By providing our
On 29/11/2016 08:56, Daniel Vetter wrote:
> On Mon, Nov 28, 2016 at 06:43:19PM -0500, Jérémy Lefaure wrote:
>> Two warnings are produced by gcc (tested with gcc 6.2.1):
>>
>> drivers/gpu/drm/i915/intel_csr.c: In function âcsr_load_work_fnâ:
>> drivers/gpu/drm/i915/intel_csr.c:400:5: error:
Hi Dan,
On 28/01/16 22:30, Dan Carpenter wrote:
> Hello Tvrtko Ursulin,
>
> The patch de1add360522: "drm/i915: Decouple execbuf uAPI from
> internal implementation" from Jan 15, 2016, leads to the following
> static checker warning:
>
> drivers/gpu/drm/
On 11/07/16 19:01, Dave Gordon wrote:
> We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
> provides several other useful intermediate levels such as NOTICE and
> WARNING. So this patch fills out the set by providing both regular and
> once-only macros for each of the
On 11/07/16 19:01, Dave Gordon wrote:
> Where we're going to continue regardless of the problem, rather than
> fail, then the message should be a WARNing rather than an ERROR.
>
> Signed-off-by: Dave Gordon
> ---
> drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
> 1 file
On 11/07/16 19:01, Dave Gordon wrote:
> Some downgraded from DRM_ERROR() to DRM_WARN(), some eliminated,
> and a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN().
>
> Signed-off-by: Dave Gordon
> ---
> drivers/gpu/drm/i915/intel_guc_loader.c | 20 ++--
> 1 file
On 12/07/16 10:27, Chris Wilson wrote:
> On Tue, Jul 12, 2016 at 10:20:43AM +0100, Tvrtko Ursulin wrote:
>> On 11/07/16 19:01, Dave Gordon wrote:
>>> @@ -553,8 +551,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
>>> if (db_ret.db_stat
On 12/07/16 14:28, Dave Gordon wrote:
> On 12/07/16 10:06, Tvrtko Ursulin wrote:
>>
>> On 11/07/16 19:01, Dave Gordon wrote:
>>> We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
>>> provides several other useful intermediate levels s
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Define DRM_NAME to i915 so that the log messages we output change from:
[drm] RC6 on
to:
[i915] RC6 on
Since I wasn't around in the beginning of DRM I wonder whether that
was the intended purpose of DRM_NAME or if it was something else.
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Driver prefix is a bit redundant in debug messages. If we choose
not to log it we change debug messages which used to look like this:
[i915:edp_panel_off [i915]] Wait for panel power off time
to this:
[edp_panel_off [i915]] Wait for panel
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Same as the previous patch did for drm_printk, allow for the
logging macros to pass in the driver set DRM_NAME.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_drv.c | 14 +++---
drivers/gpu/drm/i915/i915_drv.
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Instead of logging with the DRM core name, pass in the name explicitly
in order to allow individual drivers to have all their log messages
prefixed with their own name.
For instance i915, instead of:
[drm:edp_panel_off [i915]] Wait for
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
I wasn't here at the beginnings of DRM so I might have gotten this wrong,
however the existance of DRM_NAME suggested to me that the intention was to
allow individual drivers to override it and get appropriate prefixes in their
log messag
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Eliminate _DRM_PRINTK macro and use drm_printk for all log levels.
This required drm_printk to vary the verbosity level of the logged
metadata depending on the log level.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_drv.
Hi,
On 06/12/2016 19:49, Gustavo Padovan wrote:
> Hi Tvrtko,
>
> 2016-12-06 Tvrtko Ursulin :
>
>> From: Tvrtko Ursulin
>>
>> Driver prefix is a bit redundant in debug messages. If we choose
>> not to log it we change debug messages which used to look like th
nges summarised in v2: section below)
>
> In particular, affecting the output format, I stole an idea from Tvrtko
> Ursulin to have the prefix for messages be based on the driver name,
> such as "[i915]" instead of always being "[drm]".
>
> Depending on peoples th
On 15/12/2016 20:54, Chris Wilson wrote:
> On Thu, Dec 15, 2016 at 11:44:13PM +0300, Dan Carpenter wrote:
>> Hello Tvrtko Ursulin,
>>
>> The patch a19d6ff29a82: "drm/i915: Small compaction of the engine
>> init code" from Jun 23, 2016, leads to th
On 16/12/2016 08:02, Tvrtko Ursulin wrote:
>
> On 15/12/2016 20:54, Chris Wilson wrote:
>> On Thu, Dec 15, 2016 at 11:44:13PM +0300, Dan Carpenter wrote:
>>> Hello Tvrtko Ursulin,
>>>
>>> The patch a19d6ff29a82: "drm/i915: Small compaction of the en
On 29/02/16 11:13, Dave Gordon wrote:
> After the recent addition of drm_malloc_gfp(), it was noticed that
> some callers of these functions has swapped the parameters in the
> call - it's supposed to be 'number of members' and 'sizeof(element)',
> but a few callers had got the size first and the
Tested-by: Thomas Hellstrom #v3
Can't be 100% since apparently eDP regressed a lot recently for me, but
seems to be effective in getting rid of stale planes in my test cases.
Tested-by: Tvrtko Ursulin
Regards,
Tvrtko
> ---
> drivers/gpu/drm/drm_crtc.c | 63
> +
Hi,
On 04/05/16 13:10, Maarten Lankhorst wrote:
> Add some tests to BAT to ensure rmfb/lastclose handling doesn't break again.
>
> The test will set framebuffers on each crtc, and then try rmfb or close.
> Afterwards it rechecks to make sure the framebuffers are removed.
>
> Signed-off-by:
UILD_BUG_ON_MSG(); avoided renaming functions
> by shadowing them with #defines and then calling the function
> (non-recursively!) from inside the #define [Chris Wilson]
>
> Signed-off-by: Dave Gordon
> Cc: Chris Wilson
> Cc: Ville Syrjälä Cc: dri-
> Cc: dri-devel at lists.freede
Reviewed-by: Tvrtko Ursulin
On 09/17/2014 01:37 PM, Damien Lespiau wrote:
> When handling the error on GEM_CLOSE, we weren't freeing the allocated
> page. Plug that.
>
> Signed-off-by: Damien Lespiau
> ---
> intel/intel_bufmgr_gem.c | 5 ++---
> 1 file changed, 2 inser
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Sync up with new kernel features as per commits:
e3eb3250d84ef97b766312345774367b6a310db8
93b81f5102a7cd270a305c2741b17c8d44bb0629
b5ff6e1637b683d5996ae11ac29afe406c0bee90
8c4f83fb1e8bf317e894f62d17a63c32b7
Hi,
On 07/12/15 19:25, Andy Lutomirski wrote:
> [53834.386369] traps: gnome-session-b[2308] general protection
> ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in
> libc-2.22.so[7f10efba1000+1b7000]
> [53834.687584] [ cut here ]
> [53834.687607] WARNING: CPU: 0 PID: 23730 at
>
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
On 02/02/2015 09:58 AM, Daniel Vetter wrote:
> On Mon, Feb 02, 2015 at 10:41:24AM +0100, Daniel Vetter wrote:
>> On Fri, Jan 30, 2015 at 05:36:54PM +0000, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin
>>>
>>> To be used from the new addfb2 extension.
&
On 02/02/2015 04:32 PM, Rob Clark wrote:
> On Mon, Feb 2, 2015 at 4:41 AM, Daniel Vetter wrote:
>> On Fri, Jan 30, 2015 at 05:36:54PM +0000, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin
>>>
>>> To be used from the new addfb2 extension.
&
ate when checking them against the
>> new framebuffer during page flip.
>>
>> Cc: Matt Roper
>> Cc: Tvrtko Ursulin
>> Cc: Daniel Vetter
>> Signed-off-by: Ville Syrjälä
>
> For the series:
>
> Reviewed-by: Matt Roper
>
> I also confirmed tha
On 08/03/2015 10:48 AM, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Sync up with new kernel features as per commits:
>
> e3eb3250d84ef97b766312345774367b6a310db8
> 93b81f5102a7cd270a305c2741b17c8d44bb0629
> b5ff6e1637b683d5996ae11ac29afe406c0bee90
> 8c4f83fb1e8bf317
Hi,
On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:
> Previously RMFB and fd close chose to disable any plane that had
> an active framebuffer from this file. If it was a primary plane the
> crtc was disabled. However the fbdev code or any system compositor
> should restore the planes anyway so
On 09/09/2015 04:56 PM, Daniel Vetter wrote:
> On Wed, Sep 09, 2015 at 04:47:08PM +0100, Tvrtko Ursulin wrote:
>>
>> On 09/09/2015 04:29 PM, Daniel Vetter wrote:
>>> On Wed, Sep 09, 2015 at 04:18:02PM +0100, Tvrtko Ursulin wrote:
>>>>
>>>> On 09/09/
On 09/09/2015 05:07 PM, Daniel Vetter wrote:
> On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin
> wrote:
>> It was just an example of a class of vulnerabilities which would be possible
>> with these changes. If they, as you said, will preserve the last frame on
>> sc
On 09/09/2015 05:26 PM, Maarten Lankhorst wrote:
> Op 09-09-15 om 18:15 schreef Tvrtko Ursulin:
>>
>> On 09/09/2015 05:07 PM, Daniel Vetter wrote:
>>> On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin
>>> wrote:
>>>> It was just an example of a class of
On 09/09/2015 04:04 PM, Daniel Vetter wrote:
> On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 09/09/2015 03:40 PM, Maarten Lankhorst wrote:
>>> Previously RMFB and fd close chose to disable any plane that had
>
On 09/09/2015 04:29 PM, Daniel Vetter wrote:
> On Wed, Sep 09, 2015 at 04:18:02PM +0100, Tvrtko Ursulin wrote:
>>
>> On 09/09/2015 04:04 PM, Daniel Vetter wrote:
>>> On Wed, Sep 09, 2015 at 03:51:50PM +0100, Tvrtko Ursulin wrote:
>>>>
>>>> Hi,
>
On 09/09/2015 08:06 PM, Daniel Vetter wrote:
> On Wed, Sep 9, 2015 at 6:36 PM, Tvrtko Ursulin
> wrote:
>> I am not even going that far, just talking about last frame stuck on screen.
>> For me making that easier is a regression.
>
> So let's look at various systems:
>
On 09/10/2015 10:56 AM, Daniel Vetter wrote:
> On Thu, Sep 10, 2015 at 10:07:41AM +0100, Tvrtko Ursulin wrote:
>>
>> On 09/09/2015 08:06 PM, Daniel Vetter wrote:
>>> On Wed, Sep 9, 2015 at 6:36 PM, Tvrtko Ursulin
>>> wrote:
>>>> I am not even going
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Use cases like rotation require these hooks to have some context so they
know how to prepare and cleanup the frame buffer correctly.
For i915 specifically, object backing pages need to be mapped differently
for different rotation
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Use cases like rotation require these hooks to have some context so they
know how to prepare and cleanup the frame buffer correctly.
For i915 specifically, object backing pages need to be mapped differently
for different rotation
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
__u64 should be used instead of u64.
Feature originally added in:
commit e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark
Date: Thu Feb 5 14:41:52 2015 +
drm: add support for tiled/compressed/etc modifier in addfb2
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
__u64 should be used instead of u64.
Kernel headers originally pulled in:
commit 8983fe5497e89a3ffaba3ad1ee06a30a1c7e6daf
Author: Tvrtko Ursulin
Date: Mon Aug 3 10:48:03 2015 +0100
libdrm: Add framebuffer modifiers uapi
Sign
On 09/22/2015 03:53 PM, David Herrmann wrote:
> Hi
>
> On Thu, Sep 10, 2015 at 12:15 PM, Tvrtko Ursulin
> wrote:
>> On 09/10/2015 10:56 AM, Daniel Vetter wrote:
>>> That's not different from the compositor just freezing instead of
>>> crashing: Screen conten
On 05/04/16 14:05, Chris Wilson wrote:
> On Tue, Apr 05, 2016 at 01:57:36PM +0100, Chris Wilson wrote:
>> I have instances where I want to use drm_malloc_ab() but with a custom
>> gfp mask. And with those, where I want a temporary allocation, I want to
>> try a high-order kmalloc() before using a
> Author: Chris Wilson
> Date: Tue Apr 7 16:20:41 2015 +0100
>
> drm/i915: Optimistically spin for the request completion
>
> Reported-by: Jens Axboe
> Link: https://lkml.org/lkml/2015/11/12/621
> Cc: Jens Axboe
> Cc; "Rogozhkin, Dmitry V"
&g
a jiffie to react
to signals was the only problem then it is not too severe.
Add something to the commit message about how it was found/reported and
about the severity of impact, etc?
Otherwise,
Reviewed-by: Tvrtko Ursulin
> Fixes regression from
> commit 2def4ad99befa25775dd2f714fdd4d9
On 16/11/15 11:22, Chris Wilson wrote:
> On Mon, Nov 16, 2015 at 09:54:10AM +0000, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 15/11/15 13:32, Chris Wilson wrote:
>>> The busywait in __i915_spin_request() does not respect pending signals
>>> and so
On 16/11/15 11:12, Chris Wilson wrote:
> On Mon, Nov 16, 2015 at 10:24:45AM +0000, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 15/11/15 13:32, Chris Wilson wrote:
>>> When waiting for high frequency requests, the finite amount of time
>>> requi
On 16/11/15 12:55, Chris Wilson wrote:
> On Mon, Nov 16, 2015 at 12:08:08PM +0000, Tvrtko Ursulin wrote:
>>
>> On 16/11/15 11:12, Chris Wilson wrote:
>>> On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
>>>> On 15/11/15 13:32, Chris Wilson wro
Hi,
On 11/11/15 17:11, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> Drivers shouldn't clobber the passed in addfb ioctl parameters.
> i915 was doing just that. To prevent it from happening again,
> pass the struct around as const, starting all the way from
>
On 01/29/2015 11:30 AM, Daniel Vetter wrote:
> On Wed, Jan 28, 2015 at 05:57:56PM +0000, Tvrtko Ursulin wrote:
>>
>> On 01/28/2015 05:37 PM, Daniel Vetter wrote:
>>> From: Rob Clark
>>>
>>> In DRM/KMS we are lacking a good way to deal with tiled/compr
On 01/29/2015 11:57 AM, Daniel Vetter wrote:
> On Thu, Jan 29, 2015 at 11:43:07AM +0000, Tvrtko Ursulin wrote:
>>
>> On 01/29/2015 11:30 AM, Daniel Vetter wrote:
>>> On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:
>>>>
>>>> On 01/2
On 01/29/2015 05:01 PM, Daniel Vetter wrote:
[snip]
> +
> +/*
> + * Format Modifiers:
> + *
> + * Format modifiers describe, typically, a re-ordering or modification
> + * of the data in a plane of an FB. This can be used to express tiled/
> + * swizzled formats, or compression, or a
On 01/29/2015 05:01 PM, Daniel Vetter wrote:
> +#define fourcc_mod_code(vendor, val) \
> + u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val &
> 0x00ffL)
Unbalanced parentheses.
Finding them as I go along, sorry! :)
Regards,
Tvrtko
On 01/30/2015 01:43 PM, Rob Clark wrote:
> On Fri, Jan 30, 2015 at 5:51 AM, Tvrtko Ursulin
> wrote:
>>> +/*
>>> + * Format Modifier tokens:
>>> + *
>>> + * When adding a new token please document the layout with a code
>>> comment,
>
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Frame buffer modifiers extensions provided in;
commit e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark
Date: Thu Feb 5 14:41:52 2015 +
drm: add support for tiled/compressed/etc modifier in addfb2
Missed the str
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Frame buffer modifiers extensions provided in;
commit e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark
Date: Thu Feb 5 14:41:52 2015 +
drm: add support for tiled/compressed/etc modifier in addfb2
Missed the str
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Frame buffer modifiers extensions provided in;
commit e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark
Date: Thu Feb 5 14:41:52 2015 +
drm: add support for tiled/compressed/etc modifier in addfb2
Missed the str
On 02/09/2015 06:03 PM, Daniel Vetter wrote:
> From: Tvrtko Ursulin
>
> To be used from the new addfb2 extension.
>
> v2:
> - Drop Intel-specific untiled modfier.
> - Move to drm_fourcc.h.
> - Document layouts a bit and denote them as platform-specific and not
>
fb
> modifiers, yay!
>
> Cc: Tvrtko Ursulin
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 24 +++-
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Commit 1da30627fc511a57c9bd23a02c97f0576379f761 "drm: Add rotation value to
plane state" moved the rotation property to DRM core but only did the set
property part. This does the get property part as well.
Signed-off-by: Tvrtko U
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
So no need to have code which never gets called in the driver.
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
Reviewed-by: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_atomic_plane.
On 01/28/2015 05:37 PM, Daniel Vetter wrote:
> From: Rob Clark
>
> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> formats. Especially in the case of dmabuf/prime buffer sharing, where
> we cannot always rely on under-the-hood flags passed to driver specific
> gem-create
There is a more recent APU stepping with a new PCI ID
shipping in the same board by Fujitsu which needs the
same quirk to correctly mark the back plane connectors.
Signed-off-by: Tvrtko Ursulin
---
radeon_atombios.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi all,
I've been playing with some DisplayLink adapters, six of them to be precise
connected to six identical HDMI monitors.
Under kernel 3.5 things did not really work for me apparently because of the
udl driver's inability to fetch EDID. Interestingly, logged EDID blocks were
different for
Hi all,
On a AMD G-T56N (Radeon HD 6310) box connected to the monitor via DisplayPort
monitor does not come on after re-plugging the display cable but claims to be
in power save.
At the same time, according to xrandr it is connected and displaying.
Stopping Xorg and monitor comes back up
Hi all,
I have replaced the distro kernel on openSUSE 11.3 with custom compiled
2.6.37-rc3 and now all glx application are crashing with these kind of kernel
errors:
[ 312.028728] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0
10476800 385024 too big
[ 312.028732] radeon
ine[RCS] = mock_engine(i915, "mock");
if (!i915->engine[RCS])
- goto err_dependencies;
+ goto err_priorities;
i915->kernel_context = mock_context(i915, NULL);
if (!i915->kernel_context)
Reviewed-by: Tvrtko Ursulin <
Hi,
On 21/05/2017 05:03, Nick Desaulniers wrote:
This solves a warning when compiling the driver with Clang, -Werror enabled,
and CONFIG_DRM_I915_DEBUG_GEM unset, since Clang warns that:
drivers/gpu/drm/i915/i915_gem.c:3274:12: error: function
'wait_for_engine' is not needed
and will
struct intel_dpll_hw_state *dpll_hw_state)
+static bool
+cnl_ddi_dp_set_dpll_hw_state(int clock,
+struct intel_dpll_hw_state *dpll_hw_state)
{
uint32_t cfgcr0;
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@int
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
We have to reject unknown flags for uAPI considerations, and also
because the curent implementation limits their i915 storage space
to two bits.
v2: (Chris Wilson)
* Fix fail in ABI check.
* Added unknown flags and BUILD_BUG_ON.
v3:
On 04/12/2017 15:02, Lionel Landwerlin wrote:
Hi,
After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit to link the render node back to the card through a
symlink. Making it obvious from an application using a render node to
know where to get the information it
On 11/12/2017 10:50, Joonas Lahtinen wrote:
+ Daniel, Chris
On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:
On 04/12/2017 15:02, Lionel Landwerlin wrote:
Hi,
After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit to link the render node back to the
On 11/12/2017 21:05, Daniel Vetter wrote:
On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
On 11/12/2017 10:50, Joonas Lahtinen wrote:
+ Daniel, Chris
On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:
On 04/12/2017 15:02, Lionel Landwerlin wrote:
Hi,
After discussion
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
We have to reject unknown flags for uAPI considerations, and also
because the curent implementation limits their i915 storage space
to two bits.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Fixes: cf6e7bac6357 ("drm/
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
We have to reject unknown flags for uAPI considerations, and also
because the curent implementation limits their i915 storage space
to two bits.
v2: (Chris Wilson)
* Fix fail in ABI check.
* Added unknown flags and BUILD_BUG_ON.
Sign
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Since drm_printk is built inside the DRM core module, it will not respect
the potentially overriden by the driver DRM_LOG_NAME.
Make it tale the driver prefix and change it's wrappers so it is passed
in from the driver code. This makes the
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Same as the previous patch did for drm_printk, allow for the logging
macros to pass in the driver set DRM_LOG_NAME for drm_dev_printk.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Daniel Vetter <daniel.vet...@intel.c
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Define DRM_LOG_NAME to i915 so that the log messages we output change
from:
[drm] RC6 on
to:
[i915] RC6 on
Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/i9
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Same as the previous patch did for drm_printk, allow for the logging
macros to pass in the driver set DRM_LOG_NAME for drm_info_printer.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Daniel Vetter <daniel.vet..
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Instead of having DRM_NAME which is defined in the uAPI headers used for
kernel log prefix messages, introduct a new DRM_LOG_NAME define defined
privately in kernel space.
Leave the DRM_NAME around, but mark it as obsolete in case there i
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
dev_err will log the device in question and since there is a single caller
to drm_dev_init inside this driver, the drm prefix and the function name
can both also be safely dropped.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@inte
From: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
This series tries to solve a few issues in the current DRM logging code to
primarily make it clearer which messages belong to which driver.
Main problem is that currently some logging functions allow individual drivers
to override the log
1 - 100 of 2120 matches
Mail list logo
