The page flip event is armed in the atomic begin handler, creating a
race condition with the frame end interrupt that could send the event
before the atomic operation actually completes. To avoid that, arm the
event in the atomic flush handler after queuing the page flip.
This change doesn't fully close the race window, as the frame end
interrupt could be generated before the page flip is committed to
hardware but only handled after the event is armed. However, the race
window is now much smaller.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
When pinctrl device registers, it automatically claims hogs, that is,
maps that pinctrl device serves for itself.
It is possible that in addition to SoC's pinctrl device, other pinctrl
devices get registered. E.g. some gpio expander devies are registered
as pinctrl devices. For such devices, pinctrl maps could be defined
that set up SoC's pins (e.g. interrupt pin for gpio expander). Such
a map will have target device set to gpio expander.
Here is device tree snippet that causes this scenario:
&i2c0 {
sx1503@20 {
compatible = "semtech,sx1503q";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sx1503_20>;
...
};
};
...
&iomuxc {
pinctrl_sx1503_20: pinctrl-sx1503-20 {
fsl,pins = <
VF610_PAD_PTB1__GPIO_23 0x219d
>;
};
};
Such a map will have target device set to gpio expander. However is not
a hog, it is a regular map that is claimed by core before gpio expander
device is probed.
Thus when looking for hogs, it is not enough to check that map's target
device is set to pinctrl device being registered. Need also check that
map's control device is also set to the same.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
I've forgotten to sync the documentation with the actually available
options for some time. Now all updated.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Recently some laptops and mobos are equipped with the dual Realtek
codecs that require special quirks. For making the debugging easier,
add the model "dual-codecs" to be passed via module option.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
MSI Z270-Gamin mobo has also two ALC1220 codecs like Gigabyte AZ370-
Gaming mobo. Apply the same quirk to this one.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, AM824 is described as format of data block. In this
format, one data block consists of several data channels, which is aligned
to 32 bit. One data channel has 8 bit label field and 24 bit data field.
PCM frames are transferred in Multi Bit Linear Audio (MBLA) data channel.
This channel can include 16/20/24 bit PCM sample.
As long as I know, models which support IEC 61883-1/6 doesn't allow to
switch bit length of PCM sample in MBLA data channel. They always
transmit/receive PCM frames of 24 bit length. This can be seen for the
other models which support protocols similar to IEC 61883-1/6.
On the other hand, current drivers for these protocols supports 16 bit
length PCM sample in playback substream. In this case, PCM sample is put
into the MBLA data channel with 8 bit padding in LSB side. Although 16
bit PCM sample is major because it's in CD format, this doesn't represent
device capability as is.
This commit removes support for 16 bit PCM samples in playback substream.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Make some symbols static to fix sparse warnings like:
drivers/s390/cio/vfio_ccw_ops.c:73:1: warning: symbol 'mdev_type_attr_name' was not declared. Should it be static?
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Split off support for Salvator-X boards with the ES1.x revision of the
R-Car H3 SoC into a separate file. The main r8a7795-salvator-x.dts file
now corresponds to Salvator-X with R-Car H3 ES2.0 or later.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
- The following devices no longer exist on ES2.0, and are thus removed:
fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
- The DU <-> VSPD topology is different on ES2.0, hence remove the
"compatible" and "vsps" properties from the DU node until the driver
can handle this.
Move support for the ES1.x revision of the R-Car H3 SoC into a
separate file. To avoid duplication, r8a7795-es1.dtsi includes
r8a7795.dtsi, and adds device nodes and properties where needed.
Note that while currently r8a7795-es1.dtsi only adds device nodes,
removal of devices nodes and properties can be implemented using the
/delete-node/ and /delete-property/ keywords, as shown below:
&soc {
/delete-node/ <name>@<addr>;
};
&<label> {
/delete-property/ <prop>;
};
Switch r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts from r8a7795.dtsi
to r8a7795-es1.dtsi to preserve compatibility.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The EthernetAVB should not depend on the bootloader to setup correct
drive-strength values. Values for drive-strength where found by
examining the registers after the bootloader has configured the
registers and successfully used the EthernetAVB.
Based on:
* commit 7d73a4da26 ("arm64: dts: r8a7795: salvator-x: Set drive-strength
for ravb pins")
* commit 4903987033be ("arm64: dts: r8a7796: salvator-x: Set drive-strength
for ravb pins")
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Enable the HDMI encoders for the H3 Salvator-X board. The number of
encoders varies between the H3 and M3-W SoCs, so they can't be enabled
in the common salvator-x.dtsi file.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The DU1 and DU2 external dot clocks are provided by the fixed frequency
clock generators X21 and X22, while the DU0 and DU3 clocks are provided
by the programmable Versaclock5 clock generator.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Salvator-X board has two HDMI output connectors. Add them to the
common salvator-x.dtsi.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The DU1 and DU2 external dot clocks are fixed frequency clock generators
running at 33MHz, while the DU0 and DU3 external dot clocks are
generated by an I2C-controlled programmable clock generator.
All those clock generators are available on both the H3 and M3-W
Salvator-X boards. Add them to the salvator-x.dtsi file.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Add DT nodes for the two HDMI encoders in disabled state.
Based on work by Koji Matsuoka.
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The panel backlight is controlled through a GPIO and a PWM channel.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
[simon: apply to salvator-x.dtsi instead of r8a7795-salvator-x.dts]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Renesas ULCB development board can be equipped with either an R-Car
H3 or M3-W SiP, which are pin-compatible. Both boards use different
DTBs.
Reduce duplication by extracting common ULCB board support into its own
.dtsi file. References to SoC-specific clocks are handled through cpp
definitions. Sort device nodes while at it.
For H3ULCB, there are no functional changes.
For M3ULCB, the following new devices are now described in DT:
- External audio, CAN, and PCIe clocks,
- CS2000 clock generator,
- AK4613 Audio Codec.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Renesas Salvator-X development board can be equipped with either an
R-Car H3 or M3-W SiP, which are pin-compatible. Both boards use
different DTBs.
Reduce duplication by extracting common Salvator-X board support into
its own .dtsi file. References to SoC-specific clocks are handled
through cpp definitions. Sort device nodes while at it.
For boards with an R-Car H3 SiP, there are no functional changes.
For boards with an R-Car M3-W SiP, the following new devices are now
described in DT:
- External audio, CAN, and PCIe clocks,
- USB Vbus regulator,
- CS2000 clock generator,
- AK4613 Audio Codec,
- VGA.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Add empty device nodes serving as placeholders for devices that are not
yet supported and/or tested on R-Car M3-W, but are supported and used on
Salvator-X or H3ULCB boards equipped with an R-Car H3 SoC.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Add the external PCIe bus clock as a zero Hz fixed-frequency clock.
Boards that provide this clock should override it.
Based on r8a7795.dtsi.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Add the external audio clocks as zero Hz fixed-frequency clocks.
Boards that provide these clocks should override them.
Based on commit 623197b90c ("arm64: renesas: r8a7795: Sound SSI
PIO support").
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The device trees for Renesas SoCs use either pfc or pin-controller as the
node name for the PFC device. This patch is intended to take a step towards
unifying the node name used as pin-controller which appears to be the more
generic of the two and thus more in keeping with the DT specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from e6060000.pfc and pfc@e6060000 to
e6060000.pin-controller and pin-controller@e6060000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
The EthernetAVB should not depend on the bootloader to setup correct
drive-strength values. Values for drive-strength where found by
examining the registers after the bootloader has configured the
registers and successfully used the EthernetAVB.
Based on commit 7d73a4da26 ("arm64: dts: r8a7795: salvator-x: Set
drive-strength for ravb pins").
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Set PHY rxc-skew-ps to 1500 and all other values to their default values.
This is intended to to address failures in the case of 1Gbps communication
using the salvator-x board with the KSZ9031RNX phy. This has been
reported to occur with both the r8a7795 (H3) and r8a7796 (M3-W) SoCs.
Based in a similar patch for the r8a7796 salvator-x by Kazuya Mizuguchi.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
This supports HS200 mode for eMMC on H3ULCB board
Signed-off-by: Vladimir Barinov <vladimir.barinov+renesas@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
This supports HS200 mode for eMMC on M3ULCB board
Signed-off-by: Vladimir Barinov <vladimir.barinov+renesas@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Use a better URL for the HUTRR40 Radio HID Usages documentation and use the
HID_GD_WIRELESS_RADIO_CTLS define rather then hardcoding a check for
0x0001000c.
Fixes: 61df56bef9 ("HID: Add mapping for Microsoft Win8 Wireless Radio Controls extensions")
Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch updates memory region:
- After changes, the new map of the m3ulcb board on R8A7796 SoC
Bank0: 1GiB RAM : 0x000048000000 -> 0x0007fffffff
Bank1: 1GiB RAM : 0x000600000000 -> 0x0063fffffff
- Before changes, the old map looked like this:
Bank0: 1GiB RAM : 0x000048000000 -> 0x0007fffffff
Signed-off-by: Vladimir Barinov <vladimir.barinov+renesas@cogentembedded.com>
Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
This supports I2C2 bus on M3ULCB board
Signed-off-by: Vladimir Barinov <vladimir.barinov+renesas@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The keyboard dock used with the Asus Transformer T100 series, uses
the same vendor-defined 0xff31 usage-page as some other Asus
keyboards. But with a small twist, it has a small descriptor bug which
needs to be fixed up for things to work.
This commit adds the USB-ID for this keyboard to the hid-asus driver
and makes asus_report_fixup fix the descriptor issue, fixing
various special function keys on this keyboard not working.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Enable support for USB audio and video camera devices.
Tested on OMAP-L138 LCDK using Logitech webcam and
Plantronics headset.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
davinci_all_defconfig is out of sync with savedefconfig in some places.
Regenerate the default settings by:
$ make davinci_all_config
$ make savedefconfig
$ cp defconfig arch/arm/configs/davinci_all_defconfig
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We improved the reset reliablity on gen4 with
stopping all engines before commencing reset, in
commit 2c80353f3c ("drm/i915/g4x: Improve gpu reset reliability")
Evidence indicates that this same trick works with g33.
v2: proper gen naming, comment readability (Chris)
Testcase: igt/gem_busy/*-hang #blb-e6850
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170522090244.2557-1-mika.kuoppala@intel.com
The DSP subsystem on DA8xx has various internal RAM memories that can
accessed from the ARM side. These memories can be configured to be
used as either RAM or Cache. Add these memories as IOMEM resources
to the DSP device so that the driver can support loading of images
into internal memories.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
