On 30.12.2014 03:23, Nishanth Menon wrote:
On 12/23/2014 04:48 AM, Marek Szyprowski wrote:
-static void l2c310_resume(void)
+static void l2c310_configure(void __iomem *base)
{
- void __iomem *base = l2x0_base;
+ unsigned revision;
- if (!(readl_relaxed(base + L2X0_CTRL)
On 30.12.2014 23:51, Nishanth Menon wrote:
Looks like the following also need addressing:
data-save is called twice (once more after l2cof_init)
l2c310_init_fns also needs l2c310_configure
will be nice to use l2x0_data only after we kmemdup data in __l2c_init
I'll check this.
Thanks.
* Vignesh R vigne...@ti.com [141223 23:07]:
The charge delay value is by default 0x400. But it can be set to lower
values on some boards, as long as false pen-ups are avoided. Lowering the
value increases the sampling rate (though current sampling rate is
sufficient for TSC operation). In some
On Thursday 01 January 2015 18:06:34 Rickard Strandqvist wrote:
-void omap_change_voltscale_method(struct voltagedomain *voltdm,
- int voltscale_method)
-{
- if (!voltdm || IS_ERR(voltdm)) {
- pr_warn(%s: VDD specified does not exist!\n,
Hello Ulf,
On Tue, Dec 30, 2014 at 11:29 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
On 19 December 2014 at 20:02, Doug Anderson diand...@chromium.org wrote:
It was a bit hard to follow the
updated the revisions, please don't send patches in-reply-to for
future sets.
Very strange. I
* Doug Anderson diand...@chromium.org [150102 09:09]:
Ulf,
On Tue, Dec 30, 2014 at 2:29 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
In v5, I don't find a patch 1/4. Anyway, I have taken patch 2-4.
Ah, maybe because it wasn't sent to linux-mmc? I messed that up and
will try to do
Ulf,
On Tue, Dec 30, 2014 at 2:29 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
In v5, I don't find a patch 1/4. Anyway, I have taken patch 2-4.
Ah, maybe because it wasn't sent to linux-mmc? I messed that up and
will try to do better in the future. Sorry. :( You were in the To
line,
On 01/02/2015 03:28 AM, Tomasz Figa wrote:
On 02.01.2015 18:13, Tomasz Figa wrote:
On 30.12.2014 23:51, Nishanth Menon wrote:
Looks like the following also need addressing:
data-save is called twice (once more after l2cof_init)
l2c310_init_fns also needs l2c310_configure
will be nice to
On 02.01.2015 18:13, Tomasz Figa wrote:
On 30.12.2014 23:51, Nishanth Menon wrote:
Looks like the following also need addressing:
data-save is called twice (once more after l2cof_init)
l2c310_init_fns also needs l2c310_configure
will be nice to use l2x0_data only after we kmemdup data in
* Aaro Koskinen aaro.koski...@iki.fi [150101 10:23]:
Hi,
On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
I see a In-band ERROR warning which wasn't present in 3.18.1.
Could it be that I missed some DT updates?
On 01/02/2015 03:13 AM, Tomasz Figa wrote:
However I'm not sure about your concern about using l2x0_data before
kmemdup(). I don't see any code potentially doing this.
It is not terribly important, but anyways [1] is what I had in mind..
[1]
OMAP4 and AM437x generations of processors support programming the
PL310 L2Cache controller's Latency control registers using a secure
montior call. Unfortunately, this varies from other PL310 programming
sequence with a requirement of two parameters instead of the generic
single parameter
AM437x generation of processors support programming the PL310 L2Cache
controller's address filter start and end registers using a secure
montior service.
Unfortunately, this secure monitor service is not supported on OMAP4
generation of processors.
Information based on:
OMAP4430 Public ROM Code
On 01/02/2015 02:55 AM, Tomasz Figa wrote:
On 30.12.2014 03:23, Nishanth Menon wrote:
On 12/23/2014 04:48 AM, Marek Szyprowski wrote:
-static void l2c310_resume(void)
+static void l2c310_configure(void __iomem *base)
{
- void __iomem *base = l2x0_base;
+ unsigned revision;
- if
OMAP4 and AM437x generations of processors support programming the
PL310 L2Cache controller's Latency control registers using a secure
montior call. Unfortunately, this varies from other PL310 programming
sequence with a requirement of two parameters instead of the generic
single parameter
AM437x generation of processors support programming the PL310 L2Cache
controller's address filter start and end registers using a secure
montior service.
Unfortunately, this secure monitor service is not supported on OMAP4
generation of processors.
Information based on:
OMAP4430 Public ROM Code
* Roger Quadros rog...@ti.com [141219 01:08]:
Lokesh,
On 19/12/14 07:21, Lokesh Vutla wrote:
Hi Roger,
On Thursday 18 December 2014 09:22 PM, Roger Quadros wrote:
Fixing up Paul's email id.
cheers,
-roger
On 18/12/14 17:49, Roger Quadros wrote:
There are quite a few hwmods
On 01/02/2015 11:38 AM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [150102 09:20]:
Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
registers and AM437x provides service for programming Address filter
registers.
Provide support in the kernel for the same.
* Nishanth Menon n...@ti.com [150102 09:20]:
Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
registers and AM437x provides service for programming Address filter
registers.
Provide support in the kernel for the same.
This provides some support to the series:
Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
registers and AM437x provides service for programming Address filter
registers.
Provide support in the kernel for the same.
V2 of the series contains documentation update and a bug fix due to a
typo introduced during
Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
registers and AM437x provides service for programming Address filter
registers.
Provide support in the kernel for the same.
This provides some support to the series:
Hi,
(please use reply-all to keep mailing lists in Cc, also avoid
top-posting)
On Fri, Jan 02, 2015 at 10:58:29AM -0800, Dave Taht wrote:
The beaglebone only has a 100mbit phy, so you aren't going to get more
than that.
very true :-) Still, with AM437x SK which is definitely GigE, I'm
getting
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:
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
The CPSW IP implements pulse-signaled interrupts. Due to
that we must write a correct, pre-defined value to the
CPDMA_MACEOIVECTOR register so the controller generates
a pulse on the correct IRQ line to signal the End Of
Interrupt.
The way the driver is written today, all four IRQ lines
are
Hi,
On Fri, Jan 02, 2015 at 10:49:49AM -0800, Dave Taht wrote:
+1.
We'd had a thread on netdev (can't find it now) where we discussed
adding BQL support and also something saner for the NAPI handling to
this driver.
yeah, currently is completely borked. I'm on a gigabit network and I'm
as it turns out the current IRQ number will
*always* be available from SIR register which
renders the reads of PENDING registers as plain
unnecessary overhead.
In order to catch any situation where SIR reads
as zero, we're adding a WARN() to turn it into
a very verbose error and users actually
Hi folks,
patch 1 fixes the bug reported by Yegor Yefremov yegorsli...@googlemail.com.
patches 2 - 4 improve IRQ handling a little bit.
Tested with BeagleBone Black and AM437x SK. The bug fix has been
tested for almost 3 days non-stop while the following patches
have been tested for a couple of
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
---
Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
* Aaro Koskinen aaro.koski...@iki.fi [150101 10:23]:
Hi,
On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
I see a In-band ERROR warning which wasn't present in 3.18.1.
On 1/2/15 9:43 AM, Nishanth Menon wrote:
Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
registers and AM437x provides service for programming Address filter
registers.
Provide support in the kernel for the same.
V2 of the series contains documentation update and a
Introduce a wkup_m3_ipc driver to handle communication between the MPU
and Cortex M3 wkup_m3 present on am335x.
This driver is responsible for actually booting the wkup_m3_rproc and
also handling all IPC which is done using the IPC registers in the control
module, a mailbox, and a separate
Add a remoteproc driver to load the firmware for and boot the wkup_m3
present on am33xx. The wkup_m3 is an integrated Cortex M3 that allows
the SoC to enter the lowest possible power state by taking control from
the MPU after it has gone into its own low power state and shutting off
any additional
Allow users of remoteproc the ability to get a handle to an rproc by
passing a phandle supplied in the user's device tree node. This is
useful in situations that require manual booting of the rproc.
This patch uses the code removed by commit 40e575b1d0b3 (remoteproc:
remove the get_by_name/put
Add wkup_m3_ipc node for wkup_m3_ipc driver.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index acd3705..1ebb230 100644
---
Add the device tree bindings document for ti,am3353-wkup-m3-ipc which
is used by the wkup_m3_ipc driver.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
.../devicetree/bindings/soc/ti/wkup_m3_ipc.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
This series introduces a wkup_m3_ipc driver to handle communication
between the MPU and Cortex M3 present on TI AM335x SoCs. This is
required for much of the PM functionality for AM335x including suspend
support. This was split off from v4 of the am335x suspend series,
discussion that led to the
Use pdata-quirks to provide platform data required for reset
of the wkup_m3 during boot.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c| 13 +
include/linux/platform_data/wkup_m3.h | 23 +++
2 files changed, 36
Hi,
This patch series adds a wkup_m3_rproc driver for TI AM335x SoCs.
This family of SoCs contains an ARM Cortex M3 coprocessor that is
responsible for low-level power tasks that cannot be handled by
the main ARM Cortex A8 so firmware running from the CM3 can be
used instead. This driver handles
On 01/02/2015 12:46 PM, santosh.shilim...@oracle.com wrote:
On 1/2/15 9:43 AM, Nishanth Menon wrote:
Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
registers and AM437x provides service for programming Address filter
registers.
Provide support in the kernel for
Add the device tree bindings document for ti,am3353-wkup-m3 which is
used by the wkup_m3_rproc driver.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
.../bindings/remoteproc/wkup_m3_rproc.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644
On Fri, Jan 02, 2015 at 02:00:16PM -0600, Dave Gerlach wrote:
Introduce a wkup_m3_ipc driver to handle communication between the MPU
and Cortex M3 wkup_m3 present on am335x.
This driver is responsible for actually booting the wkup_m3_rproc and
also handling all IPC which is done using the
On Fri, Jan 02, 2015 at 01:51:59PM -0600, Dave Gerlach wrote:
Add a remoteproc driver to load the firmware for and boot the wkup_m3
present on am33xx. The wkup_m3 is an integrated Cortex M3 that allows
the SoC to enter the lowest possible power state by taking control from
the MPU after it has
* Felipe Balbi ba...@ti.com [150102 10:50]:
as it turns out the current IRQ number will
*always* be available from SIR register which
renders the reads of PENDING registers as plain
unnecessary overhead.
In order to catch any situation where SIR reads
as zero, we're adding a WARN() to turn
+ Suman, lakml
Hi Roger
On Thu, 18 Dec 2014, Roger Quadros wrote:
Fixing up Paul's email id.
cheers,
-roger
On 18/12/14 17:49, Roger Quadros wrote:
There are quite a few hwmods that don't have sysconfig register and so
_find_mpu_rt_port(oh) will return NULL thus preventing ready
* Aaro Koskinen aaro.koski...@iki.fi [150102 12:21]:
Hi,
On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
* Aaro Koskinen aaro.koski...@iki.fi [150101 10:23]:
On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
When
Hi,
On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
* Aaro Koskinen aaro.koski...@iki.fi [150101 10:23]:
On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
I see
On Fri, Jan 02, 2015 at 01:32:51PM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [150102 10:50]:
as it turns out the current IRQ number will
*always* be available from SIR register which
renders the reads of PENDING registers as plain
unnecessary overhead.
In order to catch
On Friday 02 January 2015 17:02:21 Rickard Strandqvist wrote:
2015-01-02 10:46 GMT+01:00 Arnd Bergmann a...@arndb.de:
On Thursday 01 January 2015 18:06:34 Rickard Strandqvist wrote:
You have correctly spotted the only place that references
voltdm_for_each_pwrdm
and changed the comment,
On Fri, Jan 02, 2015 at 02:16:43PM -0600, Felipe Balbi wrote:
On Fri, Jan 02, 2015 at 02:00:16PM -0600, Dave Gerlach wrote:
Introduce a wkup_m3_ipc driver to handle communication between the MPU
and Cortex M3 wkup_m3 present on am335x.
This driver is responsible for actually booting the
The CPSW IP implements pulse-signaled interrupts. Due to
that we must write a correct, pre-defined value to the
CPDMA_MACEOIVECTOR register so the controller generates
a pulse on the correct IRQ line to signal the End Of
Interrupt.
The way the driver is written today, all four IRQ lines
are
Ping. Are you going to redo this one?
- Paul
On Wed, 26 Nov 2014, Paul Walmsley wrote:
Hi Lokesh
On Tue, 25 Nov 2014, Lokesh Vutla wrote:
Hi Paul,
On Thursday 20 November 2014 10:26 PM, Paul Walmsley wrote:
On Thu, 20 Nov 2014, Lokesh Vutla wrote:
On Monday 17 November
Hi,
On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote:
* Aaro Koskinen aaro.koski...@iki.fi [150102 12:21]:
On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
* Aaro Koskinen aaro.koski...@iki.fi [150101 10:23]:
On
as it turns out the current IRQ number will
*always* be available from SIR register which
renders the reads of PENDING registers as plain
unnecessary overhead.
In order to catch any situation where SIR reads
as zero, we're adding a WARN() to turn it into
a very verbose error and users actually
From: Felipe Balbi ba...@ti.com
Date: Fri, 2 Jan 2015 12:10:24 -0600
In any case, patch 1 should go in during the -rc an get backported
all the way back to v3.9, while the other patches can (should) be
delayed for v3.20 merge window.
If that's what you want, the way you submitted these
On Fri, Jan 02, 2015 at 04:45:36PM -0500, David Miller wrote:
From: Felipe Balbi ba...@ti.com
Date: Fri, 2 Jan 2015 12:10:24 -0600
In any case, patch 1 should go in during the -rc an get backported
all the way back to v3.9, while the other patches can (should) be
delayed for v3.20 merge
From: Felipe Balbi ba...@ti.com
Date: Fri, 2 Jan 2015 15:53:35 -0600
On Fri, Jan 02, 2015 at 04:45:36PM -0500, David Miller wrote:
You should instead submit patch #1 all by itself, correctly targetting
'net'.
Then, after the next time I merge 'net' into 'net-next', you can submit
the rest
On Fri, 19 Dec 2014, Tomi Valkeinen wrote:
Set DSS core hwmod as the parent for all the DSS submodules. This fixes
the boot time DSS reset, removing the following warnings:
omap_hwmod: dss_dispc: cannot be enabled for reset (3)
omap_hwmod: dss_rfbi: cannot be enabled for reset (3)
On Fri, 19 Dec 2014, Tomi Valkeinen wrote:
Set DSS core hwmod as the parent for all the DSS submodules. This fixes
the boot time DSS reset, removing the following warnings:
omap_hwmod: dss_dispc: cannot be enabled for reset (3)
omap_hwmod: dss_hdmi: cannot be enabled for reset (3)
On Fri, Jan 2, 2015 at 11:03 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
(please use reply-all to keep mailing lists in Cc, also avoid
top-posting)
I am trying not to read netdev right now... and failing, obviously.
On Fri, Jan 02, 2015 at 10:58:29AM -0800, Dave Taht wrote:
The beaglebone
Removes some functions that are not used anywhere:
omap_change_voltscale_method() voltdm_add_pwrdm()
voltdm_for_each() voltdm_for_each_pwrdm()
And remove define VOLTSCALE_VPFORCEUPDATE and VOLTSCALE_VCBYPASS
This was partially found by using a static code analysis program called
cppcheck.
* Felipe Balbi ba...@ti.com [150102 14:19]:
The CPSW IP implements pulse-signaled interrupts. Due to
that we must write a correct, pre-defined value to the
CPDMA_MACEOIVECTOR register so the controller generates
a pulse on the correct IRQ line to signal the End Of
Interrupt.
The way the
* Aaro Koskinen aaro.koski...@iki.fi [150102 14:37]:
Hi,
On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote:
* Aaro Koskinen aaro.koski...@iki.fi [150102 12:21]:
On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
Hi Tony,
2015-01-03 9:23 GMT+09:00 Tony Lindgren t...@atomide.com:
* Nishanth Menon n...@ti.com [150102 11:50]:
On 01/02/2015 12:46 PM, santosh.shilim...@oracle.com wrote:
On 1/2/15 9:43 AM, Nishanth Menon wrote:
Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
Hi,
On Fri, Jan 02, 2015 at 02:56:36PM -0800, Dave Taht wrote:
On Fri, Jan 2, 2015 at 11:03 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
(please use reply-all to keep mailing lists in Cc, also avoid
top-posting)
I am trying not to read netdev right now... and failing, obviously.
oops :-)
* Nishanth Menon n...@ti.com [150102 11:50]:
On 01/02/2015 12:46 PM, santosh.shilim...@oracle.com wrote:
On 1/2/15 9:43 AM, Nishanth Menon wrote:
Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
registers and AM437x provides service for programming Address filter
Hi Nishanth,
2015-01-03 2:43 GMT+09:00 Nishanth Menon n...@ti.com:
AM437x generation of processors support programming the PL310 L2Cache
controller's address filter start and end registers using a secure
montior service.
typo: s/montior/monitor/
[snip]
+ base =
Hi,
On Tue, Dec 30, 2014 at 11:12:51AM +0100, Arnd Bergmann wrote:
On Monday 29 December 2014 01:52:04 Sneeker Yeh wrote:
+static int dwc3_mb86s70_remove_child(struct device *dev, void *unused)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+
Here are some basic OMAP test results for Linux v3.19-rc1.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.19-rc1/20150102151849/
Test summary
Build: uImage:
Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
Here are some basic OMAP test results for Linux v3.19-rc2.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.19-rc2/20150102204752/
Test summary
Build: uImage:
Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
70 matches
Mail list logo
