With this patch the stmmac fails in case of the phy device
is not found; w/o this fix the mdio can be register twice when
do down/up the iface and this is not correct.
Reported-by: Stas <stsp@list.ru>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the name of the macro used for
debugging the transmit process. I used STMMAC_TX_DEBUG
instead of STMMAC_XMIT_DEBUG.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Using memset does not set an array of integers properly. Replace with a
loop to set each element properly.
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Fixes for one major lockdep warning, one oops reported by a few people, and
fix for a long hang on some gpu engines.
* 'drm-nouveau-fixes-3.8' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau: add lockdep annotations
drm/nv50/fb: Fix nullptr-deref on IGPs
drm/nouveau: use different register to wait for secret scrubber
This update adds a debugfs interface to modify a pin configuration
for a given state in the pinctrl map. This allows to modify the
configuration for a non-active state, typically sleep state.
This configuration is not applied right away, but only when the state
will be entered.
This solution is mandated for us by HW validation: in order
to test and verify several pin configurations during sleep without
recompiling the software.
Signed-off-by: Laurent Meunier <laurent.meunier@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit 70d46a2 "i2c: at91: add dt support to i2c-at91"
added DT only support for at91sam9x5. Building i2c-at91
without CONFIG_OF now warns about at91sam9x5_config as
being unused.
drivers/i2c/busses/i2c-at91.c:556:30: warning: 'at91sam9x5_config' defined but not used [-Wunused-variable]
Move at91sam9x5_config under the defined(CONFIG_OF)
guard as new AT91 SoCs will be DT only.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
The iSMT (Intel SMBus Message Transport) supports multi-master I2C/SMBus,
as well as IPMI. It's operation is DMA-based and utilizes descriptors to
initiate transactions on the bus.
The iSMT hardware can act as both a master and a target, although this
driver only supports being a master.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Bill Brown <bill.e.brown@intel.com>
Tested-by: Seth Heasley <seth.heasley@intel.com>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
By default there should be no stop bit on I2C between single messages
within transfers. Fix the driver to comply and only send a stop bit at
the end of transfers or if I2C_M_STOP is set.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
Eliminate an open-coded "goto" loop by introducing a function.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
In a timeout case return an error immediately from the driver's
.master_xfer() method, instead of continuing and letting higher layers
fail.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
This patch drops the i2c timing tables from this driver and instead
derives the timing based from the requested clock sleep. The timing
tables were completely wrong anyway when observed on a scope.
This new algorithm is also only derived by using a scope, but it seems
to produce much more accurate result.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
[wsa: changed messages from dev_err to dev_warn]
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
This the basic functional Invensense MPU6050 Device driver.
Signed-off-by: Ge Gao <ggao@invensense.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Make it harder to do mistakes by introducing the actual
defined ABx500 IRQ number into the IRQ cluster definitions.
Deduct cluster offset from the GPIO offset to make each
cluster coherent.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The ABx500 GPIO controller used to provide a set of virtual contiguous
IRQs for use by sub-devices, but they have been removed after a request
from Mainline Maintainers. Now the AB8500 core driver deals with almost
all IRQ related issues instead.
The ABx500 GPIO driver is now only used to convert between GPIO and IRQ
numbers which is actually quite difficult, as the ABx500 GPIO's
associated IRQs are clustered together throughout the interrupt number
space at irregular intervals. To solve this quandary, we have placed the
read-in values into the existing cluster information table to use during
conversion.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[Moved irq_base removal into this patch]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In its current state the gpio-ab8500 driver looks after some GPIO
lines found on the AB8500 MFD chip. It also controls all of its
own IRQ handling for these GPIOs by inventing some virtual IRQs
and handing those out to sub-devices. There has been quite a bit
of controversy over this and it was a contributing factor to the
driver being marked as BROKEN in Mainline.
The reason for adopting this method was due to added complexity
in the hardware. Unusually, each GPIO has two separate IRQs
associated with it, one for a rising and a different one for a
falling interrupt. Using this method complicates matters further
because the GPIO IRQs are actually sandwiched between a bunch
of IRQs which are handled solely by the AB8500 core driver.
The best way for us to take this forward is to get rid of the
virtual IRQs and only hand out the rising IRQ lines. If a
sub-driver wishes to request a falling interrupt, they can do
so by requesting a rising line in the normal way. They just
have to add IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_EDGE_BOTH, if
they require both in the flags. Then if a falling IRQ is
triggered, the AB8500 core driver will know how to handle the
added complexity accordingly. This should greatly simply things.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[Augment to keep irq_base for a while (removed later)]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
mwait_idle() is a C1-only idle loop intended to be more efficient
than HLT, starting on Pentium-4 HT-enabled processors.
But mwait_idle() has been replaced by the more general
mwait_idle_with_hints(), which handles both C1 and deeper C-states.
ACPI processor_idle and intel_idle use only mwait_idle_with_hints(),
and no longer use mwait_idle().
Here we simplify the x86 native idle code by removing mwait_idle(),
and the "idle=mwait" bootparam used to invoke it.
Since Linux 3.0 there has been a boot-time warning when "idle=mwait"
was invoked saying it would be removed in 2012. This removal
was also noted in the (now removed:-) feature-removal-schedule.txt.
After this change, kernels configured with
(CONFIG_ACPI=n && CONFIG_INTEL_IDLE=n) when run on hardware
that supports MWAIT will simply use HLT. If MWAIT is desired
on those systems, cpuidle and the cpuidle drivers above
can be enabled.
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: x86@kernel.org
From Shawn Guo:
mxs soc changes for 3.9
- A couple of optimization on timer
- Some updates on mxs_defconfig
* tag 'mxs-soc-3.9' of git://git.linaro.org/people/shawnguo/linux-2.6:
ARM: mxs_defconfig: Select CONFIG_DEVTMPFS_MOUNT
ARM: mxs: decrease mxs_clockevent_device.min_delta_ns to 2 clock cycles
ARM: mxs: use apbx bus clock to drive the timers on timrotv2
ARM: mxs: Update mxs_defconfig
Enable ACPI SCI during suspend so that SCI can be used
as wake events for PM_SUSPEND_FREEZE.
For S3/S4 transition,
We disable all GPEs in suspend_ops->prepare_late() to
fix a problem that GPEs may trigger SCI before
arch_suspend_disable_irqs() is run.
So it is safe to leave the SCI enabled until
arch_suspend_irq_disable() is run.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PM_SUSPEND_FREEZE state is a general state that
does not need any platform specific support, it equals
frozen processes + suspended devices + idle processors.
Compared with PM_SUSPEND_MEMORY,
PM_SUSPEND_FREEZE saves less power
because the system is still in a running state.
PM_SUSPEND_FREEZE has less resume latency because it does not
touch BIOS, and the processors are in idle state.
Compared with RTPM/idle,
PM_SUSPEND_FREEZE saves more power as
1. the processor has longer sleep time because processes are frozen.
The deeper c-state the processor supports, more power saving we can get.
2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get
more power saving from the devices that does not have good RTPM support.
This state is useful for
1) platforms that do not have STR, or have a broken STR.
2) platforms that have an extremely low power idle state,
which can be used to replace STR.
The following describes how PM_SUSPEND_FREEZE state works.
1. echo freeze > /sys/power/state
2. the processes are frozen.
3. all the devices are suspended.
4. all the processors are blocked by a wait queue
5. all the processors idles and enters (Deep) c-state.
6. an interrupt fires.
7. a processor is woken up and handles the irq.
8. if it is a general event,
a) the irq handler runs and quites.
b) goto step 4.
9. if it is a real wake event, say, power button pressing, keyboard touch, mouse moving,
a) the irq handler runs and activate the wakeup source
b) wakeup_source_activate() notifies the wait queue.
c) system starts resuming from PM_SUSPEND_FREEZE
10. all the devices are resumed.
11. all the processes are unfrozen.
12. system is back to working.
Known Issue:
The wakeup of this new PM_SUSPEND_FREEZE state may behave differently
from the previous suspend state.
Take ACPI platform for example, there are some GPEs that only enabled
when the system is in sleep state, to wake the system backk from S3/S4.
But we are not touching these GPEs during transition to PM_SUSPEND_FREEZE.
This means we may lose some wake event.
But on the other hand, as we do not disable all the Interrupts during
PM_SUSPEND_FREEZE, we may get some extra "wakeup" Interrupts, that are
not available for S3/S4.
The patches has been tested on an old Sony laptop, and here are the results:
Average Power:
1. RPTM/idle for half an hour:
14.8W, 12.6W, 14.1W, 12.5W, 14.4W, 13.2W, 12.9W
2. Freeze for half an hour:
11W, 10.4W, 9.4W, 11.3W 10.5W
3. RTPM/idle for three hours:
11.6W
4. Freeze for three hours:
10W
5. Suspend to Memory:
0.5~0.9W
Average Resume Latency:
1. RTPM/idle with a black screen: (From pressing keyboard to screen back)
Less than 0.2s
2. Freeze: (From pressing power button to screen back)
2.50s
3. Suspend to Memory: (From pressing power button to screen back)
4.33s
>From the results, we can see that all the platforms should benefit from
this patch, even if it does not have Low Power S0.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
i2400m_net_wake_tx() sets ->wake_tx_skb with the given skb if
->wake_tx_ws is not pending; however, i2400m_wake_tx_work() could have
just started execution and haven't fetched -><wake_tx_skb yet. The
previous packet will be leaked.
Update ->wake_tx_skb handling.
* i2400m_net_wake_tx() now tests whether the previous ->wake_tx_skb
has been consumed by ->wake_tx_ws instead of testing work_pending().
* i2400m_net_wake_stop() is simplified similarly. It always puts
->wake_tx_skb if non-NULL.
* Spurious ->wake_tx_skb dereference outside critical section dropped
from i2400m_wake_tx_work().
Only compile tested.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Dan Williams <dcbw@redhat.com>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: linux-wimax@intel.com
Cc: wimax@linuxwimax.org
* Drop unnesssary delayd_work_pending() tests.
* Unify scan_event_{now|later} by using mod_delayed_work() w/ 0 delay
for scan_event_now.
* Make ipw2200 scan_event handling match ipw2100 - use
mod_delayed_work() w/ 0 delay for immediate scanning.
Only compile tested.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Cc: linux-wireless@vger.kernel.org
Partly a case of removing unused headers and partly a case
of ifdefing out the iio_trigger_ops structures. This has
come about because of an 'unusual' separation of code in this
driver.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
With the recent changes in cpufreq core, we just need to set mask of all
possible cpus into policy->cpus. Rest would be done by core.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The Marvell Kirkwood SoCs have simple cpufreq support in hardware. The
CPU can either use the a high speed cpu clock, or the slower DDR
clock. Add a driver to swap between these two clock sources.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add a P-state driver for the Intel Sandy bridge processor. In cpufreq
terminology this driver implements a scaling driver with an internal
governor.
When built into the the kernel this driver will be the preferred
scaling driver for Sandy bridge processors.
In addition to the interfaces provided by the cpufreq subsystem for
controlling scaling drivers. The user may control the behavior of the
driver via three sysfs files located in
"/sys/devices/system/cpu/intel_pstate".
max_perf_pct: limits the maximum P state that will be requested by
the driver stated as a percentage of the avail performance.
min_perf_pct: limits the minimum P state that will be requested by
the driver stated as a percentage of the avail performance.
no_turbo: limits the driver to selecting P states below the turbo
frequency range.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The sysfs files for cpufreq_stats are created in cpufreq_stats_create_table()
called from cpufreq_stat_notifier_policy() when a policy is added to
the cpu. cpufreq_stats_create_table() will not be called if the
scaling driver does not export a frequency table to cpufreq. Use the
same fence on tear down.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Scaling drivers that implement internal governors do not have governor
structures assocaited with them. Only track the name of the governor
associated with the CPU if the driver does not implement
cpufreq_driver.setpolicy()
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Scaling drivers that implement cpufreq_driver.setpolicy() have
internal governors that do not signal changes via
cpufreq_notify_transition() so the frequncy in the policy will almost
certainly be different than the current frequncy. Only call
cpufreq_out_of_sync() when the underlying driver implements
cpufreq_driver.target()
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Scaling drivers that implement the cpufreq_driver.setpolicy() versus
the cpufreq_driver.target() interface do not set policy->cur.
Normally policy->cur is set during the call to cpufreq_driver.target()
when the frequnecy request is made by the governor.
If the scaling driver implements cpufreq_driver.setpolicy() and
cpufreq_driver.get() interfaces use cpufreq_driver.get() to retrieve
the current frequency.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use the new spi_sync_transfer() helper function instead of open-coding it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use the new spi_sync_transfer() helper function instead of open-coding it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The following warning is generated by sparse:
drivers/staging/iio/adc/mxs-lradc.c:118:47: warning: duplicate const
Remove the duplicate const.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Re-implement gpiochip_find_base using the list of chips instead of the
global gpio_desc[] array. This makes it both simpler and more efficient,
and is needed to remove the global descriptors array.
The new code should preserve the exact same GPIO number assignment
policy as the code it is replacing. There shouldn't be any visible
change to the assigned GPIO numbers.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
[grant.likely: Added comment about assignment policy]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
This makes the code both simpler and faster compared to parsing the GPIO
number space.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Add a list member to gpio_chip that allows all chips to be parsed
quickly. The current method requires parsing the entire GPIO integer
space, which is painfully slow. Using a list makes many chip operations
that involve lookup or parsing faster, and also simplifies the code. It
is also necessary to eventually get rid of the global gpio_desc[] array.
The list of gpio_chips is always ordered by base GPIO number to ensure
chips traversal is done in the right order.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
randconfig complains about:
drivers/power/da9030_battery.c:113: error: field ‘nb’ has incomplete type
because there is no direct include for notifier.h which defines
struct notifier_block.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
Remove the assumption that cstate_tables are
indexed by MWAIT flag values. Each entry
identifies itself via its own flags value.
This change is needed to support multiple states
that share the same MWAIT flags.
Note that this can have an effect on what state is described
by 'N' on cmdline intel_idle.max_cstate=N on some systems.
intel_idle.max_cstate=0 still disables the driver
intel_idle.max_cstate=1 still results in just C1(E)
However, "place holders" in the sparse C-state name-space
(eg. Atom) have been removed.
Signed-off-by: Len Brown <len.brown@intel.com>
Cosmetic only.
Replace use of MWAIT_MAX_NUM_CSTATES with CPUIDLE_STATE_MAX.
They are both 8, so this patch has no functional change.
The reason to change is that intel_idle will soon be able
to export more than the 8 "major" states supported by MWAIT.
When we hit that limit, it is important to know
where the limit comes from.
Signed-off-by: Len Brown <len.brown@intel.com>
