Hi Maxime,
On Mon, Nov 25, 2024 at 05:00:56PM +0100, Maxime Ripard wrote:
> Hi Sean,
>
> On Mon, Nov 25, 2024 at 02:49:26PM +0100, Sean Nyekjaer wrote:
> > Check if the required pixel clock is in within .5% range of the
> > desired pixel clock.
> > This will match the requirement for HDMI where a
On Sun, Nov 24, 2024 at 02:20:15PM +0100, Jens Glathe wrote:
> Add compatible values for the HP Omnibook X Laptop 14-fe0750ng,
> using "hp,omnibook-x14"
>
> The laptop is based on the Snapdragon X Elite (x1e80100) SoC.
>
> PDF link: https://www8.hp.com/h20195/V2/GetPDF.aspx/c08989140
>
> Signed-
On 26/11/2024 08:33, Liu Ying wrote:
> On 11/26/2024, Krzysztof Kozlowski wrote:
>> On Mon, Nov 25, 2024 at 05:33:12PM +0800, Liu Ying wrote:
>>> Document SCU controlled display pixel link child nodes.
>>>
>>> Signed-off-by: Liu Ying
>>> ---
>>> v4:
>>> * No change.
>>>
>>> v3:
>>> * No change.
>>
On 11/26/2024, Krzysztof Kozlowski wrote:
> On Mon, Nov 25, 2024 at 05:33:12PM +0800, Liu Ying wrote:
>> Document SCU controlled display pixel link child nodes.
>>
>> Signed-off-by: Liu Ying
>> ---
>> v4:
>> * No change.
>>
>> v3:
>> * No change.
>>
>> v2:
>> * New patch as needed by display contr
On Mon, Nov 25, 2024 at 05:33:12PM +0800, Liu Ying wrote:
> Document SCU controlled display pixel link child nodes.
>
> Signed-off-by: Liu Ying
> ---
> v4:
> * No change.
>
> v3:
> * No change.
>
> v2:
> * New patch as needed by display controller subsystem device tree.
DO NOT MERGE means also
On 11/22/2024, Miquel Raynal wrote:
> Hello Liu,
Hello Miquel,
>
> Thanks for the feedback!
>
> On 22/11/2024 at 14:01:49 +08, Liu Ying wrote:
>
>> Hi Miquel,
>>
>> On 11/22/2024, Miquel Raynal wrote:
>>> Recent changes in the clock tree have set CLK_SET_RATE_PARENT to the two
>>> LCDIF pixel
On Mon, Nov 25, 2024 at 10:32:42AM +0100, Christian König wrote:
> Am 22.11.24 um 17:02 schrieb Raag Jadav:
> > On Fri, Nov 22, 2024 at 11:09:32AM +0100, Christian König wrote:
> > > Am 22.11.24 um 08:07 schrieb Raag Jadav:
> > > > On Mon, Nov 18, 2024 at 08:26:37PM +0530, Aravind Iddamsetty wrote:
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_r
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_r
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_r
Hi Maarten, Maxime, Thomas
Cc Laurent
The patch has been created as 1 patch for "drivers/gpu/drm", but this time
I have finely disassembled the patch into 3 patches.
v6 -> v7
- created as 3 patches
Kuninori Morimoto (3):
gpu: drm: drm_of: replace of_graph_get_next_endpoint()
gpu: d
This cmd is useful to let the VMM (i.e, Qemu) know that the backing
store associated with a resource is no longer valid, so that the VMM
can perform any cleanup or unmap operations.
The fence related changes and virtio_gpu_object_detach()/
virtio_gpu_detach_object_fenced() routines are extracted f
On Sat, Nov 23, 2024 at 5:42 AM Petr Vorel wrote:
>
> > On Thu, Nov 21, 2024 at 10:49 AM Rob Clark wrote:
>
> > > On Wed, Nov 20, 2024 at 5:17 PM Petr Vorel wrote:
>
> > > > > On Thu, Nov 21, 2024 at 5:41 AM Petr Vorel wrote:
>
> > > > > > It will be used in the next commit for DRM_MSM.
>
> > >
When an imported dmabuf obj is used as part of an atomic commit, we
need to pin it as part of prepare and unpin it during cleanup of
the associated FB, to make sure that it does not move until the
commit is completed (and also while it is being used on the Host).
Cc: Gerd Hoffmann
Cc: Dmitry Osip
The imported object can be considered a guest blob resource;
therefore, we use create_blob cmd while creating it. These helpers
are used in the next patch which does the actual import.
Cc: Gerd Hoffmann
Cc: Dmitry Osipenko
Cc: Rob Clark
Cc: Gurchetan Singh
Cc: Chia-I Wu
Signed-off-by: Vivek K
By importing scanout buffers from other devices, we should be able
to use the virtio-gpu driver in KMS only mode. Note that we attach
dynamically and register a move_notify() callback so that we can
let the VMM know of any location changes associated with the backing
store of the imported object by
Having virtio-gpu import scanout buffers (via prime) from other
devices means that we'd be adding a head to headless GPUs assigned
to a Guest VM or additional heads to regular GPU devices that are
passthrough'd to the Guest. In these cases, the Guest compositor
can render into the scanout buffer us
This helper would be used when first initializing the object as
part of import and also when updating the plane where we need to
ensure that the imported object's backing is valid.
Cc: Gerd Hoffmann
Cc: Dmitry Osipenko
Cc: Rob Clark
Cc: Gurchetan Singh
Cc: Chia-I Wu
Signed-off-by: Vivek Kasir
Hi Dmitry,
> Subject: Re: [PATCH v4 4/5] drm/virtio: Import prime buffers from other
> devices as guest blobs
>
> > struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device
> *dev,
> > struct dma_buf *buf)
> > {
> > + struct virtio_gpu_devi
Hi Dmitry,
> Subject: Re: [PATCH v4 2/5] drm/virtio: Add a helper to map and note the
> dma addrs and lengths
>
> > +int virtgpu_dma_buf_import_sgt(struct virtio_gpu_mem_entry **ents,
> > + unsigned int *nents,
> > + struct virtio_gpu_object *bo,
On 11/22/2024 9:44 PM, Dmitry Baryshkov wrote:
The macrotile_mode is a flag, not a bit value. Use true/false values to
set it rather than 1/0.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
Revie
On 11/22/2024 9:44 PM, Dmitry Baryshkov wrote:
Follow other msm_mdss_setup_ubwc_dec_nn functions and use individual
bits instead of just specifying the value to be programmed to the
UBWC_STATIC register.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 17 +-
On 11/25/2024, Francesco Dolcini wrote:
> On Mon, Nov 25, 2024 at 05:33:13PM +0800, Liu Ying wrote:
>> Add display controller subsystem in i.MX8qxp SoC.
>>
>> Signed-off-by: Liu Ying
>
> ...
>
>> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
>> b/arch/arm64/boot/dts/freescale/imx8qxp.
On 11/22/2024 9:44 PM, Dmitry Baryshkov wrote:
Rather than hand-coding UBWC_STATIC value calculation, define
corresponding bitfields and use them to setup the register value.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 38 +++---
On 2024/11/26 6:11, Dmitry Baryshkov wrote:
On Mon, 25 Nov 2024 at 04:31, fange zhang wrote:
On 2024/11/22 18:10, Dmitry Baryshkov wrote:
On Fri, Nov 22, 2024 at 05:56:50PM +0800, Fange Zhang wrote:
From: Li Liu
Add support for DSI 2.3.1 (block used on SM6150).
Signed-off-by: Li Liu
The pull request you sent on Sun, 24 Nov 2024 18:38:26 +0100:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/fbdev-for-6.13-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4e07155dd58cab024813e97dc384d48f34e3d16e
Thank you!
--
Dee
在 2024/11/22 9:42, Dmitry Baryshkov 写道:
On Mon, Nov 18, 2024 at 10:28:01PM +0800, Yongbang Shi wrote:
From: baihan li
Add dp aux read/write functions. They are basic functions
and will be used later.
Signed-off-by: Baihan Li
Signed-off-by: Yongbang Shi
---
ChangeLog:
v4 -> v5:
- fixing
On 11/25/24 2:17 PM, Maxime Ripard wrote:
On Fri, Nov 22, 2024 at 03:32:57PM +0200, Dmitry Baryshkov wrote:
On Tue, Nov 12, 2024 at 03:05:37AM +0100, Marek Vasut wrote:
The Pixel PLL is not very capable and may come up with wildly inaccurate
clock. Since DPI panels are often tolerant to slightl
On 11/22/24 2:32 PM, Dmitry Baryshkov wrote:
On Tue, Nov 12, 2024 at 03:05:37AM +0100, Marek Vasut wrote:
The Pixel PLL is not very capable and may come up with wildly inaccurate
clock. Since DPI panels are often tolerant to slightly higher pixel clock
without being operated outside of specifica
Hi Louis,
On 22/11/24 13:27, Louis Chauvet wrote:
The current VKMS driver uses managed function to create crtc, but
don't use it to properly clean the crtc workqueue. It is not an
issue yet, but in order to support multiple devices easily,
convert this code to use drm and device managed helpers.
Hi Louis,
On 22/11/24 13:27, Louis Chauvet wrote:
The current VKMS driver uses non-managed function to create encoders. It
is not an issue yet, but in order to support multiple devices easily,
convert this code to use drm and device managed helpers.
Signed-off-by: Louis Chauvet
Reviewed-by:
Hi Louis,
On 22/11/24 13:27, Louis Chauvet wrote:
The current VKMS driver uses non-managed function to create connectors. It
is not an issue yet, but in order to support multiple devices easily,
convert this code to use drm and device managed helpers.
Signed-off-by: Louis Chauvet
Reviewed-by
On Mon, Nov 25, 2024 at 08:11:19PM +0100, Maud Spierings via B4 Relay wrote:
> From: Maud Spierings
>
> Add bluetooth for the asus vivobook s15
> Describe wlan configuration
>
> Signed-off-by: Maud Spierings
> ---
> .../boot/dts/qcom/x1e80100-asus-vivobook-s15.dts | 164
> ++
On Mon, 25 Nov 2024 at 04:31, fange zhang wrote:
>
>
>
> On 2024/11/22 18:10, Dmitry Baryshkov wrote:
> > On Fri, Nov 22, 2024 at 05:56:50PM +0800, Fange Zhang wrote:
> >> From: Li Liu
> >>
> >> Add support for DSI 2.3.1 (block used on SM6150).
> >>
> >> Signed-off-by: Li Liu
> >> Signed-off-by:
On Mon, 25 Nov 2024 at 09:39, fange zhang wrote:
>
>
>
> On 2024/11/22 18:22, Dmitry Baryshkov wrote:
> > On Fri, Nov 22, 2024 at 05:56:52PM +0800, Fange Zhang wrote:
> >> From: Li Liu
> >>
> >> Add display MDSS and DSI configuration for QCS615 RIDE board.
> >> QCS615 has a DP port, and DP suppor
On Mon, 25 Nov 2024 at 15:17, Maxime Ripard wrote:
>
> On Fri, Nov 22, 2024 at 03:32:57PM +0200, Dmitry Baryshkov wrote:
> > On Tue, Nov 12, 2024 at 03:05:37AM +0100, Marek Vasut wrote:
> > > The Pixel PLL is not very capable and may come up with wildly inaccurate
> > > clock. Since DPI panels are
Am Sat, 23 Nov 2024 18:14:05 +
schrieb Mithil Bavishi :
> > > + no-map;
> > > + reg = <0xA000 0x20>;
> >
> > If used for ramoops, then there should be a compatible = "ramoops"
> > see Documentation/devicetree/bindings/reserved-memory/ramoops.yaml
> >
Reviewed-by: Lyude Paul
On Mon, 2024-11-25 at 22:53 +0200, Imre Deak wrote:
> Fix the MST sideband message body length check, which must be at least 1
> byte accounting for the message body CRC (aka message data CRC) at the
> end of the message.
>
> This fixes a case where an MST branch device r
Fix the MST sideband message body length check, which must be at least 1
byte accounting for the message body CRC (aka message data CRC) at the
end of the message.
This fixes a case where an MST branch device returns a header with a
correct header CRC (indicating a correctly received body length),
Breaks userspace command submission. Here's the log with lock debugging on.
```
[ 20.438106]
[ 20.439696] WARNING: lock held when returning to user space!
[ 20.441730] 6.12.0+ #11 Not tainted
[ 20.442389]
Tested working.
Tested-by: Ian Forbes
On Thu, Nov 21, 2024 at 4:27 AM Christian König
wrote:
>
> Start switching over vmwgfx to drm_exec as well. Replacing some
> unnecessary complex calls with just just single BO dma_resv locking.
>
> No intentional functional change, but only compile tested f
From: Zichen Xie
Like commit b0b0d811eac6 ("drm/mediatek: Fix coverity issue with
unintentional integer overflow"), directly multiply args->pitch and
args->height may lead to integer overflow. Add a cast to avoid it.
Signed-off-by: Zichen Xie
---
drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
1 f
Hi Andy,
Yes, the issue can be reproduced with the details in patch 2/3 [1].
[1]:
https://lore.kernel.org/linux-arm-kernel/20241115162120.83990-3-detlev.casan...@collabora.com/T/#m82b38f4a83c4793bb82919bf736b2f6bd804a283
Detlev.
On Monday, 25 November 2024 02:55:41 EST Andy Yan wrote:
> Hello
From: Maud Spierings
Add the lid switch for the Asus vivobook s15
Reviewed-by: Konrad Dybcio
Signed-off-by: Maud Spierings
---
.../boot/dts/qcom/x1e80100-asus-vivobook-s15.dts| 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-asus-
From: Maud Spierings
Add bluetooth for the asus vivobook s15
Describe wlan configuration
Signed-off-by: Maud Spierings
---
.../boot/dts/qcom/x1e80100-asus-vivobook-s15.dts | 164 +
1 file changed, 164 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-asus-vivo
Improves several parts of the devicetree:
1. The eDP panel bindings
2. Add a lid switch
3. Add bluetooth and describe wlan (depends on [1])
[1]:
https://lore.kernel.org/all/20241007-x1e80100-pwrseq-qcp-v1-0-f7166510a...@linaro.org/
---
I seem to get a warning that the pci17cb vendor is undocumen
From: Maud Spierings
The Asus vivobook s15 uses the ATNA56AC03 panel.
This panel is controlled by the atna33xc20 driver instead of the generic
edp-panel driver
Signed-off-by: Maud Spierings
---
.../arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts | 18 +-
1 file changed, 17 i
On Mon, Nov 25, 2024 at 02:33:35AM +0100, Marek Vasut wrote:
> Add Multi-Inno Technology MI0700A2T-30 7" 800x480 LVDS panel
> compatible string.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Conor Dooley
Acked-by: Conor Dooley
signature.asc
Description: PGP signature
On Mon, Nov 25, 2024 at 10:07:03PM +0530, Parthiban Nallathambi wrote:
> GE8300 in Allwinner A133 have reset control from the ccu.
> Add the resets property as optional one to control it.
There's no specific compatible here for an a133, but the binding
requires one. Where is your dts patch?
>
>
Hi,
On Sun, Nov 24, 2024 at 5:20 AM Jens Glathe via B4 Relay
wrote:
>
> From: Jens Glathe
>
> Seems to be like NV140DRM-N61 but with touch. Haven't disassembled
> the lid to look.
>
> Due to lack of information, use the delay_200_500_e200 timings like
> many other BOE panels do for now.
>
> The
On 11/25/24 1:21 PM, Konrad Dybcio wrote:
On 24.11.2024 11:00 AM, Maud Spierings via B4 Relay wrote:
From: Maud Spierings
The Asus vivobook s15 uses the ATNA56AC03 panel.
This panel is controlled by the atna33xc20 driver instead of the generic
edp-panel driver
Signed-off-by: Maud Spierings
-
On 11/24/2024 2:48 PM, Marek Vasut wrote:
The DSI host must be enabled for the panel to be initialized in
prepare(). Set the prepare_prev_first flag to guarantee this.
This fixes the panel operation on NXP i.MX8MP SoC / Samsung DSIM
DSI host.
Hi Marek,
LGTM.
Reviewed-by: Jessica Zhang
Th
On Mon, Nov 25, 2024 at 05:19:54PM +0100, Christian König wrote:
> Am 25.11.24 um 16:29 schrieb Matthew Brost:
> > On Fri, Nov 15, 2024 at 10:27:59AM -0800, Matthew Brost wrote:
> > > [SNIP]
> > > We use this interface to read a BO marked with a dumpable flag during a
> > > GPU hang in our error ca
From: Zichen Xie
Like commit b0b0d811eac6 ("drm/mediatek: Fix coverity issue with
unintentional integer overflow"), directly multiply pitch and
args->height may lead to integer overflow. Add a cast to avoid it.
Signed-off-by: Zichen Xie
---
drivers/gpu/drm/qxl/qxl_dumb.c | 2 +-
1 file changed
On 11/14/24 1:46 AM, Dave Airlie wrote:
From: Dave Airlie
When this code moved to non-coherent allocator the sync was put too
early for some firmwares which called the setup function, move the
sync down after the setup function.
Reported-by: Diogo Ivo
Do you have a link of where this issue
Hi,
On Sun, Nov 24, 2024 at 2:01 AM Maud Spierings via B4 Relay
wrote:
>
> From: Maud Spierings
>
> The Samsung ATNA56AC03 panel is an AMOLED eDP panel.
> It is similar to the ATNA33xc20 except it is larger and has a different
> resolution.
>
> Signed-off-by: Maud Spierings
> ---
> Documentati
On 11/25/24 19:27, Dmitry Osipenko wrote:
> On 11/25/24 10:31, Vivek Kasireddy wrote:
>> +static void virtgpu_dma_buf_free_obj(struct drm_gem_object *obj)
>> +{
>> +struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
>> +struct virtio_gpu_device *vgdev = obj->dev->dev_private;
>> +
Il 22/11/24 08:23, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Wed, 2024-11-20 at 13:44 +0100, AngeloGioacchino Del Regno wrote:
External email : Please do not click links or open attachments until you have
verified the sender or the content.
Add support for the DPI block found in the MT8195 and
Il 22/11/24 07:23, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Fri, 2024-11-22 at 11:54 +0800, CK Hu wrote:
Hi, Angelo:
On Wed, 2024-11-20 at 13:44 +0100, AngeloGioacchino Del Regno wrote:
External email : Please do not click links or open attachments until you have
verified the sender or the con
On Mon, Nov 25, 2024 at 10:03:00PM +0530, Akhil P Oommen wrote:
> There are a few chipsets which don't have system cache a.k.a LLC.
> Currently, the assumption in the driver is that the system cache
> availability correlates with the presence of GMU or RPMH, which
> is not true. For instance, Snapd
On 11/25/24 10:31, Vivek Kasireddy wrote:
> +static void virtgpu_dma_buf_free_obj(struct drm_gem_object *obj)
> +{
> + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> + struct virtio_gpu_device *vgdev = obj->dev->dev_private;
> + struct dma_buf_attachment *attach = obj->imp
On 11/25/24 10:31, Vivek Kasireddy wrote:
> struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev,
> struct dma_buf *buf)
> {
> + struct virtio_gpu_device *vgdev = dev->dev_private;
> + struct dma_buf_attachment *attach;
> +
Mesa support is already available for A612. Verified Glmark2 with
weston.
Some dependencies for the devicetree change are not yet available
in the mailing lists. I will send it out as a separate patch later.
In v2 of this series, there is a new patch to check the LLC support
by using a new QUIRK
From: Jie Zhang
Add support for Adreno 612 GPU found in SM6150/QCS615 chipsets.
A612 falls under ADRENO_6XX_GEN1 family and is a cut down version
of A615 GPU.
A612 has a new IP called Reduced Graphics Management Unit or RGMU
which is a small state machine which helps to toggle GX GDSC
(connected
There are a few chipsets which don't have system cache a.k.a LLC.
Currently, the assumption in the driver is that the system cache
availability correlates with the presence of GMU or RPMH, which
is not true. For instance, Snapdragon 6 Gen 1 has RPMH and a GPU
with a full blown GMU, but doesnot have
Am 25.11.24 um 16:29 schrieb Matthew Brost:
On Fri, Nov 15, 2024 at 10:27:59AM -0800, Matthew Brost wrote:
[SNIP]
We use this interface to read a BO marked with a dumpable flag during a
GPU hang in our error capture code. This is an internal KMD feature, not
directly exposed to user space. Would
On Mon, Nov 25, 2024 at 9:50 PM Sean Nyekjaer wrote:
>
> Use new helper function for HDMI mode validation
This is a bit misleading since this is actually the DPI or parallel
output encoder, not HDMI. HDMI is in drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
and drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
Chen
On Mon, 25 Nov 2024 14:49:27 +0100, Sean Nyekjaer wrote:
> Use new helper function for HDMI mode validation
>
> Signed-off-by: Sean Nyekjaer
Reviewed-by: Maxime Ripard
Thanks!
Maxime
On Mon, 25 Nov 2024 14:49:28 +0100, Sean Nyekjaer wrote:
> When using the DSI interface via DSI2LVDS bridge, it seems a bit harsh
> to reguire the requested and the actual px clock to be within
> 50Hz. A typical LVDS display requires the px clock to be within +-10%.
>
> In case for HDMI .5% tolera
Hi Sean,
On Mon, Nov 25, 2024 at 02:49:26PM +0100, Sean Nyekjaer wrote:
> Check if the required pixel clock is in within .5% range of the
> desired pixel clock.
> This will match the requirement for HDMI where a .5% tolerance is allowed.
>
> Signed-off-by: Sean Nyekjaer
> ---
> drivers/gpu/drm/
On Wed, Nov 20, 2024 at 08:32:45PM +0800, Zhang He wrote:
> in function `i915_gem_gtt_reserve` @node comment,
> i915_vma has no `mode` member, `i915_vma.node` is the correct name
>
> Signed-off-by: Zhang He
Reviewed-by: Rodrigo Vivi
and pushed to drm-intel-next. Thanks for the patch
> ---
>
On November 25, 2024 4:28:00 PM GMT+01:00, Maxime Ripard
wrote:
>On Mon, Nov 25, 2024 at 11:24:25PM +0900, Hector Martin wrote:
>>
>>
>> On 2024/11/25 20:24, Sasha Finkelstein wrote:
>> > On Mon, 25 Nov 2024 at 09:50, Neil Armstrong
>> > wrote:
>> >>
>> >> So this controller only supports a s
Hi Hector,
On 25/11/2024 15:24, Hector Martin wrote:
On 2024/11/25 20:24, Sasha Finkelstein wrote:
On Mon, 25 Nov 2024 at 09:50, Neil Armstrong wrote:
So this controller only supports a single mode ???
Most likely. On all devices it is connected to a single built-in display.
More s
On Fri, Nov 15, 2024 at 10:27:59AM -0800, Matthew Brost wrote:
> On Wed, Nov 13, 2024 at 12:42:35PM +0100, Christian König wrote:
> > Am 13.11.24 um 11:44 schrieb Thomas Hellström:
> > > On Wed, 2024-11-13 at 09:37 +0100, Christian König wrote:
> > > > Am 12.11.24 um 17:33 schrieb Thomas Hellström:
On 2024/11/25 23:53, Krzysztof Kozlowski wrote:
> On 25/11/2024 15:14, Hector Martin wrote:
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+additionalProperties: true
>>>
>>> This cannot be true. Must be false.
>>>
+
+re
On Mon, Nov 25, 2024 at 11:24:25PM +0900, Hector Martin wrote:
>
>
> On 2024/11/25 20:24, Sasha Finkelstein wrote:
> > On Mon, 25 Nov 2024 at 09:50, Neil Armstrong
> > wrote:
> >>
> >> So this controller only supports a single mode ???
> >>
> > Most likely. On all devices it is connected to
Hi Adrian,
On Fri, 15 Nov 2024 19:14:18 +
Adrián Larumbe wrote:
> @@ -71,9 +112,9 @@ void panthor_kernel_bo_destroy(struct panthor_kernel_bo
> *bo)
> * Return: A valid pointer in case of success, an ERR_PTR() otherwise.
> */
> struct panthor_kernel_bo *
> -panthor_kernel_bo_create(stru
On 25/11/2024 16:03, Nick Chan wrote:
>>> +static int summit_probe(struct mipi_dsi_device *dsi)
>>> +{
>>> + struct backlight_properties props = { 0 };
>>> + struct device *dev = &dsi->dev;
>>> + struct summit_data *panel;
>>> +
>>> + panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
>
On 24/11/2024 23:29, Sasha Finkelstein via B4 Relay wrote:
> From: Sasha Finkelstein
>
> This is the display panel used for the touchbar on laptops that have it.
...
> +static int summit_probe(struct mipi_dsi_device *dsi)
> +{
> + struct backlight_properties props = { 0 };
> + struct
On 25/11/2024 15:14, Hector Martin wrote:
>>> +
>>> + "#address-cells":
>>> +const: 1
>>> +
>>> + "#size-cells":
>>> +const: 0
>>> +
>>> +additionalProperties: true
>>
>> This cannot be true. Must be false.
>>
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - interrupts
>>
>>
Hi,
Thanks. Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git
(drm-misc-next)
[1/1] drm/lsdc: Request PCI BAR
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/ca053ee3c6a7a877754e6f444ce5f520e3c0a856
On 2024/11/25 22:02, Philipp Stanner wrote:
lsdc currently just io
Il 21/11/24 22:02, Rob Herring ha scritto:
On Wed, Nov 20, 2024 at 01:45:06PM +0100, AngeloGioacchino Del Regno wrote:
Add a binding for the Display Data Channel (DDC) IP in MediaTek
SoCs with version 2 HDMI TX IP.
Signed-off-by: AngeloGioacchino Del Regno
---
.../mediatek/mediatek,mt8195-h
On 2024/11/25 20:24, Sasha Finkelstein wrote:
> On Mon, 25 Nov 2024 at 09:50, Neil Armstrong
> wrote:
>>
>> So this controller only supports a single mode ???
>>
> Most likely. On all devices it is connected to a single built-in display.
More specifically, the controller obviously support
On 2024/11/25 16:45, Krzysztof Kozlowski wrote:
> On Sun, Nov 24, 2024 at 11:29:24PM +0100, Sasha Finkelstein wrote:
>> Add bindings for a secondary display controller present on certain
>> Apple laptops.
>>
>> Signed-off-by: Sasha Finkelstein
>> ---
>> .../bindings/display/apple,display-pipe.yam
From: Carlos Song
Add eDMA mode support for LPI2C.
There are some differences between TX DMA mode and RX DMA mode.
LPI2C MTDR register is Controller Transmit Data Register.
When lpi2c send data, it is tx cmd register and tx data fifo.
When lpi2c receive data, it is just a rx cmd register. LPI2C
-commit: 28eb75e178d389d325f1666e422bc139804c
change-id: 20241125-dsi-relax-1414baf6cd74
Best regards,
--
Sean Nyekjaer
When using the DSI interface via DSI2LVDS bridge, it seems a bit harsh
to reguire the requested and the actual px clock to be within
50Hz. A typical LVDS display requires the px clock to be within +-10%.
In case for HDMI .5% tolerance is required.
Signed-off-by: Sean Nyekjaer
---
drivers/gpu/dr
Check if the required pixel clock is in within .5% range of the
desired pixel clock.
This will match the requirement for HDMI where a .5% tolerance is allowed.
Signed-off-by: Sean Nyekjaer
---
drivers/gpu/drm/drm_modes.c | 34 ++
include/drm/drm_modes.h | 2 +
Use new helper function for HDMI mode validation
Signed-off-by: Sean Nyekjaer
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index
dfb6acc42f
lsdc currently just ioremaps its PCI BAR with pcim_iomap(). Performing
a region regquest additionally can make the driver more robust.
Replace pcim_iomap() with the managed function pcim_iomap_region() which
performs the request and ioremaps the BAR.
Signed-off-by: Philipp Stanner
Reviewed-by: S
On Fri, Nov 22, 2024 at 03:32:57PM +0200, Dmitry Baryshkov wrote:
> On Tue, Nov 12, 2024 at 03:05:37AM +0100, Marek Vasut wrote:
> > The Pixel PLL is not very capable and may come up with wildly inaccurate
> > clock. Since DPI panels are often tolerant to slightly higher pixel clock
> > without bei
On 25/11/2024 14:14, Sasha Finkelstein wrote:
On Mon, 25 Nov 2024 at 13:57, wrote:
On 25/11/2024 12:24, Sasha Finkelstein wrote:
On Mon, 25 Nov 2024 at 09:50, Neil Armstrong wrote:
So this controller only supports a single mode ???
Most likely. On all devices it is connected to a sin
p),%rcx# 0xd0647
10: f7 d8 neg%eax
12: 64 89 01mov%eax,%fs:(%rcx)
15: 48 rex.W
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20241125/202411252029.30061fde-...@int
On Fri, 22 Nov 2024 17:27:57 +0100, Louis Chauvet wrote:
> The current VKMS driver uses non-managed function to create encoders. It
> is not an issue yet, but in order to support multiple devices easily,
> convert this code to use drm and device managed helpers.
>
> Signed-off-by: Louis Chauvet
>
On Fri, 22 Nov 2024 17:27:58 +0100, Louis Chauvet wrote:
> The current VKMS driver uses managed function to create crtc, but
> don't use it to properly clean the crtc workqueue. It is not an
> issue yet, but in order to support multiple devices easily,
> convert this code to use drm and device mana
On Fri, 22 Nov 2024 17:27:56 +0100, Louis Chauvet wrote:
> The current VKMS driver uses non-managed function to create connectors. It
> is not an issue yet, but in order to support multiple devices easily,
> convert this code to use drm and device managed helpers.
>
> Signed-off-by: Louis Chauvet
On Fri, Nov 22, 2024 at 05:27:59PM +0100, Louis Chauvet wrote:
> Currently drm_writeback_connector are created by
> drm_writeback_connector_init or drm_writeback_connector_init_with_encoder.
> Both of the function uses drm_connector_init and drm_encoder_init, but
> there is no way to properly clean
1 - 100 of 155 matches
Mail list logo
