On 09/09/2014 06:06 PM, Marc Kleine-Budde wrote:
On 09/09/2014 05:04 PM, Marc Kleine-Budde wrote:
On 09/09/2014 04:55 PM, Roger Quadros wrote:
The SoC supports 2 DCAN nodes. Add them.
I think you should put the device-tree ml for DT related patches on Cc.
OK.
Signed-off-by: Roger Quadros
On 09/09/2014 06:09 PM, Marc Kleine-Budde wrote:
On 09/09/2014 04:55 PM, Roger Quadros wrote:
From: Afzal Mohammed af...@ti.com
Add dcan nodes.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
On 09/09/2014 06:08 PM, Marc Kleine-Budde wrote:
On 09/09/2014 04:55 PM, Roger Quadros wrote:
The d_can driver expects appropriately named aliases for
the d_can nodes for the RAMINIT control register access.
Provide those, otherwise RAMINIT register won't be configured.
Get's rid of the
of_device_ids (i.e. compatible strings and the respective data) are not
supposed to change at runtime. All functions working with of_device_ids
provided by linux/of.h work with const of_device_ids. So mark the
non-const function parameters and structs for OMAP2+ as const, too.
Signed-off-by: Uwe
Commit d4d8819e205854c (bus: omap_l3_noc: fix masterid detection)
did the right thing in dropping the LSB 2 bits which is not part
of the ConnID for NTTP master address. However, as part of that
change, we should also have ensured that existing list of OMAP4 connID
codes are also shifted by 2 bits
Hi,
On 09/08/2014 04:24 PM, Felipe Balbi wrote:
Hi,
On Mon, Sep 08, 2014 at 02:34:33PM +0300, Dmitry Lifshitz wrote:
Hi Felipe, Roger
On 04/16/2014 07:16 PM, Felipe Balbi wrote:
On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
Hi,
On 10/10/2013 01:49 PM, Kishon Vijay Abraham
Adding device tree entry for CPSW to make it work in Dual EMAC mode.
These patches were tested with DRA7 hwmod patches on top of linux-next.
Patches are tested on top of Nishanth's PM tree for v3.17 [1] and pushed
my tree to [2].
Did a boot test with CPSW and ping test with suspend/resume, the
Adding CPSW phy-id, CPSW and MDIO pinmux configuration for active and
sleep states and enable them in board evm dts file.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 107 +
1 file changed, 107 insertions(+)
diff
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 mugunthan...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 59
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 state needs to be added in
board dts files and enable the CPSW device.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
On 09/10/2014 08:37 AM, Mugunthan V N wrote:
Adding CPSW phy-id, CPSW and MDIO pinmux configuration for active and
sleep states and enable them in board evm dts file.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 107
On 09/10/2014 08:37 AM, Mugunthan V N wrote:
Adding device tree entry for CPSW to make it work in Dual EMAC mode.
These patches were tested with DRA7 hwmod patches on top of linux-next.
Patches are tested on top of Nishanth's PM tree for v3.17 [1] and pushed
my tree to [2].
Did a boot test
On Tue, Sep 09, 2014 at 09:41:20PM +0200, Sebastian Andrzej Siewior wrote:
On 09/08/2014 08:33 PM, Frans Klaver wrote:
Thanks. I'll give it a spin on Wednesday.
Could you please pull the upcoming v9 first?
git://git.breakpoint.cc/bigeasy/linux.git uart_v9_pre1
This solves a few of my
I'm having an hard time making the vanilla v7_defconfig boot off the mmc on my
pandaboard:
[1.698272] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator -517
[1.705139] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral
[1.712890] omap_hsmmc 480d5000.mmc: unable to
From: Rajendra Nayak rna...@ti.com
In order to handle errata I688, a page of sram was reserved by doing a
static iotable map. Now that we use gen_pool to manage sram, we can
completely remove all of these static mappings and use gen_pool_alloc()
to get the one page of sram space needed to
From: Rajendra Nayak rna...@ti.com
Use drivers/misc/sram.c driver to manage SRAM on all DT only
OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of
the existing private plat-omap/sram.c
Address and size related data is removed from mach-omap2/sram.c
and now passed to drivers/misc/sram.c
From: Rajendra Nayak rna...@ti.com
Remove the empty am33xx_sram_init() function.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/mach-omap2/sram.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/mach-omap2/sram.c
v3:
Fix minor issue in last patch to check for null sram_pool if no sram
phandle is given in DT.
Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5)
use drivers/misc/sram.c driver instead of the omap internal
implementation for SRAM handling.
Previous discussion can be found at
* Mauro Carvalho Chehab mche...@infradead.org [140909 17:52]:
Em Tue, 09 Sep 2014 12:36:54 -0300
Mauro Carvalho Chehab m.che...@samsung.com escreveu:
Em Tue, 9 Sep 2014 15:41:58 +0100
Russell King - ARM Linux li...@arm.linux.org.uk escreveu:
On Tue, Sep 09, 2014 at 11:38:17AM -0300,
On 17:33-20140910, Paolo Pisati wrote:
I'm having an hard time making the vanilla v7_defconfig boot off the mmc on my
pandaboard:
V3.15:
https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-vanilla.txt
https://github.com/nmenon/kernel-test-logs/blob/v3.15
On 09/10/2014 04:15 PM, Frans Klaver wrote:
On Tue, Sep 09, 2014 at 09:41:20PM +0200, Sebastian Andrzej Siewior wrote:
On 09/08/2014 08:33 PM, Frans Klaver wrote:
Thanks. I'll give it a spin on Wednesday.
Could you please pull the upcoming v9 first?
On 11:04-20140910, Dave Gerlach wrote:
v3:
Fix minor issue in last patch to check for null sram_pool if no sram
phandle is given in DT.
Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5)
use drivers/misc/sram.c driver instead of the omap internal
implementation for SRAM
Logic has been added to the OMAP2+ mailbox code to parse the
mailbox dt nodes and construct the different sub-mailboxes
associated with the instance. The DT representation of the
sub-mailbox devices is different from legacy platform data
representation to allow flexibility of interrupt
Add the device tree bindings document for OMAP2+ mailbox.
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@ti.com
---
Hi Tony,
This is a repost of just the DT support patches (first 2 patches out
of 5) from the OMAP Mailbox framework adoption and DT support series [1],
so that they can be picked up for 3.18. The only change is an Acked-by
picked up on the second patch. I will repost the third patch separately,
The sub-mailbox devices are added to the Mailbox DT nodes on
OMAP2420, OMAP2430, OMAP3, AM33xx, AM43xx, OMAP4 and OMAP5
family of SoCs. This data represents the same mailboxes that
used to be represented in hwmod attribute data previously.
The node name is chosen based on the .name field of
Hi Tony,
This is a repost of just the DTS patch (third patch) from the OMAP
Mailbox framework adoption and DT support series [1], for it to be
picked up in your dts branch for 3.18. There are no changes, just
rebased onto 3.17-rc3. This is the DTS counterpart for the mailbox
DT support series for
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 together with the 8250-core code.
There should should be hardly a noticable
the diff of v8…v9 is small:
- rebased on top's of Greg's tty-next branch
- fixed #10 where we might have THRE interrupt enabled for longer than
needed
- re-did register setup in #10. Before this less file could freeze the
am335x-evm.
Sebastian
--
To unsubscribe from this list: send the line
At least on AM335x the following problem exists: Even if the TX FIFO is
empty and a TX transfer is programmed (and started) the UART does not
trigger the DMA transfer.
After $TRESHOLD number of bytes have been written to the FIFO manually the
UART reevaluates the whole situation and decides that
Right now it is possible that serial8250_tx_dma() fails and returns
-EBUSY. The caller (serial8250_start_tx()) will then enable
UART_IER_THRI which will generate an interrupt once the TX FIFO is
empty.
In serial8250_handle_irq() nothing will happen because up-dma is set
and so
serial8250_do_startup() adds UART_IER_RDI and UART_IER_RLSI to ier.
serial8250_stop_rx() should remove both.
This is what the serial-omap driver has been doing and is now moved to
the 8250-core since it does no look to be *that* omap specific.
Cc: heikki.kroge...@linux.intel.com
Reviewed-by: Tony
The omap needs a DMA request pending right away. If it is enqueued once
the bytes are in the FIFO then nothing will happen and the FIFO will be
later purged via RX-timeout interrupt.
This patch enqueues RX-DMA request on completion but not if it was
aborted on error. The first enqueue will happen
While comparing the OMAP-serial and the 8250 part of this I noticed that
the latter does not use run time-pm. Here are the pieces. It is
basically a get before first register access and a last_busy + put after
last access. This has to be enabled from userland _and_ UART_CAP_RPM is
required for
The OMAP UART provides support for HW assisted flow control. What is
missing is the support to throttle / unthrottle callbacks which are used
by the omap-serial driver at the moment.
This patch adds the callbacks. It should be safe to add them since they
are only invoked from the serial_core
Tony noticed that the old omap-serial driver picked the uart number
based on the hint given from device tree or platform device's id.
The 8250 based omap driver doesn't do this because the core code does
not honour the -line argument which is passed by the driver.
This patch aims to keep the same
The serial8250_do_startup() function unconditionally clears the
interrupts and for that it reads from the RX-FIFO without checking if
there is a byte in the FIFO or not. This works fine on OMAP4+ HW like
AM335x or DRA7.
OMAP3630 ES1.1 (which means probably all OMAP3 and earlier) does not like
With 8250-dma, 8250-omap and am335x I observe the following:
- start a RX transfer which will finish once the FIFO has enough data
- The TX side starts a large TX transfer, say 1244 bytes. It takes approx
102ms for the transfer to complete
- cancel the RX transfer start the RX transfer a few
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the
Due to UART_BUG_DMA_TX the am335x has to put the first one byte into the
TX FIFO to get things going. If we get to serial8250_tx_dma() via
__dma_tx_complete() then the DMA engine just finished and the FIFO is
full and we can't put the first byte into the TX FIFO as kick start so
we leave with THRI
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
1 file changed, 12 insertions(+)
diff --git
There is nothing to do for RPM in the RX path. If the HW goes off then it
won't assert the DMA line and the transfer won't happen. So we hope that
the HW does not go off for RX to work (DMA or PIO makes no difference
here).
For TX the situation is slightly different. RPM is enabled on
start_tx().
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/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git
Sometimes the OMAP UART does not signal the DMA engine to unload the FIFO.
Usually this happens when we have threshold bytes in the FIFO
and start the DMA transfer. It seems that in those cases the UART won't
trigger the transfer once the requested threshold is reached. In some
rare cases the UART
After dmaengine_terminate_all() has been invoked then both DMA drivers
(edma and omap-dma) do not invoke dma_cookie_complete() to mark the
transfer as complete. This dma_cookie_complete() is performed by the
Synopsys DesignWare driver which is probably the only one that is used
by omap8250-dma and
Hi Nishanth,
On Thu, Aug 21, 2014 at 02:01:43PM -0500, Nishanth Menon wrote:
On 08/21/2014 01:03 PM, Dmitry Torokhov wrote:
I believe I have taken care of other concerns on v2, but..Arrgh.. I
did not reply to this comment..
BTW, I do not think you need to use of_node_get/put here, it's not
Kevin,
On 09/09/2014 04:10 PM, Kevin Hilman wrote:
Dave Gerlach d-gerl...@ti.com writes:
Kevin/Ohad,
On 09/09/2014 02:59 PM, Suman Anna wrote:
Hi Ohad,
On 09/09/2014 05:31 AM, Ohad Ben-Cohen wrote:
On Tue, Sep 9, 2014 at 1:30 AM, Kevin Hilman khil...@linaro.org wrote:
To me, it's not
The '#mbox-cells' property is added to all the OMAP mailbox
nodes. This property is mandatory with the new mailbox framework.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell
Hi,
This is a repost of the Mailbox Framework adaptation support patches
for the OMAP mailbox driver (last 2 patches out of 5) from the OMAP
Mailbox framework adoption and DT support series [1]. The previous
series is split into 3 different series to resolve merge and build
dependencies.
The
The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+) are adapted to use the generic mailbox framework.
No changes are done to OMAP3 TI DSP/Bridge driver as it was
deleted.
The main changes for the adaptation are:
- The tasklet used for Tx is replaced with the state machine
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
51 matches
Mail list logo
