From: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> To: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org> Cc: "Shawn Guo" <shawn.guo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Detlev Zundel" <dzu-ynQEQJNshbs@public.gmane.org>, "Dong Aisheng" <b29396-KZfg59tc24xl57MIdRCFDg@public.gmane.org>, "Fabio Estevam" <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>, "Linux ARM kernel" <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>, "Sascha Hauer" <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, "Stefano Babic" <sbabic-ynQEQJNshbs@public.gmane.org>, "Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, "Wolfgang Denk" <wd-ynQEQJNshbs@public.gmane.org> Subject: Re: [PATCH 2/2 V3] MXS: Implement DMA support into mxs-i2c Date: Sat, 14 Jul 2012 13:29:29 +0200 [thread overview] Message-ID: <20120714112929.GB29529@pengutronix.de> (raw) In-Reply-To: <201207131410.29469.marex-ynQEQJNshbs@public.gmane.org> [-- Attachment #1: Type: text/plain, Size: 3517 bytes --] Marek, > It'd be cool if someone complained earlier and the responses to new patches > would be faster. This series has been going on for more than two months and I agree it would be cool to response faster. Maintaining being mostly my priavte fun, I can't make guarantees, though. It just happened that I didn't have much time for Linux in the last weeks. Actually, I am quite happy that I managed to work through most of the backlog for the next merge-window at all (in my holidays!). That's from my side, I can't tell why other people didn't review; all being too busy is the most likely guess. > noone complained about this part until now. Instead I was made to document this > and now I have to do it in completely different way? Decide already ... When we decided to have the fallback mode as a configuration option, the driver was still considering platform_data. That would have been no problem... > > > For one reason, this is not a > > hardware property or board specific, so not a good device tree property. > > Actually, there're still people who might benefit of doing PIOq only, since they > do small (eg. one byte) transfers. And this is good to have configurable per > bus. ... but we are now on devicetree and things are different there, sadly. "use-pio" is exposing a driver specific detail which is neither describing the hardware nor it is OS agnostic. Other drivers from other OS might not even have the seperation, because they might only use PIO mode (not even PIOQUEUE). So, the binding is not acceptable AFAIK. We can add devicetree-discuss to the CC-list. > > Also, it is implicitly deprecated somehow since either we want DMA to > > fully work > > And the DMA doesn't fully work? It probably does. I was just stating the intention. > > or, even better, somewhen be able to automatically switch > > between PIOQUEUE and DMA depending on the i2c_msg size. > > That'd be cool. Some months ago, you promised to take a look. I tried it > recently again with not much luck. Yes, I wanted to. I couldn't (see above). I do imagine that it really might not be possible to switch modes at runtime. This is why I was trying to get the patch into the next release without the mode-switching. But for that to happen, there was the binding issue. I came up with the module parameter as the easiest way to fix it. I am open to other solutions. Simply dropping the binding might be another idea if we pay attention that there are no regressions, going from PIOQUEUE to DMA. I am also still interested to check the runtime switching, but it might take another month until I can really hack on it. > > Deprecated > > properties are also troublesome. Third, we don't really need this per > > instance, if somebody really has problems with DMA, it will apply to all > > i2c busses. Makes sense? > > No, it doesn't. See above about small transfers. Consider the easy situation > where you have sensor on one bus (so you do PIO because you transfer small data) > and you have EEPROM on other bus, where you use DMA because you transfer large > data. And the mixed mode isn't there yet. I fully understand what you want to configure. I did before. Yet, devicetree bindings are not platform_data and shouldn't be used like them. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: w.sang@pengutronix.de (Wolfram Sang) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 2/2 V3] MXS: Implement DMA support into mxs-i2c Date: Sat, 14 Jul 2012 13:29:29 +0200 [thread overview] Message-ID: <20120714112929.GB29529@pengutronix.de> (raw) In-Reply-To: <201207131410.29469.marex@denx.de> Marek, > It'd be cool if someone complained earlier and the responses to new patches > would be faster. This series has been going on for more than two months and I agree it would be cool to response faster. Maintaining being mostly my priavte fun, I can't make guarantees, though. It just happened that I didn't have much time for Linux in the last weeks. Actually, I am quite happy that I managed to work through most of the backlog for the next merge-window at all (in my holidays!). That's from my side, I can't tell why other people didn't review; all being too busy is the most likely guess. > noone complained about this part until now. Instead I was made to document this > and now I have to do it in completely different way? Decide already ... When we decided to have the fallback mode as a configuration option, the driver was still considering platform_data. That would have been no problem... > > > For one reason, this is not a > > hardware property or board specific, so not a good device tree property. > > Actually, there're still people who might benefit of doing PIOq only, since they > do small (eg. one byte) transfers. And this is good to have configurable per > bus. ... but we are now on devicetree and things are different there, sadly. "use-pio" is exposing a driver specific detail which is neither describing the hardware nor it is OS agnostic. Other drivers from other OS might not even have the seperation, because they might only use PIO mode (not even PIOQUEUE). So, the binding is not acceptable AFAIK. We can add devicetree-discuss to the CC-list. > > Also, it is implicitly deprecated somehow since either we want DMA to > > fully work > > And the DMA doesn't fully work? It probably does. I was just stating the intention. > > or, even better, somewhen be able to automatically switch > > between PIOQUEUE and DMA depending on the i2c_msg size. > > That'd be cool. Some months ago, you promised to take a look. I tried it > recently again with not much luck. Yes, I wanted to. I couldn't (see above). I do imagine that it really might not be possible to switch modes at runtime. This is why I was trying to get the patch into the next release without the mode-switching. But for that to happen, there was the binding issue. I came up with the module parameter as the easiest way to fix it. I am open to other solutions. Simply dropping the binding might be another idea if we pay attention that there are no regressions, going from PIOQUEUE to DMA. I am also still interested to check the runtime switching, but it might take another month until I can really hack on it. > > Deprecated > > properties are also troublesome. Third, we don't really need this per > > instance, if somebody really has problems with DMA, it will apply to all > > i2c busses. Makes sense? > > No, it doesn't. See above about small transfers. Consider the easy situation > where you have sensor on one bus (so you do PIO because you transfer small data) > and you have EEPROM on other bus, where you use DMA because you transfer large > data. And the mixed mode isn't there yet. I fully understand what you want to configure. I did before. Yet, devicetree bindings are not platform_data and shouldn't be used like them. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120714/bcd928c3/attachment.sig>
next prev parent reply other threads:[~2012-07-14 11:29 UTC|newest] Thread overview: 34+ 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 ` Marek Vasut [not found] ` <1341850974-11977-1-git-send-email-marex-ynQEQJNshbs@public.gmane.org> 2012-07-09 16:22 ` [PATCH 2/2 V3] MXS: Implement DMA support into mxs-i2c Marek Vasut 2012-07-09 16:22 ` Marek Vasut [not found] ` <1341850974-11977-2-git-send-email-marex-ynQEQJNshbs@public.gmane.org> 2012-07-13 8:22 ` Wolfram Sang 2012-07-13 8:22 ` Wolfram Sang [not found] ` <20120713082249.GF32184-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2012-07-13 12:10 ` Marek Vasut 2012-07-13 12:10 ` Marek Vasut [not found] ` <201207131410.29469.marex-ynQEQJNshbs@public.gmane.org> 2012-07-14 11:29 ` Wolfram Sang [this message] 2012-07-14 11:29 ` Wolfram Sang [not found] ` <20120714112929.GB29529-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2012-07-14 12:09 ` Marek Vasut 2012-07-14 12:09 ` Marek Vasut [not found] ` <201207141409.38554.marex-ynQEQJNshbs@public.gmane.org> 2012-07-16 10:21 ` Wolfram Sang 2012-07-16 10:21 ` Wolfram Sang [not found] ` <20120716102151.GC17435-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2012-07-16 13:06 ` Marek Vasut 2012-07-16 13:06 ` Marek Vasut [not found] ` <201207161506.08147.marex-ynQEQJNshbs@public.gmane.org> 2012-07-16 13:25 ` Wolfram Sang 2012-07-16 13:25 ` Wolfram Sang 2012-07-15 8:17 ` Shawn Guo 2012-07-15 8:17 ` Shawn Guo [not found] ` <20120715081715.GA2429-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org> 2012-07-21 12:44 ` Wolfram Sang 2012-07-21 12:44 ` Wolfram Sang [not found] ` <20120721124406.GA9946-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2012-07-21 14:11 ` Marek Vasut 2012-07-21 14:11 ` Marek Vasut [not found] ` <201207211611.58956.marex-ynQEQJNshbs@public.gmane.org> 2012-07-21 15:41 ` Wolfram Sang 2012-07-21 15:41 ` Wolfram Sang [not found] ` <20120721154153.GA25874-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> 2012-07-21 15:54 ` Marek Vasut 2012-07-21 15:54 ` Marek Vasut [not found] ` <201207211754.29372.marex-ynQEQJNshbs@public.gmane.org> 2012-07-22 8:33 ` Wolfram Sang 2012-07-22 8:33 ` Wolfram Sang 2012-07-28 8:02 ` Shawn Guo 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 2012-07-13 8:07 ` 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=20120714112929.GB29529@pengutronix.de \ --to=w.sang-bicnvbalz9megne8c9+irq@public.gmane.org \ --cc=b29396-KZfg59tc24xl57MIdRCFDg@public.gmane.org \ --cc=dzu-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=marex-ynQEQJNshbs@public.gmane.org \ --cc=s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \ --cc=sbabic-ynQEQJNshbs@public.gmane.org \ --cc=shawn.guo-KZfg59tc24xl57MIdRCFDg@public.gmane.org \ --cc=u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \ --cc=wd-ynQEQJNshbs@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: linkBe 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.