From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [RFC 1/4] ARM: tegra: Move SoC drivers to drivers/soc/tegra
Date: Sat, 28 Jun 2014 03:24:07 +0200 [thread overview]
Message-ID: <20140628012406.GC13290@ulmo> (raw)
In-Reply-To: <53ADDDC1.2080603-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]
On Fri, Jun 27, 2014 at 03:10:25PM -0600, Stephen Warren wrote:
> On 06/27/2014 10:58 AM, Thierry Reding wrote:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > These drivers are closely coupled and need to be moved as a whole. One
> > reason for moving them out of arch/arm/mach-tegra is to allow them to be
> > shared with 64-bit ARM.
>
> Aside from any discussions re: splitting out cpuidle, power domains, ...
> into separate subsystem directories, this patch looks conceptually fine
> to me.
>
> That said, given that I think arch/arm64 isn't going to have mach-*
> directories or machine descriptors, I wonder how all this code is going
> to be invoked at boot. arch/arm/mach-tegra/tegra.c calls a bunch of
> these functions at boot right now. So, it seems like moving the code so
> that it can compile in both places is only part of the solution?
Yes, that's correct. My primary motivation for moving this outside of
arch/arm/mach-tegra was because we need the powergate APIs for 64-bit
builds. I can look at moving out only that driver in a first step and
then look at moving cpuidle where it belongs. As for the other pieces
maybe a better solution would be to keep them in arch/arm/mach-tegra
for now until we've determined which of them are really needed for
64-bit and move them out on an as-needed basis. Untangling these on
by one will take some effort, though.
> Are we going to have an arm64-specific SoC driver that binds to the SoC
> compatible in order to initialize everything? If so, I wonder if the
> same can work for arch/arm so everything works the same way?
I think we'll have to do something along those lines. But I'm not sure
how well it will work out because some of these drivers need to be set
up very early, before any of the driver core is up.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2014-06-28 1:24 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-27 16:58 [RFC 1/4] ARM: tegra: Move SoC drivers to drivers/soc/tegra Thierry Reding
[not found] ` <1403888329-24755-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-06-27 16:58 ` [RFC 2/4] ARM: tegra: Add legacy interrupt controller nodes Thierry Reding
[not found] ` <1403888329-24755-2-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-06-27 20:58 ` Stephen Warren
[not found] ` <53ADDAEF.2070805-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-27 23:44 ` Thierry Reding
2014-06-27 16:58 ` [RFC 3/4] soc/tegra: Initialize interrupt controller from DT Thierry Reding
[not found] ` <1403888329-24755-3-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-06-27 21:03 ` Stephen Warren
[not found] ` <53ADDC0C.4060401-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-28 1:12 ` Thierry Reding
2014-06-30 11:30 ` Peter De Schrijver
[not found] ` <20140630113013.GS3679-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2014-06-30 19:51 ` Thierry Reding
2014-06-27 16:58 ` [RFC 4/4] soc/tegra: Remove unused defines Thierry Reding
[not found] ` <1403888329-24755-4-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-06-27 21:03 ` Stephen Warren
[not found] ` <53ADDC22.9060205-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-28 1:12 ` Thierry Reding
2014-06-27 17:30 ` [RFC 1/4] ARM: tegra: Move SoC drivers to drivers/soc/tegra Santosh Shilimkar
[not found] ` <53ADAA1C.70407-l0cyMroinI0@public.gmane.org>
2014-06-27 23:27 ` Thierry Reding
2014-06-28 17:15 ` Santosh Shilimkar
[not found] ` <53AEF81D.3080408-l0cyMroinI0@public.gmane.org>
2014-06-28 20:40 ` Thierry Reding
2014-06-30 7:20 ` Arnd Bergmann
2014-06-30 9:01 ` Thierry Reding
2014-06-30 10:36 ` Catalin Marinas
[not found] ` <20140630103649.GF28951-5wv7dgnIgG8@public.gmane.org>
2014-06-30 10:48 ` Thierry Reding
2014-06-30 13:16 ` Lorenzo Pieralisi
[not found] ` <20140630131628.GA31517-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2014-06-30 19:36 ` Thierry Reding
2014-07-01 10:50 ` Catalin Marinas
[not found] ` <20140701105056.GO18313-5wv7dgnIgG8@public.gmane.org>
2014-07-01 15:05 ` Stephen Warren
[not found] ` <53B2CE4B.2010506-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-07-01 17:00 ` Catalin Marinas
2014-06-30 19:21 ` Thierry Reding
2014-07-01 7:51 ` Peter De Schrijver
2014-07-16 19:31 ` Olof Johansson
[not found] ` <CAOesGMjgNZ0hvWy0p1fh36gOMfBVd-uJSf=AWUsr9GdrrErtyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-16 19:47 ` Thierry Reding
2014-07-17 9:31 ` Catalin Marinas
[not found] ` <20140717093149.GB3180-5wv7dgnIgG8@public.gmane.org>
2014-07-17 16:21 ` Olof Johansson
2014-06-30 7:23 ` Arnd Bergmann
2014-06-30 9:44 ` Catalin Marinas
2014-06-30 18:45 ` Stephen Warren
2014-06-30 10:25 ` Catalin Marinas
[not found] ` <20140630102512.GE28951-5wv7dgnIgG8@public.gmane.org>
2014-06-30 10:49 ` Thierry Reding
2014-06-30 11:46 ` Peter De Schrijver
[not found] ` <20140630114621.GT3679-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2014-06-30 14:13 ` Catalin Marinas
[not found] ` <20140630141334.GK28951-5wv7dgnIgG8@public.gmane.org>
2014-06-30 14:42 ` Peter De Schrijver
[not found] ` <20140630144217.GV3679-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2014-06-30 14:50 ` Peter De Schrijver
2014-06-30 16:08 ` Catalin Marinas
2014-06-27 21:10 ` Stephen Warren
[not found] ` <53ADDDC1.2080603-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-28 1:24 ` Thierry Reding [this message]
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=20140628012406.GC13290@ulmo \
--to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@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