On Wed, 29 Nov 2023 01:05:14 +0300
Dmitry Osipenko wrote:
> On 11/28/23 15:37, Boris Brezillon wrote:
> > On Tue, 28 Nov 2023 12:14:42 +0100
> > Maxime Ripard wrote:
> >
> >> Hi,
> >>
> >> On Fri, Nov 24, 2023 at 11:59:11AM +0100, Boris Brezillon wrote:
> >>> On Fri, 24 Nov 2023 11:40:06
El mar, 28-11-2023 a las 07:47 -0300, Maira Canal escribió:
> Hi Iago,
>
> On 11/28/23 05:42, Iago Toral wrote:
> > El lun, 27-11-2023 a las 15:48 -0300, Maíra Canal escribió:
> > > From: Melissa Wen
> > >
> > > Detach CSD job setup from CSD submission ioctl to reuse it in CPU
> > > submission
Hi Sasha:
On 11/27/23 22:16, Sascha Hauer wrote:
On Wed, Nov 22, 2023 at 08:54:38PM +0800, Andy Yan wrote:
From: Andy Yan
Set overlay mode register according to the
output mode is yuv or rgb.
Signed-off-by: Andy Yan
---
(no changes since v1)
drivers/gpu/drm/rockchip/rockchip_drm_drv.h
On Tue, Nov 28, 2023 at 08:48:06PM -0400, Jason Gunthorpe wrote:
The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
enable the IORT code so it can be COMPILE_TEST'd too.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/Kconfig| 2 --
drivers/acpi/Makefile | 2
On Tue, Nov 28, 2023 at 08:48:05PM -0400, Jason Gunthorpe wrote:
gcc on i386 (when compile testing) warns:
This is a weird test. The Makefile for drivers/acpi/arm64 is conditional
on CONFIG_ARM64. How does this happen?
8->8
obj-$(CONFIG_ARM64) += arm64/
8->8
On Tue, Nov 28, 2023 at 08:48:03PM -0400, Jason Gunthorpe wrote:
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Acked-by: Rafael J. Wysocki
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
On Tue, Nov 28, 2023 at 08:48:00PM -0400, Jason Gunthorpe wrote:
Allocation of dev->iommu must be done under the
iommu_probe_device_lock. Mark this with lockdep to discourage future
mistakes.
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
On Tue, Nov 28, 2023 at 08:47:59PM -0400, Jason Gunthorpe wrote:
Instead of returning 1 and trying to handle positive error codes just
stick to the convention of returning -ENODEV. Remove references to ops
from of_iommu_configure(), a NULL ops will already generate an error code.
There is no
On Tue, 28 Nov 2023 at 23:07, Christian König wrote:
>
> Am 28.11.23 um 13:50 schrieb Weixi Zhu:
> > The problem:
> >
> > Accelerator driver developers are forced to reinvent external MM subsystems
> > case by case, because Linux core MM only considers host memory resources.
> > These reinvented
On 2023-11-28 17:13, Alex Deucher wrote:
> On Mon, Nov 27, 2023 at 6:24 PM Phillip Susi wrote:
>>
>> Alex Deucher writes:
>>
In that case those are the already known problems with the scheduler
changes, aren't they?
>>>
>>> Yes. Those changes went into 6.7 though, not 6.6 AFAIK.
On 2023/10/25 20:50, Krzysztof Kozlowski wrote:
> On 25/10/2023 12:39, Keith Zhao wrote:
>> StarFive SoCs JH7110 display system:
>
> A nit, subject: drop second/last, redundant "yamls for". The
> "dt-bindings" prefix is already stating that these are bindings, so
> format is fixed.
>
>>
On 2023/11/29 8:48, Jason Gunthorpe wrote:
Allocation of dev->iommu must be done under the
iommu_probe_device_lock. Mark this with lockdep to discourage future
mistakes.
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 2 ++
1
On 2023/11/29 8:48, Jason Gunthorpe wrote:
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Acked-by: Rafael J. Wysocki
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
On 2023/11/29 8:47, Jason Gunthorpe wrote:
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Reviewed-by: Jerry Snitselaar
Acked-by: Rob Herring
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
Friendly ping. I think this patch was forgotten.
主 题：[PATCH] drm/qxl: remove unused declaration 日 期：2023-11-10 13:50 发件人：何敏红 收件人：airlied;kraxel;maarten.lankhorst;mripard;tzimmermann;airlied;daniel;
Some functions are never used by the driver,removing the functions declaration, it can
Friendly ping. I think this patch was forgotten.
主 题：[PATCH v2] drm/i915: correct the input parameter on _intel_dsb_commit() 日 期：2023-11-14 10:43 发件人：何敏红 收件人：何敏红;
Current, the dewake_scanline variable is defined as unsigned int,an unsigned int variable that is always greater than or
On 11/29/23 02:06, Gustavo A. R. Silva wrote:
On 11/28/23 19:01, Danilo Krummrich wrote:
On 11/16/23 20:55, Timur Tabi wrote:
On Thu, 2023-11-16 at 20:45 +0100, Danilo Krummrich wrote:
As I already mentioned for Timur's patch [2], I'd prefer to get a fix
upstream
(meaning [1] in this case).
On 11/27/23 13:56, Dan Carpenter wrote:
This unlock doesn't belong here and it leads to a double unlock in
the caller, r535_gsp_rpc_push().
Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
Signed-off-by: Dan Carpenter
Good catch - applied to drm-misc-fixes.
-
On 11/28/23 19:01, Danilo Krummrich wrote:
On 11/16/23 20:55, Timur Tabi wrote:
On Thu, 2023-11-16 at 20:45 +0100, Danilo Krummrich wrote:
As I already mentioned for Timur's patch [2], I'd prefer to get a fix
upstream
(meaning [1] in this case). Of course, that's probably more up to Timur
On 11/16/23 20:55, Timur Tabi wrote:
On Thu, 2023-11-16 at 20:45 +0100, Danilo Krummrich wrote:
As I already mentioned for Timur's patch [2], I'd prefer to get a fix
upstream
(meaning [1] in this case). Of course, that's probably more up to Timur to
tell
if this will work out.
Don't count on
Hi,
On Thu, Nov 23, 2023 at 9:54 AM Uwe Kleine-König
wrote:
>
> pm_runtime_resume_and_get() already drops the runtime PM usage counter
> in the error case. So a call to pm_runtime_put_sync() can be dropped.
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Reviewed-by: Jerry Snitselaar
Acked-by: Rob Herring
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/of_iommu.c | 31
Instead of returning 1 and trying to handle positive error codes just
stick to the convention of returning -ENODEV. Remove references to ops
from of_iommu_configure(), a NULL ops will already generate an error code.
There is no reason to check dev->bus, if err=0 at this point then the
called
gcc on i386 (when compile testing) warns:
drivers/acpi/arm64/iort.c:2014:18: warning: implicit conversion from 'unsigned
long long' to 'phys_addr_t' (aka 'unsigned int') changes value from
18446744073709551615 to 4294967295 [-Wconstant-conversion]
local_limit =
A perfect driver would only call dev_iommu_priv_set() from its probe
callback. We've made it functionally correct to call it from the of_xlate
by adding a lock around that call.
lockdep assert that iommu_probe_device_lock is held to discourage misuse.
Exclude PPC kernels with CONFIG_FSL_PAMU
The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
enable the IORT code so it can be COMPILE_TEST'd too.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/Kconfig| 2 --
drivers/acpi/Makefile | 2 +-
drivers/acpi/arm64/Kconfig | 1 +
drivers/acpi/arm64/Makefile | 2
The iommu_device_lock protects the iommu_device_list which is only read by
iommu_ops_from_fwnode().
This is now always called under the iommu_probe_device_lock, so we don't
need to double lock the linked list. Use the iommu_probe_device_lock on
the write side too.
Signed-off-by: Jason Gunthorpe
This API was defined to formalize the access to internal iommu details on
some Tegra SOCs, but a few callers got missed. Add them.
The helper already masks by 0x so remove this code from the callers.
Suggested-by: Thierry Reding
Signed-off-by: Jason Gunthorpe
---
Allocation of dev->iommu must be done under the
iommu_probe_device_lock. Mark this with lockdep to discourage future
mistakes.
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
This is not being used to pass ops, it is just a way to tell if an
iommu driver was probed. These days this can be detected directly via
device_iommu_mapped(). Call device_iommu_mapped() in the two places that
need to check it and remove the iommu parameter everywhere.
Reviewed-by: Jerry
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Acked-by: Rafael J. Wysocki
Reviewed-by: Jerry Snitselaar
Tested-by: Hector Martin
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/scan.c | 29
These are the patches from the from the prior series without the "fwspec
polishing":
https://lore.kernel.org/r/0-v2-36a0088ecaa7+22c6e-iommu_fwspec_...@nvidia.com
Rebased onto Robin's patch:
Hello,
On Fri, Nov 24, 2023 at 09:56:55AM +0100, Neil Armstrong wrote:
> On 23/11/2023 18:54, Uwe Kleine-König wrote:
> > Hello,
> >
> > this is a series I created while starring at the ti-sn65dsi86 driver in
> > the context of my pwm-lifetime series.
> >
> > The first patch should be fine. The
On Tue, Nov 28, 2023 at 04:34:30PM -0800, Doug Anderson wrote:
> On Thu, Nov 23, 2023 at 9:54 AM Uwe Kleine-König wrote:
> >
> > This aligns the function's parameters to regmap_{read,write} and
> > simplifies the next change that takes pwm driver data out of struct
> > ti_sn65dsi86.
> >
> >
Hi Uwe,
Thank you for the patch.
On Thu, Nov 23, 2023 at 06:54:27PM +0100, Uwe Kleine-König wrote:
> pm_runtime_resume_and_get() already drops the runtime PM usage counter
> in the error case. So a call to pm_runtime_put_sync() can be dropped.
>
> Signed-off-by: Uwe Kleine-König
I wonder if
On 11/21/23 14:23, Owen T. Heisler wrote:
On 11/21/23 09:16, Linux regression tracking (Thorsten Leemhuis) wrote:
On 15.11.23 07:19, Owen T. Heisler wrote:
On 10/31/23 04:18, Linux regression tracking (Thorsten Leemhuis) wrote:
On 28.10.23 04:46, Owen T. Heisler wrote:
#regzbot introduced:
On Tue, Nov 28, 2023 at 04:32:10PM -0800, Doug Anderson wrote:
> On Thu, Nov 23, 2023 at 9:54 AM Uwe Kleine-König wrote:
> >
> > Introduce a dedicated private data structure for the pwm aux driver
> > provided by the sn65dsi86 driver. This way data needed for PWM operation
> > is (to a certain
Hi,
On Thu, Nov 23, 2023 at 9:54 AM Uwe Kleine-König
wrote:
>
> This aligns the function's parameters to regmap_{read,write} and
> simplifies the next change that takes pwm driver data out of struct
> ti_sn65dsi86.
>
> Signed-off-by: Uwe Kleine-König
> ---
>
Hi,
On Thu, Nov 23, 2023 at 9:54 AM Uwe Kleine-König
wrote:
>
> Introduce a dedicated private data structure for the pwm aux driver
> provided by the sn65dsi86 driver. This way data needed for PWM operation
> is (to a certain degree) nicely separated and doesn't occupy memory in
> the
>> >> > DSI device lifetime has three different stages:
>> >> > 1. before the DSI link being powered up and clocking,
>> >> > 2. when the DSI link is in LP state (for the purpose of this question,
>> >> > this is the time between the DSI link being powered up and the video
>> >> > stream start)
I'm facing similar issues with the tc358775 bridge. This bridge needs
to release its reset while both clock and data lanes are in LP-11
mode.
But then it needs to be configured (via I2C) while the clock lane is
in enabled (HS mode), but the data lanes are still in LP-11 mode.
This is quite an
Hi,
On Fri, Nov 17, 2023 at 1:51 PM Hsin-Yi Wang wrote:
>
> If a non generic edp-panel is under aux-bus, the mode read from edid would
> still be selected as preferred and results in multiple preferred modes,
> which is ambiguous.
>
> If both hard-coded mode and edid exists, only add mode from
Hi,
On Fri, Nov 17, 2023 at 1:51 PM Hsin-Yi Wang wrote:
>
> Add auo_b116xa3_mode to override the original modes parsed from edid
> of the panels 0x405c B116XAK01.0 and 0x615c B116XAN06.1 which result
> in glitches on panel.
>
> Signed-off-by: Hsin-Yi Wang
> ---
> v6->v7: split usecase to
Hi,
On Fri, Nov 17, 2023 at 1:51 PM Hsin-Yi Wang wrote:
>
> Generic edp gets mode from edid. However, some panels report incorrect
> mode in this way, resulting in glitches on panel. Introduce a new quirk
> additional_mode to the generic edid to pick a correct hardcoded mode.
>
> Signed-off-by:
On Wed, 29 Nov 2023 at 00:20, Michael Walle wrote:
>
> [sorry I fat fingered my former reply and converted all CCs to BCCs..]
>
> >> >> >> > DSI device lifetime has three different stages:
> >> >> >> > 1. before the DSI link being powered up and clocking,
> >> >> >> > 2. when the DSI link is in
[sorry I fat fingered my former reply and converted all CCs to BCCs..]
>> >> > DSI device lifetime has three different stages:
>> >> > 1. before the DSI link being powered up and clocking,
>> >> > 2. when the DSI link is in LP state (for the purpose of this question,
>> >> > this is the time
On Mon, Nov 27, 2023 at 6:24 PM Phillip Susi wrote:
>
> Alex Deucher writes:
>
> >> In that case those are the already known problems with the scheduler
> >> changes, aren't they?
> >
> > Yes. Those changes went into 6.7 though, not 6.6 AFAIK. Maybe I'm
> > misunderstanding what the original
On 2023-11-16 14:57, Melissa Wen wrote:
> Hello,
>
> This series extends the current KMS color management API with AMD
> driver-specific properties to enhance the color management support on
> AMD Steam Deck. The key additions to the color pipeline include:
>
snip
> Melissa Wen (18):
>
On 11/28/23 15:37, Boris Brezillon wrote:
> On Tue, 28 Nov 2023 12:14:42 +0100
> Maxime Ripard wrote:
>
>> Hi,
>>
>> On Fri, Nov 24, 2023 at 11:59:11AM +0100, Boris Brezillon wrote:
>>> On Fri, 24 Nov 2023 11:40:06 +0100
>>> Maxime Ripard wrote:
>>>
On Mon, Oct 30, 2023 at 02:01:43AM
On Tue, Nov 28, 2023 at 06:49:23PM +0100, Thierry Reding wrote:
>
> On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
> > Merging
> > ===
> > I propose to take entire patchset through my tree (Samsung SoC), because:
On Tue, 28 Nov 2023 at 19:43, Paloma Arellano wrote:
>
>
> On 11/27/2023 5:48 PM, Dmitry Baryshkov wrote:
> > On Tue, 28 Nov 2023 at 03:12, Paloma Arellano
> > wrote:
> >> Trigger a devcoredump to dump dpu registers and capture the drm atomic
> >> state when the frame_done_timer timeouts.
> >>
On Tue, 28 Nov 2023 at 21:50, Michael Walle wrote:
>
> >> >> > DSI device lifetime has three different stages:
> >> >> > 1. before the DSI link being powered up and clocking,
> >> >> > 2. when the DSI link is in LP state (for the purpose of this question,
> >> >> > this is the time between the
On 2023-11-28 12:22, Alex Deucher wrote:
On Thu, Nov 23, 2023 at 6:12 PM Felix Kuehling wrote:
[+Alex]
On 2023-11-17 16:44, Felix Kuehling wrote:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right
November 2, 2023 at 6:56 PM, "Uwe Kleine-König" mailto:u.kleine-koe...@pengutronix.de?to=%22Uwe%20Kleine-K%C3%B6nig%22%20%3Cu.kleine-koenig%40pengutronix.de%3E
> wrote:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible
>> >> > DSI device lifetime has three different stages:
>> >> > 1. before the DSI link being powered up and clocking,
>> >> > 2. when the DSI link is in LP state (for the purpose of this question,
>> >> > this is the time between the DSI link being powered up and the video
>> >> > stream start)
>>
November 28, 2023 at 6:49 PM, "Uwe Kleine-König"
mailto:u.kleine-koe...@pengutronix.de?to=%22Uwe%20Kleine-K%C3%B6nig%22%20%3Cu.kleine-koenig%40pengutronix.de%3E
> wrote:
>
> On Fri, Nov 03, 2023 at 09:58:07AM +0200, Tomi Valkeinen wrote:
>
> >
> > On 02/11/2023 18:56, Uwe Kleine-König wrote:
Geert Uytterhoeven writes:
> Hi Javier,
>
> On Tue, Nov 28, 2023 at 8:03 PM Javier Martinez Canillas
> wrote:
>> Geert Uytterhoeven writes:
>> > The Imagination Technologies PowerVR Series 6 GPU is currently only
>> > supported on Texas Instruments K3 AM62x SoCs. Hence add a dependency on
>>
On 2023-11-27 11:09, Bert Karwatzki wrote:
> Commit f3123c2590005c, in combination with the use of work queues by the GPU
> scheduler, leads to random lock-ups of the GUI.
>
> This is a partial revert of of commit f3123c2590005c since drm_sched_wakeup()
> still
> needs its entity argument to
Hi Javier,
On Tue, Nov 28, 2023 at 8:03 PM Javier Martinez Canillas
wrote:
> Geert Uytterhoeven writes:
> > The Imagination Technologies PowerVR Series 6 GPU is currently only
> > supported on Texas Instruments K3 AM62x SoCs. Hence add a dependency on
> > ARCH_K3, to prevent asking the user
Geert Uytterhoeven writes:
Hello Geert,
> The Imagination Technologies PowerVR Series 6 GPU is currently only
> supported on Texas Instruments K3 AM62x SoCs. Hence add a dependency on
> ARCH_K3, to prevent asking the user about this driver when configuring a
> kernel without Texas Instruments
On 11/28/23 11:47, Donald Robson wrote:
Hi Danilo,
Apologies - I guess I should have submitted a patch to handle zero fences in
your
locking functions with the final patch series.
On Sat, 2023-11-25 at 00:36 +0100, Danilo Krummrich wrote:
*** CAUTION: This email originates from a source not
The Imagination Technologies PowerVR Series 6 GPU is currently only
supported on Texas Instruments K3 AM62x SoCs. Hence add a dependency on
ARCH_K3, to prevent asking the user about this driver when configuring a
kernel without Texas Instruments K3 Multicore SoC support.
Fixes: 4babef0708656c54
On Tue, Nov 28, 2023 at 04:08:39PM +0100, Flavio Suligoi wrote:
> In the function "pm3309c_parse_dt_node", when the dimming analog control
> mode (by I2C messages) is enabled, the local variable "prop_levels" is
> tested without any initialization, as indicated by the following smatch
> warning
On Mon, Nov 27, 2023 at 12:11:50PM -0800, Alan Previn wrote:
> Add missing tag for "Wa_14019159160 - Case 2" (for existing
> PXP code that ensures run alone mode bit is set to allow
> PxP-decryption.
>
> v3: - Check targeted platforms using IP_VAL. (John Harrison)
> v2: - Fix WA id number (John
On Tue, 28 Nov 2023 17:35:07 +, Donald Robson wrote:
> Some reported by Stephen Rothwell. The rest were found by running the
> kernel-doc build script.
> Some indentation fixes.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
Logging DCN3 MPC state was following DCN1 implementation that doesn't
consider new DCN3 MPC color blocks. Create new elements according to
DCN3 MPC color caps and a new DCN3-specific function for reading MPC
data.
v3:
- remove gamut remap reg reading in favor of fixed31_32 matrix data
Add color caps information for DPP and MPC block to show HW color caps.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/hwss/dcn10/dcn10_hwseq.c | 23 +++
.../amd/display/dc/hwss/dcn30/dcn30_hwseq.c | 23 +++
2 files changed, 46 insertions(+)
diff --git
Color caps changed between HW versions, which caused the DCN10 color
state sections in the DTN log to no longer match DCN2+ state. Create a
color state log specific to DCN2.0 and hook it up to DCN2 family
drivers. Instead of reading gamut remap reg values, display gamut remap
matrix data in fixed
Color caps changed between HW versions, which caused the DCN10 color
state sections in the DTN log to no longer match DCN3+ state. Create a
color state log specific to DCN3.0 and hook it up to DCN3.0+ and DCN3.1+
drivers.
rfc-v2:
- detail RAM mode for gamcor and blnd gamma blocks
- add MPC gamut
We want to be able to read the MPC's gamut remap matrix similar to
what we do with .dpp_get_gamut_remap functions. On the other hand, we
don't need a hook here because only DCN3+ has the MPC gamut remap
block, being absent in previous families.
Signed-off-by: Melissa Wen
---
From: Harry Wentland
We want to be able to read the DPP's gamut remap matrix.
v2:
- code-style and doc comments clean-up (Melissa)
Signed-off-by: Harry Wentland
Signed-off-by: Melissa Wen
---
.../drm/amd/display/dc/basics/conversion.c| 34 +
DCN3 DPP color state was uncollected and some state elements from DCN1
doesn't fit DCN3. Create new elements according to DCN3 color caps and
fill them up for DTN log output.
rfc-v2:
- fix reading of gamcor and blnd gamma states
- remove gamut remap register in favor of gamut remap matrix reading
This series updates the color state section of the AMD DTN log to match
color resource differences between DCN versions.
Currently, the DTN log considers the DCN10 color pipeline, which is
useless for newer DCN versions due to all the color capability
differences. In addition to the new color
Instead of read gamut remap data from hw values, convert HW register
values (S2D13) into a fixed-point 31.32 matrix for color state log.
Change DCN10 log to print data in the format of the gamut remap matrix.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/hwss/dcn10/dcn10_hwseq.c | 38
Prepare to hook up color state log according to the DCN version.
v3:
- put functions in single line (Siqueira)
Signed-off-by: Melissa Wen
---
.../amd/display/dc/hwss/dcn10/dcn10_hwseq.c | 26 +--
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git
On Tue, Nov 28, 2023 at 6:28 AM Alex Deucher wrote:
>
> On Tue, Nov 28, 2023 at 9:17 AM Christian König
> wrote:
> >
> > Am 17.11.23 um 20:56 schrieb Alex Deucher:
> > > Add shared stats. Useful for seeing shared memory.
> > >
> > > Signed-off-by: Alex Deucher
> > > ---
> > >
On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
> Merging
> ===
> I propose to take entire patchset through my tree (Samsung SoC), because:
> 1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920),
> so
>they will touch the same lines in some of the
On 11/27/2023 5:48 PM, Dmitry Baryshkov wrote:
On Tue, 28 Nov 2023 at 03:12, Paloma Arellano wrote:
Trigger a devcoredump to dump dpu registers and capture the drm atomic
state when the frame_done_timer timeouts.
Signed-off-by: Paloma Arellano
---
Some reported by Stephen Rothwell. The rest were found by running the
kernel-doc build script.
Some indentation fixes.
Reported-by: Stephen Rothwell
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202311241526.y2wzeuau-...@intel.com/
Signed-off-by: Donald Robson
On Thu, Nov 23, 2023 at 6:12 PM Felix Kuehling wrote:
>
> [+Alex]
>
> On 2023-11-17 16:44, Felix Kuehling wrote:
>
> > This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
> >
> > These helper functions are needed for KFD to export and import DMABufs
> > the right way without duplicating
On Tue, 28 Nov 2023 at 18:56, Michael Walle wrote:
>
> >> > DSI device lifetime has three different stages:
> >> > 1. before the DSI link being powered up and clocking,
> >> > 2. when the DSI link is in LP state (for the purpose of this question,
> >> > this is the time between the DSI link being
On 28/11/2023 17:55, Uwe Kleine-König wrote:
> Hello Inki,
>
> On Wed, Nov 08, 2023 at 08:54:54AM +0100, Uwe Kleine-König wrote:
>> Hello Inki,
>>
>> On Wed, Nov 08, 2023 at 01:16:18PM +0900, Inki Dae wrote:
>>> Sorry for late. There was a merge conflict so I fixed it manually and
>>> merged. And
> DSI device lifetime has three different stages:
> 1. before the DSI link being powered up and clocking,
> 2. when the DSI link is in LP state (for the purpose of this question,
> this is the time between the DSI link being powered up and the video
> stream start)
> 3. when the DSI link is in HS
Hello Inki,
On Wed, Nov 08, 2023 at 08:54:54AM +0100, Uwe Kleine-König wrote:
> Hello Inki,
>
> On Wed, Nov 08, 2023 at 01:16:18PM +0900, Inki Dae wrote:
> > Sorry for late. There was a merge conflict so I fixed it manually and
> > merged. And seems your patch description is duplicated so
On Fri, Nov 03, 2023 at 09:58:07AM +0200, Tomi Valkeinen wrote:
> On 02/11/2023 18:56, Uwe Kleine-König wrote:
> > The .remove() callback for a platform driver returns an int which makes
> > many driver authors wrongly assume it's possible to do error handling by
> > returning an error code.
On Mon, 27 Nov 2023 at 18:07, Michael Walle wrote:
>
> Hi,
>
> > DSI device lifetime has three different stages:
> > 1. before the DSI link being powered up and clocking,
> > 2. when the DSI link is in LP state (for the purpose of this question,
> > this is the time between the DSI link being
On Tue, 28 Nov 2023 17:10:17 +0100
AngeloGioacchino Del Regno
wrote:
> >>if (status)
> >>panfrost_job_irq_handler_thread(pfdev->js->irq, (void*)pfdev);
> >
> > Nope, we don't need to read the STAT reg and forcibly call the threaded
> > handler if it's != 0. The
On Thu, 23 Nov 2023 13:18:07 +0800, Liu Ying wrote:
> Fix a couple of building warnings on used uninitialized 'best_m' and
> 'best_n' local variables by initializing 'best_m' to zero and 'best_n'
> to UINT_MAX. This makes compiler happy only. No functional change.
>
>
Applied, thanks!
[1/1]
Il 28/11/23 16:53, Boris Brezillon ha scritto:
On Tue, 28 Nov 2023 16:10:45 +0100
AngeloGioacchino Del Regno
wrote:
static void panfrost_job_handle_err(struct panfrost_device *pfdev,
struct panfrost_job *job,
unsigned
On Tue, Nov 28, 2023 at 04:51:25PM +0100, Thomas Hellström wrote:
> On Mon, 2023-11-27 at 14:36 -0500, Rodrigo Vivi wrote:
> > On Tue, Nov 21, 2023 at 11:40:46AM +0100, Thomas Hellström wrote:
> > > Add the first version of the VM_BIND locking document which is
> > > intended to be part of the xe
On Fri, 24 Nov 2023 10:42:30 +0100, Dario Binacchi wrote:
> s/singals/signals/
>
>
Applied, thanks!
[1/1] drm/bridge: Fix typo in post_disable() description
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=288b039db225
Rob
On Tue, 28 Nov 2023 16:42:25 +0100
AngeloGioacchino Del Regno
wrote:
> >>
> panfrost_device_reset(pfdev);
> panfrost_devfreq_resume(pfdev);
>
> @@ -421,6 +422,9 @@ static int panfrost_device_runtime_suspend(struct
> device *dev)
>
Will work on that.
Dipam Turkar
On Tue, Nov 28, 2023 at 8:39 PM Maxime Ripard wrote:
> Hi,
>
> On Sat, Nov 11, 2023 at 12:54:53AM +0530, Dipam Turkar wrote:
> > Introduce unit tests for the drm_mode_create_dvi_i_properties() function
> to ensure
> > the proper creation of DVI-I specific
Accelerator driver developers are forced to reinvent external MM subsystems
case by case, introducing redundant code (14K~70K for each case). This is
because Linux core MM only considers host memory resources. At the same
time, application-level developers suffer from poor programmability -- they
This patch adds a new NUMA node state, named N_HETEROGENEOUS. It is
utilized to identify heterogeneous NUMA (hNUMA) node. Note that hNUMA node
may not be directly accessible by the CPU.
Each hNUMA node can be identified with a NUMA id. This can be extended to
provide NUMA topology including
This patch resolves potential VMA conflicts when
mmap(MAP_PRIVATE | MAP_PEER_SHARED) is invoked. Note that the semantic of
mmap(MAP_PRIVATE | MAP_PEER_SHARED) is to provide a coherent view of memory
through the allocated virtual addresses between the CPU and all attached
devices. However, an
This patch adds an abstraction layer, struct vm_object, that maintains
per-process virtual-to-physical mapping status stored in struct gm_mapping.
For example, a virtual page may be mapped to a CPU physical page or to a
device physical page. Struct vm_object effectively maintains an
This patch extends Linux core MM to support unified virtual address space.
A unified virtual address space provides a coherent view of memory for the
CPU and devices. This is achieved by maintaining coherent page tables for
the CPU and any attached devices for each process, without assuming that
The problem:
Accelerator driver developers are forced to reinvent external MM subsystems
case by case, because Linux core MM only considers host memory resources.
These reinvented MM subsystems have similar orders of magnitude of LoC as
Linux MM (80K), e.g. Nvidia-UVM has 70K, AMD GPU has 14K and
This patch adds a new syscall, hmadvise(), to issue memory hints for
heterogeneous NUMA nodes. The new syscall effectively extends madvise()
with one additional argument that indicates the NUMA id of a heterogeneous
device, which is not necessarily accessible by the CPU.
The implemented memory
1 - 100 of 269 matches
Mail list logo
