On Thu, Feb 24, 2022 at 09:24:57PM +0100, Marek Vasut wrote:
> On 2/24/22 16:40, Maxime Ripard wrote:
> > Hi,
>
> Hi,
>
> > On Sat, Feb 19, 2022 at 01:28:37AM +0100, Marek Vasut wrote:
> > > This patch series attempts to address a problem of missing support for DSI
> > > bridge-to-bridge or
On Fri, Feb 25, 2022 at 08:51:43AM +0100, Sascha Hauer wrote:
> The VOP2 is the display output controller on the RK3568. Add the node
> for it to the dtsi file along with the required display-subsystem node
> and the iommu node.
>
> Signed-off-by: Sascha Hauer
> Acked-by: Rob Herring
> ---
>
>
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 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.
>
>
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
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
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
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
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:
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:
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
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
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 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: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 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:
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 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
>
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:
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 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
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:
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
> ---
>
>
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
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
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
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 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
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 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
>>>
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
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 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
> > > ---
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
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
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
>
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
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
---
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
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 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
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
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
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 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 \
These seem to be pretty old arch and are day0 warnings, please refer to
[1] to see the warnings. Also I am not sure why my patch series didn't
append to the old one.
[1] https://patchwork.freedesktop.org/patch/475829/?series=99450=11
2022-02-25 10:19 a.m., Tvrtko Ursulin wrote:
On
This series supercedes [1]. Major change in this series is that it is now
optional to include a gpu name in the gpu-list. This helps to avoid the
confusion when we have different SKUs with different gpu names. And also
I am pretty happy that the overall changes are smaller now.
[1]
Use generic name for resources like irq and kthread instead of hardware
specific name to make it easier to grep.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/msm_gpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Add support for 7c3 SKU detection using speedbin fuse.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
Expose speedbin through MSM_PARAM_CHIP_ID parameter to help userspace
identify the sku.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 21 +
Use a gpu name which is sprintf'ed from the chipid for 7c3 gpu instead of
hardcoding one. This helps to avoid code churn in case of a gpu rename.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- use devm_kasprintf() to generate gpu name (Rob)
drivers/gpu/drm/msm/adreno/adreno_device.c | 1
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 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 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.
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: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 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:13 +0100, Maxime Ripard wrote:
> The sun4i KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in
On Mon, 21 Feb 2022 10:59:02 +0100, Maxime Ripard wrote:
> From: Dave Stevenson
>
> Some functions to create properties (drm_plane_create_zpos_property or
> drm_plane_create_color_properties for example) will ask for a range of
> acceptable value and an initial one.
>
> This initial value is
On Mon, 21 Feb 2022 10:59:11 +0100, Maxime Ripard wrote:
> The rcar-du KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in rcar_du_plane_reset()
On Mon, 21 Feb 2022 10:59:10 +0100, Maxime Ripard wrote:
> The omap KMS driver will call drm_plane_create_zpos_property() with an
> init value of the plane index and the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in
On Mon, 21 Feb 2022 10:59:08 +0100, Maxime Ripard wrote:
> The mdp 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 mdp5_plane_reset().
On Mon, 21 Feb 2022 10:59:12 +0100, Maxime Ripard wrote:
> The sti KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in sti_plane_reset().
>
On Mon, 21 Feb 2022 10:59:14 +0100, Maxime Ripard wrote:
> From: Dave Stevenson
>
> The drm_plane_create_color_properties() function asks for an initial
> value for the color encoding and range, and will set the associated
> plane state variable with that value if a state is present.
>
>
On Mon, 21 Feb 2022 10:59:18 +0100, Maxime Ripard wrote:
> The omap KMS driver will call drm_plane_create_color_properties() with
> a default encoding and range values of BT601 and Full Range,
> respectively.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it
On 24/02/2022 19:51, John Harrison wrote:
On 2/24/2022 11:19, John Harrison wrote:
[snip]
I'll change it to _uses_ and repost, then.
[ 7.683149] kernel BUG at drivers/gpu/drm/i915/gt/uc/intel_guc.h:367!
Told you that one went bang.
intel_guc_is_used ?
My suggestion was
On Fri, Feb 25, 2022 at 05:41:17PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use lockdep_assert_not_held to simplify and correct the code. Otherwise
> false positive are hit if lock state is uknown like after a previous
> taint.
>
> Signed-off-by: Tvrtko Ursulin
> Reported-by:
Quoting Kuogee Hsieh (2022-02-22 16:27:39)
> Widebus feature will transmit two pixel data per pixel clock to interface.
> Timing engine provides driving force for this purpose. This patch base
> on HPG (Hardware Programming Guide) to revise timing engine register
> setting to accommodate both
On 25/02/2022 17:40, Michael Cheng wrote:
Ah, thanks for pointing that out, when I do include it though, it causes
a few warning other systems such as h8300 and s390.
Errors look like? I haven't heard that kernel code is not allowed to
include something from linux/ on some arch yet.
Since
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 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.
Hi Dave, Daniel,
New stuff for 5.18.
The following changes since commit b63c54d978236dd6014cf2ffba96d626e97c915c:
drm/amdkfd: Use proper enum in pm_unmap_queues_v9() (2022-02-17 15:59:06
-0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
On 25/02/2022 18:05, Michal Wajdeczko wrote:
On 25.02.2022 18:18, Tvrtko Ursulin wrote:
On 25/02/2022 16:46, John Harrison wrote:
driver we don't care that much that we failed to load HWconfig and
'notice' is enough.
but I'm fine with all messages being drm_err (as we will not have 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 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
On 2/25/2022 09:06, Tvrtko Ursulin wrote:
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:
On 25/02/2022 17:11, John Harrison wrote:
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,
Ah, thanks for pointing that out, when I do include it though, it causes
a few warning other systems such as h8300 and s390.
Since it is already pulled is, would it be OK to leave it out for this
case? Or we could use something like !IS_H8300 and !IS_S390
around the header file?
On
On 2/25/2022 09:39, Tvrtko Ursulin wrote:
On 25/02/2022 17:11, John Harrison wrote:
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
Hi Robin,
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
* Thanks for adding the arm64 maintainer and sorry I didn't rope them
in sooner.
Why does i915 need to ensure the CPU's instruction cache is coherent
with its data cache? Is it
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 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
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
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
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
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
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
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
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
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
>
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 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 25/02/2022 16:52, Michael Cheng wrote:
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 \
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 use the driver core removable attribute to indicate the
> detail a
Quoting Vinod Polimera (2022-02-25 07:57:49)
> 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
On 25/02/2022 18:01, John Harrison wrote:
On 2/25/2022 09:39, Tvrtko Ursulin wrote:
On 25/02/2022 17:11, John Harrison wrote:
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
On Fri, 18 Feb 2022 18:28:15 +0800, Rex Nie wrote:
> Add support for InnoLux n140hca-eac display panel. It is a 14" eDP panel
> with 1920x1080 display resolution.
>
> Signed-off-by: Rex Nie
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2
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
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 +
1 - 100 of 202 matches
Mail list logo
