- Jul 03, 2020
-
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64675/ Use the newly introduced get_mbus_config() subdevice pad operation to retrieve the remote subdevice MIPI CSI-2 bus configuration and configure the number of active data lanes accordingly. In order to be able to call the remote subdevice operation cache the index of the remote pad connected to the single CSI-2 input port. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64676/ Implement the newly introduced get_mbus_config operation to report the number of currently used data lanes on the MIPI CSI-2 interface. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64673/ When outputting SD-Core output through the TXA MIPI CSI-2 interface, the number of enabled data lanes should be reduced in order to guarantee that the two video formats produced by the SD-Core (480i and 576i) generate a MIPI CSI-2 link clock frequency compatible with the MIPI D-PHY specifications. Limit the number of enabled data lanes to 2, which is guaranteed to support 480i and 576i formats. Cache the number of enabled data lanes to be able to report it through the new get_mbus_config operation. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64672/ Update the TODO entry that mentioned a potential use case for the now removed g_mbus_config video operation. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64670/ With all sensor and platform drivers now converted to use the new get_mbus_config and set_mbus_config pad operations, remove the deprecated video operations g_mbus_config and s_mbus_config. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64671/ Move the PXA camera driver to use the new set_mbus_config pad operation. For this platform the change is not only cosmetic, as the pxa driver is currently the only driver in mainline to make use of the g_mbus_config and s_mbus_config video operations. The existing driver semantic is the following: - Collect all supported mbus config flags from the remote end - Match them with the supported PXA mbus configuration flags - If the remote subdevice allows multiple options for for VSYNC, HSYNC and PCLK polarity, use platform data requested settings The semantic of the new get_mbus_config and set_mbus_config differs from the corresponding video ops, particularly in the fact get_mbus_config reports the current mbus configuration and not the set of supported configuration options, with set_mbus_config always reporting the actual mbus configuration applied to the remote subdevice. Adapt the driver to perform the following - Set the remote subdevice mbus configuration according to the PXA platform data preferences. - If the applied configuration differs from the requested one (i.e. the remote subdevice does not allow changing one setting) make sure that - The remote end does not claim for DATA_ACTIVE_LOW, which seems not supported by the platform - The bus mastering roles match While at there remove a few checks performed on the media bus configuration at get_format() time as they do not belong there. Compile-tested only. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64674/ Use the new get_mbus_config and set_mbus_config pad operations in place of the video operations currently in use. Compared to other drivers where the same conversion has been performed, ov6650 proved to be a bit more tricky, as the existing g_mbus_config implementation did not report the currently applied configuration but the set of all possible configuration options. Adapt the driver to support the semantic of the two newly introduced operations: - get_mbus_config reports the current media bus configuration - set_mbus_config applies only changes explicitly requested and updates the provided cfg parameter to report what has actually been applied to the hardware. Compile-tested only. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64669/ Move the existing users of the g_mbus_config video operation to use the newly introduced get_mbus_config pad operations. All the ported drivers report a static media bus configuration and do no support s_mbus_config so the operation implementation has not changed. Bridge drivers needs to call the new pad operation and will receive an -ENOICTLCMD when calling the old g_mbus_config video operation Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Jacopo Mondi authored
Upstream https://patchwork.linuxtv.org/patch/64669/ Introduce two new pad operations to allow retrieving and configuring the media bus parameters on a subdevice pad. The newly introduced operations aims to replace the s/g_mbus_config video operations, which have been on their way for deprecation since a long time. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
-
Phil Elwell authored
Allow the nvram file to set a default ccode (regulatory domain) without overriding one set in OTP. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
- Jul 01, 2020
-
-
Maxim Mikityanskiy authored
Add device tree nodes for Bluetooth on supported Raspberry Pi boards. It's disabled by default and can be enabled by `krnbt=on` dtparam. It's an alternative way of configuring Bluetooth, as compared to hciattach or btattach. When the dtparam is enabled, the Bluetooth driver is probed automatically and doesn't require any additional bring-up scripts. Note that Raspberry Pi 3 B rev 1.2 doesn't have the required hardware flow control pins of UART0 connected to the Bluetooth module, so the user should decrease the baudrate by passing `krnbt_baudrate=921600` dtparam to make it more stable. It resembles the behavior of the btuart script from Raspbian. The miniuart-bt overlay was modified to support Bluetooth probing with device tree, too. It's disabled by default and can be enabled by `krnbt=on` parameter of the miniuart-bt overlay. Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
-
Maxim Mikityanskiy authored
The next patch adds a device tree overlay for Bluetooth. The Bluetooth device node is a child of uart0 (pl011). The children of pl011 are not registered as platform devices by of_platform_bus_create, because they fall into `of_device_is_compatible(bus, "arm,primecell")` check. These children are registered by of_serdev_register_devices, called through this chain of calls: - uart_add_one_port (drivers/tty/serial/amba-pl011.c) - tty_port_register_device_attr_serdev - serdev_tty_port_register - serdev_controller_add - of_serdev_register_devices serdev_tty_port_register depends on CONFIG_SERIAL_DEV_CTRL_TTYPORT, which in turn depends on CONFIG_SERIAL_DEV_BUS=y. This patch modifies the defconfigs of Raspberry Pi devices to set these options and allow to bind drivers to subnodes of UART devices that can be added by device tree overlays. Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
-
- Jun 24, 2020
-
-
Maxim Mikityanskiy authored
Commit 8353fe6f ("Revert "staging: bcm2835-audio: Drop DT dependency"") reverts the upstream change and makes bcm2835-audio use device tree again, however, it also removes the MODULE_ALIAS for the platform device. This MODULE_ALIAS is needed, because VCHIQ registers bcm2835-audio as a child platform device since commit 25c7597a ("staging: vchiq_arm: Register a platform device for audio"), and this mechanism is adopted also in the downstream kernel. This commit puts back that MODULE_ALIAS to make bcm2835-audio autoprobing work again. The rest of VCHIQ children have their MODULE_ALIASes in place. Fixes: 8353fe6f ("Revert "staging: bcm2835-audio: Drop DT dependency"") Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
-
Markus Proeller authored
When closing the video device, the irs1125 is put in power down state. To keep V4L2 ctrls and the HW in sync, v4l2_ctrl_handler_setup is called after power up. The compound ctrl IRS1125_CID_MOD_PLL however has a default value of all zeros, which puts the imager into a non responding state. Thus, this ctrl is not written by the driver into HW after power up. The userspace has to take care to write senseful data. Signed-off-by: Markus Proeller <markus.proeller@pieye.org>
-
Markus Proeller authored
Instead of changing the exposure and framerate settings for all sequences, they can be changed for every sequence individually now. Therefore the IRS1125_CID_SAFE_RECONFIG ctrl has been removed and replaced by IRS1125_CID_SAFE_RECONFIG_S<seq_num>_EXPO and *_FRAME ctrls. The consistency check in the sequence ctrl IRS1125_CID_SEQ_CONFIG is removed. Signed-off-by: Markus Proeller <markus.proeller@pieye.org>
-
Markus Proeller authored
Changed some variable names to comply with checkpatch --strict mode. Debug messages added. Signed-off-by: Markus Proeller <markus.proeller@pieye.org>
-
Markus Proeller authored
Reading data over i2c is done by using i2c_transfer to ensure that this operation can't be interrupted. Signed-off-by: Markus Proeller <markus.proeller@pieye.org>
-
Phil Elwell authored
This reverts commit 49b9bd89. See: https://github.com/raspberrypi/linux/pull/3687
-
Phil Elwell authored
This reverts commit 2697f018. See: https://github.com/raspberrypi/linux/pull/3687
-
Phil Elwell authored
This reverts commit fe3f696b. See: https://github.com/raspberrypi/linux/pull/3687
-
Phil Elwell authored
Add initial DTS file for Compute Module 4. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
The BRCM PCIe block has controls to enable control of the CLKREQ# signal by the L1SS, and to gate the refclk with the CLKREQ# input. These controls are mutually exclusive - the upstream code sets the latter, but some use cases require the former. Add a Device Tree property - brcm,enable-l1ss - to switch to the L1SS configuration. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
- Jun 18, 2020
-
-
Maxime Ripard authored
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The CPU clock has had so far a bunch of quirks to expose the clock tree properly, but since we reverted to exposing them through the MMIO driver, we can remove that code from the firmware driver. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
We've registered the firmware clocks using their ID as name, but it's much more convenient to register them using their proper name. Since the firmware doesn't provide it, we have to duplicate it. Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
The raspberrypi firmware clock driver has a min_rate / max_rate clamping by storing the info it needs in a private structure. However, the CCF already provides such a facility, so we can switch to it to remove the boilerplate. Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
While the firmware allows us to discover the available clocks, we need to discriminate those clocks to only register the ones meaningful to Linux. The firmware also doesn't provide a clock name, so having a list of the ID will help us to give clocks a proper name later on. Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
-
Nicolas Saenz Julienne authored
commit 22e21e51 upstream. While preparing the driver for upstream this detail was missed. If not asserted during the initialization process, devices connected on the bus will not be made aware of the internal reset happening. This, potentially resulting in unexpected behavior. Link: https://lore.kernel.org/r/20200507172020.18000-1-nsaenzjulienne@suse.de Fixes: c0452137 ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
-
Colin Ian King authored
commit f37d13d5 upstream. The variable ret is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200519154553.873413-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Carpenter authored
commit e420637b upstream. The problem is that we change "p_args" to point to the middle of the string so when we free it at the end of the function it's not freeing the same pointer that we originally allocated. Fixes: e2c94d6f ("w1_therm: adding alarm sysfs entry") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200520120019.GA172354@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Akira Shimahara authored
commit 57c76221 upstream. Adding bulk read support: Sending a 'trigger' command in the dedicated sysfs entry of bus master device send a conversion command for all the slaves on the bus. The sysfs entry is added as soon as at least one device supporting this feature is detected on the bus. The behavior of the sysfs reading temperature on the device is as follow: * If no bulk read pending, trigger a conversion on the device, wait for the conversion to be done, read the temperature in device RAM * If a bulk read has been trigger, access directly the device RAM This behavior is the same on the 2 sysfs entries ('temperature' and 'w1_slave'). Reading the therm_bulk_read sysfs give the status of bulk operations: * '-1': conversion in progress on at least 1 sensor * '1': conversion complete but at least one sensor has not been read yet * '0': no bulk operation. Reading temperature on ecah device will trigger a conversion As not all devices support bulk read feature, it has been added in device family structure. The attribute is set at master level as soon as a supporting device is discover. It is removed when the last supported device leave the bus. The count of supported device is kept with the static counter bulk_read_device_counter. A strong pull up is apply on the line if at least one device required it. The duration of the pull up is the max time required by a device on the line, which depends on the resolution settings of each device. The strong pull up could be adjust with the a module parameter. Updating documentation in Documentation/ABI/testing/sysfs-driver-w1_therm and Documentation/w1/slaves/w1_therm.rst accordingly. Signed-off-by: Akira Shimahara <akira215corp@gmail.com> Link: https://lore.kernel.org/r/20200511203820.411483-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Akira Shimahara authored
commit e2c94d6f upstream. Adding device alarms settings by a dedicated sysfs entry alarms (RW): read or write TH and TL in the device RAM. Checking devices in alarm state could be performed using the master search command. As alarms temperature level are store in a 8 bit register on the device and are signed values, a safe cast shall be performed using the min and max temperature that device are able to measure. This is done by int_to_short inline function. A 'write_data' field is added in the device structure, to bind the correct writing function, as some devices may have 2 or 3 bytes RAM. Updating Documentation/ABI/testing/sysfs-driver-w1_therm accordingly. Signed-off-by: Akira Shimahara <akira215corp@gmail.com> Link: https://lore.kernel.org/r/20200511203801.411253-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Akira Shimahara authored
commit 67b392f7 upstream. Optimizing temperature reading by reducing waiting conversion time according to device resolution settings, as per device specification. This is device dependent as not all the devices supports resolution setting, so it has been added in device family structures. The process to read the temperature on the device has been adapted in a new function 'convert_t()', which replace the former 'read_therm()', is introduce to deal with this timing. Strong pull up is also applied during the required time, according to device power status needs and 'strong_pullup' module parameter. 'temperature_from_RAM()' function is introduced to get the correct temperature computation (device dependent) from device RAM data. An new sysfs entry has been added to ouptut only temperature. The old entry w1_slave has been kept for compatibility, without changing its output format. Updating Documentation/ABI/testing/sysfs-driver-w1_therm accordingly. Signed-off-by: Akira Shimahara <akira215corp@gmail.com> Link: https://lore.kernel.org/r/20200511203742.411039-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Akira Shimahara authored
commit 45d457a4 upstream. The driver implement 2 hardware functions to access device RAM: * copy_scratchpad * recall_scratchpad They act according to device specifications. As EEPROM operations are not device dependent (all w1_therm can perform EEPROM read/write operation following the same protocol), it is removed from device families structures. Updating Documentation/ABI/testing/sysfs-driver-w1_therm accordingly. Signed-off-by: Akira Shimahara <akira215corp@gmail.com> Link: https://lore.kernel.org/r/20200511203725.410844-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Akira Shimahara authored
commit 308bdb94 upstream. Adding resolution sysfs entry (RW) to get or set the device resolution Write values are managed as follow: * '9..12': resolution to set in bit * Anything else: do nothing Read values are : * '9..12': device resolution in bit * '-xx': xx is kernel error when reading the resolution Only supported devices will show the sysfs entry. A new family has been created for DS18S20 devices as they do not implement resolution feature. The resolution of each device is check when the device is discover by the bus master, in 'w1_therm_add_slave(struct w1_slave *)'. The status is stored in the device structure w1_therm_family_data so that the driver always knows the resolution of each device, which could be used later to determine the required conversion duration (resolution dependent). The resolution is re evaluate each time a user read or write the sysfs entry. To avoid looping through the w1_therm_families at run time, the pointer 'specific_functions' is set up to the correct 'w1_therm_family_converter' when the slave is added (which mean when it is discovered by the master). This initialization is done by a helper function 'device_family(struct w1_slave *sl)', and a dedicated macro 'SLAVE_SPECIFIC_FUNC(sl)' allow the access to the specific function of the slave device. 'read_scratchpad' and 'write_scratchpad' are the hardware functions to access the device RAM, as per protocol specification. It cancel the former 'precision' functions, which was only set and never read (so not stored in the device struct). Updating Documentation/ABI/testing/sysfs-driver-w1_therm accordingly. Signed-off-by: Akira Shimahara <akira215corp@gmail.com> Link: https://lore.kernel.org/r/20200511203708.410649-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Akira Shimahara authored
commit b7bb6ca1 upstream. Adding ext_power sysfs entry (RO). Return the power status of the device: - 0: device parasite powered - 1: device externally powered - xx: xx is kernel error The power status of each device is check when the device is discover by the bus master, in 'w1_therm_add_slave(struct w1_slave *)'. The status is stored in the device structure w1_therm_family_data so that the driver always knows the power state of each device, which could be used later to determine the required strong pull up to apply on the line. The power status is re evaluate each time the sysfs ext_power read by a user. The hardware function 'read_powermode(struct w1_slave *sl)' act just as per device specifications, sending W1_READ_PSUPPLY command on the bus, and issue a read time slot, reading only one bit. A helper function 'bool bus_mutex_lock(struct mutex *lock)' is introduced. It try to aquire the bus mutex several times (W1_THERM_MAX_TRY), waiting W1_THERM_RETRY_DELAY between two attempt. Updating Documentation/ABI/testing/sysfs-driver-w1_therm accordingly. Signed-off-by: Akira Shimahara <akira215corp@gmail.com> Link: https://lore.kernel.org/r/20200511203650.410439-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Akira Shimahara authored
commit c8ad65f6 upstream. Fix reset_select_slave issue during devices discovery by the master on bus. The w1_reset_select_slave() from w1_io.c, which was previously used, assume that if the slave count is 1 there is only one slave attached on the bus. This is not always true. For example when discovering devices, when the first device is discover by the bus master, its slave count is 1, but some other slaves may be on the bus. In that case instead of adressing command to the attached slave the master throw a SKIP ROM command so that all slaves attached on the bus will answer simultenaously causing data collision. A dedicated reset_select_slave() function is implemented here, it always perform an adressing to each slave using the MATCH ROM command. Signed-off-by: Akira Shimahara <akira215corp@gmail.com> Link: https://lore.kernel.org/r/20200511203610.409975-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Akira Shimahara authored
commit 92b8d272 upstream. Adding code comments to split code in dedicated parts. After the global declarations (defines, macros and function declarations), code is organized as follow : - Device and family dependent structures and functions - Interfaces functions - Helpers functions - Hardware functions - Sysfs interface functions Signed-off-by: Akira Shimahara <akira215corp@gmail.com> Link: https://lore.kernel.org/r/20200511203535.409599-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-