| Age | Commit message (Collapse) | Author |
|---|
|
There are platforms where the DSI output can be connected to another
encoder bridge chip (DSI to HDMI, DSI to LVDS etc).
Add support for external bridge support to the dsi driver. We assume that
the external bridge chip would be of the type drm_bridge. The dsi driver's
internal drm_bridge (msm_dsi->bridge) is linked to the external bridge's
drm_bridge struct.
In the case we're connected to an external bridge, we don't need to create
and manage a connector within our driver, it's the bridge driver's
responsibility to create one.
v2:
- Move the external bridge attaching stuff to dsi manager to make things
cleaner.
- Force the bridge to connect to a video mode encoder for now (the dsi
mode flags may have not been populated by modeset_init)
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Create a helper msm_dsi_device_connected() which checks whether we have a
device connected to the dsi host or not. This check gets messy when we
have support external bridges too. Having an inline function makes it
more legible.
For now, the check only consists of msm_dsi->panel being non-NULL. Later,
this will check if we have an external bridge or not.
This helper isn't used in dsi_connector related code as that's specific
to only when a drm_panel is connected.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
We currently support only panels connected to dsi output. We're going to
also support external bridge chips now.
Change 'panel_node' to 'device_node' in the struct msm_dsi_host and
'panel_flags' to 'device_flags' in msm_dsi. This makes things sound a
bit more generic.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Platforms containing only DSI video mode devices don't need a TE gpio.
Make TE gpio optional.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
We currently get the output connected to LVDS by looking for a phandle
called 'qcom,lvds-panel' under the mdp DT node.
Use the more standard of_graph approach to create an lvds output port,
and retrieve the panel node from the port's endpoint data.
v3
- Fix return value checks of of_graph_* calls.
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
The dsi host looks for the connected panel node by parsing for a child
named 'panel'. This hierarchy isn't very flexible. The connected
panel is forced to be a child to the dsi host, and hence, a mipi dsi
device. This isn't suitable for dsi devices that don't use mipi dsi
as their control bus.
Follow the of_graph approach of creating ports and endpoints to
represent the connections between the dsi host and the panel connected
to it. In our case, the dsi host will only have one output port, linked
to the panel's input port.
Update DT binding documentation with device graph usage info.
v3:
- Fix return value checks of of_graph_* calls.
- Don't make port a mandatory DT property
- Fix defer check when no panel node specified
- Rename parse_dt func to align with other dsi_host funcs
Reviewed-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Decrement device node refcount if of_get_child_by_name is successfully
called.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
AHB clock should be enabled before accessing registers during
enable/disable_vblank(). Since these 2 callbacks are called in
atomic context while clk_prepare may cause thread sleep, a work
is scheduled to control vblanks.
v2: fixup spinlock initialization
Signed-off-by: Hai Li <hali@codeaurora.org>
[add comment about cancel_work_sync() before drm_irq_uninstall()]
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
msm8x74v1 has different MDP5 version (v1.0) from msm8x74v2 (v1.2).
Add a separate config data to support msm8x74v1.
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
This change is to add planes which use DMA pipes for MDP5.
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
[slight comment adjust to s/Construct public planes/Construct video
planes/ since DMA planes are public planes too, they just can't scale
or CSC]
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
MDP planes can be implemented using different type of HW pipes,
RGB/VIG/DMA pipes for MDP5 and RGB/VG/DMA pipes for MDP4. Each type
of pipe has different HW capabilities such as scaling, color space
conversion, decimation... Add a variable in plane data structure
to specify the difference of each plane which comes from mdp5_cfg data
and use it to differenciate the plane operation.
V1: Initial change
V2: Fix a typo in mdp4_kms.h
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Add packed YUV422 and planar YUV420 formats to MDP supported
formats.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Newer MDP5 uses 2 shared memory pool clients for certain YUV formats.
For example, if VIG0 is used to fetch data in YUYV format, it will use
VIG0_Y for Y component, and VIG0_Cr for UV packed.
Signed-off-by: Wentao Xu <wentaox@codeaurora.org>
[rebase]
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
|
|
This makes it easy to determine if a format is YUV. The old
method of using chroma sample type incorrectly marks YUV444 as
RGB format.
Signed-off-by: Wentao Xu <wentaox@codeaurora.org>
[rebase]
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Use this to simplify the driver. Furthermore this is one caller less
that stops us making the flags argument to gpiod_get*() mandatory.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Reset DSI PHY silently changes its PLL registers to reset status,
which will make cached status in clock driver invalid and result
in wrong output rate of link clocks. The current restore mechanism
in DSI PLL does not cover all the cases. This change is to recover
PLL status after PHY reset to match HW status with cached status
in clock driver.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
The dsi_destroy() function was called in two cases by the dsi_init() function
during error handling even if the passed variable contained a null pointer.
* This implementation detail could be improved by adjustments for jump
targets according to the Linux coding style convention.
* Drop an unnecessary initialisation for the variable "msm_dsi" then.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
[add couple missing ERR_PTR()'s]
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
The dsi_destroy() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
This change takes advantage of a HW feature that synchronize
flush operation on CTL1 to CTL0, to keep dual DSI pipes in
sync.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
In MDP5, CTL contains information of the whole pipeline whose
output goes down to a display interface. In various cases, one
interface may require 2 CRTCs, but only one CTL. Some interfaces
also require to use certain CTLs.
Instead of allocating CTL for each active CRTC, this change is to
associate a CTL with each interface.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
This change is to add properties alpha/zpos/blend_mode to mdp5 plane
for alpha blending operation to generate the blended output.
v1: Initial change
v2: Change "premultilied" property to enum (Rob's comment)
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
[Don't actually expose alpha/premultiplied props to userspace yet
pending a chance for discussion and some userspace to exercise it]
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
This was a hold-over from the pre-atomic days and legacy userspace that
only understood CRTCs. Fortunately we don't have any properties, so
this doesn't change anything. But before we start growing some plane
properties, we should fix this.
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
DSI PHY errors are falsely reported whenever a dsi error occurs. This is
because DSI_DLN0_PHY_ERR isn't only used as a status register, but also
used to mask PHY errors. Currently, we end up reading the mask bits too
and therefore always report errors.
Ignore the register mask bits and check for only the status/clear bits.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
The maximum output width of one pipeline depends on the LayerMixer's
capability. It may be different on each target. Also, MDP5 doesn't
have vertical limitation in one frame, as long as the pixel clock
can be supported.
This change obtains the maximum LM resolution from configuration
table and treat it as the whole pipe's limitation for MDP5. The size
limit on MDP4 is not changed.
Signed-off-by: Hai Li <hali@codeaurora.org>
|
|
For all of these devices, msm89xy was the lead chip, so standardize the
compatible names to align with convention used by rest of the qcom/msm
drivers.
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
This change adds the MDP and HDMI support for msm8x94.
Note that HDMI PHY registers are not being accessed anymore from
the driver.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
[rename compatible s/8x94/8994/ since preference is to not trust the
marketing folks who invent chip #'s but instead name things after the
lead chip.. we should rename some 80XY to 89XY to standardize on the
lead chip but leave that for another patch. Also, update dt bindings
doc]
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
->reset() currently only accesses HDMI core registers, and yet it
is located in hdmi_phy*. Since no PHY registers are being
accessed during ->reset(), it would be better to bring that
function in hdmi core module where HDMI core registers are
usually being accessed.
This will also help for msm8x94 for which no PHY registers
accesses are done (->phy_init == NULL) but the HDMI PHY reset
from HDMI core still needs to be done.
Note:
SW_RESET_PLL bit is not written in hdmi_phy_8x60_reset(); this
write should not affect anything if the corresponding field is
not writable.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
[fixed warning about unused 'phy' in hpd_enable() while merging]
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
DSI controller on msm8x94 is version 1.3, which requires different
power supplies and works with 20nm DSI PHY. This change is to add
the basic support for this version.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Some targets use pinctrl framework to configure some
pins. This change allows DSI driver to set default and
sleep pinctrl status.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
The current term of *dual panel* in DSI driver code causes confusion.
It is supposed to indicate the panel using two DSI links. Rename it
to *dual DSI*.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
The source PLL to be used by each DSI PHY should be decided by
DSI manager based on dual DSI information, while the register
programming to select PLL is different from one type of PHY to
another. This change adds the H/W difference to PHY configuration
and updates the interface between DSI manager and PHY.
With this change, PLL selection can be supported on different
targets.
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Add HDMI HDCP support including HDCP PartI/II/III authentication.
V1: Initial Change
V2: Address Bjorn&Rob's comments
Refactor the authentication process to use single work instead
of multiple work for different authentication stages.
V3: Update to align with qcom SCM api.
Signed-off-by: Jilai Wang <jilaiw@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This has two libfc fixes for bugs causing rare crashes, one iscsi fix
for a potential hang on shutdown, and a fix for an I/O blocksize issue
which caused a regression"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
sd: Fix maximum I/O size for BLOCK_PC requests
libfc: Fix fc_fcp_cleanup_each_cmd()
libfc: Fix fc_exch_recv_req() error path
libiscsi: Fix host busy blocking during connection teardown
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
single MST fixes from Maarten.
* tag 'topic/drm-fixes-2015-08-14' of git://anongit.freedesktop.org/drm-intel:
drm/dp/mst: Remove port after removing connector.
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
three display fixes for Intel.
* tag 'drm-intel-fixes-2015-08-14' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Commit planes on each crtc separately.
drm/i915: calculate primary visibility changes instead of calling from set_config
drm/i915: Only dither on 6bpc panels
|
|
policy->max is the maximum allowed frequency defined by user and
clipped_freq is the maximum that thermal constraints allow.
If clipped_freq is lower than policy->max, then we need to readjust
policy->max.
But, if clipped_freq is greater than policy->max, we don't need to do
anything. We used to call cpufreq_verify_within_limits() in this case,
but it doesn't change anything in this case.
Lets skip this unnecessary call and write a comment that explains this.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
That's what it is for, lets name it properly.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
That's what it is for, lets name it properly.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
We just need to take care of single event here and there is no need to
increase indentation level of most of the code (which causes lines
longer that 80 columns to break).
Kill the switch block.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
If a valid cpufreq_dev is found for policy->cpu, we should update the
policy and quit the for loop. There is no need to keep traversing the
list of cpufreq_dev's.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
Its always set before getting used, don't initialize it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
A recent change to the cpu_cooling code introduced a AB-BA deadlock
scenario between the cpufreq_policy_notifier_list rwsem and the
cooling_cpufreq_lock. This is caused by cooling_cpufreq_lock being held
before the registration/removal of the notifier block (an operation
which takes the rwsem), and the notifier code itself which takes the
locks in the reverse order:
======================================================
[ INFO: possible circular locking dependency detected ]
3.18.0+ #1453 Not tainted
-------------------------------------------------------
rc.local/770 is trying to acquire lock:
(cooling_cpufreq_lock){+.+.+.}, at: [<c04abfc4>] cpufreq_thermal_notifier+0x34/0xfc
but task is already holding lock:
((cpufreq_policy_notifier_list).rwsem){++++.+}, at: [<c0042f04>] __blocking_notifier_call_chain+0x34/0x68
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 ((cpufreq_policy_notifier_list).rwsem){++++.+}:
[<c06bc3b0>] down_write+0x44/0x9c
[<c0043444>] blocking_notifier_chain_register+0x28/0xd8
[<c04ad610>] cpufreq_register_notifier+0x68/0x90
[<c04abe4c>] __cpufreq_cooling_register.part.1+0x120/0x180
[<c04abf44>] __cpufreq_cooling_register+0x98/0xa4
[<c04abf8c>] cpufreq_cooling_register+0x18/0x1c
[<bf0046f8>] imx_thermal_probe+0x1c0/0x470 [imx_thermal]
[<c037cef8>] platform_drv_probe+0x50/0xac
[<c037b710>] driver_probe_device+0x114/0x234
[<c037b8cc>] __driver_attach+0x9c/0xa0
[<c0379d68>] bus_for_each_dev+0x5c/0x90
[<c037b204>] driver_attach+0x24/0x28
[<c037ae7c>] bus_add_driver+0xe0/0x1d8
[<c037c0cc>] driver_register+0x80/0xfc
[<c037cd80>] __platform_driver_register+0x50/0x64
[<bf007018>] 0xbf007018
[<c0008a5c>] do_one_initcall+0x88/0x1d8
[<c0095da4>] load_module+0x1768/0x1ef8
[<c0096614>] SyS_init_module+0xe0/0xf4
[<c000ec00>] ret_fast_syscall+0x0/0x48
-> #0 (cooling_cpufreq_lock){+.+.+.}:
[<c00619f8>] lock_acquire+0xb0/0x124
[<c06ba3b4>] mutex_lock_nested+0x5c/0x3d8
[<c04abfc4>] cpufreq_thermal_notifier+0x34/0xfc
[<c0042bf4>] notifier_call_chain+0x4c/0x8c
[<c0042f20>] __blocking_notifier_call_chain+0x50/0x68
[<c0042f58>] blocking_notifier_call_chain+0x20/0x28
[<c04ae62c>] cpufreq_set_policy+0x7c/0x1d0
[<c04af3cc>] store_scaling_governor+0x74/0x9c
[<c04ad418>] store+0x90/0xc0
[<c0175384>] sysfs_kf_write+0x54/0x58
[<c01746b4>] kernfs_fop_write+0xdc/0x190
[<c010dcc0>] vfs_write+0xac/0x1b4
[<c010dfec>] SyS_write+0x44/0x90
[<c000ec00>] ret_fast_syscall+0x0/0x48
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((cpufreq_policy_notifier_list).rwsem);
lock(cooling_cpufreq_lock);
lock((cpufreq_policy_notifier_list).rwsem);
lock(cooling_cpufreq_lock);
*** DEADLOCK ***
7 locks held by rc.local/770:
#0: (sb_writers#6){.+.+.+}, at: [<c010dda0>] vfs_write+0x18c/0x1b4
#1: (&of->mutex){+.+.+.}, at: [<c0174678>] kernfs_fop_write+0xa0/0x190
#2: (s_active#52){.+.+.+}, at: [<c0174680>] kernfs_fop_write+0xa8/0x190
#3: (cpu_hotplug.lock){++++++}, at: [<c0026a60>] get_online_cpus+0x34/0x90
#4: (cpufreq_rwsem){.+.+.+}, at: [<c04ad3e0>] store+0x58/0xc0
#5: (&policy->rwsem){+.+.+.}, at: [<c04ad3f8>] store+0x70/0xc0
#6: ((cpufreq_policy_notifier_list).rwsem){++++.+}, at: [<c0042f04>] __blocking_notifier_call_chain+0x34/0x68
stack backtrace:
CPU: 0 PID: 770 Comm: rc.local Not tainted 3.18.0+ #1453
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<c00121c8>] (dump_backtrace) from [<c0012360>] (show_stack+0x18/0x1c)
r6:c0b85a80 r5:c0b75630 r4:00000000 r3:00000000
[<c0012348>] (show_stack) from [<c06b6c48>] (dump_stack+0x7c/0x98)
[<c06b6bcc>] (dump_stack) from [<c06b42a4>] (print_circular_bug+0x28c/0x2d8)
r4:c0b85a80 r3:d0071d40
[<c06b4018>] (print_circular_bug) from [<c00613b0>] (__lock_acquire+0x1acc/0x1bb0)
r10:c0b50660 r8:c09e6d80 r7:d0071d40 r6:c11d0f0c r5:00000007 r4:d0072240
[<c005f8e4>] (__lock_acquire) from [<c00619f8>] (lock_acquire+0xb0/0x124)
r10:00000000 r9:c04abfc4 r8:00000000 r7:00000000 r6:00000000 r5:c0a06f0c
r4:00000000
[<c0061948>] (lock_acquire) from [<c06ba3b4>] (mutex_lock_nested+0x5c/0x3d8)
r10:ec853800 r9:c0a06ed4 r8:d0071d40 r7:c0a06ed4 r6:c11d0f0c r5:00000000
r4:c04abfc4
[<c06ba358>] (mutex_lock_nested) from [<c04abfc4>] (cpufreq_thermal_notifier+0x34/0xfc)
r10:ec853800 r9:ec85380c r8:d00d7d3c r7:c0a06ed4 r6:d00d7d3c r5:00000000
r4:fffffffe
[<c04abf90>] (cpufreq_thermal_notifier) from [<c0042bf4>] (notifier_call_chain+0x4c/0x8c)
r7:00000000 r6:00000000 r5:00000000 r4:fffffffe
[<c0042ba8>] (notifier_call_chain) from [<c0042f20>] (__blocking_notifier_call_chain+0x50/0x68)
r8:c0a072a4 r7:00000000 r6:d00d7d3c r5:ffffffff r4:c0a06fc8 r3:ffffffff
[<c0042ed0>] (__blocking_notifier_call_chain) from [<c0042f58>] (blocking_notifier_call_chain+0x20/0x28)
r7:ec98b540 r6:c13ebc80 r5:ed76e600 r4:d00d7d3c
[<c0042f38>] (blocking_notifier_call_chain) from [<c04ae62c>] (cpufreq_set_policy+0x7c/0x1d0)
[<c04ae5b0>] (cpufreq_set_policy) from [<c04af3cc>] (store_scaling_governor+0x74/0x9c)
r7:ec98b540 r6:0000000c r5:ec98b540 r4:ed76e600
[<c04af358>] (store_scaling_governor) from [<c04ad418>] (store+0x90/0xc0)
r6:0000000c r5:ed76e6d4 r4:ed76e600
[<c04ad388>] (store) from [<c0175384>] (sysfs_kf_write+0x54/0x58)
r8:0000000c r7:d00d7f78 r6:ec98b540 r5:0000000c r4:ec853800 r3:0000000c
[<c0175330>] (sysfs_kf_write) from [<c01746b4>] (kernfs_fop_write+0xdc/0x190)
r6:ec98b540 r5:00000000 r4:00000000 r3:c0175330
[<c01745d8>] (kernfs_fop_write) from [<c010dcc0>] (vfs_write+0xac/0x1b4)
r10:0162aa70 r9:d00d6000 r8:0000000c r7:d00d7f78 r6:0162aa70 r5:0000000c
r4:eccde500
[<c010dc14>] (vfs_write) from [<c010dfec>] (SyS_write+0x44/0x90)
r10:0162aa70 r8:0000000c r7:eccde500 r6:eccde500 r5:00000000 r4:00000000
[<c010dfa8>] (SyS_write) from [<c000ec00>] (ret_fast_syscall+0x0/0x48)
r10:00000000 r8:c000edc4 r7:00000004 r6:000216cc r5:0000000c r4:0162aa70
Solve this by moving to finer grained locking - use one mutex to protect
the cpufreq_dev_list as a whole, and a separate lock to ensure correct
ordering of cpufreq notifier registration and removal.
cooling_list_lock is taken within cooling_cpufreq_lock on
(un)registration to preserve the behavior of the code, i.e. to
atomically add/remove to the list and (un)register the notifier.
Fixes: 2dcd851fe4b4 ("thermal: cpu_cooling: Update always cpufreq policy with
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
Pull KVM fixes from Paolo Bonzini:
"Just two very small & simple patches"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: Use adjustment in guest cycles when handling MSR_IA32_TSC_ADJUST
KVM: x86: zero IDT limit on entry to SMM
|
|
Merge fixes from Andrew Morton:
"11 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
Update maintainers for DRM STI driver
mm: cma: mark cma_bitmap_maxno() inline in header
zram: fix pool name truncation
memory-hotplug: fix wrong edge when hot add a new node
.mailmap: Andrey Ryabinin has moved
ipc/sem.c: update/correct memory barriers
mm/hwpoison: fix panic due to split huge zero page
ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()
ipc,sem: fix use after free on IPC_RMID after a task using same semaphore set exits
mm/hwpoison: fix fail isolate hugetlbfs page w/ refcount held
mm/hwpoison: fix page refcount of unknown non LRU page
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clock fix from Stephen Boyd:
"A one-liner for a regression found in the PXA clock driver"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: pxa: pxa3xx: fix CKEN register access
|
|
Add Vincent Abriou and myself as maintainers.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
cma_bitmap_maxno() was marked as static and not static inline, which can
cause warnings about this function not being used if this file is included
in a file that does not call that function, and violates the conventions
used elsewhere. The two options are to move the function implementation
back to mm/cma.c or make it inline here, and it's simple enough for the
latter to make sense.
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
zram_meta_alloc() constructs a pool name for zs_create_pool() call as
snprintf(pool_name, sizeof(pool_name), "zram%d", device_id);
However, it defines pool name buffer to be only 8 bytes long (minus
trailing zero), which means that we can have only 1000 pool names: zram0
-- zram999.
With CONFIG_ZSMALLOC_STAT enabled an attempt to create a device zram1000
can fail if device zram100 already exists, because snprintf() will
truncate new pool name to zram100 and pass it debugfs_create_dir(),
causing:
debugfs dir <zram100> creation failed
zram: Error creating memory pool
... and so on.
Fix it by passing zram->disk->disk_name to zram_meta_alloc() instead of
divice_id. We construct zram%d name earlier and keep it as a ->disk_name,
no need to snprintf() it again.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
When we add a new node, the edge of memory may be wrong.
e.g. system has 4 nodes, and node3 is movable, node3 mem:[24G-32G],
1. hotremove the node3,
2. then hotadd node3 with a part of memory, mem:[26G-30G],
3. call hotadd_new_pgdat()
free_area_init_node()
get_pfn_range_for_nid()
4. it will return wrong start_pfn and end_pfn, because we have not
update the memblock.
This patch also fixes a BUG_ON during hot-addition, please see
http://marc.info/?l=linux-kernel&m=142961156129456&w=2
Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
