devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	Russell King - ARM Linux
	<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	linux ARM
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: machine_is_dt() ?
Date: Mon, 07 Jan 2013 08:59:41 -0600	[thread overview]
Message-ID: <50EAE2DD.805@gmail.com> (raw)
In-Reply-To: <20130106140821.GR17242-g2DYL2Zd6BY@public.gmane.org>

On 01/06/2013 08:08 AM, Andrew Lunn wrote:
> On Sun, Jan 06, 2013 at 01:41:13PM +0000, Russell King - ARM Linux wrote:
>> On Sun, Jan 06, 2013 at 02:18:05PM +0100, Andrew Lunn wrote:
>>> I'm moving the cpuidle code for Kirkwood into drivers/cpuidle. I'm
>>> following the way cpuidle-calxeda.c instantiates the driver, it uses
>>> module_init(calxeda_cpuidle_init) and calxeda_cpuidle_init() uses
>>> of_machine_is_compatible("calxeda,highbank") so only loading the
>>> driver in a ARCH_MULTIPLATFORM kernel when needed.
>>>
>>> I can follow this model for when kirkwood is booted using device
>>> tree. However, i would also like to use the driver for those boards
>>> which are not yet converted to DT. In that situation, we have a kernel
>>> dedicate to kirkwood and the cpuidle driver is always relevant.
>>>
>>> Thus i need to code something like:
>>>
>>> (of_machine_is_compatible("marvell, kirkwood") ||
>>>  !machine_is_dt())
>>>
>>> However, there is no macro machine_is_dt().
>>>
>>> Is there a way to tell if a machine has been booted using a machine
>>> number as opposed to DT?
>>
>> This doesn't seem to me to be the right way to deal with this.  What
>> you're suggesting would mean that if you built a multiplatform kernel
>> which included this driver, and booted it on a non-DT platform, you'd
>> have this driver registered.
> 
> Hi Russel
> 
> Yes, not what i want. I would need to limit it further to non-DT
> platform on Kirkwood.
> 
>> It looks to me like many of the CPUFREQ drivers just register themselves
>> if they've been built into the kernel.  No one's thought about making
>> them platform drivers or similar, so the current "if it's built-in, then
>> we use it" approach seems to have persisted.  As many of them are
>> initialized via a late_initcall(), I don't see any problem with them
>> being platform drivers, which will solve the problem in a way that's
>> well established.
> I actually went towards a platform driver to start with. See the
> discussion here:
> 
> https://patchwork.kernel.org/patch/1915171/
> 
> About 1/2 way down, Rob Herring says:
> 
>       Don't do a platform driver and just check the machine compatible
>       property which is what I did for highbank.
> 
> What Rob mostly seems to be objecting to is that
> 
> +		cpuidle@1418 {
> +			compatible = "marvell,kirkwood-cpuidle";
> +			reg = <0x1418 0x4>;
> +		};
> 
> does not describe hardware, so it does not belong in DT. Hence i will
> check of_machine_is_compatible() to see if its a marvell,kirkwood. But
> that does not help with old style boots.
> 
> Should i make it both a platform driver for old style boots and check
> of_machine_is_compatible() for DT boots?

You could make the platform code create the platform device in the DT
case as well. Not all platform devices have to come from a DT node and
putting virtual devices in DT is wrong.

Rob

> Thanks
> 	Andrew
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 

  parent reply	other threads:[~2013-01-07 14:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-06 13:18 machine_is_dt() ? Andrew Lunn
     [not found] ` <20130106131805.GQ17242-g2DYL2Zd6BY@public.gmane.org>
2013-01-06 13:41   ` Russell King - ARM Linux
     [not found]     ` <20130106134113.GD2631-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-01-06 14:08       ` Andrew Lunn
     [not found]         ` <20130106140821.GR17242-g2DYL2Zd6BY@public.gmane.org>
2013-01-07 14:59           ` Rob Herring [this message]
     [not found]             ` <50EAE2DD.805-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-07 23:14               ` Linus Walleij
2013-01-08  0:48   ` Shawn Guo

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=50EAE2DD.805@gmail.com \
    --to=robherring2-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=andrew-g2DYL2Zd6BY@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.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;
as well as URLs for NNTP newsgroup(s).