On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote:
commit 5553f9e (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
now forces platform device to be registered for allowing cpufreq-cpu0
to be used by SoCs. example: drivers/cpufreq/highbank-cpufreq.c
However, for SoCs that wish
On Monday 11 March 2013 05:58 PM, Tomi Valkeinen wrote:
On 2013-03-05 16:17, Archit Taneja wrote:
The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
output.
- the TV
On 3/6/2013 9:45 PM, Matt Porter wrote:
Adds support for parsing the TI EDMA DT data into the
required EDMA private API platform data. Enables runtime
PM support to initialize the EDMA hwmod. Adds AM33XX EDMA
crossbar event mux support. Enables build on OMAP.
Signed-off-by: Matt Porter
On 3/6/2013 9:45 PM, Matt Porter wrote:
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter mpor...@ti.com
Okay the bindings the documented after they are used leading to some
confusion. This patch should be moved up the series. As I noted in my
On Mon, Mar 11, 2013 at 06:54:26PM -0700, Andrew Chew wrote:
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
This patch, along with many
On Mon, Mar 11, 2013 at 06:05:29PM -0500, Nishanth Menon wrote:
On certain SoCs like variants of OMAP, the clock conversion to DT
is not complete. In short, the ability to:
cpus {
cpu@0 {
clocks = cpuclk 0;
};
};
is not possible. However, the clock node is registered.
Allow
Copied devicetree-discuss list.
On Mon, Mar 11, 2013 at 06:05:30PM -0500, Nishanth Menon wrote:
commit 5553f9e (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
now forces platform device to be registered for allowing cpufreq-cpu0
to be used by SoCs. example:
This uses PTR_RET instead of IS_ERR and PTR_ERR in order to increase
readability.
Signed-off-by: Silviu-Mihai Popescu silviupopescu1...@gmail.com
---
arch/arm/mach-omap2/devices.c |4 ++--
arch/arm/mach-omap2/fb.c |5 +
arch/arm/mach-omap2/gpmc.c|2 +-
Hi,
On 03/11/2013 04:58 PM, Silviu-Mihai Popescu wrote:
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be
On Tue, Mar 12, 2013 at 10:16 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Hi,
On 03/11/2013 04:58 PM, Silviu-Mihai Popescu wrote:
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
On 03/12/2013 09:24 AM, Silviu Popescu wrote:
As far as I can tell from the mails that you have provided, those
patches replace devm_request_mem_region(), followed by devm_ioremap()
with devm_request_and_ioremap().
What this patch attempts to do is replace devm_request_and_ioremap()
with the
On 03/11/2013 04:58 PM, Silviu-Mihai Popescu wrote:
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be
On Tue, Mar 12, 2013 at 3:42 AM, Kumar, Anil anilkuma...@ti.com wrote:
On Mon, Mar 11, 2013 at 23:23:32, Hunter, Jon wrote:
On 03/08/2013 08:25 PM, Anil Kumar wrote:
Hi Jon,
On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter jon-hun...@ti.com wrote:
Adds basic device-tree support for OMAP3430
On 03/11/2013 05:52 PM, Marc Kleine-Budde wrote:
On 02/05/2013 08:26 AM, Felipe Balbi wrote:
Hi,
On Mon, Feb 04, 2013 at 05:58:48PM +0200, Roger Quadros wrote:
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros
On 03/11/2013 05:58 PM, Marc Kleine-Budde wrote:
On 02/05/2013 10:43 AM, Roger Quadros wrote:
On 02/05/2013 11:09 AM, Felipe Balbi wrote:
On Tue, Feb 05, 2013 at 10:44:05AM +0200, Roger Quadros wrote:
diff --git a/include/linux/usb/nop-usb-xceiv.h
b/include/linux/usb/nop-usb-xceiv.h
index
This patch implements support for interrupt pacing block of CPSW via ethtool
Inetrrupt pacing block is common of both the ethernet interface in
dual emac mode
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 104
1
Implement get phy_id via ioctl SIOCGMIIPHY. In switch mode active phy_id
is returned and in dual EMAC mode slave's specific phy_id is returned.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 16 ++--
1 file changed, 14 insertions(+), 2
Move all the slave note properties to separate section to reduce the
confusion between slave note properties and cpsw node properties
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Documentation/devicetree/bindings/net/cpsw.txt |9 +++--
1 file changed, 7 insertions(+), 2
This patch implements get/set of the phy settings via ethtool apis
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c
This patch serires implements the following features in CPSW driver
* get/set phy link settings
* interrupt pacing
* get phy id via ioctl cmd SIOCGMIIPHY
Changes from initial version
* Made active-slave common for cpts, ethtool and SIOCGMIIPHY ioctl
* Cleaned CPSW DT binding documentation by
Change cpts_active_slave to active_slave so that the same DT property
can be used to ethtool and SIOCGMIIPHY.
CC: Richard Cochran richardcoch...@gmail.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Documentation/devicetree/bindings/net/cpsw.txt |7 ---
Hi,
On 03/12/2013 02:54 AM, Andrew Chew wrote:
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Can you point me to the commit which makes a regulator mandatory for
pwm-backlight?
Why the
PHY reset GPIO handling will be done in the PHY driver
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/omap-usb-host.c | 47 ---
1 files changed, 0 insertions(+),
The helper functions omap_usbhs_rev1_hostconfig()
and omap_usbhs_rev2_hostconfig() don't write into
the hostconfig register. Make sure that we write
the return value into the hostconfig register.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c |6 +++---
1 files
This is because we want to get rid of platform_data usage from probe().
The only information we need is PORT_MODE, and this can be supplied
to us by the user (i.e. omap-usb-host.c).
We also move channel clock management from runtime PM handlers into
omap_tll_enable/disable().
Signed-off-by:
Allows the OMAP HS USB host controller to be specified
via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Mark Rutland mark.rutl...@arm.com
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 80 ++
drivers/mfd/omap-usb-host.c| 161
Allows the OMAP USB TLL module to be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/mfd/omap-usb-tll.txt | 17 +
drivers/mfd/omap-usb-tll.c | 10 ++
2 files changed, 27 insertions(+), 0
Hi Samuel,
These patches implement device tree support for the OMAP High Speed
USB Host subsystem. The corresponding EHCI SoC patches will be sent
separately and this set has no build dependencies with them.
Patch 3 is acutally a bug fix which should go into 3.9-rc. I've sent
it separately to
EHCI driver would need to know the number of ports available
on the platform. We set the nports parameter of platform_data
based on IP version if it was not already provided.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Samuel Ortiz
On 2013-03-12 08:07, Archit Taneja wrote:
On Monday 11 March 2013 05:58 PM, Tomi Valkeinen wrote:
On 2013-03-05 16:17, Archit Taneja wrote:
The support outputs struct for overlay managers is incorrect for
OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove
Hi Greg,
These patches implement device tree support for the OMAP's
EHCI host controller. The corresponding MFD/SoC patches will be sent
separately and this set has no dependeny with them.
NOTE: Last 2 patches are new and still need and Ack from Alan Stern.
Please accept this set after he has
The HSIC devices need to be kept in reset while the EHCI controller
is being initialized and only brought out of reset after the
initialization is complete, else HSIC devices will not be detected.
Signed-off-by: Roger Quadros rog...@ti.com
CC: Alan Stern st...@rowland.harvard.edu
---
Allows the OMAP EHCI controller to be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Mark Rutland mark.rutl...@arm.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
.../devicetree/bindings/usb/ehci-omap.txt | 32 +
Allows the OHCI controller found in OMAP3 and later chips to
be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Mark Rutland mark.rutl...@arm.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
.../devicetree/bindings/usb/ohci-omap3.txt | 15
Even when not in PHY mode, the USB device on the port (e.g. HUB)
might need resources like RESET which can be modelled as a PHY
device. So try to get the PHY device in any case.
Signed-off-by: Roger Quadros rog...@ti.com
CC: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-omap.c |
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ohci-omap3.c |5 ++---
1
Make use of devm_ioremap_resource() and correct comment.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-omap.c | 21 +
1 files changed, 5 insertions(+), 16 deletions(-)
diff --git
Reset GPIO handling for the PHY must be done in the PHY
driver. We use the PHY helpers instead to reset the PHY.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-omap.c | 72
PHY regulator handling must be done in the PHY driver
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-omap.c | 34 --
1 files changed, 0 insertions(+), 34
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-omap.c |5 ++---
1
In PHY mode we need to have the nop-usb-xceiv transceiver
driver to operate, so select it in Kconfig.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/Kconfig |1 +
1 files changed, 1
From: Alan Stern st...@rowland.harvard.edu
This patch (as1645) converts ehci-omap over to the new ehci-hcd is a
library approach, so that it can coexist peacefully with other EHCI
platform drivers and can make use of the private area allocated at
the end of struct ehci_hcd.
Signed-off-by: Alan
For each port that is in PHY mode we obtain a PHY device using the USB PHY
library and put it out of suspend.
It is up to platform code to associate the PHY to the controller's
port and it is up to the PHY driver to manage the PHY's resources.
Also remove weird spacing around declarations we
Hi,
On Tuesday 12 March 2013 04:14 PM, Roger Quadros wrote:
The HSIC devices need to be kept in reset while the EHCI controller
is being initialized and only brought out of reset after the
initialization is complete, else HSIC devices will not be detected.
Signed-off-by: Roger Quadros
On 03/12/2013 12:51 PM, kishon wrote:
Hi,
On Tuesday 12 March 2013 04:14 PM, Roger Quadros wrote:
The HSIC devices need to be kept in reset while the EHCI controller
is being initialized and only brought out of reset after the
initialization is complete, else HSIC devices will not be
+ Seb G.
Hi Jon,
How to you plan to merge that series?
Seb's just posted a McBSP adaptation to SDMA binding, so I'll have to
take this one before being able to merge any other SDMA driver
adaptation patches.
I'm fine to take that one, if you are OK, to avoid merge conflict in DTS
later.
On
On Tue, Mar 12, 2013 at 09:58:29AM +0200, Silviu-Mihai Popescu wrote:
This uses PTR_RET instead of IS_ERR and PTR_ERR in order to increase
readability.
Signed-off-by: Silviu-Mihai Popescu silviupopescu1...@gmail.com
---
arch/arm/mach-omap2/devices.c |4 ++--
arch/arm/mach-omap2/fb.c
On Sun, Mar 10, 2013 at 06:18:22PM +0100, Javier Martinez Canillas wrote:
+static int gpmc_probe_ethernet_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ int ret, cs;
+ unsigned long base;
+ struct resource res;
+ struct
The HSIC devices need to be kept in reset while the EHCI controller
is being initialized and only brought out of reset after the
initialization is complete, else HSIC devices will not be detected.
Also remove outdated TODO list from header.
Signed-off-by: Roger Quadros rog...@ti.com
CC: Alan
On Mon, 2013-03-04 at 16:42 +, Mark Jackson wrote:
I'm encountering an oops when remounting my ubifs volume as read/write.
# mount -o remount,rw /
[ 89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
[ 89.442122] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4]
Use resource managed kzalloc.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/otg/nop-usb-xceiv.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/otg/nop-usb-xceiv.c
Add 2 flags, needs_vcc and needs_reset to platform data.
If the flag is set and the regulator couldn't be found
then we bail out with -EPROBE_DEFER.
For device tree boot we depend on presensce of vcc-supply/
reset-supply properties to decide if we should bail out
with -EPROBE_DEFER or just
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 34 +++
drivers/usb/otg/nop-usb-xceiv.c
We use vcc as the supply name for the PHY's power supply.
The power supply will be enabled during .init() and disabled
during .shutdown()
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/otg/nop-usb-xceiv.c | 18 ++
1 files changed,
We expect the RESET line to be modeled as a regulator with supply
name reset. The regulator should be modeled such that enabling
the regulator brings the PHY device out of RESET and disabling the
regulator holds the device in RESET.
They PHY will be held in RESET in .shutdown() and brought out of
We would need to support multiple PHYs of the same type
so use the new PHY API usb_add_phy_dev() to register the PHY.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/otg/nop-usb-xceiv.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the regulator couldn't be found
then the driver will bail out with -EPROBE_DEFER.
Signed-off-by: Roger
If the PHY has a clock associated to it then manage the clock.
We just enable the clock in .init() and disable it in .shutdown().
Add clk_rate parameter in platform data and configure the
clock rate during probe if supplied.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi
Hi Felipe,
These patches add device tree support as well as PHY resource handling
(i.e. clock, reset, power) for the NOP transceiver driver.
Please add these patches before your patches that move/rename the
drivers/usb/otg/nop-usb-xceiv.c file.
NOTE: The first patch that changes platform header
Hi Tony,
These patches provide the SoC side code required to support
the changes in the OMAP USB Host drivers done in [1], [2] [3].
Device tree support is added for Beagleboard and Panda.
NOTE: The first patch needs to be shared between the
OMAP tree and Felipe's USB tree.
[1] MFD side
Model RESET and Power for HS USB Port 1 as GPIO fixed regulators
and link them to the 'nop-usb-xceiv' PHY by making them as reset
and vcc supplies.
The RESET and Power will then be managed by the PHY driver.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi
Currently on OMAP, it is not possible to specify a clock consumer
to any of the OMAP generated clocks using the device tree. This can pose
a problem for external devices that run off an OMAP clock as we
can't reliably provide a reference to the clock in the device tree.
This patch allows device
On Panda, the USB Host PHY is clocked by FREF3_CLK (auxclk3_ck) pin
of the OMAP. Provide this information in the device tree.
CC: Russell King li...@arm.linux.org.uk
CC: Rajendra Nayak rna...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 71
1 files
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 56 +
1
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi
Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Ports 1 and 2, so provide binding information for them.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link it
to the respective 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by:
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Model RESET for HS USB Ports 1 and 2 as GPIO fixed regulators and
link them to the 2 PHYs we just created.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by:
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 1, so provide binding information for it.
Model RESET and Power for HS USB Port 1 as GPIO fixed regulators
and link them to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Model RESET for HS USB Ports 1 and 2 as GPIO fixed regulators and
link them to the 2 PHYs we just created.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by:
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 1, so provide binding information for it.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-devkit8000.c | 20
1 files changed, 12
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Model RESET for HS USB Ports 1 and 2 as GPIO fixed regulators and
link them to the 2 PHYs we just created.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by:
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Model RESET for HS USB Ports 1 and 2 as GPIO fixed regulators and
link them to the 2 PHYs we just created.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by:
Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Port 1 and 2, so provide binding information for them.
Model RESET for HS USB Port 1 as GPIO fixed regulator and link it
to the 'nop-usb-xceiv' PHY on port 1.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by:
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Model RESET for HS USB Ports 1 and 2 as GPIO fixed regulators and
link them to the 2 PHYs we just created.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by:
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET and Power for HS USB Port 2 as GPIO fixed regulators
and link them to the 'nop-usb-xceiv' PHY.
NOTE: Register the PHY device only after the power regulator
Add platform device and data for 'nop-usb-xceiv'. This will be used
as PHY for HS USB port 1, so provide binding information for it.
Get rid of managing the PHY clock as it will be done by the PHY driver.
For that to work we create a clock alias that links the PHY clock name
to the PHY device
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the regulator couldn't be found
then the driver will bail out with -EPROBE_DEFER.
Signed-off-by: Roger
On 03/12/2013 12:24 PM, Roger Quadros wrote:
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the regulator couldn't be found
then the driver will
On Tuesday 12 March 2013 04:08 PM, Tomi Valkeinen wrote:
On 2013-03-12 08:07, Archit Taneja wrote:
On Monday 11 March 2013 05:58 PM, Tomi Valkeinen wrote:
On 2013-03-05 16:17, Archit Taneja wrote:
The support outputs struct for overlay managers is incorrect for
OMAP4. Make
these changes:
-
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The
Hi Roger,
On 03/12/2013 12:43 PM, Roger Quadros wrote:
Currently on OMAP, it is not possible to specify a clock consumer
to any of the OMAP generated clocks using the device tree. This can pose
a problem for external devices that run off an OMAP clock as we
can't reliably provide a reference
Hi,
On Sunday 10 March 2013 06:37 AM, Grazvydas Ignotas wrote:
In some rare cases we may get multiple interrupts that will generate
duplicate omap_musb_mailbox() calls. This is a problem because each
VBUS/ID event generates runtime_pm call in OMAP glue code, causing
unbalanced gets or puts and
On 2013-03-12 14:57, Archit Taneja wrote:
We could also use the recommended channel way for omapdrm, I can't
figure out what's the better approach at the moment.
Hmm, I think it'd be safer to use the recommended channel from omapdss
for now. The current omapdss code doesn't really let you
Hi,
On Sunday 10 March 2013 06:38 AM, Grazvydas Ignotas wrote:
On USB_EVENT_ID event the musb glue enables VBUS by calling
omap2430_musb_set_vbus(musb, 1) that sets the session bit, but on
USB_EVENT_NONE reverse action is never made, and that breaks PM.
Disable VBUS unconditionally on
Hi Benoit,
On 03/12/2013 03:17 PM, Benoit Cousson wrote:
Hi Roger,
On 03/12/2013 12:43 PM, Roger Quadros wrote:
Currently on OMAP, it is not possible to specify a clock consumer
to any of the OMAP generated clocks using the device tree. This can pose
a problem for external devices that run
On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
On 2013-03-12 14:57, Archit Taneja wrote:
We could also use the recommended channel way for omapdrm, I can't
figure out what's the better approach at the moment.
Hmm, I think it'd be safer to use the recommended channel from omapdss
On 2013-03-12 15:06, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel
driver
has these ops
On Mon, Feb 20, 2012 at 12:58 PM, Richard Watts r...@kynesim.co.uk wrote:
There is an erratum in DM3730 which results in the
EHCI USB PLL (DPLL5) not updating sufficiently frequently; this
leads to USB PHY clock drift and once the clock has drifted far
enough, the PHY's ULPI interface stops
On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote:
On 03/12/2013 12:24 PM, Roger Quadros wrote:
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the
On 03/12/2013 03:12 PM, Roger Quadros wrote:
On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote:
On 03/12/2013 12:24 PM, Roger Quadros wrote:
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc
I am removing almost all references to the above macro from arch/arm.
Many of them are wrong. Some of them are buggy.
For instance:
int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
{
int div;
div = gpmc_calc_divider(t-sync_clk);
if (div 0)
Hi Guys,
On 03/12/2013 06:03 AM, Santosh Shilimkar wrote:
On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote:
On certain SoCs like variants of OMAP, the clock conversion to DT
is not complete. In short, the ability to:
cpus {
cpu@0 {
clocks = cpuclk 0;
};
};
is not
On 03/12/2013 04:17 PM, Marc Kleine-Budde wrote:
On 03/12/2013 03:12 PM, Roger Quadros wrote:
On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote:
On 03/12/2013 12:24 PM, Roger Quadros wrote:
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that
1 - 100 of 166 matches
Mail list logo
