Re: [Intel-gfx] [REGRESSION BISECTED] backlight control stops workin with 3.14 and later
On Sun, 17 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: On 15-8-2014 3:43, Jani Nikula wrote: On Thu, 14 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: Attached is dmesg output from booting kernel 3.14-2 (debian unstable) with drm.debug=0xe and the samsung_laptop module enabled, from my Samsung N150plus netbook. Have you tried 3.15? I've built the v3.15 kernel (using the .config file from debian unstable and doing make oldconfig). The backlight is at maximum brightness after boot and I can't control it using the backlight buttons, nor by writing to /sys/class/backlight/samsung/brightness (say half the value or 1/10th of max_brightness) Backlight does work when writing /sys/class/backlight/intel_backlight/brightness How about disabling samsung backlight module with 3.15? BR, Jani. Kind regards, Bertrik Sikken -- Jani Nikula, 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: Use dev_priv as first argument of for_each_pipe()
On Fri, 15 Aug 2014, Damien Lespiau damien.lesp...@intel.com wrote: Chris has decided that enough is enough. It's time to fixup dev Vs dev_priv and the, oh so awful, INTEL_INFO(). This is a modest contribution to the crusade. -#define for_each_pipe(p) for ((p) = 0; (p) INTEL_INFO(dev)-num_pipes; (p)++) +#define for_each_pipe(dev, p) for ((p) = 0; (p) (dev)-info.num_pipes; (p)++) Naming the first argument dev disagrees with the subject. BR, Jani. -- Jani Nikula, 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/bdw: Disable execlists by default
On Fri, 15 Aug 2014, Damien Lespiau damien.lesp...@intel.com wrote:
We still have a few missing bits and pieces to have execlists enabled by
default eg. the error capture or the render state initialization and so
it wouldn't be wise to enable it by default on BDW just yet.
Also,
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82740
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Thomas Daniel thomas.dan...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 0886aca..139f490 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -35,7 +35,7 @@ struct i915_params i915 __read_mostly = {
.vbt_sdvo_panel_type = -1,
.enable_rc6 = -1,
.enable_fbc = -1,
- .enable_execlists = -1,
+ .enable_execlists = 0,
.enable_hangcheck = true,
.enable_ppgtt = -1,
.enable_psr = 0,
@@ -122,7 +122,7 @@ MODULE_PARM_DESC(enable_ppgtt,
module_param_named(enable_execlists, i915.enable_execlists, int, 0400);
MODULE_PARM_DESC(enable_execlists,
Override execlists usage.
- (-1=auto [default], 0=disabled, 1=enabled));
+ (-1=auto, 0=disabled [default], 1=enabled));
module_param_named(enable_psr, i915.enable_psr, int, 0600);
MODULE_PARM_DESC(enable_psr, Enable PSR (default: false));
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, 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 41/43] drm/i915/bdw: Enable Logical Ring Contexts (hence, Execlists)
On Thu, 24 Jul 2014, Thomas Daniel thomas.dan...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
The time has come, the Walrus said, to talk of many things.
FYI this causes https://bugs.freedesktop.org/show_bug.cgi?id=82740
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b7cf0ec..1ce51d6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2061,7 +2061,7 @@ struct drm_i915_cmd_table {
#define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)-need_gfx_hws)
#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)-gen = 6)
-#define HAS_LOGICAL_RING_CONTEXTS(dev) 0
+#define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)-gen = 8)
#define HAS_ALIASING_PPGTT(dev) (INTEL_INFO(dev)-gen = 6)
#define HAS_PPGTT(dev) (INTEL_INFO(dev)-gen = 7
!IS_GEN8(dev))
#define USES_PPGTT(dev) intel_enable_ppgtt(dev, false)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, 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] How to create PCH to support those existing driver
On 2014/8/18 16:21, Michael S. Tsirkin wrote:
On Mon, Aug 18, 2014 at 11:06:29AM +0800, Chen, Tiejun wrote:
On 2014/8/17 18:32, Michael S. Tsirkin wrote:
On Fri, Aug 15, 2014 at 09:58:40AM +0800, Chen, Tiejun wrote:
Michael and Paolo,
Please re-post discussion on list. These off list ones are just
wasting time since they invariably have to be repeated on list again.
Okay, now just reissue this discussion to all related guys. And do you think
we need to discuss in public, qemu and xen mail list?
Absolutely.
Now -CC qemu, xen and intel-gfx.
If I'm missing someone important please tell me as well.
After I created that new machine specific to IGD passthrough, xenigd, now I
will step next to register the PCH.
IIRC, our complete solution should be as follows:
#1 create a new machine based on piix, xenigd
This is done with Michael help.
#2 register ISA bridge
1 Its still fixed at 1f.0.
2 ISA bridge's vendor_id/device_id should be emulated but then
subsystem_vendor_id = PCI_VENDOR_ID_XEN;
subsystem_device_id = ISA Bridge's real device id
This mean we need to change driver to walk with this way.
For example, in
case of Linux native driver,
intel_detect_pch()
{
...
if (pch-subsystem_vendor == PCI_VENDOR_ID_XEN)
id = pch-subsystem_device INTEL_PCH_DEVICE_ID_MASK;
Then driver can get that real device id by 'subsystem_device', right?
This is fine now but how to support those existing drivers which are just
Here correct one point, we don't need to care about supporting the legacy
driver since the legacy driver still should work qemu-traditional. So we
just make sure the existing driver with this subsystem_id way can support
those existing and legacy platform.
Now this is clear to me.
dependent on checking real vendor_id/device_id directly,
if (pch-vendor == PCI_VENDOR_ID_INTEL) {
unsigned short id = pch-device INTEL_PCH_DEVICE_ID_MASK
Maybe I'm missing something, please hint me.
Thanks
Tiejun
The subsystem id was just one idea.
But from that email thread, RH / Intel Virtualization Engineering Meeting -
Minutes 7/10, I didn't see other idea we should prefer currently.
What was finally agreed for future drivers is that guests will get all
information they need from the video card, this ID hack was needed only
for very old legacy devices.
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258
So this is for newer guests, they will work without need
for hacks, like any other device.
Actually we had a meeting to discuss our future solution, but seems you were
on vacation at that moment :)
In that meeting we had an agreement between us and some upstream guys.
We will have such a PCI capability structure in this PCI device to represent
all information in the future. This make sens to Intel as well.
Maybe Allen or Paolo known more details.
But obviously this a long-term solution, so currently we will work with this
subsystem_id way temporarily. And this way is accepted by those guys in the
meeting.
I don't see the point really. If you are modifying the driver,
Yes, we need to modify something in the driver.
why not modify it to its final form.
What's your final form?
As I track that email thread, seems the follows is just a way you guys
achieve a better agreement.
why not set the subsys vid to the RH/Quamranet/Virtio VID, so it's
obvious for the use-match?
That's exactly the suggestion. Though upstream they might be using the
XenSource id since the patches were for Xen.
Paolo
Or I'm missing something?
Thanks
Tiejun
For existing drivers: Vendor ID is intel anyway.
Yes.
For device ID, override it through a property
or something. But I think poking at the real host from
qemu is a mistake though, host is not
protected by iommu.
Two possible suggestions were to reverse-detect
id of the device from the card that is assigned,
I guess you're saying pci_get_device(vendor/devices_ids), right?
or just make it a user property, and move the smarts
to management.
Sorry could you elaborate this way in detail?
Thanks
Tiejun
Will do but let's do it on the mailing list.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Program PFI credits for VLV
Hi Ville,
Apologize for the delay in reply.
For your inputs on the programming side (modeset global resources
handling and self documenting code parts), I agree with you and will
make the changes.
For opens related to info on the feature, internal discussions are
ongoing. I will get back to you on them next week..
Thanks,
Vandana
On Aug-08-2014 6:33 PM, Ville Syrjälä wrote:
On Thu, Aug 07, 2014 at 06:40:03PM +0530, Vandana Kannan wrote:
From: Vidya Srinivas vidya.srini...@intel.com
PFI credit programming is required when CD clock (related to data flow from
display pipeline to end display) is greater than CZ clock (related to data
flow from memory to display plane). This programming should be done when all
planes are OFF to avoid intermittent hangs while accessing memory even from
different Gfx units (not just display).
If cdclk/czclk =1, PFI credits could be set as any number. To get better
performance, larger PFI credit can be assigned to PND. Otherwise if
cdclk/czclk1, the default PFI credit of 8 should be set.
Do we have any docs for this? I see the register in the docs but nothing
about the correct programming. Some kind of refrence to the used
documentation would be nice.
v2:
- Change log to lower log level instead of DRM_ERROR
- Change function name to valleyview_program_pfi_credits
- Move program PFI credits to modeset_init instead of intel_set_mode
- Change magic numbers to logical constants
Signed-off-by: Vidya Srinivas vidya.srini...@intel.com
Signed-off-by: Gajanan Bhat gajanan.b...@intel.com
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_display.c | 4 +++-
drivers/gpu/drm/i915/intel_pm.c | 22 ++
5 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 6c4b25c..00e0b4a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -558,6 +558,9 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED);
console_unlock();
+if (IS_VALLEYVIEW(dev))
+valleyview_program_pfi_credits(dev_priv, false);
If we want to do this for system suspend I think we should stick it
into i915_drm_freeze() (just after turning off the pipes). Not sure if
we should also force cdclk to minimum there...
Hmm. Is the GCI_CONTROL register is part of the disp2d power well? If it
is we probably need to enable the power well around the register write.
+
dev_priv-suspend_count++;
intel_display_set_init_power(dev_priv, false);
@@ -693,6 +696,9 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
dev_priv-modeset_restore = MODESET_DONE;
mutex_unlock(dev_priv-modeset_restore_lock);
+if (IS_VALLEYVIEW(dev))
+valleyview_program_pfi_credits(dev_priv, true);
I think this thing can be dropped. We need to do the reprogramming as
part of the modeset global resources handling.
+
intel_opregion_notify_adapter(dev, PCI_D0);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 881e0a6..88fd4c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2172,6 +2172,8 @@ extern struct i915_params i915 __read_mostly;
/* i915_dma.c */
void i915_update_dri1_breadcrumb(struct drm_device *dev);
+extern void valleyview_program_pfi_credits(struct drm_i915_private
*dev_priv,
+ bool flag);
extern void i915_kernel_lost_context(struct drm_device * dev);
extern int i915_driver_load(struct drm_device *, unsigned long flags);
extern int i915_driver_unload(struct drm_device *);
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index fb111cd..7f4c2f5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1937,6 +1937,11 @@ enum punit_power_well {
#define CZCLK_FREQ_MASK 0xf
#define GMBUSFREQ_VLV (VLV_DISPLAY_BASE + 0x6510)
+#define GCI_CONTROL (VLV_DISPLAY_BASE + 0x650C)
+#define PFI_CREDIT(7 28)
Maybe something like this for a bit more self documenting code.
#define PFI_CREDIT(x) (((x)-8) 28) /* 8-15 */
+#define PFI_CREDIT_RESEND (1 27)
+#define VGA_FAST_MODE_DISABLE (1 14)
+
/*
* Palette regs
*/
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2089319..2af2e60 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12691,8 +12691,10 @@ void intel_modeset_init_hw(struct drm_device *dev)
{
Re: [Intel-gfx] How to create PCH to support those existing driver
On Mon, Aug 18, 2014 at 05:01:25PM +0800, Chen, Tiejun wrote:
On 2014/8/18 16:21, Michael S. Tsirkin wrote:
On Mon, Aug 18, 2014 at 11:06:29AM +0800, Chen, Tiejun wrote:
On 2014/8/17 18:32, Michael S. Tsirkin wrote:
On Fri, Aug 15, 2014 at 09:58:40AM +0800, Chen, Tiejun wrote:
Michael and Paolo,
Please re-post discussion on list. These off list ones are just
wasting time since they invariably have to be repeated on list again.
Okay, now just reissue this discussion to all related guys. And do you think
we need to discuss in public, qemu and xen mail list?
Absolutely.
Now -CC qemu, xen and intel-gfx.
If I'm missing someone important please tell me as well.
After I created that new machine specific to IGD passthrough, xenigd, now
I
will step next to register the PCH.
IIRC, our complete solution should be as follows:
#1 create a new machine based on piix, xenigd
This is done with Michael help.
#2 register ISA bridge
1 Its still fixed at 1f.0.
2 ISA bridge's vendor_id/device_id should be emulated but then
subsystem_vendor_id = PCI_VENDOR_ID_XEN;
subsystem_device_id = ISA Bridge's real device id
This mean we need to change driver to walk with this way.
For example, in
case of Linux native driver,
intel_detect_pch()
{
...
if (pch-subsystem_vendor == PCI_VENDOR_ID_XEN)
id = pch-subsystem_device INTEL_PCH_DEVICE_ID_MASK;
Then driver can get that real device id by 'subsystem_device', right?
This is fine now but how to support those existing drivers which are just
Here correct one point, we don't need to care about supporting the legacy
driver since the legacy driver still should work qemu-traditional. So we
just make sure the existing driver with this subsystem_id way can support
those existing and legacy platform.
Now this is clear to me.
dependent on checking real vendor_id/device_id directly,
if (pch-vendor == PCI_VENDOR_ID_INTEL) {
unsigned short id = pch-device INTEL_PCH_DEVICE_ID_MASK
Maybe I'm missing something, please hint me.
Thanks
Tiejun
The subsystem id was just one idea.
But from that email thread, RH / Intel Virtualization Engineering Meeting -
Minutes 7/10, I didn't see other idea we should prefer currently.
What was finally agreed for future drivers is that guests will get all
information they need from the video card, this ID hack was needed only
for very old legacy devices.
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258
So this is for newer guests, they will work without need
for hacks, like any other device.
Actually we had a meeting to discuss our future solution, but seems you were
on vacation at that moment :)
In that meeting we had an agreement between us and some upstream guys.
We will have such a PCI capability structure in this PCI device to represent
all information in the future. This make sens to Intel as well.
Maybe Allen or Paolo known more details.
But obviously this a long-term solution, so currently we will work with this
subsystem_id way temporarily. And this way is accepted by those guys in the
meeting.
I don't see the point really. If you are modifying the driver,
Yes, we need to modify something in the driver.
why not modify it to its final form.
What's your final form?
Avoid poking at other devices besides the passed through card.
Get everything from BAR and other registers of the card.
As I track that email thread, seems the follows is just a way you guys
achieve a better agreement.
why not set the subsys vid to the RH/Quamranet/Virtio VID, so it's
obvious for the use-match?
That's exactly the suggestion. Though upstream they might be using the
XenSource id since the patches were for Xen.
Paolo
Or I'm missing something?
Thanks
Tiejun
I thought the point of this work is to make existing
linux/windows drivers work. Is it or isn't it?
Wrt changing drivers, change them to behave sanely, like all other
drivers, and avoid poking at the chipset.
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258
Seems to suggest one way to do this.
Can what is suggested there work for existing devices?
For existing drivers: Vendor ID is intel anyway.
Yes.
For device ID, override it through a property
or something. But I think poking at the real host from
qemu is a mistake though, host is not
protected by iommu.
Two possible suggestions were to reverse-detect
id of the device from the card that is assigned,
I guess you're saying pci_get_device(vendor/devices_ids), right?
or just make it a user property, and move the smarts
to management.
Sorry could you elaborate this way in detail?
Thanks
Tiejun
Will do but let's do it on the mailing list.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use dev_priv as first argument of for_each_pipe()
Chris has decided that enough is enough. It's time to fixup dev Vs
dev_priv. This is a modest contribution to the crusade.
v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode
the info struct with defines (Chris)
Rename the macro argument from 'dev' to 'dev_priv' (Jani)
Suggested-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
drivers/gpu/drm/i915/i915_dma.c | 4 +--
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/i915_irq.c | 65 ++--
drivers/gpu/drm/i915/intel_display.c | 16 +
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_panel.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 17 +-
8 files changed, 60 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6c82bda..637143c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -662,7 +662,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
I915_READ(VLV_IIR_RW));
seq_printf(m, Display IMR:\t%08x\n,
I915_READ(VLV_IMR));
- for_each_pipe(pipe)
+ for_each_pipe(dev_priv, pipe)
seq_printf(m, Pipe %c stat:\t%08x\n,
pipe_name(pipe),
I915_READ(PIPESTAT(pipe)));
@@ -702,7 +702,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
i, I915_READ(GEN8_GT_IER(i)));
}
- for_each_pipe(pipe) {
+ for_each_pipe(dev_priv, pipe) {
if (!intel_display_power_enabled(dev_priv,
POWER_DOMAIN_PIPE(pipe))) {
seq_printf(m, Pipe %c power disabled\n,
@@ -749,7 +749,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
I915_READ(VLV_IIR_RW));
seq_printf(m, Display IMR:\t%08x\n,
I915_READ(VLV_IMR));
- for_each_pipe(pipe)
+ for_each_pipe(dev_priv, pipe)
seq_printf(m, Pipe %c stat:\t%08x\n,
pipe_name(pipe),
I915_READ(PIPESTAT(pipe)));
@@ -785,7 +785,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
I915_READ(IIR));
seq_printf(m, Interrupt mask: %08x\n,
I915_READ(IMR));
- for_each_pipe(pipe)
+ for_each_pipe(dev_priv, pipe)
seq_printf(m, Pipe %c stat: %08x\n,
pipe_name(pipe),
I915_READ(PIPESTAT(pipe)));
@@ -4178,7 +4178,7 @@ void intel_display_crc_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
enum pipe pipe;
- for_each_pipe(pipe) {
+ for_each_pipe(dev_priv, pipe) {
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
pipe_crc-opened = false;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3f676f9..f19dbff 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1528,10 +1528,10 @@ static void intel_device_info_runtime_init(struct
drm_device *dev)
info = (struct intel_device_info *)dev_priv-info;
if (IS_VALLEYVIEW(dev))
- for_each_pipe(pipe)
+ for_each_pipe(dev_priv, pipe)
info-num_sprites[pipe] = 2;
else
- for_each_pipe(pipe)
+ for_each_pipe(dev_priv, pipe)
info-num_sprites[pipe] = 1;
if (i915.disable_display) {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4754328..719c7c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -163,7 +163,8 @@ enum hpd_pin {
I915_GEM_DOMAIN_INSTRUCTION | \
I915_GEM_DOMAIN_VERTEX)
-#define for_each_pipe(p) for ((p) = 0; (p) INTEL_INFO(dev)-num_pipes; (p)++)
+#define for_each_pipe(dev_priv, p) \
+ for ((p) = 0; (p) INTEL_INFO(dev_priv)-num_pipes; (p)++)
#define for_each_sprite(p, s) for ((s) = 0; (s)
INTEL_INFO(dev)-num_sprites[(p)]; (s)++)
#define for_each_crtc(dev, crtc) \
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6b6fff1..06bb8cd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -238,7 +238,7 @@ static bool ivb_can_enable_err_int(struct drm_device *dev)
Re: [Intel-gfx] [PATCH] drm/i915: Use dev_priv as first argument of for_each_pipe()
On Mon, Aug 18, 2014 at 11:00:42AM +0100, Damien Lespiau wrote: Chris has decided that enough is enough. It's time to fixup dev Vs dev_priv. This is a modest contribution to the crusade. v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode the info struct with defines (Chris) Rename the macro argument from 'dev' to 'dev_priv' (Jani) If you want to be pedantic, don't use a macro name that is often a variable name. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix suspend/resume for GENs w/o runtime PM support
Before sharing common parts between the system and runtime s/r
handlers we WARNed if the runtime s/r handlers were called on GENs that
didn't support RPM. But this WARN is not correct if the same handler is
called from the system s/r path, since that can happen on any platform.
This also broke system s/r on old platforms.
The issue was introduced in
commit 016970beb05da6285c2f3ed2bee1c676cb75972e
Author: Sagar Kamble sagar.a.kam...@intel.com
Date: Wed Aug 13 23:07:06 2014 +0530
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82751
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 117f5c1..f646f34 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -499,7 +499,8 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
}
-static int intel_suspend_complete(struct drm_i915_private *dev_priv);
+static int intel_suspend_complete(struct drm_i915_private *dev_priv,
+ bool rpm_suspend);
static int intel_resume_prepare(struct drm_i915_private *dev_priv,
bool rpm_resume);
@@ -909,7 +910,7 @@ static int i915_pm_suspend_late(struct device *dev)
if (drm_dev-switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
- ret = intel_suspend_complete(dev_priv);
+ ret = intel_suspend_complete(dev_priv, false);
if (ret)
DRM_ERROR(Suspend complete failed: %d\n, ret);
@@ -1410,7 +1411,7 @@ static int intel_runtime_suspend(struct device *device)
cancel_work_sync(dev_priv-rps.work);
intel_runtime_pm_disable_interrupts(dev);
- ret = intel_suspend_complete(dev_priv);
+ ret = intel_suspend_complete(dev_priv, true);
if (ret) {
DRM_ERROR(Runtime suspend failed, disabling it (%d)\n, ret);
intel_runtime_pm_restore_interrupts(dev);
@@ -1471,10 +1472,11 @@ static int intel_runtime_resume(struct device *device)
* This function implements common functionality of runtime and system
* suspend sequence.
*/
-static int intel_suspend_complete(struct drm_i915_private *dev_priv)
+static int intel_suspend_complete(struct drm_i915_private *dev_priv,
+ bool rpm_suspend)
{
struct drm_device *dev = dev_priv-dev;
- int ret;
+ int ret = 0;
if (IS_GEN6(dev)) {
ret = 0;
@@ -1482,7 +1484,7 @@ static int intel_suspend_complete(struct drm_i915_private
*dev_priv)
ret = hsw_suspend_complete(dev_priv);
} else if (IS_VALLEYVIEW(dev)) {
ret = vlv_suspend_complete(dev_priv);
- } else {
+ } else if (rpm_suspend) {
ret = -ENODEV;
WARN_ON(1);
}
@@ -1499,7 +1501,7 @@ static int intel_resume_prepare(struct drm_i915_private
*dev_priv,
bool rpm_resume)
{
struct drm_device *dev = dev_priv-dev;
- int ret;
+ int ret = 0;
if (IS_GEN6(dev)) {
ret = snb_resume_prepare(dev_priv, rpm_resume);
@@ -1507,7 +1509,7 @@ static int intel_resume_prepare(struct drm_i915_private
*dev_priv,
ret = hsw_resume_prepare(dev_priv, rpm_resume);
} else if (IS_VALLEYVIEW(dev)) {
ret = vlv_resume_prepare(dev_priv, rpm_resume);
- } else {
+ } else if (rpm_resume) {
WARN_ON(1);
ret = -ENODEV;
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Usage of _PAGE_PCD et al in i915 driver
On Mon, Aug 18, 2014 at 07:31:58AM +0200, Juergen Gross wrote: On 08/15/2014 12:21 PM, Ville Syrjälä wrote: On Thu, Aug 14, 2014 at 05:55:11AM +0200, Juergen Gross wrote: On 08/13/2014 05:07 PM, Jesse Barnes wrote: On Fri, 8 Aug 2014 15:14:15 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: Adding relevant mailing lists. On Fri, Aug 8, 2014 at 1:23 PM, Juergen Gross jgr...@suse.com wrote: I'm just about to create a patch for full PAT support in the Linux kernel, including Xen. For this purpose I introduce a translation between cache modes and pte bits. Scanning the kernel sources for usage of the cache mode bits in the pte I discovered drivers/gpu/drm/i915/i915_gem_gtt.h is using _PAGE_PCD, _PAGE_PWT and _PAGE_PAT. I think those defines are used to create ptes not for usage by the main processor, but for the graphics processor. Is this true? In this case I'd suggest to define i915-specific macros instead of using the x86 ones. Yeah, those are gpu specific PAT tables, but the hw engineers specifically designed this to match, and we've tried to follow the cpu side to match it. Especially in the future that will be somewhat important, since we want to fully share the entire address space between cpu and gpu on the next platform. Jesse is working on that. Right, we have an x86 compatible MMU in the GPU itself, so re-using the defines makes sense. I suppose with your work you'll move them and make them a bit more opaque? If so, we'll still want a way to get at them directly, or access your mapping functions for generating PTE bits for the GPU MMU. Using the mapping functions I'm introducing should work, if the MMU has an x86 compatible MSR_IA32_CR_PAT which is configured the same way as on the x86 processor (be aware that Xen is using another MSR_IA32_CR_PAT setting as the Linux kernel). We have a PAT that is structured the same way as the x86 PAT. But the contents of the PAT entries are obviously specific to the GPU so it's not identical. But the pcd/pwt/pat bits index the PAT in exactly the same way as on x86. See bdw_setup_private_ppat() and chv_setup_private_ppat() for how we set up the PAT. So you are using the PAT bit in the ptes, but the semantic for the GPU will be different as for the x86 processor, because the GPU PAT is set up differently from the x86 one. In case you are sharing ptes between GPU and x86 processor in future, this might lead to problems when the x86 processor will use ptes with the PAT bit set. I'm not sure why you single out the PAT bit. It's just another index bit like PCD and PWT. Currently we play around with the GPU caching mode rather freely because the hardware is already fully coherent wrt. CPU caches (well, apart from display scanout which knows nothing about any caches). What we do currently is leave all the CPU mappings as WB and just change the GPU caching mode depending on the need. However once we share the page tables I'm not sure what's the plan wrt. changing the caching mode for GPU buffers since that would involve changing the CPU cachine mode as well, and we may still want finer granularity control over the various GPU caches. Maybe we need to reserve some PAT entries for GPU specific purposes so that the CPU might have no difference between two PAT entries but the GPU would. But I'm not sure there are any extra PAT entries left which could be reserved for such things. We do have ways to override the GPU caching mode using inline information in the GPU command buffers though, so in theory at least, it doesn't matter all that much to the GPU how the page table caching bits are configured. However not all commands may have such inline caching information, and we still have the display scanout to worry about which still relies on the page tables to avoid expensive manual clflushes. -- 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 i-g-t 1/1] tests: Fix seg fault when gem_mmap is run without specifying a subtest
On 15 August 2014 22:08, Mason, Michael W michael.w.ma...@intel.com wrote:
From: Mike Mason michael.w.ma...@intel.com
This patch and the previous one (scripts: Allow multiple -t and -x
regular expressions for run-tests.sh) look fine, but they don't apply
because tabs have been converted to spaces. Can you check and re-send
with this fixed?
gem_mmap seg faults when all tests are run together. This occurs because
the new-object subtest closes the gem object, but short-mmap assumes
it still exists. Thus gem_mmap__cpu() returns nil for addr and memset()
seg faults. This patch makes new-object and short-mmap create and
close their own gem objects.
Signed-off-by: Mike Mason michael.w.ma...@intel.com
---
tests/gem_mmap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/gem_mmap.c b/tests/gem_mmap.c
index 334bd76..33ffe45 100644
--- a/tests/gem_mmap.c
+++ b/tests/gem_mmap.c
@@ -62,10 +62,8 @@ igt_main
igt_assert(ret == -1 errno == ENOENT);
}
- igt_fixture
- handle = gem_create(fd, OBJECT_SIZE);
-
igt_subtest(new-object) {
+ handle = gem_create(fd, OBJECT_SIZE);
arg.handle = handle;
arg.offset = 0;
arg.size = OBJECT_SIZE;
@@ -94,9 +92,11 @@ igt_main
igt_subtest(short-mmap) {
igt_assert(OBJECT_SIZE 4096);
+ handle = gem_create(fd, OBJECT_SIZE);
addr = gem_mmap__cpu(fd, handle, 4096, PROT_WRITE);
memset(addr, 0, 4096);
munmap(addr, 4096);
+ gem_close(fd, handle);
}
igt_fixture
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix HPD IRQ reenable work cancelation
On Fri, 15 Aug 2014, Imre Deak imre.d...@intel.com wrote: On Fri, 2014-08-15 at 12:48 +0300, Jani Nikula wrote: On Fri, 15 Aug 2014, Imre Deak imre.d...@intel.com wrote: On Wed, 2014-08-13 at 19:33 +0300, Ville Syrjälä wrote: The series seems fine to me. Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com for the rest as well. Thanks, I assume it's for v2. I'd say this is for -fixes. The problem existed even in 3.16, but only the MST support made it apparent with the extra HPD signaling and DP AUX activity during suspend. The series no longer applies on any branch. Would you mind respinning on -fixes please? Ok. I just noticed that it depends on the following two patches that are only in -nightly not in -fixes: drm/i915: Introduce a for_each_intel_encoder() macro drm/i915: lock around link status and link training. Are you going to apply these? The second one is definitely needed in -fixes imo. I've rebased -fixes on top of 3.17-rc1, so the second patch is there now. However patch 3 still doesn't apply. Also, if we're going to queue these for stable to fix 3.16, it's easier if we don't depend on for_each_intel_encoder. Could you rebase this on -fixes now please? Thanks, Jani. -- Jani Nikula, 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] Usage of _PAGE_PCD et al in i915 driver
On 08/18/2014 12:21 PM, Ville Syrjälä wrote: On Mon, Aug 18, 2014 at 07:31:58AM +0200, Juergen Gross wrote: On 08/15/2014 12:21 PM, Ville Syrjälä wrote: On Thu, Aug 14, 2014 at 05:55:11AM +0200, Juergen Gross wrote: On 08/13/2014 05:07 PM, Jesse Barnes wrote: On Fri, 8 Aug 2014 15:14:15 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: Adding relevant mailing lists. On Fri, Aug 8, 2014 at 1:23 PM, Juergen Gross jgr...@suse.com wrote: I'm just about to create a patch for full PAT support in the Linux kernel, including Xen. For this purpose I introduce a translation between cache modes and pte bits. Scanning the kernel sources for usage of the cache mode bits in the pte I discovered drivers/gpu/drm/i915/i915_gem_gtt.h is using _PAGE_PCD, _PAGE_PWT and _PAGE_PAT. I think those defines are used to create ptes not for usage by the main processor, but for the graphics processor. Is this true? In this case I'd suggest to define i915-specific macros instead of using the x86 ones. Yeah, those are gpu specific PAT tables, but the hw engineers specifically designed this to match, and we've tried to follow the cpu side to match it. Especially in the future that will be somewhat important, since we want to fully share the entire address space between cpu and gpu on the next platform. Jesse is working on that. Right, we have an x86 compatible MMU in the GPU itself, so re-using the defines makes sense. I suppose with your work you'll move them and make them a bit more opaque? If so, we'll still want a way to get at them directly, or access your mapping functions for generating PTE bits for the GPU MMU. Using the mapping functions I'm introducing should work, if the MMU has an x86 compatible MSR_IA32_CR_PAT which is configured the same way as on the x86 processor (be aware that Xen is using another MSR_IA32_CR_PAT setting as the Linux kernel). We have a PAT that is structured the same way as the x86 PAT. But the contents of the PAT entries are obviously specific to the GPU so it's not identical. But the pcd/pwt/pat bits index the PAT in exactly the same way as on x86. See bdw_setup_private_ppat() and chv_setup_private_ppat() for how we set up the PAT. So you are using the PAT bit in the ptes, but the semantic for the GPU will be different as for the x86 processor, because the GPU PAT is set up differently from the x86 one. In case you are sharing ptes between GPU and x86 processor in future, this might lead to problems when the x86 processor will use ptes with the PAT bit set. I'm not sure why you single out the PAT bit. It's just another index bit like PCD and PWT. I single out the PAT bit because all entries of CPU PAT-register and GPU PAT-register differ with PAT==1. With PAT==0 they are configured to have the same semantics. Currently we play around with the GPU caching mode rather freely because the hardware is already fully coherent wrt. CPU caches (well, apart from display scanout which knows nothing about any caches). What we do currently is leave all the CPU mappings as WB and just change the GPU caching mode depending on the need. The Xen hypervisor is already using a different PAT configuration than then Linux Kernel. So your approach could break Xen when sharing the page tables between CPU and GPU. However once we share the page tables I'm not sure what's the plan wrt. changing the caching mode for GPU buffers since that would involve changing the CPU cachine mode as well, and we may still want finer granularity control over the various GPU caches. Maybe we need to reserve some PAT entries for GPU specific purposes so that the CPU might have no difference between two PAT entries but the GPU would. But I'm not sure there are any extra PAT entries left which could be reserved for such things. There should be 2 entries left in the PAT-register which could be used by the GPU, I think: there are only 6 different cache modes defined for x86 and we have 8 PAT register entries, so at least 2 entries must be duplicates. We do have ways to override the GPU caching mode using inline information in the GPU command buffers though, so in theory at least, it doesn't matter all that much to the GPU how the page table caching bits are configured. However not all commands may have such inline caching information, and we still have the display scanout to worry about which still relies on the page tables to avoid expensive manual clflushes. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915: Populate mem_freq in init_gt_powerwave()
From: Ville Syrjälä ville.syrj...@linux.intel.com
init_clock_gating() is too late to read out the mem_freq. We already
want to print out the GPU MHz numbers before it's called. Move the
mem_freq setup to init_gt_powersave().
v2: Also kill the CHV_CZ_CLOCK_FREQ_MODE_* defines
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 6 ---
drivers/gpu/drm/i915/intel_pm.c | 90 -
2 files changed, 43 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 203062e..2df946d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5650,12 +5650,6 @@ enum punit_power_well {
GEN6_PM_RP_DOWN_THRESHOLD | \
GEN6_PM_RP_DOWN_TIMEOUT)
-#define CHV_CZ_CLOCK_FREQ_MODE_200 200
-#define CHV_CZ_CLOCK_FREQ_MODE_267 267
-#define CHV_CZ_CLOCK_FREQ_MODE_320 320
-#define CHV_CZ_CLOCK_FREQ_MODE_333 333
-#define CHV_CZ_CLOCK_FREQ_MODE_400 400
-
#define GEN7_GT_SCRATCH_BASE 0x4F100
#define GEN7_GT_SCRATCH_REG_NUM8
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c84ad93..39dd066 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4088,11 +4088,27 @@ static void valleyview_cleanup_pctx(struct drm_device
*dev)
static void valleyview_init_gt_powersave(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 val;
valleyview_setup_pctx(dev);
mutex_lock(dev_priv-rps.hw_lock);
+ val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
+ switch ((val 6) 3) {
+ case 0:
+ case 1:
+ dev_priv-mem_freq = 800;
+ break;
+ case 2:
+ dev_priv-mem_freq = 1066;
+ break;
+ case 3:
+ dev_priv-mem_freq = 1333;
+ break;
+ }
+ DRM_DEBUG_DRIVER(DDR speed: %d MHz, dev_priv-mem_freq);
+
dev_priv-rps.max_freq = valleyview_rps_max_freq(dev_priv);
dev_priv-rps.rp0_freq = dev_priv-rps.max_freq;
DRM_DEBUG_DRIVER(max GPU freq: %d MHz (%u)\n,
@@ -4127,11 +4143,38 @@ static void valleyview_init_gt_powersave(struct
drm_device *dev)
static void cherryview_init_gt_powersave(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 val;
cherryview_setup_pctx(dev);
mutex_lock(dev_priv-rps.hw_lock);
+ val = vlv_punit_read(dev_priv, CCK_FUSE_REG);
+ switch ((val 2) 0x7) {
+ case 0:
+ case 1:
+ dev_priv-rps.cz_freq = 200;
+ dev_priv-mem_freq = 1600;
+ break;
+ case 2:
+ dev_priv-rps.cz_freq = 267;
+ dev_priv-mem_freq = 1600;
+ break;
+ case 3:
+ dev_priv-rps.cz_freq = 333;
+ dev_priv-mem_freq = 2000;
+ break;
+ case 4:
+ dev_priv-rps.cz_freq = 320;
+ dev_priv-mem_freq = 1600;
+ break;
+ case 5:
+ dev_priv-rps.cz_freq = 400;
+ dev_priv-mem_freq = 1600;
+ break;
+ }
+ DRM_DEBUG_DRIVER(DDR speed: %d MHz, dev_priv-mem_freq);
+
dev_priv-rps.max_freq = cherryview_rps_max_freq(dev_priv);
dev_priv-rps.rp0_freq = dev_priv-rps.max_freq;
DRM_DEBUG_DRIVER(max GPU freq: %d MHz (%u)\n,
@@ -5760,24 +5803,6 @@ static void ivybridge_init_clock_gating(struct
drm_device *dev)
static void valleyview_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 val;
-
- mutex_lock(dev_priv-rps.hw_lock);
- val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
- mutex_unlock(dev_priv-rps.hw_lock);
- switch ((val 6) 3) {
- case 0:
- case 1:
- dev_priv-mem_freq = 800;
- break;
- case 2:
- dev_priv-mem_freq = 1066;
- break;
- case 3:
- dev_priv-mem_freq = 1333;
- break;
- }
- DRM_DEBUG_DRIVER(DDR speed: %d MHz, dev_priv-mem_freq);
I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
@@ -5853,35 +5878,6 @@ static void valleyview_init_clock_gating(struct
drm_device *dev)
static void cherryview_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 val;
-
- mutex_lock(dev_priv-rps.hw_lock);
- val = vlv_punit_read(dev_priv, CCK_FUSE_REG);
- mutex_unlock(dev_priv-rps.hw_lock);
- switch ((val 2) 0x7) {
- case 0:
- case 1:
-
[Intel-gfx] [PATCH 3/4] drm/i915: Make sure hardware uses the correct swing margin/deemph bits on chv
From: Ville Syrjälä ville.syrj...@linux.intel.com
The register can house two different swing marging/deemph settings at
once. However only one gets used based on some other bits. Make sure we
set those bits correctly to make the hardware use the settings we
provided.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 19 +++
drivers/gpu/drm/i915/intel_dp.c | 14 ++
drivers/gpu/drm/i915/intel_hdmi.c | 14 ++
3 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2df946d..b8e8d33 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -824,12 +824,31 @@ enum punit_power_well {
#define _VLV_PCS_DW9_CH0 0x8224
#define _VLV_PCS_DW9_CH1 0x8424
+#define DPIO_PCS_TX2MARGIN_MASK (0x713)
+#define DPIO_PCS_TX2MARGIN_000 (013)
+#define DPIO_PCS_TX2MARGIN_101 (113)
+#define DPIO_PCS_TX1MARGIN_MASK (0x710)
+#define DPIO_PCS_TX1MARGIN_000 (010)
+#define DPIO_PCS_TX1MARGIN_101 (110)
#defineVLV_PCS_DW9(ch) _PORT(ch, _VLV_PCS_DW9_CH0, _VLV_PCS_DW9_CH1)
+#define _VLV_PCS01_DW9_CH0 0x224
+#define _VLV_PCS23_DW9_CH0 0x424
+#define _VLV_PCS01_DW9_CH1 0x2624
+#define _VLV_PCS23_DW9_CH1 0x2824
+#define VLV_PCS01_DW9(ch) _PORT(ch, _VLV_PCS01_DW9_CH0, _VLV_PCS01_DW9_CH1)
+#define VLV_PCS23_DW9(ch) _PORT(ch, _VLV_PCS23_DW9_CH0, _VLV_PCS23_DW9_CH1)
+
#define _CHV_PCS_DW10_CH0 0x8228
#define _CHV_PCS_DW10_CH1 0x8428
#define DPIO_PCS_SWING_CALC_TX0_TX2 (130)
#define DPIO_PCS_SWING_CALC_TX1_TX3 (131)
+#define DPIO_PCS_TX2DEEMP_MASK (0xf24)
+#define DPIO_PCS_TX2DEEMP_9P5(024)
+#define DPIO_PCS_TX2DEEMP_6P0(224)
+#define DPIO_PCS_TX1DEEMP_MASK (0xf16)
+#define DPIO_PCS_TX1DEEMP_9P5(016)
+#define DPIO_PCS_TX1DEEMP_6P0(216)
#define CHV_PCS_DW10(ch) _PORT(ch, _CHV_PCS_DW10_CH0, _CHV_PCS_DW10_CH1)
#define _VLV_PCS01_DW10_CH00x0228
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e5ada4f..f8e4578 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2632,12 +2632,26 @@ static uint32_t intel_chv_signal_levels(struct intel_dp
*intel_dp)
/* Clear calc init */
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
val = ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
+ val = ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
+ val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
val = ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
+ val = ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
+ val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW9(ch));
+ val = ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
+ val |= DPIO_PCS_TX1MARGIN_000 | DPIO_PCS_TX2MARGIN_000;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW9(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW9(ch));
+ val = ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
+ val |= DPIO_PCS_TX1MARGIN_000 | DPIO_PCS_TX2MARGIN_000;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW9(ch), val);
+
/* Program swing deemph */
for (i = 0; i 4; i++) {
val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW4(ch, i));
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9169786..f3bf0c7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1414,12 +1414,26 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder)
/* Clear calc init */
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
val = ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
+ val = ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
+ val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
val = ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
+ val = ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
+ val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW9(ch));
+ val = ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
+ val |= DPIO_PCS_TX1MARGIN_000 |
[Intel-gfx] [PATCH 1/4] drm/i915: Warn about odd rps values on CHV
From: Ville Syrjälä ville.syrj...@linux.intel.com CHV wants even rps opcodes so print a warning of the min/max/rpe/rp1 values are odd, and warn if an odd value slips through to valleyview_set_rps() and truncate it to an even value. Also add a comment to chv_freq_opcode() to make sure no one changes the code without considering this requirement. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_pm.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index c8f744c..c84ad93 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3453,6 +3453,10 @@ void valleyview_set_rps(struct drm_device *dev, u8 val) dev_priv-rps.cur_freq, vlv_gpu_freq(dev_priv, val), val); + if (WARN_ONCE(IS_CHERRYVIEW(dev) (val 1), + Odd GPU freq value\n)) + val = ~1; + if (val != dev_priv-rps.cur_freq) vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val); @@ -4149,6 +4153,12 @@ static void cherryview_init_gt_powersave(struct drm_device *dev) vlv_gpu_freq(dev_priv, dev_priv-rps.min_freq), dev_priv-rps.min_freq); + WARN_ONCE((dev_priv-rps.max_freq | + dev_priv-rps.efficient_freq | + dev_priv-rps.rp1_freq | + dev_priv-rps.min_freq) 1, + Odd GPU freq values\n); + /* Preserve min/max settings in case of re-init */ if (dev_priv-rps.max_freq_softlimit == 0) dev_priv-rps.max_freq_softlimit = dev_priv-rps.max_freq; @@ -7443,6 +7453,7 @@ static int chv_freq_opcode(struct drm_i915_private *dev_priv, int val) return -1; } + /* CHV needs even values */ opcode = (DIV_ROUND_CLOSEST((val * 2 * mul), dev_priv-rps.cz_freq) * 2); return opcode; -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/5] drm/i915: take display port power domain in DP HPD handler
Ville noticed that we can call ibx_digital_port_connected() which accesses
the HW without holding any power well/runtime pm reference. Fix this by
holding a display port power domain reference around the whole hpd_pulse
handler.
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ee3942f..a520188 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4037,15 +4037,21 @@ bool
intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
{
struct intel_dp *intel_dp = intel_dig_port-dp;
+ struct intel_encoder *intel_encoder = intel_dig_port-base;
struct drm_device *dev = intel_dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- int ret;
+ enum intel_display_power_domain power_domain;
+ bool ret = true;
+
if (intel_dig_port-base.type != INTEL_OUTPUT_EDP)
intel_dig_port-base.type = INTEL_OUTPUT_DISPLAYPORT;
DRM_DEBUG_KMS(got hpd irq on port %d - %s\n, intel_dig_port-port,
long_hpd ? long : short);
+ power_domain = intel_display_port_power_domain(intel_encoder);
+ intel_display_power_get(dev_priv, power_domain);
+
if (long_hpd) {
if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
goto mst_fail;
@@ -4061,8 +4067,7 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
} else {
if (intel_dp-is_mst) {
- ret = intel_dp_check_mst_status(intel_dp);
- if (ret == -EINVAL)
+ if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
goto mst_fail;
}
@@ -4076,7 +4081,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
drm_modeset_unlock(dev-mode_config.connection_mutex);
}
}
- return false;
+ ret = false;
+ goto put_power;
mst_fail:
/* if we were in MST mode, and device is not there get out of MST mode
*/
if (intel_dp-is_mst) {
@@ -4084,7 +4090,10 @@ mst_fail:
intel_dp-is_mst = false;
drm_dp_mst_topology_mgr_set_mst(intel_dp-mst_mgr,
intel_dp-is_mst);
}
- return true;
+put_power:
+ intel_display_power_put(dev_priv, power_domain);
+
+ return ret;
}
/* Return which DP Port should be selected for Transcoder DP control */
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/4] drm/i915: Clear TX FIFO reset master override bits on chv
From: Ville Syrjälä ville.syrj...@linux.intel.com
Clear the override bits to make sure the hardware maanages
the TX FIFO reset master on its own.
v2: Squash with the earlier attempt at forcing the override bits
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 | 9 +
drivers/gpu/drm/i915/intel_hdmi.c | 9 +
3 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b8e8d33..daac02b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -784,6 +784,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
@@ -860,8 +862,18 @@ enum punit_power_well {
#define _VLV_PCS_DW11_CH0 0x822c
#define _VLV_PCS_DW11_CH1 0x842c
+#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_CH00x022c
+#define _VLV_PCS23_DW11_CH00x042c
+#define _VLV_PCS01_DW11_CH10x262c
+#define _VLV_PCS23_DW11_CH10x282c
+#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_CH0 0x8230
#define _VLV_PCS_DW12_CH1 0x8430
#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 f8e4578..4f69648 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2223,6 +2223,15 @@ static void chv_pre_enable_dp(struct intel_encoder
*encoder)
mutex_lock(dev_priv-dpio_lock);
+ /* allow hardware to manage TX FIFO reset source */
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+ 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_DW11(ch));
+ 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 f3bf0c7..f0cff45 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1378,6 +1378,15 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder)
mutex_lock(dev_priv-dpio_lock);
+ /* allow hardware to manage TX FIFO reset source */
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+ 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_DW11(ch));
+ 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;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 3/5] drm/i915: cancel hotplug and dig_port work during suspend and unload
Make sure these work handlers don't run after we system suspend or
unload the driver. Note that we don't cancel the handlers during runtime
suspend. That could lead to a lockup, since we take a runtime PM ref
from the handlers themselves. Fortunaltely canceling there is not needed
since the RPM ref itself provides for the needed serialization.
v2:
- fix the order of canceling dig_port_work wrt. hotplug_work (Ville)
- zero out {long,short}_hpd_port_mask and hpd_event_bits for speed
(Ville)
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 16
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 3 +--
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ec96f9a..3f9c8f6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -494,6 +494,21 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
return true;
}
+void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
+{
+ spin_lock_irq(dev_priv-irq_lock);
+
+ dev_priv-long_hpd_port_mask = 0;
+ dev_priv-short_hpd_port_mask = 0;
+ dev_priv-hpd_event_bits = 0;
+
+ spin_unlock_irq(dev_priv-irq_lock);
+
+ cancel_work_sync(dev_priv-dig_port_work);
+ cancel_work_sync(dev_priv-hotplug_work);
+ cancel_delayed_work_sync(dev_priv-hotplug_reenable_work);
+}
+
static int i915_drm_freeze(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -538,6 +553,7 @@ static int i915_drm_freeze(struct drm_device *dev)
flush_delayed_work(dev_priv-rps.delayed_resume_work);
intel_runtime_pm_disable_interrupts(dev);
+ intel_hpd_cancel_work(dev_priv);
intel_suspend_gt_powersave(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1263aac..7a830ea 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2178,6 +2178,7 @@ extern unsigned long i915_mch_val(struct drm_i915_private
*dev_priv);
extern unsigned long i915_gfx_val(struct drm_i915_private *dev_priv);
extern void i915_update_gfx_val(struct drm_i915_private *dev_priv);
int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool on);
+void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
extern void intel_console_resume(struct work_struct *work);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bcf8d18..d074d70 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13103,8 +13103,7 @@ void intel_modeset_cleanup(struct drm_device *dev)
* experience fancy races otherwise.
*/
drm_irq_uninstall(dev);
- cancel_work_sync(dev_priv-hotplug_work);
- cancel_delayed_work_sync(dev_priv-hotplug_reenable_work);
+ intel_hpd_cancel_work(dev_priv);
dev_priv-pm._irqs_disabled = true;
/*
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/5] drm/i915: fix HPD IRQ reenable work cancelation
Atm, the HPD IRQ reenable timer can get rearmed right after it's
canceled. Also to access the HPD IRQ mask registers we need to wake up
the HW.
Solve both issues by converting the reenable timer to a delayed work and
grabbing a runtime PM reference in the work. By this we can also forgo
canceling the timer during runtime suspend, since the only important
thing there is that the HW is awake when we write the registers and
that's ensured by the RPM ref. So do the cancelation only during driver
unload time; this is also a requirement for an upcoming patch where we
want to cancel all HPD related works only during system suspend and
driver unload time, but not during runtime suspend.
Note that there is still a race between the HPD IRQ reenable work and
drm_irq_uninstall() during driver unload, where the work can reenable
the HPD IRQs disabled by drm_irq_uninstall(). This isn't a problem since
the HPD IRQs will still be effectively masked by the first level
interrupt mask.
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 33 -
drivers/gpu/drm/i915/intel_display.c | 1 +
3 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4412f6a..1263aac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1458,7 +1458,7 @@ struct drm_i915_private {
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
u32 hpd_event_bits;
- struct timer_list hotplug_reenable_timer;
+ struct delayed_work hotplug_reenable_work;
struct i915_fbc fbc;
struct i915_drrs drrs;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 390ccc2..8a5a03f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1189,8 +1189,8 @@ static void i915_hotplug_work_func(struct work_struct
*work)
* some connectors */
if (hpd_disabled) {
drm_kms_helper_poll_enable(dev);
- mod_timer(dev_priv-hotplug_reenable_timer,
- jiffies +
msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
+ schedule_delayed_work(dev_priv-hotplug_reenable_work,
+ msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
}
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
@@ -1213,11 +1213,6 @@ static void i915_hotplug_work_func(struct work_struct
*work)
drm_kms_helper_hotplug_event(dev);
}
-static void intel_hpd_irq_uninstall(struct drm_i915_private *dev_priv)
-{
- del_timer_sync(dev_priv-hotplug_reenable_timer);
-}
-
static void ironlake_rps_change_irq_handler(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -3892,8 +3887,6 @@ static void gen8_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
- intel_hpd_irq_uninstall(dev_priv);
-
gen8_irq_reset(dev);
}
@@ -3908,8 +3901,6 @@ static void valleyview_irq_uninstall(struct drm_device
*dev)
I915_WRITE(VLV_MASTER_IER, 0);
- intel_hpd_irq_uninstall(dev_priv);
-
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
@@ -3988,8 +3979,6 @@ static void ironlake_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
- intel_hpd_irq_uninstall(dev_priv);
-
ironlake_irq_reset(dev);
}
@@ -4360,8 +4349,6 @@ static void i915_irq_uninstall(struct drm_device * dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int pipe;
- intel_hpd_irq_uninstall(dev_priv);
-
if (I915_HAS_HOTPLUG(dev)) {
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -4598,8 +4585,6 @@ static void i965_irq_uninstall(struct drm_device * dev)
if (!dev_priv)
return;
- intel_hpd_irq_uninstall(dev_priv);
-
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -4615,14 +4600,18 @@ static void i965_irq_uninstall(struct drm_device * dev)
I915_WRITE(IIR, I915_READ(IIR));
}
-static void intel_hpd_irq_reenable(unsigned long data)
+static void intel_hpd_irq_reenable(struct work_struct *work)
{
- struct drm_i915_private *dev_priv = (struct drm_i915_private *)data;
+ struct drm_i915_private *dev_priv =
+ container_of(work, typeof(*dev_priv),
+hotplug_reenable_work.work);
struct drm_device *dev = dev_priv-dev;
struct drm_mode_config *mode_config = dev-mode_config;
unsigned long irqflags;
int i;
+ intel_runtime_pm_get(dev_priv);
+
spin_lock_irqsave(dev_priv-irq_lock,
[Intel-gfx] [PATCH v3 5/5] drm/i915: don't try to retrain a DP link on an inactive CRTC
Atm we may retrain the DP link even if the CRTC is inactive through
HPD work-intel_dp_check_link_status(). This in turn can lock up the PHY
(at least on BYT), since the DP port is disabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e31ac9e..99064f9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3553,6 +3553,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
if (WARN_ON(!intel_encoder-base.crtc))
return;
+ if (!to_intel_crtc(intel_encoder-base.crtc)-active)
+ return;
+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 4/5] drm/i915: make sure VDD is turned off during system suspend
Atm we may leave eDP VDD enabled during system suspend after the CRTCs
are disabled through an HPD-DPCD read event. So disable VDD during
suspend at a point when no HPDs can occur.
Note that runtime suspend doesn't have the same problem, since there the
RPM ref held by VDD provides already the needed serialization.
v2:
- add note to commit message about the runtime suspend path (Ville)
- use edp_panel_vdd_off_sync(), so we can keep the WARN in
edp_panel_vdd_off() (Ville)
v3:
- rebased on -fixes (for_each_intel_encoder()-list_for_each_entry())
(Imre)
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com (v2)
[rebased on -fixes (Imre)] (v3)
---
drivers/gpu/drm/i915/i915_drv.c | 17 +
drivers/gpu/drm/i915/intel_dp.c | 11 +++
drivers/gpu/drm/i915/intel_drv.h | 6 ++
3 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3f9c8f6..e27cdbe 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -509,6 +509,21 @@ void intel_hpd_cancel_work(struct drm_i915_private
*dev_priv)
cancel_delayed_work_sync(dev_priv-hotplug_reenable_work);
}
+static void intel_suspend_encoders(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+ struct drm_encoder *encoder;
+
+ drm_modeset_lock_all(dev);
+ list_for_each_entry(encoder, dev-mode_config.encoder_list, head) {
+ struct intel_encoder *intel_encoder = to_intel_encoder(encoder);
+
+ if (intel_encoder-suspend)
+ intel_encoder-suspend(intel_encoder);
+ }
+ drm_modeset_unlock_all(dev);
+}
+
static int i915_drm_freeze(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -555,6 +570,8 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_runtime_pm_disable_interrupts(dev);
intel_hpd_cancel_work(dev_priv);
+ intel_suspend_encoders(dev_priv);
+
intel_suspend_gt_powersave(dev);
intel_modeset_suspend_hw(dev);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a520188..e31ac9e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4003,6 +4003,16 @@ void intel_dp_encoder_destroy(struct drm_encoder
*encoder)
kfree(intel_dig_port);
}
+void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder-base);
+
+ if (!is_edp(intel_dp))
+ return;
+
+ edp_panel_vdd_off_sync(intel_dp);
+}
+
static void intel_dp_encoder_reset(struct drm_encoder *encoder)
{
intel_edp_panel_vdd_sanitize(to_intel_encoder(encoder));
@@ -4731,6 +4741,7 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
intel_encoder-disable = intel_disable_dp;
intel_encoder-get_hw_state = intel_dp_get_hw_state;
intel_encoder-get_config = intel_dp_get_config;
+ intel_encoder-suspend = intel_dp_encoder_suspend;
if (IS_CHERRYVIEW(dev)) {
intel_encoder-pre_pll_enable = chv_dp_pre_pll_enable;
intel_encoder-pre_enable = chv_pre_enable_dp;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fe3431f..b8c8bbd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -153,6 +153,12 @@ struct intel_encoder {
* be set correctly before calling this function. */
void (*get_config)(struct intel_encoder *,
struct intel_crtc_config *pipe_config);
+ /*
+* Called during system suspend after all pending requests for the
+* encoder are flushed (for example for DP AUX transactions) and
+* device interrupts are disabled.
+*/
+ void (*suspend)(struct intel_encoder *);
int crtc_mask;
enum hpd_pin hpd_pin;
};
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: fix HPD IRQ reenable work cancelation
On Mon, 18 Aug 2014, Imre Deak imre.d...@intel.com wrote:
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 390ccc2..8a5a03f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1189,8 +1189,8 @@ static void i915_hotplug_work_func(struct work_struct
*work)
* some connectors */
if (hpd_disabled) {
drm_kms_helper_poll_enable(dev);
- mod_timer(dev_priv-hotplug_reenable_timer,
- jiffies +
msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
+ schedule_delayed_work(dev_priv-hotplug_reenable_work,
+ msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
}
As we discussed face to face, there's a semantic change here, and a
lesson worth repeating on the list. If the timer is pending, mod_timer()
will update the expiry time. However, if the delayed work is pending,
schedule_delayed_work() will *not* update the expiry time.
I guess you need to be bitten by this to remember... been there done
that. ;) Happily there's no need to work around this anymore since
commit 8376fe22c7e79c7e90857d39f82aeae6cad6c4b8
Author: Tejun Heo t...@kernel.org
Date: Fri Aug 3 10:30:47 2012 -0700
workqueue: implement mod_delayed_work[_on]()
and you can use mod_delayed_work().
BR,
Jani.
--
Jani Nikula, 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 v4 2/5] drm/i915: fix HPD IRQ reenable work cancelation
Atm, the HPD IRQ reenable timer can get rearmed right after it's
canceled. Also to access the HPD IRQ mask registers we need to wake up
the HW.
Solve both issues by converting the reenable timer to a delayed work and
grabbing a runtime PM reference in the work. By this we can also forgo
canceling the timer during runtime suspend, since the only important
thing there is that the HW is awake when we write the registers and
that's ensured by the RPM ref. So do the cancelation only during driver
unload time; this is also a requirement for an upcoming patch where we
want to cancel all HPD related works only during system suspend and
driver unload time, but not during runtime suspend.
Note that there is still a race between the HPD IRQ reenable work and
drm_irq_uninstall() during driver unload, where the work can reenable
the HPD IRQs disabled by drm_irq_uninstall(). This isn't a problem since
the HPD IRQs will still be effectively masked by the first level
interrupt mask.
v2-3:
- unchanged
v4:
- use proper API for changing the expiration time for an already pending
delayed work (Jani)
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com (v2)
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 33 -
drivers/gpu/drm/i915/intel_display.c | 1 +
3 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4412f6a..1263aac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1458,7 +1458,7 @@ struct drm_i915_private {
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
u32 hpd_event_bits;
- struct timer_list hotplug_reenable_timer;
+ struct delayed_work hotplug_reenable_work;
struct i915_fbc fbc;
struct i915_drrs drrs;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 390ccc2..718aa5e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1189,8 +1189,8 @@ static void i915_hotplug_work_func(struct work_struct
*work)
* some connectors */
if (hpd_disabled) {
drm_kms_helper_poll_enable(dev);
- mod_timer(dev_priv-hotplug_reenable_timer,
- jiffies +
msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
+ mod_delayed_work(system_wq, dev_priv-hotplug_reenable_work,
+ msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
}
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
@@ -1213,11 +1213,6 @@ static void i915_hotplug_work_func(struct work_struct
*work)
drm_kms_helper_hotplug_event(dev);
}
-static void intel_hpd_irq_uninstall(struct drm_i915_private *dev_priv)
-{
- del_timer_sync(dev_priv-hotplug_reenable_timer);
-}
-
static void ironlake_rps_change_irq_handler(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -3892,8 +3887,6 @@ static void gen8_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
- intel_hpd_irq_uninstall(dev_priv);
-
gen8_irq_reset(dev);
}
@@ -3908,8 +3901,6 @@ static void valleyview_irq_uninstall(struct drm_device
*dev)
I915_WRITE(VLV_MASTER_IER, 0);
- intel_hpd_irq_uninstall(dev_priv);
-
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
@@ -3988,8 +3979,6 @@ static void ironlake_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
- intel_hpd_irq_uninstall(dev_priv);
-
ironlake_irq_reset(dev);
}
@@ -4360,8 +4349,6 @@ static void i915_irq_uninstall(struct drm_device * dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int pipe;
- intel_hpd_irq_uninstall(dev_priv);
-
if (I915_HAS_HOTPLUG(dev)) {
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -4598,8 +4585,6 @@ static void i965_irq_uninstall(struct drm_device * dev)
if (!dev_priv)
return;
- intel_hpd_irq_uninstall(dev_priv);
-
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -4615,14 +4600,18 @@ static void i965_irq_uninstall(struct drm_device * dev)
I915_WRITE(IIR, I915_READ(IIR));
}
-static void intel_hpd_irq_reenable(unsigned long data)
+static void intel_hpd_irq_reenable(struct work_struct *work)
{
- struct drm_i915_private *dev_priv = (struct drm_i915_private *)data;
+ struct drm_i915_private *dev_priv =
+ container_of(work, typeof(*dev_priv),
+hotplug_reenable_work.work);
struct drm_device *dev = dev_priv-dev;
struct drm_mode_config *mode_config = dev-mode_config;
[Intel-gfx] [PATCH] drm/i915: Use dev_priv as first argument of for_each_pipe()
Chris has decided that enough is enough. It's time to fixup dev Vs
dev_priv. This is a modest contribution to the crusade.
v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode
the info struct with defines (Chris)
Rename the macro argument from 'dev' to 'dev_priv' (Jani)
v3: Use names unlikely to be used as macro arguments (Chris)
Suggested-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
drivers/gpu/drm/i915/i915_dma.c | 4 +--
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/i915_irq.c | 65 ++--
drivers/gpu/drm/i915/intel_display.c | 16 +
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_panel.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 17 +-
8 files changed, 60 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6c82bda..637143c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -662,7 +662,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
I915_READ(VLV_IIR_RW));
seq_printf(m, Display IMR:\t%08x\n,
I915_READ(VLV_IMR));
- for_each_pipe(pipe)
+ for_each_pipe(dev_priv, pipe)
seq_printf(m, Pipe %c stat:\t%08x\n,
pipe_name(pipe),
I915_READ(PIPESTAT(pipe)));
@@ -702,7 +702,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
i, I915_READ(GEN8_GT_IER(i)));
}
- for_each_pipe(pipe) {
+ for_each_pipe(dev_priv, pipe) {
if (!intel_display_power_enabled(dev_priv,
POWER_DOMAIN_PIPE(pipe))) {
seq_printf(m, Pipe %c power disabled\n,
@@ -749,7 +749,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
I915_READ(VLV_IIR_RW));
seq_printf(m, Display IMR:\t%08x\n,
I915_READ(VLV_IMR));
- for_each_pipe(pipe)
+ for_each_pipe(dev_priv, pipe)
seq_printf(m, Pipe %c stat:\t%08x\n,
pipe_name(pipe),
I915_READ(PIPESTAT(pipe)));
@@ -785,7 +785,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
I915_READ(IIR));
seq_printf(m, Interrupt mask: %08x\n,
I915_READ(IMR));
- for_each_pipe(pipe)
+ for_each_pipe(dev_priv, pipe)
seq_printf(m, Pipe %c stat: %08x\n,
pipe_name(pipe),
I915_READ(PIPESTAT(pipe)));
@@ -4178,7 +4178,7 @@ void intel_display_crc_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
enum pipe pipe;
- for_each_pipe(pipe) {
+ for_each_pipe(dev_priv, pipe) {
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
pipe_crc-opened = false;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3f676f9..f19dbff 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1528,10 +1528,10 @@ static void intel_device_info_runtime_init(struct
drm_device *dev)
info = (struct intel_device_info *)dev_priv-info;
if (IS_VALLEYVIEW(dev))
- for_each_pipe(pipe)
+ for_each_pipe(dev_priv, pipe)
info-num_sprites[pipe] = 2;
else
- for_each_pipe(pipe)
+ for_each_pipe(dev_priv, pipe)
info-num_sprites[pipe] = 1;
if (i915.disable_display) {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4754328..dcfc63c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -163,7 +163,8 @@ enum hpd_pin {
I915_GEM_DOMAIN_INSTRUCTION | \
I915_GEM_DOMAIN_VERTEX)
-#define for_each_pipe(p) for ((p) = 0; (p) INTEL_INFO(dev)-num_pipes; (p)++)
+#define for_each_pipe(__dev_priv, __p) \
+ for ((__p) = 0; (__p) INTEL_INFO(__dev_priv)-num_pipes; (__p)++)
#define for_each_sprite(p, s) for ((s) = 0; (s)
INTEL_INFO(dev)-num_sprites[(p)]; (s)++)
#define for_each_crtc(dev, crtc) \
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6b6fff1..06bb8cd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -238,7 +238,7 @@ static bool
[Intel-gfx] [PATCH] drm/i915: Print the pipe on which the vblank wait times out
Pimp up the debug message that tells us we've been waiting for a vblank that never arrived. Printing the pipe could lead a doh! moment where we've been waiting for a vblank on a pipe that was off for instance. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/i915/intel_display.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f602924..71d3487 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -900,7 +900,8 @@ static void g4x_wait_for_vblank(struct drm_device *dev, int pipe) frame = I915_READ(frame_reg); if (wait_for(I915_READ_NOTRACE(frame_reg) != frame, 50)) - WARN(1, vblank wait timed out\n); + WARN(1, vblank wait on pipe %c timed out\n, +pipe_name(pipe)); } /** @@ -941,7 +942,8 @@ void intel_wait_for_vblank(struct drm_device *dev, int pipe) if (wait_for(I915_READ(pipestat_reg) PIPE_VBLANK_INTERRUPT_STATUS, 50)) - DRM_DEBUG_KMS(vblank wait timed out\n); + DRM_DEBUG_KMS(vblank wait on pipe %c timed out\n, + pipe_name(pipe)); } static bool pipe_dsl_stopped(struct drm_device *dev, enum pipe pipe) -- 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: Use dev_priv as first argument of for_each_pipe()
On Mon, Aug 18, 2014 at 01:49:10PM +0100, Damien Lespiau wrote: Chris has decided that enough is enough. It's time to fixup dev Vs dev_priv. This is a modest contribution to the crusade. v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode the info struct with defines (Chris) Rename the macro argument from 'dev' to 'dev_priv' (Jani) v3: Use names unlikely to be used as macro arguments (Chris) I can be annoying! These macros typically take the iter as the first argument... -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: Use dev_priv as first argument of for_each_pipe()
On Mon, Aug 18, 2014 at 01:58:06PM +0100, Chris Wilson wrote: On Mon, Aug 18, 2014 at 01:49:10PM +0100, Damien Lespiau wrote: Chris has decided that enough is enough. It's time to fixup dev Vs dev_priv. This is a modest contribution to the crusade. v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode the info struct with defines (Chris) Rename the macro argument from 'dev' to 'dev_priv' (Jani) v3: Use names unlikely to be used as macro arguments (Chris) I can be annoying! These macros typically take the iter as the first argument... How typical is your typical? #define for_each_pipe(__dev_priv, __p) #define for_each_crtc(dev, crtc) #define for_each_intel_crtc(dev, intel_crtc) #define for_each_intel_encoder(dev, intel_encoder) #define for_each_encoder_on_crtc(dev, __crtc, intel_encoder) #define for_each_connector_on_encoder(dev, __encoder, intel_connector) Sounds like a lot of churn for no good reason this time. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use dev_priv as first argument of for_each_pipe()
On Mon, Aug 18, 2014 at 02:07:40PM +0100, Damien Lespiau wrote: On Mon, Aug 18, 2014 at 01:58:06PM +0100, Chris Wilson wrote: On Mon, Aug 18, 2014 at 01:49:10PM +0100, Damien Lespiau wrote: Chris has decided that enough is enough. It's time to fixup dev Vs dev_priv. This is a modest contribution to the crusade. v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode the info struct with defines (Chris) Rename the macro argument from 'dev' to 'dev_priv' (Jani) v3: Use names unlikely to be used as macro arguments (Chris) I can be annoying! These macros typically take the iter as the first argument... How typical is your typical? list_for_each and everything derived from them that paid attention... #define for_each_pipe(__dev_priv, __p) #define for_each_crtc(dev, crtc) #define for_each_intel_crtc(dev, intel_crtc) #define for_each_intel_encoder(dev, intel_encoder) #define for_each_encoder_on_crtc(dev, __crtc, intel_encoder) #define for_each_connector_on_encoder(dev, __encoder, intel_connector) Sounds like a lot of churn for no good reason this time. Or that I forgot to tell you about this detail last time. -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 v3 1/5] drm/i915: take display port power domain in DP HPD handler
Series pushed to -fixes, thanks for the patches and review.
BR,
Jani.
On Mon, 18 Aug 2014, Imre Deak imre.d...@intel.com wrote:
Ville noticed that we can call ibx_digital_port_connected() which accesses
the HW without holding any power well/runtime pm reference. Fix this by
holding a display port power domain reference around the whole hpd_pulse
handler.
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ee3942f..a520188 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4037,15 +4037,21 @@ bool
intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
{
struct intel_dp *intel_dp = intel_dig_port-dp;
+ struct intel_encoder *intel_encoder = intel_dig_port-base;
struct drm_device *dev = intel_dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- int ret;
+ enum intel_display_power_domain power_domain;
+ bool ret = true;
+
if (intel_dig_port-base.type != INTEL_OUTPUT_EDP)
intel_dig_port-base.type = INTEL_OUTPUT_DISPLAYPORT;
DRM_DEBUG_KMS(got hpd irq on port %d - %s\n, intel_dig_port-port,
long_hpd ? long : short);
+ power_domain = intel_display_port_power_domain(intel_encoder);
+ intel_display_power_get(dev_priv, power_domain);
+
if (long_hpd) {
if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
goto mst_fail;
@@ -4061,8 +4067,7 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
} else {
if (intel_dp-is_mst) {
- ret = intel_dp_check_mst_status(intel_dp);
- if (ret == -EINVAL)
+ if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
goto mst_fail;
}
@@ -4076,7 +4081,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
drm_modeset_unlock(dev-mode_config.connection_mutex);
}
}
- return false;
+ ret = false;
+ goto put_power;
mst_fail:
/* if we were in MST mode, and device is not there get out of MST mode
*/
if (intel_dp-is_mst) {
@@ -4084,7 +4090,10 @@ mst_fail:
intel_dp-is_mst = false;
drm_dp_mst_topology_mgr_set_mst(intel_dp-mst_mgr,
intel_dp-is_mst);
}
- return true;
+put_power:
+ intel_display_power_put(dev_priv, power_domain);
+
+ return ret;
}
/* Return which DP Port should be selected for Transcoder DP control */
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, 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] intel-gpu-tools: skip kms_flip_event_leak unless we have cairo
From: Tim Gore tim.g...@intel.com kms_flip_event_leak depends on cairo, so add it to the list of tests to skip (in Android.mk) if ANDROID_HAS_CAIRO is not set to 1. Signed-off-by: Tim Gore tim.g...@intel.com --- tests/Android.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/Android.mk b/tests/Android.mk index 00e6f1b..3644aa1 100644 --- a/tests/Android.mk +++ b/tests/Android.mk @@ -72,7 +72,8 @@ else kms_render \ kms_universal_plane \ kms_rotation_crc \ -kms_force_connector +kms_force_connector \ +kms_flip_event_leak IGT_LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=0 endif -- 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: fix plane/cursor handling when runtime suspended
On Fri, Aug 15, 2014 at 03:59:32PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If we're runtime suspended and try to use the plane interfaces, we
will get a lot of WARNs saying we did the wrong thing.
We need to get runtime PM references to pin the objects, and to
change the fences. The pin functions are the ideal places for
this, but intel_crtc_cursor_set_obj() doesn't call them, so we also
have to add get/put calls inside it. There is no problem if we runtime
suspend right after these functions are finished, because the
registers written are forwarded to system memory.
Note: for a complete fix of the cursor-dpms test case, we also need
the patch named drm/i915: Don't try to enable cursor from setplane
when crtc is disabled.
v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
v3: - Make get/put also surround the fence and unpin calls (Daniel and
Ville).
- Merge all the plane changes into a single patch since they're
the same fix.
- Add the comment requested by Daniel.
v4: - Remove spurious whitespace (Ville).
v5: - Remove intel_crtc_update_cursor() chunk since Ville did an
equivalent fix in another patch (Ville).
v6: - Remove unpin chunk: it will be on a separate patch (Ville,
Chris, Daniel).
v7: - Same thing, new color.
Testcase: igt/pm_rpm/cursor
Testcase: igt/pm_rpm/cursor-dpms
Testcase: igt/pm_rpm/legacy-planes
Testcase: igt/pm_rpm/legacy-planes-dpms
Testcase: igt/pm_rpm/universal-planes
Testcase: igt/pm_rpm/universal-planes-dpms
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82603
Cc: sta...@vger.kernel.org
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3f8e037..15fe3eb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2201,6 +2201,15 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
if (need_vtd_wa(dev) alignment 256 * 1024)
alignment = 256 * 1024;
+ /*
+ * Global gtt pte registers are special registers which actually forward
+ * writes to a chunk of system memory. Which means that there is no risk
+ * that the register values disappear as soon as we call
+ * intel_runtime_pm_put(), so it is correct to wrap only the
+ * pin/unpin/fence and not more.
+ */
+ intel_runtime_pm_get(dev_priv);
+
dev_priv-mm.interruptible = false;
ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined);
if (ret)
@@ -2218,12 +2227,14 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
i915_gem_object_pin_fence(obj);
dev_priv-mm.interruptible = true;
+ intel_runtime_pm_put(dev_priv);
return 0;
err_unpin:
i915_gem_object_unpin_from_display_plane(obj);
err_interruptible:
dev_priv-mm.interruptible = true;
+ intel_runtime_pm_put(dev_priv);
return ret;
}
@@ -8253,6 +8264,7 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
uint32_t width, uint32_t height)
{
struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc-pipe;
unsigned old_width, stride;
@@ -8292,6 +8304,15 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
goto fail_locked;
}
+ /*
+ * Global gtt pte registers are special registers which actually
+ * forward writes to a chunk of system memory. Which means that
+ * there is no risk that the register values disappear as soon
+ * as we call intel_runtime_pm_put(), so it is correct to wrap
+ * only the pin/unpin/fence and not more.
+ */
+ intel_runtime_pm_get(dev_priv);
+
/* Note that the w/a also requires 2 PTE of padding following
* the bo. We currently fill all unused PTE with the shadow
* page and so we should always have valid PTE following the
@@ -8304,16 +8325,20 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
if (ret) {
DRM_DEBUG_KMS(failed to move cursor bo into the
GTT\n);
+ intel_runtime_pm_put(dev_priv);
goto fail_locked;
}
ret = i915_gem_object_put_fence(obj);
if (ret) {
Re: [Intel-gfx] [PATCH 41/43] drm/i915/bdw: Enable Logical Ring Contexts (hence, Execlists)
-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Monday, August 18, 2014 9:33 AM
To: Daniel, Thomas; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 41/43] drm/i915/bdw: Enable Logical Ring
Contexts (hence, Execlists)
On Thu, 24 Jul 2014, Thomas Daniel thomas.dan...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
The time has come, the Walrus said, to talk of many things.
FYI this causes https://bugs.freedesktop.org/show_bug.cgi?id=82740
Hmm, this seems to be an interaction between execlists and PPGTT
patches, specifically:
http://patchwork.freedesktop.org/patch/31150/
which breaks aliasing PPGTT when execlists are enabled, resulting
in this oops on boot.
I will post a patch which avoids this but I don't know if the intention
is to drop aliasing PPGTT support when execlists are enabled.
Thomas.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index b7cf0ec..1ce51d6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2061,7 +2061,7 @@ struct drm_i915_cmd_table {
#define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)-need_gfx_hws)
#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)-gen = 6)
-#define HAS_LOGICAL_RING_CONTEXTS(dev) 0
+#define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)-
gen = 8)
#define HAS_ALIASING_PPGTT(dev)(INTEL_INFO(dev)-gen = 6)
#define HAS_PPGTT(dev) (INTEL_INFO(dev)-gen = 7
!IS_GEN8(dev))
#define USES_PPGTT(dev)intel_enable_ppgtt(dev, false)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, 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] drm/i915/bdw: Populate lrc with aliasing ppgtt if required
A previous commit broke aliasing PPGTT for lrc, resulting in a kernel oops
on boot. Add a check so that is full PPGTT is not in use the context is
populated with the aliasing PPGTT.
Issue: VIZ-4278
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c096b9b..79a6b91 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1452,12 +1452,19 @@ static int
populate_lr_context(struct intel_context *ctx, struct drm_i915_gem_object
*ctx_obj,
struct intel_engine_cs *ring, struct intel_ringbuffer
*ringbuf)
{
+ struct drm_device *dev = ring-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *ring_obj = ringbuf-obj;
struct i915_hw_ppgtt *ppgtt = ctx-ppgtt;
struct page *page;
uint32_t *reg_state;
int ret;
+ if (USES_FULL_PPGTT(dev))
+ ppgtt = ctx-ppgtt;
+ else
+ ppgtt = dev_priv-mm.aliasing_ppgtt;
+
ret = i915_gem_object_set_to_cpu_domain(ctx_obj, true);
if (ret) {
DRM_DEBUG_DRIVER(Could not set to CPU domain\n);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Disable execlists by default
2014-08-18 5:29 GMT-03:00 Jani Nikula jani.nik...@linux.intel.com:
On Fri, 15 Aug 2014, Damien Lespiau damien.lesp...@intel.com wrote:
We still have a few missing bits and pieces to have execlists enabled by
default eg. the error capture or the render state initialization and so
it wouldn't be wise to enable it by default on BDW just yet.
Also,
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82740
Yes, please! I can't boot BDW anymore without this.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Tested-by: Paulo Zanoni paulo.r.zan...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Thomas Daniel thomas.dan...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 0886aca..139f490 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -35,7 +35,7 @@ struct i915_params i915 __read_mostly = {
.vbt_sdvo_panel_type = -1,
.enable_rc6 = -1,
.enable_fbc = -1,
- .enable_execlists = -1,
+ .enable_execlists = 0,
.enable_hangcheck = true,
.enable_ppgtt = -1,
.enable_psr = 0,
@@ -122,7 +122,7 @@ MODULE_PARM_DESC(enable_ppgtt,
module_param_named(enable_execlists, i915.enable_execlists, int, 0400);
MODULE_PARM_DESC(enable_execlists,
Override execlists usage.
- (-1=auto [default], 0=disabled, 1=enabled));
+ (-1=auto, 0=disabled [default], 1=enabled));
module_param_named(enable_psr, i915.enable_psr, int, 0600);
MODULE_PARM_DESC(enable_psr, Enable PSR (default: false));
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, 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
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Populate lrc with aliasing ppgtt if required
On Mon, Aug 18, 2014 at 03:54:02PM +0100, Thomas Daniel wrote:
A previous commit broke aliasing PPGTT for lrc, resulting in a kernel oops
on boot. Add a check so that is full PPGTT is not in use the context is
populated with the aliasing PPGTT.
Issue: VIZ-4278
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index c096b9b..79a6b91 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1452,12 +1452,19 @@ static int
populate_lr_context(struct intel_context *ctx, struct drm_i915_gem_object
*ctx_obj,
struct intel_engine_cs *ring, struct intel_ringbuffer
*ringbuf)
{
+ struct drm_device *dev = ring-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *ring_obj = ringbuf-obj;
struct i915_hw_ppgtt *ppgtt = ctx-ppgtt;
It's a bit weird to leave ppgtt initialized here when you're going to
always override it below.
struct page *page;
uint32_t *reg_state;
int ret;
+ if (USES_FULL_PPGTT(dev))
+ ppgtt = ctx-ppgtt;
+ else
+ ppgtt = dev_priv-mm.aliasing_ppgtt;
+
The patch drom daniel you mention removes the usage of USES_FULL_PPGTT()
to directly test ctx-ppgtt. You may want to reproduce that here ie.
ppgtt = ctx-ppgtt;
if (!ppgtt)
ppgtt = dev_priv-mm.aliasing_ppgtt;
doesn't really matter either way I guess, but can we at least not set
then always override ppgtt?
Thanks,
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel-gpu-tools: skip kms_flip_event_leak unless we have cairo
On 18 August 2014 14:56, tim.g...@intel.com wrote: From: Tim Gore tim.g...@intel.com kms_flip_event_leak depends on cairo, so add it to the list of tests to skip (in Android.mk) if ANDROID_HAS_CAIRO is not set to 1. Patch merged, thanks. Signed-off-by: Tim Gore tim.g...@intel.com --- tests/Android.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/Android.mk b/tests/Android.mk index 00e6f1b..3644aa1 100644 --- a/tests/Android.mk +++ b/tests/Android.mk @@ -72,7 +72,8 @@ else kms_render \ kms_universal_plane \ kms_rotation_crc \ -kms_force_connector +kms_force_connector \ +kms_flip_event_leak IGT_LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=0 endif -- 2.0.3 ___ 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 i-g-t 1/1] Add kms_flip_event_leak to .gitignore
On 15 August 2014 20:14, Mason, Michael W michael.w.ma...@intel.com wrote: This patch just adds kms_flip_event_leak to tests/.gitignore. Patch merged, thanks. Signed-off-by: Mike Mason michael.w.ma...@intel.com --- tests/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/.gitignore b/tests/.gitignore index d14d87b..3da061e 100644 --- a/tests/.gitignore +++ b/tests/.gitignore @@ -121,6 +121,7 @@ kms_cursor_crc kms_fbc_crc kms_fence_pin_leak kms_flip +kms_flip_event_leak kms_flip_tiling kms_force_connector kms_mmio_vs_cs_flip -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/dp: split up panel power control from backlight pwm control
On 08/12/2014 07:11 AM, Jani Nikula wrote:
Make it possible to change panel power control backlight state without
touching the PWM. No functional changes.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e5ada4fbe945..d8baf60ff3fd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1384,7 +1384,8 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
intel_display_power_put(dev_priv, power_domain);
}
-void intel_edp_backlight_on(struct intel_dp *intel_dp)
+/* Enable backlight in the panel power control. */
+static void _intel_edp_backlight_on(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;
@@ -1392,13 +1393,6 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
u32 pp;
u32 pp_ctrl_reg;
- if (!is_edp(intel_dp))
- return;
-
- DRM_DEBUG_KMS(\n);
-
- intel_panel_enable_backlight(intel_dp-attached_connector);
-
/*
* If we enable the backlight right away following a panel power
* on, we may see slight flicker as the panel syncs with the eDP
@@ -1415,17 +1409,26 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
POSTING_READ(pp_ctrl_reg);
}
-void intel_edp_backlight_off(struct intel_dp *intel_dp)
+/* Enable backlight PWM and backlight PP control. */
+void intel_edp_backlight_on(struct intel_dp *intel_dp)
+{
+ if (!is_edp(intel_dp))
+ return;
+
+ DRM_DEBUG_KMS(\n);
+
+ intel_panel_enable_backlight(intel_dp-attached_connector);
+ _intel_edp_backlight_on(intel_dp);
+}
+
+/* Disable backlight in the panel power control. */
+static void _intel_edp_backlight_off(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct drm_i915_private *dev_priv = dev-dev_private;
u32 pp;
u32 pp_ctrl_reg;
- if (!is_edp(intel_dp))
- return;
-
- DRM_DEBUG_KMS(\n);
pp = ironlake_get_pp_control(intel_dp);
pp = ~EDP_BLC_ENABLE;
@@ -1436,7 +1439,17 @@ void intel_edp_backlight_off(struct intel_dp *intel_dp)
intel_dp-last_backlight_off = jiffies;
edp_wait_backlight_off(intel_dp);
+}
+
+/* Disable backlight PP control and backlight PWM. */
+void intel_edp_backlight_off(struct intel_dp *intel_dp)
+{
+ if (!is_edp(intel_dp))
+ return;
+
+ DRM_DEBUG_KMS(\n);
+ _intel_edp_backlight_off(intel_dp);
intel_panel_disable_backlight(intel_dp-attached_connector);
}
Patch works as expected.
Some day we need to rename intel_panel_disable_backlight() to
intel_panel_disable_backlight_pwm() to make this code more readable as
all intel_panel_backlight_ methods only affect the PWM.
Clint
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: HDMI pixel replication modes now hactive of 720 for pixel replication
On 08/12/2014 04:07 AM, Ville Syrjälä wrote:
On Tue, Jul 29, 2014 at 02:58:23PM -0700, clinton.a.tay...@intel.com wrote:
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,
I think the best thing here might be to halve all the horizontal
timings (and the clock), and maybe do it with an explicit /2 to
remind people that this is a bit special, and also the spec lists
the doubled timings, so it's maybe a bit easier to compare with the
spec that way.
So perhaps something like this:
DRM_MODE(..., 27000/2, 1440/2, 1478/2, ...
snip
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2422413..f8cdf7f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -918,6 +918,19 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
intel_hdmi-color_range = 0;
}
+ /* Adjust pipe timings for pixel doubled modes */
+ if ((adjusted_mode-flags DRM_MODE_FLAG_DBLCLK)) {
+ adjusted_mode-hsync_start /= 2;
+ adjusted_mode-hsync_end /= 2;
+ adjusted_mode-htotal /= 2;
+
+ drm_mode_set_crtcinfo(adjusted_mode, 0);
+
+ /* Set 2x pixel double on pipe */
+ pipe_config-pixel_multiplier = 2;
+ pipe_config-port_clock = adjusted_mode-crtc_clock;
+ }
If you halve the timings already in drm_edid.c all of this would be
reduced to just:
if (adjusted_mode-flags DRM_MODE_FLAG_DBLCLK)
pipe_config-pixel_multiplier = 2;
+
if (intel_hdmi-color_range)
pipe_config-limited_color_range = true;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Sorry, I missed this comment completely before I submitted the second
patch to dri-devel. I will be making changes to the second patch only
based on the feedback so far.
Thanks,
Clint
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/edid: Reduce horizontal timings for pixel replicated modes
On 08/14/2014 11:48 AM, Ville Syrjälä wrote:
On Thu, Aug 14, 2014 at 11:09:25AM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor clinton.a.tay...@intel.com
Pixel replicated modes should be 720 horizontal pixel and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently fails for all pixel replicated modes. This change fizes
the HDMI certification issues with 480i/576i.
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
drivers/gpu/drm/drm_edid.c| 100 ++---
drivers/gpu/drm/i915/intel_hdmi.c | 14 +-
2 files changed, 63 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f905c63..c7a26a7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -632,27 +632,27 @@ 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,
- 1602, 1716, 0, 480, 488, 494, 525, 0,
+ /* 6 - 720(1440)x480i@60Hz */
+ { DRM_MODE(720x480i, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 0, 480, 488, 494, 525, 0,
As stated before I think I would have preferred explicit /2 here, but
if you prefer to have it this way I can live with it.
Sorry, I missed the other patches comments. The CEA-861-E specification
actually has the pixel doubled values in (Table 3) the detailed sync
information data, so it does make sense to have the doubled values in
the table with /2. I prefer the actual values myself, but I am willing
to use either method.
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,
- 1602, 1716, 0, 480, 488, 494, 525, 0,
+ /* 7 - 720(1440)x480i@60Hz */
+ { DRM_MODE(720x480i, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 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,
- 1602, 1716, 0, 240, 244, 247, 262, 0,
+ /* 8 - 720(1440)x240@60Hz */
+ { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 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,
- 1602, 1716, 0, 240, 244, 247, 262, 0,
+ /* 9 - 720(1440)x240@60Hz */
+ { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 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_16_9, },
@@ -714,27 +714,27 @@ 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,
- 1590, 1728, 0, 576, 580, 586, 625, 0,
+ /* 21 - 720(1440)x576i@50Hz */
+ { DRM_MODE(720x576i, DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+ 795, 864, 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,
- 1590, 1728, 0, 576, 580, 586, 625, 0,
+ /* 22 - 720(1440)x576i@50Hz */
+ { DRM_MODE(720x576i, DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+ 795, 864, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
[Intel-gfx] [PATCH v2 i-g-t 1/1] scripts: Allow multiple -t and -x regular expressions for run-tests.sh
Piglit allows multiple -t and -x regular expressions to be
given on the command line. This patch enables run-tests.sh to
support that as well.
Signed-off-by: Mike Mason michael.w.ma...@intel.com
---
scripts/run-tests.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh
index cf77473..d0e0c67 100755
--- a/scripts/run-tests.sh
+++ b/scripts/run-tests.sh
@@ -55,8 +55,10 @@ function print_help {
echo (default: $RESULTS)
echo -s create html summary
echo -t regex only include tests that match the regular
expression
+ echo (can be used more than once)
echo -v enable verbose mode
echo -x regex exclude tests that match the regular expression
+ echo (can be used more than once)
echo
echo Useful patterns for test filtering are described in
tests/NAMING-CONVENTION
}
@@ -78,9 +80,9 @@ while getopts :dhlr:st:vx: opt; do
l) list_tests; exit ;;
r) RESULTS=$OPTARG ;;
s) SUMMARY=html ;;
- t) FILTER=-t $OPTARG ;;
+ t) FILTER=$FILTER -t $OPTARG ;;
v) VERBOSE=-v ;;
- x) EXCLUDE=-x $OPTARG ;;
+ x) EXCLUDE=$EXCLUDE -x $OPTARG ;;
:)
echo Option -$OPTARG requires an argument.
exit 1
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 i-g-t 1/1] tests: Fix seg fault when gem_mmap is run without specifying a subtest
gem_mmap seg faults when all tests are run together. This occurs because
the new-object subtest closes the gem object, but short-mmap assumes
it still exists. Thus gem_mmap__cpu() returns nil for addr and memset()
seg faults. This patch makes new-object and short-mmap create and
close their own gem objects.
Signed-off-by: Mike Mason michael.w.ma...@intel.com
---
tests/gem_mmap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/gem_mmap.c b/tests/gem_mmap.c
index 334bd76..33ffe45 100644
--- a/tests/gem_mmap.c
+++ b/tests/gem_mmap.c
@@ -62,10 +62,8 @@ igt_main
igt_assert(ret == -1 errno == ENOENT);
}
- igt_fixture
- handle = gem_create(fd, OBJECT_SIZE);
-
igt_subtest(new-object) {
+ handle = gem_create(fd, OBJECT_SIZE);
arg.handle = handle;
arg.offset = 0;
arg.size = OBJECT_SIZE;
@@ -94,9 +92,11 @@ igt_main
igt_subtest(short-mmap) {
igt_assert(OBJECT_SIZE 4096);
+ handle = gem_create(fd, OBJECT_SIZE);
addr = gem_mmap__cpu(fd, handle, 4096, PROT_WRITE);
memset(addr, 0, 4096);
munmap(addr, 4096);
+ gem_close(fd, handle);
}
igt_fixture
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/dp: make backlight bl_power control power sequencer backlight
On 08/12/2014 07:11 AM, Jani Nikula wrote:
This lets the userspace switch off the backlight using the backlight
class sysfs bl_power file. The switch is done using the power sequencer;
the backlight PWM, and everything else, remains enabled. The display
backlight won't draw power, but for maximum power savings the encoder
needs to be switched off.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d8baf60ff3fd..f6e3e9a906b0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1453,6 +1453,27 @@ void intel_edp_backlight_off(struct intel_dp *intel_dp)
intel_panel_disable_backlight(intel_dp-attached_connector);
}
+/*
+ * Hook for controlling the panel power control backlight through the bl_power
+ * sysfs attribute. Take care to handle multiple calls.
+ */
+static void intel_edp_backlight_power(struct intel_connector *connector,
+ bool enable)
+{
+ struct intel_dp *intel_dp = intel_attached_dp(connector-base);
+ bool is_enabled = ironlake_get_pp_control(intel_dp) EDP_BLC_ENABLE;
+
+ if (is_enabled == enable)
+ return;
+
+ DRM_DEBUG_KMS(\n);
+
+ if (enable)
+ _intel_edp_backlight_on(intel_dp);
+ else
+ _intel_edp_backlight_off(intel_dp);
Is there a good reason why we leave the PWM enabled? There is a small
power requirement to leave the PWM enabled.
+}
+
static void ironlake_edp_pll_on(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -4579,6 +4600,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
}
intel_panel_init(intel_connector-panel, fixed_mode, downclock_mode);
+ intel_connector-panel.backlight_power = intel_edp_backlight_power;
intel_panel_setup_backlight(connector);
return true;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix i915_frequency_info on BDW
On Fri, Aug 15, 2014 at 10:12 AM, Paulo Zanoni przan...@gmail.com wrote:
2014-08-15 13:50 GMT-03:00 Rodrigo Vivi rodrigo.v...@gmail.com:
On Fri, Aug 1, 2014 at 2:14 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The GEN6_PM* registers don't exist on BDW anymore, so when we read
this file we trigger unclaimed register errors. The equivalent BDW
register for PMs is GEN8_GT_I*R(2), so use it.
Testcase: igt/pm_rpm/debugfs-read
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e737b7..17bd20ff 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1024,6 +1024,7 @@ static int i915_frequency_info(struct seq_file *m,
void *unused)
u32 rpstat, cagf, reqf;
u32 rpupei, rpcurup, rpprevup;
u32 rpdownei, rpcurdown, rpprevdown;
+ u32 pm_ier, pm_imr, pm_isr, pm_iir, pm_mask;
int max_freq;
/* RPSTAT1 is in the GT power well */
@@ -1061,12 +1062,21 @@ static int i915_frequency_info(struct seq_file
*m,
void *unused)
gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
mutex_unlock(dev-struct_mutex);
+ if (IS_GEN6(dev) || IS_GEN7(dev)) {
+ pm_ier = I915_READ(GEN6_PMIER);
+ pm_imr = I915_READ(GEN6_PMIMR);
+ pm_isr = I915_READ(GEN6_PMISR);
+ pm_iir = I915_READ(GEN6_PMIIR);
+ pm_mask = I915_READ(GEN6_PMINTRMSK);
+ } else {
+ pm_ier = I915_READ(GEN8_GT_IER(2));
+ pm_imr = I915_READ(GEN8_GT_IMR(2));
+ pm_isr = I915_READ(GEN8_GT_ISR(2));
+ pm_iir = I915_READ(GEN8_GT_IIR(2));
Why do we care only about GT(2) interrupt reg?
What about other 0, 1 and 3 regs?
Because, as far as I could see, the GEN8_GT(2) register is the one
that seems to be equivalent to the old GEN6_PM register in terms of
the functionality debugged by this function: it is the one that
contains all the RPS stuff. Another thing that influenced me to take
this decision was that, for example, snb_update_pm_irq() touches
GEN6_PM, while bdw_update_pm_irq() touches only GEN8_GT(2). But I'm
not a great user of this code, so maybe we do want more interrupts.
OTOH, if we want all, there's always i915_interrupt_info.
Yeah, makes sense.
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Could this explain GT3 failures?
Which GT3 failures? I don't understand why you ask this.
forget about the gt3 on this, and thanks for the ideas!
+ pm_mask = I915_READ(GEN6_PMINTRMSK);
+ }
seq_printf(m, PM IER=0x%08x IMR=0x%08x ISR=0x%08x
IIR=0x%08x, MASK=0x%08x\n,
- I915_READ(GEN6_PMIER),
- I915_READ(GEN6_PMIMR),
- I915_READ(GEN6_PMISR),
- I915_READ(GEN6_PMIIR),
- I915_READ(GEN6_PMINTRMSK));
+ pm_ier, pm_imr, pm_isr, pm_iir, pm_mask);
seq_printf(m, GT_PERF_STATUS: 0x%08x\n,
gt_perf_status);
seq_printf(m, Render p-state ratio: %d\n,
(gt_perf_status 0xff00) 8);
--
2.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
--
Paulo Zanoni
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to haswell_crtc_disable()
From: Ville Syrjälä ville.syrj...@linux.intel.com Somehow the intel_ddi_set_vc_payload_alloc(false) call has ended up in ironlake_crtc_disable() rather than haswell_crtc_disable(). Move it to the correct place. intel_ddi_disable_transcoder_func() already disables the vc payload allocation so this doesn't actually do anything more. The spec says we should wait for some kind of ack after frobbing the bit. We don't appear to do that currently, but if and when someone decides that we should do it, intel_ddi_set_vc_payload_alloc() would appear to be be the right place for it. So having the function call in haswell_crtc_disable() seems like the right thing for the future even if it does nothing currently. Cc: Dave Airlie airl...@redhat.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 09c7298..121024e 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4169,10 +4169,6 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc) intel_set_pch_fifo_underrun_reporting(dev, pipe, false); intel_disable_pipe(dev_priv, pipe); - - if (intel_crtc-config.dp_encoder_is_mst) - intel_ddi_set_vc_payload_alloc(crtc, false); - ironlake_pfit_disable(intel_crtc); for_each_encoder_on_crtc(dev, crtc, encoder) @@ -4240,6 +4236,9 @@ static void haswell_crtc_disable(struct drm_crtc *crtc) intel_set_pch_fifo_underrun_reporting(dev, TRANSCODER_A, false); intel_disable_pipe(dev_priv, pipe); + if (intel_crtc-config.dp_encoder_is_mst) + intel_ddi_set_vc_payload_alloc(crtc, false); + intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder); ironlake_pfit_disable(intel_crtc); -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/14] drm/i915: Parametrize PANEL_PORT_SELECT_VLV
From: Ville Syrjälä ville.syrj...@linux.intel.com
Passing the port as a parameter to PANEL_PORT_SELECT_VLV results in
neater code. Sadly the PCH port select bits aren't suitable for the
same treatment and the resulting macro would be much uglier, so
leave those defines as is.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +--
drivers/gpu/drm/i915/intel_dp.c | 12
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index daac02b..9503d96 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5383,8 +5383,7 @@ enum punit_power_well {
#define PIPEA_PP_STATUS (VLV_DISPLAY_BASE + 0x61200)
#define PIPEA_PP_CONTROL(VLV_DISPLAY_BASE + 0x61204)
#define PIPEA_PP_ON_DELAYS (VLV_DISPLAY_BASE + 0x61208)
-#define PANEL_PORT_SELECT_DPB_VLV (1 30)
-#define PANEL_PORT_SELECT_DPC_VLV (2 30)
+#define PANEL_PORT_SELECT_VLV(port) ((port) 30)
#define PIPEA_PP_OFF_DELAYS (VLV_DISPLAY_BASE + 0x6120c)
#define PIPEA_PP_DIVISOR(VLV_DISPLAY_BASE + 0x61210)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4f69648..43dd226 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -308,9 +308,7 @@ vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
for (pipe = PIPE_A; pipe = PIPE_B; pipe++) {
u32 port_sel = I915_READ(VLV_PIPE_PP_ON_DELAYS(pipe))
PANEL_PORT_SELECT_MASK;
- if (port_sel == PANEL_PORT_SELECT_DPB_VLV port == PORT_B)
- return pipe;
- if (port_sel == PANEL_PORT_SELECT_DPC_VLV port == PORT_C)
+ if (port_sel == PANEL_PORT_SELECT_VLV(port))
return pipe;
}
@@ -4294,6 +4292,7 @@ intel_dp_init_panel_power_sequencer_registers(struct
drm_device *dev,
u32 pp_on, pp_off, pp_div, port_sel = 0;
int div = HAS_PCH_SPLIT(dev) ? intel_pch_rawclk(dev) :
intel_hrawclk(dev);
int pp_on_reg, pp_off_reg, pp_div_reg;
+ enum port port = dp_to_dig_port(intel_dp)-port;
if (HAS_PCH_SPLIT(dev)) {
pp_on_reg = PCH_PP_ON_DELAYS;
@@ -4328,12 +4327,9 @@ intel_dp_init_panel_power_sequencer_registers(struct
drm_device *dev,
/* Haswell doesn't have any port selection bits for the panel
* power sequencer any more. */
if (IS_VALLEYVIEW(dev)) {
- if (dp_to_dig_port(intel_dp)-port == PORT_B)
- port_sel = PANEL_PORT_SELECT_DPB_VLV;
- else
- port_sel = PANEL_PORT_SELECT_DPC_VLV;
+ port_sel = PANEL_PORT_SELECT_VLV(port);
} else if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) {
- if (dp_to_dig_port(intel_dp)-port == PORT_A)
+ if (port == PORT_A)
port_sel = PANEL_PORT_SELECT_DPA;
else
port_sel = PANEL_PORT_SELECT_DPD;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/14] drm/i915: edp vdd locking and prep for power sequencer kick
From: Ville Syrjälä ville.syrj...@linux.intel.com While wrestling with the VLV/CHV panel power sequencer I noticed the locking in our edp vdd code was rather broken. This series aims to fix that by introducing a power seqeuencer mutex. I was already thinking about using the aux.hw_mutex for this since it's already locked around the aux -transfer() function, but the VLV/CHV multiple power sequencer issue requires a single lock instead of per-port. At the end of the series there's a bit of reordering of the DP port enable/disable sequences to make subsequent power sequencer kick patches easier. The last patch fixes the wait_pipe_off() timeouts on my ILK. Strictly speaking it shouldn't be part of this series, but I couldn't really test this on my ILK without suffering tons of warnings so I included it here anyway. Ville Syrjälä (14): drm/i915: Parametrize PANEL_PORT_SELECT_VLV drm/i915: Reorganize vlv eDP reboot notifier drm/i915: Use intel_edp_panel_vdd_on() in intel_dp_probe_mst() drm/i915: Rename edp vdd funcs for consistency drm/i915: Add a note explaining vdd on/off handling in intel_dp_aux_ch() drm/i915: Replace big nested if block with early return drm/i915: Warn about want_panel_vdd in edp_panel_vdd_off_sync() drm/i915: Flatten intel_edp_panel_vdd_on() drm/i915: Fix edp vdd locking drm/i915: Track which port is using which pipe's power sequencer drm/i915: Be more careful when picking the initial power sequencer pipe drm/i915: Turn on panel power before doing aux transfers drm/i915: Enable DP port earlier drm/i915: Move DP port disable to post_disable for pch platforms drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_reg.h | 3 +- drivers/gpu/drm/i915/intel_display.c | 2 + drivers/gpu/drm/i915/intel_dp.c | 619 +-- drivers/gpu/drm/i915/intel_drv.h | 6 + 5 files changed, 463 insertions(+), 170 deletions(-) -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/14] drm/i915: Reorganize vlv eDP reboot notifier
From: Ville Syrjälä ville.syrj...@linux.intel.com
Move the vlv_power_sequencer_pipe() after the IS_VALLEYVIEW() check
and flatten the rest of the function.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 43dd226..a9ed2a6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -347,22 +347,22 @@ static int edp_notify_handler(struct notifier_block
*this, unsigned long code,
struct drm_i915_private *dev_priv = dev-dev_private;
u32 pp_div;
u32 pp_ctrl_reg, pp_div_reg;
- enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
+ enum pipe pipe;
- if (!is_edp(intel_dp) || code != SYS_RESTART)
+ if (!IS_VALLEYVIEW(dev) || !is_edp(intel_dp) || code != SYS_RESTART)
return 0;
- if (IS_VALLEYVIEW(dev)) {
- pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
- pp_div_reg = VLV_PIPE_PP_DIVISOR(pipe);
- pp_div = I915_READ(pp_div_reg);
- pp_div = PP_REFERENCE_DIVIDER_MASK;
+ pipe = vlv_power_sequencer_pipe(intel_dp);
- /* 0x1F write to PP_DIV_REG sets max cycle delay */
- I915_WRITE(pp_div_reg, pp_div | 0x1F);
- I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
- msleep(intel_dp-panel_power_cycle_delay);
- }
+ pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
+ pp_div_reg = VLV_PIPE_PP_DIVISOR(pipe);
+ pp_div = I915_READ(pp_div_reg);
+ pp_div = PP_REFERENCE_DIVIDER_MASK;
+
+ /* 0x1F write to PP_DIV_REG sets max cycle delay */
+ I915_WRITE(pp_div_reg, pp_div | 0x1F);
+ I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
+ msleep(intel_dp-panel_power_cycle_delay);
return 0;
}
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/14] drm/i915: Rename edp vdd funcs for consistency
From: Ville Syrjälä ville.syrj...@linux.intel.com
edp_* are now the lower level functions and intel_edp_* the higher level
ones. One should use them in pairs.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 28d0183..30943a5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -111,7 +111,7 @@ static struct intel_dp *intel_attached_dp(struct
drm_connector *connector)
}
static void intel_dp_link_down(struct intel_dp *intel_dp);
-static bool _edp_panel_vdd_on(struct intel_dp *intel_dp);
+static bool edp_panel_vdd_on(struct intel_dp *intel_dp);
static void edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync);
int
@@ -533,7 +533,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
bool has_aux_irq = HAS_AUX_IRQ(dev);
bool vdd;
- vdd = _edp_panel_vdd_on(intel_dp);
+ vdd = edp_panel_vdd_on(intel_dp);
/* dp aux is extremely sensitive to irq latency, hence request the
* lowest possible wakeup latency and so prevent the cpu from going into
@@ -1165,7 +1165,7 @@ static u32 ironlake_get_pp_control(struct intel_dp
*intel_dp)
return control;
}
-static bool _edp_panel_vdd_on(struct intel_dp *intel_dp)
+static bool edp_panel_vdd_on(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -1216,7 +1216,7 @@ static bool _edp_panel_vdd_on(struct intel_dp *intel_dp)
void intel_edp_panel_vdd_on(struct intel_dp *intel_dp)
{
if (is_edp(intel_dp)) {
- bool vdd = _edp_panel_vdd_on(intel_dp);
+ bool vdd = edp_panel_vdd_on(intel_dp);
WARN(!vdd, eDP VDD already requested on\n);
}
@@ -1299,6 +1299,11 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp,
bool sync)
edp_panel_vdd_schedule_off(intel_dp);
}
+static void intel_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
+{
+ return edp_panel_vdd_off(intel_dp, sync);
+}
+
void intel_edp_panel_on(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
@@ -2102,7 +2107,7 @@ static void intel_enable_dp(struct intel_encoder *encoder)
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_edp_panel_vdd_off(intel_dp, true);
intel_dp_complete_link_train(intel_dp);
intel_dp_stop_link_train(intel_dp);
}
@@ -3405,7 +3410,7 @@ intel_dp_probe_oui(struct intel_dp *intel_dp)
DRM_DEBUG_KMS(Branch OUI: %02hx%02hx%02hx\n,
buf[0], buf[1], buf[2]);
- edp_panel_vdd_off(intel_dp, false);
+ intel_edp_panel_vdd_off(intel_dp, false);
}
static bool
@@ -3429,7 +3434,7 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
intel_dp-is_mst = false;
}
}
- edp_panel_vdd_off(intel_dp, false);
+ intel_edp_panel_vdd_off(intel_dp, false);
drm_dp_mst_topology_mgr_set_mst(intel_dp-mst_mgr, intel_dp-is_mst);
return intel_dp-is_mst;
@@ -4527,7 +4532,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
/* Cache DPCD and EDID for edp. */
intel_edp_panel_vdd_on(intel_dp);
has_dpcd = intel_dp_get_dpcd(intel_dp);
- edp_panel_vdd_off(intel_dp, false);
+ intel_edp_panel_vdd_off(intel_dp, false);
if (has_dpcd) {
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11)
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/14] drm/i915: Add a note explaining vdd on/off handling in intel_dp_aux_ch()
From: Ville Syrjälä ville.syrj...@linux.intel.com Add a comment to explain why we care about the current want_panel_vdd state in intel_dp_aux_ch(). Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_dp.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 30943a5..19a818f 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -533,6 +533,12 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, bool has_aux_irq = HAS_AUX_IRQ(dev); bool vdd; + /* +* We will be called with VDD already enabled for dpcd/edid/oui reads. +* In such cases we want to leave VDD enabled and it's up to upper layers +* to turn it off. But for eg. i2c-dev access we need to turn it on/off +* ourselves. +*/ vdd = edp_panel_vdd_on(intel_dp); /* dp aux is extremely sensitive to irq latency, hence request the -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/14] drm/i915: Flatten intel_edp_panel_vdd_on()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Less pointless indentation is always nice. There will be a bit more
code in this function once the power sequencer locking is fixed.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0fb510c..7ae9a9a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1221,11 +1221,14 @@ static bool edp_panel_vdd_on(struct intel_dp *intel_dp)
void intel_edp_panel_vdd_on(struct intel_dp *intel_dp)
{
- if (is_edp(intel_dp)) {
- bool vdd = edp_panel_vdd_on(intel_dp);
+ bool vdd;
- WARN(!vdd, eDP VDD already requested on\n);
- }
+ if (!is_edp(intel_dp))
+ return;
+
+ vdd = edp_panel_vdd_on(intel_dp);
+
+ WARN(!vdd, eDP VDD already requested on\n);
}
static void edp_panel_vdd_off_sync(struct intel_dp *intel_dp)
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/14] drm/i915: Warn about want_panel_vdd in edp_panel_vdd_off_sync()
From: Ville Syrjälä ville.syrj...@linux.intel.com If we force vdd off warn if someone is still using it. With this change the delayed vdd off work needs to check want_panel_vdd itself to make sure it doesn't try to turn vdd off when someone is using it. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_dp.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index e6b4d4d..0fb510c 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1241,7 +1241,9 @@ static void edp_panel_vdd_off_sync(struct intel_dp *intel_dp) WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex)); - if (intel_dp-want_panel_vdd || !edp_have_panel_vdd(intel_dp)) + WARN_ON(intel_dp-want_panel_vdd); + + if (!edp_have_panel_vdd(intel_dp)) return; DRM_DEBUG_KMS(Turning eDP VDD off\n); @@ -1273,7 +1275,8 @@ static void edp_panel_vdd_work(struct work_struct *__work) struct drm_device *dev = intel_dp_to_dev(intel_dp); drm_modeset_lock(dev-mode_config.connection_mutex, NULL); - edp_panel_vdd_off_sync(intel_dp); + if (!intel_dp-want_panel_vdd) + edp_panel_vdd_off_sync(intel_dp); drm_modeset_unlock(dev-mode_config.connection_mutex); } -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/14] drm/i915: Replace big nested if block with early return
From: Ville Syrjälä ville.syrj...@linux.intel.com
Looks nicer.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 19a818f..e6b4d4d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1232,38 +1232,38 @@ static void edp_panel_vdd_off_sync(struct intel_dp
*intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_digital_port *intel_dig_port =
+ dp_to_dig_port(intel_dp);
+ struct intel_encoder *intel_encoder = intel_dig_port-base;
+ enum intel_display_power_domain power_domain;
u32 pp;
u32 pp_stat_reg, pp_ctrl_reg;
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
- if (!intel_dp-want_panel_vdd edp_have_panel_vdd(intel_dp)) {
- struct intel_digital_port *intel_dig_port =
- dp_to_dig_port(intel_dp);
- struct intel_encoder *intel_encoder = intel_dig_port-base;
- enum intel_display_power_domain power_domain;
+ if (intel_dp-want_panel_vdd || !edp_have_panel_vdd(intel_dp))
+ return;
- DRM_DEBUG_KMS(Turning eDP VDD off\n);
+ DRM_DEBUG_KMS(Turning eDP VDD off\n);
- pp = ironlake_get_pp_control(intel_dp);
- pp = ~EDP_FORCE_VDD;
+ pp = ironlake_get_pp_control(intel_dp);
+ pp = ~EDP_FORCE_VDD;
- pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
- pp_stat_reg = _pp_stat_reg(intel_dp);
+ pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
+ pp_stat_reg = _pp_stat_reg(intel_dp);
- I915_WRITE(pp_ctrl_reg, pp);
- POSTING_READ(pp_ctrl_reg);
+ I915_WRITE(pp_ctrl_reg, pp);
+ POSTING_READ(pp_ctrl_reg);
- /* Make sure sequencer is idle before allowing subsequent
activity */
- DRM_DEBUG_KMS(PP_STATUS: 0x%08x PP_CONTROL: 0x%08x\n,
- I915_READ(pp_stat_reg), I915_READ(pp_ctrl_reg));
+ /* Make sure sequencer is idle before allowing subsequent activity */
+ DRM_DEBUG_KMS(PP_STATUS: 0x%08x PP_CONTROL: 0x%08x\n,
+ I915_READ(pp_stat_reg), I915_READ(pp_ctrl_reg));
- if ((pp POWER_TARGET_ON) == 0)
- intel_dp-last_power_cycle = jiffies;
+ if ((pp POWER_TARGET_ON) == 0)
+ intel_dp-last_power_cycle = jiffies;
- power_domain = intel_display_port_power_domain(intel_encoder);
- intel_display_power_put(dev_priv, power_domain);
- }
+ power_domain = intel_display_port_power_domain(intel_encoder);
+ intel_display_power_put(dev_priv, power_domain);
}
static void edp_panel_vdd_work(struct work_struct *__work)
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/14] drm/i915: Be more careful when picking the initial power sequencer pipe
From: Ville Syrjälä ville.syrj...@linux.intel.com
Try to make sure we find the power sequencer that the BIOS used
by first looking for one which has the panel power enabled, then
fall back to one with VDD force bit enabled, and finally look at
just the port select bits. This should make us pick the correct
power sequencer when the BIOS has already enabled the panel.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4614e6e..4952783 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -341,9 +341,31 @@ vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
return intel_dp-pps_pipe;
}
+typedef bool (*vlv_pipe_check)(struct drm_i915_private *dev_priv,
+ enum pipe pipe);
+
+static bool vlv_pipe_has_pp_on(struct drm_i915_private *dev_priv,
+ enum pipe pipe)
+{
+ return I915_READ(VLV_PIPE_PP_STATUS(pipe)) PP_ON;
+}
+
+static bool vlv_pipe_has_vdd_on(struct drm_i915_private *dev_priv,
+ enum pipe pipe)
+{
+ return I915_READ(VLV_PIPE_PP_CONTROL(pipe)) EDP_FORCE_VDD;
+}
+
+static bool vlv_pipe_any(struct drm_i915_private *dev_priv,
+enum pipe pipe)
+{
+ return true;
+}
+
static enum pipe
vlv_initial_power_sequencer_pipe(struct drm_i915_private *dev_priv,
-enum port port)
+enum port port,
+vlv_pipe_check pipe_check)
{
enum pipe pipe;
@@ -354,6 +376,9 @@ vlv_initial_power_sequencer_pipe(struct drm_i915_private
*dev_priv,
if (port_sel != PANEL_PORT_SELECT_VLV(port))
continue;
+ if (!pipe_check(dev_priv, pipe))
+ continue;
+
return pipe;
}
@@ -372,7 +397,14 @@ vlv_initial_power_sequencer_setup(struct intel_dp
*intel_dp)
lockdep_assert_held(dev_priv-pps_mutex);
/* try to find a pipe with this port selected */
- intel_dp-pps_pipe = vlv_initial_power_sequencer_pipe(dev_priv, port);
+ /* first pick one where the panel is on */
+ intel_dp-pps_pipe = vlv_initial_power_sequencer_pipe(dev_priv, port,
vlv_pipe_has_pp_on);
+ /* didn't find one? pick one where vdd is on */
+ if (intel_dp-pps_pipe == INVALID_PIPE)
+ intel_dp-pps_pipe = vlv_initial_power_sequencer_pipe(dev_priv,
port, vlv_pipe_has_vdd_on);
+ /* didn't find one? pick one with just the correct port */
+ if (intel_dp-pps_pipe == INVALID_PIPE)
+ intel_dp-pps_pipe = vlv_initial_power_sequencer_pipe(dev_priv,
port, vlv_pipe_any);
/* didn't find one? just let vlv_power_sequencer_pipe() pick one when
needed */
if (intel_dp-pps_pipe == INVALID_PIPE) {
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/14] drm/i915: Turn on panel power before doing aux transfers
From: Ville Syrjälä ville.syrj...@linux.intel.com On VLV/CHV the panel power sequencer may need to be kicked a bit to lock onto the new port, and that needs to happen before any aux transfers are attempted if we want the aux transfers to actaully succeed. So turn on panel power (part of the kick) before aux transfers (DPMS_ON + link training). This also matches the documented modeset sequence better for pch platforms. The documentation doesn't explicitly state anything about the DPMS or link training DPCD writes, but the panel power on step is always listed before link training is mentioned. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_dp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 4952783..28bc652 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2275,10 +2275,10 @@ static void intel_enable_dp(struct intel_encoder *encoder) return; intel_edp_panel_vdd_on(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); intel_edp_panel_vdd_off(intel_dp, true); + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + intel_dp_start_link_train(intel_dp); intel_dp_complete_link_train(intel_dp); intel_dp_stop_link_train(intel_dp); } -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/14] drm/i915: Enable DP port earlier
From: Ville Syrjälä ville.syrj...@linux.intel.com
Bspec says we should enable the DP port before enabling panel power,
and that the port must be enabled with training pattern 1. Do so.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 172 +++-
1 file changed, 100 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 28bc652..12925be 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2264,6 +2264,104 @@ static void chv_post_disable_dp(struct intel_encoder
*encoder)
mutex_unlock(dev_priv-dpio_lock);
}
+static void
+_intel_dp_set_link_train(struct intel_dp *intel_dp,
+uint32_t *DP,
+uint8_t dp_train_pat)
+{
+ 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;
+ enum port port = intel_dig_port-port;
+
+ if (HAS_DDI(dev)) {
+ uint32_t temp = I915_READ(DP_TP_CTL(port));
+
+ if (dp_train_pat DP_LINK_SCRAMBLING_DISABLE)
+ temp |= DP_TP_CTL_SCRAMBLE_DISABLE;
+ else
+ temp = ~DP_TP_CTL_SCRAMBLE_DISABLE;
+
+ temp = ~DP_TP_CTL_LINK_TRAIN_MASK;
+ switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
+ case DP_TRAINING_PATTERN_DISABLE:
+ temp |= DP_TP_CTL_LINK_TRAIN_NORMAL;
+
+ break;
+ case DP_TRAINING_PATTERN_1:
+ temp |= DP_TP_CTL_LINK_TRAIN_PAT1;
+ break;
+ case DP_TRAINING_PATTERN_2:
+ temp |= DP_TP_CTL_LINK_TRAIN_PAT2;
+ break;
+ case DP_TRAINING_PATTERN_3:
+ temp |= DP_TP_CTL_LINK_TRAIN_PAT3;
+ break;
+ }
+ I915_WRITE(DP_TP_CTL(port), temp);
+
+ } else if (HAS_PCH_CPT(dev) (IS_GEN7(dev) || port != PORT_A)) {
+ *DP = ~DP_LINK_TRAIN_MASK_CPT;
+
+ switch (dp_train_pat DP_TRAINING_PATTERN_MASK) {
+ case DP_TRAINING_PATTERN_DISABLE:
+ *DP |= DP_LINK_TRAIN_OFF_CPT;
+ break;
+ case DP_TRAINING_PATTERN_1:
+ *DP |= DP_LINK_TRAIN_PAT_1_CPT;
+ break;
+ case DP_TRAINING_PATTERN_2:
+ *DP |= DP_LINK_TRAIN_PAT_2_CPT;
+ break;
+ case DP_TRAINING_PATTERN_3:
+ DRM_ERROR(DP training pattern 3 not supported\n);
+ *DP |= DP_LINK_TRAIN_PAT_2_CPT;
+ break;
+ }
+
+ } else {
+ 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:
+ *DP |= DP_LINK_TRAIN_OFF;
+ break;
+ case DP_TRAINING_PATTERN_1:
+ *DP |= DP_LINK_TRAIN_PAT_1;
+ break;
+ case DP_TRAINING_PATTERN_2:
+ *DP |= DP_LINK_TRAIN_PAT_2;
+ break;
+ case DP_TRAINING_PATTERN_3:
+ 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;
+ }
+ }
+}
+
+static void intel_dp_enable_port(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ intel_dp-DP |= DP_PORT_EN;
+
+ /* enable with pattern 1 (as per spec) */
+ _intel_dp_set_link_train(intel_dp, intel_dp-DP,
+DP_TRAINING_PATTERN_1);
+
+ I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+ POSTING_READ(intel_dp-output_reg);
+}
+
static void intel_enable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
@@ -2274,6 +2372,7 @@ static void intel_enable_dp(struct intel_encoder *encoder)
if (WARN_ON(dp_reg DP_PORT_EN))
return;
+ intel_dp_enable_port(intel_dp);
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_on(intel_dp);
intel_edp_panel_vdd_off(intel_dp, true);
@@ -3174,81 +3273,10 @@
[Intel-gfx] [PATCH 03/14] drm/i915: Use intel_edp_panel_vdd_on() in intel_dp_probe_mst()
From: Ville Syrjälä ville.syrj...@linux.intel.com
We want to use the higher level vdd on func here. Not a big deal
yet (we'd just get the warn when things go awry) but when the
locking gets fixed this becomes more important.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.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 a9ed2a6..28d0183 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3419,7 +3419,7 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
if (intel_dp-dpcd[DP_DPCD_REV] 0x12)
return false;
- _edp_panel_vdd_on(intel_dp);
+ intel_edp_panel_vdd_on(intel_dp);
if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_MSTM_CAP, buf, 1)) {
if (buf[0] DP_MST_CAP) {
DRM_DEBUG_KMS(Sink is MST capable\n);
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/14] drm/i915: Move DP port disable to post_disable for pch platforms
From: Ville Syrjälä ville.syrj...@linux.intel.com
We need to turn the DP port off after the pipe, otherwise the pipe won't
turn off properly on certain pch platforms at least (happens on my ILK for
example). This also matches the BSpec modeset sequence better. We still
don't match the spec exactly though (eg. audio disable should happen
much earlier), but at last this eliminates the nasty
wait_for_pipe_off() timeouts.
We already did the port disable after the pipe for VLV/CHV and for CPU
eDP.
For g4x leave the port disable where it is since that matches the
modeset sequence in the documentation and I don't have a suitable
machine to test if the other order would work.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 12925be..915d4ec 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2194,7 +2194,6 @@ void intel_edp_psr_init(struct drm_device *dev)
static void intel_disable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
- enum port port = dp_to_dig_port(intel_dp)-port;
struct drm_device *dev = encoder-base.dev;
/* Make sure the panel is off before trying to change the mode. But also
@@ -2204,21 +2203,19 @@ static void intel_disable_dp(struct intel_encoder
*encoder)
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_off(intel_dp);
- /* cpu edp my only be disable _after_ the cpu pipe/plane is disabled. */
- if (!(port == PORT_A || IS_VALLEYVIEW(dev)))
+ /* disable the port before the pipe on g4x */
+ if (INTEL_INFO(dev)-gen 5)
intel_dp_link_down(intel_dp);
}
-static void g4x_post_disable_dp(struct intel_encoder *encoder)
+static void ilk_post_disable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
enum port port = dp_to_dig_port(intel_dp)-port;
- if (port != PORT_A)
- return;
-
intel_dp_link_down(intel_dp);
- ironlake_edp_pll_off(intel_dp);
+ if (port == PORT_A)
+ ironlake_edp_pll_off(intel_dp);
}
static void vlv_post_disable_dp(struct intel_encoder *encoder)
@@ -5044,7 +5041,8 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
} else {
intel_encoder-pre_enable = g4x_pre_enable_dp;
intel_encoder-enable = g4x_enable_dp;
- intel_encoder-post_disable = g4x_post_disable_dp;
+ if (INTEL_INFO(dev)-gen = 5)
+ intel_encoder-post_disable = ilk_post_disable_dp;
}
intel_dig_port-port = port;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/14] drm/i915: Fix edp vdd locking
From: Ville Syrjälä ville.syrj...@linux.intel.com
Introduce a new mutex (pps_mutex) to protect the power sequencer
state. For now this state includes want_panel_vdd as well as the
power sequencer registers.
We need a single mutex (as opposed to per port) because later on we
will need to deal with VLV/CHV which have multiple power sequencer
which can be reassigned to different ports.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/intel_display.c | 2 +
drivers/gpu/drm/i915/intel_dp.c | 97 +++-
3 files changed, 90 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4754328..8684898 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1501,6 +1501,9 @@ struct drm_i915_private {
/* LVDS info */
bool no_aux_handshake;
+ /* protects panel power sequencer state */
+ struct mutex pps_mutex;
+
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume
965 */
int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3f8e037..04c0e5d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12437,6 +12437,8 @@ static void intel_init_display(struct drm_device *dev)
}
intel_panel_init_backlight_funcs(dev);
+
+ mutex_init(dev_priv-pps_mutex);
}
/*
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7ae9a9a..556e4de 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -300,6 +300,8 @@ vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
enum port port = intel_dig_port-port;
enum pipe pipe;
+ lockdep_assert_held(dev_priv-pps_mutex);
+
/* modeset should have pipe */
if (crtc)
return to_intel_crtc(crtc)-pipe;
@@ -352,6 +354,8 @@ static int edp_notify_handler(struct notifier_block *this,
unsigned long code,
if (!IS_VALLEYVIEW(dev) || !is_edp(intel_dp) || code != SYS_RESTART)
return 0;
+ mutex_lock(dev_priv-pps_mutex);
+
pipe = vlv_power_sequencer_pipe(intel_dp);
pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
@@ -364,6 +368,8 @@ static int edp_notify_handler(struct notifier_block *this,
unsigned long code,
I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
msleep(intel_dp-panel_power_cycle_delay);
+ mutex_unlock(dev_priv-pps_mutex);
+
return 0;
}
@@ -372,6 +378,8 @@ static bool edp_have_panel_power(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct drm_i915_private *dev_priv = dev-dev_private;
+ lockdep_assert_held(dev_priv-pps_mutex);
+
return (I915_READ(_pp_stat_reg(intel_dp)) PP_ON) != 0;
}
@@ -383,6 +391,8 @@ static bool edp_have_panel_vdd(struct intel_dp *intel_dp)
struct intel_encoder *intel_encoder = intel_dig_port-base;
enum intel_display_power_domain power_domain;
+ lockdep_assert_held(dev_priv-pps_mutex);
+
power_domain = intel_display_port_power_domain(intel_encoder);
return intel_display_power_enabled(dev_priv, power_domain)
(I915_READ(_pp_ctrl_reg(intel_dp)) EDP_FORCE_VDD) != 0;
@@ -533,6 +543,8 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
bool has_aux_irq = HAS_AUX_IRQ(dev);
bool vdd;
+ mutex_lock(dev_priv-pps_mutex);
+
/*
* We will be called with VDD already enabled for dpcd/edid/oui reads.
* In such cases we want to leave VDD enabled and it's up to upper
layers
@@ -648,6 +660,8 @@ out:
if (vdd)
edp_panel_vdd_off(intel_dp, false);
+ mutex_unlock(dev_priv-pps_mutex);
+
return ret;
}
@@ -1102,6 +1116,8 @@ static void wait_panel_status(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv = dev-dev_private;
u32 pp_stat_reg, pp_ctrl_reg;
+ lockdep_assert_held(dev_priv-pps_mutex);
+
pp_stat_reg = _pp_stat_reg(intel_dp);
pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
@@ -1165,6 +1181,8 @@ static u32 ironlake_get_pp_control(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
u32 control;
+ lockdep_assert_held(dev_priv-pps_mutex);
+
control = I915_READ(_pp_ctrl_reg(intel_dp));
control = ~PANEL_UNLOCK_MASK;
control |= PANEL_UNLOCK_REGS;
@@ -1182,6 +1200,8 @@ static bool edp_panel_vdd_on(struct intel_dp *intel_dp)
u32 pp_stat_reg, pp_ctrl_reg;
bool need_to_disable = !intel_dp-want_panel_vdd;
+ lockdep_assert_held(dev_priv-pps_mutex);
+
if
[Intel-gfx] [PATCH 10/14] drm/i915: Track which port is using which pipe's power sequencer
From: Ville Syrjälä ville.syrj...@linux.intel.com
VLV/CHV have a per-pipe panel power sequencer which locks onto the
port once used. We need to keep track wich power sequencers are
locked to which ports.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 185 ++-
drivers/gpu/drm/i915/intel_drv.h | 6 ++
2 files changed, 168 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 556e4de..4614e6e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -294,28 +294,99 @@ static enum pipe
vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct drm_crtc *crtc = intel_dig_port-base.base.crtc;
struct drm_device *dev = intel_dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- enum port port = intel_dig_port-port;
- enum pipe pipe;
+ struct intel_encoder *encoder;
+ unsigned int pipes = (1 PIPE_A) | (1 PIPE_B);
+ struct edp_power_seq power_seq;
lockdep_assert_held(dev_priv-pps_mutex);
- /* modeset should have pipe */
- if (crtc)
- return to_intel_crtc(crtc)-pipe;
+ if (intel_dp-pps_pipe != INVALID_PIPE)
+ return intel_dp-pps_pipe;
+
+ /*
+* We don't have power sequencer currently.
+* Pick one that's not used by other ports.
+*/
+ list_for_each_entry(encoder, dev-mode_config.encoder_list, base.head)
{
+ struct intel_dp *tmp;
+
+ if (encoder-type != INTEL_OUTPUT_EDP)
+ continue;
+
+ tmp = enc_to_intel_dp(encoder-base);
+
+ if (tmp-pps_pipe != INVALID_PIPE)
+ pipes = ~(1 tmp-pps_pipe);
+ }
+
+ /*
+* Didn't find one. This should not happen since there
+* are two power sequencers and up to two eDP ports.
+*/
+ if (WARN_ON(pipes == 0))
+ return PIPE_A;
+
+ intel_dp-pps_pipe = ffs(pipes) - 1;
+
+ DRM_DEBUG_KMS(picked pipe %c power sequencer for port %c\n,
+ pipe_name(intel_dp-pps_pipe),
port_name(intel_dig_port-port));
+
+ /* init power sequencer on this pipe and port */
+ intel_dp_init_panel_power_sequencer(dev, intel_dp, power_seq);
+ intel_dp_init_panel_power_sequencer_registers(dev, intel_dp,
+ power_seq);
+
+ return intel_dp-pps_pipe;
+}
+
+static enum pipe
+vlv_initial_power_sequencer_pipe(struct drm_i915_private *dev_priv,
+enum port port)
+{
+ enum pipe pipe;
- /* init time, try to find a pipe with this port selected */
for (pipe = PIPE_A; pipe = PIPE_B; pipe++) {
u32 port_sel = I915_READ(VLV_PIPE_PP_ON_DELAYS(pipe))
PANEL_PORT_SELECT_MASK;
- if (port_sel == PANEL_PORT_SELECT_VLV(port))
- return pipe;
+
+ if (port_sel != PANEL_PORT_SELECT_VLV(port))
+ continue;
+
+ return pipe;
+ }
+
+ return INVALID_PIPE;
+}
+
+static void
+vlv_initial_power_sequencer_setup(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;
+ struct edp_power_seq power_seq;
+ enum port port = intel_dig_port-port;
+
+ lockdep_assert_held(dev_priv-pps_mutex);
+
+ /* try to find a pipe with this port selected */
+ intel_dp-pps_pipe = vlv_initial_power_sequencer_pipe(dev_priv, port);
+
+ /* didn't find one? just let vlv_power_sequencer_pipe() pick one when
needed */
+ if (intel_dp-pps_pipe == INVALID_PIPE) {
+ DRM_DEBUG_KMS(no initial power sequencer for port %c\n,
+ port_name(port));
+ return;
}
- /* shrug */
- return PIPE_A;
+ DRM_DEBUG_KMS(initial power sequencer for port %c: pipe %c\n,
+ port_name(port), pipe_name(intel_dp-pps_pipe));
+
+ intel_dp_init_panel_power_sequencer(dev, intel_dp, power_seq);
+ intel_dp_init_panel_power_sequencer_registers(dev, intel_dp,
+ power_seq);
}
static u32 _pp_ctrl_reg(struct intel_dp *intel_dp)
@@ -2209,6 +2280,76 @@ static void g4x_pre_enable_dp(struct intel_encoder
*encoder)
}
}
+static void vlv_steal_power_sequencer(struct drm_device *dev,
+ enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_encoder *encoder;
+
+
[Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert
From: Clint Taylor clinton.a.tay...@intel.com
Backlight on delay uses PWM enable time to seperate PWM to
backlight enable assert. Previous time difference used timing
from VDD enable which occur several seconds before resulting
in PWM starting 5ms after backlight enable. Changes to backlight
duty cycle take affect at the end of the current PWM cycle.
Measured time for the PWM cycle is 5ms. 5 additional ms must be
added to the backlight_on_delay to get correct VBT timing of
PWM to backlight enable assert.
V2: Rebase to Jani Nikula backlight power patch 1/4
Change-Id: I2982f9785d92e8d64c04ca25c8bd4c5d1dc8067c
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d8baf60..aed923b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1141,7 +1141,7 @@ static void wait_panel_power_cycle(struct intel_dp
*intel_dp)
static void wait_backlight_on(struct intel_dp *intel_dp)
{
- wait_remaining_ms_from_jiffies(intel_dp-last_power_on,
+ wait_remaining_ms_from_jiffies(intel_dp-last_backlight_on,
intel_dp-backlight_on_delay);
}
@@ -1418,6 +1418,7 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
DRM_DEBUG_KMS(\n);
intel_panel_enable_backlight(intel_dp-attached_connector);
+ intel_dp-last_backlight_on = jiffies;
_intel_edp_backlight_on(intel_dp);
}
@@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct drm_device
*dev,
assign_final(t11_t12);
#undef assign_final
+#define PWM_CYCLE_DELAY 5
#define get_delay(field) (DIV_ROUND_UP(final.field, 10))
intel_dp-panel_power_up_delay = get_delay(t1_t3);
- intel_dp-backlight_on_delay = get_delay(t8);
+ intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
intel_dp-backlight_off_delay = get_delay(t9);
intel_dp-panel_power_down_delay = get_delay(t10);
intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3abc915..ad6fcc1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -556,6 +556,7 @@ struct intel_dp {
bool want_panel_vdd;
unsigned long last_power_cycle;
unsigned long last_power_on;
+ unsigned long last_backlight_on;
unsigned long last_backlight_off;
struct notifier_block edp_notifier;
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/edid: Reduce horizontal timings for pixel replicated modes
From: Clint Taylor clinton.a.tay...@intel.com
Pixel replicated modes should be 720 horizontal pixel and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently fails for all pixel replicated modes. This change fizes
the HDMI certification issues with 480i/576i.
V2: Removed interlace flag from VICs 44 and 45. Will be submitted in
another patch. Various other formatting fixes.
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
drivers/gpu/drm/drm_edid.c| 96 ++---
drivers/gpu/drm/i915/intel_hdmi.c | 10 +++-
2 files changed, 57 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f905c63..412c525 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -632,27 +632,27 @@ 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,
- 1602, 1716, 0, 480, 488, 494, 525, 0,
+ /* 6 - 720(1440)x480i@60Hz */
+ { DRM_MODE(720x480i, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 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,
- 1602, 1716, 0, 480, 488, 494, 525, 0,
+ /* 7 - 720(1440)x480i@60Hz */
+ { DRM_MODE(720x480i, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 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,
- 1602, 1716, 0, 240, 244, 247, 262, 0,
+ /* 8 - 720(1440)x240@60Hz */
+ { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 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,
- 1602, 1716, 0, 240, 244, 247, 262, 0,
+ /* 9 - 720(1440)x240@60Hz */
+ { DRM_MODE(720x240, DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 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_16_9, },
@@ -714,27 +714,27 @@ 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,
- 1590, 1728, 0, 576, 580, 586, 625, 0,
+ /* 21 - 720(1440)x576i@50Hz */
+ { DRM_MODE(720x576i, DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+ 795, 864, 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,
- 1590, 1728, 0, 576, 580, 586, 625, 0,
+ /* 22 - 720(1440)x576i@50Hz */
+ { DRM_MODE(720x576i, DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+ 795, 864, 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,
- 1590, 1728, 0, 288, 290, 293, 312, 0,
+ /* 23 - 720(1440)x288@50Hz */
+ { DRM_MODE(720x288, DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+ 795, 864, 0, 288, 290, 293, 312, 0,
Re: [Intel-gfx] [PATCH 02/14] drm/i915: Reorganize vlv eDP reboot notifier
On 08/18/2014 12:15 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Move the vlv_power_sequencer_pipe() after the IS_VALLEYVIEW() check
and flatten the rest of the function.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 43dd226..a9ed2a6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -347,22 +347,22 @@ static int edp_notify_handler(struct notifier_block
*this, unsigned long code,
struct drm_i915_private *dev_priv = dev-dev_private;
u32 pp_div;
u32 pp_ctrl_reg, pp_div_reg;
- enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
+ enum pipe pipe;
- if (!is_edp(intel_dp) || code != SYS_RESTART)
+ if (!IS_VALLEYVIEW(dev) || !is_edp(intel_dp) || code != SYS_RESTART)
return 0;
- if (IS_VALLEYVIEW(dev)) {
- pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
- pp_div_reg = VLV_PIPE_PP_DIVISOR(pipe);
- pp_div = I915_READ(pp_div_reg);
- pp_div = PP_REFERENCE_DIVIDER_MASK;
+ pipe = vlv_power_sequencer_pipe(intel_dp);
- /* 0x1F write to PP_DIV_REG sets max cycle delay */
- I915_WRITE(pp_div_reg, pp_div | 0x1F);
- I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
- msleep(intel_dp-panel_power_cycle_delay);
- }
+ pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
+ pp_div_reg = VLV_PIPE_PP_DIVISOR(pipe);
+ pp_div = I915_READ(pp_div_reg);
+ pp_div = PP_REFERENCE_DIVIDER_MASK;
+
+ /* 0x1F write to PP_DIV_REG sets max cycle delay */
+ I915_WRITE(pp_div_reg, pp_div | 0x1F);
+ I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
+ msleep(intel_dp-panel_power_cycle_delay);
Looks better..
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Don't save/restore RS when not used
From: Ben Widawsky benjamin.widaw...@intel.com
v2: fix conflict on rebase.
Cc: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b99390..15ec7e4 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -563,6 +563,7 @@ mi_set_context(struct intel_engine_cs *ring,
struct intel_context *new_context,
u32 hw_flags)
{
+ u32 flags = hw_flags | MI_MM_SPACE_GTT;
int ret;
/* w/a: If Flush TLB Invalidation Mode is enabled, driver must do a TLB
@@ -576,6 +577,10 @@ mi_set_context(struct intel_engine_cs *ring,
return ret;
}
+ /* These flags are for resource streamer on HSW+ */
+ if (!IS_HASWELL(ring-dev) INTEL_INFO(ring-dev)-gen 8)
+ flags |= (MI_SAVE_EXT_STATE_EN | MI_RESTORE_EXT_STATE_EN);
+
ret = intel_ring_begin(ring, 6);
if (ret)
return ret;
@@ -589,10 +594,7 @@ mi_set_context(struct intel_engine_cs *ring,
intel_ring_emit(ring, MI_NOOP);
intel_ring_emit(ring, MI_SET_CONTEXT);
intel_ring_emit(ring,
i915_gem_obj_ggtt_offset(new_context-legacy_hw_ctx.rcs_state) |
- MI_MM_SPACE_GTT |
- MI_SAVE_EXT_STATE_EN |
- MI_RESTORE_EXT_STATE_EN |
- hw_flags);
+ flags);
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
* WaMiSetContext_Hang:snb,ivb,vlv
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: honour forced connector modes
From: Chris Wilson ch...@chris-wilson.co.uk
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off. Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config that tries to enable a connector (disabling is easy!).
Based on earlier patches by Jesse Barnes.
v2: Remove Jesse's patch
Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_fbdev.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index f475414..5d879d18 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -331,24 +331,6 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
int num_connectors_enabled = 0;
int num_connectors_detected = 0;
- /*
-* If the user specified any force options, just bail here
-* and use that config.
-*/
- for (i = 0; i fb_helper-connector_count; i++) {
- struct drm_fb_helper_connector *fb_conn;
- struct drm_connector *connector;
-
- fb_conn = fb_helper-connector_info[i];
- connector = fb_conn-connector;
-
- if (!enabled[i])
- continue;
-
- if (connector-force != DRM_FORCE_UNSPECIFIED)
- return false;
- }
-
save_enabled = kcalloc(dev-mode_config.num_connector, sizeof(bool),
GFP_KERNEL);
if (!save_enabled)
@@ -374,8 +356,18 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
continue;
}
+ if (connector-force == DRM_FORCE_OFF) {
+ DRM_DEBUG_KMS(connector %s is disabled by user,
skipping\n,
+ connector-name);
+ enabled[i] = false;
+ continue;
+ }
+
encoder = connector-encoder;
if (!encoder || WARN_ON(!encoder-crtc)) {
+ if (connector-force DRM_FORCE_OFF)
+ goto bail;
+
DRM_DEBUG_KMS(connector %s has no encoder or crtc,
skipping\n,
connector-name);
enabled[i] = false;
@@ -394,8 +386,7 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
for (j = 0; j fb_helper-connector_count; j++) {
if (crtcs[j] == new_crtc) {
DRM_DEBUG_KMS(fallback: cloned
configuration\n);
- fallback = true;
- goto out;
+ goto bail;
}
}
@@ -466,8 +457,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
fallback = true;
}
-out:
if (fallback) {
+bail:
DRM_DEBUG_KMS(Not using firmware configuration\n);
memcpy(enabled, save_enabled, dev-mode_config.num_connector);
kfree(save_enabled);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/bdw: Map unused PDPs to a scratch page
From: Bob Beckett robert.beck...@intel.com
Create a scratch page for the two unused PDPs and set all the PTEs
for them to point to it.
This patch addresses a page fault, and subsequent hang in pipe
control flush. In these cases, the Main Graphic Arbiter Error
register [0x40A0] showed a TLB Page Fault error, and a high memory
address (higher than the size of our PPGTT) was reported in the
Fault TLB RD Data0 register (0x4B10).
PDP2 PDP3 were not set because, in theory, they aren't required
for our PPGTT size, but they should be mapped to a scratch page
anyway.
v2: Rebase on latest nightly.
Signed-off-by: Michel Thierry michel.thie...@intel.com (v1)
Signed-off-by: Dave Gordon david.s.gor...@intel.com (v2)
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 79 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +
2 files changed, 65 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b4b7cfd..7cb18e7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -361,6 +361,11 @@ static void gen8_ppgtt_free(const struct i915_hw_ppgtt
*ppgtt)
kfree(ppgtt-gen8_pt_dma_addr[i]);
}
+ /* Unused PDPs are always assigned to scratch page */
+ for (i = ppgtt-num_pd_pages; i GEN8_LEGACY_PDPS; i++)
+ kfree(ppgtt-gen8_pt_dma_addr[i]);
+ __free_page(ppgtt-scratch_page);
+
__free_pages(ppgtt-pd_pages, get_order(ppgtt-num_pd_pages
PAGE_SHIFT));
}
@@ -385,6 +390,13 @@ static void gen8_ppgtt_unmap_pages(struct i915_hw_ppgtt
*ppgtt)
PCI_DMA_BIDIRECTIONAL);
}
}
+
+ /* Unused PDPs are always assigned to scratch page */
+ for (i = ppgtt-num_pd_pages; i GEN8_LEGACY_PDPS; i++) {
+ if (ppgtt-pd_dma_addr[i])
+ pci_unmap_page(hwdev, ppgtt-pd_dma_addr[i],
+ PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+ }
}
static void gen8_ppgtt_cleanup(struct i915_address_space *vm)
@@ -471,10 +483,21 @@ static int gen8_ppgtt_allocate_dma(struct i915_hw_ppgtt
*ppgtt)
static int gen8_ppgtt_allocate_page_directories(struct i915_hw_ppgtt *ppgtt,
const int max_pdp)
{
- ppgtt-pd_pages = alloc_pages(GFP_KERNEL, get_order(max_pdp
PAGE_SHIFT));
- if (!ppgtt-pd_pages)
+ /* Scratch page for unmapped PDP's */
+ ppgtt-scratch_page = alloc_page(GFP_KERNEL);
+ if (!ppgtt-scratch_page)
return -ENOMEM;
+ /* Must allocate space for all 4 PDPs. HW has implemented cache which
+* pre-fetches entries; that pre-fetch can attempt access for entries
+* even if no resources are located in that range.
+*/
+ ppgtt-pd_pages = alloc_pages(GFP_KERNEL, GEN8_LEGACY_PDPS);
+ if (!ppgtt-pd_pages) {
+ __free_page(ppgtt-scratch_page);
+ return -ENOMEM;
+ }
+
ppgtt-num_pd_pages = 1 get_order(max_pdp PAGE_SHIFT);
BUG_ON(ppgtt-num_pd_pages GEN8_LEGACY_PDPS);
@@ -492,6 +515,7 @@ static int gen8_ppgtt_alloc(struct i915_hw_ppgtt *ppgtt,
ret = gen8_ppgtt_allocate_page_tables(ppgtt, max_pdp);
if (ret) {
+ __free_page(ppgtt-scratch_page);
__free_pages(ppgtt-pd_pages, get_order(max_pdp PAGE_SHIFT));
return ret;
}
@@ -526,18 +550,25 @@ static int gen8_ppgtt_setup_page_directories(struct
i915_hw_ppgtt *ppgtt,
static int gen8_ppgtt_setup_page_tables(struct i915_hw_ppgtt *ppgtt,
const int pd,
- const int pt)
+ const int pt,
+ const int max_pdp)
{
dma_addr_t pt_addr;
struct page *p;
int ret;
- p = ppgtt-gen8_pt_pages[pd][pt];
- pt_addr = pci_map_page(ppgtt-base.dev-pdev,
- p, 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
- ret = pci_dma_mapping_error(ppgtt-base.dev-pdev, pt_addr);
- if (ret)
- return ret;
+ /* Unused PDPs need to have their ptes pointing to the
+* existing scratch page.
+*/
+ if (pd max_pdp) {
+ p = ppgtt-gen8_pt_pages[pd][pt];
+ pt_addr = pci_map_page(ppgtt-base.dev-pdev,
+ p, 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+ ret = pci_dma_mapping_error(ppgtt-base.dev-pdev, pt_addr);
+ if (ret)
+ return ret;
+ } else
+ pt_addr = ppgtt-scratch_dma_addr;
ppgtt-gen8_pt_dma_addr[pd][pt] = pt_addr;
@@ -559,6 +590,7 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt,
[Intel-gfx] [PATCH 0/4] drm-intel-collector - update
This is another drm-intel-collector updated notice: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the update list in order for better reviewers assignment: Patch drm/i915: Bring UP Power Wells before disabling RC6. - Reviewer: Patch drm/i915: Don't save/restore RS when not used - Reviewer: Patch drm/i915: honour forced connector modes - Reviewer: Patch drm/i915/bdw: Map unused PDPs to a scratch page - Reviewer: Ben Widawsky (1): drm/i915: Don't save/restore RS when not used Bob Beckett (1): drm/i915/bdw: Map unused PDPs to a scratch page Chris Wilson (1): drm/i915: honour forced connector modes Deepak S (1): drm/i915: Bring UP Power Wells before disabling RC6. drivers/gpu/drm/i915/i915_gem_context.c | 10 +++-- drivers/gpu/drm/i915/i915_gem_gtt.c | 79 ++--- drivers/gpu/drm/i915/i915_gem_gtt.h | 2 + drivers/gpu/drm/i915/intel_fbdev.c | 33 +- drivers/gpu/drm/i915/intel_pm.c | 6 +++ 5 files changed, 89 insertions(+), 41 deletions(-) -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Bring UP Power Wells before disabling RC6.
From: Deepak S deepa...@intel.com
We need do forcewake before Disabling RC6, This is what the BIOS
expects while going into suspend.
v2: updated commit message. (Daniel)
Reviewer: Paulo Zanoni paulo.r.zan...@intel.com
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Deepak S deepa...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 41de760..9f96baa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3527,8 +3527,14 @@ static void valleyview_disable_rps(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ /* we're doing forcewake before Disabling RC6,
+* This what the BIOS expects when going into suspend */
+ gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
+
I915_WRITE(GEN6_RC_CONTROL, 0);
+ gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
+
gen6_disable_rps_interrupts(dev);
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] How to create PCH to support those existing driver
On 2014/8/18 17:58, Michael S. Tsirkin wrote:
On Mon, Aug 18, 2014 at 05:01:25PM +0800, Chen, Tiejun wrote:
On 2014/8/18 16:21, Michael S. Tsirkin wrote:
On Mon, Aug 18, 2014 at 11:06:29AM +0800, Chen, Tiejun wrote:
On 2014/8/17 18:32, Michael S. Tsirkin wrote:
On Fri, Aug 15, 2014 at 09:58:40AM +0800, Chen, Tiejun wrote:
Michael and Paolo,
Please re-post discussion on list. These off list ones are just
wasting time since they invariably have to be repeated on list again.
Okay, now just reissue this discussion to all related guys. And do you think
we need to discuss in public, qemu and xen mail list?
Absolutely.
Now -CC qemu, xen and intel-gfx.
If I'm missing someone important please tell me as well.
After I created that new machine specific to IGD passthrough, xenigd, now I
will step next to register the PCH.
IIRC, our complete solution should be as follows:
#1 create a new machine based on piix, xenigd
This is done with Michael help.
#2 register ISA bridge
1 Its still fixed at 1f.0.
2 ISA bridge's vendor_id/device_id should be emulated but then
subsystem_vendor_id = PCI_VENDOR_ID_XEN;
subsystem_device_id = ISA Bridge's real device id
This mean we need to change driver to walk with this way.
For example, in
case of Linux native driver,
intel_detect_pch()
{
...
if (pch-subsystem_vendor == PCI_VENDOR_ID_XEN)
id = pch-subsystem_device INTEL_PCH_DEVICE_ID_MASK;
Then driver can get that real device id by 'subsystem_device', right?
This is fine now but how to support those existing drivers which are just
Here correct one point, we don't need to care about supporting the legacy
driver since the legacy driver still should work qemu-traditional. So we
just make sure the existing driver with this subsystem_id way can support
those existing and legacy platform.
Now this is clear to me.
dependent on checking real vendor_id/device_id directly,
if (pch-vendor == PCI_VENDOR_ID_INTEL) {
unsigned short id = pch-device INTEL_PCH_DEVICE_ID_MASK
Maybe I'm missing something, please hint me.
Thanks
Tiejun
The subsystem id was just one idea.
But from that email thread, RH / Intel Virtualization Engineering Meeting -
Minutes 7/10, I didn't see other idea we should prefer currently.
What was finally agreed for future drivers is that guests will get all
information they need from the video card, this ID hack was needed only
for very old legacy devices.
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258
So this is for newer guests, they will work without need
for hacks, like any other device.
Actually we had a meeting to discuss our future solution, but seems you were
on vacation at that moment :)
In that meeting we had an agreement between us and some upstream guys.
We will have such a PCI capability structure in this PCI device to represent
all information in the future. This make sens to Intel as well.
Maybe Allen or Paolo known more details.
But obviously this a long-term solution, so currently we will work with this
subsystem_id way temporarily. And this way is accepted by those guys in the
meeting.
I don't see the point really. If you are modifying the driver,
Yes, we need to modify something in the driver.
why not modify it to its final form.
What's your final form?
Avoid poking at other devices besides the passed through card.
Get everything from BAR and other registers of the card.
Allen,
Could you reply this?
As I track that email thread, seems the follows is just a way you guys
achieve a better agreement.
why not set the subsys vid to the RH/Quamranet/Virtio VID, so it's
obvious for the use-match?
That's exactly the suggestion. Though upstream they might be using the
XenSource id since the patches were for Xen.
Paolo
Or I'm missing something?
Thanks
Tiejun
I thought the point of this work is to make existing
linux/windows drivers work. Is it or isn't it?
Yes. We need change driver as I said previously like this,
2 ISA bridge's vendor_id/device_id should be emulated but then
subsystem_vendor_id = PCI_VENDOR_ID_XEN;
subsystem_device_id = ISA Bridge's real device id
This mean we need to change driver to walk with this way.
For example, in
case of Linux native driver,
intel_detect_pch()
{
...
if (pch-subsystem_vendor == PCI_VENDOR_ID_XEN)
id = pch-subsystem_device INTEL_PCH_DEVICE_ID_MASK;
This is a minimal change to driver as we discussed.
Wrt changing drivers, change them to behave sanely, like all other
drivers, and avoid poking at the chipset.
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258
Seems to suggest one way to do this.
Can what is suggested there work for existing devices?
Again, Allen,
Are you sure if this suggestion can work?
Thanks
Tiejun
For existing drivers: Vendor ID is intel anyway.
Yes.
For device ID,
[Intel-gfx] [PATCH] drm/i915: don't warn if backlight unexpectedly enabled
BIOS or firmware can modify hardware state during suspend/resume,
for example on the Toshiba CB35 or Lenovo T400, so log a debug message
instead of a warning if the backlight is unexpectedly enabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80930
Cc: Jani Nikula jani.nik...@intel.com
Signed-off-by: Scot Doyle lkm...@scotdoyle.com
---
drivers/gpu/drm/i915/intel_panel.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 59b028f..8e37444 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -801,7 +801,7 @@ static void pch_enable_backlight(struct intel_connector
*connector)
cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
if (cpu_ctl2 BLM_PWM_ENABLE) {
- WARN(1, cpu backlight already enabled\n);
+ DRM_DEBUG_KMS(cpu backlight already enabled\n);
cpu_ctl2 = ~BLM_PWM_ENABLE;
I915_WRITE(BLC_PWM_CPU_CTL2, cpu_ctl2);
}
@@ -845,7 +845,7 @@ static void i9xx_enable_backlight(struct intel_connector
*connector)
ctl = I915_READ(BLC_PWM_CTL);
if (ctl BACKLIGHT_DUTY_CYCLE_MASK_PNV) {
- WARN(1, backlight already enabled\n);
+ DRM_DEBUG_KMS(backlight already enabled\n);
I915_WRITE(BLC_PWM_CTL, 0);
}
@@ -876,7 +876,7 @@ static void i965_enable_backlight(struct intel_connector
*connector)
ctl2 = I915_READ(BLC_PWM_CTL2);
if (ctl2 BLM_PWM_ENABLE) {
- WARN(1, backlight already enabled\n);
+ DRM_DEBUG_KMS(backlight already enabled\n);
ctl2 = ~BLM_PWM_ENABLE;
I915_WRITE(BLC_PWM_CTL2, ctl2);
}
@@ -910,7 +910,7 @@ static void vlv_enable_backlight(struct intel_connector
*connector)
ctl2 = I915_READ(VLV_BLC_PWM_CTL2(pipe));
if (ctl2 BLM_PWM_ENABLE) {
- WARN(1, backlight already enabled\n);
+ DRM_DEBUG_KMS(backlight already enabled\n);
ctl2 = ~BLM_PWM_ENABLE;
I915_WRITE(VLV_BLC_PWM_CTL2(pipe), ctl2);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix suspend/resume for GENs w/o runtime PM support
Oh. I also missed this side effect of paths converging.
Reviewed-by: Sagar Kamble sagar.a.kam...@intel.com
On Mon, 2014-08-18 at 13:20 +0300, Imre Deak wrote:
Before sharing common parts between the system and runtime s/r
handlers we WARNed if the runtime s/r handlers were called on GENs that
didn't support RPM. But this WARN is not correct if the same handler is
called from the system s/r path, since that can happen on any platform.
This also broke system s/r on old platforms.
The issue was introduced in
commit 016970beb05da6285c2f3ed2bee1c676cb75972e
Author: Sagar Kamble sagar.a.kam...@intel.com
Date: Wed Aug 13 23:07:06 2014 +0530
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82751
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 117f5c1..f646f34 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -499,7 +499,8 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
}
-static int intel_suspend_complete(struct drm_i915_private *dev_priv);
+static int intel_suspend_complete(struct drm_i915_private *dev_priv,
+ bool rpm_suspend);
static int intel_resume_prepare(struct drm_i915_private *dev_priv,
bool rpm_resume);
@@ -909,7 +910,7 @@ static int i915_pm_suspend_late(struct device *dev)
if (drm_dev-switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
- ret = intel_suspend_complete(dev_priv);
+ ret = intel_suspend_complete(dev_priv, false);
if (ret)
DRM_ERROR(Suspend complete failed: %d\n, ret);
@@ -1410,7 +1411,7 @@ static int intel_runtime_suspend(struct device *device)
cancel_work_sync(dev_priv-rps.work);
intel_runtime_pm_disable_interrupts(dev);
- ret = intel_suspend_complete(dev_priv);
+ ret = intel_suspend_complete(dev_priv, true);
if (ret) {
DRM_ERROR(Runtime suspend failed, disabling it (%d)\n, ret);
intel_runtime_pm_restore_interrupts(dev);
@@ -1471,10 +1472,11 @@ static int intel_runtime_resume(struct device *device)
* This function implements common functionality of runtime and system
* suspend sequence.
*/
-static int intel_suspend_complete(struct drm_i915_private *dev_priv)
+static int intel_suspend_complete(struct drm_i915_private *dev_priv,
+ bool rpm_suspend)
{
struct drm_device *dev = dev_priv-dev;
- int ret;
+ int ret = 0;
if (IS_GEN6(dev)) {
ret = 0;
@@ -1482,7 +1484,7 @@ static int intel_suspend_complete(struct
drm_i915_private *dev_priv)
ret = hsw_suspend_complete(dev_priv);
} else if (IS_VALLEYVIEW(dev)) {
ret = vlv_suspend_complete(dev_priv);
- } else {
+ } else if (rpm_suspend) {
ret = -ENODEV;
WARN_ON(1);
}
@@ -1499,7 +1501,7 @@ static int intel_resume_prepare(struct drm_i915_private
*dev_priv,
bool rpm_resume)
{
struct drm_device *dev = dev_priv-dev;
- int ret;
+ int ret = 0;
if (IS_GEN6(dev)) {
ret = snb_resume_prepare(dev_priv, rpm_resume);
@@ -1507,7 +1509,7 @@ static int intel_resume_prepare(struct drm_i915_private
*dev_priv,
ret = hsw_resume_prepare(dev_priv, rpm_resume);
} else if (IS_VALLEYVIEW(dev)) {
ret = vlv_resume_prepare(dev_priv, rpm_resume);
- } else {
+ } else if (rpm_resume) {
WARN_ON(1);
ret = -ENODEV;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/dp: make backlight bl_power control power sequencer backlight
On Mon, 18 Aug 2014, Clint Taylor clinton.a.tay...@intel.com wrote:
On 08/12/2014 07:11 AM, Jani Nikula wrote:
This lets the userspace switch off the backlight using the backlight
class sysfs bl_power file. The switch is done using the power sequencer;
the backlight PWM, and everything else, remains enabled. The display
backlight won't draw power, but for maximum power savings the encoder
needs to be switched off.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index d8baf60ff3fd..f6e3e9a906b0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1453,6 +1453,27 @@ void intel_edp_backlight_off(struct intel_dp
*intel_dp)
intel_panel_disable_backlight(intel_dp-attached_connector);
}
+/*
+ * Hook for controlling the panel power control backlight through the
bl_power
+ * sysfs attribute. Take care to handle multiple calls.
+ */
+static void intel_edp_backlight_power(struct intel_connector *connector,
+ bool enable)
+{
+struct intel_dp *intel_dp = intel_attached_dp(connector-base);
+bool is_enabled = ironlake_get_pp_control(intel_dp) EDP_BLC_ENABLE;
+
+if (is_enabled == enable)
+return;
+
+DRM_DEBUG_KMS(\n);
+
+if (enable)
+_intel_edp_backlight_on(intel_dp);
+else
+_intel_edp_backlight_off(intel_dp);
Is there a good reason why we leave the PWM enabled? There is a small
power requirement to leave the PWM enabled.
Implementation simplicity. If you want to go for max power savings, you
are supposed to switch everything off using KMS, not just backlight.
BR,
Jani.
+}
+
static void ironlake_edp_pll_on(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -4579,6 +4600,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
}
intel_panel_init(intel_connector-panel, fixed_mode, downclock_mode);
+intel_connector-panel.backlight_power = intel_edp_backlight_power;
intel_panel_setup_backlight(connector);
return true;
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
