| Age | Commit message (Collapse) | Author |
|---|
|
DSP fw can have additional firmwares as libs. These libs can be
loaded using message IPC_GLB_LOAD_LIBRARY.
Signed-off-by: Ramesh Babu <ramesh.babu@intel.com>
Signed-off-by: Kranthi G <gudishax.kranthikumar@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The firmware manifest contains UUIDs which needs to be passed only once.
So use the newly introduced is_first_boot flag to distinguish and parse
these only once on bxt platform as well.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The firmware manifest contains UUIDs which needs to be passed only once.
So use the newly introduced is_first_boot flag to distinguish and parse
these only once.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For additional library parsing, we need to pass firmware to be
loaded and not use the pointer in context. Also, Library module
IDs are combination of library index and module ID in manifest.
So add the additional arguments of firmware and library offset to
snd_skl_parse_uuids().
Signed-off-by: Senthilnathan Veppur <senthilnathanx.veppur@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Topology manifest gives information about the libraries to be
loaded. Implement the topology manifest load callback to get
this.
Signed-off-by: Kranthi G <gudishax.kranthikumar@intel.com>
Signed-off-by: Senthilnathan Veppur <senthilnathanx.veppur@intel.com>
Signed-off-by: Ramesh Babu <ramesh.babu@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The DSP instance creation also loads the firmware on DSPs. For library load
the firmware names come from topology so can't be loaded at object creation.
So split the firmware load and object creation. FW load is now called after
topology init in platform probe.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
To query the ops used for a platform, we use skl_get_dsp_ops() which return
index and then we load the ops.
Rather than this return the ops, this way it cna be used later to query the
ops in rest of the driver.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Since we are moving DSP init to later, at the topology load the
module info is not available.
So set the module id to -1 at init and query at first module
initialization.
Signed-off-by: Senthilnathan Veppur <senthilnathanx.veppur@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
hdmi-codec driver is common HDMI sound driver,
but it doesn't care about multi sound ports.
For example, hdmi-codec driver is supporting 1 I2S and 1 SPDIF ports,
so, we can't use this driver if HDMI has 2 or more I2S ports.
And we would like to use multi detection.
For example, DesignWare HDMI driver is providing dw_hdmi_bind() to
DRM/KMS driver, and it will setups HDMI video/sound.
Note is that it will be called under for_each loop of ports.
int dw_hdmi_bind(xxx)
{
/* register hdmi-codec driver here */
}
static int xxx_probe(struct platform_device *pdev)
{
for_each_xxx(xx) {
...
dw_hdmi_bind(xxx);
...
}
}
This case, dw_hdmi_bind() would like to use hdmi-codec,
and it will be called multiple times for each ports.
Here, ASoC's CPU/Codec/Card bind will checks each "of_node" on DT,
and hdmi-codec driver is assuming its parent device for it.
But it doesn't care about case.
Thus, ASoC never detect correct sound card in this case.
To solve this issue, this patch checks each parent device,
and names "hdmi-hifi.x" in order to each ports.
And uses struct snd_soc_component_driver :: of_xlate_dai_name
for snd_soc_get_dai_name().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The dw_configure_dai_by_dt() function and further dev->{play,capture}
_dma_data.dt data structures seem to be used in this driver only in case
of a system using devicetree, thus chan_name assignments have no effect
since they will be ignored in dmaengine_pcm_request_chan_of() call and
will be substituted with values taken form dmaengine_pcm_dma_channel_names[]
table ("tx", "rx").
Also there is no any "TX", "RX" dma-names entries in arch/arm/boot/dts,
only lower case "tx", "rx" seem to be used.
Lastly, this driver doesn't set SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME
flag when registering a dmaengine PCM to indicate the chan_name should be
used.
My intention is to eventually remove the struct snd_dmaengine_dai_dma_data
chan_name field as there is also a chan_names[] field in struct
snd_dmaengine_pcm_config which can be used for same purpose.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently, if the driver has control of MCLK then it remains
enabled as long as the codec is in STANDBY or above. The MCLK is
only really required in STANDBY when a 3-pole jack is inserted
and the HP detect procedure is required to run.
This patch updates the code to enable/disable the MCLK when moving
between the STANDBY and PREPARE bias level, and when a 3-pole jack
is inserted and HP detection is required, thus saving power at all
other times.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
To aid PLL in locking on to a 32KHz MCLK, some register mods
are made during PLL configuration, and when enabling the DAI,
to achieve the full range of sample rates.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently the handling of the PLL in the driver is a little clunky,
and not ideal for all modes. This patch updates the code to make it
cleaner and more sensible for the various PLL states.
Key items of note are:
- MCLK squaring is now handled directly as part of the sysclk()
function, removing the need for a private flag to set this feature.
- All PLL modes are defined as an enum, and are handled as a case
statement in pll() function to clean up configuration. This also
removes any need for a private flag for SRM.
- For 32KHz mode, checks are made on codec master mode and correct
MCLK rates, to avoid incorrect usage of PLL for this operation.
- For 32KHz mode, SRM flag now correctly enabled and fout set to
sensible value to achieve appropriate PLL dividers.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently MCLK remains enabled during bias STANDBY state, and this
is not necessary. This patch updates the code to handle enabling
and disabling of MCLK, if provided, when moving between STANDBY
and PREPARE states, therefore saving power when no active streams
present.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When the clock is specified, there could be other errors besides
the EPROBE_DEFER so don't ignore them.
Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
Acked-by: Paul Handrigan <Paul.Handrigan@cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Brian Austin <brian.austin@cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch adds a set of compositions for Telit LE920A4.
Compositions in short are:
0x1207: tty + tty
0x1208: tty + adb + tty + tty
0x1211: tty + adb + ecm
0x1212: tty + adb
0x1213: ecm + tty
0x1214: tty + adb + ecm + tty
telit_le922_blacklist_usbcfg3 is reused for compositions 0x1211
and 0x1214 due to the same interfaces positions.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
asoc_simple_card_sub_parse_of() is no longer needed. Let's cleanup
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
simple-card needs to get its dai name and endpoint node.
This patch makes it simple style standard
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Current simple-card can get clock via DT clocks or
"system-clock-frequency" property.
This patch makes it simple style standard
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-simple
|
|
BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0
UART/FIFO IC.
To support BCM920706V2_EVAL dev board for WICED development on Linux.
Add the VID(0a5c) and PID(6422) to ftdi_sio driver to allow loading
ftdi_sio for this board.
Signed-off-by: Sheng-Hui J. Chu <s.jeffrey.chu@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Ivium Technologies uses the FTDI VID with custom PIDs for their line of
electrochemical interfaces and the PalmSens they developed for PalmSens
BV.
Signed-off-by: Robert Delien <robert@delien.nl>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Do not drop packet when CSeq is 0 as 0 is also a valid value for CSeq.
simple_strtoul() will return 0 either when all digits are 0
or if there are no digits at all. Therefore when simple_strtoul()
returns 0 we check if first character is digit 0 or not.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
The device has four interfaces; the three serial ports ought to be
handled by this driver:
00 Diagnostic interface serial port
01 NMEA device serial port
02 Mass storage (sd card)
03 Modem serial port
The other product ids listed in the Windows driver are present already.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
If we find a matching element that is inactive with no descendants, we
jump to the found label, then crash because of nul-dereference on the
left branch.
Fix this by checking that the element is active and not an interval end
and skipping the logic that only applies to the tree iteration.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Tested-by: Anders K. Pedersen <akp@akp.dk>
|
|
A recent commit (inadvertently?) changed how failed probe of a gpmc
child node was handled. Instead of proceeding with setting up any other
children as before, a single error now aborts the whole process.
This change broke networking on some Overo boards due to probe failing
for an unrelated nand node. This second issue should obviously be
fixed, but let's restore the old behaviour of allowing child-node
probe to fail to avoid further similar breakage on other systems.
Fixes: d2d00862dfbb ("memory: omap-gpmc: Support general purpose input
for WAITPINs")
Cc: stable@vger.kernel.org # v4.7+
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
|
|
The USB-DMAC's interruption happens even if the CHCR.DE is not set to 1
because CHCR.NULLE is set to 1. So, this driver should call
usb_dmac_isr_transfer_end() if the DE bit is set to 1 only. Otherwise,
the desc is possible to be NULL in the usb_dmac_isr_transfer_end().
Fixes: 0c1c8ff32fa2 ("dmaengine: usb-dmac: Add Renesas USB DMA Controller (USB-DMAC) driver)
Cc: <stable@vger.kernel.org> # v4.1+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
Fixes: 97f69747d8b1 ('tools/gpio: add the gpio-event-mon tool')
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
MFT_REG32_01 is a typo, rename this to NFT_REG32_01.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
Commit 96d1327ac2e3 ("netfilter: h323: Use mod_timer instead of
set_expect_timeout") just simplify the source codes
if (!del_timer(&exp->timeout))
return 0;
add_timer(&exp->timeout);
to mod_timer(&exp->timeout, jiffies + info->timeout * HZ);
This is not correct, and introduce a race codition:
CPU0 CPU1
- timer expire
process_rcf expectation_timed_out
lock(exp_lock) -
find_exp waiting exp_lock...
re-activate timer!! waiting exp_lock...
unlock(exp_lock) lock(exp_lock)
- unlink expect
- free(expect)
- unlock(exp_lock)
So when the timer expires again, we will access the memory that
was already freed.
Replace mod_timer with mod_timer_pending here to fix this problem.
Fixes: 96d1327ac2e3 ("netfilter: h323: Use mod_timer instead of set_expect_timeout")
Cc: Gao Feng <fgao@ikuai8.com>
Signed-off-by: Liping Zhang <liping.zhang@spreadtrum.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
This reverts commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724.
Ben Hutchings pointed out that the commit isn't safe since it assumes
that the structure used by the driver is iw_point, when in fact there's
no way to know about that.
Fortunately, the only driver in the tree that ever runs this code path
is the wilc1000 staging driver, so it doesn't really matter.
Clearly I should have investigated this better before applying, sorry.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable@vger.kernel.org [though I guess it doesn't matter much]
Fixes: 3d5fdff46c4b ("wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
into drm-next
A few fixes for amdgpu and ttm for 4.8
- fix a ttm regression caused by the new pipelining code
- fixes for mullins on amdgpu
- updated golden settings for amdgpu
* 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux:
drm/ttm: Wait for a BO to become idle before unbinding it from GTT
drm/amdgpu: update golden setting of polaris10
drm/amdgpu: update golden setting of stoney
drm/amdgpu: update golden setting of polaris11
drm/amdgpu: update golden setting of carrizo
drm/amdgpu: update golden setting of iceland
drm/amd/amdgpu: change pptable output format from ASCII to binary
drm/amdgpu/ci: add mullins to default case for smc ucode
drm/amdgpu/gmc7: add missing mullins case
|
|
Commit 817820b0226a ("powerpc/iommu: Support "hybrid" iommu/direct DMA
ops for coherent_mask < dma_mask) adds a check of coherent_dma_mask for
dma allocations.
Unfortunately current PASemi code does not set this value for the DMA
engine, which ends up with the default value of 0xffffffff, the result
is on a PASemi system with >2Gb ram and iommu enabled the the onboard
ethernet stops working due to an inability to allocate memory. Add an
initialisation to pci_dma_dev_setup_pasemi().
Signed-off-by: Darren Stevens <darren@stevens-zone.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
3 intel fixes.
* tag 'drm-intel-next-fixes-2016-08-05' of git://anongit.freedesktop.org/drm-intel:
drm/i915/fbdev: Check for the framebuffer before use
drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB
drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
|
|
drm_connector_register_all requires a few too many locks because our
connector_list locking is busted. Add another FIXME+hack to work
around this. This should address the below lockdep splat:
======================================================
[ INFO: possible circular locking dependency detected ]
4.7.0-rc5+ #524 Tainted: G O
-------------------------------------------------------
kworker/u8:0/6 is trying to acquire lock:
(&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
but task is already holding lock:
((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 ((fb_notifier_list).rwsem){++++.+}:
[<ffffffff810df611>] lock_acquire+0xb1/0x200
[<ffffffff819a55b4>] down_write+0x44/0x80
[<ffffffff810abf91>] blocking_notifier_chain_register+0x21/0xb0
[<ffffffff814c7448>] fb_register_client+0x18/0x20
[<ffffffff814c6c86>] backlight_device_register+0x136/0x260
[<ffffffffa0127eb2>] intel_backlight_device_register+0xa2/0x160 [i915]
[<ffffffffa00f46be>] intel_connector_register+0xe/0x10 [i915]
[<ffffffffa0112bfb>] intel_dp_connector_register+0x1b/0x80 [i915]
[<ffffffff8159dfea>] drm_connector_register+0x4a/0x80
[<ffffffff8159fe44>] drm_connector_register_all+0x64/0xf0
[<ffffffff815a2a64>] drm_modeset_register_all+0x174/0x1c0
[<ffffffff81599b72>] drm_dev_register+0xc2/0xd0
[<ffffffffa00621d7>] i915_driver_load+0x1547/0x2200 [i915]
[<ffffffffa006d80f>] i915_pci_probe+0x4f/0x70 [i915]
[<ffffffff814a2135>] local_pci_probe+0x45/0xa0
[<ffffffff814a349b>] pci_device_probe+0xdb/0x130
[<ffffffff815c07e3>] driver_probe_device+0x223/0x440
[<ffffffff815c0ad5>] __driver_attach+0xd5/0x100
[<ffffffff815be386>] bus_for_each_dev+0x66/0xa0
[<ffffffff815c002e>] driver_attach+0x1e/0x20
[<ffffffff815bf9be>] bus_add_driver+0x1ee/0x280
[<ffffffff815c1810>] driver_register+0x60/0xe0
[<ffffffff814a1a10>] __pci_register_driver+0x60/0x70
[<ffffffffa01a905b>] i915_init+0x5b/0x62 [i915]
[<ffffffff8100042d>] do_one_initcall+0x3d/0x150
[<ffffffff811a935b>] do_init_module+0x5f/0x1d9
[<ffffffff81124416>] load_module+0x20e6/0x27e0
[<ffffffff81124d63>] SYSC_finit_module+0xc3/0xf0
[<ffffffff81124dae>] SyS_finit_module+0xe/0x10
[<ffffffff819a83a9>] entry_SYSCALL_64_fastpath+0x1c/0xac
-> #0 (&dev->mode_config.mutex){+.+.+.}:
[<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260
[<ffffffff810df611>] lock_acquire+0xb1/0x200
[<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0
[<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
[<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
[<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50
[<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[<ffffffff814c13c6>] fbcon_init+0x586/0x610
[<ffffffff8154d16a>] visual_init+0xca/0x130
[<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0
[<ffffffff8154eaf6>] do_take_over_console+0x116/0x180
[<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0
[<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750
[<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0
[<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70
[<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff814c86b1>] register_framebuffer+0x251/0x330
[<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0
[<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915]
[<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150
[<ffffffff810a3947>] process_one_work+0x1e7/0x750
[<ffffffff810a3efb>] worker_thread+0x4b/0x4f0
[<ffffffff810aad4f>] kthread+0xef/0x110
[<ffffffff819a85ef>] ret_from_fork+0x1f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((fb_notifier_list).rwsem);
lock(&dev->mode_config.mutex);
lock((fb_notifier_list).rwsem);
lock(&dev->mode_config.mutex);
*** DEADLOCK ***
6 locks held by kworker/u8:0/6:
#0: ("events_unbound"){.+.+.+}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750
#1: ((&entry->work)){+.+.+.}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750
#2: (registration_lock){+.+.+.}, at: [<ffffffff814c8487>] register_framebuffer+0x27/0x330
#3: (console_lock){+.+.+.}, at: [<ffffffff814c86ce>] register_framebuffer+0x26e/0x330
#4: (&fb_info->lock){+.+.+.}, at: [<ffffffff814c78dd>] lock_fb_info+0x1d/0x40
#5: ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70
stack backtrace:
CPU: 2 PID: 6 Comm: kworker/u8:0 Tainted: G O 4.7.0-rc5+ #524
Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLKRVPA.X64.0138.B33.1606250842 06/25/2016
Workqueue: events_unbound async_run_entry_fn
0000000000000000 ffff8800758577f0 ffffffff814507a5 ffffffff828b9900
ffffffff828b9900 ffff880075857830 ffffffff810dc6fa ffff880075857880
ffff88007584d688 0000000000000005 0000000000000006 ffff88007584d6b0
Call Trace:
[<ffffffff814507a5>] dump_stack+0x67/0x92
[<ffffffff810dc6fa>] print_circular_bug+0x1aa/0x200
[<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260
[<ffffffff810df611>] lock_acquire+0xb1/0x200
[<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
[<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
[<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0
[<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
[<ffffffff810fa85f>] ? rcu_read_lock_sched_held+0x7f/0x90
[<ffffffff81208218>] ? kmem_cache_alloc_trace+0x248/0x2b0
[<ffffffff815afdc5>] ? drm_modeset_lock_all+0x25/0x120
[<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
[<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
[<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50
[<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[<ffffffff814c13c6>] fbcon_init+0x586/0x610
[<ffffffff8154d16a>] visual_init+0xca/0x130
[<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0
[<ffffffff8154eaf6>] do_take_over_console+0x116/0x180
[<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0
[<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750
[<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0
[<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70
[<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff814c86b1>] register_framebuffer+0x251/0x330
[<ffffffff815b7e8d>] ? vga_switcheroo_client_fb_set+0x5d/0x70
[<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0
[<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915]
[<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150
[<ffffffff810a3947>] process_one_work+0x1e7/0x750
[<ffffffff810a38c9>] ? process_one_work+0x169/0x750
[<ffffffff810a3efb>] worker_thread+0x4b/0x4f0
[<ffffffff810a3eb0>] ? process_one_work+0x750/0x750
[<ffffffff810aad4f>] kthread+0xef/0x110
[<ffffffff819a85ef>] ret_from_fork+0x1f/0x40
[<ffffffff810aac60>] ? kthread_stop+0x2e0/0x2e0
v2: Rebase onto the right branch (hand-editing patches ftw) and add more
reporters.
Reported-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Jiri Kosina <jikos@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The conversion of the rcar-du driver from the I2C slave encoder to the
DRM bridge API left the HDMI encoder's bridge pointer NULL, preventing
the bridge from being handled automatically by the DRM core. Fix it.
Fixes: 1d926114d8f4 ("drm: rcar-du: Remove i2c slave encoder interface for hdmi encoder")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
On Intel Xeon Phi Knights Landing processor family the channels of the
memory controller have untypical arrangement - MC0 is mapped to CH3,4,5
and MC1 is mapped to CH0,1,2. This causes the EDAC driver to report the
channel name incorrectly.
We missed this change earlier, so the code already contains similar
comment, but the translation function is incorrect.
Without this patch:
errors in DIMM_A and DIMM_D were reported in DIMM_D
errors in DIMM_B and DIMM_E were reported in DIMM_E
errors in DIMM_C and DIMM_F were reported in DIMM_F
Correct this.
Hubert Chrzaniuk:
- rebased to 4.8
- comments and code cleanup
Fixes: d0cdf9003140 ("sb_edac: Add Knights Landing (Xeon Phi gen 2) support")
Reviewed-by: Tony Luck <tony.luck@intel.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Hubert Chrzaniuk <hubert.chrzaniuk@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: lukasz.anaczkowski@intel.com
Cc: lukasz.odzioba@intel.com
Cc: mchehab@kernel.org
Cc: <stable@vger.kernel.org> # v4.5..
Link: http://lkml.kernel.org/r/1469231089-22837-1-git-send-email-lukasz.odzioba@intel.com
Signed-off-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
[ Boris: Simplify a bit by removing char mc. ]
Signed-off-by: Borislav Petkov <bp@suse.de>
|
|
|
|
The driver allocates the mutex but not initialize it.
Use mutex_init() on it to initialize it correctly.
This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
thermal_add_hwmon_sysfs()/thermal_remove_hwmon_sysfs() need
EXPORT_SYMBOL_GPL(). Otherwise we will have ERROR
>> ERROR: "thermal_remove_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] undefined!
>> ERROR: "thermal_add_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] undefined!
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
When multiple thermal zones are bound to the same cooling device, multiple
kernel threads may want to update the cooling device state by calling
thermal_cdev_update(). Having cdev not protected by a mutex can lead to a race
condition. Consider the following situation with two kernel threads k1 and k2:
Thread k1 Thread k2
||
|| call thermal_cdev_update()
|| ...
|| set_cur_state(cdev, target);
call power_actor_set_power() ||
... ||
instance->target = state; ||
cdev->updated = false; ||
|| cdev->updated = true;
|| // completes execution
call thermal_cdev_update() ||
// cdev->updated == true ||
return; ||
\/
time
k2 has already looped through the thermal instances looking for the deepest
cooling device state and is preempted right before setting cdev->updated to
true. Now, k1 runs, modifies the thermal instance state and sets cdev->updated
to false. Then, k1 is preempted and k2 continues the execution by setting
cdev->updated to true, therefore preventing k1 from performing the update.
Notice that this is not an issue if k2 looks at the instance->target modified by
k1 "after" it is assigned by k1. In fact, in this case the update will happen
anyway and k1 can safely return immediately from thermal_cdev_update().
This may lead to a situation where a thermal governor never updates the cooling
device. For example, this is the case for the step_wise governor: when calling
the function thermal_zone_trip_update(), the governor may always get a new state
equal to the old one (which, however, wasn't notified to the cooling device) and
will therefore skip the update.
CC: Zhang Rui <rui.zhang@intel.com>
CC: Eduardo Valentin <edubezval@gmail.com>
CC: Peter Feuerer <peter@piie.net>
Reported-by: Toby Huang <toby.huang@arm.com>
Signed-off-by: Michele Di Giorgio <michele.digiorgio@arm.com>
Reviewed-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
I have got a zero division error when disabling the forced
idle injection from the intel powerclamp. I did
echo 0 >/sys/class/thermal/cooling_device48/cur_state
and got
[ 986.072632] divide error: 0000 [#1] PREEMPT SMP
[ 986.078989] Modules linked in:
[ 986.083618] CPU: 17 PID: 24967 Comm: kidle_inject/17 Not tainted 4.7.0-1-default+ #3055
[ 986.093781] Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.R3.27.D685.1305151734 05/15/2013
[ 986.106227] task: ffff880430e1c080 task.stack: ffff880427ef0000
[ 986.114122] RIP: 0010:[<ffffffff81794859>] [<ffffffff81794859>] clamp_thread+0x1d9/0x600
[ 986.124609] RSP: 0018:ffff880427ef3e20 EFLAGS: 00010246
[ 986.131860] RAX: 0000000000000258 RBX: 0000000000000006 RCX: 0000000000000001
[ 986.141179] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000018
[ 986.150478] RBP: ffff880427ef3ec8 R08: ffff880427ef0000 R09: 0000000000000002
[ 986.159779] R10: 0000000000003df2 R11: 0000000000000018 R12: 0000000000000002
[ 986.169089] R13: 0000000000000000 R14: ffff880427ef0000 R15: ffff880427ef0000
[ 986.178388] FS: 0000000000000000(0000) GS:ffff880435940000(0000) knlGS:0000000000000000
[ 986.188785] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 986.196559] CR2: 00007f1d0caf0000 CR3: 0000000002006000 CR4: 00000000001406e0
[ 986.205909] Stack:
[ 986.209524] ffff8802be897b00 ffff880430e1c080 0000000000000011 0000006a35959780
[ 986.219236] 0000000000000011 ffff880427ef0008 0000000000000000 ffff8804359503d0
[ 986.228966] 0000000100029d93 ffffffff81794140 0000000000000000 ffffffff05000011
[ 986.238686] Call Trace:
[ 986.242825] [<ffffffff81794140>] ? pkg_state_counter+0x80/0x80
[ 986.250866] [<ffffffff81794680>] ? powerclamp_set_cur_state+0x180/0x180
[ 986.259797] [<ffffffff8111d1a9>] kthread+0xc9/0xe0
[ 986.266682] [<ffffffff8193d69f>] ret_from_fork+0x1f/0x40
[ 986.274142] [<ffffffff8111d0e0>] ? kthread_create_on_node+0x180/0x180
[ 986.282869] Code: d1 ea 48 89 d6 80 3d 6a d0 d4 00 00 ba 64 00 00 00 89 d8 41 0f 45 f5 0f af c2 42 8d 14 2e be 31 00 00 00 83 fa 31 0f 42 f2 31 d2 <f7> f6 48 8b 15 9e 07 87 00 48 8b 3d 97 07 87 00 48 63 f0 83 e8
[ 986.307806] RIP [<ffffffff81794859>] clamp_thread+0x1d9/0x600
[ 986.315871] RSP <ffff880427ef3e20>
RIP points to the following lines:
compensation = get_compensation(target_ratio);
interval = duration_jiffies*100/(target_ratio+compensation);
A solution would be to switch the following two commands in
powerclamp_set_cur_state():
set_target_ratio = 0;
end_power_clamp();
But I think that the zero division might happen also when target_ratio
is non-zero because the compensation might be negative. Therefore
we also check the sum of target_ratio and compensation explicitly.
Also the compensated_ratio variable is always set. Therefore there
is no need to initialize it.
Signed-off-by: Petr Mladek <pmladek@suse.com>
Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Added suspend/resume callback to disable/enable PCH thermal sensor
respectively. If the sensor is enabled by the BIOS, then the sensor status
will not be changed during suspend/resume.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
On no-MMU systems the application a5 register can be overwitten with the
address of the process data segment when processing application signals.
For flat format applications compiled with full absolute relocation this
effectively corrupts the a5 register on signal processing - and this very
quickly leads to process crash and often takes out the whole system with
a panic as well.
This has no effect on flat format applications compiled with the more
common PIC methods (such as -msep-data). These format applications reserve
a5 for the pointer to the data segment anyway - so it doesn't change it.
A long time ago the a5 register was used in the code packed into the user
stack to enable signal return processing. And so it had to be restored on
end of signal cleanup processing back to the original a5 user value. This
was historically done by saving away a5 in the sigcontext structure. At
some point (a long time back it seems) the a5 restore process was changed
and it was hard coded to put the user data segment address directly into a5.
Which is ok for the common PIC compiled application case, but breaks the
full relocation application code.
We no longer use this type of signal handling mechanism and so we don't
need to do anything special to save and restore a5 at all now. So remove the
code that hard codes a5 to the address of the user data segment.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
|
|
|
