* Aaro Koskinen [130815 12:25]:
> 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
>On 08/15/13 13:59, Mark Rutland wrote:
>> On Thu, Aug 15, 2013 at 12:03:02PM +0100, Jonathan Cameron wrote:
>>>
> 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 place
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 cl
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 OUT
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, c
On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote:
> On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar
> wrote:
>> On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote:
>>> On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R wrote:
>>>
Initially irqchip was discussed, but we also hav
On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar
wrote:
> On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote:
>> On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R wrote:
>>
>>> Initially irqchip was discussed, but we also have a DMA crossbar
>>> to map the dma-requests. Since both irq/dma
This adds devicetree for gta04 (Openmoko next generation board) with necessary
support for mmc, usb, leds and button.
Signed-off-by: Marek Belisko
---
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 o
On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote:
> On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R 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 app
On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R 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 irqch
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)
* 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
* 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_us
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 t
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 fl
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 s
Split USB2 PHY and USB3 PHY into separate omap-control-usb
nodes. Get rid of "ti,type" property.
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.
Split otghs_ctrl and USB2 PHY power down into separate
omap-control-usb nodes. Get rid of "ti,type" property.
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4.dtsi | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/
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
---
drivers/usb/musb/omap2430.c | 22 ++
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
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 dow
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
---
drivers/usb/phy/phy-omap-control.c | 31 ++-
include/linu
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
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
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
---
drivers/usb/phy/phy-omap-control.c | 18 +++---
include/linux/usb/omap_control_usb.h |4
2 files changed, 7 insertions(+)
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 _
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
---
arch/arm/mach-omap2/usb-host.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-
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
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
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-
Use a common naming scheme "mode0name.modename flags" for the
USB host pins to be consistent.
Signed-off-by: Roger Quadros
---
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
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
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 18 +-
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boo
The GPIO number of the RESET line can be passed to the
driver using the gpio_reset member.
Signed-off-by: Roger Quadros
---
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
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 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
---
arch/arm/mach-omap2/board-omap3beagle.c |6 --
arch/a
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
---
arch/arm/boot/dts/omap5-uevm.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-ue
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
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,
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.
>>
>> In
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 trivia
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
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
---
drivers/tty/serial/omap-serial.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/driver
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
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 Fernande
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 t
44 matches
Mail list logo