||
--
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/20140812/d3b017cc/attachment.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/20140812/53a6de18/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/29e67dc5/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/be1b1220/attachment.html>
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/e6533237/attachment.html>
From: J?r?me Glisse
When experiencing memory pressure we want to minimize pool size so that
memory we just shrinked is not added back again just as the next thing.
This will divide by 2 the maximum pool size for each device each time
the pool have to shrink. The limit is bumped again is next all
From: J?r?me Glisse
Current code never allowed the page pool to actualy fill in anyway. This fix
it and also allow it to grow over its limit until it grow beyond the batch
size for allocation and deallocation.
Signed-off-by: J?r?me Glisse
Reviewed-by: Mario Kleiner
Tested-by: Michel D?nzer
Cc
From: J?r?me Glisse
Due to bug in code it appear that some of the pool where never properly
use and always empty. Before fixing that bug this patch set sensible
limit on pool size. The magic 64MB number was nominated.
This is obviously a some what arbitrary number but the intend of ttm pool
is t
So it seems there was several issue with the various ttm pool. The obvious
one is fixed in patch 2 where the always empty pool syndrom is addressed.
However the pool size are kind of crazy and because before some pool were
never actualy fill we might never have experience the hill effect of the
cra
On 08/12/14 18:17, Fabio Estevam wrote:
> On Tue, Aug 12, 2014 at 2:30 PM, Randy Dunlap
> wrote:
>> This patch fixed 'make xmldocs' failed on linus's tree and
>> linux-next as of 8th/Aug,2014.
>>
>> When drm merge for 3.17-rc1 happen, a file was renamed from
>> drm_stub.c to drm_drv.c.
>> But Do
From: David Miller
Date: Fri, 04 Apr 2014 16:52:02 -0400 (EDT)
> I'll try to follow up with a patch some time next week.
And next week became 4 months later, sorry :-/
Meelis, I've coded up a patch series that should take care of this
issue, which I'll post to sparclinux with you CC:'d right no
into library code with non-default fpu control word. On some cpus setting the
fpu control word can actually be very expensive (though some have it fully
pipelined now so it's cheap).
--
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/20140812/52b5de6b/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140812/6a2aa1da/attachment.sig>
On Tue, Aug 12, 2014 at 2:30 PM, Randy Dunlap wrote:
> This patch fixed 'make xmldocs' failed on linus's tree and
> linux-next as of 8th/Aug,2014.
>
> When drm merge for 3.17-rc1 happen, a file was renamed from
> drm_stub.c to drm_drv.c.
> But Documentation/DocBook/drm.tmpl still have an old file
On Wed, Aug 13, 2014 at 04:04:15AM +0200, Mario Kleiner wrote:
> On 08/13/2014 03:50 AM, Michel D?nzer wrote:
> >On 12.08.2014 00:17, Jerome Glisse wrote:
> >>On Mon, Aug 11, 2014 at 12:11:21PM +0200, Thomas Hellstrom wrote:
> >>>On 08/10/2014 08:02 PM, Mario Kleiner wrote:
> On 08/10/2014 01:0
On 2014? 08? 12? 20:54, YoungJun Cho wrote:
> Hi Inki, Andrzej
>
> On 08/11/2014 04:09 PM, Inki Dae wrote:
>> On 2014? 08? 08? 18:40, Andrzej Hajda wrote:
>>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
On 08/08/2014 09:37 AM, Inki Dae wrote:
> On 2014? 08? 08? 16:03, Thierry Reding wrot
On Wed, Aug 13, 2014 at 10:50:25AM +0900, Michel D?nzer wrote:
> On 12.08.2014 00:17, Jerome Glisse wrote:
> > On Mon, Aug 11, 2014 at 12:11:21PM +0200, Thomas Hellstrom wrote:
> >> On 08/10/2014 08:02 PM, Mario Kleiner wrote:
> >>> On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
> On 08/10/20
ng up Hawaii support ! :-)
--
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/20140812/2faaf699/attachment-0001.html>
On Tue, Aug 12, 2014 at 06:13:41PM -0400, Jerome Glisse wrote:
> Hi,
>
> So i want over the whole fence and sync point stuff as it's becoming a
> pressing
> issue. I think we first need to agree on what is the problem we want to solve
> and what would be the requirements to solve it.
>
> Problem
Hi Inki, Andrzej
On 08/11/2014 04:09 PM, Inki Dae wrote:
> On 2014? 08? 08? 18:40, Andrzej Hajda wrote:
>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
>>> On 08/08/2014 09:37 AM, Inki Dae wrote:
On 2014? 08? 08? 16:03, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Ink
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/73a6ac47/attachment.html>
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/12d89a74/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/cfc4b9d2/attachment.html>
freedesktop.org/archives/dri-devel/attachments/20140812/e77ba891/attachment-0001.html>
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/6562e1e2/attachment.html>
and attached the file to this post.
--
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/20140812/a08c3b96/attachment.html>
Hi,
So i want over the whole fence and sync point stuff as it's becoming a pressing
issue. I think we first need to agree on what is the problem we want to solve
and what would be the requirements to solve it.
Problem :
Explicit synchronization btw different hardware block over a buffer object.
--
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/20140812/bfe5d883/attachment.html>
Added DT maintainers as we have here quite fundamental DT question:
How shall we model hardware connected to multiple buses, in DT?
Here we have panel connected to two MIPI-DSI buses.
Below is the summary of our propositions, followed by lengthly detailed
discussion,
including proposed bindings.
he bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/dfc593e4/attachment.html>
andle that correctly.
--
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/20140812/774981e8/attachment.html>
g to the target time
code as well.
--
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/20140812/4e9c6d3c/attachment.html>
On Tue, Aug 12, 2014 at 02:12:07PM +0200, Mario Kleiner wrote:
> On 08/11/2014 05:17 PM, Jerome Glisse wrote:
> >On Mon, Aug 11, 2014 at 12:11:21PM +0200, Thomas Hellstrom wrote:
> >>On 08/10/2014 08:02 PM, Mario Kleiner wrote:
> >>>On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
> On 08/10/201
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/33a7653a/attachment.html>
/lists.freedesktop.org/archives/dri-devel/attachments/20140812/48fd/attachment.html>
/sys/class/drm/card0/device/power_dpm_force_performance_level
bash: echo: write error: Invalid argument
Not sure, what valid options would be for me.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
From: Clint Taylor
Pixel replicated modes should be 720 horizontal pixel and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently
This patch adds non-continuous clock mode support.
Clock mode on Clock Lane is continuous clock by default.
So if we want to transmit data in non-continuous clock mode
to reduce power consumption, then host driver should clear
DSIM_TX_REQUEST_HSCLK.
For this, this patch makes the host driver set
This patch adds a new flag, MIPI_DSI_MODE_LPM, to transmit data
in low power. With this flag, msg.flags has MIPI_DSI_MSG_USE_LPM
so that host driver of each SoC can clear or set relevant register
bit for low power transmission.
All host controllers shall support continuous clock behavior on the
Cl
This patch considers low power transmisson to two clock behaviors,
non-continuous and continuous clock mode.
These two clock behaviors can transmit data in high speed or low power.
So this patch series adds a new flag, MIPI_DSI_MODE_LPM so that each
host driver can setup its host controller proper
On 1 July 2014 10:10, Marek Szyprowski wrote:
> This is a long awaited patch series enabling support for HDMI output
> available on Exynos4412-based Odroid boards (X/X2/U2/U3/U3+) and
> Exynos4210 Universal C210 board.
Hello,
have tested a few of these patches on an Odroid-U2 on top of
linux/mas
From: Christian K?nig
This patch allows userspace to created zero sized buffers
for use as pure synchronization object.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_drv.c| 3 ++-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_vm.c | 3 +
From: Christian K?nig
This patch allows to create zero sized TTM buffer
objects for driver internal use.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drive
On 08/11/2014 05:17 PM, Jerome Glisse wrote:
> On Mon, Aug 11, 2014 at 12:11:21PM +0200, Thomas Hellstrom wrote:
>> On 08/10/2014 08:02 PM, Mario Kleiner wrote:
>>> On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
On 08/10/2014 05:11 AM, Mario Kleiner wrote:
> Resent this time without HTML
On Tue, Jul 29, 2014 at 02:58:23PM -0700, clinton.a.taylor at intel.com wrote:
> From: Clint Taylor
>
> CEA SD interlaced modes use a horizontal 720 pixels that are pixel replicated
> to 1440. The current driver reports 1440 pixel to the OS and does not set
> pixel replicated modes.
>
> Signed
On Tue, Aug 12, 2014 at 10:50 AM, David Herrmann
wrote:
> On Tue, Aug 12, 2014 at 10:45 AM, Daniel Vetter
> wrote:
>>
>> Yet another one that was missed.
>>
>> Signed-off-by: Daniel Vetter
>
> This was already sent by Thierry. I have it in my local branch as:
>
> commit fc69dcf665ea46115c88d54
Hi Rob,
On Tue, 12 Aug 2014 07:20:09 -0400
Rob Clark wrote:
> On Tue, Aug 12, 2014 at 7:14 AM, Boris BREZILLON
> wrote:
> > Hi,
> >
> > On Sat, 12 Jul 2014 16:06:06 +0200
> > Boris BREZILLON wrote:
> >
> >> Hello,
> >>
> >> This patch series reworks the flip-work framework to make it safe when
https://bugzilla.kernel.org/show_bug.cgi?id=76321
--- Comment #13 from Alex Deucher ---
Yes, I've cc'ed stable.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi,
On Sat, 12 Jul 2014 16:06:06 +0200
Boris BREZILLON wrote:
> Hello,
>
> This patch series reworks the flip-work framework to make it safe when
> calling drm_flip_work_queue from atomic contexts.
>
> The 2nd patch of this series is optional, as it only reworks
> drm_flip_work_init prototype
behavior.
Which older kernels worked? Can you bisect?
--
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/20140812/aa3a28d5/attachment.html>
On Tue, Aug 12, 2014 at 10:03:26AM +0200, Daniel Vetter wrote:
> On Tue, Aug 12, 2014 at 9:20 AM, Pekka Paalanen
> wrote:
> >> but I tend to think it would be nice for compositors (userspace) to
> >> know explicitly what is going on.. ie. if some layers are blended via
> >> intermediate buffer,
Hi,
On Tue, 22 Jul 2014 14:23:42 +0200
Boris BREZILLON wrote:
> Hello,
>
> This patch series is a proposal to describe the different data formats used
> by HW components to connect with each other.
>
> This is just a copy of the existing V4L2_MBUS_FMT defintions with a neutral
> name so that i
tch I've sent to Alex recently.
--
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/20140812/2ba7fb0f/attachment.html>
of register
> reads and writes in there anyway.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/55b29765/attachment.html>
Am 11.08.2014 um 16:52 schrieb Alex Deucher:
> On Mon, Aug 11, 2014 at 5:08 AM, Christian K?nig
> wrote:
>> Am 07.08.2014 um 21:43 schrieb Alex Deucher:
>>
>>> On Thu, Aug 7, 2014 at 11:32 AM, Christian K?nig
>>> wrote:
Am 07.08.2014 um 16:32 schrieb Alex Deucher:
> On Thu, Aug 7, 2
On 2014? 08? 11? 18:11, Thierry Reding wrote:
> On Mon, Aug 11, 2014 at 05:15:35PM +0900, Inki Dae wrote:
>> On 2014? 08? 11? 16:50, Thierry Reding wrote:
>>> On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote:
On 2014? 08? 11? 16:24, Thierry Reding wrote:
> On Mon, Aug 11, 2014 at 0
On Mon, 11 Aug 2014 19:27:45 +0200
Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 10:16:24AM -0700, Eric Anholt wrote:
> > Daniel Vetter writes:
> >
> > > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> > >> Hi,
> > >>
> > >> there is some hardware than can do 2D compositing
rab to make a recording @ 30fps they become
short again.
--
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/20140812/ed036b5e/attachment.html>
On Mon, 11 Aug 2014 07:37:18 -0700
Matt Roper wrote:
> On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> > Hi,
> >
> > there is some hardware than can do 2D compositing with an arbitrary
> > number of planes. I'm not sure what the absolute maximum number of
> > planes is, but for
Since we cannot make sure the 'ref->size' will always be none zero here,
and then if it equals to zero, the kzalloc() will return ZERO_SIZE_PTR,
which equals to ((void *)16).
This patch fix this with just doing the zero check before calling kzalloc().
Signed-off-by: Xiubo Li
---
drivers/gpu/drm
Since we cannot make sure the 'total_objects' and 'gamma_size' will always
be none zero here, and then if either equals to zero, the kzalloc() will
return ZERO_SIZE_PTR, which equals to ((void *)16).
This patch fix this with just doing the zero check before calling kzalloc().
Signed-off-by: Xiubo
Since we cannot make sure the 'count' and 'dev->driver->dev_priv_size' will
always be none zero here, and then if either equal to zero, the kzalloc()
will return ZERO_SIZE_PTR, which equals to ((void *)16).
So this patch fix this with just doing the zero check before calling kzalloc().
Signed-off
Xiubo Li (3):
drm/bufs: Fix possible ZERO_SIZE_PTR pointer dereferencing error.
drm/crtc: Fix possible ZERO_SIZE_PTR pointer dereferencing error.
drm/global: Fix possible ZERO_SIZE_PTR pointer dereferencing error.
drivers/gpu/drm/drm_bufs.c | 12 +---
drivers/gpu/drm/drm_crtc.c
g lockdep
> when tracking down problems rather than needlessly evaluating the
> conditional every time when there are no bugs.
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/cd0a591f/attachment.html>
Am 11.08.2014 um 17:00 schrieb Alex Deucher:
> On Mon, Aug 11, 2014 at 4:42 AM, Michel D?nzer wrote:
>> On 08.08.2014 22:34, Alex Deucher wrote:
>>> On Fri, Aug 8, 2014 at 9:31 AM, Alex Deucher
>>> wrote:
On Fri, Aug 8, 2014 at 4:50 AM, Michel D?nzer
wrote:
> On 08.08.2014 17:44,
Hi
On Tue, Aug 12, 2014 at 10:45 AM, Daniel Vetter
wrote:
>
> Yet another one that was missed.
>
> Signed-off-by: Daniel Vetter
This was already sent by Thierry. I have it in my local branch as:
commit fc69dcf665ea46115c88d542f806f2780e74a21c
Author: Thierry Reding
Date: Fri Aug 8 11:33:1
Yet another one that was missed.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 1d3756d3176c..bacefc5b222e 100644
--- a/Documentation/DocBook
This patch fixed 'make xmldocs' failed on linus's tree and
linux-next as of 8th/Aug,2014.
When drm merge for 3.17-rc1 happen, a file was renamed from
drm_stub.c to drm_drv.c.
But Documentation/DocBook/drm.tmpl still have an old file name.
Signed-off-by: Masanari Iida
Signed-off-by: Randy Dunlap
On Mon, 11 Aug 2014 09:32:32 -0400
Rob Clark wrote:
> On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter wrote:
> > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> >> What if I cannot even pick a maximum number of planes, but wanted to
> >> (as the hardware allows) let the 2D compo
https://bugzilla.kernel.org/show_bug.cgi?id=76321
--- Comment #12 from Pali Roh?r ---
Alex, can you send that patch to stable trees like that in attachment 136431?
Because before these patches sysfs reported battery/performance dpm state when
card was turned off and some script used that informat
On Mon, 11 Aug 2014 17:35:31 +0200
Daniel Vetter wrote:
> Well for other drivers/stacks we'd fall back to GL compositing. pixman
> would obviously be terribly. Curious question: Can you provoke the
> hw/firmware to render into abitrary buffers or does it only work together
> with real display out
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140812/90536b36/attachment.html>
On Tue, Aug 12, 2014 at 9:20 AM, Pekka Paalanen wrote:
>> but I tend to think it would be nice for compositors (userspace) to
>> know explicitly what is going on.. ie. if some layers are blended via
>> intermediate buffer, couldn't that intermediate buffer be potentially
>> re-used on next frame
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/20140812/f044215d/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/eb0f9ae5/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/a1c78233/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/612e773b/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/10753b32/attachment.html>
t;
>> Yeah I guess we need to check reality here. If the "we've run out of bw"
>> case just never happens then it's pointless to write special code for it.
>> And we can always add a limit later for the case where GL is usually
>> better and tell userspace that we can't do this many planes. Exact same
>> thing with running out of memory bw can happen anywhere else, too.
>
> I had a chat with Eric last night, and our different views about the
> on-line/real-time performance limits of the HVS seem to be due to alpha
> blending.
>
> Eric has not been using alpha blending much or at all, while my
> experiments with Weston and DispmanX pretty much always need alpha
> blending (e.g. because DispmanX cannot say that only a sub-region of a
> buffer needs blending). Eric says alpha blending kills the
> performance.
Note, I wasn't saying anything about performance. I was just talking
about how compositing in X knows that (almost) everything is actually
opaque, so I don't have the worries about alpha blending that you
apparently do in Weston.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/7e5e6b21/attachment-0001.sig>
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/20140812/9bca0a1b/attachment.html>
On Tue, Aug 12, 2014 at 6:00 AM, Christian K?nig
wrote:
> Am 11.08.2014 um 16:52 schrieb Alex Deucher:
>
>> On Mon, Aug 11, 2014 at 5:08 AM, Christian K?nig
>> wrote:
>>>
>>> Am 07.08.2014 um 21:43 schrieb Alex Deucher:
>>>
On Thu, Aug 7, 2014 at 11:32 AM, Christian K?nig
wrote:
>
eems to make some piglit test results unstable...
--
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/20140812/8f1d964d/attachment.html>
On Mon, Aug 11, 2014 at 04:38:50PM -0700, David Rientjes wrote:
> On Mon, 11 Aug 2014, Rob Clark wrote:
>
> > > I'm suggesting that if you don't want to incur the cost of the conditional
> > > everytime you call a certain function with assert_spin_locked() that you
> > > could covert these to lock
; * sign in the upper bits of a 16 bit register.
> > diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c
> > index 71b0ec0..e69db4f 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -691,7 +691,7 @@ passive_store(struct device *dev, struct
> device_attribute *attr,
> > if (!sscanf(buf, "%d\n", &state))
> > return -EINVAL;
> >
> > - /* sanity check: values below 1000 millicelcius don't make sense
> > + /* sanity check: values below 1000 millicelsius don't make sense
> > * and can cause the system to go into a thermal heart attack
> > */
> > if (state && state < 1000)
> > --
> > 1.8.3.4 (Apple Git-47)
> >
>
>
>
> --
> Eduardo Bezerra Valentin
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/321823e2/attachment-0001.html>
On Tue, Aug 12, 2014 at 7:14 AM, Boris BREZILLON
wrote:
> Hi,
>
> On Sat, 12 Jul 2014 16:06:06 +0200
> Boris BREZILLON wrote:
>
>> Hello,
>>
>> This patch series reworks the flip-work framework to make it safe when
>> calling drm_flip_work_queue from atomic contexts.
>>
>> The 2nd patch of this s
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140812/06063072/attachment.html>
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/0e613be4/attachment.html>
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/4e419e7d/attachment.html>
in the corresponding kernel code.
--
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/20140812/fccf9e27/attachment.html>
ktop.org/archives/dri-devel/attachments/20140812/75c27f27/attachment.html>
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/772c4e99/attachment-0001.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/aea3ee91/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/e5724c95/attachment.html>
93 matches
Mail list logo
