Hi Boris,
Am 27.10.23 um 12:17 schrieb Boris Brezillon:
Hi Christian,
On Fri, 27 Oct 2023 11:06:44 +0200
Christian König wrote:
Am 27.10.23 um 10:22 schrieb Boris Brezillon:
On Fri, 27 Oct 2023 09:44:13 +0200
Christian König wrote:
Am 27.10.23 um 09:39 schrieb Boris Brezillon:
On Fri,
Am 27.10.23 um 18:58 schrieb Rob Clark:
From: Rob Clark
In cases where the # is known ahead of time, it is silly to do the table
resize dance.
Ah, yes that was my initial implementation as well, but I ditched that
because nobody actually used it.
One comment below.
Signed-off-by: Rob Cl
Many of these registers have a known name in the public datasheet.
Document them as comments for reference.
Signed-off-by: John Watts
Reviewed-by: Jessica Zhang
---
.../gpu/drm/panel/panel-newvision-nv3052c.c | 261 +-
1 file changed, 132 insertions(+), 129 deletions(-)
diff
This display is extremely similar to the LTK035C5444T, but still has
some minor variations in panel initialization.
Signed-off-by: John Watts
Reviewed-by: Jessica Zhang
---
.../gpu/drm/panel/panel-newvision-nv3052c.c | 223 ++
1 file changed, 223 insertions(+)
diff --git a/dr
This is a small 3.5" 640x480 IPS LCD panel.
Signed-off-by: John Watts
Reviewed-by: Rob Herring
---
.../display/panel/fascontek,fs035vg158.yaml | 56 +++
1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.y
Fascontek manufactures LCD panels such as the FS035VG158.
Signed-off-by: John Watts
Acked-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentat
Hello there,
This RFC introduces support for the FS035VG158 LCD panel, cleaning up
the nv3052c driver on the way and documentating existing panel code.
This patch series is at a bit of a standstill: I have gotten feedback
that it should instead use the Leadtek LTK035C5444T panel init sequence
ins
SPI drivers needs their own list of compatible device IDs in order
for automatic module loading to work. Add those for this driver.
Signed-off-by: John Watts
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/panel/panel-newvision-nv3052c.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a
Remove common properties listed in common yaml files.
Add required properties needed to describe the panel.
Signed-off-by: John Watts
Reviewed-by: Rob Herring
---
.../bindings/display/panel/leadtek,ltk035c5444t.yaml | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git
Panel initialization registers are per-display and not tied to the
controller itself. Different panels will specify their own registers.
Attach the sequences to the panel info struct so future panels
can specify their own sequences.
Signed-off-by: John Watts
---
.../gpu/drm/panel/panel-newvision
On Mon, Oct 23, 2023 at 09:24:33PM +0300, Dmitry Baryshkov wrote:
> On 15 September 2023 15:14:35 EEST, Heikki Krogerus
> wrote:
> >Hi Dmitry,
> >
> >On Mon, Sep 04, 2023 at 12:41:50AM +0300, Dmitry Baryshkov wrote:
> >> In order to notify the userspace about the DRM connector's USB-C port,
> >>
On 10/27/2023 1:17 PM, Yong Wu (吴勇) wrote:
> On Thu, 2023-10-26 at 10:18 +0530, Vijayanand Jitta wrote:
>>
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>>
>>
>> On 10/20/2023 3:29 PM, Yong Wu (吴勇) wrote:
>>> On T
This series includes patches to update the V3D kernel module
that drives the VideoCore VI GPU in Raspberry Pi 4 to also support
the Video Core VII iteration present in Raspberry Pi 5.
The first patch in the series adds a small uAPI update required for
TFU jobs, the second patch addresses the bulk
V3D 7.x takes a new parameter to configure TFU jobs that needs
to be provided by user space.
v2: added s-o-b, fixed typo in commit message (Maíra Canal)
Signed-off-by: Iago Toral Quiroga
---
include/uapi/drm/v3d_drm.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/drm/v3d
BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So add its specific
compatible to the bindings.
v2: new, requested by Stefan Wahren.
Signed-off-by: Iago Toral Quiroga
---
Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentatio
This patch updates a number of register addresses that have
been changed in Raspberry Pi 5 (V3D 7.1) and updates the
code to use the corresponding registers and addresses based
on the actual V3D version.
v2:
- added s-o-b and commit message. (Maíra Canal)
- Used macro that takes version as argum
This is required to get the V3D module to load with Raspberry Pi 5.
v2:
- added s-o-b and commit message. (Maíra)
- keep order of compatible strings. (Stefan Wahren)
Signed-off-by: Iago Toral Quiroga
---
drivers/gpu/drm/v3d/v3d_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
Hello!
On 10/30/23 1:53 AM, Sasha Levin wrote:
> From: Sergey Shtylyov
>
> [ Upstream commit 7f33df94cf0156f64eee9509bd9b4a178990f613 ]
>
> In cfb_copyarea(), the local variable bits_per_line is needlessly typed as
> *unsigned long* -- which is a 32-bit type on the 32-bit arches and a 64-bit
>
On 10/30/23 1:53 AM, Sasha Levin wrote:
> From: Sergey Shtylyov
>
> [ Upstream commit e8e4a470b677511f9d1ad4f3cef32adc1d9a60ca ]
>
> In sys_copyarea(), the local variable bits_per_line is needlessly typed as
> *unsigned long* -- which is a 32-bit type on the 32-bit arches and a 64-bit
> type on
Hi,
On 2023/10/30 07:19, Dmitry Baryshkov wrote:
On Sun, 29 Oct 2023 at 21:46, Sui Jingfeng wrote:
Due to the fact that the same display IP core has been integrated into
different platform, there is a need to differentiate them on the runtime.
The DC in LS7A1000/LS2K1000 has the PCI vendor & d
Hi,
On 2023/10/30 12:13, Sui Jingfeng wrote:
handle them one by one.
It is actually to review and understand.
Handle the cases one by one.
It is actually more easier to review the untangled code.
It is also more easier to edit and maintain.
We have started printing more and more intentional stack traces. Whether
it's testing KASAN is able to detect use after frees or it's part of a
kunit test.
These stack traces can be problematic. They suddenly show up as a new
failure. Now the test team has to contact the developers. A bunch of
This commit is based on 20231024130048.14749-1-shawn.s...@mediatek.com.
This bug is found when running IGT tests.
For CRTCs that doesn't support rotation should still return
DRM_MODE_ROTATE_0. Returns the hardware capabilities accordingly.
Changes in v2:
- Restore DRM_MODE_ROTATE_180 (reflect x +
For CRTCs that doesn't support rotation should still return
DRM_MODE_ROTATE_0. Returns hardware capabilities accordingly.
Fixes: 84d805753983 ("drm/mediatek: Support reflect-y plane rotation")
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek
Hi,
On 2023/10/30 07:10, Dmitry Baryshkov wrote:
+
+static void lsdc_pipe1_hdmi_encoder_reset(struct drm_encoder *encoder)
+{
+ struct drm_device *ddev = encoder->dev;
+ struct lsdc_device *ldev = to_lsdc(ddev);
+ u32 val;
+
+ val = PHY_CLOCK_POL | PHY_CLOCK_EN | PHY_DAT
Hi, Ville & all
Thanks for quick reply!
According to your reply, the *info has been checked info earlier, and I have
read the code of framebuffer_check() and related drm_get_format_info() which it
calls, but unfortunatelly, I haven't seen judgement(check) for it. What I only
found related with
On Mon, 30 Oct 2023 at 06:13, Sui Jingfeng wrote:
>
> Hi,
>
>
> On 2023/10/30 07:10, Dmitry Baryshkov wrote:
> >> +
> >> +/* Built-in HDMI encoder funcs on display pipe 0 */
> >> +
> >> +static void lsdc_pipe0_hdmi_encoder_reset(struct drm_encoder *encoder)
> >> +{
> >> + struct drm_device *
Hi, Ville & all
Thanks for quick reply!
According to your reply, the *info has been checked info earlier, and I have
read the code of framebuffer_check() and related drm_get_format_info() which it
calls, but unfortunatelly, I haven't seen judgement(check) for it. What I only
found related with
> -Original Message-
> From: Manna, Animesh
> Sent: Tuesday, October 17, 2023 1:52 PM
> To: Murthy, Arun R ; intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Hogander, Jouni
> ; Nikula, Jani
> Subject: RE: [PATCH v7 4/6] drm/i915/panelreplay: Enable panel replay dp
> -Original Message-
> From: Manna, Animesh
> Sent: Wednesday, October 11, 2023 4:40 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Manna, Animesh
> ; Hogander, Jouni ;
> Murthy, Arun R ; Nikula, Jani
>
> Subject: [PATCH v7 6/6] drm/i915/panelreplay: Deb
According to your(Villie) reply, the *info has been checked info earlier, and I
have read the code of framebuffer_check() and related drm_get_format_info()
which it calls, but unfortunatelly, I haven't seen judgement(check) for it.
What I only found related with check is the sentence below (in
Hi,
On 2023/10/30 06:53, Dmitry Baryshkov wrote:
On Sun, 29 Oct 2023 at 21:46, Sui Jingfeng wrote:
The IT66121 is a DVO to HDMI converter, LS3A5000+LS7A1000 ML5A_MB use this
chip to support HDMI output. Thus add a drm bridge based driver for it.
This patch is developed with drivers/gpu/drm/br
On Mon, 30 Oct 2023 at 10:19, Heikki Krogerus
wrote:
>
> On Mon, Oct 23, 2023 at 09:24:33PM +0300, Dmitry Baryshkov wrote:
> > On 15 September 2023 15:14:35 EEST, Heikki Krogerus
> > wrote:
> > >Hi Dmitry,
> > >
> > >On Mon, Sep 04, 2023 at 12:41:50AM +0300, Dmitry Baryshkov wrote:
> > >> In ord
Currently, tha ast-driver just maps the PCI-dev's regions with
pcim_iomap(). It does not actually reserve the regions exclusively
with, e.g., pci_request_regions().
Replace the calls to pcim_iomap() with ones to pcim_iomap_regions() to
reserve and map the regions simultaneously.
Suggested-by: Tho
Changes since v7:
- Rebase on linux-next.
- Dependent dtsi files:
https://patchwork.kernel.org/project/linux-mediatek/list/?series=797543
- Depends on:
Message ID = 20231024130048.14749-9-shawn.s...@mediatek.com
- Correct the bindings of the four components: FG, TCC, TDSHP and HDR.
The names
Added the configuration for MT8195 RDMA. In comparison to MT8183, it
no longer shares SRAM with RSZ, and there are now preconfigured 5 mbox.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
---
.../bindings/media/mediatek,mdp3-rdma.yaml| 26 ++-
1 file change
MT8195 RSZ inherited from MT8183, add the corresponding
compatible name to it.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/media/mediatek,mdp3-rsz.yaml| 6 +-
1 file changed, 5 insertions(+), 1 deletion(
Add a compatible string for the PADDING block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
---
.../bindings/display/mediatek/mediatek,padding.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display
Add the fundamental hardware configuration of component HDR,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/media/mediatek,mdp3-hdr.yaml | 61 +++
1 file changed, 61 i
Add the fundamental hardware configuration of component FG,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/media/mediatek,mdp3-fg.yaml | 61 +++
1 file changed, 61 in
To simplify maintenance and avoid branches, the identical component
should be merged and placed in the path belonging to the MDP
(from display/* to media/*).
In addition, currently only MDP utilizes RDMA through CMDQ, and the
necessary properties for "mediatek,gce-events", and "mboxes" have been
s
Add a compatible string for the OVL block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 +
1 file changed, 1 insertion(+)
di
The DMA-related nodes RDMA/WROT in MDP3 should be changed to generic names.
In addition, fix improper space indent in example.
Fixes: 4ad7b39623ab ("media: dt-binding: mediatek: add bindings for MediaTek
MDP3 components")
Signed-off-by: Moudy Ho
Acked-by: Rob Herring
Reviewed-by: AngeloGioacchi
MT8195 WROT inherited from MT8183, add the corresponding
compatible name to it.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/media/mediatek,mdp3-wrot.yaml | 6 +-
1 file changed, 5 insertions(+), 1 deletion
Add the fundamental hardware configuration of component TDSHP,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/media/mediatek,mdp3-tdshp.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Docume
Add the fundamental hardware configuration of component TCC,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/media/mediatek,mdp3-tcc.yaml | 62 +++
1 file changed, 62 i
Add a compatible string for the COLOR block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 +
1 file changed, 1 insertion(+)
Add a compatible string for the MERGE block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 1 +
1 file changed, 1 insertion(+)
Add compatible string and GCE property for MT8195 SPLIT, of
which is operated by MDP3.
Signed-off-by: Moudy Ho
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: AngeloGioacchino Del Regno
---
.../display/mediatek/mediatek,split.yaml | 27 +++
1 file changed, 27 insertions(+)
Add a compatible string for the AAL block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
Acked-by: Conor Dooley
Reviewed-by: AngeloGioacchino Del Regno
---
.../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
1 file changed, 1 insertion(+)
diff --gi
Add the fundamental hardware configuration of component STITCH,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/media/mediatek,mdp3-stitch.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Docum
On Mon, 30 Oct 2023 at 11:42, Sui Jingfeng wrote:
>
> Hi,
>
>
> On 2023/10/30 06:53, Dmitry Baryshkov wrote:
> > On Sun, 29 Oct 2023 at 21:46, Sui Jingfeng wrote:
> >> The IT66121 is a DVO to HDMI converter, LS3A5000+LS7A1000 ML5A_MB use this
> >> chip to support HDMI output. Thus add a drm bridg
Javier Martinez Canillas writes:
> Rob Herring writes:
>
> Hello Rob,
>
[...]
>>> Pushed to drm-misc (drm-misc-next). Thanks!
>>
>> Given what introduced this is before the drm-misc-next-2023-10-19 tag,
>> isn't it going into 6.7 and needs to be in the fixes branch? Though that
>> doesn't ex
On Sat, Oct 28, 2023 at 03:34:04PM +0200, Stanislaw Gruszka wrote:
> Various driver updates:
>
> - FW api update
> - suspend/resume optimizations
> - dynamic valtage and frequency mode knob
> - new test modes
>
> v2:
> - fix spelling mistakes pointed Jeffrey
> - move patch 7, add note whe
On Monday, October 30th, 2023 at 10:47, Dmitry Baryshkov
wrote:
> On Mon, 30 Oct 2023 at 10:19, Heikki Krogerus
> heikki.kroge...@linux.intel.com wrote:
>
> > On Mon, Oct 23, 2023 at 09:24:33PM +0300, Dmitry Baryshkov wrote:
> >
> > > On 15 September 2023 15:14:35 EEST, Heikki Krogerus
> > >
Hi,
On Mon, Oct 30, 2023 at 05:42:28PM +0800, Sui Jingfeng wrote:
> On 2023/10/30 06:53, Dmitry Baryshkov wrote:
> > On Sun, 29 Oct 2023 at 21:46, Sui Jingfeng wrote:
> > > The IT66121 is a DVO to HDMI converter, LS3A5000+LS7A1000 ML5A_MB use this
> > > chip to support HDMI output. Thus add a drm
Hi Stefan,
El lun, 30-10-2023 a las 10:58 +0100, Stefan Wahren escribió:
> Hi Iago,
>
> Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
> > This patch updates a number of register addresses that have
> > been changed in Raspberry Pi 5 (V3D 7.1) and updates the
> > code to use the corresponding r
El lun, 30-10-2023 a las 10:57 +0100, Stefan Wahren escribió:
> Hi Iago,
>
> Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
> > BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So add its
> > specific
> > compatible to the bindings.
> >
> > v2: new, requested by Stefan Wahren.
> Thanks for s
On Mon, 30 Oct 2023 at 12:13, Simon Ser wrote:
>
> On Monday, October 30th, 2023 at 10:47, Dmitry Baryshkov
> wrote:
>
> > On Mon, 30 Oct 2023 at 10:19, Heikki Krogerus
> > heikki.kroge...@linux.intel.com wrote:
> >
> > > On Mon, Oct 23, 2023 at 09:24:33PM +0300, Dmitry Baryshkov wrote:
> > >
>
Cairo always uses native byte order for rendering.
Hence if the byte order of the frame buffer differs from the byte order
of the CPU, the frame buffer contents need to be byteswapped twice: once
before rendering, to convert to native byte order, and a second time
after rendering, to restore the f
Add support for drawing the SMPTE and tiles test patterns in buffers
using big-endian formats.
For now this is limited to XRGB1555 and RGB565, which are the most
common big-endian formats.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Dmitry Baryshkov
---
v5:
- Add Reviewed-by,
v4:
- No c
DRM formats are defined to be little-endian, unless the
DRM_FORMAT_BIG_ENDIAN flag is set. Hence writes of multi-byte pixel
values need to take endianness into account.
Introduce a swap32() helper to byteswap 32-bit values, and a
cpu_to_le32() helper to convert 32-bit values from CPU-endian to
li
When specifying a frame buffer format like "RG16_BE" (big-endian RG16),
modetest still uses the little-endian variant, as the format string is
truncated to four characters.
Fix this by increasing the format string size to 8 bytes (7 characters +
NUL terminator).
Signed-off-by: Geert Uytterhoeven
The endianness of the target is currently determined based on
preprocessor symbols. Unfortunately some symbols checked are wrong
(sparc64-linux-gnu-gcc does not define __BIG_ENDIAN__ or SPARC), and
several checks for big-endian architectures are missing.
Fix this by introducing a new preprocessor
DRM formats are defined to be little-endian, unless the
DRM_FORMAT_BIG_ENDIAN flag is set. Hence writes of multi-byte pixel
values need to take endianness into account.
Introduce a swap16() helper to byteswap 16-bit values, and a
cpu_to_le16() helper to convert 16-bit values from CPU-endian to
li
Hi all,
This patch series fixes some endianness issues in libdrm.
It has been tested on ARAnyM using a work-in-progress Atari DRM driver.
After this, the smpte and tiles modetest patterns and the pwetty markers
are rendered correctly using the XR24, RG16, and RG16BE formats on
big-endian s
Add support for rendering the crosshairs in a buffer using the
big-endian RGB565 format.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Dmitry Baryshkov
---
v5:
- Add Reviewed-by,
v4:
- No changes,
v3:
- No changes,
v2:
- New.
---
tests/util/pattern.c | 1 +
1 file changed, 1 inserti
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Dmitry Baryshkov
---
v5:
- Add Reviewed-by,
v4:
- No changes,
v3:
- Update for suffix change from "be" to "_BE", cfr. commit
ffb9375a505700ad ("xf86drm: handle DRM_FORMAT_BIG_ENDIAN in
drmGetFormatName()"),
v2:
- New.
---
tests/ut
Add support for creating buffers using big-endian formats.
For now this is limited to XRGB1555 and RGB565, which are the most
common big-endian formats.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Dmitry Baryshkov
---
v5:
- Add Reviewed-by,
v4:
- No changes,
v3:
- No changes,
v2:
On Monday, October 30th, 2023 at 11:22, Dmitry Baryshkov
wrote:
> On Mon, 30 Oct 2023 at 12:13, Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, October 30th, 2023 at 10:47, Dmitry Baryshkov
> > dmitry.barysh...@linaro.org wrote:
> >
> > > On Mon, 30 Oct 2023 at 10:19, Heikki Krogerus
>
El lun, 30-10-2023 a las 11:28 +0100, Stefan Wahren escribió:
> Hi Iago,
>
> Am 30.10.23 um 11:14 schrieb Iago Toral:
> > Hi Stefan,
> >
> > El lun, 30-10-2023 a las 10:58 +0100, Stefan Wahren escribió:
> > > Hi Iago,
> > >
> > > Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
> > > > This patc
The SM8650 MDSS is very close from the MDSS 9.0.0 found
on the SM8550 SoC, with the following difference:
- DSI PHY 2.8.8, no significant differences
- DPU 10.0.0:
- Enhanced max_linewidth to 8k
- PINGPONG_8 & PINGPONG_9
- MERGE_3D_4
- DSC_4 & DSC_5, DSC_NATIVE_42x on DSC0/1
This patchset
Document the DSI PHY on the SM8650 Platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Neil Armstrong
---
Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
b/Do
Document the DSI Controller on the SM8650 Platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Neil Armstrong
---
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-
Document the Mobile Display Subsystem (MDSS) on the SM8650 Platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Neil Armstrong
---
.../bindings/display/msm/qcom,sm8650-mdss.yaml | 322 +
1 file changed, 322 insertions(+)
diff --git
a/Documentation/devicetree/bindi
Add DSI Controller version 2.8.0 support for the SM8650 platform.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 17 +
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/m
Add DPU version 10.0 support for the SM8650 platform.
Signed-off-by: Neil Armstrong
---
.../drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h| 457 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 26 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
drivers
Add DSI PHY support for the SM8650 platform.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 27 +++
3 files c
Document the DPU Display Controller on the SM8650 Platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Neil Armstrong
---
.../bindings/display/msm/qcom,sm8650-dpu.yaml | 127 +
1 file changed, 127 insertions(+)
diff --git a/Documentation/devicetree/bindings/displa
Add Mobile Display Subsystem (MDSS) support for the SM8650 platform.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/msm_mdss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 6865db1e3
On 2023-10-25 10:43, Maxime Ripard wrote:
> Hi,
>
> On Tue, Oct 24, 2023 at 07:14:25PM +0200, Marco Pagani wrote:
+static void drm_gem_shmem_test_obj_create_private(struct kunit *test)
+{
+ struct fake_dev *fdev = test->priv;
+ struct drm_gem_shmem_object *shmem;
+ s
On 30/10/2023 13:12, Julia Lawall wrote:
>
>
> On Mon, 30 Oct 2023, Bagas Sanjaya wrote:
>
>> Hi Julia,
>>
>> The submitter touched one of CI scripts for the DRM subsystem. To test
>> this patch, there must be a way to run these scripts locally (which
>> may requires non-trivial setup).
>>
>> Cc
Hi Iago,
Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
This is required to get the V3D module to load with Raspberry Pi 5.
v2:
- added s-o-b and commit message. (Maíra)
- keep order of compatible strings. (Stefan Wahren)
as in the other patch, please move the changelog below --- or in t
Hi Iago,
Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
This patch updates a number of register addresses that have
been changed in Raspberry Pi 5 (V3D 7.1) and updates the
code to use the corresponding registers and addresses based
on the actual V3D version.
v2:
- added s-o-b and commit me
Hi Iago,
Am 30.10.23 um 11:14 schrieb Iago Toral:
Hi Stefan,
El lun, 30-10-2023 a las 10:58 +0100, Stefan Wahren escribió:
Hi Iago,
Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
This patch updates a number of register addresses that have
been changed in Raspberry Pi 5 (V3D 7.1) and update
On 06.06.23 10:21, Aradhya Bhatia wrote:
> With the new encoder/bridge chain model, the display controller driver
> is required to create a drm_connector entity instead of asking the
> bridge to do so during drm_bridge_attach. Moreover, the controller
> driver should create a drm_bridge entity to n
Hi Iago,
Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So add its specific
compatible to the bindings.
v2: new, requested by Stefan Wahren.
Thanks for sending this but the line above belongs below --- since it's
not relevant after the patc
Hi Iago,
Am 30.10.23 um 11:18 schrieb Iago Toral:
El lun, 30-10-2023 a las 10:57 +0100, Stefan Wahren escribió:
Hi Iago,
Am 30.10.23 um 09:28 schrieb Iago Toral Quiroga:
BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So add its
specific
compatible to the bindings.
v2: new, requested by
On Mon, 30 Oct 2023 at 12:27, Simon Ser wrote:
>
> On Monday, October 30th, 2023 at 11:22, Dmitry Baryshkov
> wrote:
>
> > On Mon, 30 Oct 2023 at 12:13, Simon Ser cont...@emersion.fr wrote:
> >
> > > On Monday, October 30th, 2023 at 10:47, Dmitry Baryshkov
> > > dmitry.barysh...@linaro.org wrot
El mar, 24-10-2023 a las 07:05 -0300, Maira Canal escribió:
> Hi Iago,
>
> On 10/24/23 02:57, Iago Toral wrote:
> > El lun, 23-10-2023 a las 07:58 -0300, Maíra Canal escribió:
> > > Currently, we are only warning the user if the BIN or RENDER jobs
> > > don't
> > > finish before we unregister V3D.
On Mon, 30 Oct 2023 at 12:36, Neil Armstrong wrote:
>
> Add DPU version 10.0 support for the SM8650 platform.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Dmitry Baryshkov
> ---
> .../drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h| 457
> +
> drivers/gpu/drm/msm/disp/d
Hi Iago,
The whole series is:
Reviewed-by: Maíra Canal
You can add my r-b in the next version (adding the DTS maintainers in
CC).
Best Regards,
- Maíra
On 10/30/23 05:28, Iago Toral Quiroga wrote:
This series includes patches to update the V3D kernel module
that drives the VideoCore VI GPU
Hi Iago,
On 10/30/23 09:20, Iago Toral wrote:
El mar, 24-10-2023 a las 07:05 -0300, Maira Canal escribió:
Hi Iago,
On 10/24/23 02:57, Iago Toral wrote:
El lun, 23-10-2023 a las 07:58 -0300, Maíra Canal escribió:
Currently, we are only warning the user if the BIN or RENDER jobs
don't
finish b
On 27/10/2023 18:38, Tvrtko Ursulin wrote:
On 27/10/2023 18:28, Harshit Mogalapalli wrote:
When i915 perf interface is not available dereferencing it will lead to
NULL dereferences.
As returning -ENOTSUPP is pretty clear return when perf interface is not
available.
Fixes: 2fec539112e8 ("i91
Hello dri maintainers/developers,
This is a 31-day syzbot report for the dri subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/dri
During the period, 1 new issues were detected and 0 were fixed.
In total, 15 issues are still open and 30 have been
At least MediaTek platforms are able to get the GPU clocks and regulators
completely off during system suspend, allowing to save a bit of power.
Panfrost is used on more than just MediaTek SoCs and the benefits of this
can be variable across different SoC models and/or different SoCs from
differen
Currently, the GPU is being internally powered off for runtime suspend
and turned back on for runtime resume through commands sent to it, but
note that the GPU doesn't need to be clocked during the poweroff state,
hence it is possible to save some power on selected platforms.
Add suspend and resum
All of the MediaTek SoCs supported by Panfrost can switch the clocks
off and on during system sleep to save some power without any user
experience penalty.
Measurements taken on multiple MediaTek SoCs show that adding this
will not prolong the time that is required to resume the system in
any mean
All of the MediaTek SoCs supported by Panfrost can completely cut power
to the GPU during full system sleep without any user-noticeable delay
in the resume operation, as shown by measurements taken on multiple
MediaTek SoCs.
As an example, for MT8195 - a "before" with only runtime PM operations
(s
Some platforms/SoCs can power off the GPU entirely by completely cutting
off power, greatly enhancing battery time during system suspend: add a
new pm_feature GPU_PM_VREG_OFF to allow turning off the GPU regulators
during full suspend only on selected platforms.
Signed-off-by: AngeloGioacchino Del
1 - 100 of 188 matches
Mail list logo
