From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Fabio Estevam
<fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH V4] MXS: Implement DMA support into mxs-i2c
Date: Sun, 16 Sep 2012 13:14:20 +0200 [thread overview]
Message-ID: <201209161314.21049.marex@denx.de> (raw)
In-Reply-To: <20120916111223.GD933-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Dear Wolfram Sang,
> > > Unsurprisingly, I also couldn't get the mode switching between DMA and
> > > PIOQUEUE to work :(
> >
> > I'd say more work should be invested into this.
>
> I ran out of ideas. Next thing I'd do is to ask FSL if this is possible
> at all. Yet, I'd like to have some solution for 3.7.
Why? You now have the module option solution.
> > Besides, what about rather > trying PIO + DMA instead of PIOQ + DMA?
>
> That could also be a solution.
>
> > > However, I did come up with an idea how to select DMA or PIOQUEUE per
> > > bus via devicetree. If we change the view from "I want PIOQUEUE" to "I
> > > don't want DMA", we could simply override the default DMA configuration
> > >
> > > in the devicetree with, e.g.:
> > > i2c0: i2c@80058000 {
> > >
> > > ...
> > > fsl,i2c-dma-channel = <>;
> > >
> > > };
> > >
> > > So, no DMA channel set up will fall back to PIOQUEUE. This is more
> > > generic than a custom binding, because if one doesn't want DMA, don't
> > > configure it. That should also work with other devices which can fall
> > > back to something. I think this is worth trying, another advantage is
> > > that it doesn't expose something new to the user. So, there is no
> > > legacy support needed in case there will be a better way of
> > > configuration.
> >
> > Ewww ... that's such an ad-hoc hack.
>
> Please give reasons.
It's abuse of proper configuration of hardware property.
> > Besides, someone might simply forget to add the binding, you'd need to
> > print a warning.
>
> ? It is "on" by default because of the entry in the dtsi. And the status
> of DMA will be printed.
>
> > > + dev_info(dev, "registered. DMA: %s\n", i2c->dma_mode ? "on" : "off");
> >
> > dev_debug() ?
>
> Yup.
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V4] MXS: Implement DMA support into mxs-i2c
Date: Sun, 16 Sep 2012 13:14:20 +0200 [thread overview]
Message-ID: <201209161314.21049.marex@denx.de> (raw)
In-Reply-To: <20120916111223.GD933@pengutronix.de>
Dear Wolfram Sang,
> > > Unsurprisingly, I also couldn't get the mode switching between DMA and
> > > PIOQUEUE to work :(
> >
> > I'd say more work should be invested into this.
>
> I ran out of ideas. Next thing I'd do is to ask FSL if this is possible
> at all. Yet, I'd like to have some solution for 3.7.
Why? You now have the module option solution.
> > Besides, what about rather > trying PIO + DMA instead of PIOQ + DMA?
>
> That could also be a solution.
>
> > > However, I did come up with an idea how to select DMA or PIOQUEUE per
> > > bus via devicetree. If we change the view from "I want PIOQUEUE" to "I
> > > don't want DMA", we could simply override the default DMA configuration
> > >
> > > in the devicetree with, e.g.:
> > > i2c0: i2c at 80058000 {
> > >
> > > ...
> > > fsl,i2c-dma-channel = <>;
> > >
> > > };
> > >
> > > So, no DMA channel set up will fall back to PIOQUEUE. This is more
> > > generic than a custom binding, because if one doesn't want DMA, don't
> > > configure it. That should also work with other devices which can fall
> > > back to something. I think this is worth trying, another advantage is
> > > that it doesn't expose something new to the user. So, there is no
> > > legacy support needed in case there will be a better way of
> > > configuration.
> >
> > Ewww ... that's such an ad-hoc hack.
>
> Please give reasons.
It's abuse of proper configuration of hardware property.
> > Besides, someone might simply forget to add the binding, you'd need to
> > print a warning.
>
> ? It is "on" by default because of the entry in the dtsi. And the status
> of DMA will be printed.
>
> > > + dev_info(dev, "registered. DMA: %s\n", i2c->dma_mode ? "on" : "off");
> >
> > dev_debug() ?
>
> Yup.
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-09-16 11:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-24 3:44 [PATCH V4] MXS: Implement DMA support into mxs-i2c Marek Vasut
2012-08-24 3:44 ` Marek Vasut
[not found] ` <1345779871-7677-1-git-send-email-marex-ynQEQJNshbs@public.gmane.org>
2012-08-27 18:54 ` Fabio Estevam
2012-08-27 18:54 ` Fabio Estevam
[not found] ` <CAOMZO5CSvP3nXNq4VLYALh+U9OZRnjtgXqTr7zsKdeHpUdJ4cQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-09-16 10:44 ` Wolfram Sang
2012-09-16 10:44 ` Wolfram Sang
[not found] ` <20120916104436.GC933-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-09-16 14:44 ` Fabio Estevam
2012-09-16 14:44 ` Fabio Estevam
2012-09-16 10:23 ` Wolfram Sang
2012-09-16 10:23 ` Wolfram Sang
[not found] ` <20120916102342.GA933-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-09-16 10:51 ` Marek Vasut
2012-09-16 10:51 ` Marek Vasut
[not found] ` <201209161251.41895.marex-ynQEQJNshbs@public.gmane.org>
2012-09-16 11:12 ` Wolfram Sang
2012-09-16 11:12 ` Wolfram Sang
[not found] ` <20120916111223.GD933-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-09-16 11:14 ` Marek Vasut [this message]
2012-09-16 11:14 ` Marek Vasut
2012-09-27 0:03 ` Marek Vasut
2012-09-27 0:03 ` Marek Vasut
2012-10-08 9:25 ` Wolfram Sang
2012-10-08 9:25 ` Wolfram Sang
[not found] ` <20121008092530.GA22051-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-10-08 13:15 ` Marek Vasut
2012-10-08 13:15 ` Marek Vasut
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=201209161314.21049.marex@denx.de \
--to=marex-ynqeqjnshbs@public.gmane.org \
--cc=fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.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 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.