On Wed, May 29, 2019 at 08:51:21AM +0200, Boris Brezillon wrote:
> Right now, the BO is mapped as a cached region when ->vmap() is called
> and the underlying object is not a dmabuf.
> Doing that makes cache management a bit more complicated (you'd need
> to call dma_map/unmap_sg() on the ->sgt fie
On Tue, 28 May 2019 16:01:15 +0200
Boris Brezillon wrote:
> 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)
>
Right now, the BO is mapped as a cached region when ->vmap() is called
and the underlying object is not a dmabuf.
Doing that makes cache management a bit more complicated (you'd need
to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about
to be passed to the GPU/CPU), so let's map t
On Wed, May 29, 2019 at 3:17 AM Brian Masney wrote:
> It's in low speed mode but its usable.
How low speed is that?
> I assume that it's related to the
> vblank events not working properly?
They are only waiting for 50 ms before timing out, I raised it
to 100ms in the -next kernel. I'm still s
On Wed, May 29, 2019 at 1:58 PM CK Hu wrote:
>
> 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 un
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 bug.
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(&dsi->host);
> - if (ret < 0) {
> - de
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
> mtk_
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 o
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 fu
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
b/drivers/gpu/drm/gma500/psb_intel_sdvo
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 Mas
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 initia
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]
https://git.
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 fu
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 unti
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&action=edit
Output of glxinfo
--
You are receiving this mail because:
You are the assignee for the bug.
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 (Al
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: Jord
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 Danie
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)
O
https://bugs.freedesktop.org/show_bug.cgi?id=110786
dron1...@gmail.com changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving t
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 a
[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 the
[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 dynamical
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 is
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
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.
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 multi
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, Christian
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: I9f031cdcc82
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 +
drivers/g
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 a/drivers/gpu/drm/
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 this
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 Hel
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 drivers
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 fo
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 du
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
> > LVD
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 dele
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 into
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 thc63lvd
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 graphi
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 an
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
---
drivers/gpu/drm/amd/amdgpu/amdgpu_
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 a/drivers/gpu/drm/am
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 cases
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 +-
drivers/gpu/drm/amd/amdgp
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
---
.../gpu/drm/amd/am
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 d
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 b/drivers/gp
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 b/drivers/gpu/drm/ttm/ttm
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 comman
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 bug._
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 st
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 mo
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 2
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 creat
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 st
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 be
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 physi
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
---
.../arm64/boot/dts/renesas/r
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
---
Chang
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 th
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
---
.../arm64/boot/dts/renesas/r
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 Mond
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 fil
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 odd-num
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 Pinch
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: https://bugs.freedesktop.org/show_bug.cgi
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 sin
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;
> > >> +
> > >> + /*
> > >> +* Alway
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, h
https://bugs.freedesktop.org/show_bug.cgi?id=110783
--- Comment #1 from AngryPenguin ---
Created attachment 144363
--> https://bugs.freedesktop.org/attachment.cgi?id=144363&action=edit
inxi
--
You are receiving this mail because:
You are the assignee for the bug.__
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: n
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 Ripar
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
> ---
> include/drm/drm
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 enco
1 - 100 of 211 matches
Mail list logo
