On 3/4/2025 7:09 PM, Dmitry Baryshkov wrote:
On Wed, 5 Mar 2025 at 00:43, Abhinav Kumar wrote:
On 3/4/2025 12:42 PM, Dmitry Baryshkov wrote:
On Tue, Mar 04, 2025 at 11:38:24AM -0800, Abhinav Kumar wrote:
On 3/3/2025 9:32 PM, Dmitry Baryshkov wrote:
On Tue, 4 Mar 2025 at 03:44, Jessic
On Wed, 5 Mar 2025 at 00:43, Abhinav Kumar wrote:
>
>
>
> On 3/4/2025 12:42 PM, Dmitry Baryshkov wrote:
> > On Tue, Mar 04, 2025 at 11:38:24AM -0800, Abhinav Kumar wrote:
> >>
> >>
> >> On 3/3/2025 9:32 PM, Dmitry Baryshkov wrote:
> >>> On Tue, 4 Mar 2025 at 03:44, Jessica Zhang
> >>> wrote:
> >
On 3/3/2025 7:14 AM, Jun Nie wrote:
Currently, only 2 pipes are used at most for a plane. A stage structure
describes the configuration for a mixer pair. So only one stage is needed
for current usage cases. The quad-pipe case will be added in future and 2
stages are used in the case. So extend
On 3/4/2025 12:42 PM, Dmitry Baryshkov wrote:
On Tue, Mar 04, 2025 at 11:38:24AM -0800, Abhinav Kumar wrote:
On 3/3/2025 9:32 PM, Dmitry Baryshkov wrote:
On Tue, 4 Mar 2025 at 03:44, Jessica Zhang wrote:
On 3/3/2025 3:49 PM, Dmitry Baryshkov wrote:
On Mon, Mar 03, 2025 at 10:28:00AM
On 3/3/2025 7:14 AM, Jun Nie wrote:
The stage contains configuration for a mixer pair. Currently the plane
supports just one stage and 2 pipes. Quad-pipe support will require
handling 2 stages and 4 pipes at the same time. In preparation for that
add a separate define, PIPES_PER_PLANE, to deno
In some cases drm/msm has to resume a stalled transaction directly in
its fault handler. Experimentally this doesn't work on SMMU500 if the
fault hasn't already been acknowledged by clearing FSR. Rather than
trying to clear FSR in msm's fault handler and implementing a
tricky handshake to avoid acc
On Tue, Mar 04, 2025 at 01:43:09AM +0200, Dmitry Baryshkov wrote:
> On Mon, Mar 03, 2025 at 10:45:19AM -0800, Jessica Zhang wrote:
> >
> >
> > On 2/27/2025 7:07 AM, Dmitry Baryshkov wrote:
> > > On Fri, Feb 14, 2025 at 04:14:26PM -0800, Jessica Zhang wrote:
> > > > From: Dmitry Baryshkov
> > > >
On Tue, Mar 04, 2025 at 11:38:24AM -0800, Abhinav Kumar wrote:
>
>
> On 3/3/2025 9:32 PM, Dmitry Baryshkov wrote:
> > On Tue, 4 Mar 2025 at 03:44, Jessica Zhang
> > wrote:
> > >
> > >
> > >
> > > On 3/3/2025 3:49 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Mar 03, 2025 at 10:28:00AM -0800, J
On 3/3/2025 9:32 PM, Dmitry Baryshkov wrote:
On Tue, 4 Mar 2025 at 03:44, Jessica Zhang wrote:
On 3/3/2025 3:49 PM, Dmitry Baryshkov wrote:
On Mon, Mar 03, 2025 at 10:28:00AM -0800, Jessica Zhang wrote:
If new CTLs are reserved by CRTC but atomic_enable() is skipped, the
encoders will c
Up until now we have only called the set_stall callback during
initialization when the device is off. But we will soon start calling it
to temporarily disable stall-on-fault when the device is on, so handle
that by checking if the device is on and writing SCTLR.
Signed-off-by: Connor Abbott
---
drm/msm uses the stall-on-fault model to record the GPU state on the
first GPU page fault to help debugging. On systems where the GPU is
paired with a MMU-500, there were two problems:
1. The MMU-500 doesn't de-assert its interrupt line until the fault is
resumed, which led to a storm of interr
This will be used by drm/msm for GPU page faults, replacing the manual
register reading it does.
Signed-off-by: Connor Abbott
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 4 ++--
drivers/iommu/arm/arm-smmu/arm-smmu.c| 27 +---
drivers/iommu/arm/arm-smmu
On some SMMUv2 implementations, including MMU-500, SMMU_CBn_FSR.SS
asserts an interrupt. The only way to clear that bit is to resume the
transaction by writing SMMU_CBn_RESUME, but typically resuming the
transaction requires complex operations (copying in pages, etc.) that
can't be done in IRQ cont
When things go wrong, the GPU is capable of quickly generating millions
of faulting translation requests per second. When that happens, in the
stall-on-fault model each access will stall until it wins the race to
signal the fault and then the RESUME register is written. This slows
processing page f
On 3/4/2025 3:18 PM, Dmitry Baryshkov wrote:
> On Tue, 4 Mar 2025 at 10:45, Ayushi Makhija wrote:
>>
>> On 2/25/2025 11:25 PM, Dmitry Baryshkov wrote:
>>> On Tue, Feb 25, 2025 at 05:48:21PM +0530, Ayushi Makhija wrote:
Enable both DSI to DP bridge ports on SA8775P Ride plaftrom.
Sig
On 2/26/2025 2:05 PM, Krzysztof Kozlowski wrote:
> On Tue, Feb 25, 2025 at 02:31:05PM +0100, Krzysztof Kozlowski wrote:
>> On 25/02/2025 13:18, Ayushi Makhija wrote:
>>> + pinctrl-0 = <&dsi0_int_pin>,
>>> + <&dsi0_cbl_det_pin>,
>>> + <&d
On Tue, 4 Mar 2025 at 10:45, Ayushi Makhija wrote:
>
> On 2/25/2025 11:25 PM, Dmitry Baryshkov wrote:
> > On Tue, Feb 25, 2025 at 05:48:21PM +0530, Ayushi Makhija wrote:
> >> Enable both DSI to DP bridge ports on SA8775P Ride plaftrom.
> >>
> >> Signed-off-by: Ayushi Makhija
> >> ---
> >> arch/a
On 2/25/2025 11:25 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 25, 2025 at 05:48:21PM +0530, Ayushi Makhija wrote:
>> Enable both DSI to DP bridge ports on SA8775P Ride plaftrom.
>>
>> Signed-off-by: Ayushi Makhija
>> ---
>> arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 66 +-
>>
On 2/25/2025 10:48 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 25, 2025 at 05:48:18PM +0530, Ayushi Makhija wrote:
>> Add DSI Controller v2.5.1 support for SA8775P SoC.
>>
>> Signed-off-by: Ayushi Makhija
>> ---
>> drivers/gpu/drm/msm/dsi/dsi_cfg.c | 18 ++
>> drivers/gpu/drm/msm/ds
19 matches
Mail list logo
