Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type
On Wed, Aug 12, 2015 at 9:26 PM, Ville Syrjälä
wrote:
> On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
>> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
>> > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek
>> > wrote:
>> >> Hi,
>> >>
>> >> this my first build of a 4.2-rcN Linux-kernel and I see this...
>> >>
>> >
>> > Just FYI:
>> >
>> > I am *not* seeing this with drm-intel-nightly from below url.
>> >
>> > Also, I plan to test Linux v4.2-rc5.
>> >
>>
>> [ CC Linus ]
>>
>> Knock Knock Knock.
>>
>> This issue still remains here (with CONFIG_DRM_I915=m)...
>>
>> [ 18.269792] ==
>> [ 18.269798] [ INFO: possible circular locking dependency detected ]
>> [ 18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
>> [ 18.269810] ---
>> [ 18.269816] modprobe/727 is trying to acquire lock:
>> [ 18.269822] (init_mutex){+.+.+.}, at: []
>> acpi_video_get_backlight_type+0x17/0x164 [video]
>> [ 18.269840]
>> [ 18.269840] but task is already holding lock:
>> [ 18.269848] (&(&backlight_notifier)->rwsem){..}, at:
>> [] __blocking_notifier_call_chain+0x39/0x70
>> [ 18.269864]
>> [ 18.269864] which lock already depends on the new lock.
>> [ 18.269864]
>> [ 18.269875]
>> [ 18.269875] the existing dependency chain (in reverse order) is:
>> [ 18.269884]
>> ...
>>
>> Full dmesg log and kernel-config attached.
>>
>> Shall I add Rusty and modules/modprobe folks?
>
> Just got back from vacation and was greeted by this same lockdep splat.
>
> On a hunch I reverted
>
> commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
> Author: Hans de Goede
> Date: Tue Jun 16 16:27:52 2015 +0200
>
> ACPI / video: Move backlight notifier to video_detect.c
>
> and the problem seems to be gone. Hans, any thoughts?
>
Reverting this commit on top of Linux v4.2-rc6 causes troubles here.
$ LC_ALL=C git revert 93a291dfaf9c328ca5a9cea1733af1
error: could not revert 93a291dfaf9c... ACPI / video: Move backlight
notifier to video_detect.c
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'
Provide a suitable patch and I test for you.
- Sedat -
>>
>> - Sedat -
>>
>> > - Sedat -
>> >
>> > [1]
>> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
>> > [2]
>> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-994.201508010158_amd64.deb
>> >
>> >> [ 24.001043] [drm] Memory usable by graphics device = 2048M
>> >> [ 24.001118] [drm] Replacing VGA console driver
>> >> [ 24.011642] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> >> [ 24.011646] [drm] Driver supports precise vblank timestamp query.
>> >> [ 24.012480] vgaarb: device changed decodes:
>> >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>> >> [ 24.028005]
>> >> [ 24.028014] ==
>> >> [ 24.028020] [ INFO: possible circular locking dependency detected ]
>> >> [ 24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
>> >> [ 24.028032] ---
>> >> [ 24.028038] modprobe/740 is trying to acquire lock:
>> >> [ 24.028043] (init_mutex){+.+.+.}, at: []
>> >> acpi_video_get_backlight_type+0x17/0x164 [video]
>> >> [ 24.028060]
>> >> [ 24.028060] but task is already holding lock:
>> >> [ 24.028068] (&(&backlight_notifier)->rwsem){..}, at:
>> >> [] __blocking_notifier_call_chain+0x39/0x70
>> >> [ 24.028083]
>> >> [ 24.028083] which lock already depends on the new lock.
>> >> [ 24.028083]
>> >> [ 24.028095]
>> >> [ 24.028095] the existing dependency chain (in reverse order) is:
>> >> [ 24.028103]
>> >> [ 24.028103] -> #1 (&(&backlight_notifier)->rwsem){..}:
>> >> [ 24.028113][] lock_acquire+0xcf/0x280
>> >> [ 24.028121][] down_write+0x49/0x80
>> >> [ 24.028129][]
>> >> blocking_notifier_chain_register+0x21/0xb0
>> >> [ 24.028138][]
>> >> backlight_register_notifier+0x18/0x20
>> >> [ 24.028147][]
>> >> acpi_video_get_backlight_type+0xfa/0x164 [video]
>> >> [ 24.028158][] 0xa00a20e9
>> >> [ 24.028164][] do_one_initcall+0x88/0x1c0
>> >> [ 24.028172][] do_init_module+0x61/0x1ec
>> >> [ 24.028179][] load_module+0x2008/0x25c0
>> >> [ 24.028187][] SyS_init_module+0x126/0x140
>> >> [ 24.028194][]
>> >> entry_SYSCALL_64_fastpath+0x16/0x7a
>> >> [ 24.028202]
>> >> [ 24.028202] -> #0 (init_mutex){+.+.+.}:
>> >> [ 24.028211][] __lock_acquire+0x1f5d/0x21c0
>> >> [ 24.028218][] lock_acquire+0xcf/0x280
>> >> [ 24.028225][] mutex_lock_nested+0x65/0x3c0
>> >> [ 24.028233][]
>> >> acpi_video_get_backlight_type+0x17/0x164 [video]
>> >> [ 24.02
Re: [Intel-gfx] [PATCH v2 00/22] Enable gpu switching on the MacBook Pro
On Thu, Aug 13, 2015 at 1:37 AM, Lukas Wunner wrote: > Hi Daniel, > > On Wed, Aug 12, 2015 at 04:16:25PM +0200, Daniel Vetter wrote: >> > * Reprobing if the inactive GPU initializes before the apple-gmux module: >> > v1 used Matthew Garrett's approach of adding a driver callback. >> > v2 simply generates a hotplug event instead. nouveau polls its outputs >> > every 10 seconds so we want it to poll immediately once apple-gmux >> > registers. That is achieved by the hotplug event. The i915 driver is >> > changed to behave identically to nouveau. (Right now it deletes LVDS >> > and eDP connectors from the mode configuration if they can't be probed, >> > deeming them to be ghosts.) >> >> I thought -EDEFERREDPROBE is what we should be using if drivers don't get >> loaded in the right order? Hand-rolling depency avoidance stuff is imo a >> horrible idea. > [...] >> I think just reading edid and the relevant dp aux data in apple-gmux or >> somewhere like that and stalling driver load until that's ready is the >> only clean option. > > I'm afraid we can't stall initialization of a driver like that because > even though the GPU may not be switched to the panel, it may still have > an external monitor attached. > > All MacBook Pros have external DP and/or HDMI ports and these are > either soldered to the discrete GPU (model year 2011 and onwards) > or switchable between the discrete and integrated GPU (until 2010; > I think they are even switchable separately from the panel). > > So basically we'd have to initialize the driver normally, and if > intel_lvds_init() or intel_edp_init_connector() fail we'd have to > somehow pass that up the call chain so that i915_pci_probe() can > return -EPROBE_DEFER. And whenever we're asked to reprobe we'd > repeat initialization of the LVDS or eDP connector. > > I'm wondering what the benefit is compared to just keeping the > connector in the mode configuration, but with status disconnected, > and reprobing it when the ->output_poll_changed callback gets invoked? > Because that's what nouveau already does, and what I've changed i915 > to do with patch 13. > > vga_switcheroo calls drm_kms_helper_hotplug_event() when the handler > registers (patch 11), which will invoke ->output_poll_changed. > So we're talking about the Official DRM Callback [tm] to probe > outputs, not "hand-rolling depency avoidance". :-) Oh I didn't spot that one. This kind of layering inversions generally leads to deadlocks and fun stuff. Also reprobing lvds/edp is just a side-effect when you have fbdev emulation enabled. If we go with this re-probing approach then we definitely need a new hook in vga-switcheroo, and even then there's still the locking problem. >> > * Framebuffer recreation if the inactive GPU initializes before the >> > apple-gmux module (i.e. discarding the default 1024x768 fb and replacing >> > with a new one with the actual panel resolution): v1 only supported this >> > for i915, v2 has a generic solution which works with nouveau and radeon >> > as well. (Necessary if the discrete GPU is forced to be the inactive one >> > on boot via the EFI variable.) >> >> Would completely remove the need for this ;-) > > Unfortunately not: We'd still have to initialize the driver to be able > to drive external displays. If there are initially no connectors with > modes, we'll once again end up with the 1024x768 fb. EDEFERREDPROBE isn't something that gets returned to userspace, it's just internal handling so that the kernel knows there's a depency issue and it needs to retry probing once other drivers have finished loading. It is the generic means linux has to handle cross-driver depencies which aren't reflected in the bus hierarchy. I.e. it's just something to make sure that apple-gmux is fully loaded before i915/nouveau. The driver _will_ be initialized eventually. >> You can't share the dp aux like that. It's true that we need a bit more >> data (there's a few eDP related feature blocsk we need), but sharing the >> aux channel entirely is no-go. If you do you get drivers trying to link >> train and at best this fails and at worst you'll upset the configuration >> of the other driver and piss of the panel enough to need a hard reset >> until it works again. > > Yes, so far proxying of the AUX channel is read-only. In those cases > when writing is necessary for setting up the output, I'm adding code > to check if the current content of the DPCD is identical to what's > being written and if so, skip the write. We'll see if this stategy is > sufficient for the drivers to set up their outputs. You need to block anything that would write _much_ earlier. By the time we're doing link-training it's way too late. >> I think the real tricky bit here with vgaswitcheroo is locking, I need to >> take a separate lock at the patches for that. > > Locking when switching only the DDC lines is facilitated by the ddc_lock > attribute of struct vgasr_priv. This is all local to vga_switcheroo
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Clean up DP/HDMI limited color range handling
sdvo is still using color_range name in it's functions. would be good to
rename that as well along with dp & hdmi done here.
otherwise changes are fine
Reviewed-by: Sivakumar Thulasimani
On Monday 06 July 2015 05:40 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Currently we treat intel_{dp,hdmi}->color_range as partly user
controller value (via the property) but we also change it during
.compute_config() when using the "Automatic" mode. That is a bit
confusing, so let's just change things so that we store the user
property values in intel_dp, and only change what's stored in
pipe_config during .compute_config().
There should be no functional change.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 25 -
drivers/gpu/drm/i915/intel_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_hdmi.c | 26 --
3 files changed, 26 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..decefa1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1455,15 +1455,13 @@ found:
* CEA-861-E - 5.1 Default Encoding Parameters
* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
*/
- if (bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1)
- intel_dp->color_range = DP_COLOR_RANGE_16_235;
- else
- intel_dp->color_range = 0;
+ pipe_config->limited_color_range =
+ bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
+ } else {
+ pipe_config->limited_color_range =
+ intel_dp->limited_color_range;
}
- if (intel_dp->color_range)
- pipe_config->limited_color_range = true;
-
intel_dp->lane_count = lane_count;
if (intel_dp->num_sink_rates) {
@@ -1605,8 +1603,9 @@ static void intel_dp_prepare(struct intel_encoder
*encoder)
trans_dp &= ~TRANS_DP_ENH_FRAMING;
I915_WRITE(TRANS_DP_CTL(crtc->pipe), trans_dp);
} else {
- if (!HAS_PCH_SPLIT(dev) && !IS_VALLEYVIEW(dev))
- intel_dp->DP |= intel_dp->color_range;
+ if (!HAS_PCH_SPLIT(dev) && !IS_VALLEYVIEW(dev) &&
+ crtc->config->limited_color_range)
+ intel_dp->DP |= DP_COLOR_RANGE_16_235;
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
intel_dp->DP |= DP_SYNC_HS_HIGH;
@@ -4663,7 +4662,7 @@ intel_dp_set_property(struct drm_connector *connector,
if (property == dev_priv->broadcast_rgb_property) {
bool old_auto = intel_dp->color_range_auto;
- uint32_t old_range = intel_dp->color_range;
+ bool old_range = intel_dp->limited_color_range;
switch (val) {
case INTEL_BROADCAST_RGB_AUTO:
@@ -4671,18 +4670,18 @@ intel_dp_set_property(struct drm_connector *connector,
break;
case INTEL_BROADCAST_RGB_FULL:
intel_dp->color_range_auto = false;
- intel_dp->color_range = 0;
+ intel_dp->limited_color_range = false;
break;
case INTEL_BROADCAST_RGB_LIMITED:
intel_dp->color_range_auto = false;
- intel_dp->color_range = DP_COLOR_RANGE_16_235;
+ intel_dp->limited_color_range = true;
break;
default:
return -EINVAL;
}
if (old_auto == intel_dp->color_range_auto &&
- old_range == intel_dp->color_range)
+ old_range == intel_dp->limited_color_range)
return 0;
goto done;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3f0a890..983a7a7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -669,7 +669,7 @@ struct cxsr_latency {
struct intel_hdmi {
u32 hdmi_reg;
int ddc_bus;
- uint32_t color_range;
+ bool limited_color_range;
bool color_range_auto;
bool has_hdmi_sink;
bool has_audio;
@@ -714,7 +714,7 @@ struct intel_dp {
uint32_t DP;
bool has_audio;
enum hdmi_force_audio force_audio;
- uint32_t color_range;
+ bool limited_color_range;
bool color_range_auto;
uint8_t link_bw;
uint8_t rate_select;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index c7e912b..ba845f7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -848,8 +848,8 @@ static void intel_hdmi_prepare(struct intel_encoder
*encoder)
u32 hdmi_val;
hdmi_val = SDVO_ENCO
Re: [Intel-gfx] [BUGFIX] drm/i915: Fix for VBT expected size
On Wed, 2015-08-12 at 15:43 +0200, Daniel Vetter wrote: > On Wed, Aug 12, 2015 at 04:42:53PM +0300, Jani Nikula wrote: > > On Wed, 12 Aug 2015, Daniel Vetter wrote: > > > On Tue, Aug 11, 2015 at 04:49:33PM +0300, Mika Kahola wrote: > > >> Depending on the VBT BDB version the maximum size > > >> can be up to 38 bytes. > > >> > > >> This fix increases the maximum of the VBT expected size > > >> from 33 bytes to 38 bytes and by doing so cures the kernel > > >> hang on BSW box. > > >> > > >> Signed-off-by: Mika Kahola > > > > > > We already have David's patch in -fixes, how does this relate? How does it > > > blow up? Is this a regression? If so which commit created it? Where's the > > > bugzilla link from QA? > > > > There's no bugzilla link from QA because Mika found the bug and I told > > him to just send the patch. > > so bsw doesn't boot and QA didn't notice? That's fail too, just different > kind of fail ... > -Daniel Well, there is now a bug report now which can be found https://bugs.freedesktop.org/show_bug.cgi?id=91613 In addition, David refined his patch series, which relates to this issue and therefore my bugfix can be ignored. https://patchwork.freedesktop.org/patch/56911/ -Mika- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.
On 8/13/2015 8:57 AM, Zhang, Xiong Y wrote: On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote: On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote: -Original Message- From: Vivi, Rodrigo Sent: Saturday, August 8, 2015 8:34 AM To: intel-gfx@lists.freedesktop.org Cc: Vivi, Rodrigo; Zhang, Xiong Y Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes. DDI-A and DDI-E shares the 4 lanes. So when DDI-E is present we need to configure lane count propperly for both. This was based on Sonika's [PATCH] drm/i915/skl: Select DDIA lane capability based upon vbt Credits-to: Sonika Jindal Cc: Xiong Zhang Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_ddi.c | 12 ++-- drivers/gpu/drm/i915/intel_dp.c | 8 +--- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 110d546..557cecf 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct drm_device *dev, enum port port) struct intel_digital_port *intel_dig_port; struct intel_encoder *intel_encoder; struct drm_encoder *encoder; - bool init_hdmi, init_dp; + bool init_hdmi, init_dp, ddi_e_present; + + /* +* On SKL we don't have a way to detect DDI-E so we rely on VBT. +*/ + ddie_present = IS_SKYLAKE(dev) && + (dev_priv ->vbt.ddi_port_info[PORT_E].supports_dp +dev_priv ->vbt.ddi_port_info[PORT_E].supports_dvi +dev_priv ->vbt.ddi_port_info[PORT_E].supports_hdmi); [Zhang, Xiong Y] ddie_present should be ddi_e_present init_hdmi = (dev_priv ->vbt.ddi_port_info[port].supports_dvi || dev_priv ->vbt.ddi_port_info[port].supports_hdmi); @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct drm_device *dev, enum port port) intel_dig_port->port = port; intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) & (DDI_BUF_PORT_REVERSAL | - DDI_A_4_LANES); + ddi_e_present ? 0 : DDI_A_4_LANES); [Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes when DDI-E doesn't exist, I think your patch will do nothing. Actually DDI_A_4_LANES is being already set unconditionally, so Sonika's patch has no effect. [Zhang, Xiong Y] No. Sonika's patch set DDI_A_4_LANES under many conditions. + if (IS_SKYLAKE(dev) && port == PORT_A + && !(val & DDI_BUF_CTL_ENABLE) + && !dev_priv->vbt.ddi_e_used) + I915_WRITE(DDI_BUF_CTL(port), val | DDI_A_4_LANES) saved_port_bits goes to intel_dp->DP that goes to DDI_BUF_CTL and also it is used to calculate the number of lanes. With this patch we stop setting DDI_A_4_LANES when ddi_e is present so DDI-A keeps with 2 lanes and let other 2 lanes for DDI-E [Zhang, Xiong Y] Yes, this patch will clear DDI_A_4_LANES when ddi_e is present. But this patch won't set DDI_A_4_LANES under following conditions which is purpose for Sonika patch 1. Bios fail to driver eDP and doesn't enable DDI_A buffer If DDI_A isn't enabled we don't need to set DDI_A_4_LANES [Zhang, Xiong Y] From commit message on Sonika patch, she want to set DDI_A_4_LANES on such case. Maybe she met such fail case on one high resolution eDP screen. Let's Sonikia explain it. 2. Bios clear DDI_A_4_LANES 3. DDI_E isn't present I don't agree... This is already covered on current code. DDI_A_4_LANES is already being set when enabling DDI_A. As Zhang mentioned and as my commit message explains, my patch is needed when bios failed to drive edp (In my case it was an intermediate frequency supported panel which was set to 3.24 GHz and bios didn't have support for intermediate frequencies), it will not enable DDIA in which case, it will not set DDI_BUF_CTL and DDI Lane capability will remain 0 (which is DDIA with 2 lanes and DDIE with 2 lanes). So, since the native resolution of that panel was high and couldn't work with 2 lanes. So, ideally we should not rely on bios to set the initial value and set it based upon whether DDI_E is used or not. So, my patch has some effect :) thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clean up lrc context init
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7112 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -1 283/283 282/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Dont enable hpd for eDP
On 8/12/2015 6:26 PM, Daniel Vetter wrote: On Mon, Aug 10, 2015 at 05:51:48PM +0530, Sivakumar Thulasimani wrote: On 8/10/2015 5:44 PM, Jani Nikula wrote: On Mon, 10 Aug 2015, Sivakumar Thulasimani wrote: On 8/10/2015 5:07 PM, Jani Nikula wrote: On Mon, 10 Aug 2015, Sivakumar Thulasimani wrote: Reviewed-by: Sivakumar Thulasimani On 8/10/2015 10:35 AM, Sonika Jindal wrote: With HPD support added for all ports including PORT_A, setting hpd_pin will result in enabling of hpd to edp as well. There is no need to enable HPD on PORT_A hence this patch removes hpd_pin update for PORT_A, where edp will be connected. it can be added back when required What? You can't just go ahead and remove HPD from eDP sinks. BR, Jani. Nope, we are not removing HPD for edp sinks, it was never there in the first place. It was enabled for CHV (even there by mistake since PORT B/C was both DP and eDP) but it was never there for any other plaforms nor is it used for any purpose (PSR must use it, but i dont see code for it as well). Are you saying there's no HPD enabled in our *hardware* for eDP? Or driver? My point is, is this patch making it harder to enable eDP hpd handling (e.g. for PSR or DP link re-training) in the future? We currently take it into account in a few places, and if we start removing that, it will be a loss of effort to first remove and then add it back. BR, Jani. i was referring to our driver only. Our VLV/CHV code already receives hpd for every pps on and off which is later ignored. if we dont disable HPD on eDPs this behavior will be extended for all platforms which i feel is too costly to keep enabled when there is no purpose for it right now. don't optimize code because you "feel it's costly", only do it when you have hard numbers. One interrupt per pps on or off transition won't be measurable at all. -Daniel let me rephrase my concern then :) a) HPD was never enabled before this patch for edp b) this patch series will enable hpd for edp so why should we allow hpd for edp when no one is using it and will cause problems unless ignored explicitly ? -- regards, Sivakumar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type
Hi, Ville
Have you reported this to the owner of the backlight core?
This looks like a bug that the backlight core should handle.
What intel backlight driver and acpi backlight driver have done here are just
invoking APIs provided by the backlight core.
So it is the duty of the backlight core to handle such kind of circular locking.
Thanks
-Lv
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Ville Syrj?l?
> Sent: Thursday, August 13, 2015 3:26 AM
>
> On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
> > On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
> > > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek
> > > wrote:
> > >> Hi,
> > >>
> > >> this my first build of a 4.2-rcN Linux-kernel and I see this...
> > >>
> > >
> > > Just FYI:
> > >
> > > I am *not* seeing this with drm-intel-nightly from below url.
> > >
> > > Also, I plan to test Linux v4.2-rc5.
> > >
> >
> > [ CC Linus ]
> >
> > Knock Knock Knock.
> >
> > This issue still remains here (with CONFIG_DRM_I915=m)...
> >
> > [ 18.269792] ==
> > [ 18.269798] [ INFO: possible circular locking dependency detected ]
> > [ 18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
> > [ 18.269810] ---
> > [ 18.269816] modprobe/727 is trying to acquire lock:
> > [ 18.269822] (init_mutex){+.+.+.}, at: []
> > acpi_video_get_backlight_type+0x17/0x164 [video]
> > [ 18.269840]
> > [ 18.269840] but task is already holding lock:
> > [ 18.269848] (&(&backlight_notifier)->rwsem){..}, at:
> > [] __blocking_notifier_call_chain+0x39/0x70
> > [ 18.269864]
> > [ 18.269864] which lock already depends on the new lock.
> > [ 18.269864]
> > [ 18.269875]
> > [ 18.269875] the existing dependency chain (in reverse order) is:
> > [ 18.269884]
> > ...
> >
> > Full dmesg log and kernel-config attached.
> >
> > Shall I add Rusty and modules/modprobe folks?
>
> Just got back from vacation and was greeted by this same lockdep splat.
>
> On a hunch I reverted
>
> commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
> Author: Hans de Goede
> Date: Tue Jun 16 16:27:52 2015 +0200
>
> ACPI / video: Move backlight notifier to video_detect.c
>
> and the problem seems to be gone. Hans, any thoughts?
>
> >
> > - Sedat -
> >
> > > - Sedat -
> > >
> > > [1]
> > > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
> > > [2]
> > > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-
> 994.201508010158_amd64.deb
> > >
> > >> [ 24.001043] [drm] Memory usable by graphics device = 2048M
> > >> [ 24.001118] [drm] Replacing VGA console driver
> > >> [ 24.011642] [drm] Supports vblank timestamp caching Rev 2
> > >> (21.10.2013).
> > >> [ 24.011646] [drm] Driver supports precise vblank timestamp query.
> > >> [ 24.012480] vgaarb: device changed decodes:
> > >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> > >> [ 24.028005]
> > >> [ 24.028014] ==
> > >> [ 24.028020] [ INFO: possible circular locking dependency detected ]
> > >> [ 24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
> > >> [ 24.028032] ---
> > >> [ 24.028038] modprobe/740 is trying to acquire lock:
> > >> [ 24.028043] (init_mutex){+.+.+.}, at: []
> > >> acpi_video_get_backlight_type+0x17/0x164 [video]
> > >> [ 24.028060]
> > >> [ 24.028060] but task is already holding lock:
> > >> [ 24.028068] (&(&backlight_notifier)->rwsem){..}, at:
> > >> [] __blocking_notifier_call_chain+0x39/0x70
> > >> [ 24.028083]
> > >> [ 24.028083] which lock already depends on the new lock.
> > >> [ 24.028083]
> > >> [ 24.028095]
> > >> [ 24.028095] the existing dependency chain (in reverse order) is:
> > >> [ 24.028103]
> > >> [ 24.028103] -> #1 (&(&backlight_notifier)->rwsem){..}:
> > >> [ 24.028113][] lock_acquire+0xcf/0x280
> > >> [ 24.028121][] down_write+0x49/0x80
> > >> [ 24.028129][]
> > >> blocking_notifier_chain_register+0x21/0xb0
> > >> [ 24.028138][]
> > >> backlight_register_notifier+0x18/0x20
> > >> [ 24.028147][]
> > >> acpi_video_get_backlight_type+0xfa/0x164 [video]
> > >> [ 24.028158][] 0xa00a20e9
> > >> [ 24.028164][] do_one_initcall+0x88/0x1c0
> > >> [ 24.028172][] do_init_module+0x61/0x1ec
> > >> [ 24.028179][] load_module+0x2008/0x25c0
> > >> [ 24.028187][] SyS_init_module+0x126/0x140
> > >> [ 24.028194][]
> > >> entry_SYSCALL_64_fastpath+0x16/0x7a
> > >> [ 24.028202]
> > >> [ 24.028202] -> #0 (init_mutex){+.+.+.}:
> > >> [ 24.028211][] __lock_acquire+0x1f5d/0x21c0
> > >> [ 24.028218][] lock_acquire+0xcf/0x280
> > >> [ 24.0
Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.
> On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote: > > > On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote: > > > > > -Original Message- > > > > > From: Vivi, Rodrigo > > > > > Sent: Saturday, August 8, 2015 8:34 AM > > > > > To: intel-gfx@lists.freedesktop.org > > > > > Cc: Vivi, Rodrigo; Zhang, Xiong Y > > > > > Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 > > > > > lanes. > > > > > > > > > > DDI-A and DDI-E shares the 4 lanes. So when DDI-E is present we > > > > > need to configure lane count propperly for both. > > > > > > > > > > This was based on Sonika's > > > > > [PATCH] drm/i915/skl: Select DDIA lane capability based upon vbt > > > > > > > > > > Credits-to: Sonika Jindal > > > > > Cc: Xiong Zhang > > > > > Signed-off-by: Rodrigo Vivi > > > > > --- > > > > > drivers/gpu/drm/i915/intel_ddi.c | 12 ++-- > > > > > drivers/gpu/drm/i915/intel_dp.c | 8 +--- > > > > > 2 files changed, 15 insertions(+), 5 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > > > > > b/drivers/gpu/drm/i915/intel_ddi.c > > > > > index 110d546..557cecf 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c > > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c > > > > > @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct drm_device > > > > > *dev, enum port port) > > > > > struct intel_digital_port *intel_dig_port; > > > > > struct intel_encoder *intel_encoder; > > > > > struct drm_encoder *encoder; > > > > > - bool init_hdmi, init_dp; > > > > > + bool init_hdmi, init_dp, ddi_e_present; > > > > > + > > > > > + /* > > > > > + * On SKL we don't have a way to detect DDI-E so we > > > > > rely > > > > > on VBT. > > > > > + */ > > > > > + ddie_present = IS_SKYLAKE(dev) && > > > > > + (dev_priv > > > > > ->vbt.ddi_port_info[PORT_E].supports_dp > > > > > > > > > > > > + dev_priv > > > > > ->vbt.ddi_port_info[PORT_E].supports_dvi > > > > > > > > > > > > + dev_priv > > > > > ->vbt.ddi_port_info[PORT_E].supports_hdmi); > > > > [Zhang, Xiong Y] ddie_present should be ddi_e_present > > > > > > > > > > init_hdmi = (dev_priv > > > > > ->vbt.ddi_port_info[port].supports_dvi || > > > > >dev_priv > > > > > ->vbt.ddi_port_info[port].supports_hdmi); > > > > > @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct drm_device > > > > > *dev, enum port port) > > > > > intel_dig_port->port = port; > > > > > intel_dig_port->saved_port_bits = > > > > > I915_READ(DDI_BUF_CTL(port)) & > > > > > > > > > > (DDI_BUF_PORT_REVERSAL | > > > > > -DDI_A_4_LANES); > > > > > +ddi_e_present ? 0 : > > > > > DDI_A_4_LANES); > > > > [Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes when > > > > DDI-E doesn't exist, I think your patch will do nothing. > > > > > > Actually DDI_A_4_LANES is being already set unconditionally, so > > > Sonika's patch has no effect. > > [Zhang, Xiong Y] No. Sonika's patch set DDI_A_4_LANES under many > > conditions. > > + if (IS_SKYLAKE(dev) && port == PORT_A > > + && !(val & DDI_BUF_CTL_ENABLE) > > + && !dev_priv->vbt.ddi_e_used) > > + I915_WRITE(DDI_BUF_CTL(port), val | DDI_A_4_LANES) > > > > > > saved_port_bits goes to intel_dp->DP that goes to DDI_BUF_CTL and > > > also it is used to calculate the number of lanes. > > > > > > With this patch we stop setting DDI_A_4_LANES when ddi_e is present > > > so DDI-A keeps with 2 lanes and let other 2 lanes for DDI-E > > [Zhang, Xiong Y] Yes, this patch will clear DDI_A_4_LANES when ddi_e > > is present. > > But this patch won't set DDI_A_4_LANES under following conditions > > which is purpose for Sonika patch 1. Bios fail to driver eDP and > > doesn't enable DDI_A buffer > > If DDI_A isn't enabled we don't need to set DDI_A_4_LANES [Zhang, Xiong Y] From commit message on Sonika patch, she want to set DDI_A_4_LANES on such case. Maybe she met such fail case on one high resolution eDP screen. Let's Sonikia explain it. > > > 2. Bios clear DDI_A_4_LANES > > 3. DDI_E isn't present > > I don't agree... This is already covered on current code. DDI_A_4_LANES is > already being set when enabling DDI_A. > > > > > > thanks > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/1] drm/i915 : Wait until SYSTEM_RUNNING before loading CSR firmware
On Wednesday 15 July 2015 11:34:43 Daniel Vetter wrote:
> On Tue, Jul 14, 2015 at 01:37:32PM -0700, Greg KH wrote:
> > On Tue, Jul 14, 2015 at 11:22:35AM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 13, 2015 at 09:36:45AM -0700, jay.p.pa...@intel.com wrote:
> > > > From: Jay Patel
> > > >
> > > > NOTE: This is an interim solution which is targeted towards
> > > > Chrome OS/Android to be used until a long term solution is available.
> > > >
> > > > In this patch, request_firmware() is called in a worker thread
> > > > which initially waits for file system to be initialized and then
> > > > attempts to load the firmware.
> > >
> > > Aside: I posted a bunch of proof-of-principle patches to clean up dmc
> > > loading and convert over to using an explicit workqueue. They're being
> > > tested/made-to-actually-work right now I think.
> > >
> > > > "request_firmware_nowait()" is also using an asynchronous thread
> > > > running concurrently with the rest of the system initialization.
> > > > However, it tries to load firmware only once without checking the
> > > > sytem status and fails most of the time.
> > > >
> > > > Change-Id: I2cb16a768e54a85f48a6682d9690b4c8af844668
> >
> > What's this line for? :)
> >
> > > > Signed-off-by: Jay Patel
> > > > ---
> > > >
> > > > drivers/gpu/drm/i915/i915_drv.c | 2 ++
> > > > drivers/gpu/drm/i915/intel_csr.c | 58
> > > > 2 files changed, 49
> > > > insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > b/drivers/gpu/drm/i915/i915_drv.c index 8c8407d..eb6f7e3 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -559,6 +559,7 @@ void intel_hpd_cancel_work(struct drm_i915_private
> > > > *dev_priv)> > >
> > > > void i915_firmware_load_error_print(const char *fw_path, int err)
> > > > {
> > > >
> > > > DRM_ERROR("failed to load firmware %s (%d)\n", fw_path, err);
> > > >
> > > > + DRM_ERROR("The firmware file may be missing\n");
> > > >
> > > > /*
> > > >
> > > > * If the reason is not known assume -ENOENT since that's the
> > > > most
> > > >
> > > > @@ -574,6 +575,7 @@ void i915_firmware_load_error_print(const char
> > > > *fw_path, int err)> > >
> > > > "The driver is built-in, so to load the firmware you need
> > > > to\n"
> > > > "include it either in the kernel (see CONFIG_EXTRA_FIRMWARE)
> > > > or\n"
> > > > "in your initrd/initramfs image.\n");
> > > >
> > > > +
> > > >
> > > > }
> > > >
> > > > static void intel_suspend_encoders(struct drm_i915_private *dev_priv)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > > > b/drivers/gpu/drm/i915/intel_csr.c index 9311cdd..8d1f08c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_csr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > > > @@ -349,7 +349,7 @@ static void finish_csr_load(const struct firmware
> > > > *fw, void *context)> > >
> > > > /* load csr program during system boot, as needed for DC states
> > > > */
> > > > intel_csr_load_program(dev);
> > > > fw_loaded = true;
> > > >
> > > > -
> > > > + DRM_INFO("CSR Firmware Loaded\n");
> > > >
> > > > out:
> > > > if (fw_loaded)
> > > >
> > > > intel_runtime_pm_put(dev_priv);
> > > >
> > > > @@ -359,11 +359,46 @@ out:
> > > > release_firmware(fw);
> > > >
> > > > }
> > > >
> > > > +struct csr_firmware_work {
> > > > + struct work_struct work;
> > > > + struct module *module;
> > > > + struct drm_device *dev;
> > > > +};
> > > > +
> > > > +/* csr_firmware_work_func() - thread function for loading the
> > > > firmware*/
> > > > +static void csr_firmware_work_func(struct work_struct *work)
> > > > +{
> > > > + const struct firmware *fw;
> > > > + const struct csr_firmware_work *fw_work = container_of(work,
struct
> > > > csr_firmware_work, work); + int ret;
> > > > + struct drm_device *dev = fw_work->dev;
> > > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > > + struct intel_csr *csr = &dev_priv->csr;
> > > > +
> > > > + /* Wait until root filesystem is loaded in case the firmware
> > > > +* is not built-in but in /lib/firmware */
> > > > + while(system_state != SYSTEM_RUNNING){
> > > > + msleep(500);
> > > > + }
> > >
> > > Yeah, not going to merge that right now until we've had a decent
> > > discussion with Greg KH (since imo his stance of every driver creating
> > > it's own retry loop just doesn't work, especially not with gfx where
> > > init
> > > is hairy and you just don't want to retry without end).
> >
> > Exactly, this type of thing isn't good at all (especially given that
> > the code isn't even checkpatch clean...)
> >
> > Don't do this. If you really want to somehow handle built-in drivers
> > that need
Re: [Intel-gfx] [PATCH 6/6 v3] drm/i915: Enable HDMI on DDI-E
> On Wed, Aug 12, 2015 at 06:39:34PM +0800, Xiong Zhang wrote:
> > DDI-E doesn't have the correspondent GMBUS pin.
> >
> > We rely on VBT to tell us which one it being used instead.
> >
> > The DVI/HDMI on shared port couldn't exist.
> >
> > This patch isn't tested without hardware wchich has HDMI on DDI-E.
> >
> > v2: fix trailing whitespace
> > v3: WARN() take place of BUG()
>
> I asked for MISSING_CASE, not WARN.
> -Daniel
[Zhang, Xiong Y] Because DDI-E on SKL doesn't have correspondent GMBUS pin, it
should share such pin with DDI-B/C/D. We don't know the default GMBUS pin for
DDI-E if VBT doesn't tell us.
If VBT don't tell us or give us an invalid GMBUS pin, driver will fail in
getting HDMI info. In such case, we really need a warn which tell us why driver
couldn't read EDID info for HDMI on DDI-E.
thanks
>
> >
> > Signed-off-by: Xiong Zhang
> > Reviewed-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 5 +
> > drivers/gpu/drm/i915/intel_bios.c | 25 +
> > drivers/gpu/drm/i915/intel_hdmi.c | 18 ++
> > 3 files changed, 44 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 6d93334..5d8e7fe 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1414,6 +1414,10 @@ enum modeset_restore { #define DP_AUX_C
> 0x20
> > #define DP_AUX_D 0x30
> >
> > +#define DDC_PIN_B 0x05
> > +#define DDC_PIN_C 0x04
> > +#define DDC_PIN_D 0x06
> > +
> > struct ddi_vbt_port_info {
> > /*
> > * This is an index in the HDMI/DVI DDI buffer translation table.
> > @@ -1428,6 +1432,7 @@ struct ddi_vbt_port_info {
> > uint8_t supports_dp:1;
> >
> > uint8_t alternate_aux_channel;
> > + uint8_t alternate_ddc_pin;
> > };
> >
> > enum psr_lines_to_wait {
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 16cdf17..8140531 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -894,7 +894,7 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv, enum port port,
> > uint8_t hdmi_level_shift;
> > int i, j;
> > bool is_dvi, is_hdmi, is_dp, is_edp, is_crt;
> > - uint8_t aux_channel;
> > + uint8_t aux_channel, ddc_pin;
> > /* Each DDI port can have more than one value on the "DVO Port" field,
> > * so look for all the possible values for each port and abort if more
> > * than one is found. */
> > @@ -928,6 +928,7 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv, enum port port,
> > return;
> >
> > aux_channel = child->raw[25];
> > + ddc_pin = child->common.ddc_pin;
> >
> > is_dvi = child->common.device_type &
> DEVICE_TYPE_TMDS_DVI_SIGNALING;
> > is_dp = child->common.device_type &
> DEVICE_TYPE_DISPLAYPORT_OUTPUT;
> > @@ -959,11 +960,27 @@ static void parse_ddi_port(struct
> drm_i915_private *dev_priv, enum port port,
> > DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port));
> >
> > if (is_dvi) {
> > - if (child->common.ddc_pin == 0x05 && port != PORT_B)
> > + if (port == PORT_E) {
> > + info->alternate_ddc_pin = ddc_pin;
> > + /* if DDIE share ddc pin with other port, then
> > +* dvi/hdmi couldn't exist on the shared port.
> > +* Otherwise they share the same ddc bin and system
> > +* couldn't communicate with them seperately. */
> > + if (ddc_pin == DDC_PIN_B) {
> > +
> > dev_priv->vbt.ddi_port_info[PORT_B].supports_dvi = 0;
> > +
> > dev_priv->vbt.ddi_port_info[PORT_B].supports_hdmi = 0;
> > + } else if (ddc_pin == DDC_PIN_C) {
> > +
> > dev_priv->vbt.ddi_port_info[PORT_C].supports_dvi = 0;
> > +
> > dev_priv->vbt.ddi_port_info[PORT_C].supports_hdmi = 0;
> > + } else if (ddc_pin == DDC_PIN_D) {
> > +
> > dev_priv->vbt.ddi_port_info[PORT_D].supports_dvi = 0;
> > +
> > dev_priv->vbt.ddi_port_info[PORT_D].supports_hdmi = 0;
> > + }
> > + } else if (ddc_pin == DDC_PIN_B && port != PORT_B)
> > DRM_DEBUG_KMS("Unexpected DDC pin for port B\n");
> > - if (child->common.ddc_pin == 0x04 && port != PORT_C)
> > + else if (ddc_pin == DDC_PIN_C && port != PORT_C)
> > DRM_DEBUG_KMS("Unexpected DDC pin for port C\n");
> > - if (child->common.ddc_pin == 0x06 && port != PORT_D)
> > + else if (ddc_pin == DDC_PIN_D && port != PORT_D)
> > DRM_DEBUG_KMS("Unexpected DDC pin for port D\n");
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > inde
Re: [Intel-gfx] [PATCH 0/9 v6] Batch submission via GuC
On Wed, Aug 12, 2015 at 07:57:37AM -0700, Gordon, David S wrote: > On 12/08/15 15:43, Dave Gordon wrote: > > This patch series enables command submission via the GuC. In this mode, > > instead of the host CPU driving the execlist port directly, it hands > > over work items to the GuC, using a doorbell mechanism to tell the GuC > > that new items have been added to its work queue. The GuC then dispatches > > contexts to the various GPU engines, and manages the resulting context- > > switch interrupts. Completion of a batch is however still signalled to > > the CPU; the GuC is not involved in handling user interrupts. > > > > There are two subsequences within the patch series: > > > >drm/i915: GuC-specific firmware loader > >drm/i915: Debugfs interface to read GuC load status > > > > These two patches provide the GuC loader and a debugfs interface to > > verify the resulting state. At this point in the sequence we can load > > and activate the GuC firmware, but not submit any batches through it. > > (This is nonetheless a potentially useful state, as the GuC could do > > other useful work even when not handling batch submissions). > > > >drm/i915: Expose one LRC function for GuC submission mode > >drm/i915: Prepare for GuC-based command submission > >drm/i915: Enable GuC firmware log > >drm/i915: Implementation of GuC submission client > >drm/i915: Interrupt routing for GuC submission > >drm/i915: Integrate GuC-based command submission > >drm/i915: Debugfs interface for GuC submission statistics > > > > In this second section, we implement the GuC submission mechanism, and > > link it into the (execlist-based) submission path. At this stage, it is > > not yet enabled by default; it is activated only if the kernel command > > line explicitly switches it on. > > > > The GuC firmware itself is not included in this patchset; it is or will > > be available for download from https://01.org/linuxgraphics/downloads/ > > This driver works with and requires GuC firmware revision 3.x. It will > > not work with any firmware version 1.x, as the GuC protocol in those > > revisions was incompatible and is no longer supported. > > > > On platforms where there is no GuC, or where GuC submission is not > > specifically enabled, batch submission will continue to use the execlist > > (or ringbuffer) mechanisms. On the other hand, if GuC submission is > > requested but the GuC firmware cannot be found or is invalid, the GPU > > will be unusable. > > > > It is expected that a subsequent patch will enable GuC submission by > > default once the signed firmware is published on 01.org. > > > > Ben Widawsky (0): > > Vinit Azad (0): > > Michael H. Nguyen (0): > >created the original versions on which some of these patches are based. > > > > Alex Dai (5): > >drm/i915: GuC-specific firmware loader > >drm/i915: Debugfs interface to read GuC load status > >drm/i915: Prepare for GuC-based command submission > >drm/i915: Enable GuC firmware log > >drm/i915: Integrate GuC-based command submission > > > > Dave Gordon (4): > >drm/i915: Expose one LRC function for GuC submission mode > >drm/i915: Implementation of GuC submission client > >drm/i915: Interrupt routing for GuC submission > >drm/i915: Debugfs interface for GuC submission statistics > > > > Documentation/DocBook/drm.tmpl | 14 + > > drivers/gpu/drm/i915/Makefile | 4 + > > drivers/gpu/drm/i915/i915_debugfs.c| 146 - > > drivers/gpu/drm/i915/i915_dma.c| 9 + > > drivers/gpu/drm/i915/i915_drv.h| 11 + > > drivers/gpu/drm/i915/i915_gem.c| 16 + > > drivers/gpu/drm/i915/i915_gpu_error.c | 14 +- > > drivers/gpu/drm/i915/i915_guc_reg.h| 17 +- > > drivers/gpu/drm/i915/i915_guc_submission.c | 901 > > + > > drivers/gpu/drm/i915/i915_reg.h| 15 +- > > drivers/gpu/drm/i915/intel_guc.h | 122 > > drivers/gpu/drm/i915/intel_guc_fwif.h | 9 +- > > drivers/gpu/drm/i915/intel_guc_loader.c| 611 +++ > > drivers/gpu/drm/i915/intel_lrc.c | 65 ++- > > drivers/gpu/drm/i915/intel_lrc.h | 8 + > > 15 files changed, 1918 insertions(+), 44 deletions(-) > > create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c > > create mode 100644 drivers/gpu/drm/i915/intel_guc.h > > create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c > > Tom O'Rourke has already R-B'ed the previous [v5] versions of these, and > there are no substantive changes to patches 2, 3, 4, 5, 7 and 8, so we > can carry that over; also, the change in patch 1 is just an update to a > comment noted in Tom's earlier reviews as being out-of-date. > > I haven't included patch 10 (enable-by-default) as we've decided to wait > until the signed firmware is publicly available on 01.org before > making it the default. > > So, it's really
Re: [Intel-gfx] [PATCH] drm/i915: Only dither on 6bpc panels
Thanks for the quick fix! Comments below...
On 08/12/2015 11:43 AM, Daniel Vetter wrote:
In
commit d328c9d78d64ca11e744fe227096990430a88477
Author: Daniel Vetter
Date: Fri Apr 10 16:22:37 2015 +0200
drm/i915: Select starting pipe bpp irrespective or the primary plane
we started to select the pipe bpp from sink capabilities and not from
the primary framebuffer - that one might change (and we don't want to
incur a modeset) and sprites might contain higher bpp content too.
Problem is that now if you have a 10bpc screen and display 24bpp rgb
primary then we select dithering, and apparently that mangles the high
8 bits even (even thought you'd expect dithering only to affect how
12bpc gets mapped into 10bpc). And that mangling upsets certain users.
Probably doesn't matter, but your explanation of the former problem here
is slightly off. We also selected dithering on a 8 bpc screen displaying
a 24bpp rgb primary, because pipe_bpp is 24 for such a typical 8 bpc
sink, but since the commit mentioned above, base_bpp is always the
absolute maximum supported by the hardware, e.g., 36 bpp on my Ironlake
chip. Iow. the only way to not get dithering would have been to connect
a deep color 12 bpc display, so pipe_bpp == 36 == base_bpp.
Hence only enable dithering on 6bpc screens where we difinitely and
always want it.
Other than that, i tested the patch on both 8 bpc output with my
measurement equipment and on the internal laptop 6 bpc panel, and
everything is fine now - No banding on the 6 bpc panel, no banding or
equipment failure on the external 8 bpc output. Life is good again :)
Reviewed-and-tested-by: Mario Kleiner
thanks,
-mario
Cc: Mario Kleiner
Reported-by: Mario Kleiner
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9a2f229a1c3a..128462e0a0b5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12186,7 +12186,9 @@ encoder_retry:
goto encoder_retry;
}
- pipe_config->dither = pipe_config->pipe_bpp != base_bpp;
+ /* Dithering seems to not pass-through bits correctly when it should, so
+* only enable it on 6bpc panels. */
+ pipe_config->dither = pipe_config->pipe_bpp == 6*3;
DRM_DEBUG_KMS("plane bpp: %i, pipe bpp: %i, dithering: %i\n",
base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] lib/rendercopy_gen9: Setup Push constant pointer before sending BTP commands
On Wed, Aug 12, 2015 at 03:10:18PM +0300, Joonas Lahtinen wrote: > On ke, 2015-08-12 at 12:26 +0100, Arun Siluvery wrote: > > From Gen9, by default push constant command is not committed to the > > shader unit > > untill the corresponding shader's BTP_* command is parsed. This is > > the > > behaviour when set shader is enabled. This patch updates the batch to > > follow > > this requirement otherwise it results in gpu hang. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959 > > > > Set shader need to be disabled if legacy behaviour is required. > > > > Cc: Ben Widawsky > > Cc: Joonas Lahtinen > > Cc: Mika Kuoppala > > Signed-off-by: Arun Siluvery > > Reviewed-by: Joonas Lahtinen > Repeating what I said on the mesa thread: Does anyone understand why this actually causes a hang on the IGT test? I certainly don't. The docs are pretty clear that the constant command is not committed until the BTP command, but I can't make any sense of how it related to a GPU hang. [snip] --- Ben Widawsky, 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] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type
On Monday, August 10, 2015 08:29:00 PM Sedat Dilek wrote:
> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
> > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek wrote:
> >> Hi,
> >>
> >> this my first build of a 4.2-rcN Linux-kernel and I see this...
> >>
> >
> > Just FYI:
> >
> > I am *not* seeing this with drm-intel-nightly from below url.
> >
> > Also, I plan to test Linux v4.2-rc5.
> >
>
> [ CC Linus ]
>
> Knock Knock Knock.
The lock this is related to has been introduced by a commit from Hans (CCed).
Unfortunately, I'm out of office this week and I'll be traveling next week,
so my personal ability to look into this issue is rather limited ATM. Sorry
about that.
> This issue still remains here (with CONFIG_DRM_I915=m)...
>
> [ 18.269792] ==
> [ 18.269798] [ INFO: possible circular locking dependency detected ]
> [ 18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
> [ 18.269810] ---
> [ 18.269816] modprobe/727 is trying to acquire lock:
> [ 18.269822] (init_mutex){+.+.+.}, at: []
> acpi_video_get_backlight_type+0x17/0x164 [video]
> [ 18.269840]
> [ 18.269840] but task is already holding lock:
> [ 18.269848] (&(&backlight_notifier)->rwsem){..}, at:
> [] __blocking_notifier_call_chain+0x39/0x70
> [ 18.269864]
> [ 18.269864] which lock already depends on the new lock.
> [ 18.269864]
> [ 18.269875]
> [ 18.269875] the existing dependency chain (in reverse order) is:
> [ 18.269884]
> ...
>
> Full dmesg log and kernel-config attached.
>
> Shall I add Rusty and modules/modprobe folks?
>
> - Sedat -
>
> > - Sedat -
> >
> > [1]
> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
> > [2]
> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-994.201508010158_amd64.deb
> >
> >> [ 24.001043] [drm] Memory usable by graphics device = 2048M
> >> [ 24.001118] [drm] Replacing VGA console driver
> >> [ 24.011642] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> >> [ 24.011646] [drm] Driver supports precise vblank timestamp query.
> >> [ 24.012480] vgaarb: device changed decodes:
> >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> >> [ 24.028005]
> >> [ 24.028014] ==
> >> [ 24.028020] [ INFO: possible circular locking dependency detected ]
> >> [ 24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
> >> [ 24.028032] ---
> >> [ 24.028038] modprobe/740 is trying to acquire lock:
> >> [ 24.028043] (init_mutex){+.+.+.}, at: []
> >> acpi_video_get_backlight_type+0x17/0x164 [video]
> >> [ 24.028060]
> >> [ 24.028060] but task is already holding lock:
> >> [ 24.028068] (&(&backlight_notifier)->rwsem){..}, at:
> >> [] __blocking_notifier_call_chain+0x39/0x70
> >> [ 24.028083]
> >> [ 24.028083] which lock already depends on the new lock.
> >> [ 24.028083]
> >> [ 24.028095]
> >> [ 24.028095] the existing dependency chain (in reverse order) is:
> >> [ 24.028103]
> >> [ 24.028103] -> #1 (&(&backlight_notifier)->rwsem){..}:
> >> [ 24.028113][] lock_acquire+0xcf/0x280
> >> [ 24.028121][] down_write+0x49/0x80
> >> [ 24.028129][]
> >> blocking_notifier_chain_register+0x21/0xb0
> >> [ 24.028138][]
> >> backlight_register_notifier+0x18/0x20
> >> [ 24.028147][]
> >> acpi_video_get_backlight_type+0xfa/0x164 [video]
> >> [ 24.028158][] 0xa00a20e9
> >> [ 24.028164][] do_one_initcall+0x88/0x1c0
> >> [ 24.028172][] do_init_module+0x61/0x1ec
> >> [ 24.028179][] load_module+0x2008/0x25c0
> >> [ 24.028187][] SyS_init_module+0x126/0x140
> >> [ 24.028194][]
> >> entry_SYSCALL_64_fastpath+0x16/0x7a
> >> [ 24.028202]
> >> [ 24.028202] -> #0 (init_mutex){+.+.+.}:
> >> [ 24.028211][] __lock_acquire+0x1f5d/0x21c0
> >> [ 24.028218][] lock_acquire+0xcf/0x280
> >> [ 24.028225][] mutex_lock_nested+0x65/0x3c0
> >> [ 24.028233][]
> >> acpi_video_get_backlight_type+0x17/0x164 [video]
> >> [ 24.028243][]
> >> acpi_video_backlight_notify+0x19/0x2f [video]
> >> [ 24.028253][] notifier_call_chain+0x5d/0x80
> >> [ 24.028260][]
> >> __blocking_notifier_call_chain+0x51/0x70
> >> [ 24.028269][]
> >> blocking_notifier_call_chain+0x16/0x20
> >> [ 24.028278][]
> >> backlight_device_register+0x197/0x240
> >> [ 24.028286][]
> >> intel_backlight_register+0xb3/0x180 [i915]
> >> [ 24.028336][]
> >> intel_modeset_gem_init+0x176/0x190 [i915]
> >> [ 24.028371][] i915_driver_load+0xf12/0x14d0
> >> [i915]
> >> [ 24.028406][] drm_dev_register+0xb1/0x100
> >> [drm]
> >> [ 24.028425][]
Re: [Intel-gfx] [PATCH 18/18] drm/i915: Add CSC correction for BDW/SKL/BXT
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7110 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -1 283/283 282/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/1] drm/i915 : Wait until SYSTEM_RUNNING before loading CSR firmware
On Wed, Jul 15, 2015 at 2:34 AM, Daniel Vetter wrote:
>
> On Tue, Jul 14, 2015 at 01:37:32PM -0700, Greg KH wrote:
> > On Tue, Jul 14, 2015 at 11:22:35AM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 13, 2015 at 09:36:45AM -0700, jay.p.pa...@intel.com wrote:
> > > > From: Jay Patel
> > > >
> > > > NOTE: This is an interim solution which is targeted towards
> > > > Chrome OS/Android to be used until a long term solution is
available.
> > > >
> > > > In this patch, request_firmware() is called in a worker thread
> > > > which initially waits for file system to be initialized and then
> > > > attempts to load the firmware.
> > >
> > > Aside: I posted a bunch of proof-of-principle patches to clean up dmc
> > > loading and convert over to using an explicit workqueue. They're being
> > > tested/made-to-actually-work right now I think.
> > >
> > > > "request_firmware_nowait()" is also using an asynchronous thread
> > > > running concurrently with the rest of the system initialization.
> > > > However, it tries to load firmware only once without checking the
> > > > sytem status and fails most of the time.
> > > >
> > > > Change-Id: I2cb16a768e54a85f48a6682d9690b4c8af844668
> >
> > What's this line for? :)
> >
> > > > Signed-off-by: Jay Patel
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.c | 2 ++
> > > > drivers/gpu/drm/i915/intel_csr.c | 58
> > > > 2 files changed, 49 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
> > > > index 8c8407d..eb6f7e3 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -559,6 +559,7 @@ void intel_hpd_cancel_work(struct
drm_i915_private *dev_priv)
> > > > void i915_firmware_load_error_print(const char *fw_path, int err)
> > > > {
> > > > DRM_ERROR("failed to load firmware %s (%d)\n", fw_path, err);
> > > > + DRM_ERROR("The firmware file may be missing\n");
> > > >
> > > > /*
> > > >* If the reason is not known assume -ENOENT since that's the most
> > > > @@ -574,6 +575,7 @@ void i915_firmware_load_error_print(const char
*fw_path, int err)
> > > > "The driver is built-in, so to load the firmware you need to\n"
> > > > "include it either in the kernel (see CONFIG_EXTRA_FIRMWARE)
or\n"
> > > > "in your initrd/initramfs image.\n");
> > > > +
> > > > }
> > > >
> > > > static void intel_suspend_encoders(struct drm_i915_private
*dev_priv)
> > > > diff --git a/drivers/gpu/drm/i915/intel_csr.c
b/drivers/gpu/drm/i915/intel_csr.c
> > > > index 9311cdd..8d1f08c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_csr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > > > @@ -349,7 +349,7 @@ static void finish_csr_load(const struct
firmware *fw, void *context)
> > > > /* load csr program during system boot, as needed for DC states */
> > > > intel_csr_load_program(dev);
> > > > fw_loaded = true;
> > > > -
> > > > + DRM_INFO("CSR Firmware Loaded\n");
> > > > out:
> > > > if (fw_loaded)
> > > > intel_runtime_pm_put(dev_priv);
> > > > @@ -359,11 +359,46 @@ out:
> > > > release_firmware(fw);
> > > > }
> > > >
> > > > +struct csr_firmware_work {
> > > > + struct work_struct work;
> > > > + struct module *module;
> > > > + struct drm_device *dev;
> > > > +};
> > > > +
> > > > +/* csr_firmware_work_func() - thread function for loading the
firmware*/
> > > > +static void csr_firmware_work_func(struct work_struct *work)
> > > > +{
> > > > + const struct firmware *fw;
> > > > + const struct csr_firmware_work *fw_work = container_of(work,
struct csr_firmware_work, work);
> > > > + int ret;
> > > > + struct drm_device *dev = fw_work->dev;
> > > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > > + struct intel_csr *csr = &dev_priv->csr;
> > > > +
> > > > + /* Wait until root filesystem is loaded in case the firmware
> > > > + * is not built-in but in /lib/firmware */
> > > > + while(system_state != SYSTEM_RUNNING){
> > > > + msleep(500);
> > > > + }
> > >
> > > Yeah, not going to merge that right now until we've had a decent
> > > discussion with Greg KH (since imo his stance of every driver creating
> > > it's own retry loop just doesn't work, especially not with gfx where
init
> > > is hairy and you just don't want to retry without end).
> >
> > Exactly, this type of thing isn't good at all (especially given that
> > the code isn't even checkpatch clean...)
> >
> > Don't do this. If you really want to somehow handle built-in drivers
> > that need firmware before the root filesystem is present, then use the
> > async firmware loading interface, don't sit and spin, that's crazy.
>
> This code is called from a work queue already to facilitate async loading.
> I want an explicit work queue so that we properly sync with it everywhere
> like driver unload or resume (otherwise we need a completion or
> something). And with an explicit worker I can put the entire
Re: [Intel-gfx] [PATCH v2 00/22] Enable gpu switching on the MacBook Pro
Hi Daniel, On Wed, Aug 12, 2015 at 04:16:25PM +0200, Daniel Vetter wrote: > > * Reprobing if the inactive GPU initializes before the apple-gmux module: > > v1 used Matthew Garrett's approach of adding a driver callback. > > v2 simply generates a hotplug event instead. nouveau polls its outputs > > every 10 seconds so we want it to poll immediately once apple-gmux > > registers. That is achieved by the hotplug event. The i915 driver is > > changed to behave identically to nouveau. (Right now it deletes LVDS > > and eDP connectors from the mode configuration if they can't be probed, > > deeming them to be ghosts.) > > I thought -EDEFERREDPROBE is what we should be using if drivers don't get > loaded in the right order? Hand-rolling depency avoidance stuff is imo a > horrible idea. [...] > I think just reading edid and the relevant dp aux data in apple-gmux or > somewhere like that and stalling driver load until that's ready is the > only clean option. I'm afraid we can't stall initialization of a driver like that because even though the GPU may not be switched to the panel, it may still have an external monitor attached. All MacBook Pros have external DP and/or HDMI ports and these are either soldered to the discrete GPU (model year 2011 and onwards) or switchable between the discrete and integrated GPU (until 2010; I think they are even switchable separately from the panel). So basically we'd have to initialize the driver normally, and if intel_lvds_init() or intel_edp_init_connector() fail we'd have to somehow pass that up the call chain so that i915_pci_probe() can return -EPROBE_DEFER. And whenever we're asked to reprobe we'd repeat initialization of the LVDS or eDP connector. I'm wondering what the benefit is compared to just keeping the connector in the mode configuration, but with status disconnected, and reprobing it when the ->output_poll_changed callback gets invoked? Because that's what nouveau already does, and what I've changed i915 to do with patch 13. vga_switcheroo calls drm_kms_helper_hotplug_event() when the handler registers (patch 11), which will invoke ->output_poll_changed. So we're talking about the Official DRM Callback [tm] to probe outputs, not "hand-rolling depency avoidance". :-) > > * Framebuffer recreation if the inactive GPU initializes before the > > apple-gmux module (i.e. discarding the default 1024x768 fb and replacing > > with a new one with the actual panel resolution): v1 only supported this > > for i915, v2 has a generic solution which works with nouveau and radeon > > as well. (Necessary if the discrete GPU is forced to be the inactive one > > on boot via the EFI variable.) > > Would completely remove the need for this ;-) Unfortunately not: We'd still have to initialize the driver to be able to drive external displays. If there are initially no connectors with modes, we'll once again end up with the 1024x768 fb. > You can't share the dp aux like that. It's true that we need a bit more > data (there's a few eDP related feature blocsk we need), but sharing the > aux channel entirely is no-go. If you do you get drivers trying to link > train and at best this fails and at worst you'll upset the configuration > of the other driver and piss of the panel enough to need a hard reset > until it works again. Yes, so far proxying of the AUX channel is read-only. In those cases when writing is necessary for setting up the output, I'm adding code to check if the current content of the DPCD is identical to what's being written and if so, skip the write. We'll see if this stategy is sufficient for the drivers to set up their outputs. > I think the real tricky bit here with vgaswitcheroo is locking, I need to > take a separate lock at the patches for that. Locking when switching only the DDC lines is facilitated by the ddc_lock attribute of struct vgasr_priv. This is all local to vga_switcheroo.c and contained in patches 5 and 6. Locking when proxying the AUX channel is facilitated by the hw_mutex attribute of struct drm_dp_aux. nouveau has its own locking mechanism contained in drivers/gpu/drm/nouveau/nvkm/subdev/i2c/pad*.c. Thus, when proxying via nouveau, there are two locking mechanisms at work (drm_dp_aux hw_mutex as outer lock + pad as inner lock). This is nothing introduced by this patch set, all existing code. Locking of access to the struct vgasr_priv is facilitated by the vgasr_mutex in vga_switcheroo.c. Also existing code. Best regards, Lukas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] tests/kms_mmap_write_crc: Demonstrate the need for end_cpu_access
It requires i915 changes to add end_cpu_access().
Signed-off-by: Tiago Vignatti
---
tests/kms_mmap_write_crc.c | 63 --
1 file changed, 55 insertions(+), 8 deletions(-)
diff --git a/tests/kms_mmap_write_crc.c b/tests/kms_mmap_write_crc.c
index e24d535..59ac9e7 100644
--- a/tests/kms_mmap_write_crc.c
+++ b/tests/kms_mmap_write_crc.c
@@ -67,6 +67,24 @@ static char *dmabuf_mmap_framebuffer(int drm_fd, struct
igt_fb *fb)
return ptr;
}
+static void dmabuf_sync_start(void)
+{
+ struct dma_buf_sync sync_start;
+
+ memset(&sync_start, 0, sizeof(sync_start));
+ sync_start.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_RW;
+ do_ioctl(dma_buf_fd, DMA_BUF_IOCTL_SYNC, &sync_start);
+}
+
+static void dmabuf_sync_end(void)
+{
+ struct dma_buf_sync sync_end;
+
+ memset(&sync_end, 0, sizeof(sync_end));
+ sync_end.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_RW;
+ do_ioctl(dma_buf_fd, DMA_BUF_IOCTL_SYNC, &sync_end);
+}
+
static void test_begin_access(data_t *data)
{
igt_display_t *display = &data->display;
@@ -103,14 +121,11 @@ static void test_begin_access(data_t *data)
caching = gem_get_caching(data->drm_fd, fb->gem_handle);
igt_assert(caching == I915_CACHING_NONE || caching ==
I915_CACHING_DISPLAY);
- // Uncomment the following for flush and the crc check next passes. It
- // requires the kernel counter-part of it implemented obviously.
- // {
- // struct dma_buf_sync sync_start;
- // memset(&sync_start, 0, sizeof(sync_start));
- // sync_start.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_RW;
- // do_ioctl(dma_buf_fd, DMA_BUF_IOCTL_SYNC, &sync_start);
- // }
+ /*
+* firstly demonstrate the need for DMA_BUF_SYNC_START
("begin_cpu_access")
+*/
+
+ dmabuf_sync_start();
/* use dmabuf pointer to make the other fb all white too */
buf = malloc(fb->size);
@@ -126,6 +141,38 @@ static void test_begin_access(data_t *data)
/* check that the crc is as expected, which requires that caches got
flushed */
igt_pipe_crc_collect_crc(data->pipe_crc, &crc);
igt_assert_crc_equal(&crc, &data->ref_crc);
+
+ /*
+* now demonstrates the need for DMA_BUF_SYNC_END ("end_cpu_access")
+*/
+
+ /* start over, writing non-white to the fb again and flip to it to make
it
+* fully flushed */
+ cr = igt_get_cairo_ctx(data->drm_fd, fb);
+ igt_paint_test_pattern(cr, fb->width, fb->height);
+ cairo_destroy(cr);
+
+ igt_plane_set_fb(data->primary, fb);
+ igt_display_commit(display);
+
+ /* sync start, to move to CPU domain */
+ dmabuf_sync_start();
+
+ /* use dmabuf pointer in the same fb to make it all white */
+ buf = malloc(fb->size);
+ igt_assert(buf != NULL);
+ memset(buf, 0xff, fb->size);
+ memcpy(ptr, buf, fb->size);
+ free(buf);
+
+ /* there's an implicit flush in set_fb() as well (to set to the GTT
domain),
+* so if we don't do it and instead write directly into the fb as it is
the
+* scanout, that should demonstrate the need for end_cpu_access */
+ dmabuf_sync_end();
+
+ /* check that the crc is as expected, which requires that caches got
flushed */
+ igt_pipe_crc_collect_crc(data->pipe_crc, &crc);
+ igt_assert_crc_equal(&crc, &data->ref_crc);
}
static bool prepare_crtc(data_t *data)
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] tests: Add kms_mmap_write_crc for cache coherency tests
This program can be used to detect when the writes don't land in scanout due
cache incoherency. Although this seems a problem inherently of non-LCC machines
("Atom"), this particular test catches a cache dirt on scanout on LLC machines
as well. It's inspired in Ville's kms_pwrite_crc.c and can be used also to test
the correctness of the driver's begin_cpu_access (TODO end_cpu_access).
To see the need for flush, one has to run this same binary a few times cause
it's not 100% reproducible (in my Core machine it's always possible to catch
the problem by running it at most 5 times).
Signed-off-by: Tiago Vignatti
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/kms_mmap_write_crc.c | 236 +
3 files changed, 238 insertions(+)
create mode 100644 tests/kms_mmap_write_crc.c
diff --git a/tests/.gitignore b/tests/.gitignore
index 5bc4a58..9ba1e48 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -140,6 +140,7 @@ kms_force_connector
kms_frontbuffer_tracking
kms_legacy_colorkey
kms_mmio_vs_cs_flip
+kms_mmap_write_crc
kms_pipe_b_c_ivb
kms_pipe_crc_basic
kms_plane
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 5b2072e..31c5508 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -163,6 +163,7 @@ TESTS_progs = \
kms_3d \
kms_fence_pin_leak \
kms_force_connector \
+ kms_mmap_write_crc \
kms_pwrite_crc \
kms_sink_crc_basic \
prime_udl \
diff --git a/tests/kms_mmap_write_crc.c b/tests/kms_mmap_write_crc.c
new file mode 100644
index 000..e24d535
--- /dev/null
+++ b/tests/kms_mmap_write_crc.c
@@ -0,0 +1,236 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Tiago Vignatti
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+#include "intel_chipset.h"
+#include "ioctl_wrappers.h"
+#include "igt_aux.h"
+
+IGT_TEST_DESCRIPTION(
+ "Use the display CRC support to validate mmap write to an already uncached
future scanout buffer.");
+
+typedef struct {
+ int drm_fd;
+ igt_display_t display;
+ struct igt_fb fb[2];
+ igt_output_t *output;
+ igt_plane_t *primary;
+ enum pipe pipe;
+ igt_crc_t ref_crc;
+ igt_pipe_crc_t *pipe_crc;
+ uint32_t devid;
+} data_t;
+
+int dma_buf_fd;
+
+static char *dmabuf_mmap_framebuffer(int drm_fd, struct igt_fb *fb)
+{
+ char *ptr = NULL;
+
+ dma_buf_fd = prime_handle_to_fd(drm_fd, fb->gem_handle);
+ igt_assert(errno == 0);
+
+ ptr = mmap(NULL, fb->size, PROT_READ | PROT_WRITE, MAP_SHARED,
dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+
+ return ptr;
+}
+
+static void test_begin_access(data_t *data)
+{
+ igt_display_t *display = &data->display;
+ igt_output_t *output = data->output;
+ struct igt_fb *fb = &data->fb[1];
+ drmModeModeInfo *mode;
+ cairo_t *cr;
+ char *ptr;
+ uint32_t caching;
+ void *buf;
+ igt_crc_t crc;
+
+ mode = igt_output_get_mode(output);
+
+ /* create a non-white fb where we can write later */
+ igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE, fb);
+
+ ptr = dmabuf_mmap_framebuffer(data->drm_fd, fb);
+
+ cr = igt_get_cairo_ctx(data->drm_fd, fb);
+ igt_paint_test_pattern(cr, fb->width, fb->height);
+ cairo_destroy(cr);
+
+ /* flip to it to make it UC/WC and fully flushed */
+ igt_plane_set_fb(data->primary, fb);
+ igt_display_commit(display);
+
+ /* flip back the original white buffer */
+ igt_plane_set_fb(data->primary, &data->fb[0]);
+ igt_display_commit(display);
+
+ /* make sure cac
[Intel-gfx] [PATCH 3/7] prime_mmap: Add basic tests to write in a bo using CPU
This patch adds test_correct_cpu_write, which maps the texture buffer through a
prime fd and then writes directly to it using the CPU. It stresses the driver
to guarantee cache synchronization among the different domains.
This test also adds test_forked_cpu_write, which creates the GEM bo in one
process and pass the prime handle of the it to another process, which in turn
uses the handle only to map and write. Grossly speaking this test simulates
Chrome OS architecture, where the Web content ("unpriviledged process") maps
and CPU-draws a buffer, which was previously allocated in the GPU process
("priviledged process").
This requires kernel modifications (Daniel Thompson's "drm: prime: Honour
O_RDWR during prime-handle-to-fd").
Signed-off-by: Tiago Vignatti
---
lib/ioctl_wrappers.c | 5 +++-
tests/prime_mmap.c | 65
2 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 53bd635..941fa66 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1125,6 +1125,9 @@ void gem_require_ring(int fd, int ring_id)
/* prime */
+#ifndef DRM_RDWR
+#define DRM_RDWR O_RDWR
+#endif
/**
* prime_handle_to_fd:
* @fd: open i915 drm file descriptor
@@ -1142,7 +1145,7 @@ int prime_handle_to_fd(int fd, uint32_t handle)
memset(&args, 0, sizeof(args));
args.handle = handle;
- args.flags = DRM_CLOEXEC;
+ args.flags = DRM_CLOEXEC | DRM_RDWR;
args.fd = -1;
do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args);
diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
index dc59e8f..ad91371 100644
--- a/tests/prime_mmap.c
+++ b/tests/prime_mmap.c
@@ -22,6 +22,7 @@
*
* Authors:
*Rob Bradford
+ *Tiago Vignatti
*
*/
@@ -66,6 +67,12 @@ fill_bo(uint32_t handle, size_t size)
}
static void
+fill_bo_cpu(char *ptr)
+{
+ memcpy(ptr, pattern, sizeof(pattern));
+}
+
+static void
test_correct(void)
{
int dma_buf_fd;
@@ -180,6 +187,62 @@ test_forked(void)
gem_close(fd, handle);
}
+/* test CPU write. This has a rather big implication for the driver which must
+ * guarantee cache synchronization when writing the bo using CPU. */
+static void
+test_correct_cpu_write(void)
+{
+ int dma_buf_fd;
+ char *ptr;
+ uint32_t handle;
+
+ handle = gem_create(fd, BO_SIZE);
+
+ dma_buf_fd = prime_handle_to_fd(fd, handle);
+ igt_assert(errno == 0);
+
+ /* Check correctness of map using write protection (PROT_WRITE) */
+ ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+
+ /* Fill bo using CPU */
+ fill_bo_cpu(ptr);
+
+ /* Check pattern correctness */
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
+
+ munmap(ptr, BO_SIZE);
+ close(dma_buf_fd);
+ gem_close(fd, handle);
+}
+
+/* map from another process and then write using CPU */
+static void
+test_forked_cpu_write(void)
+{
+ int dma_buf_fd;
+ char *ptr;
+ uint32_t handle;
+
+ handle = gem_create(fd, BO_SIZE);
+
+ dma_buf_fd = prime_handle_to_fd(fd, handle);
+ igt_assert(errno == 0);
+
+ igt_fork(childno, 1) {
+ ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE , MAP_SHARED,
dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+ fill_bo_cpu(ptr);
+
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
+ munmap(ptr, BO_SIZE);
+ close(dma_buf_fd);
+ }
+ close(dma_buf_fd);
+ igt_waitchildren();
+ gem_close(fd, handle);
+}
+
static void
test_refcounting(void)
{
@@ -346,6 +409,8 @@ igt_main
{ "test_map_unmap", test_map_unmap },
{ "test_reprime", test_reprime },
{ "test_forked", test_forked },
+ { "test_correct_cpu_write", test_correct_cpu_write },
+ { "test_forked_cpu_write", test_forked_cpu_write },
{ "test_refcounting", test_refcounting },
{ "test_dup", test_dup },
{ "test_errors", test_errors },
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] prime_mmap: Add new test for calling mmap() on dma-buf fds
From: Rob Bradford
This test has the following subtests:
- test_correct for correctness of the data
- test_map_unmap checks for mapping idempotency
- test_reprime checks for dma-buf creation idempotency
- test_forked checks for multiprocess access
- test_refcounting checks for buffer reference counting
- test_dup chats that dup()ing the fd works
- test_errors checks the error return values for failures
- test_aperture_limit tests multiple buffer creation at the gtt aperture
limit
Signed-off-by: Rob Bradford
Signed-off-by: Tiago Vignatti
---
tests/Makefile.sources | 1 +
tests/prime_mmap.c | 383 +
2 files changed, 384 insertions(+)
create mode 100644 tests/prime_mmap.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index c94714b..5b2072e 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -90,6 +90,7 @@ TESTS_progs_M = \
pm_rps \
pm_rc6_residency \
pm_sseu \
+ prime_mmap \
prime_self_import \
template \
$(NULL)
diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
new file mode 100644
index 000..4dc2055
--- /dev/null
+++ b/tests/prime_mmap.c
@@ -0,0 +1,383 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Rob Bradford
+ *
+ */
+
+/*
+ * Testcase: Check whether mmap()ing dma-buf works
+ */
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drm.h"
+#include "i915_drm.h"
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "ioctl_wrappers.h"
+
+#define BO_SIZE (16*1024)
+
+static int fd;
+
+char pattern[] = {0xff, 0x00, 0x00, 0x00,
+ 0x00, 0xff, 0x00, 0x00,
+ 0x00, 0x00, 0xff, 0x00,
+ 0x00, 0x00, 0x00, 0xff};
+
+static void
+fill_bo(uint32_t handle, size_t size)
+{
+ off_t i;
+ for (i = 0; i < size; i+=sizeof(pattern))
+ {
+ gem_write(fd, handle, i, pattern, sizeof(pattern));
+ }
+}
+
+static int
+pattern_check(char *ptr, size_t size)
+{
+ off_t i;
+ for (i = 0; i < size; i+=sizeof(pattern))
+ {
+ if (memcmp(ptr, pattern, sizeof(pattern)) != 0)
+ return 1;
+ }
+
+ return 0;
+}
+
+static void
+test_correct(void)
+{
+ int dma_buf_fd;
+ char *ptr1, *ptr2;
+ uint32_t handle;
+
+ handle = gem_create(fd, BO_SIZE);
+ fill_bo(handle, BO_SIZE);
+
+ dma_buf_fd = prime_handle_to_fd(fd, handle);
+ igt_assert(errno == 0);
+
+ /* Check correctness vs GEM_MMAP_GTT */
+ ptr1 = gem_mmap(fd, handle, BO_SIZE, PROT_READ | PROT_WRITE);
+ ptr2 = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
+ igt_assert(ptr1 != MAP_FAILED);
+ igt_assert(ptr2 != MAP_FAILED);
+ igt_assert(memcmp(ptr1, ptr2, BO_SIZE) == 0);
+
+ /* Check pattern correctness */
+ igt_assert(pattern_check(ptr2, BO_SIZE) == 0);
+
+ munmap(ptr1, BO_SIZE);
+ munmap(ptr2, BO_SIZE);
+ close(dma_buf_fd);
+ gem_close(fd, handle);
+}
+
+static void
+test_map_unmap(void)
+{
+ int dma_buf_fd;
+ char *ptr;
+ uint32_t handle;
+
+ handle = gem_create(fd, BO_SIZE);
+ fill_bo(handle, BO_SIZE);
+
+ dma_buf_fd = prime_handle_to_fd(fd, handle);
+ igt_assert(errno == 0);
+
+ ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+ igt_assert(pattern_check(ptr, BO_SIZE) == 0);
+
+ /* Unmap and remap */
+ munmap(ptr, BO_SIZE);
+ ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+ igt_assert(pattern_check(ptr, BO_SIZE) == 0);
+
+ munmap(ptr, BO_SIZE);
+ close(dma_buf_fd);
+
[Intel-gfx] [PATCH 1/4] drm: prime: Honour O_RDWR during prime-handle-to-fd
From: Daniel Thompson
Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.
It is trivial to relax the restriction and permit read/write access.
This is safe because the flags are seldom touched by drm; mostly they
are passed verbatim to dma_buf calls.
v3 (Tiago): removed unused flags variable from drm_prime_handle_to_fd_ioctl.
Signed-off-by: Daniel Thompson
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/drm_prime.c | 10 +++---
include/uapi/drm/drm.h | 1 +
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 27aa718..df6cdc7 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -329,7 +329,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
* drm_gem_prime_export - helper library implementation of the export callback
* @dev: drm_device to export from
* @obj: GEM object to export
- * @flags: flags like DRM_CLOEXEC
+ * @flags: flags like DRM_CLOEXEC and DRM_RDWR
*
* This is the implementation of the gem_prime_export functions for GEM drivers
* using the PRIME helpers.
@@ -628,7 +628,6 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_priv)
{
struct drm_prime_handle *args = data;
- uint32_t flags;
if (!drm_core_check_feature(dev, DRIVER_PRIME))
return -EINVAL;
@@ -637,14 +636,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
return -ENOSYS;
/* check flags are valid */
- if (args->flags & ~DRM_CLOEXEC)
+ if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR))
return -EINVAL;
- /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
- flags = args->flags & DRM_CLOEXEC;
-
return dev->driver->prime_handle_to_fd(dev, file_priv,
- args->handle, flags, &args->fd);
+ args->handle, args->flags, &args->fd);
}
int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..ad8223e 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -668,6 +668,7 @@ struct drm_set_client_cap {
__u64 value;
};
+#define DRM_RDWR O_RDWR
#define DRM_CLOEXEC O_CLOEXEC
struct drm_prime_handle {
__u32 handle;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] prime_mmap: Fix a few misc stuff
- Remove pattern_check(), which was walking through a useless iterator
- Remove superfluous PROT_WRITE from gem_mmap, in test_correct()
- Add binary file to .gitignore
Signed-off-by: Tiago Vignatti
---
tests/.gitignore | 1 +
tests/prime_mmap.c | 37 -
2 files changed, 13 insertions(+), 25 deletions(-)
diff --git a/tests/.gitignore b/tests/.gitignore
index 0af0899..5bc4a58 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -163,6 +163,7 @@ pm_sseu
prime_nv_api
prime_nv_pcopy
prime_nv_test
+prime_mmap
prime_self_import
prime_udl
template
diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
index 4dc2055..dc59e8f 100644
--- a/tests/prime_mmap.c
+++ b/tests/prime_mmap.c
@@ -65,19 +65,6 @@ fill_bo(uint32_t handle, size_t size)
}
}
-static int
-pattern_check(char *ptr, size_t size)
-{
- off_t i;
- for (i = 0; i < size; i+=sizeof(pattern))
- {
- if (memcmp(ptr, pattern, sizeof(pattern)) != 0)
- return 1;
- }
-
- return 0;
-}
-
static void
test_correct(void)
{
@@ -92,14 +79,14 @@ test_correct(void)
igt_assert(errno == 0);
/* Check correctness vs GEM_MMAP_GTT */
- ptr1 = gem_mmap(fd, handle, BO_SIZE, PROT_READ | PROT_WRITE);
+ ptr1 = gem_mmap(fd, handle, BO_SIZE, PROT_READ);
ptr2 = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
igt_assert(ptr1 != MAP_FAILED);
igt_assert(ptr2 != MAP_FAILED);
igt_assert(memcmp(ptr1, ptr2, BO_SIZE) == 0);
/* Check pattern correctness */
- igt_assert(pattern_check(ptr2, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr2, pattern, sizeof(pattern)) == 0);
munmap(ptr1, BO_SIZE);
munmap(ptr2, BO_SIZE);
@@ -122,13 +109,13 @@ test_map_unmap(void)
ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
igt_assert(ptr != MAP_FAILED);
- igt_assert(pattern_check(ptr, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
/* Unmap and remap */
munmap(ptr, BO_SIZE);
ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
igt_assert(ptr != MAP_FAILED);
- igt_assert(pattern_check(ptr, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
munmap(ptr, BO_SIZE);
close(dma_buf_fd);
@@ -151,16 +138,16 @@ test_reprime(void)
ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
igt_assert(ptr != MAP_FAILED);
- igt_assert(pattern_check(ptr, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
close (dma_buf_fd);
- igt_assert(pattern_check(ptr, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
munmap(ptr, BO_SIZE);
dma_buf_fd = prime_handle_to_fd(fd, handle);
ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
igt_assert(ptr != MAP_FAILED);
- igt_assert(pattern_check(ptr, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
munmap(ptr, BO_SIZE);
close(dma_buf_fd);
@@ -184,7 +171,7 @@ test_forked(void)
igt_fork(childno, 1) {
ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
igt_assert(ptr != MAP_FAILED);
- igt_assert(pattern_check(ptr, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
munmap(ptr, BO_SIZE);
close(dma_buf_fd);
}
@@ -210,7 +197,7 @@ test_refcounting(void)
ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
igt_assert(ptr != MAP_FAILED);
- igt_assert(pattern_check(ptr, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
munmap(ptr, BO_SIZE);
close (dma_buf_fd);
}
@@ -231,7 +218,7 @@ test_dup(void)
ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
igt_assert(ptr != MAP_FAILED);
- igt_assert(pattern_check(ptr, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
munmap(ptr, BO_SIZE);
gem_close(fd, handle);
close (dma_buf_fd);
@@ -310,7 +297,7 @@ test_aperture_limit(void)
igt_assert(errno == 0);
ptr1 = mmap(NULL, size1, PROT_READ, MAP_SHARED, dma_buf_fd1, 0);
igt_assert(ptr1 != MAP_FAILED);
- igt_assert(pattern_check(ptr1, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr1, pattern, sizeof(pattern)) == 0);
handle2 = gem_create(fd, size1);
fill_bo(handle2, BO_SIZE);
@@ -318,7 +305,7 @@ test_aperture_limit(void)
igt_assert(errno == 0);
ptr2 = mmap(NULL, size2, PROT_READ, MAP_SHARED, dma_buf_fd2, 0);
igt_assert(ptr2 != MAP_FAILED);
- igt_assert(pattern_check(ptr2, BO_SIZE) == 0);
+ igt_assert(memcmp(ptr2, pattern, sizeof(patte
[Intel-gfx] [PATCH 3/4] drm/i915: Implement end_cpu_access
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index e9c2bfd..8447ba4 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -212,6 +212,15 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, size_t start, size
return ret;
}
+static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, size_t start,
size_t length, enum dma_data_direction direction)
+{
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
+ bool write = (direction == DMA_BIDIRECTIONAL || direction ==
DMA_TO_DEVICE);
+
+ if (i915_gem_object_set_to_gtt_domain(obj, write))
+ DRM_ERROR("failed to set bo into the GTT\n");
+}
+
static const struct dma_buf_ops i915_dmabuf_ops = {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
@@ -224,6 +233,7 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
.vmap = i915_gem_dmabuf_vmap,
.vunmap = i915_gem_dmabuf_vunmap,
.begin_cpu_access = i915_gem_begin_cpu_access,
+ .end_cpu_access = i915_gem_end_cpu_access,
};
struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Use CPU mapping for userspace dma-buf mmap()
Userspace is the one in charge of flush CPU by wrapping mmap with
begin{,end}_cpu_access.
v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix return
before transferring ownership when mmap fails.
v3: Fix return values.
v4: !obj->base.filp is user triggerable, so removed the WARN_ON.
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 8447ba4..ecd00d6 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -193,7 +193,23 @@ static void i915_gem_dmabuf_kunmap(struct dma_buf
*dma_buf, unsigned long page_n
static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct
*vma)
{
- return -EINVAL;
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
+ int ret;
+
+ if (obj->base.size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ if (!obj->base.filp)
+ return -ENODEV;
+
+ ret = obj->base.filp->f_op->mmap(obj->base.filp, vma);
+ if (ret)
+ return ret;
+
+ fput(vma->vm_file);
+ vma->vm_file = get_file(obj->base.filp);
+
+ return 0;
}
static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, size_t start,
size_t length, enum dma_data_direction direction)
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] lib: Add gem_userptr helpers
This patch moves userptr definitions and helpers implementation that were
locally in gem_userptr_benchmark and gem_userptr_blits to the library, so other
tests can make use of them as well. There's no functional changes.
Signed-off-by: Tiago Vignatti
---
benchmarks/gem_userptr_benchmark.c | 45 +++
lib/ioctl_wrappers.c | 30 +
lib/ioctl_wrappers.h | 13 ++
tests/gem_userptr_blits.c | 92 +++---
4 files changed, 73 insertions(+), 107 deletions(-)
diff --git a/benchmarks/gem_userptr_benchmark.c
b/benchmarks/gem_userptr_benchmark.c
index b804fdd..e0797dc 100644
--- a/benchmarks/gem_userptr_benchmark.c
+++ b/benchmarks/gem_userptr_benchmark.c
@@ -58,17 +58,6 @@
#define PAGE_SIZE 4096
#endif
-#define LOCAL_I915_GEM_USERPTR 0x33
-#define LOCAL_IOCTL_I915_GEM_USERPTR DRM_IOWR (DRM_COMMAND_BASE +
LOCAL_I915_GEM_USERPTR, struct local_i915_gem_userptr)
-struct local_i915_gem_userptr {
- uint64_t user_ptr;
- uint64_t user_size;
- uint32_t flags;
-#define LOCAL_I915_USERPTR_READ_ONLY (1<<0)
-#define LOCAL_I915_USERPTR_UNSYNCHRONIZED (1<<31)
- uint32_t handle;
-};
-
static uint32_t userptr_flags = LOCAL_I915_USERPTR_UNSYNCHRONIZED;
#define BO_SIZE (65536)
@@ -83,30 +72,6 @@ static void gem_userptr_test_synchronized(void)
userptr_flags = 0;
}
-static int gem_userptr(int fd, void *ptr, int size, int read_only, uint32_t
*handle)
-{
- struct local_i915_gem_userptr userptr;
- int ret;
-
- userptr.user_ptr = (uintptr_t)ptr;
- userptr.user_size = size;
- userptr.flags = userptr_flags;
- if (read_only)
- userptr.flags |= LOCAL_I915_USERPTR_READ_ONLY;
-
- ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_USERPTR, &userptr);
- if (ret)
- ret = errno;
- igt_skip_on_f(ret == ENODEV &&
- (userptr_flags & LOCAL_I915_USERPTR_UNSYNCHRONIZED) == 0
&&
- !read_only,
- "Skipping, synchronized mappings with no kernel
CONFIG_MMU_NOTIFIER?");
- if (ret == 0)
- *handle = userptr.handle;
-
- return ret;
-}
-
static void **handle_ptr_map;
static unsigned int num_handle_ptr_map;
@@ -144,7 +109,7 @@ static uint32_t create_userptr_bo(int fd, int size)
ret = posix_memalign(&ptr, PAGE_SIZE, size);
igt_assert(ret == 0);
- ret = gem_userptr(fd, (uint32_t *)ptr, size, 0, &handle);
+ ret = gem_userptr(fd, (uint32_t *)ptr, size, 0, userptr_flags, &handle);
igt_assert(ret == 0);
add_handle_ptr(handle, ptr);
@@ -167,7 +132,7 @@ static int has_userptr(int fd)
assert(posix_memalign(&ptr, PAGE_SIZE, PAGE_SIZE) == 0);
oldflags = userptr_flags;
gem_userptr_test_unsynchronized();
- ret = gem_userptr(fd, ptr, PAGE_SIZE, 0, &handle);
+ ret = gem_userptr(fd, ptr, PAGE_SIZE, 0, userptr_flags, &handle);
userptr_flags = oldflags;
if (ret != 0) {
free(ptr);
@@ -379,7 +344,7 @@ static void test_impact_overlap(int fd, const char *prefix)
for (i = 0, p = block; i < nr_bos[subtest];
i++, p += PAGE_SIZE)
- ret = gem_userptr(fd, (uint32_t *)p, BO_SIZE, 0,
+ ret = gem_userptr(fd, (uint32_t *)p, BO_SIZE,
0, userptr_flags,
&handles[i]);
igt_assert(ret == 0);
}
@@ -439,7 +404,7 @@ static void test_single(int fd)
start_test(test_duration_sec);
while (run_test) {
- ret = gem_userptr(fd, bo_ptr, BO_SIZE, 0, &handle);
+ ret = gem_userptr(fd, bo_ptr, BO_SIZE, 0, userptr_flags,
&handle);
assert(ret == 0);
gem_close(fd, handle);
iter++;
@@ -480,7 +445,7 @@ static void test_multiple(int fd, unsigned int batch, int
random)
for (i = 0; i < batch; i++) {
ret = gem_userptr(fd, bo_ptr + map[i] * BO_SIZE,
BO_SIZE,
- 0, &handles[i]);
+ 0, userptr_flags, &handles[i]);
assert(ret == 0);
}
if (random)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 941fa66..5152647 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -742,6 +742,36 @@ void gem_context_require_ban_period(int fd)
igt_require(has_ban_period);
}
+int gem_userptr(int fd, void *ptr, int size, int read_only, uint32_t flags,
uint32_t *handle)
+{
+ struct local_i915_gem_userptr userptr;
+ int ret;
+
+ memset(&userptr, 0, sizeof(userptr));
+ userptr.user_ptr = (uintptr_t)ptr;
+ userptr.user_size = size;
+
[Intel-gfx] [PATCH 5/7] prime_mmap: Test for userptr mmap
A userptr doesn't have the obj->base.filp, but can be exported via dma-buf, so
make sure it fails when mmaping.
Signed-off-by: Tiago Vignatti
---
In machine, export the handle to fd is actually returning error and falling
before the actual test happens. Same issue happens in gem_userptr_blits's
test_dmabuf(). This patch needs to be tested properly therefore.
tests/prime_mmap.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
index ad91371..fd6d13b 100644
--- a/tests/prime_mmap.c
+++ b/tests/prime_mmap.c
@@ -299,12 +299,47 @@ static int prime_handle_to_fd_no_assert(uint32_t handle,
int *fd_out)
args.fd = -1;
ret = drmIoctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args);
-
+ if (ret)
+ ret = errno;
*fd_out = args.fd;
return ret;
}
+/* test for mmap(dma_buf_export(userptr)) */
+static void
+test_userptr(void)
+{
+ int ret, dma_buf_fd;
+ void *ptr;
+ uint32_t handle;
+
+ /* create userptr bo */
+ ret = posix_memalign(&ptr, 4096, BO_SIZE);
+ igt_assert_eq(ret, 0);
+
+ ret = gem_userptr(fd, (uint32_t *)ptr, BO_SIZE, 0,
LOCAL_I915_USERPTR_UNSYNCHRONIZED, &handle);
+ igt_assert_eq(ret, 0);
+
+ /* export userptr */
+ ret = prime_handle_to_fd_no_assert(handle, &dma_buf_fd);
+ if (ret) {
+ igt_assert(ret == EINVAL || ret == ENODEV);
+ goto free_userptr;
+ } else {
+ igt_assert_eq(ret, 0);
+ igt_assert_lte(0, dma_buf_fd);
+ }
+
+ /* a userptr doesn't have the obj->base.filp, but can be exported via
+* dma-buf, so make sure it fails here */
+ ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
+ igt_assert(ptr == MAP_FAILED && errno == ENODEV);
+free_userptr:
+ gem_close(fd, handle);
+ close(dma_buf_fd);
+}
+
static void
test_errors(void)
{
@@ -413,6 +448,7 @@ igt_main
{ "test_forked_cpu_write", test_forked_cpu_write },
{ "test_refcounting", test_refcounting },
{ "test_dup", test_dup },
+ { "test_userptr", test_userptr },
{ "test_errors", test_errors },
{ "test_aperture_limit", test_aperture_limit },
};
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] dma-buf: Add ioctls to allow userspace to flush
From: Daniel Vetter
The userspace might need some sort of cache coherency management e.g. when CPU
and GPU domains are being accessed through dma-buf at the same time. To
circumvent this problem there are begin/end coherency markers, that forward
directly to existing dma-buf device drivers vfunc hooks. Userspace can make use
of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence would be
used like following:
- mmap dma-buf fd
- for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write
to mmap area 3. SYNC_END ioctl. This can be repeated as often as you
want (with the new data being consumed by the GPU or say scanout device)
- munamp once you don't need the buffer any more
v2 (Tiago): Fix header file type names (u64 -> __u64)
v3 (Tiago): Add documentation. Use enum dma_buf_sync_flags to the begin/end
dma-buf functions. Check for overflows in start/length.
Cc: Sumit Semwal
Signed-off-by: Daniel Vetter
Signed-off-by: Tiago Vignatti
---
Documentation/dma-buf-sharing.txt | 12 ++
drivers/dma-buf/dma-buf.c | 50 +++
include/uapi/linux/dma-buf.h | 43 +
3 files changed, 105 insertions(+)
create mode 100644 include/uapi/linux/dma-buf.h
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 480c8de..2d8ee3b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -355,6 +355,18 @@ Being able to mmap an export dma-buf buffer object has 2
main use-cases:
No special interfaces, userspace simply calls mmap on the dma-buf fd.
+ Also, the userspace might need some sort of cache coherency management e.g.
+ when CPU and GPU domains are being accessed through dma-buf at the same
+ time. To circumvent this problem there are begin/end coherency markers, that
+ forward directly to existing dma-buf device drivers vfunc hooks. Userspace
+ can make use of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The
+ sequence would be used like following:
+ - mmap dma-buf fd
+ - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write
+ to mmap area 3. SYNC_END ioctl. This can be repeated as often as you
+ want (with the new data being consumed by the GPU or say scanout device)
+ - munamp once you don't need the buffer any more
+
2. Supporting existing mmap interfaces in importers
Similar to the motivation for kernel cpu access it is again important that
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 155c146..e628415 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -34,6 +34,8 @@
#include
#include
+#include
+
static inline int is_dma_buf_file(struct file *);
struct dma_buf_list {
@@ -251,11 +253,59 @@ out:
return events;
}
+static long dma_buf_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ struct dma_buf *dmabuf;
+ struct dma_buf_sync sync;
+ enum dma_data_direction direction;
+
+ dmabuf = file->private_data;
+
+ if (!is_dma_buf_file(file))
+ return -EINVAL;
+
+ switch (cmd) {
+ case DMA_BUF_IOCTL_SYNC:
+ if (copy_from_user(&sync, (void __user *) arg, sizeof(sync)))
+ return -EFAULT;
+
+ if (sync.flags & DMA_BUF_SYNC_RW)
+ direction = DMA_BIDIRECTIONAL;
+ else if (sync.flags & DMA_BUF_SYNC_READ)
+ direction = DMA_FROM_DEVICE;
+ else if (sync.flags & DMA_BUF_SYNC_WRITE)
+ direction = DMA_TO_DEVICE;
+ else
+ return -EINVAL;
+
+ if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
+ return -EINVAL;
+
+ /* check for overflowing the buffer's size */
+ if (sync.start > dmabuf->size ||
+ sync.length > dmabuf->size - sync.start)
+ return -EINVAL;
+
+ if (sync.flags & DMA_BUF_SYNC_END)
+ dma_buf_end_cpu_access(dmabuf, sync.start,
+ sync.length, direction);
+ else
+ dma_buf_begin_cpu_access(dmabuf, sync.start,
+sync.length, direction);
+
+ return 0;
+ default:
+ return -ENOTTY;
+ }
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
.poll = dma_buf_poll,
+ .unlocked_ioctl = dma_buf_ioctl,
};
/*
diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
new file mode 100644
index 000..902c9f6
--- /dev/null
+++ b/include/uapi/linux
[Intel-gfx] [PATCH v4] mmap on the dma-buf directly
Hi,
The idea is to create a GEM bo in one process and pass the prime handle of the
it to another process, which in turn uses the handle only to map and write.
This could be useful for Chrome OS architecture, where the Web content
("unpriviledged process") maps and CPU-draws a buffer, which was previously
allocated in the GPU process ("priviledged process").
In v2, I've added a patch that Daniel kindly drafted to allow the
unpriviledged process flush through a prime fd. In v3, I've fixed a few
concerns and then added end_cpu_access to i915. In v4, I fixed Sumit Semwal's
concerns about dma-duf documentation and the FIXME missing in that same patch,
and also removed WARN in i915 dma-buf mmap (pointed by Chris). PTAL.
Best Regards,
Tiago
Daniel Thompson (1):
drm: prime: Honour O_RDWR during prime-handle-to-fd
Daniel Vetter (1):
dma-buf: Add ioctls to allow userspace to flush
Tiago Vignatti (2):
drm/i915: Implement end_cpu_access
drm/i915: Use CPU mapping for userspace dma-buf mmap()
Documentation/dma-buf-sharing.txt | 12
drivers/dma-buf/dma-buf.c | 50 ++
drivers/gpu/drm/drm_prime.c| 10 ++-
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 28 ++-
include/uapi/drm/drm.h | 1 +
include/uapi/linux/dma-buf.h | 43 +
6 files changed, 136 insertions(+), 8 deletions(-)
create mode 100644 include/uapi/linux/dma-buf.h
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] lib/igt_draw: add support for RGB565 and XRGB2101010
We need to test those pixel formats on the FBC code, so let's make
sure the drawing library works on them first.
Signed-off-by: Paulo Zanoni
---
lib/igt_draw.c | 162 +++
lib/igt_draw.h | 2 +-
tests/kms_draw_crc.c | 113 +--
tests/kms_frontbuffer_tracking.c | 2 +-
4 files changed, 206 insertions(+), 73 deletions(-)
diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index 2210f77..afb937f 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -57,6 +57,7 @@ struct buf_data {
uint32_t handle;
uint32_t size;
uint32_t stride;
+ int bpp;
};
struct rect {
@@ -133,27 +134,27 @@ static int swizzle_addr(int addr, int swizzle)
/* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
* if you need to. */
-static int linear_x_y_to_tiled_pos(int x, int y, uint32_t stride, int swizzle)
+static int linear_x_y_to_tiled_pos(int x, int y, uint32_t stride, int swizzle,
+ int bpp)
{
int x_tile_size, y_tile_size;
int x_tile_n, y_tile_n, x_tile_off, y_tile_off;
int line_size, tile_size;
int tile_n, tile_off;
int tiled_pos, tiles_per_line;
- int bpp;
+ int pixel_size = bpp / 8;
line_size = stride;
x_tile_size = 512;
y_tile_size = 8;
tile_size = x_tile_size * y_tile_size;
tiles_per_line = line_size / x_tile_size;
- bpp = sizeof(uint32_t);
y_tile_n = y / y_tile_size;
y_tile_off = y % y_tile_size;
- x_tile_n = (x * bpp) / x_tile_size;
- x_tile_off = (x * bpp) % x_tile_size;
+ x_tile_n = (x * pixel_size) / x_tile_size;
+ x_tile_off = (x * pixel_size) % x_tile_size;
tile_n = y_tile_n * tiles_per_line + x_tile_n;
tile_off = y_tile_off * x_tile_size + x_tile_off;
@@ -161,19 +162,19 @@ static int linear_x_y_to_tiled_pos(int x, int y, uint32_t
stride, int swizzle)
tiled_pos = swizzle_addr(tiled_pos, swizzle);
- return tiled_pos / bpp;
+ return tiled_pos / pixel_size;
}
/* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
* if you need to. */
static void tiled_pos_to_x_y_linear(int tiled_pos, uint32_t stride,
- int swizzle, int *x, int *y)
+ int swizzle, int bpp, int *x, int *y)
{
int tile_n, tile_off, tiles_per_line, line_size;
int x_tile_off, y_tile_off;
int x_tile_n, y_tile_n;
int x_tile_size, y_tile_size, tile_size;
- int bpp;
+ int pixel_size = bpp / 8;
tiled_pos = swizzle_addr(tiled_pos, swizzle);
@@ -182,7 +183,6 @@ static void tiled_pos_to_x_y_linear(int tiled_pos, uint32_t
stride,
y_tile_size = 8;
tile_size = x_tile_size * y_tile_size;
tiles_per_line = line_size / x_tile_size;
- bpp = sizeof(uint32_t);
tile_n = tiled_pos / tile_size;
tile_off = tiled_pos % tile_size;
@@ -193,32 +193,45 @@ static void tiled_pos_to_x_y_linear(int tiled_pos,
uint32_t stride,
x_tile_n = tile_n % tiles_per_line;
y_tile_n = tile_n / tiles_per_line;
- *x = (x_tile_n * x_tile_size + x_tile_off) / bpp;
+ *x = (x_tile_n * x_tile_size + x_tile_off) / pixel_size;
*y = y_tile_n * y_tile_size + y_tile_off;
}
-static void draw_rect_ptr_linear(uint32_t *ptr, uint32_t stride,
- struct rect *rect, uint32_t color)
+static void set_pixel(void *_ptr, int index, uint32_t color, int bpp)
+{
+ if (bpp == 16) {
+ uint16_t *ptr = _ptr;
+ ptr[index] = color;
+ } else if (bpp == 32) {
+ uint32_t *ptr = _ptr;
+ ptr[index] = color;
+ } else {
+ igt_assert_f(false, "bpp: %d\n", bpp);
+ }
+}
+
+static void draw_rect_ptr_linear(void *ptr, uint32_t stride,
+struct rect *rect, uint32_t color, int bpp)
{
int x, y, line_begin;
for (y = rect->y; y < rect->y + rect->h; y++) {
- line_begin = y * stride / sizeof(uint32_t);
+ line_begin = y * stride / (bpp / 8);
for (x = rect->x; x < rect->x + rect->w; x++)
- ptr[line_begin + x] = color;
+ set_pixel(ptr, line_begin + x, color, bpp);
}
-
}
-static void draw_rect_ptr_tiled(uint32_t *ptr, uint32_t stride, int swizzle,
-struct rect *rect, uint32_t color)
+static void draw_rect_ptr_tiled(void *ptr, uint32_t stride, int swizzle,
+ struct rect *rect, uint32_t color, int bpp)
{
int x, y, pos;
for (y = rect->y; y < rect->y + rect->h; y++) {
for (x = rect->x; x < rect->x + rect->w; x++) {
- pos = linear_x_y_to_tiled_pos(x, y, stri
Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.
On 11.08.2015 10:05, Zhang, Xiong Y wrote: >> -Original Message- >> From: Vivi, Rodrigo >> Sent: Saturday, August 8, 2015 8:34 AM >> To: intel-gfx@lists.freedesktop.org >> Cc: Vivi, Rodrigo; Zhang, Xiong Y >> Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes. >> >> DDI-A and DDI-E shares the 4 lanes. So when DDI-E is present we need to >> configure lane count propperly for both. >> >> This was based on Sonika's >> [PATCH] drm/i915/skl: Select DDIA lane capability based upon vbt >> >> Credits-to: Sonika Jindal >> Cc: Xiong Zhang >> Signed-off-by: Rodrigo Vivi >> --- >> drivers/gpu/drm/i915/intel_ddi.c | 12 ++-- >> drivers/gpu/drm/i915/intel_dp.c | 8 +--- >> 2 files changed, 15 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c >> b/drivers/gpu/drm/i915/intel_ddi.c >> index 110d546..557cecf 100644 >> --- a/drivers/gpu/drm/i915/intel_ddi.c >> +++ b/drivers/gpu/drm/i915/intel_ddi.c >> @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct drm_device *dev, enum >> port port) >> struct intel_digital_port *intel_dig_port; >> struct intel_encoder *intel_encoder; >> struct drm_encoder *encoder; >> -bool init_hdmi, init_dp; >> +bool init_hdmi, init_dp, ddi_e_present; >> + >> +/* >> + * On SKL we don't have a way to detect DDI-E so we rely on VBT. >> + */ >> +ddie_present = IS_SKYLAKE(dev) && >> +(dev_priv->vbt.ddi_port_info[PORT_E].supports_dp || >> + dev_priv->vbt.ddi_port_info[PORT_E].supports_dvi || >> + dev_priv->vbt.ddi_port_info[PORT_E].supports_hdmi); > [Zhang, Xiong Y] ddie_present should be ddi_e_present >> >> init_hdmi = (dev_priv->vbt.ddi_port_info[port].supports_dvi || >> dev_priv->vbt.ddi_port_info[port].supports_hdmi); >> @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct drm_device *dev, enum >> port port) >> intel_dig_port->port = port; >> intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) & >>(DDI_BUF_PORT_REVERSAL | >> - DDI_A_4_LANES); >> + ddi_e_present ? 0 : DDI_A_4_LANES); > [Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes when DDI-E doesn't > exist, > I think your patch will do nothing. >> >> intel_encoder->type = INTEL_OUTPUT_UNKNOWN; >> intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2); diff --git >> a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index >> 3ff2080..7ada79e 100644 >> --- a/drivers/gpu/drm/i915/intel_dp.c >> +++ b/drivers/gpu/drm/i915/intel_dp.c >> @@ -159,9 +159,11 @@ static u8 intel_dp_max_lane_count(struct intel_dp >> *intel_dp) >> u8 source_max, sink_max; >> >> source_max = 4; >> -if (HAS_DDI(dev) && intel_dig_port->port == PORT_A && >> -(intel_dig_port->saved_port_bits & DDI_A_4_LANES) == 0) >> -source_max = 2; >> +if (HAS_DDI(dev) && (intel_dig_port->port == PORT_E || >> + (intel_dig_port->port == PORT_A && >> + (intel_dig_port->saved_port_bits & >> + DDI_A_4_LANES) == 0)) >> +source_max = 2; > [Zhang, Xiong Y] it miss ')' at the end line. >> >> sink_max = drm_dp_max_lane_count(intel_dp->dpcd); with these build fixes the series is Tested-by: Timo Aaltonen the VGA port on SKL-H SDP was functional after all.. (DP-to-VGA) -- t ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check idle to active before processing CSQ
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7109 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT 283/283 283/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type
On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
> > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek wrote:
> >> Hi,
> >>
> >> this my first build of a 4.2-rcN Linux-kernel and I see this...
> >>
> >
> > Just FYI:
> >
> > I am *not* seeing this with drm-intel-nightly from below url.
> >
> > Also, I plan to test Linux v4.2-rc5.
> >
>
> [ CC Linus ]
>
> Knock Knock Knock.
>
> This issue still remains here (with CONFIG_DRM_I915=m)...
>
> [ 18.269792] ==
> [ 18.269798] [ INFO: possible circular locking dependency detected ]
> [ 18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
> [ 18.269810] ---
> [ 18.269816] modprobe/727 is trying to acquire lock:
> [ 18.269822] (init_mutex){+.+.+.}, at: []
> acpi_video_get_backlight_type+0x17/0x164 [video]
> [ 18.269840]
> [ 18.269840] but task is already holding lock:
> [ 18.269848] (&(&backlight_notifier)->rwsem){..}, at:
> [] __blocking_notifier_call_chain+0x39/0x70
> [ 18.269864]
> [ 18.269864] which lock already depends on the new lock.
> [ 18.269864]
> [ 18.269875]
> [ 18.269875] the existing dependency chain (in reverse order) is:
> [ 18.269884]
> ...
>
> Full dmesg log and kernel-config attached.
>
> Shall I add Rusty and modules/modprobe folks?
Just got back from vacation and was greeted by this same lockdep splat.
On a hunch I reverted
commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
Author: Hans de Goede
Date: Tue Jun 16 16:27:52 2015 +0200
ACPI / video: Move backlight notifier to video_detect.c
and the problem seems to be gone. Hans, any thoughts?
>
> - Sedat -
>
> > - Sedat -
> >
> > [1]
> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
> > [2]
> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-994.201508010158_amd64.deb
> >
> >> [ 24.001043] [drm] Memory usable by graphics device = 2048M
> >> [ 24.001118] [drm] Replacing VGA console driver
> >> [ 24.011642] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> >> [ 24.011646] [drm] Driver supports precise vblank timestamp query.
> >> [ 24.012480] vgaarb: device changed decodes:
> >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> >> [ 24.028005]
> >> [ 24.028014] ==
> >> [ 24.028020] [ INFO: possible circular locking dependency detected ]
> >> [ 24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
> >> [ 24.028032] ---
> >> [ 24.028038] modprobe/740 is trying to acquire lock:
> >> [ 24.028043] (init_mutex){+.+.+.}, at: []
> >> acpi_video_get_backlight_type+0x17/0x164 [video]
> >> [ 24.028060]
> >> [ 24.028060] but task is already holding lock:
> >> [ 24.028068] (&(&backlight_notifier)->rwsem){..}, at:
> >> [] __blocking_notifier_call_chain+0x39/0x70
> >> [ 24.028083]
> >> [ 24.028083] which lock already depends on the new lock.
> >> [ 24.028083]
> >> [ 24.028095]
> >> [ 24.028095] the existing dependency chain (in reverse order) is:
> >> [ 24.028103]
> >> [ 24.028103] -> #1 (&(&backlight_notifier)->rwsem){..}:
> >> [ 24.028113][] lock_acquire+0xcf/0x280
> >> [ 24.028121][] down_write+0x49/0x80
> >> [ 24.028129][]
> >> blocking_notifier_chain_register+0x21/0xb0
> >> [ 24.028138][]
> >> backlight_register_notifier+0x18/0x20
> >> [ 24.028147][]
> >> acpi_video_get_backlight_type+0xfa/0x164 [video]
> >> [ 24.028158][] 0xa00a20e9
> >> [ 24.028164][] do_one_initcall+0x88/0x1c0
> >> [ 24.028172][] do_init_module+0x61/0x1ec
> >> [ 24.028179][] load_module+0x2008/0x25c0
> >> [ 24.028187][] SyS_init_module+0x126/0x140
> >> [ 24.028194][]
> >> entry_SYSCALL_64_fastpath+0x16/0x7a
> >> [ 24.028202]
> >> [ 24.028202] -> #0 (init_mutex){+.+.+.}:
> >> [ 24.028211][] __lock_acquire+0x1f5d/0x21c0
> >> [ 24.028218][] lock_acquire+0xcf/0x280
> >> [ 24.028225][] mutex_lock_nested+0x65/0x3c0
> >> [ 24.028233][]
> >> acpi_video_get_backlight_type+0x17/0x164 [video]
> >> [ 24.028243][]
> >> acpi_video_backlight_notify+0x19/0x2f [video]
> >> [ 24.028253][] notifier_call_chain+0x5d/0x80
> >> [ 24.028260][]
> >> __blocking_notifier_call_chain+0x51/0x70
> >> [ 24.028269][]
> >> blocking_notifier_call_chain+0x16/0x20
> >> [ 24.028278][]
> >> backlight_device_register+0x197/0x240
> >> [ 24.028286][]
> >> intel_backlight_register+0xb3/0x180 [i915]
> >> [ 24.028336][]
> >> intel_modeset_gem_init+0x176/0x190 [i915]
> >> [ 24.028371][] i915_driver_load+0xf12/0x14d0
> >> [i915]
> >> [ 24.02840
Re: [Intel-gfx] [PATCH v3 01/11] drm/i915: Store max dotclock
On Wed, Aug 12, 2015 at 08:30:23PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 31, 2015 at 03:13:50PM +0300, Mika Kahola wrote:
> > Store max dotclock into dev_priv structure so we are able
> > to filter out the modes that are not supported by our
> > platforms.
> >
> > V2:
> > - limit the max dot clock frequency to max CD clock frequency
> > for the gen9 and above
> > - limit the max dot clock frequency to 90% of the max CD clock
> > frequency for the older gens
> > - for Cherryview the max dot clock frequency is limited to 95%
> > of the max CD clock frequency
> > - for gen2 and gen3 the max dot clock limit is set to 90% of the
> > 2X max CD clock frequency
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_display.c | 19 +++
> > 2 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 04aa34a..1f69211b 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1777,6 +1777,7 @@ struct drm_i915_private {
> > unsigned int fsb_freq, mem_freq, is_ddr3;
> > unsigned int skl_boot_cdclk;
> > unsigned int cdclk_freq, max_cdclk_freq;
> > + unsigned int max_dotclk;
>
> nit: maybe max_dotclk_freq for extra consistentcy?
>
> > unsigned int hpll_freq;
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 43b0f17..c9c6d19 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5259,6 +5259,23 @@ static void modeset_update_crtc_power_domains(struct
> > drm_atomic_state *state)
> > modeset_put_power_domains(dev_priv, put_domains[i]);
> > }
> >
> > +static int intel_compute_max_dotclk(struct drm_i915_private *dev_priv)
> > +{
> > + int max_cdclk_freq = dev_priv->max_cdclk_freq;
> > + int max_dotclk_freq;
> > +
> > + if (INTEL_INFO(dev_priv)->gen >= 9)
> > + max_dotclk_freq = max_cdclk_freq;
> > + else if (IS_CHERRYVIEW(dev_priv))
> > + max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 95, 100);
> > + else if (INTEL_INFO(dev_priv)->gen == 2 || INTEL_INFO(dev_priv)->gen ==
> > 3)
>
> intel_crtc_compute_config() uses 'gen < 4' as the condition around the
> double_wide handling. Maybe do the same here for consistency.
>
> > + max_dotclk_freq = DIV_ROUND_UP(2 * max_cdclk_freq * 90, 100);
> > + else
> > + max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 90, 100);
>
> These should round down to match what we do in the calc_cdclk funcs.
>
> Also to add another bikeshed color, there's no need for the local
> max_dotclk_freq variable, you can just 'return ' from each
> branch.
>
> With at least the rounding fixed this can have
> Reviewed-by: Ville Syrjälä
>
> > +
> > + return max_dotclk_freq;
> > +}
> > +
> > static void intel_update_max_cdclk(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > @@ -5298,6 +5315,8 @@ static void intel_update_max_cdclk(struct drm_device
> > *dev)
> > dev_priv->max_cdclk_freq = dev_priv->cdclk_freq;
> > }
> >
> > + dev_priv->max_dotclk = intel_compute_max_dotclk(dev_priv);
> > +
> > DRM_DEBUG_DRIVER("Max CD clock rate: %d kHz\n",
> > dev_priv->max_cdclk_freq);
Oh and I think it would be nice to add a DRM_DEBUG_DRIVER for the
compute max_dotclk so that we'll have it handy in bug reports without
having to recompute it in ones head.
> > }
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
--
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 v3 07/11] drm/i915: CRT pixel clock check
On Fri, Jul 31, 2015 at 03:13:56PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot support the requested pixel clock.
>
> This patch applies to CRT.
>
> V2:
> - removed computation for max pixel clock
>
> V3:
> - cleanup by removing unnecessary lines
>
> Signed-off-by: Mika Kahola
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_crt.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 5d78c1f..40ded5f 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -290,6 +290,7 @@ intel_crt_mode_valid(struct drm_connector *connector,
>struct drm_display_mode *mode)
> {
> struct drm_device *dev = connector->dev;
> + int max_pixclk = to_i915(dev)->max_dotclk;
>
> int max_clock = 0;
> if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> @@ -305,6 +306,9 @@ intel_crt_mode_valid(struct drm_connector *connector,
> if (mode->clock > max_clock)
> return MODE_CLOCK_HIGH;
>
> + if (mode->clock > max_pixclk)
> + return MODE_CLOCK_HIGH;
> +
> /* The FDI receiver on LPT only supports 8bpc and only has 2 lanes. */
> if (HAS_PCH_LPT(dev) &&
> (ironlake_get_lanes_required(mode->clock, 27, 24) > 2))
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/11] drm/i915: DisplayPort pixel clock check
On Fri, Jul 31, 2015 at 03:13:51PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot support the requested pixel clock.
>
> This patch applies to DisplayPort.
>
> V2:
> - removed computation for max DOT clock
>
> V3:
> - cleanup by removing unnecessary lines
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_dp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 44f8a32..5faeadb 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -206,6 +206,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
> int target_clock = mode->clock;
> int max_rate, mode_rate, max_lanes, max_link_clock;
> + int max_pixclk = to_i915(connector->dev)->max_dotclk;
>
> if (is_edp(intel_dp) && fixed_mode) {
> if (mode->hdisplay > fixed_mode->hdisplay)
> @@ -223,7 +224,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
> max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> mode_rate = intel_dp_link_required(target_clock, 18);
>
> - if (mode_rate > max_rate)
> + if (mode_rate > max_rate || target_clock > max_pixclk)
> return MODE_CLOCK_HIGH;
This one ends up checking the fixed_mode clock every time, but I think I
already declared that to OK, so let's go with it.
Reviewed-by: Ville Syrjälä
> if (mode->clock < 1)
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 09/11] drm/i915: DisplayPort-MST pixel clock check
On Fri, Jul 31, 2015 at 03:13:58PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot support the requested pixel clock.
>
> This patch applies to DisplayPort MST.
>
> V2:
> - removed computation for max pixel clock
>
> V3:
> - cleanup by removing unnecessary lines
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_dp_mst.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 585f0a4..fcf03d0 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -347,6 +347,8 @@ static enum drm_mode_status
> intel_dp_mst_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> {
> + int max_pixclk = to_i915(connector->dev)->max_dotclk;
The pixclk vs. dotclk in every patch is tickling my ocd nerves. I'd say
pick one and stick to it everywhere. I guess I'm probably to blame here
since I've been using dotclock in the .get_config() paths, and pixclk
in the cdclk calculations. With grep I can't say which one is winning,
so I guess you could pick whichever seems more awesome.
Apart from that this patch looks good so:
Reviewed-by: Ville Syrjälä
> +
> /* TODO - validate mode against available PBN for link */
> if (mode->clock < 1)
> return MODE_CLOCK_LOW;
> @@ -354,6 +356,9 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> return MODE_H_ILLEGAL;
>
> + if (mode->clock > max_pixclk)
> + return MODE_CLOCK_HIGH;
> +
> return MODE_OK;
> }
>
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 10/11] drm/i915: DVO pixel clock check
On Fri, Jul 31, 2015 at 03:13:59PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot support the requested pixel clock.
>
> This patch applies to DVO.
>
> V2:
> - removed computation for max pixel clock
>
> V3:
> - cleanup by removing unnecessary lines
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_dvo.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c
> b/drivers/gpu/drm/i915/intel_dvo.c
> index fd5e522..2bfc51c 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -247,6 +247,7 @@ intel_dvo_mode_valid(struct drm_connector *connector,
>struct drm_display_mode *mode)
> {
> struct intel_dvo *intel_dvo = intel_attached_dvo(connector);
> + int max_pixclk = to_i915(connector->dev)->max_dotclk;
>
> if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> return MODE_NO_DBLESCAN;
> @@ -260,6 +261,9 @@ intel_dvo_mode_valid(struct drm_connector *connector,
> return MODE_PANEL;
> }
>
> + if (mode->clock > max_pixclk)
> + return MODE_CLOCK_HIGH;
I think we'd need to check against the fixed_mode like you did for DP,
when it's present that is.
> +
> return intel_dvo->dev.dev_ops->mode_valid(&intel_dvo->dev, mode);
> }
>
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 03/11] drm/i915: HDMI pixel clock check
On Fri, Jul 31, 2015 at 03:13:52PM +0300, Mika Kahola wrote: > It is possible the we request to have a mode that has > higher pixel clock than our HW can support. This patch > checks if requested pixel clock is lower than the one > supported by the HW. The requested mode is discarded > if we cannot support the requested pixel clock. > > This patch applies to HDMI. > > V2: > - removed computation for max dot clock > > V3: > - cleanup by removing unnecessary lines > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/intel_hdmi.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index 70bad5b..3149e5f 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1193,10 +1193,14 @@ intel_hdmi_mode_valid(struct drm_connector *connector, > struct drm_device *dev = intel_hdmi_to_dev(hdmi); > enum drm_mode_status status; > int clock; > + int max_pixclk = to_i915(connector->dev)->max_dotclk; > > if (mode->flags & DRM_MODE_FLAG_DBLSCAN) > return MODE_NO_DBLESCAN; > > + if (mode->clock > max_pixclk) > + return MODE_CLOCK_HIGH; > + > clock = mode->clock; I believe we should do something like this here: clock = mode->clock; if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == DRM_MODE_FLAG_3D_FRAME_PACKING) clock *= 2; if (clock > max_pixclk) return MODE_CLOCK_HIGH; > if (mode->flags & DRM_MODE_FLAG_DBLCLK) > clock *= 2; The stero handling should probably be in a separate patch, but in preparation for it you could already put the dotclk check between the clock= assigment and the DBCLK doubling (since DBLCLK only affects the port_clock and not pixel clock). > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 08/11] drm/i915: TV pixel clock check
On Fri, Jul 31, 2015 at 03:13:57PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot support the requested pixel clock.
>
> This patch applies to TV.
>
> V2:
> - removed computation for max pixel clock
>
> V3:
> - cleanup by removing unnecessary lines
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_tv.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 8b9d325..beeed25 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -897,6 +897,10 @@ intel_tv_mode_valid(struct drm_connector *connector,
> {
> struct intel_tv *intel_tv = intel_attached_tv(connector);
> const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
> + int max_pixclk = to_i915(connector->dev)->max_dotclk;
> +
> + if (mode->clock > max_pixclk)
> + return MODE_CLOCK_HIGH;
The mode handling in intel_tv.c seems to be a mess. But I suppose this
should be OK.
Reviewed-by: Ville Syrjälä
>
> /* Ensure TV refresh is close to desired refresh */
> if (tv_mode && abs(tv_mode->refresh - drm_mode_vrefresh(mode) * 1000)
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 06/11] drm/i915: DSI pixel clock check
On Fri, Jul 31, 2015 at 03:13:55PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot support the requested pixel clock.
>
> This patch applies to DSI.
>
> V2:
> - removed computation for max pixel clock
>
> V3:
> - cleanup by removing unnecessary lines
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 18dd7d7..3def6f9 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -654,6 +654,7 @@ intel_dsi_mode_valid(struct drm_connector *connector,
> {
> struct intel_connector *intel_connector = to_intel_connector(connector);
> struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
> + int max_pixclk = to_i915(connector->dev)->max_dotclk;
>
> DRM_DEBUG_KMS("\n");
>
> @@ -669,6 +670,9 @@ intel_dsi_mode_valid(struct drm_connector *connector,
> return MODE_PANEL;
> }
>
> + if (mode->clock > max_pixclk)
> + return MODE_CLOCK_HIGH;
> +
Hmm. Seems like this too ought to be checking the fixed_mode.
intel_dsi_mode_valid() seems to assume there could be no fixed mode,
but looking at intel_dsi_init() tells me that can't be (if we ignore the
totally broken looking error handling).
Also we don't set up the panel fitter in the DSI code even though the
presence of fixed_mode clearly indicates that we should. So the whole
thing seems more or less busted.
For now, I think just sticking the clock check inside the 'if (fixed_mode)'
block would be fine, and then someone can try to clean up the bigger
mess.
> return MODE_OK;
> }
>
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 05/11] drm/i915: SDVO pixel clock check
On Fri, Jul 31, 2015 at 03:13:54PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot support the requested pixel clock.
>
> This patch applies to SDVO.
>
> V2:
> - removed computation for max pixel clock
>
> V3:
> - cleanup by removing unnecessary lines
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_sdvo.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 2c435a7..55a2853 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -1560,6 +1560,7 @@ intel_sdvo_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> {
> struct intel_sdvo *intel_sdvo = intel_attached_sdvo(connector);
> + int max_pixclk = to_i915(connector->dev)->max_dotclk;
>
> if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> return MODE_NO_DBLESCAN;
> @@ -1570,6 +1571,9 @@ intel_sdvo_mode_valid(struct drm_connector *connector,
> if (intel_sdvo->pixel_clock_max < mode->clock)
> return MODE_CLOCK_HIGH;
>
> + if (mode->clock > max_pixclk)
> + return MODE_CLOCK_HIGH;
> +
Had to think a bit on this one. But yeah checking mode->clock is the
right thing. I suppose in theory we should do the whole
intel_sdvo_get_preferred_input_mode() thing here, but I guess that would
clobber the current sdvo device state and so can't be done safely.
Reviewed-by: Ville Syrjälä
> if (intel_sdvo->is_lvds) {
> if (mode->hdisplay > intel_sdvo->sdvo_lvds_fixed_mode->hdisplay)
> return MODE_PANEL;
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/11] drm/i915: LVDS pixel clock check
On Fri, Jul 31, 2015 at 03:13:53PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot support the requested pixel clock.
>
> This patch applies to LVDS.
>
> V2:
> - removed computation for max pixel clock
>
> V3:
> - cleanup by removing unnecessary lines
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_lvds.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index cb634f4..59213f9 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -289,11 +289,14 @@ intel_lvds_mode_valid(struct drm_connector *connector,
> {
> struct intel_connector *intel_connector = to_intel_connector(connector);
> struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
> + int max_pixclk = to_i915(connector->dev)->max_dotclk;
>
> if (mode->hdisplay > fixed_mode->hdisplay)
> return MODE_PANEL;
> if (mode->vdisplay > fixed_mode->vdisplay)
> return MODE_PANEL;
> + if (mode->clock > max_pixclk)
> + return MODE_CLOCK_HIGH;
This should really be checking fixed_mode->clock. Though checking it
every time is a bit pointless since it never changes. But what the eDP
cases ends up doing as well.
Maybe we should just stick the check to where we pick fixed_mode, or
perhaps just have intel_panel_init() print an error if the provided
modes(s) are no good? In theory that should never happen anyway.
>
> return MODE_OK;
> }
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Spam less on dp aux send/receive problems
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7106 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -1 283/283 282/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 01/11] drm/i915: Store max dotclock
On Fri, Jul 31, 2015 at 03:13:50PM +0300, Mika Kahola wrote:
> Store max dotclock into dev_priv structure so we are able
> to filter out the modes that are not supported by our
> platforms.
>
> V2:
> - limit the max dot clock frequency to max CD clock frequency
> for the gen9 and above
> - limit the max dot clock frequency to 90% of the max CD clock
> frequency for the older gens
> - for Cherryview the max dot clock frequency is limited to 95%
> of the max CD clock frequency
> - for gen2 and gen3 the max dot clock limit is set to 90% of the
> 2X max CD clock frequency
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 19 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 04aa34a..1f69211b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1777,6 +1777,7 @@ struct drm_i915_private {
> unsigned int fsb_freq, mem_freq, is_ddr3;
> unsigned int skl_boot_cdclk;
> unsigned int cdclk_freq, max_cdclk_freq;
> + unsigned int max_dotclk;
nit: maybe max_dotclk_freq for extra consistentcy?
> unsigned int hpll_freq;
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 43b0f17..c9c6d19 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5259,6 +5259,23 @@ static void modeset_update_crtc_power_domains(struct
> drm_atomic_state *state)
> modeset_put_power_domains(dev_priv, put_domains[i]);
> }
>
> +static int intel_compute_max_dotclk(struct drm_i915_private *dev_priv)
> +{
> + int max_cdclk_freq = dev_priv->max_cdclk_freq;
> + int max_dotclk_freq;
> +
> + if (INTEL_INFO(dev_priv)->gen >= 9)
> + max_dotclk_freq = max_cdclk_freq;
> + else if (IS_CHERRYVIEW(dev_priv))
> + max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 95, 100);
> + else if (INTEL_INFO(dev_priv)->gen == 2 || INTEL_INFO(dev_priv)->gen ==
> 3)
intel_crtc_compute_config() uses 'gen < 4' as the condition around the
double_wide handling. Maybe do the same here for consistency.
> + max_dotclk_freq = DIV_ROUND_UP(2 * max_cdclk_freq * 90, 100);
> + else
> + max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 90, 100);
These should round down to match what we do in the calc_cdclk funcs.
Also to add another bikeshed color, there's no need for the local
max_dotclk_freq variable, you can just 'return ' from each
branch.
With at least the rounding fixed this can have
Reviewed-by: Ville Syrjälä
> +
> + return max_dotclk_freq;
> +}
> +
> static void intel_update_max_cdclk(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -5298,6 +5315,8 @@ static void intel_update_max_cdclk(struct drm_device
> *dev)
> dev_priv->max_cdclk_freq = dev_priv->cdclk_freq;
> }
>
> + dev_priv->max_dotclk = intel_compute_max_dotclk(dev_priv);
> +
> DRM_DEBUG_DRIVER("Max CD clock rate: %d kHz\n",
>dev_priv->max_cdclk_freq);
> }
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.
On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote: > > On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote: > > > > -Original Message- > > > > From: Vivi, Rodrigo > > > > Sent: Saturday, August 8, 2015 8:34 AM > > > > To: intel-gfx@lists.freedesktop.org > > > > Cc: Vivi, Rodrigo; Zhang, Xiong Y > > > > Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 > > > > lanes. > > > > > > > > DDI-A and DDI-E shares the 4 lanes. So when DDI-E is present we > > > > need > > > > to configure lane count propperly for both. > > > > > > > > This was based on Sonika's > > > > [PATCH] drm/i915/skl: Select DDIA lane capability based upon > > > > vbt > > > > > > > > Credits-to: Sonika Jindal > > > > Cc: Xiong Zhang > > > > Signed-off-by: Rodrigo Vivi > > > > --- > > > > drivers/gpu/drm/i915/intel_ddi.c | 12 ++-- > > > > drivers/gpu/drm/i915/intel_dp.c | 8 +--- > > > > 2 files changed, 15 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > > > > b/drivers/gpu/drm/i915/intel_ddi.c > > > > index 110d546..557cecf 100644 > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c > > > > @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct drm_device > > > > *dev, > > > > enum port port) > > > > struct intel_digital_port *intel_dig_port; > > > > struct intel_encoder *intel_encoder; > > > > struct drm_encoder *encoder; > > > > - bool init_hdmi, init_dp; > > > > + bool init_hdmi, init_dp, ddi_e_present; > > > > + > > > > + /* > > > > +* On SKL we don't have a way to detect DDI-E so we > > > > rely > > > > on VBT. > > > > +*/ > > > > + ddie_present = IS_SKYLAKE(dev) && > > > > + (dev_priv > > > > ->vbt.ddi_port_info[PORT_E].supports_dp > > > > > > > > > > +dev_priv > > > > ->vbt.ddi_port_info[PORT_E].supports_dvi > > > > > > > > > > +dev_priv > > > > ->vbt.ddi_port_info[PORT_E].supports_hdmi); > > > [Zhang, Xiong Y] ddie_present should be ddi_e_present > > > > > > > > init_hdmi = (dev_priv > > > > ->vbt.ddi_port_info[port].supports_dvi || > > > > dev_priv > > > > ->vbt.ddi_port_info[port].supports_hdmi); > > > > @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct drm_device > > > > *dev, > > > > enum port port) > > > > intel_dig_port->port = port; > > > > intel_dig_port->saved_port_bits = > > > > I915_READ(DDI_BUF_CTL(port)) & > > > > > > > > (DDI_BUF_PORT_REVERSAL | > > > > - DDI_A_4_LANES); > > > > + ddi_e_present ? 0 : > > > > DDI_A_4_LANES); > > > [Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes when > > > DDI-E > > > doesn't exist, I think your patch will do nothing. > > > > Actually DDI_A_4_LANES is being already set unconditionally, so > > Sonika's > > patch has no effect. > [Zhang, Xiong Y] No. Sonika's patch set DDI_A_4_LANES under many > conditions. > + if (IS_SKYLAKE(dev) && port == PORT_A > + && !(val & DDI_BUF_CTL_ENABLE) > + && !dev_priv->vbt.ddi_e_used) > + I915_WRITE(DDI_BUF_CTL(port), val | DDI_A_4_LANES) > > > > saved_port_bits goes to intel_dp->DP that goes to DDI_BUF_CTL and > > also it is > > used to calculate the number of lanes. > > > > With this patch we stop setting DDI_A_4_LANES when ddi_e is present > > so > > DDI-A keeps with 2 lanes and let other 2 lanes for DDI-E > [Zhang, Xiong Y] Yes, this patch will clear DDI_A_4_LANES when ddi_e > is present. > But this patch won't set DDI_A_4_LANES under following conditions > which is purpose for Sonika patch > 1. Bios fail to driver eDP and doesn't enable DDI_A buffer If DDI_A isn't enabled we don't need to set DDI_A_4_LANES > 2. Bios clear DDI_A_4_LANES > 3. DDI_E isn't present I don't agree... This is already covered on current code. DDI_A_4_LANES is already being set when enabling DDI_A. > > thanks > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: eDP can be present on DDI-E
On Wed, 2015-08-12 at 14:32 +0200, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 10:27:08AM +, Zhang, Xiong Y wrote:
> > > On Tue, 2015-08-11 at 11:47 +0200, Daniel Vetter wrote:
> > > > On Thu, Aug 06, 2015 at 03:51:39PM +0800, Xiong Zhang wrote:
> > > > > From: Rodrigo Vivi
> > > > >
> > > > > On Skylake we have eDP-to-VGA using DDI-E and another aux.
> > > > > So let's identify it properly.
> > > >
> > > > eDP means panel (the only difference in the code we have
> > > > between eDP
> > > > and DP is the power panel sequncing). VGA very much means no
> > > > panel.
> > > >
> > > > Is this some impressive hack (dp->vga dongle using panel power
> > > > as it's
> > > > power source) or what's going on here? Or just confused commit
> > > > message?
> > >
> > > That's a good question. I've heard from customer the embedded
> > > converter is
> > > eDP-to-VGA, not DP-to-VGA so I'm not sure what is behind and I
> > > have no
> > > machine here with me.
> > [Xiong, Zhang]: From vbt, it is a DP-to-VGA, not eDP-to-VGA
> > [ 103.407648] [drm:parse_ddi_port] Port E VBT info: DP:1 HDMI:0
> > DVI:0 EDP:0 CRT:0
> > >
> > > Xiong, could you please check with customer if everything works
> > > without this
> > > patch?
> > [Xiong, Zhang]: Everything works well without this patch on
> > customer's
> > machine. But if a eDP indeed connect to DDI-E without this patch,
> > intel_dp_is_edp(PORT_E) will return false, then eDP on DDI-E
> > couldn't
> > work.
>
> So if I understand it correctly this isn't about a dp2vga dongle but
> simply about edp on ddi-E? And it's also not tested with a panel
> connected
> to ddi-E?
Yes, I had miss-understood the case and messed the commit message.
>
> If that's correct I'll update the commit message to reflect this
> accurately and merge the patch.
Thanks.
> -Daniel
>
> > >
> > > Thanks,
> > > Rodrigo.
> > >
> > > > I'll punt on this for now.
> > > > -Daniel
> > > >
> > > > >
> > > > > Also let's remove duplicated definitions to avoid later
> > > > > confusion.
> > > > >
> > > > > Signed-off-by: Rodrigo Vivi
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_bios.h | 5 -
> > > > > drivers/gpu/drm/i915/intel_dp.c | 9 +
> > > > > 2 files changed, 5 insertions(+), 9 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_bios.h
> > > > > b/drivers/gpu/drm/i915/intel_bios.h
> > > > > index 02255d8..a2ef0df 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_bios.h
> > > > > +++ b/drivers/gpu/drm/i915/intel_bios.h
> > > > > @@ -747,11 +747,6 @@ int intel_parse_bios(struct drm_device
> > > > > *dev);
> > > > > #define DVO_C 2
> > > > > #define DVO_D 3
> > > > >
> > > > > -/* define the PORT for DP output type */
> > > > > -#define PORT_IDPB 7
> > > > > -#define PORT_IDPC 8
> > > > > -#define PORT_IDPD 9
> > > > > -
> > > > > /* Possible values for the "DVO Port" field for versions >=
> > > > > 155:
> > > > > */
> > > > > #define DVO_PORT_HDMIA 0
> > > > > #define DVO_PORT_HDMIB 1
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c index 7cd47bc..0643a91
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -4978,16 +4978,17 @@ intel_trans_dp_port_sel(struct
> > > > > drm_crtc
> > > > > *crtc)
> > > > > return -1;
> > > > > }
> > > > >
> > > > > -/* check the VBT to see whether the eDP is on DP-D port */
> > > > > +/* check the VBT to see whether the eDP is on another port
> > > > > */
> > > > > bool intel_dp_is_edp(struct drm_device *dev, enum port port)
> > > > > {
> > > > > struct drm_i915_private *dev_priv = dev
> > > > > ->dev_private;
> > > > > union child_device_config *p_child;
> > > > > int i;
> > > > > static const short port_mapping[] = {
> > > > > - [PORT_B] = PORT_IDPB,
> > > > > - [PORT_C] = PORT_IDPC,
> > > > > - [PORT_D] = PORT_IDPD,
> > > > > + [PORT_B] = DVO_PORT_DPB,
> > > > > + [PORT_C] = DVO_PORT_DPC,
> > > > > + [PORT_D] = DVO_PORT_DPD,
> > > > > + [PORT_E] = DVO_PORT_DPE,
> > > > > };
> > > > >
> > > > > if (port == PORT_A)
> > > > > --
> > > > > 2.1.4
> > > > >
> > > > > ___
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > >
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915:gen9: Add WA for disable gather at set shader bit
This WA doesn't have a name. According to WA ID 0555 in spec, driver need to
reset disable gather at set shader bit in per ctx WA batch. It is to be noted
that the default value is already '0' for this bit but we still need to apply
this WA because userspace may set it. If userspace really need it to be set
then they need to do in every batch.
v2: include WA ID as there is no name (Joonas)
Cc: Ben Widawsky
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
---
This was already sent sometime back today but there was an error at my end,
sending it again to be sure. Also using this opportunity to add commit msg
history.
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7456bd2..d60a510 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5834,6 +5834,7 @@ enum skl_disp_power_wells {
# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1<<10) | (1<<26))
# define GEN9_RHWO_OPTIMIZATION_DISABLE(1<<14)
#define COMMON_SLICE_CHICKEN2 0x7014
+#define GEN9_DISABLE_GATHER_SET_SHADER_SLICE (1<<12)
# define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (1<<0)
#define HIZ_CHICKEN0x7018
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5559ed9..e79be4c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1305,6 +1305,15 @@ static int gen9_init_perctx_bb(struct intel_engine_cs
*ring,
struct drm_device *dev = ring->dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
+ /* WaNoName:skl,bxt
+* This WA has no name, WA ID 0555 in spec says, driver needs to reset
+* "disable gather at set shader slice" bit in per ctx batch
+*/
+ wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
+ wa_ctx_emit(batch, index, COMMON_SLICE_CHICKEN2);
+ wa_ctx_emit(batch, index,
+ _MASKED_BIT_DISABLE(GEN9_DISABLE_GATHER_SET_SHADER_SLICE));
+
/* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
if ((IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_B0)) ||
(IS_BROXTON(dev) && (INTEL_REVID(dev) == BXT_REVID_A0))) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] drm/i915: Move DP link parameters out from intel_dp
On Mon, Jul 06, 2015 at 03:09:59PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > While working on CHV DPIO powergating I relized DP .compute_config() was > clobbering lane_count etc. stored in intel_dp. This could cause problems > if we do the .compute_config() but later fail the modeset for some reason. > Any subsequent link re-training might then fail if intel_dp->lane_count > etc. got changed. > > The reason I ran into this during the DPIO powergating work was that I may > need to know which lanes he active when shutting down the link. However > .compute_config() already clobbered that information by the time I need it. > By moving it to the pipe config we avoid that problem as well. > > I also cleaned up the limited color range handling a bit while I was > in the neighborhood. > > drm/i915: Clean up DP/HDMI limited color range handling > drm/i915: Move intel_dp->lane_count into pipe_config These two are still lacking a r-b. Would be nice to get these in so that they don't end up blocking the CHV DPIO powergating stuff once that gets reviewed. Sivakumar, any chance you'd like to review those as well? Or do we have anyone else interested? -- 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 v1 2/2] drm/i915/gen9: Disable gather at set shader bit
On 12/08/2015 16:41, Dave Gordon wrote: On 11/08/15 15:44, Arun Siluvery wrote: From Gen9, Push constant instruction parsing behaviour varies according to whether set shader is enabled or not. If we want legacy behaviour then it can be achieved by disabling set shader. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959 Cc: Ben Widawsky Cc: Joonas Lahtinen Cc: Mika Kuoppala Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 5 + drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++ 2 files changed, 15 insertions(+) [snip] diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index cf61262..7d284ed 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -983,6 +983,16 @@ static int gen9_init_workarounds(struct intel_engine_cs *ring) tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE; WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp); +/* Chicken bits to disable set shader is in multiple places, + * set bits in all required registers to disable it correctly + */ +WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2, GEN9_DISABLE_GATHER_SET_SHADER_SLICE); +if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_D0) || +(IS_BROXTON(dev) && INTEL_REVID(dev) == BXT_REVID_A0)) +WA_SET_BIT_MASKED(RS_CHICKEN, RS_CHICKEN_DISABLE_GATHER_AT_SHADER); +else +WA_SET_BIT_MASKED(CS_RCS_BE, CS_RCS_DISABLE_GATHER_AT_SHADER); + return 0; } This workaround isn't tagged with a specific /* WaXyz:chip */ comment. Also, the style isn't consistent with the other paragraphs earlier in this function: those have braces round the body part even when there's only one line of code, possibly to make it clear where the WA comment applies (of course, this is why the buggy WA_REG() macro wasn't spotted earlier). So, maybe prettify this a bit, if possible? The code actually looks correct, just ugly. Oh, and keep patch 1 even if you decide to abandon this one! Hi Dave, This patch can be ignored if we use below patch, [Intel-gfx] [PATCH] lib/rendercopy_gen9: Setup Push constantpointer before sending BTP commands http://lists.freedesktop.org/archives/intel-gfx/2015-August/073483.html I think the correct option would be to ignore this patch. regards Arun .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] drm/i915: Add port A HPD support for SPT
From: Ville Syrjälä
On SKL the port A HPD has moved to the PCH. Hook it up.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 21 +++--
drivers/gpu/drm/i915/i915_reg.h | 4 +++-
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index aefa6c4..ec739e6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -74,6 +74,7 @@ static const u32 hpd_cpt[HPD_NUM_PINS] = {
};
static const u32 hpd_spt[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = SDE_PORTA_HOTPLUG_SPT,
[HPD_PORT_B] = SDE_PORTB_HOTPLUG_CPT,
[HPD_PORT_C] = SDE_PORTC_HOTPLUG_CPT,
[HPD_PORT_D] = SDE_PORTD_HOTPLUG_CPT,
@@ -1312,6 +1313,22 @@ static bool spt_port_hotplug2_long_detect(enum port
port, u32 val)
}
}
+static bool spt_port_hotplug_long_detect(enum port port, u32 val)
+{
+ switch (port) {
+ case PORT_A:
+ return val & PORTA_HOTPLUG_LONG_DETECT;
+ case PORT_B:
+ return val & PORTB_HOTPLUG_LONG_DETECT;
+ case PORT_C:
+ return val & PORTC_HOTPLUG_LONG_DETECT;
+ case PORT_D:
+ return val & PORTD_HOTPLUG_LONG_DETECT;
+ default:
+ return false;
+ }
+}
+
static bool ilk_port_hotplug_long_detect(enum port port, u32 val)
{
switch (port) {
@@ -1891,7 +1908,7 @@ static void spt_irq_handler(struct drm_device *dev, u32
pch_iir)
intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
dig_hotplug_reg, hpd_spt,
- pch_port_hotplug_long_detect);
+ spt_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -3190,7 +3207,7 @@ static void spt_hpd_irq_setup(struct drm_device *dev)
/* Enable digital hotplug on the PCH */
hotplug = I915_READ(PCH_PORT_HOTPLUG);
hotplug |= PORTD_HOTPLUG_ENABLE | PORTC_HOTPLUG_ENABLE |
- PORTB_HOTPLUG_ENABLE;
+ PORTB_HOTPLUG_ENABLE | PORTA_HOTPLUG_ENABLE;
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
hotplug = I915_READ(PCH_PORT_HOTPLUG2);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0e9990b..3224c97 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5953,6 +5953,7 @@ enum skl_disp_power_wells {
#define SDE_AUXB_CPT (1 << 25)
#define SDE_AUX_MASK_CPT (7 << 25)
#define SDE_PORTE_HOTPLUG_SPT (1 << 25)
+#define SDE_PORTA_HOTPLUG_SPT (1 << 24)
#define SDE_PORTD_HOTPLUG_CPT (1 << 23)
#define SDE_PORTC_HOTPLUG_CPT (1 << 22)
#define SDE_PORTB_HOTPLUG_CPT (1 << 21)
@@ -5966,7 +5967,8 @@ enum skl_disp_power_wells {
#define SDE_HOTPLUG_MASK_SPT (SDE_PORTE_HOTPLUG_SPT |\
SDE_PORTD_HOTPLUG_CPT |\
SDE_PORTC_HOTPLUG_CPT |\
-SDE_PORTB_HOTPLUG_CPT)
+SDE_PORTB_HOTPLUG_CPT |\
+SDE_PORTA_HOTPLUG_SPT)
#define SDE_GMBUS_CPT (1 << 17)
#define SDE_ERROR_CPT (1 << 16)
#define SDE_AUDIO_CP_REQ_C_CPT (1 << 10)
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/11] drm/i915: Introduce spt_irq_handler()
From: Ville Syrjälä
Starting from SPT the only interrupts living in the south are GMBUS and
HPD. What's worse some of the SPT specific new bits conflict with some
other bits on earlier PCH generations. So better not use the
cpt_irq_handler() for SPT+ anymore.
Also kill the hand rolled port E handling with something more
standardish. This also avoids accidentally confusing port B and port E
long pulses since the bits occupy the same positions, just in different
registers.
Also add a comment noting that the short pulse duration bits are
reserved on LPT+. The 2ms value we program is 0, so no issue wrt. the
MBZ in the spec.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 123 +++-
1 file changed, 83 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d12106c..e2485bd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1260,6 +1260,16 @@ static bool bxt_port_hotplug_long_detect(enum port port,
u32 val)
}
}
+static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
+{
+ switch (port) {
+ case PORT_E:
+ return val & PORTE_HOTPLUG_LONG_DETECT;
+ default:
+ return false;
+ }
+}
+
static bool pch_port_hotplug_long_detect(enum port port, u32 val)
{
switch (port) {
@@ -1269,8 +1279,6 @@ static bool pch_port_hotplug_long_detect(enum port port,
u32 val)
return val & PORTC_HOTPLUG_LONG_DETECT;
case PORT_D:
return val & PORTD_HOTPLUG_LONG_DETECT;
- case PORT_E:
- return val & PORTE_HOTPLUG_LONG_DETECT;
default:
return false;
}
@@ -1771,12 +1779,7 @@ static void cpt_irq_handler(struct drm_device *dev, u32
pch_iir)
{
struct drm_i915_private *dev_priv = dev->dev_private;
int pipe;
- u32 hotplug_trigger;
-
- if (HAS_PCH_SPT(dev))
- hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT;
- else
- hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
+ u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
if (hotplug_trigger) {
u32 dig_hotplug_reg, pin_mask, long_mask;
@@ -1784,22 +1787,10 @@ static void cpt_irq_handler(struct drm_device *dev, u32
pch_iir)
dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
- if (HAS_PCH_SPT(dev)) {
- intel_get_hpd_pins(&pin_mask, &long_mask,
- hotplug_trigger,
- dig_hotplug_reg, hpd_spt,
- pch_port_hotplug_long_detect);
-
- /* detect PORTE HP event */
- dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG2);
- if (pch_port_hotplug_long_detect(PORT_E,
-dig_hotplug_reg))
- long_mask |= 1 << HPD_PORT_E;
- } else
- intel_get_hpd_pins(&pin_mask, &long_mask,
- hotplug_trigger,
- dig_hotplug_reg, hpd_cpt,
- pch_port_hotplug_long_detect);
+ intel_get_hpd_pins(&pin_mask, &long_mask,
+ hotplug_trigger,
+ dig_hotplug_reg, hpd_cpt,
+ pch_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -1833,6 +1824,42 @@ static void cpt_irq_handler(struct drm_device *dev, u32
pch_iir)
cpt_serr_int_handler(dev);
}
+static void spt_irq_handler(struct drm_device *dev, u32 pch_iir)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT &
+ ~SDE_PORTE_HOTPLUG_SPT;
+ u32 hotplug2_trigger = pch_iir & SDE_PORTE_HOTPLUG_SPT;
+
+ if (hotplug_trigger) {
+ u32 dig_hotplug_reg, pin_mask, long_mask;
+
+ dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
+ I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
+
+ intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
+ dig_hotplug_reg, hpd_spt,
+ pch_port_hotplug_long_detect);
+ intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ }
+
+ if (hotplug2_trigger) {
+ u32 dig_hotplug_reg, pin_mask, long_mask;
+
+ dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG2);
+ I915_WRITE(PCH_PORT_HOTPLUG2, dig_hotplug_reg);
+
+ intel_get_hpd_pins(&pin_mask, &long_mask, hotplug2_trigger,
+
[Intel-gfx] [PATCH 03/11] drm/i915: Factor out ilk_update_display_irq()
From: Ville Syrjälä
Extract the core of ironlake_{enable,disable}_display_irq() into a new
function. We'll have further use for it later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index de0edbd..8a1e35e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -154,35 +154,44 @@ static const u32 hpd_bxt[HPD_NUM_PINS] = {
static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir);
-/* For display hotplug interrupt */
-void
-ironlake_enable_display_irq(struct drm_i915_private *dev_priv, u32 mask)
+/**
+ * ilk_update_display_irq - update DEIMR
+ * @dev_priv: driver private
+ * @interrupt_mask: mask of interrupt bits to update
+ * @enabled_irq_mask: mask of interrupt bits to enable
+ */
+static void ilk_update_display_irq(struct drm_i915_private *dev_priv,
+ uint32_t interrupt_mask,
+ uint32_t enabled_irq_mask)
{
+ uint32_t new_val;
+
assert_spin_locked(&dev_priv->irq_lock);
if (WARN_ON(!intel_irqs_enabled(dev_priv)))
return;
- if ((dev_priv->irq_mask & mask) != 0) {
- dev_priv->irq_mask &= ~mask;
+ new_val = dev_priv->irq_mask;
+ new_val &= ~interrupt_mask;
+ new_val |= (~enabled_irq_mask & interrupt_mask);
+
+ if (new_val != dev_priv->irq_mask) {
+ dev_priv->irq_mask = new_val;
I915_WRITE(DEIMR, dev_priv->irq_mask);
POSTING_READ(DEIMR);
}
}
void
-ironlake_disable_display_irq(struct drm_i915_private *dev_priv, u32 mask)
+ironlake_enable_display_irq(struct drm_i915_private *dev_priv, u32 mask)
{
- assert_spin_locked(&dev_priv->irq_lock);
-
- if (WARN_ON(!intel_irqs_enabled(dev_priv)))
- return;
+ ilk_update_display_irq(dev_priv, mask, mask);
+}
- if ((dev_priv->irq_mask & mask) != mask) {
- dev_priv->irq_mask |= mask;
- I915_WRITE(DEIMR, dev_priv->irq_mask);
- POSTING_READ(DEIMR);
- }
+void
+ironlake_disable_display_irq(struct drm_i915_private *dev_priv, u32 mask)
+{
+ ilk_update_display_irq(dev_priv, mask, 0);
}
/**
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/11] drm/i915: Add port A HPD support for IVB/HSW
From: Ville Syrjälä
As with ILK/SNB wire up the port A HPD on IVB/HSW.
This might be more important on HSW with PSR. BSpec tells us that if the
automagic link training performed by the hardware fails for some reason,
we're going to get a short HPD and are supposed to re-train the link
manyally.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 152be8b..d994b80 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -49,6 +49,10 @@ static const u32 hpd_ilk[HPD_NUM_PINS] = {
[HPD_PORT_A] = DE_DP_A_HOTPLUG,
};
+static const u32 hpd_ivb[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = DE_DP_A_HOTPLUG_IVB,
+};
+
static const u32 hpd_ibx[HPD_NUM_PINS] = {
[HPD_CRT] = SDE_CRT_HOTPLUG,
[HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
@@ -1940,6 +1944,19 @@ static void ivb_display_irq_handler(struct drm_device
*dev, u32 de_iir)
{
struct drm_i915_private *dev_priv = dev->dev_private;
enum pipe pipe;
+ u32 hotplug_trigger = de_iir & DE_DP_A_HOTPLUG_IVB;
+
+ if (hotplug_trigger) {
+ u32 dig_hotplug_reg, pin_mask, long_mask;
+
+ dig_hotplug_reg = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
+ I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, dig_hotplug_reg);
+
+ intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
+ dig_hotplug_reg, hpd_ivb,
+ ilk_port_hotplug_long_detect);
+ intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ }
if (de_iir & DE_ERR_INT_IVB)
ivb_err_int_handler(dev);
@@ -3137,8 +3154,13 @@ static void ilk_hpd_irq_setup(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hotplug_irqs, hotplug, enabled_irqs;
- hotplug_irqs = DE_DP_A_HOTPLUG;
- enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
+ if (INTEL_INFO(dev)->gen >= 7) {
+ hotplug_irqs = DE_DP_A_HOTPLUG_IVB;
+ enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ivb);
+ } else {
+ hotplug_irqs = DE_DP_A_HOTPLUG;
+ enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
+ }
ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
@@ -3245,7 +3267,8 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
DE_PLANEB_FLIP_DONE_IVB |
DE_PLANEA_FLIP_DONE_IVB | DE_AUX_CHANNEL_A_IVB);
extra_mask = (DE_PIPEC_VBLANK_IVB | DE_PIPEB_VBLANK_IVB |
- DE_PIPEA_VBLANK_IVB | DE_ERR_INT_IVB);
+ DE_PIPEA_VBLANK_IVB | DE_ERR_INT_IVB |
+ DE_DP_A_HOTPLUG_IVB);
} else {
display_mask = (DE_MASTER_IRQ_CONTROL | DE_GSE | DE_PCH_EVENT |
DE_PLANEA_FLIP_DONE | DE_PLANEB_FLIP_DONE |
@@ -4270,10 +4293,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->irq_uninstall = ironlake_irq_uninstall;
dev->driver->enable_vblank = ironlake_enable_vblank;
dev->driver->disable_vblank = ironlake_disable_vblank;
- if (INTEL_INFO(dev)->gen >= 7)
- dev_priv->display.hpd_irq_setup = ibx_hpd_irq_setup;
- else
- dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
+ dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
} else {
if (INTEL_INFO(dev_priv)->gen == 2) {
dev->driver->irq_preinstall = i8xx_irq_preinstall;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/11] drm/i915: Add HAS_PCH_LPT_LP() macro
From: Ville Syrjälä
Make LPT:LP checks look neater by wrapping the details in a
new HAS_PCH_LPT_LP() macro.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 13 +
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 55611d8..4e391dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2573,6 +2573,7 @@ struct drm_i915_cmd_table {
#define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
#define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
#define HAS_PCH_LPT(dev) (INTEL_PCH_TYPE(dev) == PCH_LPT)
+#define HAS_PCH_LPT_LP(dev) (__I915__(dev)->pch_id ==
INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
#define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT)
#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
#define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4b3012b..97c6368 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8381,8 +8381,7 @@ static void lpt_enable_clkout_dp(struct drm_device *dev,
bool with_spread,
if (WARN(with_fdi && !with_spread, "FDI requires downspread\n"))
with_spread = true;
- if (WARN(dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE &&
-with_fdi, "LP PCH doesn't have FDI\n"))
+ if (WARN(HAS_PCH_LPT_LP(dev) && with_fdi, "LP PCH doesn't have FDI\n"))
with_fdi = false;
mutex_lock(&dev_priv->sb_lock);
@@ -8405,8 +8404,7 @@ static void lpt_enable_clkout_dp(struct drm_device *dev,
bool with_spread,
}
}
- reg = (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
- SBI_GEN0 : SBI_DBUFF0;
+ reg = HAS_PCH_LPT_LP(dev) ? SBI_GEN0 : SBI_DBUFF0;
tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
tmp |= SBI_GEN0_CFG_BUFFENABLE_DISABLE;
intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
@@ -8422,8 +8420,7 @@ static void lpt_disable_clkout_dp(struct drm_device *dev)
mutex_lock(&dev_priv->sb_lock);
- reg = (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
- SBI_GEN0 : SBI_DBUFF0;
+ reg = HAS_PCH_LPT_LP(dev) ? SBI_GEN0 : SBI_DBUFF0;
tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
tmp &= ~SBI_GEN0_CFG_BUFFENABLE_DISABLE;
intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
@@ -9435,7 +9432,7 @@ void hsw_enable_pc8(struct drm_i915_private *dev_priv)
DRM_DEBUG_KMS("Enabling package C8+\n");
- if (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ if (HAS_PCH_LPT_LP(dev)) {
val = I915_READ(SOUTH_DSPCLK_GATE_D);
val &= ~PCH_LP_PARTITION_LEVEL_DISABLE;
I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
@@ -9455,7 +9452,7 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv)
hsw_restore_lcpll(dev_priv);
lpt_init_pch_refclk(dev);
- if (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ if (HAS_PCH_LPT_LP(dev)) {
val = I915_READ(SOUTH_DSPCLK_GATE_D);
val |= PCH_LP_PARTITION_LEVEL_DISABLE;
I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fff0c226..ea49661 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6588,7 +6588,7 @@ static void lpt_init_clock_gating(struct drm_device *dev)
* TODO: this bit should only be enabled when really needed, then
* disabled when not needed anymore in order to save power.
*/
- if (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
+ if (HAS_PCH_LPT_LP(dev))
I915_WRITE(SOUTH_DSPCLK_GATE_D,
I915_READ(SOUTH_DSPCLK_GATE_D) |
PCH_LP_PARTITION_LEVEL_DISABLE);
@@ -6603,7 +6603,7 @@ static void lpt_suspend_hw(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- if (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ if (HAS_PCH_LPT_LP(dev)) {
uint32_t val = I915_READ(SOUTH_DSPCLK_GATE_D);
val &= ~PCH_LP_PARTITION_LEVEL_DISABLE;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/11] drm/i915; Extract intel_hpd_enabled_irqs()
From: Ville Syrjälä
Eliminate a bunch of duplicated code that calculates the currently
enabled HPD interrupt bits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 43 -
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8485bea..de0edbd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3002,27 +3002,34 @@ static void cherryview_irq_preinstall(struct drm_device
*dev)
vlv_display_irq_reset(dev_priv);
}
+static u32 intel_hpd_enabled_irqs(struct drm_device *dev,
+ const u32 hpd[HPD_NUM_PINS])
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_encoder *encoder;
+ u32 enabled_irqs = 0;
+
+ for_each_intel_encoder(dev, encoder)
+ if (dev_priv->hotplug.stats[encoder->hpd_pin].state ==
HPD_ENABLED)
+ enabled_irqs |= hpd[encoder->hpd_pin];
+
+ return enabled_irqs;
+}
+
static void ibx_hpd_irq_setup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_encoder *intel_encoder;
- u32 hotplug_irqs, hotplug, enabled_irqs = 0;
+ u32 hotplug_irqs, hotplug, enabled_irqs;
if (HAS_PCH_IBX(dev)) {
hotplug_irqs = SDE_HOTPLUG_MASK;
- for_each_intel_encoder(dev, intel_encoder)
- if
(dev_priv->hotplug.stats[intel_encoder->hpd_pin].state == HPD_ENABLED)
- enabled_irqs |= hpd_ibx[intel_encoder->hpd_pin];
+ enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ibx);
} else if (HAS_PCH_SPT(dev)) {
hotplug_irqs = SDE_HOTPLUG_MASK_SPT;
- for_each_intel_encoder(dev, intel_encoder)
- if
(dev_priv->hotplug.stats[intel_encoder->hpd_pin].state == HPD_ENABLED)
- enabled_irqs |= hpd_spt[intel_encoder->hpd_pin];
+ enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_spt);
} else {
hotplug_irqs = SDE_HOTPLUG_MASK_CPT;
- for_each_intel_encoder(dev, intel_encoder)
- if
(dev_priv->hotplug.stats[intel_encoder->hpd_pin].state == HPD_ENABLED)
- enabled_irqs |= hpd_cpt[intel_encoder->hpd_pin];
+ enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_cpt);
}
ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
@@ -3051,15 +3058,10 @@ static void ibx_hpd_irq_setup(struct drm_device *dev)
static void bxt_hpd_irq_setup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_encoder *intel_encoder;
- u32 hotplug_port = 0;
+ u32 hotplug_port;
u32 hotplug_ctrl;
- for_each_intel_encoder(dev, intel_encoder) {
- if (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state
- == HPD_ENABLED)
- hotplug_port |= hpd_bxt[intel_encoder->hpd_pin];
- }
+ hotplug_port = intel_hpd_enabled_irqs(dev, hpd_bxt);
hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) & ~BXT_HOTPLUG_CTL_MASK;
@@ -3935,7 +3937,6 @@ static int i965_irq_postinstall(struct drm_device *dev)
static void i915_hpd_irq_setup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_encoder *intel_encoder;
u32 hotplug_en;
assert_spin_locked(&dev_priv->irq_lock);
@@ -3944,9 +3945,7 @@ static void i915_hpd_irq_setup(struct drm_device *dev)
hotplug_en &= ~HOTPLUG_INT_EN_MASK;
/* Note HDMI and DP share hotplug bits */
/* enable bits are the same for all generations */
- for_each_intel_encoder(dev, intel_encoder)
- if (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state ==
HPD_ENABLED)
- hotplug_en |= hpd_mask_i915[intel_encoder->hpd_pin];
+ hotplug_en |= intel_hpd_enabled_irqs(dev, hpd_mask_i915);
/* Programming the CRT detection parameters tends
to generate a spurious hotplug event about three
seconds later. So just do it once.
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/11] drm/i915: Add port A HPD support for ILK/SNB
From: Ville Syrjälä
ILK/SNB support port A HPD. While HPD is optional on eDP let's at least
try to wite it up so that we might notice if the link has issues.
The eDP spec suggests that if HPD is not wired up, one should poll the
link status instead. We don't even do that currently.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 59 ++---
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e2485bd..152be8b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -45,6 +45,10 @@
* and related files, but that will be described in separate chapters.
*/
+static const u32 hpd_ilk[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = DE_DP_A_HOTPLUG,
+};
+
static const u32 hpd_ibx[HPD_NUM_PINS] = {
[HPD_CRT] = SDE_CRT_HOTPLUG,
[HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
@@ -1270,6 +1274,16 @@ static bool spt_port_hotplug2_long_detect(enum port
port, u32 val)
}
}
+static bool ilk_port_hotplug_long_detect(enum port port, u32 val)
+{
+ switch (port) {
+ case PORT_A:
+ return val & DIGITAL_PORTA_HOTPLUG_LONG_DETECT;
+ default:
+ return false;
+ }
+}
+
static bool pch_port_hotplug_long_detect(enum port port, u32 val)
{
switch (port) {
@@ -1864,6 +1878,19 @@ static void ilk_display_irq_handler(struct drm_device
*dev, u32 de_iir)
{
struct drm_i915_private *dev_priv = dev->dev_private;
enum pipe pipe;
+ u32 hotplug_trigger = de_iir & DE_DP_A_HOTPLUG;
+
+ if (hotplug_trigger) {
+ u32 dig_hotplug_reg, pin_mask, long_mask;
+
+ dig_hotplug_reg = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
+ I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, dig_hotplug_reg);
+
+ intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
+ dig_hotplug_reg, hpd_ilk,
+ ilk_port_hotplug_long_detect);
+ intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ }
if (de_iir & DE_AUX_CHANNEL_A)
dp_aux_irq_handler(dev);
@@ -3105,6 +3132,28 @@ static void spt_hpd_irq_setup(struct drm_device *dev)
I915_WRITE(PCH_PORT_HOTPLUG2, hotplug);
}
+static void ilk_hpd_irq_setup(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 hotplug_irqs, hotplug, enabled_irqs;
+
+ hotplug_irqs = DE_DP_A_HOTPLUG;
+ enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
+
+ ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
+
+ /*
+* Enable digital hotplug on the CPU, and configure the DP short pulse
+* duration to 2ms (which is the minimum in the Display Port spec)
+*/
+ hotplug = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
+ hotplug &= ~DIGITAL_PORTA_PULSE_DURATION_MASK;
+ hotplug |= DIGITAL_PORTA_HOTPLUG_ENABLE |
DIGITAL_PORTA_PULSE_DURATION_2ms;
+ I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, hotplug);
+
+ ibx_hpd_irq_setup(dev);
+}
+
static void bxt_hpd_irq_setup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3203,8 +3252,9 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
DE_AUX_CHANNEL_A |
DE_PIPEB_CRC_DONE | DE_PIPEA_CRC_DONE |
DE_POISON);
- extra_mask = DE_PIPEA_VBLANK | DE_PIPEB_VBLANK | DE_PCU_EVENT |
- DE_PIPEB_FIFO_UNDERRUN | DE_PIPEA_FIFO_UNDERRUN;
+ extra_mask = (DE_PIPEA_VBLANK | DE_PIPEB_VBLANK | DE_PCU_EVENT |
+ DE_PIPEB_FIFO_UNDERRUN | DE_PIPEA_FIFO_UNDERRUN |
+ DE_DP_A_HOTPLUG);
}
dev_priv->irq_mask = ~display_mask;
@@ -4220,7 +4270,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->irq_uninstall = ironlake_irq_uninstall;
dev->driver->enable_vblank = ironlake_enable_vblank;
dev->driver->disable_vblank = ironlake_disable_vblank;
- dev_priv->display.hpd_irq_setup = ibx_hpd_irq_setup;
+ if (INTEL_INFO(dev)->gen >= 7)
+ dev_priv->display.hpd_irq_setup = ibx_hpd_irq_setup;
+ else
+ dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
} else {
if (INTEL_INFO(dev_priv)->gen == 2) {
dev->driver->irq_preinstall = i8xx_irq_preinstall;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/11] drm/i915: LPT:LP needs port A HPD enabled in both north and south
From: Ville Syrjälä Supposedly we have to enable port A HPD also in the south on LPT:LP. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index d994b80..de60174 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -3125,6 +3125,8 @@ static void ibx_hpd_irq_setup(struct drm_device *dev) hotplug |= PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_2ms; hotplug |= PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_2ms; hotplug |= PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_2ms; + if (HAS_PCH_LPT_LP(dev)) + hotplug |= PORTA_HOTPLUG_ENABLE; I915_WRITE(PCH_PORT_HOTPLUG, hotplug); } -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] drm/i915: Add port A HPD support for BDW
From: Ville Syrjälä
Wire up the port A HPD for BDW. Compared to earlier platforms the
interrupt setup is a bit different, but basically everything else
looks the same.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 72 +
1 file changed, 66 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index de60174..aefa6c4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -53,6 +53,10 @@ static const u32 hpd_ivb[HPD_NUM_PINS] = {
[HPD_PORT_A] = DE_DP_A_HOTPLUG_IVB,
};
+static const u32 hpd_bdw[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = GEN8_PORT_DP_A_HOTPLUG,
+};
+
static const u32 hpd_ibx[HPD_NUM_PINS] = {
[HPD_CRT] = SDE_CRT_HOTPLUG,
[HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
@@ -369,6 +373,36 @@ void gen6_disable_rps_interrupts(struct drm_device *dev)
}
/**
+ * bdw_update_port_irq - update DE port interrupt
+ * @dev_priv: driver private
+ * @interrupt_mask: mask of interrupt bits to update
+ * @enabled_irq_mask: mask of interrupt bits to enable
+ */
+static void bdw_update_port_irq(struct drm_i915_private *dev_priv,
+ uint32_t interrupt_mask,
+ uint32_t enabled_irq_mask)
+{
+ uint32_t new_val;
+ uint32_t old_val;
+
+ assert_spin_locked(&dev_priv->irq_lock);
+
+ if (WARN_ON(!intel_irqs_enabled(dev_priv)))
+ return;
+
+ old_val = I915_READ(GEN8_DE_PORT_IMR);
+
+ new_val = old_val;
+ new_val &= ~interrupt_mask;
+ new_val |= (~enabled_irq_mask & interrupt_mask);
+
+ if (new_val != old_val) {
+ I915_WRITE(GEN8_DE_PORT_IMR, new_val);
+ POSTING_READ(GEN8_DE_PORT_IMR);
+ }
+}
+
+/**
* ibx_display_interrupt_update - update SDEIMR
* @dev_priv: driver private
* @interrupt_mask: mask of interrupt bits to update
@@ -2139,10 +2173,23 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
tmp = I915_READ(GEN8_DE_PORT_IIR);
if (tmp) {
bool found = false;
+ u32 hotplug_trigger = tmp & GEN8_PORT_DP_A_HOTPLUG;
I915_WRITE(GEN8_DE_PORT_IIR, tmp);
ret = IRQ_HANDLED;
+ if (hotplug_trigger) {
+ u32 dig_hotplug_reg, pin_mask, long_mask;
+
+ dig_hotplug_reg =
I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
+ I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL,
dig_hotplug_reg);
+
+ intel_get_hpd_pins(&pin_mask, &long_mask,
hotplug_trigger,
+ dig_hotplug_reg, hpd_bdw,
+
ilk_port_hotplug_long_detect);
+ intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ }
+
if (tmp & aux_mask) {
dp_aux_irq_handler(dev);
found = true;
@@ -3156,15 +3203,22 @@ static void ilk_hpd_irq_setup(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hotplug_irqs, hotplug, enabled_irqs;
- if (INTEL_INFO(dev)->gen >= 7) {
+ if (INTEL_INFO(dev)->gen >= 8) {
+ hotplug_irqs = GEN8_PORT_DP_A_HOTPLUG;
+ enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_bdw);
+
+ bdw_update_port_irq(dev_priv, hotplug_irqs, enabled_irqs);
+ } else if (INTEL_INFO(dev)->gen >= 7) {
hotplug_irqs = DE_DP_A_HOTPLUG_IVB;
enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ivb);
+
+ ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
} else {
hotplug_irqs = DE_DP_A_HOTPLUG;
enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
- }
- ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
+ ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
+ }
/*
* Enable digital hotplug on the CPU, and configure the DP short pulse
@@ -3477,6 +3531,7 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
uint32_t de_pipe_enables;
int pipe;
u32 de_port_en = GEN8_AUX_CHANNEL_A;
+ u32 de_port_masked;
if (IS_GEN9(dev_priv)) {
de_pipe_masked |= GEN9_PIPE_PLANE1_FLIP_DONE |
@@ -3486,9 +3541,14 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
if (IS_BROXTON(dev_priv))
de_port_en |= BXT_DE_PORT_GMBUS;
- } else
+ } else {
de_pipe_masked |= GEN8_PIPE_PRIMARY_FLIP_DONE |
GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
+ }
+
+ de_port_masked
[Intel-gfx] [PATCH 00/11] drm/i915: Port A HPD and other HPD cleanups
From: Ville Syrjälä I've had a bunch of this stuff sitting in a branch for quite a while, almost a year by the looks of the git dates :P I also had port E HPD in there but something similar has already landed in the meantime so I just rebased my junk on top. I've only quickly tested the port A HPD on my ILK. Don't have other machines with eDP on port A here. Ville Syrjälä (11): drm/i915: Clean up various HPD defines drm/i915; Extract intel_hpd_enabled_irqs() drm/i915: Factor out ilk_update_display_irq() drm/i915: Add HAS_PCH_LPT_LP() macro drm/i915: Rename BXT PORTA HPD defines drm/i915: Introduce spt_irq_handler() drm/i915: Add port A HPD support for ILK/SNB drm/i915: Add port A HPD support for IVB/HSW drm/i915: LPT:LP needs port A HPD enabled in both north and south drm/i915: Add port A HPD support for BDW drm/i915: Add port A HPD support for SPT drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 367 +++ drivers/gpu/drm/i915/i915_reg.h | 82 drivers/gpu/drm/i915/intel_display.c | 13 +- drivers/gpu/drm/i915/intel_pm.c | 4 +- 5 files changed, 336 insertions(+), 131 deletions(-) -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/11] drm/i915: Rename BXT PORTA HPD defines
From: Ville Syrjälä
The PORTA HPD defines are not BXT specific. They also exist on SPT,
and partially already on LPT:LP.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8a1e35e..d12106c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1248,7 +1248,7 @@ static bool bxt_port_hotplug_long_detect(enum port port,
u32 val)
{
switch (port) {
case PORT_A:
- return val & BXT_PORTA_HOTPLUG_LONG_DETECT;
+ return val & PORTA_HOTPLUG_LONG_DETECT;
case PORT_B:
return val & PORTB_HOTPLUG_LONG_DETECT;
case PORT_C:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ed2d150..0e9990b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6002,11 +6002,11 @@ enum skl_disp_power_wells {
/* digital port hotplug */
#define PCH_PORT_HOTPLUG0xc4030/* SHOTPLUG_CTL */
-#define BXT_PORTA_HOTPLUG_ENABLE (1 << 28)
-#define BXT_PORTA_HOTPLUG_STATUS_MASK (3 << 24)
-#define BXT_PORTA_HOTPLUG_NO_DETECT (0 << 24)
-#define BXT_PORTA_HOTPLUG_SHORT_DETECT(1 << 24)
-#define BXT_PORTA_HOTPLUG_LONG_DETECT (2 << 24)
+#define PORTA_HOTPLUG_ENABLE (1 << 28) /* LPT:LP+ & BXT */
+#define PORTA_HOTPLUG_STATUS_MASK (3 << 24) /* SPT+ & BXT */
+#define PORTA_HOTPLUG_NO_DETECT (0 << 24) /* SPT+ & BXT */
+#define PORTA_HOTPLUG_SHORT_DETECT(1 << 24) /* SPT+ & BXT */
+#define PORTA_HOTPLUG_LONG_DETECT (2 << 24) /* SPT+ & BXT */
#define PORTD_HOTPLUG_ENABLE (1 << 20)
#define PORTD_PULSE_DURATION_2ms (0 << 18)
#define PORTD_PULSE_DURATION_4_5ms(1 << 18)
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm/i915: Clean up various HPD defines
From: Ville Syrjälä
Indent the PORTx_HOTPLUG_... defines appropriately, and fix some space
vs. tab issues.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 72 +
1 file changed, 37 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6786e94..ed2d150 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5364,15 +5364,17 @@ enum skl_disp_power_wells {
#define CPU_VGACNTRL 0x41000
-#define DIGITAL_PORT_HOTPLUG_CNTRL 0x44030
-#define DIGITAL_PORTA_HOTPLUG_ENABLE (1 << 4)
-#define DIGITAL_PORTA_SHORT_PULSE_2MS (0 << 2)
-#define DIGITAL_PORTA_SHORT_PULSE_4_5MS(1 << 2)
-#define DIGITAL_PORTA_SHORT_PULSE_6MS (2 << 2)
-#define DIGITAL_PORTA_SHORT_PULSE_100MS(3 << 2)
-#define DIGITAL_PORTA_NO_DETECT(0 << 0)
-#define DIGITAL_PORTA_LONG_PULSE_DETECT_MASK (1 << 1)
-#define DIGITAL_PORTA_SHORT_PULSE_DETECT_MASK (1 << 0)
+#define DIGITAL_PORT_HOTPLUG_CNTRL 0x44030
+#define DIGITAL_PORTA_HOTPLUG_ENABLE (1 << 4)
+#define DIGITAL_PORTA_PULSE_DURATION_2ms (0 << 2)
+#define DIGITAL_PORTA_PULSE_DURATION_4_5ms(1 << 2)
+#define DIGITAL_PORTA_PULSE_DURATION_6ms (2 << 2)
+#define DIGITAL_PORTA_PULSE_DURATION_100ms(3 << 2)
+#define DIGITAL_PORTA_PULSE_DURATION_MASK (3 << 2)
+#define DIGITAL_PORTA_HOTPLUG_STATUS_MASK (3 << 0)
+#define DIGITAL_PORTA_HOTPLUG_NO_DETECT (0 << 0)
+#define DIGITAL_PORTA_HOTPLUG_SHORT_DETECT(1 << 0)
+#define DIGITAL_PORTA_HOTPLUG_LONG_DETECT (2 << 0)
/* refresh rate hardware control */
#define RR_HW_CTL 0x45300
@@ -6000,45 +6002,45 @@ enum skl_disp_power_wells {
/* digital port hotplug */
#define PCH_PORT_HOTPLUG0xc4030/* SHOTPLUG_CTL */
-#define BXT_PORTA_HOTPLUG_ENABLE (1 << 28)
-#define BXT_PORTA_HOTPLUG_STATUS_MASK (0x3 << 24)
+#define BXT_PORTA_HOTPLUG_ENABLE (1 << 28)
+#define BXT_PORTA_HOTPLUG_STATUS_MASK (3 << 24)
#define BXT_PORTA_HOTPLUG_NO_DETECT (0 << 24)
#define BXT_PORTA_HOTPLUG_SHORT_DETECT(1 << 24)
#define BXT_PORTA_HOTPLUG_LONG_DETECT (2 << 24)
-#define PORTD_HOTPLUG_ENABLE(1 << 20)
-#define PORTD_PULSE_DURATION_2ms(0)
-#define PORTD_PULSE_DURATION_4_5ms (1 << 18)
-#define PORTD_PULSE_DURATION_6ms(2 << 18)
-#define PORTD_PULSE_DURATION_100ms (3 << 18)
-#define PORTD_PULSE_DURATION_MASK (3 << 18)
-#define PORTD_HOTPLUG_STATUS_MASK (0x3 << 16)
+#define PORTD_HOTPLUG_ENABLE (1 << 20)
+#define PORTD_PULSE_DURATION_2ms (0 << 18)
+#define PORTD_PULSE_DURATION_4_5ms(1 << 18)
+#define PORTD_PULSE_DURATION_6ms (2 << 18)
+#define PORTD_PULSE_DURATION_100ms(3 << 18)
+#define PORTD_PULSE_DURATION_MASK (3 << 18)
+#define PORTD_HOTPLUG_STATUS_MASK (3 << 16)
#define PORTD_HOTPLUG_NO_DETECT (0 << 16)
#define PORTD_HOTPLUG_SHORT_DETECT(1 << 16)
#define PORTD_HOTPLUG_LONG_DETECT (2 << 16)
-#define PORTC_HOTPLUG_ENABLE(1 << 12)
-#define PORTC_PULSE_DURATION_2ms(0)
-#define PORTC_PULSE_DURATION_4_5ms (1 << 10)
-#define PORTC_PULSE_DURATION_6ms(2 << 10)
-#define PORTC_PULSE_DURATION_100ms (3 << 10)
-#define PORTC_PULSE_DURATION_MASK (3 << 10)
-#define PORTC_HOTPLUG_STATUS_MASK (0x3 << 8)
+#define PORTC_HOTPLUG_ENABLE (1 << 12)
+#define PORTC_PULSE_DURATION_2ms (0 << 10)
+#define PORTC_PULSE_DURATION_4_5ms(1 << 10)
+#define PORTC_PULSE_DURATION_6ms (2 << 10)
+#define PORTC_PULSE_DURATION_100ms(3 << 10)
+#define PORTC_PULSE_DURATION_MASK (3 << 10)
+#define PORTC_HOTPLUG_STATUS_MASK (3 << 8)
#define PORTC_HOTPLUG_NO_DETECT (0 << 8)
#define PORTC_HOTPLUG_SHORT_DETECT(1 << 8)
#define PORTC_HOTPLUG_LONG_DETECT (2 << 8)
-#define PORTB_HOTPLUG_ENABLE(1 << 4)
-#define PORTB_PULSE_DURATION_2ms(0)
-#define PORTB_PULSE_DURATION_4_5ms (1 << 2)
-#define PORTB_PULSE_DURATION_6ms(2 << 2)
-#define PORTB_PULSE_DURATION_100ms (3 << 2)
-#define PORTB_PULSE_DURATION_MASK (3 << 2)
-#define PORTB_HOTPLUG_STATUS_MASK (0x3 << 0)
+#define PORTB_HOTPLUG_ENABLE (1 << 4)
+#define PORTB_PULSE_DURATION_2ms (0 << 2)
+#define PORTB_PULSE_DURATION_4_5ms(1 << 2)
+#define PORTB_PULSE_DURATION_6ms (2 << 2)
+#define PORTB_PULSE_DURATION_100ms(3 << 2)
+#define PORTB_PULSE_DURATION_MASK (3 << 2)
+#define PORTB_HOTPLUG_STATUS_MASK (3 << 0)
#define PORTB_HOTPLUG_NO_DETECT (0 << 0)
#define PORTB_HOTPLUG_SHORT_DETECT(1 << 0)
#define PORTB_HOTPLUG_LONG_DETECT (2 << 0)
-#define PCH_PORT_HOTPLUG20xc403C /* SHOTPLUG_CTL2 */
-#define PORTE_HOTPLUG_ENABLE(1 << 4)
-#define PORTE_HOTPLUG_STATUS_MASK (0x3 << 0)
+#define PCH_PORT_H
Re: [Intel-gfx] [PATCH v1 2/2] drm/i915/gen9: Disable gather at set shader bit
On 11/08/15 15:44, Arun Siluvery wrote: From Gen9, Push constant instruction parsing behaviour varies according to whether set shader is enabled or not. If we want legacy behaviour then it can be achieved by disabling set shader. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959 Cc: Ben Widawsky Cc: Joonas Lahtinen Cc: Mika Kuoppala Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 5 + drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++ 2 files changed, 15 insertions(+) [snip] diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index cf61262..7d284ed 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -983,6 +983,16 @@ static int gen9_init_workarounds(struct intel_engine_cs *ring) tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE; WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp); + /* Chicken bits to disable set shader is in multiple places, +* set bits in all required registers to disable it correctly +*/ + WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2, GEN9_DISABLE_GATHER_SET_SHADER_SLICE); + if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_D0) || + (IS_BROXTON(dev) && INTEL_REVID(dev) == BXT_REVID_A0)) + WA_SET_BIT_MASKED(RS_CHICKEN, RS_CHICKEN_DISABLE_GATHER_AT_SHADER); + else + WA_SET_BIT_MASKED(CS_RCS_BE, CS_RCS_DISABLE_GATHER_AT_SHADER); + return 0; } This workaround isn't tagged with a specific /* WaXyz:chip */ comment. Also, the style isn't consistent with the other paragraphs earlier in this function: those have braces round the body part even when there's only one line of code, possibly to make it clear where the WA comment applies (of course, this is why the buggy WA_REG() macro wasn't spotted earlier). So, maybe prettify this a bit, if possible? The code actually looks correct, just ugly. Oh, and keep patch 1 even if you decide to abandon this one! .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 1/2] drm/i915: Contain the WA_REG macro
On 11/08/15 15:44, Arun Siluvery wrote:
From: Mika Kuoppala
Prevent leaking the if scoping by containing the WA_REG
macro inside its own scope.
Reported-by: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1c14233..cf61262 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -780,11 +780,11 @@ static int wa_add(struct drm_i915_private *dev_priv,
return 0;
}
-#define WA_REG(addr, mask, val) { \
+#define WA_REG(addr, mask, val) do { \
const int r = wa_add(dev_priv, (addr), (mask), (val)); \
if (r) \
return r; \
- }
+ } while(0)
#define WA_SET_BIT_MASKED(addr, mask) \
WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
On the one hand, yes, this definitely needs the do-while wrapper.
OTOH, hiding a conditional 'return' inside a macro is an abomination :(
At least it's only local to this file ...
So, on the grounds that this makes it more correct if no less ugly:
Reviewed-by: Dave Gordon
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in modeset
Hi Daniel, > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of > Daniel Vetter > Sent: Wednesday, August 12, 2015 9:43 PM > To: Jani Nikula > Cc: Daniel Vetter; Yang, Libin; alsa-de...@alsa-project.org; > ti...@suse.de; intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch > Subject: Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in > modeset > > On Wed, Aug 12, 2015 at 04:23:12PM +0300, Jani Nikula wrote: > > On Wed, 12 Aug 2015, Daniel Vetter wrote: > > > On Wed, Aug 12, 2015 at 09:20:17AM +0300, Jani Nikula wrote: > > >> On Wed, 12 Aug 2015, "Yang, Libin" wrote: > > >> > Hi Jani, > > >> > > > >> >> -Original Message- > > >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > > >> >> Sent: Tuesday, August 11, 2015 4:14 PM > > >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; > intel- > > >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > > >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper > N/CTS in > > >> >> modeset > > >> >> > > >> >> On Tue, 11 Aug 2015, "Yang, Libin" > wrote: > > >> >> > Hi Jani, > > >> >> > > > >> >> >> -Original Message- > > >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > > >> >> >> Sent: Tuesday, August 11, 2015 3:14 PM > > >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; > intel- > > >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > > >> >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper > N/CTS in > > >> >> >> modeset > > >> >> >> > > >> >> >> On Tue, 11 Aug 2015, "Yang, Libin" > wrote: > > >> >> >> > Hi Jani, > > >> >> >> > > > >> >> >> > Thanks for careful reviewing for all the patches, please > > >> >> >> > see my comments. > > >> >> >> > > > >> >> >> >> -Original Message- > > >> >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > > >> >> >> >> Sent: Monday, August 10, 2015 8:10 PM > > >> >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; > ti...@suse.de; intel- > > >> >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > > >> >> >> >> Subject: Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set > proper N/CTS > > >> >> in > > >> >> >> >> modeset > > >> >> >> >> > > >> >> >> >> On Mon, 10 Aug 2015, libin.y...@intel.com wrote: > > >> >> >> >> > From: Libin Yang > > >> >> >> >> > > > >> >> >> >> > When modeset occurs and the TMDS frequency is set > to some > > >> >> >> >> > speical value, the N/CTS need to be set manually if > audio > > >> >> >> >> > is playing. > > >> >> >> >> > > >> >> >> >> When modeset occurs, we disable everything, and then > re-enable > > >> >> >> >> everything, and notify the audio driver every step of the > way. IIUC > > >> >> >> >> there should be no audio playing across the modeset, > and when > > >> >> the > > >> >> >> >> modeset is complete and we've set the valid ELD, the > audio driver > > >> >> >> >> should > > >> >> >> >> call the callback from the earlier patches to set the > correct audio > > >> >> >> >> rate. > > >> >> >> >> > > >> >> >> >> Why is this patch needed? Please enlighten me. > > >> >> >> > > > >> >> >> > Please image this scenario: when audio is playing, the gfx > driver > > >> >> >> > does the modeset. In this situation, after modeset, audio > driver > > >> >> >> > will do nothing and continue playing. And audio driver will > not call > > >> >> >> > set_ncts. > > >> >> >> > > >> >> >> Why does the audio driver not do anything here? Whenever > there's > > >> >> a > > >> >> >> modeset, the graphics driver will disable audio and > invalidate the > > >> >> ELD, > > >> >> >> which should cause an interrupt to notify the audio driver > about > > >> >> >> this. This is no different from a hot-unplug, in fact I can't see > how > > >> >> >> the audio driver could even detect whether there's been a > hotplug > > >> >> or > > >> >> >> not > > >> >> >> when there's a codec disable/enable. > > >> >> > > > >> >> > Yes, it will trigger an interrupt to audio driver when unplug > > >> >> > and another interrupt for hotplug. But from audio driver, > > >> >> > we will not stop the playing and resume the playing based > > >> >> > on the hotplug or modeset. The audio is always playing > during > > >> >> > the hotplug/modeset. > > >> >> > > >> >> But the whole display, and consequently ELD, might have > changed > > >> >> during > > >> >> the hotplug, why do you assume you can just keep playing?! > The > > >> >> display > > >> >> might even have changed from HDMI to DP or vice versa. > > >> > > > >> > The eld info changing will not impact the audio playing. > > >> > Actually, you can image the monitor as a digital speaker, just > > >> > like the headphone to the analog audio. Unplug the speaker > > >> > will not impact on the audio playing. Of course , there is a > > >> > little difference, when monitor hotplug, in the interrupt, > > >> > we may change the codec configuration dynamically. > > >> > > > >> > And audio driver supply th
Re: [Intel-gfx] [PATCH 02/21] drm/i915/gtt: Workaround for HW preload not flushing pdps
On 12/08/15 08:56, Thierry, Michel wrote: On 8/11/2015 1:05 PM, Zhiyuan Lv wrote: Hi Mika/Dave/Michel, I saw the patch of using LRI for root pointer update has been merged to drm-intel. When we consider i915 driver to run inside a virtual machine, e.g. with XenGT, we may still need Mika's this patch like below: " if (intel_vgpu_active(ppgtt->base.dev)) gen8_preallocate_top_level_pdps(ppgtt); " Could you share with us your opinion? Thanks in advance! Hi Zhiyuan, The change looks ok to me. If you need to preallocate the PDPs, gen8_ppgtt_init is the right place to do it. Only add a similar vgpu_active check to disable the LRI updates (in gen8_emit_bb_start). The reason behind is that LRI command will make shadow PPGTT implementation hard. In XenGT, we construct shadow page table for each PPGTT in guest i915 driver, and then track every guest page table change in order to update shadow page table accordingly. The problem of page table updates with GPU command is that they cannot be trapped by hypervisor to finish the shadow page table update work. In XenGT, the only change we have is the command scan in context submission. But that is not exactly the right time to do shadow page table update. Mika's patch can address the problem nicely. With the preallocation, the root pointers in EXECLIST context will always keep the same. Then we can treat any attempt to change guest PPGTT with GPU commands as malicious behavior. Thanks! Regards, -Zhiyuan The bad thing that was happening if we didn't use LRIs was that the CPU would try to push the new mappings to the GPU by updating PDP registers in the saved context image. This is unsafe if the context is running, as switching away from it would result in the CPU-updated values being overwritten by the older values in the GPU h/w registers (if the context were known to be idle, then it would be safe). Preallocating the top-level PDPs should mean that the values need never change, so there's then no need to update the context image, thus avoiding the write hazard :) .Dave. On Thu, Jun 11, 2015 at 04:57:42PM +0300, Mika Kuoppala wrote: Dave Gordon writes: On 10/06/15 12:42, Michel Thierry wrote: On 5/29/2015 1:53 PM, Michel Thierry wrote: On 5/29/2015 12:05 PM, Michel Thierry wrote: On 5/22/2015 6:04 PM, Mika Kuoppala wrote: With BDW/SKL and 32bit addressing mode only, the hardware preloads pdps. However the TLB invalidation only has effect on levels below the pdps. This means that if pdps change, hw might access with stale pdp entry. To combat this problem, preallocate the top pdps so that hw sees them as immutable for each context. Cc: Ville Syrjälä Cc: Rafael Barbalho Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 50 + drivers/gpu/drm/i915/i915_reg.h | 17 + drivers/gpu/drm/i915/intel_lrc.c| 15 +-- 3 files changed, 68 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 0ffd459..1a5ad4c 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -941,6 +941,48 @@ err_out: return ret; } +/* With some architectures and 32bit legacy mode, hardware pre-loads + * the top level pdps but the tlb invalidation only invalidates the + * lower levels. + * This might lead to hw fetching with stale pdp entries if top level + * structure changes, ie va space grows with dynamic page tables. + */ Is this still necessary if we reload PDPs via LRI instructions whenever the address map has changed? That always (AFAICT) causes sufficient invalidation, so then we might not need to preallocate at all :) LRI reload gets my vote. Please ignore this patch. -Mika .Dave. ___ 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 0/9 v6] Batch submission via GuC
On 12/08/15 15:43, Dave Gordon wrote: This patch series enables command submission via the GuC. In this mode, instead of the host CPU driving the execlist port directly, it hands over work items to the GuC, using a doorbell mechanism to tell the GuC that new items have been added to its work queue. The GuC then dispatches contexts to the various GPU engines, and manages the resulting context- switch interrupts. Completion of a batch is however still signalled to the CPU; the GuC is not involved in handling user interrupts. There are two subsequences within the patch series: drm/i915: GuC-specific firmware loader drm/i915: Debugfs interface to read GuC load status These two patches provide the GuC loader and a debugfs interface to verify the resulting state. At this point in the sequence we can load and activate the GuC firmware, but not submit any batches through it. (This is nonetheless a potentially useful state, as the GuC could do other useful work even when not handling batch submissions). drm/i915: Expose one LRC function for GuC submission mode drm/i915: Prepare for GuC-based command submission drm/i915: Enable GuC firmware log drm/i915: Implementation of GuC submission client drm/i915: Interrupt routing for GuC submission drm/i915: Integrate GuC-based command submission drm/i915: Debugfs interface for GuC submission statistics In this second section, we implement the GuC submission mechanism, and link it into the (execlist-based) submission path. At this stage, it is not yet enabled by default; it is activated only if the kernel command line explicitly switches it on. The GuC firmware itself is not included in this patchset; it is or will be available for download from https://01.org/linuxgraphics/downloads/ This driver works with and requires GuC firmware revision 3.x. It will not work with any firmware version 1.x, as the GuC protocol in those revisions was incompatible and is no longer supported. On platforms where there is no GuC, or where GuC submission is not specifically enabled, batch submission will continue to use the execlist (or ringbuffer) mechanisms. On the other hand, if GuC submission is requested but the GuC firmware cannot be found or is invalid, the GPU will be unusable. It is expected that a subsequent patch will enable GuC submission by default once the signed firmware is published on 01.org. Ben Widawsky (0): Vinit Azad (0): Michael H. Nguyen (0): created the original versions on which some of these patches are based. Alex Dai (5): drm/i915: GuC-specific firmware loader drm/i915: Debugfs interface to read GuC load status drm/i915: Prepare for GuC-based command submission drm/i915: Enable GuC firmware log drm/i915: Integrate GuC-based command submission Dave Gordon (4): drm/i915: Expose one LRC function for GuC submission mode drm/i915: Implementation of GuC submission client drm/i915: Interrupt routing for GuC submission drm/i915: Debugfs interface for GuC submission statistics Documentation/DocBook/drm.tmpl | 14 + drivers/gpu/drm/i915/Makefile | 4 + drivers/gpu/drm/i915/i915_debugfs.c| 146 - drivers/gpu/drm/i915/i915_dma.c| 9 + drivers/gpu/drm/i915/i915_drv.h| 11 + drivers/gpu/drm/i915/i915_gem.c| 16 + drivers/gpu/drm/i915/i915_gpu_error.c | 14 +- drivers/gpu/drm/i915/i915_guc_reg.h| 17 +- drivers/gpu/drm/i915/i915_guc_submission.c | 901 + drivers/gpu/drm/i915/i915_reg.h| 15 +- drivers/gpu/drm/i915/intel_guc.h | 122 drivers/gpu/drm/i915/intel_guc_fwif.h | 9 +- drivers/gpu/drm/i915/intel_guc_loader.c| 611 +++ drivers/gpu/drm/i915/intel_lrc.c | 65 ++- drivers/gpu/drm/i915/intel_lrc.h | 8 + 15 files changed, 1918 insertions(+), 44 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c create mode 100644 drivers/gpu/drm/i915/intel_guc.h create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c Tom O'Rourke has already R-B'ed the previous [v5] versions of these, and there are no substantive changes to patches 2, 3, 4, 5, 7 and 8, so we can carry that over; also, the change in patch 1 is just an update to a comment noted in Tom's earlier reviews as being out-of-date. I haven't included patch 10 (enable-by-default) as we've decided to wait until the signed firmware is publicly available on 01.org before making it the default. So, it's really just patches 6/9 and 9/9 that need a re-review from Tom. Thanks, .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts callback
Hi Jani,
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Wednesday, August 12, 2015 10:45 PM
> To: Yang, Libin; Daniel Vetter
> Cc: alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: RE: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts
> callback
>
> On Wed, 12 Aug 2015, "Yang, Libin" wrote:
> > Hi Daniel,
> >
> >> -Original Message-
> >> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> >> Daniel Vetter
> >> Sent: Wednesday, August 12, 2015 9:06 PM
> >> To: Jani Nikula
> >> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> >> Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement
> set_ncts
> >> callback
> >>
> >> On Mon, Aug 10, 2015 at 03:16:46PM +0300, Jani Nikula wrote:
> >> > On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> >> > > From: Libin Yang
> >> > >
> >> > > Display audio may not work at some frequencies
> >> > > with the HW provided N/CTS.
> >> > >
> >> > > This patch sets the proper N value for the
> >> > > given audio sample rate at the impacted frequencies.
> >> > > At other frequencies, it will use the N/CTS value
> >> > > which HW provides.
> >> > >
> >> > > Signed-off-by: Libin Yang
> >> > > ---
> >> > > drivers/gpu/drm/i915/i915_reg.h| 2 +
> >> > > drivers/gpu/drm/i915/intel_audio.c | 95
> >> ++
> >> > > 2 files changed, 97 insertions(+)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> > > index ea46d68..da2d128 100644
> >> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> >> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> > > @@ -7014,6 +7014,8 @@ enum skl_disp_power_wells {
> >> > >_HSW_AUD_MISC_CTRL_A, \
> >> > >_HSW_AUD_MISC_CTRL_B)
> >> > >
> >> > > +#define HSW_AUD_PIPE_CONN_SEL_CTRL 0x650ac
> >> > > +
> >> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_A0x650b4
> >> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_B0x651b4
> >> > > #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
> >> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> >> b/drivers/gpu/drm/i915/intel_audio.c
> >> > > index dc32cf4..eddf37f 100644
> >> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> >> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> >> > > @@ -68,6 +68,30 @@ static const struct {
> >> > >{ 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> >> > > };
> >> > >
> >> > > +#define TMDS_297M 297000
> >> > > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
> >> > > +static const struct {
> >> > > + int sample_rate;
> >> > > + int clock;
> >> > > + int n;
> >> > > + int cts;
> >> > > +} aud_ncts[] = {
> >> > > + { 44100, TMDS_296M, 4459, 234375 },
> >> > > + { 44100, TMDS_297M, 4704, 247500 },
> >> > > + { 48000, TMDS_296M, 5824, 281250 },
> >> > > + { 48000, TMDS_297M, 5120, 247500 },
> >> > > + { 32000, TMDS_296M, 5824, 421875 },
> >> > > + { 32000, TMDS_297M, 3072, 222750 },
> >> > > + { 88200, TMDS_296M, 8918, 234375 },
> >> > > + { 88200, TMDS_297M, 9408, 247500 },
> >> > > + { 96000, TMDS_296M, 11648, 281250 },
> >> > > + { 96000, TMDS_297M, 10240, 247500 },
> >> > > + { 176400, TMDS_296M, 17836, 234375 },
> >> > > + { 176400, TMDS_297M, 18816, 247500 },
> >> > > + { 44100, TMDS_296M, 23296, 281250 },
> >> > > + { 44100, TMDS_297M, 20480, 247500 },
> >> > > +};
> >> > > +
> >> > > /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> >> > > static u32 audio_config_hdmi_pixel_clock(struct
> >> drm_display_mode *mode)
> >> > > {
> >> > > @@ -514,12 +538,83 @@ static int
> >> i915_audio_component_get_cdclk_freq(struct device *dev)
> >> > >return ret;
> >> > > }
> >> > >
> >> > > +static int i915_audio_component_set_ncts(struct device *dev,
> int
> >> port,
> >> > > + int dev_entry, int rate)
> >> > > +{
> >> > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> >> > > + struct drm_device *drm_dev = dev_priv->dev;
> >> > > + struct intel_encoder *intel_encoder;
> >> > > + struct intel_digital_port *intel_dig_port;
> >> > > + struct intel_crtc *crtc;
> >> > > + struct drm_display_mode *mode;
> >> > > + enum pipe pipe = -1;
> >> > > + u32 tmp;
> >> > > + int i;
> >> > > + int n_low, n_up, n = 0;
> >> >
> >> > I think you'll need the power well get here, and put at the end. Or
> >> > check that we it.
> >>
> >> If we call this and end up actually dropping the power well then the
> >> register writes will go exactly nowhere at all. Which indicates a bug
> in
> >> how this is orchestrated. There is probably one ...
> >
> > Sorry, I'm not understanding your meaning clearly.
> > Do you mean if we put the power well, the register's
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Commit planes on each crtc separately.
For both patches,
Reviewed-by: Ander Conselvan de Oliveira
On Tue, 2015-08-11 at 12:31 +0200, Maarten Lankhorst wrote:
> This patch is based on the upstream commit 5ac1c4bcf073ad and amended
> for v4.2 to make sure it works as intended.
>
> Repeated calls to begin_crtc_commit can cause warnings like this:
> [ 169.127746] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:616
> [ 169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip
> [ 169.127840] 3 locks held by kms_flip/1947:
> [ 169.127843] #0: (&dev->mode_config.mutex){+.+.+.}, at:
> []
> __drm_modeset_lock_all+0x9c/0x130
> [ 169.127860] #1: (crtc_ww_class_acquire){+.+.+.}, at:
> []
> __drm_modeset_lock_all+0xad/0x130
> [ 169.127870] #2: (crtc_ww_class_mutex){+.+.+.}, at: []
> drm_modeset_lock+0x38/0x110
> [ 169.127879] irq event stamp: 665690
> [ 169.127882] hardirqs last enabled at (665689): []
> _raw_spin_unlock_irqrestore+0x55/0x70
> [ 169.127889] hardirqs last disabled at (665690): []
> intel_pipe_update_start+0x113/0x5c0 [i915]
> [ 169.127936] softirqs last enabled at (665470): []
> __do_softirq+0x236/0x650
> [ 169.127942] softirqs last disabled at (665465): []
> irq_exit+0xc5/0xd0
> [ 169.127951] CPU: 1 PID: 1947 Comm: kms_flip Not tainted 4.1.0-rc4-patser+
> #4039
> [ 169.127954] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 )
> 04/15/2014
> [ 169.127957] 8800c49036f0 8800cde5fa28 817f6907
> 8001
> [ 169.127964] 8800cde5fa58 810aebed
> 0046
> [ 169.127970] 81c5d518 0268
> 8800cde5fa88
> [ 169.127981] Call Trace:
> [ 169.127992] [] dump_stack+0x4f/0x7b
> [ 169.128001] [] ___might_sleep+0x16d/0x270
> [ 169.128008] [] __might_sleep+0x48/0x90
> [ 169.128017] [] mutex_lock_nested+0x29/0x410
> [ 169.128073] [] ? vgpu_write64+0x220/0x220 [i915]
> [ 169.128138] [] ?
> ironlake_update_primary_plane+0x2ff/0x410 [i915]
> [ 169.128198] [] intel_frontbuffer_flush+0x25/0x70 [i915]
> [ 169.128253] [] intel_finish_crtc_commit+0x4c/0x180
> [i915]
> [ 169.128279] []
> drm_atomic_helper_commit_planes+0x12c/0x240 [drm_kms_helper]
> [ 169.128338] [] __intel_set_mode+0x684/0x830 [i915]
> [ 169.128378] [] intel_crtc_set_config+0x49a/0x620 [i915]
> [ 169.128385] [] ? mutex_unlock+0x9/0x10
> [ 169.128391] [] drm_mode_set_config_internal+0x69/0x120
> [ 169.128398] [] ? might_fault+0x57/0xb0
> [ 169.128403] [] drm_mode_setcrtc+0x253/0x620
> [ 169.128409] [] drm_ioctl+0x1a0/0x6a0
> [ 169.128415] [] ? get_parent_ip+0x11/0x50
> [ 169.128424] [] do_vfs_ioctl+0x2f8/0x530
> [ 169.128429] [] ? trace_hardirqs_on+0xd/0x10
> [ 169.128435] [] ? selinux_file_ioctl+0x56/0x100
> [ 169.128439] [] SyS_ioctl+0x81/0xa0
> [ 169.128445] [] system_call_fastpath+0x12/0x6f
>
> Solve it by using the newly introduced
> drm_atomic_helper_commit_planes_on_crtc.
>
> The problem here was that the drm_atomic_helper_commit_planes() helper
> we were using was basically designed to do
>
> begin_crtc_commit(crtc #1)
> begin_crtc_commit(crtc #2)
> ...
> commit all planes
> finish_crtc_commit(crtc #1)
> finish_crtc_commit(crtc #2)
>
> The problem here is that since our hardware relies on vblank evasion,
> our CRTC 'begin' function waits until we're out of the danger zone in
> which register writes might wind up straddling the vblank, then disables
> interrupts; our 'finish' function re-enables interrupts after the
> registers have been written. The expectation is that the operations between
> 'begin' and 'end' must be performed without sleeping (since interrupts
> are disabled) and should happen as quickly as possible. By clumping all
> of the 'begin' calls together, we introducing a couple problems:
> * Subsequent 'begin' invocations might sleep (which is illegal)
> * The first 'begin' ensured that we were far enough from the vblank that
>we could write our registers safely and ensure they all fell within
>the same frame. Adding extra delay waiting for subsequent CRTC's
>wasn't accounted for and could put us back into the 'danger zone' for
>CRTC #1.
>
> This commit solves the problem by using a new helper that allows an
> order of operations like:
>
>for each crtc {
> begin_crtc_commit(crtc) // sleep (maybe), then disable interrupts
> commit planes for this specific CRTC
> end_crtc_commit(crtc)// reenable interrupts
>}
>
> so that sleeps will only be performed while interrupts are enabled and
> we can be sure that registers for a CRTC will be written immediately
> once we know we're in the safe zone.
>
> The crtc->config->base.crtc update may seem unrelated, but the helper
> will use it to obtain the crtc for the state. Without the update it
> will dereference NULL and crash.
>
> Changes since v1:
> - Use Matt Roper's commit message.
>
> Signed-off-by: M
[Intel-gfx] [PATCH 1/9 v6] drm/i915: GuC-specific firmware loader
From: Alex Dai
This fetches the required firmware image from the filesystem,
then loads it into the GuC's memory via a dedicated DMA engine.
This patch is derived from GuC loading work originally done by
Vinit Azad and Ben Widawsky.
v2:
Various improvements per review comments by Chris Wilson
v3:
Removed 'wait' parameter to intel_guc_ucode_load() as firmware
prefetch is no longer supported in the common firmware loader,
per Daniel Vetter's request.
Firmware checker callback fn now returns errno rather than bool.
v4:
Squash uC-independent code into GuC-specifc loader [Daniel Vetter]
Don't keep the driver working (by falling back to execlist mode)
if GuC firmware loading fails [Daniel Vetter]
v5:
Clarify WOPCM-related #defines [Tom O'Rourke]
Delete obsolete code no longer required with current h/w & f/w
[Tom O'Rourke]
Move the call to intel_guc_ucode_init() later, so that it can
allocate GEM objects, and have it fetch the firmware; then
intel_guc_ucode_load() doesn't need to fetch it later.
[Daniel Vetter].
v6:
Update comment describing intel_guc_ucode_load() [Tom O'Rourke]
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/i915_dma.c | 9 +
drivers/gpu/drm/i915/i915_drv.h | 11 +
drivers/gpu/drm/i915/i915_gem.c | 16 +
drivers/gpu/drm/i915/i915_guc_reg.h | 17 +-
drivers/gpu/drm/i915/i915_reg.h | 4 +-
drivers/gpu/drm/i915/intel_guc.h| 67
drivers/gpu/drm/i915/intel_guc_fwif.h | 3 +-
drivers/gpu/drm/i915/intel_guc_loader.c | 529
9 files changed, 650 insertions(+), 9 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_guc.h
create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 998b464..65e52fa 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -40,6 +40,9 @@ i915-y += i915_cmd_parser.o \
intel_ringbuffer.o \
intel_uncore.o
+# general-purpose microcontroller (GuC) support
+i915-y += intel_guc_loader.o
+
# autogenerated null render state
i915-y += intel_renderstate_gen6.o \
intel_renderstate_gen7.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ab37d11..2193cc2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -435,6 +435,11 @@ static int i915_load_modeset_init(struct drm_device *dev)
* working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
+ /* intel_guc_ucode_init() needs the mutex to allocate GEM objects */
+ mutex_lock(&dev->struct_mutex);
+ intel_guc_ucode_init(dev);
+ mutex_unlock(&dev->struct_mutex);
+
ret = i915_gem_init(dev);
if (ret)
goto cleanup_irq;
@@ -476,6 +481,9 @@ cleanup_gem:
i915_gem_context_fini(dev);
mutex_unlock(&dev->struct_mutex);
cleanup_irq:
+ mutex_lock(&dev->struct_mutex);
+ intel_guc_ucode_fini(dev);
+ mutex_unlock(&dev->struct_mutex);
drm_irq_uninstall(dev);
cleanup_gem_stolen:
i915_gem_cleanup_stolen(dev);
@@ -1128,6 +1136,7 @@ int i915_driver_unload(struct drm_device *dev)
flush_workqueue(dev_priv->wq);
mutex_lock(&dev->struct_mutex);
+ intel_guc_ucode_fini(dev);
i915_gem_cleanup_ringbuffer(dev);
i915_gem_context_fini(dev);
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 674b223..0c0125c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include
#include
#include
+#include "intel_guc.h"
/* General customization:
*/
@@ -1706,6 +1707,8 @@ struct drm_i915_private {
struct i915_virtual_gpu vgpu;
+ struct intel_guc guc;
+
struct intel_csr csr;
/* Display CSR-related protection */
@@ -1950,6 +1953,11 @@ static inline struct drm_i915_private
*dev_to_i915(struct device *dev)
return to_i915(dev_get_drvdata(dev));
}
+static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+{
+ return container_of(guc, struct drm_i915_private, guc);
+}
+
/* Iterate over initialised rings */
#define for_each_ring(ring__, dev_priv__, i__) \
for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
@@ -2554,6 +2562,9 @@ struct drm_i915_cmd_table {
#define HAS_CSR(dev) (IS_SKYLAKE(dev))
+#define HAS_GUC_UCODE(dev) (IS_GEN9(dev))
+#define HAS_GUC_SCHED(dev) (IS_GEN9(dev))
+
#define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1c5
[Intel-gfx] [PATCH 6/9 v6] drm/i915: Implementation of GuC submission client
A GuC client has its own doorbell and workqueue. It maintains the
doorbell cache line, process description object and work queue item.
A default guc_client is created for the i915 driver to use for
normal-priority in-order submission.
Note that the created client is not yet ready for use; doorbell
allocation will fail as we haven't yet linked the GuC's context
descriptor to the default contexts for each ring (see later patch).
v2:
Defer adding structure members until needed [Chris Wilson]
Rationalise type declarations [Chris Wilson]
v5:
Add GuC per-engine submission & seqno statistics.
Move wq locking to encompass both get_space() and add_item().
Take forcewake lock in host2guc_action() [Tom O'Rourke]
v6:
Fix GuC doorbell cacheline selection code (the
cacheline-within-page calculation was wrong).
Rename GuC priorities to make them closer to the names used in
the GuC firmware source, matching what the autogenerated
versions will (probably) be.
Add per-ring statistics to client.
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 666 +
drivers/gpu/drm/i915/intel_guc.h | 46 ++
drivers/gpu/drm/i915/intel_guc_fwif.h | 6 +-
drivers/gpu/drm/i915/intel_guc_loader.c| 10 +
4 files changed, 725 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 669c889..3352b85 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -27,6 +27,529 @@
#include "intel_guc.h"
/**
+ * DOC: GuC Client
+ *
+ * i915_guc_client:
+ * We use the term client to avoid confusion with contexts. A i915_guc_client
is
+ * equivalent to GuC object guc_context_desc. This context descriptor is
+ * allocated from a pool of 1024 entries. Kernel driver will allocate doorbell
+ * and workqueue for it. Also the process descriptor (guc_process_desc), which
+ * is mapped to client space. So the client can write Work Item then ring the
+ * doorbell.
+ *
+ * To simplify the implementation, we allocate one gem object that contains all
+ * pages for doorbell, process descriptor and workqueue.
+ *
+ * The Scratch registers:
+ * There are 16 MMIO-based registers start from 0xC180. The kernel driver
writes
+ * a value to the action register (SOFT_SCRATCH_0) along with any data. It then
+ * triggers an interrupt on the GuC via another register write (0xC4C8).
+ * Firmware writes a success/fail code back to the action register after
+ * processes the request. The kernel driver polls waiting for this update and
+ * then proceeds.
+ * See host2guc_action()
+ *
+ * Doorbells:
+ * Doorbells are interrupts to uKernel. A doorbell is a single cache line (QW)
+ * mapped into process space.
+ *
+ * Work Items:
+ * There are several types of work items that the host may place into a
+ * workqueue, each with its own requirements and limitations. Currently only
+ * WQ_TYPE_INORDER is needed to support legacy submission via GuC, which
+ * represents in-order queue. The kernel driver packs ring tail pointer and an
+ * ELSP context descriptor dword into Work Item.
+ * See guc_add_workqueue_item()
+ *
+ */
+
+/*
+ * Read GuC command/status register (SOFT_SCRATCH_0)
+ * Return true if it contains a response rather than a command
+ */
+static inline bool host2guc_action_response(struct drm_i915_private *dev_priv,
+ u32 *status)
+{
+ u32 val = I915_READ(SOFT_SCRATCH(0));
+ *status = val;
+ return GUC2HOST_IS_RESPONSE(val);
+}
+
+static int host2guc_action(struct intel_guc *guc, u32 *data, u32 len)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ u32 status;
+ int i;
+ int ret;
+
+ if (WARN_ON(len < 1 || len > 15))
+ return -EINVAL;
+
+ intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+ spin_lock(&dev_priv->guc.host2guc_lock);
+
+ dev_priv->guc.action_count += 1;
+ dev_priv->guc.action_cmd = data[0];
+
+ for (i = 0; i < len; i++)
+ I915_WRITE(SOFT_SCRATCH(i), data[i]);
+
+ POSTING_READ(SOFT_SCRATCH(i - 1));
+
+ I915_WRITE(HOST2GUC_INTERRUPT, HOST2GUC_TRIGGER);
+
+ /* No HOST2GUC command should take longer than 10ms */
+ ret = wait_for_atomic(host2guc_action_response(dev_priv, &status), 10);
+ if (status != GUC2HOST_STATUS_SUCCESS) {
+ /*
+* Either the GuC explicitly returned an error (which
+* we convert to -EIO here) or no response at all was
+* received within the timeout limit (-ETIMEDOUT)
+*/
+ if (ret != -ETIMEDOUT)
+ ret = -EIO;
+
+ DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
+ "status=0x%08X response=0x%
[Intel-gfx] [PATCH 7/9 v6] drm/i915: Interrupt routing for GuC submission
Turn on interrupt steering to route necessary interrupts to GuC.
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
drivers/gpu/drm/i915/intel_guc_loader.c | 51 +
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d54dc2c..d4dfd06 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1674,6 +1674,7 @@ enum skl_disp_power_wells {
#define GFX_MODE_GEN7 0x0229c
#define RING_MODE_GEN7(ring) ((ring)->mmio_base+0x29c)
#define GFX_RUN_LIST_ENABLE (1<<15)
+#define GFX_INTERRUPT_STEERING (1<<14)
#define GFX_TLB_INVALIDATE_EXPLICIT (1<<13)
#define GFX_SURFACE_FAULT_ENABLE (1<<12)
#define GFX_REPLAY_MODE (1<<11)
@@ -1681,6 +1682,11 @@ enum skl_disp_power_wells {
#define GFX_PPGTT_ENABLE (1<<9)
#define GEN8_GFX_PPGTT_48B (1<<7)
+#define GFX_FORWARD_VBLANK_MASK (3<<5)
+#define GFX_FORWARD_VBLANK_NEVER (0<<5)
+#define GFX_FORWARD_VBLANK_ALWAYS(1<<5)
+#define GFX_FORWARD_VBLANK_COND (2<<5)
+
#define VLV_DISPLAY_BASE 0x18
#define VLV_MIPI_BASE VLV_DISPLAY_BASE
@@ -5694,11 +5700,12 @@ enum skl_disp_power_wells {
#define GEN8_GT_IIR(which) (0x44308 + (0x10 * (which)))
#define GEN8_GT_IER(which) (0x4430c + (0x10 * (which)))
-#define GEN8_BCS_IRQ_SHIFT 16
#define GEN8_RCS_IRQ_SHIFT 0
-#define GEN8_VCS2_IRQ_SHIFT 16
+#define GEN8_BCS_IRQ_SHIFT 16
#define GEN8_VCS1_IRQ_SHIFT 0
+#define GEN8_VCS2_IRQ_SHIFT 16
#define GEN8_VECS_IRQ_SHIFT 0
+#define GEN8_WD_IRQ_SHIFT 16
#define GEN8_DE_PIPE_ISR(pipe) (0x44400 + (0x10 * (pipe)))
#define GEN8_DE_PIPE_IMR(pipe) (0x44404 + (0x10 * (pipe)))
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 8b4b057..13e75f6 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -79,6 +79,53 @@ const char *intel_guc_fw_status_repr(enum
intel_guc_fw_status status)
}
};
+static void direct_interrupts_to_host(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *ring;
+ int i, irqs;
+
+ /* tell all command streamers NOT to forward interrupts and vblank to
GuC */
+ irqs = _MASKED_FIELD(GFX_FORWARD_VBLANK_MASK, GFX_FORWARD_VBLANK_NEVER);
+ irqs |= _MASKED_BIT_DISABLE(GFX_INTERRUPT_STEERING);
+ for_each_ring(ring, dev_priv, i)
+ I915_WRITE(RING_MODE_GEN7(ring), irqs);
+
+ /* tell DE to send nothing to GuC */
+ I915_WRITE(DE_GUCRMR, ~0);
+
+ /* route all GT interrupts to the host */
+ I915_WRITE(GUC_BCS_RCS_IER, 0);
+ I915_WRITE(GUC_VCS2_VCS1_IER, 0);
+ I915_WRITE(GUC_WD_VECS_IER, 0);
+}
+
+static void direct_interrupts_to_guc(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *ring;
+ int i, irqs;
+
+ /* tell all command streamers to forward interrupts and vblank to GuC */
+ irqs = _MASKED_FIELD(GFX_FORWARD_VBLANK_MASK,
GFX_FORWARD_VBLANK_ALWAYS);
+ irqs |= _MASKED_BIT_ENABLE(GFX_INTERRUPT_STEERING);
+ for_each_ring(ring, dev_priv, i)
+ I915_WRITE(RING_MODE_GEN7(ring), irqs);
+
+ /* tell DE to send (all) flip_done to GuC */
+ irqs = DERRMR_PIPEA_PRI_FLIP_DONE | DERRMR_PIPEA_SPR_FLIP_DONE |
+ DERRMR_PIPEB_PRI_FLIP_DONE | DERRMR_PIPEB_SPR_FLIP_DONE |
+ DERRMR_PIPEC_PRI_FLIP_DONE | DERRMR_PIPEC_SPR_FLIP_DONE;
+ /* Unmasked bits will cause GuC response message to be sent */
+ I915_WRITE(DE_GUCRMR, ~irqs);
+
+ /* route USER_INTERRUPT to Host, all others are sent to GuC. */
+ irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
+ GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
+ /* These three registers have the same bit definitions */
+ I915_WRITE(GUC_BCS_RCS_IER, ~irqs);
+ I915_WRITE(GUC_VCS2_VCS1_IER, ~irqs);
+ I915_WRITE(GUC_WD_VECS_IER, ~irqs);
+}
+
static u32 get_gttype(struct drm_i915_private *dev_priv)
{
/* XXX: GT type based on PCI device ID? field seems unused by fw */
@@ -342,6 +389,7 @@ int intel_guc_ucode_load(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+ direct_interrupts_to_host(dev_priv);
i915_guc_submission_disable(dev);
if (guc_fw->guc_fw_fetch_status == GUC_FIRMWARE_NONE)
@@ -395,6 +443,7 @@ int intel_guc_ucode_load(struct drm_device *dev)
err = i915_guc_submission_enable(dev);
if (err)
goto fail;
+ direct_interrupts_to_guc(dev_priv);
}
return 0;
@@ -403,6 +452,7 @@ fail:
if (guc_fw->guc_fw_load_status == GUC_FIRMWAR
[Intel-gfx] [PATCH 9/9 v6] drm/i915: Debugfs interface for GuC submission statistics
This provides a means of reading status and counts relating
to GuC actions and submissions.
v2:
Remove surplus blank line in output [Chris Wilson]
v5:
Added GuC per-engine submission & seqno statistics
v6:
Add per-ring statistics to client, refactor client-dumper.
Signed-off-by: Dave Gordon
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_debugfs.c | 76 +
1 file changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index cfddc9a..7a28de5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2412,6 +2412,81 @@ static int i915_guc_load_status_info(struct seq_file *m,
void *data)
return 0;
}
+static void i915_guc_client_info(struct seq_file *m,
+struct drm_i915_private *dev_priv,
+struct i915_guc_client *client)
+{
+ struct intel_engine_cs *ring;
+ uint64_t tot = 0;
+ uint32_t i;
+
+ seq_printf(m, "\tPriority %d, GuC ctx index: %u, PD offset 0x%x\n",
+ client->priority, client->ctx_index, client->proc_desc_offset);
+ seq_printf(m, "\tDoorbell id %d, offset: 0x%x, cookie 0x%x\n",
+ client->doorbell_id, client->doorbell_offset, client->cookie);
+ seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n",
+ client->wq_size, client->wq_offset, client->wq_tail);
+
+ seq_printf(m, "\tFailed to queue: %u\n", client->q_fail);
+ seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail);
+ seq_printf(m, "\tLast submission result: %d\n", client->retcode);
+
+ for_each_ring(ring, dev_priv, i) {
+ seq_printf(m, "\tSubmissions: %llu %s\n",
+ client->submissions[i],
+ ring->name);
+ tot += client->submissions[i];
+ }
+ seq_printf(m, "\tTotal: %llu\n", tot);
+}
+
+static int i915_guc_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_guc guc;
+ struct i915_guc_client client = { .client_obj = 0 };
+ struct intel_engine_cs *ring;
+ enum intel_ring_id i;
+ u64 total = 0;
+
+ if (!HAS_GUC_SCHED(dev_priv->dev))
+ return 0;
+
+ /* Take a local copy of the GuC data, so we can dump it at leisure */
+ spin_lock(&dev_priv->guc.host2guc_lock);
+ guc = dev_priv->guc;
+ if (guc.execbuf_client) {
+ spin_lock(&guc.execbuf_client->wq_lock);
+ client = *guc.execbuf_client;
+ spin_unlock(&guc.execbuf_client->wq_lock);
+ }
+ spin_unlock(&dev_priv->guc.host2guc_lock);
+
+ seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
+ seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
+ seq_printf(m, "GuC last action command: 0x%x\n", guc.action_cmd);
+ seq_printf(m, "GuC last action status: 0x%x\n", guc.action_status);
+ seq_printf(m, "GuC last action error code: %d\n", guc.action_err);
+
+ seq_printf(m, "\nGuC submissions:\n");
+ for_each_ring(ring, dev_priv, i) {
+ seq_printf(m, "\t%-24s: %10llu, last seqno 0x%08x %9d\n",
+ ring->name, guc.submissions[i],
+ guc.last_seqno[i], guc.last_seqno[i]);
+ total += guc.submissions[i];
+ }
+ seq_printf(m, "\t%s: %llu\n", "Total", total);
+
+ seq_printf(m, "\nGuC execbuf client @ %p:\n", guc.execbuf_client);
+ i915_guc_client_info(m, dev_priv, &client);
+
+ /* Add more as required ... */
+
+ return 0;
+}
+
static int i915_guc_log_dump(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5099,6 +5174,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS},
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
+ {"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
{"i915_frequency_info", i915_frequency_info, 0},
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9 v6] drm/i915: Prepare for GuC-based command submission
From: Alex Dai
This adds the first of the data structures used to communicate with the
GuC (the pool of guc_context structures).
We create a GuC-specific wrapper round the GEM object allocator as all
GEM objects shared with the GuC must be pinned into GGTT space at an
address that is NOT in the range [0..WOPCM_TOP), as that range of GGTT
addresses is not accessible to the GuC (from the GuC's point of view,
it's permanently reserved for other objects such as the BootROM & SRAM).
Later, we will need to allocate additional GuC-sharable objects for the
submission client(s) and the GuC's debug log.
v2:
Remove redundant initialisation [Chris Wilson]
Defer adding struct members until needed [Chris Wilson]
Local functions should pass dev_priv rather than dev [Chris Wilson]
v5:
Invalidate GuC TLB after allocating and pinning a new object
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 118 +
drivers/gpu/drm/i915/intel_guc.h | 7 ++
drivers/gpu/drm/i915/intel_guc_loader.c| 21 +
4 files changed, 148 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 65e52fa..44d290a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -41,7 +41,8 @@ i915-y += i915_cmd_parser.o \
intel_uncore.o
# general-purpose microcontroller (GuC) support
-i915-y += intel_guc_loader.o
+i915-y += intel_guc_loader.o \
+ i915_guc_submission.o
# autogenerated null render state
i915-y += intel_renderstate_gen6.o \
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
new file mode 100644
index 000..8ff59aa
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -0,0 +1,118 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+#include
+#include
+#include "i915_drv.h"
+#include "intel_guc.h"
+
+/**
+ * gem_allocate_guc_obj() - Allocate gem object for GuC usage
+ * @dev: drm device
+ * @size: size of object
+ *
+ * This is a wrapper to create a gem obj. In order to use it inside GuC, the
+ * object needs to be pinned lifetime. Also we must pin it to gtt space other
+ * than [0, GUC_WOPCM_TOP) because this range is reserved inside GuC.
+ *
+ * Return: A drm_i915_gem_object if successful, otherwise NULL.
+ */
+static struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device *dev,
+ u32 size)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *obj;
+
+ obj = i915_gem_alloc_object(dev, size);
+ if (!obj)
+ return NULL;
+
+ if (i915_gem_object_get_pages(obj)) {
+ drm_gem_object_unreference(&obj->base);
+ return NULL;
+ }
+
+ if (i915_gem_obj_ggtt_pin(obj, PAGE_SIZE,
+ PIN_OFFSET_BIAS | GUC_WOPCM_TOP)) {
+ drm_gem_object_unreference(&obj->base);
+ return NULL;
+ }
+
+ /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
+ I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+
+ return obj;
+}
+
+/**
+ * gem_release_guc_obj() - Release gem object allocated for GuC usage
+ * @obj: gem obj to be released
+ */
+static void gem_release_guc_obj(struct drm_i915_gem_object *obj)
+{
+ if (!obj)
+ return;
+
+ if (i915_gem_obj_is_pinned(obj))
+ i915_gem_object_ggtt_unpin(obj);
+
+ drm_gem_object_unreference(&obj->base);
+}
+
+/*
+ * Set up the memory resources to be shared with the GuC. At
[Intel-gfx] [PATCH 8/9 v6] drm/i915: Integrate GuC-based command submission
From: Alex Dai
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where the context being
dispatched would be added to the execlist queue; at this point
we submit the context to the GuC backend instead.
There are, however, a few other changes also required, notably:
1. Contexts must be pinned at GGTT addresses accessible by the GuC
i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the
PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls.
2. The GuC's TLB must be invalidated after a context is pinned at
a new GGTT address.
3. GuC firmware uses the one page before Ring Context as shared data.
Therefore, whenever driver wants to get base address of LRC, we
will offset one page for it. LRC_PPHWSP_PN is defined as the page
number of LRCA.
4. In the work queue used to pass requests to the GuC, the GuC
firmware requires the ring-tail-offset to be represented as an
11-bit value, expressed in QWords. Therefore, the ringbuffer
size must be reduced to the representable range (4 pages).
v2:
Defer adding #defines until needed [Chris Wilson]
Rationalise type declarations [Chris Wilson]
v4:
Squashed kerneldoc patch into here [Daniel Vetter]
v5:
Update request->tail in code common to both GuC and execlist modes.
Add a private version of lr_context_update(), as sharing the
execlist version leads to race conditions when the CPU and
the GuC both update TAIL in the context image.
Conversion of error-captured HWS page to string must account
for offset from start of object to actual HWS (LRC_PPHWSP_PN).
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
Documentation/DocBook/drm.tmpl | 14 ++
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 14 +++---
drivers/gpu/drm/i915/i915_guc_submission.c | 79 --
drivers/gpu/drm/i915/intel_guc.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 55 ++---
drivers/gpu/drm/i915/intel_lrc.h | 6 +++
7 files changed, 142 insertions(+), 29 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4111902..a01fca9 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4152,6 +4152,20 @@ int num_ioctls;
+ GuC-based Command Submission
+
+GuC
+!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
+!Idrivers/gpu/drm/i915/intel_guc_loader.c
+
+
+GuC Client
+!Pdrivers/gpu/drm/i915/intel_guc_submission.c GuC-based command submissison
+!Idrivers/gpu/drm/i915/intel_guc_submission.c
+
+
+
+
Tracing
This sections covers all things related to the tracepoints implemented in
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 529d2fd..cfddc9a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1995,7 +1995,7 @@ static void i915_dump_lrc_obj(struct seq_file *m,
return;
}
- page = i915_gem_object_get_page(ctx_obj, 1);
+ page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
if (!WARN_ON(page == NULL)) {
reg_state = kmap_atomic(page);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index f79c952..94012e7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -461,17 +461,17 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
}
if ((obj = error->ring[i].hws_page)) {
- err_printf(m, "%s --- HW Status = 0x%08x\n",
- dev_priv->ring[i].name,
- lower_32_bits(obj->gtt_offset));
+ err_printf(m, "%s --- HW Status = 0x%08llx\n",
+ dev_priv->ring[i].name,
+ obj->gtt_offset + LRC_PPHWSP_PN * PAGE_SIZE);
offset = 0;
for (elt = 0; elt < PAGE_SIZE/16; elt += 4) {
err_printf(m, "[%04x] %08x %08x %08x %08x\n",
offset,
- obj->pages[0][elt],
- obj->pages[0][elt+1],
- obj->pages[0][elt+2],
- obj->pages[0][elt+3]);
+ obj->pages[LRC_PPHWSP_PN][elt],
+ obj->pages[LRC_PPHWSP_PN][elt+1],
+ obj->pages[LRC_PPHWSP_PN][elt+2],
+ obj->pages[LRC_PPHWSP_PN][elt+3])
[Intel-gfx] [PATCH 2/9 v6] drm/i915: Debugfs interface to read GuC load status
From: Alex Dai
The new node provides access to the status of the GuC-specific loader;
also the scratch registers used for communication between the i915
driver and the GuC firmware.
v2:
Changes to output formats per Chris Wilson's suggestions
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 86734be..3609b13 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2374,6 +2374,44 @@ static int i915_llc(struct seq_file *m, void *data)
return 0;
}
+static int i915_guc_load_status_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_i915_private *dev_priv = node->minor->dev->dev_private;
+ struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
+ u32 tmp, i;
+
+ if (!HAS_GUC_UCODE(dev_priv->dev))
+ return 0;
+
+ seq_printf(m, "GuC firmware status:\n");
+ seq_printf(m, "\tpath: %s\n",
+ guc_fw->guc_fw_path);
+ seq_printf(m, "\tfetch: %s\n",
+ intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+ seq_printf(m, "\tload: %s\n",
+ intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+ seq_printf(m, "\tversion wanted: %d.%d\n",
+ guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+ seq_printf(m, "\tversion found: %d.%d\n",
+ guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+
+ tmp = I915_READ(GUC_STATUS);
+
+ seq_printf(m, "\nGuC status 0x%08x:\n", tmp);
+ seq_printf(m, "\tBootrom status = 0x%x\n",
+ (tmp & GS_BOOTROM_MASK) >> GS_BOOTROM_SHIFT);
+ seq_printf(m, "\tuKernel status = 0x%x\n",
+ (tmp & GS_UKERNEL_MASK) >> GS_UKERNEL_SHIFT);
+ seq_printf(m, "\tMIA Core status = 0x%x\n",
+ (tmp & GS_MIA_MASK) >> GS_MIA_SHIFT);
+ seq_puts(m, "\nScratch registers:\n");
+ for (i = 0; i < 16; i++)
+ seq_printf(m, "\t%2d: \t0x%x\n", i, I915_READ(SOFT_SCRATCH(i)));
+
+ return 0;
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5033,6 +5071,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS},
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
+ {"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9 v6] drm/i915: Expose one LRC function for GuC submission mode
GuC submission is basically execlist submission, but with the GuC
handling the actual writes to the ELSP and the resulting context
switch interrupts. So to describe a context for submission via
the GuC, we need one of the same functions used in execlist mode.
This commit exposes one such function, changing its name to better
describe what it does (it's related to logical ring contexts rather
than to execlists per se).
v2:
Replaces previous "drm/i915: Move execlists defines from .c to .h"
v3:
Incorporates a change to one of the functions exposed here that was
previously part of an internal patch, but which was omitted from
the version recently committed to drm-intel-nightly:
7a01a0a drm/i915/lrc: Update PDPx registers with lri commands
So we reinstate this change here.
v4:
Drop v3 change, update function parameters due to collision with
8ee3615 drm/i915: Convert execlists_ctx_descriptor() for requests
v5:
Don't expose execlists_update_context() after all. The current
version is no longer compatible with GuC submission; trying to
share the execlist version of this function results in both GuC
and CPU updating TAIL in the context image, with bad results when
they get out of step. The GuC submission path now has its own
private version that just updates the ringbuffer start address,
and not TAIL or PDPx.
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c | 10 +-
drivers/gpu/drm/i915/intel_lrc.h | 2 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 138964a..f3411f8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -270,11 +270,11 @@ u32 intel_execlists_ctx_id(struct drm_i915_gem_object
*ctx_obj)
return lrca >> 12;
}
-static uint64_t execlists_ctx_descriptor(struct drm_i915_gem_request *rq)
+uint64_t intel_lr_context_descriptor(struct intel_context *ctx,
+struct intel_engine_cs *ring)
{
- struct intel_engine_cs *ring = rq->ring;
struct drm_device *dev = ring->dev;
- struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
+ struct drm_i915_gem_object *ctx_obj = ctx->engine[ring->id].state;
uint64_t desc;
uint64_t lrca = i915_gem_obj_ggtt_offset(ctx_obj);
@@ -312,13 +312,13 @@ static void execlists_elsp_write(struct
drm_i915_gem_request *rq0,
uint64_t desc[2];
if (rq1) {
- desc[1] = execlists_ctx_descriptor(rq1);
+ desc[1] = intel_lr_context_descriptor(rq1->ctx, rq1->ring);
rq1->elsp_submitted++;
} else {
desc[1] = 0;
}
- desc[0] = execlists_ctx_descriptor(rq0);
+ desc[0] = intel_lr_context_descriptor(rq0->ctx, rq0->ring);
rq0->elsp_submitted++;
/* You must always write both descriptors in the order below. */
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 64f89f99..5e5788c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -74,6 +74,8 @@ int intel_lr_context_deferred_create(struct intel_context
*ctx,
void intel_lr_context_unpin(struct drm_i915_gem_request *req);
void intel_lr_context_reset(struct drm_device *dev,
struct intel_context *ctx);
+uint64_t intel_lr_context_descriptor(struct intel_context *ctx,
+struct intel_engine_cs *ring);
/* Execlists */
int intel_sanitize_enable_execlists(struct drm_device *dev, int
enable_execlists);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/9 v6] Batch submission via GuC
This patch series enables command submission via the GuC. In this mode, instead of the host CPU driving the execlist port directly, it hands over work items to the GuC, using a doorbell mechanism to tell the GuC that new items have been added to its work queue. The GuC then dispatches contexts to the various GPU engines, and manages the resulting context- switch interrupts. Completion of a batch is however still signalled to the CPU; the GuC is not involved in handling user interrupts. There are two subsequences within the patch series: drm/i915: GuC-specific firmware loader drm/i915: Debugfs interface to read GuC load status These two patches provide the GuC loader and a debugfs interface to verify the resulting state. At this point in the sequence we can load and activate the GuC firmware, but not submit any batches through it. (This is nonetheless a potentially useful state, as the GuC could do other useful work even when not handling batch submissions). drm/i915: Expose one LRC function for GuC submission mode drm/i915: Prepare for GuC-based command submission drm/i915: Enable GuC firmware log drm/i915: Implementation of GuC submission client drm/i915: Interrupt routing for GuC submission drm/i915: Integrate GuC-based command submission drm/i915: Debugfs interface for GuC submission statistics In this second section, we implement the GuC submission mechanism, and link it into the (execlist-based) submission path. At this stage, it is not yet enabled by default; it is activated only if the kernel command line explicitly switches it on. The GuC firmware itself is not included in this patchset; it is or will be available for download from https://01.org/linuxgraphics/downloads/ This driver works with and requires GuC firmware revision 3.x. It will not work with any firmware version 1.x, as the GuC protocol in those revisions was incompatible and is no longer supported. On platforms where there is no GuC, or where GuC submission is not specifically enabled, batch submission will continue to use the execlist (or ringbuffer) mechanisms. On the other hand, if GuC submission is requested but the GuC firmware cannot be found or is invalid, the GPU will be unusable. It is expected that a subsequent patch will enable GuC submission by default once the signed firmware is published on 01.org. Ben Widawsky (0): Vinit Azad (0): Michael H. Nguyen (0): created the original versions on which some of these patches are based. Alex Dai (5): drm/i915: GuC-specific firmware loader drm/i915: Debugfs interface to read GuC load status drm/i915: Prepare for GuC-based command submission drm/i915: Enable GuC firmware log drm/i915: Integrate GuC-based command submission Dave Gordon (4): drm/i915: Expose one LRC function for GuC submission mode drm/i915: Implementation of GuC submission client drm/i915: Interrupt routing for GuC submission drm/i915: Debugfs interface for GuC submission statistics Documentation/DocBook/drm.tmpl | 14 + drivers/gpu/drm/i915/Makefile | 4 + drivers/gpu/drm/i915/i915_debugfs.c| 146 - drivers/gpu/drm/i915/i915_dma.c| 9 + drivers/gpu/drm/i915/i915_drv.h| 11 + drivers/gpu/drm/i915/i915_gem.c| 16 + drivers/gpu/drm/i915/i915_gpu_error.c | 14 +- drivers/gpu/drm/i915/i915_guc_reg.h| 17 +- drivers/gpu/drm/i915/i915_guc_submission.c | 901 + drivers/gpu/drm/i915/i915_reg.h| 15 +- drivers/gpu/drm/i915/intel_guc.h | 122 drivers/gpu/drm/i915/intel_guc_fwif.h | 9 +- drivers/gpu/drm/i915/intel_guc_loader.c| 611 +++ drivers/gpu/drm/i915/intel_lrc.c | 65 ++- drivers/gpu/drm/i915/intel_lrc.h | 8 + 15 files changed, 1918 insertions(+), 44 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c create mode 100644 drivers/gpu/drm/i915/intel_guc.h create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9 v6] drm/i915: Enable GuC firmware log
From: Alex Dai
Allocate a GEM object to hold GuC log data. A debugfs interface
(i915_guc_log_dump) is provided to print out the log content.
v2:
Add struct members at point of use [Chris Wilson]
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 29 +++
drivers/gpu/drm/i915/i915_guc_submission.c | 46 ++
drivers/gpu/drm/i915/intel_guc.h | 1 +
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3609b13..529d2fd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2412,6 +2412,34 @@ static int i915_guc_load_status_info(struct seq_file *m,
void *data)
return 0;
}
+static int i915_guc_log_dump(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *log_obj = dev_priv->guc.log_obj;
+ u32 *log;
+ int i = 0, pg;
+
+ if (!log_obj)
+ return 0;
+
+ for (pg = 0; pg < log_obj->base.size / PAGE_SIZE; pg++) {
+ log = kmap_atomic(i915_gem_object_get_page(log_obj, pg));
+
+ for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
+ seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
+ *(log + i), *(log + i + 1),
+ *(log + i + 2), *(log + i + 3));
+
+ kunmap_atomic(log);
+ }
+
+ seq_putc(m, '\n');
+
+ return 0;
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5072,6 +5100,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
+ {"i915_guc_log_dump", i915_guc_log_dump, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 8ff59aa..669c889 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -79,6 +79,47 @@ static void gem_release_guc_obj(struct drm_i915_gem_object
*obj)
drm_gem_object_unreference(&obj->base);
}
+static void guc_create_log(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_i915_gem_object *obj;
+ unsigned long offset;
+ uint32_t size, flags;
+
+ if (i915.guc_log_level < GUC_LOG_VERBOSITY_MIN)
+ return;
+
+ if (i915.guc_log_level > GUC_LOG_VERBOSITY_MAX)
+ i915.guc_log_level = GUC_LOG_VERBOSITY_MAX;
+
+ /* The first page is to save log buffer state. Allocate one
+* extra page for others in case for overlap */
+ size = (1 + GUC_LOG_DPC_PAGES + 1 +
+ GUC_LOG_ISR_PAGES + 1 +
+ GUC_LOG_CRASH_PAGES + 1) << PAGE_SHIFT;
+
+ obj = guc->log_obj;
+ if (!obj) {
+ obj = gem_allocate_guc_obj(dev_priv->dev, size);
+ if (!obj) {
+ /* logging will be off */
+ i915.guc_log_level = -1;
+ return;
+ }
+
+ guc->log_obj = obj;
+ }
+
+ /* each allocated unit is a page */
+ flags = GUC_LOG_VALID | GUC_LOG_NOTIFY_ON_HALF_FULL |
+ (GUC_LOG_DPC_PAGES << GUC_LOG_DPC_SHIFT) |
+ (GUC_LOG_ISR_PAGES << GUC_LOG_ISR_SHIFT) |
+ (GUC_LOG_CRASH_PAGES << GUC_LOG_CRASH_SHIFT);
+
+ offset = i915_gem_obj_ggtt_offset(obj) >> PAGE_SHIFT; /* in pages */
+ guc->log_flags = (offset << GUC_LOG_BUF_ADDR_SHIFT) | flags;
+}
+
/*
* Set up the memory resources to be shared with the GuC. At this point,
* we require just one object that can be mapped through the GGTT.
@@ -103,6 +144,8 @@ int i915_guc_submission_init(struct drm_device *dev)
ida_init(&guc->ctx_ids);
+ guc_create_log(guc);
+
return 0;
}
@@ -111,6 +154,9 @@ void i915_guc_submission_fini(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = &dev_priv->guc;
+ gem_release_guc_obj(dev_priv->guc.log_obj);
+ guc->log_obj = NULL;
+
if (guc->ctx_pool_obj)
ida_destroy(&guc->ctx_ids);
gem_release_guc_obj(guc->ctx_pool_obj);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index be3cad8..5b51b05 100644
--- a/
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts callback
On Wed, 12 Aug 2015, "Yang, Libin" wrote:
> Hi Daniel,
>
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
>> Daniel Vetter
>> Sent: Wednesday, August 12, 2015 9:06 PM
>> To: Jani Nikula
>> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
>> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
>> Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts
>> callback
>>
>> On Mon, Aug 10, 2015 at 03:16:46PM +0300, Jani Nikula wrote:
>> > On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
>> > > From: Libin Yang
>> > >
>> > > Display audio may not work at some frequencies
>> > > with the HW provided N/CTS.
>> > >
>> > > This patch sets the proper N value for the
>> > > given audio sample rate at the impacted frequencies.
>> > > At other frequencies, it will use the N/CTS value
>> > > which HW provides.
>> > >
>> > > Signed-off-by: Libin Yang
>> > > ---
>> > > drivers/gpu/drm/i915/i915_reg.h| 2 +
>> > > drivers/gpu/drm/i915/intel_audio.c | 95
>> ++
>> > > 2 files changed, 97 insertions(+)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> > > index ea46d68..da2d128 100644
>> > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > > @@ -7014,6 +7014,8 @@ enum skl_disp_power_wells {
>> > > _HSW_AUD_MISC_CTRL_A, \
>> > > _HSW_AUD_MISC_CTRL_B)
>> > >
>> > > +#define HSW_AUD_PIPE_CONN_SEL_CTRL 0x650ac
>> > > +
>> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
>> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
>> > > #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
>> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> b/drivers/gpu/drm/i915/intel_audio.c
>> > > index dc32cf4..eddf37f 100644
>> > > --- a/drivers/gpu/drm/i915/intel_audio.c
>> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> > > @@ -68,6 +68,30 @@ static const struct {
>> > > { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
>> > > };
>> > >
>> > > +#define TMDS_297M 297000
>> > > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
>> > > +static const struct {
>> > > +int sample_rate;
>> > > +int clock;
>> > > +int n;
>> > > +int cts;
>> > > +} aud_ncts[] = {
>> > > +{ 44100, TMDS_296M, 4459, 234375 },
>> > > +{ 44100, TMDS_297M, 4704, 247500 },
>> > > +{ 48000, TMDS_296M, 5824, 281250 },
>> > > +{ 48000, TMDS_297M, 5120, 247500 },
>> > > +{ 32000, TMDS_296M, 5824, 421875 },
>> > > +{ 32000, TMDS_297M, 3072, 222750 },
>> > > +{ 88200, TMDS_296M, 8918, 234375 },
>> > > +{ 88200, TMDS_297M, 9408, 247500 },
>> > > +{ 96000, TMDS_296M, 11648, 281250 },
>> > > +{ 96000, TMDS_297M, 10240, 247500 },
>> > > +{ 176400, TMDS_296M, 17836, 234375 },
>> > > +{ 176400, TMDS_297M, 18816, 247500 },
>> > > +{ 44100, TMDS_296M, 23296, 281250 },
>> > > +{ 44100, TMDS_297M, 20480, 247500 },
>> > > +};
>> > > +
>> > > /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
>> > > static u32 audio_config_hdmi_pixel_clock(struct
>> drm_display_mode *mode)
>> > > {
>> > > @@ -514,12 +538,83 @@ static int
>> i915_audio_component_get_cdclk_freq(struct device *dev)
>> > > return ret;
>> > > }
>> > >
>> > > +static int i915_audio_component_set_ncts(struct device *dev, int
>> port,
>> > > +int dev_entry, int rate)
>> > > +{
>> > > +struct drm_i915_private *dev_priv = dev_to_i915(dev);
>> > > +struct drm_device *drm_dev = dev_priv->dev;
>> > > +struct intel_encoder *intel_encoder;
>> > > +struct intel_digital_port *intel_dig_port;
>> > > +struct intel_crtc *crtc;
>> > > +struct drm_display_mode *mode;
>> > > +enum pipe pipe = -1;
>> > > +u32 tmp;
>> > > +int i;
>> > > +int n_low, n_up, n = 0;
>> >
>> > I think you'll need the power well get here, and put at the end. Or
>> > check that we it.
>>
>> If we call this and end up actually dropping the power well then the
>> register writes will go exactly nowhere at all. Which indicates a bug in
>> how this is orchestrated. There is probably one ...
>
> Sorry, I'm not understanding your meaning clearly.
> Do you mean if we put the power well, the register's value will
> be invalid? Actually, we found another issue for audio power
> management (this is another bug, not related to this feature),
> and I'm thinking to add get_power/put_power as Jani said
> in another patch.
No, the point was that you should rather check that we have power. If
there isn't, and you get/put, you'll lose the values at the put.
BR,
Jani.
>
> Regards,
> Libin
>
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
--
Jani Nikula, Intel Open Source
Re: [Intel-gfx] [PATCH] drm/i915: Do not check or a stalled pageflip prior to it being queued
On Wed, Aug 12, 2015 at 04:54:09PM +0300, Ville Syrjälä wrote: > On Wed, Aug 12, 2015 at 01:08:22PM +0100, Chris Wilson wrote: > > When we queue the command or operation to change the scanout address, we > > mark the flip as in progress. We can use this flag to prevent us from > > checking for a stalled flip prior to its existence! > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/intel_display.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index aab8dfd1f8a5..edc7d4a7c9de 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -11248,6 +11248,9 @@ static bool __intel_pageflip_stall_check(struct > > drm_device *dev, > > if (atomic_read(&work->pending) >= INTEL_FLIP_COMPLETE) > > return true; > > > > + if (atomic_read(&work->pending) < INTEL_FLIP_PENDING) > > + return false; > > + > > unpin_work is assigned and the lock dropped before the flip is marked as > INTEL_FLIP_PENDING. Makes sense. > > Reviewed-by: Ville Syrjälä Queued for -next, thanks for the patch. -Daniel > > > if (!work->enable_stall_check) > > return false; > > > > -- > > 2.5.0 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel OTC > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts callback
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, August 12, 2015 9:06 PM
> To: Jani Nikula
> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts
> callback
>
> On Mon, Aug 10, 2015 at 03:16:46PM +0300, Jani Nikula wrote:
> > On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> > > From: Libin Yang
> > >
> > > Display audio may not work at some frequencies
> > > with the HW provided N/CTS.
> > >
> > > This patch sets the proper N value for the
> > > given audio sample rate at the impacted frequencies.
> > > At other frequencies, it will use the N/CTS value
> > > which HW provides.
> > >
> > > Signed-off-by: Libin Yang
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h| 2 +
> > > drivers/gpu/drm/i915/intel_audio.c | 95
> ++
> > > 2 files changed, 97 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> > > index ea46d68..da2d128 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7014,6 +7014,8 @@ enum skl_disp_power_wells {
> > > _HSW_AUD_MISC_CTRL_A, \
> > > _HSW_AUD_MISC_CTRL_B)
> > >
> > > +#define HSW_AUD_PIPE_CONN_SEL_CTRL 0x650ac
> > > +
> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
> > > #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> > > index dc32cf4..eddf37f 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -68,6 +68,30 @@ static const struct {
> > > { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> > > };
> > >
> > > +#define TMDS_297M 297000
> > > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
> > > +static const struct {
> > > + int sample_rate;
> > > + int clock;
> > > + int n;
> > > + int cts;
> > > +} aud_ncts[] = {
> > > + { 44100, TMDS_296M, 4459, 234375 },
> > > + { 44100, TMDS_297M, 4704, 247500 },
> > > + { 48000, TMDS_296M, 5824, 281250 },
> > > + { 48000, TMDS_297M, 5120, 247500 },
> > > + { 32000, TMDS_296M, 5824, 421875 },
> > > + { 32000, TMDS_297M, 3072, 222750 },
> > > + { 88200, TMDS_296M, 8918, 234375 },
> > > + { 88200, TMDS_297M, 9408, 247500 },
> > > + { 96000, TMDS_296M, 11648, 281250 },
> > > + { 96000, TMDS_297M, 10240, 247500 },
> > > + { 176400, TMDS_296M, 17836, 234375 },
> > > + { 176400, TMDS_297M, 18816, 247500 },
> > > + { 44100, TMDS_296M, 23296, 281250 },
> > > + { 44100, TMDS_297M, 20480, 247500 },
> > > +};
> > > +
> > > /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> > > static u32 audio_config_hdmi_pixel_clock(struct
> drm_display_mode *mode)
> > > {
> > > @@ -514,12 +538,83 @@ static int
> i915_audio_component_get_cdclk_freq(struct device *dev)
> > > return ret;
> > > }
> > >
> > > +static int i915_audio_component_set_ncts(struct device *dev, int
> port,
> > > + int dev_entry, int rate)
> > > +{
> > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > > + struct drm_device *drm_dev = dev_priv->dev;
> > > + struct intel_encoder *intel_encoder;
> > > + struct intel_digital_port *intel_dig_port;
> > > + struct intel_crtc *crtc;
> > > + struct drm_display_mode *mode;
> > > + enum pipe pipe = -1;
> > > + u32 tmp;
> > > + int i;
> > > + int n_low, n_up, n = 0;
> >
> > I think you'll need the power well get here, and put at the end. Or
> > check that we it.
>
> If we call this and end up actually dropping the power well then the
> register writes will go exactly nowhere at all. Which indicates a bug in
> how this is orchestrated. There is probably one ...
Sorry, I'm not understanding your meaning clearly.
Do you mean if we put the power well, the register's value will
be invalid? Actually, we found another issue for audio power
management (this is another bug, not related to this feature),
and I'm thinking to add get_power/put_power as Jani said
in another patch.
Regards,
Libin
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts callback
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, August 12, 2015 9:05 PM
> To: Jani Nikula
> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts
> callback
>
> On Mon, Aug 10, 2015 at 03:00:13PM +0300, Jani Nikula wrote:
> > On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> > > + n_low = n & 0xfff;
> > > + n_up = (n >> 12) & 0xff;
> > > +
> > > + /* 4. set the N/CTS */
> > > + tmp = I915_READ(HSW_AUD_CFG(pipe));
> > > + tmp |= AUD_CONFIG_N_PROG_ENABLE;
> > > + tmp &= ~AUD_CONFIG_UPPER_N_MASK;
> > > + tmp |= (n_up << AUD_CONFIG_UPPER_N_SHIFT);
> > > + tmp &= ~AUD_CONFIG_LOWER_N_MASK;
> > > + tmp |= (n_low << AUD_CONFIG_LOWER_N_SHIFT);
> >
> > You could squash the ors and ands together.
>
> Also read-modify-write considered evil. If you need to save a few bits
> please be explicit about it like
>
> tmp &= BITS_WE_WANT_TO_KEEP;
OK, I will try to use this format.
>
> if there's no bits to keep just start out with 0. If we have too much rwm
> to hw registers then probably something with the overall design is
> botched, e.g. with the pipe config precomputation we managed to
> remove
> almost all the rwm code for modesets.
Yes, if we can set the register by starting out with 0,
it will be better. But in this case, there are some reserved
bits. We should reserve its bits for compatibility, I think.
> -Daniel
>
> >
> > > + I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static const struct i915_audio_component_ops
> i915_audio_component_ops = {
> > > .owner = THIS_MODULE,
> > > .get_power = i915_audio_component_get_power,
> > > .put_power = i915_audio_component_put_power,
> > > .codec_wake_override =
> i915_audio_component_codec_wake_override,
> > > .get_cdclk_freq = i915_audio_component_get_cdclk_freq,
> > > + .set_ncts = i915_audio_component_set_ncts,
> > > };
> > >
> > > static int i915_audio_component_bind(struct device *i915_dev,
> > > --
> > > 1.9.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
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Retry port as HDMI if dp_is_edp turns out to be false
On Wed, Aug 12, 2015 at 03:14:53PM +0100, Chris Wilson wrote: > On Wed, Aug 12, 2015 at 04:45:39PM +0300, Ville Syrjälä wrote: > > > - /* > > > - * For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but > > > - * for DP the encoder type can be set by the caller to > > > - * INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it. > > > - */ > > > - if (type == DRM_MODE_CONNECTOR_eDP) > > > - intel_encoder->type = INTEL_OUTPUT_EDP; > > > > aux (and IIRC pps setup on vlv/chv) needs is_edp() to work. So I think > > this would break stuff. > > Hmm, I was hoping that all the additional setup we do in init for edp > would be enough for it to use any and all sidebands as necessary. It might work by accident at least on some machines since BIOSen seem to leave the vdd force enabled for eDP panels even if the port isn't active. But if that's not the case, then we'd fail to power up the panel before attempting the initial aux communication, and the eDP probe would fail. > > The fallout will be that we simply cannot reuse the false eDP link as a > plain DP and just establish one HDMI connector for the port. Or maybe it > is still recoverable? If we can keep is_edp() returning true during the edp init, things should work OK. For vlv/chv we might need to poke at the pps (maybe just vlv_detach_power_sequencer() would be enough) to make normal DP work without the pps preventing the port from powering up. That should be testable by pretending the VBT is lying about a DP port being an eDP port. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix divide by zero on watermark update
On Thu, 16 Jul 2015, Damien Lespiau wrote: > On Thu, Jul 16, 2015 at 07:36:51PM +0300, Mika Kuoppala wrote: >> Fix divide by zero if we end up updating the watermarks >> with zero dotclock. >> >> This is a stop gap measure to allow module load in cases >> where our state keeping fails. >> >> v2: WARN_ON added (Paulo) >> >> Cc: Paulo Zanoni >> Cc: Damien Lespiau >> Signed-off-by: Mika Kuoppala > > I want to say a loading module is more important than a proper fix, so: Any ideas on the proper fix? Patches on the list, sketches on a post-it, anything? I've got a machine here hitting this. BR, Jani. > > Reviewed-by: Damien Lespiau > > -- > Damien > >> --- >> drivers/gpu/drm/i915/intel_pm.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c >> index 5eeddc9..0d3e014 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -3316,8 +3316,10 @@ skl_compute_linetime_wm(struct drm_crtc *crtc, struct >> skl_pipe_wm_parameters *p) >> if (!to_intel_crtc(crtc)->active) >> return 0; >> >> -return DIV_ROUND_UP(8 * p->pipe_htotal * 1000, p->pixel_rate); >> +if (WARN_ON(p->pixel_rate == 0)) >> +return 0; >> >> +return DIV_ROUND_UP(8 * p->pipe_htotal * 1000, p->pixel_rate); >> } >> >> static void skl_compute_transition_wm(struct drm_crtc *crtc, >> -- >> 2.1.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
Re: [Intel-gfx] [PATCH 2/4] dma-buf: Add ioctls to allow userspace to flush
Hi Tiago,
Thanks for the patch!
On 12 August 2015 at 02:29, Tiago Vignatti wrote:
> From: Daniel Vetter
>
> FIXME: Update kerneldoc for begin/end to make it clear that those are
> for mmap too.
I think if we're going to add this patch upstream, atleast the FIXMEs
should be fixed.
>
> Open: Do we need a special indication that the begin/end is from
> userspace mmap and not from kernel mmap?
>
> There's also the question already about kernel internal users - vmap
> and kmap interfaces are much different ... We might need to add a
> mapping enum to the begin/end dma-buf functions.
Also, this looks like another thing that could be added right now
while we're adding this change.
>
> v2 (Tiago): Fix header file type names (u64 -> __u64)
>
> Signed-off-by: Daniel Vetter
> Signed-off-by: Tiago Vignatti
> ---
> drivers/dma-buf/dma-buf.c| 47
>
> include/uapi/linux/dma-buf.h | 39
> 2 files changed, 86 insertions(+)
> create mode 100644 include/uapi/linux/dma-buf.h
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 155c146..4820d61 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -34,6 +34,8 @@
> #include
> #include
>
> +#include
> +
> static inline int is_dma_buf_file(struct file *);
>
> struct dma_buf_list {
> @@ -251,11 +253,56 @@ out:
> return events;
> }
>
> +static long dma_buf_ioctl(struct file *file,
> + unsigned int cmd, unsigned long arg)
> +{
> + struct dma_buf *dmabuf;
> + struct dma_buf_sync sync;
> + enum dma_data_direction direction;
> +
> + dmabuf = file->private_data;
> +
> + if (!is_dma_buf_file(file))
> + return -EINVAL;
> +
> + switch (cmd) {
> + case DMA_BUF_IOCTL_SYNC:
> + if (copy_from_user(&sync, (void __user *) arg, sizeof(sync)))
> + return -EFAULT;
> +
> + if (sync.flags & DMA_BUF_SYNC_RW)
> + direction = DMA_BIDIRECTIONAL;
> + else if (sync.flags & DMA_BUF_SYNC_READ)
> + direction = DMA_FROM_DEVICE;
> + else if (sync.flags & DMA_BUF_SYNC_WRITE)
> + direction = DMA_TO_DEVICE;
> + else
> + return -EINVAL;
> +
> + if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
> + return -EINVAL;
> +
> + /* FIXME: Check for overflows in start/length. */
> +
Even this for fixing in this patch itself.
> + if (sync.flags & DMA_BUF_SYNC_END)
> + dma_buf_end_cpu_access(dmabuf, sync.start,
> + sync.length, direction);
> + else
> + dma_buf_begin_cpu_access(dmabuf, sync.start,
> +sync.length, direction);
> +
> + return 0;
> + default:
> + return -ENOTTY;
> + }
> +}
> +
> static const struct file_operations dma_buf_fops = {
> .release= dma_buf_release,
> .mmap = dma_buf_mmap_internal,
> .llseek = dma_buf_llseek,
> .poll = dma_buf_poll,
> + .unlocked_ioctl = dma_buf_ioctl,
> };
>
> /*
> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> new file mode 100644
> index 000..e5327df
> --- /dev/null
> +++ b/include/uapi/linux/dma-buf.h
> @@ -0,0 +1,39 @@
> +/*
> + * Framework for buffer objects that can be shared across devices/subsystems.
> + *
> + * Copyright(C) 2015 Intel Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> with
> + * this program. If not, see
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Enable HDMI on DDI-E
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7093 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -2 283/283 281/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_persistent_relocs@interruptible PASS(1) FAIL(1) *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2 v2 addendum] drm/i915: Allow parsing of variable size child device entries from VBT
On Wed, 12 Aug 2015, David Weinehall wrote:
> Some more fixup is needed; the bits from Antti's patch
> that actually expanded the struct to fully fit the newer
> versions of the child_device_config was part of the second
> patch; since that patch hasn't been merged yet we need this bit:
>
> This applies on top of the patch you already merged
> (the Iboost patch will need corresponding adjustment to
> remove the changes I split out):
>
> Expand common_child_dev_config to be able to fit all information
> defined by the latest VBT specification.
>
> Signed-off-by: David Weinehall
> CC: Antti Koskipaa
> ---
> intel_bios.c |7 ++-
> intel_bios.h |4
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 990acc20771a..40e2cc4e7419 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
> DRM_DEBUG_KMS("No general definition block is found, no devices
> defined.\n");
> return;
> }
> + /* Remember to keep this in sync with child_device_config;
> + * whenever a new feature is added to BDB that causes that
> + * struct to grow this needs to be updated too
> + */
> if (bdb->version < 195) {
> expected_size = 33;
> } else if (bdb->version == 195) {
> @@ -1051,7 +1055,8 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
> }
>
> if (expected_size > sizeof(*p_child)) {
> - DRM_ERROR("child_device_config cannot fit in p_child\n");
> + DRM_ERROR("child_device_config (size %u) cannot fit in p_child
> (size %u); bdb->version: %u\n",
> + expected_size, sizeof(*p_child), bdb->version);
drivers/gpu/drm/i915/intel_bios.c: In function ‘parse_device_mapping’:
drivers/gpu/drm/i915/intel_bios.c:1058:3: warning: format ‘%u’ expects argument
of type ‘unsigned int’, but argument 3 has type ‘long unsigned int’ [-Wformat=]
DRM_ERROR("child_device_config (size %u) cannot fit in p_child (size %u);
bdb->version: %u\n",
^
CC [M] drivers/gpu/drm/i915/intel_fifo_underrun.o
> return;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index f7ad6a585129..71cb96f77870 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -239,6 +239,10 @@ struct common_child_dev_config {
> u8 not_common2[2];
> u8 ddc_pin;
> u16 edid_ptr;
> + u8 obsolete;
> + u8 flags_1;
> + u8 not_common3[13];
> + u8 iboost_level;
> } __packed;
>
> /* This field changes depending on the BDB version, so the most reliable way
> to
> ___
> 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 v2 00/22] Enable gpu switching on the MacBook Pro
On Tue, Aug 11, 2015 at 12:29:17PM +0200, Lukas Wunner wrote: > This is a follow-up to the v1 posted in April: > http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html > > > Patches 1 - 17 enable GPU switching on the pre-retina MacBook Pro. > These were tested successfully by multiple people and solve two > tickets in Bugzilla: > https://bugzilla.kernel.org/show_bug.cgi?id=88861 > https://bugs.freedesktop.org/show_bug.cgi?id=61115 > > Patches 18 - 22 are a preview of how we're tackling retina support. > Those are marked experimental and are NOT ready to be merged yet. > Feedback on them is welcome. > > The patches are based on drm-next. > > They were tested on the following hardware (thanks a lot everyone!): > Tested-by: Paul Hordiienko > [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] > Tested-by: William Brown > [MBP 8,2 2011 intel SNB + amd turks pre-retina] > Tested-by: Lukas Wunner > [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] > Tested-by: Bruno Bierbaumer > [MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress] > > > What's new: > > * By default the MBP boots with the display switched to the discrete GPU > but it can be forced to the integrated GPU with an EFI boot variable. > Here's a handy tool for that: https://github.com/0xbb/gpu-switch > v1 didn't work in this configuration, v2 does. > > * Reprobing if the inactive GPU initializes before the apple-gmux module: > v1 used Matthew Garrett's approach of adding a driver callback. > v2 simply generates a hotplug event instead. nouveau polls its outputs > every 10 seconds so we want it to poll immediately once apple-gmux > registers. That is achieved by the hotplug event. The i915 driver is > changed to behave identically to nouveau. (Right now it deletes LVDS > and eDP connectors from the mode configuration if they can't be probed, > deeming them to be ghosts.) I thought -EDEFERREDPROBE is what we should be using if drivers don't get loaded in the right order? Hand-rolling depency avoidance stuff is imo a horrible idea. > * Framebuffer recreation if the inactive GPU initializes before the > apple-gmux module (i.e. discarding the default 1024x768 fb and replacing > with a new one with the actual panel resolution): v1 only supported this > for i915, v2 has a generic solution which works with nouveau and radeon > as well. (Necessary if the discrete GPU is forced to be the inactive one > on boot via the EFI variable.) Would completely remove the need for this ;-) > * Generally lots of rough edges were smoothed to hopefully make the > patches more suitable for merging. E.g. there's a bug in i915 where > the SSC status set by BIOS is preserved too late and v1 only contained > a workaround, whereas v2 contains a proper fix in a separate commit. > > > The long journey towards retina support: > > The pixel clock required for retina resolution is not supported by LVDS > (which was used on pre-retinas), necessitating eDP instead. Problem is, > the gmux register which switches the DDC lines on pre-retinas doesn't > switch the AUX channel on retinas. Disassembling the OS X driver revealed > that the gmux in retina MBPs gained an additional register 0x7f which gets > written to when setting up the eDP configuration. There was some hope that > this might switch the AUX channel. Alas, we tried writing various values > to that register but were unable to get the inactive GPU to talk to the > panel. The purpose of register 0x7f remains a mystery. > > Teardowns of the first generation retina MBP name the NXP CBTL06142 and > TI HD3SS212 as multiplexers and according to the data sheets I've found, > neither supports switching the AUX channel separately from the main link. > > Matthew Garrett had the idea of having the active GPU stash the EDID and > the first 8 bytes of the DPCD (receiver capabilities) and letting the > inactive GPU retrieve that data. I rebased and rewrote his patches and > got everything working, only to discover that the drivers are unhappy > with just 8 bytes of DPCD. They need full access to the DPCD to set up > their outputs. We could stash the entire DPCD but some parts of it are > mutable so the stashed data may become stale when the active GPU performs > writes to the DPCD. > > So I had the idea of using the active GPU as a proxy to talk to the panel, > thus emulating switching of the AUX channel in software. We can leverage > the struct drm_dp_aux and i2c_adapter (for DDC) to achieve this, swapping > the inactive GPU's structs with those of the active GPU on the fly. > That approach is implemented in patches 18 - 22 but there are still some > driver issues that I'm debugging. The current status as per the latest > logs Bruno sent me is that i915 rejects the mode retrieved via proxying > with CLOCK_HIGH and nouveau aborts link training halfway through. > Bottom line is that it's not yet working but we're getting closer.
Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in modeset
On Wed, 12 Aug 2015, Daniel Vetter wrote: > On Wed, Aug 12, 2015 at 04:23:12PM +0300, Jani Nikula wrote: >> On Wed, 12 Aug 2015, Daniel Vetter wrote: >> > It sounds like we actually need to ping the audio side _before_ we do the >> >> Do you mean "read _HSW_AUD_STR_DESC_*" by "ping the audio side" above? > > No, I mean call into snd-hda-intel before we do the modeset to ask it for > what it actually wants to have set up. At least it feels a bit like only > reacting to a modeset after it's done leads to confusion. Or maybe we just > need to update the register values we want at compute_time instead of > doing rwm fun ... > > Pure gut feeling comment, I didn't look into details ;-) The audio driver calls us, not vice versa... 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: Retry port as HDMI if dp_is_edp turns out to be false
On Wed, Aug 12, 2015 at 04:45:39PM +0300, Ville Syrjälä wrote: > > - /* > > -* For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but > > -* for DP the encoder type can be set by the caller to > > -* INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it. > > -*/ > > - if (type == DRM_MODE_CONNECTOR_eDP) > > - intel_encoder->type = INTEL_OUTPUT_EDP; > > aux (and IIRC pps setup on vlv/chv) needs is_edp() to work. So I think > this would break stuff. Hmm, I was hoping that all the additional setup we do in init for edp would be enough for it to use any and all sidebands as necessary. The fallout will be that we simply cannot reuse the false eDP link as a plain DP and just establish one HDMI connector for the port. Or maybe it is still recoverable? -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: Do not check or a stalled pageflip prior to it being queued
On Wed, Aug 12, 2015 at 01:08:22PM +0100, Chris Wilson wrote: > When we queue the command or operation to change the scanout address, we > mark the flip as in progress. We can use this flag to prevent us from > checking for a stalled flip prior to its existence! > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/intel_display.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index aab8dfd1f8a5..edc7d4a7c9de 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -11248,6 +11248,9 @@ static bool __intel_pageflip_stall_check(struct > drm_device *dev, > if (atomic_read(&work->pending) >= INTEL_FLIP_COMPLETE) > return true; > > + if (atomic_read(&work->pending) < INTEL_FLIP_PENDING) > + return false; > + unpin_work is assigned and the lock dropped before the flip is marked as INTEL_FLIP_PENDING. Makes sense. Reviewed-by: Ville Syrjälä > if (!work->enable_stall_check) > return false; > > -- > 2.5.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915: Add eDP intermediate frequencies for CHV"
On Wed, Aug 12, 2015 at 04:02:17PM +0300, Ville Syrjälä wrote: > On Wed, Aug 12, 2015 at 05:31:55PM +0530, Sivakumar Thulasimani wrote: > > > > > > On 8/12/2015 5:02 PM, Ville Syrjälä wrote: > > > On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote: > > >> From: "Thulasimani,Sivakumar" > > >> > > >> This reverts > > >> commit fe51bfb95c996733150c44d21e1c9f4b6322a326. > > >> Author: Ville Syrjälä > > >> Date: Thu Mar 12 17:10:38 2015 +0200 > > >> > > >> CHV does not support intermediate frequencies so reverting the > > >> patch that added it in the first place > > > My docs still say it does. Is there some undocumented problem with the > > > PLL or is this just a marketing decision? > > I don't think so, i too have just one document that shows the phy values > > for each of > > the link rates but have not found any where else to say it is supported . > > Display cluster HAS says they're supported. And since the spreadsheet > has them all in green I assume someone actually figured that they ought > to work. > > > Also this is not tested by anyone including us from product team so i > > highly doubt > > it will even work. > > Well if no one has tested them I guess we shouldn't try to use them. Not > a big loss in any case I suppose. > > So based on that reasoning I can give an ack for this patch: > Acked-by: Ville Syrjälä > > > > > regarding HBR2, it was supposed to land on a future stepping that never > > happened > > so it is not supported at all. > > Hmm. Display Cluster HAS listed it as a stretch goal for early steppings. > Apart > from that there isn't much else to go by. Excepth the training pattern 3 > support, but now that I look again the new bit for that has disappeared > from the DP register in the spec. Or maybe I was looking at the k0 spec > when I added it. It's still in the k0 spec but as you say that's been > nuked. > > In light of this, I think dropping HBR2 is reasonable. HBR is anyway > enough for 4k@30 with 4 lanes, so it's not like we really need HBR2. > > And could you also cook up a patch to kill the training pattern 3 > support for CHV? Should be mostly a revert of my original patch that > added it, but you probably need to adjust the use_tps3 condition a bit > too. Can we please grill the people responsible for this docs mess some more? Patch itself is for Jani. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Retry port as HDMI if dp_is_edp turns out to be false
On Sun, Aug 09, 2015 at 01:12:53PM +0100, Chris Wilson wrote:
> We follow the VBT as to whether a DDI port is used for eDP and if so, do
> not attach a HDMI encoder to it. However there are machines for which
> the VBT eDP flag is a lie (shocking!) and we fail to detect a eDP link.
> Furthermore, on those machines the HDMI is connected to that DDI port
> but we ignore it.
>
> If we reorder our port initialisation to try the eDP setup first and
> if that fails we can treat it as a normal DP port along with a HDMI
> output. To accomplish this, we have to delay registering the DP
> connector/encoder until after we establish its final type.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88331
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c | 27
> drivers/gpu/drm/i915/intel_dp.c | 127
> +--
> drivers/gpu/drm/i915/intel_drv.h | 6 +-
> 3 files changed, 79 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0bcd1b1aba4f..aab8dfd1f8a5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13941,7 +13941,6 @@ static void intel_setup_outputs(struct drm_device
> *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_encoder *encoder;
> - bool dpd_is_edp = false;
>
> intel_lvds_init(dev);
>
> @@ -13983,31 +13982,33 @@ static void intel_setup_outputs(struct drm_device
> *dev)
> intel_ddi_init(dev, PORT_D);
> } else if (HAS_PCH_SPLIT(dev)) {
> int found;
> - dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
>
> if (has_edp_a(dev))
> intel_dp_init(dev, DP_A, PORT_A);
>
> + found = 0;
> + /* PCH SDVOB multiplex with HDMIB */
> if (I915_READ(PCH_HDMIB) & SDVO_DETECTED) {
> - /* PCH SDVOB multiplex with HDMIB */
> found = intel_sdvo_init(dev, PCH_SDVOB, true);
> if (!found)
> intel_hdmi_init(dev, PCH_HDMIB, PORT_B);
> - if (!found && (I915_READ(PCH_DP_B) & DP_DETECTED))
> - intel_dp_init(dev, PCH_DP_B, PORT_B);
> }
> + if (!found && I915_READ(PCH_DP_B) & DP_DETECTED)
> + intel_dp_init(dev, PCH_DP_B, PORT_B);
>
> - if (I915_READ(PCH_HDMIC) & SDVO_DETECTED)
> - intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
> -
> - if (!dpd_is_edp && I915_READ(PCH_HDMID) & SDVO_DETECTED)
> - intel_hdmi_init(dev, PCH_HDMID, PORT_D);
> -
> + found = 0;
> if (I915_READ(PCH_DP_C) & DP_DETECTED)
> - intel_dp_init(dev, PCH_DP_C, PORT_C);
> + found = intel_dp_init(dev, PCH_DP_C, PORT_C);
> + if (found != DRM_MODE_CONNECTOR_eDP &&
> + I915_READ(PCH_HDMIC) & SDVO_DETECTED)
> + intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
>
> + found = 0;
> if (I915_READ(PCH_DP_D) & DP_DETECTED)
> - intel_dp_init(dev, PCH_DP_D, PORT_D);
> + found = intel_dp_init(dev, PCH_DP_D, PORT_D);
> + if (found != DRM_MODE_CONNECTOR_eDP &&
> + I915_READ(PCH_HDMID) & SDVO_DETECTED)
> + intel_hdmi_init(dev, PCH_HDMID, PORT_D);
> } else if (IS_VALLEYVIEW(dev)) {
> /*
>* The DP_DETECTED bit is the latched state of the DDC
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1e64a8c1e7cb..8adf500f3989 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1031,14 +1031,13 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> return ret;
> }
>
> -static void
> +static int
> intel_dp_aux_init(struct intel_dp *intel_dp, struct intel_connector
> *connector)
> {
> struct drm_device *dev = intel_dp_to_dev(intel_dp);
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> enum port port = intel_dig_port->port;
> const char *name = NULL;
> - int ret;
>
> switch (port) {
> case PORT_A:
> @@ -1080,20 +1079,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp, struct
> intel_connector *connector)
> DRM_DEBUG_KMS("registering %s bus for %s\n", name,
> connector->base.kdev->kobj.name);
>
> - ret = drm_dp_aux_register(&intel_dp->aux);
> - if (ret < 0) {
> - DRM_ERROR("drm_dp_aux_register() for %s failed (%d)\n",
> - name, ret);
> - return;
> - }
> -
> - ret = sysfs_create_link(&connector->base.kdev->kobj,
> -
Re: [Intel-gfx] [BUGFIX] drm/i915: Fix for VBT expected size
On Wed, Aug 12, 2015 at 04:42:53PM +0300, Jani Nikula wrote: > On Wed, 12 Aug 2015, Daniel Vetter wrote: > > On Tue, Aug 11, 2015 at 04:49:33PM +0300, Mika Kahola wrote: > >> Depending on the VBT BDB version the maximum size > >> can be up to 38 bytes. > >> > >> This fix increases the maximum of the VBT expected size > >> from 33 bytes to 38 bytes and by doing so cures the kernel > >> hang on BSW box. > >> > >> Signed-off-by: Mika Kahola > > > > We already have David's patch in -fixes, how does this relate? How does it > > blow up? Is this a regression? If so which commit created it? Where's the > > bugzilla link from QA? > > There's no bugzilla link from QA because Mika found the bug and I told > him to just send the patch. so bsw doesn't boot and QA didn't notice? That's fail too, just different kind of fail ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in modeset
On Wed, Aug 12, 2015 at 04:23:12PM +0300, Jani Nikula wrote: > On Wed, 12 Aug 2015, Daniel Vetter wrote: > > On Wed, Aug 12, 2015 at 09:20:17AM +0300, Jani Nikula wrote: > >> On Wed, 12 Aug 2015, "Yang, Libin" wrote: > >> > Hi Jani, > >> > > >> >> -Original Message- > >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> >> Sent: Tuesday, August 11, 2015 4:14 PM > >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- > >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in > >> >> modeset > >> >> > >> >> On Tue, 11 Aug 2015, "Yang, Libin" wrote: > >> >> > Hi Jani, > >> >> > > >> >> >> -Original Message- > >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> >> >> Sent: Tuesday, August 11, 2015 3:14 PM > >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- > >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in > >> >> >> modeset > >> >> >> > >> >> >> On Tue, 11 Aug 2015, "Yang, Libin" wrote: > >> >> >> > Hi Jani, > >> >> >> > > >> >> >> > Thanks for careful reviewing for all the patches, please > >> >> >> > see my comments. > >> >> >> > > >> >> >> >> -Original Message- > >> >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> >> >> >> Sent: Monday, August 10, 2015 8:10 PM > >> >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; > >> >> >> >> intel- > >> >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> >> >> >> Subject: Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS > >> >> in > >> >> >> >> modeset > >> >> >> >> > >> >> >> >> On Mon, 10 Aug 2015, libin.y...@intel.com wrote: > >> >> >> >> > From: Libin Yang > >> >> >> >> > > >> >> >> >> > When modeset occurs and the TMDS frequency is set to some > >> >> >> >> > speical value, the N/CTS need to be set manually if audio > >> >> >> >> > is playing. > >> >> >> >> > >> >> >> >> When modeset occurs, we disable everything, and then re-enable > >> >> >> >> everything, and notify the audio driver every step of the way. > >> >> >> >> IIUC > >> >> >> >> there should be no audio playing across the modeset, and when > >> >> the > >> >> >> >> modeset is complete and we've set the valid ELD, the audio driver > >> >> >> >> should > >> >> >> >> call the callback from the earlier patches to set the correct > >> >> >> >> audio > >> >> >> >> rate. > >> >> >> >> > >> >> >> >> Why is this patch needed? Please enlighten me. > >> >> >> > > >> >> >> > Please image this scenario: when audio is playing, the gfx driver > >> >> >> > does the modeset. In this situation, after modeset, audio driver > >> >> >> > will do nothing and continue playing. And audio driver will not > >> >> >> > call > >> >> >> > set_ncts. > >> >> >> > >> >> >> Why does the audio driver not do anything here? Whenever there's > >> >> a > >> >> >> modeset, the graphics driver will disable audio and invalidate the > >> >> ELD, > >> >> >> which should cause an interrupt to notify the audio driver about > >> >> >> this. This is no different from a hot-unplug, in fact I can't see how > >> >> >> the audio driver could even detect whether there's been a hotplug > >> >> or > >> >> >> not > >> >> >> when there's a codec disable/enable. > >> >> > > >> >> > Yes, it will trigger an interrupt to audio driver when unplug > >> >> > and another interrupt for hotplug. But from audio driver, > >> >> > we will not stop the playing and resume the playing based > >> >> > on the hotplug or modeset. The audio is always playing during > >> >> > the hotplug/modeset. > >> >> > >> >> But the whole display, and consequently ELD, might have changed > >> >> during > >> >> the hotplug, why do you assume you can just keep playing?! The > >> >> display > >> >> might even have changed from HDMI to DP or vice versa. > >> > > >> > The eld info changing will not impact the audio playing. > >> > Actually, you can image the monitor as a digital speaker, just > >> > like the headphone to the analog audio. Unplug the speaker > >> > will not impact on the audio playing. Of course , there is a > >> > little difference, when monitor hotplug, in the interrupt, > >> > we may change the codec configuration dynamically. > >> > > >> > And audio driver supply the mechanism to stop the > >> > audio playing when hotplug if the HW requires. > >> > > >> >> > >> >> We've also been putting a lot of effort into not depending on previous > >> >> state when enabling the outputs, for more reliability. We generally > >> >> don't do partial changes, we disable everything and then enable > >> >> again. And now you're suggesting we look at some register which for all > >> >> we know may have been valid for some other display? > >> > > >> > In the patch, it will not depend on previous state, I think. We > >> > read the register value which is based
Re: [Intel-gfx] [BUGFIX] drm/i915: Fix for VBT expected size
On Wed, 12 Aug 2015, Daniel Vetter wrote:
> On Tue, Aug 11, 2015 at 04:49:33PM +0300, Mika Kahola wrote:
>> Depending on the VBT BDB version the maximum size
>> can be up to 38 bytes.
>>
>> This fix increases the maximum of the VBT expected size
>> from 33 bytes to 38 bytes and by doing so cures the kernel
>> hang on BSW box.
>>
>> Signed-off-by: Mika Kahola
>
> We already have David's patch in -fixes, how does this relate? How does it
> blow up? Is this a regression? If so which commit created it? Where's the
> bugzilla link from QA?
There's no bugzilla link from QA because Mika found the bug and I told
him to just send the patch.
BR,
Jani.
> -Daniel
>
>> ---
>> drivers/gpu/drm/i915/intel_bios.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.h
>> b/drivers/gpu/drm/i915/intel_bios.h
>> index f7ad6a5..788463d 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.h
>> +++ b/drivers/gpu/drm/i915/intel_bios.h
>> @@ -246,7 +246,7 @@ struct common_child_dev_config {
>> union child_device_config {
>> /* This one is safe to be used anywhere, but the code should still check
>> * the BDB version. */
>> -u8 raw[33];
>> +u8 raw[38];
>> /* This one should only be kept for legacy code. */
>> struct old_child_dev_config old;
>> /* This one should also be safe to use anywhere, even without version
>> --
>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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] [RFC 0/8] *** DSC Inital Design RFC ***
jn Wed, Aug 12, 2015 at 03:23:45PM +0530, vikas.korj...@intel.com wrote: > From: vkorjani > > s RFC is for feature Display Stream Compression (DSC) for BXT, > It is a VESA defined standard to compress and decompress image in display > streams in a link independent manner. Some of the basic requirements of > the standard are to support higher resolution on a given display link > with fewer lanes or lower rate. > > DSC is architected to work in current Intel Display Engine design > without modification how current display pipeline works. DSC hardware > as per HAS is in b/n port and MIPI DSI controller. so most of the > changes are at port level. > > At begining of frame display can start sending valid pixels to DSC > at normal rate, DSC start compressing this image according to > pps parameters programmed already to 8bpp, 10bpp, 12bpp. > > /*This bitstream is temprory stored in output buffer and sent as byte > stream to DSI controller as soon as it is valid. > */ Where exactly is that bistream stored? In some on-chip buffer which is hidden from us, or do we need to allocate some memory for this? I din't spot anything of the latter form ... -Daniel > Following are the set of patches as per initial design in HLD, one > can refer DSC HLD if more details about the changes is required. > > Tested these patches on fulsim simulation enviornment. > > > vkorjani (8): > drm/915/bxt: Adding DSC VBT parameter and PPS structures > drm/i915/bxt: Adding registers to support DSC > drm/i915/bxt: Init PPS, Calculate DSI frequency and DPHY parameters > for DSC > drm/i915/bxt: MIPI DSI Register Programming for DSC > drm/i915/bxt: Program MIPI_DPI_RESOLUTION for DSC > drm/i915/bxt: Enable/Disable DSC and programme PPS. > drm: Add support for pps and compression mode command packet > drm/i915/bxt: Send PPS packet and compression mode command packet > > drivers/gpu/drm/drm_mipi_dsi.c | 29 +++ > drivers/gpu/drm/i915/i915_drv.h|2 + > drivers/gpu/drm/i915/i915_reg.h| 126 + > drivers/gpu/drm/i915/intel_bios.h | 74 > drivers/gpu/drm/i915/intel_dsi.c | 274 > ++-- > drivers/gpu/drm/i915/intel_dsi.h |5 + > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 23 +++ > drivers/gpu/drm/i915/intel_dsi_pll.c | 24 ++- > include/drm/drm_mipi_dsi.h |4 +- > include/video/mipi_display.h |3 + > 10 files changed, 539 insertions(+), 25 deletions(-) > > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/8] drm/i915/bxt: Init PPS, Calculate DSI frequency and DPHY parameters for DSC
On Wed, Aug 12, 2015 at 03:23:48PM +0530, vikas.korj...@intel.com wrote:
> From: vkorjani
>
> This patch adds code to initialize Picture Parameter set (PPS)
> data structure for DSC.
> DSC is enabled than the bitrate should be calculated using the
> formula pixel_clock * bits_per_pixel / lane_count, where
> bits_per_pixel can be 8bpp, 10bpp, 12bpp.
> value of bits_per_pixel is available in step of 1/16 in
> pps date structure.
> DPHY parameters are computed based on data rate calculated
> as per bits_per_pixel provided in pps data structure.
>
> Signed-off-by: vkorjani
> Signed-off-by: Yogesh Mohan Marimuthu
> ---
> drivers/gpu/drm/i915/intel_dsi.h |5 +
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 11 +++
> drivers/gpu/drm/i915/intel_dsi_pll.c | 24
> 3 files changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 24fc550..699f995 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -96,6 +96,11 @@ struct intel_dsi {
> u16 panel_on_delay;
> u16 panel_off_delay;
> u16 panel_pwr_cycle_delay;
> +
> + /*DSC Support */
> + u8 dsc_enable;
> + struct vesa_dsc_pps_data pps_data;
> + u8 dsc_bpp;
> };
>
> struct intel_dsi_host {
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index a5e99ac..f893d37 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -413,6 +413,17 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
> *intel_dsi, u16 panel_id)
> bits_per_pixel = 18;
> else if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB565)
> bits_per_pixel = 16;
> + else if (intel_dsi->pixel_format == VID_MODE_FORMAT_COMPRESSED &&
> + dev_priv->vbt.dsc_param.dsc_support) {
> + intel_dsi->dsc_enable = true;
> + intel_dsi->dsc_bpp =
> + (intel_dsi->pps_data.bits_per_pixel / 16);
> + bits_per_pixel = intel_dsi->dsc_bpp;
> + intel_dsi->pps_data =
> + dev_priv->vbt.dsc_param.pps_data;
> + /*TODO If PPS not available in VBT compute PPS
> + * from capablity parameter set in vbt */
We don't seem to feed back the dsi bits_per_pixel information into our
computation of pipe_config->pipe_bpp. We probably need to fix that to
actually be able to drive the higher bpc modes ...
Wiring this up correctly should probably be a prep patch.
Also do we have to compute bpp differently for dsc? Can't we just store
bits_per_pixel somewhere?
-Daniel
> + }
>
> intel_dsi->operation_mode = mipi_config->is_cmd_mode;
> intel_dsi->video_mode_format = mipi_config->video_transfer_mode;
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index b647f13..38c9433 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -143,10 +143,17 @@ static u32 dsi_rr_formula(const struct drm_display_mode
> *mode,
> #else
>
> /* Get DSI clock from pixel clock */
> -static u32 dsi_clk_from_pclk(u32 pclk, int pixel_format, int lane_count)
> +static u32 dsi_clk_from_pclk(struct intel_encoder *encoder,
> + u32 pclk, int pixel_format, int lane_count)
> {
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> u32 dsi_clk_khz;
> - u32 bpp = dsi_pixel_format_bpp(pixel_format);
> + u32 bpp;
> +
> + if (intel_dsi->dsc_enable)
> + bpp = intel_dsi->dsc_bpp;
> + else
> + bpp = dsi_pixel_format_bpp(pixel_format);
>
> /* DSI data rate = pixel clock * bits per pixel / lane count
> pixel clock is converted from KHz to Hz */
> @@ -223,8 +230,8 @@ static void vlv_configure_dsi_pll(struct intel_encoder
> *encoder)
> struct dsi_mnp dsi_mnp;
> u32 dsi_clk;
>
> - dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk, intel_dsi->pixel_format,
> - intel_dsi->lane_count);
> + dsi_clk = dsi_clk_from_pclk(encoder, intel_dsi->pclk,
> + intel_dsi->pixel_format, intel_dsi->lane_count);
>
> ret = dsi_calc_mnp(dev_priv, &dsi_mnp, dsi_clk);
> if (ret) {
> @@ -410,8 +417,9 @@ u32 bxt_get_dsi_pclk(struct intel_encoder *encoder, int
> pipe_bpp)
>
> dsi_clk = (dsi_ratio * BXT_REF_CLOCK_KHZ) / 2;
>
> - /* pixel_format and pipe_bpp should agree */
> - assert_bpp_mismatch(intel_dsi->pixel_format, pipe_bpp);
> + /* pixel_format and pipe_bpp should agree if DSC is not enabled */
> + if (!intel_dsi->dsc_enable)
> + assert_bpp_mismatch(intel_dsi->pixel_format, pipe_bpp);
>
> pclk = DIV_ROUND_CLOSEST(dsi_clk * intel_dsi->lane_count, pipe_bpp);
>
> @@ -475,8 +483,8 @@
