| 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
| ||
|
Message-ID: <1fa0f2d9-b193-4fcd-9074-2b68f09ad39c@wanadoo.fr>
Date: Mon, 1 Jul 2024 21:22:23 +0200
From: Marion & Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: Vikram Sharma <quic_vikramsa@...cinc.com>, Robert Foss
<rfoss@...nel.org>, Todor Tomov <todor.too@...il.com>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Kapatrala Syed <akapatra@...cinc.com>,
Hariram Purushothaman <hariramp@...cinc.com>,
cros-qcom-dts-watchers@...omium.org, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Loic Poulain <loic.poulain@...aro.org>, Andi Shyti <andi.shyti@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-i2c@...r.kernel.org, Suresh Vankadara <quic_svankada@...cinc.com>,
Trishansh Bhardwaj <quic_tbhardwa@...cinc.com>
Subject: Re: [PATCH 6/6] media: qcom: camss: support for camss driver for
sc7280
Le 28/06/2024 à 20:32, Vikram Sharma a écrit :
> From: Suresh Vankadara <quic_svankada@...cinc.com>
>
> This change adds support for camss driver for sc7280 soc.
>
> Signed-off-by: Suresh Vankadara <quic_svankada@...cinc.com>
> Signed-off-by: Trishansh Bhardwaj <quic_tbhardwa@...cinc.com>
> Signed-off-by: Vikram Sharma <quic_vikramsa@...cinc.com>
> ---
Hi,
...
> - if (camss->res->version == CAMSS_8250) {
> + switch (camss->res->version) {
> + case CAMSS_8250:
> /* for titan 480, CSID registers are inside the VFE region,
> * between the VFE "top" and "bus" registers. this requires
> * VFE to be initialized before CSID
> @@ -1040,10 +1041,19 @@ int msm_csid_subdev_init(struct camss *camss, struct csid_device *csid,
> else
> csid->base = csid->res->parent_dev_ops->get_base_address(camss, id)
> + VFE_480_CSID_OFFSET;
> - } else {
> + break;
> + case CAMSS_7280:
Maybe, as said for other places by Bryan, keep it ordered (CAMSS_7280,
then CAMSS_8250)?
> + /* for titan 165, CSID registers are inside the VFE region,
> + * between the VFE "top" and "bus" registers. this requires
> + * VFE to be initialized before CSID
> + */
> + csid->base = camss->vfe[id].base + VFE_165_CSID_OFFSET;
> + break;
> + default:
> csid->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
> if (IS_ERR(csid->base))
> return PTR_ERR(csid->base);
> + break;
> }
>
> /* Interrupt */
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> index df7e93a5a4f6..c7e507420732 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> @@ -510,6 +510,7 @@ static void csiphy_gen2_config_lanes(struct csiphy_device *csiphy,
> array_size = ARRAY_SIZE(lane_regs_sdm845[0]);
> break;
> case CAMSS_8250:
> + case CAMSS_7280:
> r = &lane_regs_sm8250[0][0];
> array_size = ARRAY_SIZE(lane_regs_sm8250[0]);
> break;
> @@ -560,6 +561,7 @@ static bool csiphy_is_gen2(u32 version)
> case CAMSS_845:
> case CAMSS_8250:
> case CAMSS_8280XP:
> + case CAMSS_7280:
> ret = true;
> break;
> }
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 83c5a36d071f..757e872b8eb8 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
> @@ -338,6 +338,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
> case CAMSS_845:
> case CAMSS_8250:
> case CAMSS_8280XP:
> + case CAMSS_7280:
Here as well.
> switch (sink_code) {
> case MEDIA_BUS_FMT_YUYV8_1X16:
> {
> @@ -1695,6 +1696,7 @@ static int vfe_bpl_align(struct vfe_device *vfe)
> case CAMSS_845:
> case CAMSS_8250:
> case CAMSS_8280XP:
> + case CAMSS_7280:
Here as well.
> ret = 16;
> break;
> default:
...
> +static int camss_link_entities_v2(struct camss *camss)
> +{
> + int i, j;
> + int ret;
> +
> + for (i = 0; i < camss->res->csiphy_num; i++) {
> + for (j = 0; j < camss->res->csid_num; j++) {
> + ret = media_create_pad_link(&camss->csiphy[i].subdev.entity,
> + MSM_CSIPHY_PAD_SRC,
> + &camss->csid[j].subdev.entity,
> + MSM_CSID_PAD_SINK,
> + 0);
Should there be some error handling path here and below to free the
allocated resources?
.link_entities seems to be new and I can't find it in my -next-20240627,
so I can't check myself if already handle in a way or another by the
framework.
CJ
> + if (ret < 0) {
> + dev_err(camss->dev,
> + "Failed to link %s->%s entities: %d\n",
> + camss->csiphy[i].subdev.entity.name,
> + camss->csid[j].subdev.entity.name,
> + ret);
> + return ret;
> + }
> + }
> + }
> +
> + for (i = 0; i < camss->res->csid_num; i++)
> + for (j = 0; j < camss->vfe[i].res->line_num; j++) {
> + struct v4l2_subdev *csid = &camss->csid[i].subdev;
> + struct v4l2_subdev *vfe = &camss->vfe[i].line[j].subdev;
> +
> + ret = media_create_pad_link(&csid->entity,
> + MSM_CSID_PAD_FIRST_SRC + j,
> + &vfe->entity,
> + MSM_VFE_PAD_SINK,
> + 0);
> + if (ret < 0) {
> + dev_err(camss->dev,
> + "Failed to link %s->%s entities: %d\n",
> + csid->entity.name,
> + vfe->entity.name,
> + ret);
> + return ret;
> + }
> + }
> + return 0;
> +}
...
Powered by blists - more mailing lists