Hi Mario,
kernel test robot noticed the following build errors:
[auto build test ERROR on rafael-pm/linux-next]
[also build test ERROR on rafael-pm/acpi-bus linus/master v6.8-rc2
next-20240131]
[cannot apply to drm-misc/drm-misc-next rafael-pm/devprop]
[If your patch is applied to the wrong git
* Michael Walle [231204 09:52]:
> >> @@ -643,6 +658,7 @@ static int tc_probe(struct i2c_client *client)
> >>
> >> tc->dev = dev;
> >> tc->i2c = client;
> >> + tc->type = (enum tc3587x5_type)of_device_get_match_data(dev);
> >
> > Would it make sense to use i2c_get_match_data()
* Michael Walle [231207 16:14]:
> > The hs_rate and lp_rate may be used by the dsi host for timing
> > calculations. The tc358775 has a maximum bit rate of 1 Gbps/lane,
> > tc358765 has maximurate of 800 Mbps per lane.
> >
> > Signed-off-by: Tony Lindgren
> > ---
> > drivers/gpu/drm/bridge/tc35
Convert device tree bindings for Atmel's HLCDC PWM controller to YAML
format.
Signed-off-by: Dharma Balasubiramani
Reviewed-by: Conor Dooley
---
Changelog
v4 -> v5
v3 -> v4
- No changes
Note: The clean up patch will be sent later as Sam suggested.
v2 -> v3
- Remove '|' in description, as there i
Convert the existing DT binding to DT schema of the Atmel's HLCDC display
controller.
Signed-off-by: Dharma Balasubiramani
---
Changelog
v4 -> v5
- No change.
v3 -> v4
- Add bus-width property to have one complete example.
v2 -> v3
- Remove '|' in description, as there is no formatting to preserv
Convert the atmel,hlcdc binding to DT schema format.
Align clocks and clock-names properties to clearly indicate that the LCD
controller expects lvds_pll_clk when interfaced with the lvds display. This
alignment with the specific hardware requirements ensures accurate device tree
configuration for
Converted the text bindings to YAML and validated them individually using
following commands
$ make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/
$ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/
changelogs are available in respective patches.
As Sam sug
Add Matthew Brost to DRM scheduler maintainers.
Cc: Luben Tuikov
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Christian König
Signed-off-by: Matthew Brost
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5c00fad59e91..e968d68a96c8 100644
--- a/MAIN
On Tue, Jan 30, 2024 at 11:00 AM Vinod Koul wrote:
>
> Hi Adam,
>
> On 06-01-24, 16:19, Adam Ford wrote:
> > From: Lucas Stach
> >
> > This adds the driver for the Samsung HDMI PHY found on the
> > i.MX8MP SoC.
> >
> > Signed-off-by: Lucas Stach
> > Signed-off-by: Adam Ford
> > ---
> > V2: Fix
On Tue, Jan 30, 2024 at 6:50 PM Daniel Stone wrote:
>
> Hi,
>
> On Tue, 30 Jan 2024 at 18:39, Zack Rusin wrote:
> > In general, yes. Of course it's a little more convoluted because we'll
> > act like OpenGL runtime here (i.e. glXSwapBuffers), i.e. our driver
> > will fake page-flips because the o
From: Rob Clark
Since commit 56e5abba8c3e ("dma-buf: Add unlocked variant of vmapping
functions"), the resv lock is already held in the prime vmap path, so
don't try to grab it again.
v2: This applies to vunmap path as well
Fixes: 56e5abba8c3e ("dma-buf: Add unlocked variant of vmapping functio
Hi,
On Tue, 30 Jan 2024 at 18:39, Zack Rusin wrote:
> In general, yes. Of course it's a little more convoluted because we'll
> act like OpenGL runtime here (i.e. glXSwapBuffers), i.e. our driver
> will fake page-flips because the only memory we'll have is a single
> buffer as the actual page-flip
On Wed, Jan 31, 2024 at 8:29 AM Zeng, Oak wrote:
>
> Hi Christian,
>
>
>
> Nvidia Nouveau driver uses exactly the same concept of SVM with HMM, GPU
> address in the same process is exactly the same with CPU virtual address. It
> is already in upstream Linux kernel. We Intel just follow the same
On Mon, Jan 22, 2024 at 06:50:00PM +0200, Ville Syrjälä wrote:
On Mon, Jan 22, 2024 at 10:08:05AM -0500, Sasha Levin wrote:
From: Ville Syrjälä
[ Upstream commit c6fbb6bca10838485b820e8a26c23996f77ce580 ]
Why is this being backported?
Is this not a fix for an issue?
--
Thanks,
Sasha
From: Rob Clark
Since commit 56e5abba8c3e ("dma-buf: Add unlocked variant of vmapping
functions"), the resv lock is already held in the prime vmap path, so
don't try to grab it again.
Fixes: 56e5abba8c3e ("dma-buf: Add unlocked variant of vmapping functions")
Signed-off-by: Rob Clark
---
drive
Hi Christian,
Nvidia Nouveau driver uses exactly the same concept of SVM with HMM, GPU
address in the same process is exactly the same with CPU virtual address. It is
already in upstream Linux kernel. We Intel just follow the same direction for
our customers. Why we are not allowed?
From: Chri
On 30/01/2024 16:15, Jason Gunthorpe wrote:
This was added in commit c95469aa5a18 ("gpu: host1x: Set DMA ops on device
creation") with the note:
Currently host1x-instanciated devices have their dma_ops left to NULL,
which makes any DMA operation (like buffer import) on ARM64 fallback
Hi Matthew,
On 12/21/2023 12:51 AM, Matthew Auld wrote:
Hi,
On 14/12/2023 13:42, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks
Daniel Vetter writes:
> I had no idea this exists, but Randy pointed out it's been added quite
> a long time ago in cbb4d3e6510b ("scripts/kernel-doc: handle
> object-like macros"). Definitely way before I started to write all the
> drm docs sadly, so there's a few things where I skipped writing
Anna-Maria Behnsen writes:
> Hi,
>
> this is a repost of the RFC queue
> https://lkml.kernel.org/r/20240116151456.48238-1-anna-ma...@linutronix.de
>
> Jonathan Corbet is fine with this change and mentioned in an answer the
> following:
>
> "The kernel-doc change should really go together with t
On Mon, 22 Jan 2024 14:49:58 -0600, Rob Herring wrote:
> The constraints for 'audio-ports' don't match the description. There can
> be 1 or 2 DAI entries and each entry is exactly 2 values. Also, the
> values' sizes are 32-bits, not 8-bits. Move the size constraints to the
> outer dimension (numb
On Mon, Jan 22, 2024 at 05:30:44PM +0100, Boris Brezillon wrote:
> From: Liviu Dudau
>
> Arm has introduced a new v10 GPU architecture that replaces the Job Manager
> interface with a new Command Stream Frontend. It adds firmware driven
> command stream queues that can be used by kernel and user
Add a function to support defragmentation.
v5: Defragment the freelist order array beginning
from min_order.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Matthew Auld
---
drivers/gpu/drm/drm_buddy.c | 70 ++---
1 file changed, 58 insertions(+), 12 d
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared
Add clear page support in vram memory region.
v1:(Christian)
- Dont handle clear page as TTM flag since when moving the BO back
in from GTT again we don't need that.
- Make a specialized version of amdgpu_fill_buffer() which only
clears the VRAM areas which are not already cleared
-
Hi,
On 1/30/24 20:08, Werner Sembach wrote:
> Hi,
>
> Am 30.01.24 um 19:35 schrieb Hans de Goede:
>> Hi,
>>
>> On 1/30/24 19:09, Werner Sembach wrote:
>>> Hi Hans,
>>>
>>> resend because Thunderbird htmlified the mail :/
>> I use thunderbird too. If you right click on the server name
>> and then
On Fri, Jan 12, 2024 at 4:20 PM Ian Forbes wrote:
>
> SVGA requires surfaces to fit within graphics memory (max_mob_pages) which
> means that modes with a final buffer size that would exceed graphics memory
> must be pruned otherwise creation will fail.
>
> Additionally, device commands which use
Hi Dang,
On Sat, Jan 27, 2024 at 06:35:50PM +0700, Dang Huynh wrote:
> Hi Manuel,
>
> Since the BOE patches have been accepted to next, you do not need to include
> it in this patch series.
sorry, I thought patches to LKML shall be against Linux master since the
patches are still only in drm-ne
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops.
Attempt to fetch this EDID if it exists and prefer it over the EDID
that is provided by the panel.
Signed-off-by: Mario Limonciello
---
v2:
* Use drm helper which will run more validat
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers can call this
helper to attempt to fetch the EDID from the BIOS's ACPI _DDC method.
Signed-off-by: Mario Limonciello
---
v1->v2:
* Split code from previous amdgpu specific help
Rather than inventing a wrapper to acpi_video_get_edid() use the
one provided by drm. This fixes two problems:
1. A memory leak that the memory provided by the ACPI call was
never freed.
2. Validation of the BIOS provided blob.
Signed-off-by: Mario Limonciello
---
v1->v2:
* New patch
---
dri
The ACPI specification allows for an EDID to be up to 512 bytes but
the _DDC EDID fetching code will only try up to 256 bytes.
Modify the code to instead start at 512 bytes and work it's way
down instead.
As _DDC is now called up to 4 times on a machine debugging messages
are noisier than necessa
Some laptops ship an EDID in the BIOS encoded in the _DDC method that
differs than the EDID directly on the laptop panel for $REASONS.
This is the EDID that is used by the AMD Windows driver, and so sometimes
different results are found in different operating systems.
This series adds a new DRM h
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Qiang
> Ma
> Sent: Tuesday, January 30, 2024 4:35 AM
> To: lexander.deuc...@amd.com; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; sunran...@208suo.com;
> SHANMUGAM, SRINIVASAN
> Cc: Qiang Ma ; dri-dev
On Tue, Jan 23, 2024 at 03:39:13AM +, dharm...@microchip.com wrote:
> Hi Conor,
>
> On 22/01/24 10:07 pm, Conor Dooley wrote:
> > On Mon, Jan 22, 2024 at 04:51:16PM +0100, Krzysztof Kozlowski wrote:
> >> On 22/01/2024 09:29, Dharma Balasubiramani wrote:
> >>> Add the 'sam9x7-lvds' compatible b
Hi,
Am 30.01.24 um 19:35 schrieb Hans de Goede:
Hi,
On 1/30/24 19:09, Werner Sembach wrote:
Hi Hans,
resend because Thunderbird htmlified the mail :/
I use thunderbird too. If you right click on the server name
and then go to "Settings" -> "Composition & Addressing"
and then uncheck "Compose
On Fri, Jan 19, 2024 at 4:22 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 18.01.24 um 19:25 schrieb Zack Rusin:
> > On Mon, Jan 15, 2024 at 3:21 AM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> Am 12.01.24 um 21:38 schrieb Ian Forbes:
> >>> SVGA requires surfaces to fit within graphics memory
Hi,
On 1/30/24 19:09, Werner Sembach wrote:
> Hi Hans,
>
> resend because Thunderbird htmlified the mail :/
I use thunderbird too. If you right click on the server name
and then go to "Settings" -> "Composition & Addressing"
and then uncheck "Compose messages in HTML format"
I think that should
On Tue, Jan 30, 2024 at 03:55:43PM +0100, Johan Jonker wrote:
> The hdmi-connector nodes are now functional and the new way to model
> hdmi nodes with, so deprecate the port property and
This doesn't really explain what makes having hdmi-connector nodes
replace the usecase for "port".
> make port
Hi Hans,
resend because Thunderbird htmlified the mail :/
Am 30.01.24 um 18:10 schrieb Hans de Goede:
Hi Werner,
On 1/30/24 12:12, Werner Sembach wrote:
Hi Hans,
Am 29.01.24 um 14:24 schrieb Hans de Goede:
I think that are mostly external keyboards, so in theory a possible cut could
also
On Tue, Jan 30, 2024 at 03:57:23PM +0100, Johan Jonker wrote:
> Most Rockchip hdmi nodes are part of a power domain.
> Add a power-domains property.
Acked-by: Conor Dooley
> Fix example.
Just a note, in the future please explain why simply reordering the
properties constitutes "fixing" the exam
Hi Hans,
Am 30.01.24 um 18:10 schrieb Hans de Goede:
Hi Werner,
On 1/30/24 12:12, Werner Sembach wrote:
Hi Hans,
Am 29.01.24 um 14:24 schrieb Hans de Goede:
I think that are mostly external keyboards, so in theory a possible cut could
also between built-in and external devices.
IMHO it w
On 30/01/2024 16:12, Alex Deucher wrote:
Switch to using the new gem shared memory stats helper
rather than hand rolling it.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/i915/i915_drm_client.c | 2 +-
On 30/01/2024 16:12, Alex Deucher wrote:
Show buffers as shared if they are shared via dma-buf as well
(e.g., shared with v4l or some other subsystem).
v2: switch to gem helper
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Reviewed-by: Rob Clark (v1)
On 30/01/2024 16:12, Alex Deucher wrote:
Add a helper so that drm drivers can consistently report
shared status via the fdinfo shared memory stats interface.
In addition to handle count, show buffers as shared if they
are shared via dma-buf as well (e.g., shared with v4l or some
other subsyste
On 30/01/2024 16:12, Alex Deucher wrote:
Clarify the documentaiton in preparation for updated
helpers which check the handle count as well as whether
a dma-buf has been attached.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
Hi Vinod,
Le mardi 30 janvier 2024 à 21:38 +0530, Vinod Koul a écrit :
> On 29-01-24, 18:01, Paul Cercueil wrote:
> > This function can be used to initiate a scatter-gather DMA
> > transfer,
> > where the address and size of each segment is located in one entry
> > of
> > the dma_vec array.
> >
>
On 1/30/24 11:12, Alex Deucher wrote:
Add a helper so that drm drivers can consistently report
shared status via the fdinfo shared memory stats interface.
In addition to handle count, show buffers as shared if they
are shared via dma-buf as well (e.g., shared with v4l or some
other subsystem).
Hi Werner,
On 1/30/24 12:12, Werner Sembach wrote:
> Hi Hans,
>
> Am 29.01.24 um 14:24 schrieb Hans de Goede:
>> That sounds workable OTOH combined with your remarks about also supporting
>> lightbars. I'm starting to think that we need to just punt this to userspace.
>>
>> So basically change
This was added in commit c95469aa5a18 ("gpu: host1x: Set DMA ops on device
creation") with the note:
Currently host1x-instanciated devices have their dma_ops left to NULL,
which makes any DMA operation (like buffer import) on ARM64 fallback
to the dummy_dma_ops and fail with an error.
Previously with tegra-smmu, even with CONFIG_IOMMU_DMA, the default domain
could have been left as NULL. The NULL domain is specially recognized by
host1x_client_iommu_attach() as meaning it is not the DMA domain and
should be replaced with the special shared domain.
This happened prior to the bel
On 29-01-24, 18:01, Paul Cercueil wrote:
> This function can be used to initiate a scatter-gather DMA transfer,
> where the address and size of each segment is located in one entry of
> the dma_vec array.
>
> The major difference with dmaengine_prep_slave_sg() is that it supports
> specifying the
Switch to using the new gem shared memory stats helper
rather than hand rolling it.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/xe/xe_drm_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Switch to using the new gem shared memory stats helper
rather than hand rolling it.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/i915/i915_drm_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Add a helper so that drm drivers can consistently report
shared status via the fdinfo shared memory stats interface.
In addition to handle count, show buffers as shared if they
are shared via dma-buf as well (e.g., shared with v4l or some
other subsystem).
Link:
https://lore.kernel.org/all/20231
Clarify the documentaiton in preparation for updated
helpers which check the handle count as well as whether
a dma-buf has been attached.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
---
Documentation/gpu/drm-usage-stats.rst |
Show buffers as shared if they are shared via dma-buf as well
(e.g., shared with v4l or some other subsystem).
v2: switch to gem helper
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Reviewed-by: Rob Clark (v1)
Signed-off-by: Alex Deucher
Cc: Rob Clark
--
Add shared stats. Useful for seeing shared memory.
v2: take dma-buf into account as well
v3: use the new gem helper
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
Cc: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |
We had a request to add shared buffer stats to fdinfo for amdgpu and
while implementing that, Christian mentioned that just looking at
the GEM handle count doesn't take into account buffers shared with other
subsystems like V4L or RDMA. Those subsystems don't use GEM, so it
doesn't really matter f
Hi Adam,
On 06-01-24, 16:19, Adam Ford wrote:
> From: Lucas Stach
>
> This adds the driver for the Samsung HDMI PHY found on the
> i.MX8MP SoC.
>
> Signed-off-by: Lucas Stach
> Signed-off-by: Adam Ford
> ---
> V2: Fixed some whitespace found from checkpatch
> Change error handling when
On Tue, Jan 30, 2024 at 06:42:04AM +, dharm...@microchip.com wrote:
> Hi Conor,
>
> On 24/01/24 10:10 pm, Conor Dooley wrote:
> > On Wed, Jan 24, 2024 at 03:30:16PM +0530, Dharma Balasubiramani wrote:
> >> Converted the text bindings to YAML and validated them individually using
> >> followin
On Sat, Jan 27, 2024 at 04:28:08PM +0100, Dario Binacchi wrote:
> Allow 'port' property (coming from panel-common.yaml) to be used in DTS:
>
> st/stm32f769-disco-mb1166-reva09.dtb: panel@0: 'port' does not match any of
> the regexes: 'pinctrl-[0-9]+'
>
> Signed-off-by: Dario Binacchi
> Cc: Al
Uprev IGT and add amd, v3d, vc4 and vgem specific
tests to testlist. Have testlist.txt per driver
and include a base testlist so that the driver
specific tests will run only on those hardware.
Signed-off-by: Vignesh Raman
---
v3:
- New patch in series to uprev IGT and update testlist.
---
dr
zlib.net is not allowing tarball download anymore and results
in below error in kernel+rootfs_arm32 container build,
urllib.error.HTTPError: HTTP Error 403: Forbidden
urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
Uprev mesa which includes a fix for this issue.
https://gitlab.freed
For rockchip rk3288 and rk3399, the display driver is rockchip.
Currently, in drm-ci for rockchip, only the display driver is
tested. So rename the rockchip job to indicate that display
driver is tested.
Rename the name of xfail files for rockchip (rk3288 and rk3399),
to include information about
For mediatek mt8173 and mt8183, the display driver is mediatek.
Currently, in drm-ci for mediatek, only the display driver is
tested. So rename the mediatek job to indicate that display driver is
tested. Rename the name of xfail files for mediatek (mt8173 and mt8183),
to include information about t
For rockchip rk3288 and rk3399, the GPU driver is panfrost.
So add support in drm-ci to test panfrost driver for rockchip
SOC and update xfails. Skip KMS tests for panfrost driver
since it is not a not a KMS driver.
Signed-off-by: Vignesh Raman
---
v2:
- Add panfrost GPU jobs for rockchip SOC
Enable CONFIG_DRM_ANALOGIX_ANX7625 in the arm64 defconfig to get
display driver probed on the mt8183-kukui-jacuzzi-juniper machine.
arch/arm64/configs/defconfig has CONFIG_DRM_ANALOGIX_ANX7625=m,
but drm-ci don't have initrd with modules, so add
CONFIG_DRM_ANALOGIX_ANX7625=y in CI arm64 config.
S
For amlogic meson SOC the GPU driver is panfrost. So add
support in drm-ci to test panfrost driver for amlogic meson
SOC and update xfails. Skip KMS tests for panfrost driver
since it is not a not a KMS driver.
Signed-off-by: Vignesh Raman
---
v2:
- Add panfrost GPU jobs for amlogic meson SOC
For Amlogic Meson SOC the display driver is meson. Currently,
in drm-ci for meson, only the display driver is tested.
So rename the meson job to indicate that display driver is tested.
Rename the name of xfail files for meson (g12b), to include
information about the tested driver and update xfails
For mediatek mt8173, the GPU driver is powervr and for mediatek
mt8183, the GPU driver is panfrost. So add support in drm-ci to
test panfrost and powervr GPU driver for mediatek SOCs and update
xfails. Powervr driver was merged in linux kernel, but there's no
mediatek support yet. So disable the mt
Some ARM SOCs have a separate display controller and GPU, each with
different drivers. For mediatek mt8173, the GPU driver is powervr,
and the display driver is mediatek. In the case of mediatek mt8183,
the GPU driver is panfrost, and the display driver is mediatek.
With rockchip rk3288/rk3399, the
Fix rk3399 hdmi ports node so that it matches the
rockchip,dw-hdmi.yaml binding.
Signed-off-by: Johan Jonker
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/
Fix rk3328 hdmi ports node so that it matches the
rockchip,dw-hdmi.yaml binding.
Signed-off-by: Johan Jonker
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot
Fix rk322x hdmi ports node so that it matches the
rockchip,dw-hdmi.yaml binding.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rockchip/rk322x.dtsi | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/rockchip/rk322x.dtsi
b/arch/arm/boot/
Fix rk3288 hdmi ports node so that it matches the
rockchip,dw-hdmi.yaml binding.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rockchip/rk3288.dtsi | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/rockchip/rk3288.dtsi
b/arch/arm/boot/
Most Rockchip hdmi nodes are part of a power domain.
Add a power-domains property. Fix example.
Signed-off-by: Johan Jonker
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings
The hdmi-connector nodes are now functional and the new way to model
hdmi nodes with, so deprecate the port property and make port@0 and
port@1 a requirement. Also update example.
Signed-off-by: Johan Jonker
---
.../display/rockchip/rockchip,dw-hdmi.yaml| 27 ---
1 file chang
Hi,
On 1/27/24 20:53, Gustavo A. R. Silva wrote:
On 1/27/24 09:11, David Laight wrote:
From: Linus Torvalds
Sent: 26 January 2024 22:36
On Fri, 26 Jan 2024 at 14:24, Kees Cook wrote:
I think xe has some other weird problems too. This may be related
(under
allocating):
../drivers/gpu/d
On 1/30/24 15:31, Christian König wrote:
Am 29.01.24 um 21:25 schrieb Thomas Hellström:
Hi,
On 1/29/24 17:48, Christian König wrote:
Am 27.01.24 um 16:53 schrieb Oak Zeng:
This fixes a build failure on drm-tip. This issue was introduced
during
merge of "drm/ttm: replace busy placement with
Am 29.01.24 um 21:25 schrieb Thomas Hellström:
Hi,
On 1/29/24 17:48, Christian König wrote:
Am 27.01.24 um 16:53 schrieb Oak Zeng:
This fixes a build failure on drm-tip. This issue was introduced during
merge of "drm/ttm: replace busy placement with flags v6". For some
reason, the xe_bo.c part
Am 30.01.24 um 12:16 schrieb Daniel Vetter:
On Tue, Jan 30, 2024 at 12:10:31PM +0100, Daniel Vetter wrote:
On Mon, Jan 29, 2024 at 06:31:19PM +0800, Julia Zhang wrote:
As vram objects don't have backing pages and thus can't implement
drm_gem_object_funcs.get_sg_table callback. This removes drm
Hi
Am 29.01.24 um 11:41 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
The plain values as stored in struct screen_info need to be decoded
before being used. Add helpers that decode the type of video output
and the framebuffer I/O aperture.
Old or non-x86 systems
Am 30.01.24 um 11:40 schrieb Daniel Vetter:
On Tue, Jan 30, 2024 at 10:48:23AM +0100, Paul Cercueil wrote:
Le mardi 30 janvier 2024 à 10:23 +0100, Christian König a écrit :
I would say we start with the DMA-API by getting away from sg_tables
to something cleaner and state oriented.
FYI I am
Hi
Am 29.01.24 um 12:36 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Test if the firmware framebuffer's parent PCI device, if any, has
been enabled. If not, the firmware framebuffer is most likely not
working. Hence, do not create a device for the firmware framebuffer
on disabl
Add documentation for the three ioctls used to attach or detach
externally-created DMABUFs, and to request transfers from/to previously
attached DMABUFs.
Signed-off-by: Paul Cercueil
---
v3: New patch
---
Documentation/usb/functionfs.rst | 36
1 file changed, 36
This patch introduces three new ioctls. They all should be called on a
data endpoint (ie. not ep0). They are:
- FUNCTIONFS_DMABUF_ATTACH, which takes the file descriptor of a DMABUF
object to attach to the endpoint.
- FUNCTIONFS_DMABUF_DETACH, which takes the file descriptor of the
DMABUF to
This exact same code was duplicated in two different places.
Signed-off-by: Paul Cercueil
---
drivers/usb/gadget/function/f_fs.c | 48 +-
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/
Add a new 'sg_was_mapped' field to the struct usb_request. This field
can be used to indicate that the scatterlist associated to the USB
transfer has already been mapped into the DMA space, and it does not
have to be done internally.
Signed-off-by: Paul Cercueil
---
drivers/usb/gadget/udc/core.c
Hi,
This is the v6 of my patchset that adds a new DMABUF import interface to
FunctionFS.
Given that the cache coherency issue that has been discussed after my
v5 is a tangential problem and not directly related to this new
interface, I decided to drop the dma_buf_begin/end_access() functions
for
Hi Maintainers,
There are some flaky tests reported for amdgpu driver testing in drm-ci.
# Board Name: hp-11A-G6-EE-grunt
# IGT Version: 1.28-gb0cc8160e
# Linux Version: 6.7.0-rc3
Pipeline url:
https://gitlab.freedesktop.org/vigneshraman/linux/-/jobs/54373774
# Reported by deqp-runner
amdgpu/a
There are two ways to opportunistically increment a device's runtime PM
usage count, calling either pm_runtime_get_if_active() or
pm_runtime_get_if_in_use(). The former has an argument to tell whether to
ignore the usage count or not, and the latter simply calls the former with
ign_usage_count set
Hi folks,
Here's a small but a different set of patches for making two relatively
minor changes to runtime PM API. I restarted version numbering as this is
meaningfully different from the previous set.
pm_runtime_get_if_active() loses its second argument as it only made sense
to have ign_usage_co
Hi
Am 23.01.24 um 15:56 schrieb Jocelyn Falempe:
On 23/01/2024 13:56, Thomas Zimmermann wrote:
Hi,
FYI for points 1 and 2, I'm typing up a patchset that introduces
drm_pixmap for the source buffer. I'll post it when I have something
ready.
Thanks, I didn't have time to look into this yet
On Tue, Jan 30, 2024 at 12:10:31PM +0100, Daniel Vetter wrote:
> On Mon, Jan 29, 2024 at 06:31:19PM +0800, Julia Zhang wrote:
> > As vram objects don't have backing pages and thus can't implement
> > drm_gem_object_funcs.get_sg_table callback. This removes drm dma-buf
> > callbacks in virtgpu_gem_m
Hi Hans,
Am 29.01.24 um 14:24 schrieb Hans de Goede:
Hi Werner,
On 1/19/24 17:04, Werner Sembach wrote:
Am 19.01.24 um 09:44 schrieb Hans de Goede:
So my proposal would be an ioctl interface (ioctl only no r/w)
using /dev/rgbkbd0 /dev/rgbkdb1, etc. registered as a misc chardev.
For per ke
On Mon, Jan 29, 2024 at 06:31:19PM +0800, Julia Zhang wrote:
> As vram objects don't have backing pages and thus can't implement
> drm_gem_object_funcs.get_sg_table callback. This removes drm dma-buf
> callbacks in virtgpu_gem_map_dma_buf()/virtgpu_gem_unmap_dma_buf()
> and implement virtgpu specif
> Do we really need this much flexibility, especially for the first driver
> adding the first few additional properties?
AFAIU we'd like to allow more props as well, e.g. cursor position…
1 - 100 of 160 matches
Mail list logo
