Hi,
On Wed, Mar 13, 2019 at 09:35:05AM +0100, Daniel Vetter wrote:
> On Tue, Mar 12, 2019 at 11:13:03PM +0100, Ahmed S. Darwish wrote:
> > On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
> > > Den 11.03.2019 20.23, skrev Daniel Vetter:
[……]
> > > >
> > > > class_for_each_device
Add support for gamma corretion to sun4i TCON driver. Its LUT has 256
entries and can be updated only when gamma correction is disabled.
Signed-off-by: Vasily Khoruzhick
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 15 ++
drivers/gpu/drm/sun4i/sun4i_tcon.c | 33
[[ Adding Sebastian, who is quite experienced in intricate
locking situations due to daily PREEMPT_RT work.. ]]
On Wed, Mar 13, 2019 at 09:37:10AM +0100, Daniel Vetter wrote:
> On Wed, Mar 13, 2019 at 08:49:17AM +0100, John Ogness wrote:
> > On 2019-03-12, Ahmed S. Darwish wrote:
> > > On
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #19 from krutoiles...@gmail.com ---
(In reply to tme from comment #15)
> I've been attempting to perform a bisect on an off for a while now with no
> success. The main problem I'm running into is this error when trying to
> compile.
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #18 from fin4...@hotmail.com ---
Add amdgpu.ppfeaturemask=0xfffd7fff to the kernel command line to make the
powerplay work with RX 570 at 4K60Hz.
--
You are receiving this mail because:
You are the assignee for the
In the case of a normal sync update, the preparation of framebuffers (be
it calling drm_atomic_helper_prepare_planes() or doing setups with
drm_framebuffer_get()) are performed in the new_state and the respective
cleanups are performed in the old_state.
In the case of async updates, the
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Cc: # v4.14+
Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic")
Suggested-by: Boris Brezillon
Signed-off-by: Helen Koike
---
Hello,
As mentioned in
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling
In the case of async update, modifications are done in place, i.e. in the
current plane state, so the new_state is prepared and the new_state is
cleaned up (instead of the old_state, unlike what happens in a
normal sync update).
To cleanup the old_fb properly, it needs to be placed in the
Hello,
This series fixes the slow down in performance introduced by
"[PATCH v2] drm: Block fb changes for async plane updates" where async update
falls back to a sync update, causing igt failures of type:
"CRITICAL: completed 97 cursor updated in a period of 30 flips, we
expect to
We have another thing called the "done fence" that tracks when the
scheduler considers the job done, and having the shared name was
confusing.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_drv.h | 4 ++--
drivers/gpu/drm/v3d/v3d_gem.c | 6 +++---
drivers/gpu/drm/v3d/v3d_irq.c |
The compute shader dispatch interface is pretty simple -- just pass in
the regs that userspace has passed us, with no CLs to run. However,
with no CL to run it means that we need to do manual cache flushing of
the L2 after the HW execution completes (for SSBO, atomic, and
image_load_store writes
The CL submission had two jobs embedded in an exec struct. When I
added TFU support, I had to replicate some of the exec stuff and some
of the job stuff. As I went to add CSD, it became clear that actually
what was in exec should just be in the two CL jobs, and it would let
us share a lot more
We deref v3d->bin_job in the work handler, but v3d->bin_job doesn't
actually hold a ref on the job.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
On 3/13/19 5:57 PM, Liam Mark wrote:
> On Wed, 13 Mar 2019, Andrew F. Davis wrote:
>
>> On 3/13/19 3:18 PM, Liam Mark wrote:
>>> On Tue, 5 Mar 2019, John Stultz wrote:
>>>
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported
On Wed, Mar 13, 2019 at 1:20 PM Liam Mark wrote:
> On Tue, 5 Mar 2019, John Stultz wrote:
> > +
> > + page = alloc_page(GFP_KERNEL);
>
> Need to zero the allocation (add __GFP_ZERO)
Ah! Thanks! Fixed now.
> > + if (!page)
> > + goto err2;
> > +
On Wed, Mar 13, 2019 at 1:11 PM Liam Mark wrote:
> On Tue, 5 Mar 2019, John Stultz wrote:
> >
> > Eventual TODOS:
> > * Reimplement page-pool for system heap (working on this)
> > * Add stats accounting to system/cma heaps
> > * Make the kselftest actually useful
> > * Add other heaps folks see
[note to David Ober: you -should- be able to reply to this, hopefully, but I
haven't actually tested that so results may vary]
Hi again! Sorry I didn't fully answer all of the questions you originally
asked in this email, I had to get in contact with Lenovo to make sure that it
was OK for me to
https://bugzilla.kernel.org/show_bug.cgi?id=202799
--- Comment #4 from Clément Guérin (li...@protonmail.com) ---
Hi Michel, is there anything else you need to debug this?
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 3/13/19 3:18 PM, Liam Mark wrote:
> On Tue, 5 Mar 2019, John Stultz wrote:
>
>> Add generic helper dmabuf ops for dma heaps, so we can reduce
>> the amount of duplicative code for the exported dmabufs.
>>
>> This code is an evolution of the Android ION implementation, so
>> thanks to its
Rob Herring writes:
> From: Noralf Trønnes
>
> This adds a library for shmem backed GEM objects.
I read through the whole thing, and the only bit I didn't like
(drm_gem_shmem_create_with_handle returns an unrefcounted object
pointer) was a copy-and-paste from CMA that we should fix in both
https://bugzilla.kernel.org/show_bug.cgi?id=201795
--- Comment #18 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
It's intended driver behavior, not a regression.
The driver performs no display scaling by default since it forces the timing
for the preferred mode of the display. This
Hi Dave, Daniel,
A few fixes for 5.1:
- Update golden regs for gfx9
- Powerplay fixes
The following changes since commit 59d3191f14dc18881fec1172c7096b7863622803:
drm/amd/display: don't call dm_pp_ function from an fpu block (2019-03-06
15:31:20 -0500)
are available in the Git repository
https://bugs.freedesktop.org/show_bug.cgi?id=110045
--- Comment #1 from Jan Vesely ---
see also:
https://lists.freedesktop.org/archives/mesa-dev/2019-March/216042.html
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=108879
Jan Vesely changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=110045
Jan Vesely changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=110045
Bug ID: 110045
Summary: [radeonsi][clover][regression][bisected]
cl-api-enqueue-copy-buffer hangs on radeonsi
Product: Mesa
Version: git
Hardware: Other
On 13/03/2019 20:12, Laurent Pinchart wrote:
> Hi Jyri,
>
> On Wed, Mar 13, 2019 at 07:52:08PM +0200, Jyri Sarha wrote:
>> On 13/03/2019 18:47, Laurent Pinchart wrote:
>>> On Wed, Mar 13, 2019 at 06:29:19PM +0200, Laurent Pinchart wrote:
On Wed, Mar 13, 2019 at 06:01:07PM +0200, Jyri Sarha
Hi Daniel, Dave,
Here is what should be the last drm-misc-next-fixes PR.
Thanks!
Maxime
drm-misc-next-fixes-2019-03-13:
- qxl: Remove the conflicting framebuffers earlier
- Split out some i915 code into the fb_helper to allow the above
The following changes since commit
https://bugzilla.kernel.org/show_bug.cgi?id=201795
--- Comment #17 from thomas.lassdiesonner...@gmx.de ---
@Nicholas Kazlauskas
Thx for the possible workaround.
I am however not in search for a workaround. This is a regression (4.14 works)
and I hope it will be fixed properly some day.
--
You
From: Nicholas Kazlauskas
[ Upstream commit 0921c41e19028314830b33daa681e46b46477c5e ]
[Why]
If the cursor pos passed from DM is less than the plane_state->dst_rect
top left corner then the unsigned cursor pos wraps around to a large
positive number since cursor pos is a u32.
There was an
np
Andrey
On 3/13/19 1:53 PM, Eric Anholt wrote:
> "Grodzovsky, Andrey" writes:
>
>> On 3/13/19 12:13 PM, Eric Anholt wrote:
>>> "Grodzovsky, Andrey" writes:
>>>
They are not the same, but the guilty job belongs to only one {entity,
scheduler} pair and so we mark as guilty only for
Hi Vince,
Thank you for the patch.
Are you aware of the "[PATCH 0/7] mfd/pinctrl: add initial support of TI
DS90Ux9xx ICs" patch series
(https://lore.kernel.org/lkml/20181012060314.GU4939@dell/T/) ?
On Wed, Mar 13, 2019 at 11:34:58AM -0700, Vince Kim wrote:
> Add documments of device tree
On Tue, Mar 12, 2019 at 10:15 PM Manasi Navare
wrote:
>
> Current driver sets the tile property only for DP MST connectors.
> However there are some tiled displays where each SST connector
> carries a single tile. So we need to attach this property object
> for every connector and set it for
On Wed, Mar 13, 2019 at 12:21:46PM +0100, Maarten Lankhorst wrote:
> Hey Sean and Joonas,
>
> One more pull request for the hdr-formats topic branch. FP16 support
> is now also implemented.
>
> Can this be pulled to drm-misc-next and dinq?
Merged in drm-misc-next.
Sean
>
> ~Maarten
>
>
Hi Jyri,
On Wed, Mar 13, 2019 at 07:52:08PM +0200, Jyri Sarha wrote:
> On 13/03/2019 18:47, Laurent Pinchart wrote:
> > On Wed, Mar 13, 2019 at 06:29:19PM +0200, Laurent Pinchart wrote:
> >> On Wed, Mar 13, 2019 at 06:01:07PM +0200, Jyri Sarha wrote:
> >>> The sii902x chip family supports also
On 3/13/19 6:58 AM, Michel Dänzer wrote:
> On 2019-03-13 4:42 a.m., Tomasz Figa wrote:
>> On Wed, Mar 13, 2019 at 12:52 AM Boris Brezillon
>> wrote:
>>>
>>> On Tue, 12 Mar 2019 12:34:45 -0300
>>> Helen Koike wrote:
>>>
On 3/12/19 3:34 AM, Boris Brezillon wrote:
> On Mon, 11 Mar 2019
On Wed, Mar 13, 2019 at 11:09 AM Eric Anholt wrote:
>
> Rob Herring writes:
>
> > On Fri, Mar 8, 2019 at 10:29 AM Eric Anholt wrote:
> >>
> >> Rob Herring writes:
> >>
> >> > From: "Marty E. Plummer"
> >> >
> >> > This adds the initial driver for panfrost which supports Arm Mali
> >> >
Rob Herring writes:
> On Fri, Mar 8, 2019 at 10:29 AM Eric Anholt wrote:
>>
>> Rob Herring writes:
>>
>> > From: "Marty E. Plummer"
>> >
>> > This adds the initial driver for panfrost which supports Arm Mali
>> > Midgard and Bifrost family of GPUs. Currently, only the T860 Midgard GPU
>> >
"Grodzovsky, Andrey" writes:
> On 3/13/19 12:13 PM, Eric Anholt wrote:
>> "Grodzovsky, Andrey" writes:
>>
>>> They are not the same, but the guilty job belongs to only one {entity,
>>> scheduler} pair and so we mark as guilty only for that particular
>>> entity in the context of that scheduler
Am 13.03.19 um 18:33 schrieb Michel Dänzer:
> [SNIP]
>>> Copy how? Using a GPU engine?
>> CPU maybe? Though I suppose that won't work if the buffer isn't CPU
>> accesible :/
> Well we do have a debug path for accessing invisible memory with the
> CPU.
>
> E.g. three
On 13/03/2019 18:47, Laurent Pinchart wrote:
> Hello again,
>
> On Wed, Mar 13, 2019 at 06:29:19PM +0200, Laurent Pinchart wrote:
>> On Wed, Mar 13, 2019 at 06:01:07PM +0200, Jyri Sarha wrote:
>>> The sii902x chip family supports also HDMI audio. Add binding for
>>> describing the necessary i2s
On 3/13/19 1:33 PM, Michel Dänzer wrote:
> On 2019-03-13 5:16 p.m., Kazlauskas, Nicholas wrote:
>> On 3/13/19 11:54 AM, Christian König wrote:
>>> Am 13.03.19 um 16:38 schrieb Michel Dänzer:
On 2019-03-13 2:37 p.m., Christian König wrote:
> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
On Wed, Mar 13, 2019 at 5:21 AM Christian König
wrote:
>
> We can't just map any randome page we get when memory encryption is
> active.
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_memory.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff
On 2019-03-13 5:16 p.m., Kazlauskas, Nicholas wrote:
> On 3/13/19 11:54 AM, Christian König wrote:
>> Am 13.03.19 um 16:38 schrieb Michel Dänzer:
>>> On 2019-03-13 2:37 p.m., Christian König wrote:
Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
> On Wed, Mar 13, 2019 at 10:35:08AM +0100,
Am 13.03.19 um 17:16 schrieb Kazlauskas, Nicholas:
> On 3/13/19 11:54 AM, Christian König wrote:
>> Am 13.03.19 um 16:38 schrieb Michel Dänzer:
>>> On 2019-03-13 2:37 p.m., Christian König wrote:
Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
> On Wed, Mar 13, 2019 at 10:35:08AM +0100,
On 05/03/2019 21:21, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Thu, Feb 28, 2019 at 01:18:51PM +0200, Jyri Sarha wrote:
>> Earlier there were no mode_valid() helper for crtc and tilcdc had a
>> hack to over come this limitation. But now the mode_valid() helper is
>>
Clockwork, a static code analysis SW, complains about
drm_fb_cma_get_gem_obj() possibly returning NULL. This should never
happen with the frame-buffers used by tilcdc. However, returning null
is still a part of the drm_fb_cma_get_gem_obj() API, so lets make
Clockwork quiet by adding a simple check
Earlier there were no mode_valid() helper for crtc and tilcdc had a
hack to over come this limitation. But now the mode_valid() helper is
there (has been since v4.13), so it is about time to get rid of that
hack.
Signed-off-by: Jyri Sarha
Reviewed-by: Laurent Pinchart
---
No functional changes since the first version. I'll send a pull
request about these soon.
The minor changes:
- "drm/tilcdc: Check drm_fb_cma_get_gem_obj() return value"
- Add comment and improve commit description
- "drm/tilcdc: Remove obsolete crtc_mode_valid() hack"
- Improve indentation
Hello again,
On Wed, Mar 13, 2019 at 06:29:19PM +0200, Laurent Pinchart wrote:
> On Wed, Mar 13, 2019 at 06:01:07PM +0200, Jyri Sarha wrote:
> > The sii902x chip family supports also HDMI audio. Add binding for
> > describing the necessary i2s and mclk wiring for it.
> >
> > Signed-off-by: Jyri
On 3/13/19 12:13 PM, Eric Anholt wrote:
> "Grodzovsky, Andrey" writes:
>
>> They are not the same, but the guilty job belongs to only one {entity,
>> scheduler} pair and so we mark as guilty only for that particular
>> entity in the context of that scheduler only once.
> I get it now, sorry.
Hello Jyri,
Thank you for the patch.
On Wed, Mar 13, 2019 at 06:01:07PM +0200, Jyri Sarha wrote:
> The sii902x chip family supports also HDMI audio. Add binding for
> describing the necessary i2s and mclk wiring for it.
>
> Signed-off-by: Jyri Sarha
> ---
>
Hello Jyri,
Thank you for the patch.
On Wed, Mar 13, 2019 at 06:01:06PM +0200, Jyri Sarha wrote:
> Remove trailing white space from sii902x display bridge binding.
>
> Signed-off-by: Jyri Sarha
Reviewed-by: Laurent Pinchart
> ---
>
Hello Jyri,
Thank you for the patch.
On Wed, Mar 13, 2019 at 06:01:05PM +0200, Jyri Sarha wrote:
> The pixel clock unit in the first two registers (0x00 and 0x01) of
> sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
> 10 fixes the issue.
>
> Signed-off-by: Jyri Sarha
>
Hello Jyri,
Thank you for the patch.
On Wed, Mar 13, 2019 at 06:01:03PM +0200, Jyri Sarha wrote:
> From: Tomi Valkeinen
>
> The driver always sets InputBusFmt:EDGE to 0 (falling edge).
>
> Add drm_bridge_timings's input_bus_flags to reflect that the bridge
> samples on falling edges.
>
>
Hello Jyri,
Thank you for the patch.
On Wed, Mar 13, 2019 at 06:01:04PM +0200, Jyri Sarha wrote:
> Set output mode to HDMI or DVI according to EDID HDMI signature.
>
> Signed-off-by: Jyri Sarha
> Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
> ---
>
On 3/13/19 11:54 AM, Christian König wrote:
> Am 13.03.19 um 16:38 schrieb Michel Dänzer:
>> On 2019-03-13 2:37 p.m., Christian König wrote:
>>> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
> On 2019-03-12 6:15 p.m., Noralf
The probe() reference renders incorrectly and without a link, fix it.
Also fix a typo reported by checkpatch in the context lines.
Signed-off-by: Luca Ceresoli
---
drivers/gpu/drm/drm_drv.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
"Grodzovsky, Andrey" writes:
> They are not the same, but the guilty job belongs to only one {entity,
> scheduler} pair and so we mark as guilty only for that particular
> entity in the context of that scheduler only once.
I get it now, sorry. I'll merge this through drm-misc-next.
On Thu, 07 Mar 2019, Jani Nikula wrote:
> On Thu, 07 Mar 2019, Thomas Preston wrote:
>> Would you like me to resubmit with the suggested changes?
>
> Nah, we can tweak the commit message while applying.
Pushed to dinq, thanks for the patch.
BR,
Jani.
--
Jani Nikula, Intel Open Source
Hi Laurent.
On Wed, Mar 13, 2019 at 12:42:49PM +0200, Laurent Pinchart wrote:
> drm_framebuffer.h makes use of a pointer to struct drm_format_info but
> doesn't include drm_fourcc.h (neither directly nor indirectly).
> Forward-declare the structure.
Yep, this is the way to fix this.
>
>
Rob Herring writes:
> On Fri, Mar 8, 2019 at 10:29 AM Eric Anholt wrote:
>>
>> Rob Herring writes:
>>
>> > From: "Marty E. Plummer"
>> >
>> > This adds the initial driver for panfrost which supports Arm Mali
>> > Midgard and Bifrost family of GPUs. Currently, only the T860 Midgard GPU
>> >
Hi Kieran,
On Wed, Mar 13, 2019 at 12:06:40PM +, Kieran Bingham wrote:
> On 13/03/2019 00:05, Laurent Pinchart wrote:
> > Implement writeback support for R-Car Gen3 by exposing writeback
> > connectors. Behind the scene the calls are forwarded to the VSP
> > backend.
> >
> > Using writeback
Implement HDMI audio support by using ASoC HDMI codec. The commit
implements the necessary callbacks and configuration for the HDMI
codec and registers a virtual platform device for the codec to attach.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/bridge/sii902x.c | 455
Changes since v2:
- split dt-binding and related header to a separate patch
- add vendor prefix to i2s-fifo-routing dt-property
- add license identifier and copyright notice to sii902x-audio.h
- sii902x_get_modes() reorder local variables
- put clk_prepare_enable() before clk_get_rate(), according
The pixel clock unit in the first two registers (0x00 and 0x01) of
sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
10 fixes the issue.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sii902x.c | 5 +++--
1 file changed, 3 insertions(+), 2
The sii902x chip family supports also HDMI audio. Add binding for
describing the necessary i2s and mclk wiring for it.
Signed-off-by: Jyri Sarha
---
.../bindings/display/bridge/sii902x.txt | 34 +++
include/dt-bindings/sound/sii902x-audio.h | 17 ++
2 files
Set output mode to HDMI or DVI according to EDID HDMI signature.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sii902x.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index
Remove trailing white space from sii902x display bridge binding.
Signed-off-by: Jyri Sarha
---
Documentation/devicetree/bindings/display/bridge/sii902x.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
From: Tomi Valkeinen
The driver always sets InputBusFmt:EDGE to 0 (falling edge).
Add drm_bridge_timings's input_bus_flags to reflect that the bridge
samples on falling edges.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
---
Add a missing "be". While there, also fix the syntax for
struct drm_device.
Signed-off-by: Luca Ceresoli
---
include/drm/drm_drv.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 570f9d03b2eb..ecbbcb281260 100644
---
On Tue, Mar 12, 2019 at 03:59:15PM +, Kieran Bingham wrote:
> Hi Ville,
>
> On 12/03/2019 15:14, Ville Syrjälä wrote:
> > On Tue, Mar 12, 2019 at 12:33:07AM +, Kieran Bingham wrote:
> >> Trivial fixes identified while working on the DRM code.
> >>
> >> s/artifically/artificially/
> >>
Hi Kieran,
On Wed, Mar 13, 2019 at 11:42:34AM +, Kieran Bingham wrote:
> On 13/03/2019 00:05, Laurent Pinchart wrote:
> > Extend the vsp1_du_atomic_flush() API with writeback support by adding
> > format, pitch and memory addresses of the writeback framebuffer.
> > Writeback completion is
Am 13.03.19 um 16:38 schrieb Michel Dänzer:
On 2019-03-13 2:37 p.m., Christian König wrote:
Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
Den 12.03.2019 17.17, skrev Ville Syrjälä:
On
Hi Kieran,
On Wed, Mar 13, 2019 at 11:26:14AM +, Kieran Bingham wrote:
> On 13/03/2019 00:05, Laurent Pinchart wrote:
> > The VSP1 driver will need to pass extra flags to the DU through the
> > frame completion API. Replace the completed bool flag by a bitmask to
> > support this.
> >
> >
On 2019-03-13 2:37 p.m., Christian König wrote:
> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
>> On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
>>> On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
Den 12.03.2019 17.17, skrev Ville Syrjälä:
> On Tue, Mar 12, 2019 at
https://bugs.freedesktop.org/show_bug.cgi?id=110035
Michel Dänzer changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
The Amlogic G12A has a slighly different Power Control, but uses the
same address space and sysctrl registers.
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/power/amlogic,meson-gx-pwrc.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
The Amlogic G12A SoC has a slighly modified DW-HDMI Glue with
support for HDMI 2.1 and a different DW-HDMI register access.
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/display/amlogic,meson-dw-hdmi.txt | 4
1 file changed, 4 insertions(+)
diff --git
The Amlogic G12A VPU is very similar to the Amlogic GXM VPU but with :
- an enhanced plane blender, with up to 3 OSD planes
- support for AFBC 1.2 decoder (for Bifrost GPU)
- support display mode up to 4k60@75Hz
Signed-off-by: Neil Armstrong
---
This patchset adds the G12A specific bindings for the Display VPU
and VPU Power Control.
The Amlogic Meson G12A Display module is based on the Meson GXM SoC
with an updated Plane Blender, thus VPU architecture and interconnect
is the same.
Implementation then DT nodes will come in a further
Hi,
On Wed, Mar 13, 2019 at 11:44:17AM +0100, Takashi Iwai wrote:
> On Tue, 05 Mar 2019 20:36:38 +0100,
> Ville Syrjälä wrote:
> >
> > On Tue, Mar 05, 2019 at 02:21:04PM -0500, Alex Deucher wrote:
> > > On Tue, Mar 5, 2019 at 2:15 PM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Tue, Mar 05,
Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
Den 12.03.2019 17.17, skrev Ville Syrjälä:
On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
On 2019-03-11 6:42 p.m., Noralf
On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
> On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
> >
> >
> > Den 12.03.2019 17.17, skrev Ville Syrjälä:
> >> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> >>> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
>
On Tue, Mar 12, 2019 at 11:41 PM Ayan Halder wrote:
>
> On Mon, Mar 11, 2019 at 09:39:28AM -0700, Alyssa Rosenzweig wrote:
> > > You might want to re-use the exisiting modifier
> > > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16.
> > >
> > > I would suggest you to have a look at the exisiting AFBC modifiers
>
https://bugzilla.kernel.org/show_bug.cgi?id=201795
--- Comment #16 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
By default, amdgpu DC doesn't perform any sort of display scaling. It relies on
the monitor/TV's scaler itself to do the work, which might be producing the
black bars.
On Fri, Mar 8, 2019 at 10:29 AM Eric Anholt wrote:
>
> Rob Herring writes:
>
> > From: "Marty E. Plummer"
> >
> > This adds the initial driver for panfrost which supports Arm Mali
> > Midgard and Bifrost family of GPUs. Currently, only the T860 Midgard GPU
> > has been tested.
[...]
> It
On 11/03/2019 11:51, Maxime Jourdan wrote:
> When the DRM driver for the meson platform was created, the bindings
> required that the DMC register region was provided.
>
> Through those DMC registers, the display driver could configure an IP
> called "canvas", a video lookup table used by the
On 11/03/2019 11:51, Maxime Jourdan wrote:
> This patch series aims at removing access to the DMC register range from
> the meson DRM driver, and is the final step at fully migrating it to using
> the meson canvas provider module.
>
> Please see the commit notes of patch 1/2
> "dt-bindings:
On 11/03/2019 11:51, Maxime Jourdan wrote:
> Now that the DMC register range is no longer in the bindings, remove any
> mention towards it and exclusively use the meson-canvas module.
>
> Signed-off-by: Maxime Jourdan
> ---
> drivers/gpu/drm/meson/Makefile| 2 +-
>
https://bugs.freedesktop.org/show_bug.cgi?id=110031
--- Comment #2 from Tom Hughes ---
Created attachment 143645
--> https://bugs.freedesktop.org/attachment.cgi?id=143645=edit
X log
Log with Gnome using X.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110031
Bug ID: 110031
Summary: Failure to configure monitors with dc enabled
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=110031
--- Comment #1 from Tom Hughes ---
Created attachment 143644
--> https://bugs.freedesktop.org/attachment.cgi?id=143644=edit
Wayland log
Log with Gnome using Wayland.
--
You are receiving this mail because:
You are the assignee for the
On Wed, 13 Mar 2019, Laurent Pinchart
wrote:
> drm_framebuffer.h makes use of a pointer to struct drm_format_info but
> doesn't include drm_fourcc.h (neither directly nor indirectly).
> Forward-declare the structure.
>
> Signed-off-by: Laurent Pinchart
With the subject typo fixed,
From: Ong, Hean Loong
Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is located at:
From: Ong Hean Loong
Intel FPGA Video and Image Processing Suite Frame Buffer II
driver config for Arria 10 devkit and its variants
Signed-off-by: Ong, Hean Loong
---
arch/arm/configs/socfpga_defconfig |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git
From: Ong, Hean Loong
The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver
patch here is allocating memory for information to be streamed from the
ARM/Linux to the display port.
Basically the driver just wraps the information such as the pixels to be
drawn by the Sodt IP
From: Ong, Hean Loong
Device tree binding for Intel FPGA Video and Image Processing Suite.
The bindings would set the max width, max height,
bits per pixel and memory port width.
The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as altr.
V12:
1 - 100 of 189 matches
Mail list logo
