*changes v9 - v10*
[PATCH 1/10], [PATCH 2/10]
swapped [PATCH v9 1/9] and [PATCH v9 2/9] so that DT parsing updates
(with backward compatibility) happen before the deprecation of DT values.
This way DTB does not break functionally between the patches.
[PATCH 3/10] no update
[PATCH 4/10]
OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
ecc-scheme, like:
- OMAP_ECC_HAMMING_CODE_DEFAULT
1-bit hamming ecc code using software library
- OMAP_ECC_HAMMING_CODE_HW
1-bit hamming ecc-code using GPMC h/w engine
- OMAP_ECC_HAMMING_CODE_HW_ROMCODE
current implementation in omap3_init_bch() has some redundant code like:
(1) omap3_init_bch() re-probes the DT-binding to detect presence of ELM h/w
engine on SoC. And based on that it selects implemetation of ecc-scheme.
However, this is already done as part of GPMC DT parsing.
(2) As
With OMAP NAND driver updates, selection of ecc-scheme:
*DT enabled kernel*
depends on ti,nand-ecc-opt and ti,elm-id DT bindings.
*Non DT enabled kernel*
depends on elm_dev and ecc-scheme passed along with platform-data
from board file.
So, selection of ecc-scheme (BCH8 or
As per comments below, NAND_CMD_RESET, NAND_CMD_READID, and NAND_CMD_PARAM would
work only in x8 mode.
commit 64b37b2a63eb2f80b65c7185f0013f8ffc637ae3
Author: Matthieu CASTET matthieu.cas...@parrot.com
AuthorDate: 2012-11-06
Note that nand_scan_ident send command
OMAP NAND driver support multiple ECC scheme, which can used in different
flavours, depending on in-build Hardware engines present on SoC.
This patch updates following in DT bindings related to sectionion of ecc-schemes
- ti,elm-id: replaces elm_id (maintains backward compatibility)
-
Managed Device Resource or devm_xx calls takes care of automatic freeing
of the resource in case of:
- failure during driver probe
- failure during resource allocation
- detaching or unloading of driver module (rmmod)
Reference: Documentation/driver-model/devres.txt
Though OMAP NAND driver
generic frame-work in mtd/nand/nand_bch.c is a wrapper above lib/bch.h which
encapsulates all control information specific to BCH ecc algorithm in software.
Thus this patch:
(1) replace omap specific implementations with equivalent wrapper in nand_bch.c
so that generic code from nand_bch.c is
This patch updates following in omap_nand_probe() and omap_nand_remove()
- replaces info-nand with nand_chip (struct nand_chip *nand_chip)
- replaces info-mtd with mtd (struct mtd_info *mtd)
- white-space and formatting cleanup
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap2.c
In current implementation omap3_init_bch_tail() is a common function to
define ecc layout for different BCHx ecc schemes.This patch:
(1) removes omap3_init_bch_tail() and defines ecc layout for individual
ecc-schemes along with populating their nand_chip-ecc data in
omap_nand_probe(). This
Updated DTS to replace deprecated binding with newer values
Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Signed-off-by: Pekon Gupta pe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 3 +--
arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
2 files
Hi Brian,
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Thu, Oct 17, 2013 at 09:00:27PM +, Pekon Gupta wrote:
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Thu, Oct 17, 2013 at 04:42:23AM +, Pekon Gupta wrote:
[...]
But the real point: you need to
On Wed, 2013-08-21 at 00:58 -0700, Tony Lindgren wrote:
* Zubair Lutfullah zubair.lutful...@gmail.com [130715 08:33]:
Did a grep for coordiante and replaced them all
with coordinate.
This applies to the mfd-next tree.
This should be safe to apply via the MFD tree as a non-critical
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af:
Linux 3.12-rc4 (2013-10-06 14:00:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
On Fri, 11 Oct 2013, Tero Kristo wrote:
Users of the CM funtionality should not access the CM registers directly
by themselves. Thus, added new CM driver APIs for the OMAP2 specific
functionalities which support the existing direct register accesses, and
changed the platform code to use
On Fri, 11 Oct 2013, Tero Kristo wrote:
McBSP driver require special hacks to enable/disable the autoidle feature
for its interface clock for the proper function of the sidetone hardware.
Currently the driver just writes CM registers directly, which should be
avoided. Thus, changed the driver
On Fri, 11 Oct 2013, Tero Kristo wrote:
Some drivers require direct access to the autoidle functionality of the
interface clocks. Added clock APIs for these, so that the drivers do not
need to access CM registers directly.
Signed-off-by: Tero Kristo t-kri...@ti.com
Thanks, queued. Please
On Fri, 11 Oct 2013, Tero Kristo wrote:
OMAP3 PM code for off-mode currently saves the scratchpad contents for CM
registers within OMAP control module driver. However, as we are separating
CM code into its own driver, this must be moved also. This patch adds a
new API for saving the CM
On Fri, 11 Oct 2013, Tero Kristo wrote:
OMAP3 PM core requires IVA2 bootmode to be set to idle during init. Currently,
a direct register write is used for this. Add a new ctrl API for this purpose
instead.
Signed-off-by: Tero Kristo t-kri...@ti.com
Thanks, queued.
- Paul
--
To
On Fri, 11 Oct 2013, Tero Kristo wrote:
OMAP3 PM code directly writes to CM register space to enable/disable IVA2
clock during boot during the IVA2 reset. Direct access shall be avoided,
thus implement an API call for this, and change the PM core to use this.
Signed-off-by: Tero Kristo
On Fri, 11 Oct 2013, Tero Kristo wrote:
OMAP3 PM code directly writes to CM register space to enable/disable IVA2
clock during boot during the IVA2 reset. Direct access shall be avoided,
thus implement an API call for this, and change the PM core to use this.
Signed-off-by: Tero Kristo
On Fri, 11 Oct 2013, Tero Kristo wrote:
This is correct location for this instead of the PM core, as it is accessing
PRM registers directly.
Signed-off-by: Tero Kristo t-kri...@ti.com
This is custom reset code for the IVA2, not specifically PRM code, so it
should go into a separate
On Fri, 11 Oct 2013, Tero Kristo wrote:
The direct register access macros should not be exposed to CM clients.
Thus, move the register macros to their own file and only include these
to the cm_*.c files.
Signed-off-by: Tero Kristo t-kri...@ti.com
The basic idea here looks great, obviously
On Fri, 11 Oct 2013, Tero Kristo wrote:
PRCM chain handler needs these to properly acknowledge wakeup events.
Currently this functionality is implemented as direct register accesses,
but as the CM code should eventually move to its own driver, separate
API calls are now added for this
On Fri, 11 Oct 2013, Tero Kristo wrote:
OMAP3 PM code needs this functionality during the IVA2 reset, but is currently
using direct CM register accesses for this purpose. Implement a new API so
the PM code can use this instead.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
On Sat, 19 Oct 2013, Paul Walmsley wrote:
On Fri, 11 Oct 2013, Tero Kristo wrote:
OMAP3 PM code directly writes to CM register space to enable/disable IVA2
clock during boot during the IVA2 reset. Direct access shall be avoided,
thus implement an API call for this, and change the PM core
On Fri, 18 Oct 2013, Mugunthan V N wrote:
Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Has a DRA7xx public TRM been published yet?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
Most of the boards are using the TI AM/DM37x processor, there is only a small
quantity of IGEP Processor Boards based on TI OMAP3530. So it's better use the
omap36xx.dtsi include instead of omap34xx.dtsi include.
To avoid confusion we have added to the model the (TI AM/DM37x) comment.
Both, IGEPv2 and IGEP COM MODULE have a bus-width of 4 not 8, so fix this and
do not mux data pins from mmc1_data5 to mmc1_data7.
Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
Hi Benoit,
This series are some updates for IGEP boards that would be great if can make
it for v3.13 (not sure if merge window is already closed as I saw your last
pull request).
The first patch is fix for mmc1 that should be configured for 4 bits not 8,
the second patch add support for the WiFi
The LBEE1USJYC is a WiFi/BT combo module used on OMAP3-based IGEP boards. In
both cases, IGEPv2 Rev. C and IGEP COM MODULE, the module is connected using
the same MMC interface and uses the same GPIOs.
Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
Add mmc1 dt node to IGEP COM AQUILA board.
Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
Hi Enric,
On Sat, Oct 19, 2013 at 9:54 PM, Enric Balletbo i Serra
eballe...@gmail.com wrote:
Both, IGEPv2 and IGEP COM MODULE have a bus-width of 4 not 8, so fix this and
do not mux data pins from mmc1_data5 to mmc1_data7.
I guess you meant pins from mmc1_data4 instead mmc1_data5? (i.e: only
Hi Enric,
On Sat, Oct 19, 2013 at 9:54 PM, Enric Balletbo i Serra
eballe...@gmail.com wrote:
The LBEE1USJYC is a WiFi/BT combo module used on OMAP3-based IGEP boards. In
both cases, IGEPv2 Rev. C and IGEP COM MODULE, the module is connected using
the same MMC interface and uses the same GPIOs.
[cc'ing current Benoit's address instead of the old one]
On Sat, Oct 19, 2013 at 9:54 PM, Enric Balletbo i Serra
eballe...@gmail.com wrote:
Hi Benoit,
This series are some updates for IGEP boards that would be great if can make
it for v3.13 (not sure if merge window is already closed as I saw
35 matches
Mail list logo
