On 15.01.2025 8:59 PM, Dmitry Baryshkov wrote:
> On Thu, Jan 16, 2025 at 01:07:17AM +0530, Akhil P Oommen wrote:
>> On 1/9/2025 7:27 PM, Konrad Dybcio wrote:
>>> On 8.01.2025 11:42 PM, Akhil P Oommen wrote:
>>>> Adreno X1-85 has an additional bit which is at a n
On 8.01.2025 11:42 PM, Akhil P Oommen wrote:
> Adreno X1-85 has an additional bit which is at a non-contiguous
> location in qfprom. Add support for this new "hi" bit along with
> the speedbin mappings.
> ---
> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 5 +
> drivers/gpu/drm/msm/adreno/adre
On 8.01.2025 9:40 PM, Akhil P Oommen wrote:
> Update GPU node to include acd level values.
>
> Signed-off-by: Akhil P Oommen
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 8.01.2025 9:40 PM, Akhil P Oommen wrote:
> Add a module param to disable ACD which will help to quickly rule it
> out for any GPU issues.
>
> Signed-off-by: Akhil P Oommen
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 7 +++
> drivers/gpu/drm/msm/adreno/adreno_device.c | 4
>
On 30.12.2024 10:11 PM, Akhil P Oommen wrote:
> Now that we have ACD support for GPU, add additional OPPs up to
> Turbo L3 which are supported across all existing SKUs.
>
> Signed-off-by: Akhil P Oommen
> ---
Reviewed-by: Konrad Dybcio
Konrad
ff-by: Akhil P Oommen
> ---
I think this looks right
Reviewed-by: Konrad Dybcio
Konrad
On 30.12.2024 10:11 PM, Akhil P Oommen wrote:
> Add a module param to disable ACD which will help to quickly rule it
> out for any GPU issues.
>
> Signed-off-by: Akhil P Oommen
> ---
Is that something useful during internal development, or do we
see ACD causing issues in the wild?
If the latter
On 30.12.2024 11:25 PM, Rob Herring (Arm) wrote:
>
> On Tue, 31 Dec 2024 02:41:05 +0530, Akhil P Oommen wrote:
>> Add a new schema which extends opp-v2 to support a new vendor specific
>> property required for Adreno GPUs found in Qualcomm's SoCs. The new
>> property called "qcom,opp-acd-level" ca
On 24.12.2024 9:51 AM, Krzysztof Kozlowski wrote:
> On 23/12/2024 22:31, Akhil P Oommen wrote:
>> On 12/23/2024 5:24 PM, Dmitry Baryshkov wrote:
>>> On Mon, Dec 23, 2024 at 12:31:27PM +0100, Konrad Dybcio wrote:
>>>> On 4.12.2024 7:18 PM, Akhil P Oommen wrote:
>&
ds_data[0][j] & BCM_TCS_CMD_COMMIT_MASK)
> + msg->cnoc_wait_bitmask |= BIT(j);
Still very much not a fan of this.
I think this would be equally telling:
/* Always flush on/off commands */
msg->cnoc_wait_bitmask = BIT(0);
with or without that:
Reviewed-by: Konrad Dybcio
Konrad
dth.
> The AB vote will be calculated later when setting the frequency.
>
> The vote array will then be used to dynamically generate the GMU
> bw_table sent during the GMU power-up.
>
> Reviewed-by: Akhil P Oommen
> Signed-off-by: Neil Armstrong
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 17.12.2024 3:51 PM, Neil Armstrong wrote:
> Each GPU OPP requires a specific peak DDR bandwidth, let's add
> those to each OPP and also the related interconnect path.
>
> Signed-off-by: Neil Armstrong
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 17.12.2024 3:51 PM, Neil Armstrong wrote:
> Each GPU OPP requires a specific peak DDR bandwidth, let's add
> those to each OPP and also the related interconnect path.
>
> Reviewed-by: Akhil P Oommen
> Signed-off-by: Neil Armstrong
> ---
Reviewed-by: Konrad Dybcio
Konrad
AB
> vote starting from A750 GPUs.
>
> Since we now vote for all resources via the GMU, setting the OPP
> is no more needed, so we can completely skip calling
> dev_pm_opp_set_opp() in this situation.
>
> Reviewed-by: Dmitry Baryshkov
> Reviewed-by: Akhil P Oommen
> S
On 4.12.2024 7:18 PM, Akhil P Oommen wrote:
> On 11/16/2024 1:17 AM, Dmitry Baryshkov wrote:
>> On Fri, 15 Nov 2024 at 19:54, Akhil P Oommen
>> wrote:
>>>
>>> On 11/15/2024 3:54 AM, Dmitry Baryshkov wrote:
Hello Akhil,
On Thu, 14 Nov 2024 at 20:50, Akhil P Oommen
wrote:
other
> gmu-wrapper implementations to control gpu core clock and gpu GX gdsc.
> Since there is no benefit with enabling RGMU at the moment, RGMU is
> entirely skipped in this patch.
>
> Signed-off-by: Jie Zhang
> Signed-off-by: Akhil P Oommen
> Reviewed-by: Konrad Dybcio
Might come in useful to try and track down otherwise inexplicable
failures in e.g. old CI logs. A630 uses a different mechanism that is
not implemented in this series.
Tested on 8280 and X1
Signed-off-by: Konrad Dybcio
---
Konrad Dybcio (2):
drm/msm: registers: Add GMU FW version register
From: Konrad Dybcio
Log the version for informational purposes, such as for keeping track
of possible GMU fw-related failures in crash / CI logs.
Intentionally not implemented on the if (gmu->legacy) codepath, as
these registers seem not to be used on there.
Downstream additionally warns
From: Konrad Dybcio
Add a register that contains the GMU core firmware version on non-
legacy (non-sdm845-family) SoCs.
The name is guesstimated based on what it does downstream, but it'll
do.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/registers/adreno/a6xx_gmu.xml | 5 +++
On 13.12.2024 5:55 PM, Akhil P Oommen wrote:
> On 12/13/2024 10:10 PM, neil.armstr...@linaro.org wrote:
>> On 13/12/2024 17:31, Konrad Dybcio wrote:
>>> On 13.12.2024 5:28 PM, neil.armstr...@linaro.org wrote:
>>>> On 13/12/2024 16:37, Konrad Dybcio wrote:
>&g
On 13.12.2024 5:28 PM, neil.armstr...@linaro.org wrote:
> On 13/12/2024 16:37, Konrad Dybcio wrote:
>> On 13.12.2024 2:12 PM, Akhil P Oommen wrote:
>>> On 12/13/2024 3:07 AM, Neil Armstrong wrote:
>>>> On 12/12/2024 21:21, Konrad Dybcio wrote:
>>>>>
On 13.12.2024 4:55 PM, Rob Clark wrote:
> On Fri, Dec 13, 2024 at 5:11 AM Konrad Dybcio
> wrote:
>>
>> On 23.11.2024 3:41 AM, Rob Clark wrote:
>>> On Fri, Nov 22, 2024 at 4:19 PM Konrad Dybcio
>>> wrote:
>>>>
>>>> On 22.11.2024 4:5
On 13.12.2024 2:12 PM, Akhil P Oommen wrote:
> On 12/13/2024 3:07 AM, Neil Armstrong wrote:
>> On 12/12/2024 21:21, Konrad Dybcio wrote:
>>> On 11.12.2024 9:29 AM, Neil Armstrong wrote:
>>>> The Adreno GPU Management Unit (GMU) can also scale the DDR Bandwidth
>
On 13.12.2024 4:09 PM, Konrad Dybcio wrote:
> On 13.12.2024 12:31 PM, Akhil P Oommen wrote:
>> From: Jie Zhang
>>
>> Add gpu and gmu nodes for qcs615 chipset.
>>
>> Signed-off-by: Jie Zhang
>> Signed-off-by: Akhil P Oommen
>> Reviewed-by: Dmitry Bary
On 13.12.2024 12:31 PM, Akhil P Oommen wrote:
> From: Jie Zhang
>
> Add gpu and gmu nodes for qcs615 chipset.
>
> Signed-off-by: Jie Zhang
> Signed-off-by: Akhil P Oommen
> Reviewed-by: Dmitry Baryshkov
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 23.11.2024 3:41 AM, Rob Clark wrote:
> On Fri, Nov 22, 2024 at 4:19 PM Konrad Dybcio
> wrote:
>>
>> On 22.11.2024 4:51 PM, Rob Clark wrote:
>>> On Fri, Nov 22, 2024 at 4:21 AM Konrad Dybcio
>>> wrote:
>>>>
>>>> O
On 12.12.2024 10:36 PM, Neil Armstrong wrote:
> On 12/12/2024 21:32, Konrad Dybcio wrote:
>> On 11.12.2024 9:29 AM, Neil Armstrong wrote:
>>> Now all the DDR bandwidth voting via the GPU Management Unit (GMU)
>>> is in place, declare the Bus Control Modules (BCMs
On 13.12.2024 11:35 AM, Akhil P Oommen wrote:
> From: Jie Zhang
>
> Enable GPU for qcs615-ride platform and provide path for zap
> shader.
>
> Signed-off-by: Jie Zhang
> Signed-off-by: Akhil P Oommen
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 13.12.2024 11:35 AM, Akhil P Oommen wrote:
> From: Jie Zhang
>
> Add gpu and gmu nodes for qcs615 chipset.
>
> Signed-off-by: Jie Zhang
> Signed-off-by: Akhil P Oommen
> Reviewed-by: Dmitry Baryshkov
> ---
> arch/arm64/boot/dts/qcom/qcs615.dtsi | 88
>
On 13.12.2024 11:35 AM, Akhil P Oommen wrote:
> RGMU a.k.a Reduced Graphics Management Unit is a small state machine
> with the sole purpose of providing IFPC support. Compared to GMU, it
> doesn't manage GPU clock, voltage scaling, bw voting or any other
> functionalities. All it does is detect an
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
> Now all the DDR bandwidth voting via the GPU Management Unit (GMU)
> is in place, declare the Bus Control Modules (BCMs) and the
> corresponding parameters in the GPU info struct.
>
> Reviewed-by: Dmitry Baryshkov
> Reviewed-by: Akhil P Oommen
> Sig
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale the DDR Bandwidth
> along the Frequency and Power Domain level, until now we left the OPP
> core scale the OPP bandwidth via the interconnect path.
>
> In order to enable bandwidth voting via the GPU
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale the ddr
> bandwidth along the frequency and power domain level, but for
> now we statically fill the bw_table with values from the
> downstream driver.
>
> Only the first entry is used, which is a di
On 11.12.2024 9:29 AM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale DDR Bandwidth along
> the Frequency and Power Domain level, but by default we leave the
> OPP core scale the interconnect ddr path.
>
> While scaling via the interconnect path was sufficient, newer G
On 9.12.2024 9:19 AM, Akhil P Oommen wrote:
> When kernel is booted in EL2, SECVID registers are accessible to the
> KMD. So we can use that to switch GPU's secure mode to avoid dependency
> on Zap firmware. Also, we can't load a secure firmware without a
> hypervisor that supports it.
>
> Tested
On 6.12.2024 5:32 AM, Abhinav Kumar wrote:
> From: Yongxing Mou
>
> Populate the pixel clock for stream 1 for DP0 for sa8775p DP controller.
>
> Signed-off-by: Yongxing Mou
> Signed-off-by: Abhinav Kumar
> ---
> arch/arm64/boot/dts/qcom/sa8775p.dtsi | 12
> 1 file changed, 8 inse
On 26.11.2024 3:06 PM, Akhil P Oommen wrote:
> From: Jie Zhang
>
> Add gpu and gmu nodes for qcs615 chipset.
>
> Signed-off-by: Jie Zhang
> Signed-off-by: Akhil P Oommen
> ---
> arch/arm64/boot/dts/qcom/qcs615.dtsi | 86
>
> 1 file changed, 86 insertions(
On 25.11.2024 5:33 PM, Akhil P Oommen wrote:
> There are a few chipsets which don't have system cache a.k.a LLC.
> Currently, the assumption in the driver is that the system cache
> availability correlates with the presence of GMU or RPMH, which
> is not true. For instance, Snapdragon 6 Gen 1 has R
On 25.11.2024 8:11 PM, Maud Spierings via B4 Relay wrote:
> From: Maud Spierings
>
> The Asus vivobook s15 uses the ATNA56AC03 panel.
> This panel is controlled by the atna33xc20 driver instead of the generic
> edp-panel driver
>
> Signed-off-by: Maud Spierings
>
On 28.11.2024 11:25 AM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale the ddr
> bandwidth along the frequency and power domain level, but for
> now we statically fill the bw_table with values from the
> downstream driver.
>
> Only the first entry is used, which is a d
On 28.11.2024 11:25 AM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale the DDR Bandwidth
> along the Frequency and Power Domain level, until now we left the OPP
> core scale the OPP bandwidth via the interconnect path.
>
> In order to enable bandwidth voting via the GP
On 28.11.2024 11:25 AM, Neil Armstrong wrote:
> Now all the DDR bandwidth voting via the GPU Management Unit (GMU)
> is in place, declare the Bus Control Modules (BCMs) and the
> corresponding parameters in the GPU info struct and add the
> GMU_BW_VOTE feature bit to enable it.
>
> Signed-off-by:
On 28.11.2024 11:25 AM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale DDR Bandwidth along
> the Frequency and Power Domain level, but by default we leave the
> OPP core scale the interconnect ddr path.
>
> While scaling via the interconnect path was sufficient, newer
On 24.11.2024 11:00 AM, Maud Spierings via B4 Relay wrote:
> From: Maud Spierings
>
> Add the lid switch for the Asus vivobook s15
>
> Signed-off-by: Maud Spierings
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 24.11.2024 11:00 AM, Maud Spierings via B4 Relay wrote:
> From: Maud Spierings
>
> The Asus vivobook s15 uses the ATNA56AC03 panel.
> This panel is controlled by the atna33xc20 driver instead of the generic
> edp-panel driver
>
> Signed-off-by: Maud Spierings
> ---
> arch/arm64/boot/dts/qco
On 22.11.2024 4:51 PM, Rob Clark wrote:
> On Fri, Nov 22, 2024 at 4:21 AM Konrad Dybcio
> wrote:
>>
>> On 21.11.2024 5:48 PM, Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> Debugging incorrect UAPI usage tends to be a bit painful, so add a
>>&g
On 21.11.2024 5:48 PM, Rob Clark wrote:
> From: Rob Clark
>
> Debugging incorrect UAPI usage tends to be a bit painful, so add a
> helper macro to make it easier to add debug logging which can be enabled
> at runtime via drm.debug.
>
> Signed-off-by: Rob Clark
> ---
[...]
> +/* Helper for ret
On 12.11.2024 10:15 PM, Akhil P Oommen wrote:
> On 11/11/2024 8:38 PM, Rob Clark wrote:
>> On Sun, Nov 10, 2024 at 9:31 AM Bjorn Andersson
>> wrote:
>>>
>>> Support for per-process page tables requires the SMMU aparture to be
>>> setup such that the GPU can make updates with the SMMU. On some targ
tually occur.
>
> Signed-off-by: Colin Ian King
>
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 13.11.2024 12:51 PM, Fange Zhang wrote:
> From: Li Liu
>
> Add support for DSI 2.3.1 (block used on QCS615).
> Add phy configuration for QCS615
>
> Signed-off-by: Li Liu
> Signed-off-by: Fange Zhang
> ---
> drivers/gpu/drm/msm/dsi/dsi_cfg.c | 17 +
> drivers/gpu/dr
On 11/12/24 14:20, Colin Ian King wrote:
The pointer config is dereferencing pointer pdev before pdev is null
checked, this could lead to a potential null pointer dereference on pdev.
Fix this by only assinging config after pdev has been null checked.
Fixes: 736a93273656 ("drm/msm/a5xx: reall
On 22.10.2024 12:09 AM, Akhil P Oommen wrote:
> On Mon, Oct 21, 2024 at 11:38:41AM +0200, Konrad Dybcio wrote:
>> On 11.10.2024 10:29 PM, Akhil P Oommen wrote:
>>> ACD a.k.a Adaptive Clock Distribution is a feature which helps to reduce
>>> the power consumption. In
available for A612. Verified Glmark2 with
> weston.
>
> Some dependencies for the devicetree change are not yet available
> in the mailing lists. I will send it out as a separate patch later.
> ---
Reviewed-by: Konrad Dybcio
Konrad
[...]
> - retu
at it will always suceess, quit if it fail.
>
> Signed-off-by: Sui Jingfeng
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 30.10.2024 8:02 AM, Akhil P Oommen wrote:
> From: Puranam V G Tejaswi
>
> Enable GPU for sa8775p-ride platform and provide path for zap
> shader.
>
> Signed-off-by: Puranam V G Tejaswi
> Signed-off-by: Akhil P Oommen
> Reviewed-by: Dmitry Baryshkov
> ---
On 30.10.2024 8:02 AM, Akhil P Oommen wrote:
> From: Puranam V G Tejaswi
>
> Add gpu and gmu nodes for sa8775p chipset. As of now all
> SKUs have the same GPU fmax, so there is no requirement of
> speed bin support.
>
> Signed-off-by: Puranam V G Tejaswi
> Signed-off-by: Akhil P Oommen
> Revie
On 28.10.2024 11:52 AM, Dmitry Baryshkov wrote:
> On Mon, Oct 28, 2024 at 11:36:15AM +0100, Konrad Dybcio wrote:
>> On 28.10.2024 11:27 AM, Dmitry Baryshkov wrote:
>>> On Mon, 28 Oct 2024 at 12:08, Akhil P Oommen
>>> wrote:
>>>>
>>>> On 10/28
On 28.10.2024 10:52 AM, Akhil P Oommen wrote:
> On 10/28/2024 12:13 AM, Arnd Bergmann wrote:
>> On Sun, Oct 27, 2024, at 18:05, Akhil P Oommen wrote:
>>> Clang-19 and above sometimes end up with multiple copies of the large
>>> a6xx_hfi_msg_bw_table structure on the stack. The problem is that
>>> a
On 28.10.2024 11:27 AM, Dmitry Baryshkov wrote:
> On Mon, 28 Oct 2024 at 12:08, Akhil P Oommen wrote:
>>
>> On 10/28/2024 1:56 PM, Dmitry Baryshkov wrote:
>>> On Sun, Oct 27, 2024 at 11:35:47PM +0530, Akhil P Oommen wrote:
Clang-19 and above sometimes end up with multiple copies of the large
On 15.10.2024 2:07 PM, Jyothi Kumar Seerapu wrote:
> The current GPI driver hardcodes the channel TRE (Transfer Ring Element)
> size to 64. For scenarios requiring high performance with multiple
> messages in a transfer, use Block Event Interrupt (BEI).
> This method triggers interrupt after specif
On 11.10.2024 10:29 PM, Akhil P Oommen wrote:
> ACD a.k.a Adaptive Clock Distribution is a feature which helps to reduce
> the power consumption. In some chipsets, it is also a requirement to
> support higher GPU frequencies. This patch adds support for GPU ACD by
> sending necessary data to GMU an
On 21.10.2024 11:25 AM, Akhil P Oommen wrote:
> On Sat, Oct 19, 2024 at 04:14:13PM +0300, Dmitry Baryshkov wrote:
>> On Sat, Oct 19, 2024 at 03:01:46PM +0530, Akhil P Oommen wrote:
>>> On Fri, Oct 18, 2024 at 03:11:38PM +, Arnd Bergmann wrote:
From: Arnd Bergmann
Clang-19 and ab
On 18.10.2024 12:08 PM, Dmitry Baryshkov wrote:
> On Fri, Oct 18, 2024 at 12:37:01PM +0530, Soutrik Mukhopadhyay wrote:
>> This series adds support for the DisplayPort controller
>> and eDP PHY v5 found on the Qualcomm SA8775P platform.
>>
>> ---
>> v2: Fixed review comments from Dmitry and Bjorn
>
On 5.10.2024 4:38 PM, Jonathan Marek wrote:
> drm_mode_vrefresh() can introduce a large rounding error, avoid it.
>
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_hos
sson
> ---
Not all A6xx targets support PPPT (e.g. A619 on SM6375 - but A619 on SM6350
does..). We already print some error messages when that's the case, I think
this may add one more.
Nonetheless, I think that sticks to the accepted status quo where lacking
PPPT is a bug, so..
Te
setup by firmware).
>
> This is necessary on e.g. QCS6490 Rb3Gen2, in order to avoid "CP | AHB
> bus error"-errors from the GPU.
>
> Introduce a function to allow the msm driver to invoke this call.
>
> Signed-off-by: Bjorn Andersson
> ---
Tested-by: Konrad Dybcio # FP5
Reviewed-by: Konrad Dybcio
Konrad
On 19.09.2024 5:00 PM, Jeffrey Hugo wrote:
> On 9/18/2024 5:41 PM, Konrad Dybcio wrote:
>> On 18.09.2024 5:52 PM, Jeffrey Hugo wrote:
>>> The Sahara protocol has a crashdump functionality. In the hello
>>> exchange, the device can advertise it has a memory dump av
On 18.09.2024 5:52 PM, Jeffrey Hugo wrote:
> The Sahara protocol has a crashdump functionality. In the hello
> exchange, the device can advertise it has a memory dump available for
> the host to collect. Instead of the device making requests of the host,
> the host requests data from the device whi
On 17.09.2024 5:30 PM, Rob Clark wrote:
> On Tue, Sep 17, 2024 at 6:47 AM Konrad Dybcio wrote:
>>
>> On 13.09.2024 9:51 PM, Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> The CP_SMMU_TABLE_UPDATE _should_ be waiting for idle, but on some
>>> devi
On 13.09.2024 9:51 PM, Rob Clark wrote:
> From: Rob Clark
>
> The CP_SMMU_TABLE_UPDATE _should_ be waiting for idle, but on some
> devices (x1-85, possibly others), it seems to pass that barrier while
> there are still things in the event completion FIFO waiting to be
> written back to memory.
C
On 17.09.2024 10:12 AM, Soutrik Mukhopadhyay wrote:
>
> On 9/14/2024 2:54 AM, Bjorn Andersson wrote:
>> On Thu, Sep 12, 2024 at 03:34:05PM +0530, Soutrik Mukhopadhyay wrote:
>>> On 9/12/2024 1:32 AM, Bjorn Andersson wrote:
On Wed, Sep 11, 2024 at 03:38:13PM +0530, Soutrik Mukhopadhyay wrote:
On 16.09.2024 10:33 PM, Dmitry Baryshkov wrote:
> On Mon, Sep 16, 2024 at 05:23:55PM GMT, Krzysztof Kozlowski wrote:
>> On Fri, Sep 13, 2024 at 04:07:51PM +0530, Soutrik Mukhopadhyay wrote:
>>> Add compatible string for the supported eDP PHY on sa8775p platform.
>>>
>>> Signed-off-by: Soutrik Mukho
On 13.09.2024 12:37 PM, Soutrik Mukhopadhyay wrote:
> In order to support different HW versions, introduce aux_cfg array
> to move v4 specific aux configuration settings.
>
> Signed-off-by: Soutrik Mukhopadhyay
> ---
> v2: Fixed review comments from Bjorn and Dmitry
> - Made aux_cfg array a
On 9.09.2024 1:25 PM, Dmitry Baryshkov wrote:
> On Mon, 9 Sept 2024 at 13:34, Konrad Dybcio wrote:
>>
>> On 8.09.2024 7:59 PM, Dmitry Baryshkov wrote:
>>> Under some circumstance
>>
>> Under what circumstances?
>>
>> This branch is only taken if the
On 8.09.2024 7:59 PM, Dmitry Baryshkov wrote:
> Under some circumstance
Under what circumstances?
This branch is only taken if there's a .create_private_address_space
callback and it only seems to be there on a[67]xx.
a6xx_create_address_space returns:
- an ERR_PTR if msm_iommu_pagetable_create
From: Konrad Dybcio
A621 is a clear A662 derivative (same lineage as A650), no explosions
or sick features, other than a NoC bug which can stall the GPU..
Add support for it.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 78
From: Konrad Dybcio
This was apparently never done before.. Program the expected values.
This also gets rid of sneakily setting that register through the HWCG
reg list on A690.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 1 -
drivers/gpu/drm/msm/adreno
From: Konrad Dybcio
Store the correct values that we happen to have for some A7xx SKUs in
the GPU info struct and fill out the missing information for A6xx GPUs
based on downstream kernel information.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 18
From: Konrad Dybcio
This register's magic value differs wildly between different GPUs, use
the hardcoded data instead of trying to make some logic out of it.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 ++
1 file changed, 2 insertions(+), 4 dele
Baby A650, needs mesa mr !30253 (or better)
Signed-off-by: Konrad Dybcio
---
Changes in v2:
- Split up the gmu_cgc_mode patches more sensibly and write better
commit messages
- Link to v1:
https://lore.kernel.org/r/20240719-topic-a621-v1-0-850ae5307...@linaro.org
---
Konrad Dybcio (6
From: Konrad Dybcio
A650 family includes A660 family (they've got a big family), A650
itself, and some more A6XX_GEN3 SKUs, all of which should fall into
the same branch of the if-condition. Simplify that.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 3 +--
1
From: Konrad Dybcio
The if-else monster is so unmaintainable that one case is repeated
twice. Get rid of it.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 14 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 24 +---
drivers/gpu/drm
On 27.08.2024 10:12 PM, Rob Clark wrote:
> resending with updated Konrad email addr
>
> On Mon, Aug 26, 2024 at 2:09 PM Rob Clark wrote:
>>
>> On Mon, Aug 26, 2024 at 2:07 PM Rob Clark wrote:
>>>
>>> On Fri, Jul 19, 2024 at 3:03 AM Konrad Dybcio
>>
On 2.08.2024 9:47 PM, Dmitry Baryshkov wrote:
> DPU debugging macros need to be converted to a proper drm_debug_*
> macros, however this is a going an intrusive patch, not suitable for a
> fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER
> to make sure that DPU debugging mess
On 20.08.2024 12:45 PM, Connor Abbott wrote:
> On Tue, Aug 20, 2024 at 11:15 AM Konrad Dybcio wrote:
>>
>> On 15.08.2024 8:26 PM, Antonino Maniscalco wrote:
>>> The bv_fence field of rbmemptrs was being used incorrectly as the BV
>>> rptr shadow pointer in some pl
On 20.08.2024 12:16 PM, Konrad Dybcio wrote:
> On 15.08.2024 8:26 PM, Antonino Maniscalco wrote:
>> Some userspace changes are necessary so add a flag for userspace to
>> advertise support for preemption.
>>
>> Signed-off-by: Antonino Maniscalco
>> ---
>
&g
On 15.08.2024 8:26 PM, Antonino Maniscalco wrote:
> Some userspace changes are necessary so add a flag for userspace to
> advertise support for preemption.
>
> Signed-off-by: Antonino Maniscalco
> ---
Squash this into the "add preemption" patch, or add the flag earlier
(probably the latter, as t
On 15.08.2024 8:26 PM, Antonino Maniscalco wrote:
> This patch adds a bit of infrastructure to give the different Adreno
> targets the flexibility to setup the submitqueues per their needs.
>
> Signed-off-by: Sharat Masetty
> ---
This email doesn't exist anymore and doesn't match yours
Konrad
On 15.08.2024 8:26 PM, Antonino Maniscalco wrote:
> The bv_fence field of rbmemptrs was being used incorrectly as the BV
> rptr shadow pointer in some places.
>
> Add a bv_rptr field and change the code to use that instead.
>
> Signed-off-by: Antonino Maniscalco
> ---
> drivers/gpu/drm/msm/adre
On 29.07.2024 2:51 PM, Wolfram Sang wrote:
> The old email address bounced. I found the newer one in MAINTAINERS,
> so update entries accordingly.
>
> Cc: Konrad Dybcio
> Signed-off-by: Wolfram Sang
> ---
Already sent a series of fixups, but thanks for keeping track
https
On 29.07.2024 2:13 PM, Konrad Dybcio wrote:
> On 16.07.2024 1:56 PM, Konrad Dybcio wrote:
>> On 15.07.2024 10:04 PM, Akhil P Oommen wrote:
>>> On Tue, Jul 09, 2024 at 12:45:29PM +0200, Konrad Dybcio wrote:
>>>> On recent (SM8550+) Snapdragon platforms, the GPU spe
On 16.07.2024 1:56 PM, Konrad Dybcio wrote:
> On 15.07.2024 10:04 PM, Akhil P Oommen wrote:
>> On Tue, Jul 09, 2024 at 12:45:29PM +0200, Konrad Dybcio wrote:
>>> On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
>>> abstracted through SMEM, instead of
On 26.07.2024 1:18 PM, Konrad Dybcio wrote:
> Patch 3 should probably go straight to Rob's dt-bindings tree
>
> Signed-off-by: Konrad Dybcio
> ---
> Konrad Dybcio (3):
> mailmap: Add an entry for Konrad Dybcio
> MAINTAINERS: Update Konrad Dybcio's em
Use my @kernel.org address everywhere.
Signed-off-by: Konrad Dybcio
---
MAINTAINERS | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9200d953868e..6c7d3951192f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2745,7 +2745,7 @@ F
Use my @kernel.org address everywhere.
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml
Map my old addresses.
Signed-off-by: Konrad Dybcio
---
.mailmap | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.mailmap b/.mailmap
index e51d76df75c2..d189c6424697 100644
--- a/.mailmap
+++ b/.mailmap
@@ -353,6 +353,8 @@ Kenneth Westfield
Kiran Gunda
Kirill Tkhai
Kishon Vijay
Patch 3 should probably go straight to Rob's dt-bindings tree
Signed-off-by: Konrad Dybcio
---
Konrad Dybcio (3):
mailmap: Add an entry for Konrad Dybcio
MAINTAINERS: Update Konrad Dybcio's email address
dt-bindings: Batch-update Konrad Dybcio's e
On 23.07.2024 3:38 PM, Marc Gonzalez wrote:
> On 23/07/2024 15:08, Konrad Dybcio wrote:
>
>> On 23.07.2024 2:57 PM, Marc Gonzalez wrote:
>>
>>> On 23/07/2024 13:45, Konrad Dybcio wrote:
>>>
>>>> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote:
>&g
On 23.07.2024 2:57 PM, Marc Gonzalez wrote:
> On 23/07/2024 13:45, Konrad Dybcio wrote:
>
>> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote:
>>
>>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote:
>>>
>>>> On 16/07/2024 18:37, Dmitry Baryshkov w
On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote:
> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote:
>>
>> On 16/07/2024 18:37, Dmitry Baryshkov wrote:
>>
>>> No, that's fine. It is the SMMU issue that Konrad has been asking you
>>> to take a look at.
>>
>> Context:
>>
>> [4.911422] arm-smmu c
1 - 100 of 1293 matches
Mail list logo
