Re: [Intel-gfx] [PATCH 1/2] drm/i915: Initialize bdw workarounds in logical ring mode too
On Tue, 23 Sep 2014, Michel Thierry wrote: > On 9/23/2014 2:21 PM, Jani Nikula wrote: >> On Wed, 17 Sep 2014, Michel Thierry wrote: >>> On 9/17/2014 11:20 AM, Jani Nikula wrote: >> >> FYI, Mika has posted the fix: >> http://mid.gmane.org/1411146326-9884-1-git-send-email-mika.kuopp...@intel.com >> > > Thanks, (Has it been merged? I can't find it in nightly). Not yet, the discussion is in the same thread: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/46415/focus=46443 BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable pixel replicated modes on BDW and HSW.
On Tue, 23 Sep 2014, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Haswell and later silicon has added a new pixel replication register
> to the pipe timings for each transcoder. Now in addition to the
> DPLL_A_MD register for the pixel clock double, we also need to write to
> the TRANS_MULT_n (0x6002c) register to double the pixel data. Writing
> to the DPLL only double the pixel clock.
Any idea of the failure modes that this will fix? I'm wondering if we
already have bugs for this.
BR,
Jani.
>
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/i915_reg.h |3 +++
> drivers/gpu/drm/i915/intel_display.c |6 +-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 15c0eaa..7c078d9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2431,6 +2431,7 @@ enum punit_power_well {
> #define _PIPEASRC0x6001c
> #define _BCLRPAT_A 0x60020
> #define _VSYNCSHIFT_A0x60028
> +#define _MULTIPLY_A 0x6002c
>
> /* Pipe B timing regs */
> #define _HTOTAL_B0x61000
> @@ -2442,6 +2443,7 @@ enum punit_power_well {
> #define _PIPEBSRC0x6101c
> #define _BCLRPAT_B 0x61020
> #define _VSYNCSHIFT_B0x61028
> +#define _MULTIPLY_B 0x6102c
>
> #define TRANSCODER_A_OFFSET 0x6
> #define TRANSCODER_B_OFFSET 0x61000
> @@ -2462,6 +2464,7 @@ enum punit_power_well {
> #define BCLRPAT(trans) _TRANSCODER2(trans, _BCLRPAT_A)
> #define VSYNCSHIFT(trans) _TRANSCODER2(trans, _VSYNCSHIFT_A)
> #define PIPESRC(trans) _TRANSCODER2(trans, _PIPEASRC)
> +#define MULTIPLY(trans) _TRANSCODER2(trans, _MULTIPLY_A)
>
> /* HSW+ eDP PSR registers */
> #define EDP_PSR_BASE(dev) (IS_HASWELL(dev) ? 0x64800 :
> 0x6f800)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c092ff4..e58fcde 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4152,6 +4152,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
>
> intel_set_pipe_timings(intel_crtc);
>
> + I915_WRITE(MULTIPLY(intel_crtc->config.cpu_transcoder),
> + intel_crtc->config.pixel_multiplier - 1);
> +
> if (intel_crtc->config.has_pch_encoder) {
> intel_cpu_transcoder_set_m_n(intel_crtc,
>&intel_crtc->config.fdi_m_n, NULL);
> @@ -7811,7 +7814,8 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->ips_enabled = hsw_crtc_supports_ips(crtc) &&
> (I915_READ(IPS_CTL) & IPS_ENABLE);
>
> - pipe_config->pixel_multiplier = 1;
> + pipe_config->pixel_multiplier =
> + I915_READ(MULTIPLY(pipe_config->cpu_transcoder)) + 1;
>
> return true;
> }
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440
Hi, On 09/23/2014 10:44 PM, Pali Rohár wrote: > On Tuesday 23 September 2014 22:31:31 you wrote: >> Hi, >> >> On 09/23/2014 10:06 PM, Pali Rohár wrote: >>> Hello, >>> >>> after big changes in acpi video/i915 code I cannot change >>> display brightness on my Dell Latitude E6440 with kernel >>> 3.17-rc6. With kernel 3.13 everything worked fine. >>> >>> More information about this problem: >>> >>> For configuring brightness on Dell laptops there are 4 ways: >>> 1) via acpi video driver >>> 2) via dell-laptop driver >>> 3) via i915 drm driver >>> 4) from userspace with special dell SMI call >>> >>> (e.g with program dellLcdBrightness from libsmbios >>> package) >>> >>> Methods 2) and 4) are same, both making special SMI call and >>> Bios handing this request (just 2 is from kernel and 4 from >>> userspace) >>> >>> Method 1) via acpi video driver working, but is not perfect. >>> Driver can be used to change brightness (but only some >>> levels, probably this depends on acpi/DSDT tables), but >>> cannot be used to retrieve current brightness (when >>> BIOS/SMI change brightness acpi driver report old incorrect >>> value). So I prefer dell-laptop driver instead acpi video. >>> >>> Method 3) working even with 3.17-rc6 kernel but because that >>> backlight device exported by i915 is marked as raw, desktop >>> programs prefer to use other devices. >>> >>> Moreover it looks like that methods 1) 2) and 4) just >>> forward request to method 3). So in any cased brightness is >>> changed by i915 drm driver. >>> >>> I'm not sure (correct me if I'm wrong!) but I think that >>> intel i915 drm driver accept changes (file >>> intel_opregion.c) only if acpi function >>> acpi_video_verify_backlight_support() returns true. >>> >>> Function acpi_video_verify_backlight_support() returns true >>> iff: function acpi_video_backlight_support() returns true >>> AND at least one of these functions returns false: >>> acpi_osi_is_win8() >>> acpi_video_use_native_backlight() >>> backlight_device_registered(BACKLIGHT_RAW) >>> >>> On my notebook acpi_osi_is_win8() returns true (as is win8 >>> compliant), backlight_device_registered(BACKLIGHT_RAW) >>> returns true as I'm using intel i915 drm driver with raw >>> backlight device and acpi_video_use_native_backlight() >>> returns true/false depending on >>> "video.use_native_backlight" kernel param. Default is true. >>> >>> So if I want to have working acpi video driver with display >>> brightness support I need to boot kernel with param: >>> "video.use_native_backlight=0". I tested it with kernel >>> 3.17-rc6 and this param really enabled display brightness >>> support via acpi video driver -- which is good. >>> >>> Driver dell-laptop creating backligh device for brightness >>> control only if acpi_video_backlight_support() returns >>> false. There is complicated condition for it and when >>> kernel is booted with "video.use_native_backlight=0" that >>> function returns true. >>> >>> So conclusion is: With current code in kernel 3.17-rc6 it is >>> not possible to control brightness of display with native >>> driver dell-laptop on Dell Latitude E6440 (and probably on >>> others too)!!! >>> >>> And Because laptop is win8 compliant and you create decision >>> to use native driver (instead acpi one) it is not possible >>> to control display brightness without tweeks in kernel >>> cmdline. >>> >>> As I wrote I would rather to use native dell-laptop driver >>> for controlling brightness, but it is not possible. >>> >>> So how to solve this problem? >>> >>> Quick solution would be to set use_native_backlight false >>> for some Dell laptops which means, that acpi video will be >>> used and in this case intel i915 driver will *not* drop >>> backlight change request. >>> >>> Another solution could be to disable check in dell_laptop >>> driver and add use_native_backlight=0 to hooks. But this >>> create two backlight interfaces (which is not good), but >>> only way (for now) how to make dell_laptop working again. >>> >>> Better and maybe only one proper solution would be to teach >>> intel drm i915 driver to not drop backlight change request >>> for Dell laptops (or all??). (This allows to work both acpi >>> video and dell_laptop drivers without any change and with >>> *any* value in param use_native_backlight). I think that >>> problematic code is in function asle_set_backlight() in >>> file intel_opregion.c (but I'm not sure). My idea is that >>> "drop" event function it is caused by this commit >>> 0b9f7d93ca6109048a4eb06332b666b6e29df4fe (but I'm not >>> sure). >>> >>> At least something must be done as I think that I'm not only >>> one who has Dell laptop and brightness configuration is >>> really important... >> >> I don't understand your problem, the kernel is selecting the >> i915 backlight driver, making that the only one available to >> userspace, so the one problem you state with the i915 driver, >> that it is "raw" is not an issue, as userspace will pick it >> when it is the only one.
Re: [Intel-gfx] [PATCH 2/4] drm/i915: PSR: Organize PSR enable function
On Tue, Sep 23, 2014 at 06:05:21PM -0300, Paulo Zanoni wrote:
> 2014-09-16 20:19 GMT-03:00 Rodrigo Vivi :
> > We don't need to setup everything else if it doesn't match all conditions.
>
> Reviewed-by: Paulo Zanoni
Merged the first two patches to dinq.
-Daniel
>
> >
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 271788e..168b3c3 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1912,10 +1912,12 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
> > mutex_lock(&dev_priv->psr.lock);
> > if (dev_priv->psr.enabled) {
> > DRM_DEBUG_KMS("PSR already in use\n");
> > - mutex_unlock(&dev_priv->psr.lock);
> > - return;
> > + goto unlock;
> > }
> >
> > + if (!intel_edp_psr_match_conditions(intel_dp))
> > + goto unlock;
> > +
> > dev_priv->psr.busy_frontbuffer_bits = 0;
> >
> > intel_edp_psr_setup_vsc(intel_dp);
> > @@ -1924,8 +1926,8 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
> > I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
> >EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
> >
> > - if (intel_edp_psr_match_conditions(intel_dp))
> > - dev_priv->psr.enabled = intel_dp;
> > + dev_priv->psr.enabled = intel_dp;
> > +unlock:
> > mutex_unlock(&dev_priv->psr.lock);
> > }
> >
> > --
> > 1.9.3
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Cleanup pre prod workarounds
On Tue, Sep 23, 2014 at 02:48:47PM +0300, Jani Nikula wrote: > On Tue, 23 Sep 2014, Daniel Vetter wrote: > > On Fri, Sep 19, 2014 at 08:49:06PM +0300, Ville Syrjälä wrote: > >> On Fri, Sep 19, 2014 at 08:05:26PM +0300, Mika Kuoppala wrote: > >> > as these have been fixed in production hw and hurt performance > >> > if applied. > >> > > >> > v2: adjust requested ring space (Ville) > >> > > >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83482 > >> > Tested-by: zhoujian > >> > Signed-off-by: Mika Kuoppala > >> > >> Documentation agrees that these can go. > >> Reviewed-by: Ville Syrjälä > > > > Cc: sta...@vger.kernel.org imo. Jani? > > This depends on > > commit 86d7f23842f1bce3ab5e8c8d0c676112bbc4c99b > Author: Arun Siluvery > Date: Tue Aug 26 14:44:50 2014 +0100 > > drm/i915/bdw: Apply workarounds in render ring init function > > which brought the problem to daylight to begin with. That's not in > 3.17-rc6. I'm not sure if that one has additional dependencies, but > perhaps a combined backport without an intermediate broken step is > plausible. > > In any case I don't think this is something we want to rush for 3.17 > now, since a release is imminent, so it'll be 3.18. Adding cc: stable is > up to you, but do note the size is beyond stable rules. Hm right, so a patch for drm-intel-next-fixes (first one even!). I'll leave out the cc: stable since backporting all the register wa stuff is a pile of patches ... -Daniel > > > BR, > Jani. > > > > > -Daniel > > > >> > >> > --- > >> > drivers/gpu/drm/i915/intel_ringbuffer.c | 15 ++- > >> > 1 file changed, 2 insertions(+), 13 deletions(-) > >> > > >> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > >> > b/drivers/gpu/drm/i915/intel_ringbuffer.c > >> > index 681ea86..679a3c7 100644 > >> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > >> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > >> > @@ -707,7 +707,7 @@ static int bdw_init_workarounds(struct > >> > intel_engine_cs *ring) > >> > * update the number of dwords required based on the > >> > * actual number of workarounds applied > >> > */ > >> > -ret = intel_ring_begin(ring, 24); > >> > +ret = intel_ring_begin(ring, 18); > >> > if (ret) > >> > return ret; > >> > > >> > @@ -722,19 +722,8 @@ static int bdw_init_workarounds(struct > >> > intel_engine_cs *ring) > >> > intel_ring_emit_wa(ring, GEN7_ROW_CHICKEN2, > >> > > >> > _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE)); > >> > > >> > -/* > >> > - * This GEN8_CENTROID_PIXEL_OPT_DIS W/A is only needed for > >> > - * pre-production hardware > >> > - */ > >> > intel_ring_emit_wa(ring, HALF_SLICE_CHICKEN3, > >> > - > >> > _MASKED_BIT_ENABLE(GEN8_CENTROID_PIXEL_OPT_DIS > >> > - | > >> > GEN8_SAMPLER_POWER_BYPASS_DIS)); > >> > - > >> > -intel_ring_emit_wa(ring, GEN7_HALF_SLICE_CHICKEN1, > >> > - > >> > _MASKED_BIT_ENABLE(GEN7_SINGLE_SUBSCAN_DISPATCH_ENABLE)); > >> > - > >> > -intel_ring_emit_wa(ring, COMMON_SLICE_CHICKEN2, > >> > - > >> > _MASKED_BIT_ENABLE(GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE)); > >> > + > >> > _MASKED_BIT_ENABLE(GEN8_SAMPLER_POWER_BYPASS_DIS)); > >> > > >> > /* Use Force Non-Coherent whenever executing a 3D context. This > >> > is a > >> > * workaround for for a possible hang in the unlikely event a > >> > TLB > >> > -- > >> > 1.9.1 > >> > >> -- > >> Ville Syrjälä > >> Intel OTC > >> ___ > >> Intel-gfx mailing list > >> Intel-gfx@lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > -- > Jani Nikula, Intel Open Source Technology Center -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/kms_psr_sink_crc: Use options
On Tue, Sep 23, 2014 at 08:51:09PM +, Vivi, Rodrigo wrote:
> I had tried options but didn't liked because I was unable to list subtests...
> so I gave back to env var...
>
> But now I see that I was probably forgetting igt_subtest_init_parse_opts()
Please poke me next time around you want to do something in igt and it
doesn't seem to be easily possible. Writing tests is a nuisance so I want
to make it as simple and pain-free as possible, and that only works when
people raise issues instead of papering over them.
>
> Thanks
>
> Acked/Reviewed-by: Rodrigo Vivi
Thanks for the review, patch merged.
-Daniel
>
>
> From: Daniel Vetter [daniel.vet...@ffwll.ch]
> Sent: Tuesday, September 23, 2014 6:16 AM
> To: Intel Graphics Development
> Cc: Daniel Vetter; Vivi, Rodrigo; Vetter, Daniel
> Subject: [PATCH] tests/kms_psr_sink_crc: Use options
>
> Env variables are a bit more annoying since much harder to discover.
> With options you can just see what they do with --help.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> tests/kms_psr_sink_crc.c | 30 --
> 1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
> index 767727afea6d..266e7e7b5908 100644
> --- a/tests/kms_psr_sink_crc.c
> +++ b/tests/kms_psr_sink_crc.c
> @@ -468,16 +468,32 @@ static void run_test(data_t *data)
> }
> }
>
> -igt_main
> +static int opt_handler(int opt, int opt_index)
> {
> - data_t data = {};
> - enum operations op;
> - char *env_psr;
> + switch (opt) {
> + case 'n':
> + running_with_psr_disabled = true;
> + break;
> + default:
> + igt_assert(0);
> + }
>
> - env_psr = getenv("IGT_PSR_DISABLED");
> + return 0;
> +}
>
> - running_with_psr_disabled = (bool) env_psr;
> +int main(int argc, char *argv[])
> +{
> + const char *help_str =
> + " --no-psr\tRun test without PSR to check the CRC test
> logic.";
> + static struct option long_options[] = {
> + {"no-psr", 0, 0, 'n'},
> + { 0, 0, 0, 0 }
> + };
> + data_t data = {};
> + enum operations op;
>
> + igt_subtest_init_parse_opts(argc, argv, "", long_options,
> + help_str, opt_handler);
> igt_skip_on_simulation();
>
> igt_fixture {
> @@ -522,4 +538,6 @@ igt_main
> drm_intel_bufmgr_destroy(data.bufmgr);
> display_fini(&data);
> }
> +
> + igt_exit();
> }
> --
> 2.1.0
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable pixel replicated modes on BDW and HSW.
On Wed, Sep 24, 2014 at 11:19:17AM +0300, Jani Nikula wrote:
> On Tue, 23 Sep 2014, clinton.a.tay...@intel.com wrote:
> > From: Clint Taylor
> >
> > Haswell and later silicon has added a new pixel replication register
> > to the pipe timings for each transcoder. Now in addition to the
> > DPLL_A_MD register for the pixel clock double, we also need to write to
> > the TRANS_MULT_n (0x6002c) register to double the pixel data. Writing
> > to the DPLL only double the pixel clock.
>
> Any idea of the failure modes that this will fix? I'm wondering if we
> already have bugs for this.
Should only be possible to hit since we've enabled doubleclocked hdmi
modes with
commit 697c4078c765c02b9c4ca2d828ae4d7af62453a6
Author: Clint Taylor
Date: Tue Sep 2 17:03:36 2014 -0700
drm/i915/hdmi: Enable pipe pixel replication for SD interlaced modes
Would be impressive if we'd have a hsw/bdw bug report about this already
;-)
Cheers, Daniel
>
> BR,
> Jani.
>
> >
> > Signed-off-by: Clint Taylor
> > ---
> > drivers/gpu/drm/i915/i915_reg.h |3 +++
> > drivers/gpu/drm/i915/intel_display.c |6 +-
> > 2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 15c0eaa..7c078d9 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2431,6 +2431,7 @@ enum punit_power_well {
> > #define _PIPEASRC 0x6001c
> > #define _BCLRPAT_A 0x60020
> > #define _VSYNCSHIFT_A 0x60028
> > +#define _MULTIPLY_A0x6002c
> >
> > /* Pipe B timing regs */
> > #define _HTOTAL_B 0x61000
> > @@ -2442,6 +2443,7 @@ enum punit_power_well {
> > #define _PIPEBSRC 0x6101c
> > #define _BCLRPAT_B 0x61020
> > #define _VSYNCSHIFT_B 0x61028
> > +#define _MULTIPLY_B0x6102c
> >
> > #define TRANSCODER_A_OFFSET 0x6
> > #define TRANSCODER_B_OFFSET 0x61000
> > @@ -2462,6 +2464,7 @@ enum punit_power_well {
> > #define BCLRPAT(trans) _TRANSCODER2(trans, _BCLRPAT_A)
> > #define VSYNCSHIFT(trans) _TRANSCODER2(trans, _VSYNCSHIFT_A)
> > #define PIPESRC(trans) _TRANSCODER2(trans, _PIPEASRC)
> > +#define MULTIPLY(trans) _TRANSCODER2(trans, _MULTIPLY_A)
> >
> > /* HSW+ eDP PSR registers */
> > #define EDP_PSR_BASE(dev) (IS_HASWELL(dev) ? 0x64800
> > : 0x6f800)
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index c092ff4..e58fcde 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4152,6 +4152,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
> >
> > intel_set_pipe_timings(intel_crtc);
> >
> > + I915_WRITE(MULTIPLY(intel_crtc->config.cpu_transcoder),
> > + intel_crtc->config.pixel_multiplier - 1);
> > +
> > if (intel_crtc->config.has_pch_encoder) {
> > intel_cpu_transcoder_set_m_n(intel_crtc,
> > &intel_crtc->config.fdi_m_n, NULL);
> > @@ -7811,7 +7814,8 @@ static bool haswell_get_pipe_config(struct intel_crtc
> > *crtc,
> > pipe_config->ips_enabled = hsw_crtc_supports_ips(crtc) &&
> > (I915_READ(IPS_CTL) & IPS_ENABLE);
> >
> > - pipe_config->pixel_multiplier = 1;
> > + pipe_config->pixel_multiplier =
> > + I915_READ(MULTIPLY(pipe_config->cpu_transcoder)) + 1;
> >
> > return true;
> > }
> > --
> > 1.7.9.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/9] drm/i915: Dsipll clk to be enabled for DSI1 in case of dual link configuration
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index fa7a6ca..2464089 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -243,6 +243,9 @@ static void vlv_configure_dsi_pll(struct intel_encoder
*encoder)
dsi_mnp.dsi_pll_ctrl |= DSI_PLL_CLK_GATE_DSI0_DSIPLL;
+ if (intel_dsi->dual_link)
+ dsi_mnp.dsi_pll_ctrl |= DSI_PLL_CLK_GATE_DSI1_DSIPLL;
+
DRM_DEBUG_KMS("dsi pll div %08x, ctrl %08x\n",
dsi_mnp.dsi_pll_div, dsi_mnp.dsi_pll_ctrl);
@@ -271,12 +274,11 @@ void vlv_enable_dsi_pll(struct intel_encoder *encoder)
mutex_unlock(&dev_priv->dpio_lock);
- if (wait_for(I915_READ(PIPECONF(PIPE_A)) & PIPECONF_DSI_PLL_LOCKED,
20)) {
- DRM_ERROR("DSI PLL lock failed\n");
- return;
- }
-
- DRM_DEBUG_KMS("DSI PLL locked\n");
+ tmp = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_CONTROL);
+ if (tmp & DSI_PLL_LOCK)
+ DRM_DEBUG_KMS("DSI PLL locked\n");
+ else
+ DRM_DEBUG_KMS("DSI PLL lock failed\n");
}
void vlv_disable_dsi_pll(struct intel_encoder *encoder)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/9] drm/i915: MIPI Timings related changes for dual link Configuration
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_dsi.c | 37 +++--
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 583c7fd..6aac420 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -502,12 +502,23 @@ static void set_dsi_timings(struct drm_encoder *encoder,
unsigned int lane_count = intel_dsi->lane_count;
u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
+ int count = 1;
hactive = mode->hdisplay;
hfp = mode->hsync_start - mode->hdisplay;
hsync = mode->hsync_end - mode->hsync_start;
hbp = mode->htotal - mode->hsync_end;
+ if (intel_dsi->dual_link) {
+ hactive /= 2;
+ if (intel_dsi->dual_link & MIPI_DUAL_LINK_FRONT_BACK)
+ hactive += intel_dsi->pixel_overlap;
+ hfp /= 2;
+ hsync /= 2;
+ hbp /= 2;
+ count = 2;
+ }
+
vfp = mode->vsync_start - mode->vdisplay;
vsync = mode->vsync_end - mode->vsync_start;
vbp = mode->vtotal - mode->vsync_end;
@@ -520,18 +531,24 @@ static void set_dsi_timings(struct drm_encoder *encoder,
intel_dsi->burst_mode_ratio);
hbp = txbyteclkhs(hbp, bpp, lane_count, intel_dsi->burst_mode_ratio);
- I915_WRITE(MIPI_HACTIVE_AREA_COUNT(pipe), hactive);
- I915_WRITE(MIPI_HFP_COUNT(pipe), hfp);
+ do {
+ I915_WRITE(MIPI_HACTIVE_AREA_COUNT(pipe), hactive);
+ I915_WRITE(MIPI_HFP_COUNT(pipe), hfp);
+
+ /* meaningful for video mode non-burst sync pulse mode only,
+* can be zero for non-burst sync events and burst modes */
+ I915_WRITE(MIPI_HSYNC_PADDING_COUNT(pipe), hsync);
+ I915_WRITE(MIPI_HBP_COUNT(pipe), hbp);
- /* meaningful for video mode non-burst sync pulse mode only, can be zero
-* for non-burst sync events and burst modes */
- I915_WRITE(MIPI_HSYNC_PADDING_COUNT(pipe), hsync);
- I915_WRITE(MIPI_HBP_COUNT(pipe), hbp);
+ /* vertical values are in terms of lines */
+ I915_WRITE(MIPI_VFP_COUNT(pipe), vfp);
+ I915_WRITE(MIPI_VSYNC_PADDING_COUNT(pipe), vsync);
+ I915_WRITE(MIPI_VBP_COUNT(pipe), vbp);
- /* vertical values are in terms of lines */
- I915_WRITE(MIPI_VFP_COUNT(pipe), vfp);
- I915_WRITE(MIPI_VSYNC_PADDING_COUNT(pipe), vsync);
- I915_WRITE(MIPI_VBP_COUNT(pipe), vbp);
+ /* For Port C for dual link */
+ if (intel_dsi->dual_link)
+ pipe = PIPE_B;
+ } while (--count > 0);
}
static void intel_dsi_prepare(struct intel_encoder *intel_encoder)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/9] BYT DSI Dual Link Support
Hi, These set of patches build on top of the existing DSI Video mode support to enable dual link MIPI panels with high resolutions. These patches have been tested on a 25x16 panel and works well. Regards Gaurav Gaurav K Singh (9): drm/i915: New functions added for enabling & disabling MIPI Port Ctrl reg drm/i915: MIPI Sequence to be sent to the DSI Controller based on the port no from VBT drm/i915: MIPI Port Ctrl related changes for dual link configuration drm/i915: Pixel Clock and pixel overlap related changes for dual link Configuration drm/i915: SHUTDOWN & Turn ON packets to be sent for both MIPI Ports in case of dual link Configuration drm/i915: Dsipll clk to be enabled for DSI1 in case of dual link configuration drm/i915: MIPI Timings related changes for dual link Configuration drm/i915: MIPI encoder disable related changes for dual link Configuration drm/i915: MIPI Encoder enable related changes for dual link configuration drivers/gpu/drm/i915/i915_reg.h|5 + drivers/gpu/drm/i915/intel_bios.h |3 +- drivers/gpu/drm/i915/intel_dsi.c | 471 ++-- drivers/gpu/drm/i915/intel_dsi.h |8 + drivers/gpu/drm/i915/intel_dsi_cmd.c | 44 +-- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 25 ++ drivers/gpu/drm/i915/intel_dsi_pll.c | 14 +- 7 files changed, 382 insertions(+), 188 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915: MIPI encoder disable related changes for dual link Configuration
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_dsi.c | 74 --
1 file changed, 48 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 6aac420..477b79d 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -303,6 +303,7 @@ static void intel_dsi_disable(struct intel_encoder *encoder)
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
int pipe = intel_crtc->pipe;
u32 temp;
+ int count = 1;
DRM_DEBUG_KMS("\n");
@@ -313,22 +314,30 @@ static void intel_dsi_disable(struct intel_encoder
*encoder)
msleep(2);
}
- /* Panel commands can be sent when clock is in LP11 */
- I915_WRITE(MIPI_DEVICE_READY(pipe), 0x0);
+ if (intel_dsi->dual_link)
+ count = 2;
+ do {
+ /* Panel commands can be sent when clock is in LP11 */
+ I915_WRITE(MIPI_DEVICE_READY(pipe), 0x0);
- temp = I915_READ(MIPI_CTRL(pipe));
- temp &= ~ESCAPE_CLOCK_DIVIDER_MASK;
- I915_WRITE(MIPI_CTRL(pipe), temp |
- intel_dsi->escape_clk_div <<
- ESCAPE_CLOCK_DIVIDER_SHIFT);
+ temp = I915_READ(MIPI_CTRL(pipe));
+ temp &= ~ESCAPE_CLOCK_DIVIDER_MASK;
+ I915_WRITE(MIPI_CTRL(pipe), temp |
+ intel_dsi->escape_clk_div <<
+ ESCAPE_CLOCK_DIVIDER_SHIFT);
- I915_WRITE(MIPI_EOT_DISABLE(pipe), CLOCKSTOP);
+ I915_WRITE(MIPI_EOT_DISABLE(pipe), CLOCKSTOP);
- temp = I915_READ(MIPI_DSI_FUNC_PRG(pipe));
- temp &= ~VID_MODE_FORMAT_MASK;
- I915_WRITE(MIPI_DSI_FUNC_PRG(pipe), temp);
+ temp = I915_READ(MIPI_DSI_FUNC_PRG(pipe));
+ temp &= ~VID_MODE_FORMAT_MASK;
+ I915_WRITE(MIPI_DSI_FUNC_PRG(pipe), temp);
- I915_WRITE(MIPI_DEVICE_READY(pipe), 0x1);
+ I915_WRITE(MIPI_DEVICE_READY(pipe), 0x1);
+
+ /* For Port C for dual link */
+ if (intel_dsi->dual_link)
+ pipe = PIPE_B;
+ } while (--count > 0);
/* if disable packets are sent before sending shutdown packet then in
* some next enable sequence send turn on packet error is observed */
@@ -341,31 +350,44 @@ static void intel_dsi_disable(struct intel_encoder
*encoder)
static void intel_dsi_clear_device_ready(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
int pipe = intel_crtc->pipe;
u32 val;
+ int count = 1;
DRM_DEBUG_KMS("\n");
- I915_WRITE(MIPI_DEVICE_READY(pipe), DEVICE_READY | ULPS_STATE_ENTER);
- usleep_range(2000, 2500);
+ if (intel_dsi->dual_link)
+ count = 2;
- I915_WRITE(MIPI_DEVICE_READY(pipe), DEVICE_READY | ULPS_STATE_EXIT);
- usleep_range(2000, 2500);
+ do {
+ I915_WRITE(MIPI_DEVICE_READY(pipe), DEVICE_READY |
+ ULPS_STATE_ENTER);
+ usleep_range(2000, 2500);
- I915_WRITE(MIPI_DEVICE_READY(pipe), DEVICE_READY | ULPS_STATE_ENTER);
- usleep_range(2000, 2500);
+ I915_WRITE(MIPI_DEVICE_READY(pipe), DEVICE_READY |
+ ULPS_STATE_EXIT);
+ usleep_range(2000, 2500);
- if (wait_for(((I915_READ(MIPI_PORT_CTRL(pipe)) & AFE_LATCHOUT)
- == 0x0), 30))
- DRM_ERROR("DSI LP not going Low\n");
+ I915_WRITE(MIPI_DEVICE_READY(pipe), DEVICE_READY |
+ ULPS_STATE_ENTER);
+ usleep_range(2000, 2500);
- val = I915_READ(MIPI_PORT_CTRL(pipe));
- I915_WRITE(MIPI_PORT_CTRL(pipe), val & ~LP_OUTPUT_HOLD);
- usleep_range(1000, 1500);
+ if (wait_for(((I915_READ(MIPI_PORT_CTRL(0)) & AFE_LATCHOUT)
+ == 0x0), 30))
+ DRM_ERROR("DSI LP not going Low\n");
+
+ val = I915_READ(MIPI_PORT_CTRL(0));
+ I915_WRITE(MIPI_PORT_CTRL(0), val & ~LP_OUTPUT_HOLD);
+ usleep_range(1000, 1500);
- I915_WRITE(MIPI_DEVICE_READY(pipe), 0x00);
- usleep_range(2000, 2500);
+ I915_WRITE(MIPI_DEVICE_READY(pipe), 0x00);
+ usleep_range(2000, 2500);
+ /* For Port C for dual link */
+ if (intel_dsi->dual_link)
+ pipe = PIPE_B;
+ } while (--count > 0);
vlv_disable_dsi_pll(encoder);
}
--
1.7.9.5
[Intel-gfx] [PATCH 4/9] drm/i915: Pixel Clock and pixel overlap related changes for dual link Configuration
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/i915_reg.h|4
drivers/gpu/drm/i915/intel_bios.h |3 ++-
drivers/gpu/drm/i915/intel_dsi.c |8
drivers/gpu/drm/i915/intel_dsi.h |6 ++
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 21 +
5 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 922d807..3ed5774 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5662,6 +5662,10 @@ enum punit_power_well {
#define GEN8_PMINTR_REDIRECT_TO_NON_DISP (1<<31)
#define VLV_PWRDWNUPCTL0xA294
+#define VLV_CHICKEN_3 0x7040C
+#define PIXEL_OVERLAP_CNT_MASK(3 << 30)
+#define PIXEL_OVERLAP_CNT_SHIFT 30
+
#define GEN6_PMISR 0x44020
#define GEN6_PMIMR 0x44024 /* rps_lock */
#define GEN6_PMIIR 0x44028
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 7603765..39dfb65 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -798,7 +798,8 @@ struct mipi_config {
#define DUAL_LINK_PIXEL_ALT2
u16 dual_link:2;
u16 lane_cnt:2;
- u16 rsvd3:12;
+ u16 pixel_overlap:3;
+ u16 rsvd3:9;
u16 rsvd4;
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3b1890e..583c7fd 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -116,6 +116,14 @@ static void intel_dsi_port_enable(struct intel_encoder
*encoder)
<< DUAL_LINK_MODE_SHIFT;
port_control |= pipe ? LANE_CONFIGURATION_DUAL_LINK_B :
LANE_CONFIGURATION_DUAL_LINK_A;
+
+ if (intel_dsi->dual_link & MIPI_DUAL_LINK_FRONT_BACK) {
+ temp = I915_READ(VLV_CHICKEN_3);
+ temp &= ~PIXEL_OVERLAP_CNT_MASK |
+ intel_dsi->pixel_overlap <<
+ PIXEL_OVERLAP_CNT_SHIFT;
+ I915_WRITE(VLV_CHICKEN_3, temp);
+ }
/*For Port A */
temp = I915_READ(MIPI_PORT_CTRL(0));
temp = temp | port_control;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 950ab41..7fac460 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -28,6 +28,11 @@
#include
#include "intel_drv.h"
+/* Dual Link support */
+#define MIPI_DUAL_LINK_NONE0
+#define MIPI_DUAL_LINK_FRONT_BACK 1
+#define MIPI_DUAL_LINK_PIXEL_ALT 2
+
struct intel_dsi_device {
unsigned int panel_id;
const char *name;
@@ -102,6 +107,7 @@ struct intel_dsi {
u8 escape_clk_div;
u8 dual_link;
+ u8 pixel_overlap;
u32 port_bits;
u32 bw_timer;
u32 dphy_reg;
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index d424ebc..8bc911b 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -284,6 +284,7 @@ static bool generic_init(struct intel_dsi_device *dsi)
intel_dsi->pixel_format = mipi_config->videomode_color_format << 7;
intel_dsi->port = 0;
intel_dsi->dual_link = mipi_config->dual_link;
+ intel_dsi->pixel_overlap = mipi_config->pixel_overlap;
if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB666)
bits_per_pixel = 18;
@@ -303,6 +304,20 @@ static bool generic_init(struct intel_dsi_device *dsi)
pclk = mode->clock;
+ /* In dual link mode each port needs half of pixel clock */
+ if (intel_dsi->dual_link) {
+ pclk = pclk / 2;
+
+ /* we can enable pixel_overlap if needed by panel. In this
+* case we need to increase the pixelclock for extra pixels
+*/
+ if (intel_dsi->dual_link & MIPI_DUAL_LINK_FRONT_BACK) {
+ pclk += DIV_ROUND_UP(mode->vtotal *
+ intel_dsi->pixel_overlap *
+ 60, 1000);
+ }
+ }
+
/* Burst Mode Ratio
* Target ddr frequency from VBT / non burst ddr freq
* multiply by 100 to preserve remainder
@@ -497,6 +512,12 @@ static bool generic_init(struct intel_dsi_device *dsi)
DRM_DEBUG_KMS("Clockstop %s\n", intel_dsi->clock_stop ?
"disabled" : "enabled");
DRM_DEBUG_KMS("Mode %s\n", intel_dsi->operation_mode ? "command" :
"video");
+ if (int
[Intel-gfx] [PATCH 2/9] drm/i915: MIPI Sequence to be sent to the DSI Controller based on the port no from VBT
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_dsi.h |1 +
drivers/gpu/drm/i915/intel_dsi_cmd.c |9 +++--
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |3 +++
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 657eb5c..587e71f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -115,6 +115,7 @@ struct intel_dsi {
u16 clk_lp_to_hs_count;
u16 clk_hs_to_lp_count;
+ u16 port;
u16 init_count;
u32 pclk;
u16 burst_mode_ratio;
diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.c
b/drivers/gpu/drm/i915/intel_dsi_cmd.c
index f4767fd..eb698b1 100644
--- a/drivers/gpu/drm/i915/intel_dsi_cmd.c
+++ b/drivers/gpu/drm/i915/intel_dsi_cmd.c
@@ -130,8 +130,7 @@ static int dsi_vc_send_short(struct intel_dsi *intel_dsi,
int channel,
struct drm_encoder *encoder = &intel_dsi->base.base;
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
- enum pipe pipe = intel_crtc->pipe;
+ enum pipe pipe = intel_dsi->port;
u32 ctrl_reg;
u32 ctrl;
u32 mask;
@@ -172,8 +171,7 @@ static int dsi_vc_send_long(struct intel_dsi *intel_dsi,
int channel,
struct drm_encoder *encoder = &intel_dsi->base.base;
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
- enum pipe pipe = intel_crtc->pipe;
+ enum pipe pipe = intel_dsi->port;
u32 data_reg;
int i, j, n;
u32 mask;
@@ -291,8 +289,7 @@ static int dsi_read_data_return(struct intel_dsi *intel_dsi,
struct drm_encoder *encoder = &intel_dsi->base.base;
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
- enum pipe pipe = intel_crtc->pipe;
+ enum pipe pipe = intel_dsi->port;
int i, len = 0;
u32 data_reg, val;
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f6bdd44..051bfff 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -106,6 +106,8 @@ static u8 *mipi_exec_send_packet(struct intel_dsi
*intel_dsi, u8 *data)
/* LP or HS mode */
intel_dsi->hs = mode;
+ /*MIPI Port A or MIPI Port C*/
+ intel_dsi->port = port;
/* get packet type and increment the pointer */
type = *data++;
@@ -280,6 +282,7 @@ static bool generic_init(struct intel_dsi_device *dsi)
intel_dsi->clock_stop = mipi_config->enable_clk_stop ? 1 : 0;
intel_dsi->lane_count = mipi_config->lane_cnt + 1;
intel_dsi->pixel_format = mipi_config->videomode_color_format << 7;
+ intel_dsi->port = 0;
if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB666)
bits_per_pixel = 18;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] drm/i915: SHUTDOWN & Turn ON packets to be sent for both MIPI Ports in case of dual link Configuration
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_dsi_cmd.c | 35 ++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.c
b/drivers/gpu/drm/i915/intel_dsi_cmd.c
index eb698b1..a70656e 100644
--- a/drivers/gpu/drm/i915/intel_dsi_cmd.c
+++ b/drivers/gpu/drm/i915/intel_dsi_cmd.c
@@ -394,6 +394,7 @@ int dpi_send_cmd(struct intel_dsi *intel_dsi, u32 cmd, bool
hs)
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
enum pipe pipe = intel_crtc->pipe;
u32 mask;
+ int count = 1;
/* XXX: pipe, hs */
if (hs)
@@ -401,18 +402,28 @@ int dpi_send_cmd(struct intel_dsi *intel_dsi, u32 cmd,
bool hs)
else
cmd |= DPI_LP_MODE;
- /* clear bit */
- I915_WRITE(MIPI_INTR_STAT(pipe), SPL_PKT_SENT_INTERRUPT);
-
- /* XXX: old code skips write if control unchanged */
- if (cmd == I915_READ(MIPI_DPI_CONTROL(pipe)))
- DRM_ERROR("Same special packet %02x twice in a row.\n", cmd);
-
- I915_WRITE(MIPI_DPI_CONTROL(pipe), cmd);
-
- mask = SPL_PKT_SENT_INTERRUPT;
- if (wait_for((I915_READ(MIPI_INTR_STAT(pipe)) & mask) == mask, 100))
- DRM_ERROR("Video mode command 0x%08x send failed.\n", cmd);
+ if (intel_dsi->dual_link)
+ count = 2;
+
+ do {
+ /* clear bit */
+ I915_WRITE(MIPI_INTR_STAT(pipe), SPL_PKT_SENT_INTERRUPT);
+
+ /* XXX: old code skips write if control unchanged */
+ if (cmd == I915_READ(MIPI_DPI_CONTROL(pipe)))
+ DRM_ERROR("Same special packet %02x twice in a row.\n",
+ cmd);
+ I915_WRITE(MIPI_DPI_CONTROL(pipe), cmd);
+
+ mask = SPL_PKT_SENT_INTERRUPT;
+ if (wait_for((I915_READ(MIPI_INTR_STAT(pipe)) & mask) ==
+ mask, 100))
+ DRM_ERROR("Video mode command 0x%08x send failed.\n",
+ cmd);
+ /* For Port C for dual link */
+ if (intel_dsi->dual_link)
+ pipe = PIPE_B;
+ } while (--count > 0);
return 0;
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915: MIPI Encoder enable related changes for dual link configuration
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_dsi.c | 276 ++
1 file changed, 161 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 477b79d..43212d3 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -175,8 +175,10 @@ static void intel_dsi_device_ready(struct intel_encoder
*encoder)
{
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
int pipe = intel_crtc->pipe;
u32 val;
+ int count = 1;
DRM_DEBUG_KMS("\n");
@@ -189,18 +191,26 @@ static void intel_dsi_device_ready(struct intel_encoder
*encoder)
/* bandgap reset is needed after everytime we do power gate */
band_gap_reset(dev_priv);
- I915_WRITE(MIPI_DEVICE_READY(pipe), ULPS_STATE_ENTER);
- usleep_range(2500, 3000);
+ if (intel_dsi->dual_link)
+ count = 2;
+ do {
+
+ I915_WRITE(MIPI_DEVICE_READY(pipe), ULPS_STATE_ENTER);
+ usleep_range(2500, 3000);
- val = I915_READ(MIPI_PORT_CTRL(pipe));
- I915_WRITE(MIPI_PORT_CTRL(pipe), val | LP_OUTPUT_HOLD);
- usleep_range(1000, 1500);
+ val = I915_READ(MIPI_PORT_CTRL(pipe));
+ I915_WRITE(MIPI_PORT_CTRL(pipe), val | LP_OUTPUT_HOLD);
+ usleep_range(1000, 1500);
- I915_WRITE(MIPI_DEVICE_READY(pipe), ULPS_STATE_EXIT);
- usleep_range(2500, 3000);
+ I915_WRITE(MIPI_DEVICE_READY(pipe), ULPS_STATE_EXIT);
+ usleep_range(2500, 3000);
- I915_WRITE(MIPI_DEVICE_READY(pipe), DEVICE_READY);
- usleep_range(2500, 3000);
+ I915_WRITE(MIPI_DEVICE_READY(pipe), DEVICE_READY);
+ usleep_range(2500, 3000);
+ /* For Port C for dual link */
+ if (intel_dsi->dual_link)
+ pipe = PIPE_B;
+ } while (--count > 0);
}
static void intel_dsi_enable(struct intel_encoder *encoder)
@@ -585,131 +595,167 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
int pipe = intel_crtc->pipe;
unsigned int bpp = intel_crtc->config.pipe_bpp;
u32 val, tmp;
+ int count = 1;
+ u16 mode_hactive;
DRM_DEBUG_KMS("pipe %c\n", pipe_name(pipe));
- /* escape clock divider, 20MHz, shared for A and C. device ready must be
-* off when doing this! txclkesc? */
- tmp = I915_READ(MIPI_CTRL(0));
- tmp &= ~ESCAPE_CLOCK_DIVIDER_MASK;
- I915_WRITE(MIPI_CTRL(0), tmp | ESCAPE_CLOCK_DIVIDER_1);
-
- /* read request priority is per pipe */
- tmp = I915_READ(MIPI_CTRL(pipe));
- tmp &= ~READ_REQUEST_PRIORITY_MASK;
- I915_WRITE(MIPI_CTRL(pipe), tmp | READ_REQUEST_PRIORITY_HIGH);
-
- /* XXX: why here, why like this? handling in irq handler?! */
- I915_WRITE(MIPI_INTR_STAT(pipe), 0x);
- I915_WRITE(MIPI_INTR_EN(pipe), 0x);
-
- I915_WRITE(MIPI_DPHY_PARAM(pipe), intel_dsi->dphy_reg);
+ mode_hactive = adjusted_mode->hdisplay;
+ if (intel_dsi->dual_link) {
+ count = 2;
+ mode_hactive /= 2;
+ if (intel_dsi->dual_link & MIPI_DUAL_LINK_FRONT_BACK)
+ mode_hactive += intel_dsi->pixel_overlap;
+ }
- I915_WRITE(MIPI_DPI_RESOLUTION(pipe),
- adjusted_mode->vdisplay << VERTICAL_ADDRESS_SHIFT |
- adjusted_mode->hdisplay << HORIZONTAL_ADDRESS_SHIFT);
+ do {
+ /* escape clock divider, 20MHz, shared for A and C.
+* device ready must be off when doing this! txclkesc?
+*/
+ tmp = I915_READ(MIPI_CTRL(0));
+ tmp &= ~ESCAPE_CLOCK_DIVIDER_MASK;
+ I915_WRITE(MIPI_CTRL(0), tmp | ESCAPE_CLOCK_DIVIDER_1);
+
+ /* read request priority is per pipe */
+ tmp = I915_READ(MIPI_CTRL(pipe));
+ tmp &= ~READ_REQUEST_PRIORITY_MASK;
+ I915_WRITE(MIPI_CTRL(pipe), tmp | READ_REQUEST_PRIORITY_HIGH);
+
+ /* XXX: why here, why like this? handling in irq handler?! */
+ I915_WRITE(MIPI_INTR_STAT(pipe), 0x);
+ I915_WRITE(MIPI_INTR_EN(pipe), 0x);
+
+ I915_WRITE(MIPI_DPHY_PARAM(pipe), intel_dsi->dphy_reg);
+
+ I915_WRITE(MIPI_DPI_RESOLUTION(pipe),
+ adjusted_mode->vdisplay << VERTICAL_ADDRESS_SHIFT |
+ mode_hactive << HORIZONTAL_ADDRESS_SHIFT);
+ /* For Port C for dual link */
+ if (intel_dsi->dual_link)
+ pipe = PIPE_B;
+ } while (--count > 0);
set_d
[Intel-gfx] [PATCH 1/9] drm/i915: New functions added for enabling & disabling MIPI Port Ctrl reg
This patch is in preparation for the dual link port enable and disable related
changes.
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_dsi.c | 43 --
1 file changed, 32 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 5bd9e09..e456ca9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -102,6 +102,36 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
return true;
}
+static void intel_dsi_port_enable(struct intel_encoder *encoder)
+{
+ struct drm_device *dev = encoder->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ enum pipe pipe = intel_crtc->pipe;
+ u32 temp;
+
+ /* assert ip_tg_enable signal */
+ temp = I915_READ(MIPI_PORT_CTRL(pipe)) & ~LANE_CONFIGURATION_MASK;
+ temp = temp | intel_dsi->port_bits;
+ I915_WRITE(MIPI_PORT_CTRL(pipe), temp | DPI_ENABLE);
+ POSTING_READ(MIPI_PORT_CTRL(pipe));
+}
+
+static void intel_dsi_port_disable(struct intel_encoder *encoder)
+{
+ struct drm_device *dev = encoder->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ u32 temp;
+
+ /* de-assert ip_tg_enable signal */
+ temp = I915_READ(MIPI_PORT_CTRL(pipe));
+ I915_WRITE(MIPI_PORT_CTRL(pipe), temp & ~DPI_ENABLE);
+ POSTING_READ(MIPI_PORT_CTRL(pipe));
+}
+
static void intel_dsi_device_ready(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
@@ -141,7 +171,6 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
int pipe = intel_crtc->pipe;
- u32 temp;
DRM_DEBUG_KMS("\n");
@@ -157,11 +186,7 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
wait_for_dsi_fifo_empty(intel_dsi);
- /* assert ip_tg_enable signal */
- temp = I915_READ(MIPI_PORT_CTRL(pipe)) &
~LANE_CONFIGURATION_MASK;
- temp = temp | intel_dsi->port_bits;
- I915_WRITE(MIPI_PORT_CTRL(pipe), temp | DPI_ENABLE);
- POSTING_READ(MIPI_PORT_CTRL(pipe));
+ intel_dsi_port_enable(encoder);
}
}
@@ -245,11 +270,7 @@ static void intel_dsi_disable(struct intel_encoder
*encoder)
if (is_vid_mode(intel_dsi)) {
wait_for_dsi_fifo_empty(intel_dsi);
- /* de-assert ip_tg_enable signal */
- temp = I915_READ(MIPI_PORT_CTRL(pipe));
- I915_WRITE(MIPI_PORT_CTRL(pipe), temp & ~DPI_ENABLE);
- POSTING_READ(MIPI_PORT_CTRL(pipe));
-
+ intel_dsi_port_disable(encoder);
msleep(2);
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9] drm/i915: MIPI Port Ctrl related changes for dual link configuration
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/i915_reg.h|1 +
drivers/gpu/drm/i915/intel_dsi.c | 53 ++--
drivers/gpu/drm/i915/intel_dsi.h |1 +
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |1 +
4 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ad8179b..922d807 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6215,6 +6215,7 @@ enum punit_power_well {
#define DPI_ENABLE(1 << 31) /* A + B */
#define MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT 27
#define MIPIA_MIPI4DPHY_DELAY_COUNT_MASK (0xf << 27)
+#define DUAL_LINK_MODE_SHIFT 26
#define DUAL_LINK_MODE_MASK (1 << 26)
#define DUAL_LINK_MODE_FRONT_BACK (0 << 26)
#define DUAL_LINK_MODE_PIXEL_ALTERNATIVE (1 << 26)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index e456ca9..3b1890e 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -109,13 +109,31 @@ static void intel_dsi_port_enable(struct intel_encoder
*encoder)
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
enum pipe pipe = intel_crtc->pipe;
- u32 temp;
-
- /* assert ip_tg_enable signal */
- temp = I915_READ(MIPI_PORT_CTRL(pipe)) & ~LANE_CONFIGURATION_MASK;
- temp = temp | intel_dsi->port_bits;
- I915_WRITE(MIPI_PORT_CTRL(pipe), temp | DPI_ENABLE);
- POSTING_READ(MIPI_PORT_CTRL(pipe));
+ u32 temp, port_control = 0;
+
+ if (intel_dsi->dual_link) {
+ port_control = (intel_dsi->dual_link - 1)
+ << DUAL_LINK_MODE_SHIFT;
+ port_control |= pipe ? LANE_CONFIGURATION_DUAL_LINK_B :
+ LANE_CONFIGURATION_DUAL_LINK_A;
+ /*For Port A */
+ temp = I915_READ(MIPI_PORT_CTRL(0));
+ temp = temp | port_control;
+ I915_WRITE(MIPI_PORT_CTRL(0), temp | DPI_ENABLE);
+ POSTING_READ(MIPI_PORT_CTRL(0));
+
+ /* For Port C */
+ temp = I915_READ(MIPI_PORT_CTRL(1));
+ I915_WRITE(MIPI_PORT_CTRL(1), temp | DPI_ENABLE);
+ POSTING_READ(MIPI_PORT_CTRL(1));
+ } else {
+ /* assert ip_tg_enable signal */
+ temp = I915_READ(MIPI_PORT_CTRL(pipe)) &
+ ~LANE_CONFIGURATION_MASK;
+ temp = temp | intel_dsi->port_bits;
+ I915_WRITE(MIPI_PORT_CTRL(pipe), temp | DPI_ENABLE);
+ POSTING_READ(MIPI_PORT_CTRL(pipe));
+ }
}
static void intel_dsi_port_disable(struct intel_encoder *encoder)
@@ -123,13 +141,26 @@ static void intel_dsi_port_disable(struct intel_encoder
*encoder)
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
enum pipe pipe = intel_crtc->pipe;
u32 temp;
- /* de-assert ip_tg_enable signal */
- temp = I915_READ(MIPI_PORT_CTRL(pipe));
- I915_WRITE(MIPI_PORT_CTRL(pipe), temp & ~DPI_ENABLE);
- POSTING_READ(MIPI_PORT_CTRL(pipe));
+ if (intel_dsi->dual_link) {
+ /*For Port A */
+ temp = I915_READ(MIPI_PORT_CTRL(0));
+ I915_WRITE(MIPI_PORT_CTRL(0), temp & ~DPI_ENABLE);
+ POSTING_READ(MIPI_PORT_CTRL(0));
+
+ /* For Port C */
+ temp = I915_READ(MIPI_PORT_CTRL(1));
+ I915_WRITE(MIPI_PORT_CTRL(1), temp & ~DPI_ENABLE);
+ POSTING_READ(MIPI_PORT_CTRL(1));
+ } else {
+ /* de-assert ip_tg_enable signal */
+ temp = I915_READ(MIPI_PORT_CTRL(pipe));
+ I915_WRITE(MIPI_PORT_CTRL(pipe), temp & ~DPI_ENABLE);
+ POSTING_READ(MIPI_PORT_CTRL(pipe));
+ }
}
static void intel_dsi_device_ready(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 587e71f..950ab41 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -101,6 +101,7 @@ struct intel_dsi {
u8 clock_stop;
u8 escape_clk_div;
+ u8 dual_link;
u32 port_bits;
u32 bw_timer;
u32 dphy_reg;
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 051bfff..d424ebc 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_d
Re: [Intel-gfx] [PATCH] drm/i915: Enable pixel replicated modes on BDW and HSW.
On Tue, Sep 23, 2014 at 11:06:56AM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Haswell and later silicon has added a new pixel replication register
> to the pipe timings for each transcoder. Now in addition to the
> DPLL_A_MD register for the pixel clock double, we also need to write to
> the TRANS_MULT_n (0x6002c) register to double the pixel data. Writing
> to the DPLL only double the pixel clock.
>
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/i915_reg.h |3 +++
> drivers/gpu/drm/i915/intel_display.c |6 +-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 15c0eaa..7c078d9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2431,6 +2431,7 @@ enum punit_power_well {
> #define _PIPEASRC0x6001c
> #define _BCLRPAT_A 0x60020
> #define _VSYNCSHIFT_A0x60028
> +#define _MULTIPLY_A 0x6002c
>
> /* Pipe B timing regs */
> #define _HTOTAL_B0x61000
> @@ -2442,6 +2443,7 @@ enum punit_power_well {
> #define _PIPEBSRC0x6101c
> #define _BCLRPAT_B 0x61020
> #define _VSYNCSHIFT_B0x61028
> +#define _MULTIPLY_B 0x6102c
>
> #define TRANSCODER_A_OFFSET 0x6
> #define TRANSCODER_B_OFFSET 0x61000
> @@ -2462,6 +2464,7 @@ enum punit_power_well {
> #define BCLRPAT(trans) _TRANSCODER2(trans, _BCLRPAT_A)
> #define VSYNCSHIFT(trans) _TRANSCODER2(trans, _VSYNCSHIFT_A)
> #define PIPESRC(trans) _TRANSCODER2(trans, _PIPEASRC)
> +#define MULTIPLY(trans) _TRANSCODER2(trans, _MULTIPLY_A)
MULTIPLY is a bit generic and doesn't even match Bspec lingo. I'd just go
with PIPE_MULTI instead to match Bspec and give it a nice PIPE_ prefix.
>
> /* HSW+ eDP PSR registers */
> #define EDP_PSR_BASE(dev) (IS_HASWELL(dev) ? 0x64800 :
> 0x6f800)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c092ff4..e58fcde 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4152,6 +4152,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
>
> intel_set_pipe_timings(intel_crtc);
>
> + I915_WRITE(MULTIPLY(intel_crtc->config.cpu_transcoder),
This register is per-pipe, so needs to be indexed with intel_crtc->pipe.
Same below.
Otherwise this loooks good.
-Daniel
> + intel_crtc->config.pixel_multiplier - 1);
> +
> if (intel_crtc->config.has_pch_encoder) {
> intel_cpu_transcoder_set_m_n(intel_crtc,
>&intel_crtc->config.fdi_m_n, NULL);
> @@ -7811,7 +7814,8 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->ips_enabled = hsw_crtc_supports_ips(crtc) &&
> (I915_READ(IPS_CTL) & IPS_ENABLE);
>
> - pipe_config->pixel_multiplier = 1;
> + pipe_config->pixel_multiplier =
> + I915_READ(MULTIPLY(pipe_config->cpu_transcoder)) + 1;
>
> return true;
> }
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] BYT DSI Dual Link Support
On Wed, Sep 24, 2014 at 02:16:49PM +0530, Gaurav K Singh wrote: > Hi, > These set of patches build on top of the existing DSI Video mode support to > enable dual link MIPI panels with high resolutions. These patches have been > tested on a 25x16 panel and works well. Except for the first patch (which only has a trivial "this is prep work" sentence) all your patches lack a commit message. If you do mechanical and trivial changes all over the driver split up into a bunch of patches this is ok, but for everything else it makes reviewing your code really hard since the reviewer has no idea _why_ some change is done. So please give your patches some good commit messages, focusing specifically on why you change things like you do (and also e.g. why other approaches would be worse). Also, the subject/summary should be at most 50 chars (with a hard limit at 80 characters), lots of them are longer. So probably some of the details of what exactly a patch changes should also be moved into the commit message. See "2) Describe your changes" in Documentation/SubmittingPatches for a some good examples and explanations. Also my review BKM training has some material about what a good commit message should entail. Thanks, Daniel > > Regards > Gaurav > > Gaurav K Singh (9): > drm/i915: New functions added for enabling & disabling MIPI Port Ctrl > reg > drm/i915: MIPI Sequence to be sent to the DSI Controller based on the > port no from VBT > drm/i915: MIPI Port Ctrl related changes for dual link configuration > drm/i915: Pixel Clock and pixel overlap related changes for dual link > Configuration > drm/i915: SHUTDOWN & Turn ON packets to be sent for both MIPI Ports > in case of dual link Configuration > drm/i915: Dsipll clk to be enabled for DSI1 in case of dual link > configuration > drm/i915: MIPI Timings related changes for dual link Configuration > drm/i915: MIPI encoder disable related changes for dual link > Configuration > drm/i915: MIPI Encoder enable related changes for dual link > configuration > > drivers/gpu/drm/i915/i915_reg.h|5 + > drivers/gpu/drm/i915/intel_bios.h |3 +- > drivers/gpu/drm/i915/intel_dsi.c | 471 > ++-- > drivers/gpu/drm/i915/intel_dsi.h |8 + > drivers/gpu/drm/i915/intel_dsi_cmd.c | 44 +-- > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 25 ++ > drivers/gpu/drm/i915/intel_dsi_pll.c | 14 +- > 7 files changed, 382 insertions(+), 188 deletions(-) > > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/9] drm/i915: Pixel Clock and pixel overlap related changes for dual link Configuration
On Wed, 24 Sep 2014, Gaurav K Singh wrote:
> Signed-off-by: Gaurav K Singh
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/i915/i915_reg.h|4
> drivers/gpu/drm/i915/intel_bios.h |3 ++-
> drivers/gpu/drm/i915/intel_dsi.c |8
> drivers/gpu/drm/i915/intel_dsi.h |6 ++
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 21 +
> 5 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 922d807..3ed5774 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5662,6 +5662,10 @@ enum punit_power_well {
> #define GEN8_PMINTR_REDIRECT_TO_NON_DISP (1<<31)
> #define VLV_PWRDWNUPCTL 0xA294
>
> +#define VLV_CHICKEN_30x7040C
> +#define PIXEL_OVERLAP_CNT_MASK (3 << 30)
> +#define PIXEL_OVERLAP_CNT_SHIFT 30
> +
> #define GEN6_PMISR 0x44020
> #define GEN6_PMIMR 0x44024 /* rps_lock */
> #define GEN6_PMIIR 0x44028
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index 7603765..39dfb65 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -798,7 +798,8 @@ struct mipi_config {
> #define DUAL_LINK_PIXEL_ALT 2
> u16 dual_link:2;
> u16 lane_cnt:2;
> - u16 rsvd3:12;
> + u16 pixel_overlap:3;
> + u16 rsvd3:9;
>
> u16 rsvd4;
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 3b1890e..583c7fd 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -116,6 +116,14 @@ static void intel_dsi_port_enable(struct intel_encoder
> *encoder)
> << DUAL_LINK_MODE_SHIFT;
> port_control |= pipe ? LANE_CONFIGURATION_DUAL_LINK_B :
> LANE_CONFIGURATION_DUAL_LINK_A;
> +
> + if (intel_dsi->dual_link & MIPI_DUAL_LINK_FRONT_BACK) {
It's really confusing to treat ->dual_link as a bit mask when it's not.
> + temp = I915_READ(VLV_CHICKEN_3);
> + temp &= ~PIXEL_OVERLAP_CNT_MASK |
> + intel_dsi->pixel_overlap <<
> + PIXEL_OVERLAP_CNT_SHIFT;
> + I915_WRITE(VLV_CHICKEN_3, temp);
> + }
> /*For Port A */
> temp = I915_READ(MIPI_PORT_CTRL(0));
> temp = temp | port_control;
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 950ab41..7fac460 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -28,6 +28,11 @@
> #include
> #include "intel_drv.h"
>
> +/* Dual Link support */
> +#define MIPI_DUAL_LINK_NONE 0
> +#define MIPI_DUAL_LINK_FRONT_BACK1
> +#define MIPI_DUAL_LINK_PIXEL_ALT 2
> +
Spread the word, using the word "MIPI" for "DSI" feels like saying I
have an "embedded VESA" display on my laptop. Really.
> struct intel_dsi_device {
> unsigned int panel_id;
> const char *name;
> @@ -102,6 +107,7 @@ struct intel_dsi {
>
> u8 escape_clk_div;
> u8 dual_link;
> + u8 pixel_overlap;
> u32 port_bits;
> u32 bw_timer;
> u32 dphy_reg;
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index d424ebc..8bc911b 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -284,6 +284,7 @@ static bool generic_init(struct intel_dsi_device *dsi)
> intel_dsi->pixel_format = mipi_config->videomode_color_format << 7;
> intel_dsi->port = 0;
> intel_dsi->dual_link = mipi_config->dual_link;
> + intel_dsi->pixel_overlap = mipi_config->pixel_overlap;
>
> if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB666)
> bits_per_pixel = 18;
> @@ -303,6 +304,20 @@ static bool generic_init(struct intel_dsi_device *dsi)
>
> pclk = mode->clock;
>
> + /* In dual link mode each port needs half of pixel clock */
> + if (intel_dsi->dual_link) {
> + pclk = pclk / 2;
> +
> + /* we can enable pixel_overlap if needed by panel. In this
> + * case we need to increase the pixelclock for extra pixels
> + */
> + if (intel_dsi->dual_link & MIPI_DUAL_LINK_FRONT_BACK) {
> + pclk += DIV_ROUND_UP(mode->vtotal *
> + intel_dsi->pixel_overlap *
> + 60, 1000);
> + }
> + }
> +
> /* Burst Mode Ratio
>* Target ddr frequency from VBT / non burst dd
Re: [Intel-gfx] [PATCH 3/9] drm/i915: MIPI Port Ctrl related changes for dual link configuration
On Wed, 24 Sep 2014, Gaurav K Singh wrote:
> Signed-off-by: Gaurav K Singh
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/i915/i915_reg.h|1 +
> drivers/gpu/drm/i915/intel_dsi.c | 53
> ++--
> drivers/gpu/drm/i915/intel_dsi.h |1 +
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |1 +
> 4 files changed, 45 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ad8179b..922d807 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6215,6 +6215,7 @@ enum punit_power_well {
> #define DPI_ENABLE (1 << 31) /* A + B */
> #define MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT 27
> #define MIPIA_MIPI4DPHY_DELAY_COUNT_MASK(0xf << 27)
> +#define DUAL_LINK_MODE_SHIFT26
> #define DUAL_LINK_MODE_MASK (1 << 26)
> #define DUAL_LINK_MODE_FRONT_BACK (0 << 26)
> #define DUAL_LINK_MODE_PIXEL_ALTERNATIVE(1 << 26)
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index e456ca9..3b1890e 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -109,13 +109,31 @@ static void intel_dsi_port_enable(struct intel_encoder
> *encoder)
> struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> enum pipe pipe = intel_crtc->pipe;
> - u32 temp;
> -
> - /* assert ip_tg_enable signal */
> - temp = I915_READ(MIPI_PORT_CTRL(pipe)) & ~LANE_CONFIGURATION_MASK;
> - temp = temp | intel_dsi->port_bits;
> - I915_WRITE(MIPI_PORT_CTRL(pipe), temp | DPI_ENABLE);
> - POSTING_READ(MIPI_PORT_CTRL(pipe));
> + u32 temp, port_control = 0;
> +
> + if (intel_dsi->dual_link) {
> + port_control = (intel_dsi->dual_link - 1)
> + << DUAL_LINK_MODE_SHIFT;
> + port_control |= pipe ? LANE_CONFIGURATION_DUAL_LINK_B :
> + LANE_CONFIGURATION_DUAL_LINK_A;
> + /*For Port A */
> + temp = I915_READ(MIPI_PORT_CTRL(0));
> + temp = temp | port_control;
> + I915_WRITE(MIPI_PORT_CTRL(0), temp | DPI_ENABLE);
> + POSTING_READ(MIPI_PORT_CTRL(0));
> +
> + /* For Port C */
> + temp = I915_READ(MIPI_PORT_CTRL(1));
> + I915_WRITE(MIPI_PORT_CTRL(1), temp | DPI_ENABLE);
> + POSTING_READ(MIPI_PORT_CTRL(1));
This calls for a cleanup in i915_reg.h for per port vs. per transcoder
registers. MIPI_PORT_CTRL(1) uses _TRANSCODER macro. We also have enum
port with PORT_C == 2. This gets confusing.
> + } else {
> + /* assert ip_tg_enable signal */
> + temp = I915_READ(MIPI_PORT_CTRL(pipe)) &
> + ~LANE_CONFIGURATION_MASK;
> + temp = temp | intel_dsi->port_bits;
> + I915_WRITE(MIPI_PORT_CTRL(pipe), temp | DPI_ENABLE);
> + POSTING_READ(MIPI_PORT_CTRL(pipe));
> + }
> }
>
> static void intel_dsi_port_disable(struct intel_encoder *encoder)
> @@ -123,13 +141,26 @@ static void intel_dsi_port_disable(struct intel_encoder
> *encoder)
> struct drm_device *dev = encoder->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> enum pipe pipe = intel_crtc->pipe;
> u32 temp;
>
> - /* de-assert ip_tg_enable signal */
> - temp = I915_READ(MIPI_PORT_CTRL(pipe));
> - I915_WRITE(MIPI_PORT_CTRL(pipe), temp & ~DPI_ENABLE);
> - POSTING_READ(MIPI_PORT_CTRL(pipe));
> + if (intel_dsi->dual_link) {
> + /*For Port A */
> + temp = I915_READ(MIPI_PORT_CTRL(0));
> + I915_WRITE(MIPI_PORT_CTRL(0), temp & ~DPI_ENABLE);
> + POSTING_READ(MIPI_PORT_CTRL(0));
> +
> + /* For Port C */
> + temp = I915_READ(MIPI_PORT_CTRL(1));
> + I915_WRITE(MIPI_PORT_CTRL(1), temp & ~DPI_ENABLE);
> + POSTING_READ(MIPI_PORT_CTRL(1));
> + } else {
> + /* de-assert ip_tg_enable signal */
> + temp = I915_READ(MIPI_PORT_CTRL(pipe));
> + I915_WRITE(MIPI_PORT_CTRL(pipe), temp & ~DPI_ENABLE);
> + POSTING_READ(MIPI_PORT_CTRL(pipe));
> + }
> }
>
> static void intel_dsi_device_ready(struct intel_encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 587e71f..950ab41 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -101,6 +101,7 @@ struct intel_dsi {
> u8 clock_stop;
>
>
Re: [Intel-gfx] [PATCH 5/9] drm/i915: SHUTDOWN & Turn ON packets to be sent for both MIPI Ports in case of dual link Configuration
On Wed, 24 Sep 2014, Gaurav K Singh wrote:
> Signed-off-by: Gaurav K Singh
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/i915/intel_dsi_cmd.c | 35
> ++
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.c
> b/drivers/gpu/drm/i915/intel_dsi_cmd.c
> index eb698b1..a70656e 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_cmd.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_cmd.c
> @@ -394,6 +394,7 @@ int dpi_send_cmd(struct intel_dsi *intel_dsi, u32 cmd,
> bool hs)
> struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
> enum pipe pipe = intel_crtc->pipe;
> u32 mask;
> + int count = 1;
>
> /* XXX: pipe, hs */
> if (hs)
> @@ -401,18 +402,28 @@ int dpi_send_cmd(struct intel_dsi *intel_dsi, u32 cmd,
> bool hs)
> else
> cmd |= DPI_LP_MODE;
>
> - /* clear bit */
> - I915_WRITE(MIPI_INTR_STAT(pipe), SPL_PKT_SENT_INTERRUPT);
> -
> - /* XXX: old code skips write if control unchanged */
> - if (cmd == I915_READ(MIPI_DPI_CONTROL(pipe)))
> - DRM_ERROR("Same special packet %02x twice in a row.\n", cmd);
> -
> - I915_WRITE(MIPI_DPI_CONTROL(pipe), cmd);
> -
> - mask = SPL_PKT_SENT_INTERRUPT;
> - if (wait_for((I915_READ(MIPI_INTR_STAT(pipe)) & mask) == mask, 100))
> - DRM_ERROR("Video mode command 0x%08x send failed.\n", cmd);
> + if (intel_dsi->dual_link)
> + count = 2;
> +
> + do {
Please never use a do-while when a regular for loop will do.
> + /* clear bit */
> + I915_WRITE(MIPI_INTR_STAT(pipe), SPL_PKT_SENT_INTERRUPT);
> +
> + /* XXX: old code skips write if control unchanged */
> + if (cmd == I915_READ(MIPI_DPI_CONTROL(pipe)))
> + DRM_ERROR("Same special packet %02x twice in a row.\n",
> + cmd);
> + I915_WRITE(MIPI_DPI_CONTROL(pipe), cmd);
> +
> + mask = SPL_PKT_SENT_INTERRUPT;
> + if (wait_for((I915_READ(MIPI_INTR_STAT(pipe)) & mask) ==
> + mask, 100))
> + DRM_ERROR("Video mode command 0x%08x send failed.\n",
> + cmd);
> + /* For Port C for dual link */
> + if (intel_dsi->dual_link)
> + pipe = PIPE_B;
> + } while (--count > 0);
>
> return 0;
> }
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915: Dsipll clk to be enabled for DSI1 in case of dual link configuration
On Wed, 24 Sep 2014, Gaurav K Singh wrote:
> Signed-off-by: Gaurav K Singh
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/i915/intel_dsi_pll.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index fa7a6ca..2464089 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -243,6 +243,9 @@ static void vlv_configure_dsi_pll(struct intel_encoder
> *encoder)
>
> dsi_mnp.dsi_pll_ctrl |= DSI_PLL_CLK_GATE_DSI0_DSIPLL;
>
> + if (intel_dsi->dual_link)
> + dsi_mnp.dsi_pll_ctrl |= DSI_PLL_CLK_GATE_DSI1_DSIPLL;
> +
> DRM_DEBUG_KMS("dsi pll div %08x, ctrl %08x\n",
> dsi_mnp.dsi_pll_div, dsi_mnp.dsi_pll_ctrl);
>
> @@ -271,12 +274,11 @@ void vlv_enable_dsi_pll(struct intel_encoder *encoder)
>
> mutex_unlock(&dev_priv->dpio_lock);
>
> - if (wait_for(I915_READ(PIPECONF(PIPE_A)) & PIPECONF_DSI_PLL_LOCKED,
> 20)) {
> - DRM_ERROR("DSI PLL lock failed\n");
> - return;
> - }
> -
> - DRM_DEBUG_KMS("DSI PLL locked\n");
> + tmp = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_CONTROL);
Is there no need to wait for some timeout for the pll to lock?
> + if (tmp & DSI_PLL_LOCK)
> + DRM_DEBUG_KMS("DSI PLL locked\n");
> + else
> + DRM_DEBUG_KMS("DSI PLL lock failed\n");
Please keep the happy day scenario without indent, and bail out on the
fail paths.
> }
>
> void vlv_disable_dsi_pll(struct intel_encoder *encoder)
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/core-stuff
Hi Dave, Just noticed that you've picked up the header rework stuff already, so I've rebased that out again. Otherwise just two stragglers from the vblank rework and the universal cursor planes locking fix. Plus sprinkling container_of all over fbdev emulation from Fabian. Aside: I only have just 1 fix for drm-next atm for i915 and not terribly serious. So will probably only send you a pull for it when the merge window opens or something more serious shows up. Cheers, Daniel The following changes since commit d743ecf360637d489a3ba81a268f574359149601: drm/doc: Fixup drm_irq kerneldoc includes. (2014-09-24 11:43:47 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/core-stuff-2014-09-24 for you to fetch changes up to ee0d68ab5f0997a500fdf90924a58e787b216292: drm/udl: use container_of to resolve udl_fbdev from drm_fb_helper (2014-09-24 12:09:28 +0200) Daniel Vetter (2): drm: Fixup locking for universal cursor planes drm: Improve debug output for drm_wait_one_vblank Fabian Frederick (9): drm/cirrus: use container_of to resolve cirrus_fbdev from drm_fb_helper drm/mgag200: use container_of to resolve mga_fbdev from drm_fb_helper drm/radeon: use container_of to resolve radeon_fbdev from drm_fb_helper drm/nouveau: use container_of to resolve nouveau_fbdev from drm_fb_helper drm/nouveau: use container_of to resolve nouveau_plane from drm_plane drm/qxl: use container_of to resolve qxl_fbdev from drm_fb_helper drm/gma500: use container_of to resolve psb_fbdev from drm_fb_helper drm/ast: use container_of to resolve ast_fbdev from drm_fb_helper drm/udl: use container_of to resolve udl_fbdev from drm_fb_helper Mario Kleiner (1): drm: Don't update vblank timestamp when the counter didn't change drivers/gpu/drm/ast/ast_fb.c | 3 +- drivers/gpu/drm/cirrus/cirrus_fbdev.c | 3 +- drivers/gpu/drm/drm_crtc.c | 51 -- drivers/gpu/drm/drm_irq.c | 7 ++-- drivers/gpu/drm/gma500/framebuffer.c | 3 +- drivers/gpu/drm/mgag200/mgag200_fb.c | 3 +- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 15 ++--- drivers/gpu/drm/nouveau/nouveau_fbcon.c| 3 +- drivers/gpu/drm/qxl/qxl_fb.c | 3 +- drivers/gpu/drm/radeon/radeon_fb.c | 3 +- drivers/gpu/drm/udl/udl_fb.c | 3 +- 11 files changed, 65 insertions(+), 32 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 75/89] drm/i915/skl: fetch, enable/disable pfit as needed
Hi Jesse,
Mind looking at those review comments?
--
Damien
On Tue, Sep 23, 2014 at 05:50:29PM -0300, Paulo Zanoni wrote:
> 2014-09-04 8:27 GMT-03:00 Damien Lespiau :
> > From: Jesse Barnes
> >
> > This moved around on SKL, so we need to make sure we read/write the
> > correct regs.
> >
> > Signed-off-by: Jesse Barnes
> > Signed-off-by: Damien Lespiau
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 13
> > drivers/gpu/drm/i915/intel_display.c | 61
> > +---
> > 2 files changed, 70 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 176e84e..35c0759 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4833,6 +4833,19 @@ enum skl_disp_power_wells {
> > #define PF_VSCALE(pipe)_PIPE(pipe, _PFA_VSCALE,
> > _PFB_VSCALE)
> > #define PF_HSCALE(pipe)_PIPE(pipe, _PFA_HSCALE,
> > _PFB_HSCALE)
> >
> > +#define _PSA_CTL 0x68180
> > +#define _PSB_CTL 0x68980
> > +#define PS_ENABLE (1<<31)
> > +#define PS_PIPE_SEL(pipe) ((pipe)<<27)
>
> The PS_PIPE_SEL define is wrong, but it is also not used in the code
> you wrote, so just remove this line.
>
>
> > +#define _PSA_WIN_SZ0x68174
> > +#define _PSB_WIN_SZ0x68974
> > +#define _PSA_WIN_POS 0x68178
>
> 0x68170
>
> > +#define _PSB_WIN_POS 0x68978
>
> 0x68970
>
> > +
> > +#define PS_CTL(pipe) _PIPE(pipe, _PSA_CTL, _PSB_CTL)
> > +#define PS_WIN_SZ(pipe)_PIPE(pipe, _PSA_WIN_SZ,
> > _PSB_WIN_SZ)
> > +#define PS_WIN_POS(pipe) _PIPE(pipe, _PSA_WIN_POS, _PSB_WIN_POS)
> > +
> > /* legacy palette */
> > #define _LGC_PALETTE_A 0x4a000
> > #define _LGC_PALETTE_B 0x4a800
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 393bd19..9b31342 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3882,6 +3882,19 @@ static void cpt_verify_modeset(struct drm_device
> > *dev, int pipe)
> > }
> > }
> >
> > +static void skylake_pfit_enable(struct intel_crtc *crtc)
> > +{
> > + struct drm_device *dev = crtc->base.dev;
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + int pipe = crtc->pipe;
> > +
> > + if (crtc->config.pch_pfit.enabled) {
> > + I915_WRITE(PS_CTL(pipe), PS_ENABLE);
> > + I915_WRITE(PS_WIN_POS(pipe), crtc->config.pch_pfit.pos);
> > + I915_WRITE(PS_WIN_SZ(pipe), crtc->config.pch_pfit.size);
> > + }
> > +}
> > +
> > static void ironlake_pfit_enable(struct intel_crtc *crtc)
> > {
> > struct drm_device *dev = crtc->base.dev;
> > @@ -4264,7 +4277,10 @@ static void haswell_crtc_enable(struct drm_crtc
> > *crtc)
> >
> > intel_ddi_enable_pipe_clock(intel_crtc);
> >
> > - ironlake_pfit_enable(intel_crtc);
> > + if (IS_SKYLAKE(dev))
> > + skylake_pfit_enable(intel_crtc);
> > + else
> > + ironlake_pfit_enable(intel_crtc);
> >
> > /*
> > * On ILK+ LUT must be loaded before the pipe is running but with
> > @@ -4295,6 +4311,20 @@ static void haswell_crtc_enable(struct drm_crtc
> > *crtc)
> > intel_crtc_enable_planes(crtc);
> > }
> >
> > +static void skylake_pfit_disable(struct intel_crtc *crtc)
> > +{
> > + struct drm_device *dev = crtc->base.dev;
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + int pipe = crtc->pipe;
> > +
> > + /* To avoid upsetting the power well on haswell only disable the
> > pfit if
> > +* it's in use. The hw state code will make sure we get this right.
> > */
> > + if (crtc->config.pch_pfit.enabled) {
> > + I915_WRITE(PS_CTL(pipe), 0);
> > + I915_WRITE(PS_WIN_SZ(pipe), 0);
>
> Why not also zero _POS just like HSW? Can this affect the HW state
> checker output?
>
> Everything else looks correct.
>
> > + }
> > +}
> > +
> > static void ironlake_pfit_disable(struct intel_crtc *crtc)
> > {
> > struct drm_device *dev = crtc->base.dev;
> > @@ -4399,7 +4429,10 @@ static void haswell_crtc_disable(struct drm_crtc
> > *crtc)
> >
> > intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder);
> >
> > - ironlake_pfit_disable(intel_crtc);
> > + if (IS_SKYLAKE(dev))
> > + skylake_pfit_disable(intel_crtc);
> > + else
> > + ironlake_pfit_disable(intel_crtc);
> >
> > intel_ddi_disable_pipe_clock(intel_crtc);
> >
> > @@ -7382,6 +7415,22 @@ static void ironlake_get_fdi_m_n_config(struct
> > intel_crtc *crtc,
> > &pipe_config->fdi_m_n, NULL);
> > }
> >
> > +static void skylake_get_pfit_config(struct intel_crtc *crtc,
> > +
[Intel-gfx] [PATCH v2 1/2] drm/i915: Initialize bdw workarounds in logical ring mode too
Following the legacy ring submission example, update the
ring->init_context() hook to support the execlist submission mode.
Workarounds are defined in bdw_emit_workarounds(), but the emit
now depends on the ring submission mode.
v2: Updated after "Cleanup pre prod workarounds"
For: VIZ-4092
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 66 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 75 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 11 -
4 files changed, 120 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 7b73b36..d1ed21a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -657,7 +657,7 @@ done:
if (uninitialized) {
if (ring->init_context) {
- ret = ring->init_context(ring);
+ ret = ring->init_context(ring->buffer);
if (ret)
DRM_ERROR("ring init context: %d\n", ret);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d64d518..a0aa3f0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1020,6 +1020,62 @@ int intel_logical_ring_begin(struct intel_ringbuffer
*ringbuf, int num_dwords)
return 0;
}
+static inline void intel_logical_ring_emit_wa(struct intel_ringbuffer *ringbuf,
+ u32 addr, u32 value)
+{
+ struct intel_engine_cs *ring = ringbuf->ring;
+ struct drm_device *dev = ring->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (WARN_ON(dev_priv->num_wa_regs >= I915_MAX_WA_REGS))
+ return;
+
+ intel_logical_ring_emit(ringbuf, MI_LOAD_REGISTER_IMM(1));
+ intel_logical_ring_emit(ringbuf, addr);
+ intel_logical_ring_emit(ringbuf, value);
+
+ dev_priv->intel_wa_regs[dev_priv->num_wa_regs].addr = addr;
+ dev_priv->intel_wa_regs[dev_priv->num_wa_regs].mask = value & 0x;
+ /* value is updated with the status of remaining bits of this
+* register when it is read from debugfs file
+*/
+ dev_priv->intel_wa_regs[dev_priv->num_wa_regs].value = value;
+ dev_priv->num_wa_regs++;
+}
+
+static int bdw_init_logical_workarounds(struct intel_ringbuffer *ringbuf)
+{
+ int ret;
+ struct intel_engine_cs *ring = ringbuf->ring;
+ struct drm_device *dev = ring->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ /*
+* workarounds applied in this fn are part of register state context,
+* they need to be re-initialized followed by gpu reset, suspend/resume,
+* module reload.
+*/
+ dev_priv->num_wa_regs = 0;
+ memset(dev_priv->intel_wa_regs, 0, sizeof(dev_priv->intel_wa_regs));
+
+ /*
+* update the number of dwords required based on the
+* actual number of workarounds applied
+*/
+ ret = intel_logical_ring_begin(ringbuf, BDW_WA_DWORDS_SIZE);
+ if (ret)
+ return ret;
+
+ bdw_emit_workarounds(ringbuf);
+
+ intel_logical_ring_advance(ringbuf);
+
+ DRM_DEBUG_DRIVER("Number of Workarounds applied: %d\n",
+dev_priv->num_wa_regs);
+
+ return 0;
+}
+
static int gen8_init_common_ring(struct intel_engine_cs *ring)
{
struct drm_device *dev = ring->dev;
@@ -1315,6 +1371,10 @@ static int logical_render_ring_init(struct drm_device
*dev)
if (HAS_L3_DPF(dev))
ring->irq_keep_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
+ if (IS_BROADWELL(dev))
+ ring->init_context = bdw_init_logical_workarounds;
+ ring->emit_wa = intel_logical_ring_emit_wa;
+
ring->init = gen8_init_render_ring;
ring->cleanup = intel_fini_pipe_control;
ring->get_seqno = gen8_get_seqno;
@@ -1802,6 +1862,12 @@ int intel_lr_context_deferred_create(struct
intel_context *ctx,
}
if (ring->id == RCS && !ctx->rcs_initialized) {
+ if (ring->init_context) {
+ ret = ring->init_context(ringbuf);
+ if (ret)
+ DRM_ERROR("ring init context: %d\n", ret);
+ }
+
ret = intel_lr_context_render_state_init(ring, ctx);
if (ret) {
DRM_ERROR("Init render state failed: %d\n", ret);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 395f926..e6ac913 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -677,9 +677,10 @@ err:
return ret;
}
-static inline void intel_ring_emit_wa(struct intel_engine_cs
[Intel-gfx] [PATCH v2 2/2] drm/i915: Initialize chv workarounds in logical ring mode too
Also enable the ring->init_context() hook for chv in execlist submission
mode.
For: VIZ-4092
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_lrc.c| 37 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 39 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
3 files changed, 61 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a0aa3f0..7864dac 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1076,6 +1076,39 @@ static int bdw_init_logical_workarounds(struct
intel_ringbuffer *ringbuf)
return 0;
}
+static int chv_init_logical_workarounds(struct intel_ringbuffer *ringbuf)
+{
+ int ret;
+ struct intel_engine_cs *ring = ringbuf->ring;
+ struct drm_device *dev = ring->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ /*
+* workarounds applied in this fn are part of register state context,
+* they need to be re-initialized followed by gpu reset, suspend/resume,
+* module reload.
+*/
+ dev_priv->num_wa_regs = 0;
+ memset(dev_priv->intel_wa_regs, 0, sizeof(dev_priv->intel_wa_regs));
+
+ /*
+* update the number of dwords required based on the
+* actual number of workarounds applied
+*/
+ ret = intel_logical_ring_begin(ringbuf, CHV_WA_DWORDS_SIZE);
+ if (ret)
+ return ret;
+
+ chv_emit_workarounds(ringbuf);
+
+ intel_logical_ring_advance(ringbuf);
+
+ DRM_DEBUG_DRIVER("Number of Workarounds applied: %d\n",
+dev_priv->num_wa_regs);
+
+ return 0;
+}
+
static int gen8_init_common_ring(struct intel_engine_cs *ring)
{
struct drm_device *dev = ring->dev;
@@ -1371,7 +1404,9 @@ static int logical_render_ring_init(struct drm_device
*dev)
if (HAS_L3_DPF(dev))
ring->irq_keep_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
- if (IS_BROADWELL(dev))
+ if (IS_CHERRYVIEW(dev))
+ ring->init_context = chv_init_logical_workarounds;
+ else
ring->init_context = bdw_init_logical_workarounds;
ring->emit_wa = intel_logical_ring_emit_wa;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index e6ac913..ec0b2f0 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -776,6 +776,27 @@ static int bdw_init_workarounds(struct intel_ringbuffer
*ringbuf)
return 0;
}
+void chv_emit_workarounds(struct intel_ringbuffer *ringbuf)
+{
+ struct intel_engine_cs *ring = ringbuf->ring;
+
+ /* WaDisablePartialInstShootdown:chv */
+ ring->emit_wa(ringbuf, GEN8_ROW_CHICKEN,
+ _MASKED_BIT_ENABLE(PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE));
+
+ /* WaDisableThreadStallDopClockGating:chv */
+ ring->emit_wa(ringbuf, GEN8_ROW_CHICKEN,
+ _MASKED_BIT_ENABLE(STALL_DOP_GATING_DISABLE));
+
+ /* WaDisableDopClockGating:chv (pre-production hw) */
+ ring->emit_wa(ringbuf, GEN7_ROW_CHICKEN2,
+ _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
+
+ /* WaDisableSamplerPowerBypass:chv (pre-production hw) */
+ ring->emit_wa(ringbuf, HALF_SLICE_CHICKEN3,
+ _MASKED_BIT_ENABLE(GEN8_SAMPLER_POWER_BYPASS_DIS));
+}
+
static int chv_init_workarounds(struct intel_ringbuffer *ringbuf)
{
int ret;
@@ -791,25 +812,11 @@ static int chv_init_workarounds(struct intel_ringbuffer
*ringbuf)
dev_priv->num_wa_regs = 0;
memset(dev_priv->intel_wa_regs, 0, sizeof(dev_priv->intel_wa_regs));
- ret = intel_ring_begin(ring, 12);
+ ret = intel_ring_begin(ring, CHV_WA_DWORDS_SIZE);
if (ret)
return ret;
- /* WaDisablePartialInstShootdown:chv */
- intel_ring_emit_wa(ringbuf, GEN8_ROW_CHICKEN,
-
_MASKED_BIT_ENABLE(PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE));
-
- /* WaDisableThreadStallDopClockGating:chv */
- intel_ring_emit_wa(ringbuf, GEN8_ROW_CHICKEN,
- _MASKED_BIT_ENABLE(STALL_DOP_GATING_DISABLE));
-
- /* WaDisableDopClockGating:chv (pre-production hw) */
- intel_ring_emit_wa(ringbuf, GEN7_ROW_CHICKEN2,
- _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
-
- /* WaDisableSamplerPowerBypass:chv (pre-production hw) */
- intel_ring_emit_wa(ringbuf, HALF_SLICE_CHICKEN3,
- _MASKED_BIT_ENABLE(GEN8_SAMPLER_POWER_BYPASS_DIS));
+ chv_emit_workarounds(ringbuf);
intel_ring_advance(ring);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 417aa09..02e3728 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -16,6
Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440
Hi, On 09/24/2014 11:14 AM, Pali Rohár wrote: > On Wednesday 24 September 2014 10:59:41 Pali Rohár wrote: >> On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote: >>> Hi, >>> >>> On 09/23/2014 10:44 PM, Pali Rohár wrote: On Tuesday 23 September 2014 22:31:31 you wrote: > Hi, > > On 09/23/2014 10:06 PM, Pali Rohár wrote: >> Hello, >> >> after big changes in acpi video/i915 code I cannot >> change display brightness on my Dell Latitude E6440 >> with kernel 3.17-rc6. With kernel 3.13 everything >> worked fine. >> >> More information about this problem: >> >> For configuring brightness on Dell laptops there are 4 >> ways: 1) via acpi video driver >> 2) via dell-laptop driver >> 3) via i915 drm driver >> 4) from userspace with special dell SMI call >> >> (e.g with program dellLcdBrightness from libsmbios >> package) >> >> Methods 2) and 4) are same, both making special SMI call >> and Bios handing this request (just 2 is from kernel and >> 4 from userspace) >> >> Method 1) via acpi video driver working, but is not >> perfect. Driver can be used to change brightness (but >> only some levels, probably this depends on acpi/DSDT >> tables), but cannot be used to retrieve current >> brightness (when BIOS/SMI change brightness acpi driver >> report old incorrect value). So I prefer dell-laptop >> driver instead acpi video. >> >> Method 3) working even with 3.17-rc6 kernel but because >> that backlight device exported by i915 is marked as raw, >> desktop programs prefer to use other devices. >> >> Moreover it looks like that methods 1) 2) and 4) just >> forward request to method 3). So in any cased brightness >> is changed by i915 drm driver. >> >> I'm not sure (correct me if I'm wrong!) but I think that >> intel i915 drm driver accept changes (file >> intel_opregion.c) only if acpi function >> acpi_video_verify_backlight_support() returns true. >> >> Function acpi_video_verify_backlight_support() returns >> true iff: function acpi_video_backlight_support() >> returns true AND at least one of these functions >> returns false: acpi_osi_is_win8() >> acpi_video_use_native_backlight() >> backlight_device_registered(BACKLIGHT_RAW) >> >> On my notebook acpi_osi_is_win8() returns true (as is >> win8 compliant), >> backlight_device_registered(BACKLIGHT_RAW) returns true >> as I'm using intel i915 drm driver with raw backlight >> device and acpi_video_use_native_backlight() returns >> true/false depending on >> "video.use_native_backlight" kernel param. Default is >> true. >> >> So if I want to have working acpi video driver with >> display brightness support I need to boot kernel with >> param: "video.use_native_backlight=0". I tested it with >> kernel 3.17-rc6 and this param really enabled display >> brightness support via acpi video driver -- which is >> good. >> >> Driver dell-laptop creating backligh device for >> brightness control only if >> acpi_video_backlight_support() returns false. There is >> complicated condition for it and when kernel is booted >> with "video.use_native_backlight=0" that function >> returns true. >> >> So conclusion is: With current code in kernel 3.17-rc6 >> it is not possible to control brightness of display >> with native driver dell-laptop on Dell Latitude E6440 >> (and probably on others too)!!! >> >> And Because laptop is win8 compliant and you create >> decision to use native driver (instead acpi one) it is >> not possible to control display brightness without >> tweeks in kernel cmdline. >> >> As I wrote I would rather to use native dell-laptop >> driver for controlling brightness, but it is not >> possible. >> >> So how to solve this problem? >> >> Quick solution would be to set use_native_backlight >> false for some Dell laptops which means, that acpi >> video will be used and in this case intel i915 driver >> will *not* drop backlight change request. >> >> Another solution could be to disable check in >> dell_laptop driver and add use_native_backlight=0 to >> hooks. But this create two backlight interfaces (which >> is not good), but only way (for now) how to make >> dell_laptop working again. >> >> Better and maybe only one proper solution would be to >> teach intel drm i915 driver to not drop backlight change >> request for Dell laptops (or all??). (This allows to >> work both acpi video and dell_laptop drivers without >> any change and with *any* value in param >> use_native_backlight). I think that problematic code is >> in function asle_set_backlight() in file >> intel_opregion.c (but I'm not sure). My idea is that >> "
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Adds graphic address space ballooning logic
Hi Daniel & Chris, Thank you very much for your comments, And sorry for my late reply.:) I was focusing on other tasks previously. See my questions below: On 9/23/2014 7:25 PM, Daniel Vetter wrote: On Tue, Sep 23, 2014 at 10:19:02AM +0100, Chris Wilson wrote: On Tue, Sep 23, 2014 at 10:26:26AM +0200, Daniel Vetter wrote: On Fri, Sep 19, 2014 at 09:00:00PM +0100, Chris Wilson wrote: On Fri, Sep 19, 2014 at 06:21:46PM +, Tian, Kevin wrote: From: Chris Wilson The implementation also looks backwards. To work correctly with the GTT allocator, you need to preallocate the reserved space such that it can only allocate from the allowed ranges. Similarly, it should evict any conflicting nodes when deballooning. Could you elaborate a bit for above suggestion? My expectation was that the dev_priv->gtt.base.vm would contain exactly two holes after setup (in the mappable and non-mappable range). To do that you would explicitly reserve everything barred from this client using a set of drm_mm_reserve_node() Essentially a reserve_node implements what you open-code with insert_node_range right now. Heh, there is a big difference. One inserts exactly where you ask and fails if it conflicts, the other inserts where it feels like within that range. Do you mean drm_mm_search_free_in_range_generic() may not get reserve the exact range we are expecting to? Is this why you'd prefer the drm_mm_reserve_node()? Besides, the ggtt_vm->mm is just initialized right before the ballooning code in routine i915_gem_setup_global_gtt(), so is there any chance the range to be partitioned out is already reserved by someone else? Well if the the requested size matches the range exactly then it will be the same. Which iirc is what's going on here I think. One issue aside with both this and with the PDE reservations for gen7 is that there are now other thins in the ggtt drm_mm allocator than just gem objects. Which means our debugfs files are now less useful. It might be useful to augment that dumper with one that dumps everything. We could add a few bits of driver-private tags in drm_mm_node (there's space) to figure out what kind of object it is. Would be a great follow-up task. I think moving the other way and making them all objects so that we can tie them into evection and the shrinker, use more interesting allocation strategies, improve integration with debugging etc. Hm, not sure yet since it will be a lot of work at least. But I guess we could untangle the meaning of obj->pin a bit and add an unbind vfunc which adds some magic. But there's a lot of stuff attached to a gem bo that just doesn't make a lot of sense really, so maybe a better option would be to subclass a struct i915_ggtt_vma with special magic. Dunno really. Sorry, not sure what these comments are about. :) I'll need time to read the code. Could you please elaborate a bit? Thanks! P.S. about the guard page: for now, the current logic reserves a guard page between different guests and at the very last entry of the whole physical GTT. the previous comments says: "The CS prefetcher happens everywhere and so can read from the end of one range into the beginning of another clients". So I guess the guard page in current patch is necessary, right? -Daniel Thanks Yu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] tools/null_state_gen: Add GEN9 golden context batch buffer creation
From: Armin Reese
Modifications to 'null_state_gen' so it can generate GEN9
golden context batch buffer source for SKL.
v2: - rebased on top of gen8 changes (Mika)
- fixed state base address command size (Mika)
- base address size macro as pages (Mika)
Signed-off-by: Armin Reese
Signed-off-by: Mika Kuoppala
---
lib/gen9_render.h | 8 +
tools/null_state_gen/Makefile.am | 3 +-
tools/null_state_gen/intel_null_state_gen.c | 34 +-
tools/null_state_gen/intel_renderstate_gen9.c | 442 ++
4 files changed, 476 insertions(+), 11 deletions(-)
create mode 100644 lib/gen9_render.h
create mode 100644 tools/null_state_gen/intel_renderstate_gen9.c
diff --git a/lib/gen9_render.h b/lib/gen9_render.h
new file mode 100644
index 000..a061808
--- /dev/null
+++ b/lib/gen9_render.h
@@ -0,0 +1,8 @@
+#ifndef GEN9_RENDER_H
+#define GEN9_RENDER_H
+
+#include "gen8_render.h"
+
+#define GEN9_PIPELINE_SELECT (GEN6_3D(1, 1, 4) | (3 << 8))
+
+#endif /* GEN9_RENDER_H */
diff --git a/tools/null_state_gen/Makefile.am b/tools/null_state_gen/Makefile.am
index 58fbd53..b131e0d 100644
--- a/tools/null_state_gen/Makefile.am
+++ b/tools/null_state_gen/Makefile.am
@@ -8,9 +8,10 @@ intel_null_state_gen_SOURCES = \
intel_renderstate_gen6.c \
intel_renderstate_gen7.c \
intel_renderstate_gen8.c \
+ intel_renderstate_gen9.c \
intel_null_state_gen.c
-gens := 6 7 8
+gens := 6 7 8 9
h = /tmp/intel_renderstate_gen$$gen.c
state_headers: intel_null_state_gen
diff --git a/tools/null_state_gen/intel_null_state_gen.c
b/tools/null_state_gen/intel_null_state_gen.c
index a7eb22b..1021a37 100644
--- a/tools/null_state_gen/intel_null_state_gen.c
+++ b/tools/null_state_gen/intel_null_state_gen.c
@@ -5,21 +5,23 @@
#include "intel_batchbuffer.h"
-#define STATE_ALIGN 64
-
extern int gen6_setup_null_render_state(struct intel_batchbuffer *batch);
extern int gen7_setup_null_render_state(struct intel_batchbuffer *batch);
extern int gen8_setup_null_render_state(struct intel_batchbuffer *batch);
+extern int gen9_setup_null_render_state(struct intel_batchbuffer *batch);
static int debug = 0;
static void print_usage(char *s)
{
fprintf(stderr, "%s: \n"
- " gen: gen to generate for (6,7,8)\n",
- s);
+ " gen: gen to generate for (6,7,8,9)\n",
+ s);
}
+/* Creates the intel_renderstate_genX.c file for the particular
+ * GEN product
+ */
static int print_state(int gen, struct intel_batchbuffer *batch)
{
int i;
@@ -29,24 +31,32 @@ static int print_state(int gen, struct intel_batchbuffer
*batch)
printf("#include \"intel_renderstate.h\"\n\n");
+ /* Relocation offsets. These are byte offsets in the golden context
+* batch buffer where the BB graphics address will be added to
+* the indirect state offset already stored in those locations. The
+* resulting value will inform the GPU where the indirect states are.
+*/
printf("static const u32 gen%d_null_state_relocs[] = {\n", gen);
for (i = 0; i < batch->cmds->num_items; i++) {
if (intel_batch_is_reloc(batch, i))
printf("\t0x%08x,\n", i * 4);
}
- printf("\t%d,\n", -1);
- printf("};\n\n");
+ printf("\t-1,\n};\n\n");
+ /* GPU commands to execute to set up the RCS golden state. This
+* state will become the default config.
+*/
printf("static const u32 gen%d_null_state_batch[] = {\n", gen);
for (i = 0; i < intel_batch_num_cmds(batch); i++) {
+ const int offset = i * 4;
const struct bb_item *cmd = intel_batch_cmd_get(batch, i);
printf("\t0x%08x,", cmd->data);
if (debug)
- printf("\t /* 0x%08x %s '%s' */", i * 4,
- intel_batch_type_as_str(cmd), cmd->str);
+ printf("\t /* 0x%08x %s '%s' */", offset,
+ intel_batch_type_as_str(cmd), cmd->str);
- if (i * 4 == batch->cmds_end_offset) {
+ if (offset == batch->cmds_end_offset) {
cmds = i + 1;
printf("\t /* cmds end */");
}
@@ -54,7 +64,7 @@ static int print_state(int gen, struct intel_batchbuffer
*batch)
if (intel_batch_is_reloc(batch, i))
printf("\t /* reloc */");
- if (i * 4 == batch->state_start_offset)
+ if (offset == batch->state_start_offset)
printf("\t /* state start */");
if (i == intel_batch_num_cmds(batch) - 1)
@@ -73,6 +83,7 @@ static int print_state(int gen, struct intel_batchbuffer
*batch)
return 0;
}
+/* Selects generator function for the given product and executes it. *
[Intel-gfx] [PATCH 1/3] tools/null_state_gen: add macro to emit commands with null state
In null/golden context there are multiple state commands where
the actual state is always zero. For more compact batch representation
add a macro which just emits command and the rest of the state as zero.
Signed-off-by: Mika Kuoppala
---
tools/null_state_gen/intel_batchbuffer.c| 12
tools/null_state_gen/intel_batchbuffer.h| 6 +-
tools/null_state_gen/intel_null_state_gen.c | 12 +++-
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/tools/null_state_gen/intel_batchbuffer.c
b/tools/null_state_gen/intel_batchbuffer.c
index 2a0b340..6e86aef 100644
--- a/tools/null_state_gen/intel_batchbuffer.c
+++ b/tools/null_state_gen/intel_batchbuffer.c
@@ -274,3 +274,15 @@ const char *intel_batch_type_as_str(const struct bb_item
*item)
return "UNKNOWN";
}
+
+void intel_batch_cmd_emit_null(struct intel_batchbuffer *batch, const int cmd,
const int len, const char *str)
+{
+ int i;
+
+ assert(len > 1);
+
+ bb_area_emit(batch->cmds, (cmd | (len - 2)), CMD, str);
+
+ for (i = 1; i < len; i++)
+ OUT_BATCH(0);
+}
diff --git a/tools/null_state_gen/intel_batchbuffer.h
b/tools/null_state_gen/intel_batchbuffer.h
index e44c5c9..b4eed25 100644
--- a/tools/null_state_gen/intel_batchbuffer.h
+++ b/tools/null_state_gen/intel_batchbuffer.h
@@ -34,7 +34,7 @@
#include
#define MAX_RELOCS 64
-#define MAX_ITEMS 4096
+#define MAX_ITEMS 1024
#define MAX_STRLEN 256
#define ALIGN(x, y) (((x) + (y)-1) & ~((y)-1))
@@ -69,6 +69,7 @@ struct intel_batchbuffer {
struct intel_batchbuffer *intel_batchbuffer_create(void);
+#define OUT_CMD(cmd, len) intel_batch_cmd_emit_null(batch, cmd, len, #cmd " "
#len)
#define OUT_BATCH(d) bb_area_emit(batch->cmds, d, CMD, #d)
#define OUT_BATCH_STATE_OFFSET(d) bb_area_emit(batch->cmds, d, STATE_OFFSET,
#d)
#define OUT_RELOC(batch, read_domain, write_domain, d)
bb_area_emit(batch->cmds, d, RELOC, #d)
@@ -81,6 +82,7 @@ uint32_t intel_batch_state_copy(struct intel_batchbuffer
*batch, void *d, unsign
const char *name);
uint32_t intel_batch_state_alloc(struct intel_batchbuffer *batch, unsigned
bytes, unsigned align,
const char *name);
+uint32_t intel_batch_state_offset(struct intel_batchbuffer *batch, unsigned
align);
unsigned intel_batch_num_cmds(struct intel_batchbuffer *batch);
@@ -94,4 +96,6 @@ const char *intel_batch_type_as_str(const struct bb_item
*item);
void bb_area_emit(struct bb_area *a, uint32_t dword, item_type type, const
char *str);
void bb_area_emit_offset(struct bb_area *a, unsigned i, uint32_t dword,
item_type type, const char *str);
+void intel_batch_cmd_emit_null(struct intel_batchbuffer *batch, const int cmd,
const int len, const char *str);
+
#endif
diff --git a/tools/null_state_gen/intel_null_state_gen.c
b/tools/null_state_gen/intel_null_state_gen.c
index b337706..a7eb22b 100644
--- a/tools/null_state_gen/intel_null_state_gen.c
+++ b/tools/null_state_gen/intel_null_state_gen.c
@@ -23,6 +23,9 @@ static void print_usage(char *s)
static int print_state(int gen, struct intel_batchbuffer *batch)
{
int i;
+ unsigned long cmds;
+
+ fprintf(stderr, "Generating for gen%d\n", gen);
printf("#include \"intel_renderstate.h\"\n\n");
@@ -43,8 +46,10 @@ static int print_state(int gen, struct intel_batchbuffer
*batch)
printf("\t /* 0x%08x %s '%s' */", i * 4,
intel_batch_type_as_str(cmd), cmd->str);
- if (i * 4 == batch->cmds_end_offset)
+ if (i * 4 == batch->cmds_end_offset) {
+ cmds = i + 1;
printf("\t /* cmds end */");
+ }
if (intel_batch_is_reloc(batch, i))
printf("\t /* reloc */");
@@ -60,6 +65,11 @@ static int print_state(int gen, struct intel_batchbuffer
*batch)
printf("};\n\nRO_RENDERSTATE(%d);\n", gen);
+ fprintf(stderr, "Commands %lu (%lu bytes)\n", cmds, cmds * 4);
+ fprintf(stderr, "State%lu (%lu bytes)\n", batch->state->num_items,
batch->state->num_items * 4);
+ fprintf(stderr, "Total%lu (%lu bytes)\n", batch->cmds->num_items,
batch->cmds->num_items * 4);
+ fprintf(stderr, "\n");
+
return 0;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] tools/null_state_gen: gen8 golden state
Previously we didn't have a clear understanding what is necessary for a pipeline state to be properly initialized. So we had to improvise and use a stripped out render copy. Now we have a more clear understanding so switch out render copy based frankenstate to state we can call golden state. --- lib/gen6_render.h | 5 +- lib/gen8_render.h | 24 + tools/null_state_gen/intel_renderstate_gen8.c | 842 -- 3 files changed, 295 insertions(+), 576 deletions(-) diff --git a/lib/gen6_render.h b/lib/gen6_render.h index c3e85eb..8a4ec53 100644 --- a/lib/gen6_render.h +++ b/lib/gen6_render.h @@ -41,7 +41,7 @@ /* These two are BLC and CTG only, not BW or CL */ #define GEN6_3DSTATE_AA_LINE_PARAMSGEN6_3D(3, 1, 0xa) #define GEN6_3DSTATE_GS_SVB_INDEX GEN6_3D(3, 1, 0xb) - +#define GEN6_3DSTATE_MONOFILTER_SIZE GEN6_3D(3, 1, 0x11) #define GEN6_3DPRIMITIVE GEN6_3D(3, 3, 0) #define GEN6_3DSTATE_CLEAR_PARAMS GEN6_3D(3, 1, 0x10) @@ -91,6 +91,7 @@ # define GEN6_3DSTATE_SF_TRI_PROVOKE_SHIFT 29 # define GEN6_3DSTATE_SF_LINE_PROVOKE_SHIFT27 # define GEN6_3DSTATE_SF_TRIFAN_PROVOKE_SHIFT 25 +# define GEN6_3DSTATE_SF_VERTEX_SUB_PIXEL_PRECISION_SHIFT 12 #define GEN6_3DSTATE_WMGEN6_3D(3, 0, 0x14) /* DW2 */ @@ -303,7 +304,6 @@ #define GEN6_EU_ATT_CLR_1 0x8834 #define GEN6_EU_RDATA 0x8840 - #define GEN6_PIPE_CONTROL GEN6_3D(3, 2, 0) #define GEN6_3DPRIMITIVE GEN6_3D(3, 3, 0) @@ -411,6 +411,7 @@ /* for GEN6_STATE_BASE_ADDRESS */ #define BASE_ADDRESS_MODIFY(1 << 0) +#define BUFFER_SIZE_MODIFY (1 << 0) /* for GEN6_3DSTATE_PIPELINED_POINTERS */ #define GEN6_GS_DISABLE 0 diff --git a/lib/gen8_render.h b/lib/gen8_render.h index 0eec80c..ba3f9f2 100644 --- a/lib/gen8_render.h +++ b/lib/gen8_render.h @@ -8,6 +8,8 @@ #define GEN7_3DSTATE_URB_DS (0x7832 << 16) #define GEN7_3DSTATE_URB_GS (0x7833 << 16) +# define GEN7_WM_LEGACY_DIAMOND_LINE_RASTERIZATION (1 << 26) + #define GEN6_3DSTATE_SCISSOR_STATE_POINTERSGEN6_3D(3, 0, 0xf) #define GEN7_3DSTATE_CLEAR_PARAMS GEN6_3D(3, 0, 0x04) #define GEN7_3DSTATE_DEPTH_BUFFER GEN6_3D(3, 0, 0x05) @@ -29,6 +31,7 @@ #define GEN7_3DSTATE_CONSTANT_GS GEN6_3D(3, 0, 0x16) #define GEN7_3DSTATE_CONSTANT_HS GEN6_3D(3, 0, 0x19) #define GEN7_3DSTATE_CONSTANT_DS GEN6_3D(3, 0, 0x1a) +#define GEN7_3DSTATE_CONSTANT_PS GEN6_3D(3, 0, 0x17) #define GEN7_3DSTATE_HSGEN6_3D(3, 0, 0x1b) #define GEN7_3DSTATE_TEGEN6_3D(3, 0, 0x1c) #define GEN7_3DSTATE_DSGEN6_3D(3, 0, 0x1d) @@ -44,6 +47,12 @@ # define GEN8_RASTER_FRONT_WINDING_CCW (1 << 21) # define GEN8_RASTER_CULL_NONE (1 << 16) #define GEN7_3DSTATE_PSGEN6_3D(3, 0, 0x20) +# define GEN7_PS_SPF_MODE (1 << 31) + +# define GEN7_SF_POINT_WIDTH_FROM_SOURCE(1 << 11) + +# define GEN7_VS_FLOATING_POINT_MODE_ALTERNATE (1 << 16) + #define GEN7_3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP \ GEN6_3D(3, 0, 0x21) #define GEN8_3DSTATE_PS_BLEND GEN6_3D(3, 0, 0x4d) @@ -68,14 +77,26 @@ #define GEN7_3DSTATE_SAMPLER_STATE_POINTERS_GS GEN6_3D(3, 0, 0x2e) #define GEN7_3DSTATE_SAMPLER_STATE_POINTERS_PS GEN6_3D(3, 0, 0x2f) +#define GEN8_3DSTATE_VFGEN6_3D(3, 0, 0x0c) #define GEN8_3DSTATE_VF_TOPOLOGY GEN6_3D(3, 0, 0x4b) +#define GEN8_3DSTATE_BIND_TABLE_POOL_ALLOC GEN6_3D(3, 1, 0x19) +#define GEN8_3DSTATE_GATHER_POOL_ALLOC GEN6_3D(3, 1, 0x1a) +#define GEN8_3DSTATE_DX9_CONSTANT_BUFFER_POOL_ALLOCGEN6_3D(3, 1, 0x1b) #define GEN7_3DSTATE_PUSH_CONSTANT_ALLOC_VSGEN6_3D(3, 1, 0x12) #define GEN7_3DSTATE_PUSH_CONSTANT_ALLOC_HSGEN6_3D(3, 1, 0x13) #define GEN7_3DSTATE_PUSH_CONSTANT_ALLOC_DSGEN6_3D(3, 1, 0x14) #define GEN7_3DSTATE_PUSH_CONSTANT_ALLOC_GSGEN6_3D(3, 1, 0x15) #define GEN7_3DSTATE_PUSH_CONSTANT_ALLOC_PSGEN6_3D(3, 1, 0x16) +#define GEN8_3DSTATE_VF_SGVS GEN6_3D(3, 0, 0x4a) +#define GEN8_3DSTATE_SO_DECL_LIST GEN6_3D(3, 1, 0x17) +#define GEN8_3DSTATE_SO_BUFFER GEN6_3D(3, 1, 0x18) +#define GEN8_3DSTATE_POLY_STIPPLE_OFFSET GEN6_3D(3, 1, 0x06) +#define GEN8_3DSTATE_POLY_STIPPLE_PATTERN GEN6_3D(3, 1, 0x07) +#define GEN8_3DSTATE_SAMPLER_PALETTE_LOAD0 GEN6_3D(3, 1, 0x02) +#define GEN8_3DSTATE_SAMPLER_PALETTE_LOAD1 GEN6_3D(3, 1, 0x0c) + /* Some random bits that we care about */ #define GEN7_VB0_BUFFER_A
[Intel-gfx] [IGDVFIO] [PATCH 0/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
https://github.com/UmbraMalison/qemu-igdvfio
Hi all,
I am publishing my work on IGD Direct Assignment in a semi-working state as
I need some help from the community to finish these. It may also be a good
time to take in comments from the community.
There has been an increased interest in IGD DA of recent, and as such there
has been many patches in both QEMU and XEN.
What makes these patches different is that they address some areas of
concern (whilst probably adding a few new ones).
IGDVFIO:
1) uses Q35 chipset and does not duplicate LPC controllers
2) uses VFIO, extending it to support IGD and does not use legacy
passthrough or XEN passthrough.
3) attempts to mimic host bios PCI configuration.
IGDVFIO does have some hacks, these are mostly temporary as they require
some effort to resolve and I plan to only do this once full IGD support in
guest is realised.
Hacks:
1) use of /dev/mem for memory mapping - this might be done by VFIO kernel
driver
2) use of hardcoded LPC ID's in seabios and ich9_lpc.c - this might be
solved by relaxing seabios, or providing another method for chipset
identification.
3) IGD detection in the chipset - simply need to devise a function to
detect IGD
n) ...
Current functionality:
i915 loads and DRM debug info matches host output in all respects except
for the base addresses of DSM and opregion (as these are relocated in guest
memory).
Intel frame buffer also appears to work.
Xorg drivers (in the guest) do not work, IGD falls into a loop of resetting
and failing to find anything on the blitter ring. in the logs it can be
seen that the ring buffer is working, but the blitter ring is full of
zeros. Which means that the GPU is probably reading from the wrong location.
As this is a little complex, and I suspect that I have missed some
important information, I will be updating github and wiki with detailed
instructions on how to use these patches. Currently the wiki is out of
date, so check for updates v.soon.
https://github.com/UmbraMalison/qemu-igdvfio
patches are based on qemu 2.1 and seabios 1.7.5 respectively.
Attached are the patches, incase this is a more usable format. They do also
include Alex Williamsons e820 patch, this is not mentioned in the following
patch emails.
Kind Regards,
Andrew Barnes
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 97932a6..18c72d2 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -617,6 +617,9 @@ int e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
e820_table[e820_entries].type = cpu_to_le32(type);
e820_entries++;
+fw_cfg_update_file(fw_cfg_find(), "etc/e820", e820_table,
+ sizeof(struct e820_entry) * e820_entries);
+
return e820_entries;
}
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index b846d81..e6a7fbd 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -6,6 +6,7 @@
* Isaku Yamahata
* VA Linux Systems Japan K.K.
* Copyright (C) 2012 Jason Baron
+ * Copyright (C) 2014 Andrew Barnes IGD Support
*
* This is based on piix_pci.c, but heavily modified.
*
@@ -46,6 +47,16 @@
#include "exec/address-spaces.h"
#include "sysemu/sysemu.h"
+/* #define DEBUG_LPC */
+#ifdef DEBUG_LPC
+# define LPC_DPRINTF(format, ...) print("LPC: " format, ## __VA_ARGS__)
+#else
+# define LPC_DPRINTF(format, ...) do {} while (0)
+#endif
+
+/* For intel-spec conforming config */
+#define CORRECT_CONFIG
+
static int ich9_lpc_sci_irq(ICH9LPCState *lpc);
/*/
@@ -53,6 +64,10 @@ static int ich9_lpc_sci_irq(ICH9LPCState *lpc);
static void ich9_lpc_reset(DeviceState *qdev);
+/* BEWARE: only set this if you are passing IGD through to guest */
+/* TODO: detect IGD automatically */
+static bool IGD_PASSTHROUGH = true;
+
/* chipset configuration register
* to access chipset configuration registers, pci_[sg]et_{byte, word, long}
* are used.
@@ -425,6 +440,9 @@ static void ich9_lpc_config_write(PCIDevice *d,
ICH9LPCState *lpc = ICH9_LPC_DEVICE(d);
uint32_t rbca_old = pci_get_long(d->config + ICH9_LPC_RCBA);
+LPC_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, 0x%x, len=0x%x)\n", __func__,
+, 00, PCI_SLOT(d->devfn),PCI_FUNC(d->devfn), addr, val, len);
+
pci_default_write_config(d, addr, val, len);
if (ranges_overlap(addr, len, ICH9_LPC_PMBASE, 4)) {
ich9_lpc_pmbase_update(lpc);
@@ -440,6 +458,34 @@ static void ich9_lpc_config_write(PCIDevice *d,
}
}
+static uint32_t ich9_lpc_config_read(PCIDevice *d,
+ uint32_t addr, int len)
+{
+uint32_t val;
+if (IGD_PASSTHROUGH)
+{
+ if (ranges_overlap(addr, len, 0x2c, 2) || /* SVID - Subsystem Vendor Identification */
+ ranges_overlap(addr, len, 0x2e, 2)) /* SID - Subsystem Identificaion */
+ {
+ val = host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FUNC(d->devfn),addr,len);
+ }
+ else
+ {
+ goto defaultread;
+ }
+}
+else
[Intel-gfx] [IGDVFIO] [PATCH 1/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
hw/isa/lpc_ich9.c
this patch adds:
* debug output, if enabled
* enforces correct intel config, if enabled. (unsure if this is needed)
* redirects some PCI Config to host
* uses hosts LPC device id
patch
-
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index b846d81..e6a7fbd 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -6,6 +6,7 @@
* Isaku Yamahata
* VA Linux Systems Japan K.K.
* Copyright (C) 2012 Jason Baron
+ * Copyright (C) 2014 Andrew Barnes IGD Support
*
* This is based on piix_pci.c, but heavily modified.
*
@@ -46,6 +47,16 @@
#include "exec/address-spaces.h"
#include "sysemu/sysemu.h"
+/* #define DEBUG_LPC */
+#ifdef DEBUG_LPC
+# define LPC_DPRINTF(format, ...) print("LPC: " format, ## __VA_ARGS__)
+#else
+# define LPC_DPRINTF(format, ...) do {} while (0)
+#endif
+
+/* For intel-spec conforming config */
+#define CORRECT_CONFIG
+
static int ich9_lpc_sci_irq(ICH9LPCState *lpc);
/*/
@@ -53,6 +64,10 @@ static int ich9_lpc_sci_irq(ICH9LPCState *lpc);
static void ich9_lpc_reset(DeviceState *qdev);
+/* BEWARE: only set this if you are passing IGD through to guest */
+/* TODO: detect IGD automatically */
+static bool IGD_PASSTHROUGH = true;
+
/* chipset configuration register
* to access chipset configuration registers, pci_[sg]et_{byte, word, long}
* are used.
@@ -425,6 +440,9 @@ static void ich9_lpc_config_write(PCIDevice *d,
ICH9LPCState *lpc = ICH9_LPC_DEVICE(d);
uint32_t rbca_old = pci_get_long(d->config + ICH9_LPC_RCBA);
+LPC_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, 0x%x, len=0x%x)\n", __func__,
+, 00, PCI_SLOT(d->devfn),PCI_FUNC(d->devfn), addr,
val, len);
+
pci_default_write_config(d, addr, val, len);
if (ranges_overlap(addr, len, ICH9_LPC_PMBASE, 4)) {
ich9_lpc_pmbase_update(lpc);
@@ -440,6 +458,34 @@ static void ich9_lpc_config_write(PCIDevice *d,
}
}
+static uint32_t ich9_lpc_config_read(PCIDevice *d,
+ uint32_t addr, int len)
+{
+uint32_t val;
+if (IGD_PASSTHROUGH)
+{
+ if (ranges_overlap(addr, len, 0x2c, 2) || /* SVID - Subsystem Vendor
Identification */
+ranges_overlap(addr, len, 0x2e, 2)) /* SID - Subsystem Identificaion
*/
+ {
+ val =
host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FUNC(d->devfn),addr,len);
+ }
+ else
+ {
+ goto defaultread;
+ }
+}
+else
+{
+defaultread:
+ val = pci_default_read_config(d,addr,len);
+}
+
+LPC_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %x\n", __func__,
+, 00, PCI_SLOT(d->devfn),PCI_FUNC(d->devfn), addr,
len, val);
+
+return val;
+}
+
static void ich9_lpc_reset(DeviceState *qdev)
{
PCIDevice *d = PCI_DEVICE(qdev);
@@ -577,6 +623,13 @@ static int ich9_lpc_init(PCIDevice *d)
isa_bus = isa_bus_new(&d->qdev, get_system_io());
+#ifdef CORRECT_CONFIG
+pci_set_word(d->wmask + PCI_COMMAND,
+(PCI_COMMAND_SERR | PCI_COMMAND_PARITY));
+pci_set_word(d->config + PCI_COMMAND,
+(PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
PCI_COMMAND_MASTER));
+#endif
+
pci_set_long(d->wmask + ICH9_LPC_PMBASE,
ICH9_LPC_PMBASE_BASE_ADDRESS_MASK);
@@ -665,11 +718,20 @@ static void ich9_lpc_class_init(ObjectClass *klass,
void *data)
k->init = ich9_lpc_init;
dc->vmsd = &vmstate_ich9_lpc;
k->config_write = ich9_lpc_config_write;
+k->config_read = ich9_lpc_config_read;
dc->desc = "ICH9 LPC bridge";
k->vendor_id = PCI_VENDOR_ID_INTEL;
k->device_id = PCI_DEVICE_ID_INTEL_ICH9_8;
k->revision = ICH9_A2_LPC_REVISION;
k->class_id = PCI_CLASS_BRIDGE_ISA;
+
+/* For a UN-MODIFIED guest, the following 3 registers need to be read
from the host.
+ * alternatively, modify i915_drv.c, intel_detect_pch, add a check for
+ * PCI_DEVICE_ID_INTEL_ICH9_8 and copy the settings from the PCH you
desire */
+k->vendor_id = host_pci_read_config(0,0x1f,0,0x00,2);
+k->device_id = host_pci_read_config(0,0x1f,0,0x02,2);
+//k->revision = host_pci_read_config(0,0x1f,0,0x08,1);
+
/*
* Reason: part of ICH9 southbridge, needs to be wired up by
* pc_q35_init()
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGDVFIO] [PATCH 2/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
hw/misc/vfio.c
this patch adds:
* memory map intel opregion
* mirroring of bdsm to guest's device 0 not hosts.
patch
-
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index e88b610..54e549b 100644
--- a/hw/misc/vfio.c
+++ b/hw/misc/vfio.c
@@ -5,6 +5,7 @@
*
* Authors:
* Alex Williamson
+ * Andrew Barnes IGD Support
*
* This work is licensed under the terms of the GNU GPL, version 2. See
* the COPYING file in the top-level directory.
@@ -56,6 +57,45 @@
#define VFIO_ALLOW_KVM_MSI 1
#define VFIO_ALLOW_KVM_MSIX 1
+/* A handy list of IGD device ID's */
+#define IS_IGD_HASWELL(id)(id == 0x0402 \
+|| id == 0x0406 \
+|| id == 0x040a \
+|| id == 0x0412 \
+|| id == 0x0416 \
+|| id == 0x041a \
+|| id == 0x0a04 \
+|| id == 0x0a16 \
+|| id == 0x0a22 \
+|| id == 0x0a26 \
+|| id == 0x0a2a )
+#define IS_IGD_IVYBRIDGE(id) (id == 0x0162 \
+|| id == 0x0166 \
+|| id == 0x016a \
+|| id == 0x0152 \
+|| id == 0x0156 \
+|| id == 0x015a )
+#define IS_IGD_SANDYBRIDGE(id)(id == 0x0102 \
+|| id == 0x0106 \
+|| id == 0x0112 \
+|| id == 0x0116 \
+|| id == 0x0122 \
+|| id == 0x0126 \
+|| id ==0x010a )
+#define IS_IGD_IRONLAKE_CLARKDALE(id) (id == 0x0042 )
+#define IS_IGD_IRONLAKE_ARRANDALE(id) (id == 0x0046 )
+#define IS_IGD(id)(IS_IGD_IRONLAKE_CLARKDALE(id) \
+|| IS_IGD_IRONLAKE_ARRANDALE(id) \
+|| IS_IGD_SANDYBRIDGE(id) \
+|| IS_IGD_IVYBRIDGE(id) \
+|| IS_IGD_HASWELL(id) )
+#define IGD_BAR_MASK 0x
+#define DMAR_OPERATION_TIMEOUT((s_time_t)((_ms) * 100ULL))
+
+#define PCI_CONFIG_INTEL_OPREGION 0xfc
+#define INTEL_OPREGION_PAGES3
+#define INTEL_OPREGION_SIZE INTEL_OPREGION_PAGES *
TARGET_PAGE_SIZE
+
struct VFIODevice;
typedef struct VFIOQuirk {
@@ -227,6 +267,8 @@ typedef struct VFIODevice {
bool has_pm_reset;
bool needs_reset;
bool rom_read_failed;
+MemoryRegion opregion; /* Intel opregion */
+uint32_t host_opregion; /* Host address of opregion */
} VFIODevice;
typedef struct VFIOGroup {
@@ -283,6 +325,18 @@ static void vfio_pci_write_config(PCIDevice *pdev,
uint32_t addr,
uint32_t val, int len);
static void vfio_mmap_set_enabled(VFIODevice *vdev, bool enabled);
+static void vfio_set_word_bits(uint8_t *buf, uint16_t val, uint16_t mask);
+static void vfio_add_emulated_word(VFIODevice *vdev, int pos,
+ uint16_t val, uint16_t mask);
+static void vfio_set_long_bits(uint8_t *buf, uint32_t val, uint32_t mask);
+static void vfio_add_emulated_long(VFIODevice *vdev, int pos,
+ uint32_t val, uint32_t mask);
+static void vfio_add_emulated_rw_long(VFIODevice *vdev, int pos,
+ uint32_t val, uint32_t mask);
+static void vfio_map_igdopregion(VFIODevice *vdev, uint32_t
guest_opregion);
+
+static VFIODevice *igdvfio;
+
/*
* Common VFIO interrupt disable
*/
@@ -2324,27 +2378,46 @@ static uint32_t vfio_pci_read_config(PCIDevice
*pdev, uint32_t addr, int len)
VFIODevice *vdev = DO_UPCAST(VFIODevice, pdev, pdev);
uint32_t emu_bits = 0, emu_val = 0, phys_val = 0, val;
-memcpy(&emu_bits, vdev->emulated_config_bits + addr, len);
-emu_bits = le32_to_cpu(emu_bits);
-
-if (emu_bits) {
-emu_val = pci_default_read_config(pdev, addr, len);
+/* BDSM mirror - BDSM can be read at either 0xb0 device 0, or 0x5c
device 2.
+ * Redirect this mirror from host 0xb0 device 0 to guest 0xb0 device
0.*/
+if (IS_IGD(pci_get_word(pdev->config + PCI_DEVICE_ID)) &&
ranges_overlap(addr,len,0x5c,4))
+{
+DPRINTF("%s Read Trapped (%04x:%02x:%02x.%x, @0x%x, 0x%x,
len=0x%x)\n", __func__,
+vdev->host.domain, vdev->host.bus, vdev->host.slot,
+vdev->host.function, addr, val, len);
+PCIBus *root = pci_find_primary_bus();
+PCIDevice *q35 = pci_find_device(root,0,
[Intel-gfx] [IGDVFIO] [PATCH 3/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
hw/pci-host/q35.c
this patch adds:
* redirect some PCI config reads/writes to host
* memory map BSDM, BGSM, TSEG
patch
-
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index a0a3068..05348ac 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -6,6 +6,7 @@
* Isaku Yamahata
* VA Linux Systems Japan K.K.
* Copyright (C) 2012 Jason Baron
+ * 2014 Andrew barnes IGD Support
*
* This is based on piix_pci.c, but heavily modified.
*
@@ -30,11 +31,26 @@
#include "hw/hw.h"
#include "hw/pci-host/q35.h"
#include "qapi/visitor.h"
+#include "hw/pci/pci.h"
+#include /* memory map functions */
+
+/* #define DEBUG_Q35 */
+#ifdef DEBUG_Q35
+# define Q35_DPRINTF(format, ...) printf("Q35: " format, ##
__VA_ARGS__)
+#else
+# define Q35_DPRINTF(format, ...) do { } while (0)
+#endif
+
+/* for intel-spec conforming config */
+/* #define CORRECT_CONFIG */
/
* Q35 host
*/
+/* BEWARE: only set this if you are passing IGD through */
+static bool IGD_PASSTHROUGH = true;
+
static void q35_host_realize(DeviceState *dev, Error **errp)
{
PCIHostState *pci = PCI_HOST_BRIDGE(dev);
@@ -284,11 +300,193 @@ static void mch_set_smm(int smm, void *arg)
memory_region_transaction_commit();
}
-static void mch_write_config(PCIDevice *d,
+/* TODO: Move these variables/defines to be consistent with Q35 coding
style */
+MemoryRegion bdsm;
+uint32_t bdsm_host;
+MemoryRegion bgsm;
+uint32_t bgsm_host;
+MemoryRegion tseg;
+uint32_t tseg_host;
+#define MCH_CONFIG_BDSM 0xb0
+#define MCH_CONFIG_BGSM 0xb4
+#define MCH_CONFIG_TSEG 0xb8
+#define MCH_CONFIG_GMCH 0x50
+
+/* Setup memory map for Stolen Memory */
+static void mch_setup_bdsm(PCIDevice *d)
+{
+int fd;
+char name[64];
+void *map;
+bdsm_host =
host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FUNC(d->devfn),MCH_CONFIG_BDSM,4);
+int dsm_size;
+uint16_t gmch_host =
host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FUNC(d->devfn),MCH_CONFIG_GMCH,2);
+uint16_t gmch_dsm = (gmch_host & 0xF8) >> 3;
+MCHPCIState *mch = MCH_PCI_DEVICE(d);
+
+Q35_DPRINTF("%s Setup BDSM: %x\n",__func__,bdsm_host);
+
+snprintf(name, sizeof(name), "MCH-BDSM-mmap");
+fd = open("/dev/mem", O_RDWR);
+
+switch (gmch_dsm)
+{
+ case 0x0: dsm_size = 0; break;
+ case 0x1: dsm_size = 32; break;
+ case 0x2: dsm_size = 64; break;
+ case 0x3: dsm_size = 96; break;
+ case 0x4: dsm_size = 128; break;
+ case 0x5: dsm_size = 160; break;
+ case 0x6: dsm_size = 192; break;
+ case 0x7: dsm_size = 224; break;
+ case 0x8: dsm_size = 256; break;
+ case 0x9: dsm_size = 288; break;
+ case 0xa: dsm_size = 320; break;
+ case 0xb: dsm_size = 352; break;
+ case 0xc: dsm_size = 384; break;
+ case 0xd: dsm_size = 416; break;
+ case 0xe: dsm_size = 448; break;
+ case 0xf: dsm_size = 480; break;
+ case 0x10: dsm_size = 512; break;
+ // default: /* panic */
+}
+
+dsm_size = dsm_size * 1024 * 1024;
+map = mmap(NULL,dsm_size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,(bdsm_host
& 0xFFF0));
+
+if (map == MAP_FAILED)
+{
+map = NULL;
+Q35_DPRINTF("%s Setup BDSM: MAP_FAILED\n",__func__);
+}
+
+memory_region_init_ram_ptr(&bdsm, OBJECT(mch), name, dsm_size, map);
+}
+
+/* this function memory maps the region of host memory assigned to Stolen
memory
+ * to the guest location provided by seabios. */
+static void mch_map_bdsm(PCIDevice *d, uint32_t bdsm_new)
+{
+MemoryRegion *guest_memory = get_system_memory();
+uint32_t bdsm_current = pci_default_read_config(d,MCH_CONFIG_BDSM,4);
+
+if ( bdsm_current != bdsm_host && bdsm_current != 0 )
+{
+// remap
+Q35_DPRINTF("%s Delete BDSM mapping: %x\n",__func__,(bdsm_current
& 0xFFF0));
+memory_region_del_subregion(guest_memory, &bdsm);
+}
+Q35_DPRINTF("%s Add BDSM mapping: %x ->
%x\n",__func__,bdsm_host,bdsm_new);
+memory_region_add_subregion(guest_memory, (bdsm_new & 0xFFF0),
&bdsm);
+}
+
+/* Setup memory map for GTT Stolen Memory */
+static void mch_setup_bgsm(PCIDevice *d)
+{
+int fd;
+char name[64];
+void *map;
+bgsm_host =
host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FUNC(d->devfn),MCH_CONFIG_BGSM,4);
+int gsm_size;
+uint16_t gmch_host =
host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FUNC(d->devfn),MCH_CONFIG_GMCH,2);
+uint16_t gmch_gsm = (gmch_host & 0x300) >> 8;
+MCHPCIState *mch = MCH_PCI_DEVICE(d);
+
+Q35_DPRINTF("%s Setup BGSM: %x\n",__func__,bgsm_host);
+
+snprintf(name, sizeof(name), "MCH %04x:%02x:%02x.%x BGSM mmap",
+ 0, 0, 0, 0);
+
+fd = open("/dev/mem", O_RDWR);
+
+switch (gmch_gsm)
+{
+ case 0x2: gsm_size = 2; break;
+ case 0x1: gsm_size = 1; break;
+ case 0x0: gsm_size = 0; break;
+ // default: /* panic */
+
[Intel-gfx] [IGDVFIO] [PATCH 7/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
include/hw/pci/pci_ids.h A very last minute realisation is that this is not needed. Its purpose is to make sure anything else that references LPC device ID is given the hacked-in host's ID. but in verifying the patch validity it appears this not referenced anywhere, other than where its taken care on in ich9_lpc.c for completeness, here it is: patch - diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h index e597070..b76c61b 100644 --- a/include/hw/pci/pci_ids.h +++ b/include/hw/pci/pci_ids.h @@ -130,7 +130,19 @@ #define PCI_DEVICE_ID_INTEL_ICH9_5 0x2919 #define PCI_DEVICE_ID_INTEL_ICH9_6 0x2930 #define PCI_DEVICE_ID_INTEL_ICH9_7 0x2916 -#define PCI_DEVICE_ID_INTEL_ICH9_8 0x2918 + +/* TODO: Replace this hack for a non-hack! + * PCI_DEVICE_ID_INTEL_ICH9_8 must be set to + * `setpci -s 00:1f.0 0x02.w` (LPC device id) + * of the host - so that guest LPC represents + * the archiecture of device 2 (IGD). This is + * important to i915 kernel module */ +#define BEARLAKE 0x2918 // QEMU DEFAULT +#define COUGARPOINT 0x1c4e +#define PANTHERPOINT 0x +#define LYNXPOINT 0x8c4e + +#define PCI_DEVICE_ID_INTEL_ICH9_8 COUGARPOINT #define PCI_DEVICE_ID_INTEL_82801I_UHCI1 0x2934 #define PCI_DEVICE_ID_INTEL_82801I_UHCI2 0x2935 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGDVFIO] [PATCH 5/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
include/hw/pci-host/q35.h
this patch adds:
* #defines for q35 pci config. not all are used, added for completeness
patch
-
diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index d9ee978..abb795e 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -4,6 +4,7 @@
* Copyright (c) 2009 Isaku Yamahata
*VA Linux Systems Japan K.K.
* Copyright (C) 2012 Jason Baron
+ * 2014 Andrew Baranes IGD Support
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -85,6 +86,165 @@ typedef struct Q35PCIHost {
/* D0:F0 configuration space */
#define MCH_HOST_BRIDGE_REVISION_DEFAULT 0x0
+#define D0F0_VID 0x00
/* 16 bits RO */
+#define D0F0_VID_SIZE 2
/* 2 Bytes */
+
+
+#define D0F0_DID 0x02
/* 16 bits RO */
+#define D0F0_DID_SIZE 2
/* 2 Bytes */
+
+
+#define D0F0_PCICMD0x04
/* 16 bits */
+
/* 15:10 RO RESERVED */
+#define D0F0_PCICMD_FB2B 0x200
/* 9 RO=0 Fast back-to-back Enable */
+#define D0F0_PCICMD_SERR 0x100
/* 8 RW */
+#define D0F0_PCICMD_ADSTEP 0x80
/* 7 RO=0 Address/Data Stepping Enable */
+#define D0F0_PCICMD_PERR 0x40
/* 6 RW */
+#define D0F0_PCICMD_VGASNOOP 0x20
/* 5 RO=0 VGA Palette Snoop Enable */
+#define D0F0_PCICMD_MWI0x10
/* 4 RO=0 Memory Write and Invalidate Enable */
+
/* 3 RO RESERVED */
+#define D0F0_PCICMD_BME0x04
/* 2 RO=1 Bus Master Enable */
+#define D0F0_PCICMD_MAE0x02
/* 1 RO=1 Memory Access Enable */
+#define D0F0_PCICMD_IOAE 0x01
/* 0 RO=0 I/O Access Enable */
+#define D0F0_PCICMD_SIZE 2
/* 2 Bytes */
+
+
+#define D0F0_PCISTS0x06
/* 16 bits */
+#define D0F0_PCISTS_DPE0x8000
/* 15 RW1C Detected Parity Error */
+#define D0F0_PCISTS_SSE0x4000
/* 14 RW1C Signaled System Error */
+#define D0F0_PCISTS_RMAS 0x2000
/* 13 RW1C Received Master Abort Status */
+#define D0F0_PCISTS_RTAS 0x1000
/* 12 RW1C Reveived Target Abort Status */
+#define D0F0_PCISTS_STAS 0x800
/* 11 RO=0 Signaled Target Abort Status */
+#define D0F0_PCISTS_DEVT_MASK 0x600
/* 10:9 RO=DEVSEL_FAST DEVSEL Timing */
+#define D0F0_PCISTS_DEVT_FAST 0x000
/* DEVSEL_FAST=00 */
+#define D0F0_PCISTS_DPD0x100
/* 8 RW1C Master Data parity Error Detected */
+#define D0F0_PCISTS_FB2B 0x80
/* 7 RO=1 Fast Back-to-Back */
+
/* 6 bitpos RO RESERVED */
+#define D0F0_PCISTS_MC66 0x20
/* 5 RO=0 66 MHz Capable */
+#define D0F0_PCISTS_CLIST 0x10
/* 4 RO=1 Capability List */
+
/* 3:0 bitpos RO RESERVED */
+#define D0F0_PCISTS_SIZE 2
/* 2 Bytes */
+
+
+#define D0F0_RID 0x08
/* 8 bits RO */
+#define D0F0_RID_SIZE 1
/* 1 Byte */
+
+
+#define D0F0_CC0x09
/* 24 bits */
+#define D0F0_CC_BCC0x80
/* 23:16 RO=06 Base Class Code indicating a Bridge Device */
+#define D0F0_CC_SUBCC 0x8000
/* 15:8 RO=00 Sub-Class Code indicating a Host Bridge */
+#define D0F0_CC_PI 0x80
/* 7:0 RO=00 Programming Interface */
+#define D0F0_CC_SIZE 3
/* 3 Bytes */
+
+
+#define D0F0_HDR 0x0e
/* 7:0 RO=00 indicating single function */
+#define D0F0_HDR_SIZE 1
/* 1 Byte */
+
+
+#define D0F0_SVID 0x2c
/* 15:0 RW-O Subsytem Vendor ID */
+#define D0F0_SVID_SIZE 2
/* 2 Bytes */
+
+
+#define D0F0_SID 0x2e
/* 15:0 RW-O Subsytem ID */
+#define D0F0_SID_SIZE 2
/* 2 Bytes */
+
+
+#define D0F0_PXPEPBAR 0x40
/* 64 bits PCI Express Egrees Port Base Address Register */
+
/* 63:39 RO RESERVED */
+#define D0F0_PXPEPBAR_PXPEPBAR Q35_MASK(64, 38, 12)
/* 38:12 RW PXPEPBAR */
+
/* 11:1 RO RESERVED */
+#define D0F0_PXPEPBAR_PXPEPBAREN 0x01
/* 0 RW PXPEPBAR Enable */
+#define D0F0_PXPEPBAR_SIZE 8
/* 8 Bytes */
+
+
+#define D0F0_MCHBAR0x48
/* 64 bits Host Memory Mapped Register Range Base */
+
/* 63:39 RO RESERVED */
+#define D0F0_MCHBAR_MCHBAR Q35_MASK(64, 38, 15)
/* 38:15 RW MCHBAR */
+
/* 14:1 RO RESERVED */
+#defi
[Intel-gfx] [IGDVFIO] [PATCH 8/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
Seabios patch
This patch covers all the changes to seabios. The intentions are to make
seabios behave like the hosts BIOS. and like the hosts BIOS, configure the
Q35 chipset more thoroughly.
This patch configures TOM, TOUUD, TOLUD, BDSM, BGSM, TSEG, IGD-OPREGION.
by writing new base addresses, VFIO and Q35 trap these writes and enable
memory mapping from the host memory to the new guest locations.
--
diff --git a/src/fw/dev-q35.h b/src/fw/dev-q35.h
index 6ae039f..dac8799 100644
--- a/src/fw/dev-q35.h
+++ b/src/fw/dev-q35.h
@@ -14,7 +14,18 @@
#define Q35_HOST_PCIE_START_BUS_NUMBER 0
#define Q35_HOST_PCIE_END_BUS_NUMBER255
-#define PCI_DEVICE_ID_INTEL_ICH9_LPC0x2918
+/* TODO: Replace this hack for a non-hack!
+ * PCI_DEVICE_ID_INTEL_ICH9_LPC must be set to
+ * `setpci -s 00:1f.0 0x02.w` (LPC device id)
+ * of the host - so that seabios recognises
+ * the hardware QEMU is providing,
+ * which now includes the hosts LPC */
+#define Q35_BEARLAKE 0x2918 // QEMU DEFAULT
+#define Q35_COUGARPOINT 0x1c4e
+#define Q35_PANTHERPOINT 0x
+#define Q35_LYNXPOINT 0x8c4e
+
+#define PCI_DEVICE_ID_INTEL_ICH9_LPCQ35_COUGARPOINT
#define ICH9_LPC_PMBASE 0x40
#define ICH9_LPC_PMBASE_RTE 0x1
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 0e5d51b..bcd519b 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -389,20 +389,111 @@ static void i440fx_mem_addr_setup(struct pci_device
*dev, void *arg)
static void mch_mem_addr_setup(struct pci_device *dev, void *arg)
{
-u64 addr = Q35_HOST_BRIDGE_PCIEXBAR_ADDR;
-u32 size = Q35_HOST_BRIDGE_PCIEXBAR_SIZE;
+/* Base addresses are either calculated by their location with respect
to
+ * TOM as described by Intel documentation.
+ * Or they are allocated using malloc. In either case, the new base
addresses
+ * are written to pci_config space, where by qemu(q35) and vfio catch
these changes
+ * and respond accordingly.
+ * The intention is to mimic the hosts BIOS role in configuring the
PCI_CONFIG space.
+ * TODO: Clearly, this is not complete
+ * - as complete Direct Assignment is not completly working.*/
+
+/* TODO: Move these defines to be consistent with seabios */
+#define Q35_TOM 0xa0
+#define Q35_TOM_BASEADDR0x70
+#define Q35_TOUUD 0xa8
+#define Q35_TOUUD_BASEADDR 0x70
+#define Q35_TOLUD 0xbc
+#define Q35_TOLUD_BASEADDR 0xFFF0
+#define Q35_APIC_FLASH_TXT_SIZE 20 * 1024 * 1024
+#define Q35_PCIEXBAR_SIZE 256 * 1024 * 1024
+#define Q35_IDK_SIZE768 * 1024 * 1024
+#define Q35_PCIEXBAR_BASEADDR 0x7FF000
+#define Q35_BDSM0xb0
+#define Q35_BDSM_BASEADDR 0xFFF0
+#define Q35_GMCH_DSM_MASK 0xF8
+#define Q35_BGSM0xb4
+#define Q35_BGSM_BASEADDR 0xFFF0
+#define Q35_GMCH_GSM_MASK 0x300
+#define Q35_TSEG0xb8
+#define Q35_TSEG_BASEADDR 0xFFF0
+#define TSEG_SIZE 8 * 1024 * 1024
+#define Q35_MCHBAR 0x48
+#define Q35_MCHBAR_BASEADDR 0x7F8000
+#define Q35_MCHBAR_EN 0x1
+#define Q35_MCHBAR_SIZE 0x8000
+#define Q35_DMIBAR 0x68
+#define Q35_DMIBAR_BASEADDR 0x7FF000
+#define Q35_DMIBAR_EN 0x1
+#define Q35_DMIBAR_SIZE 0x1000
+#define IGD_OPREGION0xfc
+#define IGD_OPREGION_PAGES 3
+#define IGD_OPREGION_SIZE IGD_OPREGION_PAGES * PAGE_SIZE
+#define IGD_BDSM0x5c
+#define Q35_GDSM0x52
+
+u16 q35bdf = dev->bdf;
+
+/* setup TOM - Top Of Memory */
+u32 tom_lower, tom_upper;
+u64 tom, touud;
+
+if (RamSizeOver4G)
+{
+ /* TODO: not finished. +4GB no supported */
+tom = (0x1 + RamSizeOver4G) & Q35_TOM_BASEADDR;
+touud = tom & Q35_TOUUD_BASEADDR; // minus all Intel ME stolen
memory if reclaim/remap is disabled
+dprintf(1, "Q35: RamSizeOver4G: %016llX\n", tom);
+}
+else
+{
+tom = RamSize & Q35_TOM_BASEADDR;
+touud = 0x0; // disabled if RamSize is under 4G
+dprintf(1, "Q35: RamSize: %x\n", RamSize);
+}
-/* setup mmconfig */
-u16 bdf = dev->bdf;
-u32 upper = addr >> 32;
-u32 lower = (addr & 0x) | Q35_HOST_BRIDGE_PCIEXBAREN;
-pci_config_writel(bdf, Q35_HOST_BRIDGE_PCIEXBAR, 0);
-pci_config_writel(bdf, Q35_HOST_BRIDGE_PCIEXBAR + 4, upper);
-pci_config_writel(bdf, Q35_HOST_BRIDGE_PCIEXBAR, lower);
-add_e820(addr, size, E820_RESERVED);
+tom_lower = (tom & 0x);
+tom_upper = tom >> 32;
+pci_config_writel(q35bdf,
+ Q35_TOM,
+ tom_lower);
+pci_config_writel(q35bdf,
+ Q35_TOM+0x4,
+ tom_upper);
+
+/* setup TOUUD - T
[Intel-gfx] [IGDVFIO] [PATCH 4/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
hw/pci/pci.c
this patch adds:
* read / write host PCI config space
patch
-
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 42995e6..041f6f1 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2,6 +2,8 @@
* QEMU PCI bus manager
*
* Copyright (c) 2004 Fabrice Bellard
+ *2014 Andrew Barnes IGD Support
+ *Temporarily extended to provide host config read/write.
*
* Permission is hereby granted, free of charge, to any person obtaining a
copy
* of this software and associated documentation files (the "Software"),
to deal
@@ -37,9 +39,9 @@
#include "exec/address-spaces.h"
#include "hw/hotplug.h"
-//#define DEBUG_PCI
+/* #define DEBUG_PCI */
#ifdef DEBUG_PCI
-# define PCI_DPRINTF(format, ...) printf(format, ## __VA_ARGS__)
+# define PCI_DPRINTF(format, ...) printf("pci:" format, ##
__VA_ARGS__)
#else
# define PCI_DPRINTF(format, ...) do { } while (0)
#endif
@@ -60,6 +62,81 @@ static Property pci_props[] = {
DEFINE_PROP_END_OF_LIST()
};
+/* Provides config reads from the host */
+uint32_t host_pci_read_config(int bus, int slot, int fn, uint32_t address,
int len)
+{
+uint32_t val = 0;
+int fd;
+int domain = 0;
+ssize_t ret;
+char dir[128], name[128];
+
+snprintf(dir, sizeof(dir), "/sys/bus/pci/devices/%04x:%02x:%02x.%x/",
+ domain, bus, slot, fn);
+snprintf(name, sizeof(name), "%sconfig", dir);
+
+fd = open(name, O_RDONLY);
+
+if (fd >= 0)
+{
+do
+{
+ret = pread(fd,&val,len,address);
+} while ((ret < 0) && (errno == EINTR || errno == EAGAIN));
+
+if (ret != len)
+{
+PCI_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %s ret=%zd
error=%d\n",
+ __func__, , bus, slot, fn, address, len, "pread
Failed",ret,errno);
+val = (1UL << (len * 8)) - 1;
+}
+}
+else
+{
+PCI_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %s\n",
+ __func__, , bus, slot, fn, address, len, "Open
Failed");
+}
+
+PCI_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %x\n",
+ __func__, , bus, slot, fn, address, len, val);
+return val;
+}
+
+/* Provides config writes to the host*/
+void host_pci_write_config(int bus, int slot, int fn, uint32_t address,
int len, uint32_t val)
+{
+int fd;
+int domain = 0;
+ssize_t ret;
+char dir[128], name[128];
+
+snprintf(dir, sizeof(dir), "/sys/bus/pci/devices/%04x:%02x:%02x.%x/",
+ domain, bus, slot, fn);
+snprintf(name, sizeof(name), "%sconfig", dir);
+
+fd = open(name, O_RDWR);
+
+if (fd >= 0)
+{
+do
+{
+ret = pwrite(fd,&val,len,address);
+} while ((ret < 0) && (errno == EINTR || errno == EAGAIN));
+
+
+if (ret != len)
+{
+PCI_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %x %s
ret=%zd error=%d\n",
+ __func__, , bus, slot, fn, address, len, val, "pread
Failed",ret,errno);
+}
+}
+else
+{
+PCI_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %s\n",
+ __func__, , bus, slot, fn, address, len, "Open
Failed");
+}
+}
+
static const VMStateDescription vmstate_pcibus = {
.name = "PCIBUS",
.version_id = 1,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [IGDVFIO] [PATCH 6/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
include/hw/pci/pci.h patch - diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h index c352c7b..d3bc224 100644 --- a/include/hw/pci/pci.h +++ b/include/hw/pci/pci.h @@ -338,6 +338,9 @@ typedef PCIINTxRoute (*pci_route_irq_fn)(void *opaque, int pin); #define PCI_BUS(obj) OBJECT_CHECK(PCIBus, (obj), TYPE_PCI_BUS) #define TYPE_PCIE_BUS "PCIE" +uint32_t host_pci_read_config(int bus, int slot, int fn, uint32_t address, int len); +void host_pci_write_config(int bus, int slot, int fn, uint32_t address, int len, uint32_t val); + bool pci_bus_is_express(PCIBus *bus); bool pci_bus_is_root(PCIBus *bus); void pci_bus_new_inplace(PCIBus *bus, size_t bus_size, DeviceState *parent, ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Adds graphic address space ballooning logic
On Wed, Sep 24, 2014 at 08:35:50PM +0800, Zhang, Yu wrote: > Hi Daniel & Chris, > > Thank you very much for your comments, And sorry for my late > reply.:) I was focusing on other tasks previously. > See my questions below: > > On 9/23/2014 7:25 PM, Daniel Vetter wrote: > >On Tue, Sep 23, 2014 at 10:19:02AM +0100, Chris Wilson wrote: > >>On Tue, Sep 23, 2014 at 10:26:26AM +0200, Daniel Vetter wrote: > >>>On Fri, Sep 19, 2014 at 09:00:00PM +0100, Chris Wilson wrote: > On Fri, Sep 19, 2014 at 06:21:46PM +, Tian, Kevin wrote: > >>From: Chris Wilson > >>The implementation also looks backwards. To work correctly with the GTT > >>allocator, you need to preallocate the reserved space such that it can > >>only allocate from the allowed ranges. Similarly, it should evict any > >>conflicting nodes when deballooning. > > > >Could you elaborate a bit for above suggestion? > > My expectation was that the dev_priv->gtt.base.vm would contain exactly > two holes after setup (in the mappable and non-mappable range). To do > that you would explicitly reserve everything barred from this client > using a set of drm_mm_reserve_node() > >>> > >>>Essentially a reserve_node implements what you open-code with > >>>insert_node_range right now. > >> > >>Heh, there is a big difference. One inserts exactly where you ask and > >>fails if it conflicts, the other inserts where it feels like within that > >>range. > > Do you mean drm_mm_search_free_in_range_generic() may not get > reserve the exact range we are expecting to? Is this why you'd > prefer the drm_mm_reserve_node()? > > Besides, the ggtt_vm->mm is just initialized right before the > ballooning code in routine i915_gem_setup_global_gtt(), so is there > any chance the range to be partitioned out is already reserved by > someone else? No. It is just that drm_mm_reserve_node() was added to have the precise semantics expected here with the strict checks. And should work better with dynamic ballooning... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Adds graphic address space ballooning logic
On Wed, Sep 24, 2014 at 08:35:50PM +0800, Zhang, Yu wrote: > Hi Daniel & Chris, > > Thank you very much for your comments, And sorry for my late reply.:) I > was focusing on other tasks previously. > See my questions below: > > On 9/23/2014 7:25 PM, Daniel Vetter wrote: > >On Tue, Sep 23, 2014 at 10:19:02AM +0100, Chris Wilson wrote: > >>On Tue, Sep 23, 2014 at 10:26:26AM +0200, Daniel Vetter wrote: > >>>On Fri, Sep 19, 2014 at 09:00:00PM +0100, Chris Wilson wrote: > On Fri, Sep 19, 2014 at 06:21:46PM +, Tian, Kevin wrote: > >>From: Chris Wilson > >>The implementation also looks backwards. To work correctly with the GTT > >>allocator, you need to preallocate the reserved space such that it can > >>only allocate from the allowed ranges. Similarly, it should evict any > >>conflicting nodes when deballooning. > > > >Could you elaborate a bit for above suggestion? > > My expectation was that the dev_priv->gtt.base.vm would contain exactly > two holes after setup (in the mappable and non-mappable range). To do > that you would explicitly reserve everything barred from this client > using a set of drm_mm_reserve_node() > >>> > >>>Essentially a reserve_node implements what you open-code with > >>>insert_node_range right now. > >> > >>Heh, there is a big difference. One inserts exactly where you ask and > >>fails if it conflicts, the other inserts where it feels like within that > >>range. > > Do you mean drm_mm_search_free_in_range_generic() may not get reserve the > exact range we are expecting to? Is this why you'd prefer the > drm_mm_reserve_node()? > > Besides, the ggtt_vm->mm is just initialized right before the ballooning > code in routine i915_gem_setup_global_gtt(), so is there any chance the > range to be partitioned out is already reserved by someone else? Not really, but simply using drm_mm_reserve_node makes the intent much clearer. Also if we go around to runtime ballooning failing hard is probably what we want anyway. > >Well if the the requested size matches the range exactly then it will be > >the same. Which iirc is what's going on here I think. > > > >>>One issue aside with both this and with the PDE reservations for gen7 is > >>>that there are now other thins in the ggtt drm_mm allocator than just gem > >>>objects. Which means our debugfs files are now less useful. > >>> > >>>It might be useful to augment that dumper with one that dumps everything. > >>>We could add a few bits of driver-private tags in drm_mm_node (there's > >>>space) to figure out what kind of object it is. Would be a great follow-up > >>>task. > >> > >>I think moving the other way and making them all objects so that we can > >>tie them into evection and the shrinker, use more interesting allocation > >>strategies, improve integration with debugging etc. > > > >Hm, not sure yet since it will be a lot of work at least. But I guess we > >could untangle the meaning of obj->pin a bit and add an unbind vfunc which > >adds some magic. But there's a lot of stuff attached to a gem bo that just > >doesn't make a lot of sense really, so maybe a better option would be to > >subclass a struct i915_ggtt_vma with special magic. Dunno really. > > Sorry, not sure what these comments are about. :) I'll need time to read the > code. Could you please elaborate a bit? Thanks! We're discussing different options to unify the objects allocated from the ggtt drm_mm. Not terribly relevant for your work directly. > P.S. about the guard page: for now, the current logic reserves a guard page > between different guests and at the very last entry of the whole physical > GTT. the previous comments says: "The CS prefetcher happens everywhere and > so can read from the end of one range into the beginning of another > clients". So I guess the guard page in current patch is necessary, right? tbh I'm not really sure whether we even need the guard page at the very end of the gtt any more on recent platforms. And we definitely don't need any guard page between different allocations on hsw, so I think we can just remove that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 56/89] drm/i915: Gen9 shadowed registers
Damien Lespiau writes:
> From: Zhe Wang
>
> For MMIO registers which are shadowed, force wake is not needed to
> write to these registers.
>
> v2: Rebase on top of nightly (Damien)
>
> Signed-off-by: Zhe Wang
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index f289f4f..ce1214b 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1028,13 +1028,37 @@ chv_write##x(struct drm_i915_private *dev_priv, off_t
> reg, u##x val, bool trace)
> REG_WRITE_FOOTER; \
> }
>
> +static const u32 gen9_shadowed_regs[] = {
> + FORCEWAKE_MEDIA_GEN9,
> + FORCEWAKE_RENDER_GEN9,
> + FORCEWAKE_BLITTER_GEN9,
You might want to move the ring tails first on the list
and forcewake regs to bottom, to reflect the popularity
of access.
> + GEN6_RPNSWREQ,
> + GEN6_RC_VIDEO_FREQ,
> + RING_TAIL(RENDER_RING_BASE),
> + RING_TAIL(GEN6_BSD_RING_BASE),
> + RING_TAIL(VEBOX_RING_BASE),
> + RING_TAIL(BLT_RING_BASE),
> + /* TODO: Other registers are not yet used */
I think we need exec list ones here also, but couldn't find
certain proof. Atleast with bdw we are missing them.
-Mika
> +};
> +
> +static bool is_gen9_shadowed(struct drm_i915_private *dev_priv, u32 reg)
> +{
> + int i;
> + for (i = 0; i < ARRAY_SIZE(gen9_shadowed_regs); i++)
> + if (reg == gen9_shadowed_regs[i])
> + return true;
> +
> + return false;
> +}
> +
> #define __gen9_write(x) \
> static void \
> gen9_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, \
> bool trace) { \
> REG_WRITE_HEADER; \
> if (!NEEDS_FORCE_WAKE((dev_priv), (reg)) || \
> - FORCEWAKE_GEN9_UNCORE_RANGE_OFFSET(reg)) { \
> + FORCEWAKE_GEN9_UNCORE_RANGE_OFFSET(reg) || \
> + is_gen9_shadowed(dev_priv, reg)) { \
> __raw_i915_write##x(dev_priv, reg, val); \
> } else { \
> unsigned fwengine = 0; \
> --
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] drm/i915: Add sysfs entry for reading GPU Timestamp
Reading timestamp register using I915_READ64 returns incorrect value.
Unfortunately, that's how I915_REG_READ ioctl is handling it on x86_64,
resulting in different counter size (we can only get 32 usable bits on
x86_64 vs 36 bits on x86).
Propose new sysfs interface for accessing full 36 bits of timestamp in
architecture independent way (using two consecutive reads).
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_sysfs.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 503847f..30e8e16 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -590,6 +590,23 @@ static struct bin_attribute error_state_attr = {
.write = error_state_write,
};
+static ssize_t timestamp_show(struct device *dev, struct device_attribute
*attr,
+ char *buf)
+{
+ struct drm_minor *dminor = dev_to_drm_minor(dev);
+ struct drm_device *drm_dev = dminor->dev;
+ struct drm_i915_private *dev_priv = drm_dev->dev_private;
+ u64 val;
+ val = I915_READ64_2x32(RING_TIMESTAMP(RENDER_RING_BASE),
RING_TIMESTAMP(RENDER_RING_BASE) + 4);
+ return snprintf(buf, PAGE_SIZE, "%llu\n", val);
+}
+
+static struct device_attribute timestamp_attr = {
+ .attr.name = "timestamp",
+ .attr.mode = S_IRUGO,
+ .show = timestamp_show,
+};
+
void i915_setup_sysfs(struct drm_device *dev)
{
int ret;
@@ -627,6 +644,10 @@ void i915_setup_sysfs(struct drm_device *dev)
&error_state_attr);
if (ret)
DRM_ERROR("error_state sysfs setup failed\n");
+
+ ret = device_create_file(dev->primary->kdev, ×tamp_attr);
+ if (ret)
+ DRM_ERROR("timestamp sysfs setup failed\n");
}
void i915_teardown_sysfs(struct drm_device *dev)
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Avoid re-configure panel on every PSR re-enable.
2014-09-16 20:19 GMT-03:00 Rodrigo Vivi : > The panel has to be reconfigured only when it really loose the power. > The traditional enable/disable sequence already take care of this so we can > minimize the time spend on every re-enable. Reviewed-by: Paulo Zanoni > > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_dp.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 168b3c3..2f0eee5 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1885,10 +1885,7 @@ static void intel_edp_psr_do_enable(struct intel_dp > *intel_dp) > WARN_ON(dev_priv->psr.active); > lockdep_assert_held(&dev_priv->psr.lock); > > - /* Enable PSR on the panel */ > - intel_edp_psr_enable_sink(intel_dp); > - > - /* Enable PSR on the host */ > + /* Enable/Re-enable PSR on the host */ > intel_edp_psr_enable_source(intel_dp); > > dev_priv->psr.active = true; > @@ -1926,6 +1923,9 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp) > I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP | >EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP); > > + /* Enable PSR on the panel */ > + intel_edp_psr_enable_sink(intel_dp); > + > dev_priv->psr.enabled = intel_dp; > unlock: > mutex_unlock(&dev_priv->psr.lock); > -- > 1.9.3 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 52/89] drm/i915/gen9: Disable WM if corresponding latency is 0
On Fri, Sep 19, 2014 at 01:05:02PM +0300, Ville Syrjälä wrote: > > If we're going to be paranoid I think we should disable all higher WM > levels whose latency is lower than any of the lower levels. And I > think we'll want something like dev_priv->wm.max_wm_level instead of > relying on the zero latency tricks. That thing has been on my TODO > list since forever. Can we go step by step? add this patch and then I noted this as a task for post merge work. No sure who will end up doing and and if the sanitazing code can be shared between platforms (probably yes?), but that can wait a bit longer? -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440
Hi, On 09/24/2014 02:53 PM, Pali Rohár wrote: > On Wednesday 24 September 2014 14:04:36 Hans de Goede wrote: >> Hi, >> >> On 09/24/2014 11:14 AM, Pali Rohár wrote: >>> On Wednesday 24 September 2014 10:59:41 Pali Rohár wrote: On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote: > Hi, > > On 09/23/2014 10:44 PM, Pali Rohár wrote: >> On Tuesday 23 September 2014 22:31:31 you wrote: >>> Hi, >>> >>> On 09/23/2014 10:06 PM, Pali Rohár wrote: Hello, after big changes in acpi video/i915 code I cannot change display brightness on my Dell Latitude E6440 with kernel 3.17-rc6. With kernel 3.13 everything worked fine. More information about this problem: For configuring brightness on Dell laptops there are 4 ways: 1) via acpi video driver 2) via dell-laptop driver 3) via i915 drm driver 4) from userspace with special dell SMI call (e.g with program dellLcdBrightness from libsmbios package) Methods 2) and 4) are same, both making special SMI call and Bios handing this request (just 2 is from kernel and 4 from userspace) Method 1) via acpi video driver working, but is not perfect. Driver can be used to change brightness (but only some levels, probably this depends on acpi/DSDT tables), but cannot be used to retrieve current brightness (when BIOS/SMI change brightness acpi driver report old incorrect value). So I prefer dell-laptop driver instead acpi video. Method 3) working even with 3.17-rc6 kernel but because that backlight device exported by i915 is marked as raw, desktop programs prefer to use other devices. Moreover it looks like that methods 1) 2) and 4) just forward request to method 3). So in any cased brightness is changed by i915 drm driver. I'm not sure (correct me if I'm wrong!) but I think that intel i915 drm driver accept changes (file intel_opregion.c) only if acpi function acpi_video_verify_backlight_support() returns true. Function acpi_video_verify_backlight_support() returns true iff: function acpi_video_backlight_support() returns true AND at least one of these functions returns false: acpi_osi_is_win8() acpi_video_use_native_backlight() backlight_device_registered(BACKLIGHT_RAW) On my notebook acpi_osi_is_win8() returns true (as is win8 compliant), backlight_device_registered(BACKLIGHT_RAW) returns true as I'm using intel i915 drm driver with raw backlight device and acpi_video_use_native_backlight() returns true/false depending on "video.use_native_backlight" kernel param. Default is true. So if I want to have working acpi video driver with display brightness support I need to boot kernel with param: "video.use_native_backlight=0". I tested it with kernel 3.17-rc6 and this param really enabled display brightness support via acpi video driver -- which is good. Driver dell-laptop creating backligh device for brightness control only if acpi_video_backlight_support() returns false. There is complicated condition for it and when kernel is booted with "video.use_native_backlight=0" that function returns true. So conclusion is: With current code in kernel 3.17-rc6 it is not possible to control brightness of display with native driver dell-laptop on Dell Latitude E6440 (and probably on others too)!!! And Because laptop is win8 compliant and you create decision to use native driver (instead acpi one) it is not possible to control display brightness without tweeks in kernel cmdline. As I wrote I would rather to use native dell-laptop driver for controlling brightness, but it is not possible. So how to solve this problem? Quick solution would be to set use_native_backlight false for some Dell laptops which means, that acpi video will be used and in this case intel i915 driver will *not* drop backlight change request. Another solution could be to disable check in dell_laptop driver and add use_native_backlight=0 to hooks. But this create two backlight interfaces (which is not good), but only way (for now) how to make dell_laptop working again. Better and maybe only one proper solution would be to teach intel drm i915 driver to not drop backlight chang
Re: [Intel-gfx] [Qemu-devel] [IGDVFIO] [PATCH 1/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
[meta-comment] On 09/24/2014 07:20 AM, Andrew Barnes wrote: > hw/isa/lpc_ich9.c > Your patches came through unthreaded (mail 1 through 8 are all lacking In-Reply-To the message id of 0/8, ). This makes it harder to review. You may want to double-check your git send-email settings, or look for advice at http://wiki.qemu.org/Contribute/SubmitAPatch -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: Add sysfs entry for reading GPU Timestamp
On Wed, Sep 24, 2014 at 03:41:08PM +0200, Michał Winiarski wrote: > Reading timestamp register using I915_READ64 returns incorrect value. > Unfortunately, that's how I915_REG_READ ioctl is handling it on x86_64, > resulting in different counter size (we can only get 32 usable bits on > x86_64 vs 36 bits on x86). > Propose new sysfs interface for accessing full 36 bits of timestamp in > architecture independent way (using two consecutive reads). I've seen lots of patches to avoid fixing the register read. Why? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/10] drm/i915: move checks of intel_crtc_cursor_set_obj() out
2014-09-23 Ville Syrjälä :
> On Mon, Sep 22, 2014 at 07:23:10PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Move checks inside intel_crtc_cursor_set_obj() to
> > intel_check_cursor_plane(), we only use they there so move them out to
> > make the merge of intel_crtc_cursor_set_obj() into
> > intel_check_cursor_plane() easier.
> >
> > This is another step toward the atomic modesetting support and unification
> > of plane operations such pin/unpin of fb objects on i915.
> >
> > v2: take Ville's comment: move crtc_{w,h} assignment a bit down in the
> > code
> >
> > Signed-off-by: Gustavo Padovan
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 61
> >
> > 1 file changed, 41 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 2ef1836..3f37e93 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8373,7 +8373,7 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
> > *crtc,
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > enum pipe pipe = intel_crtc->pipe;
> > - unsigned old_width, stride;
> > + unsigned old_width;
> > uint32_t addr;
> > int ret;
> >
> > @@ -8385,29 +8385,11 @@ static int intel_crtc_cursor_set_obj(struct
> > drm_crtc *crtc,
> > goto finish;
> > }
> >
> > - /* Check for which cursor types we support */
> > - if (!cursor_size_ok(dev, width, height)) {
> > - DRM_DEBUG("Cursor dimension not supported\n");
> > - return -EINVAL;
> > - }
> > -
> > - stride = roundup_pow_of_two(width) * 4;
> > - if (obj->base.size < stride * height) {
> > - DRM_DEBUG_KMS("buffer is too small\n");
> > - return -ENOMEM;
> > - }
> > -
> > /* we only need to pin inside GTT if cursor is non-phy */
> > mutex_lock(&dev->struct_mutex);
> > if (!INTEL_INFO(dev)->cursor_needs_physical) {
> > unsigned alignment;
> >
> > - if (obj->tiling_mode) {
> > - DRM_DEBUG_KMS("cursor cannot be tiled\n");
> > - ret = -EINVAL;
> > - goto fail_locked;
> > - }
> > -
> > /*
> > * Global gtt pte registers are special registers which actually
> > * forward writes to a chunk of system memory. Which means that
> > @@ -11826,16 +11808,55 @@ intel_check_cursor_plane(struct drm_plane *plane,
> > struct intel_plane_state *state)
> > {
> > struct drm_crtc *crtc = state->crtc;
> > + struct drm_device *dev = crtc->dev;
> > struct drm_framebuffer *fb = state->fb;
> > struct drm_rect *dest = &state->dst;
> > struct drm_rect *src = &state->src;
> > const struct drm_rect *clip = &state->clip;
> > + struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > + int crtc_w, crtc_h;
> > + unsigned stride;
> > + int ret;
> >
> > - return drm_plane_helper_check_update(plane, crtc, fb,
> > + ret = drm_plane_helper_check_update(plane, crtc, fb,
> > src, dest, clip,
> > DRM_PLANE_HELPER_NO_SCALING,
> > DRM_PLANE_HELPER_NO_SCALING,
> > true, true, &state->visible);
> > + if (ret)
> > + return ret;
> > +
> > +
> > + /* if we want to turn off the cursor ignore width and height */
> > + if (!obj)
> > + return 0;
> > +
> > + if (fb == crtc->cursor->fb)
> > + return 0;
>
> Hmm. This check needs to be after the cursor/obj size checks. Otherwise
> we wouldn't reject invalid sized cursors when the fb didn't change. I
> suppose we could also just drop this check, but it can still save us from
> doing the tiling check since that can't have changed if the fb hasn't
> changed so maybe it's worth keeping. But either solution is fine by me.
Only if this was a bug before this patch, if you look at the original
intel_commit_cursor_plane() we do two things when the fbs are the same:
intel_crtc_update_cursor();
intel_frontbuffer_flip();
No checks are performed, that is why I put the fbs check before any other
check to make the code as similar as possible to what it was before.
> > +
> > + /* Check for which cursor types we support */
> > + crtc_w = drm_rect_width(&state->orig_dst);
> > + crtc_h = drm_rect_height(&state->orig_dst);
> > + if (!cursor_size_ok(dev, crtc_w, crtc_h)) {
> > + DRM_DEBUG("Cursor dimension not supported\n");
> > + return -EINVAL;
> > + }
> > +
> > + stride = roundup_pow_of_two(crtc_w) * 4;
> > + if (obj->base.size < stride * crtc_h) {
> > + DRM_DEBUG_KMS("buffer is too small\n");
> > + return -ENOMEM;
> > + }
> >
Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440
On Tuesday 23 September 2014 22:31:31 you wrote: > Hi, > > On 09/23/2014 10:06 PM, Pali Rohár wrote: > > Hello, > > > > after big changes in acpi video/i915 code I cannot change > > display brightness on my Dell Latitude E6440 with kernel > > 3.17-rc6. With kernel 3.13 everything worked fine. > > > > More information about this problem: > > > > For configuring brightness on Dell laptops there are 4 ways: > > 1) via acpi video driver > > 2) via dell-laptop driver > > 3) via i915 drm driver > > 4) from userspace with special dell SMI call > > > > (e.g with program dellLcdBrightness from libsmbios > > package) > > > > Methods 2) and 4) are same, both making special SMI call and > > Bios handing this request (just 2 is from kernel and 4 from > > userspace) > > > > Method 1) via acpi video driver working, but is not perfect. > > Driver can be used to change brightness (but only some > > levels, probably this depends on acpi/DSDT tables), but > > cannot be used to retrieve current brightness (when > > BIOS/SMI change brightness acpi driver report old incorrect > > value). So I prefer dell-laptop driver instead acpi video. > > > > Method 3) working even with 3.17-rc6 kernel but because that > > backlight device exported by i915 is marked as raw, desktop > > programs prefer to use other devices. > > > > Moreover it looks like that methods 1) 2) and 4) just > > forward request to method 3). So in any cased brightness is > > changed by i915 drm driver. > > > > I'm not sure (correct me if I'm wrong!) but I think that > > intel i915 drm driver accept changes (file > > intel_opregion.c) only if acpi function > > acpi_video_verify_backlight_support() returns true. > > > > Function acpi_video_verify_backlight_support() returns true > > iff: function acpi_video_backlight_support() returns true > > AND at least one of these functions returns false: > > acpi_osi_is_win8() > > acpi_video_use_native_backlight() > > backlight_device_registered(BACKLIGHT_RAW) > > > > On my notebook acpi_osi_is_win8() returns true (as is win8 > > compliant), backlight_device_registered(BACKLIGHT_RAW) > > returns true as I'm using intel i915 drm driver with raw > > backlight device and acpi_video_use_native_backlight() > > returns true/false depending on > > "video.use_native_backlight" kernel param. Default is true. > > > > So if I want to have working acpi video driver with display > > brightness support I need to boot kernel with param: > > "video.use_native_backlight=0". I tested it with kernel > > 3.17-rc6 and this param really enabled display brightness > > support via acpi video driver -- which is good. > > > > Driver dell-laptop creating backligh device for brightness > > control only if acpi_video_backlight_support() returns > > false. There is complicated condition for it and when > > kernel is booted with "video.use_native_backlight=0" that > > function returns true. > > > > So conclusion is: With current code in kernel 3.17-rc6 it is > > not possible to control brightness of display with native > > driver dell-laptop on Dell Latitude E6440 (and probably on > > others too)!!! > > > > And Because laptop is win8 compliant and you create decision > > to use native driver (instead acpi one) it is not possible > > to control display brightness without tweeks in kernel > > cmdline. > > > > As I wrote I would rather to use native dell-laptop driver > > for controlling brightness, but it is not possible. > > > > So how to solve this problem? > > > > Quick solution would be to set use_native_backlight false > > for some Dell laptops which means, that acpi video will be > > used and in this case intel i915 driver will *not* drop > > backlight change request. > > > > Another solution could be to disable check in dell_laptop > > driver and add use_native_backlight=0 to hooks. But this > > create two backlight interfaces (which is not good), but > > only way (for now) how to make dell_laptop working again. > > > > Better and maybe only one proper solution would be to teach > > intel drm i915 driver to not drop backlight change request > > for Dell laptops (or all??). (This allows to work both acpi > > video and dell_laptop drivers without any change and with > > *any* value in param use_native_backlight). I think that > > problematic code is in function asle_set_backlight() in > > file intel_opregion.c (but I'm not sure). My idea is that > > "drop" event function it is caused by this commit > > 0b9f7d93ca6109048a4eb06332b666b6e29df4fe (but I'm not > > sure). > > > > At least something must be done as I think that I'm not only > > one who has Dell laptop and brightness configuration is > > really important... > > I don't understand your problem, the kernel is selecting the > i915 backlight driver, making that the only one available to > userspace, so the one problem you state with the i915 driver, > that it is "raw" is not an issue, as userspace will pick it > when it is the only one. > It is not only one. Also dell-
Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440
On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote: > Hi, > > On 09/23/2014 10:44 PM, Pali Rohár wrote: > > On Tuesday 23 September 2014 22:31:31 you wrote: > >> Hi, > >> > >> On 09/23/2014 10:06 PM, Pali Rohár wrote: > >>> Hello, > >>> > >>> after big changes in acpi video/i915 code I cannot change > >>> display brightness on my Dell Latitude E6440 with kernel > >>> 3.17-rc6. With kernel 3.13 everything worked fine. > >>> > >>> More information about this problem: > >>> > >>> For configuring brightness on Dell laptops there are 4 > >>> ways: 1) via acpi video driver > >>> 2) via dell-laptop driver > >>> 3) via i915 drm driver > >>> 4) from userspace with special dell SMI call > >>> > >>> (e.g with program dellLcdBrightness from libsmbios > >>> package) > >>> > >>> Methods 2) and 4) are same, both making special SMI call > >>> and Bios handing this request (just 2 is from kernel and > >>> 4 from userspace) > >>> > >>> Method 1) via acpi video driver working, but is not > >>> perfect. Driver can be used to change brightness (but > >>> only some levels, probably this depends on acpi/DSDT > >>> tables), but cannot be used to retrieve current > >>> brightness (when BIOS/SMI change brightness acpi driver > >>> report old incorrect value). So I prefer dell-laptop > >>> driver instead acpi video. > >>> > >>> Method 3) working even with 3.17-rc6 kernel but because > >>> that backlight device exported by i915 is marked as raw, > >>> desktop programs prefer to use other devices. > >>> > >>> Moreover it looks like that methods 1) 2) and 4) just > >>> forward request to method 3). So in any cased brightness > >>> is changed by i915 drm driver. > >>> > >>> I'm not sure (correct me if I'm wrong!) but I think that > >>> intel i915 drm driver accept changes (file > >>> intel_opregion.c) only if acpi function > >>> acpi_video_verify_backlight_support() returns true. > >>> > >>> Function acpi_video_verify_backlight_support() returns > >>> true iff: function acpi_video_backlight_support() returns > >>> true AND at least one of these functions returns false: > >>> acpi_osi_is_win8() > >>> acpi_video_use_native_backlight() > >>> backlight_device_registered(BACKLIGHT_RAW) > >>> > >>> On my notebook acpi_osi_is_win8() returns true (as is win8 > >>> compliant), backlight_device_registered(BACKLIGHT_RAW) > >>> returns true as I'm using intel i915 drm driver with raw > >>> backlight device and acpi_video_use_native_backlight() > >>> returns true/false depending on > >>> "video.use_native_backlight" kernel param. Default is > >>> true. > >>> > >>> So if I want to have working acpi video driver with > >>> display brightness support I need to boot kernel with > >>> param: "video.use_native_backlight=0". I tested it with > >>> kernel 3.17-rc6 and this param really enabled display > >>> brightness support via acpi video driver -- which is > >>> good. > >>> > >>> Driver dell-laptop creating backligh device for brightness > >>> control only if acpi_video_backlight_support() returns > >>> false. There is complicated condition for it and when > >>> kernel is booted with "video.use_native_backlight=0" that > >>> function returns true. > >>> > >>> So conclusion is: With current code in kernel 3.17-rc6 it > >>> is not possible to control brightness of display with > >>> native driver dell-laptop on Dell Latitude E6440 (and > >>> probably on others too)!!! > >>> > >>> And Because laptop is win8 compliant and you create > >>> decision to use native driver (instead acpi one) it is > >>> not possible to control display brightness without tweeks > >>> in kernel cmdline. > >>> > >>> As I wrote I would rather to use native dell-laptop driver > >>> for controlling brightness, but it is not possible. > >>> > >>> So how to solve this problem? > >>> > >>> Quick solution would be to set use_native_backlight false > >>> for some Dell laptops which means, that acpi video will be > >>> used and in this case intel i915 driver will *not* drop > >>> backlight change request. > >>> > >>> Another solution could be to disable check in dell_laptop > >>> driver and add use_native_backlight=0 to hooks. But this > >>> create two backlight interfaces (which is not good), but > >>> only way (for now) how to make dell_laptop working again. > >>> > >>> Better and maybe only one proper solution would be to > >>> teach intel drm i915 driver to not drop backlight change > >>> request for Dell laptops (or all??). (This allows to work > >>> both acpi video and dell_laptop drivers without any > >>> change and with *any* value in param > >>> use_native_backlight). I think that problematic code is > >>> in function asle_set_backlight() in file intel_opregion.c > >>> (but I'm not sure). My idea is that "drop" event function > >>> it is caused by this commit > >>> 0b9f7d93ca6109048a4eb06332b666b6e29df4fe (but I'm not > >>> sure). > >>> > >>> At least something must be done as I think that I'm not > >>> only one who has Dell laptop and brightn
Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440
On Wednesday 24 September 2014 10:59:41 Pali Rohár wrote: > On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote: > > Hi, > > > > On 09/23/2014 10:44 PM, Pali Rohár wrote: > > > On Tuesday 23 September 2014 22:31:31 you wrote: > > >> Hi, > > >> > > >> On 09/23/2014 10:06 PM, Pali Rohár wrote: > > >>> Hello, > > >>> > > >>> after big changes in acpi video/i915 code I cannot > > >>> change display brightness on my Dell Latitude E6440 > > >>> with kernel 3.17-rc6. With kernel 3.13 everything > > >>> worked fine. > > >>> > > >>> More information about this problem: > > >>> > > >>> For configuring brightness on Dell laptops there are 4 > > >>> ways: 1) via acpi video driver > > >>> 2) via dell-laptop driver > > >>> 3) via i915 drm driver > > >>> 4) from userspace with special dell SMI call > > >>> > > >>> (e.g with program dellLcdBrightness from libsmbios > > >>> package) > > >>> > > >>> Methods 2) and 4) are same, both making special SMI call > > >>> and Bios handing this request (just 2 is from kernel and > > >>> 4 from userspace) > > >>> > > >>> Method 1) via acpi video driver working, but is not > > >>> perfect. Driver can be used to change brightness (but > > >>> only some levels, probably this depends on acpi/DSDT > > >>> tables), but cannot be used to retrieve current > > >>> brightness (when BIOS/SMI change brightness acpi driver > > >>> report old incorrect value). So I prefer dell-laptop > > >>> driver instead acpi video. > > >>> > > >>> Method 3) working even with 3.17-rc6 kernel but because > > >>> that backlight device exported by i915 is marked as raw, > > >>> desktop programs prefer to use other devices. > > >>> > > >>> Moreover it looks like that methods 1) 2) and 4) just > > >>> forward request to method 3). So in any cased brightness > > >>> is changed by i915 drm driver. > > >>> > > >>> I'm not sure (correct me if I'm wrong!) but I think that > > >>> intel i915 drm driver accept changes (file > > >>> intel_opregion.c) only if acpi function > > >>> acpi_video_verify_backlight_support() returns true. > > >>> > > >>> Function acpi_video_verify_backlight_support() returns > > >>> true iff: function acpi_video_backlight_support() > > >>> returns true AND at least one of these functions > > >>> returns false: acpi_osi_is_win8() > > >>> acpi_video_use_native_backlight() > > >>> backlight_device_registered(BACKLIGHT_RAW) > > >>> > > >>> On my notebook acpi_osi_is_win8() returns true (as is > > >>> win8 compliant), > > >>> backlight_device_registered(BACKLIGHT_RAW) returns true > > >>> as I'm using intel i915 drm driver with raw backlight > > >>> device and acpi_video_use_native_backlight() returns > > >>> true/false depending on > > >>> "video.use_native_backlight" kernel param. Default is > > >>> true. > > >>> > > >>> So if I want to have working acpi video driver with > > >>> display brightness support I need to boot kernel with > > >>> param: "video.use_native_backlight=0". I tested it with > > >>> kernel 3.17-rc6 and this param really enabled display > > >>> brightness support via acpi video driver -- which is > > >>> good. > > >>> > > >>> Driver dell-laptop creating backligh device for > > >>> brightness control only if > > >>> acpi_video_backlight_support() returns false. There is > > >>> complicated condition for it and when kernel is booted > > >>> with "video.use_native_backlight=0" that function > > >>> returns true. > > >>> > > >>> So conclusion is: With current code in kernel 3.17-rc6 > > >>> it is not possible to control brightness of display > > >>> with native driver dell-laptop on Dell Latitude E6440 > > >>> (and probably on others too)!!! > > >>> > > >>> And Because laptop is win8 compliant and you create > > >>> decision to use native driver (instead acpi one) it is > > >>> not possible to control display brightness without > > >>> tweeks in kernel cmdline. > > >>> > > >>> As I wrote I would rather to use native dell-laptop > > >>> driver for controlling brightness, but it is not > > >>> possible. > > >>> > > >>> So how to solve this problem? > > >>> > > >>> Quick solution would be to set use_native_backlight > > >>> false for some Dell laptops which means, that acpi > > >>> video will be used and in this case intel i915 driver > > >>> will *not* drop backlight change request. > > >>> > > >>> Another solution could be to disable check in > > >>> dell_laptop driver and add use_native_backlight=0 to > > >>> hooks. But this create two backlight interfaces (which > > >>> is not good), but only way (for now) how to make > > >>> dell_laptop working again. > > >>> > > >>> Better and maybe only one proper solution would be to > > >>> teach intel drm i915 driver to not drop backlight change > > >>> request for Dell laptops (or all??). (This allows to > > >>> work both acpi video and dell_laptop drivers without > > >>> any change and with *any* value in param > > >>> use_native_backlight). I think that problematic code is > > >>> in function asle_set_backl
[Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440
Hello, after big changes in acpi video/i915 code I cannot change display brightness on my Dell Latitude E6440 with kernel 3.17-rc6. With kernel 3.13 everything worked fine. More information about this problem: For configuring brightness on Dell laptops there are 4 ways: 1) via acpi video driver 2) via dell-laptop driver 3) via i915 drm driver 4) from userspace with special dell SMI call (e.g with program dellLcdBrightness from libsmbios package) Methods 2) and 4) are same, both making special SMI call and Bios handing this request (just 2 is from kernel and 4 from userspace) Method 1) via acpi video driver working, but is not perfect. Driver can be used to change brightness (but only some levels, probably this depends on acpi/DSDT tables), but cannot be used to retrieve current brightness (when BIOS/SMI change brightness acpi driver report old incorrect value). So I prefer dell-laptop driver instead acpi video. Method 3) working even with 3.17-rc6 kernel but because that backlight device exported by i915 is marked as raw, desktop programs prefer to use other devices. Moreover it looks like that methods 1) 2) and 4) just forward request to method 3). So in any cased brightness is changed by i915 drm driver. I'm not sure (correct me if I'm wrong!) but I think that intel i915 drm driver accept changes (file intel_opregion.c) only if acpi function acpi_video_verify_backlight_support() returns true. Function acpi_video_verify_backlight_support() returns true iff: function acpi_video_backlight_support() returns true AND at least one of these functions returns false: acpi_osi_is_win8() acpi_video_use_native_backlight() backlight_device_registered(BACKLIGHT_RAW) On my notebook acpi_osi_is_win8() returns true (as is win8 compliant), backlight_device_registered(BACKLIGHT_RAW) returns true as I'm using intel i915 drm driver with raw backlight device and acpi_video_use_native_backlight() returns true/false depending on "video.use_native_backlight" kernel param. Default is true. So if I want to have working acpi video driver with display brightness support I need to boot kernel with param: "video.use_native_backlight=0". I tested it with kernel 3.17-rc6 and this param really enabled display brightness support via acpi video driver -- which is good. Driver dell-laptop creating backligh device for brightness control only if acpi_video_backlight_support() returns false. There is complicated condition for it and when kernel is booted with "video.use_native_backlight=0" that function returns true. So conclusion is: With current code in kernel 3.17-rc6 it is not possible to control brightness of display with native driver dell-laptop on Dell Latitude E6440 (and probably on others too)!!! And Because laptop is win8 compliant and you create decision to use native driver (instead acpi one) it is not possible to control display brightness without tweeks in kernel cmdline. As I wrote I would rather to use native dell-laptop driver for controlling brightness, but it is not possible. So how to solve this problem? Quick solution would be to set use_native_backlight false for some Dell laptops which means, that acpi video will be used and in this case intel i915 driver will *not* drop backlight change request. Another solution could be to disable check in dell_laptop driver and add use_native_backlight=0 to hooks. But this create two backlight interfaces (which is not good), but only way (for now) how to make dell_laptop working again. Better and maybe only one proper solution would be to teach intel drm i915 driver to not drop backlight change request for Dell laptops (or all??). (This allows to work both acpi video and dell_laptop drivers without any change and with *any* value in param use_native_backlight). I think that problematic code is in function asle_set_backlight() in file intel_opregion.c (but I'm not sure). My idea is that "drop" event function it is caused by this commit 0b9f7d93ca6109048a4eb06332b666b6e29df4fe (but I'm not sure). At least something must be done as I think that I'm not only one who has Dell laptop and brightness configuration is really important... Thanks. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440
On Wednesday 24 September 2014 14:04:36 Hans de Goede wrote: > Hi, > > On 09/24/2014 11:14 AM, Pali Rohár wrote: > > On Wednesday 24 September 2014 10:59:41 Pali Rohár wrote: > >> On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote: > >>> Hi, > >>> > >>> On 09/23/2014 10:44 PM, Pali Rohár wrote: > On Tuesday 23 September 2014 22:31:31 you wrote: > > Hi, > > > > On 09/23/2014 10:06 PM, Pali Rohár wrote: > >> Hello, > >> > >> after big changes in acpi video/i915 code I cannot > >> change display brightness on my Dell Latitude E6440 > >> with kernel 3.17-rc6. With kernel 3.13 everything > >> worked fine. > >> > >> More information about this problem: > >> > >> For configuring brightness on Dell laptops there are 4 > >> ways: 1) via acpi video driver > >> 2) via dell-laptop driver > >> 3) via i915 drm driver > >> 4) from userspace with special dell SMI call > >> > >> (e.g with program dellLcdBrightness from libsmbios > >> package) > >> > >> Methods 2) and 4) are same, both making special SMI > >> call and Bios handing this request (just 2 is from > >> kernel and 4 from userspace) > >> > >> Method 1) via acpi video driver working, but is not > >> perfect. Driver can be used to change brightness (but > >> only some levels, probably this depends on acpi/DSDT > >> tables), but cannot be used to retrieve current > >> brightness (when BIOS/SMI change brightness acpi driver > >> report old incorrect value). So I prefer dell-laptop > >> driver instead acpi video. > >> > >> Method 3) working even with 3.17-rc6 kernel but because > >> that backlight device exported by i915 is marked as > >> raw, desktop programs prefer to use other devices. > >> > >> Moreover it looks like that methods 1) 2) and 4) just > >> forward request to method 3). So in any cased > >> brightness is changed by i915 drm driver. > >> > >> I'm not sure (correct me if I'm wrong!) but I think > >> that intel i915 drm driver accept changes (file > >> intel_opregion.c) only if acpi function > >> acpi_video_verify_backlight_support() returns true. > >> > >> Function acpi_video_verify_backlight_support() returns > >> true iff: function acpi_video_backlight_support() > >> returns true AND at least one of these functions > >> returns false: acpi_osi_is_win8() > >> acpi_video_use_native_backlight() > >> backlight_device_registered(BACKLIGHT_RAW) > >> > >> On my notebook acpi_osi_is_win8() returns true (as is > >> win8 compliant), > >> backlight_device_registered(BACKLIGHT_RAW) returns true > >> as I'm using intel i915 drm driver with raw backlight > >> device and acpi_video_use_native_backlight() returns > >> true/false depending on > >> "video.use_native_backlight" kernel param. Default is > >> true. > >> > >> So if I want to have working acpi video driver with > >> display brightness support I need to boot kernel with > >> param: "video.use_native_backlight=0". I tested it with > >> kernel 3.17-rc6 and this param really enabled display > >> brightness support via acpi video driver -- which is > >> good. > >> > >> Driver dell-laptop creating backligh device for > >> brightness control only if > >> acpi_video_backlight_support() returns false. There is > >> complicated condition for it and when kernel is booted > >> with "video.use_native_backlight=0" that function > >> returns true. > >> > >> So conclusion is: With current code in kernel 3.17-rc6 > >> it is not possible to control brightness of display > >> with native driver dell-laptop on Dell Latitude E6440 > >> (and probably on others too)!!! > >> > >> And Because laptop is win8 compliant and you create > >> decision to use native driver (instead acpi one) it is > >> not possible to control display brightness without > >> tweeks in kernel cmdline. > >> > >> As I wrote I would rather to use native dell-laptop > >> driver for controlling brightness, but it is not > >> possible. > >> > >> So how to solve this problem? > >> > >> Quick solution would be to set use_native_backlight > >> false for some Dell laptops which means, that acpi > >> video will be used and in this case intel i915 driver > >> will *not* drop backlight change request. > >> > >> Another solution could be to disable check in > >> dell_laptop driver and add use_native_backlight=0 to > >> hooks. But this create two backlight interfaces (which > >> is not good), but only way (for now) how to make > >> dell_laptop working again. > >> > >> Better and maybe only one proper solution would be to > >> teach intel drm i915 driver to not drop backlight > >> change request for Dell laptops (o
Re: [Intel-gfx] [PATCH] drm/i915: Make sure PSR is ready for been re-enabled.
2014-09-17 14:23 GMT-03:00 Rodrigo Vivi :
> Let's make sure PSR is propperly disabled before to re-enabled it.
>
> According to Spec, after disabled PSR CTL, the Idle state might occur
> up to 24ms, that is one full frame time (1/refresh rate),
> plus SRD exit training time (max of 6ms),
> plus SRD aux channel handshake (max of 1.5ms).
>
> v2: The 24ms above takes in account 16ms for refresh rate on 60Hz mode.
> However
> on low frequency modes this can take longer. So let's use 50ms for safeness.
Well, the patch looks correct, but it doesn't seem to take into
consideration the fact that we already waited for 100ms before
triggering psr.work. Also, we do the wait that you added with psr.lock
locked, so we could be blocking user-space from doing other stuff for
the whole 50ms, and that's an eternity and a half.
So maybe we should tune the schedule_delayed_work() call at
intel_edp_psr_flush() based on the calculation you did above (or just
keep the 100ms, since it seems to be above the timeout for any modes
bigger than 11Hz). And then when we're inside the work function, we
should just I915_READ(EDP_PSR_STATUS_CTL) - instead of doing
wait_for() -, and in case PSR is not idle yet, there's a huge
probability that waiting for more 50ms won't really help. We could
also try to reschedule psr.work to be triggered again in the future in
case the bits we want are not ready, but by doing this we also risk
rescheduling psr.work forever.
More bikeshed on the timeout thing: can't we try discover the exact
amount of time we need to sleep based on the refresh rate? We could
try to look at the mode structure...
tl;dr: if you remove the wait_for() call and keep just the I915_READ,
I can give a R-B tag, but other patches could be acceptable too.
>
> So if something went wrong PSR will be disabled until next full
> enable/disable setup.
>
> Cc: Daniel Vetter
> Cc: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_dp.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2f0eee5..2e8c544 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1885,6 +1885,17 @@ static void intel_edp_psr_do_enable(struct intel_dp
> *intel_dp)
> WARN_ON(dev_priv->psr.active);
> lockdep_assert_held(&dev_priv->psr.lock);
>
> + /* We have to make sure PSR is ready for re-enable
> +* otherwise it keeps disabled until next full enable/disable cycle.
> +* PSR might take some time to get fully disabled
> +* and be ready for re-enable.
> +*/
> + if (wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev)) &
> + EDP_PSR_STATUS_STATE_MASK) == 0, 50)) {
> + DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n");
> + return;
> + }
> +
> /* Enable/Re-enable PSR on the host */
> intel_edp_psr_enable_source(intel_dp);
>
> --
> 1.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA
Many thanks, Chris. I'll incorporate your feedback into v2. On 09/23/2014 11:04 PM, Chris Wilson wrote: > On Tue, Sep 23, 2014 at 03:50:25PM -0700, Joe Konno wrote: >> From: Joe Konno >> >> Improper integer division-- truncated rather than rounded-- in the > That's confusing. It reads that you are converting to using truncated, > rather than to rounding. > >> scale() function causes actual_brightness != brightness. This (partial) >> work-around should be sufficient for a majority of use-cases, but it is >> by no means a complete solution. >> >> TODO: Determine how best to scale "user" values to "hw" values, and >> vice-versa, when the ranges are of different sizes. That would be a >> buggy scenario even with this work-around. >> >> The issue was introduced in the following (v3.17-rc1) commit: >> >> 6dda730 drm/i915: respect the VBT minimum backlight brightness >> >> Signed-off-by: Joe Konno >> --- >> drivers/gpu/drm/i915/intel_panel.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_panel.c >> b/drivers/gpu/drm/i915/intel_panel.c >> index f17ada3..c40f837 100644 >> --- a/drivers/gpu/drm/i915/intel_panel.c >> +++ b/drivers/gpu/drm/i915/intel_panel.c >> @@ -421,7 +421,8 @@ static uint32_t scale(uint32_t source_val, >> /* avoid overflows */ >> target_val = (uint64_t)(source_val - source_min) * >> (target_max - target_min); >> -do_div(target_val, source_max - source_min); >> +target_val = (target_val + ((source_max - source_min) / 2)) / >> +(source_max - source_min); > target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min); > >> target_val += target_min; >> >> return target_val; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
From: Joe Konno Improper truncated integer division in the scale() function causes actual_brightness != brightness. This (partial) work-around should be sufficient for a majority of use-cases, but it is by no means a complete solution. TODO: Determine how best to scale "user" values to "hw" values, and vice-versa, when the ranges are of different sizes. That would be a buggy scenario even with this work-around. The issue was introduced in the following (v3.17-rc1) commit: 6dda730 drm/i915: respect the VBT minimum backlight brightness v2: (thanks to Chris Wilson) clarify commit message, use rounded division macro Signed-off-by: Joe Konno --- drivers/gpu/drm/i915/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index f17ada3..dcdfbb3 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val, /* avoid overflows */ target_val = (uint64_t)(source_val - source_min) * (target_max - target_min); - do_div(target_val, source_max - source_min); + target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min); target_val += target_min; return target_val; -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable pixel replicated modes on BDW and HSW.
On 09/24/2014 01:51 AM, Daniel Vetter wrote:
On Tue, Sep 23, 2014 at 11:06:56AM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Haswell and later silicon has added a new pixel replication register
to the pipe timings for each transcoder. Now in addition to the
DPLL_A_MD register for the pixel clock double, we also need to write to
the TRANS_MULT_n (0x6002c) register to double the pixel data. Writing
to the DPLL only double the pixel clock.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/i915_reg.h |3 +++
drivers/gpu/drm/i915/intel_display.c |6 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 15c0eaa..7c078d9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2431,6 +2431,7 @@ enum punit_power_well {
#define _PIPEASRC 0x6001c
#define _BCLRPAT_A0x60020
#define _VSYNCSHIFT_A 0x60028
+#define _MULTIPLY_A0x6002c
/* Pipe B timing regs */
#define _HTOTAL_B 0x61000
@@ -2442,6 +2443,7 @@ enum punit_power_well {
#define _PIPEBSRC 0x6101c
#define _BCLRPAT_B0x61020
#define _VSYNCSHIFT_B 0x61028
+#define _MULTIPLY_B0x6102c
#define TRANSCODER_A_OFFSET 0x6
#define TRANSCODER_B_OFFSET 0x61000
@@ -2462,6 +2464,7 @@ enum punit_power_well {
#define BCLRPAT(trans) _TRANSCODER2(trans, _BCLRPAT_A)
#define VSYNCSHIFT(trans) _TRANSCODER2(trans, _VSYNCSHIFT_A)
#define PIPESRC(trans) _TRANSCODER2(trans, _PIPEASRC)
+#define MULTIPLY(trans) _TRANSCODER2(trans, _MULTIPLY_A)
MULTIPLY is a bit generic and doesn't even match Bspec lingo. I'd just go
with PIPE_MULTI instead to match Bspec and give it a nice PIPE_ prefix.
/* HSW+ eDP PSR registers */
#define EDP_PSR_BASE(dev) (IS_HASWELL(dev) ? 0x64800 :
0x6f800)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c092ff4..e58fcde 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4152,6 +4152,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
intel_set_pipe_timings(intel_crtc);
+ I915_WRITE(MULTIPLY(intel_crtc->config.cpu_transcoder),
This register is per-pipe, so needs to be indexed with intel_crtc->pipe.
Same below.
The MULTIPLY Macro calls the _TRANSCODER2 MACRO which already indexes
the register based on intel_crtc->pipe. This should be all that's required.
-Clint
Otherwise this loooks good.
-Daniel
+ intel_crtc->config.pixel_multiplier - 1);
+
if (intel_crtc->config.has_pch_encoder) {
intel_cpu_transcoder_set_m_n(intel_crtc,
&intel_crtc->config.fdi_m_n, NULL);
@@ -7811,7 +7814,8 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->ips_enabled = hsw_crtc_supports_ips(crtc) &&
(I915_READ(IPS_CTL) & IPS_ENABLE);
- pipe_config->pixel_multiplier = 1;
+ pipe_config->pixel_multiplier =
+ I915_READ(MULTIPLY(pipe_config->cpu_transcoder)) + 1;
return true;
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
Hi, On 09/24/2014 05:54 PM, Joe Konno wrote: > From: Joe Konno > > Improper truncated integer division in the scale() function causes > actual_brightness != brightness. This (partial) work-around should be > sufficient for a majority of use-cases, but it is by no means a complete > solution. > > TODO: Determine how best to scale "user" values to "hw" values, and > vice-versa, when the ranges are of different sizes. That would be a > buggy scenario even with this work-around. > > The issue was introduced in the following (v3.17-rc1) commit: > > 6dda730 drm/i915: respect the VBT minimum backlight brightness > > v2: (thanks to Chris Wilson) clarify commit message, use rounded division > macro I wonder why do scaling at all, why not simply shift hw_min - hw_max range to 0 - (hw_max - hw_min) range and set max_brightness as seen by userspace to (hw_max - hw_min) ? Regards, Hans > > Signed-off-by: Joe Konno > --- > drivers/gpu/drm/i915/intel_panel.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index f17ada3..dcdfbb3 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val, > /* avoid overflows */ > target_val = (uint64_t)(source_val - source_min) * > (target_max - target_min); > - do_div(target_val, source_max - source_min); > + target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min); > target_val += target_min; > > return target_val; > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/core-stuff
On Wed, Sep 24, 2014 at 6:24 AM, Daniel Vetter wrote: > Hi Dave, > > Just noticed that you've picked up the header rework stuff already, so > I've rebased that out again. Otherwise just two stragglers from the vblank > rework and the universal cursor planes locking fix. Plus sprinkling > container_of all over fbdev emulation from Fabian. I thought it was questionable whether these were desired... the pattern of casting between structs that contain others as bases is a pretty common one, and container_of just makes it harder to read. Did the discussion end in a way that concluded the opposite? I might have missed it. -ilia > > Aside: I only have just 1 fix for drm-next atm for i915 and not terribly > serious. So will probably only send you a pull for it when the merge > window opens or something more serious shows up. > > Cheers, Daniel > > > The following changes since commit d743ecf360637d489a3ba81a268f574359149601: > > drm/doc: Fixup drm_irq kerneldoc includes. (2014-09-24 11:43:47 +1000) > > are available in the git repository at: > > git://anongit.freedesktop.org/drm-intel tags/topic/core-stuff-2014-09-24 > > for you to fetch changes up to ee0d68ab5f0997a500fdf90924a58e787b216292: > > drm/udl: use container_of to resolve udl_fbdev from drm_fb_helper > (2014-09-24 12:09:28 +0200) > > > Daniel Vetter (2): > drm: Fixup locking for universal cursor planes > drm: Improve debug output for drm_wait_one_vblank > > Fabian Frederick (9): > drm/cirrus: use container_of to resolve cirrus_fbdev from drm_fb_helper > drm/mgag200: use container_of to resolve mga_fbdev from drm_fb_helper > drm/radeon: use container_of to resolve radeon_fbdev from drm_fb_helper > drm/nouveau: use container_of to resolve nouveau_fbdev from > drm_fb_helper > drm/nouveau: use container_of to resolve nouveau_plane from drm_plane > drm/qxl: use container_of to resolve qxl_fbdev from drm_fb_helper > drm/gma500: use container_of to resolve psb_fbdev from drm_fb_helper > drm/ast: use container_of to resolve ast_fbdev from drm_fb_helper > drm/udl: use container_of to resolve udl_fbdev from drm_fb_helper > > Mario Kleiner (1): > drm: Don't update vblank timestamp when the counter didn't change > > drivers/gpu/drm/ast/ast_fb.c | 3 +- > drivers/gpu/drm/cirrus/cirrus_fbdev.c | 3 +- > drivers/gpu/drm/drm_crtc.c | 51 > -- > drivers/gpu/drm/drm_irq.c | 7 ++-- > drivers/gpu/drm/gma500/framebuffer.c | 3 +- > drivers/gpu/drm/mgag200/mgag200_fb.c | 3 +- > drivers/gpu/drm/nouveau/dispnv04/overlay.c | 15 ++--- > drivers/gpu/drm/nouveau/nouveau_fbcon.c| 3 +- > drivers/gpu/drm/qxl/qxl_fb.c | 3 +- > drivers/gpu/drm/radeon/radeon_fb.c | 3 +- > drivers/gpu/drm/udl/udl_fb.c | 3 +- > 11 files changed, 65 insertions(+), 32 deletions(-) > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Qemu-devel] [IGDVFIO] [PATCH 1/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
On 09/24/2014 07:20 AM, Andrew Barnes wrote:
> hw/isa/lpc_ich9.c
>
> this patch adds:
> * debug output, if enabled
> * enforces correct intel config, if enabled. (unsure if this is needed)
> * redirects some PCI Config to host
> * uses hosts LPC device id
>
> patch
> -
>
Stylistic review (I'll leave the content review to someone more
knowledgeable)
> @@ -46,6 +47,16 @@
> #include "exec/address-spaces.h"
> #include "sysemu/sysemu.h"
>
> +/* #define DEBUG_LPC */
> +#ifdef DEBUG_LPC
> +# define LPC_DPRINTF(format, ...) print("LPC: " format, ## __VA_ARGS__)
Most debugging prints to stderr, not stdout. Even better is using a
tracepoint instead of a macro.
> +#else
> +# define LPC_DPRINTF(format, ...) do {} while (0)
There has also been work to make sure that debugging printfs are still
compiled for the sake of format checking, although optimized out by if
(0), in the normal case, so as to avoid bit-rot in the debug format
strings when not enabled.
>
> +/* BEWARE: only set this if you are passing IGD through to guest */
> +/* TODO: detect IGD automatically */
> +static bool IGD_PASSTHROUGH = true;
all-caps names are usually reserved for macros and constants, not variables.
> +
> /* chipset configuration register
> * to access chipset configuration registers, pci_[sg]et_{byte, word, long}
> * are used.
> @@ -425,6 +440,9 @@ static void ich9_lpc_config_write(PCIDevice *d,
> ICH9LPCState *lpc = ICH9_LPC_DEVICE(d);
> uint32_t rbca_old = pci_get_long(d->config + ICH9_LPC_RCBA);
>
> +LPC_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, 0x%x, len=0x%x)\n", __func__,
> +, 00, PCI_SLOT(d->devfn),PCI_FUNC(d->devfn), addr,
Style: space after comma.
> +static uint32_t ich9_lpc_config_read(PCIDevice *d,
> + uint32_t addr, int len)
> +{
> +uint32_t val;
> +if (IGD_PASSTHROUGH)
> +{
> + if (ranges_overlap(addr, len, 0x2c, 2) || /* SVID - Subsystem Vendor
> Identification */
Indentation is off. May be related to how you pasted the patch in your
mailer, rather than a flaw in your actual patch.
> +ranges_overlap(addr, len, 0x2e, 2)) /* SID - Subsystem Identificaion
> */
> + {
Style - we prefer the { on the same line as the if. Running your
patches through scripts/checkpatch.pl will catch many of the style issues.
> + val =
> host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FUNC(d->devfn),addr,len);
space after comma
> + }
> + else
> + {
> + goto defaultread;
> + }
More indentation damage.
+
> +/* For a UN-MODIFIED guest, the following 3 registers need to be read
> from the host.
> + * alternatively, modify i915_drv.c, intel_detect_pch, add a check for
> + * PCI_DEVICE_ID_INTEL_ICH9_8 and copy the settings from the PCH you
> desire */
> +k->vendor_id = host_pci_read_config(0,0x1f,0,0x00,2);
> +k->device_id = host_pci_read_config(0,0x1f,0,0x02,2);
> +//k->revision = host_pci_read_config(0,0x1f,0,0x08,1);
/**/ comments are preferred over //; also, it's good to explain with a
comment why you are adding dead code.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/27] drm/i915: use pm_runtime_last_busy_and_autosuspend helper
Use the new pm_runtime_last_busy_and_autosuspend helper instead of open coding the same code Signed-off-by: Vinod Koul --- drivers/gpu/drm/i915/intel_pm.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 40c1229..1ec9b8d 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -6729,8 +6729,7 @@ void intel_runtime_pm_put(struct drm_i915_private *dev_priv) if (!HAS_RUNTIME_PM(dev)) return; - pm_runtime_mark_last_busy(device); - pm_runtime_put_autosuspend(device); + pm_runtime_last_busy_and_autosuspend(device); } void intel_init_runtime_pm(struct drm_i915_private *dev_priv) -- 1.7.0.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper
This patch series adds a simple macro pm_runtime_last_busy_and_autosuspend() which invokes pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend() sequentially. Then we do a tree wide update of current patterns which are present. As evident from log below this pattern is frequent in the kernel. This series can be found at git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git topic/pm_runtime_last_busy_and_autosuspend Fengguang's kbuild has tested it so it shouldn't break things for anyone. Barring one patch (explictyly mentioned in its changelog) rest are simple replacements. If all are okay, this should be merged thru PM tree as it depends on macro addition. Subhransu S. Prusty (1): PM: Add helper pm_runtime_last_busy_and_autosuspend() Vinod Koul (26): dmaengine: ste_dma: use pm_runtime_last_busy_and_autosuspend helper extcon: arizona: use pm_runtime_last_busy_and_autosuspend helper drm/i915: use pm_runtime_last_busy_and_autosuspend helper drm/nouveau: use pm_runtime_last_busy_and_autosuspend helper drm/radeon: use pm_runtime_last_busy_and_autosuspend helper vga_switcheroo: use pm_runtime_last_busy_and_autosuspend helper i2c: designware: use pm_runtime_last_busy_and_autosuspend helper i2c: omap: use pm_runtime_last_busy_and_autosuspend helper i2c: qup: use pm_runtime_last_busy_and_autosuspend helper mfd: ab8500-gpadc: use pm_runtime_last_busy_and_autosuspend helper mfd: arizona: use pm_runtime_last_busy_and_autosuspend helper mei: use pm_runtime_last_busy_and_autosuspend helper mmc: use pm_runtime_last_busy_and_autosuspend helper mmc: mmci: use pm_runtime_last_busy_and_autosuspend helper mmc: omap_hsmmc: use pm_runtime_last_busy_and_autosuspend helper mmc: sdhci-pxav3: use pm_runtime_last_busy_and_autosuspend helper mmc: sdhci: use pm_runtime_last_busy_and_autosuspend helper NFC: trf7970a: use pm_runtime_last_busy_and_autosuspend helper pm2301-charger: use pm_runtime_last_busy_and_autosuspend helper spi: omap2-mcspi: use pm_runtime_last_busy_and_autosuspend helper spi: orion: use pm_runtime_last_busy_and_autosuspend helper spi: ti-qspi: use pm_runtime_last_busy_and_autosuspend helper spi: core: use pm_runtime_last_busy_and_autosuspend helper tty: serial: omap: use pm_runtime_last_busy_and_autosuspend helper usb: musb: omap2430: use pm_runtime_last_busy_and_autosuspend helper video: fbdev: use pm_runtime_last_busy_and_autosuspend helper Documentation/power/runtime_pm.txt |4 ++ drivers/dma/ste_dma40.c | 30 - drivers/extcon/extcon-arizona.c |6 +-- drivers/gpu/drm/i915/intel_pm.c |3 +- drivers/gpu/drm/nouveau/nouveau_connector.c |3 +- drivers/gpu/drm/nouveau/nouveau_drm.c |9 +--- drivers/gpu/drm/radeon/radeon_connectors.c | 15 ++ drivers/gpu/drm/radeon/radeon_drv.c |5 +- drivers/gpu/drm/radeon/radeon_kms.c |6 +-- drivers/gpu/vga/vga_switcheroo.c|7 +-- drivers/i2c/busses/i2c-designware-core.c|3 +- drivers/i2c/busses/i2c-omap.c |6 +-- drivers/i2c/busses/i2c-qup.c|3 +- drivers/mfd/ab8500-gpadc.c |6 +-- drivers/mfd/arizona-irq.c |3 +- drivers/misc/mei/client.c | 12 ++ drivers/mmc/core/core.c |3 +- drivers/mmc/host/mmci.c | 12 ++ drivers/mmc/host/omap_hsmmc.c | 19 ++--- drivers/mmc/host/sdhci-pxav3.c |6 +-- drivers/mmc/host/sdhci.c|3 +- drivers/nfc/trf7970a.c |3 +- drivers/power/pm2301_charger.c |3 +- drivers/spi/spi-omap2-mcspi.c |9 +--- drivers/spi/spi-orion.c |3 +- drivers/spi/spi-ti-qspi.c |5 +- drivers/spi/spi.c |6 +-- drivers/tty/serial/omap-serial.c| 60 +-- drivers/usb/musb/omap2430.c |6 +-- drivers/video/fbdev/auo_k190x.c |9 +--- include/linux/pm_runtime.h |6 +++ 31 files changed, 97 insertions(+), 177 deletions(-) Thanks -- ~Vinod ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, a couple of small fixes for 3.17 still. BR, Jani. The following changes since commit 0f33be009b89d2268e94194dc4fd01a7851b6d51: Linux 3.17-rc6 (2014-09-21 15:43:02 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-09-24 for you to fetch changes up to c84db77010877da6c5da119868ed54c43d59e726: drm/i915/hdmi: fix hdmi audio state readout (2014-09-23 16:36:12 +0300) Brad Volkin (1): drm/i915: Don't leak command parser tables on suspend/resume Jani Nikula (1): drm/i915/hdmi: fix hdmi audio state readout drivers/gpu/drm/i915/i915_cmd_parser.c | 12 +++- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- 2 files changed, 8 insertions(+), 6 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
On Wed, 24 Sep 2014, Hans de Goede wrote: > Hi, > > On 09/24/2014 05:54 PM, Joe Konno wrote: >> From: Joe Konno >> >> Improper truncated integer division in the scale() function causes >> actual_brightness != brightness. This (partial) work-around should be >> sufficient for a majority of use-cases, but it is by no means a complete >> solution. >> >> TODO: Determine how best to scale "user" values to "hw" values, and >> vice-versa, when the ranges are of different sizes. That would be a >> buggy scenario even with this work-around. >> >> The issue was introduced in the following (v3.17-rc1) commit: >> >> 6dda730 drm/i915: respect the VBT minimum backlight brightness >> >> v2: (thanks to Chris Wilson) clarify commit message, use rounded division >> macro > > I wonder why do scaling at all, why not simply shift hw_min - hw_max range > to 0 - (hw_max - hw_min) range and set max_brightness as seen by userspace > to (hw_max - hw_min) ? Mostly in preparation for a future where we expose an arbitrary range, say 0..100 or 0..255 to the userspace. BR, Jani. > > Regards, > > Hans > > >> >> Signed-off-by: Joe Konno >> --- >> drivers/gpu/drm/i915/intel_panel.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_panel.c >> b/drivers/gpu/drm/i915/intel_panel.c >> index f17ada3..dcdfbb3 100644 >> --- a/drivers/gpu/drm/i915/intel_panel.c >> +++ b/drivers/gpu/drm/i915/intel_panel.c >> @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val, >> /* avoid overflows */ >> target_val = (uint64_t)(source_val - source_min) * >> (target_max - target_min); >> -do_div(target_val, source_max - source_min); >> +target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min); >> target_val += target_min; >> >> return target_val; >> > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 04/11] drm/i915: move check of intel_crtc_cursor_set_obj() out
From: Gustavo Padovan
Move check inside intel_crtc_cursor_set_obj() to
intel_check_cursor_plane(), we only use it there so move them out to
make the merge of intel_crtc_cursor_set_obj() into
intel_check_cursor_plane() easier.
This is another step toward the atomic modesetting support and unification
of plane operations such pin/unpin of fb objects on i915.
v2: take Ville's comment: move crtc_{w,h} assignment a bit down in the
code
v3: take Ville's comment: kept only the restructuring changes, the rest of
the code was moved to a separated patch since it is a bug fix (we weren't
checking sizes when the fb was the same)
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 20be2ed..f91a5b0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11928,9 +11928,6 @@ intel_check_cursor_plane(struct drm_plane *plane,
if (!obj)
return 0;
- if (fb == crtc->cursor->fb)
- return 0;
-
/* Check for which cursor types we support */
crtc_w = drm_rect_width(&state->orig_dst);
crtc_h = drm_rect_height(&state->orig_dst);
@@ -11945,6 +11942,9 @@ intel_check_cursor_plane(struct drm_plane *plane,
return -ENOMEM;
}
+ if (fb == crtc->cursor->fb)
+ return 0;
+
/* we only need to pin inside GTT if cursor is non-phy */
mutex_lock(&dev->struct_mutex);
if (!INTEL_INFO(dev)->cursor_needs_physical && obj->tiling_mode) {
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 05/11] drm/i915: remove intel_crtc_cursor_set_obj()
From: Gustavo Padovan
Merge it into the plane update_plane() callback and make other
users use the update_plane() functions instead.
The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
and merge both paths into one.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 221 +--
1 file changed, 106 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f91a5b0..a583abd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8457,109 +8457,6 @@ static bool cursor_size_ok(struct drm_device *dev,
return true;
}
-static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
-struct drm_i915_gem_object *obj,
-uint32_t width, uint32_t height)
-{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc->pipe;
- unsigned old_width;
- uint32_t addr;
- int ret;
-
- /* if we want to turn off the cursor ignore width and height */
- if (!obj) {
- DRM_DEBUG_KMS("cursor off\n");
- addr = 0;
- mutex_lock(&dev->struct_mutex);
- goto finish;
- }
-
- /* we only need to pin inside GTT if cursor is non-phy */
- mutex_lock(&dev->struct_mutex);
- if (!INTEL_INFO(dev)->cursor_needs_physical) {
- unsigned alignment;
-
- /*
-* Global gtt pte registers are special registers which actually
-* forward writes to a chunk of system memory. Which means that
-* there is no risk that the register values disappear as soon
-* as we call intel_runtime_pm_put(), so it is correct to wrap
-* only the pin/unpin/fence and not more.
-*/
- intel_runtime_pm_get(dev_priv);
-
- /* Note that the w/a also requires 2 PTE of padding following
-* the bo. We currently fill all unused PTE with the shadow
-* page and so we should always have valid PTE following the
-* cursor preventing the VT-d warning.
-*/
- alignment = 0;
- if (need_vtd_wa(dev))
- alignment = 64*1024;
-
- ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
- if (ret) {
- DRM_DEBUG_KMS("failed to move cursor bo into the
GTT\n");
- intel_runtime_pm_put(dev_priv);
- goto fail_locked;
- }
-
- ret = i915_gem_object_put_fence(obj);
- if (ret) {
- DRM_DEBUG_KMS("failed to release fence for cursor");
- intel_runtime_pm_put(dev_priv);
- goto fail_unpin;
- }
-
- addr = i915_gem_obj_ggtt_offset(obj);
-
- intel_runtime_pm_put(dev_priv);
- } else {
- int align = IS_I830(dev) ? 16 * 1024 : 256;
- ret = i915_gem_object_attach_phys(obj, align);
- if (ret) {
- DRM_DEBUG_KMS("failed to attach phys object\n");
- goto fail_locked;
- }
- addr = obj->phys_handle->busaddr;
- }
-
- finish:
- if (intel_crtc->cursor_bo) {
- if (!INTEL_INFO(dev)->cursor_needs_physical)
-
i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo);
- }
-
- i915_gem_track_fb(intel_crtc->cursor_bo, obj,
- INTEL_FRONTBUFFER_CURSOR(pipe));
- mutex_unlock(&dev->struct_mutex);
-
- old_width = intel_crtc->cursor_width;
-
- intel_crtc->cursor_addr = addr;
- intel_crtc->cursor_bo = obj;
- intel_crtc->cursor_width = width;
- intel_crtc->cursor_height = height;
-
- if (intel_crtc->active) {
- if (old_width != width)
- intel_update_watermarks(crtc);
- intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL);
- }
-
- intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe));
-
- return 0;
-fail_unpin:
- i915_gem_object_unpin_from_display_plane(obj);
-fail_locked:
- mutex_unlock(&dev->struct_mutex);
- return ret;
-}
-
static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
u16 *blue, uint32_t start, uint32_t size)
{
@@ -11897,7 +11794,8 @@ intel_cursor_plane_disable(struct drm_plane *plane)
BUG_ON(!plane->crtc);
- return intel_crt
[Intel-gfx] [PATCH v3 03/11] drm/i915: Fix not checking cursor and object sizes
From: Gustavo Padovan
Even if the fb is the same we should still check if the sizes are
valid to be set.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 61
1 file changed, 41 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b1c2dbf..20be2ed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8465,7 +8465,7 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
- unsigned old_width, stride;
+ unsigned old_width;
uint32_t addr;
int ret;
@@ -8477,29 +8477,11 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
goto finish;
}
- /* Check for which cursor types we support */
- if (!cursor_size_ok(dev, width, height)) {
- DRM_DEBUG("Cursor dimension not supported\n");
- return -EINVAL;
- }
-
- stride = roundup_pow_of_two(width) * 4;
- if (obj->base.size < stride * height) {
- DRM_DEBUG_KMS("buffer is too small\n");
- return -ENOMEM;
- }
-
/* we only need to pin inside GTT if cursor is non-phy */
mutex_lock(&dev->struct_mutex);
if (!INTEL_INFO(dev)->cursor_needs_physical) {
unsigned alignment;
- if (obj->tiling_mode) {
- DRM_DEBUG_KMS("cursor cannot be tiled\n");
- ret = -EINVAL;
- goto fail_locked;
- }
-
/*
* Global gtt pte registers are special registers which actually
* forward writes to a chunk of system memory. Which means that
@@ -11923,16 +11905,55 @@ intel_check_cursor_plane(struct drm_plane *plane,
struct intel_plane_state *state)
{
struct drm_crtc *crtc = state->crtc;
+ struct drm_device *dev = crtc->dev;
struct drm_framebuffer *fb = state->fb;
struct drm_rect *dest = &state->dst;
struct drm_rect *src = &state->src;
const struct drm_rect *clip = &state->clip;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ int crtc_w, crtc_h;
+ unsigned stride;
+ int ret;
- return drm_plane_helper_check_update(plane, crtc, fb,
+ ret = drm_plane_helper_check_update(plane, crtc, fb,
src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
true, true, &state->visible);
+ if (ret)
+ return ret;
+
+
+ /* if we want to turn off the cursor ignore width and height */
+ if (!obj)
+ return 0;
+
+ if (fb == crtc->cursor->fb)
+ return 0;
+
+ /* Check for which cursor types we support */
+ crtc_w = drm_rect_width(&state->orig_dst);
+ crtc_h = drm_rect_height(&state->orig_dst);
+ if (!cursor_size_ok(dev, crtc_w, crtc_h)) {
+ DRM_DEBUG("Cursor dimension not supported\n");
+ return -EINVAL;
+ }
+
+ stride = roundup_pow_of_two(crtc_w) * 4;
+ if (obj->base.size < stride * crtc_h) {
+ DRM_DEBUG_KMS("buffer is too small\n");
+ return -ENOMEM;
+ }
+
+ /* we only need to pin inside GTT if cursor is non-phy */
+ mutex_lock(&dev->struct_mutex);
+ if (!INTEL_INFO(dev)->cursor_needs_physical && obj->tiling_mode) {
+ DRM_DEBUG_KMS("cursor cannot be tiled\n");
+ ret = -EINVAL;
+ }
+ mutex_unlock(&dev->struct_mutex);
+
+ return ret;
}
static int
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 07/11] drm: add helper to get crtc timings
From: Gustavo Padovan
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
Suggested-by: Ville Syrjälä
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_crtc.c | 20 +---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
include/drm/drm_crtc.h | 2 ++
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b702106..7c0bf9f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2490,6 +2490,17 @@ int drm_mode_set_config_internal(struct drm_mode_set
*set)
}
EXPORT_SYMBOL(drm_mode_set_config_internal);
+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+ int *hdisplay, int *vdisplay)
+{
+ struct drm_display_mode adjusted = *mode;
+
+ drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE);
+ *hdisplay = adjusted.crtc_hdisplay;
+ *vdisplay = adjusted.crtc_vdisplay;
+}
+EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+
/**
* drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
* CRTC viewport
@@ -2510,13 +2521,8 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
hdisplay = mode->hdisplay;
vdisplay = mode->vdisplay;
- if (drm_mode_is_stereo(mode)) {
- struct drm_display_mode adjusted = *mode;
-
- drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE);
- hdisplay = adjusted.crtc_hdisplay;
- vdisplay = adjusted.crtc_vdisplay;
- }
+ if (drm_mode_is_stereo(mode))
+ drm_crtc_get_hv_timing(mode, &hdisplay, &vdisplay);
if (crtc->invert_dimensions)
swap(hdisplay, vdisplay);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3cb092c..dfe9ad5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10154,9 +10154,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
* computation to clearly distinguish it from the adjusted mode, which
* can be changed by the connectors in the below retry loop.
*/
- drm_mode_set_crtcinfo(&pipe_config->requested_mode, CRTC_STEREO_DOUBLE);
- pipe_config->pipe_src_w = pipe_config->requested_mode.crtc_hdisplay;
- pipe_config->pipe_src_h = pipe_config->requested_mode.crtc_vdisplay;
+ drm_crtc_get_hv_timing(&pipe_config->requested_mode,
+ &pipe_config->pipe_src_w,
+ &pipe_config->pipe_src_h);
encoder_retry:
/* Ensure the port clock defaults are reset when retrying. */
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..9b2f6b5 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -950,6 +950,8 @@ extern int drm_plane_init(struct drm_device *dev,
extern void drm_plane_cleanup(struct drm_plane *plane);
extern unsigned int drm_plane_index(struct drm_plane *plane);
extern void drm_plane_force_disable(struct drm_plane *plane);
+extern void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+ int *hdisplay, int *vdisplay);
extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
int x, int y,
const struct drm_display_mode *mode,
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 10/11] drm/i915: use intel_fb_obj() macros to assign gem objects
From: Gustavo Padovan Use the macros makes the code cleaner and it also checks for a NULL fb. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_sprite.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 8e5445b..5cb7321 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1029,8 +1029,7 @@ intel_check_sprite_plane(struct drm_plane *plane, struct intel_crtc *intel_crtc = to_intel_crtc(state->crtc); struct intel_plane *intel_plane = to_intel_plane(plane); struct drm_framebuffer *fb = state->fb; - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); - struct drm_i915_gem_object *obj = intel_fb->obj; + struct drm_i915_gem_object *obj = intel_fb_obj(fb); int crtc_x, crtc_y; unsigned int crtc_w, crtc_h; uint32_t src_x, src_y, src_w, src_h; @@ -1232,9 +1231,8 @@ intel_commit_sprite_plane(struct drm_plane *plane, struct intel_plane *intel_plane = to_intel_plane(plane); enum pipe pipe = intel_crtc->pipe; struct drm_framebuffer *fb = state->fb; - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); - struct drm_i915_gem_object *obj = intel_fb->obj; - struct drm_i915_gem_object *old_obj = intel_plane->obj; + struct drm_i915_gem_object *obj = intel_fb_obj(fb); + struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); int crtc_x, crtc_y; unsigned int crtc_w, crtc_h; uint32_t src_x, src_y, src_w, src_h; -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 02/11] drm/i915: remove leftover from pre-universal planes days
From: Gustavo Padovan
Now that universal planes are in place we don't need this plane unref on
failures.
Suggested-by: Ville Syrjälä
Signed-off-by: Gustavo Padovan
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 966b9af..b1c2dbf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8457,13 +8457,6 @@ static bool cursor_size_ok(struct drm_device *dev,
return true;
}
-/*
- * intel_crtc_cursor_set_obj - Set cursor to specified GEM object
- *
- * Note that the object's reference will be consumed if the update fails. If
- * the update succeeds, the reference of the old object (if any) will be
- * consumed.
- */
static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
struct drm_i915_gem_object *obj,
uint32_t width, uint32_t height)
@@ -8493,8 +8486,7 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
stride = roundup_pow_of_two(width) * 4;
if (obj->base.size < stride * height) {
DRM_DEBUG_KMS("buffer is too small\n");
- ret = -ENOMEM;
- goto fail;
+ return -ENOMEM;
}
/* we only need to pin inside GTT if cursor is non-phy */
@@ -8583,8 +8575,6 @@ fail_unpin:
i915_gem_object_unpin_from_display_plane(obj);
fail_locked:
mutex_unlock(&dev->struct_mutex);
-fail:
- drm_gem_object_unreference_unlocked(&obj->base);
return ret;
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 01/11] drm/i915: Merge of visible and !visible paths for primary planes
From: Gustavo Padovan
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
v2: take Ville's comments:
- remove unnecessary plane check
- move mutex lock to inside the conditional
- make the pin fail message a debug one
- add a fixme for the fastboot hack
- call intel_frontbuffer_flip() after FBC update
v3: take more Ville's comments:
- fold update code under if (intel_crtc->active), and do the
visible/!visible split inside.
- check ret inside the same conditional we assign it
v4: don't use intel_enable_primary_hw_plane(), the primary_enabled
check inside will break page flips
v5: take more Ville's comments:
- set primary_enabled to true and add BDW hack
- unify if (old_fb) and if (old_fb != fb)
v6: take more Ville's comments:
- make was_primary bool and fix its check
- add the BDW vblank wait comment
Suggested-by: Ville Syrjälä
Signed-off-by: Gustavo Padovan
Reviewed-by: Ville Syrjälä
fixup! drm/i915: Merge of visible and !visible paths for primary planes
---
drivers/gpu/drm/i915/intel_display.c | 147 ++-
1 file changed, 92 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b8488a8..966b9af 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11676,12 +11676,23 @@ intel_check_primary_plane(struct drm_plane *plane,
struct drm_rect *dest = &state->dst;
struct drm_rect *src = &state->src;
const struct drm_rect *clip = &state->clip;
+ int ret;
- return drm_plane_helper_check_update(plane, crtc, fb,
+ ret = drm_plane_helper_check_update(plane, crtc, fb,
src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
false, true, &state->visible);
+ if (ret)
+ return ret;
+
+ /* no fb bound */
+ if (state->visible && !fb) {
+ DRM_ERROR("No FB bound\n");
+ return -EINVAL;
+ }
+
+ return 0;
}
static int
@@ -11693,6 +11704,8 @@ intel_commit_primary_plane(struct drm_plane *plane,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_framebuffer *old_fb = plane->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
struct intel_plane *intel_plane = to_intel_plane(plane);
@@ -11701,76 +11714,100 @@ intel_commit_primary_plane(struct drm_plane *plane,
intel_crtc_wait_for_pending_flips(crtc);
- /*
-* If clipping results in a non-visible primary plane, we'll disable
-* the primary plane. Note that this is a bit different than what
-* happens if userspace explicitly disables the plane by passing fb=0
-* because plane->fb still gets set and pinned.
-*/
- if (!state->visible) {
+ if (intel_crtc_has_pending_flip(crtc)) {
+ DRM_ERROR("pipe is still busy with an old pageflip\n");
+ return -EBUSY;
+ }
+
+ if (plane->fb != fb) {
mutex_lock(&dev->struct_mutex);
+ ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
+ if (ret == 0)
+ i915_gem_track_fb(old_obj, obj,
+ INTEL_FRONTBUFFER_PRIMARY(pipe));
+ mutex_unlock(&dev->struct_mutex);
+ if (ret != 0) {
+ DRM_DEBUG_KMS("pin & fence failed\n");
+ return ret;
+ }
+ }
+
+ crtc->primary->fb = fb;
+ crtc->x = src->x1;
+ crtc->y = src->y1;
+
+ intel_plane->crtc_x = state->orig_dst.x1;
+ intel_plane->crtc_y = state->orig_dst.y1;
+ intel_plane->crtc_w = drm_rect_width(&state->orig_dst);
+ intel_plane->crtc_h = drm_rect_height(&state->orig_dst);
+ intel_plane->src_x = state->orig_src.x1;
+ intel_plane->src_y = state->orig_src.y1;
+ intel_plane->src_w = drm_rect_width(&state->orig_src);
+ intel_plane->src_h = drm_rect_height(&state->orig_src);
+ intel_plane->obj = obj;
+ if (intel_crtc->active) {
/*
-* Try to pin the new fb first so that we can bail out if we
-* fail.
+* FBC does not work on some platforms for rotated
+
[Intel-gfx] [PATCH v3 06/11] drm/i915: split intel_crtc_page_flip() into check() and commit()
From: Daniel Stone
Start the work of splitting the intel_crtc_page_flip() for later use
by the atomic modesetting API.
Signed-off-by: Daniel Stone
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 51 ++--
1 file changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a583abd..3cb092c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9641,23 +9641,11 @@ void intel_check_page_flip(struct drm_device *dev, int
pipe)
spin_unlock(&dev->event_lock);
}
-static int intel_crtc_page_flip(struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event,
- uint32_t page_flip_flags)
+static int intel_crtc_check_page_flip(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb)
{
struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_framebuffer *old_fb = crtc->primary->fb;
- struct drm_i915_gem_object *obj = intel_fb_obj(fb);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc->pipe;
- struct intel_unpin_work *work;
- struct intel_engine_cs *ring;
- int ret;
-
- //trigger software GT busyness calculation
- gen8_flip_interrupt(dev);
/*
* drm_mode_page_flip_ioctl() should already catch this, but double
@@ -9680,6 +9668,27 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
fb->pitches[0] != crtc->primary->fb->pitches[0]))
return -EINVAL;
+ return 0;
+}
+
+static int intel_crtc_commit_page_flip(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_pending_vblank_event *event,
+ uint32_t page_flip_flags)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_framebuffer *old_fb = crtc->primary->fb;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct intel_unpin_work *work;
+ struct intel_engine_cs *ring;
+ int ret;
+
+ /* trigger software GT busyness calculation */
+ gen8_flip_interrupt(dev);
+
if (i915_terminally_wedged(&dev_priv->gpu_error))
goto out_hang;
@@ -9823,6 +9832,20 @@ out_hang:
return ret;
}
+static int intel_crtc_page_flip(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_pending_vblank_event *event,
+ uint32_t page_flip_flags)
+{
+ int ret;
+
+ ret = intel_crtc_check_page_flip(crtc, fb);
+ if (ret)
+ return ret;
+
+ return intel_crtc_commit_page_flip(crtc, fb, event, page_flip_flags);
+}
+
static struct drm_crtc_helper_funcs intel_helper_funcs = {
.mode_set_base_atomic = intel_pipe_set_base_atomic,
.load_lut = intel_crtc_load_lut,
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 11/11] drm/i915: remove intel_pipe_set_base()
From: Gustavo Padovan
After some refactor intel_primary_plane_setplane() does the same
as intel_pipe_set_base() so we can get rid of it and replace the calls
with intel_primary_plane_setplane().
v2: take Ville's comments:
- get the right arguments for update_plane()
- use drm_crtc_get_hv_timing()
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 89
1 file changed, 18 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9dd4952..f7c2e5f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2857,74 +2857,6 @@ static void intel_update_pipe_size(struct intel_crtc
*crtc)
crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
}
-static int
-intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *fb)
-{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc->pipe;
- struct drm_framebuffer *old_fb = crtc->primary->fb;
- struct drm_i915_gem_object *obj = intel_fb_obj(fb);
- struct drm_i915_gem_object *old_obj = intel_fb_obj(old_fb);
- int ret;
-
- if (intel_crtc_has_pending_flip(crtc)) {
- DRM_ERROR("pipe is still busy with an old pageflip\n");
- return -EBUSY;
- }
-
- /* no fb bound */
- if (!fb) {
- DRM_ERROR("No FB bound\n");
- return 0;
- }
-
- if (intel_crtc->plane > INTEL_INFO(dev)->num_pipes) {
- DRM_ERROR("no plane for crtc: plane %c, num_pipes %d\n",
- plane_name(intel_crtc->plane),
- INTEL_INFO(dev)->num_pipes);
- return -EINVAL;
- }
-
- mutex_lock(&dev->struct_mutex);
- ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
- if (ret == 0)
- i915_gem_track_fb(old_obj, obj,
- INTEL_FRONTBUFFER_PRIMARY(pipe));
- mutex_unlock(&dev->struct_mutex);
- if (ret != 0) {
- DRM_ERROR("pin & fence failed\n");
- return ret;
- }
-
- intel_update_pipe_size(intel_crtc);
-
- dev_priv->display.update_primary_plane(crtc, fb, x, y);
-
- if (intel_crtc->active)
- intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
-
- crtc->primary->fb = fb;
- crtc->x = x;
- crtc->y = y;
-
- if (old_fb) {
- if (intel_crtc->active && old_fb != fb)
- intel_wait_for_vblank(dev, intel_crtc->pipe);
- mutex_lock(&dev->struct_mutex);
- intel_unpin_fb_obj(old_obj);
- mutex_unlock(&dev->struct_mutex);
- }
-
- mutex_lock(&dev->struct_mutex);
- intel_update_fbc(dev);
- mutex_unlock(&dev->struct_mutex);
-
- return 0;
-}
-
static void intel_fdi_normal_train(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
@@ -9681,6 +9613,8 @@ static int intel_crtc_commit_page_flip(struct drm_crtc
*crtc,
struct drm_framebuffer *old_fb = crtc->primary->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_plane *primary = crtc->primary;
+ struct intel_plane *intel_plane = to_intel_plane(primary);
enum pipe pipe = intel_crtc->pipe;
struct intel_unpin_work *work;
struct intel_engine_cs *ring;
@@ -9822,7 +9756,15 @@ free_work:
if (ret == -EIO) {
out_hang:
intel_crtc_wait_for_pending_flips(crtc);
- ret = intel_pipe_set_base(crtc, crtc->x, crtc->y, fb);
+ ret = primary->funcs->update_plane(primary, crtc, fb,
+ intel_plane->crtc_x,
+ intel_plane->crtc_y,
+ intel_plane->crtc_h,
+ intel_plane->crtc_w,
+ intel_plane->src_x,
+ intel_plane->src_y,
+ intel_plane->src_h,
+ intel_plane->src_w);
if (ret == 0 && event) {
spin_lock_irq(&dev->event_lock);
drm_send_vblank_event(dev, pipe, event);
@@ -11359,11 +11301,16 @@ static int intel_crtc_set_config(struct drm_mode_set
*set)
set->x, set->y, set->fb);
} else if (config->fb_changed) {
struct intel_crtc *intel_crtc = to_intel_crtc(set->crtc);
+ stru
[Intel-gfx] [PATCH v3 09/11] drm/i915: create a prepare phase for sprite plane updates
From: Gustavo Padovan
take out pin_fb code so the commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_sprite.c | 63 +++--
1 file changed, 40 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 750b634..8e5445b 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1189,34 +1189,18 @@ intel_check_sprite_plane(struct drm_plane *plane,
}
static int
-intel_commit_sprite_plane(struct drm_plane *plane,
- struct intel_plane_state *state)
+intel_prepare_sprite_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
{
struct drm_device *dev = plane->dev;
struct drm_crtc *crtc = state->crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_plane *intel_plane = to_intel_plane(plane);
enum pipe pipe = intel_crtc->pipe;
struct drm_framebuffer *fb = state->fb;
- struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
- struct drm_i915_gem_object *obj = intel_fb->obj;
- struct drm_i915_gem_object *old_obj = intel_plane->obj;
- int crtc_x, crtc_y;
- unsigned int crtc_w, crtc_h;
- uint32_t src_x, src_y, src_w, src_h;
- struct drm_rect *dst = &state->dst;
- const struct drm_rect *clip = &state->clip;
- bool primary_enabled;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
int ret;
- /*
-* If the sprite is completely covering the primary plane,
-* we can disable the primary and save power.
-*/
- primary_enabled = !drm_rect_equals(dst, clip) ||
colorkey_enabled(intel_plane);
- WARN_ON(!primary_enabled && !state->visible && intel_crtc->active);
-
-
if (old_obj != obj) {
mutex_lock(&dev->struct_mutex);
@@ -1235,6 +1219,36 @@ intel_commit_sprite_plane(struct drm_plane *plane,
return ret;
}
+ return 0;
+}
+
+static void
+intel_commit_sprite_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
+{
+ struct drm_device *dev = plane->dev;
+ struct drm_crtc *crtc = state->crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_framebuffer *fb = state->fb;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb->obj;
+ struct drm_i915_gem_object *old_obj = intel_plane->obj;
+ int crtc_x, crtc_y;
+ unsigned int crtc_w, crtc_h;
+ uint32_t src_x, src_y, src_w, src_h;
+ struct drm_rect *dst = &state->dst;
+ const struct drm_rect *clip = &state->clip;
+ bool primary_enabled;
+
+ /*
+* If the sprite is completely covering the primary plane,
+* we can disable the primary and save power.
+*/
+ primary_enabled = !drm_rect_equals(dst, clip) ||
colorkey_enabled(intel_plane);
+ WARN_ON(!primary_enabled && !state->visible && intel_crtc->active);
+
intel_plane->crtc_x = state->orig_dst.x1;
intel_plane->crtc_y = state->orig_dst.y1;
intel_plane->crtc_w = drm_rect_width(&state->orig_dst);
@@ -1295,8 +1309,6 @@ intel_commit_sprite_plane(struct drm_plane *plane,
intel_unpin_fb_obj(old_obj);
mutex_unlock(&dev->struct_mutex);
}
-
- return 0;
}
static int
@@ -1336,7 +1348,12 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
if (ret)
return ret;
- return intel_commit_sprite_plane(plane, &state);
+ ret = intel_prepare_sprite_plane(plane, &state);
+ if (ret)
+ return ret;
+
+ intel_commit_sprite_plane(plane, &state);
+ return 0;
}
static int
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 08/11] drm/i915: create a prepare step for primary planes updates
From: Gustavo Padovan
Take out the pin_fb code so commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dfe9ad5..9dd4952 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11588,20 +11588,16 @@ intel_check_primary_plane(struct drm_plane *plane,
}
static int
-intel_commit_primary_plane(struct drm_plane *plane,
- struct intel_plane_state *state)
+intel_prepare_primary_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
{
struct drm_crtc *crtc = state->crtc;
struct drm_framebuffer *fb = state->fb;
struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
- struct drm_framebuffer *old_fb = plane->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
- struct intel_plane *intel_plane = to_intel_plane(plane);
- struct drm_rect *src = &state->src;
int ret;
intel_crtc_wait_for_pending_flips(crtc);
@@ -11611,7 +11607,7 @@ intel_commit_primary_plane(struct drm_plane *plane,
return -EBUSY;
}
- if (plane->fb != fb) {
+ if (old_obj != obj) {
mutex_lock(&dev->struct_mutex);
ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
if (ret == 0)
@@ -11624,6 +11620,25 @@ intel_commit_primary_plane(struct drm_plane *plane,
}
}
+ return 0;
+}
+
+static void
+intel_commit_primary_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
+{
+ struct drm_crtc *crtc = state->crtc;
+ struct drm_framebuffer *fb = state->fb;
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_framebuffer *old_fb = plane->fb;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct drm_rect *src = &state->src;
+
crtc->primary->fb = fb;
crtc->x = src->x1;
crtc->y = src->y1;
@@ -11700,8 +11715,6 @@ intel_commit_primary_plane(struct drm_plane *plane,
intel_unpin_fb_obj(old_obj);
mutex_unlock(&dev->struct_mutex);
}
-
- return 0;
}
static int
@@ -11742,6 +11755,10 @@ intel_primary_plane_setplane(struct drm_plane *plane,
struct drm_crtc *crtc,
if (ret)
return ret;
+ ret = intel_prepare_primary_plane(plane, &state);
+ if (ret)
+ return ret;
+
intel_commit_primary_plane(plane, &state);
return 0;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Jani Nikula > Sent: Wednesday, September 24, 2014 10:08 AM > To: Hans de Goede; Joe Konno; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2 > > On Wed, 24 Sep 2014, Hans de Goede wrote: > > Hi, > > > > On 09/24/2014 05:54 PM, Joe Konno wrote: > >> From: Joe Konno > >> > >> Improper truncated integer division in the scale() function causes > >> actual_brightness != brightness. This (partial) work-around should be > >> sufficient for a majority of use-cases, but it is by no means a complete > >> solution. > >> > >> TODO: Determine how best to scale "user" values to "hw" values, and > >> vice-versa, when the ranges are of different sizes. That would be a > >> buggy scenario even with this work-around. > >> > >> The issue was introduced in the following (v3.17-rc1) commit: > >> > >> 6dda730 drm/i915: respect the VBT minimum backlight brightness > >> > >> v2: (thanks to Chris Wilson) clarify commit message, use rounded division > >> macro > > > > I wonder why do scaling at all, why not simply shift hw_min - hw_max range > > to 0 - (hw_max - hw_min) range and set max_brightness as seen by userspace > > to (hw_max - hw_min) ? > > Mostly in preparation for a future where we expose an arbitrary range, > say 0..100 or 0..255 to the userspace. > The problem with this scaling method is that scaling from user level to hw level and back to user level is ambiguous since there isn't a 1:1 mapping between the user range and the hw range. On the other hand, this patch does fix a bug in the currently used method (scaling). That, at least, is an improvement nonetheless. U. Artie > BR, > Jani. > > > > > > Regards, > > > > Hans > > > > > >> > >> Signed-off-by: Joe Konno > >> --- > >> drivers/gpu/drm/i915/intel_panel.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_panel.c > >> b/drivers/gpu/drm/i915/intel_panel.c > >> index f17ada3..dcdfbb3 100644 > >> --- a/drivers/gpu/drm/i915/intel_panel.c > >> +++ b/drivers/gpu/drm/i915/intel_panel.c > >> @@ -421,7 +421,7 @@ static uint32_t scale(uint32_t source_val, > >>/* avoid overflows */ > >>target_val = (uint64_t)(source_val - source_min) * > >>(target_max - target_min); > >> - do_div(target_val, source_max - source_min); > >> + target_val = DIV_ROUND_CLOSEST(target_val, source_max - source_min); > >>target_val += target_min; > >> > >>return target_val; > >> > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Jani Nikula, Intel Open Source Technology Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Cleanup pre prod workarounds
Oh just noticed we duplicated effort on this.. [5/5] drm/i915/bdw: Remove BDW preproduction W/As until C stepping. After this land -nightly I rebase my series on top. On Wed, Sep 24, 2014 at 1:41 AM, Daniel Vetter wrote: > On Tue, Sep 23, 2014 at 02:48:47PM +0300, Jani Nikula wrote: > > On Tue, 23 Sep 2014, Daniel Vetter wrote: > > > On Fri, Sep 19, 2014 at 08:49:06PM +0300, Ville Syrjälä wrote: > > >> On Fri, Sep 19, 2014 at 08:05:26PM +0300, Mika Kuoppala wrote: > > >> > as these have been fixed in production hw and hurt performance > > >> > if applied. > > >> > > > >> > v2: adjust requested ring space (Ville) > > >> > > > >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83482 > > >> > Tested-by: zhoujian > > >> > Signed-off-by: Mika Kuoppala > > >> > > >> Documentation agrees that these can go. > > >> Reviewed-by: Ville Syrjälä > > > > > > Cc: sta...@vger.kernel.org imo. Jani? > > > > This depends on > > > > commit 86d7f23842f1bce3ab5e8c8d0c676112bbc4c99b > > Author: Arun Siluvery > > Date: Tue Aug 26 14:44:50 2014 +0100 > > > > drm/i915/bdw: Apply workarounds in render ring init function > > > > which brought the problem to daylight to begin with. That's not in > > 3.17-rc6. I'm not sure if that one has additional dependencies, but > > perhaps a combined backport without an intermediate broken step is > > plausible. > > > > In any case I don't think this is something we want to rush for 3.17 > > now, since a release is imminent, so it'll be 3.18. Adding cc: stable is > > up to you, but do note the size is beyond stable rules. > > Hm right, so a patch for drm-intel-next-fixes (first one even!). I'll > leave out the cc: stable since backporting all the register wa stuff is a > pile of patches ... > -Daniel > > > > > > > BR, > > Jani. > > > > > > > > > -Daniel > > > > > >> > > >> > --- > > >> > drivers/gpu/drm/i915/intel_ringbuffer.c | 15 ++- > > >> > 1 file changed, 2 insertions(+), 13 deletions(-) > > >> > > > >> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > > >> > index 681ea86..679a3c7 100644 > > >> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > > >> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > > >> > @@ -707,7 +707,7 @@ static int bdw_init_workarounds(struct > intel_engine_cs *ring) > > >> > * update the number of dwords required based on the > > >> > * actual number of workarounds applied > > >> > */ > > >> > -ret = intel_ring_begin(ring, 24); > > >> > +ret = intel_ring_begin(ring, 18); > > >> > if (ret) > > >> > return ret; > > >> > > > >> > @@ -722,19 +722,8 @@ static int bdw_init_workarounds(struct > intel_engine_cs *ring) > > >> > intel_ring_emit_wa(ring, GEN7_ROW_CHICKEN2, > > >> > > _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE)); > > >> > > > >> > -/* > > >> > - * This GEN8_CENTROID_PIXEL_OPT_DIS W/A is only needed for > > >> > - * pre-production hardware > > >> > - */ > > >> > intel_ring_emit_wa(ring, HALF_SLICE_CHICKEN3, > > >> > - > _MASKED_BIT_ENABLE(GEN8_CENTROID_PIXEL_OPT_DIS > > >> > - | > GEN8_SAMPLER_POWER_BYPASS_DIS)); > > >> > - > > >> > -intel_ring_emit_wa(ring, GEN7_HALF_SLICE_CHICKEN1, > > >> > - > _MASKED_BIT_ENABLE(GEN7_SINGLE_SUBSCAN_DISPATCH_ENABLE)); > > >> > - > > >> > -intel_ring_emit_wa(ring, COMMON_SLICE_CHICKEN2, > > >> > - > _MASKED_BIT_ENABLE(GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE)); > > >> > + > _MASKED_BIT_ENABLE(GEN8_SAMPLER_POWER_BYPASS_DIS)); > > >> > > > >> > /* Use Force Non-Coherent whenever executing a 3D context. > This is a > > >> > * workaround for for a possible hang in the unlikely > event a TLB > > >> > -- > > >> > 1.9.1 > > >> > > >> -- > > >> Ville Syrjälä > > >> Intel OTC > > >> ___ > > >> Intel-gfx mailing list > > >> Intel-gfx@lists.freedesktop.org > > >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > > -- > > Jani Nikula, Intel Open Source Technology Center > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/core-stuff
On Wed, Sep 24, 2014 at 6:24 PM, Ilia Mirkin wrote: > On Wed, Sep 24, 2014 at 6:24 AM, Daniel Vetter wrote: >> Hi Dave, >> >> Just noticed that you've picked up the header rework stuff already, so >> I've rebased that out again. Otherwise just two stragglers from the vblank >> rework and the universal cursor planes locking fix. Plus sprinkling >> container_of all over fbdev emulation from Fabian. > > I thought it was questionable whether these were desired... the > pattern of casting between structs that contain others as bases is a > pretty common one, and container_of just makes it harder to read. Did > the discussion end in a way that concluded the opposite? I might have > missed it. I like them since you can employ gcc to check mundane stuff for you. And container_of is so massively established in the kernel (with list_head alone) that I don't think any serious kernel hacker has problem's reading it. Alan Cox complained a bit a bit on imo elitist grounds so until someone goes on record with an official Nack I think they're worth it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440
On Wednesday 24 September 2014 16:34:21 Hans de Goede wrote: > Hi, > > On 09/24/2014 02:53 PM, Pali Rohár wrote: > > On Wednesday 24 September 2014 14:04:36 Hans de Goede wrote: > >> Hi, > >> > >> On 09/24/2014 11:14 AM, Pali Rohár wrote: > >>> On Wednesday 24 September 2014 10:59:41 Pali Rohár wrote: > On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote: > > Hi, > > > > On 09/23/2014 10:44 PM, Pali Rohár wrote: > >> On Tuesday 23 September 2014 22:31:31 you wrote: > >>> Hi, > >>> > >>> On 09/23/2014 10:06 PM, Pali Rohár wrote: > Hello, > > after big changes in acpi video/i915 code I cannot > change display brightness on my Dell Latitude E6440 > with kernel 3.17-rc6. With kernel 3.13 everything > worked fine. > > More information about this problem: > > For configuring brightness on Dell laptops there are > 4 ways: 1) via acpi video driver > 2) via dell-laptop driver > 3) via i915 drm driver > 4) from userspace with special dell SMI call > > (e.g with program dellLcdBrightness from > libsmbios package) > > Methods 2) and 4) are same, both making special SMI > call and Bios handing this request (just 2 is from > kernel and 4 from userspace) > > Method 1) via acpi video driver working, but is not > perfect. Driver can be used to change brightness (but > only some levels, probably this depends on acpi/DSDT > tables), but cannot be used to retrieve current > brightness (when BIOS/SMI change brightness acpi > driver report old incorrect value). So I prefer > dell-laptop driver instead acpi video. > > Method 3) working even with 3.17-rc6 kernel but > because that backlight device exported by i915 is > marked as raw, desktop programs prefer to use other > devices. > > Moreover it looks like that methods 1) 2) and 4) just > forward request to method 3). So in any cased > brightness is changed by i915 drm driver. > > I'm not sure (correct me if I'm wrong!) but I think > that intel i915 drm driver accept changes (file > intel_opregion.c) only if acpi function > acpi_video_verify_backlight_support() returns true. > > Function acpi_video_verify_backlight_support() > returns true iff: function > acpi_video_backlight_support() returns true AND at > least one of these functions returns false: > acpi_osi_is_win8() > acpi_video_use_native_backlight() > backlight_device_registered(BACKLIGHT_RAW) > > On my notebook acpi_osi_is_win8() returns true (as is > win8 compliant), > backlight_device_registered(BACKLIGHT_RAW) returns > true as I'm using intel i915 drm driver with raw > backlight device and > acpi_video_use_native_backlight() returns true/false > depending on > "video.use_native_backlight" kernel param. Default is > true. > > So if I want to have working acpi video driver with > display brightness support I need to boot kernel with > param: "video.use_native_backlight=0". I tested it > with kernel 3.17-rc6 and this param really enabled > display brightness support via acpi video driver -- > which is good. > > Driver dell-laptop creating backligh device for > brightness control only if > acpi_video_backlight_support() returns false. There > is complicated condition for it and when kernel is > booted with "video.use_native_backlight=0" that > function returns true. > > So conclusion is: With current code in kernel > 3.17-rc6 it is not possible to control brightness of > display with native driver dell-laptop on Dell > Latitude E6440 (and probably on others too)!!! > > And Because laptop is win8 compliant and you create > decision to use native driver (instead acpi one) it > is not possible to control display brightness > without tweeks in kernel cmdline. > > As I wrote I would rather to use native dell-laptop > driver for controlling brightness, but it is not > possible. > > So how to solve this problem? > > Quick solution would be to set use_native_backlight > false for some Dell laptops which means, that acpi > video will be used and in this case intel i915 driver > will *not* drop backlight change request. > > Another solution could be to disable check in > dell_laptop dri
Re: [Intel-gfx] [PATCH 04/27] drm/i915: use pm_runtime_last_busy_and_autosuspend helper
On Wed, Sep 24, 2014 at 09:44:54PM +0530, Vinod Koul wrote: > Use the new pm_runtime_last_busy_and_autosuspend helper instead of open > coding the same code > > Signed-off-by: Vinod Koul Ack to merge through whatever tree is appropriate for this. Or tell me when I should pick this up for drm-intel. -Daniel > --- > drivers/gpu/drm/i915/intel_pm.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 40c1229..1ec9b8d 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -6729,8 +6729,7 @@ void intel_runtime_pm_put(struct drm_i915_private > *dev_priv) > if (!HAS_RUNTIME_PM(dev)) > return; > > - pm_runtime_mark_last_busy(device); > - pm_runtime_put_autosuspend(device); > + pm_runtime_last_busy_and_autosuspend(device); > } > > void intel_init_runtime_pm(struct drm_i915_private *dev_priv) > -- > 1.7.0.4 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [IGDVFIO] [PATCH 1/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
On Wed, 2014-09-24 at 14:20 +0100, Andrew Barnes wrote:
> hw/isa/lpc_ich9.c
>
> this patch adds:
> * debug output, if enabled
> * enforces correct intel config, if enabled. (unsure if this is needed)
> * redirects some PCI Config to host
> * uses hosts LPC device id
>
> patch
> -
>
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index b846d81..e6a7fbd 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -6,6 +6,7 @@
> * Isaku Yamahata
> * VA Linux Systems Japan K.K.
> * Copyright (C) 2012 Jason Baron
> + * Copyright (C) 2014 Andrew Barnes IGD Support
> *
> * This is based on piix_pci.c, but heavily modified.
> *
> @@ -46,6 +47,16 @@
> #include "exec/address-spaces.h"
> #include "sysemu/sysemu.h"
>
> +/* #define DEBUG_LPC */
> +#ifdef DEBUG_LPC
> +# define LPC_DPRINTF(format, ...) print("LPC: " format, ## __VA_ARGS__)
> +#else
> +# define LPC_DPRINTF(format, ...) do {} while (0)
> +#endif
> +
> +/* For intel-spec conforming config */
> +#define CORRECT_CONFIG
> +
> static int ich9_lpc_sci_irq(ICH9LPCState *lpc);
>
>
> /*/
> @@ -53,6 +64,10 @@ static int ich9_lpc_sci_irq(ICH9LPCState *lpc);
>
> static void ich9_lpc_reset(DeviceState *qdev);
>
> +/* BEWARE: only set this if you are passing IGD through to guest */
> +/* TODO: detect IGD automatically */
> +static bool IGD_PASSTHROUGH = true;
> +
> /* chipset configuration register
> * to access chipset configuration registers, pci_[sg]et_{byte, word, long}
> * are used.
> @@ -425,6 +440,9 @@ static void ich9_lpc_config_write(PCIDevice *d,
> ICH9LPCState *lpc = ICH9_LPC_DEVICE(d);
> uint32_t rbca_old = pci_get_long(d->config + ICH9_LPC_RCBA);
>
> +LPC_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, 0x%x, len=0x%x)\n", __func__,
> +, 00, PCI_SLOT(d->devfn),PCI_FUNC(d->devfn), addr,
> val, len);
> +
> pci_default_write_config(d, addr, val, len);
> if (ranges_overlap(addr, len, ICH9_LPC_PMBASE, 4)) {
> ich9_lpc_pmbase_update(lpc);
> @@ -440,6 +458,34 @@ static void ich9_lpc_config_write(PCIDevice *d,
> }
> }
>
> +static uint32_t ich9_lpc_config_read(PCIDevice *d,
> + uint32_t addr, int len)
> +{
> +uint32_t val;
> +if (IGD_PASSTHROUGH)
> +{
> + if (ranges_overlap(addr, len, 0x2c, 2) || /* SVID - Subsystem Vendor
> Identification */
> +ranges_overlap(addr, len, 0x2e, 2)) /* SID - Subsystem Identificaion
> */
> + {
> + val =
> host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FUNC(d->devfn),addr,len);
> + }
> + else
> + {
> + goto defaultread;
> + }
> +}
> +else
> +{
> +defaultread:
> + val = pci_default_read_config(d,addr,len);
> +}
> +
> +LPC_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %x\n", __func__,
> +, 00, PCI_SLOT(d->devfn),PCI_FUNC(d->devfn), addr,
> len, val);
> +
> +return val;
> +}
Hard to see the through the poor formatting, but this doesn't seem like
something that needs to be intercepted on every config read. Instead we
should set the device subsystem IDs when we're initializing IGD
passthrough, but even then, I think Intel might be working on not
needing this based on previous feedback.
> +
> static void ich9_lpc_reset(DeviceState *qdev)
> {
> PCIDevice *d = PCI_DEVICE(qdev);
> @@ -577,6 +623,13 @@ static int ich9_lpc_init(PCIDevice *d)
>
> isa_bus = isa_bus_new(&d->qdev, get_system_io());
>
> +#ifdef CORRECT_CONFIG
> +pci_set_word(d->wmask + PCI_COMMAND,
> +(PCI_COMMAND_SERR | PCI_COMMAND_PARITY));
> +pci_set_word(d->config + PCI_COMMAND,
> +(PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
> PCI_COMMAND_MASTER));
> +#endif
> +
We need a better way to do this, obviously. I believe this change will
break migration on q35 (w/o IGD assignment). A new q35 machine type
perhaps or some sort of migration helpers.
> pci_set_long(d->wmask + ICH9_LPC_PMBASE,
> ICH9_LPC_PMBASE_BASE_ADDRESS_MASK);
>
> @@ -665,11 +718,20 @@ static void ich9_lpc_class_init(ObjectClass *klass,
> void *data)
> k->init = ich9_lpc_init;
> dc->vmsd = &vmstate_ich9_lpc;
> k->config_write = ich9_lpc_config_write;
> +k->config_read = ich9_lpc_config_read;
> dc->desc = "ICH9 LPC bridge";
> k->vendor_id = PCI_VENDOR_ID_INTEL;
> k->device_id = PCI_DEVICE_ID_INTEL_ICH9_8;
> k->revision = ICH9_A2_LPC_REVISION;
> k->class_id = PCI_CLASS_BRIDGE_ISA;
> +
> +/* For a UN-MODIFIED guest, the following 3 registers need to be read
> from the host.
> + * alternatively, modify i915_drv.c, intel_detect_pch, add a check for
> + * PCI_DEVICE_ID_INTEL_ICH9_8 and copy the settings from the PCH you
> desire */
> +k->vendor_id = host_pci_read_config(0,0x1f,0,0x00,2);
> +k->device_id = host_pci_read_config(0,0x1f,0,0x02,2);
> +//
Re: [Intel-gfx] [PATCH] drm/i915: Make sure PSR is ready for been re-enabled.
On Wed, Sep 24, 2014 at 12:40:20PM -0300, Paulo Zanoni wrote:
> 2014-09-17 14:23 GMT-03:00 Rodrigo Vivi :
> > Let's make sure PSR is propperly disabled before to re-enabled it.
> >
> > According to Spec, after disabled PSR CTL, the Idle state might occur
> > up to 24ms, that is one full frame time (1/refresh rate),
> > plus SRD exit training time (max of 6ms),
> > plus SRD aux channel handshake (max of 1.5ms).
> >
> > v2: The 24ms above takes in account 16ms for refresh rate on 60Hz mode.
> > However
> > on low frequency modes this can take longer. So let's use 50ms for safeness.
>
> Well, the patch looks correct, but it doesn't seem to take into
> consideration the fact that we already waited for 100ms before
> triggering psr.work. Also, we do the wait that you added with psr.lock
> locked, so we could be blocking user-space from doing other stuff for
> the whole 50ms, and that's an eternity and a half.
>
> So maybe we should tune the schedule_delayed_work() call at
> intel_edp_psr_flush() based on the calculation you did above (or just
> keep the 100ms, since it seems to be above the timeout for any modes
> bigger than 11Hz). And then when we're inside the work function, we
> should just I915_READ(EDP_PSR_STATUS_CTL) - instead of doing
> wait_for() -, and in case PSR is not idle yet, there's a huge
> probability that waiting for more 50ms won't really help. We could
> also try to reschedule psr.work to be triggered again in the future in
> case the bits we want are not ready, but by doing this we also risk
> rescheduling psr.work forever.
>
> More bikeshed on the timeout thing: can't we try discover the exact
> amount of time we need to sleep based on the refresh rate? We could
> try to look at the mode structure...
>
> tl;dr: if you remove the wait_for() call and keep just the I915_READ,
> I can give a R-B tag, but other patches could be acceptable too.
Hm, I think just moving the wait_for outside of the psr.lock critical
section should be good enough. Only the work item here can enable PSR, so
there's not really a race. And on the disable side we always sync with the
work before shutting down the psr work, so no synchronization issues
either. At worst the dpms off will take a few ms more.
Merged the 3rd patch meanwhile, thanks.
-Daniel
>
>
> >
> > So if something went wrong PSR will be disabled until next full
> > enable/disable setup.
> >
> > Cc: Daniel Vetter
> > Cc: Paulo Zanoni
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 2f0eee5..2e8c544 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1885,6 +1885,17 @@ static void intel_edp_psr_do_enable(struct intel_dp
> > *intel_dp)
> > WARN_ON(dev_priv->psr.active);
> > lockdep_assert_held(&dev_priv->psr.lock);
> >
> > + /* We have to make sure PSR is ready for re-enable
> > +* otherwise it keeps disabled until next full enable/disable cycle.
> > +* PSR might take some time to get fully disabled
> > +* and be ready for re-enable.
> > +*/
> > + if (wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev)) &
> > + EDP_PSR_STATUS_STATE_MASK) == 0, 50)) {
> > + DRM_ERROR("Timed out waiting for PSR Idle for re-enable\n");
> > + return;
> > + }
> > +
> > /* Enable/Re-enable PSR on the host */
> > intel_edp_psr_enable_source(intel_dp);
> >
> > --
> > 1.9.3
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] tools/null_state_gen: add macro to emit commands with null state
On Wed, Sep 24, 2014 at 05:50:30AM -0700, Mika Kuoppala wrote:
> In null/golden context there are multiple state commands where
> the actual state is always zero. For more compact batch representation
> add a macro which just emits command and the rest of the state as zero.
>
> Signed-off-by: Mika Kuoppala
> ---
> tools/null_state_gen/intel_batchbuffer.c| 12
> tools/null_state_gen/intel_batchbuffer.h| 6 +-
> tools/null_state_gen/intel_null_state_gen.c | 12 +++-
> 3 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/tools/null_state_gen/intel_batchbuffer.c
> b/tools/null_state_gen/intel_batchbuffer.c
> index 2a0b340..6e86aef 100644
> --- a/tools/null_state_gen/intel_batchbuffer.c
> +++ b/tools/null_state_gen/intel_batchbuffer.c
> @@ -274,3 +274,15 @@ const char *intel_batch_type_as_str(const struct bb_item
> *item)
>
> return "UNKNOWN";
> }
> +
> +void intel_batch_cmd_emit_null(struct intel_batchbuffer *batch, const int
> cmd, const int len, const char *str)
> +{
> + int i;
> +
> + assert(len > 1);
> +
> + bb_area_emit(batch->cmds, (cmd | (len - 2)), CMD, str);
I'm a little hesitant about the (len - 2) here just because there are
a number of commands for which those bits are not the length field, and
one or two where the length field is (len - 1). I think we're unlikely
to use those commands in a null batch, so maybe it's not something to
worry about.
> +
> + for (i = 1; i < len; i++)
> + OUT_BATCH(0);
> +}
> diff --git a/tools/null_state_gen/intel_batchbuffer.h
> b/tools/null_state_gen/intel_batchbuffer.h
> index e44c5c9..b4eed25 100644
> --- a/tools/null_state_gen/intel_batchbuffer.h
> +++ b/tools/null_state_gen/intel_batchbuffer.h
> @@ -34,7 +34,7 @@
> #include
>
> #define MAX_RELOCS 64
> -#define MAX_ITEMS 4096
> +#define MAX_ITEMS 1024
> #define MAX_STRLEN 256
>
> #define ALIGN(x, y) (((x) + (y)-1) & ~((y)-1))
> @@ -69,6 +69,7 @@ struct intel_batchbuffer {
>
> struct intel_batchbuffer *intel_batchbuffer_create(void);
>
> +#define OUT_CMD(cmd, len) intel_batch_cmd_emit_null(batch, cmd, len, #cmd "
> " #len)
> #define OUT_BATCH(d) bb_area_emit(batch->cmds, d, CMD, #d)
> #define OUT_BATCH_STATE_OFFSET(d) bb_area_emit(batch->cmds, d, STATE_OFFSET,
> #d)
> #define OUT_RELOC(batch, read_domain, write_domain, d)
> bb_area_emit(batch->cmds, d, RELOC, #d)
> @@ -81,6 +82,7 @@ uint32_t intel_batch_state_copy(struct intel_batchbuffer
> *batch, void *d, unsign
> const char *name);
> uint32_t intel_batch_state_alloc(struct intel_batchbuffer *batch, unsigned
> bytes, unsigned align,
>const char *name);
> +uint32_t intel_batch_state_offset(struct intel_batchbuffer *batch, unsigned
> align);
I see that at least patch 2 uses this function outside of intel_batchbuffer.c
but I wasn't expecting this change based on the commit title or message.
Thanks,
Brad
>
> unsigned intel_batch_num_cmds(struct intel_batchbuffer *batch);
>
> @@ -94,4 +96,6 @@ const char *intel_batch_type_as_str(const struct bb_item
> *item);
> void bb_area_emit(struct bb_area *a, uint32_t dword, item_type type, const
> char *str);
> void bb_area_emit_offset(struct bb_area *a, unsigned i, uint32_t dword,
> item_type type, const char *str);
>
> +void intel_batch_cmd_emit_null(struct intel_batchbuffer *batch, const int
> cmd, const int len, const char *str);
> +
> #endif
> diff --git a/tools/null_state_gen/intel_null_state_gen.c
> b/tools/null_state_gen/intel_null_state_gen.c
> index b337706..a7eb22b 100644
> --- a/tools/null_state_gen/intel_null_state_gen.c
> +++ b/tools/null_state_gen/intel_null_state_gen.c
> @@ -23,6 +23,9 @@ static void print_usage(char *s)
> static int print_state(int gen, struct intel_batchbuffer *batch)
> {
> int i;
> + unsigned long cmds;
> +
> + fprintf(stderr, "Generating for gen%d\n", gen);
>
> printf("#include \"intel_renderstate.h\"\n\n");
>
> @@ -43,8 +46,10 @@ static int print_state(int gen, struct intel_batchbuffer
> *batch)
> printf("\t /* 0x%08x %s '%s' */", i * 4,
> intel_batch_type_as_str(cmd), cmd->str);
>
> - if (i * 4 == batch->cmds_end_offset)
> + if (i * 4 == batch->cmds_end_offset) {
> + cmds = i + 1;
> printf("\t /* cmds end */");
> + }
>
> if (intel_batch_is_reloc(batch, i))
> printf("\t /* reloc */");
> @@ -60,6 +65,11 @@ static int print_state(int gen, struct intel_batchbuffer
> *batch)
>
> printf("};\n\nRO_RENDERSTATE(%d);\n", gen);
>
> + fprintf(stderr, "Commands %lu (%lu bytes)\n", cmds, cmds * 4);
> + fprintf(stderr, "State%lu (%lu bytes)\n", batch->state->num_items,
> batch->state->num_items * 4);
> + fprintf(stderr, "Total%lu (%lu bytes)\n", batch->cmds->num_items,
> batch->cmds->nu
Re: [Intel-gfx] [IGDVFIO] [PATCH 2/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
On Wed, 2014-09-24 at 14:20 +0100, Andrew Barnes wrote:
> hw/misc/vfio.c
>
> this patch adds:
> * memory map intel opregion
> * mirroring of bdsm to guest's device 0 not hosts.
>
> patch
> -
>
> diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
> index e88b610..54e549b 100644
> --- a/hw/misc/vfio.c
> +++ b/hw/misc/vfio.c
> @@ -5,6 +5,7 @@
> *
> * Authors:
> * Alex Williamson
> + * Andrew Barnes IGD Support
> *
> * This work is licensed under the terms of the GNU GPL, version 2. See
> * the COPYING file in the top-level directory.
> @@ -56,6 +57,45 @@
> #define VFIO_ALLOW_KVM_MSI 1
> #define VFIO_ALLOW_KVM_MSIX 1
>
> +/* A handy list of IGD device ID's */
> +#define IS_IGD_HASWELL(id)(id == 0x0402 \
> +|| id == 0x0406 \
> +|| id == 0x040a \
> +|| id == 0x0412 \
> +|| id == 0x0416 \
> +|| id == 0x041a \
> +|| id == 0x0a04 \
> +|| id == 0x0a16 \
> +|| id == 0x0a22 \
> +|| id == 0x0a26 \
> +|| id == 0x0a2a )
> +#define IS_IGD_IVYBRIDGE(id) (id == 0x0162 \
> +|| id == 0x0166 \
> +|| id == 0x016a \
> +|| id == 0x0152 \
> +|| id == 0x0156 \
> +|| id == 0x015a )
> +#define IS_IGD_SANDYBRIDGE(id)(id == 0x0102 \
> +|| id == 0x0106 \
> +|| id == 0x0112 \
> +|| id == 0x0116 \
> +|| id == 0x0122 \
> +|| id == 0x0126 \
> +|| id ==0x010a )
> +#define IS_IGD_IRONLAKE_CLARKDALE(id) (id == 0x0042 )
> +#define IS_IGD_IRONLAKE_ARRANDALE(id) (id == 0x0046 )
> +#define IS_IGD(id)(IS_IGD_IRONLAKE_CLARKDALE(id) \
> +|| IS_IGD_IRONLAKE_ARRANDALE(id) \
> +|| IS_IGD_SANDYBRIDGE(id) \
> +|| IS_IGD_IVYBRIDGE(id) \
> +|| IS_IGD_HASWELL(id) )
> +#define IGD_BAR_MASK 0x
> +#define DMAR_OPERATION_TIMEOUT((s_time_t)((_ms) * 100ULL))
> +
> +#define PCI_CONFIG_INTEL_OPREGION 0xfc
> +#define INTEL_OPREGION_PAGES3
> +#define INTEL_OPREGION_SIZE INTEL_OPREGION_PAGES *
> TARGET_PAGE_SIZE
> +
*GAG*
> struct VFIODevice;
>
> typedef struct VFIOQuirk {
> @@ -227,6 +267,8 @@ typedef struct VFIODevice {
> bool has_pm_reset;
> bool needs_reset;
> bool rom_read_failed;
> +MemoryRegion opregion; /* Intel opregion */
> +uint32_t host_opregion; /* Host address of opregion */
Let's at least create a new struct to host these with a pointer off of
VFIODevice, then we only need to test IS_IGD() once any everywhere else
can just test the pointer.
> } VFIODevice;
>
> typedef struct VFIOGroup {
> @@ -283,6 +325,18 @@ static void vfio_pci_write_config(PCIDevice *pdev,
> uint32_t addr,
>uint32_t val, int len);
> static void vfio_mmap_set_enabled(VFIODevice *vdev, bool enabled);
>
> +static void vfio_set_word_bits(uint8_t *buf, uint16_t val, uint16_t mask);
> +static void vfio_add_emulated_word(VFIODevice *vdev, int pos,
> + uint16_t val, uint16_t mask);
> +static void vfio_set_long_bits(uint8_t *buf, uint32_t val, uint32_t mask);
> +static void vfio_add_emulated_long(VFIODevice *vdev, int pos,
> + uint32_t val, uint32_t mask);
> +static void vfio_add_emulated_rw_long(VFIODevice *vdev, int pos,
> + uint32_t val, uint32_t mask);
> +static void vfio_map_igdopregion(VFIODevice *vdev, uint32_t
> guest_opregion);
> +
> +static VFIODevice *igdvfio;
Unused?
> +
> /*
> * Common VFIO interrupt disable
> */
> @@ -2324,27 +2378,46 @@ static uint32_t vfio_pci_read_config(PCIDevice
> *pdev, uint32_t addr, int len)
> VFIODevice *vdev = DO_UPCAST(VFIODevice, pdev, pdev);
> uint32_t emu_bits = 0, emu_val = 0, phys_val = 0, val;
>
> -memcpy(&emu_bits, vdev->emulated_config_bits + addr, len);
> -emu_bits = le32_to_cpu(emu_bits);
> -
> -if (emu_bits) {
> -emu_val = pci_default_read_config(pdev, addr, len);
> +/* BDSM mirror - BDSM can be read at either 0xb0 device 0, or 0x5c
> device 2.
> + * Redirect this mirror from host 0xb0 de
Re: [Intel-gfx] [PATCH] drm/i915: Enable pixel replicated modes on BDW and HSW.
On Wed, Sep 24, 2014 at 08:44:42AM -0700, Clint Taylor wrote:
> On 09/24/2014 01:51 AM, Daniel Vetter wrote:
> >On Tue, Sep 23, 2014 at 11:06:56AM -0700, clinton.a.tay...@intel.com wrote:
> >>From: Clint Taylor
> >>
> >>Haswell and later silicon has added a new pixel replication register
> >>to the pipe timings for each transcoder. Now in addition to the
> >>DPLL_A_MD register for the pixel clock double, we also need to write to
> >>the TRANS_MULT_n (0x6002c) register to double the pixel data. Writing
> >>to the DPLL only double the pixel clock.
> >>
> >>Signed-off-by: Clint Taylor
> >>---
> >> drivers/gpu/drm/i915/i915_reg.h |3 +++
> >> drivers/gpu/drm/i915/intel_display.c |6 +-
> >> 2 files changed, 8 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >>b/drivers/gpu/drm/i915/i915_reg.h
> >>index 15c0eaa..7c078d9 100644
> >>--- a/drivers/gpu/drm/i915/i915_reg.h
> >>+++ b/drivers/gpu/drm/i915/i915_reg.h
> >>@@ -2431,6 +2431,7 @@ enum punit_power_well {
> >> #define _PIPEASRC 0x6001c
> >> #define _BCLRPAT_A0x60020
> >> #define _VSYNCSHIFT_A 0x60028
> >>+#define _MULTIPLY_A0x6002c
> >>
> >> /* Pipe B timing regs */
> >> #define _HTOTAL_B 0x61000
> >>@@ -2442,6 +2443,7 @@ enum punit_power_well {
> >> #define _PIPEBSRC 0x6101c
> >> #define _BCLRPAT_B0x61020
> >> #define _VSYNCSHIFT_B 0x61028
> >>+#define _MULTIPLY_B0x6102c
> >>
> >> #define TRANSCODER_A_OFFSET 0x6
> >> #define TRANSCODER_B_OFFSET 0x61000
> >>@@ -2462,6 +2464,7 @@ enum punit_power_well {
> >> #define BCLRPAT(trans) _TRANSCODER2(trans, _BCLRPAT_A)
> >> #define VSYNCSHIFT(trans) _TRANSCODER2(trans, _VSYNCSHIFT_A)
> >> #define PIPESRC(trans) _TRANSCODER2(trans, _PIPEASRC)
> >>+#define MULTIPLY(trans) _TRANSCODER2(trans, _MULTIPLY_A)
> >
> >MULTIPLY is a bit generic and doesn't even match Bspec lingo. I'd just go
> >with PIPE_MULTI instead to match Bspec and give it a nice PIPE_ prefix.
> >>
> >> /* HSW+ eDP PSR registers */
> >> #define EDP_PSR_BASE(dev) (IS_HASWELL(dev) ?
> >> 0x64800 : 0x6f800)
> >>diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>b/drivers/gpu/drm/i915/intel_display.c
> >>index c092ff4..e58fcde 100644
> >>--- a/drivers/gpu/drm/i915/intel_display.c
> >>+++ b/drivers/gpu/drm/i915/intel_display.c
> >>@@ -4152,6 +4152,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
> >>
> >>intel_set_pipe_timings(intel_crtc);
> >>
> >>+ I915_WRITE(MULTIPLY(intel_crtc->config.cpu_transcoder),
> >
> >This register is per-pipe, so needs to be indexed with intel_crtc->pipe.
> >Same below.
> >
> The MULTIPLY Macro calls the _TRANSCODER2 MACRO which already indexes the
> register based on intel_crtc->pipe. This should be all that's required.
I don't see where it indexes with intel_crtc->pipe ...
But it doesn't matter since the register is clearly in the transcoder
block, and the reason why Bspec says is per-pipe is that the edp
transcoder doesn't have it. So on second consideration I guess we can keep
this part as-is then.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/core-stuff
On Wed, Sep 24, 2014 at 12:24:53PM +0200, Daniel Vetter wrote: > Hi Dave, > > Just noticed that you've picked up the header rework stuff already, so > I've rebased that out again. Otherwise just two stragglers from the vblank > rework and the universal cursor planes locking fix. Plus sprinkling > container_of all over fbdev emulation from Fabian. > > Aside: I only have just 1 fix for drm-next atm for i915 and not terribly > serious. So will probably only send you a pull for it when the merge > window opens or something more serious shows up. > > Cheers, Daniel > > > The following changes since commit d743ecf360637d489a3ba81a268f574359149601: > > drm/doc: Fixup drm_irq kerneldoc includes. (2014-09-24 11:43:47 +1000) > > are available in the git repository at: > > git://anongit.freedesktop.org/drm-intel tags/topic/core-stuff-2014-09-24 > > for you to fetch changes up to ee0d68ab5f0997a500fdf90924a58e787b216292: > > drm/udl: use container_of to resolve udl_fbdev from drm_fb_helper > (2014-09-24 12:09:28 +0200) > > > Daniel Vetter (2): > drm: Fixup locking for universal cursor planes Ok, this one here is bust since it introduces an inversion between the modeset locks and fpriv->fbs_lock. Oh well. I'll try to patch this up asap. -Daniel > drm: Improve debug output for drm_wait_one_vblank > > Fabian Frederick (9): > drm/cirrus: use container_of to resolve cirrus_fbdev from drm_fb_helper > drm/mgag200: use container_of to resolve mga_fbdev from drm_fb_helper > drm/radeon: use container_of to resolve radeon_fbdev from drm_fb_helper > drm/nouveau: use container_of to resolve nouveau_fbdev from > drm_fb_helper > drm/nouveau: use container_of to resolve nouveau_plane from drm_plane > drm/qxl: use container_of to resolve qxl_fbdev from drm_fb_helper > drm/gma500: use container_of to resolve psb_fbdev from drm_fb_helper > drm/ast: use container_of to resolve ast_fbdev from drm_fb_helper > drm/udl: use container_of to resolve udl_fbdev from drm_fb_helper > > Mario Kleiner (1): > drm: Don't update vblank timestamp when the counter didn't change > > drivers/gpu/drm/ast/ast_fb.c | 3 +- > drivers/gpu/drm/cirrus/cirrus_fbdev.c | 3 +- > drivers/gpu/drm/drm_crtc.c | 51 > -- > drivers/gpu/drm/drm_irq.c | 7 ++-- > drivers/gpu/drm/gma500/framebuffer.c | 3 +- > drivers/gpu/drm/mgag200/mgag200_fb.c | 3 +- > drivers/gpu/drm/nouveau/dispnv04/overlay.c | 15 ++--- > drivers/gpu/drm/nouveau/nouveau_fbcon.c| 3 +- > drivers/gpu/drm/qxl/qxl_fb.c | 3 +- > drivers/gpu/drm/radeon/radeon_fb.c | 3 +- > drivers/gpu/drm/udl/udl_fb.c | 3 +- > 11 files changed, 65 insertions(+), 32 deletions(-) > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [IGDVFIO] [PATCH 3/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
On Wed, 2014-09-24 at 14:20 +0100, Andrew Barnes wrote:
> hw/pci-host/q35.c
>
> this patch adds:
> * redirect some PCI config reads/writes to host
> * memory map BSDM, BGSM, TSEG
>
> patch
> -
>
> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> index a0a3068..05348ac 100644
> --- a/hw/pci-host/q35.c
> +++ b/hw/pci-host/q35.c
> @@ -6,6 +6,7 @@
> * Isaku Yamahata
> * VA Linux Systems Japan K.K.
> * Copyright (C) 2012 Jason Baron
> + * 2014 Andrew barnes IGD Support
> *
> * This is based on piix_pci.c, but heavily modified.
> *
> @@ -30,11 +31,26 @@
> #include "hw/hw.h"
> #include "hw/pci-host/q35.h"
> #include "qapi/visitor.h"
> +#include "hw/pci/pci.h"
> +#include /* memory map functions */
> +
> +/* #define DEBUG_Q35 */
> +#ifdef DEBUG_Q35
> +# define Q35_DPRINTF(format, ...) printf("Q35: " format, ##
> __VA_ARGS__)
> +#else
> +# define Q35_DPRINTF(format, ...) do { } while (0)
> +#endif
> +
> +/* for intel-spec conforming config */
> +/* #define CORRECT_CONFIG */
>
> /
> * Q35 host
> */
>
> +/* BEWARE: only set this if you are passing IGD through */
> +static bool IGD_PASSTHROUGH = true;
> +
> static void q35_host_realize(DeviceState *dev, Error **errp)
> {
> PCIHostState *pci = PCI_HOST_BRIDGE(dev);
> @@ -284,11 +300,193 @@ static void mch_set_smm(int smm, void *arg)
> memory_region_transaction_commit();
> }
>
> -static void mch_write_config(PCIDevice *d,
> +/* TODO: Move these variables/defines to be consistent with Q35 coding
> style */
> +MemoryRegion bdsm;
> +uint32_t bdsm_host;
> +MemoryRegion bgsm;
> +uint32_t bgsm_host;
> +MemoryRegion tseg;
> +uint32_t tseg_host;
> +#define MCH_CONFIG_BDSM 0xb0
> +#define MCH_CONFIG_BGSM 0xb4
> +#define MCH_CONFIG_TSEG 0xb8
> +#define MCH_CONFIG_GMCH 0x50
> +
> +/* Setup memory map for Stolen Memory */
> +static void mch_setup_bdsm(PCIDevice *d)
> +{
> +int fd;
> +char name[64];
> +void *map;
> +bdsm_host =
> host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FUNC(d->devfn),MCH_CONFIG_BDSM,4);
> +int dsm_size;
> +uint16_t gmch_host =
> host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FUNC(d->devfn),MCH_CONFIG_GMCH,2);
> +uint16_t gmch_dsm = (gmch_host & 0xF8) >> 3;
> +MCHPCIState *mch = MCH_PCI_DEVICE(d);
> +
> +Q35_DPRINTF("%s Setup BDSM: %x\n",__func__,bdsm_host);
> +
> +snprintf(name, sizeof(name), "MCH-BDSM-mmap");
> +fd = open("/dev/mem", O_RDWR);
> +
> +switch (gmch_dsm)
> +{
> + case 0x0: dsm_size = 0; break;
> + case 0x1: dsm_size = 32; break;
> + case 0x2: dsm_size = 64; break;
> + case 0x3: dsm_size = 96; break;
> + case 0x4: dsm_size = 128; break;
> + case 0x5: dsm_size = 160; break;
> + case 0x6: dsm_size = 192; break;
> + case 0x7: dsm_size = 224; break;
> + case 0x8: dsm_size = 256; break;
> + case 0x9: dsm_size = 288; break;
> + case 0xa: dsm_size = 320; break;
> + case 0xb: dsm_size = 352; break;
> + case 0xc: dsm_size = 384; break;
> + case 0xd: dsm_size = 416; break;
> + case 0xe: dsm_size = 448; break;
> + case 0xf: dsm_size = 480; break;
> + case 0x10: dsm_size = 512; break;
> + // default: /* panic */
Certainly do something other than pass a multiple of an uninitialized
variable through to mmap.
> +}
> +
> +dsm_size = dsm_size * 1024 * 1024;
> +map = mmap(NULL,dsm_size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,(bdsm_host
> & 0xFFF0));
> +
> +if (map == MAP_FAILED)
> +{
> +map = NULL;
> +Q35_DPRINTF("%s Setup BDSM: MAP_FAILED\n",__func__);
> +}
> +
> +memory_region_init_ram_ptr(&bdsm, OBJECT(mch), name, dsm_size, map);
> +}
Presumably this is something else we'd need to provide through the vfio
device. So we're up to
1. opregion (3 pages... wasn't it 2 before?)
2. stolen memory (up to 512M)
> +
> +/* this function memory maps the region of host memory assigned to Stolen
> memory
> + * to the guest location provided by seabios. */
> +static void mch_map_bdsm(PCIDevice *d, uint32_t bdsm_new)
> +{
> +MemoryRegion *guest_memory = get_system_memory();
> +uint32_t bdsm_current = pci_default_read_config(d,MCH_CONFIG_BDSM,4);
> +
> +if ( bdsm_current != bdsm_host && bdsm_current != 0 )
> +{
> +// remap
> +Q35_DPRINTF("%s Delete BDSM mapping: %x\n",__func__,(bdsm_current
> & 0xFFF0));
> +memory_region_del_subregion(guest_memory, &bdsm);
> +}
> +Q35_DPRINTF("%s Add BDSM mapping: %x ->
> %x\n",__func__,bdsm_host,bdsm_new);
> +memory_region_add_subregion(guest_memory, (bdsm_new & 0xFFF0),
> &bdsm);
> +}
> +
> +/* Setup memory map for GTT Stolen Memory */
> +static void mch_setup_bgsm(PCIDevice *d)
> +{
> +int fd;
> +char name[64];
> +void *map;
> +bgsm_host =
> host_pci_read_config(0,PCI_SLOT(d->devfn),PCI_FU
Re: [Intel-gfx] [IGDVFIO] [PATCH 4/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
On Wed, 2014-09-24 at 14:20 +0100, Andrew Barnes wrote:
> hw/pci/pci.c
>
> this patch adds:
> * read / write host PCI config space
>
> patch
> -
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 42995e6..041f6f1 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -2,6 +2,8 @@
> * QEMU PCI bus manager
> *
> * Copyright (c) 2004 Fabrice Bellard
> + *2014 Andrew Barnes IGD Support
> + *Temporarily extended to provide host config read/write.
> *
> * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> * of this software and associated documentation files (the "Software"),
> to deal
> @@ -37,9 +39,9 @@
> #include "exec/address-spaces.h"
> #include "hw/hotplug.h"
>
> -//#define DEBUG_PCI
> +/* #define DEBUG_PCI */
> #ifdef DEBUG_PCI
> -# define PCI_DPRINTF(format, ...) printf(format, ## __VA_ARGS__)
> +# define PCI_DPRINTF(format, ...) printf("pci:" format, ##
> __VA_ARGS__)
> #else
> # define PCI_DPRINTF(format, ...) do { } while (0)
> #endif
> @@ -60,6 +62,81 @@ static Property pci_props[] = {
> DEFINE_PROP_END_OF_LIST()
> };
>
> +/* Provides config reads from the host */
> +uint32_t host_pci_read_config(int bus, int slot, int fn, uint32_t address,
> int len)
> +{
> +uint32_t val = 0;
> +int fd;
> +int domain = 0;
> +ssize_t ret;
> +char dir[128], name[128];
> +
> +snprintf(dir, sizeof(dir), "/sys/bus/pci/devices/%04x:%02x:%02x.%x/",
> + domain, bus, slot, fn);
> +snprintf(name, sizeof(name), "%sconfig", dir);
> +
> +fd = open(name, O_RDONLY);
> +
> +if (fd >= 0)
> +{
> +do
> +{
> +ret = pread(fd,&val,len,address);
> +} while ((ret < 0) && (errno == EINTR || errno == EAGAIN));
> +
> +if (ret != len)
> +{
> +PCI_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %s ret=%zd
> error=%d\n",
> + __func__, , bus, slot, fn, address, len, "pread
> Failed",ret,errno);
> +val = (1UL << (len * 8)) - 1;
> +}
> +}
> +else
> +{
> +PCI_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %s\n",
> + __func__, , bus, slot, fn, address, len, "Open
> Failed");
> +}
> +
> +PCI_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %x\n",
> + __func__, , bus, slot, fn, address, len, val);
> +return val;
> +}
> +
> +/* Provides config writes to the host*/
> +void host_pci_write_config(int bus, int slot, int fn, uint32_t address,
> int len, uint32_t val)
> +{
> +int fd;
> +int domain = 0;
> +ssize_t ret;
> +char dir[128], name[128];
> +
> +snprintf(dir, sizeof(dir), "/sys/bus/pci/devices/%04x:%02x:%02x.%x/",
> + domain, bus, slot, fn);
> +snprintf(name, sizeof(name), "%sconfig", dir);
> +
> +fd = open(name, O_RDWR);
> +
> +if (fd >= 0)
> +{
> +do
> +{
> +ret = pwrite(fd,&val,len,address);
> +} while ((ret < 0) && (errno == EINTR || errno == EAGAIN));
> +
> +
> +if (ret != len)
> +{
> +PCI_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %x %s
> ret=%zd error=%d\n",
> + __func__, , bus, slot, fn, address, len, val, "pread
> Failed",ret,errno);
> +}
> +}
> +else
> +{
> +PCI_DPRINTF("%s(%04x:%02x:%02x.%x, @0x%x, len=0x%x) %s\n",
> + __func__, , bus, slot, fn, address, len, "Open
> Failed");
> +}
> +}
> +
> static const VMStateDescription vmstate_pcibus = {
> .name = "PCIBUS",
> .version_id = 1,
I expect a huge NAK on this one. When run from libvirt and with any
sort of process containment, QEMU won't have access to these. Not to
mention that many of the uses of these break migration.
In the case of things like stolen memory, GTT stolen memory, and tseg,
we shouldn't need to use these accessors because we shouldn't really
care what the host value is. We only care currently because we need the
offset into /dev/mem. We should consider that in designing the vfio
interface.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Drop grab fpriv->fbs_lock in drm_fb_release
Paulo Zanoni reported a lockdep splat with a locking inversion between
fpriv->fbs_lock and the modeset locks. This issue was introduced in
commit f2b50c1161590c3bcdbf3455fe4c575f1c1bd293
Author: Daniel Vetter
Date: Fri Sep 12 17:07:32 2014 +0200
drm: Fixup locking for universal cursor planes
This here is actually one of the rare cases where lockdep hits a false
positive: The deadlock only happens in drm_fb_release, which cleans up
the file private structure when all the references are gone. So the
locking is the very last one and no one else can deadlock. It also
doesn't protect anything at all, since all ioctls are guaranteed to
have returned at this point - otherwise they'd still hold a reference
on the file.
So let's just drop it and replace it with a big comment.
Cc: David Herrmann
Cc: Matt Roper
Cc: Paulo Zanoni
Reported-by: Paulo Zanoni
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b7021069b078..e79c8d3700d8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3400,7 +3400,16 @@ void drm_fb_release(struct drm_file *priv)
struct drm_device *dev = priv->minor->dev;
struct drm_framebuffer *fb, *tfb;
- mutex_lock(&priv->fbs_lock);
+ /*
+* When the file gets released that means no one else can access the fb
+* list any more, so no need to grab fpriv->fbs_lock. And we need to to
+* avoid upsetting lockdep since the universal cursor code adds a
+* framebuffer while holding mutex locks.
+*
+* Note that a real deadlock between fpriv->fbs_lock and the modeset
+* locks is impossible here since no one else but this function can get
+* at it any more.
+*/
list_for_each_entry_safe(fb, tfb, &priv->fbs, filp_head) {
mutex_lock(&dev->mode_config.fb_lock);
@@ -3413,7 +3422,6 @@ void drm_fb_release(struct drm_file *priv)
/* This will also drop the fpriv->fbs reference. */
drm_framebuffer_remove(fb);
}
- mutex_unlock(&priv->fbs_lock);
}
/**
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper
On Wednesday, September 24, 2014 09:44:50 PM Vinod Koul wrote: > This patch series adds a simple macro pm_runtime_last_busy_and_autosuspend() > which invokes pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend() > sequentially. Then we do a tree wide update of current patterns which are > present. As evident from log below this pattern is frequent in the > kernel. > > This series can be found at > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git > topic/pm_runtime_last_busy_and_autosuspend > > Fengguang's kbuild has tested it so it shouldn't break things for anyone. > Barring one patch (explictyly mentioned in its changelog) rest are simple > replacements. > > If all are okay, this should be merged thru PM tree as it depends on macro > addition. > > Subhransu S. Prusty (1): > PM: Add helper pm_runtime_last_busy_and_autosuspend() > > Vinod Koul (26): > dmaengine: ste_dma: use pm_runtime_last_busy_and_autosuspend helper > extcon: arizona: use pm_runtime_last_busy_and_autosuspend helper > drm/i915: use pm_runtime_last_busy_and_autosuspend helper > drm/nouveau: use pm_runtime_last_busy_and_autosuspend helper > drm/radeon: use pm_runtime_last_busy_and_autosuspend helper > vga_switcheroo: use pm_runtime_last_busy_and_autosuspend helper > i2c: designware: use pm_runtime_last_busy_and_autosuspend helper > i2c: omap: use pm_runtime_last_busy_and_autosuspend helper > i2c: qup: use pm_runtime_last_busy_and_autosuspend helper > mfd: ab8500-gpadc: use pm_runtime_last_busy_and_autosuspend helper > mfd: arizona: use pm_runtime_last_busy_and_autosuspend helper > mei: use pm_runtime_last_busy_and_autosuspend helper > mmc: use pm_runtime_last_busy_and_autosuspend helper > mmc: mmci: use pm_runtime_last_busy_and_autosuspend helper > mmc: omap_hsmmc: use pm_runtime_last_busy_and_autosuspend helper > mmc: sdhci-pxav3: use pm_runtime_last_busy_and_autosuspend helper > mmc: sdhci: use pm_runtime_last_busy_and_autosuspend helper > NFC: trf7970a: use pm_runtime_last_busy_and_autosuspend helper > pm2301-charger: use pm_runtime_last_busy_and_autosuspend helper > spi: omap2-mcspi: use pm_runtime_last_busy_and_autosuspend helper > spi: orion: use pm_runtime_last_busy_and_autosuspend helper > spi: ti-qspi: use pm_runtime_last_busy_and_autosuspend helper > spi: core: use pm_runtime_last_busy_and_autosuspend helper > tty: serial: omap: use pm_runtime_last_busy_and_autosuspend helper > usb: musb: omap2430: use pm_runtime_last_busy_and_autosuspend helper > video: fbdev: use pm_runtime_last_busy_and_autosuspend helper > > Documentation/power/runtime_pm.txt |4 ++ > drivers/dma/ste_dma40.c | 30 - > drivers/extcon/extcon-arizona.c |6 +-- > drivers/gpu/drm/i915/intel_pm.c |3 +- > drivers/gpu/drm/nouveau/nouveau_connector.c |3 +- > drivers/gpu/drm/nouveau/nouveau_drm.c |9 +--- > drivers/gpu/drm/radeon/radeon_connectors.c | 15 ++ > drivers/gpu/drm/radeon/radeon_drv.c |5 +- > drivers/gpu/drm/radeon/radeon_kms.c |6 +-- > drivers/gpu/vga/vga_switcheroo.c|7 +-- > drivers/i2c/busses/i2c-designware-core.c|3 +- > drivers/i2c/busses/i2c-omap.c |6 +-- > drivers/i2c/busses/i2c-qup.c|3 +- > drivers/mfd/ab8500-gpadc.c |6 +-- > drivers/mfd/arizona-irq.c |3 +- > drivers/misc/mei/client.c | 12 ++ > drivers/mmc/core/core.c |3 +- > drivers/mmc/host/mmci.c | 12 ++ > drivers/mmc/host/omap_hsmmc.c | 19 ++--- > drivers/mmc/host/sdhci-pxav3.c |6 +-- > drivers/mmc/host/sdhci.c|3 +- > drivers/nfc/trf7970a.c |3 +- > drivers/power/pm2301_charger.c |3 +- > drivers/spi/spi-omap2-mcspi.c |9 +--- > drivers/spi/spi-orion.c |3 +- > drivers/spi/spi-ti-qspi.c |5 +- > drivers/spi/spi.c |6 +-- > drivers/tty/serial/omap-serial.c| 60 > +-- > drivers/usb/musb/omap2430.c |6 +-- > drivers/video/fbdev/auo_k190x.c |9 +--- > include/linux/pm_runtime.h |6 +++ > 31 files changed, 97 insertions(+), 177 deletions(-) OK, I guess this is as good as it gets. What tree would you like it go through? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper
On Wednesday, September 24, 2014 03:15:58 PM Felipe Balbi wrote: > On Wed, Sep 24, 2014 at 10:28:07PM +0200, Rafael J. Wysocki wrote: > > On Wednesday, September 24, 2014 09:44:50 PM Vinod Koul wrote: > > > This patch series adds a simple macro > > > pm_runtime_last_busy_and_autosuspend() > > > which invokes pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend() > > > sequentially. Then we do a tree wide update of current patterns which are > > > present. As evident from log below this pattern is frequent in the > > > kernel. > > > > > > This series can be found at > > > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git > > > topic/pm_runtime_last_busy_and_autosuspend > > > > > > Fengguang's kbuild has tested it so it shouldn't break things for anyone. > > > Barring one patch (explictyly mentioned in its changelog) rest are simple > > > replacements. > > > > > > If all are okay, this should be merged thru PM tree as it depends on macro > > > addition. > > > > > > Subhransu S. Prusty (1): > > > PM: Add helper pm_runtime_last_busy_and_autosuspend() > > > > > > Vinod Koul (26): > > > dmaengine: ste_dma: use pm_runtime_last_busy_and_autosuspend helper > > > extcon: arizona: use pm_runtime_last_busy_and_autosuspend helper > > > drm/i915: use pm_runtime_last_busy_and_autosuspend helper > > > drm/nouveau: use pm_runtime_last_busy_and_autosuspend helper > > > drm/radeon: use pm_runtime_last_busy_and_autosuspend helper > > > vga_switcheroo: use pm_runtime_last_busy_and_autosuspend helper > > > i2c: designware: use pm_runtime_last_busy_and_autosuspend helper > > > i2c: omap: use pm_runtime_last_busy_and_autosuspend helper > > > i2c: qup: use pm_runtime_last_busy_and_autosuspend helper > > > mfd: ab8500-gpadc: use pm_runtime_last_busy_and_autosuspend helper > > > mfd: arizona: use pm_runtime_last_busy_and_autosuspend helper > > > mei: use pm_runtime_last_busy_and_autosuspend helper > > > mmc: use pm_runtime_last_busy_and_autosuspend helper > > > mmc: mmci: use pm_runtime_last_busy_and_autosuspend helper > > > mmc: omap_hsmmc: use pm_runtime_last_busy_and_autosuspend helper > > > mmc: sdhci-pxav3: use pm_runtime_last_busy_and_autosuspend helper > > > mmc: sdhci: use pm_runtime_last_busy_and_autosuspend helper > > > NFC: trf7970a: use pm_runtime_last_busy_and_autosuspend helper > > > pm2301-charger: use pm_runtime_last_busy_and_autosuspend helper > > > spi: omap2-mcspi: use pm_runtime_last_busy_and_autosuspend helper > > > spi: orion: use pm_runtime_last_busy_and_autosuspend helper > > > spi: ti-qspi: use pm_runtime_last_busy_and_autosuspend helper > > > spi: core: use pm_runtime_last_busy_and_autosuspend helper > > > tty: serial: omap: use pm_runtime_last_busy_and_autosuspend helper > > > usb: musb: omap2430: use pm_runtime_last_busy_and_autosuspend helper > > > video: fbdev: use pm_runtime_last_busy_and_autosuspend helper > > > > > > Documentation/power/runtime_pm.txt |4 ++ > > > drivers/dma/ste_dma40.c | 30 - > > > drivers/extcon/extcon-arizona.c |6 +-- > > > drivers/gpu/drm/i915/intel_pm.c |3 +- > > > drivers/gpu/drm/nouveau/nouveau_connector.c |3 +- > > > drivers/gpu/drm/nouveau/nouveau_drm.c |9 +--- > > > drivers/gpu/drm/radeon/radeon_connectors.c | 15 ++ > > > drivers/gpu/drm/radeon/radeon_drv.c |5 +- > > > drivers/gpu/drm/radeon/radeon_kms.c |6 +-- > > > drivers/gpu/vga/vga_switcheroo.c|7 +-- > > > drivers/i2c/busses/i2c-designware-core.c|3 +- > > > drivers/i2c/busses/i2c-omap.c |6 +-- > > > drivers/i2c/busses/i2c-qup.c|3 +- > > > drivers/mfd/ab8500-gpadc.c |6 +-- > > > drivers/mfd/arizona-irq.c |3 +- > > > drivers/misc/mei/client.c | 12 ++ > > > drivers/mmc/core/core.c |3 +- > > > drivers/mmc/host/mmci.c | 12 ++ > > > drivers/mmc/host/omap_hsmmc.c | 19 ++--- > > > drivers/mmc/host/sdhci-pxav3.c |6 +-- > > > drivers/mmc/host/sdhci.c|3 +- > > > drivers/nfc/trf7970a.c |3 +- > > > drivers/power/pm2301_charger.c |3 +- > > > drivers/spi/spi-omap2-mcspi.c |9 +--- > > > drivers/spi/spi-orion.c |3 +- > > > drivers/spi/spi-ti-qspi.c |5 +- > > > drivers/spi/spi.c |6 +-- > > > drivers/tty/serial/omap-serial.c| 60 > > > +-- > > > drivers/usb/musb/omap2430.c |6 +-- > > > drivers/video/fbdev/auo_k190x.c |9 +--- > > > include/linux/pm_runtime.h |6 +++ > > > 31 files changed, 97 insertions(+), 177 deletions(-) > > > > OK, I gues
Re: [Intel-gfx] [PATCH] drm: Drop grab fpriv->fbs_lock in drm_fb_release
2014-09-24 16:55 GMT-03:00 Daniel Vetter :
> Paulo Zanoni reported a lockdep splat with a locking inversion between
> fpriv->fbs_lock and the modeset locks. This issue was introduced in
>
> commit f2b50c1161590c3bcdbf3455fe4c575f1c1bd293
> Author: Daniel Vetter
> Date: Fri Sep 12 17:07:32 2014 +0200
>
> drm: Fixup locking for universal cursor planes
>
> This here is actually one of the rare cases where lockdep hits a false
> positive: The deadlock only happens in drm_fb_release, which cleans up
> the file private structure when all the references are gone. So the
> locking is the very last one and no one else can deadlock. It also
> doesn't protect anything at all, since all ioctls are guaranteed to
> have returned at this point - otherwise they'd still hold a reference
> on the file.
>
> So let's just drop it and replace it with a big comment.
>
> Cc: David Herrmann
> Cc: Matt Roper
> Cc: Paulo Zanoni
> Reported-by: Paulo Zanoni
> Signed-off-by: Daniel Vetter
Apparently, it fixes the problem I was seeing while running
igt/pm_rpm. It was not 100% reproducible, but it seems to be gone.
Smoke-tested-by: Paulo Zanoni
Testcase: igt/pm_rpm
> ---
> drivers/gpu/drm/drm_crtc.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b7021069b078..e79c8d3700d8 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3400,7 +3400,16 @@ void drm_fb_release(struct drm_file *priv)
> struct drm_device *dev = priv->minor->dev;
> struct drm_framebuffer *fb, *tfb;
>
> - mutex_lock(&priv->fbs_lock);
> + /*
> +* When the file gets released that means no one else can access the
> fb
> +* list any more, so no need to grab fpriv->fbs_lock. And we need to
> to
> +* avoid upsetting lockdep since the universal cursor code adds a
> +* framebuffer while holding mutex locks.
> +*
> +* Note that a real deadlock between fpriv->fbs_lock and the modeset
> +* locks is impossible here since no one else but this function can
> get
> +* at it any more.
> +*/
> list_for_each_entry_safe(fb, tfb, &priv->fbs, filp_head) {
>
> mutex_lock(&dev->mode_config.fb_lock);
> @@ -3413,7 +3422,6 @@ void drm_fb_release(struct drm_file *priv)
> /* This will also drop the fpriv->fbs reference. */
> drm_framebuffer_remove(fb);
> }
> - mutex_unlock(&priv->fbs_lock);
> }
>
> /**
> --
> 2.1.0
>
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [IGDVFIO] [PATCH 3/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
Il 24/09/2014 21:47, Alex Williamson ha scritto: > So the opregion is mapped by a config write on the IGD device itself and > the other 3 regions, that we know about so far, are mapped via writes to > the host bridge. AFAIU the opregion is mapped by the (host) BIOS, that writes the address to a well-known scratch dword in the configuration space. The host reads from the dword and finds the opregion that way. Paolo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Qemu-devel] [IGDVFIO] [PATCH 3/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
On Wed, 2014-09-24 at 22:31 +0200, Paolo Bonzini wrote: > Il 24/09/2014 21:47, Alex Williamson ha scritto: > > So the opregion is mapped by a config write on the IGD device itself and > > the other 3 regions, that we know about so far, are mapped via writes to > > the host bridge. > > AFAIU the opregion is mapped by the (host) BIOS, that writes the address > to a well-known scratch dword in the configuration space. The host > reads from the dword and finds the opregion that way. Right, that's the physical mapping, Andy's patches are mimicking that behavior virtually. Seabios reserves memory, creates e820 entries, and "maps" the hardware by writing to these registers. That triggers QEMU to adjust the MemoryRegion in the guest address space which is an mmap to the host address space, using /dev/mem for now, but hopefully the vfio file descriptor in the future (I should be careful what I hope for). The opregion is pretty trivial because the write is to the IGD itself. The others are to the host bridge, so we need to figure out what sort of abstraction makes sense to get that back into vfio code. Perhaps vfio creates all the memory regions and registers them into an igd service and the host bridge can make calls like: gtt = igd_get_gtt_mr(); which returns NULL and nothing happens or the registered MemoryRegion and the host bridge places it into the address space. Thanks, Alex ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] tools/null_state_gen: Add GEN9 golden context batch buffer creation
I went through and compared this against both the spec (the state commands
listed in 3D-Media-GPGPU chapter 3D Pipeline Stages section) and the other
information I've seen on recommended setup, and as far as I can tell this
looks good. It still might be worth getting another set of eyes on this,
but it is
Reviewed-by: Brad Volkin
On Wed, Sep 24, 2014 at 05:50:32AM -0700, Mika Kuoppala wrote:
> From: Armin Reese
>
> Modifications to 'null_state_gen' so it can generate GEN9
> golden context batch buffer source for SKL.
>
> v2: - rebased on top of gen8 changes (Mika)
> - fixed state base address command size (Mika)
> - base address size macro as pages (Mika)
>
> Signed-off-by: Armin Reese
> Signed-off-by: Mika Kuoppala
> ---
> lib/gen9_render.h | 8 +
> tools/null_state_gen/Makefile.am | 3 +-
> tools/null_state_gen/intel_null_state_gen.c | 34 +-
> tools/null_state_gen/intel_renderstate_gen9.c | 442
> ++
> 4 files changed, 476 insertions(+), 11 deletions(-)
> create mode 100644 lib/gen9_render.h
> create mode 100644 tools/null_state_gen/intel_renderstate_gen9.c
>
> diff --git a/lib/gen9_render.h b/lib/gen9_render.h
> new file mode 100644
> index 000..a061808
> --- /dev/null
> +++ b/lib/gen9_render.h
> @@ -0,0 +1,8 @@
> +#ifndef GEN9_RENDER_H
> +#define GEN9_RENDER_H
> +
> +#include "gen8_render.h"
> +
> +#define GEN9_PIPELINE_SELECT (GEN6_3D(1, 1, 4) | (3 << 8))
> +
> +#endif /* GEN9_RENDER_H */
> diff --git a/tools/null_state_gen/Makefile.am
> b/tools/null_state_gen/Makefile.am
> index 58fbd53..b131e0d 100644
> --- a/tools/null_state_gen/Makefile.am
> +++ b/tools/null_state_gen/Makefile.am
> @@ -8,9 +8,10 @@ intel_null_state_gen_SOURCES = \
> intel_renderstate_gen6.c \
> intel_renderstate_gen7.c \
> intel_renderstate_gen8.c \
> + intel_renderstate_gen9.c \
> intel_null_state_gen.c
>
> -gens := 6 7 8
> +gens := 6 7 8 9
>
> h = /tmp/intel_renderstate_gen$$gen.c
> state_headers: intel_null_state_gen
> diff --git a/tools/null_state_gen/intel_null_state_gen.c
> b/tools/null_state_gen/intel_null_state_gen.c
> index a7eb22b..1021a37 100644
> --- a/tools/null_state_gen/intel_null_state_gen.c
> +++ b/tools/null_state_gen/intel_null_state_gen.c
> @@ -5,21 +5,23 @@
>
> #include "intel_batchbuffer.h"
>
> -#define STATE_ALIGN 64
> -
> extern int gen6_setup_null_render_state(struct intel_batchbuffer *batch);
> extern int gen7_setup_null_render_state(struct intel_batchbuffer *batch);
> extern int gen8_setup_null_render_state(struct intel_batchbuffer *batch);
> +extern int gen9_setup_null_render_state(struct intel_batchbuffer *batch);
>
> static int debug = 0;
>
> static void print_usage(char *s)
> {
> fprintf(stderr, "%s: \n"
> - " gen: gen to generate for (6,7,8)\n",
> -s);
> + " gen: gen to generate for (6,7,8,9)\n",
> + s);
> }
>
> +/* Creates the intel_renderstate_genX.c file for the particular
> + * GEN product
> + */
> static int print_state(int gen, struct intel_batchbuffer *batch)
> {
> int i;
> @@ -29,24 +31,32 @@ static int print_state(int gen, struct intel_batchbuffer
> *batch)
>
> printf("#include \"intel_renderstate.h\"\n\n");
>
> + /* Relocation offsets. These are byte offsets in the golden context
> + * batch buffer where the BB graphics address will be added to
> + * the indirect state offset already stored in those locations. The
> + * resulting value will inform the GPU where the indirect states are.
> + */
> printf("static const u32 gen%d_null_state_relocs[] = {\n", gen);
> for (i = 0; i < batch->cmds->num_items; i++) {
> if (intel_batch_is_reloc(batch, i))
> printf("\t0x%08x,\n", i * 4);
> }
> - printf("\t%d,\n", -1);
> - printf("};\n\n");
> + printf("\t-1,\n};\n\n");
>
> + /* GPU commands to execute to set up the RCS golden state. This
> + * state will become the default config.
> + */
> printf("static const u32 gen%d_null_state_batch[] = {\n", gen);
> for (i = 0; i < intel_batch_num_cmds(batch); i++) {
> + const int offset = i * 4;
> const struct bb_item *cmd = intel_batch_cmd_get(batch, i);
> printf("\t0x%08x,", cmd->data);
>
> if (debug)
> - printf("\t /* 0x%08x %s '%s' */", i * 4,
> -intel_batch_type_as_str(cmd), cmd->str);
> + printf("\t /* 0x%08x %s '%s' */", offset,
> + intel_batch_type_as_str(cmd), cmd->str);
>
> - if (i * 4 == batch->cmds_end_offset) {
> + if (offset == batch->cmds_end_offset) {
> cmds = i + 1;
> printf("\t /* cmds end */");
> }
> @@ -54,7 +64,7 @@ static int print_
Re: [Intel-gfx] [PULL] topic/core-stuff
On 25 September 2014 03:59, Daniel Vetter wrote: > On Wed, Sep 24, 2014 at 6:24 PM, Ilia Mirkin wrote: >> On Wed, Sep 24, 2014 at 6:24 AM, Daniel Vetter >> wrote: >>> Hi Dave, >>> >>> Just noticed that you've picked up the header rework stuff already, so >>> I've rebased that out again. Otherwise just two stragglers from the vblank >>> rework and the universal cursor planes locking fix. Plus sprinkling >>> container_of all over fbdev emulation from Fabian. >> >> I thought it was questionable whether these were desired... the >> pattern of casting between structs that contain others as bases is a >> pretty common one, and container_of just makes it harder to read. Did >> the discussion end in a way that concluded the opposite? I might have >> missed it. > > I like them since you can employ gcc to check mundane stuff for you. > And container_of is so massively established in the kernel (with > list_head alone) that I don't think any serious kernel hacker has > problem's reading it. Alan Cox complained a bit a bit on imo elitist > grounds so until someone goes on record with an official Nack I think > they're worth it. I like them, but I don't want to encourage them, they are over time going to just be conflict creators, which makes it sounds like work for me, So I don't mind this batch for the fbdev, but I don't want to see anymore unless they provide more value. also I'm on holidays until Tuesday, I'll have some access to stuff, but won't be on top of urgent things, so hopefully nothing urgent happens. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Qemu-devel] [IGDVFIO] [PATCH 3/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
Il 24/09/2014 22:57, Alex Williamson ha scritto: > Right, that's the physical mapping, Andy's patches are mimicking that > behavior virtually. Seabios reserves memory, creates e820 entries, and > "maps" the hardware by writing to these registers. That triggers QEMU > to adjust the MemoryRegion in the guest address space which is an mmap > to the host address space, using /dev/mem for now, but hopefully the > vfio file descriptor in the future (I should be careful what I hope > for). Yeah, I remember discussing that with Andrew on IRC. So he did implement that idea. > The opregion is pretty trivial because the write is to the IGD itself. > The others are to the host bridge, so we need to figure out what sort of > abstraction makes sense to get that back into vfio code. Do we have to support all chipsets? IIUC the more recent devices need fewer and fewer "backdoors". Paolo > Perhaps vfio creates all the memory regions and registers them into an > igd service and the host bridge can make calls like: > > gtt = igd_get_gtt_mr(); > > which returns NULL and nothing happens or the registered MemoryRegion > and the host bridge places it into the address space. Thanks, ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
