From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] Driver for pxa architectures
Date: Tue, 24 Mar 2015 06:17:29 +0100 [thread overview]
Message-ID: <201503240617.29810.arnd@arndb.de> (raw)
In-Reply-To: <878uen78u5.fsf@free.fr>
On Monday 23 March 2015, Robert Jarzmik wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> ... removed people not concerned by pxa story ...
>
> >> As for XIP support, I don't have a clear view if it's a requirement for
> >> multiplatform nor if it works in these builds.
> >
> > It would be nice to not have to support both options: if we put pxa into
> > ARCH_MULTIPLATFORM, I'd like to remove the existing entry from the choice
> > statement at the same time.
> Ah I wasn't aware of that ... that will deserve some thought from me ...
It's not 100% required, but it's what we ended up doing on all other
platforms.
> >> > I think all of them are theoretically doable, but I wasn't expecting
> >> > to ever get there.
> >> Well, that makes me a goal to reach, doesn't it ? I'll stick to optimism here,
> >> and we'll see within a year how far I manage to go :)
> >
> > Fair enough. Any work you do on this is highly appreciated anyway,
> > regardless of whether you complete it or not. BTW, one thought I had
> > a while ago was that we can move support for any PXA machines that are
> > DT enabled into mach-mmp, which hopefully will be fully DT-only and
> > multiplatform enabled at some point, and we can keep mach-pxa for the
> > legacy board files if you don't succeed in converting them all.
>
> Actually, this deserves another discussion alltogether. My plan was not to
> convert all pxa board files to dt support, but all internal SoC IPs drivers +
> mach/plat support.
>
> Or put another way at the end :
> - there will be at least one pxa25x board which is fully DT converted
> - there will be at least one pxa27x board which is fully DT converted
> - there will be at least one pxa3xx board which is fully DT converted
>
> - there will be at least one pxa25x board which is not DT converted
> - there will be at least one pxa27x board which is not DT converted
> - there will be at least one pxa3xx board which is not DT converted
>
> I want to keep the support for both legacy platform_data and DT for pxa
> architecture. The idea I had was that only fully DT converted machines will
> benefit from multiplatform support.
I see. On other platforms, we also have board files that are not DT
but are included in multiplatform. I don't see anything wrong in general.
The more important question is whether you want to keep having a single
kernel capable of running on all PXA machines (DT and ATAGS), while also
doing a subset of PXA that can be multiplatform with other ARMv5 targets
like pxa168 (MMP) but excluding the rest of PXA.
> As for mach-mmp, I don't see how this could work, as there are architecture
> specific parts that will probably remain, such as the suspend to RAM code
> (arch/arm/mach-pxa/sleep.S). This might be doable, even if I don't see how.
Those parts could be moved to plat-pxa.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: linux-arm-kernel@lists.infradead.org,
Daniel Mack <daniel@zonque.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] Driver for pxa architectures
Date: Tue, 24 Mar 2015 06:17:29 +0100 [thread overview]
Message-ID: <201503240617.29810.arnd@arndb.de> (raw)
In-Reply-To: <878uen78u5.fsf@free.fr>
On Monday 23 March 2015, Robert Jarzmik wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> ... removed people not concerned by pxa story ...
>
> >> As for XIP support, I don't have a clear view if it's a requirement for
> >> multiplatform nor if it works in these builds.
> >
> > It would be nice to not have to support both options: if we put pxa into
> > ARCH_MULTIPLATFORM, I'd like to remove the existing entry from the choice
> > statement at the same time.
> Ah I wasn't aware of that ... that will deserve some thought from me ...
It's not 100% required, but it's what we ended up doing on all other
platforms.
> >> > I think all of them are theoretically doable, but I wasn't expecting
> >> > to ever get there.
> >> Well, that makes me a goal to reach, doesn't it ? I'll stick to optimism here,
> >> and we'll see within a year how far I manage to go :)
> >
> > Fair enough. Any work you do on this is highly appreciated anyway,
> > regardless of whether you complete it or not. BTW, one thought I had
> > a while ago was that we can move support for any PXA machines that are
> > DT enabled into mach-mmp, which hopefully will be fully DT-only and
> > multiplatform enabled at some point, and we can keep mach-pxa for the
> > legacy board files if you don't succeed in converting them all.
>
> Actually, this deserves another discussion alltogether. My plan was not to
> convert all pxa board files to dt support, but all internal SoC IPs drivers +
> mach/plat support.
>
> Or put another way at the end :
> - there will be at least one pxa25x board which is fully DT converted
> - there will be at least one pxa27x board which is fully DT converted
> - there will be at least one pxa3xx board which is fully DT converted
>
> - there will be at least one pxa25x board which is not DT converted
> - there will be at least one pxa27x board which is not DT converted
> - there will be at least one pxa3xx board which is not DT converted
>
> I want to keep the support for both legacy platform_data and DT for pxa
> architecture. The idea I had was that only fully DT converted machines will
> benefit from multiplatform support.
I see. On other platforms, we also have board files that are not DT
but are included in multiplatform. I don't see anything wrong in general.
The more important question is whether you want to keep having a single
kernel capable of running on all PXA machines (DT and ATAGS), while also
doing a subset of PXA that can be multiplatform with other ARMv5 targets
like pxa168 (MMP) but excluding the rest of PXA.
> As for mach-mmp, I don't see how this could work, as there are architecture
> specific parts that will probably remain, such as the suspend to RAM code
> (arch/arm/mach-pxa/sleep.S). This might be doable, even if I don't see how.
Those parts could be moved to plat-pxa.
Arnd
next prev parent reply other threads:[~2015-03-24 5:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-21 22:44 [PATCH 0/5] Driver for pxa architectures Robert Jarzmik
2015-03-21 22:44 ` Robert Jarzmik
2015-03-21 22:44 ` [PATCH 1/5] Documentation: dmaengine: pxa-dma design Robert Jarzmik
2015-03-21 22:44 ` Robert Jarzmik
2015-03-21 22:44 ` [PATCH 2/5] MAINTAINERS: add pxa dma driver to pxa architecture Robert Jarzmik
2015-03-21 22:44 ` Robert Jarzmik
2015-03-21 22:44 ` [PATCH 3/5] dmaengine: pxa: add pxa dmaengine driver Robert Jarzmik
2015-03-21 22:44 ` Robert Jarzmik
2015-04-02 9:06 ` Robert Jarzmik
2015-04-02 9:06 ` Robert Jarzmik
2015-04-02 10:46 ` Vinod Koul
2015-04-02 10:46 ` Vinod Koul
2015-03-21 22:44 ` [PATCH 4/5] dmaengine: pxa_dma: add debug information Robert Jarzmik
2015-03-21 22:44 ` Robert Jarzmik
2015-03-21 22:44 ` [PATCH 5/5] dmaengine: pxa_dma: add support for legacy transition Robert Jarzmik
2015-03-21 22:44 ` Robert Jarzmik
2015-03-22 2:20 ` [PATCH 0/5] Driver for pxa architectures Arnd Bergmann
2015-03-22 2:20 ` Arnd Bergmann
2015-03-23 9:21 ` Robert Jarzmik
2015-03-23 9:21 ` Robert Jarzmik
2015-03-23 15:04 ` Arnd Bergmann
2015-03-23 15:04 ` Arnd Bergmann
2015-03-23 20:33 ` Robert Jarzmik
2015-03-23 20:33 ` Robert Jarzmik
2015-03-24 5:17 ` Arnd Bergmann [this message]
2015-03-24 5:17 ` Arnd Bergmann
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=201503240617.29810.arnd@arndb.de \
--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 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.