The Berlin2 divider clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The SAM9x5 slow clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The SAM9x5 main clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The Actions "Pass" clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The single parent clock in our kunit tests implements a mux with a
set_parent hook, but doesn't provide a determine_rate implementation.
This is not entirely unexpected, since its whole purpose it to have a
single parent. When determine_rate is missing, and since
CLK_SET_RATE_PARENT is set for
The nodrv clock implements a mux with a set_parent hook, but doesn't
provide a determine_rate implementation.
Even though it's a mock clock and the missing function is harmless,
we'll start to require a determine_rate implementation when set_parent
is set, so let's fill it.
Signed-off-by: Maxime
The lan966x driver registers a gck clock with both a determine_rate and
a round_rate implementation. Both are equivalent, and are only called by
clk_core_determine_round_nolock() which favors determine_rate.
Thus, lan966x_gck_round_rate() is never called, so we can just remove
it.
Signed-off-by:
Commit 262ca38f4b6e ("clk: Stop forwarding clk_rate_requests to the
parent") introduced the public clk_hw_forward_rate_request() function,
but didn't export the symbol. Make sure it's the case.
Fixes: 262ca38f4b6e ("clk: Stop forwarding clk_rate_requests to the parent")
Signed-off-by: Maxime
er still matching after this series has been
applied, but it's because it uses a composite clock which throws the
script off. The driver has been converted and shouldn't be a problem.
Let me know what you think,
Maxime
Signed-off-by: Maxime Ripard
---
Changes in v3:
- Rebased on top of next-20230
Sui Jingfeng writes:
> EFI FB, VESA FB or VGA FB etc are belong to firmware based framebuffer
> driver.
>
> Signed-off-by: Sui Jingfeng
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Am 04.04.23 um 11:43 schrieb Tvrtko Ursulin:
On 04/04/2023 01:22, Matthew Brost wrote:
Hello,
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first as well
as develop a common solution for long running workloads
On Mon, 03 Apr 2023, Lee Jones wrote:
> On Mon, 03 Apr 2023, Jani Nikula wrote:
>
>> On Fri, 31 Mar 2023, Lee Jones wrote:
>> > Fixes the following W=1 kernel build warning(s):
>> >
>> > drivers/gpu/drm/i915/i915_scatterlist.c:62: warning: Function parameter
>> > or member 'size' not described
On 04/04/2023 01:22, Matthew Brost wrote:
Hello,
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first as well
as develop a common solution for long running workloads with the DRM
scheduler. This RFC series is our
Hi,
Am 04.04.23 um 02:22 schrieb Matthew Brost:
Hello,
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first as well
as develop a common solution for long running workloads with the DRM
scheduler. This RFC series is
Am 04.04.23 um 02:22 schrieb Matthew Brost:
From: Thomas Hellström
For long-running workloads, drivers either need to open-code completion
waits, invent their own synchronization primitives or internally use
dma-fences that do not obey the cross-driver dma-fence protocol, but
without any
Please make sure to CC Luben on scheduler patches.
Regards,
Christian.
Am 04.04.23 um 02:22 schrieb Matthew Brost:
Hello,
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first as well
as develop a common solution
Hi Srikanth,
[Just cc'ing a few people who may be able to help]
On Tue, 4 Apr 2023 13:26:47 +0530 "Aithal, Srikanth" wrote:
>
> Hello,
>
> Observing below kernel crash on AMD arch, from next-20230330 onwards till
> recent build [next-20230404]:
>
> [ 68.2
Am 04.04.23 um 09:42 schrieb Paul Cercueil:
Hi Hillf,
Le mardi 04 avril 2023 à 09:59 +0800, Hillf Danton a écrit :
On 3 Apr 2023 17:47:50 +0200 Paul Cercueil
This function can be used to initiate a scatter-gather DMA transfer
where the DMA addresses and lengths are located inside arrays.
Adding a bunch of people who have been involved in this before.
Am 03.04.23 um 22:15 schrieb Joshua Ashton:
On 4/3/23 20:54, Christian König wrote:
Am 03.04.23 um 21:40 schrieb Joshua Ashton:
[SNIP]
Anyway, please let me know what you think!
Definitely open to any feedback and advice you may
Hi Thorsten,
Thank you for this review.
On 04/04/2023 10:09, Thorsten Leemhuis wrote:
>
> On 03.04.23 18:23, Matthieu Baerts wrote:
>> [...]
>> diff --git a/Documentation/process/submitting-patches.rst
>> b/Documentation/process/submitting-patches.rst
>> index 828997bc9ff9..12d58ddc2b8a 100644
Hi Danilo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on d36d68fd1925d33066d52468b7c7c6aca6521248]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers-v3/20230404-093042
base
https://bugzilla.kernel.org/show_bug.cgi?id=172421
James Hendry (jameshendr...@gmail.com) changed:
What|Removed |Added
CC|
On Mon, 2023-04-03 at 17:47 +0200, Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
>
> With this new interface, DMABUF objects (externally created) can be
> attached to a IIO buffer, and subsequently used for data
On Tue, 2023-04-04 at 09:55 +0200, Paul Cercueil wrote:
> Hi Nuno,
>
> Le mardi 04 avril 2023 à 09:32 +0200, Nuno Sá a écrit :
> > On Mon, 2023-04-03 at 17:47 +0200, Paul Cercueil wrote:
> > > Add the necessary infrastructure to the IIO core to support a new
> > > optional DMABUF based interface.
On Mon, 2023-04-03 at 17:47 +0200, Paul Cercueil wrote:
> Hi Jonathan,
>
> Here's the v3 of my patchset that introduces a new interface based on
> DMABUF objects to complement the fileio API, and adds write() support to
> the existing fileio API.
>
> It changed quite a lot since V2; the IIO
On 04.04.2023 00:36, Ville Syrjala wrote:
From: Ville Syrjälä
Include the device and connector information in the SCDC
debugs. Makes it easier to figure out who did what.
v2: Rely on connector->ddc (Maxime)
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc:
On 03.04.23 18:23, Matthieu Baerts wrote:
> [...]
> diff --git a/Documentation/process/submitting-patches.rst
> b/Documentation/process/submitting-patches.rst
> index 828997bc9ff9..12d58ddc2b8a 100644
> --- a/Documentation/process/submitting-patches.rst
> +++
On Tue, Apr 04, 2023 at 01:36:52AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Include the device and connector information in the SCDC
> debugs. Makes it easier to figure out who did what.
>
> v2: Rely on connector->ddc (Maxime)
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc:
Hi Danilo,
kernel test robot noticed the following build errors:
[auto build test ERROR on d36d68fd1925d33066d52468b7c7c6aca6521248]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-execution-context-for-GEM-buffers-v3/20230404-093042
base
Hi Nuno,
Le mardi 04 avril 2023 à 09:32 +0200, Nuno Sá a écrit :
> On Mon, 2023-04-03 at 17:47 +0200, Paul Cercueil wrote:
> > Add the necessary infrastructure to the IIO core to support a new
> > optional DMABUF based interface.
> >
> > With this new interface, DMABUF objects (externally
On Mon, 3 Apr 2023 at 18:26, Rob Clark wrote:
>
> On Mon, Apr 3, 2023 at 12:57 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:a6d9e3034536 Add linux-next specific files for 20230330
> > git tree: linux-next
> > console+strace:
Hi Hillf,
Le mardi 04 avril 2023 à 09:59 +0800, Hillf Danton a écrit :
> On 3 Apr 2023 17:47:50 +0200 Paul Cercueil
> > This function can be used to initiate a scatter-gather DMA transfer
> > where the DMA addresses and lengths are located inside arrays.
> >
> > The major difference with
The LDB driver currently checks whether dual mode is used, otherwise it
assumes only channel 0 is in use. Add support for using only channel 1. In
device tree terms, this means linking port 2 only.
Doing this cleanly requires changing the logic of the probe functions from
this:
1. use
On 01/04/2023 09:38, fei.y...@intel.com wrote:
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out its life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at
The adev->dm.dc pointer can be NULL and dereferenced in amdgpu_dm_fini()
without checking.
Add a NULL pointer check before calling dc_dmub_srv_destroy().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 9a71c7d31734 ("drm/amd/display: Register DMUB service with DC")
On Mon Apr 3, 2023 at 5:08 PM CEST, Frank Oltmanns wrote:
>
> On 2023-04-03 at 15:52:36 +0200, "Roman Beranek" wrote:
> > As little a change as setting .clock in the default mode of PP's panel
> > to 73500 can fix it. Better yet, dropping pll-video0-2x from the set
> > of acceptable parents for
On Sun Apr 2, 2023 at 12:49 PM CEST, Frank Oltmanns wrote:
>
> When apply this to drm-next my panel stays dark. I haven't figured out
> yet why, though. The other two patches in this series work fine, i.e.
> they have no effect as they are just a refactoring.
>
> I'm testing this on my pinephone.
From: Qiang Yu
This reverts commit 87767de835edf527b879a363d518c33da68adb81.
This is due to the depend commit has been reverted on upstream:
baad10973fdb ("Revert "drm/scheduler: track GPU active time per entity"")
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_device.h | 3 ---
From: Qiang Yu
This reverts commit 4a66f3da99dcb4dcbd28544110636b50adfb0f0d.
This is due to the depend commit has been reverted on upstream:
baad10973fdb ("Revert "drm/scheduler: track GPU active time per entity"")
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_drv.c | 31
From: Qiang Yu
This reverts commit bccafec957a5c4b22ac29e53a39e82d0a0008348.
This is due to the depend commit has been reverted on upstream:
baad10973fdb ("Revert "drm/scheduler: track GPU active time per entity"")
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_ctx.c | 30
From: Qiang Yu
Upstream has reverted the dependant commit
df622729ddbf ("drm/scheduler: track GPU active time per entity""),
but this patchset has been pushed to drm-misc-next which still
has that commit. To avoid other branch build fail after merge
drm-misc-next, just revert the lima patchset
301 - 341 of 341 matches
Mail list logo
