Hi AngeloGioacchino,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7-rc6
next-20231222]
[cannot apply to
On Thu, Dec 21, 2023, 10:33 PM Dave Airlie wrote:
> This should let the upper layers retry as needed on EAGAIN.
>
> There may be other values we will care about in the future, but
> this covers our present needs.
>
> Signed-off-by: Dave Airlie
>
> +static int
> +r535_rpc_status_to_errno(uint32_t
Hi David,
Recently, Redhat CKI reported a kdump kernel bootup failure caused by
OOM. After bisect, it only happened after commit b5bad8c16b9b
("nouveau/gsp: move to 535.113.01"). Reverting the commit can avoid the
OOM, kdump kernel can boot up successfully.
>From debugging, we can see that about
On Mon, 11 Dec 2023 at 21:19, Andy Shevchenko
wrote:
>
> On Fri, Dec 08, 2023 at 09:18:20PM +0100, Noralf Trønnes wrote:
> > On 12/8/23 17:00, Andy Shevchenko wrote:
> > > Included authors and latest (non-white-space) contributors to the drivers
> > > in question along with relevant mailing list a
On Tue, Dec 19, 2023 at 11:15 AM Stefan Hoffmeister
wrote:
>
>
> Hi,
>
> vmwgfx implements drmPrimeFDToHandle in terms of the TTM resource manager.
>
> At the same time, the driver advertises
>
> .driver_features =
> DRIVER_MODESET | DRIVER_RENDER | DRIVER_ATOMIC | DRIVER_GEM,
>
>
On Thu, Dec 21, 2023 at 5:54 AM Sverdlin, Alexander
wrote:
>
> Hi Zack,
>
> thank you for the patch!
>
> On Thu, 2023-09-28 at 00:13 -0400, Zack Rusin wrote:
> > From: Zack Rusin
> >
> > Surfaces can be backed (i.e. stored in) memory objects (mob's) which
> > are created and managed by the usersp
On Fri, Dec 22, 2023 at 11:58 AM Akhil P Oommen
wrote:
>
> On Mon, Dec 18, 2023 at 07:59:24AM -0800, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > a6xx_recover() is relying on the gpu lock to serialize against incoming
> > submits doing a runpm get, as it tries to temporarily balance out the
>
On Mon, Dec 18, 2023 at 07:59:24AM -0800, Rob Clark wrote:
>
> From: Rob Clark
>
> a6xx_recover() is relying on the gpu lock to serialize against incoming
> submits doing a runpm get, as it tries to temporarily balance out the
> runpm gets with puts in order to power off the GPU. Unfortunately
On Thu, 26 Oct 2023 at 12:40, Jani Nikula wrote:
>
> Add new struct drm_edid based ->edid_read hook and
> drm_bridge_edid_read() function to call the hook.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_bridge.c | 46 +++-
> include/drm/drm_bridge.h
On Fri, Dec 22, 2023 at 2:32 PM Manuel Traut wrote:
>
> From: Segfault
>
> The BOE TH101MB31IG002-28A panel is a WXGA panel.
> It is used in Pine64 Pinetab2 and PinetabV.
>
> Signed-off-by: Segfault
Please use a real name instead...
> +MODULE_AUTHOR("Alexander Warnecke ");
like here.
In preparation to support RK3128's integration of the controller, this
patch adds a simple variant implementation. They mainly differ in the phy
configuration required, so those are part of the match_data. The values
have been taken from downstream. The pixelclocks in there are meant to be
max-incl
RK3128 has Innosilicon based HDMI TX controller similar to the one found in
RK3036.
Add it and the respective port nodes to the SoC device tree.
Signed-off-by: Alex Bee
---
changes in v2:
- no changes
changes in v3:
- no changes
changes in v4:
- none
arch/arm/boot/dts/rockchip/rk3128.dtsi
Add an hdmi-connector node and enable the hdmi, display-subsystem and vop
nodes.
Signed-off-by: Alex Bee
---
changes in v2:
- no changes
changes in v3:
- no changes
changes in v4:
- none
.../arm/boot/dts/rockchip/rk3128-xpi-3128.dts | 29 +++
1 file changed, 29 insertions(+
Now that we have proper pixelclock-based mode validation we can drop the
custom fill_modes hook.
CRTC size validation for the display controller has been added with
Commit 8e140cb60270 ("drm/rockchip: vop: limit maximum resolution to
hardware capabilities")
Signed-off-by: Alex Bee
Reviewed-by: Ma
This variant requires the phy reference clock to be enabled before the DDC
block can work and the (initial) DDC bus frequency is calculated based on
the rate of this clock. Besides the only difference is phy configuration
required to make the driver working for this variant as well.
Signed-off-by:
As per TRM this controller supports pixelclocks starting from 25 MHz. The
maximum supported pixelclocks are defined by the phy configurations we
have. Also it can't support modes that require doubled clocks. If the
variant has a phy reference clock we can additionally validate against VESA
DMT'srec
The data which is currently hold in hdmi_data should not be part of device
itself but of the connector state.
Introduce a connector state subclass and move the data from hdmi_data in
there.
Suggested-by: Maxime Ripard
Signed-off-by: Alex Bee
---
changes in v2:
- new patch
changes in v3:
- add
From: Maxime Ripard
The HDMI vendor infoframe is only meant to be sent with 4k60 modes and
higher, but the controller doesn't support them. Let's drop them from
the kernel.
Suggested-by: Johan Jonker
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
Add vop and display-subsystem nodes to RK3128's device tree.
Signed-off-by: Alex Bee
---
changes in v2:
- no changes
changes in v3:
- no changes
changes in v4:
- none
arch/arm/boot/dts/rockchip/rk3128.dtsi | 27 ++
1 file changed, 27 insertions(+)
diff --git a/arch
From: Maxime Ripard
The tmds_rate field in the inno_hdmi structure is used mostly to
configure the internal i2c controller divider through a call to the
inno_hdmi_i2c_init() function.
We can simply make that rate an argument to that function, which also
removes a workaround to initialize the div
The struct member irq isn't used anywhere. Drop it.
Signed-off-by: Alex Bee
Reviewed-by: Maxime Ripard
---
changes in v2:
- new patch
changes in v3:
- collect RB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/r
The display controller will always give full range RGB regardless of the
mode set, but HDMI requires certain modes to be transmitted in limited
range RGB. This is especially required for HDMI sinks which do not support
non-standard quantization ranges.
This enables color space conversion for those
From: Maxime Ripard
The mode's VIC is only ever used in the inno_hdmi_setup() function so
there's no need to store it in the main structure.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
[made checkpatch happy]
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
-
From: Maxime Ripard
The driver has a lot of logic to deal with multiple input formats, but
hardcodes it to RGB. This means that most of that code has been dead
code, so let's get rid of it.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
[made checkpatch happy]
Signed-off-by: Alex Bee
---
ch
inno_hdmi_reset is only ever called when initializing the controller. At
this point it’s completely uneccessary to power up the PHY, since all
what has to work at this point is the DDC bus. The phy will be powered up
correctly when a mode is set in inno_hdmi_encoder_enable and disabled in
inno_hdmi
From: Maxime Ripard
The drm_dev field in the inno_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my
From: Maxime Ripard
The sink_has_audio flag is not used anywhere in the driver so let's get
rid of it. It's redundant with drm_display_info.has_audio anyway.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added
The inclusion syscon.h isn't used anywhere. Remove it.
Signed-off-by: Alex Bee
Reviewed-by: Maxime Ripard
---
changes in v2:
- new patch
changes in v3:
- collect RB
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/dr
From: Maxime Ripard
The mode_fixup implementation doesn't do anything, so we can simply
remove it.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/rockchip/i
Now that the unneeded support for YUV based input formats is gone, the csc
coefficients for those formats can be dropped as well.
Signed-off-by: Alex Bee
---
changes in v2:
- new patch
changes in v3:
- none
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdmi.c | 37 ---
The controller wants the difference between *total and *sync_start in the
HDMI_VIDEO_EXT_*DELAY registers. Otherwise the signal is very unstable for
certain non-VIC modes. See downstream commit [0].
[0] https://github.com/rockchip-linux/kernel/commit/8eb559f2502c
Fixes: 412d4ae6b7a5 ("drm/rockchi
From: Maxime Ripard
The inno_hdmi encoder still uses the !atomic variants of enable, disable
and modeset. Convert to their atomic equivalents.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes
This splits setting the power mode of the controller / phy in two
functions. It's done in preparation of setting up the phy based on the
pixelclock.
No functional changes intended.
Signed-off-by: Alex Bee
---
changes in v3:
- new patch
changes in v4:
- none
drivers/gpu/drm/rockchip/inno_hdm
From: Maxime Ripard
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers
From: Maxime Ripard
The inno_hdmi driver relies on its own internal infoframe type matching
the hardware.
This works fine, but in order to make further reworks easier, let's
switch to the HDMI spec definition of those types.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex
From: Maxime Ripard
The code to upload infoframes to the controller uses a weird construct
which, based on the previous function call return code, will either
disable or enable that infoframe.
In order to get rid of that argument, let's split the function to
disable the infoframe into a separate
The integration for this SoC is different from the currently existing: It
needs it's PHY's reference clock rate to calculate the DDC bus frequency
correctly. The controller is also part of a powerdomain, so this gets added
as an mandatory property for this variant.
Signed-off-by: Alex Bee
Reviewe
From: Maxime Ripard
The driver maintains a copy of the adjusted mode but doesn't use it
anywhere. Remove it.
Signed-off-by: Maxime Ripard
Tested-by: Alex Bee
Signed-off-by: Alex Bee
---
changes in v2:
- imported patch
changes in v3:
- added my SoB
changes in v4:
- none
drivers/gpu/drm/
In contrast to RK3036, RK312x SoCs have multiple output channels such as
RGB (i.e. LVDS TTL), LVDS, DSI and HDMI.
In order to support that, this splits output from RK3036 and defines an
separate one for RK3126 with the registers required to enable the
appropriate output and setup the correct polar
This is version 4 of my series that aims to add support for the display
controller (VOP) and the HDMI controller block of RK3128 (which is very
similar to the one found in RK3036). The original intention of this series
was to add support for this slightly different integration but is by now,
driven
Dne petek, 22. december 2023 ob 10:10:25 CET je Frank Oltmanns napisal(a):
>
> On 2023-12-20 at 19:57:06 +0100, Frank Oltmanns wrote:
> > Ok, I've done more detailed testing, and it seems this patch results in
> > lots of dropped frames. I'm sorry for not being more thorough earlier.
> > I'll do
On 2023-12-20 18:25, John Paul Adrian Glaubitz wrote:
Hi Sam,
On Wed, 2023-12-20 at 16:22 +0100, Sam Ravnborg wrote:
The leon3_generic machine is maintained by different people so I'd suggest
contacting them: see [1] for their contact details. I see there is an
avocado boot test for the leon3
On 12/22/2023 5:08 AM, Rob Herring wrote:
On Thu, 21 Dec 2023 12:25:06 +0200, Dmitry Baryshkov wrote:
Rename the Qualcomm MSM Display schemas to follow the main compatible
string instead of just using the block type. This follows the
established practice for YAML file names.
Cc: Aiqun Yu (M
The sound-dai-cells property is used, e.g. in rk356x.dtsi
Signed-off-by: Manuel Traut
---
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml| 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
b/Doc
Add support for the 1080x2408 Truly NT36672E video mode
DSI panel driver.
Signed-off-by: Ritesh Kumar
---
drivers/gpu/drm/panel/Kconfig| 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-truly-nt36672e.c | 644 +++
3 files ch
devicetree checks show some warnings:
video-codec@fdea0400: 'interrupt-names' is a required property
from schema $id: http://devicetree.org/schemas/media/rockchip-vpu.yaml#
hdmi@fe0a: Unevaluated properties are not allowed ('power-domains' were
unexpected)
from schema $id:
http://devicetree
|1 +
.../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c | 307 ++
11 files changed, 1513 insertions(+), 2 deletions(-)
---
base-commit: 24e0d2e527a39f64caeb2e6be39ad5396fb2da5e
change-id: 20231222-pinetab2-faa77e01db6f
Best regards,
--
Manuel Traut
From: Segfault
This includes support for both the v0.1 units that were sent to developers and
the v2.0 units from production.
v1.0 is not included as no units are known to exist.
Working/Tested:
- SDMMC
- UART
- Buttons
- Charging/Battery/PMIC
- Audio
- USB
- Display
WiFi is not added, since t
Add devicvetree binding documentation for Pine64 Pinetab2
which uses the Rockchip RK3566 SoC.
Signed-off-by: Manuel Traut
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml
b/Doc
Add support for the 1080x2408 Truly NT36672E LCD DSI mode panel
found on the Qualcomm QCM6490 MTP board.
The driver will come with the uncompressed video mode support.
Ritesh Kumar (2):
dt-bindings: display: panel: Add Truly NT36672E LCD DSI panel
drm/panel: Add support for Truly NT36672E pan
Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is
used e.g. in the Pine64 Pinetab2 and PinetabV.
Signed-off-by: Manuel Traut
---
.../display/panel/boe,th101mb31ig002-28a.yaml | 73 ++
1 file changed, 73 insertions(+)
diff --git
a/Documentation/devicetree/bin
From: Segfault
The BOE TH101MB31IG002-28A panel is a WXGA panel.
It is used in Pine64 Pinetab2 and PinetabV.
Signed-off-by: Segfault
Signed-off-by: Manuel Traut
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile | 1 +
.../gpu/
Document Truly NT36672E FHD+ LCD DSI panel.
Signed-off-by: Ritesh Kumar
---
.../display/panel/truly,nt36672e.yaml | 66 +++
1 file changed, 66 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/truly,nt36672e.yaml
diff --git
a/Documentati
On Friday, 22 December 2023 12:05:44 CET Manuel Traut wrote:
> +
> +&cru {
> + assigned-clocks = <&cru PLL_GPLL>, <&pmucru PLL_PPLL>, <&cru
> PLL_VPLL>; + assigned-clock-rates = <12>, <2>,
> <5>; +};
Attachment seem to work and for this I also have the attached
On Friday, 22 December 2023 12:05:44 CET Manuel Traut wrote:
> + rk817-sound {
> + compatible = "simple-audio-card";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hp_det_l>;
> + simple-audio-card,format = "i2s";
> + simp
On Friday, 22 December 2023 12:05:40 CET Manuel Traut wrote:
> [3]
> https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/
> mobian-6.6/debian/patches/display/0018-drm-panel-add-BOE-TH101MB31IG002-28A-
> driver.patch?ref_type=heads
> [4]
> https://salsa.debian.org/Mobian-team
On Friday, 22 December 2023 12:05:41 CET Manuel Traut wrote:
> +title: BOE TH101MB31IG002-28A Pine64 Pinetab2 DSI Display Panel
s/Pine64 Pinetab2 // ?
It is used by the PT2 but I assume it's a 'standalone' panel?
signature.asc
Description: This is a digitally signed message part.
On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote:
Add the xe repo to drm-tip and the dim tools.
For now use the sha1 of the first drm-xe-next pull request for drm-tip,
since that branch tip is currently adapted for our CI testing.
Cc: Rodrigo Vivi
Cc: Lucas De Marchi
Cc: Oded G
On 22/12/2023 12:05, Manuel Traut wrote:
> devicetree checks show some warnings:
>
> video-codec@fdea0400: 'interrupt-names' is a required property
> from schema $id: http://devicetree.org/schemas/media/rockchip-vpu.yaml#
>
> hdmi@fe0a: Unevaluated properties are not allowed ('power-domains'
On 22/12/2023 12:05, Manuel Traut wrote:
> The sound-dai-cells property is used, e.g. in rk356x.dtsi
Better to see here rather explanation why dai cells are needed, unless
you aren't sure and just want to fix warning.
>
> Signed-off-by: Manuel Traut
> ---
> .../devicetree/bindings/display/rock
The pull request you sent on Fri, 22 Dec 2023 14:59:38 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-12-22
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8afe6f0e0e257bf7f79f5996c037e8977dcc8cc1
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On 22/12/2023 12:05, Manuel Traut wrote:
> Add devicvetree binding documentation for Pine64 Pinetab2
> which uses the Rockchip RK3566 SoC.
>
> Signed-off-by: Manuel Traut
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 22/12/2023 12:05, Manuel Traut wrote:
> Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is
> used e.g. in the Pine64 Pinetab2 and PinetabV.
>
> Signed-off-by: Manuel Traut
> ---
> +
> +maintainers:
> + - Manuel Traut
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
On Fri, 22 Dec 2023, Jani Nikula wrote:
> On Fri, 22 Dec 2023, Neil Armstrong wrote:
>> On 19/12/2023 13:15, Jani Nikula wrote:
>>> On Tue, 14 Nov 2023, Jani Nikula wrote:
On Thu, 26 Oct 2023, Jani Nikula wrote:
> This is just the first two patches of a lengthy series that I'm not
On 22/12/2023 12:07, Ritesh Kumar wrote:
> Add support for the 1080x2408 Truly NT36672E LCD DSI mode panel
Google does not find anything for "Truly NT36672E", so I have some
doubts whether you used correct vendor name or product ID.
Best regards,
Krzysztof
On 22/12/2023 12:07, Ritesh Kumar wrote:
> Add support for the 1080x2408 Truly NT36672E video mode
> DSI panel driver.
>
> Signed-off-by: Ritesh Kumar
> ---
> drivers/gpu/drm/panel/Kconfig| 9 +
> drivers/gpu/drm/panel/Makefile | 1 +
Integrate it with existing
Hi,
On Fri, Dec 22, 2023 at 2:29 AM Pin-yen Lin wrote:
>
> Hi Douglas,
>
> On Fri, Dec 22, 2023 at 5:56 AM Douglas Anderson
> wrote:
> >
> > Unlike what is claimed in commit f5aa7d46b0ee ("drm/bridge:
> > parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux"), if
> > someone manually
On 22/12/2023 12:07, Ritesh Kumar wrote:
> Document Truly NT36672E FHD+ LCD DSI panel.
>
> Signed-off-by: Ritesh Kumar
> ---
> .../display/panel/truly,nt36672e.yaml | 66 +++
> 1 file changed, 66 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/dis
On Fri, 22 Dec 2023 13:26:22 +
Liviu Dudau wrote:
> Hi Boris,
>
> On Mon, Dec 04, 2023 at 06:32:56PM +0100, Boris Brezillon wrote:
> > The panthor driver is designed in a modular way, where each logical
> > block is dealing with a specific HW-block or software feature. In order
> > for those
Quoting Andi Shyti (2023-12-21 19:08:22)
> The CCS mode involves assigning CCS engines to slices depending
> on the number of slices and the number of engines the user wishes
> to set.
>
> In this patch, the default CCS setting is established during the
> initial GT settings. It involves assigning
Hi Boris,
On Mon, Dec 04, 2023 at 06:32:56PM +0100, Boris Brezillon wrote:
> The panthor driver is designed in a modular way, where each logical
> block is dealing with a specific HW-block or software feature. In order
> for those blocks to communicate with each other, we need a central
> panthor_
On 12/22/23 13:25, Thomas Hellström wrote:
Hi,
On 12/22/23 13:01, Jani Nikula wrote:
On Fri, 22 Dec 2023, Thomas Hellström
wrote:
Add the xe repo to drm-tip and the dim tools.
For now use the sha1 of the first drm-xe-next pull request for drm-tip,
since that branch tip is currently adapted
Hi,
On 12/22/23 13:01, Jani Nikula wrote:
On Fri, 22 Dec 2023, Thomas Hellström wrote:
Add the xe repo to drm-tip and the dim tools.
For now use the sha1 of the first drm-xe-next pull request for drm-tip,
since that branch tip is currently adapted for our CI testing.
I guess we'll need xe CI
On Fri, 22 Dec 2023, Thomas Hellström wrote:
> Add the xe repo to drm-tip and the dim tools.
> For now use the sha1 of the first drm-xe-next pull request for drm-tip,
> since that branch tip is currently adapted for our CI testing.
I guess we'll need xe CI to switch to drm-tip based testing, and
tilcdc currently just ioremaps its iomem, without doing the (a bit more
robust) request on the memory first. The devm_ functions provide a handy
way to both request and ioremap the memory with automatic cleanup.
Replace the manual ioremap with the devm_ version.
Suggested-by: Thomas Zimmermann
S
Add the xe repo to drm-tip and the dim tools.
For now use the sha1 of the first drm-xe-next pull request for drm-tip,
since that branch tip is currently adapted for our CI testing.
Cc: Rodrigo Vivi
Cc: Lucas De Marchi
Cc: Oded Gabbay
Cc: daniel.vet...@ffwll.ch
Cc: Maarten Lankhorst
Cc: dim-to.
Hi Douglas,
On Fri, Dec 22, 2023 at 5:56 AM Douglas Anderson wrote:
>
> Unlike what is claimed in commit f5aa7d46b0ee ("drm/bridge:
> parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux"), if
> someone manually tries to do an AUX transfer (like via `i2cdump ${bus}
> 0x50 i`) while the
Add a Device Tree binding schema for the OLED panels based on the
Solomon SSD133x family of controllers.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Rob Herring
---
(no changes since v3)
Changes in v3:
- Move solomon,ssd-common.yaml ref before the properties section and
width/height
Commit 2d23e7d6bacb ("dt-bindings: display: Add SSD132x OLED controllers")
used the wrong properties for width and height, instead of the correct
"solomon,width" and "solomon,height" properties.
Fix this by adding the vendor prefix to the width and height properties.
Fixes: 2d23e7d6bacb ("dt-bind
The Solomon SSD133x controllers (such as the SSD1331) are used by RGB dot
matrix OLED panels, add a modesetting pipeline to support the chip family.
The SSD133x controllers support 256 (8-bit) and 65k (16-bit) color depths
but only the 256-color mode (DRM_FORMAT_RGB332) is implemented for now.
Si
Hello,
This patch-set adds support for the family of SSD133x Solomon controllers,
such as the SSD1331. These are used for RGB Dot Matrix OLED/PLED panels.
This is a v4 that addresses issues pointed out in v3:
https://lists.freedesktop.org/archives/dri-devel/2023-December/435686.html
The patches
The commit 591825fba8a2 ("dt-bindings: display: ssd1307fb: Remove default
width and height values") used the wrong properties for width and height,
instead of the correct "solomon,width" and "solomon,height" properties.
Fix this by adding the vendor prefix to the width and height properties.
Fixe
On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen
wrote:
> > > It is protected/shielded/fortified from all the kernel and userspace,
> > > but a more familiar word to describe that is inaccessible.
> > > "Inaccessible buffer" per se OTOH sounds like a useless concept.
> > >
> > > It is
Jocelyn Falempe writes:
Hello Jocelyn,
Thanks a lot for your review!
> On 19/12/2023 21:34, Javier Martinez Canillas wrote:
>> The Solomon SSD133x controllers (such as the SSD1331) are used by RGB dot
>> matrix OLED panels, add a modesetting pipeline to support the chip family.
>>
>> The SSD13
On Fri, 22 Dec 2023, Neil Armstrong wrote:
> On 19/12/2023 13:15, Jani Nikula wrote:
>> On Tue, 14 Nov 2023, Jani Nikula wrote:
>>> On Thu, 26 Oct 2023, Jani Nikula wrote:
This is just the first two patches of a lengthy series that I'm not
really sure how to proceed with. Basically the
s://download.01.org/0day-ci/archive/20231222/202312221708.b143534-oliver.s...@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On 19/12/2023 21:34, Javier Martinez Canillas wrote:
The Solomon SSD133x controllers (such as the SSD1331) are used by RGB dot
matrix OLED panels, add a modesetting pipeline to support the chip family.
The SSD133x controllers support 256 (8-bit) and 65k (16-bit) color depths
but only the form
On 2023-12-20 at 19:57:06 +0100, Frank Oltmanns wrote:
> Ok, I've done more detailed testing, and it seems this patch results in
> lots of dropped frames. I'm sorry for not being more thorough earlier.
> I'll do some more testing without this patch and might have to either
> remove it from V2 of
On Thu, 2023-12-21 at 18:30 +0100, Paul Cercueil wrote:
> Hi Jonathan,
>
> Le jeudi 21 décembre 2023 à 16:12 +, Jonathan Cameron a écrit :
> > On Tue, 19 Dec 2023 18:50:08 +0100
> > Paul Cercueil wrote:
> >
> > > Use the functions provided by the buffer-dma core to implement the
> > > DMABUF
On Thu, 2023-12-21 at 16:04 +, Jonathan Cameron wrote:
> On Tue, 19 Dec 2023 18:50:07 +0100
> Paul Cercueil wrote:
>
> > Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
> > and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
> > DMA buffer implemen
On 12/21/23 21:36, Krzysztof Kozlowski wrote:
> On 21/12/2023 13:43, Raphael Gallais-Pou wrote:
>> Add dt-binding file for "st,stm32-lvds" compatible.
>>
>> Signed-off-by: Raphael Gallais-Pou
>> ---
> I don't know why this was resend, nothing explains it, but I already
> commented on other versi
Hi Krzysztof,
Thanks for your review. I wall send another serie later with those
modifications.
Best regards,
Raphaël
On 12/21/23 18:27, Krzysztof Kozlowski wrote:
> On 21/12/2023 13:28, Raphael Gallais-Pou wrote:
>> Add dt-binding file for "st,stm32-lvds" compatible.
>>
> A nit, subject: d
Hi Rob
On 12/21/23 15:45, Rob Herring wrote:
> On Thu, 21 Dec 2023 13:43:33 +0100, Raphael Gallais-Pou wrote:
>> Add dt-binding file for "st,stm32-lvds" compatible.
>>
>> Signed-off-by: Raphael Gallais-Pou
>> ---
>> .../bindings/display/st,stm32-lvds.yaml | 114 ++
>> 1 fil
Signed-off-by: Samuel Dionne-Riel
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 3d92f66e550c3..f730886ae10df 100644
--- a/drivers/g
Hi,
Sorry, I was preparing for sending to the mailing list, and sent
before I should have.
I believe I have the orientation on the wrong side, though, so please
wait for a follow-up here or the v2.
Sorry again,
On 12/21/23, Samuel Dionne-Riel wrote:
> Signed-off-by: Samuel Dionne-Riel
> ---
>
Signed-off-by: Samuel Dionne-Riel
---
Changes since v1:
- Add 1080p right-side up panel data
- Use the correct panel orientation
drivers/gpu/drm/drm_panel_orientation_quirks.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/
Hi,
On Thu, 21 Dec 2023 13:43:31 +0100, Raphael Gallais-Pou wrote:
> This serie introduces a new DRM bridge driver for STM32MP257 platforms
> based on Arm Cortex-35. It also adds an instance in the device-tree and
> handle the inclusion of the driver within the DRM framework. First patch
> adds a
On 19/12/2023 13:15, Jani Nikula wrote:
On Tue, 14 Nov 2023, Jani Nikula wrote:
On Thu, 26 Oct 2023, Jani Nikula wrote:
This is just the first two patches of a lengthy series that I'm not
really sure how to proceed with. Basically the series converts all of
drm/bridge to the new struct drm_ed
On 20/12/2023 03:48, yang.gua...@zte.com.cn wrote:
From: Yang Guang
dev_err_probe() can check if the error code is -EPROBE_DEFER
and can return the error code, replacing dev_err() with it
simplifies the code.
Signed-off-by: Chen Haonan
Got the following checkpatch error:
ERROR:NO_AUTHOR_SIG
99 matches
Mail list logo
