27 Sep, 2011
9 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 -
Sidetone resource is already registered for a device so there is no need
for cpu_is_omap34xx() and McBSP port number tests in the driver. We can
cleanup and make the code generic by dropping remaining CONFIG_ARCH_OMAP3
conditional compilations and then using sidetone resource and st_data
variable for runtime tests.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 -
Rationale here is to remove one global variable and to make possible to have
variable size McBSP register maps inside SoC.Signed-off-by: Jarkko Nikula
Acked-by: Peter Ujfalusi
Tested-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren -
Remove CONFIG_ARCH_OMAP3 conditional compilation and cpu_is_omap34xx test
around buffer threshold based transfer and DMA operating mode control. Use
instead the buffer_size in platform data to determine when these sysfs
controls are exposed and when to access related McBSP registers. Rationale
for this is to make code generic and to allow to use it on OMAP4 that also
supports threshold based transfers.Currently buffer_size variable is set only for OMAP3 SoCs but it is easy
to extend to OMAP4 and any later OMAP version.Signed-off-by: Jarkko Nikula
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
-
struct omap_device *od is only set with find_omap_device_by_dev but not used
otherwise so remove them and references to omap device API.Acked-by: Kevin Hilman
Signed-off-by: Jarkko Nikula
11 Jul, 2011
1 commit
-
After commits d13586574d373ef40acd4725c9a269daa355e412 ("OMAP: McBSP:
implement functional clock switching via clock framework") and
cf4c87abe238ec17cd0255b4e21abd949d7f811e ("OMAP: McBSP: implement
McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c"), any OMAP1
board (such as the AMS Delta) that uses the ASoC McBSP driver will no
longer build:sound/built-in.o: In function `omap_mcbsp_dai_set_dai_sysclk':
last.c:(.text+0x24ff8): undefined reference to `omap2_mcbsp1_mux_clkr_src'
last.c:(.text+0x2500c): undefined reference to `omap2_mcbsp1_mux_fsr_src'
make: *** [vmlinux] Error 1Fix by defining three OMAP1-only dummy functions for
omap2_mcbsp1_mux_clkr_src(), omap2_mcbsp1_mux_fsr_src(), and
omap2_mcbsp_set_clks_src().Normally, code that is OMAP SoC-revision-specific like this should go
under the arch/arm/*omap* directories, and get abstracted away from
drivers via struct platform_data function pointers. This doesn't work
in this case since there doesn't appear to be any convenient way to access
struct platform_data (or something like it) in the current design of
the sound/soc/omap/omap-mcbsp.c driver.Reported by Janusz Krzysztofik and Tony Lindgren
. Janusz also posted a patch to fix this at:http://www.spinics.net/lists/linux-omap/msg39560.html
(among other places), but the following approach seems less dependent
on compiler behavior.This patch passes build tests for ams_delta_defconfig and omap2plus_defconfig,
but since I don't have an AMS Delta here, I can't boot test it on that
platform.Signed-off-by: Paul Walmsley
Cc: Janusz Krzysztofik
Cc: Tony Lindgren
Cc: Jarkko Nikula
Cc: Peter Ujfalusi
Cc: Mark Brown
Cc: Liam Girdwood
Signed-off-by: Tony Lindgren
08 Jul, 2011
1 commit
-
These variables got unused after ("omap: mcbsp: Drop in-driver transfer
support") but was noticed only afterwards.Signed-off-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
29 Jun, 2011
2 commits
-
We haven't seen either use for in-driver transfer API in McBSP driver
over the years so it looks they can be removed too.Signed-off-by: Jarkko Nikula
Signed-off-by: Tony Lindgren -
We haven't seen any use for the SPI API in McBSP driver over the years. More
over, Peter Ujfalusi noticed that SPI mode is not
even supported since OMAP2430 so it's very unlikely that we'll see any use
for it in the future either.Signed-off-by: Jarkko Nikula
Acked-by: Peter Ujfalusi
Signed-off-by: Tony Lindgren
31 Mar, 2011
1 commit
-
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi
25 Feb, 2011
5 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 -
McBSP2/3 in OMAP3 has sidetone feature which requires autoidle
to be disabled before starting the sidetone. Also SYSCONFIG
register has to be set with smart idle or no idle depending on the
dma op mode (threshold or element sync). For doing these operations
dynamically at runtime, omap_device APIs are used to modify SYSCONFIG register.Signed-off-by: Kishon Vijay Abraham I
Cc: Paul Walmsley
Acked-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Acked-by: Mark Brown
[tony@atomide.com: updated to compile without omap_device idle calls]
Signed-off-by: Tony Lindgren -
Added a name to address space belonging to SDMA and MPU facilitating
the driver to get the address space info by name. Added a revision
member inorder to facilitate the driver to differentiate between
mcbsp in different omap.
Also added a platform_get_irq in probe to get irq number by index since
from OMAP4, there will be a single irq line.Signed-off-by: Benoit Cousson
Signed-off-by: Kishon Vijay Abraham I
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
22 Dec, 2010
2 commits
-
Now that OMAP4-specific PRCM functions have been added, distinguish the
existing OMAP2/3-specific PRCM functions by prefixing them with "omap2_".This patch should not result in any functional change.
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
Cc: Jarkko Nikula
Cc: Peter Ujfalusi
Cc: Liam Girdwood
Cc: Mark Brown
Tested-by: Santosh Shilimkar
Tested-by: Rajendra Nayak -
In preparation for adding OMAP4-specific PRCM accessor/mutator
functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
OMAP2xxx/3xxx-specific.This process also requires the #includes in each of these files to be
changed to reference the new file name. As part of doing so, add some
comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
"sideways includes", to indicate that these users of the PRM/CM includes
should not be doing so.Thanks to Felipe Contreras for comments on this
patch.Signed-off-by: Paul Walmsley
Cc: Jarkko Nikula
Cc: Peter Ujfalusi
Cc: Liam Girdwood
Cc: Omar Ramirez Luna
Acked-by: Omar Ramirez Luna
Cc: Felipe Contreras
Acked-by: Felipe Contreras
Cc: Greg Kroah-Hartman
Acked-by: Mark Brown
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
Tested-by: Rajendra Nayak
Tested-by: Santosh Shilimkar
08 Dec, 2010
2 commits
-
Using true/false instead of 1/0 to update the free variable.
Signed-off-by: Shubhrajyoti D
Acked-by: Jarkko Nikula
Signed-off-by: Tony Lindgren -
Function omap_mcbsp_probe allocates struct omap_mcbsp *mcbsp but it is not
freed in omap_mcbsp_remove. Fix this, remove unneeded structure cleanups
and clk_disable calls since they are not needed here.This is not problem currently but becomes if the mcbsp driver is ever
modularized.Signed-off-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
26 Oct, 2010
1 commit
-
* 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6: (163 commits)
omap: complete removal of machine_desc.io_pg_offst and .phys_io
omap: UART: fix wakeup registers for OMAP24xx UART2
omap: Fix spotty MMC voltages
ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h
serial: omap-serial: fix signess error
OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish
omap: dma: Fix buffering disable bit setting for omap24xx
omap: serial: Fix the boot-up crash/reboot without CONFIG_PM
OMAP3: PM: fix scratchpad memory accesses for off-mode
omap4: pandaboard: enable the ehci port on pandaboard
omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set
omap4: pandaboard: remove unused hsmmc definition
OMAP: McBSP: Remove null omap44xx ops comment
OMAP: McBSP: Swap CLKS source definition
OMAP: McBSP: Fix CLKR and FSR signal muxing
OMAP2+: clock: reduce the amount of standard debugging while disabling unused clocks
OMAP: control: move plat-omap/control.h to mach-omap2/control.h
OMAP: split plat-omap/common.c
OMAP: McBSP: implement functional clock switching via clock framework
OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c
...Fixed up trivial conflicts in arch/arm/mach-omap2/
{board-zoom-peripherals.c,devices.c} as per Tony
09 Oct, 2010
4 commits
-
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 -
This patch fixes sparse warnings due non declarations of static functions.
arch/arm/plat-omap/sram.c:130:13: warning: symbol 'omap_detect_sram' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:216:13: warning: symbol 'omap_map_sram' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:450:12: warning: symbol 'omap_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:348:12: warning: symbol 'omap242x_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:369:12: warning: symbol 'omap243x_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:425:12: warning: symbol 'omap34xx_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:441:12: warning: symbol 'omap44xx_sram_init' was not declared. Should it be staticarch/arm/plat-omap/mcbsp.c:36:6: warning: symbol 'omap_mcbsp_write' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:50:5: warning: symbol 'omap_mcbsp_read' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:65:6: warning: symbol 'omap_mcbsp_st_write' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:70:5: warning: symbol 'omap_mcbsp_st_read' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:1648:15: warning: symbol 'omap_st_add' was not declared. Should it be static?arch/arm/plat-omap/fb.c:414:15: warning: symbol 'omapfb_reserve_sram' was not declared. Should it be static?
arch/arm/plat-omap/cpu-omap.c:43:5: warning: symbol 'omap_verify_speed' was not declared. Should it be static?
arch/arm/plat-omap/cpu-omap.c:61:14: warning: symbol 'omap_getspeed' was not declared. Should it be static?Signed-off-by: Manjunath Kondaiah G
Cc: linux-arm-kernel@lists.infradead.org
Cc: Nishanth Menon
Signed-off-by: Tony Lindgren
28 Sep, 2010
1 commit
-
McBSP SRG (Sample Rate Generator) and FSG (Frame Sync
Generator) is only needed to be enabled, when McBSP
is master.
In McBSP slave mode, the SRG, and FSG can be kept disabled,
which might save some power at the end in this configuration.Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
24 Sep, 2010
1 commit
-
Looks like a typo from commit d6d834b010.
Signed-off-by: Scott Ellis
Acked-by: Peter Ujfalusi
Signed-off-by: Tony Lindgren
03 Jun, 2010
3 commits
-
Sicne the platform data's buffer_size now holds the full size
of the FIFO, there is no longer need to handle the ports
differently.Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Acked-by: Mark Brown
Acked-by: Tony Lindgren
Signed-off-by: Liam Girdwood -
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 -
Users of McBSP can use the omap_mcbsp_get_fifo_size function to query
the size of the McBSP FIFO.
The function will return the FIFO size in words (the HW maximum).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
2 commits
-
McBSP module in OMAP4 needs to be able to set its tx/rx threshold
and enable the transmitter/receiver when starting an audio stream.Signed-off-by: Jorge Eduardo Candelaria
Signed-off-by: Margarita Olaya Cabrera
Acked-by: Mark Brown
Acked-by: Tony Lindgren
Signed-off-by: Liam Girdwood -
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>
23 Mar, 2010
1 commit
13 Mar, 2010
1 commit
-
The MsBSP register cache will never have any error/status flags set, since
these flags are never written to the reg_cache. So it is kind of not
necessary to clear these flags, which are actually always 0.In other words, clearing the status/error flags are not necessary, since the
reg_cache will never got these bits set. We can just write back the
register content from the cache as it is when clearing an error condition.Tested on Amstrad Delta.
Reported-by: Peter Ujfalusi
Signed-off-by: Janusz Krzysztofik
Acked-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
