[PATCH 1/2] drm: fb: cma: Fix typo in debug message

[Thierry Reding]

The debug message showing the resolution of a framebuffer to be
allocated is missing a closing parenthesis.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 09e11a5..d6c80a3 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -206,7 +206,7 @@ static int drm_fbdev_cma_create(struct drm_fb_helper 
*helper,
size_t size;
int ret;

-   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
+   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
sizes->surface_width, sizes->surface_height,
sizes->surface_bpp);

-- 
1.7.12.4

[PATCH 2/2] drm: fb: cma: Fail gracefully on allocation failure

[Thierry Reding]

The drm_gem_cma_create() function never returns NULL but rather an error
encoded in the return value using the ERR_PTR() macro. Callers therefore
need to check for errors using the IS_ERR() macro. This change allows
drivers to handle contiguous DMA allocation failures gracefully.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index d6c80a3..fd9d0af 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -220,7 +220,7 @@ static int drm_fbdev_cma_create(struct drm_fb_helper 
*helper,

size = mode_cmd.pitches[0] * mode_cmd.height;
obj = drm_gem_cma_create(dev, size);
-   if (!obj)
+   if (IS_ERR(obj))
return -ENOMEM;

fbi = framebuffer_alloc(0, dev->dev);
-- 
1.7.12.4

[PATCH 2/2 v6] of: add generic videomode description

[Thierry Reding]

On Sun, Oct 07, 2012 at 03:38:33PM +0200, Laurent Pinchart wrote:
> Hi Steffen,
> 
> On Friday 05 October 2012 17:51:21 Steffen Trumtrar wrote:
> > On Thu, Oct 04, 2012 at 12:51:00PM -0600, Stephen Warren wrote:
> > > On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
> > > > Get videomode from devicetree in a format appropriate for the
> > > > backend. drm_display_mode and fb_videomode are supported atm.
> > > > Uses the display signal timings from of_display_timings
> > > > 
> > > > +++ b/drivers/of/of_videomode.c
> > > > 
> > > > +int videomode_from_timing(struct display_timings *disp, struct
> > > > videomode *vm,
> > > > 
> > > > +   st = display_timings_get(disp, index);
> > > > +
> > > > +   if (!st) {
> > > 
> > > It's a little odd to leave a blank line between those two lines.
> > 
> > Hm, well okay. That can be remedied
> > 
> > > Only half of the code in this file seems OF-related; the routines to
> > > convert a timing to a videomode or drm display mode seem like they'd be
> > > useful outside device tree, so I wonder if putting them into
> > > of_videomode.c is the correct thing to do. Still, it's probably not a
> > > big deal.
> > 
> > I am not sure, what the appropriate way to do this is. I can split it up
> > (again).
> 
> I think it would make sense to move them to their respective subsystems.

I agree. While looking at integrating this for Tegra DRM, I came across
the issue that if I build DRM as a module, linking with this code will
fail. The reason for that was that it was that the code, itself builtin,
uses drm_mode_set_name(), which would be exported by the drm module. So
I had to modifiy the Kconfig entries to be "def_tristate DRM". That
obviously isn't very nice since the code can also be used without DRM.

Moving the subsystem specific conversion routines to the respective
subsystems should solve any of these issues.

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/20121020/7d40d208/attachment.pgp>

[PATCH 2/2 v6] of: add generic videomode description

[Thierry Reding]

On Tue, Oct 09, 2012 at 09:26:08AM +0200, Steffen Trumtrar wrote:
> Hi Laurent,
> 
> On Mon, Oct 08, 2012 at 10:52:04PM +0200, Laurent Pinchart wrote:
> > Hi Steffen,
> > 
> > On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote:
> > > On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote:
> > > > On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote:
[...]
> > > > > +int of_get_videomode(struct device_node *np, struct videomode *vm, 
> > > > > int
> > > > > index)
> > > > 
> > > > I wonder how to avoid abuse of this functions. It's a useful helper for
> > > > drivers that need to get a video mode once only, but would result in 
> > > > lower
> > > > performances if a driver calls it for every mode. Drivers must call
> > > > of_get_display_timing_list instead in that case and case the display
> > > > timings. I'm wondering whether we should really expose of_get_videomode.
> > > 
> > > The intent was to let the driver decide. That way all the other overhead 
> > > may
> > > be skipped.
> > 
> > My point is that driver writers might just call of_get_videomode() in a 
> > loop, 
> > not knowing that it's expensive. I want to avoid that. We need to at least 
> > add 
> > kerneldoc to the function stating that this shouldn't be done.
> > 
> 
> You're right. That should be made clear in the code.

In that case we should export videomode_from_timing(). For Tegra DRM I
wrote a small utility function that takes a struct display_timings and
converts every timing to a struct videomode which is then converted to
a struct drm_display_mode and added to the DRM connector. The code is
really generic and could be part of the DRM core.

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/20121020/633e65d8/attachment.pgp>

[PATCH 1/2 v6] of: add helper to parse display timings

[Thierry Reding]

On Thu, Oct 04, 2012 at 07:59:19PM +0200, Steffen Trumtrar wrote:
[...]
> diff --git a/include/linux/of_display_timings.h 
> b/include/linux/of_display_timings.h
> new file mode 100644
> index 000..1ad719e
> --- /dev/null
> +++ b/include/linux/of_display_timings.h
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright 2012 Steffen Trumtrar 
> + *
> + * description of display timings
> + *
> + * This file is released under the GPLv2
> + */
> +
> +#ifndef __LINUX_OF_DISPLAY_TIMINGS_H
> +#define __LINUX_OF_DISPLAY_TIMINGS_H

This file needs to include linux/slab.h because it uses kfree() in the
inline functions. Alternatively I think I'd rather see the inline
functions moved out of the header, with the exception of the
signal_timing_get_value() function perhaps.

Moreover there should be a forward declaration of struct display_node
to avoid the need to include linux/of.h.

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/20121020/f80fa276/attachment.pgp>

[PATCH 2/2 v6] of: add generic videomode description

[Thierry Reding]

On Thu, Oct 04, 2012 at 07:59:20PM +0200, Steffen Trumtrar wrote:
[...]
> diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
[...]
> +#if defined(CONFIG_DRM)

This should be:

#if IS_ENABLED(CONFIG_DRM)

or the code below won't be included if DRM is built as a module. But see
my other replies as to how we can probably handle this better by moving
this into the DRM subsystem.

> +int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode 
> *dmode)
> +{
> + memset(dmode, 0, sizeof(*dmode));

It appears the usual method to obtain a drm_display_mode to allocate it
using drm_mode_create(), which will allocate it and associate it with
the struct drm_device.

Now, if you do a memset() on the structure you'll overwrite a number of
fields that have previously been initialized and are actually required
to get everything cleaned up properly later on.

So I think we should remove the call to memset().

> +int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
> + int index)
> +{
[...]
> +}
> +EXPORT_SYMBOL_GPL(of_get_drm_display_mode);

This should be:

EXPORT_SYMBOL_GPL(of_get_fb_videomode);

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/20121020/a2fcc215/attachment.pgp>

[PATCH 0/2 v6] of: add display helper

[Thierry Reding]

On Mon, Oct 15, 2012 at 04:17:51PM +0200, Steffen Trumtrar wrote:
> Hi Leela,
> 
> On Mon, Oct 15, 2012 at 04:24:43PM +0530, Leela Krishna Amudala wrote:
> > Hello Steffen,
> > 
> > To which version of the kernel we can expect this patch set to be merged 
> > into?
> > Because I'm waiting for this from long time to add DT support for my
> > display controller :)
> > 
> 
> I have no idea, sorry. It seems like we have almost settled with the binding
> (clock-name needs to be changed), but I'm not responsible for any 
> merging/inclusions
> in the kernel.

I want to use this in the Tegra DRM driver which I hope to get into 3.8.
If you need any help with this, please let me know.

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/20121020/4fe575ac/attachment-0001.pgp>

[RFC 0/5] Generic panel framework

[Inki Dae]

Hi Laurent. sorry for being late.

2012/8/17 Laurent Pinchart :
> Hi everybody,
>
> While working on DT bindings for the Renesas Mobile SoC display controller
> (a.k.a. LCDC) I quickly realized that display panel implementation based on
> board code callbacks would need to be replaced by a driver-based panel
> framework.
>
> Several driver-based panel support solution already exist in the kernel.
>
> - The LCD device class is implemented in drivers/video/backlight/lcd.c and
>   exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV
>   API for historical reason, uses board code callback for reset and power
>   management, and doesn't include support for standard features available in
>   today's "smart panels".
>
> - OMAP2+ based systems use custom panel drivers available in
>   drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display
>   controller) specific APIs.
>
> - Similarly, Exynos based systems use custom panel drivers available in
>   drivers/video/exynos. Only a single driver (s6e8ax0) is currently available.
>   That driver is based on Exynos display controller specific APIs and on the
>   LCD device class API.
>
> I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus
> Lorentzon (working on panel support for ST/Linaro), and we agreed that a
> generic panel framework for display devices is needed. These patches implement
> a first proof of concept.
>
> One of the main reasons for creating a new panel framework instead of adding
> missing features to the LCD framework is to avoid being tied to the FBDEV
> framework. Panels will be used by DRM drivers as well, and their API should
> thus be subsystem-agnostic. Note that the panel framework used the
> fb_videomode structure in its API, this will be replaced by a common video
> mode structure shared across subsystems (there's only so many hours per day).
>
> Panels, as used in these patches, are defined as physical devices combining a
> matrix of pixels and a controller capable of driving that matrix.
>
> Panel physical devices are registered as children of the control bus the panel
> controller is connected to (depending on the panel type, we can find platform
> devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ...
> devices). The generic panel framework matches registered panel devices with
> panel drivers and call the panel drivers probe method, as done by other device
> classes in the kernel. The driver probe() method is responsible for
> instantiating a struct panel instance and registering it with the generic
> panel framework.
>
> Display drivers are panel consumers. They register a panel notifier with the
> framework, which then calls the notifier when a matching panel is registered.
> The reason for this asynchronous mode of operation, compared to how drivers
> acquire regulator or clock resources, is that the panel can use resources
> provided by the display driver. For instance a panel can be a child of the DBI
> or DSI bus controlled by the display device, or use a clock provided by that
> device. We can't defer the display device probe until the panel is registered
> and also defer the panel device probe until the display is registered. As
> most display drivers need to handle output devices hotplug (HDMI monitors for
> instance), handling panel through a notification system seemed to be the
> easiest solution.
>
> Note that this brings a different issue after registration, as display and
> panel drivers would take a reference to each other. Those circular references
> would make driver unloading impossible. I haven't found a good solution for
> that problem yet (hence the RFC state of those patches), and I would
> appreciate your input here. This might also be a hint that the framework
> design is wrong to start with. I guess I can't get everything right on the
> first try ;-)
>
> Getting hold of the panel is the most complex part. Once done, display drivers
> can call abstract operations provided by panel drivers to control the panel
> operation. These patches implement three of those operations (enable, start
> transfer and get modes). More operations will be needed, and those three
> operations will likely get modified during review. Most of the panels on
> devices I own are dumb panels with no control bus, and are thus not the best
> candidates to design a framework that needs to take complex panels' needs into
> account.
>
> In addition to the generic panel core, I've implemented MIPI DBI (Display Bus
> Interface, a parallel bus for panels that supports read/write transfers of
> commands and data) bus support, as well as three panel drivers (dummy panels
> with no control bus, and Renesas R61505- and R61517-based panels, both using
> DBI as their control bus). Only the dummy panel driver has been tested as I
> lack hardware for the two other drivers.
>
> I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If
> you can find a clev

[Bug 44694] Crash in WebGL Path Tracing demo on Mesa 7.11 / Gallium 0.4 AMD RV710, in src_register called from translate_src

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=44694

--- Comment #4 from Andreas Boll  ---
Created attachment 68851
  --> https://bugs.freedesktop.org/attachment.cgi?id=68851&action=edit
R600_DUMP_SHADERS

I've attached R600_DUMP_SHADERS for the WebGL demo from:

http://madebyevan.com/webgl-path-tracing/

WebGL Renderer: X.Org -- Gallium 0.4 on AMD RV770 -- 2.1 Mesa 9.1-devel
(git-d2b0338)

-- 
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/20121020/56c1b5df/attachment.html>

[Bug 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49140

Andreas Boll  changed:

   What|Removed |Added

  Attachment #60568|application/octet-stream|text/plain
  mime type||

-- 
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/20121020/91d317b0/attachment.html>

[RFC 0/5] Generic panel framework

[Inki Dae]

Hi Tomi,

2012/8/17 Tomi Valkeinen :
> Hi,
>
> On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
>
>> I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If
>
> Oookay, where to start... ;)
>
> A few cosmetic/general comments first.
>
> I find the file naming a bit strange. You have panel.c, which is the
> core framework, panel-dbi.c, which is the DBI bus, panel-r61517.c, which
> is driver for r61517 panel...
>
> Perhaps something in this direction (in order): panel-core.c,
> mipi-dbi-bus.c, panel-r61517.c? And we probably end up with quite a lot
> of panel drivers, perhaps we should already divide these into separate
> directories, and then we wouldn't need to prefix each panel with
> "panel-" at all.
>
> ---
>
> Should we aim for DT only solution from the start? DT is the direction
> we are going, and I feel the older platform data stuff would be
> deprecated soon.
>
> ---
>
> Something missing from the intro is how this whole thing should be used.
> It doesn't help if we know how to turn on the panel, we also need to
> display something on it =). So I think some kind of diagram/example of
> how, say, drm would use this thing, and also how the SoC specific DBI
> bus driver would be done, would clarify things.
>
> ---
>
> We have discussed face to face about the different hardware setups and
> scenarios that we should support, but I'll list some of them here for
> others:
>
> 1) We need to support chains of external display chips and panels. A
> simple example is a chip that takes DSI in, and outputs DPI. In that
> case we'd have a chain of SoC -> DSI2DPI -> DPI panel.
>
> In final products I think two external devices is the maximum (at least
> I've never seen three devices in a row), but in theory and in
> development environments the chain can be arbitrarily long. Also the
> connections are not necessarily 1-to-1, but a device can take one input
> while it has two outputs, or a device can take two inputs.
>
> Now, I think two external devices is a must requirement. I'm not sure if
> supporting more is an important requirement. However, if we support two
> devices, it could be that it's trivial to change the framework to
> support n devices.
>
> 2) Panels and display chips are all but standard. They very often have
> their own sequences how to do things, have bugs, or implement some
> feature in slightly different way than some other panel. This is why the
> panel driver should be able to control or define the way things happen.
>
> As an example, Sharp LQ043T1DG01 panel
> (www.sharpsme.com/download/LQ043T1DG01-SP-072106pdf). It is enabled with
> the following sequence:
>
> - Enable VCC and AVDD regulators
> - Wait min 50ms
> - Enable full video stream (pck, syncs, pixels) from SoC
> - Wait min 0.5ms
> - Set DISP GPIO, which turns on the display panel
>
> Here we could split the enabling of panel to two parts, prepare (in this
> case starts regulators and waits 50ms) and finish (wait 0.5ms and set
> DISP GPIO), and the upper layer would start the video stream in between.
>
> I realize this could be done with the PANEL_ENABLE_* levels in your RFC,
> but I don't think the concepts quite match:
>
> - PANEL_ENABLE_BLANK level is needed for "smart panels", as we need to
> configure them and send the initial frame at that operating level. With

The smart panel means command mode way(same as cpu mode)? This panel
includes framebuffer internally and needs triggering from Display
controller to update a new frame on that internal framebuffer. I think
we also need this trigger interface.

Thanks,
Inki Dae


> dummy panels there's really no such level, there's just one enable
> sequence that is always done right away.
>
> - I find waiting at the beginning of a function very ugly (what are we
> waiting for?) and we'd need that when changing the panel to
> PANEL_ENABLE_ON level.
>
> - It's still limited if the panel is a stranger one (see following
> example).
>
> Consider the following theoretical panel enable example, taken to absurd
> level just to show the general problem:
>
> - Enable regulators
> - Enable video stream
> - Wait 50ms
> - Disable video stream
> - Set enable GPIO
> - Enable video stream
>
> This one would be rather impossible with the upper layer handling the
> enabling of the video stream. Thus I see that the panel driver needs to
> control the sequences, and the Sharp panel driver's enable would look
> something like:
>
> regulator_enable(...);
> sleep();
> dpi_enable_video();
> sleep();
> gpip_set(..);
>
> Note that even with this model we still need the PANEL_ENABLE levels you
> have.
>
> ---
>
> I'm not sure I understand the panel unload problem you mentioned. Nobody
> should have direct references to the panel functions, so there shouldn't
> be any automatic references that would prevent module unloading. So when
> the user does rmmod panel-mypanel, the panel driver's remove will be
> called. It'll unregister itself from the panel framework, which causes
> notifi

[RFC 0/5] Generic panel framework

[Inki Dae]

correct some typo. Sorry for this.

2012/10/20 Inki Dae :
> Hi Laurent. sorry for being late.
>
> 2012/8/17 Laurent Pinchart :
>> Hi everybody,
>>
>> While working on DT bindings for the Renesas Mobile SoC display controller
>> (a.k.a. LCDC) I quickly realized that display panel implementation based on
>> board code callbacks would need to be replaced by a driver-based panel
>> framework.
>>
>> Several driver-based panel support solution already exist in the kernel.
>>
>> - The LCD device class is implemented in drivers/video/backlight/lcd.c and
>>   exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV
>>   API for historical reason, uses board code callback for reset and power
>>   management, and doesn't include support for standard features available in
>>   today's "smart panels".
>>
>> - OMAP2+ based systems use custom panel drivers available in
>>   drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display
>>   controller) specific APIs.
>>
>> - Similarly, Exynos based systems use custom panel drivers available in
>>   drivers/video/exynos. Only a single driver (s6e8ax0) is currently 
>> available.
>>   That driver is based on Exynos display controller specific APIs and on the
>>   LCD device class API.
>>
>> I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and 
>> Marcus
>> Lorentzon (working on panel support for ST/Linaro), and we agreed that a
>> generic panel framework for display devices is needed. These patches 
>> implement
>> a first proof of concept.
>>
>> One of the main reasons for creating a new panel framework instead of adding
>> missing features to the LCD framework is to avoid being tied to the FBDEV
>> framework. Panels will be used by DRM drivers as well, and their API should
>> thus be subsystem-agnostic. Note that the panel framework used the
>> fb_videomode structure in its API, this will be replaced by a common video
>> mode structure shared across subsystems (there's only so many hours per day).
>>
>> Panels, as used in these patches, are defined as physical devices combining a
>> matrix of pixels and a controller capable of driving that matrix.
>>
>> Panel physical devices are registered as children of the control bus the 
>> panel
>> controller is connected to (depending on the panel type, we can find platform
>> devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ...
>> devices). The generic panel framework matches registered panel devices with
>> panel drivers and call the panel drivers probe method, as done by other 
>> device
>> classes in the kernel. The driver probe() method is responsible for
>> instantiating a struct panel instance and registering it with the generic
>> panel framework.
>>
>> Display drivers are panel consumers. They register a panel notifier with the
>> framework, which then calls the notifier when a matching panel is registered.
>> The reason for this asynchronous mode of operation, compared to how drivers
>> acquire regulator or clock resources, is that the panel can use resources
>> provided by the display driver. For instance a panel can be a child of the 
>> DBI
>> or DSI bus controlled by the display device, or use a clock provided by that
>> device. We can't defer the display device probe until the panel is registered
>> and also defer the panel device probe until the display is registered. As
>> most display drivers need to handle output devices hotplug (HDMI monitors for
>> instance), handling panel through a notification system seemed to be the
>> easiest solution.
>>
>> Note that this brings a different issue after registration, as display and
>> panel drivers would take a reference to each other. Those circular references
>> would make driver unloading impossible. I haven't found a good solution for
>> that problem yet (hence the RFC state of those patches), and I would
>> appreciate your input here. This might also be a hint that the framework
>> design is wrong to start with. I guess I can't get everything right on the
>> first try ;-)
>>
>> Getting hold of the panel is the most complex part. Once done, display 
>> drivers
>> can call abstract operations provided by panel drivers to control the panel
>> operation. These patches implement three of those operations (enable, start
>> transfer and get modes). More operations will be needed, and those three
>> operations will likely get modified during review. Most of the panels on
>> devices I own are dumb panels with no control bus, and are thus not the best
>> candidates to design a framework that needs to take complex panels' needs 
>> into
>> account.
>>
>> In addition to the generic panel core, I've implemented MIPI DBI (Display Bus
>> Interface, a parallel bus for panels that supports read/write transfers of
>> commands and data) bus support, as well as three panel drivers (dummy panels
>> with no control bus, and Renesas R61505- and R61517-based panels, both using
>> DBI as their control bus). Only the dummy p

[PATCH 0/3] drm/exynos: add iommu support for -next

[Inki Dae]

Hi all,

This patch set adds iommu support for exynos drm framework
and also relevant drivers, fimd and hdmi.

Exynos4xxx SoC and later have some iommu hardware units for
video codec, Camera, Post Processer(FIMC and GScaler), FIMD, HDMI,
Graphics 2D and so on. In other words, each device has its own
iommu hardware unit. So each device could have its own device
address space.

But in case of using DRM GEM and DMA Mapping API as allocator,
there is one issue. the issue is that we can't know which device
a gem buffer should be allocated for. So this patch set will use
unified device address space. Simply saying, exynos drm-based
all devices of using iommu have same device address space.

For example, if user process requested gem allocation, exynos drm
gem framework allocates desired physical memory region and maps it
with unified iommu mapping table through DMA Mapping API call,
dma_allc_attrs function. 

And this patch set is based on the following patch, "DMA-mapping &
IOMMU - physically contiguous allocations" Marek posted before as RFC.
For this, you can refer to below link,
  http://www.serverphorums.com/read.php?12,581741

As you know, RFC to the above patch is in progress so we have to wait
for the patch to be merged to mainline.

Thanks,
Inki Dae

Inki Dae (3):
  drm/exynos: add iommu support for exynos drm framework
  drm/exynos: add iommu support to fimd driver
  drm/exynos: add iommu support for hdmi driver

 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos_drm_buf.c|  88 +---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  87 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  23 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  11 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c |  52 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   9 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c| 210 +++--
 drivers/gpu/drm/exynos/exynos_drm_gem.h|   1 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c   |  15 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h   |   1 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.c  | 156 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.h  |  85 
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  21 +++
 15 files changed, 460 insertions(+), 306 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.h

-- 
1.8.0.rc3.16.g8ead1bf

[PATCH 1/3] drm/exynos: add iommu support for exynos drm framework

[Inki Dae]

This patch adds iommu support for exynos drm framework with dma mapping
api. In this patch, we used dma mapping api to allocate physical memory
and maps it with iommu table and removed some existing codes and added
new some codes for iommu support.

GEM allocation requires one device object to use dma mapping api so
this patch uses one iommu mapping for all sub drivers. In other words,
all sub drivers have same iommu mapping.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos_drm_buf.c|  88 +---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  87 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  23 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  11 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c |  52 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.c| 210 +++--
 drivers/gpu/drm/exynos/exynos_drm_gem.h|   1 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.c  | 156 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.h  |  85 
 11 files changed, 415 insertions(+), 305 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 59a26e5..f19320f 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -10,6 +10,12 @@ config DRM_EXYNOS
  Choose this option if you have a Samsung SoC EXYNOS chipset.
  If M is selected the module will be called exynosdrm.

+config DRM_EXYNOS_IOMMU
+   bool "EXYNOS DRM IOMMU Support"
+   depends on DRM_EXYNOS && EXYNOS_IOMMU
+   help
+ Choose this option if you want to use IOMMU feature for DRM.
+
 config DRM_EXYNOS_DMABUF
bool "EXYNOS DRM DMABUF"
depends on DRM_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index eb651ca..26813b8 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -8,6 +8,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o 
exynos_drm_connector.o \
exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
exynos_drm_plane.o

+exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 118c117..48c5896 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -33,71 +33,58 @@
 static int lowlevel_buffer_allocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
 {
-   dma_addr_t start_addr;
+   int ret = 0;
unsigned int npages, i = 0;
struct scatterlist *sgl;
-   int ret = 0;
+   enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;

DRM_DEBUG_KMS("%s\n", __FILE__);

-   if (IS_NONCONTIG_BUFFER(flags)) {
-   DRM_DEBUG_KMS("not support allocation type.\n");
-   return -EINVAL;
-   }
-
if (buf->dma_addr) {
DRM_DEBUG_KMS("already allocated.\n");
return 0;
}

-   if (buf->size >= SZ_1M) {
-   npages = buf->size >> SECTION_SHIFT;
-   buf->page_size = SECTION_SIZE;
-   } else if (buf->size >= SZ_64K) {
-   npages = buf->size >> 16;
-   buf->page_size = SZ_64K;
-   } else {
-   npages = buf->size >> PAGE_SHIFT;
-   buf->page_size = PAGE_SIZE;
+   init_dma_attrs(&buf->dma_attrs);
+
+   if (flags & EXYNOS_BO_NONCONTIG)
+   attr = DMA_ATTR_WRITE_COMBINE;
+
+   dma_set_attr(attr, &buf->dma_attrs);
+
+   buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
+   &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs);
+   if (!buf->kvaddr) {
+   DRM_ERROR("failed to allocate buffer.\n");
+   return -ENOMEM;
}

buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!buf->sgt) {
DRM_ERROR("failed to allocate sg table.\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err_free_attrs;
}

-   ret = sg_alloc_table(buf->sgt, npages, GFP_KERNEL);
+   ret = dma_get_sgtable(dev->dev, buf->sgt, buf->kvaddr, buf->dma_addr,
+   buf->size);
if (ret < 0) {
-   DRM_ERROR("failed to initialize sg table.\n");
-   kfree(buf->sgt);
-   buf->sgt = NULL;
-   return -ENOMEM;
+   DRM_ERROR("failed to get sgtable.\n");
+   

[PATCH 2/3] drm/exynos: add iommu support to fimd driver

[Inki Dae]

From: Inki Dae 

The iommu will be enabled when fimd sub driver is probed and
will be disabled when removed.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a328379..1f668ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -25,6 +25,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_crtc.h"
+#include "exynos_drm_iommu.h"

 /*
  * FIMD is stand for Fully Interactive Mobile Display and
@@ -709,6 +710,10 @@ static int fimd_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
 */
drm_dev->vblank_disable_allowed = 1;

+   /* attach this sub driver to iommu mapping if supported. */
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_attach_device(drm_dev, dev);
+
return 0;
 }

@@ -716,7 +721,9 @@ static void fimd_subdrv_remove(struct drm_device *drm_dev, 
struct device *dev)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);

-   /* TODO. */
+   /* detach this sub driver from iommu mapping if supported. */
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_detach_device(drm_dev, dev);
 }

 static int fimd_calc_clkdiv(struct fimd_context *ctx,
-- 
1.8.0.rc3.16.g8ead1bf

[PATCH 3/3] drm/exynos: add iommu support for hdmi driver

[Inki Dae]

From: Inki Dae 

The iommu will be enabled when hdmi sub driver is probed and
will be disabled when removed.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 15 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c | 21 +
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 0cb8a8c..997fb6e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -368,9 +368,23 @@ static int hdmi_subdrv_probe(struct drm_device *drm_dev,
ctx->hdmi_ctx->drm_dev = drm_dev;
ctx->mixer_ctx->drm_dev = drm_dev;

+   if (hdmi_ops->iommu_on)
+   hdmi_ops->iommu_on(ctx->hdmi_ctx->ctx, true);
+
return 0;
 }

+static void hdmi_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
+{
+   struct drm_hdmi_context *ctx;
+   struct exynos_drm_subdrv *subdrv = to_subdrv(dev);
+
+   ctx = get_ctx_from_subdrv(subdrv);
+
+   if (hdmi_ops->iommu_on)
+   hdmi_ops->iommu_on(ctx->hdmi_ctx->ctx, false);
+}
+
 static int __devinit exynos_drm_hdmi_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
@@ -390,6 +404,7 @@ static int __devinit exynos_drm_hdmi_probe(struct 
platform_device *pdev)
subdrv->dev = dev;
subdrv->manager = &hdmi_manager;
subdrv->probe = hdmi_subdrv_probe;
+   subdrv->remove = hdmi_subdrv_remove;

platform_set_drvdata(pdev, subdrv);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 2da5ffd..5c033d1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -50,6 +50,7 @@ struct exynos_hdmi_ops {
int (*power_on)(void *ctx, int mode);

/* manager */
+   int (*iommu_on)(void *ctx, bool enable);
void (*mode_fixup)(void *ctx, struct drm_connector *connector,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c115f8..d1a1d71 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -40,6 +40,7 @@

 #include "exynos_drm_drv.h"
 #include "exynos_drm_hdmi.h"
+#include "exynos_drm_iommu.h"

 #include "exynos_hdmi.h"

@@ -1946,6 +1947,25 @@ static void hdmi_conf_apply(struct hdmi_context *hdata)
hdmi_regs_dump(hdata, "start");
 }

+static int hdmi_iommu_on(void *ctx, bool enable)
+{
+   struct exynos_drm_hdmi_context *drm_hdmi_ctx;
+   struct hdmi_context *hdata = ctx;
+   struct drm_device *drm_dev;
+
+   drm_hdmi_ctx = hdata->parent_ctx;
+   drm_dev = drm_hdmi_ctx->drm_dev;
+
+   if (is_drm_iommu_supported(drm_dev)) {
+   if (enable)
+   return drm_iommu_attach_device(drm_dev, hdata->dev);
+
+   drm_iommu_detach_device(drm_dev, hdata->dev);
+   }
+
+   return 0;
+}
+
 static void hdmi_mode_fixup(void *ctx, struct drm_connector *connector,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -2102,6 +2122,7 @@ static struct exynos_hdmi_ops hdmi_ops = {
.check_timing   = hdmi_check_timing,

/* manager */
+   .iommu_on   = hdmi_iommu_on,
.mode_fixup = hdmi_mode_fixup,
.mode_set   = hdmi_mode_set,
.get_max_resol  = hdmi_get_max_resol,
-- 
1.8.0.rc3.16.g8ead1bf

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #45 from Serkan Hosca  ---

> Thats cool. I found out what triggers the gart error. I had gtk-redshift on
> session start up. After removing that the ttm error is gone. It redshifts
> the screen colors so that it is easy on the eyes and when its started it
> starts the redshifting gradually.
> 

Scratch that, i removed redshift but the gart error happened again. Its not the
gdm startup though, it happens during gnome session startup.

-- 
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/20121020/44a59c80/attachment.html>

[PATCH 1/2 v6] of: add helper to parse display timings

[Thierry Reding]

On Thu, Oct 04, 2012 at 07:59:19PM +0200, Steffen Trumtrar wrote:
[...]
> diff --git a/include/linux/of_display_timings.h 
> b/include/linux/of_display_timings.h
[...]
> +struct display_timings {
> + unsigned int num_timings;
> + unsigned int default_timing;
> +
> + struct signal_timing **timings;
> +};
> +
> +struct timing_entry {
> + u32 min;
> + u32 typ;
> + u32 max;
> +};
> +
> +struct signal_timing {

I'm slightly confused by the naming here. signal_timing seems overly
generic in this context. Is there any reason why this isn't called
display_timing or even display_mode?

-- 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/20121020/9a1cb37d/attachment.pgp>

Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Martin Peres wrote: 
> 
> > Can you test the attached patch too ? I rebased the previous one I sent on
> > top on 3.7-rc1 as I accidentally used an older version.
> 
> Yes, of course.
> 
> Tried it. Unfortunately, the crash remains the same as reported.

Try this one.

Now, the question is: could 3.6 kernel get VBIOS by ACPI?
If yes, please mount debugfs and send vbios.rom to me please.
(cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)

---
From: Marcin Slusarz 
Subject: [PATCH] drm/nouveau: validate vbios size

Without checking, we could detect vbios size as 0, allocate 0-byte array
(kmalloc returns invalid pointer for such allocation) and crash in
nouveau_bios_score while checking for vbios signature.

Reported-by: Heinz Diehl 
Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index dcb5c2b..824eea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
}

data = of_get_property(dn, "NVDA,BMP", &size);
-   if (data) {
+   if (data && size) {
bios->size = size;
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data)
@@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
goto out;

bios->size = nv_rd08(bios, 0x72) * 512;
+   if (!bios->size)
+   goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)

/* read entire bios image to system memory */
bios->size = nv_rd08(bios, 0x32) * 512;
+   if (!bios->size)
+   goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
bios->size = 0;
if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
bios->size = data[2] * 512;
+   if (!bios->size)
+   return;

bios->data = kmalloc(bios->size, GFP_KERNEL);
for (i = 0; bios->data && i < bios->size; i += cnt) {
@@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
 static int
 nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
 {
-   if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
+   if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
+   bios->data[1] != 0xAA) {
nv_info(bios, "... signature not found\n");
return 0;
}

-   if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
+   if (nvbios_checksum(bios->data,
+   min_t(u32, bios->data[2] * 512, bios->size))) {
nv_info(bios, "... checksum invalid\n");
/* if a ro image is somewhat bad, it's probably all rubbish */
return writeable ? 2 : 1;
-- 
1.7.12

Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 10:28:46PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Martin Peres wrote: 
> > 
> > > Can you test the attached patch too ? I rebased the previous one I sent on
> > > top on 3.7-rc1 as I accidentally used an older version.
> > 
> > Yes, of course.
> > 
> > Tried it. Unfortunately, the crash remains the same as reported.
> 
> Try this one.
> 
> Now, the question is: could 3.6 kernel get VBIOS by ACPI?
> If yes, please mount debugfs and send vbios.rom to me please.
> (cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)
> 
> ---
> From: Marcin Slusarz 
> Subject: [PATCH] drm/nouveau: validate vbios size
> 
> Without checking, we could detect vbios size as 0, allocate 0-byte array
> (kmalloc returns invalid pointer for such allocation) and crash in
> nouveau_bios_score while checking for vbios signature.
> 
> Reported-by: Heinz Diehl 

And of course:
Reported-by: Pawe? Sikora 

> Signed-off-by: Marcin Slusarz 
> ---
>  drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index dcb5c2b..824eea0 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
>   }
>  
>   data = of_get_property(dn, "NVDA,BMP", &size);
> - if (data) {
> + if (data && size) {
>   bios->size = size;
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   if (bios->data)
> @@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
>   goto out;
>  
>   bios->size = nv_rd08(bios, 0x72) * 512;
> + if (!bios->size)
> + goto out;
> +
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   if (bios->data) {
>   for (i = 0; i < bios->size; i++)
> @@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
>  
>   /* read entire bios image to system memory */
>   bios->size = nv_rd08(bios, 0x32) * 512;
> + if (!bios->size)
> + goto out;
> +
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   if (bios->data) {
>   for (i = 0; i < bios->size; i++)
> @@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
>   bios->size = 0;
>   if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
>   bios->size = data[2] * 512;
> + if (!bios->size)
> + return;
>  
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   for (i = 0; bios->data && i < bios->size; i += cnt) {
> @@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
>  static int
>  nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
>  {
> - if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
> + if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
> + bios->data[1] != 0xAA) {
>   nv_info(bios, "... signature not found\n");
>   return 0;
>   }
>  
> - if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
> + if (nvbios_checksum(bios->data,
> + min_t(u32, bios->data[2] * 512, bios->size))) {
>   nv_info(bios, "... checksum invalid\n");
>   /* if a ro image is somewhat bad, it's probably all rubbish */
>   return writeable ? 2 : 1;
> -- 

Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote: 
> 
> > Try this one.
> 
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
> 
> [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
> minor 0
> [3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
> [3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> [3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
> [3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
> [3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> [3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond 
> end of region [VROM] (length 24) (20120913/exfldio-210)
> [3.704139] ACPI Error: Method parse/execution 
> failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), 
> AE_AML_REGION_LIMIT (20120913/psparse-536)
> [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> [3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for image...
> [3.724111] nouveau :01:00.0: Invalid ROM contents
> [3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable image
> [3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 0x1001, 
> -22
> [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> [3.736097] nouveau: probe of :01:00.0 failed with error -22
> [3.740523] dracut: Starting plymouth daemon
> 
> And here's the same output with plain vanilla 3.6.2:
> 
> [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card 
> (0x0a8800b1)
> [3.599783] vga_switcheroo: enabled
> [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
> [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found
> [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS
> [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found
> [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS
> [3.856854] [drm] nouveau :01:00.0: ... appears to be valid
> [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI
> [3.861907] [drm] nouveau :01:00.0: BIT BIOS found
> [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00
> [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0
> [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
> [3.870871] [drm] nouveau :01:00.0: DCB version 4.0
> [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 
> [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040
> [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146
> [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261
> [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330
> [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400
> [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560
> [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running 
> VBIOS init tables.
> [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at 
> offset 0xDECD
> [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6
> [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at 
> offset 0xE378
> [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at 
> offset 0xEF4B
> [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at 
> offset 0xEF64
> [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at 
> offset 0xF04B
> [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 
> 0xF0B0
> [4.018084] [TTM] Zone  kernel: Available graphics memory: 1917766 kiB
> [4.019438] [TTM] Initializing pool allocator
> [4.020694] [TTM] Initializing DMA pool allocator
> [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3)
> [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
> [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [4.084909] [drm] No driver support for vblank timestamp query.
> [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface 
> available, not registering our own
> [4.246449] [drm] nouveau :01:00.0: 3 available performance level(s)
> [4.247560] [drm] nouveau :01:00.0: 0: core 135MHz shader 270MHz 
> memory 135MHz voltage 850mV
> [4.248707] [drm] nouveau :01:00.0: 1: core 405MHz shader

Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 11:42:17PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote: 
> > 
> > > Try this one.
> > 
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> > 
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
> > minor 0
> > [3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
> > [3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > [3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
> > [3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for 
> > image...
> > [3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> > [3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond 
> > end of region [VROM] (length 24) (20120913/exfldio-210)
> > [3.704139] ACPI Error: Method parse/execution 
> > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), 
> > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > [3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for 
> > image...
> > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > [3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable 
> > image
> > [3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 
> > 0x1001, -22
> > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > [3.740523] dracut: Starting plymouth daemon
> > 
> > And here's the same output with plain vanilla 3.6.2:
> > 
> > [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card 
> > (0x0a8800b1)
> > [3.599783] vga_switcheroo: enabled
> > [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
> > [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found
> > [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS
> > [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found
> > [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS
> > [3.856854] [drm] nouveau :01:00.0: ... appears to be valid
> > [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI
> > [3.861907] [drm] nouveau :01:00.0: BIT BIOS found
> > [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00
> > [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0
> > [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
> > [3.870871] [drm] nouveau :01:00.0: DCB version 4.0
> > [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 
> > [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040
> > [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146
> > [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261
> > [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330
> > [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400
> > [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560
> > [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running 
> > VBIOS init tables.
> > [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at 
> > offset 0xDECD
> > [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6
> > [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at 
> > offset 0xE378
> > [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at 
> > offset 0xEF4B
> > [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at 
> > offset 0xEF64
> > [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at 
> > offset 0xF04B
> > [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at 
> > offset 0xF0B0
> > [4.018084] [TTM] Zone  kernel: Available graphics memory: 1917766 kiB
> > [4.019438] [TTM] Initializing pool allocator
> > [4.020694] [TTM] Initializing DMA pool allocator
> > [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3)
> > [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
> > [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> > [4.084909] [drm] No driver support for vblank timestamp query.
> > [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface 
> > available, not registering our own
> > 

Linux 3.7-rc1 (nouveau_bios_score oops).

[Martin Peres]

On 10/19/12 23:25, Linus Torvalds wrote:
> Added more appropriate people to this. Added both i915 and nouveau
> people, since apparently that fine piece of hardware has both.
>
> Guys, any ideas?
>
> Pawe?, could you perhaps get a photo of the oops and post it
> somewhere? I'm assuming the oops happens early during boot and you
> never get a usable machine with dmesg - but if you do, then please do
> post the whole dmesg too.
>
>Linus
Hi Linus,

You must have missed the oops that was attached to the mail: 
http://www.spinics.net/lists/kernel/msg1420355.html

Pawe?, could you try the attached patch please ?

Martin

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121020/c01f0b70/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-nouveau-bios-improve-error-handling-when-reading.patch
Type: text/x-patch
Size: 1018 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121020/c01f0b70/attachment-0001.bin>

Linux 3.7-rc1 (nouveau_bios_score oops).

[Martin Peres]

On 20/10/2012 11:26, Heinz Diehl wrote:
> On 20.10.2012, Linus Torvalds wrote:
>
>> Added more appropriate people to this. Added both i915 and nouveau
>> people, since apparently that fine piece of hardware has both.
>>
>> Guys, any ideas?
>
> Plese see https://lkml.org/lkml/2012/10/19/371 , this is the same
> thing going on. Reverting
>
>   Ben Skeggs 
>   drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 64KiB
>
> fixes the problem.

Can you test the attached patch too ? I rebased the previous one I sent 
on top on 3.7-rc1 as I accidentally used an older version.

Martin
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-nouveau-bios-improve-error-handling-when-reading.patch
Type: text/x-patch
Size: 1024 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121020/633c1906/attachment-0001.bin>

Linux 3.7-rc1 (nouveau_bios_score oops).

[Heinz Diehl]

On 20.10.2012, Linus Torvalds wrote:

> Added more appropriate people to this. Added both i915 and nouveau
> people, since apparently that fine piece of hardware has both.
>
> Guys, any ideas?

Plese see https://lkml.org/lkml/2012/10/19/371 , this is the same
thing going on. Reverting

 Ben Skeggs 
 drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 64KiB

fixes the problem.

Linux 3.7-rc1 (nouveau_bios_score oops).

[Heinz Diehl]

On 20.10.2012, Martin Peres wrote: 

> Can you test the attached patch too ? I rebased the previous one I sent on
> top on 3.7-rc1 as I accidentally used an older version.

Yes, of course.

Tried it. Unfortunately, the crash remains the same as reported.

Linux 3.7-rc1 (nouveau_bios_score oops).

[Heinz Diehl]

On 20.10.2012, Marcin Slusarz wrote: 

> Try this one.

It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch on top of 3.7-rc1 is:

[3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
[3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
[3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
[3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
[3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
[3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end 
of region [VROM] (length 24) (20120913/exfldio-210)
[3.704139] ACPI Error: Method parse/execution 
failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), AE_AML_REGION_LIMIT 
(20120913/psparse-536)
[3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
[3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for image...
[3.724111] nouveau :01:00.0: Invalid ROM contents
[3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable image
[3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 0x1001, 
-22
[3.734231] nouveau E[ DRM] failed to create 0x8080, -22
[3.736097] nouveau: probe of :01:00.0 failed with error -22
[3.740523] dracut: Starting plymouth daemon

And here's the same output with plain vanilla 3.6.2:

[3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card 
(0x0a8800b1)
[3.599783] vga_switcheroo: enabled
[3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
[3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found
[3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS
[3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found
[3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS
[3.856854] [drm] nouveau :01:00.0: ... appears to be valid
[3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI
[3.861907] [drm] nouveau :01:00.0: BIT BIOS found
[3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00
[3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0
[3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
[3.870871] [drm] nouveau :01:00.0: DCB version 4.0
[3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 
[3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040
[3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146
[3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261
[3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330
[3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400
[3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560
[3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running 
VBIOS init tables.
[3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 
0xDECD
[3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6
[3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 
0xE378
[3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 
0xEF4B
[3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 
0xEF64
[3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 
0xF04B
[3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 
0xF0B0
[4.018084] [TTM] Zone  kernel: Available graphics memory: 1917766 kiB
[4.019438] [TTM] Initializing pool allocator
[4.020694] [TTM] Initializing DMA pool allocator
[4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3)
[4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
[4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[4.084909] [drm] No driver support for vblank timestamp query.
[4.085985] [drm] nouveau :01:00.0: ACPI backlight interface available, 
not registering our own
[4.246449] [drm] nouveau :01:00.0: 3 available performance level(s)
[4.247560] [drm] nouveau :01:00.0: 0: core 135MHz shader 270MHz memory 
135MHz voltage 850mV
[4.248707] [drm] nouveau :01:00.0: 1: core 405MHz shader 810MHz memory 
405MHz voltage 850mV
[4.249807] [drm] nouveau :01:00.0: 3: core 606MHz shader 1468MHz memory 
667MHz voltage 1000mV
[4.250946] [drm] nouveau :01:00.0: c: core 405MHz shader 810MHz memory 
405MHz
[4.

[PATCH 1/2] drm: fb: cma: Fix typo in debug message

[Thierry Reding]

The debug message showing the resolution of a framebuffer to be
allocated is missing a closing parenthesis.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 09e11a5..d6c80a3 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -206,7 +206,7 @@ static int drm_fbdev_cma_create(struct drm_fb_helper 
*helper,
size_t size;
int ret;
 
-   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
+   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
sizes->surface_width, sizes->surface_height,
sizes->surface_bpp);
 
-- 
1.7.12.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm: fb: cma: Fail gracefully on allocation failure

[Thierry Reding]

The drm_gem_cma_create() function never returns NULL but rather an error
encoded in the return value using the ERR_PTR() macro. Callers therefore
need to check for errors using the IS_ERR() macro. This change allows
drivers to handle contiguous DMA allocation failures gracefully.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index d6c80a3..fd9d0af 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -220,7 +220,7 @@ static int drm_fbdev_cma_create(struct drm_fb_helper 
*helper,
 
size = mode_cmd.pitches[0] * mode_cmd.height;
obj = drm_gem_cma_create(dev, size);
-   if (!obj)
+   if (IS_ERR(obj))
return -ENOMEM;
 
fbi = framebuffer_alloc(0, dev->dev);
-- 
1.7.12.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2 v6] of: add generic videomode description

[Thierry Reding]

On Sun, Oct 07, 2012 at 03:38:33PM +0200, Laurent Pinchart wrote:
> Hi Steffen,
> 
> On Friday 05 October 2012 17:51:21 Steffen Trumtrar wrote:
> > On Thu, Oct 04, 2012 at 12:51:00PM -0600, Stephen Warren wrote:
> > > On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
> > > > Get videomode from devicetree in a format appropriate for the
> > > > backend. drm_display_mode and fb_videomode are supported atm.
> > > > Uses the display signal timings from of_display_timings
> > > > 
> > > > +++ b/drivers/of/of_videomode.c
> > > > 
> > > > +int videomode_from_timing(struct display_timings *disp, struct
> > > > videomode *vm,
> > > > 
> > > > +   st = display_timings_get(disp, index);
> > > > +
> > > > +   if (!st) {
> > > 
> > > It's a little odd to leave a blank line between those two lines.
> > 
> > Hm, well okay. That can be remedied
> > 
> > > Only half of the code in this file seems OF-related; the routines to
> > > convert a timing to a videomode or drm display mode seem like they'd be
> > > useful outside device tree, so I wonder if putting them into
> > > of_videomode.c is the correct thing to do. Still, it's probably not a
> > > big deal.
> > 
> > I am not sure, what the appropriate way to do this is. I can split it up
> > (again).
> 
> I think it would make sense to move them to their respective subsystems.

I agree. While looking at integrating this for Tegra DRM, I came across
the issue that if I build DRM as a module, linking with this code will
fail. The reason for that was that it was that the code, itself builtin,
uses drm_mode_set_name(), which would be exported by the drm module. So
I had to modifiy the Kconfig entries to be "def_tristate DRM". That
obviously isn't very nice since the code can also be used without DRM.

Moving the subsystem specific conversion routines to the respective
subsystems should solve any of these issues.

Thierry


pgptSuZzA052R.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2 v6] of: add generic videomode description

[Thierry Reding]

On Tue, Oct 09, 2012 at 09:26:08AM +0200, Steffen Trumtrar wrote:
> Hi Laurent,
> 
> On Mon, Oct 08, 2012 at 10:52:04PM +0200, Laurent Pinchart wrote:
> > Hi Steffen,
> > 
> > On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote:
> > > On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote:
> > > > On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote:
[...]
> > > > > +int of_get_videomode(struct device_node *np, struct videomode *vm, 
> > > > > int
> > > > > index)
> > > > 
> > > > I wonder how to avoid abuse of this functions. It's a useful helper for
> > > > drivers that need to get a video mode once only, but would result in 
> > > > lower
> > > > performances if a driver calls it for every mode. Drivers must call
> > > > of_get_display_timing_list instead in that case and case the display
> > > > timings. I'm wondering whether we should really expose of_get_videomode.
> > > 
> > > The intent was to let the driver decide. That way all the other overhead 
> > > may
> > > be skipped.
> > 
> > My point is that driver writers might just call of_get_videomode() in a 
> > loop, 
> > not knowing that it's expensive. I want to avoid that. We need to at least 
> > add 
> > kerneldoc to the function stating that this shouldn't be done.
> > 
> 
> You're right. That should be made clear in the code.

In that case we should export videomode_from_timing(). For Tegra DRM I
wrote a small utility function that takes a struct display_timings and
converts every timing to a struct videomode which is then converted to
a struct drm_display_mode and added to the DRM connector. The code is
really generic and could be part of the DRM core.

Thierry


pgpaJWsrATopQ.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2 v6] of: add helper to parse display timings

[Thierry Reding]

On Thu, Oct 04, 2012 at 07:59:19PM +0200, Steffen Trumtrar wrote:
[...]
> diff --git a/include/linux/of_display_timings.h 
> b/include/linux/of_display_timings.h
> new file mode 100644
> index 000..1ad719e
> --- /dev/null
> +++ b/include/linux/of_display_timings.h
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright 2012 Steffen Trumtrar 
> + *
> + * description of display timings
> + *
> + * This file is released under the GPLv2
> + */
> +
> +#ifndef __LINUX_OF_DISPLAY_TIMINGS_H
> +#define __LINUX_OF_DISPLAY_TIMINGS_H

This file needs to include linux/slab.h because it uses kfree() in the
inline functions. Alternatively I think I'd rather see the inline
functions moved out of the header, with the exception of the
signal_timing_get_value() function perhaps.

Moreover there should be a forward declaration of struct display_node
to avoid the need to include linux/of.h.

Thierry


pgpUMIcIfNTqb.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2 v6] of: add generic videomode description

[Thierry Reding]

On Thu, Oct 04, 2012 at 07:59:20PM +0200, Steffen Trumtrar wrote:
[...]
> diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
[...]
> +#if defined(CONFIG_DRM)

This should be:

#if IS_ENABLED(CONFIG_DRM)

or the code below won't be included if DRM is built as a module. But see
my other replies as to how we can probably handle this better by moving
this into the DRM subsystem.

> +int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode 
> *dmode)
> +{
> + memset(dmode, 0, sizeof(*dmode));

It appears the usual method to obtain a drm_display_mode to allocate it
using drm_mode_create(), which will allocate it and associate it with
the struct drm_device.

Now, if you do a memset() on the structure you'll overwrite a number of
fields that have previously been initialized and are actually required
to get everything cleaned up properly later on.

So I think we should remove the call to memset().

> +int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
> + int index)
> +{
[...]
> +}
> +EXPORT_SYMBOL_GPL(of_get_drm_display_mode);

This should be:

EXPORT_SYMBOL_GPL(of_get_fb_videomode);

Thierry


pgpbnzWtFv0Wa.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2 v6] of: add display helper

[Thierry Reding]

On Mon, Oct 15, 2012 at 04:17:51PM +0200, Steffen Trumtrar wrote:
> Hi Leela,
> 
> On Mon, Oct 15, 2012 at 04:24:43PM +0530, Leela Krishna Amudala wrote:
> > Hello Steffen,
> > 
> > To which version of the kernel we can expect this patch set to be merged 
> > into?
> > Because I'm waiting for this from long time to add DT support for my
> > display controller :)
> > 
> 
> I have no idea, sorry. It seems like we have almost settled with the binding
> (clock-name needs to be changed), but I'm not responsible for any 
> merging/inclusions
> in the kernel.

I want to use this in the Tegra DRM driver which I hope to get into 3.8.
If you need any help with this, please let me know.

Thierry


pgp0SVxtlS6z6.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/5] Generic panel framework

[Inki Dae]

Hi Laurent. sorry for being late.

2012/8/17 Laurent Pinchart :
> Hi everybody,
>
> While working on DT bindings for the Renesas Mobile SoC display controller
> (a.k.a. LCDC) I quickly realized that display panel implementation based on
> board code callbacks would need to be replaced by a driver-based panel
> framework.
>
> Several driver-based panel support solution already exist in the kernel.
>
> - The LCD device class is implemented in drivers/video/backlight/lcd.c and
>   exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV
>   API for historical reason, uses board code callback for reset and power
>   management, and doesn't include support for standard features available in
>   today's "smart panels".
>
> - OMAP2+ based systems use custom panel drivers available in
>   drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display
>   controller) specific APIs.
>
> - Similarly, Exynos based systems use custom panel drivers available in
>   drivers/video/exynos. Only a single driver (s6e8ax0) is currently available.
>   That driver is based on Exynos display controller specific APIs and on the
>   LCD device class API.
>
> I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus
> Lorentzon (working on panel support for ST/Linaro), and we agreed that a
> generic panel framework for display devices is needed. These patches implement
> a first proof of concept.
>
> One of the main reasons for creating a new panel framework instead of adding
> missing features to the LCD framework is to avoid being tied to the FBDEV
> framework. Panels will be used by DRM drivers as well, and their API should
> thus be subsystem-agnostic. Note that the panel framework used the
> fb_videomode structure in its API, this will be replaced by a common video
> mode structure shared across subsystems (there's only so many hours per day).
>
> Panels, as used in these patches, are defined as physical devices combining a
> matrix of pixels and a controller capable of driving that matrix.
>
> Panel physical devices are registered as children of the control bus the panel
> controller is connected to (depending on the panel type, we can find platform
> devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ...
> devices). The generic panel framework matches registered panel devices with
> panel drivers and call the panel drivers probe method, as done by other device
> classes in the kernel. The driver probe() method is responsible for
> instantiating a struct panel instance and registering it with the generic
> panel framework.
>
> Display drivers are panel consumers. They register a panel notifier with the
> framework, which then calls the notifier when a matching panel is registered.
> The reason for this asynchronous mode of operation, compared to how drivers
> acquire regulator or clock resources, is that the panel can use resources
> provided by the display driver. For instance a panel can be a child of the DBI
> or DSI bus controlled by the display device, or use a clock provided by that
> device. We can't defer the display device probe until the panel is registered
> and also defer the panel device probe until the display is registered. As
> most display drivers need to handle output devices hotplug (HDMI monitors for
> instance), handling panel through a notification system seemed to be the
> easiest solution.
>
> Note that this brings a different issue after registration, as display and
> panel drivers would take a reference to each other. Those circular references
> would make driver unloading impossible. I haven't found a good solution for
> that problem yet (hence the RFC state of those patches), and I would
> appreciate your input here. This might also be a hint that the framework
> design is wrong to start with. I guess I can't get everything right on the
> first try ;-)
>
> Getting hold of the panel is the most complex part. Once done, display drivers
> can call abstract operations provided by panel drivers to control the panel
> operation. These patches implement three of those operations (enable, start
> transfer and get modes). More operations will be needed, and those three
> operations will likely get modified during review. Most of the panels on
> devices I own are dumb panels with no control bus, and are thus not the best
> candidates to design a framework that needs to take complex panels' needs into
> account.
>
> In addition to the generic panel core, I've implemented MIPI DBI (Display Bus
> Interface, a parallel bus for panels that supports read/write transfers of
> commands and data) bus support, as well as three panel drivers (dummy panels
> with no control bus, and Renesas R61505- and R61517-based panels, both using
> DBI as their control bus). Only the dummy panel driver has been tested as I
> lack hardware for the two other drivers.
>
> I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If
> you can find a clev

[Bug 44694] Crash in WebGL Path Tracing demo on Mesa 7.11 / Gallium 0.4 AMD RV710, in src_register called from translate_src

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=44694

--- Comment #4 from Andreas Boll  ---
Created attachment 68851
  --> https://bugs.freedesktop.org/attachment.cgi?id=68851&action=edit
R600_DUMP_SHADERS

I've attached R600_DUMP_SHADERS for the WebGL demo from:

http://madebyevan.com/webgl-path-tracing/

WebGL Renderer: X.Org -- Gallium 0.4 on AMD RV770 -- 2.1 Mesa 9.1-devel
(git-d2b0338)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49140] r600_state_common.c:761:r600_draw_vbo: Assertion `0' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=49140

Andreas Boll  changed:

   What|Removed |Added

  Attachment #60568|application/octet-stream|text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/5] Generic panel framework

[Inki Dae]

Hi Tomi,

2012/8/17 Tomi Valkeinen :
> Hi,
>
> On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
>
>> I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If
>
> Oookay, where to start... ;)
>
> A few cosmetic/general comments first.
>
> I find the file naming a bit strange. You have panel.c, which is the
> core framework, panel-dbi.c, which is the DBI bus, panel-r61517.c, which
> is driver for r61517 panel...
>
> Perhaps something in this direction (in order): panel-core.c,
> mipi-dbi-bus.c, panel-r61517.c? And we probably end up with quite a lot
> of panel drivers, perhaps we should already divide these into separate
> directories, and then we wouldn't need to prefix each panel with
> "panel-" at all.
>
> ---
>
> Should we aim for DT only solution from the start? DT is the direction
> we are going, and I feel the older platform data stuff would be
> deprecated soon.
>
> ---
>
> Something missing from the intro is how this whole thing should be used.
> It doesn't help if we know how to turn on the panel, we also need to
> display something on it =). So I think some kind of diagram/example of
> how, say, drm would use this thing, and also how the SoC specific DBI
> bus driver would be done, would clarify things.
>
> ---
>
> We have discussed face to face about the different hardware setups and
> scenarios that we should support, but I'll list some of them here for
> others:
>
> 1) We need to support chains of external display chips and panels. A
> simple example is a chip that takes DSI in, and outputs DPI. In that
> case we'd have a chain of SoC -> DSI2DPI -> DPI panel.
>
> In final products I think two external devices is the maximum (at least
> I've never seen three devices in a row), but in theory and in
> development environments the chain can be arbitrarily long. Also the
> connections are not necessarily 1-to-1, but a device can take one input
> while it has two outputs, or a device can take two inputs.
>
> Now, I think two external devices is a must requirement. I'm not sure if
> supporting more is an important requirement. However, if we support two
> devices, it could be that it's trivial to change the framework to
> support n devices.
>
> 2) Panels and display chips are all but standard. They very often have
> their own sequences how to do things, have bugs, or implement some
> feature in slightly different way than some other panel. This is why the
> panel driver should be able to control or define the way things happen.
>
> As an example, Sharp LQ043T1DG01 panel
> (www.sharpsme.com/download/LQ043T1DG01-SP-072106pdf). It is enabled with
> the following sequence:
>
> - Enable VCC and AVDD regulators
> - Wait min 50ms
> - Enable full video stream (pck, syncs, pixels) from SoC
> - Wait min 0.5ms
> - Set DISP GPIO, which turns on the display panel
>
> Here we could split the enabling of panel to two parts, prepare (in this
> case starts regulators and waits 50ms) and finish (wait 0.5ms and set
> DISP GPIO), and the upper layer would start the video stream in between.
>
> I realize this could be done with the PANEL_ENABLE_* levels in your RFC,
> but I don't think the concepts quite match:
>
> - PANEL_ENABLE_BLANK level is needed for "smart panels", as we need to
> configure them and send the initial frame at that operating level. With

The smart panel means command mode way(same as cpu mode)? This panel
includes framebuffer internally and needs triggering from Display
controller to update a new frame on that internal framebuffer. I think
we also need this trigger interface.

Thanks,
Inki Dae


> dummy panels there's really no such level, there's just one enable
> sequence that is always done right away.
>
> - I find waiting at the beginning of a function very ugly (what are we
> waiting for?) and we'd need that when changing the panel to
> PANEL_ENABLE_ON level.
>
> - It's still limited if the panel is a stranger one (see following
> example).
>
> Consider the following theoretical panel enable example, taken to absurd
> level just to show the general problem:
>
> - Enable regulators
> - Enable video stream
> - Wait 50ms
> - Disable video stream
> - Set enable GPIO
> - Enable video stream
>
> This one would be rather impossible with the upper layer handling the
> enabling of the video stream. Thus I see that the panel driver needs to
> control the sequences, and the Sharp panel driver's enable would look
> something like:
>
> regulator_enable(...);
> sleep();
> dpi_enable_video();
> sleep();
> gpip_set(..);
>
> Note that even with this model we still need the PANEL_ENABLE levels you
> have.
>
> ---
>
> I'm not sure I understand the panel unload problem you mentioned. Nobody
> should have direct references to the panel functions, so there shouldn't
> be any automatic references that would prevent module unloading. So when
> the user does rmmod panel-mypanel, the panel driver's remove will be
> called. It'll unregister itself from the panel framework, which causes
> notifi

Re: [RFC 0/5] Generic panel framework

[Inki Dae]

correct some typo. Sorry for this.

2012/10/20 Inki Dae :
> Hi Laurent. sorry for being late.
>
> 2012/8/17 Laurent Pinchart :
>> Hi everybody,
>>
>> While working on DT bindings for the Renesas Mobile SoC display controller
>> (a.k.a. LCDC) I quickly realized that display panel implementation based on
>> board code callbacks would need to be replaced by a driver-based panel
>> framework.
>>
>> Several driver-based panel support solution already exist in the kernel.
>>
>> - The LCD device class is implemented in drivers/video/backlight/lcd.c and
>>   exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV
>>   API for historical reason, uses board code callback for reset and power
>>   management, and doesn't include support for standard features available in
>>   today's "smart panels".
>>
>> - OMAP2+ based systems use custom panel drivers available in
>>   drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display
>>   controller) specific APIs.
>>
>> - Similarly, Exynos based systems use custom panel drivers available in
>>   drivers/video/exynos. Only a single driver (s6e8ax0) is currently 
>> available.
>>   That driver is based on Exynos display controller specific APIs and on the
>>   LCD device class API.
>>
>> I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and 
>> Marcus
>> Lorentzon (working on panel support for ST/Linaro), and we agreed that a
>> generic panel framework for display devices is needed. These patches 
>> implement
>> a first proof of concept.
>>
>> One of the main reasons for creating a new panel framework instead of adding
>> missing features to the LCD framework is to avoid being tied to the FBDEV
>> framework. Panels will be used by DRM drivers as well, and their API should
>> thus be subsystem-agnostic. Note that the panel framework used the
>> fb_videomode structure in its API, this will be replaced by a common video
>> mode structure shared across subsystems (there's only so many hours per day).
>>
>> Panels, as used in these patches, are defined as physical devices combining a
>> matrix of pixels and a controller capable of driving that matrix.
>>
>> Panel physical devices are registered as children of the control bus the 
>> panel
>> controller is connected to (depending on the panel type, we can find platform
>> devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ...
>> devices). The generic panel framework matches registered panel devices with
>> panel drivers and call the panel drivers probe method, as done by other 
>> device
>> classes in the kernel. The driver probe() method is responsible for
>> instantiating a struct panel instance and registering it with the generic
>> panel framework.
>>
>> Display drivers are panel consumers. They register a panel notifier with the
>> framework, which then calls the notifier when a matching panel is registered.
>> The reason for this asynchronous mode of operation, compared to how drivers
>> acquire regulator or clock resources, is that the panel can use resources
>> provided by the display driver. For instance a panel can be a child of the 
>> DBI
>> or DSI bus controlled by the display device, or use a clock provided by that
>> device. We can't defer the display device probe until the panel is registered
>> and also defer the panel device probe until the display is registered. As
>> most display drivers need to handle output devices hotplug (HDMI monitors for
>> instance), handling panel through a notification system seemed to be the
>> easiest solution.
>>
>> Note that this brings a different issue after registration, as display and
>> panel drivers would take a reference to each other. Those circular references
>> would make driver unloading impossible. I haven't found a good solution for
>> that problem yet (hence the RFC state of those patches), and I would
>> appreciate your input here. This might also be a hint that the framework
>> design is wrong to start with. I guess I can't get everything right on the
>> first try ;-)
>>
>> Getting hold of the panel is the most complex part. Once done, display 
>> drivers
>> can call abstract operations provided by panel drivers to control the panel
>> operation. These patches implement three of those operations (enable, start
>> transfer and get modes). More operations will be needed, and those three
>> operations will likely get modified during review. Most of the panels on
>> devices I own are dumb panels with no control bus, and are thus not the best
>> candidates to design a framework that needs to take complex panels' needs 
>> into
>> account.
>>
>> In addition to the generic panel core, I've implemented MIPI DBI (Display Bus
>> Interface, a parallel bus for panels that supports read/write transfers of
>> commands and data) bus support, as well as three panel drivers (dummy panels
>> with no control bus, and Renesas R61505- and R61517-based panels, both using
>> DBI as their control bus). Only the dummy p

[PATCH 0/3] drm/exynos: add iommu support for -next

[Inki Dae]

Hi all,

This patch set adds iommu support for exynos drm framework
and also relevant drivers, fimd and hdmi.

Exynos4xxx SoC and later have some iommu hardware units for
video codec, Camera, Post Processer(FIMC and GScaler), FIMD, HDMI,
Graphics 2D and so on. In other words, each device has its own
iommu hardware unit. So each device could have its own device
address space.

But in case of using DRM GEM and DMA Mapping API as allocator,
there is one issue. the issue is that we can't know which device
a gem buffer should be allocated for. So this patch set will use
unified device address space. Simply saying, exynos drm-based
all devices of using iommu have same device address space.

For example, if user process requested gem allocation, exynos drm
gem framework allocates desired physical memory region and maps it
with unified iommu mapping table through DMA Mapping API call,
dma_allc_attrs function. 

And this patch set is based on the following patch, "DMA-mapping &
IOMMU - physically contiguous allocations" Marek posted before as RFC.
For this, you can refer to below link,
  http://www.serverphorums.com/read.php?12,581741

As you know, RFC to the above patch is in progress so we have to wait
for the patch to be merged to mainline.

Thanks,
Inki Dae

Inki Dae (3):
  drm/exynos: add iommu support for exynos drm framework
  drm/exynos: add iommu support to fimd driver
  drm/exynos: add iommu support for hdmi driver

 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos_drm_buf.c|  88 +---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  87 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  23 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  11 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c |  52 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   9 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c| 210 +++--
 drivers/gpu/drm/exynos/exynos_drm_gem.h|   1 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c   |  15 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h   |   1 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.c  | 156 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.h  |  85 
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  21 +++
 15 files changed, 460 insertions(+), 306 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.h

-- 
1.8.0.rc3.16.g8ead1bf

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/exynos: add iommu support for exynos drm framework

[Inki Dae]

This patch adds iommu support for exynos drm framework with dma mapping
api. In this patch, we used dma mapping api to allocate physical memory
and maps it with iommu table and removed some existing codes and added
new some codes for iommu support.

GEM allocation requires one device object to use dma mapping api so
this patch uses one iommu mapping for all sub drivers. In other words,
all sub drivers have same iommu mapping.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos_drm_buf.c|  88 +---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  87 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  23 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  11 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c |  52 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.c| 210 +++--
 drivers/gpu/drm/exynos/exynos_drm_gem.h|   1 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.c  | 156 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.h  |  85 
 11 files changed, 415 insertions(+), 305 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 59a26e5..f19320f 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -10,6 +10,12 @@ config DRM_EXYNOS
  Choose this option if you have a Samsung SoC EXYNOS chipset.
  If M is selected the module will be called exynosdrm.
 
+config DRM_EXYNOS_IOMMU
+   bool "EXYNOS DRM IOMMU Support"
+   depends on DRM_EXYNOS && EXYNOS_IOMMU
+   help
+ Choose this option if you want to use IOMMU feature for DRM.
+
 config DRM_EXYNOS_DMABUF
bool "EXYNOS DRM DMABUF"
depends on DRM_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index eb651ca..26813b8 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -8,6 +8,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o 
exynos_drm_connector.o \
exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
exynos_drm_plane.o
 
+exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 118c117..48c5896 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -33,71 +33,58 @@
 static int lowlevel_buffer_allocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
 {
-   dma_addr_t start_addr;
+   int ret = 0;
unsigned int npages, i = 0;
struct scatterlist *sgl;
-   int ret = 0;
+   enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
-   if (IS_NONCONTIG_BUFFER(flags)) {
-   DRM_DEBUG_KMS("not support allocation type.\n");
-   return -EINVAL;
-   }
-
if (buf->dma_addr) {
DRM_DEBUG_KMS("already allocated.\n");
return 0;
}
 
-   if (buf->size >= SZ_1M) {
-   npages = buf->size >> SECTION_SHIFT;
-   buf->page_size = SECTION_SIZE;
-   } else if (buf->size >= SZ_64K) {
-   npages = buf->size >> 16;
-   buf->page_size = SZ_64K;
-   } else {
-   npages = buf->size >> PAGE_SHIFT;
-   buf->page_size = PAGE_SIZE;
+   init_dma_attrs(&buf->dma_attrs);
+
+   if (flags & EXYNOS_BO_NONCONTIG)
+   attr = DMA_ATTR_WRITE_COMBINE;
+
+   dma_set_attr(attr, &buf->dma_attrs);
+
+   buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
+   &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs);
+   if (!buf->kvaddr) {
+   DRM_ERROR("failed to allocate buffer.\n");
+   return -ENOMEM;
}
 
buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!buf->sgt) {
DRM_ERROR("failed to allocate sg table.\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err_free_attrs;
}
 
-   ret = sg_alloc_table(buf->sgt, npages, GFP_KERNEL);
+   ret = dma_get_sgtable(dev->dev, buf->sgt, buf->kvaddr, buf->dma_addr,
+   buf->size);
if (ret < 0) {
-   DRM_ERROR("failed to initialize sg table.\n");
-   kfree(buf->sgt);
-   buf->sgt = NULL;
-   return -ENOMEM;
+   DRM_ERROR("failed to get sgtable.\n");
+

[PATCH 2/3] drm/exynos: add iommu support to fimd driver

[Inki Dae]

From: Inki Dae 

The iommu will be enabled when fimd sub driver is probed and
will be disabled when removed.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a328379..1f668ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -25,6 +25,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_crtc.h"
+#include "exynos_drm_iommu.h"
 
 /*
  * FIMD is stand for Fully Interactive Mobile Display and
@@ -709,6 +710,10 @@ static int fimd_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
 */
drm_dev->vblank_disable_allowed = 1;
 
+   /* attach this sub driver to iommu mapping if supported. */
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_attach_device(drm_dev, dev);
+
return 0;
 }
 
@@ -716,7 +721,9 @@ static void fimd_subdrv_remove(struct drm_device *drm_dev, 
struct device *dev)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);
 
-   /* TODO. */
+   /* detach this sub driver from iommu mapping if supported. */
+   if (is_drm_iommu_supported(drm_dev))
+   drm_iommu_detach_device(drm_dev, dev);
 }
 
 static int fimd_calc_clkdiv(struct fimd_context *ctx,
-- 
1.8.0.rc3.16.g8ead1bf

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/exynos: add iommu support for hdmi driver

[Inki Dae]

From: Inki Dae 

The iommu will be enabled when hdmi sub driver is probed and
will be disabled when removed.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 15 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c | 21 +
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 0cb8a8c..997fb6e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -368,9 +368,23 @@ static int hdmi_subdrv_probe(struct drm_device *drm_dev,
ctx->hdmi_ctx->drm_dev = drm_dev;
ctx->mixer_ctx->drm_dev = drm_dev;
 
+   if (hdmi_ops->iommu_on)
+   hdmi_ops->iommu_on(ctx->hdmi_ctx->ctx, true);
+
return 0;
 }
 
+static void hdmi_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
+{
+   struct drm_hdmi_context *ctx;
+   struct exynos_drm_subdrv *subdrv = to_subdrv(dev);
+
+   ctx = get_ctx_from_subdrv(subdrv);
+
+   if (hdmi_ops->iommu_on)
+   hdmi_ops->iommu_on(ctx->hdmi_ctx->ctx, false);
+}
+
 static int __devinit exynos_drm_hdmi_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
@@ -390,6 +404,7 @@ static int __devinit exynos_drm_hdmi_probe(struct 
platform_device *pdev)
subdrv->dev = dev;
subdrv->manager = &hdmi_manager;
subdrv->probe = hdmi_subdrv_probe;
+   subdrv->remove = hdmi_subdrv_remove;
 
platform_set_drvdata(pdev, subdrv);
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 2da5ffd..5c033d1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -50,6 +50,7 @@ struct exynos_hdmi_ops {
int (*power_on)(void *ctx, int mode);
 
/* manager */
+   int (*iommu_on)(void *ctx, bool enable);
void (*mode_fixup)(void *ctx, struct drm_connector *connector,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c115f8..d1a1d71 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -40,6 +40,7 @@
 
 #include "exynos_drm_drv.h"
 #include "exynos_drm_hdmi.h"
+#include "exynos_drm_iommu.h"
 
 #include "exynos_hdmi.h"
 
@@ -1946,6 +1947,25 @@ static void hdmi_conf_apply(struct hdmi_context *hdata)
hdmi_regs_dump(hdata, "start");
 }
 
+static int hdmi_iommu_on(void *ctx, bool enable)
+{
+   struct exynos_drm_hdmi_context *drm_hdmi_ctx;
+   struct hdmi_context *hdata = ctx;
+   struct drm_device *drm_dev;
+
+   drm_hdmi_ctx = hdata->parent_ctx;
+   drm_dev = drm_hdmi_ctx->drm_dev;
+
+   if (is_drm_iommu_supported(drm_dev)) {
+   if (enable)
+   return drm_iommu_attach_device(drm_dev, hdata->dev);
+
+   drm_iommu_detach_device(drm_dev, hdata->dev);
+   }
+
+   return 0;
+}
+
 static void hdmi_mode_fixup(void *ctx, struct drm_connector *connector,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -2102,6 +2122,7 @@ static struct exynos_hdmi_ops hdmi_ops = {
.check_timing   = hdmi_check_timing,
 
/* manager */
+   .iommu_on   = hdmi_iommu_on,
.mode_fixup = hdmi_mode_fixup,
.mode_set   = hdmi_mode_set,
.get_max_resol  = hdmi_get_max_resol,
-- 
1.8.0.rc3.16.g8ead1bf

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #45 from Serkan Hosca  ---

> Thats cool. I found out what triggers the gart error. I had gtk-redshift on
> session start up. After removing that the ttm error is gone. It redshifts
> the screen colors so that it is easy on the eyes and when its started it
> starts the redshifting gradually.
> 

Scratch that, i removed redshift but the gart error happened again. Its not the
gdm startup though, it happens during gnome session startup.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2 v6] of: add helper to parse display timings

[Thierry Reding]

On Thu, Oct 04, 2012 at 07:59:19PM +0200, Steffen Trumtrar wrote:
[...]
> diff --git a/include/linux/of_display_timings.h 
> b/include/linux/of_display_timings.h
[...]
> +struct display_timings {
> + unsigned int num_timings;
> + unsigned int default_timing;
> +
> + struct signal_timing **timings;
> +};
> +
> +struct timing_entry {
> + u32 min;
> + u32 typ;
> + u32 max;
> +};
> +
> +struct signal_timing {

I'm slightly confused by the naming here. signal_timing seems overly
generic in this context. Is there any reason why this isn't called
display_timing or even display_mode?



pgpnJGqmge3M4.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Martin Peres wrote: 
> 
> > Can you test the attached patch too ? I rebased the previous one I sent on
> > top on 3.7-rc1 as I accidentally used an older version.
> 
> Yes, of course.
> 
> Tried it. Unfortunately, the crash remains the same as reported.

Try this one.

Now, the question is: could 3.6 kernel get VBIOS by ACPI?
If yes, please mount debugfs and send vbios.rom to me please.
(cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)

---
From: Marcin Slusarz 
Subject: [PATCH] drm/nouveau: validate vbios size

Without checking, we could detect vbios size as 0, allocate 0-byte array
(kmalloc returns invalid pointer for such allocation) and crash in
nouveau_bios_score while checking for vbios signature.

Reported-by: Heinz Diehl 
Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index dcb5c2b..824eea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
}
 
data = of_get_property(dn, "NVDA,BMP", &size);
-   if (data) {
+   if (data && size) {
bios->size = size;
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data)
@@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
goto out;
 
bios->size = nv_rd08(bios, 0x72) * 512;
+   if (!bios->size)
+   goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
 
/* read entire bios image to system memory */
bios->size = nv_rd08(bios, 0x32) * 512;
+   if (!bios->size)
+   goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
bios->size = 0;
if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
bios->size = data[2] * 512;
+   if (!bios->size)
+   return;
 
bios->data = kmalloc(bios->size, GFP_KERNEL);
for (i = 0; bios->data && i < bios->size; i += cnt) {
@@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
 static int
 nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
 {
-   if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
+   if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
+   bios->data[1] != 0xAA) {
nv_info(bios, "... signature not found\n");
return 0;
}
 
-   if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
+   if (nvbios_checksum(bios->data,
+   min_t(u32, bios->data[2] * 512, bios->size))) {
nv_info(bios, "... checksum invalid\n");
/* if a ro image is somewhat bad, it's probably all rubbish */
return writeable ? 2 : 1;
-- 
1.7.12

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 10:28:46PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Martin Peres wrote: 
> > 
> > > Can you test the attached patch too ? I rebased the previous one I sent on
> > > top on 3.7-rc1 as I accidentally used an older version.
> > 
> > Yes, of course.
> > 
> > Tried it. Unfortunately, the crash remains the same as reported.
> 
> Try this one.
> 
> Now, the question is: could 3.6 kernel get VBIOS by ACPI?
> If yes, please mount debugfs and send vbios.rom to me please.
> (cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)
> 
> ---
> From: Marcin Slusarz 
> Subject: [PATCH] drm/nouveau: validate vbios size
> 
> Without checking, we could detect vbios size as 0, allocate 0-byte array
> (kmalloc returns invalid pointer for such allocation) and crash in
> nouveau_bios_score while checking for vbios signature.
> 
> Reported-by: Heinz Diehl 

And of course:
Reported-by: Paweł Sikora 

> Signed-off-by: Marcin Slusarz 
> ---
>  drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index dcb5c2b..824eea0 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
>   }
>  
>   data = of_get_property(dn, "NVDA,BMP", &size);
> - if (data) {
> + if (data && size) {
>   bios->size = size;
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   if (bios->data)
> @@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
>   goto out;
>  
>   bios->size = nv_rd08(bios, 0x72) * 512;
> + if (!bios->size)
> + goto out;
> +
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   if (bios->data) {
>   for (i = 0; i < bios->size; i++)
> @@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
>  
>   /* read entire bios image to system memory */
>   bios->size = nv_rd08(bios, 0x32) * 512;
> + if (!bios->size)
> + goto out;
> +
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   if (bios->data) {
>   for (i = 0; i < bios->size; i++)
> @@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
>   bios->size = 0;
>   if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
>   bios->size = data[2] * 512;
> + if (!bios->size)
> + return;
>  
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   for (i = 0; bios->data && i < bios->size; i += cnt) {
> @@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
>  static int
>  nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
>  {
> - if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
> + if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
> + bios->data[1] != 0xAA) {
>   nv_info(bios, "... signature not found\n");
>   return 0;
>   }
>  
> - if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
> + if (nvbios_checksum(bios->data,
> + min_t(u32, bios->data[2] * 512, bios->size))) {
>   nv_info(bios, "... checksum invalid\n");
>   /* if a ro image is somewhat bad, it's probably all rubbish */
>   return writeable ? 2 : 1;
> -- 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote: 
> 
> > Try this one.
> 
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
> 
> [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
> minor 0
> [3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
> [3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> [3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
> [3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
> [3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> [3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond 
> end of region [VROM] (length 24) (20120913/exfldio-210)
> [3.704139] ACPI Error: Method parse/execution 
> failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), 
> AE_AML_REGION_LIMIT (20120913/psparse-536)
> [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> [3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for image...
> [3.724111] nouveau :01:00.0: Invalid ROM contents
> [3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable image
> [3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 0x1001, 
> -22
> [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> [3.736097] nouveau: probe of :01:00.0 failed with error -22
> [3.740523] dracut: Starting plymouth daemon
> 
> And here's the same output with plain vanilla 3.6.2:
> 
> [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card 
> (0x0a8800b1)
> [3.599783] vga_switcheroo: enabled
> [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
> [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found
> [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS
> [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found
> [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS
> [3.856854] [drm] nouveau :01:00.0: ... appears to be valid
> [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI
> [3.861907] [drm] nouveau :01:00.0: BIT BIOS found
> [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00
> [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0
> [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
> [3.870871] [drm] nouveau :01:00.0: DCB version 4.0
> [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 
> [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040
> [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146
> [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261
> [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330
> [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400
> [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560
> [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running 
> VBIOS init tables.
> [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at 
> offset 0xDECD
> [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6
> [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at 
> offset 0xE378
> [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at 
> offset 0xEF4B
> [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at 
> offset 0xEF64
> [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at 
> offset 0xF04B
> [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 
> 0xF0B0
> [4.018084] [TTM] Zone  kernel: Available graphics memory: 1917766 kiB
> [4.019438] [TTM] Initializing pool allocator
> [4.020694] [TTM] Initializing DMA pool allocator
> [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3)
> [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
> [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [4.084909] [drm] No driver support for vblank timestamp query.
> [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface 
> available, not registering our own
> [4.246449] [drm] nouveau :01:00.0: 3 available performance level(s)
> [4.247560] [drm] nouveau :01:00.0: 0: core 135MHz shader 270MHz 
> memory 135MHz voltage 850mV
> [4.248707] [drm] nouveau :01:00.0: 1: core 405MHz shader

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 11:42:17PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote: 
> > 
> > > Try this one.
> > 
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> > 
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
> > minor 0
> > [3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
> > [3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > [3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
> > [3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for 
> > image...
> > [3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> > [3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond 
> > end of region [VROM] (length 24) (20120913/exfldio-210)
> > [3.704139] ACPI Error: Method parse/execution 
> > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), 
> > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > [3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for 
> > image...
> > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > [3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable 
> > image
> > [3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 
> > 0x1001, -22
> > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > [3.740523] dracut: Starting plymouth daemon
> > 
> > And here's the same output with plain vanilla 3.6.2:
> > 
> > [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card 
> > (0x0a8800b1)
> > [3.599783] vga_switcheroo: enabled
> > [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
> > [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found
> > [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS
> > [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found
> > [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS
> > [3.856854] [drm] nouveau :01:00.0: ... appears to be valid
> > [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI
> > [3.861907] [drm] nouveau :01:00.0: BIT BIOS found
> > [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00
> > [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0
> > [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
> > [3.870871] [drm] nouveau :01:00.0: DCB version 4.0
> > [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 
> > [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040
> > [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146
> > [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261
> > [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330
> > [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400
> > [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560
> > [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running 
> > VBIOS init tables.
> > [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at 
> > offset 0xDECD
> > [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6
> > [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at 
> > offset 0xE378
> > [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at 
> > offset 0xEF4B
> > [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at 
> > offset 0xEF64
> > [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at 
> > offset 0xF04B
> > [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at 
> > offset 0xF0B0
> > [4.018084] [TTM] Zone  kernel: Available graphics memory: 1917766 kiB
> > [4.019438] [TTM] Initializing pool allocator
> > [4.020694] [TTM] Initializing DMA pool allocator
> > [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3)
> > [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
> > [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> > [4.084909] [drm] No driver support for vblank timestamp query.
> > [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface 
> > available, not registering our own
> > 

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote: 
> 
> > Try this one.
> 
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
> 
> [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
> minor 0
> [3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
> [3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> [3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
> [3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
> [3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> [3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond 
> end of region [VROM] (length 24) (20120913/exfldio-210)
> [3.704139] ACPI Error: Method parse/execution 
> failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), 
> AE_AML_REGION_LIMIT (20120913/psparse-536)
> [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> [3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for image...
> [3.724111] nouveau :01:00.0: Invalid ROM contents
> [3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable image
> [3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 0x1001, 
> -22
> [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> [3.736097] nouveau: probe of :01:00.0 failed with error -22
> [3.740523] dracut: Starting plymouth daemon

Hmm, maybe we can't fetch 3 bytes only...

Let's check this:

---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index 824eea0..8bd71aa 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
 {
struct pci_dev *pdev = nv_device(bios)->pdev;
int ret, cnt, i;
-   u8  data[3];
+   u8  *data;
 
if (!nouveau_acpi_rom_supported(pdev))
return;
 
bios->size = 0;
-   if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
+   data = kmalloc(4096, GFP_KERNEL);
+   if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
bios->size = data[2] * 512;
+   kfree(data);
if (!bios->size)
return;
 
---

Please attach acpidump output.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel