On Mon, Jul 03, 2017 at 08:41:53PM +0530, Shashank Sharma wrote:
> CEA-861-F introduces extended tag codes for EDID extension blocks,
> which indicates the actual type of the data block. The code for
> using exteded tag is 0x7, whereas in the existing code, the
> corresponding macro is named as
On Tue, Jun 27, 2017 at 10:29:33PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Tue, 2017-06-27 at 16:23 +0300, David Weinehall wrote:
> > On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote:
> > > On Thu, Jun 22, 2017 at 12:03:39PM -0700, P
On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote:
> On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> > This patch adds option to enable dynamic backlight for eDP
> > panel that supports this feature via DPCD register and
> > set minimum
On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> This patch adds option to enable dynamic backlight for eDP
> panel that supports this feature via DPCD register and
> set minimum / maximum brightness to 0% and 100% of the
> normal brightness.
This patch causes a
On Mon, Nov 14, 2016 at 12:44:25PM +0200, Jani Nikula wrote:
> On Thu, 06 Oct 2016, Tomeu Vizoso wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 23a6c7213eca..7412a05fa5d9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> >
int we have everything else we
> need for polling enabled.
>
> As well, this should result in a rather significant improvement in how
> quickly we can resume the system.
>
> Signed-off-by: Lyude
> Cc: David Weinehall
Tested-by: David Weinehall
Reviewed-by: David Weineh
resuming just yet since now the
> bottleneck will be waiting for the mode_config lock in
> drm_kms_helper_poll_enable(), since that will be held as long as
> i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> address that in the next patch.
>
> Signed-off-by: Ly
On Thu, Oct 20, 2016 at 03:28:10PM +0300, Jani Nikula wrote:
> On Thu, 20 Oct 2016, Nicolae Rosia wrote:
> > Monitor hotplugging seems to be broken on latest 4.1/4.4 RT kernel with
> > i915.
> > I have tested this on non-RT kernel and it works.
The answer to your first question seems to be here
ses, and performance
improvements).
If we were asking for support for software you develop, you'd obviously
be the one to set the rules (and yes, that includes your TODO tracker,
closed forums or what not). Reporting bugs in a bug tracking system
isn't exactly a novelty. Rather the opposite.
Kind regards, David Weinehall
>
> Caught by coverity.
>
> Signed-off-by: Imre Deak
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_
On Fri, Jan 29, 2016 at 02:44:28PM +0200, Imre Deak wrote:
> Otherwise this call would have no effect.
>
> Caught by Coverity.
>
> Signed-off-by: Imre Deak
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
> 1 file changed, 3 i
A new parameter was recently added to the i915 GEM contexts.
Add its define to i915_drm.h.
Signed-off-by: David Weinehall
---
include/drm/i915_drm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1cb117..a658d1cc367a 100644
Add helper functions to set/get GEM context parameters.
Signed-off-by: David Weinehall
---
intel/intel_bufmgr.h | 4
intel/intel_bufmgr_gem.c | 57
2 files changed, 61 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel
This patch contains a few minor updates related to
I915 GEM context.
David Weinehall (2):
intel: Add get/set context parameter helpers
Add the I915_CONTEXT_PARAM_NO_ZEROMAP parameter
include/drm/i915_drm.h | 1 +
intel/intel_bufmgr.h | 4
intel/intel_bufmgr_gem.c | 57
state);
It'd probably make sense to fix all code that uses
drm_atomic_state_free() at the same time.
Regards, David Weinehall
On Fri, Feb 27, 2015 at 08:23:41PM +0200, Imre Deak wrote:
> We've checked today with Ville a few machines we've found from GEN2 to
> GEN5+. There was one Thinkpad x61s (GEN4) where I could reproduce the
> exact same problem and get rid of it using the same workaround. All the
> others were
impact machines using gen4
that *don't* have a buggy BIOS? Wouldn't a quirk tied to the laptop
or BIOS version be better suited -- or possibly a parameter that can be
passed to the driver, which would make it easier to test if others
suffering from similar symptoms on other systems suffer from the same
issue or not?
Just my 2¢.
Kind regards, David Weinehall
17 matches
Mail list logo
