* Olof Johansson o...@lixom.net [140710 14:37]:
On Wed, Jul 09, 2014 at 08:35:52AM -0700, Tony Lindgren wrote:
The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:
Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)
are available in the git repository at:
* Sebastian Andrzej Siewior bige...@linutronix.de [140710 08:50]:
On 07/10/2014 09:09 AM, Tony Lindgren wrote:
You can test this pretty easily on beagleboard xm for example
using v3.16-r4:
I tried this with am335x-evm, dra7-evm and beaglebone (omap5-uevm and
am335x-evmsk didn't want to
* Roger Quadros rog...@ti.com [140709 05:39]:
Hi,
The following hardware modules/registers are meant for NAND controller driver
usage:
- NAND I/O control (NAND address, data, command registers)
- Prefetch/Write-post engine
- ECC/BCH engine
However, these registers sit in the GPMC
Hi Roger,
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140709 05:39]:
Hi,
The following hardware modules/registers are meant for NAND controller driver
usage:
- NAND I/O control (NAND address, data, command registers)
- Prefetch/Write-post engine
- ECC/BCH
From: Quadros, Roger
Instead of hardcoding use the pre-calculated chip-ecc.steps for
configuring number of sectors to process with the BCH algorithm.
This also avoids unnecessary access to the ECC_CONFIG register in
omap_calculate_ecc_bch().
Signed-off-by: Roger Quadros rog...@ti.com
---
Hi Roger,
From: Quadros, Roger
Even though the ECC/BCH engine is meant for exclusive use by
the OMAP NAND controller, the ECC/BCH registers belong
to the GPMC controller's register space
Add omap_gpmc_ecc_configure_enable() and omap_gpmc_ecc_disable()
to manage the ECC engine. OMAP NAND driver
Roger,
From: Quadros, Roger
Don't access the ECC/BCH engine registers directly as they belong
to the GPMC controller's register space. Use the relevant
GPMC APIs instead.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 191
On 07/11/2014 04:55 AM, Dave Gerlach wrote:
This series adds suspend/resume support for am335x. Version 3 of this
series can be found at [1]. I apologize for the large delay between this
and the previous revision. This code has been heavily refined
since the last version based on the various
Hi Pekon,
On 07/11/2014 10:27 AM, Gupta, Pekon wrote:
Hi Roger,
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140709 05:39]:
Hi,
The following hardware modules/registers are meant for NAND controller
driver
usage:
- NAND I/O control (NAND address, data,
From: Quadros, Roger
On 07/11/2014 10:27 AM, Gupta, Pekon wrote:
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140709 05:39]:
Hi,
The following hardware modules/registers are meant for NAND controller
driver
usage:
- NAND I/O control (NAND address, data,
On 07/11/2014 12:42 PM, Gupta, Pekon wrote:
From: Quadros, Roger
On 07/11/2014 10:27 AM, Gupta, Pekon wrote:
From: Tony Lindgren [mailto:t...@atomide.com]
* Roger Quadros rog...@ti.com [140709 05:39]:
Hi,
The following hardware modules/registers are meant for NAND controller
driver
On 07/11/2014 10:43 AM, Gupta, Pekon wrote:
From: Quadros, Roger
Instead of hardcoding use the pre-calculated chip-ecc.steps for
configuring number of sectors to process with the BCH algorithm.
This also avoids unnecessary access to the ECC_CONFIG register in
omap_calculate_ecc_bch().
From: Quadros, Roger
On 07/11/2014 10:43 AM, Gupta, Pekon wrote:
From: Quadros, Roger
[...]
@@ -1176,6 +1172,7 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info
*mtd,
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
On 07/11/2014 02:27 PM, Gupta, Pekon wrote:
From: Quadros, Roger
On 07/11/2014 10:43 AM, Gupta, Pekon wrote:
From: Quadros, Roger
[...]
@@ -1176,6 +1172,7 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info
*mtd,
{
struct omap_nand_info *info = container_of(mtd,
On 07/09/2014 03:49 PM, Roger Quadros wrote:
Hi Rostislav,
On 06/04/2014 05:24 PM, Rostislav Lisovy wrote:
GPMC controller supports up to 8 memory devices connected to it.
Since there is one statically allocated struct platform_device
gpmc_nand_device it is not possible to configure the
On 06/04/2014 05:24 PM, Rostislav Lisovy wrote:
GPMC controller supports up to 8 memory devices connected to it.
Since there is one statically allocated struct platform_device
gpmc_nand_device it is not possible to configure the system to
use more than one NAND device connected to the GPMC.
Hi Dave,
On Thu, Jul 10, 2014 at 09:55:38PM -0500, Dave Gerlach wrote:
Hello,
This series adds suspend/resume support for am335x. Version 3 of this
series can be found at [1]. I apologize for the large delay between this
and the previous revision. This code has been heavily refined
since
On 07/11/2014 02:59 AM, Daniel Mack wrote:
On 07/11/2014 04:55 AM, Dave Gerlach wrote:
This series adds suspend/resume support for am335x. Version 3 of this
series can be found at [1]. I apologize for the large delay between this
and the previous revision. This code has been heavily refined
Andre,
On 07/11/2014 10:30 AM, Andre Heider wrote:
Hi Dave,
On Thu, Jul 10, 2014 at 09:55:38PM -0500, Dave Gerlach wrote:
Hello,
This series adds suspend/resume support for am335x. Version 3 of this
series can be found at [1]. I apologize for the large delay between this
and the previous
The mailbox DT node for AM4372 is enabled and is corrected to
remove some properties that have crept in by mistake.
Fixes: 9e3269b (ARM: dts: AM4372: Add L2, EDMA, mailbox, MMC and SHAM nodes)
Cc: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
The legacy platform device for mailbox should not be created for
a DT boot, so adjust the platform device initialization logic
appropriately.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/devices.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
OMAP2 devices are devicetree boot only, and the legacy mode
of mailbox device creation should no longer be used, so remove
the mailbox attribute data and the hwmod addr space used for
creating mailboxes in legacy mode.
Acked-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
The mailbox DT node data has been added for AM33xx device.
The mailbox IP in AM33xx is similar to the version found in
OMAP4+ devices.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git
The mailbox DT node data has been added for OMAP44xx
devices.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7e26d22..69408b5 100644
---
The legacy-style definition of the hwmod addr space is no longer
required as AM33xx/AM43xx are DT-boot only, and the minimal mailbox
DT nodes have been added, so clean up this data.
Acked-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
Hi Tony,
This is a refresh of the OMAP Mailbox DT node/hwmod cleanup series [1],
addressing the review comments [2] from Pavel Machek about the Mailbox IP
design parameters. The changes are limited to only the DTS patches, and
mainly bring back the DT properties that were dropped in the previous
The number of mailbox fifos and users (IP interrupts) are added
to the Mailbox DT nodes on OMAP2420, OMAP2430, OMAP3, and OMAP5
family of SoCs through the DT properties ti,mbox-num-fifos and
ti,mbox-num-users properties. This data represents the same data
that used to be represented in hwmod
Add the hwmod data for the 13 instances of the system mailbox
IP in DRA7 SoC. The patch is needed for performing a soft-reset
while configuring the respective mailbox instance, otherwise is
a non-essential change for functionality. The modules are smart
idled on reset, and the IP module mode is
DRA7xx has 13 system mailboxes, and is present on both the
DRA72x and DRA74x family of SoCs. Add the DT nodes for all
these 13 mailboxes. Except for mailbox 1, all other mailboxes
do not have interrupts mapped into the MPU GIC by default.
All the mailboxes have been disabled and the interrupts
The legacy-style definition of the hwmod addr space is no longer
required after the addition of the OMAP4 mailbox DT node, so
clean up this data.
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson bcous...@baylibre.com
Signed-off-by: Suman Anna s-a...@ti.com
---
Hi,
This is a refresh of the OMAP Mailbox framework adoption DT support
series [1], to work with the revised OMAP mailbox DT/hwmod cleanup
series [2].
The series has one less patch than the previous series, with the patch
mailbox/omap: add a custom of_xlate function squashed into the OMAP
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
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
The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+ and TI DSP/Bridge for OMAP3) are adapted to use
the generic mailbox framework.
The main changes for the adaptation are:
- The tasklet used for Tx is replaced with the state machine from
the generic mailbox framework.
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
---
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
On 11 July 2014 15:04, Suman Anna s-a...@ti.com wrote:
Hi,
This is a refresh of the OMAP Mailbox framework adoption DT support
series [1], to work with the revised OMAP mailbox DT/hwmod cleanup
series [2].
The series has one less patch than the previous series, with the patch
37 matches
Mail list logo
