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
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.
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
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
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
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
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
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,
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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 ++-
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
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
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
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
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
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
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
* 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
* 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
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):
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
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
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
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
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
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,
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
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
43 matches
Mail list logo
