Hi,
On Thu, Mar 14, 2013 at 4:23 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Mar 14, 2013 at 04:14:58PM +0530, Vivek Gautam wrote:
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.
Signed-off-by: Vivek Gautam
Hi,
On Fri, Mar 15, 2013 at 11:36:00AM +0530, Vivek Gautam wrote:
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
CC: Felipe Balbi ba...@ti.com
CC: Kukjin Kim
Based on 'for-next' of linux-samsung tree with following patches
from Doug on top:
usb: Document clocks in samsung, exynos4210-ehci/ohci bindings
ARM: dts: add usb 2.0 clock references to exynos5250 device tree
Also depending upon following patch-series for Samsung-usb-phy driver:
[PATCH v7 0/2]
Adding usbphy node for Exynos5250 along with the
necessary device data to be parsed.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git
Adding usb3.0 phy node for Exynos5250 along with the
necessary device data to be parsed.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git
This patch-set is in continuation with patch-series:
[PATCH v4 0/4] Enable ehci, ohci and dwc3 devices on exynos5250
out of which follwowing patches have been picked up:
ARM: Exynos5250: Enabling ehci-s5p driver
ARM: Exynos5250: Enabling ohci-exynos driver
Based on following patch-set for
Document device tree binding information as required by the
Samsung' USB 3.0 controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/usb/exynos-usb.txt | 34
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git
Adding DWC3 device tree node for Exynos5250 needed to
parse device tree data.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
This patch enables support for XHCI on exynos5 series of SOCs,
to support host side USB 3.0 support.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/mach-exynos/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig
Doug,
On 14 March 2013 02:09, Doug Anderson diand...@chromium.org wrote:
The exynos ADC won't work without a regulator called vdd and a clock
called adc. Document this fact in the device tree bindings.
Signed-off-by: Doug Anderson diand...@chromium.org
Thanks for the correction. Clocks and
On Fri, Mar 15, 2013 at 11:42:48AM +0800, Shawn Guo wrote:
On Thu, Mar 14, 2013 at 02:08:32PM +0100, Markus Pargmann wrote:
On Wed, Mar 13, 2013 at 10:18:29AM +0800, Shawn Guo wrote:
On Tue, Mar 12, 2013 at 07:02:07PM +, Mark Brown wrote:
On Sun, Mar 10, 2013 at 07:33:09PM +0100,
On 03/14/2013 06:54 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130314 08:45]:
OK. Let me know how the below patch looks. After that, the board code
will look like.
static struct usbhs_phy_data phy_data[] = {
{
.reset_gpio = 147,
.vcc_gpio = 148
Hi Kishon,
On 03/13/2013 10:11 AM, kishon wrote:
Benoit,
Will you be queuing this patch series?
I'm reviewing them right now.
Regards,
Benoit
Thanks
Kishon
On Thursday 07 March 2013 07:05 PM, Kishon Vijay Abraham I wrote:
Hi Benoit,
Here are the dt data patches to get usb device
Hi Mark,
On 3/7/2013 11:56 AM, Vishwanathrao Badarkhe, Manish wrote:
Add device tree data for regulator via tps6507x mfd device
in da850-evm.
Applies on top of v3.9-rc1 of linus tree.
I would like to take this series via the davinci tree to manage
dependencies with rest of the DT patches.
Le 03/14/13 19:08, Florian Fainelli a écrit :
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register a Marvell Orion MDIO driver. This driver
On Fri, Mar 8, 2013 at 12:14 AM, Jon Hunter jon-hun...@ti.com wrote:
On 03/02/2013 02:05 PM, Grant Likely wrote:
On Tue, 26 Feb 2013 17:01:22 -0600, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 04:44 PM, Stephen Warren wrote:
On 02/26/2013 03:40 PM, Jon Hunter wrote:
On 02/26/2013
Dear Florian Fainelli,
On Fri, 15 Mar 2013 12:07:12 +0100, Florian Fainelli wrote:
Thanks to the help of Andrew Lunn, there is at least two known issues
with this patch version:
- we need to move up the mvmdio line in
drivers/net/ethernet/marvell/Makefile to make sure that configs having
On 14 March 2013 02:10, Doug Anderson diand...@chromium.org wrote:
Without this change the exynos adc controller needed to have its phy
enabled in some out-of-driver C code. Add support for specifying the
phy enable register by listing it in the reg list.
Signed-off-by: Doug Anderson
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the
+ Jon
Hi Kishon,
On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote:
Hi Benoit,
Here are the dt data patches to get usb device functional in OMAP platforms.
All the patches deal with modifying arch/arm/boot except one which modifies
Documentation/../usb/omap-usb.txt
Changes from v2:
From: Florian Fainelli flor...@openwrt.org
Date: Thu, 14 Mar 2013 19:08:31 +0100
This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
instead of rolling its own implementation. As a result, all users of this
mv643xx_eth driver are converted to register an orion-mdio
Le 03/15/13 13:53, David Miller a écrit :
From: Florian Fainelli flor...@openwrt.org
Date: Thu, 14 Mar 2013 19:08:31 +0100
This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
instead of rolling its own implementation. As a result, all users of this
mv643xx_eth driver
From: David Miller da...@davemloft.net
Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
From: Florian Fainelli flor...@openwrt.org
Date: Thu, 14 Mar 2013 19:08:31 +0100
This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
instead of rolling its own implementation. As a
Hi Javier,
On 03/15/2013 01:18 PM, Javier Martinez Canillas wrote:
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the
Le 03/15/13 13:55, David Miller a écrit :
From: David Miller da...@davemloft.net
Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
From: Florian Fainelli flor...@openwrt.org
Date: Thu, 14 Mar 2013 19:08:31 +0100
This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
instead
From: Florian Fainelli flor...@openwrt.org
Date: Fri, 15 Mar 2013 13:53:10 +0100
Le 03/15/13 13:55, David Miller a écrit :
From: David Miller da...@davemloft.net
Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
From: Florian Fainelli flor...@openwrt.org
Date: Thu, 14 Mar 2013 19:08:31 +0100
Le 03/15/13 14:05, David Miller a écrit :
From: Florian Fainelli flor...@openwrt.org
Date: Fri, 15 Mar 2013 13:53:10 +0100
Le 03/15/13 13:55, David Miller a écrit :
From: David Miller da...@davemloft.net
Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
From: Florian Fainelli flor...@openwrt.org
On Fri, Mar 15, 2013 at 1:56 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 03/15/2013 01:18 PM, Javier Martinez Canillas wrote:
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller
Hi Sekhar,
On Thu, Feb 28, 2013 at 16:09:47, Nori, Sekhar wrote:
Prakash,
On 2/19/2013 2:02 PM, Manjunathappa, Prakash wrote:
DT kernel with latest of denx SPL U-boot boots with garbled UART
logs. This is because in U-boot UART2 gets sourced by PLL0_SYSCLK2
configured for 150MHz. But
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
property but its description after.
This is confusing so we move #interrupt-cells after the
interrupt-controller property so is followed by its description.
While being
On Friday 15 March 2013 06:11 PM, Benoit Cousson wrote:
+ Jon
Hi Kishon,
On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote:
Hi Benoit,
Here are the dt data patches to get usb device functional in OMAP platforms.
All the patches deal with modifying arch/arm/boot except one which modifies
Differences since v4:
- Split out changes to gpio-generic into patch 1
- Make the basic driver without any irq support into patch 2, so that
things can be applied so far if more revisions needs to be done for
the irq support parts.
- Change irq support to use irq domain and put it in patch 3
There is no general support for 64-bit big endian accesses, so that is
left unsupported.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
drivers/gpio/gpio-generic.c | 56 ---
include/linux/basic_mmio_gpio.h |1 +
2 files changed, 48
This driver supports GRGPIO gpio cores available in the GRLIB VHDL IP
core library from Aeroflex Gaisler.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
.../devicetree/bindings/gpio/gpio-grgpio.txt | 24 +++
drivers/gpio/Kconfig |9 ++
The drivers sets up an irq domain and hands out unique virqs to irq
capable gpio lines regardless of which underlying irqs maps to which gpio
line.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
.../devicetree/bindings/gpio/gpio-grgpio.txt |5 +
drivers/gpio/gpio-grgpio.c
On 16:42-20130314, Jon Hunter wrote:
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
migrating the cpufreq support only through device
On 16:44-20130314, Jon Hunter wrote:
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
Add DT OPP table for OMAP36xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function. This
overrides the default OMAP34xx CPU OPP table definition.
Not sure I following
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete series for v3.10.
This is based upon Benoit's for_3.10/dts branch [1]. Branch available
here [2].
V2 changes:
-
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 11 +++
arch/arm/boot/dts/omap2430.dtsi | 11 +++
arch/arm/boot/dts/omap4.dtsi| 11 +++
Add gpios bindings for OMAP2420 and OMAP2430 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 44 +++
arch/arm/boot/dts/omap2430.dtsi | 55 +++
2 files changed, 99 insertions(+)
diff
The OMAP3 gpio bindings are currently missing the reg and interrupt
properties and so add these properties.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC peripheral on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM, 128MB ONENAND flash, 256MB NAND flash and uses the TWL4030
power management IC.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3430-sdp.dts | 141
On 16:49-20130314, Jon Hunter wrote:
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
OMAP4430 and 4460 have different OPP definitions. So, create an SoC
variant dtsi file for 4460 and move the OPP definitions to it.
FYI, I had to create a similar file for PMU [1]. However, I called it
On Thu, Mar 14, 2013 at 11:51 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On Fri, Mar 15, 2013 at 2:28 AM, Nishanth Menon n...@ti.com wrote:
We can now use cpufreq-cpu0 driver using DT entries.
remove the redundant omap-cpufreq driver from the tree.
Remove MAINTAINERS file entry for the
On 03/15/2013 08:56 AM, Nishanth Menon wrote:
On 16:44-20130314, Jon Hunter wrote:
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
Add DT OPP table for OMAP36xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function. This
overrides the default OMAP34xx CPU OPP
Hi Jon,
On 03/15/2013 02:57 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete series for v3.10.
This is based upon Benoit's
On 09:26-20130315, Jon Hunter wrote:
On 03/15/2013 08:56 AM, Nishanth Menon wrote:
On 16:44-20130314, Jon Hunter wrote:
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
Add DT OPP table for OMAP36xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function
On 3/15/2013 6:56 PM, Manjunathappa, Prakash wrote:
Hi Sekhar,
On Thu, Feb 28, 2013 at 16:09:47, Nori, Sekhar wrote:
Prakash,
On 2/19/2013 2:02 PM, Manjunathappa, Prakash wrote:
DT kernel with latest of denx SPL U-boot boots with garbled UART
logs. This is because in U-boot UART2 gets
On 03/15/2013 09:21 AM, Nishanth Menon wrote:
On 10:48-20130315, Santosh Shilimkar wrote:
On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote:
The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
for doing CPU DVFS using cpufreq-cpu0. This series will eventually
On 03/15/2013 09:38 AM, Nishanth Menon wrote:
On 09:26-20130315, Jon Hunter wrote:
On 03/15/2013 08:56 AM, Nishanth Menon wrote:
On 16:44-20130314, Jon Hunter wrote:
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
Add DT OPP table for OMAP36xx family of devices. This data is
decoded
On 09:56-20130315, Jon Hunter wrote:
[..]
But, that said, there is one path I see possible:
- keep omap-cpufreq alive (BUT I will add a patch that will not let it init
when in DT entries are present)
- add DT entries for all relevant OMAPs - in DT mode, we will *only*
support cpufreq
On 09:58-20130315, Jon Hunter wrote:
On 03/15/2013 09:38 AM, Nishanth Menon wrote:
On 09:26-20130315, Jon Hunter wrote:
On 03/15/2013 08:56 AM, Nishanth Menon wrote:
On 16:44-20130314, Jon Hunter wrote:
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
Add DT OPP table for OMAP36xx
Hello,
It took me some time to get back to this topic due to my holidays and other
urgent issues. I hope that this I will be able to participate a bit more
actively.
On 2/14/2013 10:30 PM, Sascha Hauer wrote:
Hi Marek,
On Thu, Feb 14, 2013 at 01:45:26PM +0100, Marek Szyprowski wrote:
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.
v2:
- Added helper
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
This helper allows board support code to add the PHY's
VCC and RESET regulators which are GPIO controlled.
It also links the vcc and reset supplies to the
PHY's device ID that is supplied in the struct usbhs_phy_data
argument.
Signed-off-by: Roger Quadros rog...@ti.com
---
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
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.
The VCC and RESET will then be managed by the PHY driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 37 +--
1 files changed, 11 insertions(+), 26
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.
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 44
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.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 47
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.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c | 48
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.
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-am3517crane.c | 38
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.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 41
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.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 45
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.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-cm-t3517.c | 45
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 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.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-igep0020.c | 66
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.
Use usbhs_init_phys() to register the PHY's RESET regulator.
VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros rog...@ti.com
---
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.
Use usbhs_init_phys() to register the PHY's RESET regulator.
VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros rog...@ti.com
---
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.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3stalker.c | 29
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.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3touchbook.c |
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.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-overo.c | 32
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.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-zoom.c | 32
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git
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.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 56
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git
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.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 71
While adding device-tree support for NOR memories, it became apparent
that there is no common way for configuring various GPMC settings for
devices that interface to the GPMC. These settings include bus-width,
synchronous/asynchronous mode, burst settings, wait monitoring etc.
Therefore, to
The OMAP2+ code that configures the GPMC for ONENAND devices is copying
structures between functions unnecessarily. Avoid this by passing
pointers instead and simplify the code.
A pointer to structure omap_onenand_platform_data is passed to the
function omap2_onenand_calc_sync_timings(), but only
The GPMC has wait-pin signals that can be assigned to a chip-select
to monitor the ready signal of an external device. Add a variable to
indicate the total number of wait-pins for a given device. This will
allow us to detect if the wait-pin being selected is valid or not.
When booting with
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no common function for configuring these options and
various devices set these options by either programming the GPMC CONFIG1
register
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no central structure for storing all these options
when configuring the GPMC for a given device. Some of the options are
stored in the GPMC
Convert the OMAP2+ ONENAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 61
Hello,
On 2/14/2013 10:34 PM, Laura Abbott wrote:
On 2/14/2013 4:45 AM, Marek Szyprowski wrote:
snip
+name:an name given to the defined region.
+base-address:the base address of the defined region.
+size:the size of the memory region.
+linux,contiguous-region: property
Convert the OMAP2+ NAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
This moves the configuration of some GPMC options outside the
nand_gpmc_retime() because these options should only need to be
Convert the OMAP2+ SMC91x code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Move configuration of the GPMC settings outside retime function and
this does not need to be done if the timings are changed
Convert the OMAP2+ TUSB code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c | 43
With the addition of the gpmc_cs_program_settings(), we no longer need
or use gpmc_cs_configure() to configure some of the GPMC chip-select
options. So rename the function to gpmc_configure() and remove code that
modifies options in the CONFIG1 register.
Signed-off-by: Jon Hunter
Adds a function to read the various GPMC chip-select settings from
device-tree and store them in the gpmc_settings structure.
Update the GPMC device-tree binding documentation to describe these
options.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them.
The existing code in gpmc_read_timings_dt() is checking the value of
of_property_read_u32() and only is successful storing
NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.
Add documentation for the TI GPMC NOR binding.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
When booting with device-tree, retrieve GPMC settings for ONENAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
The user must now specify the ONENAND device width in the
When booting with device-tree, retrieve GPMC settings for NAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Each GPMC chip-select can be configured to map 16MB, 32MB, 64MB or 128MB
of address space. The physical base address where a chip-select starts
is also configurable and must be aligned on a boundary that is equal to
or greater than the size of the address space mapped bt the chip-select.
When
With commit 21cc2bd (ARM: OMAP2+: Remove apollon board support) the
variable boot_rom_space is now not needed and the code surrounding
this variable can be cleaned up and simplified. Remove unnecessary
definitions and clean-up the comment as well.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
When the GPMC driver is probed, we call gpmc_mem_init() to see which
chip-selects have already been configured and enabled by the boot-loader
and allocate space for them. If we fail to allocate space for one
chip-select, then we return failure from the probe and the GPMC driver
will not be
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
gpmc_probe_nor_child() calls of_platform_device_create() to create a
platform device for the NOR child. If this function fails the value
of ret is returned to the caller but this value is zero since it was
assigned the return of a
1 - 100 of 108 matches
Mail list logo
