Hi Laurent!
Thanks for the review:
On 27 March 2013 05:38, Laurent Pinchart
wrote:
> Hi Sumit,
>
> Thanks for the patch.
>
> On Monday 25 March 2013 16:50:46 Sumit Semwal wrote:
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>
>> Cc: Dave Airli
Op 26-03-13 21:29, Marcin Slusarz schreef:
> On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote:
>> Op 25-03-13 19:14, Marcin Slusarz schreef:
>>> On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
Fixes 100% cpu usage when the exit interrupt never got acked.
>>>
On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote:
> Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> and DU1 LVDS outputs will require information about the panels that will
> be connected to those outputs.
>
> Signed-off-by: Laurent Pinchart
> ---
> arc
On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote:
> Op 25-03-13 19:14, Marcin Slusarz schreef:
> > On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
> >> Fixes 100% cpu usage when the exit interrupt never got acked.
> >>
> >> Signed-off-by: Maarten Lankhorst
> >>
Hi,
the patch bellow fixes a nullptr dereference reported with OpenSUSE12.3.
I am not familiar with the area so I have no idea whether this is the
right way to go but after applying this patch the problem is not
reproducible anymore.
If the patch is correct then please mark it for stable (3.7+).
T
DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve
more power savings when DISPC is configured in Smart Standby mode. This
mechanism leads to underflows when multiple DISPC pipes are enabled.
There is a register field which can let us revert to the older mechanism of
as
When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we
need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This
is needed because the stride for the UV plane(using a 16 bit Tiler container) is
double the stride for the Y plane(using a 8 bit Tiler co
Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the
DSI PLL Fint range, this was previously just copied from the
Each version of OMAP has a limitation on the maximum pixel clock frequency
supported by an overlay manager. This limit isn't checked by omapdss. Add
dispc feats for lcd and tv managers and check whether the target timings can
be supported or not.
The pixel clock limitations are actually more compl
The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
yet, we require some muxing at the DS
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following
The omapdrm driver currently takes a config/module arg to figure out the number
of crtcs it needs to create. We could create as many crtcs as there are overlay
managers in the DSS hardware, but we don't do that because each crtc eats up
one DSS overlay, and that reduces the number of planes we can
modeset_init iterates through all the registered omapdss devices and has some
initial checks to see if the panel has a driver and the required driver ops for
it to be usable by omapdrm.
The function bails out from modeset_init if a panel doesn't meet the
requirements, and stops the registration of
These are misc fixes and improvements within omapdrm and omapdss. The fixes do
the
following:
- Make omapdrm smarter to choose the right overlay managers as it's crtcs. This
makes sure that omapdrm is functional for OMAP platforms with different
combinations of panels connected to it.
- Fix
Starting with fdb40a08 (drm: set dev_mapping before calling
drm_open_helper) inode and file mappings are set to old_mapping in the
error path. old_mapping can be NULL, however, which is handled by
initializing dev_mapping to default inode->i_data. old_mapping is left
intact though so the both inode
Hi,
Am 26.03.2013 18:02, schrieb Matthew Garrett:
> On Tue, Mar 26, 2013 at 12:48:44PM +0100, Danny Baumann wrote:
>> This patch makes the behaviour of the intel_backlight backlight device
>> consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
>> makes the panel content ba
Hi,
>> Thus far our assumption always was that the acpi backlight works better
>> than the intel native backlight. So everything only uses the intel
>> backlight if there's no other backlight driver by default.
>
> There are machines, such as the pnv netbook on my desk, on which
> intel_backlight
Hi,
> Thus far our assumption always was that the acpi backlight works better
> than the intel native backlight. So everything only uses the intel
> backlight if there's no other backlight driver by default.
>
> So if I should merge this as a general solution for Windows 8 machines not
> working p
On Tue, Mar 26, 2013 at 06:10:30PM +0100, Danny Baumann wrote:
> Am 26.03.2013 18:02, schrieb Matthew Garrett:
> >I'm not quite clear what you mean here. The behaviour of "0" isn't well
> >defined for the ACPI backlight driver - it's perfectly reasonable for it
> >to turn the backlight off entirely
Hi Sumit,
Thanks for the patch.
On Monday 25 March 2013 16:50:46 Sumit Semwal wrote:
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
> Cc: Dave Airlie
> [minor fixes on init and warning fix]
> Signed-off-by: Sumit Semwal
> ---
> changes since
On Tue, Mar 26, 2013 at 12:48:44PM +0100, Danny Baumann wrote:
> This patch makes the behaviour of the intel_backlight backlight device
> consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
> makes the panel content barely readable instead of turning the backlight off.
> Th
On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb wrote:
> Since 2514bc510d0c3aadcc5204056bb440fa36845147, the intel_dp_mode_fixup
> function prefers lane count over frequency. That causes problems on
> hardware that has less working lanes than it reports. This option allows
> to workaround such hardwar
On Tue, Mar 26, 2013 at 12:48:45PM +0100, Danny Baumann wrote:
> When controlling backlight devices via sysfs interface, user space
> generally assumes the minimum level (0) still providing a brightness
> that is usable by the user (probably due to the most commonly used
> backlight device, acpi_vi
On Tue, Mar 26, 2013 at 04:13:13PM +0100, Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 12:48:45PM +0100, Danny Baumann wrote:
> > When controlling backlight devices via sysfs interface, user space
> > generally assumes the minimum level (0) still providing a brightness
> > that is usable by the u
On Tuesday 26 March 2013 04:11 AM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Monday 25 March 2013 11:44:35 Archit Taneja wrote:
>> Hi Laurent,
>>
>> On Tuesday 19 March 2013 08:25 PM, Laurent Pinchart wrote:
>>> Extend the -P option to allow specifying the plane x and y offsets. The
>>> position
On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote:
> Op 25-03-13 19:14, Marcin Slusarz schreef:
> > On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
> >> Fixes 100% cpu usage when the exit interrupt never got acked.
> >>
> >> Signed-off-by: Maarten Lankhorst
> >>
Hi,
the patch bellow fixes a nullptr dereference reported with OpenSUSE12.3.
I am not familiar with the area so I have no idea whether this is the
right way to go but after applying this patch the problem is not
reproducible anymore.
If the patch is correct then please mark it for stable (3.7+).
T
When controlling backlight devices via sysfs interface, user space
generally assumes the minimum level (0) still providing a brightness
that is usable by the user (probably due to the most commonly used
backlight device, acpi_videoX, behaving exactly like that). This doesn't
match the current behav
This patch makes the behaviour of the intel_backlight backlight device
consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
makes the panel content barely readable instead of turning the backlight off.
This matches the expectations of user space (e.g. kde-workspace or the In
On Tue, Mar 19, 2013 at 11:24 PM, Lucas Kannebley Tavares
wrote:
> Added function to gather the speed cap for a device and return a mask to
> supported speeds. The function is divided into an interface and a weak
> implementation so that architecture-specific functions can be called.
>
> This is t
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130326/39e9b2cc/attachment.html>
On Tue, Mar 19, 2013 at 11:24 PM, Lucas Kannebley Tavares
wrote:
> Added function to gather the speed cap for a device and return a mask to
> supported speeds. The function is divided into an interface and a weak
> implementation so that architecture-specific functions can be called.
>
> This is t
Hi,
Thus far our assumption always was that the acpi backlight works better
than the intel native backlight. So everything only uses the intel
backlight if there's no other backlight driver by default.
So if I should merge this as a general solution for Windows 8 machines not
working properly,
Hi,
Am 26.03.2013 18:02, schrieb Matthew Garrett:
On Tue, Mar 26, 2013 at 12:48:44PM +0100, Danny Baumann wrote:
This patch makes the behaviour of the intel_backlight backlight device
consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
makes the panel content barely rea
Hi,
Thus far our assumption always was that the acpi backlight works better
than the intel native backlight. So everything only uses the intel
backlight if there's no other backlight driver by default.
There are machines, such as the pnv netbook on my desk, on which
intel_backlight does nothin
||
--
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/20130326/67babb30/attachment.html>
0_LLVM=0 has no problems.
--
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/20130326/fa2aa6b9/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130326/981af754/attachment-0001.html>
|--- |FIXED
--
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/20130326/01fd58cb/attachment.html>
On Tue, Mar 26, 2013 at 12:48:44PM +0100, Danny Baumann wrote:
> This patch makes the behaviour of the intel_backlight backlight device
> consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
> makes the panel content barely readable instead of turning the backlight off.
> Th
On Tue, Mar 26, 2013 at 06:10:30PM +0100, Danny Baumann wrote:
> Am 26.03.2013 18:02, schrieb Matthew Garrett:
> >I'm not quite clear what you mean here. The behaviour of "0" isn't well
> >defined for the ACPI backlight driver - it's perfectly reasonable for it
> >to turn the backlight off entirely
On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb wrote:
> Since 2514bc510d0c3aadcc5204056bb440fa36845147, the intel_dp_mode_fixup
> function prefers lane count over frequency. That causes problems on
> hardware that has less working lanes than it reports. This option allows
> to workaround such hardwar
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130326/f2ff7d1f/attachment.html>
On Tue, Mar 26, 2013 at 04:13:13PM +0100, Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 12:48:45PM +0100, Danny Baumann wrote:
> > When controlling backlight devices via sysfs interface, user space
> > generally assumes the minimum level (0) still providing a brightness
> > that is usable by the u
On Tue, Mar 26, 2013 at 12:48:45PM +0100, Danny Baumann wrote:
> When controlling backlight devices via sysfs interface, user space
> generally assumes the minimum level (0) still providing a brightness
> that is usable by the user (probably due to the most commonly used
> backlight device, acpi_vi
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130326/21c77b95/attachment.html>
When controlling backlight devices via sysfs interface, user space
generally assumes the minimum level (0) still providing a brightness
that is usable by the user (probably due to the most commonly used
backlight device, acpi_videoX, behaving exactly like that). This doesn't
match the current behav
This patch makes the behaviour of the intel_backlight backlight device
consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
makes the panel content barely readable instead of turning the backlight off.
This matches the expectations of user space (e.g. kde-workspace or the In
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130326/33926d3c/attachment.html>
Op 25-03-13 19:14, Marcin Slusarz schreef:
> On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
>> Fixes 100% cpu usage when the exit interrupt never got acked.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> diff --git a/drivers/gpu/drm/nouveau/core/core/falcon.c
>> b/drivers/gp
DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve
more power savings when DISPC is configured in Smart Standby mode. This
mechanism leads to underflows when multiple DISPC pipes are enabled.
There is a register field which can let us revert to the older mechanism of
as
When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we
need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This
is needed because the stride for the UV plane(using a 16 bit Tiler container) is
double the stride for the Y plane(using a 8 bit Tiler co
Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the
DSI PLL Fint range, this was previously just copied from the
Each version of OMAP has a limitation on the maximum pixel clock frequency
supported by an overlay manager. This limit isn't checked by omapdss. Add
dispc feats for lcd and tv managers and check whether the target timings can
be supported or not.
The pixel clock limitations are actually more compl
The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
yet, we require some muxing at the DS
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following
The omapdrm driver currently takes a config/module arg to figure out the number
of crtcs it needs to create. We could create as many crtcs as there are overlay
managers in the DSS hardware, but we don't do that because each crtc eats up
one DSS overlay, and that reduces the number of planes we can
modeset_init iterates through all the registered omapdss devices and has some
initial checks to see if the panel has a driver and the required driver ops for
it to be usable by omapdrm.
The function bails out from modeset_init if a panel doesn't meet the
requirements, and stops the registration of
These are misc fixes and improvements within omapdrm and omapdss. The fixes do
the
following:
- Make omapdrm smarter to choose the right overlay managers as it's crtcs. This
makes sure that omapdrm is functional for OMAP platforms with different
combinations of panels connected to it.
- Fix
https://bugs.freedesktop.org/show_bug.cgi?id=62756
--- Comment #1 from Michel Dänzer ---
(In reply to comment #1)
> I tried finding a working commit going back with mesa, but I get to a point
> where llvm renders nothing at all with anything using current llvm svn.
There have been incompatible c
https://bugs.freedesktop.org/show_bug.cgi?id=62756
Andy Furniss changed:
What|Removed |Added
Attachment #77043|text/plain |image/jpeg
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=62756
Priority: medium
Bug ID: 62756
Assignee: dri-devel@lists.freedesktop.org
Summary: Rendering errors on rv790 with llvm and unigine heaven
3.0
Severity: normal
Classificati
https://bugs.freedesktop.org/show_bug.cgi?id=8191
--- Comment #6 from markus gapp ---
I only can change the status to: assigned, resolved oder needinfo -- none of
them seems appropriate, but please feel free to change...
markus
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=62696
Christian König changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130326/c57944ef/attachment.html>
On Tuesday 26 March 2013 04:11 AM, Laurent Pinchart wrote:
Hi Archit,
On Monday 25 March 2013 11:44:35 Archit Taneja wrote:
Hi Laurent,
On Tuesday 19 March 2013 08:25 PM, Laurent Pinchart wrote:
Extend the -P option to allow specifying the plane x and y offsets. The
position is optional, if n
https://bugs.freedesktop.org/show_bug.cgi?id=62226
--- Comment #4 from Niels Ole Salscheider ---
This is still an issue for me.
I use an out-of-tree build for mesa (and build the shared llvm libraries with
cmake), though.
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=8174
--- Comment #2 from chemtech ---
Jaime,
Do you still experience this issue with newer soft ?
Please check the status of your issue.
Or close this bug.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=9379
--- Comment #21 from chemtech ---
Please check the status of your issue.
Or close this bug.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-deve
On Sun, 2013-03-24 at 12:56 +0100, Maarten Lankhorst wrote:
> Op 23-03-13 12:47, Peter Hurley schreef:
> > On Tue, 2013-03-19 at 11:13 -0400, Peter Hurley wrote:
> >> On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
> >> the user X session is coming up:
> > Perhaps I wasn't cl
On 25 March 2013 19:06, Rob Clark wrote:
> sorry, was offline for a while (moving), and missed the last email..
No problem :)
>
> I would guess that Tomi would send pull-req for tilcdc and omapdrm.
> Well I suppose I could do it if Tomi can't, although my
> pandas/beagles/beaglebones are not unpa
On 11 March 2013 15:38, Sachin Kamat wrote:
> Hi Rob,
>
> On 2 March 2013 20:40, Rob Clark wrote:
>> On Sat, Mar 2, 2013 at 5:23 AM, Sachin Kamat wrote:
>>> Instead of checking if num_encoders is zero, it is being assigned 0.
>>> Convert the assignment to a check.
>>>
>>> Signed-off-by: Sachin K
72 matches
Mail list logo
