Needed by hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/prm3xxx.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prm3xxx.c b/arch/arm/mach-omap2/prm3xxx.c
index 5713bbd..4f16257 100644
---
Needed by hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 58920bc..4891559 100644
--- a/arch/arm/mach-omap2/pm.c
+++
Needed by hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 88721df..de614e7 100644
---
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.h |8
arch/arm/mach-omap2/pdata-quirks.c | 11 +++
2 files changed, 19 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 3ff9133..0c7eaf8
New Kconfig option added, OMAP_HWMOD_DATA_MODULES, which builds hwmod
data as modules if enabled. By default, the data is built-in to kernel
image for ease of use. Makefile is also changed to support building of
the new hwmod data modules.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
If hwmod data is built as a module, PM init will be done after the module
has been loaded. PM code has dependencies towards certain hwmods, which
are not going to be available during early init.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/io.c |2 ++
1 file changed, 2
When hwmod data is built into modules, a slightly different init is
required at the board level. Add this new init support function, and
change the boards that support hwmod data module in subsequent patches.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-generic.c |
Needed by hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/control.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index da041b4..b0d5e47 100644
---
This is a hack in a sense that this is a temporary trial patch to verify
the module functionality for omap3. The external dependencies should
be removed all at once for all platforms when the support is added for all.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
This splits up the platform bus registration to early boot and module
time probe versions, which register different portions of the bus based
on hwmod data availability. The common version is retained still for
supporting the different SoCs during transition time.
Signed-off-by: Tero Kristo
Needed by hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |2 +-
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
arch/arm/mach-omap2/pm.h |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git
With the introduction of the hwmod data modules, the DMA init also needs
to happen later in boot. Thus, remove it from the __init section, and
also make the API publicly available.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/common.h |2 ++
arch/arm/mach-omap2/dma.c
ocp bus node will be needed for hwmod data module init, so it can't be
reserved by l3-smx driver. Thus, split l3-smx as its own separate node
under the ocp bus, and add a new compatible string for the l3-bus.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 12
If hwmod data is built as a module, PM init will be done after the module
has been loaded. PM code has dependencies towards certain hwmods, which
are not going to be available during early init.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/io.c |2 ++
1 file changed, 2
Needed by hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/common.h |4 ++--
arch/arm/mach-omap2/devices.c |4 ++--
arch/arm/mach-omap2/display.c |8
arch/arm/mach-omap2/display.h |2 +-
arch/arm/mach-omap2/drm.c |4 ++--
Needed by hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/sr_device.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index d7cff26..c453fe4 100644
---
Some devices are built late in boot with the introduction of hwmod
data modules, and the omap_device_build() function is required later
in boot also. Thus, remove it from the __init section.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_device.c | 18
This data will be registered during early boot, rest of the hwmod
data will be provided through a module during probe time.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.h |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_early_data.c | 549
While executing clk_disable_unused during boot, the dflt clk operations
to disable the clocks include usecounting mechanism for clockdomains,
which is indexed badly in case a direct clock disable call is made. This
can potentially cause the underlying clockdomain to be disabled in
certain cases.
If a hwmod with same name is already registered, reroute the links to
use the existing one rather than fail. This is needed when hwmod data
is made into a separate module, and for example, l3 bus is already
registered under different hwmod. The late module init will use
an l3 dummy hwmod instead,
Needed by hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/voltage.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index cba8cad..84512e9 100644
---
With hwmod init being split into an early and a late module init parts,
certain hwmod APIs can't reside under __init section anymore. Thus,
remove the __init declaration from the required APIs to make them
accessible at the module probe phase also.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
Previously this function was incorrectly implemented under low level
IO init. However, this API will be needed for late hwmod data module
init also, so move it to the generic hwmod codebase, and export the
function also for module use.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
Hi,
This RFC provides support for moving hwmod data into separate modules
which can be registered later during boot. Only system critical parts
of the hwmod data remain in omap_hwmod_*_early_data.c file, rest are
moved into omap_hwmod_*_late_data.c. The late data can alternatively
be built into a
Parts of the n8x0 board support code is needed during pdata registration,
which will be moved later in the boot. Thus, it can't reside under __initdata
section anymore and must be moved out of it.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-n8x0.c |8
1
These need to move later in the boot with hwmod data being moved into a
module, thus remove the __init declarations to make them accessible at
module probe phase also.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c | 58 ++--
1
Needed by hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index be9ef83..c67bdc5 100644
--- a/arch/arm/mach-omap2/vc.c
This makes it possible to do the iomapping before driver probe. Driver
probe requires access to the DMA IO mapping already, so if it is
allocated after omap_device_build, it is too late and causes a crash.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/dma.c | 25
Needed for hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index a3c3065..f757e94 100644
--- a/arch/arm/mach-omap2/vp.c
+++
hwmod currently uses memblock alloc, which only works very early in boot.
Change this by adding a runtime setup support for specifying memory alloc
functionality, this will allow hwmod init to be executed also later during
boot, when memblock allocation is no longer available.
Signed-off-by: Tero
With most of the OMAP hwmod data being moved to a module, this API
needs to be accessed later in the boot and can't reside under
__init section anymore.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/net/wireless/ti/wilink_platform_data.c |2 +-
1 file changed, 1 insertion(+), 1
Needed by hwmod module boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c |4 ++--
arch/arm/mach-omap2/twl-common.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
Certain gate clocks require this for the init time clk_disable_unused
functionality to work properly, thus add support for it. If the gate
clock does not provide disable_unused ops, just call gate_ops-disable,
just like the core clock code would do.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
Some custom platform bus registration code needs access to couple of
of/platform APIs, thus make these available outside of/platform.
The APIs exported in this patch are required by OMAP hwmod data module
support, which basically splits the platform bus registration to be done
in two phases; an
These are required for providing hwmod data in late boot through a module.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 14 ++
arch/arm/mach-omap2/omap_hwmod.h |5 -
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git
On 15/04/15 12:29, Paul Bolle wrote:
(This will go into a minor detail. That's probably not what you want
when posting an RFC. But this patch got caught by an email filter I use
and a future, non-RFC, version will get caught too. So I decided to
bother you with this now.)
On Tue, 2015-04-14
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the
On 04/02/15 01:20, Russell King - ARM Linux wrote:
This is where the DRM model is weak - we don't really have a way to
say this is the set of CRTCs which/can/ be associated with this
connector, can any of the CRTCs accept this mode? and eliminate
modes which fail that check.
This problem seems
Hi,
On Thu, Apr 09, 2015 at 02:48:43PM +0100, Russell King - ARM Linux wrote:
On Thu, Apr 09, 2015 at 12:06:58AM +0100, Russell King - ARM Linux wrote:
On Tue, Apr 07, 2015 at 08:22:08AM -0700, Tony Lindgren wrote:
Works for me. The above needs the following fix folded in to build:
On 04/14/2015 08:29 PM, Lennart Sorensen wrote:
On Tue, Mar 17, 2015 at 06:41:51PM -0700, Tony Lindgren wrote:
Yeah agreed. I suggest discussing the binding and the generic
parsing code for it first :)
It seems with the generic binding the actual driver should be
just the hardware specific
On Wed, Apr 15, 2015 at 11:51:32AM -0500, Nishanth Menon wrote:
I am yet to post a new revision to this series - few other stuff got
in the way. IODelay driver in no way removes the constraint that the
SoC architecture has - most of the pins still need to be muxed in
bootloader - we cannot
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external
On 04/15/2015 01:44 PM, Lennart Sorensen wrote:
On Wed, Apr 15, 2015 at 11:51:32AM -0500, Nishanth Menon wrote:
I am yet to post a new revision to this series - few other stuff got
in the way. IODelay driver in no way removes the constraint that the
SoC architecture has - most of the pins
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300,
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external
On 04/15/2015 11:51 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is
Without this system suspend is broken on systems that have
drivers calling enable/disable_irq_wake() for interrupts based off
the dummy irq hook.
(e.g. drivers/gpio/gpio-pcf857x.c)
http://article.gmane.org/gmane.linux.kernel/1879035
Signed-off-by: Roger Quadros rog...@ti.com
---
On 04/10/2015 10:40 AM, Maxime Ripard wrote:
On Thu, Apr 09, 2015 at 11:24:58AM +0300, Peter Ujfalusi wrote:
On 04/08/2015 06:42 PM, Maxime Ripard wrote:
---
Documentation/devicetree/bindings/dma/dma.txt | 28 +
drivers/dma/dmaengine.c | 7 +++
Hi Roger,
On 15/04/2015 10:07, Roger Quadros wrote:
Hi Gregory,
On 14/04/15 17:02, Gregory CLEMENT wrote:
Hi Roger,
On 14/04/2015 12:13, Roger Quadros wrote:
Hi Thomas,
On 30/03/15 16:15, Roger Quadros wrote:
Without this system suspend is broken on systems that have
drivers calling
(This will go into a minor detail. That's probably not what you want
when posting an RFC. But this patch got caught by an email filter I use
and a future, non-RFC, version will get caught too. So I decided to
bother you with this now.)
On Tue, 2015-04-14 at 13:41 +0300, Roger Quadros wrote:
---
On 15/04/2015 10:14, Roger Quadros wrote:
Without this system suspend is broken on systems that have
drivers calling enable/disable_irq_wake() for interrupts based off
the dummy irq hook.
(e.g. drivers/gpio/gpio-pcf857x.c)
http://article.gmane.org/gmane.linux.kernel/1879035
Hi Gregory,
On 14/04/15 17:02, Gregory CLEMENT wrote:
Hi Roger,
On 14/04/2015 12:13, Roger Quadros wrote:
Hi Thomas,
On 30/03/15 16:15, Roger Quadros wrote:
Without this system suspend is broken on systems that have
drivers calling enable/disable_irq_wake() for interrupts based off
the
54 matches
Mail list logo
