[PATCH V2] OMAP4: Intialize IVA Device in addition to DSP device.
OMAP4 has two different Devices IVA and DSP. DSP is bound
with IVA for DVFS. The registration of IVA dev in API
'omap2_init_processor_devices' was missing. Init dev for
'iva_dev' is added.
This also fixes the following error seen during boot as
omap2_set_init_voltage can now find the iva device
omap2_set_init_voltage: Invalid parameters!
omap2_set_init_voltage: Unable to put vdd_iva to its init voltage
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
Tested on OMAP4430 SDP Board.
Baseline:
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Branch :pm-core
V2:
Rephrased the Commit log.
arch/arm/mach-omap2/pm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 30af335..49486f5 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -89,6 +89,7 @@ static void omap2_init_processor_devices(void)
if (cpu_is_omap44xx()) {
_init_omap_device(l3_main_1, l3_dev);
_init_omap_device(dsp, dsp_dev);
+ _init_omap_device(iva, iva_dev);
} else {
_init_omap_device(l3_main, l3_dev);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: protect dmm_map properly
On Fri, Mar 11, 2011 at 06:29:06PM -0600, Omar Ramirez Luna wrote: Hi Greg, Please consider to apply this patch in the staging tree, as the description says it fixes a crash in tidspbridge driver, this bug was already present but it seems to have surfaced by recent tests made by Felipe and Tuomas. It is an urgent fix for 2.6.38. Heh, it's funny to see such a urgent fix take so long to get to me :) Is it also applicable for .37? More on this discussion: http://www.gossamer-threads.com/lists/linux/kernel/1351446 Thanks, - omar From: Felipe Contreras felipe.contre...@nokia.com We need to protect not only the dmm_map list, but the individual map_obj's, otherwise, we might be building the scatter-gather list with garbage. So, use the existing proc_lock for that. I observed race conditions which caused kernel panics while running stress tests, also, Tuomas Kulve found it happening quite often in Gumstix Over. This patch fixes those. Cc: Tuomas Kulve tuo...@kulve.fi Signed-off-by: Felipe Contreras felipe.contre...@nokia.com Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com How about I send it to Linus for .39 and then add it to the .38-stable tree when it comes out? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/20] world-writable files in sysfs and debugfs
Vasiliy Kulikov (20): mach-ux500: mbox-db5500: world-writable sysfs fifo file leds: lp5521: world-writable sysfs engine* files leds: lp5523: world-writable engine* sysfs files misc: ep93xx_pwm: world-writable sysfs files rtc: rtc-ds1511: world-writable sysfs nvram file scsi: aic94xx: world-writable sysfs update_bios file scsi: iscsi: world-writable sysfs priv_sess file These are still not merged :( -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/5] OMAP2+ / Panda implementation for async platform_data
The following series uses the - proposed platform support for async platform data http://marc.info/?l=linux-kernelm=129996915023642w=2 - proposed usb core and usbnet use of async platform data http://marc.info/?l=linux-kernelm=129996960824035w=2 in order to configure onboard USB - Ethernet bridge wired up on Panda boards. The same issue exists on Beagle XM boards which also have an onboard soldered USB - Ethernet bridge terminating on a normal onboard RJ45 socket. With the above support, these patches extend platform_data led control of onboard assets to include those probed by USB bus asynchronously. In the Panda case, it uses the platform data introduced to usbnet to enforce the selection of eth%d address since the board definition file knows it is a permaently wired onboard connection using RJ45 jack, and to define the MAC address from unique CPU DIE ID data. --- Andy Green (5): USBNET: SMSC95XX: if mac set in platform data no need for random one OMAP2+: Set onboard Ethernet MAC address using unique CPU ID data OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430 OMAP2+: add cpu id register to MAC address helper OMAP2+: Panda introduce async platform data definition drivers/net/usb/smsc95xx.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition
This is part of an RFC patch series introducing asynchronous platform
data, which may be attached to discovered bus devices at probe time
based on the device path.
As part of the series, platform_data is enabled in usbnet layer.
This patch defines the usbnet platform data, allowing the panda board
definition file to assert the naming of the usbnet network interface
should be eth%d instead of usb%d.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/board-omap4panda.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index e944025..7c7aa74 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -26,6 +26,12 @@
#include linux/usb/otg.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/usb.h
+#include linux/skbuff.h
+#include linux/mii.h
+#include linux/netdevice.h
+#include linux/if_ether.h
+#include linux/usb/usbnet.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -397,6 +403,17 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
+struct usbnet_platform_data panda_usbnet_platform_data_usb1_1 = {
+ .flags = USBNET_PLATDATA_FLAG__FORCE_ETH_IFNAME,
+};
+
+struct platform_async_platform_data panda_async_pdata_map[] = {
+ {
+ .device_path = usb1/1-1/1-1.1,
+ .platform_data = panda_usbnet_platform_data_usb1_1,
+ },
+};
+
static void __init omap4_panda_init(void)
{
int package = OMAP_PACKAGE_CBS;
@@ -405,6 +422,9 @@ static void __init omap4_panda_init(void)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, package);
+ platform_async_platform_data_register(panda_async_pdata_map,
+ ARRAY_SIZE(panda_async_pdata_map));
+
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
omap_serial_init();
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper
Introduce a generic helper function that can set a MAC address using
data from the OMAP unqiue CPU ID register.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/id.c | 13 +
arch/arm/mach-omap2/include/mach/id.h |1 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..fc69ec5 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -506,3 +506,16 @@ void __init omap2_set_globals_tap(struct omap_globals
*omap2_globals)
else
tap_prod_id = 0x0208;
}
+
+
+void omap2_die_id_to_mac(u8 *mac, int length)
+{
+ struct omap_die_id odi;
+
+ omap_get_die_id(odi);
+ memcpy(mac, odi.id_0, length);
+
+ /* mark it as not multicast and outside official 80211 MAC namespace */
+
+ mac[0] = (mac[0] ~1) | 2;
+}
diff --git a/arch/arm/mach-omap2/include/mach/id.h
b/arch/arm/mach-omap2/include/mach/id.h
index 02ed3aa..72e10eb 100644
--- a/arch/arm/mach-omap2/include/mach/id.h
+++ b/arch/arm/mach-omap2/include/mach/id.h
@@ -18,5 +18,6 @@ struct omap_die_id {
};
void omap_get_die_id(struct omap_die_id *odi);
+void omap2_die_id_to_mac(u8 *mac, int length);
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430
This adapts the register offsets used to read the CPU DIE ID registers
when run on 44XX so they match what is in the OMAP4430 Reference Manual
page 269
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/id.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index fc69ec5..733bb27 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -84,6 +84,11 @@ EXPORT_SYMBOL(omap_type);
#define OMAP_TAP_DIE_ID_2 0x0220
#define OMAP_TAP_DIE_ID_3 0x0224
+#define OMAP_TAP_DIE_ID_44XX_0 0x0200
+#define OMAP_TAP_DIE_ID_44XX_1 0x0208
+#define OMAP_TAP_DIE_ID_44XX_2 0x020c
+#define OMAP_TAP_DIE_ID_44XX_3 0x0210
+
#define read_tap_reg(reg) __raw_readl(tap_base + (reg))
struct omap_id {
@@ -107,6 +112,14 @@ static u16 tap_prod_id;
void omap_get_die_id(struct omap_die_id *odi)
{
+ if (cpu_is_omap44xx()) {
+ odi-id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
+ odi-id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
+ odi-id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
+ odi-id_3 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_3);
+
+ return;
+ }
odi-id_0 = read_tap_reg(OMAP_TAP_DIE_ID_0);
odi-id_1 = read_tap_reg(OMAP_TAP_DIE_ID_1);
odi-id_2 = read_tap_reg(OMAP_TAP_DIE_ID_2);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/5] OMAP2+: Set onboard Ethernet MAC address using unique CPU ID data
This is part of an RFC patch series introducing asynchronous platform
data, which may be attached to discovered bus devices at probe time
based on the device path.
As part of the series, platform_data is enabled in usbnet layer.
This patch used the usbnet platform data in the panda board
definition file to set the MAC address of the USB - Ethernet
onboard bridge to a unique value derived from unique CPU ID
data.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/board-omap4panda.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 7c7aa74..312154b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -35,6 +35,7 @@
#include mach/hardware.h
#include mach/omap4-common.h
+#include mach/id.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -404,7 +405,8 @@ static struct omap_board_mux board_mux[] __initdata = {
#endif
struct usbnet_platform_data panda_usbnet_platform_data_usb1_1 = {
- .flags = USBNET_PLATDATA_FLAG__FORCE_ETH_IFNAME,
+ .flags = USBNET_PLATDATA_FLAG__FORCE_ETH_IFNAME |
+ USBNET_PLATDATA_FLAG__USE_MAC,
};
struct platform_async_platform_data panda_async_pdata_map[] = {
@@ -422,6 +424,8 @@ static void __init omap4_panda_init(void)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, package);
+ omap2_die_id_to_mac(panda_usbnet_platform_data_usb1_1.mac,
+sizeof(panda_usbnet_platform_data_usb1_1.mac));
platform_async_platform_data_register(panda_async_pdata_map,
ARRAY_SIZE(panda_async_pdata_map));
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 5/5] USBNET: SMSC95XX: if mac set in platform data no need for random one
This is part of an RFC patch series introducing asynchronous platform
data, which may be attached to discovered bus devices at probe time
based on the device path.
As part of the series, platform_data is enabled in usbnet layer.
This patch allows smsc95xx usbnet driver to understand that the MAC
setting was handled by plaform_data sent into usbnet, and that it
does not need to overwrite the already correct MAC with a random one.
Cc: Steve Glendinning steve.glendinn...@smsc.com
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/net/usb/smsc95xx.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index bc86f4b..1d09cad 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -639,6 +639,16 @@ static int smsc95xx_ioctl(struct net_device *netdev,
struct ifreq *rq, int cmd)
static void smsc95xx_init_mac_address(struct usbnet *dev)
{
+ struct usbnet_platform_data *pdata = dev-udev-dev.platform_data;
+
+ /*
+* if netdev platform data has taken responsibility for forcing
+* the MAC then nothing to do here
+*/
+
+ if (pdata pdata-flags USBNET_PLATDATA_FLAG__USE_MAC)
+ return;
+
/* try reading mac address from EEPROM */
if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
dev-net-dev_addr) == 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] staging: tidspbridge: protect dmm_map properly
On Sat, Mar 12, 2011 at 7:36 PM, Greg KH g...@kroah.com wrote: On Fri, Mar 11, 2011 at 06:29:06PM -0600, Omar Ramirez Luna wrote: Please consider to apply this patch in the staging tree, as the description says it fixes a crash in tidspbridge driver, this bug was already present but it seems to have surfaced by recent tests made by Felipe and Tuomas. It is an urgent fix for 2.6.38. Heh, it's funny to see such a urgent fix take so long to get to me :) Well, depending on your hardware and use-case this might or might not be urgent. At least for some people the driver is unusable without this. Is it also applicable for .37? Yes. How about I send it to Linus for .39 and then add it to the .38-stable tree when it comes out? That was the plan for .38/.37-stable. I'd say that's fine, but it would be even better to avoid people getting bit by this on plain .38. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition
On Sat, Mar 12, 2011 at 10:50:39PM +, Andy Green wrote: This is part of an RFC patch series introducing asynchronous platform data, which may be attached to discovered bus devices at probe time based on the device path. As part of the series, platform_data is enabled in usbnet layer. This patch defines the usbnet platform data, allowing the panda board definition file to assert the naming of the usbnet network interface should be eth%d instead of usb%d. Why is this? If you want to do this, it should be done in userspace today, no need to involve the kernel in this type of thing. So I don't see the point of this patch. thanks, greg k-h -- 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] staging: tidspbridge: protect dmm_map properly
On Sun, Mar 13, 2011 at 01:42:35AM +0200, Felipe Contreras wrote: On Sat, Mar 12, 2011 at 7:36 PM, Greg KH g...@kroah.com wrote: On Fri, Mar 11, 2011 at 06:29:06PM -0600, Omar Ramirez Luna wrote: Please consider to apply this patch in the staging tree, as the description says it fixes a crash in tidspbridge driver, this bug was already present but it seems to have surfaced by recent tests made by Felipe and Tuomas. It is an urgent fix for 2.6.38. Heh, it's funny to see such a urgent fix take so long to get to me :) Well, depending on your hardware and use-case this might or might not be urgent. At least for some people the driver is unusable without this. Urgency is all relative :) Is it also applicable for .37? Yes. In the future, always say this so I don't have to ask please. How about I send it to Linus for .39 and then add it to the .38-stable tree when it comes out? That was the plan for .38/.37-stable. I'd say that's fine, but it would be even better to avoid people getting bit by this on plain .38. What is one more week, when you all waited months to get this to me? In other words, why should I suddenly now rush when no one else did? I'll queue this up for .39 and mark it for stable inclusion. thanks, greg k-h -- 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] OMAP4: PM: remove redundant #ifdef CONFIG_PM
pm44xx.c is built only when CONFIG_PM is setup,
remove redundant CONFIG_PM check.
This also fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=25022
Reported-by: Martin Etti ettl.mar...@gmx.de
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm44xx.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 76cfff2..59a870b 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -105,13 +105,11 @@ static int __init omap4_pm_init(void)
pr_err(Power Management for TI OMAP4.\n);
-#ifdef CONFIG_PM
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err(Failed to setup powerdomains\n);
goto err2;
}
-#endif
#ifdef CONFIG_SUSPEND
suspend_set_ops(omap_pm_ops);
--
1.7.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
