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
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
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
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
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
> > ---
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
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
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
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 -
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
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
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
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
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 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 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
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 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
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
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/
https://bugs.freedesktop.org/show_bug.cgi?id=60200
Laurent carlier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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 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 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
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.
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
@
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
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 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:
> 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:
> 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 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
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'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:
> 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/
>
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
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
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
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
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:
> 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
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'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
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>
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
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
> > ---
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
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
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 -
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
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
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
, 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>
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
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
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
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>
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>
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130211/67b8d42d/attachment-0001.pgp>
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
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>
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
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>
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 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 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 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 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
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
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
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
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
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 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 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: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
77 matches
Mail list logo
