Skip to content
GitLab
  1. Jul 05, 2012
  3. Jul 04, 2012
    • Paul Walmsley's avatar
      Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and... · 8cb8de5d
      Paul Walmsley authored 
      Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and 'misc_devel_3.6' into omap_devel_f_3.6
      8cb8de5d
    • Kishon Vijay Abraham I's avatar
      ARM: OMAP2+: hwmod code: add support to set dmadisable in hwmod framework · 6668546f
      Kishon Vijay Abraham I authored 
      

The DMADISABLE bit is a semi-automatic bit present in sysconfig register
of some modules. When the DMA must perform read/write accesses, the
DMADISABLE bit is cleared by the hardware. But when the DMA must stop for power
management, software must set the DMADISABLE bit back to 1.

In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the
DMADISABLE bit (but the romcode/bootloader might not set it back to 1).
In order for the kernel to start in a clean state, it is
necessary for the kernel to set DMADISABLE bit back to 1 (irrespective
of whether it's been set to 1 in romcode or bootloader).

During _reset of the (hwmod)device, the DMADISABLE bit is set so that it
does not prevent idling of the system. (NOTE: having DMADISABLE to 0,
prevents the system to idle)

DMADISABLE bit is present in usbotgss module of omap5.

Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
[paul@pwsan.com: updated to apply; fixed checkpatch warnings]
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      6668546f
    • R Sricharan's avatar
      ARM: OMAP2+: PRM/CM: Move the stubbed prm and cm functions to prcm.c file and make them __weak · 3f4990f4
      R Sricharan authored 
      

Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are added in the future. So move them
to a common place for OMAP2+ and make them 'weak' implementations.

This way no new ifdefs would be required in the future and also
cleans up the existing code.

Signed-off-by: default avatarR Sricharan <r.sricharan@ti.com>
[paul@pwsan.com: unsplit quoted strings; moved PRM functions to
 mach-omap2/prm_common.c; resolved sparse warnings]
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      3f4990f4
    • Tarun Kanti DebBarma's avatar
      ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API · bed9d1bb
      Tarun Kanti DebBarma authored 
      

Add an API to get main clock name associated with a given @oh.
This will avoid the need to construct fclk names during early
initialization in order to get fclk handle using clk_get().

Signed-off-by: default avatarTarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: default avatarBenoit Cousson <b-cousson@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      bed9d1bb
    • Vikram Pandita's avatar
      ARM: OMAP3+: dpll: optimize noncore dpll locking logic · 55ffe163
      Vikram Pandita authored 
      

If the dpll is already locked, code can be optimized
to return much earlier than doing redundent set of lock mode
and wait on idlest.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@ti.com>
Signed-off-by: default avatarVikram Pandita <vikram.pandita@ti.com>
Signed-off-by: default avatarNishanth Menon <nm@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      55ffe163
    • Sakari Ailus's avatar
      ARM: OMAP3: control: add definition for CONTROL_CAMERA_PHY_CTRL · f0d3d821
      Sakari Ailus authored 
      

The register is used to configure the behaviour of the CSI-2 and CCP-2
receivers. This register is available only in OMAP3630.

The original patch was submitted by Vimarsh Zutshi.

Signed-off-by: default avatarSakari Ailus <sakari.ailus@iki.fi>
Cc: Vimarsh Zutshi <vimarsh.zutshi@gmail.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      f0d3d821
    • Jon Hunter's avatar
      ARM: OMAP2+: powerdomain code: Fix Wake-up power domain power status · d49cae92
      Jon Hunter authored 
      The wake-up power domain is an alway-on power domain and so this power domain
does not have a power state status (PM_PWSTST_xxx) register that indicates the
current state. However, during the registering of the wake-up power domain the
state of the domain is queried by calling pwrdm_read_pwrst(). This actually
tries to read a register that does not exist and returns a value of 0 that
indicates that the current state is OFF. The OFF state count of the wake-up
power domain is then set to 1 and the current state to OFF. Both of which are
incorrect.

To fix this, if a power domain only supports the ON state, do not attempt to
read the power state status register and simply return ON as the current power
state.

This is based upon Tony's current linux-omap master branch.

Testing:
- Boot tested on OMAP4460 panda.
- Boot tested on OMAP3430 beagle and validated CORE RET still working (using
  Paul's 32k timer patch [1]).

[1] http://marc.info/?l=linux-omap&m=134000053229888&w=2



Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
Acked-by: default avatarKevin Hilman <khilman@ti.com>
Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: edited commit message slightly]
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      d49cae92
    • Jon Hunter's avatar
      ARM: OMAP4: clockdomain/CM code: Update supported transition modes · 65aa94b2
      Jon Hunter authored 
      

For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
following transition modes ...

NO_SLEEP (0x0) - A clock domain sleep transition is never initiated,
		 irrespective of the hardware conditions.
SW_SLEEP (0x1) - A software-forced sleep transition. The transition is initiated
		 when the associated hardware conditions are satisfied
SW_WKUP  (0x2) - A software-forced clock domain wake-up transition is initiated,
		 irrespective of the hardware conditions.
HW_AUTO  (0x3) - Hardware-controlled automatic sleep and wake-up transition is
		 initiated by the PRCM module when the associated hardware
		 conditions are satisfied.

For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is equivalent
to SW_WKUP. The only difference between HW_AUTO and SW_SLEEP for OMAP4 devices
is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt status is set in case of
SW_SLEEP transition, and not set in case of HW_AUTO transition.

For OMAP4 devices, all CLKDMs support HW_AUTO and therefore we can place the
CLKDMs in the HW_AUTO state instead of the SW_SLEEP mode. Hence, we do not
need to use the SW_SLEEP mode. With regard to NO_SLEEP and SW_WKUP it is
preferred to use SW_WKUP mode if the CLKDM supports it and so use this mode
instead of NO_SLEEP where possible.

For a software perspective the above 4 modes are represented by the following
flags to indicate what modes are supported by each of the CLKDMs.

CLKDM_CAN_DISABLE_AUTO	--> NO_SLEEP
CLKDM_CAN_ENABLE_AUTO	--> HW_AUTO
CLKDM_CAN_FORCE_SLEEP	--> SW_SLEEP
CLKDM_CAN_FORCE_WAKEUP	--> SW_WKUP

By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4 devices
can becomes ...

CLKDM_CAN_DISABLE_AUTO	--> NO_SLEEP
CLKDM_CAN_ENABLE_AUTO	--> HW_AUTO
CLKDM_CAN_FORCE_SLEEP	--> HW_AUTO
CLKDM_CAN_FORCE_WAKEUP	--> SW_WKUP

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Reviewed-by: default avatarBenoit Cousson <b-cousson@ti.com>
Reviewed-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      65aa94b2
    • Vaibhav Hiremath's avatar
      ARM: OMAP3/4: omap_hwmod: Add rstst_offs field to struct omap_hwmod_omap4_prcm · 768c69f5
      Vaibhav Hiremath authored 
      

In case of AM33XX device, XXX_RSTST register offset is not
consistent across PRM modules/instances,

PRM_XXX            RSTST
=========================
PRM_PER_MOD:       0x04
PRM_WKUP_MOD:      0x0C
PRM_MPU_MOD:       NA
PRM_DEVICE_MOD:    0x08

This means, we need to pass on XXX_RSTST register offset
information through omap_hwmod data, similar to XXX_RSTCTRL.

Currently, this field is only applicable and used for AM33XX
devices.

Signed-off-by: default avatarVaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      768c69f5
    • Vaibhav Hiremath's avatar
      ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx · 248b3b3d
      Vaibhav Hiremath authored 
      

In case of AM33xx family of devices (like cpsw) have different sysc
bit field offsets defined,

sysc_type3:
|  3     2  |  1    0  |
| STDBYMODE | IDLEMODE |

So introduce new sysc_type3 in omap_hwmod common data.

Signed-off-by: default avatarVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: default avatarVaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      248b3b3d
    • Tony Lindgren's avatar
      Merge tags 'omap-cleanup-for-v3.6', 'omap-devel-dmtimer-for-v3.6' and... · 3f96a2d9
      Tony Lindgren authored 
      Merge tags 'omap-cleanup-for-v3.6', 'omap-devel-dmtimer-for-v3.6' and 'omap-devel-am33xx-for-v3.6' into devel-am33xx-part2
      3f96a2d9
  5. Jul 01, 2012
  7. Jun 30, 2012
  9. Jun 29, 2012
    • Kay Sievers's avatar
      printk: flush continuation lines immediately to console · 084681d1
      Kay Sievers authored 
      

Continuation lines are buffered internally, intended to merge the
chunked printk()s into a single record, and to isolate potentially
racy continuation users from usual terminated line users.

This though, has the effect that partial lines are not printed to
the console in the moment they are emitted. In case the kernel
crashes in the meantime, the potentially interesting printed
information would never reach the consoles.

Here we share the continuation buffer with the console copy logic,
and partial lines are always immediately flushed to the available
consoles. They are still buffered internally to improve the
readability and integrity of the messages and minimize the amount
of needed record headers to store.

Signed-off-by: default avatarKay Sievers <kay@vrfy.org>
Tested-by: default avatarSteven Rostedt <rostedt@goodmis.org>
Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      084681d1
    • Michael Neuling's avatar
      powerpc/pseries: Fix software invalidate TCE · bc6dc752
      Michael Neuling authored 
      The following added support for powernv but broke pseries/BML:
 1f1616e8

 powerpc/powernv: Add TCE SW invalidation support

TCE_PCI_SW_INVAL was split into FREE and CREATE flags but the tests in
the pseries code were not updated to reflect this.

Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
cc: stable@kernel.org [v3.3+]
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      bc6dc752
    • Anton Blanchard's avatar
      powerpc: check_and_cede_processor() never cedes · 0b17ba72
      Anton Blanchard authored 
      Commit f948501b

 ("Make hard_irq_disable() actually hard-disable
interrupts") caused check_and_cede_processor to stop working.
->irq_happened will never be zero right after a hard_irq_disable
so the compiler removes the call to cede_processor completely.

The bug was introduced back in the lazy interrupt handling rework
of 3.4 but was hidden until recently because hard_irq_disable did
nothing.

This issue will eventually appear in 3.4 stable since the
hard_irq_disable fix is marked stable, so mark this one for stable
too.

Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0b17ba72
    • Steven Rostedt's avatar
      powerpc/ftrace: Do not trace restore_interrupts() · 2d773aa4
      Steven Rostedt authored 
      

As I was adding code that affects all archs, I started testing function
tracer against PPC64 and found that it currently locks up with 3.4
kernel. I figured it was due to tracing a function that shouldn't be, so
I went through the following process to bisect to find the culprit:

 cat /debug/tracing/available_filter_functions > t
 num=`wc -l t`
 sed -ne "1,${num}p" t > t1
 let num=num+1
 sed -ne "${num},$p" t > t2
 cat t1 > /debug/tracing/set_ftrace_filter
 echo function /debug/tracing/current_tracer
 <failed? bisect t1, if not bisect t2>

It finally came down to this function: restore_interrupts()

I'm not sure why this locks up the system. It just seems to prevent
scheduling from occurring. Interrupts seem to still work, as I can ping
the box. But all user processes freeze.

When restore_interrupts() is not traced, function tracing works fine.

Cc: stable@kernel.org
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2d773aa4
    • Li Zhong's avatar
      powerpc: Fix Section mismatch warnings in prom_init.c · 2cb387ae
      Li Zhong authored 
      

This patches tries to fix a couple of Section mismatch warnings like
following one:

WARNING: arch/powerpc/kernel/built-in.o(.text+0x2923c): Section mismatch
in reference from the function .prom_query_opal() to the
function .init.text:.call_prom()
The function .prom_query_opal() references
the function __init .call_prom().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .call_prom is wrong.

Signed-off-by: default avatarLi Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2cb387ae
    • Tiejun Chen's avatar
      ppc64: fix missing to check all bits of _TIF_USER_WORK_MASK in preempt · c58ce2b1
      Tiejun Chen authored 
      

In entry_64.S version of ret_from_except_lite, you'll notice that
in the !preempt case, after we've checked MSR_PR we test for any
TIF flag in _TIF_USER_WORK_MASK to decide whether to go to do_work
or not. However, in the preempt case, we do a convoluted trick to
test SIGPENDING only if PR was set and always test NEED_RESCHED ...
but we forget to test any other bit of _TIF_USER_WORK_MASK !!! So
that means that with preempt, we completely fail to test for things
like single step, syscall tracing, etc...

This should be fixed as the following path:

 - Test PR. If not set, go to resume_kernel, else continue.

 - If go resume_kernel, to do that original do_work.

 - If else, then always test for _TIF_USER_WORK_MASK to decide to do
that original user_work, else restore directly.

Signed-off-by: default avatarTiejun Chen <tiejun.chen@windriver.com>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c58ce2b1