On Wed, 13 Feb 2019 at 13:42, Roger Quadros <[email protected]> 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 -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAALWOA-rFsCP7wiXDYzCVxuj%2B6kuThnQjWF2cLc0%3DK8z8e2KeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
