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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx/

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@xxxxxxxxxx/



Thanks,
Depeng





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux