Hi Doug,
On 16.09.2015 23:04, Doug Anderson wrote:
> Hi,
>
> On Sun, Aug 30, 2015 at 2:34 PM, Vladimir Zapolskiy
> wrote:
>> The change adds support of internal HDMI I2C master controller, this
>> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>>
>> The main purpose of th
On Wed, Sep 16, 2015 at 01:09:54PM -0700, Daniel Vetter wrote:
> On Tue, Sep 15, 2015 at 10:03:09AM -0700, Rafael Antognolli wrote:
> > On Tue, Sep 15, 2015 at 07:46:55PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 15, 2015 at 07:41:06PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 15, 201
Fix the following 'make htmldocs' warning:
.//include/drm/drm_crtc.h:929: warning: Excess struct/union/enum/typedef
member 'base' description in 'drm_bridge'
Signed-off-by: Geliang Tang
---
include/drm/drm_crtc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/inc
On Wed, Sep 16, 2015 at 02:56:57PM -0700, Doug Anderson wrote:
> Yes, I'd expect 100kHz and 400kHz.
>
> I agree that 50ms is non-trivial, but it's also not something you're
> doing lots of. I'd expect that the EDID is read over this channel at
> cable plugin time and then not used much after that
BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be applied before Color Transformation.
This patch does the following:
1. Adds the core function to program DeGamma correction values for
BDW/SKL/BXT platform
2
I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.
This patch adds the no of coefficients(65) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.
Signed-off-by: Shashank Sharma
---
BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit mode
3. 10-bit Split Gamma mode
4. 12-bit mode
This patch does the following:
1. Adds the core function to program Gamma correction values
for BDW/SKL/BXT platforms
2. Adds Gamma correction ma
I915 color manager registers pipe gamma correction as palette
correction after CTM property.
For BDW and higher platforms, split gamma correction is the best
gamma correction. This patch adds the no of coefficients(512) for
split gamma correction as "num_samples_after_ctm" parameter in device
info
Function intel_attach_color_properties_to_crtc attaches a
color property to its CRTC object. This patch calls this
function from crtc initialization sequence.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_
The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros
Signed-of
CHV/BSW supports DeGamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
CHV/BSW platform
2.
From: Kausal Malladi
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode
This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Add
DRM color manager allows the driver to showcase its best color
correction capabilities using the cm_crtc_palette_capabilities_property.
This patch adds no of coefficitents for degamma color correction
modes possible in CHV, in device info structure, which is:
CGM Degamma(10 bit, CGM HW unit):- 65
DRM color manager allows the driver to showcase its best color
correction capabilities using the cm_crtc_palette_capabilities_property.
Driver loads the no. of coefficients for various color correction
as per the platform, during the init time.
This patch adds no of coefficitents for best gamma co
This patch adds set_property and get_property handlers for pipe
level CSC color correction for CHV/BSW platform. The set
function just attaches the CSC blob to CRTC state, that later
gets committed using atomic path.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/d
This patch adds set_property and get_property handlers for deGamma
color correction capability at Pipe level.
Set function just attaches the deGamma correction blob to CRTC state, which
will be later committed in the atomic commit path.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Mallad
I915 driver registers gamma correction as palette correction
property with DRM layer. This patch adds set_property() and get_property()
handlers for pipe level gamma correction.
The set function attaches the Gamma correction blob to CRTC state, these
values will be committed during atomic commit.
DRM color manager contains these color properties:
1. "crtc_palette_capabilities_property": to allow a
core driver to load and showcase its color correction
capabilities to user space.
2. "ctm": Color transformation matrix property, where a
color transformation matrix of 9 correction values gets
a
From: Kausal Malladi
This patch create new files intel_color_manager.c which
will contain the core color correction code for I915 driver
and its header intel_color_manager.h
The per color property patches coming up in this patch series
will fill the appropriate functions in this file.
Signed-of
From: Kausal Malladi
This patch adds atomic get property interface for Intel CRTC. This
interface will be used for get operation on any non-core DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c | 9 +
drivers/gpu/drm
From: Kausal Malladi
This patch adds atomic set property interface for Intel CRTC. This
interface will be used for set operation on any DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_atomic.c | 9 +
drivers/gpu/drm/i915/int
From: Kausal Malladi
Color Manager framework defines a color correction property for color
space transformation and Gamut mapping. This property is called CTM (Color
Transformation Matrix).
This patch adds a new structure in DRM layer for CTM.
This structure can be used by all user space agents
From: Kausal Malladi
This patch adds new structures in DRM layer for Palette color
correction.These structures will be used by user space agents
to configure appropriate number of samples and Palette LUT for
a platform.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/
From: Kausal Malladi
This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
From: Kausal Malladi
The DRM color management framework is targeting various hardware
platforms and drivers. Different platforms can have different color
correction and enhancement capabilities.
A commom user space application can query these capabilities using the
DRM property interface. Each d
From: Kausal Malladi
Color Management is an extension to Kernel display framework. It allows
abstraction of hardware color correction and enhancement capabilities by
virtue of DRM properties.
This patch initializes color management framework by :
1. Introducing new pointers in DRM mode_config st
This patch set adds Color Manager implementation in DRM layer. Color Manager
is an extension in DRM framework to support color correction/enhancement.
Various Hardware platforms can support several color correction capabilities.
Color Manager provides abstraction of these capabilities and allows a
If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
Hi
On Wed, Sep 16, 2015 at 5:03 PM, Thomas Hellstrom
wrote:
> Hi, David,
>
> On 09/16/2015 04:35 PM, David Herrmann wrote:
>> Hi
>>
>> On Tue, Sep 15, 2015 at 10:11 AM, Thomas Hellstrom
>> wrote:
>>> This should be harmless.
>>> Vmware will, due to old infrastructure reasons, be using a privile
On 16.09.2015 11:56, Andrzej Hajda wrote:
> Ping.
>
> Regards
> Andrzej
>
> On 08/07/2015 09:59 AM, Andrzej Hajda wrote:
>> The patch was generated using fixed coccinelle semantic patch
>> scripts/coccinelle/api/memdup.cocci [1].
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320
>>
>
From: Dave Airlie
In order to cache the EDID properly for tiled displays, we
need to retrieve it before we register the connector with
userspace, otherwise userspace can call get resources
and try and get the edid before we've even cached it.
This fixes some problems when hotplugging mst monitor
On Wed, Sep 16, 2015 at 11:05:11AM -0400, Eric Anholt wrote:
> Lucas Stach writes:
>
> > From: Christian Gmeiner
>
> > +static bool etnaviv_validate_load_state(struct etnaviv_gpu *gpu, u32 *buf,
> > + unsigned int state, unsigned int num)
> > +{
> > + return true;
...
> > +}
>
> I was brow
isi_drm_fbdev.h
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150916/2b0517ac/attachment.html>
On Tue, 15 Sep 2015, Geliang Tang wrote:
> Fix the following 'make htmldocs' warnings:
>
> .//drivers/gpu/drm/i915/i915_gem_gtt.c:758: warning: No description found
> for parameter 'length'
> .//drivers/gpu/drm/i915/i915_gem_gtt.c:818: warning: No description found
> for parameter 'length'
>
On Tue, 15 Sep 2015, Geliang Tang wrote:
> Fix the following 'make htmldocs' warnings:
>
> .//drivers/gpu/drm/i915/intel_lrc.c:780: warning: No description found for
> parameter 'req'
> .//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function parameter
> 'request' description in 'in
Hi, David,
On 09/16/2015 04:35 PM, David Herrmann wrote:
> Hi
>
> On Tue, Sep 15, 2015 at 10:11 AM, Thomas Hellstrom
> wrote:
>> This should be harmless.
>> Vmware will, due to old infrastructure reasons, be using a privileged
>> control client to supply GUI layout information rather than obtaini
Hi
On Tue, Sep 15, 2015 at 10:11 AM, Thomas Hellstrom
wrote:
> This should be harmless.
> Vmware will, due to old infrastructure reasons, be using a privileged
> control client to supply GUI layout information rather than obtaining
> it from the device. That control client will be needing access
hi architt
On 2015/9/16 2:11, Rob Herring wrote:
> On 09/15/2015 04:37 AM, Xinwei Kong wrote:
>> This adds documentation of device tree bindings for the
>> Graphics Processing Unit of hi6220 SOC.
>>
>> Signed-off-by: Xinliang Liu
>> Signed-off-by: Xinwei Kong
>> Signed-off-by: Andy Green
>> Sig
Hi Xinwei,
Thanks for this contribution! We look forward to seeing support for
these devices.
This isn't an exhaustive review, but two very high-level comments
which should result in a lot of changes ...
On 15 September 2015 at 10:37, Xinwei Kong
wrote:
> 1. Hardware Detail
> The display subsy
On Wed, 16 Sep 2015, Rob Herring wrote:
> On 08/29/2015 06:01 PM, Rob Herring wrote:
> > Thomas,
> >
> > As requested, here are the remaining patches for killing off
> > set_irq_flags which have not been picked up. The rest of the
> > series has been picked up and are in -next.
>
> Thomas, ar
On Wed, Sep 16, 2015 at 3:52 PM, Pierre Moreau wrote:
> If the hardware supports extended tag field (8-bit ones), then enabled it.
> This
> is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
> In case extended tag field is not supported, 5-bit tag field is used which
> limits the
Op 14-09-15 om 21:43 schreef ville.syrjala at linux.intel.com:
> From: Ville Syrjälä
>
> Collect the timestamping constants alongside the rest of the relevant
> stuff under drm_vblank_crtc.
>
> We can now get rid of the 'refcrtc' parameter to
> drm_calc_vbltimestamp_from_scanoutpos().
>
> Signed
Hi,
On Wed, Sep 16, 2015 at 2:16 PM, Vladimir Zapolskiy
wrote:
> Hi Doug,
>
> On 03.09.2015 02:19, Doug Anderson wrote:
>> Russell,
>>
>> On Wed, Sep 2, 2015 at 4:04 PM, Russell King - ARM Linux
>> wrote:
> Also, is it appropriate to hook non-DDC devices to a DDC bus? I suspect
> that's
Vladimir,
On Wed, Sep 16, 2015 at 1:58 PM, Vladimir Zapolskiy
wrote:
>>> +static void dw_hdmi_i2c_init(struct dw_hdmi *hdmi)
>>> +{
>>> + /* Set Fast Mode speed */
>>> + hdmi_writeb(hdmi, 0x0b, HDMI_I2CM_DIV);
>>
>> If you're going to hardcode to something, it seems like hardcoding to
user/kernel API is sorted, this can be resolved.
OK. Validation code is painful to write, so I was just browsing what
was in here to see if I could pick up anything useful.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/
On 09/16/2015 02:31 PM, Joonyoung Shim wrote:
> G2D and IPP drivers get event time from do_gettimeofday(), but drm
> vblank event gets it from ktime. Use ktime for consistency.
Oops, this causes build errors, please ignore, i will retry.
Thanks.
>
> Signed-off-by: Joonyoung Shim
> ---
> drive
Hi,
On 09/16/2015 02:04 PM, Xinwei Kong wrote:
> hi architt
>
> On 2015/9/16 2:11, Rob Herring wrote:
>> On 09/15/2015 04:37 AM, Xinwei Kong wrote:
>>> This adds documentation of device tree bindings for the
>>> Graphics Processing Unit of hi6220 SOC.
>>>
>>> Signed-off-by: Xinliang Liu
>>> Signe
G2D and IPP drivers get event time from do_gettimeofday(), but drm
vblank event gets it from ktime. Use ktime for consistency.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 4 +++-
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 +++-
2 files changed, 6 insertions(+), 2
The beginning of statement in function is next line of a brace.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index
By if statment, some function callings are written twice. It needs
several line feed by indentation in if statment. Make to one function
calling from outside if statment.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 56 ++---
1 file chan
The exynos_drm_gem_init() is used only in exynos_drm_gem.c file. Make it
static and don't export it.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 +--
drivers/gpu/drm/exynos/exynos_drm_gem.h | 4
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/
They will be freed right or was freed already, so NULL assignment is
unnecessary.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
ind
Hi,
This patchset is small cleanup about exynos_drm_gem codes of exynos-drm
driver. This removes unnecessary and redundant codes, and staticize a
local function.
Thanks.
Joonyoung Shim (4):
drm/exynos: remove unnecessary NULL assignment
drm/exynos: staticize exynos_drm_gem_init()
There is no guarantee that DMA addresses are the same as physical
addresses, but dma_to_pfn() knows how to convert a dma_addr_t to a PFN
which can then be converted to a struct page.
Suggested-by: Russell King
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++-
1
When obj->import_attach is existed, code calling drm_prime_gem_destroy()
was removed from commit 67e93c808b48 ("drm/exynos: stop copying sg
table"), and it's a fault.
The drm_prime_gem_destroy() is cleanup function which GEM drivers need
to call when they use drm_gem_prime_import() to import dma-b
This eliminates the need for the "connectors" and "gpus" nodes in the
devicetree, which we were doing nothing connector- or gpu-specific
with.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/msm_drv.c | 65 +--
include/drm/drmP.h| 2 +-
2 f
This is a really nice way to handle the component setup. The
subsystem driver knows that it's got a bunch of component drivers, and
for any devices that matched its component drivers, it wants all of
those to bind to it as master.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_platform_help
This matches how exynos handles the registration of its component
drivers.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 12 +---
drivers/gpu/drm/msm/dsi/dsi.c | 16 +---
drivers/gpu/drm/msm/dsi/dsi.h | 2 --
drivers/gp
This is mostly just a move of the code from exynos, with a slight
reformat. I wanted to do a similar thing for vc4, and msm looks like
a good candidate as well.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/Makefile| 3 ++-
drivers/gpu/drm/drm_platform_helpers.c | 45
I had previously modeled vc4 off of msm's component driver
registration, but on further investigation exynos has an even cleaner
way of doing it. Here's a series to turn exynos's style into core
helpers, and use it from msm.
The patches are build tested, but I don't have either of the platforms
t
On Wed, Sep 16, 2015 at 11:47:21PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 16, 2015 at 01:09:54PM -0700, Daniel Vetter wrote:
> > On Tue, Sep 15, 2015 at 10:03:09AM -0700, Rafael Antognolli wrote:
> > > On Tue, Sep 15, 2015 at 07:46:55PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 15, 201
There's a member in 'struct dw_hdmi' called cable_plugin. It's never
set to anything anywhere so thus is always false. There's a bit of code
checking it, but since it's always false this must be dead code.
Eliminate it.
Note: if someone wants to figure out the intention of the original code
and
On Tue, 15 Sep 2015, Lucas Tanure wrote:
> Hi,
>
> I would like to start to contribute to drm part of kernel. I tried a few
> things:
>
> - Compiled linux-next tree using C=1 (sparse) to find things to improve.
> But couldn't find any problem or issue.
> - I looked in "www.x.org/wiki/DRMJanitors/"
On Wed, Sep 16, 2015 at 04:23:35PM +0100, Daniel Stone wrote:
> The biggest issue though, is that this driver should become an atomic
> modesetting driver. Atomic modesetting, rather than sending small
> individual commands (enable CRTC, change plane position, etc) is based
> on validating and pass
On Tue, Sep 15, 2015 at 10:03:09AM -0700, Rafael Antognolli wrote:
> On Tue, Sep 15, 2015 at 07:46:55PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 15, 2015 at 07:41:06PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 15, 2015 at 09:34:15AM -0700, Rafael Antognolli wrote:
> > > > On Tue, Sep 15,
On Tue, Sep 15, 2015 at 07:57:19PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 15, 2015 at 09:27:27AM -0700, Rafael Antognolli wrote:
> > On Tue, Sep 15, 2015 at 10:46:43AM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 14, 2015 at 04:12:30PM -0700, Rafael Antognolli wrote:
> > > > This list will
Hi,
On Sun, Aug 30, 2015 at 2:34 PM, Vladimir Zapolskiy
wrote:
> The change adds support of internal HDMI I2C master controller, this
> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>
> The main purpose of this functionality is to support reading EDID from
> an HDMI monit
2015-09-16 10:04 GMT+02:00 Russell King - ARM Linux :
> On Fri, Sep 11, 2015 at 04:10:13PM +0200, Lucas Stach wrote:
>> From: Christian Gmeiner
>>
>> This is a squashed commit of the complete etnaviv DRM driver in order
>> to make it easy for people to review the code by seeing the driver as a
>>
On Wed, Sep 16, 2015 at 11:14 AM, Eric Anholt wrote:
> This is mostly just a move of the code from exynos, with a slight
> reformat. I wanted to do a similar thing for vc4, and msm looks like
> a good candidate as well.
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/Makefile
On Tue, Aug 25, 2015 at 12:35 PM, Rob Clark wrote:
> Convert fb-helper, or at least the two code-paths which potentially
> trigger more than a single update, to use atomic API if the driver
> supports it.
>
> The first patch is slightly unrelated, but I needed to add kerneldoc
> for 'struct drm_fb
Ping.
Regards
Andrzej
On 08/07/2015 09:59 AM, Andrzej Hajda wrote:
> The patch was generated using fixed coccinelle semantic patch
> scripts/coccinelle/api/memdup.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/a
* Archit Taneja wrote:
> From: Archit Taneja
> Date: Mon, 14 Sep 2015 20:11:43 +0530
> Subject: [PATCH] drm/mgag200: Prevent calling drm_fb_helper_fini twice
>
> mgag200_fbdev_init's error handling path calls drm_fb_helper_fini before
> bailing out. The error handling path of mgag200_driver_lo
Am Mittwoch, den 16.09.2015, 09:04 +0100 schrieb Russell King - ARM
Linux:
> On Fri, Sep 11, 2015 at 04:10:13PM +0200, Lucas Stach wrote:
> > From: Christian Gmeiner
> >
> > This is a squashed commit of the complete etnaviv DRM driver in
> > order
> > to make it easy for people to review the code
hi rob
On 2015/9/16 2:25, Rob Herring wrote:
> On 09/15/2015 04:37 AM, Xinwei Kong wrote:
>> If you config DRM_HISI_FBDEV optional, this patch will only support fbdev
>> mode while also supporting double buffer.
>
> This is a lot of duplicated code from CMA fbdev. Is double buffering the
> only r
Am Mittwoch, den 16.09.2015, 08:11 +0200 schrieb Christian Gmeiner:
> Hi Lucas
>
>
> 2015-09-11 16:10 GMT+02:00 Lucas Stach :
> > From: Christian Gmeiner
> >
> > This is a squashed commit of the complete etnaviv DRM driver in
> > order
> > to make it easy for people to review the code by seeing
From: Dave Airlie
output ports should always have a connector, unless
in the rare case connector allocation fails in the
driver.
In this case we only need to teardown the pdt,
and free the struct, and there is no need to
send a hotplug msg.
In the case were we add the port to the destroy
list w
From: Dave Airlie
This is unnecessary and it makes it easier to see what is needed
from port.
also add blank line to make things nicer.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu
> +}
I was browsing the code, and noticed that it looks like you've got a
debugging early return in your validation function here.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150916/e05ca0b4/attachment-0001.sig>
On Wed, Sep 16, 2015 at 11:06:59PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> The DRM color management framework is targeting various hardware
> platforms and drivers. Different platforms can have different color
> correction and enhancement capabilities.
>
> A commom user space ap
On Wed, Sep 16, 2015 at 11:06:58PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi
>
> Color Management is an extension to Kernel display framework. It allows
> abstraction of hardware color correction and enhancement capabilities by
> virtue of DRM properties.
>
> This patch initializes co
From: Dave Airlie
I suspect we might need to rethink when we send hotplug callback
but this at least stops us from sending them when we defintely
don't need to.
DP input port state changes aren't necessary to report.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++
On 16 September 2015 at 02:41, Oleg Nesterov wrote:
> ping ;)
>
> Andrew, should I re-send this patch? It was acked by Daniel and Dave
> doesn't object.
>
> Dave, I'll appreciate it if you ack it explicitly.
>
>
> On 08/27, Oleg Nesterov wrote:
>>
>> It is hardly possible to enumerate all problems
On 08/29/2015 06:01 PM, Rob Herring wrote:
> Thomas,
>
> As requested, here are the remaining patches for killing off
> set_irq_flags which have not been picked up. The rest of the
> series has been picked up and are in -next.
Thomas, are you going to pick up these remaining patches?
Rob
>
On Fri, Sep 11, 2015 at 04:10:13PM +0200, Lucas Stach wrote:
> From: Christian Gmeiner
>
> This is a squashed commit of the complete etnaviv DRM driver in order
> to make it easy for people to review the code by seeing the driver as a
> whole and is not intended for merging in this form.
>
> If
On Mon, Sep 14, 2015 at 09:16:01AM -0400, Rob Clark wrote:
> On Fri, Sep 11, 2015 at 10:10 AM, Lucas Stach
> wrote:
> > From: Christian Gmeiner
> >
> > This is a squashed commit of the complete etnaviv DRM driver in order
> > to make it easy for people to review the code by seeing the driver as
On Wed, Sep 16, 2015 at 08:11:54AM +0200, Christian Gmeiner wrote:
> Hi Lucas
>
>
> 2015-09-11 16:10 GMT+02:00 Lucas Stach :
> > From: Christian Gmeiner
> >
> > This is a squashed commit of the complete etnaviv DRM driver in order
> > to make it easy for people to review the code by seeing the d
Hi Lucas
2015-09-11 16:10 GMT+02:00 Lucas Stach :
> From: Christian Gmeiner
>
> This is a squashed commit of the complete etnaviv DRM driver in order
> to make it easy for people to review the code by seeing the driver as a
> whole and is not intended for merging in this form.
>
> If you are int
On Mon, Sep 14, 2015 at 8:22 AM, Daniel Vetter
wrote:
> Hi Dave,
>
> -rc1 is out the door and here's my first pull request for drm-next. It's
> all over:
> - better atomic helpers for runtime pm drivers
> - atomic fbdev
David Herrmann just pointed out to me that atomic fbdev isn't actually
in th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alan Coopersmith (1):
Include when needed before calling alloca
Christian König (2):
amdgpu: remove sequence mutex
amdgpu: serialize drmPrimeFDToHandle
Emil Velikov (20):
drm: add interface to get drm devices on
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150916/61d2a9d6/attachment-0001.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150916/94054042/attachment.html>
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150916/d6cf5dbf/attachment.html>
94 matches
Mail list logo
