All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Auchter <michael.auchter@ni.com>
To: Ben Levinsky <BLEVINSK@xilinx.com>
Cc: "Ed T. Mooring" <emooring@xilinx.com>,
	"sunnyliangjy@gmail.com" <sunnyliangjy@gmail.com>,
	"punit1.agrawal@toshiba.co.jp" <punit1.agrawal@toshiba.co.jp>,
	Stefano Stabellini <stefanos@xilinx.com>,
	Michal Simek <michals@xilinx.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"mathieu.poirier@linaro.org" <mathieu.poirier@linaro.org>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
Date: Tue, 6 Oct 2020 16:31:43 -0500	[thread overview]
Message-ID: <20201006213143.GD701433@xaphan> (raw)
In-Reply-To: <BYAPR02MB4407B7F06962DB30ED90761FB50D0@BYAPR02MB4407.namprd02.prod.outlook.com>

On Tue, Oct 06, 2020 at 07:15:49PM +0000, Ben Levinsky wrote:
> 
> Hi Michael,
> 
> Thanks for the review
> 

< ... snip ... >

> > > +	z_rproc = rproc->priv;
> > > +	z_rproc->dev.release = zynqmp_r5_release;
> > 
> > This is the only field of z_rproc->dev that's actually initialized, and
> > this device is not registered with the core at all, so zynqmp_r5_release
> > will never be called.
> > 
> > Since it doesn't look like there's a need to create this additional
> > device, I'd suggest:
> > 	- Dropping the struct device from struct zynqmp_r5_rproc
> > 	- Performing the necessary cleanup in the driver remove
> > 	  callback instead of trying to tie it to device release
> 
> For the most part I agree. I believe the device is still needed for
> the mailbox client setup.
> 
> As the call to mbox_request_channel_byname() requires its own device
> that has the corresponding child node with the corresponding
> mbox-related properties.
> 
> With that in mind, is it still ok to keep the device node?

Ah, I see. Thanks for the clarification!

Instead of manually dealing with the device node creation for the
individual processors, perhaps it makes more sense to use
devm_of_platform_populate() to create them. This is also consistent with
the way the TI K3 R5F remoteproc driver does things.

Cheers,
 Michael

WARNING: multiple messages have this Message-ID (diff)
From: Michael Auchter <michael.auchter@ni.com>
To: Ben Levinsky <BLEVINSK@xilinx.com>
Cc: Stefano Stabellini <stefanos@xilinx.com>,
	"Ed T. Mooring" <emooring@xilinx.com>,
	"punit1.agrawal@toshiba.co.jp" <punit1.agrawal@toshiba.co.jp>,
	"mathieu.poirier@linaro.org" <mathieu.poirier@linaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"sunnyliangjy@gmail.com" <sunnyliangjy@gmail.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	Michal Simek <michals@xilinx.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
Date: Tue, 6 Oct 2020 16:31:43 -0500	[thread overview]
Message-ID: <20201006213143.GD701433@xaphan> (raw)
In-Reply-To: <BYAPR02MB4407B7F06962DB30ED90761FB50D0@BYAPR02MB4407.namprd02.prod.outlook.com>

On Tue, Oct 06, 2020 at 07:15:49PM +0000, Ben Levinsky wrote:
> 
> Hi Michael,
> 
> Thanks for the review
> 

< ... snip ... >

> > > +	z_rproc = rproc->priv;
> > > +	z_rproc->dev.release = zynqmp_r5_release;
> > 
> > This is the only field of z_rproc->dev that's actually initialized, and
> > this device is not registered with the core at all, so zynqmp_r5_release
> > will never be called.
> > 
> > Since it doesn't look like there's a need to create this additional
> > device, I'd suggest:
> > 	- Dropping the struct device from struct zynqmp_r5_rproc
> > 	- Performing the necessary cleanup in the driver remove
> > 	  callback instead of trying to tie it to device release
> 
> For the most part I agree. I believe the device is still needed for
> the mailbox client setup.
> 
> As the call to mbox_request_channel_byname() requires its own device
> that has the corresponding child node with the corresponding
> mbox-related properties.
> 
> With that in mind, is it still ok to keep the device node?

Ah, I see. Thanks for the clarification!

Instead of manually dealing with the device node creation for the
individual processors, perhaps it makes more sense to use
devm_of_platform_populate() to create them. This is also consistent with
the way the TI K3 R5F remoteproc driver does things.

Cheers,
 Michael

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-10-06 22:53 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05 16:06 [PATCH v18 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP Ben Levinsky
2020-10-05 16:06 ` Ben Levinsky
2020-10-05 16:06 ` [PATCH v18 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration Ben Levinsky
2020-10-05 16:06   ` Ben Levinsky
2020-10-05 16:06 ` [PATCH v18 2/5] firmware: xilinx: Add shutdown/wakeup APIs Ben Levinsky
2020-10-05 16:06   ` Ben Levinsky
2020-10-05 16:06 ` [PATCH v18 3/5] firmware: xilinx: Add RPU configuration APIs Ben Levinsky
2020-10-05 16:06   ` Ben Levinsky
2020-10-05 16:06 ` [PATCH v18 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings Ben Levinsky
2020-10-05 16:06   ` Ben Levinsky
2020-10-08 12:37   ` Linus Walleij
2020-10-08 12:37     ` Linus Walleij
2020-10-08 14:21     ` Ben Levinsky
2020-10-08 14:21       ` Ben Levinsky
2020-10-08 16:45       ` Ben Levinsky
2020-10-08 16:45         ` Ben Levinsky
2020-10-08 20:22       ` Stefano Stabellini
2020-10-08 20:22         ` Stefano Stabellini
2020-10-08 20:54       ` Linus Walleij
2020-10-08 20:54         ` Linus Walleij
2020-10-05 16:06 ` [PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver Ben Levinsky
2020-10-05 16:06   ` Ben Levinsky
2020-10-05 19:34   ` Michael Auchter
2020-10-05 19:34     ` Michael Auchter
2020-10-06 19:15     ` Ben Levinsky
2020-10-06 19:15       ` Ben Levinsky
2020-10-06 21:31       ` Michael Auchter [this message]
2020-10-06 21:31         ` Michael Auchter
2020-10-06 21:46         ` Ben Levinsky
2020-10-06 21:46           ` Ben Levinsky
2020-10-06 22:20           ` Michael Auchter
2020-10-06 22:20             ` Michael Auchter
2020-10-07 14:31             ` Ben Levinsky
2020-10-07 14:31               ` Ben Levinsky
2020-10-15 18:31             ` Ben Levinsky
2020-10-15 18:31               ` Ben Levinsky
2020-10-19 20:43   ` Stefano Stabellini
2020-10-19 20:43     ` Stefano Stabellini
2020-10-19 21:33     ` Ben Levinsky
2020-10-19 21:33       ` Ben Levinsky

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=20201006213143.GD701433@xaphan \
    --to=michael.auchter@ni.com \
    --cc=BLEVINSK@xilinx.com \
    --cc=devicetree@vger.kernel.org \
    --cc=emooring@xilinx.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=michals@xilinx.com \
    --cc=punit1.agrawal@toshiba.co.jp \
    --cc=robh+dt@kernel.org \
    --cc=stefanos@xilinx.com \
    --cc=sunnyliangjy@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: link
Be 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.