Adds 4 callbacks for managing fan state/speed
* fan_ctrl_set_mode - manages fan control mode (nonzero == manual)
* fan_ctrl_get_mode - queries fan control mode
* set_fan_speed_percent - manages fan speed as percentage value
* get_fan_speed_percent - queries fan speed as percentage value
Signed-off
This adds percent-based fan control. Attributes (I hope) follow the
sysfs-interface specification:
* pwm1 - fan speed query/manage
* pwm1_max, pwm1_min - min/max values for fan pwm (constant)
* pwm1_enable - fan control query/manage (enable/disable)
(There is no rpm-based control for now)
Signed-
This adds a possibility to control fan on CI parts
via exported hwmon variables. Note that automatic
ucode fan management pauses if you choose to enable
manual fan control
Signed-off-by: Oleg Chernovskiy
---
drivers/gpu/drm/radeon/ci_dpm.c | 32
drivers/gpu/
Hi Julia,
On Mon, Dec 8, 2014 at 6:20 AM, Julia Lawall wrote:
> These patches replace what appears to be a reference to the name of the
> current function but is misspelled in some way by either the name of the
> function itself, or by %s and then __func__ in an argument list.
Would there be any
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/fe0e2f63/attachment.html>
On 8 December 2014 at 10:34, Theodore Ts'o wrote:
> This is an update to a problem which I reported several months ago
> (see below). The symptoms have changed a bit since then, but they've
> stablized since 3.17 and 3.18-rcX, and while annoying, it's tolerable,
> so I've been living with it.
>
>
From: Dave Airlie
On MST systems the monitors don't appear when we set the fb up,
but plymouth opens the drm device and holds it open while they
come up, when plymouth finishes and lastclose gets called we
don't do the delayed fb probe, so the monitor never appears on the
console.
Fix this by mo
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141208/498536ee/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/fdd034e7/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/06327231/attachment.html>
On 11/12/2014 09:39 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> dma_alloc_coherent() returns a kernel virtual address that is part of
> the linear range. Passing such an address to virt_to_page() is illegal
> on non-coherent architectures. This causes the kernel to oops on 64-bit
> ARM be
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/2109ff42/attachment-0001.html>
On 12/08/2014 04:14 PM, Alexandre Courbot wrote:
> On 11/12/2014 09:39 PM, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> dma_alloc_coherent() returns a kernel virtual address that is part of
>> the linear range. Passing such an address to virt_to_page() is illegal
>> on non-coherent architec
On 12/08/2014 04:14 PM, Alexandre Courbot wrote:
> On 11/12/2014 09:39 PM, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> dma_alloc_coherent() returns a kernel virtual address that is part of
>> the linear range. Passing such an address to virt_to_page() is illegal
>> on non-coherent architec
On 12/08/2014 05:11 PM, Alexandre Courbot wrote:
> On 12/08/2014 04:14 PM, Alexandre Courbot wrote:
>> On 11/12/2014 09:39 PM, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> dma_alloc_coherent() returns a kernel virtual address that is part of
>>> the linear range. Passing such an address
On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote:
> Remove the function intel_output_name() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Queued for 3.20, thanks for t
On Mon, Dec 08, 2014 at 01:38:59PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> On MST systems the monitors don't appear when we set the fb up,
> but plymouth opens the drm device and holds it open while they
> come up, when plymouth finishes and lastclose gets called we
> don't do the delay
Hello David,
This series of patches fix various issues in STI drm driver.
Now HDMI i2c adapter could be selected in device tree
and plug detection doesn't use gpio anymore.
I also had fix some signal timing problems after testing the driver
on more hardware.
The remaining patches attemps to simpl
On Sun, 07 Dec 2014, Rickard Strandqvist wrote:
> Removes some functions that are not used anywhere:
> vlv_flisdsi_read() vlv_gps_core_write() vlv_gps_core_read()
> vlv_ccu_write() vlv_ccu_read() vlv_gpio_nc_read()
I'd let them be.
BR,
Jani.
>
> This was partially found by using a static code
On Tue, Dec 2, 2014 at 11:31 AM, Ajay kumar wrote:
> On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar
> wrote:
>> Currently, third party bridge drivers(ptn3460) are dependent
>> on the corresponding encoder driver init, since bridge driver
>> needs a drm_device pointer to finish drm initializations.
On Sun, 07 Dec 2014, Julia Lawall wrote:
> Replace a misspelled function name by %s and then __func__.
>
> This was done using Coccinelle, including the use of Levenshtein distance,
> as proposed by Rasmus Villemoes.
>
> Signed-off-by: Julia Lawall
>
> ---
> The semantic patch is difficult to sum
On Sun, 07 Dec 2014, Rickard Strandqvist wrote:
> Remove the function dsi_hs_mode_enable() that is not used anywhere.
Please don't.
BR,
Jani.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm
On Mon, 08 Dec 2014, Rickard Strandqvist wrote:
> Remove the function dsi_rr_formula() that is not used anywhere.
Please don't.
BR,
Jani.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/i91
On Sun, Dec 07, 2014 at 10:36:10PM +0100, Rickard Strandqvist wrote:
> Remove the function intel_dp_set_drrs_state() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Ok I've merged one of t
2014-12-08 6:42 GMT-02:00 Daniel Vetter :
> On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote:
>> Remove the function intel_output_name() that is not used anywhere.
>>
>> This was partially found by using a static code analysis program called
>> cppcheck.
>>
>> Signed-off-by: Ric
, 1);
> + edp_ctrl_irq_enable(ctrl, 1);
> + }
> +
> + ret = drm_dp_link_probe(ctrl->drm_aux, &ctrl->dp_link);
> + if (ret) {
> + pr_err("%s: read dpcd cap failed, %d\n", __func__, ret);
> + goto disable_ret;
> + }
> +
> + /* Initialize link rate as panel max link rate */
> + ctrl->link_rate = drm_dp_link_rate_to_bw_code(ctrl->dp_link.rate);
There's a lot of code here that should probably be a separate function
rather than be called as part of retrieving the EDID.
> +int msm_edp_ctrl_timing_cfg(struct edp_ctrl *ctrl,
> + struct drm_display_mode *mode, struct drm_display_info *info)
Can mode and info be const?
> +{
> + u32 hstart_from_sync, vstart_from_sync;
> + u32 data;
> + int ret = 0;
> +
[...]
> +
> + vstart_from_sync = mode->vtotal - mode->vsync_start;
> + hstart_from_sync = (mode->htotal - mode->hsync_start);
No need for the parentheses.
> diff --git a/drivers/gpu/drm/msm/edp/edp_phy.c
> b/drivers/gpu/drm/msm/edp/edp_phy.c
[...]
> +bool msm_edp_phy_ready(struct edp_phy *phy)
> +{
> + u32 status;
> + int cnt;
> +
> + cnt = 100;
> + while (--cnt) {
> + status = edp_read(phy->base +
> + REG_EDP_PHY_GLB_PHY_STATUS);
> + if (status & 0x01)
Can you add a define for 0x01?
> + break;
> + usleep_range(500, 1000);
> + }
> +
> + if (cnt <= 0) {
This is a better version than above, except that cnt can never be
negative. It will be zero upon timeout.
> + pr_err("%s: PHY NOT ready\n", __func__);
> + return false;
> + } else {
> + return true;
> + }
> +}
> +
> +void msm_edp_phy_ctrl(struct edp_phy *phy, int enable)
> +{
> + DBG("enable=%d", enable);
> + if (enable) {
> + /* Reset */
> + edp_write(phy->base + REG_EDP_PHY_CTRL, 0x005); /* bit 0, 2 */
> + wmb();
> + usleep_range(500, 1000);
> + edp_write(phy->base + REG_EDP_PHY_CTRL, 0x000);
> + edp_write(phy->base + REG_EDP_PHY_GLB_PD_CTL, 0x3f);
> + edp_write(phy->base + REG_EDP_PHY_GLB_CFG, 0x1);
> + } else {
> + edp_write(phy->base + REG_EDP_PHY_GLB_PD_CTL, 0xc0);
> + }
Please, also add defines for the values here. It's impossible to tell
from the code what this does or what might need fixing if there was a
bug.
> +void msm_edp_phy_lane_power_ctrl(struct edp_phy *phy, int up, int max_lane)
bool for up? And unsigned int for max_lane?
> +{
> + int i;
This could also be unsigned int.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/8f94faa8/attachment-0001.sig>
r = NULL;
Can't you simply reuse encoder? It's scope is limited to the
conditionals, so no need to have two separate variables.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/69a9232a/attachment.sig>
On 2014ë
12ì 07ì¼ 21:04, Ajay Kumar wrote:
> ctx->drm_dev is unnecessary since it can be easily accessed
> via ctx->manager->drm_dev. Even the pipe variable inside
> fimd_context is redundant. Cleaning up the same.
Already applied.
Thanks,
Inki Dae
>
> Signed-off-by: Ajay Kumar
> ---
> d
On 2014ë
12ì 07ì¼ 21:04, Ajay Kumar wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> DECON(Display and Enhancement Controller) is the new IP
> in exynos7 SOC for generating video signals
On Mon, Dec 08, 2014 at 12:24:27PM +0200, Jani Nikula wrote:
> On Sun, 07 Dec 2014, Julia Lawall wrote:
> > Replace a misspelled function name by %s and then __func__.
> >
> > This was done using Coccinelle, including the use of Levenshtein distance,
> > as proposed by Rasmus Villemoes.
> >
> > Si
On Mon, Dec 08, 2014 at 10:32:49AM -0200, Paulo Zanoni wrote:
> 2014-12-08 6:42 GMT-02:00 Daniel Vetter :
> > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote:
> >> Remove the function intel_output_name() that is not used anywhere.
> >>
> >> This was partially found by using a st
https://bugzilla.kernel.org/show_bug.cgi?id=89331
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vid
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/e3c52fba/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/f0e62425/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=89331
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
On Sun, Dec 7, 2014 at 2:21 PM, Julia Lawall wrote:
> Replace a misspelled function name by %s and then __func__.
>
> This was done using Coccinelle, including the use of Levenshtein distance,
> as proposed by Rasmus Villemoes.
>
> Signed-off-by: Julia Lawall
Looks fine to me. For consistency,
When a plane is being enabled, plane->crtc has not been set yet. Use
plane->state->crtc.
Signed-off-by: Rob Clark
---
Looks like this is still missing on drm-next.. I probably forgot to
send it earlier.
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi,
So this set of patches adds YUV support for MDP4 and MDP5. This only concerns
the public planes (using ViG pipes).
The fun part was to rebase things on top of atomic but things worked out fine.
I was able to test this for MDP5 on a 8084 target. I cannot say the same for
MDP4 for which I don't
YUV support addition implies that sub-modules of the ViG pipes
need to be configured: Color Space Converter (CSC) and Scaler are
the main components used to convert YUV to RGB data. Note that
the output of a pipe has to be in RGB888 format since only this
format is understood by the (layer) mixers.
Both MDP4 and MDP5 share some code as far as YUV support is
concerned. This change adds this information and will be followed
by the actual MDP4 and MDP5 YUV support patches.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 19 --
drivers/gpu/drm/msm/mdp/mdp5/mdp
This change adds the NV12 format support for public planes.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 213 +++---
drivers/gpu/drm/msm/msm_fb.c | 2 +-
2 files changed, 194 insertions(+), 21 deletions(-)
diff --git a/drive
From: Beeresh Gopal
The patch add support for YUV frame format
for MDP4 platform.
Signed-off-by: Beeresh Gopal
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 104 +++---
1 file changed, 95 insertions(+), 9 deletions(-)
diff --git a/driver
org/archives/dri-devel/attachments/20141208/1d0bd794/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=88911
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Regression|No
From: Christian König
The driver falls back to explicit synchronization as soon as
buffers move between clients or are moved by TTM.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_cs.c | 24 +++-
include/uapi/dr
From: Christian König
Just to be sure that fences we sync to won't be released while accessed.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_sync.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sync.c
b/dr
From: Christian König
PT updates can be seen as command submissions as well,
and we don't necessary need to wait on all of them.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gem.c | 12 +++-
include/uapi/drm/radeon_drm.h | 1 +
2 files changed, 12 insertion
From: Christian König
This patch adds a new 64bit ID as a result to each command submission.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/radeon.h | 13 +-
drivers/gpu/drm/radeon/radeon_cs.c | 13 ++
drivers/gpu/drm/radeon/rad
From: Christian König
This way we can track who created the fence and then only wait
on fences that userspace doesn't knows about.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cik.c | 8 +---
drivers/gpu/drm/radeon/cik_sdma.c | 8 +---
drivers/gpu/drm/ra
From: Christian König
At least inside the same client we should stop waiting for a buffer to be
idle, but rather wait for a specific command submission to complete.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 2 ++
drivers/gpu/drm/radeon/radeon_gem.c | 26 ++
2014-12-08 12:17 GMT-02:00 Daniel Vetter :
> On Mon, Dec 08, 2014 at 10:32:49AM -0200, Paulo Zanoni wrote:
>> 2014-12-08 6:42 GMT-02:00 Daniel Vetter :
>> > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote:
>> >> Remove the function intel_output_name() that is not used anywhere.
longer crash)?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/e2c7980f/attachment.html>
Hi Inki,
2014-12-06 Dave Airlie :
> On 2 December 2014 at 22:38, Gustavo Padovan wrote:
> > Hi Inki,
> >
> > Can you please review this? I also have sent other two patch sets that sits
> > on
> > top of this one. Thanks.
>
> Inki, any plans on when you can get to looking at this?
>
> I think
On Mon, Dec 8, 2014 at 8:28 AM, Thierry Reding
wrote:
> On Fri, Dec 05, 2014 at 04:30:00PM -0500, Hai Li wrote:
> [...]
>
>> + if (IS_ERR(edp))
>> + return PTR_ERR(edp);
>> + priv->edp = edp;
>> +
>> + return 0;
>> +}
>> +
>> +static void edp_unbind(struct device *dev, str
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/01fe4f56/attachment-0001.html>
On Mon, Dec 8, 2014 at 7:45 AM, Rob Clark wrote:
>
> When a plane is being enabled, plane->crtc has not been set yet. Use
> plane->state->crtc.
>
Reviewed-by: Sean Paul
>
> Signed-off-by: Rob Clark
> ---
> Looks like this is still missing on drm-next.. I probably forgot to
> send it earlier.
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/c7a36cf1/attachment.html>
cember/071973.html
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/040f359f/attachment.html>
On Mon, Dec 08, 2014 at 11:42:56AM -0800, Sean Paul wrote:
> On Mon, Dec 8, 2014 at 7:45 AM, Rob Clark wrote:
> >
> > When a plane is being enabled, plane->crtc has not been set yet. Use
> > plane->state->crtc.
> >
>
> Reviewed-by: Sean Paul
Merged to topic/atomic-core, thanks.
-Daniel
--
Dan
/usr/src/linux-3.18> find drivers/ -type l | xargs ls -al
lrwxrwxrwx 1 markh users 21 Dec 7 17:21
./drivers/gpu/drm/nouveau/core/include/nvif/class.h -> ../../../nvif/class.h
lrwxrwxrwx 1 markh users 21 Dec 7 17:21
./drivers/gpu/drm/nouveau/core/include/nvif/event.h -> ../../../nvif/event.h
lr
t;http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/842505a8/attachment.html>
essage.
---
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/c4d392b0/attachment.html>
When we unplug a dp mst branch we unreference the entire tree from
the root towards the leaves. Which is ok, since that's the way the
pointers and so also the refcounts go.
But when we drop the reference we must make sure that we remove the
branches/ports from the lists/pointers before dropping th
ec4(1.0) to vec4(0.9) locks the gpu.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/d153222b/attachment.html>
/Mesa-3D/commits/master
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/f4df8bed/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/01380caf/attachment.html>
This patch adds the suspend/resume support for Tegra drm
driver by calling the corresponding DPMS functions.
Signed-off-by: Mark Zhang
---
Hi,
This patch hooks DSI driver's suspend/resume to implement the whole
display system's suspend/resume. I know this is a super ugly way,
but as we all know,
On Mon, 8 Dec 2014, Julian Calaby wrote:
> Hi Julia,
>
> On Mon, Dec 8, 2014 at 6:20 AM, Julia Lawall wrote:
> > These patches replace what appears to be a reference to the name of the
> > current function but is misspelled in some way by either the name of the
> > function itself, or by %s and
On Mon, 8 Dec 2014, Alex Deucher wrote:
> On Sun, Dec 7, 2014 at 2:21 PM, Julia Lawall wrote:
> > Replace a misspelled function name by %s and then __func__.
> >
> > This was done using Coccinelle, including the use of Levenshtein distance,
> > as proposed by Rasmus Villemoes.
> >
> > Signed-off-
Dez 08 22:21:08 localhost.localdomain kernel: Restarting tasks ... done.
Dez 08 22:21:08 localhost.localdomain kernel: video LNXVIDEO:00: Restoring
backlight state
Dez 08 22:21:08 localhost.localdomain kernel: BUG: unable to handle kernel NULL
pointer dereference at (null)
Dez 08 22:21:
Hi Mark Rutland, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala:
Would you please give an Ack for this?
On 2014å¹´12æ05æ¥ 21:54, Philipp Zabel wrote:
> Am Freitag, den 05.12.2014, 14:27 +0800 schrieb Andy Yan:
>> Signed-off-by: Andy Yan
> This binding is mostly a copy of the existing
> Docu
..
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/3c0a1f9e/attachment.sig>
On Wed, Nov 26, 2014 at 7:38 AM, Andy Lutomirski wrote:
> On Tue, Nov 25, 2014 at 10:42 PM, Michel Dänzer
> wrote:
>> On 20.11.2014 09:58, Andy Lutomirski wrote:
>>>
>>> On Wed, Nov 19, 2014 at 4:07 PM, Andy Lutomirski
>>> wrote:
On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer
73 matches
Mail list logo
