[PATCH] dma: add new DMA control commands
From: Huang Shijie shij...@gmail.com
[1] Why add these new DMA control commands?
In mx6q, the gpmi-nand driver is the only user of the APBH-DMA. The dma
clock
is enabled when we have successfully requested a DMA channel. So even when
the gpmi-nand driver does not work, the dma clock(apbh-dma) still runs
in high speed (198MHz). To save some power, it is better to disable the dma
clock when the dma device, such as gpmi-nand, is not working anymore.
When the dma device becomes work again, enable the dma clock again.
[2] add new DMA control commands: DMA_START/DMA_END
DMA_START: do some preprations to start the DMA engine, such as enable the
necessary clocks.
DMA_END: do some works to end the DMA engine, such as disable the
necessary clocks.
[3] This patch does not change any logic in i2c-mxs driver and mxs-pcm driver.
But for gpmi-nand driver, we will enable the the clock only when we select
the nand chip, and want to do some real jobs with the nand chip.
For mxs-mmc driver, disable the dma clock in the suspend; and enable the
dma clock in the resume.
Signed-off-by: Huang Shijie b32...@freescale.com
---
drivers/dma/mxs-dma.c | 17 +
drivers/i2c/busses/i2c-mxs.c | 10 +-
drivers/mmc/host/mxs-mmc.c | 19 ---
drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 10 ++
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 10 ++
include/linux/dmaengine.h |6 ++
sound/soc/mxs/mxs-pcm.c| 12
7 files changed, 76 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index 9f02e79..89286f4 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -384,6 +384,8 @@ static int mxs_dma_alloc_chan_resources(struct dma_chan
*chan)
/* the descriptor is ready */
async_tx_ack(mxs_chan-desc);
+ clk_disable_unprepare(mxs_dma-clk);
+
return 0;
err_clk:
@@ -399,6 +401,14 @@ static void mxs_dma_free_chan_resources(struct dma_chan
*chan)
{
struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan);
struct mxs_dma_engine *mxs_dma = mxs_chan-mxs_dma;
+ int ret;
+
+ ret = clk_prepare_enable(mxs_dma-clk);
+ if (ret) {
+ dev_err(mxs_dma-dma_device.dev,
+ failed in enabling the dma clock\n);
+ return;
+ }
mxs_dma_disable_chan(mxs_chan);
@@ -597,9 +607,13 @@ static int mxs_dma_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd,
unsigned long arg)
{
struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan);
+ struct mxs_dma_engine *mxs_dma = mxs_chan-mxs_dma;
int ret = 0;
switch (cmd) {
+ case DMA_START:
+ ret = clk_prepare_enable(mxs_dma-clk);
+ break;
case DMA_TERMINATE_ALL:
mxs_dma_reset_chan(mxs_chan);
mxs_dma_disable_chan(mxs_chan);
@@ -610,6 +624,9 @@ static int mxs_dma_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd,
case DMA_RESUME:
mxs_dma_resume_chan(mxs_chan);
break;
+ case DMA_END:
+ clk_disable_unprepare(mxs_dma-clk);
+ break;
default:
ret = -ENOSYS;
}
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index 1f58197..da1e881 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -643,6 +643,12 @@ static int __devinit mxs_i2c_probe(struct platform_device
*pdev)
dev_err(dev, Failed to request dma\n);
return -ENODEV;
}
+ err = dmaengine_device_control(i2c-dmach, DMA_START, 0);
+ if (err) {
+ dma_release_channel(i2c-dmach);
+ dev_err(dev, Failed to start dma\n);
+ return err;
+ }
}
platform_set_drvdata(pdev, i2c);
@@ -680,8 +686,10 @@ static int __devexit mxs_i2c_remove(struct platform_device
*pdev)
if (ret)
return -EBUSY;
- if (i2c-dmach)
+ if (i2c-dmach) {
+ dmaengine_device_control(i2c-dmach, DMA_END, 0);
dma_release_channel(i2c-dmach);
+ }
writel(MXS_I2C_CTRL0_SFTRST, i2c-regs + MXS_I2C_CTRL0_SET);
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 80d1e6d..aa91830 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -676,6 +676,9 @@ static int mxs_mmc_probe(struct platform_device *pdev)
%s: failed to request dma\n, __func__);
goto out_clk_put;
}
+ ret = dmaengine_device_control(ssp-dmach, DMA_START, 0);
+ if (ret)
+ goto out_free_dma;
/* set mmc core parameters
Re: [PATCH] dma: add new DMA control commands
On Thu, 2012-10-18 at 13:32 +0800, Huang Shijie wrote:
From: Huang Shijie shij...@gmail.com
[1] Why add these new DMA control commands?
In mx6q, the gpmi-nand driver is the only user of the APBH-DMA. The dma
clock
is enabled when we have successfully requested a DMA channel. So even when
the gpmi-nand driver does not work, the dma clock(apbh-dma) still runs
in high speed (198MHz). To save some power, it is better to disable the
dma
clock when the dma device, such as gpmi-nand, is not working anymore.
When the dma device becomes work again, enable the dma clock again.
[2] add new DMA control commands: DMA_START/DMA_END
DMA_START: do some preprations to start the DMA engine, such as enable the
necessary clocks.
DMA_END: do some works to end the DMA engine, such as disable the
necessary clocks.
[3] This patch does not change any logic in i2c-mxs driver and mxs-pcm driver.
But for gpmi-nand driver, we will enable the the clock only when we select
the nand chip, and want to do some real jobs with the nand chip.
For mxs-mmc driver, disable the dma clock in the suspend; and enable the
dma clock in the resume.
Why cant you do start (prepare clock etc) when you submit the descriptor
to dmaengine. Can be done in tx_submit callback.
Similarly remove the clock when dma transaction gets completed.
I don't think we need a new API for this, it needs to be handled by
driver on its own.
Signed-off-by: Huang Shijie b32...@freescale.com
---
drivers/dma/mxs-dma.c | 17 +
drivers/i2c/busses/i2c-mxs.c | 10 +-
drivers/mmc/host/mxs-mmc.c | 19 ---
drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 10 ++
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 10 ++
include/linux/dmaengine.h |6 ++
sound/soc/mxs/mxs-pcm.c| 12
7 files changed, 76 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index 9f02e79..89286f4 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -384,6 +384,8 @@ static int mxs_dma_alloc_chan_resources(struct dma_chan
*chan)
/* the descriptor is ready */
async_tx_ack(mxs_chan-desc);
+ clk_disable_unprepare(mxs_dma-clk);
+
return 0;
err_clk:
@@ -399,6 +401,14 @@ static void mxs_dma_free_chan_resources(struct dma_chan
*chan)
{
struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan);
struct mxs_dma_engine *mxs_dma = mxs_chan-mxs_dma;
+ int ret;
+
+ ret = clk_prepare_enable(mxs_dma-clk);
+ if (ret) {
+ dev_err(mxs_dma-dma_device.dev,
+ failed in enabling the dma clock\n);
+ return;
+ }
mxs_dma_disable_chan(mxs_chan);
@@ -597,9 +607,13 @@ static int mxs_dma_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd,
unsigned long arg)
{
struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan);
+ struct mxs_dma_engine *mxs_dma = mxs_chan-mxs_dma;
int ret = 0;
switch (cmd) {
+ case DMA_START:
+ ret = clk_prepare_enable(mxs_dma-clk);
+ break;
case DMA_TERMINATE_ALL:
mxs_dma_reset_chan(mxs_chan);
mxs_dma_disable_chan(mxs_chan);
@@ -610,6 +624,9 @@ static int mxs_dma_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd,
case DMA_RESUME:
mxs_dma_resume_chan(mxs_chan);
break;
+ case DMA_END:
+ clk_disable_unprepare(mxs_dma-clk);
+ break;
default:
ret = -ENOSYS;
}
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index 1f58197..da1e881 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -643,6 +643,12 @@ static int __devinit mxs_i2c_probe(struct
platform_device *pdev)
dev_err(dev, Failed to request dma\n);
return -ENODEV;
}
+ err = dmaengine_device_control(i2c-dmach, DMA_START, 0);
+ if (err) {
+ dma_release_channel(i2c-dmach);
+ dev_err(dev, Failed to start dma\n);
+ return err;
+ }
}
platform_set_drvdata(pdev, i2c);
@@ -680,8 +686,10 @@ static int __devexit mxs_i2c_remove(struct
platform_device *pdev)
if (ret)
return -EBUSY;
- if (i2c-dmach)
+ if (i2c-dmach) {
+ dmaengine_device_control(i2c-dmach, DMA_END, 0);
dma_release_channel(i2c-dmach);
+ }
writel(MXS_I2C_CTRL0_SFTRST, i2c-regs + MXS_I2C_CTRL0_SET);
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 80d1e6d..aa91830 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 14:18, Vinod Koul 写道: Why cant you do start (prepare clock etc) when you submit the descriptor to dmaengine. Can be done in tx_submit callback. Similarly remove the clock when dma transaction gets completed. I ever thought this method too. But it will become low efficient in the following case: Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ read operation. The gpmi-nand will submit the descriptor to dmaengine per page. So with your method, the system will repeat the enable/disable dma clock 1024 time. At every enable/disable dma clock, the system has to enable the clock chain and it's parents ... But with this patch, we only need to enable/disable dma clock one time, just at we select the nand chip. thanks Huang Shijie -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
ke, 2012-10-17 kello 19:02 +0300, Felipe Balbi kirjoitti: Hi, On Thu, Oct 11, 2012 at 02:08:25PM -0700, Kevin Hilman wrote: Hi Kalle, Kalle Jokiniemi kalle.jokini...@jollamobile.com writes: The resume_noirq enables interrupts one-by-one starting from first one. Now if the wake up event for suspend came from i2c device, the i2c bus irq gets enabled before the threaded i2c device irq, causing a flood of i2c bus interrupts as the threaded irq that should clear the event is not enabled yet. Fixed the issue by adding suspend_noirq and resume_early functions that keep i2c bus interrupts disabled until resume_noirq has run completely. Issue was detected doing a wake up from autosleep with twl4030 power key on N9. Patch tested on N9. Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com This version looks good, thanks for the extra comments. Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Kevin Hilman khil...@ti.com Wolfram, This should also probably be Cc'd to stable since it affects earlier kernels as well. Thanks, just to make sure we're not fixing the wrong problem... does [1] help in any way ? Yes, I was fixing the wrong problem, this patch is obsolete. But the problem was in the TWL interrupt handling (PIH was run before SIH), not in i2c. See my other patch twl4030: Fix chained irq handling on resume from suspend [1] http://marc.info/?l=linux-omapm=135048839915719w=2 Could be related, though if I understood correctly, that runtime pm stuff gets run at noirq phase, so it probably does not help. - Kalle -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
Dear Huang Shijie, Why such massive CC ? 于 2012年10月18日 14:18, Vinod Koul 写道: Why cant you do start (prepare clock etc) when you submit the descriptor to dmaengine. Can be done in tx_submit callback. Similarly remove the clock when dma transaction gets completed. I ever thought this method too. But it will become low efficient in the following case: Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ read operation. The gpmi-nand will submit the descriptor to dmaengine per page. It will? Then GPMI NAND is flat our broken ... again. So with your method, the system will repeat the enable/disable dma clock 1024 time. Yes, it is the driver that's wrong. At every enable/disable dma clock, the system has to enable the clock chain and it's parents ... But with this patch, we only need to enable/disable dma clock one time, just at we select the nand chip. You are fixing a driver problem at a framework level, wrong. So, check how the MXS SPI driver handles descriptor chaining. Indeed, the Sigmatel screwed the DMA stuff good. But if you analyze the SPI driver, you'll notice a few important points that might come handy when you fix the GPMI NAND driver properly. The direction to take here is: 1) Implement DMA chaining into the GPMI NAND driver 2) You might need to do one PIO transfer to reconfigure the IP registers between each segment of the DMA chain (just as MXS SPI does it) 3) You might run out of DMA descriptors when doing too long chains -- so you might need to fix that part of the mxs DMA driver. thanks Huang Shijie Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
Hi, On Thu, Oct 18, 2012 at 09:51:13AM +0300, Kalle Jokiniemi wrote: ke, 2012-10-17 kello 19:02 +0300, Felipe Balbi kirjoitti: Hi, On Thu, Oct 11, 2012 at 02:08:25PM -0700, Kevin Hilman wrote: Hi Kalle, Kalle Jokiniemi kalle.jokini...@jollamobile.com writes: The resume_noirq enables interrupts one-by-one starting from first one. Now if the wake up event for suspend came from i2c device, the i2c bus irq gets enabled before the threaded i2c device irq, causing a flood of i2c bus interrupts as the threaded irq that should clear the event is not enabled yet. Fixed the issue by adding suspend_noirq and resume_early functions that keep i2c bus interrupts disabled until resume_noirq has run completely. Issue was detected doing a wake up from autosleep with twl4030 power key on N9. Patch tested on N9. Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com This version looks good, thanks for the extra comments. Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Kevin Hilman khil...@ti.com Wolfram, This should also probably be Cc'd to stable since it affects earlier kernels as well. Thanks, just to make sure we're not fixing the wrong problem... does [1] help in any way ? Yes, I was fixing the wrong problem, this patch is obsolete. But the problem was in the TWL interrupt handling (PIH was run before SIH), not in i2c. See my other patch twl4030: Fix chained irq handling on resume from suspend [1] http://marc.info/?l=linux-omapm=135048839915719w=2 Could be related, though if I understood correctly, that runtime pm stuff gets run at noirq phase, so it probably does not help. well, it will be called multiple times actually :-) Since i2c is forcefully suspend in noirq time, it suspends before e.g. rtc, twl*-gpio, etc, which means that (at least for) rtc will still do i2c transfers on its suspend callback which will runtime resume the i2c controller and later suspend it again :-) You might be right, however, that it won't help in your case. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 15:14, Marek Vasut 写道: Dear Huang Shijie, Why such massive CC ? 于 2012年10月18日 14:18, Vinod Koul 写道: Why cant you do start (prepare clock etc) when you submit the descriptor to dmaengine. Can be done in tx_submit callback. Similarly remove the clock when dma transaction gets completed. I ever thought this method too. But it will become low efficient in the following case: Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ read operation. The gpmi-nand will submit the descriptor to dmaengine per page. It will? Then GPMI NAND is flat our broken ... again. yes. Please read the NAND chip spec about the comand READ PAGE(00h-30h) and the code nand_do_read_ops(). The nand chip limits us only read one page out one time. So the driver will submit the descriptor to dmaengine per page. So with your method, the system will repeat the enable/disable dma clock 1024 time. Yes, it is the driver that's wrong. not the driver. At every enable/disable dma clock, the system has to enable the clock chain and it's parents ... But with this patch, we only need to enable/disable dma clock one time, just at we select the nand chip. You are fixing a driver problem at a framework level, wrong. So, check how the MXS SPI driver handles descriptor chaining. Indeed, the Sigmatel screwed the DMA stuff good. But if you analyze the SPI driver, you'll notice a few important points that might come handy when you fix the GPMI NAND driver properly. The direction to take here is: 1) Implement DMA chaining into the GPMI NAND driver How can i implement the DMA chain if the nand chip READ-PAGE command gives us the one page limit? thanks Huang Shijie 2) You might need to do one PIO transfer to reconfigure the IP registers between each segment of the DMA chain (just as MXS SPI does it) 3) You might run out of DMA descriptors when doing too long chains -- so you might need to fix that part of the mxs DMA driver. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
Dear Huang Shijie, 于 2012年10月18日 15:14, Marek Vasut 写道: Dear Huang Shijie, Why such massive CC ? 于 2012年10月18日 14:18, Vinod Koul 写道: Why cant you do start (prepare clock etc) when you submit the descriptor to dmaengine. Can be done in tx_submit callback. Similarly remove the clock when dma transaction gets completed. I ever thought this method too. But it will become low efficient in the following case: Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ read operation. The gpmi-nand will submit the descriptor to dmaengine per page. It will? Then GPMI NAND is flat our broken ... again. yes. Please read the NAND chip spec about the comand READ PAGE(00h-30h) and the code nand_do_read_ops(). The nand chip limits us only read one page out one time. So the driver will submit the descriptor to dmaengine per page. So we can't stream data from the chip? About time to adjust the MTD framework to allow that. Maybe implement a command queue? So with your method, the system will repeat the enable/disable dma clock 1024 time. Yes, it is the driver that's wrong. not the driver. At every enable/disable dma clock, the system has to enable the clock chain and it's parents ... But with this patch, we only need to enable/disable dma clock one time, just at we select the nand chip. You are fixing a driver problem at a framework level, wrong. So, check how the MXS SPI driver handles descriptor chaining. Indeed, the Sigmatel screwed the DMA stuff good. But if you analyze the SPI driver, you'll notice a few important points that might come handy when you fix the GPMI NAND driver properly. The direction to take here is: 1) Implement DMA chaining into the GPMI NAND driver How can i implement the DMA chain if the nand chip READ-PAGE command gives us the one page limit? This smells like a time to extend the MTD api ? thanks Huang Shijie 2) You might need to do one PIO transfer to reconfigure the IP registers between each segment of the DMA chain (just as MXS SPI does it) 3) You might run out of DMA descriptors when doing too long chains -- so you might need to fix that part of the mxs DMA driver. Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 16:16, Marek Vasut 写道: So we can't stream data from the chip? About time to adjust the MTD framework to allow that. Maybe implement a command queue? to Artem David: is this possible to stream the data out with a command queue? thanks Huang Shijie -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 16:16, Marek Vasut 写道: So we can't stream data from the chip? About time to adjust the MTD framework to allow that. Maybe implement a command queue? IMHO, it's not possible. Because the READ-PAGE(00h-30h) command needs to check the busy status which means we have to stop in the middle, so we can not chain the all the read-pages DMA commands. thanks Huang Shijie -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
Dear Huang Shijie, 于 2012年10月18日 16:16, Marek Vasut 写道: So we can't stream data from the chip? About time to adjust the MTD framework to allow that. Maybe implement a command queue? IMHO, it's not possible. Because the READ-PAGE(00h-30h) command needs to check the busy status which means we have to stop in the middle, so we can not chain the all the read-pages DMA commands. Can the DMA not branch? thanks Huang Shijie Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
On Thu, Oct 18, 2012 at 02:45:41PM +0800, Huang Shijie wrote: 于 2012年10月18日 14:18, Vinod Koul 写道: Why cant you do start (prepare clock etc) when you submit the descriptor to dmaengine. Can be done in tx_submit callback. Similarly remove the clock when dma transaction gets completed. I ever thought this method too. But it will become low efficient in the following case: Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ read operation. The gpmi-nand will submit the descriptor to dmaengine per page. So with your method, the system will repeat the enable/disable dma clock 1024 time. At every enable/disable dma clock, the system has to enable the clock chain and it's parents ... And what if you stop using clk_prepare_enable(), and prepare the clock when the channel is requested and only use clk_enable() in the tx_submit method? -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c-hid: introduce HID over i2c specification implementation
Hi Benjamin,
Some suggestions to make the error messages more human, and a little
question on the return value of i2c_hid_fetch_hid_descriptor. Please see below:
Benjamin Tissoires benjamin.tissoi...@gmail.com writes:
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
new file mode 100644
index 000..8b6c31a
--- /dev/null
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -0,0 +1,990 @@
+/*
+ * HID over I2C protocol implementation
+ *
+ * Copyright (c) 2012 Benjamin Tissoires benjamin.tissoi...@gmail.com
+ * Copyright (c) 2012 Ecole Nationale de l'Aviation Civile, France
+ *
+ * This code is partly based on USB HID support for Linux:
+ *
+ * Copyright (c) 1999 Andreas Gal
+ * Copyright (c) 2000-2005 Vojtech Pavlik vojt...@suse.cz
+ * Copyright (c) 2005 Michael Haboustak mi...@cinci.rr.com for Concept2,
Inc
+ * Copyright (c) 2007-2008 Oliver Neukum
+ * Copyright (c) 2006-2010 Jiri Kosina
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include linux/module.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/input.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/pm.h
+#include linux/device.h
+#include linux/wait.h
+#include linux/err.h
+#include linux/string.h
+#include linux/list.h
+#include linux/jiffies.h
+#include linux/kernel.h
+#include linux/bug.h
+#include linux/hid.h
+
+#include linux/i2c/i2c-hid.h
+
+/* flags */
+#define I2C_HID_STARTED (1 0)
+#define I2C_HID_RESET_PENDING(1 1)
+#define I2C_HID_READ_PENDING (1 2)
+
+#define I2C_HID_PWR_ON 0x00
+#define I2C_HID_PWR_SLEEP0x01
+
+/* debug option */
+static bool debug = false;
+module_param(debug, bool, 0444);
+MODULE_PARM_DESC(debug, print a lot of debug information);
+
+#define i2c_hid_dbg(ihid, fmt, arg...) \
+ if (debug) \
+ dev_printk(KERN_DEBUG, (ihid)-client-dev, fmt, ##arg)
+
+struct i2c_hid_desc {
+ __le16 wHIDDescLength;
+ __le16 bcdVersion;
+ __le16 wReportDescLength;
+ __le16 wReportDescRegister;
+ __le16 wInputRegister;
+ __le16 wMaxInputLength;
+ __le16 wOutputRegister;
+ __le16 wMaxOutputLength;
+ __le16 wCommandRegister;
+ __le16 wDataRegister;
+ __le16 wVendorID;
+ __le16 wProductID;
+ __le16 wVersionID;
+} __packed;
+
+struct i2c_hid_cmd {
+ unsigned int registerIndex;
+ __u8 opcode;
+ unsigned int length;
+ bool wait;
+};
+
+union command {
+ u8 data[0];
+ struct cmd {
+ __le16 reg;
+ __u8 reportTypeID;
+ __u8 opcode;
+ } __packed c;
+};
+
+#define I2C_HID_CMD(opcode_) \
+ .opcode = opcode_, .length = 4, \
+ .registerIndex = offsetof(struct i2c_hid_desc, wCommandRegister)
+
+/* fetch HID descriptor */
+static const struct i2c_hid_cmd hid_descr_cmd = { .length = 2 };
+/* fetch report descriptors */
+static const struct i2c_hid_cmd hid_report_descr_cmd = {
+ .registerIndex = offsetof(struct i2c_hid_desc,
+ wReportDescRegister),
+ .opcode = 0x00,
+ .length = 2 };
+/* commands */
+static const struct i2c_hid_cmd hid_reset_cmd = {
I2C_HID_CMD(0x01),
+ .wait = true };
+static const struct i2c_hid_cmd hid_get_report_cmd = { I2C_HID_CMD(0x02) };
+static const struct i2c_hid_cmd hid_set_report_cmd = { I2C_HID_CMD(0x03) };
+static const struct i2c_hid_cmd hid_get_idle_cmd = { I2C_HID_CMD(0x04) };
+static const struct i2c_hid_cmd hid_set_idle_cmd = { I2C_HID_CMD(0x05) };
+static const struct i2c_hid_cmd hid_get_protocol_cmd = {
I2C_HID_CMD(0x06) };
+static const struct i2c_hid_cmd hid_set_protocol_cmd = {
I2C_HID_CMD(0x07) };
+static const struct i2c_hid_cmd hid_set_power_cmd = { I2C_HID_CMD(0x08) };
+/* read/write data register */
+static const struct i2c_hid_cmd hid_data_cmd = {
+ .registerIndex = offsetof(struct i2c_hid_desc, wDataRegister),
+ .opcode = 0x00,
+ .length = 2 };
+/* write output reports */
+static const struct i2c_hid_cmd hid_out_cmd = {
+ .registerIndex = offsetof(struct i2c_hid_desc,
+ wOutputRegister),
+ .opcode = 0x00,
+ .length = 2 };
+
+/* The main device structure */
+struct i2c_hid {
+ struct i2c_client *client;/* i2c client */
+ struct hid_device *hid; /* pointer to corresponding HID dev */
+ union {
+ __u8 hdesc_buffer[sizeof(struct i2c_hid_desc)];
+ struct i2c_hid_desc hdesc; /* the HID Descriptor */
+ };
+ __le16 wHIDDescRegister; /* location of the i2c
+
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 16:52, Russell King - ARM Linux 写道: On Thu, Oct 18, 2012 at 02:45:41PM +0800, Huang Shijie wrote: 于 2012年10月18日 14:18, Vinod Koul 写道: Why cant you do start (prepare clock etc) when you submit the descriptor to dmaengine. Can be done in tx_submit callback. Similarly remove the clock when dma transaction gets completed. I ever thought this method too. But it will become low efficient in the following case: Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ read operation. The gpmi-nand will submit the descriptor to dmaengine per page. So with your method, the system will repeat the enable/disable dma clock 1024 time. At every enable/disable dma clock, the system has to enable the clock chain and it's parents ... And what if you stop using clk_prepare_enable(), and prepare the clock when the channel is requested and only use clk_enable() in the tx_submit yes. it's a little better. There is nearly no difference between the clk_prepare_enable() and clk_enable() in actually. the clk_gate2_ops does not have any @-prepare. thanks Huang Shijie method? -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
于 2012年10月18日 16:49, Marek Vasut 写道: Dear Huang Shijie, 于 2012年10月18日 16:16, Marek Vasut 写道: So we can't stream data from the chip? About time to adjust the MTD framework to allow that. Maybe implement a command queue? IMHO, it's not possible. Because the READ-PAGE(00h-30h) command needs to check the busy status which means we have to stop in the middle, so we can not chain the all the read-pages DMA commands. Can the DMA not branch? it's too complicated to the MTD layer, as well as the gpmi driver. Best Regards Huang Shijie -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c-hid: introduce HID over i2c specification implementation
Benjamin Tissoires benjamin.tissoi...@gmail.com writes: Hi JJ, On Thu, Oct 18, 2012 at 11:07 AM, Jian-Jhong Ding jj_d...@emc.com.tw wrote: Hi Benjamin, Some suggestions to make the error messages more human, and a little question on the return value of i2c_hid_fetch_hid_descriptor. Please see below: I fully agree with the more human error messages. However, for i2c_hid_fetch_hid_descriptor return values, I'm affraid I can't use -EINVAL. Jean Delvare (one of the i2c maintainers) told in his review of the v1: These should all be -ENODEV in this function [i2c_hid_fetch_hid_descriptor]: the device isn't what you expected. EINVAL is for invalid argument. I must have missed that mail. Thank you for pointing this out. -JJ So ENODEV is the right return value. Anyway, thanks for the review. Cheers, Benjamin -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: cfa10049: Add the i2c muxer buses to the CFA-10049
This will allow to add the 3 Nuvoton NAU7802 ADCs and the NXP PCA9555
GPIO expander eventually.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
arch/arm/boot/dts/imx28-cfa10049.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts
b/arch/arm/boot/dts/imx28-cfa10049.dts
index 97ee098..2cda823 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -76,6 +76,30 @@
status = okay;
};
+ i2cmux {
+ compatible = i2c-mux-gpio;
+ #address-cells = 1;
+ #size-cells = 0;
+ mux-gpios = gpio1 22 0 gpio1 23 0;
+ i2c-parent = i2c1;
+
+ i2c@0 {
+ reg = 0;
+ };
+
+ i2c@1 {
+ reg = 1;
+ };
+
+ i2c@2 {
+ reg = 2;
+ };
+
+ i2c@3 {
+ reg = 3;
+ };
+ };
+
usbphy1: usbphy@8007e000 {
status = okay;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
On Thu, Oct 18, 2012 at 6:51 AM, Marek Vasut ma...@denx.de wrote: Dear Huang Shijie, 于 2012年10月18日 16:49, Marek Vasut 写道: Dear Huang Shijie, 于 2012年10月18日 16:16, Marek Vasut 写道: So we can't stream data from the chip? About time to adjust the MTD framework to allow that. Maybe implement a command queue? IMHO, it's not possible. Because the READ-PAGE(00h-30h) command needs to check the busy status which means we have to stop in the middle, so we can not chain the all the read-pages DMA commands. Can the DMA not branch? it's too complicated to the MTD layer, as well as the gpmi driver. Can you please elaborate ? could you read the nand spec about how to read a page out with the READ-PAGE(00-30) command, and tell me how to make the DMA branch? I really have no idea about how to make the DMA branch. thanks Huang Shijie . Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: add new DMA control commands
On Thu, Oct 18, 2012 at 5:29 AM, Jassi Brar jaswinder.si...@linaro.org wrote: On 18 October 2012 12:15, Huang Shijie b32...@freescale.com wrote: 于 2012年10月18日 14:18, Vinod Koul 写道: Why cant you do start (prepare clock etc) when you submit the descriptor to dmaengine. Can be done in tx_submit callback. Similarly remove the clock when dma transaction gets completed. I ever thought this method too. But it will become low efficient in the following case: Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ read operation. The gpmi-nand will submit the descriptor to dmaengine per page. So with your method, the system will repeat the enable/disable dma clock 1024 time. At every enable/disable dma clock, the system has to enable the clock chain and it's parents ... But with this patch, we only need to enable/disable dma clock one time, just at we select the nand chip. If the clock is the dmac's property (not channels'), the toggling seems too aggressive. You could try using runtime_suspend/resume for clock disabling/enabling. How about employing autosuspend with a few ms delay? Yes, employing the autosuspend is workable method too.o But it's a little more complicated then this patch. You have to create a thread or workqueue to do the job. What's more, I think other DMA engine may also meets the same issue as the mxs-dma, such as the imx-sdma. It's somehow a common issue to disable the clocks when no one use the DMA engine. Do you also suggest employing the autosuspend? Why not use a simple way to handle this issue? When the dma device want to use a DMA engine, it just needs to issue a DMA_START command. thanks Huang Shijie Huang Shijie -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver
On 10/18/2012 08:13 AM, Maxime Ripard wrote: Allow the i2c-mux-gpio to be used by a device tree enabled device. The bindings are inspired by the one found in the i2c-mux-pinctrl driver. +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt +Optional properties: +- idle-state: value to set to the muxer when idle. When no value is + given, it defaults to the first value in the array. That's inconsistent with the following text that appears later (and describes what the driver actually does): +If an idle state is defined, using the idle-state (optional) property, +whenever an access is not being made to a device on a child bus, the +idle value will be programmed into the GPIOs. + +If an idle state is not defined, the most recently used value will be +left programmed into hardware whenever no access is being made of a +device on a child bus. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
