| Age | Commit message (Collapse) | Author |
|---|
|
this patch fixes some clock issues, provides a base 720p dvi panel
and adds the panda_dvi_defconfig for testing purposes.
Signed-off-by: John Stultz <john.stultz@linaro.org>
|
|
Conflicts:
arch/arm/kernel/signal.c
drivers/mmc/card/block.c
drivers/mtd/nand/Kconfig
include/linux/amba/mmci.h
kernel/printk.c
mm/shmem.c
net/socket.c
|
|
Offering CONFIG_PM_SLEEP for CPUs which do not support suspend leads to
build errors, so only set CONFIG_ARCH_SUSPEND_POSSIBLE if we have a CPU
selected which supports suspend.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
|
|
CONFIG_PM is now set whenever we support either runtime PM in addition
to suspend and hibernate. This causes build errors when runtime PM is
enabled on a platform, but the CPU does not have the appropriate support
for suspend.
So, switch this code to use CONFIG_PM_SLEEP rather than CONFIG_PM to
allow runtime PM to be enabled without causing build errors.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
|
|
Remove call to the old GPIO init function.
Fix old MPP control offset value.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Acked-by: Saeed Bishara <saeed.bishara@gmail.com>
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
(cherry picked from commit dc7b602dd481cad61fc4f18874bbdc5b04b5ee3e)
|
|
This patchset adds support for OMAP4 MPU DVFS with following changes
- add vdd information for omap4
- enable all relevant OPPs for MPU VDD
- define and register get_rate and set_rate with DVFS layer
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
This patch adds support for DVFS in cpufreq driver by replacing clock api with
DVFS api.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
On OMAP SMP configuartion, both processors share the voltage
and clock. So both CPUs needs to be scaled together and hence
needs software co-ordination.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
cc: Vishwanath BS <vishwanath.bs@ti.com>
|
|
This patch is an attempt to cleanup the #ifdeferry in the
omap cpufreq drivers.
The split betwenn omap1 and omap2plus is logical because
- omap1 doesn't support opp layer.
- omap1 build is seperate from omap2plus.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Vishwanath BS <vishwanath.bs@ti.com>
|
|
Add an alias clock node for cpu clock control on all OMAP2PLUS devices.
The intention is avoid cpu_is_xxxx() checks in the common cpufreq driver.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
This reverts commit 7feb1d6505144376a since there is another patch set for
omap cpufreq changes at https://patchwork.kernel.org/patch/589081/
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
This patch enables Smartreflex and Cpu Freq in the
omap2plus defconfig.
Signed-off-by: Thara Gopinath <thara@ti.com>
|
|
RIght now voltage layer is initialized as part of core init which is too late
for devices to register with voltage domain as part of hwmod init.
So moving voltage layer initialization as part of common infrastructure init.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
In OMAP3, for perfomrance reasons when VDD1 is at voltage above
1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
patch introduce this cross VDD dependency for OMAP3 VDD1.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
This patch adds voltage domain info in the relevant
device hwmod structures so as to enable OMAP3 DVFS
support.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
Changes in the omap cpufreq driver for DVFS support.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
This patch also introduces omap3_mpu_set_rate, omap3_iva_set_rate,
omap3_l3_set_rate, omap3_mpu_get_rate, omap3_iva_get_rate,
omap3_l3_get_rate as device specific set rate and get rate
APIs for OMAP3 mpu, iva and l3_main devices. This patch also
calls into omap_device_populate_rate_fns during system init to register
various set_rate and get_rate APIs with the omap device layer
Signed-off-by: Thara Gopinath <thara@ti.com>
|
|
This patch disables smartreflex for a particular voltage
domain when the the voltage domain and the devices belonging
to it is being scaled and re-enables it back once the scaling
is done.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
This patch adds omap_device_scale API which can be used to generic
device rate scaling.
Based on original patch from Thara.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Cc: Thara Gopinath <thara@ti.com>
|
|
There could be dependencies between various voltage domains for
maintaining system performance or hardware limitation reasons
like VDD<X> should be at voltage v1 when VDD<Y> is at voltage v2.
This patch introduce dependent vdd information structures in the
voltage layer which can be used to populate these dependencies
for a voltage domain. This patch also adds support to scale
the dependent vdd and the scalable devices belonging to it
during the scaling of a main vdd through omap_voltage_scale.
As part of this, some of the voltage layer structure definitions are moved from
voltage.c to voltage.h as it needs to be used in the dvfs layer for dependency
voltage handling.
Based on original patch from Thara.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Cc: Thara Gopinath <thara@ti.com>
|
|
This patch introduces an API to perform DVFS for a given voltage domain.
It takes omap_vdd_dvfs_info pointer as input parameter, computes the highest
requested voltage for that vdd and scales all the devices in that vdd to the
requested frequency along with voltage scaling.
Based on original patch from Thara.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Cc: Thara Gopinath <thara@ti.com>
|
|
This patch extends the omap_device structure to contain pointers to scale the
operating rate of the device and to retrieve the operating rate of the device.
This patch also adds the three new APIs in the omap device layer
namely omap_device_set_rate that can be called to set a new operating
rate for a device, omap_device_get_rate that can be called to retrieve
the operating frequency for a device and omap_device_register_dvfs_callbacks
to register the device specific set_rate and get_rate functions.
The omap_device_set_rate and omap_device_get_rate does some routine error
checks and finally calls into the device specific set_rate
and get_rate APIs populated through omap_device_populate_rate_fns.
Signed-off-by: Thara Gopinath <thara@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
This patch introduces accessory APIs for DVFS.
Data structures added:
1. omap_dev_user_list: This structure maintains list of frequency requests per
device basis. When a device needs to be scaled to a particular frequency,
This list is searched to find the maximum request for a given device.
If noone has placed any request, device frequency is obtained from device
opp table.
2. omap_vdd_dev_list: This strcucture stores device list per vdd basis.
Whenever a device is registered with a vdd, it is added to this list.
3. omap_vdd_user_list: User list of devices associated with each voltage domain
instance. The user list is implemented using plist structure with priority
node populated with the voltage values.
4. omap_vdd_dvfs_info: This structure is used to abstract DVFS related
information per VDD basis. It holds pointer to corresponding vdd's
voltagedomain instance and pointer to user list.
Following APIs have been added to operate on above data structures:
1. omap_dvfs_add_vdd_user - API to add a user into omap_vdd_user_list
2. omap_vdd_user_list - API to remove a user from omap_vdd_user_list
3. omap_dvfs_register_device - API to register a device with vdd
4. omap_dvfs_add_freq_request - API to add a frequency request into
omap_dev_user_list
5. omap_dvfs_remove_freq_request - API to remove a frequency request from
omap_dev_user_list
6. omap_dvfs_find_voltage - API to find the opp corresponding to given voltage
DVFS layer is initialized and basic data structures are allocated and
initialized as part of this.
This patch is based on Thara's previous DVFS implementation, but with major
rework.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Cc: Thara Gopinath <thara@ti.com>
|
|
DVFS layer will use Voltage layer APIs. So move voltage layer header files to
plat-omap.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
|
|
git://git.secretlab.ca/git/linux-2.6 into linaro-2.6.38
|
|
This patch add support for the Genesi Efika MX Smarttop and Smartbook,
the Freescale mx51 babbage board, and the Freescale mx53 loco board
Signed-off-by: Jason Liu <jason.hui@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Enable basic device tree support for Gumstix Overo.
tested with Overo Tide COM and Tobi expansion board
Signed-off-by: Andy Doan <andy.doan@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Add documentation, make dt_match table __initdata, and include the
skeleton.dtsi file in the device tree.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Check if reserved_pmu is valid before passing it to release_pmu()
|
|
|
|
Conflicts:
arch/arm/kernel/traps.c
arch/arm/mach-omap2/clock34xx.c
arch/arm/mach-omap2/pm34xx.c
|
|
We cannot clock the MMCI blocks more than 50 MHz. A bug prevented
us from seeing the effect of actually driving them to 100 MHz,
which indeed resulted failure, on the external SD card.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
|
|
Adding two sets of I2C devices to the same bus doesn't quite work,
atleast not anymore. Stash one array and determine how much of it
shall be added instead.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
|
|
Note that this relies on stuff currently in mfd's next tree, but this
is also a newer driver. I'm not sure which tree it should go through,
as it's a problem that shows up in next.
From: Andres Salomon <dilinger@queued.net>
MFD changes in c738892f cause the mc13xxx_platform_data struct
to change. This changes one more (new) user of it, fixing a build
error.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
(cherry picked from commit 251290a6078cb88382344b3ee535ae8c6254c1b5)
|
|
GDB's interrupt.exp test cases currenly fail on ARM. The problem is how do_signal
handled restarting interrupted system calls:
The entry.S assembler code determines that we come from a system call; and that
information is passed as "syscall" parameter to do_signal. That routine then
calls get_signal_to_deliver [*] and if a signal is to be delivered, calls into
handle_signal. If a system call is to be restarted either after the signal
handler returns, or if no handler is to be called in the first place, the PC
is updated after the get_signal_to_deliver call, either in handle_signal (if
we have a handler) or at the end of do_signal (otherwise).
Now the problem is that during [*], the call to get_signal_to_deliver, a ptrace
intercept may happen. During this intercept, the debugger may change registers,
including the PC. This is done by GDB if it wants to execute an "inferior call",
i.e. the execution of some code in the debugged program triggered by GDB.
To this purpose, GDB will save all registers, allocate a stack frame, set up
PC and arguments as appropriate for the call, and point the link register to
a dummy breakpoint instruction. Once the process is restarted, it will execute
the call and then trap back to the debugger, at which point GDB will restore
all registers and continue original execution.
This generally works fine. However, now consider what happens when GDB attempts
to do exactly that while the process was interrupted during execution of a to-be-
restarted system call: do_signal is called with the syscall flag set; it calls
get_signal_to_deliver, at which point the debugger takes over and changes the PC
to point to a completely different place. Now get_signal_to_deliver returns
without a signal to deliver; but now do_signal decides it should be restarting
a system call, and decrements the PC by 2 or 4 -- so it now points to 2 or 4
bytes before the function GDB wants to call -- which leads to a subsequent crash.
To fix this problem, two things need to be supported:
- do_signal must be able to recognize that get_signal_to_deliver changed the PC
to a different location, and skip the restart-syscall sequence
- once the debugger has restored all registers at the end of the inferior call
sequence, do_signal must recognize that *now* it needs to restart the pending
system call, even though it was now entered from a breakpoint instead of an
actual svc instruction
This set of issues is solved on other platforms, usually by one of two
mechanisms:
- The status information "do_signal is handling a system call that may need
restarting" is itself carried in some register that can be accessed via
ptrace. This is e.g. on Intel the "orig_eax" register; on Sparc the kernel
defines a magic extra bit in the flags register for this purpose.
This allows GDB to manage that state: reset it when doing an inferior call,
and restore it after the call is finished.
- On s390, do_signal transparently handles this problem without requiring
GDB interaction, by performing system call restarting in the following
way: first, adjust the PC as necessary for restarting the call. Then,
call get_signal_to_deliver; and finally just continue execution at the
PC. This way, if GDB does not change the PC, everything is as before.
If GDB *does* change the PC, execution will simply continue there --
and once GDB restores the PC it saved at that point, it will automatically
point to the *restarted* system call. (There is the minor twist how to
handle system calls that do *not* need restarting -- do_signal will undo
the PC change in this case, after get_signal_to_deliver has returned, and
only if ptrace did not change the PC during that call.)
Because there does not appear to be any obvious register to carry the
syscall-restart information on ARM, we'd either have to introduce a new
artificial ptrace register just for that purpose, or else handle the issue
transparently like on s390. The patch below implements the second option;
using this patch makes the interrupt.exp test cases pass on ARM, with no
regression in the GDB test suite otherwise.
Signed-off-by: Ulrich Weigand <ulrich.weigand@linaro.org>
Signed-off-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Cc: patches@linaro.org
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
|
|
git://git.secretlab.ca/git/linux-2.6 into linaro-2.6.38
|
|
A merge conflict resolution was hidden in mainline commit 2f284c8463.
Let's pick it up to fix build breakage for exynos4_defconfig.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
|
|
|
|
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Enable basic device tree support for Exynos4 smdkv310 board.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
This patch adds a DT_MACHINE_START macro to use instead of
MACHINE_START when creating a machine_desc that supports using the
device tree.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Enable basic device tree support on Pandaboard
Signed-off-by: Grant Likely <grant.likely@linaro.org>
|
|
This patch adds adds very basic support for booting tegra with a
device tree. It simply allows the existing machine_descs to match
against the tegra compatible values so that the kernel can boot.
Kernel parameters and the initrd pointer is read out of the tree
instead of atags.
This is not complete device tree support. This change will be
reverted when a new machine_desc is added that can populate the
device registrations directly from data in the tree instead of using
hard coded data. That change will be made in a future patch.
v2: Fixed cut-and-paste error in commit text
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
This patch adds adds very basic support for booting versatile with a
device tree. It simply allows the existing machine_descs to match
against the versatile ab & pb compatible values so that the kernel can
boot. Kernel parameters and the initrd pointer is read out of the
tree instead of atags.
This is not complete device tree support. This change will be
reverted when a new machine_desc is added that can populate the
versatile device registrations directly from data in the tree instead
of using hard coded data. That change will be made in a future patch.
v5: - Add skeleton device tree for versatile AB and PB. Bare minimum needed
for booting.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Add a make rule to compile dt blobs for ARM.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Tested-by: Jason Liu <jason.hui@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
If a dtb is passed to the kernel then the kernel needs to iterate
through compiled-in mdescs looking for one that matches and move the
dtb data to a safe location before it gets accidentally overwritten by
the kernel.
This patch creates a new function, setup_machine_fdt() which is
analogous to the setup_machine_atags() created in the previous patch.
It does all the early setup needed to use a device tree machine
description.
v5: - Print warning with neither dtb nor atags are passed to the kernel
- Fix bug in setting of __machine_arch_type to the selected machine,
not just the last machine in the list.
Reported-by: Tixy <tixy@yxit.co.uk>
v4: - Dump some output when a matching machine_desc cannot be found
v3: - Added processing of reserved list.
- Backed out the v2 change that copied instead of reserved the
dtb. dtb is reserved again and the real problem was fixed by
using alloc_bootmem_align() for early allocation of RAM for
unflattening the tree.
- Moved cmd_line and initrd changes to earlier patch to make series
bisectable.
v2: Changed to save the dtb by copying into an allocated buffer.
- Since the dtb will very likely be passed in the first 16k of ram
where the interrupt vectors live, memblock_reserve() is
insufficient to protect the dtb data.
[based on work originally written by Jeremy Kerr <jeremy.kerr@canonical.com>]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
In preparation for adding device tree support, this patch consolidates
all of the atag-specific setup into a single function.
v5: - drop double printk("Machine; %s\n", ...); call.
v4: - adapt to the removal of lookup_machine_type()
- break out dump of machine_desc table into dump_machine_table()
because the device tree probe code will use it.
- Add for_each_machine_desc() macro
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Add some basic empty infrastructure for DT support on ARM.
v5: - Fix off-by-one error in size calculation of initrd
v3: - moved cmd_line export and initrd setup to this patch to make the
series bisectable.
- switched to alloc_bootmem_align() for allocation when
unflattening the device tree. memblock_alloc() was not the
right interface.
Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
The dtb is passed to the kernel via register r2, which is the same
method that is used to pass an atags pointer. This patch modifies
__vet_atags to not clear r2 when it encounters a dtb image.
v2: fixed bugs pointed out by Nicolas Pitre
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
This patch implements an alternate method for using device tree data
for populating machine device registration. Traditionally, board
support has directly generated and registered devices based on nodes
in the device tree. The board support code starts at the root of the
tree and begins allocating devices for each device node it finds.
Similarly, bus drivers (i2c, spi, etc.) use their child nodes to
register child devices. This model can be seen in almost all the powerpc
board ports (arch/powerpc/platforms/*).
However, for many of the ARM SoCs, there already exists complete board
support for many SoCs that have their own code for registering the
basic set of platform devices with non-trivial dependencies on clock
structure and machine specific platform code. While starting at the
base of the tree and working up is certainly possible, it requires
modifying a lot of machine support code to get it working.
This patch adds the function of_platform_prepare() to declare which
nodes will be used to create platform_devices without actually
creating them yet. Then it uses a bus notifier to inspect
platform_device registrations. If any match a node declared with
of_platform_prepare(), it will set the of_node pointer before the
device gets bound to a driver, making the device tree data available
at probe time.
After all the static devices are registered, the platform code can
still call either of_platform_populate or of_platform_bus_probe() on
the same nodes that were declared with of_platform_prepare(). Any
nodes that *were not* matched to a static platform_device will get
created in the normal way.
Note: Board ports using this facility are still required to provide a
fully populated device tree blob. It is not a shortcut to providing
an accurate device tree model of the machine to the point that it
would be reasonably possible to switch to a direct registration model
for all devices without change the device tree. ie. The SoC still
needs to be correctly identified and there should be nodes for all the
discrete devices.
v2: Complete revamp to make of_platform_populate() and
of_platform_bus_probe() respect the prepared nodes.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
