Il 04/04/23 12:47, AngeloGioacchino Del Regno ha scritto:
Hello CK,
Gentle ping for this series.
Thanks,
Angelo
Changes in v3:
- Added DPTX AUX block initialization before trying to communicate
to stop relying on the bootloader keeping it initialized before
booting Linux.
- Fixed
On Wed, May 10, 2023 at 9:12 AM Pin-yen Lin wrote:
>
> +Jagan who worked on a similar design and initiated the thread.
>
> Hi Stephen,
>
> On Sat, Apr 29, 2023 at 12:47 PM Stephen Boyd wrote:
> >
> > Quoting Pin-yen Lin (2023-04-20 02:10:46)
> > > On Thu, Apr 20, 2023 at 2:10 PM Stephen Boyd wro
On Fri, May 12, 2023 at 1:30 AM Stephen Boyd wrote:
>
> Quoting Pin-yen Lin (2023-05-09 20:41:54)
> > On Sat, Apr 29, 2023 at 12:47 PM Stephen Boyd wrote:
> > >
> > > Good point. I'm suggesting to make the drm bridge chain into a tree. We
> > > need to teach drm_bridge core about a mux, and have
在 2023-05-29星期一的 18:28 +0200，Matthias Brugger写道：
>
>
> On 29/05/2023 10:45, Icenowy Zheng wrote:
> > 在 2023-05-29星期一的 10:02 +0200，AngeloGioacchino Del Regno写道：
> > > Il 26/05/23 16:24, Doug Anderson ha scritto:
> > > > Hi,
> > > >
> > > > On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng
> > > > wr
In resume, DP's launch function, ast_dp_launch, could wait at most 30
seconds before timeout to check if DP is enabled. It could lead to 'DPM
device timeout' and trigger unrecoverable kernel panic.
To avoid this problem, we check if DP enable or not at driver probe only.
Reported-and-tested-by: W
Hi,
On 2023/5/30 03:36, Sam Ravnborg wrote:
Hi Thomas,
On Wed, May 24, 2023 at 11:21:50AM +0200, Thomas Zimmermann wrote:
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
--
v1->v2:
- check wbrf support using pmfw version(Lijo)
v2->v3:
- some minor fixes(Mario)
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 61 +++
1 file changed, 61 insertions(+)
dif
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
--
v1->v2:
- check the wbrf support using pmfw version(Lijo)
v2->v3:
- some minor fixes(Mario)
---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 4 ++
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 3
To protect PMFW from being overloaded.
Signed-off-by: Evan Quan
--
v1->v2:
- utilize the delayed work(Lijo, Christian)
- split the new module parameter changes out(Christian, Alex)
v2->v3:
- simplify the flood detection further per latest design
v3->v4:
- drop unneeded wbrf_mutex(Lijo, Ch
With WBRF feature supported, as a driver responding to the frequencies,
amdgpu driver is able to do shadow pstate switching to mitigate possible
interference(between its (G-)DDR memory clocks and local radio module
frequency bands used by Wifi 6/6e/7).
To make WBRF feature functional, the kernel n
Add those data structures to support Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
--
v1->v2:
- update smu_v13_0_7_ppsmc.h to fit latest messages definitions
---
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +-
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h |
Qualcomm wifi adapters are utilized in systems that support AMD's WBRF
interference mitigation mechanism. For this mechanism to work frequencies
utilized use must be notified to an ACPI device.
If the kernel is configured with CONFIG_ACPI_WBRF then notify this ACPI
device accordingly.
Change base
From: Anson Tsao
Qualcomm wifi adapters are utilized in systems that support AMD's WBRF
interference mitigation mechanism. For this mechanism to work frequencies
utilized use must be notified to an ACPI device.
If the kernel is configured with CONFIG_ACPI_WBRF then notify this ACPI
device accord
From: Mario Limonciello
Mediatek wifi adapters are utilized in systems that support AMD's WBRF
interference mitigation mechanism. For this mechanism to work frequencies
utilized use must be notified to an ACPI device.
If the kernel is configured with CONFIG_ACPI_WBRF then notify this ACPI
device
From: Mario Limonciello
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced an
Due to electrical and mechanical constraints in certain platform designs there
may
be likely interference of relatively high-powered harmonics of the (G-)DDR
memory
clocks with local radio module frequency bands used by Wifi 6/6e/7. To mitigate
possible RFI interference producers can advertise th
Hi all,
On Tue, 30 May 2023 11:57:52 +1000 Stephen Rothwell
wrote:
>
> @@@ -920,33 -587,8 +640,9 @@@ static const struct intel_device_info j
> #define GEN12_FEATURES \
> GEN11_FEATURES, \
> GEN(12), \
> - .display.abox_mask = GENMASK(2, 1), \
> - .__runtime.pipe_mask = BIT(
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.h
between commit:
66ca1d8f222b ("drm/i915/i915_drv: Use i915 instead of dev_priv insied the
file_priv structure")
from the drm tree and commits:
5af5169d7582 ("drm/i915: Convert INTE
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_pci.c
between commit:
5e352e32aec2 ("drm/i915: preparation for using PAT index")
from the drm tree and commits:
5af5169d7582 ("drm/i915: Convert INTEL_INFO()->display to a pointer")
18e
https://bugzilla.kernel.org/show_bug.cgi?id=217499
Wessel (wessel.working+ker...@gmail.com) changed:
What|Removed |Added
Resolution|MOVED |ANSWERED
--
Y
On 24/05/2023 01:14, Melissa Wen wrote:
This series is a refined version of our RFC [1] for AMD driver-specific
color management properties. It is a collection of contributions from
Joshua, Harry and I to enhance AMD KMS color pipeline for Steam
Deck/SteamOS by exposing the large set of color cap
Replace all drm-shmem locks with a GEM reservation lock. This makes locks
consistent with dma-buf locking convention where importers are responsible
for holding reservation lock for all operations performed over dma-bufs,
preventing deadlock between dma-buf importers and exporters.
Suggested-by: D
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
Change locking policy of mmap() callback, making exporters responsible
for handling dma-buf reservation locking. Previous locking policy stated
that dma-buf is locked for both importers and exporters by the dma-buf
core, which caused a deadlock problem for DRM drivers in a case of
self-imported dma
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
This patchset makes dma-buf exporters responisble for taking care of
the reservation lock. I also included patch that moves drm-shmem to use
reservation lock, to let CI test the whole set. I'm going to take all
the patches via the drm-misc tree, please give an ack.
Previous policy stated that dma-
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
On 30/05/2023 01:37, Marijn Suijten wrote:
On 2023-05-30 01:18:40, Dmitry Baryshkov wrote:
+ret = mipi_dsi_dcs_set_display_on(dsi);
+if (ret < 0) {
+dev_err(dev, "Failed to turn display on: %d\n", ret);
+return ret;
+}
My usual question: should the mipi_dsi_dcs_exi
On 2023-05-30 01:18:40, Dmitry Baryshkov wrote:
> > +ret = mipi_dsi_dcs_set_display_on(dsi);
> > +if (ret < 0) {
> > +dev_err(dev, "Failed to turn display on: %d\n", ret);
> > +return ret;
> > +}
>
> My usual question: should the mipi_dsi_d
On 30/05/2023 00:11, Marijn Suijten wrote:
On 2023-05-22 04:16:20, Dmitry Baryshkov wrote:
+ if (ctx->dsi->dsc) {
dsi->dsc is always set, thus this condition can be dropped.
I want to leave room for possibly running the panel without DSC (at a
lower resolution/refresh rate, or at high
On 2023-05-30 01:20:17, Dmitry Baryshkov wrote:
> On 29/05/2023 23:58, Marijn Suijten wrote:
> > On 2023-05-23 01:56:46, Dmitry Baryshkov wrote:
> >> On Tue, 23 May 2023 at 01:32, Marijn Suijten
> >> wrote:
> >>>
> >>> On 2023-05-22 04:19:45, Dmitry Baryshkov wrote:
> On 22/05/2023 00:23, Mar
On 2023-05-30 01:22:54, Dmitry Baryshkov wrote:
> On 30/05/2023 00:29, Konrad Dybcio wrote:
> >
> >
> > On 29.05.2023 23:21, Marijn Suijten wrote:
> >> On 2023-05-22 11:08:12, Neil Armstrong wrote:
> >>> On 22/05/2023 03:23, Dmitry Baryshkov wrote:
> On 22/05/2023 00:23, Marijn Suijten wrote
On 30/05/2023 00:29, Konrad Dybcio wrote:
On 29.05.2023 23:21, Marijn Suijten wrote:
On 2023-05-22 11:08:12, Neil Armstrong wrote:
On 22/05/2023 03:23, Dmitry Baryshkov wrote:
On 22/05/2023 00:23, Marijn Suijten wrote:
The SOFEF03-M Display-IC paired with an unknown panel in the Sony Xperia
On 29/05/2023 23:58, Marijn Suijten wrote:
On 2023-05-23 01:56:46, Dmitry Baryshkov wrote:
On Tue, 23 May 2023 at 01:32, Marijn Suijten
wrote:
On 2023-05-22 04:19:45, Dmitry Baryshkov wrote:
On 22/05/2023 00:23, Marijn Suijten wrote:
This SOFEF01-M Display-IC driver supports two modes with
On 30/05/2023 00:07, Marijn Suijten wrote:
On 2023-05-22 15:58:56, Dmitry Baryshkov wrote:
On Mon, 22 May 2023 at 12:04, Neil Armstrong wrote:
On 22/05/2023 03:16, Dmitry Baryshkov wrote:
On 22/05/2023 00:23, Marijn Suijten wrote:
Sony provides an unlabeled LGD + Atmel maXTouch assembly in
On 30/05/2023 00:11, Marijn Suijten wrote:
On 2023-05-22 04:16:20, Dmitry Baryshkov wrote:
+ if (ctx->dsi->dsc) {
dsi->dsc is always set, thus this condition can be dropped.
I want to leave room for possibly running the panel without DSC (at a
lower resolution/refresh rate, or at high
On Tue, 30 May 2023 at 00:46, Marijn Suijten
wrote:
>
> On 2023-05-26 12:09:45, Dmitry Baryshkov wrote:
> > Currently the driver passes the PINGPONG index to
> > dpu_hw_intf_ops::bind_pingpong_blk() callback and uses separate boolean
> > flag to tell whether INTF should be bound or unbound. Simpli
On 5/22/23 16:02, Emil Velikov wrote:
>> -void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
>> +static int drm_gem_shmem_pin_locked(struct drm_gem_shmem_object *shmem)
>> +{
>> + int ret;
>> +
>> + dma_resv_assert_held(shmem->base.resv);
>> +
>> + ret = drm_gem_shme
On 2023-05-26 12:09:45, Dmitry Baryshkov wrote:
> Currently the driver passes the PINGPONG index to
> dpu_hw_intf_ops::bind_pingpong_blk() callback and uses separate boolean
> flag to tell whether INTF should be bound or unbound. Simplify this by
> passing PINGPONG_NONE in case of unbinding and dro
On 2023-05-24 12:18:09, Abhinav Kumar wrote:
>
>
> On 5/24/2023 2:48 AM, Marijn Suijten wrote:
> > On 2023-05-23 13:01:13, Abhinav Kumar wrote:
> >>
> >>
> >> On 5/21/2023 10:21 AM, Dmitry Baryshkov wrote:
> >>> Drop SSPP-specifig debugfs register dumps in favour of using
> >>> debugfs/dri/0/kms
On 29.05.2023 23:21, Marijn Suijten wrote:
> On 2023-05-22 11:08:12, Neil Armstrong wrote:
>> On 22/05/2023 03:23, Dmitry Baryshkov wrote:
>>> On 22/05/2023 00:23, Marijn Suijten wrote:
The SOFEF03-M Display-IC paired with an unknown panel in the Sony Xperia
5 II always uses Display St
On 2023-05-22 11:08:12, Neil Armstrong wrote:
> On 22/05/2023 03:23, Dmitry Baryshkov wrote:
> > On 22/05/2023 00:23, Marijn Suijten wrote:
> >> The SOFEF03-M Display-IC paired with an unknown panel in the Sony Xperia
> >> 5 II always uses Display Stream Compression 1.1 and features a 60hz and
> >>
On 2023-05-22 04:16:20, Dmitry Baryshkov wrote:
> > + if (ctx->dsi->dsc) {
>
> dsi->dsc is always set, thus this condition can be dropped.
I want to leave room for possibly running the panel without DSC (at a
lower resolution/refresh rate, or at higher power consumption if there
is enough BW)
On 2023-05-22 15:58:56, Dmitry Baryshkov wrote:
> On Mon, 22 May 2023 at 12:04, Neil Armstrong
> wrote:
> >
> > On 22/05/2023 03:16, Dmitry Baryshkov wrote:
> > > On 22/05/2023 00:23, Marijn Suijten wrote:
> > >> Sony provides an unlabeled LGD + Atmel maXTouch assembly in its Xperia
> > >> XZ3 (t
On 2023-05-23 01:56:46, Dmitry Baryshkov wrote:
> On Tue, 23 May 2023 at 01:32, Marijn Suijten
> wrote:
> >
> > On 2023-05-22 04:19:45, Dmitry Baryshkov wrote:
> > > On 22/05/2023 00:23, Marijn Suijten wrote:
> > > > This SOFEF01-M Display-IC driver supports two modes with different
> > > > compat
https://bugzilla.kernel.org/show_bug.cgi?id=217499
Wessel (wessel.working+ker...@gmail.com) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Hi Thomas,
On Wed, May 24, 2023 at 11:21:50AM +0200, Thomas Zimmermann wrote:
> Implement dedicated fbdev helpers for framebuffer I/O instead
> of using DRM's helpers. Use an fbdev generator macro for
> deferred I/O to create the fbdev callbacks. i915 was the only
> caller of the DRM helpers, so r
On Wed, May 24, 2023 at 11:21:48AM +0200, Thomas Zimmermann wrote:
> Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
> handle damage areas for fbdev emulation. This is a temporary export
> that allows to move the DRM I/O helpers for fbdev into drivers. Only
> fbdev-generic and
Hi Thomas.
> v4:
> * use initializer and generator macros for struct fb_ops
> * partially support damage handling in msm (Dmitri)
I like the macros. They make it simpler and we do not spread the _cfb_
misname to more files.
> v3:
> * fix Kconfig options (Jingfeng)
> * mi
Hi Thomas,
On Wed, May 24, 2023 at 11:21:50AM +0200, Thomas Zimmermann wrote:
> Implement dedicated fbdev helpers for framebuffer I/O instead
> of using DRM's helpers. Use an fbdev generator macro for
> deferred I/O to create the fbdev callbacks. i915 was the only
> caller of the DRM helpers, so r
On Wed, May 24, 2023 at 11:21:40AM +0200, Thomas Zimmermann wrote:
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> helpers. Armada does not use damage handling, so DRM's fbdev helpers
> are mere wrappers around the fbdev code.
>
> By using fbdev helpers directly within each
On Wed, May 24, 2023 at 11:21:39AM +0200, Thomas Zimmermann wrote:
> For framebuffers in I/O and system memory, add macros that set
> struct fb_ops to the respective callback functions.
>
> For deferred I/O, add macros that generate callback functions with
> damage handling. Add initializer macros
Hi Thomas,
On Wed, May 24, 2023 at 11:21:38AM +0200, Thomas Zimmermann wrote:
> Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
> options to select them at once. This will help with making DRM's
> fbdev emulation code more modular, but can also be used to simplify
> fbdev's driv
On Mon, May 29, 2023 at 11:43:58AM +0200, Luca Weiss wrote:
> The MSM8226 SoC uses a slightly different 28nm dsi phy. Add a new
> compatible for it.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml | 1 +
> Documentation/devicetree/bindings/di
On Mon, May 29, 2023 at 11:44:00AM +0200, Luca Weiss wrote:
> Add the compatible for the MDP5 found on MSM8226.
>
> Signed-off-by: Luca Weiss
Acked-by: Conor Dooley
Thanks,
Conor.
signature.asc
Description: PGP signature
On Mon, May 29, 2023 at 11:43:59AM +0200, Luca Weiss wrote:
> Add the compatible for the DSI found on MSM8226.
>
> Signed-off-by: Luca Weiss
Acked-by: Conor Dooley
Thanks,
Conor.
signature.asc
Description: PGP signature
This patch adds PCI driver support on top of what already have. Take the
GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device driver.
There is only one GPU core for the GC1000 in the LS7A1000 and LS2K1000.
Therefore, component frameworks can be avoided. Because we want to bind the
DR
struct etnaviv_drm_private contains a lot of common resources that are
shared by all GPUs. This patch introduces two dedicated functions, which
is for the construction and destruction of instances of this structure.
The idea is to avoid leaking its members outside. The error handling code
can
Because getting IRQ from a device is platform-dependent, PCI devices have
different methods for getting an IRQ. This patch is a preparation patch to
extend support for the PCI device.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 34 ---
1 file c
There is a Vivante GC1000 (v5037) in LS2K1000 and LS7A1000, this GPU is a
PCI device, and it has 2D and 3D cores in the same device. Thus, this patch
series is trying to add PCI device driver support to etnaviv.
Sui Jingfeng (6):
drm/etnaviv: add a dedicated function to register an irq handler
cached system RAM is coherent on loongson CPUs, and the GPU and DC allways
snoop the CPU's cache. write-combine caching property is not suitiable for
us.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 22
Also rename the virtual master platform device as etnaviv_platform_device,
for better reflection that it is a platform device, not a DRM device.
Another benefit is that we no longer need to call of_node_put() for three
different cases, Instead, we only need to call it once.
Signed-off-by: Sui Jin
Because it is also platform-dependent, there are environments where don't
have CLK subsystem support, for example, discreted PCI gpu. So don't rage
quit if there is no CLK subsystem.
For the GPU in LS7a1000 and LS2k2000, the working frequency of the GPU is
tuned by configuring the PLL register dir
struct etnaviv_drm_private contains a lot of common resources that are
shared by all GPUs. This patch introduces two dedicated functions, which
is for the construction and destruction of instances of this structure.
The idea is to avoid leaking its members outside. The error handling code
can
Because it is also platform-dependent, there are environments where don't
have CLK subsystem support, for example, discreted PCI gpu. So don't rage
quit if there is no CLK subsystem.
For the GPU in LS7a1000 and LS2k2000, the working frequency of the GPU is
tuned by configuring the PLL register dir
Also rename the virtual master platform device as etnaviv_platform_device,
for better reflection that it is a platform device, not a DRM device.
Another benefit is that we no longer need to call of_node_put() for three
different cases, Instead, we only need to call it once.
Signed-off-by: Sui Jin
There is a Vivante GC1000 (v5037) in LS2K1000 and LS7A1000, this GPU is a
PCI device, and it has 2D and 3D cores in the same device. Thus, this
series is trying to add PCI device driver support to etnaviv.
Sui Jingfeng (6):
drm/etnaviv: add a dedicated function to register an irq handler
drm/e
This patch adds PCI driver support on top of what already have. Take the
GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device driver.
There is only one GPU core for the GC1000 in the LS7A1000 and LS2K1000.
Therefore, component frameworks can be avoided. Because we want to bind the
DR
Because getting IRQ from a device is platform-dependent, PCI devices have
different methods for getting an IRQ. This patch is a preparation patch to
extend support for the PCI device.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 34 ---
1 file c
On 29/05/2023 10:45, Icenowy Zheng wrote:
在 2023-05-29星期一的 10:02 +0200，AngeloGioacchino Del Regno写道：
Il 26/05/23 16:24, Doug Anderson ha scritto:
Hi,
On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng
wrote:
Currently a specific panel number is used in the Elm DTSI, which
is
corresponded to a
The vga_is_firmware_default() function will work on non-x86 architectures
as long as the arch has UEFI GOP support, which passes the firmware
framebuffer base address and size.
This patch makes the vga_is_firmware_default() function arch-independent.
This could help the VGAARB subsystem make the r
On Mon, May 29, 2023 at 02:22:06PM +, Biju Das wrote:
> HI Laurent,
>
> Thanks for the feedback.
>
> > Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display
> > Unit support
> >
> > Hi Biju,
> >
> > On Thu, May 25, 2023 at 02:30:10PM +, Biju Das wrote:
> > > Hi DRM mai
Hi Biju,
Thank you for the patch.
This is a partial review, because the driver is big, and because some
changes in v10 will (hopefully) simplify the code and make review
easier.
On Tue, May 02, 2023 at 11:09:11AM +0100, Biju Das wrote:
> The LCD controller is composed of Frame Compression Proces
Add the DPI1 hdmi path support in mtk dpi driver
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 121 ++--
drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 5 ++
2 files changed, 119 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm
Create a common "framework" that can be used to add support for
different hdmi IPs within the mediatek range of products.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_hdmi.c| 596 ++---
driv
Add dt-binding documentation of dpi for MediaTek MT8195 SoC.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Guillaume Ranquet
---
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/med
Add HDMI audio support for v2
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 1 +
drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 198 +
drivers/gpu/drm/mediatek/mtk_hdmi_v2.h | 4 +-
3 files changed, 202 insertions(+), 1 deleti
Adds hdmi and hdmi-ddc support for v2 IP.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/Kconfig|2 +
drivers/gpu/drm/mediatek/Makefile |2 +
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 13 +
drivers/gpu/drm/mediatek/mtk_hdmi_common.h |1 +
d
Add mt8195 SoC bindings for hdmi and hdmi-ddc
On mt8195 the ddc i2c controller is part of the hdmi IP block and thus has no
specific register range, power domain or interrupt, making it simpler
than the legacy "mediatek,hdmi-ddc" binding.
Signed-off-by: Guillaume Ranquet
---
.../bindings/displa
To prepare support for newer chips that need to share their address
range with a dedicated ddc driver, use a regmap.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 173 ++--
1 file changed, 65 insertions(+), 108 deletions(-)
diff --git
Make cec device optional in order to support newer versions of the
hdmi IP which doesn't require it
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_hdmi.c| 8 +++--
drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 52 +++---
2 files changed, 39 inse
Add support for HDMI Tx on MT8195.
This includes a split of the current "legacy" hdmi driver into a common
library of functions and two dedicated compilation units with specific
code for mt8167 and another for the "v2" mt8195 SoC.
Support for the new mt8195 dpi/drm_drv adjustments to support hdmi
HI Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v9 RESEND 0/5] Add RZ/{G2L,G2LC} and RZ/V2L Display
> Unit support
>
> Hi Biju,
>
> On Thu, May 25, 2023 at 02:30:10PM +, Biju Das wrote:
> > Hi DRM maintainers,
> >
> > Gentle ping.
>
> Sorry, I was on holidays the last two weeks.
Hi Biju,
On Thu, May 25, 2023 at 02:30:10PM +, Biju Das wrote:
> Hi DRM maintainers,
>
> Gentle ping.
Sorry, I was on holidays the last two weeks.
> Are we happy with moving all Renesas drm drivers to Renesas specific
> directory or preference is for separate one??
This works for me.
> If
On Fri, May 26, 2023 at 3:05 PM Philippe CORNU
wrote:
>
>
>
> On 5/19/23 22:05, Alexandru Ardelean wrote:
> > From: Yannick Fertre
> >
> > Add documentation for new default-brightness-level property.
> >
> > Reviewed-by: Philippe CORNU
>
> Hi Alexandru,
> same comments as for the 1/2 patch.
Ack
On Fri, May 26, 2023 at 1:20 PM Daniel Thompson
wrote:
>
> On Fri, May 19, 2023 at 11:05:20PM +0300, Alexandru Ardelean wrote:
> > From: Yannick Fertre
> >
> > Add documentation for new default-brightness-level property.
> >
> > Reviewed-by: Philippe CORNU
> > Signed-off-by: Yannick Fertre
> >
On Fri, May 26, 2023 at 3:04 PM Philippe CORNU
wrote:
>
>
> On 5/19/23 22:05, Alexandru Ardelean wrote:
> > From: Yannick Fertre
> >
> > Add new property to set a brightness by default at probe.
> >
> > Reviewed-by: Philippe CORNU
>
> Hi Alexandru,
>
> Many thanks for your patch.
>
> You have se
Hi!
I think we have a serious kernel bug that is related to or inside in
drivers/gpu/drm/ttm/ttm_bo.c
The reason for my assumptions lies in one of my recent system freezes
with kernel 6.3.4 that go along with massive kernel error logs in
journalctl. An extract from the logs:
...
May 28 14:
Hi Chun-Kuang Hu,
Can you help to merge the missing DT-binding patches in this series?
Thanks a lot,
Matthias
On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:
Add a compatible string for the MediaTek Helio X10 MT6795 SoC, using
the same parameters as MT8183.
Signed-off-by: AngeloGioacch
On 14/04/2023 10:22, Krzysztof Kozlowski wrote:
On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:
Add a compatible string for MediaTek Helio X10 MT6795: this SoC uses
the same DSI PHY as MT8173.
Signed-off-by: AngeloGioacchino Del Regno
---
Documentation/devicetree/bindings/phy/medi
Hi Laurent,
> Subject: Re: [PATCH v9 RESEND 2/5] dt-bindings: display: Document
> Renesas RZ/G2L DU bindings
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Tue, May 02, 2023 at 11:09:09AM +0100, Biju Das wrote:
> > The RZ/G2L LCD controller is composed of Frame Compression Processor
> > (FCPV
On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:
Configure and enable the MMC0/1/2 controllers, used for the eMMC chip,
MicroSD card slot and SDIO (WiFi) respectively.
Signed-off-by: AngeloGioacchino Del Regno
Applied, thanks
---
.../dts/mediatek/mt6795-sony-xperia-m5.dts| 9
On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:
This smartphone uses the Helio X10 standard MT6331+MT6332 combo PMICs:
include the mt6331 devicetree and add the required interrupt.
Note that despite there being two interrupts, one for MT6331 and one
for MT6332, in configurations using
On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:
MT6331 is the primary PMIC for the MediaTek Helio X10 MT6795 smartphone
platforms: add a devicetree describing its regulators, Real Time Clock
and PMIC-keys.
Signed-off-by: AngeloGioacchino Del Regno
Applied, thanks
---
arch/arm6
On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:
Add the pwrap node: this is used to communicate with the PMIC(s).
Signed-off-by: AngeloGioacchino Del Regno
Applied thanks!
---
arch/arm64/boot/dts/mediatek/mt6795.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --g
On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:
Add nodes for the multimedia IOMMU and its LARBs: this includes all but
the MJC LARB, which cannot currently be used and will be added later.
Signed-off-by: AngeloGioacchino Del Regno
Applied, thanks
---
arch/arm64/boot/dts/mediat
On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:
Add the MultiMedia System node, providing clocks for the multimedia
hardware blocks and their IOMMU/SMIs.
Signed-off-by: AngeloGioacchino Del Regno
Applied, thanks
---
arch/arm64/boot/dts/mediatek/mt6795.dtsi | 13 +
On 12/04/2023 13:27, AngeloGioacchino Del Regno wrote:
In preparation for adding multimedia blocks, add the CMDQ/GCE mailbox.
Signed-off-by: AngeloGioacchino Del Regno
Applied, thanks
---
arch/arm64/boot/dts/mediatek/mt6795.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff
A610 is one of (if not the) lowest-tier SKUs in the A6XX family. It
features no GMU, as it's implemented solely on SoCs with SMD_RPM.
What's more interesting is that it does not feature a VDDGX line
either, being powered solely by VDDCX and has an unfortunate hardware
quirk that makes its reset lin
1 - 100 of 171 matches
Mail list logo
