dmaengine Archive on lore.kernel.org
 help / color / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Martin Michlmayr <tbm@cyrius.com>,
	Peter Teichmann <lists@peter-teichmann.de>,
	Arnd Bergmann <arnd@arndb.de>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	soc@kernel.org, Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Vinod Koul <vkoul@kernel.org>,
	linux-i2c <linux-i2c@vger.kernel.org>,
	dmaengine@vger.kernel.org,
	Dan Williams <dan.j.williams@intel.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
Date: Fri, 16 Aug 2019 16:58:33 +0100
Message-ID: <20190816155833.GL13294@shell.armlinux.org.uk> (raw)
In-Reply-To: <20190816154249.GA30291@darkstar.musicnaut.iki.fi>

On Fri, Aug 16, 2019 at 06:42:49PM +0300, Aaro Koskinen wrote:
> Hi,
> 
> On Wed, Aug 14, 2019 at 10:36:01AM +0200, Linus Walleij wrote:
> > On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote:
> > > As Arnd points out, Debian used to have support for various iop32x
> > > devices.  While Debian hasn't supported iop32x in a number of years,
> > > these devices are still usable and in use (RMK being a prime example).
> > 
> > I suppose it could be a good idea to add support for iop32x to
> > OpenWrt and/or OpenEmbedded, both of which support some
> > pretty constrained systems.
> 
> This platform is not really too constrained... E.g. on N2100 you have
> 512 MB RAM, SATA disks and gigabit ethernet. Not that different from
> mvebu that Debian currently (?) supports. Maybe with multiplatform they
> could support iop32x again.

Probably not.  The kernel has a dividing line between ARMv5 and ARMv6
where it's not possible to multiplatform across that boundary, so
you're already needing separate kernel images there.

Secondly, armhf distros won't be compatible with ARMv5, and to make
them compatible will make performance on armhf suffer - you have to
stop using barriers, exclusive load/store and a few other things.
You have to rely on the kuser page exported by the kernel (which is
now optional as it's deemed to be a security issue for ROP attacks)
for some things that such a userspace requires - such as NPTL support.

Effectively, ARMv5 is an entirely separate userspace distro from armhf.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

  reply index

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190809162956.488941-1-arnd@arndb.de>
2019-08-09 16:33 ` Arnd Bergmann
2019-08-09 16:33   ` [PATCH 2/7] dma: iop-adma: include prefetch.h Arnd Bergmann
2019-08-13  4:33     ` Vinod Koul
2019-08-14 15:29       ` Arnd Bergmann
2019-08-09 16:33   ` [PATCH 3/7] dma: iop-adma: use correct printk format strings Arnd Bergmann
2019-08-13  4:33     ` Vinod Koul
2019-08-09 16:33   ` [PATCH 4/7] dma: iop-adma: allow building without platform headers Arnd Bergmann
2019-08-09 16:33   ` [PATCH 5/7] ARM: xscale: fix multi-cpu compilation Arnd Bergmann
2019-08-23  7:44     ` Linus Walleij
2019-08-09 16:33   ` [PATCH 6/7] ARM: iop32x: make mach/uncompress.h independent of mach/hardware.h Arnd Bergmann
2019-08-09 16:33   ` [PATCH 7/7] ARM: iop32x: merge everything into mach-iop32x/ Arnd Bergmann
2019-08-09 16:57   ` [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support Wolfram Sang
2019-08-09 18:34   ` Dan Williams
2019-08-09 18:36     ` Russell King - ARM Linux admin
2019-08-09 19:43       ` Dan Williams
2019-08-12  9:44     ` Martin Michlmayr
2019-08-14  8:36       ` Linus Walleij
2019-08-14 10:48         ` Arnd Bergmann
2019-08-16 15:42         ` Aaro Koskinen
2019-08-16 15:58           ` Russell King - ARM Linux admin [this message]
2019-08-16 16:15             ` Aaro Koskinen

Reply instructions:

You may reply publically 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=20190816155833.GL13294@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=aaro.koskinen@iki.fi \
    --cc=arnd@arndb.de \
    --cc=bgolaszewski@baylibre.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists@peter-teichmann.de \
    --cc=soc@kernel.org \
    --cc=tbm@cyrius.com \
    --cc=vkoul@kernel.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

dmaengine Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dmaengine/0 dmaengine/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dmaengine dmaengine/ https://lore.kernel.org/dmaengine \
		dmaengine@vger.kernel.org dmaengine@archiver.kernel.org
	public-inbox-index dmaengine

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.dmaengine


AGPL code for this site: git clone https://public-inbox.org/ public-inbox