mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Grosen, Mark" <mgrosen@ti.com>
To: Sergei Shtylyov <sshtylyov@mvista.com>, Ohad Ben-Cohen <ohad@wizery.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	davinci-linux-open-source 
	<davinci-linux-open-source@linux.davincidsp.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Brian Swetland <swetland@google.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Grant Likely <grant.likely@secretlab.ca>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: RE: [RFC 5/8] remoteproc: add davinci implementation
Date: Fri, 24 Jun 2011 04:25:14 +0000	[thread overview]
Message-ID: <FFF198FBBF957F4393BA834040FEFFA202D66E@DFLE35.ent.ti.com> (raw)
In-Reply-To: <4E035B78.3080200@mvista.com>

> From: Sergei Shtylyov
> Sent: Thursday, June 23, 2011 8:28 AM
> Subject: Re: [RFC 5/8] remoteproc: add davinci implementation
> 
> Hello.

Sergei, thanks for the feedback. Comments below.

Mark

> 
>     It should work on DA830 as well, but not on real DaVinci, so the
> name is misleading...

Yes, we debated calling it da8xx, but felt that with minor changes it could
accomodate the other SoCs in the davinci family. However, it may be better
to start with just the da8xx/omapl13x parts and then rename if we add the
others. 

> [...]
> > +
> > +/*
> > + * Technical Reference:
> > + * OMAP-L138 Applications Processor System Reference Guide
> > + * http://www.ti.com/litv/pdf/sprugm7d
> > + */
> > +
> > +/* local reset bit (0 is asserted) in MDCTL15 register (section
> 9.6.18) */
> > +#define LRST		BIT(8)
> 
>     Perhaps this should be named nLRST or something if the sense is inverted?

If there is an established naming convention for this, I'll adopt it.

> 
> > +/* next state bits in MDCTL15 register (section 9.6.18) */
> > +#define NEXT_ENABLED	0x3
> 
>     Isn't this already declared in <mach/psc.h> as PSC_STATE_ENABLED?

Yes, thanks, I missed it.

> > +/* register for DSP boot address in SYSCFG0 module (section 11.5.6)
> */
> > +#define HOST1CFG	0x44
> 
>     Worth declaring in <mach/da8xx.h> instead...

Possibly - since it is only used for the DSP, I thought it would be better
to keep local to this implementation. I'll adopt whichever approach is the
convention. 

> > +static inline int davinci_rproc_start(struct rproc *rproc, u64
> bootaddr)
> > +{
> > +	struct device *dev = rproc->dev;
> > +	struct davinci_rproc_pdata *pdata = dev->platform_data;
> > +	struct davinci_soc_info *soc_info = &davinci_soc_info;
> > +	void __iomem *psc_base;
> > +	struct clk *dsp_clk;
> > +
> > +	/* hw requires the start (boot) address be on 1KB boundary */
> > +	if (bootaddr & 0x3ff) {
> > +		dev_err(dev, "invalid boot address: must be aligned to
> 1KB\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	dsp_clk = clk_get(dev, pdata->clk_name);
> 
>     We could match using clkdev functionality, but the clock entry
> would need to be changed then...

I followed the existing pattern I saw in other drivers. If there is a new,
better way, please point me to an example.

> 
> > +	if (IS_ERR_OR_NULL(dsp_clk)) {
> > +		dev_err(dev, "clk_get error: %ld\n", PTR_ERR(dsp_clk));
> > +		return PTR_ERR(dsp_clk);
> > +	}
> > +
> > +	clk_enable(dsp_clk);
> 
>      This seems rather senseless activity as on DA8xx the DSP core
> boots the ARM core, so the DSP clock will be already enabled.

I think it is needed. It's true that the DSP initiates the boot, but then it is
reset and the clock disabled. See Section 13.2 of
http://focus.ti.com/lit/ug/sprugm7e/sprugm7e.pdf:

13.2 DSP Wake Up

Following deassertion of device reset, the DSP intializes the ARM296 so that
it can execute the ARM ROM bootloader. Upon successful wake up, the ARM
places the DSP in a reset and clock gated (SwRstDisable) state that is
controlled by the LPSC and the SYSCFG modules.

Besides, the boot loader could have disabled it to save power. The ARM and
DSP are clocked independently, so I think it's best to use clock management.

> > +	rproc->priv = dsp_clk;
> > +
> > +	psc_base = ioremap(soc_info->psc_bases[0], SZ_4K);
> > +
> > +	/* insure local reset is asserted before writing start address */
> > +	__raw_writel(NEXT_ENABLED, psc_base + MDCTL + 4 *
> DA8XX_LPSC0_GEM);
> > +
> > +	__raw_writel(bootaddr, DA8XX_SYSCFG0_VIRT(HOST1CFG));
> 
>     DA8XX_SYSCFG0_VIRT() is not supposed to be used outside mach-davinci. The
> variable it refers is not exported, so driver module won't work.

Ooops, I clearly did not build this as a module. Suggestion how to fix this?

> > +	/* de-assert local reset to start the dsp running */
> > +	__raw_writel(LRST | NEXT_ENABLED, psc_base + MDCTL +
> > +		4 * DA8XX_LPSC0_GEM);
> > +
> > +	iounmap(psc_base);
> > +
> > +	return 0;
> > +}
> > +
> > +static inline int davinci_rproc_stop(struct rproc *rproc)
> > +{
> > +	struct davinci_soc_info *soc_info = &davinci_soc_info;
> > +	void __iomem *psc_base;
> > +	struct clk *dsp_clk = rproc->priv;
> > +
> > +	psc_base = ioremap(soc_info->psc_bases[0], SZ_4K);
> > +
> > +	/* halt the dsp by asserting local reset */
> > +	__raw_writel(NEXT_ENABLED, psc_base + MDCTL + 4 *
> DA8XX_LPSC0_GEM);
> > +
> > +	clk_disable(dsp_clk);
> > +	clk_put(dsp_clk);
> > +
> > +	iounmap(psc_base);
> > +
> > +	return 0;
> > +}
> 
>     All this is DA8xx specific code which won't fly on real DaVincis, so I
> suggest that you rename the file to da8xx_remoteproc.c for clarity; and
> rename the patch as well...

This is probably the right thing to do ...

Mark

  reply	other threads:[~2011-06-24  4:25 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-21  7:18 [RFC 0/8] Introducing a generic AMP/IPC framework Ohad Ben-Cohen
2011-06-21  7:18 ` [RFC 1/8] drivers: add generic remoteproc framework Ohad Ben-Cohen
2011-06-22 17:55   ` Randy Dunlap
2011-06-22 19:11     ` Ohad Ben-Cohen
2011-06-27 20:49   ` Grant Likely
2011-06-27 21:52     ` Grosen, Mark
2011-06-27 22:24       ` Grant Likely
2011-06-27 23:54         ` Grosen, Mark
2011-06-27 23:29     ` Russell King - ARM Linux
2011-06-27 23:35       ` Grant Likely
2011-06-28 21:55       ` Ohad Ben-Cohen
2011-06-28 21:41     ` Ohad Ben-Cohen
2011-06-21  7:18 ` [RFC 2/8] remoteproc: add omap implementation Ohad Ben-Cohen
2011-06-22 10:05   ` Will Newton
2011-06-22 10:50     ` Ohad Ben-Cohen
2011-06-27 21:00   ` Grant Likely
2011-06-29 15:04     ` Ohad Ben-Cohen
2011-06-29 15:31       ` Grant Likely
2011-06-21  7:18 ` [RFC 3/8] omap: add carveout memory support for remoteproc Ohad Ben-Cohen
2011-06-21  7:18 ` [RFC 4/8] omap: add remoteproc devices Ohad Ben-Cohen
2011-06-21  7:18 ` [RFC 5/8] remoteproc: add davinci implementation Ohad Ben-Cohen
2011-06-23 15:27   ` Sergei Shtylyov
2011-06-24  4:25     ` Grosen, Mark [this message]
2011-06-24 15:13       ` Sergei Shtylyov
2011-06-24 15:43         ` Nori, Sekhar
2011-06-27 18:31           ` Grosen, Mark
2011-07-05  5:29             ` Nori, Sekhar
2011-07-05 16:54               ` Grosen, Mark
2011-07-05  5:34             ` Nori, Sekhar
2011-07-05 16:54               ` Grosen, Mark
2011-07-06  4:36                 ` Nori, Sekhar
2011-06-27 18:20         ` Grosen, Mark
2011-06-28  9:36           ` Nori, Sekhar
2011-06-21  7:18 ` [RFC 6/8] davinci: da850: add remoteproc dsp device Ohad Ben-Cohen
2011-06-28 10:18   ` Sergei Shtylyov
2011-06-21  7:18 ` [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus Ohad Ben-Cohen
2011-06-09 17:12   ` Pavel Machek
2011-07-19  5:38     ` Ohad Ben-Cohen
2011-06-22  2:42   ` Rusty Russell
2011-06-22  3:11     ` Sasha Levin
2011-06-22 10:46     ` Ohad Ben-Cohen
2011-09-14 18:38       ` Ohad Ben-Cohen
2011-09-15  0:12         ` Rusty Russell
2011-09-15 14:56           ` Ohad Ben-Cohen
2011-06-27 22:21   ` Grant Likely
2011-06-28 22:46     ` Ohad Ben-Cohen
2011-06-28 22:51       ` Grant Likely
2011-06-28 23:00         ` Ohad Ben-Cohen
2011-06-29 15:43           ` Grant Likely
2011-07-01 15:13             ` Ohad Ben-Cohen
2011-06-28 23:44   ` Randy Dunlap
2011-06-29  6:30     ` Ohad Ben-Cohen
2011-06-29 11:59       ` Arnd Bergmann
2011-06-29 12:29         ` Ohad Ben-Cohen
2011-06-21  7:18 ` [RFC 8/8] rpmsg: add omap host backend Ohad Ben-Cohen
2011-06-21  7:50 ` [RFC 0/8] Introducing a generic AMP/IPC framework Ohad Ben-Cohen
2011-06-21  9:30   ` Ohad Ben-Cohen
2011-06-21 14:20 ` Arnd Bergmann
2011-06-21 15:54   ` Grant Likely
2011-06-22 11:41   ` Ohad Ben-Cohen
2011-06-22 13:05     ` Arnd Bergmann
2011-06-22 13:09       ` Ohad Ben-Cohen
2011-06-23 12:23 ` Michael Williamson
2011-06-23 16:27   ` Grosen, Mark
2011-06-23 18:46     ` Arnd Bergmann
2011-06-24  4:32       ` Grosen, Mark
2011-06-24 20:16 ` Stephen Boyd
2011-06-26  1:11   ` Ohad Ben-Cohen
2011-06-26  1:17     ` Brian Swetland
2011-06-27 21:22     ` Grosen, Mark
2011-06-28 11:26       ` Ohad Ben-Cohen
2011-06-28 11:36         ` Brian Swetland

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=FFF198FBBF957F4393BA834040FEFFA202D66E@DFLE35.ent.ti.com \
    --to=mgrosen@ti.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=davinci-linux-open-source@linux.davincidsp.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ohad@wizery.com \
    --cc=rusty@rustcorp.com.au \
    --cc=sshtylyov@mvista.com \
    --cc=swetland@google.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

all inboxes | Powered by JetHome®