On 02/07/2021 18:07, Michal Wajdeczko wrote:
On 02.07.2021 10:09, Martin Peres wrote:
On 02/07/2021 10:29, Pekka Paalanen wrote:
On Thu, 1 Jul 2021 21:28:06 +0200
Daniel Vetter wrote:
On Thu, Jul 1, 2021 at 8:27 PM Martin Peres
wrote:
On 01/07/2021 11:14, Pekka Paalanen wrote:
On Wed
On 02/07/2021 16:06, Michal Wajdeczko wrote:
On 02.07.2021 10:13, Martin Peres wrote:
On 01/07/2021 21:24, Martin Peres wrote:
[...]
+ i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+ return;
+ }
+
+ /* Default: enable HuC authentication and GuC submiss
On 01/07/2021 21:24, Martin Peres wrote:
[...]
+ i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+ return;
+ }
+
+ /* Default: enable HuC authentication and GuC submission */
+ i915->params.enable_guc = ENABLE_GUC_LOAD_HUC |
ENABLE_GUC_SUBMISSION;
This seems to
On 02/07/2021 10:29, Pekka Paalanen wrote:
On Thu, 1 Jul 2021 21:28:06 +0200
Daniel Vetter wrote:
On Thu, Jul 1, 2021 at 8:27 PM Martin Peres wrote:
On 01/07/2021 11:14, Pekka Paalanen wrote:
On Wed, 30 Jun 2021 11:58:25 -0700
John Harrison wrote:
On 6/30/2021 01:22, Martin Peres
On 01/07/2021 11:14, Pekka Paalanen wrote:
On Wed, 30 Jun 2021 11:58:25 -0700
John Harrison wrote:
On 6/30/2021 01:22, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
On 30/06/2021 21:00, Matthew Brost wrote:
On Wed, Jun 30, 2021 at 11:22:38AM +0300, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
On 29/06/2021 22:35, Matthew Brost wrote:
Add entry for i915 new parallel submission uAPI plan.
v2:
(Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context
v3:
(Marcin
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
drivers/g
On 29/06/2021 22:35, Matthew Brost wrote:
Add entry for i915 GuC submission / DRM scheduler integration plan.
Follow up patch with details of new parallel submission uAPI to come.
v2:
(Daniel Vetter)
- Expand explaination of why bonding isn't supported for GuC
submission
- CC some o
On 11/05/2021 19:39, Matthew Brost wrote:
On Tue, May 11, 2021 at 08:26:59AM -0700, Bloomfield, Jon wrote:
-Original Message-
From: Martin Peres
Sent: Tuesday, May 11, 2021 1:06 AM
To: Daniel Vetter
Cc: Jason Ekstrand ; Brost, Matthew
; intel-gfx ;
dri-devel ; Ursulin, Tvrtko
On 10/05/2021 19:33, Daniel Vetter wrote:
On Mon, May 10, 2021 at 3:55 PM Martin Peres wrote:
On 10/05/2021 02:11, Jason Ekstrand wrote:
On May 9, 2021 12:12:36 Martin Peres wrote:
Hi,
On 06/05/2021 22:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point
On 10/05/2021 19:25, Jason Ekstrand wrote:
On May 10, 2021 08:55:55 Martin Peres wrote:
On 10/05/2021 02:11, Jason Ekstrand wrote:
On May 9, 2021 12:12:36 Martin Peres wrote:
Hi,
On 06/05/2021 22:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point in
On 11/05/2021 05:58, Dixit, Ashutosh wrote:
On Sun, 09 May 2021 16:11:43 -0700, Jason Ekstrand wrote:
Yes, landing GuC support may be the first step in removing execlist
support. The inevitable reality is that GPU scheduling is coming and
likely to be there only path in the not-too-distant f
On 10/05/2021 02:11, Jason Ekstrand wrote:
On May 9, 2021 12:12:36 Martin Peres wrote:
Hi,
On 06/05/2021 22:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point in the
upstreaming plan covered in the following RFC [1].
At a very high level the GuC is a
Hi,
On 06/05/2021 22:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point in the
upstreaming plan covered in the following RFC [1].
At a very high level the GuC is a piece of firmware which sits between
the i915 and the GPU. It offloads some of the scheduling of
unt(struct ttm_pool_type *pt)
Move the definition into the #ifdef block.
Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Signed-off-by: Arnd Bergmann
Thanks Arnd! The patch looks good to me:
Reviewed-by: Martin Peres
---
drivers/gpu/drm/ttm/ttm_pool.c | 29 +
:
Tested-by: Martin Peres
Acked-by: Martin Peres
Thanks,
Martin
Acked-by: Alex Deucher
---
drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 44ec41aa78d6..1b96780b4989
On 30/09/2019 19:13, Matt Roper wrote:
> CRTC background color kernel patches were written about 2.5 years ago
> and floated on the upstream mailing list, but since no opensource
> userspace materialized, we never actually merged them. However the
> corresponding IGT test did get merged and has ba
On 20/04/2019 20:24, Noralf Trønnes wrote:
>
>
> Den 20.04.2019 12.45, skrev Noralf Trønnes:
>> This moves the modesetting code from drm_fb_helper to drm_client so it
>> can be shared by all internal clients.
>>
>> Changes this time:
>> - Use full drm_client_init/release for the modesets (Daniel
ld only be called when
changing the pstate.
However, in the absence of ANY information, we fallback to a
temperature-based management which requires constant polling, so the
patch is accurate and poll = false should only be set if we have a cstate.
So, the patch is Reviewed-by: Martin Peres
>
Hi Anusha,
Sorry, I was under the expectation that userspace developers would
answer you after your first message, and I missed your second one! My
sincere apologies.
Generally, the process is that the student should research the topic by
first asking questions to developers about the effort, the
Hi everyone,
Just a quick word to remind you that the X.Org Foundation got accepted
to the Google Summer of Code 2018!
As a potential mentor, if you have a project falling under the
foundation's (large) umbrella that you would like to kick start or get
help finishing, please add it to the list on
; @@ -10,6 +10,7 @@ nvkm-y += nvkm/subdev/therm/nv50.o
> nvkm-y += nvkm/subdev/therm/g84.o
> nvkm-y += nvkm/subdev/therm/gt215.o
> nvkm-y += nvkm/subdev/therm/gf119.o
> +nvkm-y += nvkm/subdev/therm/gk104.o
> nvkm-y += nvkm/subdev/therm/gm107.o
> nvkm-y += nvkm/subdev/therm/gm20
bring up the GPU. However, the values used by
> the vbios are more power hungry then they need to be, so the nvidia driver
then -> than.
With the comment about not exposing clock gating until patch 2, 3, and 4
have landed addressed, the series is:
Reviewed-by: Martin Peres
Thanks a lot!
s/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild
> @@ -10,6 +10,7 @@ nvkm-y += nvkm/subdev/therm/nv50.o
> nvkm-y += nvkm/subdev/therm/g84.o
> nvkm-y += nvkm/subdev/therm/gt215.o
> nvkm-y += nvkm/subdev/therm/gf119.o
> +nvkm-y += nvkm/subdev/therm/gk104.o
> nvkm-y += nvkm/subdev/therm
he problem is that we do not support all Tegras. How about Tegra TK1+?
I really do not care much about this string, but I guess I probably
should a bit.
With the TK1 added, this is:
Reviewed-by" Martin Peres
> #define DRIVER_DATE "20120801"
>
> #define DRIVER_M
On 27/06/17 11:08, Colin King wrote:
From: Colin Ian King
Array thresolds should be named thresholds, rename it. Also make it static
static const char * const
Signed-off-by: Colin Ian King
Thanks for doing this,
Reviewed-by: Martin Peres
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm
inquiries/questions, please send them to Stéphane Marchesin (please also
CC: board at foundation.x.org).
Martin Peres
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 01/06/17 09:02, Daniel Kasak wrote:
Any news? Seems every TV I bump into these days has Miracast support ...
Sorry, it must be frustrating. Some code needs to be re-implemented
because it was GPL-based and we need it as MIT. Until I have some time
to do this, this will probably not move fo
On 12/05/17 02:46, Manasi Navare wrote:
> Hi Daniel,
>
> Is Call for Papers opened yet for XDC? When do they usually start accepting
> proposals?
Hey Manasi,
Our call for paper is usually sent around June with a deadline for
mid-August. Here is the call for paper from last year, we do expect it
self if you care about this (I did not care to add my name when I
wrote in this file, because the git history makes more sense nowadays.
Otherwise, I have no strong opinions on this patch. I guess the numeric
representation is easier to read, so I will give you my R-b for this and
let others deci
uveau_chip_info, special_groups);
Please align &nouveau_chip_info with dev->dev and split special_groups
on the following line.
> if (IS_ERR(hwmon_dev)) {
> ret = PTR_ERR(hwmon_dev);
> NV_ERROR(drm, "Unable to register hwmon device: %d\n", ret);
>
This commit breaks bisectability, so Ben may have to squash it in the
previous one. Otherwise, this looks good to me:
Reviewed-by: Martin Peres
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
;kobj,
> &hwmon_temp_attrgroup);
> - if (ret)
> - goto error;
> - }
> -
> - /* if the card has a pwm fan */
> - /*XXX: incorrect, need better detection for this, some boards
> have
> - * the gpio entries for pwm fan control even when there's no
> - * actual fan connected to it... therm table? */
> - if (therm->fan_get && therm->fan_get(therm) >= 0) {
> - ret = sysfs_create_group(&hwmon_dev->kobj,
> - &hwmon_pwm_fan_attrgroup);
> - if (ret)
> - goto error;
> - }
> - }
> -
> - /* if the card can read the fan rpm */
> - if (therm && nvkm_therm_fan_sense(therm) >= 0) {
> - ret = sysfs_create_group(&hwmon_dev->kobj,
> - &hwmon_fan_rpm_attrgroup);
> - if (ret)
> - goto error;
> - }
> -
> - if (volt && nvkm_volt_get(volt) >= 0) {
> - ret = sysfs_create_group(&hwmon_dev->kobj,
> - &hwmon_in0_attrgroup);
> -
> - if (ret)
> - goto error;
> - }
> -
> - if (iccsense && iccsense->data_valid && !list_empty(&iccsense->rails)) {
> - ret = sysfs_create_group(&hwmon_dev->kobj,
> - &hwmon_power_attrgroup);
> -
> - if (ret)
> - goto error;
> -
> - if (iccsense->power_w_max && iccsense->power_w_crit) {
> - ret = sysfs_create_group(&hwmon_dev->kobj,
> - &hwmon_power_caps_attrgroup);
> - if (ret)
> - goto error;
> - }
> - }
>
> hwmon->hwmon = hwmon_dev;
> -
> return 0;
> -
> -error:
> - NV_ERROR(drm, "Unable to create some hwmon sysfs files: %d\n", ret);
> - hwmon_device_unregister(hwmon_dev);
> - hwmon->hwmon = NULL;
> - return ret;
> #else
> return 0;
> #endif
> @@ -1037,17 +822,8 @@ nouveau_hwmon_fini(struct drm_device *dev)
> #if defined(CONFIG_HWMON) || (defined(MODULE) &&
> defined(CONFIG_HWMON_MODULE))
> struct nouveau_hwmon *hwmon = nouveau_hwmon(dev);
>
> - if (hwmon->hwmon) {
> - sysfs_remove_group(&hwmon->hwmon->kobj,
> &hwmon_default_attrgroup);
> - sysfs_remove_group(&hwmon->hwmon->kobj, &hwmon_temp_attrgroup);
> - sysfs_remove_group(&hwmon->hwmon->kobj,
> &hwmon_pwm_fan_attrgroup);
> - sysfs_remove_group(&hwmon->hwmon->kobj,
> &hwmon_fan_rpm_attrgroup);
> - sysfs_remove_group(&hwmon->hwmon->kobj, &hwmon_in0_attrgroup);
> - sysfs_remove_group(&hwmon->hwmon->kobj, &hwmon_power_attrgroup);
> - sysfs_remove_group(&hwmon->hwmon->kobj,
> &hwmon_power_caps_attrgroup);
> -
> + if (hwmon->hwmon)
> hwmon_device_unregister(hwmon->hwmon);
> - }
>
> nouveau_drm(dev)->hwmon = NULL;
> kfree(hwmon);
>
Thanks a lot, this patch makes a huge improvement in readability! With
the comments addressed, this patch is:
Reviewed-by: Martin Peres
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
}
> +
> +static const char input_label[] = "GPU core";
> +
> +static int
> +nouveau_read_string(struct device *dev, enum hwmon_sensor_types type, u32
> attr,
> + int channel, char **buf)
Same as above.
> +{
>
people it'll take a while to get there. For now this is good enough I
think.
All true.
Reviewed-by: Daniel Stone
Thanks for this, Daniel!
Reviewed-by: Sumit Semwal
Acked-by: Archit Taneja
Thanks for doing this, this was long overdue!
Reviewed-by: Martin
On 04/04/17 01:17, Christian Lockley wrote:
Hi all, I'm Christian Lockley
I'm wondering if it's too late to apply for GSOC if so I understand and
will apply next year. It not, is the DRM kernel janitor position still
open? While I don't have kernel or graphics experience I do know C and
Java. If
On 26/01/17 14:37, Martin Peres wrote:
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending
On 07/03/17 05:00, Daniel Kasak wrote:
Any news on this? I'm also interested :)
Dan
Hmm, good question! I will ping internally and see if we are ready to
release something as an RFC.
Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.or
On 24/02/17 12:44, Hans de Goede wrote:
Hi,
On 24-02-17 11:23, Martin Peres wrote:
On 24/02/17 11:59, Hans de Goede wrote:
Hi,
On 24-02-17 10:48, Hans de Goede wrote:
Hi,
On 24-02-17 10:46, Hans de Goede wrote:
Hi,
On 24-02-17 10:34, Jani Nikula wrote:
On Fri, 24 Feb 2017, Hans de Goede
On 24/02/17 11:59, Hans de Goede wrote:
Hi,
On 24-02-17 10:48, Hans de Goede wrote:
Hi,
On 24-02-17 10:46, Hans de Goede wrote:
Hi,
On 24-02-17 10:34, Jani Nikula wrote:
On Fri, 24 Feb 2017, Hans de Goede wrote:
On 24-02-17 09:43, Jani Nikula wrote:
I don't think we have any good ideas h
On 22/02/17 17:05, Jani Nikula wrote:
On Mon, 20 Feb 2017, Daniel Thompson wrote:
=== 1) Backlight device interoperability ===
Since we need to keep backward compatibility of the backlight, we have
to keep the current backlight drivers.
Here are possible options:
- Exclusive access: Unregi
On 20/02/17 21:57, Hans de Goede wrote:
Hi,
On 20-02-17 20:27, Dave Airlie wrote:
On 17 February 2017 at 22:58, Martin Peres
wrote:
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
+plasma-devel, as suggested by Martin Gräßlin.
On 17/02/17 14:58, Martin Peres wrote:
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
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 13/02/17 23:05, Eric Anholt wrote:
I was just trying to provide review to get the kernel unstuck. The
kernel should not be blocked until the patch gets lands (this obviously
isn't the case with ioctls, which *don't* land in userspace until kernel
does), you just need userspace published and g
On 06/02/17 17:50, Martin Peres wrote:
On 03/02/17 10:04, Daniel Vetter wrote:
On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
On 01/02/17 22:05, Manasi Navare wrote:
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
Jani Nikula writes:
On Tue, 31 Jan 2017, Eric
On 03/02/17 10:04, Daniel Vetter wrote:
On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
On 01/02/17 22:05, Manasi Navare wrote:
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
Jani Nikula writes:
On Tue, 31 Jan 2017, Eric Anholt wrote:
Martin Peres writes
On 01/02/17 22:05, Manasi Navare wrote:
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
Jani Nikula writes:
On Tue, 31 Jan 2017, Eric Anholt wrote:
Martin Peres writes:
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set
send the userspace a hotplug event. This may
happen right after a modeset or later on.
When available, we should use the link-status information to reset
the wanted mode.
Signed-off-by: Martin Peres
---
WARNING: The patches have not been merged in the kernel yet, so this patch is
merely an RFC.
On 20/01/17 18:44, Jani Nikula wrote:
On Fri, 20 Jan 2017, Martin Peres wrote:
On 19/01/17 11:18, Jani Nikula wrote:
On Wed, 18 Jan 2017, Martin Peres wrote:
On 16/12/16 15:48, Daniel Vetter wrote:
On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
The two remaining patches from
On 19/01/17 11:18, Jani Nikula wrote:
On Wed, 18 Jan 2017, Martin Peres wrote:
On 16/12/16 15:48, Daniel Vetter wrote:
On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
The two remaining patches from [1], rebased.
BR,
Jani.
[1]
http://mid.mail-archive.com/1480984058-552-1-git
On 19/01/17 13:34, Ville Syrjälä wrote:
On Wed, Jan 18, 2017 at 11:05:18PM +0200, Martin Peres wrote:
On 16/12/16 15:48, Daniel Vetter wrote:
On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
The two remaining patches from [1], rebased.
BR,
Jani.
[1]
http://mid.mail-archive.com
On 16/12/16 15:48, Daniel Vetter wrote:
On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
The two remaining patches from [1], rebased.
BR,
Jani.
[1]
http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare@intel.com
Just for the record, I think the only thing
On 04/01/17 17:06, Daniel Vetter wrote:
> On Wed, Jan 04, 2017 at 02:34:36PM +0100, Noralf Trønnes wrote:
>> Hi,
>>
>> I was previously working on tinydrm as a replacement for staging/fbtft.
>> During a break from that work, I started to think about if it would be
>> possible to move the drivers t
On 03/01/17 22:47, Jani Nikula wrote:
> On Fri, 23 Dec 2016, norbert wrote:
>> Hello,
>> about a year ago there was a discussion about Implementing Miracast on
>> this list:
>>
>> https://lists.freedesktop.org/archives/dri-devel/2015-December/096035.html
>>
>> Since then I could not find further i
On 08/11/16 15:56, Arnd Bergmann wrote:
> The newly introduced LED handling for nouveau fails to link when the
> driver is built-in but the LED subsystem is a loadable module:
>
> drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend':
> tvnv17.c:(.text.nouveau_do_suspend+0x10): undefi
On 13/05/16 01:56, Martin Peres wrote:
> Hello,
>
> I have the pleasure to announce that the X.org Developer Conference 2016
> will be held in Helsinki from September 21 to September 23. The venue is
> located at Haaga-Helia university[0], next to the Pasila station.
>
> The
if you are
attending please add your name as early as possible.
I am looking forward to seeing you there, if you have any
inquiries/questions, please send them to me (please also CC: board at
foundation.x.org).
Martin Peres
[0]
https://www.google.fi/maps/place/Ratapihantie+13,+0052
On 03/05/16 23:03, Robert Bragg wrote:
>
>
> On Tue, May 3, 2016 at 8:34 PM, Robert Bragg <mailto:robert at sixbynine.org>> wrote:
>
> Sorry for the delay replying to this, I missed it.
>
> On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres <mailt
On 03/05/16 22:34, Robert Bragg wrote:
> Sorry for the delay replying to this, I missed it.
No worries!
>
> On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres <mailto:martin.peres at free.fr>> wrote:
>
> On 20/04/16 17:23, Robert Bragg wrote:
>
> Gen grap
On 30/04/16 11:07, Manish Bisht wrote:
> Hello Devs,
>
> I want to improve the design of http://www.x.org/wiki/ website and
> want to change the user inerface with the material design theme and
> make it mobile responsive. Can I make the proposal on this and take
> part in the EVoC ?
>
> Waiting
On 20/04/16 17:23, Robert Bragg wrote:
> Gen graphics hardware can be set up to periodically write snapshots of
> performance counters into a circular buffer via its Observation
> Architecture and this patch exposes that capability to userspace via the
> i915 perf interface.
>
> Cc: Chris Wilson
>
On 13/04/16 08:13, kbuild test robot wrote:
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c:96:3-4: Unneeded semicolon
>
>
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Martin Peres
> Signed-off-by: Fengguang Wu
Signed-off-by: Martin Peres
lle/free/ifnullfree.cocci
>
> CC: Karol Herbst
> Signed-off-by: Fengguang Wu
Signed-off-by: Martin Peres
On 08/12/15 19:24, David Herrmann wrote:
> Hi
>
> On Tue, Dec 8, 2015 at 5:39 PM, Martin Peres wrote:
>> On 08/12/15 13:59, David Herrmann wrote:
>>> I looked into all this when working on WFD, but I cannot recommend
>>> going down that road. First of all, y
On 08/12/15 13:59, David Herrmann wrote:
> Hi
>
> On Fri, Dec 4, 2015 at 9:07 AM, Daniel Vetter wrote:
>> On Thu, Dec 03, 2015 at 07:26:31PM +0200, Martin Peres wrote:
>>> You are right Ilia, this is indeed what Jaakko and I had in mind, but they
>>> did not re-
On 04/12/15 19:49, Rob Herring wrote:
> I'm working on getting Android working with DRM drivers. ATM, I'm
> using virtio-gpu as the driver and trying to get just KMS side working
> without rendering. I have it working with stock AOSP and the emulated
> fb with a few additions to the virtio-gpu driv
On 04/12/15 10:07, Daniel Vetter wrote:
>
> Hm for virtual devices like this I figured there's no point exporting the
> full kms api to userspace, but instead we'd just need a simple kms driver
> with just 1 crtc and 1 connector per drm_device.
Yes, we do not need anything more. But don't forget t
On 03/12/15 18:38, Ilia Mirkin wrote:
> On Thu, Dec 3, 2015 at 11:10 AM, Laurent Pinchart
> wrote:
>> Hi Ilia,
>>
>> On Thursday 03 December 2015 11:03:28 Ilia Mirkin wrote:
>>> On Thu, Dec 3, 2015 at 10:53 AM, Laurent Pinchart wrote:
On Thursday 03 December 2015 10:42:50 Ilia Mirkin wrote:
>
Hello everyone,
We are 1.5 months away from XDC and 20 days away from the proposals
deadline[1]!
If you did not manage to secure funding from your company but still
think you could benefit the community by giving a talk, we encourage you
to send an email to the board of X.Org with your talk pr
On 20/01/15 22:49, Ian Romanick wrote:
> On 01/19/2015 03:00 AM, Chris Wilson wrote:
>> Since the introduction of DRI2GetBuffersWithFormat, the old
>> DRI2GetBuffers interface would always recreate all buffers all the time
>> as it was no longer agnostic to the format value being set by the DDXes.
st swap buffers count instead, we
>> introduce the has-buffer-age parameter.
>>
>> Signed-off-by: Chris Wilson
> Reviewed-by: Ian Romanick
>
Reviewed-by: Martin Peres
On 26/05/2015 16:23, Alexandre Courbot wrote:
> On Sun, May 24, 2015 at 3:26 PM, Maarten Lankhorst
> wrote:
>> Op 23-05-15 om 08:45 schreef Alexandre Courbot:
>>> On Fri, May 22, 2015 at 3:23 AM, Martin Peres
>>> wrote:
>>>> On 21/05/2015 11:47, Ben S
On 21/05/2015 11:47, Ben Skeggs wrote:
> On 21 May 2015 at 16:08, Alexandre Courbot wrote:
>> Add a flag allowing Nouveau to specify that an object should be coherent
>> at allocation time. This is required for some class of objects like
>> fences which are randomly-accessed by both the CPU and GP
On 20/05/15 08:11, Alexandre Courbot wrote:
> On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst
> wrote:
>> Op 15-05-15 om 09:11 schreef Alexandre Courbot:
>>> Re-pinging Marteen on an email address that still exists :P
>>>
>>> On Wed, Apr 22, 2015 at 6:08 PM, Alexandre Courbot
>>> wrote:
On 13/04/2015 02:42, Alex Deucher wrote:
> On Sat, Apr 11, 2015 at 5:52 AM, Martin Peres wrote:
>> On 05/02/2015 11:49, Christian König wrote:
>>> Am 04.02.2015 um 23:27 schrieb Alex Deucher:
>>>> 0-255 seems to be the preferred range for the pwm interface.
>>
On 05/02/2015 11:49, Christian König wrote:
> Am 04.02.2015 um 23:27 schrieb Alex Deucher:
>> 0-255 seems to be the preferred range for the pwm interface.
>>
>> Signed-off-by: Alex Deucher
> Yeah, using 100 on a 8bit pwm timer sounds rather obviously wrong.
>
> Patch is Reviewed-by: Christian Kö
way, come back to us when you have selected some areas and then we
can see if someone is interested to mentor those parts.
>
> Thanks,
> Stefan Lance
>
>
> Hi Stefan,
>
> I came across to contact to Martin Peres the last two days, I asked
> him about the project
wever
would still advice you to show your interest by providing patches or
participating to our discussions.
Finally, I would like to thank Google again this year for giving us the
opportunity to get new blood to the projects under the X.Org
Foundation's umbrella!
Martin Peres, on behalf of th
Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR.
Cc: Ville Syrjälä
Signed--off-by: Martin Peres
---
drivers/gpu/drm/drm_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0e47df4..f5a5f18
Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR.
CC: Daniel Vetter
Signed-off-by: Martin Peres
---
drivers/gpu/drm/drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4a44f89..90ad762
Le 02/05/2014 00:52, Martin Peres a ?crit :
> Hello,
>
> I have the pleasure to announce that the X.org Developer Conference 2014
> will
> be held in Bordeaux, France from October 8th to October 10th. The venue is
> located in the campus of the University of Bordeaux 1, in the
as possible and do so no later
than September 5th!
Thanks,
Martin Peres - On behalf of the board of directors
On 11/07/2014 03:42, Alexandre Courbot wrote:
> On 07/10/2014 06:50 PM, Mikko Perttunen wrote:
>> Does GK20A itself have any kind of thermal protection capabilities?
>> Upstream SOCTHERM support is not yet available (though I have a driver
>> in my tree), so we are thinking of disabling CPU DVFS on
Le 23/06/2014 19:56, Ilia Mirkin a ?crit :
> On Mon, Jun 23, 2014 at 1:46 PM, Martin Peres wrote:
>> Le 23/06/2014 18:40, Ilia Mirkin a ?crit :
>>>
>>> On Mon, Jun 23, 2014 at 12:36 PM, Greg KH wrote:
>>>>
>>>> On Mon, Jun 23, 2014 at 12:18:
Le 23/06/2014 18:40, Ilia Mirkin a ?crit :
> On Mon, Jun 23, 2014 at 12:36 PM, Greg KH wrote:
>> On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
>> A list of valid "values" that a file can be in is fine if you just then
>> write one value back to that file. That's the one exception,
st to
make badges and plan for the catering.
I am looking forward to seeing you there, if you have any
inquiries/questions,
please send them to me (please also CC: board at foundation.x.org).
Martin Peres
On 14/04/2014 15:09, Rob Clark wrote:
> On Mon, Apr 14, 2014 at 8:56 AM, Thomas Hellstrom
> wrote:
>> On 04/14/2014 02:41 PM, One Thousand Gnomes wrote:
throw out all GPU memory on master drop and block ioctls requiring
authentication until master becomes active again.
>>> If you have a
Le 13/03/2014 14:38, Ilia Mirkin a ?crit :
> On Sun, Mar 9, 2014 at 10:51 AM, Marcin Slusarz
> wrote:
>> [ 326.168487] ==
>> [ 326.168491] [ INFO: possible circular locking dependency detected ]
>> [ 326.168496] 3.13.6 #1270 Not tainted
>> [
mentor yourself. You can also have a look at the summer of code
ideas wiki page[1] for interesting projects.
Looking forward to seeing which projects will happen for this 2014 edition!
Martin Peres
[1] http://www.x.org/wiki/SummerOfCodeIdeas/
[2] https://www.google-melange.com/gsoc/homepage
mentor yourself. You can also have a look at the summer of code
ideas wiki page[1] for interesting projects.
Looking forward to seeing which projects will happen for this 2014 edition!
Martin Peres
[1] http://www.x.org/wiki/SummerOfCodeIdeas/
[2] https://www.google-melange.com/gsoc/homepage
Hi, fellow graphics stack developers,
Now that FOSDEM is over, it is time to think about the
Google Summer of Code 2014!
If you would like to propose a project for the GSoC 2014, please
write your proposals at [1], before the 14th of February, in order
to increase our chances of being an accepted
, Martin Peres, Peter Hutterer and Stuart Kreitman.
They will continue to serve until their term ends in 2015. Current
directors whose term expires in 2014 are Matthias Hopf, Keith Packard,
Matt Dew, and Alex Deucher.
A director is expected to participate in the bi-weekly IRC meeting to
discuss
On 20/12/2013 10:55, Thomas Hellstrom wrote:
> On 12/20/2013 10:31 AM, Martin Peres wrote:
>> On 20/12/2013 07:57, Thomas Hellstrom wrote:
>>> So this is a potential issue that needs to be brought up sooner or
>>> later:
>>>
>>> Let's say a clien
On 20/12/2013 07:57, Thomas Hellstrom wrote:
> So this is a potential issue that needs to be brought up sooner or later:
>
> Let's say a client is authenticated by the current master.
> Then the master drops, and we have a new master (fast user switching for
> example).
>
> What's the status of the
Le 19/11/2013 16:04, Christian K?nig a ?crit :
> So I think the very first step should be to publish everything on the
> appropriate lists, and not try an approach like releasing the kernel
> code first and waiting for it to show up upstream and then try to
> release the userspace code build on
Le 04/09/2013 14:05, Daniel Vetter a écrit :
On Wed, Sep 04, 2013 at 12:24:27PM +0200, Martin Peres wrote:
Hi Christopher,
Le 04/09/2013 05:15, Christopher James Halse Rogers a écrit :
Each dma-buf has an associated size and it's reasonable for userspace
to want to know what it is.
Hi Christopher,
Le 04/09/2013 05:15, Christopher James Halse Rogers a écrit :
Each dma-buf has an associated size and it's reasonable for userspace
to want to know what it is.
Since userspace already has an fd, expose the size using the
size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
idio
On 25/08/2013 17:09, David Herrmann wrote:
> Hi
>
> On Fri, Aug 23, 2013 at 2:00 PM, Martin Peres wrote:
>> Le 23/08/2013 13:13, David Herrmann a ?crit :
>>
>>> Hi
>>>
>>> I reduced the vma access-management patches to a minimum. I now do fil
On 25/08/2013 17:09, David Herrmann wrote:
Hi
On Fri, Aug 23, 2013 at 2:00 PM, Martin Peres wrote:
Le 23/08/2013 13:13, David Herrmann a écrit :
Hi
I reduced the vma access-management patches to a minimum. I now do filp*
tracking in gem unconditionally and force drm_gem_mmap() to check
1 - 100 of 205 matches
Mail list logo
