On Wed, Apr 15, 2015 at 11:51:32AM -0500, Nishanth Menon wrote:
I am yet to post a new revision to this series - few other stuff got
in the way. IODelay driver in no way removes the constraint that the
SoC architecture has - most of the pins still need to be muxed in
bootloader - we cannot
On Tue, Mar 17, 2015 at 06:41:51PM -0700, Tony Lindgren wrote:
Yeah agreed. I suggest discussing the binding and the generic
parsing code for it first :)
It seems with the generic binding the actual driver should be
just the hardware specific code hopefully.
Did this thread go anywhere in
If the boot loader enables HYP mode on the boot CPU, the secondary CPU
also needs to call into the ROM to switch to HYP mode before booting.
The firmwares on the omap5 and dra7xx unfortunately do not take care
of this, so it has to be handled by the kernel.
This patch is based on [PATCH 2/2] ARM:
On Wed, Dec 17, 2014 at 03:21:27PM +0200, Tero Kristo wrote:
Yea I think the 32k clock node should be fixed based on this.
Something like this:
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -100,8 +100,10 @@
sys_32k_ck: sys_32k_ck {
On Wed, Dec 17, 2014 at 09:22:25AM -0600, Nishanth Menon wrote:
A clock mux might do the job?
value 1, 2 , 3 will imply sysclk1 / 610
value of 0 implies fixed 32768
soemthing like
sys_clk32_crystal {
compatible = fixed-clock;
clock-frequency = 32768;
}
On Wed, Dec 17, 2014 at 05:45:05PM +0200, Tero Kristo wrote:
Yea clock mux can be used. However, we don't have support for DRA7
control module clocks in the DT yet. I have posted patches with
support towards this a couple of weeks back, but they need some
revising.
Thus, we maybe need to
On Tue, Dec 16, 2014 at 05:05:08PM +0530, Lokesh Vutla wrote:
Is this applicable for OMAP5 also?
If not can you drop omap5 from $subject?
DRA7xx = OMAP57xx, which to me is an omap5. Isn't it?
And I haven't been able to get a manual for the omap54xx to confirm it,
although it seems it does not
On Tue, Dec 16, 2014 at 08:58:56AM -0600, Nishanth Menon wrote:
On 17:05-20141216, Lokesh Vutla wrote:
[...]
@@ -545,6 +546,16 @@ static void __init realtime_counter_init(void)
break;
}
+ if (soc_is_dra7xx()) {
+ reg =
On Tue, Dec 16, 2014 at 08:06:34AM -0600, Nishanth Menon wrote:
On 12/12/2014 04:08 PM, Lennart Sorensen wrote:
The switch statement of the possible list of SYSCLK1 frequencies is
missing a 0 in 4 out of the 7 frequencies.
Signed-off-by: Len Sorensen lsore...@csclub.uwaterloo.ca
I see why arch_timer_freq might skip the rounding error of 39, 15 and
55 Vs existing logic which is possibly at a truncation error risk
(without errata for sysclk 13, 26 and 27MHz).
all you'd probably need to do is cast rate, num and den to unsigned
long and have a common computation logic.
On Tue, Dec 16, 2014 at 01:56:16PM -0600, Nishanth Menon wrote:
*AM*57xx is not *OMAP*57xx - there is no OMAP57xx.
Oh OK. Thanks for clearing that up.
AM57xx and DRA7xx are in the same generation of processors and is
derivative technology (not the same) as OMAP5432/OMAP5430.
We have been
While trying to deal with errata i856 on the dra7xx I encountered some
obvious typos in the frequencies checked in timer.c, so those are being
fixed in case anyone ever tries to use one of them.
Also implement a fix for errata i856. Without the fix the time on the
system will get ahead by 43
The switch statement of the possible list of SYSCLK1 frequencies is
missing a 0 in 4 out of the 7 frequencies.
Fixes: fa6d79d27614 (ARM: OMAP: Add initialisation for the real-time
counter)
Signed-off-by: Len Sorensen lsore...@csclub.uwaterloo.ca
Reviewed-by: Lokesh Vutla lokeshvu...@ti.com
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
On Fri, Dec 12, 2014 at 05:08:56PM -0500, Lennart Sorensen wrote:
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz
On Fri, Dec 12, 2014 at 11:37:41AM -0600, Nishanth Menon wrote:
-sricharan, as the email ID is defunct.
So I noticed.
On 12/11/2014 02:43 PM, Lennart Sorensen wrote:
On Thu, Dec 11, 2014 at 03:41:16PM -0500, Lennart Sorensen wrote:
Errata i856 for the AM572x (DRA7xx) points out
On Fri, Dec 12, 2014 at 01:40:01PM -0600, Nishanth Menon wrote:
we try and avoid soc_is or cpu_is as much as possible and depend usually
on compatible to mark the change..
Well you can't use the dtb really, since it depends on the chip revision
and how it started at power on. After all if you
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
The switch statement of the possible list of SYSCLK1 frequencies is
missing a 0 in 4 out of the 7 frequencies.
Signed-off-by: Len Sorensen lsore...@csclub.uwaterloo.ca
---
arch/arm/mach-omap2/timer.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
While trying to deal with errata i856 on the dra7xx I encountered some
obvious typos in the frequencies checked in timer.c, so those are being
fixed in case anyone ever tries to use one of them.
Also implement a fix for errata i856. Without the fix the time on the
system will get ahead by 43
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
On Thu, Dec 11, 2014 at 03:41:16PM -0500, Lennart Sorensen wrote:
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz
On Thu, Nov 13, 2014 at 07:34:09PM +0100, Sebastian Andrzej Siewior wrote:
misaligned dma? I haven't seen any alignment requirement for SDMA/EDMA
and I haven't seen this error on beagle board, am335x-evm or dra7-evm.
Well I am using the am5728, so it should be the same as the dra7-evm.
So
On Thu, Nov 06, 2014 at 10:18:22AM -0600, Nishanth Menon wrote:
BeagleBoard-X15 is the next generation Open Source Hardware
BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ A15
processor. The platform features 2GB DDR3L (w/dual 32bit busses),
eSATA, 3 USB3.0 ports, integrated
On Wed, Nov 05, 2014 at 09:11:35AM +0100, Sebastian Andrzej Siewior wrote:
Okay. No DMA but the basic part seems to work for you. Thanks for
testing.
Two systems ran 16 hours each so far with no issues. Pushed 170MB of
data through the pair of serial ports on one system at 230400.
--
Len
On Wed, Nov 05, 2014 at 10:33:15AM -0500, Lennart Sorensen wrote:
Two systems ran 16 hours each so far with no issues. Pushed 170MB of
data through the pair of serial ports on one system at 230400.
The console on uart3 doesn't appear to be using the dma assuming the
values in /sys for the dma
On Wed, Nov 05, 2014 at 05:30:51PM +0100, Sebastian Andrzej Siewior wrote:
On 11/05/2014 05:20 PM, Lennart Sorensen wrote:
On Wed, Nov 05, 2014 at 10:33:15AM -0500, Lennart Sorensen wrote:
Two systems ran 16 hours each so far with no issues. Pushed 170MB of
data through the pair of serial
On Mon, Sep 29, 2014 at 08:06:47PM +0200, Sebastian Andrzej Siewior wrote:
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren t...@atomide.com
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/dra7.dtsi | 12
On Tue, Nov 04, 2014 at 06:06:37PM +0100, Sebastian Andrzej Siewior wrote:
On 11/04/2014 06:02 PM, Lennart Sorensen wrote:
According to the manual the DMA channels for UART7 to 10 are:
uart7: 144 145
uart8: 146 147
uart9: 148 149
uart10: 150 151
Might as well add those too
On Tue, Nov 04, 2014 at 12:21:17PM -0500, Lennart Sorensen wrote:
Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not
sure who I am allowed to share that file with. Might be simpler to just
ask TI for the latest version.
How I hate NDAs.
Well it doesn't work, because I
On Tue, Nov 04, 2014 at 07:32:07PM +0100, Javier Martinez Canillas wrote:
Hello,
On Tue, Nov 4, 2014 at 6:21 PM, Lennart Sorensen
lsore...@csclub.uwaterloo.ca wrote:
Mind sharing the manual with me? Mine does not mention DMA channels for
UART7-10. If you are able to test 7+8 (and it works
On Tue, Nov 04, 2014 at 01:33:15PM -0500, Lennart Sorensen wrote:
Well it doesn't work, because I don't have the dma croassbar patches
from ti-linux-3.14.y which are required to use the full range of dma
channels on the dra7.
I will see how well it works without dma at least.
So it seems
On Tue, Nov 04, 2014 at 04:03:15PM -0500, Lennart Sorensen wrote:
So it seems to be working on our board so far. Will stress test it
some more. No DMA of course for now, but oh well.
Well 4 hours running with multiple reboots (our testsuite reboots every
30 minutes to test the watchdog). So
On Thu, Sep 11, 2014 at 12:02:03PM +0530, Mugunthan V N wrote:
slaves = 1;
OK, works for me.
overall disable takes care of this
Although once I enable cpsw I would need to leave the second port disabled
I suppose, although perhaps settings slaves to 1 would essentially
disable it.
Will add
On Thu, Sep 11, 2014 at 12:07:45PM +0530, Mugunthan V N wrote:
On Wednesday 10 September 2014 07:20 PM, Nishanth Menon wrote:
On 09/10/2014 08:37 AM, Mugunthan V N wrote:
Add CPSW and MDIO related device tree data for DRA7XX and made as status
disabled. Phy-id, pinmux for active and sleep
On Wed, Sep 10, 2014 at 07:07:26PM +0530, Mugunthan V N wrote:
Add CPSW and MDIO related device tree data for DRA7XX and made as status
disabled. Phy-id, pinmux for active and sleep state needs to be added in
board dts files and enable the CPSW device.
Signed-off-by: Mugunthan V N
On Fri, Aug 15, 2014 at 07:42:28PM +0200, Sebastian Andrzej Siewior wrote:
This is my complete queue fo the omap serial driver based on the 8250 core
code. I played with it on beagle bone, am335x-evm and dra7xx including DMA.
The uncertain remain the runtime-pm pieces.
I hacked a small serial
On Fri, Aug 15, 2014 at 07:42:33PM +0200, Sebastian Andrzej Siewior wrote:
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The long term goal is to provide the same functionality as the
current OMAP uart driver and DMA support.
I tried to merge omap-serial code
On Fri, Aug 15, 2014 at 09:27:59PM +0200, Sebastian Andrzej Siewior wrote:
If you want to change this to reduce the gap, then you have first
change 8250 core code. Currently it waits until the shift register is
empty.
Oh the 8250 normally works this way? I didn't know that.
On the other
On Wed, Jul 09, 2014 at 07:49:36PM +0200, Sebastian Andrzej Siewior wrote:
So after I stuffed the rs485 support from the omap-serial into
8250-omap, I've been looking at it and the only omap specific part was
the OMAP_UART_SCR_TX_EMPTY part. The driver has always TX_EMPTY set
because the 8250
40 matches
Mail list logo
