https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #86 from evan.q...@amd.com ---
Can anyone give the attachment 144237 a try and let me know the result?
And if the issue still exists, please apply attachment 144238 also which can
provide more debug outputs.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #85 from evan.q...@amd.com ---
Created attachment 144238
--> https://bugs.freedesktop.org/attachment.cgi?id=144238=edit
Added some verbose debugs
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #84 from evan.q...@amd.com ---
Created attachment 144237
--> https://bugs.freedesktop.org/attachment.cgi?id=144237=edit
Clean up the fast uclk switch settings on SMU7 asics
--
You are receiving this mail because:
You are the
On Thu, May 09, 2019 at 05:50:36PM +0200, Noralf Trønnes wrote:
> I can't see this in for-5.2 or linux-next. You also gave me a topic
> branch for this, but I wasn't able to get an r-b on the drm patch in the
> few days left before the -rc5 cutoff in the drm subsystem. This means
> that the patch
Add a new optional renesas,companion property to point to the companion
LVDS encoder. This is used to support dual-link operation where the main
LVDS encoder splits even-numbered and odd-numbered pixels between the
two LVDS encoders.
The new property doesn't control the mode of operation, it only
Extend the drm_bridge_timings structure with a new dual_link field to
indicate that the bridge's input bus carries data on two separate
physical links. The first use case is LVDS dual-link mode where even-
and odd-numbered pixels are transferred on separate LVDS links.
Signed-off-by: Laurent
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
---
.../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 21
Set a drm_bridge_timings in the drm_bridge, and use it to report the
input bus mode (single-link or dual-link). The other fields of the
timings structure are kept to 0 as they do not apply to LVDS buses.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Ignore disabled remote device
---
In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
can't be used in that case, don't create an encoder and connector for
it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c |
The DRM core and DU driver guarantee that the LVDS bridge will not be
double-enabled or double-disabled. Remove the corresponding unnecessary
checks.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 19 ---
1 file changed, 19 deletions(-)
diff --git
In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
sends odd-numbered pixels to the LVDS1 encoder for transmission on a
separate link.
To implement support for this mode of operation, determine if the LVDS
connection operates in dual-link mode by querying the next device in
Add the new renesas,companion property to the LVDS0 node to point to the
companion LVDS encoder LVDS1.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 ++
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git
The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
dual-link. In dual-link mode both input ports are used to carry even-
and odd-numbered pixels separately. Document this in the DT bindings,
along with the related rules governing port and usage.
Signed-off-by: Laurent Pinchart
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
---
.../arm64/boot/dts/renesas/r8a77995-draak.dts | 21
Hello everybody,
This patch series implements support for LVDS dual-link mode in the
R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024
LVDS decoder driver.
LVDS dual-link is a mode of operation where two individual LVDS links
are operated together to carry even- and
Hi Kieran,
On Wed, Apr 24, 2019 at 09:15:22AM +0100, Kieran Bingham wrote:
> On 06/03/2019 23:23, Laurent Pinchart wrote:
> > The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and
> > DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the
> > new
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #92 from Diego Viola ---
(In reply to komqinxit from comment #91)
> xfce4-terminal and Geany bugs seem to be this
> https://bugs.freedesktop.org/show_bug.cgi?id=110355 and solved with mesa
> 19.0.4.
That's good to know, thanks.
--
Hi Kieran,
On Wed, Apr 24, 2019 at 09:12:48AM +0100, Kieran Bingham wrote:
> On 06/03/2019 23:23, Laurent Pinchart wrote:
> > Extend the drm_bridge_timings structure with a new dual_link field to
> > indicate that the bridge's input bus carries data on two separate
> > physical links. The first
https://bugs.freedesktop.org/show_bug.cgi?id=104604
Jan Vesely changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=99312
Jan Vesely changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
Hi Matt,
Thank you for the patch.
On Wed, Apr 24, 2019 at 01:22:27PM +, Matt Redfearn wrote:
> The driver currently sets register 0xfb (Low Refresh Rate) based on the
> value of mode->vrefresh. Firstly, this field is specified to be in Hz,
> but the magic numbers used by the code are Hz *
Hi Daniel,
On Tue, Apr 23, 2019 at 09:18:52PM +0200, Daniel Vetter wrote:
> On Tue, Apr 23, 2019 at 5:45 PM Laurent Pinchart wrote:
> > On Tue, Apr 23, 2019 at 09:25:54AM +0200, Daniel Vetter wrote:
> >> On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> >>> On Thu, Apr 18, 2019
Hi Paul,
On Tue, Apr 23, 2019 at 06:54:49PM +0200, Paul Kocialkowski wrote:
> Le dimanche 21 avril 2019 à 01:40 +0300, Laurent Pinchart a écrit :
> > On Thu, Apr 18, 2019 at 01:49:54PM +0200, Paul Kocialkowski wrote:
> >> On Thu, 2019-04-18 at 11:02 +0200, Maxime Ripard wrote:
> >>> On Thu, Apr
Hi Sean,
Thank you for the patch.
On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Everyone who implements connector_helper_funcs->atomic_check reaches
> into the connector state to get the atomic state. Instead of continuing
> this pattern, change the callback
Currently the source code is compiled using hard-coded values
from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
clock divider value to be moved to the device tree and be changed
without having to recompile the kernel.
Signed-off-by: Adam Ford
diff --git
On (05/10/19 11:15), Petr Mladek wrote:
[..]
> arch/x86/kernel/smp.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/arch/x86/kernel/smp.c
> +++ b/arch/x86/kernel/smp.c
> @@ -124,7 +124,8 @@ static bool smp_no_nmi_ipi = false;
> */
> static void
On Fri, May 10, 2019 at 11:08:42AM +0100, Colin King wrote:
> From: Colin Ian King
>
> In the case where is_enable is false and lo_base_addr is non-zero the
> variable ret has not been initialized and is being checked for non-zero
> and potentially garbage is being returned. Fix this by not
On Thu 2019-05-09 18:43:12, Daniel Vetter wrote:
> One thing to keep in mind is that the kernel is already dying, and
> things will come crashing down later on
This is important information. I havn't seen it mentioned earlier.
> (I've seen this only in dmesg
> tails capture in pstore in our CI,
On 5/10/19 11:46 PM, Michel Dänzer wrote:
>> Given that the bug is a bit a mess I think we need to add a bit more
>> context here in the commit message. My understanding:
>>
>> Goal of the revert commit was to make the integrated boot device the
>> primary one, if we can't detect which one is the
nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom
struct. This patch adds copying of struct member named "or", which
previously was left uninitialized in the duplicated structure.
Due to this bug, incorrect nhsync and nvsync values were sometimes used.
In my particular case, that
Fix sparse warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_clk_mgr.c:260:5:
warning: symbol 'dcn10_set_dispclk' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_clk_mgr.c:286:5:
warning: symbol 'dcn10_set_dprefclk' was not declared.
On Thu 2019-05-09 22:06:33, Daniel Vetter wrote:
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then
On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote:
> However, the reply is incorrect. Kselftest in-kernel tests (which
> is the context here) can be configured as built in instead of as
> a module, and built in a UML kernel. The UML kernel can boot,
> running the in-kernel tests
From: Colin Ian King
The variable actual_clock is being initialized however this is never
read and later it is being reassigned to a new value. The initialization
is redundant and hence can be removed.
Addresses-Coverity: ("Unused Value")
Signed-off-by: Colin Ian King
---
If SVGA_3D_CMD_DX_DEFINE_RENDERTARGET_VIEW is called with a surface
ID of SVGA3D_INVALID_ID, the srf struct will remain NULL after
vmw_cmd_res_check(), leading to a null pointer dereference in
vmw_view_add().
Signed-off-by: Murray McAllister
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4
35 matches
Mail list logo
