From: l.stach@pengutronix.de (Lucas Stach)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: dts: imx28: Adjust i2c interrupt bindings
Date: Thu, 23 May 2013 17:28:24 +0200 [thread overview]
Message-ID: <1369322904.4142.36.camel@weser.hi.pengutronix.de> (raw)
In-Reply-To: <201305231648.17356.marex@denx.de>
Am Donnerstag, den 23.05.2013, 16:48 +0200 schrieb Marek Vasut:
> Dear Juergen Beisert,
>
> > Hi Marek,
> >
> > Marek Vasut wrote:
> > > > > i2c slowness is a different issue.
> > > >
> > > > Same happens here for my i.M23 based platform. It seems the PIO mode
> > > > does not work, or at least not like it works on a i.MX28. Each short
> > > > transfer needs about one second (without an error message) but does
> > > > not send anything on the I2C lines.
> > > >
> > > > I need the following patches to make I2C master work within a 3.10-rc2
> > > > kernel:
> > > >
> > > > Subject: [PATCH] I2C/MXS: distinguish i.MX23 and i.MX28 based I2C
> > >
> > > I'm all for it, but then ... won't it be better if you actually fixed the
> > > PIO and mixed-mode on MX23 instead of implementing such hack?
> >
> > If the PIO mode or my patch is a hack depends on the point of view: Lucas
> > told me the PIO mode is *mentioned* but *not specified* in the
> > i.MX23/i.MX28 datasheets.
>
> The PIO works the same way DMA does -- set up bits and then pump data into the
> DATA register.
> > So, the PIO mode seems to depend on some undocumented status bits in the
> > i.MX28 I2C controller implementation.
>
> How would DMA work then if it used undocumented registers ? It's in the
> documentation, just read it or ask FSL ;-)
>
While the PIO mode might use the same controller mechanisms as the DMA
mode, PIO mode is _not_ a documented mode of operation for the i.MX23.
To quote the i.MX28 RM: "The I2C block on the i.MX28 supports a new PIO
mode or soft-DMA mode.", which implies the PIO mode to be a new mode of
operation not found on earlier i.MX SoCs.
The doc is slightly fuzzy here as the i.MX23 RM in contrary states:
"Short transmission (up to three bytes plus address) can be easily
triggered using only PIO operations, i.e., no DMA setup required." But
again it's not a documented mode of operation, i.MX23 doc only describes
the DMA mode.
So while we _might_ be able to get the PIO mode to work on the i.MX23
there is nothing in the doc stating that it's even meant to work. Even
while PIO and DMA mode use the same internal mechanisms, there's still
plenty of opportunities of fail in there. After all PIO mode relies on
reading a debug register in the course of normal operation.
Only more extensive experimentation could show if we are in fact able to
make it work, a first shot of using PIO mode on MX23 failed, so it might
as well be that Juergens quick fix is correct and we have to disable PIO
mode on MX23 altogether. That said please stop slapping the word "hack"
over this patch until proven otherwise.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2013-05-23 15:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-16 14:13 [PATCH 1/2] ARM: dts: imx: Remove custom dma-channel bindings Fabio Estevam
2013-05-16 14:13 ` [PATCH 2/2] ARM: dts: imx28: Adjust i2c interrupt bindings Fabio Estevam
2013-05-16 15:50 ` Fabio Estevam
2013-05-16 17:25 ` Fabio Estevam
2013-05-16 19:33 ` Alexandre Belloni
2013-05-17 0:10 ` Fabio Estevam
2013-05-22 10:19 ` Juergen Beisert
2013-05-22 11:05 ` Marek Vasut
2013-05-23 7:20 ` Juergen Beisert
2013-05-23 14:48 ` Marek Vasut
2013-05-23 15:28 ` Lucas Stach [this message]
2013-05-23 17:51 ` Alexandre Belloni
2013-05-24 8:08 ` Lucas Stach
2013-05-24 13:57 ` Marek Vasut
2013-05-24 1:00 ` Marek Vasut
2013-05-22 13:41 ` Fabio Estevam
2013-07-17 17:05 ` Marek Vasut
2013-05-17 2:25 ` [PATCH 1/2] ARM: dts: imx: Remove custom dma-channel bindings Shawn Guo
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=1369322904.4142.36.camel@weser.hi.pengutronix.de \
--to=l.stach@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).