Hi, Hsin-Yi:
On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote:
> There is no clk_prepare() called in mtk_drm_crtc_reset(), when unbinding
> drm device, mtk_drm_crtc_destroy() will be triggered, and the clocks will
> be disabled and unprepared in mtk_crtc_ddp_clk_disable. If clk_unprepare()
>
https://bugs.freedesktop.org/show_bug.cgi?id=110658
--- Comment #4 from Timothy Arceri ---
I've run it on llvm 8 and mesa 19.0.5 and was unable to reproduce the issues
seen in the screen capture on my Vega 64.
--
You are receiving this mail because:
You are the assignee for the
On Sun, May 19, 2019 at 9:25 AM Jitao Shi wrote:
> @@ -1045,12 +1045,6 @@ static int mtk_dsi_bind(struct device *dev, struct
> device *master, void *data)
> return ret;
> }
>
> - ret = mipi_dsi_host_register(>host);
> - if (ret < 0) {
> -
On Wed, May 29, 2019 at 9:35 AM CK Hu wrote:
>
> Hi, Hsin-yi:
>
> On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote:
> > move mipi_dsi_host_unregister() to .remove since mipi_dsi_host_register()
> > is called in .probe.
>
> In the latest kernel [1], mipi_dsi_host_register() is called in
>
On Tue, May 28, 2019 at 07:42:19PM -0600, Jeffrey Hugo wrote:
> > > Do you know if the nexus 5 has a video or command mode panel? There
> > > is some glitchyness with vblanks and command mode panels.
> >
> > Its in command mode. I know this because I see two 'pp done time out'
> > messages, even
On Tue, May 28, 2019 at 8:15 PM Rob Clark wrote:
>
> On Tue, May 28, 2019 at 6:17 PM Brian Masney wrote:
> >
> > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> > >
> > > > Here is a patch series that adds initial display
On Tue, May 28, 2019 at 6:17 PM Brian Masney wrote:
>
> On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> >
> > > Here is a patch series that adds initial display support for the LG
> > > Nexus 5 (hammerhead) phone. It's not
The variable edid returned by psb_intel_sdvo_get_edid()
was never freed.
Signed-off-by: Young Xiao <92siuy...@gmail.com>
---
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
On Tue, May 28, 2019 at 7:37 PM Brian Masney wrote:
>
> On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
> > On Tue, May 28, 2019 at 7:17 PM Brian Masney wrote:
> > >
> > > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > > On Thu, May 9, 2019 at 4:04 AM Brian
On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
> On Tue, May 28, 2019 at 7:17 PM Brian Masney wrote:
> >
> > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> > >
> > > > Here is a patch series that adds
Hi, Hsin-yi:
On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote:
> move mipi_dsi_host_unregister() to .remove since mipi_dsi_host_register()
> is called in .probe.
In the latest kernel [1], mipi_dsi_host_register() is called in
mtk_dsi_bind(), I think we don't need this part.
[1]
On Tue, May 28, 2019 at 7:17 PM Brian Masney wrote:
>
> On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> >
> > > Here is a patch series that adds initial display support for the LG
> > > Nexus 5 (hammerhead) phone. It's not
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
>
> > Here is a patch series that adds initial display support for the LG
> > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > of these patches are RFC
https://bugs.freedesktop.org/show_bug.cgi?id=110787
--- Comment #1 from Manuel Vögele ---
Created attachment 144367
--> https://bugs.freedesktop.org/attachment.cgi?id=144367=edit
Output of glxinfo
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110787
Bug ID: 110787
Summary: Glitches in console of the Julia language plugin for
Atom (Juno)
Product: Mesa
Version: 19.0
Hardware: x86-64 (AMD64)
OS: Linux
On Tue, May 28, 2019 at 2:45 PM Jordan Crouse wrote:
>
> On Tue, May 28, 2019 at 10:06:12AM -0700, Jeffrey Hugo wrote:
> > The A540 is a derivative of the A530, and is found in the MSM8998 SoC.
> >
> > Signed-off-by: Jeffrey Hugo
> > ---
> > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22
On Tue, May 28, 2019 at 10:06:12AM -0700, Jeffrey Hugo wrote:
> The A540 is a derivative of the A530, and is found in the MSM8998 SoC.
>
> Signed-off-by: Jeffrey Hugo
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22 +++
> drivers/gpu/drm/msm/adreno/a5xx_power.c| 76
Sigh ... looks like this doesn't actually do what we want. See the
last couple comments in:
https://bugs.freedesktop.org/show_bug.cgi?id=110660
It seems to work as expected with "mode" instead of "adjusted_mode".
Does that make sense? It kinda does based on the later code, which
copies mode into
On Tue, May 28, 2019 at 02:26:45PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This comment doesn't make any sense, remove it.
>
> Suggested-by: Jordan Crouse
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by:
On Wed, 29 May 2019 at 02:47, Emil Velikov wrote:
>
> On 2019/05/28, Koenig, Christian wrote:
> > Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > > On 2019/05/28, Daniel Vetter wrote:
> > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> > >> wrote:
> > >>> Am 28.05.19 um 09:38 schrieb
https://bugs.freedesktop.org/show_bug.cgi?id=110786
Bug ID: 110786
Summary: Adaptive sync (vrr, freesync): Cinnamon DE isn't
blacklisted properly
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=110786
dron1...@gmail.com changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving
This patch series enables HDR output metadata support in amdgpu using the
DRM HDR interface merged in drm-misc-next. Enabled for DCE and DCN ASICs
over DP and HDMI.
It's limited to static HDR metadata support for now since that's all the
DRM interface supports. It requires a modeset for entering
[Why]
We can issue HDR static metadata as part of stream updates for
non-modesets as long as we force a modeset when entering or exiting HDR.
This avoids unnecessary blanking for simple metadata updates.
[How]
When changing scaling and abm for the stream also check if HDR has
changed and send
[Why]
For userspace to send static HDR metadata to the display we need to
attach the property on the connector and send it to DC.
[How]
The property is attached to HDMI and DP connectors. Since the metadata
isn't actually available when creating the connector this isn't a
property we can
https://bugs.freedesktop.org/show_bug.cgi?id=106302
--- Comment #4 from s...@vestigecounty.com ---
Thank you for being exactly on point, it turns out I was using a frivolous
interpretation of "change" rather than the one specified in OpenGL ES. The bug
can safely be closed as invalid, as fence
From: Sean Paul
This comment doesn't make any sense, remove it.
Suggested-by: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
From: Sean Paul
There's a comment in _dpu_kms_hw_destroy() that reads "safe to call
these more than once during shutdown", referring to
_dpu_kms_mmu_destroy(). Unfortunately that's not the case, mmu_destroy
will fail hard if it's called twice. So fix that function to ensure it
can be called
On 5/28/19 12:05 PM, Thomas Hellstrom wrote:
> On 5/28/19 7:00 PM, Lendacky, Thomas wrote:
>> On 5/28/19 11:32 AM, Koenig, Christian wrote:
>>> Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
> On 5/28/19 10:17 AM, Koenig,
On Tue, May 28, 2019 at 1:05 PM Sam Ravnborg wrote:
>
> Hi Christian.
>
> On Tue, May 28, 2019 at 06:25:54PM +0200, Christian König wrote:
> > From: Chunming Zhou
> >
> > add ticket for display bo, so that it can preempt busy bo.
> >
> > v2: fix stupid rebase error
> >
> > Change-Id:
The A540 is a derivative of the A530, and is found in the MSM8998 SoC.
Signed-off-by: Jeffrey Hugo
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22 +++
drivers/gpu/drm/msm/adreno/a5xx_power.c| 76 +-
drivers/gpu/drm/msm/adreno/adreno_device.c | 18 +
On Mon, 27 May 2019 18:56:20 +0800 Christian Koenig wrote:
> Thanks for the comments, but you are looking at a completely outdated
> patchset.
>
> If you are interested in the newest one please ping me and I'm going to CC you
> when I send out the next version.
>
Ping...
Thanks
Hillf
On Tue, May 21, 2019 at 12:27 AM Souptick Joarder wrote:
>
> Convert to use hmm_range_fault().
Any comment on this patch ?
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Hi Christian.
On Tue, May 28, 2019 at 06:25:54PM +0200, Christian König wrote:
> From: Chunming Zhou
>
> add ticket for display bo, so that it can preempt busy bo.
>
> v2: fix stupid rebase error
>
> Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
What is this?
I do not recall seeing
On 5/28/19 7:00 PM, Lendacky, Thomas wrote:
On 5/28/19 11:32 AM, Koenig, Christian wrote:
Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
On 5/28/19 10:17 AM, Koenig, Christian wrote:
Hi Thomas,
Am 28.05.19 um 17:11 schrieb Thomas
Hi!
Dne nedelja, 26. maj 2019 ob 23:18:46 CEST je Jonas Karlman napisal(a):
> Add support for HDR metadata using the hdr_output_metadata connector
> property, configure Dynamic Range and Mastering InfoFrame accordingly.
>
> A drm_infoframe flag is added to dw_hdmi_plat_data that platform
Hi Laurent.
On Tue, May 28, 2019 at 07:50:52PM +0300, Laurent Pinchart wrote:
> Hi Sam,
>
> On Tue, May 28, 2019 at 06:42:13PM +0200, Sam Ravnborg wrote:
> > On Tue, May 28, 2019 at 05:12:31PM +0300, Laurent Pinchart wrote:
> > > In dual-link LVDS mode, the LVDS1 encoder is used as a companion
On 5/28/19 11:32 AM, Koenig, Christian wrote:
> Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
>> On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
>>> On 5/28/19 10:17 AM, Koenig, Christian wrote:
Hi Thomas,
Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
> Hi, Tom,
Hi Laurent.
> > >
> > > +Optional properties:
> > > +
> > > +- renesas,companion : phandle to the companion LVDS encoder. This
> > > property is
> > > + mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall
> > > point to
> > > + the second encoder to be used as a companion in
Hi Sam,
On Tue, May 28, 2019 at 06:42:13PM +0200, Sam Ravnborg wrote:
> On Tue, May 28, 2019 at 05:12:31PM +0300, Laurent Pinchart wrote:
> > 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
Hi Sam,
On Tue, May 28, 2019 at 06:37:30PM +0200, Sam Ravnborg wrote:
> On Tue, May 28, 2019 at 05:12:28PM +0300, Laurent Pinchart wrote:
> > 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
> >
On 28/05/2019 18:41, Emil Velikov wrote:
On 2019/05/28, Tomi Valkeinen wrote:
On 22/05/2019 18:02, Emil Velikov wrote:
From: Emil Velikov
Cc: Tomi Valkeinen
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
1 file changed, 1 insertion(+), 15
On 2019/05/28, Koenig, Christian wrote:
> Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > On 2019/05/28, Daniel Vetter wrote:
> >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> >> wrote:
> >>> Am 28.05.19 um 09:38 schrieb Daniel Vetter:
> [SNIP]
> > Might be a good idea looking
Hi Laurent.
Nice series with small and well described patches.
> On Tue, May 28, 2019 at 05:12:24PM +0300, Laurent Pinchart wrote:
>> 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
Hi Laurent.
On Tue, May 28, 2019 at 05:12:31PM +0300, Laurent Pinchart wrote:
> 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
>
Hi Laurent.
Reading through this nice series.
On Tue, May 28, 2019 at 05:12:28PM +0300, Laurent Pinchart wrote:
> 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
Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
> On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
>> On 5/28/19 10:17 AM, Koenig, Christian wrote:
>>> Hi Thomas,
>>>
>>> Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
Hi, Tom,
Thanks for the reply. The question is not
On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
> On 5/28/19 10:17 AM, Koenig, Christian wrote:
> > Hi Thomas,
> >
> > Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
> > > Hi, Tom,
> > >
> > > Thanks for the reply. The question is not graphics specific, but
> > > lies
> > > in your
The messages about amdgpu_cs_list_validate are duplicated because the
caller will complain into the logs as well and we can also get
interrupted by a signal here.
Also fix the the caller to not report -EAGAIN from validation.
Signed-off-by: Christian König
---
From: Chunming Zhou
add ticket for display bo, so that it can preempt busy bo.
v2: fix stupid rebase error
Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21
And only move them in on validation. This allows for better control
when multiple processes are fighting over those resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner
Move BOs which are currently in a lower domain to the new
LRU before allocating backing space while validating.
This makes sure that we always have enough entries on the
LRU to allow for other processes to wait for an operation
to complete.
v2: generalize the test
Signed-off-by: Christian König
This avoids OOM situations when we have lots of threads
submitting at the same time.
v3: apply this to the whole driver, not just CS
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-
We are already doing this for DMA-buf imports and also for
amdgpu VM BOs for quite a while now.
If this doesn't run into any problems we are probably going
to stop removing BOs from the LRU altogether.
v2: drop BUG_ON from ttm_bo_add_to_lru
Signed-off-by: Christian König
---
We tried this once before, but that turned out to be more
complicated than thought. With all the right prerequisites
it looks like we can do this now.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 127 ++-
1 file changed, 66 insertions(+), 61
If drivers don't prefer a system memory placement
they should not but it into the placement list first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
When a signal arrives we should return immediately for
handling it and not try other placements first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
Am 28.05.19 um 18:10 schrieb Emil Velikov:
> On 2019/05/28, Daniel Vetter wrote:
>> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
>> wrote:
>>> Am 28.05.19 um 09:38 schrieb Daniel Vetter:
[SNIP]
> Might be a good idea looking into reverting it partially, so that at
> least
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #2 from Richard Thier ---
The "gallium/winsys/radeon/drm/radeon_drm_bo.c" is indeed used by r300 because
I have put a log in it.
--
You are receiving this mail because:
You are the assignee for the
On 2019/05/28, Daniel Vetter wrote:
> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> wrote:
> >
> > Am 28.05.19 um 09:38 schrieb Daniel Vetter:
> > > [SNIP]
> > >> Might be a good idea looking into reverting it partially, so that at
> > >> least command submission and buffer allocation is
Hi,
On 28/05/2019 18:09, Adam Ford wrote:
On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen wrote:
Hi,
On 10/05/2019 22:42, Adam Ford wrote:
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
On 5/28/19 10:17 AM, Koenig, Christian wrote:
> Hi Thomas,
>
> Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
>> Hi, Tom,
>>
>> Thanks for the reply. The question is not graphics specific, but lies
>> in your answer further below:
>>
>> On 5/28/19 4:48 PM, Lendacky, Thomas wrote:
>>> On 5/28/19
On 2019/05/28, Tomi Valkeinen wrote:
> On 22/05/2019 18:02, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Cc: Tomi Valkeinen
> > Signed-off-by: Emil Velikov
> > ---
> > drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
> > 1 file changed, 1 insertion(+), 15 deletions(-)
> >
>
On Tue, May 28, 2019 at 11:13:39AM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Instead of reaching into dev->primary for debugfs_root, use the minor
> passed into debugfs_init.
>
> This avoids creating a debug directory under /sys/kernel/debug/debug
> and instead uses /sys/kernel/debug/dri//
On Tue, May 28, 2019 at 8:13 AM Sean Paul wrote:
>
> From: Sean Paul
>
> Instead of reaching into dev->primary for debugfs_root, use the minor
> passed into debugfs_init.
>
> This avoids creating a debug directory under /sys/kernel/debug/debug
> and instead uses /sys/kernel/debug/dri//
>
> Since
Hi James,
On Mon, May 27, 2019 at 07:51:18AM +0100, james qian wang (Arm Technology
China) wrote:
> Hi Brian & Ville:
>
> komed has a format+modifier check before the fb size check.
> and for komeda_fb_create, the first step is do the format+modifier
> check, the size check is the furthur check
> Am 28.05.2019 um 17:09 schrieb Adam Ford :
>
> On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen wrote:
>>
>> Hi,
>>
>> On 10/05/2019 22:42, Adam Ford wrote:
>>> Currently the source code is compiled using hard-coded values
>>> from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
Hi Thomas,
Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
> Hi, Tom,
>
> Thanks for the reply. The question is not graphics specific, but lies
> in your answer further below:
>
> On 5/28/19 4:48 PM, Lendacky, Thomas wrote:
>> On 5/28/19 2:31 AM, Thomas Hellstrom wrote:
>> [SNIP]
>> As for kernel
From: Sean Paul
Instead of reaching into dev->primary for debugfs_root, use the minor
passed into debugfs_init.
This avoids creating a debug directory under /sys/kernel/debug/debug
and instead uses /sys/kernel/debug/dri//
Since we're now putting everything under */dri/, there's no
need to
Hi, Tom,
Thanks for the reply. The question is not graphics specific, but lies in
your answer further below:
On 5/28/19 4:48 PM, Lendacky, Thomas wrote:
On 5/28/19 2:31 AM, Thomas Hellstrom wrote:
Hi, Tom,
Could you shed some light on this?
I don't have a lot of GPU knowledge, so let me
On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen wrote:
>
> Hi,
>
> On 10/05/2019 22:42, Adam Ford wrote:
> > 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
Am 28.05.19 um 16:48 schrieb Lendacky, Thomas:
On 5/28/19 2:31 AM, Thomas Hellstrom wrote:
Hi, Tom,
Could you shed some light on this?
I don't have a lot of GPU knowledge, so let me start with an overview of
how everything should work and see if that answers the questions being
asked.
First,
On 5/28/19 2:31 AM, Thomas Hellstrom wrote:
> Hi, Tom,
>
> Could you shed some light on this?
I don't have a lot of GPU knowledge, so let me start with an overview of
how everything should work and see if that answers the questions being
asked.
First, SME:
The encryption bit is bit-47 of a
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
Tested-by: Jacopo Mondi
---
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
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
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
---
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
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 19
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
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
Tested-by: Jacopo Mondi
---
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
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo
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
Add the new renesas,companion property to the LVDS0 node to point to the
companion LVDS encoder LVDS1.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 ++
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 ++
2
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
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
From: Ville Syrjälä
CH7511 eDP->LVDS bridge doesn't seem to set SINK_COUNT properly
causing i915 to detect it as disconnected. Add a quirk to ignore
SINK_COUNT on these devices.
Cc: David S.
Cc: Peteris Rudzusiks
Tested-by: Peteris Rudzusiks
Bugzilla:
From: Ville Syrjälä
CH7511 doesn't update SINK_COUNT properly so in order to detect
the device as connected we have to ignore SINK_COUNT.
In order to have access to the quirk list early enough we
must move the drm_dp_read_desc() call to happen earlier.
We can also skip re-reading this on eDP
On Tue, 28 May 2019 15:53:48 +0200
Boris Brezillon wrote:
> Hi Steve,
>
> On Thu, 16 May 2019 17:21:39 +0100
> Steven Price wrote:
>
>
> > >> +static void panfrost_perfcnt_setup(struct panfrost_device *pfdev)
> > >> +{
> > >> + u32 cfg;
> > >> +
> > >> + /*
> > >> +*
Hi Steve,
On Thu, 16 May 2019 17:21:39 +0100
Steven Price wrote:
> >> +static void panfrost_perfcnt_setup(struct panfrost_device *pfdev)
> >> +{
> >> + u32 cfg;
> >> +
> >> + /*
> >> +* Always use address space 0 for now.
> >> +* FIXME: this needs to be updated when
On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> Here is a patch series that adds initial display support for the LG
> Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> of these patches are RFC until we can get it fully working.
>
> The phones boots into terminal mode,
https://bugs.freedesktop.org/show_bug.cgi?id=110783
--- Comment #1 from AngryPenguin ---
Created attachment 144363
--> https://bugs.freedesktop.org/attachment.cgi?id=144363=edit
inxi
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110783
Bug ID: 110783
Summary: Mesa 19.1 rc crashing MPV with VAAPI
Product: Mesa
Version: 19.1
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
Hi Jani.
On Tue, May 28, 2019 at 03:54:48PM +0300, Jani Nikula wrote:
> On Sun, 26 May 2019, Sam Ravnborg wrote:
> > Do not require users of include/drm/drm_auth.h to include
> > other files just to let it build.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Maarten Lankhorst
> > Cc: Maxime
On Sun, 26 May 2019, Sam Ravnborg wrote:
> Do not require users of include/drm/drm_auth.h to include
> other files just to let it build.
>
> Signed-off-by: Sam Ravnborg
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
>
Hi Jacopo,
On Tue, May 28, 2019 at 11:35:50AM +0200, Jacopo Mondi wrote:
> Hi Laurent,
> a small note.
>
> On Sun, May 12, 2019 at 12:06:58AM +0300, Laurent Pinchart wrote:
> > In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
> > sends odd-numbered pixels to the LVDS1
https://bugs.freedesktop.org/show_bug.cgi?id=110725
Lakshmi changed:
What|Removed |Added
Component|DRM/Intel |IGT
Hi Jacopo,
On Tue, May 28, 2019 at 11:28:47AM +0200, Jacopo Mondi wrote:
> On Sun, May 12, 2019 at 12:06:56AM +0300, Laurent Pinchart wrote:
> > 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
> >
On 28.05.2019 10:27, Tomi Valkeinen wrote:
> We need to know the link bandwidth to filter out modes we cannot
> support, so we need to have read the display props before doing the
> filtering.
>
> To ensure we have up to date display props, call tc_get_display_props()
> in the beginning of
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #1 from Richard Thier ---
PS.: As you can see I already have the mesa sources and can build and test my
own in case there is any kind of idea what I should search for...
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=94043
--- Comment #16 from Mike Lothian ---
Unless you're running an old r300 card I recommend you open your own bug
Make sure you state what versions of Mesa you're using and which versions (if
any) worked and take a look at
1 - 100 of 211 matches
Mail list logo
