On Mon, Mar 14 2016, Oded Gabbay wrote:
> On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes
> wrote:
>> Passing overlapping source and destination buffers to snprintf
>> formally has undefined behaviour and is rather fragile. While the
>
> I saw there were some different opinions on this.
> Have
>
>> - if (pcie_port_runtime_suspend_allowed(dev))
>> + if (pcie_port_runtime_suspend_allowed(dev)) {
>> + pm_runtime_allow(&dev->dev);
>
> PCI drivers typically have left this decision up to the userspace. I'm
> wondering whether it is good idea to deviate from that here? Of co
Hello there,
[linux-4.5/drivers/gpu/drm/gma500/oaktrail_crtc.c:175]: (error) Uninitialized
struct member: clock.dot
[linux-4.5/drivers/gpu/drm/gma500/oaktrail_crtc.c:175]: (error) Uninitialized
struct member: clock.m1
[linux-4.5/drivers/gpu/drm/gma500/oaktrail_crtc.c:175]: (error) Uninitialized
From: Gustavo Padovan
Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
future API breaks and optimize buffer allocation.
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than ze
From: Gustavo Padovan
struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
drivers/staging/android/uapi/sync.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
On 03/05/2016 06:34 AM, Daniel Vetter wrote:
> On Mon, Feb 29, 2016 at 03:02:09PM +, Chris Wilson wrote:
>> On Mon, Feb 29, 2016 at 03:54:19PM +0100, Daniel Vetter wrote:
>>> On Thu, Feb 25, 2016 at 06:01:22PM +, Chris Wilson wrote:
On Thu, Feb 11, 2016 at 08:04:51PM -0200, Tiago Vigna
26 YEAR OLD U.S. COMPANY NEEDS DISTRIBUTORS IN MANY COUNTRIES for our
amazing slip-resistant floor product.
One 30 minute application with our Amazing Anti-Slip Floor Treatment
will make floors slip-resistant and safe for 4 years - Guaranteed!
Indoors or Outdoors
No Change in Appearance
Typical A
On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes
wrote:
> Passing overlapping source and destination buffers to snprintf
> formally has undefined behaviour and is rather fragile. While the
> rather special case of passing the output buffer as the argument
> corresponding to a leading "%s" in the
On Mon, Mar 14, 2016 at 01:50:41PM +0100, Rafael J. Wysocki wrote:
> On Mon, Mar 14, 2016 at 11:23 AM, Mika Westerberg
> wrote:
> > On Mon, Mar 14, 2016 at 07:47:39PM +1000, Dave Airlie wrote:
> >> >
> >> >> - if (pcie_port_runtime_suspend_allowed(dev))
> >> >> + if (pcie_port_runtime_susp
Am Montag, den 14.03.2016, 15:09 + schrieb Russell King - ARM Linux:
> On Mon, Mar 14, 2016 at 04:02:35PM +0100, Lucas Stach wrote:
> > I guess not using the offset on MC10 will also allow you to enable TS on
> > those parts? In that case we might advertise this with a patchlevel
> > change of
https://bugzilla.kernel.org/show_bug.cgi?id=112781
--- Comment #3 from Christoph Haag ---
4.5 with the patch seems to suspend without problems, thanks.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Just as the function ipu_dmfc_config_wait4eot() tells, the DMFC wait4eot bit
depends on the number of DMFC slots to be used, so it should be called after
the slots are determined in the function ipu_dmfc_alloc_bandwidth().
Based on tests, this patch may eliminate display distortion issue on overlay
The function name 'ipu_dmfc_config_wait4eot' matches the implementation of
the function better than 'ipu_dmfc_init_channel', since it only touches the
wait4eot bits.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
drivers/gpu/ipu-v3/ipu-dmfc.c | 4 ++--
include/video/im
Since the function ipu_dmfc_init_channel() always returns zero, we may
change the return type to void to simplify the code.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/imx/ipuv3-plane.c | 6 +-
drivers/gpu/ipu-v3/ipu-dmfc.c | 4 +---
include/video/imx-ipu-v3.h| 2 +-
3 files chan
To avoid race condition issue, we should protect the function
ipu_dmfc_init_channel() with the mutex dmfc->priv->mutex, since it
configures the register DMFC_GENERAL1 at runtime which contains
several control bits for various display channels. This matches
better with fine grained locking logic in
Am Mittwoch, den 09.03.2016, 12:25 + schrieb Russell King - ARM
Linux:
> On Mon, Feb 29, 2016 at 05:20:16PM +0100, Lucas Stach wrote:
> > If the end of the system DMA window is farther away from the start of
> > physical RAM than the size of the GPU linear window, move the linear
> > window so
On Fri, Mar 11, 2016 at 9:51 AM, Dan Carpenter
wrote:
> At the end of the function we expect "status" to be zero, but it's
> either -EINVAL or unitialized.
>
> Fixes: 788bf83db301 ('drm/amdkfd: Add wave control operation to debugger')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/d
gcc-6 warns about code in the nouveau driver that is obviously silly:
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function 'nv40_perfctr_next':
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison
always evaluats to false [-Wtautological-compare]
if (pm->sequence
gcc-6 warns about a pointless loop in exynos_drm_subdrv_open:
drivers/gpu/drm/exynos/exynos_drm_core.c: In function 'exynos_drm_subdrv_open':
drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: error: self-comparison always
evaluates to false [-Werror=tautological-compare]
list_for_each_entry_rev
On Mon, Mar 14, 2016 at 04:02:35PM +0100, Lucas Stach wrote:
> I guess not using the offset on MC10 will also allow you to enable TS on
> those parts? In that case we might advertise this with a patchlevel
> change of the API.
I don't think we need that - it isn't an API change as such. What
we c
On Mon, 2016-03-14 at 13:41 +0100, Lukas Wunner wrote:
> Hi Bastien,
>
> sorry for the delay.
>
> On Sat, Mar 05, 2016 at 05:31:55PM +0100, Bastien Nocera wrote:
> >
> > We could, on boot, force using the integrated GPU, turning off the
> > discrete GPU that we're not interested in.
> Yes, many
https://bugzilla.kernel.org/show_bug.cgi?id=112781
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 f
Hi David,
As DT binding docs have been acked by Rob Herring since v6,
https://lists.freedesktop.org/archives/dri-devel/2016-March/102135.html
And it seems there is no comments on v7. I wonder if we get a chance
that v7 be merge into v4.6 mainline.
Or if no chance for v4.6, when?
Thanks,
-xinlian
On 2 December 2014 at 10:15, Mark Yao wrote:
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> new file mode 100644
> index 000..e7ca25b
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -0,0 +1,1455 @@
...
> +s
On Mon, Mar 14, 2016 at 11:23 AM, Mika Westerberg
wrote:
> On Mon, Mar 14, 2016 at 07:47:39PM +1000, Dave Airlie wrote:
>> >
>> >> - if (pcie_port_runtime_suspend_allowed(dev))
>> >> + if (pcie_port_runtime_suspend_allowed(dev)) {
>> >> + pm_runtime_allow(&dev->dev);
>> >
>> >
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/5351c988/attachment.html>
Hi Bastien,
sorry for the delay.
On Sat, Mar 05, 2016 at 05:31:55PM +0100, Bastien Nocera wrote:
> We could, on boot, force using the integrated GPU, turning off the
> discrete GPU that we're not interested in.
Yes, many people "solve" this by having grub write the requisite commands
to gmux' I/
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/1318a37a/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160314/6ab9bb03/attachment.html>
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/22679dcd/attachment.html>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/0cf366f3/attachment.html>
On Mon, Mar 14, 2016 at 07:47:39PM +1000, Dave Airlie wrote:
> >
> >> - if (pcie_port_runtime_suspend_allowed(dev))
> >> + if (pcie_port_runtime_suspend_allowed(dev)) {
> >> + pm_runtime_allow(&dev->dev);
> >
> > PCI drivers typically have left this decision up to the userspace.
s
after a certain year should probably be better, as we'll constantly be
adding PCI Ids
for every chipset ever made, and I expect we'll forget some.
Dave.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-RFC-PCI-enable-runtime-PM-on-pcieports-to-let-second.patch
Type: text/x-patch
Size: 1772 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/275f843f/attachment.bin>
On Fri, Mar 11, 2016 at 11:52:44AM +, Lionel Landwerlin wrote:
> Hi Dan,
>
> Thanks a lot for pointing this out. I saw you previous comment but
> didn't realize the issue.
> I'll set the pointer to NULL.
>
> I don't if there is an agreement on this, but do you think the
> unref/free functions
On Mon, Mar 14, 2016 at 12:19:14PM +1000, Dave Airlie wrote:
> On 11 March 2016 at 23:45, Rafael J. Wysocki wrote:
> > On Friday, March 11, 2016 12:58:15 PM Mika Westerberg wrote:
> >> On Thu, Mar 10, 2016 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
> >> > > It doesn't seem to do any runtime PM,
Hi Daniel,
On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:
> On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> >
> > ARC PGU could be found on some development boards from Synopsys.
> > This is a simple byte streamer that reads data from a framebuffer
> > and sends data to
Merge tag 'drm-vc4-fixes-2016-03-03' of github.com:anholt/linux into drm-next
(2016-03-14 09:48:04 +1000)
are available in the git repository at:
git at github.com:anholt/linux.git tags/drm-vc4-next-2016-03-14
for you to fetch changes up to 90d7116061f86c1f8ea460806a0414addea7b58b:
drm/v
On Mon, Mar 14, 2016 at 07:47:39PM +1000, Dave Airlie wrote:
> >
> >> - if (pcie_port_runtime_suspend_allowed(dev))
> >> + if (pcie_port_runtime_suspend_allowed(dev)) {
> >> + pm_runtime_allow(&dev->dev);
> >
> > PCI drivers typically have left this decision up to the userspace.
On 2016å¹´03æ12æ¥ 01:21, John Keeping wrote:
> When closing the DRM device while a vblank is pending, we access
> file_priv after it has been free'd, which gives:
>
>Unable to handle kernel NULL pointer dereference at virtual address
>
>...
>PC is at __list_add+0x5c/0xe8
>
On 2016å¹´03æ04æ¥ 19:04, John Keeping wrote:
> If the geometry of a crtc is changing in an atomic update then we must
> validate the plane size against the new state of the crtc and not the
> current size, otherwise if the crtc size is increasing the plane will be
> cropped at the previous size
On Sun, Mar 13, 2016 at 10:19 PM, Dave Airlie wrote:
> On 11 March 2016 at 23:45, Rafael J. Wysocki wrote:
>> On Friday, March 11, 2016 12:58:15 PM Mika Westerberg wrote:
>>> On Thu, Mar 10, 2016 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
>>> > > It doesn't seem to do any runtime PM,
>>> > > I
dri-devel/attachments/20160314/8a9f9de8/attachment.html>
On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> ARC PGU could be found on some development boards from Synopsys.
> This is a simple byte streamer that reads data from a framebuffer
> and sends data to the single encoder.
>
> Signed-off-by: Alexey Brodkin
> Cc: David Airlie
> Cc
On 14/03/16 01:07, Rob Clark wrote:
> On Sun, Mar 13, 2016 at 5:12 PM, Kieran Bingham
> wrote:
>> On 04/02/16 05:09, Archit Taneja wrote:
>>>
>>>
>>> On 02/03/2016 07:55 PM, Luis Henriques wrote:
This fixes the following build failure:
drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o: In
On Wed, Mar 09, 2016 at 10:56:46AM +0100, Daniel Vetter wrote:
> Hi Dave,
>
> I expect this to be the final drm-misc pull for 4.6:
> - color manager core patch from Lionel - i915 side is ready too, but will
> only land in 4.7, but I figured it's better to land this earlier for
> better coordin
On Mon, Mar 14, 2016 at 3:59 AM, Kieran Bingham
wrote:
> On 14/03/16 01:07, Rob Clark wrote:
>> On Sun, Mar 13, 2016 at 5:12 PM, Kieran Bingham
>> wrote:
>>> On 04/02/16 05:09, Archit Taneja wrote:
On 02/03/2016 07:55 PM, Luis Henriques wrote:
> This fixes the following build f
...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/e5fa0173/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160314/b9c0bd25/attachment.html>
48 matches
Mail list logo
