summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-12-08Merge branch 'brcm/stb-smp-uart' into next/driversArnd Bergmann
This resolves a nonobvious merge conflict that I got wrong the first time. * brcm/stb-smp-uart: bus: brcmstb_gisb: save and restore GISB timeout bus: brcmstb_gisb: register the fault code hook ARM: brcmstb: Kconfig: drop unneeded symbol selections ARM: brcmstb: reintroduce SMP support ARM: brcmstb: add debug UART for earlyprintk support Conflicts: drivers/bus/brcmstb_gisb.c Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
2014-12-08thermal: cpu_cooling: initialize 'cpufreq_val' on registrationViresh Kumar
There is no point checking for validity of 'cpufreq_val' from cpufreq_thermal_notifier() every time the routine is called. Its guaranteed to be 0 on the first call but will be valid otherwise. Lets update it once while the device registers. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: do error handling at the bottom in ↵Viresh Kumar
__cpufreq_cooling_register() This makes life easy and bug free. And is scalable for future resource allocations. Acked-by: Javi Merino <javi.merino@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: Don't check is_cpufreq_valid()Viresh Kumar
Because get_cpu_frequency() has returned a valid frequency, it means that the cpufreq policy is surely valid and so no point checking that again with is_cpufreq_valid(). Get rid of the routine as well as there are no more users. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: don't iterate over all allowed_cpus to update cpufreq ↵Viresh Kumar
policy All CPUs present in 'allowed_cpus' share the same 'struct cpufreq_policy' structure and so calling cpufreq_update_policy() for each of them doesn't make sense. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: Don't match min/max frequencies for all CPUs on ↵Viresh Kumar
cooling register In __cpufreq_cooling_register() we try to match min/max frequencies for all CPUs passed in 'clip_cpus' mask. This mask is the cpumask of cpus where the frequency constraints will be applied. Same frequency constraint can be applied only to the CPUs belonging to the same cluster (i.e. CPUs sharing clock line). For all such CPUs we have a single 'struct cpufreq_policy' structure managing them and so getting policies for all CPUs wouldn't make any sense as they will all return the same pointer. So, remove this useless check of checking min/max for all CPUs. Also update doc comment to make this more obvious that clip_cpus should be same as policy->related_cpus. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: propagate error returned by idr_alloc()Viresh Kumar
We aren't supposed to return our own error type here. Return what we got. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: no need to initialze 'ret'Viresh Kumar
ret is initialized before it is used, so no need to set it to 0 in its declaration. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: no need to set cpufreq_dev to NULLViresh Kumar
It will be overwritten soon with return value of kzalloc(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: no need to set cpufreq_state to zeroViresh Kumar
Its already zero, we allocated cpufreq_dev with kzalloc. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: Pass variable instead of its type to sizeof()Viresh Kumar
Just following coding guidelines here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: Add comment to clarify relation between cooling state ↵Viresh Kumar
and frequency This wasn't explained well anywhere and should be clearly specified. Lets add a top level comment for this. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: fix doc comment over struct cpufreq_cooling_deviceViresh Kumar
cooling_cpufreq_lock isn't used to protect this structure and so the comment over it is outdated. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: random comment fixupsViresh Kumar
s/give/given Acked-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: exynos: pass cpu_present_mask to cpufreq_cooling_register()Viresh Kumar
cpufreq_cooling_register() expects mask of all the CPUs where frequency constraint is applicable. This platform has more than one CPU to which these constraints will apply and so passing mask of only CPU0 wouldn't be sufficient. Also, this platform has a single cluster of CPUs and the constraint applies to all CPUs. If CPU0 is hoplugged out then we may face strange BUGs as cpu_cooling framework isn't aware of any siblings sharing clock line. Fix it by passing cpu_present_mask to cpufreq_cooling_register(). Cc: Chanwoo Choi <cw00.choi@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Amit Daniel Kachhap <amit.daniel@samsung.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: imx: pass cpu_present_mask to cpufreq_cooling_register()Viresh Kumar
cpufreq_cooling_register() expects mask of all the CPUs where frequency constraint is applicable. This platform has more than one CPU to which these constraints will apply and so passing mask of only CPU0 wouldn't be sufficient. Also, this platform has a single cluster of CPUs and the constraint applies to all CPUs. If CPU0 is hoplugged out then we may face strange BUGs as cpu_cooling framework isn't aware of any siblings sharing clock line. Fix it by passing cpu_present_mask to cpufreq_cooling_register(). Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: db8500: pass cpu_present_mask to cpufreq_cooling_register()Viresh Kumar
cpufreq_cooling_register() expects mask of all the CPUs where frequency constraint is applicable. This platform has more than one CPU to which these constraints will apply and so passing mask of only CPU0 wouldn't be sufficient. Also, this platform has a single cluster of CPUs and the constraint applies to all CPUs. If CPU0 is hoplugged out then we may face strange BUGs as cpu_cooling framework isn't aware of any siblings sharing clock line. Fix it by passing cpu_present_mask to cpufreq_cooling_register(). Cc: Hongbo Zhang <hongbo.zhang@linaro.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08thermal: cpu_cooling: check for the readiness of cpufreq layerEduardo Valentin
In this patch, the cpu_cooling code checks for the usability of cpufreq layer before proceeding with the CPU cooling device registration. The main reason is: CPU cooling device is not usable if cpufreq cannot switch frequencies. Similar checks are spread in thermal drivers. Thus, the advantage now is to have the check in a single place: cpu cooling device registration. For this reason, this patch also updates the existing drivers that depend on CPU cooling to simply propagate the error code of the cpu cooling registration call. Therefore, in case cpufreq is not ready, the thermal drivers will still return -EPROBE_DEFER, in an attempt to try again when cpufreq layer gets ready. Cc: devicetree@vger.kernel.org Cc: Grant Likely <grant.likely@linaro.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Cc: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Zhang Rui <rui.zhang@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-12-08blk-mq: re-check for available tags after running the hardware queueJens Axboe
If we run out of tags and have to sleep, we run the hardware queue to kick pending IO into gear. During that run, we may have completed requests, so re-check if we have free tags before going to sleep. Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-08blk-mq: fix hang in bt_get()Bart Van Assche
Avoid that if there are fewer hardware queues than CPU threads that bt_get() can hang. The symptoms of the hang were as follows: * All tags allocated for a particular hardware queue. * (nr_tags) pending commands for that hardware queue. * No pending commands for the software queues associated with that hardware queue. Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-08Merge remote-tracking branch 'scsi-queue/drivers-for-3.19' into for-linusJames Bottomley
Conflicts: drivers/scsi/scsi_debug.c Agreed and tested resolution to a merge problem between a fix in scsi_debug and a driver update Signed-off-by: James Bottomley <JBottomley@Parallels.com>
2014-12-08Merge remote-tracking branch 'scsi-queue/core-for-3.19' into for-linusJames Bottomley
2014-12-08hwmon: (tmp401) Detect TMP435 on all addresses it supportsGuenter Roeck
TMP435 supports a range of I2C addresses, not just 0x4c. Cc: Patrick Titiano <ptitiano@baylibre.com> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-12-08ALSA: jack: Add dummy snd_jack_set_key() definitionTakashi Iwai
For fixing a build error with CONFIG_SND_JACK=n sound/soc/codecs/ts3a227e.c:223:2: error: implicit declaration of function ‘snd_jack_set_key’ [-Werror=implicit-function-declaration] Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-12-08kobject: grammar fixJohn de la Garza
Signed-off-by: John de la Garza <john@jjdev.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2014-12-08Merge tag 'asoc-v3.19' of ↵Takashi Iwai
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Updates for v3.19 Lots and lots of changes this time around, the usual set of driver updates and a huge bulk of cleanups from Lars-Peter. Probably the most interesting thing for most users is the Intel driver updates which will (with some more machine integration work) enable support for newer x86 laptops. - Conversion of AC'97 drivers to use regmap, bringing us closer to the removal of the ASoC level I/O code. - Clean up a lot of old drivers that were open coding things that have subsequently been implemented in the core. - Some DAPM performance improvements. - Removal of the now seldom used CODEC mutex. - Lots of updates for the newer Intel SoC support, including support for the DSP and some Cherrytrail and Braswell machine drivers. - Support for Samsung boards using rt5631 as the CODEC. - Removal of the obsolete AFEB9260 machine driver. - Driver support for the TI TS3A227E headset driver used in some Chrombeooks.
2014-12-08dmaengine: fsl-edma: fix calculation of remaining bytesStefan Agner
If the current transfer control descriptor (TCD) was not yet started, the address will be the same as the initial address. Hence test if the current address is less than or equal to the start address of each TCD. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2014-12-08Merge remote-tracking branches 'asoc/topic/wm9090', 'asoc/topic/wm9712' and ↵Mark Brown
'asoc/topic/wm9713' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/wm8991', 'asoc/topic/wm8993', ↵Mark Brown
'asoc/topic/wm8994', 'asoc/topic/wm8995' and 'asoc/topic/wm9081' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/wm8978', 'asoc/topic/wm8983', ↵Mark Brown
'asoc/topic/wm8985', 'asoc/topic/wm8988' and 'asoc/topic/wm8990' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/wm8955', 'asoc/topic/wm8960', ↵Mark Brown
'asoc/topic/wm8961', 'asoc/topic/wm8962' and 'asoc/topic/wm8974' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/wm8776', 'asoc/topic/wm8804', ↵Mark Brown
'asoc/topic/wm8900', 'asoc/topic/wm8903' and 'asoc/topic/wm8940' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/wm8711', 'asoc/topic/wm8728', ↵Mark Brown
'asoc/topic/wm8731', 'asoc/topic/wm8737' and 'asoc/topic/wm8750' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/wm8350', 'asoc/topic/wm8400', ↵Mark Brown
'asoc/topic/wm8510', 'asoc/topic/wm8523' and 'asoc/topic/wm8580' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/twl6040', 'asoc/topic/uda134x', ↵Mark Brown
'asoc/topic/uda1380' and 'asoc/topic/wl1273' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/tlv320aic32x4', ↵Mark Brown
'asoc/topic/tlv320aic3x', 'asoc/topic/tlv320dac33', 'asoc/topic/ts3a227e' and 'asoc/topic/twl4030' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/tas2552', 'asoc/topic/tegra', ↵Mark Brown
'asoc/topic/tfa9879', 'asoc/topic/tlv320aic23' and 'asoc/topic/tlv320aic31xx' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/ssm4567', 'asoc/topic/sta32x', ↵Mark Brown
'asoc/topic/sta350', 'asoc/topic/sta529' and 'asoc/topic/stac9766' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/sh', 'asoc/topic/sigmadsp', ↵Mark Brown
'asoc/topic/simple', 'asoc/topic/sirf' and 'asoc/topic/sn95031' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/rt5645', 'asoc/topic/rt5670', ↵Mark Brown
'asoc/topic/rt5677', 'asoc/topic/samsung' and 'asoc/topic/sgtl5000' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/rcar', 'asoc/topic/rockchip', ↵Mark Brown
'asoc/topic/rt286' and 'asoc/topic/rt5631' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/multi-codec', ↵Mark Brown
'asoc/topic/mxs-saif', 'asoc/topic/mxs-sgtl5000', 'asoc/topic/omap' and 'asoc/topic/pxa' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/max98088', 'asoc/topic/max98090', ↵Mark Brown
'asoc/topic/max98095', 'asoc/topic/max9850' and 'asoc/topic/mop500' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/hdmi', 'asoc/topic/intel', ↵Mark Brown
'asoc/topic/jack', 'asoc/topic/jz4740' and 'asoc/topic/lm49453' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/fsl', 'asoc/topic/fsl-card', ↵Mark Brown
'asoc/topic/fsl-dt' and 'asoc/topic/fsl-ssi' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/davinci', 'asoc/topic/doc', ↵Mark Brown
'asoc/topic/dpcm', 'asoc/topic/dwc' and 'asoc/topic/fsi' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/cs4265', 'asoc/topic/cs4271', ↵Mark Brown
'asoc/topic/cs42l51' and 'asoc/topic/cs42l73' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/codec-mutex', ↵Mark Brown
'asoc/topic/compress' and 'asoc/topic/cq93vc' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/ak4671', 'asoc/topic/alc5623', ↵Mark Brown
'asoc/topic/alc5632', 'asoc/topic/arizona' and 'asoc/topic/atmel' into asoc-next
2014-12-08Merge remote-tracking branches 'asoc/topic/adav80x', 'asoc/topic/adsp', ↵Mark Brown
'asoc/topic/ak4535', 'asoc/topic/ak4641' and 'asoc/topic/ak4642' into asoc-next