| Age | Commit message (Collapse) | Author |
|---|
|
Simplify the UART setup code so that it no longer loops for each UART
present. Just make it do all the work it needs in a single function.
This will make the code easier to share when we move to a single set
of platform data for ColdFire UARTs.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
Simplify the UART setup code so that it no longer loops for each UART
present. Just make it do all the work it needs in a single function.
This will make the code easier to share when we move to a single set
of platform data for ColdFire UARTs.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 54xx UART addressing so that:
. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 5407 UART addressing so that:
. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 532x UART addressing so that:
. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 528x UART addressing so that:
. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 5307 UART addressing so that:
. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 527x UART addressing so that:
. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 5272 UART addressing so that:
. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 5249 UART addressing so that:
. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 523x UART addressing so that:
. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 520x UART addressing so that:
. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.
So modify the ColdFire 5206 UART addressing so that:
. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
The MMU and non-MMU varients of the m68k arch process.c code are pretty
much the same. Only a few minor details differ between the two. The
majority of the difference is to deal with having or wanting hardware FPU
support. So merge them back into a single process.c file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
|
|
The classic m68k code has always supported an FPU (although it may have
been a software emulated one). The non-MMU m68k code has never supported FPU
hardware. To help in merging common code create a configation setting that
signifies if we are builing in FPU support or not.
This switch, CONFIG_FPU, is set as per the current use cases. So it is
always enabled if CONFIG_MMU is set, and disabled otherwise. With a little
extra code it will be possible to disable it on the classic m68k platforms
as well, and to enable it on non-MMU platforms that do have hardware FPU.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
|
|
Most of the code in the non-mmu ptrace_no.c file is the same as the mmu
version ptrace_mm.c. So merge them back into a single file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
|
|
The set_rtc_mmss() function is defined "static inline" but is never used
in this file. Remove it.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
|
|
There is only trivial differences between the mmu time_mm.c and non-mmu
time_no.c files. Merge them back into a single time.c.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
|
|
The CONFIG_GENERIC_CMOS_UPDATE switch is always enabled for the non-MMU
m68k case. But the underlying code to support it, update_persistent_clock(),
doesn't end up doing anything on the currently supported non-MMU platforms.
No platforms supply the necessary function support for writing back the RTC.
So lets remove this option and support code. This also brings m68knommu
in line with the m68k, which doesn't enabled this switch either.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
With a few small changes we can make the m68knommu timer init code the
same as the m68k code. By using the mach_sched_init function pointer
and reworking the current timer initializers to keep track of the common
m68k timer_interrupt() handler we end up with almost identical code for
m68knommu.
This will allow us to more easily merge the mmu and non-mmu m68k time.c
in future patches.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
The read_persistent_clock() code is different on m68knommu, for really no
reason. With a few changes to support function names and some code
re-organization the code can be made the same.
This will make it easier to merge the arch/m68k/kernel/time.c for m68k and
m68knommu in a future patch.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
The base of the real RAM resident hardware vectors, _ramvec, is declared in
our asm/traps.h. No need to have local declarations spread around in other
files that use this. So remove them.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
There is a lot of years of collected cruft in the m68knommu linker script.
Clean it all up and use the well defined linker script support macros.
Support is maintained for building both ROM/FLASH based and RAM based setups.
No major changes to section layouts, though the rodata section is now lumped
in with the read/write data section.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
The ColdFire MBAR register that holds the mapping of the peripheral region
on some ColdFire CPUs is configurable. It can be configured at some address
different to that of the bootloader that loaded the kernel. So hard set
the MBAR register mapping at kernel startup time.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
|
|
* pm-qos:
PM / QoS: unconditionally build the feature
PM / QoS: Simplify PM QoS expansion/merge
|
|
* pm-domains:
PM / Domains: Fix include for PM_GENERIC_DOMAINS=n case
PM / Domains: Provide a dummy dev_gpd_data() when generic domains are not used
PM / Domains: Run late/early device suspend callbacks at the right time
ARM: EXYNOS: Hook up power domains to generic power domain infrastructure
PM / Domains: Add OF support
|
|
* pm-sleep:
PM / Freezer: Remove references to TIF_FREEZE in comments
PM / Sleep: Add more wakeup source initialization routines
PM / Hibernate: Enable usermodehelpers in hibernate() error path
PM / Sleep: Make __pm_stay_awake() delete wakeup source timers
PM / Sleep: Fix race conditions related to wakeup source timer function
PM / Sleep: Fix possible infinite loop during wakeup source destruction
PM / Hibernate: print physical addresses consistently with other parts of kernel
PM: Add comment describing relationships between PM callbacks to pm.h
PM / Sleep: Drop suspend_stats_update()
PM / Sleep: Make enter_state() in kernel/power/suspend.c static
PM / Sleep: Unify kerneldoc comments in kernel/power/suspend.c
PM / Sleep: Remove unnecessary label from suspend_freeze_processes()
PM / Sleep: Do not check wakeup too often in try_to_freeze_tasks()
PM / Sleep: Initialize wakeup source locks in wakeup_source_add()
PM / Hibernate: Refactor and simplify freezer_test_done
PM / Hibernate: Thaw kernel threads in hibernation_snapshot() in error/test path
PM / Freezer / Docs: Document the beauty of freeze/thaw semantics
PM / Suspend: Avoid code duplication in suspend statistics update
PM / Sleep: Introduce generic callbacks for new device PM phases
PM / Sleep: Introduce "late suspend" and "early resume" of devices
|
|
* pm-devfreq:
PM / devfreq: add min/max_freq limit requested by users.
PM / devfreq: fixed syntax errors.
devfreq: Remove MODULE_ALIAS for exynos4 busfreq driver
devfreq: exynos4_bus: Use dev_get_drvdata at appropriate places
|
|
Fix pm_genpd_init() arguments and make sure dev_gpd_data() and
simple_qos_governor exist regardless of CONFIG_PM_GENERIC_DOMAINS
setting.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
This patch removes all the references in the code about the TIF_FREEZE
flag removed by commit a3201227f803ad7fd43180c5195dbe5a2bf998aa
freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE
There still are some references to TIF_FREEZE in
Documentation/power/freezing-of-tasks.txt, but it looks like that
documentation needs more thorough work to reflect how the new
freezer works, and hence merely removing the references to TIF_FREEZE
won't really help. So I have not touched that part in this patch.
Suggested-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Marcos Paulo de Souza <marcos.mage@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
The existing wakeup source initialization routines are not
particularly useful for wakeup sources that aren't created by
wakeup_source_create(), because their users have to open code
filling the objects with zeros and setting their names. For this
reason, introduce routines that can be used for initializing, for
example, static wakeup source objects.
Requested-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
If create_basic_memory_bitmaps() fails, usermodehelpers are not re-enabled
before returning. Fix this. And while at it, reword the goto labels so that
they look more meaningful.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
If __pm_stay_awake() is called after __pm_wakeup_event() for the same
wakep source object before its timer expires, it won't cancel the
timer, so the wakeup source will be deactivated from the timer
function as scheduled by __pm_wakeup_event(). In that case
__pm_stay_awake() doesn't have any effect beyond incrementing
the wakeup source's event_count field, although it should cancel
the timer and make the wakeup source stay active until __pm_relax()
is called for it.
To fix this problem make __pm_stay_awake() delete the wakeup source's
timer and ensure that it won't be deactivated from the timer funtion
afterwards by clearing its timer_expires field.
Reported-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
If __pm_wakeup_event() has been used (with a nonzero timeout) to
report a wakeup event and then __pm_relax() immediately followed by
__pm_stay_awake() is called or __pm_wakeup_event() is called once
again for the same wakeup source object before its timer expires, the
timer function pm_wakeup_timer_fn() may still be run as a result of
the previous __pm_wakeup_event() call. In either of those cases it
may mistakenly deactivate the wakeup source that has just been
activated.
To prevent that from happening, make wakeup_source_deactivate()
clear the wakeup source's timer_expires field and make
pm_wakeup_timer_fn() check if timer_expires is different from zero
and if it's not in future before calling wakeup_source_deactivate()
(if timer_expires is 0, it means that the timer has just been
deleted and if timer_expires is in future, it means that the timer
has just been rescheduled to a different time).
Reported-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
If wakeup_source_destroy() is called for an active wakeup source that
is never deactivated, it will spin forever. To prevent that from
happening, make wakeup_source_destroy() call __pm_relax() for the
wakeup source object it is about to free instead of waiting until
it will be deactivated by someone else. However, for this to work
it also needs to make sure that the timer function will not be
executed after the final __pm_relax(), so make it run
del_timer_sync() on the wakeup source's timer beforehand.
Additionally, update the kerneldoc comment to document the
requirement that __pm_stay_awake() and __pm_wakeup_event() must not
be run in parallel with wakeup_source_destroy().
Reported-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
This patch adds missed "__" prefixes, otherwise these functions
works as irq/preemption safe.
Reported-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Even if cards supports 1.8V I/O voltage those should anyway be
initialized at 3.3V I/O according to (e)MMC, SD and SDIO specs.
Some eMMC and embedded SDIO devices are able to be initialized
at 1.8V as well, but it is better to be safe.
Do note that initialization in this context means that the card
has been completely powered off, otherwise the card will remain
at the last I/O voltage level that were negotitiated.
Due to the above being taken care of the suspend/resume issues
for UHS-I SD-cards has been fixed.
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Acked-by: Philip Rakity <prakity@marvell.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
|
On a system with large pages (64k in my case), the following BUG is
triggered in MMC core:
[ 2.338023] BUG: failure at drivers/mmc/core/core.c:221/mmc_start_request()!
[ 2.338102] Kernel panic - not syncing: BUG!
[ 2.338155] Call trace:
[ 2.338228] [<ffffffc00008635c>] dump_backtrace+0x0/0x120
[ 2.338317] [<ffffffc0003365ec>] dump_stack+0x14/0x1c
[ 2.338403] [<ffffffc000336990>] panic+0xbc/0x1f0
[ 2.338498] [<ffffffc00027a494>] mmc_start_request+0x154/0x184
[ 2.338600] [<ffffffc00027abdc>] mmc_start_req+0x110/0x140
[ 2.338701] [<ffffffc00028604c>] mmc_blk_issue_rw_rq+0x7c/0x39c
[ 2.338804] [<ffffffc00028652c>] mmc_blk_issue_rq+0x1c0/0x468
[ 2.338905] [<ffffffc000287564>] mmc_queue_thread+0x68/0x118
[ 2.338995] [<ffffffc0000bc308>] kthread+0x84/0x8c
This is because of a 64k request with a max_req_size of 64k-1 bytes.
The following patch fixes the problem by limiting the max_blk_count
such that max_blk_count * max_blk_size == max_req_size. I couldn't
pursuade the compiler to emit a shift instead of a div without encoding
the shift explicitly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
|
On i.MX53 we have to write a special SDHCI_CMD_ABORTCMD to the
SDHCI_TRANSFER_MODE register during a MMC_STOP_TRANSMISSION
command. This works for SD cards. However, with MMC cards
the MMC_SET_BLOCK_COUNT command is used instead, but this
needs the same handling. Fix MMC cards by testing for the
MMC_SET_BLOCK_COUNT command aswell. Tested on a custom i.MX53
board with a Transcend MMC+ card and eMMC.
The kernel started used MMC_SET_BLOCK_COUNT in 3.0, so this
is a regression for these boards introduced in 3.0; it should
go to 3.0/3.1/3.2-stable.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
|
A recent commit "mmc: core: Use delayed work in clock gating framework"
(597dd9d79cfbbb1) introduced a default 200ms delay before clock gating
actually takes place. This means that every time an MMC interface
becomes idle it first stays on for 200ms before gating its clock. This
leads to increased power consumption and is therefore a clear regression.
This patch restores the original behaviour by setting the default delay
to 0. Users prioritising throughput over power efficiency can still
modify the delay via sysfs.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
|
Modify MAINTAINERS entry for Atmel SD/MMC drivers.
I hand the atmel-mci and at91_mci drivers over to Ludovic.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
A driver specific fix that wasn't noticed as the OpenMoko guys have been
stuck on 2.6.39 for a very long time now and are just starting to catch
up again.
|
|
Without that fix the wm8753 SPI initialization fails, and then produces
a kernel panic during boot with the following call trace:
Unable to handle kernel paging request at virtual address 37386d9b
[<c01ccafc>] (regmap_get_val_bytes+0x0/0x14) from [<c0243dfc>] (snd_soc_codec_set_cache_io+0x9c/0xcc)
[<c0243dfc>] (snd_soc_codec_set_cache_io+0x9c/0xcc) from [<c0244a4c>] (wm8753_probe+0x5c/0x1c4)
[<c0244a4c>] (wm8753_probe+0x5c/0x1c4) from [<c023bb24>] (soc_probe_codec+0x174/0x284)
[<c023bb24>] (soc_probe_codec+0x174/0x284) from [<c023c2c0>] (snd_soc_instantiate_cards+0x68c/0xe28)
[<c023c2c0>] (snd_soc_instantiate_cards+0x68c/0xe28) from [<c023d278>] (snd_soc_register_card+0x240/0x2d4)
[<c023d278>] (snd_soc_register_card+0x240/0x2d4) from [<c023d330>] (soc_probe+0x24/0x40)
[<c023d330>] (soc_probe+0x24/0x40) from [<c01c3900>] (platform_drv_probe+0x14/0x18)
[...]
The commit d3398ff05907167f463e119421b053ce043741d1
( ASoC: Convert WM8753 to direct regmap API usage ) introduced
the problem.
Thanks to Lars-Peter Clausen for helping me a bit during the debugging.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
The neo1973 driver had wrong codec name which prevented the "sound card"
from appearing.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
|
|
There's now core code which falls back to global CODEC operations for
DAI calls that needs to be able to tell if it's dealing with a CPU or
CODEC DAI and given the small number of DAIs in a typical system and
overall memory usage pattern saving a pointer per DAI is really not
worth the effort.
Reported-by: Ian Lartey <ian@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
|
|
It moves and renames sgtl5000 device tree binding document to make
it aligned with other codecs.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
SND_SOC_AC97_BUS is selected to enable the AC97 support in soc-core.
Rather than selecting the option under SND_IMX_SOC, it's better to
leave the selection to individual machine driver which knows if AC97
support is needed or not.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
It's not necessary for imx-pcm-dma-mx2 to access imx_ssi.dma_params
for burstsize initialization. Instead, it can just be done in imx-ssi
probe function once.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Push everything through one function for active use cases, should be
no practical effect.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
If we're not doing jackdet it's not needed.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
