linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Gerlach <d-gerlach@ti.com>
To: Arnd Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Cc: <linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>,
	<devicetree@vger.kernel.org>, Ohad Ben-Cohen <ohad@wizery.com>,
	Paul Walmsley <paul@pwsan.com>, Kevin Hilman <khilman@linaro.org>,
	Tony Lindgren <tony@atomide.com>,
	Benoit Cousson <bcousson@baylibre.com>,
	Ohad Ben-Cohen <ohad@wizery.com>
Subject: Re: [RFC PATCH 2/3] soc: ti: Add wkup_m3_ipc driver
Date: Fri, 12 Dec 2014 16:03:21 -0600	[thread overview]
Message-ID: <548B6629.6050203@ti.com> (raw)
In-Reply-To: <2763467.KfXHXHxPJd@wuerfel>

On 11/26/2014 03:51 PM, Arnd Bergmann wrote:
> On Wednesday 26 November 2014 15:38:09 Dave Gerlach wrote:
>> +
>> +static const struct wkup_m3_wakeup_src wakeups[] = {
>> +       {.irq_nr = 35,  .src = "USB0_PHY"},
>> +       {.irq_nr = 36,  .src = "USB1_PHY"},
>> +       {.irq_nr = 40,  .src = "I2C0"},
>> +       {.irq_nr = 41,  .src = "RTC Timer"},
>> +       {.irq_nr = 42,  .src = "RTC Alarm"},
>> +       {.irq_nr = 43,  .src = "Timer0"},
>> +       {.irq_nr = 44,  .src = "Timer1"},
>> +       {.irq_nr = 45,  .src = "UART"},
>> +       {.irq_nr = 46,  .src = "GPIO0"},
>> +       {.irq_nr = 48,  .src = "MPU_WAKE"},
>> +       {.irq_nr = 49,  .src = "WDT0"},
>> +       {.irq_nr = 50,  .src = "WDT1"},
>> +       {.irq_nr = 51,  .src = "ADC_TSC"},
>> +       {.irq_nr = 0,   .src = "Unknown"},
>> +};
>>
> 
> This seems awfully specific to some SoC version, and not aware of
> IRQ domains. It also seems to be only used in a dev_dbg statement,
> so I guess you could just kill this off entirely.

This is determined by the firmware in use on the remote processor and works for
both am335x and am437x. However it is not required information and I'd be fine
with taking it out.

> 
>> +static struct rproc *wkup_m3_get_rproc(struct device *dev)
>> +{
>> +       struct device_node *node;
>> +       struct rproc *rp;
>> +
>> +       node = of_parse_phandle(dev->of_node, "ti,rproc", 0);
>> +       if (!node)
>> +               return NULL;
>> +
>> +       dev = bus_find_device(&platform_bus_type, NULL, node, match);
>> +       if (!dev)
>> +               return NULL;
>> +
>> +       rp = dev_get_drvdata(dev);
>> +       return rp;
> 
> This is wrong on a number of levels. I suspect what you really want
> is an interface exported from drivers/remoteproc that looks up
> a 'struct rproc' and performs the necessary reference counting.
> 
> That one can just use of_find_node_by_phandle() to get to
> a device_node and use that to look up the rproc device in
> a linked list it maintains.

Added Ohad as I should have cc'd him in the first place..

Yes I agree that it's not the best solution. There used to be an
rproc_get/rproc_put api but that was removed, I'll look into adding
rproc_get_by_phandle into drivers/remoteproc as that would be ideal for this
situation and a cleaner way of doing it. Thanks for the comments.

Regards,
Dave

> 
> 	Arnd
> 


  reply	other threads:[~2014-12-12 22:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-26 21:27 [RFC PATCH 0/3] remoteproc: Introduce wkup_m3_rproc driver Dave Gerlach
2014-11-26 21:27 ` [RFC PATCH 1/3] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset Dave Gerlach
2014-11-26 21:27 ` [RFC PATCH 2/3] Documentation: dt: add ti,am3353-wkup-m3 bindings Dave Gerlach
2014-11-26 21:27 ` [RFC PATCH 3/3] remoteproc: wkup_m3: Add wkup_m3 remote proc driver Dave Gerlach
2014-11-26 21:38 ` [RFC PATCH 1/3] Documentation: dt: add ti,am3353-wkup-m3-ipc bindings Dave Gerlach
2014-11-26 21:38 ` [RFC PATCH 2/3] soc: ti: Add wkup_m3_ipc driver Dave Gerlach
2014-11-26 21:51   ` Arnd Bergmann
2014-12-12 22:03     ` Dave Gerlach [this message]
2014-11-26 21:38 ` [RFC PATCH 3/3] ARM: dts: am33xx: Add wkup_m3_ipc node Dave Gerlach
2014-11-26 21:39 ` [RFC PATCH 1/3] Documentation: dt: add ti,am3352-emif bindings Dave Gerlach
2014-11-26 21:39 ` [RFC PATCH 2/3] memory: ti-emif-sram: introduce relocatable suspend/resume handlers Dave Gerlach
2014-11-26 21:39 ` [RFC PATCH 3/3] ARM: dts: am33xx: Add emif node Dave Gerlach

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=548B6629.6050203@ti.com \
    --to=d-gerlach@ti.com \
    --cc=arnd@arndb.de \
    --cc=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=khilman@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ohad@wizery.com \
    --cc=paul@pwsan.com \
    --cc=tony@atomide.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).