linux-kernel - Re: [PATCH 0/4] venus: add support for 10 bit decoding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 May 2023 19:34:28 +0530
From:   Vikash Garodia <quic_vgarodia@...cinc.com>
To:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Dikshita Agarwal <quic_dikshita@...cinc.com>,
        <linux-media@...r.kernel.org>, <stanimir.k.varbanov@...il.com>,
        <agross@...nel.org>, <andersson@...nel.org>,
        <konrad.dybcio@...aro.org>, <mchehab@...nel.org>
CC:     <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH 0/4] venus: add support for 10 bit decoding


On 5/4/2023 7:21 PM, Bryan O'Donoghue wrote:
> On 04/05/2023 14:49, Bryan O'Donoghue wrote:
>> On 04/05/2023 11:36, Dikshita Agarwal wrote:
>>> This series includes the changes to
>>>    - add V4L2_PIX_FMT_P010 as supported decoder format.
>>>    - consider dpb color format while calculating buffer
>>>      size for dpb buffers.
>>>    - update dpb and opb color format when bit depth
>>>      changes is detected, also update preferred color
>>>      format to P010 in this case.
>>>
>>> With this series, divided the previous version [1] into
>>> multiple patches as suggested in review comments.
>>>
>>> [1] 
>>> https://patchwork.linuxtv.org/project/linux-media/list/?series=10376
>>>
>>> Dikshita Agarwal (4):
>>>    venus: add support for V4L2_PIX_FMT_P010 color format
>>>    venus: update calculation for dpb buffers
>>>    venus: add handling of bit depth change from firmwar
>>>    venus: return P010 as preferred format for 10 bit decode
>>>
>>>   drivers/media/platform/qcom/venus/helpers.c        | 24 
>>> ++++++++++++++++++++++
>>>   drivers/media/platform/qcom/venus/hfi_plat_bufs.h  |  3 +++
>>>   .../media/platform/qcom/venus/hfi_plat_bufs_v6.c   |  8 +++++++-
>>>   drivers/media/platform/qcom/venus/vdec.c           | 16 
>>> +++++++++++++--
>>>   4 files changed, 48 insertions(+), 3 deletions(-)
>>>
>>
>> For future reference a series like this should:
>>
>> 1. Include a log of what changed between the last series and this
>> 2. Describe which comments you addressed
>>     I generally try to say
>>     "Added newline to dts - Konrad"
>>     "Sent the series as a -v3 - Bryan"
>>     etc
>> 3. Ideally provide a link to the previous series in
>>
>> https://lore.kernel.org/linux-arm-msm/1682492417-20496-1-git-send-email-quic_dikshita@quicinc.com/ 
>>
>> 4. Use versioning
>>     This set should be prefixed with "v2-0000-cover-letter" 
>> "v2-0001-add-support" etc
>>
>> "git format-patch mybase..targettip --cover-letter -v2"
>>
>> ---
>> bod
>
> Doh I see you did most of that - just missed the V2.
>
> Please remember to version your subsequent series. "git format-patch -v2"

Does this qualify for a version upgrade when a single patch is 
subsequently raised as series ? IMO, the link

to previous single patch in cover letter and then starting the series 
(as v0) seems to provide the required info.

>
> ---
> bod