All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ohad Ben-Cohen <ohad@wizery.com>
To: Juan Gutierrez <jgutierrez@ti.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Suman Anna <s-anna@ti.com>
Subject: Re: [PATCH v2 3/3] omap: remoteproc: add support for a boot register
Date: Sun, 6 May 2012 14:21:42 +0300	[thread overview]
Message-ID: <CAK=Wgbb4bJ22BYh444Xndaody7Q7Eoox3K7zvGCFmf6ZMHAa0w@mail.gmail.com> (raw)
In-Reply-To: <1334360392-1494-4-git-send-email-jgutierrez@ti.com>

Hi Juan,

Thanks for the patches ! it's exciting to see that support for OMAP's
DSP is (relatively) easily achieved now. I hope your work can be a
good basis for an OMAP3 port, too.

Overall the patches look good, I have only some minor comments inline.

And - sorry for the late response. I've just left for a (somewhat
long) business trip when you posted this.

On Sat, Apr 14, 2012 at 2:39 AM, Juan Gutierrez <jgutierrez@ti.com> wrote:
> Some remote processors (like Omap4's DSP) need to explicitly
> configure a boot address in a special register or memory
> location

Let's just slightly rephrase this to prevent confusion: some remote
processors "need to have the boot address configured" in a special
register (as opposed to "need to configure").

> @@ -30,6 +30,7 @@ struct platform_device;
>  * @ops: start/stop rproc handlers
>  * @device_enable: omap-specific handler for enabling a device
>  * @device_shutdown: omap-specific handler for shutting down a device
> + * @boot_reg: physical address of the control register for storing boot address
>  */
>  struct omap_rproc_pdata {
>        const char *name;
> @@ -40,6 +41,7 @@ struct omap_rproc_pdata {
>        const struct rproc_ops *ops;
>        int (*device_enable) (struct platform_device *pdev);
>        int (*device_shutdown) (struct platform_device *pdev);
> +       u32 boot_reg;

We might want to use an IORESOURCE_MEM resource instead, since we're
dealing with a platform device anyway.

The driver can then fetch the address using platform_get_resource.

> @@ -203,6 +215,9 @@ static int __devinit omap_rproc_probe(struct platform_device *pdev)
>        return 0;
>
>  free_rproc:
> +       if (oproc->boot_reg)
> +               iounmap(oproc->boot_reg);
> +err_ioremap:
>        rproc_free(rproc);
>        return ret;
>  }

I tend to call those cleanup snippets with names that indicate what they do.

In this case I'd slightly prefer to keep calling the lower snippet
with "free_rproc" and just name the new snippet with something like
"unmap_bootreg". It's then a bit easier to read the code that calls
into those snippets (the reader easily know which cleanup snippet is
invoked by each 'goto').

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: ohad@wizery.com (Ohad Ben-Cohen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/3] omap: remoteproc: add support for a boot register
Date: Sun, 6 May 2012 14:21:42 +0300	[thread overview]
Message-ID: <CAK=Wgbb4bJ22BYh444Xndaody7Q7Eoox3K7zvGCFmf6ZMHAa0w@mail.gmail.com> (raw)
In-Reply-To: <1334360392-1494-4-git-send-email-jgutierrez@ti.com>

Hi Juan,

Thanks for the patches ! it's exciting to see that support for OMAP's
DSP is (relatively) easily achieved now. I hope your work can be a
good basis for an OMAP3 port, too.

Overall the patches look good, I have only some minor comments inline.

And - sorry for the late response. I've just left for a (somewhat
long) business trip when you posted this.

On Sat, Apr 14, 2012 at 2:39 AM, Juan Gutierrez <jgutierrez@ti.com> wrote:
> Some remote processors (like Omap4's DSP) need to explicitly
> configure a boot address in a special register or memory
> location

Let's just slightly rephrase this to prevent confusion: some remote
processors "need to have the boot address configured" in a special
register (as opposed to "need to configure").

> @@ -30,6 +30,7 @@ struct platform_device;
> ?* @ops: start/stop rproc handlers
> ?* @device_enable: omap-specific handler for enabling a device
> ?* @device_shutdown: omap-specific handler for shutting down a device
> + * @boot_reg: physical address of the control register for storing boot address
> ?*/
> ?struct omap_rproc_pdata {
> ? ? ? ?const char *name;
> @@ -40,6 +41,7 @@ struct omap_rproc_pdata {
> ? ? ? ?const struct rproc_ops *ops;
> ? ? ? ?int (*device_enable) (struct platform_device *pdev);
> ? ? ? ?int (*device_shutdown) (struct platform_device *pdev);
> + ? ? ? u32 boot_reg;

We might want to use an IORESOURCE_MEM resource instead, since we're
dealing with a platform device anyway.

The driver can then fetch the address using platform_get_resource.

> @@ -203,6 +215,9 @@ static int __devinit omap_rproc_probe(struct platform_device *pdev)
> ? ? ? ?return 0;
>
> ?free_rproc:
> + ? ? ? if (oproc->boot_reg)
> + ? ? ? ? ? ? ? iounmap(oproc->boot_reg);
> +err_ioremap:
> ? ? ? ?rproc_free(rproc);
> ? ? ? ?return ret;
> ?}

I tend to call those cleanup snippets with names that indicate what they do.

In this case I'd slightly prefer to keep calling the lower snippet
with "free_rproc" and just name the new snippet with something like
"unmap_bootreg". It's then a bit easier to read the code that calls
into those snippets (the reader easily know which cleanup snippet is
invoked by each 'goto').

Thanks,
Ohad.

  reply	other threads:[~2012-05-06 11:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-13 23:39 [PATCH v2 0/3] Fixes in preparation for enabling Dsp in omap4 Juan Gutierrez
2012-04-13 23:39 ` Juan Gutierrez
2012-04-13 23:39 ` [PATCH v2 1/3] omap: mailbox: enable mailbox irq per instance Juan Gutierrez
2012-04-13 23:39   ` Juan Gutierrez
2012-05-06 16:00   ` Ohad Ben-Cohen
2012-05-06 16:00     ` Ohad Ben-Cohen
2012-05-07 22:09     ` Gutierrez, Juan
2012-05-07 22:09       ` Gutierrez, Juan
2012-05-08  9:43       ` Ohad Ben-Cohen
2012-05-08  9:43         ` Ohad Ben-Cohen
2012-04-13 23:39 ` [PATCH v2 2/3] OMAP4: iommu: fix irq and clock name for dsp-iommu Juan Gutierrez
2012-04-13 23:39   ` Juan Gutierrez
2012-05-06 12:33   ` Ohad Ben-Cohen
2012-05-06 12:33     ` Ohad Ben-Cohen
2012-05-07 15:58     ` Gutierrez, Juan
2012-05-07 15:58       ` Gutierrez, Juan
2012-04-13 23:39 ` [PATCH v2 3/3] omap: remoteproc: add support for a boot register Juan Gutierrez
2012-04-13 23:39   ` Juan Gutierrez
2012-05-06 11:21   ` Ohad Ben-Cohen [this message]
2012-05-06 11:21     ` Ohad Ben-Cohen
     [not found]     ` <CADVn9RFOBdw0_19ErT6qEpy7325TG7wWkDfJtdF-6jq74z3nFw@mail.gmail.com>
2012-05-07 15:05       ` Ohad Ben-Cohen
2012-05-07 15:05         ` Ohad Ben-Cohen
2012-05-07 15:54     ` Gutierrez, Juan
2012-05-07 15:54       ` Gutierrez, Juan

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='CAK=Wgbb4bJ22BYh444Xndaody7Q7Eoox3K7zvGCFmf6ZMHAa0w@mail.gmail.com' \
    --to=ohad@wizery.com \
    --cc=jgutierrez@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=s-anna@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 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.