On Wed, 13 Feb 2019 at 13:42, Roger Quadros <
rog...@ti.com> wrote:
> On 13/02/19 13:57, Matthijs van Duin wrote:
> > +#ifdef CONFIG_ARCH_DAVINCI_DA850
> > if (pdata->sram_pool) {
> > gdev->sram_pool = pdata->sram_pool;
>
> What is this sram pool? Is it about MSMC/OCMC RAM?
No idea, the sram pool is part of the uio-pruss driver for
freon/primus (OMAP-L1xx / AM1xxx / TMS320C674x / DA8xx) SoCs which is
in mainline, but it was never extended to the AM335x (or DT-based
configuration in general).
> Why is this only for DA850?
I simply copied that #ifdef from the previous patchset that existed.
Looking at mach-davinci/Kconfig, I guess it should probably be DA8XX
instead. Since this patchset has so far only been used for kernels
that aren't used on freon/primus anyway, it hasn't really mattered.
> > 0002: add missing hwmods for pruss on dra7 (cherry-pick of a commit also needed for remoteproc-pru)
>
> This part will eventually be not needed as we are moving away from hwmods.
Yeah I know hwmods are going away in the long run, but this patchset
was specifically to get things working on 4.19.
> > 0003: add support for ti,deassert-hard-reset (needed for uio-pruss on am335x)
>
> This should also be managed by ti-sysc bus driver but using some form of
> reset control driver that can toggle the necessary PRM registers RESET bit.
> There were some challenges as to how to keep the clockdomain out of auto-idle
> before reset can be issued.
Presumably whatever solution works for remoteproc-pru should also work
for uio-pruss.
> The only issue I see here is these 2 properties
>
> compatible = "ti,pruss-v2";
> ti,pintc-offset = <0x20000>;
>
> It will be nice if we can retain the compatibles that I'm using here
https://lkml.org/lkml/2019/2/4/679
I'm confused. Those are for remoteproc-pru, not uio-pruss. They expose
different APIs to userspace, and in practice people use the
compatible-string to select the driver.
> We use a different compatible for every SoC as there are differences e.g. different RAM sizes, number of interrupts, INTC offset, etc.
Although in principle the host interrupts available could be detected
based on what's declared in DT, it actually seems to be the same
across all PRUSS instances I've seen (namely 8: host2..host9). The
only other thing that uio-pruss cares about is the INTC offset, which
seems to be 0x4000 for the old PRUSS on freon/primus and 0x20000 for
every instance of PRU-ICSS (including PRU-ICSSG), so the two
compatible-strings that the uio-pruss driver uses seem to be
sufficient for determining that. The uio-pruss driver does not care at
all about any other differences such as RAM sizes.
> > Obviously we could also change the uio-pruss driver to avoid this need for this property entirely. It ought to be implicit from the compatible-string.
>
> Exactly.
When I find a moment I'll see if I can fix that.
Matthijs