On Fri, 17 Feb 2017, Dave Airlie wrote:
> On 16 February 2017 at 19:49, Jani Nikula wrote:
>>
>> Hi Dave, this one superseeds [1]. Better to flush out the single uapi
>> fix for v4.11 now so it's not forgotten.
>
> Looks like I had already pulled, I just reverted Maarten's patch on
> top of drm-n
Hi,
On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
> I was wondering about the following. Wasn't there some strict
> requirement about code going upstream, which also included that there
> was a full open-source driver stack for it?
>
> I don't see how this is the case for Mali, n
Hi,
On Thu, Feb 16, 2017 at 01:28:24PM +0100, Tobias Jakobi wrote:
> Hello,
>
> I'm not sure if I'm missing something here, but I don't see how this is
> supposed to work.
>
> This just multiplies the height of the drm_mode_fb_cmd2 object with the
> number of buffers. Let's say I have width=1024
Hi Dave, i915 and GVT fixes for the v4.11 merge window. There's quite a
bit of cc: stable stuff that either didn't apply cleanly to v4.10 or
just arrived too late. I played it safe, and didn't try to rush them to
v4.10 anymore.
This one superseeds [1]. I rebased/recreated the branch to get rid of
https://bugzilla.kernel.org/show_bug.cgi?id=194579
--- Comment #8 from Christian König (deathsim...@vodafone.de) ---
(In reply to Nicolai Hähnle from comment #7)
> Therefore, I'm inclined to say that this is probably not an actual bug.
Yeah, correct. The calculated offset is never used, so the ov
On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
Hi,
On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP
On Fri, 2017-02-17 at 16:32 +1100, Benjamin Herrenschmidt wrote:
> The ast driver configures a window to enable access into BMC
> memory space in order to read some configuration registers.
Aspeed suggested a couple of refinements for some chipsets,
so I'll respin either this week-end or monday.
To use HPD notifier sti CEC driver needs to get phandle
of the hdmi device.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Hans Verkuil
CC: devicet...@vger.kernel.org
version 3:
- change hdmi phandle from "st,hdmi-handle" to "hdmi-handle"
---
arch/arm/boot/dts/stih407-family.dtsi | 12 ---
Implement the HPD notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/sti/Kconfig| 1 +
drivers/gpu/drm/sti/sti_hdmi.c | 14 ++
d
This patch series following what Hans is doing on exynos to support
hotplug detect notifier code.
It add support of HPD in sti_hdmi drm driver and stih-cec driver which
move out of staging.
Those patches should be applied on top of Hans branch exynos4-cec.
I have tested hdmi notifier by pluging/
By using the HPD notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.
Update the bindings documentation the new hdmi phandle.
Signed-off-by: Benjamin Ga
Hi Dave,
this tag has a few IPUv3 fixes that are helpful for the ongoing i.MX
media driver development, a fix for the i.MX53 TV encoder on device
trees that don't set the regulator property, and a patch to drop the
arbitrary minimum framebuffer size limit of 64x64 pixels.
regards
Philipp
The fol
Hi Maxime,
On Wednesday 15 Feb 2017 13:38:44 Maxime Ripard wrote:
> On Mon, Feb 13, 2017 at 11:20:51AM +, Daniel Stone wrote:
> > On 13 February 2017 at 10:54, Maxime Ripard wrote:
> >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
> >>> On Thursday 02 Feb 2017 11:31:56 Max
Hi Maxime,
On Wednesday 15 Feb 2017 13:51:29 Maxime Ripard wrote:
> On Tue, Feb 14, 2017 at 11:25:08PM +0200, Laurent Pinchart wrote:
> > On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote:
> >> On Mon, Feb 13, 2017 at 11:20:51AM +, Daniel Stone wrote:
> >>> On 13 February 2017 at 10:54, Maxi
On Fri, 2017-02-10 at 21:59 +0530, Shashank Sharma wrote:
> Geminilake has a native HDMI 2.0 controller, which is capable of
> driving clocks upto 594Mhz. This patch updates the max tmds clock
> limit for the same.
>
> V2: rebase
> V3: rebase
>
> Cc: Ander Conselvan De Oliveira
> Signed-off-by:
Hello Maxime,
Maxime Ripard wrote:
> Hi,
>
> On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
>> I was wondering about the following. Wasn't there some strict
>> requirement about code going upstream, which also included that there
>> was a full open-source driver stack for it?
>>
>
Hello Maxime,
Maxime Ripard wrote:
> Hi,
>
> On Thu, Feb 16, 2017 at 01:28:24PM +0100, Tobias Jakobi wrote:
>> Hello,
>>
>> I'm not sure if I'm missing something here, but I don't see how this is
>> supposed to work.
>>
>> This just multiplies the height of the drm_mode_fb_cmd2 object with the
>>
Hey everyone,
We have been working towards exposing the backlight as a KMS property
instead of relying on the backlight drivers. We have CC:ed the people we
have found to be the more likely to be interested in the discussion but
please add everyone you think would have some experience with thi
On 17 February 2017 at 12:45, Tobias Jakobi
wrote:
> Hello Maxime,
>
> Maxime Ripard wrote:
>> Hi,
>>
>> On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
>>> I was wondering about the following. Wasn't there some strict
>>> requirement about code going upstream, which also included t
The assignment found in the main loop in sun4i_layers_init:
struct sun4i_layer *layer = layers[i];
is useless as it gets overwritten by the next line:
layer = sun4i_layer_init_one(drm, plane);
Drop the assignment.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_la
Hi Rafael,
On Fri, Feb 17, 2017 at 1:27 PM, Rafael J. Wysocki wrote:
> On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote:
>> There are ~4300 uses of pr_warn and ~250 uses of the older
>> pr_warning in the kernel source tree.
>>
>> Make the use of pr_warn consistent across all kernel files.
>>
>
sun4i_layers_init allocates an array to store pointers to newly created
layers returned by sun4i_layer_init_one(), but fails to actually store
them. But it actually returns the empty array to unsuspecting users.
Save the pointers in the array, so that they may be used later.
Signed-off-by: Chen-Y
In sun4i_layers_init we are allocating an array of pointers to struct
sun4i_layer:
layers = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes),
sizeof(**layers), GFP_KERNEL);
The element size should be the size of an individual element of the
array. Chan
On 02/17/2017 03:41 AM, Dave Airlie wrote:
> On 16 February 2017 at 08:16, Marek Vasut wrote:
>> Hi,
>>
>> I collected the MXSFB fixes, based on top of airlied/drm-fixes:
>
> At this stage I'd rather not give these to Linus, can you rebase them onto
> drm-next, and resend, feel free to add stable
drm_vblank_init can fail due to insufficient memory. Ignoring the error
and proceeding may cause the kernel to dereference an invalid pointer
when vblank is enabled.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
commit bb98e72adaf9d19719aba35f802d4836f5d5176c
Author: Hans de Goede
Date: Fri Dec 2 15:29:04 2016 +0100
drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from
vlv_init_display_clock_gating
On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boo
There are ~4300 uses of pr_warn and ~250 uses of the older
pr_warning in the kernel source tree.
Make the use of pr_warn consistent across all kernel files.
This excludes all files in tools/ as there is a separate
define pr_warning for that directory tree and pr_warn is
not used in tools/.
Done
The master bind function calls numerous drm functions which initialize
underlying structures. It also tries to bind the various components
of the display pipeline, some of which may add additional drm objects.
This patch adds proper cleanup functions in the error path of the
master bind function.
Hi Maxime,
This is the first bunch of fixes for the sun4i drm driver. This is part
of the cleanup I am doing towards making the driver support multiple
display pipelines.
Patch 1 moves the drm_mode_config_cleanup call from sun4i_framebuffer_free
to be called directly in sun4i_drv_unbind. This is
drm_mode_config_cleanup is the complement of drm_mode_config_init, which
is called in the bind function of sun4i_drv. drm_mode_config_cleanup
should be put in the unbind function to match.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
drivers/gpu/drm/sun4i/sun4
sun4i_crtc_init can fail for a number of reasons. Instead of returning
a NULL pointer when it fails, pass back the encountered error using
ERR_PTR.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 4 ++--
drivers/gpu/drm/sun4i/sun4i_drv.c | 4 ++--
2 files changed, 4 inserti
On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning
Hi Dave,
The following changes since commit 9ca70356a9260403c1bda40d942935e55d00c11c:
Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 +1000)
are available in the git repository at:
git://linuxtv.org/pinchartl/media.git drm/next/platform
for you to fetch changes up to 76ad
What's the verdict? We've got [1] which is about to become another
(driver) implementation - better to change before that merges than
after I guess.
-Brian
[1] https://lkml.org/lkml/2017/2/13/304
On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote:
Hi,
On 15 February 2017 at 11:39, V
On Thu, 16 Feb 2017, Ville Syrjälä wrote:
> On Thu, Feb 16, 2017 at 12:36:43PM +0200, Jani Nikula wrote:
>> Make the function useful for resetting, not just setting, the ELD.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_edid.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>>
On Fri, Feb 17, 2017 at 04:02:02PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2017, Ville Syrjälä wrote:
> > On Thu, Feb 16, 2017 at 12:36:43PM +0200, Jani Nikula wrote:
> >> Make the function useful for resetting, not just setting, the ELD.
> >>
> >> Signed-off-by: Jani Nikula
> >> ---
> >> dr
This make sure that of_platform_depopulate() is called if an error
occur in probe after populating the date from the device tree.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_drv.c
Lost of calls to of_platform_populate() are not unbalanced by a call
to of_platform_depopulate(). This create issues while drivers are
bind/unbind.
In way to solve those issues is to add devm_of_platform_populate()
which will call of_platform_depopulate() when the device is unbound
from the bus.
Lost of calls to of_platform_populate() are not unbalanced by a call
to of_platform_depopulate(). This create issues while drivers are
bind/unbind.
In way to solve those issues is to add devm_of_platform_populate()
which will call of_platform_depopulate() when the device is unbound
from the bu
On 17/02/17 13:54, Brian Starkey wrote:
What's the verdict? We've got [1] which is about to become another
(driver) implementation - better to change before that merges than
after I guess.
-Brian
[1] https://lkml.org/lkml/2017/2/13/304
On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wro
Am 17.02.2017 um 08:11 schrieb Joe Perches:
To enable eventual removal of pr_warning
This makes pr_warn use consistent for drivers/gpu
Prior to this patch, there were 15 uses of pr_warning and
20 uses of pr_warn in drivers/gpu
Signed-off-by: Joe Perches
Acked-by: Christian König .
---
d
On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:
> On 17/02/17 13:54, Brian Starkey wrote:
> > What's the verdict? We've got [1] which is about to become another
> > (driver) implementation - better to change before that merges than
> > after I guess.
> >
> > -Brian
> >
> > [1] ht
On 17/02/17 14:56, Ville Syrjälä wrote:
On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:
On 17/02/17 13:54, Brian Starkey wrote:
What's the verdict? We've got [1] which is about to become another
(driver) implementation - better to change before that merges than
after I guess.
Follow the naming in debugfs also for logging, add "unknown" for values
beyond the enumerated ones.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_connector.c | 41 +
drivers/gpu/drm/drm_debugfs.c | 24 +---
include/drm/drm_connec
Hi,
On 17 February 2017 at 14:56, Ville Syrjälä
wrote:
> On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:
>> If we're talking fixed point reprsentation, ChromeOS is using this :
>>
>> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice&l=209
Handle debugfs override edid and firmware edid at the low level to
transparently and completely replace the real edid. Previously, we
practically only used the modes from the override EDID, and none of the
other data. This also prevents actual EDID reads when the EDID is to be
overridden, but retai
Make the drm_edid_to_eld() function useful for resetting, not just
setting, the ELD and HDMI VSDB data, without debug warnings about
missing CEA extensions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c
Make the firmware loader more generic and generally useful.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid_load.c| 17 -
drivers/gpu/drm/drm_probe_helper.c | 8 +++-
include/drm/drm_edid.h | 7 ---
3 files changed, 15 insertions(+), 17 deletions
v2 of cover.1487241304.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1487241304.git.jani.nikula@intel.com
BR,
Jani.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Skip DDC probe for forced connector status. Don't try to read the EDID
if the connector is forced off. Skipping probe for forced on connectors
will make more sense when drm_do_get_edid() will handle override and
firmware EDIDs.
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/
On Fri, Feb 17, 2017 at 03:05:28PM +, Lionel Landwerlin wrote:
> On 17/02/17 14:56, Ville Syrjälä wrote:
> > On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:
> >> On 17/02/17 13:54, Brian Starkey wrote:
> >>> What's the verdict? We've got [1] which is about to become another
>
On Fri, Feb 17, 2017 at 05:14:47PM +0200, Jani Nikula wrote:
> Follow the naming in debugfs also for logging, add "unknown" for values
> beyond the enumerated ones.
>
> Signed-off-by: Jani Nikula
> ---
> +EXPORT_SYMBOL(drm_get_connector_force_name);
Do we need the symbol outside of drm-core? Ma
On Fri, Feb 17, 2017 at 05:20:50PM +0200, Jani Nikula wrote:
> v2 of cover.1487241304.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1487241304.git.jani.nikula@intel.com
lgtm. For the series
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel OTC
https://bugs.freedesktop.org/show_bug.cgi?id=99850
--- Comment #1 from Tom St Denis ---
Created attachment 129693
--> https://bugs.freedesktop.org/attachment.cgi?id=129693&action=edit
Carrizo run with HEAD~
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99850
Bug ID: 99850
Summary: Tessellation bug on Carrizo
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Prior
On Fri, Feb 17, 2017 at 01:45:44PM +0100, Tobias Jakobi wrote:
> Hello Maxime,
>
> Maxime Ripard wrote:
> > Hi,
> >
> > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
> >> I was wondering about the following. Wasn't there some strict
> >> requirement about code going upstream, whi
On Thu, Feb 16, 2017 at 04:54:45PM +, Emil Velikov wrote:
> On 16 February 2017 at 12:43, Tobias Jakobi
> wrote:
> > Hello,
> >
> > I was wondering about the following. Wasn't there some strict
> > requirement about code going upstream, which also included that there
> > was a full open-source
Hello,
I'm working on a Asus X756UQK laptop with nvidia + intel graphics
cards. After a suspend-resume cycle, the machine hangs on shutdown,
requiring a forced power off. After resuming I sometimes see the
following messages on the kernel log:
[ 186.117539] nouveau :01:00.0: DRM: evictin
Alexandre Belloni wrote:
> On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote:
>>> The device tree is a representation of the hardware itself. The state
>>> of the driver support doesn't change the hardware you're running on,
>>> just like your BIOS/UEFI on x86 won't change the device it reports
On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
wrote:
> I'm happy to file
> a bugzilla entry and provide any other needed information or help with
> testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo
> bugzilla?
Nouveau bugs are tracked on the fdo bugzilla. It would appear t
Hello Ilia,
On 17 February 2017 at 11:14, Ilia Mirkin wrote:
> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
> wrote:
>> I'm happy to file
>> a bugzilla entry and provide any other needed information or help with
>> testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo
>> bug
https://bugs.freedesktop.org/show_bug.cgi?id=99843
--- Comment #4 from d...@jerber.co.uk ---
I created a minimal test program that simply draws the 3 polygons (12 sided). I
have used apitrace with this test program to generate a trace and I'll upload
this shortly. Thanks.
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=99843
--- Comment #5 from d...@jerber.co.uk ---
Created attachment 129697
--> https://bugs.freedesktop.org/attachment.cgi?id=129697&action=edit
Trace
--
You are receiving this mail because:
You are the assignee for the bug.__
On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita
wrote:
> Hello Ilia,
>
> On 17 February 2017 at 11:14, Ilia Mirkin wrote:
>> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
>> wrote:
>>> I'm happy to file
>>> a bugzilla entry and provide any other needed information or help with
https://bugs.freedesktop.org/show_bug.cgi?id=99850
--- Comment #2 from Tom St Denis ---
Dug up the original thread that introduced this patch. Might prove useful in
debugging it.
https://lists.freedesktop.org/archives/mesa-dev/2016-May/116152.html
--
You are receiving this mail because:
You a
On 17.02.2017 18:06, Ilia Mirkin wrote:
> On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita
> wrote:
>> Hello Ilia,
>>
>> On 17 February 2017 at 11:14, Ilia Mirkin wrote:
>>> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
>>> wrote:
I'm happy to file
a bugzilla entry and
Hi all,
this is the first round of patches to enable the Prefetch Resolve Gasket
and the Prefetch Resolve Engine as found on the i.MX6 QuadPlus. Basically
those units are external extensions to the IPUv3 that are able to prefetch
display data from DRAM to an internal SRAM region, transforming the
This is a pretty minor optimization for the IC channel to get
out-of-order AXI returns, but clashes with the AXI ID assignment
that needs to be done for the display channels on QuadPlus.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 2 --
1 file changed, 2 deletions(-)
On i.MX6 QuadPlus the IPU needs to know which PRG has to be
used for this IPU instance. Add a "fsl,prg" property containing
a phandle pointing to the correct PRG device.
Signed-off-by: Lucas Stach
---
Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 ++
1 file changed, 2 inserti
This adds support for the i.MX6 QUadPlus PRG unit. It glues together the
IPU and the PRE units.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/Makefile | 2 +-
drivers/gpu/ipu-v3/ipu-prg.c | 413 +++
drivers/gpu/ipu-v3/ipu-prv.h | 3 +
include/vide
The Prefetch Resolve Engine is a prefetch and tile resolve engine
which prefetches display data from DRAM to an internal SRAM region.
It has a single clock for configuration register access and the
functional units. A single shared interrupt is used for status and
error signaling.
The only externa
This adds the the devicetree binding for the Prefetch Resolve Gasket,
as found on i.MX6 QuadPlus.
The PRG is fairly simple in that it only has a configuration register
range and two clocks, one for the AHB slave port and one for the AXI
ports and the functional units.
The PRE connections need to b
This adds support for the i.MX6 QuadPlus PRE units. Currently only
linear prefetch into SRAM is supported, other modes of operation
like the tiled-to-linear conversion will be added later.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/Makefile | 2 +-
drivers/gpu/ipu-v3/ipu-pre.c | 290 ++
The i.MX6 QuadPlus IPU needs to PRG unit to gain access to the
data bus. Make sure it is present and available to be used.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/ipu-common.c | 7 +++
drivers/gpu/ipu-v3/ipu-prv.h| 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu
On i.MX6 QuadPlus the PRG needs to be clocked in order to pass
through the data access requests from the IDMAC. This call is a
no-op for other all other SoCs.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx
Allow the planes to use the PRG/PRE units as linear prefetchers when
possible. This improves DRAM efficiency a bit and reduces the chance
for display underflow when the memory subsystem is under load.
This does not yet support scanning out tiled buffers directly, as this
needs more work, but it al
Indicate that the fence array will be signaled on the first completion
(signal-on-any mode) as opposed to waiting for all to be signaled.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Daniel Vetter
Cc: "Christian König"
---
drivers/dma-buf/dma-fence-array.c | 3 +++
in
The code currently assumes that all fence arrays it sees are the normal
signal-on-all variety, and decomposes the array into its individual
fences so that it can extract the native i915 fences. If the fence array
is using signal-on-any, we should not decompose as we must not wait on
them all, just
Hi Gabriel,
2017-02-15 Gabriel Krisman Bertazi :
> There are no device specific flags that we need to keep track of here.
> Let it vanish.
>
> Signed-off-by: Gabriel Krisman Bertazi
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
> drivers/gpu/drm/qxl/qxl_drv.h | 3 +--
> drivers/gpu/drm/qxl/qxl
Hi Gabriel,
2017-02-15 Gabriel Krisman Bertazi :
> Every attempt to pin/unpin objects in memory requires
> qxl_bo_reserve/unreserve calls around the pinning operation to protect
> the object from concurrent access, which causes that call sequence to be
> reproduced every place where pinning is ne
On 17 February 2017 at 18:00, Marek Vasut wrote:
> On 02/17/2017 03:41 AM, Dave Airlie wrote:
>> On 16 February 2017 at 08:16, Marek Vasut wrote:
>>> Hi,
>>>
>>> I collected the MXSFB fixes, based on top of airlied/drm-fixes:
>>
>> At this stage I'd rather not give these to Linus, can you rebase
Hi Maxime,
As I feared things have taken a turn for the bitter end :-]
It seems that this is a heated topic, so I'l kindly ask that we try
the following:
- For people such as myself/Tobias/others who feel that driver and DT
bindings should go hand in hand, prove them wrong.
But please, do so by
Hi Ben,
On 16 February 2017 at 21:09, Benjamin Herrenschmidt
wrote:
> On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote:
>> On 16 February 2017 at 09:09, Benjamin Herrenschmidt
>> wrote:
>> > From: "Y.C. Chen"
>> >
>> > Add detection and POST code for AST2500 generation chip,
>> > code orig
On Fri, 2017-02-17 at 21:27 +, Emil Velikov wrote:
> > Heh ok. I don't want to change that POST code too much as I'm not
> > equipped to test it, but I'll have a look later today.
> >
>
> Not sure why you opted for splitting each suggestion in separate
> email, but it seems to have lead to a
https://bugs.freedesktop.org/show_bug.cgi?id=99843
--- Comment #6 from Tom St Denis ---
What hardware is this on? I wonder if it's a dup of 99850 (which was found on
a Carrizo).
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=99843
--- Comment #7 from Ilia Mirkin ---
FWIW it appears to render correctly on both nouveau (GK208) as well as i965
(SKL).
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-
https://bugzilla.kernel.org/show_bug.cgi?id=194579
--- Comment #9 from PaX Team (pagee...@freemail.hu) ---
would the following workaround do the job of not triggering the overflow and
not causing any other logic bugs for our purposes:
--- a/drivers/gpu/drm/ttm/ttm_bo.c 2016-12-13 12:11:19.86
On Fri, 2017-02-17 at 21:27 +, Emil Velikov wrote:
> Hi Ben,
.../...
> Not sure why you opted for splitting each suggestion in separate
> email, but it seems to have lead to a [serious] bugfix to go
> unnoticed.
Many thanks for your reviews. I've put a tentative new series there
https://gi
d 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 # 10:43 0-
2 Merge branch 'for-linus' of git://git.kernel.dk/linux-block
# extra tests on tree/branch linux-next/master
git bisect bad 4ce4a759a3e221b5265ebd03c2fb69a7cf3e # 11:07 0-
1 Add linux-next specific files for 2
Signed-off-by: Geert Uytterhoeven
Cc: Alex Deucher
Cc: Christian König
Cc: dri-devel@lists.freedesktop.orgamd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/cikd.h | 2 +-
drivers/gpu/drm/radeon/cikd.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/
On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote:
> > The device tree is a representation of the hardware itself. The state
> > of the driver support doesn't change the hardware you're running on,
> > just like your BIOS/UEFI on x86 won't change the device it reports to
> > Linux based on wheth
On 02/18/2017 01:22 AM, Christian König wrote:
> Am 17.02.2017 um 08:11 schrieb Joe Perches:
>> To enable eventual removal of pr_warning
>>
>> This makes pr_warn use consistent for drivers/gpu
>>
>> Prior to this patch, there were 15 uses of pr_warning and
>> 20 uses of pr_warn in drivers/gpu
>>
On Fri, Feb 17, 2017 at 04:44:19PM +0100, Maxime Ripard wrote:
[...]
> We already have DT bindings for out of tree drivers, there's really
> nothing new here.
We have DT bindings for *hardware*, not for drivers. As stated in
Documentation/devicetree/usage-model.txt:
"The "Open Firmware Device Tre
https://bugs.freedesktop.org/show_bug.cgi?id=99843
--- Comment #8 from d...@jerber.co.uk ---
The hardware is Radeon HD 4890.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop
Am 17.02.2017 um 19:35 schrieb Chris Wilson:
Indicate that the fence array will be signaled on the first completion
(signal-on-any mode) as opposed to waiting for all to be signaled.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Daniel Vetter
Cc: "Christian König"
R
95 matches
Mail list logo
