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
next prev parent 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: linkBe 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.