Hi Seb,
On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 16
1 file changed, 16 insertions(+)
diff --git
On 10/23/2012 10:09 AM, Benoit Cousson wrote:
On 10/23/2012 04:49 PM, Jon Hunter wrote:
Hi Seb,
On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/boot/dts
Hi Mitch,
On 10/23/2012 11:55 AM, Mitch Bradley wrote:
On 10/23/2012 4:49 AM, Jon Hunter wrote:
Therefore, I believe it will improve search time and hence, boot time if
we have interrupt-parent defined in each node.
I strongly suspect (based on many years of performance tuning
Hi Gururaja,
On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote:
Hi,
I came across a peculiar issue while updating GPIO debounce registers on
OMAP platform.
According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537
gpio/omap: save and restore debounce registers
GPIO debounce
Hi Gururaja,
On 10/18/2012 12:31 AM, Hebbar, Gururaja wrote:
Jon,
On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote:
[snip]
My doubt/questions are
1. Why should debounce registers be updated only when it's accessed
previously?
If debounce is not being used by any of the gpios, then
On 04/17/2013 02:09 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
Abstract away the pinmux and the LED definitions for the two boards.
Just a heads-up but you should base this upon Benoit's for_3.10 branch
[1] as there is now a
of_node_put().
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Acked-by: Arnd Bergmann a...@arndb.de
Thanks! FWIW ...
Reviewed-by: Jon Hunter jon-hun...@ti.com
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On 04/19/2013 04:42 AM, Lars-Peter Clausen wrote:
Currently the OF DMA code uses a spin lock to protect the of_dma_list from
concurrent access and a per controller reference count to protect the
controller
from being freed while a request operation is in progress. If
On 04/20/2013 05:38 AM, Arnd Bergmann wrote:
On Saturday 20 April 2013, Lars-Peter Clausen wrote:
On 04/20/2013 12:45 AM, Jon Hunter wrote:
I think that there is a problem here. For controllers using the
of_dma_simple_xlate(), this will call dma_request_channel() which also
uses a mutex
On 04/19/2013 06:13 PM, Arnd Bergmann wrote:
On Saturday 20 April 2013, Jon Hunter wrote:
Change also means that of_dma_request_slave_channel() cannot be called
from a context where it is not possible to sleep too, right? May be
worth mentioning this in the changelog as well.
You already
On 03/20/2013 06:56 AM, Tomi Valkeinen wrote:
On 2013-03-19 10:03, Alexandru Gheorghiu wrote:
Use PTR_RET function instead of IS_ERR and PTR_ERR.
Patch found using coccinelle.
Signed-off-by: Alexandru Gheorghiu gheorghiuan...@gmail.com
---
drivers/video/omap2/dss/core.c |5 +
1
On 03/20/2013 11:59 AM, Tomi Valkeinen wrote:
On 2013-03-20 17:44, Jon Hunter wrote:
On 03/20/2013 06:56 AM, Tomi Valkeinen wrote:
On 2013-03-19 10:03, Alexandru Gheorghiu wrote:
Use PTR_RET function instead of IS_ERR and PTR_ERR.
Patch found using coccinelle.
Signed-off-by: Alexandru
On 03/20/2013 01:02 PM, Jon Hunter wrote:
On 03/20/2013 11:59 AM, Tomi Valkeinen wrote:
On 2013-03-20 17:44, Jon Hunter wrote:
On 03/20/2013 06:56 AM, Tomi Valkeinen wrote:
On 2013-03-19 10:03, Alexandru Gheorghiu wrote:
Use PTR_RET function instead of IS_ERR and PTR_ERR.
Patch found
On 03/12/2013 06:05 AM, Russell King - ARM Linux wrote:
On Tue, Mar 12, 2013 at 09:58:29AM +0200, Silviu-Mihai Popescu wrote:
This uses PTR_RET instead of IS_ERR and PTR_ERR in order to increase
readability.
Signed-off-by: Silviu-Mihai Popescu silviupopescu1...@gmail.com
---
On 03/22/2013 11:36 AM, Russell King - ARM Linux wrote:
On Wed, Mar 20, 2013 at 01:28:47PM -0500, Jon Hunter wrote:
Sorry I am now not sure I follow you here. Someone just pointed out to
me that PTR_RET() is defined as ...
static inline int __must_check PTR_RET(const void *ptr
causes regression on omap3,4 platform
which are not yet dma dt adapted.
It is best to send this patch along with Jon Hunter dma dt series,
which adds dt dma support and mmc dma data. DMA dt series is needed
any way before hwmod cleanup can happen.
*sigh* ok, I should have never split this stuff
;
}
- if (unlikely(!inuse)) {
+ if (unlikely(!twl_priv-ready)) {
Same problem here.
Here is a fix ...
From 141fcbbdee6bdc14d5a444ff20fad6b3440215dc Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Fri, 8 Feb 2013 12:42:20 -0600
Subject: [PATCH] ARM: OMAP2+: Fix
On 02/09/2013 08:52 PM, Tony Lindgren wrote:
Hi,
* Ruslan Bilovol ruslan.bilo...@ti.com [130208 11:41]:
The OMAP4 Blaze Tablet is TI OMAP4 processor-based
development platform in a tablet formfactor.
The platform contains many of the features found in
present-day handsets (such as audio,
On 02/08/2013 11:50 PM, Peter Ujfalusi wrote:
On 02/08/2013 07:56 PM, Jon Hunter wrote:
/**
* twl_i2c_write - Writes a n bit register in TWL4030/TWL5030/TWL60X0
* @mod_no: module number
@@ -322,16 +323,17 @@ int twl_i2c_write(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes
On 02/12/2013 01:26 AM, Peter Ujfalusi wrote:
On 02/11/2013 09:22 PM, Jon Hunter wrote:
Good point. I just noticed that none of my omap2+ board were booting and
on omap3/4 I was the panic in the twl code. I can't say that I checked
the panic on omap2, so may be that was another problem?
Do
On 02/13/2013 03:28 AM, Sourav Poddar wrote:
Booting 3.8-rc6 on omap4 panda results in the following error
[0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
[0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
[0.473937] omap_i2c 48072000.i2c: did not
On 02/13/2013 09:57 AM, Jon Hunter wrote:
On 02/13/2013 03:28 AM, Sourav Poddar wrote:
Booting 3.8-rc6 on omap4 panda results in the following error
[0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
[0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
On 02/13/2013 05:28 PM, Ruslan Bilovol wrote:
Hi Tony, Jon,
On Mon, Feb 11, 2013 at 9:00 PM, Tony Lindgren t...@atomide.com wrote:
* Jon Hunter jon-hun...@ti.com [130211 10:58]:
Please note that the blaze is derived from the omap4-sdp board and so I
would hope that we can use the existing
On 12/19/2012 03:24 PM, Pratik Patel wrote:
[snip]
Currently we use the CoreSight virtual bus to conveniently list
sysfs configuration attributes for all the registered CoreSight
devices.
For eg:
/sys/bus/coresight/devices/coresight-etm0/attribute
On 12/20/2012 01:51 PM, Pratik Patel wrote:
On Thu, Dec 20, 2012 at 11:46:13AM -0600, Jon Hunter wrote:
On 12/19/2012 03:24 PM, Pratik Patel wrote:
[snip]
Currently we use the CoreSight virtual bus to conveniently list
sysfs configuration attributes for all the registered CoreSight
On 12/21/2012 04:18 PM, Pratik Patel wrote:
On Thu, Dec 20, 2012 at 04:54:38PM -0600, Jon Hunter wrote:
On 12/20/2012 01:51 PM, Pratik Patel wrote:
On Thu, Dec 20, 2012 at 11:46:13AM -0600, Jon Hunter wrote:
On 12/19/2012 03:24 PM, Pratik Patel wrote:
[snip]
Currently we use
Hi Neil,
On 12/12/2012 02:24 AM, NeilBrown wrote:
This patch is based on an earlier patch by Grant Erickson
which provided pwm devices using the 'legacy' interface.
This driver instead uses the new framework interface.
Cc: Grant Erickson maratho...@gmail.com
Signed-off-by: NeilBrown
On 12/12/2012 05:31 AM, Thierry Reding wrote:
On Wed, Dec 12, 2012 at 07:24:30PM +1100, NeilBrown wrote:
[snip]
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+struct omap_chip *omap = to_omap_chip(chip);
+int status = 0;
+
+/* Enable the
On 12/12/2012 09:06 PM, NeilBrown wrote:
[Thierry: question for you near the end - thanks]
On Wed, 12 Dec 2012 10:08:28 -0600 Jon Hunter jon-hun...@ti.com wrote:
Hi Neil,
On 12/12/2012 02:24 AM, NeilBrown wrote:
This patch is based on an earlier patch by Grant Erickson
which
On 12/12/2012 10:33 PM, NeilBrown wrote:
On Thu, 13 Dec 2012 14:06:35 +1100 NeilBrown ne...@suse.de wrote:
+ omap_dm_timer_enable(omap-dm_timer);
Do you need to call omap_dm_timer_enable here? _set_load and _set_match
will enable the timer. So this should not be necessary.
True. That
On 11/15/2012 11:07 AM, Igor Mazanov wrote:
Remove inline from clock framework function definitions to
build the kernel with GCC 4.7
Adding Mike to the party ...
May be good to add some details about the exact problem seen.
I am seeing the same problem today with GCC 4.7 and Tony's master
On 11/16/2012 03:36 AM, Arnd Bergmann wrote:
On Thursday 15 November 2012, Lee Jones wrote:
On Thu, 15 Nov 2012, Arnd Bergmann wrote:
On Thursday 15 November 2012, Lee Jones wrote:
UARTs no longer require call-back information, since the reset
call-back was removed in
On 01/06/2013 03:12 PM, NeilBrown wrote:
[snip]
I've been playing with off-mode and discovered that the first attempt to set
the PWM after resume didn't work, but subsequent ones did.
I did some digging and came up with the following patch.
With this in place, the omap_pwm_suspend() above
);
return np;
Otherwise ...
Acked-by: Jon Hunter jon-hun...@ti.com
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
On 28/05/13 23:05, Stephen Warren wrote:
On 05/28/2013 03:25 PM, Jon Hunter wrote:
On 27/05/13 15:37, Afzal Mohammed wrote:
AM43x timer bindings.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
1 file changed, 2 insertions
On 04/22/2013 03:33 AM, Lars-Peter Clausen wrote:
Both of_dma_nbcells field of the of_dma_controller and the args_count field of
the dma_spec are initialized by parsing the #dma-cells attribute of their
device
tree node. So if the device tree nodes of a DMA controller and the dma_spec
match
On 04/22/2013 04:00 PM, Lars-Peter Clausen wrote:
On 04/22/2013 10:52 PM, Jon Hunter wrote:
On 04/22/2013 03:33 AM, Lars-Peter Clausen wrote:
Both of_dma_nbcells field of the of_dma_controller and the args_count field
of
the dma_spec are initialized by parsing the #dma-cells attribute
,
int posted)
{
char name[10]; /* 10 = sizeof(gptXX_Xck0) */
- const char *oh_name;
+ const char *oh_name = NULL;
struct device_node *np;
struct omap_hwmod *oh;
struct resource irq, mem;
Thanks!
Acked-by: Jon Hunter jgchun...@gmail.com
On 27/05/13 15:37, Afzal Mohammed wrote:
AM43x 32K counter binding.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Documentation/devicetree/bindings/arm/omap/counter.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/counter.txt
On 27/05/13 15:37, Afzal Mohammed wrote:
AM43x timer bindings.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
Hi Paul,
On 02/11/2015 02:25 AM, Paul Walmsley wrote:
Hi John,
thanks for the review,
On Tue, 10 Feb 2015, Jon Hunter wrote:
[snip]
Subject: [PATCH] ARM: OMAP1: PM: fix some build warnings on 1510-only Kconfigs
Building an OMAP1510-only Kconfig generates the following warnings
On 02/11/2015 09:14 PM, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [150211 13:03]:
On Wed, 11 Feb 2015, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [150210 18:28]:
On Tue, 10 Feb 2015, Jon Hunter wrote:
On 07/02/2015 00:23, Paul Walmsley wrote:
Unfortunately
built with both CONFIG_OMAP_DM_TIMER=y and
CONFIG_OMAP_32K_TIMER=y.
While here, clean up a few printk()s and unnecessary #ifdefs.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Jon Hunter jonath...@nvidia.com
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Tuukka Tikkanen tuukka.tikka
On 02/12/2015 11:26 AM, Jon Hunter wrote:
On 02/11/2015 09:14 PM, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [150211 13:03]:
On Wed, 11 Feb 2015, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [150210 18:28]:
On Tue, 10 Feb 2015, Jon Hunter wrote:
On 07/02/2015 00:23, Paul
On 02/19/2015 06:28 PM, Pantelis Antoniou wrote:
Hi Tony,
On Feb 19, 2015, at 20:16 , Tony Lindgren t...@atomide.com wrote:
* Pantelis Antoniou pantelis.anton...@konsulko.com [150218 07:03]:
Implement DT quirks for the am33xx beaglebone boards.
--- /dev/null
+++
().
If dma_get_any_slave_channel() allocates a channel also ensure the
DMA_PRIVATE flag is set, in case it was not before. If the privatecnt
becomes 0 then the DMA_PRIVATE flag should be cleared.
Cc: Stephen Warren swar...@nvidia.com
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
This issue was found when
.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
Cc: Mikko Perttunen mikko.perttu...@kapsi.fi
Cc: Tuomas Tynkkynen ttynkky...@nvidia.com
---
Hi,
hope I have gotten it right this time, but please do check :)
FWIW, this works for me.
Tested-by: Jon Hunter jonath...@nvidia.com
Cheers
Jon
and ethernet dongles. This has also been tested, with additional
out-of-tree patches, on Tegra132 and Tegra210 based boards.
For the series, you can add my ...
Reviewed-by: Jon Hunter jonath...@nvidia.com
Tested-by: Jon Hunter jonath...@nvidia.com
I have tested this on a t124 nyan-big
Hi Thierry,
On 05/05/15 15:42, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, May 05, 2015 at 03:28:25PM +0100, Jon Hunter wrote:
Hi Andrew,
On 04/05/15 18:36, Andrew Bresticker wrote:
This series adds support for xHCI on NVIDIA Tegra SoCs. This includes:
- patches 1, 2
() call to after check to see
if DMA has completed because if the DMA is in progress we do not need
to ACK yet. Changed the print from dev_info to dev_debug. Updated
changelog to add more commentary on the race condition based upon
feedback from author.]
Signed-off-by: Jon Hunter jonath...@nvidia.com
-by: Jon Hunter jonath...@nvidia.com
---
drivers/tty/serial/serial-tegra.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/serial-tegra.c
b/drivers/tty/serial/serial-tegra.c
index 17d8a08b047b..a5312e4b6393 100644
--- a/drivers/tty/serial
The DMA cookie for the RX channel is being used by the TX channel.
Therefore, fix driver to use the correct DMA cookie for the TX channel.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/tty/serial/serial-tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/tty/serial/serial-tegra.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/serial-tegra.c
b/drivers/tty/serial/serial-tegra.c
index 1d5ea3964ee5..9e08d3f07509 100644
For all tegra devices (up to t210), there is a hardware issue that
requires software to wait for 3 UART clock periods after enabling
the TX fifo, otherwise data could be lost.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/tty/serial/serial-tegra.c | 10 ++
1 file changed, 10
Various fixes for the tegra hsuart driver.
Tested on tegra124 nyan-big by opening a serial console on ttyTHS0
and performing simple z-modem transfers.
Jon Hunter (6):
serial: tegra: Correct delay after TX flush
serial: tegra: Add delay after enabling FIFO mode
serial: tegra: Use unsigned
tegra_uart_copy_rx_to_tty(). Updated
changelog with more commentary.]
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/tty/serial/serial-tegra.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/serial-tegra.c
b/drivers/tty/serial/serial
and then unmap the DMA
buffer. Finally, remove the unnecessary call to tegra_uart_flush_buffer().
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/tty/serial/serial-tegra.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/serial-tegra.c
b
is not freed/unmapped. Therefore, call tegra_uart_dma_channel_free()
instead of just dma_release_channel() if dmaengine_slave_config() fails.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/tty/serial/serial-tegra.c | 51 +--
1 file changed, 28 insertions
Hi Valentin,
On 13/05/15 14:22, Valentin Rothberg wrote:
Hi Andrew,
your commit b1f10002b00a (mailbox: Add NVIDIA Tegra XUSB mailbox
driver) is in today's linux-next tree (i.e., next-20150513) and it
adds the following lines:
+config TEGRA_XUSB_MBOX
+ tristate NVIDIA Tegra XUSB
On 12/05/15 09:39, Alexandre Courbot wrote:
On Tue, May 5, 2015 at 11:17 PM, Jon Hunter jonath...@nvidia.com wrote:
Function tegra_uart_dma_channel_allocate() does not check that
dma_map_single() mapped the DMA buffer correctly. Add a check for this
and appropriate error handling
On 14/05/15 11:23, Lee Jones wrote:
On Thu, 14 May 2015, Jon Hunter wrote:
On 14/05/15 10:30, Lee Jones wrote:
On Thu, 14 May 2015, Jon Hunter wrote:
On 14/05/15 08:40, Lee Jones wrote:
On Thu, 14 May 2015, Jon Hunter wrote:
On 13/05/15 15:39, Lee Jones wrote:
On Mon, 04 May 2015, Andrew
On 14/05/15 08:29, Lee Jones wrote:
On Wed, 13 May 2015, Andrew Bresticker wrote:
On Wed, May 13, 2015 at 9:50 AM, Lee Jones lee.jo...@linaro.org wrote:
On Wed, 13 May 2015, Andrew Bresticker wrote:
Lee,
On Wed, May 13, 2015 at 7:39 AM, Lee Jones lee.jo...@linaro.org wrote:
On Mon, 04
Hi Lee,
On 13/05/15 15:39, Lee Jones wrote:
On Mon, 04 May 2015, Andrew Bresticker wrote:
Add a binding document for the XUSB host complex on NVIDIA Tegra124
and later SoCs. The XUSB host complex includes a mailbox for
communication with the XUSB micro-controller and an xHCI
On 14/05/15 08:40, Lee Jones wrote:
On Thu, 14 May 2015, Jon Hunter wrote:
Hi Lee,
On 13/05/15 15:39, Lee Jones wrote:
On Mon, 04 May 2015, Andrew Bresticker wrote:
Add a binding document for the XUSB host complex on NVIDIA Tegra124
and later SoCs. The XUSB host complex includes
On 14/05/15 10:30, Lee Jones wrote:
On Thu, 14 May 2015, Jon Hunter wrote:
On 14/05/15 08:40, Lee Jones wrote:
On Thu, 14 May 2015, Jon Hunter wrote:
On 13/05/15 15:39, Lee Jones wrote:
On Mon, 04 May 2015, Andrew Bresticker wrote:
Add a binding document for the XUSB host complex on NVIDIA
On 13/05/15 05:56, Alexandre Courbot wrote:
On Tue, May 12, 2015 at 6:51 PM, Jon Hunter jonath...@nvidia.com wrote:
On 12/05/15 09:39, Alexandre Courbot wrote:
On Tue, May 5, 2015 at 11:17 PM, Jon Hunter jonath...@nvidia.com wrote:
Function tegra_uart_dma_channel_allocate() does not check
On 20/05/15 04:57, Alexandre Courbot wrote:
[snip]
There may still be a leak (that is not related to your patch) in the
RX path though:
dma_buf = dma_alloc_coherent(...);
ret = dmaengine_slave_config(...);
if (ret 0) {
...
goto scrub;
}
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/tty/serial/serial-tegra.c | 32 +++-
1 file changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/tty/serial/serial-tegra.c
b/drivers/tty/serial/serial-tegra.c
index 3b63f103f0c9..cf0133ae762d 100644
On 20/05/15 12:21, Jon Hunter wrote:
If the call to dmaengine_slave_config() fails, then the DMA buffer will
not be freed/unmapped. Fix this by moving the code that stores the
address of the buffer in the tegra_uart_port structure to before the
call to dmaengine_slave_config().
By the way
On 20/05/15 12:25, Jon Hunter wrote:
On 20/05/15 12:21, Jon Hunter wrote:
If the call to dmaengine_slave_config() fails, then the DMA buffer will
not be freed/unmapped. Fix this by moving the code that stores the
address of the buffer in the tegra_uart_port structure to before the
call
On 20/05/15 10:51, Jon Hunter wrote:
On 20/05/15 04:57, Alexandre Courbot wrote:
[snip]
There may still be a leak (that is not related to your patch) in the
RX path though:
dma_buf = dma_alloc_coherent(...);
ret = dmaengine_slave_config(...);
if (ret 0
On 05/06/15 00:02, Paul Walmsley wrote:
Hi folks
just a brief comment on this one:
On Thu, 30 Apr 2015, Boris Brezillon wrote:
Clock rates are stored in an unsigned long field, but -round_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are
Hi Boris,
On 05/06/15 12:39, Boris Brezillon wrote:
Hi Jon,
On Fri, 5 Jun 2015 09:46:09 +0100
Jon Hunter jonath...@nvidia.com wrote:
On 05/06/15 00:02, Paul Walmsley wrote:
Hi folks
just a brief comment on this one:
On Thu, 30 Apr 2015, Boris Brezillon wrote:
Clock rates
;
polling-delay = 1000;
thermal-sensors =
soctherm TEGRA124_SOCTHERM_SENSOR_CPU;
};
Acked-by: Jon Hunter jonath...@nvidia.com
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
Any feedback on this series?
Cheers Jon
On 06/08/15 14:32, Jon Hunter wrote:
Some clean-up changes for the tegra-apb DMA driver.
These have been compile and boot tested for ARM and ARM64. Summary of the
ARM results are below. ARM64 has been tested locally.
Test summary
already locked. To avoid this,
don't use the lock for PLLD/PLLD2, just wait 1ms and treat the clocks as
locked.
Signed-off-by: Vince Hsu vin...@nvidia.com
[jonath...@nvidia.com: Updated the changelog description]
Signed-off-by: Jon Hunter jonath...@nvidia.com
Acked-by: Peter De Schrijver pdeschrij
On 24/08/15 10:22, Vinod Koul wrote:
On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote:
On 23/08/15 15:17, Vinod Koul wrote:
On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote:
@@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev)
int ret
Add device-tree binding documentation for the Tegra210 Audio DMA
controller.
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: Jon Hunter
Move code that is common between the Tegra20-APB DMA and Tegra210 ADMA
driver into separate source files.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/dma/Kconfig | 4 +
drivers/dma/Makefile | 1 +
drivers/dma/tegra-common.c| 733
is defined as 0 and so this setting
can be completely removed.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/dma/tegra20-apb-dma.c | 53 ---
1 file changed, 19 insertions(+), 34 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma
Add support for the Tegra210 Audio DMA controller that is used for
transferring data between system memory and the Audio sub-system.
This driver is based upon the work by Dara Ramesh dram...@nvidia.com.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/dma/Kconfig | 12
, it still
needs further functional testing to ensure it is working well.
This series is based upon the Tegra-APB clean-up series [0].
[0] https://lkml.org/lkml/2015/8/6/315
Jon Hunter (7):
DMA: tegra-apb: Correct runtime-pm usage
DMA: tegra-apb: Move code dealing with h/w registers into separate
-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/dma/tegra20-apb-dma.c | 36
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index c8f79dcaaee8..097432ea89fa 100644
--- a/drivers
function pointers in the table are compulsory and so no
checking that the function pointer is valid is performed.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/dma/tegra20-apb-dma.c | 92 +--
1 file changed, 71 insertions(+), 21 deletions(-)
diff
much the same. Hence, by isolating code that deals with the hardware
registers it will then be possible to add a function table to call code
that accesses the hardware registers and re-use the common driver code
for both DMAs.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/dma/tegra20-apb
On 23/08/15 15:17, Vinod Koul wrote:
On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote:
@@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev)
int ret;
/* Enable clock before accessing register */
-ret = tegra_dma_runtime_resume(dev);
+ret
On 23/08/15 15:33, Vinod Koul wrote:
On Tue, Aug 18, 2015 at 02:49:15PM +0100, Jon Hunter wrote:
+#define AHUB_TO_MEMORY 2
+#define MEMORY_TO_AHUB 4
namespace this aptly as well
+static void
On 29/07/15 19:33, Russell King - ARM Linux wrote:
On Wed, Jul 29, 2015 at 03:43:04PM +0100, Jon Hunter wrote:
The gic_init_bases() function initialises an array that stores the mapping
between the GIC and CPUs. This array is a global array that is
unconditionally initialised on every call
for the primary GIC.
For secondary GICs the CPU map is not relevant because these GICs do not
directly route the interrupts to the main CPU(s) but to other GICs or
devices.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
This is a follow-up to the patch titled irqchip: gic: Add a cpu map for
each GIC
On 30/07/15 15:33, Marc Zyngier wrote:
On 30/07/15 15:11, Jon Hunter wrote:
The gic_init_bases() function initialises an array that stores the mapping
between the GIC and CPUs. This array is a global array that is
unconditionally initialised on every call to gic_init_bases(). Although
On 30/07/15 16:05, Jon Hunter wrote:
On 30/07/15 15:33, Marc Zyngier wrote:
On 30/07/15 15:11, Jon Hunter wrote:
The gic_init_bases() function initialises an array that stores the mapping
between the GIC and CPUs. This array is a global array that is
unconditionally initialised on every
On 30/07/15 19:11, Marc Zyngier wrote:
On 30/07/15 18:56, Jon Hunter wrote:
On 30/07/15 17:51, Marc Zyngier wrote:
On 30/07/15 17:26, Jon Hunter wrote:
Commit 3228950621d9 (irqchip: gic: Preserve gic V2 bypass bits in cpu
ctrl register) added a new function, gic_cpu_if_up(), to program
On 30/07/15 17:26, Jon Hunter wrote:
Commit 3228950621d9 (irqchip: gic: Preserve gic V2 bypass bits in cpu
ctrl register) added a new function, gic_cpu_if_up(), to program the
GIC CPU_CTRL register. This function assumes that there is only one GIC
instance present and hence always uses
On 30/07/15 08:19, Marc Zyngier wrote:
On Wed, 29 Jul 2015 17:10:45 +0100
Thomas Gleixner t...@linutronix.de wrote:
On Wed, 29 Jul 2015, Jon Hunter wrote:
Cc'ing Marc ...
Thanks for looping me in.
The gic_init_bases() function initialises an array that stores the mapping
between
On 30/07/15 09:20, Marc Zyngier wrote:
On 29/07/15 20:27, Jon Hunter wrote:
On 29/07/15 19:33, Russell King - ARM Linux wrote:
On Wed, Jul 29, 2015 at 03:43:04PM +0100, Jon Hunter wrote:
The gic_init_bases() function initialises an array that stores the mapping
between the GIC and CPUs
() should always
be successful.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
V2 changes:
- Rebased on v4.2-rc4
- Added test to ensure GIC instance is valid to gic_cpu_if_down() and
updated gic_cpu_if_down() to return an error code on failure.
arch/arm/mach-vexpress/tc2_pm.c | 2
for the primary GIC.
For secondary GICs the CPU map is not relevant because these GICs do not
directly route the interrupts to the main CPU(s) but to other GICs or
devices.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
V2 changes:
- Rebased on v4.2-rc4
drivers/irqchip/irq-gic.c | 43
this function so that an instance
number is passed for the appropriate GIC. The vexpress TC2 (which has
a single GIC) is currently the only user of this function and so update
it accordingly.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
I was hoping to make the gic_cpu_if_up/down function more
for the primary GIC.
For secondary GICs the CPU map is not relevant because these GICs do not
directly route the interrupts to the main CPU(s) but to other GICs or
devices.
Signed-off-by: Jon Hunter jonath...@nvidia.com
---
drivers/irqchip/irq-gic.c | 43 +--
1 file
On 30/07/15 17:51, Marc Zyngier wrote:
On 30/07/15 17:26, Jon Hunter wrote:
Commit 3228950621d9 (irqchip: gic: Preserve gic V2 bypass bits in cpu
ctrl register) added a new function, gic_cpu_if_up(), to program the
GIC CPU_CTRL register. This function assumes that there is only one GIC
1 - 100 of 3084 matches
Mail list logo
