Hello Qiang,
On 2024-06-26 03:11, Qiang Yu wrote:
On Wed, Jun 26, 2024 at 2:15 AM Dragan Simic
wrote:
Hello everyone,
Just checking, any further thoughts about this patch?
I'm OK with this as a temp workaround because it's simple and do no
harm
even it's not perfect. If no other better sug
has committer rights to drm-misc to push this patch ?
I guess, it will be taken by drm-misc folks like du driver, as this is now part
of
rz-du folder which is part of the list [1] ??
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/MAINTAINERS?h=next-20240625#n7345
Ch
In qxl_add_mode(), the return value of drm_cvt_mode() is assigned to mode,
which will lead to a possible NULL pointer dereference on failure of
drm_cvt_mode(). Add a check to avoid npd.
Signed-off-by: Ma Ke
---
drivers/gpu/drm/qxl/qxl_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Hi Thomas,
On Thu, Jun 20, 2024 at 10:20 PM Chun-Kuang Hu wrote:
>
> Hi, Chen-Yu:
>
> Chen-Yu Tsai 於 2024年6月20日 週四 下午1:47寫道：
> >
> > With the recent switch from fbdev-generic to fbdev-dma, the driver now
> > requires the DRM GEM DMA helpers. This dependency is missing, and will
> > cause a link
On 26/06/2024 06:31, Dmitry Baryshkov wrote:
> On Tue, Jun 25, 2024 at 04:51:27PM GMT, Rob Herring wrote:
>> On Sun, Jun 23, 2024 at 02:59:30PM +0200, Krzysztof Kozlowski wrote:
>>> dtschema v2024.4, v2024.5 and maybe earlier do not select device nodes for
>>
>> That should be just since db9c05a087
Hi Prabhakar,
Thank you for the patch.
On Tue, Jun 25, 2024 at 01:32:44PM +0100, Prabhakar wrote:
> From: Lad Prabhakar
>
> All the RZ/G2L DU specific components are located under the rz-du folder,
> so it makes sense to move the RZ/G2L MIPI DSI driver there instead of
> keeping it in the rcar-
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi:
Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for
sitronix-st7703 based panels.
Signed-off-by: Tejas Vipin
---
drivers/gpu/drm/panel/panel-sitronix-st
On Tue, Jun 25, 2024 at 06:38:13PM GMT, Marc Gonzalez wrote:
> The TI TDP158 is an AC-Coupled HDMI signal to TMDS Redriver supporting
> DVI 1.0 and HDMI 1.4b and 2.0b output signals.
>
> The default settings work fine for our use-case.
>
> Signed-off-by: Marc Gonzalez
> ---
> drivers/gpu/drm/br
On 6/25/24 4:37 PM, Alexander Stein wrote:
Hi Marek,
Hi,
Am Dienstag, 25. Juni 2024, 14:26:10 CEST schrieb Marek Vasut:
Initialize the bridge on attach already, to force lanes into LP11
state, since attach does trigger attach of downstream bridges which
may trigger (e)DP AUX channel mode rea
On Tue, Jun 25, 2024 at 04:25:50PM GMT, Jerome Brunet wrote:
> Add support for the Lincoln LCD197 1080x1920 DSI panel.
>
> Signed-off-by: Jerome Brunet
> ---
> drivers/gpu/drm/panel/Kconfig| 11 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/pa
On Tue, Jun 25, 2024 at 03:18:09PM GMT, Thomas Zimmermann wrote:
> The function drm_simple_encoder_init() is a trivial helper and
> deprecated. Replace it with the regular call to drm_encoder_init().
> Resolves the dependency on drm_simple_kms_helper.h. No functional
> changes.
>
> Signed-off-by:
On Tue, Jun 25, 2024 at 04:51:27PM GMT, Rob Herring wrote:
> On Sun, Jun 23, 2024 at 02:59:30PM +0200, Krzysztof Kozlowski wrote:
> > dtschema v2024.4, v2024.5 and maybe earlier do not select device nodes for
>
> That should be just since db9c05a08709 ("validator: Rework selecting
> schemas for v
On Mon, Jun 24, 2024 at 03:30:31AM GMT, Caleb Connolly wrote:
> Initial support for USB, UFS, touchscreen, panel, wifi, and bluetooth.
>
Nice.
> diff --git a/arch/arm64/boot/dts/qcom/sm8250-oneplus-common.dtsi
> b/arch/arm64/boot/dts/qcom/sm8250-oneplus-common.dtsi
[..]
> + vph_pwr: vph-pwr
在 2024-06-25星期二的 14:01 +0200，Lucas Stach写道：
> Am Dienstag, dem 25.06.2024 um 11:18 +0800 schrieb Icenowy Zheng:
> > 在 2024-05-20星期一的 00:53 +0800，Sui Jingfeng写道：
> > > drm/etnaviv use the component framework to bind multiple GPU
> > > cores to
> > > a
> > > virtual master, the virtual master is manu
On Wed, Jun 26, 2024 at 2:15 AM Dragan Simic wrote:
>
> Hello everyone,
>
> Just checking, any further thoughts about this patch?
>
I'm OK with this as a temp workaround because it's simple and do no harm
even it's not perfect. If no other better suggestion for short term, I'll submit
this at week
On Sun, Jun 23, 2024 at 02:59:30PM +0200, Krzysztof Kozlowski wrote:
> dtschema v2024.4, v2024.5 and maybe earlier do not select device nodes for
That should be just since db9c05a08709 ("validator: Rework selecting
schemas for validation") AKA the 6x speed up in v2024.04.
> given binding validat
On Tue, Jun 25, 2024 at 1:18 PM Dmitry Baryshkov
wrote:
>
> On Tue, 25 Jun 2024 at 21:54, Konrad Dybcio wrote:
> >
> > Commit c9707bcbd0f3 ("drm/msm/adreno: De-spaghettify the use of memory
>
> ID is not present in next
it ofc wouldn't be, because it was the previous patch in this series ;-)
I'
On Tue, Jun 25, 2024 at 1:23 PM Akhil P Oommen wrote:
>
> On Tue, Jun 25, 2024 at 11:03:42AM -0700, Rob Clark wrote: > On Tue, Jun 25,
> 2024 at 10:59 AM Akhil P Oommen wrote:
> > >
> > > On Fri, Jun 21, 2024 at 02:09:58PM -0700, Rob Clark wrote:
> > > > On Sat, Jun 8, 2024 at 8:44 AM Kiarash Ha
On 6/25/2024 1:24 PM, Dmitry Baryshkov wrote:
From: Bjorn Andersson
Some platforms provides a mechanism for configuring the mapping between
(one or two) DisplayPort intfs and their PHYs.
In particular SC8180X requires this to be configured, since on this
platform there are fewer controllers
eno/a6xx_gpu.c | 14 ++
> 2 files changed, 7 insertions(+), 11 deletions(-)
> ---
> base-commit: 0fc4bfab2cd45f9acb86c4f04b5191e114e901ed
> change-id: 20240625-adreno_barriers-29f356742418
for the whole series:
Reviewed-by: Akhil P Oommen
-Akhil
>
> Best regards,
> --
> Konrad Dybcio
>
From: Bjorn Andersson
Some platforms provides a mechanism for configuring the mapping between
(one or two) DisplayPort intfs and their PHYs.
In particular SC8180X requires this to be configured, since on this
platform there are fewer controllers than PHYs.
The change implements the logic for op
On Tue, Jun 25, 2024 at 11:03:42AM -0700, Rob Clark wrote: > On Tue, Jun 25,
2024 at 10:59 AM Akhil P Oommen wrote:
> >
> > On Fri, Jun 21, 2024 at 02:09:58PM -0700, Rob Clark wrote:
> > > On Sat, Jun 8, 2024 at 8:44 AM Kiarash Hajian
> > > wrote:
> > > >
> > > > The driver's memory regions are
On 6/25/2024 1:20 PM, Dmitry Baryshkov wrote:
On Tue, 25 Jun 2024 at 22:28, Abhinav Kumar wrote:
On 6/25/2024 12:26 PM, Abhinav Kumar wrote:
On 6/24/2024 6:39 PM, Abhinav Kumar wrote:
On 6/13/2024 4:17 AM, Dmitry Baryshkov wrote:
From: Bjorn Andersson
Some platforms provides a me
On Tue, 25 Jun 2024 at 22:28, Abhinav Kumar wrote:
>
>
>
> On 6/25/2024 12:26 PM, Abhinav Kumar wrote:
> >
> >
> > On 6/24/2024 6:39 PM, Abhinav Kumar wrote:
> >>
> >>
> >> On 6/13/2024 4:17 AM, Dmitry Baryshkov wrote:
> >>> From: Bjorn Andersson
> >>>
> >>> Some platforms provides a mechanism fo
On Tue, 25 Jun 2024 at 21:54, Konrad Dybcio wrote:
>
> Commit c9707bcbd0f3 ("drm/msm/adreno: De-spaghettify the use of memory
ID is not present in next
> barriers") made some fixups relating to write arrival, ensuring that
> the GPU's memory interface has *really really really* been told to come
Add a netdev_dmabuf_binding struct which represents the
dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
rx queues on the netdevice. On the binding, the dma_buf_attach
& dma_buf_map_attachment will occur. The entries in the sg_table from
mapping will be inserted into a genpool
Make skb_frag_page() fail in the case where the frag is not backed
by a page, and fix its relevant callers to handle this case.
Signed-off-by: Mina Almasry
---
v10:
- Fixed newly generated kdoc warnings found by patchwork. While we're
at it, fix the Return section of the functions I touched.
ncdevmem is a devmem TCP netcat. It works similarly to netcat, but it
sends and receives data using the devmem TCP APIs. It uses udmabuf as
the dmabuf provider. It is compatible with a regular netcat running on
a peer, or a ncdevmem running on a peer.
In addition to normal netcat support, ncdevmem
In tcp_recvmsg_locked(), detect if the skb being received by the user
is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
flag - pass it to tcp_recvmsg_devmem() for custom handling.
tcp_recvmsg_devmem() copies any data in the skb header to the linear
buffer, and returns a cmsg
Implement a memory provider that allocates dmabuf devmem in the form of
net_iov.
The provider receives a reference to the struct netdev_dmabuf_binding
via the pool->mp_priv pointer. The driver needs to set this pointer for
the provider in the net_iov.
The provider obtains a reference on the netde
For device memory TCP, we expect the skb headers to be available in host
memory for access, and we expect the skb frags to be in device memory
and unaccessible to the host. We expect there to be no mixing and
matching of device memory frags (unaccessible) with host memory frags
(accessible) in the
Add documentation outlining the usage and details of devmem TCP.
Signed-off-by: Mina Almasry
Reviewed-by: Bagas Sanjaya
---
v9:
https://lore.kernel.org/netdev/20240403002053.2376017-14-almasrym...@google.com/
- Bagas doc suggestions.
v8:
- Applied docs suggestions (Randy). Thanks!
v7:
- App
Add an interface for the user to notify the kernel that it is done
reading the devmem dmabuf frags returned as cmsg. The kernel will
drop the reference on the frags to make them available for reuse.
Signed-off-by: Willem de Bruijn
Signed-off-by: Kaiyuan Zhang
Signed-off-by: Mina Almasry
---
v
Convert netmem to be a union of struct page and struct netmem. Overload
the LSB of struct netmem* to indicate that it's a net_iov, otherwise
it's a page.
Currently these entries in struct page are rented by the page_pool and
used exclusively by the net stack:
struct {
unsigned long pp_mag
Implement netdev devmem allocator. The allocator takes a given struct
netdev_dmabuf_binding as input and allocates net_iov from that
binding.
The allocation simply delegates to the binding's genpool for the
allocation logic and wraps the returned memory region in a net_iov
struct.
Signed-off-by:
Abstract the memory type from the page_pool so we can later add support
for new memory types. Convert the page_pool to use the new netmem type
abstraction, rather than use struct page directly.
As of this patch the netmem type is a no-op abstraction: it's always a
struct page underneath. All the p
API takes the dma-buf fd as input, and binds it to the netdevice. The
user can specify the rx queues to bind the dma-buf to.
Suggested-by: Stanislav Fomichev
Signed-off-by: Mina Almasry
---
v7:
- Use flags: [ admin-perm ] instead of a CAP_NET_ADMIN check.
Changes in v1:
- Add rx-queue-type to
Add netdev_rx_queue_restart() function to netdev_rx_queue.h
Signed-off-by: David Wei
Signed-off-by: Mina Almasry
Reviewed-by: Pavel Begunkov
---
v13:
- Add reviewed-by from Pavel (thanks!)
- Fixed comment (Pavel)
v11:
- Fix not checking dev->queue_mgmt_ops (Pavel).
- Fix ndo_queue_mem_free c
v14:
https://patchwork.kernel.org/project/netdevbpf/list/?series=865135&archive=both&state=*
No material changes in this version. Only rebase and re-verification on
top of net-next. v13, I think, raced with commit ebad6d0334793
("net/ipv4: Use nested-BH locking for ipv4_tcp_sk.") being merge
On 6/25/2024 12:26 PM, Abhinav Kumar wrote:
On 6/24/2024 6:39 PM, Abhinav Kumar wrote:
On 6/13/2024 4:17 AM, Dmitry Baryshkov wrote:
From: Bjorn Andersson
Some platforms provides a mechanism for configuring the mapping between
(one or two) DisplayPort intfs and their PHYs.
In particul
On 6/24/2024 6:39 PM, Abhinav Kumar wrote:
On 6/13/2024 4:17 AM, Dmitry Baryshkov wrote:
From: Bjorn Andersson
Some platforms provides a mechanism for configuring the mapping between
(one or two) DisplayPort intfs and their PHYs.
In particular SC8180X provides this functionality, without
Reviewed-by: Lyude Paul
I will push this and the other patch that you sent upstream in just a
moment, thanks!
On Tue, 2024-06-25 at 16:10 +0800, Ma Ke wrote:
> In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate()
> is
> assigned to mode, which will lead to a possible NULL pointer
Reviewed-by: Lyude Paul
On Tue, 2024-06-25 at 16:18 +0800, Ma Ke wrote:
> In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate()
> is
> assigned to mode, which will lead to a possible NULL pointer
> dereference
> on failure of drm_mode_duplicate(). Add a check to avoid npd.
>
> Cc:
Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.
Moreover, the gpu_/gmu_ accessors
Commit c9707bcbd0f3 ("drm/msm/adreno: De-spaghettify the use of memory
barriers") made some fixups relating to write arrival, ensuring that
the GPU's memory interface has *really really really* been told to come
out of reset. That in turn rendered the hacky commit being reverted no
longer necessary
l for GBIF unhalt status in hw_init"
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 +---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 ++
2 files changed, 7 insertions(+), 11 deletions(-)
---
base-commit: 0fc4bfab2cd45f9acb86c4f04b5191e114e901ed
change-id: 20240625-adreno_barriers-29f
There is no need to reinvent the wheel for simple read-match-set logic.
Make speedbin discovery and assignment generation independent.
This implicitly removes the bogus 0x80 / BIT(7) speed bin on A5xx,
which has no representation in hardware whatshowever.
Signed-off-by: Konrad Dybcio
---
drive
Add the speedbin masks to ensure only the desired OPPs are available on
chips of a given bin.
Using this, add the binned 719 MHz OPP and the non-binned 124.8 MHz.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 21 -
1 f
In preparation for commonizing the speedbin handling code.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a5xx_catalog.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_catalog.c
b/drivers/gpu/drm/msm/adreno/a
Add speebin data for A740, as found on SM8550 and derivative SoCs.
For non-development SoCs it seems that "everything except FC_AC, FC_AF
should be speedbin 1", but what the values are for said "everything" are
not known, so that's an exercise left to the user..
Reviewed-by: Dmitry Baryshkov
Sig
On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
abstracted through SMEM, instead of being directly available in a fuse.
Add support for SMEM-based speed binning, which includes getting
"feature code" and "product code" from said source and parsing them
to form something that le
for 8550
- Fix some checkpatch fluff (code style)
- Rebase on next-20240625
Changes in v3:
- Wrap the argument usage in new preprocessor macros in braces (Bjorn)
- Make the SOCINFO_FC_INT_MAX define inclusive, adjust .h and .c (Bjorn)
- Pick up rbs
- Rebase on next-20240605
- Drop the already-applied
Hello everyone,
Just checking, any further thoughts about this patch?
On 2024-06-18 21:22, Dragan Simic wrote:
On 2024-06-18 12:33, Dragan Simic wrote:
On 2024-06-18 10:13, Maxime Ripard wrote:
On Tue, Jun 18, 2024 at 04:01:26PM GMT, Qiang Yu wrote:
On Tue, Jun 18, 2024 at 12:33 PM Qiang Yu
On Tue, Jun 18, 2024 at 10:08:23PM +0530, Akhil P Oommen wrote:
> On Tue, Jun 04, 2024 at 07:35:04PM +0200, Konrad Dybcio wrote:
> >
> >
> > On 5/14/24 20:38, Akhil P Oommen wrote:
> > > On Wed, May 08, 2024 at 07:46:31PM +0200, Konrad Dybcio wrote:
> > > > Memory barriers help ensure instruction
On Tue, Jun 25, 2024 at 10:59 AM Akhil P Oommen
wrote:
>
> On Fri, Jun 21, 2024 at 02:09:58PM -0700, Rob Clark wrote:
> > On Sat, Jun 8, 2024 at 8:44 AM Kiarash Hajian
> > wrote:
> > >
> > > The driver's memory regions are currently just ioremap()ed, but not
> > > reserved through a request. That
On Thu, Jun 20, 2024 at 02:04:01PM +0100, Will Deacon wrote:
> On Tue, Jun 18, 2024 at 09:41:58PM +0530, Akhil P Oommen wrote:
> > On Tue, Jun 04, 2024 at 03:40:56PM +0100, Will Deacon wrote:
> > > On Thu, May 16, 2024 at 01:55:26PM -0500, Andrew Halaney wrote:
> > > > On Thu, May 16, 2024 at 08:20
On Fri, Jun 21, 2024 at 02:09:58PM -0700, Rob Clark wrote:
> On Sat, Jun 8, 2024 at 8:44 AM Kiarash Hajian
> wrote:
> >
> > The driver's memory regions are currently just ioremap()ed, but not
> > reserved through a request. That's not a bug, but having the request is
> > a little more robust.
> >
https://bugzilla.kernel.org/show_bug.cgi?id=218900
--- Comment #20 from Jean-Denis Girard (jd.gir...@sysnux.pf) ---
Yes, I confirm the patch "iommu/amd: Fix GT feature enablement again" applied
to 6.10-rc5 fixes resume on my machine.
Thanks for prompt reply!
--
You may reply to this email to ad
On 6/25/2024 5:13 AM, zhaoxiong lv wrote:
On Tue, Jun 25, 2024 at 7:41 AM Jessica Zhang wrote:
On 6/24/2024 7:19 AM, Zhaoxiong Lv wrote:
Currently, the init_code of the jd9365da driver is placed
in the enable() function and sent, but this seems to take
a long time. It takes 17ms to send
On 25.06.2024 7:21 PM, Rob Clark wrote:
> On Wed, Jun 5, 2024 at 1:10 PM Konrad Dybcio wrote:
>>
>> Add speebin data for A740, as found on SM8550 and derivative SoCs.
>>
>> Reviewed-by: Dmitry Baryshkov
>> Signed-off-by: Konrad Dybcio
>> ---
>> drivers/gpu/drm/msm/adreno/adreno_device.c | 4 +++
On 25.06.2024 7:20 PM, Rob Clark wrote:
> On Wed, Jun 5, 2024 at 1:10 PM Konrad Dybcio wrote:
>>
[...]
>> struct adreno_speedbin {
>> - uint16_t fuse;
>> + /* <= 16-bit for NVMEM fuses, 32b for SOCID values */
>> + uint32_t fuse;
>> +/* As of SM8650, PCODE on production SoCs i
On Wed, Jun 5, 2024 at 1:10 PM Konrad Dybcio wrote:
>
> Add speebin data for A740, as found on SM8550 and derivative SoCs.
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --g
On Wed, Jun 5, 2024 at 1:10 PM Konrad Dybcio wrote:
>
> On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
> abstracted through SMEM, instead of being directly available in a fuse.
>
> Add support for SMEM-based speed binning, which includes getting
> "feature code" and "product c
https://bugzilla.kernel.org/show_bug.cgi?id=218900
--- Comment #19 from Vasant Hegde (vasant.he...@amd.com) ---
Unfortunately there was another big in suspend/resume path. Can you please test
with below patch?
https://lore.kernel.org/linux-iommu/znqzxycu8bn32...@8bytes.org/T/#m1cd1520facb8b758efd
https://bugzilla.kernel.org/show_bug.cgi?id=218900
--- Comment #18 from Jean-Denis Girard (jd.gir...@sysnux.pf) ---
Created attachment 306495
--> https://bugzilla.kernel.org/attachment.cgi?id=306495&action=edit
Complete dmesg
--
You may reply to this email to add a comment.
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=218900
Jean-Denis Girard (jd.gir...@sysnux.pf) changed:
What|Removed |Added
CC||jd.gir...@sysnux
On Sun, 23 Jun 2024 22:02:59 +0200, Krzysztof Kozlowski wrote:
> Changes since v1:
> 1. Add tags
> 2. New patches #3 and #4
> 3. Drop previous patch "dt-bindings: display/msm/gpu: constrain
>reg/reg-names per variant", because I need to investigate more.
>
> v1: dt-bindings: display/msm/gpu:
---
Changes in v2:
- Don't overload simple-bridge, spin new minimal driver
- New driver, new binding
- Default device settings work fine for us, so we don't tweak registers
- Link to v1:
https://lore.kernel.org/r/20240617-tdp158-v1-0-df98ef7de...@freebox.fr
Getting unusual message at run-time,
The TI TDP158 is an AC-Coupled HDMI signal to TMDS Redriver supporting
DVI 1.0 and HDMI 1.4b and 2.0b output signals.
The default settings work fine for our use-case.
Signed-off-by: Marc Gonzalez
---
drivers/gpu/drm/bridge/Kconfig | 6 +++
drivers/gpu/drm/bridge/Makefile| 1 +
drive
The TI TDP158 is an HDMI to TMDS Redriver.
Signed-off-by: Marc Gonzalez
---
.../bindings/display/bridge/ti,tdp158.yaml | 48 ++
1 file changed, 48 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml
b/Documentation/devicetree/b
On Tue, Jun 25, 2024 at 05:49:54PM GMT, Maxime Ripard wrote:
> On Tue, Jun 25, 2024 at 06:05:33PM GMT, Dmitry Baryshkov wrote:
> > On Tue, 25 Jun 2024 at 18:02, Maxime Ripard wrote:
> > >
> > > Hi,
> > >
> > > On Sun, Jun 23, 2024 at 08:40:12AM GMT, Dmitry Baryshkov wrote:
> > > > On HDMI connecto
On Tue, Jun 25, 2024 at 03:33:16PM +0200, Michael Walle wrote:
> Add the device tree binding for the Ilitek ILI9806E controller which can
> be found on the Ortustech COME35H3P70ULC DSI display panel.
>
> There are no peculiarities except for two different power signals.
>
> Signed-off-by: Michael
On Tue, Jun 25, 2024 at 04:25:49PM +0200, Jerome Brunet wrote:
> This adds the bindings for the 1080x1920 Licoln LCD197 DSI panel to
> panel-simple-dsi.
>
> Signed-off-by: Jerome Brunet
Acked-by: Conor Dooley
signature.asc
Description: PGP signature
On Tue, Jun 25, 2024 at 04:25:48PM +0200, Jerome Brunet wrote:
> Lincoln Technology Solutions is a design services and LCD integration
> company
>
> Link: https://lincolntechsolutions.com/
> Signed-off-by: Jerome Brunet
Acked-by: Conor Dooley
signature.asc
Description: PGP signature
On Tue, Jun 25, 2024 at 04:50:14PM +0200, Jerome Brunet wrote:
> All Amlogic instances of the Synopsys HDMI controller need a power domain
> enabled. This is currently missing because the Amlogic HDMI driver directly
> pokes the power domain controller registers, which it should not do.
>
> Instea
Hi Christoph
Sorry for the delay in coming back to you.
On Tue, 28 May 2024 at 07:33, Christoph Hellwig wrote:
>
> On Fri, May 24, 2024 at 07:26:45PM +0100, Dave Stevenson wrote:
> > From: Serge Semin
> >
> > A basic device-specific linear memory mapping was introduced back in
> > commit ("dma:
On Wed, Jun 19, 2024 at 03:01:03PM +0300, Imre Deak wrote:
> On Wed, Jun 19, 2024 at 01:10:09PM +0300, Jani Nikula wrote:
> > On Fri, 14 Jun 2024, Imre Deak wrote:
> > > Add helpers to convert between x16 fixed point and integer/fraction
> > > values. Also add the format/argument macros required t
On Tue, Jun 25, 2024 at 06:05:33PM GMT, Dmitry Baryshkov wrote:
> On Tue, 25 Jun 2024 at 18:02, Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Sun, Jun 23, 2024 at 08:40:12AM GMT, Dmitry Baryshkov wrote:
> > > On HDMI connectors which use drm_bridge_connector and DRM_BRIDGE_OP_HDMI
> > > IGT chokes o
On Tue, Jun 25, 2024 at 02:38:50PM +0530, Manikandan Muralidharan wrote:
> Remove "reset-gpio" property from required properties list and
> make it optional.When interfaced with some boards where reset line is not
> populated it leads to driver probe issues.
>
> Signed-off-by: Manikandan Muralidha
On Tue, Jun 25, 2024 at 02:38:52PM +0530, Manikandan Muralidharan wrote:
> Add compatible string for the Microchip's AC40T08A MIPI Display
> panel.This panel uses a Himax HX8394 display controller.
>
> Signed-off-by: Manikandan Muralidharan
> ---
> .../devicetree/bindings/display/panel/himax,hx8
On Tue, Jun 25, 2024 at 4:27 AM Will Deacon wrote:
>
> On Mon, Jun 24, 2024 at 08:37:26AM -0700, Rob Clark wrote:
> > On Mon, Jun 24, 2024 at 8:14 AM Will Deacon wrote:
> > >
> > > On Thu, May 23, 2024 at 10:52:21AM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > Add an io-pgtabl
On Tue, 25 Jun 2024 at 18:02, Maxime Ripard wrote:
>
> Hi,
>
> On Sun, Jun 23, 2024 at 08:40:12AM GMT, Dmitry Baryshkov wrote:
> > On HDMI connectors which use drm_bridge_connector and DRM_BRIDGE_OP_HDMI
> > IGT chokes on the max_bpc property in several kms_properties tests due
> > to the the drm_
Hi,
On Sun, Jun 23, 2024 at 08:40:12AM GMT, Dmitry Baryshkov wrote:
> On HDMI connectors which use drm_bridge_connector and DRM_BRIDGE_OP_HDMI
> IGT chokes on the max_bpc property in several kms_properties tests due
> to the the drm_bridge_connector failing to reset HDMI-related
> properties.
>
>
On Tue, 25 Jun 2024 07:16:00 -0700 Mina Almasry wrote:
> What happened here is that I sync'd to net-next, ran all the tests
> including the allmodconfig build which took a few hours, then posted
> the series. In the meantime 34 patches got merged to net-next, and one
> of those patches seems to gen
On Sun, 23 Jun 2024 22:30:35 +0200, Barnabás Czémán wrote:
> This patch series adds support for the MDP and DSI PHY as found on the
> MSM8937 platform.
>
>
Applied, thanks!
[1/4] dt-bindings: display/msm: qcom, mdp5: Add msm8937 compatible
https://gitlab.freedesktop.org/lumag/msm/-/comm
On Mon, 24 Jun 2024 00:26:01 +0200, Barnabás Czémán wrote:
> Remove MDP_CAP_SRC_SPLIT from msm8x53_config because
> it is not referenced in downstream.
>
>
Applied, thanks!
[1/1] drm/msm/mdp5: Remove MDP_CAP_SRC_SPLIT from msm8x53_config
https://gitlab.freedesktop.org/lumag/msm/-/commit
On Tue, 25 Jun 2024 01:38:25 +0300, Dmitry Baryshkov wrote:
> The frame event callback is always set to dpu_crtc_frame_event_cb() (or
> to NULL) and the data is always either the CRTC itself or NULL
> (correpondingly). Thus drop the event callback registration, call the
> dpu_crtc_frame_event_cb(
HDMI Tx needs HDMI Tx memory power domain turned on. This power domain is
handled under the VPU power domain.
The HDMI Tx currently works because it is enabling the PD by directly
poking the power controller register. It is should not do that but properly
use the power domain controller.
Fix this
All Amlogic instances of the Synopsys HDMI controller need a power domain
enabled. This is currently missing because the Amlogic HDMI driver directly
pokes the power domain controller registers, which it should not do.
Instead The HDMI controller should use the power controller.
Fix the bindings a
This patchset add the bindings for the power domain of the HDMI Tx
on Amlogic SoC.
This is a 1st step in cleaning HDMI Tx and its direct usage of HHI
register space. Eventually, this will help remove component usage from
the Amlogic display drivers.
Jerome Brunet (2):
dt-bindings: display: meso
On Mon, 24 Jun 2024 11:19:09 +0300, Dmitry Baryshkov wrote:
> FastRPC is a way to offload method invocation to the DSPs on Qualcomm
> platforms. As the driver uses dma-bufs, add dri-devel mailing list to
> the MAINTAINERS's entry, so that DRM maintainers are notified about the
> uAPI changes. Thi
Hi Marek,
Am Dienstag, 25. Juni 2024, 14:26:10 CEST schrieb Marek Vasut:
> Initialize the bridge on attach already, to force lanes into LP11
> state, since attach does trigger attach of downstream bridges which
> may trigger (e)DP AUX channel mode read.
>
> This fixes a corner case where DSIM wit
> In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
> assigned to mode, which will lead to a possible NULL pointer dereference
> on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
> Add a check to avoid null pointer dereference.
Can a wording approach (lik
On Tue, Jun 25, 2024 at 03:58:25PM GMT, Maxime Ripard wrote:
> On Tue, Jun 25, 2024 at 10:23:14AM GMT, Dmitry Baryshkov wrote:
> > On Tue, 25 Jun 2024 at 10:19, Maxime Ripard wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Jun 25, 2024 at 09:21:27AM GMT, Dmitry Baryshkov wrote:
> > > > On Tue, 25 Jun 2
On Tue, Jun 25, 2024 at 03:43:37PM +0200, Markus Elfring wrote:
> > In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is
> > assigned to mode, which will lead to a possible NULL pointer dereference
> > on failure of drm_mode_duplicate(). Add a check to avoid npd.
>
> Can a wordin
On Tue, Jun 25, 2024 at 03:33:17PM GMT, Michael Walle wrote:
> The Ortustech COM35H3P70ULC panel is based on the ILI9806E DSI display
> controller.
>
[...]
> +static int ili9806e_get_modes(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + struct
This adds the bindings for the 1080x1920 Licoln LCD197 DSI panel to
panel-simple-dsi.
Signed-off-by: Jerome Brunet
---
.../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/panel-simp
Add support for the Lincoln LCD197 1080x1920 DSI panel.
Signed-off-by: Jerome Brunet
---
drivers/gpu/drm/panel/Kconfig| 11 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-lincoln-lcd197.c | 333 +++
3 files changed, 345 insert
Lincoln Technology Solutions is a design services and LCD integration
company
Link: https://lincolntechsolutions.com/
Signed-off-by: Jerome Brunet
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/ve
This patchset adds support for the Lincoln LCD197 1080x1920 DSI panel.
Jerome Brunet (3):
dt-bindings: vendor-prefixes: add prefix for lincoln
dt-bindings: panel-simple-dsi: add lincoln LCD197 panel bindings
drm/panel: add lincoln lcd197 support
.../display/panel/panel-simple-dsi.yaml
1 - 100 of 159 matches
Mail list logo
