(dropping stable at ... until we get the fix we can agree on)
While looking through that function (drm_crtc_helper_set_config) to
figure out what we really need to save and restore, I came across a
piece of code that you added in 25f397a4. The 'if (connector->dpms !=
DRM_MODE_DPMS_ON)' (line 719
On Tue, Oct 8, 2013 at 11:34 AM, Jean-Francois Moine wrote:
> On Tue, 8 Oct 2013 10:49:39 +0100
> Russell King - ARM Linux wrote:
>
>> On Tue, Oct 08, 2013 at 11:19:13AM +0200, Jean-Francois Moine wrote:
>> > The Cubox is an open platform, and I use it just like a desktop PC.
>> > When its requir
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/b9f720e9/attachment.html>
On Sun, Oct 6, 2013 at 6:10 PM, Russell King
wrote:
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/armada/Makefile |1 +
> drivers/gpu/drm/armada/armada_610.c | 49
> ++
> drivers/gpu/drm/armada/armada_crtc.c |1 +
> drivers/gpu/drm/armada/
On Mon, Oct 7, 2013 at 8:50 AM, Russell King - ARM Linux
wrote:
> On Mon, Oct 07, 2013 at 03:29:15PM +0300, Siarhei Siamashka wrote:
>> On Mon, 7 Oct 2013 11:32:50 +0100
>> Russell King - ARM Linux wrote:
>> > However, what you're suggesting is dangerous. What do you do when you're
>> > presente
On Thu, Oct 17, 2013 at 05:02:12PM +0200, Denis Carikli wrote:
> + if (imxpd->lcd_reg)
> + if (regulator_enable(imxpd->lcd_reg))
> + dev_err(imxpd->dev, "Failed to enable lcd
> regulator.\n");
> +
In staging the style is to use braces around multi-line indents
On Mon, 14 Oct 2013 22:45:09 +0400
Eugene Shatokhin wrote:
> Hi,
>
> There is an interesting TODO item on MmioTraceDeveloper page:
> "kprobes has a generic instruction decoding facility, use that instead of
> homebrewn (or KVM), and use emulation instead of page faulting"
>
> Actually, I have d
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ebbb50e..7dac943 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/dr
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4813ff1..b4b51d4 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@
Those structures are not used anywhere.
Signed-off-by: Damien Lespiau
---
include/drm/drmP.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c3b659a..1c502ff 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -997,2
Those functions are just reading data from those pointers.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_debugfs.c | 4 ++--
include/drm/drmP.h| 9 +
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_deb
> -Original Message-
> From: Sean Paul [mailto:seanpaul at chromium.org]
> Sent: Thursday, October 17, 2013 4:27 AM
> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
> Cc: airlied at linux.ie; tomasz.figa at gmail.com; marcheu at chromium.org;
> Sean
> Paul
> Subject: [PA
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicetree at vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: driverdev-devel at linuxdriverproject.org
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: Sascha Hauer
Cc: linux-arm-kernel at lists.i
Support the RGB666 format on the IPUv3 parallel display.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicetree at vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: driverdev-devel at linuxdriverproject.org
Cc: David Airlie
Cc: dri-devel at lists.freedes
This change is needed for making the eukrea-cpuimx51
QVGA display work.
Greg Kroah-Hartman
Cc: driverdev-devel at linuxdriverproject.org
Cc: Philipp Zabel
Cc: Sascha Hauer
Cc: linux-arm-kernel at lists.infradead.org
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: Eric B?nard
Sig
The comment on top of of_get_drm_display_mode says:
* This function is expensive and should only be used, if only one mode is to be
* read from DT. To get multiple modes start with of_get_display_timings and
* work with that instead.
Cc: Greg Kroah-Hartman
Cc: driverdev-devel at linuxdriverpro
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicetree at vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: driverdev-devel at linuxdriv
Without that fix, drivers using the drm_display_mode_from_videomode
function will not be able to get certain information because
some DISPLAY_FLAGS_* have no corresponding DRM_MODE_FLAG_*.
Cc: Greg Kroah-Hartman
Cc: driverdev-devel at linuxdriverproject.org
Cc: David Airlie
Cc: dri-devel at
In 3.12 I changed audio to be enabled by default,
but you still had to turn it on via xrandr. This
was confusing to users so change it to minic the
previous behavior:
- audio option is set to -1 (auto) by default which is
the current 3.12 behavior (audio is enabled but requires
xrandr to turn
It causes hangs on some asics.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=70439
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 5b72931
w locking is
managed for those APIs. Even if in practice both APIs are used by the
same driver, and the driver can manage the locking, that's not really a
valid requirement. It'd be almost the same as requiring that gpio API
cannot be called at the same time as i2c API.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/034cfbd6/attachment-0001.pgp>
issues.
It's just a thought. Even if there's need for a endpoint node, perhaps
the port node can be made optional.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/bed122fd/attachment-0001.pgp>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/5272b9c9/attachment.html>
is there.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/2ac17d35/attachment-0001.pgp>
he electrons flow :-) What we need to model is a connection
> between a display controller and a panel (possibly with a direction). What
> I'd
> like to do is to express that link in a way that can also express more
> complex
> pipeline topologies. I don't want to make it overly complex, I had hoped that
> my DT bindings proposal would be a good approach as it's both generic and
> still pretty simple.
I get that, and for what it's worth I do think that your proposal looks
simple enough and if it can solve any of the problem you're facing with
CDF, then that's great.
But I don't think we should force inclusion of these properties on every
panel, even if it doesn't use any of the graph functionality. Is there
any problem with making them optional?
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/20131017/c1a7e062/attachment.pgp>
chment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/d0388027/attachment-0001.pgp>
; > > > default one doesn't work. How about we provide a means to override the
> > > > mode encoded in the driver using one specified in the DT? That's
> > > > obviously a backwards-compatible change, so it could be added if or when
> > > > it
Em Sun, 29 Sep 2013 10:51:00 +0200
Lars-Peter Clausen escreveu:
> The 'driver' field of the i2c_client struct is redundant and is going to be
> removed. The results of the expressions 'client->driver.driver->field' and
> 'client->dev.driver->field' are identical, so replace all occurrences of the
Em Sun, 29 Sep 2013 10:51:01 +0200
Lars-Peter Clausen escreveu:
> The 'driver' field of the i2c_client struct is redundant and is going to be
> removed. The results of the expressions 'client->driver.driver->field' and
> 'client->dev.driver->field' are identical, so replace all occurrences of the
>
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Ben Hutchings
Horngren's Observation:
Among economists, the real world is often a special case.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/381036d4/attachment.pgp>
t be in the parent node.
panel {
remote = <&dc>;
common-video-property = ;
};
The above would imply one port and one endpoint. Would that work? If we
had a function like parse_endpoint(node), we could just point it to
either a real endpoint node, or to the device's nod
On 10/17/2013 10:18 AM, Tomi Valkeinen wrote:
> On 17/10/13 10:48, Andrzej Hajda wrote:
>
>> The main function of DSI is to transport pixels from one IP to another IP
>> and this function IMO should not be modeled by display entity.
>> "Power, clocks, etc" will be performed via control bus accordin
iver compatible with
> > > > something like "generic-panel", so that you could have:
> > > >
> > > > compatible = "foo,specific-panel", "generic-panel";
> > > >
> > > > and if there's no need for any power/gpio setup for your board, you
> > > > may skip adding "foo,specific-panel" support to the panel driver.
> > > > Later, somebody else may need to implement fine grained power/gpio
> > > > support for "foo,specific-panel", and it would just work.
> > > >
> > > > Maybe that would help us with the problem of adding support in the
> > > > driver for a hundred different simple panels each used only once on a
> > > > specific board.
> > >
> > > Sure, that all sounds like reasonable additions. All of the suggestions
> > > are even backwards-compatible and hence can be added when needed without
> > > breaking compatibility with existing users of the binding.
> >
> > What's wrong with moving the three hardcoded modes we already have in the
> > driver to DT before pushing this to mainline ?
>
> I think I've answered that in a different subthread.
Then I might not have understood your answer :-)
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/92a72d44/attachment.pgp>
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/3a8c2808/attachment.pgp>
t the right thing to do would be to use specific compatible values
> > > for individual panels, because that would allow us to encode the power
> > > sequencing within the driver. And when we already have the panel model
> > > encoded in the compatible value, we might just as
is
still the DSI _control_ler that _control_s the panel. There's no
electrical way that the panel can take possession of the bus. Well,
there's BTA, but even that happens under supervision of the DSI
controller.
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/20131017/395325d5/attachment-0001.pgp>
> -Original Message-
> From: Sean Paul [mailto:seanpaul at chromium.org]
> Sent: Thursday, October 17, 2013 5:40 AM
> To: dri-devel; InKi Dae
> Cc: Dave Airlie; Tomasz Figa; St?phane Marchesin; Sean Paul
> Subject: Re: [PATCH v2 26/26] drm/exynos: Consolidate suspend/resume in
> drm_drv
>
eed for any power/gpio setup for your board, you may
> > > skip adding "foo,specific-panel" support to the panel driver. Later,
> > > somebody else may need to implement fine grained power/gpio support for
> > > "foo,specific-panel", and it would just work.
> > >
> > > Maybe that would help us with the problem of adding support in the
> > > driver for a hundred different simple panels each used only once on a
> > > specific board.
> >
> > Sure, that all sounds like reasonable additions. All of the suggestions
> > are even backwards-compatible and hence can be added when needed without
> > breaking compatibility with existing users of the binding.
>
> What's wrong with moving the three hardcoded modes we already have in the
> driver to DT before pushing this to mainline ?
I think I've answered that in a different subthread.
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/20131017/63a1008f/attachment.pgp>
On Thu, Oct 17, 2013 at 12:34 PM, wrote:
> We're rather inconsistent in which error values we return to userspace
> on failure. I want to unify the behaviour a bit and consistently return
> ENOENT when mode object lookups fail. We already do that in a few places
> but in most places we just retur
<&dc>;
> common-video-property = ;
> };
>
> The above would imply one port and one endpoint. Would that work? If we
> had a function like parse_endpoint(node), we could just point it to
> either a real endpoint node, or to the device's node.
You reference the display controller here, not a specific display controller
output. Don't most display controllers have several outputs ?
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/2584b329/attachment.pgp>
seful to tweak the mode in case the
> > default one doesn't work. How about we provide a means to override the
> > mode encoded in the driver using one specified in the DT? That's
> > obviously a backwards-compatible change, so it could be added if or when
> > it becomes necessary.
>
> I share Tomi's point of view here. Your three panels use the same power
> sequence, so I believe we should have a generic panel compatible string that
> would use modes described in DT for the common case. Only if a panel required
> something more complex which can't (or which could, but won't for any reason)
> accurately be described in DT would you need to extend the driver.
I don't see the point quite frankly. You seem to be assuming that every
panel will only be used in a single board. However what you're proposing
will require the mode timings to be repeated in every board's DT file,
if the same panel is ever used on more than a single board.
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/20131017/24f979e8/attachment.pgp>
From: Ville Syrj?l?
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.
From: Ville Syrj?l?
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index fc
From: Ville Syrj?l?
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/radeon/r100.c| 2 +-
drivers/gpu/drm/radeon/r600_cs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gp
From: Ville Syrj?l?
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_displ
From: Ville Syrj?l?
Let's be a bit more consistent with our error values.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/gma500/psb_drv.c | 4 ++--
drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma5
From: Ville Syrj?l?
Return -ENOENT for framebuffers like we do for other mode objects that
can't be found.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/d
From: Ville Syrj?l?
We tend to return -EINVAL for everything. Let's try to help poor
userland developers a bit by at least returning -ENONET for missing
objects.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 32 ++--
1 file changed, 18 insertions(+),
We're rather inconsistent in which error values we return to userspace
on failure. I want to unify the behaviour a bit and consistently return
ENOENT when mode object lookups fail. We already do that in a few places
but in most places we just return EINVAL.
I made a separate patch for each affect
On Wed, Oct 16, 2013 at 08:12:35PM -0400, Pavel Roskin wrote:
> The amount of data wanted by the userspace caller is encoded in the
> ioctl number. Generic drm ioctls were ignoring it.
>
> As a result, Intel Xorg driver didn't work for i386 userspace on x86_64
> kernel on some systems. sizeof(st
k.
Maybe that would help us with the problem of adding support in the
driver for a hundred different simple panels each used only once on a
specific board.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/29c4dca6/attachment-0001.pgp>
anel";
> >
> > and if there's no need for any power/gpio setup for your board, you may
> > skip adding "foo,specific-panel" support to the panel driver. Later,
> > somebody else may need to implement fine grained power/gpio support for
> > "foo,specific-panel", and it would just work.
> >
> > Maybe that would help us with the problem of adding support in the
> > driver for a hundred different simple panels each used only once on a
> > specific board.
>
> Sure, that all sounds like reasonable additions. All of the suggestions
> are even backwards-compatible and hence can be added when needed without
> breaking compatibility with existing users of the binding.
What's wrong with moving the three hardcoded modes we already have in the
driver to DT before pushing this to mainline ?
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/9868ff44/attachment.pgp>
= "foo,specific-panel", "generic-panel";
>
> and if there's no need for any power/gpio setup for your board, you may
> skip adding "foo,specific-panel" support to the panel driver. Later,
> somebody else may need to implement fine grained power/gpio support for
nces were designed (and NAKed at the last minute), we all decided
> that the right thing to do would be to use specific compatible values
> for individual panels, because that would allow us to encode the power
> sequencing within the driver. And when we already have the panel model
> encoded in the compatible value, we might just as well encode the mode
> within the driver for that panel. Otherwise we'll have to keep adding
> the same mode timings for every board that uses the same panel.
>
> I do agree though that it might be useful to tweak the mode in case the
> default one doesn't work. How about we provide a means to override the
> mode encoded in the driver using one specified in the DT? That's
> obviously a backwards-compatible change, so it could be added if or when
> it becomes necessary.
I share Tomi's point of view here. Your three panels use the same power
sequence, so I believe we should have a generic panel compatible string that
would use modes described in DT for the common case. Only if a panel required
something more complex which can't (or which could, but won't for any reason)
accurately be described in DT would you need to extend the driver.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/ac2224f4/attachment.pgp>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/972c7238/attachment.html>
ct timing restrictions with video, my gut feeling is just that
all the extra complexity brought with separating the control to a
separate bus is not worth it.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/578545c6/attachment-0001.pgp>
On Thu, 17 Oct 2013 13:26:47 +0100
Chris Wilson wrote:
> On Wed, Oct 16, 2013 at 08:12:35PM -0400, Pavel Roskin wrote:
> > The amount of data wanted by the userspace caller is encoded in the
> > ioctl number. Generic drm ioctls were ignoring it.
> >
> > As a result, Intel Xorg driver didn't wor
> + .vtotal = 600 + 16 + 6 + 16,
> > + .vrefresh = 60,
> > +};
>
> Instead of hardcoding the modes in the driver, which would then require to be
> updated for every new simple panel model (and we know there are lots of
> them),
> why don't you specify the modes in the panel DT node ? The simple panel
> driver
> would then become much more generic. It would also allow board designers to
> tweak h/v sync timings depending on the system requirements.
Sigh... we keep second-guessing ourselves. Back at the time when power
sequences were designed (and NAKed at the last minute), we all decided
that the right thing to do would be to use specific compatible values
for individual panels, because that would allow us to encode the power
sequencing within the driver. And when we already have the panel model
encoded in the compatible value, we might just as well encode the mode
within the driver for that panel. Otherwise we'll have to keep adding
the same mode timings for every board that uses the same panel.
I do agree though that it might be useful to tweak the mode in case the
default one doesn't work. How about we provide a means to override the
mode encoded in the driver using one specified in the DT? That's
obviously a backwards-compatible change, so it could be added if or when
it becomes necessary.
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/20131017/45b2d0c3/attachment-0001.pgp>
On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Sean Paul [mailto:seanpaul at chromium.org]
>> Sent: Thursday, October 17, 2013 4:27 AM
>> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
>> Cc: airlied at linux.ie; tomasz.figa at gmail.co
On Thu, Oct 17, 2013 at 6:35 AM, wrote:
> From: Ville Syrj?l?
>
> We tend to return -EINVAL for everything. Let's try to help poor
> userland developers a bit by at least returning -ENONET for missing
> objects.
>
> Signed-off-by: Ville Syrj?l?
For the series:
Reviewed-by: Alex Deucher
> --
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/7d141452/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/c7718291/attachment.html>
ffects
only the HD4xxx line of cards.
--
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/20131017/b952b979/attachment.html>
Hi Tomi,
Sorry for delayed response.
On 10/11/2013 04:45 PM, Tomi Valkeinen wrote:
> On 11/10/13 17:16, Andrzej Hajda wrote:
>
>> Picture size, content and format is the same on input and on output of DSI.
>> The same bits which enters DSI appears on the output. Internally bits
>> order can
>> b
On Thu, Oct 17, 2013 at 1:35 AM, Ilija Hadzic wrote:
> Embedding a mutex inside drm_crtc structure evokes a
> subtle and rare corruption in drm_crtc_helper_set_config
> failure-recovery path.
>
> Namely, if drm_crtc_helper_set_config takes the
> path under 'fail:' label *and* some other process
>
> Can't we instead just copy the few things we need to restore back?
> This wholesale structure copying has rather tricky semantics and is
> bound to trick up someone else in the future. And indeed we seem to
> have a similar (but less catastrophic) thing going on with crtc->fb I
> think.
Sure, it
est Closed source "fglrx"
driver
--
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/20131017/5aae7495/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/030f34db/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/23d14605/attachment.html>
Resolution|--- |INVALID
--
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/20131017/b81e56ce/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131017/e19cbabc/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/32722de3/attachment.html>
72 matches
Mail list logo
