he bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160222/8626ba26/attachment.html>
Hi Phillipp,
On Mon, 22 Feb 2016 17:12:27 +0100, Philipp Zabel wrote:
> Am Montag, den 22.02.2016, 14:14 + schrieb John Keeping:
> > Is there a reason why endpoints in a device tree graph can't be
> > disabled?
>
> You can always remove them using /delete-node/, which also has the
> advanta
||g/show_bug.cgi?id=94232
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160222/833c8
ou are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160222/22593699/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160222/7c76dcf0/attachment.html>
These warnings still seem to be present with DP MST configurations. They
don't actually indicate any impending doom, so we may as well use
I915_STATE_WARN_ON() here to help quiet things down a little bit for
distro kernel users.
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1
On Mon, Feb 22, 2016 at 5:07 AM, Archit Taneja
wrote:
>
>
> On 02/22/2016 08:24 AM, Rob Herring wrote:
>>
>> On Mon, Feb 15, 2016 at 12:23:26PM +0530, Archit Taneja wrote:
>>>
>>> Add HDMI PHY bindings. Update the example to use HDMI PHY.
>>>
>>> Add a missing power-domains property in the HDMI c
From: Christian König
A fence is never later than itself. This caused a bunch of overhead for AMDGPU.
v2: simplify check as suggested by Michel.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
---
include/linux/fence.h | 2
Hi Dave -
Here's the display power stuff that Daniel and I were a bit hesitant to
queue to v4.5 at this late stage, but since you said, "looks fairly self
contained, if it make skylake suck less I'm all for it", here goes.
Most of the commits are quite similar, ensuring the display power
doesn't
On Mon, Feb 22, 2016 at 1:19 AM, Archit Taneja
wrote:
>
>
> On 02/22/2016 08:23 AM, Rob Herring wrote:
>>
>> On Mon, Feb 15, 2016 at 06:30:59PM +0530, Archit Taneja wrote:
>>>
>>> The DSI driver is currently unaware of how the DSI clock and data pins
>>> are mapped to the logical lanes provided b
Hi Mehul,
On Mon, Feb 22, 2016 at 05:58:10PM +0530, Mehul Sawarkar wrote:
> I am Mehul Sawarkar from India .I want to be part of X.Org during GSoC
> 2016.I know C/C++.Please help me getting started with some easy task you
> might have in mind.What are some of prospective project ideas for GSoC 201
I saw some regressions on today's Linux-next kernel after
the Makefiles got reworked and tried to come up with a quick
fix. This ended up taking much longer, but the new version should
be cleaner and I no longer get any build errors in this
driver.
The first two patches are just preparation to avo
Global symbols in the kernel should be prefixed by the name
of the subsystem and/or driver to avoid conflicts when all
code is built-in.
In this case, function names like 'hdmi_register' or 'hdmi_set_mode'
are way too generic for an MSM specific DRM driver, so I'm renaming
them all to msm_hdmi_* h
msm.ko is not an appropriate name for a module that drives a specific
device on the msm platform. This changes the name to drm_msm.ko
to have something that won't conflict with any other module name.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/msm/Makefile | 12 ++--
1 file changed,
This is a preparation for having edp, dsi and hdmi in separate
modules. Those three drivers depend on the iotrace code and,
and edp depends on gem, which in turn depends on the fence.
With this change, those two pieces of the main driver can be
loaded first, to resolve circular dependencies.
Sign
The GEM code is used by dsi, so it can't be part of
the main module. This exports all functions that are called
by other code, and puts it into the helper module.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/msm/Makefile | 3 +--
drivers/gpu/drm/msm/msm_gem.c | 29 +
Moving around the Makefile for DSI caused a link error with
the main driver referring to a builtin module that has no
exported symbols:
drivers/gpu/built-in.o: In function `msm_drm_register':
:(.init.text+0x654): undefined reference to `msm_dsi_register'
This changes the DSI symbol to a 'tristate
Moving around the Makefile for EDP caused a link error with
the main driver referring to a builtin module that has no
exported symbols:
drivers/gpu/built-in.o: In function `msm_drm_register':
:(.init.text+0x654): undefined reference to `msm_edp_register'
This changes the EDP symbol to a 'tristate
The msm driver currently has a single module_init() function but
consists of multiple modules that each register a platform driver.
This changes the msm_drm_register() function to not call the
other functions but instead rely on module load order and/or
link order to ensure that the other modules
Moving around the Makefile for HDMI caused a link error with
the main driver referring to a builtin module that has no
exported symbols:
drivers/gpu/built-in.o: In function `msm_drm_register':
:(.init.text+0x654): undefined reference to `msm_hdmi_register'
This changes the EDP symbol to a 'trista
The fsl-dcu driver copies a drm_mode_config object to its
stack but then only accesses a single member (dpms_property)
once. The data structure is large enough to trigger a warning
about the amount of kernel stack being used:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c: In function
'fsl_dcu_drm_con
On Mon, Feb 22, 2016 at 4:08 PM, Arnd Bergmann wrote:
> I saw some regressions on today's Linux-next kernel after
> the Makefiles got reworked and tried to come up with a quick
> fix. This ended up taking much longer, but the new version should
> be cleaner and I no longer get any build errors in
On Monday 22 February 2016 17:36:36 Rob Clark wrote:
> On Mon, Feb 22, 2016 at 4:08 PM, Arnd Bergmann wrote:
> > I saw some regressions on today's Linux-next kernel after
> > the Makefiles got reworked and tried to come up with a quick
> > fix. This ended up taking much longer, but the new version
s scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160222/1a9600b2/attachment.html>
ts.freedesktop.org/archives/dri-devel/attachments/20160222/c061aadb/attachment.html>
On Mon, Feb 22, 2016 at 02:18:07PM +, Lionel Landwerlin wrote:
> The moves a couple of functions programming the gamma LUT and CSC
> units into their own file.
>
> On generations prior to Haswell there is only a gamma LUT. From
> haswell on there is also a new enhanced color correction unit th
On Mon, Feb 22, 2016 at 02:18:08PM +, Lionel Landwerlin wrote:
> Implement Daniel Stone's recommendation to not read registers to infer
> the hardware's state.
>
> Signed-off-by: Lionel Landwerlin
Do we need to ensure that software and hardware state are synchronized
at startup? A boot firm
On Mon, Feb 22, 2016 at 02:18:10PM +, Lionel Landwerlin wrote:
> Patch based on a previous series by Shashank Sharma.
>
> v2: Do not read GAMMA_MODE register to figure what mode we're in
>
> v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0
>
> Add documentation on how the Broadcas
From: Christian König
A fence is never later than itself. This caused a bunch of overhead for AMDGPU.
v2: simplify check as suggested by Michel.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
---
include/linux/fence.h | 2
The event_data passed from pem_fini was not cleared upon initialization.
This caused NULL checks to pass and cast_const_phw_tonga_power_state to
attempt to dereference an invalid pointer. Clear the event_data in
pem_init and pem_fini before calling pem_handle_event.
Signed-off-by: Bradley Pankow
101 - 130 of 130 matches
Mail list logo
