OPP pointers cannot be expected to be valid beyond the boundary
of rcu_read_lock and rcu_read_unlock. Unfortunately, the current
exynos4 busfreq driver does not honor the usage constraint and stores
the OPP pointer in struct busfreq_data. This could potentially
become invalid later such as: across devfreq opp change decisions,
resulting in unpredictable behavior.
To fix this, we introduce a busfreq specific busfreq_opp_info
structure which is used to handle OPP information. OPP information
is de-referenced to voltage and frequency pairs as needed into
busfreq_opp_info structure and used as needed.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
OPP pointers are protected by RCU locks, the pointer validity is
permissible only under the section of rcu_read_lock to rcu_read_unlock
Add documentation to the effect.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
OPP pointer is RCU protected, hence after finding it, de-reference
also should be protected with the same RCU context else the OPP
pointer may become invalid.
Reported-by: Jack Mitchell <jack@embed.me.uk>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Tested-by: Jack Mitchell <jack@embed.me.uk>
Acked-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
OPP pointer is RCU protected, hence after finding it, de-reference
also should be protected with the same RCU context else the OPP
pointer may become invalid.
Reported-by: Alexander Holler <holler@ahsoftware.de>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Acked-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Introduce an IP reset API for use on DaVinci SoC.
There is no existing "reset" framework support for SoC devices.
The remoteproc driver needs explicit control of the DSP's reset line.
To support this, a new DaVinci specific API is added.
This private API will disappear with DT migration. Some discussion
regarding a proposed DT "reset" binding is here:
https://patchwork.kernel.org/patch/1635051/
Modify davinci_clk_init() to set clk "reset" function for clocks
that indicate PSC_LRST support. Also fix indentation issue with
function opening curly brace.
Signed-off-by: Robert Tivy <rtivy@ti.com>
[nsekhar@ti.com: rename davinci_psc_config_reset() to davinci_psc_reset()]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
When a transition to the D3cold power state is requested,
acpi_device_set_power() first carries out a transition to D3hot and
then turns off the device's power resources. However, it fails to
update the device's power.state field appropriately and D3hot is
stored in it as a result.
Fix this, but make sure that the device's power state will be
D3hot if its power resources cannot be turned off in the final
step.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make acpi_power_state_string() return "D3cold" as the string
representation of ACPI power state D3cold instead of "D3" returned
currently, which is confusing.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After the only user of acpi_power_on_resources(),
acpi_bus_init_power(), has been changed to avoid calling it
for state equal to ACPI_STATE_D3_COLD, it doesn't have to special
case that state any more.
For this reason, modify the checks in acpi_power_on_resources()
so that it returns -EINVAL for ACPI_STATE_D3_COLD as it should.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI specitication (ACPI 5, Sections 7.2.8 - 7.2.11) requires
that the _PSn (n = 0..3) method, if present, be executed after the
power resources for the given device power state have been set
appropriately. However, acpi_device_set_power() does that only
if the new power state is going to be higher-power (lower-number)
than the power state the device is in already. Otherwise, the
ordering is reverse to protect against situations in which _PSn
might access device registers unavailable after configuring the
power resources for power state Dn (D3 meaning D3hot).
Such situations are very unlikely to happen, though, and _PSn may
actually be implemented with the assumption that power resources
have been configured for power state Dn in advance, so change the
code to follow the specification literally.
This change was previously porposed in a different form by Lv Zheng.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
To reduce code duplication between acpi_device_set_power() and
acpi_bus_init_power(), introduce a new helper function for executing
ACPI devices' _PSn (n = 0..3) methods, acpi_dev_pm_explicit_set().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI specification requires the _PSC method to be present under
a device object if its power state cannot be inferred from the states
of power resources used by it (ACPI 5, Section 7.6.2). However, it
also requires that (for power states D0-D2 and D3hot) if the _PSn
(n = 0, 1, 2, 3) method is present under the device object, it also
must be executed after the power resources have been set
appropriately for the device to go into power state Dn (D3 means
D3hot in this case). Thus it is not clear from the specification
whether or not the _PSn method should be executed if the initial
configuraion of power resources used by the device indicates power
state Dn and the _PSC method is not present.
The current implementation of acpi_bus_init_power() is based on the
assumption that it should not be necessary to execute _PSn in the
above situation, but experience shows that in fact that assumption
need not be satisfied. For this reason, make acpi_bus_init_power()
always execute _PSn if the initial configuration of device power
resources indicates power state Dn.
Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44156
Reported-by: Alan Zimmerman <alan.zimm@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35
[Note: There are more than one broken setups in the bug. This fixes one.]
Reported-by: Martins <andrissr@inbox.lv>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59628
Reported-by: Roland Gruber <post@rolandgruber.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
prima2 and marco has different memory base, the old code will
fail if we enable DEBUG_LL in marco.
this patch adds two debuf port, while debugging, we select one
of PRIMA2 and MARCO debug ports, in the products, we disable
DEBUG_LL.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
this patch adds tick timer, smp entries and generic DT machine
for SiRFmarco dual-core SMP chips.
with the added marco, we change the defconfig, using the same
defconfig, we get a zImage which can work on both prima2 and
marco.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Cc: Mark Rutland <mark.rutland@arm.com>
in Marco, we will use GIC. this patch prepares the handle_irq for prima2
to avoid the compiling errors since we want only one defconfig and zImage
for both prima2 and marco that means we will need handle_irq for both.
Signed-off-by: Baohua Song <Baohua.Song@csr.com>
marco has SET/CLEAR registers pair for rstc to avoid read-modify-write,
this patch detects the mach typer and access registers based on SoC.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Marco timer has different timer IP with prima2, so rename the current timer
to timer-prima2 so that we can add timer-marco.
at the same time, if we don't find prima2 timer node in dt, don't panic the
system as we will make prima2 and marco use same kernel image.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
prima2 and marco have diffetent l2 cache configuration, so
we initialize l2x0 cache based on dtb given to kernel.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
prima2 and marco have different memory base address. prima2
begins from 0 and marco begins from 0x40000000.
This patch enables AUTO_ZRELADDR so that kernel can detect
the physical address automatically.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
CC: Mark Rutland <mark.rutland@arm.com>
SiRFmarco is a dual-core cortex-a9 SMP SoC from CSR. this patch
adds the .dtsi and a basic evb board .dts for it.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Instead of having its own set of macros, use the Kernel default
ones for debug, error and info.
While here, do some cleanup on the debug printk's.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Reorder functions to have everything related to stats/status read
close. That will make the file more organized as other stats
routines will be added.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Split the logic that reads the status from the DVB callback. That
helps to properly return an error code, if status read fails.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The read/write errors are not handled well on get_frontend. Fix it,
by letting the frontend cached values to represent the DVB properties
that were successfully retrieved.
While here, use "c" for dtv_frontend_properties cache, instead of
"p", as this is more common.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Document what the fix-up is does and make it more robust by ensuring
that it is only applied to the USB interface that corresponds to the
mouse (sony_report_fixup() is called once per interface during probing).
Cc: linux-input@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch implements extent caching in case of file reading.
While reading a file, currently, UDF reads metadata serially
which takes a lot of time depending on the number of extents present
in the file. Caching last accessd extent improves metadata read time.
Instead of reading file metadata from start, now we read from
the cached extent.
This patch considerably improves the time spent by CPU in kernel mode.
For example, while reading a 10.9 GB file using dd:
Time before applying patch:
11677022208 bytes (10.9GB) copied, 1529.748921 seconds, 7.3MB/s
real 25m 29.85s
user 0m 12.41s
sys 15m 34.75s
Time after applying patch:
11677022208 bytes (10.9GB) copied, 1469.338231 seconds, 7.6MB/s
real 24m 29.44s
user 0m 15.73s
sys 3m 27.61s
[JK: Fix bh refcounting issues, simplify initialization]
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Signed-off-by: Bonggil Bak <bgbak@samsung.com>
Signed-off-by: Jan Kara <jack@suse.cz>
The pin in question is muxed between GPIO7 and PWM1. For backlight control
there is a custom code in board-zoom-display to control the backlight.
No need to request the GPIO7 - which was failing since the way it is
requested no longer valid: twl's gpio range is allocated dynamically.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
With the PWM backed driver the PMU_STAT led's brighness can be controlled.
This needs the new drivers for the TWL PWM/LED to work.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
New PWM drivers are being prepared for twl series which will enable the use
of all PWMs (PWMs and LEDs).
They are implemented as generic PWM drivers to be able to use them for different
purposes.
The current platform code was broken: the leds_pwm driver was not able to pick
up the PWM since the pwm_id was incorrect.
With the other patches we will be able to control the followings:
LCD backlight via pwm-backlight driver
Keypad leds via leds_pwm driver as normal LED
Charging indicator via leds_pwm driver as normal LED
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Boards with special audio routing can pass a custom omap_tw4030_pdata to the
audio machine driver.
At the same time update the board files using the same audio driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Select the most commonly used audio configuration on boards with twl4030
audio:
Headset, Handsfree output and Line in input
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
The HS extmute is not used on Zoom2 boards. Furthermore the GPIO153 is used
as IRQ for the TSC2004 touchscreen controller - for which we do not have
driver upstream, yet.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Some architectures (e.g. blackfin) provide gpio API without requiring
GPIOLIB support (ARCH_WANT_OPTIONAL_GPIOLIB). devm_gpio_* functions
should also work for these architectures, since they do not really
depend on GPIOLIB.
Add a new option GPIO_DEVRES (enabled by default) to control the build
of devres.c. It also removes the empty version of devm_gpio_*
functions for !GENERIC_GPIO build from linux/gpio.h, and moves the
function declarations from asm-generic/gpio.h into linux/gpio.h.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The struct gpio_chip is only defined inside #ifdef CONFIG_GPIOLIB,
but it's referenced by gpiochip_add_pin_range() and
gpiochip_remove_pin_ranges() which are outside #ifdef CONFIG_GPIOLIB.
Thus, we see the following warning when building blackfin image, where
GPIOLIB is not required.
CC arch/blackfin/kernel/bfin_gpio.o
CC init/version.o
In file included from arch/blackfin/include/asm/gpio.h:321,
from arch/blackfin/kernel/bfin_gpio.c:15:
include/asm-generic/gpio.h:298: warning: 'struct gpio_chip' declared inside parameter list
include/asm-generic/gpio.h:298: warning: its scope is only this definition or declaration, which is probably not what you want
include/asm-generic/gpio.h:304: warning: 'struct gpio_chip' declared inside parameter list
Move pinctrl trunk into #ifdef CONFIG_GPIOLIB to fix the warning,
since it appears that pinctrl gpio range support depends on GPIOLIB.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
sizeof when applied to a pointer typed expression gives the size of
the pointer
The semantic patch that makes this output is available
in scripts/coccinelle/misc/noderef.cocci.
More information about semantic patching is available at
http://coccinelle.lip6.fr/
Signed-off-by: Laurent Navet <laurent.navet@gmail.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
in probe() entry of i2c_driver, set the of node of adapter and
call of_i2c_register_devices to register all i2c_client from
dt child-nodes
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
cmd_err is used to handle error code, so it should not be unsigned.
This fixes the following warning when building with W=1 option:
drivers/i2c/busses/i2c-mxs.c: In function 'mxs_i2c_xfer_msg':
drivers/i2c/busses/i2c-mxs.c:331:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: stable@kernel.org
