All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: linux-arm-kernel@lists.infradead.org,
	Vinod Koul <vinod.koul@intel.com>,
	Jonathan Corbet <corbet@lwn.net>, Daniel Mack <daniel@zonque.org>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH 0/5] Driver for pxa architectures
Date: Mon, 23 Mar 2015 16:04:44 +0100	[thread overview]
Message-ID: <201503231604.44551.arnd@arndb.de> (raw)
In-Reply-To: <87h9tc6pd8.fsf@free.fr>

On Monday 23 March 2015, Robert Jarzmik wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> > On Saturday 21 March 2015, Robert Jarzmik wrote:
> > as much as I like this series, I think you still have a long way to go before
> > PXA can really be multiplatform. Other parts that would need to be solved
> > include the various cpu_is_pxa*() checks in drivers, the per-board header
> > files, the way that the I/O space is mapped in the PCMCIA drivers and
> > the XIP support.
> Ah yes, now you mention it ...  And still that doesn't frighten me that much,
> and certainly much less than clocks or dma stuff. Only the headers might be
> troublesome, and pxafb will certainly be a big rework, but that's for the next
> step :)

Ok.

> As for the per-board header files, as long as they're used only within mach-pxa
> and not outside (ie. not in drivers) I must admit I don't see what might be a
> problem.

No, headers that are used only in mach-pxa (or even plat-pxa) are unproblematic.

> 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.

> > 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.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] Driver for pxa architectures
Date: Mon, 23 Mar 2015 16:04:44 +0100	[thread overview]
Message-ID: <201503231604.44551.arnd@arndb.de> (raw)
In-Reply-To: <87h9tc6pd8.fsf@free.fr>

On Monday 23 March 2015, Robert Jarzmik wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> > On Saturday 21 March 2015, Robert Jarzmik wrote:
> > as much as I like this series, I think you still have a long way to go before
> > PXA can really be multiplatform. Other parts that would need to be solved
> > include the various cpu_is_pxa*() checks in drivers, the per-board header
> > files, the way that the I/O space is mapped in the PCMCIA drivers and
> > the XIP support.
> Ah yes, now you mention it ...  And still that doesn't frighten me that much,
> and certainly much less than clocks or dma stuff. Only the headers might be
> troublesome, and pxafb will certainly be a big rework, but that's for the next
> step :)

Ok.

> As for the per-board header files, as long as they're used only within mach-pxa
> and not outside (ie. not in drivers) I must admit I don't see what might be a
> problem.

No, headers that are used only in mach-pxa (or even plat-pxa) are unproblematic.

> 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.

> > 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.

	Arnd

  reply	other threads:[~2015-03-23 15:05 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 [this message]
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
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=201503231604.44551.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=daniel@zonque.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=haojian.zhuang@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robert.jarzmik@free.fr \
    --cc=vinod.koul@intel.com \
    /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.