[Your MUA messed up the quoting, FTFY below.]
On Wed, 22 Feb 2017, "Navare, Manasi D" wrote:
> > On Fri, 17 Feb 2017, Manasi Navare wrote:
> >> Display stream compression is supported on DP 1.4 DP devices. This
> >> patch adds the corersponding DPCD register definitions for DSC.
> >>
> >> v2:
A couple of the kms functions didn't have the correct/newest names.
This prevented them to be identified as refs in the html doc.
Signed-off-by: Archit Taneja
---
include/drm/drm_mode_config.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_mode_config.h
2017-02-21 23:03 GMT+01:00 Arnd Bergmann :
> One variable was left behind after its user got removed and we should now
> delete the declaration as well:
>
> drivers/gpu/drm/sti/sti_vtg.c: In function 'vtg_probe':
> drivers/gpu/drm/sti/sti_vtg.c:392:22: error: unused variable 'np'
> [-Werror=unused
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #22 from Michel Dänzer ---
I suspect what happens is that some client occasionally asks the X server to
probe the connected displays, similar to xrandr. This powers up the dGPU, in
order to probe its display connectors. That takes so
https://bugzilla.kernel.org/show_bug.cgi?id=194649
--- Comment #4 from Michel Dänzer (mic...@daenzer.net) ---
I can't seem to reproduce this on my Tonga.
Was it really only the kernel that made the difference? No updates for kwin /
Mesa / xf86-video-amdgpu / xserver / Mesa / ... in the meantime?
devm_request_threaded_irq result should be checked for errors.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sil-sii8620.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index cdd0a9d..2d51a22 100644
Op 21-02-17 om 16:23 schreef Patchwork:
> == Series Details ==
>
> Series: drm/atomic: Make drm_framebuffer_remove atomic, again.
> URL : https://patchwork.freedesktop.org/series/20008/
> State : failure
>
> == Summary ==
>
> Series 20008v1 drm/atomic: Make drm_framebuffer_remove atomic, again.
>
https://bugs.freedesktop.org/show_bug.cgi?id=99900
Bug ID: 99900
Summary: nouveau: freeze / crash after kernel update to 4.10
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=99900
--- Comment #1 from Torsten Krah ---
Created attachment 129824
--> https://bugs.freedesktop.org/attachment.cgi?id=129824&action=edit
Xorg.0.log 4.10 - flip queue failed
--
You are receiving this mail because:
You are the assignee for the bug.
Handle DRM_DP_DUAL_MODE_LSPCON in drm_dp_get_dual_mode_type_name(),
otherwise a call to that function can theoretically trigger a WARN.
Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
Cc: Shashank Sharma
Cc: Rodrigo Vivi
Cc: Dave Airlie
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=97590
--- Comment #3 from Adam Bolte ---
Is it possible the driver code for the LED controller used by fglrx can be
released to get the ball rolling on this? Someone I should get in contact with
perhaps? Or is this actually being worked on (or at least
From: Thierry Reding
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.
V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
Signed-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/
HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.
This patch series contains 6 patche
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
V2: Rebase.
V3: Added
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 scrambling, and if required,
enables it during the modeset.
V
HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340 MHz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.
This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
Reviewed-by: Ander Conselvan De Ol
At the first glace, I thought LSPCON is type2 HDMI only, then I realized
not really for us (:-))
Reviewed-by: Shashank Sharma
Regards
Shashank
On 2/22/2017 6:29 PM, Ander Conselvan de Oliveira wrote:
Handle DRM_DP_DUAL_MODE_LSPCON in drm_dp_get_dual_mode_type_name(),
otherwise a call to that f
On Tue, 21 Feb 2017 10:39:18 -0500, Sean Paul wrote:
> On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote:
> > Hi all
> >
> > [Resend this v7 version series, since there are 5 mails have gone missing,
> > last
> > week]
> >
> > This version does not change the existing v6 patches, just
https://bugs.freedesktop.org/show_bug.cgi?id=99900
poma changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o
|.o
On Tue, 21 Feb 2017, "Jasper St. Pierre" wrote:
> Instead of normalizing to 100, I think we should expose a max level, and
> specify that's max brightness. Every single step in the range should have a
> visible difference in output lumens.
The drivers can't guarantee that.
BR,
Jani.
--
Jani N
On Mon, 20 Feb 2017, Hans de Goede wrote:
> On 17-02-17 13:58, Martin Peres wrote:
> So 1 and 2 are closely related the problem is that if we expose a
> fixed number of steps we need to convert in both directions, and if
> userspace tries to increment by doing read, add 1, write and we expose
> 1-
On Mon, 20 Feb 2017, Daniel Thompson wrote:
>>> === 1) Backlight device interoperability ===
>>>
>>> Since we need to keep backward compatibility of the backlight, we have
>>> to keep the current backlight drivers.
>>>
>>> Here are possible options:
>>>
>>> - Exclusive access: Unregister a backli
On 20/02/17 21:57, Hans de Goede wrote:
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
h
Hi Ville,
On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> 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 -
On 22/02/17 17:05, Jani Nikula wrote:
On Mon, 20 Feb 2017, Daniel Thompson wrote:
=== 1) Backlight device interoperability ===
Since we need to keep backward compatibility of the backlight, we have
to keep the current backlight drivers.
Here are possible options:
- Exclusive access: Unregi
On Wed, Feb 22, 2017 at 03:15:42PM +, Liviu Dudau wrote:
> Hi Ville,
>
> On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> > 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 L
On Mon, 20 Feb 2017, Thierry Reding wrote:
>> - The luminance curve of the backlight drivers is not specified, which
>> can lead to a bad user experience: Little changes in the highest levels
>> but drastic changes in the low levels.
>
> I think this is something that the backlight framework shou
On Mon, Feb 20, 2017 at 06:59:49PM +, Russell King - ARM Linux wrote:
> 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 thin
On Mon, 20 Feb 2017, Dave Airlie wrote:
> How do you tackle that end of the problem, how does the i915/drm core
> know when the driver for the one backlight it needs has appeared, and
> is working, by deferring this to userspace we let the system load all
> the drivers and the policy of picking th
On Wed, Feb 22, 2017 at 8:43 AM, John Keeping wrote:
> On Tue, 21 Feb 2017 10:39:18 -0500, Sean Paul wrote:
>
>> On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote:
>> > Hi all
>> >
>> > [Resend this v7 version series, since there are 5 mails have gone missing,
>> > last
>> > week]
>> >
All Exynos CRTC drivers shouldn't fail at referencing vblank events,
alternate path is actually dead code.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos
Current implementation of event handling assumes that vblank interrupt is
always called at the right time. It is not true, it can be delayed due to
various reasons. As a result different races can happen. The patch fixes
the issue by using hardware frame counter present in DECON to serialize
vblank
CRTC event is currently send with next vblank, or instantly in case crtc
is being disabled. This approach usually works, but in corner cases it can
result in premature event generation. Only device driver is able to verify
if the event can be sent. This patch is a first step in that direction - it
DECON in case of video mode generates interrupt by default at start
of vertical back porch. As this interrupt is used to generate VBLANK
events more optimal point is start of vertical front porch.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
include/vide
Hi Inki,
This patchset fixes long standing issue with occassional page faults
or vblank event timeouts on TM2 targets due to delayed vblank handling.
DECON driver should now handle properly all scenarios described in drm
docs [1][2], at least it was my intention.
I have successfully tested it on
On Tue, Feb 21, 2017 at 7:54 PM, Mark yao wrote:
> Hi Dave
>
> Some fixes, looks good to me.
>
Hi Mark,
As we discussed, rockchip patches should now go through -misc. Since
4.10 is already released, I'll push these through over there.
Sean
> Best regards.
>
> The following changes since commit
Hi,
On 22-02-17 16:05, Jani Nikula wrote:
On Mon, 20 Feb 2017, Daniel Thompson wrote:
=== 1) Backlight device interoperability ===
Since we need to keep backward compatibility of the backlight, we have
to keep the current backlight drivers.
Here are possible options:
- Exclusive access: Un
https://bugs.freedesktop.org/show_bug.cgi?id=97590
--- Comment #4 from Alex Deucher ---
Created attachment 129828
--> https://bugs.freedesktop.org/attachment.cgi?id=129828&action=edit
possible fix
Does this patch work?
--
You are receiving this mail because:
You are the assignee for the bug.
Can we at least suggest they try, again with a similar disclaimer that
"this might not work in practice"? The more I think about it, a normalized
0-100 API doesn't really simplify implementations for anybody, especially
if we don't have a natural step level.
On Wed, Feb 22, 2017 at 6:00 AM, Jani N
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #23 from Matthew Fox ---
That workaround doesn't seem to have any effect so I'll run with radeon.runpm=0
Thanks for your help any way.
--
You are receiving this mail because:
You are the assignee for the bug.___
On Wed, Feb 22, 2017 at 06:48:26PM +0530, Shashank Sharma wrote:
> From: Thierry Reding
>
> SCDC is a mechanism defined in the HDMI 2.0 specification that allows
> the source and sink devices to communicate.
>
> This commit introduces helpers to access the SCDC and provides the
> symbolic names
https://bugs.freedesktop.org/show_bug.cgi?id=99850
--- Comment #4 from Tom St Denis ---
Alex commented that mesa could use this addition to the kmd to selectively
enable/disable this feature on APUs
commit 921e71c548b313f704745dcc609ffb0206da1afe
Author: Junwei Zhang
https://bugs.freedesktop.org/show_bug.cgi?id=99850
--- Comment #5 from Alex Deucher ---
(In reply to Tom St Denis from comment #4)
> Alex commented that mesa could use this addition to the kmd to selectively
> enable/disable this feature on APUs
Not to selectively enable, but I think it might be
https://bugs.freedesktop.org/show_bug.cgi?id=99850
--- Comment #6 from Marek Olšák ---
You can try this diff:
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index f615aa8..750cdd6 100644
--- a/src/gallium/drivers/radeonsi/si_state_s
https://bugs.freedesktop.org/show_bug.cgi?id=99850
--- Comment #7 from Tom St Denis ---
I'll try this momentarily (rig is configured for polaris10).
Probably cleaner though to check the flag from the KMD though in the long run
right?
--
You are receiving this mail because:
You are the assignee
On Wed, Feb 22, 2017 at 06:48:29PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340 MHz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
>
> This patch adds:
> - A function to detect scram
https://bugs.freedesktop.org/show_bug.cgi?id=99850
Tom St Denis changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Wed, Feb 22, 2017 at 06:48:30PM +0530, Shashank Sharma wrote:
> 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 moni
https://bugs.freedesktop.org/show_bug.cgi?id=99907
Bug ID: 99907
Summary: linux-firmware 2017-02-17 update causes varying breaks
in AMDGPU for recent cards
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #1 from saunders...@wright.edu ---
There's a dmesg set on the Arch bug tracker provided for the power management
failure case -
Previous firmware revision: https://bugs.archlinux.org/task/53042?getfile=15004
Current firmware revision:
https://bugs.freedesktop.org/show_bug.cgi?id=99850
--- Comment #9 from Tom St Denis ---
Confirmed 1759 "pass"'es with tessellation tests in piglit vs 1724 passes with
HEAD~.
Yipee.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #2 from Alex Deucher ---
Does the firmware here fix the issue?
https://people.freedesktop.org/~agd5f/radeon_ucode/polaris/
--
You are receiving this mail because:
You are the assignee for the bug.___
On Wed, 22 Feb 2017 10:57:05 -0500, Sean Paul wrote:
> On Wed, Feb 22, 2017 at 8:43 AM, John Keeping wrote:
> > On Tue, 21 Feb 2017 10:39:18 -0500, Sean Paul wrote:
> >
> >> On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote:
> >> > Hi all
> >> >
> >> > [Resend this v7 version series
On Tue, Feb 21, 2017 at 4:08 PM, Christian König
wrote:
> Am 21.02.2017 um 15:55 schrieb Marek Szyprowski:
>>
>> Dear All,
>>
>> On 2017-02-21 15:37, Marek Szyprowski wrote:
>>>
>>> Hi Christian,
>>>
>>> On 2017-02-21 14:59, Christian König wrote:
Am 21.02.2017 um 14:21 schrieb Marek Szy
On Fri, Feb 17, 2017 at 4:58 AM, 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
> plea
Hi,
On Wed, Feb 22, 2017 at 11:18:48PM +0800, Icenowy Zheng wrote:
> +config SUNXI_DE2_CCU
> + bool "Support for the Allwinner SoCs DE2 CCU"
> + select SUNXI_CCU_DIV
> + select SUNXI_CCU_GATE
> + default n
This is already the default.
> +
> endif
> diff --git a/drivers/clk/sunxi
On Tue, Feb 21, 2017 at 11:42 AM, Thomas Hellstrom
wrote:
> vmware tools has a daemon that gets layout information from the GUI and
> forwards it to DRM so that the modesetting code can set preferred connector
> locations and modes. This daemon was using control nodes but since control
> nodes wer
https://bugzilla.kernel.org/show_bug.cgi?id=194649
--- Comment #5 from Roberth Sjonøy (roberth.sjo...@gmail.com) ---
I tested all the way to back to kwin 5.7.5, issue still appears, tested mesa
from git, 13.0, 17.0 issue still persist. Xserver 1.19 and the latest
xf86-video-amdgpu has been used lo
Hi,
On Wed, Feb 22, 2017 at 11:23:06PM +0800, Icenowy Zheng wrote:
> Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes
> in a new "Display Engine" (mixers instead of old backends and
> frontends).
>
> Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
>
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #3 from saunders...@wright.edu ---
I tried the firmware you linked and the problems persisted (GPU hang when
starting Xorg). I did take the opportunity and the fact the machine still
responds over SSH to capture my Xorg and kernel logs
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #4 from saunders...@wright.edu ---
Created attachment 129843
--> https://bugs.freedesktop.org/attachment.cgi?id=129843&action=edit
4.9.11 kernel log with old functioning firmware.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #5 from saunders...@wright.edu ---
Created attachment 129844
--> https://bugs.freedesktop.org/attachment.cgi?id=129844&action=edit
4.9.11 kernel log with new malfunctioning firmware.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #6 from saunders...@wright.edu ---
Created attachment 129845
--> https://bugs.freedesktop.org/attachment.cgi?id=129845&action=edit
Xorg 1.19.1 log with new malfunctioning firmware.
--
You are receiving this mail because:
You are th
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #7 from saunders...@wright.edu ---
Created attachment 129846
--> https://bugs.freedesktop.org/attachment.cgi?id=129846&action=edit
Xorg 1.19.1 log with old functional firmware.
--
You are receiving this mail because:
You are the as
https://bugzilla.kernel.org/show_bug.cgi?id=194649
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=194649
--- Comment #7 from Roberth Sjonøy (roberth.sjo...@gmail.com) ---
Unfortunatly no.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel
https://bugzilla.kernel.org/show_bug.cgi?id=194649
--- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) ---
Does reverting 646cccb55b26b95b981ea9a63512260d0c21cac3 help?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #34 from Reimar Imhof ---
Suse provided a new kernel-firmware package:
kernel-firmware-20170217-35.1.
This includes amdgpu firmware.
Using this firmware the computer freezes while starting kde plasma 5.
Same bug as reported in #c18.
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #35 from Reimar Imhof ---
flickering bug still around with kernel 4.10.0
--
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=99851
--- Comment #19 from intermedi...@hotmail.com ---
(In reply to Alex Deucher from comment #17)
> (In reply to intermedi...@hotmail.com from comment #16)
> > why im sure it is an xorg issue or one of xorg component issue
> > (cafedead),because on
On Wed, Feb 22, 2017 at 1:55 PM, John Keeping wrote:
> On Wed, 22 Feb 2017 10:57:05 -0500, Sean Paul wrote:
>
>> On Wed, Feb 22, 2017 at 8:43 AM, John Keeping wrote:
>> > On Tue, 21 Feb 2017 10:39:18 -0500, Sean Paul wrote:
>> >
>> >> On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote:
>
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #20 from Alex Deucher ---
(In reply to intermedi...@hotmail.com from comment #19)
> Hi Alex,
> can you check this my post? can be a kms issue this and cafedead too?
>
I'm not sure what you are asking. The kernel driver loads first
https://bugs.freedesktop.org/show_bug.cgi?id=97590
--- Comment #5 from Adam Bolte ---
Wow Alex - I wasn't expecting anything for months, let alone hours! Thanks!
I'll certainly be trying this out tonight and will report back as soon as I
know.
--
You are receiving this mail because:
You are th
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #21 from intermedi...@hotmail.com ---
hi Alex sorry my english is not perfect.
i will try to explain better.
I know glamor is need for accelerations but if it is present i have glitched
video with fence error on rings 0 and 3 with gpu
Hi Icenowy,
(Please fix your mailer, its quotation is broken and mangles all the
indentation)
On Thu, Feb 23, 2017 at 04:28:42AM +0800, Icenowy Zheng wrote:
> >> @@ -187,3 +220,30 @@ struct sun4i_layer **sun4i_layers_init(struct
> >> drm_device *drm)
> >>
> >> return layers;
> >> }
https://bugzilla.kernel.org/show_bug.cgi?id=194649
--- Comment #9 from Roberth Sjonøy (roberth.sjo...@gmail.com) ---
No. I applied it to 4.9.11, running the firmware files you suggested to try.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=97590
Alex Deucher changed:
What|Removed |Added
Attachment #129828|0 |1
is obsolete|
From: Colin Ian King
trivial fix to spelling mistake in pr_err message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/selftests/test-drm_mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #32 from Samuel Pitoiset ---
xz -9 should help.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:/
On 02/23/2017 06:10 AM, Sean Paul wrote:
On Wed, Feb 22, 2017 at 1:55 PM, John Keeping wrote:
On Wed, 22 Feb 2017 10:57:05 -0500, Sean Paul wrote:
On Wed, Feb 22, 2017 at 8:43 AM, John Keeping wrote:
On Tue, 21 Feb 2017 10:39:18 -0500, Sean Paul wrote:
On Mon, Feb 20, 2017 at 04:02:16PM
Hi Thierry,
On Mon, Feb 20, 2017 at 05:49:26PM +0100, Thierry Reding wrote:
> 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,
Hi Stefan,
On Mon, Feb 20, 2017 at 06:07:10PM +0100, Stefan Lengfeld wrote:
> 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, M
Hi Ville, Stefan,
On Tue, Feb 21, 2017 at 12:55:01PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 21, 2017 at 11:00:59AM +0100, Stefan Lengfeld wrote:
> > Hi Maxime,
> >
> > On Wed, Feb 15, 2017 at 05:19:09PM +0100, Maxime Ripard wrote:
> > > From: Stefan Christ
> > >
> >
> > Maybe change the aut
In some cases I've been seeing a race where two framebuffers
would be initialized, as kirin_fbdev_output_poll_changed()
might get called quickly in succession, resulting in the fb
initialization happening twice. This could cause the system
to boot up with a blank screen.
This patch adds a simple m
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #24 from Michel Dänzer ---
(In reply to Matthew Fox from comment #23)
> That workaround doesn't seem to have any effect [...]
At the very least, it should have visible effects in the Xorg log file and
xrandr output. Please attach tho
Allwinner V3s SoC features a TCON without channel 1.
Add support for it.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/
Hi Nickey,
On 22-02-2017 07:45, Nickey Yang wrote:
> "I2C Master Interface Extended Read Mode" implements a segment
> pointer-based read operation using the Special Register configuration.
>
> This patch fix
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_709810
This patchset is the initial patchset for Allwinner DE2 support.
It contains the support of clocks in DE2 and the mixers in DE2.
The SoC used to develop this patchset is V3s, as V3s is the simplest
one of the SoCs that have DE2.
(Allwinner V3s features only one mixer, although its clock control
u
2017年2月23日 03:09于 Maxime Ripard 写道：
>
> Hi,
>
> On Wed, Feb 22, 2017 at 11:18:48PM +0800, Icenowy Zheng wrote:
> > +config SUNXI_DE2_CCU
> > + bool "Support for the Allwinner SoCs DE2 CCU"
> > + select SUNXI_CCU_DIV
> > + select SUNXI_CCU_GATE
> > + default n
>
> This is already the default
The "Display Engine 2.0" in Allwinner newer SoCs contains a clock
management unit for its subunits, like the DE CCU in A80.
Add a sunxi-ng style driver for it.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/Kconfig | 6 +
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/
23.02.2017, 06:01, "Jernej Škrabec" :
> Hi,
>
> Dne sreda, 22. februar 2017 ob 16:18:50 CET je Icenowy Zheng napisal(a):
>> Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes
>> in a new "Display Engine" (mixers instead of old backends and
>> frontends).
>>
>> Add suppor
On Wed, 2017-02-22 at 09:59 +0530, Archit Taneja wrote:
>
> On 02/22/2017 05:31 AM, Pandiyan, Dhinakaran wrote:
> > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> >>
> >> On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> >>> On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
>
Allwinner V3s SoC features a "Display Engine 2.0" with only one TCON
which have RGB LCD output.
Add device nodes for it as well as the TCON.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 87
1 file changed, 87 insertions(+)
diff --
Hi,
Dne sreda, 22. februar 2017 ob 16:18:50 CET je Icenowy Zheng napisal(a):
> Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes
> in a new "Display Engine" (mixers instead of old backends and
> frontends).
>
> Add support for the mixer on Allwinner V3s SoC; it's the simple
Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes
in a new "Display Engine" (mixers instead of old backends and
frontends).
Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/Kconfig | 8 +
Hi,
Dne sreda, 22. februar 2017 ob 21:17:29 CET je Icenowy Zheng napisal(a):
> 2017年2月23日 03:09于 Maxime Ripard 写道：
>
> > Hi,
> >
> > On Wed, Feb 22, 2017 at 11:18:48PM +0800, Icenowy Zheng wrote:
> > > +config SUNXI_DE2_CCU
> > > + bool "Support for the Allwinner SoCs DE2 CCU"
> > > + select SUN
Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes
in a new "Display Engine" (mixers instead of old backends and
frontends).
Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/Kconfig | 8 +
Allwinner V3s SoC features a set of pins that have functionality of RGB
LCD, the pins are at different pin ban than other SoCs.
Add pinctrl node for them.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot
1 - 100 of 134 matches
Mail list logo
