Hi,
On Tue, 2013-08-13 at 13:57 -0600, Stephen Warren wrote:
> On 08/09/2013 03:53 AM, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS)
> > and HS, SS PHY's controll and configuration registers.
>
> s/controll/control/
>
Thanks.
>
* Santosh Shilimkar [130813 06:35]:
> On Tuesday 13 August 2013 04:10 AM, Tony Lindgren wrote:
> > * Santosh Shilimkar [130724 12:06]:
> >> On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote:
> >>> On 07/24/2013 01:43 PM, Sricharan R wrote:
> On Wednesday 24 July 2013 10:17 PM, Nishant
* Lee Jones [130813 08:51]:
> Tony, Benoit,
>
> Poke
Looks like Benoit's new email address is bcous...@baylibre.com.
Probably best for Benoit to pick these to avoid merge conflicts.
Regards,
Tony
> On Mon, 22 Jul 2013, Lee Jones wrote:
>
> > Cc: Benoît Cousson
> > Cc: Tony Lindgren
> > Cc
+Benoit
Hi Felipe,
Any comments on this series?
cheers,
-roger
On 08/01/2013 05:05 PM, Roger Quadros wrote:
> Hi,
>
> This patchset does the following:
>
> * Restructure and add support for new PHY types. We now support the follwing
> four types
>
> TYPE1 - if it has otghs_control mailbox r
Hi Lee,
Thanks for that cleanup.
On 14/08/2013 09:30, Tony Lindgren wrote:
* Lee Jones [130813 08:51]:
Tony, Benoit,
Poke
Looks like Benoit's new email address is bcous...@baylibre.com.
Probably best for Benoit to pick these to avoid merge conflicts.
I've just applied the 7 following pat
+Benoit
On 08/01/2013 05:05 PM, Roger Quadros wrote:
> Split otghs_ctrl and USB2 PHY power down into separate
> omap-control-usb nodes. Update ti,mode property.
>
> CC: Benoit Cousson
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/omap4.dtsi | 17 -
> 1 files change
+Benoit
On 08/01/2013 05:05 PM, Roger Quadros wrote:
> Split USB2 PHY and USB3 PHY into separate omap-control-usb
> nodes. Update ti,mode property.
>
> CC: Benoit Cousson
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/omap5.dtsi | 18 --
> 1 files changed, 12 insert
> >Looks like Benoit's new email address is bcous...@baylibre.com.
> >Probably best for Benoit to pick these to avoid merge conflicts.
Ah nice, thanks Tony.
> I've just applied the 7 following patches. Let me know if I missed
> something.
>
> 6b9fa1b ARM: dts: Remove '0x's from OMAP5 DTS file
>
Hi Robert,
On 07/08/2013 16:14, Robert Nelson wrote:
Signed-off-by: Robert Nelson
---
arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..0c5
+Benoit
On 07/24/2013 05:32 PM, Roger Quadros wrote:
> The USB PHY gets its clock from AUXCLK3. Provide this
> information.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/omap4-panda-common.dtsi |8 ++--
> 1 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/ar
+Benoit
On 07/24/2013 05:32 PM, Roger Quadros wrote:
> Hi,
>
> These patches provide USB host support for the OMAP5 uEVM board.
>
> They depend on the OMAP clock tree DT data series by Tero Kristo [1]
>
> In patch 3 we also provide USB PHY clock for Panda. This should make
> the clock alias pat
+Benoit
On 07/24/2013 05:32 PM, Roger Quadros wrote:
> The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
> information.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/omap5-uevm.dts |8 ++--
> 1 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/a
On 08/14/2013 11:11 AM, Roger Quadros wrote:
> +Benoit
>
> On 07/24/2013 05:32 PM, Roger Quadros wrote:
>> The USB PHY gets its clock from AUXCLK3. Provide this
>> information.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/boot/dts/omap4-panda-common.dtsi |8 ++--
>> 1 files chan
The OMAP4 SoC family uses specially-designed
PMIC (power management IC) companion chip for power
management needs: TWL6030/TWL6032.
Therefore there is a typical connection of PMIC to OMAP4
so we can figure it out into separate .dtsi file
and do not duplicate over board-specific files.
Tested on OM
Hello,
There is no functional changes between v1 and v2 - just
added the patch for omap4-var-som - Uri Yosef confirmed
this board have the same connection of OMAP4<->TWL6030 as
SDP4430 board
Ruslan Bilovol (2):
arm: dts: twl6030: typical connection to omap4 as a separate dtsi
file
arm: dt
Now when typical OMAP4 to PMIC connection is figured out
into separate .dtsi file, ve can configure properly OMAP4
pins connected to TWL6030 just including one.
Signed-off-by: Ruslan Bilovol
---
arch/arm/boot/dts/omap4-var-som.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/b
* Rajendra Nayak [130813 04:45]:
> Hi Tony,
>
> Heres an updated pull request dropping the dts files.
>
> The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
>
> Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)
>
> are available in the git repository at:
>
> git://githu
* Felipe Balbi [130809 07:35]:
> Hi Tony,
>
> here's a pull request of one patch to avoid conflicts during the merge
> window.
>
> Please consider applying to your tree and I'll take this same patch
> upstream.
Thanks, pulling into omap-for-v3.12/usb.
Regards,
Tony
> The following changes s
Hi Roger,
On 01/08/2013 16:05, Roger Quadros wrote:
> Split otghs_ctrl and USB2 PHY power down into separate
> omap-control-usb nodes. Update ti,mode property.
Nit: I guess you mean ti,type?
> CC: Benoit Cousson
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/omap4.dtsi | 17 +
On 8/14/2013 3:50 AM, Russ Dill wrote:
> Changes since v1:
> * Rebased onto new am335x PM branch
>
> This adds a sleep and wake sequence to set the VDD core voltage to the
> OPP50 level, 0.950V. This saves power during suspend. The sequences are
> specific to the Beaglebone layout and PMIC, the TP
On 08/14/2013 11:41 AM, Benoit Cousson wrote:
> Hi Roger,
>
> On 01/08/2013 16:05, Roger Quadros wrote:
>> Split otghs_ctrl and USB2 PHY power down into separate
>> omap-control-usb nodes. Update ti,mode property.
>
> Nit: I guess you mean ti,type?
Right :).
>
>> CC: Benoit Cousson
>> Signed-
On 13/08/13 21:12, Andrew Ruder wrote:
> Sorry for the late reply, I've been thinking about this for some time
> and was sad to see it didn't really evoke any sort of discussion :(.
>
> On Sat, Aug 10, 2013 at 02:58:08PM +0100, Mark Jackson wrote:
>> When a UART transmitter is connected to (eg) a
From: Julia Lawall
Remove unneeded error handling on the result of a call to
platform_get_resource when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
//
@@
expression pdev,res,n,e,e1;
devm_ioremap_resource often uses the result of a call to
platform_get_resource as its last argument. devm_ioremap_resource does
appropriate error handling on this argument, so error handling can be
removed from the call site. To make the connection between the call to
platform_get_resource and th
Hi,
On Mon, 2013-08-12 at 13:24 -0500, Felipe Balbi wrote:
> On Fri, Aug 09, 2013 at 07:09:18PM +0300, Ivan T. Ivanov wrote:
> > Hi,
> >
> > On Fri, 2013-08-09 at 16:23 +0300, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Tue, Aug 06, 2013 at 02:53:11PM +0300, Ivan T. Ivanov wrote:
> > > > di
Hi Felipe,
On 07/25/2013 08:28 PM, Felipe Balbi wrote:
> On Thu, Jul 18, 2013 at 11:53:05AM +0300, Roger Quadros wrote:
>> Till now we were modelling the RESET line as a voltage regulator and
>> using the regulator framework to manage it.
>>
>> [1] introduces a GPIO based reset controller driver.
On Tuesday 13 August 2013 03:35 PM, Marc Zyngier wrote:
> On 2013-08-13 10:46, Mark Rutland wrote:
>> [Adding Marc to Cc]
>>
>> On Tue, Aug 13, 2013 at 08:24:31AM +0100, Rajendra Nayak wrote:
>>> []..
>>>
>>> >> +
>>> >> + cpus {
>>> >> + cpu@0 {
>>> >> + c
Hi,
On Fri, 2013-08-09 at 16:23 +0300, Felipe Balbi wrote:
>
> > + /*
> > +* DWC3 Core requires its CORE CLK (aka master / bus clk) to
> > +* run at 125Mhz in SSUSB mode and >60MHZ for HSUSB mode.
> > +*/
> > + clk_set_rate(mdwc->core_clk, 12500);
>
> if this is dwc3's co
On 8/14/2013 3:50 AM, Russ Dill wrote:
> Changes since v1:
> * Rebased onto new am335x PM branch
> * Changed to use 5th param register
>
> Changes since v2:
> * Passes I2C bus speed in kHz to M3 firmware
>
> Changes since v3:
> * Rebased to 3.11-rc3, moves some functionality to wkup_m3.c
> * Addi
On Friday 09 August 2013 03:05 AM, Laurent Pinchart wrote:
Hi Archit,
On Monday 05 August 2013 16:56:46 Archit Taneja wrote:
On Monday 05 August 2013 01:43 PM, Tomi Valkeinen wrote:
On 02/08/13 17:03, Archit Taneja wrote:
+struct vpdma_data_format vpdma_yuv_fmts[] = {
+ [VPDMA_DATA_FMT_
Hi Benoit,
* Benoit Cousson, August 13, 2013 5:15 PM:
> + Few TI folks to review and test.
I am out of office, will be back early next week and then test this.
Regards
Afzal--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel
From: R Sricharan
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart
This patch adds RS485 support to the OMAP serial driver, as
defined in:-
Documentation/devicetree/bindings/serial/rs485.txt
When a UART transmitter is connected to (eg) a RS485 driver, it is
necessary to turn the driver on/off as quickly as possible. This is
best achieved in the serial driver it
On 2013-08-14 11:25, Rajendra Nayak wrote:
From: R Sricharan
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin
On 08/10/2013 01:59 PM, Ezequiel Garcia wrote:
> Is there any reason why there's no DT binding patch to this
> series? (aka Documentation/devicetree/... + sent to devicetree list)
>
> (sorry if this has been already explained somewhere...)
>
Completely forgot. There are existent documents which
On Friday 09 August 2013 03:34 AM, Laurent Pinchart wrote:
Hi Archit,
Thank you for the patch.
On Friday 02 August 2013 19:33:38 Archit Taneja wrote:
The primary function of VPDMA is to move data between external memory and
internal processing modules(in our case, VPE) that source or sink data
On Wednesday 14 August 2013 04:04 PM, Marc Zyngier wrote:
> On 2013-08-14 11:25, Rajendra Nayak wrote:
>> From: R Sricharan
>>
>> Add minimal device tree source needed for DRA7 based SoCs.
>> Also add a board dts file for the dra7-evm (based on dra752)
>> which contains 1.5G of memory with 1G inte
From: R Sricharan
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart
Hi Rajendra,
On 14/08/2013 14:10, Rajendra Nayak wrote:
From: R Sricharan
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board
Hi Rajendra,
On Tue, Jul 23, 2013 at 1:24 AM, Rajendra Nayak wrote:
[..]
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 12fa589..e5c804b 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -805,6 +805,65 @@ s
Hi Rajendra,
On Tue, Jul 23, 2013 at 1:24 AM, Rajendra Nayak wrote:
[...]
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 5cc5123..12fa589 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2381,12 +2386,10
From: "Ivan T. Ivanov"
Hi,
These patches add basic support for USB3.0 controllers found
on MSM platforms. USB3.0 core is based on Synopsys DesignWare
SuperSpeed IP.
Changes since v2:
* Several improvements in devicetree bindings description
* Disable regulators in glue layer if there is error
From: "Ivan T. Ivanov"
These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/Kconfig | 11 ++
From: "Ivan T. Ivanov"
DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/dwc3/Kconfig|8 ++
drivers/usb/dwc
From: "Ivan T. Ivanov"
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration registers.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/usb/msm-ssusb.t
On Wednesday 14 August 2013 06:04 PM, Benoit Cousson wrote:
> Hi Rajendra,
>
> On 14/08/2013 14:10, Rajendra Nayak wrote:
>> From: R Sricharan
>>
>> Add minimal device tree source needed for DRA7 based SoCs.
>> Also add a board dts file for the dra7-evm (based on dra752)
>> which contains 1.5G of
On Wednesday 14 August 2013 06:18 PM, Nishanth Menon wrote:
> Hi Rajendra,
>
> On Tue, Jul 23, 2013 at 1:24 AM, Rajendra Nayak wrote:
> [..]
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
>> b/arch/arm/mach-omap2/omap_hwmod.c
>> index 12fa589..e5c804b 100644
>> --- a/arch/arm/mach-omap2/omap_h
On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote:
> The purpose and method of executing these sequences is left up to each
> platform. In the case of the am33xx, the CM3 firmware writes out the
> simple I2C sequences.
>
> Each sequence is a series of I2C write commands. The first byte is the
> l
On 08/14/2013 08:20 AM, Rajendra Nayak wrote:
On Wednesday 14 August 2013 06:18 PM, Nishanth Menon wrote:
Hi Rajendra,
On Tue, Jul 23, 2013 at 1:24 AM, Rajendra Nayak wrote:
[..]
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 12fa589..e5c804b 100644
---
From: R Sricharan
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart
On Wednesday 14 August 2013 07:09 PM, Nishanth Menon wrote:
> On 08/14/2013 08:20 AM, Rajendra Nayak wrote:
>> On Wednesday 14 August 2013 06:18 PM, Nishanth Menon wrote:
>>> Hi Rajendra,
>>>
>>> On Tue, Jul 23, 2013 at 1:24 AM, Rajendra Nayak wrote:
>>> [..]
diff --git a/arch/arm/mach-omap2/
[Adding Mike Turquette and dt maintainers to Cc]
On Tue, Jul 23, 2013 at 07:24:38AM +0100, Rajendra Nayak wrote:
> With clocks for OMAP moving to DT, its now possible to pass all optional clock
> data for each device from DT instead of having it in hwmod.
>
> Signed-off-by: Rajendra Nayak
> ---
[Adding Mike Turquette and dt maintainers]
On Wed, Aug 14, 2013 at 02:39:44PM +0100, Nishanth Menon wrote:
> On 08/14/2013 08:20 AM, Rajendra Nayak wrote:
> > On Wednesday 14 August 2013 06:18 PM, Nishanth Menon wrote:
> >> Hi Rajendra,
> >>
> >> On Tue, Jul 23, 2013 at 1:24 AM, Rajendra Nayak wr
Hi Ruslan,
On 14/08/2013 10:35, Ruslan Bilovol wrote:
Hello,
There is no functional changes between v1 and v2 - just
added the patch for omap4-var-som - Uri Yosef confirmed
this board have the same connection of OMAP4<->TWL6030 as
SDP4430 board
The series looks good to me, but it will be good
On Wednesday 14 August 2013 07:15 PM, Mark Rutland wrote:
> [Adding Mike Turquette and dt maintainers to Cc]
>
> On Tue, Jul 23, 2013 at 07:24:38AM +0100, Rajendra Nayak wrote:
>> With clocks for OMAP moving to DT, its now possible to pass all optional
>> clock
>> data for each device from DT ins
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/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-
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
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
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
On 08/14/2013 08:49 AM, Mark Rutland wrote:
[Adding Mike Turquette and dt maintainers]
On Wed, Aug 14, 2013 at 02:39:44PM +0100, Nishanth Menon wrote:
On 08/14/2013 08:20 AM, Rajendra Nayak wrote:
On Wednesday 14 August 2013 06:18 PM, Nishanth Menon wrote:
Hi Rajendra,
On Tue, Jul 23, 2013 a
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
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-
On Wed, Aug 14, 2013 at 02:49:04PM +0100, Mark Rutland wrote:
> [Adding Mike Turquette and dt maintainers]
>
> On Wed, Aug 14, 2013 at 02:39:44PM +0100, Nishanth Menon wrote:
> > yes. the idea being, we now have a meaning to the clock name - there are
> > two types of clocks here.. functional and
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
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
On Wed, Aug 14, 2013 at 02:54:57PM +0100, Rajendra Nayak wrote:
> On Wednesday 14 August 2013 07:15 PM, Mark Rutland wrote:
> > [Adding Mike Turquette and dt maintainers to Cc]
> >
> > On Tue, Jul 23, 2013 at 07:24:38AM +0100, Rajendra Nayak wrote:
> >> With clocks for OMAP moving to DT, its now p
On Wednesday 14 August 2013 07:28 PM, Nishanth Menon wrote:
> On 08/14/2013 08:49 AM, Mark Rutland wrote:
>> [Adding Mike Turquette and dt maintainers]
>>
>> On Wed, Aug 14, 2013 at 02:39:44PM +0100, Nishanth Menon wrote:
>>> On 08/14/2013 08:20 AM, Rajendra Nayak wrote:
On Wednesday 14 August
On Wed, Aug 14, 2013 at 02:58:25PM +0100, Nishanth Menon wrote:
> On 08/14/2013 08:49 AM, Mark Rutland wrote:
> > [Adding Mike Turquette and dt maintainers]
> >
> > On Wed, Aug 14, 2013 at 02:39:44PM +0100, Nishanth Menon wrote:
> >> On 08/14/2013 08:20 AM, Rajendra Nayak wrote:
> >>> On Wednesday
On Wed, Aug 14, 2013 at 03:05:25PM +0100, Rajendra Nayak wrote:
> On Wednesday 14 August 2013 07:28 PM, Nishanth Menon wrote:
> > On 08/14/2013 08:49 AM, Mark Rutland wrote:
> >> [Adding Mike Turquette and dt maintainers]
> >>
> >> On Wed, Aug 14, 2013 at 02:39:44PM +0100, Nishanth Menon wrote:
> >
[]..
>
> From the sounds of your other reply, the issue is that you're poking
> clocks for arbitrary devices, without knowing the semantics of those
> clocks, because you're doing it form outside the driver.
Thats right.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
+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
---
changes from v2
change synopsis to
On Wednesday 14 August 2013 07:35 PM, Rajendra Nayak wrote:
> On Wednesday 14 August 2013 07:28 PM, Nishanth Menon wrote:
>> On 08/14/2013 08:49 AM, Mark Rutland wrote:
>>> [Adding Mike Turquette and dt maintainers]
>>>
>>> On Wed, Aug 14, 2013 at 02:39:44PM +0100, Nishanth Menon wrote:
On 08/
On Wed, Aug 14, 2013 at 03:59:42PM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
> These drivers handles control and configuration of the HS
> and SS USB PHY transceivers. They are part of the driver
> which manage Synopsys DesignWare USB3 controller stack
> inside Qualcomm SoC's.
>
>
On Wednesday 14 August 2013 07:43 PM, Mark Rutland wrote:
> On Wed, Aug 14, 2013 at 03:05:25PM +0100, Rajendra Nayak wrote:
>> On Wednesday 14 August 2013 07:28 PM, Nishanth Menon wrote:
>>> On 08/14/2013 08:49 AM, Mark Rutland wrote:
[Adding Mike Turquette and dt maintainers]
On Wed
+ 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
On 08/14/2013 09:20 AM, Rajendra Nayak wrote:
> On Wednesday 14 August 2013 07:43 PM, Mark Rutland wrote:
>> On Wed, Aug 14, 2013 at 03:05:25PM +0100, Rajendra Nayak wrote:
>>> On Wednesday 14 August 2013 07:28 PM, Nishanth Menon wrote:
On 08/14/2013 08:49 AM, Mark Rutland wrote:
> [Adding
Hi Luca,
On 30/07/2013 22:21, Luciano Coelho wrote:
Add device tree bindings documentation for the TI WiLink modules.
Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
modules is supported.
Signed-off-by: Luciano Coelho
---
In v3, use IRQ_TYPE_LEVEL_HIGH in the example, as sugg
Hi,
On Wed, 2013-08-14 at 09:20 -0500, Josh Cartwright wrote:
> On Wed, Aug 14, 2013 at 03:59:42PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > These drivers handles control and configuration of the HS
> > and SS USB PHY transceivers. They are part of the driver
> > which m
Hi,
On Wednesday 14 August 2013 04:34 AM, Tomasz Figa wrote:
> On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
>> W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
>>> On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vi
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 drive
Here are some basic OMAP test results for Linux v3.11-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.11-rc4/20130814082546/
I'm sorry to report that my second OMAP5912 OSK has bitten the dust. So
until I can get my hands on another one, I won't be able to boot-t
Here are some basic OMAP test results for Linux v3.11-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.11-rc5/20130814083603/
Test summary
Build: uImage:
Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
omap1_defc
On 08/14/13 05:59, Ivan T. Ivanov wrote:
> +}
> +
> +static const struct of_device_id of_dwc3_matach[] = {
match? Maybe you can make it all one line too { .compatible = "qcom,dwc3" }
> + {
> + .compatible = "qcom,dwc3",
> + },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, of_d
On 08/13/2013 11:24 PM, 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 remo
On Tue, Jul 30, 2013 at 12:01 AM, Stephen Warren wrote:
> I was thinking more about people writing the device trees that define
> these states; they need to explicitly make the choice re: overlapping
> states or independent states. We should not plan to obsolete any current
> usage of overlapping
Kevin, Santosh, Dave, Russ,
On 08/13/2013 02:11 PM, Kevin Hilman wrote:
> Russ Dill writes:
>
> ARM world is also moving towards that by standardizing some of these
> through (read PSCI) and thats the way to go in general.
Agreed, but I'm not sure (yet) about enforcing PSCI on
On Wed, 2013-08-14 at 09:06 -0700, Stephen Boyd wrote:
> On 08/14/13 05:59, Ivan T. Ivanov wrote:
> > +}
> > +
> > +static const struct of_device_id of_dwc3_matach[] = {
>
> match? Maybe you can make it all one line too { .compatible = "qcom,dwc3" }
>
Thanks. Will do.
Ivan
> > + {
> > +
On Wed, Aug 14, 2013 at 10:27 AM, Suman Anna wrote:
> Kevin, Santosh, Dave, Russ,
>
> On 08/13/2013 02:11 PM, Kevin Hilman wrote:
>> Russ Dill writes:
>>
>> ARM world is also moving towards that by standardizing some of these
>> through (read PSCI) and thats the way to go in general.
On 07/25/13 14:26, Oleksandr Kozaruk wrote:
> The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
> known also as Phoenix and PhoenixLite.
>
> The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
> respectively. Some channels have current source and are used for
> measuring v
On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe wrote:
> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote:
>> The purpose and method of executing these sequences is left up to each
>> platform. In the case of the am33xx, the CM3 firmware writes out the
>> simple I2C sequences.
>>
>> Each sequence is
On Wed, Aug 14, 2013 at 1:59 AM, Gururaja Hebbar wrote:
> On 8/14/2013 3:50 AM, Russ Dill wrote:
>> Changes since v1:
>> * Rebased onto new am335x PM branch
>>
>> This adds a sleep and wake sequence to set the VDD core voltage to the
>> OPP50 level, 0.950V. This saves power during suspend. The seq
On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar wrote:
> On 8/14/2013 3:50 AM, Russ Dill wrote:
>> Changes since v1:
>> * Rebased onto new am335x PM branch
>> * Changed to use 5th param register
>>
>> Changes since v2:
>> * Passes I2C bus speed in kHz to M3 firmware
>>
>> Changes since v3:
>> * R
Intermdiate buffers were allocated, mapped and used for DMA.
These are no longer required as we use the SGs from crypto layer
directly in previous commits in the series. Also along with it,
remove the logic for copying SGs etc as they are no longer used,
and all the associated variables in omap_aes
Crypto layer only passes nbytes to encrypt but in omap-aes driver we
need to know number of SG elements to pass to dmaengine slave API.
We add function for the same to scatterwalk library.
Signed-off-by: Joel Fernandes
---
crypto/scatterwalk.c | 22 ++
include/crypt
Crypto layer only passes nbytes but number of SG elements is needed
for mapping/unmapping SGs at one time using dma_map* API and also
needed to pass in for dmaengine prep function.
We call function added to scatterwalk for this purpose in omap_aes_handle_queue
to populate the values which are used
Earlier functions that did a similar sync are replaced by
the dma_sync_sg_* which can operate on entire SG list.
Signed-off-by: Joel Fernandes
---
drivers/crypto/omap-aes.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 9104
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
In early version of this driver, assumptions were made such as
DMA layer requires contiguous buffers etc. Due to this, new buffers
were allocated, mapped and used for DMA. These assumptions are no
longer true and DMAEngine scatter-gather DMA doesn't have such
requirements. We simply the DMA operati
1 - 100 of 112 matches
Mail list logo