- 06 Apr, 2016 40 commits
-
-
Thierry Reding authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Commit d1cd2142 ("pwm: Set enable state properly on failed call to enable") introduced a mutex that is needed to protect internal state of PWM devices. Since that mutex is acquired in pwm_set_polarity() and in pwm_enable() and might potentially block, all PWM devices effectively become "might sleep". It's rather pointless to keep the .can_sleep field around, but given that there are external users let's postpone the removal for the next release cycle. Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> (cherry picked from commit ff01c944) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1520436 "omap" is NULL so we can't dereference it. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Vegard Nossum authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Ran into this on UML: drivers/built-in.o: In function `fsl_pwm_probe': linux/drivers/pwm/pwm-fsl-ftm.c:436: undefined reference to `devm_ioremap_resource' collect2: error: ld returned 1 exit status devm_ioremap_resource() is defined only when HAS_IOMEM is selected. Signed-off-by:
Vegard Nossum <vegard.nossum@oracle.com> Cc: Xiubo Li <Li.Xiubo@freescale.com> Cc: Alison Wang <b18965@freescale.com> Cc: Jingchang Lu <b35083@freescale.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Yuan Yao <yao.yuan@freescale.com> Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Neil Armstrong authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Adds support for using a OMAP dual-mode timer with PWM capability as a Linux PWM device. The driver controls the timer by using the dmtimer API. Add a platform_data structure for each pwm-omap-dmtimer nodes containing the dmtimers functions in order to get driver not rely on platform specific functions. Cc: Grant Erickson <marathon96@gmail.com> Cc: NeilBrown <neilb@suse.de> Cc: Joachim Eastwood <manabian@gmail.com> Suggested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
-
Ryo Kodama authored
BugLink: http://bugs.launchpad.net/bugs/1520436 From: Ryo Kodama <ryo.kodama.vz@renesas.com> When period_ns is set to the same value of RCAR_PWM_MAX_CYCLE in rcar_pwm_get_clock_division(), this function should allow such value for improving accuracy of frequency division setting. Signed-off-by:
Ryo Kodama <ryo.kodama.vz@renesas.com> Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Vladimir Zapolskiy authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Instead of silent acceptance of unsupported requested configuration for PWM period and setting the boundary supported value, return -ERANGE to a caller. Duty period value equal to 0 or period is still accepted to allow configuration by PWM sysfs interface, when it is set to 0 by default. For reference this is a list of restrictions on period_ns == 1/freq: | PWM parent clock | parent clock divisor | max freq | min freq | +------------------+----------------------+----------+----------+ | HCLK == 13 MHz | 1 (min) | 50.7 KHz | 198.3 Hz | | HCLK == 13 MHz | 15 (max) | 3.38 KHz | 13.22 Hz | | RTC == 32.7 KHz | 1 (min) | 128 Hz | 0.5 Hz | | RTC == 32.7 KHz | 15 (max) | 8.533 Hz | 0.033 Hz | Note that PWM sysfs interface does not support setting of period more than NSEC_PER_SEC / MAX_INT32 ~ 2 seconds, however this PWM controller supports a period up to 30 seconds. Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Signed-off-by:
-
Vladimir Zapolskiy authored
BugLink: http://bugs.launchpad.net/bugs/1520436 The change fixes a problem, if duty_ns is too small in comparison to period_ns (as a valid corner case duty_ns is 0 ns), then due to PWM_DUTY() macro applied on a value the result is overflowed over 8 bits, and instead of the highest bitfield duty cycle value 0xff the invalid duty cycle bitfield value 0x00 is written. For reference the LPC32xx spec defines PWMx_DUTY bitfield description is this way and it seems to be correct: [Low]/[High] = [PWM_DUTY]/[256-PWM_DUTY], where 0 < PWM_DUTY <= 255. In addition according to my oscilloscope measurements LPC32xx PWM is "tristate" in sense that it produces a wave with floating min/max voltage levels for different duty cycle values, for corner cases: PWM_DUTY == 0x01 => signal is in range from -1.05v to 0v .... PWM_DUTY == 0x80 => signal is in range from -0.75v to +0.75v .... PWM_DUTY == 0xff => signal is in range from 0v to +1.05v PWM_DUTY == 0x00 => signal is around 0v, PWM is off Due to this peculiarity on very long period ranges (less than 1KHz) and odd pre-divider values PWM generated wave does not remind a clock shape signal, but rather a heartbit shape signal with positive and negative peaks, so I would recommend to use high-speed HCLK clock as a PWM parent clock and avoid using RTC clock as a parent. The change corrects PWM output in corner cases and prevents any possible overflows in calculation of values for PWM_DUTY and PWM_RELOADV bitfields, thus helper macro definitions may be removed. Signed-off-by:
-
Vladimir Zapolskiy authored
BugLink: http://bugs.launchpad.net/bugs/1520436 As a preparatory change for switching LPC32xx mach support to common clock framework fix clk_enable/clk_disable calls without matching clk_prepare/clk_unprepare. The driver can not be used on a platform with common clock framework until clk_prepare/clk_unprepare calls are added, otherwise clk_enable calls will fail and a WARN is generated: # echo 1 > /sys/bus/platform/drivers/lpc32xx-pwm/4005c000.pwm/pwm/pwmchip0/pwm0/enable ------------[ cut here ]------------ WARNING: CPU: 0 PID: 701 at drivers/clk/clk.c:727 clk_core_enable+0x2c/0xa4() Modules linked in: sc16is7xx CPU: 0 PID: 701 Comm: sh Tainted: G W 4.3.0-rc2+ #171 Hardware name: LPC32XX SoC (Flattened Device Tree) Backtrace: [<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c) [<>] (show_stack) from [<>] (dump_stack+0x20/0x28) [<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8) [<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c) [<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xa4) [<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38) [<>] (clk_enable) from [<>] (lpc32xx_pwm_enable+0x1c/0x40) [<>] (lpc32xx_pwm_enable) from [<>] (pwm_enable+0x48/0x5c) [<>] (pwm_enable) from [<>] (pwm_enable_store+0x5c/0x78) [<>] (pwm_enable_store) from [<>] (dev_attr_store+0x20/0x2c) [<>] (dev_attr_store) from [<>] (sysfs_kf_write+0x44/0x50) [<>] (sysfs_kf_write) from [<>] (kernfs_fop_write+0x134/0x194) [<>] (kernfs_fop_write) from [<>] (__vfs_write+0x34/0xdc) [<>] (__vfs_write) from [<>] (vfs_write+0xb8/0x140) [<>] (vfs_write) from [<>] (SyS_write+0x50/0x90) [<>] (SyS_write) from [<>] (ret_fast_syscall+0x0/0x38) Signed-off-by:
-
Vladimir Zapolskiy authored
BugLink: http://bugs.launchpad.net/bugs/1520436 LPC32xx SoC has two independent PWM controllers, they have different clock parents, clock gates and even slightly different controls, and each of these two PWM controllers has one output channel. Due to almost similar controls arranged in a row it is incorrectly set that there is one PWM controller with two channels, fix this problem, which at the moment prevents separate configuration of different clock parents and gates for both PWM controllers. The change makes previous PWM device node description incompatible with this update. Signed-off-by:
-
Stefan Agner authored
BugLink: http://bugs.launchpad.net/bugs/1520436 A FTM PWM instance enables/disables three clocks: The bus clock, the counter clock and the PWM clock. The bus clock gets enabled on pwm_request, whereas the counter and PWM clocks will be enabled upon pwm_enable. The driver has three closesly related issues when enabling/disabling clocks during suspend/resume: - The three clocks are not treated differently in regards to the individual PWM state enabled/requested. This can lead to clocks getting disabled which have not been enabled in the first place (a PWM channel which only has been requested going through suspend/resume). - When entering suspend, the current behavior relies on the FTM_OUTMASK register: If a PWM output is unmasked, the driver assumes the clocks are enabled. However, some PWM instances have only 2 channels connected (e.g. Vybrid's FTM1). In that case, the FTM_OUTMASK reads 0x3 if all channels are disabled, even if the code wrote 0xff to it before. For those PWM instances, the current approach to detect enabled PWM signals does not work. - A third issue applies to the bus clock only, which can get enabled multiple times (once for each PWM channel of a PWM chip). This is fine, however when entering suspend mode, the clock only gets disabled once. This change introduces a different approach by relying on the enable and prepared counters of the clock framework and using the frameworks PWM signal states to address all three issues. Clocks get disabled during suspend and back enabled on resume regarding to the PWM channels individual state (requested/enabled). Since we do not count the clock enables in the driver, this change no longer clears the Status and Control registers Clock Source Selection (FTM_SC[CLKS]). However, since we disable the selected clock anyway, and we explicitly select the clock source on reenabling a PWM channel this approach should not make a difference in practice. Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Setting of PWM_SW_UPDATE is bit different in Intel Broxton compared to the previous generation SoCs. Previously it was OK to set the bit many times (from userspace via sysfs for example) before the PWM is actually enabled. Starting from Intel Broxton it seems that we must set PWM_SW_UPDATE only once before the PWM is enabled. Otherwise it is possible that the PWM does not start properly. Change the sequence of how PWM_SW_UPDATE is programmed so that we only set it in pwm_lpss_config() when the PWM is already enabled. The initial setting of PWM_SW_UPDATE will be done when PWM gets enabled. This should make the driver work with the previous generation Intel SoCs and Broxton. Add also small delay after the bit is set to let the hardware propagate it properly. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1520436 We have two users of core part right now. Let them to select core part automatically. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
qipeng.zha authored
BugLink: http://bugs.launchpad.net/bugs/1520436 For Broxton PWM controller, base unit is defined as 8-bit integer and 14-bit fraction, so need to update base unit setting to output wave with right frequency. Signed-off-by:
Qipeng Zha <qipeng.zha@intel.com> Acked-by:
-
Stefan Wahren authored
BugLink: http://bugs.launchpad.net/bugs/1520436Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Stefan Wahren authored
BugLink: http://bugs.launchpad.net/bugs/1520436 It's possible that the PWM clock becomes an orphan. So better check the result of clk_get_rate() in order to prevent a division by zero. Signed-off-by:
-
Stefan Wahren authored
BugLink: http://bugs.launchpad.net/bugs/1520436 Currently pwm-bcm2835 assumes a fixed clock rate and stores the resulting scaler in the driver structure. But with the upcoming PWM clock support for clk-bcm2835 the rate could change, so calculate the scaler in the ->config() callback. Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1520436 The LPSS PWM driver calls pwm_lpss_disable() when the PWM device is released (for example unexported from sysfs). This in turn calls pm_runtime_put() which makes runtime PM count to be unbalanced if the device has not been enabled at this point. This is easy to reproduce: # cd /sys/class/pwm/pwmchip0 # echo 0 > export # echo 0 > unexport The count is unbalanced and prevents the PWM device from being powered on next time. Fix this by removing ->free() callback. There are no resources to be released anyway. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1520436Signed-off-by:
-
Andy Whitcroft authored
Fix a number of KVP parameter parsing issues: 1) we should not be separating the prefix and instance numbers with an '_', 2) IPADDR/NETMASK instance 0 does have a suffix which we do not provide, 3) GATEWAY instance 0 is inconsistant, 4) IPv6 should be configured whether IPv4 is DHCP or not, and 5) DHCP mode is selected via BOOTPROTO=dhcp not DHCP=yes. BugLink: http://bugs.launchpad.net/bugs/1540586Signed-off-by:
Andy Whitcroft <apw@canonical.com>
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1540586Signed-off-by:
-
Tycho Andersen authored
Operations with the GENL_ADMIN_PERM flag fail permissions checks because this flag means we call netlink_capable, which uses the init user ns. Instead, let's introduce a new flag, GENL_UNS_ADMIN_PERM for operations which should be allowed inside a user namespace. The motivation for this is to be able to run openvswitch in unprivileged containers. I've tested this and it seems to work, but I really have no idea about the security consequences of this patch, so thoughts would be much appreciated. v2: use the GENL_UNS_ADMIN_PERM flag instead of a check in each function v3: use separate ifs for UNS_ADMIN_PERM and ADMIN_PERM, instead of one massive one Reported-by:James Page <james.page@canonical.com> Signed-off-by:
Tycho Andersen <tycho.andersen@canonical.com> CC: Eric Biederman <ebiederm@xmission.com> CC: Pravin Shelar <pshelar@ovn.org> CC: Justin Pettit <jpettit@nicira.com> CC: "David S. Miller" <davem@davemloft.net> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from linux-next commit 4a92602a) Signed-off-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by:
-
Tomas Henzl authored
BugLink: http://bugs.launchpad.net/bugs/1544679 A barrier should be added to ensure proper ordering of memory mapped writes. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Reviewed-by:
Kashyap Desai <kashyap.desai@broadcom.com> Acked-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from linux-next commit 4327614e7154a29a5db10469e49282f61598f41a) Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 Inside compat IOCTL hook of driver, driver was using wrong address of ioc->frame.raw which leads sense_ioc_ptr to be calculated wrongly and failing IOCTL. Signed-off-by:
Sumit Saxena <sumit.saxena@avagotech.com> Reviewed-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 Driver assumes that VFs always have peers present whenever they have same LD IDs. But this is not the case. This patch handles the above mentioned by explicitly checking for a peer before making HA/non-HA path decision. Signed-off-by:
Uday Lingala <uday.lingala@avagotech.com> Signed-off-by:
-
Maurizio Lombardi authored
BugLink: http://bugs.launchpad.net/bugs/1544679 The pd_seq_sync pointer can't be NULL, we have to check its entries instead. Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Acked-by:
Sumit Saxena <sumit.saxena@broadcom.com> Reviewed-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 This patch fixes online controller resets on SRIOV-enabled series of Avago controllers. 1) Remove late detection heartbeat. 2) Change in the behavior if the FW found in READY/OPERATIONAL state. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 This patch will introduce module-parameter for SCSI command timeout value and fix setting of resetwaittime beyond a value. Signed-off-by:
Kashyap Desai <kashyap.desai@avagotech.com> Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 Optimized MFI adapters' OCR path, particularly megasas_wait_for_outstanding() function. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 Make instance->adprecovery variable atomic and removes hba_lock spinlock while accessing instance->adprecovery. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 This patch will add capability in driver to tell firmware that it can throttle IOs in case controller's queue depth is downgraded post OFU (online firmware upgrade). This feature will ensure firmware can be downgraded from higher queue depth to lower queue depth without needing system reboot. Added throttling code in IO path of driver, in case OS tries to send more IOs than post OFU firmware's queue depth. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 1. For iMR controllers, firmware will report two queue depths: - Controller-wide queue depth - LDIO queue depth (240) Controller-wide queue depth will be greater among the two. Using this new feature, iMR can provide larger Queue depth(QD) for JBOD and limited QD for Virtual Disk(VD). 2. megaraid_sas driver will throttle read/write LDIOs based on "LDIO Queue Depth". 3. Dual queue depth can be enabled/disabled via module parameter. It is enabled by default if the firmware supports it. Only specific firmware builds will enable the feature. 4. Added sysfs parameter "ldio_outstanding" which permits querying the number of outstanding LDIO requests at runtime. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 build_and_issue_cmd should return SCSI_MLQUEUE_HOST_BUSY for a few error cases instead of returning 1. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 This patch will create a reply queue pool for each MSI-X index and will provide an array of base addresses instead of the single address of legacy mode. Using this new interface the driver can support higher queue depths through scattered DMA pools. If array mode is not supported driver will fall back to the legacy method of reply pool allocation. This limits controller queue depth to 1K max. To enable a queue depth of more than 1K driver requires firmware to support array mode and scratch_pad3 will provide the new queue depth value. When RDPQ is used, downgrading to an older firmware release should not be permitted. This may cause firmware fault and is not supported. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 Firmware will fill out per-LD data to tell driver whether a particular LD supports region lock bypass. If yes, then driver will send non-FP LDIO to region lock bypass FIFO. With this change in driver, firmware will optimize certain code to improve performance. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 This patch will update device Queue depth based on interface type(SAS, SATA..) for sysPDs. For Virtual disks(VDs), there will be no change in queue depth (will remain 256). To fetch interface type (SAS or SATA or FC..) of syspD, driver will send DCMD MR_DCMD_PD_GET_INFO. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 This patch adds task management for SCSI commands. Added functions are task abort and target reset. 1. Currently, megaraid_sas driver performs controller reset when any IO times out. With task management support added, task abort and target reset will be tried to recover timed out IO. If task management fails, then controller reset will be performaned. If the task management request times out, fail the request and escalate to the next level (controller reset). 2. mr_device_priv_data will be allocated for all generations of controller, but is_tm_capable flag will never be set for controllers (prior to Invader series) as firmware support is not available for task management. 3. Task management capable firmware will set is_tm_capable flag in firmware API. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 This patch will do proper error handling for DCMD timeout failure cases for Fusion adapters: 1. For MFI adapters, in case of DCMD timeout (DCMD which must return SUCCESS) driver will call kill adapter. 2. What action needs to be taken in case of DCMD timeout is decided by function dcmd_timeout_ocr_possible(). DCMD timeout causing OCR is applicable to the following commands: MR_DCMD_PD_LIST_QUERY MR_DCMD_LD_GET_LIST MR_DCMD_LD_LIST_QUERY MR_DCMD_CTRL_SET_CRASH_DUMP_PARAMS MR_DCMD_SYSTEM_PD_MAP_GET_INFO MR_DCMD_LD_MAP_GET_INFO 3. If DCMD fails from driver init path there are certain DCMDs which must return SUCCESS. If those DCMDs fail, driver bails out. For optional DCMDs like pd_info etc., driver continues without executing certain functionality. Signed-off-by:
-
Sumit Saxena authored
BugLink: http://bugs.launchpad.net/bugs/1544679 This patch will do synhronization between OCR function and AEN function using "reset_mutex" lock. reset_mutex will be acquired only in the first half of the AEN function which issues a DCMD. Second half of the function which calls SCSI API (scsi_add_device/scsi_remove_device) should be out of reset_mutex to avoid deadlock between scsi_eh thread and driver. During chip reset (inside OCR function), there should not be any PCI access and AEN function (which is called in delayed context) may be firing DCMDs (doing PCI writes) when chip reset is happening in parallel which will cause FW fault. This patch will solve the problem by making AEN thread and OCR thread mutually exclusive. Signed-off-by:
-
