From: Suman Anna <s-anna@ti.com> To: Tony Lindgren <tony@atomide.com>, Roger Quadros <rogerq@ti.com> Cc: ohad@wizery.com, bjorn.andersson@linaro.org, david@lechnology.com, nsekhar@ti.com, t-kristo@ti.com, nsaulnier@ti.com, jreeder@ti.com, m-karicheri2@ti.com, woods.technical@gmail.com, linux-omap@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Robert Nelson <robertcnelson@gmail.com>, dan@kulp.com, Matthijs van Duin <matthijsvanduin@gmail.com>, Rob Herring <robh@kernel.org> Subject: Re: [PATCH v2 01/14] dt-bindings: remoteproc: Add TI PRUSS bindings Date: Thu, 14 Feb 2019 19:22:23 -0600 [thread overview] Message-ID: <3386fca7-73dd-db69-e179-bb90681cf28c@ti.com> (raw) In-Reply-To: <20190214155640.GD5720@atomide.com> Hi Tony, On 2/14/19 9:56 AM, Tony Lindgren wrote: > * Roger Quadros <rogerq@ti.com> [190214 11:09]: >> Suman is mainly concerned about the following changes in v2 >> 1) pruss node does not contain reg property representing entire ICSS. >> 2) pruss node does not contain interrupts. >> >> Both of these are required if drivers/uio/uio_pruss.c or in future if >> VFIO is to be used. >> >> The beagleboard community is a primary user of this driver and we need to >> find a solution so that PRUSS is usable either via remoteproc or via UIO. >> >> Ideal case should allow user to use either of the drivers by just doing >> a unbind and bind. >> >> I don't have a better idea than having a encapsulating node that has >> the appropriate reg and interrupt properties. > > If there are existing use cases that need to be supported > you should list them as non-standard usage in the binding > and not recommended for future use. Rob may have some > comments on how to deal with this. > > Then you can have device driver that needs to pass them > parse them from the PRUSS parent node. That does not mean > there needs to be a top level device driver for PRUSS, > the child control module can just parse the non-standard > bindings for compability from the parent node. The PRUSS SoC bus driver was handling all possible architectures (OMAP, K2 and K3) which have different clocking and reset integration, and also catering to the UIO vs remoteproc usecases, by taking care of clocks and resets. I am ok to replace this layer with the ti-sysc layer on OMAP SoCs since most of the functionality added to the driver is associated with OCP, but we would still need a PRUSS driver. Not all sub-modules are peripherals and managed by respective peripheral drivers, and we still need a central entity managing the sub-system wide resources. Layering wise - it is similar if we would have done a device for the PRUSS local interconnect, but that driver wouldn't have much to do with interconnect functionality. K2 and K3 families uses TI-SCI and so you don't have a similar target-module concept that allows you to query the PRUSS parent node for PRUSS specific ranges or properties. In anycase, I don't think these drivers should depend on a parent interconnect driver. regards Suman > > And naturally in addition to handling the non-standard > binding we need to have a proper standardized binding > too :) > > Regards, > > Tony >
WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com> To: Tony Lindgren <tony@atomide.com>, Roger Quadros <rogerq@ti.com> Cc: <ohad@wizery.com>, <bjorn.andersson@linaro.org>, <david@lechnology.com>, <nsekhar@ti.com>, <t-kristo@ti.com>, <nsaulnier@ti.com>, <jreeder@ti.com>, <m-karicheri2@ti.com>, <woods.technical@gmail.com>, <linux-omap@vger.kernel.org>, <linux-remoteproc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>, Robert Nelson <robertcnelson@gmail.com>, <dan@kulp.com>, Matthijs van Duin <matthijsvanduin@gmail.com>, Rob Herring <robh@kernel.org> Subject: Re: [PATCH v2 01/14] dt-bindings: remoteproc: Add TI PRUSS bindings Date: Thu, 14 Feb 2019 19:22:23 -0600 [thread overview] Message-ID: <3386fca7-73dd-db69-e179-bb90681cf28c@ti.com> (raw) In-Reply-To: <20190214155640.GD5720@atomide.com> Hi Tony, On 2/14/19 9:56 AM, Tony Lindgren wrote: > * Roger Quadros <rogerq@ti.com> [190214 11:09]: >> Suman is mainly concerned about the following changes in v2 >> 1) pruss node does not contain reg property representing entire ICSS. >> 2) pruss node does not contain interrupts. >> >> Both of these are required if drivers/uio/uio_pruss.c or in future if >> VFIO is to be used. >> >> The beagleboard community is a primary user of this driver and we need to >> find a solution so that PRUSS is usable either via remoteproc or via UIO. >> >> Ideal case should allow user to use either of the drivers by just doing >> a unbind and bind. >> >> I don't have a better idea than having a encapsulating node that has >> the appropriate reg and interrupt properties. > > If there are existing use cases that need to be supported > you should list them as non-standard usage in the binding > and not recommended for future use. Rob may have some > comments on how to deal with this. > > Then you can have device driver that needs to pass them > parse them from the PRUSS parent node. That does not mean > there needs to be a top level device driver for PRUSS, > the child control module can just parse the non-standard > bindings for compability from the parent node. The PRUSS SoC bus driver was handling all possible architectures (OMAP, K2 and K3) which have different clocking and reset integration, and also catering to the UIO vs remoteproc usecases, by taking care of clocks and resets. I am ok to replace this layer with the ti-sysc layer on OMAP SoCs since most of the functionality added to the driver is associated with OCP, but we would still need a PRUSS driver. Not all sub-modules are peripherals and managed by respective peripheral drivers, and we still need a central entity managing the sub-system wide resources. Layering wise - it is similar if we would have done a device for the PRUSS local interconnect, but that driver wouldn't have much to do with interconnect functionality. K2 and K3 families uses TI-SCI and so you don't have a similar target-module concept that allows you to query the PRUSS parent node for PRUSS specific ranges or properties. In anycase, I don't think these drivers should depend on a parent interconnect driver. regards Suman > > And naturally in addition to handling the non-standard > binding we need to have a proper standardized binding > too :) > > Regards, > > Tony >
next prev parent reply other threads:[~2019-02-15 1:22 UTC|newest] Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-04 14:22 [PATCH v2 00/14] Add support for TI PRU ICSS Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 14:22 ` [PATCH v2 01/14] dt-bindings: remoteproc: Add TI PRUSS bindings Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 16:33 ` Tony Lindgren 2019-02-05 9:39 ` Roger Quadros 2019-02-05 9:39 ` Roger Quadros 2019-02-05 15:08 ` Murali Karicheri 2019-02-05 15:08 ` Murali Karicheri 2019-02-05 15:41 ` Roger Quadros 2019-02-05 15:41 ` Roger Quadros 2019-02-05 16:15 ` Murali Karicheri 2019-02-05 16:15 ` Murali Karicheri 2019-02-05 16:19 ` Tony Lindgren 2019-02-06 15:04 ` Roger Quadros 2019-02-06 15:04 ` Roger Quadros 2019-02-14 2:47 ` Suman Anna 2019-02-14 2:47 ` Suman Anna 2019-02-05 16:41 ` Tony Lindgren 2019-02-14 3:01 ` Suman Anna 2019-02-14 3:01 ` Suman Anna 2019-02-08 13:51 ` Linus Walleij 2019-02-08 13:51 ` Linus Walleij 2019-02-14 3:12 ` Suman Anna 2019-02-14 3:12 ` Suman Anna 2019-02-14 3:12 ` Suman Anna 2019-02-14 8:37 ` Linus Walleij 2019-02-14 8:37 ` Linus Walleij 2019-02-14 10:55 ` Roger Quadros 2019-02-14 10:55 ` Roger Quadros 2019-02-14 10:55 ` Roger Quadros 2019-02-14 12:52 ` Marc Zyngier 2019-02-14 15:44 ` Roger Quadros 2019-02-14 15:44 ` Roger Quadros 2019-02-14 15:44 ` Roger Quadros 2019-02-14 15:48 ` Roger Quadros 2019-02-14 15:48 ` Roger Quadros 2019-02-14 15:48 ` Roger Quadros 2019-02-15 0:59 ` Suman Anna 2019-02-15 0:59 ` Suman Anna 2019-02-15 0:59 ` Suman Anna 2019-02-20 9:51 ` Linus Walleij 2019-02-14 15:51 ` Marc Zyngier 2019-02-14 15:51 ` Marc Zyngier 2019-02-14 16:50 ` Roger Quadros 2019-02-14 16:50 ` Roger Quadros 2019-02-14 16:50 ` Roger Quadros 2019-02-14 9:47 ` Marc Zyngier 2019-02-14 2:52 ` Suman Anna 2019-02-14 2:52 ` Suman Anna 2019-02-14 11:08 ` Roger Quadros 2019-02-14 11:08 ` Roger Quadros 2019-02-14 15:56 ` Tony Lindgren 2019-02-15 1:22 ` Suman Anna [this message] 2019-02-15 1:22 ` Suman Anna 2019-02-15 1:08 ` Suman Anna 2019-02-15 1:08 ` Suman Anna 2019-02-15 13:43 ` Matthijs van Duin 2019-02-04 14:22 ` [PATCH v2 02/14] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 14:52 ` Andrew F. Davis 2019-02-04 14:52 ` Andrew F. Davis 2019-02-04 15:32 ` Roger Quadros 2019-02-04 15:32 ` Roger Quadros 2019-02-04 16:35 ` Tony Lindgren 2019-02-04 14:22 ` [PATCH v2 03/14] dt-binding: irqchip: Add pruss-intc-irq driver for PRUSS interrupts Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 16:36 ` Tony Lindgren 2019-02-14 2:40 ` Suman Anna 2019-02-14 2:40 ` Suman Anna 2019-02-18 19:32 ` Rob Herring 2019-02-04 14:22 ` [PATCH v2 04/14] irqchip: pruss: Add a PRUSS irqchip " Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 15:11 ` Andrew F. Davis 2019-02-04 15:11 ` Andrew F. Davis 2019-02-04 15:33 ` Roger Quadros 2019-02-04 15:33 ` Roger Quadros 2019-02-05 8:51 ` Roger Quadros 2019-02-05 8:51 ` Roger Quadros 2019-02-14 2:15 ` Suman Anna 2019-02-14 2:15 ` Suman Anna 2019-02-04 18:15 ` Tony Lindgren 2019-02-05 10:35 ` Roger Quadros 2019-02-05 10:35 ` Roger Quadros 2019-02-05 11:04 ` Marc Zyngier 2019-02-05 11:04 ` Marc Zyngier 2019-02-14 2:16 ` Suman Anna 2019-02-14 2:16 ` Suman Anna 2019-02-14 2:16 ` Suman Anna 2019-02-04 14:22 ` [PATCH v2 05/14] remoteproc: add map parameter to da_to_va Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 14:22 ` [PATCH v2 06/14] remoteproc: add page lookup for TI PRU to ELF loader Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 15:19 ` Andrew F. Davis 2019-02-04 15:19 ` Andrew F. Davis 2019-02-14 2:22 ` Suman Anna 2019-02-14 2:22 ` Suman Anna 2019-02-04 14:22 ` [PATCH v2 07/14] remoteproc: Add a rproc_set_firmware() API Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 14:22 ` [PATCH v2 08/14] remoteproc: Add support to handle device specific resource types Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 14:22 ` [PATCH v2 09/14] dt-binding: remoteproc: Add binding doc for PRU Cores in the PRU-ICSS Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-18 19:36 ` Rob Herring 2019-02-18 19:36 ` Rob Herring 2019-02-18 19:36 ` Rob Herring 2019-02-04 14:22 ` [PATCH v2 10/14] remoteproc/pru: Add PRU remoteproc driver Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-14 2:35 ` Suman Anna 2019-02-14 2:35 ` Suman Anna 2019-02-14 3:44 ` Suman Anna 2019-02-14 3:44 ` Suman Anna 2019-02-04 14:22 ` [PATCH v2 11/14] remoteproc/pru: Add pru_rproc_set_ctable() and pru_rproc_set_gpimode() Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 14:22 ` [PATCH v2 12/14] remoteproc/pru: Add support for virtio rpmsg stack Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 14:22 ` [PATCH v2 13/14] rpmsg: virtio_rpmsg_bus: move back rpmsg_hdr into a public header Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 14:22 ` [PATCH v2 14/14] rpmsg: pru: add a PRU RPMsg driver Roger Quadros 2019-02-04 14:22 ` Roger Quadros 2019-02-04 15:26 ` Andrew F. Davis 2019-02-04 15:26 ` Andrew F. Davis
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3386fca7-73dd-db69-e179-bb90681cf28c@ti.com \ --to=s-anna@ti.com \ --cc=bjorn.andersson@linaro.org \ --cc=dan@kulp.com \ --cc=david@lechnology.com \ --cc=devicetree@vger.kernel.org \ --cc=jreeder@ti.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux-remoteproc@vger.kernel.org \ --cc=m-karicheri2@ti.com \ --cc=matthijsvanduin@gmail.com \ --cc=nsaulnier@ti.com \ --cc=nsekhar@ti.com \ --cc=ohad@wizery.com \ --cc=robertcnelson@gmail.com \ --cc=robh@kernel.org \ --cc=rogerq@ti.com \ --cc=t-kristo@ti.com \ --cc=tony@atomide.com \ --cc=woods.technical@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.