On 7/2/2015 6:35 PM, Jani Nikula wrote:
Add an overview of the drm/i915 hotplug handling.
Signed-off-by: Jani Nikula
---
Documentation/DocBook/drm.tmpl | 5 +
drivers/gpu/drm/i915/intel_hotplug.c | 39
2 files changed, 44 insertions(+)
diff
On 7/3/2015 6:27 PM, Ville Syrjälä wrote:
On Fri, Jul 03, 2015 at 02:35:49PM +0300, Mika Kahola wrote:
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The req
Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
Handle it only if hpd has actually occurred like we handle other
interrupts.
Signed-off-by: Sonika Jindal
---
Hi,
I see we don't check for hotplug_trigger before processing the HPD for any of
the platform. Is there any reason for t
For dual link panel scenarios there are new fileds added in the
VBT which indicate on which port the PWM cntrl and CABC ON/OFF
commands needs to be sent.
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/intel_bios.c | 13 +
drivers/gpu/drm/i915/intel_bios.h |5 -
drivers/gp
CABC stands for the Content Adaptive Backlight Control.
In the normal display the backlight which we see is due to the
backlight which is being modulated by the filter, which is inturn
dependent on the image. In brief the CABC does the histogram
analysis of the image and then controls the filter an
In CABC (Content Adaptive Brightness Control) content grey level
scale can be increased while simultaneously decreasing
brightness of the backlight to achieve same perceived brightness.
The CABC is not standardized and panel vendors are free to follow
their implementation. The CABC implementaion h
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_bios.c |2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1dbd957..1d30cb7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
On Sun, Jul 05, 2015 at 06:49:02PM +0200, Lukas Wunner wrote:
> Hi Chris,
>
> thank you for the quick response (on a weekend no less).
>
>
> On Sat, Jul 04, 2015 at 01:31:48PM +0100, Chris Wilson wrote:
> > > - return intel_framebuffer_create(dev, &mode_cmd, obj);
> > > + fb = intel_framebuffer_
Currently when allocating a framebuffer fails, the gem object gets
unrefed at the bottom of the call chain in __intel_framebuffer_create,
not where it gets refed, which is in intel_framebuffer_create_for_mode
(via i915_gem_alloc_object) and in intel_user_framebuffer_create
(via drm_gem_object_looku
From: Tvrtko Ursulin
We had two failure modes here:
1.
Deadlock in intelfb_alloc failure path where it calls
drm_framebuffer_remove, which grabs the struct mutex and intelfb_create
(caller of intelfb_alloc) was already holding it.
2.
Deadlock in intelfb_create failure path where it calls
drm_fr
Hi Chris,
thank you for the quick response (on a weekend no less).
On Sat, Jul 04, 2015 at 01:31:48PM +0100, Chris Wilson wrote:
> > - return intel_framebuffer_create(dev, &mode_cmd, obj);
> > + fb = intel_framebuffer_create(dev, &mode_cmd, obj);
> > + if (IS_ERR(fb))
> > + drm_g
11 matches
Mail list logo
