public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/7] spi: pl022: attempt to get sspclk by name
Date: Wed, 12 Feb 2014 14:03:26 +0100	[thread overview]
Message-ID: <1786282.mNUF0ZaUg2@wuerfel> (raw)
In-Reply-To: <20140212114740.GE21992@e106331-lin.cambridge.arm.com>

On Wednesday 12 February 2014 11:47:40 Mark Rutland wrote:
> On Wed, Feb 12, 2014 at 11:21:50AM +0000, Arnd Bergmann wrote:
> > On Wednesday 12 February 2014, Mark Rutland wrote:
> > > To me it feels odd to require the last clock in the list (apb_pclk) to
> > > be named, and the rest to be in a particular order. For the dt case it
> > > seems saner to add new clocks with names as it allows arbitrary subsets
> > > of clocks to be wired up and described (though obviously in this case a
> > > missing sspclk would be problematic).
> > 
> > Yes, good point about the missing clocks, and I also agree mixing ordered
> > and named clocks in one device is rather odd and can lead to trouble.
> > 
> > I guess there isn't really a good way out here, and I certainly won't
> > ask for it to be done one way or the other if someone else has a 
> > good argument which way it should be implemented.
> 
> Having thought about it, all dts that for the ssp_pclk must have some
> name for the sspclk (though the specific name is arbitrary). I could get
> the driver to try each of those before falling back to the index
> (perhaps with a helper that takes a list of known aliases), so all
> existing dts (that we are aware of) would work with the clock requested
> by name.

Strange. Why do the even have names in there? What are those strings?

I noticed that ux500 has uses four different strings, one for each
instance, which is obviously a bug and should just be fixed. There is
no way this was intentional, and we can just rely on teh fallback
if you want to have that anyway.

> I assume that for the non-dt case it's possible to name clock inputs to
> a device without the clock being associated with the name globally? If
> so we could get rid of the index usage entirely in this case.

Sorry, I don't understand the question.

	Arnd

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

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11 11:37 [PATCH 0/7] primecell: make correct clock parsing possible Mark Rutland
2014-02-11 11:37 ` [PATCH 1/7] Documentation: devicetree: fix up pl011 clocks Mark Rutland
2014-02-11 11:37 ` [PATCH 2/7] serial: amba-pl011: attempt to get uartclk by name Mark Rutland
2014-02-11 11:37 ` [PATCH 3/7] Documentation: devicetree: fix up pl022 clocks Mark Rutland
2014-02-13 12:55   ` Linus Walleij
2014-02-11 11:37 ` [PATCH 4/7] spi: pl022: attempt to get sspclk by name Mark Rutland
2014-02-11 12:06   ` Mark Brown
2014-02-11 13:39     ` Mark Rutland
2014-02-11 14:08     ` Arnd Bergmann
2014-02-11 15:04       ` Russell King - ARM Linux
2014-02-11 15:48         ` Arnd Bergmann
2014-02-12 10:33       ` Mark Rutland
2014-02-12 10:55         ` Mark Brown
2014-02-12 11:21         ` Arnd Bergmann
2014-02-12 11:47           ` Mark Rutland
2014-02-12 13:03             ` Arnd Bergmann [this message]
2014-02-12 16:12               ` Mark Rutland
2014-02-12 16:22                 ` Mark Brown
2014-02-12 16:31                 ` Arnd Bergmann
2014-02-24 12:26                   ` Linus Walleij
2014-02-12 15:13             ` Mark Brown
2014-02-11 11:37 ` [PATCH 5/7] Documentation: devicetree: fix up pl18x clocks Mark Rutland
2014-02-11 11:37 ` [PATCH 6/7] mmc: arm-mmci: attempt to get mclk by name Mark Rutland
2014-02-11 11:37 ` [PATCH 7/7] Documentation: devicetree: loosen primecell clock requirements Mark Rutland
2014-02-11 12:33 ` [PATCH 0/7] primecell: make correct clock parsing possible Russell King - ARM Linux
2014-02-11 13:59   ` Mark Rutland

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=1786282.mNUF0ZaUg2@wuerfel \
    --to=arnd@arndb.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox