drivers/gpu/drm/i915/intel_ringbuffer.c:435:1-4: WARNING: end returns can be
simpified
Simplify a trivial if-return sequence. Possibly combine with a
preceding function call.
Generated by: scripts/coccinelle/misc/simple_return.cocci
CC: Paulo Zanoni
Signed-off-by: Fengguang Wu
---
intel_r
here is no lockups.
--
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/20150305/2334e1f7/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150305/33c94e69/attachment-0001.html>
On Thu, Mar 05, 2015 at 10:41:19AM -0800, Ian Romanick wrote:
> On 03/05/2015 08:20 AM, Damien Lespiau wrote:
> > Time to switch over all the IS_GENX() macros to the new device object.
> > Nothing more than a mechanical search & replace here.
>
> Hmm... why not just do the comparisons directly? T
On Thu, Mar 5, 2015 at 3:54 AM, David Herrmann wrote:
> Hi
>
> Why pretend the hw supports cursors if it clearly does not? I don't
> see why we cannot leave this to user-space (which can apply
> optimizations for software-only devices, which the kernel cannot). And
> a commit-message would also be
On Thu, Mar 5, 2015 at 2:33 AM, Chris Wilson
wrote:
> On Wed, Mar 04, 2015 at 06:26:23PM -0800, Haixia Shi wrote:
>> This also limits the maximum frequency of page flips by the vrefresh rate.
>>
>> Signed-off-by: Haixia Shi
>> Reviewed-by: Stéphane Marchesin
>> Tested-by: Haixia Shi
>
> I thi
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150305/6dfc2204/attachment.html>
Ping, anyone up for review?
BR,
Jani.
On Tue, 24 Feb 2015, Jani Nikula wrote:
> Hi all, I was planning on adding some connector type specific stuff in
> the sysfs for DP, but ended up scrapping the plan midway through
> it. However I was left with some drm sysfs cleanup to make it easier;
> her
On Thu, Mar 05, 2015 at 07:07:30AM -0800, Matt Roper wrote:
> On Thu, Mar 05, 2015 at 11:01:08AM +0100, Daniel Vetter wrote:
> > We shouldn't tempt driver writers into using this since it uses a
> > default format list which is likely wrong. And when that's done we can
> > simplify the code a bit,
On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote:
> On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja
> wrote:
> >
> > On 02/23/2015 09:09 PM, Daniel Vetter wrote:
> >>
> >> On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote:
> >>>
> >>> On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter
On Thu, Mar 05, 2015 at 10:03:08PM +0800, kbuild test robot wrote:
> drivers/gpu/drm/i915/intel_ringbuffer.c:435:1-4: WARNING: end returns can be
> simpified
>
> Simplify a trivial if-return sequence. Possibly combine with a
> preceding function call.
> Generated by: scripts/coccinelle/misc/si
Finally, we can remove this file now that everything is using
drm_intel_device.
Signed-off-by: Damien Lespiau
---
intel/Makefile.sources | 1 -
intel/intel_bufmgr_gem.c | 1 -
intel/intel_chipset.h| 184 ---
intel/intel_decode.c | 1 -
We were pulling a few PCI ids, we can just hardcode them, it doesn't
change much.
Signed-off-by: Damien Lespiau
---
intel/test_decode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/intel/test_decode.c b/intel/test_decode.c
index 1ffd829..b9897b3 100644
--- a/intel/t
If, for some reason, we couldn't create the decode context, exit,
instead of segfaulting.
Signed-off-by: Damien Lespiau
---
intel/test_decode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/intel/test_decode.c b/intel/test_decode.c
index 93f47ef..1ffd829 100644
--- a/intel/test_decode
Time to switch over all the IS_GENX() macros to the new device object.
Nothing more than a mechanical search & replace here.
Signed-off-by: Damien Lespiau
---
intel/intel_bufmgr_gem.c | 7 +-
intel/intel_chipset.h | 158 --
intel/intel_decode.c
One more step towards getting rid of intel_chipset.h. The slightly
tricky bit here is that I don't want to leave defines like IS_CHIP() or
IS_GEN4() is a file that can potentially become a public header.
intel_device_priv.h was introduced then.
Signed-off-by: Damien Lespiau
---
intel/Makefile.so
Turns out nobody was using it, nor the underlying defines.
Signed-off-by: Damien Lespiau
---
intel/intel_chipset.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index a8a2b0e..241d700 100644
--- a/intel/intel_chipset.h
+++ b/int
IS_9XX() has grown to mean gen >= 3. It was only used in a single test:
(IS_9XX && !IS_GEN3)
Which has then be replaced with gen >= 4.
The code in that area was idented a bit weirdly, so do a pass on that as
well.
Signed-off-by: Damien Lespiau
---
intel/intel_chipset.h | 9 -
intel
While the bitwise operator should do the right thing here, it's probably
better to use the logical or here, at least to not cause a 'wtf' when
reading the code.
At the same time, get rid of unnecessary '()'.
Signed-off-by: Damien Lespiau
---
intel/intel_bufmgr_gem.c | 4 ++--
1 file changed, 2
Signed-off-by: Damien Lespiau
---
intel/intel_decode.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 7d5cbe5..9ada2fa 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -35,6 +35
Signed-off-by: Damien Lespiau
---
intel/intel_bufmgr_gem.c | 58 +++-
1 file changed, 8 insertions(+), 50 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 33d8fbc..72a6ab1 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/i
The intention here is to:
- have a single object that represents a device
- reuse the kernel i915_pciids.h file so we only one place to update
and copy the file over.
- hide the various information about an intel device in that object
instead of having endless #define in intel_chip
Signed-off-by: Damien Lespiau
---
intel/intel_chipset.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index e22a867..9a8df6a 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -181,16 +181,6 @@
#define PCI_CHIP_SKYLAKE
A couple of things I wanted to do for the longest time:
- Have (intel's) libdrm use the kernel i915_pciids.h so we can just copy the
file when updating
- Start a new object, struct drm_intel_device where we could put common code
across several userspace projects. For instance it could
On 02/23/2015 09:09 PM, Daniel Vetter wrote:
> On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote:
>> On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter wrote:
>>> On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote:
On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja
wrote:
>
The framebuffer var width and height should reflect the size of
framebuffer memory allocated, which is the entire surface size.
In case of dual DSI connectors with TILE properties, this change
makes the whole image show on the dual DSI panel, instead of
duplicated images on both sides.
Signed-off
The width and height in SSPP_SRC_IMG_SIZE register should be the
size of the entire source framebuffer, not the fetch size.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp
This change adds the registers in mdp5 ping pong blocks
and split display control registers.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 105
1 file changed, 105 insertions(+)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
b/driver
Pingpong register base addresses are different across platforms.
This change adds this information to config table and initialize
the values for 8x74 and 8084.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 8
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 1 +
2 files c
Pingpong registers are needed by dsi command mode operation
for tearing check.
Split display registers are needed by dual dsi broadcast mode
for synchronization.
Signed-off-by: Hai Li
---
rnndb/mdp/mdp5.xml | 48
1 file changed, 48 insertions(+)
On 4 March 2015 at 23:19, Rob Clark wrote:
> On Wed, Mar 4, 2015 at 6:10 PM, Emil Velikov
> wrote:
>> On 3 March 2015 at 20:04, Rob Clark wrote:
>>> Add a reserved-memory region for bootloader splashscreen, and assign it
>>> to the display device, so that drm/msm can take over the bootloader's
The main incentive to do this is to get I915_PARAM_REVISION.
---
include/drm/i915_drm.h | 48 ++--
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 15dd01d..afa110c 100644
--- a/include/
Hi Dave, two i915 fixes, both of them cc: stable.
BR,
Jani.
The following changes since commit 13a7a6ac0a11197edcd0f756a035f472b42cdf8b:
Linux 4.0-rc2 (2015-03-03 09:04:59 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-03-0
Hi
On Thu, Mar 5, 2015 at 3:26 AM, Haixia Shi wrote:
> Signed-off-by: Haixia Shi
> Reviewed-by: Stéphane Marchesin
> Tested-by: Haixia Shi
> ---
> drivers/gpu/drm/udl/Makefile | 2 +-
> drivers/gpu/drm/udl/udl_cursor.c | 156
> +
> drivers/gpu/d
There is one minor conflict when apply the KMD patch to latest
drm-intel-nightly branch. It should be easy to fix.
Another issue is that IMO, we should bump libdrm's version number
when increase these new APIs. Then in Beignet, we can check the
libdrm version at build time and determine whether we
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index a369c14..945d622 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b
Signed-off-by: Oded Gabbay
Reviewed-by: Ben Goz
---
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 5a44f2f..b7bd7af 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
fence_wait_timeout() is an exported kernel symbol, so we should rename our
local function to something different.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkf
https://bugzilla.kernel.org/show_bug.cgi?id=94331
Bug ID: 94331
Summary: Random panic with radeon
Product: Drivers
Version: 2.5
Kernel Version: 4.0.0-rc1-00151-ga38ecbb
Hardware: x86-64
OS: Linux
Tree: Mainlin
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150305/dfe958be/attachment.html>
Hey,
On 05-03-15 02:13, Jan Vesely wrote:
> please ignore this patch, see bugzilla for details.
Just in case, can you try the patches from
https://bugzilla.kernel.org/show_bug.cgi?id=90741 ?
~Maarten
On Thu, Mar 05, 2015 at 09:50:31AM +, Chris Wilson wrote:
> On Thu, Mar 05, 2015 at 09:45:41AM +, Chris Wilson wrote:
> > Since the beginning, sysfs/connector/status has done a heavyweight
> > detection of the current connector status. But no user, such as upowerd
> > or logind, has ever de
We shouldn't tempt driver writers into using this since it uses a
default format list which is likely wrong. And when that's done we can
simplify the code a bit, too.
Noticed while reviewing a patch from Laurent.
Cc: Laurent Pinchart
Cc: Matt Roper
Signed-off-by: Daniel Vetter
---
drivers/gpu
Based on light reading, patches 1, 5, 6, 7, 8, 10, and 11 are
Reviewed-by: Ian Romanick
I sent a comment on patch 9. I'll try to look at the others in the next
few days... assuming nobody beats me to it.
I'm also going to send some similar Mesa patches that I'll CC you on.
On 03/05/2015 08:20
On 03/05/2015 08:20 AM, Damien Lespiau wrote:
> Time to switch over all the IS_GENX() macros to the new device object.
> Nothing more than a mechanical search & replace here.
Hmm... why not just do the comparisons directly? The macros seem
superfluous.
> Signed-off-by: Damien Lespiau
> ---
> i
On Thu, Mar 05, 2015 at 02:25:44AM +0200, Laurent Pinchart wrote:
> Drivers implementing the universal planes API report the list of
> supported pixel formats for the primary plane. Make sure the fb passed
> to the setcrtc ioctl is compatible.
>
> Drivers not implementing the universal planes API
On Wed, Mar 04, 2015 at 06:26:23PM -0800, Haixia Shi wrote:
> This also limits the maximum frequency of page flips by the vrefresh rate.
>
> Signed-off-by: Haixia Shi
> Reviewed-by: Stéphane Marchesin
> Tested-by: Haixia Shi
I think the better approach would have been to push the task down to
On Wed, Mar 04, 2015 at 09:30:09AM +0100, Yannick Guerrini wrote:
> Change 'pixes' to 'pixels'
> Change 'enabel' to 'enable'
> Change 'enabeling' to 'enabling'
>
> Signed-off-by: Yannick Guerrini
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_modes.c | 4 ++--
> drivers/gpu
Up until now, we assume that eDP is tight to intf_0 and HDMI to
intf_3. This information shall actually come from the mdp5_cfg
module since it can change from one chip to another.
v2: rename macro to mdp5_cfg_intf_is_virtual() [pointed by Archit]
Signed-off-by: Stephane Viau
---
drivers/gpu/drm
Some interfaces (WB, DSI Command Mode) need to be kicked off
through a START Signal. This signal needs to be sent at the right
time and requests in some cases to keep track of the pipeline
status (eg: whether pipeline registers are flushed AND output WB
buffers are ready, in case of WB interface).
DSI and WB interfaces need a more complex pipeline configuration
than the current mdp5_ctl_set_intf().
For example, memory output connections need to be selected for
WB. Interface mode (Video vs. Command modes) also need to be
configured for DSI.
This change takes care of configuring the whole pi
Prepare for pipeline operation mode configuration, in particular
for DSI and WB modes.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 68 -
1 file changed, 33 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp
WB and DSI support are in the pipe and will come out soon. Before that,
we need to prepare the MDP5 driver so we can support these connectors.
v2: rename macro to mdp5_cfg_intf_is_virtual() [pointed by Archit]
Stephane Viau (4):
drm/msm/mdp5: Update generated header files
drm/msm/mdp5: Enhanc
On Thu, Mar 05, 2015 at 09:45:41AM +, Chris Wilson wrote:
> Since the beginning, sysfs/connector/status has done a heavyweight
> detection of the current connector status. But no user, such as upowerd
> or logind, has ever desired to initiate a probe. Move the probing into a
> new attribute so
Since the beginning, sysfs/connector/status has done a heavyweight
detection of the current connector status. But no user, such as upowerd
or logind, has ever desired to initiate a probe. Move the probing into a
new attribute so that existing readers get the behaviour they desire.
v2: David Herrma
On 25 February 2015 at 02:16, Alex Williamson
wrote:
> vga_set_legacy_decoding() is defined in drivers/gpu/vga/vgaarb.c,
> which is only compiled with CONFIG_VGA_ARB. A caller would
> therefore get an undefined symbol if the VGA arbiter is not
> enabled.
Acked-by: Dave Airlie
> Signed-off-by:
On 03/04/2015 09:14 PM, "Stéphane Viau" wrote:
>> Hi,
>
> Hi Archit,
>
>>
>> On 03/04/2015 12:06 AM, Stephane Viau wrote:
>>> Up until now, we assume that eDP is tight to intf_0 and HDMI to
>>> intf_3. This information shall actually come from the mdp5_cfg
>>> module since it can change from one
On Mon, Feb 23, 2015 at 11:12:39PM +0300, Andrey Skvortsov wrote:
>
> This warning is moved from linux-next to v4.0-rc1 now. After system boot is
> just a black screen.
> I ssh'ed into the machine and saved the log. I attached updated dmesg.log
> with drm.debug=6. Hopefully it helps.
> If you n
On Wed, Mar 04, 2015 at 06:26:24PM -0800, Haixia Shi wrote:
> Signed-off-by: Haixia Shi
> Reviewed-by: Stéphane Marchesin
> Tested-by: Haixia Shi
> ---
> +static int udl_cursor_download(struct udl_cursor *cursor,
> + struct drm_gem_object *obj)
> +{
> + struct udl_gem_object *u
On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja wrote:
>
> On 02/23/2015 09:09 PM, Daniel Vetter wrote:
>>
>> On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote:
>>>
>>> On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter wrote:
On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote:
On Thu, Mar 05, 2015 at 11:01:08AM +0100, Daniel Vetter wrote:
> We shouldn't tempt driver writers into using this since it uses a
> default format list which is likely wrong. And when that's done we can
> simplify the code a bit, too.
>
> Noticed while reviewing a patch from Laurent.
>
> Cc: Lau
Drivers implementing the universal planes API report the list of
supported pixel formats for the primary plane. Make sure the fb passed
to the setcrtc ioctl is compatible.
Drivers not implementing the universal planes API will have no format
reported for the primary plane, skip the check in that c
Both the legacy and atomic helpers need to check whether a plane
supports a given pixel format. The code is currently duplicated, share
it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_atomic.c | 10 --
drivers/gpu/drm/drm_crtc.c | 25 +++--
include/drm/d
Hello,
Not much to be added, everything is in the subject line. The first patch
prepares for the modification by refactoring code, and the second patch
adds the check.
The patches are based on a merge of drm-next and drm-fixes.
Laurent Pinchart (2):
drm: Share plane pixel format check code bet
nd just leaving it set all the time.
--
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/20150305/c3f4dffe/attachment.html>
vel/attachments/20150305/bcae3ad4/attachment.html>
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/20150305/cfbb4bc9/attachment.html>
Hi Daniel,
On Friday 27 February 2015 13:07:57 Daniel Vetter wrote:
> On Thu, Feb 26, 2015 at 03:20:14PM +0200, Tomi Valkeinen wrote:
> > When setting a color format to a DRM plane, the DRM core checks whether
> > the format is supported by the HW. However, it seems that when setting
> > the color
Hi Tomi,
On Monday 02 March 2015 11:55:48 Tomi Valkeinen wrote:
> On 27/02/15 14:07, Daniel Vetter wrote:
> > On Thu, Feb 26, 2015 at 03:20:14PM +0200, Tomi Valkeinen wrote:
> >> When setting a color format to a DRM plane, the DRM core checks whether
> >> the format is supported by the HW. However
https://bugzilla.kernel.org/show_bug.cgi?id=94081
--- Comment #4 from Jan Vesely ---
This does not make sense, the work structure is zeroed so fence put should is
OK.
it looks like sometimes the lockup needs more than 1 GPU restart to manifest,
I'll replay without the good entries (at least it ex
70 matches
Mail list logo
