From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Vikash Garodia <vikash.garodia@oss.qualcomm.com>,
Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Bryan O'Donoghue <bod@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 8/8] media: iris: enable support for SC7280 platform
Date: Thu, 9 Oct 2025 17:49:45 +0200 [thread overview]
Message-ID: <0a0afe32-7814-4901-bfbb-6694cd846257@oss.qualcomm.com> (raw)
In-Reply-To: <um6d7e2su4erqet5fxyaxpyulfrzqvadq4izxgmxu3tol3i7jk@godpxwsqeqzs>
On 10/9/25 5:00 PM, Dmitry Baryshkov wrote:
> On Thu, Oct 09, 2025 at 11:19:31AM +0200, Konrad Dybcio wrote:
>> On 10/8/25 9:25 PM, Dmitry Baryshkov wrote:
>>> On Wed, Oct 08, 2025 at 10:26:02AM +0200, Konrad Dybcio wrote:
>>>> On 10/8/25 6:33 AM, Dmitry Baryshkov wrote:
>>>>> As a part of migrating code from the old Venus driver to the new Iris
>>>>> one, add support for the SC7280 platform. It is very similar to SM8250,
>>>>> but it (currently) uses no reset controls (there is an optional
>>>>> GCC-generated reset, it will be added later) and no AON registers
>>>>> region. The Venus driver names this platform "IRIS2_1", so the ops in
>>>>
>>>> Which we've learnt in the past is "IRIS2, 1-pipe"
>>>
>>> Well, I'm open for better suggestions. iris_vpu2_no_aon_ops?
>>
>> [...]
>>
>>>>> + writel(CTL_AXI_CLK_HALT | CTL_CLK_HALT,
>>>>> + core->reg_base + WRAPPER_TZ_CTL_AXI_CLOCK_CONFIG);
>>>>> + writel(RESET_HIGH, core->reg_base + WRAPPER_TZ_QNS4PDXFIFO_RESET);
>>>>> + writel(0x0, core->reg_base + WRAPPER_TZ_QNS4PDXFIFO_RESET);
>>>>> + writel(0x0, core->reg_base + WRAPPER_TZ_CTL_AXI_CLOCK_CONFIG);
>>>>> +
>>>>> +disable_power:
>>>>> + iris_disable_unprepare_clock(core, IRIS_AHB_CLK);
>>>>
>>>> ..for this line
>>>
>>> Not only. You missed the absense of AON_WRAPPER_MVP_NOC_LPI_CONTROL /
>>> AON_WRAPPER_MVP_NOC_LPI_STATUS. Which in theory can become a flag in
>>> iris_platform_data.
>>>
>>>>
>>>> but this could be added to that one instead, since both clk APIs and the
>>>> Iris wrappers around it are happy to consume a null pointer (funnily
>>>> enough this one returns !void and is never checked)
>>>>
>>>> similar story for other func additions
>>>
>>> In fact, initially I had them merged, but then I couldn't find an
>>> elegant way to handle AON regs. I can squash them back, if that's the
>>> consensus. Any idea regarding AON regs?
>>
>> Digging in techpack/video, I found:
>>
>> commit c543f70aca8d40c593b8ad342d42e913a422c552
>> Author: Priyanka Gujjula <pgujjula@codeaurora.org>
>> Date: Fri Feb 14 13:38:31 2020 +0530
>>
>> msm: vidc: Skip AON register programming for lagoon
>>
>> AON register programming is used to set NOC to low
>> power mode during IRIS2 power off sequence. However
>> AON register memory map is not applicable and hence
>> skipping AON register programming for lagoon.
>>
>> Change-Id: Ib63248d118ed9fecfa5fa87925e8f69625dc1ba8
>> Signed-off-by: Priyanka Gujjula <pgujjula@codeaurora.org>
>>
>>
>> lagoon being a downstream codename of the aforementioned sm6350
>>
>> Meaning yeah it's bus topology.. so I think an if-statement within
>> a common flow would be what we want here..
>>
>> perhaps
>>
>> if (core->iris_platform_data->num_vpp_pipe == 1)
>>
>> just like venus and downstream do for the most part, and kick the
>> can down the road.. In an unlikely event someone decides to implement
>> IRIS2_1 on a brand new SoC, we can delay our worries..
>
> But this function is being used for VPU3 devices too, if I'm not
> mistaken. So it becomes a bit ugly... Also I'm not sure if this is
> really related to a num of VPP pipes or the CVP.
Oh.. hm.. maybe we can add a .aon_shutdown op? I'm not sure how
to proceed either
Konrad
next prev parent reply other threads:[~2025-10-09 15:49 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 4:32 [PATCH 0/8] media: iris: port support for Qualcomm SC7280 Dmitry Baryshkov
2025-10-08 4:32 ` [PATCH 1/8] media: iris: turn platform caps into constants Dmitry Baryshkov
2025-10-08 8:32 ` Bryan O'Donoghue
2025-10-09 6:08 ` Dikshita Agarwal
2025-10-09 14:45 ` Dmitry Baryshkov
2025-10-08 4:33 ` [PATCH 2/8] media: iris: turn platform data " Dmitry Baryshkov
2025-10-08 8:32 ` Bryan O'Donoghue
2025-10-09 6:09 ` Dikshita Agarwal
2025-10-08 4:33 ` [PATCH 3/8] media: iris: stop copying r/o data Dmitry Baryshkov
2025-10-08 23:48 ` Bryan O'Donoghue
2025-10-09 0:16 ` Dmitry Baryshkov
2025-10-08 4:33 ` [PATCH 4/8] media: iris: stop encoding PIPE value into fw_caps Dmitry Baryshkov
2025-10-08 8:03 ` Konrad Dybcio
2025-10-08 19:10 ` Dmitry Baryshkov
2025-10-08 4:33 ` [PATCH 5/8] media: iris: remove duplicateion between generic gen2 data and qcs8300 Dmitry Baryshkov
2025-10-08 8:07 ` Konrad Dybcio
2025-10-08 19:15 ` Dmitry Baryshkov
2025-10-09 6:10 ` Dikshita Agarwal
2025-10-09 14:46 ` Dmitry Baryshkov
2025-10-08 4:33 ` [PATCH 6/8] media: iris: rename sm8250 platform file to gen1 Dmitry Baryshkov
2025-10-08 8:08 ` Konrad Dybcio
2025-10-09 7:50 ` Dikshita Agarwal
2025-10-08 4:33 ` [PATCH 7/8] media: iris: move common register definitions to the header Dmitry Baryshkov
2025-10-08 23:50 ` Bryan O'Donoghue
2025-10-09 6:10 ` Dikshita Agarwal
2025-10-09 14:48 ` Dmitry Baryshkov
2025-10-14 9:13 ` Vikash Garodia
2025-10-14 9:51 ` Dmitry Baryshkov
2025-10-14 10:10 ` Vikash Garodia
2025-10-08 4:33 ` [PATCH 8/8] media: iris: enable support for SC7280 platform Dmitry Baryshkov
2025-10-08 8:26 ` Konrad Dybcio
2025-10-08 19:25 ` Dmitry Baryshkov
2025-10-09 9:19 ` Konrad Dybcio
2025-10-09 15:00 ` Dmitry Baryshkov
2025-10-09 15:49 ` Konrad Dybcio [this message]
2025-10-09 16:20 ` Dmitry Baryshkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0a0afe32-7814-4901-bfbb-6694cd846257@oss.qualcomm.com \
--to=konrad.dybcio@oss.qualcomm.com \
--cc=abhinav.kumar@linux.dev \
--cc=bod@kernel.org \
--cc=dikshita.agarwal@oss.qualcomm.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=vikash.garodia@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox