Re: [PATCH v6 12/14] crypto: caam - force DMA address to 32-bit on 64-bit i.MX SoCs

[Andrey Smirnov]

On Tue, Aug 13, 2019 at 6:38 AM Horia Geanta <horia.geanta@xxxxxxx> wrote:
>
> On 8/12/2019 10:27 PM, Andrey Smirnov wrote:
> > On Mon, Aug 5, 2019 at 1:23 AM Horia Geanta <horia.geanta@xxxxxxx> 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