[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d3faea2a-cc28-434c-ac10-3dd55561674f@linaro.org>
Date: Tue, 31 Oct 2023 11:54:46 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
hverkuil-cisco@...all.nl, laurent.pinchart@...asonboard.com,
rfoss@...nel.org, todor.too@...il.com, andersson@...nel.org,
mchehab@...nel.org
Cc: linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/5] media: qcom: camss: Move VFE power-domain
specifics into vfe.c
On 26.10.2023 17:50, Bryan O'Donoghue wrote:
> Moving the location of the hooks to VFE power domains has several
> advantages.
>
> 1. Separation of concerns and functional decomposition.
> vfe.c should be responsible for and know best how manage
> power-domains for a VFE, excising from camss.c follows this
> principle.
>
> 2. Embeddeding a pointer to genpd in struct camss_vfe{} meas that we can
> dispense with a bunch of kmalloc array inside of camss.c.
>
> 3. Splitting up titan top gdsc from vfe/ife gdsc provides a base for
> breaking up magic indexes in dtsi.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
> ---
[...]
> + /*
> + * If the number of power-domains is greather than the number of VFEs
greater
> + * then the additional power-domain is for the entire CAMSS block the
> + * 'top' power-domain.
> + */
> + if (camss->genpd_num <= camss->res->vfe_num)
> + return 0;
>
Konrad
Powered by blists - more mailing lists