linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: ssantosh@kernel.org, "Anna, Suman" <s-anna@ti.com>,
	santosh.shilimkar@oracle.com, robh+dt@kernel.org,
	Lee Jones <lee.jones@linaro.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	"Mills, William" <wmills@ti.com>,
	"Bajjuri, Praneeth" <praneeth@ti.com>
Subject: Re: [PATCH 0/6] Add TI PRUSS platform driver
Date: Sun, 2 Aug 2020 23:41:05 +0200	[thread overview]
Message-ID: <CAMxfBF6k9wK1iPd7b42xGfDsG5rOBV2rWmVeWxY4UKTTwjSPDQ@mail.gmail.com> (raw)
In-Reply-To: <20200802115701.GD1162@bug>

Hi

On Sun, 2 Aug 2020 at 13:57, Pavel Machek <pavel@ucw.cz> wrote:
>
> On Sun 2020-08-02 13:53:30, Pavel Machek wrote:
> > Hi!
> >
> > > A typical usage scenario would be to load the application firmware into one or
> > > more of the PRU cores, initialize one or more of the peripherals and perform I/O
> > > through shared RAM from either a kernel driver or directly from userspace.
> > >
> > > This series contains the PRUSS platform driver. This is the parent driver for
> > > the entire PRUSS and is used for managing the subsystem level resources like
> > > various memories and the CFG module.  It is responsible for the creation and
> > > deletion of the platform devices for the child PRU devices and other child
> > > devices (like Interrupt Controller, MDIO node and some syscon nodes) so that
> > > they can be managed by specific platform drivers.
> >
> > >  drivers/soc/ti/Kconfig | 11 + drivers/soc/ti/Makefile | 1 + drivers/soc/ti/pruss.c |
> >
> > Is drivers/soc right place for that? We already have subsystem for various
> > programmable accelerators...
>
> ....see drivers/remoteproc.

Yes I am aware of that and remoteproc sub-system will be used but only
for managing PRU cores (drivers/remoteproc/pru-rproc - will be
submitted soon), while this driver is the parent driver for the entire
PRUSS (used for managing the subsystem level resources like various
memories and the CFG module). This driver is also responsible for
populating all child devices (described in DT), managed by specific
(and separate) drivers: e.g.:
- PRU core will be managed by drivers/remoteproc/pru-rproc (will be
submitted next)
- PRU interrupt controller will be managed by
drivers/irqchip/irq-pruss-intc.c (it is already under review)
etc.

Best regards,
Grzegorz

  reply	other threads:[~2020-08-02 21:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29 11:02 [PATCH 0/6] Add TI PRUSS platform driver Grzegorz Jaszczyk
2020-07-29 11:02 ` [PATCH 1/6] dt-bindings: soc: ti: Add TI PRUSS bindings Grzegorz Jaszczyk
2020-08-17 21:14   ` Rob Herring
2020-08-18 22:07     ` Grzegorz Jaszczyk
2020-07-29 11:02 ` [PATCH 2/6] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs Grzegorz Jaszczyk
2020-07-29 11:02 ` [PATCH 3/6] soc: ti: pruss: Add support for PRU-ICSSs on AM437x SoCs Grzegorz Jaszczyk
2020-07-29 11:02 ` [PATCH 4/6] soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs Grzegorz Jaszczyk
2020-07-29 11:02 ` [PATCH 5/6] soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC Grzegorz Jaszczyk
2020-07-29 11:02 ` [PATCH 6/6] soc: ti: pruss: enable support for ICSSG subsystems on K3 AM65x SoCs Grzegorz Jaszczyk
2020-08-02 11:53 ` [PATCH 0/6] Add TI PRUSS platform driver Pavel Machek
2020-08-02 11:57   ` Pavel Machek
2020-08-02 21:41     ` Grzegorz Jaszczyk [this message]
2020-08-20 14:43 ` Suman Anna
2020-08-20 16:27   ` santosh.shilimkar

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=CAMxfBF6k9wK1iPd7b42xGfDsG5rOBV2rWmVeWxY4UKTTwjSPDQ@mail.gmail.com \
    --to=grzegorz.jaszczyk@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=praneeth@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=s-anna@ti.com \
    --cc=santosh.shilimkar@oracle.com \
    --cc=ssantosh@kernel.org \
    --cc=wmills@ti.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).