On Tue, Jan 13, 2015 at 02:23:25PM -0800, Tony Lindgren wrote:
On dm81xx we have 128 interrupts like am33xx has. Let's add
compatible flags for dm814x and dm816x, and document the
existing binding.
As the dm81xx are booting in device tree only mode, we can now
also remove ti81xx_init_irq()
On Tue, Jan 13, 2015 at 02:23:26PM -0800, Tony Lindgren wrote:
Nowadays omap2 is booting in device tree only mode so there is no
need to keep the legacy interface around for omap2_init_irq().
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Awesome, only one to go
From: Felipe Balbi ba...@ti.com
Date: Tue, 13 Jan 2015 13:44:46 -0600
+ ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ 0, dev_name(pdev-dev), priv);
When a function call spans multiple lines, the argument on the second
and subsequent lines must start on the
Add node for NXP TDA19988 encoder and refer to it in the hdmi node
instead of referring to the i2c bus where the encoder is connected to.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am335x-boneblack.dts |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff
Add drm_i2c_encoder_attach() for attaching an already probed i2c
encoder. This is needed for instance if the encoder is probed from
device tree.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/gpu/drm/drm_encoder_slave.c | 51 +++
These patches are needed for Beaglebone-back HDMI audio. There is no
direct dependency between these patches and the other (dts and ASoC)
changes needed for the HDMI audio so these changes can be merged
independently. I also feel that these changes make sense even without
the HDMI audio.
Best
It is more convenient to refer to the i2c slave encoder directly with
phandle than to refer to the i2c bus and to create the device manually.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../devicetree/bindings/drm/tilcdc/slave.txt |4 +-
drivers/gpu/drm/tilcdc/tilcdc_slave.c
On 13/01/15 06:09, Linus Walleij wrote:
Hi Linus,
On Mon, Jan 12, 2015 at 7:26 PM, Marc Zyngier marc.zyng...@arm.com wrote:
IMX6 has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This
On 12/01/15 19:00, Stefan Agner wrote:
Hi Marc,
On 2015-01-12 19:26, Marc Zyngier wrote:
IMX6 has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This patch does just this, updating the DT
This board is working with device tree based booting so there should
not be any need to keep the legacy booting support around. People
using this board can boot it with appended DTB with existing bootloader.
By removing the 3517 legacy booting support we can get a bit closer to
making all of
This board is working with device tree based booting so there should
not be any need to keep the legacy booting support around. People
using this board can boot it with appended DTB with existing bootloader.
By removing the 3517 legacy booting support we can get a bit closer to
making all of
This board is working with device tree based booting so there should
not be any need to keep the legacy booting support around. People
using this board can boot it with appended DTB with existing bootloader.
By removing the 3517 legacy booting support we can get a bit closer to
making all of
This is no longer needed now that 3517 is booting in device tree
only mode.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile | 3 -
arch/arm/mach-omap2/am35xx-emac.c | 114 -
arch/arm/mach-omap2/am35xx-emac.h
Hi all,
It seems we can now drop omap3517 legacy booting support to get
a bit closer to making all of omap3 boot in device tree only mode.
All these boards have at least minimal support for booting with
device tree, and pretty much anything supported with the legacy
board files can be configured
On Tue, 13 Jan 2015 19:12:25 +0200
Jyri Sarha jsa...@ti.com wrote:
These patches are needed for Beaglebone-back HDMI audio. There is no
direct dependency between these patches and the other (dts and ASoC)
changes needed for the HDMI audio so these changes can be merged
independently. I also
Commit 3ba97381343b (net: ethernet: davinci_emac: add pm_runtime support)
added support for runtime PM, but it causes issues on omap3 related devices
that actually gate the clocks:
Unhandled fault: external abort on non-linefetch (0x1008)
...
[c04160f0] (emac_dev_getnetstats) from [c04d6a3c]
We only use clk_get() to get the frequency, the rest is done by
the runtime PM calls. Let's free the clock too.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/net/ethernet/ti/davinci_emac.c | 1 +
1 file changed,
On davinci_emac, we have pulse interrupts. This means that we need to
clear the EOI bits when disabling interrupts as otherwise the interrupts
keep happening. And we also need to not clear the EOI bits again when
enabling the interrupts as otherwise we will get tons of:
unexpected IRQ trap at
Some devices like dm816x have the MDIO registers within the first EMAC
instance address space. Let's fix the issue by allowing to pass an
optional second IO range for the EMAC control register area.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony
On dm816x we have two emac controllers with separate memory
areas.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
Documentation/devicetree/bindings/net/davinci_emac.txt | 3 ++-
drivers/net/ethernet/ti/davinci_emac.c
Looks like the phy_id is never set up beyond getting the phandle.
Note that we can remove the ifdef for phy_node as there is a stub
for of_phy_connec() if CONFIG_OF is not set.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
This patch is in preparation for a nicer IRQ
handling scheme where we use different IRQ
handlers for each IRQ line (as it should be).
Later, we will also drop IRQs offset 0 and 3
because they are always disabled in this driver.
Signed-off-by: Felipe Balbi ba...@ti.com
---
* Felipe Balbi ba...@ti.com [150113 11:57]:
On Tue, Jan 13, 2015 at 11:29:27AM -0800, Tony Lindgren wrote:
Some devices like dm816x have the MDIO registers within the first EMAC
instance address space. Let's fix the issue by allowing to pass an
optional second IO range for the EMAC control
Hi,
Here are some fixes for davinci_emac for the issues I've noticed
recently.
Regards,
Tony
Tony Lindgren (6):
net: davinci_emac: Fix hangs with interrupts
net: davinci_emac: Fix runtime pm calls for davinci_emac
net: davinci_emac: Free clock after checking the frequency
net:
* Felipe Balbi ba...@ti.com [150113 11:40]:
On Tue, Jan 13, 2015 at 11:29:23AM -0800, Tony Lindgren wrote:
Note that eventually we should handle the RX and TX interrupts
separately like cpsw is now doing. However, so far I have not seen
any issues with this based on my testing, so it
On Tue, Jan 13, 2015 at 11:29:27AM -0800, Tony Lindgren wrote:
Some devices like dm816x have the MDIO registers within the first EMAC
instance address space. Let's fix the issue by allowing to pass an
optional second IO range for the EMAC control register area.
Cc: Brian Hutchinson
Call clk_prepare_enable() and clk_disable_unprepare() for cpu dai
clock and codec dai clock in dai statup and shutdown callbacks. This
to make sure the related clock are enabled when the audio device is
used.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
This patch is needed for Beaglebone-back
* Tom Lendacky thomas.lenda...@amd.com [150113 11:51]:
On 01/13/2015 01:29 PM, Tony Lindgren wrote:
We only use clk_get() to get the frequency, the rest is done by
the runtime PM calls. Let's free the clock too.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Now we can introduce dedicated IRQ handlers
for each of the IRQ events. This helps with
cleaning up a little bit of the clutter in
cpsw_interrupt() while also making sure that
TX IRQs will try to handle TX buffers while
RX IRQs will try to handle RX buffers.
Signed-off-by: Felipe Balbi
CPSW never uses RX_THRESHOLD or MISC interrupts. In
fact, they are always kept masked in their appropriate
IRQ Enable register.
Instead of allocating an IRQ that never fires, it's best
to remove that code altogether and let future patches
implement it if anybody needs those.
Signed-off-by:
On Tue, Jan 13, 2015 at 01:48:24PM -0600, Tom Lendacky wrote:
On 01/13/2015 01:29 PM, Tony Lindgren wrote:
We only use clk_get() to get the frequency, the rest is done by
the runtime PM calls. Let's free the clock too.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
On Tue, Jan 13, 2015 at 03:13:51PM -0800, Tony Lindgren wrote:
The support for 81xx was never working in mainline, and it
will be only supported in device tree mode. Let's remove all
the remaining 81xx related platform code.
you should probably also mention here that you're dropping
On Tue, Jan 13, 2015 at 03:13:52PM -0800, Tony Lindgren wrote:
We need to check if we got the clock before trying to do anything
with it. Otherwise we will get something like this:
Unable to handle kernel paging request at virtual address fffe
...
[c04bef78] (clk_prepare) from
On Tue, Jan 13, 2015 at 03:13:56PM -0800, Tony Lindgren wrote:
We are missing proper hooks for 81xx for reboot to work.
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/common.h
Hi Paul,
On 01/13/2015 05:29 PM, Paul Walmsley wrote:
Hi Suman,
thanks for pitching in on this!
On Tue, 6 Jan 2015, Suman Anna wrote:
You have removed the return from the above block on failure. If any DT
entry doesn't have the reg property, this will hang the kernel boot.
Just remove
This patch fixes: 'omap_hwmod: gpmc: _wait_target_disable failed'
error during suspend.
This is because smart idle is broken.
Tested in dra7-evm D1 board.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c |3 ++-
1 file changed, 2 insertions(+), 1
On 12 January 2015 at 20:23, NeilBrown ne...@suse.de wrote:
This is another resend with mmc_gpio_set_cd_isr() now returning
void and being EXPORTed.
I included
WARN_ON(ctx-cd_gpio_isr);
to guard against misuse.
My goal is to get omap_hsmmc to use the common code for parsing of,
When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
only when it is the last TRB being prepared from the last dwc3_request entry.
The current implementation uses list_is_last to check if the
DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This
means, the max TRBs that can be submitted for an EP is fixed to 32. Since the
request queue for an EP is a linked list, any number of requests can be queued
to it by the gadget layer. However, the dwc3 driver must not
This is a re-submission of patches [1/4] and [2/4] from:
http://www.spinics.net/lists/linux-usb/msg118841.html
Commit log of both these patches has been modified for aided clarity. These
patches have been rebased on Balbi's testing/next.
Patches [3/4] and [4/4] were accepted as they
On 1/13/2015 12:10 PM, Amit VIRDI wrote:
This is a re-submission of patches [1/4] and [2/4] from:
http://www.spinics.net/lists/linux-usb/msg118841.html
Commit log of both these patches has been modified for aided clarity. These
patches have been rebased on Balbi's testing/next.
Patches
use of regmap_read() and regmap_write() in c_can_hw_raminit_syscon()
is not safe as the RAMINIT register can be shared between different drivers
at least for TI SoCs.
To make the modification atomic we switch to using regmap_update_bits().
regmap_update_bits() skips writing to the register if
On 03/12/14 23:33, Marek Belisko wrote:
Add handling for gta04 tv out chain:
venc - opa362 - svideo
Use invert-polarity in venc node because opa362
is doing polarity inversion also.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dtsi | 49
On 21/12/14 19:02, Rickard Strandqvist wrote:
Removes some functions that are not used anywhere:
rfbi_init_display() rfbi_display_disable() rfbi_display_enable()
rfbi_set_interface_timings() rfbi_set_data_lines() rfbi_set_pixel_size()
rfbi_set_size() rfbi_update() rfbi_configure()
On 01/01/15 17:29, Rickard Strandqvist wrote:
Removes some functions that are not used anywhere:
dispc_wb_go() dispc_wb_go_busy() dispc_wb_get_framedone_irq()
dispc_mgr_get_clock_div() dispc_wb_is_enabled() dispc_wb_enable()
dispc_wb_setup() dispc_enable_fifomerge() dispc_wb_set_channel_in()
On Wed, Dec 03, 2014 at 06:33:57PM +0400, Alexander Kochetkov wrote:
This pacth series intended for fixing problem reported
by Tony Lindgren t...@atomide.com here[1]
One of first four patched could fix the problem.
Last patch provide event trace so I could resolve problem.
It could be
On Sun, Nov 30, 2014 at 01:00:01AM +0400, Alexander Kochetkov wrote:
The first patch fix i2c-omap driver for omap2420, found by code review and
later reported by Tony Lindgren t...@atomide.com here[1].
Candidate for stable?
The second patch unhide the reson of system lockup.
The patch is
On 05/01/15 15:09, Rasmus Villemoes wrote:
Assigning ddata-invert_polarity to itself is not very useful; the
context suggests that the right-hand side should have been
pdata-invert_polarity.
Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk
---
Hi,
During system suspend L3INIT_960M_GFCLK and L3INIT_480M_GFCLK clocks remain
active on the DRA7 platform. This is because the pipe3 driver doesn't shut
them off as part of .suspend(). Patch 1 addresses this issue.
SATA on both OMAP5 and DRA7 breaks when SATA drive is plugged in after a
system
On system suspend, the runtime_suspend() driver hook doesn't get
called for USB phy and so the clocks are not disabled in the driver.
This causes the L3INIT_960M_GFCLK and L3INIT_480M_GFCLK to remain
active on the DRA7 platform while in system suspend.
In case of pcie-phy, the runtime_suspend
The sata_ref_clk is a reference clock to the SATA phy.
This fixes SATA malfunction across suspend/resume or when
SATA driver is used as a module.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
The sata_ref_clk is a reference clock to the SATA phy.
This fixes SATA malfunction across suspend/resume or when
SATA driver is used as a module.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Failed test case: Boot without SATA drive connected. Suspend/resume
the board and then connect SATA drive. It fails to enumerate.
Due to Errata i783 SATA Lockup After SATA DPLL Unlock/Relock
we can't allow SATA DPLL to be in the unlocked state.
The SATA refclk (sata_ref_clk) is the source of the
* Roger Quadros rog...@ti.com [150113 04:26]:
Hi,
During system suspend L3INIT_960M_GFCLK and L3INIT_480M_GFCLK clocks remain
active on the DRA7 platform. This is because the pipe3 driver doesn't shut
them off as part of .suspend(). Patch 1 addresses this issue.
SATA on both OMAP5 and
* Roger Quadros rog...@ti.com [150113 04:26]:
The sata_ref_clk is a reference clock to the SATA phy.
This fixes SATA malfunction across suspend/resume or when
SATA driver is used as a module.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
* Roger Quadros rog...@ti.com [150113 04:26]:
The sata_ref_clk is a reference clock to the SATA phy.
This fixes SATA malfunction across suspend/resume or when
SATA driver is used as a module.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
* Roger Quadros rog...@ti.com [150108 02:33]:
On 08/01/15 02:16, Tony Lindgren wrote:
* Dmitry Lifshitz lifsh...@compulab.co.il [141229 23:42]:
On 12/29/2014 03:06 PM, Roger Quadros wrote:
On 28/12/14 16:30, Dmitry Lifshitz wrote:
--- a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
+++
* Tomi Valkeinen tomi.valkei...@ti.com [150113 02:14]:
On 03/12/14 23:33, Marek Belisko wrote:
Add handling for gta04 tv out chain:
venc - opa362 - svideo
Use invert-polarity in venc node because opa362
is doing polarity inversion also.
Signed-off-by: Marek Belisko
Hi,
On Tue, Jan 13, 2015 at 10:18:20AM +0530, Amit Virdi wrote:
On 1/13/2015 12:04 AM, Felipe Balbi wrote:
Hi,
On Tue, Jan 06, 2015 at 11:44:23AM +0530, Amit Virdi wrote:
I can certainly provide the dwc3 specific kernel bootup logs, full
regdump and any loglevel you want me to, if that
prior to this check we are checking for word_length_16b and if word_length_16b
is false then we are returning with -EINVAL.
So at this point word_length_16b can only be true.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/video/fbdev/omap2/dss/hdmi5_core.c | 5 +
1 file
On Tue, Jan 13, 2015 at 11:29:23AM -0800, Tony Lindgren wrote:
On davinci_emac, we have pulse interrupts. This means that we need to
clear the EOI bits when disabling interrupts as otherwise the interrupts
keep happening. And we also need to not clear the EOI bits again when
enabling the
On 01/13/2015 01:29 PM, Tony Lindgren wrote:
We only use clk_get() to get the frequency, the rest is done by
the runtime PM calls. Let's free the clock too.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
On Tue, Jan 13, 2015 at 11:29:24AM -0800, Tony Lindgren wrote:
Commit 3ba97381343b (net: ethernet: davinci_emac: add pm_runtime support)
added support for runtime PM, but it causes issues on omap3 related devices
that actually gate the clocks:
Unhandled fault: external abort on non-linefetch
Hi,
Here's a patch to get the ti81xx interrupt support working properly,
and to remove some unused legacy code.
Regards,
Tony
clone of xxx-81xx-mainline
Tony Lindgren (2):
irqchip: omap-intc: Fix support for dm814 and dm816
irqchip: omap-intc: Remove unused legacy interface for omap2
On dm81xx we have 128 interrupts like am33xx has. Let's add
compatible flags for dm814x and dm816x, and document the
existing binding.
As the dm81xx are booting in device tree only mode, we can now
also remove ti81xx_init_irq() legacy function.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc:
Nowadays omap2 is booting in device tree only mode so there is no
need to keep the legacy interface around for omap2_init_irq().
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/irqchip/irq-omap-intc.c | 8
On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna s-a...@ti.com wrote:
Drivers can use of_platform_populate() to create platform devices
for children of the device main node, and a complementary API
of_platform_depopulate() is provided to delete these child devices.
Any platform_data supplied for
Hi Rob,
On 01/13/2015 04:27 PM, Rob Herring wrote:
On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna s-a...@ti.com wrote:
Drivers can use of_platform_populate() to create platform devices
for children of the device main node, and a complementary API
of_platform_depopulate() is provided to delete
On dm816x the clocks are sourced from a FAPLL (Flying Adder PLL)
that does not seem to be used on the other omap variants.
There are four instances of the FAPLL on dm816x that each have three
to seven child synthesizers.
I've set up the FAPLL as a single fapll.c driver. Later on we could
The clocks on ti81xx are not compatible with omap3. On dm816x
the clock source is a FAPLL (Flying Adder PLL), and on dm814x
there seems to be an APLL (All Digital PLL).
Let's fix up things for dm816x in preparation for adding the
FAPLL support. As we already have a dummy ti81xx_dt_clk_init()
in
Hi all,
Here's a minimal support for the FAPLL (Flying Adder PLL) on dm816x
which is a omap variant.
Regards,
Tony
Tony Lindgren (2):
clk: ti: Add support for FAPLL on dm816x
clk: ti: Initialize clocks for dm816x
.../devicetree/bindings/clock/ti/fapll.txt | 33 ++
On 01/13/2015 04:00 PM, Rob Herring wrote:
On Tue, Jan 13, 2015 at 3:25 PM, Suman Anna s-a...@ti.com wrote:
Hi Rob,
On 01/13/2015 02:38 PM, Rob Herring wrote:
On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna s-a...@ti.com wrote:
Drivers can use of_platform_populate() to create platform devices
* Felipe Balbi ba...@ti.com [150113 11:54]:
On Tue, Jan 13, 2015 at 01:48:24PM -0600, Tom Lendacky wrote:
On 01/13/2015 01:29 PM, Tony Lindgren wrote:
We only use clk_get() to get the frequency, the rest is done by
the runtime PM calls. Let's free the clock too.
Cc: Brian Hutchinson
On Tue, Jan 13, 2015 at 11:59:58AM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [150113 11:57]:
On Tue, Jan 13, 2015 at 11:29:27AM -0800, Tony Lindgren wrote:
Some devices like dm816x have the MDIO registers within the first EMAC
instance address space. Let's fix the issue by
* Arnd Bergmann a...@arndb.de [150113 12:27]:
On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:
It seems we can now drop omap3517 legacy booting support to get
a bit closer to making all of omap3 boot in device tree only mode.
All these boards have at least minimal support for
Hi Rob,
On 01/13/2015 02:38 PM, Rob Herring wrote:
On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna s-a...@ti.com wrote:
Drivers can use of_platform_populate() to create platform devices
for children of the device main node, and a complementary API
of_platform_depopulate() is provided to delete
On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:
It seems we can now drop omap3517 legacy booting support to get
a bit closer to making all of omap3 boot in device tree only mode.
All these boards have at least minimal support for booting with
device tree, and pretty much anything
* Felipe Balbi ba...@ti.com [150113 11:55]:
On Tue, Jan 13, 2015 at 11:29:24AM -0800, Tony Lindgren wrote:
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1538,7 +1538,7 @@ static int emac_dev_open(struct net_device *ndev)
int i = 0;
From: Tony Lindgren t...@atomide.com
Date: Tue, 13 Jan 2015 11:54:16 -0800
* Tom Lendacky thomas.lenda...@amd.com [150113 11:51]:
On 01/13/2015 01:29 PM, Tony Lindgren wrote:
We only use clk_get() to get the frequency, the rest is done by
the runtime PM calls. Let's free the clock too.
Cc:
On Tue, Jan 13, 2015 at 12:54:40PM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [150113 11:55]:
On Tue, Jan 13, 2015 at 11:29:24AM -0800, Tony Lindgren wrote:
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1538,7 +1538,7 @@
On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna s-a...@ti.com wrote:
Drivers can use of_platform_populate() to create platform devices
for children of the device main node, and a complementary API
of_platform_depopulate() is provided to delete these child platform
devices. The
On Tuesday 13 January 2015 21:42:20 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [150113 12:27]:
On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:
It seems we can now drop omap3517 legacy booting support
to get a bit closer to making all of omap3 boot in device
tree only
On Tue, Jan 13, 2015 at 3:25 PM, Suman Anna s-a...@ti.com wrote:
Hi Rob,
On 01/13/2015 02:38 PM, Rob Herring wrote:
On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna s-a...@ti.com wrote:
Drivers can use of_platform_populate() to create platform devices
for children of the device main node, and a
We are missing proper hooks for 81xx for reboot to work.
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/common.h | 8
arch/arm/mach-omap2/ti81xx-restart.c | 31
We cannot use the omap3 pm support on 81xx.
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/io.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b957776..e4a5630 100644
The support for 81xx was never working in mainline, and it
will be only supported in device tree mode. Let's remove all
the remaining 81xx related platform code.
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/cclock3xxx_data.c |
We need to check if we got the clock before trying to do anything
with it. Otherwise we will get something like this:
Unable to handle kernel paging request at virtual address fffe
...
[c04bef78] (clk_prepare) from [c00338a4]
(omap2_clk_enable_init_clocks+0x50/0x8)
[c00338a4]
Hi all,
The ti81xx support has been in a sorry half-merged state for
past few years in the mainline kernel. Let's get it working
by first fixing the issues.
Note that another series of patches is needed to add the 81xx
related data files.
Regards,
Tony
Tony Lindgren (7):
ARM: OMAP2+: Remove
Otherwise we get error Cannot detect omap type! and many
things can fail with following:
Unhandled fault: imprecise external abort (0xc06) at 0xc6031fb0
This is because the omap_type is being used to set up th SoC
specific functions for omaps.
Cc: Brian Hutchinson b.hutch...@gmail.com
Otherwise it will return true for cpu_is_omap34xx() which we don't
want for the clocks and hwmod. It's closer to am33xx for the clocks
and hwmod than to the omap34xx. We also want to be able to detect
814x and 816x separately as at least the clocks are different with
814x using a apll and 816x
Fix dm814 and dm816 clocks and timer init.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/prm_common.c | 4
arch/arm/mach-omap2/timer.c | 2 ++
2 files
Add minimal hwmod support that works at least on dm8168. This
is based on the code in the earlier TI CDP tree, and an earlier
patch by Aida Mynzhasova aida.mynzhas...@skitlab.ru.
I've set up things to work pretty much the same way as for
am33xx. We are basically using cm33xx.c with a different
From: Aida Mynzhasova aida.mynzhas...@skitlab.ru
This patch adds required definitions and structures for clockdomain
initialization, so omap3xxx_clockdomains_init() was substituted by
new ti81xx_clockdomains_init() while early initialization of
TI81XX platform.
This code is based on the
Hi,
These patches add the basic data needed for booting dm816x
after the fixes I posted earlier today. Note that also the
device tree related changes are needed that will be posted
in another series.
Regards,
Tony
Aida Mynzhasova (1):
ARM: OMAP2+: Add clock domain support for dm816x
Tony
Hi Suman,
thanks for pitching in on this!
On Tue, 6 Jan 2015, Suman Anna wrote:
You have removed the return from the above block on failure. If any DT
entry doesn't have the reg property, this will hang the kernel boot.
Just remove the reg entry from any of the existing DT, and you will
run
Hi,
Here are the device tree related changes to boot dm816x
boards as tested on a dm8168-evm.
Note that these depend on the other related patches I've
posted today. To make it easier to figure out what all is
needed, i've also posted a temporary test branch with all
the necessary patches
Similar to other omap variants, let's add dm816x support.
Note that this is based on generated data from the
TI81XX-LINUX-PSP-04.04.00.02 patches published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
I've verified the basic functionality,
The clocks on dm816x are a bit different from the other omap
variants. The clocks are sourced from a FAPLL (Flying Adder PLL)
unlike on other omaps. Other than that, it's a similar setup
to am33xx with extra muxes and dividers that can be defined
as existing component clocks.
Cc: Brian Hutchinson
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
This allows booting ti81xx boards with with when a .dts
file is in place.
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c | 34 ++
1 file changed, 34 insertions(+)
diff --git
1 - 100 of 103 matches
Mail list logo
