Re: [Intel-gfx] [PATCH] drm/i915: s/seqno/request/ tracking inside objects
On Mon, Jul 28, 2014 at 01:44:12PM -0700, Jesse Barnes wrote:
+static void
+i915_gem_object_retire(struct drm_i915_gem_object *obj)
+{
+ struct i915_gem_request *rq;
+ int i;
+
+ if (!obj-active)
+ return;
+
+ rq = obj-last_write.request;
+ if (rq i915_request_complete(rq, true))
+ i915_gem_object_retire__write(obj);
+
+ rq = obj-last_fence.request;
+ if (rq i915_request_complete(rq, true))
+ i915_gem_object_retire__fence(obj);
+
+ for (i = 0; i I915_NUM_RINGS; i++) {
+ rq = obj-last_read[i].request;
+ if (rq i915_request_complete(rq, true))
+ i915_gem_object_retire__read(obj, rq-ring);
+ }
+}
Unrelated comment on GEM in general: it seems like the callers of this
all use it after they've waited on the object; maybe it should just
be called from wait_rendering() to avoid any potential trouble? The
name is a bit ambiguous; it could be taken to mean that it does the
idling.
No. There be dragons. Quite a few of the (indirect) callers of
wait_rendering() cannot handle the recursive freeing of requests/objects
and so we must carefully inspect each caller.
-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
Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
On 2014/7/26 1:01, Konrad Rzeszutek Wilk wrote: On Thu, Jul 24, 2014 at 09:44:41AM +0800, Chen, Tiejun wrote: On 2014/7/24 4:54, Konrad Rzeszutek Wilk wrote: On Sat, Jul 19, 2014 at 12:27:21AM +, Kay, Allen M wrote: For the MCH PCI registers that do need to be read - can you tell us which ones those are? In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW. Some of the registers are needed by Ironlake GFX driver which we probably can remove. I did a trace recently on Broadwell, the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4). Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e. case 0x00:/* vendor id */ case 0x02:/* device id */ case 0x08:/* revision id */ case 0x2c:/* sybsystem vendor id */ case 0x2e:/* sybsystem id */ Right. We can fix the i915 to use the mechanism that Michael mentioned. (see attached RFC patches) case 0x50:/* SNB: processor graphics control register */ case 0x52:/* processor graphics control register */ case 0xa0:/* top of memory */ case 0xb0:/* ILK: BSM: should read from dev 2 offset 0x5c */ case 0x58:/* SNB: PAVPC Offset */ case 0xa4:/* SNB: graphics base of stolen memory */ case 0xa8:/* SNB: base of GTT stolen memory */ I dug in the intel-gtt.c (see ironlake_gtt_driver) to figure out this a bit more. As in, I speculated, what if we returned 0 (and not implement any support for reading from these registers). What would happen? 0x52 for Ironlake (g5): -- It looks like intel_gmch_probe is called when i915_gem_gtt_init starts (there is a lot of code that looks to be used between intel-gtt.c and i915.c). Anyhow the interesting parts are that i9xx_setup ends up calling ioremap the i915 BAR to setup some of these registers for older generations. Then i965_gtt_total_entries gets which reads 0x52, but it is only needed for v5 generation. For other (v4 and G33) it reads it from the GPU's 0x2020 register. If there is a mismatch, it writes to the GPU at 0x2020 to update the the size based on the bridge. And then it reads from 0x2020 and that is returned and stuck in intel_private.gtt_total_entries. So 0x52 in the emulated bridge could be populated with what the GPU has at 0x2020. And the writes go in the emulated area. 0x52 for v6 - v8: - We seem to go to gen6_gmch_probe which just figures out the the GTT based on the GPU's BAR sizes. The stolen values are read from 0x50 from the GPU. So no need to touch the bridge (see gen6_gmch_probe) OK, so no need to have 0x52 or 0x50 in the bridge. 0xA0: - Could not find any reference in the Linux code. Why would Windows driver need this? If we returned the _real_ TOM would it matter? Is it used to figure out the device should use 32-bit DMA operations or 40-bit? 0xb0 or 0x5c: - No mention of them in the Linux code. 0x58, 0xa4, 0xa8: - No usage of them in the Linux code. We seem to be using the 0x52 from the bridge and 0x2020 from the GPU for this functionality. So in theory*, if using Ironlake we need to have a proper value in 0x52 in the bridge. But for the later chipsets we do not need these values (I am assuming that intel_setup_mchbar can safely return as it does that for Ironlake and could very well for later generations). Can this be reflected in the Windows driver as well? P.S. *theory: That is assuming we modify the Linux i915_drv.c:intel_detect_pch to pick up the id as suggested earlier. See the RFC patches attached. (Not compile tested at all!) I take a look these patches, looks we still scan all PCI Bridge to walk all PCHs. So this means we still need to fake a PCI bridge, right? Or maybe you don't cover this problem this time. I totally forgot. Feel free to fix that. Sorry for this delay response. I prefer we should check dev slot to get that PCH like my previous patch, Uh? Your patch was checking for 0:1f.0, not the slot of the device. Yes. (see https://lkml.org/lkml/2014/6/19/121) gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type. Because Windows always use this way, so I think this point should be same between Linux and Windows. Didn't we discuss that we did not want to pass in PCH at all if we can? I'm a bit confused since I guess I'm missing something important in this long discussion. I guess we just fake a simple PCIe device but just has PCI_VENDOR_ID_XEN/Real_PCH_Device_ID, and then well probe such a PCIe device inside intel_detect_pch(), right? And this means we will not support those existing drivers? And from the
Re: [Intel-gfx] [PATCH] drm/i915: s/seqno/request/ tracking inside objects
On Mon, Jul 28, 2014 at 01:44:12PM -0700, Jesse Barnes wrote:
+static void i915_request_retire(struct i915_gem_request *rq)
{
- list_del(request-list);
- i915_gem_request_remove_from_client(request);
+ rq-completed = true;
+
+ list_del(rq-list);
+ i915_gem_request_remove_from_client(rq);
- if (request-ctx)
- i915_gem_context_unreference(request-ctx);
+ if (rq-ctx) {
+ i915_gem_context_unreference(rq-ctx);
+ rq-ctx = NULL;
+ }
- kfree(request);
+ i915_request_put(rq);
}
I wonder if we can somehow always use this function instead of having
both obj and request retire functions. Maybe if we moved obj retire
into the rendering sync functions we'd have a little less pseudo
duplication.
I kept it as it was as I was trying to avoid increasing the number of
calls to ring-get_seqno. Elsewhere converting to a fence is good at
reducing the number of calls (as that completed:1 is likely to catch
most cases). But here I think we really do want to treat this en masse.
request_retire does a put, where is the corresponding get so that we
don't lose the object when the lock is dropped here or in the
nonblocking wait? Or should request_retire not do a put?
Ownership flows from:
intel_ring_begin - i915_add_request - retire_request.
Everyone else has to grab their own references.
+static int
+i915_request_sync(struct i915_gem_request *rq,
+ struct intel_engine_cs *to,
+ struct drm_i915_gem_object *obj)
+{
+ int ret, idx;
+
+ if (to == NULL)
+ return i915_wait_request(rq);
+
+ /* XXX this is broken by VEBOX+ */
What does this comment mean? How does VEBOX break this? Does it not
have semaphore support or something?
It's a very old comment. In theory it should have been fixed by the recent
gen8 semaphore work.
@@ -3038,44 +3203,35 @@ out:
*/
int
i915_gem_object_sync(struct drm_i915_gem_object *obj,
-struct intel_engine_cs *to)
+struct intel_engine_cs *to,
+bool readonly)
{
It might be nice to have sync_read/sync_write functions instead, since
looking up bool args or unnamed enums is a pain.
Not convinced since it is used in a single location and two function
calls would look unelegant - but we could switch to PROT_READ |
PROT_WRITE throughout.
static bool
ring_idle(struct intel_engine_cs *ring, u32 seqno)
{
return (list_empty(ring-request_list) ||
- i915_seqno_passed(seqno, ring_last_seqno(ring)));
+ __i915_seqno_passed(seqno, ring_last_seqno(ring)));
}
Unrelated question: why do we have two checks here? Shouldn't the
seqno check always be sufficient? Or is the list_empty check for the
uninitialized case?
We can't test the seqno without testing that the pointer is valid -
that's the first check. And since we retire lazily we cannot rely on the
request_list being empty itself.
static int
-intel_ring_alloc_seqno(struct intel_engine_cs *ring)
+intel_ring_alloc_request(struct intel_engine_cs *ring)
{
- if (ring-outstanding_lazy_seqno)
- return 0;
+ struct i915_gem_request *rq;
+ int ret;
- if (ring-preallocated_lazy_request == NULL) {
- struct drm_i915_gem_request *request;
+ if (ring-preallocated_request)
+ return 0;
- request = kmalloc(sizeof(*request), GFP_KERNEL);
- if (request == NULL)
- return -ENOMEM;
+ rq = kmalloc(sizeof(*rq), GFP_KERNEL);
+ if (rq == NULL)
+ return -ENOMEM;
- ring-preallocated_lazy_request = request;
+ ret = i915_gem_get_seqno(ring-dev, rq-seqno);
+ if (ret) {
+ kfree(rq);
+ return ret;
}
- return i915_gem_get_seqno(ring-dev,
ring-outstanding_lazy_seqno);
+ kref_init(rq-kref);
+ rq-ring = ring;
+ rq-completed = false;
+
+ ring-preallocated_request = rq;
+ return 0;
}
Makes me wonder if we should have our own slab for the objs. Might
save a bit of mem and/or perf? But then could reduce our cache hit
rate, dunno.
It's just a case of whether we are in a general slab or a named slab.
Having a named slab is nice for debugging, and we definitely have a high
enough reuse rate to justify our own slab.
Elsewhere some useful comments deleted to save electrons :-)
-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
Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load thaw
On Mon, Jul 28, 2014 at 11:26:38AM +0200, Daniel Vetter wrote: Oh, I guess that's the tricky bit why the old approach never worked - because reset_in_progress is set we failed the context/ppgtt loading through the rings and screwed up. Problem with your approach is that we want to bail out here if a reset is in progress, so we can't just eat the EAGAIN. If we do that we potentially deadlock or overflow the ring. I think we need a different hack here, and a few layers down (i.e. at the place where we actually generate that offending -EAGAIN). - Around the re-init sequence in the reset function we set dev_priv-mm.reload_in_reset or similar. Since we hold dev-struct_mutex no one will see that, as long as we never leak it out of the critical section. - In the ring_begin code that checks for gpu hangs we ignore reset_in_progress if this bit is set. - Both places need fairly big comments to explain what exactly is going on. This is going from bad to worse. I think you can do better if you looked at the problem afresh. -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
Re: [Intel-gfx] [PATCH 45/53] drm/i915/bdw: Do not call intel_runtime_pm_get() in an interrupt
On Mon, Jul 28, 2014 at 10:54:06AM +0200, Daniel Vetter wrote: On Sat, Jul 26, 2014 at 11:27:38AM +0100, Chris Wilson wrote: On Wed, Jun 18, 2014 at 10:54:13PM +0200, Daniel Vetter wrote: On Fri, Jun 13, 2014 at 04:38:03PM +0100, oscar.ma...@intel.com wrote: From: Oscar Mateo oscar.ma...@intel.com Or with a spinlock grabbed, because it might sleep, which is not a nice thing to do. Instead, do the runtime_pm get/put together with the create/destroy request, and handle the forcewake get/put directly. Signed-off-by: Oscar Mateo oscar.ma...@intel.com Looks like a fixup that should be squashed into relevant earlier patches. The whole gen6_gt_force_wake_get() calling intel_runtime_pm_get() is broken due to this - we must be able to read registers in atomic context! Please revert c8c8fb33b37766acf6474784b0d5245dab9a1690 force_wake_get can't call runtime_pm_get becuase pm_get can sleep. So if you want to read registers from atomic context you have to have a runtime pm reference from someone else. Nope. That cannot work. -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
Re: [Intel-gfx] [PATCH 0/3] Fixes for runtime PM on planes APIs
On Tue, Jul 29, 2014 at 1:25 AM, Matt Roper matthew.d.ro...@intel.com wrote:
On Mon, Jul 28, 2014 at 03:37:11PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Hi
This series fixes some bugs that happen when we're runtime suspended and try
to
use the planes APIs. I also wrote IGT test cases for the bugs, so we will be
able to detect future regressions.
The controversial part of these patches is that we had previously defined
that
we wanted to get/put runtime PM in the highest level of the stack, wrapping
as
much code as possible, but Daniel asked me to only get/put runtime PM around
the
functions that pin the objects (still on the highest level, but only around
the
pin functions). This series implements Daniel's suggestions.
These look pretty straightforward to me, so for all three:
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
However as a side note on the runtime PM stuff I'll admit that it's not
an area I'd previously paid too much attention to and my first reaction
looking at the patches was I wonder if intel_runtime_pm_{get,put} could
be pushed down into intel_pin_and_fence_fb_obj(). Until I read your
cover letter I wasn't aware of the goal of get/put runtime PM in the
highest level of the stack, wrapping as much code as possible and I
don't think that's really explained anywhere in the code or in the
commit log today. Maybe we could add a comment in intel_pm.c explaining
that design goal for future contributors/reviewers?
Originally we had runtime pm calls way down, which in a few cases
meant that we'd dropped the runtime pm reference while we still
depended upon the register values surviving. Of course the usual timer
helps there. Hence why I've put out the push it to the highest level
possible guideline, to make sure that e.g. for a modeset sequence we
grab the runtime pm ref once, before we start touching any hardware.
Pinning stuff to the gtt (which is the only thing tricky here, after
the early bail-out for !crtc-active) is a bit different. Those
registers are magic aliases for memory regions, so even when we go
into runtime pm the register value will survive (since the ptes are
actually in main memory). We only need to wake up the gpu to make sure
they actually get there. And the pin plane while display is off case
is really special, all the pte writing we do in the gem code is done
as part of a userspace operation where we really need to have the gpu
on (and so where it makes sense to grab the runtime pm ref at the
top-level to make sure our setup doesn't disappear unexpectedly).
I hope this explains why these 3 cases are special.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
Il 29/07/2014 08:59, Chen, Tiejun ha scritto: (see https://lkml.org/lkml/2014/6/19/121) gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type. Because Windows always use this way, so I think this point should be same between Linux and Windows. Didn't we discuss that we did not want to pass in PCH at all if we can? I'm a bit confused since I guess I'm missing something important in this long discussion. I guess we just fake a simple PCIe device but just has PCI_VENDOR_ID_XEN/Real_PCH_Device_ID, and then well probe such a PCIe device inside intel_detect_pch(), right? Yes, for the special PIIX4 legacy machine type we want to do that and place the device at 00:1f.0. Paolo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
On 2014/7/29 16:32, Paolo Bonzini wrote: Il 29/07/2014 08:59, Chen, Tiejun ha scritto: (see https://lkml.org/lkml/2014/6/19/121) gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type. Because Windows always use this way, so I think this point should be same between Linux and Windows. Didn't we discuss that we did not want to pass in PCH at all if we can? I'm a bit confused since I guess I'm missing something important in this long discussion. I guess we just fake a simple PCIe device but just has PCI_VENDOR_ID_XEN/Real_PCH_Device_ID, and then well probe such a PCIe device inside intel_detect_pch(), right? Yes, for the special PIIX4 legacy machine type we want to do that and place the device at 00:1f.0. Got it. BTW, please review those patches implemented a separate machine, xenigd, firstly. Then I can step on this point. Thanks Tiejun ___ 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: Prevent recursive deadlock on releasing a busy userptr
On 07/23/2014 06:15 PM, Chris Wilson wrote:
On Wed, Jul 23, 2014 at 05:39:49PM +0100, Tvrtko Ursulin wrote:
On 07/21/2014 01:21 PM, Chris Wilson wrote:
+ mn = i915_mmu_notifier_get(obj-userptr.mm);
+ if (IS_ERR(mn))
+ return PTR_ERR(mn);
Very minor, but I would perhaps consider renaming this to _find
since _get in my mind strongly associates with reference counting
and this does not do that. Especially if the reviewer looks at the
bail out below and sees no matching put. But minor as I said, you
can judge what you prefer.
The same. It was _get because it did used to a reference counter, now
that counting has been removed from the i915_mmu_notifier.
+static int
+i915_gem_userptr_init__mm_struct(struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *dev_priv = to_i915(obj-base.dev);
+ struct i915_mm_struct *mm;
+ struct mm_struct *real;
+ int ret = 0;
+
+ real = get_task_mm(current);
+ if (real == NULL)
+ return -EINVAL;
Do you think we need get_task_mm()/mmput() here, given it is all
inside a single system call?
No. I kept using get_task_mm() simply because it looked neater than
current-mm, but current-mm looks like it gives simpler code.
+ /* During release of the GEM object we hold the struct_mutex. As the
+* object may be holding onto the last reference for the task-mm,
+* calling mmput() may trigger exit_mmap() which close the vma
+* which will call drm_gem_vm_close() and attempt to reacquire
+* the struct_mutex. In order to avoid that recursion, we have
+* to defer the mmput() until after we drop the struct_mutex,
+* i.e. we need to schedule a worker to do the clean up.
+*/
This comment reads like a strange mixture and past and present eg.
what used to be the case and what is the fix. We don't hold a
reference to the process mm as the address space (terminology OK?).
We do hold a reference to the mm struct itself - which is enough to
unregister the notifiers, correct?
True. I was more or less trying to explain the bug and that comment
ended up being the changelog entry. It doesn't work well as a comment.
+ /* During release of the GEM object we hold the struct_mutex. This
+* precludes us from calling mmput() at that time as that may be
+* the last reference and so call exit_mmap(). exit_mmap() will
+* attempt to reap the vma, and if we were holding a GTT mmap
+* would then call drm_gem_vm_close() and attempt to reacquire
+* the struct mutex. So in order to avoid that recursion, we have
+* to defer releasing the mm reference until after we drop the
+* struct_mutex, i.e. we need to schedule a worker to do the clean
+* up.
Sounds good, just saying really to remind you to post a respin. :)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Add rotation_property to mode_config and creating it
On Mon, Jul 28, 2014 at 08:47:22PM +0200, Daniel Vetter wrote: On Mon, Jul 28, 2014 at 06:29:41PM +0300, Ville Syrjälä wrote: On Tue, Jul 15, 2014 at 05:43:37PM +0530, sonika.jin...@intel.com wrote: From: Sonika Jindal sonika.jin...@intel.com v2: Adding creation of rotation_property here. Signed-off-by: Sonika Jindal sonika.jin...@intel.com --- drivers/gpu/drm/drm_crtc.c |3 ++- include/drm/drm_crtc.h |1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 787631e..49c0747 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1299,7 +1299,8 @@ static int drm_mode_create_standard_plane_properties(struct drm_device *dev) type, drm_plane_type_enum_list, ARRAY_SIZE(drm_plane_type_enum_list)); dev-mode_config.plane_type_property = type; - + dev-mode_config.rotation_property = drm_mode_create_rotation_property(dev, + BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180)); This might not make sense for other (!i915) hardware. And that's the reason why I had the driver create the property in the first place. I think Daniel was thinking that we might want to expose all the bits regardless of what the hardware supports, but I don't like that idea. There are other properties (eg. alpha blending, csc stuff, etc.) that have the same problem of hardware supporting only a (potentially small) subset of the possible values. I'd rather we didn't make life harder for userspace when the kernel can already report that certain values will never work. Well I'd like the property to be in some generic place so that fbcon can unroate and that with the atomic stuff we can have rotation support in the core structures. Which should help with argument checking. But for rotation I don't think we should set it up in generic code, but in i915. So the place where we keep it would be generic, the values would be the sames, but the allowed set would differ depending upon platform or driver. That would still fail if all the planes on the same device don't support the same rotation flags. Eg. on i915 we would have this problem if we exposed the old video overlay as a drm plane. And it wouldn't be the first piece of hardware where I've seen this kind of thing. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix read back of plane stride register
On Mon, Jul 28, 2014 at 07:56:27PM +0100, rafael.barba...@intel.com wrote: From: Rafael Barbalho rafael.barba...@intel.com According to the specifications bit 6 is actually valid in the stride register. Cc: Jesse Barnes jbar...@virtuousgeek.org Cc: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Rafael Barbalho rafael.barba...@intel.com Indeed, min stride alignment is 64 bytes so we want bit 6 as well. Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 99eb7ca..52dab31 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6221,7 +6221,7 @@ static void i9xx_get_plane_config(struct intel_crtc *crtc, crtc-base.primary-fb-height = ((val 0) 0xfff) + 1; val = I915_READ(DSPSTRIDE(pipe)); - crtc-base.primary-fb-pitches[0] = val 0xff80; + crtc-base.primary-fb-pitches[0] = val 0xffc0; aligned_height = intel_align_height(dev, crtc-base.primary-fb-height, plane_config-tiled); @@ -7241,7 +7241,7 @@ static void ironlake_get_plane_config(struct intel_crtc *crtc, crtc-base.primary-fb-height = ((val 0) 0xfff) + 1; val = I915_READ(DSPSTRIDE(pipe)); - crtc-base.primary-fb-pitches[0] = val 0xff80; + crtc-base.primary-fb-pitches[0] = val 0xffc0; aligned_height = intel_align_height(dev, crtc-base.primary-fb-height, plane_config-tiled); -- 2.0.3 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: Native backlight regressed from logarithmic to linear scale
Hi,
On 07/22/2014 06:32 AM, Anders Kaseorg wrote:
[1.] One line summary of the problem:
Native backlight regressed from logarithmic to linear scale
[2.] Full description of the problem/report:
With the new default of video.use_native_backlight=0 (commit
v3.16-rc1~30^2~2^3), my Thinkpad T510 backlight has become very difficult
to control near the low end of the scale. The lowest setting now turns
the backlight completely off, but the second-lowest setting is too bright.
Meanwhile, the difference between the highest several settings is nearly
imperceptible.
This happened because /sys/class/backlight/acpi_video0/brightness (which
has now disappeared) used a different scale than
/sys/class/intel_backlight/brightness; the relationship between
acpi_video0 and intel_backlight was not linear. I measured the exact
relationship as follows:
acpiintel
0 52
1 87
2 139
3 174
4 226
5 261
6 313
7 435
8 591
9 800
10 1078
11 1461
12 1914
13 2557
14 3358
15 4437
The relationship is close to logarithmic; a good fit is intel =
60*(4/3)^acpi, or acpi = log_{4/3} (intel/60). It’s well known that
perceived brightness varies logarithmically with physical luminance
(Fechner’s law), so it’s no surprise that the acpi_video0 scale was more
useful.
Since the kernel no longer uses ACPI to do this translation, it should do
the translation itself.
I've been thinking a bit about this, and I believe that the right answer
here is to do the linear to logarithmic mapping in user-space. The intel
backlight interface has a type of raw, clearly signalling to userspace that
it is a raw untranslated interface, as such any fanciness such as
creating a logarithmic scale should be done in userspace IMHO.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 22/40] drm/i915: Add chv port D TX wells
On Mon, 2014-07-28 at 18:19 +0300, Ville Syrjälä wrote:
On Fri, Jul 25, 2014 at 04:30:29PM +0300, Imre Deak wrote:
On Sat, 2014-06-28 at 02:04 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add the TX wells for port D. The Punit subsystem numbers are a total
guess at this time. Also I'm not sure these even exist. Certainly the
Punit in current hardware doesn't deal with these.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_pm.c | 23 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 3d1fef4..191df9e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -525,6 +525,10 @@ enum punit_power_well {
PUNIT_POWER_WELL_DPIO_RX0 = 10,
PUNIT_POWER_WELL_DPIO_RX1 = 11,
PUNIT_POWER_WELL_DPIO_CMN_D = 12,
+ /* FIXME: guesswork below */
+ PUNIT_POWER_WELL_DPIO_TX_D_LANES_01 = 13,
+ PUNIT_POWER_WELL_DPIO_TX_D_LANES_23 = 14,
+ PUNIT_POWER_WELL_DPIO_RX2 = 15,
PUNIT_POWER_WELL_NUM,
};
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index cae936c..55f3e6b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6540,6 +6540,15 @@ EXPORT_SYMBOL_GPL(i915_release_power_well);
BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
BIT(POWER_DOMAIN_INIT))
+#define CHV_DPIO_TX_D_LANES_01_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) | \
+ BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
+ BIT(POWER_DOMAIN_INIT))
+
+#define CHV_DPIO_TX_D_LANES_23_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
Atm, for all other ports we power up all lanes regardless of the actual
configuration (until the PHY side setup is proved to work fine). So for
consistency I'd do the same here too. With that change:
We do that here too. '.domains = 01 | 23' for both tx-d wells. Or am I
missing something?
Ah, right I should've read a couple of lines below. So my above comment
can be ignored and my r-b applies as-is.
Reviewed-by: Imre Deak imre.d...@intel.com
+ BIT(POWER_DOMAIN_INIT))
+
static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
.sync_hw = i9xx_always_on_power_well_noop,
.enable = i9xx_always_on_power_well_noop,
@@ -6757,6 +6766,20 @@ static struct i915_power_well chv_power_wells[] = {
.ops = vlv_dpio_power_well_ops,
.data = PUNIT_POWER_WELL_DPIO_TX_C_LANES_23,
},
+ {
+ .name = dpio-tx-d-01,
+ .domains = CHV_DPIO_TX_D_LANES_01_POWER_DOMAINS |
+CHV_DPIO_TX_D_LANES_23_POWER_DOMAINS,
+ .ops = vlv_dpio_power_well_ops,
+ .data = PUNIT_POWER_WELL_DPIO_TX_D_LANES_01,
+ },
+ {
+ .name = dpio-tx-d-23,
+ .domains = CHV_DPIO_TX_D_LANES_01_POWER_DOMAINS |
+CHV_DPIO_TX_D_LANES_23_POWER_DOMAINS,
+ .ops = vlv_dpio_power_well_ops,
+ .data = PUNIT_POWER_WELL_DPIO_TX_D_LANES_23,
+ },
#endif
};
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915/bdw: Initialize BDW workarounds in render ring init fn
On Mon, Jul 28, 2014 at 09:46:33PM +0100, Siluvery, Arun wrote:
On 28/07/2014 18:00, Ville Syrjälä wrote:
On Mon, Jul 28, 2014 at 05:31:46PM +0100, arun.siluv...@linux.intel.com
wrote:
From: Arun Siluvery arun.siluv...@linux.intel.com
The workarounds at the moment are initialized in init_clock_gating() but
they are lost during reset; In case of execlists some workarounds modify
registers that are part of register state context, since these are not
initialized until init_clock_gating() default context ends up with
incorrect values as render context is restored and saved before updated
by workarounds hence move them to render ring init fn. This should be
ok as these workarounds are not related to display clock gating.
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 46 ++
drivers/gpu/drm/i915/intel_pm.c | 59
drivers/gpu/drm/i915/intel_ringbuffer.c | 68
+
3 files changed, 114 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 083683c..cf7da30 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2397,20 +2397,65 @@ static int i915_shared_dplls_info(struct seq_file
*m, void *unused)
seq_printf(m, dpll_md: 0x%08x\n, pll-hw_state.dpll_md);
seq_printf(m, fp0: 0x%08x\n, pll-hw_state.fp0);
seq_printf(m, fp1: 0x%08x\n, pll-hw_state.fp1);
seq_printf(m, wrpll: 0x%08x\n, pll-hw_state.wrpll);
}
drm_modeset_unlock_all(dev);
return 0;
}
+static int i915_workaround_info(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret;
+
+ ret = mutex_lock_interruptible(dev-struct_mutex);
+ if (ret)
+ return ret;
+
+ if (IS_BROADWELL(dev)) {
+ seq_printf(m, GEN8_ROW_CHICKEN:\t0x%08x\n,
+ I915_READ(GEN8_ROW_CHICKEN));
+ seq_printf(m, HALF_SLICE_CHICKEN3:\t0x%08x\n,
+ I915_READ(HALF_SLICE_CHICKEN3));
+ seq_printf(m, GAMTARBMODE:\t0x%08x\n, I915_READ(GAMTARBMODE));
+ seq_printf(m, _3D_CHICKEN3:\t0x%08x\n,
+ I915_READ(_3D_CHICKEN3));
+ seq_printf(m, COMMON_SLICE_CHICKEN2:\t0x%08x\n,
+ I915_READ(COMMON_SLICE_CHICKEN2));
+ seq_printf(m, GEN7_HALF_SLICE_CHICKEN1:\t0x%08x\n,
+ I915_READ(GEN7_HALF_SLICE_CHICKEN1));
+ seq_printf(m, GEN7_ROW_CHICKEN2:\t0x%08x\n,
+ I915_READ(GEN7_ROW_CHICKEN2));
+ seq_printf(m, GAM_ECOCHK:\t0x%08x\n,
+ I915_READ(GAM_ECOCHK));
+ seq_printf(m, HDC_CHICKEN0:\t0x%08x\n,
+ I915_READ(HDC_CHICKEN0));
+ seq_printf(m, GEN7_FF_THREAD_MODE:\t0x%08x\n,
+ I915_READ(GEN7_FF_THREAD_MODE));
+ seq_printf(m, GEN8_UCGCTL6:\t0x%08x\n,
+ I915_READ(GEN8_UCGCTL6));
+ seq_printf(m, GEN6_RC_SLEEP_PSMI_CONTROL:\t0x%08x\n,
+ I915_READ(GEN6_RC_SLEEP_PSMI_CONTROL));
+ seq_printf(m, CACHE_MODE_1:\t0x%08x\n,
+ I915_READ(CACHE_MODE_1));
+ } else
+ DRM_DEBUG_DRIVER(Not available for Gen%d\n,
+ INTEL_INFO(dev)-gen);
+
+ mutex_unlock(dev-struct_mutex);
+ return 0;
+}
+
This smells like a separate patch. But I'm not sure we want at all since
intel_reg_read will provide the same information.
struct pipe_crc_info {
const char *name;
struct drm_device *dev;
enum pipe pipe;
};
static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
{
struct pipe_crc_info *info = inode-i_private;
struct drm_i915_private *dev_priv = info-dev-dev_private;
@@ -3904,20 +3949,21 @@ static const struct drm_info_list
i915_debugfs_list[] = {
{i915_ppgtt_info, i915_ppgtt_info, 0},
{i915_llc, i915_llc, 0},
{i915_edp_psr_status, i915_edp_psr_status, 0},
{i915_sink_crc_eDP1, i915_sink_crc, 0},
{i915_energy_uJ, i915_energy_uJ, 0},
{i915_pc8_status, i915_pc8_status, 0},
{i915_power_domain_info, i915_power_domain_info, 0},
{i915_display_info, i915_display_info, 0},
{i915_semaphore_status, i915_semaphore_status, 0},
{i915_shared_dplls_info, i915_shared_dplls_info, 0},
+ {i915_workaround_info, i915_workaround_info, 0},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
static const struct i915_debugfs_files {
const char *name;
const struct file_operations *fops;
}
[Intel-gfx] [PATCH] drm/i915: vma/ppgtt lifetime rules
VMAs should take a reference of the address space they use.
Now, when the fd is closed, it will release the ref that the context was
holding, but it will still be referenced by any vmas that are still
active.
ppgtt_release() should then only be called when the last thing referencing
it releases the ref, and it can just call the base cleanup and free the
ppgtt.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 8
drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2acc03f..a879a93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
/* i915_gem_context.c */
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
+#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
+void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dcd8d7b..25a32b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
drm_i915_gem_object *obj,
void i915_gem_vma_destroy(struct i915_vma *vma)
{
+ struct i915_address_space *vm = NULL;
+ struct i915_hw_ppgtt *ppgtt = NULL;
WARN_ON(vma-node.allocated);
/* Keep the vma as a placeholder in the execbuffer reservation lists */
if (!list_empty(vma-exec_list))
return;
+ vm = vma-vm;
+ ppgtt = vm_to_ppgtt(vm);
+
+ if (ppgtt)
+ kref_put(ppgtt-ref, ppgtt_release);
+
list_del(vma-vma_link);
kfree(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5b5af6c..59272f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt *ppgtt)
return;
}
- /*
-* Make sure vmas are unbound before we take down the drm_mm
-*
-* FIXME: Proper refcounting should take care of this, this shouldn't be
-* needed at all.
-*/
- if (!list_empty(vm-active_list)) {
- struct i915_vma *vma;
-
- list_for_each_entry(vma, vm-active_list, mm_list)
- if (WARN_ON(list_empty(vma-vma_link) ||
- list_is_singular(vma-vma_link)))
- break;
-
- i915_gem_evict_vm(ppgtt-base, true);
- } else {
- i915_gem_retire_requests(dev);
- i915_gem_evict_vm(ppgtt-base, false);
- }
+ /* vmas should already be unbound */
+ WARN_ON(!list_empty(vm-active_list));
ppgtt-base.cleanup(ppgtt-base);
}
-static void ppgtt_release(struct kref *kref)
+void ppgtt_release(struct kref *kref)
{
struct i915_hw_ppgtt *ppgtt =
container_of(kref, struct i915_hw_ppgtt, ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1411613..90c3d0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct
drm_i915_gem_object *obj,
struct i915_address_space *vm)
{
struct i915_vma *vma;
+ struct i915_hw_ppgtt *ppgtt = NULL;
vma = i915_gem_obj_to_vma(obj, vm);
if (!vma)
vma = __i915_gem_vma_create(obj, vm);
+ ppgtt = vm_to_ppgtt(vm);
+ if (ppgtt)
+ kref_get(ppgtt-ref);
+
return vma;
}
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: Native backlight regressed from logarithmic to linear scale
On Tue, 29 Jul 2014, Hans de Goede wrote: I've been thinking a bit about this, and I believe that the right answer here is to do the linear to logarithmic mapping in user-space. The intel backlight interface has a type of raw, clearly signalling to userspace that it is a raw untranslated interface, as such any fanciness such as creating a logarithmic scale should be done in userspace IMHO. I was going to respond that the kernel does its own brightness stepping when userspace isn’t paying attention. But apparently only acpi_video does that, and intel_backlight does not; my brightness keys now have no effect outside of the X server. Is that the expected behavior? In any case, if you think punting part of the problem to userspace is the right answer, then to flesh out the details: do you think it’s right for userspace to assume that any backlight with type ‘raw’ is a linear scale that needs to be converted, and one with type ‘firmware’ or ‘platform’ has already been converted appropriately? Anders ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: fix cursor handling when runtime suspended
On Mon, Jul 28, 2014 at 03:37:12PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If we're runtime suspended and try to use the cursor interfaces, we
will get a lot of WARNs saying we did the wrong thing.
For intel_crtc_update_cursor(), all we need to do is return if the
CRTC is not active, since writing the registers won't really have any
effect if the screen is not visible, and we will write the registers
later when enabling the screen.
For intel_crtc_cursor_set_obj(), we just need to wake up the hardware
then pinning the display plane.
v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
Testcase: igt/pm_rpm/cursor
Testcase: igt/pm_rpm/cursor-dpms
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
Cc: sta...@vger.kernel.org
Signed-off-by: Paulo Zanoni paulo.r.zan...@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 1edfd1a..f1a9b5c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8144,6 +8144,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
if (base == 0 intel_crtc-cursor_base == 0)
return;
+ if (!intel_crtc-active)
+ return;
+
I915_WRITE(CURPOS(pipe), pos);
if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_BROADWELL(dev))
@@ -8217,7 +8220,9 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
if (need_vtd_wa(dev))
alignment = 64*1024;
+ intel_runtime_pm_get(dev_priv);
ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
+ intel_runtime_pm_put(dev_priv);
put_fence() would need runtime pm too I think.
if (ret) {
DRM_DEBUG_KMS(failed to move cursor bo into the
GTT\n);
goto fail_locked;
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 45/53] drm/i915/bdw: Do not call intel_runtime_pm_get() in an interrupt
On Tue, Jul 29, 2014 at 08:37:48AM +0100, Chris Wilson wrote: On Mon, Jul 28, 2014 at 10:54:06AM +0200, Daniel Vetter wrote: On Sat, Jul 26, 2014 at 11:27:38AM +0100, Chris Wilson wrote: On Wed, Jun 18, 2014 at 10:54:13PM +0200, Daniel Vetter wrote: On Fri, Jun 13, 2014 at 04:38:03PM +0100, oscar.ma...@intel.com wrote: From: Oscar Mateo oscar.ma...@intel.com Or with a spinlock grabbed, because it might sleep, which is not a nice thing to do. Instead, do the runtime_pm get/put together with the create/destroy request, and handle the forcewake get/put directly. Signed-off-by: Oscar Mateo oscar.ma...@intel.com Looks like a fixup that should be squashed into relevant earlier patches. The whole gen6_gt_force_wake_get() calling intel_runtime_pm_get() is broken due to this - we must be able to read registers in atomic context! Please revert c8c8fb33b37766acf6474784b0d5245dab9a1690 force_wake_get can't call runtime_pm_get becuase pm_get can sleep. So if you want to read registers from atomic context you have to have a runtime pm reference from someone else. Nope. That cannot work. Well it works currently. So where do you see the problem? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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 22/40] drm/i915: Add chv port D TX wells
On Tue, Jul 29, 2014 at 12:54:36PM +0300, Imre Deak wrote:
On Mon, 2014-07-28 at 18:19 +0300, Ville Syrjälä wrote:
On Fri, Jul 25, 2014 at 04:30:29PM +0300, Imre Deak wrote:
On Sat, 2014-06-28 at 02:04 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add the TX wells for port D. The Punit subsystem numbers are a total
guess at this time. Also I'm not sure these even exist. Certainly the
Punit in current hardware doesn't deal with these.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_pm.c | 23 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 3d1fef4..191df9e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -525,6 +525,10 @@ enum punit_power_well {
PUNIT_POWER_WELL_DPIO_RX0 = 10,
PUNIT_POWER_WELL_DPIO_RX1 = 11,
PUNIT_POWER_WELL_DPIO_CMN_D = 12,
+ /* FIXME: guesswork below */
+ PUNIT_POWER_WELL_DPIO_TX_D_LANES_01 = 13,
+ PUNIT_POWER_WELL_DPIO_TX_D_LANES_23 = 14,
+ PUNIT_POWER_WELL_DPIO_RX2 = 15,
PUNIT_POWER_WELL_NUM,
};
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index cae936c..55f3e6b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6540,6 +6540,15 @@ EXPORT_SYMBOL_GPL(i915_release_power_well);
BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
BIT(POWER_DOMAIN_INIT))
+#define CHV_DPIO_TX_D_LANES_01_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) | \
+ BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
+ BIT(POWER_DOMAIN_INIT))
+
+#define CHV_DPIO_TX_D_LANES_23_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
Atm, for all other ports we power up all lanes regardless of the actual
configuration (until the PHY side setup is proved to work fine). So for
consistency I'd do the same here too. With that change:
We do that here too. '.domains = 01 | 23' for both tx-d wells. Or am I
missing something?
Ah, right I should've read a couple of lines below. So my above comment
can be ignored and my r-b applies as-is.
Reviewed-by: Imre Deak imre.d...@intel.com
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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: Add rotation_property to mode_config and creating it
On Tue, Jul 29, 2014 at 12:40:29PM +0300, Ville Syrjälä wrote: On Mon, Jul 28, 2014 at 08:47:22PM +0200, Daniel Vetter wrote: On Mon, Jul 28, 2014 at 06:29:41PM +0300, Ville Syrjälä wrote: On Tue, Jul 15, 2014 at 05:43:37PM +0530, sonika.jin...@intel.com wrote: From: Sonika Jindal sonika.jin...@intel.com v2: Adding creation of rotation_property here. Signed-off-by: Sonika Jindal sonika.jin...@intel.com --- drivers/gpu/drm/drm_crtc.c |3 ++- include/drm/drm_crtc.h |1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 787631e..49c0747 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1299,7 +1299,8 @@ static int drm_mode_create_standard_plane_properties(struct drm_device *dev) type, drm_plane_type_enum_list, ARRAY_SIZE(drm_plane_type_enum_list)); dev-mode_config.plane_type_property = type; - + dev-mode_config.rotation_property = drm_mode_create_rotation_property(dev, + BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180)); This might not make sense for other (!i915) hardware. And that's the reason why I had the driver create the property in the first place. I think Daniel was thinking that we might want to expose all the bits regardless of what the hardware supports, but I don't like that idea. There are other properties (eg. alpha blending, csc stuff, etc.) that have the same problem of hardware supporting only a (potentially small) subset of the possible values. I'd rather we didn't make life harder for userspace when the kernel can already report that certain values will never work. Well I'd like the property to be in some generic place so that fbcon can unroate and that with the atomic stuff we can have rotation support in the core structures. Which should help with argument checking. But for rotation I don't think we should set it up in generic code, but in i915. So the place where we keep it would be generic, the values would be the sames, but the allowed set would differ depending upon platform or driver. That would still fail if all the planes on the same device don't support the same rotation flags. Eg. on i915 we would have this problem if we exposed the old video overlay as a drm plane. And it wouldn't be the first piece of hardware where I've seen this kind of thing. Problem is still that I'd like to have a somewhat generic internal representation available. We could punt this to atomic though by adding a rotation field to the drm_plane_state structure. Which is more-or-less my plan, but wouldn't work with Rob's approach. Or we keep the property link only in drm_plane (and give drivers the freedom to set up the underlying enum however they want to), but I'm not sure whether our interfaces can cope with that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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: Rework GPU reset sequence to match driver load thaw
On Tue, Jul 29, 2014 at 08:36:33AM +0100, Chris Wilson wrote: On Mon, Jul 28, 2014 at 11:26:38AM +0200, Daniel Vetter wrote: Oh, I guess that's the tricky bit why the old approach never worked - because reset_in_progress is set we failed the context/ppgtt loading through the rings and screwed up. Problem with your approach is that we want to bail out here if a reset is in progress, so we can't just eat the EAGAIN. If we do that we potentially deadlock or overflow the ring. I think we need a different hack here, and a few layers down (i.e. at the place where we actually generate that offending -EAGAIN). - Around the re-init sequence in the reset function we set dev_priv-mm.reload_in_reset or similar. Since we hold dev-struct_mutex no one will see that, as long as we never leak it out of the critical section. - In the ring_begin code that checks for gpu hangs we ignore reset_in_progress if this bit is set. - Both places need fairly big comments to explain what exactly is going on. This is going from bad to worse. I think you can do better if you looked at the problem afresh. Well we can't really reset reset_in_progress at that point, since not all reset is done yet. Especially the modeset stuff. So I don't think that reordering the reset sequence would get us out of this ugly spot. And I don't see any other solution really. Do you? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: Native backlight regressed from logarithmic to linear scale
On Tue, Jul 29, 2014 at 06:14:16AM -0400, Anders Kaseorg wrote: On Tue, 29 Jul 2014, Hans de Goede wrote: I've been thinking a bit about this, and I believe that the right answer here is to do the linear to logarithmic mapping in user-space. The intel backlight interface has a type of raw, clearly signalling to userspace that it is a raw untranslated interface, as such any fanciness such as creating a logarithmic scale should be done in userspace IMHO. I was going to respond that the kernel does its own brightness stepping when userspace isn’t paying attention. But apparently only acpi_video does that, and intel_backlight does not; my brightness keys now have no effect outside of the X server. Is that the expected behavior? Userspace on linux is supposed to catch brightness keys and update the backlight. Some acpi drivers do funny stuff behind everyone's back, but generally that's the expected behavior. You'd need a deamon for the backlight to work on the console. In any case, if you think punting part of the problem to userspace is the right answer, then to flesh out the details: do you think it’s right for userspace to assume that any backlight with type ‘raw’ is a linear scale that needs to be converted, and one with type ‘firmware’ or ‘platform’ has already been converted appropriately? I don't think you can generally assume anything - what we do is send the pwm signal, how linearly that translates into brightness is totally panel and driver dependent. So no matter what you pick someone will complain I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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: s/seqno/request/ tracking inside objects
On Tue, Jul 29, 2014 at 08:29:53AM +0100, Chris Wilson wrote:
On Mon, Jul 28, 2014 at 01:44:12PM -0700, Jesse Barnes wrote:
@@ -3038,44 +3203,35 @@ out:
*/
int
i915_gem_object_sync(struct drm_i915_gem_object *obj,
- struct intel_engine_cs *to)
+ struct intel_engine_cs *to,
+ bool readonly)
{
It might be nice to have sync_read/sync_write functions instead, since
looking up bool args or unnamed enums is a pain.
Not convinced since it is used in a single location and two function
calls would look unelegant - but we could switch to PROT_READ |
PROT_WRITE throughout.
Switching to PROT_READ/WRITE might be nice as a general cleanup (or some
other named thing) since read_only/write booleans are all over the place.
So I like this, but definitely something for a separate patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 09/11] i915: add DP 1.2 MST support (v0.6)
On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie airl...@gmail.com wrote: On 23 July 2014 06:02, Paulo Zanoni przan...@gmail.com wrote: 2014-06-05 1:01 GMT-03:00 Dave Airlie airl...@gmail.com: From: Dave Airlie airl...@redhat.com This adds DP 1.2 MST support on Haswell systems. Hi It looks like drm-intel-nightly now includes this patch. It actually includes v7, but I couldn't find it on my mail dirs. Just by booting the machine with this patch, I get: There are two patches in my drm-i915-next branch They should remove the offending bits for the fbdev and powersave warning. Paulo, can you please test these two patches? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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 09/11] i915: add DP 1.2 MST support (v0.6)
On 29 July 2014 20:46, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie airl...@gmail.com wrote: On 23 July 2014 06:02, Paulo Zanoni przan...@gmail.com wrote: 2014-06-05 1:01 GMT-03:00 Dave Airlie airl...@gmail.com: From: Dave Airlie airl...@redhat.com This adds DP 1.2 MST support on Haswell systems. Hi It looks like drm-intel-nightly now includes this patch. It actually includes v7, but I couldn't find it on my mail dirs. Just by booting the machine with this patch, I get: There are two patches in my drm-i915-next branch They should remove the offending bits for the fbdev and powersave warning. Paulo, can you please test these two patches? Oh he did already, didn't I push them? I must have forgotten. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/11] i915: add DP 1.2 MST support (v0.6)
On Tue, Jul 29, 2014 at 12:50 PM, Dave Airlie airl...@gmail.com wrote: On 29 July 2014 20:46, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie airl...@gmail.com wrote: On 23 July 2014 06:02, Paulo Zanoni przan...@gmail.com wrote: 2014-06-05 1:01 GMT-03:00 Dave Airlie airl...@gmail.com: From: Dave Airlie airl...@redhat.com This adds DP 1.2 MST support on Haswell systems. Hi It looks like drm-intel-nightly now includes this patch. It actually includes v7, but I couldn't find it on my mail dirs. Just by booting the machine with this patch, I get: There are two patches in my drm-i915-next branch They should remove the offending bits for the fbdev and powersave warning. Paulo, can you please test these two patches? Oh he did already, didn't I push them? I must have forgotten. Oh, I guess I've missed that since it didn't go over the m-l ;-) It's there already. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
VMAs should take a reference of the address space they use.
Now, when the fd is closed, it will release the ref that the context was
holding, but it will still be referenced by any vmas that are still
active.
ppgtt_release() should then only be called when the last thing referencing
it releases the ref, and it can just call the base cleanup and free the
ppgtt.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 8
drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2acc03f..a879a93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
/* i915_gem_context.c */
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
+#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
+void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dcd8d7b..25a32b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
drm_i915_gem_object *obj,
void i915_gem_vma_destroy(struct i915_vma *vma)
{
+ struct i915_address_space *vm = NULL;
+ struct i915_hw_ppgtt *ppgtt = NULL;
WARN_ON(vma-node.allocated);
/* Keep the vma as a placeholder in the execbuffer reservation lists */
if (!list_empty(vma-exec_list))
return;
+ vm = vma-vm;
+ ppgtt = vm_to_ppgtt(vm);
+
+ if (ppgtt)
+ kref_put(ppgtt-ref, ppgtt_release);
Hm, this has the risk that we leave unwanted vmas around for a bit longer.
They will get cleaned up though when the final object references goes
away, so the leak is fairly restricted. And currently we don't have a
shrinker to just whack out vma objects even ...
It's definitely a much neater solution than what I had in mind with moving
vmas to full-blown active tracking like we do objects. So I'm tempted to
go with, but have a bit a lurking feeling that I'm missing something.
Chris?
Cheers, Daniel
+
list_del(vma-vma_link);
kfree(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5b5af6c..59272f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt
*ppgtt)
return;
}
- /*
- * Make sure vmas are unbound before we take down the drm_mm
- *
- * FIXME: Proper refcounting should take care of this, this shouldn't be
- * needed at all.
- */
- if (!list_empty(vm-active_list)) {
- struct i915_vma *vma;
-
- list_for_each_entry(vma, vm-active_list, mm_list)
- if (WARN_ON(list_empty(vma-vma_link) ||
- list_is_singular(vma-vma_link)))
- break;
-
- i915_gem_evict_vm(ppgtt-base, true);
- } else {
- i915_gem_retire_requests(dev);
- i915_gem_evict_vm(ppgtt-base, false);
- }
+ /* vmas should already be unbound */
+ WARN_ON(!list_empty(vm-active_list));
ppgtt-base.cleanup(ppgtt-base);
}
-static void ppgtt_release(struct kref *kref)
+void ppgtt_release(struct kref *kref)
{
struct i915_hw_ppgtt *ppgtt =
container_of(kref, struct i915_hw_ppgtt, ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1411613..90c3d0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct
drm_i915_gem_object *obj,
struct i915_address_space *vm)
{
struct i915_vma *vma;
+ struct i915_hw_ppgtt *ppgtt = NULL;
vma = i915_gem_obj_to_vma(obj, vm);
if (!vma)
vma = __i915_gem_vma_create(obj, vm);
+ ppgtt = vm_to_ppgtt(vm);
+ if (ppgtt)
+ kref_get(ppgtt-ref);
+
return vma;
}
--
1.9.0
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH i-g-t 1/5] lib: Remove unused field from struct igt_fb
Pushed those, before I forget.
--
Damien
On Fri, Jul 11, 2014 at 03:09:01PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
lib/igt_fb.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 6d030e6..f5110d4 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -48,7 +48,6 @@ struct igt_fb {
uint32_t drm_format;
int width;
int height;
- int depth;
unsigned stride;
unsigned tiling;
unsigned size;
--
1.8.3.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: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 01:06:40PM +0200, Daniel Vetter wrote:
On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
VMAs should take a reference of the address space they use.
Now, when the fd is closed, it will release the ref that the context was
holding, but it will still be referenced by any vmas that are still
active.
ppgtt_release() should then only be called when the last thing referencing
it releases the ref, and it can just call the base cleanup and free the
ppgtt.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 8
drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 2acc03f..a879a93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
/* i915_gem_context.c */
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt,
base)
+#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
+void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index dcd8d7b..25a32b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
drm_i915_gem_object *obj,
void i915_gem_vma_destroy(struct i915_vma *vma)
{
+ struct i915_address_space *vm = NULL;
+ struct i915_hw_ppgtt *ppgtt = NULL;
WARN_ON(vma-node.allocated);
/* Keep the vma as a placeholder in the execbuffer reservation lists */
if (!list_empty(vma-exec_list))
return;
+ vm = vma-vm;
+ ppgtt = vm_to_ppgtt(vm);
+
+ if (ppgtt)
+ kref_put(ppgtt-ref, ppgtt_release);
Hm, this has the risk that we leave unwanted vmas around for a bit longer.
They will get cleaned up though when the final object references goes
away, so the leak is fairly restricted. And currently we don't have a
shrinker to just whack out vma objects even ...
It's definitely a much neater solution than what I had in mind with moving
vmas to full-blown active tracking like we do objects. So I'm tempted to
go with, but have a bit a lurking feeling that I'm missing something.
Chris?
I don't think that only taking the reference for whilst the vma is
active would add much extra code or complexity and being consistent
with the existing active tracking has the advantages you mention.
If we could clean up the vma handling in move_to_inactive that would
remove a major wart all by itself.
-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
Re: [Intel-gfx] [PATCH i-g-t] lib: don't abort if forcing the connector state fails
On Mon, Jul 28, 2014 at 05:34:55PM +0200, Daniel Vetter wrote:
On Mon, Jul 28, 2014 at 04:24:49PM +0100, Thomas Wood wrote:
Ensure tests using igt_enable_connectors can still run even if the
relevant debugfs files are not available.
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
lib/igt_kms.c | 19 ++-
lib/igt_kms.h | 2 +-
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 20370a9..740b5dd 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -429,9 +429,11 @@ static char* get_debugfs_connector_path(int drm_fd,
drmModeConnector *connector,
* @state: state to force on @connector
*
* Force the specified state on the specified connector.
+ *
+ * Returns: true on success
*/
-void kmstest_force_connector(int drm_fd, drmModeConnector *connector, enum
-kmstest_force_connector_state state)
+bool kmstest_force_connector(int drm_fd, drmModeConnector *connector,
+enum kmstest_force_connector_state state)
{
char *path;
const char *value;
@@ -458,12 +460,15 @@ void kmstest_force_connector(int drm_fd,
drmModeConnector *connector, enum
debugfs_fd = open(path, O_WRONLY | O_TRUNC);
free(path);
- igt_assert(debugfs_fd != -1);
+ if (debugfs_fd == -1) {
+ return false;
+ }
Aside: We have some neat debugfs helpers in igt_debugfs.c. Might convert
over to them while at it.
Aside: they are not that neat... :p I felt restricted that I couldn't open
the right debugfs for an fd I had - the assumption of the singleton is
too prescriptive.
-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
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add get_config implementation for DSI encoder
On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
Call to vlv_crtc_clock_get is not needed for DSI and was causing dpio
read WARN dumps as well. Absence of -get_config was casuing othet WARN
dumps as well. With this the last of the known WARN dumps for DSI should
be fixed.
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 7 +++---
drivers/gpu/drm/i915/intel_dsi.c | 45
drivers/gpu/drm/i915/intel_dsi.h | 3 +++
drivers/gpu/drm/i915/intel_dsi_pll.c | 4 +++-
4 files changed, 55 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fe6f1db..3d0ea7c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6309,9 +6309,10 @@ static bool i9xx_get_pipe_config(struct intel_crtc
*crtc,
if (IS_CHERRYVIEW(dev))
chv_crtc_clock_get(crtc, pipe_config);
- else if (IS_VALLEYVIEW(dev))
- vlv_crtc_clock_get(crtc, pipe_config);
- else
+ else if (IS_VALLEYVIEW(dev)) {
+ if (!intel_pipe_has_type(crtc-base, INTEL_OUTPUT_DSI))
+ vlv_crtc_clock_get(crtc, pipe_config);
+ } else
i9xx_crtc_clock_get(crtc, pipe_config);
return true;
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index bfcefbf..61da0e5 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -351,9 +351,54 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
static void intel_dsi_get_config(struct intel_encoder *encoder,
struct intel_crtc_config *pipe_config)
{
+ struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
+ u32 dsi_clock, pclk;
+ u32 pll_ctl, pll_div;
+ u32 m = 0, p = 0;
+ int refclk = 25000;
+ int i;
+
DRM_DEBUG_KMS(\n);
/* XXX: read flags, set to adjusted_mode */
This comment can be removed.
+ pipe_config-quirks = 1;
The proper macro should be used.
+
+ memset(pipe_config-dpll_hw_state, 0,
+ sizeof(pipe_config-dpll_hw_state));
+
+ mutex_lock(dev_priv-dpio_lock);
+ pll_ctl = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_CONTROL);
+ pll_div = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_DIVIDER);
+ mutex_unlock(dev_priv-dpio_lock);
+
+ pll_ctl = ~(DSI_PLL_CLK_GATE_DSI0_DSIPLL | DSI_PLL_VCO_EN);
+ pll_ctl = pll_ctl (DSI_PLL_P1_POST_DIV_SHIFT - 2);
I'd prefer a proper masking of the P1 field instead of depending on
other register fields being 0. The same goes for pll_div[M1].
+
+ while (pll_ctl) {
+ pll_ctl = pll_ctl 1;
+ p++;
+ }
+ p--;
+
+ for (i = 0; i num_lfsr_converts; i++) {
+ if (lfsr_converts[i] == pll_div)
+ break;
+ }
+
+ if (i == num_lfsr_converts) {
+ DRM_ERROR(wrong m_seed programmed\n);
+ return;
+ }
+
+ m = i + 62;
+
+ dsi_clock = (m * refclk) / p;
Should guard against div-by-zero.
+ pclk = DIV_ROUND_CLOSEST(dsi_clock * intel_dsi-lane_count,
+ pipe_config-pipe_bpp);
dsi_clk_from_pclk() uses dsi-pixel_format in place of pipe_bpp, so an
assert here that the two values agree would be nice.
+
+ pipe_config-adjusted_mode.crtc_clock = pclk;
+ pipe_config-port_clock = pclk;
}
static enum drm_mode_status
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index 31db33d..e0c16b0 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -130,6 +130,9 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
return container_of(encoder, struct intel_dsi, base.base);
}
+extern const u32 lfsr_converts[];
+extern const int num_lfsr_converts;
+
extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index ba79ec1..78449ea 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -43,13 +43,15 @@ struct dsi_mnp {
u32 dsi_pll_div;
};
-static const u32 lfsr_converts[] = {
+const u32 lfsr_converts[] = {
426, 469, 234, 373, 442, 221, 110, 311, 411,/* 62 - 70 */
461, 486, 243, 377, 188, 350, 175, 343, 427, 213, /* 71 - 80 */
106, 53, 282, 397, 354, 227, 113, 56, 284, 142, /* 81 - 90 */
71, 35 /* 91 - 92 */
};
+const int num_lfsr_converts = sizeof(lfsr_converts) /
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add get_config implementation for DSI encoder
On Tue, Jul 29, 2014 at 02:38:36PM +0300, Imre Deak wrote:
On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
Call to vlv_crtc_clock_get is not needed for DSI and was causing dpio
read WARN dumps as well. Absence of -get_config was casuing othet WARN
dumps as well. With this the last of the known WARN dumps for DSI should
be fixed.
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 7 +++---
drivers/gpu/drm/i915/intel_dsi.c | 45
drivers/gpu/drm/i915/intel_dsi.h | 3 +++
drivers/gpu/drm/i915/intel_dsi_pll.c | 4 +++-
4 files changed, 55 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fe6f1db..3d0ea7c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6309,9 +6309,10 @@ static bool i9xx_get_pipe_config(struct intel_crtc
*crtc,
if (IS_CHERRYVIEW(dev))
chv_crtc_clock_get(crtc, pipe_config);
- else if (IS_VALLEYVIEW(dev))
- vlv_crtc_clock_get(crtc, pipe_config);
- else
+ else if (IS_VALLEYVIEW(dev)) {
+ if (!intel_pipe_has_type(crtc-base, INTEL_OUTPUT_DSI))
+ vlv_crtc_clock_get(crtc, pipe_config);
+ } else
i9xx_crtc_clock_get(crtc, pipe_config);
return true;
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index bfcefbf..61da0e5 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -351,9 +351,54 @@ static bool intel_dsi_get_hw_state(struct
intel_encoder *encoder,
static void intel_dsi_get_config(struct intel_encoder *encoder,
struct intel_crtc_config *pipe_config)
{
+ struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
+ u32 dsi_clock, pclk;
+ u32 pll_ctl, pll_div;
+ u32 m = 0, p = 0;
+ int refclk = 25000;
+ int i;
+
DRM_DEBUG_KMS(\n);
/* XXX: read flags, set to adjusted_mode */
This comment can be removed.
There's a v2 with a lot of this addressed already.
-Daniel
+ pipe_config-quirks = 1;
The proper macro should be used.
+
+ memset(pipe_config-dpll_hw_state, 0,
+ sizeof(pipe_config-dpll_hw_state));
+
+ mutex_lock(dev_priv-dpio_lock);
+ pll_ctl = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_CONTROL);
+ pll_div = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_DIVIDER);
+ mutex_unlock(dev_priv-dpio_lock);
+
+ pll_ctl = ~(DSI_PLL_CLK_GATE_DSI0_DSIPLL | DSI_PLL_VCO_EN);
+ pll_ctl = pll_ctl (DSI_PLL_P1_POST_DIV_SHIFT - 2);
I'd prefer a proper masking of the P1 field instead of depending on
other register fields being 0. The same goes for pll_div[M1].
+
+ while (pll_ctl) {
+ pll_ctl = pll_ctl 1;
+ p++;
+ }
+ p--;
+
+ for (i = 0; i num_lfsr_converts; i++) {
+ if (lfsr_converts[i] == pll_div)
+ break;
+ }
+
+ if (i == num_lfsr_converts) {
+ DRM_ERROR(wrong m_seed programmed\n);
+ return;
+ }
+
+ m = i + 62;
+
+ dsi_clock = (m * refclk) / p;
Should guard against div-by-zero.
+ pclk = DIV_ROUND_CLOSEST(dsi_clock * intel_dsi-lane_count,
+pipe_config-pipe_bpp);
dsi_clk_from_pclk() uses dsi-pixel_format in place of pipe_bpp, so an
assert here that the two values agree would be nice.
+
+ pipe_config-adjusted_mode.crtc_clock = pclk;
+ pipe_config-port_clock = pclk;
}
static enum drm_mode_status
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index 31db33d..e0c16b0 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -130,6 +130,9 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
return container_of(encoder, struct intel_dsi, base.base);
}
+extern const u32 lfsr_converts[];
+extern const int num_lfsr_converts;
+
extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index ba79ec1..78449ea 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -43,13 +43,15 @@ struct dsi_mnp {
u32 dsi_pll_div;
};
-static const u32 lfsr_converts[] = {
+const u32 lfsr_converts[] = {
426, 469, 234, 373, 442, 221, 110, 311, 411,/* 62 - 70 */
461, 486, 243, 377, 188, 350, 175, 343, 427, 213, /* 71 - 80 */
106, 53, 282, 397, 354, 227, 113, 56, 284, 142, /* 81 - 90 */
Re: [Intel-gfx] [v2] drm/i915: Add correct hw/sw config check for DSI encoder
On Tue, 2014-07-15 at 18:15 +0530, Shobhit Kumar wrote:
Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
It will not be enabled for DSI and avoid dpio read WARN dumps.
Absence of -get_config was causing other WARN dumps as well. Update
dpll_hw_state as well correctly
v2: Address review comments by Daniel
- Check if DPLL is enabled rather than checking pipe output type
- set adjusted_mode-flags to 0 in compute_config rather than using
pipe_config-quirks
- Add helper function in intel_dsi_pll.c and use that in intel_dsi.c
- updated dpll_hw_state correctly
- Updated commit message and title
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Ok, reviewing now the latest version after Daniel pointed me to it.
---
drivers/gpu/drm/i915/intel_display.c | 4
drivers/gpu/drm/i915/intel_dsi.c | 21 +++-
drivers/gpu/drm/i915/intel_dsi.h | 1 +
drivers/gpu/drm/i915/intel_dsi_pll.c | 46
4 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c89b4ac..d9c34e4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6132,6 +6132,10 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc,
u32 mdiv;
int refclk = 10;
+ /* In case of MIPI DPLL will not even be used */
+ if (!(pipe_config-dpll_hw_state.dpll DPLL_VCO_ENABLE))
+ return;
+
mutex_lock(dev_priv-dpio_lock);
mdiv = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW3(pipe));
mutex_unlock(dev_priv-dpio_lock);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index bfcefbf..43be71bf 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -92,6 +92,9 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
if (fixed_mode)
intel_fixed_panel_mode(fixed_mode, adjusted_mode);
+ /* DSI uses short packets for sync events, so clear mode flags for DSI
*/
+ adjusted_mode-flags = 0;
+
if (intel_dsi-dev.dev_ops-mode_fixup)
return intel_dsi-dev.dev_ops-mode_fixup(intel_dsi-dev,
mode, adjusted_mode);
@@ -177,6 +180,10 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder)
tmp |= DPLL_REFA_CLK_ENABLE_VLV;
I915_WRITE(DPLL(pipe), tmp);
+ /* update the hw state for DPLL */
+ intel_crtc-config.dpll_hw_state.dpll = DPLL_INTEGRATED_CLOCK_VLV |
+ DPLL_REFA_CLK_ENABLE_VLV;
+
tmp = I915_READ(DSPCLK_GATE_D);
tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
I915_WRITE(DSPCLK_GATE_D, tmp);
@@ -351,9 +358,21 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
static void intel_dsi_get_config(struct intel_encoder *encoder,
struct intel_crtc_config *pipe_config)
{
+ u32 pclk;
DRM_DEBUG_KMS(\n);
- /* XXX: read flags, set to adjusted_mode */
+ /*
+ * DPLL_MD is not used in case of DSI, reading will get some default
value
+ * set dpll_md = 0
+ */
+ pipe_config-dpll_hw_state.dpll_md = 0;
+
+ pclk = vlv_get_dsi_pclk(encoder, pipe_config-pipe_bpp);
+ if (!pclk)
+ return;
+
+ pipe_config-adjusted_mode.crtc_clock = pclk;
+ pipe_config-port_clock = pclk;
}
static enum drm_mode_status
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index 31db33d..fd51867 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -132,6 +132,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
+extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
extern struct intel_dsi_dev_ops vbt_generic_dsi_display_ops;
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index ba79ec1..8085afe 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -50,6 +50,8 @@ static const u32 lfsr_converts[] = {
71, 35 /* 91 - 92 */
};
+static const int num_lfsr_converts = sizeof(lfsr_converts) /
sizeof(lfsr_converts[0]);
+
This could be just inlined using ARRAY_SIZE.
#ifdef DSI_CLK_FROM_RR
static u32 dsi_rr_formula(const struct drm_display_mode *mode,
@@ -298,3 +300,47 @@ void vlv_disable_dsi_pll(struct intel_encoder *encoder)
mutex_unlock(dev_priv-dpio_lock);
}
+
+u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp)
+{
+ struct
Re: [Intel-gfx] [PATCH 2/3] drm/i915: wait for all DSI FIFOs to be empty
On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
Ensure that the DSI packets for a particular sequence are completely
sent before going ahead in the enabling or disabling of the panel
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Reviewed-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c | 8
drivers/gpu/drm/i915/intel_dsi_cmd.c | 16
drivers/gpu/drm/i915/intel_dsi_cmd.h | 1 +
3 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 61da0e5..98c78ab 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -152,6 +152,8 @@ static void intel_dsi_enable(struct intel_encoder
*encoder)
if (intel_dsi-dev.dev_ops-enable)
intel_dsi-dev.dev_ops-enable(intel_dsi-dev);
+ wait_for_dsi_fifo_empty(intel_dsi);
+
/* assert ip_tg_enable signal */
temp = I915_READ(MIPI_PORT_CTRL(pipe))
~LANE_CONFIGURATION_MASK;
temp = temp | intel_dsi-port_bits;
@@ -192,6 +194,8 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder)
if (intel_dsi-dev.dev_ops-send_otp_cmds)
intel_dsi-dev.dev_ops-send_otp_cmds(intel_dsi-dev);
+ wait_for_dsi_fifo_empty(intel_dsi);
+
/* Enable port in pre-enable phase itself because as per hw team
* recommendation, port should be enabled befor plane pipe */
intel_dsi_enable(encoder);
@@ -232,6 +236,8 @@ static void intel_dsi_disable(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(\n);
if (is_vid_mode(intel_dsi)) {
+ wait_for_dsi_fifo_empty(intel_dsi);
+
/* de-assert ip_tg_enable signal */
temp = I915_READ(MIPI_PORT_CTRL(pipe));
I915_WRITE(MIPI_PORT_CTRL(pipe), temp ~DPI_ENABLE);
@@ -261,6 +267,8 @@ static void intel_dsi_disable(struct intel_encoder
*encoder)
* some next enable sequence send turn on packet error is observed */
if (intel_dsi-dev.dev_ops-disable)
intel_dsi-dev.dev_ops-disable(intel_dsi-dev);
+
+ wait_for_dsi_fifo_empty(intel_dsi);
}
static void intel_dsi_clear_device_ready(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.c
b/drivers/gpu/drm/i915/intel_dsi_cmd.c
index 933c863..7f1430a 100644
--- a/drivers/gpu/drm/i915/intel_dsi_cmd.c
+++ b/drivers/gpu/drm/i915/intel_dsi_cmd.c
@@ -419,3 +419,19 @@ int dpi_send_cmd(struct intel_dsi *intel_dsi, u32 cmd,
bool hs)
return 0;
}
+
+void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi)
+{
+ struct drm_encoder *encoder = intel_dsi-base.base;
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder-crtc);
+ enum pipe pipe = intel_crtc-pipe;
+ u32 mask;
+
+ mask = LP_CTRL_FIFO_EMPTY | HS_CTRL_FIFO_EMPTY |
+ LP_DATA_FIFO_EMPTY | HS_DATA_FIFO_EMPTY;
+
+ if (wait_for((I915_READ(MIPI_GEN_FIFO_STAT(pipe)) mask) == mask, 100))
+ DRM_ERROR(DPI FIFOs are not empty\n);
+}
diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.h
b/drivers/gpu/drm/i915/intel_dsi_cmd.h
index 9a18cbf..46aa1ac 100644
--- a/drivers/gpu/drm/i915/intel_dsi_cmd.h
+++ b/drivers/gpu/drm/i915/intel_dsi_cmd.h
@@ -51,6 +51,7 @@ int dsi_vc_generic_read(struct intel_dsi *intel_dsi, int
channel,
u8 *reqdata, int reqlen, u8 *buf, int buflen);
int dpi_send_cmd(struct intel_dsi *intel_dsi, u32 cmd, bool hs);
+void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi);
/* XXX: questionable write helpers */
static inline int dsi_vc_dcs_write_0(struct intel_dsi *intel_dsi,
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Correctly read backlight PWM for pipe B on vlv/chv
From: Rafael Barbalho rafael.barba...@intel.com
Make the vlv/chv backlight setup more generic by actually looking at which
pipe the panel is attached to and read the backlight PWM registers that were
setup by the bios from that pipe.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
---
drivers/gpu/drm/i915/intel_panel.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 59b028f..be75d76 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1200,32 +1200,28 @@ static int vlv_setup_backlight(struct intel_connector
*connector)
struct drm_device *dev = connector-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_panel *panel = connector-panel;
- enum pipe pipe;
+ enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 ctl, ctl2, val;
- for_each_pipe(pipe) {
- u32 cur_val = I915_READ(VLV_BLC_PWM_CTL(pipe));
+ ctl2 = I915_READ(VLV_BLC_PWM_CTL2(pipe));
+ panel-backlight.active_low_pwm = ctl2 BLM_POLARITY_I965;
- /* Skip if the modulation freq is already set */
- if (cur_val ~BACKLIGHT_DUTY_CYCLE_MASK)
- continue;
+ ctl = I915_READ(VLV_BLC_PWM_CTL(pipe));
- cur_val = BACKLIGHT_DUTY_CYCLE_MASK;
- I915_WRITE(VLV_BLC_PWM_CTL(pipe), (0xf42 16) |
- cur_val);
+ /* Skip if the modulation freq is already set */
+ if ((ctl ~BACKLIGHT_DUTY_CYCLE_MASK) == 0) {
+ ctl = BACKLIGHT_DUTY_CYCLE_MASK;
+ ctl |= (0xf42 16);
+ I915_WRITE(VLV_BLC_PWM_CTL(pipe), ctl);
}
- ctl2 = I915_READ(VLV_BLC_PWM_CTL2(PIPE_A));
- panel-backlight.active_low_pwm = ctl2 BLM_POLARITY_I965;
-
- ctl = I915_READ(VLV_BLC_PWM_CTL(PIPE_A));
panel-backlight.max = ctl 16;
if (!panel-backlight.max)
return -ENODEV;
panel-backlight.min = get_backlight_min_vbt(connector);
- val = _vlv_get_backlight(dev, PIPE_A);
+ val = _vlv_get_backlight(dev, pipe);
panel-backlight.level = intel_panel_compute_brightness(connector, val);
panel-backlight.enabled = (ctl2 BLM_PWM_ENABLE)
--
2.0.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Correctly read backlight PWM for pipe B on vlv/chv
On Tue, Jul 29, 2014 at 01:44:40PM +0100, rafael.barba...@intel.com wrote:
From: Rafael Barbalho rafael.barba...@intel.com
Make the vlv/chv backlight setup more generic by actually looking at which
pipe the panel is attached to and read the backlight PWM registers that were
setup by the bios from that pipe.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
---
drivers/gpu/drm/i915/intel_panel.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 59b028f..be75d76 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1200,32 +1200,28 @@ static int vlv_setup_backlight(struct intel_connector
*connector)
struct drm_device *dev = connector-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_panel *panel = connector-panel;
- enum pipe pipe;
+ enum pipe pipe = intel_get_pipe_from_connector(connector);
This won't work unless the connector is already enabled.
The power sequencer has a similar problem where we have to somehow deduce
the correct pipe. vlv_power_sequencer_pipe() tries to guess the correct pipe
there.
We could start with intel_get_pipe_from_connector() and if that fails we'd
do something like vlv_power_sequencer_pipe(). Hmm, except the backlight
registers don't have the port information, so I guess we'd need to pick the
pipe simply based on the DP port control register.
u32 ctl, ctl2, val;
- for_each_pipe(pipe) {
- u32 cur_val = I915_READ(VLV_BLC_PWM_CTL(pipe));
+ ctl2 = I915_READ(VLV_BLC_PWM_CTL2(pipe));
+ panel-backlight.active_low_pwm = ctl2 BLM_POLARITY_I965;
- /* Skip if the modulation freq is already set */
- if (cur_val ~BACKLIGHT_DUTY_CYCLE_MASK)
- continue;
+ ctl = I915_READ(VLV_BLC_PWM_CTL(pipe));
- cur_val = BACKLIGHT_DUTY_CYCLE_MASK;
- I915_WRITE(VLV_BLC_PWM_CTL(pipe), (0xf42 16) |
-cur_val);
+ /* Skip if the modulation freq is already set */
+ if ((ctl ~BACKLIGHT_DUTY_CYCLE_MASK) == 0) {
+ ctl = BACKLIGHT_DUTY_CYCLE_MASK;
+ ctl |= (0xf42 16);
+ I915_WRITE(VLV_BLC_PWM_CTL(pipe), ctl);
}
- ctl2 = I915_READ(VLV_BLC_PWM_CTL2(PIPE_A));
- panel-backlight.active_low_pwm = ctl2 BLM_POLARITY_I965;
-
- ctl = I915_READ(VLV_BLC_PWM_CTL(PIPE_A));
panel-backlight.max = ctl 16;
if (!panel-backlight.max)
return -ENODEV;
panel-backlight.min = get_backlight_min_vbt(connector);
- val = _vlv_get_backlight(dev, PIPE_A);
+ val = _vlv_get_backlight(dev, pipe);
panel-backlight.level = intel_panel_compute_brightness(connector, val);
panel-backlight.enabled = (ctl2 BLM_PWM_ENABLE)
--
2.0.3
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Correctly read backlight PWM for pipe B on vlv/chv
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Tuesday, July 29, 2014 2:13 PM
To: Barbalho, Rafael
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Correctly read backlight PWM for pipe B on
vlv/chv
On Tue, Jul 29, 2014 at 01:44:40PM +0100, rafael.barba...@intel.com wrote:
From: Rafael Barbalho rafael.barba...@intel.com
Make the vlv/chv backlight setup more generic by actually looking at which
pipe the panel is attached to and read the backlight PWM registers that
were
setup by the bios from that pipe.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
---
drivers/gpu/drm/i915/intel_panel.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 59b028f..be75d76 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1200,32 +1200,28 @@ static int vlv_setup_backlight(struct
intel_connector *connector)
struct drm_device *dev = connector-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_panel *panel = connector-panel;
- enum pipe pipe;
+ enum pipe pipe = intel_get_pipe_from_connector(connector);
This won't work unless the connector is already enabled.
The power sequencer has a similar problem where we have to somehow
deduce
the correct pipe. vlv_power_sequencer_pipe() tries to guess the correct
pipe
there.
We could start with intel_get_pipe_from_connector() and if that fails we'd
do something like vlv_power_sequencer_pipe(). Hmm, except the backlight
registers don't have the port information, so I guess we'd need to pick the
pipe simply based on the DP port control register.
Fair point, I didn't realise that intel_get_pipe_from_connector could return
INVALID_PIPE.
How about if I add:
+ enum pipe pipe = intel_get_pipe_from_connector(connector);
+
+ if (pipe == INVALID_PIPE)
+ pipe = PIPE_A;
It would return the driver to the current behaviour but still enable pipe B
when that is present
at start up.
u32 ctl, ctl2, val;
- for_each_pipe(pipe) {
- u32 cur_val = I915_READ(VLV_BLC_PWM_CTL(pipe));
+ ctl2 = I915_READ(VLV_BLC_PWM_CTL2(pipe));
+ panel-backlight.active_low_pwm = ctl2 BLM_POLARITY_I965;
- /* Skip if the modulation freq is already set */
- if (cur_val ~BACKLIGHT_DUTY_CYCLE_MASK)
- continue;
+ ctl = I915_READ(VLV_BLC_PWM_CTL(pipe));
- cur_val = BACKLIGHT_DUTY_CYCLE_MASK;
- I915_WRITE(VLV_BLC_PWM_CTL(pipe), (0xf42 16) |
- cur_val);
+ /* Skip if the modulation freq is already set */
+ if ((ctl ~BACKLIGHT_DUTY_CYCLE_MASK) == 0) {
+ ctl = BACKLIGHT_DUTY_CYCLE_MASK;
+ ctl |= (0xf42 16);
+ I915_WRITE(VLV_BLC_PWM_CTL(pipe), ctl);
}
- ctl2 = I915_READ(VLV_BLC_PWM_CTL2(PIPE_A));
- panel-backlight.active_low_pwm = ctl2 BLM_POLARITY_I965;
-
- ctl = I915_READ(VLV_BLC_PWM_CTL(PIPE_A));
panel-backlight.max = ctl 16;
if (!panel-backlight.max)
return -ENODEV;
panel-backlight.min = get_backlight_min_vbt(connector);
- val = _vlv_get_backlight(dev, PIPE_A);
+ val = _vlv_get_backlight(dev, pipe);
panel-backlight.level =
intel_panel_compute_brightness(connector, val);
panel-backlight.enabled = (ctl2 BLM_PWM_ENABLE)
--
2.0.3
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Correctly read backlight PWM for pipe B on vlv/chv
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Barbalho, Rafael
Sent: Tuesday, July 29, 2014 2:38 PM
To: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Correctly read backlight PWM for
pipe B on vlv/chv
Importance: High
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Tuesday, July 29, 2014 2:13 PM
To: Barbalho, Rafael
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Correctly read backlight PWM for pipe B on
vlv/chv
On Tue, Jul 29, 2014 at 01:44:40PM +0100, rafael.barba...@intel.com
wrote:
From: Rafael Barbalho rafael.barba...@intel.com
Make the vlv/chv backlight setup more generic by actually looking at
which
pipe the panel is attached to and read the backlight PWM registers that
were
setup by the bios from that pipe.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
---
drivers/gpu/drm/i915/intel_panel.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 59b028f..be75d76 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1200,32 +1200,28 @@ static int vlv_setup_backlight(struct
intel_connector *connector)
struct drm_device *dev = connector-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_panel *panel = connector-panel;
- enum pipe pipe;
+ enum pipe pipe = intel_get_pipe_from_connector(connector);
This won't work unless the connector is already enabled.
The power sequencer has a similar problem where we have to somehow
deduce
the correct pipe. vlv_power_sequencer_pipe() tries to guess the correct
pipe
there.
We could start with intel_get_pipe_from_connector() and if that fails we'd
do something like vlv_power_sequencer_pipe(). Hmm, except the
backlight
registers don't have the port information, so I guess we'd need to pick the
pipe simply based on the DP port control register.
Fair point, I didn't realise that intel_get_pipe_from_connector could return
INVALID_PIPE.
How about if I add:
+ enum pipe pipe = intel_get_pipe_from_connector(connector);
+
+ if (pipe == INVALID_PIPE)
+ pipe = PIPE_A;
It would return the driver to the current behaviour but still enable pipe B
when that is present
at start up.
Thinking about it I need to still keep the initial for_each_pipe loop to very
subtly
initialise both pipe A B to a known PWM modulation frequency, which would
explain
why setting the backlight brightness works on pipe B. However, inheriting it
from the
bios is not working, which is what I am seeing. Let me rejig the patch and I'll
send out
a new version.
u32 ctl, ctl2, val;
- for_each_pipe(pipe) {
- u32 cur_val = I915_READ(VLV_BLC_PWM_CTL(pipe));
+ ctl2 = I915_READ(VLV_BLC_PWM_CTL2(pipe));
+ panel-backlight.active_low_pwm = ctl2 BLM_POLARITY_I965;
- /* Skip if the modulation freq is already set */
- if (cur_val ~BACKLIGHT_DUTY_CYCLE_MASK)
- continue;
+ ctl = I915_READ(VLV_BLC_PWM_CTL(pipe));
- cur_val = BACKLIGHT_DUTY_CYCLE_MASK;
- I915_WRITE(VLV_BLC_PWM_CTL(pipe), (0xf42 16) |
-cur_val);
+ /* Skip if the modulation freq is already set */
+ if ((ctl ~BACKLIGHT_DUTY_CYCLE_MASK) == 0) {
+ ctl = BACKLIGHT_DUTY_CYCLE_MASK;
+ ctl |= (0xf42 16);
+ I915_WRITE(VLV_BLC_PWM_CTL(pipe), ctl);
}
- ctl2 = I915_READ(VLV_BLC_PWM_CTL2(PIPE_A));
- panel-backlight.active_low_pwm = ctl2 BLM_POLARITY_I965;
-
- ctl = I915_READ(VLV_BLC_PWM_CTL(PIPE_A));
panel-backlight.max = ctl 16;
if (!panel-backlight.max)
return -ENODEV;
panel-backlight.min = get_backlight_min_vbt(connector);
- val = _vlv_get_backlight(dev, PIPE_A);
+ val = _vlv_get_backlight(dev, pipe);
panel-backlight.level =
intel_panel_compute_brightness(connector, val);
panel-backlight.enabled = (ctl2 BLM_PWM_ENABLE)
--
2.0.3
--
Ville Syrjälä
Intel OTC
___
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 1/3] drm/i915: fix cursor handling when runtime suspended
2014-07-29 7:22 GMT-03:00 Ville Syrjälä ville.syrj...@linux.intel.com:
On Mon, Jul 28, 2014 at 03:37:12PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If we're runtime suspended and try to use the cursor interfaces, we
will get a lot of WARNs saying we did the wrong thing.
For intel_crtc_update_cursor(), all we need to do is return if the
CRTC is not active, since writing the registers won't really have any
effect if the screen is not visible, and we will write the registers
later when enabling the screen.
For intel_crtc_cursor_set_obj(), we just need to wake up the hardware
then pinning the display plane.
v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
Testcase: igt/pm_rpm/cursor
Testcase: igt/pm_rpm/cursor-dpms
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
Cc: sta...@vger.kernel.org
Signed-off-by: Paulo Zanoni paulo.r.zan...@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 1edfd1a..f1a9b5c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8144,6 +8144,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
if (base == 0 intel_crtc-cursor_base == 0)
return;
+ if (!intel_crtc-active)
+ return;
+
I915_WRITE(CURPOS(pipe), pos);
if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev) || IS_BROADWELL(dev))
@@ -8217,7 +8220,9 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
if (need_vtd_wa(dev))
alignment = 64*1024;
+ intel_runtime_pm_get(dev_priv);
ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
+ intel_runtime_pm_put(dev_priv);
put_fence() would need runtime pm too I think.
This is exactly why I wanted the get/put calls around everything on
those functions... I'll see if I can reproduce this on the test suite
too.
if (ret) {
DRM_DEBUG_KMS(failed to move cursor bo into the
GTT\n);
goto fail_locked;
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
--
Paulo Zanoni
___
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: factor out intel_edp_panel_vdd_sanitize
On Fri, Jun 27, 2014 at 09:35:13PM +0300, Imre Deak wrote:
This will be needed by an upcoming patch too that needs to sanitize the
VDD state during resume. The additional async disabling is only needed
for the resume path, here it doesn't make a difference since we enable
VDD right after the sanitize call.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 59
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b5ec489..a40d914 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1234,6 +1234,19 @@ static void edp_panel_vdd_work(struct work_struct
*__work)
drm_modeset_unlock(dev-mode_config.connection_mutex);
}
+static void edp_panel_vdd_schedule_off(struct intel_dp *intel_dp)
+{
+ unsigned long delay;
+
+ /*
+ * Queue the timer to fire a long time from now (relative to the power
+ * down delay) to keep the panel power up across a sequence of
+ * operations.
+ */
+ delay = msecs_to_jiffies(intel_dp-panel_power_cycle_delay * 5);
+ schedule_delayed_work(intel_dp-panel_vdd_work, delay);
+}
+
static void edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
{
if (!is_edp(intel_dp))
@@ -1243,17 +1256,10 @@ static void edp_panel_vdd_off(struct intel_dp
*intel_dp, bool sync)
intel_dp-want_panel_vdd = false;
- if (sync) {
+ if (sync)
edp_panel_vdd_off_sync(intel_dp);
- } else {
- /*
- * Queue the timer to fire a long
- * time from now (relative to the power down delay)
- * to keep the panel power up across a sequence of operations
- */
- schedule_delayed_work(intel_dp-panel_vdd_work,
-
msecs_to_jiffies(intel_dp-panel_power_cycle_delay * 5));
- }
+ else
+ edp_panel_vdd_schedule_off(intel_dp);
}
void intel_edp_panel_on(struct intel_dp *intel_dp)
@@ -4179,6 +4185,31 @@ intel_dp_drrs_init(struct intel_digital_port
*intel_dig_port,
return downclock_mode;
}
+void intel_edp_panel_vdd_sanitize(struct intel_encoder *intel_encoder)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder-base);
+ struct drm_device *dev = intel_encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ enum intel_display_power_domain power_domain;
+
+ if (intel_encoder-type != INTEL_OUTPUT_EDP)
+ return;
I'd move the intel_dp assignment after the encoder type check to avoid
anyone thinking that they're allowed to dereference it before we're
sure about the type.
Apart from that both patches are:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
+
+ if (!edp_have_panel_vdd(intel_dp))
+ return;
+ /*
+ * The VDD bit needs a power domain reference, so if the bit is
+ * already enabled when we boot or resume, grab this reference and
+ * schedule a vdd off, so we don't hold on to the reference
+ * indefinitely.
+ */
+ DRM_DEBUG_KMS(VDD left on by BIOS, adjusting state tracking\n);
+ power_domain = intel_display_port_power_domain(intel_encoder);
+ intel_display_power_get(dev_priv, power_domain);
+
+ edp_panel_vdd_schedule_off(intel_dp);
+}
+
static bool intel_edp_init_connector(struct intel_dp *intel_dp,
struct intel_connector *intel_connector,
struct edp_power_seq *power_seq)
@@ -4199,13 +4230,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
if (!is_edp(intel_dp))
return true;
- /* The VDD bit needs a power domain reference, so if the bit is already
- * enabled when we boot, grab this reference. */
- if (edp_have_panel_vdd(intel_dp)) {
- enum intel_display_power_domain power_domain;
- power_domain = intel_display_port_power_domain(intel_encoder);
- intel_display_power_get(dev_priv, power_domain);
- }
+ intel_edp_panel_vdd_sanitize(intel_encoder);
/* Cache DPCD and EDID for edp. */
intel_edp_panel_vdd_on(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 5f7c7bd..150c09b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -855,6 +855,7 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port
port);
void intel_edp_backlight_on(struct intel_dp *intel_dp);
void intel_edp_backlight_off(struct intel_dp *intel_dp);
void intel_edp_panel_vdd_on(struct intel_dp *intel_dp);
+void intel_edp_panel_vdd_sanitize(struct intel_encoder *intel_encoder);
void intel_edp_panel_on(struct
Re: [Intel-gfx] [PATCH] drm/i915: s/seqno/request/ tracking inside objects
On Tue, 29 Jul 2014 12:41:26 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jul 29, 2014 at 08:29:53AM +0100, Chris Wilson wrote:
On Mon, Jul 28, 2014 at 01:44:12PM -0700, Jesse Barnes wrote:
@@ -3038,44 +3203,35 @@ out:
*/
int
i915_gem_object_sync(struct drm_i915_gem_object *obj,
-struct intel_engine_cs *to)
+struct intel_engine_cs *to,
+bool readonly)
{
It might be nice to have sync_read/sync_write functions instead, since
looking up bool args or unnamed enums is a pain.
Not convinced since it is used in a single location and two function
calls would look unelegant - but we could switch to PROT_READ |
PROT_WRITE throughout.
Switching to PROT_READ/WRITE might be nice as a general cleanup (or some
other named thing) since read_only/write booleans are all over the place.
So I like this, but definitely something for a separate patch.
Agreed, that's a good idea.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/40] drm/i915: Add cdclk change support for chv
On Sat, 28 Jun 2014 02:03:57 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Looks like the Punit is supposed to support the 400MHz cdclk directly on
chv, so we don't need the vlv tricks.
FIXME: Punit doesn't seem ready for this yet on current hw
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++
drivers/gpu/drm/i915/intel_display.c | 50
++--
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f156591..e296312 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -491,6 +491,10 @@
#define BUNIT_REG_BISOC 0x11
#define PUNIT_REG_DSPFREQ0x36
+#define DSPFREQSTAT_SHIFT_CHV 24
+#define DSPFREQSTAT_MASK_CHV (0x1f
DSPFREQSTAT_SHIFT_CHV)
+#define DSPFREQGUAR_SHIFT_CHV 8
+#define DSPFREQGUAR_MASK_CHV (0x1f
DSPFREQGUAR_SHIFT_CHV)
#define DSPFREQSTAT_SHIFT 30
#define DSPFREQSTAT_MASK (0x3 DSPFREQSTAT_SHIFT)
#define DSPFREQGUAR_SHIFT 14
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 99c10d1..9af1d13 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4529,6 +4529,47 @@ static void valleyview_set_cdclk(struct drm_device
*dev, int cdclk)
vlv_update_cdclk(dev);
}
+static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 val, cmd;
+
+ WARN_ON(dev_priv-display.get_display_clock_speed(dev) !=
dev_priv-vlv_cdclk_freq);
+
+ switch (cdclk) {
+ case 40:
+ cmd = 3;
+ break;
+ case 33:
+ case 32:
+ cmd = 2;
+ break;
+ case 27:
+ cmd = 1;
+ break;
+ case 20:
+ cmd = 0;
+ break;
+ default:
+ WARN_ON(1);
+ return;
+ }
+
+ mutex_lock(dev_priv-rps.hw_lock);
+ val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
+ val = ~DSPFREQGUAR_MASK_CHV;
+ val |= (cmd DSPFREQGUAR_SHIFT_CHV);
+ vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
+ if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ)
+ DSPFREQSTAT_MASK_CHV) == (cmd DSPFREQSTAT_SHIFT_CHV),
+ 50)) {
+ DRM_ERROR(timed out waiting for CDclk change\n);
+ }
+ mutex_unlock(dev_priv-rps.hw_lock);
+
+ vlv_update_cdclk(dev);
+}
+
static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
int max_pixclk)
{
@@ -4597,8 +4638,13 @@ static void valleyview_modeset_global_resources(struct
drm_device *dev)
int max_pixclk = intel_mode_max_pixclk(dev_priv);
int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
- if (req_cdclk != dev_priv-vlv_cdclk_freq)
- valleyview_set_cdclk(dev, req_cdclk);
+ if (req_cdclk != dev_priv-vlv_cdclk_freq) {
+ if (IS_CHERRYVIEW(dev))
+ cherryview_set_cdclk(dev, req_cdclk);
+ else
+ valleyview_set_cdclk(dev, req_cdclk);
+ }
+
modeset_update_crtc_power_domains(dev);
}
Which doc has these Punit commands? I'm assuming you have them
correct, but a ref would be good if we don't already have one.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
There should probably be a JIRA for this too so QA can verify once we
have updated punit support.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/40] drm/i915: Disable cdclk changes for chv until Punit is ready
On Sat, 28 Jun 2014 02:03:58 +0300 ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Punit seems a bit WIP still. Disable cdclk changes until we have hardware where it works. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 9af1d13..4abf8b6f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4576,6 +4576,10 @@ static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv, int vco = valleyview_get_vco(dev_priv); int freq_320 = (vco 1) % 32 != 0 ? 33 : 32; + /* FIXME: Punit isn't quite ready yet */ + if (IS_CHERRYVIEW(dev_priv-dev)) + return 40; + /* * Really only a few cases to deal with, as only 4 CDclks are supported: * 200MHz @@ -5297,6 +5301,10 @@ static int valleyview_get_display_clock_speed(struct drm_device *dev) u32 val; int divider; + /* FIXME: Punit isn't quite ready yet */ + if (IS_CHERRYVIEW(dev)) + return 40; + mutex_lock(dev_priv-dpio_lock); val = vlv_cck_read(dev_priv, CCK_DISPLAY_CLOCK_CONTROL); mutex_unlock(dev_priv-dpio_lock); Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/40] drm/i915: Leave DPLL ref clocks on
On Sat, 28 Jun 2014 02:03:59 +0300 ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com We enable the DPLL refclock already when bringing up the cmnlane power well, so also leave it on when otherwise disabling the DPLL. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 4abf8b6f..a430699f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1709,7 +1709,7 @@ static void chv_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe) assert_pipe_disabled(dev_priv, pipe); /* Set PLL en = 0 */ - val = DPLL_SSC_REF_CLOCK_CHV; + val = DPLL_SSC_REF_CLOCK_CHV | DPLL_REFA_CLK_ENABLE_VLV; if (pipe != PIPE_A) val |= DPLL_INTEGRATED_CRI_CLK_VLV; I915_WRITE(DPLL(pipe), val); Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/40] drm/i915: Split chv_update_pll() apart
On Sat, 28 Jun 2014 02:04:00 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Split chv_update_pll() into two parts ala:
commit bdd4b6a655749970cc632aafc5fd596c07b60b1c
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Apr 24 23:55:11 2014 +0200
drm/i915: Extract vlv_prepare_pll
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a430699f..3e4d570 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -100,6 +100,7 @@ static void ironlake_set_pipeconf(struct drm_crtc *crtc);
static void haswell_set_pipeconf(struct drm_crtc *crtc);
static void intel_set_pipe_csc(struct drm_crtc *crtc);
static void vlv_prepare_pll(struct intel_crtc *crtc);
+static void chv_prepare_pll(struct intel_crtc *crtc);
typedef struct {
int min, max;
@@ -4670,8 +4671,12 @@ static void valleyview_crtc_enable(struct drm_crtc
*crtc)
is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
- if (!is_dsi !IS_CHERRYVIEW(dev))
- vlv_prepare_pll(intel_crtc);
+ if (!is_dsi) {
+ if (IS_CHERRYVIEW(dev))
+ chv_prepare_pll(intel_crtc);
+ else
+ vlv_prepare_pll(intel_crtc);
+ }
/* Set up the display plane register */
dspcntr = DISPPLANE_GAMMA_ENABLE;
@@ -5692,6 +5697,18 @@ static void vlv_prepare_pll(struct intel_crtc *crtc)
static void chv_update_pll(struct intel_crtc *crtc)
{
+ crtc-config.dpll_hw_state.dpll = DPLL_SSC_REF_CLOCK_CHV |
+ DPLL_REFA_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS |
+ DPLL_VCO_ENABLE;
+ if (crtc-pipe != PIPE_A)
+ crtc-config.dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
+
+ crtc-config.dpll_hw_state.dpll_md =
+ (crtc-config.pixel_multiplier - 1)
DPLL_MD_UDI_MULTIPLIER_SHIFT;
+}
+
+static void chv_prepare_pll(struct intel_crtc *crtc)
+{
struct drm_device *dev = crtc-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
int pipe = crtc-pipe;
@@ -5701,15 +5718,6 @@ static void chv_update_pll(struct intel_crtc *crtc)
u32 bestn, bestm1, bestm2, bestp1, bestp2, bestm2_frac;
int refclk;
- crtc-config.dpll_hw_state.dpll = DPLL_SSC_REF_CLOCK_CHV |
- DPLL_REFA_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS |
- DPLL_VCO_ENABLE;
- if (pipe != PIPE_A)
- crtc-config.dpll_hw_state.dpll |= DPLL_INTEGRATED_CRI_CLK_VLV;
-
- crtc-config.dpll_hw_state.dpll_md =
- (crtc-config.pixel_multiplier - 1)
DPLL_MD_UDI_MULTIPLIER_SHIFT;
-
bestn = crtc-config.dpll.n;
bestm2_frac = crtc-config.dpll.m2 0x3f;
bestm1 = crtc-config.dpll.m1;
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/40] drm/i915: Call intel_{dp, hdmi}_prepare for chv
On Sat, 28 Jun 2014 02:04:02 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV was forgotten the intel_{dp,hdmi}_prepare() were introduced (or the
chv patches were still in flight?). Call these when enabling the ports.
Things tend to work much better when we actually write something
to the port registers :)
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b5ec489..e272f92 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2197,6 +2197,8 @@ static void chv_dp_pre_pll_enable(struct intel_encoder
*encoder)
enum pipe pipe = intel_crtc-pipe;
u32 val;
+ intel_dp_prepare(encoder);
+
mutex_lock(dev_priv-dpio_lock);
/* program left/right clock distribution */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2422413..c9d77d3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1240,6 +1240,8 @@ static void chv_hdmi_pre_pll_enable(struct
intel_encoder *encoder)
enum pipe pipe = intel_crtc-pipe;
u32 val;
+ intel_hdmi_prepare(encoder);
+
mutex_lock(dev_priv-dpio_lock);
/* program left/right clock distribution */
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/40] drm/i915: Clarify CHV swing margin/deemph bits
On Sat, 28 Jun 2014 02:04:03 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV display PHY registes have two swing margin/deemph settings. Make it
clear which ones we're using.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 8 ++--
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_hdmi.c | 4 ++--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e296312..ba90320 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -831,8 +831,8 @@ enum punit_power_well {
#define _VLV_TX_DW2_CH0 0x8288
#define _VLV_TX_DW2_CH1 0x8488
-#define DPIO_SWING_MARGIN_SHIFT16
-#define DPIO_SWING_MARGIN_MASK (0xff DPIO_SWING_MARGIN_SHIFT)
+#define DPIO_SWING_MARGIN000_SHIFT 16
+#define DPIO_SWING_MARGIN000_MASK (0xff DPIO_SWING_MARGIN000_SHIFT)
#define DPIO_UNIQ_TRANS_SCALE_SHIFT8
#define VLV_TX_DW2(ch) _PORT(ch, _VLV_TX_DW2_CH0, _VLV_TX_DW2_CH1)
@@ -840,12 +840,16 @@ enum punit_power_well {
#define _VLV_TX_DW3_CH1 0x848c
/* The following bit for CHV phy */
#define DPIO_TX_UNIQ_TRANS_SCALE_EN(127)
+#define DPIO_SWING_MARGIN101_SHIFT 16
+#define DPIO_SWING_MARGIN101_MASK (0xff DPIO_SWING_MARGIN101_SHIFT)
#define VLV_TX_DW3(ch) _PORT(ch, _VLV_TX_DW3_CH0, _VLV_TX_DW3_CH1)
#define _VLV_TX_DW4_CH0 0x8290
#define _VLV_TX_DW4_CH1 0x8490
#define DPIO_SWING_DEEMPH9P5_SHIFT 24
#define DPIO_SWING_DEEMPH9P5_MASK (0xff DPIO_SWING_DEEMPH9P5_SHIFT)
+#define DPIO_SWING_DEEMPH6P0_SHIFT 16
+#define DPIO_SWING_DEEMPH6P0_MASK (0xff DPIO_SWING_DEEMPH6P0_SHIFT)
#define VLV_TX_DW4(ch) _PORT(ch, _VLV_TX_DW4_CH0, _VLV_TX_DW4_CH1)
#define _VLV_TX3_DW4_CH0 0x690
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e272f92..4457f8f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2565,8 +2565,8 @@ static uint32_t intel_chv_signal_levels(struct intel_dp
*intel_dp)
/* Program swing margin */
for (i = 0; i 4; i++) {
val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW2(ch, i));
- val = ~DPIO_SWING_MARGIN_MASK;
- val |= margin_reg_value DPIO_SWING_MARGIN_SHIFT;
+ val = ~DPIO_SWING_MARGIN000_MASK;
+ val |= margin_reg_value DPIO_SWING_MARGIN000_SHIFT;
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW2(ch, i), val);
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index c9d77d3..c5c88127 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1411,8 +1411,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder)
for (i = 0; i 4; i++) {
val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW2(ch, i));
- val = ~DPIO_SWING_MARGIN_MASK;
- val |= 102 DPIO_SWING_MARGIN_SHIFT;
+ val = ~DPIO_SWING_MARGIN000_MASK;
+ val |= 102 DPIO_SWING_MARGIN000_SHIFT;
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW2(ch, i), val);
}
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/40] drm/i915: Override display PHY TX FIFO reset master on chv
On Sat, 28 Jun 2014 02:04:05 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Just an attempt to frob these bits. Apparently we should not need to
touch them (apart from maybe making sure the override is disabled so
that the hardware automagically does the right thing).
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 12
drivers/gpu/drm/i915/intel_dp.c | 23 +++
drivers/gpu/drm/i915/intel_hdmi.c | 23 +++
3 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2a7bc22..d246609 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -758,6 +758,8 @@ enum punit_power_well {
#define _VLV_PCS_DW0_CH1 0x8400
#define DPIO_PCS_TX_LANE2_RESET(116)
#define DPIO_PCS_TX_LANE1_RESET(17)
+#define DPIO_LEFT_TXFIFO_RST_MASTER2 (14)
+#define DPIO_RIGHT_TXFIFO_RST_MASTER2 (13)
#define VLV_PCS_DW0(ch) _PORT(ch, _VLV_PCS_DW0_CH0, _VLV_PCS_DW0_CH1)
#define _VLV_PCS01_DW0_CH0 0x200
@@ -834,8 +836,18 @@ enum punit_power_well {
#define _VLV_PCS_DW11_CH00x822c
#define _VLV_PCS_DW11_CH10x842c
+#define DPIO_LANEDESKEW_STRAP_OVRD (13)
+#define DPIO_LEFT_TXFIFO_RST_MASTER(11)
+#define DPIO_RIGHT_TXFIFO_RST_MASTER (10)
#define VLV_PCS_DW11(ch) _PORT(ch, _VLV_PCS_DW11_CH0, _VLV_PCS_DW11_CH1)
+#define _VLV_PCS01_DW11_CH0 0x022c
+#define _VLV_PCS23_DW11_CH0 0x042c
+#define _VLV_PCS01_DW11_CH1 0x262c
+#define _VLV_PCS23_DW11_CH1 0x282c
+#define VLV_PCS01_DW11(ch) _PORT(ch, _VLV_PCS01_DW0_CH0, _VLV_PCS01_DW0_CH1)
+#define VLV_PCS23_DW11(ch) _PORT(ch, _VLV_PCS23_DW0_CH0, _VLV_PCS23_DW0_CH1)
+
#define _VLV_PCS_DW12_CH00x8230
#define _VLV_PCS_DW12_CH10x8430
#define VLV_PCS_DW12(ch) _PORT(ch, _VLV_PCS_DW12_CH0, _VLV_PCS_DW12_CH1)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c59e8fc..814a950 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2139,6 +2139,29 @@ static void chv_pre_enable_dp(struct intel_encoder
*encoder)
mutex_lock(dev_priv-dpio_lock);
+ /* TX FIFO reset source */
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
+ val |= DPIO_LEFT_TXFIFO_RST_MASTER2;
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER2;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER;
+ val = ~DPIO_RIGHT_TXFIFO_RST_MASTER;
+ val |= DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER2;
+ val = ~DPIO_RIGHT_TXFIFO_RST_MASTER2;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER;
+ val |= DPIO_RIGHT_TXFIFO_RST_MASTER;
+ val |= DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
+
/* Deassert soft data lane reset*/
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
val |= CHV_PCS_REQ_SOFTRESET_EN;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index cda6506..47430d5 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1358,6 +1358,29 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder)
mutex_lock(dev_priv-dpio_lock);
+ /* TX FIFO reset source */
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
+ val |= DPIO_LEFT_TXFIFO_RST_MASTER2;
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER2;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER;
+ val = ~DPIO_RIGHT_TXFIFO_RST_MASTER;
+ val |= DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER2;
+ val = ~DPIO_RIGHT_TXFIFO_RST_MASTER2;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
+ val = ~DPIO_LEFT_TXFIFO_RST_MASTER;
+ val |= DPIO_RIGHT_TXFIFO_RST_MASTER;
+ val |= DPIO_LANEDESKEW_STRAP_OVRD;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
+
/* Deassert soft data lane reset*/
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
val |=
Re: [Intel-gfx] [PATCH 27/40] drm/i915: Split a few long debug prints
On Sat, 28 Jun 2014 02:04:18 +0300 ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Split some WM debug prints to multiple lines. This shouldn't hurt grappability since the important part is at the start and the rest is just repeated stuff for each pipe. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_pm.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index f0516a7..cb0b4b4 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1345,7 +1345,8 @@ static void valleyview_update_wm(struct drm_crtc *crtc) plane_sr = cursor_sr = 0; } - DRM_DEBUG_KMS(Setting FIFO watermarks - A: plane=%d, cursor=%d, B: plane=%d, cursor=%d, SR: plane=%d, cursor=%d\n, + DRM_DEBUG_KMS(Setting FIFO watermarks - A: plane=%d, cursor=%d, + B: plane=%d, cursor=%d, SR: plane=%d, cursor=%d\n, planea_wm, cursora_wm, planeb_wm, cursorb_wm, plane_sr, cursor_sr); @@ -1397,7 +1398,8 @@ static void g4x_update_wm(struct drm_crtc *crtc) plane_sr = cursor_sr = 0; } - DRM_DEBUG_KMS(Setting FIFO watermarks - A: plane=%d, cursor=%d, B: plane=%d, cursor=%d, SR: plane=%d, cursor=%d\n, + DRM_DEBUG_KMS(Setting FIFO watermarks - A: plane=%d, cursor=%d, + B: plane=%d, cursor=%d, SR: plane=%d, cursor=%d\n, planea_wm, cursora_wm, planeb_wm, cursorb_wm, plane_sr, cursor_sr); Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/40] drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
On Sat, 28 Jun 2014 02:04:20 +0300
ville.syrj...@linux.intel.com wrote:
From: Kenneth Graunke kenn...@whitecape.org
We'll want to reuse this for a workaround.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 36
-
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2faef26..97796b1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -381,6 +381,27 @@ gen7_render_ring_flush(struct intel_engine_cs *ring,
}
static int
+gen8_emit_pipe_control(struct intel_engine_cs *ring,
+u32 flags, u32 scratch_addr)
+{
+ int ret;
+
+ ret = intel_ring_begin(ring, 6);
+ if (ret)
+ return ret;
+
+ intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
+ intel_ring_emit(ring, flags);
+ intel_ring_emit(ring, scratch_addr);
+ intel_ring_emit(ring, 0);
+ intel_ring_emit(ring, 0);
+ intel_ring_emit(ring, 0);
+ intel_ring_advance(ring);
+
+ return 0;
+}
+
+static int
gen8_render_ring_flush(struct intel_engine_cs *ring,
u32 invalidate_domains, u32 flush_domains)
{
@@ -405,20 +426,7 @@ gen8_render_ring_flush(struct intel_engine_cs *ring,
flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
}
- ret = intel_ring_begin(ring, 6);
- if (ret)
- return ret;
-
- intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
- intel_ring_emit(ring, flags);
- intel_ring_emit(ring, scratch_addr);
- intel_ring_emit(ring, 0);
- intel_ring_emit(ring, 0);
- intel_ring_emit(ring, 0);
- intel_ring_advance(ring);
-
- return 0;
-
+ return gen8_emit_pipe_control(ring, flags, scratch_addr);
}
static void ring_write_tail(struct intel_engine_cs *ring,
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 34/40] drm/i915: Add DP training pattern 3 for CHV
On Sat, 28 Jun 2014 02:04:25 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV supports DP training pattern 3. Add the required stuff.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 18 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 85b59c4..8debe61 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3515,6 +3515,8 @@ enum punit_power_well {
#define DP_LINK_TRAIN_OFF (3 28)
#define DP_LINK_TRAIN_MASK (3 28)
#define DP_LINK_TRAIN_SHIFT28
+#define DP_LINK_TRAIN_PAT_3_CHV(1 14)
+#define DP_LINK_TRAIN_MASK_CHV ((3 28)|(114))
/* CPT Link training mode */
#define DP_LINK_TRAIN_PAT_1_CPT(0 8)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 739dc43..a825ff1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2900,7 +2900,10 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
}
} else {
- *DP = ~DP_LINK_TRAIN_MASK;
+ if (IS_CHERRYVIEW(dev))
+ *DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ *DP = ~DP_LINK_TRAIN_MASK;
switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
case DP_TRAINING_PATTERN_DISABLE:
@@ -2913,8 +2916,12 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
*DP |= DP_LINK_TRAIN_PAT_2;
break;
case DP_TRAINING_PATTERN_3:
- DRM_ERROR(DP training pattern 3 not supported\n);
- *DP |= DP_LINK_TRAIN_PAT_2;
+ if (IS_CHERRYVIEW(dev)) {
+ *DP |= DP_LINK_TRAIN_PAT_3_CHV;
+ } else {
+ DRM_ERROR(DP training pattern 3 not
supported\n);
+ *DP |= DP_LINK_TRAIN_PAT_2;
+ }
break;
}
}
@@ -3201,7 +3208,10 @@ intel_dp_link_down(struct intel_dp *intel_dp)
DP = ~DP_LINK_TRAIN_MASK_CPT;
I915_WRITE(intel_dp-output_reg, DP |
DP_LINK_TRAIN_PAT_IDLE_CPT);
} else {
- DP = ~DP_LINK_TRAIN_MASK;
+ if (IS_CHERRYVIEW(dev))
+ DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ DP = ~DP_LINK_TRAIN_MASK;
I915_WRITE(intel_dp-output_reg, DP | DP_LINK_TRAIN_PAT_IDLE);
}
POSTING_READ(intel_dp-output_reg);
I guess we could have a whole IS_CHV block, but that would probably add
more code than it saved...
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915: Specify when the PLL hw state fields are valid
Not all those fields are valid on a given platform. Make it explicit.
Unions could also be used, but were cluttering some code paths with
if/else ladders.
v2: Don't use anonymous unions (Daniel)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ef38c3b..d604f4f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -197,10 +197,13 @@ enum intel_dpll_id {
#define I915_NUM_PLLS 2
struct intel_dpll_hw_state {
+ /* i9xx, pch plls */
uint32_t dpll;
uint32_t dpll_md;
uint32_t fp0;
uint32_t fp1;
+
+ /* hsw, bdw */
uint32_t wrpll;
};
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915: Split the BDW/HSW specific shared pll selection
We'll need a different algorithm to select the shared DPLL.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 4012a7b..98e2fd5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -708,23 +708,10 @@ intel_ddi_calculate_wrpll(int clock /* in Hz */,
*r2_out = best.r2;
}
-/*
- * Tries to find a *shared* PLL for the CRTC and store it in
- * intel_crtc-ddi_pll_sel.
- *
- * For private DPLLs, compute_config() should do the selection for us. This
- * function should be folded into compute_config() eventually.
- */
-bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
+static bool
+hsw_ddi_pll_select(struct intel_crtc *intel_crtc, int output, int clock)
{
- struct drm_crtc *crtc = intel_crtc-base;
- struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
- int type = intel_encoder-type;
- int clock = intel_crtc-config.port_clock;
-
- intel_put_shared_dpll(intel_crtc);
-
- if (type == INTEL_OUTPUT_HDMI) {
+ if (output == INTEL_OUTPUT_HDMI) {
struct intel_shared_dpll *pll;
uint32_t val;
unsigned p, n2, r2;
@@ -750,6 +737,26 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
return true;
}
+
+/*
+ * Tries to find a *shared* PLL for the CRTC and store it in
+ * intel_crtc-ddi_pll_sel.
+ *
+ * For private DPLLs, compute_config() should do the selection for us. This
+ * function should be folded into compute_config() eventually.
+ */
+bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
+{
+ struct drm_crtc *crtc = intel_crtc-base;
+ struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
+ int type = intel_encoder-type;
+ int clock = intel_crtc-config.port_clock;
+
+ intel_put_shared_dpll(intel_crtc);
+
+ return hsw_ddi_pll_select(intel_crtc, type, clock);
+}
+
void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = crtc-dev-dev_private;
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/10] Split the HSW/BDW PLL code a bit more
Turns out we were optimistic. intel_ prefixes don't tend to last and this is one of those times. -- Damien Damien Lespiau (10): drm/i915: Specify when the PLL hw state fields are valid drm/i915: Add a space to the shared DPLL debug message drm/i915: Extract the HSW DDI selection code into its own function drm/i915: Extract the HSW/BDW shared dpll init code drm/i915: Restrict hsw_dp_set_ddi_pll_sel() to HSW/BDW drm/i915: Fix stale comment for intel_ddi_pll_select() drm/i915: Split the BDW/HSW specific shared pll selection drm/i915: Make intel_ddi_calculate_wrpll() HSW/BDW specific drm/i915: Split the CDCLK retrieval per-platform drm/i915: Make ddi_clock_gate() HSW/BDW specific drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/intel_ddi.c | 124 +++ drivers/gpu/drm/i915/intel_display.c | 29 drivers/gpu/drm/i915/intel_dp.c | 2 +- 4 files changed, 105 insertions(+), 53 deletions(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] drm/i915: Add a space to the shared DPLL debug message
Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 1edfd1a..0147652 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1778,7 +1778,7 @@ static void intel_enable_shared_dpll(struct intel_crtc *crtc) if (WARN_ON(pll-refcount == 0)) return; - DRM_DEBUG_KMS(enable %s (active %d, on? %d)for crtc %d\n, + DRM_DEBUG_KMS(enable %s (active %d, on? %d) for crtc %d\n, pll-name, pll-active, pll-on, crtc-base.base.id); -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: Extract the HSW/BDW shared dpll init code
So we can easily provide an alternate implementation in the future.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1848906..55d7dad 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1248,10 +1248,8 @@ static const char * const hsw_ddi_pll_names[] = {
WRPLL 2,
};
-void intel_ddi_pll_init(struct drm_device *dev)
+static void hsw_shared_dplls_init(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = dev-dev_private;
- uint32_t val = I915_READ(LCPLL_CTL);
int i;
dev_priv-num_shared_dpll = 2;
@@ -1264,6 +1262,14 @@ void intel_ddi_pll_init(struct drm_device *dev)
dev_priv-shared_dplls[i].get_hw_state =
hsw_ddi_pll_get_hw_state;
}
+}
+
+void intel_ddi_pll_init(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t val = I915_READ(LCPLL_CTL);
+
+ hsw_shared_dplls_init(dev_priv);
/* The LCPLL register should be turned on by the BIOS. For now let's
* just check its state and print errors in case something is wrong.
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915: Extract the HSW DDI selection code into its own function
Future platform will slightly change that.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0147652..5678c68 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7573,6 +7573,22 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
return 0;
}
+static void haswell_get_ddi_pll(struct drm_i915_private *dev_priv,
+ enum port port,
+ struct intel_crtc_config *pipe_config)
+{
+ pipe_config-ddi_pll_sel = I915_READ(PORT_CLK_SEL(port));
+
+ switch (pipe_config-ddi_pll_sel) {
+ case PORT_CLK_SEL_WRPLL1:
+ pipe_config-shared_dpll = DPLL_ID_WRPLL1;
+ break;
+ case PORT_CLK_SEL_WRPLL2:
+ pipe_config-shared_dpll = DPLL_ID_WRPLL2;
+ break;
+ }
+}
+
static void haswell_get_ddi_port_state(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config)
{
@@ -7586,16 +7602,7 @@ static void haswell_get_ddi_port_state(struct intel_crtc
*crtc,
port = (tmp TRANS_DDI_PORT_MASK) TRANS_DDI_PORT_SHIFT;
- pipe_config-ddi_pll_sel = I915_READ(PORT_CLK_SEL(port));
-
- switch (pipe_config-ddi_pll_sel) {
- case PORT_CLK_SEL_WRPLL1:
- pipe_config-shared_dpll = DPLL_ID_WRPLL1;
- break;
- case PORT_CLK_SEL_WRPLL2:
- pipe_config-shared_dpll = DPLL_ID_WRPLL2;
- break;
- }
+ haswell_get_ddi_pll(dev_priv, port, pipe_config);
if (pipe_config-shared_dpll = 0) {
pll = dev_priv-shared_dplls[pipe_config-shared_dpll];
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] drm/i915: Restrict hsw_dp_set_ddi_pll_sel() to HSW/BDW
Future platform will use config-ddi_pll_sel in a different way. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index ea6ff71..bdbe8f7 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -976,7 +976,7 @@ found: pipe_config-dp_m2_n2); } - if (HAS_DDI(dev)) + if (IS_HASWELL(dev) || IS_BROADWELL(dev)) hsw_dp_set_ddi_pll_sel(pipe_config, intel_dp-link_bw); else intel_dp_set_clock(encoder, pipe_config, intel_dp-link_bw); -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] drm/i915: Fix stale comment for intel_ddi_pll_select()
Since the run-time PM on DPMS series, this function has an outdated
comment. Refresh it a bit.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 55d7dad..4012a7b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -709,10 +709,11 @@ intel_ddi_calculate_wrpll(int clock /* in Hz */,
}
/*
- * Tries to find a PLL for the CRTC. If it finds, it increases the refcount and
- * stores it in intel_crtc-ddi_pll_sel, so other mode sets won't be able to
- * steal the selected PLL. You need to call intel_ddi_pll_enable to actually
- * enable the PLL.
+ * Tries to find a *shared* PLL for the CRTC and store it in
+ * intel_crtc-ddi_pll_sel.
+ *
+ * For private DPLLs, compute_config() should do the selection for us. This
+ * function should be folded into compute_config() eventually.
*/
bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
{
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/10] drm/i915: Split the CDCLK retrieval per-platform
This is only going to get worse, so split it now to avoid adding more
cases to the if/else ladder.
Suggested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 55 +++-
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 69dc54c..2aad888 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1192,31 +1192,52 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder)
}
}
-int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
+static int bdw_get_cdclk_freq(struct drm_i915_private *dev_priv)
+{
+ uint32_t lcpll = I915_READ(LCPLL_CTL);
+ uint32_t freq = lcpll LCPLL_CLK_FREQ_MASK;
+
+ if (lcpll LCPLL_CD_SOURCE_FCLK)
+ return 80;
+ else if (I915_READ(FUSE_STRAP) HSW_CDCLK_LIMIT)
+ return 45;
+ else if (freq == LCPLL_CLK_FREQ_450)
+ return 45;
+ else if (freq == LCPLL_CLK_FREQ_54O_BDW)
+ return 54;
+ else if (freq == LCPLL_CLK_FREQ_337_5_BDW)
+ return 337500;
+ else
+ return 675000;
+}
+
+static int hsw_get_cdclk_freq(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = dev_priv-dev;
uint32_t lcpll = I915_READ(LCPLL_CTL);
uint32_t freq = lcpll LCPLL_CLK_FREQ_MASK;
- if (lcpll LCPLL_CD_SOURCE_FCLK) {
+ if (lcpll LCPLL_CD_SOURCE_FCLK)
return 80;
- } else if (I915_READ(FUSE_STRAP) HSW_CDCLK_LIMIT) {
+ else if (I915_READ(FUSE_STRAP) HSW_CDCLK_LIMIT)
return 45;
- } else if (freq == LCPLL_CLK_FREQ_450) {
+ else if (freq == LCPLL_CLK_FREQ_450)
return 45;
- } else if (IS_HASWELL(dev)) {
- if (IS_ULT(dev))
- return 337500;
- else
- return 54;
- } else {
- if (freq == LCPLL_CLK_FREQ_54O_BDW)
- return 54;
- else if (freq == LCPLL_CLK_FREQ_337_5_BDW)
- return 337500;
- else
- return 675000;
- }
+ else if (IS_ULT(dev))
+ return 337500;
+ else
+ return 54;
+}
+
+int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+
+ if (IS_BROADWELL(dev))
+ return bdw_get_cdclk_freq(dev_priv);
+
+ /* Haswell */
+ return hsw_get_cdclk_freq(dev_priv);
}
static void hsw_ddi_pll_enable(struct drm_i915_private *dev_priv,
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: Make ddi_clock_gate() HSW/BDW specific
Turns out we were again way too naive and optimistic, of course things
will change.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2aad888..a6024de 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -587,8 +587,8 @@ static int intel_ddi_calc_wrpll_link(struct
drm_i915_private *dev_priv,
return (refclk * n * 100) / (p * r);
}
-void intel_ddi_clock_get(struct intel_encoder *encoder,
-struct intel_crtc_config *pipe_config)
+static void hsw_ddi_clock_get(struct intel_encoder *encoder,
+ struct intel_crtc_config *pipe_config)
{
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
int link_clock = 0;
@@ -643,6 +643,12 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
pipe_config-adjusted_mode.crtc_clock = pipe_config-port_clock;
}
+void intel_ddi_clock_get(struct intel_encoder *encoder,
+struct intel_crtc_config *pipe_config)
+{
+ hsw_ddi_clock_get(encoder, pipe_config);
+}
+
static void
hsw_ddi_calculate_wrpll(int clock /* in Hz */,
unsigned *r2_out, unsigned *n2_out, unsigned *p_out)
@@ -1480,7 +1486,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
dev_priv-vbt.edp_bpp = pipe_config-pipe_bpp;
}
- intel_ddi_clock_get(encoder, pipe_config);
+ hsw_ddi_clock_get(encoder, pipe_config);
}
static void intel_ddi_destroy(struct drm_encoder *encoder)
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/10] drm/i915: Make intel_ddi_calculate_wrpll() HSW/BDW specific
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 98e2fd5..69dc54c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -644,8 +644,8 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
}
static void
-intel_ddi_calculate_wrpll(int clock /* in Hz */,
- unsigned *r2_out, unsigned *n2_out, unsigned *p_out)
+hsw_ddi_calculate_wrpll(int clock /* in Hz */,
+ unsigned *r2_out, unsigned *n2_out, unsigned *p_out)
{
uint64_t freq2k;
unsigned p, n2, r2;
@@ -709,14 +709,16 @@ intel_ddi_calculate_wrpll(int clock /* in Hz */,
}
static bool
-hsw_ddi_pll_select(struct intel_crtc *intel_crtc, int output, int clock)
+hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
+ struct intel_encoder *intel_encoder,
+ int clock)
{
- if (output == INTEL_OUTPUT_HDMI) {
+ if (intel_encoder-type == INTEL_OUTPUT_HDMI) {
struct intel_shared_dpll *pll;
uint32_t val;
unsigned p, n2, r2;
- intel_ddi_calculate_wrpll(clock * 1000, r2, n2, p);
+ hsw_ddi_calculate_wrpll(clock * 1000, r2, n2, p);
val = WRPLL_PLL_ENABLE | WRPLL_PLL_LCPLL |
WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
@@ -749,12 +751,11 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
{
struct drm_crtc *crtc = intel_crtc-base;
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
- int type = intel_encoder-type;
int clock = intel_crtc-config.port_clock;
intel_put_shared_dpll(intel_crtc);
- return hsw_ddi_pll_select(intel_crtc, type, clock);
+ return hsw_ddi_pll_select(intel_crtc, intel_encoder, clock);
}
void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load thaw
drv_suspend, gem_hangcheck_forcewake are working fine now with PPGTT enabled. Both with and without my patch. The results are the same with and without my patch for: $ sudo ~/drm_nightly/intel-gpu-tools/tests/drv_hangman IGT-Version: 1.7-g70e6ed9 (x86_64) (Linux: 3.16.0-rc5+ x86_64) Subtest error-state-debugfs-entry: SUCCESS Subtest error-state-sysfs-entry: SUCCESS Subtest ring-stop-sysfs-entry: SUCCESS Subtest error-state-basic: SUCCESS Subtest error-state-capture-render: SUCCESS Test assertion failure function check_error_state, file drv_hangman.c:303: Failed assertion: gtt_offset == expected_offset Subtest error-state-capture-bsd: FAIL Test assertion failure function check_error_state, file drv_hangman.c:303: Failed assertion: gtt_offset == expected_offset Subtest error-state-capture-blt: FAIL Test assertion failure function check_error_state, file drv_hangman.c:303: Failed assertion: gtt_offset == expected_offset Subtest error-state-capture-vebox: FAIL $ sudo ~/drm_nightly/intel-gpu-tools/tests/gem_reset_stats IGT-Version: 1.7-g70e6ed9 (x86_64) (Linux: 3.16.0-rc5+ x86_64) Subtest params: SUCCESS Subtest params-ctx-render: SUCCESS Subtest reset-stats-render: SUCCESS Subtest reset-stats-ctx-render: SUCCESS Subtest ban-render: SUCCESS Subtest ban-ctx-render: SUCCESS Subtest reset-count-render: SUCCESS Subtest reset-count-ctx-render: SUCCESS Subtest unrelated-ctx-render: SUCCESS Subtest close-pending-render: SUCCESS Subtest close-pending-ctx-render: SUCCESS test now hangs Both good without PPGTT. I haven't yet seen a regression with the patch. -Original Message- From: Ben Widawsky [mailto:b...@bwidawsk.net] Sent: Tuesday, July 29, 2014 1:17 AM To: Mcaulay, Alistair Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load thaw On Mon, Jul 28, 2014 at 05:12:59PM +, Mcaulay, Alistair wrote: Hi Ben / Daniel, I agree that this needs to be properly tested. Are there any particular igt tests you would suggest I use? I've been running: drv_hangman, drv_suspend, gem_hangcheck_forcewake. I thought IGT had added some random reset stuff in the way that we have for signals. However, it looks like I imagined it. I guess you can add gem_hang, gem_reset_stats, and tests/debugfs_wedged to that list. Daniel can probably provide any I might have missed. The way that igt quiesces everything these days really hurts the ability to test multi-process. If every tests starts off with no work, and running the default context, things are pretty trivial. Similarly, running these tests in isolation, even if it isn't quiescing doesn't help the situation. The way I wrote the code originally was through debugging hangs on a desktop as I developed patches, and not with IGT (though drv_hangman could catch many issues). I'd definitely recommend trying to invoke hangs on a running desktop. I'd advise doing this by modifying mesa to submit a crap batch, I can provide you more details on how to do this if you need it. Also try to disable the quiescing in IGT and run more than these tests in isolation. Also do you have a set of PPGTT Patches that should work with these tests. Michel sent me a set of patches to enable PPGTT, but these 3 tests fail with the patches. I will try to reproduce this on my patch series when I have some time and if nothing else, that should be a good preparation/refresher for the patch review anyway. The patches I wrote shouldn't have touched much on these paths - not sure if Michel changed anything there. With patch on top of what Michel sent you, everything passes? Thanks, Alistair. -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, July 28, 2014 10:27 AM To: Ben Widawsky Cc: Mcaulay, Alistair; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: Rework GPU reset sequence to match driver load thaw On Fri, Jul 25, 2014 at 06:05:29PM -0700, Ben Widawsky wrote: On Wed, Jul 16, 2014 at 04:05:59PM +0100, alistair.mcau...@intel.com wrote: From: McAulay, Alistair alistair.mcau...@intel.com This patch is to address Daniels concerns over different code during reset: http://lists.freedesktop.org/archives/intel-gfx/2014-June/047758.h tm l The reason for aiming as hard as possible to use the exact same code for driver load, gpu reset and runtime pm/system resume is that we've simply seen too many bugs due to slight variations and unintended omissions. Tested using igt drv_hangman. Signed-off-by: McAulay, Alistair alistair.mcau...@intel.com 2 quick comments before I actually do a real review. 1. Did you actually run this with and without full ppgtt? 2. I don't think this is actually fulfilling what Daniel is requesting, though we can let him comment. Mostly looks like what I think we need. Comments
Re: [Intel-gfx] [PATCH 10/9] drm: Add dev-vblank_disable_immediate flag
On Thu, Jun 19, 2014 at 05:41:24PM -0700, Matt Roper wrote:
On Mon, May 26, 2014 at 05:26:47PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a flag to drm_device which will cause the vblank code to bypass the
disable timer and always disable the vblank interrupt immediately when
the last reference is dropped.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 6 +++---
include/drm/drmP.h| 10 ++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 20a4855..b008803 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -994,11 +994,11 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
/* Last user schedules interrupt disable */
if (atomic_dec_and_test(vblank-refcount)) {
- if (drm_vblank_offdelay 0)
+ if (dev-vblank_disable_immediate || drm_vblank_offdelay == 0)
+ vblank_disable_fn((unsigned long)vblank);
+ else if (drm_vblank_offdelay 0)
mod_timer(vblank-disable_timer,
jiffies + ((drm_vblank_offdelay * HZ)/1000));
- else if (drm_vblank_offdelay == 0)
- vblank_disable_fn((unsigned long)vblank);
}
}
EXPORT_SYMBOL(drm_vblank_put);
Would it be better if we just squashed this device flag logic back into
patch 7, but kept the drm_vblank_offdelay == 0 meaning of never
disable? I can see there being people who might already use this when
debugging new and potentially flaky hardware platforms who would be
surprised by the change in behavior. So basically something like:
if (drm_vblank_offdelay == 0)
return
else if (dev-vblank_disable_immediate)
vblank_disable_fn((unsigned long)vblank);
else
mod_timer(...);
I'm not sure I want drm_vblank_offdelay affecting drivers that have
vblank_disable_immediate set since it's a global variable. If there
are two devices on the system where one has
vblank_disable_immediate==true and the other doesn't, the user
might want to keep vblank interrupts enabled on the crappy device
all time by frobbing drm_vblank_offdelay.
I agree that changing the meaning of drm_vblank_offdelay=0 is a bit
questionable, but reversing the meaning so that '==0' meas 'never disable'
and '0' means 'disable immediately' seemed a bit weird for my taste. But
I suppose I could make that change if people think it's better. Or maybe
just forget about the 'disable immediately' behaviour when
vblank_disable_immediate==false?
I'd also suggest adding a comment in drm_stub.c to indicate that
drm_vblank_offdelay gets ignored for drivers that set
vblank_disable_immediate.
Good idea.
Other than that, patches 1-8, 10, and 11 are
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
I'll finish up reviewing #9 and 12-14 tomorrow when I have some more
time.
Matt
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 979a498..0944544 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1117,6 +1117,16 @@ struct drm_device {
*/
bool vblank_disable_allowed;
+ /*
+* If true, vblank interrupt will be disabled immediately when the
+* refcount drops to zero, as opposed to via the vblank disable
+* timer.
+* This can be set to true it the hardware has a working vblank
+* counter and the driver uses drm_vblank_on() and drm_vblank_off()
+* appropriately.
+*/
+ bool vblank_disable_immediate;
+
/* array of size num_crtcs */
struct drm_vblank_crtc *vblank;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling Development
Intel Corporation
(916) 356-2795
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/9] drm: Add dev-vblank_disable_immediate flag
On Tue, Jul 29, 2014 at 08:31:55PM +0300, Ville Syrjälä wrote:
On Thu, Jun 19, 2014 at 05:41:24PM -0700, Matt Roper wrote:
On Mon, May 26, 2014 at 05:26:47PM +0300, ville.syrj...@linux.intel.com
wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a flag to drm_device which will cause the vblank code to bypass the
disable timer and always disable the vblank interrupt immediately when
the last reference is dropped.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 6 +++---
include/drm/drmP.h| 10 ++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 20a4855..b008803 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -994,11 +994,11 @@ void drm_vblank_put(struct drm_device *dev, int
crtc)
/* Last user schedules interrupt disable */
if (atomic_dec_and_test(vblank-refcount)) {
- if (drm_vblank_offdelay 0)
+ if (dev-vblank_disable_immediate || drm_vblank_offdelay == 0)
+ vblank_disable_fn((unsigned long)vblank);
+ else if (drm_vblank_offdelay 0)
mod_timer(vblank-disable_timer,
jiffies + ((drm_vblank_offdelay * HZ)/1000));
- else if (drm_vblank_offdelay == 0)
- vblank_disable_fn((unsigned long)vblank);
}
}
EXPORT_SYMBOL(drm_vblank_put);
Would it be better if we just squashed this device flag logic back into
patch 7, but kept the drm_vblank_offdelay == 0 meaning of never
disable? I can see there being people who might already use this when
debugging new and potentially flaky hardware platforms who would be
surprised by the change in behavior. So basically something like:
if (drm_vblank_offdelay == 0)
return
else if (dev-vblank_disable_immediate)
vblank_disable_fn((unsigned long)vblank);
else
mod_timer(...);
I'm not sure I want drm_vblank_offdelay affecting drivers that have
vblank_disable_immediate set since it's a global variable. If there
are two devices on the system where one has
vblank_disable_immediate==true and the other doesn't, the user
might want to keep vblank interrupts enabled on the crappy device
all time by frobbing drm_vblank_offdelay.
I agree that changing the meaning of drm_vblank_offdelay=0 is a bit
questionable, but reversing the meaning so that '==0' meas 'never disable'
and '0' means 'disable immediately' seemed a bit weird for my taste. But
I suppose I could make that change if people think it's better. Or maybe
just forget about the 'disable immediately' behaviour when
vblank_disable_immediate==false?
I'd also suggest adding a comment in drm_stub.c to indicate that
drm_vblank_offdelay gets ignored for drivers that set
vblank_disable_immediate.
Good idea.
Yeah, I think that's good enough. There really shouldn't be any need for
drivers which support immediate vblank disabling to ever keep it on for a
while. Presuming the immediate disable actually works ofc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 06/40] drm/i915: Add cdclk change support for chv
On Tue, Jul 29, 2014 at 09:51:03AM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:03:57 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Looks like the Punit is supposed to support the 400MHz cdclk directly on
chv, so we don't need the vlv tricks.
FIXME: Punit doesn't seem ready for this yet on current hw
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++
drivers/gpu/drm/i915/intel_display.c | 50
++--
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index f156591..e296312 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -491,6 +491,10 @@
#define BUNIT_REG_BISOC0x11
#define PUNIT_REG_DSPFREQ 0x36
+#define DSPFREQSTAT_SHIFT_CHV24
+#define DSPFREQSTAT_MASK_CHV (0x1f
DSPFREQSTAT_SHIFT_CHV)
+#define DSPFREQGUAR_SHIFT_CHV8
+#define DSPFREQGUAR_MASK_CHV (0x1f
DSPFREQGUAR_SHIFT_CHV)
#define DSPFREQSTAT_SHIFT30
#define DSPFREQSTAT_MASK (0x3 DSPFREQSTAT_SHIFT)
#define DSPFREQGUAR_SHIFT14
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 99c10d1..9af1d13 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4529,6 +4529,47 @@ static void valleyview_set_cdclk(struct drm_device
*dev, int cdclk)
vlv_update_cdclk(dev);
}
+static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 val, cmd;
+
+ WARN_ON(dev_priv-display.get_display_clock_speed(dev) !=
dev_priv-vlv_cdclk_freq);
+
+ switch (cdclk) {
+ case 40:
+ cmd = 3;
+ break;
+ case 33:
+ case 32:
+ cmd = 2;
+ break;
+ case 27:
+ cmd = 1;
+ break;
+ case 20:
+ cmd = 0;
+ break;
+ default:
+ WARN_ON(1);
+ return;
+ }
+
+ mutex_lock(dev_priv-rps.hw_lock);
+ val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
+ val = ~DSPFREQGUAR_MASK_CHV;
+ val |= (cmd DSPFREQGUAR_SHIFT_CHV);
+ vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
+ if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ)
+ DSPFREQSTAT_MASK_CHV) == (cmd DSPFREQSTAT_SHIFT_CHV),
+50)) {
+ DRM_ERROR(timed out waiting for CDclk change\n);
+ }
+ mutex_unlock(dev_priv-rps.hw_lock);
+
+ vlv_update_cdclk(dev);
+}
+
static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
int max_pixclk)
{
@@ -4597,8 +4638,13 @@ static void
valleyview_modeset_global_resources(struct drm_device *dev)
int max_pixclk = intel_mode_max_pixclk(dev_priv);
int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
- if (req_cdclk != dev_priv-vlv_cdclk_freq)
- valleyview_set_cdclk(dev, req_cdclk);
+ if (req_cdclk != dev_priv-vlv_cdclk_freq) {
+ if (IS_CHERRYVIEW(dev))
+ cherryview_set_cdclk(dev, req_cdclk);
+ else
+ valleyview_set_cdclk(dev, req_cdclk);
+ }
+
modeset_update_crtc_power_domains(dev);
}
Which doc has these Punit commands? I'm assuming you have them
correct, but a ref would be good if we don't already have one.
Yeah I think I'll hold off on this until the doc has diffused better. For
byt this was too much fun with jumping backforth a few times ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 29/40] drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
On Tue, Jul 29, 2014 at 09:59:53AM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:04:20 +0300
ville.syrj...@linux.intel.com wrote:
From: Kenneth Graunke kenn...@whitecape.org
We'll want to reuse this for a workaround.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 36
-
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2faef26..97796b1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -381,6 +381,27 @@ gen7_render_ring_flush(struct intel_engine_cs *ring,
}
static int
+gen8_emit_pipe_control(struct intel_engine_cs *ring,
+ u32 flags, u32 scratch_addr)
+{
+ int ret;
+
+ ret = intel_ring_begin(ring, 6);
+ if (ret)
+ return ret;
+
+ intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
+ intel_ring_emit(ring, flags);
+ intel_ring_emit(ring, scratch_addr);
+ intel_ring_emit(ring, 0);
+ intel_ring_emit(ring, 0);
+ intel_ring_emit(ring, 0);
+ intel_ring_advance(ring);
+
+ return 0;
+}
+
+static int
gen8_render_ring_flush(struct intel_engine_cs *ring,
u32 invalidate_domains, u32 flush_domains)
{
@@ -405,20 +426,7 @@ gen8_render_ring_flush(struct intel_engine_cs *ring,
flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
}
- ret = intel_ring_begin(ring, 6);
- if (ret)
- return ret;
-
- intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(6));
- intel_ring_emit(ring, flags);
- intel_ring_emit(ring, scratch_addr);
- intel_ring_emit(ring, 0);
- intel_ring_emit(ring, 0);
- intel_ring_emit(ring, 0);
- intel_ring_advance(ring);
-
- return 0;
-
+ return gen8_emit_pipe_control(ring, flags, scratch_addr);
}
static void ring_write_tail(struct intel_engine_cs *ring,
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Aside: checkpatch complains about this since it makes it harder to grep
for dmesg noise. But I guess if 3 people here like it I should merge it
;-)
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 34/40] drm/i915: Add DP training pattern 3 for CHV
On Tue, Jul 29, 2014 at 10:01:57AM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:04:25 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV supports DP training pattern 3. Add the required stuff.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 18 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 85b59c4..8debe61 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3515,6 +3515,8 @@ enum punit_power_well {
#define DP_LINK_TRAIN_OFF(3 28)
#define DP_LINK_TRAIN_MASK (3 28)
#define DP_LINK_TRAIN_SHIFT 28
+#define DP_LINK_TRAIN_PAT_3_CHV (1 14)
+#define DP_LINK_TRAIN_MASK_CHV ((3 28)|(114))
/* CPT Link training mode */
#define DP_LINK_TRAIN_PAT_1_CPT (0 8)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 739dc43..a825ff1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2900,7 +2900,10 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
}
} else {
- *DP = ~DP_LINK_TRAIN_MASK;
+ if (IS_CHERRYVIEW(dev))
+ *DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ *DP = ~DP_LINK_TRAIN_MASK;
switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
case DP_TRAINING_PATTERN_DISABLE:
@@ -2913,8 +2916,12 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
*DP |= DP_LINK_TRAIN_PAT_2;
break;
case DP_TRAINING_PATTERN_3:
- DRM_ERROR(DP training pattern 3 not supported\n);
- *DP |= DP_LINK_TRAIN_PAT_2;
+ if (IS_CHERRYVIEW(dev)) {
+ *DP |= DP_LINK_TRAIN_PAT_3_CHV;
+ } else {
+ DRM_ERROR(DP training pattern 3 not
supported\n);
+ *DP |= DP_LINK_TRAIN_PAT_2;
+ }
break;
}
}
@@ -3201,7 +3208,10 @@ intel_dp_link_down(struct intel_dp *intel_dp)
DP = ~DP_LINK_TRAIN_MASK_CPT;
I915_WRITE(intel_dp-output_reg, DP |
DP_LINK_TRAIN_PAT_IDLE_CPT);
} else {
- DP = ~DP_LINK_TRAIN_MASK;
+ if (IS_CHERRYVIEW(dev))
+ DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ DP = ~DP_LINK_TRAIN_MASK;
I915_WRITE(intel_dp-output_reg, DP | DP_LINK_TRAIN_PAT_IDLE);
}
POSTING_READ(intel_dp-output_reg);
I guess we could have a whole IS_CHV block, but that would probably add
more code than it saved...
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
This won't do a hole lot without adding HBR2 support ... Queued for
-next anyway, thanks for the patch.
-Daniel
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 06/40] drm/i915: Add cdclk change support for chv
On Tue, 29 Jul 2014 19:59:26 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jul 29, 2014 at 09:51:03AM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:03:57 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Looks like the Punit is supposed to support the 400MHz cdclk directly on
chv, so we don't need the vlv tricks.
FIXME: Punit doesn't seem ready for this yet on current hw
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++
drivers/gpu/drm/i915/intel_display.c | 50
++--
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index f156591..e296312 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -491,6 +491,10 @@
#define BUNIT_REG_BISOC 0x11
#define PUNIT_REG_DSPFREQ0x36
+#define DSPFREQSTAT_SHIFT_CHV 24
+#define DSPFREQSTAT_MASK_CHV (0x1f
DSPFREQSTAT_SHIFT_CHV)
+#define DSPFREQGUAR_SHIFT_CHV 8
+#define DSPFREQGUAR_MASK_CHV (0x1f
DSPFREQGUAR_SHIFT_CHV)
#define DSPFREQSTAT_SHIFT 30
#define DSPFREQSTAT_MASK (0x3
DSPFREQSTAT_SHIFT)
#define DSPFREQGUAR_SHIFT 14
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 99c10d1..9af1d13 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4529,6 +4529,47 @@ static void valleyview_set_cdclk(struct drm_device
*dev, int cdclk)
vlv_update_cdclk(dev);
}
+static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 val, cmd;
+
+ WARN_ON(dev_priv-display.get_display_clock_speed(dev) !=
dev_priv-vlv_cdclk_freq);
+
+ switch (cdclk) {
+ case 40:
+ cmd = 3;
+ break;
+ case 33:
+ case 32:
+ cmd = 2;
+ break;
+ case 27:
+ cmd = 1;
+ break;
+ case 20:
+ cmd = 0;
+ break;
+ default:
+ WARN_ON(1);
+ return;
+ }
+
+ mutex_lock(dev_priv-rps.hw_lock);
+ val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
+ val = ~DSPFREQGUAR_MASK_CHV;
+ val |= (cmd DSPFREQGUAR_SHIFT_CHV);
+ vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
+ if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ)
+ DSPFREQSTAT_MASK_CHV) == (cmd DSPFREQSTAT_SHIFT_CHV),
+ 50)) {
+ DRM_ERROR(timed out waiting for CDclk change\n);
+ }
+ mutex_unlock(dev_priv-rps.hw_lock);
+
+ vlv_update_cdclk(dev);
+}
+
static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
int max_pixclk)
{
@@ -4597,8 +4638,13 @@ static void
valleyview_modeset_global_resources(struct drm_device *dev)
int max_pixclk = intel_mode_max_pixclk(dev_priv);
int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
- if (req_cdclk != dev_priv-vlv_cdclk_freq)
- valleyview_set_cdclk(dev, req_cdclk);
+ if (req_cdclk != dev_priv-vlv_cdclk_freq) {
+ if (IS_CHERRYVIEW(dev))
+ cherryview_set_cdclk(dev, req_cdclk);
+ else
+ valleyview_set_cdclk(dev, req_cdclk);
+ }
+
modeset_update_crtc_power_domains(dev);
}
Which doc has these Punit commands? I'm assuming you have them
correct, but a ref would be good if we don't already have one.
Yeah I think I'll hold off on this until the doc has diffused better. For
byt this was too much fun with jumping backforth a few times ...
Well, the next patch disables this until we can test anyway, so it
should be fine to add and fixup/add the doc link later.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: freeze display before the interrupts and GT
On Thu, 17 Jul 2014 17:43:46 -0300
Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Since we started using intel_runtime_pm_disable_interrupts() at normal
(non-runtime) suspend/resume, we had to remove a WARN from
ironlake_disable_display_irq to avoid a case where we were doing the
correct thing and the WARN was not really needed. The problem is that
the WARN was useful in other cases, and its removal can hide some bugs
that we would catch automatically.
To be able to add back the WARN, we have to call intel_crtc_control()
before interrupts are disabled, which is what this patch currently
does.
Also notice that Ville's patch from the Watermarks series drm/i915:
Leave interrupts enabled while disabling crtcs during suspend also
did a change that's equivalent to the one we're doing on this patch,
with the exception that its original patch, when applied to the
current tree, procduces a WARN.
Related commits:
commit daa390e5ee45cc051d6bf37b296901f2f92b002d
Author: Jesse Barnes jbar...@virtuousgeek.org
drm/i915: don't warn if IRQs are disabled when shutting down display IRQs
commit e11aa362308f5de467ce355a2a2471321b15a35c
Author: Jesse Barnes jbar...@virtuousgeek.org
drm/i915: use runtime irq suspend/resume in freeze/thaw
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 11 +--
drivers/gpu/drm/i915/i915_irq.c | 2 +-
2 files changed, 6 insertions(+), 7 deletions(-)
No need to revert anything :)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3315358..63675bf 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -520,12 +520,6 @@ static int i915_drm_freeze(struct drm_device *dev)
return error;
}
- flush_delayed_work(dev_priv-rps.delayed_resume_work);
-
- intel_runtime_pm_disable_interrupts(dev);
-
- intel_suspend_gt_powersave(dev);
-
/*
* Disable CRTCs directly since we want to preserve sw state
* for _thaw. Also, power gate the CRTC power wells.
@@ -535,6 +529,11 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_crtc_control(crtc, false);
drm_modeset_unlock_all(dev);
+ flush_delayed_work(dev_priv-rps.delayed_resume_work);
+ intel_runtime_pm_disable_interrupts(dev);
+
+ intel_suspend_gt_powersave(dev);
+
intel_modeset_suspend_hw(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 20c777c..af231ba 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -151,7 +151,7 @@ ironlake_disable_display_irq(struct drm_i915_private
*dev_priv, u32 mask)
{
assert_spin_locked(dev_priv-irq_lock);
- if (!intel_irqs_enabled(dev_priv))
+ if (WARN_ON(!intel_irqs_enabled(dev_priv)))
return;
if ((dev_priv-irq_mask mask) != mask) {
So with this added, we get the WARN back but don't need/want to revert
any other patches?
Did you check boot, suspend/resume, and runtime PM for warnings with
this change applied? If so, looks fine:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/gem_ringfill: add interruptible mode
Should be useful to test intel_ring_begin restart behaviour a bit.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/gem_ringfill.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/tests/gem_ringfill.c b/tests/gem_ringfill.c
index 5700a74d260b..750537a9bbab 100644
--- a/tests/gem_ringfill.c
+++ b/tests/gem_ringfill.c
@@ -226,6 +226,23 @@ igt_main
check_ring(bufmgr, batch, render, copy);
}
+ igt_fork_signal_helper();
+ igt_subtest(blitter-interruptible)
+ check_ring(bufmgr, batch, blt, blt_copy);
+
+ /* Strictly only required on architectures with a separate BLT ring,
+* but lets stress everybody.
+*/
+ igt_subtest(render-interruptible) {
+ igt_render_copyfunc_t copy;
+
+ copy = igt_get_render_copyfunc(batch-devid);
+ igt_require(copy);
+
+ check_ring(bufmgr, batch, render, copy);
+ }
+ igt_stop_signal_helper();
+
igt_fixture {
intel_batchbuffer_free(batch);
drm_intel_bufmgr_destroy(bufmgr);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Restrict hsw_dp_set_ddi_pll_sel() to HSW/BDW
On Tue, Jul 29, 2014 at 06:06:20PM +0100, Damien Lespiau wrote: Future platform will use config-ddi_pll_sel in a different way. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index ea6ff71..bdbe8f7 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -976,7 +976,7 @@ found: pipe_config-dp_m2_n2); } - if (HAS_DDI(dev)) + if (IS_HASWELL(dev) || IS_BROADWELL(dev)) hsw_dp_set_ddi_pll_sel(pipe_config, intel_dp-link_bw); else intel_dp_set_clock(encoder, pipe_config, intel_dp-link_bw); We could do an s/intel/gmch/ here too ... Or g4x. -Daniel -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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 37/40] drm/i915: Fix eDP link training when switching pipes
On Mon, Jun 30, 2014 at 02:52:12PM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:04:28 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When switching from one pipe to another, the power sequencer of the new
pipe seems to need a bit of kicking to lock into the port. Even the vdd
force bit doesn't work before the power sequencer has been sufficiently
kicked, so this must be done even before any AUX transactions.
This sequence has been found to do the trick:
1) enable port with idle pattern
2) enable the power sequencer
3) proceed with link training
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 65ab54c..07b0320 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2010,6 +2010,37 @@ static void chv_post_disable_dp(struct intel_encoder
*encoder)
mutex_unlock(dev_priv-dpio_lock);
}
+static void intel_edp_init_train(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!is_edp(intel_dp))
+ return;
This changes the order of events as observed by the sink, so I really
wonder why this is edp specific?
We do have bug reports about external DP monitors not waking up from the
sink_dpms call properly ...
-Daniel
+
+ /*
+* Need to enable the port with idle pattern to allow the power
+* sequencer to lock into the port. Otherwise the power sequencer
+* (including vdd force bit!) doesn't work on this port.
+*/
+ if (IS_VALLEYVIEW(dev)) {
+ intel_dp-DP |= DP_PORT_EN;
+
+ if (IS_CHERRYVIEW(dev))
+ intel_dp-DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ intel_dp-DP = ~DP_LINK_TRAIN_MASK;
+ intel_dp-DP |= DP_LINK_TRAIN_PAT_IDLE;
+
+ I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+ POSTING_READ(intel_dp-output_reg);
+ }
+
+ intel_edp_panel_on(intel_dp);
+ edp_panel_vdd_off(intel_dp, true);
+}
+
static void intel_enable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
@@ -2021,10 +2052,9 @@ static void intel_enable_dp(struct intel_encoder
*encoder)
return;
intel_edp_panel_vdd_on(intel_dp);
+ intel_edp_init_train(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
- intel_edp_panel_on(intel_dp);
- edp_panel_vdd_off(intel_dp, true);
intel_dp_complete_link_train(intel_dp);
intel_dp_stop_link_train(intel_dp);
}
Yeah I think this matches the doc too. I never pushed this change
because I could never find anything that it actually fixed.
I guess you have something now though!
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 00/10] Split the HSW/BDW PLL code a bit more
On Tue, Jul 29, 2014 at 06:06:15PM +0100, Damien Lespiau wrote: Turns out we were optimistic. intel_ prefixes don't tend to last and this is one of those times. Pulled in the entire series to dinq, thanks. -Daniel -- Damien Damien Lespiau (10): drm/i915: Specify when the PLL hw state fields are valid drm/i915: Add a space to the shared DPLL debug message drm/i915: Extract the HSW DDI selection code into its own function drm/i915: Extract the HSW/BDW shared dpll init code drm/i915: Restrict hsw_dp_set_ddi_pll_sel() to HSW/BDW drm/i915: Fix stale comment for intel_ddi_pll_select() drm/i915: Split the BDW/HSW specific shared pll selection drm/i915: Make intel_ddi_calculate_wrpll() HSW/BDW specific drm/i915: Split the CDCLK retrieval per-platform drm/i915: Make ddi_clock_gate() HSW/BDW specific drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/intel_ddi.c | 124 +++ drivers/gpu/drm/i915/intel_display.c | 29 drivers/gpu/drm/i915/intel_dp.c | 2 +- 4 files changed, 105 insertions(+), 53 deletions(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
VMAs should take a reference of the address space they use.
Now, when the fd is closed, it will release the ref that the context was
holding, but it will still be referenced by any vmas that are still
active.
ppgtt_release() should then only be called when the last thing referencing
it releases the ref, and it can just call the base cleanup and free the
ppgtt.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 8
drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2acc03f..a879a93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
/* i915_gem_context.c */
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
+#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
+void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dcd8d7b..25a32b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
drm_i915_gem_object *obj,
void i915_gem_vma_destroy(struct i915_vma *vma)
{
+ struct i915_address_space *vm = NULL;
+ struct i915_hw_ppgtt *ppgtt = NULL;
WARN_ON(vma-node.allocated);
/* Keep the vma as a placeholder in the execbuffer reservation lists */
if (!list_empty(vma-exec_list))
return;
+ vm = vma-vm;
+ ppgtt = vm_to_ppgtt(vm);
+
+ if (ppgtt)
+ kref_put(ppgtt-ref, ppgtt_release);
+
list_del(vma-vma_link);
kfree(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5b5af6c..59272f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt
*ppgtt)
return;
}
- /*
- * Make sure vmas are unbound before we take down the drm_mm
- *
- * FIXME: Proper refcounting should take care of this, this shouldn't be
- * needed at all.
- */
- if (!list_empty(vm-active_list)) {
- struct i915_vma *vma;
-
- list_for_each_entry(vma, vm-active_list, mm_list)
- if (WARN_ON(list_empty(vma-vma_link) ||
- list_is_singular(vma-vma_link)))
- break;
-
- i915_gem_evict_vm(ppgtt-base, true);
- } else {
- i915_gem_retire_requests(dev);
- i915_gem_evict_vm(ppgtt-base, false);
- }
+ /* vmas should already be unbound */
+ WARN_ON(!list_empty(vm-active_list));
ppgtt-base.cleanup(ppgtt-base);
}
-static void ppgtt_release(struct kref *kref)
+void ppgtt_release(struct kref *kref)
{
struct i915_hw_ppgtt *ppgtt =
container_of(kref, struct i915_hw_ppgtt, ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1411613..90c3d0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct
drm_i915_gem_object *obj,
struct i915_address_space *vm)
{
struct i915_vma *vma;
+ struct i915_hw_ppgtt *ppgtt = NULL;
vma = i915_gem_obj_to_vma(obj, vm);
if (!vma)
vma = __i915_gem_vma_create(obj, vm);
+ ppgtt = vm_to_ppgtt(vm);
+ if (ppgtt)
+ kref_get(ppgtt-ref);
+
return vma;
}
Seems like a reasonable fix to me, and it's simpler than Chris' request
to ref when active. Logically his makes more sense, but it's not quite
as simple to review. Actually active isn't the right thing to track IMO,
bound is what you want to track. I think if anything, do that one as a
patch on top, it does address the problem mentioned below. I also wonder
given the recent reset lolz how this behaves there; and I'd make sure to
thoroughly test the various reset/hang conditions.
Also, this puts a hard limit on the maximum number of VMAs in an address
space based on sizeof(atomic_t). (unless you do what I said above)
Re: [Intel-gfx] [PATCH 34/40] drm/i915: Add DP training pattern 3 for CHV
On Tue, Jul 29, 2014 at 08:04:59PM +0200, Daniel Vetter wrote:
On Tue, Jul 29, 2014 at 10:01:57AM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:04:25 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV supports DP training pattern 3. Add the required stuff.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 18 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 85b59c4..8debe61 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3515,6 +3515,8 @@ enum punit_power_well {
#define DP_LINK_TRAIN_OFF (3 28)
#define DP_LINK_TRAIN_MASK (3 28)
#define DP_LINK_TRAIN_SHIFT28
+#define DP_LINK_TRAIN_PAT_3_CHV(1 14)
+#define DP_LINK_TRAIN_MASK_CHV ((3 28)|(114))
/* CPT Link training mode */
#define DP_LINK_TRAIN_PAT_1_CPT(0 8)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 739dc43..a825ff1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2900,7 +2900,10 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
}
} else {
- *DP = ~DP_LINK_TRAIN_MASK;
+ if (IS_CHERRYVIEW(dev))
+ *DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ *DP = ~DP_LINK_TRAIN_MASK;
switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
case DP_TRAINING_PATTERN_DISABLE:
@@ -2913,8 +2916,12 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
*DP |= DP_LINK_TRAIN_PAT_2;
break;
case DP_TRAINING_PATTERN_3:
- DRM_ERROR(DP training pattern 3 not supported\n);
- *DP |= DP_LINK_TRAIN_PAT_2;
+ if (IS_CHERRYVIEW(dev)) {
+ *DP |= DP_LINK_TRAIN_PAT_3_CHV;
+ } else {
+ DRM_ERROR(DP training pattern 3 not
supported\n);
+ *DP |= DP_LINK_TRAIN_PAT_2;
+ }
break;
}
}
@@ -3201,7 +3208,10 @@ intel_dp_link_down(struct intel_dp *intel_dp)
DP = ~DP_LINK_TRAIN_MASK_CPT;
I915_WRITE(intel_dp-output_reg, DP |
DP_LINK_TRAIN_PAT_IDLE_CPT);
} else {
- DP = ~DP_LINK_TRAIN_MASK;
+ if (IS_CHERRYVIEW(dev))
+ DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ DP = ~DP_LINK_TRAIN_MASK;
I915_WRITE(intel_dp-output_reg, DP | DP_LINK_TRAIN_PAT_IDLE);
}
POSTING_READ(intel_dp-output_reg);
I guess we could have a whole IS_CHV block, but that would probably add
more code than it saved...
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
This won't do a hole lot without adding HBR2 support ... Queued for
-next anyway, thanks for the patch.
What else is missing for HBR2?
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/40] drm/i915: Add cdclk change support for chv
On Tue, Jul 29, 2014 at 09:51:03AM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:03:57 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Looks like the Punit is supposed to support the 400MHz cdclk directly on
chv, so we don't need the vlv tricks.
FIXME: Punit doesn't seem ready for this yet on current hw
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++
drivers/gpu/drm/i915/intel_display.c | 50
++--
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index f156591..e296312 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -491,6 +491,10 @@
#define BUNIT_REG_BISOC0x11
#define PUNIT_REG_DSPFREQ 0x36
+#define DSPFREQSTAT_SHIFT_CHV24
+#define DSPFREQSTAT_MASK_CHV (0x1f
DSPFREQSTAT_SHIFT_CHV)
+#define DSPFREQGUAR_SHIFT_CHV8
+#define DSPFREQGUAR_MASK_CHV (0x1f
DSPFREQGUAR_SHIFT_CHV)
#define DSPFREQSTAT_SHIFT30
#define DSPFREQSTAT_MASK (0x3 DSPFREQSTAT_SHIFT)
#define DSPFREQGUAR_SHIFT14
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 99c10d1..9af1d13 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4529,6 +4529,47 @@ static void valleyview_set_cdclk(struct drm_device
*dev, int cdclk)
vlv_update_cdclk(dev);
}
+static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 val, cmd;
+
+ WARN_ON(dev_priv-display.get_display_clock_speed(dev) !=
dev_priv-vlv_cdclk_freq);
+
+ switch (cdclk) {
+ case 40:
+ cmd = 3;
+ break;
+ case 33:
+ case 32:
+ cmd = 2;
+ break;
+ case 27:
+ cmd = 1;
+ break;
+ case 20:
+ cmd = 0;
+ break;
+ default:
+ WARN_ON(1);
+ return;
+ }
+
+ mutex_lock(dev_priv-rps.hw_lock);
+ val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
+ val = ~DSPFREQGUAR_MASK_CHV;
+ val |= (cmd DSPFREQGUAR_SHIFT_CHV);
+ vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
+ if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ)
+ DSPFREQSTAT_MASK_CHV) == (cmd DSPFREQSTAT_SHIFT_CHV),
+50)) {
+ DRM_ERROR(timed out waiting for CDclk change\n);
+ }
+ mutex_unlock(dev_priv-rps.hw_lock);
+
+ vlv_update_cdclk(dev);
+}
+
static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
int max_pixclk)
{
@@ -4597,8 +4638,13 @@ static void
valleyview_modeset_global_resources(struct drm_device *dev)
int max_pixclk = intel_mode_max_pixclk(dev_priv);
int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
- if (req_cdclk != dev_priv-vlv_cdclk_freq)
- valleyview_set_cdclk(dev, req_cdclk);
+ if (req_cdclk != dev_priv-vlv_cdclk_freq) {
+ if (IS_CHERRYVIEW(dev))
+ cherryview_set_cdclk(dev, req_cdclk);
+ else
+ valleyview_set_cdclk(dev, req_cdclk);
+ }
+
modeset_update_crtc_power_domains(dev);
}
Which doc has these Punit commands? I'm assuming you have them
correct, but a ref would be good if we don't already have one.
These were in the punit has. The display cluster has still had the old
vlv information last I looked.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
There should probably be a JIRA for this too so QA can verify once we
have updated punit support.
--
Jesse Barnes, Intel Open Source Technology Center
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 11:32:07AM -0700, Ben Widawsky wrote:
On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
VMAs should take a reference of the address space they use.
Now, when the fd is closed, it will release the ref that the context was
holding, but it will still be referenced by any vmas that are still
active.
ppgtt_release() should then only be called when the last thing referencing
it releases the ref, and it can just call the base cleanup and free the
ppgtt.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 8
drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 2acc03f..a879a93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
/* i915_gem_context.c */
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt,
base)
+#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
+void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index dcd8d7b..25a32b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
drm_i915_gem_object *obj,
void i915_gem_vma_destroy(struct i915_vma *vma)
{
+ struct i915_address_space *vm = NULL;
+ struct i915_hw_ppgtt *ppgtt = NULL;
WARN_ON(vma-node.allocated);
/* Keep the vma as a placeholder in the execbuffer reservation lists */
if (!list_empty(vma-exec_list))
return;
+ vm = vma-vm;
+ ppgtt = vm_to_ppgtt(vm);
+
+ if (ppgtt)
+ kref_put(ppgtt-ref, ppgtt_release);
+
list_del(vma-vma_link);
kfree(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5b5af6c..59272f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt
*ppgtt)
return;
}
- /*
-* Make sure vmas are unbound before we take down the drm_mm
-*
-* FIXME: Proper refcounting should take care of this, this shouldn't be
-* needed at all.
-*/
- if (!list_empty(vm-active_list)) {
- struct i915_vma *vma;
-
- list_for_each_entry(vma, vm-active_list, mm_list)
- if (WARN_ON(list_empty(vma-vma_link) ||
- list_is_singular(vma-vma_link)))
- break;
-
- i915_gem_evict_vm(ppgtt-base, true);
- } else {
- i915_gem_retire_requests(dev);
- i915_gem_evict_vm(ppgtt-base, false);
- }
+ /* vmas should already be unbound */
+ WARN_ON(!list_empty(vm-active_list));
ppgtt-base.cleanup(ppgtt-base);
}
-static void ppgtt_release(struct kref *kref)
+void ppgtt_release(struct kref *kref)
{
struct i915_hw_ppgtt *ppgtt =
container_of(kref, struct i915_hw_ppgtt, ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1411613..90c3d0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct
drm_i915_gem_object *obj,
struct i915_address_space *vm)
{
struct i915_vma *vma;
+ struct i915_hw_ppgtt *ppgtt = NULL;
vma = i915_gem_obj_to_vma(obj, vm);
if (!vma)
vma = __i915_gem_vma_create(obj, vm);
+ ppgtt = vm_to_ppgtt(vm);
+ if (ppgtt)
+ kref_get(ppgtt-ref);
+
return vma;
}
Seems like a reasonable fix to me, and it's simpler than Chris' request
to ref when active. Logically his makes more sense, but it's not quite
as simple to review. Actually active isn't the right thing to track IMO,
bound is what you want to track.
I didn't mean to imply this is anything but a semantic difference with
the driver as it exists today.
I think if anything, do that one as a
patch on top, it does address the problem mentioned below. I also wonder
given the recent reset lolz how this behaves there;
Re: [Intel-gfx] [PATCH] drm/i915: freeze display before the interrupts and GT
On Tue, Jul 29, 2014 at 11:13:03AM -0700, Jesse Barnes wrote:
On Thu, 17 Jul 2014 17:43:46 -0300
Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Since we started using intel_runtime_pm_disable_interrupts() at normal
(non-runtime) suspend/resume, we had to remove a WARN from
ironlake_disable_display_irq to avoid a case where we were doing the
correct thing and the WARN was not really needed. The problem is that
the WARN was useful in other cases, and its removal can hide some bugs
that we would catch automatically.
To be able to add back the WARN, we have to call intel_crtc_control()
before interrupts are disabled, which is what this patch currently
does.
Also notice that Ville's patch from the Watermarks series drm/i915:
Leave interrupts enabled while disabling crtcs during suspend also
did a change that's equivalent to the one we're doing on this patch,
with the exception that its original patch, when applied to the
current tree, procduces a WARN.
Related commits:
commit daa390e5ee45cc051d6bf37b296901f2f92b002d
Author: Jesse Barnes jbar...@virtuousgeek.org
drm/i915: don't warn if IRQs are disabled when shutting down display
IRQs
commit e11aa362308f5de467ce355a2a2471321b15a35c
Author: Jesse Barnes jbar...@virtuousgeek.org
drm/i915: use runtime irq suspend/resume in freeze/thaw
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 11 +--
drivers/gpu/drm/i915/i915_irq.c | 2 +-
2 files changed, 6 insertions(+), 7 deletions(-)
No need to revert anything :)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 3315358..63675bf 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -520,12 +520,6 @@ static int i915_drm_freeze(struct drm_device *dev)
return error;
}
- flush_delayed_work(dev_priv-rps.delayed_resume_work);
-
- intel_runtime_pm_disable_interrupts(dev);
-
- intel_suspend_gt_powersave(dev);
-
/*
* Disable CRTCs directly since we want to preserve sw state
* for _thaw. Also, power gate the CRTC power wells.
@@ -535,6 +529,11 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_crtc_control(crtc, false);
drm_modeset_unlock_all(dev);
+ flush_delayed_work(dev_priv-rps.delayed_resume_work);
+ intel_runtime_pm_disable_interrupts(dev);
+
+ intel_suspend_gt_powersave(dev);
+
intel_modeset_suspend_hw(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 20c777c..af231ba 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -151,7 +151,7 @@ ironlake_disable_display_irq(struct drm_i915_private
*dev_priv, u32 mask)
{
assert_spin_locked(dev_priv-irq_lock);
- if (!intel_irqs_enabled(dev_priv))
+ if (WARN_ON(!intel_irqs_enabled(dev_priv)))
return;
if ((dev_priv-irq_mask mask) != mask) {
So with this added, we get the WARN back but don't need/want to revert
any other patches?
Did you check boot, suspend/resume, and runtime PM for warnings with
this change applied? If so, looks fine:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
There was a bit of conflict with one of Dave's fixes for the dp mst work,
but I think that was just partial of this patch here. But please
double-check.
Queued for -next, thanks for the patch.
-Daniel
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 12/40] drm/i915: Clarify CHV swing margin/deemph bits
On Tue, Jul 29, 2014 at 09:55:39AM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:04:03 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV display PHY registes have two swing margin/deemph settings. Make it
clear which ones we're using.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 8 ++--
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_hdmi.c | 4 ++--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index e296312..ba90320 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -831,8 +831,8 @@ enum punit_power_well {
#define _VLV_TX_DW2_CH00x8288
#define _VLV_TX_DW2_CH10x8488
-#define DPIO_SWING_MARGIN_SHIFT 16
-#define DPIO_SWING_MARGIN_MASK (0xff DPIO_SWING_MARGIN_SHIFT)
+#define DPIO_SWING_MARGIN000_SHIFT 16
+#define DPIO_SWING_MARGIN000_MASK(0xff
DPIO_SWING_MARGIN000_SHIFT)
#define DPIO_UNIQ_TRANS_SCALE_SHIFT 8
#define VLV_TX_DW2(ch) _PORT(ch, _VLV_TX_DW2_CH0, _VLV_TX_DW2_CH1)
@@ -840,12 +840,16 @@ enum punit_power_well {
#define _VLV_TX_DW3_CH10x848c
/* The following bit for CHV phy */
#define DPIO_TX_UNIQ_TRANS_SCALE_EN (127)
+#define DPIO_SWING_MARGIN101_SHIFT 16
+#define DPIO_SWING_MARGIN101_MASK(0xff
DPIO_SWING_MARGIN101_SHIFT)
#define VLV_TX_DW3(ch) _PORT(ch, _VLV_TX_DW3_CH0, _VLV_TX_DW3_CH1)
#define _VLV_TX_DW4_CH00x8290
#define _VLV_TX_DW4_CH10x8490
#define DPIO_SWING_DEEMPH9P5_SHIFT 24
#define DPIO_SWING_DEEMPH9P5_MASK(0xff
DPIO_SWING_DEEMPH9P5_SHIFT)
+#define DPIO_SWING_DEEMPH6P0_SHIFT 16
+#define DPIO_SWING_DEEMPH6P0_MASK(0xff
DPIO_SWING_DEEMPH6P0_SHIFT)
#define VLV_TX_DW4(ch) _PORT(ch, _VLV_TX_DW4_CH0, _VLV_TX_DW4_CH1)
#define _VLV_TX3_DW4_CH0 0x690
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index e272f92..4457f8f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2565,8 +2565,8 @@ static uint32_t intel_chv_signal_levels(struct
intel_dp *intel_dp)
/* Program swing margin */
for (i = 0; i 4; i++) {
val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW2(ch, i));
- val = ~DPIO_SWING_MARGIN_MASK;
- val |= margin_reg_value DPIO_SWING_MARGIN_SHIFT;
+ val = ~DPIO_SWING_MARGIN000_MASK;
+ val |= margin_reg_value DPIO_SWING_MARGIN000_SHIFT;
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW2(ch, i), val);
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index c9d77d3..c5c88127 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1411,8 +1411,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder)
for (i = 0; i 4; i++) {
val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW2(ch, i));
- val = ~DPIO_SWING_MARGIN_MASK;
- val |= 102 DPIO_SWING_MARGIN_SHIFT;
+ val = ~DPIO_SWING_MARGIN000_MASK;
+ val |= 102 DPIO_SWING_MARGIN000_SHIFT;
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW2(ch, i), val);
}
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Ok, pulled in the pile of patches Jesse just reviewed.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 34/40] drm/i915: Add DP training pattern 3 for CHV
On Tue, Jul 29, 2014 at 09:34:34PM +0300, Ville Syrjälä wrote:
On Tue, Jul 29, 2014 at 08:04:59PM +0200, Daniel Vetter wrote:
On Tue, Jul 29, 2014 at 10:01:57AM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:04:25 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
CHV supports DP training pattern 3. Add the required stuff.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 18 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 85b59c4..8debe61 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3515,6 +3515,8 @@ enum punit_power_well {
#define DP_LINK_TRAIN_OFF(3 28)
#define DP_LINK_TRAIN_MASK (3 28)
#define DP_LINK_TRAIN_SHIFT 28
+#define DP_LINK_TRAIN_PAT_3_CHV (1 14)
+#define DP_LINK_TRAIN_MASK_CHV ((3 28)|(114))
/* CPT Link training mode */
#define DP_LINK_TRAIN_PAT_1_CPT (0 8)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 739dc43..a825ff1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2900,7 +2900,10 @@ intel_dp_set_link_train(struct intel_dp
*intel_dp,
}
} else {
- *DP = ~DP_LINK_TRAIN_MASK;
+ if (IS_CHERRYVIEW(dev))
+ *DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ *DP = ~DP_LINK_TRAIN_MASK;
switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
case DP_TRAINING_PATTERN_DISABLE:
@@ -2913,8 +2916,12 @@ intel_dp_set_link_train(struct intel_dp
*intel_dp,
*DP |= DP_LINK_TRAIN_PAT_2;
break;
case DP_TRAINING_PATTERN_3:
- DRM_ERROR(DP training pattern 3 not
supported\n);
- *DP |= DP_LINK_TRAIN_PAT_2;
+ if (IS_CHERRYVIEW(dev)) {
+ *DP |= DP_LINK_TRAIN_PAT_3_CHV;
+ } else {
+ DRM_ERROR(DP training pattern 3 not
supported\n);
+ *DP |= DP_LINK_TRAIN_PAT_2;
+ }
break;
}
}
@@ -3201,7 +3208,10 @@ intel_dp_link_down(struct intel_dp *intel_dp)
DP = ~DP_LINK_TRAIN_MASK_CPT;
I915_WRITE(intel_dp-output_reg, DP |
DP_LINK_TRAIN_PAT_IDLE_CPT);
} else {
- DP = ~DP_LINK_TRAIN_MASK;
+ if (IS_CHERRYVIEW(dev))
+ DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ DP = ~DP_LINK_TRAIN_MASK;
I915_WRITE(intel_dp-output_reg, DP |
DP_LINK_TRAIN_PAT_IDLE);
}
POSTING_READ(intel_dp-output_reg);
I guess we could have a whole IS_CHV block, but that would probably add
more code than it saved...
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
This won't do a hole lot without adding HBR2 support ... Queued for
-next anyway, thanks for the patch.
What else is missing for HBR2?
Adjusting the check in intel_dp_max_link_bw. At least I haven't seen a
patch for that yet. Maybe missed it.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 37/40] drm/i915: Fix eDP link training when switching pipes
On Tue, Jul 29, 2014 at 08:06:57PM +0200, Daniel Vetter wrote:
On Mon, Jun 30, 2014 at 02:52:12PM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:04:28 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When switching from one pipe to another, the power sequencer of the new
pipe seems to need a bit of kicking to lock into the port. Even the vdd
force bit doesn't work before the power sequencer has been sufficiently
kicked, so this must be done even before any AUX transactions.
This sequence has been found to do the trick:
1) enable port with idle pattern
2) enable the power sequencer
3) proceed with link training
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 65ab54c..07b0320 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2010,6 +2010,37 @@ static void chv_post_disable_dp(struct
intel_encoder *encoder)
mutex_unlock(dev_priv-dpio_lock);
}
+static void intel_edp_init_train(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!is_edp(intel_dp))
+ return;
This changes the order of events as observed by the sink, so I really
wonder why this is edp specific?
It's not really. I need to kick the power sequencer for regular DP ports
too (in a later patch), and recently I started to wonder if we also need
it for HDMI ports but I didn't test that theory yet.
Based on my observations there are several problems intermingled here:
1. the power sequencer prevents the port from starting up until the
power up sequence has finished
2. vdd force bit doesn't work until the power sequencer has finished
3. the power sequencer won't finish the power up sequence unless idle
pattern is used
So the fix is to enable the port with idle pattern and enable the power
sequencer even before doing any aux transactions (including the sink
dpms write).
Once the power sequencer has finished powering up on to the port once.
the vdd force bit will keep working on the port even if the port and
power sequencer are later disabled. Also iirc the power sequencer will
no longer prevent the port from starting up even if the power sequencer
is left disabled when re-enabling the port later. But the same problem
will reappear when we change the pipe-port mapping, and then we need
to kick the power sequencer again.
We do have bug reports about external DP monitors not waking up from the
sink_dpms call properly ...
On vlv or something else? I'm not quite sure if the same problems would
be possible on other platforms since they only have one power sequencer.
But maybe that too locks into the port and would need a similar kick.
But IIRC on PCH platforms the spec says that we must enable the port
with training pattern 1. So the use of idle pattern would at least go
against the spec. Which is why I left that part as vlv/chv specific.
-Daniel
+
+ /*
+ * Need to enable the port with idle pattern to allow the power
+ * sequencer to lock into the port. Otherwise the power sequencer
+ * (including vdd force bit!) doesn't work on this port.
+ */
+ if (IS_VALLEYVIEW(dev)) {
+ intel_dp-DP |= DP_PORT_EN;
+
+ if (IS_CHERRYVIEW(dev))
+ intel_dp-DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ intel_dp-DP = ~DP_LINK_TRAIN_MASK;
+ intel_dp-DP |= DP_LINK_TRAIN_PAT_IDLE;
+
+ I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+ POSTING_READ(intel_dp-output_reg);
+ }
+
+ intel_edp_panel_on(intel_dp);
+ edp_panel_vdd_off(intel_dp, true);
+}
+
static void intel_enable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
@@ -2021,10 +2052,9 @@ static void intel_enable_dp(struct intel_encoder
*encoder)
return;
intel_edp_panel_vdd_on(intel_dp);
+ intel_edp_init_train(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
- intel_edp_panel_on(intel_dp);
- edp_panel_vdd_off(intel_dp, true);
intel_dp_complete_link_train(intel_dp);
intel_dp_stop_link_train(intel_dp);
}
Yeah I think this matches the doc too. I never pushed this change
because I could never find anything that it actually fixed.
I guess you have something now though!
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
Re: [Intel-gfx] [PATCH 37/40] drm/i915: Fix eDP link training when switching pipes
On Tue, Jul 29, 2014 at 10:18:46PM +0300, Ville Syrjälä wrote:
On Tue, Jul 29, 2014 at 08:06:57PM +0200, Daniel Vetter wrote:
On Mon, Jun 30, 2014 at 02:52:12PM -0700, Jesse Barnes wrote:
On Sat, 28 Jun 2014 02:04:28 +0300
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When switching from one pipe to another, the power sequencer of the new
pipe seems to need a bit of kicking to lock into the port. Even the vdd
force bit doesn't work before the power sequencer has been sufficiently
kicked, so this must be done even before any AUX transactions.
This sequence has been found to do the trick:
1) enable port with idle pattern
2) enable the power sequencer
3) proceed with link training
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 65ab54c..07b0320 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2010,6 +2010,37 @@ static void chv_post_disable_dp(struct
intel_encoder *encoder)
mutex_unlock(dev_priv-dpio_lock);
}
+static void intel_edp_init_train(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port =
dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!is_edp(intel_dp))
+ return;
This changes the order of events as observed by the sink, so I really
wonder why this is edp specific?
It's not really. I need to kick the power sequencer for regular DP ports
too (in a later patch), and recently I started to wonder if we also need
it for HDMI ports but I didn't test that theory yet.
Based on my observations there are several problems intermingled here:
1. the power sequencer prevents the port from starting up until the
power up sequence has finished
2. vdd force bit doesn't work until the power sequencer has finished
3. the power sequencer won't finish the power up sequence unless idle
pattern is used
So the fix is to enable the port with idle pattern and enable the power
sequencer even before doing any aux transactions (including the sink
dpms write).
Once the power sequencer has finished powering up on to the port once.
the vdd force bit will keep working on the port even if the port and
power sequencer are later disabled. Also iirc the power sequencer will
no longer prevent the port from starting up even if the power sequencer
is left disabled when re-enabling the port later. But the same problem
will reappear when we change the pipe-port mapping, and then we need
to kick the power sequencer again.
We do have bug reports about external DP monitors not waking up from the
sink_dpms call properly ...
On vlv or something else? I'm not quite sure if the same problems would
be possible on other platforms since they only have one power sequencer.
But maybe that too locks into the port and would need a similar kick.
But IIRC on PCH platforms the spec says that we must enable the port
with training pattern 1. So the use of idle pattern would at least go
against the spec. Which is why I left that part as vlv/chv specific.
Hm ... tricky. And especially since it seems to be required only once. I'm
just concerned about the slight behavioural difference between the general
dp link enabling where we do the sink dpms aux transaction first, then
start with link training. But on vlv/chv here we first kick the port a bit
and enable the idle pattern. If now a few displays don't like this or
require this we have a problem.
In general I really want us to try as hard as possible to have 0
differences in sink-visible behaviour. DP is simply too fickle imo. But if
there's nothing we can do I guess good explanations in commit message and
comments is all I can ask for. I.e. something like the above should go
into the commit message and maybe we should make the comment a bit more
dangerously-sounding.
-Daniel
-Daniel
+
+ /*
+* Need to enable the port with idle pattern to allow the power
+* sequencer to lock into the port. Otherwise the power
sequencer
+* (including vdd force bit!) doesn't work on this port.
+*/
+ if (IS_VALLEYVIEW(dev)) {
+ intel_dp-DP |= DP_PORT_EN;
+
+ if (IS_CHERRYVIEW(dev))
+ intel_dp-DP = ~DP_LINK_TRAIN_MASK_CHV;
+ else
+ intel_dp-DP = ~DP_LINK_TRAIN_MASK;
+ intel_dp-DP |= DP_LINK_TRAIN_PAT_IDLE;
+
+
Re: [Intel-gfx] [PATCH] drm/i915: vma/ppgtt lifetime rules
On Tue, Jul 29, 2014 at 11:44:51AM -0700, Ben Widawsky wrote:
On Tue, Jul 29, 2014 at 11:32:07AM -0700, Ben Widawsky wrote:
On Tue, Jul 29, 2014 at 11:08:05AM +0100, Michel Thierry wrote:
VMAs should take a reference of the address space they use.
Now, when the fd is closed, it will release the ref that the context was
holding, but it will still be referenced by any vmas that are still
active.
ppgtt_release() should then only be called when the last thing referencing
it releases the ref, and it can just call the base cleanup and free the
ppgtt.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 8
drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 2acc03f..a879a93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2495,7 +2495,9 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
/* i915_gem_context.c */
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt,
base)
+#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
+void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index dcd8d7b..25a32b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
drm_i915_gem_object *obj,
void i915_gem_vma_destroy(struct i915_vma *vma)
{
+ struct i915_address_space *vm = NULL;
+ struct i915_hw_ppgtt *ppgtt = NULL;
WARN_ON(vma-node.allocated);
/* Keep the vma as a placeholder in the execbuffer reservation lists */
if (!list_empty(vma-exec_list))
return;
+ vm = vma-vm;
+ ppgtt = vm_to_ppgtt(vm);
+
+ if (ppgtt)
+ kref_put(ppgtt-ref, ppgtt_release);
+
list_del(vma-vma_link);
kfree(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5b5af6c..59272f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt
*ppgtt)
return;
}
- /*
- * Make sure vmas are unbound before we take down the drm_mm
- *
- * FIXME: Proper refcounting should take care of this, this shouldn't be
- * needed at all.
- */
- if (!list_empty(vm-active_list)) {
- struct i915_vma *vma;
-
- list_for_each_entry(vma, vm-active_list, mm_list)
- if (WARN_ON(list_empty(vma-vma_link) ||
- list_is_singular(vma-vma_link)))
- break;
-
- i915_gem_evict_vm(ppgtt-base, true);
- } else {
- i915_gem_retire_requests(dev);
- i915_gem_evict_vm(ppgtt-base, false);
- }
+ /* vmas should already be unbound */
+ WARN_ON(!list_empty(vm-active_list));
ppgtt-base.cleanup(ppgtt-base);
}
-static void ppgtt_release(struct kref *kref)
+void ppgtt_release(struct kref *kref)
{
struct i915_hw_ppgtt *ppgtt =
container_of(kref, struct i915_hw_ppgtt, ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1411613..90c3d0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct
drm_i915_gem_object *obj,
struct i915_address_space *vm)
{
struct i915_vma *vma;
+ struct i915_hw_ppgtt *ppgtt = NULL;
vma = i915_gem_obj_to_vma(obj, vm);
if (!vma)
vma = __i915_gem_vma_create(obj, vm);
+ ppgtt = vm_to_ppgtt(vm);
+ if (ppgtt)
+ kref_get(ppgtt-ref);
+
return vma;
}
Seems like a reasonable fix to me, and it's simpler than Chris' request
to ref when active. Logically his makes more sense, but it's not quite
as simple to review. Actually active isn't the right thing to track IMO,
bound is what you want to track.
I didn't mean to imply this is anything but a semantic difference with
the driver as it exists today.
Well using active would be what we want, with bound we'd have
[Intel-gfx] [PATCH 2/2] drm/i915: Embellish wait_end trace
This adds two new data points to the trace event, wait time, and whether
or not the event slept. Both of these should already be obtainable
through various means. This patch just makes the data more accessible.
Wait is obtainable with the current code by matching seqnos in
begin/end. In simple cases where begin/ends are always paired, this is
trivial. However, if you queue up multiple begins/ends, it can get
confusing. We're already calculating wait time, so it's trivially added
here. This patch also provides the slightly more accurate wait_time as
opposed to the timestamps from the tracepoint. It's observable, but just
noise.
The second bit of information, whether or not the operation slept is
helpful in determining where time went. This is probably also obtainable
through the scheduler events. However, we have the information easily at
our fingertips, we may as well give it out.
This results in an event which looks like:
gem_gtt_hog 409 [000]32.012641: i915:i915_gem_request_wait_end: dev=0,
ring=3, seqno=4294963203, duration=0.000368225 (slept=yes)
While here, rename sleep_time to wait_time since the verb sleep hasn't
been true for a long time (several conditions exist where it won't
sleep).
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 12 +++-
drivers/gpu/drm/i915/i915_trace.h | 29 ++---
2 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 17f7ac9..bb7fed6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1161,6 +1161,8 @@ static int __wait_seqno(struct intel_engine_cs *ring, u32
seqno,
struct timespec before, now;
DEFINE_WAIT(wait);
unsigned long timeout_expire;
+ struct timespec wait_time;
+ bool slept = false;
int ret;
WARN(!intel_irqs_enabled(dev_priv), IRQs disabled);
@@ -1216,6 +1218,7 @@ static int __wait_seqno(struct intel_engine_cs *ring, u32
seqno,
break;
}
+ slept = true;
timer.function = NULL;
if (timeout || missed_irq(dev_priv, ring)) {
unsigned long expire;
@@ -1233,17 +1236,16 @@ static int __wait_seqno(struct intel_engine_cs *ring,
u32 seqno,
}
}
getrawmonotonic(now);
- trace_i915_gem_request_wait_end(ring, seqno);
if (!irq_test_in_progress)
ring-irq_put(ring);
finish_wait(ring-irq_queue, wait);
+ wait_time = timespec_sub(now, before);
+ trace_i915_gem_request_wait_end(ring, seqno, wait_time, slept);
- if (timeout) {
- struct timespec sleep_time = timespec_sub(now, before);
- *timeout = timespec_sub(*timeout, sleep_time);
- }
+ if (timeout)
+ *timeout = timespec_sub(*timeout, wait_time);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index f5aa006..0936066 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -476,9 +476,32 @@ TRACE_EVENT(i915_gem_request_wait_begin,
__entry-blocking ? yes (NB) : no)
);
-DEFINE_EVENT(i915_gem_request, i915_gem_request_wait_end,
- TP_PROTO(struct intel_engine_cs *ring, u32 seqno),
- TP_ARGS(ring, seqno)
+TRACE_EVENT(i915_gem_request_wait_end,
+ TP_PROTO(struct intel_engine_cs *ring, u32 seqno, struct timespec
delta, bool slept),
+ TP_ARGS(ring, seqno, delta, slept),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(u32, ring)
+__field(u32, seqno)
+__field(long long, s)
+__field(long, ns)
+__field(bool, slept)
+),
+
+ TP_fast_assign(
+ __entry-dev = ring-dev-primary-index;
+ __entry-ring = ring-id;
+ __entry-seqno = seqno;
+ __entry-s = (long long)delta.tv_sec;
+ __entry-ns = delta.tv_nsec;
+ __entry-slept = slept;
+ ),
+
+ TP_printk(dev=%u, ring=%u, seqno=%u, duration=%lld.%.9ld
(slept=%s),
+ __entry-dev, __entry-ring, __entry-seqno,
+ __entry-s, __entry-ns,
+ __entry-slept ? yes : no)
);
DECLARE_EVENT_CLASS(i915_ring,
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: timespec_sub should already be normalized
So don't bother checking it again.
This was introduced:
commit b361237bcc7cea1d99f770490120d8bc2aed
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Fri Aug 24 09:35:08 2012 +0100
drm/i915: Juggle code order to ease flow of the next patch
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ac349ff..17f7ac9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1243,8 +1243,6 @@ static int __wait_seqno(struct intel_engine_cs *ring, u32
seqno,
if (timeout) {
struct timespec sleep_time = timespec_sub(now, before);
*timeout = timespec_sub(*timeout, sleep_time);
- if (!timespec_valid(timeout)) /* i.e. negative time remains */
- set_normalized_timespec(timeout, 0, 0);
}
return ret;
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 / 3.15 intermittently boots into blank screeen
Am 18.07.2014 18:25, schrieb Daniel Vetter: On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann j...@hz6.de wrote: Am 18.07.2014 15:27, schrieb Daniel Vetter: On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: I'm experiencing an issue with 3.15.5 on my Lenovo T400: Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but the first mode change doesn't occur, resulting in a black screen with backlight on. The system is entirely unresponsive and I can only press the power button until to switch it off. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. thank you for the feedback. I still have all my custom built kernels, I will test 3.14.0 through 3.14.8 to make sure those were OK and report back. You only need to test 3.14.0, since the backported fixes only contain a very small subset of all patches for 3.15. So it's more efficient to then switch to git bisect between 3.14 and 3.15 directly (after you've confirmed that 3.15.0 is indeed busted). I familiarized with git bisect, that was something I had never used before. I started it with git bisect start v3.15 v3.14 -- drivers/gpu/drm/i915 This lead me to this: cfa7c862982b431add7f2b362526bf31372fc7b0 is the first bad commit commit cfa7c862982b431add7f2b362526bf31372fc7b0 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Apr 29 11:53:58 2014 +0200 drm/i915: Sanitize the enable_ppgtt module option once Otherwise we'll end up spamming dmesg on every context creation on snb with vt-d enabled. This regression was introduced in commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549 Author: Ben Widawsky benjamin.widaw...@intel.com Date: Fri Dec 6 14:11:14 2013 -0800 drm/i915: Reorganize intel_enable_ppgtt As the i915.enable_ppgtt is read-only it cannot be changed after the module is loaded and so we can perform an early sanitization of the values. v2: - Add comment and pimp commit message (Chris) - Use the param consistently (Jani) v3: - Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to gtt_init. Fixes boot hangs on pre-gen6. - Add a debug output for the sanitize ppgtt mode. References: https://lkml.org/lkml/2014/4/17/599 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916 Cc: Alessandro Suardi alessandro.sua...@gmail.com Cc: Ben Widawsky b...@bwidawsk.net Cc: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Jani Nikula jani.nik...@intel.com :04 04 5488e397a1aaa28dca4a252452e9463b0a8f8d10 214c8e98b3c72844e48ab7aef02cba7daf139fab M drivers I realized that the issue does always show, contrary to the subject initially chosen. Unfortunately I can't say anything else, but maybe this will help you experts spot the issue. If I can help more, be it with testing or anything else, just let me know. Regards jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm: Add drm_plane/connector_index
In the atomic state we'll have an array of states for crtcs, planes
and connectors and need to be able to at them by their index. We
already have a drm_crtc_index function so add the missing ones for
planes and connectors.
If it later on turns out that the list walking is too expensive we can
add the index to the relevant modeset objects.
Rob Clark doesn't like the loops too much, but we can always add an
obj-idx parameter later on. And for now reiterating is actually safer
since nowadays we have hotpluggable connectors (thanks to DP MST).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 46 ++
include/drm/drm_crtc.h | 2 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 805240b11229..5a494caa8c9a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -937,6 +937,29 @@ void drm_connector_cleanup(struct drm_connector *connector)
EXPORT_SYMBOL(drm_connector_cleanup);
/**
+ * drm_plane_index - find the index of a registered CRTC
+ * @plane: CRTC to find index for
+ *
+ * Given a registered CRTC, return the index of that CRTC within a DRM
+ * device's list of CRTCs.
+ */
+unsigned int drm_connector_index(struct drm_connector *connector)
+{
+ unsigned int index = 0;
+ struct drm_connector *tmp;
+
+ list_for_each_entry(tmp, connector-dev-mode_config.connector_list,
head) {
+ if (tmp == connector)
+ return index;
+
+ index++;
+ }
+
+ BUG();
+}
+EXPORT_SYMBOL(drm_connector_index);
+
+/**
* drm_connector_register - register a connector
* @connector: the connector to register
*
@@ -1239,6 +1262,29 @@ void drm_plane_cleanup(struct drm_plane *plane)
EXPORT_SYMBOL(drm_plane_cleanup);
/**
+ * drm_plane_index - find the index of a registered CRTC
+ * @plane: CRTC to find index for
+ *
+ * Given a registered CRTC, return the index of that CRTC within a DRM
+ * device's list of CRTCs.
+ */
+unsigned int drm_plane_index(struct drm_plane *plane)
+{
+ unsigned int index = 0;
+ struct drm_plane *tmp;
+
+ list_for_each_entry(tmp, plane-dev-mode_config.plane_list, head) {
+ if (tmp == plane)
+ return index;
+
+ index++;
+ }
+
+ BUG();
+}
+EXPORT_SYMBOL(drm_plane_index);
+
+/**
* drm_plane_force_disable - Forcibly disable a plane
* @plane: plane to disable
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f1105d0da059..4cae44611ab0 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -903,6 +903,7 @@ int drm_connector_register(struct drm_connector *connector);
void drm_connector_unregister(struct drm_connector *connector);
extern void drm_connector_cleanup(struct drm_connector *connector);
+extern unsigned int drm_connector_index(struct drm_connector *crtc);
/* helper to unplug all connectors from sysfs for device */
extern void drm_connector_unplug_all(struct drm_device *dev);
@@ -942,6 +943,7 @@ extern int drm_plane_init(struct drm_device *dev,
const uint32_t *formats, uint32_t format_count,
bool is_primary);
extern void drm_plane_cleanup(struct drm_plane *plane);
+extern unsigned int drm_plane_index(struct drm_plane *crtc);
extern void drm_plane_force_disable(struct drm_plane *plane);
extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
int x, int y,
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] atomic prep work
Hi all, So I've split out every single hunk that touches existing code from my atomic series and this is it. It mostly touches error handling code and other more exceptional stuff. My idea is that if we get this in now we have a bit more leeway with the actual atomic infrastructure work since that won't touch any code any more which is used by current drivers. Comments, flames and reviews highly welcome. Cheers, Daniel Daniel Vetter (8): drm: Add drm_plane/connector_index drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc] drm: Handle legacy per-crtc locking with full acquire ctx drm: Move -old_fb from crtc to plane drm: trylock modest locking for fbdev panics drm: Add a plane-reset hook drm/irq: Implement a generic vblank_wait function drm/i915: Use generic vblank wait drivers/gpu/drm/drm_crtc.c | 194 +-- drivers/gpu/drm/drm_fb_helper.c | 10 +- drivers/gpu/drm/drm_irq.c| 45 drivers/gpu/drm/drm_modeset_lock.c | 213 ++- drivers/gpu/drm/i915/intel_display.c | 41 +-- include/drm/drmP.h | 2 + include/drm/drm_crtc.h | 21 ++-- include/drm/drm_modeset_lock.h | 16 +++ 8 files changed, 373 insertions(+), 169 deletions(-) -- 2.0.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm: Add a plane-reset hook
In general having this can't hurt, and the atomic helpers will need
it to be able to reset the state objects properly. The overall idea
is to reset in the order pixels flow, so planes - crtcs -
encoders - connectors.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 5 +
include/drm/drm_crtc.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index bacf565449d5..ff705ea3f50e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4582,9 +4582,14 @@ out:
void drm_mode_config_reset(struct drm_device *dev)
{
struct drm_crtc *crtc;
+ struct drm_crtc *plane;
struct drm_encoder *encoder;
struct drm_connector *connector;
+ list_for_each_entry(plane, dev-mode_config.plane_list, head)
+ if (plane-funcs-reset)
+ plane-funcs-reset(plane);
+
list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
if (crtc-funcs-reset)
crtc-funcs-reset(crtc);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5fffb5c53ba6..0115b80a0632 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -580,6 +580,7 @@ struct drm_plane_funcs {
uint32_t src_w, uint32_t src_h);
int (*disable_plane)(struct drm_plane *plane);
void (*destroy)(struct drm_plane *plane);
+ void (*reset)(struct drm_plane *plane);
int (*set_property)(struct drm_plane *plane,
struct drm_property *property, uint64_t val);
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm: Move -old_fb from crtc to plane
Atomic implemenations for legacy ioctls must be able to drop locks.
Which doesn't cause havoc since we only do that while constructing
the new state, so no driver or hardware state change has happened.
The only troubling bit is the fb refcounting the core does - if
someone else has snuck in then it might potentially unref an
outdated framebuffer. To fix that move the old_fb temporary storage
into struct drm_plane for all ioctls, so that the atomic helpers can
update it.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 40
include/drm/drm_crtc.h | 8
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c09374038f9a..bacf565449d5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1200,19 +1200,21 @@ EXPORT_SYMBOL(drm_plane_index);
*/
void drm_plane_force_disable(struct drm_plane *plane)
{
- struct drm_framebuffer *old_fb = plane-fb;
int ret;
- if (!old_fb)
+ if (!plane-fb)
return;
+ plane-old_fb = plane-fb;
ret = plane-funcs-disable_plane(plane);
if (ret) {
DRM_ERROR(failed to disable plane with busy fb\n);
+ plane-old_fb = NULL;
return;
}
/* disconnect the plane from the fb and crtc: */
- __drm_framebuffer_unreference(old_fb);
+ __drm_framebuffer_unreference(plane-old_fb);
+ plane-old_fb = NULL;
plane-fb = NULL;
plane-crtc = NULL;
}
@@ -2188,7 +2190,7 @@ static int setplane_internal(struct drm_plane *plane,
uint32_t src_w, uint32_t src_h)
{
struct drm_device *dev = plane-dev;
- struct drm_framebuffer *old_fb = NULL;
+ struct drm_framebuffer *old_fb;
int ret = 0;
unsigned int fb_width, fb_height;
int i;
@@ -2196,14 +2198,16 @@ static int setplane_internal(struct drm_plane *plane,
/* No fb means shut it down */
if (!fb) {
drm_modeset_lock_all(dev);
- old_fb = plane-fb;
+ plane-old_fb = plane-fb;
ret = plane-funcs-disable_plane(plane);
if (!ret) {
plane-crtc = NULL;
plane-fb = NULL;
} else {
- old_fb = NULL;
+ plane-old_fb = NULL;
}
+ old_fb = plane-old_fb;
+ plane-old_fb = NULL;
drm_modeset_unlock_all(dev);
goto out;
}
@@ -2245,7 +2249,7 @@ static int setplane_internal(struct drm_plane *plane,
}
drm_modeset_lock_all(dev);
- old_fb = plane-fb;
+ plane-old_fb = plane-fb;
ret = plane-funcs-update_plane(plane, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h);
@@ -2254,8 +2258,10 @@ static int setplane_internal(struct drm_plane *plane,
plane-fb = fb;
fb = NULL;
} else {
- old_fb = NULL;
+ plane-old_fb = NULL;
}
+ old_fb = plane-old_fb;
+ plane-old_fb = NULL;
drm_modeset_unlock_all(dev);
out:
@@ -2369,7 +2375,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
* crtcs. Atomic modeset will have saner semantics ...
*/
list_for_each_entry(tmp, crtc-dev-mode_config.crtc_list, head)
- tmp-old_fb = tmp-primary-fb;
+ tmp-primary-old_fb = tmp-primary-fb;
fb = set-fb;
@@ -2382,8 +2388,9 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
list_for_each_entry(tmp, crtc-dev-mode_config.crtc_list, head) {
if (tmp-primary-fb)
drm_framebuffer_reference(tmp-primary-fb);
- if (tmp-old_fb)
- drm_framebuffer_unreference(tmp-old_fb);
+ if (tmp-primary-old_fb)
+ drm_framebuffer_unreference(tmp-primary-old_fb);
+ tmp-primary-old_fb = NULL;
}
return ret;
@@ -4458,7 +4465,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
{
struct drm_mode_crtc_page_flip *page_flip = data;
struct drm_crtc *crtc;
- struct drm_framebuffer *fb = NULL, *old_fb = NULL;
+ struct drm_framebuffer *fb = NULL;
struct drm_pending_vblank_event *e = NULL;
unsigned long flags;
int ret = -EINVAL;
@@ -4530,7 +4537,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
(void (*) (struct drm_pending_event *)) kfree;
}
- old_fb = crtc-primary-fb;
+ crtc-primary-old_fb = crtc-primary-fb;
ret = crtc-funcs-page_flip(crtc, fb, e, page_flip-flags);
if (ret) {
if
[Intel-gfx] [PATCH 7/8] drm/irq: Implement a generic vblank_wait function
As usual in both a crtc index and a struct drm_crtc * version.
The function assumes that no one drivers their display below 10Hz, and
it will complain if the vblank wait takes longer than that.
v2: Also check dev-max_vblank_counter since some drivers register a
fake get_vblank_counter function.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_irq.c | 45 +
include/drm/drmP.h| 2 ++
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0de123afdb34..76024fdde452 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -999,6 +999,51 @@ void drm_crtc_vblank_put(struct drm_crtc *crtc)
EXPORT_SYMBOL(drm_crtc_vblank_put);
/**
+ * drm_vblank_wait - wait for one vblank
+ * @dev: DRM device
+ * @crtc: crtc index
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disable, e.g.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_vblank_wait(struct drm_device *dev, int crtc)
+{
+ int ret;
+ u32 last;
+
+ ret = drm_vblank_get(dev, crtc);
+ if (WARN_ON(ret))
+ return;
+
+ last = drm_vblank_count(dev, crtc);
+
+#define C (last != drm_vblank_count(dev, crtc))
+ ret = wait_event_timeout(dev-vblank[crtc].queue,
+C, msecs_to_jiffies(100));
+
+ WARN_ON(ret == 0);
+#undef C
+
+ drm_vblank_put(dev, crtc);
+}
+EXPORT_SYMBOL(drm_vblank_wait);
+
+/**
+ * drm_crtc_vblank_wait - wait for one vblank
+ * @crtc: DRM crtc
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disable, e.g.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc-dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
* drm_vblank_off - disable vblank events on a CRTC
* @dev: DRM device
* @crtc: CRTC in question
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 06a673894c47..f72e5ef5f7b0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1355,6 +1355,8 @@ extern int drm_vblank_get(struct drm_device *dev, int
crtc);
extern void drm_vblank_put(struct drm_device *dev, int crtc);
extern int drm_crtc_vblank_get(struct drm_crtc *crtc);
extern void drm_crtc_vblank_put(struct drm_crtc *crtc);
+extern void drm_vblank_wait(struct drm_device *dev, int crtc);
+extern void drm_crtc_vblank_wait(struct drm_crtc *crtc);
extern void drm_vblank_off(struct drm_device *dev, int crtc);
extern void drm_vblank_on(struct drm_device *dev, int crtc);
extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm: trylock modest locking for fbdev panics
In the fbdev code we want to do trylocks only to avoid deadlocks and
other ugly issues. Thus far we've only grabbed the overall modeset
lock, but that already failed to exclude a pile of potential
concurrent operations. With proper atomic support this will be worse.
So add a trylock mode to the modeset locking code which attempts all
locks only with trylocks, if possible. We need to track this in the
locking functions themselves and can't restrict this to drivers since
driver-private w/w mutexes must be treated the same way.
There's still the issue that other driver private locks aren't handled
here at all, but well can't have everything. With this we will at
least not regress, even once atomic allows lots of concurrent kms
activity.
Aside: We should move the acquire context to stack-based allocation in
the callers to get rid of that awful WARN_ON(kmalloc_failed) control
flow which just blows up when memory is short. But that's material for
separate patches.
v2:
- Fix logic inversion fumble in the fb helper.
- Add proper kerneldoc.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_fb_helper.c| 10 +++
drivers/gpu/drm/drm_modeset_lock.c | 56 ++
include/drm/drm_modeset_lock.h | 6
3 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9dc0f1..841e039ba028 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -419,11 +419,11 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (dev-switch_power_state == DRM_SWITCH_POWER_OFF)
continue;
- /* NOTE: we use lockless flag below to avoid grabbing other
-* modeset locks. So just trylock the underlying mutex
-* directly:
+ /*
+* NOTE: Use trylock mode to avoid deadlocks and sleeping in
+* panic context.
*/
- if (!mutex_trylock(dev-mode_config.mutex)) {
+ if (__drm_modeset_lock_all(dev, true) != 0) {
error = true;
continue;
}
@@ -432,7 +432,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (ret)
error = true;
- mutex_unlock(dev-mode_config.mutex);
+ drm_modeset_unlock_all(dev);
}
return error;
}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 4d2aa549c614..acfe187609b0 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -57,26 +57,37 @@
/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
+ * __drm_modeset_lock_all - internal helper to grab all modeset locks
+ * @dev: DRM device
+ * @trylock: trylock mode for atomic contexts
*
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
+ * This is a special version of drm_modeset_lock_all() which can also be used
in
+ * atomic contexts. Then @trylock must be set to true.
+ *
+ * Returns:
+ * 0 on success or negative error code on failure.
*/
-void drm_modeset_lock_all(struct drm_device *dev)
+int __drm_modeset_lock_all(struct drm_device *dev,
+ bool trylock)
{
struct drm_mode_config *config = dev-mode_config;
struct drm_modeset_acquire_ctx *ctx;
int ret;
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
- if (WARN_ON(!ctx))
- return;
+ ctx = kzalloc(sizeof(*ctx),
+ trylock ? GFP_ATOMIC : GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
- mutex_lock(config-mutex);
+ if (trylock) {
+ if (!mutex_trylock(config-mutex))
+ return -EBUSY;
+ } else {
+ mutex_lock(config-mutex);
+ }
drm_modeset_acquire_init(ctx, 0);
+ ctx-trylock_only = trylock;
retry:
ret = drm_modeset_lock(config-connection_mutex, ctx);
@@ -95,13 +106,29 @@ retry:
drm_warn_on_modeset_not_all_locked(dev);
- return;
+ return 0;
fail:
if (ret == -EDEADLK) {
drm_modeset_backoff(ctx);
goto retry;
}
+
+ return ret;
+}
+EXPORT_SYMBOL(__drm_modeset_lock_all);
+
+/**
+ * drm_modeset_lock_all - take all modeset locks
+ * @dev: drm device
+ *
+ * This function takes all modeset locks, suitable where a more fine-grained
+ * scheme isn't (yet) implemented. Locks must be dropped with
+ * drm_modeset_unlock_all.
+ */
+void drm_modeset_lock_all(struct drm_device *dev)
+{
+ WARN_ON(__drm_modeset_lock_all(dev, false) != 0);
}
EXPORT_SYMBOL(drm_modeset_lock_all);
@@ -287,7 +314,12 @@ static inline int
[Intel-gfx] [PATCH 2/8] drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc]
Somehow we've forgotten about this little bit of OCD.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 95 --
drivers/gpu/drm/drm_modeset_lock.c | 95 ++
include/drm/drm_crtc.h | 4 --
include/drm/drm_modeset_lock.h | 5 ++
4 files changed, 100 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5a494caa8c9a..ff583bec31f9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -45,101 +45,6 @@ static struct drm_framebuffer
*add_framebuffer_internal(struct drm_device *dev,
struct drm_mode_fb_cmd2
*r,
struct drm_file
*file_priv);
-/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
- *
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
- */
-void drm_modeset_lock_all(struct drm_device *dev)
-{
- struct drm_mode_config *config = dev-mode_config;
- struct drm_modeset_acquire_ctx *ctx;
- int ret;
-
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
- if (WARN_ON(!ctx))
- return;
-
- mutex_lock(config-mutex);
-
- drm_modeset_acquire_init(ctx, 0);
-
-retry:
- ret = drm_modeset_lock(config-connection_mutex, ctx);
- if (ret)
- goto fail;
- ret = drm_modeset_lock_all_crtcs(dev, ctx);
- if (ret)
- goto fail;
-
- WARN_ON(config-acquire_ctx);
-
- /* now we hold the locks, so now that it is safe, stash the
-* ctx for drm_modeset_unlock_all():
-*/
- config-acquire_ctx = ctx;
-
- drm_warn_on_modeset_not_all_locked(dev);
-
- return;
-
-fail:
- if (ret == -EDEADLK) {
- drm_modeset_backoff(ctx);
- goto retry;
- }
-}
-EXPORT_SYMBOL(drm_modeset_lock_all);
-
-/**
- * drm_modeset_unlock_all - drop all modeset locks
- * @dev: device
- *
- * This function drop all modeset locks taken by drm_modeset_lock_all.
- */
-void drm_modeset_unlock_all(struct drm_device *dev)
-{
- struct drm_mode_config *config = dev-mode_config;
- struct drm_modeset_acquire_ctx *ctx = config-acquire_ctx;
-
- if (WARN_ON(!ctx))
- return;
-
- config-acquire_ctx = NULL;
- drm_modeset_drop_locks(ctx);
- drm_modeset_acquire_fini(ctx);
-
- kfree(ctx);
-
- mutex_unlock(dev-mode_config.mutex);
-}
-EXPORT_SYMBOL(drm_modeset_unlock_all);
-
-/**
- * drm_warn_on_modeset_not_all_locked - check that all modeset locks are locked
- * @dev: device
- *
- * Useful as a debug assert.
- */
-void drm_warn_on_modeset_not_all_locked(struct drm_device *dev)
-{
- struct drm_crtc *crtc;
-
- /* Locking is currently fubar in the panic handler. */
- if (oops_in_progress)
- return;
-
- list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
- WARN_ON(!drm_modeset_is_locked(crtc-mutex));
-
- WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
- WARN_ON(!mutex_is_locked(dev-mode_config.mutex));
-}
-EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
-
/* Avoid boilerplate. I'm tired of typing. */
#define DRM_ENUM_NAME_FN(fnname, list) \
const char *fnname(int val) \
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 0dc57d5ecd10..73e6534fd0aa 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -57,6 +57,101 @@
/**
+ * drm_modeset_lock_all - take all modeset locks
+ * @dev: drm device
+ *
+ * This function takes all modeset locks, suitable where a more fine-grained
+ * scheme isn't (yet) implemented. Locks must be dropped with
+ * drm_modeset_unlock_all.
+ */
+void drm_modeset_lock_all(struct drm_device *dev)
+{
+ struct drm_mode_config *config = dev-mode_config;
+ struct drm_modeset_acquire_ctx *ctx;
+ int ret;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (WARN_ON(!ctx))
+ return;
+
+ mutex_lock(config-mutex);
+
+ drm_modeset_acquire_init(ctx, 0);
+
+retry:
+ ret = drm_modeset_lock(config-connection_mutex, ctx);
+ if (ret)
+ goto fail;
+ ret = drm_modeset_lock_all_crtcs(dev, ctx);
+ if (ret)
+ goto fail;
+
+ WARN_ON(config-acquire_ctx);
+
+ /* now we hold the locks, so now that it is safe, stash the
+* ctx for drm_modeset_unlock_all():
+*/
+ config-acquire_ctx = ctx;
+
+ drm_warn_on_modeset_not_all_locked(dev);
+
+ return;
+
+fail:
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(ctx);
[Intel-gfx] [PATCH 3/8] drm: Handle legacy per-crtc locking with full acquire ctx
So drivers using the atomic interfaces expect that they can acquire
additional locks internal to the driver as-needed. Examples would be
locks to protect shared state like shared display PLLs.
Unfortunately the legacy ioctls assume that all locking is fully done
by the drm core. Now for those paths which grab all locks we already
have to keep around an acquire context in dev-mode_config. Helper
functions that implement legacy interfaces in terms of atomic support
can therefore grab this acquire contexts and reuse it.
The only interfaces left are the cursor and pageflip ioctls. So add
functions to grab the crtc lock these need using an acquire context
and preserve it for atomic drivers to reuse.
v2:
- Fixup commentskerneldoc.
- Drop the WARNING from modeset_lock_all_crtcs since that can be used
in legacy paths with crtc locking.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 8 ++--
drivers/gpu/drm/drm_modeset_lock.c | 84 ++
include/drm/drm_crtc.h | 6 +++
include/drm/drm_modeset_lock.h | 5 +++
4 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ff583bec31f9..c09374038f9a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2714,7 +2714,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
if (crtc-cursor)
return drm_mode_cursor_universal(crtc, req, file_priv);
- drm_modeset_lock(crtc-mutex, NULL);
+ drm_modeset_lock_crtc(crtc);
if (req-flags DRM_MODE_CURSOR_BO) {
if (!crtc-funcs-cursor_set !crtc-funcs-cursor_set2) {
ret = -ENXIO;
@@ -2738,7 +2738,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
}
}
out:
- drm_modeset_unlock(crtc-mutex);
+ drm_modeset_unlock_crtc(crtc);
return ret;
@@ -4474,7 +4474,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (!crtc)
return -ENOENT;
- drm_modeset_lock(crtc-mutex, NULL);
+ drm_modeset_lock_crtc(crtc);
if (crtc-primary-fb == NULL) {
/* The framebuffer is currently unbound, presumably
* due to a hotplug event, that userspace has not
@@ -4558,7 +4558,7 @@ out:
drm_framebuffer_unreference(fb);
if (old_fb)
drm_framebuffer_unreference(old_fb);
- drm_modeset_unlock(crtc-mutex);
+ drm_modeset_unlock_crtc(crtc);
return ret;
}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 73e6534fd0aa..4d2aa549c614 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -130,6 +130,90 @@ void drm_modeset_unlock_all(struct drm_device *dev)
EXPORT_SYMBOL(drm_modeset_unlock_all);
/**
+ * drm_modeset_lock_crtc - lock crtc with hidden acquire ctx
+ * @crtc: drm crtc
+ *
+ * This function locks the given crtc using a hidden acquire context. This is
+ * necessary so that drivers internally using the atomic interfaces can grab
+ * furether locks with the lock acquire context.
+ */
+void drm_modeset_lock_crtc(struct drm_crtc *crtc)
+{
+ struct drm_modeset_acquire_ctx *ctx;
+ int ret;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (WARN_ON(!ctx))
+ return;
+
+ drm_modeset_acquire_init(ctx, 0);
+
+retry:
+ ret = drm_modeset_lock(crtc-mutex, ctx);
+ if (ret)
+ goto fail;
+
+ WARN_ON(crtc-acquire_ctx);
+
+ /* now we hold the locks, so now that it is safe, stash the
+* ctx for drm_modeset_unlock_crtc():
+*/
+ crtc-acquire_ctx = ctx;
+
+ return;
+
+fail:
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(ctx);
+ goto retry;
+ }
+}
+EXPORT_SYMBOL(drm_modeset_lock_crtc);
+
+/**
+ * drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls
+ * crtc: drm crtc
+ *
+ * Legacy ioctl operations like cursor updates or page flips only have per-crtc
+ * locking, and store the acquire ctx in the corresponding crtc. All other
+ * legacy operations take all locks and use a global acquire context. This
+ * function grabs the right one.
+ */
+struct drm_modeset_acquire_ctx *
+drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
+{
+ if (crtc-acquire_ctx)
+ return crtc-acquire_ctx;
+
+ WARN_ON(!crtc-dev-mode_config.acquire_ctx);
+
+ return crtc-dev-mode_config.acquire_ctx;
+}
+EXPORT_SYMBOL(drm_modeset_legacy_acquire_ctx);
+
+/**
+ * drm_modeset_unlock_crtc - drop crtc lock
+ * @crtc: drm crtc
+ *
+ * This drops the crtc lock acquire with drm_modeset_lock_crtc() and all other
+ * locks acquired through the hidden context.
+ */
+void drm_modeset_unlock_crtc(struct drm_crtc *crtc)
+{
+ struct drm_modeset_acquire_ctx *ctx =
Re: [Intel-gfx] i915 / 3.15 intermittently boots into blank screeen
On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann j...@hz6.de wrote: Am 18.07.2014 18:25, schrieb Daniel Vetter: On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann j...@hz6.de wrote: Am 18.07.2014 15:27, schrieb Daniel Vetter: On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: I'm experiencing an issue with 3.15.5 on my Lenovo T400: Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but the first mode change doesn't occur, resulting in a black screen with backlight on. The system is entirely unresponsive and I can only press the power button until to switch it off. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. thank you for the feedback. I still have all my custom built kernels, I will test 3.14.0 through 3.14.8 to make sure those were OK and report back. You only need to test 3.14.0, since the backported fixes only contain a very small subset of all patches for 3.15. So it's more efficient to then switch to git bisect between 3.14 and 3.15 directly (after you've confirmed that 3.15.0 is indeed busted). I familiarized with git bisect, that was something I had never used before. I started it with git bisect start v3.15 v3.14 -- drivers/gpu/drm/i915 This lead me to this: cfa7c862982b431add7f2b362526bf31372fc7b0 is the first bad commit commit cfa7c862982b431add7f2b362526bf31372fc7b0 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Apr 29 11:53:58 2014 +0200 drm/i915: Sanitize the enable_ppgtt module option once Otherwise we'll end up spamming dmesg on every context creation on snb with vt-d enabled. This regression was introduced in commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549 Author: Ben Widawsky benjamin.widaw...@intel.com Date: Fri Dec 6 14:11:14 2013 -0800 drm/i915: Reorganize intel_enable_ppgtt As the i915.enable_ppgtt is read-only it cannot be changed after the module is loaded and so we can perform an early sanitization of the values. v2: - Add comment and pimp commit message (Chris) - Use the param consistently (Jani) v3: - Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to gtt_init. Fixes boot hangs on pre-gen6. - Add a debug output for the sanitize ppgtt mode. References: https://lkml.org/lkml/2014/4/17/599 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916 Cc: Alessandro Suardi alessandro.sua...@gmail.com Cc: Ben Widawsky b...@bwidawsk.net Cc: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Jani Nikula jani.nik...@intel.com :04 04 5488e397a1aaa28dca4a252452e9463b0a8f8d10 214c8e98b3c72844e48ab7aef02cba7daf139fab M drivers I realized that the issue does always show, contrary to the subject initially chosen. Unfortunately I can't say anything else, but maybe this will help you experts spot the issue. If I can help more, be it with testing or anything else, just let me know. Hm, I'm not aware of this breaking any gm45 machines, mine here is still happy. Can you please make sure that you don't have any i915 module options set anywhere, either on the kernel cmdline, modeprobe config files in /etc or anywhere else? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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] Displayport compliance testing
2014-07-22 18:11 GMT-03:00 Jesse Barnes jbar...@virtuousgeek.org: On Tue, 22 Jul 2014 22:53:44 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jul 22, 2014 at 10:48 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Are you saying you'll reject this approach entirely? I'm saying that I don't see terrible lot of value in adding a bunch of code for a sticker, and that we should look into making it actually useful by testing the paths that end-users end up using. And we have to keep this working once it's merged. But if it doesn't make sense to make this sticker useful while still being able to get it then I'll reconsider. Yeah I think it depends on the test. We're supposed to go through existing paths for testing e.g. link training with different params (though with a fixed fb and mode), so getting coverage there is something we want regardless. But getting something like probing covered as part of the compliance testing may be something else entirely... I was finally able to take some time to read the spec, and I agree that the hybrid approach looks like the way to go. Some tests require specifically-crafted FBs, while some other tests cause real hotplug events to be sent from the sink. If there's an unknown/unspecified user-space running when the tests are happening, who knows how it is going to react? Of course, for tests that can be implemented directly inside the Kernel still using the standard code paths, we should do it in the Kernel. One possible approach that I thought would be the following: - Each DP encoder provides its own debugfs file for DP test compiance (e.g., /sys/kernel/debug/dri/0/i915_ddi_b_dp_test_compliance). - If the file is not open, any requests for tests that require special actions from our driver - outside of the normal behavior - will be NACKed. - If the file is open, we ACK test requests and print special strings to the debugfs file telling the user-space app what it's supposed to do. We could use simple strings like set the preferred mode, set failsafe mode, set mode using FB test pattern Y, etc. A stringly typed protocol :) - The user-space app needs to be the DRM master, open the debugfs file, parse the operations it prints and act accordingly, and listen to the hotplug events sent by the Kernel. - If some special corner quirky case needs to be done (e.g., train link with a specific number of lanes), the Kernel should store this information at struct intel_dp, and then when a modeset is done on this encoder, we check if the debugfs file is open (i.e., we're doing compliance testing) and then we use the specified configuration. With this, we can probably avoid special uevents or debug-only connector/encoder properties. - The user-space app could be part of intel-gpu-tools. Anyway, this is just an alternate idea to Daniel's suggestion, and many other possible implementation ideas would work for me. Todd, what is your opinion? I will continue the review of the patches we currently have, since it seems we didn't decide what we're gonna merge. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: HDMI pixel replication modes now hactive of 720 for pixel replication
From: Clint Taylor clinton.a.tay...@intel.com
CEA SD interlaced modes use a horizontal 720 pixels that are pixel replicated
to 1440. The current driver reports 1440 pixel to the OS and does not set pixel
replicated modes.
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
drivers/gpu/drm/drm_edid.c| 68 ++---
drivers/gpu/drm/i915/intel_hdmi.c | 13 +++
2 files changed, 47 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dfa9769..5233f4c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -632,26 +632,26 @@ static const struct drm_display_mode edid_cea_modes[] = {
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 6 - 1440x480i@60Hz */
- { DRM_MODE(1440x480i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 6 - 720(1440)x480i@60Hz */
+ { DRM_MODE(720x480i, DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 7 - 1440x480i@60Hz */
- { DRM_MODE(1440x480i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 7 - 720(1440)x480i@60Hz */
+ { DRM_MODE(720x480i, DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 8 - 1440x240@60Hz */
- { DRM_MODE(1440x240, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 8 - 720(1440)x240@60Hz */
+ { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 9 - 1440x240@60Hz */
- { DRM_MODE(1440x240, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ /* 9 - 720(1440)x240@60Hz */
+ { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,
1602, 1716, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
@@ -714,26 +714,26 @@ static const struct drm_display_mode edid_cea_modes[] = {
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 21 - 1440x576i@50Hz */
- { DRM_MODE(1440x576i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 21 - 720(1440)x576i@50Hz */
+ { DRM_MODE(720x576i, DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 22 - 1440x576i@50Hz */
- { DRM_MODE(1440x576i, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 22 - 720(1440)x576i@50Hz */
+ { DRM_MODE(720x576i, DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 23 - 1440x288@50Hz */
- { DRM_MODE(1440x288, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 23 - 720(1440)x288@50Hz */
+ { DRM_MODE(720x288, DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 288, 290, 293, 312, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 24 - 1440x288@50Hz */
- { DRM_MODE(1440x288, DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
+ /* 24 - 720(1440)x288@50Hz */
+ { DRM_MODE(720x288, DRM_MODE_TYPE_DRIVER, 27000, 720, 1464,
1590, 1728, 0, 288, 290, 293, 312, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
@@ -837,17 +837,17 @@ static const struct drm_display_mode edid_cea_modes[] = {
796, 864, 0, 576, 581, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
Re: [Intel-gfx] i915 / 3.15 intermittently boots into blank screeen
Am 29.07.2014 23:35, schrieb Daniel Vetter: On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann j...@hz6.de wrote: Am 18.07.2014 18:25, schrieb Daniel Vetter: On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann j...@hz6.de wrote: Am 18.07.2014 15:27, schrieb Daniel Vetter: On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: I'm experiencing an issue with 3.15.5 on my Lenovo T400: Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but the first mode change doesn't occur, resulting in a black screen with backlight on. The system is entirely unresponsive and I can only press the power button until to switch it off. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. thank you for the feedback. I still have all my custom built kernels, I will test 3.14.0 through 3.14.8 to make sure those were OK and report back. You only need to test 3.14.0, since the backported fixes only contain a very small subset of all patches for 3.15. So it's more efficient to then switch to git bisect between 3.14 and 3.15 directly (after you've confirmed that 3.15.0 is indeed busted). I familiarized with git bisect, that was something I had never used before. I started it with git bisect start v3.15 v3.14 -- drivers/gpu/drm/i915 This lead me to this: cfa7c862982b431add7f2b362526bf31372fc7b0 is the first bad commit commit cfa7c862982b431add7f2b362526bf31372fc7b0 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Apr 29 11:53:58 2014 +0200 drm/i915: Sanitize the enable_ppgtt module option once Otherwise we'll end up spamming dmesg on every context creation on snb with vt-d enabled. This regression was introduced in commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549 Author: Ben Widawsky benjamin.widaw...@intel.com Date: Fri Dec 6 14:11:14 2013 -0800 drm/i915: Reorganize intel_enable_ppgtt As the i915.enable_ppgtt is read-only it cannot be changed after the module is loaded and so we can perform an early sanitization of the values. v2: - Add comment and pimp commit message (Chris) - Use the param consistently (Jani) v3: - Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to gtt_init. Fixes boot hangs on pre-gen6. - Add a debug output for the sanitize ppgtt mode. References: https://lkml.org/lkml/2014/4/17/599 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916 Cc: Alessandro Suardi alessandro.sua...@gmail.com Cc: Ben Widawsky b...@bwidawsk.net Cc: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Jani Nikula jani.nik...@intel.com :04 04 5488e397a1aaa28dca4a252452e9463b0a8f8d10 214c8e98b3c72844e48ab7aef02cba7daf139fab M drivers I realized that the issue does always show, contrary to the subject initially chosen. Unfortunately I can't say anything else, but maybe this will help you experts spot the issue. If I can help more, be it with testing or anything else, just let me know. Hm, I'm not aware of this breaking any gm45 machines, mine here is still happy. Can you please make sure that you don't have any i915 module options set anywhere, either on the kernel cmdline, modeprobe config files in /etc or anywhere else? My kernel cmdline doesn't have anything, but /etc/modprobe.d/i915-kms.conf exists. Its content is this single line: options i915 modeset=1 Can't remember if I created that (it's from 2010) or if it's Debian default... grep -Ri i915 /etc/ doesn't show anything else. grep 915 config-3.15 CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_I915_FBDEV=y # CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set # CONFIG_DRM_I915_UMS is not set CONFIG_SND_HDA_I915=y Would it help if I included the driver instead of building a module? --jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Move BDW workarounds to ring init fn
On 28/07/2014 18:26, Ville Syrjälä wrote: On Mon, Jul 28, 2014 at 05:31:45PM +0100, arun.siluv...@linux.intel.com wrote: From: Arun Siluvery arun.siluv...@linux.intel.com This patch moves BDW workarounds from init_clock_gating() to render ring init fn otherwise they are lost when gpu is reset. In case of execlists, some of the workarounds modify registers that are part of register state context which doesn't get initialized until init_clock_gating(); this results in default context with incorrect values as it is restored and saved before updated by workarounds. I don't think it has to do with execlists. Many of the registers are part of the context image even in ring buffer mode AFAIK. Open issue: For Wa4x4STCOptimizationDisable, we set CACHE_MODE_1[6:6] = 1 At the time when HW contexts are enabled after rings are initialized with default context this workaround is valid but followed by a context switch this is getting reset, please see below log snippet. This is a bit weird. The default context should have restore inhibit==1 so it shouldn't clobber the CACHE_MODE_1 register. There was a specific magic dance you're supposed to do when accessing such registers with mmio, but here we do the write even before the first context switch. Apparently there was some kind of problem with CACHE_MODE_0 on snb too: commit 3a69ddd6f872180b6f61fda87152b37202118fbc Author: Kenneth Graunke kenn...@whitecape.org Date: Fri Apr 27 12:44:41 2012 -0700 drm/i915: Set the Stencil Cache eviction policy to non-LRA mode. but IIRC I wasn't able to reproduce it when I tried. Similar to this register I am also applying this in render ring init fn. Maybe we need to delay these register writes until we've switched to the default context? In its current state (WAs applied in init_clock_gating()) we are writing these registers after switching to default context. When a new hw context is created does all the registers part of context start with default values or they sample the current state? and at what point this sampling takes place? As a test I have updated CACHE_MODE_1 after mi_set_context() then the workaround was valid with every context switch but I think it may not be the right way otherwise we will have to update other WA registers also at this point with every context switch. regards Arun ... [5.978209] [drm:i915_pages_create_for_stolen] offset=0x0, size=8294400 [5.978213] [drm:intel_alloc_plane_obj] plane fb obj 8801472e [5.978215] [drm:i915_gem_setup_global_gtt] reserving preallocated space: 0 + 7e9000 [5.978216] [drm:i915_gem_setup_global_gtt] clearing unused GTT space: [7e9000, f000] [5.979613] [drm:i915_gem_init] CACHE_MODE_1: 0x0180 [5.981372] [drm:gen8_ppgtt_init] Allocated 4 pages for page directories (0 wasted) [5.981373] [drm:gen8_ppgtt_init] Allocated 2048 pages for page tables (0 wasted) [5.981376] [drm:i915_gem_context_init] HW context support initialized [5.981462] [drm:i915_gem_init_hw] CACHE_MODE_1: 0x0180 [5.981467] [drm:i915_gem_init_rings] CACHE_MODE_1: 0x0180 [5.981704] [drm:bdw_init_workarounds] CACHE_MODE_1: 0x01C0 [5.981716] [drm:init_status_page] bsd ring hws offset: 0x0081e000 [5.981792] [drm:init_status_page] blitter ring hws offset: 0x0083f000 [5.981910] [drm:init_status_page] video enhancement ring hws offset: 0x0086 [5.982001] [drm:i915_gem_init_hw] CACHE_MODE_1: 0x01C0 [5.982104] [drm:i915_gem_context_enable] Switch render ring to default_context [5.982106] [drm:i915_gem_render_state_init] render ring: Render state init [5.982120] [drm:do_switch] render ring, CACHE_MODE_1: 0x01C0, uninitialized: 1 [5.982121] [drm:i915_gem_context_enable] Switch bsd ring to default_context [5.982122] [drm:do_switch] bsd ring, CACHE_MODE_1: 0x01C0, uninitialized: 0 [5.982123] [drm:i915_gem_context_enable] Switch blitter ring to default_context [5.982126] [drm:do_switch] blitter ring, CACHE_MODE_1: 0x01C0, uninitialized: 0 [5.982126] [drm:i915_gem_context_enable] Switch video enhancement ring to default_context [5.982128] [drm:do_switch] video enhancement ring, CACHE_MODE_1: 0x01C0, uninitialized: 0 [5.982133] [drm:i915_gem_init] CACHE_MODE_1: 0x01C0 [5.982258] [drm:intel_init_clock_gating] ... [ 10.037019] [drm:do_switch] blitter ring, CACHE_MODE_1: 0x0180, uninitialized: 0 ... [ 10.488145] [drm:do_switch] render ring, CACHE_MODE_1: 0x0180, uninitialized: 0 ... I am currently testing this with an igt which triggers a gpu reset and compares WA register contents before and after reset but the test fails because of this register hence not sending it now. Please let me know how to keep this WA valid after a context switch. Arun Siluvery (1): drm/i915/bdw: Initialize BDW workarounds in render ring init fn drivers/gpu/drm/i915/i915_debugfs.c | 46 ++
