On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote:
> Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST")
> WERROR
> now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
>
> builds. This leads to some interesting failures, each resolved in this
On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote:
> Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST")
> WERROR
> now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
>
> builds. This leads to some interesting failures, each resolved in this
Make the offb (Open Firmware frame buffer) driver tristate,
i.e., so that it can be built as a loadable module.
However, it still depends on the setting of DRM_OFDRM
so that both of these drivers cannot be builtin at the same time
nor can one be builtin and the other one a loadable module.
On Wed, Nov 16, 2022 at 2:03 PM Matti Vaittinen
wrote:
>
> Simplify using the devm_regulator_get_enable_optional(). Also drop the
> seemingly unused struct member 'hdmi_supply'.
Personally I'd replace "seemingly" with "now" because hdmi_supply was
used before (although only in this one function,
From: Chris Wilson
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Chris commit "drm/i915: Introduce guard pages to i915_vma" was
"cunningly" changing display_alignment to u32 from u64. The
reason is that the display GGTT is and will be limited o 4GB.
Put it in a separate patch and use "max(...)" instead of
"max_t(64, ...)" when asigning the value. We can safely
From: Chris Wilson
Introduce the concept of padding the i915_vma with guard pages before
and after. The major consequence is that all ordinary uses of i915_vma
must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
directly, as the drm_mm_node will include the guard pages that
From: Chris Wilson
We already wrap i915_vma.node.start for use with the GGTT, as there we
can perform additional sanity checks that the node belongs to the GGTT
and fits within the 32b registers. In the next couple of patches, we
will introduce guard pages around the objects _inside_ the
This reverts commit 2ef6efa79fecd5e3457b324155d35524d95f2b6b.
Checking the presence if the IRST (Intel Rapid Start Technology)
through the ACPI to decide whether to rebuild or not the GGTT
puts us at the mercy of the boot firmware and we need to
unnecessarily rely on third parties.
Because now
Hi,
This series adds guards around vma's but setting a pages at the
beginning and at the end that work as padding.
The first user of the vma guard are scanout objects which don't
need anymore to add scratch to all the unused ggtt's and speeding
up up considerably the boot and resume by several
On Mon, Nov 07, 2022 at 03:24:12PM +0800, Nancy.Lin wrote:
> Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
> the component exists in the path.
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: AngeloGioacchino Del Regno
>
> Reviewed-by: CK Hu
> Tested-by: AngeloGioacchino Del
On 11/23/22 21:09, Jagan Teki wrote:
On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut wrote:
On 11/17/22 14:04, Marek Szyprowski wrote:
On 17.11.2022 05:58, Marek Vasut wrote:
On 11/10/22 19:38, Jagan Teki wrote:
DSI host initialization handling in previous exynos dsi driver has
some pitfalls.
Fix documentation build errors for amdgpu: correct the filename.
Error: Cannot open file ../drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
Error: Cannot open file ../drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
Error: Cannot open file ../drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
WARNING: kernel-doc
Currently, there are issues with enabling PSR-SU + DSC. This stems from
the fact that DSC imposes a slice height on transmitted video data and
we are not conforming to that slice height in PSR-SU regions. So, pass
slice_height into su_y_granularity to feed the DSC slice height into
PSR-SU code.
Hi all,
This RFC patch series adds a DRM driver for the good old Atari
ST/TT/Falcon hardware. It was developed and tested (only) on the ARAnyM
emulator.
Supported formats:
- C[1248],
- RG16 (both standard DRM (little-endian) and native (big-endian)),
- XR24.
Patch overview:
1.
From: Thomas Zimmermann
The mode fix-up function for simple display helpers is equivalent to the
regular pipeline's CRTC mode fix-up function. It's called to adjust the
CRTC's display mode for the encoder. Add this function for DRM fbconv
helpers.
Signed-off-by: Thomas Zimmermann
The various mode->*specified flags are not handled in an uniform way:
some flags are set by the corresponding drm_mode_parse_cmdline_*()
function, some flags by the caller of the function, and some flags by
both.
Make this uniform by making this the responsibility of the various
parsing helpers,
Add transpose operations on two 32-bit words, using normal or reverse
order.
To be used by the Atari DRM driver.
Signed-off-by: Geert Uytterhoeven
---
drivers/video/fbdev/c2p_core.h | 38 ++
1 file changed, 38 insertions(+)
diff --git
Supported formats:
- C[1248],
- RG16 (both standard DRM (little-endian) and native (big-endian)),
- XR24.
RG16 and XR24 are only supported with the underlying RGB565 hardware
mode on Falcon, and are subject to hardware restrictions (limited to
e.g. "qvga" and "hvga" modes).
All formats use
Hi all,
This patch series contains improvements for specifying video modes on the
kernel command line.
I don't expect the second patch to be acceptable as-is, but it's a
dependency for posting the RFC Atari DRM driver...
Changes compared to v2[1]:
- Drop applied and obsolete patches,
The mode parsing code recognizes named modes only if they are explicitly
listed in the internal named mode list, which is currently limited to
"NTSC" and "PAL".
Provide a mechanism for drivers to override this list to support custom
modes.
Ideally, this list should just come from the driver's
On Thu, Nov 24, 2022 at 1:43 AM Christian König
wrote:
>
> Am 24.11.22 um 10:05 schrieb Daniel Vetter:
> > On Thu, Nov 24, 2022 at 08:03:09AM +0100, Christian König wrote:
> >> Am 23.11.22 um 20:35 schrieb T.J. Mercier:
> >>> I've been collecting these typo fixes for a while and it feels like
>
Applied the series. Thanks!
Alex
On Tue, Nov 22, 2022 at 6:13 AM Xiongfeng Wang
wrote:
>
> As comment of pci_get_class() says, it returns a pci_device with its
> refcount increased and decreased the refcount for the input parameter
> @from if it is not NULL.
>
> If we break the loop in
The pull request you sent on Fri, 25 Nov 2022 13:47:02 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-11-25
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6fe0e074e76985c7be3eaa7a8fd51401a8999cae
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, Nov 25, 2022 at 5:21 AM Christian König
wrote:
>
> We already fallback to a dummy BO with no backing store when we
> allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
>
> Drop all those workarounds and generalize this for GTT as well. This
> fixes ENOMEM issues with
Hi Dave, Daniel,
More stuff for 6.2. Mostly bug fixes at this point.
The following changes since commit 3d335a523b938a445a674be24d1dd5c7a4c86fb6:
Merge tag 'drm-intel-next-2022-11-18' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-11-23 09:15:44
+1000)
are available in
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
> drivers vmap/vunmap GEM buffer memory during the atomic commit.
> Shadow-plane helpers automate this process.
>
> Patches 1 to 4 prepare the MIPI code for the change and simplify
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Call drm_dev_enter() and drm_dev_exit() in the outer-most callbacks
> of the modesetting pipeline. If drm_dev_enter() fails, the driver can
> thus avoid unnecessary work.
>
> Signed-off-by: Thomas Zimmermann
> ---
Makes sense in order to make
Add a work function to send a GPU reset uevent and scheduled it during
a GPU reset.
Co-developed-by: Shashank Sharma
Signed-off-by: Shashank Sharma
Signed-off-by: André Almeida
---
V3:
- Merge two last commits
V2: Addressed review comments from Christian
- Changed the name of the work
From: Shashank Sharma
Add a sysfs event to notify userspace about GPU resets providing:
- PID that triggered the GPU reset, if any. Resets can happen from
kernel threads as well, in that case no PID is provided
- Information about the reset (e.g. was VRAM lost?)
Co-developed-by: André Almeida
This patchset adds a udev event for DRM device's resets.
Userspace apps can trigger GPU resets by misuse of graphical APIs or driver
bugs. Either way, the GPU reset might lead the system to a broken state[1], that
might be recovered if user has access to a tty or a remote shell. Arguably, this
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Introduce struct drm_mipi_dbi_plane_state that contains state related to
> MIPI DBI. It currently only inherits from struct drm_shadow_plane_state,
> so that MIPI DBI drivers can use the vmap'ed GEM-buffer memory. Implement
> state helpers, the
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Move the vmap/vunmap blocks from the inner fb_dirty helpers into the
> MIPI DBI update helpers. The function calls can result in waiting and/or
> processing overhead. Reduce the penalties by executing the functions once
> in the outer-most
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Introduce DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS to initialize MIPI-DBI
> helpers to default values and convert drivers. The prepare_fb function
> set by some drivers is called implicitly by simple-kms helpers, so leave
> it out.
>
>
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> MIPI DBI drivers validate each mode against their native resolution.
> Add this test to st7586.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> MIPI DBI drivers validate each mode against their native resolution.
> Add this test to ili9225.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> The helper drm_gem_simple_display_pipe_prepare_fb() is simple-KMS'
> default implementation for prepare_fb. Remove the call from drivers
> that set it explicitly. Then inline the helper into the only caller
> within simple-kms helpers and remove
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 9e46a79967326efb03c481ddfd58902475bd920d Add linux-next specific
files for 20221125
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com
https
Le mercredi 23 novembre 2022 à 17:33 +0100, Daniel Vetter a écrit :
> On Wed, Nov 23, 2022 at 10:33:38AM +0200, Pekka Paalanen wrote:
> > On Tue, 22 Nov 2022 18:33:59 +0100
> > Christian König wrote:
> >
> > > We should have come up with dma-heaps earlier and make it clear that
> > > exporting
On Wed, Nov 23, 2022 at 10:15:25AM +0100, AngeloGioacchino Del Regno wrote:
> Il 22/11/22 15:39, Nícolas F. R. A. Prado ha scritto:
> > mtk_drm_bind() can fail, in which case drm_dev_put() is called,
> > destroying the drm_device object. However a pointer to it was still
> > being held in the
Hi Dave, Daniel,
The following changes since commit c2418f911a31a266af4fbaca998dc73d3676475a:
gpu: host1x: Avoid trying to use GART on Tegra20 (2022-11-18 09:33:20 +0100)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/tegra.git tags/drm/tegra/for-6.2-rc1
for
On 10/5/22 06:51, Jani Nikula wrote:
> Currently i915 assumes all drm_connectors it encounters are embedded in
> intel_connectors that i915 allocated. The drm_writeback_connector forces
> a design where this is not the case; we can't provide our own connector,
> and writeback embeds the
Hi,
On Fri, Nov 25, 2022 at 11:10:02AM -0300, Maíra Canal wrote:
> On 11/23/22 12:25, Maxime Ripard wrote:
> > The name doesn't really fit the conventions for the other helpers in
> > DRM/KMS, so let's rename it to make it obvious that we allocate a new
> > DRM device.
> >
> > Signed-off-by:
On Thu, Nov 24, 2022 at 09:02:19AM +0800, Gaosheng Cui wrote:
> The dma_free_coherent() should be called when memory fails to
> be allocated for list, or drm_map_handle() fails, otherwise there
> will be a memory leak, so add dma_free_coherent to fix it.
>
> In addition, if drm_map_handle() fails
On 11/23/22 12:25, Maxime Ripard wrote:
The name doesn't really fit the conventions for the other helpers in
DRM/KMS, so let's rename it to make it obvious that we allocate a new
DRM device.
Signed-off-by: Maxime Ripard
Although I believe using "drm_device" on the function name is a bit
On Fri, Nov 25, 2022, at 14:40, Lee Jones wrote:
> On Fri, 25 Nov 2022, Lee Jones wrote:
>
>> When enabled, KASAN enlarges function's stack-frames. Pushing quite a
>> few over the current threshold. This can mainly be seen on 32-bit
>> architectures where the present limit (when !GCC) is a lowly
On Thu, Nov 10, 2022 at 04:56:51PM -0800, Daniele Ceraolo Spurio wrote:
> The fence is always initialized in huc_init_early, but the cleanup in
> huc_fini is only being run if HuC is enabled. This causes a leaking of
> the debug object when HuC is disabled/not supported, which can in turn
>
On Fri, 25 Nov 2022, Lee Jones wrote:
> When enabled, KASAN enlarges function's stack-frames. Pushing quite a
> few over the current threshold. This can mainly be seen on 32-bit
> architectures where the present limit (when !GCC) is a lowly
> 1024-Bytes.
>
> Signed-off-by: Lee Jones
> ---
>
Am 25.11.22 um 12:14 schrieb Tvrtko Ursulin:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file
Hello Greg,
On Fri, 25 Nov 2022 at 17:25, Mauro Carvalho Chehab wrote:
>
> Em Wed, 23 Nov 2022 13:25:20 +0100
> Greg Kroah-Hartman escreveu:
>
> > The devnode() in struct class should not be modifying the device that is
> > passed into it, so mark it as a const * and propagate the function
> >
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
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 --
1
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.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 --
1 file changed, 4 insertions(+),
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.
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1
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.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 ++-
1 file changed, 2 insertions(+),
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
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 ++-
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
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 | 152 --
1 file changed, 142 insertions(+), 10 deletions(-)
diff --git
Add silicon specific compatible qcom,sdm630-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm630 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
1 file changed, 2 insertions(+), 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
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 ++-
1
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
---
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
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
power-domain is required for the sc7180 dispcc GDSC but not every qcom SoC
has a similar dependency for example the aqp8064.
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,
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.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 --
1 file changed, 4
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
---
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
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 3 ++-
We will add in a number of compat strings to dsi-controller-main.yaml in
the format "qcom,socname-dsi-ctrl" convert the currently unused
qcom,dsi-ctrl-6g-qcm2290 to qcom,qcm2290-dsi-ctrl.
Signed-off-by: Bryan O'Donoghue
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 +-
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
V4:
- Moves the update of the example from patch #5 to patch #4
V3:
- Moves declaration of mdss-dsi-ctrl into compat string declaration
patch - Krzysztof, Dmitry
- Renames qcm-2290 compat string to agreed compat "qcom,socname-dsi-ctrl"
Dmirty, Krzysztof
- Adds empty line after if clause in
On Wed, 05 Oct 2022, Jani Nikula wrote:
> Currently i915 assumes all drm_connectors it encounters are embedded in
> intel_connectors that i915 allocated. The drm_writeback_connector forces
> a design where this is not the case; we can't provide our own connector,
> and writeback embeds the
On Fri, Nov 25, 2022 at 05:44:11PM +0800, Jiaxin Yu wrote:
> + /*
> + * PCM trigger callback.
> + * Mandatory
> + */
> + int (*trigger)(struct device *dev, int cmd);
> +
Making this mandatory would break all existing users, though...
> + switch (event) {
> + case
On Fri, Nov 25, 2022, at 13:07, Lee Jones wrote:
> calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64)
> architectures built with Clang (all released versions), whereby the stack
> frame gets blown up to well over 5k. This would cause an immediate kernel
> panic on most
When enabled, KASAN enlarges function's stack-frames. Pushing quite a
few over the current threshold. This can mainly be seen on 32-bit
architectures where the present limit (when !GCC) is a lowly
1024-Bytes.
Signed-off-by: Lee Jones
---
lib/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64)
architectures built with Clang (all released versions), whereby the stack
frame gets blown up to well over 5k. This would cause an immediate kernel
panic on most architectures. We'll revert this when the following bug
Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST") WERROR
now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
builds. This leads to some interesting failures, each resolved in this set.
Em Wed, 23 Nov 2022 13:25:20 +0100
Greg Kroah-Hartman escreveu:
> The devnode() in struct class should not be modifying the device that is
> passed into it, so mark it as a const * and propagate the function
> signature changes out into all relevant subsystems that use this
> callback.
On 11/23/22 16:26, Maxime Ripard wrote:
> We'll need to initialize the HVS structure without a backing device to
> create a mock we'll use for testing.
>
> Split the structure initialization part into a separate function.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez
On 11/23/22 16:26, Maxime Ripard wrote:
> It's fairly hard to figure out the instance of the CRTC affected by an
> atomic change using the default name.
>
> Since we can provide our own to the CRTC initialization functions, let's
> do so to make the debugging sessions easier.
>
> Signed-off-by:
On 11/23/22 16:26, Maxime Ripard wrote:
> We'll need a function that looks up an encoder by its vc4_encoder_type.
> Such a function is already present in the CRTC code, so let's make it
> public so that we can reuse it in the unit tests.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by:
On 11/23/22 16:26, Maxime Ripard wrote:
> The current vc4_crtc_init() helper assumes that we will be using
> hardware planes and calls vc4_plane_init().
>
> While it's a reasonable assumption, we'll want to mock the plane and
> thus provide our own. Let's create a helper that will take the plane
The IPUv3 and DCSS driver are two totally separate DRM drivers. Having
one of them live in the drivers/gpu/drm/imx toplevel directory and the
other one in the dcss/ subdirectory is confusing. Move the IPUv3 driver
into its own subdirectory to make the separation more clear.
Signed-off-by: Lucas
On 11/25/2022 1:21 AM, Dmitry Baryshkov wrote:
On 25/11/2022 07:45, Abhinav Kumar wrote:
On 11/24/2022 4:02 PM, Dmitry Baryshkov wrote:
Since the commit commit c6122688f265 ("drm/msm/mdp5: stop overriding
drvdata") reading the MDP5 hw revision on db410c will crash the board
as the MDSS_GDSC
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas downstream kernel driver
6.4.4.3.310723AAA.
Signed-off-by: Tomeu Vizoso
---
Hi,
This series adds support for the Verisilicon VIPNano-QI NPU in the A311D
as in the VIM3 board.
The IP is very closeley based on previous Vivante GPUs, so the etnaviv
driver works basically unchanged.
Regards,
Tomeu
Tomeu Vizoso (6):
dt-bindings: reset: meson-g12a: Add missing NNA reset
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
On 11/23/22 16:25, Maxime Ripard wrote:
> Both users of vc4_crtc_init need the same extra initialization to set
> the pointer to the platform_device and the CRTC data. Since it's
> mandatory, let's make them both arguments of vc4_crtc_init().
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by:
On 11/23/22 16:25, Maxime Ripard wrote:
> It makes more sense to register the CRTC before the encoder and
> connectors, so let's move our call around.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red
On 11/23/22 16:25, Maxime Ripard wrote:
> The TXP is integrated as a separate CRTC/Encoder/Connector combo, but
> for some reason doesn't rely on the vc4_encoder type and it's associated
> type.
>
> Let's create a type to make it consistent with the other encoders.
>
> Signed-off-by: Maxime
On 11/23/22 16:25, Maxime Ripard wrote:
> The current order of variable assignments is unneccessarily complex,
> let's make it simpler.
>
> Signed-off-by: Maxime Ripard
> ---
Much easier to follow indeed.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core
On 11/23/22 16:25, Maxime Ripard wrote:
> The vc4_hvs_get_(old|new)_global_state functions don't modify the
> drm_atomic_state passed as an argument, so let's make it const.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez
On 11/23/22 16:25, Maxime Ripard wrote:
> In order to introduce unit tests for the HVS state computation, we'll
> need access to the vc4_hvs_state struct definition and its associated
> helpers.
>
> Let's move them in our driver header.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by:
On 11/23/22 16:25, Maxime Ripard wrote:
> None of our wrappers around container_of to access our objects from the
> DRM object pointer actually modify the latter.
>
> Let's make them const.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier
On 11/23/22 16:25, Maxime Ripard wrote:
> On the vc4 devices (and later), the blending is done by a single device
> called the HVS. The HVS has three FIFO that can operate in parallel, and
> route their output to 6 CRTCs and 7 encoders on the BCM2711.
>
> Each of these CRTCs and encoders have
On 11/23/22 16:25, Maxime Ripard wrote:
> The drm_atomic_get_(old|new)_*_state don't modify the passed
> drm_atomic_state, so we can make it const.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 11/23/22 16:25, Maxime Ripard wrote:
> DRM-managed actions are supposed to be ran whenever the device is
> released. Let's introduce a basic unit test to make sure it happens.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/tests/Makefile | 1 +
>
On 11/23/22 16:25, Maxime Ripard wrote:
> Some tests will need to provide their own drm_driver instead of relying
> on the dumb one in the helpers, so let's create a helper that allows to
> do so.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
On 11/23/22 16:25, Maxime Ripard wrote:
> The current helper to allocate a DRM device doesn't allow for any
> subclassing by drivers, which is going to be troublesome as we work on
> getting some kunit testing on atomic modesetting code.
>
> Let's use a similar pattern to the other allocation
Since the dma_alloc_coherent() may return NULL,
the pointer returned needs to be checked to avoid
null-poineter dereference.
Fixes: 46f226c93d35 ("drm/tegra: Add NVDEC driver")
Signed-off-by: Zeng Heng
---
drivers/gpu/drm/tegra/nvdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Not used anymore by other drivers or TTM itself.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 44 +++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 19 -
drivers/gpu/drm/vmwgfx/ttm_object.h | 11
include/drm/ttm/ttm_bo.h
Make sure that we use the correct settings from the context.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f9d9fd2d865d..cd266a067773
1 - 100 of 123 matches
Mail list logo
