Re: [Intel-gfx] [PATCH] drm/i915: Fix some NUM_RING iterators
On Sat, Jun 28, 2014 at 08:28:55PM +0100, Chris Wilson wrote:
> On Sat, Jun 28, 2014 at 08:26:15AM -0700, Ben Widawsky wrote:
> > On Sat, Jun 28, 2014 at 07:20:38AM +0100, Chris Wilson wrote:
> > > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > > > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > > > index 86362de..6e5250d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > > > @@ -848,7 +848,7 @@ static uint32_t i915_error_generate_code(struct
> > > > drm_i915_private *dev_priv,
> > > > * synchronization commands which almost always appear in
> > > > the
> > > > case
> > > > * strictly a client bug. Use instdone to differentiate
> > > > those
> > > > some.
> > > > */
> > > > - for (i = 0; i < I915_NUM_RINGS; i++) {
> > > > + for (i = 0; i < I915_ACTIVE_RINGS(dev_priv->dev); i++) {
> > > > if (error->ring[i].hangcheck_action ==
> > > > HANGCHECK_HUNG) {
> > > > if (ring_id)
> > > > *ring_id = i;
> > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > > index e72017b..67e2919 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > > @@ -90,6 +90,8 @@ struct intel_engine_cs {
> > > > } id;
> > > > #define I915_NUM_RINGS 5
> > > > #define LAST_USER_RING (VECS + 1)
> > > > +#define I915_ACTIVE_RINGS(dev)
> > > > hweight8(INTEL_INFO(dev)->ring_mask)
> > >
> > > What does the popcount of the mask have to do with the validity of the
> > > arrays being iterated over in this patch?
> > > -Chris
> >
> > The popcount of the mask represents the number of rings available on the
> > specific SKU, as opposed to the total number of rings on any SKU ever.
> > It is not always correct to iterate on all rings in the system. Please
> > note, the patch is incomplete. I have a couple of other, perhaps more
> > interesting, cases which I've missed.
>
> You still iterate over holes in the ring mask, and the iteration here is
> over a completely different array, not rings.
> -Chris
For the holes, I mentioned that in the commit message of the yet to be
submitted v2; it's not really an issue in the way things are today.
When/if we add a new ring, it will be.
What you're asking for has already been submitted multiple times with
seemingly no traction. I do realize the fixes (with my v2) are due to
bugs introduced in patches I've not yet submitted, so I think for that
reason, it's fair to drop this patch.
I'd rather the other patch get in (for_each_active_ring), but it's tied
up with execlists atm, and I continue to think this is a useful way to
iterate over the rings in error conditions and during reset.
As for your second point, assuming it's the code above, I don't quite
follow what you mean. Error code generation shouldn't be based upon
inactive rings. As for whether it changes any of the functionality, it
does not - but that wasn't the point of that hunk.
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix some NUM_RING iterators
On Sat, Jun 28, 2014 at 08:26:15AM -0700, Ben Widawsky wrote:
> On Sat, Jun 28, 2014 at 07:20:38AM +0100, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > > index 86362de..6e5250d 100644
> > > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > > @@ -848,7 +848,7 @@ static uint32_t i915_error_generate_code(struct
> > > drm_i915_private *dev_priv,
> > > * synchronization commands which almost always appear in the
> > > case
> > > * strictly a client bug. Use instdone to differentiate those
> > > some.
> > > */
> > > - for (i = 0; i < I915_NUM_RINGS; i++) {
> > > + for (i = 0; i < I915_ACTIVE_RINGS(dev_priv->dev); i++) {
> > > if (error->ring[i].hangcheck_action ==
> > > HANGCHECK_HUNG) {
> > > if (ring_id)
> > > *ring_id = i;
> > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > index e72017b..67e2919 100644
> > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > @@ -90,6 +90,8 @@ struct intel_engine_cs {
> > > } id;
> > > #define I915_NUM_RINGS 5
> > > #define LAST_USER_RING (VECS + 1)
> > > +#define I915_ACTIVE_RINGS(dev) hweight8(INTEL_INFO(dev)->ring_mask)
> >
> > What does the popcount of the mask have to do with the validity of the
> > arrays being iterated over in this patch?
> > -Chris
>
> The popcount of the mask represents the number of rings available on the
> specific SKU, as opposed to the total number of rings on any SKU ever.
> It is not always correct to iterate on all rings in the system. Please
> note, the patch is incomplete. I have a couple of other, perhaps more
> interesting, cases which I've missed.
You still iterate over holes in the ring mask, and the iteration here is
over a completely different array, not rings.
-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] Linux 3.16-rc1: drm:intel_dp_start_link_train *ERROR* too many full retries, give up
Hello Daniel, just to close my request: The latest git pull from Linus' tree fixed my issue. vmlinuz-3.16.0-rc2-00211-gd7933ab (26.6. 21:19) was bad vmlinuz-3.16.0-rc2-00319-g3e7b256 (28.6. 09:23) works again There are two pulls with 'drm-fixes' and 'x86/urgent' in this area. Don't know what it was in detail - but it's fixed now (lightdm/xfce4 runs). Thanks, Oliver On 17.06.2014 20:38, Oliver Hartkopp wrote: > Hello Daniel, > > thanks for your fast reply. > > I started the system with drm.debug=0xe with the same effect - therefore I was > not able to log in %-( > > Btw. when starting into single user mode, I was able to say 'xinit' which > produced the borderless xterm at the top left position. So obviously the > display is working. Running lightdm from the console in single user mode does > not work (dbus missing?). Starting lightdm a second time kills the console. > > I think I need to dig into the lightdm and startup stuff. > So this might not be an i915 issue. Sorry for the noise. > > I'll send an update if I discover any new info ... > > Thanks for your support so far, > Oliver > > On 16.06.2014 23:47, Daniel Vetter wrote: >> On Mon, Jun 16, 2014 at 10:08 PM, Oliver Hartkopp >> wrote: >>> Hey all, >>> >>> with my Debian unstable the upgrade from 3.15 to 3.16-rc1 failed with this >>> fancy >>> [drm:intel_dp_start_link_train *ERROR* too many full retries, give up] >>> message loop. >> >> This message in dmesg and >> >>> lightdm/XFCE4 doesn't start anymore (it tries several times but fails >>> always). >> >> xfce not starting shouldn't be related. Are you sure xfce isn't >> starting and that it's not just a black screen, but otherwise working >> X? >> >> Please attach complete dmesg with drm.debug=0xe added to your kernel >> cmdline and Xorg.log. >> >> Thanks, Daniel >> >>> Hm - I just found this stuff in my stock Debian Kernel too: >>> 3.14-1-686-pae #1 SMP Debian 3.14.5-1 (2014-06-05) i686 GNU/Linux >>> >>> >>> [6.461232] [drm:intel_dp_start_link_train] *ERROR* too many full >>> retries, give up >>> [6.873772] dell_wmi: Received unknown WMI event (0x11) >>> [6.884336] Console: switching to colour frame buffer device 240x67 >>> [6.948511] i915 :00:02.0: fb0: inteldrmfb frame buffer device >>> [6.948513] i915 :00:02.0: registered panic notifier >>> >>> [7.430429] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on >>> minor 0 >>> >>> But at least it starts with the 3.14 (any the latest 3.15). >>> >>> I have a Intel(R) Core(TM) i7 CPU M 640 @ 2.80GHz with Intel HD graphics. >>> >>> Any idea? >>> >>> Regards, >>> Oliver >> >> >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix some NUM_RING iterators
On Sat, Jun 28, 2014 at 07:20:38AM +0100, Chris Wilson wrote:
> On Fri, Jun 27, 2014 at 03:21:20PM -0700, Rodrigo Vivi wrote:
> >Reviewed-by: Rodrigo Vivi <[1]rodrigo.v...@intel.com>
> >
> >On Fri, Jun 27, 2014 at 3:09 PM, Ben Widawsky
> ><[2]benjamin.widaw...@intel.com> wrote:
> >
> > There are some cases in the code where we need to know how many rings
> > to
> > iterate over, but cannot use for_each_ring(). These are always error
> > cases
> > which happen either before ring setup, or after ring teardown (or
> > reset).
> >
> > Note, a NUM_RINGS issue exists in semaphores, but this is fixed by the
> > remaining semaphore patches which Rodrigo will resubmit shortly. I'd
> > rather see those patches for fixing the problem than fix it here.
> >
> > I found this initially for the BSD2 case where on the same platform we
> > can have differing rings. AFAICT however this effects many platforms.
> >
> > I'd CC stable on this, except I think all the issues have been around
> > for multiple releases without bug reports.
> >
> > Compile tested only for now.
> >
> > Signed-off-by: Ben Widawsky <[3]b...@bwidawsk.net>
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c | 6 +++---
> > drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
> > 3 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index b9bac25..0c044a9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -403,7 +403,7 @@ void i915_gem_context_reset(struct drm_device *dev)
> >
> > /* Prevent the hardware from restoring the last context (which
> > hung) on
> > * the next switch */
> > - for (i = 0; i < I915_NUM_RINGS; i++) {
> > + for (i = 0; i < I915_ACTIVE_RINGS(dev); i++) {
> > struct intel_engine_cs *ring = &dev_priv->ring[i];
> > struct intel_context *dctx = ring->default_context;
> >
> > @@ -456,7 +456,7 @@ int i915_gem_context_init(struct drm_device *dev)
> > }
> >
> > /* NB: RCS will hold a ref for all rings */
> > - for (i = 0; i < I915_NUM_RINGS; i++)
> > + for (i = 0; i < I915_ACTIVE_RINGS(dev); i++)
> > dev_priv->ring[i].default_context = ctx;
> >
> > DRM_DEBUG_DRIVER("%s context support initialized\n",
> > dev_priv->hw_context_size ? "HW" : "fake");
> > @@ -493,7 +493,7 @@ void i915_gem_context_fini(struct drm_device *dev)
> > i915_gem_object_ggtt_unpin(dctx->obj);
> > }
> >
> > - for (i = 0; i < I915_NUM_RINGS; i++) {
> > + for (i = 0; i < I915_ACTIVE_RINGS(dev); i++) {
> > struct intel_engine_cs *ring = &dev_priv->ring[i];
> >
> > if (ring->last_context)
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index 86362de..6e5250d 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > @@ -848,7 +848,7 @@ static uint32_t i915_error_generate_code(struct
> > drm_i915_private *dev_priv,
> > * synchronization commands which almost always appear in the
> > case
> > * strictly a client bug. Use instdone to differentiate those
> > some.
> > */
> > - for (i = 0; i < I915_NUM_RINGS; i++) {
> > + for (i = 0; i < I915_ACTIVE_RINGS(dev_priv->dev); i++) {
> > if (error->ring[i].hangcheck_action == HANGCHECK_HUNG)
> > {
> > if (ring_id)
> > *ring_id = i;
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > index e72017b..67e2919 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > @@ -90,6 +90,8 @@ struct intel_engine_cs {
> > } id;
> > #define I915_NUM_RINGS 5
> > #define LAST_USER_RING (VECS + 1)
> > +#define I915_ACTIVE_RINGS(dev) hweight8(INTEL_INFO(dev)->ring_mask)
>
> What does the popcount of the mask have to do with the validity of the
> arrays being iterated over in this patch?
> -Chris
The popcount of the mask represents the number of rings available on the
specific SKU, as opposed to the total number of rings on any SKU ever.
It is not always correct to iterate on all rings in the system. Please
note, the patch is incomplete. I have a couple of other, perhaps more
interesting, cases which I've missed.
--
Ben Widawsky, Intel Open Sourc
Re: [Intel-gfx] [PATCH 0/5] drm/i915: Fix backlight regression caused by misconfigured VBT
On Fri, 27 Jun 2014, Scot Doyle wrote: > commit c675949ec58ca50d5a3ae3c757892f1560f6e896 > drm/i915: do not setup backlight if not available according to VBT > > caused a regression on machines with a misconfigured VBT. Add a quirk to > assert the presence of a controllable backlight, overriding the VBT. Then > apply this quirk to four Haswell-based Chromebook laptops. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813 Oh, we'll want this stuff in the commit message of (at least) patch 1. No need to resend for this. Thanks, Jani. > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] quirk asserts controllable backlight presence, overriding VBT
On Fri, 27 Jun 2014, Scot Doyle wrote:
> Add a quirk to assert the presence of a controllable backlight. Use it to
> ignore the VBT backlight presence check during backlight setup.
>
> Tested-by: James Duley
> Signed-off-by: Scot Doyle
> CC: Jani Nikula
> ---
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8cea596..723b1fe 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -657,6 +657,7 @@ enum intel_sbi_destination {
> #define QUIRK_PIPEA_FORCE (1<<0)
> #define QUIRK_LVDS_SSC_DISABLE (1<<1)
> #define QUIRK_INVERT_BRIGHTNESS (1<<2)
> +#define QUIRK_BACKLIGHT_PRESENT (1<<3)
>
> struct intel_fbdev;
> struct intel_fbc_work;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 065984d..c583b07 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12290,6 +12290,14 @@ static void quirk_invert_brightness(struct
> drm_device *dev)
> DRM_INFO("applying inverted panel brightness quirk\n");
> }
>
> +/* Some VBT's incorrectly indicate no backlight is present */
> +static void quirk_backlight_present(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + dev_priv->quirks |= QUIRK_BACKLIGHT_PRESENT;
> + DRM_INFO("applying backlight present quirk\n");
> +}
> +
> struct intel_quirk {
> int device;
> int subsystem_vendor;
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 38a9857..dfc6b5f 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1118,8 +1118,13 @@ int intel_panel_setup_backlight(struct drm_connector
> *connector)
> int ret;
>
> if (!dev_priv->vbt.backlight.present) {
> - DRM_DEBUG_KMS("native backlight control not available per
> VBT\n");
> - return 0;
> + if (dev_priv->quirks & QUIRK_BACKLIGHT_PRESENT) {
> + DRM_DEBUG_KMS("no backlight present per VBT, but "
> + "present per quirk\n");
Usually strings are not wrapped so that you can grep the source for
them.
Reviewed-by: Jani Nikula
> + } else {
> + DRM_DEBUG_KMS("no backlight present per VBT\n");
> + return 0;
> + }
> }
>
> /* set level and max in panel struct */
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] Dell 11 Chromebook has a controllable backlight
On Fri, 27 Jun 2014, Scot Doyle wrote:
> The Dell 11 Chromebook laptop has a controllable backlight although its
> VBT reports otherwise.
>
> Signed-off-by: Scot Doyle
> CC: Jani Nikula
Tested-bys on patches 3-4 would be awesome.
BR,
Jani.
> ---
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2855d29..2ac699b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12369,6 +12369,9 @@ static struct intel_quirk intel_quirks[] = {
>
> /* Acer C720 Chromebook has a controllable backlight */
> { 0x0a06, 0x1025, 0x0a11, quirk_backlight_present },
> +
> + /* Dell 11 Chromebook */
> + { 0x0a06, 0x1028, 0x0a35, quirk_backlight_present },
> };
>
> static void intel_init_quirks(struct drm_device *dev)
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness
On Fri, 27 Jun 2014, Jesse Barnes wrote:
> On Tue, 24 Jun 2014 18:27:40 +0300
> Jani Nikula wrote:
>
>> Historically we've exposed the full backlight PWM duty cycle range to
>> the userspace, in the name of "mechanism, not policy". However, it turns
>> out there are both panels and board designs where there is a minimum
>> duty cycle that is required for proper operation. The minimum duty cycle
>> is available in the VBT.
>>
>> The backlight class sysfs interface does not make any promises to the
>> userspace about the physical meaning of the range
>> 0..max_brightness. Specifically there is no guarantee that 0 means off;
>> indeed for acpi_backlight 0 usually is not off, but the minimum
>> acceptable value.
>>
>> Respect the minimum backlight, and expose the range acceptable to the
>> hardware as 0..max_brightness to the userspace via the backlight class
>> device; 0 means the minimum acceptable enabled value. To switch off the
>> backlight, the user must disable the encoder.
>>
>> As a side effect, make the backlight class device max brightness and
>> physical PWM modulation frequency (i.e. max duty cycle)
>> independent. This allows a follow-up patch to virtualize the max value
>> exposed to the userspace.
>>
>> Signed-off-by: Jani Nikula
>>
>> ---
>>
>> This version turned out uglier than I anticipated because the requests
>> through opregion in range 0..255 already have the minimum limit bundled
>> in. Scaling that would be wrong. Ideas welcome.
>> ---
>> drivers/gpu/drm/i915/intel_drv.h | 5 +-
>> drivers/gpu/drm/i915/intel_opregion.c | 2 +-
>> drivers/gpu/drm/i915/intel_panel.c| 158
>> ++
>> 3 files changed, 146 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 5f7c7bd94d90..2651e2ff7c05 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -165,6 +165,7 @@ struct intel_panel {
>> struct {
>> bool present;
>> u32 level;
>> +u32 min;
>> u32 max;
>> bool enabled;
>> bool combination_mode; /* gen 2/4 only */
>> @@ -948,8 +949,8 @@ void intel_pch_panel_fitting(struct intel_crtc *crtc,
>> void intel_gmch_panel_fitting(struct intel_crtc *crtc,
>>struct intel_crtc_config *pipe_config,
>>int fitting_mode);
>> -void intel_panel_set_backlight(struct intel_connector *connector, u32 level,
>> - u32 max);
>> +void intel_panel_set_backlight_acpi(struct intel_connector *connector,
>> +u32 level, u32 max);
>> int intel_panel_setup_backlight(struct drm_connector *connector);
>> void intel_panel_enable_backlight(struct intel_connector *connector);
>> void intel_panel_disable_backlight(struct intel_connector *connector);
>> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
>> b/drivers/gpu/drm/i915/intel_opregion.c
>> index 2e2c71fcc9ed..5a979b70e3cf 100644
>> --- a/drivers/gpu/drm/i915/intel_opregion.c
>> +++ b/drivers/gpu/drm/i915/intel_opregion.c
>> @@ -418,7 +418,7 @@ static u32 asle_set_backlight(struct drm_device *dev,
>> u32 bclp)
>> */
>> DRM_DEBUG_KMS("updating opregion backlight %d/255\n", bclp);
>> list_for_each_entry(intel_connector, &dev->mode_config.connector_list,
>> base.head)
>> -intel_panel_set_backlight(intel_connector, bclp, 255);
>> +intel_panel_set_backlight_acpi(intel_connector, bclp, 255);
>> iowrite32(DIV_ROUND_UP(bclp * 100, 255) | ASLE_CBLV_VALID, &asle->cblv);
>>
>> drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c
>> b/drivers/gpu/drm/i915/intel_panel.c
>> index 38a98570d10c..4924c5e07b07 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -398,6 +398,69 @@ intel_panel_detect(struct drm_device *dev)
>> }
>> }
>>
>> +/**
>> + * scale - scale values from one range to another
>> + *
>> + * @source_val: value in range [@source_min..@source_max]
>> + *
>> + * Return @source_val in range [@source_min..@source_max] scaled to range
>> + * [@target_min..@target_max].
>> + */
>> +static uint32_t scale(uint32_t source_val,
>> + uint32_t source_min, uint32_t source_max,
>> + uint32_t target_min, uint32_t target_max)
>> +{
>> +uint64_t target_val;
>> +
>> +BUG_ON(source_min > source_max);
>> +BUG_ON(target_min > target_max);
>> +
>> +/* defensive */
>> +source_val = clamp(source_val, source_min, source_max);
>> +
>> +/* avoid overflows */
>> +target_val = (uint64_t)(source_val - source_min) *
>> +(target_max - target_min);
>> +do_div(target_val, source_max - source_min);
>> +target_val += target_min;
>> +
>> +return target_val;
>> +}
>> +
>> +/* Scale user_level in range [0
Re: [Intel-gfx] drm/i915 KMS regression in Linux 3.16-rc2 (with git bisect result)
>> There seems to be a regression in the upcoming Linux 3.16-rc2 release >> candidate that I bisected down to this first bad commit: >> [dbb42748ac4929987c1449ecb296b39ef8956b62] drm/i915: Move the C3 LP >> write bit setup to gen3_init_clock_gating() for KMS. > > Can you attach the dmesg with rc2 and dbb4274 reverted? Hmm, for some reason I started having a hard time reproducing the issue on commit dbb4274. I still have it on the 3.16-rc2 though and I'm doing another bisect. The issue comes and goes during the bisect so let's see where it leads... perhaps it turns out to be some configuration setting. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
