linux-kernel - Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780

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]

Message-ID: <de2c8fa3-afc1-4163-aae5-3868ca59e95e@quicinc.com>
Date: Fri, 16 Aug 2024 20:42:32 +0800
From: Depeng Shao <quic_depengs@...cinc.com>
To: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>, <rfoss@...nel.org>,
        <todor.too@...il.com>, <bryan.odonoghue@...aro.org>,
        <mchehab@...nel.org>, <robh@...nel.org>, <krzk+dt@...nel.org>,
        <conor+dt@...nel.org>
CC: <linux-arm-msm@...r.kernel.org>, <linux-media@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <kernel@...cinc.com>, Yongsheng Li <quic_yon@...cinc.com>
Subject: Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware
 version Titan 780

Hi Vladimir,

On 8/16/2024 5:31 AM, Vladimir Zapolskiy wrote:
> Hi Depeng.
> 
> On 8/15/24 18:43, Depeng Shao wrote:
>> Hi Vladimir,
>>
>>>>
>>>> Thanks for the confirmation, even though I add the rup_update and
>>>> buf_done function in later commits, it is still called in platform
>>>> specific code(camss-vfe-780.c), so I will keep as it is done today.
>>>
>>> let it be so.
>>>
>>> I have another ask about it, please move new camss_reg_update() out from
>>> camss.c into camss-csid.c, and camss_buf_done() from camss.c into camss-
>>> vfe.c
>>>
>>
>> The cross direct call has been removed by below commit, so it looks
>> strange if I add the cross direct call.
>>
>> media: qcom: camss: Decouple VFE from CSID
>> https://lore.kernel.org/lkml/20240522154659.510-9- 
>> quic_grosikop@...cinc.com/
> 
> This I don't understand, please elaborate. I don't ask for a "cross direct
> call", but you do introduce a CSID specific function in the generic camss.c
> and another VFE specific function in the same camss.c
> 

CSID calls vfe_get/vfe_put to power up/reset vfe hw in old code, but 
above decouple commit removes this cross direct call, this commit has 
been merged recently.

> What I ask is just move the current versions of camss_buf_done() and
> camss_reg_update() out from camss.c to the files, which are related to the
> sub-IP blocks, and of course move the function declarations from camss.h
> into camss-vfe.h and camss-csid.h respectively.
> 
> If possible there shall be no CSID or VFE specific specific code in 
> camss.c,
> and that fact is that it's possible.
> 

Yes, I understand what you mean. Let's take camss_buf_done as example, 
if we move camss_buf_done to camss-vfe.c, but this function is called in 
csid csid driver, so here will have a cross direct call again, 
camss_reg_update is same. Since the cross call is removed in above 
commit, then it will be strange if I do this again.

So, I moved them to camss.c

>> I use the v4l2_subdev_notify to do the cross communication in v1 and v2
>> series, but Bryan said, "The subdev notify is I think not the right fit
>> for this purpose within our driver.".
> 
> As far as I see all of that is irrelevant.
> 
>> Then I add an internal notify interface in camss structure, but Bryan
>> suggested to use direct call, so I add these functions directly in 
>> camss.c
>>
>> https://lore.kernel.org/all/236cfe43-8321-4168-8630- 
>> fb9528f581bd@...aro.org/
>>
> 

Thanks,
Depeng