As per section 5.6.1 of the DSI specification, all DSI transmitters must
support continuous clock behavior on the clock lane, while non-continuous
mode support is only optional. Add a flag that allows devices to indicate
that they support non-continuous clock mode so host drivers can adapt
their behavior accordingly.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
John W. Linville says:
====================
Please pull this batch of updates intended for the 3.17 stream...
This is primarily a Bluetooth pull. Gustavo says:
"A lot of patches to 3.17. The bulk of changes here are for LE support.
The 6loWPAN over Bluetooth now has it own module, we also have support for
background auto-connection and passive scanning, Bluetooth device address
provisioning, support for reading Bluetooth clock values and LE connection
parameters plus many many fixes."
The balance is just a pull of the wireless.git tree, to avoid some
pending merge problems.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
fl_owner_t is a cookie that can store all kinds of different pointers,
so don't pretends it points to a file structure.
For now just change the typedef, but as a follow on this will allow
to get rids of lots of casts and eventually the typedef itself.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jeff Layton <jlayton@primarydata.com>
This resolves a number of merge issues with changes in this tree and
Linus's tree at the same time.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The spinlock protecting the L2CAP ident number can be converted into
a mutex since the whole processing is run in a workqueue. So instead
of using a spinlock, just use a mutex here.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Jonathan writes:
3rd round of IIO new drivers, cleanups and functionality for the 3.17 cycle.
New drivers
* isl29125 digital color light sensor driver
* TAOS/AMS tcs3414 digital color sensor
Staging graduation
* ad7291 ADC driver.
New functionality
* st_sensors - device tree support and bindings
* mma8452 - device tree support
Cleanups
* Drop redundant variables in a number of drivers.
* Reorder a structure definition to ealy wiht a warning about static
not being at the beginning in the hid-sensors driver.
* Switch a few more drivers away from using explicit sampling_frequency
attribute to providing this through the core.
* Make hid_sensor_get_reporting_interval static as only used within a single
file.
* Drop a redundant check for negative values in an unsigned variable from
ad9832
* Drop some duplicate case labels in the event monitor example code.
* Use devm_ioremap_resource to simplify error handling.
* Use devm_kzalloc within the blackfin timer driver to simplify error
handling and removal.
* A number of cleanups of the ad7291 from Hartmut Knaack in response
to a patch moving it out of staging.
* Core support for the period info element about events. It has been
in the abi for a while, but not added until now to the newer handling
of information related to events.
* Add HAS_IOMEM dependency to mxs_lradc to avoid build issues when testing
enabled.
Pull clock driver fixes from Mike Turquette:
"This batch of fixes is for a handful of clock drivers from Allwinner,
Samsung, ST & TI. Most of them are of the "this hardware won't work
without this fix" variety, including patches that fix platforms that
did not boot under certain configurations. Other fixes are the result
of changes to the clock core introduced in 3.15 that had subtle
impacts on the clock drivers.
There are no fixes to the clock framework core in this pull request"
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
clk: spear3xx: Set proper clock parent of uart1/2
clk: spear3xx: Use proper control register offset
clk: qcom: HDMI source sel is 3 not 2
clk: sunxi: fix devm_ioremap_resource error detection code
clk: s2mps11: Fix double free corruption during driver unbind
clk: ti: am43x: Fix boot with CONFIG_SOC_AM33XX disabled
clk: exynos5420: Remove aclk66_peric from the clock tree description
clk/exynos5250: fix bit number for tv sysmmu clock
clk: s3c64xx: Hookup SPI clocks correctly
clk: samsung: exynos4: Remove SRC_MASK_ISP gates
clk: samsung: add more aliases for s3c24xx
clk: samsung: fix several typos to fix boot on s3c2410
clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
clk: ti: am43x: Fix boot with CONFIG_SOC_AM33XX disabled
clk: ti: dra7: return error code in failure case
clk: ti: apll: not allocating enough data
This adds a clock driver that handles the specific muxes, dividers and gates
of rk3188 and rk3066 SoCs.
The structure of the clock list resembles the arrangement of their
counterparts in the clock architecture diagrams found in the SoC
documentation.
Clocks exported to the clock provider are currently limited to well known
or measured ones. So additional clock exports may be necessary in the future.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-By: Max Schwarz <max.schwarz@online.de>
Tested-By: Max Schwarz <max.schwarz@online.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Pull ARM SoC fixes from Olof Johansson:
"This week's arm-soc fixes:
- Another set of OMAP fixes
* Clock fixes
* Restart handling
* PHY regulators
* SATA hwmod data for DRA7
+ Some trivial fixes and removal of a bit of dead code
- Exynos fixes
* A bunch of clock fixes
* Some SMP fixes
* Exynos multi-core timer: register as clocksource and fix ftrace.
+ a few other minor fixes
There's also a couple more patches, and at91 fix for USB caused by
common clock conversion, and more MAINTAINERS entries for shmobile.
We're definitely switching to only regression fixes from here on out,
we've been a little less strict than usual up until now"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (26 commits)
ARM: at91: at91sam9x5: add clocks for usb device
ARM: EXYNOS: Register cpuidle device only on exynos4210 and 5250
ARM: dts: Add clock property for mfc_pd in exynos5420
clk: exynos5420: Add IDs for clocks used in PD mfc
ARM: EXYNOS: Add support for clock handling in power domain
ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
ARM: imx: fix shared gate clock
ARM: dts: Update the parent for Audss clocks in Exynos5420
ARM: EXYNOS: Update secondary boot addr for secure mode
ARM: dts: Fix TI CPSW Phy mode selection on IGEP COM AQUILA.
ARM: dts: am335x-evmsk: Enable the McASP FIFO for audio
ARM: dts: am335x-evm: Enable the McASP FIFO for audio
ARM: OMAP2+: Make GPMC skip disabled devices
ARM: OMAP2+: create dsp device only on OMAP3 SoCs
ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
ARM: DRA7/AM43XX: fix header definition for omap44xx_restart
ARM: OMAP2+: clock/dpll: fix _dpll_test_fint arithmetics overflow
ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
ARM: DRA7: hwmod: Fixup SATA hwmod
ARM: OMAP3: PRM/CM: Add back macros used by TI DSP/Bridge driver
...
The support for LE encryption is optional. When encryption is not
supported then also do not enable the encryption related events.
This moves the event mask setting to the third initialization
stage to ensure that the LE features are available.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Merge "Ux500 core changes for v3.17 take 1" from Linus Walleij:
Some minor cleanups to the Ux500 core. DT-only probe path and
some constification from static code analysis.
* tag 'ux500-core-for-v3.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
ARM: ux500: remove pointless cache setup complexity
ARM: ux500: storage class should be before const qualifier
ARM: ux500: Staticize ab8505_regulators
ARM: ux500: Staticize local symbols in cpu-db8500.c
ARM: ux500: Staticise ux500_soc_attr
+ Linux 3.16-rc4
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "Ux500 devicetree changes for v3.17" from Linus Walleij:
Ux500 device tree patches for v3.17:
- Add regulators to STMPE expanders
- Add proper DMA channels for all SD/MMC blocks
- Add sensors to the device tree
* tag 'ux500-devicetree-v3.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
ARM: ux500: add misc sensors to the device trees
ARM: ux500: add some DB8500 DMA channel info
ARM: ux500: add VCC and VIO regulators to STMPE IC
+ Linux 3.16-rc4
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "Samsung cleanup 2nd version for S5P SoCs for 3.17" from Kukjin Kim:
Cleanup S5P SoCs for 3.17
- removing s5p64x0 SoCs and s5pc100 SoC in mainline because
no more user and if it is required next time, it will be
supported with DT.
* tag 's5p-cleanup-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
video: fbdev: s3c-fb: remove s5pc100 related fimd and fb codes
mtd: onenand: remove s5pc100 related onenand codes
spi: s3c64xx: remove s5pc100 related spi codes
gpio: samsung: remov s5pc100 related gpio codes
ARM: S5PC100: no more support S5PC100 SoC
video: fbdev: s3c-fb: remove s5p64x0 related fimd codes
spi: s3c64xx: remove s5p64x0 related spi codes
gpio: samsung: remove s5p64x0 related gpio codes
ARM: S5P64X0: no more support S5P6440 and S5P6450 SoCs
Signed-off-by: Olof Johansson <olof@lixom.net>
The current CB_COMPOUND handling code tries to compare the principal
name of the request with the cl_hostname in the client. This is not
guaranteed to ever work, particularly if the client happened to mount
a CNAME of the server or a non-fqdn.
Fix this by instead comparing the cr_principal string with the acceptor
name that we get from gssd. In the event that gssd didn't send one
down (i.e. it was too old), then we fall back to trying to use the
cl_hostname as we do today.
Signed-off-by: Jeff Layton <jlayton@poochiereds.net>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
...and add an new rpc_auth function to call it when it exists. This
is only applicable for AUTH_GSS mechanisms, so we only specify this
for those sorts of credentials.
Signed-off-by: Jeff Layton <jlayton@poochiereds.net>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
If rpc.gssd sends us an acceptor name string trailing the context token,
stash it as part of the context.
Signed-off-by: Jeff Layton <jlayton@poochiereds.net>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Some new Micron flash chips require reading the flag status register to
determine when operations have completed.
Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
require reading the status register before reading the flag status
register.
This patch adds support for the flag status register in the n25q512ax3
and n25q00 Micron QSPI flash chips.
Signed-off-by: Graham Moore <grmoore@altera.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This MIC virtual bus driver takes the responsibility of creating all
the virtual devices connected to the PCIe device on the host and the
platform device on the card. The MIC bus hardware operations provide
a way to abstract certain hardware details from the base physical devices.
Examples of devices added on the MIC virtual bus include host DMA and card DMA.
This abstraction enables using a common DMA driver on host and card.
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Nikhil Rao <nikhil.rao@intel.com>
Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: Siva Yerramreddy <yshivakrishna@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The two functions alloc_tty_struct and initialize_tty_struct are
always called together. Merge them into alloc_tty_struct, updating its
prototype and the only two callers of these functions.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch introduces a possibility for userspace to set various (so far
two) modes of generating addresses. This is useful for example for
NetworkManager because it can set the mode to NONE and take care of link
local addresses itself. That allow it to have the interface up,
monitoring carrier but still don't have any addresses on it.
One more use-case by Dan Williams:
<quote>
WWAN devices often have their LL address provided by the firmware of the
device, which sometimes refuses to respond to incorrect LL addresses
when doing DHCPv6 or IPv6 ND. The kernel cannot generate the correct LL
address for two reasons:
1) WWAN pseudo-ethernet interfaces often construct a fake MAC address,
or read a meaningless MAC address from the firmware. Thus the EUI64 and
the IPv6LL address the kernel assigns will be wrong. The real LL
address is often retrieved from the firmware with AT or proprietary
commands.
2) WWAN PPP interfaces receive their LL address from IPV6CP, not from
kernel assignments. Only after IPV6CP has completed do we know the LL
address of the PPP interface and its peer. But the kernel has already
assigned an incorrect LL address to the interface.
So being able to suppress the kernel LL address generation and assign
the one retrieved from the firmware is less complicated and more robust.
</quote>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
drm_rotation_simplify() can be used to eliminate unsupported rotation
flags. It will check if any unsupported flags are present, and if so
it will modify the rotation to an alternate form by adding 180 degrees
to rotation angle, and flipping the reflect x and y bits. The hope is
that this identity transform will eliminate the unsupported flags.
Of course that might not result in any more supported rotation, so
the caller is still responsible for checking the result afterwards.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.
v2: Populate values[] array as non-sparse
Make supported_bits 64bit
Fix up omapdrm call site (Rob)
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sagar Kamble <sagar.a.kamble@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add the necessary clocks for SATA, PCIe and UFS to the
APQ8084 global clock controller (GCC). This will allow
the above device drivers to control their clocks.
Signed-off-by: Georgi Djakov <gdjakov@mm-sol.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
This patch adds support for the global clock controller found on
the APQ8084 based devices. This includes UART, I2C, SPI etc.
Signed-off-by: Georgi Djakov <gdjakov@mm-sol.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The iio sysfs ABI defines a way to specify period for roc and thresholds.
What: /sys/.../events/in_accel_x_thresh_rising_period
What: /sys/.../events/in_accel_x_thresh_falling_period
what: /sys/.../events/in_accel_x_roc_rising_period
What: /sys/.../events/in_accel_x_roc_falling_period
But there is no way to add period with the current event info enum.
Added IIO_EV_INFO_PERIOD and corresponding string.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The I2C devices that make up the STMicroelectronics MEMS sensors
may be sneakily enabled by cleverly giving the device node the same
name as a string match from the platform device ID table. However
the right method is to use the compatible string.
On detection, the ST sensors use the ID string to probe and
instatiate the right sensor driver, so pass the kernel-internal ID
string in the .data field of the OF match table, and set the I2C
client name to this name when a compatible match is used.
This avoids having misc Linux-specific strings floating around in
the device tree.
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add a helper to allow encoders to find their possible CRTCs from the
OF graph without having to re-implement this functionality. We add a
device_node to drm_crtc which corresponds with the port node in the
DT description of the CRTC device.
We can then scan the DRM device list for CRTCs to find their index,
matching the appropriate CRTC using the port device_node, thus building
up the possible CRTC mask.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch adds the device tree binding documentation for the XUSB pad
controller found on NVIDIA Tegra SoCs. It exposes both pinmuxing and PHY
capabilities.
Tested-by: Mikko Perttunen <mperttunen@nvidia.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
What the patch does:
1. Call pinmux_disable_setting ahead of pinmux_enable_setting
each time pinctrl_select_state is called
2. Remove the HW disable operation in pinmux_disable_setting function.
3. Remove the disable ops in struct pinmux_ops
4. Remove all the disable ops users in current code base.
Notes:
1. Great thanks for the suggestion from Linus, Tony Lindgren and
Stephen Warren and Everyone that shared comments on this patch.
2. The patch also includes comment fixes from Stephen Warren.
The reason why we do this:
1. To avoid duplicated calling of the enable_setting operation
without disabling operation inbetween which will let the pin
descriptor desc->mux_usecount increase monotonously.
2. The HW pin disable operation is not useful for any of the
existing platforms.
And this can be used to avoid the HW glitch after using the
item #1 modification.
In the following case, the issue can be reproduced:
1. There is a driver that need to switch pin state dynamically,
e.g. between "sleep" and "default" state
2. The pin setting configuration in a DTS node may be like this:
component a {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&a_grp_setting &c_grp_setting>;
pinctrl-1 = <&b_grp_setting &c_grp_setting>;
}
The "c_grp_setting" config node is totally identical, maybe like
following one:
c_grp_setting: c_grp_setting {
pinctrl-single,pins = <GPIO48 AF6>;
}
3. When switching the pin state in the following official pinctrl
sequence:
pin = pinctrl_get();
state = pinctrl_lookup_state(wanted_state);
pinctrl_select_state(state);
pinctrl_put();
Test Result:
1. The switch is completed as expected, that is: the device's
pin configuration is changed according to the description in the
"wanted_state" group setting
2. The "desc->mux_usecount" of the corresponding pins in "c_group"
is increased without being decreased, because the "desc" is for
each physical pin while the setting is for each setting node
in the DTS.
Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead
of enabling "c_grp_setting" in pinctrl-1, the desc->mux_usecount
will keep increasing without any chance to be decreased.
According to the comments in the original code, only the setting,
in old state but not in new state, will be "disabled" (calling
pinmux_disable_setting), which is correct logic but not intact. We
still need consider case that the setting is in both old state
and new state. We can do this in the following two ways:
1. Avoid to "enable"(calling pinmux_enable_setting) the "same pin
setting" repeatedly
2. "Disable"(calling pinmux_disable_setting) the "same pin setting",
actually two setting instances, ahead of enabling them.
Analysis:
1. The solution #2 is better because it can avoid too much
iteration.
2. If we disable all of the settings in the old state and one of
the setting(s) exist in the new state, the pins mux function
change may happen when some SoC vendors defined the
"pinctrl-single,function-off"
in their DTS file.
old_setting => disabled_setting => new_setting.
3. In the pinmux framework, when a pin state is switched, the
setting in the old state should be marked as "disabled".
Conclusion:
1. To Remove the HW disabling operation to above the glitch mentioned
above.
2. Handle the issue mentioned above by disabling all of the settings
in old state and then enable the all of the settings in new state.
Signed-off-by: Fan Wu <fwu@marvell.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Introduce the support code for emulating a GICv2 on top of GICv3
hardware.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Move the GICv2 world switch code into its own file, and add the
necessary indirection to the arm64 switch code.
Also introduce a new type field to the vgic_params structure.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
So far, irqchip_in_kernel() was implemented by testing the value of
vctrl_base, which worked fine with GICv2.
With GICv3, this field is useless, as we're using system registers
instead of a emmory mapped interface. To solve this, add a boolean
flag indicating if the we're using a vgic or not.
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Brutally hack the innocent vgic code, and move the GICv2 specific code
to its own file, using vgic_ops and vgic_params as a way to pass
information between the two blocks.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Instead of directly messing with with the GICH_VMCR bits for the CPU
interface save/restore code, add accessors that encode/decode the
entire set of registers exposed by VMCR.
Not the most efficient thing, but given that this code is only used
by the save/restore code, performance is far from being critical.
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Instead of directly dealing with the GICH_MISR bits, move the code to
its own function and use a couple of public flags to represent the
actual state.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
