[PATCH] ARM: OMAP2+: timer: initialize before using oh_name
of_property_read_string_index(...,oh_name) in omap_dm_timer_init_one
does not alter the value of 'oh_name' even if the relevant function
fails and as 'oh_name' in stack may have a non-zero value, it would
be misunderstood by timer code that DT has specified ti,hwmod
property for timer. 'oh_name' in this scenario would be a junk value,
this would result in module not being enabled by hwmod API's for
timer, and in turn crash.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f8b23b8..8e0c390 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -220,7 +220,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
int posted)
{
char name[10]; /* 10 = sizeof(gptXX_Xck0) */
- const char *oh_name;
+ const char *oh_name = NULL;
struct device_node *np;
struct omap_hwmod *oh;
struct resource irq, mem;
--
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 v6 0/9] Generic PHY Framework
Hi, On Tuesday 21 May 2013 10:31 AM, Kishon Vijay Abraham I wrote: Hi, On Monday 29 April 2013 03:33 PM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on linux-next tree. Any comments on this patch series? Ping.. This series is needed for usb3 phy/sata phy and can also be used by certain video phys. I think it's important to get this in. 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
[PATCH v2] usb: musb: fix clock naming
From: Yegor Yefremov yegorsli...@googlemail.com
'ick' was changed to 'hsotgusb_ick'
'fck' was changed to 'hsotgusb_fck'
Signed-off-by: Jan Luebbe j...@pengutronix.de
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
v2: CC linux-usb mailing list
drivers/usb/musb/am35x.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 2231850..92b5b23 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -477,14 +477,14 @@ static int am35x_probe(struct platform_device *pdev)
goto err1;
}
- phy_clk = clk_get(pdev-dev, fck);
+ phy_clk = clk_get(pdev-dev, hsotgusb_ick);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
ret = PTR_ERR(phy_clk);
goto err3;
}
- clk = clk_get(pdev-dev, ick);
+ clk = clk_get(pdev-dev, hsotgusb_fck);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clock\n);
ret = PTR_ERR(clk);
--
1.7.7
--
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] OMAP: AES: Don't idle/start AES device between Encrypt operations
On Tue, May 14, 2013 at 03:07:47AM +, Joel A Fernandes wrote: Calling runtime PM API for every block causes serious perf hit to crypto operations that are done on a long buffer. As crypto is performed on a page boundary, encrypting large buffers can cause a series of crypto operations divided by page. The runtime PM API is also called those many times. We call runtime_pm_get_sync only at beginning on the session (cra_init) and runtime_pm_put at the end. This result in upto a 50% speedup as below. This doesn't make the driver to keep the system awake as runtime get/put is only called during a crypto session which completes usually quickly. Before: root@beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s After: root@beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s While at it, also drop enter and exit pr_debugs, in related code. tracers can be used for that. Tested on a Beaglebone (AM335x SoC) board. Signed-off-by: Joel A Fernandes joelag...@ti.com I like your patch but it doesn't apply against the current cryptodev tree. Please rebase and repost. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
OMAP DSS: How to skip FB initialization?
Hi, I've initialized the OMAP3 DDS framebuffer subsystem in u-boot to show a splash screen on LCD. Is there an option in the kernel implementation to avoid the reinitializing of the DSS framebuffer subsystem? Thanks for help, Sven -- 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] dts: am33xx: Correct properties on gpmc node
From: Lars Poeschel poesc...@lemonage.de The gpmc driver is actually looking for gpmc,num-cs and gpmc,num-waitpins properties in DT. The binding doc also states this. Correct the properties in the dts to provide the right values for the gpmc driver. Signed-off-by: Lars Poeschel poesc...@lemonage.de --- arch/arm/boot/dts/am33xx.dtsi |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 1460d9b..8e1248f 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -409,8 +409,8 @@ ti,hwmods = gpmc; reg = 0x5000 0x2000; interrupts = 100; - num-cs = 7; - num-waitpins = 2; + gpmc,num-cs = 7; + gpmc,num-waitpins = 2; #address-cells = 2; #size-cells = 1; status = disabled; -- 1.7.10.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 v3 0/5] ARM: dts: OMAP2+: use preprocessor for device trees
On 05/27/2013 04:52 PM, Florian Vaussard wrote: Hello, Following a similar proposal by Stephen Warren for tegra [1], this series makes use of the C preprocessor when compiling OMAP DT files, and accomplishes some improvements to improve overall readability. I realized that I should also address am* devices. I will wait for comments on this version, then post a v4. Sorry for the noise. Regards, Florian -- 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] dts: am33xx: Correct properties on gpmc node
Lars == Lars Poeschel la...@wh2.tu-dresden.de writes: Lars From: Lars Poeschel poesc...@lemonage.de Lars The gpmc driver is actually looking for gpmc,num-cs and Lars gpmc,num-waitpins properties in DT. The binding doc also states Lars this. Lars Correct the properties in the dts to provide the right values for the Lars gpmc driver. Lars Signed-off-by: Lars Poeschel poesc...@lemonage.de Acked-by: Peter Korsgaard jac...@sunsite.dk -- Bye, Peter Korsgaard -- 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 v4,3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
From: Philip Avinash avinashphi...@ti.com
NAND flash connected in am335x-evm on GPMC controller. This patch adds
device tree node in am3355-evm with GPMC contoller timing for NAND flash
interface, NAND partition table, ECC scheme, elm handle id.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Gupta, Pekon pe...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 105 +++
1 file changed, 105 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0423298..7d2be9c 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -44,6 +44,26 @@
0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
;
};
+
+ nandflash_pins_s0: nandflash_pins_s0 {
+ pinctrl-single,pins =
+ 0x0 0x30/* gpmc_ad0.gpmc_ad0, INPUT |
PULLUP | MODE0 */
+ 0x4 0x30/* gpmc_ad1.gpmc_ad1, INPUT |
PULLUP | MODE0 */
+ 0x8 0x30/* gpmc_ad2.gpmc_ad2, INPUT |
PULLUP | MODE0 */
+ 0xc 0x30/* gpmc_ad3.gpmc_ad3, INPUT |
PULLUP | MODE0 */
+ 0x10 0x30 /* gpmc_ad4.gpmc_ad4, INPUT |
PULLUP | MODE0 */
+ 0x14 0x30 /* gpmc_ad5.gpmc_ad5, INPUT |
PULLUP | MODE0 */
+ 0x18 0x30 /* gpmc_ad6.gpmc_ad6, INPUT |
PULLUP | MODE0 */
+ 0x1c 0x30 /* gpmc_ad7.gpmc_ad7, INPUT |
PULLUP | MODE0 */
+ 0x70 0x30 /* gpmc_wait0.gpmc_wait0, INPUT
| PULLUP | MODE0 */
+ 0x74 0x37 /* gpmc_wpn.gpio0_30, INPUT |
PULLUP | MODE7 */
+ 0x7c 0x8/* gpmc_csn0.gpmc_csn0, PULL
DISA */
+ 0x90 0x8/* gpmc_advn_ale.gpmc_advn_ale,
PULL DISA */
+ 0x94 0x8/* gpmc_oen_ren.gpmc_oen_ren,
PULL DISA */
+ 0x98 0x8/* gpmc_wen.gpmc_wen, PULL DISA
*/
+ 0x9c 0x8/* gpmc_be0n_cle.gpmc_be0n_cle,
PULL DISA */
+ ;
+ };
};
ocp {
@@ -102,6 +122,91 @@
reg = 0x48;
};
};
+
+ elm: elm@4808 {
+ status = okay;
+ };
+
+ gpmc: gpmc@5000 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nandflash_pins_s0;
+ ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ nand-bus-width = 8;
+ ti,nand-ecc-opt = bch8;
+ gpmc,device-nand = true;
+ gpmc,device-width = 1;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 44;
+ gpmc,cs-wr-off-ns = 44;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 34;
+ gpmc,adv-wr-off-ns = 44;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 40;
+ gpmc,oe-on-ns = 0;
+ gpmc,oe-off-ns = 54;
+ gpmc,access-ns = 64;
+ gpmc,rd-cycle-ns = 82;
+ gpmc,wr-cycle-ns = 82;
+ gpmc,wait-on-read = true;
+ gpmc,wait-on-write = true;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,clk-activation-ns = 0;
+ gpmc,wait-monitoring-ns = 0;
+ gpmc,wr-access-ns = 40;
+ gpmc,wr-data-mux-bus-ns = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+ elm_id = elm;
+
+ /* MTD partition table */
+ partition@0 {
+ label = SPL1;
+ reg = 0x 0x2;
+ };
+
+ partition@1 {
+ label = SPL2;
+ reg = 0x0002
[PATCH v4,0/3] DT support for NAND on OMAP2
From: Gupta, Pekon pe...@ti.com Changes v3-v4 - rebased to linux-3.10-rc3 - updated newly supported DT properties based on following commits [d36b4cd] jon-hun...@ti.com ARM: OMAP2+: Add additional GPMC timing ... [8c8a777] jon-hun...@ti.com ARM: OMAP2+: Add function to read GPMC ... [9f83315] jon-hun...@ti.com ARM: OMAP2+: Add variable to store number Changes v2-v3 - rebased to linux-3.9-rc8 - AM335x-evm.dts: moved GPMC pin-mux config to nand node Changes v1-v2 - Change number of chip select to 7 - Replace xx literals to 52 - remove tab Gupta, Pekon (1): ARM: dts: AM33XX: update GPMC node Philip Avinash (1): ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm Philip, Avinash (1): ARM: dts: AM33XX: Add ELM node arch/arm/boot/dts/am335x-evm.dts | 105 +++ arch/arm/boot/dts/am33xx.dtsi| 10 +++- 2 files changed, 114 insertions(+), 1 deletion(-) -- 1.8.1 -- 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 v4,1/3] ARM: dts: AM33XX: Add ELM node
From: Philip, Avinash avinashphi...@ti.com
Add ELM data node to AM33XX device tree file.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Acked-by: Peter Korsgaard jac...@sunsite.dk
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1460d9b..0425af8 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -404,6 +404,14 @@
ti,hwmods = wkup_m3;
};
+ elm: elm@4808 {
+ compatible = ti,am3352-elm;
+ reg = 0x4808 0x2000;
+ interrupts = 4;
+ ti,hwmods = elm;
+ status = disabled;
+ };
+
gpmc: gpmc@5000 {
compatible = ti,am3352-gpmc;
ti,hwmods = gpmc;
--
1.8.1
--
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 v4,2/3] ARM: dts: AM33XX: update GPMC node
From: Gupta, Pekon pe...@ti.com add prefix to 'gpmc' specific properties Signed-off-by: Gupta, Pekon pe...@ti.com --- arch/arm/boot/dts/am33xx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 0425af8..095f696 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -418,7 +418,7 @@ reg = 0x5000 0x2000; interrupts = 100; num-cs = 7; - num-waitpins = 2; + gpmc,num-waitpins = 2; #address-cells = 2; #size-cells = 1; status = disabled; -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: fix IVA2 module base address
This patch corrects the base address of IVA2 module on omap3430. Signed-off-by: Aida Mynzhasova aida.mynzhas...@skitlab.ru --- arch/arm/mach-omap2/prcm-common.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index c7d355f..d5ec044 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -37,7 +37,7 @@ #define OMAP2430_MDM_MOD 0xc00 /* IVA2 module is base on 3430 */ -#define OMAP3430_IVA2_MOD -0x800 +#define OMAP3430_IVA2_MOD 0x800 #define OMAP3430ES2_SGX_MODGFX_MOD #define OMAP3430_CCR_MOD PLL_MOD #define OMAP3430_DSS_MOD 0x600 -- 1.7.10.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] usb: omap2430: fix memleak in err case
ping...
On 2013/5/22 11:30, Libo Chen wrote:
when omap_get_control_dev faild, we should release related platform_device
* Changelog from v1:
* fix spell: s/fail/fails/, s/relational/related/ , thank Sergei
sergei.shtyl...@cogentembedded.com
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/usb/musb/omap2430.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 3551f1a..b626f19 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -549,7 +549,8 @@ static int omap2430_probe(struct platform_device *pdev)
glue-control_otghs = omap_get_control_dev();
if (IS_ERR(glue-control_otghs)) {
dev_vdbg(pdev-dev, Failed to get control device\n);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err2;
}
} else {
glue-control_otghs = ERR_PTR(-ENODEV);
--
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: [net-next PATCH v3 1/6] net: cpsw: enhance pinctrl support
On 5/28/2013 3:06 AM, Tony Lindgren wrote:
* Mugunthan V N mugunthan...@ti.com [130526 11:28]:
From: Hebbar Gururaja gururaja.heb...@ti.com
Amend cpsw controller to optionally take a pin control handle and set
the state of the pins to:
- default on boot, resume
- sleep on suspend()
This should make it possible to optimize energy usage for the pins
for the suspend/resume cycle.
If any of the above pin states are missing in dt, a warning message
about the missing state is displayed.
If certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 48
1 file changed, 48 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 21a5b29..c9ed730 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -35,6 +35,7 @@
#include linux/if_vlan.h
#include linux/platform_data/cpsw.h
+#include linux/pinctrl/consumer.h
#include cpsw_ale.h
#include cpts.h
@@ -351,6 +352,11 @@ struct cpsw_priv {
bool irq_enabled;
struct cpts *cpts;
u32 emac_port;
+
+ /* Two optional pin states - default sleep */
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*pins_def;
+ struct pinctrl_state*pins_sleep;
};
Which pins do you need to dynamically remux? If it's not all
the pins, you should have three sets: default, active and idle.
This way the static pins in the default group don't need to be
constantly toggled.
Regards,
Tony
Tony
I am using this for all the pins, in probe all the cpsw pins will be
configured
and i have used the same in suspend/resume callback for power saving.
Regards
Mugunthan V N
--
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] ARM: OMAP: fix IVA2 module base address
Aida Mynzhasova aida.mynzhas...@skitlab.ru writes: This patch corrects the base address of IVA2 module on omap3430. Signed-off-by: Aida Mynzhasova aida.mynzhas...@skitlab.ru I know it looks a bit weird to have a negative offset like this, but it's actually correct. These offsets are used relative to prm_base (on 34xx, it's OMAP3430_PRM_BASE defined in omap34xx.h). So I suggest you double check the values there, and cross reference to the PRCM Register Manual section of the TRM (last section of the PRCM chapter.) Thanks, Kevin --- arch/arm/mach-omap2/prcm-common.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index c7d355f..d5ec044 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -37,7 +37,7 @@ #define OMAP2430_MDM_MOD 0xc00 /* IVA2 module is base on 3430 */ -#define OMAP3430_IVA2_MOD-0x800 +#define OMAP3430_IVA2_MOD0x800 #define OMAP3430ES2_SGX_MOD GFX_MOD #define OMAP3430_CCR_MOD PLL_MOD #define OMAP3430_DSS_MOD 0x600 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] ARM: dts: OMAP2+: use preprocessor for device trees
On 05/23/2013 09:36 AM, Florian Vaussard wrote: Hello, Following a similar proposal by Stephen Warren for tegra [1], this series makes use of the C preprocessor when compiling OMAP DT files, and accomplishes some improvements to improve overall readability. Patch 1 is a preparation for the rest of the series. Patch 2 uses existing constants for GPIOs. Patch 3 does the same for IRQs. Patch 4 creates a new header for OMAP's padmux, and patch 5 uses it to simplify pinctrl DT. For all targets, the .dtb files were diff-tested before and after applying the series to guarantee identity. The series briefly, Reviewed-by: Stephen Warren swar...@nvidia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] ARM: dts: OMAP2+: use preprocessor for device trees
On 05/28/2013 05:07 PM, Stephen Warren wrote: On 05/23/2013 09:36 AM, Florian Vaussard wrote: Hello, Following a similar proposal by Stephen Warren for tegra [1], this series makes use of the C preprocessor when compiling OMAP DT files, and accomplishes some improvements to improve overall readability. Patch 1 is a preparation for the rest of the series. Patch 2 uses existing constants for GPIOs. Patch 3 does the same for IRQs. Patch 4 creates a new header for OMAP's padmux, and patch 5 uses it to simplify pinctrl DT. For all targets, the .dtb files were diff-tested before and after applying the series to guarantee identity. The series briefly, Reviewed-by: Stephen Warren swar...@nvidia.com Thank you. FYI, I posted a v3 addressing Tony's comments [1]. Regards, Florian [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/98320 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap2: fix AM33xx hwmod infos for UART2
The UART2 hwmod structure is pointing to the EDMA channels of UART1,
which doesn't look right. This patch fixes this by making the UART2
hwmod structure to a new structure that lists the EDMA channels to be
used by the UART2.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 01d8f32..9113251 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2006,6 +2006,13 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
},
};
+/* uart2 */
+static struct omap_hwmod_dma_info uart2_edma_reqs[] = {
+ { .name = tx, .dma_req = 28, },
+ { .name = rx, .dma_req = 29, },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_irq_info am33xx_uart2_irqs[] = {
{ .irq = 73 + OMAP_INTC_START, },
{ .irq = -1 },
@@ -2016,7 +2023,7 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
.class = uart_class,
.clkdm_name = l4ls_clkdm,
.mpu_irqs = am33xx_uart2_irqs,
- .sdma_reqs = uart1_edma_reqs,
+ .sdma_reqs = uart2_edma_reqs,
.main_clk = dpll_per_m2_div4_ck,
.prcm = {
.omap4 = {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: omap2430: fix memleak in err case
No go. Check the 4b7e450fb5cefb5865c77999a675330206ab3b8a And update you tree, please. -- With Best Regards, Andy Shevchenko -- 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/3] usb: dwc3: omap Modify dwc3_omap_readl/writel with offsets
Hi,
On Mon, May 27, 2013 at 01:32:57PM +0530, George Cherian wrote:
This patch modifies dwc3_omap_readl/writel calls to accomodate
both OMAP5 and AM437x reg maps (It uses the cached register offsets).
Also renames OMAP5 IRQ1 as IRQMISC, IRQ1 bits as IRQMISC bits.
Signed-off-by: George Cherian george.cher...@ti.com
can you change this patch a bit so that it adds wrappers around
dwc3_omap_*() ? The idea is the have the code look like:
static u32 dwc3_omap_read_utmi_status(struct dwc3_omap *omap)
{
return dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS +
omap-utmi_otg_offset);
}
(likewise for write and for all other offsets, of course)
that way, reading/writing to registers which need the offset will be
less error-prone and th driver will look a little nicer.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/3] palmas usb driver
On Fri, May 24, 2013 at 08:01:33PM +0530, Kishon Vijay Abraham I wrote: This patch series adds driver for palmas usb which is used to detect attach/detach events of usb device and usb host. [PATCH v5 2/3] extcon: Palmas Extcon Driver which was sent previously is added in this patch series itself. The revision history is added in the patch comments section. A checkpatch warning WARNING: static const char * array should probably be static const char * constis ignored since it introduces a compilation warning. Graeme Gregory (2): drivers: regulator: palmas: add an API to set/clear the switch bit on SMPS10 extcon: Palmas Extcon Driver Kishon Vijay Abraham I (1): usb: dwc3: use extcon fwrk to receive connect/disconnect notification There were some comments to this series, what will happen with it ? Any new versions coming ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: musb: fix clock naming
On Tue, May 28, 2013 at 09:21:01AM +0200, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com 'ick' was changed to 'hsotgusb_ick' 'fck' was changed to 'hsotgusb_fck' Signed-off-by: Jan Luebbe j...@pengutronix.de Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com NAK. Fix your clock data. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: omap2430: fix memleak in err case
Hello. On 22-05-2013 7:30, Libo Chen wrote: when omap_get_control_dev faild, we should release related platform_device * Changelog from v1: * fix spell: s/fail/fails/, s/relational/related/ , thank Sergei sergei.shtyl...@cogentembedded.com It seems you've actually replaced fail with faild, not fails. Signed-off-by: Libo Chen libo.c...@huawei.com --- drivers/usb/musb/omap2430.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) WBR, Sergei -- 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] arm: configs: omap2plus_defconfig: enable USB bits which work
Roger Quadros rog...@ti.com writes: On 05/14/2013 05:09 PM, Kevin Hilman wrote: [...] @@ -206,10 +207,18 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=y +CONFIG_USB_EHCI_HCD=y NAK (on this particular change) This cannot be enable by default yet as EHCI *still* breaks core retention[1] (which has been broken since at least v3.5, almost a year now.) True. Due to broken smart idle/wakeup, EHCI host has to rely on IO Daisy chaining mechanism for remote wakeup. So this can't be fixed till we have daisy chaining working with device tree boot. ... and is anyone working on that? 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] ARM: DTS: OMAP4: Panda/SDP: twl6030: fix mux for IRQ pin and msecure line
Nishanth Menon n...@ti.com writes: On Fri, May 24, 2013 at 5:15 PM, Kevin Hilman khil...@linaro.org wrote: Kevin Hilman khil...@linaro.org writes: Nishanth Menon n...@ti.com writes: [...] Actually 2 things: a) patch seems to do the wrong thing for 4460 - 0x18 offset should have been used instead of 0x14 which is correct for 4430? I see, thanks. I'll double check the TRMs. b) yes, I understand, the current settings we did worked, but the mode(0) we are setting to is real weird - we are setting it up for clk0 out - I cant even think why it is even working in the first place :( - is it because we are pumping out sysclkout and as a result we are lucky that msecure is being sampled at the right point by twl6030 allowing rtc access? either way, IMHO, the configuration is wrong. Ah, yes. Mode zero is definitely wrong. When I did the original patch for legacy mode, I just duplicated the settings u-boot was using. Guess it's a fluke that it works. Actually, for legacy mode, it's set correctly in mode 2. This line: omap_mux_init_signal(fref_clk0_out.sys_drm_msecure, OMAP_PIN_OUTPUT); does the right thing based on the signal name.But for DT boot, I defintely screwed it up by setting it to mode (and putting it in the wrong padconf section.) Also, are you *really* sure about the offset difference between 4430 and 4460 here? I don't have access to NDA docs anymore, so I cannot double check this. What I do know is that the legacy code is using 0x54 for both, and if I simply comment out that 'sys_drm_msecure' line above, RTC wake stops working (legacy boot) on both 4430 and 4460, so that seems like pretty stront evidence that it's the same offset on both. Schematics are public for PandaBoard ES and PandaBoard - as you can see from that the registers connected are definitely different. What I see from both schematics is that SYS_DRM_MSECURE is available on a few different pads, but on both 4430 and 4460, one of the places is in mode 2 of FREF_CLK0_OUT, which is at offset 0x54 on both SoCs. Based on that reading, and the fact that not correctly muxing that pad to mode 2 on *both* 4430 and 4460 makes the RTC work, I'm rather convinced that the offset should be the same for 4430 and 4460. What am I missing? 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: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression
On 23/05/13 21:13, Aaro Koskinen wrote: On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote: On 22/05/13 22:20, Aaro Koskinen wrote: On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: On 21/05/13 18:39, Aaro Koskinen wrote: On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130516 14:50]: * Aaro Koskinen aaro.koski...@iki.fi [130516 14:05]: On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [130513 13:58]: I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: [2.264221] retu-mfd 2-0001: Retu v3.2 found [2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 [2.300140] retu-mfd: probe of 2-0001 failed with error -12 The error is coming from regmap code. According to git bisect, it is caused by: commit ede4d7a5b9835510fd1f724367f68d2fa4128453 Author: Jon Hunter jon-hun...@ti.com Date: Fri Mar 1 11:22:47 2013 -0600 gpio/omap: convert gpio irq domain to linear mapping The commit does not anymore revert cleanly, and I haven't yet tried crafting a manual revert, so any fix proposals/ideas are welcome... Hmm this might be a bit trickier to fix. Obviously the real solution is to convert omap1 to SPARSE_IRQ like we did for omap2+. For the -rc cycle, it might be possible to fix this by adding a different irq_to_gpio() and gpio_to_irq() functions for omap1. The commit reverts cleanly if we also revert 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt service routine), which seems to be just some minor optimization. The result is below, and with it 770 works again. Hmm in this case it seems that we should just fix it rather than go back to the old code, so let's take a look at that first. Does the following fix it for you or do we need to fix something else there too? Thanks, that fixes Retu probe on 770. Sorry for not responding sooner, but I have been moving. From looking at the code it appears that the regmap_add_irq_chip() is failing in the retu driver. I am not sure if this will work, but have you tried making the following change to the retu driver so that it also uses irq_domain_add_linear() as well? Just a thought ... This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. Sorry, there is another change needed. Can you try ... I will try this. However, I would also like to point out that Retu works fine on N800/N810 (OMAP2). If the problem is in Retu, why only OMAP1 is affected? The problem is not with retu or the gpio driver per-se, its just that now they are conflicting because the way the irq domains are being allocated. So probably just getting lucky on the n8xx. I had tested on omap1-4 and had not seen any problems, but none of my boards used the retu driver. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression
On 26/05/13 20:07, Aaro Koskinen wrote: On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote: On 22/05/13 22:20, Aaro Koskinen wrote: On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: On 21/05/13 18:39, Aaro Koskinen wrote: On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130516 14:50]: * Aaro Koskinen aaro.koski...@iki.fi [130516 14:05]: On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [130513 13:58]: I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: [2.264221] retu-mfd 2-0001: Retu v3.2 found [2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 [2.300140] retu-mfd: probe of 2-0001 failed with error -12 The error is coming from regmap code. According to git bisect, it is caused by: commit ede4d7a5b9835510fd1f724367f68d2fa4128453 Author: Jon Hunter jon-hun...@ti.com Date: Fri Mar 1 11:22:47 2013 -0600 gpio/omap: convert gpio irq domain to linear mapping The commit does not anymore revert cleanly, and I haven't yet tried crafting a manual revert, so any fix proposals/ideas are welcome... Hmm this might be a bit trickier to fix. Obviously the real solution is to convert omap1 to SPARSE_IRQ like we did for omap2+. For the -rc cycle, it might be possible to fix this by adding a different irq_to_gpio() and gpio_to_irq() functions for omap1. The commit reverts cleanly if we also revert 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt service routine), which seems to be just some minor optimization. The result is below, and with it 770 works again. Hmm in this case it seems that we should just fix it rather than go back to the old code, so let's take a look at that first. Does the following fix it for you or do we need to fix something else there too? Thanks, that fixes Retu probe on 770. Sorry for not responding sooner, but I have been moving. From looking at the code it appears that the regmap_add_irq_chip() is failing in the retu driver. I am not sure if this will work, but have you tried making the following change to the retu driver so that it also uses irq_domain_add_linear() as well? Just a thought ... This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. Sorry, there is another change needed. Can you try ... I don't see much improvement with this. Although Retu probe succeeds, genirq error logs are still there. Also none of the GPIO irqs used by other drivers seem to be working at all, e.g. touchscreen. Care to share the log? Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/3] PM / AVS: SmartReflex: disable errgen before vpbound disable
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes: From: Nishanth Menon n...@ti.com vpboundsintr_en is available inside the IP block as an re-sycned version and one which is not. Due to this, there is an 1 sysclk cycle window where interruptz could be asserted low for 1 cycle. ^^^ Is that the way the cool kidz are spelling interrupts these days? ;) IF, intr_en is cleared on the exact same cycle as the irqclr, an additional pulse is generated which indicates for VP that an additional adjustment of voltage is required. This results in VP doing two voltage adjustments for the SRERR (based on configuration, upto 4 steps), instead of the needed 1 step. Due to the unexpected pulse from AVS which breaks the AVS-VP communication protocol, VP also ends up in a stuck condition by entering a state where VP module remains non-responsive to any futher AVS adjustment events. This creates the symptom called TRANXDONE Timeout scenario. By disabling errgen prior to disable of intr_en, this situation can be avoided. Signed-off-by: Vincent Bour v-b...@ti.com Signed-off-by: Leonardo Affortunati l-affortun...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com From Documentation/SubbmittingPatches: If a person was not directly involved in the preparation or handling of a patch but wishes to signify and record their approval of it then they can arrange to have an Acked-by: line added to the patch's changelog. Are all of the tags above co-authors or on the delivery path? I suspect an Acked-by or Reviewed-by is more appropriate here. Otherwise, patch itself looks fine. Kevin --- drivers/power/avs/smartreflex.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c index 6b2238b..f34d34d 100644 --- a/drivers/power/avs/smartreflex.c +++ b/drivers/power/avs/smartreflex.c @@ -449,12 +449,17 @@ int sr_disable_errgen(struct voltagedomain *voltdm) return -EINVAL; } - /* Disable the interrupts of ERROR module */ - sr_modify_reg(sr, errconfig_offs, vpboundint_en | vpboundint_st, 0); - /* Disable the Sensor and errorgen */ sr_modify_reg(sr, SRCONFIG, SRCONFIG_SENENABLE | SRCONFIG_ERRGEN_EN, 0); + /* + * Disable the interrupts of ERROR module + * NOTE: modify is a read, modify,write - an implicit OCP barrier + * which is required is present here - sequencing is critical + * at this point (after errgen is disabled, vpboundint disable) + */ + sr_modify_reg(sr, errconfig_offs, vpboundint_en | vpboundint_st, 0); + return 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] arm: configs: omap2plus_defconfig: enable USB bits which work
Hi, On Tue, May 28, 2013 at 11:18:13AM -0700, Kevin Hilman wrote: Roger Quadros rog...@ti.com writes: On 05/14/2013 05:09 PM, Kevin Hilman wrote: [...] @@ -206,10 +207,18 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=y +CONFIG_USB_EHCI_HCD=y NAK (on this particular change) This cannot be enable by default yet as EHCI *still* breaks core retention[1] (which has been broken since at least v3.5, almost a year now.) True. Due to broken smart idle/wakeup, EHCI host has to rely on IO Daisy chaining mechanism for remote wakeup. So this can't be fixed till we have daisy chaining working with device tree boot. ... and is anyone working on that? Let's ask Tero :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v1 0/3] PM / AVS: SmartReflex: driver misc fixes
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes: The following patch series contain several misc fixes to SmartReflex driver: 1. disable errgen before vpbound disable. Critical fix, needed for proper work of AVS-VP communicaton protocol. 2. disable runtime PM on driver remove. Trivial - runtime PM cleanup. 3. fix driver name. Trivial - proper DRIVER_NAME was not defined since SmartReflex driver was introduced with initial commit. Patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git tag: v3.10-rc2 Verified on OMAP4430. Boot - OK. SmartReflex registers debug dump - OK Available on GitHub: https://github.com/andriit/linux-omap-k3.8/commits/avs_sr_driver_misc_fixes_v01 Andrii Tseglytskyi (2): PM / AVS: SmartReflex: disable runtime PM on driver remove PM / AVS: SmartReflex: fix driver name Nishanth Menon (1): PM / AVS: SmartReflex: disable errgen before vpbound disable drivers/power/avs/smartreflex.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) I had a minor comment on PATCH 1/3, otherwise these look good for v3.11 (since they are not regressions, they don't qualify for v3.10.) Please repost with the changes and be sure to copy linux...@vger.kernel.org Thanks, 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] ARM: OMAP2+: timer: initialize before using oh_name
On 28/05/13 07:24, Afzal Mohammed wrote:
of_property_read_string_index(...,oh_name) in omap_dm_timer_init_one
does not alter the value of 'oh_name' even if the relevant function
fails and as 'oh_name' in stack may have a non-zero value, it would
be misunderstood by timer code that DT has specified ti,hwmod
property for timer. 'oh_name' in this scenario would be a junk value,
this would result in module not being enabled by hwmod API's for
timer, and in turn crash.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f8b23b8..8e0c390 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -220,7 +220,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
int posted)
{
char name[10]; /* 10 = sizeof(gptXX_Xck0) */
- const char *oh_name;
+ const char *oh_name = NULL;
struct device_node *np;
struct omap_hwmod *oh;
struct resource irq, mem;
Thanks!
Acked-by: Jon Hunter jgchun...@gmail.com
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 12/14] Documentation: dt: binding: omap: am43x counter
On 27/05/13 15:37, Afzal Mohammed wrote: AM43x 32K counter binding. Signed-off-by: Afzal Mohammed af...@ti.com --- Documentation/devicetree/bindings/arm/omap/counter.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/omap/counter.txt b/Documentation/devicetree/bindings/arm/omap/counter.txt index 5bd8aa0..9c48dca 100644 --- a/Documentation/devicetree/bindings/arm/omap/counter.txt +++ b/Documentation/devicetree/bindings/arm/omap/counter.txt @@ -2,6 +2,7 @@ OMAP Counter-32K bindings Required properties: - compatible:Must be ti,omap-counter32k for OMAP controllers + ti,am4372-counter32k,ti,omap-counter32k for AM43x counter - reg: Contains timer register address range (base address and length) - ti,hwmods: Name of the hwmod associated to the counter, which is typically counter_32k Changelog should state why this is needed. Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
On 27/05/13 15:37, Afzal Mohammed wrote: AM43x timer bindings. Signed-off-by: Afzal Mohammed af...@ti.com --- Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt index d02e27c..70cb398 100644 --- a/Documentation/devicetree/bindings/arm/omap/timer.txt +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt @@ -14,6 +14,8 @@ Required properties: ti,omap5430-timer (applicable to OMAP543x devices) ti,am335x-timer (applicable to AM335x devices) ti,am335x-timer-1ms (applicable to AM335x devices) + ti,am4372-timer-1ms, ti,am335x-timer-1ms for AM43x 1ms timer + ti,am4372-timer, ti,am335x-timer for AM43x timers other than 1ms one - reg: Contains timer register address range (base address and length). If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these. Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
On 05/28/2013 03:25 PM, Jon Hunter wrote: On 27/05/13 15:37, Afzal Mohammed wrote: AM43x timer bindings. Signed-off-by: Afzal Mohammed af...@ti.com --- Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt index d02e27c..70cb398 100644 --- a/Documentation/devicetree/bindings/arm/omap/timer.txt +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt @@ -14,6 +14,8 @@ Required properties: ti,omap5430-timer (applicable to OMAP543x devices) ti,am335x-timer (applicable to AM335x devices) ti,am335x-timer-1ms (applicable to AM335x devices) +ti,am4372-timer-1ms, ti,am335x-timer-1ms for AM43x 1ms timer +ti,am4372-timer, ti,am335x-timer for AM43x timers other than 1ms one - reg: Contains timer register address range (base address and length). If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these. I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/9] drivers: phy: add generic PHY framework
Hi Kishon,
On 04/29/2013 12:03 PM, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.
PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Thanks for working on this. For the record, I plan to give this a try
in the end of this week, with my simple MIPI CSI/DSI PHY driver. I might
have some more comments then. For now just couple of remarks after
reading the documentation.
---
.../devicetree/bindings/phy/phy-bindings.txt | 66 +++
Documentation/phy.txt | 123 +
MAINTAINERS|7 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 13 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 539
include/linux/phy/phy.h| 248 +
9 files changed, 1005 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
create mode 100644 Documentation/phy.txt
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===
+
+Required Properties:
+#phy-cells:Number of cells in a PHY specifier; The meaning of all those
+ cells is defined by the binding for the phy node. The PHY
+ provider can use the values in cells to find the appropriate
+ PHY.
+
+For example:
+
+phys: phy {
+compatible = xxx;
+reg =...;
+.
+.
+#phy-cells =1;
+.
+.
+};
+
+That node describes an IP block (PHY provider) that implements 2 different
PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should
be
+given while trying to get a reference to it.
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+compatible = xxx;
+reg =xxx;
+.
+.
+phys =usb2_phy,usb3_phy;
+phy-names = usb2phy, usb3phy;
+.
+.
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+compatible = xxx;
+reg =xxx;
+.
+.
+phys =phys 1;
+phy-names = usbphy;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+1 to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000..408d25f
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,123 @@
+ PHY SUBSYSTEM
+ Kishon Vijay Abraham Ikis...@ti.com
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controller has PHY functionality embedded into it and others use an external
Note that some USB
controllers have PHY functionality embedded into them... ?
+PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet,
s/uses/use ?
+SATA etc.
+
+The intention of creating this framework is to bring the phy drivers spread
s/phy/PHY ?
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that uses external PHY (PHY
s/that
[PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
Calling runtime PM API for every block causes serious perf hit to
crypto operations that are done on a long buffer.
As crypto is performed on a page boundary, encrypting large buffers can
cause a series of crypto operations divided by page. The runtime PM API
is also called those many times.
We call runtime_pm_get_sync only at beginning on the session (cra_init)
and runtime_pm_put at the end. This result in upto a 50% speedup as below.
This doesn't make the driver to keep the system awake as runtime get/put
is only called during a crypto session which completes usually quickly.
Before:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s
Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s
Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s
After:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s
Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s
While at it, also drop enter and exit pr_debugs, in related code. tracers
can be used for that.
Tested on a Beaglebone (AM335x SoC) board.
v3 changes:
Refreshed patch on kernel v3.10-rc3
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
drivers/crypto/omap-aes.c | 29 +++--
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ee15b0f..06524a0 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -203,13 +203,6 @@ static void omap_aes_write_n(struct omap_aes_dev *dd, u32
offset,
static int omap_aes_hw_init(struct omap_aes_dev *dd)
{
- /*
-* clocks are enabled when request starts and disabled when finished.
-* It may be long delays between requests.
-* Device might go to off mode to save power.
-*/
- pm_runtime_get_sync(dd-dev);
-
if (!(dd-flags FLAGS_INIT)) {
dd-flags |= FLAGS_INIT;
dd-err = 0;
@@ -636,7 +629,6 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd,
int err)
pr_debug(err: %d\n, err);
- pm_runtime_put(dd-dev);
dd-flags = ~FLAGS_BUSY;
req-base.complete(req-base, err);
@@ -837,8 +829,16 @@ static int omap_aes_ctr_decrypt(struct ablkcipher_request
*req)
static int omap_aes_cra_init(struct crypto_tfm *tfm)
{
- pr_debug(enter\n);
+ struct omap_aes_dev *dd = NULL;
+ /* Find AES device, currently picks the first device */
+ spin_lock_bh(list_lock);
+ list_for_each_entry(dd, dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(list_lock);
+
+ pm_runtime_get_sync(dd-dev);
tfm-crt_ablkcipher.reqsize = sizeof(struct omap_aes_reqctx);
return 0;
@@ -846,7 +846,16 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
static void omap_aes_cra_exit(struct crypto_tfm *tfm)
{
- pr_debug(enter\n);
+ struct omap_aes_dev *dd = NULL;
+
+ /* Find AES device, currently picks the first device */
+ spin_lock_bh(list_lock);
+ list_for_each_entry(dd, dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(list_lock);
+
+ pm_runtime_put_sync(dd-dev);
}
/* ** ALGS */
--
1.7.4.1
--
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] usb: omap2430: fix memleak in err case
On 2013/5/28 23:34, Andy Shevchenko wrote: No go. Check the 4b7e450fb5cefb5865c77999a675330206ab3b8a And update you tree, please. -- With Best Regards, Andy Shevchenko It had been changed :( Thanks, Libo -- 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] usb: omap2430: fix memleak in err case
On 2013/5/29 1:40, Sergei Shtylyov wrote: Hello. On 22-05-2013 7:30, Libo Chen wrote: when omap_get_control_dev faild, we should release related platform_device * Changelog from v1: * fix spell: s/fail/fails/, s/relational/related/ , thank Sergei sergei.shtyl...@cogentembedded.com It seems you've actually replaced fail with faild, not fails. sorry for my weak spell. thanks again, Libo Signed-off-by: Libo Chen libo.c...@huawei.com --- drivers/usb/musb/omap2430.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) WBR, Sergei -- 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] arm: omap2: fix AM33xx hwmod infos for UART2
-Original Message-
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
Sent: Tuesday, May 28, 2013 8:48 PM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Hiremath, Vaibhav; Paul Walmsley
Subject: [PATCH] arm: omap2: fix AM33xx hwmod infos for UART2
The UART2 hwmod structure is pointing to the EDMA channels of UART1,
which doesn't look right. This patch fixes this by making the UART2
hwmod structure to a new structure that lists the EDMA channels to be
used by the UART2.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 01d8f32..9113251 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2006,6 +2006,13 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
},
};
+/* uart2 */
+static struct omap_hwmod_dma_info uart2_edma_reqs[] = {
+ { .name = tx, .dma_req = 28, },
+ { .name = rx, .dma_req = 29, },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_irq_info am33xx_uart2_irqs[] = {
{ .irq = 73 + OMAP_INTC_START, },
{ .irq = -1 },
@@ -2016,7 +2023,7 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
.class = uart_class,
.clkdm_name = l4ls_clkdm,
.mpu_irqs = am33xx_uart2_irqs,
- .sdma_reqs = uart1_edma_reqs,
+ .sdma_reqs = uart2_edma_reqs,
.main_clk = dpll_per_m2_div4_ck,
.prcm = {
.omap4 = {
Good catch.
Acked-by: Vaibhav Hiremath hvaib...@ti.com
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 v6 1/9] drivers: phy: add generic PHY framework
Hi, On Wednesday 29 May 2013 04:07 AM, Sylwester Nawrocki wrote: Hi Kishon, On 04/29/2013 12:03 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. For dt-boot, the PHY drivers should also register *PHY provider* with the framework. PHY drivers should create the PHY by passing id and ops like init, exit, power_on and power_off. This framework is also pm runtime enabled. The documentation for the generic PHY framework is added in Documentation/phy.txt and the documentation for dt binding can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com Thanks for working on this. For the record, I plan to give this a try in the end of this week, with my simple MIPI CSI/DSI PHY driver. I might have some more comments then. For now just couple of remarks after reading the documentation. Thanks for reviewing. I'll wait for your comments before posting the next version. 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
