Re: [Intel-gfx] [PATCH 19/37] drm/fsl: Drop drm_vblank_cleanup
On Thu, May 25, 2017 at 10:18 AM, Stefan Agner wrote: > On 2017-05-24 07:51, Daniel Vetter wrote: >> Again cleanup before irq disabling doesn't really stop the races, >> so just drop it. Proper fix would be to put drm_atomic_helper_shutdown >> before everything gets cleaned up. > > Hm, I already use the non-atomic drm_crtc_force_disable_all before, I > think that fixed the races I saw. > > But I guess what you are saying instead of using > drm_crtc_force_disable_all I should use drm_atomic_helper_shutdown...? Yes. I thought I audited all existing users of the legacy force_disable (it won't work correctly for atomic drivers), but somehow I missed the one in fsl. See commit 18dddadc78c91a91b546acc48506c24f5f840c4f Author: Daniel Vetter Date: Tue Mar 21 17:41:49 2017 +0100 drm/atomic: Introduce drm_atomic_helper_shutdown 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 https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On Thu, May 25, 2017 at 05:06:26PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Implement support for this DisplayPort feature.
>
> The cec device is created whenever it detects an adapter that
> has this feature. It is only removed when a new adapter is connected
> that does not support this. If a new adapter is connected that has
> different properties than the previous one, then the old cec device is
> unregistered and a new one is registered to replace the old one.
>
> Signed-off-by: Hans Verkuil
Some small comments below.
> ---
> drivers/gpu/drm/i915/Kconfig| 11 ++
> drivers/gpu/drm/i915/intel_dp.c | 46
> +
> 2 files changed, 53 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index a5cd5dacf055..f317b13a1409 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
> Choose this option if you want to enable KVMGT support for
> Intel GVT-g.
>
> +config DRM_I915_DP_CEC
> + tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> + depends on DRM_I915 && CEC_CORE
> + select DRM_DP_CEC
> + help
> + Choose this option if you want to enable HDMI CEC support for
> + DisplayPort/USB-C to HDMI adapters.
> +
> + Note: not all adapters support this feature, and even for those
> + that do support this often do not hook up the CEC pin.
Why Kconfig? There's not anything else optional in i915.ko (except debug
stuff ofc), since generally just not worth the pain. Also doesn't seem to
be wired up at all :-)
> +
> menu "drm/i915 Debugging"
> depends on DRM_I915
> depends on EXPERT
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index ee77b519835c..38e17ee2548d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp
> *intel_dp)
> static void
> intel_dp_aux_fini(struct intel_dp *intel_dp)
> {
> + cec_unregister_adapter(intel_dp->aux.cec_adap);
> kfree(intel_dp->aux.name);
> }
>
> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> return -EINVAL;
> }
>
> +static bool
> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
> +{
> + bool handled = false;
> +
> + for (;;) {
> + u8 cec_irq;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + &cec_irq);
> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
> + return handled;
> +
> + cec_irq &= ~DP_CEC_IRQ;
> + drm_dp_cec_irq(&intel_dp->aux);
> + handled = true;
> +
> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + cec_irq);
> + if (ret < 0)
> + return handled;
> + }
> +}
Shouldn't the above be a helper in the cec library? Doesn't look i915
specific to me at least ...
> +
> static void
> intel_dp_retrain_link(struct intel_dp *intel_dp)
> {
> @@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
> intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
> else
> intel_dp->has_audio = drm_detect_monitor_audio(edid);
> + cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
> }
>
> static void
> @@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>
> kfree(intel_connector->detect_edid);
> intel_connector->detect_edid = NULL;
> + cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
>
> intel_dp->has_audio = false;
> }
> @@ -4582,13 +4613,17 @@ intel_dp_long_pulse(struct intel_connector
> *intel_connector)
> intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
>
> /* Can't disconnect eDP, but you can close the lid... */
> - if (is_edp(intel_dp))
> + if (is_edp(intel_dp)) {
> status = edp_detect(intel_dp);
> - else if (intel_digital_port_connected(to_i915(dev),
> - dp_to_dig_port(intel_dp)))
> + } else if (intel_digital_port_connected(to_i915(dev),
> + dp_to_dig_port(intel_dp))) {
> status = intel_dp_detect_dpcd(intel_dp);
> - else
> + if (status == connector_status_connected)
> + drm_dp_cec_configure_adapter(&intel_dp->aux,
> + intel_dp->aux.name, dev->dev);
Did you look into also wiring this up for dp m
Re: [Intel-gfx] [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature that is part of the DisplayPort 1.3 standard.
>
> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
> chip that has this capability actually hook up the CEC pin, so
> even though a CEC device is created, it may not actually work.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/gpu/drm/Kconfig | 3 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_dp_cec.c | 196
> +++
> include/drm/drm_dp_helper.h | 24 ++
> 4 files changed, 224 insertions(+)
> create mode 100644 drivers/gpu/drm/drm_dp_cec.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 78d7fc0ebb57..dd771ce8a3d0 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -120,6 +120,9 @@ config DRM_LOAD_EDID_FIRMWARE
> default case is N. Details and instructions how to build your own
> EDID data are given in Documentation/EDID/HOWTO.txt.
>
> +config DRM_DP_CEC
> + bool
We generally don't bother with a Kconfig for every little bit in drm, not
worth the trouble (yes I know there's some exceptions, but somehow they're
all from soc people). Just smash this into the KMS_HELPER one and live is
much easier for drivers. Also allows you to drop the dummy inline
functions.
The other nitpick: Pls kernel-doc the functions exported to drivers, and
then pull them into Documentation/gpu/drm-kms-helpers.rst, next to the
existing DP helper section.
Thanks, Daniel
> +
> config DRM_TTM
> tristate
> depends on DRM && MMU
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 59f0f9b696eb..22f1a17dfc8a 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -34,6 +34,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
> drm_probe_helper.o \
> drm_simple_kms_helper.o drm_modeset_helper.o \
> drm_scdc_helper.o
>
> +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
> drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> new file mode 100644
> index ..44c544ba53cb
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -0,0 +1,196 @@
> +/*
> + * DisplayPort CEC-Tunneling-over-AUX support
> + *
> + * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights
> reserved.
> + *
> + * This program is free software; you may redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * 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
> +#include
> +#include
> +
> +static int drm_dp_cec_adap_enable(struct cec_adapter *adap, bool enable)
> +{
> + struct drm_dp_aux *aux = cec_get_drvdata(adap);
> + ssize_t err = 0;
> +
> + if (enable)
> + err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL,
> + DP_CEC_TUNNELING_ENABLE);
> + else
> + err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, 0);
> + return (enable && err < 0) ? err : 0;
> +}
> +
> +static int drm_dp_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
> +{
> + struct drm_dp_aux *aux = cec_get_drvdata(adap);
> + u8 mask[2] = { 0x00, 0x80 };
> + ssize_t err;
> +
> + if (addr != CEC_LOG_ADDR_INVALID) {
> + u16 la_mask = adap->log_addrs.log_addr_mask;
> +
> + la_mask |= 0x8000 | (1 << addr);
> + mask[0] = la_mask & 0xff;
> + mask[1] = la_mask >> 8;
> + }
> + err = drm_dp_dpcd_write(aux, DP_CEC_LOGICAL_ADDRESS_MASK, mask, 2);
> + return (addr != CEC_LOG_ADDR_INVALID && err < 0) ? err : 0;
> +}
> +
> +static int drm_dp_cec_adap_transmit(struct cec_adapter *adap, u8 attempts,
> + u32 signal_free_time, struct cec_msg *msg)
> +{
> + struct drm_dp_aux *aux = cec_get_drvdata(adap);
> + unsigned int retries = attempts - 1;
> + ssize_t err;
> +
> + err = drm_dp_dpcd_write(aux, DP_CEC_TX_MESSAGE_BUFFER,
> + msg->msg, msg->len);
> + if (er
Re: [Intel-gfx] [PULL] drm-misc-fixes
On Fri, 26 May 2017, Daniel Vetter wrote: > On Thu, May 25, 2017 at 7:44 PM, Sean Paul wrote: >> The pull is noisy >> because it includes -rc2. > > dim has you covered for this, in case you've rolled forward but Dave > hasn't yet, you can regenerate against linus upstream branch for a > cleaner pull (but still warn Dave ofc): > > $ dim pull-request drm-misc-next origin/master FWIW this is what I've always done with drm-intel-fixes. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/37] drm/arcgpu: Drop drm_vblank_cleanup
Hi Daniel, On Wed, 2017-05-24 at 16:51 +0200, Daniel Vetter wrote: > CRTC don't seem to get shut down in a controlled fashion, but no one > bothers to stop interrupts either so this races no matter what. Might > as well remove it. A call to drm_atomic_helper_shutdown would be > pretty sweet somewhere (and maybe getting rid of the load/unload > callbacks while at it). > > Cc: Alexey Brodkin > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/arc/arcpgu_drv.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c > b/drivers/gpu/drm/arc/arcpgu_drv.c > index 1926b200e4cb..3e43a5d4fb09 100644 > --- a/drivers/gpu/drm/arc/arcpgu_drv.c > +++ b/drivers/gpu/drm/arc/arcpgu_drv.c > @@ -155,7 +155,6 @@ static int arcpgu_unload(struct drm_device *drm) > arcpgu->fbdev = NULL; > } > drm_kms_helper_poll_fini(drm); > - drm_vblank_cleanup(drm); > drm_mode_config_cleanup(drm); > > return 0; Reviewed-by: Alexey Brodkin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/37] drm/zte: Drop drm_vblank_cleanup
On Wed, May 24, 2017 at 04:52:11PM +0200, Daniel Vetter wrote: > It again looks all cargo-culted for no good reasons. drm_vblank_cleanup() is called to release the resources allocated by drm_vblank_init(). I think that's the reason, no? Shawn > > Cc: Shawn Guo > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/zte/zx_drm_drv.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c > b/drivers/gpu/drm/zte/zx_drm_drv.c > index 490aafc99610..696836303229 100644 > --- a/drivers/gpu/drm/zte/zx_drm_drv.c > +++ b/drivers/gpu/drm/zte/zx_drm_drv.c > @@ -149,7 +149,6 @@ static int zx_drm_bind(struct device *dev) > out_poll_fini: > drm_kms_helper_poll_fini(drm); > drm_mode_config_cleanup(drm); > - drm_vblank_cleanup(drm); > out_unbind: > component_unbind_all(dev, drm); > out_unregister: > @@ -171,7 +170,6 @@ static void zx_drm_unbind(struct device *dev) > } > drm_kms_helper_poll_fini(drm); > drm_mode_config_cleanup(drm); > - drm_vblank_cleanup(drm); > component_unbind_all(dev, drm); > dev_set_drvdata(dev, NULL); > drm->dev_private = NULL; > -- > 2.11.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use a cached mapping for the physical HWS
On Mon, May 22, 2017 at 10:13:44AM +0100, Chris Wilson wrote: > On Mon, May 22, 2017 at 10:55:01AM +0200, Daniel Vetter wrote: > > On Wed, May 17, 2017 at 02:02:50PM +0100, Chris Wilson wrote: > > > Older gen use a physical address for the hardware status page, for which > > > we use cache-coherent writes. As the writes are into the cpu cache, we use > > > a normal WB mapped page to read the HWS, used for our seqno tracking. > > > > > > Anecdotally, I observed lost breadcrumbs writes into the HWS on i965gm, > > > which so far have not reoccurred with this patch. How reliable that > > > evidence is remains to be seen. > > > > > > Signed-off-by: Chris Wilson > > > > dma is assumed to be coherent, so this should give you the same thing in > > the end. > > Hmm, DMA historically hasn't been coherent, to get coherency required > UC - being able to snoop was an ability of the GMCH, I thought. Looking > at drivers/base/dma-coherent.c it is allocating UC (WC if you are > lucky) from a device region, though I'm lost working out how the dynamic > allocaton is treated. Yes, gpu dma wasn't coherent, but x86 dma api always assumed that everything is coherent (since for non-gpus that was the case). At least that's how I thought things worked. > > Except that dma_map_page can use bounce buffers, whereas > > dma_alloc_coherent will make sure you're not doing that. > > Hmm, on these machines we don't have DMAR, we really should be feeding > in physical addresses. That was probably being too polite. Fancy > without? Not sure what you mean ... page_to_pfn, plus comment? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] intel-ci: Add gem_exec_reloc/basic-range to BAT
On Mon, May 22, 2017 at 10:40:13AM +0100, Chris Wilson wrote: > On Mon, May 15, 2017 at 04:03:50PM +0200, Daniel Vetter wrote: > > What would probably help the CI folks is a gem testcase list that includes > > all the important stuff (so much more than BAT), but also completes in a > > reasonable amount of time (2h as a goal might be good). Atm not even > > excluding gem_concurrent_* (which really is a shame, since it has lots of > > correctness tests among all the combinatorial stress) doesn't get us > > there, with Mexico reporting it takes over 10h to just run that. > > To reiterate myself, such a constrained test suite can and should be > generated automatically. But how do you generate that test list to make sure it does actually include the stuff you really want to have tested? Random or semi-random selection adds noise, and noise in CI is not cool. The other issue is that since no one runs full igt, the survival pressure on tests died, and we're piling up tons of stuff. That's imo not good at all. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Defined NM doesn't work on KBL and uses automatic N/M.
On Fri, 26 May 2017, Quanxian Wang wrote:
> According to the bspec, when set N/M, should disable
> and enable transcoder which attaching DP audio. However
> with that implementation will affect performance more.
>
> But with current implementation, KBL could not work with defined N/M.
> By default, KBL will use automatic N/M.
>
> Signed-off-by: Quanxian Wang
> Reviewed-by: Libin Yang
> Reviewed-by: Jani Nikula
I have *NOT* reviewed this patch. Even if it's based on my suggestion in
[1], it does not automatically signify review.
The patch subject should start with "drm/i915/audio:".
The DP spec always expresses the values as M/N, more specifically
Maud/Naud, so it's confusing to see them expressed as N/M.
I still have trouble understanding the commit message. I am wondering if
something was fixed in Kabylake and beyond, since according to
6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset") we need this
for certain modes. In particular, should the condition check for KBL ||
gen >= 10?
BR,
Jani.
[1] http://mid.mail-archive.com/87pogs1lz7.fsf@intel.com
> ---
> drivers/gpu/drm/i915/intel_audio.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index d805b6e..ba4994e 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -289,6 +289,10 @@ hsw_dp_audio_config_update(struct intel_crtc
> *intel_crtc, enum port port,
> enum pipe pipe = intel_crtc->pipe;
> u32 tmp;
>
> + /* It doesn't work on KBL and uses automatic N/M. */
> + if (IS_KABYLAKE(dev_priv))
> + nm = NULL;
> +
> if (nm)
> DRM_DEBUG_KMS("using Maud %u, Naud %u\n", nm->m, nm->n);
> else
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/5] drm/i915/gvt: Dmabuf support for GVT-g
On Thu, May 25, 2017 at 02:28:25PM +0100, Chris Wilson wrote:
> On Tue, May 23, 2017 at 06:32:00PM +0800, Xiaoguang Chen wrote:
> > + gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
> > + (fb_gma >> PAGE_SHIFT);
> > + for_each_sg(st->sgl, sg, fb_size, i) {
> > + sg->offset = 0;
> > + sg->length = PAGE_SIZE;
> > + sg_dma_address(sg) =
> > + GEN8_DECODE_PTE(readq(>t_entries[i]));
> > + sg_dma_len(sg) = PAGE_SIZE;
>
> This assumes that the entries are PAGE_SIZE. This will not remain true.
Ok, we will only be supporting different page sizes for ppgtt. However,
it is probably better to use I915_GTT_PAGE_SIZE to match our insertions.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Do not drop pagetables when empty
From: Chris Wilson
This is the minimal backport for stable of the upstream commit:
commit dd19674bacba227ae5d3ce680cbc5668198894dc
Author: Chris Wilson
Date: Wed Feb 15 08:43:46 2017 +
drm/i915: Remove bitmap tracking for used-ptes
Due to a race with the shrinker, when we try to allocate a pagetable, we
may end up shrinking it instead. This comes as a nasty surprise as we
try to dereference it to fill in the pagetable entries for the object.
In linus/master this is fixed by pinning the pagetables prior to
allocation, but that backport is roughly
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_gem_evict.c | 12 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 2017 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 123 +-
drivers/gpu/drm/i915/i915_trace.h | 104 --
drivers/gpu/drm/i915/i915_vgpu.c |9 +-
drivers/gpu/drm/i915/i915_vma.c |9 -
drivers/gpu/drm/i915/intel_lrc.c |4 +-
8 files changed, 946 insertions(+), 1334 deletions(-)
i.e. unsuitable for stable. Instead we neuter the code that tried to
free the pagetables.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99295
Fixes: 2ce5179fe826 ("drm/i915/gtt: Free unused lower-level page tables")
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuoppala
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michał Winiarski
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.10+
Tested-by: Maël Lavault
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 96e45a4d5441..4f581adf2fcf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -755,10 +755,6 @@ static bool gen8_ppgtt_clear_pt(struct i915_address_space
*vm,
GEM_BUG_ON(pte_end > GEN8_PTES);
bitmap_clear(pt->used_ptes, pte, num_entries);
- if (USES_FULL_PPGTT(vm->i915)) {
- if (bitmap_empty(pt->used_ptes, GEN8_PTES))
- return true;
- }
pt_vaddr = kmap_px(pt);
@@ -798,9 +794,6 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space
*vm,
}
}
- if (bitmap_empty(pd->used_pdes, I915_PDES))
- return true;
-
return false;
}
@@ -829,9 +822,6 @@ static bool gen8_ppgtt_clear_pdp(struct i915_address_space
*vm,
mark_tlbs_dirty(ppgtt);
- if (bitmap_empty(pdp->used_pdpes, I915_PDPES_PER_PDP(dev_priv)))
- return true;
-
return false;
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 5/7] drm/cec: Add CEC over Aux register definitions
On Thu, 25 May 2017, Hans Verkuil wrote: > From: Clint Taylor > > Adding DPCD register definitions from the DP 1.3 specification for CEC > over AUX support. > > V2: Add DP_ prefix to all defines. > V3: missed prefixes from the ESI1 defines > > Cc: Jani Nikula > > Reviewed-by: Jani Nikula > Signed-off-by: Clint Taylor > Signed-off-by: Jani Nikula > Link: > http://patchwork.freedesktop.org/patch/msgid/1492703263-11494-1-git-send-email-clinton.a.tay...@intel.com This one's already in drm-next as commit d753e41d475421543eaaea5f0feadba827f5fa01 Author: Clint Taylor Date: Thu Apr 20 08:47:43 2017 -0700 drm/cec: Add CEC over Aux register definitions BR, Jani. > --- > include/drm/drm_dp_helper.h | 59 > + > 1 file changed, 59 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index c0bd0d7651a9..3f4ad709534e 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -603,6 +603,9 @@ > #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 0x2003 /* 1.2 */ > > #define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 0x2004 /* 1.2 */ > +# define DP_RX_GTC_MSTR_REQ_STATUS_CHANGE(1 << 0) > +# define DP_LOCK_ACQUISITION_REQUEST (1 << 1) > +# define DP_CEC_IRQ (1 << 2) > > #define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */ > > @@ -636,6 +639,62 @@ > # define DP_VSC_EXT_CEA_SDP_SUPPORTED(1 << 6) /* DP > 1.4 */ > # define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP > 1.4 */ > > +/* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */ > +#define DP_CEC_TUNNELING_CAPABILITY0x3000 > +# define DP_CEC_TUNNELING_CAPABLE (1 << 0) > +# define DP_CEC_SNOOPING_CAPABLE(1 << 1) > +# define DP_CEC_MULTIPLE_LA_CAPABLE (1 << 2) > + > +#define DP_CEC_TUNNELING_CONTROL 0x3001 > +# define DP_CEC_TUNNELING_ENABLE(1 << 0) > +# define DP_CEC_SNOOPING_ENABLE (1 << 1) > + > +#define DP_CEC_RX_MESSAGE_INFO 0x3002 > +# define DP_CEC_RX_MESSAGE_LEN_MASK (0xf << 0) > +# define DP_CEC_RX_MESSAGE_LEN_SHIFT0 > +# define DP_CEC_RX_MESSAGE_HPD_STATE(1 << 4) > +# define DP_CEC_RX_MESSAGE_HPD_LOST (1 << 5) > +# define DP_CEC_RX_MESSAGE_ACKED(1 << 6) > +# define DP_CEC_RX_MESSAGE_ENDED(1 << 7) > + > +#define DP_CEC_TX_MESSAGE_INFO 0x3003 > +# define DP_CEC_TX_MESSAGE_LEN_MASK (0xf << 0) > +# define DP_CEC_TX_MESSAGE_LEN_SHIFT0 > +# define DP_CEC_TX_RETRY_COUNT_MASK (0x7 << 4) > +# define DP_CEC_TX_RETRY_COUNT_SHIFT4 > +# define DP_CEC_TX_MESSAGE_SEND (1 << 7) > + > +#define DP_CEC_TUNNELING_IRQ_FLAGS 0x3004 > +# define DP_CEC_RX_MESSAGE_INFO_VALID (1 << 0) > +# define DP_CEC_RX_MESSAGE_OVERFLOW (1 << 1) > +# define DP_CEC_TX_MESSAGE_SENT (1 << 4) > +# define DP_CEC_TX_LINE_ERROR (1 << 5) > +# define DP_CEC_TX_ADDRESS_NACK_ERROR (1 << 6) > +# define DP_CEC_TX_DATA_NACK_ERROR (1 << 7) > + > +#define DP_CEC_LOGICAL_ADDRESS_MASK0x300E /* 0x300F word */ > +# define DP_CEC_LOGICAL_ADDRESS_0 (1 << 0) > +# define DP_CEC_LOGICAL_ADDRESS_1 (1 << 1) > +# define DP_CEC_LOGICAL_ADDRESS_2 (1 << 2) > +# define DP_CEC_LOGICAL_ADDRESS_3 (1 << 3) > +# define DP_CEC_LOGICAL_ADDRESS_4 (1 << 4) > +# define DP_CEC_LOGICAL_ADDRESS_5 (1 << 5) > +# define DP_CEC_LOGICAL_ADDRESS_6 (1 << 6) > +# define DP_CEC_LOGICAL_ADDRESS_7 (1 << 7) > +#define DP_CEC_LOGICAL_ADDRESS_MASK_2 0x300F /* 0x300E word */ > +# define DP_CEC_LOGICAL_ADDRESS_8 (1 << 0) > +# define DP_CEC_LOGICAL_ADDRESS_9 (1 << 1) > +# define DP_CEC_LOGICAL_ADDRESS_10 (1 << 2) > +# define DP_CEC_LOGICAL_ADDRESS_11 (1 << 3) > +# define DP_CEC_LOGICAL_ADDRESS_12 (1 << 4) > +# define DP_CEC_LOGICAL_ADDRESS_13 (1 << 5) > +# define DP_CEC_LOGICAL_ADDRESS_14 (1 << 6) > +# define DP_CEC_LOGICAL_ADDRESS_15 (1 << 7) > + > +#define DP_CEC_RX_MESSAGE_BUFFER 0x3010 > +#define DP_CEC_TX_MESSAGE_BUFFER 0x3020 > +#define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10 > + > /* DP 1.2 Sideband message defines */ > /* peer device type - DP 1.2a Table 2-92 */ > #define DP_PEER_DEVICE_NONE 0x0 -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] New "RPM wakelock ref not held during HW access" in 4.12-rc1 ?
Hi,
On 18-05-17 15:59, Hans de Goede wrote:
Hi,
On 16-05-17 12:34, Jani Nikula wrote:
On Tue, 16 May 2017, Ville Syrjälä wrote:
mn Tue, May 16, 2017 at 10:47:48AM +0300, Jani Nikula wrote:
On Mon, 15 May 2017, Hans de Goede wrote:
Hi,
I'm seeing this on suspend/resume on a GPD-win,
cherrytrail z8700 device:
ebf5f921478b ("drm/i915: Stop pretending to mask/unmask LPE audio
interrupts") is a more likely candidate.
I can confirm that that patch does fix this.
Is that applicable to v4.12-rc1?
I added it to my 4.12-rc1 based tree with a simple git cherry-pick
without any conflicts, so from a does it apply pov yes it is
applicable. If it is a good idea to merge it into 4.12-rc#, I don't
know.
I've been running with commit ebf5f921478b cherry picked into my
kernel for a while now on multiple Bay and Cherry Trail devices,
and it fixes the below oops on suspend resume.
Can we get this commit cherry-picked into fixes please ?
Note this is masking the other oops I reported since we only report
one of these per suspend/resume, which is likely why no-one else is
reporting the other oops.
Regards,
Hans
[ 75.514651] RPM wakelock ref not held during HW access
[ 75.514827] [ cut here ]
[ 75.515025] WARNING: CPU: 2 PID: 1832 at
drivers/gpu/drm/i915/intel_drv.h:1780 fwtable_write32+0x1d3/0x240 [i915]
...
[ 75.515704] RIP: 0010:fwtable_write32+0x1d3/0x240 [i915]
...
[ 75.515767] Call Trace:
[ 75.515952] lpe_audio_irq_unmask+0x6a/0xc0 [i915]
[ 75.515972] irq_enable+0x3a/0x50
[ 75.515984] __enable_irq+0x34/0x60
[ 75.515996] resume_irqs+0x8f/0xd0
[ 75.516007] resume_device_irqs+0x10/0x20
[ 75.516021] dpm_resume_noirq+0x23e/0x310
[ 75.516041] suspend_devices_and_enter+0x2f3/0x7f0
[ 75.516055] ? finish_wait+0x80/0x80
[ 75.516067] pm_suspend+0x335/0x3a0
[ 75.516078] state_store+0x85/0xf0
[ 75.516095] kobj_attr_store+0xf/0x20
[ 75.516108] sysfs_kf_write+0x37/0x40
[ 75.516117] kernfs_fop_write+0x11c/0x1a0
[ 75.516132] __vfs_write+0x37/0x160
[ 75.516145] ? selinux_file_permission+0xfb/0x120
[ 75.516158] ? security_file_permission+0x3b/0xc0
[ 75.516169] vfs_write+0xb1/0x1a0
[ 75.516180] SyS_write+0x55/0xc0
[ 75.516197] entry_SYSCALL_64_fastpath+0x1a/0xa5
...
[ 76.584235] PM: early resume of devices complete after 1067.477 msecs
If someone has a fix for this they want me to try, let me know.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND 5/6] drm/msm: remove mdp5_cursor_plane_funcs
On 05/26/2017 01:21 AM, Gustavo Padovan wrote:
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.
Tested-by: Archit Taneja
Cc: Rob Clark
Cc: Archit Taneja
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 07106c1..794ca07 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -247,19 +247,6 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
.atomic_print_state = mdp5_plane_atomic_print_state,
};
-static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
- .update_plane = drm_atomic_helper_update_plane,
- .disable_plane = drm_atomic_helper_disable_plane,
- .destroy = mdp5_plane_destroy,
- .set_property = drm_atomic_helper_plane_set_property,
- .atomic_set_property = mdp5_plane_atomic_set_property,
- .atomic_get_property = mdp5_plane_atomic_get_property,
- .reset = mdp5_plane_reset,
- .atomic_duplicate_state = mdp5_plane_duplicate_state,
- .atomic_destroy_state = mdp5_plane_destroy_state,
- .atomic_print_state = mdp5_plane_atomic_print_state,
-};
-
static int mdp5_plane_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
@@ -,16 +1098,9 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
spin_lock_init(&mdp5_plane->pipe_lock);
- if (type == DRM_PLANE_TYPE_CURSOR)
- ret = drm_universal_plane_init(dev, plane, 0xff,
- &mdp5_cursor_plane_funcs,
- mdp5_plane->formats, mdp5_plane->nformats,
- type, NULL);
- else
- ret = drm_universal_plane_init(dev, plane, 0xff,
- &mdp5_plane_funcs,
- mdp5_plane->formats, mdp5_plane->nformats,
- type, NULL);
+ ret = drm_universal_plane_init(dev, plane, 0xff, &mdp5_plane_funcs,
+ mdp5_plane->formats,
+ mdp5_plane->nformats, type, NULL);
if (ret)
goto fail;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND 4/6] drm/msm: update cursors asynchronously through atomic
On 05/26/2017 01:21 AM, Gustavo Padovan wrote:
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.
Tested-by: Archit Taneja
v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja)
v3: move size checks back to drivers (Ville Syrjälä)
v2: move fb setting to core and use new state (Eric Anholt)
Cc: Rob Clark
Cc: Archit Taneja
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 151 +-
drivers/gpu/drm/msm/msm_atomic.c | 6 ++
2 files changed, 69 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index a38c5fe..07106c1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -33,15 +33,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest);
-static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
- struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h,
- struct drm_modeset_acquire_ctx *ctx);
-
static struct mdp5_kms *get_kms(struct drm_plane *plane)
{
struct msm_drm_private *priv = plane->dev->dev_private;
@@ -257,7 +248,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
};
static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
- .update_plane = mdp5_update_cursor_plane_legacy,
+ .update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = mdp5_plane_destroy,
.set_property = drm_atomic_helper_plane_set_property,
@@ -484,11 +475,73 @@ static void mdp5_plane_atomic_update(struct drm_plane
*plane,
}
}
+static int mdp5_plane_atomic_async_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+ struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+ state->crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ if (!crtc_state->active)
+ return -EINVAL;
+
+ mdp5_state = to_mdp5_plane_state(state);
+
+ /* don't use fast path if we don't have a hwpipe allocated yet */
+ if (!mdp5_state->hwpipe)
+ return -EINVAL;
+
+ /* only allow changing of position(crtc x/y or src x/y) in fast path */
+ if (plane->state->crtc != state->crtc ||
+ plane->state->src_w != state->src_w ||
+ plane->state->src_h != state->src_h ||
+ plane->state->crtc_w != state->crtc_w ||
+ plane->state->crtc_h != state->crtc_h ||
+ !plane->state->fb ||
+ plane->state->fb != state->fb)
+ return -EINVAL;
+
+ return 0;
+}
+
+static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+ plane->state->src_x = new_state->src_x;
+ plane->state->src_y = new_state->src_y;
+ plane->state->crtc_x = new_state->crtc_x;
+ plane->state->crtc_y = new_state->crtc_y;
+
+ if (plane_enabled(new_state)) {
+ struct mdp5_ctl *ctl;
+ struct mdp5_pipeline *pipeline =
+ mdp5_crtc_get_pipeline(plane->crtc);
+ int ret;
+
+ ret = mdp5_plane_mode_set(plane, new_state->crtc, new_state->fb,
+ &new_state->src, &new_state->dst);
+ WARN_ON(ret < 0);
+
+ ctl = mdp5_crtc_get_ctl(new_state->crtc);
+
+ mdp5_ctl_commit(ctl, pipeline, mdp5_plane_get_flush(plane));
+ }
+
+ *to_mdp5_plane_state(plane->state) =
+ *to_mdp5_plane_state(new_state);
+}
+
static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
.prepare_fb = mdp5_plane_prepare_fb,
.cleanup_fb = mdp5_plane_cleanup_fb,
.atomic_check = mdp5_plane_atomic_check,
.atomic_update = mdp5_plane_atomic_update,
+ .atomic_async_check = mdp5_plane_atomic_async_check,
+ .atomic_async_update = mdp5_plane_atomic_async_update,
};
static void set_scanout_locked(struct mdp5_kms *mdp5_kms,
@@ -997,84 +1050,6 @@ static int mdp5
Re: [Intel-gfx] [PATCH RESEND 1/6] drm/atomic: initial support for asynchronous plane update
On 05/26/2017 01:21 AM, Gustavo Padovan wrote:
From: Gustavo Padovan
In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we update the
cursor synchronously through the atomic API it will cause significant
delays that would even be noticed by the final user.
This patch creates a fast path to jump ahead the current queued state and
do single planes updates without going through all atomic steps in
drm_atomic_helper_commit(). We take this path for legacy cursor updates.
For now only single plane updates are supported, but we plan to support
multiple planes updates and async PageFlips through this interface as well
in the near future.
Reviewed-by: Archit Taneja
v4:
- fix state->crtc NULL check (Archit Taneja)
v3:
- fix iteration on the wrong crtc state
- put back code to forbid updates if there is a queued update for
the same plane (Ville Syrjälä)
- move size checks back to drivers (Ville Syrjälä)
- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)
v2:
- allow updates even if there is a queued update for the same
plane.
- fixes on the documentation (Emil Velikov)
- unconditionally call ->atomic_async_update (Emil Velikov)
- check for ->atomic_async_update earlier (Daniel Vetter)
- make ->atomic_async_check() the last step (Daniel Vetter)
- add ASYNC_UPDATE flag (Eric Anholt)
- update state in core after ->atomic_async_update (Eric Anholt)
- update docs (Eric Anholt)
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Eric Anholt
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic.c | 65
drivers/gpu/drm/drm_atomic_helper.c | 35 +
include/drm/drm_atomic.h | 2 +
include/drm/drm_atomic_helper.h | 2 +
include/drm/drm_modeset_helper_vtables.h | 48 +++
5 files changed, 152 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index be62774..2a0c297 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -631,6 +631,68 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
return 0;
}
+static bool drm_atomic_async_check(struct drm_atomic_state *state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc_commit *commit;
+ struct drm_plane *__plane, *plane = NULL;
+ struct drm_plane_state *__plane_state, *plane_state = NULL;
+ const struct drm_plane_helper_funcs *funcs;
+ int i, j, n_planes = 0;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ if (drm_atomic_crtc_needs_modeset(crtc_state))
+ return false;
+ }
+
+ for_each_new_plane_in_state(state, __plane, __plane_state, i) {
+ n_planes++;
+ plane = __plane;
+ plane_state = __plane_state;
+ }
+
+ /* FIXME: we support only single plane updates for now */
+ if (!plane || n_planes != 1)
+ return false;
+
+ if (!plane_state->crtc)
+ return false;
+
+ funcs = plane->helper_private;
+ if (!funcs->atomic_async_update)
+ return false;
+
+ if (plane_state->fence)
+ return false;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ if (plane->crtc != crtc)
+ continue;
+
+ spin_lock(&crtc->commit_lock);
+ commit = list_first_entry_or_null(&crtc->commit_list,
+ struct drm_crtc_commit,
+ commit_entry);
+ if (!commit) {
+ spin_unlock(&crtc->commit_lock);
+ continue;
+ }
+ spin_unlock(&crtc->commit_lock);
+
+ if (!crtc->state->state)
+ continue;
+
+ for_each_plane_in_state(crtc->state->state, __plane,
+ __plane_state, j) {
+ if (__plane == plane)
+ return false;
+ }
+ }
+
+ return !funcs->atomic_async_check(plane, plane_state);
+}
+
static void drm_atomic_crtc_print_state(struct drm_printer *p,
const struct drm_crtc_state *state)
{
@@ -1591,6 +1653,9 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
+ if (state->legacy_cursor_update)
+ state->async_update = drm_atomic_async_check(state);
+
return ret;
}
EXPORT_SYMBOL(drm_atomic_check_only);
diff --git a/d
Re: [Intel-gfx] New "RPM wakelock ref not held during HW access" in 4.12-rc1 ?
On Fri, 26 May 2017, Hans de Goede wrote:
> Hi,
>
> On 18-05-17 15:59, Hans de Goede wrote:
>> Hi,
>>
>> On 16-05-17 12:34, Jani Nikula wrote:
>>> On Tue, 16 May 2017, Ville Syrjälä wrote:
mn Tue, May 16, 2017 at 10:47:48AM +0300, Jani Nikula wrote:
> On Mon, 15 May 2017, Hans de Goede wrote:
>> Hi,
>>
>> I'm seeing this on suspend/resume on a GPD-win,
>> cherrytrail z8700 device:
>
>
>
ebf5f921478b ("drm/i915: Stop pretending to mask/unmask LPE audio
interrupts") is a more likely candidate.
>>
>> I can confirm that that patch does fix this.
>>
>>> Is that applicable to v4.12-rc1?
>>
>> I added it to my 4.12-rc1 based tree with a simple git cherry-pick
>> without any conflicts, so from a does it apply pov yes it is
>> applicable. If it is a good idea to merge it into 4.12-rc#, I don't
>> know.
>
> I've been running with commit ebf5f921478b cherry picked into my
> kernel for a while now on multiple Bay and Cherry Trail devices,
> and it fixes the below oops on suspend resume.
>
> Can we get this commit cherry-picked into fixes please ?
Done, with your Tested-by. I expect it to hit -rc4.
> Note this is masking the other oops I reported since we only report
> one of these per suspend/resume, which is likely why no-one else is
> reporting the other oops.
I fail, what's the other oops?
Thanks,
Jani.
>
>
> Regards,
>
> Hans
>
>
>> [ 75.514651] RPM wakelock ref not held during HW access
>> [ 75.514827] [ cut here ]
>> [ 75.515025] WARNING: CPU: 2 PID: 1832 at
>> drivers/gpu/drm/i915/intel_drv.h:1780 fwtable_write32+0x1d3/0x240 [i915]
>> ...
>> [ 75.515704] RIP: 0010:fwtable_write32+0x1d3/0x240 [i915]
>> ...
>> [ 75.515767] Call Trace:
>> [ 75.515952] lpe_audio_irq_unmask+0x6a/0xc0 [i915]
>> [ 75.515972] irq_enable+0x3a/0x50
>> [ 75.515984] __enable_irq+0x34/0x60
>> [ 75.515996] resume_irqs+0x8f/0xd0
>> [ 75.516007] resume_device_irqs+0x10/0x20
>> [ 75.516021] dpm_resume_noirq+0x23e/0x310
>> [ 75.516041] suspend_devices_and_enter+0x2f3/0x7f0
>> [ 75.516055] ? finish_wait+0x80/0x80
>> [ 75.516067] pm_suspend+0x335/0x3a0
>> [ 75.516078] state_store+0x85/0xf0
>> [ 75.516095] kobj_attr_store+0xf/0x20
>> [ 75.516108] sysfs_kf_write+0x37/0x40
>> [ 75.516117] kernfs_fop_write+0x11c/0x1a0
>> [ 75.516132] __vfs_write+0x37/0x160
>> [ 75.516145] ? selinux_file_permission+0xfb/0x120
>> [ 75.516158] ? security_file_permission+0x3b/0xc0
>> [ 75.516169] vfs_write+0xb1/0x1a0
>> [ 75.516180] SyS_write+0x55/0xc0
>> [ 75.516197] entry_SYSCALL_64_fastpath+0x1a/0xa5
>> ...
>> [ 76.584235] PM: early resume of devices complete after 1067.477 msecs
>>
>> If someone has a fix for this they want me to try, let me know.
>>
>> Regards,
>>
>> Hans
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
>>>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] New "RPM wakelock ref not held during HW access" in 4.12-rc1 ?
Hi,
On 26-05-17 10:55, Jani Nikula wrote:
On Fri, 26 May 2017, Hans de Goede wrote:
Hi,
On 18-05-17 15:59, Hans de Goede wrote:
Hi,
On 16-05-17 12:34, Jani Nikula wrote:
On Tue, 16 May 2017, Ville Syrjälä wrote:
mn Tue, May 16, 2017 at 10:47:48AM +0300, Jani Nikula wrote:
On Mon, 15 May 2017, Hans de Goede wrote:
Hi,
I'm seeing this on suspend/resume on a GPD-win,
cherrytrail z8700 device:
ebf5f921478b ("drm/i915: Stop pretending to mask/unmask LPE audio
interrupts") is a more likely candidate.
I can confirm that that patch does fix this.
Is that applicable to v4.12-rc1?
I added it to my 4.12-rc1 based tree with a simple git cherry-pick
without any conflicts, so from a does it apply pov yes it is
applicable. If it is a good idea to merge it into 4.12-rc#, I don't
know.
I've been running with commit ebf5f921478b cherry picked into my
kernel for a while now on multiple Bay and Cherry Trail devices,
and it fixes the below oops on suspend resume.
Can we get this commit cherry-picked into fixes please ?
Done, with your Tested-by. I expect it to hit -rc4.
Thank you.
Note this is masking the other oops I reported since we only report
one of these per suspend/resume, which is likely why no-one else is
reporting the other oops.
I fail, what's the other oops?
https://www.spinics.net/lists/intel-gfx/msg128453.html
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use a cached mapping for the physical HWS
On Fri, May 26, 2017 at 10:18:30AM +0200, Daniel Vetter wrote: > On Mon, May 22, 2017 at 10:13:44AM +0100, Chris Wilson wrote: > > On Mon, May 22, 2017 at 10:55:01AM +0200, Daniel Vetter wrote: > > > On Wed, May 17, 2017 at 02:02:50PM +0100, Chris Wilson wrote: > > > > Older gen use a physical address for the hardware status page, for which > > > > we use cache-coherent writes. As the writes are into the cpu cache, we > > > > use > > > > a normal WB mapped page to read the HWS, used for our seqno tracking. > > > > > > > > Anecdotally, I observed lost breadcrumbs writes into the HWS on i965gm, > > > > which so far have not reoccurred with this patch. How reliable that > > > > evidence is remains to be seen. > > > > > > > > Signed-off-by: Chris Wilson > > > > > > dma is assumed to be coherent, so this should give you the same thing in > > > the end. > > > > Hmm, DMA historically hasn't been coherent, to get coherency required > > UC - being able to snoop was an ability of the GMCH, I thought. Looking > > at drivers/base/dma-coherent.c it is allocating UC (WC if you are > > lucky) from a device region, though I'm lost working out how the dynamic > > allocaton is treated. > > Yes, gpu dma wasn't coherent, but x86 dma api always assumed that > everything is coherent (since for non-gpus that was the case). At least > that's how I thought things worked. But it can only be coherent by disabling the cpu cache for that range. I think Broadwell is the earliest that allowed pci-e devices to write into the CPU cache (specifically to support 10G nic iirc), but I can't remember if that came to pass. > > > Except that dma_map_page can use bounce buffers, whereas > > > dma_alloc_coherent will make sure you're not doing that. > > > > Hmm, on these machines we don't have DMAR, we really should be feeding > > in physical addresses. That was probably being too polite. Fancy > > without? > > Not sure what you mean ... page_to_pfn, plus comment? See v3, just feed in the physical address of the page (and not the kernel's page_address()) which is just its pfn << PAGE_SHIFT. Completely avoid passing it a dma mapped address, just in case it does something. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gvt: Return -EIO if host enable_execlists not enabled when loading GVT-g
On Fri, May 26, 2017 at 11:04:18AM +0800, Chuanxiao Dong wrote:
> GVT-g relies on the enable_execlists parameter in i915. If this option
> is not enabled for GVT-g, should return -EIO to make i915 driver loading
> failed.
>
> Suggested-by: Joonas Lahtinen
> Cc: Joonas Lahtinen
> Signed-off-by: Chuanxiao Dong
> ---
> drivers/gpu/drm/i915/intel_gvt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> b/drivers/gpu/drm/i915/intel_gvt.c
> index dde9c78..c90d476 100644
> --- a/drivers/gpu/drm/i915/intel_gvt.c
> +++ b/drivers/gpu/drm/i915/intel_gvt.c
> @@ -97,7 +97,7 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
>
> if (!i915.enable_execlists) {
> DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to
> disabled execlist submission [i915.enable_execlists module parameter]\n");
> - goto bail;
> + return -EIO;
Hmm, interesting debate as to whether or not you still want to set
i915.enable_gvt=0 to indicate gvt being lost. Since this will cause the
driver to fail to load, it should be now DRM_ERROR("and the error
message changed to reflect the fatal failure!") and having modprobe
report -EIO with i915.enable_gvt still to 1 seems like the best approach.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gvt: Return -EIO if host GuC submission is enabled when loading GVT-g
On Fri, May 26, 2017 at 11:04:19AM +0800, Chuanxiao Dong wrote:
> Currently GVT-g cannot work properly when host GuC submission is
> enabled, so make i915 driver loading failed in this case.
>
> Suggested-by: Joonas Lahtinen
> Suggested-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: Zhenyu Wang
> Signed-off-by: Chuanxiao Dong
> ---
> drivers/gpu/drm/i915/intel_gvt.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> b/drivers/gpu/drm/i915/intel_gvt.c
> index c90d476..63bff89 100644
> --- a/drivers/gpu/drm/i915/intel_gvt.c
> +++ b/drivers/gpu/drm/i915/intel_gvt.c
> @@ -100,6 +100,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
> return -EIO;
> }
>
> + if (i915.enable_guc_submission) {
> + DRM_INFO("Graphics virtualization is not yet supported with GuC
> submission");
> + return -EIO;
> + }
Again, this is an actual DRM_ERROR as it is fatal.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Defined NM doesn't work on KBL and uses automatic N/M.
Hi, Jani
Thanks for your comment. My comment below.
-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Friday, May 26, 2017 4:31 PM
To: Wang, Quanxian ; intel-gfx@lists.freedesktop.org
Cc: Yang, Libin ; Wang, Quanxian
Subject: Re: [PATCH] Defined NM doesn't work on KBL and uses automatic N/M.
On Fri, 26 May 2017, Quanxian Wang wrote:
> According to the bspec, when set N/M, should disable and enable
> transcoder which attaching DP audio. However with that implementation
> will affect performance more.
>
> But with current implementation, KBL could not work with defined N/M.
> By default, KBL will use automatic N/M.
>
> Signed-off-by: Quanxian Wang
> Reviewed-by: Libin Yang
> Reviewed-by: Jani Nikula
I have *NOT* reviewed this patch. Even if it's based on my suggestion in [1],
it does not automatically signify review.
[Wang, Quanxian] Sorry, I accept your suggestion. So in order to respect what
you said, I input your name here.
The patch subject should start with "drm/i915/audio:".
[Wang, Quanxian] Ok.
The DP spec always expresses the values as M/N, more specifically Maud/Naud, so
it's confusing to see them expressed as N/M.
[Wang, Quanxian] accept it.
I still have trouble understanding the commit message. I am wondering if
something was fixed in Kabylake and beyond, since according to
[Wang, Quanxian] in Ubuntu 17.04, we do audio testing on KBL/SKL/APL and more,
the audio doesn't work on KBL specially, and other platform works fine. Even if
with latest upstream kernel, but it works on 4.8 kernel. Therefore It is a
regression issue. After investigation, we found it is caused by commit
"6014ac122ed081feca99217bc57b2e15c7fc1a51] drm/i915/audio: set proper N/M in
modeset". Therefore I provided this patch.
After getting suggestion from you and Libin, we do more testing on 4K monitor
for audio delay issue. Also talked with Libin why not use transcoder
disable/enable process described in bspec, it will affect performance.
This is the whole story. You can check LCK number 3791 in Intel JIRA about that.
6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset") we need this for
certain modes. In particular, should the condition check for KBL || gen >= 10?
[Wang, Quanxian] Basically if upstream could provide a reasonable patch, it
will appreciate since you are expert in this area.
Thanks for your understanding.
BR,
Jani.
[1] http://mid.mail-archive.com/87pogs1lz7.fsf@intel.com
> ---
> drivers/gpu/drm/i915/intel_audio.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index d805b6e..ba4994e 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -289,6 +289,10 @@ hsw_dp_audio_config_update(struct intel_crtc
> *intel_crtc, enum port port,
> enum pipe pipe = intel_crtc->pipe;
> u32 tmp;
>
> + /* It doesn't work on KBL and uses automatic N/M. */
> + if (IS_KABYLAKE(dev_priv))
> + nm = NULL;
> +
> if (nm)
> DRM_DEBUG_KMS("using Maud %u, Naud %u\n", nm->m, nm->n);
> else
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: prevent generating unusable gvt build which no mpt module is selected
On Thu, 25 May 2017, "Du, Changbin" wrote: > Hi, Jani, just relized you are in i915 team. :) > >> > +menu "Intel GVT-g graphics virtualization host support" >> > + depends on DRM_I915 >> > + depends on 64BIT >> > + >> > config DRM_I915_GVT >> > -bool "Enable Intel GVT-g graphics virtualization host support" >> > -depends on DRM_I915 >> > -depends on 64BIT >> > -default n >> > -help >> > + bool "Enable Intel GVT-g graphics virtualization host support" >> > + default n >> > + depends on DRM_I915_GVT_KVMGT >> > + help >> >> With this change, you can't actually change this config option. It's >> purely subject to CONFIG_DRM_I915_GVT_KVMGT. You need to enable KVMGT to >> even see this option, but enabling it will enable this one too. You >> can't disable this before you disable KVMGT, but then disabling KVMGT >> will disable this one too. This config option becomes pointless as a >> visible option. Which isn't all that bad, considering >> Documentation/kbuild/kconfig-language.txt: >> > Jani, this is by design in this patch. We will add another xengt hypervisor > glue > layer to support XenGT. After that, enable DRM_I915_GVT only if at least one > of > KVMGT or XENGT enabled or both. Also it doesn't make sense that we only build > KVMGT/XenGT module without DRM_I915_GVT. > > Such mechanism is not as straigforward as two simple 'choice', so I agree with > 'choice' if you prefer it. As you said, it is not a big problem. > >> Note: >> select should be used with care. select will force >> a symbol to a value without visiting the dependencies. >> By abusing select you are able to select a symbol FOO even >> if FOO depends on BAR that is not set. >> In general use select only for non-visible symbols >> (no prompts anywhere) and for symbols with no dependencies. >> That will limit the usefulness but on the other hand avoid >> the illegal configurations all over. >> > Yes, we should always be carefull with 'select' and should not use it if > possible. So here I must create a 'menu' to ensure its safety. I'm trying to say, why do you make DRM_I915_GVT visible in menuconfig at all when you can't actually change it in menuconfig? BR, Jani. > >> BR, >> Jani. >> >> > Choose this option if you want to enable Intel GVT-g graphics >> > virtualization technology host support with integrated graphics. >> > With GVT-g, it's possible to have one integrated graphics >> > @@ -116,13 +119,14 @@ config DRM_I915_GVT >> > >> > config DRM_I915_GVT_KVMGT >> >tristate "Enable KVM/VFIO support for Intel GVT-g" >> > - depends on DRM_I915_GVT >> > + select DRM_I915_GVT >> >depends on KVM >> >depends on VFIO_MDEV && VFIO_MDEV_DEVICE >> >default n >> >help >> > Choose this option if you want to enable KVMGT support for >> > Intel GVT-g. >> > +endmenu >> > >> > menu "drm/i915 Debugging" >> > depends on DRM_I915 >> >> -- >> Jani Nikula, Intel Open Source Technology Center >> ___ >> intel-gvt-dev mailing list >> intel-gvt-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gvt: Return -EIO if host enable_execlists not enabled when loading GVT-g
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, May 26, 2017 5:35 PM
> To: Dong, Chuanxiao
> Cc: intel-gvt-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915/gvt: Return -EIO if host
> enable_execlists not enabled when loading GVT-g
>
> On Fri, May 26, 2017 at 11:04:18AM +0800, Chuanxiao Dong wrote:
> > GVT-g relies on the enable_execlists parameter in i915. If this option
> > is not enabled for GVT-g, should return -EIO to make i915 driver
> > loading failed.
> >
> > Suggested-by: Joonas Lahtinen
> > Cc: Joonas Lahtinen
> > Signed-off-by: Chuanxiao Dong
> > ---
> > drivers/gpu/drm/i915/intel_gvt.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> > b/drivers/gpu/drm/i915/intel_gvt.c
> > index dde9c78..c90d476 100644
> > --- a/drivers/gpu/drm/i915/intel_gvt.c
> > +++ b/drivers/gpu/drm/i915/intel_gvt.c
> > @@ -97,7 +97,7 @@ int intel_gvt_init(struct drm_i915_private
> > *dev_priv)
> >
> > if (!i915.enable_execlists) {
> > DRM_INFO("GPU guest virtualisation [GVT-g] disabled due to
> disabled execlist submission [i915.enable_execlists module parameter]\n");
> > - goto bail;
> > + return -EIO;
>
> Hmm, interesting debate as to whether or not you still want to set
> i915.enable_gvt=0 to indicate gvt being lost. Since this will cause the driver
> to fail to load, it should be now DRM_ERROR("and the error message
> changed to reflect the fatal failure!") and having modprobe report -EIO with
> i915.enable_gvt still to 1 seems like the best approach.
> -Chris
Yes, agree with keeping i915.enable_gvt to be 1, this is also the current
solution. For the error message, how about DRM_ERROR("i915 GVT-g driver loading
failed due to disabled execlists mode.\n")?
Regarding fail with -EIO, as we can take i915.enable_gvt as a single feature of
intel i915 GPU, is it still reasonable to return -EIO to disable the whole i915
driver? It is something like two features A and B in i915, as B relies on A, so
B should be disabled if detected feature A is not enable, but not just making
the whole i915 stack disabled.
Thanks
Chuanxiao
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [GIT PULL] GVT fixes for 4.12-rc3
On Thu, 25 May 2017, Zhenyu Wang wrote: > Hi, > > Please pull these two gvt fixes for 4.12, one to fix > vGPU workload cleanup in destroy and another one is > important to fix vGPU hang in stress test. Pulled, thanks. They'll make it to v4.12-rc4. BR, Jani. > > Thanks. > -- > The following changes since commit 2f720aac936dc7a301b757d3b197d86c333d59b8: > > drm/i915: don't do allocate_va_range again on PIN_UPDATE (2017-05-15 > 14:44:33 +0300) > > are available in the git repository at: > > https://github.com/01org/gvt-linux.git tags/gvt-fixes-2017-05-25 > > for you to fetch changes up to e274086e473c0cbea18051ae0a78a05f8d658f47: > > drm/i915/gvt: clean up unsubmited workloads before destroying kmem cache > (2017-05-24 10:33:37 +0800) > > > gvt-fixes-2017-05-25 > > - workload cleanup fix for vGPU destroy (Changbin) > - disable compression workaround to fix vGPU hang (Chuanxiao) > > > Changbin Du (1): > drm/i915/gvt: clean up unsubmited workloads before destroying kmem cache > > Chuanxiao Dong (1): > drm/i915/gvt: Disable compression workaround for Gen9 > > drivers/gpu/drm/i915/gvt/execlist.c | 30 -- > drivers/gpu/drm/i915/gvt/handlers.c | 30 +- > 2 files changed, 41 insertions(+), 19 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On Thu, 25 May 2017, Hans Verkuil wrote:
> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> return -EINVAL;
> }
>
> +static bool
> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
> +{
> + bool handled = false;
> +
> + for (;;) {
> + u8 cec_irq;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + &cec_irq);
> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
> + return handled;
> +
> + cec_irq &= ~DP_CEC_IRQ;
> + drm_dp_cec_irq(&intel_dp->aux);
> + handled = true;
> +
> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> + cec_irq);
> + if (ret < 0)
> + return handled;
> + }
DP sinks suck. Please add a limit to the loop.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/26/2017 12:13 PM, Jani Nikula wrote:
> On Thu, 25 May 2017, Hans Verkuil wrote:
>> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>> return -EINVAL;
>> }
>>
>> +static bool
>> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
>> +{
>> +bool handled = false;
>> +
>> +for (;;) {
>> +u8 cec_irq;
>> +int ret;
>> +
>> +ret = drm_dp_dpcd_readb(&intel_dp->aux,
>> +DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> +&cec_irq);
>> +if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
>> +return handled;
>> +
>> +cec_irq &= ~DP_CEC_IRQ;
>> +drm_dp_cec_irq(&intel_dp->aux);
>> +handled = true;
>> +
>> +ret = drm_dp_dpcd_writeb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + cec_irq);
>> +if (ret < 0)
>> +return handled;
>> +}
>
> DP sinks suck. Please add a limit to the loop.
Good to know. I wondered about that.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On 05/26/2017 09:15 AM, Daniel Vetter wrote:
> On Thu, May 25, 2017 at 05:06:26PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> Implement support for this DisplayPort feature.
>>
>> The cec device is created whenever it detects an adapter that
>> has this feature. It is only removed when a new adapter is connected
>> that does not support this. If a new adapter is connected that has
>> different properties than the previous one, then the old cec device is
>> unregistered and a new one is registered to replace the old one.
>>
>> Signed-off-by: Hans Verkuil
>
> Some small comments below.
>
>> ---
>> drivers/gpu/drm/i915/Kconfig| 11 ++
>> drivers/gpu/drm/i915/intel_dp.c | 46
>> +
>> 2 files changed, 53 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index a5cd5dacf055..f317b13a1409 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
>>Choose this option if you want to enable KVMGT support for
>>Intel GVT-g.
>>
>> +config DRM_I915_DP_CEC
>> +tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
>> +depends on DRM_I915 && CEC_CORE
>> +select DRM_DP_CEC
>> +help
>> + Choose this option if you want to enable HDMI CEC support for
>> + DisplayPort/USB-C to HDMI adapters.
>> +
>> + Note: not all adapters support this feature, and even for those
>> + that do support this often do not hook up the CEC pin.
>
> Why Kconfig? There's not anything else optional in i915.ko (except debug
> stuff ofc), since generally just not worth the pain. Also doesn't seem to
> be wired up at all :-)
It selects DRM_DP_CEC, but you're right, it can be dropped.
>
>> +
>> menu "drm/i915 Debugging"
>> depends on DRM_I915
>> depends on EXPERT
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index ee77b519835c..38e17ee2548d 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -32,6 +32,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp
>> *intel_dp)
>> static void
>> intel_dp_aux_fini(struct intel_dp *intel_dp)
>> {
>> +cec_unregister_adapter(intel_dp->aux.cec_adap);
>> kfree(intel_dp->aux.name);
>> }
>>
>> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>> return -EINVAL;
>> }
>>
>> +static bool
>> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
>> +{
>> +bool handled = false;
>> +
>> +for (;;) {
>> +u8 cec_irq;
>> +int ret;
>> +
>> +ret = drm_dp_dpcd_readb(&intel_dp->aux,
>> +DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> +&cec_irq);
>> +if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
>> +return handled;
>> +
>> +cec_irq &= ~DP_CEC_IRQ;
>> +drm_dp_cec_irq(&intel_dp->aux);
>> +handled = true;
>> +
>> +ret = drm_dp_dpcd_writeb(&intel_dp->aux,
>> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>> + cec_irq);
>> +if (ret < 0)
>> +return handled;
>> +}
>> +}
>
> Shouldn't the above be a helper in the cec library? Doesn't look i915
> specific to me at least ...
Good point, this can be moved to drm_dp_cec_irq().
>
>> +
>> static void
>> intel_dp_retrain_link(struct intel_dp *intel_dp)
>> {
>> @@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
>> intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
>> else
>> intel_dp->has_audio = drm_detect_monitor_audio(edid);
>> +cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
>> }
>>
>> static void
>> @@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>>
>> kfree(intel_connector->detect_edid);
>> intel_connector->detect_edid = NULL;
>> +cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
>>
>> intel_dp->has_audio = false;
>> }
>> @@ -4582,13 +4613,17 @@ intel_dp_long_pulse(struct intel_connector
>> *intel_connector)
>> intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
>>
>> /* Can't disconnect eDP, but you can close the lid... */
>> -if (is_edp(intel_dp))
>> +if (is_edp(intel_dp)) {
>> status = edp_detect(intel_dp);
>> -else if (intel_digital_port_connected(to_i915(dev),
>> - dp_to_dig_port(intel_dp)))
>> +} else if (intel_digital_port_connected(to_i915(dev),
>> +dp_to_dig_port(intel_dp))) {
>> status = intel_dp_detect_dpcd(intel_
[Intel-gfx] [PATCH] drm/i915/audio:Defined M/N doesn't work on KBL and uses automatic M/N.
According to the bspec, when set M/N, should disable
and enable transcoder which attaching DP audio. However
the implementation will affect performance much more.
Therefore, only KBL changed to use automatic M/N.
Testing:
DP audio testing on SKL/KBL works (MP4, speaker test case).
no audio delay in multiple resolution including 4K.
Signed-off-by: Quanxian Wang
---
drivers/gpu/drm/i915/intel_audio.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index d805b6e..ba4994e 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -289,6 +289,10 @@ hsw_dp_audio_config_update(struct intel_crtc *intel_crtc,
enum port port,
enum pipe pipe = intel_crtc->pipe;
u32 tmp;
+ /* It doesn't work on KBL and uses automatic M/N. */
+ if (IS_KABYLAKE(dev_priv))
+ nm = NULL;
+
if (nm)
DRM_DEBUG_KMS("using Maud %u, Naud %u\n", nm->m, nm->n);
else
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/3] drm/i915/guc: Introduce buffer based cmd transport
On Thu, May 25, 2017 at 10:48:19AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 25/05/17 04:36, Michal Wajdeczko wrote:
> > Buffer based command transport can replace MMIO based mechanism.
> > It may be used to perform host-2-guc and guc-to-host communication.
> >
> > Portions of this patch are based on work by:
> > Michel Thierry
> > Robert Beckett
> > Daniele Ceraolo Spurio
> >
> > v2: use gem_object_pin_map (Chris)
> > don't use DEBUG_RATELIMITED (Chris)
> > don't track action stats (Chris)
> > simplify next fence (Chris)
> > use READ_ONCE (Chris)
> > move blob allocation to new function (Chris)
> >
> > v3: use static owner id (Daniele)
> > v4: but keep channel initialization generic (Daniele)
> > and introduce owner_sub_id (Daniele)
> >
> > Signed-off-by: Michal Wajdeczko
> > Cc: Daniele Ceraolo Spurio
> > Cc: Oscar Mateo
> > Cc: Joonas Lahtinen
> > Cc: Chris Wilson
> > ---
>
> Reviewed-by: Daniele Ceraolo Spurio
>
> minor possible bikeshed below.
>
> > +
> > +/** Holds all command transport channels.
> > + *
> > + * @host_channel: main channel used by the host
> > + */
> > +struct intel_guc_ct {
> > + struct intel_guc_ct_channel host_channel;
> > + /* other channels are tbd */
> > +};
> > +
>
> We could also use an array if we modify the enum:
>
> enum {
> CTB_OWNER_HOST = 0,
> /* other channels are tbd */
> CTB_MAX_CHANNELS
> };
>
> and use:
>
> struct intel_guc_ct_channel ct_channels[CTB_MAX_CHANNELS];
>
> we can then address the host specific one with:
>
> &guc.ct_channels[CTB_OWNER_HOST];
>
I would wait with this approach until we actually introduce other
channels and have more than single entry in this array.
Thanks,
Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: prevent generating unusable gvt build which no mpt module is selected
On Fri, May 26, 2017 at 12:58:55PM +0300, Jani Nikula wrote: > On Thu, 25 May 2017, "Du, Changbin" wrote: > >> Note: > >>select should be used with care. select will force > >>a symbol to a value without visiting the dependencies. > >>By abusing select you are able to select a symbol FOO even > >>if FOO depends on BAR that is not set. > >>In general use select only for non-visible symbols > >>(no prompts anywhere) and for symbols with no dependencies. > >>That will limit the usefulness but on the other hand avoid > >>the illegal configurations all over. > >> > > Yes, we should always be carefull with 'select' and should not use it if > > possible. So here I must create a 'menu' to ensure its safety. > > I'm trying to say, why do you make DRM_I915_GVT visible in menuconfig at > all when you can't actually change it in menuconfig? > ok, that is to info the user that GVT is enabled, since DRM_I915_GVT apply to seperated i915 module. I saw similar behaviour in some driver, but cannot recall its name now... > BR, > Jani. > > > > > > >> BR, > >> Jani. > >> > >> >Choose this option if you want to enable Intel GVT-g graphics > >> >virtualization technology host support with integrated > >> > graphics. > >> >With GVT-g, it's possible to have one integrated graphics > >> > @@ -116,13 +119,14 @@ config DRM_I915_GVT > >> > > >> > config DRM_I915_GVT_KVMGT > >> > tristate "Enable KVM/VFIO support for Intel GVT-g" > >> > -depends on DRM_I915_GVT > >> > +select DRM_I915_GVT > >> > depends on KVM > >> > depends on VFIO_MDEV && VFIO_MDEV_DEVICE > >> > default n > >> > help > >> >Choose this option if you want to enable KVMGT support for > >> >Intel GVT-g. > >> > +endmenu > >> > > >> > menu "drm/i915 Debugging" > >> > depends on DRM_I915 > >> > >> -- > >> Jani Nikula, Intel Open Source Technology Center > >> ___ > >> intel-gvt-dev mailing list > >> intel-gvt-...@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev > > -- > Jani Nikula, Intel Open Source Technology Center -- Thanks, Changbin Du signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
On 05/26/2017 09:18 AM, Daniel Vetter wrote: > On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote: >> From: Hans Verkuil >> >> This adds support for the DisplayPort CEC-Tunneling-over-AUX >> feature that is part of the DisplayPort 1.3 standard. >> >> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a >> chip that has this capability actually hook up the CEC pin, so >> even though a CEC device is created, it may not actually work. >> >> Signed-off-by: Hans Verkuil >> --- >> drivers/gpu/drm/Kconfig | 3 + >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/drm_dp_cec.c | 196 >> +++ >> include/drm/drm_dp_helper.h | 24 ++ >> 4 files changed, 224 insertions(+) >> create mode 100644 drivers/gpu/drm/drm_dp_cec.c >> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index 78d7fc0ebb57..dd771ce8a3d0 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -120,6 +120,9 @@ config DRM_LOAD_EDID_FIRMWARE >>default case is N. Details and instructions how to build your own >>EDID data are given in Documentation/EDID/HOWTO.txt. >> >> +config DRM_DP_CEC >> +bool > > We generally don't bother with a Kconfig for every little bit in drm, not > worth the trouble (yes I know there's some exceptions, but somehow they're > all from soc people). Just smash this into the KMS_HELPER one and live is > much easier for drivers. Also allows you to drop the dummy inline > functions. For all other CEC implementations I have placed it under a config option. The reason is that 1) CEC is an optional feature of HDMI and you may not actually want it, and 2) enabling CEC also pulls in the cec module. I still think turning this into a drm config option makes sense. This would replace the i915 config option I made in the next patch, i.e. this config option is moved up one level. Your choice, though. > The other nitpick: Pls kernel-doc the functions exported to drivers, and > then pull them into Documentation/gpu/drm-kms-helpers.rst, next to the > existing DP helper section. Will do. BTW, do you know if it is possible to detect when a DP-to-HDMI adapter is connected as I discussed in my cover letter? That's my main open question for this patch series. Regarding the other thing I discussed in the cover letter about detecting if the CEC pin is really hooked up: I think I shouldn't try to be smart. Yes, I can try to poll for a TV, but that doesn't really say anything about whether CEC is working or not since the TV itself may not have enabled CEC (actually quite common). One alternative might be to poll and, if no TV is detected, call dev_info to let the user know that either there is no CEC-enabled TV, or the CEC pin isn't connected. I'm not sure if that helps the user or not. Regards, Hans > > Thanks, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Defined NM doesn't work on KBL and uses automatic N/M.
On Fri, 26 May 2017, "Wang, Quanxian" wrote:
> [Wang, Quanxian] in Ubuntu 17.04, we do audio testing on KBL/SKL/APL
> and more, the audio doesn't work on KBL specially, and other platform
> works fine. Even if with latest upstream kernel, but it works on 4.8
> kernel. Therefore It is a regression issue. After investigation, we
> found it is caused by commit
> "6014ac122ed081feca99217bc57b2e15c7fc1a51] drm/i915/audio: set proper
> N/M in modeset". Therefore I provided this patch.
If it's a regression, we need to backport the fix to stable kernels, and
the patch needs annotation:
Fixes: 6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset")
Cc: # v4.10+
> After getting suggestion from you and Libin, we do more testing on 4K
> monitor for audio delay issue. Also talked with Libin why not use
> transcoder disable/enable process described in bspec, it will affect
> performance.
>
> This is the whole story. You can check LCK number 3791 in Intel JIRA
> about that.
Actually, I can't. And the commit message needs to have the
explanation. I still do not know what the bug is specifically, or why
Kabylake, and only Kabylake, needs this.
> [Wang, Quanxian] Basically if upstream could provide a reasonable
> patch, it will appreciate since you are expert in this area.
> Thanks for your understanding.
The patch is probably fine. But I can't invent an explanation if I don't
know what the problem is.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/37] drm/zte: Drop drm_vblank_cleanup
On Fri, May 26, 2017 at 08:57:32AM +0200, Daniel Vetter wrote: > On Thu, May 25, 2017 at 5:01 AM, Shawn Guo wrote: > > On Wed, May 24, 2017 at 04:52:11PM +0200, Daniel Vetter wrote: > >> It again looks all cargo-culted for no good reasons. > > > > drm_vblank_cleanup() is called to release the resources allocated by > > drm_vblank_init(). I think that's the reason, no? > > Pls read the code and the last patch in this series. The drm core > already calls drm_vblank_cleanup for you, the only reason it was > exported was to handle certain usersmodesetting fallback scenarios in > radeon.ko. Ah, okay. The drm_dev_unref() in the error and unbind path will eventually triggers drm_dev_fini() where drm_vblank_cleanup() will get called. Thanks for the hint. FWIW, Acked-by: Shawn Guo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/audio:Defined M/N doesn't work on KBL and uses automatic M/N.
== Series Details == Series: drm/i915/audio:Defined M/N doesn't work on KBL and uses automatic M/N. URL : https://patchwork.freedesktop.org/series/24947/ State : warning == Summary == Series 24947v1 drm/i915/audio:Defined M/N doesn't work on KBL and uses automatic M/N. https://patchwork.freedesktop.org/api/1.0/series/24947/revisions/1/mbox/ Test kms_busy: Subgroup basic-flip-default-b: pass -> DMESG-WARN (fi-skl-6700hq) fdo#101144 +2 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: pass -> FAIL (fi-skl-6700hq) fdo#101154 +24 Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-6700hq) fdo#100867 Subgroup basic-flip-vs-wf_vblank: pass -> SKIP (fi-skl-6700hq) fdo#99739 Subgroup basic-plain-flip: pass -> SKIP (fi-skl-6700hq) Test kms_frontbuffer_tracking: Subgroup basic: pass -> SKIP (fi-skl-6700hq) fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fdo#101154 https://bugs.freedesktop.org/show_bug.cgi?id=101154 fdo#100867 https://bugs.freedesktop.org/show_bug.cgi?id=100867 fdo#99739 https://bugs.freedesktop.org/show_bug.cgi?id=99739 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:447s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:432s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:571s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:505s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:488s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:481s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:412s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:495s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:469s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:568s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-6700hqtotal:278 pass:228 dwarn:2 dfail:0 fail:26 skip:22 time:408s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:462s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:501s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:441s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:404s 6a14ef30fb2b57a909a889d51b514c1ac988af02 drm-tip: 2017y-05m-26d-08h-56m-52s UTC integration manifest 5a417c92 drm/i915/audio:Defined M/N doesn't work on KBL and uses automatic M/N. == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4817/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/gvt: Add gvt options sanitize function
On Fri, May 26, 2017 at 11:04:17AM +0800, Chuanxiao Dong wrote:
> The intel_gvt_sanitize_options will sanitize the GVT-g related
> options before doing GVT-g init.
>
> Suggested-by: Joonas Lahtinen
> Cc: Joonas Lahtinen
> Signed-off-by: Chuanxiao Dong
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 ++
> drivers/gpu/drm/i915/intel_gvt.c | 36 ++--
> drivers/gpu/drm/i915/intel_gvt.h | 5 +
> 3 files changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 72fb47a..9c59b22 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -997,6 +997,8 @@ static void intel_sanitize_options(struct
> drm_i915_private *dev_priv)
> DRM_DEBUG_DRIVER("use GPU semaphores? %s\n", yesno(i915.semaphores));
>
> intel_uc_sanitize_options(dev_priv);
> +
> + intel_gvt_sanitize_options(dev_priv);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> b/drivers/gpu/drm/i915/intel_gvt.c
> index e1ab643..dde9c78 100644
> --- a/drivers/gpu/drm/i915/intel_gvt.c
> +++ b/drivers/gpu/drm/i915/intel_gvt.c
> @@ -51,6 +51,32 @@ static bool is_supported_device(struct drm_i915_private
> *dev_priv)
> }
>
> /**
> + * intel_gvt_sanitize_options - sanitize GVT related options
> + * @dev_priv: drm i915 private data
> + *
> + * This function is called at the i915 options sanitize stage.
> + */
> +void intel_gvt_sanitize_options(struct drm_i915_private *dev_priv)
> +{
> + if (!i915.enable_gvt)
> + return;
> +
> + if (intel_vgpu_active(dev_priv)) {
> + DRM_INFO("GVT-g is disabled for guest\n");
> + goto bail;
> + }
> +
> + if (!is_supported_device(dev_priv)) {
> + DRM_INFO("Unsupported device. GVT-g is disabled\n");
> + goto bail;
> + }
Good. I came back to check that we didn't trigger an EIO if the device
wasn't supported (and only an EIO if the user gave conflicting params).
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt: Fix detection of missing flex
From: Tvrtko Ursulin
AM_PROG_FLEX macro will set the LEX variable using the missing
script when the flex is not present. This will confuse the
configure.ac check, which expects the AC_PROG_FLEX behaviour,
and will so fail to detect the missing flex:
AS_IF([test x"$LEX" != "x:" -a x"$YACC" != xyacc],
[enable_assembler=yes],
[enable_assembler=no])
This is because AM_PROG_LEX sets the LEX variable to
"${SHELL} /home/sc/intel-gpu-tools/build-aux/missing flex",
while AC_PROG_LEX would set it to ":".
If for some reason we really need to keep AM_PROG_LEX,
alternative fix could be something like this placed before
the above AS_IF check:
AC_MSG_CHECKING([checking for working flex])
if ! eval "$LEX --version >/dev/null 2>&1"; then
AC_MSG_RESULT([failed])
LEX=:
else
AC_MSG_RESULT([pass])
fi
Note the evil eval needed to recursively expand variables.
Signed-off-by: Tvrtko Ursulin
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 5342e33c8293..82857a8325b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -40,7 +40,7 @@ AM_INIT_AUTOMAKE([1.12 foreign subdir-objects dist-bzip2])
AM_PATH_PYTHON([3],, [:])
AC_PROG_CC
-AM_PROG_LEX
+AC_PROG_LEX
AC_PROG_YACC
# check for gtk-doc
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI v4 2/3] drm/i915/guc: Introduce buffer based cmd transport
Buffer based command transport can replace MMIO based mechanism.
It may be used to perform host-2-guc and guc-to-host communication.
Portions of this patch are based on work by:
Michel Thierry
Robert Beckett
Daniele Ceraolo Spurio
v2: use gem_object_pin_map (Chris)
don't use DEBUG_RATELIMITED (Chris)
don't track action stats (Chris)
simplify next fence (Chris)
use READ_ONCE (Chris)
move blob allocation to new function (Chris)
v3: use static owner id (Daniele)
v4: but keep channel initialization generic (Daniele)
and introduce owner_sub_id (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
Cc: Joonas Lahtinen
Cc: Chris Wilson
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_guc_ct.c | 461 ++
drivers/gpu/drm/i915/intel_guc_ct.h | 86 +++
drivers/gpu/drm/i915/intel_guc_fwif.h | 43
drivers/gpu/drm/i915/intel_uc.c | 19 +-
drivers/gpu/drm/i915/intel_uc.h | 3 +-
7 files changed, 613 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_guc_ct.c
create mode 100644 drivers/gpu/drm/i915/intel_guc_ct.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7b05fb8..16dccf5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -58,6 +58,7 @@ i915-y += i915_cmd_parser.o \
# general-purpose microcontroller (GuC) support
i915-y += intel_uc.o \
+ intel_guc_ct.o \
intel_guc_log.o \
intel_guc_loader.o \
intel_huc.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9ba2242..d2a5749 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -760,6 +760,7 @@ struct intel_csr {
func(has_gmbus_irq); \
func(has_gmch_display); \
func(has_guc); \
+ func(has_guc_ct); \
func(has_hotplug); \
func(has_l3_dpf); \
func(has_llc); \
@@ -2947,6 +2948,7 @@ intel_info(const struct drm_i915_private *dev_priv)
* properties, so we have separate macros to test them.
*/
#define HAS_GUC(dev_priv) ((dev_priv)->info.has_guc)
+#define HAS_GUC_CT(dev_priv) ((dev_priv)->info.has_guc_ct)
#define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
#define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
new file mode 100644
index 000..c4cbec1
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -0,0 +1,461 @@
+/*
+ * Copyright © 2016-2017 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 "i915_drv.h"
+#include "intel_guc_ct.h"
+
+enum { CTB_SEND = 0, CTB_RECV = 1 };
+
+enum { CTB_OWNER_HOST = 0 };
+
+void intel_guc_ct_init_early(struct intel_guc_ct *ct)
+{
+ /* we're using static channel owners */
+ ct->host_channel.owner = CTB_OWNER_HOST;
+}
+
+static inline const char *guc_ct_buffer_type_to_str(u32 type)
+{
+ switch (type) {
+ case INTEL_GUC_CT_BUFFER_TYPE_SEND:
+ return "SEND";
+ case INTEL_GUC_CT_BUFFER_TYPE_RECV:
+ return "RECV";
+ default:
+ return "";
+ }
+}
+
+static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
+ u32 cmds_addr, u32 size, u32 owner)
+{
+ DRM_DEBUG_DRIVER("CT: desc %p init addr=%#x size=%u owner=%u\n",
+desc, cmds_addr, size, owner);
+ memset(desc, 0, sizeof(*desc));
+ desc->addr = cmds_addr;
+ desc->size = size;
+ desc->owner = owner;
+}
+
+static void guc_ct_buffer_desc_reset(struct guc_ct_buffer_desc
[Intel-gfx] [CI v4 0/3] Introduce buffer based cmd transport
Buffer based command transport can replace MMIO based mechanism. It may be used to perform host-2-guc and guc-to-host communication. v3: using static owner id (Daniele) v4: but keep channel initialization generic (Daniele) and introduce owner_sub_id (Daniele) (1/3 added Chris r-b from IRC) (2/3 added Daniele r-b from ML) Michal Wajdeczko (3): drm/i915/guc: Disable send function on fini drm/i915/guc: Introduce buffer based cmd transport HAX Enable GuC loading & submission drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_params.c| 8 +- drivers/gpu/drm/i915/intel_guc_ct.c | 461 ++ drivers/gpu/drm/i915/intel_guc_ct.h | 86 +++ drivers/gpu/drm/i915/intel_guc_fwif.h | 43 drivers/gpu/drm/i915/intel_uc.c | 26 +- drivers/gpu/drm/i915/intel_uc.h | 3 +- 8 files changed, 623 insertions(+), 7 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_guc_ct.c create mode 100644 drivers/gpu/drm/i915/intel_guc_ct.h -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI v4 3/3] HAX Enable GuC loading & submission
This is just for CI testing, *** DO NOT MERGE ***
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e36..abd2894 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,8 +56,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
- .enable_guc_loading = 0,
- .enable_guc_submission = 0,
+ .enable_guc_loading = 1,
+ .enable_guc_submission = 1,
.guc_log_level = -1,
.guc_firmware_path = NULL,
.huc_firmware_path = NULL,
@@ -221,12 +221,12 @@ MODULE_PARM_DESC(edp_vswing,
module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int,
0400);
MODULE_PARM_DESC(enable_guc_loading,
"Enable GuC firmware loading "
- "(-1=auto, 0=never [default], 1=if available, 2=required)");
+ "(-1=auto, 0=never, 1=if available [default], 2=required)");
module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
int, 0400);
MODULE_PARM_DESC(enable_guc_submission,
"Enable GuC submission "
- "(-1=auto, 0=never [default], 1=if available, 2=required)");
+ "(-1=auto, 0=never, 1=if available [default], 2=required)");
module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
MODULE_PARM_DESC(guc_log_level,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI v4 1/3] drm/i915/guc: Disable send function on fini
In earlier patch 789a625 we were enabling send function only
after successful init. For completeness, we should make sure
that we disable it on fini.
v2: don't group steps by submission flag (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index d27b527..31dc8c3 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -410,11 +410,16 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
if (!i915.enable_guc_loading)
return;
- if (i915.enable_guc_submission) {
+ if (i915.enable_guc_submission)
i915_guc_submission_disable(dev_priv);
+
+ guc_disable_communication(&dev_priv->guc);
+
+ if (i915.enable_guc_submission) {
gen9_disable_guc_interrupts(dev_priv);
i915_guc_submission_fini(dev_priv);
}
+
i915_ggtt_disable_guc(dev_priv);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] v4.9+ stable backport request
Stable team, please backport upstream commits
665788572c64 ("drm/i915/vbt: don't propagate errors from intel_bios_init()")
bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no
VBT")
to stable kernels v4.9+. The first is a small refactor that makes the
actual fix in second easier and apply cleanly.
References:
http://mid.mail-archive.com/CAD8Lp45zcVDAAshmiBbi3VZ-Zk=bcsbwp0qw0ql8ibndo-c...@mail.gmail.com
Fixes: 0ce140d45a83 ("drm/i915: Clean up DDI DDC/AUX CH sanitation")
Tested-by: Daniel Drake
Cc: # v4.9+
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 4.9 regression: DP AUX CH sanitization no longer working on Asus desktops
On Wed, 24 May 2017, Daniel Drake wrote:
> On Fri, May 5, 2017 at 4:29 AM, Ville Syrjälä
> wrote:
>> On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
>>> On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä
>>> wrote:
>>> > Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults
>>> > that are set when there is no VBT") fixes things for you.
>>>
>>> I think this is not going to help. This would only make a difference
>>> when there is no VBT at all at which point we would see this message
>>> in the logs:
>>>
>>> DRM_INFO("Failed to find VBIOS tables (VBT)\n");
>>
>> No, the patch will in fact make a difference only when there is a VBT.
>
> We confirmed the mentioned patch fixes the issue. Apologies for
> doubting you :)
Thanks for the follow-up, I made a stable backport request [1] of the
relevant commits to v4.9+.
BR,
Jani.
[1] 87bmqfn9sp.fsf@intel.com">http://mid.mail-archive.com/87bmqfn9sp.fsf@intel.com
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for Introduce buffer based cmd transport (rev3)
== Series Details == Series: Introduce buffer based cmd transport (rev3) URL : https://patchwork.freedesktop.org/series/24786/ State : warning == Summary == Series 24786v3 Introduce buffer based cmd transport https://patchwork.freedesktop.org/api/1.0/series/24786/revisions/3/mbox/ Test kms_busy: Subgroup basic-flip-default-a: dmesg-warn -> PASS (fi-skl-6700hq) fdo#101144 +1 Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-6700hq) fdo#100867 Subgroup basic-flip-vs-wf_vblank: pass -> SKIP (fi-skl-6700hq) fdo#99739 Subgroup basic-plain-flip: pass -> SKIP (fi-skl-6700hq) Test kms_frontbuffer_tracking: Subgroup basic: pass -> SKIP (fi-skl-6700hq) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> FAIL (fi-skl-6700hq) fdo#101154 +16 Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bsw-n3050) fdo#100651 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fdo#100867 https://bugs.freedesktop.org/show_bug.cgi?id=100867 fdo#99739 https://bugs.freedesktop.org/show_bug.cgi?id=99739 fdo#101154 https://bugs.freedesktop.org/show_bug.cgi?id=101154 fdo#100651 https://bugs.freedesktop.org/show_bug.cgi?id=100651 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:436s fi-bsw-n3050 total:237 pass:204 dwarn:0 dfail:0 fail:0 skip:32 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:496s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:488s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:481s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:417s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:412s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:418s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:490s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:468s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:451s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:555s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:445s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:426s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:462s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:486s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:417s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:525s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:405s 6a14ef30fb2b57a909a889d51b514c1ac988af02 drm-tip: 2017y-05m-26d-08h-56m-52s UTC integration manifest 67cb6c3 HAX Enable GuC loading & submission 21d1923 drm/i915/guc: Introduce buffer based cmd transport aa07142 drm/i915/guc: Disable send function on fini == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4818/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX
On Fri, May 26, 2017 at 12:34 PM, Hans Verkuil wrote: >>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >>> index 78d7fc0ebb57..dd771ce8a3d0 100644 >>> --- a/drivers/gpu/drm/Kconfig >>> +++ b/drivers/gpu/drm/Kconfig >>> @@ -120,6 +120,9 @@ config DRM_LOAD_EDID_FIRMWARE >>>default case is N. Details and instructions how to build your own >>>EDID data are given in Documentation/EDID/HOWTO.txt. >>> >>> +config DRM_DP_CEC >>> +bool >> >> We generally don't bother with a Kconfig for every little bit in drm, not >> worth the trouble (yes I know there's some exceptions, but somehow they're >> all from soc people). Just smash this into the KMS_HELPER one and live is >> much easier for drivers. Also allows you to drop the dummy inline >> functions. > > For all other CEC implementations I have placed it under a config option. The > reason is that 1) CEC is an optional feature of HDMI and you may not actually > want it, and 2) enabling CEC also pulls in the cec module. > > I still think turning this into a drm config option makes sense. This would > replace the i915 config option I made in the next patch, i.e. this config > option > is moved up one level. > > Your choice, though. If there is a CEC option already, can we just reuse that one? I.e. when it's enabled, we compile the drm dp cec helpers, if it's not, you get the pile of dummy functions. drm_dp_cec.c should still be part of drm_kms_helper.ko though I think (since the dp aux stuff is in there anyway, doesn't make sense to split it). I'm still not sold on Kconfig proliferation for optional features (have one for the driver, that's imo enough), but if it exists already not going to block it's use in drm. As long as it's minimally invasive on the code and drivers don't have to care at all. -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 https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] lib/kms: Force a full reprobe if we find a bad link
If we do a shallow probe of the connector and it reports the link failed
previous (link-status != GOOD), force a full probe of the connector to
give the kernel a chance to validate the mode list.
Signed-off-by: Chris Wilson
---
lib/igt_kms.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f7758458..5f2adbdb 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -852,6 +852,26 @@ _kmstest_connector_config_find_encoder(int drm_fd,
drmModeConnector *connector,
return NULL;
}
+static bool connector_check_link_status(int fd, drmModeConnector *connector)
+{
+ for (int i = 0; i < connector->count_props; i++) {
+ struct drm_mode_get_property prop;
+
+ prop.prop_id = connector->props[i];
+ prop.count_values = 0;
+ prop.count_enum_blobs = 0;
+ if (drmIoctl(fd, DRM_IOCTL_MODE_GETPROPERTY, &prop))
+ continue;
+
+ if (strcmp(prop.name, "link-status"))
+ continue;
+
+ return connector->prop_values[i] == 0;
+ }
+
+ return true;
+}
+
/**
* _kmstest_connector_config:
* @drm_fd: DRM fd
@@ -894,6 +914,15 @@ static bool _kmstest_connector_config(int drm_fd, uint32_t
connector_id,
goto err3;
}
+ if (!probe && !connector_check_link_status(drm_fd, connector)) {
+ drmModeFreeConnector(connector);
+ connector = drmModeGetConnector(drm_fd, connector_id);
+ if (!connector)
+ goto err2;
+
+ igt_assert(connector->connector_id == connector_id);
+ }
+
/*
* Find given CRTC if crtc_id != 0 or else the first CRTC not in use.
* In both cases find the first compatible encoder and skip the CRTC
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] i2c: refactor core and break out blocks
On Fri, 26 May 2017, Wolfram Sang wrote: > Yes, I wanted to do this for years now... The I2C core became a huge > monolithic > blob getting harder and harder to maintain. This series breaks out some > functional parts into seperate files. This makes the code easier to handle > because of the smaller chunks. It reduces ifdeffery because we can now handle > compilation at the Makefile level. And it helps to spread responsibility, e.g. > the ACPI maintainers do now have a dedicated file listed in MAINTAINERS. > > This series was tested with a Renesas Lager board (R-Car H2 SoC). It booted > normally and all device drivers for I2C clients seem to work normally. I wired > two I2C busses together and used i2c-slave-eeprom to let one I2C IP core read > out data from the other. That all worked fine. Buildbot is also happy, it > found > two issues of the first (non public) iteration. Thanks! > > I did not test ACPI and hope for some assistance here :) I'd also be happy if > people could check the includes of the newly created files, there might be > missing some. If you don't mind sending the whole series to the intel-gfx list (Cc'd), our CI will run a bunch of tests on it, exercising our use of the I2C adapter interfaces for display data channel and I2C over Display Port native aux. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] lib/kms: Force a full reprobe if we find a bad link
On Fri, May 26, 2017 at 12:48:46PM +0100, Chris Wilson wrote: > If we do a shallow probe of the connector and it reports the link failed > previous (link-status != GOOD), force a full probe of the connector to > give the kernel a chance to validate the mode list. Do we also need to do a SetCrtc on top? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v14 00/14] Enable OA unit for Gen 8 and 9 in i915 perf
Hi, Here are the changes from v13 : * there is no more locking mechanism of the SSEU configuration on the whole system, instead we now make the i915 driver monitors the changes on submissions when OA is enabled and events are inserted in the perf stream to enable userspace to parse reports appropriately (this is reflected by changes in patch 6 and patch 14). * now that we let SSEU configuration be configurable per context & engine, we need to reprogram the NOA muxes in between batches when OA is enabled (patch 13). With exception of patch 6, I think patches 1 to 12 don't need much looking at. In patch 6 the only bit that actually changed is the gen8_configure_all_contexts() function. The IGT tests for this are available here : https://github.com/djdeath/intel-gpu-tools/tree/wip/djdeath/oa-next Cheers, Chris Wilson (3): drm/i915: Record both min/max eu_per_subslice in sseu_dev_info drm/i915: Program RPCS for Broadwell drm/i915: Record the sseu configuration per-context & engine Lionel Landwerlin (6): drm/i915/perf: rework mux configurations queries drm/i915: add KBL GT2/GT3 check macros drm/i915/perf: add KBL support drm/i915/perf: add GLK support drm/i915/perf: reprogram NOA muxes at the beginning of each workload drm/i915/perf: notify sseu configuration changes Robert Bragg (5): drm/i915/perf: Add 'render basic' Gen8+ OA unit configs drm/i915/perf: Add OA unit support for Gen 8+ drm/i915/perf: Add more OA configs for BDW, CHV, SKL + BXT drm/i915/perf: per-gen timebase for checking sample freq drm/i915/perf: remove perf.hook_lock drivers/gpu/drm/i915/Makefile| 11 +- drivers/gpu/drm/i915/i915_debugfs.c | 36 +- drivers/gpu/drm/i915/i915_drv.h | 125 +- drivers/gpu/drm/i915/i915_gem_context.c |9 + drivers/gpu/drm/i915/i915_gem_context.h | 42 + drivers/gpu/drm/i915/i915_oa_bdw.c | 5376 ++ drivers/gpu/drm/i915/i915_oa_bdw.h | 40 + drivers/gpu/drm/i915/i915_oa_bxt.c | 2690 +++ drivers/gpu/drm/i915/i915_oa_bxt.h | 40 + drivers/gpu/drm/i915/i915_oa_chv.c | 2873 drivers/gpu/drm/i915/i915_oa_chv.h | 40 + drivers/gpu/drm/i915/i915_oa_glk.c | 2602 +++ drivers/gpu/drm/i915/i915_oa_glk.h | 40 + drivers/gpu/drm/i915/i915_oa_hsw.c | 263 +- drivers/gpu/drm/i915/i915_oa_hsw.h |4 +- drivers/gpu/drm/i915/i915_oa_kblgt2.c| 2991 + drivers/gpu/drm/i915/i915_oa_kblgt2.h| 40 + drivers/gpu/drm/i915/i915_oa_kblgt3.c| 3040 + drivers/gpu/drm/i915/i915_oa_kblgt3.h| 40 + drivers/gpu/drm/i915/i915_oa_sklgt2.c| 3479 +++ drivers/gpu/drm/i915/i915_oa_sklgt2.h| 40 + drivers/gpu/drm/i915/i915_oa_sklgt3.c| 3039 + drivers/gpu/drm/i915/i915_oa_sklgt3.h| 40 + drivers/gpu/drm/i915/i915_oa_sklgt4.c| 3093 + drivers/gpu/drm/i915/i915_oa_sklgt4.h| 40 + drivers/gpu/drm/i915/i915_perf.c | 1622 - drivers/gpu/drm/i915/i915_reg.h | 22 + drivers/gpu/drm/i915/intel_device_info.c | 32 +- drivers/gpu/drm/i915/intel_lrc.c | 39 +- drivers/gpu/drm/i915/intel_lrc.h |2 + drivers/gpu/drm/i915/intel_ringbuffer.c |3 + include/uapi/drm/i915_drm.h | 49 +- 32 files changed, 31511 insertions(+), 291 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.c create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.h create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt2.c create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt2.h create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt3.c create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt3.h create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v14 06/14] drm/i915/perf: Add OA unit support for Gen 8+
From: Robert Bragg
Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.
Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
more complicated to manage synchronous state changes from the cpu while
there's no guarantee of what context (if any) is currently actively
running on the gpu.
The periodic sampling frequency which can be particularly useful for
system-wide analysis (as opposed to command stream synchronised
MI_REPORT_PERF_COUNT commands) is perhaps the most surprising state to
have become per-context save and restored (while the OABUFFER
destination is still a shared, system-wide resource).
This support for gen8+ takes care to consider a number of timing
challenges involved in synchronously updating per-context state
primarily by programming all config state from the cpu and updating all
current and saved contexts synchronously while the OA unit is still
disabled.
The driver intentionally avoids depending on command streamer
programming to update OA state considering the lack of synchronization
between the automatic loading of OACTXCONTROL state (that includes the
periodic sampling state and enable state) on context restore and the
parsing of any general purpose BB the driver can control. I.e. this
implementation is careful to avoid the possibility of a context restore
temporarily enabling any out-of-date periodic sampling state. In
addition to the risk of transiently-out-of-date state being loaded
automatically; there are also internal HW latencies involved in the
loading of MUX configurations which would be difficult to account for
from the command streamer (and we only want to enable the unit when once
the MUX configuration is complete).
Since the Gen8+ OA unit design no longer supports clock gating the unit
off for a single given context (which effectively stopped any progress
of counters while any other context was running) and instead supports
tagging OA reports with a context ID for filtering on the CPU, it means
we can no longer hide the system-wide progress of counters from a
non-privileged application only interested in metrics for its own
context. Although we could theoretically try and subtract the progress
of other contexts before forwarding reports via read() we aren't in a
position to filter reports captured via MI_REPORT_PERF_COUNT commands.
As a result, for Gen8+, we always require the
dev.i915.perf_stream_paranoid to be unset for any access to OA metrics
if not root.
v5: Drain submitted requests when enabling metric set to ensure no
lite-restore erases the context image we just updated (Lionel)
v6: In addition to drain, switch to kernel context & update all
context in place (Chris)
v7: Add missing mutex_unlock() if switching to kernel context fails
(Matthew)
v8: Simplify OA period/flex-eu-counters programming by using the
batchbuffer instead of modifying ctx-image (Lionel)
v9: Back to updating the context image (due to erroneous testing,
batchbuffer programming the OA unit doesn't actually work)
(Lionel)
Pin context before updating context image (Chris)
Drop MMIO programming now that we switch to a kernel context with
right values in initial context image (Chris)
v10: Just pin_map the contexts we want to modify or let the
configuration happen on first use (Chris)
v11: Update kernel context OA config through the batchbuffer rather
than on the fly ctx-image update (Lionel)
v12: Rework OA context registers update again by swithing away from
user contexts and reconfiguring the kernel context through the
batchbuffer and updating all the other contexts' context image.
Also take care to lock slice/subslice configuration when OA is
on. (Lionel)
v13: Request rpcs updates on all engine when updating the OA config
(Lionel)
v14: Drop any kind of rpcs management now that we monitor sseu
configuration changes in a later patch (Lionel)
Remove usleep after programming the NOA configs on Gen8+, this
doesn't seem to be needed (Lionel)
Signed-off-by: Robert Bragg
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld \o/
---
drivers/gpu/drm/i915/i915_drv.h | 45 +-
drivers/gpu/drm/i915/i915_perf.c | 1005 +++---
drivers/gpu/drm/i915/i915_reg.h | 22 +
drivers/gpu/drm/i915/intel_lrc.c |2 +
drivers/gpu/drm/i915/intel_lrc.h |2 +
include/uapi/drm/i915_drm.h | 19 +-
6 files changed, 1000 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index db0378b71941..84bde667bb45 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1997,9 +1997,17 @@ struct i915_oa_ops {
void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
/**
-* @enable_metric_set: Applies any MUX configuration t
[Intel-gfx] [PATCH v14 01/14] drm/i915: Record both min/max eu_per_subslice in sseu_dev_info
From: Chris Wilson
When we query the available eu on each subslice, we currently only
report the max. It would also be useful to report the minimum found as
well.
When we set RPCS (power gating over the EU), we can also specify both
the min and max number of eu to configure on each slice; currently we
just set it to a single value, but the flexibility may be beneficial in
future.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_device_info.c | 32 +---
drivers/gpu/drm/i915/intel_lrc.c | 4 ++--
4 files changed, 50 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c08a6d8a4e07..149214ba36c3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4489,6 +4489,7 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_cache_sharing_fops,
static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
{
+ unsigned int min_eu_per_subslice, max_eu_per_subslice;
int ss_max = 2;
int ss;
u32 sig1[ss_max], sig2[ss_max];
@@ -4498,6 +4499,9 @@ static void cherryview_sseu_device_status(struct
drm_i915_private *dev_priv,
sig2[0] = I915_READ(CHV_POWER_SS0_SIG2);
sig2[1] = I915_READ(CHV_POWER_SS1_SIG2);
+ min_eu_per_subslice = ~0u;
+ max_eu_per_subslice = 0;
+
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4512,14 +4516,18 @@ static void cherryview_sseu_device_status(struct
drm_i915_private *dev_priv,
((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
((sig2[ss] & CHV_EU311_PG_ENABLE) ? 0 : 2);
sseu->eu_total += eu_cnt;
- sseu->eu_per_subslice = max_t(unsigned int,
- sseu->eu_per_subslice, eu_cnt);
+ min_eu_per_subslice = min(min_eu_per_subslice, eu_cnt);
+ max_eu_per_subslice = max(max_eu_per_subslice, eu_cnt);
}
+
+ sseu->min_eu_per_subslice = min_eu_per_subslice;
+ sseu->max_eu_per_subslice = max_eu_per_subslice;
}
static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
{
+ unsigned int min_eu_per_subslice, max_eu_per_subslice;
int s_max = 3, ss_max = 4;
int s, ss;
u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
@@ -4545,6 +4553,9 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
GEN9_PGCTL_SSB_EU210_ACK |
GEN9_PGCTL_SSB_EU311_ACK;
+ min_eu_per_subslice = ~0u;
+ max_eu_per_subslice = 0;
+
for (s = 0; s < s_max; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
@@ -4570,11 +4581,14 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
eu_mask[ss%2]);
sseu->eu_total += eu_cnt;
- sseu->eu_per_subslice = max_t(unsigned int,
- sseu->eu_per_subslice,
- eu_cnt);
+
+ min_eu_per_subslice = min(min_eu_per_subslice, eu_cnt);
+ max_eu_per_subslice = max(max_eu_per_subslice, eu_cnt);
}
}
+
+ sseu->min_eu_per_subslice = min_eu_per_subslice;
+ sseu->max_eu_per_subslice = max_eu_per_subslice;
}
static void broadwell_sseu_device_status(struct drm_i915_private *dev_priv,
@@ -4587,9 +4601,11 @@ static void broadwell_sseu_device_status(struct
drm_i915_private *dev_priv,
if (sseu->slice_mask) {
sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
- sseu->eu_per_subslice =
- INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
- sseu->eu_total = sseu->eu_per_subslice *
+ sseu->min_eu_per_subslice =
+ INTEL_INFO(dev_priv)->sseu.min_eu_per_subslice;
+ sseu->max_eu_per_subslice =
+ INTEL_INFO(dev_priv)->sseu.max_eu_per_subslice;
+ sseu->eu_total = sseu->max_eu_per_subslice *
sseu_subslice_total(sseu);
/* subtract fused off EU(s) from enabled slice(s) */
@@ -4620,8 +4636,8 @@ static void i915_print_sseu_info(struct seq_file *m, bool
is_available_info,
hweight8(sseu->subslice_mask));
seq_printf(m, "
[Intel-gfx] [PATCH v14 05/14] drm/i915/perf: Add 'render basic' Gen8+ OA unit configs
From: Robert Bragg
Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic
v2: add newlines to debug messages + fix comment (Matthew Auld)
Signed-off-by: Robert Bragg
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 8 +-
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/i915_oa_bdw.c| 392 ++
drivers/gpu/drm/i915/i915_oa_bdw.h| 40
drivers/gpu/drm/i915/i915_oa_bxt.c| 248 +
drivers/gpu/drm/i915/i915_oa_bxt.h| 40
drivers/gpu/drm/i915/i915_oa_chv.c| 238 +
drivers/gpu/drm/i915/i915_oa_chv.h| 40
drivers/gpu/drm/i915/i915_oa_sklgt2.c | 238 +
drivers/gpu/drm/i915/i915_oa_sklgt2.h | 40
drivers/gpu/drm/i915/i915_oa_sklgt3.c | 249 +
drivers/gpu/drm/i915/i915_oa_sklgt3.h | 40
drivers/gpu/drm/i915/i915_oa_sklgt4.c | 260 ++
drivers/gpu/drm/i915/i915_oa_sklgt4.h | 40
14 files changed, 1876 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7b05fb802f4c..aabc660f94cb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -128,7 +128,13 @@ i915-y += i915_vgpu.o
# perf code
i915-y += i915_perf.o \
- i915_oa_hsw.o
+ i915_oa_hsw.o \
+ i915_oa_bdw.o \
+ i915_oa_chv.o \
+ i915_oa_sklgt2.o \
+ i915_oa_sklgt3.o \
+ i915_oa_sklgt4.o \
+ i915_oa_bxt.o
ifeq ($(CONFIG_DRM_I915_GVT),y)
i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 225bee890822..db0378b71941 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2396,12 +2396,14 @@ struct drm_i915_private {
int metrics_set;
- const struct i915_oa_reg *mux_regs[1];
- int mux_regs_lens[1];
+ const struct i915_oa_reg *mux_regs[2];
+ int mux_regs_lens[2];
int n_mux_configs;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+ const struct i915_oa_reg *flex_regs;
+ int flex_regs_len;
struct {
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_oa_bdw.c
b/drivers/gpu/drm/i915/i915_oa_bdw.c
new file mode 100644
index ..9a11c03b4ecb
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_bdw.c
@@ -0,0 +1,392 @@
+/*
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
+ *
+ * Copyright (c) 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 SOFTWA
[Intel-gfx] [PATCH v14 04/14] drm/i915/perf: rework mux configurations queries
Gen8+ might have mux configurations per slices/subslices. Depending on
whether slices/subslices have been fused off, only part of the
configuration needs to be applied. This change reworks the mux
configurations query mechanism to allow more than one set of registers
to be programmed.
v2: s/n_mux_regs/n_mux_configs/ (Matthew)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h| 6 +-
drivers/gpu/drm/i915/i915_oa_hsw.c | 215 -
drivers/gpu/drm/i915/i915_oa_hsw.h | 4 +-
drivers/gpu/drm/i915/i915_perf.c | 7 +-
4 files changed, 151 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d76e731e8156..225bee890822 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2396,8 +2396,10 @@ struct drm_i915_private {
int metrics_set;
- const struct i915_oa_reg *mux_regs;
- int mux_regs_len;
+ const struct i915_oa_reg *mux_regs[1];
+ int mux_regs_lens[1];
+ int n_mux_configs;
+
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 4ddf756add31..8c13e0880e53 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -1,5 +1,7 @@
/*
- * Autogenerated file, DO NOT EDIT manually!
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
*
* Copyright (c) 2015 Intel Corporation
*
@@ -109,12 +111,21 @@ static const struct i915_oa_reg mux_config_render_basic[]
= {
{ _MMIO(0x25428), 0x00042049 },
};
-static const struct i915_oa_reg *
+static int
get_render_basic_mux_config(struct drm_i915_private *dev_priv,
- int *len)
+ const struct i915_oa_reg **regs,
+ int *lens)
{
- *len = ARRAY_SIZE(mux_config_render_basic);
- return mux_config_render_basic;
+ int n = 0;
+
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+ regs[n] = mux_config_render_basic;
+ lens[n] = ARRAY_SIZE(mux_config_render_basic);
+ n++;
+
+ return n;
}
static const struct i915_oa_reg b_counter_config_compute_basic[] = {
@@ -172,12 +183,21 @@ static const struct i915_oa_reg
mux_config_compute_basic[] = {
{ _MMIO(0x25428), 0x0c03 },
};
-static const struct i915_oa_reg *
+static int
get_compute_basic_mux_config(struct drm_i915_private *dev_priv,
-int *len)
+const struct i915_oa_reg **regs,
+int *lens)
{
- *len = ARRAY_SIZE(mux_config_compute_basic);
- return mux_config_compute_basic;
+ int n = 0;
+
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+ regs[n] = mux_config_compute_basic;
+ lens[n] = ARRAY_SIZE(mux_config_compute_basic);
+ n++;
+
+ return n;
}
static const struct i915_oa_reg b_counter_config_compute_extended[] = {
@@ -221,12 +241,21 @@ static const struct i915_oa_reg
mux_config_compute_extended[] = {
{ _MMIO(0x25428), 0x },
};
-static const struct i915_oa_reg *
+static int
get_compute_extended_mux_config(struct drm_i915_private *dev_priv,
- int *len)
+ const struct i915_oa_reg **regs,
+ int *lens)
{
- *len = ARRAY_SIZE(mux_config_compute_extended);
- return mux_config_compute_extended;
+ int n = 0;
+
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+ regs[n] = mux_config_compute_extended;
+ lens[n] = ARRAY_SIZE(mux_config_compute_extended);
+ n++;
+
+ return n;
}
static const struct i915_oa_reg b_counter_config_memory_reads[] = {
@@ -281,12 +310,21 @@ static const struct i915_oa_reg mux_config_memory_reads[]
= {
{ _MMIO(0x25428), 0x },
};
-static const struct i915_oa_reg *
+static int
get_memory_reads_mux_config(struct drm_i915_private *dev_priv,
- int *len)
+ const struct i915_oa_reg **regs,
+ int *lens)
{
- *len = ARRAY_SIZE(mux_config_memory_reads);
- return mux_config_memory_reads;
+ int n = 0;
+
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+ BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+ regs[n] = mux_config_memory_reads;
+
[Intel-gfx] [PATCH v14 02/14] drm/i915: Program RPCS for Broadwell
From: Chris Wilson Currently we only configure the power gating for Skylake and above, but the configuration should equally apply to Broadwell and Braswell. Even though, there is not as much variation as for later generations, we want to expose control over the configuration to userspace and may want to opt out of the "always-enabled" setting. Signed-off-by: Chris Wilson Signed-off-by: Lionel Landwerlin Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_lrc.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 9a279a559a0f..fec66204fe88 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1816,13 +1816,6 @@ make_rpcs(struct drm_i915_private *dev_priv) u32 rpcs = 0; /* -* No explicit RPCS request is needed to ensure full -* slice/subslice/EU enablement prior to Gen9. - */ - if (INTEL_GEN(dev_priv) < 9) - return 0; - - /* * Starting in Gen9, render power gating can leave * slice/subslice/EU in a partially enabled state. We * must make an explicit request through RPCS for full -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v14 10/14] drm/i915: add KBL GT2/GT3 check macros
Add macros to detect GT2/GT3 skus so we can apply the proper OA configuration later. Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.h | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index cdd6f8fa105a..cd1dc9ee05cb 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2802,6 +2802,10 @@ intel_info(const struct drm_i915_private *dev_priv) (INTEL_DEVID(dev_priv) & 0x00F0) == 0x0020) #define IS_SKL_GT4(dev_priv) (IS_SKYLAKE(dev_priv) && \ (INTEL_DEVID(dev_priv) & 0x00F0) == 0x0030) +#define IS_KBL_GT2(dev_priv) (IS_KABYLAKE(dev_priv) && \ +(INTEL_DEVID(dev_priv) & 0x00F0) == 0x0010) +#define IS_KBL_GT3(dev_priv) (IS_KABYLAKE(dev_priv) && \ +(INTEL_DEVID(dev_priv) & 0x00F0) == 0x0020) #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v14 03/14] drm/i915: Record the sseu configuration per-context & engine
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 19 ---
drivers/gpu/drm/i915/i915_gem_context.c | 6 ++
drivers/gpu/drm/i915/i915_gem_context.h | 21 +
drivers/gpu/drm/i915/intel_lrc.c| 23 +--
4 files changed, 36 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7faad0ea18a8..d76e731e8156 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -779,25 +779,6 @@ struct intel_csr {
func(overlay_needs_physical); \
func(supports_tv);
-struct sseu_dev_info {
- u8 slice_mask;
- u8 subslice_mask;
- u8 eu_total;
- u8 min_eu_per_subslice;
- u8 max_eu_per_subslice;
- u8 min_eu_in_pool;
- /* For each slice, which subslice(s) has(have) 7 EUs (bitfield)? */
- u8 subslice_7eu[3];
- u8 has_slice_pg:1;
- u8 has_subslice_pg:1;
- u8 has_eu_pg:1;
-};
-
-static inline unsigned int sseu_subslice_total(const struct sseu_dev_info
*sseu)
-{
- return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
-}
-
/* Keep in gen based order, and chronological order within a gen */
enum intel_platform {
INTEL_PLATFORM_UNINITIALIZED = 0,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index c5d1666d7071..60d0bbf0ae2b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -184,6 +184,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct drm_i915_file_private *file_priv)
{
struct i915_gem_context *ctx;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
int ret;
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -229,6 +231,10 @@ __create_hw_context(struct drm_i915_private *dev_priv,
* is no remap info, it will be a NOP. */
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
+ /* On all engines, use the whole device by default */
+ for_each_engine(engine, dev_priv, id)
+ ctx->engine[id].sseu = INTEL_INFO(dev_priv)->sseu;
+
i915_gem_context_set_bannable(ctx);
ctx->ring_size = 4 * PAGE_SIZE;
ctx->desc_template =
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 4af2ab94558b..e8247e2f6011 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -39,6 +39,25 @@ struct i915_hw_ppgtt;
struct i915_vma;
struct intel_ring;
+struct sseu_dev_info {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 eu_total;
+ u8 min_eu_per_subslice;
+ u8 max_eu_per_subslice;
+ u8 min_eu_in_pool;
+ /* For each slice, which subslice(s) has(have) 7 EUs (bitfield)? */
+ u8 subslice_7eu[3];
+ u8 has_slice_pg:1;
+ u8 has_subslice_pg:1;
+ u8 has_eu_pg:1;
+};
+
+static inline unsigned int sseu_subslice_total(const struct sseu_dev_info
*sseu)
+{
+ return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
+}
+
#define DEFAULT_CONTEXT_HANDLE 0
/**
@@ -151,6 +170,8 @@ struct i915_gem_context {
u64 lrc_desc;
int pin_count;
bool initialised;
+ /** sseu: Control eu/slice partitioning */
+ struct sseu_dev_info sseu;
} engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fec66204fe88..78fb1f452891 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1810,8 +1810,7 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
return logical_ring_init(engine);
}
-static u32
-make_rpcs(struct drm_i915_private *dev_priv)
+static u32 make_rpcs(const struct sseu_dev_info *sseu)
{
u32 rpcs = 0;
@@ -1821,25 +1820,21 @@ make_rpcs(struct drm_i915_private *dev_priv)
* must make an explicit request through RPCS for full
* enablement.
*/
- if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
+ if (sseu->has_slice_pg) {
rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
+ rpcs |= hweight8(sseu->slice_mask) << GEN8_RPCS_S_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
- if (INTEL_INFO(dev_pri
[Intel-gfx] [PATCH v14 09/14] drm/i915/perf: remove perf.hook_lock
From: Robert Bragg
In earlier iterations of the i915-perf driver we had a number of
callbacks/hooks from other parts of the i915 driver to e.g. notify us
when a legacy context was pinned and these could run asynchronously with
respect to the stream file operations and might also run in atomic
context.
dev_priv->perf.hook_lock had been for serialising access to state needed
within these callbacks, but as the code has evolved some of the hooks
have gone away or are implemented to avoid needing to lock any state.
The remaining use of this lock was actually redundant considering how
the gen7 oacontrol state used to be updated as part of a context pin
hook.
Signed-off-by: Robert Bragg
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/i915_perf.c | 32 ++--
2 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b0f5d6fae6b0..cdd6f8fa105a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2375,8 +2375,6 @@ struct drm_i915_private {
struct mutex lock;
struct list_head streams;
- spinlock_t hook_lock;
-
struct {
struct i915_perf_stream *exclusive_stream;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4fab9974b1b8..9e5307bbaab1 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1810,9 +1810,17 @@ static void gen8_disable_metric_set(struct
drm_i915_private *dev_priv)
gen8_configure_all_contexts(dev_priv, false);
}
-static void gen7_update_oacontrol_locked(struct drm_i915_private *dev_priv)
+static void gen7_oa_enable(struct drm_i915_private *dev_priv)
{
- lockdep_assert_held(&dev_priv->perf.hook_lock);
+ /* Reset buf pointers so we don't forward reports from before now.
+*
+* Think carefully if considering trying to avoid this, since it
+* also ensures status flags and the buffer itself are cleared
+* in error paths, and we have checks for invalid reports based
+* on the assumption that certain fields are written to zeroed
+* memory which this helps maintains.
+*/
+ gen7_init_oa_buffer(dev_priv);
if (dev_priv->perf.oa.exclusive_stream->enabled) {
struct i915_gem_context *ctx =
@@ -1835,25 +1843,6 @@ static void gen7_update_oacontrol_locked(struct
drm_i915_private *dev_priv)
I915_WRITE(GEN7_OACONTROL, 0);
}
-static void gen7_oa_enable(struct drm_i915_private *dev_priv)
-{
- unsigned long flags;
-
- /* Reset buf pointers so we don't forward reports from before now.
-*
-* Think carefully if considering trying to avoid this, since it
-* also ensures status flags and the buffer itself are cleared
-* in error paths, and we have checks for invalid reports based
-* on the assumption that certain fields are written to zeroed
-* memory which this helps maintains.
-*/
- gen7_init_oa_buffer(dev_priv);
-
- spin_lock_irqsave(&dev_priv->perf.hook_lock, flags);
- gen7_update_oacontrol_locked(dev_priv);
- spin_unlock_irqrestore(&dev_priv->perf.hook_lock, flags);
-}
-
static void gen8_oa_enable(struct drm_i915_private *dev_priv)
{
u32 report_format = dev_priv->perf.oa.oa_buffer.format;
@@ -3069,7 +3058,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
INIT_LIST_HEAD(&dev_priv->perf.streams);
mutex_init(&dev_priv->perf.lock);
- spin_lock_init(&dev_priv->perf.hook_lock);
spin_lock_init(&dev_priv->perf.oa.oa_buffer.ptr_lock);
oa_sample_rate_hard_limit =
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v14 08/14] drm/i915/perf: per-gen timebase for checking sample freq
From: Robert Bragg
An oa_exponent_to_ns() utility and per-gen timebase constants where
recently removed when updating the tail pointer race condition WA, and
this restores those so we can update the _PROP_OA_EXPONENT validation
done in read_properties_unlocked() to not assume we have a 12.5MHz
timebase as we did for Haswell.
Accordingly the oa_sample_rate_hard_limit value that's referenced by
proc_dointvec_minmax defining the absolute limit for the OA sampling
frequency is now initialized to (timestamp_frequency / 2) instead of the
6.25MHz constant for Haswell.
v2:
Specify frequency of 19.2MHz for BXT (Ville)
Initialize oa_sample_rate_hard_limit per-gen too (Lionel)
Signed-off-by: Robert Bragg
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_perf.c | 39 ---
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7741881e9605..b0f5d6fae6b0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2394,6 +2394,7 @@ struct drm_i915_private {
bool periodic;
int period_exponent;
+ int timestamp_frequency;
int metrics_set;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 9f524a0ec727..4fab9974b1b8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -288,10 +288,12 @@ static u32 i915_perf_stream_paranoid = true;
/* For sysctl proc_dointvec_minmax of i915_oa_max_sample_rate
*
- * 160ns is the smallest sampling period we can theoretically program the OA
- * unit with on Haswell, corresponding to 6.25MHz.
+ * The highest sampling frequency we can theoretically program the OA unit
+ * with is always half the timestamp frequency: E.g. 6.25Mhz for Haswell.
+ *
+ * Initialized just before we register the sysctl parameter.
*/
-static int oa_sample_rate_hard_limit = 625;
+static int oa_sample_rate_hard_limit;
/* Theoretically we can program the OA unit to sample every 160ns but don't
* allow that by default unless root...
@@ -2613,6 +2615,12 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
*dev_priv,
return ret;
}
+static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)
+{
+ return div_u64(10ULL * (2ULL << exponent),
+ dev_priv->perf.oa.timestamp_frequency);
+}
+
/**
* read_properties_unlocked - validate + copy userspace stream open properties
* @dev_priv: i915 device instance
@@ -2709,16 +2717,13 @@ static int read_properties_unlocked(struct
drm_i915_private *dev_priv,
}
/* Theoretically we can program the OA unit to sample
-* every 160ns but don't allow that by default unless
-* root.
-*
-* On Haswell the period is derived from the exponent
-* as:
-*
-* period = 80ns * 2^(exponent + 1)
+* e.g. every 160ns for HSW, 167ns for BDW/SKL or 104ns
+* for BXT. We don't allow such high sampling
+* frequencies by default unless root.
*/
+
BUILD_BUG_ON(sizeof(oa_period) != 8);
- oa_period = 80ull * (2ull << value);
+ oa_period = oa_exponent_to_ns(dev_priv, value);
/* This check is primarily to ensure that oa_period <=
* UINT32_MAX (before passing to do_div which only
@@ -2974,6 +2979,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.oa_hw_tail_read =
gen7_oa_hw_tail_read;
+ dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.oa_formats = hsw_oa_formats;
dev_priv->perf.oa.n_builtin_sets =
@@ -2989,6 +2996,9 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
if (IS_GEN8(dev_priv)) {
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
+
+ dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
if (IS_BROADWELL(dev_priv)) {
@@ -3005,6 +3015,9 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
} else if (IS_GEN9(dev_priv)) {
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
+
+ dev_priv->perf.oa.timestamp_
[Intel-gfx] [PATCH v14 14/14] drm/i915/perf: notify sseu configuration changes
This adds the ability for userspace to request that the kernel track &
record sseu configuration changes. These changes are inserted into the
perf stream so that userspace can interpret the OA reports using the
configuration applied at the time the OA reports where generated.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 45
drivers/gpu/drm/i915/i915_gem_context.c | 3 +
drivers/gpu/drm/i915/i915_gem_context.h | 21 ++
drivers/gpu/drm/i915/i915_perf.c| 452 ++--
drivers/gpu/drm/i915/intel_lrc.c| 7 +-
include/uapi/drm/i915_drm.h | 30 +++
6 files changed, 531 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index efa8a0b302ca..02daea8d49fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1962,6 +1962,12 @@ struct i915_perf_stream {
struct i915_gem_context *ctx;
/**
+* @has_sseu: Whether the stream emits SSEU configuration changes
+* reports.
+*/
+ bool has_sseu;
+
+ /**
* @enabled: Whether the stream is currently enabled, considering
* whether the stream was opened in a disabled state and based
* on `I915_PERF_IOCTL_ENABLE` and `I915_PERF_IOCTL_DISABLE` calls.
@@ -2492,6 +2498,44 @@ struct drm_i915_private {
const struct i915_oa_format *oa_formats;
int n_builtin_sets;
} oa;
+
+ struct {
+ /**
+* Buffer containing change reports of the SSEU
+* configuration.
+*/
+ struct i915_vma *vma;
+ u8 *vaddr;
+
+ /**
+* Scheduler write to the head, and the perf driver
+* reads from tail.
+*/
+ u32 head;
+ u32 tail;
+
+ /**
+* Is the sseu buffer enabled.
+*/
+ bool enabled;
+
+ /**
+* Whether the buffer overflown.
+*/
+ bool overflow;
+
+ /**
+* Keeps track of how many times the OA unit has been
+* enabled. This number is used to discard stale
+* @perf_sseu in @i915_gem_context.
+*/
+ atomic64_t enable_no;
+
+ /**
+* Lock writes & tail pointer updates on this buffer.
+*/
+ spinlock_t ptr_lock;
+ } sseu_buffer;
} perf;
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
@@ -3537,6 +3581,7 @@ void i915_oa_init_reg_state(struct intel_engine_cs
*engine,
struct i915_gem_context *ctx,
uint32_t *reg_state);
int i915_oa_emit_noa_config_locked(struct drm_i915_gem_request *req);
+void i915_perf_emit_sseu_config(struct drm_i915_gem_request *req);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 60d0bbf0ae2b..368bb527a75a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -510,6 +510,9 @@ mi_set_context(struct drm_i915_gem_request *req, u32 flags)
if (IS_ERR(cs))
return PTR_ERR(cs);
+ /* Notify perf of possible change in SSEU configuration. */
+ i915_perf_emit_sseu_config(req);
+
/* WaProgramMiArbOnOffAroundMiSetContext:ivb,vlv,hsw,bdw,chv */
if (INTEL_GEN(dev_priv) >= 7) {
*cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index e8247e2f6011..9c005be4933a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -194,6 +194,27 @@ struct i915_gem_context {
/** remap_slice: Bitmask of cache lines that need remapping */
u8 remap_slice;
+
+ /**
+* @oa_sseu: last SSEU configuration notified to userspace
+*
+* SSEU configuration changes are notified to userspace through the
+* perf infrastructure. We keep track here of the last notified
+* configuration for a given context since configuration can change
+* per engine.
+*/
+ struct sseu_dev_info perf_sseu;
+
+ /**
+* @perf_enable_no: last perf enable identifier
+*
+* Userspace can enable/disable the perf infrastructure whenever
[Intel-gfx] [PATCH v14 12/14] drm/i915/perf: add GLK support
Add OA support for Geminilake (pretty much identical to Broxton), and
also add the associated OA configurations.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile |3 +-
drivers/gpu/drm/i915/i915_oa_glk.c | 2602
drivers/gpu/drm/i915/i915_oa_glk.h | 40 +
drivers/gpu/drm/i915/i915_perf.c | 17 +-
4 files changed, 2659 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.c
create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 859e1751d7ab..bb781bc628df 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -136,7 +136,8 @@ i915-y += i915_perf.o \
i915_oa_sklgt4.o \
i915_oa_bxt.o \
i915_oa_kblgt2.o \
- i915_oa_kblgt3.o
+ i915_oa_kblgt3.o \
+ i915_oa_glk.o
ifeq ($(CONFIG_DRM_I915_GVT),y)
i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_oa_glk.c
b/drivers/gpu/drm/i915/i915_oa_glk.c
new file mode 100644
index ..2f356d51bff8
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_glk.c
@@ -0,0 +1,2602 @@
+/*
+ * Autogenerated file by GPU Top : https://github.com/rib/gputop
+ * DO NOT EDIT manually!
+ *
+ *
+ * Copyright (c) 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.
+ *
+ */
+
+#include
+
+#include "i915_drv.h"
+#include "i915_oa_glk.h"
+
+enum metric_set_id {
+ METRIC_SET_ID_RENDER_BASIC = 1,
+ METRIC_SET_ID_COMPUTE_BASIC,
+ METRIC_SET_ID_RENDER_PIPE_PROFILE,
+ METRIC_SET_ID_MEMORY_READS,
+ METRIC_SET_ID_MEMORY_WRITES,
+ METRIC_SET_ID_COMPUTE_EXTENDED,
+ METRIC_SET_ID_COMPUTE_L3_CACHE,
+ METRIC_SET_ID_HDC_AND_SF,
+ METRIC_SET_ID_L3_1,
+ METRIC_SET_ID_RASTERIZER_AND_PIXEL_BACKEND,
+ METRIC_SET_ID_SAMPLER,
+ METRIC_SET_ID_TDL_1,
+ METRIC_SET_ID_TDL_2,
+ METRIC_SET_ID_COMPUTE_EXTRA,
+ METRIC_SET_ID_TEST_OA,
+};
+
+int i915_oa_n_builtin_metric_sets_glk = 15;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+ { _MMIO(0x2710), 0x },
+ { _MMIO(0x2714), 0x0080 },
+ { _MMIO(0x2720), 0x },
+ { _MMIO(0x2724), 0x0080 },
+ { _MMIO(0x2740), 0x },
+};
+
+static const struct i915_oa_reg flex_eu_config_render_basic[] = {
+ { _MMIO(0xe458), 0x5004 },
+ { _MMIO(0xe558), 0x00010003 },
+ { _MMIO(0xe658), 0x00012011 },
+ { _MMIO(0xe758), 0x00015014 },
+ { _MMIO(0xe45c), 0x00051050 },
+ { _MMIO(0xe55c), 0x00053052 },
+ { _MMIO(0xe65c), 0x00055054 },
+};
+
+static const struct i915_oa_reg mux_config_render_basic[] = {
+ { _MMIO(0x9888), 0x166c00f0 },
+ { _MMIO(0x9888), 0x12120280 },
+ { _MMIO(0x9888), 0x12320280 },
+ { _MMIO(0x9888), 0x11930317 },
+ { _MMIO(0x9888), 0x159303df },
+ { _MMIO(0x9888), 0x3f900c00 },
+ { _MMIO(0x9888), 0x419000a0 },
+ { _MMIO(0x9888), 0x002d1000 },
+ { _MMIO(0x9888), 0x062d4000 },
+ { _MMIO(0x9888), 0x082d5000 },
+ { _MMIO(0x9888), 0x0a2d1000 },
+ { _MMIO(0x9888), 0x0c2e0800 },
+ { _MMIO(0x9888), 0x0e2e5900 },
+ { _MMIO(0x9888), 0x0a4c8000 },
+ { _MMIO(0x9888), 0x0c4c8000 },
+ { _MMIO(0x9888), 0x0e4c4000 },
+ { _MMIO(0x9888), 0x064e8000 },
+ { _MMIO(0x9888), 0x084e8000 },
+ { _MMIO(0x9888), 0x0a4e2000 },
+ { _MMIO(0x9888), 0x1c4f0010 },
+ { _MMIO(0x9888), 0x0a6c0053 },
+ { _MMIO(0x9888), 0x106c },
+ { _MMIO(0x9888), 0x1c6c },
+ { _MMIO(0x9888), 0x1a0fcc00 },
+ { _MMIO(0x9888), 0x1c0f0002 },
+ { _MMIO(0x9888), 0x1c2c0040 },
+ { _MMIO(0x9888), 0x00101000 },
+ { _MMIO(0x9888), 0x04101000 },
+ { _MMIO(0x9888), 0x001140
[Intel-gfx] [PATCH v14 13/14] drm/i915/perf: reprogram NOA muxes at the beginning of each workload
Dynamic slices/subslices shutdown will effectivelly loose the NOA
configuration uploaded in the slices/subslices. When i915 perf is in
use, we therefore need to reprogram it.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_perf.c| 64 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 ++
3 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cd1dc9ee05cb..efa8a0b302ca 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2399,6 +2399,7 @@ struct drm_i915_private {
const struct i915_oa_reg *mux_regs[6];
int mux_regs_lens[6];
int n_mux_configs;
+ int total_n_mux_regs;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
@@ -3535,6 +3536,7 @@ int i915_perf_open_ioctl(struct drm_device *dev, void
*data,
void i915_oa_init_reg_state(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
uint32_t *reg_state);
+int i915_oa_emit_noa_config_locked(struct drm_i915_gem_request *req);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c281847eb56b..15b1f92fe5b5 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1438,11 +1438,24 @@ static void config_oa_regs(struct drm_i915_private
*dev_priv,
}
}
+static void count_total_mux_regs(struct drm_i915_private *dev_priv)
+{
+ int i;
+
+ dev_priv->perf.oa.total_n_mux_regs = 0;
+ for (i = 0; i < dev_priv->perf.oa.n_mux_configs; i++) {
+ dev_priv->perf.oa.total_n_mux_regs +=
+ dev_priv->perf.oa.mux_regs_lens[i];
+ }
+}
+
static int hsw_enable_metric_set(struct drm_i915_private *dev_priv)
{
int ret = i915_oa_select_metric_set_hsw(dev_priv);
int i;
+ count_total_mux_regs(dev_priv);
+
if (ret)
return ret;
@@ -1756,6 +1769,8 @@ static int gen8_enable_metric_set(struct drm_i915_private
*dev_priv)
int ret = dev_priv->perf.oa.ops.select_metric_set(dev_priv);
int i;
+ count_total_mux_regs(dev_priv);
+
if (ret)
return ret;
@@ -2094,6 +2109,55 @@ void i915_oa_init_reg_state(struct intel_engine_cs
*engine,
gen8_update_reg_state_unlocked(ctx, reg_state);
}
+int i915_oa_emit_noa_config_locked(struct drm_i915_gem_request *req)
+{
+ struct drm_i915_private *dev_priv = req->i915;
+ u32 *cs;
+ int i, j;
+
+ lockdep_assert_held(&dev_priv->drm.struct_mutex);
+
+ if (!IS_GEN(dev_priv, 8, 9))
+ return 0;
+
+ /* Perf not supported or not enabled. */
+ if (!dev_priv->perf.initialized ||
+ !dev_priv->perf.oa.exclusive_stream)
+ return 0;
+
+ cs = intel_ring_begin(req,
+ 1 /* MI_LOAD_REGISTER_IMM */ +
+ dev_priv->perf.oa.total_n_mux_regs * 2 +
+ 4 /* GDT_CHICKEN_BITS */ +
+ 1 /* NOOP */);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ *cs++ = MI_LOAD_REGISTER_IMM(dev_priv->perf.oa.total_n_mux_regs);
+
+ *cs++ = i915_mmio_reg_offset(GDT_CHICKEN_BITS);
+ *cs++ = 0xA0;
+
+ for (i = 0; i < dev_priv->perf.oa.n_mux_configs; i++) {
+ const struct i915_oa_reg *mux_regs =
+ dev_priv->perf.oa.mux_regs[i];
+ const int mux_regs_len = dev_priv->perf.oa.mux_regs_lens[i];
+
+ for (j = 0; j < mux_regs_len; j++) {
+ *cs++ = i915_mmio_reg_offset(mux_regs[j].addr);
+ *cs++ = mux_regs[j].value;
+ }
+ }
+
+ *cs++ = i915_mmio_reg_offset(GDT_CHICKEN_BITS);
+ *cs++ = 0x80;
+
+ *cs++ = MI_NOOP;
+ intel_ring_advance(req, cs);
+
+ return 0;
+}
+
/**
* i915_perf_read_locked - &i915_perf_stream_ops->read with error normalisation
* @stream: An i915 perf stream
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index acd1da9b62a3..67aaaebb194b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1874,6 +1874,9 @@ gen8_emit_bb_start(struct drm_i915_gem_request *req,
!(dispatch_flags & I915_DISPATCH_SECURE);
u32 *cs;
+ /* Emit NOA config */
+ i915_oa_emit_noa_config_locked(req);
+
cs = intel_ring_begin(req, 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
--
2.11.0
_
Re: [Intel-gfx] [PATCH v9 1/5] drm/i915: Drop AUX backlight enable check for backlight control
On Wed, 24 May 2017, Jani Nikula wrote:
> On Tue, 23 May 2017, Puthikorn Voravootivat wrote:
>> There are some panel that
>> (1) does not support display backlight enable via AUX
>> (2) support display backlight adjustment via AUX
>> (3) support display backlight enable via eDP BL_ENABLE pin
>>
>> The current driver required that (1) must be support to enable (2).
>> This patch drops that requirement.
>>
>> Signed-off-by: Puthikorn Voravootivat
>
> Reviewed-by: Jani Nikula
And pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> index b87c5a381d6a..a0995c00fc84 100644
>> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> @@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp
>> *intel_dp, bool enable)
>> {
>> uint8_t reg_val = 0;
>>
>> +/* Early return when display use other mechanism to enable backlight. */
>> +if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
>> +return;
>> +
>> if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
>>®_val) < 0) {
>> DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
>> @@ -165,10 +169,8 @@ intel_dp_aux_display_control_capable(struct
>> intel_connector *connector)
>> * the panel can support backlight control over the aux channel
>> */
>> if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
>> -(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
>> (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
>> -!((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
>> - (intel_dp->edp_dpcd[2] &
>> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
>> +!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
>> {
>> DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
>> return true;
>> }
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI v4 2/3] drm/i915/guc: Introduce buffer based cmd transport
On Fri, May 26, 2017 at 11:13:25AM +, Michal Wajdeczko wrote:
> Buffer based command transport can replace MMIO based mechanism.
> It may be used to perform host-2-guc and guc-to-host communication.
>
> Portions of this patch are based on work by:
> Michel Thierry
> Robert Beckett
> Daniele Ceraolo Spurio
>
> v2: use gem_object_pin_map (Chris)
> don't use DEBUG_RATELIMITED (Chris)
> don't track action stats (Chris)
> simplify next fence (Chris)
> use READ_ONCE (Chris)
> move blob allocation to new function (Chris)
>
> v3: use static owner id (Daniele)
> v4: but keep channel initialization generic (Daniele)
> and introduce owner_sub_id (Daniele)
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> Cc: Oscar Mateo
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Reviewed-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_guc_ct.c | 461
> ++
> drivers/gpu/drm/i915/intel_guc_ct.h | 86 +++
> drivers/gpu/drm/i915/intel_guc_fwif.h | 43
> drivers/gpu/drm/i915/intel_uc.c | 19 +-
> drivers/gpu/drm/i915/intel_uc.h | 3 +-
> 7 files changed, 613 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_guc_ct.c
> create mode 100644 drivers/gpu/drm/i915/intel_guc_ct.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 7b05fb8..16dccf5 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -58,6 +58,7 @@ i915-y += i915_cmd_parser.o \
>
> # general-purpose microcontroller (GuC) support
> i915-y += intel_uc.o \
> + intel_guc_ct.o \
> intel_guc_log.o \
> intel_guc_loader.o \
> intel_huc.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9ba2242..d2a5749 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -760,6 +760,7 @@ struct intel_csr {
> func(has_gmbus_irq); \
> func(has_gmch_display); \
> func(has_guc); \
> + func(has_guc_ct); \
> func(has_hotplug); \
> func(has_l3_dpf); \
> func(has_llc); \
> @@ -2947,6 +2948,7 @@ intel_info(const struct drm_i915_private *dev_priv)
> * properties, so we have separate macros to test them.
> */
> #define HAS_GUC(dev_priv)((dev_priv)->info.has_guc)
> +#define HAS_GUC_CT(dev_priv) ((dev_priv)->info.has_guc_ct)
> #define HAS_GUC_UCODE(dev_priv) (HAS_GUC(dev_priv))
> #define HAS_GUC_SCHED(dev_priv) (HAS_GUC(dev_priv))
> #define HAS_HUC_UCODE(dev_priv) (HAS_GUC(dev_priv))
> diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
> b/drivers/gpu/drm/i915/intel_guc_ct.c
> new file mode 100644
> index 000..c4cbec1
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_guc_ct.c
> @@ -0,0 +1,461 @@
> +/*
> + * Copyright © 2016-2017 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 "i915_drv.h"
> +#include "intel_guc_ct.h"
> +
> +enum { CTB_SEND = 0, CTB_RECV = 1 };
> +
> +enum { CTB_OWNER_HOST = 0 };
> +
> +void intel_guc_ct_init_early(struct intel_guc_ct *ct)
> +{
> + /* we're using static channel owners */
> + ct->host_channel.owner = CTB_OWNER_HOST;
> +}
> +
> +static inline const char *guc_ct_buffer_type_to_str(u32 type)
> +{
> + switch (type) {
> + case INTEL_GUC_CT_BUFFER_TYPE_SEND:
> + return "SEND";
> + case INTEL_GUC_CT_BUFFER_TYPE_RECV:
> + return "RECV";
> + default:
> + return "";
> + }
> +}
> +
> +static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
> + u32 cmds_addr, u32 size, u32 owner)
> +{
> + DRM_DEBUG_DRIVER("CT: desc %p init addr=%#x s
Re: [Intel-gfx] [PATCH v9 4/5] drm: Add definition for eDP backlight frequency
On Wed, 24 May 2017, Jani Nikula wrote: > On Tue, 23 May 2017, Puthikorn Voravootivat wrote: >> This patch adds the following definition >> - Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap >> register which only use bit 0:4 >> - Base frequency (27 MHz) for backlight PWM frequency >> generator. >> >> Signed-off-by: Puthikorn Voravootivat >> Reviewed-by: Dhinakaran Pandiyan >> --- >> include/drm/drm_dp_helper.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h >> index c0bd0d7651a9..eaa307f6ae8c 100644 >> --- a/include/drm/drm_dp_helper.h >> +++ b/include/drm/drm_dp_helper.h >> @@ -572,10 +572,12 @@ >> #define DP_EDP_PWMGEN_BIT_COUNT 0x724 >> #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725 >> #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726 >> +# define DP_EDP_PWMGEN_BIT_COUNT_MASK (0x1f << 0) >^^ > > Extra space crept in. Fixed that while applying to drm-intel-next-queued, thanks for the patch. Pushed via drm-intel with Dave's IRC ack to not require a backmerge for the subsequent patches. BR, Jani. > > BR, > Jani. > >> >> #define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727 >> >> #define DP_EDP_BACKLIGHT_FREQ_SET 0x728 >> +# define DP_EDP_BACKLIGHT_FREQ_BASE_KHZ 27000 >> >> #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB 0x72a >> #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID 0x72b -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Introduce buffer based cmd transport (rev3)
On Fri, May 26, 2017 at 11:32:59AM -, Patchwork wrote: > == Series Details == > > Series: Introduce buffer based cmd transport (rev3) > URL : https://patchwork.freedesktop.org/series/24786/ > State : warning > > == Summary == > > Series 24786v3 Introduce buffer based cmd transport > https://patchwork.freedesktop.org/api/1.0/series/24786/revisions/3/mbox/ > > Test kms_busy: > Subgroup basic-flip-default-a: > dmesg-warn -> PASS (fi-skl-6700hq) fdo#101144 +1 > Test kms_flip: > Subgroup basic-flip-vs-modeset: > pass -> SKIP (fi-skl-6700hq) fdo#100867 > Subgroup basic-flip-vs-wf_vblank: > pass -> SKIP (fi-skl-6700hq) fdo#99739 > Subgroup basic-plain-flip: > pass -> SKIP (fi-skl-6700hq) > Test kms_frontbuffer_tracking: > Subgroup basic: > pass -> SKIP (fi-skl-6700hq) > Test kms_pipe_crc_basic: > Subgroup hang-read-crc-pipe-a: > pass -> FAIL (fi-skl-6700hq) fdo#101154 +16 Just the link-status snafu. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,9/15] drm/i915: expose _SLICE_MASK GETPARM (rev2)
== Series Details == Series: series starting with [v2,9/15] drm/i915: expose _SLICE_MASK GETPARM (rev2) URL : https://patchwork.freedesktop.org/series/23896/ State : success == Summary == Series 23896v2 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/23896/revisions/2/mbox/ Test kms_busy: Subgroup basic-flip-default-a: pass -> DMESG-WARN (fi-skl-6700hq) fdo#101144 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:430s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:574s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:509s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:489s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:481s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:413s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:412s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:421s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:495s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:464s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:469s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:565s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:278 pass:260 dwarn:1 dfail:0 fail:0 skip:17 time:568s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:465s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:503s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:532s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:404s 736e09119776656409971acbf0da829de9eb07e6 drm-tip: 2017y-05m-26d-11h-44m-35s UTC integration manifest 3a5bb9b drm/i915: Program RPCS for Broadwell 268c663 drm/i915: expose _SLICE_MASK GETPARM == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4819/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 5/5] drm/i915: Set PWM divider to match desired frequency in vbt
On Tue, 23 May 2017, Puthikorn Voravootivat wrote:
> Read desired PWM frequency from panel vbt and calculate the
> value for divider in DPCD address 0x724 and 0x728 to have
> as many bits as possible for PWM duty cyle for granularity of
> brightness adjustment while the frequency divisor is still
> within 25% of the desired value.
IIUC this patch doesn't have a dependency on the more contentious
patches 2/5 and 3/5. This should probably be merged before them.
I share DK's concern about doing a bunch of reads and writes and
calculations every time the backlight's enabled. But I guess that could
be optimized later.
I haven't had time to check the changed algorithm here, but in the mean
time one comment below.
BR,
Jani.
>
> Signed-off-by: Puthikorn Voravootivat
> ---
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 82
> +++
> 1 file changed, 82 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index f1b7855a2d2a..b7cd44550127 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -116,10 +116,85 @@ intel_dp_aux_set_dynamic_backlight_percent(struct
> intel_dp *intel_dp,
> }
> }
>
> +/*
> + * Set PWM Frequency divider to match desired frequency in vbt.
> + * The PWM Frequency is calculated as 27Mhz / (F x P).
> + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
> + * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
> + * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
> + * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> + */
> +static void intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
> + int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
> + u8 pn, pn_min, pn_max;
> +
> + /* Find desired value of (F x P)
> + * Note that, if F x P is out of supported range, the maximum value or
> + * minimum value will applied automatically. So no need to check that.
> + */
> + freq = dev_priv->vbt.backlight.pwm_freq_hz;
> + DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
> + if (!freq) {
> + DRM_DEBUG_KMS("Use panel default backlight frequency\n");
> + return;
> + }
> +
> + fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
> +
> + /* Use highest possible value of Pn for more granularity of brightness
> + * adjustment while satifying the conditions below.
> + * - Pn is in the range of Pn_min and Pn_max
> + * - F is in the range of 1 and 255
> + * - FxP is within 25% of desired value.
> + * Note: 25% is arbitrary value and may need some tweak.
> + */
> + if (drm_dp_dpcd_readb(&intel_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, &pn_min) != 1) {
> + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
> + return;
> + }
> + if (drm_dp_dpcd_readb(&intel_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, &pn_max) != 1) {
> + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
> + return;
> + }
> + pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> + pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> +
> + fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
> + fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
> + if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
> + DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
> + return;
> + }
> +
> + for (pn = pn_max; pn >= pn_min; pn--) {
> + f = clamp(DIV_ROUND_CLOSEST(fxp , 1 << pn), 1, 255);
> + fxp_actual = f << pn;
> + if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
> + break;
> + }
> +
> + if (drm_dp_dpcd_writeb(&intel_dp->aux,
> +DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
> + return;
> + }
> + if (drm_dp_dpcd_writeb(&intel_dp->aux,
> +DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
> + return;
> + }
> +}
> +
> static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
> {
> struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
> uint8_t dpcd_buf, new_dpcd_buf, edp_backlight_mode;
> + bool freq_cap;
>
> if (drm_dp_dpcd_readb(&intel_dp->aux,
> DP_EDP_BACKLIGHT_MODE_SET_REGISTER, &dpcd_buf) != 1) {
> @@ -152,6 +227,10 @@ static void intel_dp_aux_enable_backlight(struct
> i
Re: [Intel-gfx] [PATCH] drm/i915: Only GGTT vma may be pinned and prevent shrinking
On Thu, May 25, 2017 at 04:49:56PM +0300, Joonas Lahtinen wrote: > On to, 2017-05-25 at 08:25 +0100, Chris Wilson wrote: > > As only GGTT vma may be permanently pinned and are always at the head of > > the object's vma list, as soon as we seen a ppGTT vma we can stop > > searching for any_vma_pinned(). > > > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > Is this in the kerneldoc of the list? > > Reviewed-by: Joonas Lahtinen Pushed this last night and sent a patch for the kerneldoc, thanks for the review. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6] drm/i915/guc: capture GuC logs if FW fails to load
On Thu, May 25, 2017 at 11:58:25AM -0700, Michel Thierry wrote: > On 25/05/17 08:31, Daniele Ceraolo Spurio wrote: > > > > > >On 22/05/17 12:56, Michal Wajdeczko wrote: > >>On Mon, May 22, 2017 at 10:50:28AM -0700, Daniele Ceraolo Spurio wrote: > >>>We're currently deleting the GuC logs if the FW fails to load, but those > >>>are still useful to understand why the loading failed. Keeping the > >>>object around allows us to access them after driver load is completed. > >>> > >>>v2: keep the object around instead of using kernel memory (chris) > >>>don't store the logs in the gpu_error struct (Chris) > >>>add a check on guc_log_level to avoid snapshotting empty logs > >>> > >>>v3: use separate debugfs for error log (Chris) > >>> > >>>v4: rebased > >>> > >>>v5: clean up obj selection, move err_load inside guc_log, move err_load > >>>cleanup, rename functions (Michal) > >>> > >>>v6: move obj back to intel_guc, move functions to intel_uc.c, don't > >>>clear obj on new GuC load, free object only if enable_guc_loading > >>>is set (Michal) > >>> > >>>Cc: Chris Wilson > >>>Cc: Oscar Mateo > >>>Cc: Michal Wajdeczko > >>>Signed-off-by: Daniele Ceraolo Spurio > >>>--- > >> > >>Reviewed-by: Michal Wajdeczko > >> > >>Regards, > >>Michal > >> > > > >Does anyone else have any concern or can this patch be merged? > > > > +1 about being merged, and since I've been using this patch you could say, And done. Thanks for the patch, testing and review. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Keep the forcewake timer alive for 1ms past the most recent use
Currently the timer is armed for 1ms after the first use and is killed
immediately, dropping the forcewake as early as possible. However, for
very frequent operations the forcewake dance has a large impact on
latency and keeping the timer alive until we are idle is preferred. To
achieve this, if we call intel_uncore_forcewake_get whilst the timer is
alive (repeated use), then set a flag to restart the timer on expiry
rather than drop the forcewake usage count. The timer is racy, the
consequence of the race is to expire the timer earlier than is now
desired but does not impact on correct behaviour. The offset the race
slightly, we set the active flag again on intel_uncore_forcewake_put.
The effect should be to reduce the jitter of reacquiring the fw every
1ms on a busy system. However, the cost is to keep the timer alive for
an extra 1ms on a nearly idle system. We chose to incur the jitter
previously to keep the timer off for as much as possible.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 15 ---
drivers/gpu/drm/i915/intel_uncore.h | 1 +
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 9269cae5713a..47d7ee1b5d86 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -214,6 +214,9 @@ intel_uncore_fw_release_timer(struct hrtimer *timer)
assert_rpm_device_not_suspended(dev_priv);
+ if (xchg(&domain->active, false))
+ return HRTIMER_RESTART;
+
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
if (WARN_ON(domain->wake_count == 0))
domain->wake_count++;
@@ -244,6 +247,7 @@ static void intel_uncore_forcewake_reset(struct
drm_i915_private *dev_priv,
active_domains = 0;
for_each_fw_domain(domain, dev_priv, tmp) {
+ smp_store_mb(domain->active, false);
if (hrtimer_cancel(&domain->timer) == 0)
continue;
@@ -451,9 +455,12 @@ static void __intel_uncore_forcewake_get(struct
drm_i915_private *dev_priv,
fw_domains &= dev_priv->uncore.fw_domains;
- for_each_fw_domain_masked(domain, fw_domains, dev_priv, tmp)
- if (domain->wake_count++)
+ for_each_fw_domain_masked(domain, fw_domains, dev_priv, tmp) {
+ if (domain->wake_count++) {
fw_domains &= ~domain->mask;
+ domain->active = true;
+ }
+ }
if (fw_domains)
dev_priv->uncore.funcs.force_wake_get(dev_priv, fw_domains);
@@ -518,8 +525,10 @@ static void __intel_uncore_forcewake_put(struct
drm_i915_private *dev_priv,
if (WARN_ON(domain->wake_count == 0))
continue;
- if (--domain->wake_count)
+ if (--domain->wake_count) {
+ domain->active = true;
continue;
+ }
fw_domain_arm_timer(domain);
}
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index ff6fe2bb0ccf..5f90278da461 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -96,6 +96,7 @@ struct intel_uncore {
enum forcewake_domain_id id;
enum forcewake_domains mask;
unsigned int wake_count;
+ bool active;
struct hrtimer timer;
i915_reg_t reg_set;
i915_reg_t reg_ack;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dim: Enforce review requirements
On Wed, May 24, 2017 at 11:28:12AM +0200, Daniel Vetter wrote:
> We can't check this when applying (since r-b/a-b tags often get added
> afterwards), but we can check this when pushing. This only looks at
> patches authored by the pusher.
>
> Also update the docs to highlight that review requirements hold
> especially also for bugfixes.
>
> Cc: Patrik Jakobsson
> Cc: Lukas Wunner
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Sean Paul
I think I acked this on IRC, but just in case,
Acked-by: Sean Paul
> Signed-off-by: Daniel Vetter
> ---
> dim | 42 ++
> drm-misc.rst | 4 +++-
> 2 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/dim b/dim
> index baa0b3832314..79738a1b37a0 100755
> --- a/dim
> +++ b/dim
> @@ -340,6 +340,15 @@ function git_branch_exists # branch
> fi
> }
>
> +function git_committer_email
> +{
> + if ! commiter_email=$(git config --get user.email) ; then
> + commiter_email=$EMAIL
> + fi
> +
> + echo $commiter_email
> +}
> +
> # get message id from file
> # $1 = file
> message_get_id ()
> @@ -632,11 +641,32 @@ function dim_rebuild_tip
> exit 1
> fi
> }
> +
> +# additional patch checks before pushing, e.g. for r-b tags
> +function checkpatch_commit_push
> +{
> + local sha1
> +
> + sha1=$1
> +
> + # check for a-b/r-b tag
> + if git show -s $sha1 | grep -qi '\(reviewed\|acked\)\S*-by:' ; then
> + return
> + fi
> +
> + # check for commiter != author
> + if [[ $(git show -s $sha1 --format="format:%ce") != $(git show -s $sha1
> --format="format:%ae") ]]; then
> + return
> + fi
> +
> + warn_or_fail "$sha1 is lacking mandatory review"
> +}
> +
> # push branch $1, rebuild drm-tip. the rest of the arguments are passed to
> git
> # push.
> function dim_push_branch
> {
> - local branch remote
> + local branch remote commiter_email
>
> branch=${1:?$usage}
> shift
> @@ -645,6 +675,12 @@ function dim_push_branch
>
> remote=$(branch_to_remote $branch)
>
> + commiter_email=$(git_committer_email)
> +
> + for sha1 in $(git rev-list $branch@{u}..$branch
> --committer="$commiter_email" --no-merges) ; do
> + checkpatch_commit_push $sha1
> + done
> +
> git push $DRY_RUN $remote $branch "$@"
>
> update_linux_next $branch drm-intel-next-queued drm-intel-next-fixes
> drm-intel-fixes
> @@ -690,9 +726,7 @@ function dim_apply_branch
>
> message_id=$(message_get_id $file)
>
> - if ! commiter_email=$(git config --get user.email) ; then
> - commiter_email=$EMAIL
> - fi
> + commiter_email=$(git_committer_email)
>
> patch_from=$(grep "From:" "$file" | head -1)
> if [[ "$patch_from" != *"$commiter_email"* ]] ; then
> diff --git a/drm-misc.rst b/drm-misc.rst
> index caba8dc77696..d56c3c7f92a3 100644
> --- a/drm-misc.rst
> +++ b/drm-misc.rst
> @@ -90,7 +90,9 @@ Merge Criteria
> Right now the only hard merge criteria are:
>
> * Patch is properly reviewed or at least Ack, i.e. don't just push your own
> - stuff directly.
> + stuff directly. This rule holds even more for bugfix patches - it would be
> + embarrassing if the bugfix contains a small gotcha that review would have
> + caught.
>
> * drm-misc is for drm core (non-driver) patches, subsystem-wide refactorings,
>and small trivial patches all over (including drivers). For a detailed
> list of
> --
> 2.11.0
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-misc-fixes
On Fri, May 26, 2017 at 10:40:15AM +0300, Jani Nikula wrote: > On Fri, 26 May 2017, Daniel Vetter wrote: > > On Thu, May 25, 2017 at 7:44 PM, Sean Paul wrote: > >> The pull is noisy > >> because it includes -rc2. > > > > dim has you covered for this, in case you've rolled forward but Dave > > hasn't yet, you can regenerate against linus upstream branch for a > > cleaner pull (but still warn Dave ofc): > > > > $ dim pull-request drm-misc-next origin/master > > FWIW this is what I've always done with drm-intel-fixes. I had considered it, but wanted to make sure the PR merged cleanly into Dave's tree. I'll start basing off Linus' tree for -fixes in the future. Sean > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Technology Center -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Keep the forcewake timer alive for 1ms past the most recent use
== Series Details == Series: drm/i915: Keep the forcewake timer alive for 1ms past the most recent use URL : https://patchwork.freedesktop.org/series/24956/ State : success == Summary == Series 24956v1 drm/i915: Keep the forcewake timer alive for 1ms past the most recent use https://patchwork.freedesktop.org/api/1.0/series/24956/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-skl-6770hq) fdo#99739 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#99739 https://bugs.freedesktop.org/show_bug.cgi?id=99739 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:443s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:437s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:580s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:510s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:488s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:480s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:430s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:415s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:492s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:464s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:461s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:570s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:437s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:462s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:498s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:531s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:401s d53f251997f0e122a6cad2ef82488e8e8f744476 drm-tip: 2017y-05m-26d-13h-03m-36s UTC integration manifest 48a9428 drm/i915: Keep the forcewake timer alive for 1ms past the most recent use == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4820/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] Remaining patches for WM cleanup series
This series contains remaining two patches from wm cleanup series https://patchwork.freedesktop.org/series/20152/ Initial 10 patches already got merged in tree so sending remaining 2 separately. This series also includes a patch to solve underrun issue, when i915 is build as a module. Mahesh Kumar (3): drm/i915/skl+: Don't trust cached ddb values drm/i915/skl: New ddb allocation algorithm drm/i915/skl+: consider max supported plane pixel rate while scaling drivers/gpu/drm/i915/intel_display.c | 3 + drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_pm.c | 359 +-- 3 files changed, 261 insertions(+), 103 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/skl+: Don't trust cached ddb values
Don't trust cached DDB values. Recalculate the ddb value if cached value
is zero.
If i915 is build as a module, there may be a race condition when
cursor_disable call comes even before intel_fbdev_initial_config.
Which may lead to cached value being 0. And further commit will fail
until a modeset.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_pm.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 936eef1634c7..b67be1355e39 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3721,6 +3721,7 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_crtc *for_crtc = cstate->base.crtc;
unsigned int pipe_size, ddb_size;
+ unsigned int active_crtcs;
int nth_active_pipe;
if (WARN_ON(!state) || !cstate->base.active) {
@@ -3731,10 +3732,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
*dev,
}
if (intel_state->active_pipe_changes)
- *num_active = hweight32(intel_state->active_crtcs);
+ active_crtcs = intel_state->active_crtcs;
else
- *num_active = hweight32(dev_priv->active_crtcs);
+ active_crtcs = dev_priv->active_crtcs;
+ *num_active = hweight32(active_crtcs);
ddb_size = INTEL_INFO(dev_priv)->ddb_size;
WARN_ON(ddb_size == 0);
@@ -3754,12 +3756,15 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
*dev,
* copy from old state to be sure
*/
*alloc = to_intel_crtc_state(for_crtc->state)->wm.skl.ddb;
- return;
+ if (!skl_ddb_entry_size(alloc))
+ DRM_DEBUG_KMS("Cached pipe DDB is 0 recalculate\n");
+ else
+ return;
}
- nth_active_pipe = hweight32(intel_state->active_crtcs &
+ nth_active_pipe = hweight32(active_crtcs &
(drm_crtc_mask(for_crtc) - 1));
- pipe_size = ddb_size / hweight32(intel_state->active_crtcs);
+ pipe_size = ddb_size / hweight32(active_crtcs);
alloc->start = nth_active_pipe * ddb_size / *num_active;
alloc->end = alloc->start + pipe_size;
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/skl: New ddb allocation algorithm
This patch implements new DDB allocation algorithm as per HW team
recommendation. This algo takecare of scenario where we allocate less DDB
for the planes with lower relative pixel rate, but they require more DDB
to work.
It also takes care of enabling same watermark level for each
plane in crtc, for efficient power saving.
Changes since v1:
- Rebase on top of Paulo's patch series
Changes since v2:
- Fix the for loop condition to enable WM
Changes since v3:
- Fix crash in cursor i-g-t reported by Maarten
- Rebase after addressing Paulo's comments
- Few other ULT fixes
Changes since v4:
- Rebase on drm-tip
- Added separate function to enable WM levels
Changes since v5:
- Fix a crash identified in skl-6770HQ system
Changes since v6:
- Address review comments from Matt
Changes since v7:
- Fix failure return in skl_compute_plane_wm (Matt)
- fix typo
Changes since v8:
- Always check cursor wm enable irrespective of total_data_rate
Signed-off-by: Mahesh Kumar
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 257 +---
1 file changed, 159 insertions(+), 98 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b67be1355e39..46aca5cbc047 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4044,13 +4044,41 @@ skl_ddb_calc_min(const struct intel_crtc_state *cstate,
int num_active,
minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
}
+static void
+skl_enable_plane_wm_levels(const struct drm_i915_private *dev_priv,
+ uint16_t plane_ddb,
+ uint16_t max_level,
+ struct skl_plane_wm *wm)
+{
+ int level;
+ /*
+* Now enable all levels in WM structure which can be enabled
+* using current DDB allocation
+*/
+ for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
+ struct skl_wm_level *level_wm = &wm->wm[level];
+
+ if (level > max_level || level_wm->plane_res_b == 0
+ || level_wm->plane_res_l >= 31
+ || level_wm->plane_res_b >= plane_ddb) {
+ level_wm->plane_en = false;
+ level_wm->plane_res_b = 0;
+ level_wm->plane_res_l = 0;
+ } else {
+ level_wm->plane_en = true;
+ }
+ }
+}
+
static int
skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
+ struct skl_pipe_wm *pipe_wm,
struct skl_ddb_allocation *ddb /* out */)
{
struct drm_atomic_state *state = cstate->base.state;
struct drm_crtc *crtc = cstate->base.crtc;
struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
struct skl_ddb_entry *alloc = &cstate->wm.skl.ddb;
@@ -4063,6 +4091,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
unsigned plane_data_rate[I915_MAX_PLANES] = {};
unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
uint16_t total_min_blocks = 0;
+ uint16_t total_level_ddb;
+ uint16_t plane_blocks = 0;
+ int max_level, level;
/* Clear the partitioning for disabled planes. */
memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
@@ -4101,10 +4132,48 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
return -EINVAL;
}
- alloc_size -= total_min_blocks;
- ddb->plane[pipe][PLANE_CURSOR].start = alloc->end -
minimum[PLANE_CURSOR];
+ alloc_size -= minimum[PLANE_CURSOR];
+ ddb->plane[pipe][PLANE_CURSOR].start = alloc->end -
+ minimum[PLANE_CURSOR];
ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
+ for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
+ total_level_ddb = 0;
+ for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+ /*
+* TODO: We should calculate watermark values for Y/UV
+* plane both in case of NV12 format and use both values
+* for ddb calculation. NV12 is disabled as of now, So
+* using only single/UV plane value here.
+*/
+ struct skl_plane_wm *wm = &pipe_wm->planes[plane_id];
+ uint16_t plane_res_b = wm->wm[level].plane_res_b;
+ uint16_t min = minimum[plane_id] + y_minimum[plane_id];
+
+ if (plane_id == PLANE_CURSOR)
+ continue;
+
+ total_level_ddb += max(plane_res_b, min);
+ }
+
+ /*
+
[Intel-gfx] [PATCH 3/3] drm/i915/skl+: consider max supported plane pixel rate while scaling
A display resolution is only supported if it meets all the restrictions
below for Maximum Pipe Pixel Rate.
The display resolution must fit within the maximum pixel rate output
from the pipe. Make sure that the display pipe is able to feed pixels at
a rate required to support the desired resolution.
For each enabled plane on the pipe {
If plane scaling enabled {
Horizontal down scale amount = Maximum[1, plane horizontal size /
scaler horizontal window size]
Vertical down scale amount = Maximum[1, plane vertical size /
scaler vertical window size]
Plane down scale amount = Horizontal down scale amount *
Vertical down scale amount
Plane Ratio = 1 / Plane down scale amount
}
Else {
Plane Ratio = 1
}
If plane source pixel format is 64 bits per pixel {
Plane Ratio = Plane Ratio * 8/9
}
}
Pipe Ratio = Minimum Plane Ratio of all enabled planes on the pipe
If pipe scaling is enabled {
Horizontal down scale amount = Maximum[1, pipe horizontal source size /
scaler horizontal window size]
Vertical down scale amount = Maximum[1, pipe vertical source size /
scaler vertical window size]
Note: The progressive fetch - interlace display mode is equivalent to a
2.0 vertical down scale
Pipe down scale amount = Horizontal down scale amount *
Vertical down scale amount
Pipe Ratio = Pipe Ratio / Pipe down scale amount
}
Pipe maximum pixel rate = CDCLK frequency * Pipe Ratio
In this patch our calculation is based on pipe downscale amount
(plane max downscale amount * pipe downscale amount) instead of Pipe
Ratio. So,
max supported crtc clock with given scaling = CDCLK / pipe downscale.
Flip will fail if,
current crtc clock > max supported crct clock with given scaling.
Changes since V1:
- separate out fixed_16_16 wrapper API definition
Changes since V2:
- Fix buggy crtc !active condition (Maarten)
- use intel_wm_plane_visible wrapper as per Maarten's suggestion
Changes since V3:
- Change failure return from ERANGE to EINVAL
Changes since V4:
- Rebase based on previous patch changes
Changes since V5:
- return EINVAL instead of continue (Maarten)
Changes since V6:
- Improve commit message
- Address review comment
Changes since V7:
- use !enable instead of !active
- rename config variable for consistency (Maarten)
Signed-off-by: Mahesh Kumar
Reviewed-by: Matt Roper
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 3 ++
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pm.c | 87
3 files changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7fa21df5bcd7..fb2e43d3eb5b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11177,6 +11177,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
ret = skl_update_scaler_crtc(pipe_config);
if (!ret)
+ ret = skl_check_pipe_max_pixel_rate(intel_crtc,
+ pipe_config);
+ if (!ret)
ret = intel_atomic_setup_scalers(dev_priv, intel_crtc,
pipe_config);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index bd500977b3fc..93afac4a83fa 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1885,6 +1885,8 @@ bool skl_ddb_allocation_overlaps(const struct
skl_ddb_entry **entries,
int ignore);
bool ilk_disable_lp_wm(struct drm_device *dev);
int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
+int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
+ struct intel_crtc_state *cstate);
static inline int intel_enable_rc6(void)
{
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 46aca5cbc047..ead346f1deb2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3868,6 +3868,93 @@ skl_plane_downscale_amount(const struct intel_crtc_state
*cstate,
return mul_fixed16(downscale_w, downscale_h);
}
+static uint_fixed_16_16_t
+skl_pipe_downscale_amount(const struct intel_crtc_state *crtc_state)
+{
+ uint_fixed_16_16_t pipe_downscale = u32_to_fixed_16_16(1);
+
+ if (!crtc_state->base.enable)
+ return pipe_downscale;
+
+ if (crtc_state->pch_pfit.enabled) {
+ uint32_t src_w, src_h, dst_w, dst_h;
+ uint32_t pfit_size = crtc_state->pch_pfit.size;
+ uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
+ uint_fixed_16
[Intel-gfx] ✗ Fi.CI.BAT: warning for Remaining patches for WM cleanup series (rev3)
== Series Details == Series: Remaining patches for WM cleanup series (rev3) URL : https://patchwork.freedesktop.org/series/24615/ State : warning == Summary == Series 24615v3 Remaining patches for WM cleanup series https://patchwork.freedesktop.org/api/1.0/series/24615/revisions/3/mbox/ Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> DMESG-FAIL (fi-skl-6700hq) fdo#101144 Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-6700hq) fdo#100867 Subgroup basic-flip-vs-wf_vblank: pass -> SKIP (fi-skl-6700hq) fdo#99739 Subgroup basic-plain-flip: pass -> SKIP (fi-skl-6700hq) Test kms_frontbuffer_tracking: Subgroup basic: pass -> SKIP (fi-skl-6700hq) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> FAIL (fi-skl-6700hq) fdo#101154 +16 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fdo#100867 https://bugs.freedesktop.org/show_bug.cgi?id=100867 fdo#99739 https://bugs.freedesktop.org/show_bug.cgi?id=99739 fdo#101154 https://bugs.freedesktop.org/show_bug.cgi?id=101154 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:447s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:430s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:576s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:510s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:483s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:486s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:434s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:420s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:495s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:461s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:568s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:461s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:439s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:463s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:493s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:439s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:529s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:405s 235defd9a6d61596c283002e2b55694cec4806fc drm-tip: 2017y-05m-26d-14h-59m-56s UTC integration manifest 884c1d0 drm/i915/skl+: consider max supported plane pixel rate while scaling 8d9989d drm/i915/skl: New ddb allocation algorithm bf734bd drm/i915/skl+: Don't trust cached ddb values == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4821/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] drm/i915: Extend PARAMS_FOR_EACH macro with more data
Currently our PARAMS_FOR_EACH macro contains only param type and name.
We use this macro to define struct members, but later on we initialize
this struct using handcrafted code, which leads in some cases to use
mismatched value vs. type. Let's extend our root macro with param
default value to keep them in sync. Also drop ; from the macro to allow
more flexible usages.
Later on we can also add there permission, unsafe tag and description.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +--
drivers/gpu/drm/i915/i915_params.c| 42 ++
drivers/gpu/drm/i915/i915_params.h| 82 +--
4 files changed, 48 insertions(+), 84 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7e0816c..845b740 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -66,7 +66,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
#undef PRINT_FLAG
kernel_param_lock(THIS_MODULE);
-#define PRINT_PARAM(T, x) seq_print_param(m, #x, #T, &i915.x);
+#define PRINT_PARAM(T, x, v) seq_print_param(m, #x, #T, &i915.x);
I915_PARAMS_FOR_EACH(PRINT_PARAM);
#undef PRINT_PARAM
kernel_param_unlock(THIS_MODULE);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index e18f350..4f181b4 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -566,7 +566,7 @@ static __always_inline void err_print_param(struct
drm_i915_error_state_buf *m,
static void err_print_params(struct drm_i915_error_state_buf *m,
const struct i915_params *p)
{
-#define PRINT(T, x) err_print_param(m, #x, #T, &p->x);
+#define PRINT(T, x, v) err_print_param(m, #x, #T, &p->x);
I915_PARAMS_FOR_EACH(PRINT);
#undef PRINT
}
@@ -860,7 +860,7 @@ void __i915_gpu_state_free(struct kref *error_ref)
kfree(error->overlay);
kfree(error->display);
-#define FREE(T, x) free_param(#T, &error->params.x);
+#define FREE(T, x, v) free_param(#T, &error->params.x);
I915_PARAMS_FOR_EACH(FREE);
#undef FREE
@@ -1694,7 +1694,7 @@ static int capture(void *data)
error->i915->gt.last_init_time));
error->params = i915;
-#define DUP(T, x) dup_param(#T, &error->params.x);
+#define DUP(T, x, v) dup_param(#T, &error->params.x);
I915_PARAMS_FOR_EACH(DUP);
#undef DUP
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e36..e74c7bd 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -25,47 +25,11 @@
#include "i915_params.h"
#include "i915_drv.h"
+#define MEMBER(T, member, value) .member = value,
struct i915_params i915 __read_mostly = {
- .modeset = -1,
- .panel_ignore_lid = 1,
- .semaphores = -1,
- .lvds_channel_mode = 0,
- .panel_use_ssc = -1,
- .vbt_sdvo_panel_type = -1,
- .enable_rc6 = -1,
- .enable_dc = -1,
- .enable_fbc = -1,
- .enable_execlists = -1,
- .enable_hangcheck = true,
- .enable_ppgtt = -1,
- .enable_psr = -1,
- .alpha_support = IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT),
- .disable_power_well = -1,
- .enable_ips = 1,
- .fastboot = 0,
- .prefault_disable = 0,
- .load_detect_test = 0,
- .force_reset_modeset_test = 0,
- .reset = true,
- .error_capture = true,
- .invert_brightness = 0,
- .disable_display = 0,
- .enable_cmd_parser = true,
- .use_mmio_flip = 0,
- .mmio_debug = 0,
- .verbose_state_checks = 1,
- .nuclear_pageflip = 0,
- .edp_vswing = 0,
- .enable_guc_loading = 0,
- .enable_guc_submission = 0,
- .guc_log_level = -1,
- .guc_firmware_path = NULL,
- .huc_firmware_path = NULL,
- .enable_dp_mst = true,
- .inject_load_failure = 0,
- .enable_dpcd_backlight = false,
- .enable_gvt = false,
+ I915_PARAMS_FOR_EACH(MEMBER)
};
+#undef MEMBER
module_param_named(modeset, i915.modeset, int, 0400);
MODULE_PARM_DESC(modeset,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc..ca72a8c 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -28,50 +28,50 @@
#include /* for __read_mostly */
#define I915_PARAMS_FOR_EACH(func) \
- func(int, modeset); \
- func(int, panel_ignore_lid); \
- func(int, semaphores); \
- func(int, lvds_channel_mode); \
- func(int, panel_use_ssc); \
- func(int, vbt_sdvo_panel_type); \
- func(int, enable_rc6); \
- func(int, enable_dc); \
- func(int, enable_fbc); \
- func(int, enable_ppgtt); \
- func(int, enable_execlists); \
Re: [Intel-gfx] [RFC] drm/i915: Extend PARAMS_FOR_EACH macro with more data
On Fri, May 26, 2017 at 03:44:29PM +, Michal Wajdeczko wrote: > Currently our PARAMS_FOR_EACH macro contains only param type and name. > We use this macro to define struct members, but later on we initialize > this struct using handcrafted code, which leads in some cases to use > mismatched value vs. type. Let's extend our root macro with param > default value to keep them in sync. Also drop ; from the macro to allow > more flexible usages. Completely overlooked the initialization, so that looks to be a good improvement. You can also add the default value to the printers, and if possible highlight values that have been changed by the user -- we could include the unsafe notifier in that as well. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Extend PARAMS_FOR_EACH macro with more data
== Series Details == Series: drm/i915: Extend PARAMS_FOR_EACH macro with more data URL : https://patchwork.freedesktop.org/series/24962/ State : warning == Summary == Series 24962v1 drm/i915: Extend PARAMS_FOR_EACH macro with more data https://patchwork.freedesktop.org/api/1.0/series/24962/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> DMESG-FAIL (fi-skl-6700hq) fdo#101144 Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-6700hq) fdo#100867 Subgroup basic-flip-vs-wf_vblank: pass -> SKIP (fi-skl-6700hq) fdo#99739 Subgroup basic-plain-flip: pass -> SKIP (fi-skl-6700hq) Test kms_frontbuffer_tracking: Subgroup basic: pass -> SKIP (fi-skl-6700hq) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> FAIL (fi-skl-6700hq) fdo#101154 +16 Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bsw-n3050) fdo#100651 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fdo#100867 https://bugs.freedesktop.org/show_bug.cgi?id=100867 fdo#99739 https://bugs.freedesktop.org/show_bug.cgi?id=99739 fdo#101154 https://bugs.freedesktop.org/show_bug.cgi?id=101154 fdo#100651 https://bugs.freedesktop.org/show_bug.cgi?id=100651 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:445s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:430s fi-bsw-n3050 total:237 pass:204 dwarn:0 dfail:0 fail:0 skip:32 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:510s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:482s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:480s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:438s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:414s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:486s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:472s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:463s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:565s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:457s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:435s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:469s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:509s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:535s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:400s 235defd9a6d61596c283002e2b55694cec4806fc drm-tip: 2017y-05m-26d-14h-59m-56s UTC integration manifest 7a57852 drm/i915: Extend PARAMS_FOR_EACH macro with more data == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4822/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20
I believe we need to cc:stable on this right?!
Jani, is this ok to go ahead and merge after stable is cc'ed?
On Thu, May 25, 2017 at 9:43 AM, vathsala nagaraju
wrote:
> psr1 is also disabled for panel resolution greater than 32X20.
> Added psr2 check to disable only for psr2 panels having resolution
> greater than 32X20.
>
> issue was introduced by
> commit-id : "acf45d11050abd751dcec986ab121cb2367dcbba"
> commit message: "PSR2 is restricted to work with panel resolutions
> upto 3200x2000, move the check to intel_psr_match_conditions and fully
> block psr."
>
> v2: (Rodrigo)
>Add previous commit details which introduced the issue
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Cc: Yaroslav Shabalin
> Reported-by: Yaroslav Shabalin
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: vathsala nagaraju
> ---
> drivers/gpu/drm/i915/intel_psr.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3780d0..559f1ab 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -435,8 +435,9 @@ static bool intel_psr_match_conditions(struct intel_dp
> *intel_dp)
> }
>
> /* PSR2 is restricted to work with panel resolutions upto 3200x2000 */
> - if (intel_crtc->config->pipe_src_w > 3200 ||
> - intel_crtc->config->pipe_src_h > 2000) {
> + if (dev_priv->psr.psr2_support &&
> + (intel_crtc->config->pipe_src_w > 3200 ||
> +intel_crtc->config->pipe_src_h > 2000)) {
> dev_priv->psr.psr2_support = false;
> return false;
> }
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Dave, Here's another misc-next pull for you. We have some nice improvements in core adding mode_valid hooks and de-duping the allocation code. Daniel continues to improve documentation (\o/), and a bunch of little stuff was fixed up. Also noteworthy is that I backmerged -next so Daniel could pick up Michal's kvmalloc set. drm-misc-next-2017-05-26: UAPI Changes: - Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI (Robert) Cross-subsystem Changes: - Standardize sync_file.txt documentation format (Mauro) Core Changes: - Turf drm_[cm]alloc functions for kvmalloc alternatives (Michal) - Add optional mode_valid() hook to crtc/encoder/bridge (Jose) - Improve documentation around mode validation/alteration (Daniel) - Reduce sync_file construction time by deferring name creation (Chris) Driver Changes: - pl111: Wire up the clock divider and add debugfs (Eric) - various: Fix include notation and remove -Iinclude/drm (Masahiro) - stm: Add Benjamin Gaignard and Vincent Abriou as STM maintainers (Vincent) - various: Miscellaneous trivial fixes to pl111/stm/vgem/vc4 Cc: Michal Hocko Cc: Eric Anholt Cc: Masahiro Yamada Cc: Robert Foss Cc: Vincent Abriou Cc: Jose Abreu Cc: Daniel Vetter Cc: Chris Wilson Cc: Mauro Carvalho Chehab Happy weekend, Sean The following changes since commit e98c58e55f68f8785aebfab1f8c9a03d8de0afe1: Merge tag 'drm-misc-next-2017-05-16' of git://anongit.freedesktop.org/git/drm-misc into drm-next (2017-05-18 12:57:06 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-05-26 for you to fetch changes up to 71ebc9a3795818eab52e81bbcbdfae130ee35d9e: dma-buf/sync-file: Defer creation of sync_file->name (2017-05-24 13:08:29 -0300) UAPI Changes: - Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI (Robert) Cross-subsystem Changes: - Standardize sync_file.txt documentation format (Mauro) Core Changes: - Turf drm_[cm]alloc functions for kvmalloc alternatives (Michal) - Add optional mode_valid() hook to crtc/encoder/bridge (Jose) - Improve documentation around mode validation/alteration (Daniel) - Reduce sync_file construction time by deferring name creation (Chris) Driver Changes: - pl111: Wire up the clock divider and add debugfs (Eric) - various: Fix include notation and remove -Iinclude/drm (Masahiro) - stm: Add Benjamin Gaignard and Vincent Abriou as STM maintainers (Vincent) - various: Miscellaneous trivial fixes to pl111/stm/vgem/vc4 Cc: Michal Hocko Cc: Eric Anholt Cc: Masahiro Yamada Cc: Robert Foss Cc: Vincent Abriou Cc: Jose Abreu Cc: Daniel Vetter Cc: Chris Wilson Cc: Mauro Carvalho Chehab Arnd Bergmann (2): gpu: host1x: select IOMMU_IOVA gpu: drm: gma500: remove two more dead variable Chris Wilson (1): dma-buf/sync-file: Defer creation of sync_file->name Colin Ian King (4): drm/vc4: fix spelling mistake: "dimesions" -> "dimensions" drm/sti:fix spelling mistake: "compoment" -> "component" drm/pl111: make structure pl111_display_funcs static drm/pl111: make structure mode_config_funcs static Daniel Vetter (2): drm/doc: Document adjusted/request modes a bit better drm/doc: Clarify mode_fixup vs. atomic_check a bit more Eric Anholt (4): drm/vc4: Enable selection in Kconfig on any 32-bit BCM platform. drm/vc4: Adjust modes in DSI to work around the integer PLL divider. drm/pl111: Register the clock divider and use it. drm/pl111: Add a debugfs node to dump our registers. Gabriel Krisman Bertazi (1): drm: trivial documentation fix to drm_for_each_connector_iter Jose Abreu (1): drm: Add crtc/encoder/bridge->mode_valid() callbacks Masahiro Yamada (31): drm: make drm_panel.h self-contained drm/ttm: fix include notation and remove -Iinclude/drm flag drm/amd: fix include notation and remove -Iinclude/drm flag drm/ast: fix include notation and remove -Iinclude/drm flag drm/bochs: fix include notation and remove -Iinclude/drm flag drm/bridge: fix include notation and remove -Iinclude/drm flag drm/cirrus: fix include notation and remove -Iinclude/drm flag drm/hisilicon: fix include notation and remove -Iinclude/drm flag drm/mgag200: fix include notation and remove -Iinclude/drm flag drm/msm: fix include notation and remove -Iinclude/drm flag drm/nouveau: fix include notation and remove -Iinclude/drm flag drm/qxl: fix include notation and remove -Iinclude/drm flag drm/radeon: fix include notation and remove -Iinclude/drm flag drm/tilcdc: fix include notation and remove -Iinclude/drm flag drm/virtio: fix include notation and remove -Iinclude/drm flag drm/vmwgfx: fix include notation and remove -Iinclude/drm flag drm/gma500: remove unneeded -Iinclude/drm c
Re: [Intel-gfx] [PATCH 1/3] drm/i915/skl+: Don't trust cached ddb values
On Fri, May 26, 2017 at 8:15 AM, Mahesh Kumar wrote:
> Don't trust cached DDB values. Recalculate the ddb value if cached value
> is zero.
>
> If i915 is build as a module, there may be a race condition when
> cursor_disable call comes even before intel_fbdev_initial_config.
> Which may lead to cached value being 0. And further commit will fail
> until a modeset.
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/intel_pm.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 936eef1634c7..b67be1355e39 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3721,6 +3721,7 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
> *dev,
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_crtc *for_crtc = cstate->base.crtc;
> unsigned int pipe_size, ddb_size;
> + unsigned int active_crtcs;
> int nth_active_pipe;
>
> if (WARN_ON(!state) || !cstate->base.active) {
> @@ -3731,10 +3732,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
> *dev,
> }
>
> if (intel_state->active_pipe_changes)
> - *num_active = hweight32(intel_state->active_crtcs);
> + active_crtcs = intel_state->active_crtcs;
> else
> - *num_active = hweight32(dev_priv->active_crtcs);
> + active_crtcs = dev_priv->active_crtcs;
>
> + *num_active = hweight32(active_crtcs);
> ddb_size = INTEL_INFO(dev_priv)->ddb_size;
> WARN_ON(ddb_size == 0);
>
> @@ -3754,12 +3756,15 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
> *dev,
> * copy from old state to be sure
> */
> *alloc = to_intel_crtc_state(for_crtc->state)->wm.skl.ddb;
> - return;
> + if (!skl_ddb_entry_size(alloc))
> + DRM_DEBUG_KMS("Cached pipe DDB is 0 recalculate\n");
> + else
> + return;
I see 2 different patches inside this patch here. One is this chunk
here that does what commit message tells.
> }
>
> - nth_active_pipe = hweight32(intel_state->active_crtcs &
> + nth_active_pipe = hweight32(active_crtcs &
> (drm_crtc_mask(for_crtc) - 1));
> - pipe_size = ddb_size / hweight32(intel_state->active_crtcs);
> + pipe_size = ddb_size / hweight32(active_crtcs);
While this is fixing another bug where we were still using
intel_state->active_crtcs here even when we use dev_priv->active_crtcs
for num_active.
Am I missing or misunderstanding something?
> alloc->start = nth_active_pipe * ddb_size / *num_active;
> alloc->end = alloc->start + pipe_size;
> }
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Defined NM doesn't work on KBL and uses automatic N/M.
"The patch is probably fine. But I can't invent an explanation if I don't know
what the problem is."
@Jani @libin, is it possible for you to help contact Intel graphics hardware
design engineer to get the reason why M/N doesn't work as you implemented in
kernel code in Kabylake platform? I don't find good reason in bspec. Thanks.
-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Friday, May 26, 2017 7:01 PM
To: Wang, Quanxian ; intel-gfx@lists.freedesktop.org
Cc: Yang, Libin
Subject: RE: [PATCH] Defined NM doesn't work on KBL and uses automatic N/M.
On Fri, 26 May 2017, "Wang, Quanxian" wrote:
> [Wang, Quanxian] in Ubuntu 17.04, we do audio testing on KBL/SKL/APL
> and more, the audio doesn't work on KBL specially, and other platform
> works fine. Even if with latest upstream kernel, but it works on 4.8
> kernel. Therefore It is a regression issue. After investigation, we
> found it is caused by commit
> "6014ac122ed081feca99217bc57b2e15c7fc1a51] drm/i915/audio: set proper
> N/M in modeset". Therefore I provided this patch.
If it's a regression, we need to backport the fix to stable kernels, and the
patch needs annotation:
Fixes: 6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset")
Cc: # v4.10+
> After getting suggestion from you and Libin, we do more testing on 4K
> monitor for audio delay issue. Also talked with Libin why not use
> transcoder disable/enable process described in bspec, it will affect
> performance.
>
> This is the whole story. You can check LCK number 3791 in Intel JIRA
> about that.
Actually, I can't. And the commit message needs to have the explanation. I
still do not know what the bug is specifically, or why Kabylake, and only
Kabylake, needs this.
> [Wang, Quanxian] Basically if upstream could provide a reasonable
> patch, it will appreciate since you are expert in this area.
> Thanks for your understanding.
The patch is probably fine. But I can't invent an explanation if I don't know
what the problem is.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 5/5] drm/i915: Set PWM divider to match desired frequency in vbt
Good catch.
It will use default frequency in this case. But it is better to not
set DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP in this case.
I will add return value to intel_dp_aux_set_pwm_freq() and set
DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP based on that.
On Fri, May 26, 2017 at 5:49 AM, Jani Nikula
wrote:
> On Tue, 23 May 2017, Puthikorn Voravootivat wrote:
> > Read desired PWM frequency from panel vbt and calculate the
> > value for divider in DPCD address 0x724 and 0x728 to have
> > as many bits as possible for PWM duty cyle for granularity of
> > brightness adjustment while the frequency divisor is still
> > within 25% of the desired value.
>
> IIUC this patch doesn't have a dependency on the more contentious
> patches 2/5 and 3/5. This should probably be merged before them.
>
> I share DK's concern about doing a bunch of reads and writes and
> calculations every time the backlight's enabled. But I guess that could
> be optimized later.
>
> I haven't had time to check the changed algorithm here, but in the mean
> time one comment below.
>
> BR,
> Jani.
>
>
> >
> > Signed-off-by: Puthikorn Voravootivat
> > ---
> > drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 82
> +++
> > 1 file changed, 82 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index f1b7855a2d2a..b7cd44550127 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -116,10 +116,85 @@ intel_dp_aux_set_dynamic_backlight_percent(struct
> intel_dp *intel_dp,
> > }
> > }
> >
> > +/*
> > + * Set PWM Frequency divider to match desired frequency in vbt.
> > + * The PWM Frequency is calculated as 27Mhz / (F x P).
> > + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0
> of the
> > + * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
> > + * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of
> the
> > + * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> > + */
> > +static void intel_dp_aux_set_pwm_freq(struct intel_connector
> *connector)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + struct intel_dp *intel_dp = enc_to_intel_dp(&connector->
> encoder->base);
> > + int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
> > + u8 pn, pn_min, pn_max;
> > +
> > + /* Find desired value of (F x P)
> > + * Note that, if F x P is out of supported range, the maximum
> value or
> > + * minimum value will applied automatically. So no need to check
> that.
> > + */
> > + freq = dev_priv->vbt.backlight.pwm_freq_hz;
> > + DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
> > + if (!freq) {
> > + DRM_DEBUG_KMS("Use panel default backlight frequency\n");
> > + return;
> > + }
> > +
> > + fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ),
> freq);
> > +
> > + /* Use highest possible value of Pn for more granularity of
> brightness
> > + * adjustment while satifying the conditions below.
> > + * - Pn is in the range of Pn_min and Pn_max
> > + * - F is in the range of 1 and 255
> > + * - FxP is within 25% of desired value.
> > + * Note: 25% is arbitrary value and may need some tweak.
> > + */
> > + if (drm_dp_dpcd_readb(&intel_dp->aux,
> > +DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, &pn_min)
> != 1) {
> > + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
> > + return;
> > + }
> > + if (drm_dp_dpcd_readb(&intel_dp->aux,
> > +DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, &pn_max)
> != 1) {
> > + DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
> > + return;
> > + }
> > + pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> > + pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> > +
> > + fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
> > + fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
> > + if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
> > + DRM_DEBUG_KMS("VBT defined backlight frequency out of
> range\n");
> > + return;
> > + }
> > +
> > + for (pn = pn_max; pn >= pn_min; pn--) {
> > + f = clamp(DIV_ROUND_CLOSEST(fxp , 1 << pn), 1, 255);
> > + fxp_actual = f << pn;
> > + if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
> > + break;
> > + }
> > +
> > + if (drm_dp_dpcd_writeb(&intel_dp->aux,
> > +DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
> > + DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
> > + return;
> > + }
> > + if (drm_dp_dpcd_writeb(&intel_dp->aux,
> > +DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
> > + DRM_DEBUG_KMS("Failed to writ
[Intel-gfx] [PATCH 3/3] RFC drm/i915: Don't increase the BW when WA is not required.
Based on patch submited to intel-gfx:
"drm/i915/cnl: don't apply the GEN9/CNL:A WM WAs to CNL:B+"
and subsequential tests on CNL, it seems that
this part is not required if we are not applying WA#0893.
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 919235c..85d9705 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4356,7 +4356,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
res_lines = div_round_up_fixed16(selected_result,
plane_blocks_per_line);
- if (level >= 1 && level <= 7) {
+ if (NEEDS_WaIncreaseMemoryBW(dev_priv) && level >= 1 && level <= 7) {
if (y_tiled) {
res_blocks +=
fixed_16_16_to_u32_round_up(y_tile_minimum);
res_lines += y_min_scanlines;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Wa#0893 is defined per platform.
No detection will ever be needed. So let's simplify
and clean it up.
Cc: Mahesh Kumar
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i915/intel_pm.c | 21 ++---
2 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d2a5749..5abeb3f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2904,6 +2904,10 @@ static inline struct scatterlist *__sg_next(struct
scatterlist *sg)
#define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
(IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
+/* WA#0893 */
+#define NEEDS_WaIncreaseMemoryBW(dev_priv) (IS_GEN9_BC(dev_priv) || \
+IS_BROXTON(dev_priv))
+
/*
* dp aux and gmbus irq on gen4 seems to be able to generate legacy interrupts
* even when in MSI mode. This results in spurious interrupt warnings if the
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 32b3b3e..919235c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3532,21 +3532,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
#define SKL_SAGV_BLOCK_TIME30 /* µs */
-/*
- * FIXME: We still don't have the proper code detect if we need to apply the
WA,
- * so assume we'll always need it in order to avoid underruns.
- */
-static bool skl_needs_memory_bw_wa(struct intel_atomic_state *state)
-{
- struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-
- /* WA#0893: GEN9:ALL */
- if (IS_GEN9(dev_priv))
- return true;
-
- return false;
-}
-
static bool
intel_has_sagv(struct drm_i915_private *dev_priv)
{
@@ -3694,7 +3679,7 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
latency = dev_priv->wm.skl_latency[level];
- if (skl_needs_memory_bw_wa(intel_state) &&
+ if (NEEDS_WaIncreaseMemoryBW(dev_priv) &&
plane->base.state->fb->modifier ==
I915_FORMAT_MOD_X_TILED)
latency += 15;
@@ -4265,9 +4250,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint32_t plane_pixel_rate;
uint_fixed_16_16_t y_tile_minimum;
uint32_t y_min_scanlines;
- struct intel_atomic_state *state =
- to_intel_atomic_state(cstate->base.state);
- bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
+ bool apply_memory_bw_wa = NEEDS_WaIncreaseMemoryBW(dev_priv);
bool y_tiled, x_tiled;
if (latency == 0 ||
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/glk: WA#0893: Also apply memory bw wa to Geminilake.
According to spec this WA is needed for every gen9. Cc:Arthur Runyan Cc: Ander Conselvan de Oliveira Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 5abeb3f..7a5f2e4 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2904,9 +2904,8 @@ static inline struct scatterlist *__sg_next(struct scatterlist *sg) #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \ (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv)) -/* WA#0893 */ -#define NEEDS_WaIncreaseMemoryBW(dev_priv) (IS_GEN9_BC(dev_priv) || \ -IS_BROXTON(dev_priv)) +/* WA#0893: GEN9:ALL */ +#define NEEDS_WaIncreaseMemoryBW(dev_priv) (IS_GEN9(dev_priv)) /* * dp aux and gmbus irq on gen4 seems to be able to generate legacy interrupts -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH v3 5/5] ACPI: button: Always notify kernel space using _LID returning value
Both nouveau and i915, the only 2 kernel space lid notification listeners,
invoke acpi_lid_open() API to obtain _LID returning value instead of using
the notified value.
So this patch moves this logic from listeners to lid driver, always notify
kernel space listeners using _LID returning value.
This is a no-op cleanup, but facilitates administrators to configure to
notify kernel drivers with faked lid init states via command line
"button.lid_notify_init_state=Y".
Cc:
Cc:
Cc: Benjamin Tissoires
Cc: Peter Hutterer
Signed-off-by: Lv Zheng
---
drivers/acpi/button.c | 16 ++--
drivers/gpu/drm/i915/intel_lvds.c | 2 +-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index 4abf8ae..e047d34 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -119,6 +119,9 @@ static u8 lid_init_state = ACPI_BUTTON_LID_INIT_OPEN;
static unsigned long lid_report_interval __read_mostly = 500;
module_param(lid_report_interval, ulong, 0644);
MODULE_PARM_DESC(lid_report_interval, "Interval (ms) between lid key events");
+static bool lid_notify_init_state __read_mostly = false;
+module_param(lid_notify_init_state, bool, 0644);
+MODULE_PARM_DESC(lid_notify_init_state, "Notify init lid state to kernel
drivers after boot/resume");
/* --
FS Interface (/proc)
@@ -224,6 +227,15 @@ static void acpi_lid_notify_state(struct acpi_device
*device,
if (state)
pm_wakeup_event(&device->dev, 0);
+ if (!lid_notify_init_state) {
+ /*
+* There are cases "state" is not a _LID return value, so
+* correct it before notification.
+*/
+ if (!bios_notify &&
+ lid_init_state != ACPI_BUTTON_LID_INIT_METHOD)
+ state = acpi_lid_evaluate_state(device);
+ }
acpi_lid_notifier_call(device, state);
}
@@ -572,10 +584,10 @@ static int param_set_lid_init_state(const char *val,
struct kernel_param *kp)
if (!strncmp(val, "open", sizeof("open") - 1)) {
lid_init_state = ACPI_BUTTON_LID_INIT_OPEN;
- pr_info("Notify initial lid state as open\n");
+ pr_info("Notify initial lid state to users space as open and
kernel drivers with _LID return value\n");
} else if (!strncmp(val, "method", sizeof("method") - 1)) {
lid_init_state = ACPI_BUTTON_LID_INIT_METHOD;
- pr_info("Notify initial lid state with _LID return value\n");
+ pr_info("Notify initial lid state to user/kernel space with
_LID return value\n");
} else if (!strncmp(val, "ignore", sizeof("ignore") - 1)) {
lid_init_state = ACPI_BUTTON_LID_INIT_IGNORE;
pr_info("Do not notify initial lid state\n");
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 9ca4dc4..8ca9080 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -548,7 +548,7 @@ static int intel_lid_notify(struct notifier_block *nb,
unsigned long val,
/* Don't force modeset on machines where it causes a GPU lockup */
if (dmi_check_system(intel_no_modeset_on_lid))
goto exit;
- if (!acpi_lid_open()) {
+ if (!val) {
/* do modeset on next lid open event */
dev_priv->modeset_restore = MODESET_ON_LID_OPEN;
goto exit;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 3/3] drm/i915: Set PWM divider to match desired frequency in vbt
Read desired PWM frequency from panel vbt and calculate the
value for divider in DPCD address 0x724 and 0x728 to have
as many bits as possible for PWM duty cyle for granularity of
brightness adjustment while the frequency divisor is still
within 25% of the desired value.
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 79 +++
1 file changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index f55af41ce3bd..a8d485a29f29 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -116,6 +116,81 @@ intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp
*intel_dp,
}
}
+/*
+ * Set PWM Frequency divider to match desired frequency in vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
+ * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
+ */
+static int intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
+ int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
+ u8 pn, pn_min, pn_max;
+
+ /* Find desired value of (F x P)
+* Note that, if F x P is out of supported range, the maximum value or
+* minimum value will applied automatically. So no need to check that.
+*/
+ freq = dev_priv->vbt.backlight.pwm_freq_hz;
+ DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
+ if (!freq) {
+ DRM_DEBUG_KMS("Use panel default backlight frequency\n");
+ return -1;
+ }
+
+ fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
+
+ /* Use highest possible value of Pn for more granularity of brightness
+* adjustment while satifying the conditions below.
+* - Pn is in the range of Pn_min and Pn_max
+* - F is in the range of 1 and 255
+* - FxP is within 25% of desired value.
+* Note: 25% is arbitrary value and may need some tweak.
+*/
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, &pn_min) != 1) {
+ DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
+ return -EIO;
+ }
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, &pn_max) != 1) {
+ DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
+ return -EIO;
+ }
+ pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+ pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+
+ fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
+ fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
+ if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
+ DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
+ return -ERANGE;
+ }
+
+ for (pn = pn_max; pn >= pn_min; pn--) {
+ f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
+ fxp_actual = f << pn;
+ if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
+ break;
+ }
+
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
+ DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
+ return -EIO;
+ }
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
+ DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
+ return -EIO;
+ }
+ return 0;
+}
+
static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
{
struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
@@ -152,6 +227,10 @@ static void intel_dp_aux_enable_backlight(struct
intel_connector *connector)
DRM_DEBUG_KMS("Enable dynamic brightness.\n");
}
+ if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
+ if (!intel_dp_aux_set_pwm_freq(connector))
+ new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
--
2.13.0.219.gdb65acc882-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 2/3] drm/i915: Add option to support dynamic backlight via DPCD
This patch adds option to enable dynamic backlight for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/i915_params.c| 5
drivers/gpu/drm/i915/i915_params.h| 3 +-
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 42 ++-
3 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 3758ae1f11b4..ce033d58134e 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
.inject_load_failure = 0,
.enable_dpcd_backlight = -1,
.enable_gvt = false,
+ .enable_dbc = false,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -254,3 +255,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
MODULE_PARM_DESC(enable_gvt,
"Enable support for Intel GVT-g graphics virtualization host
support(default:false)");
+
+module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
+MODULE_PARM_DESC(enable_dbc,
+ "Enable support for dynamic backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index ac02efce6e22..2de3e2850b54 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -67,7 +67,8 @@
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
func(int, enable_dpcd_backlight); \
- func(bool, enable_gvt)
+ func(bool, enable_gvt); \
+ func(bool, enable_dbc)
#define MEMBER(T, member) T member
struct i915_params {
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index c89aae804659..f55af41ce3bd 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -100,11 +100,26 @@ intel_dp_aux_set_backlight(struct intel_connector
*connector, u32 level)
}
}
+/*
+ * Set minimum / maximum dynamic brightness percentage. This value is expressed
+ * as the percentage of normal brightness in 5% increments.
+ */
+static void
+intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
+ u32 min, u32 max)
+{
+ u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
+
+ if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
+ dbc, sizeof(dbc)) < 0) {
+ DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
+ }
+}
+
static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
{
struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
- uint8_t dpcd_buf = 0;
- uint8_t edp_backlight_mode = 0;
+ uint8_t dpcd_buf, new_dpcd_buf, edp_backlight_mode;
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, &dpcd_buf) != 1) {
@@ -113,18 +128,15 @@ static void intel_dp_aux_enable_backlight(struct
intel_connector *connector)
return;
}
+ new_dpcd_buf = dpcd_buf;
edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
switch (edp_backlight_mode) {
case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
- dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
- dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
- if (drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
- DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
- }
+ new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+ new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
break;
/* Do nothing when it is already DPCD mode */
@@ -133,6 +145,20 @@ static void intel_dp_aux_enable_backlight(struct
intel_connector *connector)
break;
}
+ if (i915.enable_dbc &&
+ (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
+ new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
+ intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
+ DRM_DEBUG_KMS("Enable dynamic brightness.\n");
+ }
+
+ if (new_dpcd_buf != dpcd_buf) {
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
+ DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+ }
+ }
+
s
[Intel-gfx] [PATCH v10 0/3] Enhancement to intel_dp_aux_backlight driver
This patch set contain 3 patches. Another 6 patches in previous version was already merged in v7 and v9. - First patch adds heuristic to determine whether we should use AUX or PWM pin to adjust panel backlight brightness. - Next patch adds support for dynamic brightness. - Last patch sets the PWM freqency to match data in panel vbt. Change log: v10: - Add heuristic in patch #1 - Add _unsafe mod option in patch #1, #2 - handle frequency set error in patch #3 v9: - Fix nits in v8 v8: - Drop 4 patches that was already merged - Move DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check to patch #2 to avoid behavior change if only apply patch #1 - Add TODO to warn about enable backlight twice in patch #2 - Use DIV_ROUND_CLOSEST instead of just "/" in patch #5 - Fix bug calculate pn in patch #5 - Clarify commit message / code comment in patch #5 v7: - Add check in intel_dp_pwm_pin_display_control_capable in patch #4 - Add option in patch #6 to enable DPCD or not - Change definition in patch #8 and implementation in #9 to use Khz - Fix compiler warning from build bot in patch #9 v6: - Address review from Dhinakaran - Make PWM frequency to have highest value of Pn that make the frequency still within 25% of desired frequency. v5: - Split first patch in v4 to 3 patches - Bump priority for "Correctly enable backlight brightness adjustment via DPCD" - Make logic clearer for the case that both PWM pin and AUX are supported - Add more log when write to register fail - Add log when enable DBC v4: - Rebase / minor typo fix. v3: - Add new implementation of PWM frequency patch v2: - Drop PWM frequency patch - Address suggestion from Jani Nikula Puthikorn Voravootivat (3): drm/i915: Add heuristic to determine better way to adjust brightness drm/i915: Add option to support dynamic backlight via DPCD drm/i915: Set PWM divider to match desired frequency in vbt drivers/gpu/drm/i915/i915_params.c| 12 +- drivers/gpu/drm/i915/i915_params.h| 5 +- drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 185 -- 3 files changed, 186 insertions(+), 16 deletions(-) -- 2.13.0.219.gdb65acc882-goog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 1/3] drm/i915: Add heuristic to determine better way to adjust brightness
Add heuristic to decide that AUX or PWM pin should use for
backlight brightness adjustment and modify i915 param description
to have auto, force disable, and force enable.
The heuristic to determine that using AUX pin is better than using
PWM pin is that the panel support any of the feature list here.
- Regional backlight brightness adjustment
- Backlight PWM frequency set
- More than 8 bits resolution of brightness level
- Backlight enablement via AUX and not by BL_ENABLE pin
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/i915_params.c| 7 +--
drivers/gpu/drm/i915/i915_params.h| 2 +-
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 64 +--
3 files changed, 66 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..3758ae1f11b4 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
.huc_firmware_path = NULL,
.enable_dp_mst = true,
.inject_load_failure = 0,
- .enable_dpcd_backlight = false,
+ .enable_dpcd_backlight = -1,
.enable_gvt = false,
};
@@ -246,9 +246,10 @@ MODULE_PARM_DESC(enable_dp_mst,
module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint,
0400);
MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled
(default), N:force failure at the Nth failure check point)");
-module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
0600);
+module_param_named_unsafe(enable_dpcd_backlight, i915.enable_dpcd_backlight,
int, 0600);
MODULE_PARM_DESC(enable_dpcd_backlight,
- "Enable support for DPCD backlight control (default:false)");
+ "Enable support for DPCD backlight control "
+ "(-1:auto (default), 0:force disable, 1:force enabled if supported");
module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
MODULE_PARM_DESC(enable_gvt,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc8637c..ac02efce6e22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,7 +66,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
- func(bool, enable_dpcd_backlight); \
+ func(int, enable_dpcd_backlight); \
func(bool, enable_gvt)
#define MEMBER(T, member) T member
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index a0995c00fc84..c89aae804659 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -43,6 +43,9 @@ static void set_aux_backlight_enable(struct intel_dp
*intel_dp, bool enable)
else
reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
+ /* TODO: If the panel also support enabling backlight via BL_ENABLE pin,
+* the backlight will be enabled again in _intel_edp_backlight_on()
+*/
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
reg_val) != 1) {
DRM_DEBUG_KMS("Failed to %s aux backlight\n",
@@ -168,15 +171,66 @@ intel_dp_aux_display_control_capable(struct
intel_connector *connector)
/* Check the eDP Display control capabilities registers to determine if
* the panel can support backlight control over the aux channel
*/
- if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
- (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
- !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
{
+ if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+ (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
return true;
}
return false;
}
+/*
+ * Heuristic function whether we should use AUX for backlight adjustment or
not.
+ *
+ * We should use AUX for backlight brightness adjustment if panel doesn't this
+ * via PWM pin or using AUX is better than using PWM pin.
+ *
+ * The heuristic to determine that using AUX pin is better than using PWM pin
is
+ * that the panel support any of the feature list here.
+ * - Regional backlight brightness adjustment
+ * - Backlight PWM frequency set
+ * - More than 8 bits resolution of brightness level
+ * - Backlight enablement via AUX and not by BL_ENABLE pin
+ *
+ * If all above are not true, assume that using PWM pin is better.
+ */
+static bool
+intel_dp_aux_display_control_heuristic(struct intel_connector *connector)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
+ uint8_t reg_val;
+
[Intel-gfx] ✓ Fi.CI.BAT: success for Enhancement to intel_dp_aux_backlight driver (rev9)
== Series Details == Series: Enhancement to intel_dp_aux_backlight driver (rev9) URL : https://patchwork.freedesktop.org/series/21086/ State : success == Summary == Series 21086v9 Enhancement to intel_dp_aux_backlight driver https://patchwork.freedesktop.org/api/1.0/series/21086/revisions/9/mbox/ Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (fi-skl-6700hq) fdo#101144 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:442s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:434s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:587s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:520s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:491s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:485s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:432s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:416s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:489s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:462s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:568s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:561s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:465s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:499s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:530s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:402s bf9722dc7ed767dd56571e82950e533f69d9318e drm-tip: 2017y-05m-26d-23h-15m-13s UTC integration manifest b57c3ff drm/i915: Set PWM divider to match desired frequency in vbt a4edbd5 drm/i915: Add option to support dynamic backlight via DPCD bc40f50 drm/i915: Add heuristic to determine better way to adjust brightness == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4824/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
