On Tuesday 30 October 2012 09:39 PM, Tomi Valkeinen wrote:
It seems that using the second EDID block causes more problems than is
of any help. The first mode in the extended block will get
FB_MODE_IS_FIRST set, which will override the first mode from the first
EDID block, thus making the default
On 2012-10-31 08:10, Archit Taneja wrote:
On Tuesday 30 October 2012 09:39 PM, Tomi Valkeinen wrote:
It seems that using the second EDID block causes more problems than is
of any help. The first mode in the extended block will get
FB_MODE_IS_FIRST set, which will override the first mode from
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
We don't currently set the dss fck when starting up. This is not a
problem, as we setup the fck later when configuring the pixel clocks. Or
this is how it was for omap2, for the rest of the omaps this may not be
so.
For DSI, HDMI and
On 10/26/2012 4:51 AM, Paul Walmsley wrote:
Split omap_prcm_restart() from mach-omap2/prcm.c into SoC-specific
variants. These functions need to be able to save the reboot reason
into the scratchpad RAM. This implies a dependency on both the PRM
and SCM IP blocks, so they've been moved
On Wed, Oct 31, 2012 at 11:19:44, Paul Walmsley wrote:
On Wed, 31 Oct 2012, Hiremath, Vaibhav wrote:
As far as lck clock node is concerned, we had deliberately dropped all leaf-
node clocks from the clock tree, please refer to the description mentioned
in -
On Wed, 31 Oct 2012, Vaibhav Hiremath wrote:
omap5xxx_restart declaration needs to be removed from here.
There is no such function implemented in code.
Thanks, prototype dropped.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
The DSI PLL and HSDivider can be used to generate the pixel clock for
LCD overlay manager, which then goes to DPI output. On the DPI output
pin the voltage of the signal is shifted from the OMAP's internal
minimal voltage to 1.8V range.
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
dss.c currently exposes functions to configure the dispc source clock
and lcd source clock. There are configured separately from the output
drivers.
However, there is no safe way for the output drivers to handle dispc
clock, as it's
On Wed, Oct 31, 2012 at 11:14:28, Balbi, Felipe wrote:
Hi,
On Wed, Oct 31, 2012 at 06:17:02AM +0100, Hebbar, Gururaja wrote:
On Mon, Oct 29, 2012 at 21:47:19, Balbi, Felipe wrote:
Hi,
On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need a
On 2012-10-31 08:54, Archit Taneja wrote:
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
dss.c currently exposes functions to configure the dispc source clock
and lcd source clock. There are configured separately from the output
drivers.
However, there is no safe way for the
Hi Greg,
On 30 October 2012 16:02, Greg Kroah-Hartman gre...@linuxfoundation.org wrote:
OK.
Greg, do these patches look OK to you to move to live under
drivers/mailbox?
Um, I don't know, I wasn't paying attention here, sorry.
As part of plat-omap code cleanup, I was planning to move
On 2012-10-31 08:45, Archit Taneja wrote:
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
The DSI PLL and HSDivider can be used to generate the pixel clock for
LCD overlay manager, which then goes to DPI output. On the DPI output
pin the voltage of the signal is shifted from the
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
We currently get the decision whether to use PRCM or DSI PLL clock for
DPI from the board file. This is not a good way to handle it, and it
won't work with device tree.
This patch changes DPI to always use DSI PLL if it's available.
On 2012-10-31 08:31, Archit Taneja wrote:
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
We don't currently set the dss fck when starting up. This is not a
problem, as we setup the fck later when configuring the pixel clocks. Or
this is how it was for omap2, for the rest of the
On Wednesday 31 October 2012 12:56 PM, Tomi Valkeinen wrote:
On 2012-10-31 08:45, Archit Taneja wrote:
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
The DSI PLL and HSDivider can be used to generate the pixel clock for
LCD overlay manager, which then goes to DPI output. On the DPI
On 10/31/2012 05:41 AM, Russ Dill wrote:
On Wed, Oct 31, 2012 at 8:55 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
The MFD parent device now uses a regmap, instead of direct
memory access. Use the same method in the sub devices to avoid
nasty surprises.
Also rework the channel
Hi Paul,
On Tue, Oct 30, 2012 at 7:23 AM, Paul Walmsley p...@pwsan.com wrote:
Hi Jean,
On Tue, 30 Oct 2012, Jean Pihet wrote:
On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 23 Oct 2012, Jean Pihet wrote:
Let me try with the same setup as yours (bootloader
On Tue, Oct 30, 2012 at 9:17 AM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 30 Oct 2012, Felipe Balbi wrote:
On Tue, Oct 30, 2012 at 12:50:52PM +, Paul Walmsley wrote:
certainly PM-idle related, given that the problem goes away by reverting
Jean's commit
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals
Paul,
- Added Rafael for the PM QoS discussion -
On Tue, Oct 30, 2012 at 10:04 AM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 30 Oct 2012, Paul Walmsley wrote:
Based on a very quick look, I'd say the original patch 3db11fe is broken.
I don't see how it can ensure that its
Hi Omar,
On 10/31/2012 08:22 AM, Omar Ramirez Luna wrote:
As part of plat-omap code cleanup, I was planning to move omap-mailbox
framework to a newly drivers/mailbox folder, right now this code is
specific to OMAP platforms, but with some clean up it could be the
base for a generic
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the truncating of the rev register
for OMAP4.
Also use the scheme bit ie bit-14 of the hi register to know if it
is OMAP_I2C_IP_VERSION_2.
On platforms
On Wednesday, October 31, 2012 04:34:21 AM Jean Pihet wrote:
Paul,
- Added Rafael for the PM QoS discussion -
On Tue, Oct 30, 2012 at 10:04 AM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 30 Oct 2012, Paul Walmsley wrote:
Based on a very quick look, I'd say the original patch 3db11fe
On Wed, Oct 31, 2012 at 2:29 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the truncating of the rev register
for OMAP4.
Also use the scheme bit ie
Hi,
On Wed, Oct 31, 2012 at 01:58:35PM +0530, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM
On 10/30/2012 10:10 AM, Felipe Balbi wrote:
Hi,
On Tue, Oct 30, 2012 at 09:16:34AM -0500, Jon Hunter wrote:
Hi Felipe,
On 10/30/2012 02:09 AM, Felipe Balbi wrote:
...
its bit of an issue to take care. How do you ensure that GPIO
does idle on SOC idle C-state attempts in such cases.
Hi Avinash,
On 10/30/2012 10:41 AM, Philip, Avinash wrote:
On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
Adds AM33XX SPI support for am335x-bone and am335x-evm.
Matt,
Can you build SPI DT patch with DMA support on top of
Hi,
On Wed, Oct 31, 2012 at 02:29:19PM +0530, Shubhrajyoti D wrote:
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the truncating of the rev register
for OMAP4.
very good, but you need to test this
Hi,
On Wed, Oct 31, 2012 at 03:02:57PM +0530, Shubhrajyoti Datta wrote:
On Wed, Oct 31, 2012 at 2:29 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the
Hi,
On Wed, Oct 31, 2012 at 05:15:02AM -0500, Jon Hunter wrote:
its bit of an issue to take care. How do you ensure that GPIO
does idle on SOC idle C-state attempts in such cases. Today that
job is done by omap_gpio_[prepare/resume]_for_idle.
that's only there because we
On 10/31/2012 11:16 AM, Benoit Cousson wrote:
Hi Avinash,
On 10/30/2012 10:41 AM, Philip, Avinash wrote:
On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
Adds AM33XX SPI support for am335x-bone and am335x-evm.
Matt,
Can you
Santosh Shilimkar santosh.shilim...@ti.com writes:
[...]
Just to summaries, there are 3 things we are talking here.
Santosh, thanks for the summary. You are right on.
1. Delaying the idle with a timeout which $subject patch is
trying to do to reduce latency for interrupts. That itself
is
A few more OMAP fixes for the 3.7-rc timeframe. Mostly hwmod fixes.
Basic test logs are available here:
http://www.pwsan.com/omap/testlogs/fixes_b_v3.7-rc/20121029222655/
However the v3.7-rc3 kernel is still missing fixes for several regressions,
which cause several tests to fail. With
From: Miguel Vadillo vadi...@ti.com
Since CAM domain (ISS) has no module wake-up dependency
with any other clock domain of the device and the dynamic
dependency from L3_main_2 is always disabled, the domain
needs to be in force wakeup in order to be able to access
it for configure (sysconfig) it
From: Tero Kristo t-kri...@ti.com
When waking up from off-mode, some IP blocks are reset automatically by
hardware. For this reason, software must wait until the reset has
completed before attempting to access the IP block.
This patch fixes for example the bug introduced by commit
Add HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
dependent on an off-chip functional clock that is not guaranteed to be
present during initialization. IP blocks marked with this flag are
left in the INITIALIZED state during kernel init.
This is a workaround for a hardware
Resolve this kernel boot message:
omap_hwmod: mcpdm: cannot be enabled for reset (3)
The McPDM on OMAP4 can only receive its functional clock from an
off-chip source. This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C. This would
introduce a
On 10/31/2012 3:34 PM, Felipe Balbi wrote:
Hi,
On Wed, Oct 31, 2012 at 01:58:35PM +0530, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for
On Wednesday 31 October 2012 03:42 PM, Felipe Balbi wrote:
Hi,
On Wed, Oct 31, 2012 at 02:29:19PM +0530, Shubhrajyoti D wrote:
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the truncating of the rev
Hi Jean,
Jean Pihet jean.pi...@newoldbits.com writes:
[...]
Based on a very quick look, I'd say the original patch 3db11fe is broken.
I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is
honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony
The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
Linux 3.7-rc3 (2012-10-28 12:24:48 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
Hi Tony
On Wed, 31 Oct 2012, Paul Walmsley wrote:
The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
Linux 3.7-rc3 (2012-10-28 12:24:48 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
On Wednesday 31 October 2012 03:42 PM, Felipe Balbi wrote:
+ if (!_dev-regs)
+ return 0;
this is wrong, you need to make sure dev-regs is set early enough.
to set the dev-regs I use the value read from revision register.
to read the revision register I do a get_sync first.
On Wed, Oct 31, 2012 at 16:05:13, Cousson, Benoit wrote:
On 10/31/2012 11:16 AM, Benoit Cousson wrote:
Hi Avinash,
On 10/30/2012 10:41 AM, Philip, Avinash wrote:
On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
Adds
On Wednesday 31 October 2012 04:07 PM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
[...]
Just to summaries, there are 3 things we are talking here.
Santosh, thanks for the summary. You are right on.
1. Delaying the idle with a timeout which $subject patch is
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Tested-by: Matt Porter mpor...@ti.com
---
Changes since v2:
- Commit message corrected.
- Rebase on top of for_3.8/dts
Hi Peter,
That's great you've have done that fix.
On 10/30/2012 12:24 PM, Peter Ujfalusi wrote:
Add flags parameter for omap_hwmod_count_resources() so users can tell which
type of resources they are interested when counting them in hwmod database.
Mmm, does it worth doing that for every
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Tested-by: Matt Porter mpor...@ti.com
---
Applied in for_3.8/dts
Thanks,
Benoit
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals
Hi,
On Wed, Oct 31, 2012 at 04:18:15PM +0530, Shubhrajyoti wrote:
On Wednesday 31 October 2012 03:42 PM, Felipe Balbi wrote:
Hi,
On Wed, Oct 31, 2012 at 02:29:19PM +0530, Shubhrajyoti D wrote:
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads
Hi,
On Wed, Oct 31, 2012 at 04:28:38PM +0530, Shubhrajyoti wrote:
On Wednesday 31 October 2012 03:42 PM, Felipe Balbi wrote:
+if (!_dev-regs)
+return 0;
this is wrong, you need to make sure dev-regs is set early enough.
to set the dev-regs I use the value
Hi Paul,
On Tue, 2012-10-16 at 07:29 +, Paul Walmsley wrote:
Hi Kevin,
Here's an updated version of this one, with the erratum coverage expanded
to include OMAP34xx/35xx.
I think this one can replace Tero's [PATCHv6 06/11] ARM: OMAP:
clockdomain: add support for preventing autodep
Hi all,
On Tue, Oct 16, 2012 at 2:15 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
We are removing plat data which was used till now to init and
exit phy. We no longer need this since dwc3-core takes care of
initializing and shutting-down the phy using usb_phy_init()
and
The tll ports clock names are renamed as channel clocks.
This is change is just adhere to TRM words
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/mfd/omap-usb-tll.c | 46 ++--
1 file changed, 23 insertions(+), 23 deletions(-)
diff
The USB2 Host driver of OMAP3/OMAP4 are device tree complaiant with
this patch series.
The device tree data of UHH, EHCI, OHCI and TLL are included.
The drivers are updated to extract and use the register set and
interrupt numbers delivered by these device tree structures.
Keshava Munegowda (11):
OMAP4 panda board specific device tree node is included.
In OMAP4 panda board, the port 1 is used in ULPI PHY mode.
The port 1 is connected to a on board hub with ethernet
interface.
TODO:
The clock bindings are not yet avilable for OMAP4.
hence , USB hub specific clocks are exported as
OMAP3 Beagle-XM board specific data for usb2 host device tree node
is included.
In Beagle XM board , the port 2 of usb host is connected to a hub
with ethernet interface.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 32
Since TLL channels clocks are dummy(virtual) nodes for OMAP3.
The device names for these clocks are set to NULL.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
The device tree node details of usb2 host and tll components
are included for OMAP4 SOC
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
.../devicetree/bindings/usb/omap-usb-host.txt | 24
.../devicetree/bindings/usb/omap-usb-tll.txt | 21
The device tree node details of usb2 host and tll components
are included for OMAP3
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi
The USB TLL device node is extracted and used in the probe
of the driver to initialize the driver data.
This TLL driver exports an API to usbhs driver to perform
the port configuration. The usb2 hs driver invoke the same
API in its driver probe to initialize the ports.
Signed-off-by: Keshava
The USB2 Host device node is extracted and used in the probe
of the driver to initialize the usb ports and controller. The
platform specific initialization is also performed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c |2 -
The usbhs core driver data is used by the ehci driver, because
the ehci driver is child of usbhs core. The unused ehci, ohci
and tll specific structures are removed.
platform device creation of usbhs and tll using hwmod is
removed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
The port1 of omap4 panda board is used in ULPI PHY mode.
The pin mux of usbhs (usbb1) port 1 is configured accordingly.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git
The port2 of omap4 panda board is used in ULPI PHY mode.
The pin mux of usbhs (usbb2) port 2 is configured accordingly.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 24
1 file changed, 24 insertions(+)
diff --git
Hi,
On Wed, Oct 31, 2012 at 05:27:36PM +0530, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM
On 30/10/12 14:48, Vaibhav Hiremath wrote:
On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote:
Mark,
MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
already submitted to the list recently. So MMC support will come along with
EDMA support. DMA-EDMA patches are
Hi,
On Wed, Oct 31, 2012 at 05:46:38PM +0530, Keshava Munegowda wrote:
The USB2 Host driver of OMAP3/OMAP4 are device tree complaiant with
this patch series.
The device tree data of UHH, EHCI, OHCI and TLL are included.
The drivers are updated to extract and use the register set and
Hi,
On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
This patch adds support to parse probe data for
dwc3-exynos driver using device tree.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
does not apply to my dwc3 branch. Care to respin ?
--
balbi
signature.asc
On Sat, Oct 27, 2012 at 07:05:54PM +0530, Kishon Vijay Abraham I wrote:
ocp2scp was not having pdata support which makes *musb* fail for non-dt
boot in OMAP platform. The pdata will have information about the devices
that is connected to ocp2scp. ocp2scp driver will now make use of this
On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote:
On 30/10/12 14:48, Vaibhav Hiremath wrote:
On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote:
Mark,
MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
already submitted to the list recently. So MMC support
Hi Balbi,
This series contains a couple of fixes for musb dsps wrapper.
First one restores capability to support at least one instance of musb.
Without it, even a single instance can't be supported as change which
is reverted by it was made along with multi phy changes and nop
transciever dt
This reverts commit d8c3ef256f88b7c6ecd673d03073b5645be9c5e4.
Above mentioned change was made along with multi usb phy change and
adding DT support for nop transceiver. But other two changes did not
make it to mainline. This in effect makes dsps musb wrapper unusable
even for single instance.
DT bindings normally use '-' (hyphens) instead of '_' (underscore),
driver has it the proper way, but binding documentation does not
reflect it, fix it.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Documentation/devicetree/bindings/usb/am33xx-usb.txt | 8
1 file changed, 4
On 31/10/12 13:57, Hiremath, Vaibhav wrote:
On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote:
If I try the latest mainline U-Boot (or the TI branch), I just get to
Starting kernel ... and then
hangs.
I am using Mainline u-boot and it works for me. Can you paste u-boot boot
log
The device tree node details of usb2 host and tll components
are included for OMAP4 SOC
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
.../devicetree/bindings/usb/omap-usb-host.txt | 24
.../devicetree/bindings/usb/omap-usb-tll.txt | 21
The tll ports clock names are renamed as channel clocks.
This is change is just adhere to TRM words
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/mfd/omap-usb-tll.c | 46 ++--
1 file changed, 23 insertions(+), 23 deletions(-)
diff
The port1 of omap4 panda board is used in ULPI PHY mode.
The pin mux of usbhs (usbb1) port 1 is configured accordingly.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git
OMAP4 panda board specific device tree node is included.
In OMAP4 panda board, the port 1 is used in ULPI PHY mode.
The port 1 is connected to a on board hub with ethernet
interface.
TODO:
The clock bindings are not yet avilable for OMAP4.
hence , USB hub specific clocks are exported as
The usbhs core driver data is used by the ehci driver, because
the ehci driver is child of usbhs core. The unused ehci, ohci
and tll specific structures are removed.
platform device creation of usbhs and tll using hwmod is
removed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
The USB2 Host device node is extracted and used in the probe
of the driver to initialize the usb ports and controller. The
platform specific initialization is also performed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c |2 -
The USB TLL device node is extracted and used in the probe
of the driver to initialize the driver data.
This TLL driver exports an API to usbhs driver to perform
the port configuration. The usb2 hs driver invoke the same
API in its driver probe to initialize the ports.
Signed-off-by: Keshava
The USB2 Host driver of OMAP3/OMAP4 are device tree complaiant with
this patch series.
The device tree data of UHH, EHCI, OHCI and TLL are included.
The drivers are updated to extract and use the register set and
interrupt numbers delivered by these device tree structures.
Keshava Munegowda (11):
Since TLL channels clocks are dummy(virtual) nodes for OMAP3.
The device names for these clocks are set to NULL.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
The device tree node details of usb2 host and tll components
are included for OMAP3
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi
The port2 of omap4 panda board is used in ULPI PHY mode.
The pin mux of usbhs (usbb2) port 2 is configured accordingly.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 24
1 file changed, 24 insertions(+)
diff --git
Hi Balbi,
On Thursday 27 September 2012 11:15 AM, Afzal Mohammed wrote:
This series is made over over Balbi's usb master branch.
It applies cleanly over musb branch too.
Please ignore this series, a new series has been posted,
usb: musb: dsps: fixes for -rc.
Regards
Afzal
--
To unsubscribe
Hi Felipe,
On Wed, Oct 31, 2012 at 7:08 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
This patch adds support to parse probe data for
dwc3-exynos driver using device tree.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
does
On 21:12 Sun 28 Oct , Linus Walleij wrote:
On Wed, Oct 24, 2012 at 7:28 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
drivers/spi/spi-pl022.c
Default/sleep transitions could be moved into bus code.
No that's not a good idea as long as we have both the platform bus
and the
Hi,
On 10/29/2012 09:21 AM, Vaibhav Hiremath wrote:
From: Mugunthan V N mugunthan...@ti.com
Add CPSW and MDIO related device tree data for AM33XX.
Also enable them into board/evm dts files by providing
respective phy-id.
Is there any bindings documentation for that device?
Signed-off-by:
It is painless to move the adapter DT devices to arch/arm/mach-omap2
However I got bit by the __init at omap_build_device family functions.
If you don't remove it, crashes every time you instantiate a device
at runtime, or you load the cape driver as a module.
Pantelis Antoniou (3):
omap_device is going private.
Move the ti-tscadc-dt adapter device to arch/arm/mach-omap2.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/ti-tscadc-dt.c | 155 +
2 files
omap_device is going private.
Move the da8xx-dt adapter device to arch/arm/mach-omap2.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/da8xx-dt.c | 197 +
2 files changed, 200
Add an IIO map interface that consumers can use.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/iio/adc/ti_am335x_adc.c | 60 +
1 file changed, 49 insertions(+), 11 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c
It's common not for both the touchscreen adc to be activated
at the same time. Deal with this case.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/mfd/ti_am335x_tscadc.c | 34 +++---
include/linux/mfd/ti_am335x_tscadc.h | 8 +++-
The MFD parent device now uses a regmap, instead of direct
memory access. Use the same method in the sub devices to avoid
nasty surprises.
Please not that this driver can't really deal with the case of the regmap
call failing in anyway. So that's why there's no error handling.
I think it's best
Capebus is created to address the problem of many SoCs that can provide a
multitude of hardware interfaces but in order to keep costs down the main
boards only support a limited number of them. The rest are typically brought
out to pin connectors on to which other boards, named capes are connected
Introduce beaglebone capebus board support.
This patch creates the beaglebone's board cape bus controller.
The board controller is responsible for the probing of capes
at the well defined I2C address for capes, parsing the EEPROM
info and matching them to specific cape drivers.
On top of that,
Describe capebus DT bindings in detail.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
.../capebus/bone-capebus-slot-override.txt | 28 +++
.../devicetree/bindings/capebus/bone-capebus.txt | 50 +++
.../bindings/capebus/bone-geiger-cape.txt | 78
Small summary of capebus.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
Documentation/capebus/capebus-summary | 40 +++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/capebus/capebus-summary
diff --git
1 - 100 of 156 matches
Mail list logo
