Hi Bryan, On 3/20/2024 6:08 PM, Bryan O'Donoghue wrote: > On 20/03/2024 14:11, Depeng Shao wrote: >> From: Yongsheng Li <quic_yon@xxxxxxxxxxx> >> >> The buf done irq and register update register are moved >> to CSID in SM8550, so but the write master configuration >> in VFE, in case adapt existing code logic. So add buf >> done and register related subdev event, and use the notify >> interface in the v4l2_device structure to communicate >> between CSID and VFE driver. > > > Shouldn't it be possible to just have a function to write internally ? > > You know the indexes of the CSID -> VFE connection. > > The subdev notify is I think not the right fit for this purpose within > our driver. > <snip> > > I'm really not sure I see a good reason for this. > > Why can't we just define calls between vfe and csid similar to > > drivers/media/platform/qcom/camss/camss-csid.c: ret = vfe_get(vfe); Maybe we need to rethink and redesign this part of the driver. In the initial version when this driver was introduced the CSID was independent device from hw perspective, and represented as separate sub-device. With the newer architectures CSID was part of IFE hw (handled by the VFE sub-device in this driver) and vfe_get was introduced, but i believe it was not an issue because the CISD still was kind of independent. In the patch series: "https://lore.kernel.org/lkml/20240319173935.481-4-quic_grosikop@xxxxxxxxxxx/T/"; We try to decouple CSID from VFE and remove direct dependency introducing parent_dev_ops, where depending of the topology and parent device (VFE in this case or other parent in future chipsets which contain CSID) can reuse the code. I am not sure if introducing parent_dev_ops is right way to go but we can discuss further and see how to extend the driver in proper way. Just to add i am not saying that adding direct calls to VFE is not proper but just close the door for other sub-device contain CSID to use the code. :-) Regards, ~Gjorgji > > --- > bod >
