On Tue, Jan 22, 2013 at 06:27:24PM +0100, Mario Kleiner wrote:
> On 22.01.13 09:31, Terje Bergström wrote:
> >On 14.01.2013 18:06, Thierry Reding wrote:
> >>+static int tegra_dc_page_flip(struct drm_crtc *crtc, struct
> >>drm_framebuffer *fb,
> >>+ struct drm_pending_vblank
On Wed, Jan 23, 2013 at 10:02:20AM +0200, Terje Bergström wrote:
> On 22.01.2013 21:59, Mario Kleiner wrote:
> > The current swap scheduling is based on having an accurate software
> > vblank counter. Atm. that counter is maintained in software, incremented
> > during vblank irq. At irq off -> on
On Tue, Jan 22, 2013 at 06:37:39PM +0100, Mario Kleiner wrote:
> On 14.01.13 17:05, Thierry Reding wrote:
> >Implement support for the VBLANK IOCTL. Note that Tegra is somewhat
> >special in this case because it doesn't use the generic IRQ support
> >provided by the DRM core (DRIVER_HAVE_IRQ) but r
On 2013-02-08 16:54, Marcus Lorentzon wrote:
> On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
>> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>>
>>> When we do that we stop->setup->start during blanking. So our "DSS" is
>>> optimized to be able to do that without getting blocked. All DSI video
>>> m
On 02/11/2013 09:21 AM, Tomi Valkeinen wrote:
On 2013-02-08 16:54, Marcus Lorentzon wrote:
On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
On 2013-02-08 15:28, Marcus Lorentzon wrote:
When we do that we stop->setup->start during blanking. So our "DSS" is
optimized to be able to do that without
The intention here is to make the output of dmesg with full verbosity a
bit easier for a human to parse. This commit transforms:
[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc
Hi Patrik
Patrik Jakobsson wrote:
> The value of VCO_MIN comes from the Intel PRM for similar GPUs.
>
> Instead of changing VCO_MIN, could you try setting N_MIN=1, N_MAX=6 and
> M1_MAX=22? I'll test it on my own hardware tomorrow.
Thanks for your suggestion.
With "N_MIN=1, N_MAX=6 and M1_MAX=22
https://bugs.freedesktop.org/show_bug.cgi?id=49981
--- Comment #28 from Alex Deucher ---
Created attachment 74606
--> https://bugs.freedesktop.org/attachment.cgi?id=74606&action=edit
fix multi-head stability
This should fix stability problems with profiles and multi-head.
--
You are receivin
On 2013-02-11 11:31, Marcus Lorentzon wrote:
> Ok, so what about a compromise which I think would work for "both" HWs
> ... we allow the "configure" operation during video on, then each HW
> driver could decide if this means you have to stop or not to do the
> changes required. But then it is also
On 10.02.2013 22:44, Thierry Reding wrote:
> On Sun, Feb 10, 2013 at 04:42:53PM -0800, Terje Bergström wrote:
>> You're right about performance. We already saw quite a bad performance
>> hit with the current firewall, so we'll need to worry about performance
>> later.
>
> I guess the additional ov
On 11.02.2013 01:08, Thierry Reding wrote:
> Are the syncpoints incremented even if the VBLANK interrupts are turned
> off? If that's the case they could indeed be used as a hardware counter
> rather than the fake approach used right now.
>
> Maybe we should leave the code as it is right now and f
On Sat, Feb 2, 2013 at 12:05 AM, Laurent Pinchart
wrote:
>> Back to the original topic: should it not work to queue a page flip and
>> immediately exit(0) after that to test the cleanup code? I suppose if
>> that can be tested on all drivers we should have pretty good coverage.
>
> Maybe we need s
From: Jerome Glisse
When ever parsing cmd buffer supplied by userspace we need to use
radeon_get_ib_value rather than directly accessing the ib as the user
cmd might not yet be copied into the ib thus the parser might read
value that does not correspond to what user is sending and possibly
allowi
Hello Ben Skeggs,
The patch 496a73bbecb8: "drm/nv50/pm: use hwsq for engine reclocking
too" from Jan 24, 2012, leads to the following Smatch warning:
"drivers/gpu/drm/nouveau/nv50_pm.c:638 nv50_pm_clocks_pre()
warn: 'info->mmast' might be uninitialized"
[ This Smatch check isn't ready f
Hello,
Here's the second version of a small patch set that adds an argument to the
modetest command line to specify the driver name instead of using the builtin
list of drivers. This is particularly handy during development of new DRM/KMS
drivers.
Changes from v1:
- Use the module name specified
Those variables are declared in unistd.h, there's no need to redeclare
them here.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index c91bb9d..489918e 100644
--- a/tests/mod
The current mostly random sort order hinders code readability. Sort the
options alphabetically in the code, and by group in the help message.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 49 ++-
1 file changed, 27 insertions(+), 22 d
If the -M parameter is specific, modetest will use the requested device
name instead of trying its builtin list of device names.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff -
On Monday 11 February 2013 21:13:45 Laurent Pinchart wrote:
> If the -M parameter is specific, modetest will use the requested device
> name instead of trying its builtin list of device names.
>
> Signed-off-by: Laurent Pinchart
> ---
> tests/modetest/modetest.c | 41
Hi Jani,
On Friday 08 February 2013 15:15:50 Jani Nikula wrote:
> On Fri, 08 Feb 2013, Laurent Pinchart wrote:
> > If the -M parameter is specific, modetest will use the requested device
> > name instead of trying its builtin list of device names.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
On Mon, Feb 11, 2013 at 8:57 AM, wrote:
> From: Jerome Glisse
>
> When ever parsing cmd buffer supplied by userspace we need to use
> radeon_get_ib_value rather than directly accessing the ib as the user
> cmd might not yet be copied into the ib thus the parser might read
> value that does not c
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter wrote:
> It's only used internally for the sysrq and panic handlers provided by
> the drm fb helper implementation. Hence just inline it, kill the
> export and remove the confusing kerneldoc. Driver's are supposed to
> call drm_fb_helper_restore_fbde
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter wrote:
> ... it's required. Fix up exynos and the cma helper, and add a
> corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode.
>
> Note that tegra calls the fbdev cma helper restore function also from
> it's driver-load callback. Which is a bit
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter wrote:
> It doesn't even show up in any header files and only used iternally.
> Originally it was (ab)used to restore the fbcon on lastclose, but that
> died with
>
> commit e8e7a2b8ccfdae0d4cb6bd25824bbedcd42da316
> Author: Dave Airlie
> Date: Th
https://bugzilla.kernel.org/show_bug.cgi?id=53391
--- Comment #9 from Marcin Slusarz 2013-02-11
22:12:35 ---
Yes, please do it. I think it will fix all issues (both VGA and DVI setups will
work and output numbering will be correct).
--
Configure bugmail: https://bugzilla.kernel.org/userpr
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter wrote:
> Not called by anyone, and really, shouldn't be. Drivers are supposed
> either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event.
> Originally this was done differently, but is now consolidated in the
> helper functions and no longe
On Mon, Feb 11, 2013 at 2:15 PM, "David Müller (ELSOFT AG)"
wrote:
> Hi Patrik
>
> Patrik Jakobsson wrote:
>> The value of VCO_MIN comes from the Intel PRM for similar GPUs.
>>
>> Instead of changing VCO_MIN, could you try setting N_MIN=1, N_MAX=6 and
>> M1_MAX=22? I'll test it on my own hardware
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter wrote:
> While doing the modeset rework for drm/i915 I've noticed that the fb
> helper is very liberal with the semantics of the ->set_config
> interface:
> - It doesn't bother clearing stale modes (e.g. when unpluggint a
s/unpluggint/unplugging/
>
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter wrote:
> The idea behind calling down into the driver's ->fb_probe function on each
> hotplug seems to be able to reallocate the backing storage (if e.g. a screen
> with higher resolution gets added). But that requires quite a bit of work in
> the
>
While doing the modeset rework for drm/i915 I've noticed that the fb
helper is very liberal with the semantics of the ->set_config
interface:
- It doesn't bother clearing stale modes (e.g. when unplugging a
screen).
- It unconditionally sets the fb, even if no mode will be set on a
given crtc.
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter wrote:
> No need to check whether we've allocated a new fb since we're not
> always doing that. Also, we always need to register the fbdev and add
> it to the panic notifier.
hmm, how is this not leading to a register_framebuffer() on every hotplug
Spotted by Rob Clark.
Signed-off-by: Daniel Vetter
---
include/drm/drm_fb_helper.h |2 --
1 file changed, 2 deletions(-)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index a60311c..8ef4c63 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@
While doing the modeset rework for drm/i915 I've noticed that the fb
helper is very liberal with the semantics of the ->set_config
interface:
- It doesn't bother clearing stale modes (e.g. when unplugging a
screen).
- It unconditionally sets the fb, even if no mode will be set on a
given crtc.
On Tue, Feb 12, 2013 at 1:24 AM, Rob Clark wrote:
> On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter
> wrote:
>> No need to check whether we've allocated a new fb since we're not
>> always doing that. Also, we always need to register the fbdev and add
>> it to the panic notifier.
>
> hmm, how is
On Mon, Feb 11, 2013 at 7:25 PM, Daniel Vetter wrote:
> While doing the modeset rework for drm/i915 I've noticed that the fb
> helper is very liberal with the semantics of the ->set_config
> interface:
> - It doesn't bother clearing stale modes (e.g. when unplugging a
> screen).
> - It unconditi
On Mon, Feb 11, 2013 at 7:33 PM, Daniel Vetter wrote:
> On Tue, Feb 12, 2013 at 1:24 AM, Rob Clark wrote:
>> On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter
>> wrote:
>>> No need to check whether we've allocated a new fb since we're not
>>> always doing that. Also, we always need to register th
On Sun, Jan 27, 2013 at 11:41 AM, Daniel Vetter wrote:
> This should be done in the drivers for two reasons:
> - it gets in the way of fastboot efforts
> - it links the fb helpers with the crtc helpers instead of going
> through the real interface vfuncs, forcing i915 to fake all the
> ->disab
https://bugs.freedesktop.org/show_bug.cgi?id=60200
Laurent carlier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=44341
Christopher Frömmel changed:
What|Removed |Added
Kernel Version|3.7.5 |3.7.7
--- Comment #10 from Chri
Smatch anlysis:
drivers/gpu/drm/radeon/atom.c:1242 atom_index_iio() error: potential null
dereference 'ctx->iio'. (kzalloc returns null)
Also cleaned up some checks before calls to kfree(). kfree(NULL) is OK.
Cc: David Airlie
Cc: Alex Deucher
Cc: "Michel Dänzer"
Cc: Dave Airlie
Cc: "Christ
radeon_i2c_destroy on a NULL pointer is a no-op.
Signed-off-by: Cyril Roelandt
---
drivers/gpu/drm/radeon/radeon_i2c.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
b/drivers/gpu/drm/radeon/radeon_i2c.c
index fc60b74..850df44 10
On Mon, 11 Feb 2013, Laurent Pinchart wrote:
> On Monday 11 February 2013 21:13:45 Laurent Pinchart wrote:
>> If the -M parameter is specific, modetest will use the requested device
>> name instead of trying its builtin list of device names.
>>
>> Signed-off-by: Laurent Pinchart
>> ---
>> tests
register offsets seems a lot more
straightforward than a bitfield. In my opinion an array of offsets is a
lot more readable than a field of bits. Especially since you can't just
setup a bitfield easily with initialized values.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130211/adcd2a5f/attachment.pgp>
dc->event = event;
drm_vblank_get(drm, dc->pipe);
}
spin_unlock_irqrestore(&drm->event_lock, flags);
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130211/92bb6f44/attachment.pgp>
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130211/67b8d42d/attachment-0001.pgp>
hat
this should be implemented using the upcoming syncpoint support.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130211/957289c3/attachment.pgp>
ation.
Hotplug is not a use case we should aim to support for the CDF v1, but I
think we should strive not to prevent hotplug either. So if we can
design the API so that hotplug is possible, I say let's do that.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130211/d79bdc97/attachment.pgp>
On 02/11/2013 09:21 AM, Tomi Valkeinen wrote:
> On 2013-02-08 16:54, Marcus Lorentzon wrote:
>> On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
>>> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>>>
When we do that we stop->setup->start during blanking. So our "DSS" is
optimized to be able to
The intention here is to make the output of dmesg with full verbosity a
bit easier for a human to parse. This commit transforms:
[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc
Hi Patrik
Patrik Jakobsson wrote:
> The value of VCO_MIN comes from the Intel PRM for similar GPUs.
>
> Instead of changing VCO_MIN, could you try setting N_MIN=1, N_MAX=6 and
> M1_MAX=22? I'll test it on my own hardware tomorrow.
Thanks for your suggestion.
With "N_MIN=1, N_MAX=6 and M1_MAX=22
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/20130211/612831be/attachment.html>
, as I said, I also think we shouldn't aim for hotplug in the v1. But
we also shouldn't prevent it.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130211/94bbf725/attachment.pgp>
On 10.02.2013 22:44, Thierry Reding wrote:
> On Sun, Feb 10, 2013 at 04:42:53PM -0800, Terje Bergstr?m wrote:
>> You're right about performance. We already saw quite a bad performance
>> hit with the current firewall, so we'll need to worry about performance
>> later.
>
> I guess the additional ov
On 11.02.2013 01:08, Thierry Reding wrote:
> Are the syncpoints incremented even if the VBLANK interrupts are turned
> off? If that's the case they could indeed be used as a hardware counter
> rather than the fake approach used right now.
>
> Maybe we should leave the code as it is right now and f
On Sat, Feb 2, 2013 at 12:05 AM, Laurent Pinchart
wrote:
>> Back to the original topic: should it not work to queue a page flip and
>> immediately exit(0) after that to test the cleanup code? I suppose if
>> that can be tested on all drivers we should have pretty good coverage.
>
> Maybe we need s
From: Jerome Glisse
When ever parsing cmd buffer supplied by userspace we need to use
radeon_get_ib_value rather than directly accessing the ib as the user
cmd might not yet be copied into the ib thus the parser might read
value that does not correspond to what user is sending and possibly
allowi
Hello Ben Skeggs,
The patch 496a73bbecb8: "drm/nv50/pm: use hwsq for engine reclocking
too" from Jan 24, 2012, leads to the following Smatch warning:
"drivers/gpu/drm/nouveau/nv50_pm.c:638 nv50_pm_clocks_pre()
warn: 'info->mmast' might be uninitialized"
[ This Smatch check isn't ready f
Hello,
Here's the second version of a small patch set that adds an argument to the
modetest command line to specify the driver name instead of using the builtin
list of drivers. This is particularly handy during development of new DRM/KMS
drivers.
Changes from v1:
- Use the module name specified
Those variables are declared in unistd.h, there's no need to redeclare
them here.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index c91bb9d..489918e 100644
--- a/tests/mod
The current mostly random sort order hinders code readability. Sort the
options alphabetically in the code, and by group in the help message.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 49 ++-
1 file changed, 27 insertions(+), 22 d
If the -M parameter is specific, modetest will use the requested device
name instead of trying its builtin list of device names.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff -
On Monday 11 February 2013 21:13:45 Laurent Pinchart wrote:
> If the -M parameter is specific, modetest will use the requested device
> name instead of trying its builtin list of device names.
>
> Signed-off-by: Laurent Pinchart
> ---
> tests/modetest/modetest.c | 41
Hi Jani,
On Friday 08 February 2013 15:15:50 Jani Nikula wrote:
> On Fri, 08 Feb 2013, Laurent Pinchart wrote:
> > If the -M parameter is specific, modetest will use the requested device
> > name instead of trying its builtin list of device names.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
On Mon, Feb 11, 2013 at 8:57 AM, wrote:
> From: Jerome Glisse
>
> When ever parsing cmd buffer supplied by userspace we need to use
> radeon_get_ib_value rather than directly accessing the ib as the user
> cmd might not yet be copied into the ib thus the parser might read
> value that does not c
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter
wrote:
> It's only used internally for the sysrq and panic handlers provided by
> the drm fb helper implementation. Hence just inline it, kill the
> export and remove the confusing kerneldoc. Driver's are supposed to
> call drm_fb_helper_restore_fbd
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter
wrote:
> ... it's required. Fix up exynos and the cma helper, and add a
> corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode.
>
> Note that tegra calls the fbdev cma helper restore function also from
> it's driver-load callback. Which is a bi
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter
wrote:
> It doesn't even show up in any header files and only used iternally.
> Originally it was (ab)used to restore the fbcon on lastclose, but that
> died with
>
> commit e8e7a2b8ccfdae0d4cb6bd25824bbedcd42da316
> Author: Dave Airlie
> Date: T
https://bugzilla.kernel.org/show_bug.cgi?id=53391
--- Comment #9 from Marcin Slusarz 2013-02-11
22:12:35 ---
Yes, please do it. I think it will fix all issues (both VGA and DVI setups will
work and output numbering will be correct).
--
Configure bugmail: https://bugzilla.kernel.org/userpr
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter
wrote:
> Not called by anyone, and really, shouldn't be. Drivers are supposed
> either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event.
> Originally this was done differently, but is now consolidated in the
> helper functions and no long
On Mon, Feb 11, 2013 at 2:15 PM, "David M?ller (ELSOFT AG)"
wrote:
> Hi Patrik
>
> Patrik Jakobsson wrote:
>> The value of VCO_MIN comes from the Intel PRM for similar GPUs.
>>
>> Instead of changing VCO_MIN, could you try setting N_MIN=1, N_MAX=6 and
>> M1_MAX=22? I'll test it on my own hardware
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter
wrote:
> While doing the modeset rework for drm/i915 I've noticed that the fb
> helper is very liberal with the semantics of the ->set_config
> interface:
> - It doesn't bother clearing stale modes (e.g. when unpluggint a
s/unpluggint/unplugging/
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter
wrote:
> The idea behind calling down into the driver's ->fb_probe function on each
> hotplug seems to be able to reallocate the backing storage (if e.g. a screen
> with higher resolution gets added). But that requires quite a bit of work in
> the
On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter
wrote:
> No need to check whether we've allocated a new fb since we're not
> always doing that. Also, we always need to register the fbdev and add
> it to the panic notifier.
hmm, how is this not leading to a register_framebuffer() on every hotplug
On Mon, Feb 11, 2013 at 7:25 PM, Daniel Vetter
wrote:
> While doing the modeset rework for drm/i915 I've noticed that the fb
> helper is very liberal with the semantics of the ->set_config
> interface:
> - It doesn't bother clearing stale modes (e.g. when unplugging a
> screen).
> - It uncondit
On Mon, Feb 11, 2013 at 7:33 PM, Daniel Vetter
wrote:
> On Tue, Feb 12, 2013 at 1:24 AM, Rob Clark wrote:
>> On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter
>> wrote:
>>> No need to check whether we've allocated a new fb since we're not
>>> always doing that. Also, we always need to register t
On Sun, Jan 27, 2013 at 11:41 AM, Daniel Vetter
wrote:
> This should be done in the drivers for two reasons:
> - it gets in the way of fastboot efforts
> - it links the fb helpers with the crtc helpers instead of going
> through the real interface vfuncs, forcing i915 to fake all the
> ->disa
Smatch anlysis:
drivers/gpu/drm/radeon/atom.c:1242 atom_index_iio() error: potential null
dereference 'ctx->iio'. (kzalloc returns null)
Also cleaned up some checks before calls to kfree(). kfree(NULL) is OK.
Cc: David Airlie
Cc: Alex Deucher
Cc: "Michel D?nzer"
Cc: Dave Airlie
Cc: "Christ
77 matches
Mail list logo
