On 2022.12.19 20:52:04 +0800, Zheng Wang wrote:
> If intel_gvt_dma_map_guest_page failed, it will call
> ppgtt_invalidate_spt, which will finally free the spt. But the caller does
> not notice that, it will free spt again in error path.
>
It's not clear from this description which caller is actu
On 2022.12.20 16:41:15 +1300, Paulo Miguel Almeida wrote:
> One-element arrays are deprecated, and we are replacing them with
> flexible array members instead. So, replace one-element array with
> flexible-array member in struct gvt_firmware_header and refactor the
> rest of the code accordingly.
>
On 19/12/2022 22:47, Laurent Pinchart wrote:
> Hi Tomi,
>
> (CC'ing Sakari and Hans)
>
> Thank you for the patch.
>
> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
>> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
>>
>> Signed-off-by: Tomi Valkeinen
>>
On 16/12/2022 20:30, Thomas Zimmermann wrote:
Ast hardware scans out the primary plane from video memory, which
is in I/O-memory space. Hence init the damage handler's iosys_map
pointer as I/O memory.
Not all platforms support accessing I/O memory as system memory,
although it's usually not a pr
Zhenyu Wang 于2022年12月20日周二 16:25写道：
>
> On 2022.12.19 20:52:04 +0800, Zheng Wang wrote:
> > If intel_gvt_dma_map_guest_page failed, it will call
> > ppgtt_invalidate_spt, which will finally free the spt. But the caller does
> > not notice that, it will free spt again in error path.
> >
>
> It's
Hi Hans,
On Tue, Dec 20, 2022 at 10:01 AM Hans Verkuil wrote:
> On 19/12/2022 22:47, Laurent Pinchart wrote:
> > (CC'ing Sakari and Hans)
> >
> > Thank you for the patch.
> >
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> >> Add new pixel formats: RGBX1010102, RGBA1010102,
On 12/19/22 17:04, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 12/19/22 17:05, Thomas Zimmermann wrote:
> This reverts commit ae1287865f5361fa138d4d3b1b6277908b54eac9.
>
> Always free the console font when deinitializing the framebuffer
> console. Subsequent framebuffer consoles will then use the default
> font. Rely on userspace to load any user-configure
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in gma500.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Hello,
On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
> On 19/12/2022 22:47, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > (CC'ing Sakari and Hans)
> >
> > Thank you for the patch.
> >
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> >> Add new pixel formats:
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in i915.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in radeon.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
On 20/12/2022 10:09, Geert Uytterhoeven wrote:
> Hi Hans,
>
> On Tue, Dec 20, 2022 at 10:01 AM Hans Verkuil
> wrote:
>> On 19/12/2022 22:47, Laurent Pinchart wrote:
>>> (CC'ing Sakari and Hans)
>>>
>>> Thank you for the patch.
>>>
>>> On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrot
On 12/19/22 17:05, Thomas Zimmermann wrote:
> The apertures field in struct fb_info is not used by DRM drivers. Do
> not allocate it.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in clps711x-fb.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Cani
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in hyperv-fb.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canill
On 20/12/2022 10:18, Laurent Pinchart wrote:
> Hello,
>
> On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
>> On 19/12/2022 22:47, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> (CC'ing Sakari and Hans)
>>>
>>> Thank you for the patch.
>>>
>>> On Mon, Dec 19, 2022 at 04:01:39PM +0200, T
[adding Kirti Wankhede and k...@vger.kernel.org to Cc list]
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in mdpy-fb.
>
> Signed-off-by: Th
On 12/19/22 17:05, Thomas Zimmermann wrote:
> The efifb_par structure holds the palette for efifb. It will also
> be useful for storing the device's aperture range.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core
Hi Hans,
On Tue, Dec 20, 2022 at 10:22 AM Hans Verkuil wrote:
> On 20/12/2022 10:09, Geert Uytterhoeven wrote:
> > On Tue, Dec 20, 2022 at 10:01 AM Hans Verkuil
> > wrote:
> >> On 19/12/2022 22:47, Laurent Pinchart wrote:
> >>> (CC'ing Sakari and Hans)
> >>>
> >>> Thank you for the patch.
> >>>
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Acquire ownership of the firmware scanout buffer by calling Linux'
> aperture helpers. Remove the use of struct fb_info.apertures and do
> not set FBINFO_MISC_FIRMWARE; both of which previously configured
> buffer ownership.
>
> Signed-off-by: Thomas Z
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Move the palette array into struct offb_par and allocate both via
> framebuffer_alloc(), as intended by fbdev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martine
Am 19.12.22 um 11:58 schrieb Thomas Zimmermann:
Hi
Am 19.12.22 um 10:23 schrieb José Expósito:
Hi Thomas,
Thanks for CCing me.
There are some issues with this helpers on big endian architectures,
you can
run the test on big endian with this command:
$ ./tools/testing/kunit/kunit.py run
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Acquire ownership of the firmware scanout buffer by calling Linux'
> aperture helpers. Remove the use of struct fb_info.apertures and do
> not set FBINFO_MISC_FIRMWARE; both of which previously configured
> buffer ownership.
>
> Signed-off-by: Thomas Z
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Acquire ownership of the firmware scanout buffer by calling Linux'
> aperture helpers. Remove the use of struct fb_info.apertures and do
> not set FBINFO_MISC_FIRMWARE; both of which previously configured
> buffer ownership.
>
> Signed-off-by: Thomas Z
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt. But the
caller function ppgtt_populate_spt_by_guest_entry does not notice
that, it will free spt again in its error path.
Fix this by undoing the mapping of DMA address and freeing sub_sp
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Acquire ownership of the firmware scanout buffer by calling Linux'
> aperture helpers. Remove the use of struct fb_info.apertures and do
> not set FBINFO_MISC_FIRMWARE; both of which previously configured
> buffer ownership.
>
> Signed-off-by: Thomas Z
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Acquire ownership of the firmware scanout buffer by calling Linux'
> aperture helpers. Remove the use of struct fb_info.apertures and do
> not set FBINFO_MISC_FIRMWARE; both of which previously configured
> buffer ownership.
>
> Signed-off-by: Thomas Z
On 12/19/22 17:05, Thomas Zimmermann wrote:
> There are no users left of struct fb_info.apertures and the flag
> FBINFO_MISC_FIRMWARE. Remove both and the aperture-ownership code
> in the fbdev core. All code for aperture ownership is now located
> in the fbdev drivers.
>
> Signed-off-by: Thomas Z
Use the already existing local variable height = drm_rect_height() >> 16
to replace other occurrences of the same value.
Suggested-by: Lucas Stach
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --g
On 12/16/22 18:46, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 12/16/22 18:46, Thomas Zimmermann wrote:
> Change struct fb_ops.release and its implementations to not return
> a value. Returing an error is not necessary and callers of the
> function ignore it. It is also good practice to make clean-up code
> unable ot fail, as such failure cannot be handled.
On 19/12/2022 15:23, Johan Jonker wrote:
>
>
> On 12/19/22 14:04, Krzysztof Kozlowski wrote:
>> On 19/12/2022 13:32, Johan Jonker wrote:
>>> Convert rockchip-lvds.txt to YAML.
>>>
>>> Changed:
>>> Add power-domains property.
>>> Requirements between PX30 and RK3288
>>>
>>> Signed-off-by: Joha
On 12/13/22 21:12, Thomas Zimmermann wrote:
> Select color format for EFI/VESA firmware scanout buffer from the
> number of bits per pixel and the position of the individual color
> components. Fixes the selected format for the buffer in several odd
> cases. For example, XRGB1555 has been reported
On 12/13/22 21:12, Thomas Zimmermann wrote:
> Upcoming changes to the format conversion will mostly blit from
> XRGB to some other format. So put the source format in blit's
> outer branches to make the code more readable. For cases where
> a format only changes its endianness, such as XRGB565,
On 12/13/22 21:12, Thomas Zimmermann wrote:
> Add dedicated helper to convert from XRGB to ARGB. Sets
> all alpha bits to make pixels fully opaque.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platform
On 12/13/22 21:12, Thomas Zimmermann wrote:
> Add dedicated helper to convert from XRGB to ARGB2101010. Sets
> all alpha bits to make pixels fully opaque.
>
> Signed-off-by: Thomas Zimmermann
> ---
[...]
> +static void drm_test_fb_xrgb_to_argb2101010(struct kunit *test)
> +{
> + con
Hi Hans,
On Tue, Dec 20, 2022 at 10:26:35AM +0100, Hans Verkuil wrote:
> On 20/12/2022 10:18, Laurent Pinchart wrote:
> > On Tue, Dec 20, 2022 at 10:01:04AM +0100, Hans Verkuil wrote:
> >> On 19/12/2022 22:47, Laurent Pinchart wrote:
> >>> Hi Tomi,
> >>>
> >>> (CC'ing Sakari and Hans)
> >>>
> >>>
On 12/13/22 21:12, Thomas Zimmermann wrote:
> Add conversion from XRGB to XRGB1555, ARGB1555 and RGBA5551, which
> are the formats currently supported by the simplefb infrastructure. The
> new helpers allow the output of XRGB framebuffers to firmware
> scanout buffers in one of the 15-bit f
This patchset is trying to fix problems seen on S905X boards when interfacing
with an ILI9486 equipped SPI panel.
To: Kamlesh Gurudasani
To: David Airlie
To: Daniel Vetter
To: Mark Brown
To: Neil Armstrong
To: Kevin Hilman
To: Jerome Brunet
To: Martin Blumenstingl
Cc: dri-devel@lists.freed
Add VI6_IP_VERSION_SOC_V4H so that we can identify V4H SoC.
Signed-off-by: Tomi Valkeinen
---
drivers/media/platform/renesas/vsp1/vsp1_regs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
ind
Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
Signed-off-by: Tomi Valkeinen
---
.../userspace-api/media/v4l/pixfmt-rgb.rst| 194 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 3 +
include/uapi/linux/videodev2.h| 3 +
3 files changed, 200 inser
Having a bigger number of FIFO lines held after vsync is only useful to
SoCs using AFBC to give time to the AFBC decoder to be reset, configured
and enabled again.
For SoCs not using AFBC this, on the contrary, is causing on some
displays issues and a few pixels vertical offset in the displayed im
The pixel data for the ILI9486 is always 16-bits wide and it must be
sent over the SPI bus. When the controller is only able to deal with
8-bit transfers, this 16-bits data needs to be swapped before the
sending to account for the big endian bus, this is on the contrary not
needed when the SPI cont
On 06/12/2022 16:38, Geert Uytterhoeven wrote:
Hi Tomi,
On Tue, Dec 6, 2022 at 2:44 PM Tomi Valkeinen
wrote:
Add new pixel formats: XBGR2101010, ABGR2101010, BGRA1010102 and Y210.
Signed-off-by: Tomi Valkeinen
Thanks for your patch!
--- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
++
Add new pixel formats: XBGR2101010, ABGR2101010, BGRA1010102 and Y210.
Signed-off-by: Tomi Valkeinen
---
.../media/platform/renesas/vsp1/vsp1_pipe.c | 15 ++
.../media/platform/renesas/vsp1/vsp1_regs.h | 22 +
.../media/platform/renesas/vsp1/vsp1_rpf.c| 49 +++
From: Tomi Valkeinen
Hi,
These add new pixel formats for Renesas V3U and V4H SoCs.
As the display pipeline is split between DRM and V4L2 components, this
series touches both subsystems. I'm sending all these together to
simplify review. If needed, I can later split this to V4L2 and DRM
parts, o
Hi,
On 06/12/2022 19:39, Nicolas Dufresne wrote:
Hi,
Le mardi 06 décembre 2022 à 15:39 +0200, Tomi Valkeinen a écrit :
Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
Signed-off-by: Tomi Valkeinen
This patch is simply missing an update to
Documentation/userspace-api/media/v4l/pixfmt
SPI devices use the spi_device_id for module autoloading even on
systems using device tree.
Add the spi_device_id entry to enable autoloading for the 3.5inch RPi
Display (rpi-lcd-35 and piscreen).
Reviewed-by: Neil Armstrong
Signed-off-by: Carlo Caione
---
drivers/gpu/drm/tiny/ili9486.c | 2 ++
On 19/12/22 19:13, Neil Armstrong wrote:
Hi Kamlesh,
On 19/12/2022 10:02, Carlo Caione wrote:
This patchset is trying to fix problems seen on S905X boards when
interfacing
with an ILI9486 equipped SPI panel.
I fully reviewed both patches, but I'd like a review from the maintainer,
can you h
Add Y210, Y212 and Y216 formats.
Signed-off-by: Tomi Valkeinen
---
.../media/v4l/pixfmt-packed-yuv.rst | 44 +++
drivers/media/v4l2-core/v4l2-ioctl.c | 3 ++
include/uapi/linux/videodev2.h| 8
3 files changed, 55 insertions(+)
diff --git
V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the
rcar_du_r8a779a0_info.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_d
V3U is actually gen4, not gen3. The same IP is also used in the
(not-yet-supported) V4H.
Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
to represent the model correctly. V3U and V4H can still be
differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
Also mark VI6_IP_
On Tue, Nov 08, 2022 at 03:49:55PM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Nov 08, 2022 at 03:14:20PM +0100, Philipp Zabel wrote:
> > ipu_src_rect_width() was introduced to support odd screen resolutions
> > such as 1366x768 by internally rounding up primary plane width to a
> > multiple
On Mon, 19 Dec 2022 20:27:45 +0530, Thomas Zimmermann wrote:
> Hi
>
> Am 19.12.22 um 15:23 schrieb Siddh Raman Pant:
> > Line 536 of drm_print.h says DRM_INFO() is deprecated
> > in favor of pr_info().
>
> That's a misleading comment. DRM_INFO() is deprecated for drm_info().
> pr_info() et al is
Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +--
2 files changed, 71 insertions(+), 2 deletions(-)
diff --git
Line 536 of drm_print.h says DRM_INFO() is deprecated
in favor of pr_info().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_connector.c | 8
drivers/gpu/drm/drm_drv.c| 10 +-
drivers/gpu/drm/drm_edid_load.c
Hi Sakari,
On Tue, Dec 20, 2022 at 11:36:35AM +0200, Sakari Ailus wrote:
> On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> > > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
> > >
> > >
On 12/13/22 21:12, Thomas Zimmermann wrote:
> Split the single-probe helper's implementation into multiple
> functions and get locking and overallocation out of the way of
> the surface setup. Simplifies later changes to the setup code.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Jav
On 12/13/22 21:12, Thomas Zimmermann wrote:
> Fix the color-format selection of the single-probe helper. Go
> through all user-specified values and test each for compatibility
> with the driver. If none is supported, use the driver-provided
> default. This guarantees that the console is always avai
On 12/13/22 21:12, Thomas Zimmermann wrote:
> The DRM helper drm_fb_build_fourcc_list() creates a list of color
> formats for primary planes of the generic drivers. Simplify the helper:
>
> - It used to mix and filter native and emulated formats as provided
>by the driver. Now the only emulat
On 12/13/22 21:12, Thomas Zimmermann wrote:
> Drivers only emulate XRGB framebuffers. Remove all conversion
> helpers that do not use XRGB as their source format. Also remove
> some special cases for alpha formats in the blit helper.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by
On 12/20/2022 3:41 AM, john.c.harri...@intel.com wrote:
From: John Harrison
In the case where a firmware file is too large (e.g. someone
downloaded a web page ASCII dump from github...), the firmware object
is released but the pointer is not zerod. If no other firmware file
was found then re
rpi_firmware_get() takes refcount, we should release it with
rpi_firmware_put(), add missing rpi_firmware_put() in the error path.
Fixes: 2a001ca00ad5 ("drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection code")
Signed-off-by: Miaoqian Lin
---
drivers/gpu/drm/vc4/vc4_hvs.c | 1 +
1 file changed, 1
Changes since v2:
- added macros for stanby mode (untested, please review @pcercuei)
- added SPI table_id
- changed description in the bindings to describe the hw more
---
Changes since v1:
- fixed the dt-bindings maintainer email adress
- dropped backlight, port, power-supply and reset-gpios
Add driver for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
interface.
Signed-off-by: Christophe Branchereau
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Make
From: Paul Cercueil
Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
interface.
Signed-off-by: Paul Cercueil
Signed-off-by: Christophe Branchereau
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/display/p
On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
> By moving update_display_info() out of _drm_edid_connector_update() we
> make the function purely about adding modes.
I don't think that's quite true. The 4:2:0 stuff still updates
various display_info things from the mode parsing func
V5:
- Adds compat strings to bindings/display/msm/qcom,SoC-mdss.yaml - Dmitry
- Re-orders simple fixes to the start of the series to allow backports - Dmitry
- VDDA and drop of node-names - Krzysztof
- Deprecates qcom,dsi-ctrl-6g-qcm2290 - Krzysztof, Dmitry
- Expands set of updated files to includ
There's a typo in describing the core clock as an 'escape' clock. The
accurate description is 'core'.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/
power-domain is required for the sc7180 dispcc GDSC but not every qcom SoC
has a similar dependency for example the apq8064.
Most Qcom SoC's using mdss-dsi-ctrl seem to have the ability to
power-collapse the MDP without collapsing DSI.
For example the qcom vendor kernel commit for apq8084, msm822
The existing msm8916.dtsi does not depend on nor require operating points.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/display/msm/dsi-co
Currently we do not differentiate between the various users of the
qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
compatible string but, the hardware does have some significant differences
in the number of clocks.
To facilitate documenting the clocks add the following compat
Deprecate qcom,dsi-ctrl-6g-qcm2290 in favour of the desired format
qcom,qcm2290-dsi-ctrl.
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 36 +++
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git
a/Documentation/devicetree/bindings
Each compatible has a different set of clocks which are associated with it.
Add in the list of clocks for each compatible.
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 189 +-
1 file changed, 179 insertions(+), 10 deletions(-)
diff --git
a
Add silicon specific compatible qcom,msm8974-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8974 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 3 ++-
1 fi
Add silicon specific compatible qcom,sdm845-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm845 against the yaml documentation.
Reviewed-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/
Several MDSS yaml files exist which document the dsi sub-node.
For each existing SoC MDSS yaml, provide the right dsi compat string.
Signed-off-by: Bryan O'Donoghue
---
.../bindings/display/msm/qcom,msm8998-mdss.yaml | 8 +---
.../devicetree/bindings/display/msm/qcom,sc7180-mdss.ya
Add silicon specific compatible qcom,sc7280-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7280 against the yaml documentation.
Reviewed-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/
Add silicon specific compatible qcom,sm8250-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sm8250 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 --
1
When converting from .txt to .yaml we didn't include descriptions for the
existing regulator supplies.
- vdd
- vdda
- vddio
Add those descriptions into the yaml now as they were prior to the
conversion. In the .txt description we marked these regulators as required,
however, that requirement appe
Append silicon specific compatible qcom,apq8064-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for apq8064 against the yaml documentation.
Reviewed-by: David Heidelberg
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/d
Add the list of current compats absent the deprecated qcm2290 to the list
of dsi compats listed here.
Signed-off-by: Bryan O'Donoghue
---
.../bindings/display/msm/qcom,mdss.yaml | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree
Add silicon specific compatible qcom,msm8996-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8996 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 --
Add silicon specific compatible qcom,sc7180-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7180 against the yaml documentation.
Reviewed-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/
Add silicon specific compatible qcom,msm8953-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8953 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 4 ++--
1 file changed, 2 insertions(+),
When converting from .txt to .yaml dt-binding descriptions we appear to
have missed some of the previous detail on the number and names of
permissible clocks.
Fix this by listing the clock descriptions against the clock names at a
high level.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml
Add silicon specific compatible qcom,msm8916-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8916 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 ++-
1
The sdm630 can use the sdm660 mdss-dsi-ctrl compat. Currently it has the
same set of binding dependencies as sdm660.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch
Add silicon specific compatible qcom,sdm660-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm660 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 d
On Tue, 20 Dec 2022, Ville Syrjälä wrote:
> On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
>> By moving update_display_info() out of _drm_edid_connector_update() we
>> make the function purely about adding modes.
>
> I don't think that's quite true. The 4:2:0 stuff still updates
> va
On Tue, Dec 20, 2022 at 02:52:01PM +0200, Jani Nikula wrote:
> On Tue, 20 Dec 2022, Ville Syrjälä wrote:
> > On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
> >> By moving update_display_info() out of _drm_edid_connector_update() we
> >> make the function purely about adding modes.
>
Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
Representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Changes in v1:
- Few nit
On Tue, 20 Dec 2022, Ville Syrjälä wrote:
> On Tue, Dec 20, 2022 at 02:52:01PM +0200, Jani Nikula wrote:
>> On Tue, 20 Dec 2022, Ville Syrjälä wrote:
>> > On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
>> >> By moving update_display_info() out of _drm_edid_connector_update() we
>> >
On Tue, 20 Dec 2022 13:01:08 +0100, Christophe Branchereau wrote:
> From: Paul Cercueil
>
> Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
> interface.
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: C
It's missing the spi node, will do v4 once panel driver is reviewed.
On Tue, Dec 20, 2022, 15:10 Rob Herring wrote:
>
> On Tue, 20 Dec 2022 13:01:08 +0100, Christophe Branchereau wrote:
> > From: Paul Cercueil
> >
> > Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> > 24-b
Hi Tomi,
On Tue, Dec 20, 2022 at 04:12:29PM +0200, Tomi Valkeinen wrote:
> On 19/12/2022 21:10, Laurent Pinchart wrote:
> > On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
> >> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
> >>
> >> Signed-off-by: Tomi Valkeinen
> >> ---
>
On 20/12/2022 13:01, Christophe Branchereau wrote:
> From: Paul Cercueil
>
> Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
> interface.
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: Christophe Branche
https://bugzilla.kernel.org/show_bug.cgi?id=216625
--- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Pierre Ossman from comment #7)
>
> Is that also handled by mesa, or some other component?
Yes, mesa handles video APIs (VAAPI, OpenMAX, VDPAU) as well as 3D (OpenGL,
Vulka
1 - 100 of 141 matches
Mail list logo
