Paul Walmsley [Tue, 23 Feb 2010 05:09:12 +0000 (22:09 -0700)]
OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation
The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are
one increment higher than they should be. See for example the
OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the
OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL". Programming a 0 into
the DPLL's M register bitfield is valid for OMAP2/3 and indicates that
the DPLL should enter MN-bypass mode. Also, increase the minimum
multiplier (M) value for the DPLL rate rounding code from 1 to 2, to
ensure that it does not inadvertently put the DPLL into bypass.
Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs
does not make clear that the actual DPLL divider value (the "N") is
the content of the appropriate register bitfield for the N value,
_plus one_. (In other words, an N register bitfield of 0 indicates a
DPLL divider value of 1.) This is only clearly documented in the
OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167
"CM_CLKSEL_DPLL_USB".
While here, update copyrights, add kerneldoc for struct dpll_data,
drop the unused struct dpll_data.max_tolerance field, remove some
unnecessary #includes in DPLL-related code, and replace the #include
of <linux/module.h> with <linux/list.h>, which is what was really
needed. The OMAP4 clock autogenerator script has been updated
accordingly.
Vishwanath BS [Tue, 23 Feb 2010 05:09:10 +0000 (22:09 -0700)]
OMAP3 clock: add support for 192Mhz DPLL4M2 output
In 3630, DPLL4M2 output can be 96MHz or 192MHz (for SGX to run at
192). This patch has changes to support this feature. 96MHz clock is
generated by dividing 192Mhz clock by 2 using CM_CLKSEL_CORE register.
SGX can select Core Clock, 192MHz clock or CM_96M_FCLK as it's
functional clock. In summary changes done are:
1. Added a feature called omap3_has_192mhz_clk and enabled for 3630
2. Added a new clock node called omap_192m_alwon_ck
3. Made omap_96m_alwon_fck to derive its clock from omap_192m_alwon_ck
Divider (M2, M3, M4, M5 and M6) field width has been increased by 1 bit
in 3630. This patch has changes to accommodate this in CM dynamically
based on chip version.
Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and
M6 and value of these nodes are used if cpu type is 3630.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
[paul@pwsan.com: updated to apply on 2.6.34 queue; comments added] Signed-off-by: Paul Walmsley <paul@pwsan.com>
Richard Woodruff [Tue, 23 Feb 2010 05:09:08 +0000 (22:09 -0700)]
OMAP3 clock: introduce DPLL4 Jtype
DPLL4 for 3630 introduces a changed block called j type dpll, requiring
special divisor bits and additional reg fields. To allow for silicons to
use this, this is introduced as a flag and is enabled for 3630 silicon.
OMAP4 also has j type dpll for usb.
Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
Signed-off-by: Richard Woodruff <r-woodruff2@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Vishwanath BS <Vishwanath.bs@ti.com>
[paul@pwsan.com: added some comments; updated copyrights and credits; fixed
some style issues] Signed-off-by: Paul Walmsley <paul@pwsan.com>
Mike Turquette [Wed, 24 Feb 2010 19:06:00 +0000 (12:06 -0700)]
OMAP3630: Clock: Workaround for DPLL HS divider limitation
This patch implements a workaround for the DPLL HS divider limitation
in OMAP3630 as given by Errata ID: i556.
Errata:
When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
The reset value gets loaded instead of the previous value.
The following HSDIVIDERs exhibit above behavior:
. DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
. DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
Work Around:
It is mandatory to apply the following sequence to ensure the write
value will
be loaded in DPLL HSDIVIDER FSM:
The global sequence when using PWRDN bit is the following:
. Disable Mx HSDIVIDER clock output related functional clock enable bits
(in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
. Enable PWRDN bit of HSDIVIDER
. Disable PWRDN bit of HSDIVIDER
. Read current HSDIVIDER register value
. Write different value in HSDIVIDER register
. Write expected value in HSDIVIDER register
. Enable Mx HSDIVIDER clock output related functional clocks
(CM_FCLKEN_xxx / CM_ICLKEN_xxx)
Signed-off-by: Mike Turquette <mturquette@ti.com> Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Vijaykumar GN <vijaykumar.gn@ti.com>
[paul@pwsan.com: updated patch to apply; made workaround function static;
marked as being 36xx-specific] Signed-off-by: Paul Walmsley <paul@pwsan.com>
Thara Gopinath [Wed, 24 Feb 2010 19:05:58 +0000 (12:05 -0700)]
OMAP: HWMOD: Add support for early device register into omap device layer
This patch adds support in omap device layer to register devices
as early platform devices. Certain devices needed during system boot up
like timers, gpio etc can be registered as early devices. This will
allow for them to be probed very early on during system boot up.
This patch adds a parameter is_early_device in omap_device_build.
Depending on this parameter a call to early_platform_add_devices
or platform_register_device is made.
Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Thara Gopinath [Wed, 24 Feb 2010 19:05:58 +0000 (12:05 -0700)]
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits.
In OMAP3 Some modules like Smartreflex do not have the regular sysconfig
register.Instead clockactivity bits are part of another register at a
different bit position than the usual bit positions 8 and 9.
In OMAP4, a new scheme is available due to the new protocol
between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG
bitfields position will be different.
The IP_REVISION register should be at offset 0x00.
It should contain a SCHEME field. From this we can determine whether
the IP follows legacy scheme or the new scheme.
31:30 SCHEME Used to distinguish between old scheme and current.
Read 0x0: Legacy protocol.
Read 0x1: New PRCM protocol defined for new OMAP4 IPs
For legacy IP
13:12 MIDLEMODE
11:8 CLOCKACTIVITY
6 EMUSOFT
5 EMUFREE
4:3 SIDLEMODE
2 ENAWAKEUP
1 SOFTRESET
0 AUTOIDLE
For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target):
5:4 STANDBYMODE (Ex MIDLEMODE)
3:2 IDLEMODE (Ex SIDLEMODE)
1 FREEEMU (Ex EMUFREE)
0 SOFTRESET
Unfortunately In OMAP4 also some IPs will not follow any of these
two schemes. This is the case at least for McASP, SmartReflex
and some security IPs.
This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which
can be used by the hwmod structures to specify the offsets for the
sysconfig register of the IP.Also two static structures
omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined
which can be used directly to populate the sysc_fields if the IP follows
legacy or new OMAP4 scheme. If the IP follows none of these two schemes
a new omap_hwmod_sysc_fields structure has to be defined and
passed as part of omap_hwmod_sysconfig.
Vishwanath BS [Wed, 24 Feb 2010 19:05:57 +0000 (12:05 -0700)]
OMAP3 clock: Remove FreqSel for 3630
DPLL_FREQSEL field in CLKEN_PLL register is no longer valid for
OMAP3630. So remove references to that.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com> Cc: Sergei Shtylyov <sshtylyov@mvista.com>
[paul@pwsan.com: added comment fix from Sergei Shtylyov] Signed-off-by: Paul Walmsley <paul@pwsan.com>
AM35xx: Add clock support for new modules on AM35xx
This patch adds clock support for the following AM35xx modules
- Ethernet MAC
- CAN Controller (HECC)
- New MUSB OTG Controller with integrated Phy
- Video Processing Front End (VPFE)
- Additional UART (UART4)
Signed-off-by: Ranjith Lohithakshan <ranjithl@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
OMAP2/3 clock: Extend find_idlest() to pass back idle state value
Current implementation defines clock idle state indicators based on the
cpu information (cpu_is_omap24xx() or cpu_is_omap34xx()) in a system wide
manner. This patch extends the find_idlest() function in clkops to pass
back the idle state indicator for that clock, thus allowing idle state
indicators to be defined on a per clock basis if required.
This is specifically needed on AM35xx devices as the new IPSS clocks
indicates the idle status (0 is idle, 1 is ready) in a way just
opposite to how its handled in OMAP3 (0 is ready, 1 is idle).
Signed-off-by: Ranjith Lohithakshan <ranjithl@ti.com>
[paul@pwsan.com: updated to apply after commit 98c45457 et seq.] Signed-off-by: Paul Walmsley <paul@pwsan.com>
Thara Gopinath [Wed, 24 Feb 2010 19:05:50 +0000 (12:05 -0700)]
OMAP3 PM: Adding counters for power domain logic off and mem off during retention.
This patch adds counters to keep track of whether the powerdomain
logic or software controllable memory banks are turned off when
the power domain enters retention. During power domain retention
if logic gets turned off, the scenario is known as Open Switch Retention.
Also during retention s/w controllable memory banks of a power
domain can be chosen to be kept in retention or off.
This patch adds one counter per powerdomain to track the power domain
logic state during retention. Number of memory bank state counters
added depends on the number of software controllable memory banks
of the powerdomain. To view these counters do
cat ../debug/pm_debug/count
Signed-off-by: Thara Gopinath <thara@ti.com>
[paul@pwsan.com: conditional expressions simplified; counter increment
code moved to its own function] Signed-off-by: Paul Walmsley <paul@pwsan.com>
Thara Gopinath [Wed, 24 Feb 2010 19:05:50 +0000 (12:05 -0700)]
OMAP3 PM: Defining .pwrsts_logic_ret field for core power domain structure
This patch adds the flag .pwrsts_logic_ret info for the core power domain
in the associated powerdomain structure. This flag specifies the states
core domain logic can hit in event of the domain entering retention.
Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Thara Gopinath [Wed, 24 Feb 2010 19:05:49 +0000 (12:05 -0700)]
OMAP2/3 PM: Adding powerdomain APIs for reading the next logic and mem state
This patch adds APIs pwrdm_read_logic_retst and
pwrdm_read_mem_retst for reading the next programmed
logic and memory state a powerdomain is to hit in event
of the next power domain state being retention.
These are needed for OSWR support.
Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Kevin Hilman [Wed, 24 Feb 2010 19:05:45 +0000 (12:05 -0700)]
OMAP: omap_device: when 'called from invalid state', print state
The omap_device_[enable|idle|shutdown] functions print a warning
when called from an invalid state. Print the invalid state in
the warning messages. This also uses __func__ to get the function
name.
Also, move the entire print string onto a single line to facilitate
grepping or error messages. Recent discussions on LKML show
strong preference for grep-able code vs. strict 80 column limit.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Kevin Hilman [Wed, 24 Feb 2010 19:05:45 +0000 (12:05 -0700)]
OMAP: omap_device: add omap_device_is_valid()
The omap_device struct contains a 'struct platform_device'. Normally,
converting a platform_device pointer to an omap_device pointer
consists of simply doing a container_of(), as is done currently by the
to_omap_device() macro.
However, if this is attempted when using platform_device that has not
been created as part of the omap_device creation, the container_of()
will point to a memory location before the platform_device pointer
which will contain random data.
Therefore, we need a way to detect valid omap_device pointers. This
patch solves this by using the simple magic number approach.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
omap: Remove DEBUG_FS dependency for mux name checking
The check for a valid mux name should be performed regardless of whether
DEBUG_FS is enabled or not. Otherwise without DEBUG_FS, we get:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1]
last sysfs file:
Modules linked in:
CPU: 0 Not tainted (2.6.33-rc8 #10)
PC is at strcmp+0x18/0x40
LR is at omap_mux_init_signal+0x68/0x14c
...
This fixes the issue currently seen with boards not booting up
if DEBUG_FS is not enabled in defconfig.
Note that the earlier ifndef + ifdef now becomes simpler ifdef else:
If CONFIG_OMAP_MUX is selected, we use pin names. If it's not selected,
we only want the GPIO to mux register mapping.
Signed-off-by: Ranjith Lohithakshan <ranjithl@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Adrian Hunter [Mon, 15 Feb 2010 18:03:34 +0000 (10:03 -0800)]
omap_hsmmc: Allow for a shared VccQ
EMMC can have two voltage supplies, Vcc and VccQ
which are implemented in the code as consumer
supplies vmmc and vmmc_aux.
If the regulator that supplies vmmc_aux is shared
with other consumers, then sending it to sleep
will disrupt those consumers. However, the
TWL4030-family regulators may have OFF remapped
to SLEEP, in which case 'regulator_disable()'
will put the regulator to sleep only when all
consumers are disabled - which is the desired
behaviour.
This patch adds a platform data field to allow
that option.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Adrian Hunter [Mon, 15 Feb 2010 18:03:34 +0000 (10:03 -0800)]
omap: RX51: Remux to pull eMMC lines down when powering off
It has been discovered that, when eMMC is powered off, current
will flow from OMAP eMMC data pull-ups to the eMMC voltage supply.
Configuring pads for OMAP off-mode does not help because eMMC is
powered off independently of OMAP off-mode. Hence the pads are
now re-configured when eMMC is powered on or off.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Adrian Hunter [Mon, 15 Feb 2010 18:03:34 +0000 (10:03 -0800)]
omap_hsmmc: Move gpio and regulator control from board file
This patch moves the setup code for GPIO's and Voltage
Regulators from the board file mmc-twl4030.c to the
driver omap_hsmmc.c. PBIAS and other system control
configuration remains in the board file.
Moving GPIO code to the driver makes the board initialisation
code independent of when GPIO's are defined. That makes the
board initialisation now entirely independent of its original
twl4030 roots.
Moving Voltage Regulator code to the driver allows for further
development of regulator support in the core MMC code. It also
permits the MMC core to be compiled as a module, because the
board code no longer calls MMC core functions.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Vimal Singh [Mon, 15 Feb 2010 18:03:33 +0000 (10:03 -0800)]
omap3: SDP: Introducing 'board-sdp-flash.c' for flash init
This patch adds 'board-sdp-flash.c', which could be utilized
by boards similar to 3430SDP. (For ex: 2430sdp, 36030sdp).
This file does initialization for all three flash devices present
in SDP boards (NOR, NAND, OneNAND), by finding there 'cs' number
dynamically using switch setting information (S8: 1-4).
This also expects partition information from core board files (for
ex: board-3430sdp.c). Which allows to choose different default
partitions for different boards.
A new structure is created for this purpose: 'flash_partitions'
in 'mach/board-sdp.h'. This has two members:
1. struct mtd_partition *parts
2. int nr_parts
A board file is expected to fill this structure and pass it to
'sdp-flsash-init'. Partition information should be passed in
structure array of 'flash_partitions'. Partition information should
be passed in below sequence in array:
NOR
OneNAND
NAND
Signed-off-by: Vimal Singh <vimalsingh@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Vimal Singh [Mon, 15 Feb 2010 18:03:33 +0000 (10:03 -0800)]
omap2/3/4: Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh <vimalsingh@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
omap: McBSP: Use cache when modifying individual register bits
Change the way McBSP registers are updated: use cached values instead of
relying upon those read back from the device.
With this patch, I have finally managed to get rid of all random
playback/recording hangups on my OMAP1510 based Amstrad Delta hardware. Before
that, values read back from McBSP registers to be used for updating them
happened to be errornous.
From the hardware side, the issue appeared to be caused by a relatively high
power requirements of an external USB adapter connected to the board's printer
dedicated USB port.
I think there is one important point that makes this patch worth of applying,
apart from my hardware quality. With the current code, if it ever happens to
any machine, no matter if OMAP1510 or newer, to read incorrect value from a
McBSP register, this wrong value will get written back without any checking.
That can lead to hardware damage if, for example, an input pin is turned into
output as a result.
Applies on top of patch 3 from this series:
[PATCH v9 3/4] OMAP: McBSP: Introduce caching in register write operations
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next, commit fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11).
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: Peter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
omap: McBSP: Introduce caching in register write operations
Determine cache size required per McBSP port at init time, based on
processor type running on.
Allocate space for storing cached copies of McBSP register values at
port request.
Modify omap_msbcp_write() function to update the cache with every
register write operation.
Modify omap_mcbsp_read() to support reading from cache or hardware.
Update MCBSP_READ() macro for modified omap_mcbsp_read() function API.
Introduce a new macro that reads from the cache.
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next, commit fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11).
Compile-tested with: omap_perseus2_730_defconfig, omap_generic_1610_defconfig,
omap_generic_2420_defconfig, omap_2430sdp_defconfig, omap_3430sdp_defconfig,
omap_4430sdp_defconfig with CONFIG_OMAP_MCBSP=y selected.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: Peter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
omap: McBSP: Modify macros/functions API for easy cache access
OMAP_MCBSP_READ()/_WRITE() macros and omap_mcbsp_read()/_write() functions
accept McBSP register base address as an argument. In order to support
caching, that must be replaced with an address of the omap_mcbsp structure
that would provide addresses for both register AND cache access.
Since OMAP_ prefix seems obvious in macro names, drop it off in order to
minimize line wrapping throughout the file.
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next, commit fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11).
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: Peter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
omap: McBSP: Use macros for all register read/write operations
There are several places where readw()/writew() functions are used instead of
OMAP_MCBSP_READ()/WRITE() macros for manipulating McBSP registers. Replace
them with macros to ensure consistent behaviour after caching is introduced.
Tested on OMAP1510 based Amstrad Delta.
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: Peter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Hiroshi DOYU [Mon, 15 Feb 2010 18:03:32 +0000 (10:03 -0800)]
omap iommu: fix incorrect address for largepage 1st entry
There was a potential risk that the following "memset" could override
its range if a given address was not the 1st entry of a
largepage. This is not the case for "iovmm".
Reported-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Hiroshi DOYU [Mon, 15 Feb 2010 18:03:32 +0000 (10:03 -0800)]
omap: iommu: fix incorrect address for supersection 1st entry
There was a potential risk that the following "memset" could override
its range if a given address was not the 1st entry of a
supersection. This is not the case for "iovmm".
Signed-off-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Tony Lindgren [Fri, 12 Feb 2010 20:26:49 +0000 (12:26 -0800)]
omap2/3: Update omap3_defconfig to build in all the 2420 based boards
Note that booting 2420 depends on another patch posted earlier to not
select CONFIG_CPU_32v6K if CONFIG_ARCH_OMAP2 is selected.
Also note that we cannot add omap2430 in yet because of the different
clock addresses compared to 2420. Also note that we cannot have
CONFIG_CPU_32v6K=y in order to boot on 24xx.
Tony Lindgren [Mon, 15 Feb 2010 17:26:51 +0000 (09:26 -0800)]
omap2/3: Make get_irqnr_and_base common for mach-omap2 multiboot
Make get_irqnr_and_base common for mach-omap2 multiboot
Thanks to a tip from Russell King <rmk+kernel@arm.linux.org.uk>,
this also optimizes the code for non-multiboot configurations by
using get_irqnr_preamble.
Note that this will only work currently for 24xx and 34xx.
Support for 44xx can be added later on for basic multiboot,
and similar patch should be done for mach-omap1/entry-macro.S.
Tony Lindgren [Mon, 15 Feb 2010 16:49:01 +0000 (08:49 -0800)]
omap: Make uncompress code and DEBUG_LL code generic
Define arch_decomp_setup() the same way as some other
architectures do. Use arch_id to configure the debug uart
based on the machine_is by storing it into the uart
scratchpad register for DEBUG_LL code to use.
Tony Lindgren [Mon, 15 Feb 2010 16:48:53 +0000 (08:48 -0800)]
omap: Clean the serial port defines
This way we don't have conflicts with the defines
with compiling in multiple omaps. Set the addresses
for uarts in struct omap_globals for the early serial
init code.
Linus Torvalds [Fri, 12 Feb 2010 17:32:10 +0000 (09:32 -0800)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
drm/i915: hold ref on flip object until it completes
drm/i915: Fix crash while aborting hibernation
drm/i915: Correctly return -ENOMEM on allocation failure in cmdbuf ioctls.
drm/i915: fix pipe source image setting in flip command
drm/i915: fix flip done interrupt on Ironlake
drm/i915: untangle page flip completion
drm/i915: handle FBC and self-refresh better
drm/i915: Increase fb alignment to 64k
drm/i915: Update write_domains on active list after flush.
drm/i915: Rework DPLL calculation parameters for Ironlake
Takashi Iwai [Fri, 12 Feb 2010 17:17:06 +0000 (18:17 +0100)]
ALSA: hda - use WARN_ON_ONCE() for zero-division detection
Replace the zero-division warning message with WARN_ON_ONCE() per the
advice by Linus. This shouldn't happen, but if it happens, it's
possible that the bug happens often due to buggy IRQs.
Kyle McMartin [Fri, 12 Feb 2010 15:53:08 +0000 (10:53 -0500)]
parisc: fix tracing of signals
Mike Frysinger pointed out that calling tracehook_signal_handler with
stepping=0 missed testing the thread flags, resulting in not calling
ptrace_notify. Fix this by testing if we're single stepping or branch
stepping and setting the flag accordingly.
Linus Torvalds [Fri, 12 Feb 2010 16:48:35 +0000 (08:48 -0800)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6:
regulator/lp3971: vol_map out of bounds in lp3971_{ldo,dcdc}_set_voltage()
regulator: Fix display of null constraints for regulators
Roel Kluin [Fri, 12 Feb 2010 11:30:21 +0000 (12:30 +0100)]
regulator/lp3971: vol_map out of bounds in lp3971_{ldo,dcdc}_set_voltage()
After `for (val = LDO_VOL_MIN_IDX; val <= LDO_VOL_MAX_IDX; val++)', if no break
occurs, val reaches LDO_VOL_MIN_IDX + 1, which is out of bounds for
ldo45_voltage_map[] and ldo123_voltage_map[].
Similarly BUCK_TARGET_VOL_MAX_IDX + 1 is out of bounds for buck_voltage_map[].
Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Mark Brown [Thu, 11 Feb 2010 19:20:48 +0000 (19:20 +0000)]
regulator: Fix display of null constraints for regulators
If the regulator constraints are empty and there is no voltage
reported then nothing will be added to the text displayed for the
constraints, leading to random stack data being printed. This is
unlikely to happen for practical regulators since most will at
least report a voltage but should still be fixed.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This patch solves a corner case during allocation which occurs if both
metadata (indirect) and data blocks are required but there is an
obstacle in the filesystem (e.g. a resource group header or another
allocated block) such that when the allocation is requested only
enough blocks for the metadata are returned.
By changing the exit condition of this loop, we ensure that a
minimum of one data block will always be returned.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>