On 04/06/2024 19:52, Abhinav Kumar wrote:
>
>
> On 6/4/2024 8:36 AM, Krzysztof Kozlowski wrote:
>> On 04/06/2024 17:32, Dmitry Baryshkov wrote:
>>> On Tue, Jun 04, 2024 at 05:22:03PM +0200, Krzysztof Kozlowski wrote:
On 04/06/2024 17:14, Dmitry Baryshkov wrote:
>>
>> I didnt
On Tue, Jun 04, 2024 at 05:38:28PM -0700, Abhinav Kumar wrote:
> GCC diagnostic pragma method throws below warnings in some of the versions
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:16:9: warning: unknown
> option after '#pragma GCC diagnostic' kind [-Wpragmas]
> #pragma GCC diagnostic ign
e as below:
-->
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240604/202406041618.27dcc912-oliver.s
On 2024/6/5 10:00, Baolu Lu wrote:
On 6/4/24 4:03 PM, Yi Liu wrote:
On 2024/6/4 09:51, Lu Baolu wrote:
Commit <909f4abd1097> ("iommu: Add new iommu op to create domains owned
by userspace") added a dedicated iommu op to allocate a user domain.
While IOMMUFD has already made use of this callback
Thanks for looking at ixing this Tvrtko.
El mar, 04-06-2024 a las 17:02 +0100, Tvrtko Ursulin escribió:
> From: Tvrtko Ursulin
>
> Move static const array into the source file to fix the "defined but
> not
> used" errors.
>
> The fix is perhaps not the prettiest due hand crafting the array
> si
Hi Abhinav,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next-fixes]
[also build test WARNING on drm-tip/drm-tip linus/master v6.10-rc2
next-20240604]
[cannot apply to drm-intel/for-linux-next]
[If your patch is applied to the wrong git
On Tue, Jun 4, 2024 at 8:39 PM AngeloGioacchino Del Regno
wrote:
>
> MediaTek MT8188 has a Mali-G57 MC3 (Valhall-JM): add a new
> compatible and platform data using the same supplies and the
> same power domain lists as MT8183 (one regulator, three power
> domains).
>
> Signed-off-by: AngeloGioacc
Hi Abhinav,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-intel/for-linux-next-fixes]
[also build test ERROR on drm-tip/drm-tip linus/master v6.10-rc2 next-20240604]
[cannot apply to drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree
On Tue, Jun 4, 2024 at 8:39 PM AngeloGioacchino Del Regno
wrote:
>
> Add a compatible for the MediaTek MT8188 SoC, with an integrated
> ARM Mali G57 MC3 (Valhall-JM) GPU.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Reviewed-by: Chen-Yu Tsai
> ---
> Documentation/devicetree/bindings/gpu/a
On 6/5/24 12:51 AM, Jason Gunthorpe wrote:
On Tue, Jun 04, 2024 at 09:51:14AM +0800, Lu Baolu wrote:
Replace iommu_domain_alloc() with iommu_user_domain_alloc().
Signed-off-by: Lu Baolu
---
drivers/iommu/iommufd/hw_pagetable.c | 20 +---
1 file changed, 5 insertions(+), 15 d
On 6/4/24 4:03 PM, Yi Liu wrote:
On 2024/6/4 09:51, Lu Baolu wrote:
Commit <909f4abd1097> ("iommu: Add new iommu op to create domains owned
by userspace") added a dedicated iommu op to allocate a user domain.
While IOMMUFD has already made use of this callback, other frameworks
like vfio/type1 a
From: Barry Song
dma_heap_allocation_data defines the UAPI as follows:
struct dma_heap_allocation_data {
__u64 len;
__u32 fd;
__u32 fd_flags;
__u64 heap_flags;
};
However, dma_heap_buffer_alloc() casts both fd_flags and heap_flags
into unsigned int. We're incon
-20240604]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Christian-K-nig/d
> How is the compiler going to know which path is going to be taken the most?
> There's two main paths in the ring buffer logic. One when an event stays on
> the sub-buffer, the other when the event crosses over to a new sub buffer.
> As there's 100s of events that happen on the same sub-buffer for
GCC diagnostic pragma method throws below warnings in some of the versions
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:16:9: warning: unknown
option after '#pragma GCC diagnostic' kind [-Wpragmas]
#pragma GCC diagnostic ignored "-Wunused-const-variable"
^
In file included from drivers/
GCC diagnostic pragma method throws below warnings in some of the versions
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:16:9: warning: unknown
option after '#pragma GCC diagnostic' kind [-Wpragmas]
#pragma GCC diagnostic ignored "-Wunused-const-variable"
^
In file included from drivers/
On Wed, 5 Jun 2024 01:44:37 +0200
Andrew Lunn wrote:
> > Interesting, as I sped up the ftrace ring buffer by a substantial amount by
> > adding strategic __always_inline, noinline, likely() and unlikely()
> > throughout the code. It had to do with what was considered the fast path
> > and slow pa
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
Now that most panels have been updated not to track/double-check their
prepared/enabled state update the TODO with next steps.
Acked-by: Linus Walleij
Acked-by: Maxime Ripard
Signed-off-by: Douglas Anderson
---
(no changes since v1)
Documentation/gpu/todo.rst | 47 +--
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
At shutdown if you've got a _properly_ coded DRM modeset driver then
you'll get these two warnings at shutdown time:
Skipping disable of already disabled panel
Skipping unprepare of already unprepared panel
These warnings are ugly and sound concerning, but they're actually a
sign of a properl
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
It's the responsibility of a correctly written DRM modeset driver to
call drm_atomic_helper_shutdown() at shutdown time and that should be
disabling / unpreparing the panel if needed. Panel drivers shouldn't
be calling these functions themselves.
A recent effort was made to fix as many DRM modeset
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is n
On 6/4/2024 4:58 PM, Dmitry Baryshkov wrote:
On Tue, Jun 04, 2024 at 02:51:04PM -0700, Abhinav Kumar wrote:
GCC diagnostic pragma method throws below warnings in some of the versions
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:16:9: warning: unknown option after
'#pragma GCC diagnostic' kin
> Interesting, as I sped up the ftrace ring buffer by a substantial amount by
> adding strategic __always_inline, noinline, likely() and unlikely()
> throughout the code. It had to do with what was considered the fast path
> and slow path, and not actually the size of the function. gcc got it
> hor
On Tue, Jun 04, 2024 at 02:51:04PM -0700, Abhinav Kumar wrote:
> GCC diagnostic pragma method throws below warnings in some of the versions
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:16:9: warning: unknown option
> after '#pragma GCC diagnostic' kind [-Wpragmas]
> #pragma GCC diagnostic ign
On Tue, Jun 04, 2024 at 10:44:04PM +0300, Cristian Ciocaltea wrote:
> On 6/1/24 7:32 PM, Dmitry Baryshkov wrote:
> > On Sat, Jun 01, 2024 at 04:12:22PM +0300, Cristian Ciocaltea wrote:
> >> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
> >> Synopsys DesignWare HDMI TX controller
Hi Krzysztof,
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Tuesday, June 4, 2024 10:11 PM
> To: Jingoo Han ; Inki Dae ;
> Seung-Woo Kim ; Kyungmin Park
> ; David Airlie ; Daniel
> Vetter ; Krzysztof Kozlowski ; Alim
> Akhtar ; dri-devel@lists.freedesktop.org; linux-
> arm-ker.
On Wed, 5 Jun 2024 at 01:30, Peter Robinson wrote:
>
> On Tue, 4 Jun 2024 at 23:18, Dmitry Baryshkov
> wrote:
> >
> > On Wed, 5 Jun 2024 at 00:40, Peter Robinson wrote:
> > >
> > > Add missing MODULE_FIRMWARE for firmware in linux-firmware,
> > > this is needed for automatically adding firmware
On Tue, 4 Jun 2024 at 23:18, Dmitry Baryshkov
wrote:
>
> On Wed, 5 Jun 2024 at 00:40, Peter Robinson wrote:
> >
> > Add missing MODULE_FIRMWARE for firmware in linux-firmware,
> > this is needed for automatically adding firmware to things
> > like initrds when the drivers are built as modules. Th
Acked-by: Dave Airlie
Please merge through xe-fixes
Dave.
On Mon, 3 Jun 2024 at 05:13, Thomas Hellström
wrote:
>
> Add Rodrigo Vivi as an Xe driver maintainer.
>
> v2:
> - Cc also Lucas De Marchi (Rodrigo vivi)
> - Remove a blank line in commit the commit message (Lucas De Marchi)
>
> Cc: Davi
On Wed, 5 Jun 2024 at 00:40, Peter Robinson wrote:
>
> Add missing MODULE_FIRMWARE for firmware in linux-firmware,
> this is needed for automatically adding firmware to things
> like initrds when the drivers are built as modules. This is
> useful for devices like the X13s and the RBx devices on
>
On 2024-05-22 18:05, Mario Limonciello wrote:
The `power saving policy` DRM property is an optional property that
can be added to a connector by a driver.
This property is for compositors to indicate intent of policy of
whether a driver can use power saving features that may compromise
the ex
On 2024-05-22 18:05, Mario Limonciello wrote:
When the `power_saving_policy` property is set to bit mask
"Require color accuracy" ABM should be disabled immediately and
any requests by sysfs to update will return an -EBUSY error.
When the `power_saving_policy` property is set to bit mask
"Requ
GCC diagnostic pragma method throws below warnings in some of the versions
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:16:9: warning: unknown option after
'#pragma GCC diagnostic' kind [-Wpragmas]
#pragma GCC diagnostic ignored "-Wunused-const-variable"
^
In file included from drivers/g
Add missing MODULE_FIRMWARE for firmware in linux-firmware,
this is needed for automatically adding firmware to things
like initrds when the drivers are built as modules. This is
useful for devices like the X13s and the RBx devices on
general distros.
Fixes: 5e7665b5e484b ("drm/msm/adreno: Add Adr
On Tue, Jun 4, 2024 at 8:41 AM Greg Kroah-Hartman
wrote:
>
> On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote:
> > We can skip children resources when the parent resource does not cover
> > the range.
> >
> > This should help vmf_insert_* users on x86, such as several DRM drivers.
> > On
On 6/4/24 11:41 PM, Sam Ravnborg wrote:
> Hi Cristian.
>
> On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
>> Hi Sam,
>>
>> On 6/1/24 5:32 PM, Sam Ravnborg wrote:
>>> Hi Cristian,
>>>
>>> a few drive-by comments below.
>>>
>>> Sam
>>>
>>>
+
+static const struct dr
Hi Cristian.
On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
> Hi Sam,
>
> On 6/1/24 5:32 PM, Sam Ravnborg wrote:
> > Hi Cristian,
> >
> > a few drive-by comments below.
> >
> > Sam
> >
> >
> >> +
> >> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs
On 6/3/24 4:08 PM, neil.armstr...@linaro.org wrote:
> Hi,
>
> On 03/06/2024 15:03, Heiko Stuebner wrote:
>> Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan:
>>> Hi Neil:
>>>
>>> On 6/3/24 16:55, Neil Armstrong wrote:
Hi Christian,
On 01/06/2024 15:12, Cristian Ciocaltea wrot
On 6/2/24 10:59 AM, Piotr Oniszczuk wrote:
> (resent as plain text instead of html)
>
> Cristian,
>
> I was awaiting over year for this work!
>
> I’m devel. 2 distros where single mainline kernel serves
> 2835/2711/2712/h6/h313/h616/h618/rk3328/rk3399/rk3566/rk3568/rk3588/s905/s912/sm1/g12.
>
On 6/1/24 7:32 PM, Dmitry Baryshkov wrote:
> On Sat, Jun 01, 2024 at 04:12:22PM +0300, Cristian Ciocaltea wrote:
>> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
>> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
>>
>> It is HDMI 2.1 compliant and supports the
Hi Sam,
On 6/1/24 5:32 PM, Sam Ravnborg wrote:
> Hi Cristian,
>
> a few drive-by comments below.
>
> Sam
>
>
>> +
>> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
>> +.fill_modes = drm_helper_probe_single_connector_modes,
>> +.detect = dw_hdmi_connector_
[now without a descriptor leak; it really needs testing, though]
Using drm_gem_prime_handle_to_fd() to set dmabuf up and insert it into
descriptor table, only to have it looked up by file descriptor and
remove it from descriptor table is not just too convoluted - it's
racy; another thread might ha
On Tue, Jun 04, 2024 at 02:08:30PM -0400, Felix Kuehling wrote:
> > +int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> > + struct drm_file *file_priv, uint32_t handle,
> > + uint32_t flags,
> > + int *prime_fd)
> > +{
On Tue, 04 Jun 2024 10:45:37 +0300
Jani Nikula wrote:
> On Sun, 02 Jun 2024, Andy Shevchenko
> wrote:
> > Make two APIs look similar. Hence convert match_string() to be
> > a 2-argument macro. In order to avoid unneeded churn, convert
> > all users as well. There is no functional change intende
Hi Andy,
On Sun, Jun 02, 2024 at 06:57:12PM +0300, Andy Shevchenko wrote:
> Make two APIs look similar. Hence convert match_string() to be
> a 2-argument macro. In order to avoid unneeded churn, convert
> all users as well. There is no functional change intended.
>
> Signed-off-by: Andy Shevchenk
On Tue, 4 Jun 2024 at 11:25, Rodrigo Vivi wrote:
>
> (I believe that the new _match_string(str1, size, str2) deserves a better
> name,
> but since I'm bad with naming stuff, I don't have any good suggestion)
I hated the enormous cc list, so I didn't reply to all. But clearly
everybody else is ju
On Sun, Jun 02, 2024 at 06:57:12PM +0300, Andy Shevchenko wrote:
> Make two APIs look similar. Hence convert match_string() to be
> a 2-argument macro. In order to avoid unneeded churn, convert
> all users as well. There is no functional change intended.
>
> Signed-off-by: Andy Shevchenko
> ---
>
[AMD Official Use Only - AMD Internal Distribution Only]
> -Original Message-
> From: Kuehling, Felix
> Sent: Tuesday, June 4, 2024 2:25 PM
> To: Armin Wolf ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> gre...@linuxfoundation.org; sas...@kernel.org
> Cc: sta...@vger.kerne
On 2024-06-03 18:19, Armin Wolf wrote:
Am 23.05.24 um 19:30 schrieb Armin Wolf:
This reverts commit 56b522f4668167096a50c39446d6263c96219f5f.
A user reported that this commit breaks the integrated gpu of his
notebook, causing a black screen. He was able to bisect the problematic
commit and v
On 6/4/2024 11:33 PM, John Stultz wrote:
> On Mon, Jun 3, 2024 at 11:30 PM Hailong Liu wrote:
>> On 6/4/2024 2:06 AM, John Stultz wrote:
>>> On Mon, Jun 3, 2024 at 10:21 AM Hailong Liu wrote:
We now aim to improve priority dma-buf allocation. Consider android
animations scene:
From: Daniil Titov
This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz),
SDM439 (650 MHz).
Signed-off-by: Daniil Titov
Signed-off-by: Barnabás Czémán
---
Changes in v2:
- use DRM_MSM_INACTIVE_PERIOD instead of 250 ms.
- Link to v1:
https://lore.kernel.org/r/20240604-a505-v1
On 2024-06-03 22:13, Al Viro wrote:
Using drm_gem_prime_handle_to_fd() to set dmabuf up and insert it into
descriptor table, only to have it looked up by file descriptor and
remove it from descriptor table is not just too convoluted - it's
racy; another thread might have modified the descriptor
On Mon, Jun 03, 2024 at 08:00:07PM +0200, Thorsten Blum wrote:
> The if condition !A || A && B can be simplified to !A || B.
>
> Fixes the following Coccinelle/coccicheck warning reported by
> excluded_middle.cocci:
>
> WARNING !A || A && B is equivalent to !A || B
>
> Compile-tested only.
Last caller was removed with commit 078a5b498d6a ("drm/tests:
Remove slow tests").
Cc: Maxime Ripard
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_mm.c | 35 ---
include/drm/drm_mm.h | 1 -
2 files changed, 36 deletions(-)
diff --git a/drivers/gpu/drm
On 6/4/2024 8:36 AM, Krzysztof Kozlowski wrote:
On 04/06/2024 17:32, Dmitry Baryshkov wrote:
On Tue, Jun 04, 2024 at 05:22:03PM +0200, Krzysztof Kozlowski wrote:
On 04/06/2024 17:14, Dmitry Baryshkov wrote:
I didnt follow why this is a link property. Sorry , I didnt follow the
split part.
On Tue, Jun 4, 2024 at 7:38 PM Konrad Dybcio wrote:
>
>
>
> On 6/4/24 19:33, Barnabás Czémán wrote:
> > On Tue, Jun 4, 2024 at 7:06 PM Konrad Dybcio
> > wrote:
> >>
> >>
> >>
> >> On 6/4/24 18:45, Barnabás Czémán wrote:
> >>> On Tue, Jun 4, 2024 at 2:27 PM Barnabás Czémán wrote:
>
> O
On 6/4/24 19:33, Barnabás Czémán wrote:
On Tue, Jun 4, 2024 at 7:06 PM Konrad Dybcio wrote:
On 6/4/24 18:45, Barnabás Czémán wrote:
On Tue, Jun 4, 2024 at 2:27 PM Barnabás Czémán wrote:
On Tue, Jun 4, 2024 at 1:55 PM Konrad Dybcio wrote:
On 6/4/24 02:20, Barnabás Czémán wrote:
F
On 5/14/24 20:38, Akhil P Oommen wrote:
On Wed, May 08, 2024 at 07:46:31PM +0200, Konrad Dybcio wrote:
Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the
On Tue, Jun 4, 2024 at 7:06 PM Konrad Dybcio wrote:
>
>
>
> On 6/4/24 18:45, Barnabás Czémán wrote:
> > On Tue, Jun 4, 2024 at 2:27 PM Barnabás Czémán wrote:
> >>
> >> On Tue, Jun 4, 2024 at 1:55 PM Konrad Dybcio
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 6/4/24 02:20, Barnabás Czémán wrote:
>
On 6/4/24 1:12 PM, Alexander Stein wrote:
Hi Marek,
Hi,
Am Montag, 3. Juni 2024, 23:25:43 CEST schrieb Marek Vasut:
On 6/3/24 2:18 PM, Alexander Stein wrote:
Hi Marek,
Hi,
Am Freitag, 31. Mai 2024, 22:39:49 CEST schrieb Marek Vasut:
This line_pixel_subtract is no longer needed now that
On 6/4/24 11:42 AM, Alexander Stein wrote:
Hi Marek,
Hi,
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
@@ -98,6 +98,24 @@ properties:
reference to a valid eDP panel input
On 6/4/24 11:49 AM, Alexander Stein wrote:
Hi,
@@ -2372,6 +2392,21 @@ static int tc_probe_edp_bridge_endpoint(struct tc_data
*tc)
tc->bridge.ops |= DRM_BRIDGE_OP_DETECT;
tc->bridge.ops |= DRM_BRIDGE_OP_EDID;
+ port = of_graph_get_port_by_id(dev->of_node, 2);
+
On 6/4/24 1:35 PM, Alexander Stein wrote:
Hi Marek,
Hi,
Am Montag, 3. Juni 2024, 23:27:34 CEST schrieb Marek Vasut:
On 6/3/24 2:45 PM, Alexander Stein wrote:
Hi,
@@ -1631,6 +1643,18 @@ static int tc_edp_atomic_check(struct drm_bridge *bridge,
struct drm_crtc
On 6/4/24 18:45, Barnabás Czémán wrote:
On Tue, Jun 4, 2024 at 2:27 PM Barnabás Czémán wrote:
On Tue, Jun 4, 2024 at 1:55 PM Konrad Dybcio wrote:
On 6/4/24 02:20, Barnabás Czémán wrote:
From: Daniil Titov
This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz),
SDM439
On 6/4/24 17:48, Rob Clark wrote:
From: Rob Clark
Add the SQE fw version to dmesg and devcoredump.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 32 +++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gp
Hi Neil,
On Mon, Jun 03, 2024 at 10:46:16AM +0200, Neil Armstrong wrote:
> Hi,
>
> On Thu, 30 May 2024 23:14:02 +0200, Sam Ravnborg wrote:
> > Drop myself as reviewer of panel patches, to reflect the reality.
> >
> >
>
> Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git
>
On Tue, Jun 04, 2024 at 09:51:14AM +0800, Lu Baolu wrote:
> Replace iommu_domain_alloc() with iommu_user_domain_alloc().
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/iommufd/hw_pagetable.c | 20 +---
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/driver
On Tue, Jun 4, 2024 at 2:27 PM Barnabás Czémán wrote:
>
> On Tue, Jun 4, 2024 at 1:55 PM Konrad Dybcio wrote:
> >
> >
> >
> > On 6/4/24 02:20, Barnabás Czémán wrote:
> > > From: Daniil Titov
> > >
> > > This GPU is found on SoCs such as MSM8937 (450 MHz), MSM8940 (475 MHz),
> > > SDM439 (650 MHz
On Tue, Jun 04, 2024 at 09:51:27AM +0800, Lu Baolu wrote:
> usnic_uiom_alloc_pd() allocates a paging domain for a given device.
> In this case, iommu_domain_alloc(dev->bus) is equivalent to
> iommu_paging_domain_alloc(dev). Replace it as iommu_domain_alloc()
> has been deprecated.
>
> Signed-off-
On Tue, 4 Jun 2024 13:31:58 -0300
Jason Gunthorpe wrote:
> On Tue, Jun 04, 2024 at 12:15:51PM -0400, Steven Rostedt wrote:
> > On Tue, 04 Jun 2024 12:13:15 +0200
> > Paolo Abeni wrote:
> >
> > > On Thu, 2024-05-30 at 20:16 +, Mina Almasry wrote:
> > > > diff --git a/net/core/devmem.c b/
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: d97496ca23a2d4ee80b7302849404859d9058bcd Add linux-next specific
files for 20240604
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202406041641.we3cct4c-...@intel.com
Error
On Tue, Jun 04, 2024 at 02:39:21PM +0200, AngeloGioacchino Del Regno wrote:
> Add a compatible for the MediaTek MT8188 SoC, with an integrated
> ARM Mali G57 MC3 (Valhall-JM) GPU.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Acked-by: Conor Dooley
Thanks,
Conor.
signature.asc
Description
On Tue, Jun 04, 2024 at 12:15:51PM -0400, Steven Rostedt wrote:
> On Tue, 04 Jun 2024 12:13:15 +0200
> Paolo Abeni wrote:
>
> > On Thu, 2024-05-30 at 20:16 +, Mina Almasry wrote:
> > > diff --git a/net/core/devmem.c b/net/core/devmem.c
> > > index d82f92d7cf9ce..d5fac8edf621d 100644
> > > ---
On Tue, 4 Jun 2024 at 18:48, Rob Clark wrote:
>
> From: Rob Clark
>
> Add the SQE fw version to dmesg and devcoredump.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 32 +++--
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
> drivers/gpu
On Tue, 04 Jun 2024 12:13:15 +0200
Paolo Abeni wrote:
> On Thu, 2024-05-30 at 20:16 +, Mina Almasry wrote:
> > diff --git a/net/core/devmem.c b/net/core/devmem.c
> > index d82f92d7cf9ce..d5fac8edf621d 100644
> > --- a/net/core/devmem.c
> > +++ b/net/core/devmem.c
> > @@ -32,6 +32,14 @@ static
That should probably come last.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index f7b534
This should prevent buffer moves when the threshold is reached during
CS.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 36 --
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 +
2 files changed, 29 insertions(+), 29 deletions(-)
The approach of having a separate WB slot for each submission doesn't
really work well and for example breaks GPU reset.
Use a status query packet for the fence update instead since those
should always succeed we can use the fence of the original packet to
signal the state of the operation.
Only
1 - 100 of 177 matches
Mail list logo
