13 Dec, 2011
1 commit
-
Commits 09d28d ("ARM: OMAP: mcbsp: Start generalize omap2_mcbsp_set_clks_src")
and 7bc0c4 ("ARM: OMAP: mcbsp: Start generalize signal muxing functions")
incorrectly set two struct omap_mcbsp_platform_data fields after
omap_device_build_ss and kfree calls.Fix this by moving these pdata assignments before those calls.
Signed-off-by: Jarkko Nikula
Reported-by: NeilBrown
Signed-off-by: Tony Lindgren
05 Oct, 2011
1 commit
-
Remove all these duplicated structures since a default one is now
available.Signed-off-by: Benoit Cousson
Signed-off-by: Kevin Hilman
27 Sep, 2011
6 commits
-
This generalizes the omap2_mcbsp1_mux_clkr_src and omap2_mcbsp1_mux_fsr_src
implementation between generic McBSP and OMAP2 specific McBSP code. These
functions are used to select source for CLKR and FSR signals on OMAP2+.Start generalizing the code by implementing an optional mux_signal function
pointer in platform data that will implement the actual muxing and which is
called now from omap2_mcbsp1_mux_clkr_src and omap2_mcbsp1_mux_fsr_src.
These functions are to be removed later and cleanup the API so that
mux_signal gets its arguments directly from client code.Signed-off-by: Jarkko Nikula
Acked-by: Peter Ujfalusi
Tested-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren -
This generalizes the omap2_mcbsp_set_clks_src implementation between generic
McBSP and OMAP2 specific McBSP code. Currently this function is used to
select either internal fclk or clks pin as a McBSP CLKS source on OMAP2+.Implement generalization by having an optional set_clk_src function pointer
in platform data that is used to select parent for a given clock. Idea is to
pass higher level source clock name (later coming from client driver) that
platform specific code will map to platform specific clock name.API cleanup between McBSP and client code comes later.
Signed-off-by: Jarkko Nikula
Acked-by: Peter Ujfalusi
Tested-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren -
Active sidetone requires that McBSP interface clock doesn't idle and there
is no mechanism in hwmod to turn autoidling on/off in runtime. McBSP2 and 3
in OMAP34xx share their interface clock with McBSP sidetone module and
that interface clock must be active when the sidetone is operating.Sidetone has its own autoidle bit which should keep the interface clock
active but it is broken. Putting the McBSP core to no-idle mode when the
sidetone is active is no good either since it results to higher power
consumption when using the threshold based DMA transfers.For making the McBSP code more generic, move this sidetone clock management
with fixme comments to mach-omap2/mcbsp.c and pass pointer to it via
platform data.Signed-off-by: Jarkko Nikula
Cc: Paul Wamsley
Acked-by: Peter Ujfalusi
Tested-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren -
McBSP transmit and receive configuration control registers must be set up
for OMAP2430 and later. Replace is_omap tests in generic code with a new
feature flag has_ccr in platform data so that there is no need to change
code for any upcoming OMAP version.Signed-off-by: Jarkko Nikula
Acked-by: Peter Ujfalusi
Tested-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren -
Currently wakeup control code is compiled only when CONFIG_ARCH_OMAP3 is
set even it should be available for CONFIG_ARCH_OMAP4 only builds also.Fix this by making wakeup control generic so that it is executed whenever
new feature flag has_wakeup in platform data is set. Currently flag is set
for McBSP config types 3 and 4.Remove also old comments about idle mode settings and HW bug workarounds
that were not updated during hwmod conversion.Signed-off-by: Jarkko Nikula
Acked-by: Peter Ujfalusi
Tested-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren -
Register access can be made more generic by calculating register address
offsets runtime from common register definitions and by using reg_size and
reg_step variables that are passed via platform data. Common register
definitions are possible since McBSP registers are ordered similarly between
OMAP versions.Remove also references to OMAP2+ specific config_type variable from generic
McBSP code since other variables and feature flags are better to carry needed
information from platform code.Signed-off-by: Jarkko Nikula
Acked-by: Peter Ujfalusi
Tested-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren
16 Sep, 2011
1 commit
-
All of the device init and device driver interaction with omap_device
is done using platform_device pointers. To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.All current users of the omap_device pointer were only using it to get
at the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
31 Mar, 2011
1 commit
-
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi
25 Feb, 2011
4 commits
-
After McBSP driver is hwmod adapted, the information about the hw would be
obtained from the hwmod database by the mcbsp driver. Since DMA programming is
handled by the client driver, APIs are provided to pass the DMA channel number
and base address of data register required by the client driver for DMA
programming.Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Charulatha V
Acked-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Acked-by: Mark Brown
Signed-off-by: Tony Lindgren -
Add pm runtime support for McBSP driver.
Reference to fclk is not removed because it is required when the
functional clock is switched from one source to another.Signed-off-by: Kishon Vijay Abraham I
Cc: Paul Walmsley
Acked-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Acked-by: Mark Brown
Signed-off-by: Tony Lindgren -
Modify OMAP2+ McBSP to use omap hwmod framework APIs
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Charulatha V
Signed-off-by: Shubhrajyoti D
Acked-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Acked-by: Mark Brown
Signed-off-by: Tony Lindgren -
Implement McBSP as platform device and add support for
registering through platform device layer using resource
structures.Later in this patch series, OMAP2+ McBSP driver would be modified to
use hwmod framework after populating the omap2+ hwmod database.Signed-off-by: Kishon Vijay Abraham I
Acked-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Acked-by: Mark Brown
Signed-off-by: Tony Lindgren
28 Jan, 2011
1 commit
-
We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest
are nowadays just subcategories of these.Search and replace the following:
ARCH_OMAP2420 SOC_OMAP2420
ARCH_OMAP2430 SOC_OMAP2430
ARCH_OMAP3430 SOC_OMAP3430No functional changes.
Signed-off-by: Tony Lindgren
Signed-off-by: Thomas Weber
Acked-by: Sourav Poddar
09 Oct, 2010
5 commits
-
It seems these comments where accidentally added so remove them.
Signed-off-by: Jarkko Nikula
Acked-by: Paul Walmsley
Acked-by: Peter Ujfalusi -
Fix bit clear. Now it clears all other bits than mask bit where it should
clear only it.Signed-off-by: Jarkko Nikula
Acked-by: Paul Walmsley
Acked-by: Peter Ujfalusi -
Only OMAP2+ platforms have the System Control Module (SCM) IP block.
In the past, we've kept the SCM header file in plat-omap. This has
led to abuse - device drivers including it; includes being added that
create implicit dependencies on OMAP2+ builds; etc.In response, move the SCM headers into mach-omap2/.
As part of this, remove the direct SCM access from the OMAP UDC
driver. It was clearly broken. The UDC code needs an indepth review for
use on OMAP2+ chips.Signed-off-by: Paul Walmsley
Cc: Cory Maccarrone
Cc: Kyungmin Park -
Previously the OMAP McBSP ASoC driver implemented CLKS switching by
using omap_ctrl_{read,write}l() directly. This is against policy; the OMAP
System Control Module functions are not intended to be exported to drivers.
These symbols are no longer exported, so as a result, the OMAP McBSP ASoC
driver does not build as a module.Resolve the CLKS clock changing portion of this problem by creating a
clock parent changing function that lives in
arch/arm/mach-omap2/mcbsp.c, and modify the ASoC driver to use it.
Due to the unfortunate way that McBSP support is implemented in ASoC
and the OMAP tree, this symbol must be exported for use by
sound/soc/omap/omap-mcbsp.c.Going forward, the McBSP device driver should be moved from
arch/arm/*omap* into drivers/ or sound/soc/* and the CPU DAI driver
should be implemented as a platform_driver as many other ASoC CPU DAI
drivers are. These two steps should resolve many of the layering
problems, which will rapidly reappear during a McBSP hwmod/PM runtime
conversions.Signed-off-by: Paul Walmsley
Acked-by: Jarkko Nikula
Acked-by: Peter Ujfalusi
Acked-by: Liam Girdwood
Acked-by: Mark Brown -
The OMAP ASoC McBSP code implemented CLKR and FSR signal muxing via
direct System Control Module writes on OMAP2+. This required the
omap_ctrl_{read,write}l() functions to be exported, which is against
policy: the only code that should call those functions directly is
OMAP core code, not device drivers. omap_ctrl_{read,write}*() are no
longer exported, so the driver no longer builds as a module.Fix the pinmuxing part of the problem by removing calls to
omap_ctrl_{read,write}l() from the OMAP ASoC McBSP code and
implementing signal muxing functions in arch/arm/mach-omap2/mcbsp.c.
Due to the unfortunate way that McBSP support is implemented in ASoC
and the OMAP tree, these symbols must be exported for use by
sound/soc/omap/omap-mcbsp.c.Going forward, the McBSP device driver should be moved from
arch/arm/*omap* into drivers/ or sound/soc/*, and the CPU DAI driver
should be implemented as a platform_driver as many other ASoC CPU DAI
drivers are. These two steps should resolve many of the layering
problems, which will rapidly reappear during a McBSP hwmod/PM runtime
conversion.Signed-off-by: Paul Walmsley
Acked-by: Jarkko Nikula
Acked-by: Peter Ujfalusi
Acked-by: Liam Girdwood
Acked-by: Mark Brown
28 Sep, 2010
1 commit
-
This 'legacy' OMAP2420 McBSP2 muxing code is currently broken after recent
conversion to new mux code. The omap_mcbsp_request calling this code is
usually called after booting whereas the omap_mux_init_signal is __init
marked so null pointer dereference would occur.Fix this by removing the muxing code and let the bootloader or board file to
do it if necessary. Remove also omap2_mcbsp_ops as there is no use for it.Signed-off-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
09 Aug, 2010
1 commit
-
* 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6: (143 commits)
omap: mailbox: reorganize headers
omap: mailbox: standarize on 'omap-mailbox'
omap: mailbox: only compile for configured archs
omap: mailbox: simplify omap_mbox_register()
omap: mailbox: reorganize registering
omap: mailbox: add IRQ names
omap: mailbox: remove unecessary fields
omap: mailbox: don't export unecessary symbols
omap: mailbox: update omap1 probing
omap: mailbox: use correct config for omap1
omap: mailbox: 2420 should be detected at run-time
omap: mailbox: reorganize structures
omap: mailbox: trivial cleanups
omap mailbox: Set a device in logical mbox instance for traceability
omap: mailbox: convert block api to kfifo
omap: mailbox: remove (un)likely macros from cold paths
omap: mailbox cleanup: split MODULE_AUTHOR line
omap: mailbox: convert rwlocks to spinlock
Mailbox: disable mailbox interrupt when request queue
Mailbox: new mutext lock for h/w mailbox configuration
...
05 Jul, 2010
1 commit
-
Convert 2420 platform init code to use new mux code
Signed-off-by: Tony Lindgren
03 Jun, 2010
1 commit
-
Use the actual FIFO size in words as buffer_size on OMAP3.
Change the threshold configuration to use 1 based numbering, when
specifying the allowed threshold maximum or the McBSP threshold value.
Set the default maximum threshold to (buffer_size - 0x10) intialy.
>From users of McBSP, now it is expected to use this method.
Asking for threshold 1 means that the value written to threshold registers
are going to be 0, which means 1 word threshold.Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Acked-by: Mark Brown
Acked-by: Tony Lindgren
Signed-off-by: Liam Girdwood
20 May, 2010
1 commit
-
Conflicts:
sound/soc/codecs/ad1938.c
14 May, 2010
1 commit
-
In OMAP4, there is only one irq line for TX and RX paths. Use
the correct irq line to avoid errors at runtime.Also, request irq line only once (instead of requesting for TX
and RX).Signed-off-by: Jorge Eduardo Candelaria
Acked-by: Jarkko Nikula
Acked-by: Mark Brown
Acked-by: Tony Lindgren
Signed-off-by: Liam Girdwood
30 Mar, 2010
1 commit
-
…it slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
24 Feb, 2010
1 commit
-
Add sidetone feature to McBSP instances 2 and 3 on OMAP3 based devices.
Signed-off-by: Ilkka Koskinen
Acked-by: Peter Ujfalusi
Acked-by: Liam Girdwood
Acked-by: Mark Brown
Tested-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
16 Feb, 2010
2 commits
-
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
Acked-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Signed-off-by: Tony Lindgren -
Replace ARCH_OMAP34XX with ARCH_OMAP3
Signed-off-by: Tony Lindgren
21 Oct, 2009
1 commit
-
Move the remaining headers under plat-omap/include/mach
to plat-omap/include/plat. Also search and replace the
files using these headers to include using the right path.This was done with:
#!/bin/bash
mach_dir_old="arch/arm/plat-omap/include/mach"
plat_dir_new="arch/arm/plat-omap/include/plat"
headers=$(cd $mach_dir_old && ls *.h)
omap_dirs="arch/arm/*omap*/ \
drivers/video/omap \
sound/soc/omap"
other_files="drivers/leds/leds-ams-delta.c \
drivers/mfd/menelaus.c \
drivers/mfd/twl4030-core.c \
drivers/mtd/nand/ams-delta.c"for header in $headers; do
old="#include
15 Sep, 2009
1 commit
-
* 'devel' of master.kernel.org:/home/rmk/linux-2.6-arm: (257 commits)
[ARM] Update mach-types
ARM: 5636/1: Move vendor enum to AMBA include
ARM: Fix pfn_valid() for sparse memory
[ARM] orion5x: Add LaCie NAS 2Big Network support
[ARM] pxa/sharpsl_pm: zaurus c3000 aka spitz: fix resume
ARM: 5686/1: at91: Correct AC97 reset line in at91sam9263ek board
ARM: 5640/1: This patch modifies the support of AC97 on the at91sam9263 ek board
ARM: 5689/1: Update default config of HP Jornada 700-series machines
ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem
ARM: 5688/1: ks8695_serial: disable_irq() lockup
ARM: 5687/1: fix an oops with highmem
ARM: 5684/1: Add nuc960 platform to w90x900
ARM: 5683/1: Add nuc950 platform to w90x900
ARM: 5682/1: Add cpu.c and dev.c and modify some files of w90p910 platform
ARM: 5626/1: add suspend/resume functions to amba-pl011 serial driver
ARM: 5625/1: fix hard coded 4K resource size in amba bus detection
MMC: MMCI: convert realview MMC to use gpiolib
ARM: 5685/1: Make MMCI driver compile without gpiolib
ARM: implement highpte
ARM: Show FIQ in /proc/interrupts on CONFIG_FIQ
...Fix up trivial conflict in arch/arm/kernel/signal.c.
It was due to the TIF_NOTIFY_RESUME addition in commit d0420c83f ("KEYS:
Extend TIF_NOTIFY_RESUME to (almost) all architectures") and follow-ups.
12 Sep, 2009
1 commit
-
Conflicts:
MAINTAINERS
arch/arm/mm/fault.c
10 Sep, 2009
1 commit
-
* topic/asoc: (226 commits)
ASoC: au1x: PSC-AC97 bugfixes
ASoC: Fix WM835x Out4 capture enumeration
ASoC: Remove unuused hw_read_t
ASoC: fix pxa2xx-ac97.c breakage
ASoC: Fully specify DC servo bits to update in wm_hubs
ASoC: Debugged improper setting of PLL fields in WM8580 driver
ASoC: new board driver to connect bfin-5xx with ad1836 codec
ASoC: OMAP: Add functionality to set CLKR and FSR sources in McBSP DAI
ASoC: davinci: i2c device creation moved into board files
ASoC: Don't reconfigure WM8350 FLL if not needed
ASoC: Fix s3c-i2s-v2 build
ASoC: Make platform data optional for TLV320AIC3x
ASoC: Add S3C24xx dependencies for Simtec machines
ASoC: SDP3430: Fix TWL GPIO6 pin mux request
ASoC: S3C platform: Fix s3c2410_dma_started() called at improper time
ARM: OMAP: McBSP: Merge two functions into omap_mcbsp_start/_stop
ASoC: OMAP: Fix setup of XCCR and RCCR registers in McBSP DAI
OMAP: McBSP: Use textual values in DMA operating mode sysfs files
ARM: OMAP: DMA: Add support for DMA channel self linking on OMAP1510
ASoC: Select core DMA when building for S3C64xx
...
21 Aug, 2009
2 commits
-
Do not allow applications to use the full buffer found on
McBSP1,3,4,5. Using the full buffer in threshold mode causes
the McBSP buffer to run dry, which can be observed as channels
are switching (in reality the channels are shifting).Signed-off-by: Peter Ujfalusi
Acked-by: Tony Lindgren
Signed-off-by: Mark Brown -
This patch export through sysfs two properties to configure
maximum threshold for transmission and reception on each
mcbsp instance. Also, it exports two helper functions to
allow mcbsp users to read this values.Signed-off-by: Eduardo Valentin
Acked-by: Tony Lindgren
Signed-off-by: Mark Brown
28 Jul, 2009
1 commit
-
This patch creates McBSP support on OMAP4430 development platform. This patch
includes corresponding base address changes for OMAP4.Signed-off-by: Syed Rafiuddin
26 Jul, 2009
1 commit
-
fix the following 'make includecheck' warning:
arch/arm/mach-omap2/mcbsp.c: mach/irqs.h is included more than once.
Signed-off-by: Jaswinder Singh Rajput
Acked-by: Eduardo Valentin
Acked-by: Kevin Hilman
Signed-off-by: Russell King
11 Jul, 2009
1 commit
-
Remove duplicated #include('s) in
arch/arm/mach-mx3/devices.c
arch/arm/mach-omap1/mcbsp.c
arch/arm/mach-omap2/mcbsp.c
arch/arm/plat-stmp3xxx/pinmux.cSigned-off-by: Huang Weiyi
Signed-off-by: Russell King
09 Feb, 2009
1 commit
-
Rather than introducing a special 'mcbsp_clk' with code behind it in
mach-omap*/mcbsp.c to handle the SoC specifics, arrange for the mcbsp
driver to be like any other driver. mcbsp requests its fck and ick
clocks directly, and the SoC specific code deals with selecting the
correct clock.There is one oddity to deal with - OMAP1 fiddles with the DSP clocks
and DSP reset, so we move this to the two callback functions.Signed-off-by: Russell King