On Thu, Dec 05, 2024 at 08:32:03PM -0800, Abhinav Kumar wrote:
> Add connector abstraction for the DP MST. Each MST encoder
> is connected through a DRM bridge to a MST connector and each
> MST connector has a DP panel abstraction attached to it.
Why do we need an extra DRM bridge? Can we merge it
On Thu, Dec 05, 2024 at 08:32:02PM -0800, Abhinav Kumar wrote:
> Add a new file dp_mst_drm to manage the DP MST bridge operations
> similar to the dp_drm file which manages the SST bridge operations.
> Each MST encoder creates one bridge and each bridge is bound to its
> own dp_panel abstraction to
On Thu, Dec 05, 2024 at 08:32:04PM -0800, Abhinav Kumar wrote:
> Add irq hpd callback for the dp mst module which shall be
> invoked from the dp_display's irq hpd handler to perform
> mst specific operations in case of irq hpd. In MST case, route
Nit: MST, IRQ, HPD
> the IRQ HPD messages to MST m
On Thu, Dec 05, 2024 at 08:32:09PM -0800, Abhinav Kumar wrote:
> Initiliaze a DPMST encoder for each MST capable DP controller
> and the number of encoders it supports depends on the number
> of streams it supports. Replace the opencoded instances of max_stream
> with the newly introduced API to c
On Thu, Dec 05, 2024 at 08:32:10PM -0800, Abhinav Kumar wrote:
> For each MST capable DP controller, initialize a dp_mst module to
> manage its DP MST operations. The DP MST module for each controller
> is the central entity to manage its topology related operations as
> well as interfacing with th
On Thu, Dec 05, 2024 at 08:31:47PM -0800, Abhinav Kumar wrote:
> p1 register block is needed for the second mst stream.
> Add support in the catalog to be able to program this block.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dp/dp_catalog.c | 29 +
>
On Thu, Dec 05, 2024 at 08:31:53PM -0800, Abhinav Kumar wrote:
> VC payload fill sequence is inserted by the DP controller in the
> absence of stream symbols that is before stream is disabled. Add
> support to send the VCPF sequence for msm dp controller.
>
> Signed-off-by: Abhinav Kumar
> ---
>
On Thu, Dec 05, 2024 at 08:31:52PM -0800, Abhinav Kumar wrote:
> For DP MST streams, the 64 MTP slots are time-shared between
> the streams. Add the support to calculate the rate governor,
> slots and reservation of the slots to the DP controller. Each
> DP MST stream shall reserve its streams by c
On Thu, Dec 05, 2024 at 08:31:51PM -0800, Abhinav Kumar wrote:
> DP stream is transmitted in transfer units only for SST
> case there is no need to calculate and program TU parameters
> for MST case. Skip the TU programming for MST cases.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/
On Thu, Dec 05, 2024 at 08:31:49PM -0800, Abhinav Kumar wrote:
> Whenever virtual channel slot allocation changes, the DP
> source must send the action control trigger sequence to notify
> the sink about the same. This would be applicable during the
> start and stop of the pixel stream. Add the inf
On Thu, Dec 05, 2024 at 08:31:48PM -0800, Abhinav Kumar wrote:
> Use the dp_panel's stream_id to adjust the offsets for stream 1
> which will be used for MST in the dp_catalog. Also add additional
> register defines for stream 1.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dp/dp
On Fri, Dec 06, 2024 at 12:00:53PM -0800, Abhinav Kumar wrote:
> On chipsets such as QCS615, there is no 3dmux present. In such
> a case, a layer exceeding the max_mixer_width cannot be split,
> hence cannot be supported.
>
> Filter out the modes which exceed the max_mixer_width when there
> is no
Hello,
syzbot found the following issue on:
HEAD commit:4a5df3796467 Merge tag 'mm-hotfixes-stable-2024-11-16-15-3..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=149b537858
kernel config: https://syzkaller.appspot.com/x/.config?x=4fca5d6b7cd3e6f
dash
On Sat, 7 Dec 2024 at 15:52, Martin Uecker wrote:
>
> Can you point me to some horror stories?
So the main issues tended to be about various static verification tools.
Ranging from things like the stackleak plugin for gcc, where handling
VLA's and alloca() (which are pretty much the same thing w
On Sat. 7 Dec. 2024 at 05:24, David Laight wrote:
> > > > #define const_NULL(x) _Generic(0 ? (x) : (char *)0, char *: 1, void *:
> > > > 0)
> > > > #define const_true(x) const_NULL((x) ? NULL : (void *)1L))
> > > > #define const_expr(x) const_NULL((x) ? NULL : NULL))
> > > > I send this morning.
Am Samstag, dem 07.12.2024 um 12:28 -0800 schrieb Linus Torvalds:
> On Sat, 7 Dec 2024 at 11:19, Martin Uecker wrote:
> >
> > But that all seem solvable issues on the compiler side.
>
[... Itanium, value range analysis, no assertions in kernel...]
> Now, would we want to have proper value *sta
Add driver for backlight controllers attached via Apple DWI 2-wire
interface, which is found on some Apple iPhones, iPads and iPod touches
with a LCD display.
Signed-off-by: Nick Chan
---
drivers/video/backlight/Kconfig | 12 +++
drivers/video/backlight/Makefile | 1 +
drivers/video/backligh
Add MAINTAINERS entries for the driver.
Signed-off-by: Nick Chan
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1e930c7a58b1..36de76bc6fd4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2204,6 +2204,7 @@ F:
Documentation/devicetree/b
On Thu. 5 Dec 2024 at 03:48, David Laight wrote:
> From: Vincent Mailhol
> > Sent: 02 December 2024 17:33
> >
> > __builtin_constant_p() is known for not always being able to produce
> > constant expression [1] which led to the introduction of
> > __is_constexpr() [2]. Because of its dependency on
On Fri. 6 Dec. 2024 at 15:40, Martin Uecker wrote:
> Am Freitag, dem 06.12.2024 um 02:25 + schrieb David Laight:
> > From: Vincent Mailhol
> > > Sent: 05 December 2024 15:31
> > >
> > > -CC: Martin Uecker
> > > +CC: Martin Uecker
> > > (seems that Martin changed his address)
>
> My current o
Add the device tree bindings for backlight controllers attached via Apple
DWI 2-wire interface.
Signed-off-by: Nick Chan
---
.../bindings/leds/backlight/apple,dwi-bl.yaml | 54 +++
1 file changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backli
On Sun. 8 Dec. 2024 at 00:10, Martin Uecker wrote:
> Am Samstag, dem 07.12.2024 um 22:50 +0900 schrieb Vincent Mailhol:
> > On Sat. 7 Dec. 2024 à 22:19, Martin Uecker wrote:
> > >
> ...
>
> >
> > I was invited to WG14 this September. For now, I am only lurking. The
> > thing I have in mind right
On Thu. 5 Dec. 2024 at 03:54, David Laight wrote:
> From: Vincent Mailhol
> > Sent: 02 December 2024 17:33
> >
> > In __clamp_once(),
> >
> > __builtin_choose_expr(__is_constexpr((lo) > (hi)), (lo) <= (hi), true)
> >
> > is equivalent to:
> >
> > !is_const_false((lo) <= (hi))
> >
> > Apply is_
On Thu. 5 Dec 2024 at 03:52, David Laight wrote:
> From: Vincent Mailhol
> > Sent: 02 December 2024 17:33
> >
> > __builtin_choose_expr(__is_constexpr((l) > (h)), (l) > (h), 0)
> >
> > is equivalent to:
> >
> > is_const_true((l) > (h))
>
> Change it to BUILD_BUG_ON_MSG(statically_true((l) < (h
On Fri, Dec 06, 2024 at 11:15:20AM -0800, Linus Torvalds wrote:
> On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
> >
> > I'm missing the compiler version and options to generate the error.
>
> Just -Wall with most recent gcc versions seems to do it. At least I
> can repro it with gcc-14.2.1 and
-CC: Martin Uecker
+CC: Martin Uecker
(seems that Martin changed his address)
On Thu. 5 Dec. 2024 at 03:39, David Laight wrote:
> > Sent: 02 December 2024 17:33
> >
> > From: Vincent Mailhol
> >
> > __is_constexpr(), while being one of the most glorious one liner hack
> > ever witnessed by man
On Sat. 7 Dec. 2024 at 20:19, David Laight wrote:
> From: Vincent Mailhol
> > Sent: 07 December 2024 07:43
> ...
> > > So maybe the slightly long lines:
> > > #define const_true(x) _Generic(0 ? (void *)((x) + 0 ? 0L : 1L) : (char
> > > *)0, char *: 1, void *: 0)
> > > #define const_expr(x) _Gener
On Sat. 7 Dec. 2024 at 17:39, Martin Uecker wrote:
> Am Freitag, dem 06.12.2024 um 16:26 +0900 schrieb Vincent Mailhol:
> > > On Fri. 6 Dec. 2024 at 15:40, Martin Uecker wrote:
> > > > > Am Freitag, dem 06.12.2024 um 02:25 + schrieb David Laight:
> > > > > > > From: Vincent Mailhol
> > > > >
On Sat. 7 Dec. 2024 à 22:19, Martin Uecker wrote:
> Am Samstag, dem 07.12.2024 um 21:45 +0900 schrieb Vincent Mailhol:
> > On Sat. 7 Dec. 2024 at 17:39, Martin Uecker wrote:
> > > Am Freitag, dem 06.12.2024 um 16:26 +0900 schrieb Vincent Mailhol:
>
> ...
>
> > > I find it amazing how much time th
Apple SoCs come with a 2-wire interface named DWI. On some iPhones, iPads
and iPod touches the backlight controller is connected via this interface.
This series adds a backlight driver for backlight controllers connected
this way.
Changes since v1:
- Fixed dt-bindings $id.
- Make power-domains an
On Mon, Dec 2, 2024 at 12:18 PM Thomas Zimmermann wrote:
> Thanks for testing. Attached is another patch. It attempts to restore
> the fbdev handling as before the regression. Please give it a try.
This one fixes it for me. Thanks
From: Martin Uecker
> Sent: 07 December 2024 21:06
>
> Am Samstag, dem 07.12.2024 um 21:00 + schrieb David Laight:
> > From: Martin Uecker
> > > Sent: 07 December 2024 19:52
> ...
>
> >
> > > There exist proposals along those lines for C2Y.
> > >
> > > From a more near-term solution, I wonder
s(-)
---
base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37
change-id: 20241207-rk3588-hdmi1-704cbb7cd75f
Add support for the second HDMI TX port found on RK3588 SoC.
Signed-off-by: Cristian Ciocaltea
---
arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
b/arch/arm64/boot/dts/
In preparation to enable the second HDMI output port found on RK3588
SoC, add the related PHY node. This requires a GRF, hence add the
dependent node as well.
Signed-off-by: Cristian Ciocaltea
---
arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi | 21 +
1 file changed, 21 inse
Add the necessary DT changes to enable the second HDMI output port on
Radxa ROCK 5B.
While at it, switch the position of &vop_mmu and @vop to maintain the
alphabetical order.
Signed-off-by: Cristian Ciocaltea
---
arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 42 +++--
1
Provide the basic support required to enable the second HDMI TX port
found on RK3588 SoC.
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 119 -
1 file changed, 96 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/rockchip
Am Samstag, dem 07.12.2024 um 21:00 + schrieb David Laight:
> From: Martin Uecker
> > Sent: 07 December 2024 19:52
...
>
> > There exist proposals along those lines for C2Y.
> >
> > From a more near-term solution, I wonder if making it possible (or
> > easier) to return integer constant expr
From: Martin Uecker
> Sent: 07 December 2024 19:52
...
> > Of course, often the compiler *does* have helper builtins, but we
> > can't use them, because they aren't *quite* the right thing. Like that
> > "__builtin_constant_p()" not actually working for some situations
> > where we absolutely need
From: Linus Torvalds
> Sent: 07 December 2024 20:31
...
> We're currently still accepting gcc-5.1 as a compiler, although it's
> time to look at that and probably (judging by what stable distros use)
> upgrade to something like gcc-8.1 as the minimum supported compiler
> version.
That's going to a
On Sat, 7 Dec 2024 at 11:19, Martin Uecker wrote:
>
> But that all seem solvable issues on the compiler side.
You know, there was a whole *architecture* that was designed and
predicated on "it's all solvable on the compiler side".
That architecture was pure and utter *shit*.
Because no, it's no
On Sat, 7 Dec 2024 at 11:51, Martin Uecker wrote:
>
> Am Samstag, dem 07.12.2024 um 10:19 -0800 schrieb Linus Torvalds:
> >
> > If there is one feature of C I would have liked it is "allow inline
> > functions and statement expressions with constant arguments as
> > constant expressions".
>
> Ther
Am Samstag, dem 07.12.2024 um 10:19 -0800 schrieb Linus Torvalds:
> On Sat, 7 Dec 2024 at 04:24, Vincent Mailhol
> wrote:
> >
> > > No good - expands everything twice.
> >
> > And? __is_const_zero() does not evaluate its arguments, so no side effect:
>
> No, the problem is literally the expans
Am Samstag, dem 07.12.2024 um 10:26 -0800 schrieb Linus Torvalds:
> On Sat, 7 Dec 2024 at 05:07, Martin Uecker wrote:
> >
> > VLA use *less* stack than a fixed size arrays with fixed bound.
>
> Not really. You end up with tons of problems, not the least of which
> is how to actually analyze the
On Sat, 7 Dec 2024 at 05:07, Martin Uecker wrote:
>
> VLA use *less* stack than a fixed size arrays with fixed bound.
Not really. You end up with tons of problems, not the least of which
is how to actually analyze the stack size. It also gets *very* nasty
to have code that declares the VLA size u
On Sat, 7 Dec 2024 at 04:24, Vincent Mailhol wrote:
>
> > No good - expands everything twice.
>
> And? __is_const_zero() does not evaluate its arguments, so no side effect:
No, the problem is literally the expansion.
Double expansion of these fundamental helpers gets exponential,
because they ar
From: Vincent Mailhol
> Sent: 07 December 2024 13:51
...
> > > It seems to me that the long term solution to this problem are the
> > > constexpr functions.
> >
> > How would constexpr functions help here? (I am a bit sceptical about
> > constexpr functions.)
>
> I was thinking of some of the "si
From: Rob Clark
Add a SET_PARAM for userspace to request to manage to the VM itself,
instead of getting a kernel managed VM.
In order to transition to a userspace managed VM, this param must be set
before any mappings are created.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_g
From: Rob Clark
We'll re-use this in the vm_bind path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 12 ++--
drivers/gpu/drm/msm/msm_gem.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem
From: Rob Clark
If userspace has opted-in to VM_BIND, then GPU faults and VM_BIND errors
will mark the VM as unusable.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h| 17 +
drivers/gpu/drm/msm/msm_gem_submit.c | 3 +++
drivers/gpu/drm/msm/msm_gpu.c|
From: Rob Clark
Add PRR (Partial Resident Region) is a bypass address which make GPU
writes go to /dev/null and reads return zero. This is used to implement
vulkan sparse residency.
To support PRR/NULL mappings, we allocate a page to reserve a physical
address which we know will not be used as
From: Rob Clark
This fits better drm_gpuvm/drm_gpuva.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 16 +++-
drivers/gpu/drm/msm/msm_gem_vma.c | 2 ++
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm
From: Rob Clark
Bump version to signal to userspace that VM_BIND is supported.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index b31ec287c600..dc00
From: Rob Clark
Hook up the map/remap/unmap ops to apply MAP/UNMAP operations. The
MAP/UNMAP operations are split up by drm_gpuvm into a series of map/
remap/unmap ops, for example an UNMAP operation which spans multiple
vmas will get split up into a sequence of unmap (and possibly remap)
ops wh
From: Rob Clark
Buffers that are not shared between contexts can share a single resv
object. This way drm_gpuvm will not track them as external objects, and
submit-time validating overhead will be O(1) for all N non-shared BOs,
instead of O(n).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm
From: Rob Clark
This is a more descriptive name.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
drivers/gpu/drm/msm/msm_gem.h | 2 +-
drivers/gpu/drm/msm/msm_gem_vma.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_g
From: Rob Clark
Only needs to be supported for iopgtables mmu, the other cases are
either only used for kernel managed mappings (where offset is always
zero) or devices which do not support sparse bindings.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpummu.c | 5 -
drive
From: Rob Clark
This is a bit different than the path taken by other clean-slate
drivers. But there is a lot in similar with BO pinning in the legacy
"EXEC" path and "VM_BIND" MAP path. Also, we want the same fence and
syncobj handling.
(Why bother with fence fd's? Because for virtgpu nctx fo
From: Rob Clark
This submitqueue type isn't tied to a hw ringbuffer, but instead
executes on the CPU for performing async VM_BIND ops.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 3 +-
drivers/gpu/drm/msm/msm_gem.h | 10 +++
drivers/gpu/drm/msm/msm_gem_submi
From: Rob Clark
For VM_BIND, in the first step, we just want to get the backing pages,
but defer creating the vma until the map/unmap/ops are evaluated.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 27 +++
1 file changed, 19 insertions(+), 8 delet
From: Rob Clark
In the next commit, a way for userspace to opt-in to userspace managed
VM is added. For this to work, we need to defer creation of the VM
until it is needed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 ++-
drivers/gpu/drm/msm/adreno/adreno_gpu.c
From: Rob Clark
Most of the driver code doesn't need to reach in to msm specific fields,
so just use the drm_gpuvm/drm_gpuva types directly. This should
hopefully improve commonality with other drivers and make the code
easier to understand.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/ad
From: Rob Clark
It is standing in the way of drm_gpuvm / VM_BIND support. Not to
mention frequently broken and rarely tested. And I think only needed
for a 10yr old not quite upstream SoC (msm8974).
Maybe we can add support back in later, but I'm doubtful.
Signed-off-by: Rob Clark
---
drive
From: Rob Clark
The WIP VM_BIND patches don't yet support shrinker..
Not-signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 2aefb8becda0..6bc6f67825ce
From: Rob Clark
Now that we've realigned deletion and allocation, switch over to using
drm_gpuvm/drm_gpuva. This allows us to support multiple VMAs per BO per
VM, to allow mapping different parts of a single BO at different virtual
addresses, which is a key requirement for sparse/VM_BIND.
This
From: Rob Clark
Now that we've dropped vram carveout support, we can collapse vma
allocation and initialization. This better matches how things work
with drm_gpuvm.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 30 +++---
drivers/gpu/drm/msm/msm_gem.h
From: Rob Clark
Re-aligning naming to better match drm_gpuvm terminology will make
things less confusing at the end of the drm_gpuvm conversion.
This is just rename churn, no functional change.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 18 ++--
drivers/gpu/d
From: Rob Clark
See commit a414fe3a2129 ("drm/msm/gem: Drop obj lock in
msm_gem_free_object()") for justification.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gpuvm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/d
From: Rob Clark
Conversion to DRM GPU VA Manager[1], and adding support for Vulkan Sparse
Memory[2] in the form of:
1. A new VM_BIND submitqueue type for executing VM MSM_SUBMIT_BO_OP_MAP/
MAP_NULL/UNMAP commands
2. Extending the SUBMIT` ioctl to allow submitting batches of one or more
MAP/
From: Rob Clark
This is a more descriptive name.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 ++--
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 4 +--
drivers/gpu/drm/msm/msm_drv.c | 14 -
drivers/gp
From: Rob Clark
Just some tidying up.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.h | 44 +++
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 76ad75f06706..01a3b2770
From: Rob Clark
If the driver is using an external mutex to synchronize vm access, it
doesn't need to hold vm->r_obj->resv. And if the driver is already
holding obj->resv, then needing to pointlessly grab vm->r_obj->resv will
be seen by lockdep as nested locking.
Signed-off-by: Rob Clark
---
Am Samstag, dem 07.12.2024 um 22:50 +0900 schrieb Vincent Mailhol:
> On Sat. 7 Dec. 2024 à 22:19, Martin Uecker wrote:
> >
...
>
> I was invited to WG14 this September. For now, I am only lurking. The
> thing I have in mind right now is to write a paper to allow the use of
> static_assert() in
Am Samstag, dem 07.12.2024 um 22:50 +0900 schrieb Vincent Mailhol:
> On Sat. 7 Dec. 2024 à 22:19, Martin Uecker wrote:
> > Am Samstag, dem 07.12.2024 um 21:45 +0900 schrieb Vincent Mailhol:
> > > On Sat. 7 Dec. 2024 at 17:39, Martin Uecker wrote:
> > > > Am Freitag, dem 06.12.2024 um 16:26 +0900
Am Samstag, dem 07.12.2024 um 21:45 +0900 schrieb Vincent Mailhol:
> On Sat. 7 Dec. 2024 at 17:39, Martin Uecker wrote:
> > Am Freitag, dem 06.12.2024 um 16:26 +0900 schrieb Vincent Mailhol:
...
> > I find it amazing how much time the Linux kernel community spends
> > revising code to make it wo
Am Samstag, dem 07.12.2024 um 10:33 + schrieb David Laight:
> From: Martin Uecker
> > Sent: 07 December 2024 08:40
> ...
> > I find it amazing how much time the Linux kernel community spends
> > revising code to make it work perfectly.
> >
> > Still, I am wondering whether some of this time an
On 12/4/24 11:55 AM, Nikolaus Voss wrote:
Hi Marek,
Hi,
I doubt that pixel clock tree cannot find appropriate division
ratios
for some pixel clock rates, especially for dual-link LVDS on i.MX8MP
and i.MX93 platforms, because PLL clock rate should be 7x faster
than
pixel clock rate and 2x f
On 12/4/24 11:40 AM, Nikolaus Voss wrote:
Hi,
LDB clock has to be a fixed multiple of the pixel clock.
As LDB and pixel clock are derived from different clock sources
Can you please share the content of /sys/kernel/debug/clk/clk_summary ?
Sure. Without my patch:
video_pll1_ref_sel
On 6 December 2024 12:33:38 EET, "Murthy, Arun R"
wrote:
>> On Thu, Dec 05, 2024 at 04:29:55PM +, Murthy, Arun R wrote:
>> > > > > -Original Message-
>> > > > > From: Dmitry Baryshkov
>> > > > > Sent: Wednesday, December 4, 2024 5:17 PM
>> > > > > To: Murthy, Arun R
>> > > > > Cc: i
From: Vincent Mailhol
> Sent: 07 December 2024 07:43
...
> > So maybe the slightly long lines:
> > #define const_true(x) _Generic(0 ? (void *)((x) + 0 ? 0L : 1L) : (char *)0,
> > char *: 1, void *: 0)
> > #define const_expr(x) _Generic(0 ? (void *)((x) + 0 ? 0L : 0L) : (char *)0,
> > char *: 1, v
As vram objects may be imported by other gpu drivers, peer2peer flag
should be checked in dma_buf_ops->attach(). This reimplement virtio gpu
dma_buf_ops->attach by adding a device_attach() function for virtio gpu.
This function will get pci_p2pdma_distance and check attach->peer2peer
before calling
virtgpu driver need to get the p2pdma_distance to decide if virtio
iGPU buffer can be imported by passthrough dGPU, which is the main
step implement dGPU prime feature.
To get the p2pdma_distance, this create a new virtgpu ioctl to send
command of getting p2pdma_distance and pci notations of two p
To get the p2pdma_distance, this create a new privcmd ioctl to calculate
p2pdma_distance for two pci devices on the host with pci notations sent
from guest virtgpu driver.
Signed-off-by: Julia Zhang
---
drivers/xen/privcmd.c | 42 ++
include/uapi/xen/priv
To implement dGPU prime feature, virtgpu needs to import/export buffer
between virtio iGPU and passthrough dGPU. Before that, virtgpu should
check if P2P is possible or not. But calling function pci_p2pdma_distance
in guest VM will only get virtual p2pdma_distance instead of real physical
p2pdma_di
From: Martin Uecker
> Sent: 07 December 2024 08:40
...
> I find it amazing how much time the Linux kernel community spends
> revising code to make it work perfectly.
>
> Still, I am wondering whether some of this time and effort should not
> be targeted at C compilers and language work to make the
Am Freitag, dem 06.12.2024 um 16:26 +0900 schrieb Vincent Mailhol:
> > On Fri. 6 Dec. 2024 at 15:40, Martin Uecker wrote:
> > > > Am Freitag, dem 06.12.2024 um 02:25 + schrieb David Laight:
> > > > > > From: Vincent Mailhol
> > > > > > > > Sent: 05 December 2024 15:31
> > > > > > > >
> > > >
86 matches
Mail list logo
