Tony Lindgren [Fri, 20 Apr 2012 00:45:33 +0000 (17:45 -0700)]
Merge tag 'omap-devel-a-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into devel-hwmod
Add in most of the remaining hwmods (IP block descriptions) for the
OMAP44xx family of SoCs. There still seem to be a few missing, such
as those for the MMU IP blocks, but this seems to cover the bulk of
the remainder.
Tony Lindgren [Fri, 20 Apr 2012 00:43:42 +0000 (17:43 -0700)]
Merge tag 'omap-cleanup-b-for-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-hwmod
Clean up various aspects of the OMAP hwmod code, which is the IP block
control code for OMAP SoCs. In particular, this series results in
a considerable diffstat savings by changing the way that IP block
interconnections are defined.
Add a skeleton hwmod for the DEBUGSS and associated interconnect data.
This is a basic set of data that will need further additions as
further DEBUGSS information becomes available.
Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Add the OCP-WP hwmod and associated interconnect data. The OCP-WP,
or OCP watchpoint, can be used to collect interconnect data and
transmit it via the STM port.
Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP4: hwmod data: add remaining USB-related IP blocks
Add the OCP2SCP IP block and interconnect data. The OCP2SCP can be
used in conjunction with the on-chip embedded USB PHY, associated with
the OTG controller.
Add the on-chip full-speed USB host controller IP block and
interconnect data.
Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Paul Walmsley [Thu, 19 Apr 2012 19:33:54 +0000 (13:33 -0600)]
ARM: OMAP4: hwmod data: add some interconnect-related IP blocks
Add the SL2 interface IP block and interconnect data. The SL2 is related
to the IVA-HD subsystem.
Add IP block and interconnect data for the C2C ("Chip-to-chip")
interconnect. This can provide a direct system interconnect link to
other devices stacked on the OMAP package.
Add the ELM IP block and interconnect data. The ELM can be used
to locate errors in NAND flash connected to the GPMC.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com> Acked-by: Benoît Cousson <b-cousson@ti.com> Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
[paul@pwsan.com: rearranged to match script output; fixed FDIF end address to
match script data; wrote trivial changelog; combined the FDIF portion of
Fernando's srst_udelay patch] Signed-off-by: Paul Walmsley <paul@pwsan.com>
Paul Walmsley [Thu, 19 Apr 2012 19:33:49 +0000 (13:33 -0600)]
ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
The PRM and CM implicit clockdomains will soon be used by OMAP44xx.
So, make them common to OMAP2+ and modify the OMAP4 clockdomains code
so use of these clockdomains doesn't crash the system.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:04:38 +0000 (04:04 -0600)]
ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP
N800 logs this message on boot:
[ 0.182281] omap_hwmod: iva: cannot be enabled for reset (3)
Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2
hwmod for OMAP2430. There is still more information to be added, but
this should resolve the immediate issue.
Paul Walmsley [Thu, 19 Apr 2012 10:04:35 +0000 (04:04 -0600)]
ARM: OMAP3: hwmod data: fix IVA interface clock
The OMAP3 hwmod data listed iva2_ck as an interface clock between the
IVA and L3. This is incorrect. iva2_ck is not an interface clock.
Since it cannot auto-idle, specifying it here prevents the IVA and at
least one of the CORE clockdomains from going idle, which causes PM
problems such as these upon system suspend:
[ 70.626129] Powerdomain (iva2_pwrdm) didn't enter target state 1
[ 70.626190] Powerdomain (core_pwrdm) didn't enter target state 1
Fix by specifying the actual interface clock in the hwmod data.
Paul Walmsley [Thu, 19 Apr 2012 10:04:34 +0000 (04:04 -0600)]
ARM: OMAP2xxx: hwmod data: share common interface data
Several struct omap_hwmod_ocp_if records can be shared between OMAP2420
and OMAP2430. Move these shared records out of the chip-specific files
into mach-omap2/omap_hwmod_2xxx_interconnect_data.c. This should save some
memory and source lines, at the cost of readability.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:04:33 +0000 (04:04 -0600)]
ARM: OMAP2xxx: hwmod data: share common hwmods between OMAP2420 and OMAP2430
After the link registration conversion, it's much easier to share some
hwmod data between OMAP2420 and 2430. Move the shareable data into a
common file. This should save some memory and lines of source, at the
cost of readability.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Reorganize the hwmod data to declare the IP blocks first and the
interconnects second. This allows us to remove the forward
declarations, which this patch also does. Saves some lines of source
data. While here, take the opportunity to synchronize the order of
the OMAP44xx hwmod data with the autogenerator output -- it's slightly
different due to past mismerges -- and fix a few minor typos and
whitespace problems in the files.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:04:31 +0000 (04:04 -0600)]
ARM: OMAP2+: hwmod data: convert to link registration
Register interconnect links between IP blocks, rather than the IP
blocks themselves. (The IP blocks will be registered as a side-effect
of registering the links.)
The objective is to reduce the number of lines of static data and
facilitate the sharing of IP block data between different SoCs. These
objectives come at the penalty of increased boot time due to increased
computation.
While here, fix a few whitespace problems and inaccurate variable names.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:04:30 +0000 (04:04 -0600)]
ARM: OMAP2+: hwmod: add support for link registration
Add support for direct IP block interconnect ("link") registration to
the hwmod code via a new function, omap_hwmod_register_links(). This
will replace direct registration of hwmods, and a subsequent patch
will remove omap_hwmod_register().
This change will allow a subsequent patch to remove the hwmod data
link arrays. This will reduce the size of the hwmod static data and
also make it easier to generate the data files. It will also make it
possible to share some of the struct omap_hwmod records across
multiple SoCs, since the link array pointers will be removed from the
struct omap_hwmod.
The downside is that boot time will increase. Minimizing boot time
was the reason why the link arrays were originally introduced.
Removing them will require extra computation during boot to allocate
memory and associate IP blocks with their interconnects. However,
since the current kernel development focus is on reducing the number
of lines in arch/arm/mach-omap2/, boot time impact is now seemingly
considered a lower priority.
This patch contains additional complexity to reduce the number of
memory allocations required for this change. This reduces the boot
time impact: total hwmod link registration time was ~ 2655
microseconds with a simple allocation strategy, but is now ~ 549
microseconds[1] with the approach taken by this patch.
1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average
of 7 samples. Total uncertainty is +/- 61 microseconds.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:04:29 +0000 (04:04 -0600)]
ARM: OMAP2+: hwmod: consolidate finding the MPU port index and storing it
An IP block's MPU interface port only needs to be found once. The result
can be cached to speed further lookups. This patch consolidates these
two steps into a single function.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:04:28 +0000 (04:04 -0600)]
ARM: OMAP2+: hwmod: add function to iterate over struct omap_hwmod_ocp_if
To reduce the number of lines of data in the OMAP portion of the Linux
code base, subsequent patches will remove the lists of hwmod
interconnect links from the static hwmod data. These lists will be
built dynamically during boot. To ease this transition, this patch
centralizes the way that interconnect links are iterated into a single
function, _fetch_next_ocp_if().
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:04:27 +0000 (04:04 -0600)]
ARM: OMAP2+: hwmod: add _find_mpu_rt_port()
Most IP blocks on the OMAP SoC have an interconnect link that is
intended to be used by the MPU to communicate with the IP block.
Several parts of the hwmod code need to be able to identify this link.
Currently, this is open-coded. However, future patches will change
the way that interconnect links are represented and will make
identifying the link more complex. So to avoid code duplication, this
patch centralizes the MPU port link identification code into a new
function, _find_mpu_rt_port().
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:03:57 +0000 (04:03 -0600)]
ARM: OMAP2+: hwmod: extend OCP_* register offsets from 16 to 32 bits
Extend the OCP_* register offsets in the struct
omap_hwmod_class_sysconfig to 32 bits. This is required to add the
OMAP4+ GPU hwmod, which uses OCP_* register offsets larger than 16
bits.
Another possible solution may be to simply add a single 16 bit offset
field in this structure, and to add code to factor that offset into
all OCP_* register accesses. This would save some memory, since
almost no modules need 32 bit offsets.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:03:56 +0000 (04:03 -0600)]
ARM: OMAP4: hwmod data: uncomment some "excluded" hwmods
Some hwmods were commented out from the OMAP4 data, under the theory
that they shouldn't be added until drivers were ready. But part of
the utility of the hwmod code is that it can reset and properly
initialize IP blocks that have no drivers associated with them.
Rather than commenting the links in the future hwmod data conversion
patches, discussing this with Benoit, it seems best to simply
uncomment them now.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:03:55 +0000 (04:03 -0600)]
ARM: OMAP4: hwmod data: add OCP_USER_DSP; mark omap44xx_dsp__iva appropriately
One of the OMAP4 links was missing OCP_USER flags, since it was only
used by the DSP initiator, and we did not have an OCP_USER_DSP flag.
Future patches will switch the hwmod code and data to register
interfaces, rather than hwmods, and it will be mandatory for all
interfaces to have at least one user bit set. This patch resolves the
issue by adding OCP_USER_DSP and marking the DSP-IVA interface
appropriately.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:03:54 +0000 (04:03 -0600)]
ARM: OMAP4: hwmod data: remove bandgap hwmod
Commit 407a6888f7362cb3dabe69ea6d9dcf3c750dc56a ("OMAP4: hwmod data:
Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS & IPU") adds a
hwmod for the bandgap die temperature sensor IP block. This IP block
has no interconnect port or firewall region, nor does it have an
independent register space or OCP control registers. Its registers
are embedded in the System Control Module (SCM) IP block. So it
appears that the bandgap device should be created by the SCM driver.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 10:03:52 +0000 (04:03 -0600)]
ARM: OMAP3: hwmod data: add DSS->L3 interconnect for 3430ES1
The OMAP3 hwmod data was missing a DSS->L3 interconnect link for the
OMAP3430 ES1 DSS hwmod. Since the hwmod code and data is being modified
to register interfaces rather than hwmods, this would result in the DSS hwmod
not being registered correctly on OMAP3430ES1.
Paul Walmsley [Thu, 19 Apr 2012 10:03:51 +0000 (04:03 -0600)]
ARM: OMAP3: hwmod data: fix interfaces for the MMC hwmods
Commit a52e2ab66d4a9305e1ba64d9b9d25754b6c70895 ("ARM: OMAP3: hwmod
data: disable multiblock reads on MMC1/2 on OMAP34xx/35xx <= ES2.1")
didn't link the MMC hwmods to the interconnects correctly. Future
patches will register hwmods by interface, so if this is not fixed,
the MMC IP blocks won't be registered. Update the interface data
records to point to the correct IP blocks.
Paul Walmsley [Thu, 19 Apr 2012 10:03:50 +0000 (04:03 -0600)]
ARM: OMAP2/3: hwmod data: update old names
Some of the 2xxx and 3xxx hwmod data files use the old naming style
for hwmods, ending in a "_hwmod". These names are used by the OMAP
integration code to map hwmods to platform_devices, so they need to be
consistent, or the platform_devices won't be created. Remove the
_hwmod suffix to conform with the rest of the OMAP SoC data.
Paul Walmsley [Thu, 19 Apr 2012 10:01:50 +0000 (04:01 -0600)]
ARM: OMAP2+: timer: use a proper interface to get hwmod data
arch/arm/mach-omap2/timer.c pokes around inside the hwmod data
structures. Since the hwmod data structures are about to change, this
code will break. This patch modifies the timer code to use
recently-added hwmod functions instead.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
The timer integration code pokes around in hwmod data structures.
Those data structures are about to change. Define a function,
omap_hwmod_get_resource_byname(), for the timer integration code to
use instead.
The original patch has been changed to use struct resource by Tony's
request, although the caller of this function should not be a driver._
Platform drivers should get their data through the regular platform_*
functions; DT drivers through the appropriate of_* functions. This a
function is only for use by OMAP core code in arch/arm/*omap*.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Thu, 19 Apr 2012 01:10:05 +0000 (19:10 -0600)]
ARM: OMAP2+: hwmod: provide a function to return the address space of the MPU RT
A subsequent patch will need to know the struct omap_hwmod_addr_space
record corresponding to the module's register target, used by the MPU.
So, convert _find_mpu_rt_base() into _find_mpu_rt_addr_space(). Then
modify its sole current user, _populate_mpu_rt_base(), to extract the
MPU RT base address itself from the struct omap_hwmod_addr_space record.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 01:10:04 +0000 (19:10 -0600)]
ARM: OMAP2+: hwmod: revise hardreset behavior
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 01:10:03 +0000 (19:10 -0600)]
ARM: OMAP2+: hwmod: reorganize and document the reset and configuration process
Reorganize the code involved in resetting and configuring an IP block
to make it easier to read and maintain. This involves improving
documentation, splitting some large functions up into smaller ones to
better conform with Documentation/CodingStyle, and removing some
unnecessary code.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 06:58:22 +0000 (00:58 -0600)]
ARM: OMAP2+: hwmod: reorganize and document the initialization process
Reorganize the code involved in initializing the internal data for
each hwmod to make it easier to read and maintain. This involves
improving documentation and removing some duplicated and unnecessary
code.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 06:49:09 +0000 (00:49 -0600)]
ARM: OMAP2+: hwmod: revise the IP block reset process
Revise the IP block reset process. This patch ensures that the
OCP_SYSCONFIG registers are reloaded after a custom reset. Since
OCP_SYSCONFIG bits are cleared during reset, they should be
reprogrammed unless the IP block is being left in reset. (The only IP
blocks that are left in reset are IP blocks with hardreset lines and
no custom reset function.) If the IP block is left in reset, then it
is inaccessible to the MPU, and an access to the OCP_SYSCONFIG
register will cause an abort.
This version incorporates comments from Omar Ramirez Luna
<omar.ramirez@ti.com> to skip the OCP_SYSCONFIG access after asserting
hardreset lines. This allows the MMU (IOMMU) IP block, which has
both hardreset lines and an OCP_SYSCONFIG register.
Also, ignore _ocp_softreset() errors if the IP block doesn't include a
softreset bit. This is needed since a subsequent patch will start
taking the return value of the _reset() function seriously.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 01:10:02 +0000 (19:10 -0600)]
ARM: OMAP4: hwmod data: remove pseudo-hwmods associated with hardreset lines
Remove the pseudo-hwmods associated with hardreset lines from the
OMAP4 data file. Future patches will convert this data to register
hwmods by interfaces, rather than registering hwmods directly. The
pseudo-hwmods aren't associated with any interfaces, so this will
create a problem.
After this change, the hwmod code will reset processor IPs at the
hwmod level, rather than by individual hardreset lines. So, for
example, if the IVA device driver code wishes to place one of the
sequencer cores into reset, while leaving the other active, it must do
so itself by calling the appropriate PRM functions.
This patch will cause a change in the initialization behavior of the
DSP, IVA, and IPU.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Paul Walmsley [Thu, 19 Apr 2012 01:10:02 +0000 (19:10 -0600)]
ARM: OMAP2+: hwmod: control all hardreset lines attached to a hwmod
Parts of the hwmod code test to see if a module has one and only one
hardreset line before taking an action. It seems more appropriate
to control all hardreset lines associated with a hwmod, not just one.
It so happens that with the current hwmod data, this patch will not
change any behavior, since hwmods with hardreset lines have only one
hardreset line associated with them, and 'pseudo-hwmods' are used to
handle the other hardreset lines. But future hwmod data patches to
remove the pseudo-hwmods will change this.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm
Pull ARM fixes from Russell King:
"Nothing too disasterous, the biggest thing being the removal of the
regulator support for vcore in the AMBA driver; only one SoC was using
this and it got broken during the last merge window, which then
started causing problems for other people. Mutual agreement was
reached for it to be removed."
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7386/1: jump_label: fixup for rename to static_key
ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE
ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU
ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus
ARM: 7383/1: nommu: populate vectors page from paging_init
ARM: 7381/1: nommu: fix typo in mm/Kconfig
ARM: 7380/1: DT: do not add a zero-sized memory property
ARM: 7379/1: DT: fix atags_to_fdt() second call site
ARM: 7366/3: amba: Remove AMBA level regulator support
ARM: 7377/1: vic: re-read status register before dispatching each IRQ handler
ARM: 7368/1: fault.c: correct how the tsk->[maj|min]_flt gets incremented
The 'max' range needs to be unsigned, since the size of the user address
space is bigger than 2GB.
We know that 'count' is positive in 'long' (that is checked in the
caller), so we will truncate 'max' down to something that fits in a
signed long, but before we actually do that, that comparison needs to be
done in unsigned.
Bug introduced in commit 92ae03f2ef99 ("x86: merge 32/64-bit versions of
'strncpy_from_user()' and speed it up"). On x86-64 you can't trigger
this, since the user address space is much smaller than 63 bits, and on
x86-32 it works in practice, since you would seldom hit the strncpy
limits anyway.
I had actually tested the corner-cases, I had only tested them on
x86-64. Besides, I had only worried about the case of a pointer *close*
to the end of the address space, rather than really far away from it ;)
This also changes the "we hit the user-specified maximum" to return
'res', for the trivial reason that gcc seems to generate better code
that way. 'res' and 'count' are the same in that case, so it really
doesn't matter which one we return.
Rabin Vincent [Sat, 14 Apr 2012 20:51:32 +0000 (21:51 +0100)]
ARM: 7386/1: jump_label: fixup for rename to static_key
c5905afb0 ("static keys: Introduce 'struct static_key'...") renamed
struct jump_label_key to struct static_key. Fixup ARM for this to
eliminate these build warnings:
include/linux/jump_label.h:113:2:
warning: passing argument 1 of 'arch_static_branch' from incompatible pointer type
include/asm/jump_label.h:17:82:
note: expected 'struct jump_label_key *' but argument is of type 'struct static_key *'
Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Jonathan Austin [Thu, 12 Apr 2012 16:45:25 +0000 (17:45 +0100)]
ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE
Currently when ThumbEE is not enabled (!CONFIG_ARM_THUMBEE) the ThumbEE
register states are not saved/restored at context switch. The default state
of the ThumbEE Ctrl register (TEECR) allows userspace accesses to the
ThumbEE Base Handler register (TEEHBR). This can cause unexpected behaviour
when people use ThumbEE on !CONFIG_ARM_THUMBEE kernels, as well as allowing
covert communication - eg between userspace tasks running inside chroot
jails.
This patch sets up TEECR in order to prevent user-space access to TEEHBR
when !CONFIG_ARM_THUMBEE. In this case, tasks are sent SIGILL if they try to
access TEEHBR.
Cc: stable@vger.kernel.org Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Jonathan Austin <jonathan.austin@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Will Deacon [Thu, 12 Apr 2012 16:15:08 +0000 (17:15 +0100)]
ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU
If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
kernel then we will hang early during boot since the memory bank will
have wrapped around to zero.
This patch truncates memory banks for !LPAE configurations when the end
address is not representable in 32 bits.
Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus
During booting of cpu1, there is a short window where cpu1
is online, but not active where cpu1 is occupied by waiting
to become active. If cpu0 then decides to schedule something
on cpu1 and wait for it to complete, before cpu0 has set
cpu1 active, we have a deadlock.
Typically it's this CPU frequency transition that happens at
this time, so let's just not wait for it to happen, it will
happen whenever the CPU eventually comes online instead.
Cc: Peter Zijlstra <peterz@infradead.org> Cc: stable@kernel.org Signed-off-by: Jonas Aaberg <jonas.aberg@stericsson.com> Reviewed-by: Rickard Andersson <rickard.andersson@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 26f41062f28d ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.
First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one). Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt. Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.
All of this actually caused resume failures for some devices on Mikko's
system.
To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value. Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: Mikko Vinni <mmvinni@yahoo.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull "ARM: a few more SoC fixes for 3.4-rc" from Olof Johansson:
- A handful of warning and build fixes for Qualcomm MSM
- Build/warning and bug fixes for Samsung Exynos
- A fix from Rob Herring that removes misplaced interrupt-parent
properties from a few device trees
- A fix to OMAP dealing with cpufreq build errors, removing some of the
offending code since it was redundant anyway
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: OMAP: clock: cleanup CPUfreq leftovers, fix build errors
ARM: dts: remove blank interrupt-parent properties
ARM: EXYNOS: Fix Kconfig dependencies for device tree enabled machine files
ARM: EXYNOS: Remove broken config values for touchscren for NURI board
ARM: EXYNOS: set fix xusbxti clock for NURI and Universal210 boards
ARM: EXYNOS: fix regulator name for NURI board
ARM: SAMSUNG: make SAMSUNG_PM_DEBUG select DEBUG_LL
ARM: msm: Fix section mismatches in proc_comm.c
video: msm: Fix section mismatches in mddi.c
arm: msm: trout: fix compile failure
arm: msm: halibut: remove unneeded fixup
ARM: EXYNOS: Add PDMA and MDMA physical base address defines
ARM: S5PV210: Fix compiler warning in dma.c file
ARM: EXYNOS: Fix compile error in exynos5250-cpufreq.c
ARM: EXYNOS: Add missing definition for IRQ_I2S0
ARM: S5PV210: fix unused LDO supply field from wm8994_pdata
Merge tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull another round of sound fixes from Takashi Iwai:
"A few regression fixes for Realtek HD-audio codecs, mainly specific to
some laptop models."
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda/realtek - Fix mem leak (and rid us of trailing whitespace).
ALSA: hda/realtek - Add quirk for Mac Pro 5,1 machines
ALSA: hda/realtek - Add a fixup entry for Acer Aspire 8940G
ALSA: hda/realtek - Fix GPIO1 setup for Acer Aspire 4930 & co
ALSA: hda/realtek - Add a few ALC882 model strings back
Commit 18a4d0a22ed6 ("[SCSI] Handle disk devices which can not process
medium access commands") introduced a bug in which we would attempt to
dereference the scsi driver even when the device had no ULD attached.
Ensure that a driver is registered and make the driver accessor function
more resilient to errors during device discovery.
Reported-by: Elric Fu <elricfu1@gmail.com> Reported-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Removing this code also eliminates build errors when CPU_FREQ_TABLE
support is not enabled.
Thanks to Russell King for pointing out the parts I missed under
plat-omap in the original version and also pointing out the build
errors when CPUFREQ_TABLE support was not enabled.
Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Kevin Hilman <khilman@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Olof Johansson <olof@lixom.net>
These were incorrectly introduced and can cause problems for of_irq_init.
The correct way to define a root controller is no interrupt-parent set at
all or the interrupt-parent is set to the root controller itself when
inherited from a parent node.
Signed-off-by: Rob Herring <rob.herring@calxeda.com> Tested-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
Olof Johansson [Sun, 15 Apr 2012 00:44:21 +0000 (17:44 -0700)]
Merge branch 'msm-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm into fixes
From David Brown:
"Here are some fixes for msm that fix problems caused by the latest
ARM code. The ones from Daniel remove unneeded fixups that now
cause compilation failures. Mine fix section mismatches, that were
incompletely fixed earlier."
* 'msm-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm:
ARM: msm: Fix section mismatches in proc_comm.c
video: msm: Fix section mismatches in mddi.c
arm: msm: trout: fix compile failure
arm: msm: halibut: remove unneeded fixup
ARM: EXYNOS: Fix Kconfig dependencies for device tree enabled machine files
Add config dependency for Exynos4 and Exynos5 device tree enabled machine
files on config options ARCH_EXYNOS4 and ARCH_EXYNOS5 respectively.
Enabling machine support without proper ARCH support enabled is incorrect.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Lubos Lunak [Wed, 21 Mar 2012 13:08:24 +0000 (14:08 +0100)]
do not export kernel's NULL #define to userspace
GCC's NULL is actually __null, which allows detecting some questionable
NULL usage and warn about it. Moreover each platform/compiler should
have its own stddef.h anyway (which is different from linux/stddef.h).
So there's no good reason to leak kernel's NULL to userspace and
override what the compiler provides.
Marek Szyprowski [Tue, 10 Apr 2012 04:10:32 +0000 (21:10 -0700)]
ARM: EXYNOS: Remove broken config values for touchscren for NURI board
The atmel_mxt_ts driver has been extended to support more 'configuration
objects' in commit 81c88a711 ("Input: atmel_mxt_ts - update object list"),
what broke the configuration values for NURI board. These values are
optional anyway, so remove them to get the driver working correctly.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Marek Szyprowski [Tue, 10 Apr 2012 04:10:32 +0000 (21:10 -0700)]
ARM: EXYNOS: set fix xusbxti clock for NURI and Universal210 boards
On some versions of NURI and UniversalC210 boards, camera clocks are
routed directly to xusbxti clock source. This patch sets the correct
value for this clock to let usb and camera sensors to work correctly and
avoid division by zero on driver's probe.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Marek Szyprowski [Tue, 10 Apr 2012 04:10:32 +0000 (21:10 -0700)]
ARM: EXYNOS: fix regulator name for NURI board
Regulator names should not contain slash to avoid issues with debugfs.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
ARM: SAMSUNG: make SAMSUNG_PM_DEBUG select DEBUG_LL
When selecting SAMSUNG_PM_DEBUG, it complains about a missing printascii()
function if you do not select DEBUG_LL, so make the former select the latter.
Merge branch 'systemh-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux
Pull system.h fixups for less common arch's from Paul Gortmaker:
"Here is what is hopefully the last of the system.h related fixups.
The fixes for Alpha and ia64 are code relocations consistent with what
was done for the more mainstream architectures. Note that the
diffstat lines removed vs lines added are not the same since I've
fixed some of the whitespace issues in the relocated code blocks.
However they are functionally the same. Compile tested locally, plus
these two have been in linux-next for a while.
There is also a trivial one line system.h related fix for the Tilera
arch from Chris Metcalf to fix an implict include.."
* 'systemh-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
irq_work: fix compile failure on tile from missing include
ia64: populate the cmpxchg header with appropriate code
alpha: fix build failures from system.h dismemberment
Merge tag 'fbdev-fixes-for-3.4-1' of git://github.com/schandinat/linux-2.6
Pull fbdev fixes from Florian Tobias Schandinat:
- a compile fix for au1*fb
- a fix to make kyrofb usable on x86_64
- a fix for uvesafb to prevent an oops due to NX-protection
"The fix for kyrofb is a bit large but it's just replacing "unsigned
long" by "u32" for 64 bit compatibility."
* tag 'fbdev-fixes-for-3.4-1' of git://github.com/schandinat/linux-2.6:
video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
fbdev: fix au1*fb builds
kyrofb: fix on x86_64
Merge branch 'for-linus-min' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs
Pull the minimal btrfs branch from Chris Mason:
"We have a use-after-free in there, along with errors when mount -o
discard is enabled, and a BUG_ON(we should compile with UP more
often)."
* 'for-linus-min' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
Btrfs: use commit root when loading free space cache
Btrfs: fix use-after-free in __btrfs_end_transaction
Btrfs: check return value of bio_alloc() properly
Btrfs: remove lock assert from get_restripe_target()
Btrfs: fix eof while discarding extents
Btrfs: fix uninit variable in repair_eb_io_failure
Revert "Btrfs: increase the global block reserve estimates"
Merge branch 'for-3.4/drivers' of git://git.kernel.dk/linux-block
Pull block driver bits from Jens Axboe:
- A series of fixes for mtip32xx. Most from Asai at Micron, but also
one from Greg, getting rid of the dependency on PCIE_HOTPLUG.
- A few bug fixes for xen-blkfront, and blkback.
- A virtio-blk fix for Vivek, making resize actually work.
- Two fixes from Stephen, making larger transfers possible on cciss.
This is needed for tape drive support.
* 'for-3.4/drivers' of git://git.kernel.dk/linux-block:
block: mtip32xx: remove HOTPLUG_PCI_PCIE dependancy
mtip32xx: dump tagmap on failure
mtip32xx: fix handling of commands in various scenarios
mtip32xx: Shorten macro names
mtip32xx: misc changes
mtip32xx: Add new sysfs entry 'status'
mtip32xx: make setting comp_time as common
mtip32xx: Add new bitwise flag 'dd_flag'
mtip32xx: fix error handling in mtip_init()
virtio-blk: Call revalidate_disk() upon online disk resize
xen/blkback: Make optional features be really optional.
xen/blkback: Squash the discard support for 'file' and 'phy' type.
mtip32xx: fix incorrect value set for drv_cleanup_done, and re-initialize and start port in mtip_restart_port()
cciss: Fix scsi tape io with more than 255 scatter gather elements
cciss: Initialize scsi host max_sectors for tape drive support
xen-blkfront: make blkif_io_lock spinlock per-device
xen/blkfront: don't put bdev right after getting it
xen-blkfront: use bitmap_set() and bitmap_clear()
xen/blkback: Enable blkback on HVM guests
xen/blkback: use grant-table.c hypercall wrappers
Merge branch 'for-3.4/core' of git://git.kernel.dk/linux-block
Pull block core bits from Jens Axboe:
"It's a nice and quiet round this time, since most of the tricky stuff
has been pushed to 3.5 to give it more time to mature. After a few
hectic block IO core changes for 3.3 and 3.2, I'm quite happy with a
slow round.
Really minor stuff in here, the only real functional change is making
the auto-unplug threshold a per-queue entity. The threshold is set so
that it's low enough that we don't hold off IO for too long, but still
big enough to get a nice benefit from the batched insert (and hence
queue lock cost reduction). For raid configurations, this currently
breaks down."
* 'for-3.4/core' of git://git.kernel.dk/linux-block:
block: make auto block plug flush threshold per-disk based
Documentation: Add sysfs ABI change for cfq's target latency.
block: Make cfq_target_latency tunable through sysfs.
block: use lockdep_assert_held for queue locking
block: blk_alloc_queue_node(): use caller's GFP flags instead of GFP_KERNEL
Kevin Hilman [Fri, 13 Apr 2012 20:32:30 +0000 (13:32 -0700)]
cpufreq: OMAP: fix build errors: depends on ARCH_OMAP2PLUS
The OMAP driver needs a 'depends on ARCH_OMAP2PLUS' since it only
builds for OMAP2+ platforms.
This 'depends on' was in the original patch from Russell King, but was
erroneously removed by me when making this option user-selectable in
commit b09db45c (cpufreq: OMAP driver depends CPUfreq tables.) This
patch remedies that.
Apologies to Russell King for breaking his originally working patch.
Also, thanks to Grazvydas Ignotas for reporting the same problem.
Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6
Pull GPIO bug fixes from Grant Likely:
"Miscellaneous bug fixes to GPIO drivers and for a corner case in the
gpio device tree parsing code."
* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6:
gpio/exynos: Fix compiler warning in gpio-samsung.c file
gpio: Fix range check in of_gpio_simple_xlate()
gpio: Fix uninitialized variable bit in adp5588_irq_handler
gpio/sodaville: Convert sodaville driver to new irqdomain API
Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6
Pull SPI bug fixes from Grant Likely:
"Miscellaneous driver bug fixes. No major changes in this branch."
* tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6:
spi/imx: prevent NULL pointer dereference in spi_imx_probe()
spi/imx: mark base member in spi_imx_data as __iomem
spi/mpc83xx: fix NULL pdata dereference bug
spi/davinci: Fix DMA API usage in davinci
spi/pL022: include types.h to remove compilation warnings
Paul E. McKenney [Fri, 13 Apr 2012 03:35:13 +0000 (03:35 +0000)]
sparc64: Eliminate obsolete __handle_softirq() function
The invocation of softirq is now handled by irq_exit(), so there is no
need for sparc64 to invoke it on the trap-return path. In fact, doing so
is a bug because if the trap occurred in the idle loop, this invocation
can result in lockdep-RCU failures. The problem is that RCU ignores idle
CPUs, and the sparc64 trap-return path to the softirq handlers fails to
tell RCU that the CPU must be considered non-idle while those handlers
are executing. This means that RCU is ignoring any RCU read-side critical
sections in those handlers, which in turn means that RCU-protected data
can be yanked out from under those read-side critical sections.
The shiny new lockdep-RCU ability to detect RCU read-side critical sections
that RCU is ignoring located this problem.
The fix is straightforward: Make sparc64 stop manually invoking the
softirq handlers.
Reported-by: Meelis Roos <mroos@linux.ee> Suggested-by: David Miller <davem@davemloft.net> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested-by: Meelis Roos <mroos@linux.ee> Cc: stable@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 13 Apr 2012 18:56:22 +0000 (11:56 -0700)]
sparc64: Fix bootup crash on sun4v.
The DS driver registers as a subsys_initcall() but this can be too
early, in particular this risks registering before we've had a chance
to allocate and setup module_kset in kernel/params.c which is
performed also as a subsyts_initcall().
Register DS using device_initcall() insteal.
Signed-off-by: David S. Miller <davem@davemloft.net> Cc: stable@vger.kernel.org
fixes a section mismatch between the board file and the smd driver's
probe function, however, it misses the additional mismatches between
the probe function and some routines it calls. Fix these up as well.
Signed-off-by: David Brown <davidb@codeaurora.org>
fixes a section mismatch between the board file and the driver's probe
function, however, it misses the additional mismatches between the
probe function and some routines it calls. Fix these up as well.
Signed-off-by: David Brown <davidb@codeaurora.org>
Daniel Walker [Thu, 12 Apr 2012 15:45:37 +0000 (08:45 -0700)]
arm: msm: trout: fix compile failure
Fixes the following warnings,
arch/arm/mach-msm/board-trout.c: In function 'trout_init':
arch/arm/mach-msm/board-trout.c:71: error: 'system_rev' undeclared (first use in this function)
arch/arm/mach-msm/board-trout.c:71: error: (Each undeclared identifier is reported only once
arch/arm/mach-msm/board-trout.c:71: error: for each function it appears in.)
and
arch/arm/mach-msm/board-trout-panel.c: In function 'trout_init_panel':
arch/arm/mach-msm/board-trout-panel.c:267: error: 'system_rev' undeclared (first use in this function)
arch/arm/mach-msm/board-trout-panel.c:267: error: (Each undeclared identifier is reported only once
arch/arm/mach-msm/board-trout-panel.c:267: error: for each function it appears in.)
Signed-off-by: Daniel Walker <dwalker@fifo99.com>
cc: David Howells <dhowells@redhat.com>
cc: Bryan Huntsman <bryanh@codeaurora.org>
cc: linux-arm-msm@vger.kernel.org
cc: linux-arm-kernel@lists.infradead.org Signed-off-by: David Brown <davidb@codeaurora.org>
"Move the asm-generic/system.h xchg() implementation to asm-generic/cmpxchg.h"
introduced the concept of asm/cmpxchg.h but the alpha arch
never got one. Fork the cmpxchg content out of the asm/atomic.h
file to create one.
Some minor whitespace fixups were done on the block of code that
created the new file.
Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: David Howells <dhowells@redhat.com> Acked-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Will Deacon [Thu, 12 Apr 2012 16:16:01 +0000 (17:16 +0100)]
ARM: 7383/1: nommu: populate vectors page from paging_init
Commit 94e5a85b ("ARM: earlier initialization of vectors page") made it
the responsibility of paging_init to initialise the vectors page.
This patch adds a call to early_trap_init for the !CONFIG_MMU case,
placing the vectors at CONFIG_VECTORS_BASE.
Cc: Jonathan Austin <jonathan.austin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Marc Zyngier [Wed, 11 Apr 2012 13:52:56 +0000 (14:52 +0100)]
ARM: 7380/1: DT: do not add a zero-sized memory property
Some bootloaders are broken enough to expose an ATAG_MEM with
a null size. Converting such tag to a memory node leads to
an unbootable system.
Skip over zero sized ATAG_MEM to avoid this situation.
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Marc Zyngier [Wed, 11 Apr 2012 13:52:55 +0000 (14:52 +0100)]
ARM: 7379/1: DT: fix atags_to_fdt() second call site
atags_to_fdt() returns 1 when it fails to find a valid FDT signature.
The CONFIG_ARM_ATAG_DTB_COMPAT code is supposed to retry with another
location, but only does so when the initial call doesn't fail.
Fix this by using the correct condition in the assembly code.
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Mark Brown [Fri, 13 Apr 2012 12:11:50 +0000 (13:11 +0100)]
ARM: 7366/3: amba: Remove AMBA level regulator support
The AMBA bus regulator support is being used to model on/off switches
for power domains which isn't terribly idiomatic for modern kernels with
the generic power domain code and creates integration problems on platforms
which don't use regulators for their power domains as it's hard to tell
the difference between a regulator that is needed but failed to be provided
and one that isn't supposed to be there (though DT does make that easier).
Platforms that wish to use the regulator API to manage their power domains
can indirect via the power domain interface.
This feature is only used with the vape supply of the db8500 PRCMU
driver which supplies the UARTs and MMC controllers, none of which have
support for managing vcore at runtime in mainline (only pl022 SPI
controller does). Update that supply to have an always_on constraint
until the power domain support for the system is updated so that it is
enabled for these users, this is likely to have no impact on practical
systems as probably at least one of these devices will be active and
cause AMBA to hold the supply on anyway.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: OMAP2/3: VENC hwmods: Remove OCPIF_SWSUP_IDLE flag from VENC slave interface
The clocks for all DSS slave interfaces were recently changed to "dss_ick" on
OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface
previously had "dss_54m_fck" as it's clock which couldn't be autoidled, and
hence the OCPIF_SWSUP_IDLE flag was needed.
Remove the OCPIF_SWSUP_IDLE flag from VENC interfaces as it's clock is
now "dss_ick". This allows the PRCM hardware to autoidle the VENC
interface clocks when they are not active, rather than relying on the
software to do it, which can keep the interface clocks active
unnecessarily.
Signed-off-by: Archit Taneja <archit@ti.com>
[paul@pwsan.com: add a short description of the fix to the commit log] Signed-off-by: Paul Walmsley <paul@pwsan.com>
Paul Walmsley [Fri, 13 Apr 2012 11:08:43 +0000 (05:08 -0600)]
ARM: OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status"
This reverts commit f9a2f9c3fa76eec55928e8e06f3094c8f01df7cb. This
commit caused a regression in the I2C hwmod reset on OMAP2/3/4,
logging messages similar to these during boot:
While the original patch was intended to fix some reset-related timing
issues, it's believed that these problems were actually fixed by
commit 2800852a079504f35f88e44faf5c9c96318c0cca ("ARM: OMAP2+: hwmod:
Restore sysc after a reset"):
ARM: OMAP2+: hwmod: add softreset delay field and OMAP4 data
Due to HW limitation, some IPs should not be accessed just after a
softreset. Since the current hwmod sequence is accessing the sysconfig
register just after the reset, it might lead to OCP bus error in
that case.
Add a new field in the sysconfig structure to specify a delay in usecs
needed after doing a softreset.
In the case of the ISS and FDIF modules, the L3 OCP port will be
disconnected upon a SW reset. That issue was confirmed with HW simulation
and an errata should be available soon. The HW recommendation to avoid
that is to wait for 100 OCP clk cycles, before accessing the IP.
Considering the worse case (OPP50), the L3 bus will run at 100 MHz,
so a 1 usec delay is needed. Add an x2 margin to be safe.
Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
[paul@pwsan.com: dropped FDIF change for now since the hwmod data is not
yet upstream; the FDIF change will need to be added later once the FDIF
data is merged] Signed-off-by: Paul Walmsley <paul@pwsan.com>
ALSA: hda/realtek - Fix mem leak (and rid us of trailing whitespace).
In sound/pci/hda/patch_realtek.c::alc_auto_fill_dac_nids(), in the
'for (;;)' loop, if the 'badness' value returned from
fill_and_eval_dacs() is negative, then we'll return from the function
without freeing the memory we allocated for 'best_cfg', thus leaking.
Fix the leak by kfree()'ing the memory when badness is negative.
While I was there I also noticed some trailing whitespace in the
function that I removed (along with all other trailing whitespace in
the file) - it didn't seem worth-while to do that as two patches, so I
hope it's OK that I just did it all as one patch.
Paul Gortmaker [Thu, 12 Apr 2012 23:46:34 +0000 (19:46 -0400)]
kconfig: delete last traces of __enabled_ from autoconf.h
We've now fixed IS_ENABLED() and friends to not require any special
"__enabled_" prefixed versions of the normal Kconfig options, so delete
the last traces of them being generated.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dumping two lines into autoconf.h for all existing Kconfig options
results in a giant file (~16k lines) we have to process each time we
compile something. We've weaned IS_ENABLED() and similar off of
requiring the __enabled_ definitions so now we can revert the change
which caused all the extra lines.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>