RE: [PATCH v2] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
From: Vikram Pandita vikram.pand...@ti.com This patch enables the DMA mode1 RX support. This feature is enabled based on the short_not_ok flag passed from gadget drivers. This will result in a thruput performance gain of around 40% for USB mass-storage/mtp use cases. Based on Original work by Anand Gadiyar gadi...@ti.com on 2.6.35 kernel Change-Id: I9b3a7cae73b63e86128d2caf4cdd67ab77556e75 Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com I think the change-id should not be included in upstream submissions - it may not be useful to someone looking at the changelog. So you probably should drop it. Could you please retain my authorship and sign off from the original patch, since I did pretty much all the original work on writing this patch (and if I remember correctly several attempts to get this merged upstream)? I don't see any functional changes from my original patch. - Anand -- 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: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Mon, Jul 18, 2011 at 11:22 PM, Gadiyar, Anand gadi...@ti.com wrote: From: Vikram Pandita vikram.pand...@ti.com This patch enables the DMA mode1 RX support. This feature is enabled based on the short_not_ok flag passed from gadget drivers. This will result in a thruput performance gain of around 40% for USB mass-storage/mtp use cases. Based on Original work by Anand Gadiyar gadi...@ti.com on 2.6.35 kernel Change-Id: I9b3a7cae73b63e86128d2caf4cdd67ab77556e75 Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com I think the change-id should not be included in upstream submissions - it may not be useful to someone looking at the changelog. So you probably should drop it. yes will drop that. This comes from gerrit commit hook that does not have a meaning for upstream. Could you please retain my authorship and sign off from the original patch, since I did pretty much all the original work on writing this patch That is given and clearly mentioned in the commit message. I will change the authorship with no issues, but would have been nice if you could have taken this upstream. We have been carrying this optimisation around in product kernels for a long time now and we keep redoing on each migration, with the downside of sometimes loosing the authorship. (and if I remember correctly several attempts to get this merged upstream)? I don't see any functional changes from my original patch. Wonder what were the reasons for not getting accepted? Can you re-ignite the discussion why it cannot be taken in then? - Anand -- 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: musb: Enable DMA mode1 RX for USB-Mass-Storage
Pandita, Vikram wrote: On Mon, Jul 18, 2011 at 11:22 PM, Gadiyar, Anand gadi...@ti.com wrote: From: Vikram Pandita vikram.pand...@ti.com This patch enables the DMA mode1 RX support. This feature is enabled based on the short_not_ok flag passed from gadget drivers. This will result in a thruput performance gain of around 40% for USB mass-storage/mtp use cases. Based on Original work by Anand Gadiyar gadi...@ti.com on 2.6.35 kernel Change-Id: I9b3a7cae73b63e86128d2caf4cdd67ab77556e75 Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com I think the change-id should not be included in upstream submissions - it may not be useful to someone looking at the changelog. So you probably should drop it. yes will drop that. This comes from gerrit commit hook that does not have a meaning for upstream. Could you please retain my authorship and sign off from the original patch, since I did pretty much all the original work on writing this patch That is given and clearly mentioned in the commit message. I will change the authorship with no issues, but would have been nice if you could have taken this upstream. Yes, I ought to have followed up more. But this was at a time when we were promised a competing implementation from Nokia would be merged that would get mode1 working for all use cases. A patch series was posted to the mailing lists around Dec 2009 with promises off-list to repost with comments addressed - that has never happened so far. But you can't just change authorship when the entire functional code is the same. (It doesn't matter much to me - I'm not as active on MUSB as I used to be; it's just the principle of the thing). We have been carrying this optimisation around in product kernels for a long time now and we keep redoing on each migration, with the downside of sometimes loosing the authorship. (and if I remember correctly several attempts to get this merged upstream)? I don't see any functional changes from my original patch. Wonder what were the reasons for not getting accepted? Can you re-ignite the discussion why it cannot be taken in then? You've already re-ignited this discussion. I haven't tested the patch with the current kernel (and will do so soon), but if it does still work and there are no objections, it ought to be merged. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/6] omap: voltage: change code to use new location of voltage.h and vp.h
On Mon, 2011-07-18 at 20:16 +0200, Balbi, Felipe wrote: Hi, On Mon, Jul 18, 2011 at 08:35:18PM +0300, Tero Kristo wrote: These are now under plat-omap/include/plat. Signed-off-by: Tero Kristo t-kri...@ti.com this has to be folded into previous patch, otherwise we will have a broken bisection point. Good to know for future, I will just drop this patch (and patch 1 also) though as Kevin suggested and create a simple stub that provides only the API needed. -Tero Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/6] OMAP: move voltage.h and vp.h under platform include directory
On Mon, 2011-07-18 at 20:16 +0200, Balbi, Felipe wrote: Hi, On Mon, Jul 18, 2011 at 08:35:17PM +0300, Tero Kristo wrote: This is needed so that these include files can be accessed from drivers. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/voltage.h | 180 - arch/arm/mach-omap2/vp.h | 128 arch/arm/plat-omap/include/plat/voltage.h | 179 arch/arm/plat-omap/include/plat/vp.h | 128 4 files changed, 307 insertions(+), 308 deletions(-) delete mode 100644 arch/arm/mach-omap2/voltage.h delete mode 100644 arch/arm/mach-omap2/vp.h create mode 100644 arch/arm/plat-omap/include/plat/voltage.h create mode 100644 arch/arm/plat-omap/include/plat/vp.h just one small tip, if you use git format-patch -M, it would detect that this was just a rename ;-) Hmm did not notice this... git-format actually detected that this was a rename in previous version of the set, even without the -M option. Will try to remember that in the future. Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 3/6] regulator: omap smps regulator driver
On Tue, 2011-07-19 at 01:40 +0200, Hilman, Kevin wrote: Felipe Balbi ba...@ti.com writes: On Mon, Jul 18, 2011 at 08:35:19PM +0300, Tero Kristo wrote: diff --git a/drivers/regulator/omap-smps-regulator.c b/drivers/regulator/omap-smps-regulator.c new file mode 100644 index 000..8b56e4f --- /dev/null +++ b/drivers/regulator/omap-smps-regulator.c @@ -0,0 +1,179 @@ +/* + * omap-vp-regulator.c -- support SMPS regulators for OMAP chips name is wrong here. In fact, just leave filenames out of file headers all together to avoid this kind of problem. Yea, can drop that out. Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 3/6] regulator: omap smps regulator driver
On Mon, 2011-07-18 at 20:22 +0200, Balbi, Felipe wrote:
Hi,
On Mon, Jul 18, 2011 at 08:35:19PM +0300, Tero Kristo wrote:
diff --git a/drivers/regulator/omap-smps-regulator.c
b/drivers/regulator/omap-smps-regulator.c
new file mode 100644
index 000..8b56e4f
--- /dev/null
+++ b/drivers/regulator/omap-smps-regulator.c
@@ -0,0 +1,179 @@
+/*
+ * omap-vp-regulator.c -- support SMPS regulators for OMAP chips
name is wrong here.
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/ctype.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/err.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/regulator/omap-smps.h
+#include plat/voltage.h
+
+#define DRIVER_NAMEomap-smps
+
+struct omap_smps_reg_info {
+ const char *vdd_name;
+ struct regulator_dev*rdev;
+ struct voltagedomain*voltdm;
+ struct regulator_desc desc;
+};
+
+static int omap_smps_set_voltage(struct regulator_dev *rdev, int min_uV,
+ int max_uV, unsigned *selector)
+{
+ struct omap_smps_reg_info *info = rdev_get_drvdata(rdev);
+ return voltdm_scale(info-voltdm, min_uV);
+}
+
+static int omap_smps_get_voltage(struct regulator_dev *rdev)
+{
+ struct omap_smps_reg_info *info = rdev_get_drvdata(rdev);
+ return omap_vp_get_curr_volt(info-voltdm);
+}
+
+static struct regulator_ops omap_smps_ops = {
should this be const ?
I think it can be yea, I'll change that for next version.
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Tue, Jul 19, 2011 at 12:46 AM, Gadiyar, Anand gadi...@ti.com wrote:
Pandita, Vikram wrote:
On Mon, Jul 18, 2011 at 11:22 PM, Gadiyar, Anand gadi...@ti.com wrote:
snip
But you can't just change authorship when the entire functional code
is the same. (It doesn't matter much to me - I'm not as active on
MUSB as I used to be; it's just the principle of the thing).
Moiz fixed the second part of your patch - which was not there on your
original work:
snip
+ if (use_mode_1) {
+ transfer_size =
min(request-length - request-actual,
+
channel-max_len);
musb_ep-dma-desired_mode = 1;
+ } else {
+ transfer_size =
min(request-length - request-actual,
+ (unsigned)len);
+
musb_ep-dma-desired_mode = 0;+
if (use_mode_1) {
+ transfer_size =
min(request-length - request-actual,
+
channel-max_len);
musb_ep-dma-desired_mode = 1;
+ } else {
+ transfer_size =
min(request-length - request-actual,
+ (unsigned)len);
+ musb_ep-dma-desired_mode = 0;
snip end
The history is:
Original author on .35 or .32 kernel : Anand Gadiyar
Fixes done by and some more forward ports: Moiz Sonasath
Tested on 3.0 and code cleanups, commit message updates, community
comment fixes: Vikram Pandita
Wonder if original author did not act all this while, is there
anything wrong in changing authorship with proper accreditation to
original author?
For future pushes, i would really like to learn what the linux
community suggests the right approach for such cases.
As i said, i am open to change and will repost as decided - there is
no attempt to sabotage anyone's work here :-)
We have been carrying this optimisation around in product kernels for
a long time now and we keep redoing on each migration,
with the downside of sometimes loosing the authorship.
(and if I remember correctly several
attempts to get this merged upstream)? I don't see any
functional changes from my original patch.
Wonder what were the reasons for not getting accepted?
Can you re-ignite the discussion why it cannot be taken in then?
You've already re-ignited this discussion. I haven't tested the patch
with the current kernel (and will do so soon), but if it does still
work and there are no objections, it ought to be merged.
- Anand
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 4/6] omap3: pmic: add API to get common SMPS regulators
On Mon, 2011-07-18 at 20:23 +0200, Balbi, Felipe wrote:
Hi,
On Mon, Jul 18, 2011 at 08:35:20PM +0300, Tero Kristo wrote:
diff --git a/arch/arm/mach-omap2/twl-common.h
b/arch/arm/mach-omap2/twl-common.h
index 5e83a5b..fde8467 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -25,6 +25,11 @@
#define TWL_COMMON_REGULATOR_VPLL1 (1 4)
#define TWL_COMMON_REGULATOR_VPLL2 (1 5)
+/* TWL SMPS regulators */
+#define SMPS_COMMON_REGULATOR_MPU (1 0)
+#define SMPS_COMMON_REGULATOR_CORE (1 1)
+#define SMPS_COMMON_REGULATOR_IVA (1 2)
+#define SMPS_COMMON_REGULATOR_MPU_IVA (1 3)
struct twl4030_platform_data;
@@ -56,4 +61,13 @@ void omap3_pmic_get_config(struct twl4030_platform_data
*pmic_data,
void omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
u32 pdata_flags, u32 regulators_flags);
+void omap_pmic_get_smps_config(struct platform_device *smps_dev,
+ u32 smps_flags);
+
+static inline void omap3_pmic_get_smps_config(struct platform_device
*smps_dev)
+{
+ omap_pmic_get_smps_config(smps_dev, SMPS_COMMON_REGULATOR_MPU_IVA |
+ SMPS_COMMON_REGULATOR_CORE);
+}
if these are specific to OMAP SoC, why do they come on twl-common.h
header ?
I was wondering about this myself too and was almost certain that
someone will ask about it. I decided to follow the easy path for this
version though for comments. Anyway, which would be the best option for
this:
1) just add them into twl-common
2) rename twl-common to something else and add these
3) add a completely new file + header for the smps regulator support
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
--
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: musb: Enable DMA mode1 RX for USB-Mass-Storage
Pandita, Vikram wrote: On Tue, Jul 19, 2011 at 12:46 AM, Gadiyar, Anand gadi...@ti.com wrote: Pandita, Vikram wrote: On Mon, Jul 18, 2011 at 11:22 PM, Gadiyar, Anand gadi...@ti.com wrote: snip But you can't just change authorship when the entire functional code is the same. (It doesn't matter much to me - I'm not as active on MUSB as I used to be; it's just the principle of the thing). Moiz fixed the second part of your patch - which was not there on your original work: snip ... snip end The history is: Original author on .35 or .32 kernel : Anand Gadiyar Fixes done by and some more forward ports: Moiz Sonasath Tested on 3.0 and code cleanups, commit message updates, community comment fixes: Vikram Pandita Wonder if original author did not act all this while, is there anything wrong in changing authorship with proper accreditation to original author? For future pushes, i would really like to learn what the linux community suggests the right approach for such cases. As i said, i am open to change and will repost as decided - there is no attempt to sabotage anyone's work here :-) Checking the git tree history and the patch you just posted, you're right. I missed Moiz's changes. (but that same git tree shows you've got my sign-off on all the internal patches Moiz posted - and I don't remember if the original debugging was done by me or not) I'm withdrawing my objection - let's just get the patch merged. It's stayed out-of-tree for far too long. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
From: Anand Gadiyar gadi...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Tested-by: Vikram Pandita vikram.pand...@ti.com
---
v1 - initial push
v2 - fixed whitespace issues as per Sergei Shtylyovsshtyl...@mvista.com
comments
v3 - restor authorship to Anand Gadiyar gadi...@ti.com
drivers/usb/musb/musb_gadget.c | 68 ---
1 files changed, 42 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6aeb363..4a1432e 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -634,6 +634,7 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
u16 len;
u16 csr = musb_readw(epio, MUSB_RXCSR);
struct musb_hw_ep *hw_ep = musb-endpoints[epnum];
+ u8 use_mode_1;
if (hw_ep-is_shared_fifo)
musb_ep = hw_ep-ep_in;
@@ -683,6 +684,18 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
if (csr MUSB_RXCSR_RXPKTRDY) {
len = musb_readw(epio, MUSB_RXCOUNT);
+
+ /*
+* Enable Mode 1 for RX transfers only for mass-storage
+* use-case, based on short_not_ok flag which is set only
+* from file_storage and f_mass_storage drivers
+*/
+
+ if (request-short_not_ok len == musb_ep-packet_sz)
+ use_mode_1 = 1;
+ else
+ use_mode_1 = 0;
+
if (request-actual request-length) {
#ifdef CONFIG_USB_INVENTRA_DMA
if (is_buffer_mapped(req)) {
@@ -714,37 +727,40 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
* then becomes usable as a runtime use mode 1 hint...
*/
- csr |= MUSB_RXCSR_DMAENAB;
-#ifdef USE_MODE1
- csr |= MUSB_RXCSR_AUTOCLEAR;
- /* csr |= MUSB_RXCSR_DMAMODE; */
-
- /* this special sequence (enabling and then
-* disabling MUSB_RXCSR_DMAMODE) is required
-* to get DMAReq to activate
-*/
- musb_writew(epio, MUSB_RXCSR,
- csr | MUSB_RXCSR_DMAMODE);
-#else
- if (!musb_ep-hb_mult
- musb_ep-hw_ep-rx_double_buffered)
+ /* Experimental: Mode1 works with mass storage
use cases */
+ if (use_mode_1) {
csr |= MUSB_RXCSR_AUTOCLEAR;
-#endif
- musb_writew(epio, MUSB_RXCSR, csr);
+ musb_writew(epio, MUSB_RXCSR, csr);
+ csr |= MUSB_RXCSR_DMAENAB;
+ musb_writew(epio, MUSB_RXCSR, csr);
+
+ /* this special sequence (enabling and
then
+ * disabling MUSB_RXCSR_DMAMODE) is
required
+ * to get DMAReq to activate
+ */
+ musb_writew(epio, MUSB_RXCSR,
+ csr | MUSB_RXCSR_DMAMODE);
+ musb_writew(epio, MUSB_RXCSR, csr);
+
+ } else {
+ if (!musb_ep-hb_mult
+
musb_ep-hw_ep-rx_double_buffered)
+ csr |= MUSB_RXCSR_AUTOCLEAR;
+ csr |= MUSB_RXCSR_DMAENAB;
+ musb_writew(epio, MUSB_RXCSR, csr);
+ }
if (request-actual request-length) {
int transfer_size = 0;
-#ifdef USE_MODE1
- transfer_size = min(request-length -
request-actual,
- channel-max_len);
-#else
- transfer_size = min(request-length -
request-actual,
- (unsigned)len);
-#endif
- if (transfer_size = musb_ep-packet_sz)
- musb_ep-dma-desired_mode = 0;
-
Re: [PATCHv3 3/6] regulator: omap smps regulator driver
On 07/18/2011 06:35 PM, Tero Kristo wrote:
OMAP SMPS regulator driver provides access to OMAP voltage processor
controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and
additionally VDD_IVA for OMAP4. SMPS regulators use the OMAP voltage
layer for the actual voltage regulation operations.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Todd Poynor toddpoy...@google.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Liam Girdwood l...@ti.com
---
drivers/regulator/Kconfig |9 ++
drivers/regulator/Makefile |1 +
drivers/regulator/omap-smps-regulator.c | 180
+++
include/linux/regulator/omap-smps.h | 20
4 files changed, 210 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/omap-smps-regulator.c
create mode 100644 include/linux/regulator/omap-smps.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index d7ed20f..bb18ff2 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -303,5 +303,14 @@ config REGULATOR_TPS65910
help
This driver supports TPS65910 voltage regulator chips.
+config REGULATOR_OMAP_SMPS
+ tristate TI OMAP SMPS Power Regulators
+ depends on (ARCH_OMAP3 || ARCH_OMAP4) PM TWL4030_CORE
+ help
+ This driver supports the OMAP3 / OMAP4 SMPS regulators for VDD1,
+ VDD2 and VDD3. These regulators reside inside the TWL4030 /
+ TWL6030 chip but are accessed using the voltage processor
+ interface of OMAP.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 3932d2e..191e3d5 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -43,5 +43,6 @@ obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
obj-$(CONFIG_REGULATOR_AB8500) += ab8500.o
obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
+obj-$(CONFIG_REGULATOR_OMAP_SMPS) += omap-smps-regulator.o
ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
diff --git a/drivers/regulator/omap-smps-regulator.c
b/drivers/regulator/omap-smps-regulator.c
new file mode 100644
index 000..8b56e4f
--- /dev/null
+++ b/drivers/regulator/omap-smps-regulator.c
@@ -0,0 +1,179 @@
+/*
+ * omap-vp-regulator.c -- support SMPS regulators for OMAP chips
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/ctype.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/err.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/regulator/omap-smps.h
+#include plat/voltage.h
+
+#define DRIVER_NAME omap-smps
+
+struct omap_smps_reg_info {
+ const char *vdd_name;
+ struct regulator_dev*rdev;
+ struct voltagedomain*voltdm;
+ struct regulator_desc desc;
+};
+
+static int omap_smps_set_voltage(struct regulator_dev *rdev, int min_uV,
+ int max_uV, unsigned *selector)
+{
+ struct omap_smps_reg_info *info = rdev_get_drvdata(rdev);
+ return voltdm_scale(info-voltdm, min_uV);
+}
+
+static int omap_smps_get_voltage(struct regulator_dev *rdev)
+{
+ struct omap_smps_reg_info *info = rdev_get_drvdata(rdev);
+ return omap_vp_get_curr_volt(info-voltdm);
+}
+
+static struct regulator_ops omap_smps_ops = {
+ .set_voltage= omap_smps_set_voltage,
+ .get_voltage= omap_smps_get_voltage,
+};
+
+#define SMPS_REG(name) { \
+ .vdd_name = #name, \
+ .desc = { \
+ .ops = omap_smps_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .owner = THIS_MODULE, \
+ }, \
+ }
+
+static struct omap_smps_reg_info omap_smps_regs[] = {
+ SMPS_REG(mpu),
+ SMPS_REG(mpu_iva),
+ SMPS_REG(iva),
+ SMPS_REG(core),
+};
+
+static void omap_smps_reg_cleanup(void)
+{
+ int i;
+ struct omap_smps_reg_info *info;
+
+ for (i = 0; i ARRAY_SIZE(omap_smps_regs); i++) {
+ info = omap_smps_regs[i];
+ if (info-rdev) {
+ regulator_unregister(info-rdev);
+ info-rdev = NULL;
+ }
+
+ kfree(info-desc.name);
+ info-desc.name = NULL;
+ }
+}
+
+static struct regulator_init_data dummy_initdata __initdata;
+
+static int __devinit omap_smps_reg_probe(struct
[RFC 0/2 v2] join omap4panda and pcm049
Try to join both boards. Only compile testet. basis for discusson Jan Weitzel (2): omap4: board-omap4panda: prepare for join omap4: board-omap4pcm049: add Phytec phyCORE-OMAP4 arch/arm/mach-omap2/Kconfig |6 + arch/arm/mach-omap2/Makefile |5 + arch/arm/mach-omap2/board-omap4panda-common.c | 380 ++ arch/arm/mach-omap2/board-omap4panda-common.h | 39 +++ arch/arm/mach-omap2/board-omap4panda.c| 421 + arch/arm/mach-omap2/board-omap4pcm049.c | 368 + arch/arm/plat-omap/include/plat/uncompress.h |1 + 7 files changed, 875 insertions(+), 345 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap4panda-common.c create mode 100644 arch/arm/mach-omap2/board-omap4panda-common.h create mode 100644 arch/arm/mach-omap2/board-omap4pcm049.c -- 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 1/2] omap4: board-omap4panda: prepare for join
Prepare board-omap4panda for joing other similar boards.
Split common stuff into board-omap4panda-common.
MUX: board_mux and omap4_panda_mux
omap4_common_preinit: for muxing
omap4_common_init: all common devices
struct panda_board_data: gpios, omap_board_data, i2c_board_info ...
some inititialisation check if omap4_panda_config entry is valid
i2c_2_board_speed == 0 - i2c_2 not used
hup_power_gpio == -EINVAL - gpio not used
Signed-off-by: Jan Weitzel j.weit...@phytec.de
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap4panda-common.c | 380 ++
arch/arm/mach-omap2/board-omap4panda-common.h | 39 +++
arch/arm/mach-omap2/board-omap4panda.c| 421 +
4 files changed, 496 insertions(+), 345 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap4panda-common.c
create mode 100644 arch/arm/mach-omap2/board-omap4panda-common.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 2d4d18e..5d829d6 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -237,6 +237,7 @@ obj-$(CONFIG_MACH_OMAP_4430SDP) +=
board-4430sdp.o \
hsmmc.o \
omap_phy_internal.o
obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o \
+ board-omap4panda-common.o \
hsmmc.o \
omap_phy_internal.o
diff --git a/arch/arm/mach-omap2/board-omap4panda-common.c
b/arch/arm/mach-omap2/board-omap4panda-common.c
new file mode 100644
index 000..bcf8776
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda-common.c
@@ -0,0 +1,380 @@
+/*
+ * Board support file for OMAP4430 based PandaBoard.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: David Anders x0132...@ti.com
+ *
+ * Based on mach-omap2/board-4430sdp.c
+ *
+ * Author: Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Based on mach-omap2/board-3430sdp.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/leds.h
+#include linux/gpio.h
+#include linux/usb/otg.h
+#include linux/i2c/twl.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include linux/wl12xx.h
+
+#include mach/hardware.h
+#include mach/omap4-common.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include video/omapdss.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/usb.h
+#include plat/mmc.h
+#include video/omap-panel-generic-dpi.h
+
+#include hsmmc.h
+#include control.h
+#include mux.h
+#include common-board-devices.h
+#include board-omap4panda-common.h
+
+struct panda_board_data *board_config;
+
+void omap4_common_hdmi_mux_init(void)
+{
+ /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
+ omap_mux_init_signal(hdmi_hpd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_cec,
+ OMAP_PIN_INPUT_PULLUP);
+ /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
+ omap_mux_init_signal(hdmi_ddc_scl,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_ddc_sda,
+ OMAP_PIN_INPUT_PULLUP);
+}
+
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ /* dispc2_data23 */
+ OMAP4_MUX(USBB2_ULPITLL_STP, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data22 */
+ OMAP4_MUX(USBB2_ULPITLL_DIR, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data21 */
+ OMAP4_MUX(USBB2_ULPITLL_NXT, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data20 */
+ OMAP4_MUX(USBB2_ULPITLL_DAT0, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data19 */
+ OMAP4_MUX(USBB2_ULPITLL_DAT1, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data18 */
+ OMAP4_MUX(USBB2_ULPITLL_DAT2, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data15 */
+ OMAP4_MUX(USBB2_ULPITLL_DAT3, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data14 */
+ OMAP4_MUX(USBB2_ULPITLL_DAT4, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data13 */
+ OMAP4_MUX(USBB2_ULPITLL_DAT5, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data12 */
+ OMAP4_MUX(USBB2_ULPITLL_DAT6, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data11 */
+ OMAP4_MUX(USBB2_ULPITLL_DAT7, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data10 */
+ OMAP4_MUX(DPM_EMU3, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data9 */
+ OMAP4_MUX(DPM_EMU4, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+ /* dispc2_data16 */
+
[RFC 2/2] omap4: board-omap4pcm049: add Phytec phyCORE-OMAP4
Adds support for the Phytec OMAP4430 board called phyCORE-OMAP4 PCM049.
Signed-off-by: Jan Weitzel j.weit...@phytec.de
---
arch/arm/mach-omap2/Kconfig |6 +
arch/arm/mach-omap2/Makefile |4 +
arch/arm/mach-omap2/board-omap4pcm049.c | 368 ++
arch/arm/plat-omap/include/plat/uncompress.h |1 +
4 files changed, 379 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap4pcm049.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 6b88799..d5e4b60 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -333,6 +333,12 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE
+config MACH_PCM049
+ bool OMAP4 based phyCORE OMAP4
+ depends on ARCH_OMAP4
+ default y
+ select OMAP_PACKAGE_CBS
+
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d829d6..6cc4ccb 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -240,6 +240,10 @@ obj-$(CONFIG_MACH_OMAP4_PANDA) +=
board-omap4panda.o \
board-omap4panda-common.o \
hsmmc.o \
omap_phy_internal.o
+obj-$(CONFIG_MACH_MACH_PCM049) += board-pcm049.o \
+ board-omap4panda-common.o \
+ hsmmc.o \
+ omap_phy_internal.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \
omap_phy_internal.o \
diff --git a/arch/arm/mach-omap2/board-omap4pcm049.c
b/arch/arm/mach-omap2/board-omap4pcm049.c
new file mode 100644
index 000..117334e
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4pcm049.c
@@ -0,0 +1,368 @@
+/*
+ * Board support file for Phytec phyCORE-OMAP4 Board.
+ *
+ * Copyright (C) 2011 Phytec Messtechnik GmbH
+ *
+ * Author: Jan Weitzel armli...@phytec.de
+ *
+ * Based on mach-omap2/board-omap4panda.c
+ *
+ * Author: David Anders x0132...@ti.com
+ *
+ * Author: Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/leds.h
+#include linux/gpio.h
+#include linux/usb/otg.h
+#include linux/i2c/twl.h
+#include linux/i2c/at24.h
+#include linux/mfd/stmpe.h
+#include linux/leds-pca9532.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include linux/wl12xx.h
+#include linux/smsc911x.h
+
+#include mach/hardware.h
+#include mach/omap4-common.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include video/omapdss.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/usb.h
+#include plat/gpmc.h
+#include plat/gpmc-smsc911x.h
+#include plat/mmc.h
+#include video/omap-panel-generic-dpi.h
+
+#include hsmmc.h
+#include control.h
+#include mux.h
+#include common-board-devices.h
+#include board-omap4panda-common.h
+
+#define OMAP4_PCM049_ETH_GPIO_IRQ 121
+#define OMAP4_PCM049_ETH_CS5
+#define OMAP4_PCM049_STMPE811_GPIO_IRQ 117
+#define OMAP4_PCM049_LCD_ENABLE118
+
+/* phyCORE OMAP4 */
+#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
+static struct omap_smsc911x_platform_data __initdata board_smsc911x_data = {
+ .cs = OMAP4_PCM049_ETH_CS,
+ .gpio_irq = OMAP4_PCM049_ETH_GPIO_IRQ,
+ .gpio_reset = -EINVAL,
+ .flags = SMSC911X_USE_16BIT,
+};
+
+static inline void __init pcm049_init_smsc911x(void)
+{
+ omap_mux_init_gpio(OMAP4_PCM049_ETH_GPIO_IRQ, OMAP_PIN_INPUT);
+ gpmc_smsc911x_init(board_smsc911x_data);
+}
+#else
+static inline void __init pcm049_init_smsc911x(void) { return; }
+#endif
+
+/* Fixed regulator for max1027 */
+static struct regulator_consumer_supply pcm049_vcc_3v3_consumer_supply[] = {
+ REGULATOR_SUPPLY(vcc, 4-0064),
+};
+
+struct regulator_init_data pcm049_vcc_3v3_initdata = {
+ .consumer_supplies = pcm049_vcc_3v3_consumer_supply,
+ .num_consumer_supplies = ARRAY_SIZE(pcm049_vcc_3v3_consumer_supply),
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+};
+
+static struct fixed_voltage_config pcm049_vcc_3v3_config = {
+ .supply_name= pcm049_vcc_3v3,
+ .microvolts = 330,
+ .gpio = -EINVAL,
+ .enabled_at_boot= 1,
+ .init_data =
Re: conflicts between omap/cleanup branch and omap_dss2 tree
Hi, On Monday 18 July 2011 01:38 PM, Tony Lindgren wrote: * Arnd Bergmanna...@arndb.de [110717 14:36]: Hi Paul and Tomi, I'm trying to get the arm-soc tree integrated into linux-next, but right now that fails because of lots of conflicts in the arch/arm/mach-omap2/clock44xx_data.c and arch/arm/mach-omap2/omap_hwmod_44xx_data.c files. I've done a dumb resolution by pulling in the omap_dss2/for_next tree as a depedency and taking Tomi's version of the files, which is probably wrong but lets Stephen at least take the arm-soc tree. Yes that's the wrong way around for these files.. Please fix this properly in either the omap or the omap_dss2 trees. The clock and hwmod data patches should get queued by Benoit and Paul, so I'm suspecting these are some of Tomi's patches still in development. Tomi can you please check what you have in for-next? Tomi is on vacation right now, but he checks his mail once in a while, so we may get a response soon. Tomi's for-next branch is not up to date yet. So it shouldn't be considered for now. The HWMOD patches in Tomi's for-next branch will be pushed by Paul as 3.1-rc fixes. We will make a temporary branch which will contain all the DSS2 patches which Tomi intended to push for this merge window, once he gets a chance, he can quickly update his for-next branch with it. Archit Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: conflicts between omap/cleanup branch and omap_dss2 tree
On Tuesday 19 July 2011, Archit Taneja wrote: Tomi is on vacation right now, but he checks his mail once in a while, so we may get a response soon. Tomi's for-next branch is not up to date yet. So it shouldn't be considered for now. The HWMOD patches in Tomi's for-next branch will be pushed by Paul as 3.1-rc fixes. We will make a temporary branch which will contain all the DSS2 patches which Tomi intended to push for this merge window, once he gets a chance, he can quickly update his for-next branch with it. Ok, just let me know when you upload that branch so I can remove the dependency from the arm-soc tree. Right now, I'm pulling the omap_dss2/for_next branch into arm-soc/for_next as a dependency to resolve the conflict. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHV2] OMAP4: OPP: add OMAP4460 definitions
Kevin/Paul,
I see that this patch is not queued for 3.1 merge window. Any
issues/comments on this patch?
Vishwa
-Original Message-
From: Vishwanath BS [mailto:vishwanath...@ti.com]
Sent: Monday, July 04, 2011 11:11 AM
To: linux-omap@vger.kernel.org
Cc: Vishwanath BS; Nishanth Menon
Subject: [PATCHV2] OMAP4: OPP: add OMAP4460 definitions
Add OMAP4460 OPP definitions for voltage and frequencies based on
OMAP4460 ES1.0 DM Operating Condition Addendum Version 0.1
The following exceptions are present:
* Smartreflex support is still on experimental mode: the gains and
min
limits are currently pending characterization data. Currently
OMAP4430 values
are used.
* Efuse offset for core OPP100-OV setting is not clear in
documentation.
* IVA OPPs beyond OPP100 are disabled due to the delta between max
OMAP4460
current requirements and Phoenix Max supply on VCORE2 in the
default
configuration - boards which have supply which can support this
should
explicitly call opp_enable and enable the same.
* MPU OPPs OPPTURBO can easily be detected using a efuse burnt -
currently
disabled pending clock changes to support DCC feature.
[n...@ti.com: cleanups and updates from Datamanual]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
Patch is generated against Patch series [PATCH v2 0/6] OMAP4: Add
4460 base
support from Rajendra and boot tested on 4460 and 4430 SDP.
Changes in V2: Updated the commit log as per Nishant's comments
arch/arm/mach-omap2/control.h |1 +
arch/arm/mach-omap2/omap_opp_data.h |9 ++-
arch/arm/mach-omap2/opp4xxx_data.c| 96
++---
arch/arm/mach-omap2/voltagedomains44xx_data.c | 14 +++-
4 files changed, 105 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-
omap2/control.h
index a016c8b..a41b9a7 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -195,6 +195,7 @@
#define OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO 0x249
#define OMAP44XX_CONTROL_FUSE_CORE_OPP50 0x254
#define OMAP44XX_CONTROL_FUSE_CORE_OPP1000x257
+#define OMAP44XX_CONTROL_FUSE_CORE_OPP100OV 0x25A
/* AM35XX only CONTROL_GENERAL register offsets */
#define AM35XX_CONTROL_MSUSPENDMUX_6(OMAP2_CONTROL_GENERAL +
0x0038)
diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach-
omap2/omap_opp_data.h
index c784c12..18a750e 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -89,8 +89,11 @@ extern struct omap_volt_data
omap34xx_vddcore_volt_data[];
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
extern struct omap_volt_data omap36xx_vddcore_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
+extern struct omap_volt_data omap443x_vdd_mpu_volt_data[];
+extern struct omap_volt_data omap443x_vdd_iva_volt_data[];
+extern struct omap_volt_data omap443x_vdd_core_volt_data[];
+extern struct omap_volt_data omap446x_vdd_mpu_volt_data[];
+extern struct omap_volt_data omap446x_vdd_iva_volt_data[];
+extern struct omap_volt_data omap446x_vdd_core_volt_data[];
#endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-
omap2/opp4xxx_data.c
index 2293ba2..8c285e4 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -1,7 +1,7 @@
/*
* OMAP4 OPP table definitions.
*
- * Copyright (C) 2010 Texas Instruments Incorporated -
http://www.ti.com/
+ * Copyright (C) 2010-2011 Texas Instruments Incorporated -
http://www.ti.com/
* Nishanth Menon
* Kevin Hilman
* Thara Gopinath
@@ -36,7 +36,7 @@
#define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000
#define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000
-struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
+struct omap_volt_data omap443x_vdd_mpu_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP50_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP100_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPP100, 0xf9, 0x16),
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPPTURBO_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, 0xfa, 0x23),
@@ -48,7 +48,7 @@ struct omap_volt_data omap44xx_vdd_mpu_volt_data[]
= {
#define OMAP4430_VDD_IVA_OPP100_UV 1188000
#define OMAP4430_VDD_IVA_OPPTURBO_UV 130
-struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
+struct omap_volt_data omap443x_vdd_iva_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP50_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPP50, 0xf4, 0x0c),
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP100_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPP100, 0xf9, 0x16),
[PATCH] arm: omap: usb: clock enable typo fix in usbhs driver
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs_disable function was invoking clk_enable api
instead of clk_disable; The clk_disable is called to
disble the port clocks of usbhs
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/mfd/omap-usb-host.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 1717144..29601e7 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -998,9 +998,9 @@ static void usbhs_disable(struct device *dev)
if (is_omap_usbhs_rev2(omap)) {
if (is_ehci_tll_mode(pdata-port_mode[0]))
- clk_enable(omap-usbtll_p1_fck);
+ clk_disable(omap-usbtll_p1_fck);
if (is_ehci_tll_mode(pdata-port_mode[1]))
- clk_enable(omap-usbtll_p2_fck);
+ clk_disable(omap-usbtll_p2_fck);
clk_disable(omap-utmi_p2_fck);
clk_disable(omap-utmi_p1_fck);
}
--
1.6.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: [PATCHV2] OMAP4: OPP: add OMAP4460 definitions
Vishwanath Sripathy vishwanath...@ti.com writes: I see that this patch is not queued for 3.1 merge window. Any issues/comments on this patch? I did not look at this patch as it came late in the development cycle. A quick glance now suggests it has a few minor problems. - patch was not Cc's to linux-arm-kernel - uses 44XX naming which is not used in l-o master Please update against current l-o tree which has the PRCM/hwmod updates from Paul/Benoit as well as the base 4460 support for v3.1. 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 v3] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
Vikram Pandita vikram.pand...@ti.com writes: From: Anand Gadiyar gadi...@ti.com This patch enables the DMA mode1 RX support. This feature is enabled based on the short_not_ok flag passed from gadget drivers. This will result in a thruput performance gain of around 40% for USB mass-storage/mtp use cases. Signed-off-by: Anand Gadiyar gadi...@ti.com Signed-off-by: Moiz Sonasath m-sonas...@ti.com Tested-by: Vikram Pandita vikram.pand...@ti.com As you are on the delivery path now, it also needs your signoff. 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: [PATCHv3 3/6] regulator: omap smps regulator driver
On Mon, Jul 18, 2011 at 08:35:19PM +0300, Tero Kristo wrote: OMAP SMPS regulator driver provides access to OMAP voltage processor controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and additionally VDD_IVA for OMAP4. SMPS regulators use the OMAP voltage layer for the actual voltage regulation operations. +config REGULATOR_OMAP_SMPS + tristate TI OMAP SMPS Power Regulators + depends on (ARCH_OMAP3 || ARCH_OMAP4) PM TWL4030_CORE Why does this depend on TWL4030_CORE or PM? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 3/6] regulator: omap smps regulator driver
On Tue, 2011-07-19 at 17:38 +0200, Mark Brown wrote: On Mon, Jul 18, 2011 at 08:35:19PM +0300, Tero Kristo wrote: OMAP SMPS regulator driver provides access to OMAP voltage processor controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and additionally VDD_IVA for OMAP4. SMPS regulators use the OMAP voltage layer for the actual voltage regulation operations. +config REGULATOR_OMAP_SMPS + tristate TI OMAP SMPS Power Regulators + depends on (ARCH_OMAP3 || ARCH_OMAP4) PM TWL4030_CORE Why does this depend on TWL4030_CORE or PM? Oh forgot that one, TWL_CORE can be removed, PM must be there because the depending libraries are only built when PM is enabled. Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- 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/4] dt: omap3: add generic board file for dt support
On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: * Grant Likely grant.lik...@secretlab.ca [110716 22:08]: The way I see it, you've got two options: 1) modify the of_platform_bus_create() to call some kind of of_platform_bus_create_omap() for devices that match ti,omap3-device or something. 2) Leave of_platform_bus_create(), and instead us a notifier to attach hwmod data to normal platform devices. omap_device_build() is actually pretty simple. It allocated a device, it attaches platform_data and hwmod pointers to the device and registers it. omap_device_register() is just a wrapper around platform_device_register(). My preference is definitely #2, but there is a wrinkle in this approach. Unfortunately omap_devices are not simply plain platform_devices with extra data attached, an omap_device actually embeds the platform_device inside it, which cannot be attached after the fact. I think I had talked with Kevin (cc'd) about eliminating the embedding, but I cannot remember clearly on this point. As long as platform_device remains embedded inside struct omap_device, #2 won't work. In either case, looking up the correct hwmod data should be easy for any device provided the omap code maintains a lookup table of compatible strings and base addresses of devices (much like auxdata). In fact, I'd be okay with extending auxdata to include OMAP fields if that would be easiest since the whole point of auxdata is to ease the transition to DT support. When a matching device is created, the hwmod pointer can easily be attached. This should work transparently for all omap devices, not just the i2c bus. Well we should be able to automgagically build the omap_device for each device tree entry. And then the device driver probe and runtime PM should be able to take care of the rest for the driver. And then there's no more driver specific platform init code needed ;) Right! That's the solution I'd like to see. How about if we just have the hwmod code call omap_device_build for each device tree entry? I think that is pretty much equivalent to suggestion #1 above, only I'm suggesting to take advantage of the infrastructure already available in driver/of/platform.c in the form of of_platform_populate(). The of_platform_bus_create_omap() function suggested above I assumed would directly call omap_device_build(). There are already hooks in the _populate call path to handle the creation of amba_devices. I have no problem doing the same thing for omap devices. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
On Mon, Jul 18, 2011 at 03:45:57PM +0530, G, Manjunath Kondaiah wrote:
Hi Grant,
On 17 July 2011 10:43, Grant Likely grant.lik...@secretlab.ca wrote:
Hi Manjunath,
Comments below. I left in a lot of context for the new folks that
I've cc'd (Tony and Kevin).
On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah manj...@ti.com
wrote:
On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
+static void __init omap3_init(void)
+{
+ struct device_node *node;
+
[...]
+static struct omap_device *of_omap_i2c_device_create(struct device_node
*node,
+ const char *bus_id,
+ void *platform_data,
+ struct device *parent)
+{
+ struct platform_device *pdev;
+ struct i2c_board_info *i2c_board_info;
+ u8 id;
+
+ printk(Creating omap i2c device %s\n, node-full_name);
+
+ if (!of_device_is_available(node))
+ return NULL;
+
+ id = simple_strtol(bus_id, NULL, 0);
+ pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
+ pdev-dev.of_node = of_node_get(node);
+ if (!pdev-dev.of_node) {
+ speed = 100;
+ } else {
+ u32 prop;
+ if (!of_property_read_u32(pdev-dev.of_node,
clock-frequency,
+
prop))
+ speed = prop/100;
+ else
+ speed = 100;
+ }
+ printk(%s : speed-%d\n,__func__, speed);
+
+ for_each_child_of_node(bus, child) {
+ u32 prop;
+
+ printk( create child: %s\n, child-full_name);
+ i2c_board_info = kzalloc(sizeof(*i2c_board_info),
GFP_KERNEL);
+ if (!of_property_read_u32(pdev-dev.of_node, reg,
+ prop))
+ i2c_board_info-addr = prop;
+ if (!of_property_read_u32(pdev-dev.of_node, interrupts,
+ prop))
+ i2c_board_info-irq = prop;
+ i2c_board_info-platform_data = platform_data;
+ strncpy(i2c_board_info-type, child-name,
+ sizeof(i2c_board_info-type));
+ }
+ omap_register_i2c_bus(id, speed, i2c_board_info, 1);
While this does in a sense work, and creates an omap_device for the
i2c bus that does get probed, it ends up encoding an awful lot of
device specific details into the generic devicetree support code. The
i2c bus driver itself must be responsible for decoding the speed and
child nodes, and in fact it can easily be modified to do so (I've
Decoding speed in i2c driver seems to be fine. But the i2c child nodes are
board specific. We might bring board specific handling code into i2c driver
with this approach.
It shouldn't. They're just i2c devices, and the child nodes will
always follow the i2c device binding.
BTW, I have observed that, if we create i2c device node in omapx-soc.dtsi
file and the define i2c bus clock-frequency in beagle.dts, the clock-frequency
is not available in driver probe. Is this expected behavior?
No, it sounds like something isn't getting set up correctly. Send me
your current beagle.dts and omap3-soc.dtsi files.
g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
On Tue, Jul 19, 2011 at 11:28:53AM +0530, G, Manjunath Kondaiah wrote:
Grant/Kevin,
On Sun, Jul 17, 2011 at 10:43 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
Hi Manjunath,
Comments below. I left in a lot of context for the new folks that
I've cc'd (Tony and Kevin).
On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah manj...@ti.com
wrote:
On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
+static void __init omap3_init(void)
+{
[...]
+ omap_register_i2c_bus(id, speed, i2c_board_info, 1);
While this does in a sense work, and creates an omap_device for the
i2c bus that does get probed, it ends up encoding an awful lot of
device specific details into the generic devicetree support code. The
i2c bus driver itself must be responsible for decoding the speed and
child nodes, and in fact it can easily be modified to do so (I've
already demonstrated how to do so). The real problem is making sure
the platform_device is created in a way that attaches the correct
hwmod data. For this context, the current omap_register_i2c_bus()
isn't a useful method for doing so.
So what is to be done? omap_register_i2c_bus() does three things;
1) register an i2c board info for the bus with i2c_register_board_info(),
2) fill platform_data for the device, and
3) use omap_i2c_add_bus to create the platform_device with attached hwmod.
Of these three, 1 2 must not be done when using the DT. Only
omap_i2c_add_bus() does something useful, but that is still specific
to the i2c device.
omap_i2c_add_bus() splits to omap{1,2}_add_bus().
omap1_i2c_add_bus() sets up pinmux and calls platform_device register.
pinmux setup needs to be factored out anyway for generic DT platform
device registration, which just leaves platform_device creation which
is already handled by of_platform_populate().
omap2_i2c_add_bus() does the same thing, except it also looks up the
hwmod data (*oh) and uses it to call omap_device_build().
omap_device_build() or something equivalent needs to be called for
every omap device in the system, which is to create platform_devices
with hwmod attached. Now we're starting to hit generic code. :-)
The way I see it, you've got two options:
1) modify the of_platform_bus_create() to call some kind of
of_platform_bus_create_omap() for devices that match ti,omap3-device
or something.
2) Leave of_platform_bus_create(), and instead us a notifier to attach
hwmod data to normal platform devices. omap_device_build() is
actually pretty simple. It allocated a device, it attaches
platform_data and hwmod pointers to the device and registers it.
omap_device_register() is just a wrapper around
platform_device_register().
My preference is definitely #2, but there is a wrinkle in this
approach. Unfortunately omap_devices are not simply plain
platform_devices with extra data attached, an omap_device actually
embeds the platform_device inside it, which cannot be attached after
the fact. I think I had talked with Kevin (cc'd) about eliminating
the embedding, but I cannot remember clearly on this point. As long
as platform_device remains embedded inside struct omap_device, #2
won't work.
Can you please elaborate more on this issue?
Look at the of_platform_populate() call path (in devicetree/next) and
see how it handles amba devices. Do the same thing for omap_devices.
g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: Nand: use MTD_NAND_OMAP2 for OMAP4
On Fri, 2011-07-15 at 12:52 +0200, Jan Weitzel wrote: config MTD_NAND_OMAP2 tristate NAND Flash device on OMAP2 and OMAP3 I guess you need to add OMAP4 to the string above as well. - depends on ARM (ARCH_OMAP2 || ARCH_OMAP3) + depends on ARM (ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4) help - Support for NAND flash on Texas Instruments OMAP2 and OMAP3 platforms. + Support for NAND flash on Texas Instruments OMAP2, OMAP3 and OMAP4 + platforms. -- Best Regards, Artem Bityutskiy -- 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] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
From: Anand Gadiyar gadi...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Tested-by: Vikram Pandita vikram.pand...@ti.com
---
v1 - initial push
v2 - fixed whitespace issues as per Sergei Shtylyovsshtyl...@mvista.com
comments
v3 - restor authorship to Anand Gadiyar gadi...@ti.com
v4 - adding my signed-off as per Kevin Hilman khil...@ti.com
drivers/usb/musb/musb_gadget.c | 68 ---
1 files changed, 42 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6aeb363..4a1432e 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -634,6 +634,7 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
u16 len;
u16 csr = musb_readw(epio, MUSB_RXCSR);
struct musb_hw_ep *hw_ep = musb-endpoints[epnum];
+ u8 use_mode_1;
if (hw_ep-is_shared_fifo)
musb_ep = hw_ep-ep_in;
@@ -683,6 +684,18 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
if (csr MUSB_RXCSR_RXPKTRDY) {
len = musb_readw(epio, MUSB_RXCOUNT);
+
+ /*
+* Enable Mode 1 for RX transfers only for mass-storage
+* use-case, based on short_not_ok flag which is set only
+* from file_storage and f_mass_storage drivers
+*/
+
+ if (request-short_not_ok len == musb_ep-packet_sz)
+ use_mode_1 = 1;
+ else
+ use_mode_1 = 0;
+
if (request-actual request-length) {
#ifdef CONFIG_USB_INVENTRA_DMA
if (is_buffer_mapped(req)) {
@@ -714,37 +727,40 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
* then becomes usable as a runtime use mode 1 hint...
*/
- csr |= MUSB_RXCSR_DMAENAB;
-#ifdef USE_MODE1
- csr |= MUSB_RXCSR_AUTOCLEAR;
- /* csr |= MUSB_RXCSR_DMAMODE; */
-
- /* this special sequence (enabling and then
-* disabling MUSB_RXCSR_DMAMODE) is required
-* to get DMAReq to activate
-*/
- musb_writew(epio, MUSB_RXCSR,
- csr | MUSB_RXCSR_DMAMODE);
-#else
- if (!musb_ep-hb_mult
- musb_ep-hw_ep-rx_double_buffered)
+ /* Experimental: Mode1 works with mass storage
use cases */
+ if (use_mode_1) {
csr |= MUSB_RXCSR_AUTOCLEAR;
-#endif
- musb_writew(epio, MUSB_RXCSR, csr);
+ musb_writew(epio, MUSB_RXCSR, csr);
+ csr |= MUSB_RXCSR_DMAENAB;
+ musb_writew(epio, MUSB_RXCSR, csr);
+
+ /* this special sequence (enabling and
then
+ * disabling MUSB_RXCSR_DMAMODE) is
required
+ * to get DMAReq to activate
+ */
+ musb_writew(epio, MUSB_RXCSR,
+ csr | MUSB_RXCSR_DMAMODE);
+ musb_writew(epio, MUSB_RXCSR, csr);
+
+ } else {
+ if (!musb_ep-hb_mult
+
musb_ep-hw_ep-rx_double_buffered)
+ csr |= MUSB_RXCSR_AUTOCLEAR;
+ csr |= MUSB_RXCSR_DMAENAB;
+ musb_writew(epio, MUSB_RXCSR, csr);
+ }
if (request-actual request-length) {
int transfer_size = 0;
-#ifdef USE_MODE1
- transfer_size = min(request-length -
request-actual,
- channel-max_len);
-#else
- transfer_size = min(request-length -
request-actual,
- (unsigned)len);
-#endif
- if
Re: [PATCH v4] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Wed, Jul 20, 2011 at 10:41 AM, Vikram Pandita vikram.pand...@ti.com wrote:
From: Anand Gadiyar gadi...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Tested-by: Vikram Pandita vikram.pand...@ti.com
---
v1 - initial push
v2 - fixed whitespace issues as per Sergei Shtylyovsshtyl...@mvista.com
comments
v3 - restor authorship to Anand Gadiyar gadi...@ti.com
v4 - adding my signed-off as per Kevin Hilman khil...@ti.com
drivers/usb/musb/musb_gadget.c | 68 ---
1 files changed, 42 insertions(+), 26 deletions(-)
@@ -683,6 +684,18 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
if (csr MUSB_RXCSR_RXPKTRDY) {
len = musb_readw(epio, MUSB_RXCOUNT);
+
+ /*
+ * Enable Mode 1 for RX transfers only for mass-storage
+ * use-case, based on short_not_ok flag which is set only
+ * from file_storage and f_mass_storage drivers
+ */
+
+ if (request-short_not_ok len == musb_ep-packet_sz)
+ use_mode_1 = 1;
+ else
+ use_mode_1 = 0;
+
There is nothing UMS class specific in this patch...
(request-short_not_ok len == musb_ep-packet_sz) may not be the
signature of, and only of, Mass Storage Functions. So maybe removing
the UMS mention from
comment and change-log is a good idea.
You might want to add is-ep-type-bulk-out check to the condition
though, so that it doesn't affect
cases that you didn't verify.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Tue, Jul 19, 2011 at 10:34 PM, Jassi Brar jassisinghb...@gmail.com wrote:
On Wed, Jul 20, 2011 at 10:41 AM, Vikram Pandita vikram.pand...@ti.com
wrote:
From: Anand Gadiyar gadi...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Tested-by: Vikram Pandita vikram.pand...@ti.com
---
v1 - initial push
v2 - fixed whitespace issues as per Sergei Shtylyovsshtyl...@mvista.com
comments
v3 - restor authorship to Anand Gadiyar gadi...@ti.com
v4 - adding my signed-off as per Kevin Hilman khil...@ti.com
drivers/usb/musb/musb_gadget.c | 68
---
1 files changed, 42 insertions(+), 26 deletions(-)
@@ -683,6 +684,18 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
if (csr MUSB_RXCSR_RXPKTRDY) {
len = musb_readw(epio, MUSB_RXCOUNT);
+
+ /*
+ * Enable Mode 1 for RX transfers only for mass-storage
+ * use-case, based on short_not_ok flag which is set only
+ * from file_storage and f_mass_storage drivers
+ */
+
+ if (request-short_not_ok len == musb_ep-packet_sz)
+ use_mode_1 = 1;
+ else
+ use_mode_1 = 0;
+
There is nothing UMS class specific in this patch...
(request-short_not_ok len == musb_ep-packet_sz) may not be the
signature of, and only of, Mass Storage Functions. So maybe removing
the UMS mention from
comment and change-log is a good idea.
Have you grepped the code in drivers/usb/gadget/*.*
only UMS sets this flag today and hence the use of this flag.
As i understand, on UMS, CSW/data/CBW - the data part size is a known
size and to be safe that mode=1 dma is not stuck up,
the mode is enabled only for the gadget driver that sets short_not_ok
flag - and that today happens to be only UMS.
You might want to add is-ep-type-bulk-out check to the condition
though, so that it doesn't affect
cases that you didn't verify.
TX path (IN host), already uses the mode=1 DMA and hence the comment
is not valid.
This patch just also enables mode=1 on RX path.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Wed, Jul 20, 2011 at 11:15 AM, Pandita, Vikram vikram.pand...@ti.com wrote:
On Tue, Jul 19, 2011 at 10:34 PM, Jassi Brar jassisinghb...@gmail.com wrote:
On Wed, Jul 20, 2011 at 10:41 AM, Vikram Pandita vikram.pand...@ti.com
wrote:
From: Anand Gadiyar gadi...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Tested-by: Vikram Pandita vikram.pand...@ti.com
---
v1 - initial push
v2 - fixed whitespace issues as per Sergei Shtylyovsshtyl...@mvista.com
comments
v3 - restor authorship to Anand Gadiyar gadi...@ti.com
v4 - adding my signed-off as per Kevin Hilman khil...@ti.com
drivers/usb/musb/musb_gadget.c | 68
---
1 files changed, 42 insertions(+), 26 deletions(-)
@@ -683,6 +684,18 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
if (csr MUSB_RXCSR_RXPKTRDY) {
len = musb_readw(epio, MUSB_RXCOUNT);
+
+ /*
+ * Enable Mode 1 for RX transfers only for mass-storage
+ * use-case, based on short_not_ok flag which is set only
+ * from file_storage and f_mass_storage drivers
+ */
+
+ if (request-short_not_ok len == musb_ep-packet_sz)
+ use_mode_1 = 1;
+ else
+ use_mode_1 = 0;
+
There is nothing UMS class specific in this patch...
(request-short_not_ok len == musb_ep-packet_sz) may not be the
signature of, and only of, Mass Storage Functions. So maybe removing
the UMS mention from
comment and change-log is a good idea.
Have you grepped the code in drivers/usb/gadget/*.*
only UMS sets this flag today and hence the use of this flag.
As i understand, on UMS, CSW/data/CBW - the data part size is a known
size and to be safe that mode=1 dma is not stuck up,
the mode is enabled only for the gadget driver that sets short_not_ok
flag - and that today happens to be only UMS.
This *today happens to be only UMS* is my exact point here.
Can you guarantee no other function driver will ever expect only
full packet xfers and treat short as errors ?
You might want to add is-ep-type-bulk-out check to the condition
though, so that it doesn't affect
cases that you didn't verify.
TX path (IN host), already uses the mode=1 DMA and hence the comment
is not valid.
This patch just also enables mode=1 on RX path.
Well, then no need for the ep-type check.
--
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
