[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAHQ1cqGdT8Td_1iDCKuCazti53hCJ9HC3-mJMCo+g6FzZBnEOw@mail.gmail.com>
Date: Tue, 13 Aug 2019 11:50:33 -0700
From: Andrey Smirnov <andrew.smirnov@...il.com>
To: Horia Geanta <horia.geanta@....com>
Cc: "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
Chris Spencer <christopher.spencer@....co.uk>,
Cory Tusar <cory.tusar@....aero>,
Chris Healy <cphealy@...il.com>,
Lucas Stach <l.stach@...gutronix.de>,
Aymen Sghaier <aymen.sghaier@....com>,
Leonard Crestez <leonard.crestez@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 12/14] crypto: caam - force DMA address to 32-bit on
64-bit i.MX SoCs
On Tue, Aug 13, 2019 at 6:38 AM Horia Geanta <horia.geanta@....com> wrote:
>
> On 8/12/2019 10:27 PM, Andrey Smirnov wrote:
> > On Mon, Aug 5, 2019 at 1:23 AM Horia Geanta <horia.geanta@....com> wrote:
> >>
> >> On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> >>> @@ -603,11 +603,13 @@ static int caam_probe(struct platform_device *pdev)
> >>> ret = init_clocks(dev, ctrlpriv, imx_soc_match->data);
> >>> if (ret)
> >>> return ret;
> >>> +
> >>> + caam_ptr_sz = sizeof(u32);
> >>> + } else {
> >>> + caam_ptr_sz = sizeof(dma_addr_t);
> >> caam_ptr_sz should be deduced by reading MCFGR[PS] bit, i.e. decoupled
> >> from dma_addr_t.
> >>
> >
> > MCFGR[PS] is not mentioned in i.MX8MQ SRM and MCFG_PS in CTPR_MS is
> > documented as set to "0" (seems to match in real HW as well). Doesn't
> > seem like a workable solution for i.MX8MQ. Is there something I am
> > missing?
> >
> If CTPR_MS[PS]=0, this means CAAM does not allow choosing the "pointer size"
> via MCFGR[PS]. Usually in this case the RM does not document MCFGR[PS] bit,
> which is identical to MCFGR[PS]=0.
>
> Thus the logic should be smth. like:
> caam_ptr_sz = CTPR_MS[PS] && MCFGR[PS] ? 64 : 32;
>
Where is PS located in MCFGR? Same as in CTPR_MS, i.e. BIT(17)?
> >> There is another configuration that should be considered
> >> (even though highly unlikely):
> >> caam_ptr_sz=1 - > 32-bit addresses for CAAM
> >> CONFIG_ARCH_DMA_ADDR_T_64BIT=n - 32-bit dma_addr_t
> >> so the logic has to be carefully evaluated.
> >>
> >
> > I don't understand what you mean here. 32-bit CAAM + 32-bit dma_addr_t
> > should already be the case for i.MX6, etc. how is what you describe
> > different?
> >
> Sorry for not being clear.
>
> caam_ptr_sz=1 - > 32-bit addresses for CAAM
> should have been
> caam_ptr_sz=*64* - > 32-bit addresses for CAAM
> i.e. CAAM address has "more than" (>) 32 bits (exact number of bits is
> SoC / chassis specific) and thus will be represented on 8 bytes.
>
Ah, I see. Can this use-case be addressed in a separate series when
the need for it arises?
Thanks,
Andrey Smirnov
Powered by blists - more mailing lists