Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:10 CET schrieb Liu Ying:
> The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> simultaneously. Check bus format and flags across first bridges in
> ->atomic_check() to ensure they are consistent. This is a
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:12 CET schrieb Liu Ying:
> With all previous preparations done to make it possible for the
> single LCDIF embedded in i.MX93 SoC to drive multiple displays
> simultaneously, add i.MX93 LCDIF compatible string as the last
> step of
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:11 CET schrieb Liu Ying:
> The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> simultaneously. Look at LCDIF output port's remote port parents to
> find all enabled first bridges. Add an encoder for each found
On Wed, 2023-02-15 at 08:26 +0100, Alexander Stein wrote:
> Hi Liu,
Hi Alexander,
>
> thanks for the update.
Thanks for the review.
>
> Am Montag, 13. Februar 2023, 09:56:07 CET schrieb Liu Ying:
> > There is one LCDIF embedded in i.MX93 SoC to connect with
> > MIPI DSI controller through
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:07 CET schrieb Liu Ying:
> There is one LCDIF embedded in i.MX93 SoC to connect with
> MIPI DSI controller through LCDIF cross line pattern(controlled
> by mediamix blk-ctrl) or connect with LVDS display bridge(LDB)
> directly or
On Tue, Feb 14, 2023 at 08:25:08PM -0800, Ira Weiny wrote:
> Date: Tue, 14 Feb 2023 20:25:08 -0800
> From: Ira Weiny
> Subject: Re: [PATCH 0/9] drm/i915: Replace kmap_atomic() with
> kmap_local_page()
>
> Zhao Liu wrote:
> > From: Zhao Liu
> >
> > The use of kmap_atomic() is being deprecated
On 14/02/2023 02:37, Laurent Pinchart wrote:
On R-Car D3 and E3, the LVDS encoder provides the dot (pixel) clock to
the DU, regardless of whether the LVDS output is used or not. When using
the DPAD (RGB) output, the DU driver thus enables and disables the LVDS
PLL manually, while when using the
On 14/02/2023 02:37, Laurent Pinchart wrote:
To prepare for a rework of the LVDS disable code, which will need to be
called from rcar_lvds_pclk_disable(), move the LVDS enable code,
currently stored in the __rcar_lvds_atomic_enable() function, to a
separate code section separate from bridge
On 14/02/2023 02:37, Laurent Pinchart wrote:
When disabling the companion bridge in rcar_lvds_atomic_disable(),
there's no need to go through the bridge's operations to call
.atomic_disable(). Call rcar_lvds_atomic_disable() on the companion
directly.
Signed-off-by: Laurent Pinchart
---
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
Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT)
into a list of other symbols that do have a dependency (on DRM_I915)
breaks the driver menu presentation in 'make *config'.
Relocate the DRM_I915_GVT symbol so that it does not cause this
problem.
Fixes: 8b750bf74418
Zhao Liu wrote:
> From: Zhao Liu
>
> The use of kmap_atomic() is being deprecated in favor of
> kmap_local_page()[1].
Zhao,
Was there ever a v2 of this series? I'm not finding it on Lore.
Thanks,
Ira
>
> In the following patches, we can convert the calls of kmap_atomic() /
>
Applied. Thanks!
Alex
On Fri, Feb 10, 2023 at 2:37 PM Harry Wentland wrote:
>
> On 2/10/23 05:00, Deepak R Varma wrote:
> > Remove duplicate or repeating expressions in the if condition
> > evaluation. Issue identified using doubletest.cocci Coccinelle semantic
> > patch.
> >
> >
Applied. Thanks!
On Fri, Feb 10, 2023 at 10:22 AM Harry Wentland wrote:
>
> On 2/10/23 05:11, Deepak R Varma wrote:
> > Remove duplicate or repeating expressions in the if condition
> > evaluation. Issue identified using doubletest.cocci Coccinelle semantic
> > patch.
> >
> > Signed-off-by:
On Tue, 2023-02-14 at 15:12 +0100, Alexander Stein wrote:
> Hi Liu,
Hi Alexander,
>
> thanks for the update.
Thanks for your review.
>
> Am Montag, 13. Februar 2023, 09:56:09 CET schrieb Liu Ying:
> > Instead of determining LCDIF output bus format and bus flags in
> > ->atomic_enable(), do
On Mon, 13 Feb 2023 22:16:44 -0800, Guenter Roeck wrote:
>
Hi Guenter,
> On 2/13/23 21:33, Ashutosh Dixit wrote:
> > On ATSM the PL1 power limit is disabled at power up. The previous uapi
> > assumed that the PL1 limit is always enabled and therefore did not have a
> > notion of a disabled PL1
On 2/14/2023 3:48 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations. There are too many caching pitfalls due to the
way stolen memory accesses are routed. So it is safest to just not use
On Tue, Feb 14, 2023 at 4:38 PM Konrad Dybcio wrote:
>
>
>
> On 15.02.2023 01:10, Dmitry Baryshkov wrote:
> > On 14/02/2023 23:56, Rob Clark wrote:
> >> On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio
> >> wrote:
> >>>
> >>> One of the protected ranges was too small (compared to the data we
> >>>
Instead of relying on an accidental, transitive inclusion of linux/leds.h
use it directly.
Also drop the forware definition of struct led_classdev that is now
provided by linux/leds.h.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/nouveau/nouveau_led.h | 2 +-
1 file changed, 1
On 15.02.2023 01:10, Dmitry Baryshkov wrote:
> On 14/02/2023 23:56, Rob Clark wrote:
>> On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio
>> wrote:
>>>
>>> One of the protected ranges was too small (compared to the data we
>>> have downstream). Fix it.
>>>
>>> Fixes: 408434036958 ("drm/msm/a6xx:
On 14/02/2023 23:56, Rob Clark wrote:
On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio wrote:
One of the protected ranges was too small (compared to the data we
have downstream). Fix it.
Fixes: 408434036958 ("drm/msm/a6xx: update/fix CP_PROTECT initialization")
Signed-off-by: Konrad Dybcio
---
On 15/02/2023 01:25, Abhinav Kumar wrote:
Hi Dmitry
Sorry for the late response on this one.
On 2/3/2023 2:55 PM, Dmitry Baryshkov wrote:
On 04/02/2023 00:44, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the
On Sat, 11 Feb 2023 13:26:48 +0100, Konrad Dybcio wrote:
> Add the DSI host found on SM6375.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring
On Sat, 11 Feb 2023 13:26:47 +0100, Konrad Dybcio wrote:
> Add the DSI host found on SM6350.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations. There are too many caching pitfalls due to the
way stolen memory accesses are routed. So it is safest to just not use
it.
Signed-off-by: John Harrison
---
Hi Dmitry
Sorry for the late response on this one.
On 2/3/2023 2:55 PM, Dmitry Baryshkov wrote:
On 04/02/2023 00:44, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to
+ Akhil
On Tue, Feb 14, 2023 at 10:03 AM Konrad Dybcio wrote:
>
>
> v1 -> v2:
> - Fix A630 values in [2/14]
> - Fix [6/14] for GMU-equipped GPUs
>
> Link to v1:
> https://lore.kernel.org/linux-arm-msm/20230126151618.225127-1-konrad.dyb...@linaro.org/
>
> This series concludes my
On Tue, Feb 14, 2023 at 9:32 AM Konrad Dybcio wrote:
>
> One of the protected ranges was too small (compared to the data we
> have downstream). Fix it.
>
> Fixes: 408434036958 ("drm/msm/a6xx: update/fix CP_PROTECT initialization")
> Signed-off-by: Konrad Dybcio
> ---
>
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the timeouts for new GSC-CS + firmware specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
2 files changed, 2 insertions(+), 1
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
Despite KCR subsystem being in the media-tile (close to the
GSC-CS), the IRQ controls for it are on GT-0 with other global
IRQ controls. Thus, add a helper for KCR hw interrupt
enable/disable functions to get the correct gt structure (for
uncore) for MTL.
In the helper, we get GT-0's handle for
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
Also add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.
Before checking the return status, look at the GSC-CS-Mem-Header's
pending-bit
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for
This series enables PXP on MTL. On ADL/TGL platforms, we rely on
the mei driver via the i915-mei PXP component interface to establish
a connection to the security firmware via the HECI device interface.
That interface is used to create and teardown the PXP ARB session.
PXP ARB session is created
On Tue, Feb 14, 2023 at 10:26:24PM +0100, Martin Blumenstingl wrote:
> On Mon, Feb 13, 2023 at 12:11 PM Ville Syrjälä
> wrote:
> [...]
> > > One could use HDMI_VENDOR_INFOFRAME_SIZE with this as well:
> > > u8 buffer[HDMI_INFOFRAME_SIZE(VENDOR)];
> > > But it would only result in an 8 byte wide
On Tue, Feb 14, 2023 at 10:18:49PM +0100, Sebastian Wick wrote:
> On Tue, Feb 14, 2023 at 9:10 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote:
> > > On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland
> > > wrote:
> > > >
> > > >
> > > >
> > > > On
On Mon, Feb 13, 2023 at 12:11 PM Ville Syrjälä
wrote:
[...]
> > One could use HDMI_VENDOR_INFOFRAME_SIZE with this as well:
> > u8 buffer[HDMI_INFOFRAME_SIZE(VENDOR)];
> > But it would only result in an 8 byte wide buffer.
> > Nobody uses it like this yet.
>
> Not sure that would make any sense
On Tue, Feb 14, 2023 at 9:10 PM Ville Syrjälä
wrote:
>
> On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote:
> > On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland
> > wrote:
> > >
> > >
> > >
> > > On 2/14/23 10:49, Sebastian Wick wrote:
> > > > On Fri, Feb 3, 2023 at 5:00 PM Ville
Since, hot plugging eDP displays isn't supported, it is sufficient for
us to warn about the lack of a connected display once. So, use ASSERT()
in dce110_edp_wait_for_hpd_ready() instead of DC_LOG_WARNING().
Signed-off-by: Hamza Mahfooz
---
Hi,
You seem to have sent this twice, perhaps to adjust the To/CC list. I
think I've picked the right one to reply to, but it's usually nice to
use a "v2" notation or otherwise put a comment somewhere in the email.
On Wed, Feb 08, 2023 at 12:44:06PM +0800, Kencp huang wrote:
> From: zain wang
>
On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote:
> On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote:
> >
> >
> >
> > On 2/14/23 10:49, Sebastian Wick wrote:
> > > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä
> > > wrote:
> > >>
> > >> On Fri, Feb 03, 2023 at 10:24:52AM -0500,
On 2/14/23 14:45, Sebastian Wick wrote:
On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote:
On 2/14/23 10:49, Sebastian Wick wrote:
On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä
wrote:
On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
On 2/3/23 10:19, Ville Syrjälä
On Tue, Feb 14, 2023 at 02:27:19PM -0500, Harry Wentland wrote:
>
>
> On 2/14/23 05:28, Ville Syrjälä wrote:
> > On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote:
> >> On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote:
> >>> On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas
On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland wrote:
>
>
>
> On 2/14/23 10:49, Sebastian Wick wrote:
> > On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä
> > wrote:
> >>
> >> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
> >>>
> >>>
> >>> On 2/3/23 10:19, Ville Syrjälä wrote:
>
On 2/14/23 05:28, Ville Syrjälä wrote:
On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote:
On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote:
On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote:
On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote:
On Tue, Feb 14, 2023 at 11:14 AM Rob Clark wrote:
>
> On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
> wrote:
> >
> > From: Tvrtko Ursulin
> >
> > In i915 we have this concept of "wait boosting" where we give a priority
> > boost
> > for instance to fences which are actively waited upon from
On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> In i915 we have this concept of "wait boosting" where we give a priority boost
> for instance to fences which are actively waited upon from userspace. This has
> it's pros and cons and can certainly be discussed
On Thu, 2023-02-09 at 16:42 -0800, Teres Alexis, Alan Previn wrote:
> Add MTL's function for ARB session creation using PXP firmware
> version 4.3 ABI structure format.
>
> Also add MTL's function for ARB session invalidation but this
> reuses PXP firmware version 4.2 ABI structure format.
>
>
v1 -> v2:
- Fix A630 values in [2/14]
- Fix [6/14] for GMU-equipped GPUs
Link to v1:
https://lore.kernel.org/linux-arm-msm/20230126151618.225127-1-konrad.dyb...@linaro.org/
This series concludes my couple-weeks-long suffering of figuring out
the ins and outs of the "non-standard" A6xx GPUs
On 2/14/2023 5:06 AM, Marijn Suijten wrote:
On 2023-02-13 19:09:32, Abhinav Kumar wrote:
On 2/13/2023 1:46 PM, Dmitry Baryshkov wrote:
On 13/02/2023 21:37, Jessica Zhang wrote:
On 12/31/2022 1:50 PM, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 (and seemingly up until and including
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Make variables declaration inside ifdef guard, as they are only used
> inside the same ifdef guard. This remove some of the
> -Wunused-but-set-variable warning.
>
> Signed-off-by: Arthur Grillo
> ---
>
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Remove arguments present on kernel-doc that are not present on the
> function declaration and add the new ones if present.
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c| 15
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Add includes that were previously missing to reduce the number of
> -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/amd/display/dc/dcn32/dcn32_init.c | 1 +
>
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Add function prototypes to headers to reduce the number of
> -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 1 +
> 1 file changed, 1 insertion(+)
>
>
Applied. Thanks!
On Mon, Feb 13, 2023 at 3:50 PM Arthur Grillo wrote:
>
> Add function prototypes to headers to reduce the number of
> -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hubbub.h | 2 ++
>
On Mon, Feb 13, 2023 at 3:49 PM Arthur Grillo wrote:
>
> Turn global functions that are only used locally into static ones. This
> reduces the number of -Wmissing-prototypes warnings.
>
> Signed-off-by: Arthur Grillo
The first hunk was already fixed, but I applied the second hunk.
Alex
> ---
On Mon, Feb 13, 2023 at 6:10 PM Dmitry Baryshkov
wrote:
>
> The rptr_addr is set in the preempt_init_ring(), which is called from
> a5xx_gpu_init(). It uses shadowptr() to set the address, however the
> shadow_iova is not yet initialized at that time. Move the rptr_addr
> setting to the
A610 is implemented on at least three SoCs: SM6115 (bengal), SM6125
(trinket) and SM6225 (khaje). Trinket does not support speed binning
(only a single SKU exists) and we don't yet support khaje upstream.
Hence, add a fuse mapping table for bengal to allow for per-chip
frequency limiting.
A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375
(blair). This is what seems to be a first occurrence of this happening,
but it's easy to overcome by guarding the SoC-specific fuse values with
of_machine_is_compatible(). Do just that to enable frequency limiting
on these
The GPU can only be one at a time. Turn a series of ifs into if +
elseifs to save some CPU cycles.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
On GMU-equipped GPUs, the GMU requests appropriate bandwidth votes
for us. This is however not the case for the other GPUs. Add the
dev_pm_opp_of_find_icc_paths() call to let the OPP framework handle
bus voting as part of power level setting.
Signed-off-by: Konrad Dybcio
---
One of the protected ranges was too small (compared to the data we
have downstream). Fix it.
Fixes: 408434036958 ("drm/msm/a6xx: update/fix CP_PROTECT initialization")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Adreno 619 expects some tunables to be set differently. Make up for it.
Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
A610 is one of (if not the) lowest-tier SKUs in the A6XX family. It
features no GMU, as it's implemented solely on SoCs with SMD_RPM.
What's more interesting is that it does not feature a VDDGX line
either, being powered solely by VDDCX and has an unfortunate hardware
quirk that makes its reset
A619_holi is a GMU-less variant of the already-supported A619 GPU.
It's present on at least SM4350 (holi) and SM6375 (blair). No mesa
changes are required. Add the required kernel-side support for it.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 37
Currently we only utilize the OPP table connected to the GPU for
getting (available) frequencies. We do however need to scale the
voltage rail(s) accordingly to ensure that we aren't trying to
run the GPU at 1GHz with a VDD_LOW vote, as that would result in
an otherwise inexplainable hang.
Tell
These SKUs don't support the feature. Disable it to make the GPU stop
crashing after almost each and every submission - the received data on
the GPU end was simply incomplete in garbled, resulting in almost nothing
being executed properly.
Signed-off-by: Konrad Dybcio
---
These two will be reused by at least A619_holi in the non-gmu
paths. De-staticize them to make it possible.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
but don't implement the associated GMUs. This is due to the fact that
the GMU directly pokes at RPMh. Sadly, this means we have to take care
of enabling & scaling power rails, clocks and bandwidth ourselves.
Reuse existing
Currently we're only deasserting REG_A6XX_RBBM_GBIF_HALT, but we also
need REG_A6XX_GBIF_HALT to be set to 0. For GMU-equipped GPUs this is
done in a6xx_bus_clear_pending_transactions(), but for the GMU-less
ones we have to do it *somewhere*. Unhalting both side by side sounds
like a good plan and
Port setting min_access_length, ubwc_mode and upper_bit from downstream.
Values were validated using downstream device trees for SM8[123]50 and
left default (as per downstream) elsewhere.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 29 +++
1
Hi,
On 2/14/23 17:46, Darrell Kavanagh wrote:
> Another Lenovo convertable where the panel is installed landscape but is
> reported to the kernel as portrait.
>
> Signed-off-by: Darrell Kavanagh
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Note for other developers the reason
On 2/14/23 10:49, Sebastian Wick wrote:
> On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä
> wrote:
>>
>> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
>>>
>>>
>>> On 2/3/23 10:19, Ville Syrjälä wrote:
On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
>
Another Lenovo convertable where the panel is installed landscape but is
reported to the kernel as portrait.
Signed-off-by: Darrell Kavanagh
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
On Fri, Feb 3, 2023 at 5:00 PM Ville Syrjälä
wrote:
>
> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
> >
> >
> > On 2/3/23 10:19, Ville Syrjälä wrote:
> > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
> > >>
> > >>
> > >> On 2/3/23 07:59, Sebastian Wick
On Mon, Feb 13, 2023 at 04:11:46PM +0900, FUKAUMI Naoki wrote:
> hi,
>
> on my rk3399 boards(ROCK Pi 4B+ and ROCK 4C+), fb0 is configured as
> 1920x1080, and nothing is displayed... "no signal" on display.
I can confirm this.
First of all there is a stupid bug in my patch:
> + if
Hi,
On Mon, Feb 13, 2023 at 6:02 PM Abhinav Kumar wrote:
>
> Hi Doug
>
> Sorry for the delayed response.
>
> On 2/2/2023 2:46 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Feb 2, 2023 at 2:37 PM Abhinav Kumar
> > wrote:
> >>
> >> Hi Doug
> >>
> >> On 1/31/2023 2:18 PM, Douglas Anderson
On Tue, Feb 14, 2023 at 03:12:55PM +0100, Alexander Stein wrote:
> Hi Liu,
>
> thanks for the update.
>
> Am Montag, 13. Februar 2023, 09:56:09 CET schrieb Liu Ying:
> > Instead of determining LCDIF output bus format and bus flags in
> > ->atomic_enable(), do that in ->atomic_check(). This is a
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:09 CET schrieb Liu Ying:
> Instead of determining LCDIF output bus format and bus flags in
> ->atomic_enable(), do that in ->atomic_check(). This is a
> preparation for the upcoming patch to check consistent bus format
> and bus
Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete. This allowing
of working against a partially constructed object, which may also be in
the process of having
Hi Liu,
thanks for the update.
Am Montag, 13. Februar 2023, 09:56:08 CET schrieb Liu Ying:
> A valid bridge is already found in lcdif_attach_bridge() and set
> to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop
> the unnecessary NULL pointer check in KMS stage.
>
> Signed-off-by:
On 2023-02-13 19:09:32, Abhinav Kumar wrote:
>
>
> On 2/13/2023 1:46 PM, Dmitry Baryshkov wrote:
> > On 13/02/2023 21:37, Jessica Zhang wrote:
> >>
> >>
> >> On 12/31/2022 1:50 PM, Marijn Suijten wrote:
> >>> All SoCs since DPU 5.0.0 (and seemingly up until and including 6.0.0,
> >>> but
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete. This allowing
of working against a partially constructed object, which may also be in
the process of having its creation fail, can have a range of
On Tue, Feb 14, 2023 at 01:19:51PM +0100, Stanislaw Gruszka wrote:
> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> > -void drm_debugfs_late_register(struct drm_device *dev)
> > -{
> > - struct drm_minor *minor = dev->primary;
> > - struct drm_debugfs_entry *entry, *tmp;
>
Use adreno_fault_handler() to implement a5xx_fault_handler(). This
enables devcoredump support on a5xx platforms, allowing one to capture
the crashed GPU state at the time of context fault.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 -
1 file
During the debug of the a5xx preempt issue, having the devcoredump
support was a great help. These patches port necessary code bits from
being a6xx-specific to generic code path and then enables devcoredump
for a5xx.
Dmitry Baryshkov (3):
drm/msm/adreno: stall translation on fault for all GPU
Split the a6xx_fault_handler() into the generic adreno_fault_handler()
and platform-specific parts. The adreno_fault_handler() can further be
used by a5xx and hopefully by a4xx (at some point).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 64
The commit e25e92e08e32 ("drm/msm: devcoredump iommu fault support")
enabled SMMU stalling to collect GPU state, but only for a6xx. It tied
enabling the stall with tha per-instance pagetables creation.
Since that commit SoCs with a5xx also gained support for
adreno-smmu-priv. Move stalling into
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> -void drm_debugfs_late_register(struct drm_device *dev)
> -{
> - struct drm_minor *minor = dev->primary;
> - struct drm_debugfs_entry *entry, *tmp;
> -
> - if (!minor)
> - return;
> -
> -
On Thu, Feb 09, 2023 at 09:18:36AM +0100, Christian König wrote:
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index c6eb8972451a..88ce22c04672 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -156,6 +156,10 @@ static int
On 2/3/23 18:37, Matthew Brost wrote:
On Wed, Jan 18, 2023 at 07:12:45AM +0100, Danilo Krummrich wrote:
This adds the infrastructure for a manager implementation to keep track
of GPU virtual address (VA) mappings.
New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
start
On 2/13/23 14:50, Jani Nikula wrote:
> On Mon, 13 Feb 2023, Dmitry Osipenko wrote:
>> On 2/13/23 12:56, Jani Nikula wrote:
>>> On Sun, 12 Feb 2023, Dmitry Osipenko wrote:
Hi,
On 1/18/22 20:00, Yaroslav Bolyukin wrote:
Add a brief commit message, describing a user-visible
On Tue, Feb 14, 2023 at 10:28:24AM +0100, Christian König wrote:
> Am 14.02.23 um 09:59 schrieb Stanislaw Gruszka:
> > On Thu, Feb 09, 2023 at 09:18:35AM +0100, Christian König wrote:
> > > Hello everyone,
> > >
> > > the drm_debugfs has a couple of well known design problems.
> > >
> > >
On 2/13/23 21:49, Arthur Grillo wrote:
> Make implicit enum conversion to avoid -Wenum-conversion warning, such
> as:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:4109:88:
> warning: implicit conversion from ‘enum ’ to ‘enum
> odm_combine_mode’
On Tue, Feb 14, 2023 at 01:17:45PM +0200, Pekka Paalanen wrote:
> On Tue, 14 Feb 2023 12:27:45 +0200
> Ville Syrjälä wrote:
>
> > On Tue, Feb 14, 2023 at 11:42:27AM +0200, Pekka Paalanen wrote:
> > > On Thu, 9 Feb 2023 13:51:05 +0200
> > > Pekka Paalanen wrote:
> > >
> > > > Maybe we could
On 8.02.2023 19:21, Jordan Crouse wrote:
> On Thu, Jan 26, 2023 at 04:16:13PM +0100, Konrad Dybcio wrote:
>> Adreno 619 expects some tunables to be set differently. Make up for it.
>>
>> Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support")
>> Signed-off-by: Konrad Dybcio
>> ---
>>
On Tue, Feb 14, 2023 at 12:01:49PM +0100, Jonas Ådahl wrote:
> On Tue, Feb 14, 2023 at 12:28:44PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote:
> > > On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote:
> > > > On Thu, Feb 09, 2023 at
1 - 100 of 130 matches
Mail list logo
