On 2/13/19 1:11 PM, Matthijs van Duin wrote: > 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.
Yeah, best to deal with this as a match data property. We can obviously supply this using pdata-quirks as well, but definitely want to avoid that short-term path. Just FYI, I will be preparing my TI 4.19 baseline to support all the SoCs within the next two weeks, and this will still follow the current 4.14 binding style, but I am going to move some of the files out of remoteproc folder like Roger's series (as per the remoteproc maintainer's wishes). Roger's current upstream series is not yet ready to scale for all the SoCs, and we are also lacking a whole bunch of ti-sysc support for AM335x/AM437x on vanilla 4.19 kernel. regards Suman -- 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/e3463371-0eb9-dd02-1ef2-1e35a9b90883%40ti.com. For more options, visit https://groups.google.com/d/optout.
