Hi,
> > So if this really has to come back then I think the pragmatic approach is
> > to do it behind a CONFIG_FBCON_ACCEL, default n, and with a huge warning
> > that enabling that shouldn't be done for any distro which only enables
> > firmware and drm fbdev drivers.
>
> Thanks for coming bac
Hi,
> > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of
> > doing it synchronously.
>
> Hopefully only the parts of the screen which need a redraw?
Sure. drm fbdev emulation with shadow framebuffer tracks changes and
only flushes dirty areas to the real framebuffer.
Am 21.01.22 um 06:28 schrieb Xin Xiong:
This issue takes place in an error path in
amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into
default case, the function simply returns -EINVAL, forgetting to
decrement the reference count of a dma_fence obj, which is bumped
earlier by amdgp
On 1/20/22 14:27, Christian König wrote:
Consolidate the wrapper functions to check for dma_fence
subclasses in the dma_fence header.
This makes it easier to document and also check the different
requirements for fence containers in the subclasses.
Signed-off-by: Christian König
---
includ
The pull request you sent on Fri, 21 Jan 2022 10:17:05 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-01-21
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c2c94b3b187dc92b2002809f489e0f24a41e91bc
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Fri, 21 Jan 2022 at 07:30, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-01-19 14:16:15)
> > diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
> > b/drivers/gpu/drm/msm/msm_io_utils.c
> > index 7b504617833a..5533c87c7158 100644
> > --- a/drivers/gpu/drm/msm/msm_io_utils.c
> > +++ b/driv
On 1/20/22 14:27, Christian König wrote:
Chaining of dma_fence_chain objects is only allowed through the prev
fence and not through the contained fence.
Warn about that when we create a dma_fence_chain.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/dma-buf/dma-fenc
On 1/20/22 14:27, Christian König wrote:
It's not allowed to nest another dma_fence container into a dma_fence_array
or otherwise we can run into recursion.
Warn about that when we create a dma_fence_array.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/dma-buf/dma-
On Thu, 20 Jan 2022, Matthew Brost wrote:
> Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
> set, before CT write / read as this could result in a read across the
> PCIe bus thus adding latency to every CT write / read. On well behavied
> systems this vaue should always read
Hi Matthew,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.16 next-20220121]
[cannot apply to airlied/drm-next]
[If your patch
Hi Matthew,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.16 next-20220121]
[cannot apply to airlied/drm-next]
[If your patch
The G2H handler needs to be flushed during a GT reset but a G2H
indicating engine reset failure can trigger a GT reset. Add a worker to
trigger the GT rest when an engine reset failure is received to break
this circular dependency.
v2:
(John Harrison)
- Store engine reset mask
- Fix typo in c
Now that the error capture is fully decoupled from fence signalling
(request retirement to free memory, which in turn depends on resets) we
can safely flush the G2H handler during a GT reset. This eliminates
corner cases where GuC generated G2H (e.g. engine resets) race with a GT
reset.
v2:
(John
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than
GFP_KERNEL to fully decouple the error capture from fence signalling.
v2:
(John Harrison)
- Fix typo in commit message (s/do/to)
Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code")
Signed-off-by: Matt
After a small fix to error capture code, we now can flush G2H during a
GT reset which simplifies code and seals some extreme corner case races.
v2:
(CI)
- Don't trigger GT reset from G2H handler
v3:
- Address John Harrison's comments
v4:
- Address John Harrison's comments
Signed-off-by: M
Quoting Daniel Latypov (2022-01-20 13:56:39)
> On Thu, Jan 20, 2022 at 1:31 PM Stephen Boyd wrote:
> > I was thinking this would be more generic so that one file tests clk.c
> > and all the code in there, but I guess there may be config dependencies
> > like CONFIG_OF that we may want to extract o
Quoting Dmitry Baryshkov (2022-01-19 14:16:15)
> diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
> b/drivers/gpu/drm/msm/msm_io_utils.c
> index 7b504617833a..5533c87c7158 100644
> --- a/drivers/gpu/drm/msm/msm_io_utils.c
> +++ b/drivers/gpu/drm/msm/msm_io_utils.c
> @@ -5,6 +5,8 @@
> * Author: Ro
On Thu, Jan 20, 2022 at 05:36:22PM -0800, John Harrison wrote:
> On 1/19/2022 13:24, Matthew Brost wrote:
> > Now that the error capture is fully decoupled from fence signalling
> > (request retirement to free memory, which in turn depends on resets) we
> > can safely flush the G2H handler during a
On Thu, Jan 20, 2022 at 05:34:54PM -0800, John Harrison wrote:
> On 1/19/2022 13:24, Matthew Brost wrote:
> > The G2H handler needs to be flushed during a GT reset but a G2H
> > indicating engine reset failure can trigger a GT reset. Add a worker to
> > trigger the GT when an engine reset failure i
Hi Laurent
Thanks for the response.
On 1/20/2022 6:43 PM, Laurent Pinchart wrote:
Hi Abhinav,
Thank you for the patch.
On Thu, Jan 20, 2022 at 06:29:55PM -0800, Abhinav Kumar wrote:
Instead of creating an internal encoder for the writeback
connector to satisfy DRM requirements, allow the cli
Hi Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.16 next-20220120]
[cannot apply to airlied/drm-next]
[If
Hi Abhinav,
Thank you for the patch.
On Thu, Jan 20, 2022 at 06:29:55PM -0800, Abhinav Kumar wrote:
> Instead of creating an internal encoder for the writeback
> connector to satisfy DRM requirements, allow the clients
> to pass a real encoder to it by changing the drm_writeback's
> encoder to a
Instead of creating an internal encoder for the writeback
connector to satisfy DRM requirements, allow the clients
to pass a real encoder to it by changing the drm_writeback's
encoder to a pointer.
If a real encoder is not passed, drm_writeback_connector_init
will internally allocate one.
This wi
Hi, Yongqiang:
On Thu, 2022-01-20 at 15:43 +0800, Yongqiang Niu wrote:
> From: mtk18742
>
> add cmdq_pkt_poll_addr function in cmdq helper functions
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 39
>
> include/linux/mailbox/mtk-c
On Wed, 2022-01-19 at 16:00 -0500, Steven Rostedt wrote:
> On Wed, 19 Jan 2022 21:25:08 +0200
> Andy Shevchenko wrote:
>
> > > I say keep it one line!
> > >
> > > Reviewed-by: Steven Rostedt (Google)
> >
> > I believe Sakari strongly follows the 80 rule, which means...
>
> Checkpatch says "
On 1/19/2022 13:24, Matthew Brost wrote:
Now that the error capture is fully decoupled from fence signalling
(request retirement to free memory, which in turn depends on resets) we
can safely flush the G2H handler during a GT reset. This is eliminates
This eliminates
John.
corner cases where
On 1/19/2022 13:24, Matthew Brost wrote:
The G2H handler needs to be flushed during a GT reset but a G2H
indicating engine reset failure can trigger a GT reset. Add a worker to
trigger the GT when an engine reset failure is received to break this
trigger the GT reset?
circular dependency.
v2:
On 19.01.2022 01:28, Daniel Latypov wrote:
On Mon, Jan 17, 2022 at 3:24 PM Michał Winiarski
wrote:
igt_dp_mst_calc_pbn_mode was converted one-to-one,
igt_dp_mst_sideband_msg_req_decode was refactored to parameterized test.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/selftests/Makef
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next next-20220120]
[cannot apply to tegra-drm/drm/tegra/for-next airlied/drm-next v5.16]
[If your
Hi Linus,
Thanks to Daniel for taking care of things while I was out, just a set
of merge window fixes that came in this week, two i915 display fixes
and a bunch of misc amdgpu, along with a radeon regression fix.
Regards,
Dave.
drm-next-2022-01-21:
drm fixes for 5.17-rc1
amdgpu:
- SR-IOV fix
Starting from xehpsdv, bit 0 of of the GuC shim control register has
been repurposed, while bit 2 is now reserved, so we need to avoid
setting those for their old meaning on newer platforms.
Cc: Vinay Belgaumkar
Cc: Stuart Summers
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/
On 19.01.2022 00:58, Daniel Latypov wrote:
change
On Mon, Jan 17, 2022 at 3:24 PM Michał Winiarski
wrote:
KUnit unifies the test structure and provides helper tools that simplify
the development. Basic use case allows running tests as regular processes,
leveraging User Mode Linux.
For exampl
On 1/20/22 6:12 AM, Christoph Hellwig wrote:
On Tue, Jan 11, 2022 at 12:17:18AM -0800, John Hubbard wrote:
Zooming in on the pinning aspect for a moment: last time I attempted to
convert O_DIRECT callers from gup to pup, I recall wanting very much to
record, in each bio_vec, whether these pages
Starting from DG2, some of the programming previously done by i915 and
the GuC has been moved to the GSC and the relevant registers are no
longer writable by either CPU or GuC. This is also referred to as GuC
deprivilege.
On the i915 side, this affects the WOPCM registers: these are no longer
progr
Quoting Maxime Ripard (2022-01-20 06:34:08)
> Let's test various parts of the rate-related clock API with the kunit
> testing framework.
>
> Cc: kunit-...@googlegroups.com
> Suggested-by: Stephen Boyd
> Signed-off-by: Maxime Ripard
> ---
This is great! Thanks for doing this.
> drivers/clk/Kco
On Thu, 2022-01-20 at 11:00 +0100, Thomas Zimmermann wrote:
> > >
> > > If that works, would you consider protecting pci_request_region()
> > > with
> > > #if not defined(CONFIG_FB_SIMPLE)
> > > #endif
> > >
> > > with a FIXME comment?
> >
> > Yes, I think that's a good compromise. I'll re
On 1/11/2022 08:39, Matthew Brost wrote:
Don't use the interruptable version of the timeline mutex lock in the
error path of eb_pin_timeline as the cleanup must always happen.
v2:
(John Harrison)
- Don't check for interrupt during mutex lock
v3:
(Tvrtko)
- A comment explaining why lock
add test to check handling of misaligned offsets and sizes
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 130 ++
1 file changed, 130 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i91
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on formatting
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no long
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
Suggested-by: Ma
This series continues support for 64K pages for discrete cards.
It supersedes the 64K patches from
https://patchwork.freedesktop.org/series/95686/#rev4
Changes since that series:
- set min alignment for DG2 to 2MB in i915_address_space_init
- replace coloring with simpler 2MB VA alignment for lme
On Thu, 20 Jan 2022 11:40:09 +0100, Krzysztof Kozlowski wrote:
> Enric Balletbo i Serra emails bounce:
>
> : Recipient address rejected: User unknown in
> local recipient table
>
> so drop him from the maintainers, similarly to commit 3119c28634dd
> ("MAINTAINERS: Chrome: Drop Enric Balletbo
On Thu, 20 Jan 2022 11:40:08 +0100, Krzysztof Kozlowski wrote:
> Enric Balletbo i Serra emails bounce:
>
> : Recipient address rejected: User unknown in
> local recipient table
>
> so drop him from the maintainers, similarly to commit 3119c28634dd
> ("MAINTAINERS: Chrome: Drop Enric Balletbo
[Public]
From: dri-devel on behalf of
sunpeng...@amd.com
Sent: Monday, January 17, 2022 5:33 PM
To: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org
Cc: Li, Sun peng (Leo)
Subject: [PATCH] drm: Add PSR version 4 macro
From: Leo Li
eDP 1.5 specification defines PSR version
On Thu, Jan 20, 2022 at 06:13:47PM +, Teres Alexis, Alan Previn wrote:
> Just one nit below, (assuming that igt CI failure isnt related - kms flip not
> completing)
> Reviewed-by Alan Previn
>
> -Original Message-
> From: Ceraolo Spurio, Daniele
> Sent: Friday, January 14, 2022 11:
On 2022-01-20 at 16:42:52 +, Robert Beckett wrote:
>
>
> On 20/01/2022 16:21, Ramalingam C wrote:
> > Add a new platform flag, needs_compact_pt, to mark the requirement of
> > compact pt layout support for the ppGTT when using 64K GTT pages.
> >
> > With this flag has_64k_pages will only ind
Noticed that the CT descriptor status was not printed in the CT debug
function, add that in.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/
A couple of minor CT updates. 1 for performance, 1 for extra debug.
Signed-off-by: Matthew Brost
Matthew Brost (2):
drm/i915/guc: Don't check CT descriptor status before CT write / read
drm/i915/guc: Print CT descriptor status in CT debug function
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
set, before CT write / read as this could result in a read across the
PCIe bus thus adding latency to every CT write / read. On well behavied
systems this vaue should always read as zero. For some reason it doesn't
the CT channel
On Thu, Jan 20, 2022 at 2:04 PM Neil Armstrong wrote:
>
> The Amlogic G12A/G12B/SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver
> 1.21a),
> with a custom glue managing the IP resets, clock and data input similar to
> the DW-HDMI
> Glue on other Amlogic SoCs.
>
> This adds support for the
On Thu, Jan 20, 2022 at 10:00 PM Neil Armstrong wrote:
>
> Hi,
>
> On 20/01/2022 15:24, Jagan Teki wrote:
> > On Thu, Jan 20, 2022 at 2:04 PM Neil Armstrong
> > wrote:
> >>
> >> The Amlogic G12A/G12B/SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver
> >> (ver 1.21a),
> >> with a custom glue ma
Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
set, before CT write / read as this could result in a read across the
PCIe bus thus adding latency to every CT write / read. On well behavied
systems this vaue should always read as zero. For some reason it doesn't
the CT channel
Just one nit below, (assuming that igt CI failure isnt related - kms flip not
completing)
Reviewed-by Alan Previn
-Original Message-
From: Ceraolo Spurio, Daniele
Sent: Friday, January 14, 2022 11:33 AM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Ceraolo Sp
Am 2022-01-20 um 5:17 a.m. schrieb Miaoqian Lin:
> Callback function amdgpu_xgmi_hive_release() in kobject_put()
> calls kfree(hive), So we don't need call kfree(hive) again.
>
> Fixes: 7b833d680481 ("drm/amd/amdgpu: fix potential memleak")
> Signed-off-by: Miaoqian Lin
The patch is
Reviewed-by:
On 2022-01-20 15:27, Keith Busch wrote:
On Thu, Jan 20, 2022 at 02:56:02PM +0100, Christoph Hellwig wrote:
- on the input side to dma mapping the bio_vecs (or phyrs) are chained
as bios or whatever the containing structure is. These already exist
and have infrastructure at least in th
Move spinner start out of the steps loop. If we restart WL for each
freq step, the rapid start/stop causes SLPC algorithm to think that
GT busyness is 50% for it's evaluation interval. This leads to SLPC
not increasing the requested frequency as per the test expectation.
Fixes: 8ee2c227822e (drm/i
On Tue, 18 Jan 2022 19:53:25 -0600, Rob Herring wrote:
> For a single pinctrl mode, it is not necessary to define pinctrl
> properties as the tools always allow pinctrl properties.
>
> Signed-off-by: Rob Herring
> ---
> .../display/rockchip/rockchip,rk3066-hdmi.yaml | 8
> Docu
On 19/01/2022 11:37, Arunpravin wrote:
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
On Thu, Jan 20, 2022 at 03:03:40PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 12, 2022 at 06:37:03PM +, Matthew Wilcox wrote:
> > But let's go further than that (which only brings us to 32 bytes per
> > range). For the systems you care about which use an identity mapping,
> > and have sizeo
Hello Daniel,
On 1/20/22 15:30, Daniel Vetter wrote:
> On Wed, Jan 19, 2022 at 12:08:39PM +0100, Helge Deller wrote:
>> This reverts commit 39aead8373b3c20bb5965c024dfb51a94e526151.
>>
>> Revert this patch. This patch started to introduce the regression that
>> all hardware acceleration of more t
On Thu, Jan 20, 2022 at 04:48:50PM +0100, Daniel Vetter wrote:
> On Thu, Jan 20, 2022 at 09:16:35AM +0100, Christian König wrote:
> > Am 20.01.22 um 00:55 schrieb Ira Weiny:
> > > On Wed, Jan 19, 2022 at 06:24:22PM +0100, Daniel Vetter wrote:
> > > > On Wed, Jan 19, 2022 at 08:53:56AM -0800, Ira We
On Wed, Jan 19, 2022 at 7:09 AM Daniel Vetter wrote:
>
> On Thu, Jan 06, 2022 at 04:55:35PM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Proposal to standardise the fdinfo text format as optionally output by DRM
> > drivers.
> >
> > Idea is that a simple but, well defined, spec w
On 20/01/2022 16:21, Ramalingam C wrote:
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory
[AMD Official Use Only]
Hi Matthew,
Do you have suggestions / issues for the other patches, shall we push all the
other patches into drm-misc-next.
Thanks,
Arun.
I've just gone ahead and pushed this version here to drm-misc-next.
That should at least reduce the amount of mails send back and f
Hi,
On 20/01/2022 15:24, Jagan Teki wrote:
> On Thu, Jan 20, 2022 at 2:04 PM Neil Armstrong
> wrote:
>>
>> The Amlogic G12A/G12B/SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver
>> (ver 1.21a),
>> with a custom glue managing the IP resets, clock and data input similar to
>> the DW-HDMI
>> Gl
On 2022-01-20 at 16:09:01 +, Robert Beckett wrote:
>
>
> On 20/01/2022 15:58, Matthew Auld wrote:
> > On 20/01/2022 15:44, Robert Beckett wrote:
> > >
> > >
> > > On 20/01/2022 14:59, Matthew Auld wrote:
> > > > On 20/01/2022 13:15, Robert Beckett wrote:
> > > > >
> > > > >
> > > > > On 2
Hi,
On Wed, Jan 19, 2022 at 10:45 PM Grace Mi
wrote:
>
> From: Yunlong Jia
>
> We have added corresponding information:
> [BOE]NV116WHM-N45 use delay_200_500_e50
> [KDB]116N29-30NK-C007 use delay_200_500_e80_d50
> [STA]2081116HHD028001-51D use delay_100_500_e200
> Add 3 panels & 2 de
On 20/01/2022 09:33, Neil Armstrong wrote:
> This adds supports for the ENCL encoder connected to a MIPI-DSI transceiver
> on the
> Amlogic AXG, G12A, G12B & SM1 SoCs.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_registers.h | 15 ++
> drivers/gpu/drm/meson/meson_venc.
On 20/01/2022 16:09, Robert Beckett wrote:
On 20/01/2022 15:58, Matthew Auld wrote:
On 20/01/2022 15:44, Robert Beckett wrote:
On 20/01/2022 14:59, Matthew Auld wrote:
On 20/01/2022 13:15, Robert Beckett wrote:
On 20/01/2022 11:46, Ramalingam C wrote:
On 2022-01-18 at 17:50:34 +, R
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
Suggested-by: Matthew Auld
Signed-of
On 20/01/2022 15:58, Matthew Auld wrote:
On 20/01/2022 15:44, Robert Beckett wrote:
On 20/01/2022 14:59, Matthew Auld wrote:
On 20/01/2022 13:15, Robert Beckett wrote:
On 20/01/2022 11:46, Ramalingam C wrote:
On 2022-01-18 at 17:50:34 +, Robert Beckett wrote:
From: Matthew Auld
On 20/01/2022 15:44, Robert Beckett wrote:
On 20/01/2022 14:59, Matthew Auld wrote:
On 20/01/2022 13:15, Robert Beckett wrote:
On 20/01/2022 11:46, Ramalingam C wrote:
On 2022-01-18 at 17:50:34 +, Robert Beckett wrote:
From: Matthew Auld
For local-memory objects we need to align the
On Thu, Jan 20, 2022 at 09:16:35AM +0100, Christian König wrote:
> Am 20.01.22 um 00:55 schrieb Ira Weiny:
> > On Wed, Jan 19, 2022 at 06:24:22PM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 19, 2022 at 08:53:56AM -0800, Ira Weiny wrote:
> > > > On Fri, Dec 10, 2021 at 03:23:57PM -0800, 'Ira Weiny
On 20/01/2022 14:59, Matthew Auld wrote:
On 20/01/2022 13:15, Robert Beckett wrote:
On 20/01/2022 11:46, Ramalingam C wrote:
On 2022-01-18 at 17:50:34 +, Robert Beckett wrote:
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt a
On Thu, Jan 20, 2022 at 07:27:36AM -0800, Keith Busch wrote:
> It doesn't look like IOMMU page sizes are exported, or even necessarily
> consistently sized on at least one arch (power).
At the DMA API layer dma_get_merge_boundary is the API for it.
On Thu, Jan 20, 2022 at 02:56:02PM +0100, Christoph Hellwig wrote:
> - on the input side to dma mapping the bio_vecs (or phyrs) are chained
>as bios or whatever the containing structure is. These already exist
>and have infrastructure at least in the block layer
> - on the output side I
Il 14/01/22 10:14, allen ha scritto:
This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.
From: Allen Chen
Tested-by: Hsin-yi Wang
Signed-off-by: Hermes Wu
Signed-off-by: Allen Chen
---
v10 -> v11 : remove drm_bridge_new_crtc_state
---
drivers/gpu/drm/brid
In addition to the RGB444 output, the BCM2711 HDMI controller supports
the YUV444 and YUV422 output formats.
Let's add support for them in the driver, but still use RGB as the
preferred format.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 289 ++
Currently we take the max_bpc property as the bpc value and do not try
anything else.
However, what the other drivers seem to be doing is that they would try
with the highest bpc allowed by the max_bpc property and the hardware
capabilities, test if it results in an acceptable configuration, and i
The current code only base its decision for whether the scrambler must be
enabled or not on the pixel clock of the mode, but doesn't take the bits
per color into account.
Let's leverage the new function to compute the clock rate in the
scrambler setup code.
Signed-off-by: Maxime Ripard
---
driv
In the function that validates that the clock isn't too high, we've only
taken our controller limitations into account so far.
However, the sink can have a limit on the maximum TMDS clock it can deal
with too which is exposed through the EDID and the drm_display_info.
Make sure we check it.
Sign
The code to compute our clock rate for a given setup will be called in
multiple places in the next patches, so let's create a separate function
for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 49 +++---
1 file changed, 34 insertions(+), 15 de
Our code is doing the same clock rate validation in multiple instances.
Let's create a helper to share the rate validation.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu
In order to support the YUV output, we'll need the atomic state to know
what is the state of the associated property in the CSC setup callback.
Let's change the prototype of that callback to allow us to access it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4
The current CSC setup code for the BCM2711 uses a sequence of register
writes to configure the CSC depending on whether we output using a full
or limited range.
However, with the upcoming introduction of the YUV output, we're going
to add new matrices to perform the conversions, so we should switc
On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an
opaque value. Let's replace it with properly defined values.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_regs.h | 3 +++
2 files changed, 5 ins
On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration
depends on whether we're using an RGB or YUV output. Let's move that
configuration to the CSC setup.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
1 file changed, 2 insertio
The CSC callbacks takes a boolean as an argument to tell whether we're
using the full range or limited range RGB.
However, with the upcoming YUV support, the logic will be a bit more
complex. In order to address this, let's make the callbacks take the
entire mode, and call our new helper to tell w
We're going to need to tell whether we want to run with a full or
limited range RGB output in multiple places in the code, so let's create
a helper that will return whether we need with full range or not.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.
The HDMI specification mentions YCbCr everywhere, but our enums have
YCrCb. Let's rename it to match.
Signed-off-by: Maxime Ripard
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
.../drm/arm/display/komeda/d71/d71_component.c | 12 ++--
drivers/gpu/drm/bridge/adv7511/adv7511_
The current code assumes that the RGB444 and YUV444 formats are the
same, but the HDMI 2.0 specification states that:
The three DC_XXbit bits above only indicate support for RGB 4:4:4 at
that pixel size. Support for YCBCR 4:4:4 in Deep Color modes is
indicated with the DC_Y444 bit. If DC_
The current code, when parsing the EDID Deep Color depths, that the
YUV422 cannot be used, referring to the HDMI 1.3 Specification.
This specification, in its section 6.2.4, indeed states:
For each supported Deep Color mode, RGB 4:4:4 shall be supported and
optionally YCBCR 4:4:4 may be suppo
The drm_hdmi_avi_infoframe_colorspace() function actually sets the
colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe
structure with DRM_MODE_COLORIMETRY_* values.
To make things worse, the hdmi_avi_infoframe structure also has a
colorspace field used to signal whether an RGB or
Hi,
This is another attempt at supporting the HDMI YUV output in the vc4 HDMI
driver.
This is a follow-up of
https://lore.kernel.org/dri-devel/20210317154352.732095-1-max...@cerno.tech/
And the discussions that occured recently on the mailing lists and IRC about
this.
The series mentioned above
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/logicvc/logicvc_drm.h | 3 +
drivers/gpu/drm/logicvc/logicvc_layer.c | 151 +++-
drivers/gpu/drm/logicvc/logicvc_layer.h | 7 ++
3 files changed, 155 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/logicvc/
Introduces a driver for the LogiCVC display controller, a programmable
logic controller optimized for use in Xilinx Zynq-7000 SoCs and other
Xilinx FPGAs. The controller is mostly configured at logic synthesis
time so only a subset of configuration is left for the driver to
handle.
The following f
There are lots of different versions of the logicvc block and it
makes little sense to list them all in compatibles since all versions
with the same major are found to be register-compatible.
Introduce a new compatible with the major version only.
Signed-off-by: Paul Kocialkowski
---
Documentat
There are lots of different versions of the logicvc block and it
makes little sense to list them all in compatibles since all versions
with the same major are found to be register-compatible.
Add common compatibles that only list the major version instead.
Signed-off-by: Paul Kocialkowski
---
.
1 - 100 of 204 matches
Mail list logo
