From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Marc Gonzalez <mgonzalez@freebox.fr>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: DT <devicetree@vger.kernel.org>,
linux-media <linux-media@vger.kernel.org>,
MSM <linux-arm-msm@vger.kernel.org>,
Stanimir Varbanov <stanimir.k.varbanov@gmail.com>,
Vikash Garodia <quic_vgarodia@quicinc.com>,
Bjorn Andersson <andersson@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Pierre-Hugues Husson <phh@phh.me>
Subject: Re: [RFC WIP PATCH] venus: add qcom,no-low-power property
Date: Tue, 20 Feb 2024 14:27:36 +0100 [thread overview]
Message-ID: <4ab95e87-c912-469b-b8d4-be0cf0e4710b@linaro.org> (raw)
In-Reply-To: <6342e92d-eed0-45c2-8f04-3779aa2e521d@freebox.fr>
On 20/02/2024 13:34, Marc Gonzalez wrote:
> On 20/02/2024 12:37, Krzysztof Kozlowski wrote:
>
>> On 20/02/2024 12:21, Bryan O'Donoghue wrote:
>>
>>> On 20/02/2024 10:56 a.m., Marc Gonzalez wrote:
>>>
>>>> On 19/02/2024 20:24, Bryan O'Donoghue wrote:
>>>>
>>>>> On 19/02/2024 5:44 p.m., Dmitry Baryshkov wrote:
>>>>>
>>>>>> On Mon, 19 Feb 2024 at 19:29, Konrad Dybcio wrote:
>>>>>>>
>>>>>>> On 19.02.2024 18:18, Marc Gonzalez wrote:
>>>>>>>
>>>>>>>> On our msm8998-based device, calling venus_sys_set_power_control()
>>>>>>>> breaks playback. Since the vendor kernel never calls it, we assume
>>>>>>>> it should not be called for this device/FW combo.
>>>>>>>
>>>>>>> FWIW, this is also broken on other SoCs.. 8280/8350 and 6115
>>>>>>> to name a couple.
>>>>>>
>>>>>> Then let's just disable it until it gets unbroken?
>>>>>
>>>>> Its functional on most of our upstream stuff though, why switch if off
>>>>> unless necessary ?
>>>>>
>>>>> Maybe it should be an opt-in instead of an opt-out, TBH my own feeling
>>>>> is its better to minimize the amount of work and opt as per the proposed
>>>>> patch.
>>>>>
>>>>> Perhaps the qcom vidc team can give insights on 8280xp and 8350 when we
>>>>> come to tackling new HFI6XX and later SoCs ...
>>>>
>>>> I was wondering if the chosen property name might cause issues later...
>>>>
>>>> Thinking "qcom,no-low-power" might be a bit too general?
>>>> Perhaps would need to mention venus somewhere in the name,
>>>> to limit this to the video decoder?
>>>
>>> Yep, the word venus should probably appear in the property name.
>>
>> This is RFC, so I am ignoring it, but just in case before you send v2
>> with the same:
>>
>> You described the desired Linux feature or behavior, not the actual
>> hardware. The bindings are about the latter, so instead you need to
>> rephrase the property and its description to match actual hardware
>> capabilities/features/configuration etc.
>
> I added the RFC tag explicitly because I was hoping for the DT folks
> and msm maintainers to comment on the property name ;)
And for the PATCH we would not comment? RFC means not ready and you
gather opinion before doing more work. Some maintainers ignore entirely
RFC patches.
>
> Thanks for your comment!
>
> Here's the proposal for v2:
>
> qcom,venus-broken-low-power-mode
>
> Description:
> This property is defined for devices where playback does not work
> when the video decoder is in low power mode.
Would be nice to know what's broken but if that's tricky to get, then
sounds fine.
Best regards,
Krzysztof
next prev parent reply other threads:[~2024-02-20 13:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 17:18 [RFC WIP PATCH] venus: add qcom,no-low-power property Marc Gonzalez
2024-02-19 17:28 ` Konrad Dybcio
2024-02-19 17:44 ` Dmitry Baryshkov
2024-02-19 19:24 ` Bryan O'Donoghue
2024-02-20 10:56 ` Marc Gonzalez
2024-02-20 11:21 ` Bryan O'Donoghue
2024-02-20 11:37 ` Krzysztof Kozlowski
2024-02-20 12:34 ` Marc Gonzalez
2024-02-20 13:27 ` Krzysztof Kozlowski [this message]
2024-02-20 13:53 ` Vikash Garodia
2024-02-20 14:45 ` Marc Gonzalez
2024-02-23 13:48 ` Vikash Garodia
2024-02-26 13:09 ` Marc Gonzalez
2024-02-26 14:30 ` Vikash Garodia
2024-02-26 15:55 ` Marc Gonzalez
2024-02-27 6:55 ` Vikash Garodia
2024-02-27 16:11 ` Marc Gonzalez
2024-02-29 15:32 ` Vikash Garodia
2024-02-29 16:24 ` Marc Gonzalez
2024-02-29 16:47 ` Jeffrey Hugo
2024-03-12 18:39 ` Konrad Dybcio
2024-04-10 10:24 ` Vikash Garodia
2024-04-08 15:39 ` Marc Gonzalez
2024-04-09 11:27 ` Bryan O'Donoghue
2024-04-09 14:09 ` Marc Gonzalez
2024-04-09 16:53 ` Marc Gonzalez
2024-04-10 8:17 ` Bryan O'Donoghue
2024-04-10 10:34 ` Vikash Garodia
2024-04-10 12:23 ` Marc Gonzalez
2024-04-10 13:14 ` Bryan O'Donoghue
2024-04-10 13:18 ` Marc Gonzalez
2024-04-10 13:29 ` Bryan O'Donoghue
2024-04-10 13:31 ` Bryan O'Donoghue
2024-04-11 9:02 ` Bryan O'Donoghue
2024-04-25 16:43 ` Marc Gonzalez
2024-04-30 16:13 ` venus decoder hangs at EOF Marc Gonzalez
2024-02-19 18:33 ` [RFC WIP PATCH] venus: add qcom,no-low-power property Rob Herring
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=4ab95e87-c912-469b-b8d4-be0cf0e4710b@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=andersson@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=mgonzalez@freebox.fr \
--cc=phh@phh.me \
--cc=quic_vgarodia@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=stanimir.k.varbanov@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).