[PATCH v5 3/5] media: platform: mediatek: isp_30: add mediatek ISP3.0 sensor interface
Julien Stephan
jstephan at baylibre.com
Mon Jul 29 05:46:29 PDT 2024
Le jeu. 18 juil. 2024 à 04:44, CK Hu (胡俊光) <ck.hu at mediatek.com> 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 at mediatek.com>
> >
> > 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 at mediatek.com>
> > Signed-off-by: Phi-bang Nguyen <pnguyen at baylibre.com>
> > Signed-off-by: Florian Sylvestre <fsylvestre at baylibre.com>
> > Co-developed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > Co-developed-by: Julien Stephan <jstephan at baylibre.com>
> > Signed-off-by: Julien Stephan <jstephan at baylibre.com>
> > ---
>
> [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@collabora.com/).
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!
More information about the linux-arm-kernel
mailing list