From Tony Lindgren:
Few more legacy booting vs device tree booting fixes that people
have noticed while booting things with device tree for things like
omap4 WLAN, smsc911x, and beagle audio. Hopefully this will be it
for the legacy booting vs device tree fixes for this -rc cycle.
* tag 'omap-for-v3.13/more-dt-regressions' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: Fix the name of supplies for smsc911x shared by OMAP
ARM: OMAP2+: Powerdomain: Fix unchecked dereference of arch_pwrdm
ARM: dts: omap3-beagle: Add omap-twl4030 audio support
ARM: dts: omap4-sdp: Fix pin muxing for wl12xx
ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx
BeagleBone Black uses the TI CPSW ethernet controller, enable it in the
multi_v7_defconfig for testing coverage purposes.
Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: stable@vger.kernel.org # v3.12
From Nicolas Ferre:
AT91: second round of fixes for 3.13
- reduce IP frequency for I2C on sama5d3
- missing aliases directive for USART3 on 9x5 family
- a PM symbol is missing if !CONFIG_PM
* tag 'at91-fixes' of git://github.com/at91linux/linux-at91:
ARM: at91: fixed unresolved symbol "at91_pm_set_standby" when built without CONFIG_PM
ARM: at91: add usart3 alias to dtsi
ARM: at91: sama5d3: reduce TWI internal clock frequency
From Jason Cooper, mvebu DT fixes for v3.13:
- mvebu
- PCIe fixes now that we have test devices with more ports.
- fix access to coherency registers
* tag 'mvebu-dt-fixes-3.13' of git://git.infradead.org/linux-mvebu:
ARM: mvebu: re-enable PCIe on Armada 370 DB
ARM: mvebu: use the virtual CPU registers to access coherency registers
ARM: mvebu: fix second and third PCIe unit of Armada XP mv78260
ARM: mvebu: second PCIe unit of Armada XP mv78230 is only x1 capable
From Tony Lindgren:
Some omap related fixes that have come up with people moving to device
tree only based booting for omap2+.
The series contains a handful of fixes for the igep boards as they were
one of the first omap3 boards to jump over completely to device tree
based booting. So these can be considered regressions compared to
booting igep in legacy mode with board files in v3.12.
Also included are few other device tree vs legacy booting regressions:
- yet more missing omap3 .dtsi entries that have showed up booting
various boards with device tree only
- n900 eMMC device tree fix
- fixes for beagle USB EHCI
- two fixes to make omap2420 MMC work
As we're moving omap2+ to be device tree only for v3.14, I'd like to
have v3.13 work equally well for legacy based booting and device tree
based booting. So there will be likely few more device tree related
booting patches trickling in.
This series also includes a regression fix for the omap timer posted
mode that may wrongly stay on from the bootloader for some SoCs.
* tag 'omap-for-v3.13/fixes-against-rc1-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
mmc: omap: Fix I2C dependency and make driver usable with device tree
mmc: omap: Fix DMA configuration to not rely on device id
ARM: dts: omap3-beagle: Fix USB host on beagle boards (for 3.13)
ARM: dts: omap3-igep0020: name twl4030 VPLL2 regulator as vdds_dsi
ARM: dts: AM33XX IGEP0033: add USB support
ARM: dts: AM33XX BASE0033: add 32KBit EEPROM support
ARM: dts: AM33XX BASE0033: add pinmux and user led support
ARM: dts: AM33XX BASE0033: add pinmux and hdmi node to enable display
ARM: dts: omap3-igep0020: Add pinmuxing for DVI output
ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices
ARM: dts: omap3-igep: Update to use the TI AM/DM37x processor
ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO
ARM: dts: omap3-igep: Fix bus-width for mmc1
ARM: OMAP2+: dss-common: change IGEP's DVI DDC i2c bus
ARM: OMAP2+: Disable POSTED mode for errata i103 and i767
ARM: OMAP2+: Fix eMMC on n900 with device tree
ARM: OMAP2+: Add fixed regulator to omap2plus_defconfig
ARM: OMAP2+: Fix more missing data for omap3.dtsi file
Signed-off-by: Olof Johansson <olof@lixom.net>
Added usage id processing for Inclinometer 3D. This uses IIO
interfaces for triggered buffer to present data to user
mode.This uses HID sensor framework for registering callback
events from the sensor hub.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
There are already humidity sensors in the hwmon subsystem,
so we use their unit (milli percent) here as well.
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fixes the following warnings from sparse:
drivers/staging/iio/frequency/ad9834.c:45:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9834.c:45:26: expected unsigned short [unsigned] [short] <noident>
drivers/staging/iio/frequency/ad9834.c:45:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9834.c:47:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9834.c:47:26: expected unsigned short [unsigned] [short] <noident>
drivers/staging/iio/frequency/ad9834.c:47:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9834.c:59:18: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9834.c:59:18: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9834.c:59:18: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9834.c💯26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9834.c💯26: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9834.c💯26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9834.c:108:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9834.c:108:26: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9834.c:108:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9834.c:122:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9834.c:122:26: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9834.c:122:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9834.c:131:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9834.c:131:26: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9834.c:131:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9834.c:194:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9834.c:194:26: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9834.c:194:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9834.c:387:18: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9834.c:387:18: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9834.c:387:18: got restricted __be16 [usertype] <noident>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fixes the following warnings from sparse:
drivers/staging/iio/frequency/ad9832.c:43:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:43:26: expected unsigned short [unsigned] [short] <noident>
drivers/staging/iio/frequency/ad9832.c:43:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9832.c:46:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:46:26: expected unsigned short [unsigned] [short] <noident>
drivers/staging/iio/frequency/ad9832.c:46:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9832.c:49:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:49:26: expected unsigned short [unsigned] [short] <noident>
drivers/staging/iio/frequency/ad9832.c:49:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9832.c:52:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:52:26: expected unsigned short [unsigned] [short] <noident>
drivers/staging/iio/frequency/ad9832.c:52:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9832.c:65:27: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:65:27: expected unsigned short [unsigned] [short] <noident>
drivers/staging/iio/frequency/ad9832.c:65:27: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9832.c:68:27: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:68:27: expected unsigned short [unsigned] [short] <noident>
drivers/staging/iio/frequency/ad9832.c:68:27: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9832.c:107:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:107:26: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9832.c:107:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9832.c:120:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:120:26: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9832.c:120:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9832.c:133:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:133:26: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9832.c:133:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9832.c:144:26: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:144:26: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9832.c:144:26: got restricted __be16 [usertype] <noident>
drivers/staging/iio/frequency/ad9832.c:277:18: warning: incorrect type in assignment (different base types)
drivers/staging/iio/frequency/ad9832.c:277:18: expected unsigned short [unsigned] data
drivers/staging/iio/frequency/ad9832.c:277:18: got restricted __be16 [usertype] <noident>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use new ATTRIBUTE_GROUPS macro to declare attribute groups.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Currently the IIO buffer interface only allows non-blocking reads. This patch
adds support for blocking IO. In blocking mode the thread will go to sleep if no
data is available and will wait for the buffer implementation to signal that new
data is available by waking up the buffers waitqueue.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch implements the data_available() callback for the kfifo buffer instead
of using the stufftoread flag. The kfifo used by the buffer already knows
whether it is empty or not based on the position of its read and write pointer.
Using this makes it a lot easier to tell whether data is available or not and it
is not necessary to take special measures to ensure that no race conditions
between reading and writing from the buffer occur.
Note, that we still have to take the buffers lock to protect against concurrent
resizeing of the kfifo.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch adds a new data_available() callback to the iio_buffer_access_funcs
struct. The callback is used to indicate whether data is available in the buffer
for reading. It is meant to replace the stufftoread flag from the iio_buffer
struct. The reasoning for this is that the buffer implementation usually can
determine whether data is available rather easily based on its state, on the
other hand it can be rather tricky to update the stufftoread flag in a race free
way.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some I2C controllers might not be able to handle transfer buffers that are
stored on stack.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fixes the following warnings from sparse:
drivers/staging/iio/cdc/ad7746.c:599:25: warning: cast to restricted __be32
drivers/staging/iio/cdc/ad7746.c:599:25: warning: cast to restricted __be32
drivers/staging/iio/cdc/ad7746.c:599:25: warning: cast to restricted __be32
drivers/staging/iio/cdc/ad7746.c:599:25: warning: cast to restricted __be32
drivers/staging/iio/cdc/ad7746.c:599:25: warning: cast to restricted __be32
drivers/staging/iio/cdc/ad7746.c:599:25: warning: cast to restricted __be32
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some I2C controllers may not be able to handle transfer buffers that are placed
on the stack.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fixes the following warnings from sparse:
drivers/iio/light/vcnl4000.c:88:16: warning: cast to restricted __be16
drivers/iio/light/vcnl4000.c:88:16: warning: cast to restricted __be16
drivers/iio/light/vcnl4000.c:88:16: warning: cast to restricted __be16
drivers/iio/light/vcnl4000.c:88:16: warning: cast to restricted __be16
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fixes the following warnings from sparse:
drivers/iio/adc/ad7266.c:140:16: warning: cast to restricted __be16
drivers/iio/adc/ad7266.c:140:16: warning: cast to restricted __be16
drivers/iio/adc/ad7266.c:140:16: warning: cast to restricted __be16
drivers/iio/adc/ad7266.c:140:16: warning: cast to restricted __be16
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some SPI controllers may not be able to handle transfer buffers that are placed
on the stack.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Some SPI controllers may not be able to handle transfer buffers that are placed
on the stack.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The ioctl is (at least currently) mandatory.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The pad::get_fmt call must be protected by a mutex, but preparing its
arguments doesn't need to be. Move the non-critical code out of the
mutex-protected section.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Translating -ENOIOCTLCMD to -EINVAL is invalid, the correct ioctl return
value is -ENOTTY.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The remote subdev of any video node in the OMAP4 ISS is an internal
subdev that is guaranteed to implement get_fmt. Don't check the return
value for -ENOIOCTLCMD, as this can't happen.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Get rid of a goto statement for a simple error path that can be inlined,
and split spaghetti error code to a separate section.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The iss_device structure is allocated with kzalloc, there's no need to
initialize its fields to 0 explicitly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Loop counters that can only take positive values should be unsigned.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The functions always succeed, there's no need to return an error value.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The only udelay() call takes place in a sleepable context, we can sleep
instead. Use usleep_range().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The failure variable is initialized with 0 and used as a return value
without ever being modified. Remove it and return 0 directly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The video_unregister_device() function checks if the video device is
registered before proceeding, remote the duplicate check from the
driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The vb2 queue already keeps track of the streaming state, there's no
need to duplicate that in the driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Code common to all cases can be moved out of the switch...case
statement.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using the extended control API internally to get the sensor
pixel rate, use the dedicated in-kernel APIs (find the control with
v4l2_ctrl_find() and get its value with v4l2_ctrl_g_ctrl_int64()).
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds and updates Kconfig's and Makefile's, as well as a TODO
list.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds resizer support.
[Port the driver to v3.12-rc3, including the following changes
- Don't include plat/ headers
- Don't use cpu_is_omap44xx() macro
- Don't depend on EXPERIMENTAL
- Fix s_crop operation prototype
- Update link_notify prototype
- Rename media_entity_remote_source to media_entity_remote_pad]
Signed-off-by: Sergio Aguirre <sergio.a.aguirre@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds the IPIPEIF and IPIPE processing blocks support.
Signed-off-by: Sergio Aguirre <sergio.a.aguirre@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds CSI receivers support.
Signed-off-by: Sergio Aguirre <sergio.a.aguirre@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds video devices support.
Signed-off-by: Sergio Aguirre <sergio.a.aguirre@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds the driver core, registers definitions and
documentation.
Signed-off-by: Sergio Aguirre <sergio.a.aguirre@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
