On 28/12/2022 14:11, Bryan O'Donoghue wrote:
> Add in missing qcom,dsi-phy-regulator-ldo-mode to the 28nm DSI PHY.
> When converting from .txt to .yaml we missed this one.
>
> Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI
> bindings")
> Reviewed-by: Dmitry Baryshkov
> Sig
On Wed, Dec 28, 2022 at 11:16:11PM +0100, Stefan Wahren wrote:
> Hi Maíra,
>
> Am 28.12.22 um 20:49 schrieb Maíra Canal:
> > Hi Stefan,
> >
> > I was able to reproduce this error on drm-misc-next. I bisected,
> > and I got into commit 6bed2ea3cb38. I noticed that the crtc->mutex is
> > being lock
On 27/12/22 22:03, Javier Martinez Canillas wrote:
From: Ondrej Jirman
The phone's display is using Hannstar LCD panel, and Goodix based
touchscreen. Support it.
Signed-off-by: Ondrej Jirman
Co-developed-by: Martijn Braam
Signed-off-by: Martijn Braam
Co-developed-by: Kamil Trzciński
Signed
On 27/12/22 22:03, Javier Martinez Canillas wrote:
From: Kamil Trzciński
The driver is for panels based on the Himax HX8394 controller, such as the
HannStar HSD060BHW4 720x1440 TFT LCD panel that uses a MIPI-DSI interface.
Signed-off-by: Kamil Trzciński
Co-developed-by: Ondrej Jirman
Signed-
On 25-12-2022 13:17, Deepak R Varma wrote:
> The refcount_* APIs are designed to address known issues with the
> atomic_t APIs for reference counting. They provide following distinct
> advantages:
>- protect the reference counters from overflow/underflow
>- avoid use-after-free errors
>
Switch to gpiod_set_value_cansleep() in sii902x_reset().
This is relevant if the reset line is tied to a I2C GPIO
controller.
Signed-off-by: Wadim Egorov
---
drivers/gpu/drm/bridge/sii902x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c
On Thu, Dec 22, 2022, at 12:46, Andrzej Hajda wrote:
> __xchg will be used for non-atomic xchg macro.
>
> Signed-off-by: Andrzej Hajda
> ---
> arch/arc/include/asm/cmpxchg.h | 4 ++--
Reviewed-by: Arnd Bergmann
for all the arch/*/include/asm/cmpxchg.h changes.
Since these patches are all the s
On 12/29/22 05:37, Maxime Ripard wrote:
On Wed, Dec 28, 2022 at 11:16:11PM +0100, Stefan Wahren wrote:
Hi Maíra,
Am 28.12.22 um 20:49 schrieb Maíra Canal:
Hi Stefan,
I was able to reproduce this error on drm-misc-next. I bisected,
and I got into commit 6bed2ea3cb38. I noticed that the crtc->m
On Wed, Dec 28, 2022 at 3:46 AM Javier Martinez Canillas
wrote:
>
> On Tue, Dec 27, 2022 at 8:37 PM Jagan Teki wrote:
> >
> > On Wed, Dec 28, 2022 at 12:58 AM Javier Martinez Canillas
> > wrote:
> > >
> > > Hello Jagan,
> > >
> > > On Tue, Dec 27, 2022 at 7:16 PM Jagan Teki
> > > wrote:
> > >
Forgive me late response - Holidays,
On 22.12.2022 18:21, Andrew Morton wrote:
On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda
wrote:
Hi all,
I hope there will be place for such tiny helper in kernel.
Quick cocci analyze shows there is probably few thousands places
where it could be useful
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 941aae3263153cea91cb306cc889951486e16634
commit: 5ea6b17027810ffbdb5bea7d0a2b1d312dd1021c [25/26] drm/panel: Add
prepare_prev_first flag to drm_panel
config: nios2-randconfig-m041-20221228
compiler: nios2-linux-gcc (GCC) 12.1
Add bindings for the display hardware on SM8150.
Reviewed-by: Rob Herring
Signed-off-by: Konrad Dybcio
---
v1 -> v2:
- Pick up tags
.../bindings/display/msm/qcom,sm8150-dpu.yaml | 92 +
.../display/msm/qcom,sm8150-mdss.yaml | 330 ++
2 files changed, 422 insertions
Add required nodes for MDSS and hook up provided clocks in DISPCC.
This setup is almost identical to 8[23]50.
Tested-by: Marijn Suijten # Xperia 5
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
v1 -> v2:
- Pick up tags
- mdss@ -> display-subsystem@
arch/arm64/boot/dts/qcom/sm815
Years after the SoC support has been added, it's high time for it to
get dispcc going. Add the node to ensure that.
Tested-by: Marijn Suijten # Xperia 5
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
v1 -> v2:
- Pick up tags
- Remove required-opps
- Move power-domains up
arch/arm
Hi,
On 12/27/22 22:28, Guilherme G. Piccoli wrote:
> Hi Dmitry / Christian, thanks for the fix!
>
> (And thanks Melissa for pointing that, saving me lots of time in
> research heh)
>
> Is this fix planned to be released on 6.2-rc cycle? I've just tested it
> on Steam Deck, and it resolved a lock
So far the adreno quirks have all been assigned with an OR operator,
which is problematic, because they were assigned consecutive integer
values, which makes checking them with an AND operator kind of no bueno..
Switch to using BIT(n) so that only the quirks that the programmer chose
are taken int
On 2022-12-29 11:18:45, Konrad Dybcio wrote:
> So far the adreno quirks have all been assigned with an OR operator,
> which is problematic, because they were assigned consecutive integer
> values, which makes checking them with an AND operator kind of no bueno..
>
> Switch to using BIT(n) so that
__xchg will be used for non-atomic xchg macro.
Signed-off-by: Andrzej Hajda
Reviewed-by: Arnd Bergmann
---
arch/alpha/include/asm/cmpxchg.h | 6 +++---
arch/arc/include/asm/cmpxchg.h | 4 ++--
arch/arm/include/asm/cmpxchg.h | 4 ++--
arch/arm64/include/asm/cmpxchg.h | 4 ++--
On Thu, 29 Dec 2022 at 12:05, Konrad Dybcio wrote:
>
> Years after the SoC support has been added, it's high time for it to
> get dispcc going. Add the node to ensure that.
>
> Tested-by: Marijn Suijten # Xperia 5
> Reviewed-by: Marijn Suijten
> Signed-off-by: Konrad Dybcio
Reviewed-by: Dmitry
Hello Jagan,
On Thu, 29 Dec 2022 at 10:54 Jagan Teki wrote:
>
[…]
> > > compatible:
> > > items:
> > > - enum:
> > > - hannstar,hsd060bhw4
> > > - const: himax,hx8394
> > >
> > > himax,hx8394 is the actual controller and is denoted as fallback
> compatible.
> > >
> >
Hello Tom,
On Thu, 29 Dec 2022 at 10:39 Tom Fitzhenry wrote:
> On 27/12/22 22:03, Javier Martinez Canillas wrote:
> > From: Ondrej Jirman
> >
> > The phone's display is using Hannstar LCD panel, and Goodix based
> > touchscreen. Support it.
> >
> > Signed-off-by: Ondrej Jirman
> > Co-developed
On Tue, Dec 27, 2022 at 8:29 PM Jeffrey Hugo wrote:
>
> On 12/26/2022 2:32 PM, Oded Gabbay wrote:
> > Move the habanalabs.h uapi file from include/uapi/misc to
> > include/uapi/drm, and rename it to habanalabs_accel.h.
> >
> > This is required before moving the actual driver to the accel
> > subsy
V3:
Moves change to last item in list so as not to break-up grouping of
reg/reg-names
V2:
This is the one remaining patch I had from a previous series for
mdss-dsi-ctrl and the dsi-phy. The mdss-dsi-ctrl set became a bigger so I
split out the 28nm phy fixes.
I'm resubmitting with Dmitry's RB as
Add in missing qcom,dsi-phy-regulator-ldo-mode to the 28nm DSI PHY.
When converting from .txt to .yaml we missed this one.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/d
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. This patch set adds support for Tegra20 VIP
captu
Some fields are irrelevant for Tegra20/VIP. Add a note to clarify that.
Signed-off-by: Luca Ceresoli
---
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/tegra-video/vi.h
The Tegra20 VI peripheral can receive parallel input from the VIP parallel
input module. Add it to the allowed properties and augment the existing
nvidia,tegra20-vi example to show a 'vip' property.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Luca Ceresoli
---
Changed in v3 (suggested by R
Tegra20 supports planar YUV422 capture, which can be implemented by writing
U and V base address registers in addition to the "main" base buffer
address register.
It also supports H and V flip, which among others requires to write the
start address (i.e. the 1st offset to write, at the end of the
tegra_channel_fmt_align() takes care of the size constraints, alignment and
rounding requirements of the Tegra210 VI peripheral. Tegra20 has different
constraints.
In preparation for adding Tegra20 support, move this function to a new op
in the soc-specific `struct tegra_vi_ops` .
Also move to te
tegra_vi_channels_alloc() can primarily fail for two reasons:
1. "ports" node not found
2. port_num > vi->soc->vi_max_channels
Case 1 prints nothing, case 2 has a dev_err(). The caller [tegra_vi_init()]
has a generic dev_err() on any failure. This mean that in case 2 we print
two messages, and
The tegra_default_format in vi.c is specific to Tegra210 CSI.
In preparation for adding Tegra20 VIP support, move the default format to a
new field in the soc-specific `struct tegra_vi_soc`. Instead of an entire
format struct, only store a pointer to an item in the existing format
array.
No funct
The CSI module does not handle all the MIPI lane calibration procedure,
leaving a small part of it to the VI module. In doing this,
tegra_channel_enable_stream() (vi.c) manipulates the private data of the
upstream subdev casting it to struct 'tegra_csi_channel', which will be
wrong after introducin
struct tegra_vi_graph_entity is an internal implementation detail of the VI
module. Move its declaration from vi.h to vi.c.
Signed-off-by: Luca Ceresoli
---
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 13 +
drivers/staging/media/tegra-video/vi.h |
of_node_put(node) does nothing if node == NULL, so it can be moved to the
cleanup section at the bottom.
Signed-off-by: Luca Ceresoli
---
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/dri
There is only a pointer reference to struct tegra_vi in video.h, thus vi.h
is not needed.
Signed-off-by: Luca Ceresoli
---
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/video.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/tegra-video/video.
Add "skip" in "so we can *skip* the current channel" or it doesn't make
sense.
Also add articles where appropriate to fix English grammar.
Signed-off-by: Luca Ceresoli
---
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 6 +++---
1 file changed, 3 insertions(+),
We are about to add support for the Tegra20 parallel video capture, which
has no TPG. In preparation for that, limit the VIDEO_TEGRA_TPG option to
Tegra210 which is the only implementation currently provided by this
driver.
Signed-off-by: Luca Ceresoli
---
No changes in v3
No changes in v2
---
In preparation to implement Tegra20 parallel video capture, add a variable
to hold the required syncpt and document all the syncpt variables.
Signed-off-by: Luca Ceresoli
---
Changed in v3:
- recycle mw_ack_sp[0] instead of adding out_sp
No changes in v2
---
drivers/staging/media/tegra-video
This declaration is used only in csi.c, no need to export it elsewhere.
Signed-off-by: Luca Ceresoli
---
This patch was added in v3.
---
drivers/staging/media/tegra-video/csi.c | 4
drivers/staging/media/tegra-video/csi.h | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --
The Tegra20 VI needs an additional operation to enable the VI, add an
operation for that.
Signed-off-by: Luca Ceresoli
---
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 7 +++
drivers/staging/media/tegra-video/vi.h | 4
2 files changed, 11 insertions(+
The .vidioc_enum_fmt_vid_cap (called tegra_channel_enum_format() here)
should return all the supported formats. Instead the current implementation
computes the intersection between the formats it supports and those
supported by the first subdev in the stream (typically the image sensor).
Remove al
VIP is the parallel video capture component within the video input
subsystem of Tegra20 (and other Tegra chips, apparently).
Signed-off-by: Luca Ceresoli
---
Changed in v3:
- remove channel@0 node (Krzysztof, Rob, Dmitry)
- add myself as a maintainer of the whole Tegra video driver (Dmitry)
Tegra20 can do horizontal and vertical image flip, but Tegra210 cannot
(either the hardware, or this driver).
In preparation to adding Tegra20 support, add a flag in struct tegra_vi_soc
so the generic vi.c code knows whether the flip controls should be added or
not.
Also provide a generic impleme
tegra_channel_host1x_syncpt_init() gets the host1x syncpts needed for the
Tegra210 implementation, and tegra_channel_host1x_syncpts_free() puts
them.
Tegra20 needs to get and put a different syncpt. In preparation for adding
Tegra20 support, move these functions to new ops in the soc-specific
`str
The VI peripheral of Tegra supports capturing from MIPI CSI-2 or parallel
video (called VIP in the docs).
The staging tegra-video driver currently implements MIPI CSI-2 video
capture for Tegra210. Add support for parallel video capture (VIP) on
Tegra20. With the generalizations added to the VI dri
Clarify what this function does.
Signed-off-by: Luca Ceresoli
---
No changes in v3
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/media/tegra-video/vi.c
b/drivers/staging/media/tegra-video/vi.c
index 9dba6e97e
Hello Guido,
On 12/28/22 13:01, Guido Günther wrote:
> Hi Javier,
> Could you please also cc maintainers on the actual macro addition since
> it's hard to review without seeing what the code gets changed to
> (especially when there's multiple revisions). I assume
>
Sure, I will do it if post anot
Hello Mario,
On 12/28/22 17:30, Mario Limonciello wrote:
> Removing the firmware framebuffer from the driver means that even
> if the driver doesn't support the IP blocks in a GPU it will no
> longer be functional after the driver fails to initialize.
>
> This change will ensure that unsupported
Hi Javier,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.2-rc1 next-20221226]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--
From: Thomas Zimmermann Sent: Monday, December 19, 2022
8:05 AM
>
> 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
> ---
> drivers/
On Thu, 22 Dec 2022 03:46:29 PST (-0800), andrzej.ha...@intel.com wrote:
__xchg will be used for non-atomic xchg macro.
Signed-off-by: Andrzej Hajda
---
arch/riscv/include/asm/atomic.h | 2 +-
arch/riscv/include/asm/cmpxchg.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --
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 canceling the mapping of DMA address and freeing sub
On Fri, 23 Dec 2022 02:10:07 +, Bryan O'Donoghue wrote:
> V6:
> - Squashes a number of patches per Krzysztof's comments on bisectability
> - Adds in Acked-by Rob and Krzysztof
>
> V5:
> - Adds compat strings to bindings/display/msm/qcom,SoC-mdss.yaml - Dmitry
> - Re-orders simple fixes to the
On Thu, 29 Dec 2022 11:05:08 +0100, Konrad Dybcio wrote:
> Add bindings for the display hardware on SM8150.
>
>
Applied, thanks!
[2/3] arm64: dts: qcom: sm8150: Add DISPCC node
commit: 2ef3bb17c45c5b83204a845bbe4045eed11bc759
[3/3] arm64: dts: qcom: sm8150: Wire up MDSS
commit: 9887
Patches 1-10 are:
Reviewed-by: Alex Deucher
On Wed, Dec 28, 2022 at 11:31 AM Mario Limonciello
wrote:
>
> One of the first thing that KMS drivers do during initialization is
> destroy the system firmware framebuffer by means of
> `drm_aperture_remove_conflicting_pci_framebuffers`
>
> This means
On Wed, Dec 28, 2022 at 11:32 AM Mario Limonciello
wrote:
>
> If PSP microcode is required but not available during early init, the
> firmware framebuffer will have already been released and the screen will
> freeze.
>
> Move the request for PSP microcode into the IP discovery phase
> so that if i
On 29/12/2022 07:15, Dmitry Osipenko wrote:
> [...]
> I'll push the patch to misc-fixes as soon as it will be rebased on
> 6.2-rc. Thanks!
>
> Best regards,
> Dmitry
>
Thank you Dmitry, much appreciated!
Cheers,
Guilherme
It took me a way longer to finish than I expected. And more patches that
I previously hoped (despite having several patches already being merged
from v1).
This patchset brings in multirect usage to support using two SSPP
rectangles for a single plane. Full virtual planes support is omitted
from th
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 42 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 42
The function dpu_plane_sspp_atomic_update() updates pdpu->is_rt_pipe
flag, but after the commit 854f6f1c653b ("drm/msm/dpu: update the qos
remap only if the client type changes") it sets the flag late, after all
the qos functions have updated QoS programming. Move the flag update
back to the place
Follow the example of all other hw blocks and initialize SSPP blocks in
Resource Manager.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 17 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 22 ++
drivers/gpu/drm/msm/disp/dpu1/dpu
Wrap SSPP and multirect index/mode into a single structure that
represents software view on the pipe used.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 9 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 16 ++-
drivers/gpu/drm/
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (allocated during atomic check) rather
than part of a plane (allocated during boot).
Signed-off-by: Dmitry Baryshkov
---
drivers/
There no more need for the dpu_plane_pipe() function, crtc code can
access pstate->pipe_hw.idx directly.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
drivers/gpu/drm/msm/di
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 57 +++--
1 file changed, 29 insertions(+), 28 deleti
The pipe's layout is not cached, corresponding data structure is zeroed
out each time in the dpu_plane_sspp_atomic_update(), right before the
call to _dpu_plane_set_scanout() -> dpu_format_populate_layout().
Drop plane_addr comparison against previous layout and corresponding
EAGAIN handling.
Sig
There is no need to pass full dpu_hw_pipe_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 7 +++
drivers/gpu/drm/msm/d
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms. We are going to break
the 1:1 correspondence between planes and SSPPs, so it makes no sense
anymore to create SSPP debugfs entries in dpu_plane.c
Reviewed-by: Abhinav Kumar
Signed
The dpu_crtc_atomic_check() compares blending stage with DPU_STAGE_MAX
(maximum amount of blending stages supported by the driver), however we
should compare it against .max_mixer_blendstages, the maximum blend
stage supported by the mixer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++
drivers/
Where feasible, use dpu_sw_pipe rather than a combo of dpu_hw_sspp and
multirect_index/_mode arguments.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 59 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 46 +--
Remove dpu_hw_fmt_layout instance from struct dpu_hw_pipe_cfg, leaving
only src_rect and dst_rect. This way right and left pipes will have
separate dpu_hw_pipe_cfg isntances, while the layout is common to both
of them.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp
Since the driver uses clipped src coordinates, there is no need to check
against the fb coordinates. Remove corresponding checks and inline
dpu_plane_validate_src().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 30 ---
1 file changed, 10 ins
Neither source split nor multirect are properly supported at this
moment. Both of these checks depend on normalized_zpos being equal for
several planes (which is never the case for normalized zpos).
Drop these checks to simplify dpu_crtc_atomic_check(). The actual
support for either of these featur
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not enbaling setup_multirect callback. Add corresponding SmartDMA SSPP
feature bits to dpu hw cat
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 91 +--
1 file changed,
Typically SSPP can support rectangle with width up to 2560. However it's
possible to use multirect feature and split source to use the SSPP to
output two consecutive rectangles. This commit brings in this capability
to support wider screen resolutions.
Signed-off-by: Dmitry Baryshkov
---
drivers
Rework the code flushing CSC settings for the plane. Separate out the
pipe and pipe_cfg as a preparation for r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 45 +--
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a
Rework bandwidth/clock calculation functions to use mode directly rather
than fetching it through the plane data.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 39 ++-
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/gp
Rework static color fill code to separate the pipe / pipe_cfg handling.
This is a preparation for the r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 70 +--
1 file changed, 41 insertions(+), 29 deletions(-)
diff --git a/driver
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 98 +++
1 file changed, 47 ins
The helper drm_atomic_helper_check_plane_state() already checks whether
the scaled and clipped plane falls into the CRTC visible region (and
clears plane_state->visible if it doesn't). Drop the redundant check
from dpu_crtc_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/
Now as all accesses to pipe_cfg and pstate have been cleaned, re-add
struct dpu_hw_pipe_cfg back to dpu_plane_state, so that
dpu_plane_atomic_check() and dpu_plane_atomic_update() do not have a
chance to disagree about src/dst rectangles (currently
dpu_plane_atomic_check() uses unclipped rectangles
Split pipe-dependent code from dpu_plane_sspp_atomic_update() into the
separate function dpu_plane_sspp_update_pipe(). This is one of
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 113 --
1 file chan
Rework _dpu_crtc_blend_setup_mixer() to split away pipe handling to a
separate functon. This is a preparation for the r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 86 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 ++-
2
If vc4_hdmi_reset_link() returns -EDEADLK, it means that a deadlock
happened in the locking context. This situation should be addressed by
dropping all currently held locks and block until the contended lock
becomes available. Currently, vc4 is not dealing with the deadlock
properly, producing the
On Mon, Dec 19, 2022 at 8:52 PM Christophe Branchereau
wrote:
> Changes since v2:
This v3 patch set applied and pushed to drm-misc-next.
There were some minor checkpatch warnings that I just fixed
up while applying. Check the result in linux-next once it percolates.
Yours,
Linus Walleij
On Thu, Dec 15, 2022 at 7:52 PM Chris Morgan wrote:
> From: Chris Morgan
>
> Add helper function to find DSI host for devices where DSI panel is not
> a minor of a DSI bus (such as the Samsung AMS495QA01 panel or the
> official Raspberry Pi touchscreen display).
>
> Signed-off-by: Chris Morgan
From: Rob Clark
RB_MRT_FLAG_BUFFER is 0x8903->0xa91a inclusive.. don't split it (with a
hole) in the ps_cluster_rac and don't accidentially re-dump part of the
range in ps_cluster_rbp.
Signed-off-by: Rob Clark
---
I'm not 100% sure about this, because the RB_RB_SUB_BLOCK_SEL_CNTL_CD
stuff makes
https://bugzilla.kernel.org/show_bug.cgi?id=216840
--- Comment #3 from Salvador Pérez (carlosalvat...@gmail.com) ---
Hi, Alex,
I am afraid that not setting amdgpu.vm_update_mode=3 is not an option. If I try
to play Cities Skylines (linux native version), the game goes 1 fps and the
system is ext
https://bugzilla.kernel.org/show_bug.cgi?id=216840
--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Salvador Pérez from comment #3)
> Hi, Alex,
>
> I am afraid that not setting amdgpu.vm_update_mode=3 is not an option. If I
> try to play Cities Skylines (linux native ver
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 12cf36c7125e5313249230e6235b4bfb2c4f765f
commit: 78df640394cd0de88b9f84982f90f2079e60a5b7 [6/7] drm/vc4: dsi: Convert to
using a bridge instead of encoder
config: xtensa-randconfig-r002-20221230
compiler: xtensa-linux-gcc (GC
One of the first thing that KMS drivers do during initialization is
destroy the system firmware framebuffer by means of
`drm_aperture_remove_conflicting_pci_framebuffers`
This means that if for any reason the GPU failed to probe the user
will be stuck with at best a screen frozen at the last thing
The special case for the one dGPU has been moved into
`amdgpu_ucode_ip_version_decode`, so simplify this code.
Reviewed-by: Alex Deucher
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff
Removing the firmware framebuffer from the driver means that even
if the driver doesn't support the IP blocks in a GPU it will no
longer be functional after the driver fails to initialize.
This change will ensure that unsupported IP blocks at least cause
the driver to work with the EFI framebuffer
This will allow other parts of the driver that currently special
case firmware file names to before IP version style naming to just
have a single call to `amdgpu_ucode_ip_version_decode`.
Signed-off-by: Mario Limonciello
---
v2->v3:
* Fixes for GFX9 SDMA
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uc
If SDMA microcode is not available during early init, the firmware
framebuffer will have already been released and the screen will
freeze.
Move the request from SDMA microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Signed-off-by: Mario Limonciello
---
If MES microcode is required but not available during early init, the
firmware framebuffer will have already been released and the screen will
freeze.
Move the request for MES microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Reviewed-by: Alex Deucher
S
Remove the special casing from SMU v11 code. No intended functional
changes.
Signed-off-by: Mario Limonciello
---
.../gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c| 35 ++-
1 file changed, 3 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
If GFX11 microcode is required but not available during early init, the
firmware framebuffer will have already been released and the screen will
freeze.
Move the request for GFX11 microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Reviewed-by: Alex Deuche
1 - 100 of 105 matches
Mail list logo
