All of lore.kernel.org
 help / color / mirror / Atom feed
From: mporter@ti.com (Matt Porter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 5/6] ARM: davinci: Add support for PRUSS on DA850
Date: Thu, 4 Oct 2012 12:35:46 -0400	[thread overview]
Message-ID: <20121004163546.GK11149@beef> (raw)
In-Reply-To: <506D7F95.2030401@ti.com>

On Thu, Oct 04, 2012 at 05:52:45PM +0530, Sekhar Nori wrote:
> On 10/3/2012 8:25 PM, Matt Porter wrote:
> > +static struct clk pruss_clk = {
> > +	.name		= "pruss",
> > +	.parent		= &pll0_sysclk2,
> > +	.lpsc		= DA8XX_LPSC0_PRUSS,
> > +};
> > +
> >  static struct clk uart0_clk = {
> >  	.name		= "uart0",
> >  	.parent		= &pll0_sysclk2,
> > @@ -378,6 +384,7 @@ static struct clk_lookup da850_clks[] = {
> >  	CLK(NULL,		"tptc1",	&tptc1_clk),
> >  	CLK(NULL,		"tpcc1",	&tpcc1_clk),
> >  	CLK(NULL,		"tptc2",	&tptc2_clk),
> > +	CLK(NULL,		"pruss",	&pruss_clk),
> 
> This is actually incorrect since we should use device name rather than
> con_id for matching the clock. If there is just one clock that the
> driver needs, connection id should be NULL. Looking at the driver now,
> the clk_get() call seems to pass a valid device pointer. So, I wonder
> how you are able to look up the clock even with a NULL device name.

I doublechecked the clk_get() find implentation to confirm that I indeed
did get lucky here. Since pruss has only one instance and the clk_find()
implementation looks for the best found match, it's able to find the
clock just by the con_id, though it's not the "best possible" match in
the find implementation...it's the "best found" match.. As you noted,
this is incorrect though for a clock expected to be used from a driver
context so I will address this in the update.

-Matt

WARNING: multiple messages have this Message-ID (diff)
From: Matt Porter <mporter@ti.com>
To: Sekhar Nori <nsekhar@ti.com>
Cc: Linux DaVinci Kernel List 
	<davinci-linux-open-source@linux.davincidsp.com>,
	Russell King <linux@arm.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Hans J. Koch" <hjk@hansjkoch.de>,
	Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 5/6] ARM: davinci: Add support for PRUSS on DA850
Date: Thu, 4 Oct 2012 12:35:46 -0400	[thread overview]
Message-ID: <20121004163546.GK11149@beef> (raw)
In-Reply-To: <506D7F95.2030401@ti.com>

On Thu, Oct 04, 2012 at 05:52:45PM +0530, Sekhar Nori wrote:
> On 10/3/2012 8:25 PM, Matt Porter wrote:
> > +static struct clk pruss_clk = {
> > +	.name		= "pruss",
> > +	.parent		= &pll0_sysclk2,
> > +	.lpsc		= DA8XX_LPSC0_PRUSS,
> > +};
> > +
> >  static struct clk uart0_clk = {
> >  	.name		= "uart0",
> >  	.parent		= &pll0_sysclk2,
> > @@ -378,6 +384,7 @@ static struct clk_lookup da850_clks[] = {
> >  	CLK(NULL,		"tptc1",	&tptc1_clk),
> >  	CLK(NULL,		"tpcc1",	&tpcc1_clk),
> >  	CLK(NULL,		"tptc2",	&tptc2_clk),
> > +	CLK(NULL,		"pruss",	&pruss_clk),
> 
> This is actually incorrect since we should use device name rather than
> con_id for matching the clock. If there is just one clock that the
> driver needs, connection id should be NULL. Looking at the driver now,
> the clk_get() call seems to pass a valid device pointer. So, I wonder
> how you are able to look up the clock even with a NULL device name.

I doublechecked the clk_get() find implentation to confirm that I indeed
did get lucky here. Since pruss has only one instance and the clk_find()
implementation looks for the best found match, it's able to find the
clock just by the con_id, though it's not the "best possible" match in
the find implementation...it's the "best found" match.. As you noted,
this is incorrect though for a clock expected to be used from a driver
context so I will address this in the update.

-Matt

  parent reply	other threads:[~2012-10-04 16:35 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03 14:55 [PATCH v3 0/6] uio_pruss cleanup and platform support Matt Porter
2012-10-03 14:55 ` Matt Porter
2012-10-03 14:55 ` [PATCH v3 1/6] ARM: davinci: sram: ioremap the davinci_soc_info specified sram regions Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-04 11:48   ` Sekhar Nori
2012-10-04 11:48     ` Sekhar Nori
2012-10-04 12:49     ` Matt Porter
2012-10-04 12:49       ` Matt Porter
2012-10-03 14:55 ` [PATCH v3 2/6] ARM: davinci: da850-dm646x: remove the SRAM_VIRT iotable entry Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-04 11:53   ` Sekhar Nori
2012-10-04 11:53     ` Sekhar Nori
2012-10-04 12:54     ` Matt Porter
2012-10-04 12:54       ` Matt Porter
2012-10-03 14:55 ` [PATCH v3 3/6] ARM: davinci: da850: changed SRAM allocator to shared ram Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-04 11:57   ` Sekhar Nori
2012-10-04 11:57     ` Sekhar Nori
2012-10-04 12:56     ` Matt Porter
2012-10-04 12:56       ` Matt Porter
2012-10-04 20:39     ` Matt Porter
2012-10-04 20:39       ` Matt Porter
2012-10-03 14:55 ` [PATCH v3 4/6] ARM: davinci: add platform hook to fetch the SRAM pool Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-03 14:55 ` [PATCH v3 5/6] ARM: davinci: Add support for PRUSS on DA850 Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-04 12:22   ` Sekhar Nori
2012-10-04 12:22     ` Sekhar Nori
2012-10-04 13:08     ` Matt Porter
2012-10-04 13:08       ` Matt Porter
2012-10-04 16:35     ` Matt Porter [this message]
2012-10-04 16:35       ` Matt Porter
2012-10-05 10:30       ` Sekhar Nori
2012-10-05 10:30         ` Sekhar Nori
2012-10-03 14:55 ` [PATCH v3 6/6] uio: uio_pruss: replace private SRAM API with genalloc Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-04  9:11 ` [PATCH v3 0/6] uio_pruss cleanup and platform support Philipp Zabel
2012-10-04  9:11   ` Philipp Zabel
2012-10-04 12:42   ` Matt Porter
2012-10-04 12:42     ` Matt Porter
2012-10-04 12:54     ` Sekhar Nori
2012-10-04 12:54       ` Sekhar Nori
2012-10-04 13:10       ` Matt Porter
2012-10-04 13:10         ` Matt Porter
2012-10-04 13:35     ` Philipp Zabel
2012-10-04 13:35       ` Philipp Zabel
2012-10-04 13:54       ` Matt Porter
2012-10-04 13:54         ` Matt Porter
2012-10-04 14:06         ` Philipp Zabel
2012-10-04 14:06           ` Philipp Zabel

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=20121004163546.GK11149@beef \
    --to=mporter@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.