linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] dma: imx-sdma: Add ROM script addresses to driver
Date: Tue, 20 Aug 2013 09:00:39 +0200	[thread overview]
Message-ID: <20130820070039.GH31036@pengutronix.de> (raw)
In-Reply-To: <CAHCPf3t1_5zhSOrfVFHgeVPa25sT+ewv1=OZA8X4_YZXb9cSeA@mail.gmail.com>

On Mon, Aug 19, 2013 at 05:23:40PM -0500, Matt Sealey wrote:
> Please could you describe how the compatible property allows matching
> and covers both the ROM version *and* the distributed firmware file
> that is also referenced in the device tree for each sdma node for each
> SoC supported?

As said, we have a problem here since currently the dts references a
single firmware file in a compatible entry which covers two SoC
revisions. Both SoC revisions need a different firmware file.

> As far as I recall, the offsets for the (potentially
> buggy) on-chip version and the one in the BSP (and hopefully in
> upstream kernels at some soon-approaching version) are not the same
> for a good swath of these chips.

The patch only adds the ROM code addresses which don't change. If a ROM
script turns out to be buggy, just remove the corresponding pointer from
the driver. Even if you don't remove it, a RAM firmware file is always
able to overwrite already existing pointers.

> 
> How would the driver hope to match this up without causing some DMA
> explosions and/or invalid device trees if the BSP firmware is
> described, the BSP firmware file is not found, and the driver is left
> with the ROM version?

The driver only contains the ROM script addresses which don't change. As
said, if one turns out to be buggy, remove the correspong pointer. What
kind of DMA explosions do you envision?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2013-08-20  7:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-19 12:16 [PATCH] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer
2013-08-19 12:16 ` [PATCH 1/3] dma: imx-sdma: Use struct for driver data Sascha Hauer
2013-08-19 12:16 ` [PATCH 2/3] dma: imx-sdma: Add ROM script addresses to driver Sascha Hauer
2013-08-19 14:41   ` Shawn Guo
2013-08-19 17:39     ` Sascha Hauer
2013-08-20  2:35       ` Shawn Guo
2013-08-20  6:42         ` Sascha Hauer
2013-08-19 12:16 ` [PATCH 3/3] ARM: i.MX: remove sdma script address arrays from platform data Sascha Hauer
2013-08-19 22:23 ` [PATCH] dma: imx-sdma: Add ROM script addresses to driver Matt Sealey
2013-08-20  7:00   ` Sascha Hauer [this message]
2013-08-20 13:53     ` Matt Sealey
2013-08-20 15:02       ` Sascha Hauer
2013-08-29 17:23         ` Matt Sealey
2013-08-31  8:56           ` Sascha Hauer

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=20130820070039.GH31036@pengutronix.de \
    --to=s.hauer@pengutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).