logs are available here:
http://www.pwsan.com/omap/testlogs/prcm_fixes_b_3.8-rc/20130102120724/
The 3730 Beagle XM here has an intermittent failure mounting SD root,
but the suspicion right now is that this is due to a failing SD card,
rather than any change introduced by these patches.
This second version includes a few changes requested by Tony Lindgren.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQ5IkPAAoJEMePsQ0LvSpL/RQQAJUbGPZTdMEH2DHHDVPRxgBE
bWEg0RQfzheOLfFvfot2tReJoN7GMlhzcDq2DSHZLwp5b9XgOgOJdNdldvrvFljD
p3QEy+y/7ZSgsAdgDV33vAAUAv4c0CIh0cKgw3JwOn/dqVSbiMXXqXe1kZe419gi
bbJHBr6fZH63qvGzkjI17vl3lDq6RsX7vgtEQ9TeiTMUAOnrXzp3rt9oDNVsChSs
Ml6h1WKnxQdMFjbNNmBOUGltSg7O1rwuWeS/9mg77yV3lIZ5QdmAVlcq6lUB+jqy
CWhAYbrhXMBPYFaxzw0I8h00m0VNBSOZf2e1d5Lw8wU8dVxQ3PVZCI4SyRssBdd3
T+91zy4Axmo+SWrkTxpq+yE2Sn1AMZC4mJwI62UhCZV8TPPvek8IlK3ktKeV97ql
BNehuGYqbc3u5TiIjO8K+akTBKKTVDdXaah9ms8rtQ4hcwLwC0VA/71R9qaQJx3E
mGf3pRK6FSV83vEMrGb2mRk3ByGHzpYlMD0sb4+0OFvkj5Hyv7OCPb0TJapn6OPO
vpeG6pIbHN3p/mKrj/RNHVtvpV5/mHJmMOXgkcXLcdlZhsnGE21dqw/vPrvjf3Wa
SnUp7q48/4a2FP2d0KpQ+CpHyLyNEs4x4zs9hfjHGsYs1fWBwdu0+/8rVPaAEjjB
iUa8sxlv/1o0rJfiyRkd
=oUTN
-----END PGP SIGNATURE-----
Merge tag 'omap-fixes-a2-for-v3.8-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8-rc2/fixes
Some OMAP PRCM and sparse fixes against v3.8-rc1. A basic set of test
logs are available here:
http://www.pwsan.com/omap/testlogs/prcm_fixes_b_3.8-rc/20130102120724/
The 3730 Beagle XM here has an intermittent failure mounting SD root,
but the suspicion right now is that this is due to a failing SD card,
rather than any change introduced by these patches.
This second version includes a few changes requested by Tony Lindgren.
Linux was granted a new system call to load modules by file descriptor
in commit 34e1169d99 ("module: add syscall to load module from fd").
Wire it up for ia64 (ready for the Chrome port :-)
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This try to reset the dma engine when performing gpu reset. Hopefully
bringing back the gpu dma engine in sane state.
v2: agd5f: fix dma reset on cayman/TN, add support for SI
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To help debug dma related lockup.
v2: agd5f: update SI as well
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Print 32dword before last know rptr as problem most likely comes
from previous command. Also small cosmetic change to the printing.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
count must be a multiple of 2. Fixes crashes on
R6xx chips reported by a number of people.
Cc: Borislav Petkov <bp@alien8.de>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Tested-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Apple cards do not provide data tables in the vbios
so we have to hard code the connector parameters
in the driver.
Reported-by: Albrecht Dreß <albrecht.dress@arcor.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The bestcomm dma hardware, and some of its users like the FEC ethernet
component, is used in different FreeScale parts, including non-powerpc
parts like the ColdFire MCF547x & MCF548x families. Don't keep the
driver hidden in arch/powerpc where it is inaccessible for other arches.
.c files are moved to drivers/dma/bestcomm, while .h files are moved to
include/linux/fsl/bestcomm. Makefiles, Kconfigs and #include directives
are updated for the new file locations.
Tested by recompiling for MPC5200 with all bestcomm users enabled.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
This allows to let sparse check that the NIC access is
always released.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix typo in the macro name and the wrong value.
Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Synchronizing the IRQ is pointless when we will
then enable the RF-Kill interrupt again, but is
needed before we free it and the data needed to
handle IRQs; move it to the free function.
Simiarly, cancelling the replenish work struct
can move to the function that frees the RX data
structures.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no need to request the IRQ every time the
device is started, we can request it just once.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwl_trans_grab_nic_access returns a boolean. So ret should
explicitely set to an error code and not rely on the value
returned by iwl_trans_grab_nic_access.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's a bug in the currently released firmware version,
the sequence control in the Tx response isn't updated in
all cases. Take it from the packet as a workaround.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Different transports implement the access to the SRAM in
different ways. Virtualize it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since different transports have different ways to wake the
up the NIC, we need to virtualize it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
By accident, commit eb6476441b
("iwlwifi: protect use_ict with irq_lock") changed the return
value of the iwl_pcie_isr() function in case it handles an
interrupt -- it now returns IRQ_NONE instead of IRQ_HANDLED.
Put back the correct return value.
Cc: stable@vger.kernel.org
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Use __packed instead of __attribute__((packed)).
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In some cases, the fw should run even if the NIC is in
RFKILL. Make the API more flexible to allow that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
No need to verify that the fw has been written correctly.
In case it hasn't, we won't get ALIVE notification.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If we take a pointer to the tid_data, then use it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Support the Creative BT-D1 Bluetooth USB audio device. Before this
patch, Linux had trouble finding the correct USB descriptors and bailed
out with these messages:
no or invalid class specific endpoint descriptor
Now it still prints these messages on hotplug:
snd-usb-audio: probe of ...:1.0 failed with error -5
snd-usb-audio: probe of ...:1.2 failed with error -5
snd-usb-audio: probe of ...:1.3 failed with error -5
But the device works correctly, including the HID support.
The patch is diff'ed against 3.8-rc1 but should apply to older kernels
as well.
Signed-off-by: Alexander Schremmer <alex@alexanderweb.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The vmaster hook sends 1 for enabled/unmuted and 0 for disabled/muted,
but "Mute-LED Mode" being "On" refers to the LED being on, not the
volume being on.
Therefore "On" and "Off" should be switched.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
regulator_register() does not return 0 on success, fix the comment.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Current FSI driver is using platform info pointer,
but it is not good design for DT support.
This patch made it not to use platform info pointer.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Since commit 2aacdff entitled "cpufreq: Move common part from governors
to separate file", whenever the drivers that depend on this new file
(cpufreq_ondemand or cpufreq_conservative) are built as modules, a new
module named cpufreq_governor is created because the Makefile includes
cpufreq_governor.o twice. As drivers/cpufreq/cpufreq_governor.c contains no
MODULE directives, the resulting module has no license specified, which
results in logging of a "module license 'unspecified' taints kernel". In
addition, a number of globals are exported GPL only, and are therefore
not available. This fix establishes a new boolean configuration variable
that forces cpufreq_governor.o to be linked into the kernel whenever
either cpufreq_ondemand or cpufreq_conservative is selected.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This is only solution I can think of. User decides if he wants this
driver on his machine. I don't have enough knowledge and time to find
the reason why same code works on some machines and doesn't on others
which use the same, or very similar, chipset and processor.
Signed-off-by: Rafał Bilski <rafalbilski@interia.pl>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch forces complete struct cpufreq_stats allocation for all cpus before
registering CPUFREQ_TRANSITION_NOTIFIER notifier, otherwise in some conditions
cpufreq_stat_notifier_trans() can be called in the middle of stats allocation,
in this case cpufreq_stats_table already exists, but stat->freq_table is NULL.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit bf4d1b5 (cpuidle: support multiple drivers) introduced
locking in cpuidle_get_cpu_driver(), which is used in the
idle_call() function.
This leads to a contention problem with a large number of CPUs,
because they all try to run the idle routine at the same time.
The lock can be safely removed because of how is used the cpuidle
API. Namely, cpuidle_register_driver() is called first, but the
cpuidle idle function is not entered before cpuidle_register_device()
is called, because the cpuidle device is not enabled then. Moreover,
cpuidle_unregister_driver(), which would reset the driver value to
NULL, is not called before cpuidle_unregister_device().
All of the cpuidle drivers use the API in the same way.
In general, a cleanup around the lock is necessary and a proper
refcounting mechanism should be used to ensure the consistency in the
API (for example, cpuidle_unregister_driver() should fail if the
driver's refcount is not 0). However, these modifications will require
some code reorganization and rewrite which will be too intrusive for
a fix.
For this reason, fix the contention problem introduced by commit
bf4d1b5 by simply removing the locking from cpuidle_get_cpu_driver(),
which restores the original behavior of that routine.
[rjw: Changelog.]
Reported-and-tested-by: Russ Anderson <rja@sgi.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When debug kernel, the the below information is found:
intel_idle: unaware of model 0x1a MWAIT 4 please contact lenb@kernel.orgACPI: Device input0 -> No ACPI support
so this patch separates it.
Signed-off-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ready_waiting_counts atomic variable is compared against the wrong
online cpu count. The latter is computed incorrectly using logical-OR
instead of bit-OR. This patch fixes that.
Signed-off-by: Sivaram Nair <sivaramn@nvidia.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Colin Cross <ccross@android.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since cpuidle_state.power_usage is a signed value, use INT_MAX (instead
of -1) to init the local copies so that functions that tries to find
cpuidle states with minimum power usage works correctly even if they use
non-negative values.
Signed-off-by: Sivaram Nair <sivaramn@nvidia.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The patch copies the flags masked by IORESOURCE_BITS from a resource's
template. This is necessary because the resource settings require proper
IORESOURCE_BITS which are not known during the definition of these resources
using the "/sys/bus/pnp/*/*/resources" interface. (In fact, they should not
be set by the user as the resource templates define the proper settings.)
If the patch is not applied, the resource flags are not initialized properly
and obscure messages in the kernel log have been seen ("invalid flags").
Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch factors out the setting of PNP resources into one function which is
then reused for all PNP resource types. This makes the code more concise and
avoids duplication. The parameters "type" and "flags" are not used at the
moment but may be used by follow-up patches. Placeholders for these patches
can be found in the comment lines that contain the "TBD" marker.
As the code does not make any changes to the ABI, no regressions are expected.
NB: While at it, support for bus type resources is added.
Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After commit 71fbad6 (PCI/ACPI: Notify PCI devices when their power
resource is turned on) made acpi_pci_bind() call
acpi_power_resource_register_device(), the debug message at the end
of the latter appears in the kernel log for every PCI device that
doesn't happen to have power resources assigned (which is the vast
majority of them). However, this message is totally useless, because
it doesn't even say which device it is about. Moreover, it is
misleading, because it only means that the given device has no power
resources, which isn't exceptional at all.
Remove that useless message altogether and simplify
acpi_power_resource_register_device() slightly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently these DBG statements are emitted at KERN_DEFAULT.
Change the macro to emit at KERN_DEBUG.
This can help avoid unexpected message interleaving.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since the return value of acpi_bus_get_device() is not of type
acpi_status, ACPI_SUCCESS() should not be used for checking its
return value. Fix that.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
When memory hotadd, acpi_memory_enable_device has already been done
at drv->ops.add (acpi_memory_device_add), no need to do it again
at notify callback.
At acpi_memory_enable_device, acpi_memory_get_device_resources
is also a redundant action, since it has been done at drv->ops.add.
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If the persistent store is empty initially, the function 'erst_dbg_read'
returns a nonzero value. The better way is to return a zero indicating the
read operation reaches EOF.
Tested on two different servers.
Signed-off-by: Adrian Huang <adrian.huang@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This member is never initialized and never referenced, so remove it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Drop the .bind() and .unbind() that have no more users from
struct acpi_device_ops and remove all of the code referring to
them from drivers/acpi/scan.c.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Move the code related to _PRT setup and removal and to power
resources from acpi_pci_bind() and acpi_pci_unbind() to the .setup()
and .cleanup() callbacks in acpi_pci_bus and remove acpi_pci_bind()
and acpi_pci_unbind() that have no purpose any more. Accordingly,
remove the code related to device .bind() and .unbind() operations
from the ACPI PCI root bridge driver.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Currently, the ACPI wakeup capability of PCI devices is set up
in two different places, partially in acpi_pci_bind() where
runtime wakeup is initialized and partially in
platform_pci_wakeup_init(), where system wakeup is initialized.
The cleanup is only done in acpi_pci_unbind() and it only covers
runtime wakeup.
Use the new .setup() and .cleanup() callbacks in struct acpi_bus_type
to consolidate that code and do the setup and the cleanup each in one
place.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Add two new callbacks,.setup() and .cleanup(), struct acpi_bus_type
and modify acpi_platform_notify() to call .setup() after executing
acpi_bind_one() successfully and acpi_platform_notify_remove() to
call .cleanup() before running acpi_unbind_one(). This will allow
the users of struct acpi_bus_type, PCI in particular, to specify
operations to be executed right after the given device has been
associated with a companion struct acpi_device and right before
it's going to be detached from that companion, respectively.
The main motivation is to be able to get rid of acpi_pci_bind()
and acpi_pci_unbind(), which are horrible horrible stuff. [In short,
there are three problems with them: The way they populate the .bind()
and .unbind() callbacks of ACPI devices is rather less than
straightforward, they require special hotplug-specific paths to be
present in the ACPI namespace scanning code and by the time
acpi_pci_unbind() is called the PCI device object in question may
not exist any more.]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
