Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation
On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: On 06/15/2015 08:53 AM, Daniel Vetter wrote: On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: From: Kausal Malladi kausal.mall...@intel.com This patch set adds color manager implementation in drm/i915 layer. Color Manager is an extension in i915 driver to support color correction/enhancement. Various Intel platforms support several color correction capabilities. Color Manager provides abstraction of these properties and allows a user space UI agent to correct/enhance the display. So I did a first rough pass on the API itself. The big question that isn't solved at the moment is: do we want to try to do generic KMS properties for pre-LUT + matrix + post-LUT or not. Generic has 3 levels: 1/ Generic for all KMS drivers 2/ Generic for i915 supported platfoms 3/ Specific to each platform At this point, I'm quite tempted to say we should give 1/ a shot. We should be able to have pre-LUT + matrix + post-LUT on CRTC objects and guarantee that, when the drivers expose such properties, user space can at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. It may be possible to use the try version of the atomic ioctl to explore the space of possibilities from a generic user space to use bigger LUTs as well. A HAL layer (which is already there in some but not all OSes) would still be able to use those generic properties to load precision optimized LUTs with some knowledge of the hardware. Yeah, imo 1/ should be doable. For the matrix we should be able to be fully generic with a 16.16 format. For gamma one option would be to have I know I am late replying, apologies for that. I've been working on CSC support for V4L2 as well (still work in progress) and I would like to at least end up with the same low-level fixed point format as DRM so we can share matrix/vector calculations. Based on my experiences I have concerns about the 16.16 format: the precision is quite low which can be a problem when such values are used in matrix multiplications. In addition, while the precision may be sufficient for 8 bit color component values, I'm pretty sure it will be insufficient when dealing with 12 or 16 bit color components. In earlier versions of my CSC code I used a 12.20 format, but in the latest I switched to 32.32. This fits nicely in a u64 and it's easy to extract the integer and fractional parts. If this is going to be a generic and future proof API, then my suggestion would be to increase the precision of the underlying data type. We discussed this a bit more internally and figured it would be nice to have the same fixed point for both CSC matrix and LUT/gamma tables. Current consensus seems to be to go with 8.24 for both. Since LUTs are fairly big I think it makes sense if we try to be not too wasteful (while still future-proof ofc). But yeah agreeing on the underlying layout would be good so that we could share in-kernel code. We're aiming to not have any LUT interpolation in the kernel (just dropping samples at most if e.g. the hw table doesn't have linear sample positions). But with the LUT we might need to mutliply it with an in-kernel one (we need the CSC unit on some platforms to compress the color output range for hdmi). And maybe compress the LUTs too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation
On 07/13/2015 11:18 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: On 06/15/2015 08:53 AM, Daniel Vetter wrote: On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: From: Kausal Malladi kausal.mall...@intel.com This patch set adds color manager implementation in drm/i915 layer. Color Manager is an extension in i915 driver to support color correction/enhancement. Various Intel platforms support several color correction capabilities. Color Manager provides abstraction of these properties and allows a user space UI agent to correct/enhance the display. So I did a first rough pass on the API itself. The big question that isn't solved at the moment is: do we want to try to do generic KMS properties for pre-LUT + matrix + post-LUT or not. Generic has 3 levels: 1/ Generic for all KMS drivers 2/ Generic for i915 supported platfoms 3/ Specific to each platform At this point, I'm quite tempted to say we should give 1/ a shot. We should be able to have pre-LUT + matrix + post-LUT on CRTC objects and guarantee that, when the drivers expose such properties, user space can at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. It may be possible to use the try version of the atomic ioctl to explore the space of possibilities from a generic user space to use bigger LUTs as well. A HAL layer (which is already there in some but not all OSes) would still be able to use those generic properties to load precision optimized LUTs with some knowledge of the hardware. Yeah, imo 1/ should be doable. For the matrix we should be able to be fully generic with a 16.16 format. For gamma one option would be to have I know I am late replying, apologies for that. I've been working on CSC support for V4L2 as well (still work in progress) and I would like to at least end up with the same low-level fixed point format as DRM so we can share matrix/vector calculations. Based on my experiences I have concerns about the 16.16 format: the precision is quite low which can be a problem when such values are used in matrix multiplications. In addition, while the precision may be sufficient for 8 bit color component values, I'm pretty sure it will be insufficient when dealing with 12 or 16 bit color components. In earlier versions of my CSC code I used a 12.20 format, but in the latest I switched to 32.32. This fits nicely in a u64 and it's easy to extract the integer and fractional parts. If this is going to be a generic and future proof API, then my suggestion would be to increase the precision of the underlying data type. We discussed this a bit more internally and figured it would be nice to have the same fixed point for both CSC matrix and LUT/gamma tables. Current consensus seems to be to go with 8.24 for both. Since LUTs are fairly big I think it makes sense if we try to be not too wasteful (while still future-proof ofc). The .24 should have enough precision, but I am worried about the 8: while this works for 8 bit components, you can't use it to represent values 255, which might be needed (now or in the future) for 10, 12 or 16 bit color components. It's why I ended up with 32.32: it's very generic so usable for other things besides CSC. Note that 8.24 is really 7.24 + one sign bit. So 255 can't be represented in this format. That said, all values I'm working with in my current code are small integers (say between -4 and 4 worst case), so 8.24 would work. But I am not at all confident that this is future proof. My gut feeling is that you need to be able to represent at least the max component value + a sign bit + 7 decimals precision. Which makes 17.24. Regards, Hans But yeah agreeing on the underlying layout would be good so that we could share in-kernel code. We're aiming to not have any LUT interpolation in the kernel (just dropping samples at most if e.g. the hw table doesn't have linear sample positions). But with the LUT we might need to mutliply it with an in-kernel one (we need the CSC unit on some platforms to compress the color output range for hdmi). And maybe compress the LUTs too. -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
On Mon, Jul 13, 2015 at 11:49:01AM +0200, Maarten Lankhorst wrote:
Op 13-07-15 om 11:45 schreef Daniel Vetter:
On Mon, Jul 13, 2015 at 11:23:45AM +0200, Maarten Lankhorst wrote:
Op 13-07-15 om 11:13 schreef Daniel Vetter:
On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 22:12 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 19:52 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 10:55 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 18:43 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 14:10 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst
wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
wrote:
This allows the first atomic call during hw init to be a
real modeset,
which is useful for forcing a recalculation.
fbcon is optional, you can't rely on anything being done in
any specific
way. What exactly do you need this for, what's the
implications?
In the hw readout I noticed some warnings when I wasn't
setting any mode property in the readout.
I want the first function to be the modeset, so we have a sane
base to commit changes on.
Ideally this whole function would have a atomic counterpart
which does it in one go. :)
Yeah. Otoh as soon as we have atomic modeset working we can
replace all
the legacy entry points with atomic helpers, and then even
plane_disable
will be a full atomic modeset.
What did fall apart with just touching properties/planes now?
Also when i915 is fully atomic it calculates in
intel_modeset_compute_config
if a modeset is needed after the first atomic call. Right now
because
intel_modeset_compute_config is only called in set_config so
this works as expected.
Otherwise drm_plane_force_disable or rotate_0 will force a
modeset,
and if the final mode is different this will introduce a double
modeset.
For expensive properties (i.e. a no-op changes causes something
that takes
time like modeset or vblank wait) we need to make sure we filter
them out
in atomic_check. Yeah not quite there yet with pure atomic, but
meanwhile
the existing legacy set_prop functions should all filter out
no-op changes
themselves. If we don't do that for rotation then that's a bug.
Same for disabling planes harder, that shouldn't take time.
Especially
since fbcon only force-disable non-primary plane, and for driver
load
that's the exact thing we already do in the driver anyway.
Something like this?
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a1d4e13f3908..2989232f4996 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
#include drm/drm_plane_helper.h
#include drm/drm_crtc_helper.h
#include drm/drm_atomic_helper.h
+#include drm_crtc_internal.h
#include linux/fence.h
/**
@@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
drm_crtc *crtc,
{
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(crtc-base, property, retval);
+ if (!ret val == retval)
+ return 0;
state = drm_atomic_state_alloc(crtc-dev);
if (!state)
@@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
drm_plane *plane,
{
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(plane-base, property, retval);
+ if (!ret val == retval)
+ return 0;
state = drm_atomic_state_alloc(plane-dev);
if (!state)
@@ -1836,7 +1847,12 @@
drm_atomic_helper_connector_set_property(struct drm_connector
*connector,
{
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(connector-base, property,
retval);
+ if (!ret val == retval)
+ return 0;
state = drm_atomic_state_alloc(connector-dev);
if (!state)
The reason I didn't do this is that a prop change might still
result in no
hw state change (e.g. if you go automitic-explicit setting matching
automatic one). Hence I think we need to solve this in lower levels
anyway, i.e. in when computing the config. But it shouldn't cause
trouble
yet.
Is that a ack or nack?
I think we shouldn't need this really for i915, and it might cover up
bugs. I prefer we just do the evade modeset logic you've
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't forget to mark crtc as inactive after disable
Op 10-07-15 om 13:22 schreef Damien Lespiau: Hi Patrik, Please do Cc the patch author and reviewer when finding a regression, they are superb candidates for the review, especially when they are busy rewriting the display code. On Wed, Jul 08, 2015 at 03:31:52PM +0200, Patrik Jakobsson wrote: Watermark calculations depend on the intel_crtc-active flag to be set properly. Suspend/resume is broken on SKL and we also get DDB mismatches without this patch. The regression was introduced in: commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 Author: Maarten Lankhorst maarten.lankho...@linux.intel.com Date: Mon Jun 15 12:33:53 2015 +0200 drm/i915: Update less state during modeset. No need to repeatedly call update_watermarks, or update_fbc. Down to a single call to update_watermarks in .crtc_enable Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com Reviewed-by: Matt Roper matthew.d.ro...@intel.com Tested-by(IVB): Matt Roper matthew.d.ro...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch v2: Don't touch disable_shared_dpll() Signed-off-by: Patrik Jakobsson patrik.jakobs...@linux.intel.com We do need to update the watermarks in disable() as well, to repartition the DDB and update the watermarks based on the new allocation. Maarten, Matt, I've no clue where you want the crtc state update, where the atomic WM work is at, could you comment? I'd rather have we had a better way of updating watermarks, but keeping it in the .crtc_disable hook looks good to me right now. Some proper atomic solution will eventually have to be done. :) Reviewed-by: Maarten Lankhorst maarten.lankho...@linux.intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 22:12 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 19:52 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 10:55 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 18:43 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 14:10 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
This allows the first atomic call during hw init to be a real
modeset,
which is useful for forcing a recalculation.
fbcon is optional, you can't rely on anything being done in any
specific
way. What exactly do you need this for, what's the implications?
In the hw readout I noticed some warnings when I wasn't setting
any mode property in the readout.
I want the first function to be the modeset, so we have a sane
base to commit changes on.
Ideally this whole function would have a atomic counterpart which
does it in one go. :)
Yeah. Otoh as soon as we have atomic modeset working we can replace
all
the legacy entry points with atomic helpers, and then even
plane_disable
will be a full atomic modeset.
What did fall apart with just touching properties/planes now?
Also when i915 is fully atomic it calculates in
intel_modeset_compute_config
if a modeset is needed after the first atomic call. Right now because
intel_modeset_compute_config is only called in set_config so this
works as expected.
Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
and if the final mode is different this will introduce a double
modeset.
For expensive properties (i.e. a no-op changes causes something that
takes
time like modeset or vblank wait) we need to make sure we filter them
out
in atomic_check. Yeah not quite there yet with pure atomic, but
meanwhile
the existing legacy set_prop functions should all filter out no-op
changes
themselves. If we don't do that for rotation then that's a bug.
Same for disabling planes harder, that shouldn't take time. Especially
since fbcon only force-disable non-primary plane, and for driver load
that's the exact thing we already do in the driver anyway.
Something like this?
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a1d4e13f3908..2989232f4996 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
#include drm/drm_plane_helper.h
#include drm/drm_crtc_helper.h
#include drm/drm_atomic_helper.h
+#include drm_crtc_internal.h
#include linux/fence.h
/**
@@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
drm_crtc *crtc,
{
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(crtc-base, property, retval);
+ if (!ret val == retval)
+ return 0;
state = drm_atomic_state_alloc(crtc-dev);
if (!state)
@@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
drm_plane *plane,
{
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(plane-base, property, retval);
+ if (!ret val == retval)
+ return 0;
state = drm_atomic_state_alloc(plane-dev);
if (!state)
@@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
drm_connector *connector,
{
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(connector-base, property,
retval);
+ if (!ret val == retval)
+ return 0;
state = drm_atomic_state_alloc(connector-dev);
if (!state)
The reason I didn't do this is that a prop change might still result in
no
hw state change (e.g. if you go automitic-explicit setting matching
automatic one). Hence I think we need to solve this in lower levels
anyway, i.e. in when computing the config. But it shouldn't cause
trouble
yet.
Is that a ack or nack?
I think we shouldn't need this really for i915, and it might cover up
bugs. I prefer we just do the evade modeset logic you've implemented once
we switch over to atomic props. Since atm we only have atomic props which
get updated in pageflips we shouldn't
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to stop_rings mode bits
On Fri, Jul 10, 2015 at 02:06:06PM +0100, tim.g...@intel.com wrote: From: Tim Gore tim.g...@intel.com In function igt_set_stop_rings, the test igt_assert_f(flags == 0 || current == 0, .. will fail if we are trying to force a hang but the STOP_RINGS_ALLOW_BAN or STOP_RINGS_ALLOW_ERROR bit is set. With the introduction of per ring resets in the driver (in android) these bits do not get cleared to zero when an individual ring is reset. This causes subsequent attempt to cause a ring hang via this function to fail, leading to several igt tests failing (ie gem_reset_stats subtest ban-xxx etc). Fix tdr to reset these instead? -Daniel So, modify this test to look only at the bits that are used to hang the gpu rings. Signed-off-by: Tim Gore tim.g...@intel.com --- lib/igt_gt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/igt_gt.c b/lib/igt_gt.c index 8e5e076..12c56fa 100644 --- a/lib/igt_gt.c +++ b/lib/igt_gt.c @@ -345,8 +345,8 @@ void igt_set_stop_rings(enum stop_ring_flags flags) STOP_RING_ALLOW_ERRORS)) == 0); current = igt_get_stop_rings(); - igt_assert_f(flags == 0 || current == 0, - previous i915_ring_stop is still 0x%x\n, current); + igt_assert_f( (flags STOP_RING_ALL) == 0 || (current STOP_RING_ALL) == 0, + previous i915_ring_stop is still 0x%x\n, current); stop_rings_write(flags); current = igt_get_stop_rings(); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 14/18] drm/i915: object size needs to be u64
On 7/8/2015 6:03 PM, Chris Wilson wrote: On Wed, Jul 08, 2015 at 05:42:17PM +0100, Michel Thierry wrote: WARN_ON(vma-node.size != obj-base.size) ? Feel free to get the casting right - I suck at implicit C integer conversion rules ... -Daniel Thanks, if there's no objections, I'll change it to: if (WARN_ON(vma-node.size != (u64)vma-obj-base.size)) return -ENODEV; Are we still talking about i915_vma_bind()? Then vma-node.size != vma-obj.base.size anyway. -Chris Right, it can be either obj-base.size, fence_size or view_size... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 35/36] drivers/gpu/drm/virtio/virtgpu_drm_bus.c:55:2: error: implicit declaration of function 'drm_fb_helper_remove_conflicting_framebuffers'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3 commit: 7bd870e7b1c8b4ff0b1624778d9ab17bfe6b903d [35/36] drm/virtio: Use new drm_fb_helper functions config: x86_64-randconfig-i0-201528 (attached as .config) reproduce: git checkout 7bd870e7b1c8b4ff0b1624778d9ab17bfe6b903d # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by ): drivers/gpu/drm/virtio/virtgpu_drm_bus.c: In function 'virtio_pci_kick_out_firmware_fb': drivers/gpu/drm/virtio/virtgpu_drm_bus.c:55:2: error: implicit declaration of function 'drm_fb_helper_remove_conflicting_framebuffers' [-Werror=implicit-function-declaration] drm_fb_helper_remove_conflicting_framebuffers(ap, virtiodrmfb, ^ cc1: some warnings being treated as errors -- drivers/gpu/drm/virtio/virtgpu_fb.c: In function 'virtio_gpufb_create': drivers/gpu/drm/virtio/virtgpu_fb.c:233:17: warning: unused variable 'device' [-Wunused-variable] struct device *device = vgdev-dev; ^ drivers/gpu/drm/virtio/virtgpu_fb.c: In function 'virtio_gpu_fbdev_destroy': drivers/gpu/drm/virtio/virtgpu_fb.c:365:18: warning: unused variable 'info' [-Wunused-variable] struct fb_info *info; ^ vim +/drm_fb_helper_remove_conflicting_framebuffers +55 drivers/gpu/drm/virtio/virtgpu_drm_bus.c 50cb941a Gerd Hoffmann 2015-03-26 49 ap-ranges[0].base = pci_resource_start(pci_dev, 0); 50cb941a Gerd Hoffmann 2015-03-26 50 ap-ranges[0].size = pci_resource_len(pci_dev, 0); 50cb941a Gerd Hoffmann 2015-03-26 51 50cb941a Gerd Hoffmann 2015-03-26 52 primary = pci_dev-resource[PCI_ROM_RESOURCE].flags 50cb941a Gerd Hoffmann 2015-03-26 53IORESOURCE_ROM_SHADOW; 50cb941a Gerd Hoffmann 2015-03-26 54 7bd870e7 Archit Taneja 2015-07-13 @55 drm_fb_helper_remove_conflicting_framebuffers(ap, virtiodrmfb, 7bd870e7 Archit Taneja 2015-07-13 56 primary); 50cb941a Gerd Hoffmann 2015-03-26 57 50cb941a Gerd Hoffmann 2015-03-26 58 kfree(ap); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 4.1.0-rc6 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: avoid leaking DMA mappings
On la, 2015-07-11 at 21:54 +0100, Chris Wilson wrote:
On Thu, Jul 09, 2015 at 12:59:05PM +0300, Imre Deak wrote:
+static int
+__i915_gem_userptr_set_pages(struct drm_i915_gem_object *obj,
+struct page **pvec, int num_pages)
+{
+ int ret;
+
+ ret = st_set_pages(obj-pages, pvec, num_pages);
+ if (ret)
+ return ret;
+
+ ret = i915_gem_gtt_prepare_object(obj);
+ if (ret) {
+ sg_free_table(obj-pages);
+ kfree(obj-pages);
+ obj-pages = NULL;
Oh dear, we just leaked a ref one each page.
To summarize the IRC discussion on this: it would be logical that
sg_set_page() takes a ref - and in that case this would result in
leaking those refs - but this is not so. Instead we rely on the GUP refs
which we keep in case of success by setting pinned=0 (release_pages will
be a nop) and drop in case of failure by passing the original pinned
value to release_pages(). So after checking both the sync and async
userptr paths this looks ok to me.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/amdgpu: fix odd_ptr_err.cocci warnings
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:205:5-11: inconsistent IS_ERR and
PTR_ERR, PTR_ERR on line 206
PTR_ERR should access the value just tested by IS_ERR
Semantic patch information:
There can be false positives in the patch case, where it is the call
IS_ERR that is wrong.
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
CC: Archit Taneja arch...@codeaurora.org
Signed-off-by: Fengguang Wu fengguang...@intel.com
---
amdgpu_fb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -203,7 +203,7 @@ static int amdgpufb_create(struct drm_fb
/* okay we have an object now allocate the framebuffer */
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
- ret = PTR_ERR(ret);
+ ret = PTR_ERR(info);
goto out_unref;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 34/36] drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:205:5-11: inconsistent IS_ERR and PTR_ERR, PTR_ERR on line 206
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3 commit: 9d70561ba3b129ae7bc052a9f73812bc3b7ad91a [34/36] drm/amdgpu: Use new drm_fb_helper functions coccinelle warnings: (new ones prefixed by ) drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:205:5-11: inconsistent IS_ERR and PTR_ERR, PTR_ERR on line 206 Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update PM interrupts before updating the freq
On Sat, Jul 11, 2015 at 05:46:37PM +0100, Chris Wilson wrote: On Fri, Jul 10, 2015 at 06:31:40PM +0530, Praveen Paneri wrote: From: Deepak S deepa...@intel.com Currently we update the freq before masking the interrupts, which can allow new interrupts to occur before the frequency has changed. These extra interrupts might waste some cpu cycles. This patch corrects this by masking interrupts prior to updating the frequency. Well it won't waste CPU cycles as the interrupt is also masked by the threshold limits, but there should be no harm at all in reordering the patch so, and it does make a certain amount of sense. Added and ... Signed-off-by: Deepak S deepa...@intel.com Signed-off-by: Praveen Paneri praveen.pan...@intel.com Quibbling over the language in the changelog aside, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
On Mon, Jul 13, 2015 at 02:10:09PM +0530, Sonika Jindal wrote:
As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection.
And remove the redundant comment.
v2: Remove redundant IS_BROXTON check, Add comment about port C not
connected, and rephrase the commit message to include only what we
are doing here (Imre)
v3: Add comment about the WA, move 'hpd' initialization outside for
loop (Siva)
Also, remove few redundant comments from hpd handler (me)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Can't we do this in two steps:
- Wire up port A hpd in a generic way.
- Add wa for bxt to use port A hpd in the various encoder setup functions
where we assign intel_encoder-hpd_pin.
Currently that switchover is spread all through low-level functions, which
makes this a bit confusion. Imo low-level code shouldn't treat hpd A as
anything but hpd A since that's just confusing. And we already have the
infrastructure for encoders to ask for any hpd pin they want really.
-Daniel
---
drivers/gpu/drm/i915/i915_irq.c | 46
++-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a897f68..13cabca 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,14 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-/* BXT hpd list */
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and interrupts to check
+ * the external panel connection. Port C is not connected on bxt A0/A1
+ */
+static const u32 hpd_bxt_a0[HPD_NUM_PINS] = {
+ [HPD_PORT_B] = BXT_DE_PORT_HP_DDIA
+};
+
static const u32 hpd_bxt[HPD_NUM_PINS] = {
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
@@ -1967,6 +1974,7 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
struct drm_i915_private *dev_priv = dev-dev_private;
u32 hp_control, hp_trigger;
u32 pin_mask, long_mask;
+ const u32 *hpd;
/* Get the status */
hp_trigger = iir_status BXT_DE_PORT_HOTPLUG_MASK;
@@ -1981,7 +1989,12 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
/* Clear sticky bits in hpd status */
I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
- pch_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control,
hpd_bxt);
+ if (INTEL_REVID(dev) BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ pch_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control, hpd);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -3021,31 +3034,34 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
struct intel_encoder *intel_encoder;
u32 hotplug_port = 0;
u32 hotplug_ctrl;
+ const u32 *hpd;
- /* Now, enable HPD */
- for_each_intel_encoder(dev, intel_encoder) {
+ if (INTEL_REVID(dev) BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ for_each_intel_encoder(dev, intel_encoder)
if (dev_priv-hotplug.stats[intel_encoder-hpd_pin].state
== HPD_ENABLED)
- hotplug_port |= hpd_bxt[intel_encoder-hpd_pin];
- }
+ hotplug_port |= hpd[intel_encoder-hpd_pin];
- /* Mask all HPD control bits */
hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) ~BXT_HOTPLUG_CTL_MASK;
- /* Enable requested port in hotplug control */
/* TODO: implement (short) HPD support on port A */
- WARN_ON_ONCE(hotplug_port BXT_DE_PORT_HP_DDIA);
- if (hotplug_port BXT_DE_PORT_HP_DDIB)
- hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
- if (hotplug_port BXT_DE_PORT_HP_DDIC)
- hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ if (INTEL_REVID(dev) BXT_REVID_B0 (hotplug_port
BXT_DE_PORT_HP_DDIA))
+ hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
+ else {
+ if (hotplug_port BXT_DE_PORT_HP_DDIB)
+ hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
+ if (hotplug_port BXT_DE_PORT_HP_DDIC)
+ hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ }
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
- /* Unmask DDI hotplug in IMR */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR) ~hotplug_port;
I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
- /* Enable DDI hotplug in IER */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
POSTING_READ(GEN8_DE_PORT_IER);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
[Intel-gfx] [PATCH] drm/i915: Fix noatomic crtc disabling, v2.
This fixes the breakage caused by commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 Author: Maarten Lankhorst maarten.lankho...@linux.intel.com Date: Mon Jun 15 12:33:53 2015 +0200 drm/i915: Update less state during modeset. No need to repeatedly call update_watermarks, or update_fbc. Down to a single call to update_watermarks in .crtc_enable Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com Reviewed-by: Matt Roper matthew.d.ro...@intel.com Tested-by(IVB): Matt Roper matthew.d.ro...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Add missing shared dpll disable to the noatomic disable function. This function will be replaced by its atomic counterpart soon. Changes since v1: - intel_crtc-active and watermarks are fixed by a patch from Patrik Jakobsson Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com --- diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 80a08c701574..887ba0a54352 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6184,6 +6184,7 @@ static void intel_crtc_disable_noatomic(struct drm_crtc *crtc) intel_crtc_disable_planes(crtc, crtc-state-plane_mask); dev_priv-display.crtc_disable(crtc); + intel_disable_shared_dpll(intel_crtc); domains = intel_crtc-enabled_power_domains; for_each_power_domain(domain, domains) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect
On 7/13/2015 5:10 PM, Chris Wilson wrote: On Mon, Jul 13, 2015 at 04:19:15PM +0530, Sonika Jindal wrote: During init_connector set the edid, then edid will be set/unset only during hotplug. For the sake of older platforms where HPD is not stable, let edid read happen from detect as well only if it is forced to do so. v2: Removing the 'force' check, instead let detect call read the edid for platforms older than gen 7 (Shashank) That's enough worse. We now have a random gen check with no rationale for why you suddenly believe all manufacturers have fixed their wiring. There is no reason to believe that gen7 suddenly works is there? If there is, why don't you mention it? -Chris This gen7 check is to be on the safer side not to affect older paltforms. For CHV/VLV, already the live status check is stable enough to determine if we can read edid or not. In VPG production branches we have this patch already available and it was tested with variety of monitors extensively. So we now read the edid only during init and during hotplug. For SKL, the [PATCH] drm/i915: Handle HPD when it has actually occurred patch makes HPD stable enough. So, we can rely on the edid read from init_connector instead of reading edid on every detect call. Regards, Sonika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915/skl: Updated the i915_ring_freq_table debugfs function
On Mon, Jun 29, 2015 at 02:50:22PM +0530, akash.g...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
Updated the i915_ring_freq_table debugfs function to support the read
of ring frequency table, through Punit interface, for SKL also.
Issue: VIZ-5144
Signed-off-by: Akash Goel akash.g...@intel.com
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Merged patches 1, 34 from this series, thanks.
-Daniel
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e40e479..f8df5f2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1760,6 +1760,7 @@ static int i915_ring_freq_table(struct seq_file *m,
void *unused)
struct drm_i915_private *dev_priv = dev-dev_private;
int ret = 0;
int gpu_freq, ia_freq;
+ unsigned int max_gpu_freq, min_gpu_freq;
if (!(IS_GEN6(dev) || IS_GEN7(dev))) {
seq_puts(m, unsupported on this chipset\n);
@@ -1774,17 +1775,27 @@ static int i915_ring_freq_table(struct seq_file *m,
void *unused)
if (ret)
goto out;
+ if (IS_SKYLAKE(dev)) {
+ /* Convert GT frequency to 50 HZ units */
+ min_gpu_freq =
+ dev_priv-rps.min_freq_softlimit / GEN9_FREQ_SCALER;
+ max_gpu_freq =
+ dev_priv-rps.max_freq_softlimit / GEN9_FREQ_SCALER;
+ } else {
+ min_gpu_freq = dev_priv-rps.min_freq_softlimit;
+ max_gpu_freq = dev_priv-rps.max_freq_softlimit;
+ }
+
seq_puts(m, GPU freq (MHz)\tEffective CPU freq (MHz)\tEffective Ring
freq (MHz)\n);
- for (gpu_freq = dev_priv-rps.min_freq_softlimit;
- gpu_freq = dev_priv-rps.max_freq_softlimit;
- gpu_freq++) {
+ for (gpu_freq = min_gpu_freq; gpu_freq = max_gpu_freq; gpu_freq++) {
ia_freq = gpu_freq;
sandybridge_pcode_read(dev_priv,
GEN6_PCODE_READ_MIN_FREQ_TABLE,
ia_freq);
seq_printf(m, %d\t\t%d\t\t\t\t%d\n,
-intel_gpu_freq(dev_priv, gpu_freq),
+intel_gpu_freq(dev_priv, (gpu_freq *
+ (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1))),
((ia_freq 0) 0xff) * 100,
((ia_freq 8) 0xff) * 100);
}
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Allow parsing of variable size child device entries from VBT
On Fri, Jul 10, 2015 at 02:10:54PM +0300, Antti Koskipaa wrote:
VBT version 196 increased the size of common_child_dev_config. The parser
code assumed that the size of this structure would not change.
So now, instead of checking for smaller size, check that the VBT entry is
not too large and memcpy only child_dev_size amount of data, leaving any
trailing entries as zero. If this is not good enough for the future,
we can always sprinkle extra version checks in there.
Signed-off-by: Antti Koskipaa antti.koski...@linux.intel.com
As I mentioned in the other threads I think with vbt it's not too paranoid
to double-check our assumptions. So for each vbt version range I'd like us
to check what size we exactly expect. Being super paranoid with vbt is imo
good practice since otherwise the hw teams will sneak in another update
without us realizing it.
-Daniel
---
drivers/gpu/drm/i915/intel_bios.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 2ff9eb0..763a636 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1022,10 +1022,15 @@ parse_device_mapping(struct drm_i915_private
*dev_priv,
DRM_DEBUG_KMS(No general definition block is found, no devices
defined.\n);
return;
}
- if (p_defs-child_dev_size sizeof(*p_child)) {
+ /* Historically, child_dev_size has to be at least 33 bytes in size. */
+ if (p_defs-child_dev_size 33) {
DRM_ERROR(General definiton block child device size is too
small.\n);
return;
}
+ if (p_defs-child_dev_size sizeof(*p_child)) {
+ DRM_ERROR(General definiton block child device size is too
large.\n);
+ return;
+ }
/* get the block size of general definitions */
block_size = get_blocksize(p_defs);
/* get the number of child device */
@@ -1070,7 +1075,7 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
child_dev_ptr = dev_priv-vbt.child_dev + count;
count++;
- memcpy(child_dev_ptr, p_child, sizeof(*p_child));
+ memcpy(child_dev_ptr, p_child, p_defs-child_dev_size);
}
return;
}
--
2.3.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation
On Mon, Jul 13, 2015 at 11:43:31AM +0200, Hans Verkuil wrote: On 07/13/2015 11:18 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: On 06/15/2015 08:53 AM, Daniel Vetter wrote: On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: From: Kausal Malladi kausal.mall...@intel.com This patch set adds color manager implementation in drm/i915 layer. Color Manager is an extension in i915 driver to support color correction/enhancement. Various Intel platforms support several color correction capabilities. Color Manager provides abstraction of these properties and allows a user space UI agent to correct/enhance the display. So I did a first rough pass on the API itself. The big question that isn't solved at the moment is: do we want to try to do generic KMS properties for pre-LUT + matrix + post-LUT or not. Generic has 3 levels: 1/ Generic for all KMS drivers 2/ Generic for i915 supported platfoms 3/ Specific to each platform At this point, I'm quite tempted to say we should give 1/ a shot. We should be able to have pre-LUT + matrix + post-LUT on CRTC objects and guarantee that, when the drivers expose such properties, user space can at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. It may be possible to use the try version of the atomic ioctl to explore the space of possibilities from a generic user space to use bigger LUTs as well. A HAL layer (which is already there in some but not all OSes) would still be able to use those generic properties to load precision optimized LUTs with some knowledge of the hardware. Yeah, imo 1/ should be doable. For the matrix we should be able to be fully generic with a 16.16 format. For gamma one option would be to have I know I am late replying, apologies for that. I've been working on CSC support for V4L2 as well (still work in progress) and I would like to at least end up with the same low-level fixed point format as DRM so we can share matrix/vector calculations. Based on my experiences I have concerns about the 16.16 format: the precision is quite low which can be a problem when such values are used in matrix multiplications. In addition, while the precision may be sufficient for 8 bit color component values, I'm pretty sure it will be insufficient when dealing with 12 or 16 bit color components. In earlier versions of my CSC code I used a 12.20 format, but in the latest I switched to 32.32. This fits nicely in a u64 and it's easy to extract the integer and fractional parts. If this is going to be a generic and future proof API, then my suggestion would be to increase the precision of the underlying data type. We discussed this a bit more internally and figured it would be nice to have the same fixed point for both CSC matrix and LUT/gamma tables. Current consensus seems to be to go with 8.24 for both. Since LUTs are fairly big I think it makes sense if we try to be not too wasteful (while still future-proof ofc). The .24 should have enough precision, but I am worried about the 8: while this works for 8 bit components, you can't use it to represent values 255, which might be needed (now or in the future) for 10, 12 or 16 bit color components. It's why I ended up with 32.32: it's very generic so usable for other things besides CSC. Note that 8.24 is really 7.24 + one sign bit. So 255 can't be represented in this format. That said, all values I'm working with in my current code are small integers (say between -4 and 4 worst case), so 8.24 would work. But I am not at all confident that this is future proof. My gut feeling is that you need to be able to represent at least the max component value + a sign bit + 7 decimals precision. Which makes 17.24. The idea is to steal from GL and always normalize everything to [0.0, 1.0], irrespective of the source color format. We need that in drm since if you blend together planes with different formats it's completely undefined which one you should pick. 8 bits of precision for values out of range should be enough ;-) Oh and we might need those since for CSC and at least some LUTs you can do this. It's probably needed if your destination color space is much smaller than the source and you need to expand it. Will result in some clamping ofc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation
On 07/13/2015 11:54 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 11:43:31AM +0200, Hans Verkuil wrote: On 07/13/2015 11:18 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: On 06/15/2015 08:53 AM, Daniel Vetter wrote: On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: From: Kausal Malladi kausal.mall...@intel.com This patch set adds color manager implementation in drm/i915 layer. Color Manager is an extension in i915 driver to support color correction/enhancement. Various Intel platforms support several color correction capabilities. Color Manager provides abstraction of these properties and allows a user space UI agent to correct/enhance the display. So I did a first rough pass on the API itself. The big question that isn't solved at the moment is: do we want to try to do generic KMS properties for pre-LUT + matrix + post-LUT or not. Generic has 3 levels: 1/ Generic for all KMS drivers 2/ Generic for i915 supported platfoms 3/ Specific to each platform At this point, I'm quite tempted to say we should give 1/ a shot. We should be able to have pre-LUT + matrix + post-LUT on CRTC objects and guarantee that, when the drivers expose such properties, user space can at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. It may be possible to use the try version of the atomic ioctl to explore the space of possibilities from a generic user space to use bigger LUTs as well. A HAL layer (which is already there in some but not all OSes) would still be able to use those generic properties to load precision optimized LUTs with some knowledge of the hardware. Yeah, imo 1/ should be doable. For the matrix we should be able to be fully generic with a 16.16 format. For gamma one option would be to have I know I am late replying, apologies for that. I've been working on CSC support for V4L2 as well (still work in progress) and I would like to at least end up with the same low-level fixed point format as DRM so we can share matrix/vector calculations. Based on my experiences I have concerns about the 16.16 format: the precision is quite low which can be a problem when such values are used in matrix multiplications. In addition, while the precision may be sufficient for 8 bit color component values, I'm pretty sure it will be insufficient when dealing with 12 or 16 bit color components. In earlier versions of my CSC code I used a 12.20 format, but in the latest I switched to 32.32. This fits nicely in a u64 and it's easy to extract the integer and fractional parts. If this is going to be a generic and future proof API, then my suggestion would be to increase the precision of the underlying data type. We discussed this a bit more internally and figured it would be nice to have the same fixed point for both CSC matrix and LUT/gamma tables. Current consensus seems to be to go with 8.24 for both. Since LUTs are fairly big I think it makes sense if we try to be not too wasteful (while still future-proof ofc). The .24 should have enough precision, but I am worried about the 8: while this works for 8 bit components, you can't use it to represent values 255, which might be needed (now or in the future) for 10, 12 or 16 bit color components. It's why I ended up with 32.32: it's very generic so usable for other things besides CSC. Note that 8.24 is really 7.24 + one sign bit. So 255 can't be represented in this format. That said, all values I'm working with in my current code are small integers (say between -4 and 4 worst case), so 8.24 would work. But I am not at all confident that this is future proof. My gut feeling is that you need to be able to represent at least the max component value + a sign bit + 7 decimals precision. Which makes 17.24. The idea is to steal from GL and always normalize everything to [0.0, 1.0], irrespective of the source color format. We need that in drm since if you blend together planes with different formats it's completely undefined which one you should pick. 8 bits of precision for values out of range should be enough ;-) That doesn't really help much, using a [0-1] range just means that you need more precision for the fraction since the integer precision is now added to the fractional precision. So for 16-bit color components the 8.24 format will leave you with only 8 bits precision if you scale each component to the [0-1] range. That's slightly more than 2 decimals. I don't believe that is enough. If you do a gamma table lookup and then feed the result to a CSC matrix you need more precision if you want to get accurate results. Oh and we might need those since for CSC and at least some LUTs you can do this. Sorry, I don't understand this sentence. What does 'those' and 'this' refer to? It's probably needed if your destination color space is much smaller than the source and
[Intel-gfx] [PATCH v2 3/4] drm/i915/gen9: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround
In Indirect context w/a batch buffer,
+WaFlushCoherentL3CacheLinesAtContextSwitch:bdw
v2: address static checker warning where unsigned value was checked for
less than zero which is never true.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6a0b128..7536682 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1253,6 +1253,7 @@ static int gen9_init_indirectctx_bb(struct
intel_engine_cs *ring,
uint32_t *const batch,
uint32_t *offset)
{
+ int ret;
struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
@@ -1261,6 +1262,12 @@ static int gen9_init_indirectctx_bb(struct
intel_engine_cs *ring,
(IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0)))
wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_DISABLE);
+ /* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt */
+ ret = gen8_emit_flush_coherentl3_wa(ring, batch, index);
+ if (ret 0)
+ return ret;
+ index = ret;
+
/* Pad to end of cacheline */
while (index % CACHELINE_DWORDS)
wa_ctx_emit(batch, MI_NOOP);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check live status before reading edid
Adding this for SKL onwards.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 42 +
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..7b54b9d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
return intel_dp_detect_dpcd(intel_dp);
}
-static int g4x_digital_port_connected(struct drm_device *dev,
- struct intel_digital_port
*intel_dig_port)
+int g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port)
{
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a47fbc3..30c8dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
void intel_edp_drrs_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
+int g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port);
/* intel_dp_mst.c */
int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1fb6919..7eb0d0e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,39 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
to_intel_connector(connector)-detect_edid = NULL;
}
+static bool bxt_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *port)
+{
+ u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+ switch (port-port) {
+ case PORT_B:
+ return temp BXT_DE_PORT_HP_DDIB;
+
+ case PORT_C:
+ return temp BXT_DE_PORT_HP_DDIC;
+
+ default:
+ return false;
+
+ }
+}
+
+static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
+{
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ if (IS_VALLEYVIEW(dev))
+ return g4x_digital_port_connected(dev, intel_dig_port);
+ else if (IS_SKYLAKE(dev))
+ return ibx_digital_port_connected(dev_priv, intel_dig_port);
+ else if (IS_BROXTON(dev))
+ return bxt_port_connected(dev_priv, intel_dig_port);
+
+ return true;
+}
+
static bool
intel_hdmi_set_edid(struct drm_connector *connector)
{
@@ -1308,15 +1341,16 @@ intel_hdmi_set_edid(struct drm_connector *connector)
struct intel_encoder *intel_encoder =
hdmi_to_dig_port(intel_hdmi)-base;
enum intel_display_power_domain power_domain;
- struct edid *edid;
+ struct edid *edid = NULL;
bool connected = false;
power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
- edid = drm_get_edid(connector,
- intel_gmbus_get_adapter(dev_priv,
- intel_hdmi-ddc_bus));
+ if (intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi)))
+ edid = drm_get_edid(connector,
+ intel_gmbus_get_adapter(dev_priv,
+ intel_hdmi-ddc_bus));
intel_display_power_put(dev_priv, power_domain);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround
Arun Siluvery arun.siluv...@linux.intel.com writes:
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).
Cc: Robert Beckett robert.beck...@intel.com
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 1e88b3b..e84fc52 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1274,10 +1274,13 @@ static int gen9_init_indirectctx_bb(struct
intel_engine_cs *ring,
uint32_t *const batch,
uint32_t *offset)
{
+ struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
- /* FIXME: Replace me with WA */
- wa_ctx_emit(batch, MI_NOOP);
+ /* WaDisableCtxRestoreArbitration:skl,bxt */
+ if ((IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_D0)) ||
+ (IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0)))
+ wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_DISABLE);
/* Pad to end of cacheline */
while (index % CACHELINE_DWORDS)
@@ -1291,8 +1294,14 @@ static int gen9_init_perctx_bb(struct intel_engine_cs
*ring,
uint32_t *const batch,
uint32_t *offset)
{
+ struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
+ /* WaDisableCtxRestoreArbitration:skl,bxt */
+ if ((IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_D0)) ||
+ (IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0)))
+ wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_ENABLE);
+
wa_ctx_emit(batch, MI_BATCH_BUFFER_END);
return wa_ctx_end(wa_ctx, *offset = index, 1);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Adjust BXT HDMI port clock limits
On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: On ma, 2015-07-06 at 14:44 +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Since commit e62925567c7926e78bc8ca976cde5c28ea265a49 Author: Vandana Kannan vandana.kan...@intel.com Date: Wed Jul 1 17:02:57 2015 +0530 drm/i915/bxt: BUNs related to port PLL BXT DPLL can now generate frequencies in the 216-223 MHz range. Adjust the HDMI port clock checks to account for the reduced range of invalid frequencies. Cc: Vandana Kannan vandana.kan...@intel.com Cc: Imre Deak imre.d...@intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Ville wrote a tool for CHV that calculates the valid frequencies based on the algorithm in the kernel. With the help of that I verified that this matches the list of target frequencies bxt_find_best_dpll() will accept, so: Reviewed-by: Imre Deak imre.d...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: storm detection documentation update
On Fri, Jul 10, 2015 at 12:30:43PM +0530, Sivakumar Thulasimani wrote: From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com Update the hotplug documentation to explain that hotplug storm is not expected for Display port panels and hence is not handled in current code. v2: update the statements as recommended by Daniel Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com Queued for -next, thanks for the patch. -Daniel --- drivers/gpu/drm/i915/intel_hotplug.c |8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index bac91a1..3c9171f 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -66,6 +66,14 @@ * while before being re-enabled. The intention is to mitigate issues raising * from broken hardware triggering massive amounts of interrupts and grinding * the system to a halt. + * + * Current implementation expects that hotplug interrupt storm will not be + * seen when display port sink is connected, hence on platforms whose DP + * callback is handled by i915_digport_work_func reenabling of hpd is not + * performed (it was never expected to be disabled in the first place ;) ) + * this is specific to DP sinks handled by this routine and any other display + * such as HDMI or DVI enabled on the same port will have proper logic since + * it will use i915_hotplug_work_func where this logic is handled. */ enum port intel_hpd_pin_to_port(enum hpd_pin pin) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
On Mon, Jul 13, 2015 at 11:23:45AM +0200, Maarten Lankhorst wrote:
Op 13-07-15 om 11:13 schreef Daniel Vetter:
On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 22:12 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 19:52 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 10:55 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 18:43 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 14:10 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
wrote:
This allows the first atomic call during hw init to be a real
modeset,
which is useful for forcing a recalculation.
fbcon is optional, you can't rely on anything being done in any
specific
way. What exactly do you need this for, what's the implications?
In the hw readout I noticed some warnings when I wasn't setting
any mode property in the readout.
I want the first function to be the modeset, so we have a sane
base to commit changes on.
Ideally this whole function would have a atomic counterpart
which does it in one go. :)
Yeah. Otoh as soon as we have atomic modeset working we can
replace all
the legacy entry points with atomic helpers, and then even
plane_disable
will be a full atomic modeset.
What did fall apart with just touching properties/planes now?
Also when i915 is fully atomic it calculates in
intel_modeset_compute_config
if a modeset is needed after the first atomic call. Right now
because
intel_modeset_compute_config is only called in set_config so this
works as expected.
Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
and if the final mode is different this will introduce a double
modeset.
For expensive properties (i.e. a no-op changes causes something
that takes
time like modeset or vblank wait) we need to make sure we filter
them out
in atomic_check. Yeah not quite there yet with pure atomic, but
meanwhile
the existing legacy set_prop functions should all filter out no-op
changes
themselves. If we don't do that for rotation then that's a bug.
Same for disabling planes harder, that shouldn't take time.
Especially
since fbcon only force-disable non-primary plane, and for driver
load
that's the exact thing we already do in the driver anyway.
Something like this?
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a1d4e13f3908..2989232f4996 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
#include drm/drm_plane_helper.h
#include drm/drm_crtc_helper.h
#include drm/drm_atomic_helper.h
+#include drm_crtc_internal.h
#include linux/fence.h
/**
@@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
drm_crtc *crtc,
{
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
-int ret = 0;
+uint64_t retval;
+int ret;
+
+ret = drm_atomic_get_property(crtc-base, property, retval);
+if (!ret val == retval)
+return 0;
state = drm_atomic_state_alloc(crtc-dev);
if (!state)
@@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
drm_plane *plane,
{
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
-int ret = 0;
+uint64_t retval;
+int ret;
+
+ret = drm_atomic_get_property(plane-base, property, retval);
+if (!ret val == retval)
+return 0;
state = drm_atomic_state_alloc(plane-dev);
if (!state)
@@ -1836,7 +1847,12 @@
drm_atomic_helper_connector_set_property(struct drm_connector
*connector,
{
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
-int ret = 0;
+uint64_t retval;
+int ret;
+
+ret = drm_atomic_get_property(connector-base, property,
retval);
+if (!ret val == retval)
+return 0;
state = drm_atomic_state_alloc(connector-dev);
if (!state)
The reason I didn't do this is that a prop change might still result
in no
hw state change (e.g. if you go automitic-explicit setting matching
automatic one). Hence I think we need to solve this in lower levels
anyway, i.e. in when computing the config. But it shouldn't cause
trouble
yet.
Is that a ack or nack?
I think we shouldn't need this really for i915, and it might cover up
bugs. I prefer we just do the evade modeset logic you've implemented
once
we switch over to atomic props. Since atm
[Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect
During init_connector set the edid, then edid will be set/unset only during
hotplug. For the sake of older platforms where HPD is not stable, let edid
read happen from detect as well only if it is forced to do so.
v2: Removing the 'force' check, instead let detect call read the edid for
platforms older than gen 7 (Shashank)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 66af388..44e7160 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1399,6 +1399,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
enum drm_connector_status status;
struct intel_connector *intel_connector =
to_intel_connector(connector);
+ struct drm_device *dev = connector-dev;
DRM_DEBUG_KMS([CONNECTOR:%d:%s]\n,
connector-base.id, connector-name);
@@ -1412,7 +1413,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
* based on availability of cached EDID. This will avoid many of
* these race conditions and timing problems.
*/
- if (force)
+ if (INTEL_INFO(dev)-gen 7)
intel_hdmi_probe(intel_connector-encoder);
if (intel_connector-detect_edid) {
@@ -2070,6 +2071,9 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
drm_connector_register(connector);
intel_hdmi-attached_connector = intel_connector;
+ /* Set edid during init */
+ intel_hdmi_probe(intel_encoder);
+
/* For G4X desktop chip, PEG_BAND_GAP_DATA 3:0 must first be written
* 0xd. Failure to do so will result in spurious interrupts being
* generated on the port when a cable is not attached.
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection.
And remove the redundant comment.
v2: Remove redundant IS_BROXTON check, Add comment about port C not
connected, and rephrase the commit message to include only what we
are doing here (Imre)
v3: Add comment about the WA, move 'hpd' initialization outside for
loop (Siva)
Also, remove few redundant comments from hpd handler (me)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 46 ++-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a897f68..13cabca 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,14 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-/* BXT hpd list */
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and interrupts to check
+ * the external panel connection. Port C is not connected on bxt A0/A1
+ */
+static const u32 hpd_bxt_a0[HPD_NUM_PINS] = {
+ [HPD_PORT_B] = BXT_DE_PORT_HP_DDIA
+};
+
static const u32 hpd_bxt[HPD_NUM_PINS] = {
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
@@ -1967,6 +1974,7 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
struct drm_i915_private *dev_priv = dev-dev_private;
u32 hp_control, hp_trigger;
u32 pin_mask, long_mask;
+ const u32 *hpd;
/* Get the status */
hp_trigger = iir_status BXT_DE_PORT_HOTPLUG_MASK;
@@ -1981,7 +1989,12 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
/* Clear sticky bits in hpd status */
I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
- pch_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control,
hpd_bxt);
+ if (INTEL_REVID(dev) BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ pch_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control, hpd);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -3021,31 +3034,34 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
struct intel_encoder *intel_encoder;
u32 hotplug_port = 0;
u32 hotplug_ctrl;
+ const u32 *hpd;
- /* Now, enable HPD */
- for_each_intel_encoder(dev, intel_encoder) {
+ if (INTEL_REVID(dev) BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ for_each_intel_encoder(dev, intel_encoder)
if (dev_priv-hotplug.stats[intel_encoder-hpd_pin].state
== HPD_ENABLED)
- hotplug_port |= hpd_bxt[intel_encoder-hpd_pin];
- }
+ hotplug_port |= hpd[intel_encoder-hpd_pin];
- /* Mask all HPD control bits */
hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) ~BXT_HOTPLUG_CTL_MASK;
- /* Enable requested port in hotplug control */
/* TODO: implement (short) HPD support on port A */
- WARN_ON_ONCE(hotplug_port BXT_DE_PORT_HP_DDIA);
- if (hotplug_port BXT_DE_PORT_HP_DDIB)
- hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
- if (hotplug_port BXT_DE_PORT_HP_DDIC)
- hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ if (INTEL_REVID(dev) BXT_REVID_B0 (hotplug_port
BXT_DE_PORT_HP_DDIA))
+ hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
+ else {
+ if (hotplug_port BXT_DE_PORT_HP_DDIB)
+ hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
+ if (hotplug_port BXT_DE_PORT_HP_DDIC)
+ hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ }
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
- /* Unmask DDI hotplug in IMR */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR) ~hotplug_port;
I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
- /* Enable DDI hotplug in IER */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
POSTING_READ(GEN8_DE_PORT_IER);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Clear out DPLL state from pipe config in DSI get config
On Fri, Jul 10, 2015 at 05:37:07PM +0530, Sivakumar Thulasimani wrote: On 7/1/2015 6:12 PM, Daniel Vetter wrote: On Tue, Jun 30, 2015 at 02:50:33PM +0300, Ville Syrjälä wrote: On Tue, Jun 30, 2015 at 12:13:37PM +0200, Daniel Vetter wrote: On Mon, Jun 29, 2015 at 08:08:27PM +0300, Ville Syrjälä wrote: On Mon, Jun 29, 2015 at 07:56:05PM +0300, Ville Syrjälä wrote: On Mon, Jun 29, 2015 at 06:42:11PM +0200, Daniel Vetter wrote: On Mon, Jun 29, 2015 at 03:25:52PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com VLV/CHV don't use the DPLL with DSI, so just clear out the DPLL state from the pipe_config in intel_dsi_get_config(). This avoids spurious state checker warnings. We already did it this way for DPLL_MD, but do it for DPLL too. Toss in a WARN to intel_dsi_pre_enable() to make sure the ref clocks are enabled however. Supposedly they have some meaning to DSI too. We now keep the ref clocks always enabled while the disp2d well is enabled. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_dsi.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 36e2148..92bb252 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -421,18 +421,12 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder) /* Disable DPOunit clock gating, can stall pipe * and we need DPLL REFA always enabled */ - tmp = I915_READ(DPLL(pipe)); - tmp |= DPLL_REF_CLK_ENABLE_VLV; - I915_WRITE(DPLL(pipe), tmp); - - /* update the hw state for DPLL */ - intel_crtc-config-dpll_hw_state.dpll = DPLL_INTEGRATED_REF_CLK_VLV | - DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS; - tmp = I915_READ(DSPCLK_GATE_D); tmp |= DPOUNIT_CLOCK_GATE_DISABLE; I915_WRITE(DSPCLK_GATE_D, tmp); + WARN_ON((I915_READ(DPLL(pipe)) DPLL_REF_CLK_ENABLE_VLV) == 0); + /* put device in ready state */ intel_dsi_device_ready(encoder); @@ -635,9 +629,10 @@ static void intel_dsi_get_config(struct intel_encoder *encoder, DRM_DEBUG_KMS(\n); /* - * DPLL_MD is not used in case of DSI, reading will get some default value - * set dpll_md = 0 + * DPLL is not used in case of DSI, reading will getsome default value. + * Clear the state to keep the state checker happy. */ + pipe_config-dpll_hw_state.dpll = 0; pipe_config-dpll_hw_state.dpll_md = 0; State configs are supposed to be kzallocated. Needing this indicates a pretty serious bug - I'd vote to instead also ditch the dpll_md line and fix the offender. There is no offender really. We read out the DPLL state before we know which ports are active and hence can't tell at that point if the information is really relevant. So the bios leaves the DPLL enabled even when using a DSI port? Or do we miss to check some routing bits in get_clock? Not necessarily enabled, but there are other bits in there that could be left in any state basically. The DSI port simply doesn't care. If the enable bit is what's gating things here then we should just forgo reading out any dpll register state if that's not set. Looking at the vlv/chv state readout code that seems to be the trouble - there's nothing guarding the register reads into the pipe_config at all. Didn't matter pre-vlv without dsi since enable pipe should imply enabled dpll, but obviously won't work correctly with dsi. Can you please spin such a patch and remove the hacks here from dsi_get_config? -Daniel Not sure i understand the point of contention here, just noticed this after i gave my RB :) so my justification on why this is proper is that DSI is not supposed to touch DPLL register any place we access dpll_hw_state.dpll is under !is_dsi check so that ensures that we dont program DPLL register for dsi panel. it was wrong to have originally modfied DPLL register inside intel_dsi_pre_enable so removal is fine. setting it to zero in intel_dsi_get_config is of no impact since any place we write back the contents of dpll_hw_state is past the !is_dsi check is never consumed by anyone as long as the CRTC uses DSI. Ok, let's try a patch. Does the below work y/n? I've merged the patches up to this one to dinq meanwhile, but I'd really like to close this first. If it works I can rebase this patch here myself. Diff below is based on -nightly with the above patch, so if you want to test on top of it you also have to remove the dpll = 0; line too ofc. Thanks, Daniel diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a7482ab140e1..c770655f5612 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8079,6 +8079,10 @@ static bool
Re: [Intel-gfx] commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2 laptop reboots or hangs at boot time
Op 12-07-15 om 21:56 schreef Hans de Bruin: Daniel, commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2 causes my laptop to hang or reboot at the moment the kernel swiches the vido mode at boot time. I also noticed a warning while compiling: CC drivers/gpu/drm/i915/i915_gem_gtt.o /usr/src/linux.bisect/drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_init': /usr/src/linux.bisect/drivers/gpu/drm/i915/i915_gem_gtt.c:954:2: warning: large integer implicitly truncated to unsigned type [-Woverflow] ppgtt-base.total = 1ULL 32; ^ It might be related, or not. http://lists.freedesktop.org/archives/dri-devel/2015-July/086263.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 33/36] drivers/gpu/drm/bochs/bochs_fbdev.c:63:17: warning: unused variable 'device'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3
commit: 394111a2b303c49b3a6c123320d08173588a1b37 [33/36] drm/boschs: Use new
drm_fb_helper functions
config: x86_64-randconfig-i0-201528 (attached as .config)
reproduce:
git checkout 394111a2b303c49b3a6c123320d08173588a1b37
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by ):
drivers/gpu/drm/bochs/bochs_fbdev.c: In function 'bochsfb_create':
drivers/gpu/drm/bochs/bochs_fbdev.c:63:17: warning: unused variable 'device'
[-Wunused-variable]
struct device *device = dev-pdev-dev;
^
vim +/device +63 drivers/gpu/drm/bochs/bochs_fbdev.c
0a6659bd Gerd Hoffmann 2013-12-17 47 if (ret)
0a6659bd Gerd Hoffmann 2013-12-17 48 return ret;
0a6659bd Gerd Hoffmann 2013-12-17 49
0a6659bd Gerd Hoffmann 2013-12-17 50 *gobj_p = gobj;
0a6659bd Gerd Hoffmann 2013-12-17 51 return ret;
0a6659bd Gerd Hoffmann 2013-12-17 52 }
0a6659bd Gerd Hoffmann 2013-12-17 53
0a6659bd Gerd Hoffmann 2013-12-17 54 static int bochsfb_create(struct
drm_fb_helper *helper,
0a6659bd Gerd Hoffmann 2013-12-17 55 struct
drm_fb_helper_surface_size *sizes)
0a6659bd Gerd Hoffmann 2013-12-17 56 {
0a6659bd Gerd Hoffmann 2013-12-17 57 struct bochs_device *bochs =
0a6659bd Gerd Hoffmann 2013-12-17 58 container_of(helper, struct
bochs_device, fb.helper);
0a6659bd Gerd Hoffmann 2013-12-17 59 struct drm_device *dev = bochs-dev;
0a6659bd Gerd Hoffmann 2013-12-17 60 struct fb_info *info;
0a6659bd Gerd Hoffmann 2013-12-17 61 struct drm_framebuffer *fb;
0a6659bd Gerd Hoffmann 2013-12-17 62 struct drm_mode_fb_cmd2 mode_cmd;
0a6659bd Gerd Hoffmann 2013-12-17 @63 struct device *device = dev-pdev-dev;
0a6659bd Gerd Hoffmann 2013-12-17 64 struct drm_gem_object *gobj = NULL;
0a6659bd Gerd Hoffmann 2013-12-17 65 struct bochs_bo *bo = NULL;
0a6659bd Gerd Hoffmann 2013-12-17 66 int size, ret;
0a6659bd Gerd Hoffmann 2013-12-17 67
0a6659bd Gerd Hoffmann 2013-12-17 68 if (sizes-surface_bpp != 32)
0a6659bd Gerd Hoffmann 2013-12-17 69 return -EINVAL;
0a6659bd Gerd Hoffmann 2013-12-17 70
0a6659bd Gerd Hoffmann 2013-12-17 71 mode_cmd.width = sizes-surface_width;
:: The code at line 63 was first introduced by commit
:: 0a6659bdc5e8221da99eebb176fd9591435e38de drm/bochs: new driver
:: TO: Gerd Hoffmann kra...@redhat.com
:: CC: Dave Airlie airl...@redhat.com
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.1.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME=(none)
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: fix ban tests with scheduler
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, July 13, 2015 10:35 AM
To: Gore, Tim
Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas; Kuoppala, Mika
Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: fix ban
tests
with scheduler
On Fri, Jul 10, 2015 at 02:26:59PM +0100, tim.g...@intel.com wrote:
From: Tim Gore tim.g...@intel.com
The tests for context banning fail when the gpu scheduler is enabled.
The test causes a hang (using an infinite loop
batch) and then queues up some work behind it on both the hanging
context and also on a second good context. On the good context it
queues up 2 batch buffers. After the hanging ring has been reset (not
a full gpu reset) the test checks the values of batch_active and
batch_pending returned by the i915_get_reset_stats_ioctl. For the
good
context it expects to see batch_pending == 2, because two batch
buffers we queued up behind the hang on this context. But, with the
scheduler enabled (android, gen8), one of these batch buffers is still
waiting in the scheduler and has not made it as far as the
ring-request_list, so this batch buffer is unaffected by
the ring reset, and batch_pending is only 1.
I considered putting in a test for the scheduler being enabled, but
decided that a simpler solution is to only queue up 1 batch buffer on
the good context. This does not change the test logic in any way and
ensures that we should always have batch_pending=1, with or without
the scheduler.
For the scheduler/tdr we probably need to split this up into two testcases
each:
- one where the 2nd batch depends upon the first (cross-context depency).
- one where the 2nd batch doesn't depend upon the first (should execute
unhampered with scheduler/tdr).
Since we don't yet have a scheduler/tdr both of these will result in the same
outcome (since there's always the temporal depency). But with your patch
you only test the 2nd case (and incompletely, we should assert that the 2nd
batch did run) and ignore the first case.
In short this failure here is telling you that your test coverage for these
features is lacking. The correct fix is not to mangle the existing, but fix
it up to
correctly cover the new expectations in all cases. And that should be done as
part of the tdr/scheduler submission.
-Daniel
Should gem_rest_stats be testing the operation of the scheduler? I would have
thought that the scheduler operation should have its own test(s).
Gem_reset_stats
is just about the reset mechanism and the stats collected. I can add this test,
just
seems like the wrong place.
Tim
Signed-off-by: Tim Gore tim.g...@intel.com
---
tests/gem_reset_stats.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c index
2bb4291..6529463 100644
--- a/tests/gem_reset_stats.c
+++ b/tests/gem_reset_stats.c
@@ -468,7 +468,7 @@ static void test_rs_ctx(int num_fds, int num_ctx,
int hang_index,
static void test_ban(void)
{
- int h1,h2,h3,h4,h5,h6,h7;
+ int h1,h2,h3,h4,h5,h6;
int fd_bad, fd_good;
int retry = 10;
int active_count = 0, pending_count = 0; @@ -496,7 +496,6 @@ static
void test_ban(void)
pending_count++;
h6 = exec_valid(fd_good, 0);
- h7 = exec_valid(fd_good, 0);
while (retry--) {
h3 = inject_hang_no_ban_error(fd_bad, 0); @@ -525,7
+524,7 @@ static void test_ban(void)
igt_assert_eq(h4, -EIO);
assert_reset_status(fd_bad, 0, RS_BATCH_ACTIVE);
- gem_sync(fd_good, h7);
+ gem_sync(fd_good, h6);
assert_reset_status(fd_good, 0, RS_BATCH_PENDING);
igt_assert_eq(gem_reset_stats(fd_good, 0, rs_good), 0); @@ -
534,12
+533,11 @@ static void test_ban(void)
igt_assert(rs_bad.batch_active == active_count);
igt_assert(rs_bad.batch_pending == pending_count);
igt_assert(rs_good.batch_active == 0);
- igt_assert(rs_good.batch_pending == 2);
+ igt_assert(rs_good.batch_pending == 1);
gem_close(fd_bad, h1);
gem_close(fd_bad, h2);
gem_close(fd_good, h6);
- gem_close(fd_good, h7);
h1 = exec_valid(fd_good, 0);
igt_assert_lte(0, h1);
@@ -554,7 +552,7 @@ static void test_ban(void)
static void test_ban_ctx(void)
{
- int h1,h2,h3,h4,h5,h6,h7;
+ int h1,h2,h3,h4,h5,h6;
int ctx_good, ctx_bad;
int fd;
int retry = 10;
@@ -587,7 +585,6 @@ static void test_ban_ctx(void)
pending_count++;
h6 = exec_valid(fd, ctx_good);
- h7 = exec_valid(fd, ctx_good);
while (retry--) {
h3 = inject_hang_no_ban_error(fd, ctx_bad); @@ -616,7
+613,7 @@ static void test_ban_ctx(void)
igt_assert_eq(h4, -EIO);
Re: [Intel-gfx] [PATCH] drm/i915: Adjust BXT HDMI port clock limits
On Fri, Jul 10, 2015 at 02:27:48PM +0100, Damien Lespiau wrote: On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote: On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote: On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: On ma, 2015-07-06 at 14:44 +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Since commit e62925567c7926e78bc8ca976cde5c28ea265a49 Author: Vandana Kannan vandana.kan...@intel.com Date: Wed Jul 1 17:02:57 2015 +0530 drm/i915/bxt: BUNs related to port PLL BXT DPLL can now generate frequencies in the 216-223 MHz range. Adjust the HDMI port clock checks to account for the reduced range of invalid frequencies. Cc: Vandana Kannan vandana.kan...@intel.com Cc: Imre Deak imre.d...@intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Ville wrote a tool for CHV that calculates the valid frequencies based on the algorithm in the kernel. With the help of that I verified that this matches the list of target frequencies bxt_find_best_dpll() will accept, so: Could we have that tool in i-g-t? We could lift all the .find_dpll routines from the kernel into i-g-t. The only real concern is that we'll forget to update the i-g-t copies when changing the kernel. But I guess it would still be easier to just update them slightly when noticing that rather than having to lift them from the kernel all over again. Right, while not ideal, I think having something in i-g-t, even if it diverges slightly (but then we can remind the patch author to update the i-g-t tool during review) is still better than not having that code around at all. Another way to check this would be to inject EDIDs with hand-rolled timings that increment in small steps. Then we can try modesets on all the unfiltered ones vs. just manually adding it with addmode. If any mode gets filtered inconsistently in the mode list parsing compared to modeset code that would be a bug. Unfortunately the hdmi injection stuff isn't ready yet. I'll create a jira for this idea. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: Add gen check for fb size
On Fri, Jul 10, 2015 at 04:45:12PM +0530, Vandana Kannan wrote:
From gen7, the platform can support fb of size 3x3.
Adding this check for gen along with fb width height.
Note: IVB is gen7 but its not clear if it can support width 3 and
height 3.
This patch has been tested in Android environment.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
What exactly are you usinga 3x3 framebuffer for? Imo this needs userspace
plus igt testcases and all that, but really not sure why this would be
worth it ever.
-Daniel
---
drivers/gpu/drm/i915/intel_sprite.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index cd21525..310d0a7 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -770,8 +770,13 @@ intel_check_sprite_plane(struct drm_plane *plane,
return -EINVAL;
}
+ if (INTEL_INFO(dev)-gen 7 (fb-width 3 || fb-height 3)) {
+ DRM_DEBUG_KMS(Unsuitable framebuffer for plane\n);
+ return -EINVAL;
+ }
+
/* FIXME check all gen limits */
- if (fb-width 3 || fb-height 3 || fb-pitches[0] 16384) {
+ if (fb-pitches[0] 16384) {
DRM_DEBUG_KMS(Unsuitable framebuffer for plane\n);
return -EINVAL;
}
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Op 13-07-15 om 11:13 schreef Daniel Vetter:
On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 22:12 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 19:52 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 10:55 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 18:43 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 14:10 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
This allows the first atomic call during hw init to be a real
modeset,
which is useful for forcing a recalculation.
fbcon is optional, you can't rely on anything being done in any
specific
way. What exactly do you need this for, what's the implications?
In the hw readout I noticed some warnings when I wasn't setting
any mode property in the readout.
I want the first function to be the modeset, so we have a sane
base to commit changes on.
Ideally this whole function would have a atomic counterpart which
does it in one go. :)
Yeah. Otoh as soon as we have atomic modeset working we can replace
all
the legacy entry points with atomic helpers, and then even
plane_disable
will be a full atomic modeset.
What did fall apart with just touching properties/planes now?
Also when i915 is fully atomic it calculates in
intel_modeset_compute_config
if a modeset is needed after the first atomic call. Right now because
intel_modeset_compute_config is only called in set_config so this
works as expected.
Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
and if the final mode is different this will introduce a double
modeset.
For expensive properties (i.e. a no-op changes causes something that
takes
time like modeset or vblank wait) we need to make sure we filter them
out
in atomic_check. Yeah not quite there yet with pure atomic, but
meanwhile
the existing legacy set_prop functions should all filter out no-op
changes
themselves. If we don't do that for rotation then that's a bug.
Same for disabling planes harder, that shouldn't take time. Especially
since fbcon only force-disable non-primary plane, and for driver load
that's the exact thing we already do in the driver anyway.
Something like this?
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a1d4e13f3908..2989232f4996 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
#include drm/drm_plane_helper.h
#include drm/drm_crtc_helper.h
#include drm/drm_atomic_helper.h
+#include drm_crtc_internal.h
#include linux/fence.h
/**
@@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
drm_crtc *crtc,
{
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(crtc-base, property, retval);
+ if (!ret val == retval)
+ return 0;
state = drm_atomic_state_alloc(crtc-dev);
if (!state)
@@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
drm_plane *plane,
{
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(plane-base, property, retval);
+ if (!ret val == retval)
+ return 0;
state = drm_atomic_state_alloc(plane-dev);
if (!state)
@@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
drm_connector *connector,
{
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(connector-base, property,
retval);
+ if (!ret val == retval)
+ return 0;
state = drm_atomic_state_alloc(connector-dev);
if (!state)
The reason I didn't do this is that a prop change might still result in
no
hw state change (e.g. if you go automitic-explicit setting matching
automatic one). Hence I think we need to solve this in lower levels
anyway, i.e. in when computing the config. But it shouldn't cause
trouble
yet.
Is that a ack or nack?
I think we shouldn't need this really for i915, and it might cover up
bugs. I prefer we just do the evade modeset logic you've implemented once
we switch over to atomic props. Since atm we only have atomic props which
get updated in pageflips we shouldn't have serious problems here yet (for
setting the rotation prop to 0° again when
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't forget to mark crtc as inactive after disable
On Mon, Jul 13, 2015 at 11:10:51AM +0200, Maarten Lankhorst wrote: Op 10-07-15 om 13:22 schreef Damien Lespiau: Hi Patrik, Please do Cc the patch author and reviewer when finding a regression, they are superb candidates for the review, especially when they are busy rewriting the display code. Yeah you need to list everyone you want to Cc: explicitly. On Wed, Jul 08, 2015 at 03:31:52PM +0200, Patrik Jakobsson wrote: Watermark calculations depend on the intel_crtc-active flag to be set properly. Suspend/resume is broken on SKL and we also get DDB mismatches without this patch. The regression was introduced in: commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 Author: Maarten Lankhorst maarten.lankho...@linux.intel.com Date: Mon Jun 15 12:33:53 2015 +0200 drm/i915: Update less state during modeset. No need to repeatedly call update_watermarks, or update_fbc. Down to a single call to update_watermarks in .crtc_enable Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com Reviewed-by: Matt Roper matthew.d.ro...@intel.com Tested-by(IVB): Matt Roper matthew.d.ro...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch v2: Don't touch disable_shared_dpll() Signed-off-by: Patrik Jakobsson patrik.jakobs...@linux.intel.com We do need to update the watermarks in disable() as well, to repartition the DDB and update the watermarks based on the new allocation. Maarten, Matt, I've no clue where you want the crtc state update, where the atomic WM work is at, could you comment? I'd rather have we had a better way of updating watermarks, but keeping it in the .crtc_disable hook looks good to me right now. Some proper atomic solution will eventually have to be done. :) Reviewed-by: Maarten Lankhorst maarten.lankho...@linux.intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 09/20] drm/i915: Fill in more crtc state, v2.
On Mon, Jul 13, 2015 at 11:32:09AM +0200, Maarten Lankhorst wrote: Op 07-07-15 om 12:28 schreef Daniel Vetter: On Tue, Jul 07, 2015 at 09:08:20AM +0200, Maarten Lankhorst wrote: Perform a full readout of the state by making sure the mode is set up correctly atomically. Also there was a small memory leak by doing the memset, fix this by calling __drm_atomic_helper_crtc_destroy_state first. Changes since v1: - Moved after reworking primary plane and updating mode members. - Force a modeset calculation by changing mode-type from what the final mode will be. Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com tbh I don't really like mode_from_pipe_config since it goes in reverse. With the adjust mode of config_compare we can compare different final hw states and make a call whether they match enough for modeset avoidance or not. mode_from_pipe_config otoh is a lie on panels where we can do upscaling, hence I'd like to remove it to avoid confusion. What do you want the initial mode to be then? You need to fill in some mode to satisfy drm_atomic_crtc_check. All zeros? That would make it clear that we have a mode, and that we also have no idea really what it is ... Otoh I think you've convinced me now that we indeed do need a real mode object here to avoid other troubles (i.e. the entire discussion around initial fbcon modesets). Given that I'd guess even the slightly wrong fill_in_modes here with the change to set DRIVER_MODE would be ok. As long as we can guarantee that we'll get a full modeset eventually we should be fine I hope. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Clear out DPLL state from pipe config in DSI get config
On 7/13/2015 2:21 PM, Daniel Vetter wrote: On Fri, Jul 10, 2015 at 05:37:07PM +0530, Sivakumar Thulasimani wrote: On 7/1/2015 6:12 PM, Daniel Vetter wrote: On Tue, Jun 30, 2015 at 02:50:33PM +0300, Ville Syrjälä wrote: On Tue, Jun 30, 2015 at 12:13:37PM +0200, Daniel Vetter wrote: On Mon, Jun 29, 2015 at 08:08:27PM +0300, Ville Syrjälä wrote: On Mon, Jun 29, 2015 at 07:56:05PM +0300, Ville Syrjälä wrote: On Mon, Jun 29, 2015 at 06:42:11PM +0200, Daniel Vetter wrote: On Mon, Jun 29, 2015 at 03:25:52PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com VLV/CHV don't use the DPLL with DSI, so just clear out the DPLL state from the pipe_config in intel_dsi_get_config(). This avoids spurious state checker warnings. We already did it this way for DPLL_MD, but do it for DPLL too. Toss in a WARN to intel_dsi_pre_enable() to make sure the ref clocks are enabled however. Supposedly they have some meaning to DSI too. We now keep the ref clocks always enabled while the disp2d well is enabled. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_dsi.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 36e2148..92bb252 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -421,18 +421,12 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder) /* Disable DPOunit clock gating, can stall pipe * and we need DPLL REFA always enabled */ - tmp = I915_READ(DPLL(pipe)); - tmp |= DPLL_REF_CLK_ENABLE_VLV; - I915_WRITE(DPLL(pipe), tmp); - - /* update the hw state for DPLL */ - intel_crtc-config-dpll_hw_state.dpll = DPLL_INTEGRATED_REF_CLK_VLV | - DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS; - tmp = I915_READ(DSPCLK_GATE_D); tmp |= DPOUNIT_CLOCK_GATE_DISABLE; I915_WRITE(DSPCLK_GATE_D, tmp); + WARN_ON((I915_READ(DPLL(pipe)) DPLL_REF_CLK_ENABLE_VLV) == 0); + /* put device in ready state */ intel_dsi_device_ready(encoder); @@ -635,9 +629,10 @@ static void intel_dsi_get_config(struct intel_encoder *encoder, DRM_DEBUG_KMS(\n); /* -* DPLL_MD is not used in case of DSI, reading will get some default value -* set dpll_md = 0 +* DPLL is not used in case of DSI, reading will getsome default value. +* Clear the state to keep the state checker happy. */ + pipe_config-dpll_hw_state.dpll = 0; pipe_config-dpll_hw_state.dpll_md = 0; State configs are supposed to be kzallocated. Needing this indicates a pretty serious bug - I'd vote to instead also ditch the dpll_md line and fix the offender. There is no offender really. We read out the DPLL state before we know which ports are active and hence can't tell at that point if the information is really relevant. So the bios leaves the DPLL enabled even when using a DSI port? Or do we miss to check some routing bits in get_clock? Not necessarily enabled, but there are other bits in there that could be left in any state basically. The DSI port simply doesn't care. If the enable bit is what's gating things here then we should just forgo reading out any dpll register state if that's not set. Looking at the vlv/chv state readout code that seems to be the trouble - there's nothing guarding the register reads into the pipe_config at all. Didn't matter pre-vlv without dsi since enable pipe should imply enabled dpll, but obviously won't work correctly with dsi. Can you please spin such a patch and remove the hacks here from dsi_get_config? -Daniel Not sure i understand the point of contention here, just noticed this after i gave my RB :) so my justification on why this is proper is that DSI is not supposed to touch DPLL register any place we access dpll_hw_state.dpll is under !is_dsi check so that ensures that we dont program DPLL register for dsi panel. it was wrong to have originally modfied DPLL register inside intel_dsi_pre_enable so removal is fine. setting it to zero in intel_dsi_get_config is of no impact since any place we write back the contents of dpll_hw_state is past the !is_dsi check is never consumed by anyone as long as the CRTC uses DSI. Ok, let's try a patch. Does the below work y/n? I've merged the patches up to this one to dinq meanwhile, but I'd really like to close this first. If it works I can rebase this patch here myself. Diff below is based on -nightly with the above patch, so if you want to test on top of it you also have to remove the dpll = 0; line too ofc. Thanks, Daniel diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a7482ab140e1..c770655f5612 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8079,6 +8079,10 @@ static bool i9xx_get_pipe_config(struct
[Intel-gfx] [drm-intel:topic/drm-misc 26/36] drivers/gpu/drm//gma500/framebuffer.c:346:17: warning: unused variable 'device'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3
commit: 3b9a13e85365c441dc7335d81afc0a3a344766e6 [26/36] drm/gma500: Use new
drm_fb_helper functions
config: x86_64-randconfig-i0-201528 (attached as .config)
reproduce:
git checkout 3b9a13e85365c441dc7335d81afc0a3a344766e6
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by ):
drivers/gpu/drm//gma500/framebuffer.c: In function 'psbfb_create':
drivers/gpu/drm//gma500/framebuffer.c:346:17: warning: unused variable
'device' [-Wunused-variable]
struct device *device = dev-pdev-dev;
^
vim +/device +346 drivers/gpu/drm//gma500/framebuffer.c
4d8d096e Alan Cox2011-11-03 330 /**
4d8d096e Alan Cox2011-11-03 331 *psbfb_create-
create a framebuffer
4d8d096e Alan Cox2011-11-03 332 *@fbdev: the framebuffer device
4d8d096e Alan Cox2011-11-03 333 *@sizes: specification of the
layout
4d8d096e Alan Cox2011-11-03 334 *
4d8d096e Alan Cox2011-11-03 335 *Create a framebuffer to the
specifications provided
4d8d096e Alan Cox2011-11-03 336 */
4d8d096e Alan Cox2011-11-03 337 static int psbfb_create(struct psb_fbdev
*fbdev,
4d8d096e Alan Cox2011-11-03 338struct
drm_fb_helper_surface_size *sizes)
4d8d096e Alan Cox2011-11-03 339 {
4d8d096e Alan Cox2011-11-03 340struct drm_device *dev =
fbdev-psb_fb_helper.dev;
4d8d096e Alan Cox2011-11-03 341struct drm_psb_private *dev_priv =
dev-dev_private;
4d8d096e Alan Cox2011-11-03 342struct fb_info *info;
4d8d096e Alan Cox2011-11-03 343struct drm_framebuffer *fb;
4d8d096e Alan Cox2011-11-03 344struct psb_framebuffer *psbfb =
fbdev-pfb;
a9a644ac Dave Airlie 2011-11-28 345struct drm_mode_fb_cmd2 mode_cmd;
4d8d096e Alan Cox2011-11-03 @346struct device *device = dev-pdev-dev;
4d8d096e Alan Cox2011-11-03 347int size;
4d8d096e Alan Cox2011-11-03 348int ret;
4d8d096e Alan Cox2011-11-03 349struct gtt_range *backing;
a9a644ac Dave Airlie 2011-11-28 350u32 bpp, depth;
1b223c9e Alan Cox2011-11-29 351int gtt_roll = 0;
1b223c9e Alan Cox2011-11-29 352int pitch_lines = 0;
4d8d096e Alan Cox2011-11-03 353
4d8d096e Alan Cox2011-11-03 354mode_cmd.width = sizes-surface_width;
:: The code at line 346 was first introduced by commit
:: 4d8d096e9ae86621cc38b5417f4353305c5fd3a9 gma500: introduce the
framebuffer support code
:: TO: Alan Cox a...@linux.intel.com
:: CC: Dave Airlie airl...@redhat.com
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.1.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME=(none)
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
Re: [Intel-gfx] [PATCH v2 09/20] drm/i915: Fill in more crtc state, v2.
Op 07-07-15 om 12:28 schreef Daniel Vetter: On Tue, Jul 07, 2015 at 09:08:20AM +0200, Maarten Lankhorst wrote: Perform a full readout of the state by making sure the mode is set up correctly atomically. Also there was a small memory leak by doing the memset, fix this by calling __drm_atomic_helper_crtc_destroy_state first. Changes since v1: - Moved after reworking primary plane and updating mode members. - Force a modeset calculation by changing mode-type from what the final mode will be. Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com tbh I don't really like mode_from_pipe_config since it goes in reverse. With the adjust mode of config_compare we can compare different final hw states and make a call whether they match enough for modeset avoidance or not. mode_from_pipe_config otoh is a lie on panels where we can do upscaling, hence I'd like to remove it to avoid confusion. What do you want the initial mode to be then? You need to fill in some mode to satisfy drm_atomic_crtc_check. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: fix ban tests with scheduler
On Fri, Jul 10, 2015 at 02:26:59PM +0100, tim.g...@intel.com wrote:
From: Tim Gore tim.g...@intel.com
The tests for context banning fail when the gpu scheduler
is enabled. The test causes a hang (using an infinite loop
batch) and then queues up some work behind it on both the
hanging context and also on a second good context. On
the good context it queues up 2 batch buffers. After the
hanging ring has been reset (not a full gpu reset) the
test checks the values of batch_active and batch_pending
returned by the i915_get_reset_stats_ioctl. For the good
context it expects to see batch_pending == 2, because two
batch buffers we queued up behind the hang on this
context. But, with the scheduler enabled (android, gen8),
one of these batch buffers is still waiting in the
scheduler and has not made it as far as the
ring-request_list, so this batch buffer is unaffected by
the ring reset, and batch_pending is only 1.
I considered putting in a test for the scheduler being
enabled, but decided that a simpler solution is to only
queue up 1 batch buffer on the good context. This does
not change the test logic in any way and ensures that we
should always have batch_pending=1, with or without the
scheduler.
For the scheduler/tdr we probably need to split this up into two testcases
each:
- one where the 2nd batch depends upon the first (cross-context depency).
- one where the 2nd batch doesn't depend upon the first (should execute
unhampered with scheduler/tdr).
Since we don't yet have a scheduler/tdr both of these will result in the
same outcome (since there's always the temporal depency). But with your
patch you only test the 2nd case (and incompletely, we should assert that
the 2nd batch did run) and ignore the first case.
In short this failure here is telling you that your test coverage for
these features is lacking. The correct fix is not to mangle the existing,
but fix it up to correctly cover the new expectations in all cases. And
that should be done as part of the tdr/scheduler submission.
-Daniel
Signed-off-by: Tim Gore tim.g...@intel.com
---
tests/gem_reset_stats.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
index 2bb4291..6529463 100644
--- a/tests/gem_reset_stats.c
+++ b/tests/gem_reset_stats.c
@@ -468,7 +468,7 @@ static void test_rs_ctx(int num_fds, int num_ctx, int
hang_index,
static void test_ban(void)
{
- int h1,h2,h3,h4,h5,h6,h7;
+ int h1,h2,h3,h4,h5,h6;
int fd_bad, fd_good;
int retry = 10;
int active_count = 0, pending_count = 0;
@@ -496,7 +496,6 @@ static void test_ban(void)
pending_count++;
h6 = exec_valid(fd_good, 0);
- h7 = exec_valid(fd_good, 0);
while (retry--) {
h3 = inject_hang_no_ban_error(fd_bad, 0);
@@ -525,7 +524,7 @@ static void test_ban(void)
igt_assert_eq(h4, -EIO);
assert_reset_status(fd_bad, 0, RS_BATCH_ACTIVE);
- gem_sync(fd_good, h7);
+ gem_sync(fd_good, h6);
assert_reset_status(fd_good, 0, RS_BATCH_PENDING);
igt_assert_eq(gem_reset_stats(fd_good, 0, rs_good), 0);
@@ -534,12 +533,11 @@ static void test_ban(void)
igt_assert(rs_bad.batch_active == active_count);
igt_assert(rs_bad.batch_pending == pending_count);
igt_assert(rs_good.batch_active == 0);
- igt_assert(rs_good.batch_pending == 2);
+ igt_assert(rs_good.batch_pending == 1);
gem_close(fd_bad, h1);
gem_close(fd_bad, h2);
gem_close(fd_good, h6);
- gem_close(fd_good, h7);
h1 = exec_valid(fd_good, 0);
igt_assert_lte(0, h1);
@@ -554,7 +552,7 @@ static void test_ban(void)
static void test_ban_ctx(void)
{
- int h1,h2,h3,h4,h5,h6,h7;
+ int h1,h2,h3,h4,h5,h6;
int ctx_good, ctx_bad;
int fd;
int retry = 10;
@@ -587,7 +585,6 @@ static void test_ban_ctx(void)
pending_count++;
h6 = exec_valid(fd, ctx_good);
- h7 = exec_valid(fd, ctx_good);
while (retry--) {
h3 = inject_hang_no_ban_error(fd, ctx_bad);
@@ -616,7 +613,7 @@ static void test_ban_ctx(void)
igt_assert_eq(h4, -EIO);
assert_reset_status(fd, ctx_bad, RS_BATCH_ACTIVE);
- gem_sync(fd, h7);
+ gem_sync(fd, h6);
assert_reset_status(fd, ctx_good, RS_BATCH_PENDING);
igt_assert_eq(gem_reset_stats(fd, ctx_good, rs_good), 0);
@@ -625,12 +622,11 @@ static void test_ban_ctx(void)
igt_assert(rs_bad.batch_active == active_count);
igt_assert(rs_bad.batch_pending == pending_count);
igt_assert(rs_good.batch_active == 0);
- igt_assert(rs_good.batch_pending == 2);
+ igt_assert(rs_good.batch_pending == 1);
gem_close(fd, h1);
gem_close(fd, h2);
gem_close(fd, h6);
- gem_close(fd, h7);
h1 = exec_valid(fd, ctx_good);
igt_assert_lte(0, h1);
--
1.9.1
Re: [Intel-gfx] [RFC 0/2] Add Pooled EU support
Arun Siluvery arun.siluv...@linux.intel.com writes: These patches enabled Pooled EU support for BXT, they are implemented by Armin Reese. I am sending these patches in its current form for comments. These patches modify Golden batch to have a set of modification values where we can change the commands based on Gen. The commands to enable Pooled EU are inserted after MI_BATCH_BUFFER_END. If the given Gen supports this feature, modification values are used to replace MI_BATCH_BUFFER_END so we send commands to enable Pooled EU. These commands need to be part of this batch because they are to be initialized only once. Userspace will have option to query the availability of this feature, those changes are not included in this series. I would like to upstream this feature and really appreciate any comments in this regard. Latest command stream programming guide has this to say in context initialization: Render CS Only: Render state need not be initialized If it is so that we get a proper render state from hw, with 'Restore Inhibit', then we can get rid of golden context for skl+. -Mika Armin Reese (2): drm/i915: Offsets for golden context BB modification drm/i915/bxt: Enable pooled EUs for BXT drivers/gpu/drm/i915/i915_gem_render_state.c | 125 +- drivers/gpu/drm/i915/i915_gem_render_state.h | 7 ++ drivers/gpu/drm/i915/intel_renderstate.h | 6 +- drivers/gpu/drm/i915/intel_renderstate_gen6.c | 4 + drivers/gpu/drm/i915/intel_renderstate_gen7.c | 4 + drivers/gpu/drm/i915/intel_renderstate_gen8.c | 4 + drivers/gpu/drm/i915/intel_renderstate_gen9.c | 18 ++-- 7 files changed, 157 insertions(+), 11 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
On 7/13/2015 3:10 PM, Daniel Vetter wrote:
On Mon, Jul 13, 2015 at 02:10:09PM +0530, Sonika Jindal wrote:
As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection.
And remove the redundant comment.
v2: Remove redundant IS_BROXTON check, Add comment about port C not
connected, and rephrase the commit message to include only what we
are doing here (Imre)
v3: Add comment about the WA, move 'hpd' initialization outside for
loop (Siva)
Also, remove few redundant comments from hpd handler (me)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Can't we do this in two steps:
- Wire up port A hpd in a generic way.
- Add wa for bxt to use port A hpd in the various encoder setup functions
where we assign intel_encoder-hpd_pin.
Currently that switchover is spread all through low-level functions, which
makes this a bit confusion. Imo low-level code shouldn't treat hpd A as
anything but hpd A since that's just confusing. And we already have the
infrastructure for encoders to ask for any hpd pin they want really.
-Daniel
---
drivers/gpu/drm/i915/i915_irq.c | 46 ++-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a897f68..13cabca 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,14 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-/* BXT hpd list */
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and interrupts to check
+ * the external panel connection. Port C is not connected on bxt A0/A1
+ */
+static const u32 hpd_bxt_a0[HPD_NUM_PINS] = {
+ [HPD_PORT_B] = BXT_DE_PORT_HP_DDIA
+};
+
static const u32 hpd_bxt[HPD_NUM_PINS] = {
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
@@ -1967,6 +1974,7 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
struct drm_i915_private *dev_priv = dev-dev_private;
u32 hp_control, hp_trigger;
u32 pin_mask, long_mask;
+ const u32 *hpd;
/* Get the status */
hp_trigger = iir_status BXT_DE_PORT_HOTPLUG_MASK;
@@ -1981,7 +1989,12 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
/* Clear sticky bits in hpd status */
I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
- pch_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control, hpd_bxt);
+ if (INTEL_REVID(dev) BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ pch_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control, hpd);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -3021,31 +3034,34 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
struct intel_encoder *intel_encoder;
u32 hotplug_port = 0;
u32 hotplug_ctrl;
+ const u32 *hpd;
- /* Now, enable HPD */
- for_each_intel_encoder(dev, intel_encoder) {
+ if (INTEL_REVID(dev) BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ for_each_intel_encoder(dev, intel_encoder)
if (dev_priv-hotplug.stats[intel_encoder-hpd_pin].state
== HPD_ENABLED)
- hotplug_port |= hpd_bxt[intel_encoder-hpd_pin];
- }
+ hotplug_port |= hpd[intel_encoder-hpd_pin];
- /* Mask all HPD control bits */
hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) ~BXT_HOTPLUG_CTL_MASK;
- /* Enable requested port in hotplug control */
/* TODO: implement (short) HPD support on port A */
- WARN_ON_ONCE(hotplug_port BXT_DE_PORT_HP_DDIA);
- if (hotplug_port BXT_DE_PORT_HP_DDIB)
- hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
- if (hotplug_port BXT_DE_PORT_HP_DDIC)
- hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ if (INTEL_REVID(dev) BXT_REVID_B0 (hotplug_port
BXT_DE_PORT_HP_DDIA))
+ hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
+ else {
+ if (hotplug_port BXT_DE_PORT_HP_DDIB)
+ hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
+ if (hotplug_port BXT_DE_PORT_HP_DDIC)
+ hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ }
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
- /* Unmask DDI hotplug in IMR */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR) ~hotplug_port;
I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
- /* Enable DDI hotplug in IER */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
POSTING_READ(GEN8_DE_PORT_IER);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect
On Mon, Jul 13, 2015 at 04:19:15PM +0530, Sonika Jindal wrote: During init_connector set the edid, then edid will be set/unset only during hotplug. For the sake of older platforms where HPD is not stable, let edid read happen from detect as well only if it is forced to do so. v2: Removing the 'force' check, instead let detect call read the edid for platforms older than gen 7 (Shashank) That's enough worse. We now have a random gen check with no rationale for why you suddenly believe all manufacturers have fixed their wiring. There is no reason to believe that gen7 suddenly works is there? If there is, why don't you mention it? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 27/36] drivers/gpu/drm/mgag200/mgag200_fb.c:232:1: warning: label 'out' defined but not used
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3
commit: 53ebb642ccba1212b7b97a5dccb358eb791b85f6 [27/36] drm/mgag200: Use new
drm_fb_helper functions
config: x86_64-randconfig-i0-201528 (attached as .config)
reproduce:
git checkout 53ebb642ccba1212b7b97a5dccb358eb791b85f6
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by ):
drivers/gpu/drm/mgag200/mgag200_fb.c: In function 'mgag200fb_create':
drivers/gpu/drm/mgag200/mgag200_fb.c:232:1: warning: label 'out' defined but
not used [-Wunused-label]
out:
^
drivers/gpu/drm/mgag200/mgag200_fb.c:169:17: warning: unused variable
'device' [-Wunused-variable]
struct device *device = dev-pdev-dev;
^
vim +/out +232 drivers/gpu/drm/mgag200/mgag200_fb.c
414c45310 Dave Airlie 2012-04-17 163 struct drm_device *dev =
mfbdev-helper.dev;
414c45310 Dave Airlie 2012-04-17 164 struct drm_mode_fb_cmd2
mode_cmd;
414c45310 Dave Airlie 2012-04-17 165 struct mga_device *mdev =
dev-dev_private;
414c45310 Dave Airlie 2012-04-17 166 struct fb_info *info;
414c45310 Dave Airlie 2012-04-17 167 struct drm_framebuffer *fb;
414c45310 Dave Airlie 2012-04-17 168 struct drm_gem_object *gobj =
NULL;
414c45310 Dave Airlie 2012-04-17 @169 struct device *device =
dev-pdev-dev;
414c45310 Dave Airlie 2012-04-17 170 struct mgag200_bo *bo;
414c45310 Dave Airlie 2012-04-17 171 int ret;
414c45310 Dave Airlie 2012-04-17 172 void *sysram;
414c45310 Dave Airlie 2012-04-17 173 int size;
414c45310 Dave Airlie 2012-04-17 174
414c45310 Dave Airlie 2012-04-17 175 mode_cmd.width =
sizes-surface_width;
414c45310 Dave Airlie 2012-04-17 176 mode_cmd.height =
sizes-surface_height;
414c45310 Dave Airlie 2012-04-17 177 mode_cmd.pitches[0] =
mode_cmd.width * ((sizes-surface_bpp + 7) / 8);
414c45310 Dave Airlie 2012-04-17 178
414c45310 Dave Airlie 2012-04-17 179 mode_cmd.pixel_format =
drm_mode_legacy_fb_format(sizes-surface_bpp,
414c45310 Dave Airlie 2012-04-17 180
sizes-surface_depth);
414c45310 Dave Airlie 2012-04-17 181 size = mode_cmd.pitches[0] *
mode_cmd.height;
414c45310 Dave Airlie 2012-04-17 182
414c45310 Dave Airlie 2012-04-17 183 ret =
mgag200fb_create_object(mfbdev, mode_cmd, gobj);
414c45310 Dave Airlie 2012-04-17 184 if (ret) {
414c45310 Dave Airlie 2012-04-17 185 DRM_ERROR(failed to
create fbcon backing object %d\n, ret);
414c45310 Dave Airlie 2012-04-17 186 return ret;
414c45310 Dave Airlie 2012-04-17 187 }
414c45310 Dave Airlie 2012-04-17 188 bo = gem_to_mga_bo(gobj);
414c45310 Dave Airlie 2012-04-17 189
414c45310 Dave Airlie 2012-04-17 190 sysram = vmalloc(size);
414c45310 Dave Airlie 2012-04-17 191 if (!sysram)
414c45310 Dave Airlie 2012-04-17 192 return -ENOMEM;
414c45310 Dave Airlie 2012-04-17 193
53ebb642c Archit Taneja 2015-07-13 194 info =
drm_fb_helper_alloc_fbi(helper);
53ebb642c Archit Taneja 2015-07-13 195 if (IS_ERR(info))
53ebb642c Archit Taneja 2015-07-13 196 return PTR_ERR(info);
414c45310 Dave Airlie 2012-04-17 197
414c45310 Dave Airlie 2012-04-17 198 info-par = mfbdev;
414c45310 Dave Airlie 2012-04-17 199
414c45310 Dave Airlie 2012-04-17 200 ret =
mgag200_framebuffer_init(dev, mfbdev-mfb, mode_cmd, gobj);
414c45310 Dave Airlie 2012-04-17 201 if (ret)
414c45310 Dave Airlie 2012-04-17 202 return ret;
414c45310 Dave Airlie 2012-04-17 203
414c45310 Dave Airlie 2012-04-17 204 mfbdev-sysram = sysram;
414c45310 Dave Airlie 2012-04-17 205 mfbdev-size = size;
414c45310 Dave Airlie 2012-04-17 206
414c45310 Dave Airlie 2012-04-17 207 fb = mfbdev-mfb.base;
414c45310 Dave Airlie 2012-04-17 208
414c45310 Dave Airlie 2012-04-17 209 /* setup helper */
414c45310 Dave Airlie 2012-04-17 210 mfbdev-helper.fb = fb;
414c45310 Dave Airlie 2012-04-17 211
414c45310 Dave Airlie 2012-04-17 212 strcpy(info-fix.id,
mgadrmfb);
414c45310 Dave Airlie 2012-04-17 213
414c45310 Dave Airlie 2012-04-17 214 info-flags = FBINFO_DEFAULT |
FBINFO_CAN_FORCE_OUTPUT;
414c45310 Dave Airlie 2012-04-17 215 info-fbops = mgag200fb_ops;
414c45310 Dave Airlie 2012-04-17 216
414c45310 Dave Airlie 2012-04-17 217 /* setup aperture base/size for
vesafb takeover */
414c45310 Dave Airlie 2012-04-17 218 info-apertures-ranges[0].base
= mdev-dev-mode_config.fb_base;
414c45310 Dave Airlie 2012-04-17 219 info-apertures-ranges[0].size
=
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Op 08-07-15 om 22:12 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 19:52 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 10:55 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 18:43 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 14:10 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
This allows the first atomic call during hw init to be a real
modeset,
which is useful for forcing a recalculation.
fbcon is optional, you can't rely on anything being done in any
specific
way. What exactly do you need this for, what's the implications?
In the hw readout I noticed some warnings when I wasn't setting any
mode property in the readout.
I want the first function to be the modeset, so we have a sane base
to commit changes on.
Ideally this whole function would have a atomic counterpart which
does it in one go. :)
Yeah. Otoh as soon as we have atomic modeset working we can replace
all
the legacy entry points with atomic helpers, and then even
plane_disable
will be a full atomic modeset.
What did fall apart with just touching properties/planes now?
Also when i915 is fully atomic it calculates in
intel_modeset_compute_config
if a modeset is needed after the first atomic call. Right now because
intel_modeset_compute_config is only called in set_config so this
works as expected.
Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
and if the final mode is different this will introduce a double
modeset.
For expensive properties (i.e. a no-op changes causes something that
takes
time like modeset or vblank wait) we need to make sure we filter them
out
in atomic_check. Yeah not quite there yet with pure atomic, but
meanwhile
the existing legacy set_prop functions should all filter out no-op
changes
themselves. If we don't do that for rotation then that's a bug.
Same for disabling planes harder, that shouldn't take time. Especially
since fbcon only force-disable non-primary plane, and for driver load
that's the exact thing we already do in the driver anyway.
Something like this?
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a1d4e13f3908..2989232f4996 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
#include drm/drm_plane_helper.h
#include drm/drm_crtc_helper.h
#include drm/drm_atomic_helper.h
+#include drm_crtc_internal.h
#include linux/fence.h
/**
@@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
drm_crtc *crtc,
{
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
-int ret = 0;
+uint64_t retval;
+int ret;
+
+ret = drm_atomic_get_property(crtc-base, property, retval);
+if (!ret val == retval)
+return 0;
state = drm_atomic_state_alloc(crtc-dev);
if (!state)
@@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
drm_plane *plane,
{
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
-int ret = 0;
+uint64_t retval;
+int ret;
+
+ret = drm_atomic_get_property(plane-base, property, retval);
+if (!ret val == retval)
+return 0;
state = drm_atomic_state_alloc(plane-dev);
if (!state)
@@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
drm_connector *connector,
{
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
-int ret = 0;
+uint64_t retval;
+int ret;
+
+ret = drm_atomic_get_property(connector-base, property,
retval);
+if (!ret val == retval)
+return 0;
state = drm_atomic_state_alloc(connector-dev);
if (!state)
The reason I didn't do this is that a prop change might still result in no
hw state change (e.g. if you go automitic-explicit setting matching
automatic one). Hence I think we need to solve this in lower levels
anyway, i.e. in when computing the config. But it shouldn't cause trouble
yet.
Is that a ack or nack?
I think we shouldn't need this really for i915, and it might cover up
bugs. I prefer we just do the evade modeset logic you've implemented once
we switch over to atomic props. Since atm we only have atomic props which
get updated in pageflips we shouldn't have serious problems here yet (for
setting the rotation prop to 0° again when fbdev starts up).
Or do I miss something still here?
[Intel-gfx] [drm-intel:topic/drm-misc 31/36] drivers/gpu/drm//nouveau/nouveau_fbcon.c:322:18: warning: unused variable 'pdev'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3
commit: 237fc6452ca562188349a9abe0f9e579fd260276 [31/36] drm/nouveau: Use new
drm_fb_helper functions
config: x86_64-randconfig-i0-201528 (attached as .config)
reproduce:
git checkout 237fc6452ca562188349a9abe0f9e579fd260276
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by ):
drivers/gpu/drm//nouveau/nouveau_fbcon.c: In function 'nouveau_fbcon_create':
drivers/gpu/drm//nouveau/nouveau_fbcon.c:322:18: warning: unused variable
'pdev' [-Wunused-variable]
struct pci_dev *pdev = dev-pdev;
^
vim +/pdev +322 drivers/gpu/drm//nouveau/nouveau_fbcon.c
6ee73861 Ben Skeggs 2009-12-11 306
6ee73861 Ben Skeggs 2009-12-11 307 static int
cd5428a5 Daniel Vetter2013-01-21 308 nouveau_fbcon_create(struct
drm_fb_helper *helper,
8be48d92 Dave Airlie 2010-03-30 309struct
drm_fb_helper_surface_size *sizes)
6ee73861 Ben Skeggs 2009-12-11 310 {
918b7ed4 Fabian Frederick 2014-09-14 311 struct nouveau_fbdev *fbcon =
918b7ed4 Fabian Frederick 2014-09-14 312 container_of(helper,
struct nouveau_fbdev, helper);
ebb945a9 Ben Skeggs 2012-07-20 313 struct drm_device *dev =
fbcon-dev;
77145f1c Ben Skeggs 2012-07-31 314 struct nouveau_drm *drm =
nouveau_drm(dev);
967e7bde Ben Skeggs 2014-08-10 315 struct nvif_device *device =
drm-device;
6ee73861 Ben Skeggs 2009-12-11 316 struct fb_info *info;
6ee73861 Ben Skeggs 2009-12-11 317 struct drm_framebuffer *fb;
6ee73861 Ben Skeggs 2009-12-11 318 struct nouveau_framebuffer
*nouveau_fb;
45143cb5 Ben Skeggs 2011-06-07 319 struct nouveau_channel *chan;
6ee73861 Ben Skeggs 2009-12-11 320 struct nouveau_bo *nvbo;
308e5bcb Jesse Barnes 2011-11-14 321 struct drm_mode_fb_cmd2
mode_cmd;
1471ca9a Marcin Slusarz 2010-05-16 @322 struct pci_dev *pdev =
dev-pdev;
6ee73861 Ben Skeggs 2009-12-11 323 int size, ret;
6ee73861 Ben Skeggs 2009-12-11 324
38651674 Dave Airlie 2010-03-30 325 mode_cmd.width =
sizes-surface_width;
38651674 Dave Airlie 2010-03-30 326 mode_cmd.height =
sizes-surface_height;
6ee73861 Ben Skeggs 2009-12-11 327
308e5bcb Jesse Barnes 2011-11-14 328 mode_cmd.pitches[0] =
mode_cmd.width * (sizes-surface_bpp 3);
308e5bcb Jesse Barnes 2011-11-14 329 mode_cmd.pitches[0] =
roundup(mode_cmd.pitches[0], 256);
6ee73861 Ben Skeggs 2009-12-11 330
:: The code at line 322 was first introduced by commit
:: 1471ca9aa71cd37b6a7476bb6f06a3a8622ea1bd fbdev: allow passing more than
one aperture for handoff
:: TO: Marcin Slusarz marcin.slus...@gmail.com
:: CC: Dave Airlie airl...@redhat.com
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.1.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
#
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Op 13-07-15 om 11:45 schreef Daniel Vetter:
On Mon, Jul 13, 2015 at 11:23:45AM +0200, Maarten Lankhorst wrote:
Op 13-07-15 om 11:13 schreef Daniel Vetter:
On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 22:12 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 19:52 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 10:55 schreef Daniel Vetter:
On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 18:43 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 14:10 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
wrote:
This allows the first atomic call during hw init to be a real
modeset,
which is useful for forcing a recalculation.
fbcon is optional, you can't rely on anything being done in any
specific
way. What exactly do you need this for, what's the implications?
In the hw readout I noticed some warnings when I wasn't setting
any mode property in the readout.
I want the first function to be the modeset, so we have a sane
base to commit changes on.
Ideally this whole function would have a atomic counterpart
which does it in one go. :)
Yeah. Otoh as soon as we have atomic modeset working we can
replace all
the legacy entry points with atomic helpers, and then even
plane_disable
will be a full atomic modeset.
What did fall apart with just touching properties/planes now?
Also when i915 is fully atomic it calculates in
intel_modeset_compute_config
if a modeset is needed after the first atomic call. Right now
because
intel_modeset_compute_config is only called in set_config so this
works as expected.
Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
and if the final mode is different this will introduce a double
modeset.
For expensive properties (i.e. a no-op changes causes something
that takes
time like modeset or vblank wait) we need to make sure we filter
them out
in atomic_check. Yeah not quite there yet with pure atomic, but
meanwhile
the existing legacy set_prop functions should all filter out no-op
changes
themselves. If we don't do that for rotation then that's a bug.
Same for disabling planes harder, that shouldn't take time.
Especially
since fbcon only force-disable non-primary plane, and for driver
load
that's the exact thing we already do in the driver anyway.
Something like this?
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a1d4e13f3908..2989232f4996 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
#include drm/drm_plane_helper.h
#include drm/drm_crtc_helper.h
#include drm/drm_atomic_helper.h
+#include drm_crtc_internal.h
#include linux/fence.h
/**
@@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
drm_crtc *crtc,
{
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
-int ret = 0;
+uint64_t retval;
+int ret;
+
+ret = drm_atomic_get_property(crtc-base, property, retval);
+if (!ret val == retval)
+return 0;
state = drm_atomic_state_alloc(crtc-dev);
if (!state)
@@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
drm_plane *plane,
{
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
-int ret = 0;
+uint64_t retval;
+int ret;
+
+ret = drm_atomic_get_property(plane-base, property, retval);
+if (!ret val == retval)
+return 0;
state = drm_atomic_state_alloc(plane-dev);
if (!state)
@@ -1836,7 +1847,12 @@
drm_atomic_helper_connector_set_property(struct drm_connector
*connector,
{
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
-int ret = 0;
+uint64_t retval;
+int ret;
+
+ret = drm_atomic_get_property(connector-base, property,
retval);
+if (!ret val == retval)
+return 0;
state = drm_atomic_state_alloc(connector-dev);
if (!state)
The reason I didn't do this is that a prop change might still result
in no
hw state change (e.g. if you go automitic-explicit setting matching
automatic one). Hence I think we need to solve this in lower levels
anyway, i.e. in when computing the config. But it shouldn't cause
trouble
yet.
Is that a ack or nack?
I think we shouldn't need this really for i915, and it might cover up
bugs. I prefer we just do the evade modeset logic you've implemented
once
we switch over to atomic props. Since atm we only have atomic props
which
get updated in pageflips we shouldn't have serious
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to stop_rings mode bits
Tim Gore Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, July 13, 2015 10:30 AM To: Gore, Tim Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas Subject: Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to stop_rings mode bits On Fri, Jul 10, 2015 at 02:06:06PM +0100, tim.g...@intel.com wrote: From: Tim Gore tim.g...@intel.com In function igt_set_stop_rings, the test igt_assert_f(flags == 0 || current == 0, .. will fail if we are trying to force a hang but the STOP_RINGS_ALLOW_BAN or STOP_RINGS_ALLOW_ERROR bit is set. With the introduction of per ring resets in the driver (in android) these bits do not get cleared to zero when an individual ring is reset. This causes subsequent attempt to cause a ring hang via this function to fail, leading to several igt tests failing (ie gem_reset_stats subtest ban-xxx etc). Fix tdr to reset these instead? -Daniel I could change tdr, but why. When the TDR handles a ring hang and resets the ring, why would it modify the flag that defines if the driver should ban a frequently hanging context? If we get rid of the stop_rings interface, as Chris Wilson suggested, we would still need to keep the STOP_RING_ALLOW_BAN/ALLOW_ERRORS bits in debugfs, but you would not expect to have to re-write these bits each time there is a ring reset. Tim So, modify this test to look only at the bits that are used to hang the gpu rings. Signed-off-by: Tim Gore tim.g...@intel.com --- lib/igt_gt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/igt_gt.c b/lib/igt_gt.c index 8e5e076..12c56fa 100644 --- a/lib/igt_gt.c +++ b/lib/igt_gt.c @@ -345,8 +345,8 @@ void igt_set_stop_rings(enum stop_ring_flags flags) STOP_RING_ALLOW_ERRORS)) == 0); current = igt_get_stop_rings(); - igt_assert_f(flags == 0 || current == 0, -previous i915_ring_stop is still 0x%x\n, current); + igt_assert_f( (flags STOP_RING_ALL) == 0 || (current STOP_RING_ALL) == 0, +previous i915_ring_stop is still 0x%x\n, current); stop_rings_write(flags); current = igt_get_stop_rings(); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't forget to mark crtc as inactive after disable
On Mon, Jul 13, 2015 at 11:49:49AM +0200, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 11:10:51AM +0200, Maarten Lankhorst wrote: Op 10-07-15 om 13:22 schreef Damien Lespiau: Hi Patrik, Please do Cc the patch author and reviewer when finding a regression, they are superb candidates for the review, especially when they are busy rewriting the display code. Yeah you need to list everyone you want to Cc: explicitly. Also need the Bugzilla reference when fixing a bug. In this case: https://bugs.freedesktop.org/show_bug.cgi?id=91203 -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check live status before reading edid
On 7/13/2015 8:25 PM, Daniel Vetter wrote:
On Mon, Jul 13, 2015 at 04:35:00PM +0530, Sonika Jindal wrote:
Adding this for SKL onwards.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 42 +
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..7b54b9d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
return intel_dp_detect_dpcd(intel_dp);
}
-static int g4x_digital_port_connected(struct drm_device *dev,
- struct intel_digital_port
*intel_dig_port)
+int g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port)
{
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a47fbc3..30c8dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
void intel_edp_drrs_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
+int g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port);
/* intel_dp_mst.c */
int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1fb6919..7eb0d0e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,39 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
to_intel_connector(connector)-detect_edid = NULL;
}
+static bool bxt_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *port)
+{
+ u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+ switch (port-port) {
+ case PORT_B:
+ return temp BXT_DE_PORT_HP_DDIB;
+
+ case PORT_C:
+ return temp BXT_DE_PORT_HP_DDIC;
+
+ default:
+ return false;
+
+ }
+}
+
+static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
+{
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ if (IS_VALLEYVIEW(dev))
+ return g4x_digital_port_connected(dev, intel_dig_port);
+ else if (IS_SKYLAKE(dev))
+ return ibx_digital_port_connected(dev_priv, intel_dig_port);
+ else if (IS_BROXTON(dev))
+ return bxt_port_connected(dev_priv, intel_dig_port);
Really I want this to be rolled out for all platforms, together with the
fix for handling hpd interrupts. Together with a reference to the old
commits we had to revert because it didn't work.
I want to test this on my ivb (since that's the machine where I can
readily reproduce this bug), and if it still doesn't work there I won't
take this.
-Daniel
Is there a formal process to raise a test for hpd on all platforms which
might be affected by this?
Regards,
Sonika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/bxt: Add HPD support for DDIA
Also remove redundant comments.
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a897f68..63137dd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -90,6 +90,7 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
/* BXT hpd list */
static const u32 hpd_bxt[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
};
@@ -3022,30 +3023,25 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
u32 hotplug_port = 0;
u32 hotplug_ctrl;
- /* Now, enable HPD */
for_each_intel_encoder(dev, intel_encoder) {
if (dev_priv-hotplug.stats[intel_encoder-hpd_pin].state
== HPD_ENABLED)
hotplug_port |= hpd_bxt[intel_encoder-hpd_pin];
}
- /* Mask all HPD control bits */
hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) ~BXT_HOTPLUG_CTL_MASK;
- /* Enable requested port in hotplug control */
- /* TODO: implement (short) HPD support on port A */
- WARN_ON_ONCE(hotplug_port BXT_DE_PORT_HP_DDIA);
+ if (hotplug_port BXT_DE_PORT_HP_DDIA)
+ hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
if (hotplug_port BXT_DE_PORT_HP_DDIB)
hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
if (hotplug_port BXT_DE_PORT_HP_DDIC)
hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
- /* Unmask DDI hotplug in IMR */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR) ~hotplug_port;
I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
- /* Enable DDI hotplug in IER */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
POSTING_READ(GEN8_DE_PORT_IER);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/bxt: WA for swapped HPD pins in A stepping
As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 18 --
drivers/gpu/drm/i915/intel_hdmi.c |9 -
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7b54b9d..c32f3d3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5869,10 +5869,24 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
/* Set up the hotplug pin. */
switch (port) {
case PORT_A:
- intel_encoder-hpd_pin = HPD_PORT_A;
+ /*
+* On BXT A0/A1, sw needs to activate DDIC HPD logic and
+* interrupts to check the eDP panel connection.
+*/
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0))
+ intel_encoder-hpd_pin = HPD_PORT_C;
+ else
+ intel_encoder-hpd_pin = HPD_PORT_A;
break;
case PORT_B:
- intel_encoder-hpd_pin = HPD_PORT_B;
+ /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0))
+ intel_encoder-hpd_pin = HPD_PORT_A;
+ else
+ intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 44e7160..121e626 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2011,7 +2011,14 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
else
intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
- intel_encoder-hpd_pin = HPD_PORT_B;
+ /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+ if (IS_BROXTON(dev_priv) (INTEL_REVID(dev) BXT_REVID_B0))
+ intel_encoder-hpd_pin = HPD_PORT_A;
+ else
+ intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
if (IS_BROXTON(dev_priv))
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect
Hi Daniel, Chris Gen7 and Gen8 platforms have a different live status register (0x61114) and we need not to rely on ISR on that. As Sonika mentioned, We have been using this register for our commercial releases, and found them reliable across a wide range of monitors. On the other hand, Bsepc clearly mentions, to check the live status before even try to read EDID. The current DRM nightly code doesn't do that, and we have received few errors from Gen7 Chromebooks where you can still read valid EDID on HDMI hot-unplug. So I think this patch and solution is ready, and it should go in. Regards Shashank -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, July 13, 2015 8:27 PM To: Jindal, Sonika Cc: Chris Wilson; intel-gfx@lists.freedesktop.org; Sharma, Shashank Subject: Re: [Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect On Mon, Jul 13, 2015 at 05:29:12PM +0530, Jindal, Sonika wrote: On 7/13/2015 5:10 PM, Chris Wilson wrote: On Mon, Jul 13, 2015 at 04:19:15PM +0530, Sonika Jindal wrote: During init_connector set the edid, then edid will be set/unset only during hotplug. For the sake of older platforms where HPD is not stable, let edid read happen from detect as well only if it is forced to do so. v2: Removing the 'force' check, instead let detect call read the edid for platforms older than gen 7 (Shashank) That's enough worse. We now have a random gen check with no rationale for why you suddenly believe all manufacturers have fixed their wiring. There is no reason to believe that gen7 suddenly works is there? If there is, why don't you mention it? -Chris This gen7 check is to be on the safer side not to affect older paltforms. For CHV/VLV, already the live status check is stable enough to determine if we can read edid or not. In VPG production branches we have this patch already available and it was tested with variety of monitors extensively. So we now read the edid only during init and during hotplug. For SKL, the [PATCH] drm/i915: Handle HPD when it has actually occurred patch makes HPD stable enough. So, we can rely on the edid read from init_connector instead of reading edid on every detect call. Again, not going to take this with random gen checks. I want your fix for handling hpd on other platforms, then roll this out everywhere. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/virtio/virtgpu_drm_bus.c: In function 'virtio_pci_kick_out_firmware_fb': drivers/gpu/drm/virtio/virtgpu_drm_bus.c:55:2: error: implicit declaration of function 'drm_fb_helper_remove_conflicting_framebuffers' [-Werror=implicit-function-declaration] drm_fb_helper_remove_conflicting_framebuffers(ap, virtiodrmfb, ^ Caused by commit 7bd870e7b1c8 (drm/virtio: Use new drm_fb_helper functions) I have used the drm-misc tree from next-20150713 for today. (That commit said COMPILE TESTED ONLY :-() -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp5cB7wGZvSm.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
Op 13-07-15 om 14:51 schreef Sergey Senozhatsky: 4.2.0-rc2-next-20150713 [ 1239.783862] [ cut here ] [ 1239.783892] WARNING: CPU: 0 PID: 364 at drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() [ 1239.783894] WARN_ON(new-frontbuffer_bits frontbuffer_bits) [ 1239.783895] Modules linked in: [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress lzo_decompress zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 mac80211 cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel iwlwifi i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac cfg80211 lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 mxm_wmi wmi i8042 evdev video serio backlight processor ext4 crc16 mbcache jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted -dbg-00017-g16b87ed-dirty #183 [ 1239.783944] 0009 88041c5379d8 813a19ac 81077163 [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 88041c5379f8 [ 1239.783950] a0533273 0002 88041c578000 88041c578000 [ 1239.783953] Call Trace: [ 1239.783961] [813a19ac] dump_stack+0x4c/0x65 [ 1239.783965] [81077163] ? up+0x39/0x3e [ 1239.783968] [8103b5d9] warn_slowpath_common+0x9b/0xb5 [ 1239.783986] [a0533273] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.783987] [8103b639] warn_slowpath_fmt+0x46/0x48 [ 1239.784002] [a0533273] i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.784026] [a0575928] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 1239.784033] [a0261f0f] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 1239.784055] [a0585596] intel_atomic_commit+0x46/0xc0 [i915] [ 1239.784072] [a02d2139] drm_atomic_commit+0x4d/0x52 [drm] [ 1239.784078] [a0262f32] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 1239.784092] [a02c7572] __setplane_internal+0x24e/0x2ae [drm] [ 1239.784103] [a02c771b] drm_mode_cursor_universal+0x149/0x197 [drm] [ 1239.784113] [a02c7e58] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 1239.784122] [a02c781e] drm_mode_cursor_common+0xb5/0x156 [drm] [ 1239.784132] [a02c7e8f] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 1239.784140] [a02bae85] drm_ioctl+0x287/0x415 [drm] [ 1239.784143] [81078580] ? __lock_is_held+0x3c/0x57 [ 1239.784146] [8114c3d1] ? __fget+0x170/0x1a1 [ 1239.784148] [811422c1] do_vfs_ioctl+0x455/0x4dd [ 1239.784151] [8114c48e] ? __fget_light+0x65/0x75 [ 1239.784153] [8114238d] SyS_ioctl+0x44/0x63 [ 1239.784155] [813a8057] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- Do you have some steps to reproduce? ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: remove unused has_dma_mapping flag
On Wed, Jul 08, 2015 at 06:43:23PM +0100, Chris Wilson wrote: On Wed, Jul 08, 2015 at 07:18:59PM +0300, Imre Deak wrote: After the previous patch this flag will check always clear, as it's never set for shmem backed and userptr objects, so we can remove it. Signed-off-by: Imre Deak imre.d...@intel.com Mentioned a trivial obj-get_page bugfix for __i915_gem_userptr_set_pages(), and then went on an archaelogical dig to understand why I didn't think of this earlier. Apparently, it just never occurred to me that I could remove this flag introduced for i915_gem_prime when we did the get_pages/put_pages support for it. Both patches (incl. the minor fix above for 1), Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Applied to -fixes (too lazy for a backmerge), thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: fix ban tests with scheduler
On Mon, Jul 13, 2015 at 10:09:59AM +, Gore, Tim wrote: Tim Gore Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, July 13, 2015 10:35 AM To: Gore, Tim Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas; Kuoppala, Mika Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: fix ban tests with scheduler On Fri, Jul 10, 2015 at 02:26:59PM +0100, tim.g...@intel.com wrote: From: Tim Gore tim.g...@intel.com The tests for context banning fail when the gpu scheduler is enabled. The test causes a hang (using an infinite loop batch) and then queues up some work behind it on both the hanging context and also on a second good context. On the good context it queues up 2 batch buffers. After the hanging ring has been reset (not a full gpu reset) the test checks the values of batch_active and batch_pending returned by the i915_get_reset_stats_ioctl. For the good context it expects to see batch_pending == 2, because two batch buffers we queued up behind the hang on this context. But, with the scheduler enabled (android, gen8), one of these batch buffers is still waiting in the scheduler and has not made it as far as the ring-request_list, so this batch buffer is unaffected by the ring reset, and batch_pending is only 1. I considered putting in a test for the scheduler being enabled, but decided that a simpler solution is to only queue up 1 batch buffer on the good context. This does not change the test logic in any way and ensures that we should always have batch_pending=1, with or without the scheduler. For the scheduler/tdr we probably need to split this up into two testcases each: - one where the 2nd batch depends upon the first (cross-context depency). - one where the 2nd batch doesn't depend upon the first (should execute unhampered with scheduler/tdr). Since we don't yet have a scheduler/tdr both of these will result in the same outcome (since there's always the temporal depency). But with your patch you only test the 2nd case (and incompletely, we should assert that the 2nd batch did run) and ignore the first case. In short this failure here is telling you that your test coverage for these features is lacking. The correct fix is not to mangle the existing, but fix it up to correctly cover the new expectations in all cases. And that should be done as part of the tdr/scheduler submission. -Daniel Should gem_rest_stats be testing the operation of the scheduler? I would have thought that the scheduler operation should have its own test(s). Gem_reset_stats is just about the reset mechanism and the stats collected. I can add this test, just seems like the wrong place. Well gem_reset_stats assumes that a hang will victimize all subsequent batches, irrespective of context. tdr/scheduler change that rather fundamentally (which is the entire point really, at least of tdr). So yeah we need to adjust those existing testcase. And I think it's clearer if we do that by changing the existing test-cases, that way the impact on existing features for new code is much clearer. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On Mon, Jul 13, 2015 at 11:44:15PM +0900, Sergey Senozhatsky wrote: On (07/13/15 16:35), Daniel Vetter wrote: On Mon, Jul 13, 2015 at 09:51:39PM +0900, Sergey Senozhatsky wrote: 4.2.0-rc2-next-20150713 Is this also an issue in the 4.2-rc series or only in -next? don't know how to reproduce this, but I'll check. It goes boom somewhere from the cursor ioctl code, which means X is probably involved. Usual suspects are vt-switching, suspend/resume or cursor vs. DPMS. You can force a DPMS off from within X with $ xset dpms force off For suspend resume it occasionally matters whether you initiate it through the gui or by closing the lid or through timeout (if you're not connected to a wallplug). I hope this helps with figuring out a repro recipe. It could also be a race somewhere, in which case you won't be able to consistently reproduce this. -Daniel -ss [ 1239.783862] [ cut here ] [ 1239.783892] WARNING: CPU: 0 PID: 364 at drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() [ 1239.783894] WARN_ON(new-frontbuffer_bits frontbuffer_bits) [ 1239.783895] Modules linked in: [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress lzo_decompress zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 mac80211 cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel iwlwifi i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac cfg80211 lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 mxm_wmi wmi i8042 evdev video serio backlight processor ext4 crc16 mbcache jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 [ 1239.783944] 0009 88041c5379d8 813a19ac 81077163 [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 88041c5379f8 [ 1239.783950] a0533273 0002 88041c578000 88041c578000 [ 1239.783953] Call Trace: [ 1239.783961] [813a19ac] dump_stack+0x4c/0x65 [ 1239.783965] [81077163] ? up+0x39/0x3e [ 1239.783968] [8103b5d9] warn_slowpath_common+0x9b/0xb5 [ 1239.783986] [a0533273] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.783987] [8103b639] warn_slowpath_fmt+0x46/0x48 [ 1239.784002] [a0533273] i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.784026] [a0575928] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 1239.784033] [a0261f0f] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 1239.784055] [a0585596] intel_atomic_commit+0x46/0xc0 [i915] [ 1239.784072] [a02d2139] drm_atomic_commit+0x4d/0x52 [drm] [ 1239.784078] [a0262f32] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 1239.784092] [a02c7572] __setplane_internal+0x24e/0x2ae [drm] [ 1239.784103] [a02c771b] drm_mode_cursor_universal+0x149/0x197 [drm] [ 1239.784113] [a02c7e58] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 1239.784122] [a02c781e] drm_mode_cursor_common+0xb5/0x156 [drm] [ 1239.784132] [a02c7e8f] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 1239.784140] [a02bae85] drm_ioctl+0x287/0x415 [drm] [ 1239.784143] [81078580] ? __lock_is_held+0x3c/0x57 [ 1239.784146] [8114c3d1] ? __fget+0x170/0x1a1 [ 1239.784148] [811422c1] do_vfs_ioctl+0x455/0x4dd [ 1239.784151] [8114c48e] ? __fget_light+0x65/0x75 [ 1239.784153] [8114238d] SyS_ioctl+0x44/0x63 [ 1239.784155] [813a8057] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [-next] WARNING at i915_gem_track_fb
4.2.0-rc2-next-20150713 [ 1239.783862] [ cut here ] [ 1239.783892] WARNING: CPU: 0 PID: 364 at drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() [ 1239.783894] WARN_ON(new-frontbuffer_bits frontbuffer_bits) [ 1239.783895] Modules linked in: [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress lzo_decompress zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 mac80211 cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel iwlwifi i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac cfg80211 lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 mxm_wmi wmi i8042 evdev video serio backlight processor ext4 crc16 mbcache jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 [ 1239.783944] 0009 88041c5379d8 813a19ac 81077163 [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 88041c5379f8 [ 1239.783950] a0533273 0002 88041c578000 88041c578000 [ 1239.783953] Call Trace: [ 1239.783961] [813a19ac] dump_stack+0x4c/0x65 [ 1239.783965] [81077163] ? up+0x39/0x3e [ 1239.783968] [8103b5d9] warn_slowpath_common+0x9b/0xb5 [ 1239.783986] [a0533273] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.783987] [8103b639] warn_slowpath_fmt+0x46/0x48 [ 1239.784002] [a0533273] i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.784026] [a0575928] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 1239.784033] [a0261f0f] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 1239.784055] [a0585596] intel_atomic_commit+0x46/0xc0 [i915] [ 1239.784072] [a02d2139] drm_atomic_commit+0x4d/0x52 [drm] [ 1239.784078] [a0262f32] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 1239.784092] [a02c7572] __setplane_internal+0x24e/0x2ae [drm] [ 1239.784103] [a02c771b] drm_mode_cursor_universal+0x149/0x197 [drm] [ 1239.784113] [a02c7e58] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 1239.784122] [a02c781e] drm_mode_cursor_common+0xb5/0x156 [drm] [ 1239.784132] [a02c7e8f] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 1239.784140] [a02bae85] drm_ioctl+0x287/0x415 [drm] [ 1239.784143] [81078580] ? __lock_is_held+0x3c/0x57 [ 1239.784146] [8114c3d1] ? __fget+0x170/0x1a1 [ 1239.784148] [811422c1] do_vfs_ioctl+0x455/0x4dd [ 1239.784151] [8114c48e] ? __fget_light+0x65/0x75 [ 1239.784153] [8114238d] SyS_ioctl+0x44/0x63 [ 1239.784155] [813a8057] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/gen9: Add WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
Arun Siluvery arun.siluv...@linux.intel.com writes:
In Indirect context w/a batch buffer,
+WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).
Cc: Robert Beckett robert.beck...@intel.com
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 9 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +--
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 58247f0..61ed92b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1302,6 +1302,15 @@ static int gen9_init_perctx_bb(struct intel_engine_cs
*ring,
struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
+ /* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
+ if ((IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_B0)) ||
+ (IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0))) {
+ wa_ctx_emit(batch, MI_LOAD_REGISTER_IMM(1));
+ wa_ctx_emit(batch, GEN9_SLICE_COMMON_ECO_CHICKEN0);
+ wa_ctx_emit(batch,
_MASKED_BIT_ENABLE(DISABLE_PIXEL_MASK_CAMMING));
+ wa_ctx_emit(batch, MI_NOOP);
+ }
+
/* WaDisableCtxRestoreArbitration:skl,bxt */
if ((IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_D0)) ||
(IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0)))
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index af7c12e..66dde7f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -946,8 +946,11 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
/*
WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
WA_SET_BIT_MASKED(GEN7_COMMON_SLICE_CHICKEN1,
GEN9_RHWO_OPTIMIZATION_DISABLE);
- WA_SET_BIT_MASKED(GEN9_SLICE_COMMON_ECO_CHICKEN0,
- DISABLE_PIXEL_MASK_CAMMING);
+ /*
+ * WA also requires GEN9_SLICE_COMMON_ECO_CHICKEN0[14] to be
set,
+ * but that register is write only hence it is set
+ * in per ctx batch buffer
Why the need to move to per ctx bb? Why the write would not stick
with this? Is the rationale that we get fails with the gem_workarounds?
If so, perhaps we need a write_only marker for workaround list?
-Mika
+ */
}
if ((IS_SKYLAKE(dev) INTEL_REVID(dev) = SKL_REVID_C0) ||
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 17/20] drm/i915: Use full atomic modeset.
Huzzah! \o/
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_params.c | 5 -
drivers/gpu/drm/i915/intel_atomic.c | 123 ---
drivers/gpu/drm/i915/intel_display.c | 279 ++-
drivers/gpu/drm/i915/intel_drv.h | 5 -
6 files changed, 43 insertions(+), 372 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index db48aee7f140..f13ed1ef6641 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1731,7 +1731,7 @@ static int __init i915_init(void)
* to the atomic ioctl and the atomic properties. Only plane
operations on
* a single CRTC will actually work.
*/
- if (i915.nuclear_pageflip)
+ if (driver.driver_features DRIVER_MODESET)
driver.driver_features |= DRIVER_ATOMIC;
return drm_pci_init(driver, i915_pci_driver);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d3e14cb43924..3d02d0094132 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2612,7 +2612,6 @@ struct i915_params {
int use_mmio_flip;
int mmio_debug;
bool verbose_state_checks;
- bool nuclear_pageflip;
int edp_vswing;
};
extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 7983fe48a654..5f4e7295295f 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -51,7 +51,6 @@ struct i915_params i915 __read_mostly = {
.use_mmio_flip = 0,
.mmio_debug = 0,
.verbose_state_checks = 1,
- .nuclear_pageflip = 0,
.edp_vswing = 0,
};
@@ -176,10 +175,6 @@ module_param_named(verbose_state_checks,
i915.verbose_state_checks, bool, 0600);
MODULE_PARM_DESC(verbose_state_checks,
Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state
conditions.);
-module_param_named_unsafe(nuclear_pageflip, i915.nuclear_pageflip, bool, 0600);
-MODULE_PARM_DESC(nuclear_pageflip,
-Force atomic modeset functionality; only planes work for now
(default: false).);
-
/* WA to get away with the default setting in VBT for early platforms.Will be
removed */
module_param_named_unsafe(edp_vswing, i915.edp_vswing, int, 0400);
MODULE_PARM_DESC(edp_vswing,
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index dcf4fb458649..e2531cf59266 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -35,129 +35,6 @@
#include drm/drm_plane_helper.h
#include intel_drv.h
-
-/**
- * intel_atomic_check - validate state object
- * @dev: drm device
- * @state: state to validate
- */
-int intel_atomic_check(struct drm_device *dev,
- struct drm_atomic_state *state)
-{
- int nplanes = dev-mode_config.num_total_plane;
- int ncrtcs = dev-mode_config.num_crtc;
- int nconnectors = dev-mode_config.num_connector;
- enum pipe nuclear_pipe = INVALID_PIPE;
- struct intel_crtc *nuclear_crtc = NULL;
- struct intel_crtc_state *crtc_state = NULL;
- int ret;
- int i;
- bool not_nuclear = false;
-
- to_intel_atomic_state(state)-cdclk = to_i915(dev)-cdclk_freq;
-
- /*
-* FIXME: At the moment, we only support nuclear pageflip on a
-* single CRTC. Cross-crtc updates will be added later.
-*/
- for (i = 0; i nplanes; i++) {
- struct intel_plane *plane = to_intel_plane(state-planes[i]);
- if (!plane)
- continue;
-
- if (nuclear_pipe == INVALID_PIPE) {
- nuclear_pipe = plane-pipe;
- } else if (nuclear_pipe != plane-pipe) {
- DRM_DEBUG_KMS(i915 only support atomic plane
operations on a single CRTC at the moment\n);
- return -EINVAL;
- }
- }
-
- /*
-* FIXME: We only handle planes for now; make sure there are no CRTC's
-* or connectors involved.
-*/
- state-allow_modeset = false;
- for (i = 0; i ncrtcs; i++) {
- struct intel_crtc *crtc = to_intel_crtc(state-crtcs[i]);
- if (crtc)
- memset(crtc-atomic, 0, sizeof(crtc-atomic));
- if (crtc crtc-pipe != nuclear_pipe)
- not_nuclear = true;
- if (crtc crtc-pipe == nuclear_pipe) {
- nuclear_crtc = crtc;
- crtc_state = to_intel_crtc_state(state-crtc_states[i]);
- }
- }
- for (i = 0; i nconnectors; i++)
- if (state-connectors[i] != NULL)
- not_nuclear =
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Clear out DPLL state from pipe config in DSI get config
On Mon, Jul 13, 2015 at 03:49:44PM +0530, Sivakumar Thulasimani wrote: On 7/13/2015 2:21 PM, Daniel Vetter wrote: On Fri, Jul 10, 2015 at 05:37:07PM +0530, Sivakumar Thulasimani wrote: On 7/1/2015 6:12 PM, Daniel Vetter wrote: On Tue, Jun 30, 2015 at 02:50:33PM +0300, Ville Syrjälä wrote: On Tue, Jun 30, 2015 at 12:13:37PM +0200, Daniel Vetter wrote: On Mon, Jun 29, 2015 at 08:08:27PM +0300, Ville Syrjälä wrote: On Mon, Jun 29, 2015 at 07:56:05PM +0300, Ville Syrjälä wrote: On Mon, Jun 29, 2015 at 06:42:11PM +0200, Daniel Vetter wrote: On Mon, Jun 29, 2015 at 03:25:52PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com VLV/CHV don't use the DPLL with DSI, so just clear out the DPLL state from the pipe_config in intel_dsi_get_config(). This avoids spurious state checker warnings. We already did it this way for DPLL_MD, but do it for DPLL too. Toss in a WARN to intel_dsi_pre_enable() to make sure the ref clocks are enabled however. Supposedly they have some meaning to DSI too. We now keep the ref clocks always enabled while the disp2d well is enabled. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_dsi.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 36e2148..92bb252 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -421,18 +421,12 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder) /* Disable DPOunit clock gating, can stall pipe * and we need DPLL REFA always enabled */ -tmp = I915_READ(DPLL(pipe)); -tmp |= DPLL_REF_CLK_ENABLE_VLV; -I915_WRITE(DPLL(pipe), tmp); - -/* update the hw state for DPLL */ -intel_crtc-config-dpll_hw_state.dpll = DPLL_INTEGRATED_REF_CLK_VLV | -DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS; - tmp = I915_READ(DSPCLK_GATE_D); tmp |= DPOUNIT_CLOCK_GATE_DISABLE; I915_WRITE(DSPCLK_GATE_D, tmp); +WARN_ON((I915_READ(DPLL(pipe)) DPLL_REF_CLK_ENABLE_VLV) == 0); + /* put device in ready state */ intel_dsi_device_ready(encoder); @@ -635,9 +629,10 @@ static void intel_dsi_get_config(struct intel_encoder *encoder, DRM_DEBUG_KMS(\n); /* - * DPLL_MD is not used in case of DSI, reading will get some default value - * set dpll_md = 0 + * DPLL is not used in case of DSI, reading will getsome default value. + * Clear the state to keep the state checker happy. */ +pipe_config-dpll_hw_state.dpll = 0; pipe_config-dpll_hw_state.dpll_md = 0; State configs are supposed to be kzallocated. Needing this indicates a pretty serious bug - I'd vote to instead also ditch the dpll_md line and fix the offender. There is no offender really. We read out the DPLL state before we know which ports are active and hence can't tell at that point if the information is really relevant. So the bios leaves the DPLL enabled even when using a DSI port? Or do we miss to check some routing bits in get_clock? Not necessarily enabled, but there are other bits in there that could be left in any state basically. The DSI port simply doesn't care. If the enable bit is what's gating things here then we should just forgo reading out any dpll register state if that's not set. Looking at the vlv/chv state readout code that seems to be the trouble - there's nothing guarding the register reads into the pipe_config at all. Didn't matter pre-vlv without dsi since enable pipe should imply enabled dpll, but obviously won't work correctly with dsi. Can you please spin such a patch and remove the hacks here from dsi_get_config? -Daniel Not sure i understand the point of contention here, just noticed this after i gave my RB :) so my justification on why this is proper is that DSI is not supposed to touch DPLL register any place we access dpll_hw_state.dpll is under !is_dsi check so that ensures that we dont program DPLL register for dsi panel. it was wrong to have originally modfied DPLL register inside intel_dsi_pre_enable so removal is fine. setting it to zero in intel_dsi_get_config is of no impact since any place we write back the contents of dpll_hw_state is past the !is_dsi check is never consumed by anyone as long as the CRTC uses DSI. Ok, let's try a patch. Does the below work y/n? I've merged the patches up to this one to dinq meanwhile, but I'd really like to close this first. If it works I can rebase this patch here myself. Diff below is based on -nightly with the above patch, so if you want to test on top of it you also have to remove the dpll = 0; line too ofc. Thanks, Daniel diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a7482ab140e1..c770655f5612 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++
Re: [Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect
On Mon, Jul 13, 2015 at 05:29:12PM +0530, Jindal, Sonika wrote: On 7/13/2015 5:10 PM, Chris Wilson wrote: On Mon, Jul 13, 2015 at 04:19:15PM +0530, Sonika Jindal wrote: During init_connector set the edid, then edid will be set/unset only during hotplug. For the sake of older platforms where HPD is not stable, let edid read happen from detect as well only if it is forced to do so. v2: Removing the 'force' check, instead let detect call read the edid for platforms older than gen 7 (Shashank) That's enough worse. We now have a random gen check with no rationale for why you suddenly believe all manufacturers have fixed their wiring. There is no reason to believe that gen7 suddenly works is there? If there is, why don't you mention it? -Chris This gen7 check is to be on the safer side not to affect older paltforms. For CHV/VLV, already the live status check is stable enough to determine if we can read edid or not. In VPG production branches we have this patch already available and it was tested with variety of monitors extensively. So we now read the edid only during init and during hotplug. For SKL, the [PATCH] drm/i915: Handle HPD when it has actually occurred patch makes HPD stable enough. So, we can rely on the edid read from init_connector instead of reading edid on every detect call. Again, not going to take this with random gen checks. I want your fix for handling hpd on other platforms, then roll this out everywhere. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On Mon, Jul 13, 2015 at 09:51:39PM +0900, Sergey Senozhatsky wrote: 4.2.0-rc2-next-20150713 Is this also an issue in the 4.2-rc series or only in -next? -Daniel [ 1239.783862] [ cut here ] [ 1239.783892] WARNING: CPU: 0 PID: 364 at drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() [ 1239.783894] WARN_ON(new-frontbuffer_bits frontbuffer_bits) [ 1239.783895] Modules linked in: [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress lzo_decompress zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 mac80211 cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel iwlwifi i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac cfg80211 lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 mxm_wmi wmi i8042 evdev video serio backlight processor ext4 crc16 mbcache jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 [ 1239.783944] 0009 88041c5379d8 813a19ac 81077163 [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 88041c5379f8 [ 1239.783950] a0533273 0002 88041c578000 88041c578000 [ 1239.783953] Call Trace: [ 1239.783961] [813a19ac] dump_stack+0x4c/0x65 [ 1239.783965] [81077163] ? up+0x39/0x3e [ 1239.783968] [8103b5d9] warn_slowpath_common+0x9b/0xb5 [ 1239.783986] [a0533273] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.783987] [8103b639] warn_slowpath_fmt+0x46/0x48 [ 1239.784002] [a0533273] i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.784026] [a0575928] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 1239.784033] [a0261f0f] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 1239.784055] [a0585596] intel_atomic_commit+0x46/0xc0 [i915] [ 1239.784072] [a02d2139] drm_atomic_commit+0x4d/0x52 [drm] [ 1239.784078] [a0262f32] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 1239.784092] [a02c7572] __setplane_internal+0x24e/0x2ae [drm] [ 1239.784103] [a02c771b] drm_mode_cursor_universal+0x149/0x197 [drm] [ 1239.784113] [a02c7e58] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 1239.784122] [a02c781e] drm_mode_cursor_common+0xb5/0x156 [drm] [ 1239.784132] [a02c7e8f] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 1239.784140] [a02bae85] drm_ioctl+0x287/0x415 [drm] [ 1239.784143] [81078580] ? __lock_is_held+0x3c/0x57 [ 1239.784146] [8114c3d1] ? __fget+0x170/0x1a1 [ 1239.784148] [811422c1] do_vfs_ioctl+0x455/0x4dd [ 1239.784151] [8114c48e] ? __fget_light+0x65/0x75 [ 1239.784153] [8114238d] SyS_ioctl+0x44/0x63 [ 1239.784155] [813a8057] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround
On Mon, Jul 13, 2015 at 04:49:37PM +0200, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 03:31:45PM +0300, Mika Kuoppala wrote: Arun Siluvery arun.siluv...@linux.intel.com writes: In Indirect and Per context w/a batch buffer, +WaDisableCtxRestoreArbitration v2: SKL revision id was used for BXT, copy paste error found during internal review (Bob Beckett). Cc: Robert Beckett robert.beck...@intel.com Cc: Imre Deak imre.d...@intel.com Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com Merged first two patches of this series to dinq, thanks. Actually strike that, these all need rebasing. Dropped again. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/2] Add Pooled EU support
On 11/07/2015 20:09, Chris Wilson wrote: On Sat, Jul 11, 2015 at 08:05:05PM +0100, Chris Wilson wrote: On Fri, Jul 10, 2015 at 06:35:18PM +0100, Arun Siluvery wrote: These patches enabled Pooled EU support for BXT, they are implemented by Armin Reese. I am sending these patches in its current form for comments. These patches modify Golden batch to have a set of modification values where we can change the commands based on Gen. The commands to enable Pooled EU are inserted after MI_BATCH_BUFFER_END. If the given Gen supports this feature, modification values are used to replace MI_BATCH_BUFFER_END so we send commands to enable Pooled EU. These commands need to be part of this batch because they are to be initialized only once. Userspace will have option to query the availability of this feature, those changes are not included in this series. Would it not just be simpler to execute 2 batches? First holding the basic and common state for the gen, the second using subgen. That we have a chunk of binary data is nasty, but at least we can point to the generator and be able to decipher it and recreate it as required. Doing binary patching on top, on that path lies madness. I like this idea of sending 2 batches if that is acceptable. In this case we don't have to touch the golden batch and hence the generator tool and also not worry about using the correct binary blob as header. the setup in this case would be, 1. send golden batch 2. prepare and send batch to configure pooled EU as per subslice and EU count Why we have a separate tool in the first place, is it not possible to carry all of them in code or are there any restrictions in doing so? What is the minimum instruction sequence required to be able to setup the default EU state? Is it small enough that carrying it as code in the kernel is viable (and readable)? setting up of pooled EU configuration is only few instructions, it can be added to the driver. (That actually is critical here as currently we have to juggle multiple sources and look very carefully at what is being patched - I am not confident that we will not introduce mistakes in a week's time, let alone a year or two.) The alternative is to just say that the patch table is also autogenerated and for that to be simple and clear, and far more documentated as it relies on a strict protocol. The patch table is also auto generated using intel_null_state_gen tool but it is patched based on Gen. regards Arun -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 07/20] drm/i915: Rework plane readout.
All non-primary planes get disabled during hw readout,
this reduces complexity and means not having to do some plane
visibility checks during the first commit.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_atomic.c | 7 ---
drivers/gpu/drm/i915/intel_display.c | 86
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 8 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index b92b8581efc2..dcf4fb458649 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -98,13 +98,6 @@ int intel_atomic_check(struct drm_device *dev,
return -EINVAL;
}
- if (crtc_state
- crtc_state-quirks PIPE_CONFIG_QUIRK_INITIAL_PLANES) {
- ret = drm_atomic_add_affected_planes(state,
nuclear_crtc-base);
- if (ret)
- return ret;
- }
-
ret = drm_atomic_helper_check_planes(dev, state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e4d8acc63823..118187dc76be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11783,34 +11783,6 @@ static bool check_encoder_cloning(struct
drm_atomic_state *state,
return true;
}
-static void intel_crtc_check_initial_planes(struct drm_crtc *crtc,
- struct drm_crtc_state *crtc_state)
-{
- struct intel_crtc_state *pipe_config =
- to_intel_crtc_state(crtc_state);
- struct drm_plane *p;
- unsigned visible_mask = 0;
-
- drm_for_each_plane_mask(p, crtc-dev, crtc_state-plane_mask) {
- struct drm_plane_state *plane_state =
- drm_atomic_get_existing_plane_state(crtc_state-state,
p);
-
- if (WARN_ON(!plane_state))
- continue;
-
- if (!plane_state-fb)
- crtc_state-plane_mask =
- ~(1 drm_plane_index(p));
- else if (to_intel_plane_state(plane_state)-visible)
- visible_mask |= 1 drm_plane_index(p);
- }
-
- if (!visible_mask)
- return;
-
- pipe_config-quirks = ~PIPE_CONFIG_QUIRK_INITIAL_PLANES;
-}
-
static int intel_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *crtc_state)
{
@@ -11832,10 +11804,6 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
[CRTC:%i] mismatch between state-active(%i) and
crtc-active(%i)\n,
idx, crtc-state-active, intel_crtc-active);
- /* plane mask is fixed up after all initial planes are calculated */
- if (pipe_config-quirks PIPE_CONFIG_QUIRK_INITIAL_PLANES)
- intel_crtc_check_initial_planes(crtc, crtc_state);
-
if (mode_changed !crtc_state-active)
intel_crtc-atomic.update_wm_post = true;
@@ -13188,19 +13156,6 @@ intel_modeset_compute_config(struct drm_atomic_state
*state)
continue;
}
- if (pipe_config-quirks PIPE_CONFIG_QUIRK_INITIAL_PLANES) {
- ret = drm_atomic_add_affected_planes(state, crtc);
- if (ret)
- return ret;
-
- /*
-* We ought to handle i915.fastboot here.
-* If no modeset is required and the primary plane has
-* a fb, update the members of crtc_state as needed,
-* and run the necessary updates during vblank evasion.
-*/
- }
-
modeset = needs_modeset(crtc_state);
recalc = pipe_config-quirks PIPE_CONFIG_QUIRK_INHERITED_MODE;
@@ -15460,47 +15415,22 @@ static void readout_plane_state(struct intel_crtc
*crtc,
struct intel_crtc_state *crtc_state)
{
struct intel_plane *p;
- struct drm_plane_state *drm_plane_state;
+ struct intel_plane_state *plane_state;
bool active = crtc_state-base.active;
- if (active) {
- crtc_state-quirks |= PIPE_CONFIG_QUIRK_INITIAL_PLANES;
-
- /* apply to previous sw state too */
- to_intel_crtc_state(crtc-base.state)-quirks |=
- PIPE_CONFIG_QUIRK_INITIAL_PLANES;
- }
-
for_each_intel_plane(crtc-base.dev, p) {
- bool visible = active;
-
if (crtc-pipe != p-pipe)
continue;
- drm_plane_state = p-base.state;
-
- /* Plane scaler state is not touched here. The first atomic
-* commit will restore all plane scalers to its
[Intel-gfx] [PATCH v3 13/20] drm/i915: Get rid of unused transitional members.
The previous commit converted hw readout to atomic, all the new_*
members were used for restoring the old state, but with the
conversion of suspend to atomic there's no use left for them.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 80
drivers/gpu/drm/i915/intel_drv.h | 12 --
2 files changed, 18 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b8984b4f8081..6bab045b389c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10254,7 +10254,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
*connector,
retry:
ret = drm_modeset_lock(config-connection_mutex, ctx);
if (ret)
- goto fail_unlock;
+ goto fail;
/*
* Algorithm gets a little messy:
@@ -10272,10 +10272,10 @@ retry:
ret = drm_modeset_lock(crtc-mutex, ctx);
if (ret)
- goto fail_unlock;
+ goto fail;
ret = drm_modeset_lock(crtc-primary-mutex, ctx);
if (ret)
- goto fail_unlock;
+ goto fail;
old-dpms_mode = connector-dpms;
old-load_detect_temp = false;
@@ -10294,9 +10294,6 @@ retry:
continue;
if (possible_crtc-state-enable)
continue;
- /* This can occur when applying the pipe A quirk on resume. */
- if (to_intel_crtc(possible_crtc)-new_enabled)
- continue;
crtc = possible_crtc;
break;
@@ -10307,20 +10304,17 @@ retry:
*/
if (!crtc) {
DRM_DEBUG_KMS(no pipe available for load-detect\n);
- goto fail_unlock;
+ goto fail;
}
ret = drm_modeset_lock(crtc-mutex, ctx);
if (ret)
- goto fail_unlock;
+ goto fail;
ret = drm_modeset_lock(crtc-primary-mutex, ctx);
if (ret)
- goto fail_unlock;
- intel_encoder-new_crtc = to_intel_crtc(crtc);
- to_intel_connector(connector)-new_encoder = intel_encoder;
+ goto fail;
intel_crtc = to_intel_crtc(crtc);
- intel_crtc-new_enabled = true;
old-dpms_mode = connector-dpms;
old-load_detect_temp = true;
old-release_fb = NULL;
@@ -10388,9 +10382,7 @@ retry:
intel_wait_for_vblank(dev, intel_crtc-pipe);
return true;
- fail:
- intel_crtc-new_enabled = crtc-state-enable;
-fail_unlock:
+fail:
drm_atomic_state_free(state);
state = NULL;
@@ -10436,10 +10428,6 @@ void intel_release_load_detect_pipe(struct
drm_connector *connector,
if (IS_ERR(crtc_state))
goto fail;
- to_intel_connector(connector)-new_encoder = NULL;
- intel_encoder-new_crtc = NULL;
- intel_crtc-new_enabled = false;
-
connector_state-best_encoder = NULL;
connector_state-crtc = NULL;
@@ -11843,37 +11831,6 @@ static const struct drm_crtc_helper_funcs
intel_helper_funcs = {
.atomic_check = intel_crtc_atomic_check,
};
-/**
- * intel_modeset_update_staged_output_state
- *
- * Updates the staged output configuration state, e.g. after we've read out the
- * current hw state.
- */
-static void intel_modeset_update_staged_output_state(struct drm_device *dev)
-{
- struct intel_crtc *crtc;
- struct intel_encoder *encoder;
- struct intel_connector *connector;
-
- for_each_intel_connector(dev, connector) {
- connector-new_encoder =
- to_intel_encoder(connector-base.encoder);
- }
-
- for_each_intel_encoder(dev, encoder) {
- encoder-new_crtc =
- to_intel_crtc(encoder-base.crtc);
- }
-
- for_each_intel_crtc(dev, crtc) {
- crtc-new_enabled = crtc-base.state-enable;
- }
-}
-
-/* Transitional helper to copy current connector/encoder state to
- * connector-state. This is needed so that code that is partially
- * converted to atomic does the right thing.
- */
static void intel_modeset_update_connector_atomic_state(struct drm_device *dev)
{
struct intel_connector *connector;
@@ -12314,7 +12271,6 @@ intel_modeset_update_state(struct drm_atomic_state
*state)
}
drm_atomic_helper_update_legacy_modeset_state(state-dev, state);
- intel_modeset_update_staged_output_state(state-dev);
/* Double check state. */
for_each_crtc_in_state(state, crtc, crtc_state, i) {
@@ -12714,11 +12670,14 @@ check_connector_state(struct drm_device *dev)
struct intel_connector *connector;
for_each_intel_connector(dev,
[Intel-gfx] [PATCH v3 19/20] drm/i915: always disable irqs in intel_pipe_update_start
This can only fail because of a bug in the code.
Suggested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 15 +--
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 17 +++--
3 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fd41cfa92d3d..cc8ae7601884 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11248,12 +11248,11 @@ static void ilk_do_mmio_flip(struct intel_crtc
*intel_crtc)
static void intel_do_mmio_flip(struct intel_crtc *intel_crtc)
{
struct drm_device *dev = intel_crtc-base.dev;
- bool atomic_update;
u32 start_vbl_count;
intel_mark_page_flip_active(intel_crtc);
- atomic_update = intel_pipe_update_start(intel_crtc, start_vbl_count);
+ intel_pipe_update_start(intel_crtc, start_vbl_count);
if (INTEL_INFO(dev)-gen = 9)
skl_do_mmio_flip(intel_crtc);
@@ -11261,8 +11260,7 @@ static void intel_do_mmio_flip(struct intel_crtc
*intel_crtc)
/* use_mmio_flip() retricts MMIO flips to ilk+ */
ilk_do_mmio_flip(intel_crtc);
- if (atomic_update)
- intel_pipe_update_end(intel_crtc, start_vbl_count);
+ intel_pipe_update_end(intel_crtc, start_vbl_count);
}
static void intel_mmio_flip_work_func(struct work_struct *work)
@@ -13649,9 +13647,7 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc)
/* Perform vblank evasion around commit operation */
if (crtc-state-active)
- intel_crtc-atomic.evade =
- intel_pipe_update_start(intel_crtc,
-
intel_crtc-atomic.start_vbl_count);
+ intel_pipe_update_start(intel_crtc,
intel_crtc-atomic.start_vbl_count);
if (!needs_modeset(crtc-state) INTEL_INFO(dev)-gen = 9)
skl_detach_scalers(intel_crtc);
@@ -13663,9 +13659,8 @@ static void intel_finish_crtc_commit(struct drm_crtc
*crtc)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- if (intel_crtc-atomic.evade)
- intel_pipe_update_end(intel_crtc,
- intel_crtc-atomic.start_vbl_count);
+ if (crtc-state-active)
+ intel_pipe_update_end(intel_crtc,
intel_crtc-atomic.start_vbl_count);
intel_runtime_pm_put(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cc91ea370c99..250ee28baff9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1385,7 +1385,7 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob);
int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-bool intel_pipe_update_start(struct intel_crtc *crtc,
+void intel_pipe_update_start(struct intel_crtc *crtc,
uint32_t *start_vbl_count);
void intel_pipe_update_end(struct intel_crtc *crtc, u32 start_vbl_count);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index cd21525df352..9d8af2f8a875 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -75,10 +75,8 @@ static int usecs_to_scanlines(const struct drm_display_mode
*mode, int usecs)
* until a subsequent call to intel_pipe_update_end(). That is done to
* avoid random delays. The value written to @start_vbl_count should be
* supplied to intel_pipe_update_end() for error checking.
- *
- * Return: true if the call was successful
*/
-bool intel_pipe_update_start(struct intel_crtc *crtc, uint32_t
*start_vbl_count)
+void intel_pipe_update_start(struct intel_crtc *crtc, uint32_t
*start_vbl_count)
{
struct drm_device *dev = crtc-base.dev;
const struct drm_display_mode *mode = crtc-config-base.adjusted_mode;
@@ -96,13 +94,14 @@ bool intel_pipe_update_start(struct intel_crtc *crtc,
uint32_t *start_vbl_count)
min = vblank_start - usecs_to_scanlines(mode, 100);
max = vblank_start - 1;
+ local_irq_disable();
+ *start_vbl_count = 0;
+
if (min = 0 || max = 0)
- return false;
+ return;
if (WARN_ON(drm_crtc_vblank_get(crtc-base)))
- return false;
-
- local_irq_disable();
+ return;
trace_i915_pipe_update_start(crtc, min, max);
@@ -138,8 +137,6 @@ bool intel_pipe_update_start(struct intel_crtc *crtc,
uint32_t *start_vbl_count)
*start_vbl_count = dev-driver-get_vblank_counter(dev, pipe);
[Intel-gfx] [PATCH v3 05/20] drm/i915: Update missing properties in find_initial_plane_obj
The src and crtc rectangles were never set, resulting in the primary plane being made invisible on first atomic update. Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c3a3d108..037a85f1b127 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2586,6 +2586,7 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc, struct intel_crtc *i; struct drm_i915_gem_object *obj; struct drm_plane *primary = intel_crtc-base.primary; + struct drm_plane_state *plane_state = primary-state; struct drm_framebuffer *fb; if (!plane_config-fb) @@ -2625,13 +2626,21 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc, return; valid_fb: + plane_state-src_x = plane_state-src_y = 0; + plane_state-src_w = fb-width 16; + plane_state-src_h = fb-height 16; + + plane_state-crtc_x = plane_state-src_y = 0; + plane_state-crtc_w = fb-width; + plane_state-crtc_h = fb-height; + obj = intel_fb_obj(fb); if (obj-tiling_mode != I915_TILING_NONE) dev_priv-preserve_bios_swizzle = true; - primary-fb = fb; + drm_framebuffer_reference(fb); + primary-fb = primary-state-fb = fb; primary-crtc = primary-state-crtc = intel_crtc-base; - update_state_fb(primary); intel_crtc-base.state-plane_mask |= (1 drm_plane_index(primary)); obj-frontbuffer_bits |= to_intel_plane(primary)-frontbuffer_bit; } -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 15/20] drm/i915: Always reset in intel_crtc_restore_mode
And get rid of things that are no longer true. This function is only
used for forcing a modeset when encoder properties are changed.
Because this is not yet done atomically, assume a full modeset is
needed and reset the crtc.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 58 ++--
1 file changed, 16 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f6c65706cebf..599af76d34f6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13273,63 +13273,37 @@ void intel_crtc_restore_mode(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
struct drm_atomic_state *state;
- struct intel_encoder *encoder;
- struct intel_connector *connector;
- struct drm_connector_state *connector_state;
- struct intel_crtc_state *crtc_state;
+ struct drm_crtc_state *crtc_state;
int ret;
state = drm_atomic_state_alloc(dev);
if (!state) {
- DRM_DEBUG_KMS([CRTC:%d] mode restore failed, out of memory,
+ DRM_DEBUG_KMS([CRTC:%d] crtc restore failed, out of memory,
crtc-base.id);
return;
}
- state-acquire_ctx = dev-mode_config.acquire_ctx;
-
- /* The force restore path in the HW readout code relies on the staged
-* config still keeping the user requested config while the actual
-* state has been overwritten by the configuration read from HW. We
-* need to copy the staged config to the atomic state, otherwise the
-* mode set will just reapply the state the HW is already in. */
- for_each_intel_encoder(dev, encoder) {
- if (encoder-base.crtc != crtc)
- continue;
+ state-acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
- for_each_intel_connector(dev, connector) {
- if (connector-base.state-best_encoder !=
- encoder-base)
- continue;
-
- connector_state = drm_atomic_get_connector_state(state,
connector-base);
- if (IS_ERR(connector_state)) {
- DRM_DEBUG_KMS(Failed to add [CONNECTOR:%d:%s]
to state: %ld\n,
- connector-base.base.id,
- connector-base.name,
- PTR_ERR(connector_state));
- continue;
- }
+retry:
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ ret = PTR_ERR_OR_ZERO(crtc_state);
+ if (!ret) {
+ if (!crtc_state-active)
+ goto out;
- connector_state-crtc = crtc;
- }
+ crtc_state-mode_changed = true;
+ ret = intel_set_mode(state);
}
- crtc_state = intel_atomic_get_crtc_state(state, to_intel_crtc(crtc));
- if (IS_ERR(crtc_state)) {
- DRM_DEBUG_KMS(Failed to add [CRTC:%d] to state: %ld\n,
- crtc-base.id, PTR_ERR(crtc_state));
- drm_atomic_state_free(state);
- return;
+ if (ret == -EDEADLK) {
+ drm_atomic_state_clear(state);
+ drm_modeset_backoff(state-acquire_ctx);
+ goto retry;
}
- drm_mode_copy(crtc_state-base.mode, crtc-mode);
-
- intel_modeset_setup_plane_state(state, crtc, crtc-mode,
- crtc-primary-fb, crtc-x, crtc-y);
-
- ret = intel_set_mode(state);
if (ret)
+out:
drm_atomic_state_free(state);
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 20/20] drm/i915: Remove use of runtime pm in atomic commit functions
We needed this originally for updating pagetables in plane commit
functions. But that's extracted into prepare/cleanup now. The other
issue was running updates when the pipe was off. That's also now
fixed.
Suggested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cc8ae7601884..9bf67e34961c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13637,14 +13637,11 @@ intel_disable_primary_plane(struct drm_plane *plane,
static void intel_begin_crtc_commit(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
if (intel_crtc-atomic.update_wm_pre)
intel_update_watermarks(crtc);
- intel_runtime_pm_get(dev_priv);
-
/* Perform vblank evasion around commit operation */
if (crtc-state-active)
intel_pipe_update_start(intel_crtc,
intel_crtc-atomic.start_vbl_count);
@@ -13655,14 +13652,10 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc)
static void intel_finish_crtc_commit(struct drm_crtc *crtc)
{
- struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
if (crtc-state-active)
intel_pipe_update_end(intel_crtc,
intel_crtc-atomic.start_vbl_count);
-
- intel_runtime_pm_put(dev_priv);
}
/**
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 12/20] drm/i915: Convert resume to atomic.
Instead of all the ad-hoc updating, duplicate the old state first
before reading out the hw state, then restore it.
intel_display_resume is a new function that duplicates the sw state,
then reads out the hw state, and commits the old state.
intel_display_setup_hw_state now only reads out the atomic state.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90396
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/intel_display.c | 77 ++--
drivers/gpu/drm/i915/intel_lvds.c| 2 +-
4 files changed, 60 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e44dc0d6656f..db48aee7f140 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -741,7 +741,7 @@ static int i915_drm_resume(struct drm_device *dev)
spin_unlock_irq(dev_priv-irq_lock);
drm_modeset_lock_all(dev);
- intel_modeset_setup_hw_state(dev, true);
+ intel_display_resume(dev);
drm_modeset_unlock_all(dev);
intel_dp_mst_resume(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 38cfd53bc262..d3e14cb43924 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3279,8 +3279,7 @@ extern void intel_modeset_gem_init(struct drm_device
*dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
extern void intel_connector_unregister(struct intel_connector *);
extern int intel_modeset_vga_set_state(struct drm_device *dev, bool state);
-extern void intel_modeset_setup_hw_state(struct drm_device *dev,
-bool force_restore);
+extern void intel_display_resume(struct drm_device *dev);
extern void i915_redisable_vga(struct drm_device *dev);
extern void i915_redisable_vga_power_on(struct drm_device *dev);
extern bool ironlake_set_drps(struct drm_device *dev, u8 val);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a4a2c3fbdc2d..b8984b4f8081 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -109,6 +109,7 @@ static void skl_init_scalers(struct drm_device *dev, struct
intel_crtc *intel_cr
struct intel_crtc_state *crtc_state);
static int i9xx_get_refclk(const struct intel_crtc_state *crtc_state,
int num_connectors);
+static void intel_modeset_setup_hw_state(struct drm_device *dev);
static struct intel_encoder *intel_find_encoder(struct intel_connector
*connector, int pipe)
{
@@ -3249,7 +3250,7 @@ void intel_finish_reset(struct drm_device *dev)
dev_priv-display.hpd_irq_setup(dev);
spin_unlock_irq(dev_priv-irq_lock);
- intel_modeset_setup_hw_state(dev, true);
+ intel_display_resume(dev);
intel_hpd_init(dev_priv);
@@ -15163,7 +15164,7 @@ void intel_modeset_init(struct drm_device *dev)
intel_fbc_disable(dev_priv);
drm_modeset_lock_all(dev);
- intel_modeset_setup_hw_state(dev, false);
+ intel_modeset_setup_hw_state(dev);
drm_modeset_unlock_all(dev);
for_each_intel_crtc(dev, crtc) {
@@ -15542,10 +15543,11 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
}
}
-/* Scan out the current hw modeset state, sanitizes it and maps it into the drm
- * and i915 state tracking structures. */
-void intel_modeset_setup_hw_state(struct drm_device *dev,
- bool force_restore)
+/* Scan out the current hw modeset state,
+ * and sanitizes it to the current state
+ */
+static void
+intel_modeset_setup_hw_state(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
enum pipe pipe;
@@ -15588,24 +15590,59 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
else if (HAS_PCH_SPLIT(dev))
ilk_wm_get_hw_state(dev);
- if (force_restore) {
- i915_redisable_vga(dev);
+ intel_modeset_update_staged_output_state(dev);
+}
- /*
-* We need to use raw interfaces for restoring state to avoid
-* checking (bogus) intermediate states.
-*/
- for_each_pipe(dev_priv, pipe) {
- struct drm_crtc *crtc =
- dev_priv-pipe_to_crtc_mapping[pipe];
+void intel_display_resume(struct drm_device *dev)
+{
+ struct drm_atomic_state *state = drm_atomic_state_alloc(dev);
+ struct intel_connector *conn;
+ struct intel_plane *plane;
+ struct drm_crtc *crtc;
+ int ret;
- intel_crtc_restore_mode(crtc);
- }
- } else {
- intel_modeset_update_staged_output_state(dev);
+ if (!state)
+
[Intel-gfx] [PATCH v3 09/20] drm/i915: Fill in more crtc state, v3.
There is a small memory leak in intel_modeset_readout_hw_state,
plug it.
intel_sanitize_crtc should set a null mode when disabling the crtc,
this updates crtc_state-enable too.
intel_sanitize_crtc also needs to update the vblank timestamps before
enabling vblank to make it work right.
Changes since v1:
- Moved after reworking primary plane and updating mode members.
- Force a modeset calculation by changing mode-type from what the
final mode will be.
Changes since v2:
- Do not fill out mode, this should only be done for supporting fastboot.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d37f6a93b094..819a2b551f1f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15248,6 +15248,7 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc)
/* restore vblank interrupts to correct state */
drm_crtc_vblank_reset(crtc-base);
if (crtc-active) {
+ drm_calc_timestamping_constants(crtc-base,
crtc-base.hwmode);
update_scanline_offset(crtc);
drm_crtc_vblank_on(crtc-base);
}
@@ -15300,7 +15301,7 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc)
crtc-base.state-enable ? enabled : disabled,
crtc-active ? enabled : disabled);
- crtc-base.state-enable = crtc-active;
+ WARN_ON(drm_atomic_set_mode_for_crtc(crtc-base.state, NULL)
0);
crtc-base.state-active = crtc-active;
crtc-base.enabled = crtc-active;
@@ -15450,6 +15451,7 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
int i;
for_each_intel_crtc(dev, crtc) {
+ __drm_atomic_helper_crtc_destroy_state(crtc-base,
crtc-base.state);
memset(crtc-config, 0, sizeof(*crtc-config));
crtc-config-base.crtc = crtc-base;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 18/20] drm/i915: Call plane update functions directly from intel_atomic_commit.
Now that there's only a single path for all atomic updates we can call
intel_(pre/post)_plane_update from intel_atomic_commit directly. This
makes the intention more clear.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 510e31f16135..fd41cfa92d3d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13292,12 +13292,19 @@ static int intel_atomic_commit(struct drm_device *dev,
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
for_each_crtc_in_state(state, crtc, crtc_state, i) {
- if (needs_modeset(crtc-state) crtc-state-active) {
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ bool modeset = needs_modeset(crtc-state);
+
+ if (modeset crtc-state-active) {
update_scanline_offset(to_intel_crtc(crtc));
dev_priv-display.crtc_enable(crtc);
}
+ if (!modeset)
+ intel_pre_plane_update(intel_crtc);
+
drm_atomic_helper_commit_planes_on_crtc(crtc_state);
+ intel_post_plane_update(intel_crtc);
}
/* FIXME: add subpixel order */
@@ -13635,9 +13642,6 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- if (!needs_modeset(crtc-state))
- intel_pre_plane_update(intel_crtc);
-
if (intel_crtc-atomic.update_wm_pre)
intel_update_watermarks(crtc);
@@ -13664,8 +13668,6 @@ static void intel_finish_crtc_commit(struct drm_crtc
*crtc)
intel_crtc-atomic.start_vbl_count);
intel_runtime_pm_put(dev_priv);
-
- intel_post_plane_update(intel_crtc);
}
/**
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 16/20] drm/i915: Make intel_display_suspend atomic, try 2.
Calculate all state using a normal transition, but afterwards fudge
crtc-state-active back to its old value. This should still allow
state restore in setup_hw_state to work properly.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 52 +---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 599af76d34f6..6e3df10a43b9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6224,12 +6224,58 @@ static void intel_crtc_disable_noatomic(struct drm_crtc
*crtc)
* turn all crtc's off, but do not adjust state
* This has to be paired with a call to intel_modeset_setup_hw_state.
*/
-void intel_display_suspend(struct drm_device *dev)
+int intel_display_suspend(struct drm_device *dev)
{
+ struct drm_mode_config *config = dev-mode_config;
+ struct drm_modeset_acquire_ctx *ctx = config-acquire_ctx;
+ struct drm_atomic_state *state;
struct drm_crtc *crtc;
+ unsigned crtc_mask = 0;
+ int ret = 0;
+
+ if (WARN_ON(!ctx))
+ return 0;
+
+ lockdep_assert_held(ctx-ww_ctx);
+ state = drm_atomic_state_alloc(dev);
+ if (WARN_ON(!state))
+ return -ENOMEM;
+
+ state-acquire_ctx = ctx;
+ state-allow_modeset = true;
+
+ for_each_crtc(dev, crtc) {
+ struct drm_crtc_state *crtc_state =
+ drm_atomic_get_crtc_state(state, crtc);
- for_each_crtc(dev, crtc)
- intel_crtc_disable_noatomic(crtc);
+ ret = PTR_ERR_OR_ZERO(crtc_state);
+ if (ret)
+ goto free;
+
+ if (!crtc_state-active)
+ continue;
+
+ crtc_state-active = false;
+ crtc_mask |= 1 drm_crtc_index(crtc);
+ }
+
+ if (crtc_mask) {
+ ret = intel_set_mode(state);
+
+ if (!ret) {
+ for_each_crtc(dev, crtc)
+ if (crtc_mask (1 drm_crtc_index(crtc)))
+ crtc-state-active = true;
+
+ return ret;
+ }
+ }
+
+free:
+ if (ret)
+ DRM_ERROR(Suspending crtc's failed with %i\n, ret);
+ drm_atomic_state_free(state);
+ return ret;
}
/* Master function to enable/disable CRTC and corresponding power wells */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 217b773e0673..f4abce103221 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -988,7 +988,7 @@ int intel_pch_rawclk(struct drm_device *dev);
void intel_mark_busy(struct drm_device *dev);
void intel_mark_idle(struct drm_device *dev);
void intel_crtc_restore_mode(struct drm_crtc *crtc);
-void intel_display_suspend(struct drm_device *dev);
+int intel_display_suspend(struct drm_device *dev);
int intel_crtc_control(struct drm_crtc *crtc, bool enable);
void intel_crtc_update_dpms(struct drm_crtc *crtc);
void intel_encoder_destroy(struct drm_encoder *encoder);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 03/20] drm/i915: Do not use plane_config in intel_fbdev.c
Use the atomic state instead, this allows removing plane_config
from the crtc after the full hw readout is completed.
The size can be found in the fb, no need for the plane_config.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_fbdev.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 33b3c9233eac..b791f2374f3b 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -581,7 +581,6 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
struct intel_framebuffer *fb = NULL;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
- struct intel_initial_plane_config *plane_config = NULL;
unsigned int max_size = 0;
if (!i915.fastboot)
@@ -589,20 +588,21 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
/* Find the largest fb */
for_each_crtc(dev, crtc) {
+ struct drm_i915_gem_object *obj =
+ intel_fb_obj(crtc-primary-state-fb);
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc-active || !crtc-primary-fb) {
+ if (!intel_crtc-active || !obj) {
DRM_DEBUG_KMS(pipe %c not active or no fb, skipping\n,
pipe_name(intel_crtc-pipe));
continue;
}
- if (intel_crtc-plane_config.size max_size) {
+ if (obj-base.size max_size) {
DRM_DEBUG_KMS(found possible fb from plane %c\n,
pipe_name(intel_crtc-pipe));
- plane_config = intel_crtc-plane_config;
- fb = to_intel_framebuffer(crtc-primary-fb);
- max_size = plane_config-size;
+ fb = to_intel_framebuffer(crtc-primary-state-fb);
+ max_size = obj-base.size;
}
}
@@ -637,7 +637,6 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
DRM_DEBUG_KMS(fb not wide enough for plane %c (%d vs
%d)\n,
pipe_name(intel_crtc-pipe),
cur_size, fb-base.pitches[0]);
- plane_config = NULL;
fb = NULL;
break;
}
@@ -658,7 +657,6 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
DRM_DEBUG_KMS(fb not big enough for plane %c (%d vs
%d)\n,
pipe_name(intel_crtc-pipe),
cur_size, max_size);
- plane_config = NULL;
fb = NULL;
break;
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 14/20] drm/i915: Update power domains on readout.
This allows us to get rid of the set_init_power in
modeset_update_crtc_domains. The state should be sanitized enough
after setup_hw_state to not need the init power.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 76
1 file changed, 50 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6bab045b389c..f6c65706cebf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5194,6 +5194,9 @@ static unsigned long get_crtc_power_domains(struct
drm_crtc *crtc)
unsigned long mask;
enum transcoder transcoder;
+ if (!crtc-state-active)
+ return 0;
+
transcoder = intel_pipe_to_cpu_transcoder(dev-dev_private, pipe);
mask = BIT(POWER_DOMAIN_PIPE(pipe));
@@ -5208,27 +5211,46 @@ static unsigned long get_crtc_power_domains(struct
drm_crtc *crtc)
return mask;
}
-static void modeset_update_crtc_power_domains(struct drm_atomic_state *state)
+static unsigned long modeset_get_crtc_power_domains(struct drm_crtc *crtc)
{
- struct drm_device *dev = state-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- unsigned long pipe_domains[I915_MAX_PIPES] = { 0, };
- struct intel_crtc *crtc;
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum intel_display_power_domain domain;
+ unsigned long domains, new_domains, old_domains;
- /*
-* First get all needed power domains, then put all unneeded, to avoid
-* any unnecessary toggling of the power wells.
-*/
- for_each_intel_crtc(dev, crtc) {
- enum intel_display_power_domain domain;
+ old_domains = intel_crtc-enabled_power_domains;
+ intel_crtc-enabled_power_domains = new_domains =
get_crtc_power_domains(crtc);
- if (!crtc-base.state-enable)
- continue;
+ domains = new_domains ~old_domains;
+
+ for_each_power_domain(domain, domains)
+ intel_display_power_get(dev_priv, domain);
+
+ return old_domains ~new_domains;
+}
+
+static void modeset_put_power_domains(struct drm_i915_private *dev_priv,
+ unsigned long domains)
+{
+ enum intel_display_power_domain domain;
+
+ for_each_power_domain(domain, domains)
+ intel_display_power_put(dev_priv, domain);
+}
- pipe_domains[crtc-pipe] = get_crtc_power_domains(crtc-base);
+static void modeset_update_crtc_power_domains(struct drm_atomic_state *state)
+{
+ struct drm_device *dev = state-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long put_domains[I915_MAX_PIPES] = {};
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc;
+ int i;
- for_each_power_domain(domain, pipe_domains[crtc-pipe])
- intel_display_power_get(dev_priv, domain);
+ for_each_crtc_in_state(state, crtc, crtc_state, i) {
+ if (needs_modeset(crtc-state))
+ put_domains[to_intel_crtc(crtc)-pipe] =
+ modeset_get_crtc_power_domains(crtc);
}
if (dev_priv-display.modeset_commit_cdclk) {
@@ -5239,16 +5261,9 @@ static void modeset_update_crtc_power_domains(struct
drm_atomic_state *state)
dev_priv-display.modeset_commit_cdclk(state);
}
- for_each_intel_crtc(dev, crtc) {
- enum intel_display_power_domain domain;
-
- for_each_power_domain(domain, crtc-enabled_power_domains)
- intel_display_power_put(dev_priv, domain);
-
- crtc-enabled_power_domains = pipe_domains[crtc-pipe];
- }
-
- intel_display_set_init_power(dev_priv, false);
+ for (i = 0; i I915_MAX_PIPES; i++)
+ if (put_domains[i])
+ modeset_put_power_domains(dev_priv, put_domains[i]);
}
static void intel_update_max_cdclk(struct drm_device *dev)
@@ -15547,6 +15562,15 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
skl_wm_get_hw_state(dev);
else if (HAS_PCH_SPLIT(dev))
ilk_wm_get_hw_state(dev);
+
+ for_each_intel_crtc(dev, crtc) {
+ unsigned long put_domains;
+
+ put_domains = modeset_get_crtc_power_domains(crtc-base);
+ if (WARN_ON(put_domains))
+ modeset_put_power_domains(dev_priv, put_domains);
+ }
+ intel_display_set_init_power(dev_priv, false);
}
void intel_display_resume(struct drm_device *dev)
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH v3 00/20] Convert to atomic, part 4.
Atomic suspend/resume, full hardware readout and atomic ioctl support. Changes from the previous version: - The fastboot changes from the previous patch have been removed, fastboot will have to be a separate patch because of the testing it needs. - I've cleaned up the changes to planes and split it into separate patches. This makes it easier to bisect. - Some commit logs have been updated. Maarten Lankhorst (20): drm/i915: Only update state on crtc's that are part of the atomic state. drm/i915: Do not update pfit state when toggling crtc enabled. drm/i915: Do not use plane_config in intel_fbdev.c drm/i915: Allow fuzzy matching in pipe_config_compare, v2. drm/i915: Update missing properties in find_initial_plane_obj drm/i915: Remove plane_config from struct intel_crtc. drm/i915: Rework plane readout. drm/i915: fill in more mode members drm/i915: Fill in more crtc state, v3. drm/i915: Set csc coefficients in intel_sanitize_crtc. drm/i915: Readout initial hw mode. drm/i915: Convert resume to atomic. drm/i915: Get rid of unused transitional members. drm/i915: Update power domains on readout. drm/i915: Always reset in intel_crtc_restore_mode drm/i915: Make intel_display_suspend atomic, try 2. drm/i915: Use full atomic modeset. drm/i915: Call plane update functions directly from intel_atomic_commit. drm/i915: always disable irqs in intel_pipe_update_start drm/i915: Remove use of runtime pm in atomic commit functions drivers/gpu/drm/i915/i915_drv.c |4 +- drivers/gpu/drm/i915/i915_drv.h |4 +- drivers/gpu/drm/i915/i915_params.c |5 - drivers/gpu/drm/i915/intel_atomic.c | 144 + drivers/gpu/drm/i915/intel_display.c | 1083 +++--- drivers/gpu/drm/i915/intel_dp.c |2 +- drivers/gpu/drm/i915/intel_drv.h | 25 +- drivers/gpu/drm/i915/intel_fbdev.c | 25 +- drivers/gpu/drm/i915/intel_lvds.c|2 +- drivers/gpu/drm/i915/intel_sprite.c | 17 +- 10 files changed, 517 insertions(+), 794 deletions(-) -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 10/20] drm/i915: Set csc coefficients in intel_sanitize_crtc.
This might not have been set during boot, and when we preserve the initial mode this can result in a black screen. Cc: Daniel Stone dani...@collabora.com Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 819a2b551f1f..80e878929bab 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15251,6 +15251,9 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc) drm_calc_timestamping_constants(crtc-base, crtc-base.hwmode); update_scanline_offset(crtc); drm_crtc_vblank_on(crtc-base); + + if (IS_HASWELL(dev) || INTEL_INFO(dev)-gen 7) + intel_set_pipe_csc(crtc-base); } /* We need to sanitize the plane - pipe mapping first because this will -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On (07/13/15 16:35), Daniel Vetter wrote: On Mon, Jul 13, 2015 at 09:51:39PM +0900, Sergey Senozhatsky wrote: 4.2.0-rc2-next-20150713 Is this also an issue in the 4.2-rc series or only in -next? don't know how to reproduce this, but I'll check. -ss [ 1239.783862] [ cut here ] [ 1239.783892] WARNING: CPU: 0 PID: 364 at drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() [ 1239.783894] WARN_ON(new-frontbuffer_bits frontbuffer_bits) [ 1239.783895] Modules linked in: [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress lzo_decompress zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 mac80211 cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel iwlwifi i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac cfg80211 lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 mxm_wmi wmi i8042 evdev video serio backlight processor ext4 crc16 mbcache jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 [ 1239.783944] 0009 88041c5379d8 813a19ac 81077163 [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 88041c5379f8 [ 1239.783950] a0533273 0002 88041c578000 88041c578000 [ 1239.783953] Call Trace: [ 1239.783961] [813a19ac] dump_stack+0x4c/0x65 [ 1239.783965] [81077163] ? up+0x39/0x3e [ 1239.783968] [8103b5d9] warn_slowpath_common+0x9b/0xb5 [ 1239.783986] [a0533273] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.783987] [8103b639] warn_slowpath_fmt+0x46/0x48 [ 1239.784002] [a0533273] i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.784026] [a0575928] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 1239.784033] [a0261f0f] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 1239.784055] [a0585596] intel_atomic_commit+0x46/0xc0 [i915] [ 1239.784072] [a02d2139] drm_atomic_commit+0x4d/0x52 [drm] [ 1239.784078] [a0262f32] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 1239.784092] [a02c7572] __setplane_internal+0x24e/0x2ae [drm] [ 1239.784103] [a02c771b] drm_mode_cursor_universal+0x149/0x197 [drm] [ 1239.784113] [a02c7e58] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 1239.784122] [a02c781e] drm_mode_cursor_common+0xb5/0x156 [drm] [ 1239.784132] [a02c7e8f] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 1239.784140] [a02bae85] drm_ioctl+0x287/0x415 [drm] [ 1239.784143] [81078580] ? __lock_is_held+0x3c/0x57 [ 1239.784146] [8114c3d1] ? __fget+0x170/0x1a1 [ 1239.784148] [811422c1] do_vfs_ioctl+0x455/0x4dd [ 1239.784151] [8114c48e] ? __fget_light+0x65/0x75 [ 1239.784153] [8114238d] SyS_ioctl+0x44/0x63 [ 1239.784155] [813a8057] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't forget to mark crtc as inactive after disable
On Mon, Jul 13, 2015 at 11:42:34AM +0100, Damien Lespiau wrote: On Mon, Jul 13, 2015 at 11:49:49AM +0200, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 11:10:51AM +0200, Maarten Lankhorst wrote: Op 10-07-15 om 13:22 schreef Damien Lespiau: Hi Patrik, Please do Cc the patch author and reviewer when finding a regression, they are superb candidates for the review, especially when they are busy rewriting the display code. Yeah you need to list everyone you want to Cc: explicitly. Also need the Bugzilla reference when fixing a bug. In this case: https://bugs.freedesktop.org/show_bug.cgi?id=91203 Added, thanks for supplying the link. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On (07/13/15 16:46), Maarten Lankhorst wrote: [ 1239.783961] [813a19ac] dump_stack+0x4c/0x65 [ 1239.783965] [81077163] ? up+0x39/0x3e [ 1239.783968] [8103b5d9] warn_slowpath_common+0x9b/0xb5 [ 1239.783986] [a0533273] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.783987] [8103b639] warn_slowpath_fmt+0x46/0x48 [ 1239.784002] [a0533273] i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.784026] [a0575928] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 1239.784033] [a0261f0f] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 1239.784055] [a0585596] intel_atomic_commit+0x46/0xc0 [i915] [ 1239.784072] [a02d2139] drm_atomic_commit+0x4d/0x52 [drm] [ 1239.784078] [a0262f32] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 1239.784092] [a02c7572] __setplane_internal+0x24e/0x2ae [drm] [ 1239.784103] [a02c771b] drm_mode_cursor_universal+0x149/0x197 [drm] [ 1239.784113] [a02c7e58] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 1239.784122] [a02c781e] drm_mode_cursor_common+0xb5/0x156 [drm] [ 1239.784132] [a02c7e8f] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 1239.784140] [a02bae85] drm_ioctl+0x287/0x415 [drm] [ 1239.784143] [81078580] ? __lock_is_held+0x3c/0x57 [ 1239.784146] [8114c3d1] ? __fget+0x170/0x1a1 [ 1239.784148] [811422c1] do_vfs_ioctl+0x455/0x4dd [ 1239.784151] [8114c48e] ? __fget_light+0x65/0x75 [ 1239.784153] [8114238d] SyS_ioctl+0x44/0x63 [ 1239.784155] [813a8057] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- Do you have some steps to reproduce? Unfortunately no. -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/gen9: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround
Arun Siluvery arun.siluv...@linux.intel.com writes:
In Indirect context w/a batch buffer,
+WaFlushCoherentL3CacheLinesAtContextSwitch:bdw
s/bdw/skl ?
v2: address static checker warning where unsigned value was checked for
less than zero which is never true.
Add ^^ (Dan Carpenter)
Reported-by: Dan Carpenter dan.carpen...@oracle.com
And remove this line as this would mean the workaround/bug
in question would be reported by Dan.
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 6a0b128..7536682 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1253,6 +1253,7 @@ static int gen9_init_indirectctx_bb(struct
intel_engine_cs *ring,
uint32_t *const batch,
uint32_t *offset)
{
+ int ret;
struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
@@ -1261,6 +1262,12 @@ static int gen9_init_indirectctx_bb(struct
intel_engine_cs *ring,
(IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0)))
wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_DISABLE);
+ /* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt */
+ ret = gen8_emit_flush_coherentl3_wa(ring, batch, index);
Not shown in this patch but the above function assumes default
value for GEN8_L3SQCREG4 which doesn't match what we have by
default.
This is due to skl_init_clock_gating() setting up one bit
in this register.
I think the proper way to fix this would be remove the
write from skl_init_clock_gating() and setup all
the bits in this register, even the default ones with
WA_SET_BIT() in gen9_init_workarounds().
And then search the default value out from the wa list,
when you build the batch.
But if you choose to go with default skl value of
0x4840, make a comment to intel_pm.c and also
the gen8_emit_flush_coherentl3_wa() that you
have a dependency.
-Mika
+ if (ret 0)
+ return ret;
+ index = ret;
+
/* Pad to end of cacheline */
while (index % CACHELINE_DWORDS)
wa_ctx_emit(batch, MI_NOOP);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 01/20] drm/i915: Only update state on crtc's that are part of the atomic state.
This is probably hard to hit right now because in most cases all
atomic locks are taken, but after conversion to atomic this will make
it more likely to corrupt the crtc-config pointer, resulting in hard
to find bugs.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 887ba0a54352..f9b1db734502 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12314,6 +12314,7 @@ intel_modeset_update_state(struct drm_atomic_state
*state)
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
+ int i;
intel_shared_dpll_commit(state);
@@ -12333,7 +12334,7 @@ intel_modeset_update_state(struct drm_atomic_state
*state)
intel_modeset_update_staged_output_state(state-dev);
/* Double check state. */
- for_each_crtc(dev, crtc) {
+ for_each_crtc_in_state(state, crtc, crtc_state, i) {
WARN_ON(crtc-state-enable != intel_crtc_in_use(crtc));
to_intel_crtc(crtc)-config = to_intel_crtc_state(crtc-state);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 08/20] drm/i915: fill in more mode members
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 118187dc76be..d37f6a93b094 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7754,9 +7754,14 @@ void intel_mode_from_pipe_config(struct drm_display_mode *mode, mode-vsync_end = pipe_config-base.adjusted_mode.crtc_vsync_end; mode-flags = pipe_config-base.adjusted_mode.flags; + mode-type = DRM_MODE_TYPE_DRIVER; mode-clock = pipe_config-base.adjusted_mode.crtc_clock; mode-flags |= pipe_config-base.adjusted_mode.flags; + + mode-hsync = drm_mode_hsync(mode); + mode-vrefresh = drm_mode_vrefresh(mode); + drm_mode_set_name(mode); } static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc) -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 02/20] drm/i915: Do not update pfit state when toggling crtc enabled.
There's not much point for calculating the changes for the old
state. Instead just disable all scalers when disabling. It's
probably good enough to just disable the crtc_scaler, but just in
case there's a bug disable all scalers.
This means intel_atomic_setup_scalers is only called in the crtc
check function now, so all the transitional code can be removed.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_atomic.c | 14 ++--
drivers/gpu/drm/i915/intel_display.c | 68 +++-
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
4 files changed, 48 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 5c79a31603af..b92b8581efc2 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -272,17 +272,12 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
struct drm_plane *plane = NULL;
struct intel_plane *intel_plane;
struct intel_plane_state *plane_state = NULL;
- struct intel_crtc_scaler_state *scaler_state;
- struct drm_atomic_state *drm_state;
+ struct intel_crtc_scaler_state *scaler_state =
+ crtc_state-scaler_state;
+ struct drm_atomic_state *drm_state = crtc_state-base.state;
int num_scalers_need;
int i, j;
- if (INTEL_INFO(dev)-gen 9 || !intel_crtc || !crtc_state)
- return 0;
-
- scaler_state = crtc_state-scaler_state;
- drm_state = crtc_state-base.state;
-
num_scalers_need = hweight32(scaler_state-scaler_users);
DRM_DEBUG_KMS(crtc_state = %p need = %d avail = %d scaler_users =
0x%x\n,
crtc_state, num_scalers_need, intel_crtc-num_scalers,
@@ -326,9 +321,6 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
} else {
name = PLANE;
- if (!drm_state)
- continue;
-
/* plane scaler case: assign as a plane scaler */
/* find the plane that set the bit as scaler_user */
plane = drm_state-planes[i];
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f9b1db734502..6eed925f3300 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2909,29 +2909,32 @@ unsigned long intel_plane_obj_offset(struct intel_plane
*intel_plane,
return i915_gem_obj_ggtt_offset_view(obj, view);
}
+static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
+{
+ struct drm_device *dev = intel_crtc-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ I915_WRITE(SKL_PS_CTRL(intel_crtc-pipe, id), 0);
+ I915_WRITE(SKL_PS_WIN_POS(intel_crtc-pipe, id), 0);
+ I915_WRITE(SKL_PS_WIN_SZ(intel_crtc-pipe, id), 0);
+ DRM_DEBUG_KMS(CRTC:%d Disabled scaler id %u.%u\n,
+ intel_crtc-base.base.id, intel_crtc-pipe, id);
+}
+
/*
* This function detaches (aka. unbinds) unused scalers in hardware
*/
static void skl_detach_scalers(struct intel_crtc *intel_crtc)
{
- struct drm_device *dev;
- struct drm_i915_private *dev_priv;
struct intel_crtc_scaler_state *scaler_state;
int i;
- dev = intel_crtc-base.dev;
- dev_priv = dev-dev_private;
scaler_state = intel_crtc-config-scaler_state;
/* loop through and disable scalers that aren't in use */
for (i = 0; i intel_crtc-num_scalers; i++) {
- if (!scaler_state-scalers[i].in_use) {
- I915_WRITE(SKL_PS_CTRL(intel_crtc-pipe, i), 0);
- I915_WRITE(SKL_PS_WIN_POS(intel_crtc-pipe, i), 0);
- I915_WRITE(SKL_PS_WIN_SZ(intel_crtc-pipe, i), 0);
- DRM_DEBUG_KMS(CRTC:%d Disabled scaler id %u.%u\n,
- intel_crtc-base.base.id, intel_crtc-pipe, i);
- }
+ if (!scaler_state-scalers[i].in_use)
+ skl_detach_scaler(intel_crtc, i);
}
}
@@ -4362,13 +4365,12 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
* skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
*
* @state: crtc's scaler state
- * @force_detach: whether to forcibly disable scaler
*
* Return
* 0 - scaler_usage updated successfully
*error - requested scaling cannot be supported or other error condition
*/
-int skl_update_scaler_crtc(struct intel_crtc_state *state, int force_detach)
+int skl_update_scaler_crtc(struct intel_crtc_state *state)
{
struct intel_crtc *intel_crtc = to_intel_crtc(state-base.crtc);
struct drm_display_mode *adjusted_mode =
@@ -4377,7 +4379,7 @@ int skl_update_scaler_crtc(struct intel_crtc_state
[Intel-gfx] [PATCH v3 11/20] drm/i915: Readout initial hw mode.
Atomic requires a mode blob when crtc_state-enable is true.
With a few tweaks the mode we read out from hardware could be used
as the real mode without a modeset, but this requires too much
testing, so force a modeset the first time the mode blob's updated.
This preserves the old behavior, because previously we never set
the initial mode, which always meant that a modeset happened
when the mode was first set.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 38
drivers/gpu/drm/i915/intel_fbdev.c | 11 +++
2 files changed, 20 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 80e878929bab..a4a2c3fbdc2d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13153,7 +13153,7 @@ intel_modeset_compute_config(struct drm_atomic_state
*state)
for_each_crtc_in_state(state, crtc, crtc_state, i) {
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
- bool modeset, recalc;
+ bool modeset, recalc = false;
if (!crtc_state-enable) {
if (needs_modeset(crtc_state))
@@ -13162,7 +13162,9 @@ intel_modeset_compute_config(struct drm_atomic_state
*state)
}
modeset = needs_modeset(crtc_state);
- recalc = pipe_config-quirks PIPE_CONFIG_QUIRK_INHERITED_MODE;
+ if (!modeset crtc_state-mode_blob != crtc-state-mode_blob
+ pipe_config-quirks PIPE_CONFIG_QUIRK_INHERITED_MODE)
+ recalc = true;
if (!modeset !recalc)
continue;
@@ -13177,9 +13179,10 @@ intel_modeset_compute_config(struct drm_atomic_state
*state)
if (ret)
return ret;
- if (recalc !intel_pipe_config_compare(state-dev,
+ if (recalc (!i915.fastboot ||
+ !intel_pipe_config_compare(state-dev,
to_intel_crtc_state(crtc-state),
- pipe_config, true)) {
+ pipe_config, true))) {
modeset = crtc_state-mode_changed = true;
ret = drm_atomic_add_affected_planes(state, crtc);
@@ -15463,11 +15466,19 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
crtc-active = dev_priv-display.get_pipe_config(crtc,
crtc-config);
- crtc-base.state-enable = crtc-active;
crtc-base.state-active = crtc-active;
crtc-base.enabled = crtc-active;
- crtc-base.hwmode = crtc-config-base.adjusted_mode;
+ memset(crtc-base.mode, 0, sizeof(crtc-base.mode));
+ if (crtc-base.state-active) {
+ intel_mode_from_pipe_config(crtc-base.mode,
crtc-config);
+
intel_mode_from_pipe_config(crtc-base.state-adjusted_mode, crtc-config);
+ WARN_ON(drm_atomic_set_mode_for_crtc(crtc-base.state,
crtc-base.mode));
+
+ crtc-base.state-mode.type = 0;
+ }
+
+ crtc-base.hwmode = crtc-config-base.adjusted_mode;
readout_plane_state(crtc,
to_intel_crtc_state(crtc-base.state));
DRM_DEBUG_KMS([CRTC:%d] hw state readout: %s\n,
@@ -15544,21 +1,6 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
intel_modeset_readout_hw_state(dev);
- /*
-* Now that we have the config, copy it to each CRTC struct
-* Note that this could go away if we move to using crtc_config
-* checking everywhere.
-*/
- for_each_intel_crtc(dev, crtc) {
- if (crtc-active i915.fastboot) {
- intel_mode_from_pipe_config(crtc-base.mode,
- crtc-config);
- DRM_DEBUG_KMS([CRTC:%d] found active mode: ,
- crtc-base.base.id);
- drm_mode_debug_printmodeline(crtc-base.mode);
- }
- }
-
/* HW state is read out, now we need to sanitize this mess. */
for_each_intel_encoder(dev, encoder) {
intel_sanitize_encoder(encoder);
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index b791f2374f3b..7eff33ff84f6 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -483,18 +483,13 @@ retry:
* IMPORTANT: We want to use the adjusted mode (i.e.
* after the panel fitter upscaling) as the initial
[Intel-gfx] [PATCH v3 04/20] drm/i915: Allow fuzzy matching in pipe_config_compare, v2.
Instead of doing ad-hoc checks we already have a way of checking
if the state is compatible or not. Use this to force a modeset.
Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE
we should check if a full modeset is really needed.
Fastboot will allow the adjust parameter to ignore some stuff
too, and it will fix up differences in state that are ignored
by the compare function.
Changes since v1:
- Increase the value of the lowest m/n to prevent truncation.
- Dump pipe config when fastboot's used, without a modeset.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 218 +--
1 file changed, 157 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6eed925f3300..c3a3d108 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12290,19 +12290,6 @@ encoder_retry:
DRM_DEBUG_KMS(plane bpp: %i, pipe bpp: %i, dithering: %i\n,
base_bpp, pipe_config-pipe_bpp, pipe_config-dither);
- /* Check if we need to force a modeset */
- if (pipe_config-has_audio !=
- to_intel_crtc_state(crtc-state)-has_audio) {
- pipe_config-base.mode_changed = true;
- ret = drm_atomic_add_affected_planes(state, crtc);
- }
-
- /*
-* Note we have an issue here with infoframes: current code
-* only updates them on the full mode set path per hw
-* requirements. So here we should be checking for any
-* required changes and forcing a mode set.
-*/
fail:
return ret;
}
@@ -12406,27 +12393,133 @@ static bool intel_fuzzy_clock_check(int clock1, int
clock2)
base.head) \
if (mask (1 (intel_crtc)-pipe))
+
+static bool
+intel_compare_m_n(unsigned int m, unsigned int n,
+ unsigned int m2, unsigned int n2,
+ bool exact)
+{
+ if (m == m2 n == n2)
+ return true;
+
+ if (exact || !m || !n || !m2 || !n2)
+ return false;
+
+ BUILD_BUG_ON(DATA_LINK_M_N_MASK INT_MAX);
+
+ if (m m2) {
+ while (m m2) {
+ m2 = 1;
+ n2 = 1;
+ }
+ } else if (m m2) {
+ while (m m2) {
+ m = 1;
+ n = 1;
+ }
+ }
+
+ return m == m2 n == n2;
+}
+
+static bool
+intel_compare_link_m_n(const struct intel_link_m_n *m_n,
+ struct intel_link_m_n *m2_n2,
+ bool adjust)
+{
+ if (m_n-tu == m2_n2-tu
+ intel_compare_m_n(m_n-gmch_m, m_n-gmch_n,
+ m2_n2-gmch_m, m2_n2-gmch_n, !adjust)
+ intel_compare_m_n(m_n-link_m, m_n-link_n,
+ m2_n2-link_m, m2_n2-link_n, !adjust)) {
+ if (adjust)
+ *m2_n2 = *m_n;
+
+ return true;
+ }
+
+ return false;
+}
+
static bool
intel_pipe_config_compare(struct drm_device *dev,
struct intel_crtc_state *current_config,
- struct intel_crtc_state *pipe_config)
+ struct intel_crtc_state *pipe_config,
+ bool adjust)
{
+ bool ret = true;
+
+#define INTEL_ERR_OR_DBG_KMS(fmt, ...) \
+ do { \
+ if (!adjust) \
+ DRM_ERROR(fmt, ##__VA_ARGS__); \
+ else \
+ DRM_DEBUG_KMS(fmt, ##__VA_ARGS__); \
+ } while (0)
+
#define PIPE_CONF_CHECK_X(name)\
if (current_config-name != pipe_config-name) { \
- DRM_ERROR(mismatch in #name \
+ INTEL_ERR_OR_DBG_KMS(mismatch in #name \
(expected 0x%08x, found 0x%08x)\n, \
current_config-name, \
pipe_config-name); \
- return false; \
+ ret = false; \
}
#define PIPE_CONF_CHECK_I(name)\
if (current_config-name != pipe_config-name) { \
- DRM_ERROR(mismatch in #name \
+ INTEL_ERR_OR_DBG_KMS(mismatch in #name \
(expected %i, found %i)\n, \
current_config-name, \
pipe_config-name); \
- return false; \
+ ret = false; \
+ }
+
+#define PIPE_CONF_CHECK_M_N(name) \
+ if (!intel_compare_link_m_n(current_config-name, \
+ pipe_config-name,\
+ adjust)) { \
+ INTEL_ERR_OR_DBG_KMS(mismatch in #name \
+ (expected tu %i gmch %i/%i link %i/%i, \
+ found tu %i, gmch %i/%i link %i/%i)\n, \
+
[Intel-gfx] [PATCH v3 06/20] drm/i915: Remove plane_config from struct intel_crtc.
Nothing depends on this outside initial hw readout, so keep this
struct on the stack instead.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 037a85f1b127..e4d8acc63823 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15204,7 +15204,9 @@ void intel_modeset_init(struct drm_device *dev)
drm_modeset_unlock_all(dev);
for_each_intel_crtc(dev, crtc) {
- if (!crtc-active)
+ struct intel_initial_plane_config plane_config;
+
+ if (!crtc-base.state-active)
continue;
/*
@@ -15214,15 +15216,16 @@ void intel_modeset_init(struct drm_device *dev)
* can even allow for smooth boot transitions if the BIOS
* fb is large enough for the active pipe configuration.
*/
- if (dev_priv-display.get_initial_plane_config) {
- dev_priv-display.get_initial_plane_config(crtc,
- crtc-plane_config);
- /*
-* If the fb is shared between multiple heads, we'll
-* just get the first one.
-*/
- intel_find_initial_plane_obj(crtc, crtc-plane_config);
- }
+
+ plane_config.fb = NULL;
+ dev_priv-display.get_initial_plane_config(crtc,
+ plane_config);
+
+ /*
+* If the fb is shared between multiple heads, we'll
+* just get the first one.
+*/
+ intel_find_initial_plane_obj(crtc, plane_config);
}
}
@@ -15713,6 +15716,8 @@ void intel_modeset_gem_init(struct drm_device *dev)
if (ret) {
DRM_ERROR(failed to pin boot fb on pipe %d\n,
to_intel_crtc(c)-pipe);
+ obj-frontbuffer_bits =
+ ~to_intel_plane(c-primary)-frontbuffer_bit;
drm_framebuffer_unreference(c-primary-fb);
c-primary-fb = NULL;
c-primary-crtc = c-primary-state-crtc = NULL;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 09a0a9222a3a..09e3581c8441 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -550,7 +550,6 @@ struct intel_crtc {
uint32_t cursor_size;
uint32_t cursor_base;
- struct intel_initial_plane_config plane_config;
struct intel_crtc_state *config;
bool new_enabled;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround
On Mon, Jul 13, 2015 at 03:31:45PM +0300, Mika Kuoppala wrote:
Arun Siluvery arun.siluv...@linux.intel.com writes:
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).
Cc: Robert Beckett robert.beck...@intel.com
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com
Merged first two patches of this series to dinq, thanks.
-Daniel
---
drivers/gpu/drm/i915/intel_lrc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 1e88b3b..e84fc52 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1274,10 +1274,13 @@ static int gen9_init_indirectctx_bb(struct
intel_engine_cs *ring,
uint32_t *const batch,
uint32_t *offset)
{
+ struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
- /* FIXME: Replace me with WA */
- wa_ctx_emit(batch, MI_NOOP);
+ /* WaDisableCtxRestoreArbitration:skl,bxt */
+ if ((IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_D0)) ||
+ (IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0)))
+ wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_DISABLE);
/* Pad to end of cacheline */
while (index % CACHELINE_DWORDS)
@@ -1291,8 +1294,14 @@ static int gen9_init_perctx_bb(struct
intel_engine_cs *ring,
uint32_t *const batch,
uint32_t *offset)
{
+ struct drm_device *dev = ring-dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
+ /* WaDisableCtxRestoreArbitration:skl,bxt */
+ if ((IS_SKYLAKE(dev) (INTEL_REVID(dev) = SKL_REVID_D0)) ||
+ (IS_BROXTON(dev) (INTEL_REVID(dev) == BXT_REVID_A0)))
+ wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_ENABLE);
+
wa_ctx_emit(batch, MI_BATCH_BUFFER_END);
return wa_ctx_end(wa_ctx, *offset = index, 1);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check live status before reading edid
On Mon, Jul 13, 2015 at 04:35:00PM +0530, Sonika Jindal wrote:
Adding this for SKL onwards.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 42
+
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..7b54b9d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
return intel_dp_detect_dpcd(intel_dp);
}
-static int g4x_digital_port_connected(struct drm_device *dev,
-struct intel_digital_port
*intel_dig_port)
+int g4x_digital_port_connected(struct drm_device *dev,
+struct intel_digital_port *intel_dig_port)
{
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index a47fbc3..30c8dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
void intel_edp_drrs_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
+int g4x_digital_port_connected(struct drm_device *dev,
+struct intel_digital_port *intel_dig_port);
/* intel_dp_mst.c */
int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1fb6919..7eb0d0e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,39 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
to_intel_connector(connector)-detect_edid = NULL;
}
+static bool bxt_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *port)
+{
+ u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+ switch (port-port) {
+ case PORT_B:
+ return temp BXT_DE_PORT_HP_DDIB;
+
+ case PORT_C:
+ return temp BXT_DE_PORT_HP_DDIC;
+
+ default:
+ return false;
+
+ }
+}
+
+static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
+{
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ if (IS_VALLEYVIEW(dev))
+ return g4x_digital_port_connected(dev, intel_dig_port);
+ else if (IS_SKYLAKE(dev))
+ return ibx_digital_port_connected(dev_priv, intel_dig_port);
+ else if (IS_BROXTON(dev))
+ return bxt_port_connected(dev_priv, intel_dig_port);
Really I want this to be rolled out for all platforms, together with the
fix for handling hpd interrupts. Together with a reference to the old
commits we had to revert because it didn't work.
I want to test this on my ivb (since that's the machine where I can
readily reproduce this bug), and if it still doesn't work there I won't
take this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation
On Mon, Jul 13, 2015 at 12:11:08PM +0200, Hans Verkuil wrote: On 07/13/2015 11:54 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 11:43:31AM +0200, Hans Verkuil wrote: On 07/13/2015 11:18 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: On 06/15/2015 08:53 AM, Daniel Vetter wrote: On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: From: Kausal Malladi kausal.mall...@intel.com This patch set adds color manager implementation in drm/i915 layer. Color Manager is an extension in i915 driver to support color correction/enhancement. Various Intel platforms support several color correction capabilities. Color Manager provides abstraction of these properties and allows a user space UI agent to correct/enhance the display. So I did a first rough pass on the API itself. The big question that isn't solved at the moment is: do we want to try to do generic KMS properties for pre-LUT + matrix + post-LUT or not. Generic has 3 levels: 1/ Generic for all KMS drivers 2/ Generic for i915 supported platfoms 3/ Specific to each platform At this point, I'm quite tempted to say we should give 1/ a shot. We should be able to have pre-LUT + matrix + post-LUT on CRTC objects and guarantee that, when the drivers expose such properties, user space can at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. It may be possible to use the try version of the atomic ioctl to explore the space of possibilities from a generic user space to use bigger LUTs as well. A HAL layer (which is already there in some but not all OSes) would still be able to use those generic properties to load precision optimized LUTs with some knowledge of the hardware. Yeah, imo 1/ should be doable. For the matrix we should be able to be fully generic with a 16.16 format. For gamma one option would be to have I know I am late replying, apologies for that. I've been working on CSC support for V4L2 as well (still work in progress) and I would like to at least end up with the same low-level fixed point format as DRM so we can share matrix/vector calculations. Based on my experiences I have concerns about the 16.16 format: the precision is quite low which can be a problem when such values are used in matrix multiplications. In addition, while the precision may be sufficient for 8 bit color component values, I'm pretty sure it will be insufficient when dealing with 12 or 16 bit color components. In earlier versions of my CSC code I used a 12.20 format, but in the latest I switched to 32.32. This fits nicely in a u64 and it's easy to extract the integer and fractional parts. If this is going to be a generic and future proof API, then my suggestion would be to increase the precision of the underlying data type. We discussed this a bit more internally and figured it would be nice to have the same fixed point for both CSC matrix and LUT/gamma tables. Current consensus seems to be to go with 8.24 for both. Since LUTs are fairly big I think it makes sense if we try to be not too wasteful (while still future-proof ofc). The .24 should have enough precision, but I am worried about the 8: while this works for 8 bit components, you can't use it to represent values 255, which might be needed (now or in the future) for 10, 12 or 16 bit color components. It's why I ended up with 32.32: it's very generic so usable for other things besides CSC. Note that 8.24 is really 7.24 + one sign bit. So 255 can't be represented in this format. That said, all values I'm working with in my current code are small integers (say between -4 and 4 worst case), so 8.24 would work. But I am not at all confident that this is future proof. My gut feeling is that you need to be able to represent at least the max component value + a sign bit + 7 decimals precision. Which makes 17.24. The idea is to steal from GL and always normalize everything to [0.0, 1.0], irrespective of the source color format. We need that in drm since if you blend together planes with different formats it's completely undefined which one you should pick. 8 bits of precision for values out of range should be enough ;-) That doesn't really help much, using a [0-1] range just means that you need more precision for the fraction since the integer precision is now added to the fractional precision. So for 16-bit color components the 8.24 format will leave you with only 8 bits precision if you scale each component to the [0-1] range. That's slightly more than 2 decimals. I don't believe that is enough. If you do a gamma table lookup and then feed the result to a CSC matrix you need more precision if you want to get accurate results. Hm, why do we need 8 bits more precision than source data? At least in the
Re: [Intel-gfx] [PATCH v4 03/18] drm/i915/gen8: Add PML4 structure
On 7/11/2015 9:02 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:14:48PM +0100, Michel Thierry wrote:
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
Cc: Akash Goel akash.g...@intel.com
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 7 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 40 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 35
3 files changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 464b28d..de3a5d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2497,7 +2497,12 @@ struct drm_i915_cmd_table {
#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)-gen = 6)
#define HAS_LOGICAL_RING_CONTEXTS(dev)(INTEL_INFO(dev)-gen = 8)
#define USES_PPGTT(dev) (i915.enable_ppgtt)
-#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt == 2)
+#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt = 2)
+#ifdef CONFIG_X86_64
+# define USES_FULL_48BIT_PPGTT(dev)(i915.enable_ppgtt == 3)
+#else
+# define USES_FULL_48BIT_PPGTT(dev)false
+#endif
This requires an explanation.
-Chris
Actually, this is no longer necessary after Mika's changes:
commit c44ef60e437019b8ca1dab8b4d2e8761fd4ce1e9
Author: Mika Kuoppala mika.kuopp...@linux.intel.com
Date: Thu Jun 25 18:35:05 2015 +0300
drm/i915/gtt: Allow = 4GB sizes for vm.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to stop_rings mode bits
On Mon, Jul 13, 2015 at 09:43:11AM +, Gore, Tim wrote: Tim Gore Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, July 13, 2015 10:30 AM To: Gore, Tim Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas Subject: Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to stop_rings mode bits On Fri, Jul 10, 2015 at 02:06:06PM +0100, tim.g...@intel.com wrote: From: Tim Gore tim.g...@intel.com In function igt_set_stop_rings, the test igt_assert_f(flags == 0 || current == 0, .. will fail if we are trying to force a hang but the STOP_RINGS_ALLOW_BAN or STOP_RINGS_ALLOW_ERROR bit is set. With the introduction of per ring resets in the driver (in android) these bits do not get cleared to zero when an individual ring is reset. This causes subsequent attempt to cause a ring hang via this function to fail, leading to several igt tests failing (ie gem_reset_stats subtest ban-xxx etc). Fix tdr to reset these instead? -Daniel I could change tdr, but why. When the TDR handles a ring hang and resets the ring, why would it modify the flag that defines if the driver should ban a frequently hanging context? If we get rid of the stop_rings interface, as Chris Wilson suggested, we would still need to keep the STOP_RING_ALLOW_BAN/ALLOW_ERRORS bits in debugfs, but you would not expect to have to re-write these bits each time there is a ring reset. The fix current hang recover code to no reset this, add some grace period, then push this patch to igt. We don't have full-blown abi guarantees for debugfs/igt stuff, but I want at least a few months (really last released kerneligt) of backwards/forward compatibility. And inconsistent behaviour isn't great imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build warnings after merge of the drm-misc tree
Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/gpu/drm/bochs/bochs_fbdev.c: In function 'bochsfb_create': drivers/gpu/drm/bochs/bochs_fbdev.c:63:17: warning: unused variable 'device' [-Wunused-variable] struct device *device = dev-pdev-dev; ^ Caused by commit 394111a2b303 (drm/boschs: Use new drm_fb_helper functions) drivers/gpu/drm/cirrus/cirrus_fbdev.c: In function 'cirrusfb_create': drivers/gpu/drm/cirrus/cirrus_fbdev.c:247:1: warning: label 'out_iounmap' defined but not used [-Wunused-label] out_iounmap: ^ Caused by commit fd6ab591ce15 (drm/cirrus: Use new drm_fb_helper functions) drivers/gpu/drm/ast/ast_fb.c: In function 'astfb_create': drivers/gpu/drm/ast/ast_fb.c:196:17: warning: unused variable 'device' [-Wunused-variable] struct device *device = dev-pdev-dev; ^ Caused by commit 6f4900cd28c9 (drm/ast: Use new drm_fb_helper functions) drivers/gpu/drm/gma500/framebuffer.c: In function 'psbfb_create': drivers/gpu/drm/gma500/framebuffer.c:346:17: warning: unused variable 'device' [-Wunused-variable] struct device *device = dev-pdev-dev; ^ Caused by commit 3b9a13e85365 (drm/gma500: Use new drm_fb_helper functions) drivers/gpu/drm/mgag200/mgag200_fb.c: In function 'mgag200fb_create': drivers/gpu/drm/mgag200/mgag200_fb.c:232:1: warning: label 'out' defined but not used [-Wunused-label] out: ^ drivers/gpu/drm/mgag200/mgag200_fb.c:169:17: warning: unused variable 'device' [-Wunused-variable] struct device *device = dev-pdev-dev; ^ Caused by commit 53ebb642ccba (drm/mgag200: Use new drm_fb_helper functions) drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c: In function 'amdgpufb_create': drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:206:9: warning: passing argument 1 of 'PTR_ERR' makes pointer from integer without a cast ret = PTR_ERR(ret); ^ In file included from arch/x86/include/asm/processor.h:31:0, from arch/x86/include/asm/thread_info.h:49, from include/linux/thread_info.h:54, from arch/x86/include/asm/preempt.h:6, from include/linux/preempt.h:64, from include/linux/spinlock.h:50, from include/linux/seqlock.h:35, from include/linux/time.h:5, from include/linux/stat.h:18, from include/linux/module.h:10, from drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:26: include/linux/err.h:28:33: note: expected 'const void *' but argument is of type 'int' static inline long __must_check PTR_ERR(__force const void *ptr) ^ drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:182:17: warning: unused variable 'device' [-Wunused-variable] struct device *device = adev-pdev-dev; ^ drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c: In function 'amdgpu_fbdev_destroy': drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:283:18: warning: unused variable 'info' [-Wunused-variable] struct fb_info *info; ^ Caused by commit 9d70561ba3b1 (drm/amdgpu: Use new drm_fb_helper functions) drivers/gpu/drm/udl/udl_fb.c: In function 'udlfb_create': drivers/gpu/drm/udl/udl_fb.c:479:17: warning: unused variable 'device' [-Wunused-variable] struct device *device = dev-dev; ^ Caused by commit 457959f2ed5f (drm/udl: Use new drm_fb_helper functions) drivers/gpu/drm/radeon/radeon_fb.c: In function 'radeonfb_create': drivers/gpu/drm/radeon/radeon_fb.c:230:17: warning: unused variable 'device' [-Wunused-variable] struct device *device = rdev-pdev-dev; ^ Caused by commit 4bc29bb98bae (drm/radeon: Use new drm_fb_helper functions) drivers/gpu/drm/nouveau/nouveau_fbcon.c: In function 'nouveau_fbcon_create': drivers/gpu/drm/nouveau/nouveau_fbcon.c:322:18: warning: unused variable 'pdev' [-Wunused-variable] struct pci_dev *pdev = dev-pdev; ^ Caused by commit 237fc6452ca5 (drm/nouveau: Use new drm_fb_helper functions) I think COMPILE TESTED ONLY should at least include eliminating such warnings ... -- Cheers, Stephen Rothwells...@canb.auug.org.au pgppqziGryNOA.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commit:
8aa3053bf731 (drm/i915: fix oops in primary_check_plane)
from the drm-intel-fixes tree and commit:
da20eabd2c69 (drm/i915: Split plane updates of crtc-atomic into a helper,
v2.)
from the drm-intel tree.
I fixed it up (but it probably needs more - see below) and can carry
the fix as necessary.
Daniel, can you please merge your fixes branch into your main branch
(maybe after Linus has merged it) and fix these conflicts correctly as
these conflicts tend to go on and on as the files get changed.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index 85ac6d85dc39,00c60c1c5162..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4851,25 -4802,13 +4802,16 @@@ static void intel_crtc_disable_planes(s
{
struct drm_device *dev = crtc-dev;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_plane *intel_plane;
+ struct drm_plane *p;
int pipe = intel_crtc-pipe;
+ if (!intel_crtc-active)
+ return;
+
- intel_crtc_wait_for_pending_flips(crtc);
-
- intel_pre_disable_primary(crtc);
-
intel_crtc_dpms_overlay_disable(intel_crtc);
- for_each_intel_plane(dev, intel_plane) {
- if (intel_plane-pipe == pipe) {
- struct drm_crtc *from = intel_plane-base.crtc;
- intel_plane-disable_plane(intel_plane-base,
- from ?: crtc, true);
- }
- }
+ drm_for_each_plane_mask(p, dev, plane_mask)
+ to_intel_plane(p)-disable_plane(p, crtc);
/*
* FIXME: Once we grow proper nuclear flip support out of this we need
@@@ -13382,47 -13751,11 +13757,14 @@@ static void intel_begin_crtc_commit(str
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_plane *intel_plane;
- struct drm_plane *p;
- unsigned fb_bits = 0;
-
- /* Track fb's for any planes being disabled */
- list_for_each_entry(p, dev-mode_config.plane_list, head) {
- intel_plane = to_intel_plane(p);
-
- if (intel_crtc-atomic.disabled_planes
- (1 drm_plane_index(p))) {
- switch (p-type) {
- case DRM_PLANE_TYPE_PRIMARY:
- fb_bits =
INTEL_FRONTBUFFER_PRIMARY(intel_plane-pipe);
- break;
- case DRM_PLANE_TYPE_CURSOR:
- fb_bits =
INTEL_FRONTBUFFER_CURSOR(intel_plane-pipe);
- break;
- case DRM_PLANE_TYPE_OVERLAY:
- fb_bits =
INTEL_FRONTBUFFER_SPRITE(intel_plane-pipe);
- break;
- }
- mutex_lock(dev-struct_mutex);
- i915_gem_track_fb(intel_fb_obj(p-fb), NULL, fb_bits);
- mutex_unlock(dev-struct_mutex);
- }
- }
-
- if (intel_crtc-atomic.wait_for_flips)
- intel_crtc_wait_for_pending_flips(crtc);
-
- if (intel_crtc-atomic.disable_fbc)
- intel_fbc_disable(dev);
+ if (!needs_modeset(crtc-state))
+ intel_pre_plane_update(intel_crtc);
+ if (intel_crtc-atomic.disable_ips)
+ hsw_disable_ips(intel_crtc);
+
- if (intel_crtc-atomic.pre_disable_primary)
- intel_pre_disable_primary(crtc);
-
- if (intel_crtc-atomic.update_wm)
+ if (intel_crtc-atomic.update_wm_pre)
intel_update_watermarks(crtc);
intel_runtime_pm_get(dev_priv);
pgpPBUU1Esxgt.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Provide compat ioctl for addfb2.1
btw, I mentioned on irc, but someone *really* ought to go through the
ioclt structs and split each struct member into it's own line, so
things like '__u32 width, height' aren't so sneaky ;-)
On Mon, Jul 13, 2015 at 11:56 AM, Tvrtko Ursulin
tvrtko.ursu...@linux.intel.com wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Frame buffer modifiers extensions provided in;
commit e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark robdcl...@gmail.com
Date: Thu Feb 5 14:41:52 2015 +
drm: add support for tiled/compressed/etc modifier in addfb2
Missed the structure packing/alignment problem where 64-bit
members were added after the odd number of 32-bit ones. This
makes the compiler produce structures of different sizes under
32- and 64-bit x86 targets and makes the ioctl need explicit
compat handling.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: dri-de...@lists.freedesktop.org
Cc: Rob Clark robdcl...@gmail.com
Cc: Daniel Stone dani...@collabora.com
Cc: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/drm_ioc32.c | 60
+
1 file changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index aa8bbb460c57..2bea11bfb3ae 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -70,6 +70,8 @@
#define DRM_IOCTL_WAIT_VBLANK32DRM_IOWR(0x3a,
drm_wait_vblank32_t)
+#define DRM_IOCTL_MODE_ADDFB232DRM_IOWR(0xb8,
drm_mode_fb_cmd232_t)
+
typedef struct drm_version_32 {
int version_major;/** Major version */
int version_minor;/** Minor version */
@@ -1016,6 +1018,63 @@ static int compat_drm_wait_vblank(struct file *file,
unsigned int cmd,
return 0;
}
+typedef struct drm_mode_fb_cmd232 {
+ u32 fb_id;
+ u32 width;
+ u32 height;
+ u32 pixel_format;
+ u32 flags;
+ u32 handles[4];
+ u32 pitches[4];
+ u32 offsets[4];
+ u64 modifier[4];
+} __attribute__((packed)) drm_mode_fb_cmd232_t;
+
+static int compat_drm_mode_addfb2(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ drm_mode_fb_cmd232_t __user *argp = (void __user *)arg;
+ struct drm_mode_fb_cmd232 req32;
+ struct drm_mode_fb_cmd2 __user *req64;
+ int i;
+ int err;
+
+ if (copy_from_user(req32, argp, sizeof(req32)))
+ return -EFAULT;
+
+ req64 = compat_alloc_user_space(sizeof(*req64));
+
+ if (!access_ok(VERIFY_WRITE, req64, sizeof(*req64))
+ || __put_user(req32.width, req64-width)
+ || __put_user(req32.height, req64-height)
+ || __put_user(req32.pixel_format, req64-pixel_format)
+ || __put_user(req32.flags, req64-flags))
+ return -EFAULT;
+
+ for (i = 0; i 4; i++) {
+ if (__put_user(req32.handles[i], req64-handles[i]))
+ return -EFAULT;
+ if (__put_user(req32.pitches[i], req64-pitches[i]))
+ return -EFAULT;
+ if (__put_user(req32.offsets[i], req64-offsets[i]))
+ return -EFAULT;
+ if (__put_user(req32.modifier[i], req64-modifier[i]))
+ return -EFAULT;
+ }
+
+ err = drm_ioctl(file, DRM_IOCTL_MODE_ADDFB2, (unsigned long)req64);
+ if (err)
+ return err;
+
+ if (__get_user(req32.fb_id, req64-fb_id))
+ return -EFAULT;
+
+ if (copy_to_user(argp, req32, sizeof(req32)))
+ return -EFAULT;
+
+ return 0;
+}
+
static drm_ioctl_compat_t *drm_compat_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_VERSION32)] = compat_drm_version,
[DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE32)] = compat_drm_getunique,
@@ -1048,6 +1107,7 @@ static drm_ioctl_compat_t *drm_compat_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_UPDATE_DRAW32)] = compat_drm_update_draw,
#endif
[DRM_IOCTL_NR(DRM_IOCTL_WAIT_VBLANK32)] = compat_drm_wait_vblank,
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_ADDFB232)] = compat_drm_mode_addfb2,
};
/**
--
2.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 19/20] drm/i915: always disable irqs in intel_pipe_update_start
Hi, On 13 July 2015 at 15:30, Maarten Lankhorst maarten.lankho...@linux.intel.com wrote: @@ -13649,9 +13647,7 @@ static void intel_begin_crtc_commit(struct drm_crtc *crtc) /* Perform vblank evasion around commit operation */ if (crtc-state-active) - intel_crtc-atomic.evade = - intel_pipe_update_start(intel_crtc, - intel_crtc-atomic.start_vbl_count); + intel_pipe_update_start(intel_crtc, intel_crtc-atomic.start_vbl_count); if (!needs_modeset(crtc-state) INTEL_INFO(dev)-gen = 9) skl_detach_scalers(intel_crtc); @@ -13663,9 +13659,8 @@ static void intel_finish_crtc_commit(struct drm_crtc *crtc) struct drm_i915_private *dev_priv = dev-dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - if (intel_crtc-atomic.evade) - intel_pipe_update_end(intel_crtc, - intel_crtc-atomic.start_vbl_count); Can we get rid of the 'evade' member in the struct now? Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Provide compat ioctl for addfb2.1
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Frame buffer modifiers extensions provided in;
commit e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark robdcl...@gmail.com
Date: Thu Feb 5 14:41:52 2015 +
drm: add support for tiled/compressed/etc modifier in addfb2
Missed the structure packing/alignment problem where 64-bit
members were added after the odd number of 32-bit ones. This
makes the compiler produce structures of different sizes under
32- and 64-bit x86 targets and makes the ioctl need explicit
compat handling.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: dri-de...@lists.freedesktop.org
Cc: Rob Clark robdcl...@gmail.com
Cc: Daniel Stone dani...@collabora.com
Cc: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/drm_ioc32.c | 60 +
1 file changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index aa8bbb460c57..2bea11bfb3ae 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -70,6 +70,8 @@
#define DRM_IOCTL_WAIT_VBLANK32DRM_IOWR(0x3a,
drm_wait_vblank32_t)
+#define DRM_IOCTL_MODE_ADDFB232DRM_IOWR(0xb8,
drm_mode_fb_cmd232_t)
+
typedef struct drm_version_32 {
int version_major;/** Major version */
int version_minor;/** Minor version */
@@ -1016,6 +1018,63 @@ static int compat_drm_wait_vblank(struct file *file,
unsigned int cmd,
return 0;
}
+typedef struct drm_mode_fb_cmd232 {
+ u32 fb_id;
+ u32 width;
+ u32 height;
+ u32 pixel_format;
+ u32 flags;
+ u32 handles[4];
+ u32 pitches[4];
+ u32 offsets[4];
+ u64 modifier[4];
+} __attribute__((packed)) drm_mode_fb_cmd232_t;
+
+static int compat_drm_mode_addfb2(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ drm_mode_fb_cmd232_t __user *argp = (void __user *)arg;
+ struct drm_mode_fb_cmd232 req32;
+ struct drm_mode_fb_cmd2 __user *req64;
+ int i;
+ int err;
+
+ if (copy_from_user(req32, argp, sizeof(req32)))
+ return -EFAULT;
+
+ req64 = compat_alloc_user_space(sizeof(*req64));
+
+ if (!access_ok(VERIFY_WRITE, req64, sizeof(*req64))
+ || __put_user(req32.width, req64-width)
+ || __put_user(req32.height, req64-height)
+ || __put_user(req32.pixel_format, req64-pixel_format)
+ || __put_user(req32.flags, req64-flags))
+ return -EFAULT;
+
+ for (i = 0; i 4; i++) {
+ if (__put_user(req32.handles[i], req64-handles[i]))
+ return -EFAULT;
+ if (__put_user(req32.pitches[i], req64-pitches[i]))
+ return -EFAULT;
+ if (__put_user(req32.offsets[i], req64-offsets[i]))
+ return -EFAULT;
+ if (__put_user(req32.modifier[i], req64-modifier[i]))
+ return -EFAULT;
+ }
+
+ err = drm_ioctl(file, DRM_IOCTL_MODE_ADDFB2, (unsigned long)req64);
+ if (err)
+ return err;
+
+ if (__get_user(req32.fb_id, req64-fb_id))
+ return -EFAULT;
+
+ if (copy_to_user(argp, req32, sizeof(req32)))
+ return -EFAULT;
+
+ return 0;
+}
+
static drm_ioctl_compat_t *drm_compat_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_VERSION32)] = compat_drm_version,
[DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE32)] = compat_drm_getunique,
@@ -1048,6 +1107,7 @@ static drm_ioctl_compat_t *drm_compat_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_UPDATE_DRAW32)] = compat_drm_update_draw,
#endif
[DRM_IOCTL_NR(DRM_IOCTL_WAIT_VBLANK32)] = compat_drm_wait_vblank,
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_ADDFB232)] = compat_drm_mode_addfb2,
};
/**
--
2.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
