Re: [PATCH v5 3/5] media: platform: mediatek: isp_30: add mediatek ISP3.0 sensor interface

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

 



Le jeu. 18 juil. 2024 à 04:44, CK Hu (胡俊光) <ck.hu@xxxxxxxxxxxx> a écrit :
>
> Hi, Julien:
>
> On Thu, 2024-07-04 at 15:36 +0200, Julien Stephan wrote:
> >
> > External email : Please do not click links or open attachments until you have verified the sender or the content.
> >  From: Louis Kuo <louis.kuo@xxxxxxxxxxxx>
> >
> > This will add the mediatek ISP3.0 seninf (sensor interface) driver found
> > on several Mediatek SoCs such as the mt8365.
> >
> > Then seninf module has 4 physical CSI-2 inputs. Depending on the soc they
> > may not be all connected.
> >
> > Signed-off-by: Louis Kuo <louis.kuo@xxxxxxxxxxxx>
> > Signed-off-by: Phi-bang Nguyen <pnguyen@xxxxxxxxxxxx>
> > Signed-off-by: Florian Sylvestre <fsylvestre@xxxxxxxxxxxx>
> > Co-developed-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> > Co-developed-by: Julien Stephan <jstephan@xxxxxxxxxxxx>
> > Signed-off-by: Julien Stephan <jstephan@xxxxxxxxxxxx>
> > ---
>
> [snip]
>
> > +static const struct mtk_seninf_conf seninf_8365_conf = {
> > +.model = "mtk-camsys-3.0",
> > +.nb_inputs = 4,
> > +.nb_muxes = 6,
> > +.nb_outputs = 4,
> > +};
> > +
>
> I think you should directly define these value as symbols because now
> only support one SoC.
>
> #define MODEL     "mtk-camsys-3.0"
> #define INPUT_NR  4
> #define MUTEX_NR  6
> #define OUTPUT_NR 4
>
> Because we don't know which SoC would be upstream later, maybe the next
> SoC would be
>
> static const struct mtk_seninf_conf seninf_83xx_conf = {
>         .model = "mtk-camsys-3.0",
>         .nb_inputs = 4,
>         .nb_muxes = 6,
>         .nb_outputs = 4,
>         .support_xxx = true;
> };
>
> then model, nb_inputs, nb_muxes, and nb_outputs has no difference, so
> it's not necessary to define them as variable. So define them as
> constant now, and when next SoC upstream, then we know which one would
> be variable.
>

Hi CK,

Thank you for your feedback on this series.
We already discussed this in an early version of the series (see
https://lore.kernel.org/all/2dd412f0-86cb-3ae0-305d-0e8192b9128a@xxxxxxxxxxxxx/).
I also discussed with internal teams in Mediatek about the folder
architecture. If this is not a red flag for you, I 'll let it as is.

I will fix other comments you did and that I forgot to add in previous versions.

Cheers
Julien

> Regards,
> CK
>
>
>
> ************* MEDIATEK Confidentiality Notice ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!





[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux