From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
linux-kernel@vger.kernel.org, grant.likely@secretlab.ca,
linus.walleij@linaro.org, eric.y.miao@gmail.com,
linux@arm.linux.org.uk, haojian.zhuang@gmail.com,
chao.bi@intel.com, "H. Peter Anvin" <hpa@linux.intel.com>
Subject: Re: [PATCH 05/11] spi/pxa2xx: make clock rate configurable from platform data
Date: Thu, 10 Jan 2013 15:07:40 +0200 [thread overview]
Message-ID: <20130110130740.GP13897@intel.com> (raw)
In-Reply-To: <20130110125159.GQ20956@opensource.wolfsonmicro.com>
On Thu, Jan 10, 2013 at 12:51:59PM +0000, Mark Brown wrote:
> On Thu, Jan 10, 2013 at 01:54:41PM +0100, Rafael J. Wysocki wrote:
> > On Thursday, January 10, 2013 02:38:37 PM Mika Westerberg wrote:
>
> > > 3. We make the acpi_create_platform_device() match on, lets say
> > > "INT33C" (a partial match), and in such case it assumes that we are
> > > running on Lynxpoint. It will then create platform device for 'clk-lpt'.
>
> > > 4. Now the clk-lpt driver creates the clocks.
>
> > > 5. The SPI driver gets the clock it wants.
>
> > That sounds reasonable to me. Mark, what do you think?
>
> Sounds sensible, yes - about what I'd expect. Is it possible to match
> on CPUID or similar information (given that this is all in the SoC)
> instead of ACPI, that might be more robust I guess?
I can look into that but I'm not sure whether there are any other way to
detect are we running on Lynxpoint or not, except the device IDs (and even
that is not 100% guaranteed because of ACPI _CIDs).
next prev parent reply other threads:[~2013-01-10 13:04 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-07 10:44 [PATCH 00/11] spi/pxa2xx: add Intel Lynxpoint SPI controller support Mika Westerberg
2013-01-07 10:44 ` [PATCH 01/11] spi/pxa2xx: allow building on a 64-bit kernel Mika Westerberg
2013-01-08 3:27 ` Eric Miao
2013-01-08 10:29 ` Mika Westerberg
2013-01-07 10:44 ` [PATCH 02/11] spi/pxa2xx: convert to the pump message infrastructure Mika Westerberg
2013-01-17 9:26 ` Linus Walleij
2013-01-07 10:44 ` [PATCH 03/11] spi/pxa2xx-pci: switch to use pcim_* interfaces Mika Westerberg
2013-01-08 10:59 ` Mark Brown
2013-01-07 10:44 ` [PATCH 04/11] spi/pxa2xx: embed the ssp_device to platform data Mika Westerberg
2013-01-07 10:44 ` [PATCH 05/11] spi/pxa2xx: make clock rate configurable from " Mika Westerberg
2013-01-08 11:02 ` Mark Brown
2013-01-08 12:41 ` Mika Westerberg
2013-01-08 13:10 ` Mark Brown
2013-01-08 21:33 ` Rafael J. Wysocki
2013-01-09 10:51 ` Mika Westerberg
2013-01-09 21:52 ` Rafael J. Wysocki
2013-01-10 10:00 ` Mika Westerberg
2013-01-09 12:25 ` Mark Brown
2013-01-09 22:07 ` Rafael J. Wysocki
2013-01-10 9:58 ` Mika Westerberg
2013-01-10 12:38 ` Mika Westerberg
2013-01-10 12:54 ` Rafael J. Wysocki
2013-01-10 12:51 ` Mark Brown
2013-01-10 13:07 ` Mika Westerberg [this message]
2013-01-10 13:23 ` Rafael J. Wysocki
2013-01-10 13:33 ` Mika Westerberg
2013-01-10 13:18 ` Rafael J. Wysocki
2013-01-10 13:33 ` Mark Brown
2013-01-10 13:58 ` Mika Westerberg
2013-01-10 21:56 ` Rafael J. Wysocki
2013-01-11 10:59 ` Mark Brown
2013-01-10 13:08 ` Mika Westerberg
2013-01-08 21:37 ` Rafael J. Wysocki
2013-01-07 10:44 ` [PATCH 06/11] spi/pxa2xx: use the private DMA API only when CONFIG_ARCH_PXA is set Mika Westerberg
2013-01-17 9:36 ` Linus Walleij
2013-01-17 10:00 ` Mika Westerberg
2013-01-07 10:44 ` [PATCH 07/11] spi/pxa2xx: add support for DMA engine Mika Westerberg
2013-01-17 9:48 ` Linus Walleij
2013-01-17 10:39 ` Mika Westerberg
2013-01-07 10:44 ` [PATCH 08/11] spi/pxa2xx: add support for runtime PM Mika Westerberg
2013-01-07 10:44 ` [PATCH 09/11] spi/pxa2xx: add support for SPI_LOOP Mika Westerberg
2013-01-07 10:44 ` [PATCH 10/11] spi/pxa2xx: add support for Intel Low Power Subsystem SPI Mika Westerberg
2013-01-07 10:44 ` [PATCH 11/11] spi/pxa2xx: add support for Lynxpoint SPI controllers Mika Westerberg
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=20130110130740.GP13897@intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=chao.bi@intel.com \
--cc=eric.y.miao@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=haojian.zhuang@gmail.com \
--cc=hpa@linux.intel.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=rjw@sisk.pl \
/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;
as well as URLs for NNTP newsgroup(s).