https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #16 from Alex Deucher ---
(In reply to Andrey Grodzovsky from comment #15)
> I think it just means systems with large VRAM so it will require large BAR
> for mapping. But I am not sure on that point.
That's correct. the updates
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #15 from Andrey Grodzovsky ---
(In reply to dwagner from comment #13)
> (In reply to Andrey Grodzovsky from comment #12)
> > Can you load the kernel with grub command line amdgpu.vm_update_mode=3 to
> > force CPU VM update mode and
Hi, Daniel Vetter:
On Mon, 2018-06-25 at 10:47 +0200, Daniel Vetter wrote:
> On Wed, Jun 20, 2018 at 04:19:02PM +0800, Stu Hsieh wrote:
> > This patch add support for the Mediatek MT2712 DISP subsystem.
> > MT2712 is base on MT8173, there are some difference as following:
> > MT2712 support three
Hi Dave,
A few fixes for 4.18:
- fix a read past the end of an array due to vega20 changes
- fix driver on systems with non-4K pages
- fix locking with pageflipping in DC that could lead to a sleep while atomic
- fix VCN firmware version reporting for upcoming firmware
The following changes
On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec wrote:
> Since HDMI can be considered as main output, most capable mixer is
> connected to it (mixer0).
>
> Signed-off-by: Jernej Skrabec
> ---
> .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 45 +++
> 1 file changed, 45
On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec wrote:
> Add all entries needed for HDMI to function properly.
>
> Since R40 has highly configurable pipeline, both mixers and both TCON
> TVs are added. Board specific DT should then connect them together
> trough TCON TOP muxers to best fit the
On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec wrote:
> drm_of_find_possible_crtcs() doesn't work when DW HDMI encoder is
> connected to TCON (crtc) through mux in TCON TOP.
>
> In that case TCON TOP HDMI mux input port has to be manually traversed
> and checked if it matches any known crtc.
>
>
On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec wrote:
> Function is useful when drm_of_find_possible_crtcs() can't be used and
> custom parsing is needed. This can happen for example when there is a
> node with multiple muxes between crtc and encoder.
>
> Signed-off-by: Jernej Skrabec
On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec wrote:
> PHY is the same as in H3, except it can switch between two clock
> parents.
>
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> Expand HDMI PHY clock driver to support second clock parent.
>
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
> ---
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 4 +-
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 3 +-
>
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> Some DW HDMI PHYs, like those found in A64 and R40 SoCs, can select
> between two clock parents.
>
> Add code which reads second PLL from DT.
>
> Signed-off-by: Jernej Skrabec
This patch by itself does not do anything. It should be merged
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> DW HDMI PHY driver and PHY clock driver share same registers. Make sure
> that DW HDMI PHY setup code doesn't change any clock related bits.
> During initialization, set PHY PLL parent bit to 0.
>
> Signed-off-by: Jernej Skrabec
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> Current DW HDMI PHY code never prepares and enables PHY clock after it is
> created. It's just used as it is. This may work in some cases, but it's
> clearly wrong. Fix it by adding proper calls to enable/disable PHY
> clock.
>
> Fixes:
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL
> clock parents. It is compatible to other HDMI PHYs, like that found in
> R40.
>
> Acked-by: Rob Herring
> Signed-off-by: Jernej Skrabec
> ---
>
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> Both mixers have similar capabilities as others SoCs with DE2.
>
> First mixer has 1 VI and 3 UI planes and supports HW scaling on all
> planes.
>
> Second mixer has 1 VI and 1 UI planes and also supports HW scaling on
> all planes.
>
>
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> R40 DE2 mixers are similar to those found in A83T, except it needs
> different clock settings.
>
> Add a compatibles for them.
>
> Acked-by: Rob Herring
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> sense to check if panel or bridge is connected to them.
>
> Check if TCON has channel 0 and only then check for connected panel or
> bridges.
>
> Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #14 from Alex Deucher ---
(In reply to dwagner from comment #13)
>
> Much lower shader clocks are used only if I lower the refresh rate of the
> screen. Is there a reason why the shader clocks should stay high even in the
> absence
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> LVDS and RGB interfaces are always connected to TCONs which have channel
> 0. It doesn't make sense to try to init them on TV TCONs.
>
> Add a check if TCON has channel 0 before trying to init LVDS or RGB
> interface.
>
> Signed-off-by:
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> Current "old" method to find engine worked pretty well for DE2. However,
> it doesn't work when TCON TOP is between mixer (engine) and TCON. TCON
> TOP has multiple input ports, but current engine search algorithm
> expects only one.
>
>
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> TCON TOP is different from other nodes in graph by having 3 input and 3
> output ports. Additionally, connection to TV TCON might lead back to
> HDMI mux input port, creating loops.
>
> Add support for traversing such graph.
>
>
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> Until now, each node has one input port and one output port. However,
> with TCON TOP this is no longer true. It has 3 input and 3 output ports.
>
> In order to prepare to this situation, split out the code which checks
> all endpoints in
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> sun4i_drv_add_endpoints() has a memory leak since it uses of_node_put()
> when remote is equal to NULL and does nothing when remote has a valid
> pointer.
>
> Invert the logic to fix memory leak.
>
> Signed-off-by: Jernej Skrabec
Given
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> TV TCONs (channel 1 only) are always connected to TV or HDMI encoder.
> Because of that, all output endpoints on such TCON node will point to a
> encoder which is part of component framework.
>
> Correct current graph traversing algorithm
Hi,
So I'm late to the party, but...
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote:
> As already described in DT binding, TCON TOP is responsible for
> configuring display pipeline. In this initial driver focus is on HDMI
> pipeline, so TVE and LCD configuration is not implemented.
>
>
Hi Dave,
One more for 4.19. We don't have any big change on this one,
it is mostly drivers updates here. Please pull.
Regards,
Gustavo
drm-misc-next-2018-06-27:
drm-misc-next for 4.19:
Cross-subsystem Changes:
devicetree documentation
dt-bindings defintions for sun8i (Jernej Skrabec)
Core
On Wed, Jun 27, 2018 at 2:48 PM, Doug Anderson wrote:
> Hi,
>
> On Tue, Jun 26, 2018 at 10:27 AM, Rob Clark wrote:
>> On Tue, Jun 26, 2018 at 11:55 AM, Doug Anderson
>> wrote:
>>> Hi,
>>>
>>> On Mon, Jun 25, 2018 at 9:45 PM, Sandeep Panda
>>> wrote:
From: Abhinav Kumar
https://bugzilla.kernel.org/show_bug.cgi?id=199621
Matthew Trescott (matthewtresc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #13 from dwagner ---
(In reply to Andrey Grodzovsky from comment #12)
> Can you load the kernel with grub command line amdgpu.vm_update_mode=3 to
> force CPU VM update mode and see if this helps ?
Sure. Too early yet to say
https://bugs.freedesktop.org/show_bug.cgi?id=106942
--- Comment #3 from Andrey Grodzovsky ---
(In reply to Olaf 'Rhialto' Seibert from comment #2)
> On the Launchpad ticket I got a reqest to try a pre-built mainline kernel
> from Ubuntu. So I had this one tested:
> Linux xa-xubu
https://bugs.freedesktop.org/show_bug.cgi?id=106942
Andrey Grodzovsky changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=106942
--- Comment #2 from Olaf 'Rhialto' Seibert ---
On the Launchpad ticket I got a reqest to try a pre-built mainline kernel from
Ubuntu. So I had this one tested:
Linux xa-xubu 4.18.0-041800rc1-generic #201806162031 SMP Sun Jun 17 00:34:22
UTC
https://bugs.freedesktop.org/show_bug.cgi?id=106263
--- Comment #8 from Harry Wentland ---
Bisected commit is different from what was originally reported (both in
generic_reg_update_ex, but otherwise completely different codepaths and cases).
The bisected commit is fixed in 4.18 rc1 by this
1;5202;0c
On Wed, Jun 27, 2018 at 08:02:15PM +0200, Maxime Ripard wrote:
> On Mon, Jun 25, 2018 at 02:02:40PM +0200, Jernej Skrabec wrote:
> > This series adds support for R40 HDMI pipeline. It is a bit special
> > than other already supported pipelines because it has additional unit
> > called
https://bugs.freedesktop.org/show_bug.cgi?id=105018
Harry Wentland changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi,
On Tue, Jun 26, 2018 at 10:27 AM, Rob Clark wrote:
> On Tue, Jun 26, 2018 at 11:55 AM, Doug Anderson wrote:
>> Hi,
>>
>> On Mon, Jun 25, 2018 at 9:45 PM, Sandeep Panda wrote:
>>> From: Abhinav Kumar
>>>
>>> Setting the DSI PLL src in probe doesn't provide the clock
>>> driver sufficient
Hi!
On Wed, Jun 27, 2018 at 06:45:14PM +0200, Jernej Skrabec wrote:
> Initial implementation of DE2 planes only supported fixed zpos.
>
> Expand implementation with configurable zpos property.
>
> Signed-off-by: Jernej Skrabec
Thanks for that work. I guess you should expand a bit on the exact
On 06/27/2018 01:58 AM, Daniel Vetter wrote:
On Tue, Jun 26, 2018 at 8:16 PM, David Lechner wrote:
On 06/20/2018 04:07 AM, Daniel Vetter wrote:
I acked and forwarded the account request, sorry for the delay. Next
time around, poking maintainers on irc helps if this stuff is stuck.
-Daniel
On Mon, Jun 25, 2018 at 02:02:40PM +0200, Jernej Skrabec wrote:
> This series adds support for R40 HDMI pipeline. It is a bit special
> than other already supported pipelines because it has additional unit
> called TCON TOP responsible for relationship configuration between
> mixers, TCONs and
On Tue, Jun 12, 2018 at 01:18:29PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature that is part of the DisplayPort 1.3 standard.
>
> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
> chip that has this
Lucas Stach writes:
> When the hangcheck handler was replaced by the DRM scheduler timeout
> handling we dropped the forward progress check, as this might allow
> clients to hog the GPU for a long time with a big job.
>
> It turns out that even reasonably well behaved clients like the
> Armada
On Thu, Jun 21, 2018 at 08:49:41PM +0200, Linus Walleij wrote:
> The TPO TPG110 bindings were using the DPI bindings (popular
> in the fbdev subsystem) but this misses the finer points
> learned in the DRM subsystem.
>
> We need to augment the bindings for proper DRM integration:
> the timings
https://bugs.freedesktop.org/show_bug.cgi?id=106430
--- Comment #10 from mikhail.v.gavri...@gmail.com ---
Benjamin, I see that in Fedora 29 (Rawhide) with kernel
4.18.0-0.rc0.git9.1.fc29 problem was gone.
But with kernel 4.18.0-0.rc0.git10.1.fc29.x86_64 came yet another problem
(video output at
https://bugs.freedesktop.org/show_bug.cgi?id=106430
--- Comment #9 from Benjamin Xiao ---
I am seeing the same thing with VLC when setting Hardware-accelerated decoding
from Automatic to VA-API.
Fedora 28
RX Vega 64
Kernel 4.17.2
mesa 18.0.5
llvm 6
--
You are receiving this mail because:
You
Hi Lucas,
On Wed, Jun 27, 2018 at 11:34 AM, Lucas Stach wrote:
> When the hangcheck handler was replaced by the DRM scheduler timeout
> handling we dropped the forward progress check, as this might allow
> clients to hog the GPU for a long time with a big job.
>
> It turns out that even
On 2018-06-27 01:50 PM, Chris Wilson wrote:
> Quoting Michel Dänzer (2018-06-26 15:31:47)
>> From: Michel Dänzer
>>
>> Fixes the BUG_ON spuriously triggering under the following
>> circumstances:
>>
>> * ttm_eu_reserve_buffers processes a list containing multiple BOs using
>> the same
https://bugs.freedesktop.org/show_bug.cgi?id=107053
--- Comment #2 from cen.is.i...@gmail.com ---
Created attachment 140367
--> https://bugs.freedesktop.org/attachment.cgi?id=140367=edit
dmesg
attached dmesg
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107053
--- Comment #1 from Michel Dänzer ---
Please attach the corresponding dmesg output as well.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=107053
Michel Dänzer changed:
What|Removed |Added
Attachment #140366|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=106544
--- Comment #8 from Harald Judt ---
I have experienced no bad symptoms caused by this error so far on my R9 390,
but I also get these after hibernate/resume and will try if reverting the patch
mentioned in Comment #4 gets rid of them.
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=107053
Bug ID: 107053
Summary: Flicker/tearing on MacBook Pro 11.5 Ubuntu 18.04
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=106159
--- Comment #17 from Harry Wentland ---
I think we had a fix for that. Can you check if this is still a problem on
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
--
You are receiving this mail because:
You are the
Hi,
On 6/27/2018 8:48 PM, Maarten Lankhorst wrote:
Op 27-06-18 om 16:44 schreef Mahesh Kumar:
This patch implements a callback function "pre_crc_read" which will
be called before crc read. In this function driver can implement and
preparation work required for successfully reading CRC data.
Op 27-06-18 om 16:44 schreef Mahesh Kumar:
> This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
>
> Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
> during open. If application want to wait after read call, it can use
> poll/read blocking read() call.
>
>
Op 27-06-18 om 16:44 schreef Mahesh Kumar:
> This patch implements a callback function "pre_crc_read" which will
> be called before crc read. In this function driver can implement and
> preparation work required for successfully reading CRC data.
>
> Signed-off-by: Mahesh Kumar
> Cc:
On Wed, Jun 27, 2018 at 11:11:57AM +0200, Daniel Vetter wrote:
> On Wed, Jun 27, 2018 at 11:08:48AM +0200, Daniel Vetter wrote:
> > On Tue, Jun 26, 2018 at 08:47:09PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Add a convenience macro for iterating connector->encoder_ids[].
https://bugzilla.kernel.org/show_bug.cgi?id=199425
--- Comment #11 from Harry Wentland (harry.wentl...@amd.com) ---
Should be fixed by https://patchwork.freedesktop.org/patch/230831/ which is
merged into amd-staging-drm-next
--
You are receiving this mail because:
You are watching the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=103277
--- Comment #25 from Harry Wentland ---
Is this fixed on recent kernels? If so, can we close this one?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=105354
Harry Wentland changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi Noralf,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20180627]
[cannot apply to drm/drm-next linus/master drm-exynos/exynos-drm/for-next
v4.18-rc2 v4.18-rc1 v4.17 v4.18-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
https://bugs.freedesktop.org/show_bug.cgi?id=107049
--- Comment #8 from Dan Horák ---
Created attachment 140365
--> https://bugs.freedesktop.org/attachment.cgi?id=140365=edit
Xorg log for 4.17.2-200.fc28 with amdgpu.dc=0
--
You are receiving this mail because:
You are the assignee for the
Fixes: 0654edaa3690 ("misc/mei/hdcp: Component framework for I915 Interface")
Signed-off-by: kbuild test robot
---
mei_hdcp.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index ba75502..146a4be
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20180627]
[cannot apply to v4.18-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
https://bugs.freedesktop.org/show_bug.cgi?id=107049
--- Comment #7 from Dan Horák ---
Created attachment 140364
--> https://bugs.freedesktop.org/attachment.cgi?id=140364=edit
Xorg log for 4.18.0-0.rc2.git2.1.fc29
--
You are receiving this mail because:
You are the assignee for the
This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable inputs, values_cnt we
already gets as part of verify_crc_source.
This patch implements verify_crc_source callback function introduced
earlier in this series.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +
drivers/gpu/drm/i915/intel_pipe_crc.c |
This patch implements "verify_crc_source" callback function for
AMD drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
during open. If application want to wait after read call, it can use
poll/read blocking read() call.
Suggested-by: Ville Syrjälä
Signed-off-by: Mahesh Kumar
Cc:
This patch implements "verify_crc_source" callback function for
rockchip drm driver.
Changes since V1:
- simplify the verification (Jani N)
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20
1 file
This patch implements get_crc_sources callback, which returns list of
all the valid crc sources supported by driver in current platform.
Changes since V1:
- Return array of crc sources
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c |
This patch implements "verify_crc_source" callback function for
rcar drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 40 ++
1 file changed, 40 insertions(+)
diff --git
This patch implements a callback function "get_crc_sources" which
will be called during read of control node. It is an optional
callback function and if driver implements this callback, driver
should print list of available CRC sources in seq_file privided
as an input to the callback.
Changes
This series improves crc-core <-> driver interface.
This series adds following functionality in the crc-core
- Now control node will print all the available sources if
implemented by driver along with current source.
- Setting of sorce will fail if provided source is not supported
- cleanup
This patch adds a new callback function "verify_crc_source" which will
be used during setting the crc source in control node and while opening
data node for crc reading. This will help in avoiding setting of wrong
string for source.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
This patch implements a callback function "pre_crc_read" which will
be called before crc read. In this function driver can implement and
preparation work required for successfully reading CRC data.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
Hi Russell,
Am Dienstag, den 26.06.2018, 17:48 +0200 schrieb Lucas Stach:
> Hi Russell,
>
> Am Dienstag, den 26.06.2018, 16:36 +0100 schrieb Russell King - ARM
> Linux:
> > On Tue, Jun 26, 2018 at 09:17:26AM +0100, Russell King - ARM Linux
> > wrote:
> > > On Tue, Jun 19, 2018 at 02:28:46PM
When the hangcheck handler was replaced by the DRM scheduler timeout
handling we dropped the forward progress check, as this might allow
clients to hog the GPU for a long time with a big job.
It turns out that even reasonably well behaved clients like the
Armada Xorg driver occasionally trip over
https://bugs.freedesktop.org/show_bug.cgi?id=107049
--- Comment #6 from Ben Crocker ---
Dan,
Could you please also post the respective /var/log/Xorg.* logs?
Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.18-rc2 next-20180627]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Tue, Jun 26, 2018 at 05:05:48PM -0700, Vito Caputo wrote:
> Hello,
>
> Beginning with 4.18, when I lock my X server using the `xlock` command,
> and close the lid, upon reopening the lid I am not presented with the
> xlock UI.
>
> The system is not hung. If I blindly enter the password, I
https://bugs.freedesktop.org/show_bug.cgi?id=107045
--- Comment #7 from Michel Dänzer ---
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/lib/str_error_r.c?id=854e55ad289efe7991f0ada85d5846f5afb9
is required for building with GCC 8.
--
You are receiving this
On Wed, Jun 27, 2018 at 1:13 PM, Hans de Goede wrote:
> Hi,
>
>
> On 27-06-18 11:47, Bartlomiej Zolnierkiewicz wrote:
>>
>> On Wednesday, June 27, 2018 11:15:20 AM Daniel Vetter wrote:
>>>
>>> On Tue, Jun 26, 2018 at 08:36:09PM +0200, Hans de Goede wrote:
Hi All,
Here is v4 of
Hi,
On 6/27/2018 5:30 PM, Jani Nikula wrote:
On Tue, 26 Jun 2018, Mahesh Kumar wrote:
This patch implements "verify_crc_source" callback function for
rockchip drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 21
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #12 from Andrey Grodzovsky ---
(In reply to dwagner from comment #2)
> Just to mention this once again: These system crashes still occur, and way
> too frequently to consider the amdgpu driver stable enough for professional
> use.
https://bugzilla.kernel.org/show_bug.cgi?id=199749
--- Comment #24 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
(In reply to notsyncing from comment #23)
> In fact there is no specified graphic work. I just put an Android source
> compilation running and go to bed, besides only firefox
Hi Sandy,
Am Dienstag, 26. Juni 2018, 10:16:44 CEST schrieb Sandy Huang:
> linebuffer mode should be LB_YUV_3840X5 when width is bigger
> than 1280 in yuv mode.
> seperate yuv and rgb case make the scl_vop_cal_lb_mode() logic
> is clearer.
>
> Signed-off-by: Sandy Huang
applied to
Am Dienstag, 26. Juni 2018, 21:47:13 CEST schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> Use drm_crtc_mask() where appropriate.
>
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Signed-off-by: Ville Syrjälä
thanks for that small cleanup, applied to drm-misc-next
Thanks
Heiko
Am Mittwoch, den 27.06.2018, 10:07 -0300 schrieb Fabio Estevam:
> > From: Fabio Estevam
>
> platform_device_register_simple() may fail, so we should better
> check its return value and propagate it in the case of error.
>
> > Cc:
> Fixes: 246774d17fc0 ("drm/etnaviv: remove the need for a
On Wed, 2018-06-27 at 10:07 -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> platform_device_register_simple() may fail, so we should better
> check its return value and propagate it in the case of error.
>
> Cc:
> Fixes: 246774d17fc0 ("drm/etnaviv: remove the need for a gpu-subsystem DT
Make full use of the generic fbdev client.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +--
drivers/gpu/drm/tinydrm/ili9225.c | 1 -
drivers/gpu/drm/tinydrm/mi0283qt.c | 1 -
drivers/gpu/drm/tinydrm/st7586.c
This adds a drm_fbdev_generic_setup() function that sets up generic
fbdev emulation with client callbacks for restore, hotplug and
unregister.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 117
include/drm/drm_fb_helper.h | 7
Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has
moved to drm_fbdev_generic_setup().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_cma_helper.c | 21 -
include/drm/drm_fb_cma_helper.h | 3 ---
2 files changed, 24
Print the names of the internal clients currently attached.
Reviewed-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 28
drivers/gpu/drm/drm_debugfs.c | 7 +++
include/drm/drm_client.h | 3 +++
3 files changed, 38
This switches the CMA helper drivers that use its fbdev emulation over
to the generic fbdev emulation. It's the first phase of using generic
fbdev. A later phase will use DRM client callbacks for the
lastclose/hotplug/remove callbacks.
There are currently 2 fbdev init/fini functions:
-
Add client callbacks and hook them up.
Add a list of clients per drm_device.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 92 -
drivers/gpu/drm/drm_drv.c | 7 +++
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
This the beginning of an API for in-kernel clients.
First out is a way to get a framebuffer backed by a dumb buffer.
Only GEM drivers are supported.
The original idea of using an exported dma-buf was dropped because it
also creates an anonomous file descriptor which doesn't work when the
buffer
This is the first step in getting generic fbdev emulation.
A drm_fb_helper_funcs.fb_probe function is added which uses the
DRM client API to get a framebuffer backed by a dumb buffer.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 192
This patchset adds generic fbdev emulation for drivers that supports GEM
based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An
API is begun to support in-kernel clients in general.
The only change this time is reworking client removal (again). Drop
reference counting, only allow
These are needed for pl111 to use the generic fbdev emulation.
Cc: Eric Anholt
Signed-off-by: Noralf Trønnes
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/pl111/pl111_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
From: Fabio Estevam
platform_device_register_simple() may fail, so we should better
check its return value and propagate it in the case of error.
Cc:
Fixes: 246774d17fc0 ("drm/etnaviv: remove the need for a gpu-subsystem DT node")
Signed-off-by: Fabio Estevam
---
Changes since v3:
- Only set
1 - 100 of 195 matches
Mail list logo
