Re: [PATCH 0/7] crypto: omap-sham updates
Mark, On Saturday 20 October 2012 03:23 AM, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com This series updates the crypto omap-sham driver and supporting infrastructure. Notes: a) Based on current k.o. c9623de (Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media) b) These have only been tested on an omap2420 h4 and an am37x evm. If you have different hardware available and a few minutes, please test them. A quick and easy test is to enable tcrypt as a module (CONFIG_CRYPTO_TEST=m), boot, then run 'modprobe tcrypt sec=2 mode=403'. 'CONFIG_CRYPTO_SHA1' and 'CONFIG_CRYPTO_DEV_OMAP_SHAM' also have to be enabled. A quick 'grep omap-sham /proc/interrupts' will tell you if the omap-sham driver was really used. c) To test these patches, you will likely need... i) The patch included here: http://marc.info/?l=kernel-janitorsm=134910841909057w=2 ii) This patch from linux-omap/master: 27615a9 (ARM: OMAP: Trivial driver changes to remove include plat/cpu.h) iii) This patch from Paul Walmsley: http://www.spinics.net/lists/linux-omap/msg79436.html d) If you prefer, a version you can test is available at g...@github.com:mgreeraz/linux-mag.git mag/wip/crypto-test e) There is a reduction in DMA performance after switching to dmaengine (see http://www.spinics.net/lists/linux-omap/msg79855.html) f) Many thanks to Jon Hunter for testing on his omap2420 h4. Mark A. Greer (7): ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod ARM: OMAP2xxx: hwmod: Add DMA information for SHAM module ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod ARM: OMAP2+: Remove unnecessary message when no SHA IP is present crypto: omap-sham: Convert to use pm_runtime API crypto: omap-sham: Add code to use dmaengine API crypto: omap_sham: Remove usage of private DMA API Thanks for the series and oveall its looks pretty good to me. The DMA performance is understandable with need of PREFETCH support in OMAP DMA engine driver. IIRC, crypto was the only driver used this feature. From the history mostly we need to restrict the prefetch usage to applicable client driver like crypto and hence adding such parameter/api support might be the direction to go forward. Lets see what Peter reports for audio as discussed on other thread. 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: OMAP baseline test results for v3.7-rc1
On Sat, Oct 20, 2012 at 04:27:19PM +, Paul Walmsley wrote: Here's the console log from the boot test here: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/am335xbone/am335xbone_log.txt And here's the kernel config and uImage+DTB from the boot test here: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/build/am33xx_only/ In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. Paul, You are using an obsolete u-boot and the legacy appended dtb method. It was my understanding that that way is just a temporary hack in case the boot loader does not support dtb. Now that u-boot has the proper support, using the dtb method is the offical boot method, AFAICT. At least, that is what people are saying on the arm list. So I think that if you want to test whether a particular board is booting correctly, it is more useful to try the offical method. People keep saying, the beaglebone works fine with v3.7-rc1, but it isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been fixed, and no one is doing anything about it either. When I read your report, it gave me a much rosier picture than is actually the case WRT the beaglebone. Thanks, Richard -- 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: OMAP baseline test results for v3.7-rc1
On Sun, 21 Oct 2012, Richard Cochran wrote: You are using an obsolete u-boot and the legacy appended dtb method. It was my understanding that that way is just a temporary hack in case the boot loader does not support dtb. Now that u-boot has the proper support, using the dtb method is the offical boot method, AFAICT. At least, that is what people are saying on the arm list. So I think that if you want to test whether a particular board is booting correctly, it is more useful to try the offical method. I'm not interested in testing the bootloader, only the kernel. And in particular, my focus is currently on the OMAP-specific parts of the boot and the PM code, not any kernel DT code. People keep saying, the beaglebone works fine with v3.7-rc1, but it isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been fixed, and no one is doing anything about it either. There's likely to be quite a bit that doesn't work in the AM335x boards in mainline, due to the fact that it's the first OMAP DT-only board. Many device drivers and subsystems are still not fully adapted to DT across most ARM boards. When I read your report, it gave me a much rosier picture than is actually the case WRT the beaglebone. Really? What section of the message provided that to you? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sun, Oct 21, 2012 at 08:23:35AM +, Paul Walmsley wrote: On Sun, 21 Oct 2012, Richard Cochran wrote: When I read your report, it gave me a much rosier picture than is actually the case WRT the beaglebone. Really? What section of the message provided that to you? It was the part that said, Passing tests - Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone It sounded to me like you were saying that the current kernel release boots just fine on the beaglebone, with no issues. It surprised me, because in fact I have had one heck of a time getting the beaglebone to boot. It is a bit of a cop-out to say that you are not interested in the boot loader. Way back when the whole dt is so cool, arm should use it too argument appeared, I wrote that, in my experience with Freescale powerpc chips, the whole kernel/dt/u-boot is a kind of Bermuda Triangle of misfortune. Looks like that dt is turning out to be just as successful for arm as it was for powerpc. Thanks, Richard -- 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 6/7] crypto: omap-sham: Add code to use dmaengine API
Hello,
I got only 3 patches out of 7.
Can you please re-submit them also to linux-cry...@vger.kernel.org
That is a list where crypto drivers are discussed.
Thanks.
- Dmitry
On Sat, Oct 20, 2012 at 12:53 AM, Mark A. Greer mgr...@animalcreek.com wrote:
From: Mark A. Greer mgr...@animalcreek.com
Add code to use the new dmaengine API alongside
the existing DMA code that uses the private
OMAP DMA API. The API to use is chosen by
defining or undefining 'OMAP_SHAM_DMA_PRIVATE'.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-sham.c | 150
+++--
1 file changed, 145 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index acb85df..c782f60 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -13,6 +13,8 @@
* Some ideas are from old omap-sha1-md5.c driver.
*/
+#define OMAP_SHAM_DMA_PRIVATE
+
#define pr_fmt(fmt) %s: fmt, __func__
#include linux/err.h
@@ -27,6 +29,10 @@
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
+#ifndef OMAP_SHAM_DMA_PRIVATE
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#endif
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/crypto.h
@@ -37,9 +43,11 @@
#include crypto/hash.h
#include crypto/internal/hash.h
+#ifdef OMAP_SHAM_DMA_PRIVATE
#include plat/cpu.h
#include plat/dma.h
#include mach/irqs.h
+#endif
#define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04))
#define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
@@ -47,6 +55,8 @@
#define SHA1_MD5_BLOCK_SIZESHA1_BLOCK_SIZE
#define MD5_DIGEST_SIZE16
+#defineDST_MAXBURST16 /* Really element number
(en) */
+
#define SHA_REG_DIGCNT 0x14
#define SHA_REG_CTRL 0x18
@@ -110,6 +120,9 @@ struct omap_sham_reqctx {
/* walk state */
struct scatterlist *sg;
+#ifndef OMAP_SHAM_DMA_PRIVATE
+ struct scatterlist sgl;
+#endif
unsigned intoffset; /* offset in current sg */
unsigned inttotal; /* total request */
@@ -143,8 +156,12 @@ struct omap_sham_dev {
int irq;
spinlock_t lock;
int err;
+#ifdef OMAP_SHAM_DMA_PRIVATE
int dma;
int dma_lch;
+#else
+ struct dma_chan *dma_lch;
+#endif
struct tasklet_struct done_task;
unsigned long flags;
@@ -312,15 +329,32 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd,
const u8 *buf,
return -EINPROGRESS;
}
+#ifndef OMAP_SHAM_DMA_PRIVATE
+static void omap_sham_dma_callback(void *param)
+{
+ struct omap_sham_dev *dd = param;
+
+ set_bit(FLAGS_DMA_READY, dd-flags);
+ tasklet_schedule(dd-done_task);
+}
+#endif
+
static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
- size_t length, int final)
+ size_t length, int final, int is_sg)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
+#ifdef OMAP_SHAM_DMA_PRIVATE
int len32;
+#else
+ struct dma_async_tx_descriptor *tx;
+ struct dma_slave_config cfg;
+ int ret;
+#endif
dev_dbg(dd-dev, xmit_dma: digcnt: %d, length: %d, final: %d\n,
ctx-digcnt, length, final);
+#ifdef OMAP_SHAM_DMA_PRIVATE
len32 = DIV_ROUND_UP(length, sizeof(u32));
omap_set_dma_transfer_params(dd-dma_lch, OMAP_DMA_DATA_TYPE_S32,
len32,
@@ -330,6 +364,48 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd,
dma_addr_t dma_addr,
omap_set_dma_src_params(dd-dma_lch, 0, OMAP_DMA_AMODE_POST_INC,
dma_addr, 0, 0);
+#else
+ memset(cfg, 0, sizeof(cfg));
+
+ cfg.dst_addr = dd-phys_base + SHA_REG_DIN(0);
+ cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.dst_maxburst = DST_MAXBURST;
+
+ ret = dmaengine_slave_config(dd-dma_lch, cfg);
+ if (ret) {
+ pr_err(omap-sham: can't configure dmaengine slave: %d\n,
ret);
+ return ret;
+ }
+
+ if (is_sg) {
+ /*
+* The SG entry passed in may not have the 'length' member
+* set correctly so use a local SG entry (sgl) with the
+* proper value for 'length' instead. If this is not done,
+* the dmaengine may try to DMA the incorrect amount of data.
+*/
+ sg_init_table(ctx-sgl, 1);
+ ctx-sgl.page_link =
RE: OMAP baseline test results for v3.7-rc1
Hi Richard, * Richard Cochran, October 21, 2012 1:05 PM: People keep saying, the beaglebone works fine with v3.7-rc1, but it isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been fixed, and no one is doing anything about it either. A fix to resolve the gpmc issue has been merged recently, so I am expecting beagle bone to boot on -rc2 (I don't have hardware to test, on vacation now), can you please try with -rc2. Note: Sending via exchange, hope this is readable. Regards Afzal-- 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: OMAP baseline test results for v3.7-rc1
On Sun, Oct 21, 2012 at 12:29:26PM +, Mohammed, Afzal wrote: Hi Richard, * Richard Cochran, October 21, 2012 1:05 PM: People keep saying, the beaglebone works fine with v3.7-rc1, but it isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been fixed, and no one is doing anything about it either. A fix to resolve the gpmc issue has been merged recently, so I am expecting beagle bone to boot on -rc2 (I don't have hardware to test, on vacation now), can you please try with -rc2. I am happy to report that v3.7-rc2 boots via the modern DT method, using Paul's am33xx_only config and U-Boot 2012.10-rc1-00148-g4668a08. Thanks, and have a nice vacation, Richard -- 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] OMAPDSS: HDMI: fix missing unlock on error in hdmi_dump_regs()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing unlock on the error handling path in function
hdmi_dump_regs().
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
no test
---
drivers/video/omap2/dss/hdmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index a48a7dd..8c9b8b3 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -644,8 +644,10 @@ static void hdmi_dump_regs(struct seq_file *s)
{
mutex_lock(hdmi.lock);
- if (hdmi_runtime_get())
+ if (hdmi_runtime_get()) {
+ mutex_unlock(hdmi.lock);
return;
+ }
hdmi.ip_data.ops-dump_wrapper(hdmi.ip_data, s);
hdmi.ip_data.ops-dump_pll(hdmi.ip_data, s);
--
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: OMAP baseline test results for v3.7-rc1
On Sat, Oct 20, 2012 at 06:58:10PM +, Paul Walmsley wrote: On Sat, 20 Oct 2012, Richard Cochran wrote: On Sat, Oct 20, 2012 at 06:12:35PM +, Paul Walmsley wrote: Just tried omap2plus_defconfig here and the board didn't boot, confirming your result. Will add a section to the testlog README.txt about that. In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. I tried both omap2plus_defconfig and your am33xx_only config, and neither one work with my (recent) u-boot version. Just sent you the MLO and u-boot.img from here via private E-mail. Those were the files that came with the BeagleBone SD card here. TI also has a u-boot tree for the AM33xx; might be worth trying: git://arago-project.org/git/projects/u-boot-am33x.git Use of the vendor tree should be discouraged. The best thing to use is current ToT U-Boot mainline or the v2012.10 stable U-Boot release. X-Loader is deprecated by U-Boot SPL. -Matt -- 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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
On Fri, Oct 19, 2012 at 7:07 PM, Tony Lindgren t...@atomide.com wrote:
...
We could optimize away a minimal amount of code for many configurations
with the ifdef? :)
Sure, here goes (compile tested only):
From 6b82365da2c04986e647d06c285197efece7cb34 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@wizery.com
Date: Sun, 14 Oct 2012 20:16:01 +0200
Subject: [PATCH] ARM: OMAP: don't print any error when wl12xx isn't
configured
Stop intimidating users with scary wlan error messages in case wl12xx
support wasn't even built.
In addition, when wl12xx_set_platform_data() fails, don't bother
registering wl12xx's fixed regulator device (on the relevant
boards).
While we're at it, extract the wlan init code to a dedicated function to
make (the relevant boards') init code look a bit nicer.
Compile tested only.
Reported-by: Russell King li...@arm.linux.org.uk
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-davinci/board-da850-evm.c | 8 ++-
arch/arm/mach-omap2/board-4430sdp.c | 7 +++---
arch/arm/mach-omap2/board-omap3evm.c | 6 ++---
arch/arm/mach-omap2/board-omap3pandora.c | 9 +++-
arch/arm/mach-omap2/board-omap4panda.c | 20 -
arch/arm/mach-omap2/board-zoom-peripherals.c | 15 -
arch/arm/mach-omap2/common-board-devices.c | 33
arch/arm/mach-omap2/common-board-devices.h | 2 ++
8 files changed, 71 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 32ee3f8..7243c22 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1401,13 +1401,9 @@ static __init int da850_wl12xx_init(void)
goto free_wlan_en;
}
- da850_wl12xx_wlan_data.irq = gpio_to_irq(DA850_WLAN_IRQ);
-
- ret = wl12xx_set_platform_data(da850_wl12xx_wlan_data);
- if (ret) {
- pr_err(Could not set wl12xx data: %d\n, ret);
+ ret = wl12xx_board_init(da850_wl12xx_wlan_data, DA850_WLAN_IRQ);
+ if (ret)
goto free_wlan_irq;
- }
return 0;
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 3669c12..bc48679 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -825,10 +825,11 @@ static void __init omap4_sdp4430_wifi_init(void)
int ret;
omap4_sdp4430_wifi_mux_init();
- omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
- ret = wl12xx_set_platform_data(omap4_sdp4430_wlan_data);
+
+ ret = wl12xx_board_init(omap4_sdp4430_wlan_data, GPIO_WIFI_IRQ);
if (ret)
- pr_err(Error setting wl12xx data: %d\n, ret);
+ return;
+
ret = platform_device_register(omap_vwlan_device);
if (ret)
pr_err(Error registering wl12xx device: %d\n, ret);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index b9b776b..8e3a075 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -636,10 +636,10 @@ static void __init omap3_evm_wl12xx_init(void)
int ret;
/* WL12xx WLAN Init */
- omap3evm_wlan_data.irq = gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO);
- ret = wl12xx_set_platform_data(omap3evm_wlan_data);
+ ret = wl12xx_board_init(omap3evm_wlan_data, OMAP3EVM_WLAN_IRQ_GPIO);
if (ret)
- pr_err(error setting wl12xx data: %d\n, ret);
+ return;
+
ret = platform_device_register(omap3evm_wlan_regulator);
if (ret)
pr_err(error registering wl12xx device: %d\n, ret);
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 00a1f4a..bfdc7aa 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -543,13 +543,10 @@ static void __init pandora_wl1251_init(void)
if (ret 0)
goto fail;
- pandora_wl1251_pdata.irq = gpio_to_irq(PANDORA_WIFI_IRQ_GPIO);
- if (pandora_wl1251_pdata.irq 0)
- goto fail_irq;
-
pandora_wl1251_pdata.use_eeprom = true;
- ret = wl12xx_set_platform_data(pandora_wl1251_pdata);
- if (ret 0)
+
+ ret = wl12xx_board_init(pandora_wl1251_pdata, PANDORA_WIFI_IRQ_GPIO);
+ if (ret)
goto fail_irq;
return;
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..f203cd9 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -486,24 +486,32 @@ static void omap4_panda_init_rev(void)
}
}
+static void __init omap4_panda_wlan_init(void)
+{
+ int ret;
+
+ ret = wl12xx_board_init(omap_panda_wlan_data, GPIO_WIFI_IRQ);
+ if (ret)
+ return;
+
+ ret =
Re: OMAP baseline test results for v3.7-rc1
On Sun, 21 Oct 2012, Richard Cochran wrote: On Sun, Oct 21, 2012 at 08:23:35AM +, Paul Walmsley wrote: On Sun, 21 Oct 2012, Richard Cochran wrote: When I read your report, it gave me a much rosier picture than is actually the case WRT the beaglebone. Really? What section of the message provided that to you? It was the part that said, Passing tests - Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone It sounded to me like you were saying that the current kernel release boots just fine on the beaglebone, with no issues. Which it does here, on the configuration described earlier: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/am335xbone/am335xbone_log.txt - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Sun, 21 Oct 2012, Matt Porter wrote: On Sat, Oct 20, 2012 at 06:58:10PM +, Paul Walmsley wrote: TI also has a u-boot tree for the AM33xx; might be worth trying: git://arago-project.org/git/projects/u-boot-am33x.git Use of the vendor tree should be discouraged. That's good. Maybe someone can drop a comment to that effect into the top of the arago u-boot README? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc2
On Sat, 20 Oct 2012, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/ ... Failing tests: needing investigation PM tests: * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works Just confirmed that this longstanding bug affects both MMC root and NFS root. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP2+: first set of PRM/CM cleanups for 3.8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
tags/omap-cleanup-a-for-3.8
for you to fetch changes up to 2bb2a5d30abb0dc99d074877bfad2056142c730b:
ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver
(2012-10-21 01:01:13 -0600)
-
The first set of OMAP PRM/CM-related cleanup patches for 3.8.
Prepares for the future move of the PRM/CM code to drivers/. Also
includes some prcm.[ch] cleanup patches from the WDTIMER cleanup
series that don't need external acks.
Basic test logs for this branch on top of v3.7-rc2 are here:
http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121021123719/
But due to the number of unrelated regressions present in v3.7-rc[12],
it's not particularly usable as a testing base. With reverts, fixes,
and workarounds applied as documented in:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/README.txt
the following test logs were obtained:
http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121020231757/
which indicate that the series tests cleanly.
-
vmlinux object size
(delta in bytes from test_v3.7-rc2 (6f0c0580b70c89094b3422ba81118c7b959c7556)):
text data bsstotal kernel
+11200 +112 am33xx_only
-1740 -1040-1844 n800_multi_omap2xxx
-1648 -800-1728 n800_only_a
+8000 +80 omap1_defconfig
+3200 +32 omap1_defconfig_1510innovator_only
+8000 +80 omap1_defconfig_5912osk_only
+912 +640 +976 omap2plus_defconfig
-1836 -1120-1948 omap2plus_defconfig_2430sdp_only
+912 +1360+1048 omap2plus_defconfig_cpupm
+896 +640 +960 omap2plus_defconfig_no_pm
-6004 -80 +64-6020 omap2plus_defconfig_omap2_4_only
-428 -560 -484 omap2plus_defconfig_omap3_4_only
-888 -1360-1024 rmk_omap3430_ldp_oldconfig
+200 +560 +256 rmk_omap4430_sdp_oldconfig
Boot-time memory difference
(delta in bytes from test_v3.7-rc2 (6f0c0580b70c89094b3422ba81118c7b959c7556))
avail rsrvd high freed board kconfig
8k-8k . . 2420n800 omap2plus_defconfig
-8k 8k . . am335xbone omap2plus_defconfig
Paul Walmsley (9):
ARM: OMAP2+: PRM: remove PRM weak functions
ARM: OMAP2+: PRM: split PRM functions into OMAP2, OMAP3-specific files
ARM: OMAP2+: powerdomain/PRM: move the low-level powerdomain functions
into PRM
ARM: OMAP2+: CM/hwmod: split CM functions into OMAP2, OMAP3-specific files
ARM: OMAP2/3: clockdomain/PRM/CM: move the low-level clockdomain
functions into PRM/CM
ARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers
ARM: OMAP2+: CM: prepare for use of cm_ll_data function pointers
ARM: OMAP1: create read_reset_sources() function (for initial use by
watchdog)
ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer
driver
arch/arm/mach-omap1/common.h|2 +
arch/arm/mach-omap1/reset.c | 38 +++
arch/arm/mach-omap2/Makefile| 110 ---
arch/arm/mach-omap2/clkt2xxx_apll.c |2 +-
arch/arm/mach-omap2/clkt2xxx_dpll.c |2 +-
arch/arm/mach-omap2/clock.c |3 +-
arch/arm/mach-omap2/clock2420_data.c|2 +-
arch/arm/mach-omap2/clock2430.c |2 +-
arch/arm/mach-omap2/clock2430_data.c|2 +-
arch/arm/mach-omap2/clock34xx.c |2 +-
arch/arm/mach-omap2/clock3517.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c|2 +-
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 339 ---
arch/arm/mach-omap2/clockdomain33xx.c | 74 -
arch/arm/mach-omap2/clockdomain44xx.c | 151 -
arch/arm/mach-omap2/cm.h| 12 +
arch/arm/mach-omap2/cm2xxx.c| 255 ++
arch/arm/mach-omap2/cm2xxx.h| 66
arch/arm/mach-omap2/cm2xxx_3xxx.h | 119 +++
arch/arm/mach-omap2/cm33xx.c| 56
arch/arm/mach-omap2/{cm2xxx_3xxx.c = cm3xxx.c} | 307 +
arch/arm/mach-omap2/cm3xxx.h| 86 +
arch/arm/mach-omap2/cm_common.c | 71
arch/arm/mach-omap2/cminst44xx.c| 142 +++-
arch/arm/mach-omap2/control.c |4 +-
Re: [PATCH 2/3] RTC: omap-rtc: enable pm_runtime
On 19.10.2012 12:58, Mohammed, Afzal wrote: Hi Daniel, On Thu, Oct 18, 2012 at 22:03:13, Hiremath, Vaibhav wrote: On Thu, Oct 18, 2012 at 21:49:44, Daniel Mack wrote: On 18.10.2012 18:12, Vaibhav Hiremath wrote: It would be really helpful if you could test these patches and ack them. Ok, will do tomorrow. What's missing there is support for writing to the OMAP_RTC_OSC_REG (path 3/3 in my series). Would like me to rebase the functionality? I need thatkind of setup for my board ... This is bit tricky and required more discussion before merging it, let me reopen the old discussion which I had started some time back - RTC OSC clock is required to configure clocksource systemtimer for the kernel, and it is important when you get into PM related features. Please refer the below commit for more reference, http://marc.info/?l=u-bootm=135057734713796w=2 Newer version (v4) of omap rtc patches for am335x has been posted, rtc: omap dt support (for am33xx). In case you can test, please do it over the new series. You would need also need DT patch that adds DT node to test (it has been separated from the series as it is felt that it should not be part of same series), arm/dts: am33xx rtc node Agreed. I tested your patches and they do basically the same thing than mine. You can take my Tested-by: Daniel Mack zon...@gmail.com on all patches in this series except for 2/5 which I didn't test as I don't have any Davinci platform. If you are using mainline uboot, you would need the fix as mentioned by Vaibhav H (as in the link he provided above), expecting it to reach uboot mainline soon. If the above is being attempted to achieve in Kernel it would cause 2-3 seconds delay in boot time (else it had to be made a module), please refer link provided by Vaibhav H for more details. else you can do in current mainline uboot, mw.l 0x44e3e06c 0x83e70b13 mw.l 0x44e3e070 0x95a4f1e0 mw.b 0x44e3e054 0x48 and then boot kernel. I'm surprised that survives the kernel boot, but I'll give it a try. In case you want to add that logic to the kernel as well, please copy me in the discussion :) Thanks, Daniel -- 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
booting pandaboard with dtb
Hi, Tell me please, which u-boot and u-boot configuration to use to boot latest kernel with omap4-panda.dtb ? Thanks -- Constantine Shulyupin http://www.MakeLinux.com/ Embedded Linux Systems, Device Drivers, TI DaVinci -- 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
booting pandaboard with dtb
Hi, Tell me please, which u-boot and u-boot configuration to use to boot latest kernel with omap4-panda.dtb ? Thanks -- Constantine Shulyupin http://www.MakeLinux.com/ Embedded Linux Systems, Device Drivers, TI DaVinci -- 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: booting pandaboard with dtb
Hi, On Monday 22 October 2012 03:58 AM, Constantine Shulyupin wrote: Hi, Tell me please, which u-boot and u-boot configuration to use to boot latest kernel with omap4-panda.dtb ? denx u-boot (git://git.denx.de/u-boot.git) should do. Do you face any issues? Thanks Kishon -- 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 0/9] OMAPDSS: minor fixes cleanups
On Wednesday 17 October 2012 04:50 PM, Tomi Valkeinen wrote:
Hi,
This series contains minor cleanups and fixes for omapdss.
This series looks fine to me. I have a related cleanup patch which you
may consider adding to the series.
Thanks,
Archit
From: Archit Taneja arc...@ti.com
Date: Thu, 18 Oct 2012 16:51:57 +0530
Subject: [PATCH] OMAPDSS: Remove acb and acbi fields from omap_dss_device
acbi and acb fields were meant for passive matrix panels which omapdss
doesn't
support any longer. Remove these fields from omap_dss_device struct.
Signed-off-by: Archit Taneja arc...@ti.com
---
include/video/omapdss.h |4
1 file changed, 4 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 88c8294..f39e6aa 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -621,10 +621,6 @@ struct omap_dss_device {
struct {
struct omap_video_timings timings;
- int acbi; /* ac-bias pin transitions per interrupt */
- /* Unit: line clocks */
- int acb;/* ac-bias pin frequency */
-
enum omap_dss_dsi_pixel_format dsi_pix_fmt;
enum omap_dss_dsi_mode dsi_mode;
struct omap_dss_dsi_videomode_timings dsi_vm_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
RE: [RFC PATCH v3 00/16] DMA Engine support for AM33XX
On Fri, Oct 19, 2012 at 22:16:15, Porter, Matt wrote:
On Fri, Oct 19, 2012 at 12:02:42PM +, Bedia, Vaibhav wrote:
On Fri, Oct 19, 2012 at 16:45:58, Porter, Matt wrote:
On Fri, Oct 19, 2012 at 10:26:20AM +, Bedia, Vaibhav wrote:
[...]
I didn't see all the patches that you posted on edma-dmaengine-v3
but I do seem them on edma-dmaengine-am33xx-v3 branch.
I see I referenced the wrong branch in the cover letter. Thanks for
testing and noticing this. Sorry to make you hunt for the correct
branch in that repo. ;)
No problem.
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3
is indeed the correct branch for those wanting to pull this in or
grab some of the not-to-be-merged drivers I used for testing.
I added a couple of patches to enable earlyprintk and build the DTB
appended kernel image uImage-dtb.am335x-evm
Here's what i see
[...]
snip
[0.175354] edma: probe of 4900.edma failed with error -16
I missed an uninitialized pdata case in the bug fixes mentioned in
the changelog and the folks previously failing the same way didn't
hit the case I suspect you are hitting. Can you try this and let me
know how it works?
That doesn't help :(
Ok, so I dumped my Linaro toolchain which was masking this issue that
you got unlucky with on EVM, whereas I was lucky. Switching toolchains I
was able to reproduce the problem. Pantelis Antoniou suggested some
changes and the following fixes this issue for me...verified on both
BeagleBone and EVM. Let me know if that works on your end and I'll
incorporate some version of it in the next update.
Heh I would not have suspected the toolchain so early ;)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index b761b7a..6ed394f 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1598,6 +1598,8 @@ static struct of_dma_filter_info edma_filter_info = {
static int __init edma_probe(struct platform_device *pdev)
{
struct edma_soc_info**info = pdev-dev.platform_data;
+ struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL, NULL};
+ struct edma_soc_infotmpinfo;
s8 (*queue_priority_mapping)[2];
s8 (*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
@@ -1614,15 +1616,13 @@ static int __init edma_probe(struct platform_device
*pdev)
charirq_name[10];
struct device_node *node = pdev-dev.of_node;
struct device *dev = pdev-dev;
- struct edma_soc_info*pdata;
int ret;
if (node) {
- pdata = devm_kzalloc(dev,
- sizeof(struct edma_soc_info),
- GFP_KERNEL);
- edma_of_parse_dt(dev, node, pdata);
- info = pdata;
+ info = ninfo;
+ edma_of_parse_dt(dev, node, tmpinfo);
+ info[0] = tmpinfo;
+
dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
of_dma_controller_register(dev-of_node,
of_dma_simple_xlate,
With the above diff, the kernel boots fine on the EVM.
Looking at the original crash log, I suspect something is not correct
with the irq portion, probably in the DT or the driver.
genirq: Flags mismatch irq 28. (edma) vs. (edma)
The warning below that is coming due to fail case in edma_probe not tracking
the request_irq status properly and but IMO that's a separate issue.
It is a separate issue, indeed. My ideal goal was to avoid changing
anything in this existing davinci dma implementation, that's why the
error paths were unmodified. Since I'm having to rework a few more things
I'll look at those and generate an improved version.
Russ Dill also made some good simplification/cleanup suggestions for the
of parsing on irc which I'll incorporate in the next version.
Ok, sounds good.
Regards,
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 3/5] ARM: OMAP2+: powerdomain/PRM: move the low-level powerdomain functions into PRM
On Sat, Oct 20, 2012 at 23:20:18, Paul Walmsley wrote:
Hi Rajendra, Russ, Santosh,
thanks for your Reviewed-bys and acks and comments. Have folded them into
the series here. Russ, the file headers have been updated per your
comments. Also while there, the copyrights from the
{clock,power}domain.c files were copied in, along with Rajendra's
authorship line.
Sorry for delayed response,
I have just tested it on Beaglebone platform without any issues. I tested
your branch
prm_cm_split_cleanup_3.8 + gpmc patch from Jon (already in linus/master).
So to this compete patch-series,
Reviewed-Acked-Tested-By: Vaibhav Hiremath hvaib...@ti.com
Thanks,
Vaibhav
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
