Best practice device tree design for display subsystems/DRM

[Rob Clark]

On Tue, Jul 2, 2013 at 9:46 PM, St?phane Marchesin
 wrote:
> On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie  wrote:
>> On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer  
>> wrote:
>>> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
 On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
 > I am against a super node which contains lcd and dcon/ire nodes. You can
 > enable those devices on a per board basis. We add them to dove.dtsi but
 > disable them by default (status = "disabled").
 >
 > The DRM driver itself should get a video-card node outside of
 > soc/internal-regs where you can put e.g. video memory hole (or video
 > mem size if it will be taken from RAM later)
 >
 > About the unusual case, I guess we should try to get both lcd
 > controllers into one DRM driver. Then support mirror or screen
 > extension X already provides. For those applications where you want
 > X on one lcd and some other totally different video stream - wait
 > for someone to come up with a request or proposal.

 Well, all I can say then is that the onus is on those who want to treat
 the components as separate devices to come up with some foolproof way
 to solve this problem which doesn't involve making assumptions about
 the way that devices are probed and doesn't end up creating artificial
 restrictions on how the devices can be used - and doesn't end up burdening
 the common case with lots of useless complexity that they don't need.

 It's _that_ case which needs to come up with a proposal about how to
 handle it because you _can't_ handle it at the moment in any sane
 manner which meets the criteria I've set out above, and at the moment
 the best proposal by far to resolve that is the "super node" approach.

 There is _no_ way in the device model to combine several individual
 devices together into one logical device safely when the subsystem
 requires that there be a definite point where everything is known.
 That applies even more so with -EPROBE_DEFER.  With the presence of
 such a thing, there is now no logical point where any code can say
 definitively that the system has technically finished booting and all
 resources are known.

 That's the problem - if you don't od the super-node approach, you end
 up with lots of individual devices which you have to figure out some
 way of combining, and coping with missing ones which might not be
 available in the order you want them to be, etc.

 That's the advantage of the "super node" approach - it's a container
 to tell you what's required in order to complete the creation of the
 logical device, and you can parse the sub-nodes to locate the
 information you need.
>>>
>>> I think such an approach would lead to drm drivers which all parse their
>>> "super nodes" themselves and driver authors would become very creative
>>> how such a node should look like.
>>>
>>> Also this gets messy with i2c devices which are normally registered
>>> under their i2c bus masters. With the super node approach these would
>>> have to live under the super node, maybe with a phandle to the i2c bus
>>> master. This again probably leads to very SoC specific solutions. It
>>> also doesn't solve the problem that the i2c bus master needs to be
>>> registered by the time the DRM driver probes.
>>>
>>> On i.MX the IPU unit not only handles the display path but also the
>>> capture path. v4l2 begins to evolve an OF model in which each (sub)device
>>> has its natural position in the devicetree; the devices are then
>>> connected with phandles. I'm not sure how good this will work together
>>> with a super node approach.
>>>

 An alternative as I see it is that DRM - and not only DRM but also
 the DRM API and Xorg - would need to evolve hotplug support for the
 various parts of the display subsystem.  Do we have enough people
 with sufficient knowledge and willingness to be able to make all
 that happen?  I don't think we do, and I don't see that there's any
 funding out there to make such a project happen, which would make it
 a volunteer/spare time effort.
>>>
>>> +1 for this solution, even if this means more work to get from the
>>> ground.
>>>
>>> Do we really need full hotplug support in the DRM API and Xorg? I mean
>>> it would really be nice if Xorg detected a newly registered device, but
>>> as a start it should be sufficient when Xorg detects what's there when
>>> it starts, no?
>>
>> Since fbdev and fbcon sit on top of drm to provide the console
>> currently I'd also expect some fun with them. How do I get a console
>> if I have no outputs at boot, but I have crtcs? do I just wait around
>> until an output appears.
>>
>> There are a number of issues with hotplugging encoders and connectors
>> at runtime, when really the SoC/board designer knows what it provides
>> and 

[PATCH] drm/radeon/dpm: Add #include to *_dpm.c files

[Mike Lothian]

Hi

I sent this to the wrong mailing list and it had the wrong patch format

Fixed thanks to glisse

Cheers

Mike


On 2 July 2013 21:34, Mike Lothian  wrote:

> Hi
>
> This patch allows me to compile using GCC 4.7.3 system when using ld.bfd -
> it doesn't seem to be required on my GCC 4.8.1 system using ld.gold - I'm
> not sure why
>
> Cheers
>
> Mike
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130702/77461d2d/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Add-include-linux-seq_file.h-to-_dpm.c-files.patch
Type: application/octet-stream
Size: 2924 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130702/77461d2d/attachment.obj>

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

[Jörg-Volker Peetz]

Alex Deucher wrote, on 07/02/2013 22:17:
> On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz  wrote:
>> Alex Deucher wrote, on 07/02/2013 21:46:
>>> On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz  
>>> wrote:
 With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics 
 (ATI
 RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon 
 HD 5400
 Series]) uvd seems to be broken.

 The new firware files are installed in /lib/firmware/radeon:

 sha1 hashes
 3142a64061ade6032c95ed948c85b15dd0ae46be  CEDAR_me.bin
 a92856a4fa16926e2451a6335da7e20f01fde210  CEDAR_pfp.bin
 644b29756636687ad31a49da4aa3ed85dcedecdb  CEDAR_rlc.bin
 992d49518d3936986b5ce3ddb0d9bbd75135bb8f  CYPRESS_uvd.bin
 3e04529600d666ddb2f2f83bb0112d4fab516c04  R600_rlc.bin

 The system boots without initial ram disk.
>>>
>>> Make sure your system is using the latest CEDAR_rlc.bin as well.
>>>
>>> Alex
>>>
>> Thanks for the hint, Alex. Actually I took the files today from your 
>> repository
>> at http://people.freedesktop.org/~agd5f/radeon_ucode/ and checked them 
>> against
>> the ones downloaded from
>> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git .
> 
> Make sure that your kernel is actually using the new ones.
> 
> Alex
> 

The files are located in /lib/firmware/radeon , the kernel configuration 
contains

CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin radeon/R600_rlc.bin
radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin
radeon/CYPRESS_uvd.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

I compiled the kernel with the firmware files already in /lib/firmware/radeon .
The kernel boots without initial ram disk.

Do I miss something?

Regards,
J?rg-Volker.

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

[Jörg-Volker Peetz]

Alex Deucher wrote, on 07/02/2013 21:46:
> On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz  wrote:
>> With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics (ATI
>> RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon HD 
>> 5400
>> Series]) uvd seems to be broken.
>>
>> The new firware files are installed in /lib/firmware/radeon:
>>
>> sha1 hashes
>> 3142a64061ade6032c95ed948c85b15dd0ae46be  CEDAR_me.bin
>> a92856a4fa16926e2451a6335da7e20f01fde210  CEDAR_pfp.bin
>> 644b29756636687ad31a49da4aa3ed85dcedecdb  CEDAR_rlc.bin
>> 992d49518d3936986b5ce3ddb0d9bbd75135bb8f  CYPRESS_uvd.bin
>> 3e04529600d666ddb2f2f83bb0112d4fab516c04  R600_rlc.bin
>>
>> The system boots without initial ram disk.
> 
> Make sure your system is using the latest CEDAR_rlc.bin as well.
> 
> Alex
> 
Thanks for the hint, Alex. Actually I took the files today from your repository
at http://people.freedesktop.org/~agd5f/radeon_ucode/ and checked them against
the ones downloaded from
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git .

Regards,
J?rg-Volker.

> 

Best practice device tree design for display subsystems/DRM

[Sebastian Hesselbarth]

On 07/02/2013 09:19 PM, Russell King wrote:
> On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote:
>> It seems that you did not look at the NVIDIA Tegra driver (I got its
>> general concept for my own driver, but I used a simple atomic counter):
>>
>> - at probe time, the main driver (drivers/gpu/host1x/drm/drm.c) scans
>>the DT and finds its external modules. These ones are put in a
>>"clients" list.
>>
>> - when loaded, the other modules register themselves into the main
>>driver. This last one checks if each module is in the "client" list.
>>If so, the module is moved from the "client" to an "active" list".
>>
>> - when the "client" list is empty, this means all modules are started,
>>and, so, the main driver starts the drm stuff.
>>
>> The active list is kept for module unloading.
>
> Please tell me how this works with the two LCD controllers if you wish
> to drive the two LCD controllers as entirely separate devices.  Given
> that the above requires the use of global data in the driver, how do
> you distinguish between the two?
>
>> Putting "phandle"s in the 'display' seems more flexible (I did not do so
>> because I knew the hardware - 2 LCDs and the dcon/ire).
>
> Except you haven't looked at the bigger picture - the Armada 510 is
> unusual in that it has two LCD controllers and the DCON.  All of the
> other SoCs using this IP block that I've been able to research have
> only one LCD controller and no DCON.  I don't think they even have an
> IRE (image rotation engine) either.
>
> Neither have you considered the case where you may wish to keep the
> two LCD controllers entirely separate (eg, you want X to drive one
> but something else on the other.)  X drives the DRM device as a whole,
> including all CRTCs which make up that device - with them combined
> into one DRM device, you can't ask X to leave one controller alone
> because you're doing something else with it.  (This is just the simple
> extension of the common case of a single LCD controller, so it's
> really nothing special.)
>
> So, the unusual case _is_ the Armada 510 with its two LCD controllers
> and DCON which we _could_ work out some way of wrapping up into one
> DRM device, or we could just ignore the special case, ignore the DCON
> and just keep the two LCD CRTCs as two separate and independent DRM
> devices.
>
> I'm actually starting to come towards the conclusion that we should go
> for the easiest solution, which is the one I just mentioned, and forget
> trying to combine these devices into one super DRM driver.

I am against a super node which contains lcd and dcon/ire nodes. You can
enable those devices on a per board basis. We add them to dove.dtsi but
disable them by default (status = "disabled").

The DRM driver itself should get a video-card node outside of 
soc/internal-regs where you can put e.g. video memory hole (or video
mem size if it will be taken from RAM later)

About the unusual case, I guess we should try to get both lcd
controllers into one DRM driver. Then support mirror or screen
extension X already provides. For those applications where you want
X on one lcd and some other totally different video stream - wait
for someone to come up with a request or proposal.

Sebastian

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Ville Syrjälä]

On Tue, Jul 02, 2013 at 07:23:27PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 02, 2013 at 09:01:55PM +0300, Ville Syrj?l? wrote:
> > On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote:
> > > On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
> > >  wrote:
> > > > | Default Colorimetry
> > > > |
> > > > | ...
> > > > |
> > > > | 480p, 480i, 576p, 576i, 240p and 288p
> > > > |
> > > > | The default colorimetry for all 480-line, 576-line, 240-line, and 
> > > > 288-line
> > > > | video formats described in CEA-861-D is based on SMPTE 170M.
> > > > |
> > > > | 1080i, 1080p and 720p
> > > > |
> > > > | The default colorimetry for high-definition video formats (1080i, 
> > > > 1080p and
> > > > | 720p) described in CEA-861-D is based on ITU-R BT.709-5.
> > 
> > I think this was pretty much copy pasted from CEA-861-D which is very
> > vague.
> > 
> > CEA-861-E is a bit better, and more clearly states that if the sink can
> > receive YCbCr, then the source should use it by default for CE formats,
> > and the default colorimetry depends on whether it's SD or HD. It also
> > states that when transmitting IT or CE formats as RGB, the color space
> > is the one defined in the EDID. CEA-861-D only made that statement for
> > IT formats, and left the RGB CE format case out in the cold.
> 
> Actually, what I'm doing there is probably wrong when you consider
> what is going on:
> 
>  Overlay (YUV) -> YUV->RGB colorspace conversion
>   |
>   v
>  Graphic (RGB) ---(colorkey)> HDMI
> 
> These bits control the YUV->RGB colorspace conversion.  The "is it 601
> or 709 colorspace" question applies more to the colorspace of the
> overlay image.  As far as I can tell, that is unspecified within our
> normal video playback programs - there's provision to communicate that
> information (they certainly don't seem to look for any kind of Xv
> attribute).
> 
> The "is it computer or studio RGB" question (I think - I can't say
> because the documentation is hellishly poor, and you now have as much
> information on this as I do) refers to the colorspace of the RGB side.
> 
> So, maybe I should move the YUV colorspace setting to be a drm_plane
> property?  But then how do we know what format it is supposed to be?
> Do we just pick one and hope it's right?  Do we try to autodetect it
> from the size of the drm_plane framebuffer?  What if something
> downscales a HD YUV framebuffer to something smaller because the
> display is smaller?

Yes a plane property would be the right thing to use here. I'm not sure
we need any automagic default in the kernel for this stuff. I'm thinking
we just default to BT.601 (or something else if the hardware is really
weird and doesn't do BT.601) and let userspace override if it wants.

My plan for such a property has thus far been an enum called "csc matrix"
(or something vaguely similar) and the values could just be something
like "BT.601", "BT.709" etc.

Calling the property "csc matrix" has one downside though; What if the
hardware CSC is fully programmable and we want to push an actual matrix
from userspace. That property might also like to be called "csc matrix",
so maybe we want try to come up with a better name for this first guy.
Or maybe it should be "csc matrix" = "custom" + "csc matrix custom" =
. There's also the question of the format of the
coefficients in the custom matrix. We may need some HW specifics
there...

> What I can say is that I've watched many hours of content with my driver
> and at 720p output resolution, I prefer it converting the YUV between
> 709 to studio RGB - otherwise the blacks are too black and I find that
> I have to adjust the brightness/contrast to bring the black levels up
> compared to a standard TV broadcast.
> 
> > Oh and the other thing someone should do is fix the intel Xv code to
> > use BT.709 CSC matrix for HD content. I believe that code is hardcoded
> > for BT.601 currently, which may explain the last weirdness reported in
> > that CEA bug or ours.
> 
> How do you propose to switch between the two?

An Xv port attribute should do. Google found me XV_COLORSPACE, which
seems to be the name the radeon folks picked for it.

-- 
Ville Syrj?l?
Intel OTC

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

[Inki Dae]

2013/7/2 YoungJun Cho :
> Dear Ville
>
> On Jul 2, 2013 8:42 PM, "Ville Syrj?l?" 
> wrote:
>>
>> On Tue, Jul 02, 2013 at 07:59:22PM +0900, Seung-Woo Kim wrote:
>> > From: YoungJun Cho 
>> >
>> > When drm iommu is not supported, buf->pages has to be allocated
>> > and assigned to phys_to_page() result, which type is struct page *.
>> > So it is sufficient to allocate buf->pages with multiple struct
>> > page pointer size.
>> >
>> > Signed-off-by: YoungJun Cho 
>> > Signed-off-by: Kyungmin Park 
>> > ---
>> >  drivers/gpu/drm/exynos/exynos_drm_buf.c |2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_buf.c
>> > index 22865ba..3200622 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
>> > @@ -57,7 +57,7 @@ static int lowlevel_buffer_allocate(struct drm_device
>> > *dev,
>> >   dma_addr_t start_addr;
>> >   unsigned int i = 0;
>> >
>> > - buf->pages = kzalloc(sizeof(struct page) * nr_pages,
>> > + buf->pages = kzalloc(sizeof(struct page *) * nr_pages,
>> >   GFP_KERNEL);
>>
>> Looks like a prime candidate for kcalloc()
>>
>
> Thank you for nice comments.
> I had no idea to consider overflow!
>
> I'll update again.

Mr. Cho,

it seems better to use utility function, drm_calloc_large().

Thanks,
Inki Dae

>
> Best regards YJ
>
>> >   if (!buf->pages) {
>> >   DRM_ERROR("failed to allocate pages.\n");
>> > --
>> > 1.7.9.5
>> >
>> > ___
>> > dri-devel mailing list
>> > dri-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> --
>> Ville Syrj?l?
>> Intel OTC
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Best practice device tree design for display subsystems/DRM

[Russell King]

On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
> I am against a super node which contains lcd and dcon/ire nodes. You can
> enable those devices on a per board basis. We add them to dove.dtsi but
> disable them by default (status = "disabled").
>
> The DRM driver itself should get a video-card node outside of  
> soc/internal-regs where you can put e.g. video memory hole (or video
> mem size if it will be taken from RAM later)
>
> About the unusual case, I guess we should try to get both lcd
> controllers into one DRM driver. Then support mirror or screen
> extension X already provides. For those applications where you want
> X on one lcd and some other totally different video stream - wait
> for someone to come up with a request or proposal.

Well, all I can say then is that the onus is on those who want to treat
the components as separate devices to come up with some foolproof way
to solve this problem which doesn't involve making assumptions about
the way that devices are probed and doesn't end up creating artificial
restrictions on how the devices can be used - and doesn't end up burdening
the common case with lots of useless complexity that they don't need.

It's _that_ case which needs to come up with a proposal about how to
handle it because you _can't_ handle it at the moment in any sane
manner which meets the criteria I've set out above, and at the moment
the best proposal by far to resolve that is the "super node" approach.

There is _no_ way in the device model to combine several individual
devices together into one logical device safely when the subsystem
requires that there be a definite point where everything is known.
That applies even more so with -EPROBE_DEFER.  With the presence of
such a thing, there is now no logical point where any code can say
definitively that the system has technically finished booting and all
resources are known.

That's the problem - if you don't od the super-node approach, you end
up with lots of individual devices which you have to figure out some
way of combining, and coping with missing ones which might not be
available in the order you want them to be, etc.

That's the advantage of the "super node" approach - it's a container
to tell you what's required in order to complete the creation of the
logical device, and you can parse the sub-nodes to locate the
information you need.

An alternative as I see it is that DRM - and not only DRM but also
the DRM API and Xorg - would need to evolve hotplug support for the
various parts of the display subsystem.  Do we have enough people
with sufficient knowledge and willingness to be able to make all
that happen?  I don't think we do, and I don't see that there's any
funding out there to make such a project happen, which would make it
a volunteer/spare time effort.

-- 
Russell King

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

[YoungJun Cho]

Dear Ville

On Jul 2, 2013 8:42 PM, "Ville Syrj?l?" 
wrote:
>
> On Tue, Jul 02, 2013 at 07:59:22PM +0900, Seung-Woo Kim wrote:
> > From: YoungJun Cho 
> >
> > When drm iommu is not supported, buf->pages has to be allocated
> > and assigned to phys_to_page() result, which type is struct page *.
> > So it is sufficient to allocate buf->pages with multiple struct
> > page pointer size.
> >
> > Signed-off-by: YoungJun Cho 
> > Signed-off-by: Kyungmin Park 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_buf.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
> > index 22865ba..3200622 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
> > @@ -57,7 +57,7 @@ static int lowlevel_buffer_allocate(struct drm_device
*dev,
> >   dma_addr_t start_addr;
> >   unsigned int i = 0;
> >
> > - buf->pages = kzalloc(sizeof(struct page) * nr_pages,
> > + buf->pages = kzalloc(sizeof(struct page *) * nr_pages,
> >   GFP_KERNEL);
>
> Looks like a prime candidate for kcalloc()
>

Thank you for nice comments.
I had no idea to consider overflow!

I'll update again.

Best regards YJ

> >   if (!buf->pages) {
> >   DRM_ERROR("failed to allocate pages.\n");
> > --
> > 1.7.9.5
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130702/4036e6f5/attachment.html>

[PATCH] drm/exynos: Add missing includes

[Inki Dae]

> -Original Message-
> From: Mark Brown [mailto:broonie at kernel.org]
> Sent: Monday, July 01, 2013 9:56 PM
> To: Inki Dae; Joonyoung Shim; Seung-Woo Kim; Kyungmin Park; David Airlie
> Cc: dri-devel at lists.freedesktop.org; linux-arm-kernel at 
> lists.infradead.org;
> linux-samsung-soc at vger.kernel.org; Mark Brown
> Subject: [PATCH] drm/exynos: Add missing includes
> 
> From: Mark Brown 
> 
> Ensure that all externally accessed functions are correctly prototyped
> when defined in each file by making sure the headers with the protoypes
> are included in the file with the definition.
> 

Hi Mark,

I don't see why this patch is needed. it seems like including unnecessary
headers so it makes the code size enlarged.

Thanks,
Inki Dae

> Signed-off-by: Mark Brown 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_connector.c | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c| 1 +
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 1 +
>  10 files changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index 8bcc13a..ec80293 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_encoder.h"
> +#include "exynos_drm_connector.h"
> 
>  #define to_exynos_connector(x)   container_of(x, struct
> exynos_drm_connector,\
>   drm_connector)
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 073c10a..6933ee9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
> 
> +#include "exynos_drm_crtc.h"
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_encoder.h"
>  #include "exynos_drm_plane.h"
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> index ff7f2a8..8adafde 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> @@ -11,6 +11,7 @@
> 
>  #include 
>  #include 
> +#include "exynos_drm_dmabuf.h"
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_gem.h"
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 8f007aa..45b6cb3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -19,6 +19,7 @@
> 
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
> +#include "exynos_drm_fbdev.h"
>  #include "exynos_drm_gem.h"
>  #include "exynos_drm_iommu.h"
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 4a1616a..a83e664 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include "regs-fimc.h"
> +#include "exynos_drm_drv.h"
>  #include "exynos_drm_ipp.h"
>  #include "exynos_drm_fimc.h"
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index af75434..03ba897 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include "exynos_drm_drv.h"
> +#include "exynos_drm_g2d.h"
>  #include "exynos_drm_gem.h"
>  #include "exynos_drm_iommu.h"
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 762f40d..4683251 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include "regs-gsc.h"
> +#include "exynos_drm_drv.h"
>  #include "exynos_drm_ipp.h"
>  #include "exynos_drm_gsc.h"
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 83efc66..63ebeeb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -16,6 +16,7 @@
>  #include "exynos_drm_encoder.h"
>  #include "exynos_drm_fb.h"
>  #include "exynos_drm_gem.h"
> +#include "exynos_drm_plane.h"
> 
>  #define to_exynos_plane(x)   container_of(x, struct exynos_plane,
> base)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index 9b6c709..2e9eee2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ 

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Ville Syrjälä]

On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote:
> On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
>  wrote:
> > On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote:
> >> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> >> > +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
> >> > +{
> >> > +   struct drm_display_mode *adj = >crtc.mode;
> >> > +   uint32_t val = 0;
> >> > +
> >> > +   if (dcrtc->csc_yuv_mode == CSC_YUV_CCIR709)
> >> > +   val |= CFG_CSC_YUV_CCIR709;
> >> > +   if (dcrtc->csc_rgb_mode == CSC_RGB_STUDIO)
> >> > +   val |= CFG_CSC_RGB_STUDIO;
> >> > +
> >> > +   /*
> >> > +* In auto mode, set the colorimetry, based upon the HDMI spec.
> >> > +* 1280x720p, 1920x1080p and 1920x1080i use ITU709, others use
> >> > +* ITU601.  It may be more appropriate to set this depending on
> >> > +* the source - but what if the graphic frame is YUV and the
> >> > +* video frame is RGB?
> >> > +*/
> >> > +   if ((adj->hdisplay == 1280 && adj->vdisplay == 720 &&
> >> > +!(adj->flags & DRM_MODE_FLAG_INTERLACE)) ||
> >> > +   (adj->hdisplay == 1920 && adj->vdisplay == 1080)) {
> >> > +   if (dcrtc->csc_yuv_mode == CSC_AUTO)
> >> > +   val |= CFG_CSC_YUV_CCIR709;
> >> > +   }
> >> > +
> >> > +   /*
> >> > +* We assume we're connected to a TV-like device, so the YUV->RGB
> >> > +* conversion should produce a limited range.  We should set this
> >> > +* depending on the connectors attached to this CRTC, and what
> >> > +* kind of device they report being connected.
> >> > +*/
> >> > +   if (dcrtc->csc_rgb_mode == CSC_AUTO)
> >> > +   val |= CFG_CSC_RGB_STUDIO;
> >>
> >> In the intel driver we check whether it's an cea mode with
> >> drm_match_cea_mode, e.g. in intel_hdmi.c:
> >>
> >>   if (intel_hdmi->color_range_auto) {
> >>   /* See CEA-861-E - 5.1 Default Encoding Parameters */
> >>   if (intel_hdmi->has_hdmi_sink &&
> >>   drm_match_cea_mode(adjusted_mode) > 1)
> >>   intel_hdmi->color_range = HDMI_COLOR_RANGE_16_235;
> >>   else
> >>   intel_hdmi->color_range = 0;
> >>   }
> >>
> >> (The color_range gets then propageted to the right place since different
> >> platforms have different ways to do that in intel hw).
> >
> > Unfortunately, this disagrees with the HDMI v1.3a specification:
> >
> > | Default Colorimetry
> > |
> > | ...
> > |
> > | 480p, 480i, 576p, 576i, 240p and 288p
> > |
> > | The default colorimetry for all 480-line, 576-line, 240-line, and 288-line
> > | video formats described in CEA-861-D is based on SMPTE 170M.
> > |
> > | 1080i, 1080p and 720p
> > |
> > | The default colorimetry for high-definition video formats (1080i, 1080p 
> > and
> > | 720p) described in CEA-861-D is based on ITU-R BT.709-5.

I think this was pretty much copy pasted from CEA-861-D which is very
vague.

CEA-861-E is a bit better, and more clearly states that if the sink can
receive YCbCr, then the source should use it by default for CE formats,
and the default colorimetry depends on whether it's SD or HD. It also
states that when transmitting IT or CE formats as RGB, the color space
is the one defined in the EDID. CEA-861-D only made that statement for
IT formats, and left the RGB CE format case out in the cold.

> > As the HDMI spec refers to the CEA-861 specs, the HDMI spec overrides
> > CEA when dealing with HDMI specifics.
> >
> > So, according to the HDMI specification, the default is that it's only
> > 1080i, 1080p and 720p which are 709, the others are 601.  This does not
> > correspond with "drm_match_cea_mode(adjusted_mode) > 1".

We're mixing our apples and oranges here. The logic in i915 has to do
with the default RGB quantization range only.

> Hm, sounds like we need to improve stuff a bit, maybe add a common cea
> helper to the drm core with a bool is_hdmi to decide whether it's
> palin CEA or HDMI-CEA. Ville (who's written the current code and the
> match cea mode helper) can you please take a look?

Currently i915 only outputs RGB, so based on CEA-861-E setting C=00 is
the right thing to do. So I think the only thing we could improve is to
use YCbCr for CE formats by default, but first we need to implement
YCbCr output support :P

Oh and the other thing someone should do is fix the intel Xv code to
use BT.709 CSC matrix for HD content. I believe that code is hardcoded
for BT.601 currently, which may explain the last weirdness reported in
that CEA bug or ours.

> > Unfortunately, given DRM's structure, there's no way for the CRTC layer
> > to really know what its driving, and this setting is at the CRTC layer,
> > not the output layer.  It may be that you have the CRTC duplicated
> > between two different display devices with different characteristics,
> > which means you have to "choose" one - or just not bother.  I've chosen
> > 

Best practice device tree design for display subsystems/DRM

[Jean-Francois Moine]

On Tue, 2 Jul 2013 11:43:59 -0600
Daniel Drake  wrote:

> Hi,

Hi Daniel,

> I'm looking into implementing devicetree support in armada_drm and
> would like to better understand the best practice here.
> 
> Adding DT support for a DRM driver seems to be complicated by the fact
> that DRM is not "hotpluggable" - it is not possible for the drm_device
> to be initialised without an output, with the output connector/encoder
> appearing at some later moment. Instead, the connectors/encoders must
> be fully loaded before the drm_driver load function returns. This
> means that we cannot drive the individual display components through
> individual, separate modules - we need a way to control their load
> order.
> 
> Looking at existing DRM drivers:
[snip]

It seems that you did not look at the NVIDIA Tegra driver (I got its
general concept for my own driver, but I used a simple atomic counter):

- at probe time, the main driver (drivers/gpu/host1x/drm/drm.c) scans
  the DT and finds its external modules. These ones are put in a
  "clients" list.

- when loaded, the other modules register themselves into the main
  driver. This last one checks if each module is in the "client" list.
  If so, the module is moved from the "client" to an "active" list".

- when the "client" list is empty, this means all modules are started,
  and, so, the main driver starts the drm stuff.

The active list is kept for module unloading.

> Russell King suggested an alternative design for armada_drm. If all
> display components are represented within the same "display"
> super-node, we can examine the DT during drm_device initialisation and
> initialise the appropriate output components. In this case, the output
> components would not be registered as platform drivers.
> 
> The end result would be something similar to exynos/tilcdc (i.e.
> drm_driver figuring out its output in the appropriate moment), however
> the hackyness of using global storage to store output devices before
> drm_driver is ready is avoided. And there is the obvious difference in
> devicetree layout, which would look something like:
> 
> display {
>   compatible = "marvell,armada-510-display";
>   clocks = <_clk0>, <_pll_clk>;
>   lcd0 {
> compatible = "marvell,armada-510-lcd";
> reg = <0xf182 0x1000>;
> interrupts = <47>;
>   };
>   lcd1 {
> compatible = "marvell,armada-510-lcd";
> reg = <0xf181 0x1000>;
> interrupts = <46>;
>   };
>   dcon {
> compatible = "marvell,armada-510-dcon";
> reg = <...>;
>   };
> };

Putting "phandle"s in the 'display' seems more flexible (I did not do so
because I knew the hardware - 2 LCDs and the dcon/ire).

But, anyway, this does not solve the exact moment the modules are
loaded at startup time.

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

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

216000
[  199.715661] [drm] fb depth is 24
[  199.715714] [drm]pitch is 7680
[  199.715797] fbcon: radeondrmfb (fb0) is primary device
[  199.990513] Console: switching to colour frame buffer device 240x75
[  200.042891] radeon :05:00.0: fb0: radeondrmfb frame buffer device
[  200.043109] radeon :05:00.0: registered panic notifier
[  200.043296] [drm] Initialized radeon 2.33.0 20080528 for :05:00.0 on
minor 0

Justin.

-- 
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/20130702/9b9bfa5d/attachment.html>

Best practice device tree design for display subsystems/DRM

[Russell King]

On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote:
> It seems that you did not look at the NVIDIA Tegra driver (I got its
> general concept for my own driver, but I used a simple atomic counter):
> 
> - at probe time, the main driver (drivers/gpu/host1x/drm/drm.c) scans
>   the DT and finds its external modules. These ones are put in a
>   "clients" list.
> 
> - when loaded, the other modules register themselves into the main
>   driver. This last one checks if each module is in the "client" list.
>   If so, the module is moved from the "client" to an "active" list".
> 
> - when the "client" list is empty, this means all modules are started,
>   and, so, the main driver starts the drm stuff.
> 
> The active list is kept for module unloading.

Please tell me how this works with the two LCD controllers if you wish
to drive the two LCD controllers as entirely separate devices.  Given
that the above requires the use of global data in the driver, how do
you distinguish between the two?

> Putting "phandle"s in the 'display' seems more flexible (I did not do so
> because I knew the hardware - 2 LCDs and the dcon/ire).

Except you haven't looked at the bigger picture - the Armada 510 is
unusual in that it has two LCD controllers and the DCON.  All of the
other SoCs using this IP block that I've been able to research have
only one LCD controller and no DCON.  I don't think they even have an
IRE (image rotation engine) either.

Neither have you considered the case where you may wish to keep the
two LCD controllers entirely separate (eg, you want X to drive one
but something else on the other.)  X drives the DRM device as a whole,
including all CRTCs which make up that device - with them combined
into one DRM device, you can't ask X to leave one controller alone
because you're doing something else with it.  (This is just the simple
extension of the common case of a single LCD controller, so it's
really nothing special.)

So, the unusual case _is_ the Armada 510 with its two LCD controllers
and DCON which we _could_ work out some way of wrapping up into one
DRM device, or we could just ignore the special case, ignore the DCON
and just keep the two LCD CRTCs as two separate and independent DRM
devices.

I'm actually starting to come towards the conclusion that we should go
for the easiest solution, which is the one I just mentioned, and forget
trying to combine these devices into one super DRM driver.

-- 
Russell King

Best practice device tree design for display subsystems/DRM

[Russell King]

On Tue, Jul 02, 2013 at 12:54:41PM -0600, Daniel Drake wrote:
> On Tue, Jul 2, 2013 at 12:43 PM, Russell King  wrote:
> > I will point out that relying on driver probing orders has already been
> > stated by driver model people to be unsafe.  This is why I will not
> > adopt such a solution for my driver; it is a bad design.
> 
> Just to clarify, what you're objecting to is effectively the
> following? Because it is not guaranteed in the future that the probe
> order will be the same as the platform_driver_register() calls?

Correct.  Consider what happens if the devices are registered after
the driver(s) have been registered, which may not be in the correct
order.

-- 
Russell King

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

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

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

--- Comment #3 from Alex Deucher  ---
Does it work if build the driver as a module and load it manually after the
system has booted to a non-X runlevel?

-- 
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/20130702/cb72409a/attachment-0001.html>

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

[Seung-Woo Kim]

From: YoungJun Cho 

When drm iommu is not supported, buf->pages has to be allocated
and assigned to phys_to_page() result, which type is struct page *.
So it is sufficient to allocate buf->pages with multiple struct
page pointer size.

Signed-off-by: YoungJun Cho 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 22865ba..3200622 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -57,7 +57,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
dma_addr_t start_addr;
unsigned int i = 0;

-   buf->pages = kzalloc(sizeof(struct page) * nr_pages,
+   buf->pages = kzalloc(sizeof(struct page *) * nr_pages,
GFP_KERNEL);
if (!buf->pages) {
DRM_ERROR("failed to allocate pages.\n");
-- 
1.7.9.5

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

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

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

--- Comment #2 from Justin Piszcz  ---
Created attachment 81908
  --> https://bugs.freedesktop.org/attachment.cgi?id=81908=edit
dmesg

-- 
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/20130702/06855eaf/attachment.html>

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

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

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

--- Comment #1 from Justin Piszcz  ---
Created attachment 81907
  --> https://bugs.freedesktop.org/attachment.cgi?id=81907=edit
Xorg.0.log.old

-- 
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/20130702/b3f6c211/attachment.html>

[Bug 66519] New: 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

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

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

  Priority: medium
Bug ID: 66519
  Assignee: dri-devel at lists.freedesktop.org
   Summary: 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon:
error initializing UVD (-1).
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: jpiszcz at lucidpixels.com
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 81905
  --> https://bugs.freedesktop.org/attachment.cgi?id=81905=edit
Xorg.0.log

Per:
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg462393.html

Please open a bug (product: DRI, component: DRM/Radeon):
https://bugs.freedesktop.org
and attach your dmesg output and xorg log.

Attaching..

Distribution: Debian Testing
Xorg Version: 7.7+3

1. full-dmesg.txt
2. Xorg.0.log
3. Xorg.0.log.old

-- 
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/20130702/5ec7d74d/attachment.html>

Best practice device tree design for display subsystems/DRM

[Russell King]

On Tue, Jul 02, 2013 at 11:43:59AM -0600, Daniel Drake wrote:
> exynos seems to take a the same approach. Components are separate in
> the device tree, and each component is implemented as a platform
> driver or i2c driver. However all the drivers are built together in
> the same module, and the module_init sequence is careful to initialise
> all of the output component drivers before loading the DRM driver. The
> output component driver store their findings in global structures.

I will point out that relying on driver probing orders has already been
stated by driver model people to be unsafe.  This is why I will not
adopt such a solution for my driver; it is a bad design.

-- 
Russell King

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Tue, Jul 02, 2013 at 09:01:55PM +0300, Ville Syrj?l? wrote:
> On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
> >  wrote:
> > > | Default Colorimetry
> > > |
> > > | ...
> > > |
> > > | 480p, 480i, 576p, 576i, 240p and 288p
> > > |
> > > | The default colorimetry for all 480-line, 576-line, 240-line, and 
> > > 288-line
> > > | video formats described in CEA-861-D is based on SMPTE 170M.
> > > |
> > > | 1080i, 1080p and 720p
> > > |
> > > | The default colorimetry for high-definition video formats (1080i, 1080p 
> > > and
> > > | 720p) described in CEA-861-D is based on ITU-R BT.709-5.
> 
> I think this was pretty much copy pasted from CEA-861-D which is very
> vague.
> 
> CEA-861-E is a bit better, and more clearly states that if the sink can
> receive YCbCr, then the source should use it by default for CE formats,
> and the default colorimetry depends on whether it's SD or HD. It also
> states that when transmitting IT or CE formats as RGB, the color space
> is the one defined in the EDID. CEA-861-D only made that statement for
> IT formats, and left the RGB CE format case out in the cold.

Actually, what I'm doing there is probably wrong when you consider
what is going on:

 Overlay (YUV) -> YUV->RGB colorspace conversion
  |
  v
 Graphic (RGB) ---(colorkey)> HDMI

These bits control the YUV->RGB colorspace conversion.  The "is it 601
or 709 colorspace" question applies more to the colorspace of the
overlay image.  As far as I can tell, that is unspecified within our
normal video playback programs - there's provision to communicate that
information (they certainly don't seem to look for any kind of Xv
attribute).

The "is it computer or studio RGB" question (I think - I can't say
because the documentation is hellishly poor, and you now have as much
information on this as I do) refers to the colorspace of the RGB side.

So, maybe I should move the YUV colorspace setting to be a drm_plane
property?  But then how do we know what format it is supposed to be?
Do we just pick one and hope it's right?  Do we try to autodetect it
from the size of the drm_plane framebuffer?  What if something
downscales a HD YUV framebuffer to something smaller because the
display is smaller?

What I can say is that I've watched many hours of content with my driver
and at 720p output resolution, I prefer it converting the YUV between
709 to studio RGB - otherwise the blacks are too black and I find that
I have to adjust the brightness/contrast to bring the black levels up
compared to a standard TV broadcast.

> Oh and the other thing someone should do is fix the intel Xv code to
> use BT.709 CSC matrix for HD content. I believe that code is hardcoded
> for BT.601 currently, which may explain the last weirdness reported in
> that CEA bug or ours.

How do you propose to switch between the two?

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

[Alex Deucher]

On Tue, Jul 2, 2013 at 4:34 PM, J?rg-Volker Peetz  wrote:
> Alex Deucher wrote, on 07/02/2013 22:17:
>> On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz  wrote:
>>> Alex Deucher wrote, on 07/02/2013 21:46:
 On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz  
 wrote:
> With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics 
> (ATI
> RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon 
> HD 5400
> Series]) uvd seems to be broken.
>
> The new firware files are installed in /lib/firmware/radeon:
>
> sha1 hashes
> 3142a64061ade6032c95ed948c85b15dd0ae46be  CEDAR_me.bin
> a92856a4fa16926e2451a6335da7e20f01fde210  CEDAR_pfp.bin
> 644b29756636687ad31a49da4aa3ed85dcedecdb  CEDAR_rlc.bin
> 992d49518d3936986b5ce3ddb0d9bbd75135bb8f  CYPRESS_uvd.bin
> 3e04529600d666ddb2f2f83bb0112d4fab516c04  R600_rlc.bin
>
> The system boots without initial ram disk.

 Make sure your system is using the latest CEDAR_rlc.bin as well.

 Alex

>>> Thanks for the hint, Alex. Actually I took the files today from your 
>>> repository
>>> at http://people.freedesktop.org/~agd5f/radeon_ucode/ and checked them 
>>> against
>>> the ones downloaded from
>>> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git .
>>
>> Make sure that your kernel is actually using the new ones.
>>
>> Alex
>>
>
> The files are located in /lib/firmware/radeon , the kernel configuration 
> contains
>
> CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin radeon/R600_rlc.bin
> radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin
> radeon/CYPRESS_uvd.bin"
> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>
> I compiled the kernel with the firmware files already in /lib/firmware/radeon 
> .
> The kernel boots without initial ram disk.
>

I've encountered people having all sorts of problems with stale or
truncated firmware, so I just wanted to double check.  The best test
would be to build the driver as a module and blacklist the module,
then, once the system is booted to a non-X runlevel, manually load the
module so it loads the ucode directly from the filesystem.

Alex

Best practice device tree design for display subsystems/DRM

[Stéphane Marchesin]

On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie  wrote:
> On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer  
> wrote:
>> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
>>> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
>>> > I am against a super node which contains lcd and dcon/ire nodes. You can
>>> > enable those devices on a per board basis. We add them to dove.dtsi but
>>> > disable them by default (status = "disabled").
>>> >
>>> > The DRM driver itself should get a video-card node outside of
>>> > soc/internal-regs where you can put e.g. video memory hole (or video
>>> > mem size if it will be taken from RAM later)
>>> >
>>> > About the unusual case, I guess we should try to get both lcd
>>> > controllers into one DRM driver. Then support mirror or screen
>>> > extension X already provides. For those applications where you want
>>> > X on one lcd and some other totally different video stream - wait
>>> > for someone to come up with a request or proposal.
>>>
>>> Well, all I can say then is that the onus is on those who want to treat
>>> the components as separate devices to come up with some foolproof way
>>> to solve this problem which doesn't involve making assumptions about
>>> the way that devices are probed and doesn't end up creating artificial
>>> restrictions on how the devices can be used - and doesn't end up burdening
>>> the common case with lots of useless complexity that they don't need.
>>>
>>> It's _that_ case which needs to come up with a proposal about how to
>>> handle it because you _can't_ handle it at the moment in any sane
>>> manner which meets the criteria I've set out above, and at the moment
>>> the best proposal by far to resolve that is the "super node" approach.
>>>
>>> There is _no_ way in the device model to combine several individual
>>> devices together into one logical device safely when the subsystem
>>> requires that there be a definite point where everything is known.
>>> That applies even more so with -EPROBE_DEFER.  With the presence of
>>> such a thing, there is now no logical point where any code can say
>>> definitively that the system has technically finished booting and all
>>> resources are known.
>>>
>>> That's the problem - if you don't od the super-node approach, you end
>>> up with lots of individual devices which you have to figure out some
>>> way of combining, and coping with missing ones which might not be
>>> available in the order you want them to be, etc.
>>>
>>> That's the advantage of the "super node" approach - it's a container
>>> to tell you what's required in order to complete the creation of the
>>> logical device, and you can parse the sub-nodes to locate the
>>> information you need.
>>
>> I think such an approach would lead to drm drivers which all parse their
>> "super nodes" themselves and driver authors would become very creative
>> how such a node should look like.
>>
>> Also this gets messy with i2c devices which are normally registered
>> under their i2c bus masters. With the super node approach these would
>> have to live under the super node, maybe with a phandle to the i2c bus
>> master. This again probably leads to very SoC specific solutions. It
>> also doesn't solve the problem that the i2c bus master needs to be
>> registered by the time the DRM driver probes.
>>
>> On i.MX the IPU unit not only handles the display path but also the
>> capture path. v4l2 begins to evolve an OF model in which each (sub)device
>> has its natural position in the devicetree; the devices are then
>> connected with phandles. I'm not sure how good this will work together
>> with a super node approach.
>>
>>>
>>> An alternative as I see it is that DRM - and not only DRM but also
>>> the DRM API and Xorg - would need to evolve hotplug support for the
>>> various parts of the display subsystem.  Do we have enough people
>>> with sufficient knowledge and willingness to be able to make all
>>> that happen?  I don't think we do, and I don't see that there's any
>>> funding out there to make such a project happen, which would make it
>>> a volunteer/spare time effort.
>>
>> +1 for this solution, even if this means more work to get from the
>> ground.
>>
>> Do we really need full hotplug support in the DRM API and Xorg? I mean
>> it would really be nice if Xorg detected a newly registered device, but
>> as a start it should be sufficient when Xorg detects what's there when
>> it starts, no?
>
> Since fbdev and fbcon sit on top of drm to provide the console
> currently I'd also expect some fun with them. How do I get a console
> if I have no outputs at boot, but I have crtcs? do I just wait around
> until an output appears.
>
> There are a number of issues with hotplugging encoders and connectors
> at runtime, when really the SoC/board designer knows what it provides
> and should be able to tell the driver in some fashion.
>
> The main problems when I played with hot adding eDP on Intel last
> time, are we have grouping of 

[ANNOUNCE] libdrm 2.4.46

[Dave Airlie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Release because I want the cursor ioctls released,
also haswell and radeon ids.

Alex Deucher (3):
  radeon: add CIK chip families
  radeon: add Bonaire pci ids
  radeon: add kabini pci ids

Damien Lespiau (3):
  intel/aub: Sync the AUB defines with mesa's
  intel/aub: Return early if we disable aub dumps
  intel/aub: Implement a way to specify the output .aub filename

Dave Airlie (2):
  drm: add hotspot cursor interface support.
  libdrm: bump to 2.4.46

Mark Kettenis (1):
  radeon: correct RADEON_GEM_WAIT_IDLE use

Rob Clark (3):
  freedreno: add handle and name tracking
  freedreno: add some asserts
  freedreno: also remove from name table on bo delete

Rodrigo Vivi (2):
  intel: Fix Haswell GT3 names.
  intel: Adding more reserved PCI IDs for Haswell.

Ville Syrj?l? (1):
  modetest: Make RGB565 pwetty too

git tag: libdrm-2.4.46

http://dri.freedesktop.org/libdrm/libdrm-2.4.46.tar.bz2
MD5:  9cba217fd3daa10b1d052ec60d3aa7d5  libdrm-2.4.46.tar.bz2
SHA1: b3a0fac0c8ef9110dce32feb8004f53f0081dea4  libdrm-2.4.46.tar.bz2
SHA256: 33cf320dad4e8060768714792e12643ddf6756a719d262ba7d60b39c2b2650f1  
libdrm-2.4.46.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.46.tar.gz
MD5:  b454a43366eb386294f87a5cd16699e6  libdrm-2.4.46.tar.gz
SHA1: dbd99aca49db5fa87e49fec5fa3d2eba5a781185  libdrm-2.4.46.tar.gz
SHA256: 75dda05aa7717594d48f215d598525ffb7d4c60f60cc3fc2084672ca5d3ae039  
libdrm-2.4.46.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJR0o14AAoJEAx081l5xIa+QOAP/A9wAIljpxy6KGYC7LutVzTy
oncZk3ivkKI0a+rAqXP5DrV+Fu9Gkmx/rSNrHw/VwdY83EenRbyijIQk4QQjj0AN
ibPWyWTIlc+sdJoXBEieqWdSxZLqCgT3GIhaBmnkVBEPyse2qu5ob1MZQYX62tKJ
MZ45OpW8glhEvBdKrcvN1wfe710MH1RYwwgIrkmD1RPuCFyhIOnkj/hMICCnBOil
vkng1tW7TitW84YFsUDu4rV6iug9OSnIvNNN/j810QREGyNdhPqPV5rhv8zncjRk
cg3nFmcjyTnzHX0Eq1gHQenam0ocHvfGuknQ2tiIaH4MiN7TIg+39NK8Zi4OvAMj
DfxlYHna3xBpnhTKuyRkG/1/BrUFr1f8vnw2yqV5qUBJeZ5uZIEt7rAGZcMOkKuE
LCA9boM1KgNaAG4i6NPaWJwavM25DFYDV/I6Xy8xeFPvChslc7VBmei9B53NNAx8
k3yyz0+LICjJo8XKZouueK6UaZFE7+9lHhLp8qxXMqLH/cErdUirUEDUvB3YdUEI
bjq41nMsIYnBCIdkNpiUQVUP5rGeUEsninZO7nfVRV6sQXVI5rsb+iob6aA1rwJM
am+/3vppn1oTjrvFxywY6ctBIu1Ko+DCHmo/1WpdNNnMIXRr24FMXYrkUcORrp7Z
ZQm76FmMzsSxgCv2/iUT
=esMI
-END PGP SIGNATURE-

[PATCH v3 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Seung-Woo Kim]

If raw_edid of drm_edid_block_vaild() is null, it will crash, so
checking in bad label is removed and instead assertion is added at
the top of the function.
The type of return for the function is bool, so it fixes to return
true and false instead of 1 and 0.

Signed-off-by: Seung-Woo Kim 
Signed-off-by: Kyungmin Park 
---
change from v2
- check result of WARN_ON() as Ville's comment
chages from v1
- NULL checking is replaced with WARN_ON() as Daniel commented
- all return value is replaced as true/false as Chris and Daniel commented

 drivers/gpu/drm/drm_edid.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2dc1a60..95d6f4b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -968,6 +968,9 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid)
u8 csum = 0;
struct edid *edid = (struct edid *)raw_edid;

+   if (WARN_ON(!raw_edid))
+   return false;
+
if (edid_fixup > 8 || edid_fixup < 0)
edid_fixup = 6;

@@ -1010,15 +1013,15 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid)
break;
}

-   return 1;
+   return true;

 bad:
-   if (raw_edid && print_bad_edid) {
+   if (print_bad_edid) {
printk(KERN_ERR "Raw EDID:\n");
print_hex_dump(KERN_ERR, " \t", DUMP_PREFIX_NONE, 16, 1,
   raw_edid, EDID_LENGTH, false);
}
-   return 0;
+   return false;
 }
 EXPORT_SYMBOL(drm_edid_block_valid);

-- 
1.7.4.1

[PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Seung-Woo Kim]

Hello Ville,

Thanks for comment.

On 2013? 07? 02? 17:29, Ville Syrj?l? wrote:
> On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote:
>> If raw_edid of drm_edid_block_vaild() is null, it will crash, so
>> checking in bad label is removed and instead assertion is added at
>> the top of the function.
>> The type of return for the function is bool, so it fixes to return
>> true and false instead of 1 and 0.
>>
>> Signed-off-by: Seung-Woo Kim 
>> Signed-off-by: Kyungmin Park 
>> ---
>> chages from v1
>> - NULL checking is replaced with WARN_ON() as Daniel commented
>> - all return value is replaced as true/false as Chris and Daniel commented
>>
>>  drivers/gpu/drm/drm_edid.c |8 +---
>>  1 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 2dc1a60..1117f02 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -968,6 +968,8 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
>> print_bad_edid)
>>  u8 csum = 0;
>>  struct edid *edid = (struct edid *)raw_edid;
>>  
>> +WARN_ON(!raw_edid);
>> +
> 
> I don't see this buying us anything. All you get is two backtraces
> instead of one.
> 
> if (WARN_ON(!raw_edid))
>   return false;
> 
> would make more sense if we want tolerate programmer errors a bit
> better. I'm not a huge fan of such defensive programming though
> since it tends to make it less clear what the function actually
> expects from you. But here the WARN_ON() would at least make it
> clear that it's not meant to happen.
> 

Ok, it looks better than just WARN_ON(). I'll updated patch as you
commented.

Best Regards,
- Seung-Woo Kim

> 
>>  if (edid_fixup > 8 || edid_fixup < 0)
>>  edid_fixup = 6;
>>  
>> @@ -1010,15 +1012,15 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, 
>> bool print_bad_edid)
>>  break;
>>  }
>>  
>> -return 1;
>> +return true;
>>  
>>  bad:
>> -if (raw_edid && print_bad_edid) {
>> +if (print_bad_edid) {
>>  printk(KERN_ERR "Raw EDID:\n");
>>  print_hex_dump(KERN_ERR, " \t", DUMP_PREFIX_NONE, 16, 1,
>> raw_edid, EDID_LENGTH, false);
>>  }
>> -return 0;
>> +return false;
>>  }
>>  EXPORT_SYMBOL(drm_edid_block_valid);
>>  
>> -- 
>> 1.7.4.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Seung-Woo Kim
Samsung Software R Center
--

PCI device IDs for device needing the i915 invert_brightness quirk

[Pedro Ângelo]

Dear all,

Recently I've come across this article about a probable fix for my 
laptop's black screen on boot:

http://people.skolelinux.org/pere/blog/Fixing_the_Linux_black_screen_of_death_on_machines_with_Intel_HD_video.html

I've tried the fix and it works perfectly so I'm contacting you as 
directed in the above article to send the PCI device IDs of the 
integrated graphics card of the laptop in question for future inclusion 
in the driver.

The laptop is an HP Envy 14 2020, the output of lspci -vvnn for the 
graphics card is:



00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd 
Generation Core
Processor Family Integrated Graphics Controller [8086:0116] (rev 09) 
(prog-if 00
  [VGA controller])
 Subsystem: Hewlett-Packard Company Device [103c:3385]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Step
ping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR-  [disabled]T
 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
 Address: feeff00c  Data: 41c1
 Capabilities: [d0] Power Management version 2
 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [a4] PCI Advanced Features
 AFCap: TP+ FLR+
 AFCtrl: FLR-
 AFStatus: TP-
 Kernel driver in use: i915



Best regards,
Pedro ?ngelo

[PATCH] drm/prime: fix up handle_to_fd ioctl return value

[YoungJun Cho]

Dear Daniel,

On Jul 2, 2013 5:14 PM, "Daniel Vetter"  wrote:
>
> On Tue, Jul 02, 2013 at 04:55:16PM +0900, YoungJun Cho wrote:
> > Dear Daniel,
> >
> > On Jul 2, 2013 4:19 PM, "Daniel Vetter"  wrote:
> > >
> > > In
> > >
> > > commit da34242e5e0638312130f5bd5d2d277afbc6f806
> > > Author: YoungJun Cho 
> > > Date:   Wed Jun 26 10:21:42 2013 +0900
> > >
> > > drm/prime: add return check for dma_buf_fd
> > >
> > > the failure case handling was fixed up. But in the case when we
> > > already had the buffer exported it changed the return value:
> > > Previously we've return 0 on success, now we return the fd.
> > >
> > > This ABI change has been caught by
i-g-t/prime_self_import/with_one_bo.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66436
> > > Cc: YoungJun Cho 
> > > Cc: Seung-Woo Kim 
> > > Cc: Kyungmin Park 
> > > Tested-by: lu hua 
> > > Signed-off-by: Daniel Vetter 

Reviewed-by: YoungJun Cho 

Thank you and best regards YJ

> > > ---
> > >  drivers/gpu/drm/drm_prime.c |7 +--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > index 52709f2..1e0de41 100644
> > > --- a/drivers/gpu/drm/drm_prime.c
> > > +++ b/drivers/gpu/drm/drm_prime.c
> > > @@ -347,10 +347,13 @@ int drm_gem_prime_handle_to_fd(struct drm_device
> > *dev,
> > >  out_have_obj:
> > > get_dma_buf(dmabuf);
> > > ret = dma_buf_fd(dmabuf, flags);
> > > -   if (ret < 0)
> > > +   if (ret < 0) {
> > > dma_buf_put(dmabuf);
> > > -   else
> > > +   } else {
> > > *prime_fd = ret;
> > > +   ret = 0;
> > > +   }
> > > +
> > > goto out;
> > >
> > >  fail_rm_handle:
> > > --
> > > 1.7.10.4
> > >
> > >
> >
> > Right, that's my mistake.
> > I'll pay attention from now on!
> >
> > Thank you & best regards YJ
>
> Reviewed-by ?
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130702/7d82fb07/attachment.html>

[PATCH] drm/prime: fix up handle_to_fd ioctl return value

[YoungJun Cho]

Dear Daniel,

On Jul 2, 2013 4:19 PM, "Daniel Vetter"  wrote:
>
> In
>
> commit da34242e5e0638312130f5bd5d2d277afbc6f806
> Author: YoungJun Cho 
> Date:   Wed Jun 26 10:21:42 2013 +0900
>
> drm/prime: add return check for dma_buf_fd
>
> the failure case handling was fixed up. But in the case when we
> already had the buffer exported it changed the return value:
> Previously we've return 0 on success, now we return the fd.
>
> This ABI change has been caught by i-g-t/prime_self_import/with_one_bo.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66436
> Cc: YoungJun Cho 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Tested-by: lu hua 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_prime.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 52709f2..1e0de41 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -347,10 +347,13 @@ int drm_gem_prime_handle_to_fd(struct drm_device
*dev,
>  out_have_obj:
> get_dma_buf(dmabuf);
> ret = dma_buf_fd(dmabuf, flags);
> -   if (ret < 0)
> +   if (ret < 0) {
> dma_buf_put(dmabuf);
> -   else
> +   } else {
> *prime_fd = ret;
> +   ret = 0;
> +   }
> +
> goto out;
>
>  fail_rm_handle:
> --
> 1.7.10.4
>
>

Right, that's my mistake.
I'll pay attention from now on!

Thank you & best regards YJ
___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130702/35fe13c8/attachment.html>

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

[Alex Deucher]

On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz  wrote:
> Alex Deucher wrote, on 07/02/2013 21:46:
>> On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz  wrote:
>>> With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics (ATI
>>> RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon HD 
>>> 5400
>>> Series]) uvd seems to be broken.
>>>
>>> The new firware files are installed in /lib/firmware/radeon:
>>>
>>> sha1 hashes
>>> 3142a64061ade6032c95ed948c85b15dd0ae46be  CEDAR_me.bin
>>> a92856a4fa16926e2451a6335da7e20f01fde210  CEDAR_pfp.bin
>>> 644b29756636687ad31a49da4aa3ed85dcedecdb  CEDAR_rlc.bin
>>> 992d49518d3936986b5ce3ddb0d9bbd75135bb8f  CYPRESS_uvd.bin
>>> 3e04529600d666ddb2f2f83bb0112d4fab516c04  R600_rlc.bin
>>>
>>> The system boots without initial ram disk.
>>
>> Make sure your system is using the latest CEDAR_rlc.bin as well.
>>
>> Alex
>>
> Thanks for the hint, Alex. Actually I took the files today from your 
> repository
> at http://people.freedesktop.org/~agd5f/radeon_ucode/ and checked them against
> the ones downloaded from
> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git .

Make sure that your kernel is actually using the new ones.

Alex

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

[Jörg-Volker Peetz]

With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics (ATI
RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon HD 5400
Series]) uvd seems to be broken.

The new firware files are installed in /lib/firmware/radeon:

sha1 hashes
3142a64061ade6032c95ed948c85b15dd0ae46be  CEDAR_me.bin
a92856a4fa16926e2451a6335da7e20f01fde210  CEDAR_pfp.bin
644b29756636687ad31a49da4aa3ed85dcedecdb  CEDAR_rlc.bin
992d49518d3936986b5ce3ddb0d9bbd75135bb8f  CYPRESS_uvd.bin
3e04529600d666ddb2f2f83bb0112d4fab516c04  R600_rlc.bin

The system boots without initial ram disk.

In dmesg it says:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
VGA switcheroo: detected switching method \_SB_.PCI0.AGP_.VGA_.ATPX handle
[drm] initializing kernel modesetting (RS880 0x1002:0x9712 0x103C:0x1443).
[drm] register mmio base: 0xF040
[drm] register mmio size: 65536
ATOM BIOS: HP_JoYaHeWi
radeon :01:05.0: VRAM: 320M 0xC000 - 0xD3FF (320M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=320M, BAR=256M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 3960190 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 320M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and
cpu addr 0x880215cb6c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and
cpu addr 0x880215cb6c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
ACPI: Battery Slot [BAT0] (battery present)
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm] Enabling audio support
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] radeon atom DIG backlight initialized
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   LVDS-1
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] LCD1: INTERNAL_KLDSCP_LVTMA
[drm] radeon: power management initialized
tsc: Refined TSC clocksource calibration: 2793.006 MHz
Switching to clocksource tsc
[drm] fb mappable at 0xD0142000
[drm] vram apper at 0xD000
[drm] size 5787648
[drm] fb depth is 24
[drm]pitch is 6400
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 200x56
radeon :01:05.0: fb0: radeondrmfb frame buffer device
radeon :01:05.0: registered panic notifier
[drm] Initialized radeon 2.33.0 20080528 for :01:05.0 on minor 0
radeon :02:00.0: enabling device ( -> 0003)
[drm] initializing kernel modesetting (CEDAR 0x1002:0x68E0 0x103C:0x1443).
[drm] register mmio base: 0xF020
[drm] register mmio size: 131072
vga_switcheroo: enabled
ATPX version 1
ATOM BIOS: HP
radeon :02:00.0: VRAM: 512M 0x - 0x1FFF (512M 
used)
radeon :02:00.0: GTT: 512M 0x2000 - 0x3FFF
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 64bits DDR
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
radeon :02:00.0: 880215ec6800 unpin not necessary
radeon :02:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and
cpu addr 0xc900030ba418
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] Loading CEDAR Microcode
[drm] PCIE GART of 512M enabled (table at 0x0004).
radeon :02:00.0: WB enabled
radeon :02:00.0: fence driver on ring 0 use gpu addr 0x2c00 and
cpu addr 0x880215b24c00
radeon :02:00.0: fence driver on ring 3 use gpu addr 0x2c0c and
cpu addr 0x880215b24c0c
radeon :02:00.0: fence driver on ring 5 use gpu addr 0x0015e418 and
cpu addr 0xc9000391c418
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
radeon :02:00.0: irq 43 for MSI/MSI-X
radeon :02:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset 

[PATCH] drm/exynos: Add missing includes

[Mark Brown]

On Tue, Jul 02, 2013 at 09:21:32PM +0900, Inki Dae wrote:

> > Ensure that all externally accessed functions are correctly prototyped
> > when defined in each file by making sure the headers with the protoypes
> > are included in the file with the definition.

> I don't see why this patch is needed. it seems like including unnecessary
> headers so it makes the code size enlarged.

Well, aside from it being basic good practice and allowing the compiler
to check for errors in the prototypes this is also something that sparse
warns about.

If the resulting binary size is changed by having the headers included
then that indicates a bug in the headers - they *really* shouldn't be
doing anything substantial here.  None of the headers in question looked
at all worrying.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130702/d4c8cc03/attachment-0001.pgp>

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

[Alex Deucher]

On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz  wrote:
> With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics (ATI
> RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon HD 
> 5400
> Series]) uvd seems to be broken.
>
> The new firware files are installed in /lib/firmware/radeon:
>
> sha1 hashes
> 3142a64061ade6032c95ed948c85b15dd0ae46be  CEDAR_me.bin
> a92856a4fa16926e2451a6335da7e20f01fde210  CEDAR_pfp.bin
> 644b29756636687ad31a49da4aa3ed85dcedecdb  CEDAR_rlc.bin
> 992d49518d3936986b5ce3ddb0d9bbd75135bb8f  CYPRESS_uvd.bin
> 3e04529600d666ddb2f2f83bb0112d4fab516c04  R600_rlc.bin
>
> The system boots without initial ram disk.

Make sure your system is using the latest CEDAR_rlc.bin as well.

Alex


>
> In dmesg it says:
>
> [drm] Initialized drm 1.1.0 20060810
> [drm] radeon kernel modesetting enabled.
> VGA switcheroo: detected switching method \_SB_.PCI0.AGP_.VGA_.ATPX handle
> [drm] initializing kernel modesetting (RS880 0x1002:0x9712 0x103C:0x1443).
> [drm] register mmio base: 0xF040
> [drm] register mmio size: 65536
> ATOM BIOS: HP_JoYaHeWi
> radeon :01:05.0: VRAM: 320M 0xC000 - 0xD3FF (320M 
> used)
> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
> [drm] Detected VRAM RAM=320M, BAR=256M
> [drm] RAM width 32bits DDR
> [TTM] Zone  kernel: Available graphics memory: 3960190 kiB
> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [TTM] Initializing pool allocator
> [TTM] Initializing DMA pool allocator
> [drm] radeon: 320M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] Loading RS780 Microcode
> [drm] PCIE GART of 512M enabled (table at 0xC004).
> radeon :01:05.0: WB enabled
> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
> and
> cpu addr 0x880215cb6c00
> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
> and
> cpu addr 0x880215cb6c0c
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] Driver supports precise vblank timestamp query.
> [drm] radeon: irq initialized.
> radeon :01:05.0: setting latency timer to 64
> ACPI: Battery Slot [BAT0] (battery present)
> [drm] ring test on 0 succeeded in 1 usecs
> [drm] ring test on 3 succeeded in 1 usecs
> [drm] Enabling audio support
> [drm] ib test on ring 0 succeeded in 0 usecs
> [drm] ib test on ring 3 succeeded in 0 usecs
> [drm] radeon atom DIG backlight initialized
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   VGA-1
> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> [drm]   Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [drm] Connector 1:
> [drm]   LVDS-1
> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
> [drm]   Encoders:
> [drm] LCD1: INTERNAL_KLDSCP_LVTMA
> [drm] radeon: power management initialized
> tsc: Refined TSC clocksource calibration: 2793.006 MHz
> Switching to clocksource tsc
> [drm] fb mappable at 0xD0142000
> [drm] vram apper at 0xD000
> [drm] size 5787648
> [drm] fb depth is 24
> [drm]pitch is 6400
> fbcon: radeondrmfb (fb0) is primary device
> Console: switching to colour frame buffer device 200x56
> radeon :01:05.0: fb0: radeondrmfb frame buffer device
> radeon :01:05.0: registered panic notifier
> [drm] Initialized radeon 2.33.0 20080528 for :01:05.0 on minor 0
> radeon :02:00.0: enabling device ( -> 0003)
> [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E0 0x103C:0x1443).
> [drm] register mmio base: 0xF020
> [drm] register mmio size: 131072
> vga_switcheroo: enabled
> ATPX version 1
> ATOM BIOS: HP
> radeon :02:00.0: VRAM: 512M 0x - 0x1FFF (512M 
> used)
> radeon :02:00.0: GTT: 512M 0x2000 - 0x3FFF
> [drm] Detected VRAM RAM=512M, BAR=256M
> [drm] RAM width 64bits DDR
> [drm] radeon: 512M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> radeon :02:00.0: 880215ec6800 unpin not necessary
> radeon :02:00.0: fence driver on ring 5 use gpu addr 0x0005c418 
> and
> cpu addr 0xc900030ba418
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
> [drm] Loading CEDAR Microcode
> [drm] PCIE GART of 512M enabled (table at 0x0004).
> radeon :02:00.0: WB enabled
> radeon :02:00.0: fence driver on ring 0 use gpu addr 0x2c00 
> and
> cpu addr 0x880215b24c00
> radeon :02:00.0: fence driver on ring 3 use gpu addr 0x2c0c 
> and
> cpu addr 0x880215b24c0c
> radeon :02:00.0: fence driver on ring 5 use gpu addr 0x0015e418 
> and
> cpu addr 0xc9000391c418
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] Driver supports precise vblank timestamp query.
> radeon :02:00.0: irq 43 for MSI/MSI-X
> 

3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

[Alex Deucher]

On Tue, Jul 2, 2013 at 2:44 PM, Justin Piszcz  
wrote:
>
>
> -Original Message-
> From: Alex Deucher [mailto:alexdeucher at gmail.com]
> Sent: Tuesday, July 02, 2013 2:36 PM
> To: Justin Piszcz
> Cc: linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org
> Subject: Re: 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error
> initializing UVD (-1).
>
>> The screen goes black for ~5 seconds and then come back on.
>> Not sure if this has been reported or not (w/CEDAR chipset) but FYI.
>
> Make sure you have the the latest CEDAR_rlc.bin in addition to
> CYPRESS_uvd.bin and make sure the latest images are available in your
> initrd or kernel image, etc.
>
> Alex
>
> --
>
> Hi,
>
> Even with the latest (confirmed below) and built-in to the kernel:
>
> $ git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git
> Cloning into 'linux-firmware'...
> remote: Counting objects: 2210, done.
> remote: Compressing objects: 100% (1102/1102), done.
> remote: Total 2210 (delta 1123), reused 2113 (delta 1073)
> Receiving objects: 100% (2210/2210), 39.84 MiB | 6.49 MiB/s, done.
> Resolving deltas: 100% (1123/1123), done.
> $ date
> Tue Jul  2 14:39:19 EDT 2013
>
> 2b244d41832f46382bfbb8994522dcdd  d/linux-firmware/radeon/CEDAR_me.bin
> 23915e382ea0d2f2491a19146ca3001c  d/linux-firmware/radeon/CEDAR_pfp.bin
> e8770d3d588f24dc6f1a8609c9db3467  d/linux-firmware/radeon/CEDAR_rlc.bin
> fb23b281dcc94a035d374e709c9842bd  d/linux-firmware/radeon/CYPRESS_uvd.bin
>
> Current system firmware (/lib/firmware/radeon):
> $ for i in $CONFIG_EXTRA_FIRMWARE; do md5sum $i; done
> 2b244d41832f46382bfbb8994522dcdd  radeon/CEDAR_me.bin
> 23915e382ea0d2f2491a19146ca3001c  radeon/CEDAR_pfp.bin
> e8770d3d588f24dc6f1a8609c9db3467  radeon/CEDAR_rlc.bin
> fb23b281dcc94a035d374e709c9842bd  radeon/CYPRESS_uvd.bin
>
> CONFIG_EXTRA_FIRMWARE="radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin
> radeon/CEDAR_rlc.bin radeon/CYPRESS_uvd.bin"
>
> Same issue.

Please open a bug (product: DRI, component: DRM/Radeon):
https://bugs.freedesktop.org
and attach your dmesg output and xorg log.

Alex

Best practice device tree design for display subsystems/DRM

[Daniel Drake]

On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
 wrote:
> I am against a super node which contains lcd and dcon/ire nodes. You can
> enable those devices on a per board basis. We add them to dove.dtsi but
> disable them by default (status = "disabled").
>
> The DRM driver itself should get a video-card node outside of
> soc/internal-regs where you can put e.g. video memory hole (or video
> mem size if it will be taken from RAM later)

For completeness of the discussion, and my understanding too, can you
explain your objections to the display super-node in a bit more
detail?

Thanks
Daniel

3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

[Justin Piszcz]

-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com] 
Sent: Tuesday, July 02, 2013 2:36 PM
To: Justin Piszcz
Cc: linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org
Subject: Re: 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error
initializing UVD (-1).

> The screen goes black for ~5 seconds and then come back on.
> Not sure if this has been reported or not (w/CEDAR chipset) but FYI.

Make sure you have the the latest CEDAR_rlc.bin in addition to
CYPRESS_uvd.bin and make sure the latest images are available in your
initrd or kernel image, etc.

Alex

--

Hi,

Even with the latest (confirmed below) and built-in to the kernel:

$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git
Cloning into 'linux-firmware'...
remote: Counting objects: 2210, done.
remote: Compressing objects: 100% (1102/1102), done.
remote: Total 2210 (delta 1123), reused 2113 (delta 1073)
Receiving objects: 100% (2210/2210), 39.84 MiB | 6.49 MiB/s, done.
Resolving deltas: 100% (1123/1123), done.
$ date
Tue Jul  2 14:39:19 EDT 2013

2b244d41832f46382bfbb8994522dcdd  d/linux-firmware/radeon/CEDAR_me.bin
23915e382ea0d2f2491a19146ca3001c  d/linux-firmware/radeon/CEDAR_pfp.bin
e8770d3d588f24dc6f1a8609c9db3467  d/linux-firmware/radeon/CEDAR_rlc.bin
fb23b281dcc94a035d374e709c9842bd  d/linux-firmware/radeon/CYPRESS_uvd.bin

Current system firmware (/lib/firmware/radeon):
$ for i in $CONFIG_EXTRA_FIRMWARE; do md5sum $i; done
2b244d41832f46382bfbb8994522dcdd  radeon/CEDAR_me.bin
23915e382ea0d2f2491a19146ca3001c  radeon/CEDAR_pfp.bin
e8770d3d588f24dc6f1a8609c9db3467  radeon/CEDAR_rlc.bin
fb23b281dcc94a035d374e709c9842bd  radeon/CYPRESS_uvd.bin

CONFIG_EXTRA_FIRMWARE="radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin
radeon/CEDAR_rlc.bin radeon/CYPRESS_uvd.bin"

Same issue.

Justin.

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

[Ville Syrjälä]

On Tue, Jul 02, 2013 at 07:59:22PM +0900, Seung-Woo Kim wrote:
> From: YoungJun Cho 
> 
> When drm iommu is not supported, buf->pages has to be allocated
> and assigned to phys_to_page() result, which type is struct page *.
> So it is sufficient to allocate buf->pages with multiple struct
> page pointer size.
> 
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_buf.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
> b/drivers/gpu/drm/exynos/exynos_drm_buf.c
> index 22865ba..3200622 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
> @@ -57,7 +57,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
>   dma_addr_t start_addr;
>   unsigned int i = 0;
>  
> - buf->pages = kzalloc(sizeof(struct page) * nr_pages,
> + buf->pages = kzalloc(sizeof(struct page *) * nr_pages,
>   GFP_KERNEL);

Looks like a prime candidate for kcalloc()

>   if (!buf->pages) {
>   DRM_ERROR("failed to allocate pages.\n");
> -- 
> 1.7.9.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

[Alex Deucher]

On Tue, Jul 2, 2013 at 2:33 PM, Justin Piszcz  
wrote:
> Hello,
>
> I use an ATI graphics card (PCI-e x1) for a server:
> Card: [AMD/ATI] Park [Mobility Radeon HD 5430]
>
> I upgraded my kernel from 3.9.x to 3.10, after rebooting I found the driver
> now wants a new firmware:
> radeon :05:00.0: radeon_uvd: Can't load firmware
> "radeon/CYPRESS_uvd.bin"
>
> I pulled the latest firmware down (and also updated the others) and
> rebooted:
> CONFIG_EXTRA_FIRMWARE="radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin
> radeon/CEDAR_rlc.bin radeon/CYPRESS_uvd.bin"
>
> Then have this issue:
> [drm] radeon: irq initialized.
> [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).
>
> The screen goes black for ~5 seconds and then come back on.
> Not sure if this has been reported or not (w/CEDAR chipset) but FYI.

Make sure you have the the latest CEDAR_rlc.bin in addition to
CYPRESS_uvd.bin and make sure the latest images are available in your
initrd or kernel image, etc.

Alex


>
> Kernel config:
> http://home.comcast.net/~jpiszcz/20130702/config-3.10-4.txt
>
> Full dmesg:
> http://home.comcast.net/~jpiszcz/20130702/full-dmesg.txt
>
> Possibly related:
> http://lists.opensuse.org/opensuse-bugs/2013-06/msg00053.html
> https://bugzilla.novell.com/show_bug.cgi?id=822777
> https://bugzilla.novell.com/show_bug.cgi?id=822777#c0
> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg38066.html
> https://bugs.freedesktop.org/show_bug.cgi?id=63935
>
> Snippet:
> [2.033535] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [3.053742] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [4.073985] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [5.094192] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [6.114405] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [7.134611] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [8.154824] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [9.175044] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   10.195251] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   11.215464] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   11.235537] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
> [   11.235607] [drm:evergreen_startup] *ERROR* radeon: error initializing
> UVD (-1).
>
> Justin.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

[Justin Piszcz]

Hello,

I use an ATI graphics card (PCI-e x1) for a server:
Card: [AMD/ATI] Park [Mobility Radeon HD 5430]

I upgraded my kernel from 3.9.x to 3.10, after rebooting I found the driver
now wants a new firmware:
radeon :05:00.0: radeon_uvd: Can't load firmware
"radeon/CYPRESS_uvd.bin"

I pulled the latest firmware down (and also updated the others) and
rebooted:
CONFIG_EXTRA_FIRMWARE="radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin
radeon/CEDAR_rlc.bin radeon/CYPRESS_uvd.bin"

Then have this issue:
[drm] radeon: irq initialized.
[drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

The screen goes black for ~5 seconds and then come back on.
Not sure if this has been reported or not (w/CEDAR chipset) but FYI.

Kernel config:
http://home.comcast.net/~jpiszcz/20130702/config-3.10-4.txt

Full dmesg:
http://home.comcast.net/~jpiszcz/20130702/full-dmesg.txt

Possibly related:
http://lists.opensuse.org/opensuse-bugs/2013-06/msg00053.html
https://bugzilla.novell.com/show_bug.cgi?id=822777
https://bugzilla.novell.com/show_bug.cgi?id=822777#c0
http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg38066.html
https://bugs.freedesktop.org/show_bug.cgi?id=63935

Snippet:
[2.033535] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
reset the VCPU!!!
[3.053742] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
reset the VCPU!!!
[4.073985] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
reset the VCPU!!!
[5.094192] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
reset the VCPU!!!
[6.114405] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
reset the VCPU!!!
[7.134611] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
reset the VCPU!!!
[8.154824] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
reset the VCPU!!!
[9.175044] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
reset the VCPU!!!
[   10.195251] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
reset the VCPU!!!
[   11.215464] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to
reset the VCPU!!!
[   11.235537] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[   11.235607] [drm:evergreen_startup] *ERROR* radeon: error initializing
UVD (-1).

Justin.

[PATCH 1/6] drm: make drm_mm_init() return void

[Dave Airlie]

On Tue, Jul 2, 2013 at 5:22 AM, Daniel Vetter  wrote:
> On Mon, Jul 01, 2013 at 08:32:58PM +0200, David Herrmann wrote:
>> There is no reason to return "int" as this function never fails.
>> Furthermore, several drivers (ast, sis) already depend on this.
>>
>> Signed-off-by: David Herrmann 
>
> Back when I've reworked drm_mm I was still a rookie and didn't want to
> touch all drivers, hence why I've left the int return type. Good riddance
> to that!
>
> Reviewed-by: Daniel Vetter 

Thanks, I've stuck this in -next as it looks like a nice cleanup I'd like now.

Dave.

[PATCH] drm/nouveau: handle framebuffer pinning correctly

[Maarten Lankhorst]

Unpinning wasn't always handled correctly. The crtc_disable
and nouveau_fbcon_destroy calls needed to unpin but didn't,
resulting in a pin leak.

While debugging this I found some leaks in the error paths of
nouveau_user_framebuffer_create, so I fixed those too.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_display.c |   15 ++-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |7 +++
 drivers/gpu/drm/nouveau/nv50_display.c|   13 +
 3 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 165f04a..599abc9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -142,17 +142,22 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
if (!gem)
return ERR_PTR(-ENOENT);

+   ret = -ENOMEM;
nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
if (!nouveau_fb)
-   return ERR_PTR(-ENOMEM);
+   goto err_unref;

ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, 
nouveau_gem_object(gem));
-   if (ret) {
-   drm_gem_object_unreference(gem);
-   return ERR_PTR(ret);
-   }
+   if (ret)
+   goto err;

return _fb->base;
+
+err:
+   kfree(nouveau_fb);
+err_unref:
+   drm_gem_object_unreference(gem);
+   return ERR_PTR(ret);
 }

 static const struct drm_mode_config_funcs nouveau_mode_config_funcs = {
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index ecbfe69..839b7e7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -385,6 +385,7 @@ out_unlock:
mutex_unlock(>struct_mutex);
if (chan)
nouveau_bo_vma_del(nvbo, >nouveau_fb.vma);
+   nouveau_bo_unmap(nvbo);
 out_unpin:
nouveau_bo_unpin(nvbo);
 out_unref:
@@ -415,6 +416,12 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct 
nouveau_fbdev *fbcon)
}

if (nouveau_fb->nvbo) {
+   struct drm_crtc *crtc;
+
+   list_for_each_entry(crtc, >mode_config.crtc_list, head)
+   if (nouveau_framebuffer(crtc->fb) == nouveau_fb)
+   nouveau_bo_unpin(nouveau_fb->nvbo);
+
nouveau_bo_unmap(nouveau_fb->nvbo);
nouveau_bo_vma_del(nouveau_fb->nvbo, _fb->vma);
nouveau_bo_unpin(nouveau_fb->nvbo);
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index c60bae1..05c9667 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -1272,6 +1272,18 @@ nv50_crtc_gamma_set(struct drm_crtc *crtc, u16 *r, u16 
*g, u16 *b,
 }

 static void
+nv50_crtc_disable(struct drm_crtc *crtc)
+{
+   struct nouveau_framebuffer *nv_fb;
+
+   if (!crtc->fb)
+   return;
+
+   nv_fb = nouveau_framebuffer(crtc->fb);
+   nouveau_bo_unpin(nv_fb->nvbo);
+}
+
+static void
 nv50_crtc_destroy(struct drm_crtc *crtc)
 {
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
@@ -1294,6 +1306,7 @@ nv50_crtc_destroy(struct drm_crtc *crtc)
 }

 static const struct drm_crtc_helper_funcs nv50_crtc_hfunc = {
+   .disable = nv50_crtc_disable,
.dpms = nv50_crtc_dpms,
.prepare = nv50_crtc_prepare,
.commit = nv50_crtc_commit,

[PATCH] drm: drm init call takes large time

[Ville Syrjälä]

On Sun, Jun 30, 2013 at 05:41:59AM +0500, Abbas Raza wrote:
> From: Abbas Raza 
> 
> DRM_INFO calls in the drm init routines are causing a large delay at boot time
> due to which imx_drm_init call average takes around 26 ms. Changing DRM_INFO 
> to
> DRM_DEBUG reduces startup time to < 3ms.

Serial console enabled?

Not that I think these printks are particularly useful...

> Signed-off-by: Abbas Raza 
> CC: David Airlie 
> Acked-by: Dmitry Eremin-Solenikov 
> ---
>  drivers/gpu/drm/drm_irq.c  | 6 +++---
>  drivers/gpu/drm/drm_platform.c | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c798eea..782f5ff 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -252,13 +252,13 @@ int drm_vblank_init(struct drm_device *dev, int 
> num_crtcs)
>   if (!dev->_vblank_time)
>   goto err;
>  
> - DRM_INFO("Supports vblank timestamp caching Rev 1 (10.10.2010).\n");
> + DRM_DEBUG("Supports vblank timestamp caching Rev 1 (10.10.2010).\n");
>  
>   /* Driver specific high-precision vblank timestamping supported? */
>   if (dev->driver->get_vblank_timestamp)
> - DRM_INFO("Driver supports precise vblank timestamp query.\n");
> + DRM_DEBUG("Driver supports precise vblank timestamp query.\n");
>   else
> - DRM_INFO("No driver support for vblank timestamp query.\n");
> + DRM_DEBUG("No driver support for vblank timestamp query.\n");
>  
>   /* Zero per-crtc vblank stuff */
>   for (i = 0; i < num_crtcs; i++) {
> diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> index 82431dc..7649963 100644
> --- a/drivers/gpu/drm/drm_platform.c
> +++ b/drivers/gpu/drm/drm_platform.c
> @@ -92,7 +92,7 @@ int drm_get_platform_dev(struct platform_device *platdev,
>  
>   mutex_unlock(_global_mutex);
>  
> - DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n",
> + DRM_DEBUG("Initialized %s %d.%d.%d %s on minor %d\n",
>driver->name, driver->major, driver->minor, driver->patchlevel,
>driver->date, dev->primary->index);
>  
> -- 
> 1.8.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[Bug 66317] FlightGear 2.10 crashes on load

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

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

Marc Dietrich  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #2 from Marc Dietrich  ---
DRAW_USE_LLVM=0 helped, release_33 also works

wasted a week of bisecting, just to find out that I configured my llvm branch
wrong (I used --enable-targets=r600). It turned out that you need at least
--enable-targets=host,r600 or you will get the crash above. Maybe mesa's
configure should check for "llvm-config --targets-build" or document this fact
somewhere.

-- 
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/20130702/099f1986/attachment.html>

Best practice device tree design for display subsystems/DRM

[Daniel Drake]

On Tue, Jul 2, 2013 at 12:43 PM, Russell King  wrote:
> I will point out that relying on driver probing orders has already been
> stated by driver model people to be unsafe.  This is why I will not
> adopt such a solution for my driver; it is a bad design.

Just to clarify, what you're objecting to is effectively the
following? Because it is not guaranteed in the future that the probe
order will be the same as the platform_driver_register() calls?

static int __init exynos_drm_init(void)
{
ret = platform_driver_register(_driver);
if (ret < 0)
goto out_hdmi;
ret = platform_driver_register(_driver);
if (ret < 0)
goto out_mixer;
ret = platform_driver_register(_drm_common_hdmi_driver);
if (ret < 0)
goto out_common_hdmi;
ret = platform_driver_register(_drm_platform_driver);
if (ret < 0)
goto out_drm;

(exynos_drm_platform_driver is the driver that creates the drm_device)

Thanks
Daniel

[PATCH v3 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Chris Wilson]

On Tue, Jul 02, 2013 at 05:57:04PM +0900, Seung-Woo Kim wrote:
> If raw_edid of drm_edid_block_vaild() is null, it will crash, so
> checking in bad label is removed and instead assertion is added at
> the top of the function.
> The type of return for the function is bool, so it fixes to return
> true and false instead of 1 and 0.
> 
> Signed-off-by: Seung-Woo Kim 
> Signed-off-by: Kyungmin Park 

Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Chris Wilson]

On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote:
> If raw_edid of drm_edid_block_vaild() is null, it will crash, so
> checking in bad label is removed and instead assertion is added at
> the top of the function.
> The type of return for the function is bool, so it fixes to return
> true and false instead of 1 and 0.
> 
> Signed-off-by: Seung-Woo Kim 
> Signed-off-by: Kyungmin Park 

if (WARN_ON(raw_edid == NULL))
   return false;

Otherwise it is just a WARN_ON() followed by a BUG() :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v4 3/3] drm: fix error routines in drm_open_helper

[Chris Wilson]

On Tue, Jul 02, 2013 at 09:53:28AM +0900, Seung-Woo Kim wrote:
> From: YoungJun Cho 
> 
> There are missing parts to handle error in drm_open_helper().
> The priv->minor, assigned by idr_find() which can return NULL,
> should be checked whether it is NULL or not before referencing it.
> put_pid(), drm_gem_release(), and drm_prime_destory_file_private()
> should be called when error happens after their pair functions are
> called. If an error occurs after executing dev->driver->open()
> which allocates driver specific per-file private data, then the
> private data should be released.
> 
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Seung-Woo Kim 
> Signed-off-by: Kyungmin Park 

I can't see anything else that we setup and miss freeing along the
failed open, so if it compiles ;-)
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

On Tue, Jul 02, 2013 at 10:25:17AM +0100, Chris Wilson wrote:
> On Tue, Jul 02, 2013 at 10:48:31AM +0200, Daniel Vetter wrote:
> > Every other place properly checks whether we've managed to set
> > up the stolen allocator at boot-up properly, with the exception
> > of the cleanup code. Which results in an ugly
> > 
> > *ERROR* Memory manager not clean. Delaying takedown
> > 
> > at module unload time since the drm_mm isn't initialized at all.
> > 
> > v2: While at it check whether the stolen drm_mm is initialized instead
> > of the more obscure stolen_base == 0 check.
> > 
> > v3: Fix up the logic. Also we need to keep the stolen_base check in
> > i915_gem_object_create_stolen_for_preallocated since that can be
> > called before stolen memory is fully set up. Spotted by Chris Wilson.
> > 
> > v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
> > the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
> > allocatot must already be initialized when calling that function (if
> > we indeed have stolen memory).
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
> > Cc: Chris Wilson 
> > Tested-by: lu hua  (v3)
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Chris Wilson 

Thanks for the review, merged to -fixes.
> 
> Once thing I noticed is that we should probably warn if vlv_reserved >=
> stolen_size.

I've added that patch to my queue, I'll submit it together with the gm45
reset fixes (once QA has tested them).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Best practice device tree design for display subsystems/DRM

[Daniel Drake]

Hi,

I'm looking into implementing devicetree support in armada_drm and
would like to better understand the best practice here.

Adding DT support for a DRM driver seems to be complicated by the fact
that DRM is not "hotpluggable" - it is not possible for the drm_device
to be initialised without an output, with the output connector/encoder
appearing at some later moment. Instead, the connectors/encoders must
be fully loaded before the drm_driver load function returns. This
means that we cannot drive the individual display components through
individual, separate modules - we need a way to control their load
order.

Looking at existing DRM drivers:

tilcdc_drm takes an approach that each of the components in the
display subsystem (panel, framebuffer, encoder, display controllers)
are separate DT nodes and do not have any DT-level linkage.
It implements just a single module, and that module carefully
initialises things in this order:
 1. Register platform drivers for output components
 2. Register main drm_driver

When the output component's platform drivers get loaded, probes for
such drivers immediately run as they match things in the device tree.
At this point, there is no drm_device available for the outputs to
bind to, so instead, references to these platform devices just get
saved in some global structures.

Later, when the drm_driver gets registered and loaded, the global
structures are consulted to find all of the output devices at the
right moment.


exynos seems to take a the same approach. Components are separate in
the device tree, and each component is implemented as a platform
driver or i2c driver. However all the drivers are built together in
the same module, and the module_init sequence is careful to initialise
all of the output component drivers before loading the DRM driver. The
output component driver store their findings in global structures.



Russell King suggested an alternative design for armada_drm. If all
display components are represented within the same "display"
super-node, we can examine the DT during drm_device initialisation and
initialise the appropriate output components. In this case, the output
components would not be registered as platform drivers.

The end result would be something similar to exynos/tilcdc (i.e.
drm_driver figuring out its output in the appropriate moment), however
the hackyness of using global storage to store output devices before
drm_driver is ready is avoided. And there is the obvious difference in
devicetree layout, which would look something like:

display {
  compatible = "marvell,armada-510-display";
  clocks = <_clk0>, <_pll_clk>;
  lcd0 {
compatible = "marvell,armada-510-lcd";
reg = <0xf182 0x1000>;
interrupts = <47>;
  };
  lcd1 {
compatible = "marvell,armada-510-lcd";
reg = <0xf181 0x1000>;
interrupts = <46>;
  };
  dcon {
compatible = "marvell,armada-510-dcon";
reg = <...>;
  };
};

Any thoughts/comments?

Thanks
Daniel

[PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Ville Syrjälä]

On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote:
> If raw_edid of drm_edid_block_vaild() is null, it will crash, so
> checking in bad label is removed and instead assertion is added at
> the top of the function.
> The type of return for the function is bool, so it fixes to return
> true and false instead of 1 and 0.
> 
> Signed-off-by: Seung-Woo Kim 
> Signed-off-by: Kyungmin Park 
> ---
> chages from v1
> - NULL checking is replaced with WARN_ON() as Daniel commented
> - all return value is replaced as true/false as Chris and Daniel commented
> 
>  drivers/gpu/drm/drm_edid.c |8 +---
>  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 2dc1a60..1117f02 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -968,6 +968,8 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
> print_bad_edid)
>   u8 csum = 0;
>   struct edid *edid = (struct edid *)raw_edid;
>  
> + WARN_ON(!raw_edid);
> +

I don't see this buying us anything. All you get is two backtraces
instead of one.

if (WARN_ON(!raw_edid))
return false;

would make more sense if we want tolerate programmer errors a bit
better. I'm not a huge fan of such defensive programming though
since it tends to make it less clear what the function actually
expects from you. But here the WARN_ON() would at least make it
clear that it's not meant to happen.


>   if (edid_fixup > 8 || edid_fixup < 0)
>   edid_fixup = 6;
>  
> @@ -1010,15 +1012,15 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, 
> bool print_bad_edid)
>   break;
>   }
>  
> - return 1;
> + return true;
>  
>  bad:
> - if (raw_edid && print_bad_edid) {
> + if (print_bad_edid) {
>   printk(KERN_ERR "Raw EDID:\n");
>   print_hex_dump(KERN_ERR, " \t", DUMP_PREFIX_NONE, 16, 1,
>  raw_edid, EDID_LENGTH, false);
>   }
> - return 0;
> + return false;
>  }
>  EXPORT_SYMBOL(drm_edid_block_valid);
>  
> -- 
> 1.7.4.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

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

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

--- Comment #4 from Austin Lund  ---
(In reply to comment #3)
> 
> Yes, indeed UVD is ring 5 and that is not present in older kernels. Are you
> sure that the system instability is related to this? Cause except for non
> working UVD it shouldn't affect the driver at all.

Cannot say about the instability.  Maybe it's not related but hard to debug as
the system just stalls soon after the screen gets back (after the fence
timeout) and needs a reset and the logs are gone.

-- 
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/20130702/022dc595/attachment.html>

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

Every other place properly checks whether we've managed to set
up the stolen allocator at boot-up properly, with the exception
of the cleanup code. Which results in an ugly

*ERROR* Memory manager not clean. Delaying takedown

at module unload time since the drm_mm isn't initialized at all.

v2: While at it check whether the stolen drm_mm is initialized instead
of the more obscure stolen_base == 0 check.

v3: Fix up the logic. Also we need to keep the stolen_base check in
i915_gem_object_create_stolen_for_preallocated since that can be
called before stolen memory is fully set up. Spotted by Chris Wilson.

v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
allocatot must already be initialized when calling that function (if
we indeed have stolen memory).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
Cc: Chris Wilson 
Tested-by: lu hua  (v3)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 8e02344..0f8cf62 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device 
*dev, int size)
 {
struct drm_i915_private *dev_priv = dev->dev_private;

-   if (dev_priv->mm.stolen_base == 0)
+   if (!drm_mm_initialized(_priv->mm.stolen))
return -ENODEV;

if (size < dev_priv->fbc.size)
@@ -179,6 +179,9 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;

+   if (!drm_mm_initialized(_priv->mm.stolen))
+   return;
+
i915_gem_stolen_cleanup_compression(dev);
drm_mm_takedown(_priv->mm.stolen);
 }
@@ -300,7 +303,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 
size)
struct drm_i915_gem_object *obj;
struct drm_mm_node *stolen;

-   if (dev_priv->mm.stolen_base == 0)
+   if (!drm_mm_initialized(_priv->mm.stolen))
return NULL;

DRM_DEBUG_KMS("creating stolen object: size=%x\n", size);
@@ -331,7 +334,7 @@ i915_gem_object_create_stolen_for_preallocated(struct 
drm_device *dev,
struct drm_i915_gem_object *obj;
struct drm_mm_node *stolen;

-   if (dev_priv->mm.stolen_base == 0)
+   if (!drm_mm_initialized(_priv->mm.stolen))
return NULL;

DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, 
gtt_offset=%x, size=%x\n",
-- 
1.8.3.1

[Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

On Tue, Jul 02, 2013 at 09:13:34AM +0100, Chris Wilson wrote:
> On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote:
> > On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote:
> > > On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
> > > > Every other place properly checks whether we've managed to set
> > > > up the stolen allocator at boot-up properly, with the exception
> > > > of the cleanup code. Which results in an ugly
> > > > 
> > > > *ERROR* Memory manager not clean. Delaying takedown
> > > > 
> > > > at module unload time since the drm_mm isn't initialized at all.
> > > > 
> > > > v2: While at it check whether the stolen drm_mm is initialized instead
> > > > of the more obscure stolen_base == 0 check.
> > > > 
> > > > v3: Fix up the logic. Also we need to keep the stolen_base check in
> > > > i915_gem_object_create_stolen_for_preallocated since that can be
> > > > called before stolen memory is fully set up. Spotted by Chris Wilson.
> > > 
> > > Can you grab a backtrace for stolen_base && !initialized(stolen)? Since
> > > preallocated touches the stolen mm, it should be setup by that point.
> > 
> > I haven't seen it blow up at runtime, but we have special code in
> > i915_gem_object_create_stolen_for_preallocated which handles the
> > !drm_mm_initialized case. So I've figured we need this. Iirc it's to allow
> > us to wrap the vbios framebuffer.
> 
> That's a different drm_mm for the ggtt. We still need the stolen mm setup
> in order to allocate our memory (as we don't have the same dance to
> reconstruct the reserved blocks upon initialisation of stolen).

Oh right, I'll update the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Chris Wilson]

On Tue, Jul 02, 2013 at 10:48:31AM +0200, Daniel Vetter wrote:
> Every other place properly checks whether we've managed to set
> up the stolen allocator at boot-up properly, with the exception
> of the cleanup code. Which results in an ugly
> 
> *ERROR* Memory manager not clean. Delaying takedown
> 
> at module unload time since the drm_mm isn't initialized at all.
> 
> v2: While at it check whether the stolen drm_mm is initialized instead
> of the more obscure stolen_base == 0 check.
> 
> v3: Fix up the logic. Also we need to keep the stolen_base check in
> i915_gem_object_create_stolen_for_preallocated since that can be
> called before stolen memory is fully set up. Spotted by Chris Wilson.
> 
> v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
> the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
> allocatot must already be initialized when calling that function (if
> we indeed have stolen memory).
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
> Cc: Chris Wilson 
> Tested-by: lu hua  (v3)
> Signed-off-by: Daniel Vetter 

Reviewed-by: Chris Wilson 

Once thing I noticed is that we should probably warn if vlv_reserved >=
stolen_size.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/prime: fix up handle_to_fd ioctl return value

[Daniel Vetter]

On Tue, Jul 02, 2013 at 04:55:16PM +0900, YoungJun Cho wrote:
> Dear Daniel,
> 
> On Jul 2, 2013 4:19 PM, "Daniel Vetter"  wrote:
> >
> > In
> >
> > commit da34242e5e0638312130f5bd5d2d277afbc6f806
> > Author: YoungJun Cho 
> > Date:   Wed Jun 26 10:21:42 2013 +0900
> >
> > drm/prime: add return check for dma_buf_fd
> >
> > the failure case handling was fixed up. But in the case when we
> > already had the buffer exported it changed the return value:
> > Previously we've return 0 on success, now we return the fd.
> >
> > This ABI change has been caught by i-g-t/prime_self_import/with_one_bo.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66436
> > Cc: YoungJun Cho 
> > Cc: Seung-Woo Kim 
> > Cc: Kyungmin Park 
> > Tested-by: lu hua 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_prime.c |7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 52709f2..1e0de41 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -347,10 +347,13 @@ int drm_gem_prime_handle_to_fd(struct drm_device
> *dev,
> >  out_have_obj:
> > get_dma_buf(dmabuf);
> > ret = dma_buf_fd(dmabuf, flags);
> > -   if (ret < 0)
> > +   if (ret < 0) {
> > dma_buf_put(dmabuf);
> > -   else
> > +   } else {
> > *prime_fd = ret;
> > +   ret = 0;
> > +   }
> > +
> > goto out;
> >
> >  fail_rm_handle:
> > --
> > 1.7.10.4
> >
> >
> 
> Right, that's my mistake.
> I'll pay attention from now on!
> 
> Thank you & best regards YJ

Reviewed-by ?

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
> Every other place properly checks whether we've managed to set
> up the stolen allocator at boot-up properly, with the exception
> of the cleanup code. Which results in an ugly
> 
> *ERROR* Memory manager not clean. Delaying takedown
> 
> at module unload time since the drm_mm isn't initialized at all.
> 
> v2: While at it check whether the stolen drm_mm is initialized instead
> of the more obscure stolen_base == 0 check.
> 
> v3: Fix up the logic. Also we need to keep the stolen_base check in
> i915_gem_object_create_stolen_for_preallocated since that can be
> called before stolen memory is fully set up. Spotted by Chris Wilson.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
> Cc: Chris Wilson 
> Signed-off-by: Daniel Vetter 

Tested-by: lu hua 

> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 8e02344..fbfc2c7 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device 
> *dev, int size)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> - if (dev_priv->mm.stolen_base == 0)
> + if (!drm_mm_initialized(_priv->mm.stolen))
>   return -ENODEV;
>  
>   if (size < dev_priv->fbc.size)
> @@ -179,6 +179,9 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> + if (!drm_mm_initialized(_priv->mm.stolen))
> + return;
> +
>   i915_gem_stolen_cleanup_compression(dev);
>   drm_mm_takedown(_priv->mm.stolen);
>  }
> @@ -300,7 +303,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 
> size)
>   struct drm_i915_gem_object *obj;
>   struct drm_mm_node *stolen;
>  
> - if (dev_priv->mm.stolen_base == 0)
> + if (!drm_mm_initialized(_priv->mm.stolen))
>   return NULL;
>  
>   DRM_DEBUG_KMS("creating stolen object: size=%x\n", size);
> -- 
> 1.8.3.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote:
> On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
> > Every other place properly checks whether we've managed to set
> > up the stolen allocator at boot-up properly, with the exception
> > of the cleanup code. Which results in an ugly
> > 
> > *ERROR* Memory manager not clean. Delaying takedown
> > 
> > at module unload time since the drm_mm isn't initialized at all.
> > 
> > v2: While at it check whether the stolen drm_mm is initialized instead
> > of the more obscure stolen_base == 0 check.
> > 
> > v3: Fix up the logic. Also we need to keep the stolen_base check in
> > i915_gem_object_create_stolen_for_preallocated since that can be
> > called before stolen memory is fully set up. Spotted by Chris Wilson.
> 
> Can you grab a backtrace for stolen_base && !initialized(stolen)? Since
> preallocated touches the stolen mm, it should be setup by that point.

I haven't seen it blow up at runtime, but we have special code in
i915_gem_object_create_stolen_for_preallocated which handles the
!drm_mm_initialized case. So I've figured we need this. Iirc it's to allow
us to wrap the vbios framebuffer.

Hm, on that notion I wonder whether we should keep the display up while
doing a module reload - it would be a neat exercise for all that fastboot
state reconstruction code. Especially the fb reconstruction code would get
much more pacing than what it gets now (since grub tends to leave the
display in VGA mode so often ...).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v4 3/3] drm: fix error routines in drm_open_helper

[Seung-Woo Kim]

From: YoungJun Cho 

There are missing parts to handle error in drm_open_helper().
The priv->minor, assigned by idr_find() which can return NULL,
should be checked whether it is NULL or not before referencing it.
put_pid(), drm_gem_release(), and drm_prime_destory_file_private()
should be called when error happens after their pair functions are
called. If an error occurs after executing dev->driver->open()
which allocates driver specific per-file private data, then the
private data should be released.

Signed-off-by: YoungJun Cho 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Kyungmin Park 
---
change from v3
- fix typo
change from v2
- adds put_pid, drm_gem_release, drm_prime_destroy_file_private as Chris's 
review
change from v1
- replaces error value for failure to find the minor as ENODEV as Chris 
commented

 drivers/gpu/drm/drm_fops.c |   25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 429e07d..33b1125 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -271,6 +271,11 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
priv->uid = current_euid();
priv->pid = get_pid(task_pid(current));
priv->minor = idr_find(_minors_idr, minor_id);
+   if (!priv->minor) {
+   ret = -ENODEV;
+   goto out_put_pid;
+   }
+
priv->ioctl_count = 0;
/* for compatibility root is always authenticated */
priv->authenticated = capable(CAP_SYS_ADMIN);
@@ -292,7 +297,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
if (dev->driver->open) {
ret = dev->driver->open(dev, priv);
if (ret < 0)
-   goto out_free;
+   goto out_prime_destroy;
}


@@ -304,7 +309,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
if (!priv->minor->master) {
mutex_unlock(>struct_mutex);
ret = -ENOMEM;
-   goto out_free;
+   goto out_close;
}

priv->is_master = 1;
@@ -322,7 +327,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
drm_master_put(>minor->master);
drm_master_put(>master);
mutex_unlock(>struct_mutex);
-   goto out_free;
+   goto out_close;
}
}
mutex_lock(>struct_mutex);
@@ -333,7 +338,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
drm_master_put(>minor->master);
drm_master_put(>master);
mutex_unlock(>struct_mutex);
-   goto out_free;
+   goto out_close;
}
}
mutex_unlock(>struct_mutex);
@@ -367,7 +372,17 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
 #endif

return 0;
-  out_free:
+
+out_close:
+   if (dev->driver->postclose)
+   dev->driver->postclose(dev, priv);
+out_prime_destroy:
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_destroy_file_private(>prime);
+   if (dev->driver->driver_features & DRIVER_GEM)
+   drm_gem_release(dev, priv);
+out_put_pid:
+   put_pid(priv->pid);
kfree(priv);
filp->private_data = NULL;
return ret;
-- 
1.7.9.5

[PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Seung-Woo Kim]

If raw_edid of drm_edid_block_vaild() is null, it will crash, so
checking in bad label is removed and instead assertion is added at
the top of the function.
The type of return for the function is bool, so it fixes to return
true and false instead of 1 and 0.

Signed-off-by: Seung-Woo Kim 
Signed-off-by: Kyungmin Park 
---
chages from v1
- NULL checking is replaced with WARN_ON() as Daniel commented
- all return value is replaced as true/false as Chris and Daniel commented

 drivers/gpu/drm/drm_edid.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2dc1a60..1117f02 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -968,6 +968,8 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid)
u8 csum = 0;
struct edid *edid = (struct edid *)raw_edid;

+   WARN_ON(!raw_edid);
+
if (edid_fixup > 8 || edid_fixup < 0)
edid_fixup = 6;

@@ -1010,15 +1012,15 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid)
break;
}

-   return 1;
+   return true;

 bad:
-   if (raw_edid && print_bad_edid) {
+   if (print_bad_edid) {
printk(KERN_ERR "Raw EDID:\n");
print_hex_dump(KERN_ERR, " \t", DUMP_PREFIX_NONE, 16, 1,
   raw_edid, EDID_LENGTH, false);
}
-   return 0;
+   return false;
 }
 EXPORT_SYMBOL(drm_edid_block_valid);

-- 
1.7.4.1

[patch] drm/radeon/dpm: cleanup a type issue with rv6xx_clocks_per_unit()

[Dan Carpenter]

The rv6xx_clocks_per_unit() function pretends it can set flags in a u64
bitfield but really because "1" is an int it doesn't work for more than
32 bits.  The only caller truncates the high bits away anyway.  I've
just changed it to be a u32.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/radeon/rv6xx_dpm.c 
b/drivers/gpu/drm/radeon/rv6xx_dpm.c
index 0e8b7d9..a4b80f23 100644
--- a/drivers/gpu/drm/radeon/rv6xx_dpm.c
+++ b/drivers/gpu/drm/radeon/rv6xx_dpm.c
@@ -406,9 +406,9 @@ static void 
rv6xx_enable_engine_feedback_and_reference_sync(struct radeon_device
WREG32_P(SPLL_CNTL_MODE, SPLL_DIV_SYNC, ~SPLL_DIV_SYNC);
 }

-static u64 rv6xx_clocks_per_unit(u32 unit)
+static u32 rv6xx_clocks_per_unit(u32 unit)
 {
-   u64 tmp = 1 << (2 * unit);
+   u32 tmp = 1 << (2 * unit);

return tmp;
 }
@@ -416,7 +416,7 @@ static u64 rv6xx_clocks_per_unit(u32 unit)
 static u32 rv6xx_scale_count_given_unit(struct radeon_device *rdev,
u32 unscaled_count, u32 unit)
 {
-   u32 count_per_unit = (u32)rv6xx_clocks_per_unit(unit);
+   u32 count_per_unit = rv6xx_clocks_per_unit(unit);

return (unscaled_count + count_per_unit - 1) / count_per_unit;
 }

armada_drm clock selection - try 2

[Sebastian Hesselbarth]

On 07/02/13 03:57, Daniel Drake wrote:
> On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
>  wrote:
>> I prefer not to try to find the best clock (source) at all. Let the
>> user pass the clock name by e.g. platform_data (or DT) and just try to
>> get the requested pixclk or a integer multiple of it. You will never be
>> able to find the best clock for all use cases.
>>
>> Just figure out, if integer division is sufficient to get requested
>> pixclk and clk_set_rate otherwise. This may be useful for current mode
>> running at 148.5MHz (1080p50) and new mode at 74.25MHz (1080i50, 720p).
>
> I am not opposed to this approach, it is nice and simple, but as
> Russell points out we do additionally need to distinguish between
> clocks that are "ours" to play with, vs those that are shared with
> other devices. It would be a bad idea to try call clk_set_rate() on
> the AXI bus clock, for example, changing the clock for a whole bunch
> of other devices. This is what the is_dedicated flag is about. However
> such a flag could be easily added to the DT/platform data definition
> that you propose.

Daniel,

now I got the idea of .is_dedicated. At least for Dove, we could still
implement AXI bus clock as fixed-rate clock, so you cannot mess with it.
I am almost sure, it will hang Dove when you change it, as there are
some devices depending on it (and the correct rate of it). Moreover,
LCDCLK is dedicated to CRTC0/1 so AXICLK is the only clock not
dedicated to LCD controllers.

But I am fine with .is_dedicated - I just think we should not try to
find the best clock source but leave that decision to the user
(=developer, DTS author; not userspace user).

Sebastian

[patch] drm/radeon/dpm: off by one in si_set_mc_special_registers()

[Dan Carpenter]

These checks should be ">=" instead of ">".  j is used as an offset into
the table->mc_reg_address[] array and that has
SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE (16) elements.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 6918f07..ea88bbe 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -5126,7 +5126,7 @@ static int si_set_mc_special_registers(struct 
radeon_device *rdev,
table->mc_reg_table_entry[k].mc_data[j] 
|= 0x100;
}
j++;
-   if (j > SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
+   if (j >= SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
return -EINVAL;

if (!pi->mem_gddr5) {
@@ -5136,7 +5136,7 @@ static int si_set_mc_special_registers(struct 
radeon_device *rdev,
table->mc_reg_table_entry[k].mc_data[j] 
=

(table->mc_reg_table_entry[k].mc_data[i] & 0x) >> 16;
j++;
-   if (j > SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
+   if (j >= SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
return -EINVAL;
}
break;
@@ -5149,7 +5149,7 @@ static int si_set_mc_special_registers(struct 
radeon_device *rdev,
(temp_reg & 0x) |

(table->mc_reg_table_entry[k].mc_data[i] & 0x);
j++;
-   if (j > SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
+   if (j >= SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
return -EINVAL;
break;
default:

[PATCH] drm/prime: fix up handle_to_fd ioctl return value

[Daniel Vetter]

In

commit da34242e5e0638312130f5bd5d2d277afbc6f806
Author: YoungJun Cho 
Date:   Wed Jun 26 10:21:42 2013 +0900

drm/prime: add return check for dma_buf_fd

the failure case handling was fixed up. But in the case when we
already had the buffer exported it changed the return value:
Previously we've return 0 on success, now we return the fd.

This ABI change has been caught by i-g-t/prime_self_import/with_one_bo.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66436
Cc: YoungJun Cho 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Tested-by: lu hua 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_prime.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 52709f2..1e0de41 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -347,10 +347,13 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
 out_have_obj:
get_dma_buf(dmabuf);
ret = dma_buf_fd(dmabuf, flags);
-   if (ret < 0)
+   if (ret < 0) {
dma_buf_put(dmabuf);
-   else
+   } else {
*prime_fd = ret;
+   ret = 0;
+   }
+
goto out;

 fail_rm_handle:
-- 
1.7.10.4

[Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Chris Wilson]

On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote:
> On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote:
> > On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
> > > Every other place properly checks whether we've managed to set
> > > up the stolen allocator at boot-up properly, with the exception
> > > of the cleanup code. Which results in an ugly
> > > 
> > > *ERROR* Memory manager not clean. Delaying takedown
> > > 
> > > at module unload time since the drm_mm isn't initialized at all.
> > > 
> > > v2: While at it check whether the stolen drm_mm is initialized instead
> > > of the more obscure stolen_base == 0 check.
> > > 
> > > v3: Fix up the logic. Also we need to keep the stolen_base check in
> > > i915_gem_object_create_stolen_for_preallocated since that can be
> > > called before stolen memory is fully set up. Spotted by Chris Wilson.
> > 
> > Can you grab a backtrace for stolen_base && !initialized(stolen)? Since
> > preallocated touches the stolen mm, it should be setup by that point.
> 
> I haven't seen it blow up at runtime, but we have special code in
> i915_gem_object_create_stolen_for_preallocated which handles the
> !drm_mm_initialized case. So I've figured we need this. Iirc it's to allow
> us to wrap the vbios framebuffer.

That's a different drm_mm for the ggtt. We still need the stolen mm setup
in order to allocate our memory (as we don't have the same dance to
reconstruct the reserved blocks upon initialisation of stolen).

> Hm, on that notion I wonder whether we should keep the display up while
> doing a module reload - it would be a neat exercise for all that fastboot
> state reconstruction code. Especially the fb reconstruction code would get
> much more pacing than what it gets now (since grub tends to leave the
> display in VGA mode so often ...).

Yes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v3 3/3] drm: fix error routines in drm_open_helper

[Seung-Woo Kim]

From: YoungJun Cho 

There are missing parts to handle error in drm_open_helper().
The priv->minor, assigned by idr_find() which can return NULL,
should be checked whether it is NULL or not before referencing it.
put_pid(), drm_gem_release(), and drm_prime_destory_file_private()
should be called when error happens after their pair functions are
called. If an error occurs after executing dev->driver->open()
which allocates driver specific per-file private data, then the
private data should be released.

Signed-off-by: YoungJun Cho 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Kyungmin Park 
---
change from v2
- adds put_pid, drm_gem_release, drm_prime_destroy_file_private as Chris's 
review
change from v1
- replaces error value for failure to find the minor as ENODEV as Chris 
commented

 drivers/gpu/drm/drm_fops.c |   25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 429e07d..33b1125 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -271,6 +271,11 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
priv->uid = current_euid();
priv->pid = get_pid(task_pid(current));
priv->minor = idr_find(_minors_idr, minor_id);
+   if (!priv->minor) {
+   ret = -ENODEV;
+   goto out_put_pid;
+   }
+
priv->ioctl_count = 0;
/* for compatibility root is always authenticated */
priv->authenticated = capable(CAP_SYS_ADMIN);
@@ -292,7 +297,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
if (dev->driver->open) {
ret = dev->driver->open(dev, priv);
if (ret < 0)
-   goto out_free;
+   goto out_prime_destroy;
}


@@ -304,7 +309,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
if (!priv->minor->master) {
mutex_unlock(>struct_mutex);
ret = -ENOMEM;
-   goto out_free;
+   goto out_close;
}

priv->is_master = 1;
@@ -322,7 +327,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
drm_master_put(>minor->master);
drm_master_put(>master);
mutex_unlock(>struct_mutex);
-   goto out_free;
+   goto out_close;
}
}
mutex_lock(>struct_mutex);
@@ -333,7 +338,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
drm_master_put(>minor->master);
drm_master_put(>master);
mutex_unlock(>struct_mutex);
-   goto out_free;
+   goto out_close;
}
}
mutex_unlock(>struct_mutex);
@@ -367,7 +372,17 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
 #endif

return 0;
-  out_free:
+
+out_close:
+   if (dev->driver->postclose)
+   dev->driver->postclose(dev, priv);
+out_prime_destroy:
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_destroy_file_private(>prime);
+   if (dev->driver->driver_feature & DRIVER_GEM)
+   drm_gem_release(dev, priv);
+out_put_pid:
+   put_pid(priv->pid);
kfree(priv);
filp->private_data = NULL;
return ret;
-- 
1.7.9.5

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

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

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Christian K?nig  ---
(In reply to comment #2)
> (In reply to comment #1)
> > This is a mac?
> 
> Yes.  Macbookpro8,2

What else should it be? I'm really wondering if we shouldn't just disable UVD
on Macs (with an option to override it of course).

> 
> Also, this doesn't happen with a 3.9.7 kernel.
> 
> It seems to be related to the UVD stuff that was added to 3.10.  Ring 5
> appears to be related to this and it doesn't appear in the 3.9 kernels.

Yes, indeed UVD is ring 5 and that is not present in older kernels. Are you
sure that the system instability is related to this? Cause except for non
working UVD it shouldn't affect the driver at all.

-- 
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/20130702/e97e058e/attachment.html>

[PATCH 2/3] drm: move edid null check to the first part of drm_edid_block_valid

[Seung-Woo Kim]

Hi Daniel,

On 2013? 07? 01? 23:56, Daniel Vetter wrote:
> On Mon, Jul 1, 2013 at 12:21 PM, Chris Wilson  
> wrote:
>> On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote:
>>> If raw_edid is null, it will crash, so checking in bad label is
>>> meaningless.
>>
>> It would be an error on part of the caller, but the defense looks sane.
>> As the function is a bool, I would have preferred it returned
>> true/false, but your patch is correct wrt to the rest of the function.
> 
> If we consider passing a NULL raw_edid here a caller-error, shouldn't
> this be a WARN on top? And I concur on the s/0/false/ bikeshed, return
> 0 could be misleading since for errno returning functions that reads
> as success.

Yes, you are right. WARN_ON() is better because there was no crash until
now. and I will also update all return values as false/true instead of 0/1.

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Seung-Woo Kim
Samsung Software R Center
--

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Chris Wilson]

On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
> Every other place properly checks whether we've managed to set
> up the stolen allocator at boot-up properly, with the exception
> of the cleanup code. Which results in an ugly
> 
> *ERROR* Memory manager not clean. Delaying takedown
> 
> at module unload time since the drm_mm isn't initialized at all.
> 
> v2: While at it check whether the stolen drm_mm is initialized instead
> of the more obscure stolen_base == 0 check.
> 
> v3: Fix up the logic. Also we need to keep the stolen_base check in
> i915_gem_object_create_stolen_for_preallocated since that can be
> called before stolen memory is fully set up. Spotted by Chris Wilson.

Can you grab a backtrace for stolen_base && !initialized(stolen)? Since
preallocated touches the stolen mm, it should be setup by that point.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/nouveau: fix locking in nouveau_crtc_page_flip

[Dave Airlie]

On Mon, Jul 1, 2013 at 8:00 PM, Maarten Lankhorst
 wrote:
> This is a bit messed up because chan->cli->mutex is a different class,
> depending on whether it is the global drm client or not. This is
> because the global cli->mutex lock can be taken for eviction,
> so locking it before pinning the buffer objects may result in a deadlock.

conditional mutex locking made me free a bit ill,

Ben any cleaner way to do this? if not I'll merge this.

Dave.

linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]

[Sedat Dilek]

On Mon, Jul 1, 2013 at 11:03 AM, Sedat Dilek  wrote:
> On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter  
> wrote:
>> On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek  
>> wrote:
>>> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell  
>>> wrote:
 Hi all,

 Changes since 20130628:

 The regulator tree gained a build failure so I used the version from
 next-20130628.

 The trivial tree gained a conflict against the fbdev tree.

 The arm-soc tree gained a conflict against the net-next tree.

 The akpm tree lost a few patches that turned up elsewhere and I removed 2
 that were causing run time problems.

>>>
>>> [ CC drm and drm-intel folks ]
>>>
>>> [ Did not check any relevant MLs ]
>>>
>>> Please, see attached dmesg output.
>>
>> Clock mismatch, one for Jesse to figure out. Note that this patch is
>> for 3.12, I simply haven't yet gotten around to properly split my
>> patch queue so a few spilled into -next. I'll do that now.
>
> I like lightspeed-fast replies :-).
>
> Guess "drm/i915: get mode clock when reading the pipe config v9" [1]
> is the cause.
>

Problem solved by applying these patches to next-20130701 from
intel-gfx patchwork-service [0]:

   [1/2] drm/i915: fixup messages in pipe_config_compare
   [2/2] drm/i915: get clock config when checking CRTC state too

AFAICS 2/2 was folded into updated "drm/i915: get mode clock when
reading the pipe config v9" [3].

It would be kind to be CCed on the patches and get also some credits.
Also a CC to the report in linux-next should IMHO be done.

- Sedat -

[0] https://patchwork.kernel.org/project/intel-gfx/list/
[1] https://patchwork.kernel.org/patch/2809031/
[2] https://patchwork.kernel.org/patch/2809021/
[3] 
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightly=f1f644dc66cbaf5a4c7dcde683361536b41885b9

> - Sedat -
>
> [1] 
> http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued=d325d8b4f351f9d45e7c8baabf581fd21f343133
>
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Dave Airlie]

> Of course, I share the idea of true, full-blown of_drm_something
> helpers. But the DT patch, is not an improvement but a real fix as in
> "make DRM not break on some platforms". From that on, I can start
> digging into DRM API and improve DT support here and there.
>
> So for the three patches I mentioned above, they are all minor
> improvements of the API. Minor, because I cannot ever sent _the_ single
> perfect patch just because I don't know the API well enough, yet.
>
> Just based on my personal experience: TDA998x driver got merged the way it
> is _although_ I addressed some concerns - the fixes are not merged
> _although_ I provided experimental results. This is of course
> disappointing for me, but I am sure it will work out soon and I will
> get back to happily send improvements for the platforms I can test on.

To be honest I've no idea what those tda998x patches could fix or
break, so they go on my no ideas list and I hope if they get reposted
someone will tell me what they do.

I could probably be more motivated towards poking other people to
review stuff, but I mostly hope in vain that the ARM people will cross
review things for other ARM chips, I had a bit of that happening for a
while at the start, but it seems to have died off. Now I'm mostly
relying on Rob to have some clue what I'm merging is sane.

My current priority for merging stuff is:
core patches that affect all platforms,
core patches that affect x86
drivers that I maintain by default
core patches that affect ARM
misc ARM drivers that fall through cracks.

Maybe I can persuade Rob to become a sub maintainer for all of the SoC
drivers but I suspect he'd try and hurt me in real life.

I'll take another look at the tda patches but I may still have no idea
what they are doing.

Dave.

RADEON / DPM: GPU cannot properly up-clock

[Joshua C.]

2013/6/28 Joshua C. :
> 2013/6/27 Alex Deucher :
>> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C.  wrote:
>>> 2013/6/26 Deucher, Alexander :


> -Original Message-
> From: Joshua C. [mailto:joshuacov at gmail.com]
> Sent: Wednesday, June 26, 2013 1:52 PM
> To: dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: RADEON / DPM: GPU cannot properly up-clock
>
> First of all thank you guys for pushing this out! Great work!
>
> I tried the latest code in drm-next-3.11-wip (up to commit
> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm
> code") in connection with the latest radeon_ucode (latest update on
> 2013-06-26). I also reintroduced the debugfs info so that I can better
> observe the gpu-settings. For this I put back the following patch:
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 7ba5d6f..9367234 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
> radeon_device *rdev)
>  ret = device_create_file(rdev->dev, _attr_power_method);
>  if (ret)
>  DRM_ERROR("failed to create device file for power method\n");
> +
> +if (radeon_debugfs_pm_init(rdev)) {
> +DRM_ERROR("Failed to register debugfs file for PM!\n");
> +}
> +
>  DRM_INFO("radeon: dpm initialized\n");
>  }
>
> --
> 1.8.2.1

 I removed that code for a reason when DPM is active.  With DPM the 
 hardware changes the power state dynamically internally so that old 
 debugging information is completely irrelevant when DPM is active.

 Alex


>>>
>>> I see. Do you have any idea why I see those delays when playing a
>>> HD-movie? They do not appear when switching to dynpm. I use the latest
>>> llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
>>> xf86-video-ati(deve) - all fetched from git as of 2013-06-26.
>>
>> What type of movie is it and what are you using to decode the movie? UVD?  
>> CPU?
>>
>> Alex
>
> Here is an example of the information from one of the films:
>
> Stream 0
> Type: Video
> Codec: H264 - MPEG-4 AVC (part 10) (avc1)
> Lang: English
> Res: 1280x544
> Bitrate: 23.976215
> Format: Planar 4:2:0 YVU
> Stream 1
> Type: Audio
> Codec: DTS Audio (dts )
> Lang: English
> Channels: 3F2R/LFE
> Freq: 48000 Hz
> Bitrate: 1536 kb/s
>
> I recompiled the whole videostack (mesa, llvm, drm, xserver,
> xf86-video-ati, vdpau - all from git) against the patched kernel and
> can say that currently there are no visible regressions. The "slow
> motion" is almost gone. However I still see it in some frames but I'm
> not sure if this is a kernel-part-problem or just a mesa-problem.
>
> However I observe the following:
>
> Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5%
> on all cores on a 4-core cpu, temps when playing the film: up to 42C,
> cpu-usage: up to 5% on all 4 cores
>
> Under linux (updated as described above): some discrepences (those
> happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to
> 5%, temps when playing the film: no more than 37C, cpu-usage: one core
> is constantly spiking up to 40% the other 3 stay below 7%.
>
> When looking through the dmesg I cannot see that dpm is changing the
> power state to "uvd". This makes me believe that I'm maybe using a
> cpu-decode rather then the dedicated uvd. The gpu-temps are also
> staying surpricingly low comapred to windows...
>
> --
> --joshua


With the latest git 7982128c3d447df27db963af67bc6b8dc7efb1de
"drm/radeon/dpm: add debugfs support for SI" from
git://people.freedesktop.org/~agd5f/linux drm-next-3.11 everything
works fine here (on TURKS). Under Linux I get the same temps as under
windows. No more tearing when watching videos. The GPU re-clocks as
desired...


--
--joshua

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Sebastian Hesselbarth]

On 07/01/2013 11:55 PM, Rob Clark wrote:
> On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth
>   wrote:
>> - TDA998x irq handling - ignored
>> - TDA998x sync fix - ignored
>
> At least the sync fix, looks like I missed it (it probably is a good
> idea to CC me if you want me to look at it).  Looks like there was
> some follow-up discussion on both patches, unless I missed seeing a
> newer version of those patches.

Yeah, I will update the patch for current mainline linux as it was
based on some of Russell's RFC patches.

> Sometimes if you think a patch has been ignored/forgotten, it doesn't
> hurt to ping on mailing list or #dri-devel..  a lot of us are working
> not just on kernel (the relatively small part in the whole linux
> graphics stack), but also mesa and/or x11.  Some times things end up
> several pages down in the mail folder.  It's not because we are all
> sitting on a beach drinking margaritas, or because we don't like you.
> It is just because we are busy and missed it.
>
> Last few months I've been pretty buried in r/e + gallium driver for
> new gpu, so I wasn't always checking dri-devel list every day.  At
> least now I am in drm-driver mode again ;-)

It is ok, I don't blame anyone here. Darren wants to test it on tilcdc.
I also found a datasheet for TDA9983b which is kind of compatible but
has more information about register layout in it. IIRC digikey also has
it.

>> - Fix drm I2C slave encoder probing
>>
> If you have a better idea about how to make the slave encoder probing
> better (and/or more generic to support stuff other than i2c), please
> send RFC patch.  (And if you already did this, please send updated
> version, see previous point about sometimes missing patches.)

Also, will send an updated fix.

Sebastian

[pull] radeon drm-next-3.11

[Markus Trippelsdorf]

On 2013.07.01 at 17:01 -0400, alexdeucher at gmail.com wrote:
> From: Alex Deucher 
> 
> Hi Dave,
> 
> A few more patches for 3.11:
> - add debugfs interface to check current DPM state
> - Fix a bug that caused problems with DPM on BTC+ asics.
> 
> The following changes since commit f7d452f4fd5d86f764807a1234a407deb5b105ef:
> 
>   Merge branch 'drm-nouveau-next' of 
> git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-07-01 
> 14:10:20 +1000)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~agd5f/linux drm-next-3.11
> 
> Alex Deucher (12):
>   drm/radeon: remove sumo dpm/uvd bringup leftovers
>   drm/radeon/atom: fix endian bug in radeon_atom_init_mc_reg_table()
>   drm/radeon: fix typo in radeon_atom_init_mc_reg_table()
>   drm/radeon/dpm: re-enable state transitions for BTC
>   drm/radeon/dpm: re-enable state transitions for Cayman
>   drm/radeon/dpm: add infrastructure to support debugfs info
>   drm/radeon/dpm: add debugfs support for rv6xx
>   drm/radeon/dpm: add debugfs support for 7xx/evergreen/btc

Looks like you forgot to add debugfs support for rs780:

diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index a5b244d..ca4f928 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1270,6 +1270,7 @@ static struct radeon_asic rs780_asic = {
.get_sclk = _dpm_get_sclk,
.get_mclk = _dpm_get_mclk,
.print_power_state = _dpm_print_power_state,
+   .debugfs_print_current_performance_level = 
_dpm_debugfs_print_current_performance_level,
},
.pflip = {
.pre_page_flip = _pre_page_flip,

-- 
Markus

armada_drm clock selection - try 2

[Sebastian Hesselbarth]

On 07/01/2013 10:30 PM, Daniel Drake wrote:
> Here is a new patch which should incorporate all your previous feedback.
> Now each variant passes clock info to the main driver via a new
> armada_clk_info structure.
>
> A helper function in the core lets each variant find the best clock.
> As you suggested we first try external ("dedicated") clocks, where we can
> change the rate to find an exact match. We fall back on looking at the rates
> of the other clocks and we return the clock that provides us with the closest
> match after integer division (rejecting those that don't bring us within 1%).
>
> There is still the possibility that two CRTCs on the same device end up using
> the same clock, so I added a usage counter to each clock to prevent the rate
> from being changed by another CRTC.
>
> This is compile-tested only - but after your feedback I will add the
> remaining required hacks and test it on XO.
>
> diff --git a/drivers/gpu/drm/armada/armada_510.c 
> b/drivers/gpu/drm/armada/armada_510.c
> index a016888..7dff2dc 100644
> --- a/drivers/gpu/drm/armada/armada_510.c
> +++ b/drivers/gpu/drm/armada/armada_510.c
> @@ -17,12 +17,29 @@
>
>   static int armada510_init(struct armada_private *priv, struct device *dev)
>   {
> - priv->extclk[0] = devm_clk_get(dev, "ext_ref_clk_1");
> + struct armada_clk_info *clk_info = devm_kzalloc(dev,
> + sizeof(struct armada_clk_info) * 4, GFP_KERNEL);
>
> - if (IS_ERR(priv->extclk[0])&&  PTR_ERR(priv->extclk[0]) == -ENOENT)
> - priv->extclk[0] = ERR_PTR(-EPROBE_DEFER);
> + if (!clk_info)
> + return -ENOMEM;
>
> - return PTR_RET(priv->extclk[0]);
> + /* External clocks */
> + clk_info[0].clk = devm_clk_get(dev, "ext_ref_clk_0");
> + clk_info[0].is_dedicated = true;

Daniel,

I guess "extclk0" and "extclk1" should be sufficient for clock names.
Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
extclk0 simultaneously. See below for .is_dedicated in general.

[...]
> diff --git a/drivers/gpu/drm/armada/armada_drm.h 
> b/drivers/gpu/drm/armada/armada_drm.h
> index e8c4f80..4fe8ec5 100644
> --- a/drivers/gpu/drm/armada/armada_drm.h
> +++ b/drivers/gpu/drm/armada/armada_drm.h
> @@ -55,6 +55,20 @@ void armada_drm_vbl_event_remove_unlocked(struct 
> armada_crtc *,
>   __e->fn = _f;   \
>   } while (0)
>
> +struct armada_clk_info {
> + struct clk *clk;
> +
> + /* If this clock is dedicated to us, we can change its rate without
> +  * worrying about any other users in other parts of the system. */
> + bool is_dedicated;
> +
> + /* However, we cannot share the same dedicated clock between two CRTCs
> +  * if each CRTC wants a different rate. Track the number of users. */
> + int usage_count;

You can share the same clock between two CRTCs. Just consider CRTC1
using a mode with half pixel clock as CRTC0. Not that I think this will
ever happen, but it is possible.

> + /* The bits in the SCLK register that select this clock */
> + uint32_t sclk;
> +};
>
>   struct armada_private;
>
> @@ -77,7 +91,8 @@ struct armada_private {
>   struct drm_fb_helper*fbdev;
>   struct armada_crtc  *dcrtc[2];
>   struct drm_mm   linear;
> - struct clk  *extclk[2];
> + int num_clks;
> + struct armada_clk_info  *clk_info;
>   struct drm_property *csc_yuv_prop;
>   struct drm_property *csc_rgb_prop;
>   struct drm_property *colorkey_prop;
> @@ -99,6 +114,9 @@ void __armada_drm_queue_unref_work(struct drm_device *,
>   void armada_drm_queue_unref_work(struct drm_device *,
>   struct drm_framebuffer *);
>
> +struct armada_clk_info *armada_drm_find_best_clock(struct armada_private 
> *priv,
> + long rate, int *divider);
> +
>   extern const struct drm_mode_config_funcs armada_drm_mode_config_funcs;
>
>   int armada_fbdev_init(struct drm_device *);
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index e0a08e9..411d56f 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -16,6 +16,97 @@
>   #include "armada_ioctl.h"
>   #include "armada_ioctlP.h"
>
> +/* Find the best clock and integer divisor for a given rate.
> + * NULL is returned when no clock can be found.
> + * When the return value is non-NULL, the divider output variable is set
> + * appropriately, and the clock is returned in prepared state. */
> +struct armada_clk_info *armada_drm_find_best_clock(struct armada_private 
> *priv,
> + long rate, int *divider)

I prefer not to try to find the best clock (source) at all. Let the
user pass the clock name by e.g. platform_data (or DT) and just try to
get the requested pixclk or a integer multiple of it. You will never be
able to find the best clock for all use cases.

Just figure out, if integer division is sufficient to get requested
pixclk and 

[patch] drm/radeon/dpm: off by one in si_set_mc_special_registers()

[Dan Carpenter]

These checks should be = instead of .  j is used as an offset into
the table-mc_reg_address[] array and that has
SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE (16) elements.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 6918f07..ea88bbe 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -5126,7 +5126,7 @@ static int si_set_mc_special_registers(struct 
radeon_device *rdev,
table-mc_reg_table_entry[k].mc_data[j] 
|= 0x100;
}
j++;
-   if (j  SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
+   if (j = SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
return -EINVAL;
 
if (!pi-mem_gddr5) {
@@ -5136,7 +5136,7 @@ static int si_set_mc_special_registers(struct 
radeon_device *rdev,
table-mc_reg_table_entry[k].mc_data[j] 
=

(table-mc_reg_table_entry[k].mc_data[i]  0x)  16;
j++;
-   if (j  SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
+   if (j = SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
return -EINVAL;
}
break;
@@ -5149,7 +5149,7 @@ static int si_set_mc_special_registers(struct 
radeon_device *rdev,
(temp_reg  0x) |

(table-mc_reg_table_entry[k].mc_data[i]  0x);
j++;
-   if (j  SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
+   if (j = SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE)
return -EINVAL;
break;
default:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch] drm/radeon/dpm: cleanup a type issue with rv6xx_clocks_per_unit()

[Dan Carpenter]

The rv6xx_clocks_per_unit() function pretends it can set flags in a u64
bitfield but really because 1 is an int it doesn't work for more than
32 bits.  The only caller truncates the high bits away anyway.  I've
just changed it to be a u32.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

diff --git a/drivers/gpu/drm/radeon/rv6xx_dpm.c 
b/drivers/gpu/drm/radeon/rv6xx_dpm.c
index 0e8b7d9..a4b80f23 100644
--- a/drivers/gpu/drm/radeon/rv6xx_dpm.c
+++ b/drivers/gpu/drm/radeon/rv6xx_dpm.c
@@ -406,9 +406,9 @@ static void 
rv6xx_enable_engine_feedback_and_reference_sync(struct radeon_device
WREG32_P(SPLL_CNTL_MODE, SPLL_DIV_SYNC, ~SPLL_DIV_SYNC);
 }
 
-static u64 rv6xx_clocks_per_unit(u32 unit)
+static u32 rv6xx_clocks_per_unit(u32 unit)
 {
-   u64 tmp = 1  (2 * unit);
+   u32 tmp = 1  (2 * unit);
 
return tmp;
 }
@@ -416,7 +416,7 @@ static u64 rv6xx_clocks_per_unit(u32 unit)
 static u32 rv6xx_scale_count_given_unit(struct radeon_device *rdev,
u32 unscaled_count, u32 unit)
 {
-   u32 count_per_unit = (u32)rv6xx_clocks_per_unit(unit);
+   u32 count_per_unit = rv6xx_clocks_per_unit(unit);
 
return (unscaled_count + count_per_unit - 1) / count_per_unit;
 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/prime: fix up handle_to_fd ioctl return value

[Daniel Vetter]

In

commit da34242e5e0638312130f5bd5d2d277afbc6f806
Author: YoungJun Cho yj44@samsung.com
Date:   Wed Jun 26 10:21:42 2013 +0900

drm/prime: add return check for dma_buf_fd

the failure case handling was fixed up. But in the case when we
already had the buffer exported it changed the return value:
Previously we've return 0 on success, now we return the fd.

This ABI change has been caught by i-g-t/prime_self_import/with_one_bo.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66436
Cc: YoungJun Cho yj44@samsung.com
Cc: Seung-Woo Kim sw0312@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: lu hua huax...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/drm_prime.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 52709f2..1e0de41 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -347,10 +347,13 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
 out_have_obj:
get_dma_buf(dmabuf);
ret = dma_buf_fd(dmabuf, flags);
-   if (ret  0)
+   if (ret  0) {
dma_buf_put(dmabuf);
-   else
+   } else {
*prime_fd = ret;
+   ret = 0;
+   }
+
goto out;
 
 fail_rm_handle:
-- 
1.7.10.4

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

Re: [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Chris Wilson]

On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
 Every other place properly checks whether we've managed to set
 up the stolen allocator at boot-up properly, with the exception
 of the cleanup code. Which results in an ugly
 
 *ERROR* Memory manager not clean. Delaying takedown
 
 at module unload time since the drm_mm isn't initialized at all.
 
 v2: While at it check whether the stolen drm_mm is initialized instead
 of the more obscure stolen_base == 0 check.
 
 v3: Fix up the logic. Also we need to keep the stolen_base check in
 i915_gem_object_create_stolen_for_preallocated since that can be
 called before stolen memory is fully set up. Spotted by Chris Wilson.

Can you grab a backtrace for stolen_base  !initialized(stolen)? Since
preallocated touches the stolen mm, it should be setup by that point.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/prime: fix up handle_to_fd ioctl return value

[YoungJun Cho]

Dear Daniel,

On Jul 2, 2013 4:19 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:

 In

 commit da34242e5e0638312130f5bd5d2d277afbc6f806
 Author: YoungJun Cho yj44@samsung.com
 Date:   Wed Jun 26 10:21:42 2013 +0900

 drm/prime: add return check for dma_buf_fd

 the failure case handling was fixed up. But in the case when we
 already had the buffer exported it changed the return value:
 Previously we've return 0 on success, now we return the fd.

 This ABI change has been caught by i-g-t/prime_self_import/with_one_bo.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66436
 Cc: YoungJun Cho yj44@samsung.com
 Cc: Seung-Woo Kim sw0312@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Tested-by: lu hua huax...@intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/drm_prime.c |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
 index 52709f2..1e0de41 100644
 --- a/drivers/gpu/drm/drm_prime.c
 +++ b/drivers/gpu/drm/drm_prime.c
 @@ -347,10 +347,13 @@ int drm_gem_prime_handle_to_fd(struct drm_device
*dev,
  out_have_obj:
 get_dma_buf(dmabuf);
 ret = dma_buf_fd(dmabuf, flags);
 -   if (ret  0)
 +   if (ret  0) {
 dma_buf_put(dmabuf);
 -   else
 +   } else {
 *prime_fd = ret;
 +   ret = 0;
 +   }
 +
 goto out;

  fail_rm_handle:
 --
 1.7.10.4



Right, that's my mistake.
I'll pay attention from now on!

Thank you  best regards YJ
___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote:
 On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
  Every other place properly checks whether we've managed to set
  up the stolen allocator at boot-up properly, with the exception
  of the cleanup code. Which results in an ugly
  
  *ERROR* Memory manager not clean. Delaying takedown
  
  at module unload time since the drm_mm isn't initialized at all.
  
  v2: While at it check whether the stolen drm_mm is initialized instead
  of the more obscure stolen_base == 0 check.
  
  v3: Fix up the logic. Also we need to keep the stolen_base check in
  i915_gem_object_create_stolen_for_preallocated since that can be
  called before stolen memory is fully set up. Spotted by Chris Wilson.
 
 Can you grab a backtrace for stolen_base  !initialized(stolen)? Since
 preallocated touches the stolen mm, it should be setup by that point.

I haven't seen it blow up at runtime, but we have special code in
i915_gem_object_create_stolen_for_preallocated which handles the
!drm_mm_initialized case. So I've figured we need this. Iirc it's to allow
us to wrap the vbios framebuffer.

Hm, on that notion I wonder whether we should keep the display up while
doing a module reload - it would be a neat exercise for all that fastboot
state reconstruction code. Especially the fb reconstruction code would get
much more pacing than what it gets now (since grub tends to leave the
display in VGA mode so often ...).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
 Every other place properly checks whether we've managed to set
 up the stolen allocator at boot-up properly, with the exception
 of the cleanup code. Which results in an ugly
 
 *ERROR* Memory manager not clean. Delaying takedown
 
 at module unload time since the drm_mm isn't initialized at all.
 
 v2: While at it check whether the stolen drm_mm is initialized instead
 of the more obscure stolen_base == 0 check.
 
 v3: Fix up the logic. Also we need to keep the stolen_base check in
 i915_gem_object_create_stolen_for_preallocated since that can be
 called before stolen memory is fully set up. Spotted by Chris Wilson.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
 Cc: Chris Wilson ch...@chris-wilson.co.uk
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Tested-by: lu hua huax...@intel.com

 ---
  drivers/gpu/drm/i915/i915_gem_stolen.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 8e02344..fbfc2c7 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device 
 *dev, int size)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
  
 - if (dev_priv-mm.stolen_base == 0)
 + if (!drm_mm_initialized(dev_priv-mm.stolen))
   return -ENODEV;
  
   if (size  dev_priv-fbc.size)
 @@ -179,6 +179,9 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
  
 + if (!drm_mm_initialized(dev_priv-mm.stolen))
 + return;
 +
   i915_gem_stolen_cleanup_compression(dev);
   drm_mm_takedown(dev_priv-mm.stolen);
  }
 @@ -300,7 +303,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 
 size)
   struct drm_i915_gem_object *obj;
   struct drm_mm_node *stolen;
  
 - if (dev_priv-mm.stolen_base == 0)
 + if (!drm_mm_initialized(dev_priv-mm.stolen))
   return NULL;
  
   DRM_DEBUG_KMS(creating stolen object: size=%x\n, size);
 -- 
 1.8.3.1
 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/prime: fix up handle_to_fd ioctl return value

[Daniel Vetter]

On Tue, Jul 02, 2013 at 04:55:16PM +0900, YoungJun Cho wrote:
 Dear Daniel,
 
 On Jul 2, 2013 4:19 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 
  In
 
  commit da34242e5e0638312130f5bd5d2d277afbc6f806
  Author: YoungJun Cho yj44@samsung.com
  Date:   Wed Jun 26 10:21:42 2013 +0900
 
  drm/prime: add return check for dma_buf_fd
 
  the failure case handling was fixed up. But in the case when we
  already had the buffer exported it changed the return value:
  Previously we've return 0 on success, now we return the fd.
 
  This ABI change has been caught by i-g-t/prime_self_import/with_one_bo.
 
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66436
  Cc: YoungJun Cho yj44@samsung.com
  Cc: Seung-Woo Kim sw0312@samsung.com
  Cc: Kyungmin Park kyungmin.p...@samsung.com
  Tested-by: lu hua huax...@intel.com
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   drivers/gpu/drm/drm_prime.c |7 +--
   1 file changed, 5 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
  index 52709f2..1e0de41 100644
  --- a/drivers/gpu/drm/drm_prime.c
  +++ b/drivers/gpu/drm/drm_prime.c
  @@ -347,10 +347,13 @@ int drm_gem_prime_handle_to_fd(struct drm_device
 *dev,
   out_have_obj:
  get_dma_buf(dmabuf);
  ret = dma_buf_fd(dmabuf, flags);
  -   if (ret  0)
  +   if (ret  0) {
  dma_buf_put(dmabuf);
  -   else
  +   } else {
  *prime_fd = ret;
  +   ret = 0;
  +   }
  +
  goto out;
 
   fail_rm_handle:
  --
  1.7.10.4
 
 
 
 Right, that's my mistake.
 I'll pay attention from now on!
 
 Thank you  best regards YJ

Reviewed-by ?

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Chris Wilson]

On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote:
 On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote:
  On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
   Every other place properly checks whether we've managed to set
   up the stolen allocator at boot-up properly, with the exception
   of the cleanup code. Which results in an ugly
   
   *ERROR* Memory manager not clean. Delaying takedown
   
   at module unload time since the drm_mm isn't initialized at all.
   
   v2: While at it check whether the stolen drm_mm is initialized instead
   of the more obscure stolen_base == 0 check.
   
   v3: Fix up the logic. Also we need to keep the stolen_base check in
   i915_gem_object_create_stolen_for_preallocated since that can be
   called before stolen memory is fully set up. Spotted by Chris Wilson.
  
  Can you grab a backtrace for stolen_base  !initialized(stolen)? Since
  preallocated touches the stolen mm, it should be setup by that point.
 
 I haven't seen it blow up at runtime, but we have special code in
 i915_gem_object_create_stolen_for_preallocated which handles the
 !drm_mm_initialized case. So I've figured we need this. Iirc it's to allow
 us to wrap the vbios framebuffer.

That's a different drm_mm for the ggtt. We still need the stolen mm setup
in order to allocate our memory (as we don't have the same dance to
reconstruct the reserved blocks upon initialisation of stolen).

 Hm, on that notion I wonder whether we should keep the display up while
 doing a module reload - it would be a neat exercise for all that fastboot
 state reconstruction code. Especially the fb reconstruction code would get
 much more pacing than what it gets now (since grub tends to leave the
 display in VGA mode so often ...).

Yes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/prime: fix up handle_to_fd ioctl return value

[YoungJun Cho]

Dear Daniel,

On Jul 2, 2013 5:14 PM, Daniel Vetter dan...@ffwll.ch wrote:

 On Tue, Jul 02, 2013 at 04:55:16PM +0900, YoungJun Cho wrote:
  Dear Daniel,
 
  On Jul 2, 2013 4:19 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
  
   In
  
   commit da34242e5e0638312130f5bd5d2d277afbc6f806
   Author: YoungJun Cho yj44@samsung.com
   Date:   Wed Jun 26 10:21:42 2013 +0900
  
   drm/prime: add return check for dma_buf_fd
  
   the failure case handling was fixed up. But in the case when we
   already had the buffer exported it changed the return value:
   Previously we've return 0 on success, now we return the fd.
  
   This ABI change has been caught by
i-g-t/prime_self_import/with_one_bo.
  
   Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66436
   Cc: YoungJun Cho yj44@samsung.com
   Cc: Seung-Woo Kim sw0312@samsung.com
   Cc: Kyungmin Park kyungmin.p...@samsung.com
   Tested-by: lu hua huax...@intel.com
   Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Reviewed-by: YoungJun Cho yj44@samsung.com

Thank you and best regards YJ

   ---
drivers/gpu/drm/drm_prime.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
  
   diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
   index 52709f2..1e0de41 100644
   --- a/drivers/gpu/drm/drm_prime.c
   +++ b/drivers/gpu/drm/drm_prime.c
   @@ -347,10 +347,13 @@ int drm_gem_prime_handle_to_fd(struct drm_device
  *dev,
out_have_obj:
   get_dma_buf(dmabuf);
   ret = dma_buf_fd(dmabuf, flags);
   -   if (ret  0)
   +   if (ret  0) {
   dma_buf_put(dmabuf);
   -   else
   +   } else {
   *prime_fd = ret;
   +   ret = 0;
   +   }
   +
   goto out;
  
fail_rm_handle:
   --
   1.7.10.4
  
  
 
  Right, that's my mistake.
  I'll pay attention from now on!
 
  Thank you  best regards YJ

 Reviewed-by ?

 Cheers, Daniel
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Ville Syrjälä]

On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote:
 If raw_edid of drm_edid_block_vaild() is null, it will crash, so
 checking in bad label is removed and instead assertion is added at
 the top of the function.
 The type of return for the function is bool, so it fixes to return
 true and false instead of 1 and 0.
 
 Signed-off-by: Seung-Woo Kim sw0312@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 chages from v1
 - NULL checking is replaced with WARN_ON() as Daniel commented
 - all return value is replaced as true/false as Chris and Daniel commented
 
  drivers/gpu/drm/drm_edid.c |8 +---
  1 files changed, 5 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index 2dc1a60..1117f02 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -968,6 +968,8 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
 print_bad_edid)
   u8 csum = 0;
   struct edid *edid = (struct edid *)raw_edid;
  
 + WARN_ON(!raw_edid);
 +

I don't see this buying us anything. All you get is two backtraces
instead of one.

if (WARN_ON(!raw_edid))
return false;

would make more sense if we want tolerate programmer errors a bit
better. I'm not a huge fan of such defensive programming though
since it tends to make it less clear what the function actually
expects from you. But here the WARN_ON() would at least make it
clear that it's not meant to happen.


   if (edid_fixup  8 || edid_fixup  0)
   edid_fixup = 6;
  
 @@ -1010,15 +1012,15 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, 
 bool print_bad_edid)
   break;
   }
  
 - return 1;
 + return true;
  
  bad:
 - if (raw_edid  print_bad_edid) {
 + if (print_bad_edid) {
   printk(KERN_ERR Raw EDID:\n);
   print_hex_dump(KERN_ERR,  \t, DUMP_PREFIX_NONE, 16, 1,
  raw_edid, EDID_LENGTH, false);
   }
 - return 0;
 + return false;
  }
  EXPORT_SYMBOL(drm_edid_block_valid);
  
 -- 
 1.7.4.1
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[ANNOUNCE] libdrm 2.4.46

[Dave Airlie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Release because I want the cursor ioctls released,
also haswell and radeon ids.

Alex Deucher (3):
  radeon: add CIK chip families
  radeon: add Bonaire pci ids
  radeon: add kabini pci ids

Damien Lespiau (3):
  intel/aub: Sync the AUB defines with mesa's
  intel/aub: Return early if we disable aub dumps
  intel/aub: Implement a way to specify the output .aub filename

Dave Airlie (2):
  drm: add hotspot cursor interface support.
  libdrm: bump to 2.4.46

Mark Kettenis (1):
  radeon: correct RADEON_GEM_WAIT_IDLE use

Rob Clark (3):
  freedreno: add handle and name tracking
  freedreno: add some asserts
  freedreno: also remove from name table on bo delete

Rodrigo Vivi (2):
  intel: Fix Haswell GT3 names.
  intel: Adding more reserved PCI IDs for Haswell.

Ville Syrjälä (1):
  modetest: Make RGB565 pwetty too

git tag: libdrm-2.4.46

http://dri.freedesktop.org/libdrm/libdrm-2.4.46.tar.bz2
MD5:  9cba217fd3daa10b1d052ec60d3aa7d5  libdrm-2.4.46.tar.bz2
SHA1: b3a0fac0c8ef9110dce32feb8004f53f0081dea4  libdrm-2.4.46.tar.bz2
SHA256: 33cf320dad4e8060768714792e12643ddf6756a719d262ba7d60b39c2b2650f1  
libdrm-2.4.46.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.46.tar.gz
MD5:  b454a43366eb386294f87a5cd16699e6  libdrm-2.4.46.tar.gz
SHA1: dbd99aca49db5fa87e49fec5fa3d2eba5a781185  libdrm-2.4.46.tar.gz
SHA256: 75dda05aa7717594d48f215d598525ffb7d4c60f60cc3fc2084672ca5d3ae039  
libdrm-2.4.46.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJR0o14AAoJEAx081l5xIa+QOAP/A9wAIljpxy6KGYC7LutVzTy
oncZk3ivkKI0a+rAqXP5DrV+Fu9Gkmx/rSNrHw/VwdY83EenRbyijIQk4QQjj0AN
ibPWyWTIlc+sdJoXBEieqWdSxZLqCgT3GIhaBmnkVBEPyse2qu5ob1MZQYX62tKJ
MZ45OpW8glhEvBdKrcvN1wfe710MH1RYwwgIrkmD1RPuCFyhIOnkj/hMICCnBOil
vkng1tW7TitW84YFsUDu4rV6iug9OSnIvNNN/j810QREGyNdhPqPV5rhv8zncjRk
cg3nFmcjyTnzHX0Eq1gHQenam0ocHvfGuknQ2tiIaH4MiN7TIg+39NK8Zi4OvAMj
DfxlYHna3xBpnhTKuyRkG/1/BrUFr1f8vnw2yqV5qUBJeZ5uZIEt7rAGZcMOkKuE
LCA9boM1KgNaAG4i6NPaWJwavM25DFYDV/I6Xy8xeFPvChslc7VBmei9B53NNAx8
k3yyz0+LICjJo8XKZouueK6UaZFE7+9lHhLp8qxXMqLH/cErdUirUEDUvB3YdUEI
bjq41nMsIYnBCIdkNpiUQVUP5rGeUEsninZO7nfVRV6sQXVI5rsb+iob6aA1rwJM
am+/3vppn1oTjrvFxywY6ctBIu1Ko+DCHmo/1WpdNNnMIXRr24FMXYrkUcORrp7Z
ZQm76FmMzsSxgCv2/iUT
=esMI
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

On Tue, Jul 02, 2013 at 09:13:34AM +0100, Chris Wilson wrote:
 On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote:
  On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote:
   On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote:
Every other place properly checks whether we've managed to set
up the stolen allocator at boot-up properly, with the exception
of the cleanup code. Which results in an ugly

*ERROR* Memory manager not clean. Delaying takedown

at module unload time since the drm_mm isn't initialized at all.

v2: While at it check whether the stolen drm_mm is initialized instead
of the more obscure stolen_base == 0 check.

v3: Fix up the logic. Also we need to keep the stolen_base check in
i915_gem_object_create_stolen_for_preallocated since that can be
called before stolen memory is fully set up. Spotted by Chris Wilson.
   
   Can you grab a backtrace for stolen_base  !initialized(stolen)? Since
   preallocated touches the stolen mm, it should be setup by that point.
  
  I haven't seen it blow up at runtime, but we have special code in
  i915_gem_object_create_stolen_for_preallocated which handles the
  !drm_mm_initialized case. So I've figured we need this. Iirc it's to allow
  us to wrap the vbios framebuffer.
 
 That's a different drm_mm for the ggtt. We still need the stolen mm setup
 in order to allocate our memory (as we don't have the same dance to
 reconstruct the reserved blocks upon initialisation of stolen).

Oh right, I'll update the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Seung-Woo Kim]

Hello Ville,

Thanks for comment.

On 2013년 07월 02일 17:29, Ville Syrjälä wrote:
 On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote:
 If raw_edid of drm_edid_block_vaild() is null, it will crash, so
 checking in bad label is removed and instead assertion is added at
 the top of the function.
 The type of return for the function is bool, so it fixes to return
 true and false instead of 1 and 0.

 Signed-off-by: Seung-Woo Kim sw0312@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 chages from v1
 - NULL checking is replaced with WARN_ON() as Daniel commented
 - all return value is replaced as true/false as Chris and Daniel commented

  drivers/gpu/drm/drm_edid.c |8 +---
  1 files changed, 5 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index 2dc1a60..1117f02 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -968,6 +968,8 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
 print_bad_edid)
  u8 csum = 0;
  struct edid *edid = (struct edid *)raw_edid;
  
 +WARN_ON(!raw_edid);
 +
 
 I don't see this buying us anything. All you get is two backtraces
 instead of one.
 
 if (WARN_ON(!raw_edid))
   return false;
 
 would make more sense if we want tolerate programmer errors a bit
 better. I'm not a huge fan of such defensive programming though
 since it tends to make it less clear what the function actually
 expects from you. But here the WARN_ON() would at least make it
 clear that it's not meant to happen.
 

Ok, it looks better than just WARN_ON(). I'll updated patch as you
commented.

Best Regards,
- Seung-Woo Kim

 
  if (edid_fixup  8 || edid_fixup  0)
  edid_fixup = 6;
  
 @@ -1010,15 +1012,15 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, 
 bool print_bad_edid)
  break;
  }
  
 -return 1;
 +return true;
  
  bad:
 -if (raw_edid  print_bad_edid) {
 +if (print_bad_edid) {
  printk(KERN_ERR Raw EDID:\n);
  print_hex_dump(KERN_ERR,  \t, DUMP_PREFIX_NONE, 16, 1,
 raw_edid, EDID_LENGTH, false);
  }
 -return 0;
 +return false;
  }
  EXPORT_SYMBOL(drm_edid_block_valid);
  
 -- 
 1.7.4.1

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

-- 
Seung-Woo Kim
Samsung Software RD Center
--

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

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

Every other place properly checks whether we've managed to set
up the stolen allocator at boot-up properly, with the exception
of the cleanup code. Which results in an ugly

*ERROR* Memory manager not clean. Delaying takedown

at module unload time since the drm_mm isn't initialized at all.

v2: While at it check whether the stolen drm_mm is initialized instead
of the more obscure stolen_base == 0 check.

v3: Fix up the logic. Also we need to keep the stolen_base check in
i915_gem_object_create_stolen_for_preallocated since that can be
called before stolen memory is fully set up. Spotted by Chris Wilson.

v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
the check is for the dev_priv-mm.gtt_space drm_mm, the stolen
allocatot must already be initialized when calling that function (if
we indeed have stolen memory).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
Cc: Chris Wilson ch...@chris-wilson.co.uk
Tested-by: lu hua huax...@intel.com (v3)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 8e02344..0f8cf62 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device 
*dev, int size)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
 
-   if (dev_priv-mm.stolen_base == 0)
+   if (!drm_mm_initialized(dev_priv-mm.stolen))
return -ENODEV;
 
if (size  dev_priv-fbc.size)
@@ -179,6 +179,9 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
 
+   if (!drm_mm_initialized(dev_priv-mm.stolen))
+   return;
+
i915_gem_stolen_cleanup_compression(dev);
drm_mm_takedown(dev_priv-mm.stolen);
 }
@@ -300,7 +303,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 
size)
struct drm_i915_gem_object *obj;
struct drm_mm_node *stolen;
 
-   if (dev_priv-mm.stolen_base == 0)
+   if (!drm_mm_initialized(dev_priv-mm.stolen))
return NULL;
 
DRM_DEBUG_KMS(creating stolen object: size=%x\n, size);
@@ -331,7 +334,7 @@ i915_gem_object_create_stolen_for_preallocated(struct 
drm_device *dev,
struct drm_i915_gem_object *obj;
struct drm_mm_node *stolen;
 
-   if (dev_priv-mm.stolen_base == 0)
+   if (!drm_mm_initialized(dev_priv-mm.stolen))
return NULL;
 
DRM_DEBUG_KMS(creating preallocated stolen object: stolen_offset=%x, 
gtt_offset=%x, size=%x\n,
-- 
1.8.3.1

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

[PATCH v3 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Seung-Woo Kim]

If raw_edid of drm_edid_block_vaild() is null, it will crash, so
checking in bad label is removed and instead assertion is added at
the top of the function.
The type of return for the function is bool, so it fixes to return
true and false instead of 1 and 0.

Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
change from v2
- check result of WARN_ON() as Ville's comment
chages from v1
- NULL checking is replaced with WARN_ON() as Daniel commented
- all return value is replaced as true/false as Chris and Daniel commented

 drivers/gpu/drm/drm_edid.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2dc1a60..95d6f4b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -968,6 +968,9 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid)
u8 csum = 0;
struct edid *edid = (struct edid *)raw_edid;
 
+   if (WARN_ON(!raw_edid))
+   return false;
+
if (edid_fixup  8 || edid_fixup  0)
edid_fixup = 6;
 
@@ -1010,15 +1013,15 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid)
break;
}
 
-   return 1;
+   return true;
 
 bad:
-   if (raw_edid  print_bad_edid) {
+   if (print_bad_edid) {
printk(KERN_ERR Raw EDID:\n);
print_hex_dump(KERN_ERR,  \t, DUMP_PREFIX_NONE, 16, 1,
   raw_edid, EDID_LENGTH, false);
}
-   return 0;
+   return false;
 }
 EXPORT_SYMBOL(drm_edid_block_valid);
 
-- 
1.7.4.1

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

[Bug 66425] failed testing IB on ring 5 when suspending to disk

[bugzilla-daemon]

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

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Christian König deathsim...@vodafone.de ---
(In reply to comment #2)
 (In reply to comment #1)
  This is a mac?
 
 Yes.  Macbookpro8,2

What else should it be? I'm really wondering if we shouldn't just disable UVD
on Macs (with an option to override it of course).

 
 Also, this doesn't happen with a 3.9.7 kernel.
 
 It seems to be related to the UVD stuff that was added to 3.10.  Ring 5
 appears to be related to this and it doesn't appear in the 3.9 kernels.

Yes, indeed UVD is ring 5 and that is not present in older kernels. Are you
sure that the system instability is related to this? Cause except for non
working UVD it shouldn't affect the driver at all.

-- 
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] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Chris Wilson]

On Tue, Jul 02, 2013 at 10:48:31AM +0200, Daniel Vetter wrote:
 Every other place properly checks whether we've managed to set
 up the stolen allocator at boot-up properly, with the exception
 of the cleanup code. Which results in an ugly
 
 *ERROR* Memory manager not clean. Delaying takedown
 
 at module unload time since the drm_mm isn't initialized at all.
 
 v2: While at it check whether the stolen drm_mm is initialized instead
 of the more obscure stolen_base == 0 check.
 
 v3: Fix up the logic. Also we need to keep the stolen_base check in
 i915_gem_object_create_stolen_for_preallocated since that can be
 called before stolen memory is fully set up. Spotted by Chris Wilson.
 
 v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
 the check is for the dev_priv-mm.gtt_space drm_mm, the stolen
 allocatot must already be initialized when calling that function (if
 we indeed have stolen memory).
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
 Cc: Chris Wilson ch...@chris-wilson.co.uk
 Tested-by: lu hua huax...@intel.com (v3)
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk

Once thing I noticed is that we should probably warn if vlv_reserved =
stolen_size.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

[Daniel Vetter]

On Tue, Jul 02, 2013 at 10:25:17AM +0100, Chris Wilson wrote:
 On Tue, Jul 02, 2013 at 10:48:31AM +0200, Daniel Vetter wrote:
  Every other place properly checks whether we've managed to set
  up the stolen allocator at boot-up properly, with the exception
  of the cleanup code. Which results in an ugly
  
  *ERROR* Memory manager not clean. Delaying takedown
  
  at module unload time since the drm_mm isn't initialized at all.
  
  v2: While at it check whether the stolen drm_mm is initialized instead
  of the more obscure stolen_base == 0 check.
  
  v3: Fix up the logic. Also we need to keep the stolen_base check in
  i915_gem_object_create_stolen_for_preallocated since that can be
  called before stolen memory is fully set up. Spotted by Chris Wilson.
  
  v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
  the check is for the dev_priv-mm.gtt_space drm_mm, the stolen
  allocatot must already be initialized when calling that function (if
  we indeed have stolen memory).
  
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
  Cc: Chris Wilson ch...@chris-wilson.co.uk
  Tested-by: lu hua huax...@intel.com (v3)
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk

Thanks for the review, merged to -fixes.
 
 Once thing I noticed is that we should probably warn if vlv_reserved =
 stolen_size.

I've added that patch to my queue, I'll submit it together with the gm45
reset fixes (once QA has tested them).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: drm init call takes large time

[Ville Syrjälä]

On Sun, Jun 30, 2013 at 05:41:59AM +0500, Abbas Raza wrote:
 From: Abbas Raza abbas_r...@mentor.com
 
 DRM_INFO calls in the drm init routines are causing a large delay at boot time
 due to which imx_drm_init call average takes around 26 ms. Changing DRM_INFO 
 to
 DRM_DEBUG reduces startup time to  3ms.

Serial console enabled?

Not that I think these printks are particularly useful...

 Signed-off-by: Abbas Raza abbas_r...@mentor.com
 CC: David Airlie airl...@linux.ie
 Acked-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
 ---
  drivers/gpu/drm/drm_irq.c  | 6 +++---
  drivers/gpu/drm/drm_platform.c | 2 +-
  2 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
 index c798eea..782f5ff 100644
 --- a/drivers/gpu/drm/drm_irq.c
 +++ b/drivers/gpu/drm/drm_irq.c
 @@ -252,13 +252,13 @@ int drm_vblank_init(struct drm_device *dev, int 
 num_crtcs)
   if (!dev-_vblank_time)
   goto err;
  
 - DRM_INFO(Supports vblank timestamp caching Rev 1 (10.10.2010).\n);
 + DRM_DEBUG(Supports vblank timestamp caching Rev 1 (10.10.2010).\n);
  
   /* Driver specific high-precision vblank timestamping supported? */
   if (dev-driver-get_vblank_timestamp)
 - DRM_INFO(Driver supports precise vblank timestamp query.\n);
 + DRM_DEBUG(Driver supports precise vblank timestamp query.\n);
   else
 - DRM_INFO(No driver support for vblank timestamp query.\n);
 + DRM_DEBUG(No driver support for vblank timestamp query.\n);
  
   /* Zero per-crtc vblank stuff */
   for (i = 0; i  num_crtcs; i++) {
 diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
 index 82431dc..7649963 100644
 --- a/drivers/gpu/drm/drm_platform.c
 +++ b/drivers/gpu/drm/drm_platform.c
 @@ -92,7 +92,7 @@ int drm_get_platform_dev(struct platform_device *platdev,
  
   mutex_unlock(drm_global_mutex);
  
 - DRM_INFO(Initialized %s %d.%d.%d %s on minor %d\n,
 + DRM_DEBUG(Initialized %s %d.%d.%d %s on minor %d\n,
driver-name, driver-major, driver-minor, driver-patchlevel,
driver-date, dev-primary-index);
  
 -- 
 1.8.2
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

[Seung-Woo Kim]

From: YoungJun Cho yj44@samsung.com

When drm iommu is not supported, buf-pages has to be allocated
and assigned to phys_to_page() result, which type is struct page *.
So it is sufficient to allocate buf-pages with multiple struct
page pointer size.

Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 22865ba..3200622 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -57,7 +57,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
dma_addr_t start_addr;
unsigned int i = 0;
 
-   buf-pages = kzalloc(sizeof(struct page) * nr_pages,
+   buf-pages = kzalloc(sizeof(struct page *) * nr_pages,
GFP_KERNEL);
if (!buf-pages) {
DRM_ERROR(failed to allocate pages.\n);
-- 
1.7.9.5

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

Re: [PATCH v4 3/3] drm: fix error routines in drm_open_helper

[Chris Wilson]

On Tue, Jul 02, 2013 at 09:53:28AM +0900, Seung-Woo Kim wrote:
 From: YoungJun Cho yj44@samsung.com
 
 There are missing parts to handle error in drm_open_helper().
 The priv-minor, assigned by idr_find() which can return NULL,
 should be checked whether it is NULL or not before referencing it.
 put_pid(), drm_gem_release(), and drm_prime_destory_file_private()
 should be called when error happens after their pair functions are
 called. If an error occurs after executing dev-driver-open()
 which allocates driver specific per-file private data, then the
 private data should be released.
 
 Signed-off-by: YoungJun Cho yj44@samsung.com
 Signed-off-by: Seung-Woo Kim sw0312@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

I can't see anything else that we setup and miss freeing along the
failed open, so if it compiles ;-)
Reviewed-by: Chris Wilson chris-wilson.co.uk
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Chris Wilson]

On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote:
 If raw_edid of drm_edid_block_vaild() is null, it will crash, so
 checking in bad label is removed and instead assertion is added at
 the top of the function.
 The type of return for the function is bool, so it fixes to return
 true and false instead of 1 and 0.
 
 Signed-off-by: Seung-Woo Kim sw0312@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

if (WARN_ON(raw_edid == NULL))
   return false;

Otherwise it is just a WARN_ON() followed by a BUG() :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

[Chris Wilson]

On Tue, Jul 02, 2013 at 05:57:04PM +0900, Seung-Woo Kim wrote:
 If raw_edid of drm_edid_block_vaild() is null, it will crash, so
 checking in bad label is removed and instead assertion is added at
 the top of the function.
 The type of return for the function is bool, so it fixes to return
 true and false instead of 1 and 0.
 
 Signed-off-by: Seung-Woo Kim sw0312@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel