Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Sun, 07 Oct 2012 15:01:17 +0100, Ben Hutchings wrote: > On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote: > > Hi Ben, > > > > Please consider > > > > cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29 > > > > for application to the 3.2.y tree. It adds a PCI id to the i915 > > driver, making kms work. It was applied during the 3.4-rc2 cycle, so > > newer stable kernels don't need it. > > > > Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok > > (thanks!). > > > > Note that pre-2.4.34 versions of libdrm don't cope well with that > > card, with or without this patch: > [...] > > - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, > >X freezes at startup. > > > > "No regressions" means you probably shouldn't take this patch without > > a safety to work around the old X userspace, > [...] > > Then this workaround is also required in mainline. And once that's > done, I can take both patches. The bugs Jonathan mentions are both in userspace packages; not recognising the existence of Bromlow, and then misprogramming it. There are no other kernel patches required specifically for this chipset, afaik. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Set guardband clipping workaround bit in the right register.
A previous patch, namely: commit bf97b276ca04cee9ab65ffd378fa8e6aedd71ff6 Author: Daniel Vetter Date: Wed Apr 11 20:42:41 2012 +0200 drm/i915: implement w/a for incorrect guarband clipping accidentally set bit 5 in 3D_CHICKEN, which has nothing to do with clipping. This patch changes it to be set in 3D_CHICKEN3, where it belongs. The game "Dante" demonstrates random clipping issues when guardband clipping is enabled and bit 5 of 3D_CHICKEN3 isn't set. So the workaround is actually necessary. Cc: Daniel Vetter Cc: Oliver McFadden Acked-by: Paul Menzel Signed-off-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index a828e90..438bb7a 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -521,7 +521,7 @@ */ # define _3D_CHICKEN2_WM_READ_PIPELINED(1 << 14) #define _3D_CHICKEN3 0x02090 -#define _3D_CHICKEN_SF_DISABLE_FASTCLIP_CULL (1 << 5) +#define _3D_CHICKEN3_SF_DISABLE_FASTCLIP_CULL (1 << 5) #define MI_MODE0x0209c # define VS_TIMER_DISPATCH (1 << 6) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 82ca172..7ac8a48 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3410,8 +3410,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) GEN6_RCCUNIT_CLOCK_GATE_DISABLE); /* Bspec says we need to always set all mask bits. */ - I915_WRITE(_3D_CHICKEN, (0x << 16) | - _3D_CHICKEN_SF_DISABLE_FASTCLIP_CULL); + I915_WRITE(_3D_CHICKEN3, (0x << 16) | + _3D_CHICKEN3_SF_DISABLE_FASTCLIP_CULL); /* * According to the spec the following bits should be -- 1.7.12.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] i915 problems with suspend to disk
Hi, On 3.6, I've got a problem with my video driver after resuming from suspend-to-disk: the lower part of the display flickers, rapidly but irregularly (think of a neon sign in a bad film noir), flicking between the correct display and... something else, it's hard to see what. Shutting the lid of the machine (to trigger a suspend-to-ram) and waking it up again fixes the flicker. In syslogs, I have nothing obvious on suspend, and this warning on resume: Oct 4 19:53:04 ruth kernel: [ 2892.184086] [ cut here ] Oct 4 19:53:04 ruth kernel: [ 2892.184114] WARNING: at drivers/gpu/drm/i915/intel_display.c:1225 intel_crtc_disable+0x52/0x86 [i915]() Oct 4 19:53:04 ruth kernel: [ 2892.184115] Hardware name: 0196CTO Oct 4 19:53:04 ruth kernel: [ 2892.184117] pipe B assertion failure (expected off, current on) Oct 4 19:53:04 ruth kernel: [ 2892.184188] Modules linked in: cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss nfs_acl nfs lockd fscache sunrpc ext4 jbd2 mbcache loop arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant coretemp i915 snd_hda_intel snd_hda_codec drm_kms_helper iwlwifi snd_hwdep snd_pcm snd_page_alloc joydev snd_seq snd_seq_device snd_timer kvm_intel drm i2c_algo_bit thinkpad_acpi acpi_cpufreq nvram btusb bluetooth kvm crc16 cfg80211 microcode psmouse evdev i2c_i801 video rfkill wmi mperf i2c_core snd battery ac processor soundcore button btrfs crc32c libcrc32c zlib_deflate sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod sd_mod crc_t10dif ums_realtek usb_storage uas thermal thermal_sys ahci libahci libata uhci_hcd scsi_mod ehci_hcd r8169 mii usbcore usb_common Oct 4 19:53:04 ruth kernel: [ 2892.184198] Pid: 4117, comm: kworker/u:3 Not tainted 3.6.0 #14 Oct 4 19:53:04 ruth kernel: [ 2892.184199] Call Trace: Oct 4 19:53:04 ruth kernel: [ 2892.184207] [] ? warn_slowpath_common+0x78/0x8c Oct 4 19:53:04 ruth kernel: [ 2892.184213] [] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184216] [] ? warn_slowpath_fmt+0x45/0x4a Oct 4 19:53:04 ruth kernel: [ 2892.184221] [] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184238] [] ? intel_crtc_disable+0x52/0x86 [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184245] [] ? drm_helper_disable_unused_functions+0xd0/0xfb [drm_kms_helper] Oct 4 19:53:04 ruth kernel: [ 2892.184250] [] ? drm_helper_resume_force_mode+0xf1/0xff [drm_kms_helper] Oct 4 19:53:04 ruth kernel: [ 2892.184254] [] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184264] [] ? i915_drm_thaw+0xd4/0x10b [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184274] [] ? i915_resume+0x3b/0x50 [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184279] [] ? pci_legacy_resume+0x39/0x39 Oct 4 19:53:04 ruth kernel: [ 2892.184284] [] ? dpm_run_callback.isra.5+0x26/0x54 Oct 4 19:53:04 ruth kernel: [ 2892.184289] [] ? device_resume+0xd0/0x110 Oct 4 19:53:04 ruth kernel: [ 2892.184292] [] ? async_resume+0x14/0x38 Oct 4 19:53:04 ruth kernel: [ 2892.184296] [] ? async_run_entry_fn+0x9d/0x175 Oct 4 19:53:04 ruth kernel: [ 2892.184300] [] ? process_one_work+0x184/0x2a3 Oct 4 19:53:04 ruth kernel: [ 2892.184304] [] ? worker_thread+0x1fe/0x29f Oct 4 19:53:04 ruth kernel: [ 2892.184307] [] ? manage_workers+0x223/0x223 Oct 4 19:53:04 ruth kernel: [ 2892.184310] [] ? manage_workers+0x223/0x223 Oct 4 19:53:04 ruth kernel: [ 2892.184315] [] ? kthread+0x67/0x6f Oct 4 19:53:04 ruth kernel: [ 2892.184319] [] ? kernel_thread_helper+0x4/0x10 Oct 4 19:53:04 ruth kernel: [ 2892.184324] [] ? kthread_freezable_should_stop+0x3c/0x3c Oct 4 19:53:04 ruth kernel: [ 2892.184327] [] ? gs_change+0xb/0xb Oct 4 19:53:04 ruth kernel: [ 2892.184328] ---[ end trace 4e63ed9ed8ebc493 ]--- Hardware is a Lenovo Thinkpad Edge13, lspci says: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) aka 00:02.0 0300: 8086:2a42 (rev 07) Let me know if you need more information. I can probably manage a bisect if necessary -- it's easily repeatable as a bug. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Ceci n'est pas une pipe: | --- signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] [PATCH 00/14] HPD/connector-polling rework
On Thu, May 24, 2012 at 3:26 PM, Daniel Vetter wrote: > Hi all, > > I've got fed up with our sorry state of connector detection and rampant edid > re > and rere-reading. > > This patch series lays the groundwork in the drm helpers so that drivers can > avoid all this madness (at least on working hw) and properly cache the edid. > > With the additional changes for drm/i915, the edid is now read _once_ per plug > event (or at boot-up/resume time). A further step would be to integrate the > hotplug handling into the driver itself and only call ->detect on the > connectors > for which the irq handler received a hotplug event. > > By adding POLL_FORCE drivers can get back the old behaviour of calling > ->detect > every time probe_single_connector is called from userspace. I've splattered > that > over all drivers where I've thought it might be required. > > Note though that setting this doesn't avoid all regressions - the regular > output > poll work will still ignore any connectors with POLL_HPD set. If a driver/hw > with broken hpd got away due to this, this will break stuff. But that should > be > easy to fix by admitting the defeat and setting POLL_CONNECT|DISCONNECT > directly. > > If other people want to convert over their drivers, the following steps are > required: > - Ensure that the connector status is unknown every time the driver could have > missed a hpd event (e.g. after resume). drm_mode_config_reset will do that > for > you. > - Drop the POLL_FORCE flag for connectors where hdp is fully reliable. > - Implement edid caching - that's a nice way to figure out whether hpd is > actually reliable, because if it isn't, this step will ensure that you get > bug > reports because the the edid won't ever get updated ;-) > - Optionally teach the driver some smarts about which specific connectors > actually got a hotplug event. Mostly useful on cheap hw (like intel's) that > can't distinguish between hdmi and dp without trying some aux channel > transfers. > > As you can guess from the patch series, I've discovered the hard way that i915 > sdvo support is totally broken. Tested on most of the intel machines I have > and > also quickly on my radeon hd5000. > > Comments, flames, ideas and test reports highly welcome. This set looks good to me. Do you have plans to revive this? At least the common drm ones are much better than what we currently have. Alex > > Cheers, Daniel > > Daniel Vetter (14): > drm: extract drm_kms_helper_hotplug_event > drm: handle HDP and polled connectors separately > drm: introduce DRM_CONNECTOR_POLL_FORCE > drm/i915: set POLL_FORCE for sdvo outputs > drm: properly init/reset connector status > drm: kill unnecessary calls to connector->detect > drm: don't start the poll engine in probe_single_connector > drm: don't unnecessarily enable the polling work > drm: don't poll forced connectors > drm/i915: cache crt edid > drm/i915: cache dp edid > drm/i915: cache hdmi edid > drm/i915/sdvo: implement correct return value for ->get_modes > drm/i915: s/mdelay/msleep/ in the sdvo detect function > > drivers/gpu/drm/drm_crtc.c|6 ++- > drivers/gpu/drm/drm_crtc_helper.c | 76 > ++--- > drivers/gpu/drm/exynos/exynos_drm_connector.c |2 + > drivers/gpu/drm/gma500/cdv_intel_crt.c|2 + > drivers/gpu/drm/gma500/cdv_intel_hdmi.c |2 + > drivers/gpu/drm/gma500/mdfld_dsi_output.c |1 + > drivers/gpu/drm/gma500/oaktrail_hdmi.c|2 + > drivers/gpu/drm/gma500/psb_intel_sdvo.c |2 + > drivers/gpu/drm/i915/intel_crt.c | 28 +++-- > drivers/gpu/drm/i915/intel_dp.c | 47 +++ > drivers/gpu/drm/i915/intel_drv.h |2 + > drivers/gpu/drm/i915/intel_hdmi.c | 48 ++-- > drivers/gpu/drm/i915/intel_modes.c| 18 +- > drivers/gpu/drm/i915/intel_sdvo.c | 45 +-- > drivers/gpu/drm/i915/intel_tv.c |3 +- > drivers/gpu/drm/nouveau/nouveau_connector.c |1 + > drivers/gpu/drm/radeon/radeon_connectors.c|5 ++ > drivers/gpu/drm/udl/udl_connector.c |2 + > drivers/staging/omapdrm/omap_connector.c |2 + > include/drm/drm_crtc.h|5 ++ > include/drm/drm_crtc_helper.h |1 + > 21 files changed, 208 insertions(+), 92 deletions(-) > > -- > 1.7.7.6 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] [PATCH 00/14] HPD/connector-polling rework
On Thu, Oct 4, 2012 at 1:16 PM, Daniel Vetter wrote: > On Thu, Oct 04, 2012 at 12:07:01PM -0400, Alex Deucher wrote: >> On Thu, May 24, 2012 at 3:26 PM, Daniel Vetter >> wrote: >> > Hi all, >> > >> > I've got fed up with our sorry state of connector detection and rampant >> > edid re >> > and rere-reading. >> > >> > This patch series lays the groundwork in the drm helpers so that drivers >> > can >> > avoid all this madness (at least on working hw) and properly cache the >> > edid. >> > >> > With the additional changes for drm/i915, the edid is now read _once_ per >> > plug >> > event (or at boot-up/resume time). A further step would be to integrate the >> > hotplug handling into the driver itself and only call ->detect on the >> > connectors >> > for which the irq handler received a hotplug event. >> > >> > By adding POLL_FORCE drivers can get back the old behaviour of calling >> > ->detect >> > every time probe_single_connector is called from userspace. I've >> > splattered that >> > over all drivers where I've thought it might be required. >> > >> > Note though that setting this doesn't avoid all regressions - the regular >> > output >> > poll work will still ignore any connectors with POLL_HPD set. If a >> > driver/hw >> > with broken hpd got away due to this, this will break stuff. But that >> > should be >> > easy to fix by admitting the defeat and setting POLL_CONNECT|DISCONNECT >> > directly. >> > >> > If other people want to convert over their drivers, the following steps are >> > required: >> > - Ensure that the connector status is unknown every time the driver could >> > have >> > missed a hpd event (e.g. after resume). drm_mode_config_reset will do >> > that for >> > you. >> > - Drop the POLL_FORCE flag for connectors where hdp is fully reliable. >> > - Implement edid caching - that's a nice way to figure out whether hpd is >> > actually reliable, because if it isn't, this step will ensure that you >> > get bug >> > reports because the the edid won't ever get updated ;-) >> > - Optionally teach the driver some smarts about which specific connectors >> > actually got a hotplug event. Mostly useful on cheap hw (like intel's) >> > that >> > can't distinguish between hdmi and dp without trying some aux channel >> > transfers. >> > >> > As you can guess from the patch series, I've discovered the hard way that >> > i915 >> > sdvo support is totally broken. Tested on most of the intel machines I >> > have and >> > also quickly on my radeon hd5000. >> > >> > Comments, flames, ideas and test reports highly welcome. >> >> This set looks good to me. Do you have plans to revive this? At >> least the common drm ones are much better than what we currently have. > > The issue I've meanwhile discovered with hpd handling is that we really > need the smarts in the driver to only do probing on native hdmi/dp outputs > if we have a hpd irq for that specific port: Since we have 2 encoders for > the same port, if e.g. dp is enabled and we do edid probing on the hdmi > encoder/connector the display might get unhappy, which can happen even > with these patches applied e.g. when pluggin in a 2nd display. > > So the new plan (for 3.8 hopefully) is to revamp the i915-internal hpd > handling and keep on using the crtc helper stuff. For connectors with > reliable hpd we'd simply return the tracked stated in ->detect without > touching the hw at all. So I don't think we need any changes in the > hotplug/polling helper code. And looking again at these patches, they're a > rather decent kludge and it's probably better to do this all in the > drivers. Since the helper code sets the force parameter to false for all > the background polling, you can just return any driver-internal cached > state. And when force=true you could invalidate that cached state or do > some additional (more expensive) detection. Well the current code skips all hotplug event propagation if the poll option is disabled (even for hpd capable connectors) which is fail so the first few patches still seem like a win. I guess you are not planning to use any of the current common hpd code? If so, do you mind if we pull at least the first few patches in in the interim for other drivers? Alex > > In short: No plans to revive this, but certainly plans to improve the > drm/i915 hpd handling. > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 problems with suspend to disk
On Thu, Oct 04, 2012 at 09:31:39PM +0200, Daniel Vetter wrote: > On Thu, Oct 04, 2012 at 08:20:17PM +0100, Hugo Mills wrote: > >On 3.6, I've got a problem with my video driver after resuming from > > suspend-to-disk: the lower part of the display flickers, rapidly but > > irregularly (think of a neon sign in a bad film noir), flicking > > between the correct display and... something else, it's hard to see > > what. > > > >Shutting the lid of the machine (to trigger a suspend-to-ram) and > > waking it up again fixes the flicker. > > > >In syslogs, I have nothing obvious on suspend, and this warning on > > resume: [snip] > >Hardware is a Lenovo Thinkpad Edge13, lspci says: > > > > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series > > Chipset Integrated Graphics Controller (rev 07) > > > > aka > > > > 00:02.0 0300: 8086:2a42 (rev 07) > > > >Let me know if you need more information. I can probably manage a > > bisect if necessary -- it's easily repeatable as a bug. > > Before you do a bisect, can you try the drm-intel-fixes branch from > http://cgit.freedesktop.org/~danvet/drm-intel or a bit more risky, latest > upstream git? That contains a completely rewritten modeset code, which > might fix this already. To fix the breakage on 3.6 I guess we need a > bisect - at least I don't have any idea off-hand what could have gone > wrong here. Thank you for the quick response. The drm-intel-fixes branch seems to have done the trick. No more flickering. I think we can call this one fixed. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- I always felt that as a C programmer, I --- was becoming typecast. signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/4] drm: add support for raw monotonic vblank timestamps
On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: > In practice we never want the timestamps for vblank and page flip events > to be affected by time adjustments, so in addition to the gettimeofday > timestamps we used so far add support for raw monotonic timestamps. > > For backward compatibility use flags to select between the old and new > timestamp format. > > Note that with this change we will save the timestamp in both formats, > for cases where multiple clients are expecting an event notification in > different time formats. I wonder if all this trouble is really necessary. I honestly can't imagine any user of this API requiring non-monotonic timestamps and breaking with monotonic ones. I think it was simply a mistake that we didn't make them monotonic in the first place (or maybe it wasn't even possible when this API was first introduced). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/4] drm: add support for raw monotonic vblank timestamps
On Fre, 2012-10-05 at 16:59 +0300, Imre Deak wrote: > On Fri, 2012-10-05 at 15:55 +0200, Michel Dänzer wrote: > > On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: > > > In practice we never want the timestamps for vblank and page flip events > > > to be affected by time adjustments, so in addition to the gettimeofday > > > timestamps we used so far add support for raw monotonic timestamps. > > > > > > For backward compatibility use flags to select between the old and new > > > timestamp format. > > > > > > Note that with this change we will save the timestamp in both formats, > > > for cases where multiple clients are expecting an event notification in > > > different time formats. > > > > I wonder if all this trouble is really necessary. I honestly can't > > imagine any user of this API requiring non-monotonic timestamps and > > breaking with monotonic ones. I think it was simply a mistake that we > > didn't make them monotonic in the first place (or maybe it wasn't even > > possible when this API was first introduced). > > Yea, I'd rather simply switch over to monotonic timestamps too. But that > would break apps that already compare against the wall time for whatever > purpose (for example A/V sync). Are there actually any such apps in the real world? Do they work when the wall time jumps? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Align the retire_requests worker to the nearest second
On 10/5/2012 6:53 AM, Chris Wilson wrote:
> By using round_jiffies() we can align the wakeup of our worker to the
> nearest second in order to batch wakeups and reduce system load, which
> is useful for unimportant coarse tasks like our retire_requests.
>
> Suggested-by: Arjan van de Ven
> Signed-off-by: Chris Wilson
> Cc: Arjan van de Ven
> ---
> drivers/gpu/drm/i915/i915_gem.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 8e05d53..706f481 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2084,6 +2084,11 @@ i915_gem_next_request_seqno(struct intel_ring_buffer
> *ring)
> return ring->outstanding_lazy_request;
> }
>
> +static unsigned long round_jiffies_delay(unsigned long delay)
> +{
> + return round_jiffies_relative(delay) - jiffies;
> +}
this is buggy
> +
> int
> i915_add_request(struct intel_ring_buffer *ring,
>struct drm_file *file,
> @@ -2155,7 +2160,8 @@ i915_add_request(struct intel_ring_buffer *ring,
> }
> if (was_empty) {
> queue_delayed_work(dev_priv->wq,
> -&dev_priv->mm.retire_work, HZ);
> +&dev_priv->mm.retire_work,
> +round_jiffies_delay(HZ));
when used like this
round_jiffies() rounds absolute jiffies towards the next second
round_jiffies_relative() already subtracts jiffies from the result, like
the helper that you're trying to invent here does ;=)
doing that double up is a bad idea.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/4] drm: add support for raw monotonic vblank timestamps
On Fri, Oct 5, 2012 at 7:37 AM, Imre Deak wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ab1ef15..056e810 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6247,7 +6247,6 @@ static void do_intel_finish_page_flip(struct drm_device
> *dev,
> struct intel_unpin_work *work;
> struct drm_i915_gem_object *obj;
> struct drm_pending_vblank_event *e;
> - struct timeval tvbl;
> unsigned long flags;
>
> /* Ignore early vblank irqs */
> @@ -6264,12 +6263,13 @@ static void do_intel_finish_page_flip(struct
> drm_device *dev,
> intel_crtc->unpin_work = NULL;
>
> if (work->event) {
> - e = work->event;
> - e->event.sequence = drm_vblank_count_and_time(dev,
> intel_crtc->pipe, &tvbl);
> -
> - e->event.tv_sec = tvbl.tv_sec;
> - e->event.tv_usec = tvbl.tv_usec;
> + struct drm_vblank_time tvbl;
> + u32 seq;
>
> + e = work->event;
> + seq = drm_vblank_count_and_time(dev, intel_crtc->pipe, &tvbl);
> + drm_set_event_seq_and_time(&e->event, e->timestamp_raw, seq,
> + &tvbl);
> list_add_tail(&e->base.link,
> &e->base.file_priv->event_list);
> wake_up_interruptible(&e->base.file_priv->event_wait);
btw, I wonder if we could just have a helper like:
int drm_send_page_flip_event(struct drm_device *dev, int crtc,
struct drm_pending_vblank_event *event);
Since most drivers have pretty much the same code for sending vblank
event after a page flip..
I guess not strictly related to monotonic timestamps, but it has been
a cleanup that I've been meaning to do for a while.. and I guess if
this was done first it wouldn't mean touching each driver (as much) to
add support for monotonic timestamps.
BR,
-R
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 7ddef8f..55c014a 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -272,7 +272,6 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev,
> int crtc_id)
> struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
> struct radeon_unpin_work *work;
> struct drm_pending_vblank_event *e;
> - struct timeval now;
> unsigned long flags;
> u32 update_pending;
> int vpos, hpos;
> @@ -329,10 +328,13 @@ void radeon_crtc_handle_flip(struct radeon_device
> *rdev, int crtc_id)
>
> /* wakeup userspace */
> if (work->event) {
> + struct drm_vblank_time now;
> + u32 seq;
> +
> e = work->event;
> - e->event.sequence = drm_vblank_count_and_time(rdev->ddev,
> crtc_id, &now);
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + seq = drm_vblank_count_and_time(rdev->ddev, crtc_id, &now);
> + drm_set_event_seq_and_time(&e->event, e->timestamp_raw,
> + seq, &now);
> list_add_tail(&e->base.link, &e->base.file_priv->event_list);
> wake_up_interruptible(&e->base.file_priv->event_wait);
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/4] drm: add support for raw monotonic vblank timestamps
On Fri, Oct 5, 2012 at 5:41 PM, Imre Deak wrote:
> On Fri, 2012-10-05 at 16:18 -0600, Rob Clark wrote:
>> On Fri, Oct 5, 2012 at 7:37 AM, Imre Deak wrote:
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index ab1ef15..056e810 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -6247,7 +6247,6 @@ static void do_intel_finish_page_flip(struct
>> > drm_device *dev,
>> > struct intel_unpin_work *work;
>> > struct drm_i915_gem_object *obj;
>> > struct drm_pending_vblank_event *e;
>> > - struct timeval tvbl;
>> > unsigned long flags;
>> >
>> > /* Ignore early vblank irqs */
>> > @@ -6264,12 +6263,13 @@ static void do_intel_finish_page_flip(struct
>> > drm_device *dev,
>> > intel_crtc->unpin_work = NULL;
>> >
>> > if (work->event) {
>> > - e = work->event;
>> > - e->event.sequence = drm_vblank_count_and_time(dev,
>> > intel_crtc->pipe, &tvbl);
>> > -
>> > - e->event.tv_sec = tvbl.tv_sec;
>> > - e->event.tv_usec = tvbl.tv_usec;
>> > + struct drm_vblank_time tvbl;
>> > + u32 seq;
>> >
>> > + e = work->event;
>> > + seq = drm_vblank_count_and_time(dev, intel_crtc->pipe,
>> > &tvbl);
>> > + drm_set_event_seq_and_time(&e->event, e->timestamp_raw,
>> > seq,
>> > + &tvbl);
>> > list_add_tail(&e->base.link,
>> > &e->base.file_priv->event_list);
>> > wake_up_interruptible(&e->base.file_priv->event_wait);
>>
>>
>> btw, I wonder if we could just have a helper like:
>>
>> int drm_send_page_flip_event(struct drm_device *dev, int crtc,
>> struct drm_pending_vblank_event *event);
>>
>> Since most drivers have pretty much the same code for sending vblank
>> event after a page flip..
>>
>> I guess not strictly related to monotonic timestamps, but it has been
>> a cleanup that I've been meaning to do for a while.. and I guess if
>> this was done first it wouldn't mean touching each driver (as much) to
>> add support for monotonic timestamps.
>
> Good idea, we should do this.
>
> But if we want to reduce the diff from my changes then the proto should
> rather be:
>
> int drm_send_page_flip_event(struct drm_device *dev, int crtc,
>struct drm_pending_vblank_event *event,
>int seq, struct timeval *now);
do we need 'seq' and 'now'? I was sort of thinking that could all be
internal to the send_page_flip_event() fxn.. ie. like:
-
void drm_send_page_flip_event(struct drm_device *dev, int pipe,
struct drm_crtc *crtc, struct drm_pending_vblank_event *event)
{
struct timeval tnow, tvbl;
do_gettimeofday(&tnow);
event->event.sequence = drm_vblank_count_and_time(dev, pipe, &tvbl);
/* Called before vblank count and timestamps have
* been updated for the vblank interval of flip
* completion? Need to increment vblank count and
* add one videorefresh duration to returned timestamp
* to account for this. We assume this happened if we
* get called over 0.9 frame durations after the last
* timestamped vblank.
*
* This calculation can not be used with vrefresh rates
* below 5Hz (10Hz to be on the safe side) without
* promoting to 64 integers.
*/
if (10 * (timeval_to_ns(&tnow) - timeval_to_ns(&tvbl)) >
9 * crtc->framedur_ns) {
event->event.sequence++;
tvbl = ns_to_timeval(timeval_to_ns(&tvbl) +
crtc->framedur_ns);
}
event->event.tv_sec = tvbl.tv_sec;
event->event.tv_usec = tvbl.tv_usec;
list_add_tail(&event->base.link,
&event->base.file_priv->event_list);
wake_up_interruptible(&event->base.file_priv->event_wait);
}
-
well, this would be the pre-monotonic timestamp version.. and it is a
bit weird to have to pass in both crtc ptr and pipe #.. I don't see
anything obvious in drm core that links pipe # and crtc ptr, although
userspace seems to make this assumption about order of crtc's. But I
think that if() statement is only in i915 driver.. I assume because
you don't know if this will get called before or after
drm_handle_vblank()? I guess that shouldn't hurt for other drivers.
then each driver would just have something like:
-
if (work->event)
drm_send_page_flip_event(dev, intel_crtc->pipe, crtc,
work->event);
-
> with struct timeval changing to struct drm_vblank_time with my changes.
>
> I can do this if you agree - unless you have something ready.
I've locally split out this into a helper fxn in omapdrm, but haven't
got around to pushing
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote: > Hi Ben, > > Please consider > > cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29 > > for application to the 3.2.y tree. It adds a PCI id to the i915 > driver, making kms work. It was applied during the 3.4-rc2 cycle, so > newer stable kernels don't need it. > > Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok > (thanks!). > > Note that pre-2.4.34 versions of libdrm don't cope well with that > card, with or without this patch: [...] > - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, >X freezes at startup. > > "No regressions" means you probably shouldn't take this patch without > a safety to work around the old X userspace, [...] Then this workaround is also required in mainline. And once that's done, I can take both patches. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Sun, 2012-10-07 at 15:11 +0100, Chris Wilson wrote: > On Sun, 07 Oct 2012 15:01:17 +0100, Ben Hutchings > wrote: > > On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote: > > > Hi Ben, > > > > > > Please consider > > > > > > cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29 > > > > > > for application to the 3.2.y tree. It adds a PCI id to the i915 > > > driver, making kms work. It was applied during the 3.4-rc2 cycle, so > > > newer stable kernels don't need it. > > > > > > Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok > > > (thanks!). > > > > > > Note that pre-2.4.34 versions of libdrm don't cope well with that > > > card, with or without this patch: > > [...] > > > - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, > > >X freezes at startup. > > > > > > "No regressions" means you probably shouldn't take this patch without > > > a safety to work around the old X userspace, > > [...] > > > > Then this workaround is also required in mainline. And once that's > > done, I can take both patches. > > The bugs Jonathan mentions are both in userspace packages; not > recognising the existence of Bromlow, and then misprogramming it. Yes, I understand that. > There > are no other kernel patches required specifically for this chipset, > afaik. If upgrading the kernel currently triggers a (more) serious bug in typical userland then the kernel should work around that. If I've misunderstood, and the userland behaviour is roughly equally broken with or without this change, then I'll be happy to take it. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Mon, Oct 1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote: > - without this patch, modern X errors out instead of starting, >because the intel driver requires kms. (In a hypothetical better >world, userspace would know to fall back to vesa or something.) > I'd expect X to start with vesa or fbdev, rather than erroring out? Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
Maik Zumstrull wrote: > On Sun, Oct 7, 2012 at 7:26 PM, Julien Cristau wrote: >> On Mon, Oct 1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote: >>> - without this patch, modern X errors out instead of starting, [...] >> I'd expect X to start with vesa or fbdev, rather than erroring out? > > There's a corner case when X and the kernel know about the graphics > device, but libdrm doesn't, in which case an assertion in the X driver > fails and X doesn't start. Upstream libdrm has been okay for a few > releases. I think Julien means the case where the kernel does not know about the graphics device. From [1]: | 3.2 crashes as well, but not as hard as 3.4. With 3.2, X doesn't come | up, but you can switch to a console and reboot. 3.4 needs the reset | button. X should have been able to start using the vesa or fbdev driver. I'm not sure why that doesn't happen --- do you have an Xorg log from booting and trying to start X with a 3.2.y kernel without the "drm/i915: add Ivy Bridge GT2 Server entries" patch? Thanks, Jonathan [1] http://bugs.debian.org/684767 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove the disabling of VHR unit clock gating for HSW
On Fri, Oct 05, 2012 at 10:40:35AM -0300, Paulo Zanoni wrote: > 2012/10/5 Damien Lespiau : > > From: Damien Lespiau > > > > There's is another register (a read only, so no harm done) at 0x42020 on > > Haswell GPUs. Let's just remove the write from the copy&paste that > > introduced haswell_init_clock_gating(). > > > > A note for the interested reader, it does seem we have a duplication of > > the 0x42020 register definition, hence the removal of 2 writes. That > > duplication could be the object of a later patch. > > > > Signed-off-by: Damien Lespiau > > Cc: Paulo Zanoni > > Nice catch! > > As you pointed, it seems that we're applying the same workaround twice > in some functions. You fixed the problem in haswell_init_clock_gating > by just removing both register writes, but could you also write a new > patch to fix ivybridge_init_clock_gating and > valleyview_init_clock_gating to not apply the same workaround twice? > Maybe just remove the ILK_DSPCLK_GATE definitions and just use > PCH_DSPCLK_GATE_D everywhere, removing duplicated code? Then we'd also > have to check ironlake_init_clock_gating and gen6_init_clock_gating... > > Reviewed-by: Paulo Zanoni > Tested-by: Paulo Zanoni Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/4] drm: add support for raw monotonic vblank timestamps
On Sat, Oct 06, 2012 at 03:49:16AM +0300, Imre Deak wrote:
> On Fri, 2012-10-05 at 18:09 -0600, Rob Clark wrote:
> >
> > /* Called before vblank count and timestamps have
> > * been updated for the vblank interval of flip
> > * completion? Need to increment vblank count and
> > * add one videorefresh duration to returned timestamp
> > * to account for this. We assume this happened if we
> > * get called over 0.9 frame durations after the last
> > * timestamped vblank.
> > *
> > * This calculation can not be used with vrefresh rates
> > * below 5Hz (10Hz to be on the safe side) without
> > * promoting to 64 integers.
> > */
> > if (10 * (timeval_to_ns(&tnow) - timeval_to_ns(&tvbl)) >
> > 9 * crtc->framedur_ns) {
> > event->event.sequence++;
> > tvbl = ns_to_timeval(timeval_to_ns(&tvbl) +
> > crtc->framedur_ns);
> > }
>
> This has been recently removed by danvet's "drm/i915: don't frob the
> vblank ts in finish_page_flip", though not yet committed, so we can do
> away with it here too.
Yeah, I'd prefer if the common code doesn't have such hackes - this bit
here papered over some bugs in our driver code, but only partially
successfully ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [regression] 3.6-rc6, gpu hang with vaapi
Hi Guilherme, Sorry, I cannot reproduce this issue with the following Env: --- Kernel: (this is the same with yours) Version : 3.6.0rc6_stable_20120919+ Kernel: (drm-intel-fixes)b98b60167279df3acac9422c3c9820d9ebbcf9fb Some additional commit info: Author: Wang Xingchao Date: Thu Sep 13 07:43:22 2012 +0800 --- X: (This is newer than yours) Libdrm: (master)libdrm-2.4.39-9-g2426a6a7112ae62755408a371831eddbe2d89d99 Mesa: (9.0)b1ce5749b996d6ce3dcf9bbd1537c46d14e62adb Xserver: (server-1.12-branch)xorg-server-1.12.4-2-g78c77356c5d88d78d69b1a244c7e27cd85544842 Xf86_video_intel: (master)2.20.8-36-g8bfd31e9bb13bcb7f12e4147bec0da87b8e87dde Cairo: (master)797441093a8346003552e0cf89aef2a644ff53ab --- GPU Driver: ( this is the latest) Libva: commit a78128ac9a52b7567296e076c3cd9e5b7ea640ad Author: Jonathan Bian Date: Sun Sep 16 21:26:00 2012 -0700 Intel-driver: commit eb5f7f88fbd9085c3346a6b00698cef091e2ece2 Author: Gwenole Beauchesne Date: Wed Aug 29 18:37:25 2012 +0200 Thanks, Chao -Original Message- From: intel-gfx-bounces+haihao.xiang=intel@lists.freedesktop.org [mailto:intel-gfx-bounces+haihao.xiang=intel@lists.freedesktop.org] On Behalf Of Guilherme M. Schroeder Sent: Thursday, September 20, 2012 5:59 PM To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [regression] 3.6-rc6, gpu hang with vaapi Hi, I get a GPU hang every time i play an mkv using mplayer -vo vaapi with 3.6-rc6. With 3.5.4 no GPU hang at all. I'm using xf86-video-intel 2.20.8, xorg-server 1.12.4 and libva-1.1.0 on Intel(R) Sandybridge Mobile (GT2+). On dmesg, i915_error_state and Xorg.0.log: [ 105.822821] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 105.822825] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [ 111.871670] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 112.950746] [ cut here ] [ 112.950751] WARNING: at mm/page_alloc.c:2349 __alloc_pages_nodemask+0x87c/0x960() [ 112.950753] Hardware name: 4177CTO [ 112.950753] Modules linked in: fuse ip6table_filter ip6_tables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc snd_hda_codec_hdmi arc4 vhost_net tun macvtap macvlan snd_hda_codec_conexant iwldvm btusb joydev mac80211 kvm_intel iwlwifi i915 bluetooth intel_agp intel_gtt i2c_algo_bit drm_kms_helper cfg80211 drm thinkpad_acpi nvram rfkill snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 snd_timer e1000e i2c_i801 aes_generic ablk_helper snd cryptd iTCO_wdt iTCO_vendor_support soundcore lpc_ich i2c_core tpm_tis sdhci_pci sdhci mei mmc_core psmouse serio_raw kvm acpi_cpufreq battery video button thermal [ 112.950785] mperf mfd_core ac pcspkr evdev wmi tpm processor tpm_bios coretemp microcode autofs4 ext4 crc16 jbd2 mbcache sd_mod ahci ehci_hcd libahci libata scsi_mod usbcore usb_common [ 112.950795] Pid: 1461, comm: cp Not tainted 3.6.0-rc6-00052-gc46de22 #33 [ 112.950796] Call Trace: [ 112.950801] [] warn_slowpath_common+0x7f/0xc0 [ 112.950803] [] warn_slowpath_null+0x1a/0x20 [ 112.950804] [] __alloc_pages_nodemask+0x87c/0x960 [ 112.950807] [] alloc_pages_current+0xb0/0x120 [ 112.950809] [] __get_free_pages+0xe/0x50 [ 112.950811] [] kmalloc_order_trace+0x39/0xf0 [ 112.950812] [] __kmalloc+0x177/0x180 [ 112.950815] [] ? put_page+0x2c/0x40 [ 112.950818] [] seq_read+0x10e/0x3b0 [ 112.950821] [] vfs_read+0xa5/0x180 [ 112.950822] [] sys_read+0x4a/0xa0 [ 112.950825] [] system_call_fastpath+0x16/0x1b [ 112.950826] ---[ end trace b5c3af991219a333 ]--- # cat /sys/kernel/debug/dri/0/i915_error_state cat: /sys/kernel/debug/dri/0/i915_error_state: Cannot allocate memory [ 115.163] [mi] EQ overflowing. Additional events will be discarded until existing events are processed. [ 115.163] [ 115.163] Backtrace: [ 115.174] 0: /usr/bin/Xorg (xorg_backtrace+0x36) [0x560366] [ 115.174] 1: /usr/bin/Xorg (mieqEnqueue+0x26b) [0x54161b] [ 115.174] 2: /usr/bin/Xorg (0x40+0x47f92) [0x447f92] [ 115.174] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fb83c986000+0x5f74) [0x7fb83c98bf74] [ 115.174] 4: /usr/bin/Xorg (0x40+0x6efd7) [0x46efd7] [ 115.174] 5: /usr/bin/Xorg (0x40+0x93370) [0x493370] [ 115.174] 6: /usr/lib/libpthread.so.0 (0x7fb840d71000+0xf170) [0x7fb840d80170] [ 115.174] 7: /usr/lib/libc.so.6 (ioctl+0x7) [0x7fb83fcdb977] [ 115.174] 8: /usr/lib/libdrm.so.2 (drmIoctl+0x28) [0x7fb83e271978] [ 115.174] 9: /usr/lib/xorg/modules/drivers/intel_
