All of lore.kernel.org
 help / color / mirror / Atom feed
From: nsekhar@ti.com (Sekhar Nori)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
Date: Tue, 15 Jan 2013 14:45:47 +0530	[thread overview]
Message-ID: <50F51E43.2090605@ti.com> (raw)
In-Reply-To: <13514BD7FAEBA745BBD7D8A672905C14311FE538@DFLE08.ent.ti.com>

On 1/12/2013 7:56 AM, Tivy, Robert wrote:

>> From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
>> Sent: Friday, January 11, 2013 4:26 AM

>> On Fri, Jan 11, 2013 at 2:23 AM, Robert Tivy <rtivy@ti.com> wrote:
>>> +static int davinci_rproc_probe(struct platform_device *pdev)
>>> +{
>>> +       struct da8xx_rproc_pdata *pdata = pdev->dev.platform_data;
>>> +       struct davinci_rproc *drproc;
>>> +       struct rproc *rproc;
>>> +       struct clk *dsp_clk;
>>> +       int ret;
>>> +
>>> +       if (!fw_name) {
>>> +               dev_err(&pdev->dev, "No firmware file specified\n");
>>> +
>>> +               return -EINVAL;
>>> +       }

>> There are a few issues with this fw_name module param:
>>
>> 1. Usually we don't rely on users providing the firmware file name for
>> drivers to work. Drivers should know the name beforehand, and if there
>> may be several different instances of firmwares (for different cores
>> you may have), then it's just better to get it from the platform data.
> 
> Is this suggesting that there be separate platform device instances for each different potential fw, and that each platform device instance hardcodes the fw filename?

I am not convinced firmware name should be in platform data (or DT)
since it is not hardware specific. User can choose multiple different
firmwares to load on the DSP depending the application he is running all
for the same platform (da850 evm).

> 
>>
>> 2. You may still want to have such a module param in order to be able
>> to override the default firmware name (for debugging purposes?), but
>> I'm not sure it should be davinci-specific. if we do want it to be
>> then please prefix the name with 'davinci'.
> 
> Sekhar asked that there not be a default fw name, so there's conflicting feedback on this point.  I prefer to have a default name plus the module parameter override (but don't have much opinion on whether it should be davinci-specific (and passed with davinci_remoteproc.ko) or general (and passed with remoteproc.ko), please advise).

Rob, I don't remember objecting to a default firmware name if module
parameter is not passed. On 29th November 2012 you wrote:

"
Sounds OK.  I propose then to have the above be the default firmware
name, along with a module parameter that will override if specified.
"

and I wrote back:

"
Sounds good.
"

As you can see, there was no objection from me.

> 
> Since the fw file (i.e., DSP program) is typically paired with a particular Linux app, I like the ability to specify the fw filename at runtime, depending on the Linux app I need to run.

Right, and platform data is not the way to achieve this.

Thanks,
Sekhar

  reply	other threads:[~2013-01-15  9:15 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1357863807-380-1-git-send-email-rtivy@ti.com>
     [not found] ` <1357863807-380-7-git-send-email-rtivy@ti.com>
2013-01-11 12:26   ` [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP Ohad Ben-Cohen
2013-01-12  2:26     ` Tivy, Robert
2013-01-15  9:15       ` Sekhar Nori [this message]
2013-01-15 10:03         ` Ohad Ben-Cohen
2013-01-15 12:29           ` Sekhar Nori
2013-01-15 12:49             ` Ohad Ben-Cohen
2013-01-15 23:06               ` Tivy, Robert
2013-01-15 23:17                 ` Ohad Ben-Cohen
2013-01-16  5:16               ` Sekhar Nori
2013-01-15 10:00       ` Ohad Ben-Cohen
2013-01-12  9:31     ` Russell King - ARM Linux
2013-01-21  5:38   ` Sekhar Nori
2013-01-21 16:41     ` Russell King - ARM Linux
2013-01-21 18:53       ` Tivy, Robert
2013-01-22  2:09     ` Tivy, Robert
     [not found] ` <1357863807-380-2-git-send-email-rtivy@ti.com>
2013-01-16 13:55   ` [PATCH v5 1/9] ARM: davinci: da850 board: change pr_warning() to pr_warn() Sekhar Nori
     [not found] ` <1357863807-380-3-git-send-email-rtivy@ti.com>
2013-01-17  7:47   ` [PATCH v5 2/9] ARM: davinci: devices-da8xx.c: " Sekhar Nori
     [not found] ` <1357863807-380-5-git-send-email-rtivy@ti.com>
2013-01-17  7:55   ` [PATCH v5 4/9] ARM: davinci: da850: added pll0_sysclk1 for DSP usage Sekhar Nori
     [not found] ` <1357863807-380-6-git-send-email-rtivy@ti.com>
2013-01-17 11:33   ` [PATCH v5 5/9] ARM: davinci: New reset functionality/API provided for Davinci DSP Sekhar Nori
2013-01-17 17:46     ` Tivy, Robert
     [not found] ` <1357863807-380-8-git-send-email-rtivy@ti.com>
2013-01-21  8:34   ` [PATCH v5 7/9] ARM: davinci: Remoteproc platform device creation data/code Sekhar Nori
2013-01-22  2:33     ` Tivy, Robert
     [not found] ` <1357863807-380-9-git-send-email-rtivy@ti.com>
2013-01-21  8:36   ` [PATCH v5 8/9] ARM: davinci: da850 board: Added .reserve function and rproc platform registration Sekhar Nori
     [not found] ` <1357863807-380-10-git-send-email-rtivy@ti.com>
2013-01-21 10:36   ` [PATCH v5 9/9] ARM: davinci: da850: Added dsp clock definition Sekhar Nori
2013-01-22 12:03   ` Sekhar Nori
2013-01-23  1:37     ` Tivy, Robert
2013-01-24  6:27       ` Sekhar Nori

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=50F51E43.2090605@ti.com \
    --to=nsekhar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.