remove usage of CONFIG_ARCH_MX1. It's mostly unused anyway, replace
it with cpu_is_mx1() where necessary. Also, depend on
IMX_HAVE_PLATFORM_IMX_FB instead of the architectures directly.
LAKML-Reference: 20110303141244.GQ29521@pengutronix.de
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
There is no need for using a MX51-specific version of imx_add_gpio_keys.
Remove imx51_add_gpio_keys and use imx_add_gpio_keys instead.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
LAKML-Reference: 1302105926-20574-1-git-send-email-fabio.estevam@freescale.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The platform id is used to determine the spi bus number, so it should
better be different to the ids used for imx51-ecspi. Otherwise it's not
possible to use both devices "imx51-cspi.0" and "imx51-ecspi.0".
Alternative approaches are to use dynamic bus numbering as offered by
the spi framework or let the machine code set the bus number. The
downside of both possibilities is that the bus number isn't fixed for
the same busses on different machines using i.MX51.
LAKML-Reference: 1302100716-21034-1-git-send-email-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
For consistency mxs has to be repeated, one for the name space and
another one for the device name.
LAKML-Reference: 1300308028-8922-1-git-send-email-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The defines for the i2c related irqs (MX23_INT_I2C_DMA and
MX23_INT_I2C_ERROR) already match the reference manual. So make the base
address consistent.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
LAKML-Reference: 1298049507-6987-2-git-send-email-w.sang@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
... together with the related devices "mx3_camera" and "mx3_sdc_fb".
"mx3_camera" doesn't fit the scheme of the other devices that just are
allocated and registered in a single function because it needs additional
care to get some dmaable memory. So currently imx31_alloc_mx3_camera
duplicates most of imx_add_platform_device_dmamask, but I'm not sure it's
worth to split the latter to be able to reuse more code.
This gets rid of mach-mx3/devices.[ch] and so several files need to be
adapted not to #include devices.h anymore.
LAKML-Reference: 1299271882-2130-5-git-send-email-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
It's not allowed to create an alias of system RAM for DMA. So the memory
used must not be allocated using dma_alloc_coherent but has to be reserved
before using memblock routines.
There is no need to memzero the buffer because dma_alloc_coherent zeros
the memory for us.
LAKML-Reference: 1299271882-2130-4-git-send-email-u.kleine-koenig@pengutronix.de
Tested-by: Philippe Retornaz <philippe.retornaz@epfl.ch>
Acked-by: Philippe Retornaz <philippe.retornaz@epfl.ch>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
There is no need to memzero the buffer because dma_alloc_coherent zeros
the memory for us.
This fixes:
BUG: Your driver calls ioremap() on system memory. This leads
<4>to architecturally unpredictable behaviour on ARMv6+, and ioremap()
<4>will fail in the next kernel release. Please fix your driver.
Tested-by: Michael Grzeschik <mgr@pengutronix.de>
LAKML-Reference: 1299271882-2130-3-git-send-email-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Current code does not set the GPIO value to zero as mentioned in the comment.
Fix it by setting the initial GPIO value to zero.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
LAKML-Reference: 1301427910-31726-1-git-send-email-fabio.estevam@freescale.com
[ukleinek: squashed two patches together fixing both boards at once]
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Most machine files include "devices-imxXX.h" which in turn includes
<mach/devices-common.h>. The latter already includes many headers
that the machine files don't need to include again.
These were found by:
$ grep \#include arch/arm/plat-mxc/include/mach/devices-common.h > tmpfile
$ git grep -l 'devices-imx' arch/arm | xargs grep -f tmpfile -F
(but I kept linux/init.h, linux/kernel.h and linux/platform_device.h)
LAKML-Reference: 1298912674-15153-2-git-send-email-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Current code inside babbage_usbhub_reset uses gpio_direction_output with initial value of the GPIO and also sets
the GPIO value via gpio_set_value to the same level right after. This is not needed.
By using gpio_request_one it is possible to set the direction and initial value in one shot.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
LAKML-Reference: 1300377359-23212-2-git-send-email-fabio.estevam@freescale.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Having the silicon revision to appear on the boot log is a useful information.
MX31, MX35 and MX51 already show the silicon revision on boot.
Add support for displaying such information for MX53 as well.
Tested on a mx53loco board, where it shows:
CPU identified as i.MX53, silicon rev 2.0
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
LAKML-Reference: 1301068367-18937-1-git-send-email-fabio.estevam@freescale.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas. As a
result, using these directives in code sections can result in
misaligned data words when building a Thumb-2 kernel
(CONFIG_THUMB2_KERNEL).
This is a Bad Thing, since the ABI permits the compiler to
assume that fundamental types of word size or above are word-
aligned when accessing them from C. If the data is not really
word-aligned, this can cause impaired performance and stray
alignment faults in some circumstances.
In general, the following rules should be applied when using
data word declaration directives inside code sections:
* .quad and .double:
.align 3
* .long, .word, .single, .float:
.align (or .align 2)
* .short:
No explicit alignment required, since Thumb-2
instructions are always 2 or 4 bytes in size.
immediately after an instruction.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
LAKML-Reference: 1289913217-8672-1-git-send-email-dave.martin@linaro.org
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
For the lcdif clock get_rate looks as follows:
read div from HW_CLKCTRL_DIS_LCDIF.DIV
return clk_get_rate(clk->parent) / div
with clk->parent being ref_pix_clk on my system.
ref_pix_clk's rate depends on HW_CLKCTRL_FRAC1.PIXFRAC.
The set_rate function for lcdif does:
parent_rate = clk_get_rate(clk->parent);
based on that calculate frac and div such that
parent_rate * 18 / frac / div is near the requested rate.
HW_CLKCTRL_FRAC1.PIXFRAC is updated with frac
HW_CLKCTRL_DIS_LCDIF.DIV is updated with div
For this calculation to be correct parent_rate needs to be
initialized not with the clock rate of lcdif's parent (i.e. ref_pix) but
that of its grandparent (i.e. ref_pix' parent == pll0_clk).
The obvious downside of this patch is that now set_rate(lcdif) changes
its parent's rate, too. Still this is better than a wrong rate.
Acked-by: Shawn Guo <shawn.guo@freescale.com>
LAKML-Reference: 20110225084950.GA13684@S2101-09.ap.freescale.net
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This was broken by
4bd597b (ARM i.MX ehci: do ehci init in board specific functions)
and fixes:
CC arch/arm/mach-mx3/mach-vpr200.o
arch/arm/mach-mx3/mach-vpr200.c:263: error: unknown field 'flags' specified in initializer
arch/arm/mach-mx3/mach-vpr200.c:264: warning: initialization makes pointer from integer without a cast
by just applying the change to mach-vpr200.c that the other machine files
got by 4bd597b.
LAKML-Reference: 1302257029-17397-1-git-send-email-u.kleine-koenig@pengutronix.de
Acked-by: Marc Reilly <marc@cpdesign.com.au>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block:
ide: always ensure that blk_delay_queue() is called if we have pending IO
block: fix request sorting at unplug
dm: improve block integrity support
fs: export empty_aops
ide: ide_requeue_and_plug() reinstate "always plug" behaviour
blk-throttle: don't call xchg on bool
ufs: remove unessecary blk_flush_plug
block: make the flush insertion use the tail of the dispatch list
block: get rid of elv_insert() interface
block: dump request state on seeing a corrupted request completion
On an error path in inotify_init1 a normal user can trigger a double
free of struct user. This is a regression introduced by a2ae4cc9a1
("inotify: stop kernel memory leak on file creation failure").
We fix this by making sure that if a group exists the user reference is
dropped when the group is cleaned up. We should not explictly drop the
reference on error and also drop the reference when the group is cleaned
up.
The new lifetime rules are that an inotify group lives from
inotify_new_group to the last fsnotify_put_group. Since the struct user
and inotify_devs are directly tied to this lifetime they are only
changed/updated in those two locations. We get rid of all special
casing of struct user or user->inotify_devs.
Signed-off-by: Eric Paris <eparis@redhat.com>
Cc: stable@kernel.org (2.6.37 and up)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Just because we are not requeuing a request does not mean that
some aren't pending. So always issue a blk_delay_queue() if
either we are requeueing OR there's pending IO.
This fixes a boot problem for some IDE boxes.
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Comparison function for list_sort() must be anticommutative,
otherwise it is not sorting in ordinary meaning.
But fortunately list_sort() always check ((*cmp)(priv, a, b) <= 0)
it not distinguish negative and zero, so comparison function can
implement only less-or-equal instead of full three-way comparison.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
The current block integrity (DIF/DIX) support in DM is verifying that
all devices' integrity profiles match during DM device resume (which
is past the point of no return). To some degree that is unavoidable
(stacked DM devices force this late checking). But for most DM
devices (which aren't stacking on other DM devices) the ideal time to
verify all integrity profiles match is during table load.
Introduce the notion of an "initialized" integrity profile: a profile
that was blk_integrity_register()'d with a non-NULL 'blk_integrity'
template. Add blk_integrity_is_initialized() to allow checking if a
profile was initialized.
Update DM integrity support to:
- check all devices with _initialized_ integrity profiles match
during table load; uninitialized profiles (e.g. for underlying DM
device(s) of a stacked DM device) are ignored.
- disallow a table load that would result in an integrity profile that
conflicts with a DM device's existing (in-use) integrity profile
- avoid clearing an existing integrity profile
- validate all integrity profiles match during resume; but if they
don't all we can do is report the mismatch (during resume we're past
the point of no return)
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
With the ->sync_page() hook gone, we have a few users that
add their own static address_space_operations without any
functions defined.
fs/inode.c already has an empty_aops that it uses for init
purposes. Lets export that and use it in the places where
an otherwise empty aops was defined.
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
We see stalls if we don't always ensure that the queue gets run
again. Even if rq == NULL, we could have other pending requests
in the queue.
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
xchg does not work portably with smaller than 32bit types.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
We already flush the per-process plugging list when context switching,
so a blk_flush_plug call just before a yield() is not needed.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
It's not a preempt type request, in fact we have to insert it
behind requests that do specify INSERT_FRONT.
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Merge it with __elv_add_request(), it's pretty pointless to
have a function with only two callers. The main interface
is elv_add_request()/__elv_add_request().
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Currently we just dump a non-informative 'request botched' message.
Lets actually try and print something sane to help debug issues
around this.
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc/pseries: Fix build without CONFIG_HOTPLUG_CPU
powerpc: Set nr_cpu_ids early and use it to free PACAs
powerpc/pseries: Don't register global initcall
powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP.
edac/mpc85xx: Limit setting/clearing of HID1[RFXE] to e500v1/v2 cores
powerpc/85xx: Update dts for PCIe memory maps to match u-boot of Px020RDB
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable:
Btrfs: don't warn in btrfs_add_orphan
Btrfs: fix free space cache when there are pinned extents and clusters V2
Btrfs: Fix uninitialized root flags for subvolumes
btrfs: clear __GFP_FS flag in the space cache inode
Btrfs: fix memory leak in start_transaction()
Btrfs: fix memory leak in btrfs_ioctl_start_sync()
Btrfs: fix subvol_sem leak in btrfs_rename()
Btrfs: Fix oops for defrag with compression turned on
Btrfs: fix /proc/mounts info.
Btrfs: fix compiler warning in file.c
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (27 commits)
ipv6: Don't pass invalid dst_entry pointer to dst_release().
mlx4: fix kfree on error path in new_steering_entry()
tcp: len check is unnecessarily devastating, change to WARN_ON
sctp: malloc enough room for asconf-ack chunk
sctp: fix auth_hmacs field's length of struct sctp_cookie
net: Fix dev dev_ethtool_get_rx_csum() for forced NETIF_F_RXCSUM
usbnet: use eth%d name for known ethernet devices
starfire: clean up dma_addr_t size test
iwlegacy: fix bugs in change_interface
carl9170: Fix tx aggregation problems with some clients
iwl3945: disable hw scan by default
wireless: rt2x00: rt2800usb.c add and identify ids
iwl3945: do not deprecate software scan
mac80211: fix aggregation frame release during timeout
cfg80211: fix BSS double-unlinking (continued)
cfg80211:: fix possible NULL pointer dereference
mac80211: fix possible NULL pointer dereference
mac80211: fix NULL pointer dereference in ieee80211_key_alloc()
ath9k: fix a chip wakeup related crash in ath9k_start
mac80211: fix a crash in minstrel_ht in HT mode with no supported MCS rates
...
This is a revert of 428d2e828c.
This is broken in the same manner as for VGA: trying to write to an
invalid address on the (currently 7-bit) i2c bus.
One notable failure appears to be for MacBooks. The scary part was that
it gave the appearance of working (i.e. reporting the absence of the
panel) on various all-in-one machines with ghost LVDS panels and not
failing for laptops.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is a moral revert of 6ec3d0c0e9.
Following the fix to reset the GMBUS controller after a NAK, we finally
utilize the 0xa0 probe for a CRT connection. And discover that the code
is broken. Shock.
There are a number of issues, but following a key insight from Dave
Airlie, that 0xA0 is an invalid address on a 7-bit bus (though not if we
were to enable 10-bit addressing), and would look like the EDID port
0x50, it is possible to see where the confusion starts.
In short, a write to 0xA0 is accepted by the GMBUS controller which we
interpreted as meaning the existence of a connection (a slave on the
other end of the wire ACKing the write). That was false.
During testing with a broken GMBUS implementation, which never reset an
earlier NAK, this test always reported a NAK and so we proceeded on to
the next test.
Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35904
Reported-and-tested-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32612
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Keith Packard <keithp@keithp.com>
Commit b3df895aeb "powerpc/kexec: Add support for FSL-BookE"
introduced the original PPC_STD_MMU_64 checks around the function
crash_kexec_wait_realmode(). Then commit c2be05481f
"powerpc: Fix default_machine_crash_shutdown #ifdef botch" changed
the ifdef around the calling site to add a check on SMP, but the
ifdef around the function itself was left unchanged, leaving an
unused function for PPC_STD_MMU_64=y and SMP=n
Rather than have two ifdefs that can get out of sync like this,
simply put the corrected conditional around the function and use
a stub to get rid of one set of ifdefs completely.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
When I moved the orphan adding to btrfs_truncate I missed the fact that during
orphan cleanup we just add the orphan items to the orphan list without going
through btrfs_orphan_add, which results in lots of warnings on mount if you have
any orphan items that need to be truncated. Just remove this warning since it's
ok, this will allow all of the normal space accounting take place. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
I noticed a huge problem with the free space cache that was presenting
as an early ENOSPC. Turns out when writing the free space cache out I
forgot to take into account pinned extents and more importantly
clusters. This would result in us leaking free space everytime we
unmounted the filesystem and remounted it.
I fix this by making sure to check and see if the current block group
has a cluster and writing out any entries that are in the cluster to the
cache, as well as writing any pinned extents we currently have to the
cache since those will be available for us to use the next time the fs
mounts.
This patch also adds a check to the end of load_free_space_cache to make
sure we got the right amount of free space cache, and if not make sure
to clear the cache and re-cache the old fashioned way.
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
