Re: [PATCH 02/10] crypto: omap-aes: Add useful debug macros
On 15/08/13 06:12, Joel Fernandes wrote:
On 08/14/2013 07:47 PM, Joe Perches wrote:
On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
On 08/14/2013 06:29 PM, Joe Perches wrote:
On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
When DEBUG is enabled, these macros can be used to print variables
in integer and hex format, and clearly display which registers,
offsets and values are being read/written , including printing the
names of the offsets and their values.
[]
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
[]
@@ -15,6 +15,14 @@
#define pr_fmt(fmt) %s: fmt, __func__
+#ifdef DEBUG
+#define prn(num) printk(#num =%d\n, num)
+#define prx(num) printk(#num =%x\n, num)
pr_debug?
Sure, can change that.
+#else
+#define prn(num) do { } while (0)
+#define prx(num) do { } while (0)
+#endif
[]
@@ -172,13 +180,35 @@ struct omap_aes_dev {
static LIST_HEAD(dev_list);
static DEFINE_SPINLOCK(list_lock);
+#ifdef DEBUG
+#define omap_aes_read(dd, offset)
\
+ do {\
+ omap_aes_read_1(dd, offset);\
+ pr_debug(omap_aes_read( #offset )\n); \
+ } while (0)
+
+static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
+#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
+#endif
{
return __raw_readl(dd-io_base + offset);
}
+#ifdef DEBUG
+#define omap_aes_write(dd, offset, value)
\
+ do {\
+ pr_debug(omap_aes_write( #offset =%x) value=%d\n, \
+ offset, value);\
+ omap_aes_write_1(dd, offset, value);\
+ } while (0)
+
+static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
+ u32 value)
+#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
+#endif
{
__raw_writel(value, dd-io_base + offset);
}
Umm, yuck?
Is there any real value in read_1 and write_1?
Can you be more descriptive? There is a lot of value in them for debug
to show clearly sequence of read/writes. Moreover, they are no-op'd when
DEBUG is disabled.
pr_debug is no-op'd when DEBUG is not #defined.
so just use a single
omap_aes_write(...)
{
pr_debug(...)
__raw_writel(...);
}
Actually this doesn't work, as the pr_debug cannot print the name of the
offset as my original patch set does using #offset.
There are many places where named offsets are used to pass to
read/write, and this macro helps to visually see which offset is being
written to by name.
So the original patch would stand in its current form except for a small
rewrite of the write debug part of it as follows to be cleaner getting
rid of the _1. For the read , we still need it as we need to return the
value from a function which cannot be done in a macro.
So the new patch would look something like this:
#ifdef DEBUG
#define omap_aes_read(dd, offset) \
omap_aes_read_1(dd, offset); \
pr_debug(omap_aes_read( #offset )\n);
static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
#endif
{
return __raw_readl(dd-io_base + offset);
}
Bellow version write looks much more readable - never re-define
function signature by macro.
Above should be similar as well...
#ifdef DEBUG
#define omap_aes_write(dd, offset, value) \
do { \
pr_debug(omap_aes_write( #offset =%x) value=%d\n, \
offset, value); \
__raw_writel(value, dd-io_base + offset); \
} while (0)
#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
{
__raw_writel(value, dd-io_base + offset);
}
#endif
Thanks,
-Joel
--
To unsubscribe from this list: send the line unsubscribe linux-crypto 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: [PATCH 00/10] crypto: omap-aes: DMA and PIO mode improvements
On 08/15/2013 12:58 AM, Dmitry Kasatkin wrote: On 15/08/13 02:30, Joel Fernandes wrote: On 08/14/2013 06:12 PM, Joel Fernandes wrote: This patch series is a rewrite of the DMA portion of omap-aes driver and also adds support for PIO mode. Both these modes, give better performance than before. Earlier, only a single SG was used for DMA purpose, and the SG-list passed from the crypto layer was being copied and DMA'd one entry at a time. This turns out to be quite inefficient, so we replace it with much simpler code that directly passes the SG-list from crypto to the DMA layer. We also add PIO mode support to the driver, and switch to PIO mode whenever the DMA channel allocation is not available. This is only for OMAP4 platform will work on any platform on which IRQ information is populated. Tests performed on am33xx and omap4 SoCs , notice the 50% perf improvement Just correcting, this is more like 35% not 50% when using DMA. Hmm :) 1766/1460 = ~20% Yes sorry, I messed the cover letter up. If I resend the series again, I'll update this number. On OMAP4 though, I saw 2800 ops/sec vs 1800 ops/sec which is around 50% so it depends on SoC and DMA controller. OMAP4 uses SDMA while AM335x uses EDMA. Also with very large blocks, this improvement will be much higher as we will not be doing all the intermediate copy but I haven't tested with such large blocks. Thanks, -Joel -- 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 02/10] crypto: omap-aes: Add useful debug macros
On 08/15/2013 01:23 AM, Dmitry Kasatkin wrote:
On 15/08/13 06:12, Joel Fernandes wrote:
On 08/14/2013 07:47 PM, Joe Perches wrote:
On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
On 08/14/2013 06:29 PM, Joe Perches wrote:
On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
When DEBUG is enabled, these macros can be used to print variables
in integer and hex format, and clearly display which registers,
offsets and values are being read/written , including printing the
names of the offsets and their values.
[]
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
[]
@@ -15,6 +15,14 @@
#define pr_fmt(fmt) %s: fmt, __func__
+#ifdef DEBUG
+#define prn(num) printk(#num =%d\n, num)
+#define prx(num) printk(#num =%x\n, num)
pr_debug?
Sure, can change that.
+#else
+#define prn(num) do { } while (0)
+#define prx(num) do { } while (0)
+#endif
[]
@@ -172,13 +180,35 @@ struct omap_aes_dev {
static LIST_HEAD(dev_list);
static DEFINE_SPINLOCK(list_lock);
+#ifdef DEBUG
+#define omap_aes_read(dd, offset)
\
+do {
\
+omap_aes_read_1(dd, offset);
\
+pr_debug(omap_aes_read( #offset )\n);
\
+} while (0)
+
+static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
+#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
+#endif
{
return __raw_readl(dd-io_base + offset);
}
+#ifdef DEBUG
+#define omap_aes_write(dd, offset, value)
\
+do {
\
+pr_debug(omap_aes_write( #offset =%x) value=%d\n,
\
+ offset, value);
\
+omap_aes_write_1(dd, offset, value);
\
+} while (0)
+
+static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
+ u32 value)
+#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
+#endif
{
__raw_writel(value, dd-io_base + offset);
}
Umm, yuck?
Is there any real value in read_1 and write_1?
Can you be more descriptive? There is a lot of value in them for debug
to show clearly sequence of read/writes. Moreover, they are no-op'd when
DEBUG is disabled.
pr_debug is no-op'd when DEBUG is not #defined.
so just use a single
omap_aes_write(...)
{
pr_debug(...)
__raw_writel(...);
}
Actually this doesn't work, as the pr_debug cannot print the name of the
offset as my original patch set does using #offset.
There are many places where named offsets are used to pass to
read/write, and this macro helps to visually see which offset is being
written to by name.
So the original patch would stand in its current form except for a small
rewrite of the write debug part of it as follows to be cleaner getting
rid of the _1. For the read , we still need it as we need to return the
value from a function which cannot be done in a macro.
So the new patch would look something like this:
#ifdef DEBUG
#define omap_aes_read(dd, offset) \
omap_aes_read_1(dd, offset); \
pr_debug(omap_aes_read( #offset )\n);
static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
#endif
{
return __raw_readl(dd-io_base + offset);
}
Bellow version write looks much more readable - never re-define
function signature by macro.
Above should be similar as well...
Yes, I'll write the read in the final version of this patch like the
write. Its certainly cleaner.
-Joel
#ifdef DEBUG
#define omap_aes_write(dd, offset, value) \
do { \
pr_debug(omap_aes_write( #offset =%x) value=%d\n, \
offset, value); \
__raw_writel(value, dd-io_base + offset); \
} while (0)
#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
{
__raw_writel(value, dd-io_base + offset);
}
#endif
Thanks,
-Joel
--
To unsubscribe from this list: send the line unsubscribe linux-crypto 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
dma_unmap causing issues with __get_free_pages
Hi, I'm having some trouble with using the dma_map/unmap API. On unmapping a particular page using dma_unmap, it seems that the PG_dcache_clean flag is set in the page-flags. This is set by the following statement in __dma_page_dev_to_cpu function in arch/arm/mm/dma-mapping.c set_bit(PG_dcache_clean, page-flags); Due to this, on any subsequent page allocations using __get_free_pages, the following BUG gets triggered. [ 15.267913] BUG: Bad page state in process insmod pfn:acb26 [ 15.274017] page:c151e4c0 count:0 mapcount:0 mapping: (null) index:0x0 [ 15.281097] page flags: 0x200(arch_1) [ 15.285003] Modules linked in: tcrypt(+) [ 15.289062] CPU: 0 PID: 1616 Comm: insmod Tainted: GB 3.10.0-00038-gbafd29d-dirty #89 [ 15.298706] [c001c720] (unwind_backtrace+0x0/0xfc) from [c0018794] (show_stack+0x20/0x24) [ 15.307861] [c0018794] (show_stack+0x20/0x24) from [c05a7284] (dump_stack+0x20/0x28) [ 15.316497] [c05a7284] (dump_stack+0x20/0x28) from [c00fa220] (bad_page+0xbc/0x11c) [ 15.325195] [c00fa220] (bad_page+0xbc/0x11c) from [c00fa8c8] (get_page_from_freelist+0x4dc/0x620) [ 15.335083] [c00fa8c8] (get_page_from_freelist+0x4dc/0x620) from [c00fb57c] (__alloc_pages_nodemask+0x114/0x8b4) [ 15.346343] [c00fb57c] (__alloc_pages_nodemask+0x114/0x8b4) from [c00fbd3c] (__get_free_pages+0x20/0x3c) [ 15.356872] [c00fbd3c] (__get_free_pages+0x20/0x3c) from [c0486bd0] (omap_aes_copy_sgs+0x48/0x1bc) If I don't do the unmap and leave the page alone, everything works just fine. What is correct way to fix this? Why does the page allocator think its a BAD page descriptor after the unmap? Thanks, -Joel -- 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] OMAP: serial: Remove incorrect disabling of IER interrupt
The recent patch to add RS485 contained a bug whereby the IER interrupt was cleared down incorrectly. This patch fixes the problem. Signed-off-by: Mark Jackson m...@newflow.co.uk --- drivers/tty/serial/omap-serial.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 2706c11..2fa7b5c 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1327,9 +1327,6 @@ serial_omap_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf) pm_runtime_get_sync(up-dev); spin_lock_irqsave(up-port.lock, flags); - up-ier = ~(UART_IER_RLSI | UART_IER_RDI); - serial_out(up, UART_IER, up-ier); - /* Disable interrupts from this port */ mode = up-ier; up-ier = 0; -- 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 v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
On Wed, 2013-08-14 at 15:21 -0700, Russ Dill wrote: The CM3 driver needs to figure out where the core regulator is connected using using either DT or the regulator framework and ask the TPS (via a new interface) for register writes for sleep/wake sequences. Then those sequences will actually match the correct voltages configured using DT/DVFS. That seems like it'd add a lot of complexity to the regulator subsystem, as well as all the PMIC and other I2C regulators that any users of these device tree properties may end up using for not a lot of gain. There would be two separate code paths for any used I2C regulator or PMIC for setting voltages. Yes, it would be additional complexity, but it would avoid duplicating information which is already in the DT (locationaddress of the PMIC, type of pmic) and in the kernel (how to program voltages for a given regulator). As DT is supposed to describe the hardware, duplicate information should be unnecessary. One different way to look at this is that the CM3 firmware is a separate consumer of the DT. DT being OS-indepentent, the CM3 firmware should be able to get all the information it needs from the DT (maybe with help from the CM3 driver). Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 v8 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On 08/15/13 06:45, Oleksandr Kozaruk wrote: Hello Jonathan, Thank you for the review and valuable comments. Multiple authors are done by having multiple MODULE_AUTHOR lines rather as one long string. See include/linux/module.h. I fixed that up and dealt with some trivial fuzz in the makefile/Kconfig. You might want to take advantage of devm_iio_allocate_device which has been introduced in the meantime and greatly simplifies error paths in IIO probe functions. Should I make new version of the patch, or just prepare a new patch that patches the patch? I've applied the current one with the MODULE_AUTHOR line broken up. If you want to do the devm_ patch then that will want to be as an additional patch on top of the togreg branch of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git Regards, Sasha. Anyhow, applied to the togreg branch of iio.git Note I haven't taken the device tree patch. For that I would need and ack from the relevant maintainer(s). Personally I'd rather not touch device tree files unless i have to due to the high chance of merge conflicts occuring. I would expect the subarch maintainer to pick that one up (or to ask me to ;) Nice relatively clean driver for a somewhat 'interesting' bit of hardware. Thanks Jonathan --- drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1027 +++ 3 files changed, 1042 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 93129ec..f8f9f18 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -160,6 +160,20 @@ config TI_AM335X_ADC Say yes here to build support for Texas Instruments ADC driver which is also a MFD client. +config TWL6030_GPADC + tristate TWL6030 GPADC (General Purpose A/D Converter) Support + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030/TWL6032 General + Purpose A/D Converter. This will add support for battery type + detection, battery voltage and temperature measurement, die + temperature measurement, system supply voltage, audio accessory, + USB ID detection. + + This driver can also be built as a module. If so, the module will be + called twl6030-gpadc. + config VIPERBOARD_ADC tristate Viperboard ADC support depends on MFD_VIPERBOARD USB diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 8f475d3..db430bd 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -17,4 +17,5 @@ obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_MCP320X) += mcp320x.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..2b63083 --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1027 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat nska...@ti.com mailto:nska...@ti.com + * Balaji T K balaj...@ti.com mailto:balaj...@ti.com + * Graeme Gregory g...@slimlogic.co.uk mailto:g...@slimlogic.co.uk + * Girish S Ghongdemath giris...@ti.com mailto:giris...@ti.com + * Ambresh K ambr...@ti.com mailto:ambr...@ti.com + * Oleksandr Kozaruk oleksandr.koza...@ti.com mailto:oleksandr.koza...@ti.com + * + * Based on twl4030-madc.c + * Copyright (C) 2008 Nokia Corporation + * Mikko Ylinen mikko.k.yli...@nokia.com mailto:mikko.k.yli...@nokia.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. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */
Re: [PATCH 2/9] usb: phy: nop: Don't use regulator framework for RESET line
On 08/14/2013 06:27 PM, Philipp Zabel wrote:
Hi Roger,
Am Mittwoch, den 14.08.2013, 16:58 +0300 schrieb Roger Quadros:
Modelling the RESET line as a regulator supply wasn't a good idea
as it kind of abuses the regulator framework and also makes adaptation
code more complex.
Instead, manage the RESET gpio line directly in the driver. Update
the device tree binding information.
This also makes us easy to migrate to a dedicated GPIO RESET controller
whenever it becomes available.
Signed-off-by: Roger Quadros rog...@ti.com
using the reset-gpios property
Acked-by: Philipp Zabel p.za...@pengutronix.de
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt |7 +--
drivers/usb/phy/phy-nop.c | 48
2 files changed, 32 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index d7e2726..5535f3b 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -15,7 +15,7 @@ Optional properties:
- vcc-supply: phandle to the regulator that provides RESET to the PHY.
-- reset-supply: phandle to the regulator that provides power to the PHY.
+- reset-gpios: Should specify the GPIO for reset.
Example:
@@ -25,10 +25,9 @@ Example:
clocks = osc 0;
clock-names = main_clk;
vcc-supply = hsusb1_vcc_regulator;
-reset-supply = hsusb1_reset_regulator;
+reset-gpios = gpio1 7;
Yes, although the example should probably include GPIO_ACTIVE_LOW or
GPIO_ACTIVE_HIGH flags.
OK.
};
hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
-hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
-controls RESET.
+hsusb1_vcc_regulator provides power to the PHY and GPIO 7 controls RESET.
diff --git a/drivers/usb/phy/phy-nop.c b/drivers/usb/phy/phy-nop.c
index 55445e5d..af5e1a6 100644
--- a/drivers/usb/phy/phy-nop.c
+++ b/drivers/usb/phy/phy-nop.c
@@ -35,6 +35,9 @@
#include linux/clk.h
#include linux/regulator/consumer.h
#include linux/of.h
+#include linux/of_gpio.h
+#include linux/gpio.h
+#include linux/delay.h
struct nop_usb_xceiv {
struct usb_phy phy;
@@ -42,6 +45,7 @@ struct nop_usb_xceiv {
struct clk *clk;
struct regulator *vcc;
struct regulator *reset;
+int gpio_reset;
};
static struct platform_device *pd;
@@ -70,6 +74,15 @@ static int nop_set_suspend(struct usb_phy *x, int suspend)
return 0;
}
+static void nop_gpio_reset(int gpio, int state)
+{
+if (gpio_is_valid(gpio))
+gpio_set_value(gpio, state);
+
+if (state)
+usleep_range(1, 2);
+}
+
static int nop_init(struct usb_phy *phy)
{
struct nop_usb_xceiv *nop = dev_get_drvdata(phy-dev);
@@ -82,11 +95,8 @@ static int nop_init(struct usb_phy *phy)
if (!IS_ERR(nop-clk))
clk_enable(nop-clk);
-if (!IS_ERR(nop-reset)) {
-/* De-assert RESET */
-if (regulator_enable(nop-reset))
-dev_err(phy-dev, Failed to de-assert reset\n);
-}
+/* De-assert RESET */
+nop_gpio_reset(nop-gpio_reset, 1);
return 0;
}
@@ -95,11 +105,8 @@ static void nop_shutdown(struct usb_phy *phy)
{
struct nop_usb_xceiv *nop = dev_get_drvdata(phy-dev);
-if (!IS_ERR(nop-reset)) {
-/* Assert RESET */
-if (regulator_disable(nop-reset))
-dev_err(phy-dev, Failed to assert reset\n);
-}
+/* Assert RESET */
+nop_gpio_reset(nop-gpio_reset, 0);
if (!IS_ERR(nop-clk))
clk_disable(nop-clk);
@@ -148,7 +155,6 @@ static int nop_usb_xceiv_probe(struct platform_device
*pdev)
int err;
u32 clk_rate = 0;
bool needs_vcc = false;
-bool needs_reset = false;
nop = devm_kzalloc(pdev-dev, sizeof(*nop), GFP_KERNEL);
if (!nop)
@@ -166,13 +172,15 @@ static int nop_usb_xceiv_probe(struct platform_device
*pdev)
clk_rate = 0;
needs_vcc = of_property_read_bool(node, vcc-supply);
-needs_reset = of_property_read_bool(node, reset-supply);
+nop-gpio_reset = of_get_named_gpio(node, reset-gpios, 0);
I'd suggest to use of_get_named_gpio_flags to also obtain the polarity
from the flags.
OK. good point.
+if (nop-gpio_reset == -EPROBE_DEFER)
+return -EPROBE_DEFER;
} else if (pdata) {
type = pdata-type;
clk_rate = pdata-clk_rate;
needs_vcc = pdata-needs_vcc;
-needs_reset = pdata-needs_reset;
+nop-gpio_reset = pdata-gpio_reset;
}
nop-clk =
Re: [PATCH v8 0/2] TWL6030, TWL6032 GPADC driver
Hi, apologies for the late reply. On Thu, Jul 25, 2013 at 02:26:51PM +0100, Oleksandr Kozaruk wrote: Hello, v8 - removed unused test channels completely, removed die temperature channels, as it is not known how to convert ADC code to temperature. There if formula for twl6030, but no formula for twl6032. v7 - addressed clean up comments, removed test channels v6 - addressed comments about trim bits, checkpatch clean up v5 - gpadc DT node renamed from gpadc to generic adc, added temperature channels; raw code is corracted with calibration data. v4 - addressed comments: fixed style violation, bug in freeing memory, added comments explaining calibration method, removed test network channels from exposing to userspace, error handling for wait_for_complition v3 - fixed compiler warning v2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; I couldn't see a binding document in this series or in mainline. Have I looked in the wrong places? Mark. -- 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 7/9] ARM: dts: omap5-uevm: Use reset-gpios for hsusb2_reset
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts reset-gpios property.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 65d7b60..c087762 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -27,21 +27,10 @@
regulator-max-microvolt = 300;
};
- /* HS USB Port 2 RESET */
- hsusb2_reset: hsusb2_reset_reg {
- compatible = regulator-fixed;
- regulator-name = hsusb2_reset;
- regulator-min-microvolt = 330;
- regulator-max-microvolt = 330;
- gpio = gpio3 16 GPIO_ACTIVE_HIGH; /* gpio3_80 HUB_NRESET */
- startup-delay-us = 7;
- enable-active-high;
- };
-
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
- reset-supply = hsusb2_reset;
+ reset-gpios = gpio3 16 GPIO_ACTIVE_LOW; /* gpio3_80
HUB_NRESET */
/**
* FIXME
* Put the right clock phandle here when available
--
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
[PATCH v2 2/9] usb: phy: nop: Don't use regulator framework for RESET line
Modelling the RESET line as a regulator supply wasn't a good idea
as it kind of abuses the regulator framework and also makes adaptation
code more complex.
Instead, manage the RESET gpio line directly in the driver. Update
the device tree binding information.
This also makes us easy to migrate to a dedicated GPIO RESET controller
whenever it becomes available.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt |7 +-
drivers/usb/phy/phy-nop.c | 71 ++-
2 files changed, 55 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index d7e2726..1bd37fa 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -15,7 +15,7 @@ Optional properties:
- vcc-supply: phandle to the regulator that provides RESET to the PHY.
-- reset-supply: phandle to the regulator that provides power to the PHY.
+- reset-gpios: Should specify the GPIO for reset.
Example:
@@ -25,10 +25,9 @@ Example:
clocks = osc 0;
clock-names = main_clk;
vcc-supply = hsusb1_vcc_regulator;
- reset-supply = hsusb1_reset_regulator;
+ reset-gpios = gpio1 7 GPIO_ACTIVE_LOW;
};
hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
-hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
-controls RESET.
+hsusb1_vcc_regulator provides power to the PHY and GPIO 7 controls RESET.
diff --git a/drivers/usb/phy/phy-nop.c b/drivers/usb/phy/phy-nop.c
index 55445e5d..1f88c32 100644
--- a/drivers/usb/phy/phy-nop.c
+++ b/drivers/usb/phy/phy-nop.c
@@ -35,6 +35,9 @@
#include linux/clk.h
#include linux/regulator/consumer.h
#include linux/of.h
+#include linux/of_gpio.h
+#include linux/gpio.h
+#include linux/delay.h
struct nop_usb_xceiv {
struct usb_phy phy;
@@ -42,6 +45,8 @@ struct nop_usb_xceiv {
struct clk *clk;
struct regulator *vcc;
struct regulator *reset;
+ int gpio_reset;
+ bool reset_active_low;
};
static struct platform_device *pd;
@@ -70,6 +75,23 @@ static int nop_set_suspend(struct usb_phy *x, int suspend)
return 0;
}
+static void nop_reset_set(struct nop_usb_xceiv *nop, int asserted)
+{
+ int value;
+
+ if (!gpio_is_valid(nop-gpio_reset))
+ return;
+
+ value = asserted;
+ if (nop-reset_active_low)
+ value = !value;
+
+ gpio_set_value_cansleep(nop-gpio_reset, value);
+
+ if (!asserted)
+ usleep_range(1, 2);
+}
+
static int nop_init(struct usb_phy *phy)
{
struct nop_usb_xceiv *nop = dev_get_drvdata(phy-dev);
@@ -82,11 +104,8 @@ static int nop_init(struct usb_phy *phy)
if (!IS_ERR(nop-clk))
clk_enable(nop-clk);
- if (!IS_ERR(nop-reset)) {
- /* De-assert RESET */
- if (regulator_enable(nop-reset))
- dev_err(phy-dev, Failed to de-assert reset\n);
- }
+ /* De-assert RESET */
+ nop_reset_set(nop, 0);
return 0;
}
@@ -95,11 +114,8 @@ static void nop_shutdown(struct usb_phy *phy)
{
struct nop_usb_xceiv *nop = dev_get_drvdata(phy-dev);
- if (!IS_ERR(nop-reset)) {
- /* Assert RESET */
- if (regulator_disable(nop-reset))
- dev_err(phy-dev, Failed to assert reset\n);
- }
+ /* Assert RESET */
+ nop_reset_set(nop, 1);
if (!IS_ERR(nop-clk))
clk_disable(nop-clk);
@@ -148,7 +164,6 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)
int err;
u32 clk_rate = 0;
bool needs_vcc = false;
- bool needs_reset = false;
nop = devm_kzalloc(pdev-dev, sizeof(*nop), GFP_KERNEL);
if (!nop)
@@ -159,20 +174,28 @@ static int nop_usb_xceiv_probe(struct platform_device
*pdev)
if (!nop-phy.otg)
return -ENOMEM;
+ nop-reset_active_low = true; /* default behaviour */
+
if (dev-of_node) {
struct device_node *node = dev-of_node;
+ enum of_gpio_flags flags;
if (of_property_read_u32(node, clock-frequency, clk_rate))
clk_rate = 0;
needs_vcc = of_property_read_bool(node, vcc-supply);
- needs_reset = of_property_read_bool(node, reset-supply);
+ nop-gpio_reset = of_get_named_gpio_flags(node, reset-gpios,
+ 0, flags);
+ if (nop-gpio_reset == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ nop-reset_active_low = flags
[PATCH v2 6/9] ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts reset-gpios property.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 18 +-
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..c60ebd0 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -60,22 +60,6 @@
AFMR, Line In;
};
- /*
-* Temp hack: Need to be replaced with the proper gpio-controlled
-* reset driver as soon it will be merged.
-* http://thread.gmane.org/gmane.linux.drivers.devicetree/36830
-*/
- /* HS USB Port 1 RESET */
- hsusb1_reset: hsusb1_reset_reg {
- compatible = regulator-fixed;
- regulator-name = hsusb1_reset;
- regulator-min-microvolt = 330;
- regulator-max-microvolt = 330;
- gpio = gpio2 30 0; /* gpio_62 */
- startup-delay-us = 7;
- enable-active-high;
- };
-
/* HS USB Port 1 Power */
hsusb1_power: hsusb1_power_reg {
compatible = regulator-fixed;
@@ -97,7 +81,7 @@
/* HS USB Host PHY on PORT 1 */
hsusb1_phy: hsusb1_phy {
compatible = usb-nop-xceiv;
- reset-supply = hsusb1_reset;
+ reset-gpios = gpio2 30 GPIO_ACTIVE_LOW; /* gpio_62 */
vcc-supply = hsusb1_power;
/**
* FIXME:
--
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
[PATCH v2 0/9] USB: phy: phy-nop: Manage RESET GPIO in the driver
Hi, Modelling the RESET line as a regulator supply wasn't a good idea as it abuses the regulator framework and makes adaptation code/data more complex. Instead, manage the RESET gpio line directly in the driver. This also makes us easy to migrate to a dedicated GPIO RESET controller whenever it becomes available. As of now, it doesn't seem to be making it into 3.12. *NOTE:* As there are changes to platform data, Patch 1 needs to be shared between the arm-soc tree and usb tree. Patch 1 is available at repo git://github.com/rogerq/linux.git in branch phy-reset-common Patch 2 contains the phy-nop driver changes Patches 3 and 4 adapt legacy boot code to the phy-nop driver changes. Patches 5, 6 and 7 adapt DT data to the binding changes. Patch 8 is cleanup of omap3-beagle DT. Patch 9 adds USB host support to omap3-beagle-xm using the new binding. Patches are based on v3.11-rc5. Tested leacy boot on omap3-beagle and omap3-beagle-xm Tested DT boot on omap3-beagle, omap3-beagle-xm and omap4-panda-es v2: - Added RESET GPIO polarity feature - Changed to gpio_set_value_cansleep() cheers, -roger --- Roger Quadros (9): usb: phy: nop: Add gpio_reset to platform data usb: phy: nop: Don't use regulator framework for RESET line ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset ARM: dts: omap5-uevm: Use reset-gpios for hsusb2_reset ARM: dts: omap3-beagle: Make USB host pin naming consistent ARM: dts: omap3-beagle-xm: Add USB Host support .../devicetree/bindings/usb/usb-nop-xceiv.txt |7 +- arch/arm/boot/dts/omap3-beagle-xm.dts | 65 +++--- arch/arm/boot/dts/omap3-beagle.dts | 37 --- arch/arm/boot/dts/omap4-panda-common.dtsi | 18 +- arch/arm/boot/dts/omap5-uevm.dts | 13 +--- arch/arm/mach-omap2/board-omap3beagle.c|6 -- arch/arm/mach-omap2/usb-host.c | 18 +++--- arch/arm/mach-omap2/usb.h |1 - drivers/usb/phy/phy-nop.c | 71 ++- include/linux/usb/nop-usb-xceiv.h |4 +- 10 files changed, 138 insertions(+), 102 deletions(-) -- 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
[PATCH v2 1/9] usb: phy: nop: Add gpio_reset to platform data
The GPIO number of the RESET line can be passed to the
driver using the gpio_reset member.
Signed-off-by: Roger Quadros rog...@ti.com
---
include/linux/usb/nop-usb-xceiv.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/linux/usb/nop-usb-xceiv.h
b/include/linux/usb/nop-usb-xceiv.h
index 148d351..1e57acb 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -9,7 +9,9 @@ struct nop_usb_xceiv_platform_data {
/* if set fails with -EPROBE_DEFER if can't get regulator */
unsigned int needs_vcc:1;
- unsigned int needs_reset:1;
+ unsigned int needs_reset:1; /* Deprecated */
+
+ int gpio_reset;
};
#if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE)
defined(MODULE))
--
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
[PATCH v2 4/9] ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes
The USB phy-nop nop driver expects the RESET line information
to be sent as a GPIO number via platform data. Adapt to that.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 1626801..4528b40 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -460,8 +460,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
memset(nop_pdata, 0, sizeof(nop_pdata));
if (gpio_is_valid(phy-vcc_gpio))
nop_pdata.needs_vcc = true;
- if (gpio_is_valid(phy-reset_gpio))
- nop_pdata.needs_reset = true;
+ nop_pdata.gpio_reset = phy-reset_gpio;
nop_pdata.type = USB_PHY_TYPE_USB2;
/* create a NOP PHY device */
@@ -483,14 +482,6 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
usb_bind_phy(ehci-omap.0, phy-port - 1, phy_id);
- /* Do we need RESET regulator ? */
- if (gpio_is_valid(phy-reset_gpio)) {
- scnprintf(rail_name, MAX_STR,
- hsusb%d_reset, phy-port);
- usbhs_add_regulator(rail_name, phy_id, reset,
- phy-reset_gpio, 1);
- }
-
/* Do we need VCC regulator ? */
if (gpio_is_valid(phy-vcc_gpio)) {
scnprintf(rail_name, MAX_STR, hsusb%d_vcc, phy-port);
--
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
[PATCH v2 9/9] ARM: dts: omap3-beagle-xm: Add USB Host support
Provide RESET GPIO and Power regulator for the USB PHY,
the USB Host port mode and the PHY device for the controller.
Also provide pin multiplexer information for USB host pins.
We also relocate omap3_pmx_core pin definations so that they
are close to omap3_pmx_wkup pin definations.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 65 -
1 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..b081f5a 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -69,6 +69,23 @@
};
};
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 18 0;/* GPIO LEDA */
+ startup-delay-us = 7;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-gpios = gpio5 19 GPIO_ACTIVE_LOW; /* gpio_147 */
+ vcc-supply = hsusb2_power;
+ };
};
omap3_pmx_wkup {
@@ -79,6 +96,37 @@
};
};
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusbb2_pins
+ ;
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+ 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
+ ;
+ };
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins =
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
+ ;
+ };
+};
+
i2c1 {
clock-frequency = 260;
@@ -148,15 +196,6 @@
power = 50;
};
-omap3_pmx_core {
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins =
- 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
- 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
- ;
- };
-};
-
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
@@ -166,3 +205,11 @@
pinctrl-names = default;
pinctrl-0 = gpio1_pins;
};
+
+usbhshost {
+ port2-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy;
+};
--
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
[PATCH v2 5/9] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts reset-gpios property.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
- /* HS USB Port 2 RESET */
- hsusb2_reset: hsusb2_reset_reg {
- compatible = regulator-fixed;
- regulator-name = hsusb2_reset;
- regulator-min-microvolt = 330;
- regulator-max-microvolt = 330;
- gpio = gpio5 19 0; /* gpio_147 */
- startup-delay-us = 7;
- enable-active-high;
- };
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = regulator-fixed;
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
- reset-supply = hsusb2_reset;
+ reset-gpios = gpio5 19 GPIO_ACTIVE_LOW; /* gpio_147 */
vcc-supply = hsusb2_power;
};
--
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
[PATCH v2 8/9] ARM: dts: omap3-beagle: Make USB host pin naming consistent
Use a common naming scheme mode0name.modename flags for the
USB host pins to be consistent.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 71bde47..1237822 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -90,18 +90,18 @@
hsusbb2_pins: pinmux_hsusbb2_pins {
pinctrl-single,pins =
- 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_clk */
- 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_stp */
- 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dir */
- 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_nxt */
- 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat0 */
- 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat1 */
- 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat2 */
- 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat3 */
- 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat4 */
- 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat5 */
- 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat6 */
- 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat7 */
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
;
};
--
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
[PATCH v2 3/9] ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
The platform data bits can be inferred from the other members of
struct usbhs_phy_data. So get rid of the platform_data member.
Build the platform data for the PHY device in usbhs_init_phys() instead.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |6 --
arch/arm/mach-omap2/usb-host.c | 11 ++-
arch/arm/mach-omap2/usb.h |1 -
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 04c1165..47bca8f 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -278,18 +278,12 @@ static struct regulator_consumer_supply
beagle_vsim_supply[] = {
static struct gpio_led gpio_leds[];
-/* PHY's VCC regulator might be added later, so flag that we need it */
-static struct nop_usb_xceiv_platform_data hsusb2_phy_data = {
- .needs_vcc = true,
-};
-
static struct usbhs_phy_data phy_data[] = {
{
.port = 2,
.reset_gpio = 147,
.vcc_gpio = -1, /* updated in beagle_twl_gpio_setup */
.vcc_polarity = 1, /* updated in beagle_twl_gpio_setup */
- .platform_data = hsusb2_phy_data,
},
};
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 2eb19d4..1626801 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -435,6 +435,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
struct platform_device *pdev;
char *phy_id;
struct platform_device_info pdevinfo;
+ struct nop_usb_xceiv_platform_data nop_pdata;
for (i = 0; i num_phys; i++) {
@@ -455,11 +456,19 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
return -ENOMEM;
}
+ /* set platform data */
+ memset(nop_pdata, 0, sizeof(nop_pdata));
+ if (gpio_is_valid(phy-vcc_gpio))
+ nop_pdata.needs_vcc = true;
+ if (gpio_is_valid(phy-reset_gpio))
+ nop_pdata.needs_reset = true;
+ nop_pdata.type = USB_PHY_TYPE_USB2;
+
/* create a NOP PHY device */
memset(pdevinfo, 0, sizeof(pdevinfo));
pdevinfo.name = nop_name;
pdevinfo.id = phy-port;
- pdevinfo.data = phy-platform_data;
+ pdevinfo.data = nop_pdata;
pdevinfo.size_data = sizeof(struct nop_usb_xceiv_platform_data);
scnprintf(phy_id, MAX_STR, nop_usb_xceiv.%d,
diff --git a/arch/arm/mach-omap2/usb.h b/arch/arm/mach-omap2/usb.h
index e7261eb..4ba2ae7 100644
--- a/arch/arm/mach-omap2/usb.h
+++ b/arch/arm/mach-omap2/usb.h
@@ -58,7 +58,6 @@ struct usbhs_phy_data {
int reset_gpio;
int vcc_gpio;
bool vcc_polarity; /* 1 active high, 0 active low */
- void *platform_data;
};
extern void usb_musb_init(struct omap_musb_board_data *board_data);
--
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: dma_unmap causing issues with __get_free_pages
On Thu, Aug 15, 2013 at 02:35:59AM -0500, Joel Fernandes wrote:
Hi,
I'm having some trouble with using the dma_map/unmap API.
On unmapping a particular page using dma_unmap, it seems that the
PG_dcache_clean flag is set in the page-flags. This is set by the
following statement in __dma_page_dev_to_cpu function in
arch/arm/mm/dma-mapping.c
set_bit(PG_dcache_clean, page-flags);
Due to this, on any subsequent page allocations using __get_free_pages,
the following BUG gets triggered.
Are you calling dma_unmap() after the page has been freed?
What is correct way to fix this? Why does the page allocator think its a
BAD page descriptor after the unmap?
Well, on free, this is done:
if (page-flags PAGE_FLAGS_CHECK_AT_PREP)
page-flags = ~PAGE_FLAGS_CHECK_AT_PREP;
which clears PG_arch_1. On allocation:
if (unlikely(page_mapcount(page) |
(page-mapping != NULL) |
(atomic_read(page-_count) != 0) |
(page-flags PAGE_FLAGS_CHECK_AT_PREP) |
(mem_cgroup_bad_page_check(page {
bad_page(page);
return 1;
}
As PG_arch_1 is part of the PAGE_FLAGS_CHECK_AT_PREP mask, this means that
when a page is freed, it has PG_arch_1 cleared. Therefore, if on allocation
the page now has this bit set, it means that something touched the page
after it was freed. Quite simply, the page was freed while still being
in use. That's very bad and needs fixing.
--
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 1/8] usb: phy: omap-control: Get rid of platform data
omap-control device is present from OMAP4 onwards which
support device tree boots only. So get rid of platform data.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/phy/phy-omap-control.c | 18 +++---
include/linux/usb/omap_control_usb.h |4
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index a4dda8e..3b9ee83 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -197,8 +197,13 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
{
struct resource *res;
struct device_node *np = pdev-dev.of_node;
- struct omap_control_usb_platform_data *pdata =
- dev_get_platdata(pdev-dev);
+
+ if (np) {
+ of_property_read_u32(np, ti,type, control_usb-type);
+ } else {
+ /* We only support DT boot */
+ return -ENODEV;
+ }
control_usb = devm_kzalloc(pdev-dev, sizeof(*control_usb),
GFP_KERNEL);
@@ -207,15 +212,6 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
- if (np) {
- of_property_read_u32(np, ti,type, control_usb-type);
- } else if (pdata) {
- control_usb-type = pdata-type;
- } else {
- dev_err(pdev-dev, no pdata present\n);
- return -EINVAL;
- }
-
control_usb-dev= pdev-dev;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 27b5b8c..e2416b4 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -31,10 +31,6 @@ struct omap_control_usb {
u32 type;
};
-struct omap_control_usb_platform_data {
- u8 type;
-};
-
enum omap_control_usb_mode {
USB_MODE_UNDEFINED = 0,
USB_MODE_HOST,
--
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
[PATCH v2 3/8] usb: phy: omap-usb2: Don't use omap_get_control_dev()
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is not present.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/phy/phy-omap-usb2.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 376b367..77e0cf4 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/usb/omap_control_usb.h
+#include linux/of_platform.h
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -124,6 +125,8 @@ static int omap_usb2_probe(struct platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct device_node *node = pdev-dev.of_node;
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
if (!node)
return -ENODEV;
@@ -148,11 +151,18 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-phy.otg= otg;
phy-phy.type = USB_PHY_TYPE_USB2;
- phy-control_dev = omap_get_control_dev();
- if (IS_ERR(phy-control_dev)) {
- dev_dbg(pdev-dev, Failed to get control device\n);
+ control_node = of_parse_phandle(node, ctrl-module, 0);
+ if (!control_node) {
+ dev_err(pdev-dev, Failed to get control device phandle\n);
return -ENODEV;
}
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(pdev-dev, Failed to get control device\n);
+ return -ENODEV;
+ }
+
+ phy-control_dev = control_pdev-dev;
phy-is_suspended = 1;
omap_control_usb_phy_power(phy-control_dev, 0);
--
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
[PATCH v2 2/8] usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power()
Add support for new device types and in the process rid of ti,type
device tree property. The correct type of device will be determined
from the compatible string instead.
Introduce a compatible string for each device type. At the moment
we support 4 types Mailbox, USB2, USB3 and DRA7.
Update DT binding information to reflect these changes.
Also get rid of omap_control_usb3_phy_power(). Just one function
i.e. omap_control_usb_phy_power() will now take care of all PHY types.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 29 ++--
drivers/usb/phy/phy-omap-control.c | 148
drivers/usb/phy/phy-omap-usb2.c|4 +
drivers/usb/phy/phy-omap-usb3.c|6 +-
include/linux/usb/omap_control_usb.h | 24 ++--
5 files changed, 122 insertions(+), 89 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..1c6b54a 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -73,22 +73,23 @@ omap_dwc3 {
OMAP CONTROL USB
Required properties:
- - compatible: Should be ti,omap-control-usb
+ - compatible: Should be one of
+ ti,omap-control-usb - if it has otghs_control mailbox register
+ e.g. on OMAP4.
+ ti,usb2-control-usb - if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+ ti,usb3-control-usb - if it has DPLL and individual Rx Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+ ti,dra7-control-usb - if it has both power down and power aux registers
+ e.g. USB2 PHY on DRA7 platform.
+
- reg : Address and length of the register set for the device. It contains
- the address of control_dev_conf and otghs_control or phy_power_usb
- depending upon omap4 or omap5.
- - reg-names: The names of the register addresses corresponding to the
registers
- filled in reg.
- - ti,type: This is used to differentiate whether the control module has
- usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
- notify events to the musb core and omap5 has usb3 phy power register to
- power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3
- phy power.
+ the address of otghs_control for type 1 or power register for other
types.
+ For type 4, it must also contain power_aux register.
+ - reg-names: should be otghs_control for type 1 and power for other types.
omap_control_usb: omap-control-usb@4a002300 {
compatible = ti,omap-control-usb;
- reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
- reg-names = control_dev_conf, otghs_control;
- ti,type = 1;
+ reg = 0x4a00233c 0x4;
+ reg-names = otghs_control;
};
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 3b9ee83..078c46f 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -46,61 +46,76 @@ struct device *omap_get_control_dev(void)
EXPORT_SYMBOL_GPL(omap_get_control_dev);
/**
- * omap_control_usb3_phy_power - power on/off the serializer using control
- * module
+ * omap_control_usb_phy_power - power on/off the phy using control module reg
* @dev: the control module device
- * @on: 0 to off and 1 to on based on powering on or off the PHY
- *
- * usb3 PHY driver should call this API to power on or off the PHY.
+ * @on: 0 or 1, based on powering on or off the PHY
*/
-void omap_control_usb3_phy_power(struct device *dev, bool on)
+void omap_control_usb_phy_power(struct device *dev, int on)
{
- u32 val;
+ u32 val, val_aux;
unsigned long rate;
- struct omap_control_usb *control_usb = dev_get_drvdata(dev);
+ struct omap_control_usb *control_usb;
- if (control_usb-type != OMAP_CTRL_DEV_TYPE2)
+ if (IS_ERR(dev) || !dev) {
+ pr_err(%s: invalid device\n, __func__);
return;
+ }
- rate = clk_get_rate(control_usb-sys_clk);
- rate = rate/100;
+ control_usb = dev_get_drvdata(dev);
+ if (!control_usb) {
+ dev_err(dev, %s: invalid control usb device\n, __func__);
+ return;
+ }
- val = readl(control_usb-phy_power);
+ if (control_usb-type == OMAP_CTRL_TYPE_OMAP)
+ return;
- if (on) {
- val = ~(OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK |
- OMAP_CTRL_USB_PWRCTL_CLK_FREQ_MASK);
- val |= OMAP_CTRL_USB3_PHY_TX_RX_POWERON
- OMAP_CTRL_USB_PWRCTL_CLK_CMD_SHIFT;
- val |= rate OMAP_CTRL_USB_PWRCTL_CLK_FREQ_SHIFT;
- } else {
- val = ~OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK;
- val |= OMAP_CTRL_USB3_PHY_TX_RX_POWEROFF
-
[PATCH v2 0/8] phy: omap-usb: Support multiple instances and new types
Hi, This patchset does the following: * Get rid of omap_control_usb platform data as we support DT only. * Restructure and add support for new PHY types. We now support the follwing four types TYPE_OMAP - if it has otghs_control mailbox register (e.g. on OMAP4) TYPE_USB2 - if it has Power down bit in control_dev_conf register. e.g. USB2 PHY TYPE_USB3 - if it has DPLL and individual Rx Tx power control. e.g. USB3 PHY or SATA PHY TYPE_DRA7 - if it has both power down and power aux registers. e.g. USB2 PHY on DRA7 * Get rid of ti,type DT property and introduce compatible strings for each type. * Have only one power control API omap_control_usb_phy_power() instead of a different one for each PHY type. * Get rid of omap_get_control_dev() so that we can support multiple instances of the control device. We take advantage of the fact that omap control USB device is only present on OMAP4 onwards and hence only supports DT boot. The users of control USB device can get a reference to it from the device node's phandle. Patches are based on balbi/next. Smoke tested on OMAP4 panda with MUSB in gadget mode (g_zero). You can find the patches in branch usb-control-module in git tree git://github.com/rogerq/linux.git v2: - get rid of ti,type property and introduce compatible strings for each device type. cheers, -roger --- Roger Quadros (8): usb: phy: omap-control: Get rid of platform data usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power() usb: phy: omap-usb2: Don't use omap_get_control_dev() usb: phy: omap-usb3: Don't use omap_get_control_dev() usb: musb: omap2430: Don't use omap_get_control_dev() usb: phy: omap: get rid of omap_get_control_dev() ARM: dts: omap4: update omap-control-usb nodes ARM: dts: omap5: update omap-control-usb node Documentation/devicetree/bindings/usb/omap-usb.txt | 29 ++-- arch/arm/boot/dts/omap4.dtsi | 17 ++- arch/arm/boot/dts/omap5.dtsi | 20 ++- drivers/usb/musb/omap2430.c| 22 ++- drivers/usb/phy/phy-omap-control.c | 189 +++- drivers/usb/phy/phy-omap-usb2.c| 20 ++- drivers/usb/phy/phy-omap-usb3.c| 26 ++- include/linux/usb/omap_control_usb.h | 33 ++--- 8 files changed, 206 insertions(+), 150 deletions(-) -- 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
[PATCH v2 6/8] usb: phy: omap: get rid of omap_get_control_dev()
This function was preventing us from supporting multiple
instances. Get rid of it. Since we support DT boots only,
users can get the control device phandle from the DT node.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/phy/phy-omap-control.c | 31 ++-
include/linux/usb/omap_control_usb.h |5 -
2 files changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 078c46f..d144c14 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -25,26 +25,6 @@
#include linux/clk.h
#include linux/usb/omap_control_usb.h
-static struct omap_control_usb *control_usb;
-
-/**
- * omap_get_control_dev - returns the device pointer for this control device
- *
- * This API should be called to get the device pointer for this control
- * module device. This device pointer should be used for called other
- * exported API's in this driver.
- *
- * To be used by PHY driver and glue driver.
- */
-struct device *omap_get_control_dev(void)
-{
- if (!control_usb)
- return ERR_PTR(-ENODEV);
-
- return control_usb-dev;
-}
-EXPORT_SYMBOL_GPL(omap_get_control_dev);
-
/**
* omap_control_usb_phy_power - power on/off the phy using control module reg
* @dev: the control module device
@@ -187,11 +167,19 @@ void omap_control_usb_set_mode(struct device *dev,
{
struct omap_control_usb *ctrl_usb;
- if (IS_ERR(dev) || control_usb-type != OMAP_CTRL_TYPE_OMAP)
+ if (IS_ERR(dev) || !dev)
return;
ctrl_usb = dev_get_drvdata(dev);
+ if (!ctrl_usb) {
+ dev_err(dev, Invalid control usb device\n);
+ return;
+ }
+
+ if (ctrl_usb-type != OMAP_CTRL_TYPE_OMAP)
+ return;
+
switch (mode) {
case USB_MODE_HOST:
omap_control_usb_host_mode(ctrl_usb);
@@ -212,6 +200,7 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
{
struct resource *res;
struct device_node *np = pdev-dev.of_node;
+ struct omap_control_usb *control_usb;
if (!np) {
/* We only support DT boot */
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 9eb6f9ca..aa41bd5 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -65,15 +65,10 @@ enum omap_control_usb_mode {
#define OMAP_CTRL_USB2_PHY_PD BIT(28)
#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
-extern struct device *omap_get_control_dev(void);
extern void omap_control_usb_phy_power(struct device *dev, int on);
extern void omap_control_usb_set_mode(struct device *dev,
enum omap_control_usb_mode mode);
#else
-static inline struct device *omap_get_control_dev(void)
-{
- return ERR_PTR(-ENODEV);
-}
static inline void omap_control_usb_phy_power(struct device *dev, int on)
{
--
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
[PATCH v2 5/8] usb: musb: omap2430: Don't use omap_get_control_dev()
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/musb/omap2430.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index ebb46ec..1db9588 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -38,6 +38,7 @@
#include linux/delay.h
#include linux/usb/musb-omap.h
#include linux/usb/omap_control_usb.h
+#include linux/of_platform.h
#include musb_core.h
#include omap2430.h
@@ -547,12 +548,25 @@ static int omap2430_probe(struct platform_device *pdev)
}
if (pdata-has_mailbox) {
- glue-control_otghs = omap_get_control_dev();
- if (IS_ERR(glue-control_otghs)) {
- dev_vdbg(pdev-dev, Failed to get control device\n);
- ret = PTR_ERR(glue-control_otghs);
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+
+ control_node = of_parse_phandle(np, ctrl-module, 0);
+ if (!control_node) {
+ dev_err(pdev-dev, Failed to get control device
phandle\n);
+ ret = -ENODEV;
+ goto err2;
+ }
+
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(pdev-dev, Failed to get control device\n);
+ ret = -ENODEV;
goto err2;
}
+
+ glue-control_otghs = control_pdev-dev;
+
} else {
glue-control_otghs = ERR_PTR(-ENODEV);
}
--
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
[PATCH v2 4/8] usb: phy: omap-usb3: Don't use omap_get_control_dev()
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is not present.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/phy/phy-omap-usb3.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index 4a7f27c..bad032e 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
@@ -26,6 +26,7 @@
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/usb/omap_control_usb.h
+#include linux/of_platform.h
#definePLL_STATUS 0x0004
#definePLL_GO 0x0008
@@ -198,6 +199,12 @@ static int omap_usb3_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
struct resource *res;
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+
+ if (!node)
+ return -ENODEV;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -239,11 +246,18 @@ static int omap_usb3_probe(struct platform_device *pdev)
return -EINVAL;
}
- phy-control_dev = omap_get_control_dev();
- if (IS_ERR(phy-control_dev)) {
- dev_dbg(pdev-dev, Failed to get control device\n);
+ control_node = of_parse_phandle(node, ctrl-module, 0);
+ if (!control_node) {
+ dev_err(pdev-dev, Failed to get control device phandle\n);
return -ENODEV;
}
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(pdev-dev, Failed to get control device\n);
+ return -ENODEV;
+ }
+
+ phy-control_dev = control_pdev-dev;
omap_control_usb_phy_power(phy-control_dev, 0);
usb_add_phy_dev(phy-phy);
--
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
[PATCH v2 7/8] ARM: dts: omap4: update omap-control-usb nodes
Split otghs_ctrl and USB2 PHY power down into separate
omap-control-usb nodes. Get rid of ti,type property.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..ca08cf2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -519,7 +519,7 @@
usb2_phy: usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
- ctrl-module = omap_control_usb;
+ ctrl-module = omap_control_usb2phy;
};
};
@@ -643,12 +643,16 @@
};
};
- omap_control_usb: omap-control-usb@4a002300 {
+ omap_control_usb2phy: omap-control-usb@4a002300 {
+ compatible = ti,usb2-control-usb;
+ reg = 0x4a002300 0x4;
+ reg-names = power;
+ };
+
+ omap_control_usbotg: omap-control-usb@4a00233c {
compatible = ti,omap-control-usb;
- reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
- reg-names = control_dev_conf, otghs_control;
- ti,type = 1;
+ reg = 0x4a00233c 0x4;
+ reg-names = otghs_control;
};
usb_otg_hs: usb_otg_hs@4a0ab000 {
@@ -662,6 +666,7 @@
num-eps = 16;
ram-bits = 12;
ti,has-mailbox;
+ ctrl-module = omap_control_usbotg;
};
};
};
--
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
[PATCH v2 8/8] ARM: dts: omap5: update omap-control-usb node
Split USB2 PHY and USB3 PHY into separate omap-control-usb
nodes. Get rid of ti,type property.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07be2cd..7cda18b 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -626,12 +626,16 @@
hw-caps-temp-alert;
};
- omap_control_usb: omap-control-usb@4a002300 {
- compatible = ti,omap-control-usb;
- reg = 0x4a002300 0x4,
- 0x4a002370 0x4;
- reg-names = control_dev_conf, phy_power_usb;
- ti,type = 2;
+ omap_control_usb2phy: omap-control-usb@4a002300 {
+ compatible = ti,usb2-control-usb;
+ reg = 0x4a002300 0x4;
+ reg-names = power;
+ };
+
+ omap_control_usb3phy: omap-control-usb@0x4a002370 {
+ compatible = ti,usb3-control-usb;
+ reg = 0x4a002370 0x4;
+ reg-names = power;
};
omap_dwc3@4a02 {
@@ -661,7 +665,7 @@
usb2_phy: usb2phy@4a084000 {
compatible = ti,omap-usb2;
reg = 0x4a084000 0x7c;
- ctrl-module = omap_control_usb;
+ ctrl-module = omap_control_usb2phy;
};
usb3_phy: usb3phy@4a084400 {
@@ -670,7 +674,7 @@
0x4a084800 0x64,
0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
- ctrl-module = omap_control_usb;
+ ctrl-module = omap_control_usb3phy;
};
};
--
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 2/8] usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power()
Hi Roger,
On 15/08/2013 15:15, Roger Quadros wrote:
Add support for new device types and in the process rid of ti,type
device tree property. The correct type of device will be determined
from the compatible string instead.
Introduce a compatible string for each device type. At the moment
we support 4 types Mailbox, USB2, USB3 and DRA7.
Update DT binding information to reflect these changes.
Also get rid of omap_control_usb3_phy_power(). Just one function
i.e. omap_control_usb_phy_power() will now take care of all PHY types.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 29 ++--
drivers/usb/phy/phy-omap-control.c | 148
drivers/usb/phy/phy-omap-usb2.c|4 +
drivers/usb/phy/phy-omap-usb3.c|6 +-
include/linux/usb/omap_control_usb.h | 24 ++--
5 files changed, 122 insertions(+), 89 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..1c6b54a 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -73,22 +73,23 @@ omap_dwc3 {
OMAP CONTROL USB
Required properties:
- - compatible: Should be ti,omap-control-usb
+ - compatible: Should be one of
+ ti,omap-control-usb - if it has otghs_control mailbox register
+ e.g. on OMAP4.
How generic is that one? I mean if this is applicable for OMAP4 only,
you'd better name it omap4-control-usb.
+ ti,usb2-control-usb - if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+ ti,usb3-control-usb - if it has DPLL and individual Rx Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+ ti,dra7-control-usb - if it has both power down and power aux registers
+ e.g. USB2 PHY on DRA7 platform.
+
- reg : Address and length of the register set for the device. It contains
- the address of control_dev_conf and otghs_control or phy_power_usb
- depending upon omap4 or omap5.
- - reg-names: The names of the register addresses corresponding to the
registers
- filled in reg.
- - ti,type: This is used to differentiate whether the control module has
- usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
- notify events to the musb core and omap5 has usb3 phy power register to
- power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3
- phy power.
+ the address of otghs_control for type 1 or power register for other
types.
+ For type 4, it must also contain power_aux register.
+ - reg-names: should be otghs_control for type 1 and power for other types.
type1 and 4 are less obvious now that you have name, you should be more
explicit and name them directly.
omap_control_usb: omap-control-usb@4a002300 {
compatible = ti,omap-control-usb;
- reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
- reg-names = control_dev_conf, otghs_control;
- ti,type = 1;
+ reg = 0x4a00233c 0x4;
+ reg-names = otghs_control;
};
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 3b9ee83..078c46f 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -46,61 +46,76 @@ struct device *omap_get_control_dev(void)
EXPORT_SYMBOL_GPL(omap_get_control_dev);
/**
- * omap_control_usb3_phy_power - power on/off the serializer using control
- * module
+ * omap_control_usb_phy_power - power on/off the phy using control module reg
* @dev: the control module device
- * @on: 0 to off and 1 to on based on powering on or off the PHY
- *
- * usb3 PHY driver should call this API to power on or off the PHY.
+ * @on: 0 or 1, based on powering on or off the PHY
*/
-void omap_control_usb3_phy_power(struct device *dev, bool on)
+void omap_control_usb_phy_power(struct device *dev, int on)
{
- u32 val;
+ u32 val, val_aux;
unsigned long rate;
- struct omap_control_usb *control_usb = dev_get_drvdata(dev);
+ struct omap_control_usb *control_usb;
- if (control_usb-type != OMAP_CTRL_DEV_TYPE2)
+ if (IS_ERR(dev) || !dev) {
+ pr_err(%s: invalid device\n, __func__);
return;
+ }
- rate = clk_get_rate(control_usb-sys_clk);
- rate = rate/100;
+ control_usb = dev_get_drvdata(dev);
+ if (!control_usb) {
+ dev_err(dev, %s: invalid control usb device\n, __func__);
+ return;
+ }
- val = readl(control_usb-phy_power);
+ if (control_usb-type == OMAP_CTRL_TYPE_OMAP)
+ return;
- if (on) {
- val = ~(OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK |
- OMAP_CTRL_USB_PWRCTL_CLK_FREQ_MASK);
- val |=
Re: dma_unmap causing issues with __get_free_pages
Hi Russell,
On 08/15/2013 06:55 AM, Russell King - ARM Linux wrote:
On Thu, Aug 15, 2013 at 02:35:59AM -0500, Joel Fernandes wrote:
Hi,
I'm having some trouble with using the dma_map/unmap API.
On unmapping a particular page using dma_unmap, it seems that the
PG_dcache_clean flag is set in the page-flags. This is set by the
following statement in __dma_page_dev_to_cpu function in
arch/arm/mm/dma-mapping.c
set_bit(PG_dcache_clean, page-flags);
Due to this, on any subsequent page allocations using __get_free_pages,
the following BUG gets triggered.
Are you calling dma_unmap() after the page has been freed?
What is correct way to fix this? Why does the page allocator think its a
BAD page descriptor after the unmap?
Well, on free, this is done:
if (page-flags PAGE_FLAGS_CHECK_AT_PREP)
page-flags = ~PAGE_FLAGS_CHECK_AT_PREP;
which clears PG_arch_1. On allocation:
if (unlikely(page_mapcount(page) |
(page-mapping != NULL) |
(atomic_read(page-_count) != 0) |
(page-flags PAGE_FLAGS_CHECK_AT_PREP) |
(mem_cgroup_bad_page_check(page {
bad_page(page);
return 1;
}
As PG_arch_1 is part of the PAGE_FLAGS_CHECK_AT_PREP mask, this means that
when a page is freed, it has PG_arch_1 cleared. Therefore, if on allocation
the page now has this bit set, it means that something touched the page
after it was freed. Quite simply, the page was freed while still being
in use. That's very bad and needs fixing.
Absolutely you nailed it! I was doing alloc, map, free, unmap, changed
this to alloc, map, unmap, free and its working fine now and I learnt a
thing or 2 about page-flags. Thanks!
-Joel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] extcon: palmas: Added a new compatible type *ti, palmas-usb-vid*
Hi Kishon, On 14/08/2013 07:24, Kishon Vijay Abraham I wrote: Hi, On Wednesday 14 August 2013 12:43 AM, Stephen Warren wrote: On 08/12/2013 11:37 PM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so added a compatible type *ti,palmas-usb-vid*. Dint remove the existing compatible s/Dint/Didn't/ diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt b/Documentation/devicetree/bindings/extcon/extcon-twl.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb or ti,twl6035-usb or + ti,palmas-usb-vid. So are ti,palmas-usb and ti,twl6035-usb full EHCI controllers then? No. I thought I shouldn't remove those if someone is already using those compatible value. Well, I think we still have a short period of time where we can clean some badly defined bindings before it is really too late. Both kernel and DTS are still in sync for the moment, so changing both at the same time should be safe. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/8] usb: phy: omap-control: Get rid of platform data
* Roger Quadros | 2013-08-15 16:15:05 [+0300]:
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index a4dda8e..3b9ee83 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -197,8 +197,13 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
{
struct resource *res;
struct device_node *np = pdev-dev.of_node;
- struct omap_control_usb_platform_data *pdata =
- dev_get_platdata(pdev-dev);
+
+ if (np) {
+ of_property_read_u32(np, ti,type, control_usb-type);
+ } else {
+ /* We only support DT boot */
+ return -ENODEV;
+ }
what about
if (!nop)
return -EINVAL;
control_usb = devm_kzalloc(pdev-dev, sizeof(*control_usb),
GFP_KERNEL);
@@ -207,15 +212,6 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
- if (np) {
- of_property_read_u32(np, ti,type, control_usb-type);
and here you shift the property to the left and remove the other lines.
But then you wanted to remove that ti,type thingy but I guess this will
be part of another patch then. Since you can't do everything in one
patch, it is okay.
- } else if (pdata) {
- control_usb-type = pdata-type;
- } else {
- dev_err(pdev-dev, no pdata present\n);
- return -EINVAL;
- }
-
control_usb-dev= pdev-dev;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
Sebastian
--
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 6/8] usb: phy: omap: get rid of omap_get_control_dev()
* Roger Quadros | 2013-08-15 16:15:10 [+0300]:
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 078c46f..d144c14 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -187,11 +167,19 @@ void omap_control_usb_set_mode(struct device *dev,
{
struct omap_control_usb *ctrl_usb;
- if (IS_ERR(dev) || control_usb-type != OMAP_CTRL_TYPE_OMAP)
+ if (IS_ERR(dev) || !dev)
return;
ctrl_usb = dev_get_drvdata(dev);
+ if (!ctrl_usb) {
+ dev_err(dev, Invalid control usb device\n);
+ return;
+ }
+
+ if (ctrl_usb-type != OMAP_CTRL_TYPE_OMAP)
+ return;
+
I don't like that part where you can call this function even before the
driver probed the device. This shouldn't happen since you have hard module
dependency and the proper compatible string in your device. But this
kind of thing won't happen in the am335x reset driver.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: OMAP: fix USB regression on Nokia boards
Hi, On Tue, Aug 06, 2013 at 08:06:14PM +0300, Aaro Koskinen wrote: USB subsystem changes broke the USB peripheral/gadget on N800, N810 and RX-51/N900 during the merge window. We need to fix this in board files. I tested all these with 3.11-rc4 + g_ether + ssh. Ping? A. Aaro Koskinen (1): ARM: OMAP: rx51: change musb mode to OTG Daniel Mack (1): ARM: omap2: fix musb usage for n8x0 arch/arm/mach-omap2/board-n8x0.c | 4 arch/arm/mach-omap2/board-rx51.c | 2 +- arch/arm/mach-omap2/usb-musb.c | 5 + 3 files changed, 2 insertions(+), 9 deletions(-) -- 1.8.3.2 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] misc: Add crossbar driver
On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R r.sricha...@ti.com wrote: Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. I think it is better to use irqchip. For DMA there is already an arbiter mechanism for arbitration of virtual channels over physical channels, this is not much different, the DMA might need some different tweaking but should be solved in that subsystem I think. I don't see any way to really abstract this pretty simple crossbar for reuse across subsystems. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R r.sricha...@ti.com wrote: Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. I think it is better to use irqchip. Did you happen to read the thread why irqchip is in-appropriate for such an IP. As I said earlier, an IRQ-chip always need a real IRQ link (even for the chained one) to the primary irqchip. This IP is just dummy IP makes the connections for the primary irqchip(read GIC). And its use only limited to make the connection between the peripheral IRQ event to the GIC IRQ line. I don't see how you can make this happen with an irqchip infrastructure. If you have a idea to make that work, we can go with that since for time being we can ignore the DMA event related need of this IP. For DMA there is already an arbiter mechanism for arbitration of virtual channels over physical channels, this is not much different, the DMA might need some different tweaking but should be solved in that subsystem I think. Sure. The IP won't be limited to DMA and IRQ lines but any other events like gpio etc in future. I don't see any way to really abstract this pretty simple crossbar for reuse across subsystems. This exactly the reason, i am against idea of over-engineering the simple IP whose only job is to make the physical wire connection in software where as this is generally done in RTL by default on most of the SOCs. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM:dts: Add devicetree for gta04 board.
This adds devicetree for gta04 (Openmoko next generation board) with necessary
support for mmc, usb, leds and button.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
This is resurrection of patch sent in March https://lkml.org/lkml/2013/1/24/419
when I got no reply from maintainer. Patch is updated and based on linux-next
(20130807)
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/omap3-gta04.dts | 168 ++
2 files changed, 169 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-gta04.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ada589c..f091c50 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -171,6 +171,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+ omap3-gta04.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
omap4-panda.dtb \
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
new file mode 100644
index 000..0987f76
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2013 Marek Belisko ma...@goldelico.com
+ *
+ * Based on omap3-beagle-xm.dts
+ *
+ * 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.
+ */
+/dts-v1/;
+
+#include omap36xx.dtsi
+
+/ {
+ model = OMAP3 GTA04;
+ compatible = ti,omap3-gta04, ti,omap3;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+
+ aux-button {
+ label = aux;
+ linux,code = 169;
+ gpios = gpio1 7 GPIO_ACTIVE_LOW;
+ gpio-key,wakeup;
+ };
+ };
+};
+
+omap3_pmx_core {
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x152 (PIN_INPUT | MUX_MODE0) /*
uart1_rx.uart1_rx */
+ 0x14c (PIN_OUTPUT |MUX_MODE0) /*
uart1_tx.uart1_tx */
+ ;
+ };
+
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins =
+ 0x14a (PIN_INPUT | MUX_MODE0) /*
uart2_rx.uart2_rx */
+ 0x148 (PIN_OUTPUT | MUX_MODE0) /*
uart2_tx.uart2_tx */
+ ;
+ };
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e (PIN_INPUT | MUX_MODE0) /*
uart3_rx.uart3_rx */
+ 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx.uart3_tx */
+ ;
+ };
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x114 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_clk.sdmmc1_clk */
+ 0x116 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_cmd.sdmmc1_cmd */
+ 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat0.sdmmc1_dat0 */
+ 0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat1.sdmmc1_dat1 */
+ 0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat2.sdmmc1_dat2 */
+ 0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat3.sdmmc1_dat3 */
+ ;
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+#include twl4030.dtsi
+#include twl4030_omap3.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+
+ /* pressure sensor */
+ bmp085@77 {
+ compatible = bosch,bmp085;
+ reg = 0x77;
+ };
+
+ /* leds */
+ tca6507@45 {
+ compatible = ti,tca6507;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x45;
+
+ gta04_led0: red_aux@0 {
+ label = gta04:red:aux;
+ reg = 0x0;
+ };
+
+ gta04_led1: green_aux@1 {
+ label = gta04:green:aux;
+ reg = 0x1;
+ };
+
+ gta04_led3: red_power@3 {
+ label = gta04:red:power;
+ reg = 0x3;
+ linux,default-trigger = default-on;
+ };
+
+ gta04_led4: green_power@4 {
+ label = gta04:green:power;
+ reg = 0x4;
+ };
+ };
+};
+
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R r.sricha...@ti.com wrote: Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. I think it is better to use irqchip. Did you happen to read the thread why irqchip is in-appropriate for such an IP. Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernelm=137442541628641w=2 As I said earlier, an IRQ-chip always need a real IRQ link (even for the chained one) to the primary irqchip. This IP is just dummy IP makes the connections for the primary irqchip(read GIC). And its use only limited to make the connection between the peripheral IRQ event to the GIC IRQ line. I don't see how you can make this happen with an irqchip infrastructure. I think my post above describes this. I don't see any way to really abstract this pretty simple crossbar for reuse across subsystems. This exactly the reason, i am against idea of over-engineering the simple IP whose only job is to make the physical wire connection in software where as this is generally done in RTL by default on most of the SOCs. Well, it was made accessible by software, and if someone has a usecase that requires this do be done dynamically, i.e. not just being set up by firmware and never touched, and that use case is valid, then I guess we need to do something... I think it was mentioned in the thread that there is really such a usecase? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R r.sricha...@ti.com wrote: Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. I think it is better to use irqchip. Did you happen to read the thread why irqchip is in-appropriate for such an IP. Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernelm=137442541628641w=2 It was discussed in couple of threads but the main point was the need of a link needed for the irqchip. As I said earlier, an IRQ-chip always need a real IRQ link (even for the chained one) to the primary irqchip. This IP is just dummy IP makes the connections for the primary irqchip(read GIC). And its use only limited to make the connection between the peripheral IRQ event to the GIC IRQ line. I don't see how you can make this happen with an irqchip infrastructure. I think my post above describes this. Sorry for being dumb but I don't think cascaded irqchip examples like GPIO and cross-bars are same. If you take an example of GPIO irqchip, it always have a physical connection even if it is 1 IRQ line for (32 logical/sparse IRQs). That goes with other MFD examples too. So may be I am still missing something in your proposal. I don't see any way to really abstract this pretty simple crossbar for reuse across subsystems. This exactly the reason, i am against idea of over-engineering the simple IP whose only job is to make the physical wire connection in software where as this is generally done in RTL by default on most of the SOCs. Well, it was made accessible by software, and if someone has a usecase that requires this do be done dynamically, i.e. not just being set up by firmware and never touched, and that use case is valid, then I guess we need to do something... I think it was mentioned in the thread that there is really such a usecase? Actually there is no practical usecase but one but one can manufacture it ;-) -- 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] arm: dts: AM43x: Add usb DT nodes for AM4372
Hi Benoit ,
Thanks for your review.
On 8/14/2013 8:04 PM, Benoit Cousson wrote:
+ Roger
Hi George,
Yes, I had some comment about the ti'type in Roger's series that
will be applicable here as well.
On 14/08/2013 16:16, George Cherian wrote:
+Benoit
If you dont have any comments, can you take this for 3.12?
Regards
-George
On 7/10/2013 1:44 PM, George Cherian wrote:
This patch adds
- HS USB nodes
- phy nodes
- usb control module nodes.
Signed-off-by: George Cherian george.cher...@ti.com
---
changes from v2
change synopsis to snps
use simple node names
add both USB and PHY instances
add usbctrl node
changes from v1
renamed synopsis to snps
removed flag tx-fifo-resize
arch/arm/boot/dts/am4372.dtsi | 58
+++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi
b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..37f196f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,63 @@
compatible = ti,am4372-counter32k,ti,omap-counter32k;
reg = 0x44e86000 0x40;
};
+
+phy1: usbphy1 {
+compatible = ti,am4372-usb2;
That's not a very good name for a phy? It looks like a usb module.
The bindings specify only ti,omap-usb2 or ti,omap-usb3 for USB2 or USB3.
I guess it should be one of them and potentially the binding should be
updated with ti,omap-usb2-phy and ti,omap-usb3-phy names while we can
still do it.
+#phy-cells = 0;
+id = 0;
+status = disabled;
+};
+
+phy2: usbphy2 {
Why do you need a different node name here? It should be a generic
name to identify the function, so usbphy or usb-phy seems good enough.
There are 2 instances of usb controllers and these instances for those 2
phys, which essentially dont have any reg property. So I named it as
usbphy1 and usbphy2.
+compatible = ti,am4372-usb2;
+#phy-cells = 0;
+id = 1;
+status = disabled;
+};
+
+usbctrl: omap-control-usb@44e10620 {
+compatible = ti,omap-control-usb;
+reg = 0x44e10620 0x10;
+reg-names = control_dev_conf;
+ti,type = 3;
+status = disabled;
+};
+
+usb1: am4372_dwc3@4838 {
+status = disabled;
+compatible = ti,am4372-dwc3;
+reg = 0x4838 0x200;
+interrupts = GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH;
+#address-cells = 1;
+#size-cells = 1;
+utmi-mode = 1;
+ranges;
A blank line here will be nice.
okay
+dwc3@4839 {
+compatible = snps,dwc3;
+reg = 0x4839 0xd000;
+interrupts = GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH;
+phys = phy1;
+phy-names = am4372-usb1;
What is the purpose of the phy-names? Is it relevant to add the SoC
name in something that usually, at least for the clocks and IRQs, is
IP specific?
The current documentation does not explain it and does not support
phys property either.
synopsys DWC3 CORE
DWC3- USB3 CONTROLLER
Required properties:
- compatible: must be synopsys,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
- usb-phy : array of phandle for the PHY device
Is there some binding update ongoing for 3.12?
The phy part, especially was added with the generic phy framework in
mind. The generic phy framework uses phys and phy-names instead of usb-phy.
Also all synopsys references for compatible are being replaced with snps.
+};
+};
+
+usb2: am4372_dwc3@483c {
+status = disabled;
+compatible = ti,am4372-dwc3;
+reg = 0x483c 0x200;
+interrupts = GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH;
+#address-cells = 1;
+#size-cells = 1;
+utmi-mode = 1;
+ranges;
A blank line here will be nice.
okay
+dwc3@483d {
+compatible = snps,dwc3;
+reg = 0x483d 0xd000;
+interrupts = GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH;
+phys = phy2;
+phy-names = am4372-usb2;
+};
+};
};
};
Regards,
Benoit
--
-George
--
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: omap5: dts: split SMPS10 dt node
Hi Benoit, On Tuesday 13 August 2013 08:18 PM, Benoit Cousson wrote: On 13/08/2013 16:45, Kishon Vijay Abraham I wrote: Hi, On Tuesday 13 August 2013 06:51 PM, Benoit Cousson wrote: Hi Kishon, On 12/08/2013 11:37, Kishon Vijay Abraham I wrote: SMPS10 has two outputs OUT1 and OUT2. Hence SMPS10 is modeled as two regulators. The dt node is split to reflect it. Mmm, I'm curious. How is it supposed to work? Do you have dedicated control on each output? Yes. It can be controlled by setting different values to the same bit fields. You can refer [1] where we actually implement SMPS10 as two different regulators. [1] - http://permalink.gmane.org/gmane.linux.kernel/1542521 Great, thanks. Can we merge that one safely if the driver changed are not done yet? I think it shouldn't cause any issues. However Mark has already merged the driver changes. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/12] edma: Add support for SG lists of any length
Following offline discussions with Sekhar, we discussed some ideas to change a few things in this patch series to make it fail-safe. As such, the only changes we are making for v4 will be to not cyclically link immediately but doing so only once the ISR has finished setup (apart from other style cleanups). Any conditions where we are not able to modify the link in time (due to heavily loaded system) will be detected and reported by the use of linking to a NULL set. The new approach will be fast because of no requirement to stall or wait, and any DMA issues with heavily loaded systems can be detected as error conditions. This should architecturally be the final version of the patch series to add DMA support for SG lists of any length. Thanks, -Joel On 08/05/2013 11:14 AM, Joel Fernandes wrote: Here is a more improved approach for DMA support of SG lists of any length in the EDMA DMA Engine driver. In the previous approach [1] we depended on error interrupts to detect missed events and manually retrigger them, however as discussed in [2], there are concerns this can be trouble some for high speed peripherals which may need a more real-time response from the DMA controller. In this approach, we divide the total no of MAX slots per channel, into 2 linked sets which are cyclically linked to each other (the cyclic link between the 2 sets make sure that the DMA is continuous till the whole SG list has exhausted). We then enable completion interrupts on both linked sets which results in recyling/preparing respective linked set with the next set of SG entries. The interrupt handler executes in parallel while the EDMA controller DMA's the next list. This results in no interruption. Special handling is done for first linked set (as we set up both linked sets initially before starting with the DMA), and last one where the cyclic link has to be broken and a link to the Dummy slot has to be created. Also we keep track of whether all pending DMA operations have completed before we can mark it as complete. [1] https://lkml.org/lkml/2013/7/29/312 [2] https://lkml.org/lkml/2013/7/30/54 Joel Fernandes (12): dma: edma: Setup parameters to DMA MAX_NR_SG at a time ARM: edma: Don't clear EMR of channel in edma_stop dma: edma: remove limits on number of slots dma: edma: Write out and handle MAX_NR_SG at a given time ARM: edma: Add function to enable interrupt for a PaRAM slot ARM: edma: Add pr_debug in edma_link dma: edma: Add function to dump a PaRAM set from PaRAM dma: edma: Add one more required slot to MAX slots dma: edma: Implement multiple linked sets for continuity dma: edma: Check if MAX_NR_SG is even in prep function dma: edma: Keep tracking of Pending interrupts (pending_acks) dma: edma: Return if nothing left todo in edma_execute arch/arm/common/edma.c | 18 ++- drivers/dma/edma.c | 279 +--- include/linux/platform_data/edma.h |1 + 3 files changed, 243 insertions(+), 55 deletions(-) -- 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
