https://bugs.freedesktop.org/show_bug.cgi?id=101675
Bug ID: 101675
Summary: Peace, Death! crashed on start-up
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Prior
Am 01.07.2017 um 11:47 schrieb Arvind Yadav:
drm_prop_enum_lists are not supposed to change at runtime. All functions
working with drm_prop_enum_list provided by work with
const drm_prop_enum_list. So mark the non-const structs as const.
File size before:
text data bss dec
Am 02.07.2017 um 11:06 schrieb Arvind Yadav:
ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by work
with const ttm_place. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
9235
Am 02.07.2017 um 11:13 schrieb Arvind Yadav:
ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by work
with const ttm_place. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
Reviewed-by: Christian König
---
drivers/gpu/drm/
https://bugs.freedesktop.org/show_bug.cgi?id=101675
--- Comment #1 from Timothy Arceri ---
Note LLVM crashes at a different point, and running in valgrind the game starts
up correctly.
--
You are receiving this mail because:
You are the assignee for the bug._
This patch moves of_drm_find_bridge call into probe.
It doesn't need to call of_drm_find_bridge function every time
bind callback is called. It's enough to call this funcation
at probe one time.
Suggested-by: Inki Dae
Signed-off-by: Shuah Khan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exyno
This patch series cleans up bridge binding of DSI and MIC driver.
It doesn't have to call of_drm_find_bridge function every time
bind callback of DSI driver is called so moves this function call
into probe function and for this support it adds a bridge
at probe function of MIC driver instead of ad
This patch moves drm_bridge_add call into probe.
This change is required by DSI driver so that
the brige can be bound at DSI driver's probe.
Suggested-by: Andrzej Hajda
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 17 ++---
1 file changed, 10 insertions(+),
On Fri, Jun 30, 2017 at 09:46:36PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 30, 2017 at 08:23:58PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
> > wrote:
> > >> And if the GEM folks insist the old behavior can't be restored, then we
> > >> just need a tailor-mad
On Fri, Jun 30, 2017 at 5:39 PM, Chris Wilson wrote:
>> Yeah, but my point is that this here is an extremely fancy and fragile
>> (and afaics in this form, incomplete) fix for something that in the past
>> was fixed much, much simpler. Why do we need this massive amount of
>> complexity now? Who's
On Fri, Jun 30, 2017 at 03:03:17PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> In some cases, like cursor updates, it is interesting to update the
> plane in an asynchronous fashion to avoid big delays. The current queued
> update could be still waiting for a fence to signal and thu
On Sat, Jul 01, 2017 at 06:06:46PM +0530, Arvind Yadav wrote:
> dma_buf_ops are not supposed to change at runtime. All functions
> working with dma_buf_ops provided by work with
> const dma_buf_ops. So mark the non-const structs as const.
>
> File size before:
>text data bss
On Sun, Jul 02, 2017 at 10:52:43PM +0100, Mark Cave-Ayland wrote:
> The current drm_fb_helper_sys helpers referenced in fb_ops assume that the
> video memory is in system RAM. This is not the case for sparc which uses
> direct
> physical memory accesses for IO memory and causes the bochs_drm modul
Quoting Daniel Vetter (2017-07-03 09:03:36)
> On Fri, Jun 30, 2017 at 5:39 PM, Chris Wilson
> wrote:
> >> Yeah, but my point is that this here is an extremely fancy and fragile
> >> (and afaics in this form, incomplete) fix for something that in the past
> >> was fixed much, much simpler. Why do
Am Sonntag, den 02.07.2017, 12:04 +0200 schrieb Christian Gmeiner:
> 2017-06-26 14:56 GMT+02:00 Lucas Stach :
> > Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> >> Sadly we can not read any registers via command stream so we need
> >> to extend the drm_etnaviv_gem_submit struc
On 03/07/17 09:11, Daniel Vetter wrote:
> On Sun, Jul 02, 2017 at 10:52:43PM +0100, Mark Cave-Ayland wrote:
>> The current drm_fb_helper_sys helpers referenced in fb_ops assume that the
>> video memory is in system RAM. This is not the case for sparc which uses
>> direct
>> physical memory access
Op 30-06-17 om 14:46 schreef Daniel Vetter:
> On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
> With a real commit message (just explain why it's needed):
>
> Reviewed-by: Daniel Vetter
>
> Also needs
>
> Fixes: db8f6403e88a ("drm: Convert dr
This patch removes unnecessary checking of return value.
Ps. this patch depends on below one,
http://www.spinics.net/lists/dri-devel/msg145687.html
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
This patch series changes return type of drm_bridge_add
function to void one and also removes unnecessary checking
of the return type from relevant drivers.
Ps. I had just build test so each maintainer may need to check this.
Inki Dae (14):
drm/bridge: change return type of drm_bridge_add funct
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/bridge/analogix-anx78xx.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index 900
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index 831a606..8a
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ea
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0a4ffd7..62652ee 1006
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/bridge/sii902x.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 9b87067..b8d10e5 100644
--- a/d
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/bridge/tc358767.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 5c26488..12a35f9 100644
---
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/bridge/ti-tfp410.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index eee4efd..7ea2a15 100644
This patch changes return type of drm_bridge_add function.
This function never return negative value but returns only 0.
So it changes the return type of this function to void one.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/drm_bridge.c | 7 +--
include/drm/drm_bridge.h | 2 +-
2 files
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/bridge/parade-ps8622.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c
b/drivers/gpu/drm/bridge/parade-ps8622.c
index 6f22f9f..4f7
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/bridge/panel.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 99f9a4b..65ab28c 100644
--- a/drivers/
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/sti/sti_dvo.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 24ebc6b..dcc2c22 100644
--- a/drivers/gp
This patch removes unnecessary checking of return value.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 4f64e71..f0b5d0f 1
On Fri, Jun 30, 2017 at 08:13:58PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 6:51 PM, Liviu Dudau wrote:
> > Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
> > if no output is connected at framebuffer setup time, we get a default
> > 1024x768 mode that is going
This patch adds documentation of device tree bindings for the
Synopsys DesignWare MIPI DSI host controller.
Signed-off-by: Philippe CORNU
---
.../bindings/display/bridge/dw_mipi_dsi.txt| 32 ++
1 file changed, 32 insertions(+)
create mode 100644
Documentation/device
Version 5:
- bridge/synopsis/dw-mipi-dsi.c: Improve the direct call to panel
bridge post_disable() & related comments (Archit Taneja)
- stm/ltdc.c: fix leak of pixel clock enable in some error
paths (Eric Anholt)
- bindings/display/bridge/dw_mipi_dsi.txt: add pixel clock & remove
"driver" (Ro
Add the panel-bridge support for both panels & bridges (used by DSI host &
HDMI/LVDS bridges).
Signed-off-by: Philippe CORNU
Reviewed-by: Archit Taneja
---
drivers/gpu/drm/stm/Kconfig | 2 +-
drivers/gpu/drm/stm/ltdc.c | 210
drivers/gpu/drm/stm/l
This patch adds documentation of device tree bindings for the STM32 DSI
controller based on the Synopsys DesignWare MIPI DSI host controller.
Signed-off-by: Philippe CORNU
Reviewed-by: Neil Armstrong
Acked-by: Rob Herring
---
.../devicetree/bindings/display/st,stm32-ltdc.txt | 104 +++
Add the STM32 DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.
Signed-off-by: Philippe CORNU
Reviewed-by: Neil Armstrong
Reviewed-by: Archit Taneja
---
drivers/gpu/drm/stm/Kconfig | 7 +
drivers/gpu/drm/stm/Makefile | 2 +
drivers/
There is no need anymore to have a "st-display-subsystem" parent node
in the device tree for the ltdc.
Signed-off-by: Philippe CORNU
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/
The pixel clock gets enabled early during init, since it's required
in order to read registers. This pixel clock must be disabled if
errors during this init phase.
Signed-off-by: Eric Anholt
Acked-by: Philippe Cornu
---
drivers/gpu/drm/stm/ltdc.c | 10 ++
1 file changed, 6 insertions(+)
Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
Signed-off-by: Philippe CORNU
---
drivers/gpu/drm/bridge/synopsys/Kconfig | 6 +
drivers/gpu/drm/bridge/synopsys/Makefile | 2 +
drivers/gpu
On 06/28/17 00:16, Laurent Pinchart wrote:
> The CRTC .disable() helper operation is deprecated for atomic drivers,
> the new .atomic_disable() helper operation being preferred. Convert all
> atomic drivers to .atomic_disable() to avoid cargo-cult use of
> .disable() in new drivers.
>
> Signed-off
Hi,
> Hopefully Gerd has experience using bochs_drm with other non-x86
> systems
> and can comment further.
Just pushed to drm-misc-next, fix is correct. bochs video memory is a
pci bar, and the framebuffer is stored there.
Using sys instead of cfb is probably a leftover from cirrus, where th
On 06/28/17 00:16, Laurent Pinchart wrote:
> The old state is useful for drivers that need to perform operations at
> enable time that depend on the transition between the old and new
> states.
>
> While at it, rename the operation to .atomic_enable() to be consistent
> with .atomic_disable(), as
On 07/03/2017 08:31 AM, Archit Taneja wrote:
>
>
> On 06/29/2017 08:13 PM, Philippe CORNU wrote:
>>
>>
>> On 06/28/2017 08:44 AM, Archit Taneja wrote:
>>>
>>>
>>> On 06/19/2017 09:58 PM, Philippe CORNU wrote:
Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
Rock
Regards
Shashank
On 6/30/2017 5:24 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:03:59PM +0530, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support vid
On 03/07/17 09:55, Gerd Hoffmann wrote:
> Hi,
>
>> Hopefully Gerd has experience using bochs_drm with other non-x86
>> systems
>> and can comment further.
>
> Just pushed to drm-misc-next, fix is correct. bochs video memory is a
> pci bar, and the framebuffer is stored there.
>
> Using sys i
https://bugs.freedesktop.org/show_bug.cgi?id=101675
--- Comment #2 from Timothy Arceri ---
Yeah it's spewing out a bunch of various valgrind issues:
Conditional jump or move depends on uninitialised value
Mismatched free() / delete / delete []
Address 0x245c7100 is 0 bytes inside a bl
On Mon, Jul 03, 2017 at 09:55:48AM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 09:46:36PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 30, 2017 at 08:23:58PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
> > > wrote:
> > > >> And if the GEM folks insist
On Sun, 2017-07-02 at 13:11 +0530, Arvind Yadav wrote:
> ttm_place are not supposed to change at runtime. All functions
> working with ttm_place provided by work
> with const ttm_place. So mark the non-const structs as const.
>
> File size before:
> text data bss dec hex
Hi Inki,
On 3 July 2017 at 09:42, Inki Dae wrote:
> This patch changes return type of drm_bridge_add function.
>
> This function never return negative value but returns only 0.
> So it changes the return type of this function to void one.
>
This patch should be the final in the series. Otherwise
On Mon, Jul 03, 2017 at 02:36:58PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/30/2017 5:24 PM, Ville Syrjälä wrote:
> > On Wed, Jun 21, 2017 at 04:03:59PM +0530, Shashank Sharma wrote:
> >> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> >> For
On 03.07.2017 09:27, Inki Dae wrote:
> This patch moves of_drm_find_bridge call into probe.
>
> It doesn't need to call of_drm_find_bridge function every time
> bind callback is called. It's enough to call this funcation
> at probe one time.
>
> Suggested-by: Inki Dae
> Signed-off-by: Shuah Khan
On 03.07.2017 09:27, Inki Dae wrote:
> This patch moves drm_bridge_add call into probe.
>
> This change is required by DSI driver so that
> the brige can be bound at DSI driver's probe.
>
> Suggested-by: Andrzej Hajda
> Signed-off-by: Inki Dae
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
___
https://bugs.freedesktop.org/show_bug.cgi?id=100242
Nicolai Hähnle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
On 06/29/2017 04:09 PM, Andrzej Hajda wrote:
On 29.06.2017 07:03, Archit Taneja wrote:
On 06/28/2017 01:28 AM, Eric Anholt wrote:
When a mipi_dsi_host is registered, the DT is walked to find any child
nodes with compatible strings. Those get registered as DSI devices,
and most DSI panel dri
Op 30-06-17 om 15:56 schreef Daniel Vetter:
> On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
>> We want to change swap_state to wait indefinitely, but to do this
>> swap_state should wait interruptibly. This requires propagating
>> the error to each driver. All drivers have chan
Thanks!
Minor typo "dsiplay", otherwise: Reviewed-by: Sinclair Yeh
On Mon, Jun 26, 2017 at 06:19:48PM +0200, Daniel Vetter wrote:
> Again stopping the vblank before uninstalling the irq handler is kinda
> the wrong way round, but the fb_off stuff should take care of
> disabling the dsiplay at l
Regards
Shashank
On 7/3/2017 3:27 PM, Ville Syrjälä wrote:
On Mon, Jul 03, 2017 at 02:36:58PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/30/2017 5:24 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:03:59PM +0530, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes
On Mon, 3 Jul 2017 11:42:10 +0200
Peter Rosin wrote:
> At init and if the gamma_lut property is ever removed, the clut
> registers must be programmed with a default gamma ramp instead of
> being left in some unknown state.
>
> Fixes: 364a7bf574eb ("drm: atmel-hlcdc: add support for 8-bit color
Remove drm_mode_config_fb, I don't see the point of it.
To make it clear that it's ok to use plane->fb directly,
move up drm_drv_uses_atomic_modeset so the code is skipped for atomic
drivers that require plane_state->fb.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_fb_helper.c | 22 +
On Mon, 3 Jul 2017 13:53:28 +0200
Peter Rosin wrote:
> On 2017-07-03 13:31, Boris Brezillon wrote:
> > On Mon, 3 Jul 2017 11:42:10 +0200
> > Peter Rosin wrote:
> >
> >> At init and if the gamma_lut property is ever removed, the clut
> >> registers must be programmed with a default gamma ramp
Op 30-06-17 om 15:56 schreef Daniel Vetter:
> On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
>> We want to change swap_state to wait indefinitely, but to do this
>> swap_state should wait interruptibly. This requires propagating
>> the error to each driver. All drivers have chan
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 "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from "VIDE
On Mon, Jul 03, 2017 at 05:55:43PM +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 "VI
From: Ville Syrjälä
state->connectors[] can grows dynamically, so we can switch over to
using the new drm_dynarray.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c| 49 +++--
drivers/gpu/drm/drm_atomic_helper.c | 4 +--
include/drm/drm_ato
From: Ville Syrjälä
This series refactors some of the atomic krealloc() stuff into a small helper
that avoids everyone having to do the krealloc() dance and memset() themselves.
Another thing we do is rework the private objects state handling to resemble
the normal crtc/plane/connector state han
From: Ville Syrjälä
Add a small helper that gives us dynamically growing arrays. We have a
couple hand rolled implementations of this in the atomic code, which we
can unify to use a common implementation.
Signed-off-by: Ville Syrjälä
---
Documentation/gpu/drm-utils.rst | 15 +++
Documentat
From: Ville Syrjälä
Make the atomic private object stuff less special by introducing proper
base classes for the object and its state. Drivers can embed these in
their own appropriate objects, after which these things will work
exactly like the plane/crtc/connector states during atomic operations
From: Ville Syrjälä
state->private_objs grows dynamically, so switch it over to use
the new drm_dynarray helper.
Cc: Dhinakaran Pandiyan
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c| 64 -
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
From: Ville Syrjälä
We will never add private objects with a NULL state into the atomic
state, hence checking for that is pointless.
Cc: Dhinakaran Pandiyan
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/driv
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 "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from "VIDE
On Fri, Jun 30, 2017 at 08:18:19PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 5:26 PM, Daniel Vetter wrote:
> > On Fri, Jun 30, 2017 at 05:18:41PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> >> From: Ville Syrjälä
> >>
> >> Add drm_crtc_vblank_get_accurate() which is the same as
On Mon, Jul 03, 2017 at 07:53:44PM +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 "VI
https://bugzilla.kernel.org/show_bug.cgi?id=194761
--- Comment #69 from siyia (eutychio...@gmail.com) ---
Created attachment 257315
--> https://bugzilla.kernel.org/attachment.cgi?id=257315&action=edit
Bumped number Patch for linux 4.12
Patch still works for linux 4.12.0
--
You are receiving t
https://bugzilla.kernel.org/show_bug.cgi?id=194761
siyia (eutychio...@gmail.com) changed:
What|Removed |Added
Attachment #257315|0 |1
is patch|
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 "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from "VIDE
Please ignore this version, sent premature. Actual one on the way.
-Original Message-
From: Sharma, Shashank
Sent: Monday, July 3, 2017 8:39 PM
To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
Cc: Sharma, Shashank ; Ville Syrjala
Subject: [PATCH v3] drm/edid: rename
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 "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from "VIDE
https://bugzilla.kernel.org/show_bug.cgi?id=194761
siyia (eutychio...@gmail.com) changed:
What|Removed |Added
Attachment #257315|Bumped number Patch for |Bumped Patch version numbe
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 "VI
Fixes a problem with console not appearing when booting with EFI that
has GOP support, because fb0 would end up being efifb, even after drm
has taken over the display.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 20
drivers/gpu/drm/msm/msm_drv.h | 1 +
Regards
Shashank
On 7/3/2017 9:14 PM, David Weinehall wrote:
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
https://bugs.freedesktop.org/show_bug.cgi?id=100979
--- Comment #8 from Przemek ---
Created attachment 132411
--> https://bugs.freedesktop.org/attachment.cgi?id=132411&action=edit
dmesg after first suspend/resume process kernel 4.12
Situation still persist on kernel 4.12. After second "suspend
On Mon, Jul 03, 2017 at 09:44:50AM +0100, Liviu Dudau wrote:
> On Fri, Jun 30, 2017 at 08:13:58PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 30, 2017 at 6:51 PM, Liviu Dudau wrote:
> > > Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
> > > if no output is connected at fra
On Mon, Jul 03, 2017 at 01:01:55PM +0200, Maarten Lankhorst wrote:
> Op 30-06-17 om 15:56 schreef Daniel Vetter:
> > On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
> >> We want to change swap_state to wait indefinitely, but to do this
> >> swap_state should wait interruptibly. T
On Mon, Jul 03, 2017 at 09:16:54AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-07-03 09:03:36)
> > On Fri, Jun 30, 2017 at 5:39 PM, Chris Wilson
> > wrote:
> > >> Yeah, but my point is that this here is an extremely fancy and fragile
> > >> (and afaics in this form, incomplete) fix f
On Mon, Jul 03, 2017 at 05:26:24PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 30, 2017 at 08:18:19PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 30, 2017 at 5:26 PM, Daniel Vetter wrote:
> > > On Fri, Jun 30, 2017 at 05:18:41PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > >> From: Ville S
On Mon, Jul 03, 2017 at 12:30:48PM +0300, Ville Syrjälä wrote:
> I've pretty much decided that I'll be happy if I can solve this for
> future kernels. If someone else wants to try and cook up some kind
> of simple regression fix I don't have any real objections.
Imo fixing the regression isn't the
On Mon, Jul 03, 2017 at 01:51:06PM +0200, Maarten Lankhorst wrote:
> Remove drm_mode_config_fb, I don't see the point of it.
> To make it clear that it's ok to use plane->fb directly,
> move up drm_drv_uses_atomic_modeset so the code is skipped for atomic
> drivers that require plane_state->fb.
>
On Mon, Jul 03, 2017 at 04:43:35PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We will never add private objects with a NULL state into the atomic
> state, hence checking for that is pointless.
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Ville Syrjälä
Reviewed-by: D
On Mon, Jul 03, 2017 at 04:43:37PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make the atomic private object stuff less special by introducing proper
> base classes for the object and its state. Drivers can embed these in
> their own appropriate objects, after which the
On Mon, Jul 03, 2017 at 11:56:23AM -0400, Rob Clark wrote:
> Fixes a problem with console not appearing when booting with EFI that
> has GOP support, because fb0 would end up being efifb, even after drm
> has taken over the display.
>
> Signed-off-by: Rob Clark
So I have no idea, but I thought D
On Mon, Jul 03, 2017 at 06:53:38PM +0200, Daniel Vetter wrote:
> On Mon, Jul 03, 2017 at 04:43:35PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We will never add private objects with a NULL state into the atomic
> > state, hence checking for that is pointless.
> >
Fixes an insta-reboot when screen-blanking kicks in, due to cursor
updates without clocks enabled.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp
Accessing registers for an unclocked block is an insta-reboot on
snapdragon devices. So add a bit of logic to track the enable_count so
we can WARN_ON() unclocked register writes. This makes it much easier
to track down mistakes.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_k
On Mon, Jul 3, 2017 at 1:02 PM, Daniel Vetter wrote:
> On Mon, Jul 03, 2017 at 11:56:23AM -0400, Rob Clark wrote:
>> Fixes a problem with console not appearing when booting with EFI that
>> has GOP support, because fb0 would end up being efifb, even after drm
>> has taken over the display.
>>
>> S
We unref the man->move fence in ttm_bo_clean_mm() and then call
ttm_bo_force_list_clean() which waits on it, except the refcount is now
zero so a warning is generated (or worse):
[149492.279301] refcount_t: increment on 0; use-after-free.
[149492.279309] [ cut here ]
[14949
amd_powerplay_destroy() expects a handle pointing to a struct pp_instance.
On chips without PowerPlay, pp_handle points to a struct amdgpu_device. The
resulting attempt to kfree() fields of the wrong struct ends in fire:
[ 91.560405] BUG: unable to handle kernel paging request at ebe0062
I've gone ahead and pushed the two to our amd-staging-4.11 branch.
Alex will certainly pick that up for his next fixes pull request.
Thanks for the help,
Christian.
Am 03.07.2017 um 20:05 schrieb John Brooks:
We unref the man->move fence in ttm_bo_clean_mm() and then call
ttm_bo_force_list_cle
1 - 100 of 133 matches
Mail list logo
