Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 71ac7d5..f2848a8 100644
---
This is needed for NAND and OneNAND to work.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/configs/omap2plus_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index a4e8d01..98dad6c 100644
---
Don't access any GPMC registers here. Use gpmc_generic_init()
to pass GPMC Chip Select settings, platform device and platform data
to the GPMC driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-flash.c | 28 +++-
1 file changed, 11
Most of the GPMC functions are now not used by other drivers.
Make them private.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 84 ++
arch/arm/mach-omap2/gpmc.h | 63 --
2 files changed, 56
This function should only be called by board init code for
legacy boot.
Re-arrange init order so that gpmc device is created after
the gpmc platform data is initialized by board files.
i.e. move omap_gpmc_init() to subsys_initcall.
Load gpmc platform driver later in the boot process.
i.e. move
Some devices (e.g. tusb6010) need 2 chip selects to work with
2 separate IOMEM resources. Allow such use case. The user just
needs to call gpmc_generic_init() for as many chip selects
with the same platform_device pointer. The GPMC driver will
take care of fixing up the memory resources.
The retime() function is not provided by board files so get rid of
it from omap_smc91x_platform_data().
Instead change it to smc91c96_get_device_timing() to get the device
timings.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 8 --
Provide NAND specific resources and platform data.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index
Use devres managed resources for Memory, GPIO and Interrupt
resources.
0 is a valid gpio, so use gpio_is_valid() to check for
valid gpio number.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/onenand/omap2.c | 92 -
1 file changed, 33
Add compatible id, fix chip select partition size and
I/O space size. OneNAND devices just need 128KB for I/O
and the minimum possible chips select partition can be
16MB.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 5 +++--
Move OneNAND specific device tree parsing to NAND driver.
The OneNAND device node must have its own compatible id.
Add a new property 'ti,onenand-sync-rw' to indicate
synchronous read + write support. Default mode would be
only synchronous reads.
Signed-off-by: Roger Quadros rog...@ti.com
---
Add gpmc_probe_legacy() that will be called for non DT boots. This function
will use platform data to setup each chip select and populate the child
platform device for each of the chip selects.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 129
This function populates platform data for the specified Chip Select.
It should be called by board init code.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 79 ++
arch/arm/mach-omap2/gpmc.h | 6
2 files changed, 85
Don't access any GPMC registers here. Use gpmc_generic_init()
to pass GPMC Chip Select settings, platform device and platform data
to the GPMC driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 53 --
1 file changed, 11
Move the code that puts the onenand in synchronous mode
into the appropriate place i.e. drivers/mtd/onenand/omap2.c.
Make use of omap_gpmc_get_clk_period() and omap_gpmc_retime()
to calculate the necessary timings and configure the GPMC
parent's timings.
Signed-off-by: Roger Quadros
Don't access any GPMC registers here. Use gpmc_generic_init()
to pass GPMC Chip Select settings, platform device and platform data
to the GPMC driver.
Some boards use multiple smsc911x devices, so we dynamically
allocate pdev and pdata.
Signed-off-by: Roger Quadros rog...@ti.com
---
Don't access any GPMC registers here. Use gpmc_generic_init()
to pass GPMC Chip Select settings, platform device and platform data
to the GPMC driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc-smc91x.c | 50 +++
1 file changed, 19
Onenand device operates in Asynchronous mode by default. So
configure GPMC settings/timings based on Async mode before the onenand
device is created.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 66 ++
1 file changed, 32
In order to change the GPMC settings/timings on the fly,
we must use omap_gpmc_retime(). The other gpmc_*() functions
will soon be made private and moved out of arch/mach-omap2/
CC: Felipe Balbi ba...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c | 94
Don't access any GPMC registers here. Use gpmc_generic_init()
to pass GPMC Chip Select settings, platform device and platform data
to the GPMC driver.
CC: Felipe Balbi ba...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c | 78
Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC
timings in order to operate with different peripheral clock frequencies.
Introduce omap_gpmc_retime() to allow them to do that. The driver
needs to pass the chips select number, GPMC settings and Device timings to
None of the OMAP platforms are suppying the regulator_can_sleep
parameter via platform data. Regulator management is generic
enough to be done in onenand_base driver if required.
Mark the regulator_can_sleep platform data parameter as deprecated.
Signed-off-by: Roger Quadros rog...@ti.com
---
GPMC_CLK is the external clock output pin that is used for syncronous
accesses.
Device drivers need to know the fastest possible GPMC_CLK period in order
to calculate the most optimal device timings. Add the function
omap_gpmc_get_clk_period() to allow drivers to get the nearset possible
(equal
Add compatible id, interrupts and update reg property description.
As the NAND controller needs access to GPMC register space, we need
to pass a second memory resource to the NAND controller node.
Due to the wierd way the reg property has been implemented (i.e.
CS number required in 1st number of
The beagle board contains a 16-bit NAND device connected to
chip select 0 of the GPMC controller.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 53 ++
1 file changed, 53 insertions(+)
diff --git
Make sure bank-width property provided via DT is sane.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index c713616..70cb6b0
The write protect (WP) pin is only used for NAND devices. So move
the code into the NAND driver.
Get rid of gpmc_configure() as it is no longer used.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 4
arch/arm/mach-omap2/gpmc.c
Move NAND specific device tree parsing to NAND driver.
The NAND controller node must have a compatible id, register space
resource and interrupt resource.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 5 +-
arch/arm/mach-omap2/gpmc.c
Add compatible id, GPMC register resource and interrupt
resource to NAND controller nodes.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 8 ++--
arch/arm/boot/dts/am335x-igep0033.dtsi | 8 ++--
arch/arm/boot/dts/am43x-epos-evm.dts | 8
Add device_timings, gpmc_timings and gpmc_setting to
gpmc platform data.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.h | 134 --
include/linux/platform_data/gpmc-omap.h | 139
2 files changed,
Add a platform data structure for GPMC. It contains all the necessary
platform information that needs to be passed from platform init code
to GPMC driver.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.h | 4 +---
include/linux/platform_data/gpmc-omap.h |
Copy all the platform data parameters to the driver's local data
structure 'omap_nand_info' and use it in the entire driver. This will
make it easer for device tree migration.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 27 ++-
1 file
GPMC and NAND drivers share the same register space but never use the
same registers. As there is no clear address seperation between the
registers for GPMC and NAND, we can't easily split it up into 2 regions
i.e. one for GPMC and other for NAND. Instead, we simply remap the entire
register space
Since the Interrupt Events are used only by the NAND driver,
there is no point in managing the Interrupt registers
in the GPMC driver and complicating it with irqchip modeling.
Let's manage the interrupt registers directly in the NAND driver
and get rid of irqchip model from GPMC driver.
Get rid
Use actual register space size from Reference Manual.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 2 +-
arch/arm/boot/dts/am4372.dtsi | 2 +-
arch/arm/boot/dts/omap2420.dtsi | 2 +-
arch/arm/boot/dts/omap2430.dtsi | 2 +-
arch/arm/boot/dts/omap3.dtsi| 2
Hi,
This is a complete functional set to get the gpmc driver out of mach-omap2
and into drivers/memory. The DT binding remains the same except for the
following minor changes
- compatible property is required for NAND OneNAND nodes
- Second register space and interrupts properties are required
Resending with rename detection option to git-format-patch
for easier review.
From: Roger Quadros rog...@ti.com
Move the GPMC driver out of mach-omap2. We leave behind only
the mach-omap2 specific bits in mach-omap2/gpmc_legacy.c
i.e. gpmc_generic_init() for use by board files to register
the
Hi Javier,
On 06/11/2014 02:52 PM, Javier Martinez Canillas wrote:
Hello Roger,
What a great series!!
Thanks :)
On Wed, Jun 11, 2014 at 10:56 AM, Roger Quadros rog...@ti.com wrote:
Hi,
This is a complete functional set to get the gpmc driver out of mach-omap2
and into drivers/memory.
Hello Roger,
What a great series!!
On Wed, Jun 11, 2014 at 10:56 AM, Roger Quadros rog...@ti.com wrote:
Hi,
This is a complete functional set to get the gpmc driver out of mach-omap2
and into drivers/memory. The DT binding remains the same except for the
following minor changes
I probably
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly
* Arnd Bergmann a...@arndb.de [140611 07:37]:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
That's good news, but let's not fix it this way.
This can be solved by turning
On Wednesday 11 June 2014 09:42:04 Nishanth Menon wrote:
On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be
On 06/11/2014 09:49 AM, Arnd Bergmann wrote:
On Wednesday 11 June 2014 09:42:04 Nishanth Menon wrote:
On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera
On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately
* Arnd Bergmann a...@arndb.de [140611 07:51]:
On Wednesday 11 June 2014 09:42:04 Nishanth Menon wrote:
On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the
This series intends to add support for L2 cache on Exynos4 SoCs on boards
running under secure firmware, which requires certain initialization steps
to be done with help of firmware, as selected registers are writable only
from secure mode.
First three patches extend existing support for secure
For certain platforms (e.g. Exynos) it is necessary to read back some
values from registers before they can be written (i.e. SMC calls that
set multiple registers per call), so base address of L2C controller is
needed for .write_sec operation. This patch adds base argument to
.write_sec callback
This patch adds device tree nodes for L2 cache controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 9 +
2 files changed, 18 insertions(+)
diff --git
On 06/10/2014 05:48 PM, Brian Norris wrote:
On Wed, Jun 11, 2014 at 01:34:39AM +0200, Thomas Gleixner wrote:
On Tue, 10 Jun 2014, Brian Norris wrote:
Other random thought: it seems like any irqchip driver which does lazy IRQ
masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the IRQ core
According to the documentation, TAG_LATENCY_CTRL and DATA_LATENCY_CTRL
registers of L2C-310 can be written only in secure mode, so
l2c_write_sec() should be used to change them, instead of plain
writel_relaxed().
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mm/cache-l2x0.c | 8
Certain platforms (i.e. Exynos) might need to set .write_sec callback
from firmware initialization which is happenning in .init_early callback
of machine descriptor. However current code will overwrite the pointer
with whatever is present in machine descriptor, even though it can be
already set
Exynos4 SoCs equipped with an L2C-310 cache controller and running under
secure firmware require certain registers of aforementioned IP to be
accessed only from secure mode. This means that SMC calls are required
for certain register writes. To handle this, an implementation of
.write_sec callback
diff --git a/arch/arm/include/asm/mach/arch.h
b/arch/arm/include/asm/mach/arch.h
index 060a75e..ddaebcd 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -46,7 +46,8 @@ struct machine_desc {
enum reboot_modereboot_mode;/* default
On 11.06.2014 18:00, Jon Loeliger wrote:
diff --git a/arch/arm/include/asm/mach/arch.h
b/arch/arm/include/asm/mach/arch.h
index 060a75e..ddaebcd 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -46,7 +46,8 @@ struct machine_desc {
enum
Since AI lines could be selected at will (linux-3.11) the sending
and receiving ends of the FIFO does not agree about what step is used
for a line. It only works if the last lines are used, like 5,6,7,
and fails if ie 2,4,6 is selected in DT.
Signed-off-by: Jan Kardell jan.kard...@telliq.com
---
* Lee Jones lee.jo...@linaro.org [140603 01:08]:
On Mon, 02 Jun 2014, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [140528 11:11]:
* Lee Jones lee.jo...@linaro.org [140528 00:14]:
Thanks Tony, here's the pull-request:
The following changes since commit
56 matches
Mail list logo
