https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #13 from Michel Dänzer ---
Please attach the output of xrandr.
With runpm enabled, if you run xrandr, does the dedicated GPU turn on and the
corresponding messages appear in dmesg?
--
You are receiving this mail because:
You are th
>
> No.
>
> IMO Not fixing this immediately through stable is out of the question.
> The deal is that we don't break userspace.
> Having said that, I'm not against a long term vmwgfx-only solution. But
> let's fix this now.
>
> Admittedly we missed testing this but you got to understand that no
No.
IMO Not fixing this immediately through stable is out of the question.
The deal is that we don't break userspace.
Having said that, I'm not against a long term vmwgfx-only solution. But
let's fix this now.
Admittedly we missed testing this but you got to understand that not all
developer team
https://bugs.freedesktop.org/show_bug.cgi?id=99881
Matthew Fox changed:
What|Removed |Added
Attachment #129782|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #12 from Matthew Fox ---
Created attachment 129785
--> https://bugs.freedesktop.org/attachment.cgi?id=129785&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #11 from Matthew Fox ---
Created attachment 129784
--> https://bugs.freedesktop.org/attachment.cgi?id=129784&action=edit
Xorg.1.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #10 from Matthew Fox ---
Created attachment 129783
--> https://bugs.freedesktop.org/attachment.cgi?id=129783&action=edit
dmesg.log 2
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #9 from Matthew Fox ---
(In reply to Michel Dänzer from comment #8)
> Please attach the corresponding Xorg log file.
Hi,
The only Xorg logs I have are for my new session. They weren't in /var/log/ but
/home/matthew/.local/share/xor
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #8 from Michel Dänzer ---
Please attach the corresponding Xorg log file.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #7 from Matthew Fox ---
(In reply to Michel Dänzer from comment #6)
> Note that you should run
>
> env | grep DRI_
>
> in an X terminal, not in a console TTY.
Same result in both :/
--
You are receiving this mail because:
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #6 from Michel Dänzer ---
Note that you should run
env | grep DRI_
in an X terminal, not in a console TTY.
--
You are receiving this mail because:
You are the assignee for the bug.___
d
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 +++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 +
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.
Hdmi or DisplayPort request a accurate clock,
reject the display mode if clock is not good.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/d
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #5 from Matthew Fox ---
> What does
>
> env | grep DRI_
>
> say?
That printed nothing.
My session with runtime pm enabled (no radeon.runpm=0 in cmdline) had been
running for a couple of hours without problem (apart from a bit of
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #4 from Michel Dänzer ---
(In reply to Matthew Fox from comment #3)
> This is a fresh install and I have not set that env var anywhere. Where
> could I check for that?
What does
env | grep DRI_
say?
> Does that mean with radeon.
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #3 from Matthew Fox ---
Hi Michel,
Just a slight correction to my description - I am running Ubuntu Gnome 16.04.2.
This is a fresh install and I have not set that env var anywhere. Where could I
check for that?
Does that mean with
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #2 from Michel Dänzer ---
It sounds like you have the environment variable DRI_PRIME=1 set for all
applications?
Those dmesg messages are normal when the dedicated GPU is powered up, which
takes some time. With runpm enabled, it's po
https://bugs.freedesktop.org/show_bug.cgi?id=99881
Michel Dänzer changed:
What|Removed |Added
Attachment #129781|text/x-log |text/plain
mime type|
On Mon, Feb 20, 2017 at 10:32 AM, Inki Dae wrote:
>
>
> 2017년 02월 20일 16:27에 Krzysztof Kozlowski 이(가) 쓴 글:
>> On Mon, Feb 20, 2017 at 9:07 AM, Inki Dae wrote:
>>> Hi Krzysztof,
>>>
>>> Can you merge patch 2 and 5 to your tree so that they can go to mainline?
>>> Otherwise, I can merge them to my
On Mon, Feb 20, 2017 at 05:53:31PM +, Liviu Dudau wrote:
> Sorry, looks like this fell through the cracks of us trying to fix the
> other issues you were seeing. I'm attaching a patch, please let me know
> if this works for you.
I don't have time to test right now, but it looks similar to what
On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> This stuff should be using the clipped coordinates, not the user
> coordinates. And it doesn't look like this guy is even calling the
> clip helper thing.
>
> malidp seems to be calling that thing, but it still doesn't
> manage to pr
Hi Phillipp
On Mon, Feb 20, 2017 at 3:42 PM, Philipp Zabel wrote:
> Hi Dan,
>
> On Sat, 2017-02-11 at 21:09 +, Dan MacDonald wrote:
>> Hi Phillipp
>>
>> I'm having trouble getting xf86-video-armada working properly on a
>> Element 14 / Embest SABRE Lite board running Arch Linux with kernel
>>
On 02/09/17 21:05, Rob Herring wrote:
> Convert drivers to use the new of_graph_get_remote_node() helper
> instead of parsing the endpoint node and then getting the remote device
> node. Now drivers can just specify the device node and which
> port/endpoint and get back the connected remote device
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in this
case.
Add a missing call to 'pm_runtime_put()'.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399
On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> Something I also noticed is this:
>
> scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> plane->state->crtc_y * plane->state->fb->pitches[0] +
> plane->state->crtc_x * bpp
On Thu, Feb 9, 2017 at 3:26 AM, Hoegeun Kwon wrote:
> The OF graph is not needed because the panel is a child of dsi. So
> Remove the ports node and move burst and esc clock frequency
> properties to the parent (DSI node).
>
> Signed-off-by: Hoegeun Kwon
> ---
> arch/arm/boot/dts/exynos3250-rina
On 6 January 2017 at 07:09, Lorenzo Stoakes wrote:
>
> Adding Andrew, as this may be another less active corner of the corner,
> thanks!
Hi all,
Thought I'd also give this one a gentle nudge now the merge window has
re-opened, Andrew - are you ok to pick this up? I've checked the patch
and it s
Pandiyan, Dhinakaran schreef op ma 13-02-2017 om 22:48 [+]:
> On Mon, 2017-02-13 at 21:26 +, Pandiyan, Dhinakaran wrote:
> >
> > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> > >
> > > Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> > > >
> > > > On Thu
On 02/20/2017 10:05 AM, Dave Airlie wrote:
> On 20 Feb. 2017 18:29, "Marek Vasut" wrote:
>
> On 02/20/2017 03:56 AM, Dave Airlie wrote:
>> On 19 February 2017 at 08:25, Marek Vasut wrote:
>>> On 02/17/2017 09:34 PM, Dave Airlie wrote:
On 17 February 2017 at 18:00, Marek Vasut wrote:
>
On 02/20/2017 03:56 AM, Dave Airlie wrote:
> On 19 February 2017 at 08:25, Marek Vasut wrote:
>> On 02/17/2017 09:34 PM, Dave Airlie wrote:
>>> On 17 February 2017 at 18:00, Marek Vasut wrote:
On 02/17/2017 03:41 AM, Dave Airlie wrote:
> On 16 February 2017 at 08:16, Marek Vasut wrote:
Hi Tomasz,
在 2017/2/20 10:40, Tomasz Figa 写道:
Hi Zain,
On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote:
The analogix_dp_transfer() will return -EBUSY if num_transferred is zero.
But sometimes we will send a bare address packet to start the transaction,
like drm_dp_i2c_xfer() show:
.
On Mon, Feb 20, 2017 at 9:09 AM, Hoegeun Kwon wrote:
> From: Hyungwon Hwang
>
> This patch add the panel device tree node for S6E3HA2 display
> controller to TM2 dts.
>
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Hoegeun Kwon
>
On Mon 13-02-17 14:44:16, Maxime Ripard wrote:
> Hi Michal,
>
> On Thu, Feb 09, 2017 at 08:20:47PM +0100, Michal Hocko wrote:
> > [CC CMA people]
> >
> > On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> > > Modules might want to check their CMA pool size and address for debugging
> > > and / or h
On Mon, Feb 20, 2017 at 9:07 AM, Inki Dae wrote:
> Hi Krzysztof,
>
> Can you merge patch 2 and 5 to your tree so that they can go to mainline?
> Otherwise, I can merge them to my tree if you give me acked-by.
Hi,
Hm? Why do you need them to be merged? Do you mean that the first
patch breaks not
Hi Sean,
Could you give some comments for this patch?
Thanks
Zain
在 2017/2/13 17:27, zain wang 写道:
The analogix_dp_transfer() will return -EBUSY if num_transferred is zero.
But sometimes we will send a bare address packet to start the transaction,
like drm_dp_i2c_xfer() show:
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #1 from Matthew Fox ---
Created attachment 129782
--> https://bugs.freedesktop.org/attachment.cgi?id=129782&action=edit
lspci.log
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=99881
Bug ID: 99881
Summary: Lockup/Freezes on Laptop with switchable graphics
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
2017년 02월 20일 17:55에 Krzysztof Kozlowski 이(가) 쓴 글:
> On Mon, Feb 20, 2017 at 10:32 AM, Inki Dae wrote:
>>
>>
>> 2017년 02월 20일 16:27에 Krzysztof Kozlowski 이(가) 쓴 글:
>>> On Mon, Feb 20, 2017 at 9:07 AM, Inki Dae wrote:
Hi Krzysztof,
Can you merge patch 2 and 5 to your tree so that t
I don't work on this anymore, but, even disregarding the mess that is ACPI
backlight:
I think when people start interfacing with the Backlight API, they wonder
why it's not normalized. And then you start implementing it, and you
realize that some writes don't do anything. And that when you read ba
https://bugs.freedesktop.org/show_bug.cgi?id=99857
--- Comment #2 from Ederson ---
In the `dmesg` attachment I've sent, I was using 4.9.8. I've just updated to
4.9.9 on Arch, and the issue is still here.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #16 from intermedi...@hotmail.com ---
Created attachment 129780
--> https://bugs.freedesktop.org/attachment.cgi?id=129780&action=edit
my xorg log 7xxx
(In reply to Alex Deucher from comment #14)
> (In reply to intermedi...@hotmail.
On Mon, Feb 20, 2017 at 2:27 PM, Dave Airlie wrote:
> On 17 February 2017 at 22:58, Martin Peres
> wrote:
>> Hey everyone,
>>
>> We have been working towards exposing the backlight as a KMS property
>> instead of relying on the backlight drivers. We have CC:ed the people we
>> have found to be t
For next time around, pls cc dri-devel (it's in MAINTAINERS,
get_maintainers.pl gets it right) too.
-Daniel
On Mon, Dec 5, 2016 at 10:49 PM, Pierre-Louis Bossart
wrote:
> 100% reproducible issue found on SKL SkullCanyon NUC with two external
> DP daisy-chained monitors in DP/MST mode. When turnin
I thought about this some more, I think what we need to fix this mess
properly is:
- mode_valid helper callbacks for crtc, encoder, bridges, with the
same interface as for connectors.
- calling all these new mode_valid hooks from the probe helpers, but
with the restriction that we only reject a mod
On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom wrote:
> So I think we need a quick revert of this commit or a quick stable
> follow-up to unbreak things on our side.
I'd much prefer we just register control nodes for vmwgfx only, with a
commit message explaining in detail what exactly your con
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #15 from Alex Deucher ---
(In reply to Christian Zigotzky from comment #12)
> Hi All,
>
> I have the same problem.
>
> System:
>
> A-EON AmigaOne X1000 PowerPC
> Nemo board with a P.A. Semi PA6T-1682M CPU
> 8GB RAM
> ASUS Radeon H
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #14 from Alex Deucher ---
(In reply to intermedi...@hotmail.com from comment #9)
> Created attachment 129726 [details]
> xorg new
>
> Hi Alex,
> making more tests changing totally my inside pci setting and .
> no ring issue but xorg
https://bugs.freedesktop.org/show_bug.cgi?id=99851
Alex Deucher changed:
What|Removed |Added
Attachment #129726|text/x-log |text/plain
mime type|
Hi All,
On 17-02-17 13:58, Martin Peres wrote:
Hey everyone,
We have been working towards exposing the backlight as a KMS property instead
of relying on the backlight drivers. We have CC:ed the people we have found to
be the more likely to be interested in the discussion but please add everyo
Hi,
On 20-02-17 20:27, Dave Airlie wrote:
On 17 February 2017 at 22:58, Martin Peres wrote:
Hey everyone,
We have been working towards exposing the backlight as a KMS property
instead of relying on the backlight drivers. We have CC:ed the people we
have found to be the more likely to be inter
https://bugs.freedesktop.org/show_bug.cgi?id=99857
--- Comment #1 from Nayan Deshmukh ---
What is the kernel version that you are using?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@list
On 17 February 2017 at 22:58, Martin Peres wrote:
> Hey everyone,
>
> We have been working towards exposing the backlight as a KMS property
> instead of relying on the backlight drivers. We have CC:ed the people we
> have found to be the more likely to be interested in the discussion but
> please
On Mon, Feb 20, 2017 at 05:53:31PM +, Liviu Dudau wrote:
> Hi Russell,
>
> On Mon, Feb 20, 2017 at 12:16:03PM +, Russell King - ARM Linux wrote:
> > On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> > > Something I also noticed is this:
> > >
> > > scanou
Hi Russell,
On Mon, Feb 20, 2017 at 12:16:03PM +, Russell King - ARM Linux wrote:
> On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> > Something I also noticed is this:
> >
> > scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > p
Hi Maxime,
sorry, I have missed the discussion about the double buffering/virtual
surface size patch series two weeks ago. My comments about the patch are
inline:
On Wed, Feb 15, 2017 at 05:19:08PM +0100, Maxime Ripard wrote:
> From: Xinliang Liu
Mabye you should take the authorship here. Takin
On Mon, 2017-02-20 at 12:17 +, Eric Engestrom wrote:
> On Wednesday, 2017-02-15 15:33:18 -0800, Joe Perches wrote:
> > drm_printf does not currently use the compiler to verify
> > format and arguments. Make it do so.
> >
> > Miscellanea:
> >
> > o Add appropriate #include files for __printf
https://bugs.freedesktop.org/show_bug.cgi?id=96999
Jan Ziak <0xe2.0x9a.0...@gmail.com> changed:
What|Removed |Added
Status|NEW |RESOLVED
Re
On Fri, Feb 17, 2017 at 04:43:41PM +0100, Maxime Ripard wrote:
> On Fri, Feb 17, 2017 at 01:45:44PM +0100, Tobias Jakobi wrote:
> > Hello Maxime,
> >
> > Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
> > >> I was wondering about the foll
Cc'ing Daniel, Lee and Jingoo, the backlight subsystem maintainers.
On 17/02/17 14:58, Martin Peres wrote:
> Hey everyone,
>
> We have been working towards exposing the backlight as a KMS property
> instead of relying on the backlight drivers. We have CC:ed the people we
> have found to be the mo
Version 3:
- Update "st,stm32-ltdc.txt" binding.
- Add a commit to "ARM: configs: stm32: ADD LDTC support" patch.
Version 2:
- Rename driver directory from st to stm.
- Rename compatiblity from st,ltdc to st,stm32-ltdc.
- Remove compatibility st,display-subsystem.
- Rename driver from st-drm to st
This patch adds support for the STM32 LCD-TFT display controller.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/stm/Kconfig | 14 +
drivers/gpu/drm/stm/Makefile |7 +
drivers/gpu/drm/stm/drv.c| 232
Enable ltdc & enable am-480272h3tmqw-t01h panel.
Signed-off-by: Yannick Fertre
---
arch/arm/boot/dts/stm32429i-eval.dts | 59
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 601
Signed-off-by: Yannick Fertre
---
.../devicetree/bindings/display/st,stm32-ltdc.txt | 36 ++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.
Add simple-panel support for the Ampire AM-480272H3TMQW-T01H,
which is a 4.3" WQVGA panel.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/panel/panel-simple.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu
This patch adds STM32 LTDC support & simple panel support in stm32_defconfig
file
Signed-off-by: Yannick Fertre
---
arch/arm/configs/stm32_defconfig | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index e995209..d6a00b
Signed-off-by: Yannick Fertre
---
.../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7 +++
1 file changed, 7 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
diff --git
a/Documentation/devicetree/bindings/d
Add LTDC (Lcd-tft Display Controller) support.
Signed-off-by: Yannick Fertre
---
arch/arm/boot/dts/stm32f429.dtsi | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e4dae0e..4cd8244 100
Hi Dan,
On Sat, 2017-02-11 at 21:09 +, Dan MacDonald wrote:
> Hi Phillipp
>
> I'm having trouble getting xf86-video-armada working properly on a
> Element 14 / Embest SABRE Lite board running Arch Linux with kernel
> 4.9.8. I have been in touch with RMK and he's confident the crash
> below is
On Fri, 2017-02-17 at 19:28 +0100, Lucas Stach wrote:
> This adds support for the i.MX6 QUadPlus PRG unit. It glues together the
> IPU and the PRE units.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/ipu-v3/Makefile | 2 +-
> drivers/gpu/ipu-v3/ipu-prg.c | 413
>
Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
1.1.
When a sink that supports deep color is connected to the output, the
receiver will send EDIDs that advertise this capability, even if it
isn't possible with HDMI versions earlier than 1.3.
Currently the kernel is assuming
On 18 February 2017 at 22:22, Benjamin Herrenschmidt
wrote:
> On Sat, 2017-02-18 at 15:43 +, Emil Velikov wrote:
>>
>> Out of curiosity - can you try testing with and w/o the ddr_test_2500
>> bug fix(?).
>> Would be interesting to see if any of the omitted code [in
>> ast_dram_init_2500] has n
On Fri, 2017-02-17 at 19:28 +0100, Lucas Stach wrote:
> This adds support for the i.MX6 QuadPlus PRE units. Currently only
> linear prefetch into SRAM is supported, other modes of operation
> like the tiled-to-linear conversion will be added later.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/
On Fri, 2017-02-17 at 19:28 +0100, Lucas Stach wrote:
> The Prefetch Resolve Engine is a prefetch and tile resolve engine
> which prefetches display data from DRAM to an internal SRAM region.
> It has a single clock for configuration register access and the
> functional units. A single shared inter
On 02/16/2017 04:15 AM, Rob Herring wrote:
> On Fri, Feb 10, 2017 at 04:24:28PM +0100, Yannick Fertre wrote:
>> Signed-off-by: Yannick Fertre
>> ---
>> .../devicetree/bindings/display/st,stm32-ltdc.txt | 37
>> ++
>> 1 file changed, 37 insertions(+)
>> create mode 100644
On 20/02/17 12:46, Martin Peres wrote:
+plasma-devel, as suggested by Martin Gräßlin.
This reply also adds the current drivers/video/backlight maintainers (I
forwarded the original mail to them separately, so I've been pretty
brutal with the delete key when quoting the original mail).
On
On Mon, 2017-02-20 at 14:30 +0100, Philipp Zabel wrote:
> Use drm_plane_helper_check_state to clip raw user coordinates to crtc
> bounds. This checks for full plane coverage and scaling already, so
> we can drop some custom checks. Use the clipped coordinates everywhere.
>
> Suggested-by: Ville Sy
Use drm_plane_helper_check_state to clip raw user coordinates to crtc
bounds. This checks for full plane coverage and scaling already, so
we can drop some custom checks. Use the clipped coordinates everywhere.
Suggested-by: Ville Syrjälä
Signed-off-by: Philipp Zabel
---
Changes since v5:
- Reba
From: Shawn Guo
Commit 4e986d3705df ("drm: zte: add overlay plane support") introduces
the following static checker warning:
drivers/gpu/drm/zte/zx_plane.c:170 zx_vl_rsz_setup()
warn: always true condition '(fmt >= 0) => (0-u32max >= 0)'
Fix it by change 'fmt' type to integer.
Reported-by: D
Use drm_plane_helper_check_state to clip raw user coordinates to crtc
bounds. This checks for full plane coverage and scaling already, so
we can drop some custom checks. Use the clipped coordinates everywhere.
Suggested-by: Ville Syrjälä
Signed-off-by: Philipp Zabel
---
Changes since v4:
- Reve
Hi,
On 16-02-17 17:58, Ville Syrjälä wrote:
On Thu, Feb 16, 2017 at 11:01:29AM +0100, Hans de Goede wrote:
Hi,
On 15-02-17 15:59, Ville Syrjälä wrote:
On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:
Hi Jani,
As discussed here:
https://bugs.freedesktop.org/show_bug.cgi?id=948
On Fri, 2017-02-17 at 19:28 +0100, Lucas Stach wrote:
> This is a pretty minor optimization for the IC channel to get
> out-of-order AXI returns, but clashes with the AXI ID assignment
> that needs to be done for the display channels on QuadPlus.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gp
+plasma-devel, as suggested by Martin Gräßlin.
On 17/02/17 14:58, Martin Peres wrote:
Hey everyone,
We have been working towards exposing the backlight as a KMS property
instead of relying on the backlight drivers. We have CC:ed the people we
have found to be the more likely to be interested i
Op 10-02-17 om 17:29 schreef Shashank Sharma:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
>
> This patch checks if the monitor supports scrambl
On Wednesday, 2017-02-15 15:33:18 -0800, Joe Perches wrote:
> drm_printf does not currently use the compiler to verify
> format and arguments. Make it do so.
>
> Miscellanea:
>
> o Add appropriate #include files for __printf and struct va_format
> o Convert dev_printk to dev_info
I think these
Op 20-02-17 om 13:03 schreef Chris Wilson:
> On Mon, Feb 20, 2017 at 01:32:42PM +0200, Joonas Lahtinen wrote:
>> On pe, 2017-02-17 at 18:35 +, Chris Wilson wrote:
>>> The code currently assumes that all fence arrays it sees are the normal
>>> signal-on-all variety, and decomposes the array into
On Mon, Feb 20, 2017 at 01:32:42PM +0200, Joonas Lahtinen wrote:
> On pe, 2017-02-17 at 18:35 +, Chris Wilson wrote:
> > The code currently assumes that all fence arrays it sees are the normal
> > signal-on-all variety, and decomposes the array into its individual
> > fences so that it can extr
Fix compilation warning introduced by:
commit 0c7ff84f7f9d ("drm/sti: remove deprecated legacy vtg slave")
commit 5e60f595d6ca ("drm/sti: use atomic_helper for commit")
Signed-off-by: Vincent Abriou
---
drivers/gpu/drm/sti/sti_drv.c | 9 -
drivers/gpu/drm/sti/sti_vtg.c | 1 -
2 files cha
On pe, 2017-02-17 at 18:35 +, Chris Wilson wrote:
> The code currently assumes that all fence arrays it sees are the normal
> signal-on-all variety, and decomposes the array into its individual
> fences so that it can extract the native i915 fences. If the fence array
> is using signal-on-any,
On 02/16/2017 03:34 AM, Rob Herring wrote:
> On Fri, Feb 10, 2017 at 03:54:44PM +0100, Yannick Fertre wrote:
>> Signed-off-by: Yannick Fertre
>> ---
>> .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7
>> +++
>> 1 file changed, 7 insertions(+)
>> create mode 100644
On 20 Feb. 2017 18:29, "Marek Vasut" wrote:
On 02/20/2017 03:56 AM, Dave Airlie wrote:
> On 19 February 2017 at 08:25, Marek Vasut wrote:
>> On 02/17/2017 09:34 PM, Dave Airlie wrote:
>>> On 17 February 2017 at 18:00, Marek Vasut wrote:
On 02/17/2017 03:41 AM, Dave Airlie wrote:
> On 1
Follow the naming in debugfs also for logging, add "unknown" for values
beyond the enumerated ones.
v2: add \n in connector_show, make internal to drm (Chris)
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
It's easy enough to move the declaration to include/drm/drm
2017년 02월 20일 16:27에 Krzysztof Kozlowski 이(가) 쓴 글:
> On Mon, Feb 20, 2017 at 9:07 AM, Inki Dae wrote:
>> Hi Krzysztof,
>>
>> Can you merge patch 2 and 5 to your tree so that they can go to mainline?
>> Otherwise, I can merge them to my tree if you give me acked-by.
>
> Hi,
>
> Hm? Why do you
Hi,
On 16-02-17 20:02, Jani Nikula wrote:
On Thu, 16 Feb 2017, Ville Syrjälä wrote:
On Fri, Feb 10, 2017 at 11:28:02AM +0100, Hans de Goede wrote:
Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
the bus is accessed to avoid needing to do any forcewakes, which need
PMIC bu
Since atomic framework, crtc enable and disable are in pairs,
no need to wait vblank.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 -
1 file changed, 36 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/g
Hello Ville, Jani
I have addressed all your review comments in this patch set (V3).
Can you please have a look if this seems ok ?
Link: https://patchwork.kernel.org/patch/9567061/
Regards
Shashank
-Original Message-
From: Sharma, Shashank
Sent: Friday, February 10, 2017 9:59 PM
To: d
Reference the power domain incase dw-mipi power down when
in use.
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16
1 file changed, 16 insertions(+
The vopb/vopl switch register of RK3399 mipi is different from RK3288,
the default setting for mipi dsi mode is different too, so add a
of_device_id structure to distinguish them, and make sure set the
correct mode before mipi phy init.
Signed-off-by: Chris Zhong
Signed-off-by: Mark Yao
Reviewed
The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has
additional phy config clock.
Signed-off-by: Chris Zhong
Acked-by: Rob Herring
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
.../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchi
Signed-off-by: Chris Zhong
Acked-by: Rob Herring
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
.../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
a/Documentation/devicetree/bindings/
Set the lanes bps to 1 / 0.9 times of pclk, the margin is not enough
for some panel, it will cause the screen display is not normal, so
increases the badnwidth to 1 / 0.8.
Signed-off-by: Chris Zhong
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu
1 - 100 of 103 matches
Mail list logo
