Re: [Intel-gfx] [PATCH] drm/i915/bios: Fix the sequence size calculations for MIPI seq v3
On Thu, 2016-01-14 at 17:12 +0200, Jani Nikula wrote:
> Two errors in a single line. The size was read from the wrong offset,
> and the end index didn't take the five bytes for sequence byte and size
> of sequence into account. Fix it all, and break up the calculations a
> bit to make it clearer.
>
Tested-by: Mika Kahola
> Cc: Ville Syrjälä
> Reported-by: Mika Kahola
> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_bios.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 12e2f8b8bf9c..bf62a19c8f69 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -842,6 +842,7 @@ static int goto_next_sequence_v3(const u8 *data, int
> index, int total)
> {
> int seq_end;
> u16 len;
> + u32 size_of_sequence;
>
> /*
>* Could skip sequence based on Size of Sequence alone, but also do some
> @@ -852,14 +853,24 @@ static int goto_next_sequence_v3(const u8 *data, int
> index, int total)
> return 0;
> }
>
> - seq_end = index + *((const u32 *)(data + 1));
> + /* Skip Sequence Byte. */
> + index++;
> +
> + /*
> + * Size of Sequence. Excludes the Sequence Byte and the size itself,
> + * includes MIPI_SEQ_ELEM_END byte, excludes the final MIPI_SEQ_END
> + * byte.
> + */
> + size_of_sequence = *((const uint32_t *)(data + index));
> + index += 4;
> +
> + seq_end = index + size_of_sequence;
> if (seq_end > total) {
> DRM_ERROR("Invalid sequence size\n");
> return 0;
> }
>
> - /* Skip Sequence Byte and Size of Sequence. */
> - for (index = index + 5; index < total; index += len) {
> + for (; index < total; index += len) {
> u8 operation_byte = *(data + index);
> index++;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl
On Thu, 14 Jan 2016, Jonathan Corbet wrote: > On Thu, 14 Jan 2016 22:03:26 +0200 > Jani Nikula wrote: > >> What if we added support for some markup language as an alternative to >> DocBook for the high level documentation? What if we taught kernel-doc >> to output said markup natively, and included those generated pieces into >> the high level documentation using the markup's own include directives? >> At least AsciiDoc and reStructuredText support this. > > That is kind of what I've been thinking. I think we could dispense with > docbook entirely, simplifying the toolchain and making the template files > easier to read and edit. Something like that would also make it easy to > keep the regular .txt documents in a structured form and to integrate them > into the "formatted" documents if it makes sense. Thanks, this is enough encouragement that maybe I'll toy around with this a little more in my, uh, copious free time. > Jani, want to join us at LCA and talk about it? :) Heh, sure I'd *want* to... 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 0/7] Misc WM fixes and Arbitrated Display Bandwidth WA for SKL
On 01/15/2016 07:18 AM, Matt Roper wrote: On Thu, Jan 14, 2016 at 05:32:41PM +0530, Shobhit Kumar wrote: Hi, This series add a set of updates to the WM calculation and also enables arbitrated display bandwidth based WA. Some of these patches do overlap with Matts work but we wanted to send them out as we have them in our internal testing for early review. Most likley some of them can be superceded by patches from Matt, or can be re-used if deemed necessary. I've left some feedback on your patches, but it was all pretty minor; they look pretty good overall. So I think we should polish up this set and merge it; I've got more SKL WM work coming (more atomic-y watermark calculation and programming) but I'll hold off on that until your series lands so that I don't cause too much thrash. Thanks Matt for the quick review. I will get the comments addressed and final patches uploaded quickly. Regards Shobhit Thanks. Matt Especially "drm/i915/skl+: Use fb size for relative data rate calculation" this already addresses some of Ville's comment on similar patch from Matt. Regards Shobhit Kumar, Mahesh (6): drm/i915/skl+: Use proper bytes_per_pixel during WM calculation drm/i915/skl+: Use fb size for relative data rate calculation drm/i915/skl+: calculate ddb minimum allocation drm/i915/skl+: calculate plane pixel rate. drm/i915/skl+: Use scaling amount for plane data rate calculation drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW Shobhit Kumar (1): drm/i915: Add support to parse DMI table and get platform memory info drivers/gpu/drm/i915/i915_dma.c | 19 +++ drivers/gpu/drm/i915/i915_drv.h | 15 ++ drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_pm.c | 294 +-- 4 files changed, 316 insertions(+), 14 deletions(-) -- 2.4.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use the active wm config for merging on ILK-BDW
On Thu, Jan 14, 2016 at 02:53:35PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> ilk_program_watermarks() is supposed to merge the active watermarks from
> all pipes. Thus we need to use the active config too instead of some
> precomputed stuff.
So to clarify, the bug you're fixing here would be if we have racing
commits that operate on disjoint sets of CRTC's; in that case the second
one that actually gets into wm_mutex will fail to see the config changes
made by the first commit, right?
Seems like we could go ahead and remove dev_priv->wm.config (and
calc_watermark_data() that builds it) since it's not actually doing us
any good. Although it's probably fine to hold that off to a subsequent
patch.
Both of your patches are
Reviewed-by: Matt Roper
CI results do report SKL failures, but those are clearly bogus since SKL
doesn't even run any of the functions that you're changing in these two
patches; as you noted, it looks more like the machine had some kind of
bizarre hardware failure that was unrelated to the patchset. The other
results look clean. Given that, I've gone ahead and pushed your patches
to dinq. Thanks!
Matt
>
> Fixes: aa363136866c ("drm/i915: Calculate watermark configuration during
> atomic check (v2)")
> Cc: Matt Roper
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 32 ++--
> 1 file changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index e9f4e6e7b736..f44a961183d7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3680,23 +3680,43 @@ static void skl_update_wm(struct drm_crtc *crtc)
> dev_priv->wm.skl_hw = *results;
> }
>
> +static void ilk_compute_wm_config(struct drm_device *dev,
> + struct intel_wm_config *config)
> +{
> + struct intel_crtc *crtc;
> +
> + /* Compute the currently _active_ config */
> + for_each_intel_crtc(dev, crtc) {
> + const struct intel_pipe_wm *wm = &crtc->wm.active.ilk;
> +
> + if (!wm->pipe_enabled)
> + continue;
> +
> + config->sprites_enabled |= wm->sprites_enabled;
> + config->sprites_scaled |= wm->sprites_scaled;
> + config->num_pipes_active++;
> + }
> +}
> +
> static void ilk_program_watermarks(struct drm_i915_private *dev_priv)
> {
> struct drm_device *dev = dev_priv->dev;
> struct intel_pipe_wm lp_wm_1_2 = {}, lp_wm_5_6 = {}, *best_lp_wm;
> struct ilk_wm_maximums max;
> - struct intel_wm_config *config = &dev_priv->wm.config;
> + struct intel_wm_config config = {};
> struct ilk_wm_values results = {};
> enum intel_ddb_partitioning partitioning;
>
> - ilk_compute_wm_maximums(dev, 1, config, INTEL_DDB_PART_1_2, &max);
> - ilk_wm_merge(dev, config, &max, &lp_wm_1_2);
> + ilk_compute_wm_config(dev, &config);
> +
> + ilk_compute_wm_maximums(dev, 1, &config, INTEL_DDB_PART_1_2, &max);
> + ilk_wm_merge(dev, &config, &max, &lp_wm_1_2);
>
> /* 5/6 split only in single pipe config on IVB+ */
> if (INTEL_INFO(dev)->gen >= 7 &&
> - config->num_pipes_active == 1 && config->sprites_enabled) {
> - ilk_compute_wm_maximums(dev, 1, config, INTEL_DDB_PART_5_6,
> &max);
> - ilk_wm_merge(dev, config, &max, &lp_wm_5_6);
> + config.num_pipes_active == 1 && config.sprites_enabled) {
> + ilk_compute_wm_maximums(dev, 1, &config, INTEL_DDB_PART_5_6,
> &max);
> + ilk_wm_merge(dev, &config, &max, &lp_wm_5_6);
>
> best_lp_wm = ilk_find_best_result(dev, &lp_wm_1_2, &lp_wm_5_6);
> } else {
> --
> 2.4.10
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] Misc WM fixes and Arbitrated Display Bandwidth WA for SKL
On Thu, Jan 14, 2016 at 05:32:41PM +0530, Shobhit Kumar wrote: > Hi, > This series add a set of updates to the WM calculation and also enables > arbitrated display bandwidth based WA. Some of these patches do overlap > with Matts work but we wanted to send them out as we have them in our > internal testing for early review. Most likley some of them can be > superceded by patches from Matt, or can be re-used if deemed necessary. I've left some feedback on your patches, but it was all pretty minor; they look pretty good overall. So I think we should polish up this set and merge it; I've got more SKL WM work coming (more atomic-y watermark calculation and programming) but I'll hold off on that until your series lands so that I don't cause too much thrash. Thanks. Matt > > Especially "drm/i915/skl+: Use fb size for relative data rate calculation" > this already addresses some of Ville's comment on similar patch from Matt. > > Regards > Shobhit > > Kumar, Mahesh (6): > drm/i915/skl+: Use proper bytes_per_pixel during WM calculation > drm/i915/skl+: Use fb size for relative data rate calculation > drm/i915/skl+: calculate ddb minimum allocation > drm/i915/skl+: calculate plane pixel rate. > drm/i915/skl+: Use scaling amount for plane data rate calculation > drm/i915/skl: WA for watermark calculation based on Arbitrated Display > BW > > Shobhit Kumar (1): > drm/i915: Add support to parse DMI table and get platform memory info > > drivers/gpu/drm/i915/i915_dma.c | 19 +++ > drivers/gpu/drm/i915/i915_drv.h | 15 ++ > drivers/gpu/drm/i915/intel_drv.h | 2 + > drivers/gpu/drm/i915/intel_pm.c | 294 > +-- > 4 files changed, 316 insertions(+), 14 deletions(-) > > -- > 2.4.3 > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Add support to parse DMI table and get platform memory info
On Thu, Jan 14, 2016 at 05:32:47PM +0530, Shobhit Kumar wrote:
> This is needed for WM computation workaround for arbitrated display
> bandwidth.
>
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/i915/i915_dma.c | 19 +++
> drivers/gpu/drm/i915/i915_drv.h | 6 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index a0f5659..03c3131 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -49,6 +49,7 @@
> #include
> #include
> #include
> +#include
>
>
> static int i915_getparam(struct drm_device *dev, void *data,
> @@ -855,6 +856,21 @@ static void intel_init_dpio(struct drm_i915_private
> *dev_priv)
> }
> }
>
> +static void dmi_decode_memory_info(const struct dmi_header *hdr, void *priv)
> +{
> + struct drm_i915_private *dev_priv = (struct drm_i915_private *) priv;
> + const u8 *data = (const u8 *) hdr;
> +
> + if (hdr->type == 17 && hdr->length > 0x17) {
I think there are some constants in include/linux/dmi.h that we can use
instead of magic numbers. DMI_ENTRY_MEM_DEVICE.
I'm not familiar with any of this DMI stuff; it seems like there are
functions elsewhere in the kernel (e.g., decode_dclk() in
drivers/edac/i7core_edac.c) that decode this into a memdev_dmi_entry and
then do some more robust/paranoid checking to determine the actual
speed. Unfortunately it's static to that file and not directly callable
by us.
I wonder if it would make sense to refactor that structure and decoding
out into the general DMI files and export them for module use so that we
could just call those functions.
Matt
> +
> + /* Found a memory channel */
> + dev_priv->dmi.mem_channel++;
> +
> + /* Get the speed */
> + dev_priv->dmi.mem_speed = (uint16_t) (*((uint16_t *)(data +
> 0x15)));
> + }
> +}
> +
> /**
> * i915_driver_load - setup chip and create an initial config
> * @dev: DRM device
> @@ -882,6 +898,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> dev->dev_private = dev_priv;
> dev_priv->dev = dev;
>
> + /* walk the dmi device table for getting platform memory information */
> + dmi_walk(dmi_decode_memory_info, (void *) dev_priv);
> +
> /* Setup the write-once "constant" device info */
> device_info = (struct intel_device_info *)&dev_priv->info;
> memcpy(device_info, info, sizeof(dev_priv->info));
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 104bd18..f588993 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1962,6 +1962,12 @@ struct drm_i915_private {
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
>*/
> +
> + /* DMI data for memory bandwidth calculation */
> + struct {
> + uint16_t mem_channel;
> + uint16_t mem_speed;
> + } dmi;
> };
>
> static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
> --
> 2.4.3
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915/skl+: Use scaling amount for plane data rate calculation
On Thu, Jan 14, 2016 at 05:32:46PM +0530, Shobhit Kumar wrote:
> From: "Kumar, Mahesh"
>
> Signed-off-by: Kumar, Mahesh
> ---
> drivers/gpu/drm/i915/intel_pm.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ffcc56a..dc08494 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2978,6 +2978,8 @@ skl_plane_relative_data_rate(const struct
> intel_crtc_state *cstate,
> struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
> struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
> struct drm_framebuffer *fb = pstate->fb;
> + struct intel_plane *intel_plane = to_intel_plane(pstate->plane);
> + uint32_t down_scale_amount, data_rate;
> uint32_t width = 0, height = 0;
>
> if (drm_rect_width(&intel_pstate->src)) {
> @@ -2994,15 +2996,19 @@ skl_plane_relative_data_rate(const struct
> intel_crtc_state *cstate,
> /* for planar format */
> if (fb->pixel_format == DRM_FORMAT_NV12) {
> if (y) /* y-plane data rate */
> - return width * height *
> + data_rate = width * height *
> drm_format_plane_cpp(fb->pixel_format, 0);
> else/* uv-plane data rate */
> - return (width / 2) * (height / 2) *
> + data_rate = (width / 2) * (height / 2) *
> drm_format_plane_cpp(fb->pixel_format, 1);
> }
>
> /* for packed formats */
> - return width * height * drm_format_plane_cpp(fb->pixel_format, 0);
> + data_rate = width * height * drm_format_plane_cpp(fb->pixel_format, 0);
This needs to be moved into an 'else' block now, otherwise you'll
clobber the NV12 values you calculated above.
Matt
> + down_scale_amount = skl_plane_downscale_amount(intel_plane);
> +
> + return DIV_ROUND_UP((data_rate * down_scale_amount), 1000);
> +
> }
>
> /*
> --
> 2.4.3
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/skl+: calculate plane pixel rate.
On Thu, Jan 14, 2016 at 05:32:45PM +0530, Shobhit Kumar wrote:
> From: "Kumar, Mahesh"
>
> Don't use pipe pixel rate for plane pixel rate.
> Calculate plane pixel according to formula
>
> adjusted plane_pixel_rate = adjusted pipe_pixel_rate * downscale ammount
>
> downscale amount = max[1, src_h/dst_h] * max[1, src_w/dst_w]
> if 90/270 rotation use rotated width & height
>
> Signed-off-by: Kumar, Mahesh
> ---
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> drivers/gpu/drm/i915/intel_pm.c | 95
> +++-
> 2 files changed, 95 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 059b46e..49f237e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -661,6 +661,8 @@ struct intel_plane_wm_parameters {
> u64 tiling;
> unsigned int rotation;
> uint16_t fifo_size;
> + /* Stores the adjusted plane pixel rate for WM calculation */
> + uint32_t plane_pixel_rate;
> };
>
> struct intel_plane {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 64b39ec..ffcc56a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2841,6 +2841,54 @@ skl_wm_plane_id(const struct intel_plane *plane)
> }
> }
>
> +/*
> + * This function takes drm_plane_state as input
> + * and decides the downscale amount according to the formula
> + *
> + * downscale amount = Max[1, Horizontal source size / Horizontal dest size]
> + *
> + * Return value is multiplied by 1000 to retain fractional part
> + * Caller should take care of dividing & Rounding off the value
Would it be simpler to just continue using 16.16 fixed point format?
Also, are there any helpers in drm_rect.c that we can use to simplify
this at all?
> + */
> +static uint32_t
> +skl_plane_downscale_amount(const struct intel_plane *intel_plane)
> +{
> + struct drm_plane_state *pstate = intel_plane->base.state;
> + struct intel_crtc *crtc = to_intel_crtc(pstate->crtc);
> + struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
> + uint32_t downscale_h, downscale_w;
> + uint32_t src_w, src_h, dst_w, dst_h, tmp;
> +
> + if (drm_rect_width(&intel_pstate->src)) {
> + src_w = drm_rect_width(&intel_pstate->src) >> 16;
> + src_h = drm_rect_height(&intel_pstate->src) >> 16;
> + } else {
> + src_w = crtc->config->pipe_src_w;
> + src_h = crtc->config->pipe_src_h;
> + }
> +
> + dst_w = drm_rect_width(&intel_pstate->dst);
> + dst_h = drm_rect_height(&intel_pstate->dst);
> +
> + if (intel_rotation_90_or_270(pstate->rotation))
> + swap(dst_w, dst_h);
> +
> + /* If destination height & wight are zero return amount as unity */
> + if (dst_w == 0 || dst_h == 0)
> + return 1000;
> +
> + /* Multiply by 1000 for precision */
> + tmp = (1000 * src_h) / dst_h;
> + downscale_h = max_t(uint32_t, 1000, tmp);
> +
> + tmp = (1000 * src_w) / dst_w;
> + downscale_w = max_t(uint32_t, 1000, tmp);
> +
> + /* Reducing precision to 3 decimal places */
> + return DIV_ROUND_UP(downscale_h * downscale_w, 1000);
> +}
> +
> +
> static void
> skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
> const struct intel_crtc_state *cstate,
> @@ -3265,10 +3313,10 @@ static bool skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
> bytes_per_pixel = (fb->pixel_format == DRM_FORMAT_NV12) ?
> drm_format_plane_cpp(fb->pixel_format, 1) :
> drm_format_plane_cpp(fb->pixel_format, 0);
> - method1 = skl_wm_method1(skl_pipe_pixel_rate(cstate),
> + method1 = skl_wm_method1(intel_plane->wm.plane_pixel_rate,
>bytes_per_pixel,
>latency);
> - method2 = skl_wm_method2(skl_pipe_pixel_rate(cstate),
> + method2 = skl_wm_method2(intel_plane->wm.plane_pixel_rate,
>cstate->base.adjusted_mode.crtc_htotal,
>width,
>bytes_per_pixel,
> @@ -3709,6 +3757,46 @@ static void skl_update_other_pipe_wm(struct drm_device
> *dev,
> }
> }
>
> +static uint32_t
> +skl_plane_pixel_rate(struct intel_crtc_state *cstate, struct intel_plane
> *plane)
> +{
> + uint32_t adjusted_pixel_rate;
> + uint32_t downscale_amount;
> +
> + /*
> + * adjusted plane pixel rate = adjusted pipe pixel rate
> + * Plane pixel rate = adjusted plane pixel rate * plane down scale
> + * amount
> + */
> + adjusted_pixel_rate = skl_pipe_pixel_rate(cstate);
> + downscale_amount = skl_plane_downscale_amount(plane);
> +
> + return DIV_ROUND_UP(adjusted_pixel_rate * downscale_amount,
> + 1000);
> +}
> +
> +static vo
Re: [Intel-gfx] [PATCH 3/7] drm/i915/skl+: calculate ddb minimum allocation
On Thu, Jan 14, 2016 at 05:32:44PM +0530, Shobhit Kumar wrote:
> From: "Kumar, Mahesh"
>
> don't always use 8 ddb as minimum, instead calculate using proper
> algorithm.
>
> Signed-off-by: Kumar, Mahesh
> ---
> drivers/gpu/drm/i915/intel_pm.c | 57
> +++--
> 1 file changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d33c4ff..64b39ec 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2994,6 +2994,59 @@ skl_get_total_relative_data_rate(const struct
> intel_crtc_state *cstate)
> return total_data_rate;
> }
>
> +static uint16_t
> +skl_ddb_min_alloc(const struct intel_crtc *crtc,
> + const struct drm_plane *plane, int y)
> +{
> + struct drm_framebuffer *fb = plane->state->fb;
> + struct intel_plane_state *pstate = to_intel_plane_state(plane->state);
> + uint16_t min_alloc;
> + uint32_t src_w, src_h;
> +
> + /* For packed formats, no y-plane, return 0 */
> + if (y && !(fb->pixel_format == DRM_FORMAT_NV12))
> + return 0;
Your general logic all looks fine, but I'd move the simple/common case
of !tile-y up here and immediately return the constant 8 to make it a
bit more obvious. Then the remaining code below will only apply to
tile-y formats and you can even remove a level of nesting farther down.
> +
> + if (drm_rect_width(&pstate->src)) {
> + src_w = drm_rect_width(&pstate->src) >> 16;
> + src_h = drm_rect_height(&pstate->src) >> 16;
> + } else {
> + src_w = crtc->config->pipe_src_w;
> + src_h = crtc->config->pipe_src_h;
> + }
> +
> + if (intel_rotation_90_or_270(plane->state->rotation))
> + swap(src_w, src_h);
> +
> + if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> + fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> + uint32_t min_scanlines = 8;
> + uint8_t bytes_per_pixel =
> + y ? drm_format_plane_cpp(fb->pixel_format, 1) :
> + drm_format_plane_cpp(fb->pixel_format, 0);
Isn't this backwards? As noted on an earlier patch, the second
parameter isn't a "is y" boolean, but rather a "which plane number"
integer. For NV12, Y=0, UV=1.
> +
> + if (intel_rotation_90_or_270(plane->state->rotation)) {
> + switch (bytes_per_pixel) {
> + case 1:
> + min_scanlines = 32;
> + break;
> + case 2:
> + min_scanlines = 16;
> + break;
> + case 8:
> + WARN(1, "Unsupported pixel depth for rotation");
> + }
Can we simplify this to a min_scalines = 32/bpp instead of the switch statement?
Matt
> + }
> + min_alloc = DIV_ROUND_UP((4 * src_w / (y ? 1 : 2) *
> + bytes_per_pixel), 512) * min_scanlines/4 + 3;
> + } else {
> + min_alloc = 8;
> + }
> +
> + return min_alloc;
> +}
> +
> +
> static void
> skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
> struct skl_ddb_allocation *ddb /* out */)
> @@ -3038,9 +3091,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
> if (plane->type == DRM_PLANE_TYPE_CURSOR)
> continue;
>
> - minimum[id] = 8;
> + minimum[id] = skl_ddb_min_alloc(intel_crtc, plane, 0);
> alloc_size -= minimum[id];
> - y_minimum[id] = (fb->pixel_format == DRM_FORMAT_NV12) ? 8 : 0;
> + y_minimum[id] = skl_ddb_min_alloc(intel_crtc, plane, 1);
> alloc_size -= y_minimum[id];
> }
>
> --
> 2.4.3
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915/skl+: Use fb size for relative data rate calculation
On Thu, Jan 14, 2016 at 05:32:43PM +0530, Shobhit Kumar wrote:
> From: "Kumar, Mahesh"
>
> Use FB size for relative data rate calculation. don't always use
Minor wording nitpick: it's not really the FB size you're using here
but rather the plane size. The FB itself may be larger than the plane
and largely offscreen.
> pipe source width & height.
> adjust height & width according to rotation.
>
> Signed-off-by: Kumar, Mahesh
> ---
> drivers/gpu/drm/i915/intel_pm.c | 42
> -
> 1 file changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 68f21b9..d33c4ff 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2928,24 +2928,33 @@ skl_plane_relative_data_rate(const struct
> intel_crtc_state *cstate,
>int y)
> {
> struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
> + struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
> struct drm_framebuffer *fb = pstate->fb;
> + uint32_t width = 0, height = 0;
> +
> + if (drm_rect_width(&intel_pstate->src)) {
> + width = drm_rect_width(&intel_pstate->src) >> 16;
> + height = drm_rect_height(&intel_pstate->src) >> 16;
> + } else {
> + width = intel_crtc->config->pipe_src_w;
> + height = intel_crtc->config->pipe_src_h;
The else block would mean the plane is invisible (either off or fully
clipped), right? Shouldn't our relative data rate be 0 in that case
(instead of max possible)?
> + }
> +
> + if (intel_rotation_90_or_270(pstate->rotation))
> + swap(width, height);
>
> /* for planar format */
> if (fb->pixel_format == DRM_FORMAT_NV12) {
> if (y) /* y-plane data rate */
> - return intel_crtc->config->pipe_src_w *
> - intel_crtc->config->pipe_src_h *
> + return width * height *
> drm_format_plane_cpp(fb->pixel_format, 0);
> else/* uv-plane data rate */
> - return (intel_crtc->config->pipe_src_w/2) *
> - (intel_crtc->config->pipe_src_h/2) *
> + return (width / 2) * (height / 2) *
> drm_format_plane_cpp(fb->pixel_format, 1);
> }
>
> /* for packed formats */
> - return intel_crtc->config->pipe_src_w *
> - intel_crtc->config->pipe_src_h *
> - drm_format_plane_cpp(fb->pixel_format, 0);
> + return width * height * drm_format_plane_cpp(fb->pixel_format, 0);
> }
>
> /*
> @@ -3181,10 +3190,25 @@ static bool skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
> uint32_t res_blocks, res_lines;
> uint32_t selected_result;
> uint8_t bytes_per_pixel;
> + struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
> + struct intel_plane_state *intel_pstate =
> to_intel_plane_state(plane->state);
> + uint32_t width = 0, height = 0;
>
> if (latency == 0 || !cstate->base.active || !fb)
> return false;
>
> + if (drm_rect_width(&intel_pstate->src)) {
> + width = drm_rect_width(&intel_pstate->src) >> 16;
> + height = drm_rect_height(&intel_pstate->src) >> 16;
> + } else {
> + width = intel_crtc->config->pipe_src_w;
> + height = intel_crtc->config->pipe_src_h;
> + }
We're already bailing above this on !fb; shouldn't we do the same on a
plane that has a valid fb but is disabled due to being fully clipped
(which I think is the only thing that will trigger the else block here)?
Matt
> +
> + if (intel_rotation_90_or_270(plane->state->rotation))
> + swap(width, height);
> +
> + /* for planar format */
> bytes_per_pixel = (fb->pixel_format == DRM_FORMAT_NV12) ?
> drm_format_plane_cpp(fb->pixel_format, 1) :
> drm_format_plane_cpp(fb->pixel_format, 0);
> @@ -3193,12 +3217,12 @@ static bool skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
>latency);
> method2 = skl_wm_method2(skl_pipe_pixel_rate(cstate),
>cstate->base.adjusted_mode.crtc_htotal,
> - cstate->pipe_src_w,
> + width,
>bytes_per_pixel,
>fb->modifier[0],
>latency);
>
> - plane_bytes_per_line = cstate->pipe_src_w * bytes_per_pixel;
> + plane_bytes_per_line = width * bytes_per_pixel;
> plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
>
> if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> --
> 2.4.3
>
--
Matt Roper
Graphics Software Engineer
Re: [Intel-gfx] [PATCH v4] drm/i915: edp resume/On time optimization.
On 1/12/2016 5:57 PM, Kumar, Abhay wrote:
From: Abhay Kumar
Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.
v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle
delay calculation(Ville).
v3: Addressed below comments
1. Tracking time from where last powercycle is initiated.
2. Used ktime_get_bootime() wrapper for boottime clock.
3. Used ktime_ms_delta() to get time difference.
v4: Updated v3 change log in detail.
Cc: Ville Syrjälä
Signed-off-by: Abhay Kumar
---
drivers/gpu/drm/i915/intel_dp.c | 19 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 796e3d3..0042693 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1812,12 +1812,21 @@ static void wait_panel_off(struct intel_dp *intel_dp)
static void wait_panel_power_cycle(struct intel_dp *intel_dp)
{
+ static ktime_t panel_power_on_time;
+ s64 panel_power_off_duration;
+
DRM_DEBUG_KMS("Wait for panel power cycle\n");
+ /* take the difference of currrent time and panel power off time
+* and then make panel wait for t11_t12 if needed. */
+ panel_power_on_time = ktime_get_boottime();
+ panel_power_off_duration = ktime_ms_delta(panel_power_on_time,
intel_dp->panel_power_off_time);
+
/* When we disable the VDD override bit last we have to do the manual
* wait. */
- wait_remaining_ms_from_jiffies(intel_dp->last_power_cycle,
- intel_dp->panel_power_cycle_delay);
+ if (panel_power_off_duration < (s64)intel_dp->panel_power_cycle_delay)
+ wait_remaining_ms_from_jiffies(jiffies,
+ intel_dp->panel_power_cycle_delay -
panel_power_off_duration);
wait_panel_status(intel_dp, IDLE_CYCLE_MASK, IDLE_CYCLE_VALUE);
}
@@ -1969,7 +1978,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp
*intel_dp)
I915_READ(pp_stat_reg), I915_READ(pp_ctrl_reg));
if ((pp & POWER_TARGET_ON) == 0)
- intel_dp->last_power_cycle = jiffies;
+ intel_dp->panel_power_off_time = ktime_get_boottime();
power_domain = intel_display_port_aux_power_domain(intel_encoder);
intel_display_power_put(dev_priv, power_domain);
@@ -2118,7 +2127,7 @@ static void edp_panel_off(struct intel_dp *intel_dp)
I915_WRITE(pp_ctrl_reg, pp);
POSTING_READ(pp_ctrl_reg);
- intel_dp->last_power_cycle = jiffies;
+ intel_dp->panel_power_off_time = ktime_get_boottime();
wait_panel_off(intel_dp);
/* We got a reference when we enabled the VDD. */
@@ -5122,7 +5131,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
{
- intel_dp->last_power_cycle = jiffies;
+ intel_dp->panel_power_off_time = ktime_get_boottime();
intel_dp->last_power_on = jiffies;
intel_dp->last_backlight_off = jiffies;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index bdfe403..06b37b8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -793,9 +793,9 @@ struct intel_dp {
int backlight_off_delay;
struct delayed_work panel_vdd_work;
bool want_panel_vdd;
- unsigned long last_power_cycle;
unsigned long last_power_on;
unsigned long last_backlight_off;
+ ktime_t panel_power_off_time;
struct notifier_block edp_notifier;
Hi Ville,
If we have everything addressed can we please get this pulled into
drm-nightly?
Regards,
Abhay Kumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Make display gtt offsets u32
On Thu, Jan 14, 2016 at 03:22:15PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Using 'unsigned long' for ggtt offsets doesn't make much sense. Use
> 'u32' instead since we've not yet seen a >4GiB ggtt.
We should do:
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2e460b369e82..2ce16acceb75 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3143,6 +3143,13 @@ int i915_gem_gtt_init(struct drm_device *dev)
if (ret)
return ret;
+ if (gtt->base.total >> 32) {
+ DRM_ERROR("The code does not expect a Global GTT with more that
32bits of address space! Found %lldM!\n",
+ gtt->base.total >> 20);
+ gtt->base.total = 1ull << 32;
+ gtt->mappable_end = min(gtt->mappable_end, gtt->base.total);
+ }
+
/* GMADR is the PCI mmio aperture into the global GTT. */
DRM_INFO("Memory usable by graphics device = %lluM\n",
gtt->base.total >> 20);
To get that early warning in.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Decouple execbuf uAPI from internal implementation
On Thu, Jan 14, 2016 at 03:02:59PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> At the moment execbuf ring selection is fully coupled to
> internal ring ids which is not a good thing on its own.
>
> This dependency is also spread between two source files and
> not spelled out at either side which makes it hidden and
> fragile.
>
> This patch decouples this dependency by introducing an explicit
> translation table of execbuf uAPI to ring id close to the only
> call site (i915_gem_do_execbuffer).
>
> This way we are free to change driver internal implementation
> details without breaking userspace. All state relating to the
> uAPI is now contained in, or next to, i915_gem_do_execbuffer.
I was hesistant at first, since "why?" isn't fully developed, but the
code won me over.
> +#define I915_USER_RINGS (4)
> +
> +static const enum intel_ring_id user_ring_map[I915_USER_RINGS + 1] = {
> + [I915_EXEC_DEFAULT] = RCS,
> + [I915_EXEC_RENDER] = RCS,
> + [I915_EXEC_BLT] = BCS,
> + [I915_EXEC_BSD] = VCS,
> + [I915_EXEC_VEBOX] = VECS
> +};
I was wondering whether packing here mattered at all, but we're under a
cacheline so highly unlikely.
> static int
> i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> struct drm_file *file,
> @@ -1393,6 +1393,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
> struct i915_execbuffer_params params_master; /* XXX: will be removed
> later */
> struct i915_execbuffer_params *params = ¶ms_master;
> const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
> + unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
> u32 dispatch_flags;
> int ret;
> bool need_relocs;
> @@ -1414,49 +1415,39 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
> if (args->flags & I915_EXEC_IS_PINNED)
> dispatch_flags |= I915_DISPATCH_PINNED;
>
> - if ((args->flags & I915_EXEC_RING_MASK) > LAST_USER_RING) {
> - DRM_DEBUG("execbuf with unknown ring: %d\n",
> - (int)(args->flags & I915_EXEC_RING_MASK));
> + if (user_ring_id > I915_USER_RINGS) {
> + DRM_DEBUG("execbuf with unknown ring: %u\n", user_ring_id);
> return -EINVAL;
> }
>
> - if (((args->flags & I915_EXEC_RING_MASK) != I915_EXEC_BSD) &&
> + if ((user_ring_id != I915_EXEC_BSD) &&
> ((args->flags & I915_EXEC_BSD_MASK) != 0)) {
> DRM_DEBUG("execbuf with non bsd ring but with invalid "
> "bsd dispatch flags: %d\n", (int)(args->flags));
> return -EINVAL;
> - }
> -
> - if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_DEFAULT)
> - ring = &dev_priv->ring[RCS];
> - else if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
> - if (HAS_BSD2(dev)) {
> - int ring_id;
> -
> - switch (args->flags & I915_EXEC_BSD_MASK) {
> - case I915_EXEC_BSD_DEFAULT:
> - ring_id = gen8_dispatch_bsd_ring(dev, file);
> - ring = &dev_priv->ring[ring_id];
> - break;
> - case I915_EXEC_BSD_RING1:
> - ring = &dev_priv->ring[VCS];
> - break;
> - case I915_EXEC_BSD_RING2:
> - ring = &dev_priv->ring[VCS2];
> - break;
> - default:
> - DRM_DEBUG("execbuf with unknown bsd ring: %d\n",
> - (int)(args->flags &
> I915_EXEC_BSD_MASK));
> - return -EINVAL;
> - }
> - } else
> - ring = &dev_priv->ring[VCS];
> - } else
> - ring = &dev_priv->ring[(args->flags & I915_EXEC_RING_MASK) - 1];
> + }
> +
> + if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev)) {
HAS_BSD2(dev_priv)
> + unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
> +
> + if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
> + bsd_idx = gen8_dispatch_bsd_ring(dev_priv, file);
> + } else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
> +bsd_idx <= I915_EXEC_BSD_RING2) {
> + bsd_idx--;
> + } else {
> + DRM_DEBUG("execbuf with unknown bsd ring: %u\n",
> + bsd_idx);
> + return -EINVAL;
> + }
> +
> + ring = &dev_priv->ring[_VCS(bsd_idx)];
> + } else {
> + ring = &dev_priv->ring[user_ring_map[user_ring_id]];
> + }
>
> if (!intel_ring_initialized(ring)) {
> - DRM_DEBUG("execbuf with invalid ring: %d\n",
> - (int)(args->flags & I915_
[Intel-gfx] [PATCH i-g-t] lib/igt_kms, tests/testdisplay: allow probing of new connector modes
Fixup some fallout from the connector probing changes so testdisplay -m
will pick up newly hotplugged displays correctly.
Signed-off-by: Jesse Barnes mode_valid = 0;
return;
}
@@ -456,7 +463,7 @@ set_stereo_mode(struct connector *c)
* Each connector has a corresponding encoder, except in the SDVO case
* where an encoder may have multiple connectors.
*/
-int update_display(void)
+int update_display(bool probe)
{
struct connector *connectors;
int c;
@@ -488,7 +495,7 @@ int update_display(void)
connector_find_preferred_mode(connector->id,
crtc_idx_mask,
specified_mode_num,
- connector);
+ connector, probe);
if (!connector->mode_valid)
continue;
@@ -513,7 +520,7 @@ int update_display(void)
connector_find_preferred_mode(connector->id,
-1UL,
specified_mode_num,
- connector);
+ connector, probe);
if (!connector->mode_valid)
continue;
@@ -765,7 +772,7 @@ int main(int argc, char **argv)
ret = 0;
- if (!update_display()) {
+ if (!update_display(false)) {
ret = 1;
goto out_stdio;
}
diff --git a/tests/testdisplay.h b/tests/testdisplay.h
index 962e621..27f8209 100644
--- a/tests/testdisplay.h
+++ b/tests/testdisplay.h
@@ -32,4 +32,4 @@ gboolean testdisplay_setup_hotplug(void);
void testdisplay_cleanup_hotplug(void);
/* called by the hotplug code */
-int update_display(void);
+int update_display(bool probe);
diff --git a/tests/testdisplay_hotplug.c b/tests/testdisplay_hotplug.c
index 9d11399..3b900ca 100644
--- a/tests/testdisplay_hotplug.c
+++ b/tests/testdisplay_hotplug.c
@@ -59,7 +59,7 @@ static gboolean hotplug_event(GIOChannel *source,
GIOCondition condition,
if (memcmp(&s.st_rdev, &udev_devnum, sizeof(dev_t)) == 0 &&
hotplug && atoi(hotplug) == 1)
- update_display();
+ update_display(true);
udev_device_unref(dev);
out:
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl
On Thu, 14 Jan 2016 22:03:26 +0200 Jani Nikula wrote: > What if we added support for some markup language as an alternative to > DocBook for the high level documentation? What if we taught kernel-doc > to output said markup natively, and included those generated pieces into > the high level documentation using the markup's own include directives? > At least AsciiDoc and reStructuredText support this. That is kind of what I've been thinking. I think we could dispense with docbook entirely, simplifying the toolchain and making the template files easier to read and edit. Something like that would also make it easy to keep the regular .txt documents in a structured form and to integrate them into the "formatted" documents if it makes sense. Jani, want to join us at LCA and talk about it? :) jon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave - Our first bag of fixes for drm-next/v4.5. BR, Jani. The following changes since commit 7447a2b221cd4df3960e82478a4ee29312589611: drm/i915: Update DRIVER_DATE to 20151218 (2015-12-18 20:26:17 +0100) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2016-01-14 for you to fetch changes up to 48ea1e32c39db94c59b63580b965222c7782112f: drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page (2016-01-13 10:50:55 +0200) Chris Wilson (2): drm/i915: Move Braswell stop_machine GGTT insertion workaround drm/i915: Restore inhibiting the load of the default context Daniel Vetter (1): drm/i915: Tune down rpm wakelock debug checks Jani Nikula (1): drm/i915: shut up gen8+ SDE irq dmesg noise, again Lyude (1): drm/i915: intel_hpd_init(): Fix suspend/resume reprobing Maarten Lankhorst (1): drm/i915: Widen return value for reservation_object_wait_timeout_rcu to long. Michał Winiarski (1): drm/i915: Avoid writing relocs with addresses in non-canonical form Michel Thierry (1): drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page drivers/gpu/drm/i915/i915_gem.c| 2 +- drivers/gpu/drm/i915/i915_gem_context.c| 6 +++- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 52 +++--- drivers/gpu/drm/i915/i915_gem_gtt.c| 50 +++- drivers/gpu/drm/i915/i915_irq.c| 10 -- drivers/gpu/drm/i915/intel_display.c | 14 drivers/gpu/drm/i915/intel_drv.h | 6 ++-- drivers/gpu/drm/i915/intel_hotplug.c | 9 -- 8 files changed, 108 insertions(+), 41 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 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl
On Tue, 12 Jan 2016, Jonathan Corbet wrote: > On Sat, 12 Dec 2015 12:13:45 +0100 > Daniel Vetter wrote: > >> I just figured there's no way this could get it, and I'd >> much rather improve the docs themselves than trying to convince core >> kernel folks that this might be useful. > > So I'm not quite sure why you figured that; I never said it, certainly. > > I've been messing with it a bit, seems to work. I do still wish we could > consider alternatives, especially those that might simplify the toolchain > rather than complicating it. But it's clear that I'm not succeeding in > finding time to actually explore that idea; the contents of $EXCUSES are > good, but the end result is the same. And the patch fairy just isn't > coming through for me on this one. > > In my mind, there's clearly no good that can come from (further) delaying > something that works in favor of an "it would be nice" that may never > even exist. So I'm currently thinking that I'll pull this into the docs > tree once the merge window is done, with the plan to push it for 4.6. > Then we can see if anybody screams. > > That gives a couple of weeks for an updated patch set, should you have > one. > > The build-time increase is painful in the extreme - about a factor of > three for a -j1 build, and that's with only one file using the feature. > It feels wrong, somehow, for the docs build to take longer than building > the kernel itself. Can we do something about that? > > - How many of the comments actually use asciidoc features? Might there >be some possibility of detecting those in kernel-doc and skipping the >callout to asciidoc when it's not needed? > > - Pandoc seems to do asciidoc. I still don't like the idea of depending >on it for this to work, but having the *option* to use it is fine. If >it's really that much faster (yes, Python startup is painful) then >maybe providing the option is worth it. > > - All over the kernel we've seen that batching improves performance. It >would take a bit of work, but I bet kernel-doc could put together all >the snippets from one file, pass them through a single asciidoc >invocation, then split the results back apart. That would probably >eliminate the performance hit entirely. I had another look at the whole thing, inspired by your lwn article [1]. I am guessing the whole design of calling the markup tool (asciidoc or pandoc or whatever) from kernel-doc for every documentation comment comes from trying really hard to minimize changes to the rest of the documentation system. From trying not to touch the DocBook parts so much. And thus the documentation build works really hard to convert thousands of markup snippets to DocBook and then again back to a bunch of other formats like html or pdf. What if we added support for some markup language as an alternative to DocBook for the high level documentation? What if we taught kernel-doc to output said markup natively, and included those generated pieces into the high level documentation using the markup's own include directives? At least AsciiDoc and reStructuredText support this. kernel-doc already supports several output formats, DocBook, HTML, plain text, man, whatnot. It should not be a big deal to add another. Even though I don't do perl (and that's the main reason I've generally steered clear anything kernel-doc) I toyed with adding reStructuredText support, and I got some sensible output surprisingly quickly. This would mean *one* kernel-doc invocation per source file included, and *one* markup tool invocation per high level document. Additionally there would have to be dependency generation from the high level document to the included files. As a bonus, one could write (and *read*!) the high level documentation in a markup that's meant for humans. If needed, at least AsciiDoc supports generating DocBook, which I suppose could be fed back to the existing documentation pipeline. > None of that is a condition for pulling this stuff in, but can it be > looked into? To be clear, I also don't want this idea to block the code that we have now from being merged. This is a longer term thing anyway. But I'd like to explore the alternatives. Thoughts? BR, Jani. [1] https://lwn.net/Articles/671496/ -- 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 1/7] drm/i915/skl+: Use proper bytes_per_pixel during WM calculation
On Thu, Jan 14, 2016 at 05:32:42PM +0530, Shobhit Kumar wrote: > From: "Kumar, Mahesh" > > Don't always use bytes_per_pixel using y_plane=0, instead use it > according to pixel format. If NV12 use y_plane eqal to 1 > > Signed-off-by: Kumar, Mahesh The second parameter to drm_format_plane_cpp() is the plane index (0 => Y = 1bpp, 1 => UV = 2bpp), so I think passing 0 actually was what we wanted, right? Matt > --- > drivers/gpu/drm/i915/intel_pm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 9df9e9a..68f21b9 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3185,7 +3185,9 @@ static bool skl_compute_plane_wm(const struct > drm_i915_private *dev_priv, > if (latency == 0 || !cstate->base.active || !fb) > return false; > > - bytes_per_pixel = drm_format_plane_cpp(fb->pixel_format, 0); > + bytes_per_pixel = (fb->pixel_format == DRM_FORMAT_NV12) ? > + drm_format_plane_cpp(fb->pixel_format, 1) : > + drm_format_plane_cpp(fb->pixel_format, 0); > method1 = skl_wm_method1(skl_pipe_pixel_rate(cstate), >bytes_per_pixel, >latency); > -- > 2.4.3 > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/22] drm: Create drm_send_event helpers
Hi Daniel,
Thank you for the patch.
On Monday 11 January 2016 22:40:59 Daniel Vetter wrote:
> Use them in the core vblank code and exynos/vmwgfx drivers.
>
> Note that the difference between wake_up_all and _interruptible in
> vmwgfx doesn't matter since the only waiter is the core code in
> drm_fops.c. And that is interruptible.
>
> v2: Adjust existing kerneldoc too.
>
> Reviewed-by: Alex Deucher (v1)
> Acked-by: Daniel Stone
> Cc: Alex Deucher
> Cc: Thomas Hellstrom
> Cc: Inki Dae
> Signed-off-by: Daniel Vetter
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_fops.c | 42 +-
> drivers/gpu/drm/drm_irq.c | 7 ++
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 5 +---
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 +---
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 3 +--
> include/drm/drmP.h | 2 ++
> 6 files changed, 48 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 476408b638e3..d85af1b2a238 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -683,7 +683,9 @@ EXPORT_SYMBOL(drm_poll);
> * This function prepares the passed in event for eventual delivery. If the
> event * doesn't get delivered (because the IOCTL fails later on, before
> queuing up * anything) then the even must be cancelled and freed using
> - * drm_event_cancel_free().
> + * drm_event_cancel_free(). Successfully initialized events should be sent
> out + * using drm_send_event() or drm_send_event_locked() to signal
> completion of the + * asynchronous event to userspace.
> *
> * If callers embedded @p into a larger structure it must be allocated with
> * kmalloc and @p must be the first member element.
> @@ -739,3 +741,41 @@ void drm_event_cancel_free(struct drm_device *dev,
> p->destroy(p);
> }
> EXPORT_SYMBOL(drm_event_cancel_free);
> +
> +/**
> + * drm_send_event_locked - send DRM event to file descriptor
> + * @dev: DRM device
> + * @e: DRM event to deliver
> + *
> + * This function sends the event @e, initialized with
> drm_event_reserve_init(), + * to its associated userspace DRM file. Callers
> must already hold + * dev->event_lock, see drm_send_event() for the
> unlocked version. + */
> +void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event
> *e) +{
> + assert_spin_locked(&dev->event_lock);
> +
> + list_add_tail(&e->link,
> + &e->file_priv->event_list);
> + wake_up_interruptible(&e->file_priv->event_wait);
> +}
> +EXPORT_SYMBOL(drm_send_event_locked);
> +
> +/**
> + * drm_send_event - send DRM event to file descriptor
> + * @dev: DRM device
> + * @e: DRM event to deliver
> + *
> + * This function sends the event @e, initialized with
> drm_event_reserve_init(), + * to its associated userspace DRM file. This
> function acquires dev->event_lock, + * see drm_send_event_locked() for
> callers which already hold this lock. + */
> +void drm_send_event(struct drm_device *dev, struct drm_pending_event *e)
> +{
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev->event_lock, irqflags);
> + drm_send_event_locked(dev, e);
> + spin_unlock_irqrestore(&dev->event_lock, irqflags);
> +}
> +EXPORT_SYMBOL(drm_send_event);
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index a70b29909974..3fe8dbff6058 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -983,15 +983,12 @@ static void send_vblank_event(struct drm_device *dev,
> struct drm_pending_vblank_event *e,
> unsigned long seq, struct timeval *now)
> {
> - assert_spin_locked(&dev->event_lock);
> -
> e->event.sequence = seq;
> e->event.tv_sec = now->tv_sec;
> e->event.tv_usec = now->tv_usec;
>
> - list_add_tail(&e->base.link,
> - &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> + drm_send_event_locked(dev, &e->base);
> +
> trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
>e->event.sequence);
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c index 82e7f95dfed9..db56c8259f18
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -893,10 +893,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32
> cmdlist_no) e->event.tv_usec = now.tv_usec;
> e->event.cmdlist_no = cmdlist_no;
>
> - spin_lock_irqsave(&drm_dev->event_lock, flags);
> - list_move_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> - spin_unlock_irqrestore(&drm_dev->event_lock, flags);
> + drm_send_event(dev, &e->base);
> }
>
> static irqreturn_t g2d_irq_handler(int irq, void *dev_id)
> diff --git a/drivers/gpu/drm/exynos/exynos_
Re: [Intel-gfx] [PATCH] drm: Clean up pending events in the core
Hi Daniel,
On Monday 11 January 2016 14:51:46 Daniel Stone wrote:
> On 10 January 2016 at 23:48, Laurent Pinchart wrote:
> > On Saturday 09 January 2016 14:28:46 Daniel Vetter wrote:
> >> @@ -353,18 +354,16 @@ static void drm_events_release(struct drm_file
> >> *file_priv) {
> >>
> >> struct drm_device *dev = file_priv->minor->dev;
> >> struct drm_pending_event *e, *et;
> >>
> >> - struct drm_pending_vblank_event *v, *vt;
> >>
> >> unsigned long flags;
> >>
> >> spin_lock_irqsave(&dev->event_lock, flags);
> >>
> >> - /* Remove pending flips */
> >> - list_for_each_entry_safe(v, vt, &dev->vblank_event_list, base.link)
> >> - if (v->base.file_priv == file_priv) {
> >> - list_del(&v->base.link);
> >> - drm_vblank_put(dev, v->pipe);
> >> - v->base.destroy(&v->base);
> >> - }
> >
> > Where does this code go ?
>
> It doesn't: instead of deleting the events, the helpers to either
> cancel or send the event just notice that file_priv is NULL and bail
> out early.
Thank you for the explanation. What bothered me was that the drm_vblank_put()
call got dropped. With v2 of this patch series that splits that change to a
separate patch it's easier to understand.
> >> + /* Unlink pending events */
> >> + list_for_each_entry_safe(e, et, &file_priv->pending_event_list,
> >> + pending_link) {
> >> + list_del(&e->pending_link);
> >> + e->file_priv = NULL;
> >> + }
>
> file_priv gets reset here ...
>
> >> @@ -736,7 +736,10 @@ void drm_event_cancel_free(struct drm_device *dev,
> >>
> >> {
> >>
> >> unsigned long flags;
> >> spin_lock_irqsave(&dev->event_lock, flags);
> >>
> >> - p->file_priv->event_space += p->event->length;
> >> + if (p->file_priv) {
> >> + p->file_priv->event_space += p->event->length;
> >> + list_del(&p->pending_link);
> >> + }
> >>
> >> spin_unlock_irqrestore(&dev->event_lock, flags);
> >> p->destroy(p);
>
> Allowing us to DTRT here ...
>
> >> void drm_send_event_locked(struct drm_device *dev, struct
> >> drm_pending_event
> >>
> >> *e) {
> >>
> >> assert_spin_locked(&dev->event_lock);
> >>
> >> + if (!e->file_priv) {
> >
> > I don't think this could happen before this patch as e->file_priv is
> > dereferenced below, and I don't see anything in this patch that makes the
> > condition possible.
> >
> >> + e->destroy(e);
> >> + return;
> >> + }
>
> ... and now here.
>
> This looks good to me, and a good sight better than doing it in every
> driver. Still drowning in stuff after three weeks off though, so the
> best I can offer for the series right now is:
> Acked-by: Daniel Stone
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/22] drm: Clean up pending events in the core
Hi Daniel,
Thank you for the patch.
On Monday 11 January 2016 22:41:03 Daniel Vetter wrote:
> There's really no reason to not do so, instead of replicating this
> for every use-case and every driver. Now we can't just nuke the events,
> since that would still mean that all drm_event users would need to know
> when that has happened, since calling e.g. drm_send_event isn't allowed
> any more. Instead just unlink them from the file, and detect this case
> and handle it appropriately in all functions.
>
> v2: Adjust existing kerneldoc too.
>
> v3: Improve wording of the kerneldoc and split out vblank cleanup (Laurent).
>
> Cc: Alex Deucher
> Cc: Laurent Pinchart
Reviewed-by: Laurent Pinchart
> Acked-by: Daniel Stone
> Reviewed-by: Alex Deucher (v1)
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fops.c | 30 +-
> include/drm/drmP.h | 2 ++
> 2 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index d85af1b2a238..109903f5b68a 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -264,6 +264,7 @@ static int drm_open_helper(struct file *filp, struct
> drm_minor *minor) INIT_LIST_HEAD(&priv->fbs);
> mutex_init(&priv->fbs_lock);
> INIT_LIST_HEAD(&priv->blobs);
> + INIT_LIST_HEAD(&priv->pending_event_list);
> INIT_LIST_HEAD(&priv->event_list);
> init_waitqueue_head(&priv->event_wait);
> priv->event_space = 4096; /* set aside 4k for event buffer */
> @@ -366,6 +367,13 @@ static void drm_events_release(struct drm_file
> *file_priv) v->base.destroy(&v->base);
> }
>
> + /* Unlink pending events */
> + list_for_each_entry_safe(e, et, &file_priv->pending_event_list,
> + pending_link) {
> + list_del(&e->pending_link);
> + e->file_priv = NULL;
> + }
> +
> /* Remove unconsumed events */
> list_for_each_entry_safe(e, et, &file_priv->event_list, link) {
> list_del(&e->link);
> @@ -712,6 +720,7 @@ int drm_event_reserve_init(struct drm_device *dev,
> file_priv->event_space -= e->length;
>
> p->event = e;
> + list_add(&p->pending_link, &file_priv->pending_event_list);
> p->file_priv = file_priv;
>
> /* we *could* pass this in as arg, but everyone uses kfree: */
> @@ -736,7 +745,10 @@ void drm_event_cancel_free(struct drm_device *dev,
> {
> unsigned long flags;
> spin_lock_irqsave(&dev->event_lock, flags);
> - p->file_priv->event_space += p->event->length;
> + if (p->file_priv) {
> + p->file_priv->event_space += p->event->length;
> + list_del(&p->pending_link);
> + }
> spin_unlock_irqrestore(&dev->event_lock, flags);
> p->destroy(p);
> }
> @@ -750,11 +762,22 @@ EXPORT_SYMBOL(drm_event_cancel_free);
> * This function sends the event @e, initialized with
> drm_event_reserve_init(), * to its associated userspace DRM file. Callers
> must already hold * dev->event_lock, see drm_send_event() for the unlocked
> version. + *
> + * Note that the core will take care of unlinking and disarming events when
> the + * corresponding DRM file is closed. Drivers need not worry about
> whether the + * DRM file for this event still exists and can call this
> function upon + * completion of the asynchronous work unconditionally.
> */
> void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event
> *e) {
> assert_spin_locked(&dev->event_lock);
>
> + if (!e->file_priv) {
> + e->destroy(e);
> + return;
> + }
> +
> + list_del(&e->pending_link);
> list_add_tail(&e->link,
> &e->file_priv->event_list);
> wake_up_interruptible(&e->file_priv->event_wait);
> @@ -769,6 +792,11 @@ EXPORT_SYMBOL(drm_send_event_locked);
> * This function sends the event @e, initialized with
> drm_event_reserve_init(), * to its associated userspace DRM file. This
> function acquires dev->event_lock, * see drm_send_event_locked() for
> callers which already hold this lock. + *
> + * Note that the core will take care of unlinking and disarming events when
> the + * corresponding DRM file is closed. Drivers need not worry about
> whether the + * DRM file for this event still exists and can call this
> function upon + * completion of the asynchronous work unconditionally.
> */
> void drm_send_event(struct drm_device *dev, struct drm_pending_event *e)
> {
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index ae73abf5c2cf..3d78a7406d54 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -283,6 +283,7 @@ struct drm_ioctl_desc {
> struct drm_pending_event {
> struct drm_event *event;
> struct list_head link;
> + struct list_head pending_link;
> struct drm_file *file_priv;
> pid_t pid; /* pid of requester, no guarantee it's valid by the time
>
Re: [Intel-gfx] [PATCH 02/22] drm: Add functions to setup/tear down drm_events.
Hi Daniel,
Thank you for the patch.
On Monday 11 January 2016 22:40:56 Daniel Vetter wrote:
> An attempt at not spreading out the file_priv->event_space stuff out
> quite so far and wide. And I think fixes something in ipp_get_event()
> that is broken (or if they are doing something more weird/subtle, then
> breaks it in a fun way).
>
> Based upon a patch from Rob Clark, rebased and polished.
>
> v2: Spelling fixes (Alex).
>
> Cc: Alex Deucher
> Acked-by: Daniel Stone
> Reviewed-by: Alex Deucher
> Cc: Rob Clark
> Signed-off-by: Daniel Vetter
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_atomic.c | 44 -
> drivers/gpu/drm/drm_crtc.c | 36 +++-
> drivers/gpu/drm/drm_fops.c | 67 +
> include/drm/drmP.h | 7 -
> 4 files changed, 94 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3f74193885f1..8fb469c4e4b8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1347,44 +1347,23 @@ static struct drm_pending_vblank_event
> *create_vblank_event( struct drm_device *dev, struct drm_file *file_priv,
> uint64_t user_data) {
> struct drm_pending_vblank_event *e = NULL;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&dev->event_lock, flags);
> - if (file_priv->event_space < sizeof e->event) {
> - spin_unlock_irqrestore(&dev->event_lock, flags);
> - goto out;
> - }
> - file_priv->event_space -= sizeof e->event;
> - spin_unlock_irqrestore(&dev->event_lock, flags);
> + int ret;
>
> e = kzalloc(sizeof *e, GFP_KERNEL);
> - if (e == NULL) {
> - spin_lock_irqsave(&dev->event_lock, flags);
> - file_priv->event_space += sizeof e->event;
> - spin_unlock_irqrestore(&dev->event_lock, flags);
> - goto out;
> - }
> + if (!e)
> + return NULL;
>
> e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
> - e->event.base.length = sizeof e->event;
> + e->event.base.length = sizeof(e->event);
> e->event.user_data = user_data;
> - e->base.event = &e->event.base;
> - e->base.file_priv = file_priv;
> - e->base.destroy = (void (*) (struct drm_pending_event *)) kfree;
> -
> -out:
> - return e;
> -}
>
> -static void destroy_vblank_event(struct drm_device *dev,
> - struct drm_file *file_priv, struct drm_pending_vblank_event *e)
> -{
> - unsigned long flags;
> + ret = drm_event_reserve_init(dev, file_priv, &e->base, &e->event.base);
> + if (ret) {
> + kfree(e);
> + return NULL;
> + }
>
> - spin_lock_irqsave(&dev->event_lock, flags);
> - file_priv->event_space += sizeof e->event;
> - spin_unlock_irqrestore(&dev->event_lock, flags);
> - kfree(e);
> + return e;
> }
>
> static int atomic_set_prop(struct drm_atomic_state *state,
> @@ -1646,8 +1625,7 @@ out:
> if (!crtc_state->event)
> continue;
>
> - destroy_vblank_event(dev, file_priv,
> - crtc_state->event);
> + drm_event_cancel_free(dev, &crtc_state->event->base);
> }
> }
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 1e75a145834a..60a4184d41b7 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5264,7 +5264,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> struct drm_crtc *crtc;
> struct drm_framebuffer *fb = NULL;
> struct drm_pending_vblank_event *e = NULL;
> - unsigned long flags;
> int ret = -EINVAL;
>
> if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS ||
> @@ -5315,41 +5314,26 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> }
>
> if (page_flip->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> - ret = -ENOMEM;
> - spin_lock_irqsave(&dev->event_lock, flags);
> - if (file_priv->event_space < sizeof(e->event)) {
> - spin_unlock_irqrestore(&dev->event_lock, flags);
> - goto out;
> - }
> - file_priv->event_space -= sizeof(e->event);
> - spin_unlock_irqrestore(&dev->event_lock, flags);
> -
> - e = kzalloc(sizeof(*e), GFP_KERNEL);
> - if (e == NULL) {
> - spin_lock_irqsave(&dev->event_lock, flags);
> - file_priv->event_space += sizeof(e->event);
> - spin_unlock_irqrestore(&dev->event_lock, flags);
> + e = kzalloc(sizeof *e, GFP_KERNEL);
> + if (!e) {
> + ret = -ENOMEM;
> goto out;
> }
> -
> e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
> e->event.base.length = sizeof
Re: [Intel-gfx] [PATCH 7/7] drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW
On Thu, Jan 14, 2016 at 11:30:31PM +0800, kbuild test robot wrote: > Hi Mahesh, > > [auto build test ERROR on drm-intel/for-linux-next] > [also build test ERROR on next-20160114] > [cannot apply to v4.4] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: > https://github.com/0day-ci/linux/commits/Shobhit-Kumar/Misc-WM-fixes-and-Arbitrated-Display-Bandwidth-WA-for-SKL/20160114-200444 > base: git://anongit.freedesktop.org/drm-intel for-linux-next > config: i386-defconfig (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=i386 > > All errors (new ones prefixed by >>): > >drivers/built-in.o: In function `skl_update_wm': > >> intel_pm.c:(.text+0xdcbfb): undefined reference to `__udivdi3' >intel_pm.c:(.text+0xdccb7): undefined reference to `__udivdi3' In case you wonder, compiling for x86 32 bits, this is most likely because DIV_ROUND_UP() uses a stray '/' operator and you use it with 64 bit values, which will make gcc use a run-time helper function that isn't part of the kernel. You need to use DIV_ROUND_UP_ULL(), making sure the second parameter is 32 bits only. HTH, -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Hold a RPM reference during i915_driver_unload
On ke, 2015-12-30 at 15:03 +0200, Joonas Lahtinen wrote:
> Hi,
>
> On ti, 2015-12-29 at 12:55 +0200, Gabriel Feceoru wrote:
> > This fixes an issue added with: "1f814da drm/i915: add support for
> > checking
> > if we hold an RPM reference", noticed while running
> > drv_module_reload_basic.
> >
> > WARNING: CPU: 1 PID: 2032 at drivers/gpu/drm/i915/intel_drv.h:1446
> > gen6_read32+0x1ca/0x1e0 [i915]()
> > [ 138.682686] RPM wakelock ref not held during HW access
> > [ 138.682687] Modules linked in:
> > [ 138.682688] i915(-) drm_kms_helper drm snd_hda_codec_hdmi
> > snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep
> > x86_pkg_temp_thermal snd_hda_core i2c_algo_bit syscopyarea
> > sysfillrect sysimgblt fb_sys_fops xhci_pci ehci_pci r8169 xhci_hcd
> > mii ehci_hcd video [last unloaded: snd_hda_intel]
> > [ 138.682699] CPU: 1 PID: 2032 Comm: rmmod Tainted: GW
> > 4.4.0-rc4+ #44
> > [ 138.682701] Hardware name: Dell Inc. Inspiron 3847/088DT1 ,
> > BIOS A06 01/15/2015
> > [ 138.682702] c03b6358 880210d8ba58 813e0c0f
> > 880210d8baa0
> > [ 138.682703] 880210d8ba90 8105f6a2 8800daa4
> > 00064400
> > [ 138.682705] 0004 880210d8bb9c 8800daa4
> > 880210d8baf0
> > [ 138.682706] Call Trace:
> > [ 138.682710] [] dump_stack+0x44/0x55
> > [ 138.682713] [] warn_slowpath_common+0x82/0xc0
> > [ 138.682715] [] warn_slowpath_fmt+0x4c/0x50
> > [ 138.682725] [] ?
> > i915_gem_object_unpin_from_display_plane+0x1c/0x50 [i915]
> > [ 138.682734] [] gen6_read32+0x1ca/0x1e0 [i915]
> > [ 138.682737] [] ? mutex_lock+0x12/0x30
> > [ 138.682747] []
> > intel_ddi_get_hw_state+0x7a/0x180 [i915]
> > [ 138.682758] []
> > intel_connector_get_hw_state+0x28/0x30 [i915]
> > [ 138.682767] [] intel_atomic_commit+0xa9c/0x17e0
> > [i915]
> > [ 138.682779] [] ?
> > drm_atomic_check_only+0x18e/0x590 [drm]
> > [ 138.682786] [] ?
> > drm_atomic_add_affected_connectors+0x8c/0xf0 [drm]
> > [ 138.682792] [] drm_atomic_commit+0x37/0x60
> > [drm]
> > [ 138.682797] []
> > drm_atomic_helper_set_config+0x76/0xb0 [drm_kms_helper]
> > [ 138.682804] [] ?
> > drm_modeset_lock_all_ctx+0x9a/0xb0 [drm]
> > [ 138.682809] []
> > drm_mode_set_config_internal+0x62/0x100 [drm]
> > [ 138.682814] []
> > drm_framebuffer_remove+0xe8/0x120 [drm]
> > [ 138.682826] [] intel_fbdev_fini+0x6d/0x90
> > [i915]
> > [ 138.682838] [] i915_driver_unload+0x1a/0x290
> > [i915]
> > [ 138.682844] [] drm_dev_unregister+0x29/0xb0
> > [drm]
> > [ 138.682848] [] drm_put_dev+0x23/0x60 [drm]
> > [ 138.682854] [] i915_pci_remove+0x15/0x20 [i915]
> > [ 138.682856] [] pci_device_remove+0x39/0xc0
> > [ 138.682859] []
> > __device_release_driver+0xa1/0x150
> > [ 138.682860] [] driver_detach+0xa3/0xb0
> > [ 138.682862] [] bus_remove_driver+0x55/0xd0
> > [ 138.682864] [] driver_unregister+0x2c/0x50
> > [ 138.682866] [] pci_unregister_driver+0x21/0x90
> > [ 138.682871] [] drm_pci_exit+0x94/0xb0 [drm]
> > [ 138.682883] [] i915_exit+0x20/0xc1c [i915]
> >
> > Reported-by: Marius Vlad
> > Signed-off-by: Gabriel Feceoru
> > ---
> > drivers/gpu/drm/i915/i915_dma.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 988a380..08ad01f0 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1136,6 +1136,8 @@ int i915_driver_unload(struct drm_device
> > *dev)
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > int ret;
> >
> > + intel_runtime_pm_get(dev_priv);
> > +
> > intel_fbdev_fini(dev);
> >
> > i915_audio_component_cleanup(dev_priv);
> > @@ -1143,6 +1145,7 @@ int i915_driver_unload(struct drm_device
> > *dev)
> > ret = i915_gem_suspend(dev);
> > if (ret) {
> > DRM_ERROR("failed to idle hardware: %d\n", ret);
> > + intel_runtime_pm_put(dev_priv);
>
> This should be made into goto construct.
>
> > return ret;
> > }
> >
> > @@ -1221,6 +1224,9 @@ int i915_driver_unload(struct drm_device
> > *dev)
> > kmem_cache_destroy(dev_priv->vmas);
> > kmem_cache_destroy(dev_priv->objects);
> > pci_dev_put(dev_priv->bridge_dev);
> > +
> > + intel_runtime_pm_put(dev_priv);
> > +
>
> Not sure if we should/can keep the runtime reference until this
> point.
> At worst this could lead into the runtime_pm_put function poking at
> the
> hardware registers after the pci_dev has been released.
Well if you meant the above bridge_dev PCI device it's not relevant as
far as power management goes, we only care about the main PCI device.
That one in turn is guaranteed to exist while we are in the load/unload
functions.
But since this looks like fixing the problem where the HW readout code
in the modeset state checker doesn't hold an RPM reference I would
prefer fixing it there, see the discussion with Chris about i
Re: [Intel-gfx] [PATCH 7/7] drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW
Hi Mahesh, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160114] [cannot apply to v4.4] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Shobhit-Kumar/Misc-WM-fixes-and-Arbitrated-Display-Bandwidth-WA-for-SKL/20160114-200444 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-randconfig-c0-01142249 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) UNSTABLE dmesg-warn -> PASS (bdw-nuci7) dmesg-warn -> PASS (bdw-ultra) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a: pass -> DMESG-WARN (snb-x220t) Subgroup read-crc-pipe-b: dmesg-warn -> PASS (snb-x220t) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:132 dwarn:0 dfail:0 fail:0 skip:6 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:132 dwarn:1 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1192/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make sure DC writes are coherent on flush.
Jani Nikula writes:
> On Thu, 14 Jan 2016, Francisco Jerez wrote:
>> We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
>> that writes performed via the HDC are visible in memory. Fixes an
>> intermittent failure in a Piglit test that writes to a BO from a
>> shader using GL atomic counters (implemented as HDC untyped atomics)
>> and then expects the memory to read back the same value after mapping
>> it on the CPU.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91298
>> Tested-by: Mark Janes
>> Cc: Rodrigo Vivi
>
> Francisco, this is missing your Signed-off-by i.e. developer certificate
> of origin http://developercertificate.org/ - can't push without. Please
> reply with that.
>
Oops, sorry for that -- And yeah it shouldn't hurt to CC stable too.
Signed-off-by: Francisco Jerez
> BR,
> Jani.
>
>
>> ---
>> drivers/gpu/drm/i915/intel_lrc.c| 1 +
>> drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
>> 2 files changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>> b/drivers/gpu/drm/i915/intel_lrc.c
>> index ab344e0..02213c6 100644
>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> @@ -1735,6 +1735,7 @@ static int gen8_emit_flush_render(struct
>> drm_i915_gem_request *request,
>> if (flush_domains) {
>> flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
>> flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
>> +flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
>> flags |= PIPE_CONTROL_FLUSH_ENABLE;
>> }
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index 4060acf..8cd8aab 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -331,6 +331,7 @@ gen7_render_ring_flush(struct drm_i915_gem_request *req,
>> if (flush_domains) {
>> flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
>> flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
>> +flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
>> flags |= PIPE_CONTROL_FLUSH_ENABLE;
>> }
>> if (invalidate_domains) {
>> @@ -403,6 +404,7 @@ gen8_render_ring_flush(struct drm_i915_gem_request *req,
>> if (flush_domains) {
>> flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
>> flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
>> +flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
>> flags |= PIPE_CONTROL_FLUSH_ENABLE;
>> }
>> if (invalidate_domains) {
>
> --
> Jani Nikula, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't do pre plane update on disabled crtcs
On Thu, Jan 14, 2016 at 06:32:10PM +0200, Mika Kuoppala wrote:
> CI/Bat got following (shortened) trace on byt and also
> on bsw:
>
> [ cut here ]---
> Unclaimed register detected before reading register 0x186500
> Call Trace:
> __unclaimed_reg_debug+0x68/0x80 [i915]
> vlv_read32+0x2de/0x370 [i915]
> intel_set_memory_cxsr+0x87/0x1a0 [i915]
> intel_pre_plane_update+0xb3/0xf0 [i915]
> intel_atomic_commit+0x3b5/0x17c0 [i915]
> ...
> ---[ end trace 6387a0ad001bb39f ]---
>
> Fix this by limiting pre plane update only to active crtcs.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=93698
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index aa24f79d85bf..a134a698d97d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13580,9 +13580,8 @@ static int intel_atomic_commit(struct drm_device *dev,
> if (!needs_modeset(crtc->state))
> continue;
>
> - intel_pre_plane_update(intel_crtc);
> -
> if (crtc_state->active) {
> + intel_pre_plane_update(intel_crtc);
I think you'll want to deal with the other one too (the one in the crtc
enable/plane update path). Actually I think the plane update stuff
should be split into a separate loop from the crtc_enable stuff, but
that's a separate topic.
Hmm. And there's a post_plane_update there that looks a bit too
lonely as well. Something really should be done to make this code
less convoluted. A modeset/plane update shouldn't be this hard to
get right.
> intel_crtc_disable_planes(crtc, crtc_state->plane_mask);
> dev_priv->display.crtc_disable(crtc);
> intel_crtc->active = false;
> --
> 2.5.0
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Acquire RPM wakeref for KMS atomic commit
On la, 2015-12-19 at 09:58 +, Chris Wilson wrote:
> Once all the preparations are complete, we are ready to write the
> modesetting to the hardware. During this phase, we will be making
> lots
> of HW register access, so take a top level wakeref to prevent an
> unwarranted rpm suspend cycle mid-commit. Lower level functions
> should
> be waking the individual power wells as required.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439
I would separate here two things:
The device level power flip-flopping you mention and the fix for the
above bug. For the flip-flopping we could use what you suggest, perhaps
by also avoiding waking up the device if nothing will change and
everything will stay disabled.
As for the fix I would go with what Ville suggested. By ensuring we
keep an RPM reference we still allow for a display power domain
reference to come and go in the middle of the HW readout. I went ahead
and tried the following which got rid of the problem too, if people are
ok with it I could convert the rest of the HW readout places
accordingly and send out the patch. We can also
get pm_runtime_get_if_in_use() into use once it's added, but it's
not crucial for the fix.
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1f9a368..907377dc 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1910,13 +1910,16 @@ bool intel_ddi_connector_get_hw_state(struct
intel_connector *intel_connector)
enum transcoder cpu_transcoder;
enum intel_display_power_domain power_domain;
uint32_t tmp;
+ bool ret;
power_domain = intel_display_port_power_domain(intel_encoder);
- if (!intel_display_power_is_enabled(dev_priv, power_domain))
+ if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
return false;
- if (!intel_encoder->get_hw_state(intel_encoder, &pipe))
- return false;
+ if (!intel_encoder->get_hw_state(intel_encoder, &pipe)) {
+ ret = false;
+ goto out;
+ }
if (port == PORT_A)
cpu_transcoder = TRANSCODER_EDP;
@@ -1928,23 +1931,30 @@ bool intel_ddi_connector_get_hw_state(struct
intel_connector *intel_connector)
switch (tmp & TRANS_DDI_MODE_SELECT_MASK) {
case TRANS_DDI_MODE_SELECT_HDMI:
case TRANS_DDI_MODE_SELECT_DVI:
- return (type == DRM_MODE_CONNECTOR_HDMIA);
+ ret = type == DRM_MODE_CONNECTOR_HDMIA;
+ goto out;
case TRANS_DDI_MODE_SELECT_DP_SST:
- if (type == DRM_MODE_CONNECTOR_eDP)
- return true;
- return (type == DRM_MODE_CONNECTOR_DisplayPort);
+ ret = type == DRM_MODE_CONNECTOR_eDP ||
+ type == DRM_MODE_CONNECTOR_DisplayPort;
+ goto out;
case TRANS_DDI_MODE_SELECT_DP_MST:
/* if the transcoder is in MST state then
* connector isn't connected */
- return false;
+ ret = false;
+ goto out;
case TRANS_DDI_MODE_SELECT_FDI:
- return (type == DRM_MODE_CONNECTOR_VGA);
+ ret = type == DRM_MODE_CONNECTOR_VGA;
+ goto out;
default:
- return false;
+ ret = false;
}
+out:
+ intel_display_power_put(dev_priv, power_domain);
+
+ return ret;
}
bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 059b46e..3c84159 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1456,6 +1456,8 @@ bool __intel_display_power_is_enabled(struct
drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
void intel_display_power_get(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
+bool intel_display_power_get_if_enabled(struct drm_i915_private *dev_priv,
+ enum intel_display_power_domain domain);
void intel_display_power_put(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index bbca527..6c4f170 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1470,6 +1470,17 @@ void intel_display_power_get(struct drm_i915_private
*dev_priv,
mutex_unlock(&power_domains->lock);
}
+bool intel_display_power_get_if_enabled(struct drm_i915_private *dev_priv,
+ enum intel_display_power_domain domain)
+{
+ if (!intel_display_power_is_enabled(dev_priv, domain))
+ return false;
+
+ intel_display_power_get(dev_pr
[Intel-gfx] [PATCH] drm/i915: Don't do pre plane update on disabled crtcs
CI/Bat got following (shortened) trace on byt and also
on bsw:
[ cut here ]---
Unclaimed register detected before reading register 0x186500
Call Trace:
__unclaimed_reg_debug+0x68/0x80 [i915]
vlv_read32+0x2de/0x370 [i915]
intel_set_memory_cxsr+0x87/0x1a0 [i915]
intel_pre_plane_update+0xb3/0xf0 [i915]
intel_atomic_commit+0x3b5/0x17c0 [i915]
...
---[ end trace 6387a0ad001bb39f ]---
Fix this by limiting pre plane update only to active crtcs.
References: https://bugs.freedesktop.org/show_bug.cgi?id=93698
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_display.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index aa24f79d85bf..a134a698d97d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13580,9 +13580,8 @@ static int intel_atomic_commit(struct drm_device *dev,
if (!needs_modeset(crtc->state))
continue;
- intel_pre_plane_update(intel_crtc);
-
if (crtc_state->active) {
+ intel_pre_plane_update(intel_crtc);
intel_crtc_disable_planes(crtc, crtc_state->plane_mask);
dev_priv->display.crtc_disable(crtc);
intel_crtc->active = false;
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == HEAD is now at 8fb2fee drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest Applying: drm/i915/bxt: Check BIOS RC6 setup before enabling RC6 Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_gem_stolen.c M drivers/gpu/drm/i915/i915_reg.h M drivers/gpu/drm/i915/intel_drv.h M drivers/gpu/drm/i915/intel_pm.c M drivers/gpu/drm/i915/intel_uncore.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_uncore.c Auto-merging drivers/gpu/drm/i915/intel_pm.c Auto-merging drivers/gpu/drm/i915/intel_drv.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_drv.h Auto-merging drivers/gpu/drm/i915/i915_reg.h Auto-merging drivers/gpu/drm/i915/i915_gem_stolen.c Auto-merging drivers/gpu/drm/i915/i915_drv.h Patch failed at 0001 drm/i915/bxt: Check BIOS RC6 setup before enabling RC6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) UNSTABLE dmesg-warn -> PASS (bdw-nuci7) dmesg-warn -> PASS (bdw-ultra) Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: pass -> DMESG-WARN (bdw-ultra) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:1 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:132 dwarn:1 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 HANGED skl-i7k-2 in Patchwork_1190/skl-i7k-2/tests/115.json:igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b Patchwork_1190/skl-i7k-2/tests/116.json:igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c Patchwork_1190/skl-i7k-2/tests/117.json:igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a Patchwork_1190/skl-i7k-2/tests/118.json:igt@gem_ctx_create@basic Patchwork_1190/skl-i7k-2/tests/119.json:igt@gem_ctx_param_basic@invalid-ctx-get Patchwork_1190/skl-i7k-2/tests/120.json:igt@kms_addfb_basic@size-max Patchwork_1190/skl-i7k-2/tests/121.json:igt@kms_addfb_basic@no-handle Patchwork_1190/skl-i7k-2/tests/122.json:igt@kms_pipe_crc_basic@read-crc-pipe-a Patchwork_1190/skl-i7k-2/tests/123.json:igt@kms_pipe_crc_basic@read-crc-pipe-c Patchwork_1190/skl-i7k-2/tests/124.json:igt@kms_pipe_crc_basic@read-crc-pipe-b Patchwork_1190/skl-i7k-2/tests/125.json:igt@kms_addfb_basic@bad-pitch-256 Patchwork_1190/skl-i7k-2/tests/126.json:igt@gem_mmap_gtt@basic-write-gtt Patchwork_1190/skl-i7k-2/tests/127.json:igt@kms_s etmode@basic-clone-single-crtc Patchwork_1190/skl-i7k-2/tests/128.json:igt@kms_addfb_basic@addfb25-x-tiled Patchwork_1190/skl-i7k-2/tests/129.json:igt@gem_basic@bad-close Patchwork_1190/skl-i7k-2/tests/130.json:igt@gem_render_linear_blits@basic Patchwork_1190/skl-i7k-2/tests/131.json:igt@gem_mmap_gtt@basic-copy Patchwork_1190/skl-i7k-2/tests/132.json:igt@kms_addfb_basic@small-bo Patchwork_1190/skl-i7k-2/tests/133.json:igt@kms_addfb_basic@basic Patchwork_1190/skl-i7k-2/tests/134.json:igt@kms_flip@basic-flip-vs-modeset Patchwork_1190/skl-i7k-2/tests/135.json:igt@kms_addfb_basic@unused-pitches Patchwork_1190/skl-i7k-2/tests/136.json:igt@kms_addfb_basic@bo-too-small-due-to-tiling Patchwork_1190/skl-i7k-2/tests/137.json:igt@gem_storedw_loop@basic-blt Patchwork_1190/skl-i7k-2/tests/138.json:igt@drv_getparams_basic@basic-eu-total Patchwork_1190/skl-i7k-2/tests/139.json:igt@gem_ctx_param_basic@invalid-ctx-set Patchwork_1190/skl-i7k-2/tests/140.json:igt@kms_pipe_crc_basic@read-crc-pipe-a-fra me-sequence Results at /archive/results/CI_IGT_test/Patchwork_1190/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bios: Fix the sequence size calculations for MIPI seq v3
On Thu, Jan 14, 2016 at 05:12:07PM +0200, Jani Nikula wrote:
> Two errors in a single line. The size was read from the wrong offset,
> and the end index didn't take the five bytes for sequence byte and size
> of sequence into account. Fix it all, and break up the calculations a
> bit to make it clearer.
>
> Cc: Ville Syrjälä
> Reported-by: Mika Kahola
> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_bios.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 12e2f8b8bf9c..bf62a19c8f69 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -842,6 +842,7 @@ static int goto_next_sequence_v3(const u8 *data, int
> index, int total)
> {
> int seq_end;
> u16 len;
> + u32 size_of_sequence;
>
> /*
>* Could skip sequence based on Size of Sequence alone, but also do some
> @@ -852,14 +853,24 @@ static int goto_next_sequence_v3(const u8 *data, int
> index, int total)
> return 0;
> }
>
> - seq_end = index + *((const u32 *)(data + 1));
> + /* Skip Sequence Byte. */
> + index++;
> +
> + /*
> + * Size of Sequence. Excludes the Sequence Byte and the size itself,
> + * includes MIPI_SEQ_ELEM_END byte, excludes the final MIPI_SEQ_END
> + * byte.
> + */
> + size_of_sequence = *((const uint32_t *)(data + index));
Hmm. So it was reading from 'data+1' and now it's basically 'data+index+1'.
So it was correct for the first sequence, and busted for later ones I
suppose.
> + index += 4;
> +
> + seq_end = index + size_of_sequence;
And now we count the size of the sequence starting from the operation
byte, before we counted it from the sequence byte. "Fortunately" the spec
doesn't even tell us which is correct. If it works, it works.
Reviewed-by: Ville Syrjälä
BTW I was thinking that we could maybe add some kind of
"read the thing at index, and and increment the index past it" helpers.
Eg.
int get_u8(const void *data, int index, int size, u8 *ret);
int get_u32(const void *data, int index, int size, u32 *ret);
they could also do the index vs. size check and just return an error if
we try to go too far.
> if (seq_end > total) {
> DRM_ERROR("Invalid sequence size\n");
> return 0;
> }
>
> - /* Skip Sequence Byte and Size of Sequence. */
> - for (index = index + 5; index < total; index += len) {
> + for (; index < total; index += len) {
> u8 operation_byte = *(data + index);
> index++;
>
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/6] intel_bios_reader: dump MIPI sequence block v3
Similar to what's done in kernel. It's a bit artificial that the parsing
and dumping are two separate steps in the userspace tool, but it's
easier to follow and debug the code when both the kernel and userspace
are similar.
v2: don't segfault so much on dumping null pointers
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 47 +++
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 944ad5315f3a..4cfd30afbb46 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -973,7 +973,7 @@ static const char *sequence_name(enum mipi_seq seq_id)
return "(unknown)";
}
-static const uint8_t *dump_sequence(const uint8_t *data)
+static const uint8_t *dump_sequence(const uint8_t *data, uint8_t seq_version)
{
fn_mipi_elem_dump mipi_elem_dump;
@@ -982,21 +982,33 @@ static const uint8_t *dump_sequence(const uint8_t *data)
/* Skip Sequence Byte. */
data++;
+ /* Skip Size of Sequence. */
+ if (seq_version >= 3)
+ data += 4;
+
while (1) {
uint8_t operation_byte = *data++;
+ uint8_t operation_size = 0;
if (operation_byte == MIPI_SEQ_ELEM_END)
break;
- if (operation_byte < ARRAY_SIZE(dump_elem) &&
- dump_elem[operation_byte])
+ if (operation_byte < ARRAY_SIZE(dump_elem))
mipi_elem_dump = dump_elem[operation_byte];
else
mipi_elem_dump = NULL;
+ /* Size of Operation. */
+ if (seq_version >= 3)
+ operation_size = *data++;
+
if (mipi_elem_dump) {
data = mipi_elem_dump(data);
+ } else if (operation_size) {
+ /* We have size, skip. */
+ data += operation_size;
} else {
+ /* No size, can't skip without parsing. */
printf("Error: Unsupported MIPI element %u\n",
operation_byte);
return NULL;
@@ -1167,7 +1179,8 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
const struct bdb_mipi_sequence *sequence = block->data;
const uint8_t *data;
uint32_t seq_size;
- int index = 0;
+ int index = 0, i;
+ const uint8_t *sequence_ptrs[MIPI_SEQ_MAX] = {};
/* Check if we have sequence block as well */
if (!sequence) {
@@ -1200,6 +1213,8 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
return;
}
+ sequence_ptrs[seq_id] = data + index;
+
if (sequence->version >= 3)
index = goto_next_sequence_v3(data, index, seq_size);
else
@@ -1210,26 +1225,10 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
}
}
- if (sequence->version >= 3) {
- fprintf(stderr, "Unable to dump MIPI Sequence Block v%u\n",
- sequence->version);
- return;
- }
-
- /*
-* loop into the sequence data and split into multiple sequneces
-* There are only 5 types of sequences as of now
-*/
-
-while (1) {
- int seq_id = *data;
- if (seq_id == MIPI_SEQ_END)
- break;
-
- data = dump_sequence(data);
- if (!data)
- break;
- }
+ /* Dump the sequences. Corresponds to sequence execution in kernel. */
+ for (i = 0; i < ARRAY_SIZE(sequence_ptrs); i++)
+ if (sequence_ptrs[i])
+ dump_sequence(sequence_ptrs[i], sequence->version);
}
static int
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6
RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
setup registers. If those are not setup Driver should not enable RC6.
For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
to know if BIOS has enabled HW/SW RC6.
This will also enable user to control RC6 using BIOS settings alone.
RC6 related instability can be avoided by disabling via BIOS settings
till driver fixes it.
v2: Had placed logic in gen8 function by mistake. Fixed it.
Ensuring RPM is not enabled in case BIOS disabled RC6.
v3: Need to disable RPM if RC6 is disabled due to BIOS settings. (Daniel)
Runtime PM enabling happens before gen9_enable_rc6.
Moved the updation of enable_rc6 parameter in intel_uncore_sanitize.
v4: Added elaborate check for BIOS RC6 setup. Prepared check_pctx for bxt.
(Imre)
v5: Caching reserved stolen base and size in the driver private data.
Reorganized RC6 setup check. Moved from gen9_enable_rc6 to
intel_uncore_sanitize. (Imre)
Cc: Imre Deak
Change-Id: If89518708e133be6b3c7c6f90869fb66224b7b87
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem_gtt.h| 2 ++
drivers/gpu/drm/i915/i915_gem_stolen.c | 39 ++
drivers/gpu/drm/i915/i915_reg.h| 11 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c| 59 --
drivers/gpu/drm/i915/intel_uncore.c| 4 +++
7 files changed, 109 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cf7e0fc..0c8e61c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3223,6 +3223,7 @@ int i915_gem_stolen_insert_node_in_range(struct
drm_i915_private *dev_priv,
u64 end);
void i915_gem_stolen_remove_node(struct drm_i915_private *dev_priv,
struct drm_mm_node *node);
+int i915_gem_init_stolen_reserved(struct drm_device *dev);
int i915_gem_init_stolen(struct drm_device *dev);
void i915_gem_cleanup_stolen(struct drm_device *dev);
struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index b448ad8..20ff6ca 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -343,6 +343,8 @@ struct i915_gtt {
size_t stolen_size; /* Total size of stolen memory */
size_t stolen_usable_size; /* Total size minus BIOS reserved */
+ size_t stolen_reserved_base;
+ size_t stolen_reserved_size;
u64 mappable_end; /* End offset that we can CPU map */
struct io_mapping *mappable;/* Mapping to our CPU mappable region */
phys_addr_t mappable_base; /* PA of our GMADR */
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 3476877..d5a65d9 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -386,14 +386,12 @@ static void bdw_get_stolen_reserved(struct
drm_i915_private *dev_priv,
*size = stolen_top - *base;
}
-int i915_gem_init_stolen(struct drm_device *dev)
+int i915_gem_init_stolen_reserved(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- unsigned long reserved_total, reserved_base = 0, reserved_size;
+ unsigned long reserved_base = 0, reserved_size;
unsigned long stolen_top;
- mutex_init(&dev_priv->mm.stolen_lock);
-
#ifdef CONFIG_INTEL_IOMMU
if (intel_iommu_gfx_mapped && INTEL_INFO(dev)->gen < 8) {
DRM_INFO("DMAR active, disabling use of stolen memory\n");
@@ -458,9 +456,38 @@ int i915_gem_init_stolen(struct drm_device *dev)
return 0;
}
+ dev_priv->gtt.stolen_reserved_base = reserved_base;
+ dev_priv->gtt.stolen_reserved_size = reserved_size;
+
+ return 0;
+}
+
+int i915_gem_init_stolen(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ unsigned long reserved_total;
+ unsigned long stolen_top;
+
+ mutex_init(&dev_priv->mm.stolen_lock);
+
+#ifdef CONFIG_INTEL_IOMMU
+ if (intel_iommu_gfx_mapped && INTEL_INFO(dev)->gen < 8) {
+ DRM_INFO("DMAR active, disabling use of stolen memory\n");
+ return 0;
+ }
+#endif
+
+ if (dev_priv->gtt.stolen_size == 0)
+ return 0;
+
+ if (dev_priv->mm.stolen_base == 0)
+ return 0;
+
+ stolen_top = dev_priv->mm.stolen_base + dev_priv->gtt.stolen_size;
+
/* It is possible for the reserved area to end before the end of stolen
-* memory, so just consider the start. */
- reserved_total = stolen_top - reserved_base;
+ * memory, so just consider the start. */
+ reserved_total = stolen_top - dev_priv->gtt.stolen_rese
[Intel-gfx] [i-g-t PATCH 4/6] intel_bios_reader: port find_panel_sequence_block from kernel
No need to reinvent wheels, reuse the code from kernel.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 81 ++-
1 file changed, 52 insertions(+), 29 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 7dbda3eac77c..eb550817c44e 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -1006,13 +1006,60 @@ static const uint8_t *dump_sequence(const uint8_t *data)
return data;
}
+/* Find the sequence block and size for the given panel. */
+static const uint8_t *
+find_panel_sequence_block(const struct bdb_mipi_sequence *sequence,
+ uint16_t panel_id, uint32_t total, uint32_t *seq_size)
+{
+ const uint8_t *data = &sequence->data[0];
+ uint8_t current_id;
+ uint32_t current_size;
+ int header_size = sequence->version >= 3 ? 5 : 3;
+ int index = 0;
+ int i;
+
+ /* skip new block size */
+ if (sequence->version >= 3)
+ data += 4;
+
+ for (i = 0; i < MAX_MIPI_CONFIGURATIONS && index < total; i++) {
+ if (index + header_size > total) {
+ fprintf(stderr, "Invalid sequence block (header)\n");
+ return NULL;
+ }
+
+ current_id = *(data + index);
+ if (sequence->version >= 3)
+ current_size = *((const uint32_t *)(data + index + 1));
+ else
+ current_size = *((const uint16_t *)(data + index + 1));
+
+ index += header_size;
+
+ if (index + current_size > total) {
+ fprintf(stderr, "Invalid sequence block\n");
+ return NULL;
+ }
+
+ if (current_id == panel_id) {
+ *seq_size = current_size;
+ return data + index;
+ }
+
+ index += current_size;
+ }
+
+ fprintf(stderr, "Sequence block detected but no valid configuration\n");
+
+ return NULL;
+}
+
static void dump_mipi_sequence(const struct bdb_header *bdb,
const struct bdb_block *block)
{
const struct bdb_mipi_sequence *sequence = block->data;
const uint8_t *data;
- int i, panel_id, seq_size;
- uint32_t block_size;
+ uint32_t seq_size;
/* Check if we have sequence block as well */
if (!sequence) {
@@ -1025,34 +1072,10 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
if (sequence->version >= 3)
return;
- block_size = block->size;
-
- data = &sequence->data[0];
-
- /*
-* sequence block is variable length and hence we need to parse and
-* get the sequence data for specific panel id
-*/
- for (i = 0; i < MAX_MIPI_CONFIGURATIONS; i++) {
- panel_id = *data;
- seq_size = *((uint16_t *) (data + 1));
- data += 3;
-
- if (data + seq_size > (const uint8_t *)sequence + block_size) {
- printf("Invalid sequence block\n");
- return;
- }
-
- if (panel_id == panel_type)
- break;
-
- data += seq_size;
- }
-
- if (i == MAX_MIPI_CONFIGURATIONS) {
- printf("Sequence block detected but no valid configuration\n");
+ data = find_panel_sequence_block(sequence, panel_type,
+block->size, &seq_size);
+ if (!data)
return;
- }
/*
* loop into the sequence data and split into multiple sequneces
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 2/6] intel_bios_reader: fix size handling for 32-bit block size
The MIPI DSI sequence block v3+ has a separate block size field.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 46 +-
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 7b525f220f16..496f2b4f8d1e 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -65,9 +65,10 @@ uint8_t *VBIOS;
#define YESNO(val) ((val) ? "yes" : "no")
+/* This is not for mapping to memory layout. */
struct bdb_block {
uint8_t id;
- uint16_t size;
+ uint32_t size;
void *data;
};
@@ -76,17 +77,27 @@ static int tv_present;
static int lvds_present;
static int panel_type;
+/* Get BDB block size given a pointer to Block ID. */
+static uint32_t _get_blocksize(const uint8_t *block_base)
+{
+ /* The MIPI Sequence Block v3+ has a separate size field. */
+ if (*block_base == BDB_MIPI_SEQUENCE && *(block_base + 3) >= 3)
+ return *((const uint32_t *)(block_base + 4));
+ else
+ return *((const uint16_t *)(block_base + 1));
+}
+
static struct bdb_block *find_section(const struct bdb_header *bdb,
int section_id, int length)
{
struct bdb_block *block;
unsigned char *base = (unsigned char *)bdb;
- int idx = 0;
- uint16_t total, current_size;
+ int index = 0;
+ uint32_t total, current_size;
unsigned char current_id;
/* skip to first section */
- idx += bdb->header_size;
+ index += bdb->header_size;
total = bdb->bdb_size;
if (total > length)
total = length;
@@ -98,20 +109,22 @@ static struct bdb_block *find_section(const struct
bdb_header *bdb,
}
/* walk the sections looking for section_id */
- while (idx + 3 < total) {
- current_id = *(base + idx);
- current_size = *(uint16_t *)(base + idx + 1);
- if (idx + current_size > total)
+ while (index + 3 < total) {
+ current_id = *(base + index);
+ current_size = _get_blocksize(base + index);
+ index += 3;
+
+ if (index + current_size > total)
return NULL;
if (current_id == section_id) {
block->id = current_id;
block->size = current_size;
- block->data = base + idx + 3;
+ block->data = base + index;
return block;
}
- idx += current_size + 3;
+ index += current_size;
}
free(block);
@@ -993,22 +1006,13 @@ static const uint8_t *dump_sequence(const uint8_t *data)
return data;
}
-static uint16_t get_blocksize(void *p)
-{
- uint16_t *block_ptr, block_size;
-
- block_ptr = (uint16_t *)((char *)p - 2);
- block_size = *block_ptr;
- return block_size;
-}
-
static void dump_mipi_sequence(const struct bdb_header *bdb,
const struct bdb_block *block)
{
struct bdb_mipi_sequence *sequence = block->data;
const uint8_t *data;
int i, panel_id, seq_size;
- uint16_t block_size;
+ uint32_t block_size;
/* Check if we have sequence block as well */
if (!sequence) {
@@ -1021,7 +1025,7 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
if (sequence->version >= 3)
return;
- block_size = get_blocksize(sequence);
+ block_size = block->size;
data = &sequence->data[0];
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 5/6] intel_bios_reader: port the sequence block parsing from kernel
Reuse the same code as kernel. Also parses v3, although does not
actually dump that stuff yet.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 141 +-
1 file changed, 140 insertions(+), 1 deletion(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index eb550817c44e..944ad5315f3a 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -1054,12 +1054,120 @@ find_panel_sequence_block(const struct
bdb_mipi_sequence *sequence,
return NULL;
}
+static int goto_next_sequence(const uint8_t *data, int index, int total)
+{
+ uint16_t len;
+
+ /* Skip Sequence Byte. */
+ for (index = index + 1; index < total; index += len) {
+ uint8_t operation_byte = *(data + index);
+ index++;
+
+ switch (operation_byte) {
+ case MIPI_SEQ_ELEM_END:
+ return index;
+ case MIPI_SEQ_ELEM_SEND_PKT:
+ if (index + 4 > total)
+ return 0;
+
+ len = *((const uint16_t *)(data + index + 2)) + 4;
+ break;
+ case MIPI_SEQ_ELEM_DELAY:
+ len = 4;
+ break;
+ case MIPI_SEQ_ELEM_GPIO:
+ len = 2;
+ break;
+ case MIPI_SEQ_ELEM_I2C:
+ if (index + 7 > total)
+ return 0;
+ len = *(data + index + 6) + 7;
+ break;
+ default:
+ fprintf(stderr, "Unknown operation byte\n");
+ return 0;
+ }
+ }
+
+ return 0;
+}
+
+static int goto_next_sequence_v3(const uint8_t *data, int index, int total)
+{
+ int seq_end;
+ uint16_t len;
+ uint32_t size_of_sequence;
+
+ /*
+* Could skip sequence based on Size of Sequence alone, but also do some
+* checking on the structure.
+*/
+ if (total < 5) {
+ fprintf(stderr, "Too small sequence size\n");
+ return 0;
+ }
+
+ /* Skip Sequence Byte. */
+ index++;
+
+ /*
+* Size of Sequence. Excludes the Sequence Byte and the size itself,
+* includes MIPI_SEQ_ELEM_END byte, excludes the final MIPI_SEQ_END
+* byte.
+*/
+ size_of_sequence = *((const uint32_t *)(data + index));
+ index += 4;
+
+ seq_end = index + size_of_sequence;
+ if (seq_end > total) {
+ fprintf(stderr, "Invalid sequence size\n");
+ return 0;
+ }
+
+ for (; index < total; index += len) {
+ uint8_t operation_byte = *(data + index);
+ index++;
+
+ if (operation_byte == MIPI_SEQ_ELEM_END) {
+ if (index != seq_end) {
+ fprintf(stderr, "Invalid element structure\n");
+ return 0;
+ }
+ return index;
+ }
+
+ len = *(data + index);
+ index++;
+
+ /*
+* FIXME: Would be nice to check elements like for v1/v2 in
+* goto_next_sequence() above.
+*/
+ switch (operation_byte) {
+ case MIPI_SEQ_ELEM_SEND_PKT:
+ case MIPI_SEQ_ELEM_DELAY:
+ case MIPI_SEQ_ELEM_GPIO:
+ case MIPI_SEQ_ELEM_I2C:
+ case MIPI_SEQ_ELEM_SPI:
+ case MIPI_SEQ_ELEM_PMIC:
+ break;
+ default:
+ fprintf(stderr, "Unknown operation byte %u\n",
+ operation_byte);
+ break;
+ }
+ }
+
+ return 0;
+}
+
static void dump_mipi_sequence(const struct bdb_header *bdb,
const struct bdb_block *block)
{
const struct bdb_mipi_sequence *sequence = block->data;
const uint8_t *data;
uint32_t seq_size;
+ int index = 0;
/* Check if we have sequence block as well */
if (!sequence) {
@@ -1069,14 +1177,45 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
printf("\tSequence block version v%u\n", sequence->version);
- if (sequence->version >= 3)
+ /* Fail gracefully for forward incompatible sequence block. */
+ if (sequence->version >= 4) {
+ fprintf(stderr, "Unable to parse MIPI Sequence Block v%u\n",
+ sequence->version);
return;
+ }
data = find_panel_sequence_block(sequence, panel_type,
block->size, &seq_size);
if (!data)
return;
+ /* Parse the sequences. Corresponds to VBT parsi
[Intel-gfx] [i-g-t PATCH 1/6] intel_bios_reader: pass bdb pointer around instead of having as global
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 88 ---
1 file changed, 52 insertions(+), 36 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index b31f648f0607..7b525f220f16 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -71,13 +71,13 @@ struct bdb_block {
void *data;
};
-struct bdb_header *bdb;
struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
static int tv_present;
static int lvds_present;
static int panel_type;
-static struct bdb_block *find_section(int section_id, int length)
+static struct bdb_block *find_section(const struct bdb_header *bdb,
+ int section_id, int length)
{
struct bdb_block *block;
unsigned char *base = (unsigned char *)bdb;
@@ -118,7 +118,8 @@ static struct bdb_block *find_section(int section_id, int
length)
return NULL;
}
-static void dump_general_features(const struct bdb_block *block)
+static void dump_general_features(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_general_features *features = block->data;
@@ -170,7 +171,8 @@ static void dump_general_features(const struct bdb_block
*block)
lvds_present = 1; /* should be based on IS_MOBILE() */
}
-static void dump_backlight_info(const struct bdb_block *block)
+static void dump_backlight_info(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_lvds_backlight *backlight = block->data;
struct blc_struct *blc;
@@ -352,7 +354,8 @@ static const char *efp_conn(uint8_t type)
-static void dump_child_device(struct child_device_config *child)
+static void dump_child_device(const struct bdb_header *bdb,
+ struct child_device_config *child)
{
char child_id[11];
@@ -390,7 +393,8 @@ static void dump_child_device(struct child_device_config
*child)
}
}
-static void dump_general_definitions(const struct bdb_block *block)
+static void dump_general_definitions(const struct bdb_header *bdb,
+const struct bdb_block *block)
{
struct bdb_general_definitions *defs = block->data;
int i;
@@ -409,10 +413,11 @@ static void dump_general_definitions(const struct
bdb_block *block)
child_device_num = (block->size - sizeof(*defs)) /
defs->child_dev_size;
for (i = 0; i < child_device_num; i++)
- dump_child_device((void*)&defs->devices[i *
defs->child_dev_size]);
+ dump_child_device(bdb,(void*)&defs->devices[i *
defs->child_dev_size]);
}
-static void dump_child_devices(const struct bdb_block *block)
+static void dump_child_devices(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_child_devices *child_devs = block->data;
struct child_device_config *child;
@@ -435,7 +440,8 @@ static void dump_child_devices(const struct bdb_block
*block)
}
}
-static void dump_lvds_options(const struct bdb_block *block)
+static void dump_lvds_options(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_lvds_options *options = block->data;
@@ -451,7 +457,8 @@ static void dump_lvds_options(const struct bdb_block *block)
printf("\tPFIT mode: %d\n", options->pfit_mode);
}
-static void dump_lvds_ptr_data(const struct bdb_block *block)
+static void dump_lvds_ptr_data(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_lvds_lfp_data_ptrs *ptrs = block->data;
@@ -461,7 +468,8 @@ static void dump_lvds_ptr_data(const struct bdb_block
*block)
lvds_lfp_data_ptrs = ptrs;
}
-static void dump_lvds_data(const struct bdb_block *block)
+static void dump_lvds_data(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_lvds_lfp_data *lvds_data = block->data;
struct bdb_lvds_lfp_data_ptrs *ptrs = lvds_lfp_data_ptrs;
@@ -533,7 +541,8 @@ static void dump_lvds_data(const struct bdb_block *block)
}
}
-static void dump_driver_feature(const struct bdb_block *block)
+static void dump_driver_feature(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_driver_feature *feature = block->data;
@@ -599,7 +608,8 @@ static void dump_driver_feature(const struct bdb_block
*block)
feature->legacy_crt_max_refresh);
}
-static void dump_edp(const struct bdb_block *block)
+static void dump_edp(const struct bdb_header *bdb,
+const struct bdb_block *block)
{
struct bdb_edp *edp = block->data;
int bpp, msa;
@@ -728,7 +738,8 @@ print_detail_timing_data(struct lvds_dvo_timing2
*dvo_timing
[Intel-gfx] [i-g-t PATCH 3/6] intel_bios_reader: make the VBT pointers more const
In const we trust.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 56 +++
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 496f2b4f8d1e..7dbda3eac77c 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -69,10 +69,10 @@ uint8_t *VBIOS;
struct bdb_block {
uint8_t id;
uint32_t size;
- void *data;
+ const void *data;
};
-struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
+const struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
static int tv_present;
static int lvds_present;
static int panel_type;
@@ -91,7 +91,7 @@ static struct bdb_block *find_section(const struct bdb_header
*bdb,
int section_id, int length)
{
struct bdb_block *block;
- unsigned char *base = (unsigned char *)bdb;
+ const uint8_t *base = (const uint8_t *)bdb;
int index = 0;
uint32_t total, current_size;
unsigned char current_id;
@@ -134,7 +134,7 @@ static struct bdb_block *find_section(const struct
bdb_header *bdb,
static void dump_general_features(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_general_features *features = block->data;
+ const struct bdb_general_features *features = block->data;
printf("\tPanel fitting: ");
switch (features->panel_fitting) {
@@ -187,8 +187,8 @@ static void dump_general_features(const struct bdb_header
*bdb,
static void dump_backlight_info(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_lvds_backlight *backlight = block->data;
- struct blc_struct *blc;
+ const struct bdb_lvds_backlight *backlight = block->data;
+ const struct blc_struct *blc;
if (sizeof(struct blc_struct) != backlight->blcstruct_size) {
printf("\tBacklight struct sizes don't match (expected %zu, got
%u), skipping\n",
@@ -409,7 +409,7 @@ static void dump_child_device(const struct bdb_header *bdb,
static void dump_general_definitions(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_general_definitions *defs = block->data;
+ const struct bdb_general_definitions *defs = block->data;
int i;
int child_device_num;
@@ -432,8 +432,8 @@ static void dump_general_definitions(const struct
bdb_header *bdb,
static void dump_child_devices(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_child_devices *child_devs = block->data;
- struct child_device_config *child;
+ const struct bdb_child_devices *child_devs = block->data;
+ const struct child_device_config *child;
int i;
for (i = 0; i < DEVICE_CHILD_SIZE; i++) {
@@ -456,7 +456,7 @@ static void dump_child_devices(const struct bdb_header *bdb,
static void dump_lvds_options(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_lvds_options *options = block->data;
+ const struct bdb_lvds_options *options = block->data;
panel_type = options->panel_type;
printf("\tPanel type: %d\n", panel_type);
@@ -473,7 +473,7 @@ static void dump_lvds_options(const struct bdb_header *bdb,
static void dump_lvds_ptr_data(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_lvds_lfp_data_ptrs *ptrs = block->data;
+ const struct bdb_lvds_lfp_data_ptrs *ptrs = block->data;
printf("\tNumber of entries: %d\n", ptrs->lvds_entries);
@@ -484,8 +484,8 @@ static void dump_lvds_ptr_data(const struct bdb_header *bdb,
static void dump_lvds_data(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_lvds_lfp_data *lvds_data = block->data;
- struct bdb_lvds_lfp_data_ptrs *ptrs = lvds_lfp_data_ptrs;
+ const struct bdb_lvds_lfp_data *lvds_data = block->data;
+ const struct bdb_lvds_lfp_data_ptrs *ptrs = lvds_lfp_data_ptrs;
int num_entries;
int i;
int hdisplay, hsyncstart, hsyncend, htotal;
@@ -509,11 +509,11 @@ static void dump_lvds_data(const struct bdb_header *bdb,
num_entries);
for (i = 0; i < num_entries; i++) {
- uint8_t *lfp_data_ptr =
- (uint8_t *) lvds_data->data + lfp_data_size * i;
- uint8_t *timing_data = lfp_data_ptr + dvo_offset;
- struct bdb_lvds_lfp_data_entry *lfp_data =
- (struct bdb_lvds_lfp_data_entry *)lfp_data_ptr;
+ const uint8_t *lfp_data_ptr =
+ (const uint8_t *) lvds_data->data + lfp_data_size * i;
+ const uint8_t *timing_data = lfp_data_ptr + dvo_off
[Intel-gfx] [i-g-t PATCH 6/6] intel_bios_reader: dump MIPI sequence block v3
Similar to what's done in kernel. It's a bit artificial that the parsing
and dumping are two separate steps in the userspace tool, but it's
easier to follow and debug the code when both the kernel and userspace
are similar.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 46 ++
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 944ad5315f3a..d73ff5b32e35 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -973,7 +973,7 @@ static const char *sequence_name(enum mipi_seq seq_id)
return "(unknown)";
}
-static const uint8_t *dump_sequence(const uint8_t *data)
+static const uint8_t *dump_sequence(const uint8_t *data, uint8_t seq_version)
{
fn_mipi_elem_dump mipi_elem_dump;
@@ -982,21 +982,33 @@ static const uint8_t *dump_sequence(const uint8_t *data)
/* Skip Sequence Byte. */
data++;
+ /* Skip Size of Sequence. */
+ if (seq_version >= 3)
+ data += 4;
+
while (1) {
uint8_t operation_byte = *data++;
+ uint8_t operation_size = 0;
if (operation_byte == MIPI_SEQ_ELEM_END)
break;
- if (operation_byte < ARRAY_SIZE(dump_elem) &&
- dump_elem[operation_byte])
+ if (operation_byte < ARRAY_SIZE(dump_elem))
mipi_elem_dump = dump_elem[operation_byte];
else
mipi_elem_dump = NULL;
+ /* Size of Operation. */
+ if (seq_version >= 3)
+ operation_size = *data++;
+
if (mipi_elem_dump) {
data = mipi_elem_dump(data);
+ } else if (operation_size) {
+ /* We have size, skip. */
+ data += operation_size;
} else {
+ /* No size, can't skip without parsing. */
printf("Error: Unsupported MIPI element %u\n",
operation_byte);
return NULL;
@@ -1167,7 +1179,8 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
const struct bdb_mipi_sequence *sequence = block->data;
const uint8_t *data;
uint32_t seq_size;
- int index = 0;
+ int index = 0, i;
+ const uint8_t *sequence_ptrs[MIPI_SEQ_MAX] = {};
/* Check if we have sequence block as well */
if (!sequence) {
@@ -1200,6 +1213,8 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
return;
}
+ sequence_ptrs[seq_id] = data + index;
+
if (sequence->version >= 3)
index = goto_next_sequence_v3(data, index, seq_size);
else
@@ -1210,26 +1225,9 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
}
}
- if (sequence->version >= 3) {
- fprintf(stderr, "Unable to dump MIPI Sequence Block v%u\n",
- sequence->version);
- return;
- }
-
- /*
-* loop into the sequence data and split into multiple sequneces
-* There are only 5 types of sequences as of now
-*/
-
-while (1) {
- int seq_id = *data;
- if (seq_id == MIPI_SEQ_END)
- break;
-
- data = dump_sequence(data);
- if (!data)
- break;
- }
+ /* Dump the sequences. Corresponds to sequence execution in kernel. */
+ for (i = 0; i < ARRAY_SIZE(sequence_ptrs); i++)
+ dump_sequence(sequence_ptrs[i], sequence->version);
}
static int
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 0/6] intel_bios_reader: support MIPI sequence block v3
Support MIPI sequence block v3 in the intel_bios_reader tool. This is mostly copied from the kernel. It makes some of the parts a bit artifical for an userspace tool, but hey, this pattern has been followed all around in IGT and it makes debugging kernel issues much easier that the code is similar. BR, Jani. Jani Nikula (6): intel_bios_reader: pass bdb pointer around instead of having as global intel_bios_reader: fix size handling for 32-bit block size intel_bios_reader: make the VBT pointers more const intel_bios_reader: port find_panel_sequence_block from kernel intel_bios_reader: port the sequence block parsing from kernel intel_bios_reader: dump MIPI sequence block v3 tools/intel_bios_reader.c | 412 +- 1 file changed, 296 insertions(+), 116 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) UNSTABLE dmesg-warn -> PASS (bdw-nuci7) dmesg-warn -> PASS (bdw-ultra) Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:0 dfail:0 fail:1 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:132 dwarn:1 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1189/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers
Some of the HW registers are privileged and cannot be written to from
non-privileged batch buffers coming from userspace unless they are added to
the HW whitelist. This whitelist is maintained by HW and it is different from
SW whitelist. Userspace need write access to them to implement preemption
related WA.
The reason for using this approach is, the register bits that control
preemption granularity at the HW level are not context save/restored; so even
if we set these bits always in kernel they are going to change once the
context is switched out. We can consider making them non-privileged by
default but these registers also contain other chicken bits which should not
be allowed to be modified.
In the later revisions controlling bits are save/restored at context level but
in the existing revisions these are exported via other debug registers and
should be on the whitelist. This patch adds changes to provide HW with a list
of registers to be whitelisted. HW checks this list during execution and
provides access accordingly.
HW imposes a limit on the number of registers on whitelist and it is
per-engine. At this point we are only enabling whitelist for RCS and we don't
foresee any requirement for other engines.
The registers to be whitelisted are added using generic workaround list
mechanism, even these are only enablers for userspace workarounds. But by
sharing this mechanism we get some test assets without additional cost (Mika).
v2: rebase
v3: parameterize RING_FORCE_TO_NONPRIV() as _MMIO() should be limited to
i915_reg.h (Ville), drop inline for wa_ring_whitelist_reg (Mika).
v4: improvements suggested by Chris Wilson.
Clarify that this is HW whitelist and different from the one maintained in
driver. This list is engine specific but it gets initialized along with other
WA which is RCS specific thing, so make it clear that we are not doing any
cross engine setup during initialization.
Make HW whitelist count of each engine available in debugfs.
Reviewed-by: Chris Wilson
Reviewed-by: Mika Kuoppala
Cc: Mika Kuoppala
Cc: Chris Wilson
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_debugfs.c | 15 ++-
drivers/gpu/drm/i915/i915_drv.h | 9 -
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 17 +
4 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e3377ab..7eb002c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3229,9 +3229,11 @@ static int i915_wa_registers(struct seq_file *m, void
*unused)
{
int i;
int ret;
+ struct intel_engine_cs *ring;
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+ struct i915_workarounds *workarounds = &dev_priv->workarounds;
ret = mutex_lock_interruptible(&dev->struct_mutex);
if (ret)
@@ -3239,15 +3241,18 @@ static int i915_wa_registers(struct seq_file *m, void
*unused)
intel_runtime_pm_get(dev_priv);
- seq_printf(m, "Workarounds applied: %d\n", dev_priv->workarounds.count);
- for (i = 0; i < dev_priv->workarounds.count; ++i) {
+ seq_printf(m, "Workarounds applied: %d\n", workarounds->count);
+ for_each_ring(ring, dev_priv, i)
+ seq_printf(m, "HW whitelist count for %s: %d\n",
+ ring->name, workarounds->hw_whitelist_count[i]);
+ for (i = 0; i < workarounds->count; ++i) {
i915_reg_t addr;
u32 mask, value, read;
bool ok;
- addr = dev_priv->workarounds.reg[i].addr;
- mask = dev_priv->workarounds.reg[i].mask;
- value = dev_priv->workarounds.reg[i].value;
+ addr = workarounds->reg[i].addr;
+ mask = workarounds->reg[i].mask;
+ value = workarounds->reg[i].value;
read = I915_READ(addr);
ok = (value & mask) == (read & mask);
seq_printf(m, "0x%X: 0x%08X, mask: 0x%08X, read: 0x%08x,
status: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 104bd18..83fccc0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1653,11 +1653,18 @@ struct i915_wa_reg {
u32 mask;
};
-#define I915_MAX_WA_REGS 16
+/*
+ * RING_MAX_NONPRIV_SLOTS is per-engine but at this point we are only
+ * allowing it for RCS as we don't foresee any requirement of having
+ * a whitelist for other engines. When it is really required for
+ * other engines then the limit need to be increased.
+ */
+#define I915_MAX_WA_REGS (16 + RING_MAX_NONPRIV_SLOTS)
struct i915_workarounds {
struct i915_wa_reg reg[I915_MAX_WA_REGS];
u32 count;
+
Re: [Intel-gfx] [PATCH 7/7] drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW
Hi Mahesh, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160114] [cannot apply to v4.4] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Shobhit-Kumar/Misc-WM-fixes-and-Arbitrated-Display-Bandwidth-WA-for-SKL/20160114-200444 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-defconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/built-in.o: In function `skl_update_wm': >> intel_pm.c:(.text+0xdcbfb): undefined reference to `__udivdi3' intel_pm.c:(.text+0xdccb7): undefined reference to `__udivdi3' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bios: Fix the sequence size calculations for MIPI seq v3
Two errors in a single line. The size was read from the wrong offset,
and the end index didn't take the five bytes for sequence byte and size
of sequence into account. Fix it all, and break up the calculations a
bit to make it clearer.
Cc: Ville Syrjälä
Reported-by: Mika Kahola
Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 12e2f8b8bf9c..bf62a19c8f69 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -842,6 +842,7 @@ static int goto_next_sequence_v3(const u8 *data, int index,
int total)
{
int seq_end;
u16 len;
+ u32 size_of_sequence;
/*
* Could skip sequence based on Size of Sequence alone, but also do some
@@ -852,14 +853,24 @@ static int goto_next_sequence_v3(const u8 *data, int
index, int total)
return 0;
}
- seq_end = index + *((const u32 *)(data + 1));
+ /* Skip Sequence Byte. */
+ index++;
+
+ /*
+* Size of Sequence. Excludes the Sequence Byte and the size itself,
+* includes MIPI_SEQ_ELEM_END byte, excludes the final MIPI_SEQ_END
+* byte.
+*/
+ size_of_sequence = *((const uint32_t *)(data + index));
+ index += 4;
+
+ seq_end = index + size_of_sequence;
if (seq_end > total) {
DRM_ERROR("Invalid sequence size\n");
return 0;
}
- /* Skip Sequence Byte and Size of Sequence. */
- for (index = index + 5; index < total; index += len) {
+ for (; index < total; index += len) {
u8 operation_byte = *(data + index);
index++;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Decouple execbuf uAPI from internal implementation
From: Tvrtko Ursulin
At the moment execbuf ring selection is fully coupled to
internal ring ids which is not a good thing on its own.
This dependency is also spread between two source files and
not spelled out at either side which makes it hidden and
fragile.
This patch decouples this dependency by introducing an explicit
translation table of execbuf uAPI to ring id close to the only
call site (i915_gem_do_execbuffer).
This way we are free to change driver internal implementation
details without breaking userspace. All state relating to the
uAPI is now contained in, or next to, i915_gem_do_execbuffer.
As a side benefit, this patch decreases the compiled size
of i915_gem_do_execbuffer.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 4 +-
drivers/gpu/drm/i915/i915_gem.c| 2 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 103 +
drivers/gpu/drm/i915/intel_ringbuffer.h| 10 +--
4 files changed, 56 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb7bb97f7316..35d5d6099a44 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -334,7 +334,7 @@ struct drm_i915_file_private {
unsigned boosts;
} rps;
- struct intel_engine_cs *bsd_ring;
+ unsigned int bsd_ring;
};
enum intel_dpll_id {
@@ -1300,7 +1300,7 @@ struct i915_gem_mm {
bool busy;
/* the indicator for dispatch video commands on two BSD rings */
- int bsd_ring_dispatch_index;
+ unsigned int bsd_ring_dispatch_index;
/** Bit 6 swizzling required for X tiling */
uint32_t bit_6_swizzle_x;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ddc21d4b388d..26e6842f2df3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5112,6 +5112,8 @@ int i915_gem_open(struct drm_device *dev, struct drm_file
*file)
spin_lock_init(&file_priv->mm.lock);
INIT_LIST_HEAD(&file_priv->mm.request_list);
+ file_priv->bsd_ring = -1;
+
ret = i915_gem_context_open(dev, file);
if (ret)
kfree(file_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index d469c4779ff5..cd8646a23780 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1328,33 +1328,23 @@ i915_gem_ringbuffer_submission(struct
i915_execbuffer_params *params,
/**
* Find one BSD ring to dispatch the corresponding BSD command.
- * The Ring ID is returned.
+ * The ring index is returned.
*/
-static int gen8_dispatch_bsd_ring(struct drm_device *dev,
- struct drm_file *file)
+static unsigned int
+gen8_dispatch_bsd_ring(struct drm_i915_private *dev_priv, struct drm_file
*file)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_file_private *file_priv = file->driver_priv;
- /* Check whether the file_priv is using one ring */
- if (file_priv->bsd_ring)
- return file_priv->bsd_ring->id;
- else {
- /* If no, use the ping-pong mechanism to select one ring */
- int ring_id;
-
- mutex_lock(&dev->struct_mutex);
- if (dev_priv->mm.bsd_ring_dispatch_index == 0) {
- ring_id = VCS;
- dev_priv->mm.bsd_ring_dispatch_index = 1;
- } else {
- ring_id = VCS2;
- dev_priv->mm.bsd_ring_dispatch_index = 0;
- }
- file_priv->bsd_ring = &dev_priv->ring[ring_id];
- mutex_unlock(&dev->struct_mutex);
- return ring_id;
+ /* Check whether the file_priv has already selected one ring. */
+ if ((int)file_priv->bsd_ring < 0) {
+ /* If not, use the ping-pong mechanism to select one. */
+ mutex_lock(&dev_priv->dev->struct_mutex);
+ file_priv->bsd_ring = dev_priv->mm.bsd_ring_dispatch_index;
+ dev_priv->mm.bsd_ring_dispatch_index ^= 1;
+ mutex_unlock(&dev_priv->dev->struct_mutex);
}
+
+ return file_priv->bsd_ring;
}
static struct drm_i915_gem_object *
@@ -1377,6 +1367,16 @@ eb_get_batch(struct eb_vmas *eb)
return vma->obj;
}
+#define I915_USER_RINGS (4)
+
+static const enum intel_ring_id user_ring_map[I915_USER_RINGS + 1] = {
+ [I915_EXEC_DEFAULT] = RCS,
+ [I915_EXEC_RENDER] = RCS,
+ [I915_EXEC_BLT] = BCS,
+ [I915_EXEC_BSD] = VCS,
+ [I915_EXEC_VEBOX] = VECS
+};
+
static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
@@ -1393,6 +1393,7 @@ i915_gem_do_execbuffer(struct drm_device *
Re: [Intel-gfx] ✗ failure: Fi.CI.BAT
On Thu, Jan 14, 2016 at 02:49:45PM -, Patchwork wrote: > == Summary == > > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: > 2016y-01m-14d-13h-06m-44s UTC integration manifest > > Test gem_ctx_basic: > pass -> FAIL (bdw-ultra) "Returncode -15" and nothing more. Weird. > Test gem_storedw_loop: > Subgroup basic-render: > dmesg-warn -> PASS (bdw-nuci7) > dmesg-warn -> PASS (bdw-ultra) > > bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 > bdw-ultratotal:138 pass:131 dwarn:0 dfail:0 fail:1 skip:6 > bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 > hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 > hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 > ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 > ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 > skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 > snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 > snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 > > Results at /archive/results/CI_IGT_test/Patchwork_1188/ -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) dmesg-warn -> PASS (bdw-ultra) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:0 dfail:0 fail:1 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1188/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ failure: Fi.CI.BAT
On Thu, Jan 14, 2016 at 02:20:40PM -, Patchwork wrote: > == Summary == > > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: > 2016y-01m-14d-13h-06m-44s UTC integration manifest > > Test gem_basic: > Subgroup create-close: > pass -> DMESG-WARN (skl-i7k-2) > Test gem_cpu_reloc: > Subgroup basic: > pass -> DMESG-FAIL (skl-i7k-2) > Test gem_ctx_param_basic: > Subgroup basic: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup invalid-param-set: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup non-root-set-no-zeromap: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup root-set-no-zeromap-disabled: > pass -> DMESG-WARN (skl-i7k-2) > Test gem_mmap: > Subgroup basic: > pass -> DMESG-WARN (skl-i7k-2) > Test gem_mmap_gtt: > Subgroup basic-read: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup basic-write: > pass -> DMESG-WARN (skl-i7k-2) > Test gem_storedw_loop: > Subgroup basic-render: > dmesg-warn -> PASS (skl-i5k-2) UNSTABLE > dmesg-warn -> PASS (bdw-nuci7) > dmesg-warn -> PASS (skl-i7k-2) UNSTABLE > Test kms_addfb_basic: > Subgroup addfb25-modifier-no-flag: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup addfb25-x-tiled-mismatch: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup addfb25-yf-tiled: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup bad-pitch-1024: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup bad-pitch-63: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup bad-pitch-999: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup clobberred-modifier: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup too-high: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup too-wide: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup unused-offsets: > pass -> DMESG-WARN (skl-i7k-2) > Test kms_flip: > Subgroup basic-plain-flip: > pass -> DMESG-FAIL (skl-i7k-2) > Test kms_pipe_crc_basic: > Subgroup nonblocking-crc-pipe-a-frame-sequence: > pass -> DMESG-FAIL (skl-i7k-2) > Subgroup read-crc-pipe-b-frame-sequence: > pass -> DMESG-FAIL (skl-i7k-2) > Test prime_self_import: > Subgroup basic-with_two_bos: > pass -> DMESG-WARN (skl-i7k-2) Looks like the GPU died or something on that skl. Can't imagine it being related to watermark patches. Unfortunately these didn't cure the recent underrun regressions from the ilk-ivb machines. So seems like there's something more busted somewhere. > > bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 > bdw-ultratotal:138 pass:131 dwarn:1 dfail:0 fail:0 skip:6 > bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 > hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 > hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 > ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 > ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 > skl-i5k-2total:141 pass:132 dwarn:1 dfail:0 fail:0 skip:8 > skl-i7k-2total:141 pass:108 dwarn:20 dfail:4 fail:0 skip:8 > snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 > snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 > > Results at /archive/results/CI_IGT_test/Patchwork_1187/ -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/9] staging/android/sync: Move sync framework out of staging
On 14/01/2016 13:42, Gustavo Padovan wrote: Hi John, 2016-01-14 John Harrison : On 13/01/2016 19:00, Gustavo Padovan wrote: Hi John, 2016-01-13 john.c.harri...@intel.com : From: John Harrison The sync framework is now used by the i915 driver. Therefore it can be moved out of staging and into the regular tree. Also, the public interfaces can actually be made public and exported. I also have been working on de-staging the sync framework, but I've taken the approach of cleaning up the sync framework first. e.g., I got rid of sync_pt and use struct fence directly, also sync_timeline is now fence_timeline and its ops are gone in favor of fence_ops. My current work is here: https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=sync My current plan is clean up patches, add commits messages and document the changes I've made and then it should be ready for a RFC. Gustavo Hello, Sounds good. I did note in my cover letter that these patches were only being posted to let people review the i915 side of the changes on a complete and working tree. Once we found out you were working on the de-stage the decision was to let you get on with it and not duplicate the effort here :). Note that patches four and five of this series are enhancements to the sync code rather than just de-staging it. Would they still be applicable to your new and improved version? Yes, with a small rework we can surely apply them on top of my changes. Do you have an expected time scale for when your patches will land? I hope to send a RFC sometime next week, after that it will depend on how many comments and iterations I get from upstream. Make sure to CC myself and hopefully I should be able to do some testing/reviewing for you. Also, do you have any sort of overview document explaining what externally visible changes you are making and what the implications are for other drivers that are using the API? Not yet. But I'll write one. In short: SW_SYNC didn't change from API point of view. And I replaced sync_timeline with fence_timeline and sync_pt with fence changing the respective functions name, e.g., sync_timeline_create is now fence_timeline_create. Re the SW_SYNC_USER bits, we were just using that for a user land test program. The idea was to create an timeline external to the i915 driver and pass sync points in to i915 to be waited on and check that the i915 work itself only happens after the test signals the timeline appropriately. If this interface is going away, is there a plan to replace it with any other mechanism for doing similar? Or do we have to create some kind of dummy kernel module in order to get a testing timeline? I've moved it to debugfs. You just need to point your test program to /sync/sw_sync and everything will continue to work. Okay, that sounds easy enough :). Daniel Vetter, do you see any issues with using this in an IGT test? Gustavo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest Test gem_basic: Subgroup create-close: pass -> DMESG-WARN (skl-i7k-2) Test gem_cpu_reloc: Subgroup basic: pass -> DMESG-FAIL (skl-i7k-2) Test gem_ctx_param_basic: Subgroup basic: pass -> DMESG-WARN (skl-i7k-2) Subgroup invalid-param-set: pass -> DMESG-WARN (skl-i7k-2) Subgroup non-root-set-no-zeromap: pass -> DMESG-WARN (skl-i7k-2) Subgroup root-set-no-zeromap-disabled: pass -> DMESG-WARN (skl-i7k-2) Test gem_mmap: Subgroup basic: pass -> DMESG-WARN (skl-i7k-2) Test gem_mmap_gtt: Subgroup basic-read: pass -> DMESG-WARN (skl-i7k-2) Subgroup basic-write: pass -> DMESG-WARN (skl-i7k-2) Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) UNSTABLE dmesg-warn -> PASS (bdw-nuci7) dmesg-warn -> PASS (skl-i7k-2) UNSTABLE Test kms_addfb_basic: Subgroup addfb25-modifier-no-flag: pass -> DMESG-WARN (skl-i7k-2) Subgroup addfb25-x-tiled-mismatch: pass -> DMESG-WARN (skl-i7k-2) Subgroup addfb25-yf-tiled: pass -> DMESG-WARN (skl-i7k-2) Subgroup bad-pitch-1024: pass -> DMESG-WARN (skl-i7k-2) Subgroup bad-pitch-63: pass -> DMESG-WARN (skl-i7k-2) Subgroup bad-pitch-999: pass -> DMESG-WARN (skl-i7k-2) Subgroup clobberred-modifier: pass -> DMESG-WARN (skl-i7k-2) Subgroup too-high: pass -> DMESG-WARN (skl-i7k-2) Subgroup too-wide: pass -> DMESG-WARN (skl-i7k-2) Subgroup unused-offsets: pass -> DMESG-WARN (skl-i7k-2) Test kms_flip: Subgroup basic-plain-flip: pass -> DMESG-FAIL (skl-i7k-2) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a-frame-sequence: pass -> DMESG-FAIL (skl-i7k-2) Subgroup read-crc-pipe-b-frame-sequence: pass -> DMESG-FAIL (skl-i7k-2) Test prime_self_import: Subgroup basic-with_two_bos: pass -> DMESG-WARN (skl-i7k-2) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:1 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:132 dwarn:1 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:108 dwarn:20 dfail:4 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1187/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/dsi: start using enum mipi_dsi_pixel_format
On Thu, 2016-01-14 at 12:28 +0200, Jani Nikula wrote:
> A small step moving us closer to DRM MIPI DSI code. Use enum
> mipi_dsi_pixel_format instead of our own. The first benefit is being
> able to use common mipi_dsi_pixel_format_to_bpp().
>
> There's a little back and forth conversion with the VBT -> enum ->
> register, since we have just shoved the VBT value into the register
> directly. Longer term, all the VBT parsing and deciphering should be
> done in intel_bios.c, and abstracted there.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 19 +++-
> drivers/gpu/drm/i915/intel_dsi.h | 8 +--
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 36
> +-
> drivers/gpu/drm/i915/intel_dsi_pll.c | 30 +
> 4 files changed, 54 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 91cef3525c93..83f18791c009 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -840,6 +840,23 @@ static void set_dsi_timings(struct drm_encoder *encoder,
> }
> }
>
> +static u32 pixel_format_to_reg(enum mipi_dsi_pixel_format fmt)
> +{
> + switch (fmt) {
> + case MIPI_DSI_FMT_RGB888:
> + return VID_MODE_FORMAT_RGB888;
> + case MIPI_DSI_FMT_RGB666:
> + return VID_MODE_FORMAT_RGB666;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + return VID_MODE_FORMAT_RGB666_PACKED;
> + case MIPI_DSI_FMT_RGB565:
> + return VID_MODE_FORMAT_RGB565;
> + default:
> + MISSING_CASE(fmt);
> + return VID_MODE_FORMAT_RGB666;
> + }
> +}
> +
> static void intel_dsi_prepare(struct intel_encoder *intel_encoder)
> {
> struct drm_encoder *encoder = &intel_encoder->base;
> @@ -910,7 +927,7 @@ static void intel_dsi_prepare(struct intel_encoder
> *intel_encoder)
> val |= intel_dsi->channel << VID_MODE_CHANNEL_NUMBER_SHIFT;
>
> /* XXX: cross-check bpp vs. pixel format? */
> - val |= intel_dsi->pixel_format;
> + val |= pixel_format_to_reg(intel_dsi->pixel_format);
> }
>
> tmp = 0;
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index de7be7f3fb42..54f072cd78f1 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -62,8 +62,12 @@ struct intel_dsi {
> /* number of DSI lanes */
> unsigned int lane_count;
>
> - /* video mode pixel format for MIPI_DSI_FUNC_PRG register */
> - u32 pixel_format;
> + /*
> + * video mode pixel format
> + *
> + * XXX: consolidate on .format in struct mipi_dsi_device.
> + */
> + enum mipi_dsi_pixel_format pixel_format;
>
> /* video mode format for MIPI_VIDEO_MODE_FORMAT register */
> u32 video_mode_format;
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 3f4b9712bffd..9a963fa3491c 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -392,6 +392,25 @@ static const struct drm_panel_funcs vbt_panel_funcs = {
> .get_modes = vbt_panel_get_modes,
> };
>
> +/* XXX: This should be done when parsing the VBT in intel_bios.c */
> +static enum mipi_dsi_pixel_format pixel_format_from_vbt(u32 fmt)
> +{
> + /* It just so happens the VBT matches register contents. */
> + switch (fmt) {
> + case VID_MODE_FORMAT_RGB888:
> + return MIPI_DSI_FMT_RGB888;
> + case VID_MODE_FORMAT_RGB666:
> + return MIPI_DSI_FMT_RGB666;
> + case VID_MODE_FORMAT_RGB666_PACKED:
> + return MIPI_DSI_FMT_RGB666_PACKED;
> + case VID_MODE_FORMAT_RGB565:
> + return MIPI_DSI_FMT_RGB565;
> + default:
> + MISSING_CASE(fmt);
> + return MIPI_DSI_FMT_RGB666;
> + }
> +}
> +
> struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id)
> {
> struct drm_device *dev = intel_dsi->base.base.dev;
> @@ -400,7 +419,7 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
> *intel_dsi, u16 panel_id)
> struct mipi_pps_data *pps = dev_priv->vbt.dsi.pps;
> struct drm_display_mode *mode = dev_priv->vbt.lfp_lvds_vbt_mode;
> struct vbt_panel *vbt_panel;
> - u32 bits_per_pixel = 24;
> + u32 bpp;
> u32 tlpx_ns, extra_byte_count, bitrate, tlpx_ui;
> u32 ui_num, ui_den;
> u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
> @@ -416,15 +435,11 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
> *intel_dsi, u16 panel_id)
> intel_dsi->eotp_pkt = mipi_config->eot_pkt_disabled ? 0 : 1;
> intel_dsi->clock_stop = mipi_config->enable_clk_stop ? 1 : 0;
> intel_dsi->lane_count = mipi_config->lane_cnt + 1;
> - intel_dsi->pixel_form
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dsi: lose the loose 666 format name in favor of packed
On Thu, 2016-01-14 at 12:28 +0200, Jani Nikula wrote:
> The enum mipi_dsi_pixel_format defines MIPI_DSI_FMT_RGB666 for the
> "loose" 24 bpp format and MIPI_DSI_FMT_RGB666_PACKED for the 18 bpp
> format. We have this the other way round, defining a loose version for
> 24 bpp.
>
> Follow suit with what's in enum mipi_dsi_pixel_format to avoid future
> confusion. Rename
>
> VID_MODE_FORMAT_RGB666 -> VID_MODE_FORMAT_RGB666_PACKED
> VID_MODE_FORMAT_RGB666_LOOSE -> VID_MODE_FORMAT_RGB666
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h| 4 ++--
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 +-
> drivers/gpu/drm/i915/intel_dsi_pll.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0a988895165f..379c61677334 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7849,8 +7849,8 @@ enum skl_disp_power_wells {
> #define VID_MODE_FORMAT_MASK(0xf << 7)
> #define VID_MODE_NOT_SUPPORTED (0 << 7)
> #define VID_MODE_FORMAT_RGB565 (1 << 7)
> -#define VID_MODE_FORMAT_RGB666 (2 << 7)
> -#define VID_MODE_FORMAT_RGB666_LOOSE(3 << 7)
> +#define VID_MODE_FORMAT_RGB666_PACKED (2 << 7)
> +#define VID_MODE_FORMAT_RGB666 (3 << 7)
> #define VID_MODE_FORMAT_RGB888 (4 << 7)
> #define CMD_MODE_CHANNEL_NUMBER_SHIFT 5
> #define CMD_MODE_CHANNEL_NUMBER_MASK(3 << 5)
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 1d43e6f37fc1..3f4b9712bffd 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -420,7 +420,7 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
> *intel_dsi, u16 panel_id)
> 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)
> + if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB666_PACKED)
> bits_per_pixel = 18;
> else if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB565)
> bits_per_pixel = 16;
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index bb5e95a1a453..f70df2b42b23 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -37,10 +37,10 @@ static int dsi_pixel_format_bpp(int pixel_format)
> switch (pixel_format) {
> default:
> case VID_MODE_FORMAT_RGB888:
> - case VID_MODE_FORMAT_RGB666_LOOSE:
> + case VID_MODE_FORMAT_RGB666:
> bpp = 24;
> break;
> - case VID_MODE_FORMAT_RGB666:
> + case VID_MODE_FORMAT_RGB666_PACKED:
> bpp = 18;
> break;
> case VID_MODE_FORMAT_RGB565:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: force full detect on sink count change
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
> This patch checks for changes in sink count between short pulse
> hpds and forces full detect when there is a change.
>
> This will allow both detection of hotplug and unplug of panels
> through dongles that give only short pulse for such events.
>
> v2: changed variable type from u8 to bool (Jani)
> return immediately if perform_full_detect is set(Siva)
>
> v3: changed method of determining full detection from using
> pointer to return code (Siva)
>
> Tested-by: Nathan D Ciobanu
> Signed-off-by: Sivakumar Thulasimani
> Signed-off-by: Shubhangi Shrivastava
> ---
> drivers/gpu/drm/i915/intel_dp.c | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 0d58bfd..8a659ee 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4331,12 +4331,14 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> * 3. Use Link Training from 2.5.3.3 and 3.5.1.3
> * 4. Check link status on receipt of hot-plug interrupt
> */
> -static void
> +static bool
Please expand the comment above to indicate what the return value of this
function is supposed to mean.
> intel_dp_short_pulse(struct intel_dp *intel_dp)
> {
> struct drm_device *dev = intel_dp_to_dev(intel_dp);
> u8 sink_irq_vector;
> u8 link_status[DP_LINK_STATUS_SIZE];
> + u8 old_sink_count = intel_dp->sink_count;
> + bool ret;
>
> /*
>* Clearing compliance test variables to allow capturing
> @@ -4348,12 +4350,20 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>
> /* Try to read receiver status if the link appears to be up */
> if (!intel_dp_get_link_status(intel_dp, link_status)) {
> - return;
> + return false;
> }
>
> - /* Now read the DPCD to see if it's actually running */
> - if (!intel_dp_get_dpcd(intel_dp)) {
> - return;
> + /*
> + * Now read the DPCD to see if it's actually running
> + * Don't return immediately if dpcd read failed,
> + * if sink count was 1 and dpcd read failed we need
> + * to do full detection
> + */
> + ret = intel_dp_get_dpcd(intel_dp);
> +
> + if ((old_sink_count != intel_dp->sink_count) || !ret) {
I don't see the connection of the comment above with this. If the dpcd read
fails, the 'return false' will be reached regardless of the previous value of
intel_dp->sink_count. Did you intend to do something different or did I miss
something?
> + /* No need to proceed if we are going to do full detect */
> + return false;
> }
>
> /* Try to read the source of the interrupt */
> @@ -4373,6 +4383,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> intel_dp_check_link_status(intel_dp);
> drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> + return true;
> }
>
> /* XXX this is probably wrong for multiple downstream ports */
> @@ -5095,8 +5107,12 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> }
> }
>
> - if (!intel_dp->is_mst)
> - intel_dp_short_pulse(intel_dp);
> + if (!intel_dp->is_mst) {
> + if (!intel_dp_short_pulse(intel_dp)) {
> + intel_dp_long_pulse(intel_dp
> ->attached_connector);
> + goto put_power;
It could be in a follow up patch, but I think its a good moment to get rid of
the goto put_power. The only thing they do is skip the 'ret = IRQ_HANDLED'
assignment now.
Ander
> + }
> + }
> }
>
> ret = IRQ_HANDLED;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Splitting intel_dp_detect
On Wednesday 13 January 2016 07:03 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2016-01-13 at 13:20 +0200, Ander Conselvan De Oliveira wrote:
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
intel_dp_detect() is called for not just detection but
during modes enumeration as well. Repeating the whole
sequence during each of these calls is wasteful and
time consuming.
This patch moves probing for panel, DPCD read etc done in
intel_dp_detect() to a new function intel_dp_long_pulse().
Note that the behavior of intel_dp_detect() is changed to
report connected or disconnected depending on whether the
EDID is available or not.
This change will be required by further patches in the series
to avoid performing duplicated DPCD operations on hotplug.
v2: Moved a hunk to next patch of the series.
Moved intel_dp_unset_edid to out. (Ander)
v3: Rephrased commit message and intel_dp_unset_dp() is called
within intel_dp_set_dp() to free the previous EDID. (Ander)
Tested-by: Nathan D Ciobanu
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Shubhangi Shrivastava
---
drivers/gpu/drm/i915/intel_dp.c | 56 +-
--
-
1 file changed, 35 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 796e3d3..e3b4208 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -129,6 +129,7 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp,
bool sync);
static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
static void vlv_steal_power_sequencer(struct drm_device *dev,
enum pipe pipe);
+static void intel_dp_unset_edid(struct intel_dp *intel_dp);
static unsigned int intel_dp_unused_lane_mask(int lane_count)
{
@@ -4587,6 +4588,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
struct intel_connector *intel_connector = intel_dp
->attached_connector;
struct edid *edid;
+ intel_dp_unset_edid(intel_dp);
edid = intel_dp_get_edid(intel_dp);
intel_connector->detect_edid = edid;
@@ -4607,9 +4609,10 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
intel_dp->has_audio = false;
}
-static enum drm_connector_status
-intel_dp_detect(struct drm_connector *connector, bool force)
+static void
+intel_dp_long_pulse(struct intel_connector *intel_connector)
{
+ struct drm_connector *connector = &intel_connector->base;
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_digital_port *intel_dig_port =
dp_to_dig_port(intel_dp);
struct intel_encoder *intel_encoder = &intel_dig_port->base;
@@ -4619,17 +4622,6 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
bool ret;
u8 sink_irq_vector;
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
- connector->base.id, connector->name);
- intel_dp_unset_edid(intel_dp);
-
- if (intel_dp->is_mst) {
- /* MST devices are disconnected from a monitor POV */
- if (intel_encoder->type != INTEL_OUTPUT_EDP)
- intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
- return connector_status_disconnected;
- }
-
power_domain = intel_display_port_aux_power_domain(intel_encoder);
intel_display_power_get(to_i915(dev), power_domain);
@@ -4653,14 +4645,8 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
intel_dp_probe_oui(intel_dp);
ret = intel_dp_probe_mst(intel_dp);
- if (ret) {
- /* if we are in MST mode then this connector
- won't appear connected or have anything with EDID on it
*/
- if (intel_encoder->type != INTEL_OUTPUT_EDP)
- intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
This deletion is new in this version of the patch. I think we still need the
hunk above, otherwise we might not properly update the encoder type when we
switch from an HDMI sink connected through a level shifter to an MST sink.
Ander
Encoder type setting for MST is being done in intel_dp_detect(). So,
don't find a need to add it here.
- status = connector_status_disconnected;
+ if (ret)
goto out;
Also, there is no call to intel_dp_unset_edid() for this case, since the code
will reach the label 'out' with status being connected. So in this case the
return value of intel_dp_detect() will depend on the stale value of
intel_dp->detect_edid.
Ander
Yes.. Thats right.. Will add a call to intel_dp_unset_edid() in is_mst()
check of intel_dp_detect().
- }
/*
* Clearing NACK and defer counts to get their exact values
@@ -4691,8 +4677,36 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
}
out:
+ if (status != connector_status_connected)
+ intel_dp_unset_edid(intel_dp);
intel_display_power
Re: [Intel-gfx] [RFC 3/9] staging/android/sync: Move sync framework out of staging
Hi John, 2016-01-14 John Harrison : > On 13/01/2016 19:00, Gustavo Padovan wrote: > >Hi John, > > > >2016-01-13 john.c.harri...@intel.com : > > > >>From: John Harrison > >> > >>The sync framework is now used by the i915 driver. Therefore it can be > >>moved out of staging and into the regular tree. Also, the public > >>interfaces can actually be made public and exported. > >I also have been working on de-staging the sync framework, but I've > >taken the approach of cleaning up the sync framework first. e.g., I got > >rid of sync_pt and use struct fence directly, also sync_timeline is now > >fence_timeline and its ops are gone in favor of fence_ops. My current > >work is here: > > > >https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=sync > > > >My current plan is clean up patches, add commits messages and document > >the changes I've made and then it should be ready for a RFC. > > > > Gustavo > Hello, > > Sounds good. I did note in my cover letter that these patches were only > being posted to let people review the i915 side of the changes on a complete > and working tree. Once we found out you were working on the de-stage the > decision was to let you get on with it and not duplicate the effort here :). > Note that patches four and five of this series are enhancements to the sync > code rather than just de-staging it. Would they still be applicable to your > new and improved version? Yes, with a small rework we can surely apply them on top of my changes. > Do you have an expected time scale for when your patches will land? I hope to send a RFC sometime next week, after that it will depend on how many comments and iterations I get from upstream. > Also, do you have any sort of overview document explaining what externally > visible changes you are making and what the implications are for other > drivers that are using the API? Not yet. But I'll write one. In short: SW_SYNC didn't change from API point of view. And I replaced sync_timeline with fence_timeline and sync_pt with fence changing the respective functions name, e.g., sync_timeline_create is now fence_timeline_create. > > Re the SW_SYNC_USER bits, we were just using that for a user land test > program. The idea was to create an timeline external to the i915 driver and > pass sync points in to i915 to be waited on and check that the i915 work > itself only happens after the test signals the timeline appropriately. If > this interface is going away, is there a plan to replace it with any other > mechanism for doing similar? Or do we have to create some kind of dummy > kernel module in order to get a testing timeline? I've moved it to debugfs. You just need to point your test program to /sync/sw_sync and everything will continue to work. Gustavo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/i915: Add support for mapping an object page by page
On Thu, Jan 14, 2016 at 10:32:11AM +, Tvrtko Ursulin wrote:
> >diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >index b448ad8..5f86596 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >@@ -317,6 +317,11 @@ struct i915_address_space {
> > uint64_t start,
> > uint64_t length,
> > bool use_scratch);
> >+void (*insert_page)(struct i915_address_space *vm,
> >+dma_addr_t addr,
> >+uint64_t offset,
> >+enum i915_cache_level cache_level,
> >+u32 flags);
> > void (*insert_entries)(struct i915_address_space *vm,
> >struct sg_table *st,
> >uint64_t start,
>
> Why not extend the current API to support start page offset and
> number of pages? Could default to full object like today if zero.
> Eg:
>
> void (*insert_entries)(struct i915_address_space *vm,
> struct sg_table *st,
> + unsigned page_offset,
> + unsigned num_pages,
Ouch. That would be quite slow for the insert_page() use case of
page-by-page looping.
> uint64_t start,
> enum i915_cache_level cache_level,
> u32 flags);
>
> That way we would not have two functions for effectively the same
> thing operating on different type of input parameters.
>
> If extending insert_entries is not preferable, then still we could
> add another compatible one, like insert_entries_range or something,
> and then both could share the same underlying implementation for
> less code.
>
> Like this, this patch already does not match current codebase - see
> assert_rpm_atomic_begin in insert_entries.
>
> Also if API between the two was compatible there would be no need
> for i915_gem_object_get_dma_address() and i915_gem_object_get_page()
> could be used instead.
The point was to write a lowlevel analog to provide a complementary API
to insert_entries that could be used for everywhere the we wanted to peek
through the GTT without even touching an object, i.e. for cases where we
might allocate a scratch page and temporarily put it into the GTT.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915: Pass rotation_info to intel_rotate_fb_obj_pages()
From: Ville Syrjälä
intel_rotate_fb_obj_pages() doens't need the entire gtt view, just the
rotation info suffices.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d547eecac242..b3d8e2b0948c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3364,10 +3364,9 @@ rotate_pages(const dma_addr_t *in, unsigned int offset,
}
static struct sg_table *
-intel_rotate_fb_obj_pages(struct i915_ggtt_view *ggtt_view,
+intel_rotate_fb_obj_pages(struct intel_rotation_info *rot_info,
struct drm_i915_gem_object *obj)
{
- struct intel_rotation_info *rot_info = &ggtt_view->params.rotated;
unsigned int size_pages = rot_info->size >> PAGE_SHIFT;
unsigned int size_pages_uv;
struct sg_page_iter sg_iter;
@@ -3507,7 +3506,7 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma)
vma->ggtt_view.pages = vma->obj->pages;
else if (vma->ggtt_view.type == I915_GGTT_VIEW_ROTATED)
vma->ggtt_view.pages =
- intel_rotate_fb_obj_pages(&vma->ggtt_view, vma->obj);
+
intel_rotate_fb_obj_pages(&vma->ggtt_view.params.rotated, vma->obj);
else if (vma->ggtt_view.type == I915_GGTT_VIEW_PARTIAL)
vma->ggtt_view.pages =
intel_partial_pages(&vma->ggtt_view, vma->obj);
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915: Rename the rotated gtt view member to 'rotated'
From: Ville Syrjälä
Also rename 'rotation_info' to 'rotated' to match the view type exactly,
this should avoid confusion which union members is valid for each view
type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7377b6725c33..a3ea6b15c762 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3366,7 +3366,7 @@ static struct sg_table *
intel_rotate_fb_obj_pages(struct i915_ggtt_view *ggtt_view,
struct drm_i915_gem_object *obj)
{
- struct intel_rotation_info *rot_info = &ggtt_view->params.rotation_info;
+ struct intel_rotation_info *rot_info = &ggtt_view->params.rotated;
unsigned int size_pages = rot_info->size >> PAGE_SHIFT;
unsigned int size_pages_uv;
struct sg_page_iter sg_iter;
@@ -3598,7 +3598,7 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
if (view->type == I915_GGTT_VIEW_NORMAL) {
return obj->base.size;
} else if (view->type == I915_GGTT_VIEW_ROTATED) {
- return view->params.rotation_info.size;
+ return view->params.rotated.size;
} else if (view->type == I915_GGTT_VIEW_PARTIAL) {
return view->params.partial.size << PAGE_SHIFT;
} else {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index b448ad832dcf..75a84e116e93 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -156,7 +156,7 @@ struct i915_ggtt_view {
u64 offset;
unsigned int size;
} partial;
- struct intel_rotation_info rotation_info;
+ struct intel_rotation_info rotated;
} params;
struct sg_table *pages;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2bf2e76849b0..e68b2904e68f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2290,7 +2290,7 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
const struct drm_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(fb->dev);
- struct intel_rotation_info *info = &view->params.rotation_info;
+ struct intel_rotation_info *info = &view->params.rotated;
unsigned int tile_size, tile_width, tile_height, cpp;
*view = i915_ggtt_view_normal;
@@ -2957,7 +2957,7 @@ u32 intel_plane_obj_offset(struct intel_plane
*intel_plane,
offset = vma->node.start;
if (plane == 1) {
- offset += vma->ggtt_view.params.rotation_info.uv_start_page *
+ offset += vma->ggtt_view.params.rotated.uv_start_page *
PAGE_SIZE;
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915: Pass stride to rotate_pages()
From: Ville Syrjälä
Pass stride in addition to width and height to rotate_pages(). For now
width and stride are the same, but once framebuffer offsets enter the
scene that may no longer be the case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a3ea6b15c762..d547eecac242 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -,6 +,7 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct
drm_i915_gem_object *obj,
static struct scatterlist *
rotate_pages(const dma_addr_t *in, unsigned int offset,
unsigned int width, unsigned int height,
+unsigned int stride,
struct sg_table *st, struct scatterlist *sg)
{
unsigned int column, row;
@@ -3344,7 +3345,7 @@ rotate_pages(const dma_addr_t *in, unsigned int offset,
}
for (column = 0; column < width; column++) {
- src_idx = width * (height - 1) + column;
+ src_idx = stride * (height - 1) + column;
for (row = 0; row < height; row++) {
st->nents++;
/* We don't need the pages, but need to initialize
@@ -3355,7 +3356,7 @@ rotate_pages(const dma_addr_t *in, unsigned int offset,
sg_dma_address(sg) = in[offset + src_idx];
sg_dma_len(sg) = PAGE_SIZE;
sg = sg_next(sg);
- src_idx -= width;
+ src_idx -= stride;
}
}
@@ -3408,6 +3409,7 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
/* Rotate the pages. */
sg = rotate_pages(page_addr_list, 0,
rot_info->width_pages, rot_info->height_pages,
+rot_info->width_pages,
st, NULL);
/* Append the UV plane if NV12. */
@@ -3423,6 +3425,7 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
rotate_pages(page_addr_list, uv_start_page,
rot_info->width_pages_uv,
rot_info->height_pages_uv,
+rot_info->width_pages_uv,
st, sg);
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915: Standardize on 'cpp' for bytes per pixel
From: Ville Syrjälä
We more or less randomly call the "bytes per pixel" value
'cpp', 'bytes_per_pixel', 'pixel_size', or even 'bpp'. Let's just pick
one and stick to it. I've chosen 'cpp'.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 22 +++---
drivers/gpu/drm/i915/intel_pm.c | 128 +--
drivers/gpu/drm/i915/intel_sprite.c | 34 --
3 files changed, 87 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 686de845176e..33a2b3e18754 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2715,7 +2715,7 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
u32 linear_offset;
u32 dspcntr;
i915_reg_t reg = DSPCNTR(plane);
- int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
+ int cpp = drm_format_plane_cpp(fb->pixel_format, 0);
int x = plane_state->src.x1 >> 16;
int y = plane_state->src.y1 >> 16;
@@ -2775,13 +2775,12 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- linear_offset = y * fb->pitches[0] + x * pixel_size;
+ linear_offset = y * fb->pitches[0] + x * cpp;
if (INTEL_INFO(dev)->gen >= 4) {
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(dev_priv, &x, &y,
- fb->modifier[0],
- pixel_size,
+ fb->modifier[0], cpp,
fb->pitches[0]);
linear_offset -= intel_crtc->dspaddr_offset;
} else {
@@ -2798,7 +2797,7 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
data and adding to linear_offset*/
linear_offset +=
(crtc_state->pipe_src_h - 1) * fb->pitches[0] +
- (crtc_state->pipe_src_w - 1) * pixel_size;
+ (crtc_state->pipe_src_w - 1) * cpp;
}
intel_crtc->adjusted_x = x;
@@ -2846,7 +2845,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
u32 linear_offset;
u32 dspcntr;
i915_reg_t reg = DSPCNTR(plane);
- int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
+ int cpp = drm_format_plane_cpp(fb->pixel_format, 0);
int x = plane_state->src.x1 >> 16;
int y = plane_state->src.y1 >> 16;
@@ -2885,11 +2884,10 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
if (!IS_HASWELL(dev) && !IS_BROADWELL(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- linear_offset = y * fb->pitches[0] + x * pixel_size;
+ linear_offset = y * fb->pitches[0] + x * cpp;
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(dev_priv, &x, &y,
- fb->modifier[0],
- pixel_size,
+ fb->modifier[0], cpp,
fb->pitches[0]);
linear_offset -= intel_crtc->dspaddr_offset;
if (plane_state->base.rotation == BIT(DRM_ROTATE_180)) {
@@ -2903,7 +2901,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
data and adding to linear_offset*/
linear_offset +=
(crtc_state->pipe_src_h - 1) * fb->pitches[0] +
- (crtc_state->pipe_src_w - 1) * pixel_size;
+ (crtc_state->pipe_src_w - 1) * cpp;
}
}
@@ -14735,10 +14733,12 @@ u32 intel_fb_pitch_limit(struct drm_device *dev,
uint64_t fb_modifier,
u32 gen = INTEL_INFO(dev)->gen;
if (gen >= 9) {
+ int cpp = drm_format_plane_cpp(pixel_format, 0);
+
/* "The stride in bytes must not exceed the of the size of 8K
* pixels and 32K bytes."
*/
-return min(8192*drm_format_plane_cpp(pixel_format, 0), 32768);
+ return min(8192 * cpp, 32768);
} else if (gen >= 5 && !IS_VALLEYVIEW(dev) && !IS_CHERRYVIEW(dev)) {
return 32*1024;
} else if (gen >= 4) {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9df9e9a22f3c..fda14852f843 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -546,7 +546,7 @@ static const struct intel_watermark_params i845_wm_info = {
* intel_calculate_wm - calculate watermark level
* @clock_in_khz: pixel clock
* @wm: chip FIFO params
- * @pixel_size: display pixel size
+ * @cpp: bytes per pixel
* @latency
[Intel-gfx] [PATCH 7/8] drm/i915: Make display gtt offsets u32
From: Ville Syrjälä
Using 'unsigned long' for ggtt offsets doesn't make much sense. Use
'u32' instead since we've not yet seen a >4GiB ggtt.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 22 ++
drivers/gpu/drm/i915/intel_drv.h | 12 ++--
drivers/gpu/drm/i915/intel_sprite.c | 6 +++---
3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e68b2904e68f..686de845176e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2454,11 +2454,11 @@ static void intel_unpin_fb_obj(struct drm_framebuffer
*fb,
/* Computes the linear offset to the base tile and adjusts x, y. bytes per
pixel
* is assumed to be a power-of-two. */
-unsigned long intel_compute_tile_offset(struct drm_i915_private *dev_priv,
- int *x, int *y,
- uint64_t fb_modifier,
- unsigned int cpp,
- unsigned int pitch)
+u32 intel_compute_tile_offset(struct drm_i915_private *dev_priv,
+ int *x, int *y,
+ uint64_t fb_modifier,
+ unsigned int cpp,
+ unsigned int pitch)
{
if (fb_modifier != DRM_FORMAT_MOD_NONE) {
unsigned int tile_size, tile_width, tile_height;
@@ -2712,14 +2712,12 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
int plane = intel_crtc->plane;
- unsigned long linear_offset;
- int x = plane_state->src.x1 >> 16;
- int y = plane_state->src.y1 >> 16;
+ u32 linear_offset;
u32 dspcntr;
i915_reg_t reg = DSPCNTR(plane);
- int pixel_size;
-
- pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
+ int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
+ int x = plane_state->src.x1 >> 16;
+ int y = plane_state->src.y1 >> 16;
dspcntr = DISPPLANE_GAMMA_ENABLE;
@@ -2845,7 +2843,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
int plane = intel_crtc->plane;
- unsigned long linear_offset;
+ u32 linear_offset;
u32 dspcntr;
i915_reg_t reg = DSPCNTR(plane);
int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 059b46e22c31..d955084ecda1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -597,7 +597,7 @@ struct intel_crtc {
/* Display surface base address adjustement for pageflips. Note that on
* gen4+ this only adjusts up to a tile, offsets within a tile are
* handled in the hw itself (with the TILEOFF register). */
- unsigned long dspaddr_offset;
+ u32 dspaddr_offset;
int adjusted_x;
int adjusted_y;
@@ -1195,11 +1195,11 @@ void assert_fdi_rx_pll(struct drm_i915_private
*dev_priv,
void assert_pipe(struct drm_i915_private *dev_priv, enum pipe pipe, bool
state);
#define assert_pipe_enabled(d, p) assert_pipe(d, p, true)
#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
-unsigned long intel_compute_tile_offset(struct drm_i915_private *dev_priv,
- int *x, int *y,
- uint64_t fb_modifier,
- unsigned int cpp,
- unsigned int pitch);
+u32 intel_compute_tile_offset(struct drm_i915_private *dev_priv,
+ int *x, int *y,
+ uint64_t fb_modifier,
+ unsigned int cpp,
+ unsigned int pitch);
void intel_prepare_reset(struct drm_device *dev);
void intel_finish_reset(struct drm_device *dev);
void hsw_enable_pc8(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0875c8e0ec0a..f1ee7db0811a 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -350,7 +350,7 @@ vlv_update_plane(struct drm_plane *dplane,
int pipe = intel_plane->pipe;
int plane = intel_plane->plane;
u32 sprctl;
- unsigned long sprsurf_offset, linear_offset;
+ u32 sprsurf_offset, linear_offset;
int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
const struct drm_intel_sprite_colorkey *key = &plane_state->ckey;
int crtc_x = plane_state->dst.x1;
@@ -493,7 +493,7 @@ ivb_update_pla
[Intel-gfx] [PATCH 3/8] drm/i915: Pass the dma_addr_t array as const to rotate_pages()
From: Ville Syrjälä
rotate_pages() doesn't modify the passed in dma addresses, so make
them const.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d7f9ddd52840..7377b6725c33 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3331,7 +3331,7 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct
drm_i915_gem_object *obj,
}
static struct scatterlist *
-rotate_pages(dma_addr_t *in, unsigned int offset,
+rotate_pages(const dma_addr_t *in, unsigned int offset,
unsigned int width, unsigned int height,
struct sg_table *st, struct scatterlist *sg)
{
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Don't leak framebuffer_references if drm_framebuffer_init() fails
From: Ville Syrjälä
Don't increment obj->framebuffer_references until we know we actually
managed to create the framebuffer.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a087892dd797..2bf2e76849b0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14899,7 +14899,6 @@ static int intel_framebuffer_init(struct drm_device
*dev,
drm_helper_mode_fill_fb_struct(&intel_fb->base, mode_cmd);
intel_fb->obj = obj;
- intel_fb->obj->framebuffer_references++;
ret = drm_framebuffer_init(dev, &intel_fb->base, &intel_fb_funcs);
if (ret) {
@@ -14907,6 +14906,8 @@ static int intel_framebuffer_init(struct drm_device
*dev,
return ret;
}
+ intel_fb->obj->framebuffer_references++;
+
return 0;
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915: Set i915_ggtt_view_normal type explicitly
From: Ville Syrjälä
Just for clarity set the type for i915_ggtt_view_normal explicitly.
While at it fix the indentation fail for i915_ggtt_view_rotated.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 56f4f2e58d53..d7f9ddd52840 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -96,9 +96,11 @@
static int
i915_get_ggtt_vma_pages(struct i915_vma *vma);
-const struct i915_ggtt_view i915_ggtt_view_normal;
+const struct i915_ggtt_view i915_ggtt_view_normal = {
+ .type = I915_GGTT_VIEW_NORMAL,
+};
const struct i915_ggtt_view i915_ggtt_view_rotated = {
-.type = I915_GGTT_VIEW_ROTATED
+ .type = I915_GGTT_VIEW_ROTATED,
};
static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] drm/i915: Some more fb offsets[] prep stuff
From: Ville Syrjälä Yanked a few more prep patches from my earlier fb offsets[] work [1]. First few have r-bs, the rest don't. The last two patches are new. Things just tickled my OCD a bit too much so had to deal with them. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/078050.html Ville Syrjälä (8): drm/i915: Don't leak framebuffer_references if drm_framebuffer_init() fails drm/i915: Set i915_ggtt_view_normal type explicitly drm/i915: Pass the dma_addr_t array as const to rotate_pages() drm/i915: Rename the rotated gtt view member to 'rotated' drm/i915: Pass stride to rotate_pages() drm/i915: Pass rotation_info to intel_rotate_fb_obj_pages() drm/i915: Make display gtt offsets u32 drm/i915: Standardize on 'cpp' for bytes per pixel drivers/gpu/drm/i915/i915_gem_gtt.c | 22 +++--- drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 49 +++--- drivers/gpu/drm/i915/intel_drv.h | 12 ++-- drivers/gpu/drm/i915/intel_pm.c | 128 +-- drivers/gpu/drm/i915/intel_sprite.c | 40 +-- 6 files changed, 123 insertions(+), 130 deletions(-) -- 2.4.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) pass -> DMESG-WARN (bdw-ultra) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:1 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1186/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add onoff utility function
On Thu, 14 Jan 2016, Ville Syrjälä wrote:
> On Thu, Jan 14, 2016 at 12:53:34PM +0200, Jani Nikula wrote:
>> Add a common function to return "on" or "off" string based on the
>> argument, and drop the local versions of it.
>>
>> This is the onoff version of
>>
>> commit 42a8ca4cb4a48ddbf40e8edb291425e76bcdc230
>> Author: Jani Nikula
>> Date: Thu Aug 27 16:23:30 2015 +0300
>>
>> drm/i915: add yesno utility function
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Pushed to drm-intel-next-queued, thanks for the review.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
>> drivers/gpu/drm/i915/i915_drv.h | 5 +
>> drivers/gpu/drm/i915/intel_display.c | 30 --
>> drivers/gpu/drm/i915/intel_dp.c | 9 ++---
>> drivers/gpu/drm/i915/intel_pm.c | 11 +--
>> 5 files changed, 27 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index f17a2b0c2493..975af3568521 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -1335,8 +1335,8 @@ static int vlv_wait_for_gt_wells(struct
>> drm_i915_private *dev_priv,
>> return 0;
>>
>> DRM_DEBUG_KMS("waiting for GT wells to go %s (%08x)\n",
>> -wait_for_on ? "on" : "off",
>> -I915_READ(VLV_GTLC_PW_STATUS));
>> + onoff(wait_for_on),
>> + I915_READ(VLV_GTLC_PW_STATUS));
>>
>> /*
>> * RC6 transitioning can be delayed up to 2 msec (see
>> @@ -1345,7 +1345,7 @@ static int vlv_wait_for_gt_wells(struct
>> drm_i915_private *dev_priv,
>> err = wait_for(COND, 3);
>> if (err)
>> DRM_ERROR("timeout waiting for GT wells to go %s\n",
>> - wait_for_on ? "on" : "off");
>> + onoff(wait_for_on));
>>
>> return err;
>> #undef COND
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 104bd1809936..eb7bb97f7316 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -102,6 +102,11 @@ static inline const char *yesno(bool v)
>> return v ? "yes" : "no";
>> }
>>
>> +static inline const char *onoff(bool v)
>> +{
>> +return v ? "on" : "off";
>> +}
>> +
>> enum pipe {
>> INVALID_PIPE = -1,
>> PIPE_A = 0,
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index a087892dd797..0f52f71402a0 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -1150,11 +1150,6 @@ static void intel_wait_for_pipe_off(struct intel_crtc
>> *crtc)
>> }
>> }
>>
>> -static const char *state_string(bool enabled)
>> -{
>> -return enabled ? "on" : "off";
>> -}
>> -
>> /* Only for pre-ILK configs */
>> void assert_pll(struct drm_i915_private *dev_priv,
>> enum pipe pipe, bool state)
>> @@ -1166,7 +1161,7 @@ void assert_pll(struct drm_i915_private *dev_priv,
>> cur_state = !!(val & DPLL_VCO_ENABLE);
>> I915_STATE_WARN(cur_state != state,
>> "PLL state assertion failure (expected %s, current %s)\n",
>> - state_string(state), state_string(cur_state));
>> +onoff(state), onoff(cur_state));
>> }
>>
>> /* XXX: the dsi pll is shared between MIPI DSI ports */
>> @@ -1182,7 +1177,7 @@ static void assert_dsi_pll(struct drm_i915_private
>> *dev_priv, bool state)
>> cur_state = val & DSI_PLL_VCO_EN;
>> I915_STATE_WARN(cur_state != state,
>> "DSI PLL state assertion failure (expected %s, current %s)\n",
>> - state_string(state), state_string(cur_state));
>> +onoff(state), onoff(cur_state));
>> }
>> #define assert_dsi_pll_enabled(d) assert_dsi_pll(d, true)
>> #define assert_dsi_pll_disabled(d) assert_dsi_pll(d, false)
>> @@ -1206,14 +1201,13 @@ void assert_shared_dpll(struct drm_i915_private
>> *dev_priv,
>> bool cur_state;
>> struct intel_dpll_hw_state hw_state;
>>
>> -if (WARN (!pll,
>> - "asserting DPLL %s with no DPLL\n", state_string(state)))
>> +if (WARN(!pll, "asserting DPLL %s with no DPLL\n", onoff(state)))
>> return;
>>
>> cur_state = pll->get_hw_state(dev_priv, pll, &hw_state);
>> I915_STATE_WARN(cur_state != state,
>> "%s assertion failure (expected %s, current %s)\n",
>> - pll->name, state_string(state), state_string(cur_state));
>> +pll->name, onoff(state), onoff(cur_state));
>> }
>>
>> static void assert_fdi_tx(struct drm_i915_private *dev_priv,
>> @@ -1233,7 +1227,7 @@ static void assert_fdi_tx(struct drm_i915_private
>> *dev_priv,
>> }
>> I915_STATE_WARN(cur_state != state,
>> "FDI TX state assertion failure (expected %s, current %s)\n",
>> - state_string(state), state_string(cur_
Re: [Intel-gfx] [PATCH 5/6] drm/i915: read sink_count dpcd always
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
> This patch reads sink_count dpcd always and removes its
> read operation based on values in downstream port dpcd.
>
> SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
> SINK_COUNT denotes if a display is attached, while
> DOWNSTREAM_PORT_PRESET indicates how many ports are available
> in the dongle where display can be attached. so it is possible
> for sink count to change irrespective of value in downstream
> port dpcd.
>
> Here is a table of possible values and scenarios
>
> sink_count downstream_port
> present
> 0 0 no display is attached
> 0 1 dongle is connected without display
> 1 0 display connected directly
> 1 1 display connected through dongle
>
> Tested-by: Nathan D Ciobanu
> Signed-off-by: Sivakumar Thulasimani
> Signed-off-by: Shubhangi Shrivastava
> ---
> drivers/gpu/drm/i915/intel_dp.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c2e8516..0d58bfd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3865,6 +3865,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> if (intel_dp->dpcd[DP_DPCD_REV] == 0)
> return false; /* DPCD not present */
>
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> + &intel_dp->sink_count, 1) < 0)
> + return false;
> +
> + if (!DP_GET_SINK_COUNT(intel_dp->sink_count))
> + return false;
> +
My understanding is that this function should only read the DPCD data while
detection based on that data is done in intel_dp_detect_dpcd(). With the return
on sink_count == 0 here, we skip the end of the function, which updates the
cached downstream port information. Is there a reason why we need this early
return here?
Also, I think this could be squashed with the previous patch.
Ander
> /* Check if the panel supports PSR */
> memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
> if (is_edp(intel_dp)) {
> @@ -4386,10 +4393,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
>
> - if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> - &intel_dp->sink_count, 1) < 0)
> - return connector_status_unknown;
> -
> return DP_GET_SINK_COUNT(intel_dp->sink_count) ?
> connector_status_connected : connector_status_disconnected;
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Save sink_count for tracking changes to it
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
> Sink count can change between short pulse hpd hence this patch
> adds a member variable to intel_dp so we can track any changes
> between short pulse interrupts.
>
> Tested-by: Nathan D Ciobanu
> Signed-off-by: Sivakumar Thulasimani
> Signed-off-by: Shubhangi Shrivastava
> ---
> drivers/gpu/drm/i915/intel_dp.c | 7 +++
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 842790e..c2e8516 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4385,14 +4385,13 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> /* If we're HPD-aware, SINK_COUNT changes dynamically */
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
> - uint8_t reg;
>
> if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> - ®, 1) < 0)
> + &intel_dp->sink_count, 1) < 0)
> return connector_status_unknown;
>
> - return DP_GET_SINK_COUNT(reg) ? connector_status_connected
> - :
> connector_status_disconnected;
> + return DP_GET_SINK_COUNT(intel_dp->sink_count) ?
> + connector_status_connected : connector_status_disconnected;
I think it would be better to have the value of intel_dp->sink_count ready for
consumption, i.e., store the result of DP_GET_SINK_COUNT().
Ander
> }
>
> /* If no HPD, poke DDC gently */
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0438b57..88b05ba 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -757,6 +757,7 @@ struct intel_dp {
> uint32_t DP;
> int link_rate;
> uint8_t lane_count;
> + uint8_t sink_count;
> bool has_audio;
> enum hdmi_force_audio force_audio;
> bool limited_color_range;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add onoff utility function
On Thu, Jan 14, 2016 at 12:53:34PM +0200, Jani Nikula wrote:
> Add a common function to return "on" or "off" string based on the
> argument, and drop the local versions of it.
>
> This is the onoff version of
>
> commit 42a8ca4cb4a48ddbf40e8edb291425e76bcdc230
> Author: Jani Nikula
> Date: Thu Aug 27 16:23:30 2015 +0300
>
> drm/i915: add yesno utility function
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/intel_display.c | 30 --
> drivers/gpu/drm/i915/intel_dp.c | 9 ++---
> drivers/gpu/drm/i915/intel_pm.c | 11 +--
> 5 files changed, 27 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f17a2b0c2493..975af3568521 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1335,8 +1335,8 @@ static int vlv_wait_for_gt_wells(struct
> drm_i915_private *dev_priv,
> return 0;
>
> DRM_DEBUG_KMS("waiting for GT wells to go %s (%08x)\n",
> - wait_for_on ? "on" : "off",
> - I915_READ(VLV_GTLC_PW_STATUS));
> + onoff(wait_for_on),
> + I915_READ(VLV_GTLC_PW_STATUS));
>
> /*
>* RC6 transitioning can be delayed up to 2 msec (see
> @@ -1345,7 +1345,7 @@ static int vlv_wait_for_gt_wells(struct
> drm_i915_private *dev_priv,
> err = wait_for(COND, 3);
> if (err)
> DRM_ERROR("timeout waiting for GT wells to go %s\n",
> - wait_for_on ? "on" : "off");
> + onoff(wait_for_on));
>
> return err;
> #undef COND
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 104bd1809936..eb7bb97f7316 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -102,6 +102,11 @@ static inline const char *yesno(bool v)
> return v ? "yes" : "no";
> }
>
> +static inline const char *onoff(bool v)
> +{
> + return v ? "on" : "off";
> +}
> +
> enum pipe {
> INVALID_PIPE = -1,
> PIPE_A = 0,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a087892dd797..0f52f71402a0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1150,11 +1150,6 @@ static void intel_wait_for_pipe_off(struct intel_crtc
> *crtc)
> }
> }
>
> -static const char *state_string(bool enabled)
> -{
> - return enabled ? "on" : "off";
> -}
> -
> /* Only for pre-ILK configs */
> void assert_pll(struct drm_i915_private *dev_priv,
> enum pipe pipe, bool state)
> @@ -1166,7 +1161,7 @@ void assert_pll(struct drm_i915_private *dev_priv,
> cur_state = !!(val & DPLL_VCO_ENABLE);
> I915_STATE_WARN(cur_state != state,
>"PLL state assertion failure (expected %s, current %s)\n",
> - state_string(state), state_string(cur_state));
> + onoff(state), onoff(cur_state));
> }
>
> /* XXX: the dsi pll is shared between MIPI DSI ports */
> @@ -1182,7 +1177,7 @@ static void assert_dsi_pll(struct drm_i915_private
> *dev_priv, bool state)
> cur_state = val & DSI_PLL_VCO_EN;
> I915_STATE_WARN(cur_state != state,
>"DSI PLL state assertion failure (expected %s, current %s)\n",
> - state_string(state), state_string(cur_state));
> + onoff(state), onoff(cur_state));
> }
> #define assert_dsi_pll_enabled(d) assert_dsi_pll(d, true)
> #define assert_dsi_pll_disabled(d) assert_dsi_pll(d, false)
> @@ -1206,14 +1201,13 @@ void assert_shared_dpll(struct drm_i915_private
> *dev_priv,
> bool cur_state;
> struct intel_dpll_hw_state hw_state;
>
> - if (WARN (!pll,
> - "asserting DPLL %s with no DPLL\n", state_string(state)))
> + if (WARN(!pll, "asserting DPLL %s with no DPLL\n", onoff(state)))
> return;
>
> cur_state = pll->get_hw_state(dev_priv, pll, &hw_state);
> I915_STATE_WARN(cur_state != state,
>"%s assertion failure (expected %s, current %s)\n",
> - pll->name, state_string(state), state_string(cur_state));
> + pll->name, onoff(state), onoff(cur_state));
> }
>
> static void assert_fdi_tx(struct drm_i915_private *dev_priv,
> @@ -1233,7 +1227,7 @@ static void assert_fdi_tx(struct drm_i915_private
> *dev_priv,
> }
> I915_STATE_WARN(cur_state != state,
>"FDI TX state assertion failure (expected %s, current %s)\n",
> - state_string(state), state_string(cur_state));
> + onoff(state), onoff(cur_state));
> }
> #define assert_fdi_tx_enabled(d, p) assert_fdi_tx(d, p, true)
> #define assert_fdi_tx_disabled(d, p) assert_fdi_tx(d, p, false)
>
[Intel-gfx] [PATCH 2/2] drm/i915: Use the active wm config for merging on ILK-BDW
From: Ville Syrjälä
ilk_program_watermarks() is supposed to merge the active watermarks from
all pipes. Thus we need to use the active config too instead of some
precomputed stuff.
Fixes: aa363136866c ("drm/i915: Calculate watermark configuration during atomic
check (v2)")
Cc: Matt Roper
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e9f4e6e7b736..f44a961183d7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3680,23 +3680,43 @@ static void skl_update_wm(struct drm_crtc *crtc)
dev_priv->wm.skl_hw = *results;
}
+static void ilk_compute_wm_config(struct drm_device *dev,
+ struct intel_wm_config *config)
+{
+ struct intel_crtc *crtc;
+
+ /* Compute the currently _active_ config */
+ for_each_intel_crtc(dev, crtc) {
+ const struct intel_pipe_wm *wm = &crtc->wm.active.ilk;
+
+ if (!wm->pipe_enabled)
+ continue;
+
+ config->sprites_enabled |= wm->sprites_enabled;
+ config->sprites_scaled |= wm->sprites_scaled;
+ config->num_pipes_active++;
+ }
+}
+
static void ilk_program_watermarks(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = dev_priv->dev;
struct intel_pipe_wm lp_wm_1_2 = {}, lp_wm_5_6 = {}, *best_lp_wm;
struct ilk_wm_maximums max;
- struct intel_wm_config *config = &dev_priv->wm.config;
+ struct intel_wm_config config = {};
struct ilk_wm_values results = {};
enum intel_ddb_partitioning partitioning;
- ilk_compute_wm_maximums(dev, 1, config, INTEL_DDB_PART_1_2, &max);
- ilk_wm_merge(dev, config, &max, &lp_wm_1_2);
+ ilk_compute_wm_config(dev, &config);
+
+ ilk_compute_wm_maximums(dev, 1, &config, INTEL_DDB_PART_1_2, &max);
+ ilk_wm_merge(dev, &config, &max, &lp_wm_1_2);
/* 5/6 split only in single pipe config on IVB+ */
if (INTEL_INFO(dev)->gen >= 7 &&
- config->num_pipes_active == 1 && config->sprites_enabled) {
- ilk_compute_wm_maximums(dev, 1, config, INTEL_DDB_PART_5_6,
&max);
- ilk_wm_merge(dev, config, &max, &lp_wm_5_6);
+ config.num_pipes_active == 1 && config.sprites_enabled) {
+ ilk_compute_wm_maximums(dev, 1, &config, INTEL_DDB_PART_5_6,
&max);
+ ilk_wm_merge(dev, &config, &max, &lp_wm_5_6);
best_lp_wm = ilk_find_best_result(dev, &lp_wm_1_2, &lp_wm_5_6);
} else {
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Start WM computation from scratch on ILK-BDW
From: Ville Syrjälä
ilk_compute_pipe_wm() assumes as zeroed pipe_wm structure when it
starts. We used to pass such a zeroed struct in, but this got broken
when the pipe_wm structure got embedded in the crtc state.
To fix it without too much fuzz, we need to resort to a memset().
Fixes: 4e0963c7663b ("drm/i915: Calculate pipe watermarks into CRTC state (v3)")
Cc: Matt Roper
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9df9e9a22f3c..e9f4e6e7b736 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2317,6 +2317,7 @@ static int ilk_compute_pipe_wm(struct intel_crtc
*intel_crtc,
return PTR_ERR(cstate);
pipe_wm = &cstate->wm.optimal.ilk;
+ memset(pipe_wm, 0, sizeof(*pipe_wm));
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
ps = drm_atomic_get_plane_state(state,
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915: move VBT based DSI presence check to intel_bios.c
On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_bios.c | 33 -
> drivers/gpu/drm/i915/intel_dsi.c | 23 ++-
> 3 files changed, 47 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6ae828f984de..f8516f564d0a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1474,7 +1474,6 @@ struct intel_vbt_data {
>
> /* MIPI DSI */
> struct {
> - u16 port;
> u16 panel_id;
> struct mipi_config *config;
> struct mipi_pps_data *pps;
> @@ -3350,6 +3349,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t
> size);
> bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
> bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin);
> bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> port);
> +bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
> *port);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index a7491a450cc8..94c2baa50db7 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1221,7 +1221,6 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
> &&p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT) {
> DRM_DEBUG_KMS("Found MIPI as LFP\n");
> dev_priv->vbt.has_mipi = 1;
> - dev_priv->vbt.dsi.port = p_child->common.dvo_port;
> }
>
> child_dev_ptr = dev_priv->vbt.child_dev + count;
> @@ -1536,3 +1535,35 @@ bool intel_bios_is_port_edp(struct drm_i915_private
> *dev_priv, enum port port)
>
> return false;
> }
> +
> +/**
> + * intel_bios_is_dsi_present - is DSI present in VBT
> + * @dev_priv:i915 device instance
> + * @port:port for DSI if present
> + *
> + * Return true if DSI is present, and return the port in %port.
> + */
> +bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv,
> +enum port *port)
> +{
> + union child_device_config *p_child;
> + int i;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = dev_priv->vbt.child_dev + i;
> +
> + if (!(p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT))
> + continue;
> +
> + switch (p_child->common.dvo_port) {
> + case DVO_PORT_MIPIA:
> + case DVO_PORT_MIPIB:
> + case DVO_PORT_MIPIC:
> + case DVO_PORT_MIPID:
> + *port = p_child->common.dvo_port - DVO_PORT_MIPIA;
> + return true;
> + }
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 91cef3525c93..33f219cfba43 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1112,9 +1112,15 @@ void intel_dsi_init(struct drm_device *dev)
> DRM_DEBUG_KMS("\n");
>
> /* There is no detection method for MIPI so rely on VBT */
> - if (!dev_priv->vbt.has_mipi)
> + if (!intel_bios_is_dsi_present(dev_priv, &port))
> return;
>
> + if (port != PORT_A && port != PORT_C) {
> + DRM_DEBUG_KMS("VBT has unsupported DSI port %c\n",
> + port_name(port));
> + return;
> + }
> +
> if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
> dev_priv->mipi_mmio_base = VLV_MIPI_BASE;
> } else {
> @@ -1153,16 +1159,15 @@ void intel_dsi_init(struct drm_device *dev)
> intel_connector->unregister = intel_connector_unregister;
>
> /* Pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI port C */
> - if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIA) {
> - intel_encoder->crtc_mask = (1 << PIPE_A);
> - intel_dsi->ports = (1 << PORT_A);
> - } else if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIC) {
> - intel_encoder->crtc_mask = (1 << PIPE_B);
> - intel_dsi->ports = (1 << PORT_C);
> - }
> + if (port == PORT_A)
> + intel_encoder->crtc_mask = 1 << PIPE_A;
> + else
> + intel_encoder->crtc_mask = 1 << PIPE_B;
>
> if (dev_priv->vbt.dsi.config->dual_link)
> - intel_dsi->ports = ((1 << PORT_A) | (1 << PORT_C));
> + intel_dsi->ports = (1 << PORT_A) | (1 << PORT_C);
> + else
> + intel_dsi->ports = 1 << port;
>
> /* Create a DSI host (and a device) for each port. */
>
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: move VBT based eDP port check to intel_bios.c
On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 33 +
> drivers/gpu/drm/i915/intel_dp.c | 21 +
> 3 files changed, 35 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5f0d44b380aa..6ae828f984de 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3349,6 +3349,7 @@ int intel_bios_init(struct drm_i915_private *dev_priv);
> bool intel_bios_is_valid_vbt(const void *buf, size_t size);
> bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
> bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin);
> +bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> port);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 099f3f0002a2..a7491a450cc8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1503,3 +1503,36 @@ bool intel_bios_is_lvds_present(struct
> drm_i915_private *dev_priv, u8 *i2c_pin)
>
> return false;
> }
> +
> +/**
> + * intel_bios_is_port_edp - is the device in given port eDP
> + * @dev_priv:i915 device instance
> + * @port:port to check
> + *
> + * Return true if the device in %port is eDP.
> + */
> +bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> port)
> +{
> + union child_device_config *p_child;
> + static const short port_mapping[] = {
> + [PORT_B] = DVO_PORT_DPB,
> + [PORT_C] = DVO_PORT_DPC,
> + [PORT_D] = DVO_PORT_DPD,
> + [PORT_E] = DVO_PORT_DPE,
> + };
> + int i;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = dev_priv->vbt.child_dev + i;
> +
> + if (p_child->common.dvo_port == port_mapping[port] &&
> + (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
> + (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
> + return true;
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 796e3d313cb9..02cb4e9bf5ea 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5068,14 +5068,6 @@ put_power:
> bool intel_dp_is_edp(struct drm_device *dev, enum port port)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - union child_device_config *p_child;
> - int i;
> - static const short port_mapping[] = {
> - [PORT_B] = DVO_PORT_DPB,
> - [PORT_C] = DVO_PORT_DPC,
> - [PORT_D] = DVO_PORT_DPD,
> - [PORT_E] = DVO_PORT_DPE,
> - };
>
> /*
>* eDP not supported on g4x. so bail out early just
> @@ -5087,18 +5079,7 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port
> port)
> if (port == PORT_A)
> return true;
>
> - if (!dev_priv->vbt.child_dev_num)
> - return false;
> -
> - for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> - p_child = dev_priv->vbt.child_dev + i;
> -
> - if (p_child->common.dvo_port == port_mapping[port] &&
> - (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
> - (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
> - return true;
> - }
> - return false;
> + return intel_bios_is_port_edp(dev_priv, port);
> }
>
> void
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: hide away VBT private data in a separate header
On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> We've been accumulating code across the driver that depends on the VBT
> specific structures and defines. The VBT is an uncontrollable
> beast. Encourage encapsulation of the VBT data by hiding the structures
> and defines in a private header only to be included from intel_bios.c.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> Documentation/DocBook/gpu.tmpl| 2 +-
> drivers/gpu/drm/i915/intel_bios.c | 2 +-
> drivers/gpu/drm/i915/intel_bios.h | 860
> ++
> drivers/gpu/drm/i915/intel_bios_private.h | 823
> 4 files changed, 859 insertions(+), 828 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_bios_private.h
>
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 351e801cead9..4ba7c6f8e8b1 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -3323,7 +3323,7 @@ int num_ioctls;
> Video BIOS Table (VBT)
> !Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT)
> !Idrivers/gpu/drm/i915/intel_bios.c
> -!Idrivers/gpu/drm/i915/intel_bios.h
> +!Idrivers/gpu/drm/i915/intel_bios_private.h
>
>
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 94c2baa50db7..83b78e0df306 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -29,7 +29,7 @@
> #include
> #include
> #include "i915_drv.h"
> -#include "intel_bios.h"
> +#include "intel_bios_private.h"
>
> /**
> * DOC: Video BIOS Table (VBT)
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index 350d4e0f75a4..536d90f0c3eb 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -1,5 +1,5 @@
> /*
> - * Copyright © 2006 Intel Corporation
> + * Copyright © 2016 Intel Corporation
> *
> * Permission is hereby granted, free of charge, to any person obtaining a
> * copy of this software and associated documentation files (the "Software"),
> @@ -19,543 +19,15 @@
> * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE
> * SOFTWARE.
> - *
> - * Authors:
> - *Eric Anholt
> - *
> - */
> -
> -#ifndef _INTEL_BIOS_H_
> -#define _INTEL_BIOS_H_
> -
> -/**
> - * struct vbt_header - VBT Header structure
> - * @signature: VBT signature, always starts with "$VBT"
> - * @version: Version of this structure
> - * @header_size: Size of this structure
> - * @vbt_size:Size of VBT (VBT Header, BDB Header and data
> blocks)
> - * @vbt_checksum:Checksum
> - * @reserved0: Reserved
> - * @bdb_offset: Offset of &struct bdb_header from beginning of
> VBT
> - * @aim_offset: Offsets of add-in data blocks from beginning of
> VBT
> - */
> -struct vbt_header {
> - u8 signature[20];
> - u16 version;
> - u16 header_size;
> - u16 vbt_size;
> - u8 vbt_checksum;
> - u8 reserved0;
> - u32 bdb_offset;
> - u32 aim_offset[4];
> -} __packed;
> -
> -/**
> - * struct bdb_header - BDB Header structure
> - * @signature: BDB signature "BIOS_DATA_BLOCK"
> - * @version: Version of the data block definitions
> - * @header_size: Size of this structure
> - * @bdb_size:Size of BDB (BDB Header and data blocks)
> - */
> -struct bdb_header {
> - u8 signature[16];
> - u16 version;
> - u16 header_size;
> - u16 bdb_size;
> -} __packed;
> -
> -/* strictly speaking, this is a "skip" block, but it has interesting info */
> -struct vbios_data {
> - u8 type; /* 0 == desktop, 1 == mobile */
> - u8 relstage;
> - u8 chipset;
> - u8 lvds_present:1;
> - u8 tv_present:1;
> - u8 rsvd2:6; /* finish byte */
> - u8 rsvd3[4];
> - u8 signon[155];
> - u8 copyright[61];
> - u16 code_segment;
> - u8 dos_boot_mode;
> - u8 bandwidth_percent;
> - u8 rsvd4; /* popup memory size */
> - u8 resize_pci_bios;
> - u8 rsvd5; /* is crt already on ddc2 */
> -} __packed;
> -
> -/*
> - * There are several types of BIOS data blocks (BDBs), each block has
> - * an ID and size in the first 3 bytes (ID in first, size in next 2).
> - * Known types are listed below.
> */
> -#define BDB_GENERAL_FEATURES 1
> -#define BDB_GENERAL_DEFINITIONS2
> -#define BDB_OLD_TOGGLE_LIST3
> -#define BDB_MODE_SUPPORT_LIST 4
> -#define BDB_GENERIC_MODE_TABLE 5
> -#define BDB_EXT_MMIO_REGS 6
> -#define BDB_SWF_IO 7
> -#define BDB_SWF_MMIO 8
> -#define BDB_PSR9
> -#define BDB_MODE_REMOVAL_TABLE10
> -#define BDB_CHILD_DEVICE_TABLE11
> -#define BDB_DRIVER_FEATURES 12
> -#define BDB_DRIVER_PERSI
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: move VBT based LVDS presence check to intel_bios.c
On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 50
> drivers/gpu/drm/i915/intel_lvds.c | 53
> +--
> 3 files changed, 52 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3822c465d3dc..5f0d44b380aa 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3348,6 +3348,7 @@ extern void intel_i2c_reset(struct drm_device *dev);
> int intel_bios_init(struct drm_i915_private *dev_priv);
> bool intel_bios_is_valid_vbt(const void *buf, size_t size);
> bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
> +bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index bb9e8b086b63..099f3f0002a2 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1453,3 +1453,53 @@ bool intel_bios_is_tv_present(struct drm_i915_private
> *dev_priv)
>
> return false;
> }
> +
> +/**
> + * intel_bios_is_lvds_present - is LVDS present in VBT
> + * @dev_priv:i915 device instance
> + * @i2c_pin: i2c pin for LVDS if present
> + *
> + * Return true if LVDS is present. If no child devices were parsed from VBT,
> + * assume LVDS is present.
> + */
> +bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin)
> +{
> + int i;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return true;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + union child_device_config *uchild = dev_priv->vbt.child_dev + i;
> + struct old_child_dev_config *child = &uchild->old;
> +
> + /* If the device type is not LFP, continue.
> + * We have to check both the new identifiers as well as the
> + * old for compatibility with some BIOSes.
> + */
> + if (child->device_type != DEVICE_TYPE_INT_LFP &&
> + child->device_type != DEVICE_TYPE_LFP)
> + continue;
> +
> + if (intel_gmbus_is_valid_pin(dev_priv, child->i2c_pin))
> + *i2c_pin = child->i2c_pin;
> +
> + /* However, we cannot trust the BIOS writers to populate
> + * the VBT correctly. Since LVDS requires additional
> + * information from AIM blocks, a non-zero addin offset is
> + * a good indicator that the LVDS is actually present.
> + */
> + if (child->addin_offset)
> + return true;
> +
> + /* But even then some BIOS writers perform some black magic
> + * and instantiate the device without reference to any
> + * additional data. Trust that if the VBT was written into
> + * the OpRegion then they have validated the LVDS's existence.
> + */
> + if (dev_priv->opregion.vbt)
> + return true;
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index 0da0240caf81..80f8684e5137 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -772,57 +772,6 @@ static const struct dmi_system_id intel_no_lvds[] = {
> { } /* terminating entry */
> };
>
> -/*
> - * Enumerate the child dev array parsed from VBT to check whether
> - * the LVDS is present.
> - * If it is present, return 1.
> - * If it is not present, return false.
> - * If no child dev is parsed from VBT, it assumes that the LVDS is present.
> - */
> -static bool lvds_is_present_in_vbt(struct drm_device *dev,
> -u8 *i2c_pin)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - int i;
> -
> - if (!dev_priv->vbt.child_dev_num)
> - return true;
> -
> - for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> - union child_device_config *uchild = dev_priv->vbt.child_dev + i;
> - struct old_child_dev_config *child = &uchild->old;
> -
> - /* If the device type is not LFP, continue.
> - * We have to check both the new identifiers as well as the
> - * old for compatibility with some BIOSes.
> - */
> - if (child->device_type != DEVICE_TYPE_INT_LFP &&
> - child->device_type != DEVICE_TYPE_LFP)
> - continue;
> -
> - if (intel_gmbus_is_valid_pin(dev_priv, child->i2c_pin))
> - *i2c_pin = child->i2c_pin;
> -
>
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: move VBT based TV presence check to intel_bios.c
On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 38 ++
> drivers/gpu/drm/i915/intel_tv.c | 43
> +--
> 3 files changed, 40 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 104bd1809936..3822c465d3dc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3347,6 +3347,7 @@ extern void intel_i2c_reset(struct drm_device *dev);
> /* intel_bios.c */
> int intel_bios_init(struct drm_i915_private *dev_priv);
> bool intel_bios_is_valid_vbt(const void *buf, size_t size);
> +bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 15ba52bd2538..bb9e8b086b63 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1415,3 +1415,41 @@ intel_bios_init(struct drm_i915_private *dev_priv)
>
> return 0;
> }
> +
> +/**
> + * intel_bios_is_tv_present - is integrated TV present in VBT
> + * @dev_priv:i915 device instance
> + *
> + * Return true if TV is present. If no child devices were parsed from VBT,
> + * assume TV is present.
> + */
> +bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv)
> +{
> + union child_device_config *p_child;
> + int i;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return true;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = dev_priv->vbt.child_dev + i;
> + /*
> + * If the device type is not TV, continue.
> + */
> + switch (p_child->old.device_type) {
> + case DEVICE_TYPE_INT_TV:
> + case DEVICE_TYPE_TV:
> + case DEVICE_TYPE_TV_SVIDEO_COMPOSITE:
> + break;
> + default:
> + continue;
> + }
> + /* Only when the addin_offset is non-zero, it is regarded
> + * as present.
> + */
> + if (p_child->old.addin_offset)
> + return true;
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 948cbff6c62e..29e68859b9b7 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1529,47 +1529,6 @@ static const struct drm_encoder_funcs
> intel_tv_enc_funcs = {
> .destroy = intel_encoder_destroy,
> };
>
> -/*
> - * Enumerate the child dev array parsed from VBT to check whether
> - * the integrated TV is present.
> - * If it is present, return 1.
> - * If it is not present, return false.
> - * If no child dev is parsed from VBT, it assumes that the TV is present.
> - */
> -static int tv_is_present_in_vbt(struct drm_device *dev)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - union child_device_config *p_child;
> - int i, ret;
> -
> - if (!dev_priv->vbt.child_dev_num)
> - return 1;
> -
> - ret = 0;
> - for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> - p_child = dev_priv->vbt.child_dev + i;
> - /*
> - * If the device type is not TV, continue.
> - */
> - switch (p_child->old.device_type) {
> - case DEVICE_TYPE_INT_TV:
> - case DEVICE_TYPE_TV:
> - case DEVICE_TYPE_TV_SVIDEO_COMPOSITE:
> - break;
> - default:
> - continue;
> - }
> - /* Only when the addin_offset is non-zero, it is regarded
> - * as present.
> - */
> - if (p_child->old.addin_offset) {
> - ret = 1;
> - break;
> - }
> - }
> - return ret;
> -}
> -
> void
> intel_tv_init(struct drm_device *dev)
> {
> @@ -1585,7 +1544,7 @@ intel_tv_init(struct drm_device *dev)
> if ((I915_READ(TV_CTL) & TV_FUSE_STATE_MASK) == TV_FUSE_STATE_DISABLED)
> return;
>
> - if (!tv_is_present_in_vbt(dev)) {
> + if (!intel_bios_is_tv_present(dev_priv)) {
> DRM_DEBUG_KMS("Integrated TV is not present.\n");
> return;
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ success: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest bdw-nuci7total:138 pass:128 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:132 dwarn:0 dfail:0 fail:0 skip:6 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 Results at /archive/results/CI_IGT_test/Patchwork_1185/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback
On 14/01/2016 12:31, Chris Wilson wrote:
On Thu, Jan 14, 2016 at 11:56:07AM +, Nick Hoath wrote:
On 14/01/2016 11:36, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 04:19:45PM +, Nick Hoath wrote:
+ if (ctx->engine[ring->id].dirty) {
+ struct drm_i915_gem_request *req = NULL;
+
+ /**
+* If there is already a request pending on
+* this ring, wait for that to complete,
+* otherwise create a switch to idle request
+*/
+ if (list_empty(&ring->request_list)) {
+ int ret;
+
+ ret = i915_gem_request_alloc(
+ ring,
+ ring->default_context,
+ &req);
+ if (!ret)
+ i915_add_request(req);
+ else
+ DRM_DEBUG("Failed to ensure context saved");
+ } else {
+ req = list_first_entry(
+ &ring->request_list,
+ typeof(*req), list);
+ }
+ if (req) {
+ ret = i915_wait_request(req);
+ if (ret != 0) {
+ /**
+* If we get here, there's probably been a ring
+* reset, so we just clean up the dirty flag.&
+* pin count.
+*/
+ ctx->engine[ring->id].dirty = false;
+ __intel_lr_context_unpin(
+ ring,
+ ctx);
+ }
+ }
If you were to take a lr_context_pin on the last_context, and only
release that pin when you change to a new context, you do not need to
That what this patch does.
introduce a blocking context-close, nor do you need to introduce the
usage of default_context.
The use of default_context here is to stop a context hanging around
after it is no longer needed.
By blocking, which is not acceptable. Also we can eliminate the
default_context and so pinning that opposed to the last_context serves
no purpose other than by chance having a more preferrable position when
it comes to defragmentation. But you don't enable that anyway and we
Enabling the shrinker on execlists is something I'm working on which is
predicated on this patch. Also why is blocking on closing a context not
acceptable?
have alternative strategies now that avoid the issue with fragmentation
of the mappable aperture.
(lr_context_pin should take a reference on the ctx to prevent early
freeeing ofc).
You can't clear the reference on the ctx in an interrupt context.
The execlists submission should moved out of the interrupt context, for
the very simple reason that it is causing machine panics. userspace
submits a workload, machine lockups
Create a jira, and I'm sure we'll look at making that change.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback
On Thu, Jan 14, 2016 at 11:56:07AM +, Nick Hoath wrote:
> On 14/01/2016 11:36, Chris Wilson wrote:
> >On Wed, Jan 13, 2016 at 04:19:45PM +, Nick Hoath wrote:
> >>+ if (ctx->engine[ring->id].dirty) {
> >>+ struct drm_i915_gem_request *req = NULL;
> >>+
> >>+ /**
> >>+* If there is already a request pending on
> >>+* this ring, wait for that to complete,
> >>+* otherwise create a switch to idle request
> >>+*/
> >>+ if (list_empty(&ring->request_list)) {
> >>+ int ret;
> >>+
> >>+ ret = i915_gem_request_alloc(
> >>+ ring,
> >>+ ring->default_context,
> >>+ &req);
> >>+ if (!ret)
> >>+ i915_add_request(req);
> >>+ else
> >>+ DRM_DEBUG("Failed to ensure context saved");
> >>+ } else {
> >>+ req = list_first_entry(
> >>+ &ring->request_list,
> >>+ typeof(*req), list);
> >>+ }
> >>+ if (req) {
> >>+ ret = i915_wait_request(req);
> >>+ if (ret != 0) {
> >>+ /**
> >>+* If we get here, there's probably been a ring
> >>+* reset, so we just clean up the dirty flag.&
> >>+* pin count.
> >>+*/
> >>+ ctx->engine[ring->id].dirty = false;
> >>+ __intel_lr_context_unpin(
> >>+ ring,
> >>+ ctx);
> >>+ }
> >>+ }
> >
> >If you were to take a lr_context_pin on the last_context, and only
> >release that pin when you change to a new context, you do not need to
>
> That what this patch does.
>
> >introduce a blocking context-close, nor do you need to introduce the
> >usage of default_context.
>
> The use of default_context here is to stop a context hanging around
> after it is no longer needed.
By blocking, which is not acceptable. Also we can eliminate the
default_context and so pinning that opposed to the last_context serves
no purpose other than by chance having a more preferrable position when
it comes to defragmentation. But you don't enable that anyway and we
have alternative strategies now that avoid the issue with fragmentation
of the mappable aperture.
> >(lr_context_pin should take a reference on the ctx to prevent early
> >freeeing ofc).
>
> You can't clear the reference on the ctx in an interrupt context.
The execlists submission should moved out of the interrupt context, for
the very simple reason that it is causing machine panics. userspace
submits a workload, machine lockups
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) bdw-nuci7total:138 pass:128 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:0 dfail:0 fail:1 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1184/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 6/9] drm/i915: Add sync framework support to execbuff IOCTL
On Thu, Jan 14, 2016 at 11:47:17AM +, John Harrison wrote: > On 13/01/2016 18:43, Chris Wilson wrote: > >Use the upper s32 for the output, so again you are not overwriting user > >state without good reason. > > > Makes sense. Will do. It would also be useful (for nefarious reasons) to only copy back the rsvd2 field, i.e. keep it as DRM_IOW(EXECBUFFER2) and do the small fixed-sized copy_to_user of rsvd2 as required. That means we can avoid the copy mostly, and treat args as a private copy of the user parameters, i.e. space we can scribble over with impunity. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915/skl+: Use scaling amount for plane data rate calculation
From: "Kumar, Mahesh"
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_pm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ffcc56a..dc08494 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2978,6 +2978,8 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
struct drm_framebuffer *fb = pstate->fb;
+ struct intel_plane *intel_plane = to_intel_plane(pstate->plane);
+ uint32_t down_scale_amount, data_rate;
uint32_t width = 0, height = 0;
if (drm_rect_width(&intel_pstate->src)) {
@@ -2994,15 +2996,19 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
/* for planar format */
if (fb->pixel_format == DRM_FORMAT_NV12) {
if (y) /* y-plane data rate */
- return width * height *
+ data_rate = width * height *
drm_format_plane_cpp(fb->pixel_format, 0);
else/* uv-plane data rate */
- return (width / 2) * (height / 2) *
+ data_rate = (width / 2) * (height / 2) *
drm_format_plane_cpp(fb->pixel_format, 1);
}
/* for packed formats */
- return width * height * drm_format_plane_cpp(fb->pixel_format, 0);
+ data_rate = width * height * drm_format_plane_cpp(fb->pixel_format, 0);
+ down_scale_amount = skl_plane_downscale_amount(intel_plane);
+
+ return DIV_ROUND_UP((data_rate * down_scale_amount), 1000);
+
}
/*
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW
From: "Kumar, Mahesh"
If the arbitary display bandwidth is > 60% of memory bandwith, for
x-tile we should increase latency at all levels by 15us.
If the arbitary dsplay bandwidth is greater than 20% of memory bandwith
in case of y-tile being enabled, double the scan lines
v2: Update the commit message to explain the WA (shobhit)
Signed-off-by: Shobhit Kumar
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/i915_drv.h | 9 +
drivers/gpu/drm/i915/intel_pm.c | 86 +
2 files changed, 95 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f588993..3c914a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1620,6 +1620,12 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_MAX,
};
+enum watermark_memory_wa {
+ WATERMARK_WA_NONE,
+ WATERMARK_WA_X_TILED,
+ WATERMARK_WA_Y_TILED,
+};
+
struct intel_pipe_crc_entry {
uint32_t frame;
uint32_t crc[5];
@@ -1915,6 +1921,9 @@ struct drm_i915_private {
/* Committed wm config */
struct intel_wm_config config;
+ /* This stores if WaterMark memory workaround is needed */
+ enum watermark_memory_wa mem_wa;
+
/*
* The skl_wm_values structure is a bit too big for stack
* allocation, so we keep the staging struct where we store
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index dc08494..fb59f4e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3304,6 +3304,11 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
if (latency == 0 || !cstate->base.active || !fb)
return false;
+ if (dev_priv->wm.mem_wa != WATERMARK_WA_NONE) {
+ if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
+ latency += 15;
+ }
+
if (drm_rect_width(&intel_pstate->src)) {
width = drm_rect_width(&intel_pstate->src) >> 16;
height = drm_rect_height(&intel_pstate->src) >> 16;
@@ -3352,6 +3357,9 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
WARN(1, "Unsupported pixel depth for rotation");
}
}
+ if (dev_priv->wm.mem_wa == WATERMARK_WA_Y_TILED)
+ min_scanlines *= 2;
+
y_tile_minimum = plane_blocks_per_line * min_scanlines;
selected_result = max(method2, y_tile_minimum);
} else {
@@ -3803,6 +3811,83 @@ static void skl_set_plane_pixel_rate(struct drm_crtc
*crtc)
}
+static void
+skl_set_display_memory_wa(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = NULL;
+ struct intel_plane *intel_plane = NULL;
+ uint32_t num_active_crtc = 0;
+ uint64_t max_pixel_rate_pipe = 0;
+ uint64_t display_bw = 0, available_bw = 0;
+ bool y_tile_enabled = false;
+ int memory_portion = 0;
+
+ for_each_intel_crtc(dev, intel_crtc) {
+ uint64_t max_pixel_rate_plane = 0;
+ uint64_t pipe_bw;
+ uint32_t num_active_plane = 0;
+ const struct intel_crtc_state *cstate = NULL;
+
+ if (!intel_crtc->active)
+ continue;
+ cstate = to_intel_crtc_state(intel_crtc->base.state);
+ num_active_crtc++;
+
+ for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
+ struct drm_plane *plane = &intel_plane->base;
+ struct drm_framebuffer *fb = plane->state->fb;
+ uint64_t plane_bw, interm_bw = 1000;
+
+ if (fb == NULL)
+ continue;
+ if (plane->type == DRM_PLANE_TYPE_CURSOR)
+ continue;
+ num_active_plane++;
+
+ if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED)
+ y_tile_enabled = true;
+
+ /*
+* planeBW = pixel_rate(MHz) * BPP * plane downscale
+* amount * pipe downscale amount;
+*
+* skl_pipe_pixel_rate return adjusted value according
+* to downscaling amount
+* pixel rate is in KHz & downscale factor is multiplied
+* by 1000, so devide by 1000*1000
+*/
+ interm_bw = skl_pipe_pixel_rate(cstate) *
+ drm_format_plane_cpp(fb->pixel_format, 0) *
+ skl_plane_downscale_amount(intel_plane);
+
[Intel-gfx] [PATCH 1/7] drm/i915/skl+: Use proper bytes_per_pixel during WM calculation
From: "Kumar, Mahesh" Don't always use bytes_per_pixel using y_plane=0, instead use it according to pixel format. If NV12 use y_plane eqal to 1 Signed-off-by: Kumar, Mahesh --- drivers/gpu/drm/i915/intel_pm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 9df9e9a..68f21b9 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3185,7 +3185,9 @@ static bool skl_compute_plane_wm(const struct drm_i915_private *dev_priv, if (latency == 0 || !cstate->base.active || !fb) return false; - bytes_per_pixel = drm_format_plane_cpp(fb->pixel_format, 0); + bytes_per_pixel = (fb->pixel_format == DRM_FORMAT_NV12) ? + drm_format_plane_cpp(fb->pixel_format, 1) : + drm_format_plane_cpp(fb->pixel_format, 0); method1 = skl_wm_method1(skl_pipe_pixel_rate(cstate), bytes_per_pixel, latency); -- 2.4.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Add support to parse DMI table and get platform memory info
This is needed for WM computation workaround for arbitrated display
bandwidth.
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/i915_dma.c | 19 +++
drivers/gpu/drm/i915/i915_drv.h | 6 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a0f5659..03c3131 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
static int i915_getparam(struct drm_device *dev, void *data,
@@ -855,6 +856,21 @@ static void intel_init_dpio(struct drm_i915_private
*dev_priv)
}
}
+static void dmi_decode_memory_info(const struct dmi_header *hdr, void *priv)
+{
+ struct drm_i915_private *dev_priv = (struct drm_i915_private *) priv;
+ const u8 *data = (const u8 *) hdr;
+
+ if (hdr->type == 17 && hdr->length > 0x17) {
+
+ /* Found a memory channel */
+ dev_priv->dmi.mem_channel++;
+
+ /* Get the speed */
+ dev_priv->dmi.mem_speed = (uint16_t) (*((uint16_t *)(data +
0x15)));
+ }
+}
+
/**
* i915_driver_load - setup chip and create an initial config
* @dev: DRM device
@@ -882,6 +898,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
dev->dev_private = dev_priv;
dev_priv->dev = dev;
+ /* walk the dmi device table for getting platform memory information */
+ dmi_walk(dmi_decode_memory_info, (void *) dev_priv);
+
/* Setup the write-once "constant" device info */
device_info = (struct intel_device_info *)&dev_priv->info;
memcpy(device_info, info, sizeof(dev_priv->info));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 104bd18..f588993 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1962,6 +1962,12 @@ struct drm_i915_private {
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
*/
+
+ /* DMI data for memory bandwidth calculation */
+ struct {
+ uint16_t mem_channel;
+ uint16_t mem_speed;
+ } dmi;
};
static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915/skl+: calculate plane pixel rate.
From: "Kumar, Mahesh"
Don't use pipe pixel rate for plane pixel rate.
Calculate plane pixel according to formula
adjusted plane_pixel_rate = adjusted pipe_pixel_rate * downscale ammount
downscale amount = max[1, src_h/dst_h] * max[1, src_w/dst_w]
if 90/270 rotation use rotated width & height
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pm.c | 95 +++-
2 files changed, 95 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 059b46e..49f237e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -661,6 +661,8 @@ struct intel_plane_wm_parameters {
u64 tiling;
unsigned int rotation;
uint16_t fifo_size;
+/* Stores the adjusted plane pixel rate for WM calculation */
+ uint32_t plane_pixel_rate;
};
struct intel_plane {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 64b39ec..ffcc56a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2841,6 +2841,54 @@ skl_wm_plane_id(const struct intel_plane *plane)
}
}
+/*
+ * This function takes drm_plane_state as input
+ * and decides the downscale amount according to the formula
+ *
+ * downscale amount = Max[1, Horizontal source size / Horizontal dest size]
+ *
+ * Return value is multiplied by 1000 to retain fractional part
+ * Caller should take care of dividing & Rounding off the value
+ */
+static uint32_t
+skl_plane_downscale_amount(const struct intel_plane *intel_plane)
+{
+ struct drm_plane_state *pstate = intel_plane->base.state;
+ struct intel_crtc *crtc = to_intel_crtc(pstate->crtc);
+ struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
+ uint32_t downscale_h, downscale_w;
+ uint32_t src_w, src_h, dst_w, dst_h, tmp;
+
+ if (drm_rect_width(&intel_pstate->src)) {
+ src_w = drm_rect_width(&intel_pstate->src) >> 16;
+ src_h = drm_rect_height(&intel_pstate->src) >> 16;
+ } else {
+ src_w = crtc->config->pipe_src_w;
+ src_h = crtc->config->pipe_src_h;
+ }
+
+ dst_w = drm_rect_width(&intel_pstate->dst);
+ dst_h = drm_rect_height(&intel_pstate->dst);
+
+ if (intel_rotation_90_or_270(pstate->rotation))
+ swap(dst_w, dst_h);
+
+ /* If destination height & wight are zero return amount as unity */
+ if (dst_w == 0 || dst_h == 0)
+ return 1000;
+
+ /* Multiply by 1000 for precision */
+ tmp = (1000 * src_h) / dst_h;
+ downscale_h = max_t(uint32_t, 1000, tmp);
+
+ tmp = (1000 * src_w) / dst_w;
+ downscale_w = max_t(uint32_t, 1000, tmp);
+
+ /* Reducing precision to 3 decimal places */
+ return DIV_ROUND_UP(downscale_h * downscale_w, 1000);
+}
+
+
static void
skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
const struct intel_crtc_state *cstate,
@@ -3265,10 +3313,10 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
bytes_per_pixel = (fb->pixel_format == DRM_FORMAT_NV12) ?
drm_format_plane_cpp(fb->pixel_format, 1) :
drm_format_plane_cpp(fb->pixel_format, 0);
- method1 = skl_wm_method1(skl_pipe_pixel_rate(cstate),
+ method1 = skl_wm_method1(intel_plane->wm.plane_pixel_rate,
bytes_per_pixel,
latency);
- method2 = skl_wm_method2(skl_pipe_pixel_rate(cstate),
+ method2 = skl_wm_method2(intel_plane->wm.plane_pixel_rate,
cstate->base.adjusted_mode.crtc_htotal,
width,
bytes_per_pixel,
@@ -3709,6 +3757,46 @@ static void skl_update_other_pipe_wm(struct drm_device
*dev,
}
}
+static uint32_t
+skl_plane_pixel_rate(struct intel_crtc_state *cstate, struct intel_plane
*plane)
+{
+ uint32_t adjusted_pixel_rate;
+ uint32_t downscale_amount;
+
+ /*
+* adjusted plane pixel rate = adjusted pipe pixel rate
+* Plane pixel rate = adjusted plane pixel rate * plane down scale
+* amount
+*/
+ adjusted_pixel_rate = skl_pipe_pixel_rate(cstate);
+ downscale_amount = skl_plane_downscale_amount(plane);
+
+ return DIV_ROUND_UP(adjusted_pixel_rate * downscale_amount,
+ 1000);
+}
+
+static void skl_set_plane_pixel_rate(struct drm_crtc *crtc)
+{
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
+ struct intel_plane *intel_plane = NULL;
+ struct drm_device *dev = crtc->dev;
+
+ if (!intel_crtc->active)
+ return;
+ for_each_inte
[Intel-gfx] [PATCH 2/7] drm/i915/skl+: Use fb size for relative data rate calculation
From: "Kumar, Mahesh"
Use FB size for relative data rate calculation. don't always use
pipe source width & height.
adjust height & width according to rotation.
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_pm.c | 42 -
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 68f21b9..d33c4ff 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2928,24 +2928,33 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
int y)
{
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
+ struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
struct drm_framebuffer *fb = pstate->fb;
+ uint32_t width = 0, height = 0;
+
+ if (drm_rect_width(&intel_pstate->src)) {
+ width = drm_rect_width(&intel_pstate->src) >> 16;
+ height = drm_rect_height(&intel_pstate->src) >> 16;
+ } else {
+ width = intel_crtc->config->pipe_src_w;
+ height = intel_crtc->config->pipe_src_h;
+ }
+
+ if (intel_rotation_90_or_270(pstate->rotation))
+ swap(width, height);
/* for planar format */
if (fb->pixel_format == DRM_FORMAT_NV12) {
if (y) /* y-plane data rate */
- return intel_crtc->config->pipe_src_w *
- intel_crtc->config->pipe_src_h *
+ return width * height *
drm_format_plane_cpp(fb->pixel_format, 0);
else/* uv-plane data rate */
- return (intel_crtc->config->pipe_src_w/2) *
- (intel_crtc->config->pipe_src_h/2) *
+ return (width / 2) * (height / 2) *
drm_format_plane_cpp(fb->pixel_format, 1);
}
/* for packed formats */
- return intel_crtc->config->pipe_src_w *
- intel_crtc->config->pipe_src_h *
- drm_format_plane_cpp(fb->pixel_format, 0);
+ return width * height * drm_format_plane_cpp(fb->pixel_format, 0);
}
/*
@@ -3181,10 +3190,25 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint32_t res_blocks, res_lines;
uint32_t selected_result;
uint8_t bytes_per_pixel;
+ struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
+ struct intel_plane_state *intel_pstate =
to_intel_plane_state(plane->state);
+ uint32_t width = 0, height = 0;
if (latency == 0 || !cstate->base.active || !fb)
return false;
+ if (drm_rect_width(&intel_pstate->src)) {
+ width = drm_rect_width(&intel_pstate->src) >> 16;
+ height = drm_rect_height(&intel_pstate->src) >> 16;
+ } else {
+ width = intel_crtc->config->pipe_src_w;
+ height = intel_crtc->config->pipe_src_h;
+ }
+
+ if (intel_rotation_90_or_270(plane->state->rotation))
+ swap(width, height);
+
+ /* for planar format */
bytes_per_pixel = (fb->pixel_format == DRM_FORMAT_NV12) ?
drm_format_plane_cpp(fb->pixel_format, 1) :
drm_format_plane_cpp(fb->pixel_format, 0);
@@ -3193,12 +3217,12 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
latency);
method2 = skl_wm_method2(skl_pipe_pixel_rate(cstate),
cstate->base.adjusted_mode.crtc_htotal,
-cstate->pipe_src_w,
+width,
bytes_per_pixel,
fb->modifier[0],
latency);
- plane_bytes_per_line = cstate->pipe_src_w * bytes_per_pixel;
+ plane_bytes_per_line = width * bytes_per_pixel;
plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915/skl+: calculate ddb minimum allocation
From: "Kumar, Mahesh"
don't always use 8 ddb as minimum, instead calculate using proper
algorithm.
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_pm.c | 57 +++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d33c4ff..64b39ec 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2994,6 +2994,59 @@ skl_get_total_relative_data_rate(const struct
intel_crtc_state *cstate)
return total_data_rate;
}
+static uint16_t
+skl_ddb_min_alloc(const struct intel_crtc *crtc,
+ const struct drm_plane *plane, int y)
+{
+ struct drm_framebuffer *fb = plane->state->fb;
+ struct intel_plane_state *pstate = to_intel_plane_state(plane->state);
+ uint16_t min_alloc;
+ uint32_t src_w, src_h;
+
+ /* For packed formats, no y-plane, return 0 */
+ if (y && !(fb->pixel_format == DRM_FORMAT_NV12))
+ return 0;
+
+ if (drm_rect_width(&pstate->src)) {
+ src_w = drm_rect_width(&pstate->src) >> 16;
+ src_h = drm_rect_height(&pstate->src) >> 16;
+ } else {
+ src_w = crtc->config->pipe_src_w;
+ src_h = crtc->config->pipe_src_h;
+ }
+
+ if (intel_rotation_90_or_270(plane->state->rotation))
+ swap(src_w, src_h);
+
+ if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
+ fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
+ uint32_t min_scanlines = 8;
+ uint8_t bytes_per_pixel =
+ y ? drm_format_plane_cpp(fb->pixel_format, 1) :
+ drm_format_plane_cpp(fb->pixel_format, 0);
+
+ if (intel_rotation_90_or_270(plane->state->rotation)) {
+ switch (bytes_per_pixel) {
+ case 1:
+ min_scanlines = 32;
+ break;
+ case 2:
+ min_scanlines = 16;
+ break;
+ case 8:
+ WARN(1, "Unsupported pixel depth for rotation");
+ }
+ }
+ min_alloc = DIV_ROUND_UP((4 * src_w / (y ? 1 : 2) *
+ bytes_per_pixel), 512) * min_scanlines/4 + 3;
+ } else {
+ min_alloc = 8;
+ }
+
+ return min_alloc;
+}
+
+
static void
skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
struct skl_ddb_allocation *ddb /* out */)
@@ -3038,9 +3091,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
if (plane->type == DRM_PLANE_TYPE_CURSOR)
continue;
- minimum[id] = 8;
+ minimum[id] = skl_ddb_min_alloc(intel_crtc, plane, 0);
alloc_size -= minimum[id];
- y_minimum[id] = (fb->pixel_format == DRM_FORMAT_NV12) ? 8 : 0;
+ y_minimum[id] = skl_ddb_min_alloc(intel_crtc, plane, 1);
alloc_size -= y_minimum[id];
}
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] Misc WM fixes and Arbitrated Display Bandwidth WA for SKL
Hi, This series add a set of updates to the WM calculation and also enables arbitrated display bandwidth based WA. Some of these patches do overlap with Matts work but we wanted to send them out as we have them in our internal testing for early review. Most likley some of them can be superceded by patches from Matt, or can be re-used if deemed necessary. Especially "drm/i915/skl+: Use fb size for relative data rate calculation" this already addresses some of Ville's comment on similar patch from Matt. Regards Shobhit Kumar, Mahesh (6): drm/i915/skl+: Use proper bytes_per_pixel during WM calculation drm/i915/skl+: Use fb size for relative data rate calculation drm/i915/skl+: calculate ddb minimum allocation drm/i915/skl+: calculate plane pixel rate. drm/i915/skl+: Use scaling amount for plane data rate calculation drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW Shobhit Kumar (1): drm/i915: Add support to parse DMI table and get platform memory info drivers/gpu/drm/i915/i915_dma.c | 19 +++ drivers/gpu/drm/i915/i915_drv.h | 15 ++ drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_pm.c | 294 +-- 4 files changed, 316 insertions(+), 14 deletions(-) -- 2.4.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
On Thu, Jan 14, 2016 at 11:27:42AM +, Tvrtko Ursulin wrote: > > On 14/01/16 11:14, Chris Wilson wrote: > >On Thu, Jan 14, 2016 at 10:46:39AM +, Tvrtko Ursulin wrote: > >> > >>On 14/01/16 10:24, Chris Wilson wrote: > >>> * Stolen memory is a very limited resource and certain functions of the > >>> * hardware can only work from within stolen memory. Userspace's > >>> * allocations may be evicted from stolen and moved to normal memory as > >>> * required. If the allocation is marked as purgeable (using madvise), > >>> * the allocation will be dropped and further access to the object's > >>> * backing storage will result in -EFAULT. Stolen objects will also be > >>> * migrated to normal memory across suspend and resume, as the stolen > >>> * memory is not preserved. > >>> * > >>> * Stolen memory is regarded as a resource placement hint, most suitable > >>> * for medium-sized buffers that are only accessed by the GPU and can be > >>> * discarded. > >>> */ > >> > >>Would it be better if the placement hint did not specifically > >>mention stolen memory but specific limitations? Like, > > > >It is a nice idea, but it doesn't really fit with the other placement > >domains I have sketched out (they are all fully featured, or nearly so, > >but exist in different pools of memory with different characteristics > >and reasons for choice). > > Perhaps these pools have some characteristics which could be > described abstractly? I am of course coming back to why would > userspace have to know about stolen, why would we fail object > creation if there is no space, and then move objects out of stolen > on hibernate and never put them back. Sounds like a bad and > inflexible interface, and a lying kernel to me. I agree that migrating and failing because of not enough space is nasty. I was tempted to suggest we allow stolen to fallback to normal during creation. (But ABI is tricky, and I think we've got way past the point where this series is ready, we're down to stray lines and choosing a colour for the kettle.) The choice is whether we disable powersaving because userspace allocated a ton of vertex buffers in stolen, or if we just tell them to get lost and take back our memory. It's a two-level priority eviction pass at the moment, kernel vs userspace. We could extend that to several classes/priorites (anything that maps to an unsigned long), but then we need to define a policy of whether some levels are privileged etc. (Overengineering until someone discovers that the kernel kicking their objects out to enable FBC actually causes regression.) Some of the abstraction is nice, but I feel that it makes for sloppy uAPI, and a hindrance to letting userspace decide what it wants. With complex questions of "where should I allocate this buffer", the answer has always been to push that as close to the real decision maker as possible. Making the choice in the kernel, smacks of policy. The mechanism would be to let userspace know the details and make a choice. (All the kernel should have to do is make sure userspace doesn't stomp on each other.) The question is whether the important API detail is the placement, or the first/second class nature of the object interface. I favour selecting placement. -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 v10] drm/i915: Extend LRC pinning to cover GPU context writeback
On 14/01/2016 11:36, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 04:19:45PM +, Nick Hoath wrote:
+ if (ctx->engine[ring->id].dirty) {
+ struct drm_i915_gem_request *req = NULL;
+
+ /**
+* If there is already a request pending on
+* this ring, wait for that to complete,
+* otherwise create a switch to idle request
+*/
+ if (list_empty(&ring->request_list)) {
+ int ret;
+
+ ret = i915_gem_request_alloc(
+ ring,
+ ring->default_context,
+ &req);
+ if (!ret)
+ i915_add_request(req);
+ else
+ DRM_DEBUG("Failed to ensure context saved");
+ } else {
+ req = list_first_entry(
+ &ring->request_list,
+ typeof(*req), list);
+ }
+ if (req) {
+ ret = i915_wait_request(req);
+ if (ret != 0) {
+ /**
+* If we get here, there's probably been a ring
+* reset, so we just clean up the dirty flag.&
+* pin count.
+*/
+ ctx->engine[ring->id].dirty = false;
+ __intel_lr_context_unpin(
+ ring,
+ ctx);
+ }
+ }
If you were to take a lr_context_pin on the last_context, and only
release that pin when you change to a new context, you do not need to
That what this patch does.
introduce a blocking context-close, nor do you need to introduce the
usage of default_context.
The use of default_context here is to stop a context hanging around
after it is no longer needed.
(lr_context_pin should take a reference on the ctx to prevent early
freeeing ofc).
You can't clear the reference on the ctx in an interrupt context.
The code at that point starts to look v.v.similar to legacy, right down
to the need to use a GPU reset during shutdown to prevent writing back
the context image. (Which you still currently need to get rid of the
default context now.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (bdw-ultra) bdw-ultratotal:138 pass:131 dwarn:1 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1183/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 6/9] drm/i915: Add sync framework support to execbuff IOCTL
On 13/01/2016 18:43, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 05:57:32PM +, john.c.harri...@intel.com wrote:
static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
@@ -1428,6 +1465,17 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
u32 dispatch_flags;
int ret, i;
bool need_relocs;
+ int fd_fence_complete = -1;
+ int fd_fence_wait = lower_32_bits(args->rsvd2);
+ struct sync_fence *sync_fence;
+
+ /*
+* Make sure an broken fence handle is not returned no matter
+* how early an error might be hit. Note that rsvd2 has been
+* saved away above because it is also an input parameter!
+*/
+ if (args->flags & I915_EXEC_CREATE_FENCE)
+ args->rsvd2 = (__u64) -1;
But you are not restoring the user input parameter upon an error path.
Very simple example is the user trying to do a wait on a fence but is
woken up by a signal and then tries to restart the syscall, the standard
do {
ret = ioctl(fd, request, arg);
} while (ret == -1 && (errno == EINTR || errno == EAGAIN));
loop errors out with EINVAL on the second pass.
if (!i915_gem_check_execbuffer(args))
return -EINVAL;
@@ -1511,6 +1559,17 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
dispatch_flags |= I915_DISPATCH_RS;
}
+ /*
+* Without a GPU scheduler, any fence waits must be done up front.
+*/
+ if (args->flags & I915_EXEC_WAIT_FENCE) {
+ ret = i915_early_fence_wait(ring, fd_fence_wait);
+ if (ret < 0)
+ return ret;
+
+ args->flags &= ~I915_EXEC_WAIT_FENCE;
+ }
+
ret = i915_mutex_lock_interruptible(dev);
if (ret)
goto pre_mutex_err;
@@ -1695,13 +1754,41 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
i915_gem_context_reference(ctx);
params->ctx = ctx;
+ if (args->flags & I915_EXEC_CREATE_FENCE) {
+ /*
+* Caller has requested a sync fence.
+* User interrupts will be enabled to make sure that
+* the timeline is signalled on completion.
+*/
+ ret = i915_create_sync_fence(params->request, &sync_fence,
+&fd_fence_complete);
+ if (ret) {
+ DRM_ERROR("Fence creation failed for ring %d, ctx %p\n",
+ ring->id, ctx);
+ goto err_batch_unpin;
+ }
+ }
+
ret = dev_priv->gt.execbuf_submit(params, args, &eb->vmas);
if (ret)
- goto err_batch_unpin;
+ goto err_fence;
/* the request owns the ref now */
i915_gem_context_unreference(ctx);
+ if (fd_fence_complete != -1) {
+ /*
+* Install the fence into the pre-allocated file
+* descriptor to the fence object so that user land
+* can wait on it...
+*/
+ i915_install_sync_fence_fd(params->request,
+ sync_fence, fd_fence_complete);
+
+ /* Return the fence through the rsvd2 field */
+ args->rsvd2 = (__u64) fd_fence_complete;
Use the upper s32 for the output, so again you are not overwriting user
state without good reason.
-Chris
Makes sense. Will do.
Thanks,
John.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback
On Wed, Jan 13, 2016 at 04:19:45PM +, Nick Hoath wrote:
> + if (ctx->engine[ring->id].dirty) {
> + struct drm_i915_gem_request *req = NULL;
> +
> + /**
> + * If there is already a request pending on
> + * this ring, wait for that to complete,
> + * otherwise create a switch to idle request
> + */
> + if (list_empty(&ring->request_list)) {
> + int ret;
> +
> + ret = i915_gem_request_alloc(
> + ring,
> + ring->default_context,
> + &req);
> + if (!ret)
> + i915_add_request(req);
> + else
> + DRM_DEBUG("Failed to ensure context saved");
> + } else {
> + req = list_first_entry(
> + &ring->request_list,
> + typeof(*req), list);
> + }
> + if (req) {
> + ret = i915_wait_request(req);
> + if (ret != 0) {
> + /**
> + * If we get here, there's probably been a ring
> + * reset, so we just clean up the dirty flag.&
> + * pin count.
> + */
> + ctx->engine[ring->id].dirty = false;
> + __intel_lr_context_unpin(
> + ring,
> + ctx);
> + }
> + }
If you were to take a lr_context_pin on the last_context, and only
release that pin when you change to a new context, you do not need to
introduce a blocking context-close, nor do you need to introduce the
usage of default_context.
(lr_context_pin should take a reference on the ctx to prevent early
freeeing ofc).
The code at that point starts to look v.v.similar to legacy, right down
to the need to use a GPU reset during shutdown to prevent writing back
the context image. (Which you still currently need to get rid of the
default context now.)
-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] [RFC 3/9] staging/android/sync: Move sync framework out of staging
On 13/01/2016 19:00, Gustavo Padovan wrote: Hi John, 2016-01-13 john.c.harri...@intel.com : From: John Harrison The sync framework is now used by the i915 driver. Therefore it can be moved out of staging and into the regular tree. Also, the public interfaces can actually be made public and exported. I also have been working on de-staging the sync framework, but I've taken the approach of cleaning up the sync framework first. e.g., I got rid of sync_pt and use struct fence directly, also sync_timeline is now fence_timeline and its ops are gone in favor of fence_ops. My current work is here: https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=sync My current plan is clean up patches, add commits messages and document the changes I've made and then it should be ready for a RFC. Gustavo Hello, Sounds good. I did note in my cover letter that these patches were only being posted to let people review the i915 side of the changes on a complete and working tree. Once we found out you were working on the de-stage the decision was to let you get on with it and not duplicate the effort here :). Note that patches four and five of this series are enhancements to the sync code rather than just de-staging it. Would they still be applicable to your new and improved version? Do you have an expected time scale for when your patches will land? Also, do you have any sort of overview document explaining what externally visible changes you are making and what the implications are for other drivers that are using the API? Re the SW_SYNC_USER bits, we were just using that for a user land test program. The idea was to create an timeline external to the i915 driver and pass sync points in to i915 to be waited on and check that the i915 work itself only happens after the test signals the timeline appropriately. If this interface is going away, is there a plan to replace it with any other mechanism for doing similar? Or do we have to create some kind of dummy kernel module in order to get a testing timeline? Thanks, John. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3] lib/igt_pm: Lib for power management
Move power management related code to a separate library.
Initially this is done only for workarounds that apply to external
components. Modify the users of such workarounds accordingly.
This currently involves HD audio and SATA link power management.
For SATA link PM there's also code to save the previous settings,
to allow for resetting the values after we've finished testing.
Signed-off-by: David Weinehall
---
.../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 +
lib/Makefile.sources | 2 +
lib/igt.h | 1 +
lib/igt_aux.c | 15 +-
lib/igt_pm.c | 233 +
lib/igt_pm.h | 31 +++
tests/pm_lpsp.c| 25 +--
tests/pm_rpm.c | 40 +---
8 files changed, 281 insertions(+), 67 deletions(-)
create mode 100644 lib/igt_pm.c
create mode 100644 lib/igt_pm.h
diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
index 618dc5fd7076..3ea3563a029a 100644
--- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
+++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
@@ -24,6 +24,7 @@
+
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 4999868052b1..2f0eb2075e14 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -60,6 +60,8 @@ libintel_tools_la_SOURCES = \
igt_core.h \
igt_draw.c \
igt_draw.h \
+ igt_pm.c\
+ igt_pm.h\
$(NULL)
.PHONY: version.h.tmp
diff --git a/lib/igt.h b/lib/igt.h
index 3be25511bb77..d751f2439de2 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -35,6 +35,7 @@
#include "igt_fb.h"
#include "igt_gt.h"
#include "igt_kms.h"
+#include "igt_pm.h"
#include "igt_stats.h"
#include "instdone.h"
#include "intel_batchbuffer.h"
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 4d08d68bb932..cd7f14649fe2 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -59,6 +59,7 @@
#include "intel_reg.h"
#include "ioctl_wrappers.h"
#include "igt_kms.h"
+#include "igt_pm.h"
/**
* SECTION:igt_aux
@@ -531,19 +532,7 @@ bool igt_setup_runtime_pm(void)
if (pm_status_fd >= 0)
return true;
- /* The Audio driver can get runtime PM references, so we need to make
-* sure its runtime PM is enabled, so it can release the refs and
-* actually enable us to runtime suspend. */
- fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
- if (fd >= 0) {
- igt_assert(write(fd, "1\n", 2) == 2);
- close(fd);
- }
- fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
- if (fd >= 0) {
- igt_assert(write(fd, "auto\n", 5) == 5);
- close(fd);
- }
+ igt_pm_enable_audio_runtime_pm();
/* Our implementation uses autosuspend. Try to set it to 0ms so the test
* suite goes faster and we have a higher probability of triggering race
diff --git a/lib/igt_pm.c b/lib/igt_pm.c
new file mode 100644
index ..2f574961d179
--- /dev/null
+++ b/lib/igt_pm.c
@@ -0,0 +1,233 @@
+/*
+ * Copyright © 2013, 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Paulo Zanoni
+ *David Weinehall
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drmtest.h"
+#include "igt_pm.h"
+
+enum {
+ POLICY_UNKNOWN = -1,
+ POLICY_MAX_PERFORMANCE = 0,
+ POLICY_MEDIUM_POWER = 1,
+ POLICY_MIN_POWER = 2
+};
+
+#define MAX_PERFORMANCE_STR"max_performance\n"
+#define M
[Intel-gfx] [PATCH i-g-t v3] Add a lib for power management helpers
This patch aims to create a separate lib for power management related helpers. Initially it only contains code that modify settings for external components (to handle components with default settings that prevents entering deeper sleep states), but moving i915-related power management helpers to this lib would probably make sense too. v2: Change name of library to igt_pm Namespace all exported functions with igt_pm_ v3: Various fixes based on feedback from Thomas Wood David Weinehall (1): lib/igt_pm: Lib for power management .../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 + lib/Makefile.sources | 2 + lib/igt.h | 1 + lib/igt_aux.c | 15 +- lib/igt_pm.c | 233 + lib/igt_pm.h | 31 +++ tests/pm_lpsp.c| 25 +-- tests/pm_rpm.c | 40 +--- 8 files changed, 281 insertions(+), 67 deletions(-) create mode 100644 lib/igt_pm.c create mode 100644 lib/igt_pm.h -- 2.7.0.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
