linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2 V3] MXS: Implement DMA support into mxs-i2c
Date: Sat, 21 Jul 2012 16:11:58 +0200	[thread overview]
Message-ID: <201207211611.58956.marex@denx.de> (raw)
In-Reply-To: <20120721124406.GA9946@pengutronix.de>

Dear Wolfram Sang,

> On Sun, Jul 15, 2012 at 04:17:16PM +0800, Shawn Guo wrote:
> > On Fri, Jul 13, 2012 at 10:22:49AM +0200, Wolfram Sang wrote:
> > > > +	/*
> > > > +	 * TODO: This is a temporary solution and should be changed
> > > > +	 * to use generic DMA binding later when the helpers get in.
> > > > +	 */
> > > 
> > > @Shawn: Any idea when this is going to happen? And why do we need this?
> > 
> > See thread [1] for current statues.  I'm not sure when it's going to
> > happen though.
> 
> Phew, [1] is a bit too much too read. I will just assume there are still
> issues.
> 
> > > AFAICT it will be always channel 6/7 on mx28?
> > 
> > Yes, but it might be a different channel on mx23.  Just like we define
> > IO region and interrupt number in device tree, dma channel is just
> > another resource of hardware block that we choose to define in device
> > tree.
> 
> What makes me wonder now that I come to think of it (not necessarily a
> question for Shawn but to all):
> 
> If I have an I2C slave with an interrupt line tied to something, GPIO or
> external IRQ from the SoC, it makes perfect sense to define that in the
> devicetree.
> 
> Yet, if I know the compatible property for the mxs I2C driver, and also
> know the CPU type (be it MX23 or MX28), I can deduce from that a lot of
> information, including DMA channel. That is fix. Why encode it?

You know the compatible and the "fallback compatible". From the later one, you 
can deduce nothing if that happens to kick in.

btw. the PIO discussion on DT discuss is completely ignored. How shall we 
proceed, this driver is stalled for too long.

> Regards,
> 
>    Wolfram

Best regards,
Marek Vasut

  reply	other threads:[~2012-07-21 14:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-09 16:22 [PATCH 1/2 V3] MXS: Set I2C timing registers for mxs-i2c Marek Vasut
2012-07-09 16:22 ` [PATCH 2/2 V3] MXS: Implement DMA support into mxs-i2c Marek Vasut
2012-07-13  8:22   ` Wolfram Sang
2012-07-13 12:10     ` Marek Vasut
2012-07-14 11:29       ` Wolfram Sang
2012-07-14 12:09         ` Marek Vasut
2012-07-16 10:21           ` Wolfram Sang
2012-07-16 13:06             ` Marek Vasut
2012-07-16 13:25               ` Wolfram Sang
2012-07-15  8:17     ` Shawn Guo
2012-07-21 12:44       ` Wolfram Sang
2012-07-21 14:11         ` Marek Vasut [this message]
2012-07-21 15:41           ` Wolfram Sang
2012-07-21 15:54             ` Marek Vasut
2012-07-22  8:33               ` Wolfram Sang
2012-07-28  8:02         ` Shawn Guo
2012-07-13  8:07 ` [PATCH 1/2 V3] MXS: Set I2C timing registers for mxs-i2c Wolfram Sang

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=201207211611.58956.marex@denx.de \
    --to=marex@denx.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).