The type field of VIDIOC_CROPCAP does not allow the MPLANE variants, just
as all the other crop/selection related ioctls.
Fix the description of CROPCAP and G_CROP and make the text describing
this consistent for all selection ioctls.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The documentation is not clear whether this is a three or four byte
format. Clarify this.
Also move the BGR666 format to the other 32 bit formats.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Sequential top-bottom/bottom-top fields are not supported as video loopback.
This is too much work to implement for field settings that are rarely used.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The colorspace section IDs were assigned to the title instead of to the
section. Some links failed because of that.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The documentation says that the bytesperline field in v4l2_pix_format refers
to the largest plane in the case of planar formats (i.e. multiple planes
stores in a single buffer).
For almost all planar formats the first plane is also the largest (or equal)
plane, except for two formats: V4L2_PIX_FMT_NV24/NV42. For this YUV 4:4:4
format the second chroma plane is twice the size of the first luma plane.
Looking at the very few drivers that support this format the bytesperline
value that they report is actually that of the first plane and not that
of the largest plane.
Rather than fixing the drivers it makes more sense to update the documentation
since it is very difficult to use the largest plane for this. You would have
to check what the format is in order to know to which plane bytesperline
belongs, which makes calculations much more difficult.
This patch updates the documentation accordingly.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
In contrast to all other colorspaces, the BT.2020 colorspace uses
limited range R'G'B' quantization as the default.
This was incorrected documented, so fix this.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The denominator for the scaling and offsets is 256, not 255. Fix this.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Add lane-polarity property to endpoint nodes. This essentially tells that
the order of the differential signal wires is inverted.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Add a list of available module parameters as attachment to the
documentation.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Reformat the existing documentation to have more structure. This allows
for more documentation seperated from the existing paragraphs.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
This adds support for the AM-800480R3TMQW-A1H 7" 800x480 panel to the
DRM simple panel driver.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This adds support for the COM43H4M85ULC 3.7" 800x480 panel to the
DRM simple panel driver.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The AUO b101ean01 panel is a 10.1" 1280x800 panel which can be supported
by the simple panel driver.
Signed-off-by: Huang Lin <hl@rock-chips.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Innolux ZJ070NA-01P is a 7.0" TFT LCD panel with an integrated LED
backlight unit.
This panel is used on the Technexion Toucan.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Innolux AT043TN24 4.3" WQVGA TFT LCD panel.
This panel with backlight is found in PDA 4.3" LCD screen (TM43xx series for
instance).
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Shelly SCA07010-BFN-LNN is a 7.0" WVGA TFT LCD panel.
This panel with backlight is found in PDA 7" LCD screen (TM70xx series for
instance).
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This panel is used by the Nyan Blaze board and can be supported by the
simple-panel driver.
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
[tomeu.vizoso@collabora.com: add device tree binding document]
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Documentation: DT bindings: Tegra AHB: require the legacy base address for existing chips
Per Stephen Warren, note in the Tegra AHB DT binding documentation
that we specifically deprecate any attempt to use the IP block's
actual hardware base address, and advocate the use of the legacy
"off-by-four" address in the 'regs' property, for Tegra chips with
existing upstream Linux DT files that include a Tegra AHB node. This
patch updates the documentation accordingly.
Changing the existing kernel DT data isn't under consideration because
Linux kernel DT data policy is to preserve compatibility between newer
DT data files and older kernels. However, this additional step of
changing the documentation should discourage others from sending
kernel patches to try to change the legacy kernel DT data.
Furthermore, for out-of-tree software (such as bootloaders or other
operating systems) that may rely on Linux kernel DT binding
documentation as an ABI (but not the Linux kernel DT data itself),
such a change may allow future convergence with the Linux kernel DT
data without additional code changes.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Paul Walmsley <pwalmsley@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The eMMC on a tablet I've will stop working / communicating as soon as
the kernel executes:
mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_HPI_MGMT, 1,
card->ext_csd.generic_cmd6_time);
There seems to be no way to reliable identify eMMC-s which have a broken
hpi implementation, but at least for eMMC's which are soldered onto a board
we can work around this by specifying that hpi is broken in devicetree.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Merge "at91: multiplatform for 4.1 #1" from Nicolas Ferre:
This is the multi-platform support for AT91:
- reworked arch/arm/mach-at91/Kconfig and arch/arm/Kconfig to switch to
multi-platform
- updated at91_dt_defconfig
- continue the cleanup of unneeded files and code chunks
* tag 'at91-multiplatform' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91: (61 commits)
ARM: at91: drop AT91_TIMER_HZ
ARM: at91: remove hardware.h
ARM: at91: remove SoC headers
ARM: at91: remove useless mach/cpu.h
ARM: at91: remove unused headers
ARM: at91: switch at91_dt_defconfig to multiplatform
ARM: at91: switch to multiplatform
ARM: at91: remove useless include
clocksource: atmel-st: remove mach/hardware dependency
clocksource: atmel-st: use syscon/regmap
ARM: at91: time: move the system timer driver to drivers/clocksource
ARM: at91: properly initialize timer
ARM: at91: at91rm9200: remove deprecated arm_pm_restart
watchdog: at91rm9200: implement restart handler
watchdog: at91rm9200: use the system timer syscon
mfd: syscon: Add atmel system timer registers definition
ARM: at91/dt: declare atmel,at91rm9200-st as a syscon
ARM: at91: remove old setup
ARM: at91: sama5d4: remove useless map_io
ARM: at91: sama5 use SoC detection infrastructure
...
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "ARM: rockchip: dts changes for 4.1" from Heiko Stuebner:
This adds and enables the usbphy nodes on the rk3288 boards and enables
the gmac on the firefly board. A new board the Popmetal-rk3288 is also
added. And finally the pmic supplies for act8846 based boards are added,
as the act8865/act8846 driver gained supply handling in the regulator tree.
* tag 'v4.1-rockchip-dts1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
ARM: dts: rockchip: complete rk3288-evb pmic supplies
ARM: dts: rockchip: add input supplies for the act8846 on Radxa Rock
ARM: dts: add rk3288 PopMetal board
dt-bindings: add root compatible property for PopMetal board
ARM: dts: rockchip: enable gmac on rk3288-firefly
ARM: dts: rockchip: enable usbphy on rk3288-firefly
ARM: dts: rockchip: Enable usb PHY on rk3288-evb board
ARM: dts: rockchip: add rk3288 usb PHY
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "qcom SoC changes for v4.1" from Kumar Gala:
Qualcomm ARM Based SoC Updates for v4.1
* Merged the based Qualcomm SCM and SCM boot support
* Cleaned up SCM interface to only expose functional SCM APIs
* Moved Qualcomm SCM code into drivers/firmware
* Updated the SCM APIs for setting cpu cold and warm boot addresses
* Added support for ADM CRCI muxing
* tag 'qcom-soc-for-4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom:
soc: qcom: gsbi: Add support for ADM CRCI muxing
firmware: qcom: scm: Support cpu power down through SCM
firmware: qcom: scm: Add qcom_scm_set_warm_boot_addr function
firmware: qcom: scm: Clean cold boot entry to export only the API
firmware: qcom: scm: Move the scm driver to drivers/firmware
ARM: qcom: Prep scm code for move to drivers/firmware
ARM: qcom: Cleanup scm interface to only export what is needed
ARM: qcom: Merge scm and scm boot code together
Signed-off-by: Olof Johansson <olof@lixom.net>
As part of testing ahci_st driver working on stih407 I noticed
several things wrong in the DT documentation: -
1) Compatible string doesn't match the driver code
2) pwr-rst reset isn't documented (but exists in the driver)
3) some whitespace issues (spaces not tabs)
Also add in a stih407 family example into the doc.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The example is wrong in that the phys property should take a
phandle to the phy port.
Also with the changing over to generic PHY type constants we also
update that as well.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
BCM3384/BCM63xx can use the common drivers/irqchip/irq-bcm7120-l2.c for
this purpose; BCM7xxx will use drivers/irqchip/irq-bcm7038-l1.c. We no
longer need this code under arch/mips.
[ralf@linux-mips.org: Fix conflicts.]
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Cc: f.fainelli@gmail.com
Cc: jaedon.shin@gmail.com
Cc: abrestic@chromium.org
Cc: tglx@linutronix.de
Cc: jason@lakedaemon.net
Cc: jogo@openwrt.org
Cc: arnd@arndb.de
Cc: computersforpeace@gmail.com
Cc: linux-mips@linux-mips.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/8853/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Pull EFI updates from Matt Fleming:
- Fixes and cleanups for SMBIOS 3.0 DMI code. (Ivan Khoronzhuk)
- A new efi=debug command line option that enables debug output in the
EFI boot stub and results in less verbose EFI memory map output by
default. (Borislav Petkov)
- Disable interrupts around EFI calls and use a more standard page
table saving and restoring idiom when making EFI calls. (Ingo Molnar)
- Reduce the number of memory allocations performed when allocating the
FDT in EFI boot stub by retrieving size from the FDT header in the
EFI config table. (Ard Biesheuvel)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Chanwoo writes:
Update extcon for v4.1
This patchset include two new extcon driver and fix minor issue of extcon
driver.
Detailed description for patchset:
1. new extcon-max77843.c and extcon-usb-gpio.c extcon driver
- extcon-max77843.c driver support the MAXIM MAX77843 MUIC (Micor-USB Interface
Controller) device which handles the various external connectors such as TA/USB
/USB-HOST/JIG and so on.
- extcon-usb-gpio.c driver support the USB and USB-HOST cable detection by
using the GPIO pin which is connected to USB ID pin. This GPIO pin updates the
USB cable states.
2. Rename the filename of extcon core driver and add missing locking mechanism
- Rename the previous extcon-class driver.c as extcon.c because '-class'
postfix is not necessary word.
- extcon core driver (extcon.c) used the raw_notifier_chain. It must be
protected by locking mechanism to avoid the list changing while
extcon_update_state() is executed.
3. Fix minor issue of extcon drviers
- Fix cable name by using the capital letter instead of small letter on
extcon-max77693.c driver.
- Clean-up code of extcon-arizona.c to detect headphone cable.
- Fix the wrong return type and variable type on extcon-max77843.c.
- Fix the checkpatch warning of all extcon drivers.
