On Mon, 21 Feb 2022 10:59:03 +0100, Maxime Ripard wrote:
> From: Dave Stevenson
>
> The drm_plane_create_zpos_property() function asks for an initial value,
> and will set the associated plane state variable with that value if a
> state is present.
>
> However, that function is usually called
On Mon, 21 Feb 2022 10:59:00 +0100, Maxime Ripard wrote:
> While the omap_plane_init() function calls
> drm_plane_create_zpos_property() with an initial value of 0,
> omap_plane_reset() will force it to another value depending on the plane
> type.
>
> Fix the discrepancy by setting the initial
On Mon, 21 Feb 2022 10:59:09 +0100, Maxime Ripard wrote:
> The nouveau KMS driver will call drm_plane_create_zpos_property() with
> an init value depending on the plane purpose.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in nv50_wndw_reset().
On 2/25/2022 08:36, Tvrtko Ursulin wrote:
On 24/02/2022 20:02, John Harrison wrote:
On 2/23/2022 04:00, Tvrtko Ursulin wrote:
On 23/02/2022 02:22, John Harrison wrote:
On 2/22/2022 01:53, Tvrtko Ursulin wrote:
On 18/02/2022 21:33, john.c.harri...@intel.com wrote:
From: John Harrison
On 2/25/2022 1:04 AM, Dmitry Baryshkov wrote:
On Fri, 25 Feb 2022 at 07:45, Abhinav Kumar wrote:
On 2/24/2022 8:22 PM, Dmitry Baryshkov wrote:
On Fri, 25 Feb 2022 at 05:01, Abhinav Kumar wrote:
On 2/24/2022 12:41 PM, Dmitry Baryshkov wrote:
On Thu, 24 Feb 2022 at 21:25, Abhinav
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_snps_phy.c
between commit:
28adef861233c ("drm/i915/dg2: Print PHY name properly on calibration error")
from the drm-intel-fixes tree and commits:
84073e568eec7 ("drm/i915/dg2:
On 24/02/2022 19:19, John Harrison wrote:
[snip]
./gt/uc/intel_guc_fwif.h: u32 execution_quantum;
./gt/uc/intel_guc_submission.c: desc->execution_quantum =
engine->props.timeslice_duration_ms * 1000;
./gt/intel_engine_types.h: unsigned long
timeslice_duration_ms;
Hi Tvrtko,
It seems without cacheflush.h being included, when I build for arm64 or
x86, it stills pulls in cacheflush.h:
./.drm_cache.o.cmd:838: include/linux/cacheflush.h \
./.drm_cache.o.cmd:839: arch/x86/include/asm/cacheflush.h \
./.drm_cache.o.cmd:920: include/asm-generic/cacheflush.h \
On 2/25/2022 05:26, Tvrtko Ursulin wrote:
On 25/02/2022 09:44, Michal Wajdeczko wrote:
On 25.02.2022 06:03, Jordan Justen wrote:
John Harrison writes:
On 2/22/2022 02:36, Jordan Justen wrote:
From: John Harrison
Implement support for fetching the hardware description table from
the
Hi all,
After merging the drm tree, today's linux-next build (x86 allmodconfig)
failed like this:
lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x10b: call to
do_strncpy_from_user() with UACCESS enabled
lib/strnlen_user.o: warning: objtool: strnlen_user()+0xbb: call to
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
between commit:
e2b993302f40c ("drm/amdgpu: bypass tiling flag check in virtual display case
(v2)")
from the drm-fixes tree and commit:
2af104290da5e ("drm: introduce
On 24/02/2022 20:02, John Harrison wrote:
On 2/23/2022 04:00, Tvrtko Ursulin wrote:
On 23/02/2022 02:22, John Harrison wrote:
On 2/22/2022 01:53, Tvrtko Ursulin wrote:
On 18/02/2022 21:33, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not
Hi Dave, Daniel,
The following changes since commit 8913e1aea4b32a866343b14e565c62cec54f3f78:
drm/tegra: dpaux: Populate AUX bus (2022-02-23 13:00:37 +0100)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/tegra.git tags/drm/tegra/for-5.18-rc1
for you to fetch
On Thu, 17 Feb 2022 15:57:52 +0800, Yunfei Dong wrote:
> Adds decoder dt-bindings for compatible "mediatek,mtk-vcodec-lat-soc".
>
> Signed-off-by: Yunfei Dong
> ---
> .../media/mediatek,vcodec-subdev-decoder.yaml | 51 +--
> 1 file changed, 35 insertions(+), 16 deletions(-)
>
On 25/02/2022 03:24, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush by first performing a clean, follow by an invalidation
operation.
v2 (Michael Cheng): Use correct macro for cleaning and invalidation the
dcache.
Already fixed. Thanks for the patch.
Alex
On Thu, Feb 24, 2022 at 5:43 PM Colin Ian King wrote:
>
> Currently the call to function amdgpu_benchmark_move should be
> assigning the return value to variable r as this is checked in
> the next statement, however, this assignment is missing. Fix
>
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/display/intel_snps_phy.c
between commit:
28adef861233c ("drm/i915/dg2: Print PHY name properly on calibration error")
from the drm-intel-fixes tree and commits:
c5274e86da5fe ("drm/i915/snps:
On Thu, Feb 24, 2022 at 8:23 PM Bjorn Helgaas wrote:
>
> On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> > The `is_thunderbolt` attribute originally had a well defined list of
> > quirks that it existed for, but it has been overloaded with more
> > meaning.
> >
> > Instead
Hi Melissa,
On Tue, Feb 01, 2022 at 08:26:51PM -0100, Melissa Wen wrote:
> Trace submit_cl_ioctl and related IRQs for CL submission and bin/render
> jobs execution. It might be helpful to get a rendering timeline and
> track job throttling.
>
> Signed-off-by: Melissa Wen
I'm not really sure
Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.
drop the assigned clock rate property and set it
during resume sequence with max value in the opp table.
Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add
use max clock during resume sequence from the opp table.
The clock will be scaled down when framework sends an update.
Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
1 file changed, 3
*** BLURB HERE ***
Vinod Polimera (2):
arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk
drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table
arch/arm64/boot/dts/qcom/sc7280.dtsi| 9 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
2 files
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
allocation doesn't fit within the pfn range, like with mappable lmem.
The hugepages selftest, for example, needs this to know if a smaller
size is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas
If the user doesn't require CPU access for the buffer, then
ALLOC_GPU_ONLY should be used, in order to prioritise allocating in the
non-mappable portion of LMEM, on devices with small BAR.
v2(Thomas):
- The BO_ALLOC_TOPDOWN naming here is poor, since this is pure lies on
systems that don't
Differentiate between mappable vs non-mappable resources, also if this
is an actual range allocation ensure we set res->start as the starting
pfn. Later when we need to do non-mappable -> mappable moves then we
want TTM to see that the current placement is not compatible, which
should result in an
Track the total amount of available visible memory, and also track
per-resource the amount of used visible memory. For now this is useful
for our debug output, and deciding if it is even worth calling into the
buddy allocator. In the future tracking the per-resource visible usage
will be useful
On devices with non-mappable LMEM ensure we always allocate the pages
within the mappable portion. For now we assume that all LMEM buffers
will require CPU access, which is also inline with pretty much all
current kernel internal users. In the next patch we will introduce a new
flag to override
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
v2: also update intelfb_create
Signed-off-by: Matthew Auld
Cc: Thomas
Now that the clock driver makes sure we never end up with a rate of 0,
the HDMI driver doesn't need to care anymore.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
The HVS core clock isn't really obvious, so let's add a bunch more
comments and some logging for easier debugging.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c
The core clock and M2MC clocks are shared between some devices (Unicam
controllers and the HVS, and the HDMI controllers, respectively) that
will have various, varying, requirements depending on their current work
load.
Since those loads can require a fairly high clock rate in extreme
conditions
Any registered clk_core structure can have a NULL pointer in its dev
field. While never actually documented, this is evidenced by the wide
usage of clk_register and clk_hw_register with a NULL device pointer,
and the fact that the core of_clk_hw_register() function also passes a
NULL device
The M2MC clock provides the state machine clock for both HDMI
controllers.
However, if no HDMI monitor is plugged in at boot, its clock rate will
be left at 0 by the firmware and will make any register access end up in
a CPU stall, even though the clock was enabled.
We had some code in the HDMI
In order to reset the range on a clock, we need to call
clk_set_rate_range with a minimum of 0 and a maximum of ULONG_MAX. Since
it's fairly inconvenient, let's introduce a clk_drop_range() function
that will do just this.
Suggested-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
We only export a bunch of firmware clocks, and some of them require
special treatment.
This has been do so far using some tests on the clock id in various
places, but this is fairly hard to extend and doesn't scale very well.
Since we'll need some more cases in the next patches, let's switch to
When we change a clock minimum or maximum using clk_set_rate_range(),
clk_set_min_rate() or clk_set_max_rate(), the current code will only
trigger a new rate change if the rate is outside of the new boundaries.
However, a clock driver might want to always keep the clock rate to
one of its
The current core while setting the min and max rate properly in the
clk_request structure will not make sure that the requested rate is
within these boundaries, leaving it to each and every driver to make
sure it is.
It's not clear if this was on purpose or not, but this introduces some
If we were to have two users of the same clock, doing something like:
clk_set_rate_range(user1, 1000, 2000);
clk_set_rate_range(user2, 3000, 4000);
The second call would fail with -EINVAL, preventing from getting in a
situation where we end up with impossible limits.
However, this is never
The code in clk_set_rate_range() will, if the current rate is outside of
the new range, force it to the minimum or maximum.
Since it's running under the condition that the rate is either lower
than the minimum, or higher than the maximum, this is equivalent to
using clamp, while being less
Let's test various parts of the rate-related clock API with the kunit
testing framework.
Cc: kunit-...@googlegroups.com
Tested-by: Daniel Latypov
Suggested-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/.kunitconfig | 1 +
drivers/clk/Kconfig | 7 +
Hi,
This is a follow-up of the discussion here:
https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
and here:
https://lore.kernel.org/all/20210914093515.260031-1-max...@cerno.tech/
While the initial proposal implemented a new API to temporarily raise and lower
clock rates
Hi Stephen,
On Thu, Feb 24, 2022 at 02:54:20PM -0800, Stephen Boyd wrote:
> Quoting Daniel Latypov (2022-02-23 14:50:59)
> > On Wed, Feb 23, 2022 at 2:56 AM Maxime Ripard wrote:
> > Incremental coverage for 3/9 files in --diff_file
> > Total incremental: 99.29% coverage (281/283 lines)
> >
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #67 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Randune from comment #66)
>
> I understand that amdgpu.runpm=0 is related to power management but I don't
> know the specifics. Possibly Alex Deucher can chime in and
On Sun, Nov 07, 2021 at 10:16:36PM +0100, Christophe JAILLET wrote:
> Add a missing 'host1x_channel_list_free()' call in the remove function,
> as already done in the error handling path of the probe function.
>
> Fixes: 8474b02531c4 ("gpu: host1x: Refactor channel allocation code")
>
On Sun, Nov 07, 2021 at 10:16:25PM +0100, Christophe JAILLET wrote:
> Add the missing 'host1x_bo_cache_destroy()' call in the error handling
> path of the probe, as already done in the remove function.
>
> In order to simplify the error handling, move the 'host1x_bo_cache_init()'
> call after all
When unbinding a DRM master driver there's a race condition that
sometimes results in an invalid vm access when userspace (gnome-shell)
issues a DRM_IOCTL_MODE_GETCONNECTOR ioctl right after a bridge has been
removed from an encoder's bridge chain.
This means that once a bridge has been disabled
Depending on the bridge code, certain userspace events during a driver
teardown (such as a DRM ioctl call) might cause a race condition where
the drm_bridge_chain_pre_enable() and drm_bridge_chain_post_enable()
functions could be called for a bridge that has just been detached and
removed from the
Hi all,
I'm sending these patches to try to improve the current situation for a
particular corner case (DRM driver unbinding).
I could reproduce a specific race condition during the unbinding of the
mediatek-drm driver that caused an invalid memory address. The race
condition is triggered by a
On 2022-02-25 13:11, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 12:41:23PM +, Robin Murphy wrote:
On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
25.02.2022 10:51, Sascha Hauer пишет:
The
On 25/02/2022 09:44, Michal Wajdeczko wrote:
On 25.02.2022 06:03, Jordan Justen wrote:
John Harrison writes:
On 2/22/2022 02:36, Jordan Justen wrote:
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a
Hi Daniel,
On Wed, Feb 23, 2022 at 02:50:59PM -0800, Daniel Latypov wrote:
> On Wed, Feb 23, 2022 at 2:56 AM Maxime Ripard wrote:
> >
> > Let's test various parts of the rate-related clock API with the kunit
> > testing framework.
> >
> > Cc: kunit-...@googlegroups.com
> > Suggested-by: Stephen
It updates the name of the structure with the target function callback is
incorrect
: drm_gem_object_funcs.gem_prime_import_sg_table to
drm_driver.gem_prime_import_sg_table
And it updates the part where the description and the function callback
name are different.
: drm_gem_object_funcs.pin to
It fixes typo and updates outdated struct and API names that are currently
deprecated or in use but have changed on the kernel documents of DRM section
and comments.
Signed-off-by: Gwan-gyeong Mun
---
Documentation/gpu/drm-mm.rst | 8
drivers/gpu/drm/drm_file.c|
It updates i915_gem_ctx to i915_gem_ww_ctx and adds missing indefinite
article to doc.
Signed-off-by: Gwan-gyeong Mun
---
Documentation/gpu/i915.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index
On 2/22/22 16:20, Nathan Chancellor wrote:
Clang warns:
drivers/gpu/drm/stm/ltdc.c:625:2: warning: variable 'val' is used
uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
default:
^~~
drivers/gpu/drm/stm/ltdc.c:635:2: note:
On 2/11/22 11:46, Raphaël Gallais-Pou wrote:
From: Raphael Gallais-Pou
This patch adds the CRC hashing feature supported by some recent hardware
versions of the LTDC. This is useful for test suite such as IGT-GPU-tools
[1] where a CRTC output frame can be compared to a test reference frame
On Fri, Feb 25, 2022 at 12:41:23PM +, Robin Murphy wrote:
> On 2022-02-25 11:10, Dmitry Osipenko wrote:
> > 25.02.2022 13:49, Sascha Hauer пишет:
> > > On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
> > > > 25.02.2022 10:51, Sascha Hauer пишет:
> > > > > The rk3568 HDMI has
Quoting CK Hu (2022-02-25 10:45:26)
> Hi, Guillaume:
>
> On Fri, 2022-02-18 at 15:54 +0100, Guillaume Ranquet wrote:
> > From: Markus Schneider-Pargmann
> >
> > This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
> >
> > It supports the mt8195, the embedded DisplayPort units. It
[AMD Official Use Only]
Thanks!
The patch is reviewed-by: Evan Quan
> -Original Message-
> From: Meng Tang
> Sent: Friday, February 25, 2022 5:47 PM
> To: airl...@linux.ie; dan...@ffwll.ch
> Cc: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; amd-
>
On 2022-02-25 11:10, Dmitry Osipenko wrote:
25.02.2022 13:49, Sascha Hauer пишет:
On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
25.02.2022 10:51, Sascha Hauer пишет:
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The
Il 25/02/22 12:49, Guillaume Ranquet ha scritto:
Quoting AngeloGioacchino Del Regno (2022-02-21 15:31:51)
Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
From: Markus Schneider-Pargmann
This is a new driver that supports the integrated DisplayPort phy for
mediatek SoCs, especially the
Quoting AngeloGioacchino Del Regno (2022-02-21 15:31:51)
> Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
> > From: Markus Schneider-Pargmann
> >
> > This is a new driver that supports the integrated DisplayPort phy for
> > mediatek SoCs, especially the mt8195. The phy is integrated into the
>
On Thu, 24 Feb 2022 17:34:54 +0100,
Kai Vehmanen wrote:
>
> Hi,
>
> On Thu, 24 Feb 2022, Ramalingam C wrote:
>
> > Split the wait for component binding from i915 in multiples of
> > sysctl_hung_task_timeout_secs. This helps to avoid the possible kworker
> > thread hung detection given below.
>
On Fri, Feb 25, 2022 at 02:10:55PM +0300, Dmitry Osipenko wrote:
> 25.02.2022 13:49, Sascha Hauer пишет:
> > On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
> >> 25.02.2022 10:51, Sascha Hauer пишет:
> >>> The rk3568 HDMI has an additional clock that needs to be enabled for the
>
Quoting Maxime Ripard (2022-02-21 10:44:20)
> Hi
>
> (Now I remember your series ;)
Hi,
I'm not sure this is a good thing though :)
>
> On Fri, Feb 18, 2022 at 03:54:31PM +0100, Guillaume Ranquet wrote:
> > dpintf is the displayport interface hardware unit. This unit is similar
> > to dpi and
25.02.2022 13:49, Sascha Hauer пишет:
> On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
>> 25.02.2022 10:51, Sascha Hauer пишет:
>>> The rk3568 HDMI has an additional clock that needs to be enabled for the
>>> HDMI controller to work. The purpose of that clock is not clear. It is
Quoting Chun-Kuang Hu (2022-02-21 04:24:32)
> Hi, Guillaume:
>
> Guillaume Ranquet 於 2022年2月18日 週五 下午10:56寫道：
> >
> > Add flexibility by moving the swap shift value to board config
> >
> > Signed-off-by: Guillaume Ranquet
> > ---
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
> > 1 file
On Tue, Feb 15, 2022 at 09:46:24PM +0100, Helge Deller wrote:
> On 2/14/22 07:08, Yong Wu wrote:
> > Use the common compare helper from component.
> >
> > Cc: Helge Deller
> > Cc: linux-o...@vger.kernel.org
> > Cc: linux-fb...@vger.kernel.org
> > Signed-off-by: Yong Wu
>
> Applied to the fbdev
Quoting Chun-Kuang Hu (2022-02-21 03:32:32)
> Hi, Guillaume:
>
> Guillaume Ranquet 於 2022年2月18日 週五 下午10:56寫道：
> >
> > Adds a bit of flexibility to support boards without swap_input support
> >
> > Signed-off-by: Guillaume Ranquet
> > ---
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 14
Quoting Chun-Kuang Hu (2022-02-21 03:14:02)
> HI, Guillaume:
>
> Guillaume Ranquet 於 2022年2月18日 週五 下午10:56寫道：
> >
> > Adds a bit of flexibility to support boards without CK/DE pol support
>
> I'm not sure what the term 'board' mean. Do you mean different board
> with different panel but all with
On Thu, Feb 24, 2022 at 09:07:19PM +0100, Marek Vasut wrote:
> On 2/24/22 16:19, Maxime Ripard wrote:
> > On Sat, Feb 19, 2022 at 01:28:40AM +0100, Marek Vasut wrote:
> > > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> > > index 1701c2128a5cb..32455cf28f0bc 100644
> > > ---
On Fri, Feb 25, 2022 at 01:26:14PM +0300, Dmitry Osipenko wrote:
> 25.02.2022 10:51, Sascha Hauer пишет:
> > The rk3568 HDMI has an additional clock that needs to be enabled for the
> > HDMI controller to work. The purpose of that clock is not clear. It is
> > named "hclk" in the downstream
Quoting Chun-Kuang Hu (2022-02-21 02:46:15)
> Hi, Guillaume:
>
> Guillaume Ranquet 於 2022年2月18日 週五 下午10:56寫道：
> >
> > Add flexibility by moving the dpi limits to the board config
>
> This patch looks good to me. But I would like to know what's this
> limit and why it vary in different SoC. If
On 2/25/22 11:34, Matthew Auld wrote:
On DG2 we allow objects that are smaller than the min_page_size, under
the premise that these are never mapped by the GTT, like with the paging
structures. Currently the suspend-resume path will try to map such
objects through the migration vm, which hits:
Quoting AngeloGioacchino Del Regno (2022-02-22 16:16:48)
> Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
> > From: Markus Schneider-Pargmann
> >
> > Similar to HDMI, DP uses audio infoframes as well which are structured
> > very similar to the HDMI ones.
> >
> > This patch adds a helper
Quoting AngeloGioacchino Del Regno (2022-02-21 15:30:07)
> Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
> > From: Markus Schneider-Pargmann
> >
> > Similar to HDMI, DP uses audio infoframes as well which are structured
> > very similar to the HDMI ones.
> >
> > This patch adds a helper
On 2022-02-22 06:19:48, Dmitry Baryshkov wrote:
> The commit adding msm8998 support didn't added msm8998's DSPP blocks
You might have meant: [did*] add(ed) msm8998's DSPP blocks configuration
[to the source /code file], but did not...
Or however you wish to word this :)
- Marijn
>
Quoting AngeloGioacchino Del Regno (2022-02-21 15:30:04)
> Il 18/02/22 15:54, Guillaume Ranquet ha scritto:
> > From: Markus Schneider-Pargmann
> >
> > This patch adds two helper functions that extract the frequency and word
> > length from a struct cea_sad.
> >
> > For these helper functions new
On DG2 we allow objects that are smaller than the min_page_size, under
the premise that these are never mapped by the GTT, like with the paging
structures. Currently the suspend-resume path will try to map such
objects through the migration vm, which hits:
[ 560.529217] kernel BUG at
25.02.2022 10:51, Sascha Hauer пишет:
> The rk3568 HDMI has an additional clock that needs to be enabled for the
> HDMI controller to work. The purpose of that clock is not clear. It is
> named "hclk" in the downstream driver, so use the same name.
>
> Signed-off-by: Sascha Hauer
> ---
>
>
Am 25.02.22 um 08:33 schrieb Daniel Vetter:
Useful for checking for dma-fence signalling annotations since they
don't quite nest as freely as we'd like to.
Cc: Matthew Brost
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: "Christian König"
Cc:
On Thu, 24 Feb 2022 14:24:25 +0100
Daniel Vetter wrote:
> Some things changed, and add two useful links.
>
> v2: Also include a link to the QR encoding work. Plus review from
> Javier.
>
> Reviewed-by: Javier Martinez Canillas
> Cc: Javier Martinez Canillas
> Cc: Pekka Paalanen
> Cc:
Hi,
On Thu, Feb 24, 2022 at 02:32:37PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-02-21 08:18:21)
> > Hi,
> >
> > On Fri, Feb 18, 2022 at 03:15:06PM -0800, Stephen Boyd wrote:
> > > Quoting Maxime Ripard (2022-01-25 06:15:41)
> > > > The current core while setting the min and max
On 25.02.2022 06:03, Jordan Justen wrote:
> John Harrison writes:
>
>> On 2/22/2022 02:36, Jordan Justen wrote:
>>> From: John Harrison
>>>
>>> Implement support for fetching the hardware description table from the
>>> GuC. The call is made twice - once without a destination buffer to
>>>
On Thu, 24 Feb 2022 22:03:42 -0300
Igor Torrente wrote:
> Hi Pekka,
>
> On Thu, Feb 10, 2022 at 6:50 AM Pekka Paalanen wrote:
>
> > On Fri, 21 Jan 2022 18:38:31 -0300
> > Igor Torrente wrote:
> >
> > > Adds this common format to vkms.
> > >
> > > This commit also adds new helper macros to
On Thu, Feb 24, 2022 at 02:44:20PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-02-21 08:30:01)
> > On Fri, Feb 18, 2022 at 02:34:20PM -0800, Stephen Boyd wrote:
> > > Quoting Maxime Ripard (2022-01-25 06:15:42)
> > > > The code in clk_set_rate_range() will, if the current rate is
On Thu, 24 Feb 2022 21:43:01 -0300
Igor Torrente wrote:
> Hi Pekka,
>
> On 2/10/22 06:37, Pekka Paalanen wrote:
> > On Fri, 21 Jan 2022 18:38:29 -0300
> > Igor Torrente wrote:
> >
> >> Currently the blend function only accepts XRGB_ and ARGB_
> >> as a color input.
> >>
> >> This
Hi,
On Thu, Feb 24, 2022 at 02:39:20PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-02-21 08:43:23)
> > Hi again,
> >
> > On Mon, Feb 21, 2022 at 05:18:21PM +0100, Maxime Ripard wrote:
> > > On Fri, Feb 18, 2022 at 03:15:06PM -0800, Stephen Boyd wrote:
> > > > Quoting Maxime Ripard
On Thu, Feb 24, 2022 at 07:56:08PM -0800, Kees Cook wrote:
> Hi,
>
> I'm sending these again, as they still need fixing. They have been
> rebased due to the drm_dp_helper code being moved into a subdirectory.
Yeah, I noticed the other day that this had been partially reverted by
the DP code
Il 23/02/22 04:40, Yunfei Dong ha scritto:
Capture queue format type is difference for different platform,
need to calculate capture buffer size according to capture queue
format type in scp.
Signed-off-by: Yunfei Dong
This change is ok, but the commit message should be changed to advertise
Il 23/02/22 04:40, Yunfei Dong ha scritto:
Needs to use mediatek compressed mode for mt8192 decoder.
Signed-off-by: Yunfei Dong
Reviewed-by: AngeloGioacchino Del Regno
Il 23/02/22 04:40, Yunfei Dong ha scritto:
Supported output and capture format types for mt8192 are different
with mt8183. Needs to get format types according to decoder capability.
Signed-off-by: Yunfei Dong
Reviewed-by: AngeloGioacchino Del Regno
Il 23/02/22 04:39, Yunfei Dong ha scritto:
Supported max resolution for different platforms are not the same: 2K
or 4K, getting it according to dec_capability.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
Reviewed-by: AngeloGioacchino Del Regno
Il 23/02/22 04:39, Yunfei Dong ha scritto:
Lock, power and clock are highly coupled operations. Adds vdec
enable/disable hardware helpers and uses them.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
Reviewed-by: AngeloGioacchino Del Regno
On Thu, Feb 24, 2022 at 05:30:54PM -0800, Manasi Navare wrote:
> VRR capable property is not attached by default to the connector
> It is attached only if VRR is supported.
> So if the driver tries to call drm core set prop function without
> it being attached that causes NULL dereference.
>
>
On Fri, 25 Feb 2022 at 07:45, Abhinav Kumar wrote:
>
>
>
> On 2/24/2022 8:22 PM, Dmitry Baryshkov wrote:
> > On Fri, 25 Feb 2022 at 05:01, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/24/2022 12:41 PM, Dmitry Baryshkov wrote:
> >>> On Thu, 24 Feb 2022 at 21:25, Abhinav Kumar
> >>> wrote:
On 2/21/22 15:16, Alex Deucher wrote:
Is this system S0i3 or regular S3?
>>
>> For me it is real S3.
>>
>> The proposed patch is intended for INTEl + intel gpu + amdgpu but I have
>> dual amd GPU.
> It doesn't really matter what the platform is, it could still
> potentially help on your
On 2/24/22 10:47, Sascha Hauer wrote:
> On Thu, Feb 17, 2022 at 04:24:29PM +0300, Dmitry Osipenko wrote:
>> 17.02.2022 11:29, Sascha Hauer пишет:
>>> @@ -28,6 +28,12 @@ config ROCKCHIP_VOP
>>> This selects support for the VOP driver. You should enable it
>>> on all older SoCs up to
Hello Inki,
On Thu, Feb 24, 2022 at 10:41:04AM +0900, Inki Dae wrote:
> Hi Martin.
>
> I found that exynos4 and 5 data sheet include documented same register.
> RGB_ORDER_E field of VIDCONx registers will do same thing.
If I read the manual correctly, this register combined with the
RGB_ORDER_O
101 - 200 of 202 matches
Mail list logo
