Zhenyu Wang 于2022年12月21日周三 11:01写道：
>
> On 2022.12.20 17:40:14 +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 function ppgtt_populate_spt_by_guest_entry does not notice
> > that, it
On 2022.12.20 17:40:14 +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 function ppgtt_populate_spt_by_guest_entry does not notice
> that, it will free spt again in its error path.
indent
On 2022-12-15 02:52:01, Dmitry Baryshkov wrote:
> On 14/12/2022 21:23, Marijn Suijten wrote:
> > On 2022-12-14 20:40:06, Dmitry Baryshkov wrote:
> >> On 14/12/2022 01:22, Marijn Suijten wrote:
> >>> This preliminary Display Stream Compression support package for
> >>> (initially tested on)
On 2022-12-16 14:20:52, Abhinav Kumar wrote:
>
>
> On 12/14/2022 5:08 PM, Dmitry Baryshkov wrote:
> > On 14/12/2022 21:30, Marijn Suijten wrote:
> >> On 2022-12-14 20:43:29, Dmitry Baryshkov wrote:
> >>> On 14/12/2022 01:22, Marijn Suijten wrote:
> [..]
> >>> We usually don't have DSC with
Ignore this, use rev2 instead, apologies for the mistake.
On Tue, 2022-12-20 at 14:03 -0800, Teres Alexis, Alan Previn wrote:
> If PXP arb-session is being attempted on older hardware SKUs or
> on hardware with older, unsupported, firmware versions, then don't
> report the failure with a
If PXP arb-session is being attempted on older hardware SKUs or
on hardware with older, unsupported, firmware versions, then don't
report the failure with a drm_error. Instead, look specifically for
the API-version error reply and drm_dbg that reply. In this case, the
user-space will eventually
If PXP arb-session is being attempted on older hardware SKUs or
on hardware with older, unsupported, firmware versions, then don't
report the failure with a drm_error. Instead, look specifically for
the API-version error reply and drm_dbg that reply. In this case, the
user-space will eventually
28.11.2022 18:23, Luca Ceresoli пишет:
> +static int tegra20_channel_capture_frame(struct tegra_vi_channel *chan,
> + struct tegra_channel_buffer *buf)
> +{
> + u32 value;
> + int err;
> +
> + chan->next_out_sp_idx++;
> +
> +
Panel is 800x1280 but mounted on a detachable form factor sideways.
Signed-off-by: Patrick Thompson
---
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
28.11.2022 18:23, Luca Ceresoli пишет:
> Tegra20 and other Tegra SoCs have a video input (VI) peripheral that can
> receive from either MIPI CSI-2 or parallel video (called respectively "CSI"
> and "VIP" in the documentation). The kernel currently has a staging driver
> for Tegra210 CSI capture.
On Thu, Dec 8, 2022 at 1:08 PM Jacek Lawrynowicz
wrote:
>
> VPU stands for Versatile Processing Unit and it's a CPU-integrated
> inference accelerator for Computer Vision and Deep Learning
> applications.
>
> The VPU device consist of following components:
> - Buttress - provides CPU to VPU
02.12.2022 11:11, Luca Ceresoli пишет:
> Hello Rob,
>
> Thanks for your review.
>
> On Thu, 1 Dec 2022 17:19:36 -0600
> Rob Herring wrote:
>
>> On Mon, Nov 28, 2022 at 04:23:16PM +0100, Luca Ceresoli wrote:
>>> VIP is the parallel video capture component within the video input
>>> subsystem of
On Mon, Dec 19, 2022 at 05:56:55PM +0100, Johan Jonker wrote:
> On Rockchip rk3399 a port node with one endpoint can be connected
> to a USB Type-C connector node.
> Add a port node to the phy-rockchip-inno-usb2.yaml file.
>
> Signed-off-by: Johan Jonker
> ---
>
On Tue 2022-12-20 13:45:19, Steven Rostedt wrote:
> [
> Linus,
>
> I ran the script against your latest master branch:
> commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
>
> As the timer_shutdown*() code is now in your tree, I figured
> we can start doing the conversions. At
On 12/15/22 13:34, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The check_reserve_boundaries function uses a lot of kernel stack,
> and it gets inlined by clang, which makes __drm_test_mm_reserve
> use even more of it, to the point of hitting the warning limit:
>
>
On Fri, 16 Dec 2022 13:44:59 -0800, Kuogee Hsieh wrote:
> To increase the flexibility of supporting different DP main link configuration
> at different platform, add both data-lanes and link-frequencies property
> into endpoint so that different platform can specify its own main link
>
[
Linus,
I ran the script against your latest master branch:
commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
As the timer_shutdown*() code is now in your tree, I figured
we can start doing the conversions. At least add the trivial ones
now as Thomas suggested that this gets
On Sat, Dec 17, 2022 at 03:40:24PM +0800, Liu Ying wrote:
> Hi Lucas,
>
> On Fri, 2022-12-16 at 22:07 +0100, Lucas Stach wrote:
> > The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> > core with a little bit of SoC integration around it.
> >
> > Signed-off-by: Lucas Stach
>
On Fri, Dec 16, 2022 at 10:07:39PM +0100, Lucas Stach wrote:
> The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> core with a little bit of SoC integration around it.
>
> Signed-off-by: Lucas Stach
> ---
> .../bindings/display/imx/fsl,imx8mp-hdmi.yaml | 69
On Sat, Dec 17, 2022 at 07:38:06PM +0100, Uwe Kleine-König wrote:
> On Fri, Dec 16, 2022 at 05:57:58PM -0600, Rob Herring wrote:
> > On Fri, Dec 16, 2022 at 06:50:04PM +0100, Uwe Kleine-König wrote:
> > > Hello,
> > >
> > > Changes since v2:
> > >
> > > - added allOf as Krzysztof requested
> >
On Wed, 14 Dec 2022 18:29:06 +0530, Jagan Teki wrote:
> Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC.
>
> Add dt-bingings for it.
>
> Cc: devicet...@vger.kernel.org
> Cc: Rob Herring
> Signed-off-by: Jagan Teki
> ---
> Changes for v10, v9:
> - none
>
>
On Fri, Dec 16, 2022 at 01:21:54PM +0100, Paul Cercueil wrote:
> Hi Krzysztof,
>
> Le vendredi 16 décembre 2022 à 12:21 +0100, Krzysztof Kozlowski a
> écrit :
> > On 16/12/2022 11:46, Paul Cercueil wrote:
> >
> > > > > properties:
> > > > > compatible:
> > > > > - const: ite,it66121
> > >
On Tue, 20 Dec 2022 12:36:19 +, Bryan O'Donoghue wrote:
> 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
On Tue, 20 Dec 2022 12:36:20 +, Bryan O'Donoghue wrote:
> 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
Hi
Am 19.12.22 um 21:55 schrieb Deepak R Varma:
On Sun, Dec 11, 2022 at 07:25:08PM +0530, Deepak R Varma wrote:
Hello,
May I please request a review and feedback on this patch proposal?
Added to drm-misc-next. Thanks for the patch.
Best regards
Thomas
Thank you,
./drv
A call to
Add dedicated helper to convert from XRGB to ARGB. Sets
all alpha bits to make pixels fully opaque.
v2:
* use cpubuf_to_le32()
* type fixes
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_format_helper.c | 53
Add dedicated helper to convert from XRGB to ARGB2101010. Sets
all alpha bits to make pixels fully opaque.
v2:
* set correct format in struct drm_framebuffer (Javier)
* use cpubuf_to_le32()
* type fixes
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez
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 available in
any color format at least.
Until now, the
Convert test input for format helpers from host byte order to
little-endian order. The current code does it the other way around,
but there's no effective difference to the result.
Signed-off-by: Thomas Zimmermann
---
.../gpu/drm/tests/drm_format_helper_test.c| 35 +--
1
Change the source-buffer type of le32buf_to_cpu() to __le32* to
reflect endianness. Result buffers are converted to local endianness,
so instantiate them from regular u8 or u32 types.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tests/drm_format_helper_test.c | 12 ++--
1 file
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, introduce
dedicated branches that handle this for
Fix to-RGB565 conversion helpers to store the result in little-
endian byte order. Update test cases as well.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 9 +
.../gpu/drm/tests/drm_format_helper_test.c| 20 ++-
2 files
Fix the selection of the fbdev emulation's color format and make
XRGB the only emulated color format. Resolves the blank screen
in cases where video= specifies an unsupported color format. Also
resolves the issues around current format-conversion helpers.
Version 2 of the patchset fixes the
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 as ARGB1555 because
of the different use of depth
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 emulated format is XRGB, which is
required as
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: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fb_helper.c
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: Javier Martinez Canillas
---
RGB888 is different than the other formats as most of its pixels are
unaligned and therefore helper functions do not use endianness conversion
helpers. Comment on this in the source code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c| 1 +
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 formats.
v2:
* test 15-bit results with
On Mon, Dec 19, 2022 at 05:56:35PM +0100, Johan Jonker wrote:
> Add new converted rockchip,lvds.yaml to grf.yaml file.
> Prepare for more SoCs with lvds output.
>
> Signed-off-by: Johan Jonker
> ---
> .../devicetree/bindings/soc/rockchip/grf.yaml | 10 +++---
> 1 file changed, 7
On Mon, 19 Dec 2022 17:54:16 +0100, Johan Jonker wrote:
> Convert rockchip-lvds.txt to YAML.
>
> Changed:
> Add power-domains property.
> Requirements between PX30 and RK3288
>
> Signed-off-by: Johan Jonker
> ---
>
> Changed V3:
> Filename matching compatible style
> Drop "Regulator
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,
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
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
> >> ---
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
> >
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:
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
>>
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
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.
>
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
>
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
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
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
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,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
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
---
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 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
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
---
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
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
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
---
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 +---
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
---
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
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
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
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
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
---
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,
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
---
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
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
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
---
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 +
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
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,
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
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
> ---
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
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
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:
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.
> > >
> >
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 +-
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
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
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
> >
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
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
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
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
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
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
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,
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
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
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
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
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
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
1 - 100 of 141 matches
Mail list logo
