Re: [PATCHv8 00/23]I2C big cleanup
On Thursday 13 September 2012 03:57 AM, Kevin Hilman wrote: Shubhrajyoti D shubhrajy...@ti.com writes: [...] This is the cleanup only series. Tested on omap4sdp and 3430sdp. It would be extremely helpful if you would describe how this was tested. And for me, it would be a source of extreme joy if you described any PM testing. I gave this some additional PM testing on 3430/n900, 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM and 4430/Panda. I tested v3.6-rc5 which passed all PM tests and then added this series (by merging the i2c-embedded/i2c-next branch.) PM tests then fail. At least on 3530/Overo and 3730/Overo, CORE no longer hits retenion (or off) during idle. The easy way to notice this is to see that even when no i2c transactions are happening, the runtime PM status for omap_i2c.1 is remains 'active': # cat omap_i2c.*/power/runtime_status active suspended Of course that means that clocks are never gated during idle, and CORE will never hit retention. I noticed it because my PM tests detected that the CORE powerdomain was not transitioning to retention (or off) during idle. To reproduce, simply enable UART timeouts so CORE will hit retention: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms and check the core_pwrm state counters: cat /debug/pm_debug/count wait 3 seconds for the UART autosuspend timers to kick in. At this point, CORE should be transitioning to retenion in idle (determined by noticing that the RET counter for core_pwrdm is increasing.) With $SUBJECT series applied, you'll notice that CORE is not transitioning. However I do not see the issue,let me know if I missed something see below. On my 3430sdp /sys/bus/platform/devices # cat omap_i2c.*/power/runtime_status suspended suspended suspended /sys/bus/platform/devices # /sys/bus/platform/devices # cat omap_i2c.*/power/autosuspend_delay_ms 1000 1000 1000 /sys/bus/platform/devices # echo 3000 /sys/devices/platform/omap_uart.0/power/ autosuspend_delay_ms /sys/bus/platform/devices # echo 3000 /sys/devices/platform/omap_uart.1/power/ autosuspend_delay_ms /sys/bus/platform/devices # echo 3000 /sys/devices/platform/omap_uart.2/power/ autosuspend_delay_ms /sys/bus/platform/devices # /sys/bus/platform/devices # cat /debug/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:1373,INA:0,ON:1374,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:79,INA:0,ON:80,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:1373,INA:0,ON:1374,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:1373,INA:0,ON:1374,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:1373,INA:0,ON:1374,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RE0 usbhost_clkdm-usbhost_pwrdm (1) sgx_clkdm-sgx_pwrdm (0) per_clkdm-per_pwrdm (13) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) d2d_clkdm-core_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) core_l4_clkdm-core_pwrdm (23) core_l3_clkdm-core_pwrdm (4) neon_clkdm-neon_pwrdm (0) /sys/bus/platform/devices # /sys/bus/platform/devices # /sys/bus/platform/devices # sleep 5 /sys/bus/platform/devices # cat /debug/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:1512,INA:0,ON:1513,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:12,INA:0,ON:13,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:218,INA:0,ON:219,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:1512,INA:0,ON:1513,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:1512,INA:0,ON:1513,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:1512,INA:0,ON:1513,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RE0 usbhost_clkdm-usbhost_pwrdm (1) sgx_clkdm-sgx_pwrdm (0) per_clkdm-per_pwrdm (13) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) d2d_clkdm-core_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) core_l4_clkdm-core_pwrdm (23) core_l3_clkdm-core_pwrdm (4) neon_clkdm-neon_pwrdm (0) /sys/bus/platform/devices # cat omap_i2c.*/power/runtime_status suspended suspended suspended /sys/bus/platform/devices # Kevin The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217: Linux 3.6-rc5 (2012-09-08 16:43:45 -0700) are
RE: [PATCH 2/2] arm/dts: AM33XX: Add device tree OPP table
On Wed, Sep 12, 2012 at 22:51:55, Cousson, Benoit wrote: + Paul Hi Anil, On 08/31/2012 11:37 AM, AnilKumar Ch wrote: Add DT OPP table for AM33XX family of devices. This data is decoded by OF with of_init_opp_table() helper function. Also adds cpu0 supply name to the corresponding dts files. cpu0-supply name is used by cpufreq-cpu0 driver to get the regulator pointer for voltage modifications. Signed-off-by: AnilKumar Ch anilku...@ti.com I've just applied your patch in my for_3.7/dts_part2 branch. Thanks Benoit, I changed the subject to use ARM: dts: prefix seems it seems to be the convention nowadays. I will take care from next time onwards. I can apply as the well the clock patch if Paul acks it, but it can go through Paul as well since there is no strong dependency between them AFAIK. Paul, Can you ACK clock data entry patch? 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: [PATCHv8 00/23]I2C big cleanup
Hi, On Thu, Sep 13, 2012 at 11:34:48AM +0530, Shubhrajyoti wrote: On Thursday 13 September 2012 03:57 AM, Kevin Hilman wrote: Shubhrajyoti D shubhrajy...@ti.com writes: [...] This is the cleanup only series. Tested on omap4sdp and 3430sdp. It would be extremely helpful if you would describe how this was tested. And for me, it would be a source of extreme joy if you described any PM testing. I gave this some additional PM testing on 3430/n900, 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM and 4430/Panda. I tested v3.6-rc5 which passed all PM tests and then added this series (by merging the i2c-embedded/i2c-next branch.) PM tests then fail. At least on 3530/Overo and 3730/Overo, CORE no longer hits retenion (or off) during idle. The easy way to notice this is to see that even when no i2c transactions are happening, the runtime PM status for omap_i2c.1 is remains 'active': # cat omap_i2c.*/power/runtime_status active suspended Of course that means that clocks are never gated during idle, and CORE will never hit retention. I noticed it because my PM tests detected that the CORE powerdomain was not transitioning to retention (or off) during idle. To reproduce, simply enable UART timeouts so CORE will hit retention: echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms echo 3000 /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms and check the core_pwrm state counters: cat /debug/pm_debug/count wait 3 seconds for the UART autosuspend timers to kick in. At this point, CORE should be transitioning to retenion in idle (determined by noticing that the RET counter for core_pwrdm is increasing.) With $SUBJECT series applied, you'll notice that CORE is not transitioning. However I do not see the issue,let me know if I missed something see below. On my 3430sdp /sys/bus/platform/devices # cat omap_i2c.*/power/runtime_status suspended suspended suspended /sys/bus/platform/devices # /sys/bus/platform/devices # cat omap_i2c.*/power/autosuspend_delay_ms 1000 1000 1000 I just revived my very, very old 3503 overo and while i2c isn't active, I don't see transitions on core power domain: # mount -t proc none /proc # mount -t sysfs none /sys # mount -t debugfs none /debug # echo 3000 /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms # echo 3000 /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms # echo 3000 /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms # cat /sys/devices/platform/omap_i2c.*/power/runtime_status suspended suspended # grep ^core_pwrdm /debug/pm_debug/count sleep 5 grep ^core_pwrdm /debug/pm_debug/count core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 Weird, but I don't think i2c is to blame here (unless I'm missing something). I can see that after i2c transfers, my suspend function is called and right after that i2c is suspended: # cat /sys/class/regulator/regulator.*/status sleep 1 cat /sys/devices/platform/omap_i2c.*/power/runtime_status [ 411.072998] omap_i2c omap_i2c.1: omap_i2c_runtime_resume normal normal normal [ 412.075347] omap_i2c omap_i2c.1: omap_i2c_runtime_suspend suspended suspended What am I missing to get any pm transitions to happen with my overo ? # cat /debug/pm_debug/count sleep 5 cat /debug/pm_debug/count usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:2379,INA:0,ON:2380,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:2377,INA:0,ON:2378,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm-usbhost_pwrdm (1) sgx_clkdm-sgx_pwrdm (0) per_clkdm-per_pwrdm (19) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) d2d_clkdm-core_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) core_l4_clkdm-core_pwrdm (21) core_l3_clkdm-core_pwrdm (4) neon_clkdm-neon_pwrdm (0) usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm
[PATCH V2] mmc: omap_hsmmc: Pass on the suspend failure to the PM core
From: Vaibhav Bedia vaibhav.be...@ti.com
In some cases mmc_suspend_host() is not able to claim the
host and proceed with the suspend process. The core returns
-EBUSY to the host controller driver. Unfortunately, the
host controller driver does not pass on this information
to the PM core and hence the system suspend process continues.
ret = mmc_suspend_host(host-mmc);
if (ret) {
host-suspended = 0;
if (host-pdata-resume) {
ret = host-pdata-resume(dev, host-slot_id);
The return status from mmc_suspend_host() is overwritten by return
status from host-pdata-resume. So the original return status is lost.
In these cases the MMC core gets to an unexpected state
during resume and multiple issues related to MMC crop up.
1. Host controller driver starts accessing the device registers
before the clocks are enabled which leads to a prefetch abort.
2. A file copy thread which was launched before suspend gets
stuck due to the host not being reclaimed during resume.
To avoid such problems pass on the -EBUSY status to the PM core
from the host controller driver. With this change, MMC core
suspend might still fail but it does not end up making the
system unusable. Suspend gets aborted and the user can try
suspending the system again.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Changes from V1:
- Instead of forcibly returning -EBUSY on err, retain old
status and pass on the same to the caller.
- add more detail to commit message (explanation with code
snippet)
:100644 100644 9afdd20... d9af5f1... M drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/omap_hsmmc.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9afdd20..d9af5f1 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2050,8 +2050,7 @@ static int omap_hsmmc_suspend(struct device *dev)
if (ret) {
host-suspended = 0;
if (host-pdata-resume) {
- ret = host-pdata-resume(dev, host-slot_id);
- if (ret)
+ if (host-pdata-resume(dev, host-slot_id))
dev_dbg(dev, Unmask interrupt failed\n);
}
goto err;
--
1.7.0.4
--
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] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
On Wed, Sep 12, 2012 at 10:27 PM, Tony Lindgren t...@atomide.com wrote: * Peter Ujfalusi peter.ujfal...@ti.com [120911 01:54]: With pinctrl-single,bits it is possible to update just part of the register within the pinctrl-single,function-mask area. This is useful when one register configures mmore than one pin's mux. size /= sizeof(*mux); /* Number of elements in array */ - rows = size / 2;/* Each row is a key value pair */ + rows = size / params; /* Each row is a key value pair */ Maybe just remove the comment: ^^ I don't think it's needed any longer. Other than that, thanks for updating the patch: Acked-by: Tony Lindgren t...@atomide.com Applied minus the comment, plus Tony's ACK, thanks! Linus Walleij -- 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 Thursday 13 September 2012 11:34 AM, Shubhrajyoti wrote: At least on 3530/Overo and 3730/Overo, CORE no longer hits retenion (or off) during idle. I dont have an Overo, anyways will see if I can get one However on beagleXm even off count increases / # grep ^core_pwrdm /debug/pm_debug/count core_pwrdm (ON),OFF:48,RET:856,INA:0,ON:905,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 / # cat /sys/devices/platform/omap_i2c.*/power/runtime_status suspended suspended / # / # / # cat /sys/devices/platform/omap_i2c.*/power/autosuspend_delay_ms 1000 1000 / # / # / # grep ^core_pwrdm /debug/pm_debug/count core_pwrdm (ON),OFF:218,RET:856,INA:0,ON:1075,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 / # -- 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 0/7] ARM: OMAP2+: PM: introduce the power domains functional states
On Thu, Sep 13, 2012 at 2:34 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: Here is a re-spin after some comments and suggestions after review and discussions. Implement the functional states for the power domains: - unify the API to use the functional states. The new API consists of the pwrdm_set*_fpwrst and pwrdm_read*_fpwrst functions and is the API to use to control the power domains power and logic states, - reorganize the powerdomain API in internal and external parts, in powerdomain.h [1] - protect the power domain state change by a lock in the functions that read and set the powerdomains next functional state, - introduce the functional states for power domains power states and logic power states [2], and the conversion functions between the functional and internal states. The conversion functions are lightweight and generic. The power domains allowed states [3] are defined in the pwrsts and pwrsts_logic_ret fields of the struct powerdomain, - program the logic power state of power domains from the functional states, in pwrdm_set*_fpwrst - convert the OMAP2/3/4 PM code to use the updated API, - provide the power domains statistics by functional states, - provide ftrace tracepoints with the functional state, - provide error logs in critical code, which makes the development easier. I just gave this series a round of PM testing. I tested retention and off in idle suspend, with and without CPUidle on 3430/n900, 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM and 4430/Panda (though only MPU/CPU ret/off is supported for OMAP4 in mainline.) All PM tests passed with flying colors. Nice! Great! Thanks a lot Kevin for testing Jean 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
[PATCH v6 0/2] ARM: New cache API for iommu
From a00cbfadc0053a3c21812593997a1b7338234a9f Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Thu, 13 Sep 2012 11:43:20 +0530 Subject: [PATCH v6 0/2] ARM: New cache API for iommu This patch series is the next version to - add a new cache maintenance api to support non-coherent iommu drivers. - flush both L1 and L2 caches from OMAP iommu whenever the page table memory is updated. Changes since the previous patch set (v5) - Fixed the RMK's comments on the flush function names in omap-iommu to reflect the purpose. The implementation of the new api is based on the approach[1] discussed. [1]http://marc.info/?l=linux-kernelm=131316512713815w=2 Ramesh Gupta G (2): ARM: new cache maintenance api for iommu OMAP:IOMMU:flush L1 and L2 caches arch/arm/include/asm/cacheflush.h | 21 +++ arch/arm/include/asm/glue-cache.h |1 + arch/arm/mm/cache-fa.S| 16 ++ arch/arm/mm/cache-v3.S| 14 - arch/arm/mm/cache-v4.S| 15 + arch/arm/mm/cache-v4wb.S | 22 arch/arm/mm/cache-v4wt.S | 18 arch/arm/mm/cache-v6.S| 21 +++ arch/arm/mm/cache-v7.S| 22 arch/arm/mm/proc-arm1020.S| 23 + arch/arm/mm/proc-arm1020e.S | 21 +++ arch/arm/mm/proc-arm1022.S| 21 +++ arch/arm/mm/proc-arm1026.S| 20 ++ arch/arm/mm/proc-arm920.S | 18 arch/arm/mm/proc-arm922.S | 18 arch/arm/mm/proc-arm925.S | 23 + arch/arm/mm/proc-arm926.S | 23 + arch/arm/mm/proc-arm940.S | 26 arch/arm/mm/proc-arm946.S | 25 +++ arch/arm/mm/proc-feroceon.S | 32 + arch/arm/mm/proc-macros.S |1 + arch/arm/mm/proc-mohawk.S | 19 + arch/arm/mm/proc-xsc3.S | 18 arch/arm/mm/proc-xscale.S | 20 ++ drivers/iommu/omap-iommu.c| 40 25 files changed, 475 insertions(+), 23 deletions(-) -- regards Ramesh Gupta G -- 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] mmc: omap_hsmmc: Pass on the suspend failure to the PM core
On Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote: On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: From: Vaibhav Bedia vaibhav.be...@ti.com In some cases mmc_suspend_host() is not able to claim the host and proceed with the suspend process. The core returns -EBUSY to the host controller driver. Unfortunately, the host controller driver does not pass on this information to the PM core and hence the system suspend process continues. In these cases the MMC core gets to an unexpected state during resume and multiple issues related to MMC crop up. 1. Host controller driver starts accessing the device registers before the clocks are enabled which leads to a prefetch abort. 2. A file copy thread which was launched before suspend gets stuck due to the host not being reclaimed during resume. To avoid such problems pass on the -EBUSY status to the PM core from the host controller driver. With this change, MMC core suspend might still fail but it does not end up making the system unusable. Suspend gets aborted and the user can try suspending the system again. The last time we discussed this, didn't we plan to fix this differently ? Holding the return code of mmc_suspend_host in a separate variable and passing it to the caller of omap_hsmmc_suspend looks more sane to me. I just pushed a new revision (V2) with above changes. I also added extra information (explanation with code snippet). Kindly let me know your review for the same. Regards, Gururaja -- 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] ARM: new cache maintenance api for iommu
From e88037801393f86ade3c79bcc900d3c84d989655 Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Wed, 12 Sep 2012 13:07:26 +0530
Subject: [PATCH v6 1/2] ARM: new cache maintenance api for iommu
Non-coherent IOMMU drivers need to make sure
that the data held in the caches is available
for the slave processor MMU hardware whenever
there is an update to the page table memory of
the slave processor.
The page table memory is always updated from
the main processor and read from the slave
processor MMU.
A new cache maintenance api iommu_flush_area is
added to handle this.The implementation is based
on the dma cache apis.
Thanks to RMK's suggestions on creating a
dedicated API for this purpose.
ref:http://marc.info/?l=linux-kernelm=131316512713815w=2
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
arch/arm/include/asm/cacheflush.h | 21 +
arch/arm/include/asm/glue-cache.h |1 +
arch/arm/mm/cache-fa.S| 16
arch/arm/mm/cache-v3.S| 14 +-
arch/arm/mm/cache-v4.S| 15 +++
arch/arm/mm/cache-v4wb.S | 22 ++
arch/arm/mm/cache-v4wt.S | 18 ++
arch/arm/mm/cache-v6.S| 21 +
arch/arm/mm/cache-v7.S| 22 ++
arch/arm/mm/proc-arm1020.S| 23 +++
arch/arm/mm/proc-arm1020e.S | 21 +
arch/arm/mm/proc-arm1022.S| 21 +
arch/arm/mm/proc-arm1026.S| 20
arch/arm/mm/proc-arm920.S | 18 ++
arch/arm/mm/proc-arm922.S | 18 ++
arch/arm/mm/proc-arm925.S | 23 +++
arch/arm/mm/proc-arm926.S | 23 +++
arch/arm/mm/proc-arm940.S | 26 ++
arch/arm/mm/proc-arm946.S | 25 +
arch/arm/mm/proc-feroceon.S | 32
arch/arm/mm/proc-macros.S |1 +
arch/arm/mm/proc-mohawk.S | 19 +++
arch/arm/mm/proc-xsc3.S | 18 ++
arch/arm/mm/proc-xscale.S | 20
24 files changed, 457 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index e4448e1..c772d75 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -84,6 +84,15 @@
* - kaddr - page address
* - size - region size
*
+ * iommu_flush_area(start, size)
+ *
+ * Perform CPU specific cache operations are required to ensure
+ * that the IOMMU page table mappings covering the speified block
+ * memory are visible to the IOMMU. This api is intended for the
+ * IOMMU page table memory, do not use this for the general data.
+ * - start - virtual start address
+ * - size - region size
+ *
* DMA Cache Coherency
* ===
*
@@ -108,6 +117,7 @@ struct cpu_cache_fns {
void (*dma_unmap_area)(const void *, size_t, int);
void (*dma_flush_range)(const void *, const void *);
+ void (*iommu_flush_area)(const void *, size_t);
};
/*
@@ -135,6 +145,12 @@ extern struct cpu_cache_fns cpu_cache;
#define dmac_unmap_areacpu_cache.dma_unmap_area
#define dmac_flush_range cpu_cache.dma_flush_range
+/* This API is to support non-coherent IOMMUs. The purpose of
+ * this API is to ensure that the data held in the cache is visible
+ * to the MMU of the slave processor. Do not use this for general data.
+ */
+#define iommu_flush_area (cpu_cache.iommu_flush_area)
+
#else
extern void __cpuc_flush_icache_all(void);
@@ -155,6 +171,11 @@ extern void dmac_map_area(const void *, size_t, int);
extern void dmac_unmap_area(const void *, size_t, int);
extern void dmac_flush_range(const void *, const void *);
+/* This API is to support non-coherent IOMMUs. The purpose of
+ * this API is to ensure that the data held in the cache is visible
+ * to the MMU of the slave processor. Do not use this for general data.
+ */
+extern void iommu_flush_area(const void *, size_t);
#endif
/*
diff --git a/arch/arm/include/asm/glue-cache.h
b/arch/arm/include/asm/glue-cache.h
index 7e30874..64f00b2 100644
--- a/arch/arm/include/asm/glue-cache.h
+++ b/arch/arm/include/asm/glue-cache.h
@@ -141,6 +141,7 @@
#define dmac_map_area __glue(_CACHE,_dma_map_area)
#define dmac_unmap_area__glue(_CACHE,_dma_unmap_area)
#define dmac_flush_range __glue(_CACHE,_dma_flush_range)
+#define iommu_flush_area __glue(_CACHE, _iommu_flush_area)
#endif
#endif
diff --git a/arch/arm/mm/cache-fa.S b/arch/arm/mm/cache-fa.S
index
[PATCH v6 2/2] OMAP:IOMMU:flush L1 and L2 caches
From a00cbfadc0053a3c21812593997a1b7338234a9f Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Wed, 12 Sep 2012 19:05:29 +0530
Subject: [PATCH v6 2/2] OMAP:IOMMU:flush L1 and L2 caches
OMAP IOMMU need to make sure that data in the L1 and L2 caches
is visible to the MMU hardware whenever the page tables are
updated. The current code only takes care of L1 cache using
assembly. Added code to handle this using a new L1 cache
maintenance function and the outer cache function.
Thanks to the RMK's suggestions.
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
drivers/iommu/omap-iommu.c | 40 ++--
1 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index d0b1234..d399493 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -469,24 +469,20 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
/*
* H/W pagetable operations
*/
-static void flush_iopgd_range(u32 *first, u32 *last)
+static void flush_iopgd_area(u32 *first, size_t size)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ phys_addr_t phys = virt_to_phys(first);
+
+ iommu_flush_area(first, size);
+ outer_flush_range(phys, phys + size);
}
-static void flush_iopte_range(u32 *first, u32 *last)
+static void flush_iopte_area(u32 *first, size_t size)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ phys_addr_t phys = virt_to_phys(first);
+
+ iommu_flush_area(first, size);
+ outer_flush_range(phys, phys + size);
}
static void iopte_free(u32 *iopte)
@@ -515,7 +511,7 @@ static u32 *iopte_alloc(struct omap_iommu *obj,
u32 *iopgd, u32 da)
return ERR_PTR(-ENOMEM);
*iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_area(iopgd, sizeof(*iopgd));
dev_vdbg(obj-dev, %s: a new pte:%p\n, __func__, iopte);
} else {
@@ -544,7 +540,7 @@ static int iopgd_alloc_section(struct omap_iommu
*obj, u32 da, u32 pa, u32 prot)
}
*iopgd = (pa IOSECTION_MASK) | prot | IOPGD_SECTION;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_area(iopgd, sizeof(*iopgd));
return 0;
}
@@ -561,7 +557,7 @@ static int iopgd_alloc_super(struct omap_iommu
*obj, u32 da, u32 pa, u32 prot)
for (i = 0; i 16; i++)
*(iopgd + i) = (pa IOSUPER_MASK) | prot | IOPGD_SUPER;
- flush_iopgd_range(iopgd, iopgd + 15);
+ flush_iopgd_area(iopgd, sizeof(*iopgd) * 16);
return 0;
}
@@ -574,7 +570,7 @@ static int iopte_alloc_page(struct omap_iommu
*obj, u32 da, u32 pa, u32 prot)
return PTR_ERR(iopte);
*iopte = (pa IOPAGE_MASK) | prot | IOPTE_SMALL;
- flush_iopte_range(iopte, iopte);
+ flush_iopte_area(iopte, sizeof(*iopte));
dev_vdbg(obj-dev, %s: da:%08x pa:%08x pte:%p *pte:%08x\n,
__func__, da, pa, iopte, *iopte);
@@ -599,7 +595,7 @@ static int iopte_alloc_large(struct omap_iommu
*obj, u32 da, u32 pa, u32 prot)
for (i = 0; i 16; i++)
*(iopte + i) = (pa IOLARGE_MASK) | prot | IOPTE_LARGE;
- flush_iopte_range(iopte, iopte + 15);
+ flush_iopte_area(iopte, sizeof(*iopte) * 16);
return 0;
}
@@ -702,7 +698,7 @@ static size_t iopgtable_clear_entry_core(struct
omap_iommu *obj, u32 da)
}
bytes *= nent;
memset(iopte, 0, nent * sizeof(*iopte));
- flush_iopte_range(iopte, iopte + (nent - 1) * sizeof(*iopte));
+ flush_iopte_area(iopte, (nent) * sizeof(*iopte));
/*
* do table walk to check if this table is necessary or not
@@ -724,7 +720,7 @@ static size_t iopgtable_clear_entry_core(struct
omap_iommu *obj, u32 da)
bytes *= nent;
}
memset(iopgd, 0, nent * sizeof(*iopgd));
- flush_iopgd_range(iopgd, iopgd + (nent - 1) * sizeof(*iopgd));
+ flush_iopgd_area(iopgd, (nent) * sizeof(*iopgd));
out:
return bytes;
}
@@ -768,7 +764,7 @@ static void iopgtable_clear_entry_all(struct
omap_iommu *obj)
iopte_free(iopte_offset(iopgd, 0));
*iopgd = 0;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_area(iopgd, sizeof(*iopgd));
}
flush_iotlb_all(obj);
--
1.7.0.4
--
regards
Ramesh Gupta G
--
To unsubscribe from this list: send the line
RE: [PATCH 4/4] can: c_can: Add d_can suspend resume support
Marc,
On Wed, Sep 12, 2012 at 18:32:53, Marc Kleine-Budde wrote:
On 09/12/2012 02:48 PM, AnilKumar, Chimata wrote:
Hi Marc,
On Tue, Sep 04, 2012 at 12:57:18, Marc Kleine-Budde wrote:
On 09/04/2012 08:14 AM, AnilKumar, Chimata wrote:
Marc,
Thanks for the comments,
On Tue, Sep 04, 2012 at 01:31:35, Marc Kleine-Budde wrote:
On 09/03/2012 01:52 PM, AnilKumar Ch wrote:
Adds suspend resume support to DCAN driver which enables
DCAN power down mode bit (PDR). Then DCAN will ack the local
power-down mode by setting PDA bit in STATUS register.
Also adds a status flag to know the status of DCAN module,
whether it is opened or not.
Use ndev-flags IFF_UP for that. Have a look at the at91_can driver
[1]. I'm not sure if you need locking here.
Then I can use this to check the status, lock is not
required.
[1] http://lxr.free-electrons.com/source/drivers/net/can/at91_can.c#L1198
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/net/can/c_can/c_can.c | 78
drivers/net/can/c_can/c_can.h |5 ++
drivers/net/can/c_can/c_can_platform.c | 70
++--
3 files changed, 150 insertions(+), 3 deletions(-)
[snip]
+#ifdef CONFIG_PM
+int c_can_power_down(struct net_device *dev)
+{
+ unsigned long time_out;
+ struct c_can_priv *priv = netdev_priv(dev);
+
+ if (!priv-is_opened)
+ return 0;
Should we add a BUG_ON(id-driver_data != BOSCH_D_CAN)?
These APIs are called from platform driver where device type
device type is verified. I think we have to add BUG_ON() in
platform driver.
The platform driver returns if not on D_CAN and will not call this
function. But this functions are exported, so can be called by someone
else. So if the caller is not D_CAN, it's a bug.
I agree with you, but I have some concern here.
I think we should do return 0; instead of BUG_ON(). With
BUG_ON() system will hang and ultimately user lost his/her
contents.
Good point, better safe then sorry.
But this should not happen. What about WARN_ON()?
Either would be fine printing a warning message or WARN_ON()
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 5/7] ARM: OMAP2+: PM debug: trace the functional power domains states
HI Kevin,
On Thu, Sep 13, 2012 at 1:47 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Trace the power domain transitions using the functional power states,
which include the power and logic states.
Just to be clear, this means that a trace will only contain functional
power state changes, not logical ones, correct?
Correct! The trace reports functional states, while pr_err and
pr_debug statements (added by patch 6/7) are present for hardcore
debugging on the functional and internal states.
While at it, fix the trace in the case a power domain did not hit
the desired state, as reported by Paul Walmsley.
What was broken here? needs a bit more description.
Ok will do
To me it sounds
like a fix that should be a separate patch.
I kept the fix in this patch since it matches $SUBJECT. Can be split
if needed though.
Thanks for reviewing!
Jean
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 267241f..2277ad3 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -144,7 +144,7 @@ static void _update_logic_membank_counters(struct
powerdomain *pwrdm)
static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
{
- int prev, state, trace_state = 0;
+ int prev, next, state, trace_state;
if (pwrdm == NULL)
return -EINVAL;
@@ -165,10 +165,10 @@ static int _pwrdm_state_switch(struct powerdomain
*pwrdm, int flag)
* If the power domain did not hit the desired state,
* generate a trace event with both the desired and hit states
*/
- if (state != prev) {
+ next = pwrdm_read_next_fpwrst(pwrdm);
+ if (next != prev) {
trace_state = (PWRDM_TRACE_STATES_FLAG |
-((state OMAP_POWERSTATE_MASK) 8) |
-((prev OMAP_POWERSTATE_MASK) 0));
+(next 8) | (prev 0));
trace_power_domain_target(pwrdm-name, trace_state,
smp_processor_id());
}
@@ -723,6 +723,10 @@ int pwrdm_set_fpwrst(struct powerdomain *pwrdm, enum
pwrdm_func_state fpwrst)
}
}
+ /* Trace the pwrdm desired target state */
+ trace_power_domain_target(pwrdm-name, next_fpwrst,
+ smp_processor_id());
Use of smp_processor_id() here will require the same care as pointed out
by Roger Quadros in [PATCH] perf: Use raw_smp_processor_id insted of
smp_processor_id.
Kevin
if (logic != pwrdm_read_logic_retst(pwrdm))
pwrdm_set_logic_retst(pwrdm, logic);
@@ -776,6 +780,10 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
spin_lock_irqsave(pwrdm-lock, flags);
+ /* Trace the pwrdm desired target state */
+ trace_power_domain_target(pwrdm-name, fpwrst,
+ smp_processor_id());
+
ret = pwrdm_set_logic_retst(pwrdm, logic);
if (ret)
pr_err(%s: unable to set logic state %0x of powerdomain:
%s\n,
@@ -821,13 +829,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
pwrst)
pr_debug(powerdomain: setting next powerstate for %s to %0x\n,
pwrdm-name, pwrst);
- if (arch_pwrdm arch_pwrdm-pwrdm_set_next_pwrst) {
- /* Trace the pwrdm desired target state */
- trace_power_domain_target(pwrdm-name, pwrst,
- smp_processor_id());
- /* Program the pwrdm desired target state */
+ if (arch_pwrdm arch_pwrdm-pwrdm_set_next_pwrst)
ret = arch_pwrdm-pwrdm_set_next_pwrst(pwrdm, pwrst);
- }
return ret;
}
--
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 7/7] ARM: OMAP2+: PM: reorganize the powerdomain API in public and private parts
On Thu, Sep 13, 2012 at 2:11 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: The newly added code for functional power states re-defines the API to query and control the power domains settings. The API is now split in the following parts in powerdomain.h: - the public or external API, to be used by external PM components: cpuidle, suspend, pm, clock* etc. - the private or internal API, to be used by the low level PM code only: powerdomain*, pm-debug, hwmod, voltage, clockdomain. The function omap_set_pwrdm_state is not used anymore and so is removed. No functional change is introduced by this patch. Note: the API reorganization in a public and private header files is not part of this patch, this comes as a subsequent clean-up patch series. Signed-off-by: Jean Pihet j-pi...@ti.com In addition to reorganizing the API, I suspect there are a handful of out-of-tree hacks, er, users, that will are using the internal state names, as well as the functions that should now only be internal. The API clean-up series (planned after this one is in the queue) will sort out the public vs private APIs using different header files and static functions. As part of the subsequent cleanup series, it would it make sense to add a '_' prefix to the internal names as well to catch unintentional use of internal APIs? Sure. Kevin Thanks, Jean -- 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] can: c_can: Move pm_runtime_enable/disable calls to common code
Move pm_runtime_enable/disable calls to c_can.c driver. Current
implementation is such that platform driver is doing pm_runtime
enable/disable and core driver is doing put_sync/get_sync.
PM runtime calls should be invoked if there is a valid device
pointer from platform driver so moving enable/disable calls
to core driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Incorporated Kevin's comments on can: c_can: Add runtime PM
support to Bosch C_CAN/D_CAN controller patch.
This patch is tested on AM335x-EVM and cleanly applies on
linux-can master
drivers/net/can/c_can/c_can.c | 18 +-
drivers/net/can/c_can/c_can_platform.c |5 -
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index aa6c5eb..e472975 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -1155,10 +1155,23 @@ static const struct net_device_ops c_can_netdev_ops = {
int register_c_can_dev(struct net_device *dev)
{
+ int ret;
+ struct c_can_priv *priv = netdev_priv(dev);
+
+ if (priv-device)
+ pm_runtime_enable(priv-device);
+
dev-flags |= IFF_ECHO; /* we support local echo */
dev-netdev_ops = c_can_netdev_ops;
- return register_candev(dev);
+ ret = register_candev(dev);
+ if (ret) {
+ if (priv-device)
+ pm_runtime_disable(priv-device);
+ return ret;
+ }
+
+ return 0;
}
EXPORT_SYMBOL_GPL(register_c_can_dev);
@@ -1170,6 +1183,9 @@ void unregister_c_can_dev(struct net_device *dev)
c_can_enable_all_interrupts(priv, DISABLE_ALL_INTERRUPTS);
unregister_candev(dev);
+
+ if (priv-device)
+ pm_runtime_disable(priv-device);
}
EXPORT_SYMBOL_GPL(unregister_c_can_dev);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index c351975..491101a 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,7 +32,6 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
-#include linux/pm_runtime.h
#include linux/pinctrl/consumer.h
#include linux/can/dev.h
@@ -185,8 +184,6 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
goto exit_free_device;
}
- pm_runtime_enable(pdev-dev);
-
dev-irq = irq;
priv-base = addr;
priv-device = pdev-dev;
@@ -209,7 +206,6 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
exit_clear_drvdata:
platform_set_drvdata(pdev, NULL);
- pm_runtime_disable(pdev-dev);
exit_free_device:
free_c_can_dev(dev);
exit_iounmap:
@@ -239,7 +235,6 @@ static int __devexit c_can_plat_remove(struct
platform_device *pdev)
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(mem-start, resource_size(mem));
- pm_runtime_disable(pdev-dev);
clk_put(priv-priv);
return 0;
--
1.7.0.4
--
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 5/7] ARM: OMAP2+: PM debug: trace the functional power domains states
On Thu, Sep 13, 2012 at 1:47 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Use of smp_processor_id() here will require the same care as pointed out by Roger Quadros in [PATCH] perf: Use raw_smp_processor_id insted of smp_processor_id. BTW it looks like get_cpu and put_cpu is the way to go, as pointed out by Russell. Jean -- 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] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
On 09/13/2012 09:52 AM, Linus Walleij wrote: On Wed, Sep 12, 2012 at 10:27 PM, Tony Lindgren t...@atomide.com wrote: * Peter Ujfalusi peter.ujfal...@ti.com [120911 01:54]: With pinctrl-single,bits it is possible to update just part of the register within the pinctrl-single,function-mask area. This is useful when one register configures mmore than one pin's mux. size /= sizeof(*mux); /* Number of elements in array */ - rows = size / 2;/* Each row is a key value pair */ + rows = size / params; /* Each row is a key value pair */ Maybe just remove the comment: ^^ I don't think it's needed any longer. Other than that, thanks for updating the patch: Acked-by: Tony Lindgren t...@atomide.com Applied minus the comment, plus Tony's ACK, thanks! Thank you Linus, I was about to send the v3 with the removed comment. -- 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: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend
On Wed, 2012-09-12 at 16:11 -0700, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: [...] It kind of looks to me like there are two or three separate sets within the series. My feeling is that Kevin should take the first two, then I should take the rest other than 6 and 7. Then once those are queued, we can pull in 6 and 7. Does that make sense to you? Looks like 1, 2 7 are needed for OSWR, and the rest can go now via Paul. Tero, can create a new OSWR series including 1, 2 7? Can you also refresh it against Jean's latest functional power state series (v6)? Yes, I already have these patches locally available. I'll just refresh them against Paul's minor tweaks on rest of the patches and re-post. -Tero -- 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] can: c_can: Move pm_runtime_enable/disable calls to common code
On 09/13/2012 09:28 AM, AnilKumar Ch wrote:
Move pm_runtime_enable/disable calls to c_can.c driver. Current
implementation is such that platform driver is doing pm_runtime
enable/disable and core driver is doing put_sync/get_sync.
PM runtime calls should be invoked if there is a valid device
pointer from platform driver so moving enable/disable calls
to core driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Incorporated Kevin's comments on can: c_can: Add runtime PM
support to Bosch C_CAN/D_CAN controller patch.
This patch is tested on AM335x-EVM and cleanly applies on
linux-can master
I'll squash this into can: c_can: Add runtime PM support to Bosch
C_CAN/D_CAN controller.
drivers/net/can/c_can/c_can.c | 18 +-
drivers/net/can/c_can/c_can_platform.c |5 -
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index aa6c5eb..e472975 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -1155,10 +1155,23 @@ static const struct net_device_ops c_can_netdev_ops =
{
int register_c_can_dev(struct net_device *dev)
{
+ int ret;
+ struct c_can_priv *priv = netdev_priv(dev);
+
+ if (priv-device)
+ pm_runtime_enable(priv-device);
I'll add a static inline for these two new function, too.
+
dev-flags |= IFF_ECHO; /* we support local echo */
dev-netdev_ops = c_can_netdev_ops;
- return register_candev(dev);
+ ret = register_candev(dev);
+ if (ret) {
+ if (priv-device)
+ pm_runtime_disable(priv-device);
+ return ret;
+ }
+
+ return 0;
}
EXPORT_SYMBOL_GPL(register_c_can_dev);
@@ -1170,6 +1183,9 @@ void unregister_c_can_dev(struct net_device *dev)
c_can_enable_all_interrupts(priv, DISABLE_ALL_INTERRUPTS);
unregister_candev(dev);
+
+ if (priv-device)
+ pm_runtime_disable(priv-device);
}
EXPORT_SYMBOL_GPL(unregister_c_can_dev);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index c351975..491101a 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,7 +32,6 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
-#include linux/pm_runtime.h
#include linux/pinctrl/consumer.h
#include linux/can/dev.h
@@ -185,8 +184,6 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
goto exit_free_device;
}
- pm_runtime_enable(pdev-dev);
-
dev-irq = irq;
priv-base = addr;
priv-device = pdev-dev;
@@ -209,7 +206,6 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
exit_clear_drvdata:
platform_set_drvdata(pdev, NULL);
- pm_runtime_disable(pdev-dev);
When squaahsing both patches we see still some changes here, I'll fix
that, too.
exit_free_device:
free_c_can_dev(dev);
exit_iounmap:
@@ -239,7 +235,6 @@ static int __devexit c_can_plat_remove(struct
platform_device *pdev)
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(mem-start, resource_size(mem));
- pm_runtime_disable(pdev-dev);
clk_put(priv-priv);
return 0;
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 00/11] ASoC: OMAP: Convert to use dmaengine
On Wed, Sep 12, 2012 at 02:46:56PM +0300, Peter Ujfalusi wrote: Hello, 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. I'm fine with this from the ASoC side but it sounds like you're going to respin anyway. Are the earlier bits of the series safe to apply without the last bit, it seems like that's the only bit that really needs a respin so we may as well go ahead and apply the earlier bits now? -- 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] can: c_can: Move pm_runtime_enable/disable calls to common code
Marc,
On Thu, Sep 13, 2012 at 13:18:07, Marc Kleine-Budde wrote:
On 09/13/2012 09:28 AM, AnilKumar Ch wrote:
Move pm_runtime_enable/disable calls to c_can.c driver. Current
implementation is such that platform driver is doing pm_runtime
enable/disable and core driver is doing put_sync/get_sync.
PM runtime calls should be invoked if there is a valid device
pointer from platform driver so moving enable/disable calls
to core driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Incorporated Kevin's comments on can: c_can: Add runtime PM
support to Bosch C_CAN/D_CAN controller patch.
This patch is tested on AM335x-EVM and cleanly applies on
linux-can master
I'll squash this into can: c_can: Add runtime PM support to Bosch
C_CAN/D_CAN controller.
drivers/net/can/c_can/c_can.c | 18 +-
drivers/net/can/c_can/c_can_platform.c |5 -
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index aa6c5eb..e472975 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -1155,10 +1155,23 @@ static const struct net_device_ops c_can_netdev_ops
= {
int register_c_can_dev(struct net_device *dev)
{
+ int ret;
+ struct c_can_priv *priv = netdev_priv(dev);
+
+ if (priv-device)
+ pm_runtime_enable(priv-device);
I'll add a static inline for these two new function, too.
My bad, this should be my first change.
+
dev-flags |= IFF_ECHO; /* we support local echo */
dev-netdev_ops = c_can_netdev_ops;
- return register_candev(dev);
+ ret = register_candev(dev);
+ if (ret) {
+ if (priv-device)
+ pm_runtime_disable(priv-device);
+ return ret;
+ }
+
+ return 0;
}
EXPORT_SYMBOL_GPL(register_c_can_dev);
@@ -1170,6 +1183,9 @@ void unregister_c_can_dev(struct net_device *dev)
c_can_enable_all_interrupts(priv, DISABLE_ALL_INTERRUPTS);
unregister_candev(dev);
+
+ if (priv-device)
+ pm_runtime_disable(priv-device);
}
EXPORT_SYMBOL_GPL(unregister_c_can_dev);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index c351975..491101a 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,7 +32,6 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
-#include linux/pm_runtime.h
#include linux/pinctrl/consumer.h
#include linux/can/dev.h
@@ -185,8 +184,6 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
goto exit_free_device;
}
- pm_runtime_enable(pdev-dev);
-
dev-irq = irq;
priv-base = addr;
priv-device = pdev-dev;
@@ -209,7 +206,6 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
exit_clear_drvdata:
platform_set_drvdata(pdev, NULL);
- pm_runtime_disable(pdev-dev);
When squaahsing both patches we see still some changes here, I'll fix
that, too.
Thanks Marc
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 4/4] can: c_can: Add d_can suspend resume support
On 09/13/2012 09:24 AM, AnilKumar, Chimata wrote:
Marc,
On Wed, Sep 12, 2012 at 18:32:53, Marc Kleine-Budde wrote:
On 09/12/2012 02:48 PM, AnilKumar, Chimata wrote:
Hi Marc,
On Tue, Sep 04, 2012 at 12:57:18, Marc Kleine-Budde wrote:
On 09/04/2012 08:14 AM, AnilKumar, Chimata wrote:
Marc,
Thanks for the comments,
On Tue, Sep 04, 2012 at 01:31:35, Marc Kleine-Budde wrote:
On 09/03/2012 01:52 PM, AnilKumar Ch wrote:
Adds suspend resume support to DCAN driver which enables
DCAN power down mode bit (PDR). Then DCAN will ack the local
power-down mode by setting PDA bit in STATUS register.
Also adds a status flag to know the status of DCAN module,
whether it is opened or not.
Use ndev-flags IFF_UP for that. Have a look at the at91_can driver
[1]. I'm not sure if you need locking here.
Then I can use this to check the status, lock is not
required.
[1] http://lxr.free-electrons.com/source/drivers/net/can/at91_can.c#L1198
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/net/can/c_can/c_can.c | 78
drivers/net/can/c_can/c_can.h |5 ++
drivers/net/can/c_can/c_can_platform.c | 70
++--
3 files changed, 150 insertions(+), 3 deletions(-)
[snip]
+#ifdef CONFIG_PM
+int c_can_power_down(struct net_device *dev)
+{
+ unsigned long time_out;
+ struct c_can_priv *priv = netdev_priv(dev);
+
+ if (!priv-is_opened)
+ return 0;
Should we add a BUG_ON(id-driver_data != BOSCH_D_CAN)?
These APIs are called from platform driver where device type
device type is verified. I think we have to add BUG_ON() in
platform driver.
The platform driver returns if not on D_CAN and will not call this
function. But this functions are exported, so can be called by someone
else. So if the caller is not D_CAN, it's a bug.
I agree with you, but I have some concern here.
I think we should do return 0; instead of BUG_ON(). With
BUG_ON() system will hang and ultimately user lost his/her
contents.
Good point, better safe then sorry.
But this should not happen. What about WARN_ON()?
Either would be fine printing a warning message or WARN_ON()
I'm for a WARN_ON()
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv8 00/23]I2C big cleanup
Hi Kevin, 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. I thought I'll give you guys some more days to fix the problem before reverting. With that patch reverted, all my PM tests are passing. Feel free to add: Tested-by: Kevin Hilman khil...@ti.com Thanks. That indeed increases confidence in this series. I won't add the tags to the tree, though, since that would mean rebasing. All the best, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 2/2] ARM: OMAP5: Enable arch timer support
Hi Santosh,
On 09/11/2012 11:29 AM, Shilimkar, Santosh wrote:
Benoit,
On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote:
[...]
Silly question: Don't we have one arch-timer per CPU?
It is per CPU just like A9 TWD
Shouldn't we have two nodes then?
I need to check this but arch timer DT node should be same
as the twd DT node. May be one node with reference to
each CPU node should do but am not too sure about the DT
nodes and how all that work.
Here is an updated patch based on our discussion. Thanks for comments.
Let me know if you are ok with this version.
Cool, thanks for the update.
From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 13 Aug 2012 14:39:03 +0530
Subject: [PATCH] ARM: OMAP5: Enable arch timer support
Enable Cortex A15 generic timer support for OMAP5 based SOCs.
The CPU local timers run on the free running real time counter clock.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
Tony,
I can potentially add it along with the timer changes in the dts part2
series if you ack the timer patch. We don't have tons of OMAP5 content
in the dts branch so it should not conflict.
Regards,
Benoit
---
arch/arm/boot/dts/omap5.dtsi | 12
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/timer.c |7 +++
3 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..7b986ed 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -33,9 +33,21 @@
cpus {
cpu@0 {
compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /* 14th PPI IRQ, active low level-sensitive */
+ interrupts = 1 14 0x308;
+ clock-frequency = 6144000;
+ };
};
cpu@1 {
compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /* 14th PPI IRQ, active low level-sensitive */
+ interrupts = 1 14 0x308;
+ clock-frequency = 6144000;
+ };
};
};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2120f90..53fb77c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -73,6 +73,7 @@ config SOC_OMAP5
select ARM_GIC
select HAVE_SMP
select SOC_HAS_REALTIME_COUNTER
+ select ARM_ARCH_TIMER
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 8f5b88b..46982d0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -41,6 +41,7 @@
#include plat/dmtimer.h
#include asm/smp_twd.h
#include asm/sched_clock.h
+#include asm/arch_timer.h
#include common.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
@@ -481,9 +482,15 @@ OMAP_SYS_TIMER(4)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_timer_init(void)
{
+ int err;
+
omap2_gp_clockevent_init(1, OMAP4_CLKEV_SOURCE);
omap2_clocksource_init(2, OMAP4_MPU_SOURCE);
realtime_counter_init();
+
+ err = arch_timer_of_register();
+ if (err)
+ pr_err(%s: arch_timer_register failed %d\n, __func__, err);
}
OMAP_SYS_TIMER(5)
#endif
--
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: OMAP5: Enable arch timer support
On Thu, Sep 13, 2012 at 2:26 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Santosh, On 09/11/2012 11:29 AM, Shilimkar, Santosh wrote: Benoit, On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote: [...] Silly question: Don't we have one arch-timer per CPU? It is per CPU just like A9 TWD Shouldn't we have two nodes then? I need to check this but arch timer DT node should be same as the twd DT node. May be one node with reference to each CPU node should do but am not too sure about the DT nodes and how all that work. Here is an updated patch based on our discussion. Thanks for comments. Let me know if you are ok with this version. Cool, thanks for the update. From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Mon, 13 Aug 2012 14:39:03 +0530 Subject: [PATCH] ARM: OMAP5: Enable arch timer support Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Thanks Benoit. Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yep. let me know what works. if needed I can put these two patches on a branch and send a pull request. Regards santosh -- 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/11] ASoC: OMAP: Convert to use dmaengine
On 09/13/2012 11:11 AM, Mark Brown wrote: On Wed, Sep 12, 2012 at 02:46:56PM +0300, Peter Ujfalusi wrote: Hello, 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. I'm fine with this from the ASoC side but it sounds like you're going to respin anyway. Are the earlier bits of the series safe to apply without the last bit, it seems like that's the only bit that really needs a respin so we may as well go ahead and apply the earlier bits now? Yes, I'm preparing the second series (adding the pause/resume support). Patch 2-10 is to prepare the OMAP audio drivers for the dmaengine conversion they can be applied earlier IMHO. I can in turn can send only dmaengine related patches in v2 (patch 1 and 10 from this series and additional ones). Anyways I need some time to figure out how to add back the support for SNDRV_PCM_INFO_NO_PERIOD_WAKEUP. Either way is good for me. -- 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 2/2] ARM: OMAP5: Enable arch timer support
On 09/13/2012 11:00 AM, Shilimkar, Santosh wrote: On Thu, Sep 13, 2012 at 2:26 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Santosh, On 09/11/2012 11:29 AM, Shilimkar, Santosh wrote: Benoit, On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote: [...] Silly question: Don't we have one arch-timer per CPU? It is per CPU just like A9 TWD Shouldn't we have two nodes then? I need to check this but arch timer DT node should be same as the twd DT node. May be one node with reference to each CPU node should do but am not too sure about the DT nodes and how all that work. Here is an updated patch based on our discussion. Thanks for comments. Let me know if you are ok with this version. Cool, thanks for the update. From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Mon, 13 Aug 2012 14:39:03 +0530 Subject: [PATCH] ARM: OMAP5: Enable arch timer support Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Thanks Benoit. Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yep. let me know what works. if needed I can put these two patches on a branch and send a pull request. It does not apply to the current devel-dt, what base did you used? Regards, Benoit -- 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: OMAP5: Enable arch timer support
On Thu, Sep 13, 2012 at 2:57 PM, Benoit Cousson b-cous...@ti.com wrote: On 09/13/2012 11:00 AM, Shilimkar, Santosh wrote: On Thu, Sep 13, 2012 at 2:26 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Santosh, On 09/11/2012 11:29 AM, Shilimkar, Santosh wrote: Benoit, On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote: [...] Silly question: Don't we have one arch-timer per CPU? It is per CPU just like A9 TWD Shouldn't we have two nodes then? I need to check this but arch timer DT node should be same as the twd DT node. May be one node with reference to each CPU node should do but am not too sure about the DT nodes and how all that work. Here is an updated patch based on our discussion. Thanks for comments. Let me know if you are ok with this version. Cool, thanks for the update. From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Mon, 13 Aug 2012 14:39:03 +0530 Subject: [PATCH] ARM: OMAP5: Enable arch timer support Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Thanks Benoit. Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yep. let me know what works. if needed I can put these two patches on a branch and send a pull request. It does not apply to the current devel-dt, what base did you used? Mainline 3.6-rc3. Just refreshed the patches against devel-dt. The Kconfig file had a minor conflict. Updated patches are updated. Regards Santosh 0001-ARM-OMAP-Add-initialisation-for-the-real-time-counte.patch Description: Binary data 0002-ARM-OMAP5-Enable-arch-timer-support.patch Description: Binary data
Re: [PATCH 2/2] ARM: OMAP5: Enable arch timer support
On Thu, Sep 13, 2012 at 3:30 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, Sep 13, 2012 at 2:57 PM, Benoit Cousson b-cous...@ti.com wrote: On 09/13/2012 11:00 AM, Shilimkar, Santosh wrote: On Thu, Sep 13, 2012 at 2:26 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Santosh, On 09/11/2012 11:29 AM, Shilimkar, Santosh wrote: Benoit, On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote: [...] Silly question: Don't we have one arch-timer per CPU? It is per CPU just like A9 TWD Shouldn't we have two nodes then? I need to check this but arch timer DT node should be same as the twd DT node. May be one node with reference to each CPU node should do but am not too sure about the DT nodes and how all that work. Here is an updated patch based on our discussion. Thanks for comments. Let me know if you are ok with this version. Cool, thanks for the update. From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Mon, 13 Aug 2012 14:39:03 +0530 Subject: [PATCH] ARM: OMAP5: Enable arch timer support Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Thanks Benoit. Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yep. let me know what works. if needed I can put these two patches on a branch and send a pull request. It does not apply to the current devel-dt, what base did you used? Mainline 3.6-rc3. Just refreshed the patches against devel-dt. The Kconfig file had a minor conflict. Updated patches. Let me know if they apply ok for you ? Regards Santosh -- 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 6/6] ARM: mm: update __v7_setup() to the new LoUIS cache maintenance API
From: Santosh Shilimkar santosh.shilim...@ti.com
The ARMv7 processor setup function __v7_setup() cleans and invalidates the
CPU cache before enabling MMU to start the CPU with a clean CPU local cache.
But on ARMv7 architectures like Cortex-[A15/A8], this code will end
up flushing the L2 caches(up to level of Coherency) which is undesirable
and expensive. The setup functions are used in the CPU hotplug scenario too
and hence flushing all cache levels should be avoided.
This patch replaces the cache flushing call with the newly introduced
v7 dcache LoUIS API where only cache levels up to LoUIS are cleaned and
invalidated when a processors executes __v7_setup which is the expected
behavior.
For processors like A9 and A5 where the L2 cache is an outer one the
behavior should be unchanged.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/mm/proc-v7.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index c2e2b66..846d279 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -172,7 +172,7 @@ __v7_ca15mp_setup:
__v7_setup:
adr r12, __v7_setup_stack @ the local stack
stmia r12, {r0-r5, r7, r9, r11, lr}
- bl v7_flush_dcache_all
+ bl v7_flush_dcache_louis
ldmia r12, {r0-r5, r7, r9, r11, lr}
mrc p15, 0, r0, c0, c0, 0 @ read main ID register
--
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
[RFC PATCH 4/6] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
In processors like A15/A7 L2 cache is unified and integrated within the
processor cache hierarchy, so that it is not considered an outer cache
anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
all cache levels up to Level of Coherency (LoC) that includes
the L2 unified cache.
When a single CPU is suspended (CPU idle) a complete L2 clean is not
required, so generic cpu_suspend code must clean the data cache using the
newly introduced cache LoUIS function.
The context and stack pointer (context pointer) are cleaned to main memory
using cache area functions that operate on MVA and guarantee that the data
is written back to main memory (perform cache cleaning up to the Point of
Coherency - PoC) so that the processor can fetch the context when the MMU
is off in the cpu_resume code path.
outer_cache management remains unchanged.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/suspend.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 1794cc3..358bca3 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -17,6 +17,8 @@ extern void cpu_resume_mmu(void);
*/
void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
{
+ u32 *ctx = ptr;
+
*save_ptr = virt_to_phys(ptr);
/* This must correspond to the LDM in cpu_resume() assembly */
@@ -26,7 +28,20 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32
*save_ptr)
cpu_do_suspend(ptr);
- flush_cache_all();
+ flush_cache_louis();
+
+ /*
+* flush_cache_louis does not guarantee that
+* save_ptr and ptr are cleaned to main memory,
+* just up to the Level of Unification Inner Shareable.
+* Since the context pointer and context itself
+* are to be retrieved with the MMU off that
+* data must be cleaned from all cache levels
+* to main memory using area cache primitives.
+ */
+ __cpuc_flush_dcache_area(ctx, ptrsz);
+ __cpuc_flush_dcache_area(save_ptr, sizeof(*save_ptr));
+
outer_clean_range(*save_ptr, *save_ptr + ptrsz);
outer_clean_range(virt_to_phys(save_ptr),
virt_to_phys(save_ptr) + sizeof(*save_ptr));
--
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
[RFC PATCH 5/6] ARM: kernel: update __cpu_disable to use cache LoUIS maintenance API
When a CPU is hotplugged out caches that reside in its power domain lose their contents and so must be cleaned to the next memory level. Currently, __cpu_disable calls flush_cache_all() that for new generation processor like A15/A7 ends up cleaning and invalidating all cache levels up to Level of Coherency, which includes the unified L2. This ends up being a waste of cycles since the L2 cache contents are not lost on power down. This patch updates __cpu_disable to use the new LoUIS API cache operations. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- arch/arm/kernel/smp.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index d3eb222..f44e9cd 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -136,8 +136,11 @@ int __cpu_disable(void) /* * Flush user cache and TLB mappings, and then remove this CPU * from the vm mask set of all processes. +* +* Caches are flushed to the Level of Unification Inner Shareable +* to write-back dirty lines to unified caches shared by all CPUs. */ - flush_cache_all(); + flush_cache_louis(); local_flush_tlb_all(); clear_tasks_mm_cpumask(cpu); -- 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
[RFC PATCH 2/6] ARM: mm: add v7 cache LoUIS API implementation
ARM v7 architecture introduces the concept of cache levels and registers to
probe and manage cache levels accordingly.
This patch adds v7 support for cache LoUIS (Level of Unification Inner
Shareable) operations and defines a function that allows to clean and
invalidate data caches up to LoUIS.
Power-down operations like hotplug and CPU idle require to clean/invalidate
only cache levels that are within the CPU power domain, and LoUIS reflects
this requirement properly in most of the systems.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/mm/cache-v7.S | 42 +++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index 39e3fb3..74aec79 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -33,6 +33,24 @@ ENTRY(v7_flush_icache_all)
mov pc, lr
ENDPROC(v7_flush_icache_all)
+ /*
+ * v7_flush_dcache_louis()
+ *
+ * Flush the D-cache up to the Level of Unification Inner Shareable
+ *
+ * Corrupted registers: r0-r7, r9-r11 (r6 only in Thumb mode)
+ */
+
+ENTRY(v7_flush_dcache_louis)
+ dmb @ ensure ordering with previous
memory accesses
+ mrc p15, 1, r0, c0, c0, 1 @ read clidr
+ andsr3, r0, #0xe0 @ extract louis from clidr
+ mov r3, r3, lsr #20 @ left align louis bit field
+ moveq pc, lr @ return if level == 0
+ mov r10, #0 @ starting level == 0
+ b __flush_level
+ENDPROC(v7_flush_dcache_louis)
+
/*
* v7_flush_dcache_all()
*
@@ -49,7 +67,7 @@ ENTRY(v7_flush_dcache_all)
mov r3, r3, lsr #23 @ left align loc bit field
beq finished@ if loc is 0, then no need to
clean
mov r10, #0 @ start clean at cache level 0
-loop1:
+__flush_level:
add r2, r10, r10, lsr #1@ work out 3x current cache
level
mov r1, r0, lsr r2 @ extract cache type bits from
clidr
and r1, r1, #7 @ mask of the bits for current
cache only
@@ -88,7 +106,7 @@ loop3:
skip:
add r10, r10, #2@ increment cache number
cmp r3, r10
- bgt loop1
+ bgt __flush_level
finished:
mov r10, #0 @ swith back to cache level 0
mcr p15, 2, r10, c0, c0, 0 @ select current cache level in
cssr
@@ -120,6 +138,24 @@ ENTRY(v7_flush_kern_cache_all)
mov pc, lr
ENDPROC(v7_flush_kern_cache_all)
+ /*
+ * v7_flush_kern_cache_louis(void)
+ *
+ * Flush the data cache up to Level of Unification Inner Shareable.
+ * Invalidate the I-cache to the point of unification.
+ */
+ENTRY(v7_flush_kern_cache_louis)
+ ARM( stmfd sp!, {r4-r5, r7, r9-r11, lr})
+ THUMB(stmfd sp!, {r4-r7, r9-r11, lr})
+ bl v7_flush_dcache_louis
+ mov r0, #0
+ ALT_SMP(mcr p15, 0, r0, c7, c1, 0) @ invalidate I-cache inner
shareable
+ ALT_UP(mcr p15, 0, r0, c7, c5, 0) @ I+BTB cache invalidate
+ ARM( ldmfd sp!, {r4-r5, r7, r9-r11, lr})
+ THUMB(ldmfd sp!, {r4-r7, r9-r11, lr})
+ mov pc, lr
+ENDPROC(v7_flush_kern_cache_louis)
+
/*
* v7_flush_cache_all()
*
@@ -350,4 +386,4 @@ ENDPROC(v7_dma_unmap_area)
__INITDATA
@ define struct cpu_cache_fns (see asm/cacheflush.h and proc-macros.S)
- define_cache_functions v7
+ define_cache_functions v7, cachelouis=1
--
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
[RFC PATCH 1/6] ARM: mm: define LoUIS API for cache maintenance ops
ARM v7 architecture introduced the concept of cache levels and related
coherency requirements. New processors like A7 and A15 embed an
L2 unified cache controller that becomes part of the cache level
hierarchy. Some operations in the kernel like cpu_suspend and __cpu_disable
does not require a flush of the entire cache hierarchy to DRAM but just the
cache levels belonging to the Level of Unification Inner Shareable (LoUIS),
which in most of ARM v7 systems correspond to L1.
The current cache flushing API used in cpu_suspend and __cpu_disable,
flush_cache_all(), ends up flushing the whole cache hierarchy since for
v7 it cleans and invalidates all cache levels up to Level of Coherency
(LoC) which cripples system performance when used in hot paths like hotplug
and cpuidle.
Therefore a new kernel cache maintenance API must be added to the
cpu_cache_fns structure of pointers to cope with latest ARM system requirements.
This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.
This function cleans and invalidates all data cache levels up to the
level of unification inner shareable (LoUIS) and invalidates the instruction
cache.
The cpu_cache_fns struct reflects this change by adding a new function pointer
that is initialized by arch specific assembly files.
By default, all existing ARM archs do not instantiate any cache LoUIS function
pointer, and flush_dcache_louis just falls back to flush_kern_all.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/include/asm/cacheflush.h | 17 +
arch/arm/mm/proc-macros.S | 7 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index c6e2ed9..7683316 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -50,6 +50,13 @@
*
* Unconditionally clean and invalidate the entire cache.
*
+ * flush_kern_cache_louis()
+ *
+ * Flush data cache levels up to the level of unification
+ * inner shareable and invalidate the I-cache.
+ * Only needed from v7 onwards, falls back to flush_cache_all()
+ * for all other processor versions.
+ *
* flush_user_all()
*
* Clean and invalidate all user space cache entries
@@ -98,6 +105,7 @@
struct cpu_cache_fns {
void (*flush_icache_all)(void);
void (*flush_kern_all)(void);
+ void (*flush_kern_cache_louis)(void);
void (*flush_user_all)(void);
void (*flush_user_range)(unsigned long, unsigned long, unsigned int);
@@ -200,6 +208,15 @@ extern void copy_to_user_page(struct vm_area_struct *,
struct page *,
#define __flush_icache_preferred __flush_icache_all_generic
#endif
+/*
+ * Flush caches up to Level of Unification Inner Shareable
+ */
+#ifdef MULTI_CACHE
+#define flush_cache_louis() cpu_cache.flush_kern_cache_louis()
+#else
+#define flush_cache_louis() __cpuc_flush_kern_all()
+#endif
+
static inline void __flush_icache_all(void)
{
__flush_icache_preferred();
diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index 2d8ff3a..28e91f8 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -293,12 +293,17 @@ ENTRY(\name\()_processor_functions)
.size \name\()_processor_functions, . - \name\()_processor_functions
.endm
-.macro define_cache_functions name:req
+.macro define_cache_functions name:req, cachelouis=0
.align 2
.type \name\()_cache_fns, #object
ENTRY(\name\()_cache_fns)
.long \name\()_flush_icache_all
.long \name\()_flush_kern_cache_all
+ .if \cachelouis
+ .long \name\()_flush_kern_cache_louis
+ .else
+ .long \name\()_flush_kern_cache_all
+ .endif
.long \name\()_flush_user_cache_all
.long \name\()_flush_user_cache_range
.long \name\()_coherent_kern_range
--
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
[RFC PATCH 0/6] ARM: augment cache flushing API
This patch series provides an update of a previous posting: http://www.spinics.net/lists/arm-kernel/msg169075.html Main changes: - Changed the new API to Level of Unification Inner Shareable (LoUIS) - Fixed a pointer bug in __cpu_suspend_save code update - Added patches to update __cpu_disable and __v7_setup to LoUIS API - Changed the v7 dcache level function to make it clean/invalidate a specific level instead of up to a certain level v7 ARM architecture introduced the concept of cache levels and relative control registers to manage them. Cache operations that operate on set/way require to define the cache level at which maintenance operations are carried out by using coprocessor registers. Processors like A7/A15 integrates a unified L2 that is part of the cache level hierarchy; this implies that cache operations operating on all levels also end up cleaning the L2 unified cache which is a very time consuming operation and it is not needed for some power-down operations like single CPU shutdown. For v7, flush_kern_all() cleans all the cache levels up to the Level of Coherency which includes L2 in it. This is suboptimal for code paths that end up shutting-down a single processor like CPU hotplug and CPU idle, where only per-CPU cache state (ie L1 integrated cache) has to be cleaned and invalidated. To fix this performance issue this patchset introduces cache LoUIS (Level of Unification Inner Shareable) maintenance operations in the kernel. A new cache operations pointer is added to cpu_cache_fns void (*flush_kern_cache_louis)(void); that allows to clean and invalidate all data cache levels up to the LoUIS and invalidate the instruction cache. This new API should provide a sufficiently optimized API to be used in generic C code in the kernel for power management operations on most v7 systems. For architecture versions previous to v7, flush_kern_cache_louis() falls back to flush_kern_all() leaving the current behaviour unchanged. In order to allow finer grain operations on cache levels, this series also defines an assembly stub for v7 that allows to clean and invalidate a specific data cache level and it is provided for completeness. For A9/A5 processors Level of Unification Inner Shareable and Level of Coherency are equivalent hence this patch should not affect current kernel behaviour in any way when run on A9/A5 based systems, but should nonetheless be thoroughly tested on them. Tested on: - OMAP4 (S2R, cpuidle and hotplug) - OMAP5 (out of tree code) (S2R, cpuidle and hotplug) - TC2 big.LITTLE testchip (out of tree code) (cpuidle, on both A7 and A15 clusters) Lorenzo Pieralisi (4): ARM: mm: define LoUIS API for cache maintenance ops ARM: mm: add v7 cache LoUIS API implementation ARM: kernel: update cpu_suspend code to use cache LoUIS operations ARM: kernel: update __cpu_disable to use cache LoUIS maintenance API Santosh Shilimkar (2): ARM: mm: add v7 dcache level API ARM: mm: update __v7_setup() to the new LoUIS cache maintenance API arch/arm/include/asm/cacheflush.h | 17 +++ arch/arm/kernel/smp.c | 5 +++- arch/arm/kernel/suspend.c | 17 ++- arch/arm/mm/cache-v7.S| 62 +-- arch/arm/mm/proc-macros.S | 7 - arch/arm/mm/proc-v7.S | 2 +- 6 files changed, 103 insertions(+), 7 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
[RFC PATCH 3/6] ARM: mm: add v7 dcache level API
From: Santosh Shilimkar santosh.shilim...@ti.com On ARMv7 based SOC with an integrated L2 cache, there is a need to have a flush API to operate on each cache level. In few low power modes, L2 cache is retained whereas L1 is lost. The current v7_flush_dcache_all(), flushes all the levels and it would be quite expensive in cases where only one of the level needs to be flushed. So this patch introduces v7_flush_dcache_level() API which takes a parameter (cache level), and flush only that level. This API is useful for the power management code where depending on CPU and CPU cluster low power state, a specific cache level can be cleaned instead of cleaning all the cache levels with existing flush_dcache_all(). Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- arch/arm/mm/cache-v7.S | 20 1 file changed, 20 insertions(+) diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index 74aec79..d0fbe5c 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -51,6 +51,26 @@ ENTRY(v7_flush_dcache_louis) b __flush_level ENDPROC(v7_flush_dcache_louis) + /* + * v7_flush_dcache_level(level) + * + * Flush the D-cache the specified level passed as input parameter. + * + * r0 - cache level + * + * Corrupted registers: r0-r7, r9-r11 (r6 only in Thumb mode) + */ + +ENTRY(v7_flush_dcache_level) + dmb @ ensure ordering with previous memory accesses + sub r10, r0, #1 + mov r10, r10, lsl #1 + movsr3, r0, lsl #1 @ level * 2 + mrc p15, 1, r0, c0, c0, 1 @ read clidr + moveq pc, lr @ return if level == 0 + b __flush_level +ENDPROC(v7_flush_dcache_level) + /* * v7_flush_dcache_all() * -- 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 01/10] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
On Thu, Sep 06, 2012 at 19:36:08, Hunter, Jon wrote:
On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
On 9/6/2012 12:34 AM, Jon Hunter wrote:
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer registers
after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode (TSICR
[2].POSTED=1),
due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2
registers right after the timer interface clock (L4) goes from stopped to
active may not return the expected values. The most common event leading to
this situation occurs upon wake up from idle.
GPTimer non-posted synchronization mode is not impacted by this limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead
for configuring the timers as the CPU has to wait for the write to
complete.
However, disabling posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR)
and capture (TCARx) registers will never be read. An example of this is the
clock-event system timer. This is used by the kernel to schedule events
however,
the timers counter is never read and capture registers are not used. Given
that
the kernel configures this timer often yet never reads the counter
register it
is safe to enable posted mode in this case. Hence, for the timer used for
kernel
clock-events, posted mode is enabled by overriding the errata for devices
that
are impacted by this defect.
Although both dmtimers and watchdogs are impacted by this defect this
patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does
not read the counter register and so no workaround is necessary.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices.
Thanks for pinging me on this and getting it confirmed.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |9 +++
arch/arm/plat-omap/dmtimer.c |2 ++
arch/arm/plat-omap/include/plat/dmtimer.h | 39
+
3 files changed, 50 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2ff6d41..5471706 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -208,6 +208,13 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
{
int res;
+ /*
+ * For clock-event timers we never read the timer counter and
+ * so we are not impacted by errata i103 and i767. Therefore,
+ * we can safely ignore this errata for clock-event timers.
+ */
+ __omap_dm_timer_populate_errata(clkev, OMAP_TIMER_ERRATA_I103_I767);
+
Couple of points,
1. It is confusing to me, as you are passing the errata flag so i expect
api should set it. Why can't we do reverse way, you pass 0 here, since
you don't want to set and pass this flag every other places where you
want to enable this errata.
Per the design of the __omap_dm_timer_populate_errata function, the 2nd
argument is called override to allow us to override an errata. I am not
a huge fan of this, but I wanted to be explicit in the code that we are
intentionally allowing posted mode for the clock-events timer.
I did not wish to pass the flags we want to set because if there more
flags added in the future then we will have to keep changing the calls
to the populate_errata function to add these.
Isn't that would self-explain himself which flag is going to set without
looking at the implementation?
I do not have any reservations here, it just doesn't seem easily readable to
me.
You can make a call here.
2. Why can't we enable for all timers? Even though clock-event is anyway
not reading it, but still is is applicable to it, right?
Yes it is still applicable but we never read it so it is ok to override.
If you see Richard W's original patch for enabling posted mode it is to
reduce overhead of programming timers, specifically the clock-events
timer which is program very often.
For other timers, we do not know how they will be used and so by default
we disable posted mode as this is safe.
3. Why can't we just simply Add this flag to hwmod_data file and read it
back in omap_timer_init() and omap_dm_timer_init_one(). Wouldn't that be
a good approach to handle it?
It could be done in this case, but typically I have not seen errata
flags added to HWMOD.
We are already using it, look at I2C, MMC. And in some cases, we have
RE: [PATCH 02/10] ARM: OMAP: Fix timer posted mode support
On Thu, Sep 06, 2012 at 21:31:21, Hunter, Jon wrote:
On 09/06/2012 09:20 AM, Jon Hunter wrote:
On 09/06/2012 07:57 AM, Vaibhav Hiremath wrote:
On 9/6/2012 12:34 AM, Jon Hunter wrote:
Currently the dmtimer posted mode is being enabled when the function
__omap_dm_timer_reset() is called. This function is only being called for
OMAP1 timers and OMAP2+ timers that are being used as system timers.
Hence,
for OMAP2+ timers that are NOT being used as a system timer, posted mode
is
not enabled but the timer-posted variable is still set (incorrectly) in
the omap_dm_timer_prepare() function.
This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
switch-over to platform device driver) which changed the code to only call
omap_dm_timer_reset() for OMAP1 devices. Although this is a regression
from
the original code it only impacts performance and so is not needed for
stable.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |3 +--
arch/arm/plat-omap/dmtimer.c | 14 +-
arch/arm/plat-omap/include/plat/dmtimer.h |9 -
3 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 5471706..e24ee0f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -194,10 +194,9 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
}
__omap_dm_timer_init_regs(timer);
__omap_dm_timer_reset(timer, 1, 1);
- timer-posted = 1;
+ __omap_dm_timer_enable_posted(timer);
timer-rate = clk_get_rate(timer-fclk);
-
timer-reserved = 1;
return res;
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index c34f55b..22790ea 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -122,21 +122,15 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
- omap_dm_timer_enable(timer);
if (timer-pdev-id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
-
__omap_dm_timer_reset(timer, 0, 0);
- omap_dm_timer_disable(timer);
- timer-posted = 1;
}
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
- int ret;
-
/*
* FIXME: OMAP1 devices do not use the clock framework for dmtimers so
* do not call clk_get() for these devices.
@@ -150,13 +144,15 @@ int omap_dm_timer_prepare(struct omap_dm_timer
*timer)
}
}
+ omap_dm_timer_enable(timer);
+
if (timer-capability OMAP_TIMER_NEEDS_RESET)
omap_dm_timer_reset(timer);
- ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+ __omap_dm_timer_enable_posted(timer);
+ omap_dm_timer_disable(timer);
- timer-posted = 1;
- return ret;
+ return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
May be I am speculating here and I know this is tested and supposed to
work, but Isn't it safe to set parent keeping module enables.
So you would rather change the functional clock while the timer is
enabled/active? So although that we are doing this today, that does not
sound like a good idea to me :-)
Actually, we are not doing this today. If you look at the current code
we are only enabling the timer while doing the soft-reset for omap1
devices. Hence, even in the current code we set the parent while the
timer is not enabled. So there is no actual change here in the sequence.
Yes, you are absolutely right here. As such there is no change in the
sequence.
Thanks,
Vaibhav
--
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 01/10] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
On Thu, Sep 06, 2012 at 20:50:27, Hunter, Jon wrote:
On 09/06/2012 09:42 AM, Jon Hunter wrote:
On 09/06/2012 09:06 AM, Jon Hunter wrote:
On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
On 9/6/2012 12:34 AM, Jon Hunter wrote:
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers
after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode (TSICR
[2].POSTED=1),
due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2
registers right after the timer interface clock (L4) goes from stopped to
active may not return the expected values. The most common event leading
to
this situation occurs upon wake up from idle.
GPTimer non-posted synchronization mode is not impacted by this
limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead
for configuring the timers as the CPU has to wait for the write to
complete.
However, disabling posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR)
and capture (TCARx) registers will never be read. An example of this is
the
clock-event system timer. This is used by the kernel to schedule events
however,
the timers counter is never read and capture registers are not used.
Given that
the kernel configures this timer often yet never reads the counter
register it
is safe to enable posted mode in this case. Hence, for the timer used
for kernel
clock-events, posted mode is enabled by overriding the errata for
devices that
are impacted by this defect.
Although both dmtimers and watchdogs are impacted by this defect this
patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does
not read the counter register and so no workaround is necessary.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.
Thanks for pinging me on this and getting it confirmed.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |9 +++
arch/arm/plat-omap/dmtimer.c |2 ++
arch/arm/plat-omap/include/plat/dmtimer.h | 39
+
3 files changed, 50 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2ff6d41..5471706 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -208,6 +208,13 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
{
int res;
+/*
+ * For clock-event timers we never read the timer counter and
+ * so we are not impacted by errata i103 and i767. Therefore,
+ * we can safely ignore this errata for clock-event timers.
+ */
+__omap_dm_timer_populate_errata(clkev,
OMAP_TIMER_ERRATA_I103_I767);
+
Couple of points,
1. It is confusing to me, as you are passing the errata flag so i expect
api should set it. Why can't we do reverse way, you pass 0 here, since
you don't want to set and pass this flag every other places where you
want to enable this errata.
Per the design of the __omap_dm_timer_populate_errata function, the 2nd
argument is called override to allow us to override an errata. I am not
a huge fan of this, but I wanted to be explicit in the code that we are
intentionally allowing posted mode for the clock-events timer.
I did not wish to pass the flags we want to set because if there more
flags added in the future then we will have to keep changing the calls
to the populate_errata function to add these.
By the way, your proposal could work nicely if we could pass errata
flags from HWMOD. However, I am not sure if Paul or Benoit would go for
this as they want HWMOD data to be auto-generated as much as possible
and so I am not sure how that would work for errata which are not
expected by design ;-)
Another alternative would be to drop the override argument altogether
and just do something like the following for the clock-events timer ...
I would still vote for adding this info to hwmod data, I think that is the
right place for all such hw related information.
Thanks,
Viabhav
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 43da595..f59e797 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -206,12 +206,14 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
{
int res;
+
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 My main question is: what is CBUS? It doesn't look like an I2C/SMBUS host controller, but some bit-banging protocol? As such, it shouldn't go to i2c/busses/. And the protocol doesn't look much like I2C, neither. There is no ACK/NACK/START/STOP, so I wonder if it should be in i2c after all... Jean, maybe you want to have a glimpse on this as well? Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [RFC PATCH 1/6] ARM: mm: define LoUIS API for cache maintenance ops
On Thu, Sep 13, 2012 at 11:20:46AM +0100, Lorenzo Pieralisi wrote:
ARM v7 architecture introduced the concept of cache levels and related
coherency requirements. New processors like A7 and A15 embed an
L2 unified cache controller that becomes part of the cache level
hierarchy. Some operations in the kernel like cpu_suspend and __cpu_disable
does not require a flush of the entire cache hierarchy to DRAM but just the
cache levels belonging to the Level of Unification Inner Shareable (LoUIS),
which in most of ARM v7 systems correspond to L1.
The current cache flushing API used in cpu_suspend and __cpu_disable,
flush_cache_all(), ends up flushing the whole cache hierarchy since for
v7 it cleans and invalidates all cache levels up to Level of Coherency
(LoC) which cripples system performance when used in hot paths like hotplug
and cpuidle.
Therefore a new kernel cache maintenance API must be added to the
cpu_cache_fns structure of pointers to cope with latest ARM system
requirements.
This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.
This function cleans and invalidates all data cache levels up to the
level of unification inner shareable (LoUIS) and invalidates the instruction
cache.
The cpu_cache_fns struct reflects this change by adding a new function pointer
that is initialized by arch specific assembly files.
By default, all existing ARM archs do not instantiate any cache LoUIS function
pointer, and flush_dcache_louis just falls back to flush_kern_all.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/include/asm/cacheflush.h | 17 +
arch/arm/mm/proc-macros.S | 7 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index c6e2ed9..7683316 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -50,6 +50,13 @@
*
* Unconditionally clean and invalidate the entire cache.
*
+ * flush_kern_cache_louis()
+ *
+ * Flush data cache levels up to the level of unification
+ * inner shareable and invalidate the I-cache.
+ * Only needed from v7 onwards, falls back to flush_cache_all()
+ * for all other processor versions.
+ *
* flush_user_all()
*
* Clean and invalidate all user space cache entries
@@ -98,6 +105,7 @@
struct cpu_cache_fns {
void (*flush_icache_all)(void);
void (*flush_kern_all)(void);
+ void (*flush_kern_cache_louis)(void);
void (*flush_user_all)(void);
void (*flush_user_range)(unsigned long, unsigned long, unsigned int);
@@ -200,6 +208,15 @@ extern void copy_to_user_page(struct vm_area_struct *,
struct page *,
#define __flush_icache_preferred __flush_icache_all_generic
#endif
+/*
+ * Flush caches up to Level of Unification Inner Shareable
+ */
+#ifdef MULTI_CACHE
+#define flush_cache_louis() cpu_cache.flush_kern_cache_louis()
+#else
+#define flush_cache_louis() __cpuc_flush_kern_all()
+#endif
So, without MULTI_CACHE, we always fall back to flush_kern_all.
I'm guessing this is done because CPUs can't be relied on to provide
flush_kern_cache_louis. Shouldn't this be handled directly?
We could introduce something like CONFIG_ARM_HAVE_CACHEFLUSH_LOUIS, and
do:
asm/glue-cache.h
#ifndef MULTI_CACHE
#ifdef CONFIG_HAVE_ARM_CACHEFLUSH_LOUIS
#define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_cache_louis)
#else
#define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_all)
#endif
#endif
asm/cacheflush.h
#ifdef MULTI_CACHE
#define flush_cache_louis() cpu_cache.flush_kern_cache_louis()
#else
#define flush_cache_louis() __cpuc_flush_kern_cache_louis()
#endif
Any good?
Then the only question is whether this is worth the complexity.
This only works if the __cpuc_ aliases are not used from assembler.
That seems wrong anyway, since on a MULTI_CACHE kernel those would turn
into C struct member references which wouldn't be valid in assembler
anyway.
Cheers
---Dave
--
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 0/5] ARM: OMAP: HOST: TLL driver implementation
On Mon, Aug 13, 2012 at 8:23 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Aug 13, 2012 at 7:39 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Aug 13, 2012 at 06:52:13PM +0530, Munegowda, Keshava wrote: On Fri, Jul 27, 2012 at 5:44 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 23, 2012 at 8:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 23, 2012 at 7:38 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 23, 2012 at 07:31:10PM +0530, Munegowda, Keshava wrote: On Thu, Jul 19, 2012 at 3:48 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 16, 2012 at 7:01 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: The TLL (Transceiver Less Link) is an separate IP block, independent of the host controller. Basically this TLL operates like USB PHY which allows the user to connect two USB transceiver interfaces together directly without the use of differential transceivers in omap3 and later chips. The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com In v4: - rebased on top of linux kernel version 3.5.rc7 - reworked as per the comments given by Paul Walmsley p...@pwsan.com In v3: - rebased on top V3 of Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller http://permalink.gmane.org/gmane.linux.usb.general/65988 - rebased on top of patch OMAP: USB : Fix the EHCI enumeration and core retention issue http://permalink.gmane.org/gmane.linux.usb.general/66239 In V2: - covered review comments from linux omap and usb community - rebased on top Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller Keshava Munegowda (5): ARM: OMAP: Add the USB TLL clocks device name ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: USB: Remove TLL specific code from USB HS core driver ARM: OMAP: Remove older device name of the USB TLL clocks arch/arm/mach-omap2/clock3xxx_data.c |8 +- arch/arm/mach-omap2/clock44xx_data.c |4 +- arch/arm/mach-omap2/usb-host.c| 31 ++- arch/arm/plat-omap/include/plat/usb.h |7 + drivers/mfd/Kconfig |2 +- drivers/mfd/Makefile |2 +- drivers/mfd/omap-usb-host.c | 238 ++--- drivers/mfd/omap-usb-tll.c| 471 + 8 files changed, 523 insertions(+), 240 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c -- 1.7.9.5 Felipe/ Paul please let me know if you have any review comments on this v4 series. regards keshava Hi Felipe please let me know if you have any review comments on this series now. looks ok... pretty much just moving code around. -- balbi Thanks Felipe then I request please give your Ack by for this series. regards keshava Hi Paul do you have any review comments on this series? Felipe is OK with this series. if there are no review comments on this series I request your ack by for the same. Once this series gets in to mainline. i will start the Device tree conversion for usb2 host. regards keshava Hi Felipe please give you ack by this series , so that I request samuel to merge to mainline. sure, here you go Acked-by: Felipe Balbi ba...@ti.com -- balbi Thanks Felipe Samuel I request please queue this series for the next merge window. regards keshava samuel : ping regards keshava -- 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 00/21] OMAPDSS: DISPC changes for writeback pipeline
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, 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_* functions. The next few patches change how overlay caps are used within the dispc functions, this helps reusing more functions between overlays and writeback. The patches in the end add writeback register offsets, and make changes in the code where writeback behaves differently than The changes are made only keeping writeback mem to mem support in mind. There would be a few changes required when capture mode is added, but those are minimal. Reference branch: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 1-writeback-dispc Archit Taneja (21): OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup() OMAPDSS: DISPC: Rename scalar related functions from dispc_ovl_* to dispc_plane_* OMAPDSS: DISPC: Rename fifo/burst related functions from dispc_ovl_* to dispc_plane_* OMAPDSS: DISPC: Rename misc functions from dispc_ovl_* to dispc_plane_* OMAPDSS: DISPC: Simplify function names for setting pipeline input and output sizes OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane functions OMAPDSS: OVERLAY: Add position and replication as overlay caps OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_plane_setup OMAPDSS: DISPC: Calculate scaling limits in a more generic way OMAPDSS: DISPC: Allow both upscaling and downscaling of chroma OMAPDSS: DISPC: Add writeback register offsets and dss features structs OMAPDSS: DISPC: Configure input and output sizes for writeback OMAPDSS: DISPC: Pass dummy scalar output rates for writeback pipeline OMAPDSS: DISPC: Downscale chroma if plane is writeback OMAPDSS: DISPC: Don't set chroma resampling bit for writeback OMAPDSS: DISPC: Add function to set channel in for writeback OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup() OMAPDSS: DISPC: Configure writeback FIFOs OMAPDSS: DISPC: Add manager like functions for writeback OMAPDSS: DISPC: Configure color conversion coefficients for writeback drivers/video/omap2/dss/apply.c|4 +- drivers/video/omap2/dss/dispc.c| 659 +--- drivers/video/omap2/dss/dispc.h| 35 +- drivers/video/omap2/dss/dispc_coefs.c |2 +- drivers/video/omap2/dss/dss.h | 26 +- drivers/video/omap2/dss/dss_features.c | 57 ++- drivers/video/omap2/dss/dss_features.h |1 + include/video/omapdss.h| 15 + 8 files changed, 564 insertions(+), 235 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
[PATCH 05/21] OMAPDSS: DISPC: Simplify function names for setting pipeline input and output sizes
The DISPC pipeline register names in the TRM for setting the buffer size and
the output size are a bit misleading, for example, there are different register
names for setting the buffer size for VID and GFX pipes. Things get more
confusing when considering writeback pipeline.
Rename the functions so that they tell whether they are configuring the input
to the scalar or the output. These will be extended later to support writeback
registers.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 9ecdd44..f60fcf4 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -710,7 +710,7 @@ static void dispc_plane_set_pos(enum omap_plane plane, int
x, int y)
dispc_write_reg(DISPC_OVL_POSITION(plane), val);
}
-static void dispc_plane_set_pic_size(enum omap_plane plane, int width,
+static void dispc_plane_set_input_size(enum omap_plane plane, int width,
int height)
{
u32 val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
@@ -721,7 +721,7 @@ static void dispc_plane_set_pic_size(enum omap_plane plane,
int width,
dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
}
-static void dispc_plane_set_vid_size(enum omap_plane plane, int width,
+static void dispc_plane_set_output_size(enum omap_plane plane, int width,
int height)
{
u32 val;
@@ -2393,13 +2393,13 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
omap_overlay_info *oi,
dispc_plane_set_pos(plane, oi-pos_x, pos_y);
- dispc_plane_set_pic_size(plane, in_width, in_height);
+ dispc_plane_set_input_size(plane, in_width, in_height);
if (ovl-caps OMAP_DSS_OVL_CAP_SCALE) {
dispc_plane_set_scaling(plane, in_width, in_height, out_width,
out_height, ilace, five_taps, fieldmode,
oi-color_mode, oi-rotation);
- dispc_plane_set_vid_size(plane, out_width, out_height);
+ dispc_plane_set_output_size(plane, out_width, out_height);
dispc_plane_set_vid_color_conv(plane, cconv);
}
--
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 04/21] OMAPDSS: DISPC: Rename misc functions from dispc_ovl_* to dispc_plane_*
Writeback pipeline has similar registers compared to graphics and video pipes
for setting base addresses, color conversion, row inc, pix inc etc. Rename these
functions from dispc_ovl_* to dispc_plane_*. The actual registers are kept as
DISPC_OVL_* only to prevent too much change.
All functions which are common to overlays and writeback are to be named as
dispc_plane_*, functions which are specific to overlays are to be named as
dispc_ovl_*, and writeback as dispc_wb_*.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 67 ---
1 file changed, 35 insertions(+), 32 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 44e86ad..9ecdd44 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -683,34 +683,35 @@ static void _dispc_setup_color_conv_coef(void)
}
-static void dispc_ovl_set_ba0(enum omap_plane plane, u32 paddr)
+static void dispc_plane_set_ba0(enum omap_plane plane, u32 paddr)
{
dispc_write_reg(DISPC_OVL_BA0(plane), paddr);
}
-static void dispc_ovl_set_ba1(enum omap_plane plane, u32 paddr)
+static void dispc_plane_set_ba1(enum omap_plane plane, u32 paddr)
{
dispc_write_reg(DISPC_OVL_BA1(plane), paddr);
}
-static void dispc_ovl_set_ba0_uv(enum omap_plane plane, u32 paddr)
+static void dispc_plane_set_ba0_uv(enum omap_plane plane, u32 paddr)
{
dispc_write_reg(DISPC_OVL_BA0_UV(plane), paddr);
}
-static void dispc_ovl_set_ba1_uv(enum omap_plane plane, u32 paddr)
+static void dispc_plane_set_ba1_uv(enum omap_plane plane, u32 paddr)
{
dispc_write_reg(DISPC_OVL_BA1_UV(plane), paddr);
}
-static void dispc_ovl_set_pos(enum omap_plane plane, int x, int y)
+static void dispc_plane_set_pos(enum omap_plane plane, int x, int y)
{
u32 val = FLD_VAL(y, 26, 16) | FLD_VAL(x, 10, 0);
dispc_write_reg(DISPC_OVL_POSITION(plane), val);
}
-static void dispc_ovl_set_pic_size(enum omap_plane plane, int width, int
height)
+static void dispc_plane_set_pic_size(enum omap_plane plane, int width,
+ int height)
{
u32 val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
@@ -720,7 +721,8 @@ static void dispc_ovl_set_pic_size(enum omap_plane plane,
int width, int height)
dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
}
-static void dispc_ovl_set_vid_size(enum omap_plane plane, int width, int
height)
+static void dispc_plane_set_vid_size(enum omap_plane plane, int width,
+ int height)
{
u32 val;
@@ -731,7 +733,7 @@ static void dispc_ovl_set_vid_size(enum omap_plane plane,
int width, int height)
dispc_write_reg(DISPC_OVL_SIZE(plane), val);
}
-static void dispc_ovl_set_zorder(enum omap_plane plane, u8 zorder)
+static void dispc_plane_set_zorder(enum omap_plane plane, u8 zorder)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
@@ -752,7 +754,7 @@ static void dispc_ovl_enable_zorder_planes(void)
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(i), 1, 25, 25);
}
-static void dispc_ovl_set_pre_mult_alpha(enum omap_plane plane, bool enable)
+static void dispc_plane_set_pre_mult_alpha(enum omap_plane plane, bool enable)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
@@ -762,7 +764,8 @@ static void dispc_ovl_set_pre_mult_alpha(enum omap_plane
plane, bool enable)
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), enable ? 1 : 0, 28, 28);
}
-static void dispc_ovl_setup_global_alpha(enum omap_plane plane, u8
global_alpha)
+static void dispc_plane_setup_global_alpha(enum omap_plane plane,
+ u8 global_alpha)
{
static const unsigned shifts[] = { 0, 8, 16, 24, };
int shift;
@@ -775,17 +778,17 @@ static void dispc_ovl_setup_global_alpha(enum omap_plane
plane, u8 global_alpha)
REG_FLD_MOD(DISPC_GLOBAL_ALPHA, global_alpha, shift + 7, shift);
}
-static void dispc_ovl_set_pix_inc(enum omap_plane plane, s32 inc)
+static void dispc_plane_set_pix_inc(enum omap_plane plane, s32 inc)
{
dispc_write_reg(DISPC_OVL_PIXEL_INC(plane), inc);
}
-static void dispc_ovl_set_row_inc(enum omap_plane plane, s32 inc)
+static void dispc_plane_set_row_inc(enum omap_plane plane, s32 inc)
{
dispc_write_reg(DISPC_OVL_ROW_INC(plane), inc);
}
-static void dispc_ovl_set_color_mode(enum omap_plane plane,
+static void dispc_plane_set_color_mode(enum omap_plane plane,
enum omap_color_mode color_mode)
{
u32 m = 0;
@@ -1045,7 +1048,7 @@ static void dispc_mgr_set_cpr_coef(enum omap_channel
channel,
dispc_write_reg(DISPC_CPR_COEF_B(channel), coef_b);
}
-static void dispc_ovl_set_vid_color_conv(enum omap_plane plane, bool enable)
+static void dispc_plane_set_vid_color_conv(enum omap_plane plane, bool enable)
{
u32 val;
@@ -1056,7 +1059,7 @@ static void dispc_ovl_set_vid_color_conv(enum omap_plane
plane, bool
[PATCH 06/21] OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane functions
Currently, the functions below take the omap_plane parameter and derive the
overlay caps within them. Pass the overlay caps as a parameter to the function
to allow these to be used by writeback too.
- dispc_plane_set_zorder()
- dispc_plane_set_pre_mult_alpha()
- dispc_plane_setup_global_alpha()
- dispc_plane_calc_scaling()
- dispc_ovl_setup()
These functions will be used for writeback later, and the caps will help in
deciding if they are to be used for writeback or not. This allows reuse of
overlay caps for writeback.
Using omap_overlay_caps for writeback seems a bit incorrect, but caps is
something already in use by users of OMAPDSS(omapfb/omap_vout), so we use
overlay caps for overlay like features of writeback too.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 40 +++
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index f60fcf4..3a0a576 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -733,11 +733,10 @@ static void dispc_plane_set_output_size(enum omap_plane
plane, int width,
dispc_write_reg(DISPC_OVL_SIZE(plane), val);
}
-static void dispc_plane_set_zorder(enum omap_plane plane, u8 zorder)
+static void dispc_plane_set_zorder(enum omap_plane plane,
+ enum omap_overlay_caps caps, u8 zorder)
{
- struct omap_overlay *ovl = omap_dss_get_overlay(plane);
-
- if ((ovl-caps OMAP_DSS_OVL_CAP_ZORDER) == 0)
+ if ((caps OMAP_DSS_OVL_CAP_ZORDER) == 0)
return;
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), zorder, 27, 26);
@@ -754,24 +753,22 @@ static void dispc_ovl_enable_zorder_planes(void)
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(i), 1, 25, 25);
}
-static void dispc_plane_set_pre_mult_alpha(enum omap_plane plane, bool enable)
+static void dispc_plane_set_pre_mult_alpha(enum omap_plane plane,
+ enum omap_overlay_caps caps, bool enable)
{
- struct omap_overlay *ovl = omap_dss_get_overlay(plane);
-
- if ((ovl-caps OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA) == 0)
+ if ((caps OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA) == 0)
return;
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), enable ? 1 : 0, 28, 28);
}
static void dispc_plane_setup_global_alpha(enum omap_plane plane,
- u8 global_alpha)
+ enum omap_overlay_caps caps, u8 global_alpha)
{
static const unsigned shifts[] = { 0, 8, 16, 24, };
int shift;
- struct omap_overlay *ovl = omap_dss_get_overlay(plane);
- if ((ovl-caps OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
+ if ((caps OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
return;
shift = shifts[plane];
@@ -2200,13 +2197,12 @@ static int dispc_ovl_calc_scaling_44xx(enum
omap_channel channel,
}
static int dispc_plane_calc_scaling(enum omap_plane plane,
- enum omap_channel channel,
+ enum omap_overlay_caps caps, enum omap_channel channel,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
int *x_predecim, int *y_predecim, u16 pos_x)
{
- struct omap_overlay *ovl = omap_dss_get_overlay(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
const int max_decim_limit = 16;
unsigned long core_clk = 0;
@@ -2215,7 +2211,7 @@ static int dispc_plane_calc_scaling(enum omap_plane plane,
if (width == out_width height == out_height)
return 0;
- if ((ovl-caps OMAP_DSS_OVL_CAP_SCALE) == 0)
+ if ((caps OMAP_DSS_OVL_CAP_SCALE) == 0)
return -EINVAL;
*x_predecim = max_decim_limit;
@@ -2266,6 +2262,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
omap_overlay_info *oi,
bool replication, const struct omap_video_timings *mgr_timings)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
+ enum omap_overlay_caps caps = ovl-caps;
bool five_taps = true;
bool fieldmode = 0;
int r, cconv = 0;
@@ -2314,9 +2311,10 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
omap_overlay_info *oi,
if (!dss_feat_color_mode_supported(plane, oi-color_mode))
return -EINVAL;
- r = dispc_plane_calc_scaling(plane, channel, mgr_timings, in_width,
- in_height, out_width, out_height, oi-color_mode,
- five_taps, x_predecim, y_predecim, oi-pos_x);
+ r = dispc_plane_calc_scaling(plane, caps, channel, mgr_timings,
+ in_width, in_height, out_width, out_height,
+ oi-color_mode, five_taps, x_predecim, y_predecim,
+ oi-pos_x);
if (r)
[PATCH 07/21] OMAPDSS: OVERLAY: Add position and replication as overlay caps
Add position and replication as overlay caps, and pass overlay caps as an
argument to the corresponding functions. Adding position and replication to
overlay caps seems a bit unnecessary, but it allows us to use the
corresponding functions for writeback too.
These caps will be set for all overlays, but not for writeback. This is done
so writeback can reuse dispc_ovl_setup() to the maximum.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c| 20 -
drivers/video/omap2/dss/dss_features.c | 38 +---
include/video/omapdss.h|2 ++
3 files changed, 42 insertions(+), 18 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 3a0a576..325cd51 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -703,9 +703,15 @@ static void dispc_plane_set_ba1_uv(enum omap_plane plane,
u32 paddr)
dispc_write_reg(DISPC_OVL_BA1_UV(plane), paddr);
}
-static void dispc_plane_set_pos(enum omap_plane plane, int x, int y)
+static void dispc_plane_set_pos(enum omap_plane plane,
+ enum omap_overlay_caps caps, int x, int y)
{
- u32 val = FLD_VAL(y, 26, 16) | FLD_VAL(x, 10, 0);
+ u32 val;
+
+ if ((caps OMAP_DSS_OVL_CAP_POS) == 0)
+ return;
+
+ val = FLD_VAL(y, 26, 16) | FLD_VAL(x, 10, 0);
dispc_write_reg(DISPC_OVL_POSITION(plane), val);
}
@@ -1056,11 +1062,15 @@ static void dispc_plane_set_vid_color_conv(enum
omap_plane plane, bool enable)
dispc_write_reg(DISPC_OVL_ATTRIBUTES(plane), val);
}
-static void dispc_plane_enable_replication(enum omap_plane plane, bool enable)
+static void dispc_plane_enable_replication(enum omap_plane plane,
+ enum omap_overlay_caps caps, bool enable)
{
static const unsigned shifts[] = { 5, 10, 10, 10 };
int shift;
+ if ((caps OMAP_DSS_OVL_CAP_REPLICATION) == 0)
+ return;
+
shift = shifts[plane];
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), enable, shift, shift);
}
@@ -2389,7 +2399,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
omap_overlay_info *oi,
DSSDBG(%d,%d %dx%d - %dx%d\n, oi-pos_x, oi-pos_y, in_width,
in_height, out_width, out_height);
- dispc_plane_set_pos(plane, oi-pos_x, pos_y);
+ dispc_plane_set_pos(plane, caps, oi-pos_x, pos_y);
dispc_plane_set_input_size(plane, in_width, in_height);
@@ -2408,7 +2418,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
omap_overlay_info *oi,
dispc_plane_set_pre_mult_alpha(plane, caps, oi-pre_mult_alpha);
dispc_plane_setup_global_alpha(plane, caps, oi-global_alpha);
- dispc_plane_enable_replication(plane, replication);
+ dispc_plane_enable_replication(plane, caps, replication);
return 0;
}
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 63d109f..8b6c79f 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -269,54 +269,66 @@ static const enum omap_color_mode
omap4_dss_supported_color_modes[] = {
static const enum omap_overlay_caps omap2_dss_overlay_caps[] = {
/* OMAP_DSS_GFX */
- 0,
+ OMAP_DSS_OVL_CAP_POS | OMAP_DSS_OVL_CAP_REPLICATION,
/* OMAP_DSS_VIDEO1 */
- OMAP_DSS_OVL_CAP_SCALE,
+ OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_POS |
+ OMAP_DSS_OVL_CAP_REPLICATION,
/* OMAP_DSS_VIDEO2 */
- OMAP_DSS_OVL_CAP_SCALE,
+ OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_POS |
+ OMAP_DSS_OVL_CAP_REPLICATION,
};
static const enum omap_overlay_caps omap3430_dss_overlay_caps[] = {
/* OMAP_DSS_GFX */
- OMAP_DSS_OVL_CAP_GLOBAL_ALPHA,
+ OMAP_DSS_OVL_CAP_GLOBAL_ALPHA | OMAP_DSS_OVL_CAP_POS |
+ OMAP_DSS_OVL_CAP_REPLICATION,
/* OMAP_DSS_VIDEO1 */
- OMAP_DSS_OVL_CAP_SCALE,
+ OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_POS |
+ OMAP_DSS_OVL_CAP_REPLICATION,
/* OMAP_DSS_VIDEO2 */
- OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_GLOBAL_ALPHA,
+ OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_GLOBAL_ALPHA |
+ OMAP_DSS_OVL_CAP_POS | OMAP_DSS_OVL_CAP_REPLICATION,
};
static const enum omap_overlay_caps omap3630_dss_overlay_caps[] = {
/* OMAP_DSS_GFX */
- OMAP_DSS_OVL_CAP_GLOBAL_ALPHA | OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA,
+ OMAP_DSS_OVL_CAP_GLOBAL_ALPHA | OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA |
+ OMAP_DSS_OVL_CAP_POS | OMAP_DSS_OVL_CAP_REPLICATION,
/* OMAP_DSS_VIDEO1 */
- OMAP_DSS_OVL_CAP_SCALE,
+ OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_POS |
+ OMAP_DSS_OVL_CAP_REPLICATION,
/* OMAP_DSS_VIDEO2 */
OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_GLOBAL_ALPHA |
-
[PATCH 08/21] OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_plane_setup
Add a new static function called dispc_plane_setup(). This function is used by
dispc_ovl_setup() to configure the overlay registers.
This split is done so that dispc_wb_setup() can reuse the common overlay related
registers configured in dispc_plane_setup().
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 125 ++-
1 file changed, 70 insertions(+), 55 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 325cd51..e6d8b77 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2268,43 +2268,34 @@ static int dispc_plane_calc_scaling(enum omap_plane
plane,
return 0;
}
-int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
+static int dispc_plane_setup(enum omap_plane plane, enum omap_channel channel,
+ enum omap_overlay_caps caps, u32 paddr, u32 p_uv_addr,
+ u16 screen_width, int pos_x, int pos_y, u16 width, u16 height,
+ u16 out_width, u16 out_height, enum omap_color_mode color_mode,
+ u8 rotation, bool mirror, u8 zorder, u8 pre_mult_alpha,
+ u8 global_alpha, enum omap_dss_rotation_type rotation_type,
bool replication, const struct omap_video_timings *mgr_timings)
{
- struct omap_overlay *ovl = omap_dss_get_overlay(plane);
- enum omap_overlay_caps caps = ovl-caps;
bool five_taps = true;
bool fieldmode = 0;
int r, cconv = 0;
unsigned offset0, offset1;
s32 row_inc;
s32 pix_inc;
- u16 frame_height = oi-height;
+ u16 frame_height = height;
unsigned int field_offset = 0;
- u16 in_height = oi-height;
- u16 in_width = oi-width;
- u16 out_width, out_height;
- enum omap_channel channel;
+ u16 in_height = height;
+ u16 in_width = width;
int x_predecim = 1, y_predecim = 1;
bool ilace = mgr_timings-interlace;
- u16 pos_y = oi-pos_y;
-
- channel = dispc_ovl_get_channel_out(plane);
-
- DSSDBG(dispc_ovl_setup %d, pa %x, pa_uv %x, sw %d, %d,%d, %dx%d -
- %dx%d, cmode %x, rot %d, mir %d, ilace %d chan %d repl %d\n,
- plane, oi-paddr, oi-p_uv_addr,
- oi-screen_width, oi-pos_x, oi-pos_y, oi-width, oi-height,
- oi-out_width, oi-out_height, oi-color_mode, oi-rotation,
- oi-mirror, ilace, channel, replication);
- if (oi-paddr == 0)
+ if (paddr == 0)
return -EINVAL;
- out_width = oi-out_width == 0 ? oi-width : oi-out_width;
- out_height = oi-out_height == 0 ? oi-height : oi-out_height;
+ out_width = out_width == 0 ? width : out_width;
+ out_height = out_height == 0 ? height : out_height;
- if (ilace oi-height == out_height)
+ if (ilace height == out_height)
fieldmode = 1;
if (ilace) {
@@ -2314,26 +2305,26 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
omap_overlay_info *oi,
out_height /= 2;
DSSDBG(adjusting for ilace: height %d, pos_y %d,
- out_height %d\n,
- in_height, pos_y, out_height);
+ out_height %d\n, in_height, pos_y,
+ out_height);
}
- if (!dss_feat_color_mode_supported(plane, oi-color_mode))
+ if (!dss_feat_color_mode_supported(plane, color_mode))
return -EINVAL;
r = dispc_plane_calc_scaling(plane, caps, channel, mgr_timings,
in_width, in_height, out_width, out_height,
- oi-color_mode, five_taps, x_predecim, y_predecim,
- oi-pos_x);
+ color_mode, five_taps, x_predecim, y_predecim,
+ pos_x);
if (r)
return r;
in_width = DIV_ROUND_UP(in_width, x_predecim);
in_height = DIV_ROUND_UP(in_height, y_predecim);
- if (oi-color_mode == OMAP_DSS_COLOR_YUV2 ||
- oi-color_mode == OMAP_DSS_COLOR_UYVY ||
- oi-color_mode == OMAP_DSS_COLOR_NV12)
+ if (color_mode == OMAP_DSS_COLOR_YUV2 ||
+ color_mode == OMAP_DSS_COLOR_UYVY ||
+ color_mode == OMAP_DSS_COLOR_NV12)
cconv = 1;
if (ilace !fieldmode) {
@@ -2359,70 +2350,94 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
omap_overlay_info *oi,
row_inc = 0;
pix_inc = 0;
- if (oi-rotation_type == OMAP_DSS_ROT_TILER)
- calc_tiler_rotation_offset(oi-screen_width, in_width,
- oi-color_mode, fieldmode, field_offset,
+ if (rotation_type == OMAP_DSS_ROT_TILER)
+ calc_tiler_rotation_offset(screen_width, in_width,
+
[PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
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.
This also helps us in replacing omap_channel arguments with output_rate, making
dispc_plane_setup more pipeline specific.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 126 ++-
1 file changed, 72 insertions(+), 54 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e6d8b77..58cb06c 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -86,13 +86,13 @@ struct dispc_features {
u16 sw_max;
u16 vp_max;
u16 hp_max;
- int (*calc_scaling) (enum omap_channel channel,
+ int (*calc_scaling) (enum omap_plane plane, unsigned long out_rate,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
u16 pos_x, unsigned long *core_clk);
- unsigned long (*calc_core_clk) (enum omap_channel channel,
+ unsigned long (*calc_core_clk) (unsigned long out_rate,
u16 width, u16 height, u16 out_width, u16 out_height);
u8 num_fifos;
@@ -236,6 +236,8 @@ static const struct {
};
static void _omap_dispc_set_irqs(void);
+static unsigned long dispc_plane_output_rate(enum omap_plane plane);
+static unsigned long dispc_plane_lclk_rate(enum omap_plane plane);
static inline void dispc_write_reg(const u16 idx, u32 val)
{
@@ -1925,29 +1927,25 @@ static void calc_tiler_rotation_offset(u16
screen_width, u16 width,
* This function is used to avoid synclosts in OMAP3, because of some
* undocumented horizontal position and timing related limitations.
*/
-static int check_horiz_timing_omap3(enum omap_channel channel,
- const struct omap_video_timings *t, u16 pos_x,
- u16 width, u16 height, u16 out_width, u16 out_height)
+static int check_horiz_timing_omap3(enum omap_plane plane,
+ unsigned long out_rate, const struct omap_video_timings *t,
+ u16 pos_x, u16 width, u16 height, u16 out_width, u16 out_height)
{
int DS = DIV_ROUND_UP(height, out_height);
- unsigned long nonactive, lclk, pclk;
+ unsigned long nonactive;
+ unsigned long lclk_rate = dispc_plane_lclk_rate(plane);
static const u8 limits[3] = { 8, 10, 20 };
u64 val, blank;
int i;
nonactive = t-x_res + t-hfp + t-hsw + t-hbp - out_width;
- pclk = dispc_mgr_pclk_rate(channel);
- if (dss_mgr_is_lcd(channel))
- lclk = dispc_mgr_lclk_rate(channel);
- else
- lclk = dispc_fclk_rate();
i = 0;
if (out_height height)
i++;
if (out_width width)
i++;
- blank = div_u64((u64)(t-hbp + t-hsw + t-hfp) * lclk, pclk);
+ blank = div_u64((u64)(t-hbp + t-hsw + t-hfp) * lclk_rate, out_rate);
DSSDBG(blanking period + ppl = %llu (limit = %u)\n, blank, limits[i]);
if (blank = limits[i])
return -EINVAL;
@@ -1957,7 +1955,7 @@ static int check_horiz_timing_omap3(enum omap_channel
channel,
* So, atleast DS-2 lines must have already been fetched by DISPC
* during nonactive - pos_x period.
*/
- val = div_u64((u64)(nonactive - pos_x) * lclk, pclk);
+ val = div_u64((u64)(nonactive - pos_x) * lclk_rate, out_rate);
DSSDBG((nonactive - pos_x) * pcd = %llu max(0, DS - 2) * width = %d\n,
val, max(0, DS - 2) * width);
if (val max(0, DS - 2) * width)
@@ -1968,7 +1966,7 @@ static int check_horiz_timing_omap3(enum omap_channel
channel,
* only one line can be loaded during the active period. So, atleast
* DS - 1 lines should be loaded during nonactive period.
*/
- val = div_u64((u64)nonactive * lclk, pclk);
+ val = div_u64((u64)nonactive * lclk_rate, out_rate);
DSSDBG(nonactive * pcd = %llu, max(0, DS - 1) * width = %d\n,
val, max(0, DS - 1) * width);
if (val max(0, DS - 1) * width)
@@ -1977,21 +1975,21
[PATCH 01/21] OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup()
The struct omap_overlay_info passed to dispc_ovl_setup() is used to configure
DISPC registers. It shouldn't modify the overlay_info structure. The pos_y field
was being changed in dispc_ovl_setup in the case of interlaced displays. Fix
this and const qualifier to the omap_overlay_info argument.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |9 +
drivers/video/omap2/dss/dss.h |2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 33db882..cd3d532 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2253,7 +2253,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
return 0;
}
-int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
+int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool replication, const struct omap_video_timings *mgr_timings)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
@@ -2271,6 +2271,7 @@ int dispc_ovl_setup(enum omap_plane plane, struct
omap_overlay_info *oi,
enum omap_channel channel;
int x_predecim = 1, y_predecim = 1;
bool ilace = mgr_timings-interlace;
+ u16 pos_y = oi-pos_y;
channel = dispc_ovl_get_channel_out(plane);
@@ -2293,12 +2294,12 @@ int dispc_ovl_setup(enum omap_plane plane, struct
omap_overlay_info *oi,
if (ilace) {
if (fieldmode)
in_height /= 2;
- oi-pos_y /= 2;
+ pos_y /= 2;
out_height /= 2;
DSSDBG(adjusting for ilace: height %d, pos_y %d,
out_height %d\n,
- in_height, oi-pos_y, out_height);
+ in_height, pos_y, out_height);
}
if (!dss_feat_color_mode_supported(plane, oi-color_mode))
@@ -2381,7 +2382,7 @@ int dispc_ovl_setup(enum omap_plane plane, struct
omap_overlay_info *oi,
DSSDBG(%d,%d %dx%d - %dx%d\n, oi-pos_x, oi-pos_y, in_width,
in_height, out_width, out_height);
- dispc_ovl_set_pos(plane, oi-pos_x, oi-pos_y);
+ dispc_ovl_set_pos(plane, oi-pos_x, pos_y);
dispc_ovl_set_pic_size(plane, in_width, in_height);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index c2bc092..43210b8 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -440,7 +440,7 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane,
u32 low, u32 high);
void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
u32 *fifo_low, u32 *fifo_high, bool use_fifomerge,
bool manual_update);
-int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
+int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool replication, const struct omap_video_timings *mgr_timings);
int dispc_ovl_enable(enum omap_plane plane, bool enable);
void dispc_ovl_set_channel_out(enum omap_plane plane,
--
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 02/21] OMAPDSS: DISPC: Rename scalar related functions from dispc_ovl_* to dispc_plane_*
Writeback pipeline has an identical scalar block as in video pipelines. Rename
the scalar related function from dispc_ovl_* to dispc_plane_*. The actual
registers are kept as DISPC_OVL_* only to prevent too much change.
All functions which are common to overlays and writeback are to be named as
dispc_plane_*, functions which are specific to overlays are to be named as
dispc_ovl_*, and writeback as dispc_wb_*.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 92 ++---
drivers/video/omap2/dss/dispc.h |2 +-
drivers/video/omap2/dss/dispc_coefs.c |2 +-
3 files changed, 51 insertions(+), 45 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index cd3d532..eae9da4 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -560,29 +560,33 @@ void dispc_mgr_go(enum omap_channel channel)
mgr_fld_write(channel, DISPC_MGR_FLD_GO, 1);
}
-static void dispc_ovl_write_firh_reg(enum omap_plane plane, int reg, u32 value)
+static void dispc_plane_write_firh_reg(enum omap_plane plane, int reg,
+ u32 value)
{
dispc_write_reg(DISPC_OVL_FIR_COEF_H(plane, reg), value);
}
-static void dispc_ovl_write_firhv_reg(enum omap_plane plane, int reg, u32
value)
+static void dispc_plane_write_firhv_reg(enum omap_plane plane, int reg,
+ u32 value)
{
dispc_write_reg(DISPC_OVL_FIR_COEF_HV(plane, reg), value);
}
-static void dispc_ovl_write_firv_reg(enum omap_plane plane, int reg, u32 value)
+static void dispc_plane_write_firv_reg(enum omap_plane plane, int reg,
+ u32 value)
{
dispc_write_reg(DISPC_OVL_FIR_COEF_V(plane, reg), value);
}
-static void dispc_ovl_write_firh2_reg(enum omap_plane plane, int reg, u32
value)
+static void dispc_plane_write_firh2_reg(enum omap_plane plane, int reg,
+ u32 value)
{
BUG_ON(plane == OMAP_DSS_GFX);
dispc_write_reg(DISPC_OVL_FIR_COEF_H2(plane, reg), value);
}
-static void dispc_ovl_write_firhv2_reg(enum omap_plane plane, int reg,
+static void dispc_plane_write_firhv2_reg(enum omap_plane plane, int reg,
u32 value)
{
BUG_ON(plane == OMAP_DSS_GFX);
@@ -590,22 +594,23 @@ static void dispc_ovl_write_firhv2_reg(enum omap_plane
plane, int reg,
dispc_write_reg(DISPC_OVL_FIR_COEF_HV2(plane, reg), value);
}
-static void dispc_ovl_write_firv2_reg(enum omap_plane plane, int reg, u32
value)
+static void dispc_plane_write_firv2_reg(enum omap_plane plane, int reg,
+ u32 value)
{
BUG_ON(plane == OMAP_DSS_GFX);
dispc_write_reg(DISPC_OVL_FIR_COEF_V2(plane, reg), value);
}
-static void dispc_ovl_set_scale_coef(enum omap_plane plane, int fir_hinc,
- int fir_vinc, int five_taps,
- enum omap_color_component color_comp)
+static void dispc_plane_set_scale_coef(enum omap_plane plane, int fir_hinc,
+ int fir_vinc, int five_taps,
+ enum omap_color_component color_comp)
{
const struct dispc_coef *h_coef, *v_coef;
int i;
- h_coef = dispc_ovl_get_scale_coef(fir_hinc, true);
- v_coef = dispc_ovl_get_scale_coef(fir_vinc, five_taps);
+ h_coef = dispc_plane_get_scale_coef(fir_hinc, true);
+ v_coef = dispc_plane_get_scale_coef(fir_vinc, five_taps);
for (i = 0; i 8; i++) {
u32 h, hv;
@@ -620,11 +625,11 @@ static void dispc_ovl_set_scale_coef(enum omap_plane
plane, int fir_hinc,
| FLD_VAL(v_coef[i].hc3_vc2, 31, 24);
if (color_comp == DISPC_COLOR_COMPONENT_RGB_Y) {
- dispc_ovl_write_firh_reg(plane, i, h);
- dispc_ovl_write_firhv_reg(plane, i, hv);
+ dispc_plane_write_firh_reg(plane, i, h);
+ dispc_plane_write_firhv_reg(plane, i, hv);
} else {
- dispc_ovl_write_firh2_reg(plane, i, h);
- dispc_ovl_write_firhv2_reg(plane, i, hv);
+ dispc_plane_write_firh2_reg(plane, i, h);
+ dispc_plane_write_firhv2_reg(plane, i, hv);
}
}
@@ -635,9 +640,9 @@ static void dispc_ovl_set_scale_coef(enum omap_plane plane,
int fir_hinc,
v = FLD_VAL(v_coef[i].hc0_vc00, 7, 0)
| FLD_VAL(v_coef[i].hc4_vc22, 15, 8);
if (color_comp == DISPC_COLOR_COMPONENT_RGB_Y)
- dispc_ovl_write_firv_reg(plane, i, v);
+ dispc_plane_write_firv_reg(plane, i, v);
else
- dispc_ovl_write_firv2_reg(plane, i, v);
+ dispc_plane_write_firv2_reg(plane, i, v);
}
}
}
@@ -1208,9 +1213,8 @@ void
[PATCH 10/21] OMAPDSS: DISPC: Allow both upscaling and downscaling of chroma
In the function dispc_plane_set_scaling_uv(), create a parameter which tells if
we want to upscale or downscale the chroma plane.
Downscaling of chroma is required by writeback pipeline for converting the input
YUV444 color format to YUV422 or NV12.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 58cb06c..60a60fc 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1462,6 +1462,7 @@ static void dispc_plane_set_scaling_uv(enum omap_plane
plane,
{
int scale_x = out_width != orig_width;
int scale_y = out_height != orig_height;
+ bool chroma_upscale = true;
if (!dss_has_feature(FEAT_HANDLE_UV_SEPARATE))
return;
@@ -1478,23 +1479,34 @@ static void dispc_plane_set_scaling_uv(enum omap_plane
plane,
switch (color_mode) {
case OMAP_DSS_COLOR_NV12:
- /* UV is subsampled by 2 vertically*/
- orig_height = 1;
- /* UV is subsampled by 2 horz.*/
- orig_width = 1;
+ if (chroma_upscale) {
+ /* UV is subsampled by 2 horizontally and vertically */
+ orig_height = 1;
+ orig_width = 1;
+ } else {
+ /* UV is downsampled by 2 horizontally and vertically */
+ orig_height = 1;
+ orig_width = 1;
+ }
+
break;
case OMAP_DSS_COLOR_YUV2:
case OMAP_DSS_COLOR_UYVY:
- /*For YUV422 with 90/270 rotation,
-*we don't upsample chroma
-*/
+ /* For YUV422 with 90/270 rotation, we don't upsample chroma */
if (rotation == OMAP_DSS_ROT_0 ||
- rotation == OMAP_DSS_ROT_180)
- /* UV is subsampled by 2 hrz*/
- orig_width = 1;
+ rotation == OMAP_DSS_ROT_180) {
+ if (chroma_upscale)
+ /* UV is subsampled by 2 horizontally */
+ orig_width = 1;
+ else
+ /* UV is downsampled by 2 horizontally */
+ orig_width = 1;
+ }
+
/* must use FIR for YUV422 if rotated */
if (rotation != OMAP_DSS_ROT_0)
scale_x = scale_y = true;
+
break;
default:
BUG();
--
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 11/21] OMAPDSS: DISPC: Add writeback register offsets and dss features structs
Since writeback has many overlay like properties, and most of it's registers are similar to that of overlays, it's possible to reuse most of the overlay related DISPC code for writeback when considering it as a plane. Writeback was added as a plane in the omap_plane field as OMAP_DSS_WB. Add the writeback register offsets in dispc.h, add minimal WB plane related info needed in dss_features. Add a function which returns the number of writeback pipelines an OMAP version has. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/dispc.h| 33 drivers/video/omap2/dss/dss_features.c | 19 ++ drivers/video/omap2/dss/dss_features.h |1 + 3 files changed, 53 insertions(+) diff --git a/drivers/video/omap2/dss/dispc.h b/drivers/video/omap2/dss/dispc.h index 84cc472..2b008f7 100644 --- a/drivers/video/omap2/dss/dispc.h +++ b/drivers/video/omap2/dss/dispc.h @@ -373,6 +373,7 @@ static inline u16 DISPC_BA0_OFFSET(enum omap_plane plane) case OMAP_DSS_VIDEO2: return 0x; case OMAP_DSS_VIDEO3: + case OMAP_DSS_WB: return 0x0008; default: BUG(); @@ -388,6 +389,7 @@ static inline u16 DISPC_BA1_OFFSET(enum omap_plane plane) case OMAP_DSS_VIDEO2: return 0x0004; case OMAP_DSS_VIDEO3: + case OMAP_DSS_WB: return 0x000C; default: BUG(); @@ -407,6 +409,8 @@ static inline u16 DISPC_BA0_UV_OFFSET(enum omap_plane plane) return 0x04BC; case OMAP_DSS_VIDEO3: return 0x0310; + case OMAP_DSS_WB: + return 0x0118; default: BUG(); return 0; @@ -425,6 +429,8 @@ static inline u16 DISPC_BA1_UV_OFFSET(enum omap_plane plane) return 0x04C0; case OMAP_DSS_VIDEO3: return 0x0314; + case OMAP_DSS_WB: + return 0x011C; default: BUG(); return 0; @@ -454,6 +460,7 @@ static inline u16 DISPC_SIZE_OFFSET(enum omap_plane plane) case OMAP_DSS_VIDEO2: return 0x000C; case OMAP_DSS_VIDEO3: + case OMAP_DSS_WB: return 0x00A8; default: BUG(); @@ -470,6 +477,7 @@ static inline u16 DISPC_ATTR_OFFSET(enum omap_plane plane) case OMAP_DSS_VIDEO2: return 0x0010; case OMAP_DSS_VIDEO3: + case OMAP_DSS_WB: return 0x0070; default: BUG(); @@ -489,6 +497,8 @@ static inline u16 DISPC_ATTR2_OFFSET(enum omap_plane plane) return 0x04DC; case OMAP_DSS_VIDEO3: return 0x032C; + case OMAP_DSS_WB: + return 0x0310; default: BUG(); return 0; @@ -504,6 +514,7 @@ static inline u16 DISPC_FIFO_THRESH_OFFSET(enum omap_plane plane) case OMAP_DSS_VIDEO2: return 0x0014; case OMAP_DSS_VIDEO3: + case OMAP_DSS_WB: return 0x008C; default: BUG(); @@ -537,6 +548,7 @@ static inline u16 DISPC_ROW_INC_OFFSET(enum omap_plane plane) case OMAP_DSS_VIDEO2: return 0x001C; case OMAP_DSS_VIDEO3: + case OMAP_DSS_WB: return 0x00A4; default: BUG(); @@ -553,6 +565,7 @@ static inline u16 DISPC_PIX_INC_OFFSET(enum omap_plane plane) case OMAP_DSS_VIDEO2: return 0x0020; case OMAP_DSS_VIDEO3: + case OMAP_DSS_WB: return 0x0098; default: BUG(); @@ -602,6 +615,7 @@ static inline u16 DISPC_FIR_OFFSET(enum omap_plane plane) case OMAP_DSS_VIDEO2: return 0x0024; case OMAP_DSS_VIDEO3: + case OMAP_DSS_WB: return 0x0090; default: BUG(); @@ -621,6 +635,8 @@ static inline u16 DISPC_FIR2_OFFSET(enum omap_plane plane) return 0x055C; case OMAP_DSS_VIDEO3: return 0x0424; + case OMAP_DSS_WB: + return 0x290; default: BUG(); return 0; @@ -637,6 +653,7 @@ static inline u16 DISPC_PIC_SIZE_OFFSET(enum omap_plane plane) case OMAP_DSS_VIDEO2: return 0x0028; case OMAP_DSS_VIDEO3: + case OMAP_DSS_WB: return 0x0094; default: BUG(); @@ -655,6 +672,7 @@ static inline u16 DISPC_ACCU0_OFFSET(enum omap_plane plane) case OMAP_DSS_VIDEO2: return 0x002C; case OMAP_DSS_VIDEO3: + case OMAP_DSS_WB: return 0x; default: BUG(); @@ -674,6 +692,8 @@ static inline u16 DISPC_ACCU2_0_OFFSET(enum omap_plane plane) return 0x0560; case OMAP_DSS_VIDEO3: return 0x0428; +
[PATCH 12/21] OMAPDSS: DISPC: Configure input and output sizes for writeback
Writeback uses the WB_PICTURE_SIZE register to define the size of the content
written to memory, this is the output of the scalar. It uses the WB_SIZE
register to define the size of the content coming from the overlay/manager to
which it is connected, this is the input to the scalar. This naming is different
as compared to overlays.
Add checks for writeback in dispc_plane_set_input_size() and
dispc_plane_set_output_size() to write to the correct registers.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 60a60fc..8673a33 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -723,7 +723,7 @@ static void dispc_plane_set_input_size(enum omap_plane
plane, int width,
{
u32 val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
- if (plane == OMAP_DSS_GFX)
+ if (plane == OMAP_DSS_GFX || plane == OMAP_DSS_WB)
dispc_write_reg(DISPC_OVL_SIZE(plane), val);
else
dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
@@ -738,7 +738,10 @@ static void dispc_plane_set_output_size(enum omap_plane
plane, int width,
val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
- dispc_write_reg(DISPC_OVL_SIZE(plane), val);
+ if (plane == OMAP_DSS_WB)
+ dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
+ else
+ dispc_write_reg(DISPC_OVL_SIZE(plane), val);
}
static void dispc_plane_set_zorder(enum omap_plane plane,
--
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 13/21] OMAPDSS: DISPC: Pass dummy scalar output rates for writeback pipeline
The scalar output rate for writeback pipeline when configured in memory to
memory mode isn't a fixed rate, it can increase or reduce based on the time
it needs to downscale. It also depends on the rate at which it can receive
and push out data from/to the interconnect.
Set the scalar output rates for writeback to a low dummy value(set to 1) to
represent that it can output at low rates, this is done so that maximum
downscaling is possible in memory to memory mode.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 8673a33..1d5dddf 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3011,21 +3011,30 @@ unsigned long dispc_core_clk_rate(void)
static unsigned long dispc_plane_output_rate(enum omap_plane plane)
{
- enum omap_channel channel = dispc_ovl_get_channel_out(plane);
+ if (plane != OMAP_DSS_WB) {
+ enum omap_channel channel = dispc_ovl_get_channel_out(plane);
- return dispc_mgr_pclk_rate(channel);
+ return dispc_mgr_pclk_rate(channel);
+ } else {
+ return 1;
+ }
}
static unsigned long dispc_plane_lclk_rate(enum omap_plane plane)
{
- enum omap_channel channel = dispc_ovl_get_channel_out(plane);
- if (dss_mgr_is_lcd(channel))
- return dispc_mgr_lclk_rate(channel);
- else
- return dispc_fclk_rate();
+ if (plane != OMAP_DSS_WB) {
+ enum omap_channel channel = dispc_ovl_get_channel_out(plane);
+ if (dss_mgr_is_lcd(channel))
+ return dispc_mgr_lclk_rate(channel);
+ else
+ return dispc_fclk_rate();
+ } else {
+ return 1;
+ }
}
+
static void dispc_dump_clocks_channel(struct seq_file *s, enum omap_channel
channel)
{
int lcd, pcd;
--
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 14/21] OMAPDSS: DISPC: Downscale chroma if plane is writeback
When converting YUYV444 content to YUV422 or NV12 formats through writeback
pipeline, the scalar needs to downscale the chroma plane. Ensure that chroma
is downscaled when the pipeline is writeback.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 1d5dddf..f3bf93d 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1465,7 +1465,7 @@ static void dispc_plane_set_scaling_uv(enum omap_plane
plane,
{
int scale_x = out_width != orig_width;
int scale_y = out_height != orig_height;
- bool chroma_upscale = true;
+ bool chroma_upscale = plane != OMAP_DSS_WB ? true : false;
if (!dss_has_feature(FEAT_HANDLE_UV_SEPARATE))
return;
--
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 15/21] OMAPDSS: DISPC: Don't set chroma resampling bit for writeback
The bit YUVCHROMARESAMPLING isn't there for writeback in DISPC_WB_ATTRIBUTES2.
It isn't there because we don't upsample chroma like for video pipelines, we
downsample chroma in writeback to get YUV422 or NV12 formats from the YUV444
input.
Ignore this bit in dispc_ovl_set_scaling_uv() if the plane is OMAP_DSS_WB.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index f3bf93d..b0f14c0 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1473,7 +1473,8 @@ static void dispc_plane_set_scaling_uv(enum omap_plane
plane,
color_mode != OMAP_DSS_COLOR_UYVY
color_mode != OMAP_DSS_COLOR_NV12)) {
/* reset chroma resampling for RGB formats */
- REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane), 0, 8, 8);
+ if (plane != OMAP_DSS_WB)
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane), 0, 8, 8);
return;
}
@@ -1525,8 +1526,10 @@ static void dispc_plane_set_scaling_uv(enum omap_plane
plane,
out_width, out_height, five_taps,
rotation, DISPC_COLOR_COMPONENT_UV);
- REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane),
- (scale_x || scale_y) ? 1 : 0, 8, 8);
+ if (plane != OMAP_DSS_WB)
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane),
+ (scale_x || scale_y) ? 1 : 0, 8, 8);
+
/* set H scaling */
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), scale_x ? 1 : 0, 5, 5);
/* set V scaling */
--
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 16/21] OMAPDSS: DISPC: Add function to set channel in for writeback
Writeback can take input from either one of the overlays, or one of the overlay
managers. Add an enum which represents the channel_in for writeback, and maps
to the register field programming.
Add a function to configure channel in for writeback. This will be used later in
APPLY.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |7 +++
drivers/video/omap2/dss/dss.h | 13 +
2 files changed, 20 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index b0f14c0..a33ed8e 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -987,6 +987,13 @@ static enum omap_channel dispc_ovl_get_channel_out(enum
omap_plane plane)
return channel;
}
+void dispc_wb_set_channel_in(enum dss_writeback_channel channel)
+{
+ enum omap_plane plane = OMAP_DSS_WB;
+
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), channel, 18, 16);
+}
+
static void dispc_plane_set_burst_size(enum omap_plane plane,
enum omap_burst_size burst_size)
{
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 4b1ca03..ea17d68 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -113,6 +113,17 @@ enum dss_dsi_content_type {
DSS_DSI_CONTENT_GENERIC,
};
+enum dss_writeback_channel {
+ DSS_WB_LCD1_MGR = 0,
+ DSS_WB_LCD2_MGR = 1,
+ DSS_WB_TV_MGR = 2,
+ DSS_WB_OVL0 = 3,
+ DSS_WB_OVL1 = 4,
+ DSS_WB_OVL2 = 5,
+ DSS_WB_OVL3 = 6,
+ DSS_WB_LCD3_MGR = 7,
+};
+
struct dss_clock_info {
/* rates that we get with dividers below */
unsigned long fck;
@@ -470,6 +481,8 @@ int dispc_mgr_get_clock_div(enum omap_channel channel,
void dispc_mgr_setup(enum omap_channel channel,
struct omap_overlay_manager_info *info);
+void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
+
/* VENC */
#ifdef CONFIG_OMAP2_DSS_VENC
int venc_init_platform_driver(void) __init;
--
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 03/21] OMAPDSS: DISPC: Rename fifo/burst related functions from dispc_ovl_* to dispc_plane_*
Writeback pipeline uses fifo and burst related IP similar to what the graphics
and video pipe have. Rename the related functions from dispc_ovl_* to
dispc_plane_*. The actual registers are kept as DISPC_OVL_* only to prevent too
much change.
All functions which are common to overlays and writeback are to be named as
dispc_plane_*, functions which are specific to overlays are to be named as
dispc_ovl_*, and writeback as dispc_wb_*.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c |4 ++--
drivers/video/omap2/dss/dispc.c | 30 +++---
drivers/video/omap2/dss/dss.h |4 ++--
3 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 2b1fa85..9abeca0 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -618,7 +618,7 @@ static void dss_ovl_write_regs_extra(struct omap_overlay
*ovl)
dispc_ovl_enable(ovl-id, op-enabled);
dispc_ovl_set_channel_out(ovl-id, op-channel);
- dispc_ovl_set_fifo_threshold(ovl-id, op-fifo_low, op-fifo_high);
+ dispc_plane_set_fifo_threshold(ovl-id, op-fifo_low, op-fifo_high);
mp = get_mgr_priv(ovl-manager);
@@ -973,7 +973,7 @@ static void dss_ovl_setup_fifo(struct omap_overlay *ovl)
if (!op-enabled !op-enabling)
return;
- dispc_ovl_compute_fifo_thresholds(ovl-id, fifo_low, fifo_high,
+ dispc_plane_compute_fifo_thresholds(ovl-id, fifo_low, fifo_high,
use_fifo_merge, ovl_manual_update(ovl));
dss_apply_ovl_fifo_thresholds(ovl, fifo_low, fifo_high);
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index eae9da4..44e86ad 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -866,7 +866,7 @@ static void dispc_ovl_set_color_mode(enum omap_plane plane,
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), m, 4, 1);
}
-static void dispc_ovl_configure_burst_type(enum omap_plane plane,
+static void dispc_plane_configure_burst_type(enum omap_plane plane,
enum omap_dss_rotation_type rotation_type)
{
if (dss_has_feature(FEAT_BURST_2D) == 0)
@@ -976,7 +976,7 @@ static enum omap_channel dispc_ovl_get_channel_out(enum
omap_plane plane)
return channel;
}
-static void dispc_ovl_set_burst_size(enum omap_plane plane,
+static void dispc_plane_set_burst_size(enum omap_plane plane,
enum omap_burst_size burst_size)
{
static const unsigned shifts[] = { 6, 14, 14, 14, };
@@ -993,10 +993,10 @@ static void dispc_configure_burst_sizes(void)
/* Configure burst size always to maximum size */
for (i = 0; i omap_dss_get_num_overlays(); ++i)
- dispc_ovl_set_burst_size(i, burst_size);
+ dispc_plane_set_burst_size(i, burst_size);
}
-static u32 dispc_ovl_get_burst_size(enum omap_plane plane)
+static u32 dispc_plane_get_burst_size(enum omap_plane plane)
{
unsigned unit = dss_feat_get_burst_size_unit();
/* burst multiplier is always x8 (see dispc_configure_burst_sizes()) */
@@ -1121,7 +1121,7 @@ static void dispc_init_fifos(void)
}
}
-static u32 dispc_ovl_get_fifo_size(enum omap_plane plane)
+static u32 dispc_plane_get_fifo_size(enum omap_plane plane)
{
int fifo;
u32 size = 0;
@@ -1134,7 +1134,7 @@ static u32 dispc_ovl_get_fifo_size(enum omap_plane plane)
return size;
}
-void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
+void dispc_plane_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
{
u8 hi_start, hi_end, lo_start, lo_end;
u32 unit;
@@ -1174,7 +1174,7 @@ void dispc_enable_fifomerge(bool enable)
REG_FLD_MOD(DISPC_CONFIG, enable ? 1 : 0, 14, 14);
}
-void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
+void dispc_plane_compute_fifo_thresholds(enum omap_plane plane,
u32 *fifo_low, u32 *fifo_high, bool use_fifomerge,
bool manual_update)
{
@@ -1184,18 +1184,18 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane
plane,
*/
unsigned buf_unit = dss_feat_get_buffer_size_unit();
- unsigned ovl_fifo_size, total_fifo_size, burst_size;
+ unsigned plane_fifo_size, total_fifo_size, burst_size;
int i;
- burst_size = dispc_ovl_get_burst_size(plane);
- ovl_fifo_size = dispc_ovl_get_fifo_size(plane);
+ burst_size = dispc_plane_get_burst_size(plane);
+ plane_fifo_size = dispc_plane_get_fifo_size(plane);
if (use_fifomerge) {
total_fifo_size = 0;
for (i = 0; i omap_dss_get_num_overlays(); ++i)
- total_fifo_size += dispc_ovl_get_fifo_size(i);
+ total_fifo_size += dispc_plane_get_fifo_size(i);
} else {
- total_fifo_size = ovl_fifo_size;
+
[PATCH 17/21] OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup
Create struct omap_dss_writeback_info, this is similar to omap_overlay_info,
the major difference is that there is no parameter which describes the input
size to writeback, this is because this is always fixed, and decided by the
connected overlay or overlay manager. One more difference is that screen_width
is renamed to buf_width, to give the value of stride the writeback buffer has.
Call dispc_plane_setup() through dispc_wb_setup() to configure overlay-like
parameters. The parameters in dispc_plane_setup() which do not hold for
writeback are filled passed as zeroes or false, dispc_plane_setup() takes
care of not configuring them as they won't possess the needed overlay caps.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 30 ++
drivers/video/omap2/dss/dss.h |2 ++
include/video/omapdss.h | 13 +
3 files changed, 45 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a33ed8e..f575875 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2464,6 +2464,36 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
omap_overlay_info *oi,
return r;
}
+int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
+ const struct omap_video_timings *mgr_timings)
+{
+ int r;
+ enum omap_plane plane = OMAP_DSS_WB;
+ const int pos_x = 0, pos_y = 0;
+ const u8 zorder = 0, global_alpha = 0;
+ const bool replication = false;
+ int in_width = mgr_timings-x_res;
+ int in_height = mgr_timings-y_res;
+ unsigned long out_rate;
+ enum omap_overlay_caps caps =
+ OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA;
+
+ DSSDBG(dispc_wb_setup, pa %x, pa_uv %x, %d,%d - %dx%d, cmode %x,
+ rot %d, mir %d\n, wi-paddr, wi-p_uv_addr, in_width,
+ in_height, wi-width, wi-height, wi-color_mode, wi-rotation,
+ wi-mirror);
+
+ out_rate = dispc_plane_output_rate(plane);
+
+ r = dispc_plane_setup(plane, caps, out_rate, wi-paddr, wi-p_uv_addr,
+ wi-buf_width, pos_x, pos_y, in_width, in_height,
+ wi-width, wi-height, wi-color_mode, wi-rotation,
+ wi-mirror, zorder, wi-pre_mult_alpha, global_alpha,
+ wi-rotation_type, replication, mgr_timings);
+
+ return r;
+}
+
int dispc_ovl_enable(enum omap_plane plane, bool enable)
{
DSSDBG(dispc_enable_plane %d, %d\n, plane, enable);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ea17d68..bd7c5cf 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -482,6 +482,8 @@ void dispc_mgr_setup(enum omap_channel channel,
struct omap_overlay_manager_info *info);
void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
+int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
+ const struct omap_video_timings *timings);
/* VENC */
#ifdef CONFIG_OMAP2_DSS_VENC
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 46097bd..3729173 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -510,6 +510,19 @@ struct omap_dsi_pin_config {
int pins[OMAP_DSS_MAX_DSI_PINS];
};
+struct omap_dss_writeback_info {
+ u32 paddr;
+ u32 p_uv_addr;
+ u16 buf_width;
+ u16 width;
+ u16 height;
+ enum omap_color_mode color_mode;
+ u8 rotation;
+ enum omap_dss_rotation_type rotation_type;
+ bool mirror;
+ u8 pre_mult_alpha;
+};
+
struct omap_dss_output {
struct list_head list;
--
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 18/21] OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup()
Configure some of the writeback specific parameters in dispc_wb_setup(). The
writeback parameters configured are:
truncation: This needs to be set if the color depth input to writeback is more
than the color depth of the color mode we want to store in memory.
writeback mode: This configures whether we want to use writeback in mem to mem
or capture mode. This information will be directly passed by APPLY later.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 26 +-
drivers/video/omap2/dss/dss.h |2 +-
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index f575875..a44cbac 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2465,13 +2465,15 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
omap_overlay_info *oi,
}
int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
- const struct omap_video_timings *mgr_timings)
+ bool mem_to_mem, const struct omap_video_timings *mgr_timings)
{
int r;
+ u32 l;
enum omap_plane plane = OMAP_DSS_WB;
const int pos_x = 0, pos_y = 0;
const u8 zorder = 0, global_alpha = 0;
const bool replication = false;
+ bool truncation;
int in_width = mgr_timings-x_res;
int in_height = mgr_timings-y_res;
unsigned long out_rate;
@@ -2491,6 +2493,28 @@ int dispc_wb_setup(const struct omap_dss_writeback_info
*wi,
wi-mirror, zorder, wi-pre_mult_alpha, global_alpha,
wi-rotation_type, replication, mgr_timings);
+ switch (wi-color_mode) {
+ case OMAP_DSS_COLOR_RGB16:
+ case OMAP_DSS_COLOR_RGB24P:
+ case OMAP_DSS_COLOR_ARGB16:
+ case OMAP_DSS_COLOR_RGBA16:
+ case OMAP_DSS_COLOR_RGB12U:
+ case OMAP_DSS_COLOR_ARGB16_1555:
+ case OMAP_DSS_COLOR_XRGB16_1555:
+ case OMAP_DSS_COLOR_RGBX16:
+ truncation = true;
+ break;
+ default:
+ truncation = false;
+ break;
+ }
+
+ /* setup extra DISPC_WB_ATTRIBUTES */
+ l = dispc_read_reg(DISPC_OVL_ATTRIBUTES(plane));
+ l = FLD_MOD(l, truncation, 10, 10); /* TRUNCATIONENABLE */
+ l = FLD_MOD(l, mem_to_mem, 19, 19); /* WRITEBACKMODE */
+ dispc_write_reg(DISPC_OVL_ATTRIBUTES(plane), l);
+
return r;
}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index bd7c5cf..c49c054 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -483,7 +483,7 @@ void dispc_mgr_setup(enum omap_channel channel,
void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
- const struct omap_video_timings *timings);
+ bool mem_to_mem, const struct omap_video_timings *timings);
/* VENC */
#ifdef CONFIG_OMAP2_DSS_VENC
--
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 19/21] OMAPDSS: DISPC: Configure writeback FIFOs
Extend the DISPC fifo functions to also configure the writeback FIFO thresholds.
The most optimal configuration for writeback is to push out data to the
interconnect the moment writeback pushes enough pixels in the FIFO to form a
burst. This reduces the chance of writeback overflowing it's FIFO.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a44cbac..6068271 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -997,7 +997,7 @@ void dispc_wb_set_channel_in(enum dss_writeback_channel
channel)
static void dispc_plane_set_burst_size(enum omap_plane plane,
enum omap_burst_size burst_size)
{
- static const unsigned shifts[] = { 6, 14, 14, 14, };
+ static const unsigned shifts[] = { 6, 14, 14, 14, 14, };
int shift;
shift = shifts[plane];
@@ -1229,6 +1229,14 @@ void dispc_plane_compute_fifo_thresholds(enum omap_plane
plane,
if (manual_update dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
*fifo_low = plane_fifo_size - burst_size * 2;
*fifo_high = total_fifo_size - burst_size;
+ } else if (plane == OMAP_DSS_WB) {
+ /*
+* Most optimal configuration for writeback is to push out data
+* to the interconnect the moment writeback pushes enough pixels
+* in the FIFO to form a burst
+*/
+ *fifo_low = 0;
+ *fifo_high = burst_size;
} else {
*fifo_low = plane_fifo_size - burst_size;
*fifo_high = total_fifo_size - buf_unit;
--
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 20/21] OMAPDSS: DISPC: Add manager like functions for writeback
Add functions to enable writeback, and set/check state of GO bit. These bits are
identical in behaviour with the corresponding overlay manager bits. Configure
them in a similar way to mgr_enable() and mgr_go_* functions. Add a helper to
get the FRAMEDONE irq corresponding to writeback.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 70 +++
drivers/video/omap2/dss/dss.h |5 +++
2 files changed, 75 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 6068271..1623c9b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -535,6 +535,11 @@ u32 dispc_mgr_get_framedone_irq(enum omap_channel channel)
return mgr_desc[channel].framedone_irq;
}
+u32 dispc_wb_get_framedone_irq(void)
+{
+ return DISPC_IRQ_FRAMEDONEWB;
+}
+
bool dispc_mgr_go_busy(enum omap_channel channel)
{
return mgr_fld_read(channel, DISPC_MGR_FLD_GO) == 1;
@@ -562,6 +567,30 @@ void dispc_mgr_go(enum omap_channel channel)
mgr_fld_write(channel, DISPC_MGR_FLD_GO, 1);
}
+bool dispc_wb_go_busy(void)
+{
+ return REG_GET(DISPC_CONTROL2, 6, 6) == 1;
+}
+
+void dispc_wb_go(void)
+{
+ enum omap_plane plane = OMAP_DSS_WB;
+ bool enable, go;
+
+ enable = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0) == 1;
+
+ if (!enable)
+ return;
+
+ go = REG_GET(DISPC_CONTROL2, 6, 6) == 1;
+ if (go) {
+ DSSERR(GO bit not down for WB\n);
+ return;
+ }
+
+ REG_FLD_MOD(DISPC_CONTROL2, 1, 6, 6);
+}
+
static void dispc_plane_write_firh_reg(enum omap_plane plane, int reg,
u32 value)
{
@@ -2678,6 +2707,47 @@ void dispc_mgr_enable(enum omap_channel channel, bool
enable)
BUG();
}
+void dispc_wb_enable(bool enable)
+{
+ enum omap_plane plane = OMAP_DSS_WB;
+ struct completion frame_done_completion;
+ bool is_on;
+ int r;
+ u32 irq;
+
+ is_on = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0);
+ irq = DISPC_IRQ_FRAMEDONEWB;
+
+ if (!enable is_on) {
+ init_completion(frame_done_completion);
+
+ r = omap_dispc_register_isr(dispc_disable_isr,
+ frame_done_completion, irq);
+ if (r)
+ DSSERR(failed to register FRAMEDONEWB isr\n);
+ }
+
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), enable ? 1 : 0, 0, 0);
+
+ if (!enable is_on) {
+ if (!wait_for_completion_timeout(frame_done_completion,
+ msecs_to_jiffies(100)))
+ DSSERR(timeout waiting for FRAMEDONEWB\n);
+
+ r = omap_dispc_unregister_isr(dispc_disable_isr,
+ frame_done_completion, irq);
+ if (r)
+ DSSERR(failed to unregister FRAMEDONEWB isr\n);
+ }
+}
+
+bool dispc_wb_is_enabled(void)
+{
+ enum omap_plane plane = OMAP_DSS_WB;
+
+ return REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0);
+}
+
void dispc_lcd_enable_signal_polarity(bool act_high)
{
if (!dss_has_feature(FEAT_LCDENABLEPOL))
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index c49c054..59ea86a 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -481,6 +481,11 @@ int dispc_mgr_get_clock_div(enum omap_channel channel,
void dispc_mgr_setup(enum omap_channel channel,
struct omap_overlay_manager_info *info);
+u32 dispc_wb_get_framedone_irq(void);
+bool dispc_wb_go_busy(void);
+void dispc_wb_go(void);
+void dispc_wb_enable(bool enable);
+bool dispc_wb_is_enabled(void);
void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
bool mem_to_mem, const struct omap_video_timings *timings);
--
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 21/21] OMAPDSS: DISPC: Configure color conversion coefficients for writeback
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),
@@ -710,6 +720,8 @@ static void _dispc_setup_color_conv_coef(void)
11, 11);
}
+#undef RGBTOYUV
+#undef YUVTORGB
#undef CVAL
}
--
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: [RFC PATCH 1/6] ARM: mm: define LoUIS API for cache maintenance ops
On Thu, Sep 13, 2012 at 11:20:46AM +0100, Lorenzo Pieralisi wrote: +/* + * Flush caches up to Level of Unification Inner Shareable + */ +#ifdef MULTI_CACHE +#define flush_cache_louis() cpu_cache.flush_kern_cache_louis() +#else +#define flush_cache_louis() __cpuc_flush_kern_all() +#endif NAK. This is broken as you don't seem to understand what MULTI_CACHE actually means. MULTI_CACHE means that we _may_ support more than one type of cache, so it not being selected means nothing as far as whether to use flush_kern_all() or not. Follow the pattern in the rest of the file - that's the _only_ way to do this. Note that ARMv6 only and ARMv7 only kernels will not have MULTI_CACHE defined (I mentioned this on Monday in our call, though not explicitly by that name.) diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S index 2d8ff3a..28e91f8 100644 --- a/arch/arm/mm/proc-macros.S +++ b/arch/arm/mm/proc-macros.S @@ -293,12 +293,17 @@ ENTRY(\name\()_processor_functions) .size \name\()_processor_functions, . - \name\()_processor_functions .endm -.macro define_cache_functions name:req +.macro define_cache_functions name:req, cachelouis=0 .align 2 .type \name\()_cache_fns, #object ENTRY(\name\()_cache_fns) .long \name\()_flush_icache_all .long \name\()_flush_kern_cache_all + .if \cachelouis + .long \name\()_flush_kern_cache_louis + .else + .long \name\()_flush_kern_cache_all + .endif .long \name\()_flush_user_cache_all .long \name\()_flush_user_cache_range .long \name\()_coherent_kern_range And what the above means is that _every_ cache support file must supply a XXX_flush_kern_cache_louis function name. If there is no separate implementation, then name it an alias for the XXX_flush_cache_all function. -- 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: [RFC PATCH 4/6] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Sep 13, 2012 at 11:20:49AM +0100, Lorenzo Pieralisi wrote:
In processors like A15/A7 L2 cache is unified and integrated within the
processor cache hierarchy, so that it is not considered an outer cache
anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
all cache levels up to Level of Coherency (LoC) that includes
the L2 unified cache.
When a single CPU is suspended (CPU idle) a complete L2 clean is not
required, so generic cpu_suspend code must clean the data cache using the
newly introduced cache LoUIS function.
The context and stack pointer (context pointer) are cleaned to main memory
using cache area functions that operate on MVA and guarantee that the data
is written back to main memory (perform cache cleaning up to the Point of
Coherency - PoC) so that the processor can fetch the context when the MMU
is off in the cpu_resume code path.
outer_cache management remains unchanged.
LoUIS matches the power domain affected by turning a single CPU off
on most (all?) current v7 SoCs where this matters, but only by coincidence.
There is no guarantee of that.
The _louis() API is useful, because this is exactly what you need to to
I-/D-/TLB synchronisation in an SMP OS. Using it as preparation for
powering a CPU off feels like misuse, at least in theory.
For powerdown, we would logically need a separate function,
flush_cache_cpu() or something, whose job is precisely to flush those
levels which will be affected by the powerdown if that single CPU.
In a multi-cluster system, it's possible that the architectural cache
level this corresponds to is not even the same across all clusters (though
for the foreseeable future it probably will be -- at least for all clusters
participating in SMP).
I don't know how urgent it is to fix this if there are just a few call
sites for flush_cache_louis(). My worry would be that misuse of these
functions propagates before we find that this needs cleaning up...
Cheers
---Dave
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/suspend.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 1794cc3..358bca3 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -17,6 +17,8 @@ extern void cpu_resume_mmu(void);
*/
void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
{
+ u32 *ctx = ptr;
+
*save_ptr = virt_to_phys(ptr);
/* This must correspond to the LDM in cpu_resume() assembly */
@@ -26,7 +28,20 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32
*save_ptr)
cpu_do_suspend(ptr);
- flush_cache_all();
+ flush_cache_louis();
+
+ /*
+ * flush_cache_louis does not guarantee that
+ * save_ptr and ptr are cleaned to main memory,
+ * just up to the Level of Unification Inner Shareable.
+ * Since the context pointer and context itself
+ * are to be retrieved with the MMU off that
+ * data must be cleaned from all cache levels
+ * to main memory using area cache primitives.
+ */
+ __cpuc_flush_dcache_area(ctx, ptrsz);
+ __cpuc_flush_dcache_area(save_ptr, sizeof(*save_ptr));
+
outer_clean_range(*save_ptr, *save_ptr + ptrsz);
outer_clean_range(virt_to_phys(save_ptr),
virt_to_phys(save_ptr) + sizeof(*save_ptr));
--
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: [RFC PATCH 1/6] ARM: mm: define LoUIS API for cache maintenance ops
On Thu, Sep 13, 2012 at 01:36:04PM +0100, Russell King - ARM Linux wrote: On Thu, Sep 13, 2012 at 11:20:46AM +0100, Lorenzo Pieralisi wrote: +/* + * Flush caches up to Level of Unification Inner Shareable + */ +#ifdef MULTI_CACHE +#define flush_cache_louis() cpu_cache.flush_kern_cache_louis() +#else +#define flush_cache_louis() __cpuc_flush_kern_all() +#endif NAK. This is broken as you don't seem to understand what MULTI_CACHE actually means. MULTI_CACHE means that we _may_ support more than one type of cache, so it not being selected means nothing as far as whether to use flush_kern_all() or not. Follow the pattern in the rest of the file - that's the _only_ way to do this. Note that ARMv6 only and ARMv7 only kernels will not have MULTI_CACHE defined (I mentioned this on Monday in our call, though not explicitly by that name.) Point taken, I will fix it. diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S index 2d8ff3a..28e91f8 100644 --- a/arch/arm/mm/proc-macros.S +++ b/arch/arm/mm/proc-macros.S @@ -293,12 +293,17 @@ ENTRY(\name\()_processor_functions) .size \name\()_processor_functions, . - \name\()_processor_functions .endm -.macro define_cache_functions name:req +.macro define_cache_functions name:req, cachelouis=0 .align 2 .type \name\()_cache_fns, #object ENTRY(\name\()_cache_fns) .long \name\()_flush_icache_all .long \name\()_flush_kern_cache_all + .if \cachelouis + .long \name\()_flush_kern_cache_louis + .else + .long \name\()_flush_kern_cache_all + .endif .long \name\()_flush_user_cache_all .long \name\()_flush_user_cache_range .long \name\()_coherent_kern_range And what the above means is that _every_ cache support file must supply a XXX_flush_kern_cache_louis function name. If there is no separate implementation, then name it an alias for the XXX_flush_cache_all function. I will do that, thanks for the review. Lorenzo -- 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: [RFC PATCH 4/6] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Sep 13, 2012 at 6:23 PM, Dave Martin dave.mar...@linaro.org wrote: On Thu, Sep 13, 2012 at 11:20:49AM +0100, Lorenzo Pieralisi wrote: In processors like A15/A7 L2 cache is unified and integrated within the processor cache hierarchy, so that it is not considered an outer cache anymore. For processors like A15/A7 flush_cache_all() ends up cleaning all cache levels up to Level of Coherency (LoC) that includes the L2 unified cache. When a single CPU is suspended (CPU idle) a complete L2 clean is not required, so generic cpu_suspend code must clean the data cache using the newly introduced cache LoUIS function. The context and stack pointer (context pointer) are cleaned to main memory using cache area functions that operate on MVA and guarantee that the data is written back to main memory (perform cache cleaning up to the Point of Coherency - PoC) so that the processor can fetch the context when the MMU is off in the cpu_resume code path. outer_cache management remains unchanged. LoUIS matches the power domain affected by turning a single CPU off on most (all?) current v7 SoCs where this matters, but only by coincidence. There is no guarantee of that. The _louis() API is useful, because this is exactly what you need to to I-/D-/TLB synchronisation in an SMP OS. Using it as preparation for powering a CPU off feels like misuse, at least in theory. For powerdown, we would logically need a separate function, flush_cache_cpu() or something, whose job is precisely to flush those levels which will be affected by the power-down if that single CPU. In the series, there is patch [PATCH 3/6] which adds an API which let you operate on a specific level. Regards Santosh -- 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: [RFC PATCH 1/6] ARM: mm: define LoUIS API for cache maintenance ops
On Thu, Sep 13, 2012 at 12:39:49PM +0100, Dave Martin wrote:
We could introduce something like CONFIG_ARM_HAVE_CACHEFLUSH_LOUIS, and
do:
asm/glue-cache.h
#ifndef MULTI_CACHE
#ifdef CONFIG_HAVE_ARM_CACHEFLUSH_LOUIS
#define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_cache_louis)
#else
#define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_all)
#endif
#endif
asm/cacheflush.h
#ifdef MULTI_CACHE
#define flush_cache_louis() cpu_cache.flush_kern_cache_louis()
#else
#define flush_cache_louis() __cpuc_flush_kern_cache_louis()
#endif
No, this is stupidly complicated and is fragile. Just alias the
functions, like we do in cache-v4wt.S:
.globl v4wt_dma_flush_range
.equv4wt_dma_flush_range, v4wt_dma_inv_range
except, you'll need:
.globl v4wt_flush_kern_cache_louis
.equv4wt_flush_kern_cache_louis, v4wt_flush_kern_cache_all
You can do it automatically, using the attached sedscript and this bit
of shell:
$ for f in $(grep -l define_cache_functions arch/arm/mm/*.S ); do
sed -if sedscript $f
git add $f
done
$ git commit -s
Do that first, and then go over those which you need to add a real
flush_kern_cache_louis function to.
1,/__INITDATA\|define struct cpu_cache_fns/ {
/ENTRY.*flush_kern_cache_all/ {
h
s/.*(\([^_]*\)_.*/\t.globl\t\1_flush_kern_cache_louis\n\t.equ\t\1_flush_kern_cache_louis,
\1_flush_kern_cache_all\n/
x
}
/__INITDATA\|define struct cpu_cache_fns/ {
H
g
}
}
Re: [RFC PATCH 4/6] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Sep 13, 2012 at 06:31:35PM +0530, Shilimkar, Santosh wrote: In the series, there is patch [PATCH 3/6] which adds an API which let you operate on a specific level. Which is introduced but as far as I can see, is never used in the patch set. Therefore, it shouldn't be introduced. We've been here before many many many times, where people introduce stuff into the kernel, and then they never get around to using the damned stuff. It's happened far too many times to permit on a but I will use it in the future kind of arguments. If you're going to introduce something new, include the users in the patch set, or don't bother submitting the new function in the vague hope that some day it will get used. -- 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: [RFC PATCH 4/6] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Sep 13, 2012 at 6:38 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Sep 13, 2012 at 06:31:35PM +0530, Shilimkar, Santosh wrote: In the series, there is patch [PATCH 3/6] which adds an API which let you operate on a specific level. Which is introduced but as far as I can see, is never used in the patch set. Therefore, it shouldn't be introduced. We've been here before many many many times, where people introduce stuff into the kernel, and then they never get around to using the damned stuff. It's happened far too many times to permit on a but I will use it in the future kind of arguments. If you're going to introduce something new, include the users in the patch set, or don't bother submitting the new function in the vague hope that some day it will get used. Fair enough. We can postpone adding that API now in this series and add it along with the user. For the record, it was added to use in the A15 low power code to operate on L1 and L2 levels based on the power domain states. Regards santosh -- 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 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 v2 04/15] dmaengine: Pass no_wakeup parameter via device_prep_dma_cyclic() callback
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.
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 | 5 +++--
13 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 3934fcc..c1ea42c 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
+ * @no_wakeup: suppress interrupts
* @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)
+ bool no_wakeup, 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..dfaf0df 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
+ * @no_wakeup: suppress interrupts
* @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, bool no_wakeup,
+ 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..8f05eb2 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)
+ bool no_wakeup, 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..3109fa0 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)
+ bool no_wakeup, 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..6d70d9c 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)
+ bool no_wakeup, void *context)
{
struct mmp_tdma_chan *tdmac = to_mmp_tdma_chan(chan);
struct mmp_tdma_desc *desc;
diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index 7f41b25..d137ebb 100644
[PATCH v2 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 v2 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 v2 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 v2 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 v2 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 v2 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 v2 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
[PATCH v2 00/15] ASoC: OMAP: Convert to use dmaengine
Hello, Changelog: - 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 no_wakeup parameter to dmaengine_prep_dma_cyclic() dmaengine: Pass no_wakeup parameter via device_prep_dma_cyclic() callback dmaengine: omap-dma: Add support for no_wakeup 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 | 47 -- 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 | 8 +- 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 | 3 +- 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 v2 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 v2 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 v2 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 v2 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 v2 05/15] dmaengine: omap-dma: Add support for no_wakeup in cyclic mode
When requested 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 | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c6a711d..cbe087e 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -374,6 +374,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_dma_cyclic(
struct omap_desc *d;
dma_addr_t dev_addr;
unsigned es, sync_type;
+ unsigned long tx_flags = 0;
u32 burst;
if (dir == DMA_DEV_TO_MEM) {
@@ -429,7 +430,11 @@ 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 (!no_wakeup) {
+ omap_enable_dma_irq(c-dma_ch, OMAP_DMA_FRAME_IRQ);
+ tx_flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
+ }
omap_disable_dma_irq(c-dma_ch, OMAP_DMA_BLOCK_IRQ);
}
@@ -438,7 +443,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, tx_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 v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
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.
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 | 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;
--
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: [RFC PATCH 1/6] ARM: mm: define LoUIS API for cache maintenance ops
On Thu, Sep 13, 2012 at 02:03:34PM +0100, Russell King - ARM Linux wrote:
On Thu, Sep 13, 2012 at 12:39:49PM +0100, Dave Martin wrote:
We could introduce something like CONFIG_ARM_HAVE_CACHEFLUSH_LOUIS, and
do:
asm/glue-cache.h
#ifndef MULTI_CACHE
#ifdef CONFIG_HAVE_ARM_CACHEFLUSH_LOUIS
#define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_cache_louis)
#else
#define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_all)
#endif
#endif
asm/cacheflush.h
#ifdef MULTI_CACHE
#define flush_cache_louis() cpu_cache.flush_kern_cache_louis()
#else
#define flush_cache_louis() __cpuc_flush_kern_cache_louis()
#endif
No, this is stupidly complicated and is fragile. Just alias the
functions, like we do in cache-v4wt.S:
.globl v4wt_dma_flush_range
.equv4wt_dma_flush_range, v4wt_dma_inv_range
except, you'll need:
.globl v4wt_flush_kern_cache_louis
.equv4wt_flush_kern_cache_louis, v4wt_flush_kern_cache_all
You can do it automatically, using the attached sedscript and this bit
of shell:
$ for f in $(grep -l define_cache_functions arch/arm/mm/*.S ); do
sed -if sedscript $f
git add $f
done
$ git commit -s
Do that first, and then go over those which you need to add a real
flush_kern_cache_louis function to.
Sure, that works better.
I was trying to think of a more localised way to do it, but the result
was admittedly rather ugly (and not that localised once we select
HAVE_ARM_CACHEFLUSH_LOUIS all over the place).
Cheers
---Dave
1,/__INITDATA\|define struct cpu_cache_fns/ {
/ENTRY.*flush_kern_cache_all/ {
h
s/.*(\([^_]*\)_.*/\t.globl\t\1_flush_kern_cache_louis\n\t.equ\t\1_flush_kern_cache_louis,
\1_flush_kern_cache_all\n/
x
}
/__INITDATA\|define struct cpu_cache_fns/ {
H
g
}
}
--
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] can: c_can: Move pm_runtime_enable/disable calls to common code
AnilKumar Ch anilku...@ti.com writes: Move pm_runtime_enable/disable calls to c_can.c driver. Current implementation is such that platform driver is doing pm_runtime enable/disable and core driver is doing put_sync/get_sync. PM runtime calls should be invoked if there is a valid device pointer from platform driver so moving enable/disable calls to core driver. Signed-off-by: AnilKumar Ch anilku...@ti.com --- Incorporated Kevin's comments on can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller patch. This looks better, but in addition, you can get rid of the runtime PM helper functions you added (the ones that check for priv-device) and call the pm_runtime_get/put APIs directly. 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: [RFC PATCH 4/6] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Sep 13, 2012 at 01:53:48PM +0100, Dave Martin wrote: On Thu, Sep 13, 2012 at 11:20:49AM +0100, Lorenzo Pieralisi wrote: In processors like A15/A7 L2 cache is unified and integrated within the processor cache hierarchy, so that it is not considered an outer cache anymore. For processors like A15/A7 flush_cache_all() ends up cleaning all cache levels up to Level of Coherency (LoC) that includes the L2 unified cache. When a single CPU is suspended (CPU idle) a complete L2 clean is not required, so generic cpu_suspend code must clean the data cache using the newly introduced cache LoUIS function. The context and stack pointer (context pointer) are cleaned to main memory using cache area functions that operate on MVA and guarantee that the data is written back to main memory (perform cache cleaning up to the Point of Coherency - PoC) so that the processor can fetch the context when the MMU is off in the cpu_resume code path. outer_cache management remains unchanged. LoUIS matches the power domain affected by turning a single CPU off on most (all?) current v7 SoCs where this matters, but only by coincidence. There is no guarantee of that. The _louis() API is useful, because this is exactly what you need to to I-/D-/TLB synchronisation in an SMP OS. Using it as preparation for powering a CPU off feels like misuse, at least in theory. For powerdown, we would logically need a separate function, flush_cache_cpu() or something, whose job is precisely to flush those levels which will be affected by the powerdown if that single CPU. Yes, you are right, we discussed this at length and I think that cleaning to LoUIS is a good trade-off for now. Detecting what cache levels are affected by the power down in question implies linking caches to power domains in some sensible (and ARM generic) way, let's not go that far for now. Thanks, Lorenzo -- 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] can: c_can: Move pm_runtime_enable/disable calls to common code
On 09/13/2012 04:14 PM, Kevin Hilman wrote: AnilKumar Ch anilku...@ti.com writes: Move pm_runtime_enable/disable calls to c_can.c driver. Current implementation is such that platform driver is doing pm_runtime enable/disable and core driver is doing put_sync/get_sync. PM runtime calls should be invoked if there is a valid device pointer from platform driver so moving enable/disable calls to core driver. Signed-off-by: AnilKumar Ch anilku...@ti.com --- Incorporated Kevin's comments on can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller patch. This looks better, but in addition, you can get rid of the runtime PM helper functions you added (the ones that check for priv-device) and call the pm_runtime_get/put APIs directly. But priv-device might be NULL. AFAICS pm_runtime_get() is not safe to be called with a NULL pointer. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH 4/6] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Sep 13, 2012 at 02:01:35PM +0100, Shilimkar, Santosh wrote: On Thu, Sep 13, 2012 at 6:23 PM, Dave Martin dave.mar...@linaro.org wrote: [...] LoUIS matches the power domain affected by turning a single CPU off on most (all?) current v7 SoCs where this matters, but only by coincidence. There is no guarantee of that. The _louis() API is useful, because this is exactly what you need to to I-/D-/TLB synchronisation in an SMP OS. Using it as preparation for powering a CPU off feels like misuse, at least in theory. For powerdown, we would logically need a separate function, flush_cache_cpu() or something, whose job is precisely to flush those levels which will be affected by the power-down if that single CPU. In the series, there is patch [PATCH 3/6] which adds an API which let you operate on a specific level. Yep, but that's not callable from __cpu_suspend_save in a generic way (it is v7 specific and we are not going to add another API/macro for that to be usable in generic code, at least for now). Let's keep that patch in our trees and as Russell suggested we will repost it with the PM BSP accordingly to raise the point and take it from there. Thanks, Lorenzo -- 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
Felipe Balbi ba...@ti.com writes: [...] I just ran same tests on pandaboard and i2c is suspended actually, though no power domain transitions to RET. Do we not have retention while idle on pandaboard ? Not for CORE. Only CPUx and MPU domains will be transitioning on OMAP4, and then, only with CPUidle enabled. Until we have CORE retention support in mainline (we're almost there) OMAP4 is not a useful test platform for device PM. 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: [PATCH 1/4] i2c: introduce i2c-cbus driver
On Thu, Sep 13, 2012 at 12:53:09PM +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 My main question is: what is CBUS? It doesn't look like an I2C/SMBUS host controller, but some bit-banging protocol? As such, it shouldn't go to i2c/busses/. And the protocol doesn't look much like I2C, neither. There is no ACK/NACK/START/STOP, so I wonder if it should be in i2c after all... It's some legacy 3-wire bus protocol. Not much info is available, there's some references to CBUS in i2c spec, so I thought it wouldn't be a completly wrong place for it... A. -- 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] mtd: nand: omap2: Fix the nand-disk led trigger
When the omap2 nand flash driver is used, the nand-disk led trigger does not
work due to nand_wait_ready not being called.
This patch exports the trigger from nand_base.c, letting specific drivers
such omap2 control the led as appropriate.
Signed-off-by: Raphael Assenat r...@8d.com
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index a11253a..b967c45 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -103,7 +103,7 @@ static int nand_do_write_oob(struct mtd_info *mtd, loff_t
to,
* For devices which display every fart in the system on a separate LED. Is
* compiled away when LED support is disabled.
*/
-DEFINE_LED_TRIGGER(nand_led_trigger);
+DEFINE_LED_TRIGGER_GLOBAL(nand_led_trigger);
static int check_offs_len(struct mtd_info *mtd,
loff_t ofs, uint64_t len)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index ac4fd75..6aa683f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -19,6 +19,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/leds.h
#include linux/omap-dma.h
#include linux/io.h
#include linux/slab.h
@@ -254,6 +255,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
int ret = 0;
u32 *p = (u32 *)buf;
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
/* take care of subpage reads */
if (len % 4) {
if (info-nand.options NAND_BUSWIDTH_16)
@@ -284,6 +287,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
/* disable and stop the PFPW engine */
gpmc_prefetch_reset(info-gpmc_cs);
}
+
+ led_trigger_event(nand_led_trigger, LED_OFF);
}
/**
@@ -302,6 +307,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
u16 *p = (u16 *)buf;
unsigned long tim, limit;
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
/* take care of subpage writes */
if (len % 2 != 0) {
writeb(*buf, info-nand.IO_ADDR_W);
@@ -335,6 +342,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
/* disable and stop the PFPW engine */
gpmc_prefetch_reset(info-gpmc_cs);
}
+
+ led_trigger_event(nand_led_trigger, LED_OFF);
}
/*
@@ -366,6 +375,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
unsigned n;
int ret;
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
if (addr = high_memory) {
struct page *p1;
@@ -417,6 +428,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
gpmc_prefetch_reset(info-gpmc_cs);
dma_unmap_sg(info-dma-device-dev, sg, 1, dir);
+
+ led_trigger_event(nand_led_trigger, LED_OFF);
return 0;
out_copy_unmap:
@@ -428,6 +441,9 @@ out_copy:
else
is_write == 0 ? omap_read_buf8(mtd, (u_char *) addr, len)
: omap_write_buf8(mtd, (u_char *) addr, len);
+
+ led_trigger_event(nand_led_trigger, LED_OFF);
+
return 0;
}
@@ -886,6 +902,8 @@ static int omap_wait(struct mtd_info *mtd, struct nand_chip
*chip)
else
timeo += (HZ * 20) / 1000;
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
gpmc_nand_write(info-gpmc_cs,
GPMC_NAND_COMMAND, (NAND_CMD_STATUS 0xFF));
while (time_before(jiffies, timeo)) {
@@ -894,6 +912,7 @@ static int omap_wait(struct mtd_info *mtd, struct nand_chip
*chip)
break;
cond_resched();
}
+ led_trigger_event(nand_led_trigger, LED_OFF);
status = gpmc_nand_read(info-gpmc_cs, GPMC_NAND_DATA);
return status;
@@ -909,6 +928,8 @@ static int omap_dev_ready(struct mtd_info *mtd)
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
+ led_trigger_event(nand_led_trigger, LED_FULL);
+
val = gpmc_read_status(GPMC_GET_IRQ_STATUS);
if ((val 0x100) == 0x100) {
/* Clear IRQ Interrupt */
@@ -923,6 +944,8 @@ static int omap_dev_ready(struct mtd_info *mtd)
val = gpmc_read_status(GPMC_GET_IRQ_STATUS);
}
}
+
+ led_trigger_event(nand_led_trigger, LED_OFF);
return 1;
}
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 57977c6..321b7ef 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -23,6 +23,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/flashchip.h
#include linux/mtd/bbm.h
+#include linux/leds.h
struct mtd_info;
struct nand_flash_dev;
@@ -48,6 +49,9 @@ extern int nand_lock(struct mtd_info *mtd, loff_t ofs,
uint64_t len);
/* unlocks specified locked blocks
Re: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
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.
- 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;
--
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 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 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... -- 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/2] lis3: lis3lv02d_i2c: Add device tree support
Add device tree matching table support to lis3lv02d_i2c driver. If
the driver data is passed from device tree, then this driver picks
up platform data from device node through common/generic lis3lv02d.c
driver.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/misc/lis3lv02d/lis3lv02d_i2c.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
b/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
index 15255eb..e851ee8 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d_i2c.c
@@ -31,6 +31,9 @@
#include linux/i2c.h
#include linux/pm_runtime.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_platform.h
+
#include lis3lv02d.h
#define DRV_NAME lis3lv02d_i2c
@@ -102,12 +105,21 @@ static int lis3_i2c_init(struct lis3lv02d *lis3)
static union axis_conversion lis3lv02d_axis_map =
{ .as_array = { LIS3_DEV_X, LIS3_DEV_Y, LIS3_DEV_Z } };
+static struct of_device_id lis3lv02d_i2c_dt_ids[] = {
+ { .compatible = st,lis3lv02d-i2c },
+ {}
+};
+MODULE_DEVICE_TABLE(of, lis3lv02d_i2c_dt_ids);
+
static int __devinit lis3lv02d_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
int ret = 0;
struct lis3lv02d_platform_data *pdata = client-dev.platform_data;
+ if (of_match_device(lis3lv02d_i2c_dt_ids, client-dev))
+ lis3_dev.of_node = client-dev.of_node;
+
if (pdata) {
if ((pdata-driver_features LIS3_USE_BLOCK_READ)
(i2c_check_functionality(client-adapter,
@@ -255,6 +267,7 @@ static struct i2c_driver lis3lv02d_i2c_driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
.pm = lis3_pm_ops,
+ .of_match_table = of_match_ptr(lis3lv02d_i2c_dt_ids),
},
.probe = lis3lv02d_i2c_probe,
.remove = __devexit_p(lis3lv02d_i2c_remove),
--
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 0/2] lis3: lis3lv02d_i2c: Add device tree support
First patch adds device tree support to lis3lv02d_i2c driver and second patch adds platform data for lis331dlh driver to am335x EVM. These patches were tested on AM335x-EVM. AnilKumar Ch (2): lis3: lis3lv02d_i2c: Add device tree support ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm arch/arm/boot/dts/am335x-evm.dts | 42 drivers/misc/lis3lv02d/lis3lv02d_i2c.c | 13 ++ 2 files changed, 55 insertions(+) -- 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 2/2] 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 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;
+ };
+ };
+
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;
+ 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
