[patch] usb: phy: signedness bug in suspend/resume
ret should be signed here for the error handling to work.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 15ab3d6..d36c282 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -120,7 +120,7 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
static int omap_usb2_suspend(struct usb_phy *x, int suspend)
{
- u32 ret;
+ int ret;
struct omap_usb *phy = phy_to_omapusb(x);
if (suspend !phy-is_suspended) {
@@ -223,7 +223,7 @@ static int omap_usb2_runtime_suspend(struct device *dev)
static int omap_usb2_runtime_resume(struct device *dev)
{
- u32 ret = 0;
+ int ret;
struct platform_device *pdev = to_platform_device(dev);
struct omap_usb *phy = platform_get_drvdata(pdev);
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 04/15] dmaengine: Pass no_wakeup parameter via device_prep_dma_cyclic() callback
On 09/14/2012 06:24 AM, Vinod Koul wrote: On Thu, 2012-09-13 at 16:37 +0300, Peter Ujfalusi wrote: Change the parameter list of device_prep_dma_cyclic() so the DMA drivers can receive the no_wakeup request coming from client drivers. This feature can be used during audio operation to disable all audio related interrupts. We already have a flag to indicate this, see * @DMA_PREP_INTERRUPT - trigger an interrupt (callback) upon completion of * this transaction I have also noticed this flag. It is not really a direct match for our case since the notion of completion of this transfer is not applicable for cyclic mode, but it is close enough. Unfortunately, the addition of cyclic API missed having this flag. So right way would be to add flag argument in the API. I have not looked at the non cyclic APIs, but I think I can modify the dmaengine_prep_dma_cyclic() to pass the flags instead of the 'bool no_wakeup'. If the DMA_PREP_INTERRUPT is not set dma drivers can interpret it in a way that they will disable all interrupts during cyclic mode. None of the dma drivers in cyclic mode cares about the flags AFAIK or they can just ignore this parameter for now (as they did with my no_wakeup parameter). Will resend the series soon with this change. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
Hi,
On 09/13/2012 06:27 PM, Lars-Peter Clausen wrote:
On 09/13/2012 03:37 PM, Peter Ujfalusi wrote:
The dmaengine_prep_dma_cyclic() function primarily used by audio for cyclic
transfer required by ALSA.
With this new parameter it is going to be possible to enable the
SNDRV_PCM_INFO_NO_PERIOD_WAKEUP mode on platforms where it is possible.
This patch only changes the public API first. Followup patch will change
the device_prep_dma_cyclic() callback parameters to pass this information
towards the dma drivers.
Hi,
Hm... Do you think it would work as well if we implement this by setting the
callback for the descriptor to NULL? If the callback is NULL there is
nothing to at the end of a transfer/period and the dma engine driver may
choose to disable interrupts. This would also benefit non cyclic transfers
where the callback is NULL and we do not need add the new parameter to
dmaengine_prep_dma_cyclic.
We could do that but dma drivers enable the interrupts within
dmaengine_prep_dma_cyclic() call, and we fill up the callback for
dmaengine_submit() dmaengine API call.
We need to tell the dma drivers in dmaengine_prep_dma_cyclic() to suppress the
interrupts.
Note: First I was trying this to be done in hw_params() time via the
dmaengine_slave_config() call, but substream-runtime-no_period_wakeup is not
configured in there. It is set for _prepare() and _trigger().
As Vinod and Russell suggested I will modify the dmaengine_prep_dma_cyclic()
API to pass flags as well instead of the no_wakeup parameter.
- Lars
---
include/linux/dmaengine.h | 3 ++-
sound/soc/soc-dmaengine-pcm.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9c02a45..990444b 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -653,7 +653,8 @@ static inline struct dma_async_tx_descriptor
*dmaengine_prep_rio_sg(
static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_cyclic(
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
-size_t period_len, enum dma_transfer_direction dir)
+size_t period_len, enum dma_transfer_direction dir,
+bool no_wakeup)
{
return chan-device-device_prep_dma_cyclic(chan, buf_addr, buf_len,
period_len, dir, NULL);
diff --git a/sound/soc/soc-dmaengine-pcm.c b/sound/soc/soc-dmaengine-pcm.c
index 5df529e..6b70adb 100644
--- a/sound/soc/soc-dmaengine-pcm.c
+++ b/sound/soc/soc-dmaengine-pcm.c
@@ -147,7 +147,8 @@ static int dmaengine_pcm_prepare_and_submit(struct
snd_pcm_substream *substream)
desc = dmaengine_prep_dma_cyclic(chan,
substream-runtime-dma_addr,
snd_pcm_lib_buffer_bytes(substream),
-snd_pcm_lib_period_bytes(substream), direction);
+snd_pcm_lib_period_bytes(substream), direction,
+substream-runtime-no_period_wakeup);
if (!desc)
return -ENOMEM;
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
On 09/13/2012 06:38 PM, Russell King - ARM Linux wrote: On Thu, Sep 13, 2012 at 05:27:09PM +0200, Lars-Peter Clausen wrote: Hm... Do you think it would work as well if we implement this by setting the callback for the descriptor to NULL? If the callback is NULL there is nothing to at the end of a transfer/period and the dma engine driver may choose to disable interrupts. This would also benefit non cyclic transfers where the callback is NULL and we do not need add the new parameter to dmaengine_prep_dma_cyclic. Actually, there's a way to do that already. DMA_PREP_INTERRUPT. Unfortunately, most DMA engine slave API users don't set it when they setup their transfer: * @DMA_PREP_INTERRUPT - trigger an interrupt (callback) upon completion of * this transaction As I mentioned already to Vinod: the description of this flag is close enough for our needs (other than the notion of 'this transaction' is not really correct for cyclic mode). I will resend the series to add the flags as new parameter instead of the no_wakeup. if we fixed that, then we could use the lack of it to avoid the interrupt. However, cyclic transfers don't have the flags parameter used to pass this bit. Yet another bit of yucky inconsistent design in DMA engine land... -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
On 09/14/2012 06:26 AM, Vinod Koul wrote: On Thu, 2012-09-13 at 17:27 +0200, Lars-Peter Clausen wrote: Hi, Hm... Do you think it would work as well if we implement this by setting the callback for the descriptor to NULL? If the callback is NULL there is nothing to at the end of a transfer/period and the dma engine driver may choose to disable interrupts. This would also benefit non cyclic transfers where the callback is NULL and we do not need add the new parameter to dmaengine_prep_dma_cyclic. That will work too BUT the idea of no_wake mode in ALSA is that we should not have any interrupts, so anything which is going to cause interrupts to AP in undesired. The interrupts still happen and it just that dmaengine driver is not notifying client. Yes, this is correct. We could go and hack around later if the callback is not present and modify the irq requests for the platform but it is really not elegant way of dealing with the issue IMHO. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/9] ir-rx51: Handle signals properly
On 09/03/12 15:36, Sean Young wrote: On Sun, Sep 02, 2012 at 11:08:20PM +0300, Timo Kokkonen wrote: On 09/02/12 22:41, Sakari Ailus wrote: On Sun, Sep 02, 2012 at 06:20:27PM +0300, Timo Kokkonen wrote: On 09.02 2012 18:06:34, Sakari Ailus wrote: Heippa, Timo Kokkonen wrote: Terve, On 09/01/12 20:14, Sakari Ailus wrote: Moi, On Thu, Aug 30, 2012 at 08:54:24PM +0300, Timo Kokkonen wrote: @@ -273,9 +281,18 @@ static ssize_t lirc_rx51_write(struct file *file, const char *buf, /* * Don't return back to the userspace until the transfer has - * finished + * finished. However, we wish to not spend any more than 500ms + * in kernel. No IR code TX should ever take that long. + */ + i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0, + HZ / 2); Why such an arbitrary timeout? In reality it might not bite the user space in practice ever, but is it (and if so, why) really required in the first place? Well, I can think of two cases: 1) Something goes wrong. Such before I converted the patch to use the up to date PM QoS implementation, the transmitting could take very long time because the interrupts were not waking up the MPU. Now that this is sorted out only unknown bugs can cause transmitting to hang indefinitely. 2) User is (intentionally?) doing something wrong. For example by feeding in an IR code that has got very long pulses, he could end up having the lircd process hung in kernel unkillable for long time. That could be avoided quite easily by counting the pulse lengths and rejecting any IR codes that are obviously too long. But since I'd like to also protect against 1) case, I think this solution works just fine. In the end, this is just safety measure that this driver behaves well. In that case I think you should use wait_event_interruptible() instead. Well, that's what I had there in the first place. With interruptible wait we are left with problem with signals. I was told by Sean Young that the lirc API expects the write call to finish only after the IR code is transmitted. It's not the driver's job to decide what the user can do with the hardware and what not, is it? Yeah, policy should be decided by the user space. However, kernel should not leave any objvious denial of service holes open either. Allowing a process to get stuck unkillable within kernel for long time sounds like one to me. It's not elegant, but this can't be used as a denial of service attack. The driver waits for a maximum of a half a second after which signals are serviced as normal. It's interruptible, so the user space can interrupt that wait if it chooses so. Besides, if you call this denial of service, then capturing video on V4L2 is, too, since others can't use the device in the meantime. :-) Well, of course there is no problem if we use interruptible waits. But I was told by Sean that the lirc API expects the IR TX to be finished always when the write call returns. This is part of the ABI. The lircd deamon might want to do gap calculation if there are large spaces in the IR code being sent. Maybe others can enlighten us why such an ABI was choosen. I guess the assumption is to avoid breaking the transmission in the middle in case the process is signaled. And that's why we shouldn't use interruptible waits. However, if we allow simply breaking the transmitting in case the process is signaled any way during the transmission, then the handling would be trivial in the driver. That is, if someone for example kills or stops the lirc daemon process, then the IR code just wouldn't finish ever. Sean, do you have an opinion how this should or is allowed to work? You want to know when the hardware is done sending the IR. If you return EINTR to user space, how would user space know how much IR has been sent, if any? This ABI is not particularily elegant so there are proposals for a better interface which would obsolete the lirc interface. David Hardeman has worked on this: http://patchwork.linuxtv.org/patch/11411/ It appears that all modern lirc drivers are now using the rc-core functionalities to implement the common stuff. When the rx51 lirc driver was first written, the core was not in place yet. Therefore it is implementing the file operations in the driver, which other rc drivers won't do today. So, I think it would make sense to modify the rx51 driver to use the rc core functionality. But if there is an ABI change ongoing, I could wait until you have that done before I start working on the change? Considering this patch set, I think it makes sense still to apply these as they improve the existing code base. I'll just squash the one patch to the misc fixes, as pointed by Sakari, and then re-send the set. -Timo Anyway, we are trying to cover some rare corner cases here, I'm not sure how it should work exactly.. If there was a generic maximum
[PATCH v2 4/4] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
Add lis331dlh device tree data to am335x-evm.dts. In AM335x EVM
lis331dlh accelerometer is connected to I2C2 bus. So this patch
change the status of I2C2 node to okay to use I2C2 bus. Also
added all the required platform data to am335x-evm.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9fb59c5..890f955 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -47,6 +47,15 @@
};
};
+ i2c2: i2c@4802a000 {
+ status = okay;
+ clock-frequency = 40;
+
+ lis331dlh: lis331dlh@18 {
+ reg = 0x18;
+ };
+ };
+
dcan1: d_can@481d {
status = okay;
pinctrl-names = default;
@@ -61,6 +70,39 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ lis3_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = lis3_reg;
+ regulator-boot-on;
+ };
+};
+
+lis331dlh {
+ compatible = st,lis331dlh-i2c;
+ Vdd-supply = lis3_reg;
+ Vdd_IO-supply = lis3_reg;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = 10;
+ st,click-thresh-y = 10;
+ st,click-thresh-z = 10;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = 120;
+ st,min-limit-y = 120;
+ st,min-limit-z = 140;
+ st,max-limit-x = 550;
+ st,max-limit-y = 550;
+ st,max-limit-z = 750;
};
/include/ tps65910.dtsi
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] lis3: lis3lv02d: remove lis3lv02d driver DT init
Remove lis3lv02d driver device tree initialization from core driver
and move it to individual drivers. With the current implementation
some pdata parameters are missing if we use lis3lv02d_init_device()
in lis3lv02d_i2c driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/misc/lis3lv02d/lis3lv02d.c |8 ++--
drivers/misc/lis3lv02d/lis3lv02d.h |1 +
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index 79349ec..026021e 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -944,7 +944,7 @@ static void lis3lv02d_8b_configure(struct lis3lv02d *lis3,
}
#ifdef CONFIG_OF
-static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
+int lis3lv02d_init_dt(struct lis3lv02d *lis3)
{
struct lis3lv02d_platform_data *pdata;
struct device_node *np = lis3-of_node;
@@ -1084,7 +1084,7 @@ static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
}
#else
-static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
+int lis3lv02d_init_dt(struct lis3lv02d *lis3)
{
return 0;
}
@@ -1100,10 +1100,6 @@ int lis3lv02d_init_device(struct lis3lv02d *lis3)
irq_handler_t thread_fn;
int irq_flags = 0;
- err = lis3lv02d_init_dt(lis3);
- if (err 0)
- return err;
-
lis3-whoami = lis3lv02d_read_8(lis3, WHO_AM_I);
switch (lis3-whoami) {
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.h
b/drivers/misc/lis3lv02d/lis3lv02d.h
index 4cf0779..b5505fa 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.h
+++ b/drivers/misc/lis3lv02d/lis3lv02d.h
@@ -326,5 +326,6 @@ void lis3lv02d_joystick_disable(struct lis3lv02d *lis3);
void lis3lv02d_poweroff(struct lis3lv02d *lis3);
int lis3lv02d_poweron(struct lis3lv02d *lis3);
int lis3lv02d_remove_fs(struct lis3lv02d *lis3);
+int lis3lv02d_init_dt(struct lis3lv02d *lis3);
extern struct lis3lv02d lis3_dev;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] lis3: lis3lv02d_spi: Add lis3lv02d device tree init
Add lis3lv02d device tree initialization code/API to take pdata
from device node. Also remove CONFIG_OF ifdef from the driver,
if CONFIG_OF is not defined then OF APIs returns 0.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/misc/lis3lv02d/lis3lv02d_spi.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
index 23f3986..e1db6f4 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
@@ -84,10 +84,12 @@ static int __devinit lis302dl_spi_probe(struct spi_device
*spi)
lis3_dev.ac = lis3lv02d_axis_normal;
lis3_dev.pdata = spi-dev.platform_data;
-#ifdef CONFIG_OF
- if (of_match_device(lis302dl_spi_dt_ids, spi-dev))
+ if (of_match_device(lis302dl_spi_dt_ids, spi-dev)) {
lis3_dev.of_node = spi-dev.of_node;
-#endif
+ ret = lis3lv02d_init_dt(lis3_dev);
+ if (ret)
+ return ret;
+ }
spi_set_drvdata(spi, lis3_dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] lis3: lis3lv02d_i2c: Add device tree support
Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. Changes from v1: - Moved lis3lv02d_init_dt to individual drivers with some code clean-up. - Added lis331dlh compatible entry for lis331dlh parts AnilKumar Ch (4): lis3: lis3lv02d: remove lis3lv02d driver DT init lis3: lis3lv02d_spi: Add lis3lv02d device tree init lis3: lis3lv02d_i2c: Add lis3lv02d device tree init ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm arch/arm/boot/dts/am335x-evm.dts | 42 drivers/misc/lis3lv02d/lis3lv02d.c |8 ++ drivers/misc/lis3lv02d/lis3lv02d.h |1 + drivers/misc/lis3lv02d/lis3lv02d_i2c.c | 19 +++ drivers/misc/lis3lv02d/lis3lv02d_spi.c |8 +++--- 5 files changed, 69 insertions(+), 9 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3/4 stall when idling
Hi Tomi
On Fri, 14 Sep 2012, Tomi Valkeinen wrote:
I've noticed the following stack dump on omap3 and omap4 when the device
idles. It takes some time to happen, but it does happen reliably. I just
boot up the device to my minimal filesystem, and wait. Attached is my
kernel config, and I'm using Linus' master branch from today.
I haven't noticed these affect anything, but they sure are somewhat
annoying =).
Trace on omap3:
[ 602.007629] INFO: rcu_sched self-detected stall on CPU { 0} (t=29678
jiffies)
Good timing, check out this thread:
http://marc.info/?l=linux-omapm=134756235228309w=2
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
On 09/14/2012 05:26 AM, Vinod Koul wrote: On Thu, 2012-09-13 at 17:27 +0200, Lars-Peter Clausen wrote: Hi, Hm... Do you think it would work as well if we implement this by setting the callback for the descriptor to NULL? If the callback is NULL there is nothing to at the end of a transfer/period and the dma engine driver may choose to disable interrupts. This would also benefit non cyclic transfers where the callback is NULL and we do not need add the new parameter to dmaengine_prep_dma_cyclic. That will work too BUT the idea of no_wake mode in ALSA is that we should not have any interrupts, so anything which is going to cause interrupts to AP in undesired. The interrupts still happen and it just that dmaengine driver is not notifying client. Well, the idea was that the driver would disable interrupts if there is no callback to call, since there would be nothing to do in the interrupt handler anyway. But I guess the flags approach should work fine as well. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
On Thursday 13 September 2012, AnilKumar Ch wrote:
Add lis331dlh device tree data to am335x-evm.dts. In AM335x EVM
lis331dlh accelerometer is connected to I2C2 bus. So this patch
change the status to okay to use I2C2 bus. Also added all the
required platform data to am335x-evm.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 42
++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 9fb59c5..9e5a878 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -47,6 +47,15 @@
};
};
+ i2c2: i2c@4802a000 {
+ status = okay;
+ clock-frequency = 40;
+
+ lis331dlh: lis331dlh@18 {
+ reg = 0x18;
+ };
+ };
Why do you put the reg property here
dcan1: d_can@481d {
status = okay;
pinctrl-names = default;
@@ -61,6 +70,39 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ lis3_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = lis3_reg;
+ regulator-boot-on;
+ };
+};
+lis331dlh {
+ compatible = st,lis3lv02d-i2c;
and all the rest here? At least I would expect the compatible property
to be in the same place above.
Also, I think you should remove the -i2c postfix from the name, that
is already implied by the parent bus.
+ Vdd-supply = lis3_reg;
+ Vdd_IO-supply = lis3_reg;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = 10;
+ st,click-thresh-y = 10;
+ st,click-thresh-z = 10;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = 120;
+ st,min-limit-y = 120;
+ st,min-limit-z = 140;
+ st,max-limit-x = 550;
+ st,max-limit-y = 550;
+ st,max-limit-z = 750;
Is there a binding document that describes all these?
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote: DSS HW on OMAP4 onwards supports a new pipeline called writeback. Unlike other pipelines(called overlays in OMAPDSS), writeback takes pixel data from an overlay output or a overlay manager output and writes it back into a specified address in memory. writeback pipeline allows us to take benefit of the hardware processing available inside the DISPC like color space conversion, rescaling, compositing etc and do either a) perform memory-to-memory transfer with data processing, b) capture a displayed frame. The former is known as memory to memory mode of the writeback pipeline, and the latter is known as capture mode. More details about writeback can be found in the Display Subsystem section of the OMAP4/5 TRMs. witeback has properties of both overlays and overlay managers. It is like an overlay as it has programmable base addresses and contains blocks like scalar, You consistently use the term scalar in the patches, but I believe the correct term is scaler. color conversion unit, truncation unit, DISPC DMA FIFO. It is like a manager as enabling it immediately starts transfer to the memory, and it has a GO bit to use a new writeback configuration. This series prepares the low level DISPC driver(dispc.c) to configure writeback registers. The aim is to reuse most of the code as most of its registers are like overlay or manager registers, and are configured in the same way in most cases. The first few patches rename dispc_ovl_* functions to dispc_plane_* I'm not sure if the renaming causes more confusion than clarity... It kinda creates a mishmash of ovl/plane names, and the term plane doesn't really sound like it's a base for both overlays and wb. Could we consider the wb as a special case, and keep the ovl name for most of the things and have wb used for wb specific things? functions. The next few patches change how overlay caps are used within the dispc functions, this helps reusing more functions between overlays and I dislike this a bit, I think dispc driver should know what HW it has, you shouldn't need to pass caps to it. So I'd prefer the dispc driver to to have this information in dispc_features. I believe all OVL_CAPS should be there, and then exported to other drivers via some means. I guess this means could for now be just initializing ovl-caps with data from dispc.c. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote: On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote: This series prepares the low level DISPC driver(dispc.c) to configure writeback registers. The aim is to reuse most of the code as most of its registers are like overlay or manager registers, and are configured in the same way in most cases. The first few patches rename dispc_ovl_* functions to dispc_plane_* I'm not sure if the renaming causes more confusion than clarity... It kinda creates a mishmash of ovl/plane names, and the term plane doesn't really sound like it's a base for both overlays and wb. Could we consider the wb as a special case, and keep the ovl name for most of the things and have wb used for wb specific things? And while WB is a combination of overlays and ovl managers, do you think it'd be difficult to consider WB as a special, extended overlay? So just call it an overlay, and consider it as an overlay with special features, at least inside dispc.c. We probably need to have it as a totally different entity from user's point of view (i.e. the list of overlays wouldn't return WB, etc). Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote: Scaling calculations for an overlay are done by comparing pixel clock of the connected overlay manager and the core clock of DISPC. The pixel clock is the output rate of the scalar. The scalar block needs to provide pixels at this rate since the manager is connected to a panel, which has real time constraints. In the case of writeback in memory to memory mode, the output of the scalar blocks aren't connected to a display, and hence there isn't a pixel clock which causes downscaling limitations. Make the input to scaling calculations a bit more generic by passing the scalar output rate rather than passing pixel clock of the overlay manager connected to the pipeline, as we now have use cases where the scalar's output may not go to a manager connected to a panel. Pixel clock is the rate at which pixels are processed. I don't see it only meaning a clock that's related to actual video signal going out of OMAP. So if in normal case the scaler outputs pixels at the rate of pixel clock, we can call it pixel clock with WB's case also, instead of renaming it to output clock. Or was there some other reason for the rename, that I missed? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
On Fri, 2012-09-14 at 10:13 +0200, Lars-Peter Clausen wrote: On 09/14/2012 05:26 AM, Vinod Koul wrote: On Thu, 2012-09-13 at 17:27 +0200, Lars-Peter Clausen wrote: Hi, Hm... Do you think it would work as well if we implement this by setting the callback for the descriptor to NULL? If the callback is NULL there is nothing to at the end of a transfer/period and the dma engine driver may choose to disable interrupts. This would also benefit non cyclic transfers where the callback is NULL and we do not need add the new parameter to dmaengine_prep_dma_cyclic. That will work too BUT the idea of no_wake mode in ALSA is that we should not have any interrupts, so anything which is going to cause interrupts to AP in undesired. The interrupts still happen and it just that dmaengine driver is not notifying client. Well, the idea was that the driver would disable interrupts if there is no callback to call, since there would be nothing to do in the interrupt handler anyway. But I guess the flags approach should work fine as well. Yes we _could_ do that, but this relies on dmaengine driver to have this implicit understanding. Anyone using dmaengine library in ASoC may or may not be aware of this, so i would consider it hackish. Using this flag explicitly makes everyone aware what the intended behaviour is. -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/21] OMAPDSS: DISPC: Configure color conversion coefficients for writeback
On Thu, 2012-09-13 at 17:45 +0530, Archit Taneja wrote:
Writeback pipeline receives RGB data from one of the overlays or one of the
overlay managers. If the target color mode is YUV422 or NV12, we need to
convert
the RGB pixels to YUV. The scalar in WB then converts it to the target color
mode.
Hence, the color conversion coefficients that need to be programmed are the
ones
which convert a RGB24 pixel to YUV444. Program these coefficients for
writeback
pipeline.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 1623c9b..5811a18 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -681,20 +681,30 @@ static void dispc_plane_set_scale_coef(enum omap_plane
plane, int fir_hinc,
static void _dispc_setup_color_conv_coef(void)
{
int i;
+ int num_ovl = dss_feat_get_num_ovls();
+ int num_wb = dss_feat_get_num_wbs();
+
const struct color_conv_coef {
int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
int full_range;
- } ctbl_bt601_5 = {
- 298, 409,0, 298, -208, -100, 298,0, 517, 0,
+ } ctbl_bt601_5[2] = {
+ { 298, 409, 0, 298, -208, -100, 298, 0, 517, 0, },
+ { 66, 112, -38, 129, -94, -74, 25, -18, 112, 0, },
};
const struct color_conv_coef *ct;
#define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
+#define YUVTORGB 0
+#define RGBTOYUV 1
- ct = ctbl_bt601_5;
+ ct = ctbl_bt601_5[YUVTORGB];
+
+ for (i = 1; i num_ovl + num_wb; i++) {
+
+ if (i = num_ovl)
+ ct = ctbl_bt601_5[RGBTOYUV];
- for (i = 1; i dss_feat_get_num_ovls(); i++) {
dispc_write_reg(DISPC_OVL_CONV_COEF(i, 0),
CVAL(ct-rcr, ct-ry));
dispc_write_reg(DISPC_OVL_CONV_COEF(i, 1),
This looks a bit funny. I'd suggest to take the actual register writes
to a separate function, and have a separate tables for ovls and wb, and
have two for loops, first for ovls and then for wbs.
Btw, I wonder if we could consider WB as a single special entity, i.e.
no need for num_wbs or such. I know things may change in the future
HW, but I got the impression that adding overlays to DSS is costly, and
single WB is enough.
Then again, I'm not sure if handling only single WB would simplify much.
If you think it's no issue to have support for multiple WBs, perhaps we
can have it, just in case.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote: On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote: Scaling calculations for an overlay are done by comparing pixel clock of the connected overlay manager and the core clock of DISPC. The pixel clock is the output rate of the scalar. The scalar block needs to provide pixels at this rate since the manager is connected to a panel, which has real time constraints. In the case of writeback in memory to memory mode, the output of the scalar blocks aren't connected to a display, and hence there isn't a pixel clock which causes downscaling limitations. Make the input to scaling calculations a bit more generic by passing the scalar output rate rather than passing pixel clock of the overlay manager connected to the pipeline, as we now have use cases where the scalar's output may not go to a manager connected to a panel. Pixel clock is the rate at which pixels are processed. I don't see it only meaning a clock that's related to actual video signal going out of OMAP. So if in normal case the scaler outputs pixels at the rate of pixel clock, we can call it pixel clock with WB's case also, instead of renaming it to output clock. Pixel clock, in OMAP DSS terms, is the rate at which the video port of an overlay manager provides pixels to an output. It is a fixed rate at which the scaler needs to push out data. If we stick to this terminology of pixel clock, I don't think it applies to writeback. As far as I see it, there is no specific rate at which the scaler outputs data, it adjusts itself based on how much scaling is done, and at the rate we can get/push data to the interconnect. That's why I didn't want to call it pixel clock. Because, that sounds a lot like a fixed rate at which pixels need to be output. Or was there some other reason for the rename, that I missed? The main aim of this patch was to pass pixel clock rate/or output rate as an argument to scaler functions, rather than passing the overlay manager's channel id to calculate this rate. I can rename it to pixel clock if that seems better. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
Hi Arnd,
Thanks for the review,
On Fri, Sep 14, 2012 at 13:56:06, Arnd Bergmann wrote:
On Thursday 13 September 2012, AnilKumar Ch wrote:
Add lis331dlh device tree data to am335x-evm.dts. In AM335x EVM
lis331dlh accelerometer is connected to I2C2 bus. So this patch
change the status to okay to use I2C2 bus. Also added all the
required platform data to am335x-evm.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 42
++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 9fb59c5..9e5a878 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -47,6 +47,15 @@
};
};
+ i2c2: i2c@4802a000 {
+ status = okay;
+ clock-frequency = 40;
+
+ lis331dlh: lis331dlh@18 {
+ reg = 0x18;
+ };
+ };
Why do you put the reg property here
Here I specified reg property because lis331dlh I2C slave address is 0x18.
dcan1: d_can@481d {
status = okay;
pinctrl-names = default;
@@ -61,6 +70,39 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ lis3_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = lis3_reg;
+ regulator-boot-on;
+ };
+};
+lis331dlh {
+ compatible = st,lis3lv02d-i2c;
and all the rest here? At least I would expect the compatible property
to be in the same place above.
This data is appended to above one, to make it readable I moved remaining
properties to here.
Also, I think you should remove the -i2c postfix from the name, that
is already implied by the parent bus.
I will remove, but in case of spi the compatible name is lis3lv02d_spi.
By mistake I have uses -i2c instead of _i2c.
+ Vdd-supply = lis3_reg;
+ Vdd_IO-supply = lis3_reg;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = 10;
+ st,click-thresh-y = 10;
+ st,click-thresh-z = 10;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ st,min-limit-x = 120;
+ st,min-limit-y = 120;
+ st,min-limit-z = 140;
+ st,max-limit-x = 550;
+ st,max-limit-y = 550;
+ st,max-limit-z = 750;
Is there a binding document that describes all these?
Document is already present,
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=2f2ff3cc8d930493f9a598b9192706c09403e12e
Some minor changes in docs, in my next version I will update document
as well. I will send V3 if there are no comments on v2.
Thanks
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] drivers: bus: Move the OMAP interconnect driver to drivers/bus/
OMAP interconnect drivers are used for the interconnect error handling.
Since they are bus driver, lets move it to newly created drivers/bus.
Cc: Arnd Bergmann a...@arndb.de
Cc: Tony Lindgren t...@atomide.com
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Patch just moves OMAP interconnect drivers as is to the newly created
driver/bus/* directory. Patch is generated against arm-soc/drivers/ocp2scp
tree and test on all OMAP boards.
arch/arm/mach-omap2/Kconfig|2 ++
arch/arm/mach-omap2/Makefile |5 -
drivers/bus/Kconfig|6 ++
drivers/bus/Makefile |3 +++
{arch/arm/mach-omap2 = drivers/bus}/omap_l3_noc.c |0
{arch/arm/mach-omap2 = drivers/bus}/omap_l3_noc.h |0
{arch/arm/mach-omap2 = drivers/bus}/omap_l3_smx.c |0
{arch/arm/mach-omap2 = drivers/bus}/omap_l3_smx.h |0
8 files changed, 11 insertions(+), 5 deletions(-)
rename {arch/arm/mach-omap2 = drivers/bus}/omap_l3_noc.c (100%)
rename {arch/arm/mach-omap2 = drivers/bus}/omap_l3_noc.h (100%)
rename {arch/arm/mach-omap2 = drivers/bus}/omap_l3_smx.c (100%)
rename {arch/arm/mach-omap2 = drivers/bus}/omap_l3_smx.h (100%)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dd2db02..7d3c8ab 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -44,6 +44,7 @@ config ARCH_OMAP3
select ARM_CPU_SUSPEND if PM
select MULTI_IRQ_HANDLER
select SOC_HAS_OMAP2_SDRC
+ select OMAP_INTERCONNECT
config ARCH_OMAP4
bool TI OMAP4
@@ -63,6 +64,7 @@ config ARCH_OMAP4
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
select ARCH_NEEDS_CPU_IDLE_COUPLED
+ select OMAP_INTERCONNECT
config SOC_OMAP5
bool TI OMAP5
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f6a24b3..7fed980 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -199,11 +199,6 @@ obj-$(CONFIG_ARCH_OMAP4) +=
omap_hwmod_44xx_data.o
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU)+= emu.o
-# L3 interconnect
-obj-$(CONFIG_ARCH_OMAP3) += omap_l3_smx.o
-obj-$(CONFIG_ARCH_OMAP4) += omap_l3_noc.o
-obj-$(CONFIG_SOC_OMAP5)+= omap_l3_noc.o
-
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
mailbox_mach-objs := mailbox.o
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 6270415..bbec35d 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -12,4 +12,10 @@ config OMAP_OCP2SCP
OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via
OCP2SCP.
+config OMAP_INTERCONNECT
+ tristate OMAP INTERCONNECT DRIVER
+ depends on ARCH_OMAP2PLUS
+
+ help
+ Driver to enable OMAP interconnect error handling driver.
endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 0ec50bc..45d997c 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -3,3 +3,6 @@
#
obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
+
+# Interconnect bus driver for OMAP SoCs.
+obj-$(CONFIG_OMAP_INTERCONNECT)+= omap_l3_smx.o omap_l3_noc.o
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
similarity index 100%
rename from arch/arm/mach-omap2/omap_l3_noc.c
rename to drivers/bus/omap_l3_noc.c
diff --git a/arch/arm/mach-omap2/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
similarity index 100%
rename from arch/arm/mach-omap2/omap_l3_noc.h
rename to drivers/bus/omap_l3_noc.h
diff --git a/arch/arm/mach-omap2/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
similarity index 100%
rename from arch/arm/mach-omap2/omap_l3_smx.c
rename to drivers/bus/omap_l3_smx.c
diff --git a/arch/arm/mach-omap2/omap_l3_smx.h b/drivers/bus/omap_l3_smx.h
similarity index 100%
rename from arch/arm/mach-omap2/omap_l3_smx.h
rename to drivers/bus/omap_l3_smx.h
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
Hi, On 09/14/2012 11:50 AM, Vinod Koul wrote: Well, the idea was that the driver would disable interrupts if there is no callback to call, since there would be nothing to do in the interrupt handler anyway. But I guess the flags approach should work fine as well. Yes we _could_ do that, but this relies on dmaengine driver to have this implicit understanding. Anyone using dmaengine library in ASoC may or may not be aware of this, so i would consider it hackish. Using this flag explicitly makes everyone aware what the intended behaviour is. I'm not sure about which flags should ASoC set for the two case we are going to have. I think it should be something like this: unsigned long flags = DMA_CTRL_ACK; if (!substream-runtime-no_period_wakeup) flags |= DMA_PREP_INTERRUPT; I'm not 100% sure of the role of DMA_CTRL_ACK in this case. Or should we only handle the DMA_PREP_INTERRUPT flag, like this: unsigned long flags = 0; if (!substream-runtime-no_period_wakeup) flags |= DMA_PREP_INTERRUPT; What do you think? -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: SmartReflex: pass device dependent data via platform data
From: Jean Pihet j-pi...@ti.com
Remove the device dependent settings (cpu_is_xxx(), IP clock name)
from the driver code and pass them instead via the platform
data.
This allows a clean separation of the driver code and the platform
code.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/sr_device.c | 20
drivers/power/avs/smartreflex.c | 36 +---
include/linux/power/smartreflex.h | 19 +--
3 files changed, 46 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index d033a65..549e008 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -122,6 +122,26 @@ static int __init sr_dev_init(struct omap_hwmod *oh, void
*user)
sr_data-senn_mod = 0x1;
sr_data-senp_mod = 0x1;
+ if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
+ sr_data-err_weight = OMAP3430_SR_ERRWEIGHT;
+ sr_data-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
+ sr_data-accum_data = OMAP3430_SR_ACCUMDATA;
+ if (!(strcmp(sr_data-name, smartreflex_mpu_iva))) {
+ sr_data-senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
+ sr_data-senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
+ } else {
+ sr_data-senn_avgweight = OMAP3430_SR2_SENNAVGWEIGHT;
+ sr_data-senp_avgweight = OMAP3430_SR2_SENPAVGWEIGHT;
+ }
+ }
+
+ if (cpu_is_omap34xx())
+ strncpy(sr_data-sys_clk_name, sys_ck,
+ sizeof(sr_data-sys_clk_name));
+ else
+ strncpy(sr_data-sys_clk_name, sys_clkin_ck,
+ sizeof(sr_data-sys_clk_name));
+
sr_data-voltdm = voltdm_lookup(sr_dev_attr-sensor_voltdm_name);
if (IS_ERR(sr_data-voltdm)) {
pr_err(%s: Unable to get voltage domain pointer for VDD %s\n,
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index 44efc6e..734493d 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -131,10 +131,7 @@ static void sr_set_clk_length(struct omap_sr *sr)
struct clk *sys_ck;
u32 sys_clk_speed;
- if (cpu_is_omap34xx())
- sys_ck = clk_get(NULL, sys_ck);
- else
- sys_ck = clk_get(NULL, sys_clkin_ck);
+ sys_ck = clk_get(NULL, sr-sys_clk_name);
if (IS_ERR(sys_ck)) {
dev_err(sr-pdev-dev, %s: unable to get sys clk\n,
@@ -168,28 +165,6 @@ static void sr_set_clk_length(struct omap_sr *sr)
}
}
-static void sr_set_regfields(struct omap_sr *sr)
-{
- /*
-* For time being these values are defined in smartreflex.h
-* and populated during init. May be they can be moved to board
-* file or pmic specific data structure. In that case these structure
-* fields will have to be populated using the pdata or pmic structure.
-*/
- if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
- sr-err_weight = OMAP3430_SR_ERRWEIGHT;
- sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
- sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-name, smartreflex_mpu_iva))) {
- sr-senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
- sr-senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
- } else {
- sr-senn_avgweight = OMAP3430_SR2_SENNAVGWEIGHT;
- sr-senp_avgweight = OMAP3430_SR2_SENPAVGWEIGHT;
- }
- }
-}
-
static void sr_start_vddautocomp(struct omap_sr *sr)
{
if (!sr_class || !(sr_class-enable) || !(sr_class-configure)) {
@@ -922,8 +897,16 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
sr_info-nvalue_count = pdata-nvalue_count;
sr_info-senn_mod = pdata-senn_mod;
sr_info-senp_mod = pdata-senp_mod;
+ sr_info-err_weight = pdata-err_weight;
+ sr_info-err_maxlimit = pdata-err_maxlimit;
+ sr_info-accum_data = pdata-accum_data;
+ sr_info-senn_avgweight = pdata-senn_avgweight;
+ sr_info-senp_avgweight = pdata-senp_avgweight;
+ strncpy(sr_info-sys_clk_name, pdata-sys_clk_name,
+ sizeof(sr_info-sys_clk_name));
sr_info-autocomp_active = false;
sr_info-ip_type = pdata-ip_type;
+
sr_info-base = ioremap(mem-start, resource_size(mem));
if (!sr_info-base) {
dev_err(pdev-dev, %s: ioremap fail\n, __func__);
@@ -935,7 +918,6 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
sr_info-irq = irq-start;
sr_set_clk_length(sr_info);
- sr_set_regfields(sr_info);
list_add(sr_info-node, sr_list);
diff --git a/include/linux/power/smartreflex.h
b/include/linux/power/smartreflex.h
index
Re: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
On Fri, 2012-09-14 at 12:28 +0300, Peter Ujfalusi wrote: Hi, On 09/14/2012 11:50 AM, Vinod Koul wrote: Well, the idea was that the driver would disable interrupts if there is no callback to call, since there would be nothing to do in the interrupt handler anyway. But I guess the flags approach should work fine as well. Yes we _could_ do that, but this relies on dmaengine driver to have this implicit understanding. Anyone using dmaengine library in ASoC may or may not be aware of this, so i would consider it hackish. Using this flag explicitly makes everyone aware what the intended behaviour is. I'm not sure about which flags should ASoC set for the two case we are going to have. I think it should be something like this: unsigned long flags = DMA_CTRL_ACK; usage of ACK flag is mostly async_tx thingy, we can skip it for slave. if (!substream-runtime-no_period_wakeup) flags |= DMA_PREP_INTERRUPT; I'm not 100% sure of the role of DMA_CTRL_ACK in this case. Or should we only handle the DMA_PREP_INTERRUPT flag, like this: unsigned long flags = 0; if (!substream-runtime-no_period_wakeup) flags |= DMA_PREP_INTERRUPT; What do you think? Looks fine. -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
On Thursday 13 September 2012, Jon Hunter wrote:
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
I think we're getting very close now, I only have a few small comments left
that should all be uncontroversial.
+
+Client drivers should specify the DMA property using a phandle to the
controller
+followed by DMA controller specific data.
+
+Required property:
+- dmas: List of one or more DMA specifiers, each
consisting of
+ - A phandle pointing to DMA controller node
+ - A single integer cell containing DMA controller
+ specific information. This typically contains a dma
+ request line number or a channel number, but can
+ contain any data that is used required for configuring
+ a channel.
+- dma-names: Contains one identifier string for each dma
specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
I think here we need to clarify that listing the same name multiple times
implies
having multiple alternatives for the same channel.
+Example:
+
+- One DMA write channel, one DMA read/write channel:
+
+ i2c1: i2c@1 {
+ ...
+ dmas = sdma 2 /* read channel */
+ sdma 3; /* write channel */
+ dma-names = rx, tx
+ ...
+ };
And please add an example documenting this case.
+/**
+ * of_dma_find_channel - Find a DMA channel by name
+ * @np: device node to look for DMA channels
+ * @name:name of desired channel
+ * @dma_spec:pointer to DMA specifier as found in the device tree
+ *
+ * Find a DMA channel by the name. Returns 0 on success or appropriate
+ * errno value on error.
+ */
+static int of_dma_find_channel(struct device_node *np, char *name,
+struct of_phandle_args *dma_spec)
+{
+ int count, i;
+ const char *s;
+
+ count = of_property_count_strings(np, dma-names);
+ if (count 0)
+ return count;
+
+ for (i = 0; i count; i++) {
+ of_property_read_string_index(np, dma-names, i, s);
+
+ if (strcmp(name, s))
+ continue;
+
+ return of_parse_phandle_with_args(np, dmas, #dma-cells,
+ i, dma_spec);
+ }
+
+ return -ENODEV;
+}
I think we should at least keep trying the other channels with the same name
when
of_parse_phandle_with_args fails. We might want to do something smarter in
the long run, e.g. to spread channel allocations across the avaialable
controllers.
+/**
+ * of_dma_request_slave_channel - Get the DMA slave channel
+ * @np: device node to get DMA request from
+ * @name:name of desired channel
+ *
+ * Returns pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
+ char *name)
+{
...
+}
+EXPORT_SYMBOL_GPL(of_dma_request_slave_channel);
I think this no longer needs to be exported, with patch 2 on top.
+/**
+ * of_dma_simple_xlate - Simple DMA engine translation function
+ * @dma_spec:pointer to DMA specifier as found in the device tree
+ * @of_dma: pointer to DMA controller data
+ *
+ * A simple translation function for devices that use a 32-bit value for the
+ * filter_param when calling the DMA engine dma_request_channel() function.
+ * Note that this translation function requires that #dma-cells is equal to 1
+ * and the argument of the dma specifier is the 32-bit filter_param. Returns
+ * pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ int count = dma_spec-args_count;
+ struct of_dma_filter_info *info = ofdma-of_dma_data;
+
+ if (!info || !info-filter_fn)
+ return NULL;
+
+ if (count != 1)
+ return NULL;
+
+ return dma_request_channel(info-dma_cap, info-filter_fn,
+ dma_spec-args[0]);
+}
But this one does.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
On Fri, 2012-09-14 at 14:43 +0530, Archit Taneja wrote: On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote: On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote: Scaling calculations for an overlay are done by comparing pixel clock of the connected overlay manager and the core clock of DISPC. The pixel clock is the output rate of the scalar. The scalar block needs to provide pixels at this rate since the manager is connected to a panel, which has real time constraints. In the case of writeback in memory to memory mode, the output of the scalar blocks aren't connected to a display, and hence there isn't a pixel clock which causes downscaling limitations. Make the input to scaling calculations a bit more generic by passing the scalar output rate rather than passing pixel clock of the overlay manager connected to the pipeline, as we now have use cases where the scalar's output may not go to a manager connected to a panel. Pixel clock is the rate at which pixels are processed. I don't see it only meaning a clock that's related to actual video signal going out of OMAP. So if in normal case the scaler outputs pixels at the rate of pixel clock, we can call it pixel clock with WB's case also, instead of renaming it to output clock. Pixel clock, in OMAP DSS terms, is the rate at which the video port of an overlay manager provides pixels to an output. It is a fixed rate at which the scaler needs to push out data. If we stick to this terminology of pixel clock, I don't think it applies to writeback. As far as I see it, there is no specific rate at which the scaler outputs data, it adjusts itself based on how much scaling is done, and at the rate we can get/push data to the interconnect. That's why I didn't want to call it pixel clock. Because, that sounds a lot like a fixed rate at which pixels need to be output. I see your reasoning. I'm a bit reluctant to add a new clock term to omapdss. You can't (probably) find it in the TRM. Does the TRM talk about clocks with regard to WB? I do think pixel clock can be used as well here. While normally used for output, it's just a clock used for pixels, and at each tick we process one pixel, which is exactly what happens with WB also. Also, if I understood right, this pixel clock is not even used for WB, and in a later patch you just use a dummy value of 1 for the clock for WB. So even if pixel clock would not be the best name, would it make sense to use the name of pixel clock, but return 0 as the pck for WB, implying that pck is not valid/does not exist, and the scaling restrictions can be skipped for that? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
On Fri, Sep 14, 2012 at 12:28:28PM +0300, Peter Ujfalusi wrote: I'm not sure about which flags should ASoC set for the two case we are going to have. I think it should be something like this: unsigned long flags = DMA_CTRL_ACK; if (!substream-runtime-no_period_wakeup) flags |= DMA_PREP_INTERRUPT; That looks about right. I would encourage DMA_CTRL_ACK to always be set for slave stuff, because it will (according to my understanding of it) make the behaviour no different from the async_tx stuff... which is important when support for that stuff gets added. We could, of course, set DMA_CTRL_ACK in the slave APIs beneath the user, but the user has access to tx-flags between the prepare and submit calls... And doing it in the submit callback will force DMA engine drivers to have two separate submission paths (as tx'es can't be acked at submission time.) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
On Friday 14 September 2012 03:19 PM, Tomi Valkeinen wrote: On Fri, 2012-09-14 at 14:43 +0530, Archit Taneja wrote: On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote: On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote: Scaling calculations for an overlay are done by comparing pixel clock of the connected overlay manager and the core clock of DISPC. The pixel clock is the output rate of the scalar. The scalar block needs to provide pixels at this rate since the manager is connected to a panel, which has real time constraints. In the case of writeback in memory to memory mode, the output of the scalar blocks aren't connected to a display, and hence there isn't a pixel clock which causes downscaling limitations. Make the input to scaling calculations a bit more generic by passing the scalar output rate rather than passing pixel clock of the overlay manager connected to the pipeline, as we now have use cases where the scalar's output may not go to a manager connected to a panel. Pixel clock is the rate at which pixels are processed. I don't see it only meaning a clock that's related to actual video signal going out of OMAP. So if in normal case the scaler outputs pixels at the rate of pixel clock, we can call it pixel clock with WB's case also, instead of renaming it to output clock. Pixel clock, in OMAP DSS terms, is the rate at which the video port of an overlay manager provides pixels to an output. It is a fixed rate at which the scaler needs to push out data. If we stick to this terminology of pixel clock, I don't think it applies to writeback. As far as I see it, there is no specific rate at which the scaler outputs data, it adjusts itself based on how much scaling is done, and at the rate we can get/push data to the interconnect. That's why I didn't want to call it pixel clock. Because, that sounds a lot like a fixed rate at which pixels need to be output. I see your reasoning. I'm a bit reluctant to add a new clock term to omapdss. You can't (probably) find it in the TRM. Does the TRM talk about clocks with regard to WB? Yes, you can't find the word pixel clock linked to WB in the TRM. I do think pixel clock can be used as well here. While normally used for output, it's just a clock used for pixels, and at each tick we process one pixel, which is exactly what happens with WB also. Also, if I understood right, this pixel clock is not even used for WB, and in a later patch you just use a dummy value of 1 for the clock for WB. So even if pixel clock would not be the best name, would it make sense to use the name of pixel clock, but return 0 as the pck for WB, implying that pck is not valid/does not exist, and the scaling restrictions can be skipped for that? Yes, we could do that. I can check if zero leads to some bad results, or we could just bypass the scaler clock stuff if the pixel clock is 0. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/4] i2c: introduce i2c-cbus driver
On Mon, Sep 03, 2012 at 11:23:22PM +0300, Aaro Koskinen wrote:
Add i2c driver to enable access to devices behind CBUS on Nokia Internet
Tablets.
The patch also adds CBUS I2C configuration for N8x0 which is one of the
users of this driver.
Cc: linux-...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
OK, I found the short paragrahp about CBUS in the I2C spec, so I2C might
be an appropriate place. Still, before deciding if it should rather be
in the core directory, I still have a few questions.
Also, does anybody know of a generic bit-banging implementation in the
kernel which could be used here?
Jean: I'd appreciate your general opinion here, too.
diff --git a/drivers/i2c/busses/i2c-cbus.c b/drivers/i2c/busses/i2c-cbus.c
new file mode 100644
index 000..bacf2a9
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cbus.c
@@ -0,0 +1,369 @@
+/*
+ * CBUS I2C driver for Nokia Internet Tablets.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall, Mikko Ylinen and
+ * Felipe Balbi. Converted to I2C driver by Aaro Koskinen.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/io.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/i2c-cbus.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+
+struct cbus_host {
+ /* host lock */
+ spinlock_t lock;
+
+ struct device *dev;
+
+ int clk_gpio;
+ int dat_gpio;
+ int sel_gpio;
+};
+
+/**
+ * cbus_send_bit - sends one bit over the bus
+ * @host: the host we're using
+ * @bit: one bit of information to send
+ * @input: whether to set data pin as input after sending
+ */
+static int cbus_send_bit(struct cbus_host *host, unsigned bit,
+ unsigned input)
+{
+ int ret = 0;
+
+ gpio_set_value(host-dat_gpio, bit ? 1 : 0);
+ gpio_set_value(host-clk_gpio, 1);
+
+ /* The data bit is read on the rising edge of CLK */
This comment doesn't belong to the if-block, or?
+ if (input)
+ ret = gpio_direction_input(host-dat_gpio);
No minimum delay for the signal to be on the bus?
+
+ gpio_set_value(host-clk_gpio, 0);
+
+ return ret;
+}
+
+/**
+ * cbus_send_data - sends @len amount of data over the bus
+ * @host: the host we're using
+ * @data: the data to send
+ * @len: size of the transfer
+ * @input: whether to set data pin as input after sending
+ */
+static int cbus_send_data(struct cbus_host *host, unsigned data, unsigned
len,
+ unsigned input)
+{
+ int ret = 0;
+ int i;
+
+ for (i = len; i 0; i--) {
+ ret = cbus_send_bit(host, data (1 (i - 1)),
+ input (i == 1));
+ if (ret 0)
+ goto out;
+ }
+
+out:
+ return ret;
+}
+
+/**
+ * cbus_receive_bit - receives one bit from the bus
+ * @host: the host we're using
+ */
+static int cbus_receive_bit(struct cbus_host *host)
+{
+ int ret;
+
+ gpio_set_value(host-clk_gpio, 1);
No delays to ensure the signal has stabilized?
+ ret = gpio_get_value(host-dat_gpio);
+ if (ret 0)
+ goto out;
+ gpio_set_value(host-clk_gpio, 0);
+
+out:
+ return ret;
+}
+
+/**
+ * cbus_receive_word - receives 16-bit word from the bus
+ * @host: the host we're using
+ */
+static int cbus_receive_word(struct cbus_host *host)
+{
+ int ret = 0;
+ int i;
+
+ for (i = 16; i 0; i--) {
+ int bit = cbus_receive_bit(host);
+
+ if (bit 0)
+ goto out;
+
+ if (bit)
+ ret |= 1 (i - 1);
+ }
+
+out:
+ return ret;
+}
+
+/**
+ * cbus_transfer - transfers data over the bus
+ * @host: the host we're using
+ * @rw: read/write flag
+ * @dev: device address
+ * @reg: register address
+ * @data: if @rw == I2C_SBUS_WRITE data to send otherwise 0
+ */
+static int cbus_transfer(struct cbus_host *host, char rw, unsigned dev,
+ unsigned reg, unsigned data)
+{
+ unsigned long flags;
+ int ret;
+
+ /* We don't want interrupts disturbing our transfer */
+ spin_lock_irqsave(host-lock, flags);
+
+ /* Reset
Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
On Friday 14 September 2012 01:57 PM, Tomi Valkeinen wrote: On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote: DSS HW on OMAP4 onwards supports a new pipeline called writeback. Unlike other pipelines(called overlays in OMAPDSS), writeback takes pixel data from an overlay output or a overlay manager output and writes it back into a specified address in memory. writeback pipeline allows us to take benefit of the hardware processing available inside the DISPC like color space conversion, rescaling, compositing etc and do either a) perform memory-to-memory transfer with data processing, b) capture a displayed frame. The former is known as memory to memory mode of the writeback pipeline, and the latter is known as capture mode. More details about writeback can be found in the Display Subsystem section of the OMAP4/5 TRMs. witeback has properties of both overlays and overlay managers. It is like an overlay as it has programmable base addresses and contains blocks like scalar, You consistently use the term scalar in the patches, but I believe the correct term is scaler. Yes, my bad, I'll fix this. color conversion unit, truncation unit, DISPC DMA FIFO. It is like a manager as enabling it immediately starts transfer to the memory, and it has a GO bit to use a new writeback configuration. This series prepares the low level DISPC driver(dispc.c) to configure writeback registers. The aim is to reuse most of the code as most of its registers are like overlay or manager registers, and are configured in the same way in most cases. The first few patches rename dispc_ovl_* functions to dispc_plane_* I'm not sure if the renaming causes more confusion than clarity... It kinda creates a mishmash of ovl/plane names, and the term plane doesn't really sound like it's a base for both overlays and wb. Could we consider the wb as a special case, and keep the ovl name for most of the things and have wb used for wb specific things? I initially kept all of this the same, but I changed my mind at some point, not totally sure why. Even if we stick to the dispc_ovl_* names, we would still need to create q common function which dispc_ovl_setup() and dispc_wb_setup() could call. I called this dispc_plane_setup(), and then it felt weird to call everything else ovl specifuic, hence renamed all of them to dispc_plane_*. Could you suggest a better name than dispc_plane_setup? functions. The next few patches change how overlay caps are used within the dispc functions, this helps reusing more functions between overlays and I dislike this a bit, I think dispc driver should know what HW it has, you shouldn't need to pass caps to it. So I'd prefer the dispc driver to to have this information in dispc_features. I believe all OVL_CAPS should be there, and then exported to other drivers via some means. I guess this means could for now be just initializing ovl-caps with data from dispc.c. Currently, we pass the plane id to these low level functions, it extracts out the ovl struct usingthe plane id, and checks the ovl caps. What I'm doing now is just passing the caps directly to these low level functions. So that I don't need to have complicated checks in every function to extract caps between overlays or writeback. Archit Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: SmartReflex: fix error path in init function
From: Jean Pihet j-pi...@ti.com
Fix the error handling path in omap_sr_probe to correctly
de-allocate resources in case of problems.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
drivers/power/avs/smartreflex.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index 734493d..a802f4c 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -911,7 +911,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
if (!sr_info-base) {
dev_err(pdev-dev, %s: ioremap fail\n, __func__);
ret = -ENOMEM;
- goto err_release_region;
+ goto err_free_name;
}
if (irq)
@@ -949,7 +949,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
dev_err(pdev-dev, %s: Unable to create debugfs directory\n,
__func__);
ret = PTR_ERR(sr_info-dbg_dir);
- goto err_free_name;
+ goto err_debugfs;
}
(void) debugfs_create_file(autocomp, S_IRUGO | S_IWUSR,
@@ -993,11 +993,11 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
err_debugfs:
debugfs_remove_recursive(sr_info-dbg_dir);
-err_free_name:
- kfree(sr_info-name);
err_iounmap:
list_del(sr_info-node);
iounmap(sr_info-base);
+err_free_name:
+ kfree(sr_info-name);
err_release_region:
release_mem_region(mem-start, resource_size(mem));
err_free_devinfo:
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
On Fri, 2012-09-14 at 15:33 +0530, Archit Taneja wrote: On Friday 14 September 2012 03:19 PM, Tomi Valkeinen wrote: I see your reasoning. I'm a bit reluctant to add a new clock term to omapdss. You can't (probably) find it in the TRM. Does the TRM talk about clocks with regard to WB? Yes, you can't find the word pixel clock linked to WB in the TRM. Is there some other term for the clock related to WB? Yes, we could do that. I can check if zero leads to some bad results, or we could just bypass the scaler clock stuff if the pixel clock is 0. I think 0 value would make more sense than a dummy 1. 1 is still a valid clock, and it could go unnoticed in some other code paths that would use the function to get the clock. Of course, the scaler check function could internally check if the pck is 0, and then use 1 in its calculations, if that makes the function simpler. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: OMAP: SmartReflex: fix error path in init function
Hi!
On Fri, Sep 14, 2012 at 12:14 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Fix the error handling path in omap_sr_probe to correctly
de-allocate resources in case of problems.
Please note that this patch applies on top of 'ARM: OMAP: SmartReflex:
pass device dependent data via platform data' [1].
[1] http://marc.info/?l=linux-omapm=134761557609931w=2
Regards,
Jean
Signed-off-by: Jean Pihet j-pi...@ti.com
---
drivers/power/avs/smartreflex.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index 734493d..a802f4c 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -911,7 +911,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
if (!sr_info-base) {
dev_err(pdev-dev, %s: ioremap fail\n, __func__);
ret = -ENOMEM;
- goto err_release_region;
+ goto err_free_name;
}
if (irq)
@@ -949,7 +949,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
dev_err(pdev-dev, %s: Unable to create debugfs
directory\n,
__func__);
ret = PTR_ERR(sr_info-dbg_dir);
- goto err_free_name;
+ goto err_debugfs;
}
(void) debugfs_create_file(autocomp, S_IRUGO | S_IWUSR,
@@ -993,11 +993,11 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
err_debugfs:
debugfs_remove_recursive(sr_info-dbg_dir);
-err_free_name:
- kfree(sr_info-name);
err_iounmap:
list_del(sr_info-node);
iounmap(sr_info-base);
+err_free_name:
+ kfree(sr_info-name);
err_release_region:
release_mem_region(mem-start, resource_size(mem));
err_free_devinfo:
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
* Mohammed, Afzal: Wednesday, September 12, 2012 3:20 PM
But some of the tusb async values is less by one. I need
to get it right.
Reason has been identified. It was due to rounding error,
no changes are required in the expressions. Moving
completely to picoseconds resolves the issue.
Can you please try with the attached patch ?
Once it is confirmed that issue is resolved, I will cleanup
gpmc-nand.c too (which would also take care of picoseconds)
Note: As this mail is sent via exchange, I am attaching the
patch so that it reaches you in proper way.
Regards
AfzalFrom 101b3d4c558bae420cbeba634f4deeae27c3b905 Mon Sep 17 00:00:00 2001
From: Afzal Mohammed af...@ti.com
Date: Wed, 12 Sep 2012 19:30:27 +0530
Subject: [PATCH] gpmc: rounding error fix
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 150 +++-
arch/arm/plat-omap/include/plat/gpmc.h | 40
2 files changed, 90 insertions(+), 100 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index d8e5b08..e9d57db 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -289,11 +289,11 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
if (time == 0)
ticks = 0;
else
- ticks = gpmc_ns_to_ticks(time);
+ ticks = gpmc_ps_to_ticks(time);
nr_bits = end_bit - st_bit + 1;
if (ticks = 1 nr_bits) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d: %-10s* %3d ns, %3d ticks = %d\n,
+ pr_info(GPMC CS%d: %-10s* %3d ps, %3d ticks = %d\n,
cs, name, time, ticks, 1 nr_bits);
#endif
return -1;
@@ -302,10 +302,9 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
mask = (1 nr_bits) - 1;
l = gpmc_cs_read_reg(cs, reg);
#ifdef DEBUG
- printk(KERN_INFO
- GPMC CS%d: %-10s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n,
- cs, name, ticks, gpmc_get_fclk_period() * ticks / 1000,
- (l st_bit) mask, time);
+ pr_info(GPMC CS%d: %-10s: %3d ticks, %3lu ps (was %3i ticks) %3d ps\n,
+ cs, name, ticks, gpmc_get_fclk_period() * ticks,
+ (l st_bit) mask, time);
#endif
l = ~(mask st_bit);
l |= ticks st_bit;
@@ -385,8 +384,8 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
if (l (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
-cs, (div * gpmc_get_fclk_period()) / 1000, div);
+ pr_info(GPMC CS%d CLK period is %lu ps (div %d)\n,
+cs, div * gpmc_get_fclk_period(), div);
#endif
l = ~0x03;
l |= (div - 1);
@@ -922,46 +921,42 @@ static int gpmc_calc_sync_read_timings(struct gpmc_timings *gpmc_t,
* indirectly necessitates requirement of t_avdp_r t_avdp_w
* instead of having a single t_avdp
*/
- temp = max_t(u32, temp, gpmc_t-clk_activation * 1000 +
- dev_t-t_avdh);
- temp = max_t(u32,
- (gpmc_t-adv_on + gpmc_ticks_to_ns(1)) * 1000, temp);
+ temp = max_t(u32, temp, gpmc_t-clk_activation + dev_t-t_avdh);
+ temp = max_t(u32, gpmc_t-adv_on + gpmc_ticks_to_ps(1), temp);
}
- gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp) / 1000;
+ gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp);
/* oe_on */
temp = dev_t-t_oeasu; /* remove this ? */
if (mux) {
- temp = max_t(u32, temp,
- gpmc_t-clk_activation * 1000 + dev_t-t_ach);
- temp = max_t(u32, temp, (gpmc_t-adv_rd_off +
-gpmc_ticks_to_ns(dev_t-cyc_aavdh_oe)) * 1000);
+ temp = max_t(u32, temp, gpmc_t-clk_activation + dev_t-t_ach);
+ temp = max_t(u32, temp, gpmc_t-adv_rd_off +
+gpmc_ticks_to_ps(dev_t-cyc_aavdh_oe));
}
- gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp) / 1000;
+ gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp);
/* access */
/* any scope for improvement ?, by combining oe_on clk_activation,
* need to check whether access = clk_activation + round to sync clk ?
*/
temp = max_t(u32, dev_t-t_iaa, dev_t-cyc_iaa * gpmc_t-sync_clk);
- temp += gpmc_t-clk_activation * 1000;
+ temp += gpmc_t-clk_activation;
if (dev_t-cyc_oe)
- temp = max_t(u32, temp, (gpmc_t-oe_on +
-gpmc_ticks_to_ns(dev_t-cyc_oe)) * 1000);
- gpmc_t-access = gpmc_round_ps_to_ticks(temp) / 1000;
+ temp = max_t(u32, temp, gpmc_t-oe_on +
+gpmc_ticks_to_ps(dev_t-cyc_oe));
+ gpmc_t-access = gpmc_round_ps_to_ticks(temp);
- gpmc_t-oe_off = gpmc_t-access + gpmc_ticks_to_ns(1);
+ gpmc_t-oe_off = gpmc_t-access + gpmc_ticks_to_ps(1);
gpmc_t-cs_rd_off = gpmc_t-oe_off;
/* rd_cycle */
temp = max_t(u32, dev_t-t_cez_r, dev_t-t_oez);
temp = gpmc_round_ps_to_sync_clk(temp, gpmc_t-sync_clk) +
- gpmc_t-access * 1000;
+ gpmc_t-access;
/* barter t_ce_rdyz with t_cez_r ? */
if (dev_t-t_ce_rdyz)
- temp = max_t(u32, temp,
-gpmc_t-cs_rd_off * 1000 + dev_t-t_ce_rdyz);
- gpmc_t-rd_cycle = gpmc_round_ps_to_ticks(temp) / 1000;
+ temp = max_t(u32, temp, gpmc_t-cs_rd_off + dev_t-t_ce_rdyz);
+ gpmc_t-rd_cycle =
Re: [PATCH 1/4] i2c: introduce i2c-cbus driver
On Fri, 14 Sep 2012 12:08:06 +0200, Wolfram Sang wrote: OK, I found the short paragrahp about CBUS in the I2C spec, so I2C might be an appropriate place. Still, before deciding if it should rather be in the core directory, I still have a few questions. Also, does anybody know of a generic bit-banging implementation in the kernel which could be used here? Jean: I'd appreciate your general opinion here, too. Out of time at the moment :( -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
On Friday 14 September 2012 02:16 PM, Tomi Valkeinen wrote: On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote: On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote: This series prepares the low level DISPC driver(dispc.c) to configure writeback registers. The aim is to reuse most of the code as most of its registers are like overlay or manager registers, and are configured in the same way in most cases. The first few patches rename dispc_ovl_* functions to dispc_plane_* I'm not sure if the renaming causes more confusion than clarity... It kinda creates a mishmash of ovl/plane names, and the term plane doesn't really sound like it's a base for both overlays and wb. Could we consider the wb as a special case, and keep the ovl name for most of the things and have wb used for wb specific things? And while WB is a combination of overlays and ovl managers, do you think it'd be difficult to consider WB as a special, extended overlay? So just call it an overlay, and consider it as an overlay with special features, at least inside dispc.c. We probably need to have it as a totally different entity from user's point of view (i.e. the list of overlays wouldn't return WB, etc). Yes, we could do that within dispc.c, we would still need some manager like functions which set GO or ENABLE. But apart from that it should be okay. I think for dispc.c in general, for future, it might be a good idea to represent each piece of HW(like scalar or color converter, or a timing FSM) as a little function/module, and construct overlay/writeback/manager out of those, it might be cleaner. However, this may be an overkill, and not needed much if there aren't any new blocks comprising of these little blocks. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
On Friday 14 September 2012, AnilKumar, Chimata wrote:
On Fri, Sep 14, 2012 at 13:56:06, Arnd Bergmann wrote:
On Thursday 13 September 2012, AnilKumar Ch wrote:
Why do you put the reg property here
Here I specified reg property because lis331dlh I2C slave address is 0x18.
dcan1: d_can@481d {
status = okay;
pinctrl-names = default;
@@ -61,6 +70,39 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ lis3_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = lis3_reg;
+ regulator-boot-on;
+ };
+};
+lis331dlh {
+ compatible = st,lis3lv02d-i2c;
and all the rest here? At least I would expect the compatible property
to be in the same place above.
This data is appended to above one, to make it readable I moved remaining
properties to here.
I don't follow how this is making things more readable.
Maybe a more logical way to do this would be use the existing i2c2 label
and write all the additions as
i2c2: {
status = okay;
clock-frequency = 40;
lis331dlh@18 {
compatible = st,lis3lv02d;
reg = 0x18;
vdd-supply = lis3_reg;
vdd-io-supply = lis3_reg;
...
};
Also, I think you should remove the -i2c postfix from the name, that
is already implied by the parent bus.
I will remove, but in case of spi the compatible name is lis3lv02d_spi.
By mistake I have uses -i2c instead of _i2c.
The normal convention is to use '-', not '_', so that part was ok.
I think naming the other one lis3lv02d_spi was a mistake, it should
be named 'st,lis3lv02d' independent of the bus IMHO.
Document is already present,
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=2f2ff3cc8d930493f9a598b9192706c09403e12e
Some minor changes in docs, in my next version I will update document
as well. I will send V3 if there are no comments on v2.
Ok.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 00/23]I2C big cleanup
On Friday 14 September 2012 02:58 AM, Kevin Hilman wrote: Felipe Balbi ba...@ti.com writes: Hi, On Thu, Sep 13, 2012 at 11:04:42AM -0700, Kevin Hilman wrote: Kevin Hilman khil...@deeprootsystems.com writes: Kevin Hilman khil...@deeprootsystems.com writes: [...] Sorry to be late to the party (again), but still catching up after some time off. Unfortunately, this series causes PM regressions on several OMAP platforms. I hope we can hold off on this until those issues are addressed. I tracked the regression down to [PATCHv8 21/22] (see reply there.) Since this series is already merged, I suggest that the problem patch be reverted, at least for v3.7 and until the problem is better understood and tested. With that patch reverted, all my PM tests are passing. Feel free to add: OK, the i2c series is off the hook. Felipe and I spent a little time tracking this down. Felipe suggested that there might be a driver with periodic i2c activity keeping I2C awake, and thus preventing CORE retention. He was right. FYI, the original idea came from Shubhro. We agreed that would be the only way i2c would be prevented from idling. Great, thanks Shubhro! Also, FYI, I just submitted a patch to the TWL RTC driver which was the source of all the I2C activity since it's on the I2C-connected PMIC. Thanks for the help and suggestions, Kevin [1] https://groups.google.com/forum/#!topic/rtc-linux/sFbYmAzCRLQ Thanks for the testing and the patch. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
On Fri, 2012-09-14 at 15:43 +0530, Archit Taneja wrote: On Friday 14 September 2012 01:57 PM, Tomi Valkeinen wrote: I initially kept all of this the same, but I changed my mind at some point, not totally sure why. Even if we stick to the dispc_ovl_* names, we would still need to create q common function which dispc_ovl_setup() and dispc_wb_setup() could call. I called this dispc_plane_setup(), and then it felt weird to call everything else ovl specifuic, hence renamed all of them to dispc_plane_*. Could you suggest a better name than dispc_plane_setup? Well... dispc_ovl_setup_common? The function is also quite big, with huge number of arguments. Makes me wonder if we could split it up to some sensible parts. Would it be possible to have functions to setup, say, input related parameters (base-address, pix format, etc.), output related parameters (ovl position, ...). Well, it could just make it more confusing, as some things are shared between input and output, like scaling related things. But just an idea. functions. The next few patches change how overlay caps are used within the dispc functions, this helps reusing more functions between overlays and I dislike this a bit, I think dispc driver should know what HW it has, you shouldn't need to pass caps to it. So I'd prefer the dispc driver to to have this information in dispc_features. I believe all OVL_CAPS should be there, and then exported to other drivers via some means. I guess this means could for now be just initializing ovl-caps with data from dispc.c. Currently, we pass the plane id to these low level functions, it extracts out the ovl struct usingthe plane id, and checks the ovl caps. What I'm doing now is just passing the caps directly to these low level functions. So that I don't need to have complicated checks in every function to extract caps between overlays or writeback. Yep, I see. It's ok. My main dislike is the use of omap_dss_get_overlay() in dispc.c. I'd like dispc.c to be self-contained, so what I mean is that instead of initializing the caps in dss_features.c, and calling the above function in dispc.c, we should have a dispc.c internal table for dispc's HW, which would contain the caps and other necessary information. But that's not really related to this series. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
On Fri, 2012-09-14 at 15:54 +0530, Archit Taneja wrote: On Friday 14 September 2012 02:16 PM, Tomi Valkeinen wrote: On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote: On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote: This series prepares the low level DISPC driver(dispc.c) to configure writeback registers. The aim is to reuse most of the code as most of its registers are like overlay or manager registers, and are configured in the same way in most cases. The first few patches rename dispc_ovl_* functions to dispc_plane_* I'm not sure if the renaming causes more confusion than clarity... It kinda creates a mishmash of ovl/plane names, and the term plane doesn't really sound like it's a base for both overlays and wb. Could we consider the wb as a special case, and keep the ovl name for most of the things and have wb used for wb specific things? And while WB is a combination of overlays and ovl managers, do you think it'd be difficult to consider WB as a special, extended overlay? So just call it an overlay, and consider it as an overlay with special features, at least inside dispc.c. We probably need to have it as a totally different entity from user's point of view (i.e. the list of overlays wouldn't return WB, etc). Yes, we could do that within dispc.c, we would still need some manager like functions which set GO or ENABLE. But apart from that it should be okay. Yep, I was going through the WB registers, and to me it looks like 99% of them are like overlay regs. Then there are a few bits like GO which are special. I think for dispc.c in general, for future, it might be a good idea to represent each piece of HW(like scalar or color converter, or a timing Scal_e_r! ;) FSM) as a little function/module, and construct overlay/writeback/manager out of those, it might be cleaner. However, this may be an overkill, and not needed much if there aren't any new blocks comprising of these little blocks. I agree. In the minimum we should try to somehow group functions related to certain block, perhaps with name prefixes etc. I think it'll also help understanding the code. We probably currently have functions that touch multiple different blocks. Those funcs should be split to handle only one of the blocks. Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCH 2/2] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
+Daniel
On Fri, Sep 14, 2012 at 15:58:37, Arnd Bergmann wrote:
On Friday 14 September 2012, AnilKumar, Chimata wrote:
On Fri, Sep 14, 2012 at 13:56:06, Arnd Bergmann wrote:
On Thursday 13 September 2012, AnilKumar Ch wrote:
Why do you put the reg property here
Here I specified reg property because lis331dlh I2C slave address is 0x18.
dcan1: d_can@481d {
status = okay;
pinctrl-names = default;
@@ -61,6 +70,39 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+ lis3_reg: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = lis3_reg;
+ regulator-boot-on;
+ };
+};
+lis331dlh {
+ compatible = st,lis3lv02d-i2c;
and all the rest here? At least I would expect the compatible property
to be in the same place above.
This data is appended to above one, to make it readable I moved remaining
properties to here.
I don't follow how this is making things more readable.
Basic lis3 parameter is in i2c2 node to tell the hierarchy of
nodes and remaining parameters at the bottom. With this way
we can understand easily what is start end braces so that
node hierarchy is cleaner. (This is my view)
Maybe a more logical way to do this would be use the existing i2c2 label
and write all the additions as
i2c2: {
status = okay;
clock-frequency = 40;
lis331dlh@18 {
compatible = st,lis3lv02d;
reg = 0x18;
vdd-supply = lis3_reg;
vdd-io-supply = lis3_reg;
...
};
If this is better/preferable way then I will change.
Also, I think you should remove the -i2c postfix from the name, that
is already implied by the parent bus.
I will remove, but in case of spi the compatible name is lis3lv02d_spi.
By mistake I have uses -i2c instead of _i2c.
Then, I will change to 'st,lis3lv02d' in lis3lv02d_i2c driver
and same will added to .dts file.
Small question here, in my v2 version I have specified both
the compatible names lis3lv02d and lis331dlh is it fine or
only one is sufficient?
+static struct of_device_id lis3lv02d_i2c_dt_ids[] = {
+ { .compatible = st,lis3lv02d },
+ { .compatible = st,lis331dlh },
+ {}
+};
The normal convention is to use '-', not '_', so that part was ok.
I think naming the other one lis3lv02d_spi was a mistake, it should
be named 'st,lis3lv02d' independent of the bus IMHO.
Yes, initially I expected the same. I think driver name is used
as a compatible string.
Document is already present,
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=2f2ff3cc8d930493f9a598b9192706c09403e12e
Some minor changes in docs, in my next version I will update document
as well. I will send V3 if there are no comments on v2.
Can you just quickly review v2 series? So that I will send
V3.
Thanks
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RTC: TWL: ensure all interrupts are disabled during probe
Hi Kevin, On Fri, Sep 14, 2012 at 2:15 AM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Kevin Hilman khil...@ti.com On some platforms, bootloaders are known to do some interesting RTC programming. Without going into the obscurities as to why this may be the case, suffice it to say the the driver should not make any assumptions about the state of the RTC when the driver loads. In particular, the driver probe should be sure that all interrupts are disabled until otherwise programmed. This was discovered when finding bursty I2C traffic every second on Overo platforms. This I2C overhead was keeping the SoC from hitting deep power states. The cause was found to be the RTC firing every second on the I2C-connected TWL PMIC. Special thanks to Felipe Balbi for suggesting to look for a rogue driver as the source of the I2C traffic rather than the I2C driver itself. Special thanks to Steve Sakoman for helping track down the source of the continuous RTC interrups on the Overo boards. Tested that the continuous interrupt issue after doing a i2c mm on omap4sdp. This patch solves the issue. thanks, Cc: Felipe Balbi ba...@ti.com Cc: Steve Sakoman st...@sakoman.com Signed-off-by: Kevin Hilman khil...@ti.com --- Patch applies to v3.6-rc5 drivers/rtc/rtc-twl.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c index c5d06fe..9277d94 100644 --- a/drivers/rtc/rtc-twl.c +++ b/drivers/rtc/rtc-twl.c @@ -495,6 +495,11 @@ static int __devinit twl_rtc_probe(struct platform_device *pdev) if (ret 0) goto out1; + /* ensure interrupts are disabled, bootloaders can be strange */ + ret = twl_rtc_write_u8(0, REG_RTC_INTERRUPTS_REG); + if (ret 0) + dev_warn(pdev-dev, unable to disable interrupt\n); + Now that it is always 0 can the below read be removed as it is redundant now. /* init cached IRQ enable bits */ ret = twl_rtc_read_u8(rtc_irq_bits, REG_RTC_INTERRUPTS_REG); if (ret 0) -- 1.7.9.2 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] drivers: phy: add generic PHY framework
The PHY framework provides a set of API's for the PHY drivers to
create/remove a PHY and the PHY users to obtain a reference to the PHY
using or without using phandle. If the PHY users has to obtain a reference to
the PHY without using phandle, the platform specfic intialization code (say
from board file) should have already called phy_bind with the binding
information. The binding information consists of phy's device name, phy
user device name and an index. The index is used when the same phy user
binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
information about the PHY and ops like init, exit, suspend, resume,
poweron, shutdown.
Nyet-signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
This framework is actually intended to be used by all the PHY drivers in the
kernel. Though it's going to take a while for that, I intend to migrate
existing USB/OTG phy drivers to use this framework as we align on the design
of this framework. Once I migrate these phy drivers, I'll be able to test this
framework (I haven't tested this framework so far). I sent this patch early
so as to get review comments and align on the design. Thanks :-)
drivers/Kconfig |2 +
drivers/Makefile|2 +
drivers/phy/Kconfig | 13 ++
drivers/phy/Makefile|5 +
drivers/phy/phy-core.c | 437 +++
include/linux/phy/phy.h | 181
6 files changed, 640 insertions(+)
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ece958d..8488818 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -152,4 +152,6 @@ source drivers/vme/Kconfig
source drivers/pwm/Kconfig
+source drivers/phy/Kconfig
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 5b42184..63d6bbe 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -38,6 +38,8 @@ obj-y += char/
# gpu/ comes after char for AGP vs DRM startup
obj-y += gpu/
+obj-y += phy/
+
obj-$(CONFIG_CONNECTOR)+= connector/
# i810fb and intelfb depend on char/agp/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 000..34f7077
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+ tristate Generic PHY Support
+ help
+ Generic PHY support.
+
+ This framework is designed to provide a generic interface for PHY
+ devices present in the kernel. This layer will have the generic
+ API by which phy drivers can create PHY using the phy framework and
+ phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY) += phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 000..c55446a
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,437 @@
+/*
+ * phy-core.c -- Generic Phy framework.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/err.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/phy/phy.h
+
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
+
+ phy_put(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+ return res == match_data;
+}
+
+static struct phy *phy_lookup(struct device *dev, u8 index)
+{
+ struct phy_bind *phy_bind = NULL;
+
+ list_for_each_entry(phy_bind, phy_bind_list, list) {
+ if (!(strcmp(phy_bind-dev_name, dev_name(dev)))
+ phy_bind-index == index)
+
[PATCH v3 06/15] ASoC: omap-mcbsp: Use sDMA packet mode instead of frame mode
When McBSP is configured in threshold mode we can use sDMA packet mode in
all cases.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-mcbsp.c | 47 -
1 file changed, 17 insertions(+), 30 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 2e91a86..fe3debc 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -81,9 +81,6 @@ static void omap_mcbsp_set_threshold(struct snd_pcm_substream
*substream)
*/
if (dma_data-packet_size)
words = dma_data-packet_size;
- else if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
- words = snd_pcm_lib_period_bytes(substream) /
- (mcbsp-wlen / 8);
else
words = 1;
@@ -251,6 +248,7 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
dma_data-set_threshold = omap_mcbsp_set_threshold;
if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
int period_words, max_thrsh;
+ int divider = 0;
period_words = params_period_bytes(params) / (wlen / 8);
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
@@ -258,34 +256,23 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
else
max_thrsh = mcbsp-max_rx_thres;
/*
-* If the period contains less or equal number of words,
-* we are using the original threshold mode setup:
-* McBSP threshold = sDMA frame size = period_size
-* Otherwise we switch to sDMA packet mode:
-* McBSP threshold = sDMA packet size
-* sDMA frame size = period size
+* Use sDMA packet mode if McBSP is in threshold mode:
+* If period words less than the FIFO size the packet
+* size is set to the number of period words, otherwise
+* Look for the biggest threshold value which divides
+* the period size evenly.
*/
- if (period_words max_thrsh) {
- int divider = 0;
-
- /*
-* Look for the biggest threshold value, which
-* divides the period size evenly.
-*/
- divider = period_words / max_thrsh;
- if (period_words % max_thrsh)
- divider++;
- while (period_words % divider
- divider period_words)
- divider++;
- if (divider == period_words)
- return -EINVAL;
-
- pkt_size = period_words / divider;
- sync_mode = OMAP_DMA_SYNC_PACKET;
- } else {
- sync_mode = OMAP_DMA_SYNC_FRAME;
- }
+ divider = period_words / max_thrsh;
+ if (period_words % max_thrsh)
+ divider++;
+ while (period_words % divider
+ divider period_words)
+ divider++;
+ if (divider == period_words)
+ return -EINVAL;
+
+ pkt_size = period_words / divider;
+ sync_mode = OMAP_DMA_SYNC_PACKET;
} else if (channels 1) {
/* Use packet mode for non mono streams */
pkt_size = channels;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 15/15] ASoC: omap-pcm: Convert to use dmaengine
Original author: Russell King rmk+ker...@arm.linux.org.uk
Switch the omap-pcm to use dmaengine.
Certain features are not supported by after dmaengine conversion:
1. No period wakeup mode
DMA engine has no way to communicate this information through
standard channels.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Russell King rmk+ker...@arm.linux.org.uk
---
sound/soc/omap/Kconfig| 3 +-
sound/soc/omap/omap-pcm.c | 269 ++
2 files changed, 61 insertions(+), 211 deletions(-)
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 2c484a5..7048137 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -1,6 +1,7 @@
config SND_OMAP_SOC
tristate SoC Audio for the Texas Instruments OMAP chips
- depends on ARCH_OMAP
+ depends on ARCH_OMAP DMA_OMAP
+ select SND_SOC_DMAENGINE_PCM
config SND_OMAP_SOC_DMIC
tristate
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 74da4b7..a2636f6 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -25,12 +25,13 @@
#include linux/dma-mapping.h
#include linux/slab.h
#include linux/module.h
+#include linux/omap-dma.h
#include sound/core.h
#include sound/pcm.h
#include sound/pcm_params.h
+#include sound/dmaengine_pcm.h
#include sound/soc.h
-#include plat/dma.h
#include omap-pcm.h
static const struct snd_pcm_hardware omap_pcm_hardware = {
@@ -49,61 +50,34 @@ static const struct snd_pcm_hardware omap_pcm_hardware = {
.buffer_bytes_max = 128 * 1024,
};
-struct omap_runtime_data {
- spinlock_t lock;
- struct omap_pcm_dma_data*dma_data;
- int dma_ch;
- int period_index;
-};
-
-static void omap_pcm_dma_irq(int ch, u16 stat, void *data)
+static int omap_pcm_get_dma_buswidth(int num_bits)
{
- struct snd_pcm_substream *substream = data;
- struct snd_pcm_runtime *runtime = substream-runtime;
- struct omap_runtime_data *prtd = runtime-private_data;
- unsigned long flags;
-
- if ((cpu_is_omap1510())) {
- /*
-* OMAP1510 doesn't fully support DMA progress counter
-* and there is no software emulation implemented yet,
-* so have to maintain our own progress counters
-* that can be used by omap_pcm_pointer() instead.
-*/
- spin_lock_irqsave(prtd-lock, flags);
- if ((stat == OMAP_DMA_LAST_IRQ)
- (prtd-period_index == runtime-periods - 1)) {
- /* we are in sync, do nothing */
- spin_unlock_irqrestore(prtd-lock, flags);
- return;
- }
- if (prtd-period_index = 0) {
- if (stat OMAP_DMA_BLOCK_IRQ) {
- /* end of buffer reached, loop back */
- prtd-period_index = 0;
- } else if (stat OMAP_DMA_LAST_IRQ) {
- /* update the counter for the last period */
- prtd-period_index = runtime-periods - 1;
- } else if (++prtd-period_index = runtime-periods) {
- /* end of buffer missed? loop back */
- prtd-period_index = 0;
- }
- }
- spin_unlock_irqrestore(prtd-lock, flags);
- }
+ int buswidth;
- snd_pcm_period_elapsed(substream);
+ switch (num_bits) {
+ case 16:
+ buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
+ break;
+ case 32:
+ buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ break;
+ default:
+ buswidth = -EINVAL;
+ break;
+ }
+ return buswidth;
}
+
/* this may get called several times by oss emulation */
static int omap_pcm_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
struct snd_pcm_runtime *runtime = substream-runtime;
struct snd_soc_pcm_runtime *rtd = substream-private_data;
- struct omap_runtime_data *prtd = runtime-private_data;
struct omap_pcm_dma_data *dma_data;
-
+ struct dma_slave_config config;
+ struct dma_chan *chan;
int err = 0;
dma_data = snd_soc_dai_get_dma_data(rtd-cpu_dai, substream);
@@ -116,195 +90,78 @@ static int omap_pcm_hw_params(struct snd_pcm_substream
*substream,
snd_pcm_set_runtime_buffer(substream, substream-dma_buffer);
runtime-dma_bytes = params_buffer_bytes(params);
- if (prtd-dma_data)
- return 0;
- prtd-dma_data = dma_data;
- err = omap_request_dma(dma_data-dma_req, dma_data-name,
-
[PATCH v3 12/15] ASoC: OMAP: mcbsp, mcpdm, dmic: Let omap-pcm to pick the dma_type
omap-pcm can figure out the correct dma_type based on the stream's format.
In this way we can get rid of the plat/dma.h include from these drivers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-dmic.c | 2 --
sound/soc/omap/omap-mcbsp.c | 3 ---
sound/soc/omap/omap-mcpdm.c | 3 ---
3 files changed, 8 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 60b7b8c..df0ff24 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -33,7 +33,6 @@
#include linux/slab.h
#include linux/pm_runtime.h
#include linux/of_device.h
-#include plat/dma.h
#include sound/core.h
#include sound/pcm.h
@@ -63,7 +62,6 @@ struct omap_dmic {
*/
static struct omap_pcm_dma_data omap_dmic_dai_dma_params = {
.name = DMIC capture,
- .data_type = OMAP_DMA_DATA_TYPE_S32,
};
static inline void omap_dmic_write(struct omap_dmic *dmic, u16 reg, u32 val)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 5b3bacc..a230646 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -34,7 +34,6 @@
#include sound/initval.h
#include sound/soc.h
-#include plat/dma.h
#include plat/mcbsp.h
#include mcbsp.h
#include omap-mcbsp.h
@@ -234,11 +233,9 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
- dma_data-data_type = OMAP_DMA_DATA_TYPE_S16;
wlen = 16;
break;
case SNDRV_PCM_FORMAT_S32_LE:
- dma_data-data_type = OMAP_DMA_DATA_TYPE_S32;
wlen = 32;
break;
default:
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index f90d5de..84743d4 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -40,7 +40,6 @@
#include sound/pcm_params.h
#include sound/soc.h
-#include plat/dma.h
#include plat/omap_hwmod.h
#include omap-mcpdm.h
#include omap-pcm.h
@@ -71,11 +70,9 @@ struct omap_mcpdm {
static struct omap_pcm_dma_data omap_mcpdm_dai_dma_params[] = {
{
.name = Audio playback,
- .data_type = OMAP_DMA_DATA_TYPE_S32,
},
{
.name = Audio capture,
- .data_type = OMAP_DMA_DATA_TYPE_S32,
},
};
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 14/15] ASoC: OMAP: mcbsp, mcpdm, dmic, hdmi: Set dma_data at startup time
Set the dma_data for the stream (snd_soc_dai_set_dma_data) at dai_startup
time so omap-pcm will have access to the needed information regarding to
the DMA channel earlier.
This is needed for the clean dmaengine support.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-dmic.c | 6 --
sound/soc/omap/omap-hdmi.c | 15 +--
sound/soc/omap/omap-mcbsp.c | 7 ---
sound/soc/omap/omap-mcpdm.c | 8
4 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index df0ff24..68f2cd1 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -118,6 +118,7 @@ static int omap_dmic_dai_startup(struct snd_pcm_substream
*substream,
mutex_unlock(dmic-mutex);
+ snd_soc_dai_set_dma_data(dai, substream, omap_dmic_dai_dma_params);
return ret;
}
@@ -202,6 +203,7 @@ static int omap_dmic_dai_hw_params(struct snd_pcm_substream
*substream,
struct snd_soc_dai *dai)
{
struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
+ struct omap_pcm_dma_data *dma_data;
int channels;
dmic-clk_div = omap_dmic_select_divider(dmic, params_rate(params));
@@ -227,8 +229,8 @@ static int omap_dmic_dai_hw_params(struct snd_pcm_substream
*substream,
}
/* packet size is threshold * channels */
- omap_dmic_dai_dma_params.packet_size = dmic-threshold * channels;
- snd_soc_dai_set_dma_data(dai, substream, omap_dmic_dai_dma_params);
+ dma_data = snd_soc_dai_get_dma_data(dai, substream);
+ dma_data-packet_size = dmic-threshold * channels;
return 0;
}
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index 0951767..f59c69f 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -67,6 +67,9 @@ static int omap_hdmi_dai_startup(struct snd_pcm_substream
*substream,
dev_err(dai-dev, audio not supported\n);
return -ENODEV;
}
+
+ snd_soc_dai_set_dma_data(dai, substream, priv-dma_params);
+
return 0;
}
@@ -85,24 +88,24 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream
*substream,
struct hdmi_priv *priv = snd_soc_dai_get_drvdata(dai);
struct snd_aes_iec958 *iec = priv-iec;
struct snd_cea_861_aud_if *cea = priv-cea;
+ struct omap_pcm_dma_data *dma_data;
int err = 0;
+ dma_data = snd_soc_dai_get_dma_data(dai, substream);
+
switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
- priv-dma_params.packet_size = 16;
+ dma_data-packet_size = 16;
break;
case SNDRV_PCM_FORMAT_S24_LE:
- priv-dma_params.packet_size = 32;
+ dma_data-packet_size = 32;
break;
default:
dev_err(dai-dev, format not supported!\n);
return -EINVAL;
}
- priv-dma_params.data_type = 32;
-
- snd_soc_dai_set_dma_data(dai, substream,
-priv-dma_params);
+ dma_data-data_type = 32;
/*
* fill the IEC-60958 channel status word
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index a230646..fef2f59 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -151,6 +151,9 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream
*substream,
SNDRV_PCM_HW_PARAM_PERIOD_SIZE, 2);
}
+ snd_soc_dai_set_dma_data(cpu_dai, substream,
+mcbsp-dma_data[substream-stream]);
+
return err;
}
@@ -228,7 +231,7 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
int pkt_size = 0;
unsigned int format, div, framesize, master;
- dma_data = mcbsp-dma_data[substream-stream];
+ dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream);
channels = params_channels(params);
switch (params_format(params)) {
@@ -277,8 +280,6 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
dma_data-packet_size = pkt_size;
- snd_soc_dai_set_dma_data(cpu_dai, substream, dma_data);
-
if (mcbsp-configured) {
/* McBSP already configured by another stream */
return 0;
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index 84743d4..7755650 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -267,9 +267,11 @@ static int omap_mcpdm_dai_startup(struct snd_pcm_substream
*substream,
}
omap_mcpdm_open_streams(mcpdm);
}
-
mutex_unlock(mcpdm-mutex);
+ snd_soc_dai_set_dma_data(dai, substream,
+omap_mcpdm_dai_dma_params[substream-stream]);
+
return 0;
}
@@ -324,7
[PATCH v3 05/15] dmaengine: omap-dma: Add support to suppress interrupts in cyclic mode
When requested (DMA_PREP_INTERRUPT is cleared in flags) disable all DMA
interrupts for the channel. In this mode user space does not expect
periodic reports from kernel about the progress of the audio stream.
PulseAudio for example support this type of mode.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/omap-dma.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 4d2650f..f59f244 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -429,7 +429,10 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_dma_cyclic(
if (!c-cyclic) {
c-cyclic = true;
omap_dma_link_lch(c-dma_ch, c-dma_ch);
- omap_enable_dma_irq(c-dma_ch, OMAP_DMA_FRAME_IRQ);
+
+ if (flags DMA_PREP_INTERRUPT)
+ omap_enable_dma_irq(c-dma_ch, OMAP_DMA_FRAME_IRQ);
+
omap_disable_dma_irq(c-dma_ch, OMAP_DMA_BLOCK_IRQ);
}
@@ -438,7 +441,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_dma_cyclic(
omap_set_dma_dest_burst_mode(c-dma_ch, OMAP_DMA_DATA_BURST_16);
}
- return vchan_tx_prep(c-vc, d-vd, DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ return vchan_tx_prep(c-vc, d-vd, flags);
}
static int omap_dma_slave_config(struct omap_chan *c, struct dma_slave_config
*cfg)
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/15] ARM: OMAP4: hwmod_data: Add resource names to McPDM memory ranges
To help the driver to get the correct memory range to access McPDM
registers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..f65251e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5059,6 +5059,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_per__mcbsp4 =
{
static struct omap_hwmod_addr_space omap44xx_mcpdm_addrs[] = {
{
+ .name = mpu,
.pa_start = 0x40132000,
.pa_end = 0x4013207f,
.flags = ADDR_TYPE_RT
@@ -5077,6 +5078,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcpdm = {
static struct omap_hwmod_addr_space omap44xx_mcpdm_dma_addrs[] = {
{
+ .name = dma,
.pa_start = 0x49032000,
.pa_end = 0x4903207f,
.flags = ADDR_TYPE_RT
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 13/15] ASoC: omap-pcm, omap-dmic: Change the use of omap_pcm_dma_data-data_type
Instead of the OMAP DMA data type definition the data_type will be used to
specify the number of bits the DMA word should be configured or 0 in case
when based on the stream's format the omap-pcm can decide the needed DMA
word size.
This feature is needed for the omap-hdmi where the sDMA need to be
configured for 32bit word type regardless of the audio format used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-hdmi.c | 3 +--
sound/soc/omap/omap-pcm.c | 3 ++-
sound/soc/omap/omap-pcm.h | 3 ++-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index b194646..0951767 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -34,7 +34,6 @@
#include sound/asoundef.h
#include video/omapdss.h
-#include plat/dma.h
#include omap-pcm.h
#include omap-hdmi.h
@@ -100,7 +99,7 @@ static int omap_hdmi_dai_hw_params(struct snd_pcm_substream
*substream,
return -EINVAL;
}
- priv-dma_params.data_type = OMAP_DMA_DATA_TYPE_S32;
+ priv-dma_params.data_type = 32;
snd_soc_dai_set_dma_data(dai, substream,
priv-dma_params);
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 4c13a5f..74da4b7 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -183,7 +183,8 @@ static int omap_pcm_prepare(struct snd_pcm_substream
*substream)
memset(dma_params, 0, sizeof(dma_params));
if (dma_data-data_type)
- dma_params.data_type = dma_data-data_type;
+ dma_params.data_type = omap_pcm_get_dma_type(
+ dma_data-data_type);
else
dma_params.data_type = omap_pcm_get_dma_type(
snd_pcm_format_physical_width(runtime-format));
diff --git a/sound/soc/omap/omap-pcm.h b/sound/soc/omap/omap-pcm.h
index 1bf47e4..cabe74c 100644
--- a/sound/soc/omap/omap-pcm.h
+++ b/sound/soc/omap/omap-pcm.h
@@ -32,7 +32,8 @@ struct omap_pcm_dma_data {
int dma_req;/* DMA request line */
unsigned long port_addr; /* transmit/receive register */
void (*set_threshold)(struct snd_pcm_substream *substream);
- int data_type; /* data type 8,16,32 */
+ int data_type; /* 8, 16, 32 (bits) or 0 to let omap-pcm
+* to decide the sDMA data type */
int packet_size;/* packet size only in PACKET mode */
};
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 11/15] ASoC: omap-mcpdm: Use platform_get_resource_* to get resources
Get the needed resources in a correct way and avoid using defines for them.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-mcpdm.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index baf92da..f90d5de 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -71,15 +71,11 @@ struct omap_mcpdm {
static struct omap_pcm_dma_data omap_mcpdm_dai_dma_params[] = {
{
.name = Audio playback,
- .dma_req = OMAP44XX_DMA_MCPDM_DL,
.data_type = OMAP_DMA_DATA_TYPE_S32,
- .port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_REG_DN_DATA,
},
{
.name = Audio capture,
- .dma_req = OMAP44XX_DMA_MCPDM_UP,
.data_type = OMAP_DMA_DATA_TYPE_S32,
- .port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_REG_UP_DATA,
},
};
@@ -452,10 +448,33 @@ static __devinit int asoc_mcpdm_probe(struct
platform_device *pdev)
mutex_init(mcpdm-mutex);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, dma);
+ if (res == NULL)
+ return -ENOMEM;
+
+ omap_mcpdm_dai_dma_params[0].port_addr = res-start + MCPDM_REG_DN_DATA;
+ omap_mcpdm_dai_dma_params[1].port_addr = res-start + MCPDM_REG_UP_DATA;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
return -ENOMEM;
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, dn_link);
+ if (!res)
+ return -ENODEV;
+
+ omap_mcpdm_dai_dma_params[0].dma_req = res-start;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, up_link);
+ if (!res)
+ return -ENODEV;
+
+ omap_mcpdm_dai_dma_params[1].dma_req = res-start;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mpu);
+ if (res == NULL)
+ return -ENOMEM;
+
if (!devm_request_mem_region(pdev-dev, res-start,
resource_size(res), McPDM))
return -EBUSY;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 09/15] ASoC: omap-pcm: Prepare to configure the DMA data_type based on stream properties
Based on the format of the stream the omap-pcm can decide alone what data
type should be used with by the sDMA.
Keep the possibility for OMAP dai drivers to tell omap-pcm if they want to
use different data type. This is needed for the omap-hdmi for example which
needs 32bit data type even if the stream format is S16_LE.
The check if (dma_data-data_type) is safe at the moment since omap-pcm
does not support 8bit samples (OMAP_DMA_DATA_TYPE_S8 == 0x00).
The next step is to redefine the meaning of dma_data-data_type to unblock
this limitation.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-pcm.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 02eeb2e..4c13a5f 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -149,6 +149,24 @@ static int omap_pcm_hw_free(struct snd_pcm_substream
*substream)
return 0;
}
+static int omap_pcm_get_dma_type(int num_bits)
+{
+ int data_type;
+
+ switch (num_bits) {
+ case 16:
+ data_type = OMAP_DMA_DATA_TYPE_S16;
+ break;
+ case 32:
+ data_type = OMAP_DMA_DATA_TYPE_S32;
+ break;
+ default:
+ data_type = -EINVAL;
+ break;
+ }
+ return data_type;
+}
+
static int omap_pcm_prepare(struct snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime = substream-runtime;
@@ -163,7 +181,16 @@ static int omap_pcm_prepare(struct snd_pcm_substream
*substream)
return 0;
memset(dma_params, 0, sizeof(dma_params));
- dma_params.data_type= dma_data-data_type;
+
+ if (dma_data-data_type)
+ dma_params.data_type = dma_data-data_type;
+ else
+ dma_params.data_type = omap_pcm_get_dma_type(
+ snd_pcm_format_physical_width(runtime-format));
+
+ if (dma_params.data_type 0)
+ return dma_params.data_type;
+
dma_params.trigger = dma_data-dma_req;
if (dma_data-packet_size)
@@ -195,7 +222,7 @@ static int omap_pcm_prepare(struct snd_pcm_substream
*substream)
* still can get an interrupt at each period bounary
*/
bytes = snd_pcm_lib_period_bytes(substream);
- dma_params.elem_count = bytes dma_data-data_type;
+ dma_params.elem_count = bytes dma_params.data_type;
dma_params.frame_count = runtime-periods;
omap_set_dma_params(prtd-dma_ch, dma_params);
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/15] ASoC: OMAP: Convert to use dmaengine
Hello, Changes since v2: - As it has been discussed the no_wakeup parameter has been replaced with flags for the dmaengine APIs Changes since v1: - Support for pause/resume for OMAP audio via dmaengine - dmaengine: support for NO_PERIOD_WAKEUP in cyclic mode - OMAP to keep supporting NO_PERIOD_WAKEUP for audio - Other plaforms can also try to enable this mode since we have now generic interface to do so. This series will switch the OMAP audio to use dmaengine. The final patch which does the switch was based on Russell King's earlier patch. The first 10 patch is to prepare the OMAP audio drivers for a smooth change to dmaengine: - sDMA FRAME sync mode is removed and replaced with PACKET mode - dai drivers no longer need to configure sDMA sync mode - dai drivers does not need to specify the DMA word length - with the exception of the omap-hdmi driver which requires 32bit word length regardless of the audio format in use - the McPDM driver used (to my surprise) hackish way of getting the DMA channel and address - via defines from some header files After the conversion OMAP audio support should have the same features as before, no regressions expected. I have tested the series on: - BeagleBoard (audio via McBSP): - aplay/arecord. In element mode and in threshold mode with different period sizes - mplayer -ao alsa: for direct ALSA access - mplayer -ao pulse: via PulseAudio to test NO_PERIOD_WAKEUP feature - OMAP4 Blaze (audio via McPDM and DMIC) - aplay/arecord - mplayer -ao alsa: for direct ALSA access - mplayer -ao pulse: via PulseAudio to test NO_PERIOD_WAKEUP feature The patches has been generated against: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.7 Janusz: Can you retest this series on OMAP1 to be sure I have not broken it? Ricardo: Can you test the omap-hmdi if it is still working? Regards, Peter --- Peter Ujfalusi (15): dmaengine: omap: Support for element mode in cyclic DMA dmaengine: omap: Add support for pause/resume in cyclic dma mode dmaengine: Add flags parameter to dmaengine_prep_dma_cyclic() dmaengine: Pass flags via device_prep_dma_cyclic() callback dmaengine: omap-dma: Add support to suppress interrupts in cyclic mode ASoC: omap-mcbsp: Use sDMA packet mode instead of frame mode ASoC: omap-pcm: Select sDMA synchronization based on packet_size ASoC: OMAP: Remove sync_mode from omap_pcm_dma_data struct ASoC: omap-pcm: Prepare to configure the DMA data_type based on stream properties ARM: OMAP4: hwmod_data: Add resource names to McPDM memory ranges ASoC: omap-mcpdm: Use platform_get_resource_* to get resources ASoC: OMAP: mcbsp, mcpdm, dmic: Let omap-pcm to pick the dma_type ASoC: omap-pcm, omap-dmic: Change the use of omap_pcm_dma_data-data_type ASoC: OMAP: mcbsp, mcpdm, dmic, hdmi: Set dma_data at startup time ASoC: omap-pcm: Convert to use dmaengine arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 + drivers/dma/at_hdmac.c | 3 +- drivers/dma/ep93xx_dma.c | 4 +- drivers/dma/imx-dma.c | 2 +- drivers/dma/imx-sdma.c | 2 +- drivers/dma/mmp_tdma.c | 2 +- drivers/dma/mxs-dma.c | 2 +- drivers/dma/omap-dma.c | 45 -- drivers/dma/pl330.c| 2 +- drivers/dma/sa11x0-dma.c | 2 +- drivers/dma/sirf-dma.c | 2 +- drivers/dma/ste_dma40.c| 3 +- drivers/dma/tegra20-apb-dma.c | 2 +- include/linux/dmaengine.h | 7 +- sound/soc/omap/Kconfig | 3 +- sound/soc/omap/omap-dmic.c | 9 +- sound/soc/omap/omap-hdmi.c | 17 ++- sound/soc/omap/omap-mcbsp.c| 60 +++- sound/soc/omap/omap-mcpdm.c| 40 +++-- sound/soc/omap/omap-pcm.c | 236 - sound/soc/omap/omap-pcm.h | 4 +- sound/soc/soc-dmaengine-pcm.c | 6 +- 22 files changed, 186 insertions(+), 269 deletions(-) -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 02/15] dmaengine: omap: Add support for pause/resume in cyclic dma mode
The audio stack used omap_stop_dma/omap_start_dma to pause/resume the DMA.
This method has been used for years on OMAP based products.
We only allow pause/resume when the DMA has been configured in cyclic mode
which is used by the audio stack.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/omap-dma.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index b77a40d..71d7869 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -34,6 +34,7 @@ struct omap_chan {
struct dma_slave_config cfg;
unsigned dma_sig;
bool cyclic;
+ bool paused;
int dma_ch;
struct omap_desc *desc;
@@ -470,11 +471,14 @@ static int omap_dma_terminate_all(struct omap_chan *c)
*/
if (c-desc) {
c-desc = NULL;
- omap_stop_dma(c-dma_ch);
+ /* Avoid stopping the dma twice */
+ if (!c-paused)
+ omap_stop_dma(c-dma_ch);
}
if (c-cyclic) {
c-cyclic = false;
+ c-paused = false;
omap_dma_unlink_lch(c-dma_ch, c-dma_ch);
}
@@ -487,14 +491,30 @@ static int omap_dma_terminate_all(struct omap_chan *c)
static int omap_dma_pause(struct omap_chan *c)
{
- /* FIXME: not supported by platform private API */
- return -EINVAL;
+ /* Pause/Resume only allowed with cyclic mode */
+ if (!c-cyclic)
+ return -EINVAL;
+
+ if (!c-paused) {
+ omap_stop_dma(c-dma_ch);
+ c-paused = true;
+ }
+
+ return 0;
}
static int omap_dma_resume(struct omap_chan *c)
{
- /* FIXME: not supported by platform private API */
- return -EINVAL;
+ /* Pause/Resume only allowed with cyclic mode */
+ if (!c-cyclic)
+ return -EINVAL;
+
+ if (c-paused) {
+ omap_start_dma(c-dma_ch);
+ c-paused = false;
+ }
+
+ return 0;
}
static int omap_dma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/15] dmaengine: Pass flags via device_prep_dma_cyclic() callback
Change the parameter list of device_prep_dma_cyclic() so the DMA drivers
can receive the flags coming from clients.
This feature can be used during audio operation to disable all audio
related interrupts when the DMA_PREP_INTERRUPT is cleared from the flags.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Nicolas Ferre nicolas.fe...@atmel.com
CC: Barry Song baohua.s...@csr.com
CC: Srinidhi Kasagar srinidhi.kasa...@stericsson.com
CC: Russell King - ARM Linux li...@arm.linux.org.uk
CC: Vista Silicon javier.mar...@vista-silicon.com
CC: Zhangfei Gao zhangfei@marvell.com
CC: Shawn Guo shawn@linaro.org
CC: Laxman Dewangan ldewan...@nvidia.com
---
drivers/dma/at_hdmac.c| 3 ++-
drivers/dma/ep93xx_dma.c | 4 +++-
drivers/dma/imx-dma.c | 2 +-
drivers/dma/imx-sdma.c| 2 +-
drivers/dma/mmp_tdma.c| 2 +-
drivers/dma/mxs-dma.c | 2 +-
drivers/dma/omap-dma.c| 3 ++-
drivers/dma/pl330.c | 2 +-
drivers/dma/sa11x0-dma.c | 2 +-
drivers/dma/sirf-dma.c| 2 +-
drivers/dma/ste_dma40.c | 3 ++-
drivers/dma/tegra20-apb-dma.c | 2 +-
include/linux/dmaengine.h | 4 ++--
13 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 3934fcc..7e5f6b6 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -841,12 +841,13 @@ atc_dma_cyclic_fill_desc(struct dma_chan *chan, struct
at_desc *desc,
* @buf_len: total number of bytes for the entire buffer
* @period_len: number of bytes for each period
* @direction: transfer direction, to or from device
+ * @flags: tx descriptor status flags
* @context: transfer context (ignored)
*/
static struct dma_async_tx_descriptor *
atc_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction,
- void *context)
+ unsigned long flags, void *context)
{
struct at_dma_chan *atchan = to_at_dma_chan(chan);
struct at_dma_slave *atslave = chan-private;
diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
index c64917e..493735b 100644
--- a/drivers/dma/ep93xx_dma.c
+++ b/drivers/dma/ep93xx_dma.c
@@ -1120,6 +1120,7 @@ fail:
* @buf_len: length of the buffer (in bytes)
* @period_len: lenght of a single period
* @dir: direction of the operation
+ * @flags: tx descriptor status flags
* @context: operation context (ignored)
*
* Prepares a descriptor for cyclic DMA operation. This means that once the
@@ -1133,7 +1134,8 @@ fail:
static struct dma_async_tx_descriptor *
ep93xx_dma_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t dma_addr,
size_t buf_len, size_t period_len,
- enum dma_transfer_direction dir, void *context)
+ enum dma_transfer_direction dir, unsigned long flags,
+ void *context)
{
struct ep93xx_dma_chan *edmac = to_ep93xx_dma_chan(chan);
struct ep93xx_dma_desc *desc, *first;
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 5084975..41b4376 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -801,7 +801,7 @@ static struct dma_async_tx_descriptor *imxdma_prep_slave_sg(
static struct dma_async_tx_descriptor *imxdma_prep_dma_cyclic(
struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction,
- void *context)
+ unsigned long flags, void *context)
{
struct imxdma_channel *imxdmac = to_imxdma_chan(chan);
struct imxdma_engine *imxdma = imxdmac-imxdma;
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 1dc2a4a..2c5fd3e 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1012,7 +1012,7 @@ err_out:
static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction,
- void *context)
+ unsigned long flags, void *context)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac-sdma;
diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c
index 8a15cf2..6d52bd4 100644
--- a/drivers/dma/mmp_tdma.c
+++ b/drivers/dma/mmp_tdma.c
@@ -358,7 +358,7 @@ struct mmp_tdma_desc *mmp_tdma_alloc_descriptor(struct
mmp_tdma_chan *tdmac)
static struct dma_async_tx_descriptor *mmp_tdma_prep_dma_cyclic(
struct dma_chan *chan, dma_addr_t dma_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction,
- void *context)
+ unsigned long flags, void *context)
{
struct mmp_tdma_chan *tdmac = to_mmp_tdma_chan(chan);
struct mmp_tdma_desc *desc;
diff --git
[PATCH v3 03/15] dmaengine: Add flags parameter to dmaengine_prep_dma_cyclic()
With this parameter added to dmaengine_prep_dma_cyclic() the API will be in
sync with other dmaengine_prep_*() functions.
The dmaengine_prep_dma_cyclic() function primarily used by audio for cyclic
transfer required by ALSA, we use the from audio to ask dma drivers to
suppress interrupts (if DMA_PREP_INTERRUPT is cleared) when it is supported
on the platform.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Lars-Peter Clausen l...@metafoo.de
---
include/linux/dmaengine.h | 3 ++-
sound/soc/soc-dmaengine-pcm.c | 6 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9c02a45..2abcac5 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -653,7 +653,8 @@ static inline struct dma_async_tx_descriptor
*dmaengine_prep_rio_sg(
static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_cyclic(
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
- size_t period_len, enum dma_transfer_direction dir)
+ size_t period_len, enum dma_transfer_direction dir,
+ unsigned long flags)
{
return chan-device-device_prep_dma_cyclic(chan, buf_addr, buf_len,
period_len, dir, NULL);
diff --git a/sound/soc/soc-dmaengine-pcm.c b/sound/soc/soc-dmaengine-pcm.c
index 5df529e..bbc1257 100644
--- a/sound/soc/soc-dmaengine-pcm.c
+++ b/sound/soc/soc-dmaengine-pcm.c
@@ -140,14 +140,18 @@ static int dmaengine_pcm_prepare_and_submit(struct
snd_pcm_substream *substream)
struct dma_chan *chan = prtd-dma_chan;
struct dma_async_tx_descriptor *desc;
enum dma_transfer_direction direction;
+ unsigned long flags = DMA_CTRL_ACK;
direction = snd_pcm_substream_to_dma_direction(substream);
+ if (!substream-runtime-no_period_wakeup)
+ flags |= DMA_PREP_INTERRUPT;
+
prtd-pos = 0;
desc = dmaengine_prep_dma_cyclic(chan,
substream-runtime-dma_addr,
snd_pcm_lib_buffer_bytes(substream),
- snd_pcm_lib_period_bytes(substream), direction);
+ snd_pcm_lib_period_bytes(substream), direction, flags);
if (!desc)
return -ENOMEM;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/15] ASoC: OMAP: Remove sync_mode from omap_pcm_dma_data struct
The omap-pcm platform driver no longer needs this parameter to select
between ELEMENT and PACKET mode. The selection is based on the configured
packet_size.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-dmic.c | 1 -
sound/soc/omap/omap-hdmi.c | 1 -
sound/soc/omap/omap-mcbsp.c | 5 +
sound/soc/omap/omap-mcpdm.c | 2 --
sound/soc/omap/omap-pcm.h | 1 -
5 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 75f5dca..60b7b8c 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -64,7 +64,6 @@ struct omap_dmic {
static struct omap_pcm_dma_data omap_dmic_dai_dma_params = {
.name = DMIC capture,
.data_type = OMAP_DMA_DATA_TYPE_S32,
- .sync_mode = OMAP_DMA_SYNC_PACKET,
};
static inline void omap_dmic_write(struct omap_dmic *dmic, u16 reg, u32 val)
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index a08245d..b194646 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -290,7 +290,6 @@ static __devinit int omap_hdmi_probe(struct platform_device
*pdev)
hdmi_data-dma_params.dma_req = hdmi_rsrc-start;
hdmi_data-dma_params.name = HDMI playback;
- hdmi_data-dma_params.sync_mode = OMAP_DMA_SYNC_PACKET;
/*
* TODO: We assume that there is only one DSS HDMI device. Future
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index fe3debc..5b3bacc 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -225,7 +225,7 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
struct omap_mcbsp *mcbsp = snd_soc_dai_get_drvdata(cpu_dai);
struct omap_mcbsp_reg_cfg *regs = mcbsp-cfg_regs;
struct omap_pcm_dma_data *dma_data;
- int wlen, channels, wpf, sync_mode = OMAP_DMA_SYNC_ELEMENT;
+ int wlen, channels, wpf;
int pkt_size = 0;
unsigned int format, div, framesize, master;
@@ -272,15 +272,12 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
return -EINVAL;
pkt_size = period_words / divider;
- sync_mode = OMAP_DMA_SYNC_PACKET;
} else if (channels 1) {
/* Use packet mode for non mono streams */
pkt_size = channels;
- sync_mode = OMAP_DMA_SYNC_PACKET;
}
}
- dma_data-sync_mode = sync_mode;
dma_data-packet_size = pkt_size;
snd_soc_dai_set_dma_data(cpu_dai, substream, dma_data);
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index f7babb3..baf92da 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -73,14 +73,12 @@ static struct omap_pcm_dma_data omap_mcpdm_dai_dma_params[]
= {
.name = Audio playback,
.dma_req = OMAP44XX_DMA_MCPDM_DL,
.data_type = OMAP_DMA_DATA_TYPE_S32,
- .sync_mode = OMAP_DMA_SYNC_PACKET,
.port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_REG_DN_DATA,
},
{
.name = Audio capture,
.dma_req = OMAP44XX_DMA_MCPDM_UP,
.data_type = OMAP_DMA_DATA_TYPE_S32,
- .sync_mode = OMAP_DMA_SYNC_PACKET,
.port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_REG_UP_DATA,
},
};
diff --git a/sound/soc/omap/omap-pcm.h b/sound/soc/omap/omap-pcm.h
index b92248c..1bf47e4 100644
--- a/sound/soc/omap/omap-pcm.h
+++ b/sound/soc/omap/omap-pcm.h
@@ -33,7 +33,6 @@ struct omap_pcm_dma_data {
unsigned long port_addr; /* transmit/receive register */
void (*set_threshold)(struct snd_pcm_substream *substream);
int data_type; /* data type 8,16,32 */
- int sync_mode; /* DMA sync mode */
int packet_size;/* packet size only in PACKET mode */
};
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 07/15] ASoC: omap-pcm: Select sDMA synchronization based on packet_size
Since we only have element or packet synchronization we can use the
dma_data-packet_size to select the desired mode:
if packet_size is 0 we use ELEMENT mode
if packet_size is not 0 we use PACKET mode for sDMA synchronization.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/omap-pcm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index f0feb06..02eeb2e 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -165,7 +165,12 @@ static int omap_pcm_prepare(struct snd_pcm_substream
*substream)
memset(dma_params, 0, sizeof(dma_params));
dma_params.data_type= dma_data-data_type;
dma_params.trigger = dma_data-dma_req;
- dma_params.sync_mode= dma_data-sync_mode;
+
+ if (dma_data-packet_size)
+ dma_params.sync_mode = OMAP_DMA_SYNC_PACKET;
+ else
+ dma_params.sync_mode = OMAP_DMA_SYNC_ELEMENT;
+
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) {
dma_params.src_amode= OMAP_DMA_AMODE_POST_INC;
dma_params.dst_amode= OMAP_DMA_AMODE_CONSTANT;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/15] dmaengine: omap: Support for element mode in cyclic DMA
When src_maxburst/dst_maxburst is set to 0 by the users of cyclic DMA (mostly audio) indicates that we should configure the omap DMA to element sync mode instead of packet mode. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com CC: Russell King rmk+ker...@arm.linux.org.uk --- drivers/dma/omap-dma.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index ae05618..b77a40d 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -413,7 +413,10 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic( d-dev_addr = dev_addr; d-fi = burst; d-es = es; - d-sync_mode = OMAP_DMA_SYNC_PACKET; + if (burst) + d-sync_mode = OMAP_DMA_SYNC_PACKET; + else + d-sync_mode = OMAP_DMA_SYNC_ELEMENT; d-sync_type = sync_type; d-periph_port = OMAP_DMA_PORT_MPUI; d-sg[0].addr = buf_addr; -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/4] i2c: introduce i2c-cbus driver
On Fri, Sep 14, 2012 at 12:08:06PM +0200, Wolfram Sang wrote: On Mon, Sep 03, 2012 at 11:23:22PM +0300, Aaro Koskinen wrote: Add i2c driver to enable access to devices behind CBUS on Nokia Internet Tablets. The patch also adds CBUS I2C configuration for N8x0 which is one of the users of this driver. Cc: linux-...@vger.kernel.org Acked-by: Felipe Balbi ba...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi OK, I found the short paragrahp about CBUS in the I2C spec, so I2C might be an appropriate place. Still, before deciding if it should rather be in the core directory, I still have a few questions. Also, does anybody know of a generic bit-banging implementation in the kernel which could be used here? there is i2c-gpio, but it wouldn't help much for cbus, unless we change it quite a lot. The generic i2c_algo_bit_data would have to be changed to learn about a 3 wire bus. I guess the impact is much bigger than just accepting this small, self-contained driver. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH] drivers: phy: add generic PHY framework
On 09/14/2012 01:58 PM, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of API's for the PHY drivers to
create/remove a PHY and the PHY users to obtain a reference to the PHY
using or without using phandle. If the PHY users has to obtain a reference to
the PHY without using phandle, the platform specfic intialization code (say
from board file) should have already called phy_bind with the binding
information. The binding information consists of phy's device name, phy
user device name and an index. The index is used when the same phy user
binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
information about the PHY and ops like init, exit, suspend, resume,
poweron, shutdown.
Some comments inside.
While looking over the code, I was thinking why not abstract the phy
with a bus in the linux kernel. The ethernet phys are on the mdio_bus,
see /sys/bus/mdio_bus. This saves you hand crafting devices, drivers and
bindings,
Marc
Nyet-signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
This framework is actually intended to be used by all the PHY drivers in the
kernel. Though it's going to take a while for that, I intend to migrate
existing USB/OTG phy drivers to use this framework as we align on the design
of this framework. Once I migrate these phy drivers, I'll be able to test this
framework (I haven't tested this framework so far). I sent this patch early
so as to get review comments and align on the design. Thanks :-)
drivers/Kconfig |2 +
drivers/Makefile|2 +
drivers/phy/Kconfig | 13 ++
drivers/phy/Makefile|5 +
drivers/phy/phy-core.c | 437
+++
include/linux/phy/phy.h | 181
6 files changed, 640 insertions(+)
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ece958d..8488818 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -152,4 +152,6 @@ source drivers/vme/Kconfig
source drivers/pwm/Kconfig
+source drivers/phy/Kconfig
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 5b42184..63d6bbe 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -38,6 +38,8 @@ obj-y += char/
# gpu/ comes after char for AGP vs DRM startup
obj-y+= gpu/
+obj-y+= phy/
+
obj-$(CONFIG_CONNECTOR) += connector/
# i810fb and intelfb depend on char/agp/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 000..34f7077
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+ tristate Generic PHY Support
+ help
+ Generic PHY support.
+
+ This framework is designed to provide a generic interface for PHY
+ devices present in the kernel. This layer will have the generic
+ API by which phy drivers can create PHY using the phy framework and
+ phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 000..c55446a
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,437 @@
+/*
+ * phy-core.c -- Generic Phy framework.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/err.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/phy/phy.h
+
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
What
USB problem on beagleboard clone
Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. Cheers and thanks, Maximilian Schwerin. __ Maximilian Schwerin | maximilian.schwe...@tigris.de Tigris Elektronik GmbH | Wikingerufer 7 | 10555 Berlin, Germany | http://www.tigris.de Tel: +49 (30) 301048-30 | Fax: +49 (30) 301048-59 Geschäftsführer/CEO: Henry Westphal, Guido Kuhlmann Sitz der Gesellschaft/Company's registered office: Berlin Amtsgericht/Register: Berlin-Charlottenburg, HRB 71737 PGP-Keys: mailto:p...@tigris.de __ pgpUpCRHLd8B2.pgp Description: PGP signature
AW: USB problem on beagleboard clone
Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-omap@vger.kernel.org; linux-...@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. Cheers and thanks, Maximilian Schwerin. USB_failures.log Description: USB_failures.log pgpPoNLPiFZTx.pgp Description: PGP signature
Re: [RFC PATCH] drivers: phy: add generic PHY framework
Hi, On Fri, Sep 14, 2012 at 5:58 PM, Marc Kleine-Budde m...@pengutronix.de wrote: On 09/14/2012 01:58 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of API's for the PHY drivers to create/remove a PHY and the PHY users to obtain a reference to the PHY using or without using phandle. If the PHY users has to obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has information about the PHY and ops like init, exit, suspend, resume, poweron, shutdown. Some comments inside. While looking over the code, I was thinking why not abstract the phy with a bus in the linux kernel. The ethernet phys are on the mdio_bus, see /sys/bus/mdio_bus. This saves you hand crafting devices, drivers and bindings, well... have to think about it. Marc Nyet-signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- This framework is actually intended to be used by all the PHY drivers in the kernel. Though it's going to take a while for that, I intend to migrate existing USB/OTG phy drivers to use this framework as we align on the design of this framework. Once I migrate these phy drivers, I'll be able to test this framework (I haven't tested this framework so far). I sent this patch early so as to get review comments and align on the design. Thanks :-) drivers/Kconfig |2 + drivers/Makefile|2 + drivers/phy/Kconfig | 13 ++ drivers/phy/Makefile|5 + drivers/phy/phy-core.c | 437 +++ include/linux/phy/phy.h | 181 6 files changed, 640 insertions(+) create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h diff --git a/drivers/Kconfig b/drivers/Kconfig index ece958d..8488818 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -152,4 +152,6 @@ source drivers/vme/Kconfig source drivers/pwm/Kconfig +source drivers/phy/Kconfig + endmenu diff --git a/drivers/Makefile b/drivers/Makefile index 5b42184..63d6bbe 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -38,6 +38,8 @@ obj-y += char/ # gpu/ comes after char for AGP vs DRM startup obj-y+= gpu/ +obj-y+= phy/ + obj-$(CONFIG_CONNECTOR) += connector/ # i810fb and intelfb depend on char/agp/ diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig new file mode 100644 index 000..34f7077 --- /dev/null +++ b/drivers/phy/Kconfig @@ -0,0 +1,13 @@ +# +# PHY +# + +menuconfig GENERIC_PHY + tristate Generic PHY Support + help + Generic PHY support. + + This framework is designed to provide a generic interface for PHY + devices present in the kernel. This layer will have the generic + API by which phy drivers can create PHY using the phy framework and + phy users can obtain reference to the PHY. diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile new file mode 100644 index 000..9e9560f --- /dev/null +++ b/drivers/phy/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the phy drivers. +# + +obj-$(CONFIG_GENERIC_PHY)+= phy-core.o diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c new file mode 100644 index 000..c55446a --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,437 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2012 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. + */ + +#include linux/kernel.h +#include linux/export.h +#include linux/module.h +#include linux/err.h +#include linux/device.h +#include linux/slab.h +#include linux/of.h +#include linux/phy/phy.h + +static struct class *phy_class; +static LIST_HEAD(phy_list); +static DEFINE_MUTEX(phy_list_mutex); +static LIST_HEAD(phy_bind_list); + +static
Re: USB problem on beagleboard clone
Hi, On Fri, Sep 14, 2012 at 02:57:49PM +0200, Maximilian Schwerin wrote: Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-omap@vger.kernel.org; linux-...@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? -- balbi signature.asc Description: Digital signature
Re: USB problem on beagleboard clone
Hi again, On Fri, Sep 14, 2012 at 04:07:56PM +0300, Felipe Balbi wrote: On Fri, Sep 14, 2012 at 02:57:49PM +0200, Maximilian Schwerin wrote: Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-omap@vger.kernel.org; linux-...@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? Which kernel are you using ? Have you tried with v3.5 or something more recent ? -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH] drivers: phy: add generic PHY framework
On Fri, Sep 14, 2012 at 02:28:19PM +0200, Marc Kleine-Budde wrote: On 09/14/2012 01:58 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of API's for the PHY drivers to create/remove a PHY and the PHY users to obtain a reference to the PHY using or without using phandle. If the PHY users has to obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has information about the PHY and ops like init, exit, suspend, resume, poweron, shutdown. Some comments inside. While looking over the code, I was thinking why not abstract the phy with a bus in the linux kernel. The ethernet phys are on the mdio_bus, see /sys/bus/mdio_bus. This saves you hand crafting devices, drivers and bindings, I don't think that's a good idea, actually. You can have USB PHYs which are memory mapped, or connected through i2c, or connected through any other bus. If the PHYs layer itself is a bus, it means we will need to register a device on two different buses, which doesn't sound very nice IMHO. -- balbi signature.asc Description: Digital signature
AW: USB problem on beagleboard clone
Hi, -Ursprüngliche Nachricht- Von: Felipe Balbi [mailto:ba...@ti.com] Gesendet: Freitag, 14. September 2012 15:08 An: Maximilian Schwerin Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org Betreff: Re: USB problem on beagleboard clone (PGP: Plain, Unable to verify signature) Hi, On Fri, Sep 14, 2012 at 02:57:49PM +0200, Maximilian Schwerin wrote: Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-omap@vger.kernel.org; linux-...@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? -- balbi I'm still on 3.3 but am planing to go to a newer version. We used the OTG port so we would not need another chip on a rather small board. Cheers, m. pgphoIEku5XmZ.pgp Description: PGP signature
Re: USB problem on beagleboard clone
On Fri, Sep 14, 2012 at 03:21:47PM +0200, Maximilian Schwerin wrote: Hi, -Ursprüngliche Nachricht- Von: Felipe Balbi [mailto:ba...@ti.com] Gesendet: Freitag, 14. September 2012 15:08 An: Maximilian Schwerin Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org Betreff: Re: USB problem on beagleboard clone (PGP: Plain, Unable to verify signature) Hi, On Fri, Sep 14, 2012 at 02:57:49PM +0200, Maximilian Schwerin wrote: Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-omap@vger.kernel.org; linux-...@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? -- balbi I'm still on 3.3 but am planing to go to a newer version. We used the OTG port so we would not need another chip on a rather small board. And which chip are you talking about ? You already have LAN9514 on your board anyway... -- balbi signature.asc Description: Digital signature
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
Hi Arnd,
On 09/14/2012 04:43 AM, Arnd Bergmann wrote:
On Thursday 13 September 2012, Jon Hunter wrote:
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
I think we're getting very close now, I only have a few small comments left
that should all be uncontroversial.
+
+Client drivers should specify the DMA property using a phandle to the
controller
+followed by DMA controller specific data.
+
+Required property:
+- dmas: List of one or more DMA specifiers, each
consisting of
+- A phandle pointing to DMA controller node
+- A single integer cell containing DMA controller
+ specific information. This typically contains a dma
+ request line number or a channel number, but can
+ contain any data that is used required for configuring
+ a channel.
+- dma-names:Contains one identifier string for each dma
specifier in
+the dmas property. The specific strings that can be used
+are defined in the binding of the DMA client device.
I think here we need to clarify that listing the same name multiple times
implies
having multiple alternatives for the same channel.
Ok, however, the way it works right now is that we will use the first
specifier that matches the name. So if there are multiple with the same
name that would imply that someone will need call the
xxx_request_slave_channel() multiple times to extract these. Is that ok?
+Example:
+
+- One DMA write channel, one DMA read/write channel:
+
+i2c1: i2c@1 {
+...
+dmas = sdma 2 /* read channel */
+sdma 3; /* write channel */
+dma-names = rx, tx
+...
+};
And please add an example documenting this case.
Ok.
+/**
+ * of_dma_find_channel - Find a DMA channel by name
+ * @np: device node to look for DMA channels
+ * @name: name of desired channel
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ *
+ * Find a DMA channel by the name. Returns 0 on success or appropriate
+ * errno value on error.
+ */
+static int of_dma_find_channel(struct device_node *np, char *name,
+ struct of_phandle_args *dma_spec)
+{
+int count, i;
+const char *s;
+
+count = of_property_count_strings(np, dma-names);
+if (count 0)
+return count;
+
+for (i = 0; i count; i++) {
+of_property_read_string_index(np, dma-names, i, s);
+
+if (strcmp(name, s))
+continue;
+
+return of_parse_phandle_with_args(np, dmas, #dma-cells,
+i, dma_spec);
+}
+
+return -ENODEV;
+}
I think we should at least keep trying the other channels with the same name
when
of_parse_phandle_with_args fails. We might want to do something smarter in
the long run, e.g. to spread channel allocations across the avaialable
controllers.
Ok, can add this.
+/**
+ * of_dma_request_slave_channel - Get the DMA slave channel
+ * @np: device node to get DMA request from
+ * @name: name of desired channel
+ *
+ * Returns pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
+ char *name)
+{
...
+}
+EXPORT_SYMBOL_GPL(of_dma_request_slave_channel);
I think this no longer needs to be exported, with patch 2 on top.
Right, I was in two minds but I can remove this.
+/**
+ * of_dma_simple_xlate - Simple DMA engine translation function
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ * @of_dma: pointer to DMA controller data
+ *
+ * A simple translation function for devices that use a 32-bit value for the
+ * filter_param when calling the DMA engine dma_request_channel() function.
+ * Note that this translation function requires that #dma-cells is equal to
1
+ * and the argument of the dma specifier is the 32-bit filter_param. Returns
+ * pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
+struct of_dma *ofdma)
+{
+int count = dma_spec-args_count;
+struct of_dma_filter_info *info = ofdma-of_dma_data;
+
+if (!info || !info-filter_fn)
+return NULL;
+
+if (count != 1)
+return NULL;
+
+return dma_request_channel(info-dma_cap, info-filter_fn,
+dma_spec-args[0]);
+}
But this one does.
Good catch!
Thanks
Jon
--
To unsubscribe from this list:
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
On Friday 14 September 2012, Jon Hunter wrote: On 09/14/2012 04:43 AM, Arnd Bergmann wrote: + +Client drivers should specify the DMA property using a phandle to the controller +followed by DMA controller specific data. + +Required property: +- dmas: List of one or more DMA specifiers, each consisting of + - A phandle pointing to DMA controller node + - A single integer cell containing DMA controller +specific information. This typically contains a dma +request line number or a channel number, but can +contain any data that is used required for configuring +a channel. +- dma-names: Contains one identifier string for each dma specifier in + the dmas property. The specific strings that can be used + are defined in the binding of the DMA client device. I think here we need to clarify that listing the same name multiple times implies having multiple alternatives for the same channel. Ok, however, the way it works right now is that we will use the first specifier that matches the name. So if there are multiple with the same name that would imply that someone will need call the xxx_request_slave_channel() multiple times to extract these. Is that ok? I would expect a driver to only call the function once, and get something back from the dmaengine layer that works. If there are two controllers to choose from and one is busy, then it should definitely give a channel from the non-busy one. It's not much of an issue if the code doesn't handle all corner cases at first, but I would expect that the binding correctly describes how to write a device tree that will work once the code implements it correctly. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 08:32 AM, Arnd Bergmann wrote:
On Friday 14 September 2012, Jon Hunter wrote:
On 09/14/2012 04:43 AM, Arnd Bergmann wrote:
+
+Client drivers should specify the DMA property using a phandle to the
controller
+followed by DMA controller specific data.
+
+Required property:
+- dmas: List of one or more DMA specifiers, each
consisting of
+ - A phandle pointing to DMA controller node
+ - A single integer cell containing DMA controller
+specific information. This typically contains a dma
+request line number or a channel number, but can
+contain any data that is used required for configuring
+a channel.
+- dma-names: Contains one identifier string for each dma
specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
I think here we need to clarify that listing the same name multiple times
implies
having multiple alternatives for the same channel.
Ok, however, the way it works right now is that we will use the first
specifier that matches the name. So if there are multiple with the same
name that would imply that someone will need call the
xxx_request_slave_channel() multiple times to extract these. Is that ok?
I would expect a driver to only call the function once, and get something
back from the dmaengine layer that works. If there are two controllers
to choose from and one is busy, then it should definitely give a channel
from the non-busy one.
It's not much of an issue if the code doesn't handle all corner cases at
first, but I would expect that the binding correctly describes how to write
a device tree that will work once the code implements it correctly.
Gotcha, may be something like the following should work then ...
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index 4025f2f..de59611 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -127,13 +127,15 @@ static int of_dma_find_channel(struct device_node *np,
char *name,
return count;
for (i = 0; i count; i++) {
- of_property_read_string_index(np, dma-names, i, s);
+ if (of_property_read_string_index(np, dma-names, i, s))
+ continue;
if (strcmp(name, s))
continue;
- return of_parse_phandle_with_args(np, dmas, #dma-cells,
- i, dma_spec);
+ if (!of_parse_phandle_with_args(np, dmas, #dma-cells, i,
+ dma_spec))
+ return 0;
}
return -ENODEV;
@@ -159,33 +161,34 @@ struct dma_chan *of_dma_request_slave_channel(struct
device_node *np,
return NULL;
}
- r = of_dma_find_channel(np, name, dma_spec);
-
- if (r) {
- pr_err(%s: can't find DMA channel\n, np-full_name);
- return NULL;
- }
+ do {
+ r = of_dma_find_channel(np, name, dma_spec);
+ if (r) {
+ pr_err(%s: can't find DMA channel\n, np-full_name);
+ return NULL;
+ }
+
+ ofdma = of_dma_find_controller(dma_spec.np);
+ if (!ofdma) {
+ pr_debug(%s: can't find DMA controller %s\n,
+ np-full_name, dma_spec.np-full_name);
+ continue;
+ }
- ofdma = of_dma_find_controller(dma_spec.np);
- if (!ofdma) {
- pr_err(%s: can't find DMA controller %s\n, np-full_name,
- dma_spec.np-full_name);
- return NULL;
- }
+ if (dma_spec.args_count != ofdma-of_dma_nbcells) {
+ pr_debug(%s: wrong #dma-cells for %s\n, np-full_name,
+ dma_spec.np-full_name);
+ continue;
+ }
- if (dma_spec.args_count != ofdma-of_dma_nbcells) {
- pr_err(%s: wrong #dma-cells for %s\n, np-full_name,
- dma_spec.np-full_name);
- return NULL;
- }
+ chan = ofdma-of_dma_xlate(dma_spec, ofdma);
- chan = ofdma-of_dma_xlate(dma_spec, ofdma);
+ of_node_put(dma_spec.np);
- of_node_put(dma_spec.np);
+ } while (!chan);
return chan;
}
-EXPORT_SYMBOL_GPL(of_dma_request_slave_channel);
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RTC: TWL: ensure all interrupts are disabled during probe
Shubhrajyoti Datta omaplinuxker...@gmail.com writes: Hi Kevin, On Fri, Sep 14, 2012 at 2:15 AM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Kevin Hilman khil...@ti.com On some platforms, bootloaders are known to do some interesting RTC programming. Without going into the obscurities as to why this may be the case, suffice it to say the the driver should not make any assumptions about the state of the RTC when the driver loads. In particular, the driver probe should be sure that all interrupts are disabled until otherwise programmed. This was discovered when finding bursty I2C traffic every second on Overo platforms. This I2C overhead was keeping the SoC from hitting deep power states. The cause was found to be the RTC firing every second on the I2C-connected TWL PMIC. Special thanks to Felipe Balbi for suggesting to look for a rogue driver as the source of the I2C traffic rather than the I2C driver itself. Special thanks to Steve Sakoman for helping track down the source of the continuous RTC interrups on the Overo boards. Tested that the continuous interrupt issue after doing a i2c mm on omap4sdp. This patch solves the issue. thanks, Cc: Felipe Balbi ba...@ti.com Cc: Steve Sakoman st...@sakoman.com Signed-off-by: Kevin Hilman khil...@ti.com --- Patch applies to v3.6-rc5 drivers/rtc/rtc-twl.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c index c5d06fe..9277d94 100644 --- a/drivers/rtc/rtc-twl.c +++ b/drivers/rtc/rtc-twl.c @@ -495,6 +495,11 @@ static int __devinit twl_rtc_probe(struct platform_device *pdev) if (ret 0) goto out1; + /* ensure interrupts are disabled, bootloaders can be strange */ + ret = twl_rtc_write_u8(0, REG_RTC_INTERRUPTS_REG); + if (ret 0) + dev_warn(pdev-dev, unable to disable interrupt\n); + Now that it is always 0 can the below read be removed as it is redundant now. Possibly, but I don't know this HW well enough to know if there are any persistent bits in that register on any of the various derivations of this PMIC. Since this read-back value is used throughout the driver, I decided not to mess with it when doing this targetted fix. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Converting OMAP's custom vram allocator
Hello, On Friday, September 07, 2012 12:55 PM Tomi Valkeinen wrote: On Fri, 2012-09-07 at 07:55 +0200, Marek Szyprowski wrote: Hello, On Wednesday, September 05, 2012 12:09 PM Tomi Valkeinen wrote: OMAP has a custom video ram allocator, which I'd like to remove and use the standard dma allocation functions. There are two problems for which I'd like to hear suggestions or comments: First one is that the dma_alloc_* functions map the allocated memory for cpu use. In many cases with OMAP DSS (display subsystem) this is not needed: the memory may be written only by the SGX or the DSP, and it's only read by the DSS, so it's never touched by the CPU. This is even more true when using VRFB on omap3 (and probably TILER on omap4) for rotation, as VRFB hides the actual memory and offers rotated views. In this case the backend memory is never accessed by anyone else than VRFB. Is there a way to allocate the memory without creating a mapping? While it won't break anything as such, the allocated areas can be quite large thus causing large areas of the kernel's memory space to be needlessly reserved. Please check commits d5724f172fd1 and 955c757e090 merged to v3.6-rc1. Support for this attribute is now only available in IOMMU-aware dma-mapping implementation, but I plan to add it also to standard linear ARM dma-mapping implementation based on alloc_pages_exact(). Ok, good to know. Do you have any guestimate when the non-iommu version could end up in the mainline? Any chance for 3.7? I volunteer for testing if needed =). Well, I'm not sure if I manage to have it ready for 3.7. I was very busy this week and now I'm just leaving the office for my vacations and I wonder if I manage to work on it just after getting back... Feel free to provide a patch which add such feature, then I will schedule it for inclusion to mainline. Some not-well-documented example can be found here: https://patchwork.kernel.org/patch/1323591/ (at the bottom). You probably might need to add your own custom dma_map_ops set of functions for TILER device, but I'm not really sure if I get right what does that device do and what will be the use cases for it. I think we have three different cases how we need to manage the memory used for video on OMAP. 1) Conventional case, without VRFB/TILER. We need large contiguous areas. I think we usually want both normal kernel and userspace mapping in this case, although some use cases could not need those. 2) VRFB (omap3). In this case we need large contigous area, which is given to the VRFB hardware to be used as a storage. This area is never mapped. VRFB offers four rotated views (i.e. memory areas), which give a 0/90/180/270 degree view of the same image, and we will create mapping of these views with ioremap. The actual data is stored in the memory by VRFB in a proprietary format. 3) TILER (omap4). I'm not too familiar with TILER, but afaik it's kinda like a better version of VRFB. In this case we don't need contiguous memory, but like VRFB, we never create mapping for the memory. (Rob, correct me if I'm wrong). I think we can manage all of those with dma_alloc_attrs(), even though contiguous area is not really needed for TILER. dma_alloc_attrs()/dma_alloc_coherent() plays with memory which is contiguous in the dma (io) address space. It doesn't need to be contiguous in physical memory if device has iommu (or iommu-like physical memory interface). So, if I define DMA_ATTR_NO_KERNEL_MAPPING, there's no point in defining DMA_ATTR_WRITE_COMBINE at the same time, right? Yes and no. It might be useful for creating userspace mappings on systems which support write-combining. Please note that attributes which are not supported by some systems are simply ignored. So if driver specifies both, some systems might benefit from using NO_KERNEL_MAPPING, the other will benefit from WRITE_COMBINE mappings. Both can coexist without a single change to the device driver. Can I still create the kernel mapping for the allocated memory later, yielding the same result as if I would've omitted DMA_ATTR_NO_KERNEL_MAPPING? Well, this will probably work, but it is not yet officially supported by the dma-mapping, but I'm aware of such use cases and specifying how to do it right is also on my todo list. The second case is passing a framebuffer address from the bootloader to the kernel. Often with mobile devices the bootloader will initialize the display hardware, showing a company logo or such. To keep the image on the screen when kernel starts we need to reserve the same physical memory area early at boot, and use that for the framebuffer. I'm not sure if there's any actual problem with this one, presuming there is a solution for the first case. Somehow the memory is reserved at early boot time, and this is passed to the fb driver. But can the memory be managed the
[PATCH] CLK: clk-twl6040: Initial clock driver for OMAP4+ McPDM fclk clock
On OMAP4+ platforms the functional clock for the McPDM IP is suplied by
the twl6040 codec (bit clock on the PDM bus).
This common clock driver for twl6040 will register the mcpdm_fclk clock to
be used by the McPDM driver to make sure that the needed clocks are
available when needed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hello Mike,
This driver is going to be used by the OMAP McPDM driver when we moved to common
clock framework.
To avoid merge conflicts I'm going to send the patch needed for the twl6040 MFD
core driver to register the platform device for the clk driver.
Some background: OMAP McPDM's functional clock is coming from external source,
which is the bitclock of the McPDM interface generated by external codec
(twl6040). This clock is needed to access McPDM registers as well and when I'm
going to implement the power states of twl6040 we need to make sure that the
clock is running from twl6040 to McPDM in order to avoid surprises.
Regards,
Peter
drivers/clk/Kconfig | 8 +++
drivers/clk/Makefile | 1 +
drivers/clk/clk-twl6040.c | 126 ++
3 files changed, 135 insertions(+)
create mode 100644 drivers/clk/clk-twl6040.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index bace9e9..3d0b784 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -53,4 +53,12 @@ config COMMON_CLK_MAX77686
---help---
This driver supports Maxim 77686 crystal oscillator clock.
+config CLK_TWL6040
+ tristate External McPDM functional clock from twl6040
+ depends on TWL6040_CORE
+ ---help---
+ Enable the external functional clock support on OMAP4+ platforms for
+ McPDM. McPDM module is using the external bit clock on the McPDM bus
+ as functional clock.
+
endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 6327536..c55d840 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_ARCH_U8500) += ux500/
# Chip specific
obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
+obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
diff --git a/drivers/clk/clk-twl6040.c b/drivers/clk/clk-twl6040.c
new file mode 100644
index 000..f4a3389
--- /dev/null
+++ b/drivers/clk/clk-twl6040.c
@@ -0,0 +1,126 @@
+/*
+* TWL6040 clock module driver for OMAP4 McPDM functional clock
+*
+* Copyright (C) 2012 Texas Instruments Inc.
+* Peter Ujfalusi peter.ujfal...@ti.com
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU General Public License
+* version 2 as published by the Free Software Foundation.
+*
+* This program is distributed in the hope that it will be useful, but
+* WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+* General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+* 02110-1301 USA
+*
+*/
+
+#include linux/clk.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/platform_device.h
+#include linux/mfd/twl6040.h
+#include linux/clk-provider.h
+
+struct twl6040_clk {
+ struct twl6040 *twl6040;
+ struct device *dev;
+ struct clk_hw mcpdm_fclk;
+ struct clk *clk;
+ int enabled;
+};
+
+static int twl6040_bitclk_is_enabled(struct clk_hw *hw)
+{
+ struct twl6040_clk *twl6040_clk = container_of(hw, struct twl6040_clk,
+ mcpdm_fclk);
+ return twl6040_clk-enabled;
+}
+
+static int twl6040_bitclk_prepare(struct clk_hw *hw)
+{
+ struct twl6040_clk *twl6040_clk = container_of(hw, struct twl6040_clk,
+ mcpdm_fclk);
+ int ret;
+
+ ret = twl6040_power(twl6040_clk-twl6040, 1);
+ if (!ret)
+ twl6040_clk-enabled = 1;
+
+ return ret;
+}
+
+static void twl6040_bitclk_unprepare(struct clk_hw *hw)
+{
+ struct twl6040_clk *twl6040_clk = container_of(hw, struct twl6040_clk,
+ mcpdm_fclk);
+ int ret;
+
+ ret = twl6040_power(twl6040_clk-twl6040, 0);
+ if (!ret)
+ twl6040_clk-enabled = 0;
+}
+
+static const struct clk_ops twl6040_mcpdm_ops = {
+ .is_enabled = twl6040_bitclk_is_enabled,
+ .prepare = twl6040_bitclk_prepare,
+ .unprepare = twl6040_bitclk_unprepare,
+};
+
+static struct clk_init_data wm831x_clkout_init = {
+ .name = mcpdm_fclk,
+ .ops = twl6040_mcpdm_ops,
+ .flags = CLK_IS_ROOT,
+};
+
+static int __devinit twl6040_clk_probe(struct platform_device *pdev)
+{
+ struct twl6040 *twl6040 = dev_get_drvdata(pdev-dev.parent);
+ struct twl6040_clk
[PATCH V5 0/2] of: Add generic device tree DMA helpers
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic device-tree helpers to retrieve a DMA controller device_node and the DMA request/channel information. v5: - minor update to binding documentation - added loop to exhaustively search for a slave channel in the case where there could be alternative channels available v4: - revert the removal of xlate function from v3 - update the proposed binding format and APIs based upon discussions [3] v3: - avoid passing an xlate function and instead pass DMA engine parameters - define number of dma channels and requests in dma-controller node v2: - remove of_dma_to_resource API - make property #dma-cells required (no fallback anymore) - another check in of_dma_xlate_onenumbercell() function [1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022 [2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622 [3] http://marc.info/?l=linux-omapm=133582085008539w=2 Jon Hunter (2): of: Add generic device tree DMA helpers dmaengine: add helper function to request a slave DMA channel Documentation/devicetree/bindings/dma/dma.txt | 80 + drivers/dma/dmaengine.c | 16 ++ drivers/of/Makefile |2 +- drivers/of/dma.c | 219 + include/linux/dmaengine.h |6 + include/linux/of_dma.h| 45 + 6 files changed, 367 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dma/dma.txt create mode 100644 drivers/of/dma.c create mode 100644 include/linux/of_dma.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 2/2] dmaengine: add helper function to request a slave DMA channel
Currently slave DMA channels are requested by calling dma_request_channel()
and requires DMA clients to pass various filter parameters to obtain the
appropriate channel.
With device-tree being used by architectures such as arm and the addition of
device-tree helper functions to extract the relevant DMA client information
from device-tree, add a new function to request a slave DMA channel using
device-tree. This function is currently a simple wrapper that calls the
device-tree of_dma_request_slave_channel() function.
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/dma/dmaengine.c | 16
include/linux/dmaengine.h |6 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 3491654..9b466da 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -62,6 +62,7 @@
#include linux/rculist.h
#include linux/idr.h
#include linux/slab.h
+#include linux/of_dma.h
static DEFINE_MUTEX(dma_list_mutex);
static DEFINE_IDR(dma_idr);
@@ -546,6 +547,21 @@ struct dma_chan *__dma_request_channel(dma_cap_mask_t
*mask, dma_filter_fn fn, v
}
EXPORT_SYMBOL_GPL(__dma_request_channel);
+/**
+ * dma_request_slave_channel - try to allocate an exclusive slave channel
+ * @dev: pointer to client device structure
+ * @name: slave channel name
+ */
+struct dma_chan *dma_request_slave_channel(struct device *dev, char *name)
+{
+ /* If device-tree is present get slave info from here */
+ if (dev-of_node)
+ return of_dma_request_slave_channel(dev-of_node, name);
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(dma_request_slave_channel);
+
void dma_release_channel(struct dma_chan *chan)
{
mutex_lock(dma_list_mutex);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9c02a45..9500aa5 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -973,6 +973,7 @@ enum dma_status dma_sync_wait(struct dma_chan *chan,
dma_cookie_t cookie);
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
void dma_issue_pending_all(void);
struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn,
void *fn_param);
+struct dma_chan *dma_request_slave_channel(struct device *dev, char *name);
void dma_release_channel(struct dma_chan *chan);
#else
static inline enum dma_status dma_wait_for_async_tx(struct
dma_async_tx_descriptor *tx)
@@ -987,6 +988,11 @@ static inline struct dma_chan
*__dma_request_channel(dma_cap_mask_t *mask,
{
return NULL;
}
+static inline struct dma_chan *dma_request_slave_channel(struct device *dev,
+char *name)
+{
+ return NULL
+}
static inline void dma_release_channel(struct dma_chan *chan)
{
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 1/2] of: Add generic device tree DMA helpers
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
Thinking about DMA controllers purely from the context of the hardware to
begin with, we can describe a device in terms of a DMA controller as
follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task. In previous discussions on this topic the following concerns
have been raised ...
1. How does the binding support devices with multiple DMA controllers?
2. How to support both legacy DMA controllers not using DMA Engine as
well as those that support DMA Engine.
3. When using with DMA Engine how do we support the various
implementations where the opaque filter function parameter differs
between implementations?
4. How do we handle DMA channels that are identified with a string
versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
an agreement what can be or should be supported.
Design of DMA helpers
1. Registering DMA controllers
In the case of DMA controllers that are using DMA Engine, requesting a
channel is performed by calling the following function.
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
dma_filter_fn filter_fn,
void *filter_param);
The mask variable is used to match a type of the device controller in a list
of controllers. The filter_fn and filter_param are used to identify the
required dma channel and return a handle to the dma channel of type dma_chan.
From the examples I have seen, the mask and filter_fn are constant
for a given DMA controller and therefore, we can specify these as controller
specific data when registering the DMA controller with the device-tree DMA
helpers.
The filter_param variable is of an unknown type and is typically specific
to the DMA engine implementation for a given DMA controller. To allow some
flexibility in the type and formating of this filter_param we employ an
xlate to translate the device-tree binding information into the appropriate
format. The xlate function used for a DMA controller can also be specified
when registering the DMA controller with the device-tree DMA helpers.
Based upon the above, a function for registering the DMA controller with the
DMA helpers now looks like the below. The data variable is used to pass a
pointer to DMA controller specific data used by the xlate function.
int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
For example, in the case where DMA engine is used, we define the following
structure (that stores the DMA engine capability mask and filter function)
and pass this to the data variable in the above function.
struct of_dma_filter_info {
dma_cap_mask_t dma_cap;
dma_filter_fn filter_fn;
};
2. Representing and requesting channel information
Please see the dma binding documentation included in this patch for a
description of how DMA controllers and client information should be
represented with device-tree. For more information on how this binding
came about please see [3]. In addition to this, feedback received from
the Linux kernel summit showed a consensus (among those who attended) to
use a name to identify DMA client information [4].
A DMA channel can be requested by calling the following function, where name
is a required parameter used for identifying a DMA channel. This function
has been designed to return a structure of type dma_chan to work with the
DMA engine driver. Note that if DMA engine is used then drivers should be
using the DMA engine API dma_request_slave_channel() (implemented in part 2
of this series, dmaengine: add helper function to request a slave DMA
channel) which will in turn call the below function if device-tree is
present. The aim being to have a common DMA engine interface regardless of
whether device tree is being used.
struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
Re: [PATCH V5 1/2] of: Add generic device tree DMA helpers
On Friday 14 September 2012, Jon Hunter wrote: Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Stephen Warren swar...@nvidia.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Russell King li...@arm.linux.org.uk Cc: Rob Herring rob.herr...@calxeda.com Cc: Arnd Bergmann a...@arndb.de Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Signed-off-by: Jon Hunter jon-hun...@ti.com Reviewed-by: Arnd Bergmann a...@arndb.de Thanks for all this work, looks great! My final (tiny) comment on this: +2. A single read-write channel with two alternative dma controllers: + + dmas = dma1 5 + dma2 7 + dma3 2; + dma-names = rx-tx, rx-tx, rx-tx *three* alternative dma controllers, not two. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 2/2] dmaengine: add helper function to request a slave DMA channel
On Friday 14 September 2012, Jon Hunter wrote: Currently slave DMA channels are requested by calling dma_request_channel() and requires DMA clients to pass various filter parameters to obtain the appropriate channel. With device-tree being used by architectures such as arm and the addition of device-tree helper functions to extract the relevant DMA client information from device-tree, add a new function to request a slave DMA channel using device-tree. This function is currently a simple wrapper that calls the device-tree of_dma_request_slave_channel() function. Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Stephen Warren swar...@nvidia.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Russell King li...@arm.linux.org.uk Cc: Rob Herring rob.herr...@calxeda.com Cc: Arnd Bergmann a...@arndb.de Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Signed-off-by: Jon Hunter jon-hun...@ti.com Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
On Friday 14 September 2012, AnilKumar, Chimata wrote:
Small question here, in my v2 version I have specified both
the compatible names lis3lv02d and lis331dlh is it fine or
only one is sufficient?
+static struct of_device_id lis3lv02d_i2c_dt_ids[] = {
+ { .compatible = st,lis3lv02d },
+ { .compatible = st,lis331dlh },
+ {}
+};
That's ok. In most cases, people will need the data field to point to a
data structure with the differences between two chips, but not if they are
identical from the software side.
It's also fine if you just list one entry here and put both values as
compatible in the device tree, to signify that the device is backwards
compatible with the older variant.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Friday 14 September 2012, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. No further comments on this version besides the ones I already gave on v1. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RTC: TWL: ensure all interrupts are disabled during probe
On Thu, Sep 13, 2012 at 1:45 PM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Kevin Hilman khil...@ti.com On some platforms, bootloaders are known to do some interesting RTC programming. Without going into the obscurities as to why this may be the case, suffice it to say the the driver should not make any assumptions about the state of the RTC when the driver loads. In particular, the driver probe should be sure that all interrupts are disabled until otherwise programmed. This was discovered when finding bursty I2C traffic every second on Overo platforms. This I2C overhead was keeping the SoC from hitting deep power states. The cause was found to be the RTC firing every second on the I2C-connected TWL PMIC. Special thanks to Felipe Balbi for suggesting to look for a rogue driver as the source of the I2C traffic rather than the I2C driver itself. Special thanks to Steve Sakoman for helping track down the source of the continuous RTC interrups on the Overo boards. Cc: Felipe Balbi ba...@ti.com Cc: Steve Sakoman st...@sakoman.com Signed-off-by: Kevin Hilman khil...@ti.com Tested on Overo/Tobi, and I no longer see the 1/second interrupts. Also verified that alarm interrupts still work using rtcwake. Tested-by: Steve Sakoman st...@sakoman.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 05:18 PM, Jon Hunter :
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
Thinking about DMA controllers purely from the context of the hardware to
begin with, we can describe a device in terms of a DMA controller as
follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task. In previous discussions on this topic the following concerns
have been raised ...
1. How does the binding support devices with multiple DMA controllers?
2. How to support both legacy DMA controllers not using DMA Engine as
well as those that support DMA Engine.
3. When using with DMA Engine how do we support the various
implementations where the opaque filter function parameter differs
between implementations?
4. How do we handle DMA channels that are identified with a string
versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
an agreement what can be or should be supported.
Design of DMA helpers
1. Registering DMA controllers
In the case of DMA controllers that are using DMA Engine, requesting a
channel is performed by calling the following function.
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
dma_filter_fn filter_fn,
void *filter_param);
The mask variable is used to match a type of the device controller in a
list
of controllers. The filter_fn and filter_param are used to identify the
required dma channel and return a handle to the dma channel of type
dma_chan.
From the examples I have seen, the mask and filter_fn are constant
for a given DMA controller and therefore, we can specify these as
controller
specific data when registering the DMA controller with the device-tree DMA
helpers.
The filter_param variable is of an unknown type and is typically specific
to the DMA engine implementation for a given DMA controller. To allow some
flexibility in the type and formating of this filter_param we employ an
xlate to translate the device-tree binding information into the appropriate
format. The xlate function used for a DMA controller can also be specified
when registering the DMA controller with the device-tree DMA helpers.
Based upon the above, a function for registering the DMA controller with
the
DMA helpers now looks like the below. The data variable is used to pass a
pointer to DMA controller specific data used by the xlate function.
int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
For example, in the case where DMA engine is used, we define the following
structure (that stores the DMA engine capability mask and filter function)
and pass this to the data variable in the above function.
struct of_dma_filter_info {
dma_cap_mask_t dma_cap;
dma_filter_fn filter_fn;
};
2. Representing and requesting channel information
Please see the dma binding documentation included in this patch for a
description of how DMA controllers and client information should be
represented with device-tree. For more information on how this binding
came about please see [3]. In addition to this, feedback received from
the Linux kernel summit showed a consensus (among those who attended) to
use a name to identify DMA client information [4].
A DMA channel can be requested by calling the following function, where
name
is a required parameter used for identifying a DMA channel. This function
has been designed to return a structure of type dma_chan to work with the
DMA engine driver. Note that if DMA engine is used then drivers should be
using the DMA engine API dma_request_slave_channel() (implemented in part 2
of this series, dmaengine: add helper function to request a slave DMA
channel) which will in turn call the below function if device-tree is
present. The aim being to have a common DMA engine interface regardless of
whether device tree is being used.
Re: USB problem on beagleboard clone
Hi, On Fri, Sep 14, 2012 at 03:38:56PM +0200, Maximilian Schwerin wrote: I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? -- balbi I'm still on 3.3 but am planing to go to a newer version. We used the OTG port so we would not need another chip on a rather small board. And which chip are you talking about ? You already have LAN9514 on your board anyway... -- balbi How would I connect the OMAP to the LAN9514 without a PHY? Fair enough.. for whatever reason I assumed you had external PHY with MUSB. But seems like you're using the internal PHY... Anyway, please check with my tree (see MAINTAINERS file), either master branch or musb branch and let me know if you have the same behavior. -- balbi signature.asc Description: Digital signature
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
On 09/13/2012 04:00 PM, Jon Hunter wrote: This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt +* Generic DMA Controller and DMA request bindings + +Generic binding to provide a way for a driver using DMA Engine to retrieve the +DMA request or channel information that goes from a hardware device to a DMA +controller. + + +* DMA controller + +Required property: +- #dma-cells:Must be at least 1. Used to provide DMA controller + specific information. See DMA client binding below for ... +* DMA client + +Client drivers should specify the DMA property using a phandle to the controller +followed by DMA controller specific data. + +Required property: +- dmas: List of one or more DMA specifiers, each consisting of + - A phandle pointing to DMA controller node + - A single integer cell containing DMA controller + specific information. This typically contains a dma + request line number or a channel number, but can + contain any data that is used required for configuring + a channel. A single integer cell doesn't sound correct; shouldn't this be something like a number of integer cells, as determined by the #dma-cells property in the node referenced by phandle? +- dma-names: Contains one identifier string for each dma specifier in + the dmas property. The specific strings that can be used + are defined in the binding of the DMA client device. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 11:28 AM, Stephen Warren wrote: On 09/13/2012 04:00 PM, Jon Hunter wrote: This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt +* Generic DMA Controller and DMA request bindings + +Generic binding to provide a way for a driver using DMA Engine to retrieve the +DMA request or channel information that goes from a hardware device to a DMA +controller. + + +* DMA controller + +Required property: +- #dma-cells: Must be at least 1. Used to provide DMA controller +specific information. See DMA client binding below for ... +* DMA client + +Client drivers should specify the DMA property using a phandle to the controller +followed by DMA controller specific data. + +Required property: +- dmas: List of one or more DMA specifiers, each consisting of +- A phandle pointing to DMA controller node +- A single integer cell containing DMA controller + specific information. This typically contains a dma + request line number or a channel number, but can + contain any data that is used required for configuring + a channel. A single integer cell doesn't sound correct; shouldn't this be something like a number of integer cells, as determined by the #dma-cells property in the node referenced by phandle? Thanks for catching that. I had been re-working this a few times and must have forgotten to update that. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 10:26 AM, Arnd Bergmann wrote: On Friday 14 September 2012, Jon Hunter wrote: Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Stephen Warren swar...@nvidia.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Russell King li...@arm.linux.org.uk Cc: Rob Herring rob.herr...@calxeda.com Cc: Arnd Bergmann a...@arndb.de Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams d...@fb.com Signed-off-by: Jon Hunter jon-hun...@ti.com Reviewed-by: Arnd Bergmann a...@arndb.de Thanks for all this work, looks great! Thanks! My final (tiny) comment on this: +2. A single read-write channel with two alternative dma controllers: + +dmas = dma1 5 +dma2 7 +dma3 2; +dma-names = rx-tx, rx-tx, rx-tx *three* alternative dma controllers, not two. Oops! I have been starring at this so long I can no longer see the wood for the trees! Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RTC: TWL: ensure all interrupts are disabled during probe
On Fri, Sep 14, 2012 at 7:37 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Shubhrajyoti Datta omaplinuxker...@gmail.com writes: Hi Kevin, On Fri, Sep 14, 2012 at 2:15 AM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Kevin Hilman khil...@ti.com On some platforms, bootloaders are known to do some interesting RTC programming. Without going into the obscurities as to why this may be the case, suffice it to say the the driver should not make any assumptions about the state of the RTC when the driver loads. In particular, the driver probe should be sure that all interrupts are disabled until otherwise programmed. This was discovered when finding bursty I2C traffic every second on Overo platforms. This I2C overhead was keeping the SoC from hitting deep power states. The cause was found to be the RTC firing every second on the I2C-connected TWL PMIC. Special thanks to Felipe Balbi for suggesting to look for a rogue driver as the source of the I2C traffic rather than the I2C driver itself. Special thanks to Steve Sakoman for helping track down the source of the continuous RTC interrups on the Overo boards. Tested that the continuous interrupt issue after doing a i2c mm on omap4sdp. This patch solves the issue. thanks, Cc: Felipe Balbi ba...@ti.com Cc: Steve Sakoman st...@sakoman.com Signed-off-by: Kevin Hilman khil...@ti.com --- Patch applies to v3.6-rc5 drivers/rtc/rtc-twl.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c index c5d06fe..9277d94 100644 --- a/drivers/rtc/rtc-twl.c +++ b/drivers/rtc/rtc-twl.c @@ -495,6 +495,11 @@ static int __devinit twl_rtc_probe(struct platform_device *pdev) if (ret 0) goto out1; + /* ensure interrupts are disabled, bootloaders can be strange */ + ret = twl_rtc_write_u8(0, REG_RTC_INTERRUPTS_REG); + if (ret 0) + dev_warn(pdev-dev, unable to disable interrupt\n); + Now that it is always 0 can the below read be removed as it is redundant now. Possibly, but I don't know this HW well enough to know if there are any persistent bits in that register on any of the various derivations of this PMIC. Since this read-back value is used throughout the driver, I decided not to mess with it when doing this targetted fix. Indeed makes sense. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 5/7] omap sparse irq and local hardware.h cleanup for v3.7 merge window
* Tony Lindgren t...@atomide.com [120914 08:28]: The following changes since commit a1e01703bacbadd22eb4aaca0bbba59bcba7d3b3: Merge tags 'omap-devel-gpmc-fixed-for-v3.7' and 'cleanup-omap-tags-for-v3.7' into cleanup-sparseirq (2012-09-12 18:05:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-cleanup-sparseirq-for-v3.7 for you to fetch changes up to 68cb700c59fae6cd539c9dc1e9f2584f671935a0: ARM: OMAP1: Move SoC specific headers from plat to mach for omap1 (2012-09-12 18:06:31 -0700) This branch contains changes needed to make omap2+ work properly with sparse IRQ. It also removes dependencies to mach/hardware.h. These help moving things towards ARM single zImage support. This branch is based on a commit in tty-next branch with omap-devel-gpmc-fixed-for-v3.7 and cleanup-omap-tags-for-v3.7 merged in to keep things compiling and sort out some merge conflicts. This will need some manual merging with what's in testing/platform-data, so please let me know if you need help with that. But basically it's mostly: remove #include plat/board.h for both mach-omap1 mach-omap2 remove #include mach/hardware.h for mach-omap2 remove #include mach/irqs.h for mach-omap2 Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] CPUFreq: OMAP: remove unnecessary plat/ includes
On Wednesday, September 12, 2012, Paul Walmsley wrote:
Remove some unnecessary plat/ includes that are interfering with multi-subarch
ARM kernels.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rafael J. Wysocki r...@sisk.pl
Acked-by: Kevin Hilman khil...@ti.com
Acked-by: Rafael J. Wysocki r...@sisk.pl
---
Still awaiting some final testing here. Rafael, was wondering if you
would be willing to ack this so we can merge it via the OMAP tree?
Otherwise the patch can be split into an OMAP part and a CPUFreq part that
can go in across two merge windows.
arch/arm/mach-omap2/clock2420_data.c |1 +
arch/arm/mach-omap2/clock2430_data.c |1 +
arch/arm/mach-omap2/clock3xxx_data.c |1 +
arch/arm/mach-omap2/clock44xx_data.c |1 +
drivers/cpufreq/omap-cpufreq.c | 19 +--
5 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index ea8e883..de1b9a4 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1897,6 +1897,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_242X),
CLK(NULL, usb_fck, usb_fck, CK_242X),
CLK(musb-hdrc,fck, osc_ck,CK_242X),
+ CLK(NULL, cpufreq_ck, virt_prcm_set, CK_242X),
};
/*
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index cacabb0..d3ecdf7 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1993,6 +1993,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, timer_32k_ck, func_32k_ck, CK_243X),
CLK(NULL, timer_sys_ck, sys_ck,CK_243X),
CLK(NULL, timer_ext_ck, alt_ck,CK_243X),
+ CLK(NULL, cpufreq_ck, virt_prcm_set, CK_243X),
};
/*
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 83bed9a..ea4690c 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3466,6 +3466,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, uart4_ick,uart4_ick_am35xx, CK_AM35XX),
CLK(NULL, timer_32k_ck, omap_32k_fck, CK_3XXX),
CLK(NULL, timer_sys_ck, sys_ck,CK_3XXX),
+ CLK(NULL, cpufreq_ck, dpll1_ck, CK_3XXX),
};
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index d7f55e4..9b31767 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3325,6 +3325,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(omap_timer.6, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(omap_timer.7, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(omap_timer.8, timer_sys_ck, syc_clk_div_ck,
CK_443X),
+ CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
};
int __init omap4xxx_clk_init(void)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index b47034e..2737d08 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -30,13 +30,9 @@
#include asm/smp_plat.h
#include asm/cpu.h
-#include plat/clock.h
-#include plat/omap-pm.h
#include plat/common.h
#include plat/omap_device.h
-#include mach/hardware.h
-
/* OPP tolerance in percentage */
#define OPP_TOLERANCE 4
@@ -53,7 +49,6 @@ static struct lpj_info global_lpj_ref;
static struct cpufreq_frequency_table *freq_table;
static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
-static char *mpu_clk_name;
static struct device *mpu_dev;
static struct regulator *mpu_reg;
@@ -207,7 +202,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
{
int result = 0;
- mpu_clk = clk_get(NULL, mpu_clk_name);
+ mpu_clk = clk_get(NULL, cpufreq_ck);
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
@@ -288,18 +283,6 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
- if (cpu_is_omap24xx())
- mpu_clk_name = virt_prcm_set;
- else if (cpu_is_omap34xx())
- mpu_clk_name = dpll1_ck;
- else if (cpu_is_omap44xx())
- mpu_clk_name = dpll_mpu_ck;
-
- if (!mpu_clk_name) {
- pr_err(%s: unsupported Silicon?\n, __func__);
- return -EINVAL;
- }
-
mpu_dev = omap_device_get_by_hwmod_name(mpu);
if (!mpu_dev) {
pr_warning(%s: unable to get the mpu device\n, __func__);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH] RTC: TWL: ensure all interrupts are disabled during probe
On Fri, 14 Sep 2012 08:33:42 -0700 Steve Sakoman st...@sakoman.com wrote: Tested-by: Steve Sakoman st...@sakoman.com Thanks. Given the tested-by's that are rolling in, I will assume that people are hitting this problem in 3.5 and perhaps earlier kernels, so I scheduled the fix for 3.6, with a -stable backport. I might have been wrong about that - in future, please do make these issues clear in the patch changelog? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RTC: TWL: ensure all interrupts are disabled during probe
On Fri, Sep 14, 2012 at 12:20 PM, Andrew Morton a...@linux-foundation.org wrote: Given the tested-by's that are rolling in, I will assume that people are hitting this problem in 3.5 and perhaps earlier kernels, so I scheduled the fix for 3.6, with a -stable backport. Yes, I just checked an Overo setup here that is running 3.2 and it has the same issue. So your plan for 3.6 and -stable is a good one. Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Fri, 14 Sep 2012 15:31:36 + Arnd Bergmann a...@arndb.de wrote: On Friday 14 September 2012, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. No further comments on this version besides the ones I already gave on v1. My linux-arm-kernel subscription died so I don't know what your v1 comments said. Were they fatal? -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Friday 14 September 2012, Andrew Morton wrote: On Fri, 14 Sep 2012 15:31:36 + Arnd Bergmann a...@arndb.de wrote: On Friday 14 September 2012, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. No further comments on this version besides the ones I already gave on v1. My linux-arm-kernel subscription died so I don't know what your v1 comments said. Were they fatal? Just details. AnilKumar just said in that thread that he'd do a version 3 based on the earlier discussion once I was done looking at v2, so I replied here to say that there is nothing new to add. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 0/2] of: Add generic device tree DMA helpers
Hi all, I apologise for sending out so many updates in quick succession before everyone has had chance to review, however, I will be out of office next week and I know that several people have been waiting for this. Normally, I would not send out a series and disappear for a week, but Arnd agreed to help while I am out. Arnd, Feel free to make any changes you see fit while I am out or correct any balls-up I have made! Cheers Jon This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic device-tree helpers to retrieve a DMA controller device_node and the DMA request/channel information. v6: - minor corrections in DMA binding documentation v5: - minor update to binding documentation - added loop to exhaustively search for a slave channel in the case where there could be alternative channels available v4: - revert the removal of xlate function from v3 - update the proposed binding format and APIs based upon discussions [3] v3: - avoid passing an xlate function and instead pass DMA engine parameters - define number of dma channels and requests in dma-controller node v2: - remove of_dma_to_resource API - make property #dma-cells required (no fallback anymore) - another check in of_dma_xlate_onenumbercell() function [1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022 [2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622 [3] http://marc.info/?l=linux-omapm=133582085008539w=2 Jon Hunter (2): of: Add generic device tree DMA helpers dmaengine: add helper function to request a slave DMA channel Documentation/devicetree/bindings/dma/dma.txt | 81 + drivers/dma/dmaengine.c | 16 ++ drivers/of/Makefile |2 +- drivers/of/dma.c | 219 + include/linux/dmaengine.h |6 + include/linux/of_dma.h| 45 + 6 files changed, 368 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dma/dma.txt create mode 100644 drivers/of/dma.c create mode 100644 include/linux/of_dma.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel
Currently slave DMA channels are requested by calling dma_request_channel()
and requires DMA clients to pass various filter parameters to obtain the
appropriate channel.
With device-tree being used by architectures such as arm and the addition of
device-tree helper functions to extract the relevant DMA client information
from device-tree, add a new function to request a slave DMA channel using
device-tree. This function is currently a simple wrapper that calls the
device-tree of_dma_request_slave_channel() function.
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/dma/dmaengine.c | 16
include/linux/dmaengine.h |6 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 3491654..9b466da 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -62,6 +62,7 @@
#include linux/rculist.h
#include linux/idr.h
#include linux/slab.h
+#include linux/of_dma.h
static DEFINE_MUTEX(dma_list_mutex);
static DEFINE_IDR(dma_idr);
@@ -546,6 +547,21 @@ struct dma_chan *__dma_request_channel(dma_cap_mask_t
*mask, dma_filter_fn fn, v
}
EXPORT_SYMBOL_GPL(__dma_request_channel);
+/**
+ * dma_request_slave_channel - try to allocate an exclusive slave channel
+ * @dev: pointer to client device structure
+ * @name: slave channel name
+ */
+struct dma_chan *dma_request_slave_channel(struct device *dev, char *name)
+{
+ /* If device-tree is present get slave info from here */
+ if (dev-of_node)
+ return of_dma_request_slave_channel(dev-of_node, name);
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(dma_request_slave_channel);
+
void dma_release_channel(struct dma_chan *chan)
{
mutex_lock(dma_list_mutex);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9c02a45..9500aa5 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -973,6 +973,7 @@ enum dma_status dma_sync_wait(struct dma_chan *chan,
dma_cookie_t cookie);
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
void dma_issue_pending_all(void);
struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn,
void *fn_param);
+struct dma_chan *dma_request_slave_channel(struct device *dev, char *name);
void dma_release_channel(struct dma_chan *chan);
#else
static inline enum dma_status dma_wait_for_async_tx(struct
dma_async_tx_descriptor *tx)
@@ -987,6 +988,11 @@ static inline struct dma_chan
*__dma_request_channel(dma_cap_mask_t *mask,
{
return NULL;
}
+static inline struct dma_chan *dma_request_slave_channel(struct device *dev,
+char *name)
+{
+ return NULL
+}
static inline void dma_release_channel(struct dma_chan *chan)
{
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 1/2] of: Add generic device tree DMA helpers
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
Thinking about DMA controllers purely from the context of the hardware to
begin with, we can describe a device in terms of a DMA controller as
follows ...
1. Number of DMA controllers
2. Number of channels (maybe physical or logical)
3. Mapping of DMA requests signals to DMA controller
4. Number of DMA interrupts
5. Mapping of DMA interrupts to channels
- With the above in mind the aim of the DT DMA helper functions is to extract
the above information from the DT and provide to the appropriate driver.
However, due to the vast number of DMA controllers and not all are using a
common driver (such as DMA Engine) it has been seen that this is not a
trivial task. In previous discussions on this topic the following concerns
have been raised ...
1. How does the binding support devices with multiple DMA controllers?
2. How to support both legacy DMA controllers not using DMA Engine as
well as those that support DMA Engine.
3. When using with DMA Engine how do we support the various
implementations where the opaque filter function parameter differs
between implementations?
4. How do we handle DMA channels that are identified with a string
versus a integer?
- Hence the design of the DMA helpers has to accomodate the above or align on
an agreement what can be or should be supported.
Design of DMA helpers
1. Registering DMA controllers
In the case of DMA controllers that are using DMA Engine, requesting a
channel is performed by calling the following function.
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
dma_filter_fn filter_fn,
void *filter_param);
The mask variable is used to match a type of the device controller in a list
of controllers. The filter_fn and filter_param are used to identify the
required dma channel and return a handle to the dma channel of type dma_chan.
From the examples I have seen, the mask and filter_fn are constant
for a given DMA controller and therefore, we can specify these as controller
specific data when registering the DMA controller with the device-tree DMA
helpers.
The filter_param variable is of an unknown type and is typically specific
to the DMA engine implementation for a given DMA controller. To allow some
flexibility in the type and formating of this filter_param we employ an
xlate to translate the device-tree binding information into the appropriate
format. The xlate function used for a DMA controller can also be specified
when registering the DMA controller with the device-tree DMA helpers.
Based upon the above, a function for registering the DMA controller with the
DMA helpers now looks like the below. The data variable is used to pass a
pointer to DMA controller specific data used by the xlate function.
int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
(struct of_phandle_args *, struct of_dma *),
void *data)
For example, in the case where DMA engine is used, we define the following
structure (that stores the DMA engine capability mask and filter function)
and pass this to the data variable in the above function.
struct of_dma_filter_info {
dma_cap_mask_t dma_cap;
dma_filter_fn filter_fn;
};
2. Representing and requesting channel information
Please see the dma binding documentation included in this patch for a
description of how DMA controllers and client information should be
represented with device-tree. For more information on how this binding
came about please see [3]. In addition to this, feedback received from
the Linux kernel summit showed a consensus (among those who attended) to
use a name to identify DMA client information [4].
A DMA channel can be requested by calling the following function, where name
is a required parameter used for identifying a DMA channel. This function
has been designed to return a structure of type dma_chan to work with the
DMA engine driver. Note that if DMA engine is used then drivers should be
using the DMA engine API dma_request_slave_channel() (implemented in part 2
of this series, dmaengine: add helper function to request a slave DMA
channel) which will in turn call the below function if device-tree is
present. The aim being to have a common DMA engine interface regardless of
whether device tree is being used.
struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 04:41 PM, Jon Hunter wrote: This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. The binding looks good to me now, so, Reviewed-by: Stephen Warren swar...@wwwdotorg.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: 3. Supporting legacy devices not using DMA Engine These devices present a problem, as there may not be a uniform way to easily support them with regard to device tree. Ideally, these should be migrated to DMA engine. However, if this is not possible, then they should still be able to use this binding, the only constaint imposed by this implementation is that when requesting a DMA channel via of_dma_request_slave_channel(), it will return a type of dma_chan. As far as devices not using DMA engine, the answer is we don't support their specification in the DT model. Note that the legacy OMAP DMA API is scheduled for removal next year, so it's not going to be around that much longer. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
