Re: Mesa >= 23.3.x and python 2.6 ...

[Matt Turner]

On Thu, Jan 18, 2024 at 10:22 AM Stefan Dirsch  wrote:
> I noticed that with version 23.3.x Mesa no longer can be built with python
> 2.6. It still worked with Mesa 23.2.1.

For anyone who got this far and was completely incredulous... this
(and the subject) is typo'd -- the problem is about Python 3.6, not
2.6.

Re: [PATCH v10 00/15] dma-fence: Deadline awareness

[Matt Turner]

On Wed, Mar 8, 2023 at 10:53 AM Rob Clark  wrote:
>
> From: Rob Clark 
>
> This series adds a deadline hint to fences, so realtime deadlines
> such as vblank can be communicated to the fence signaller for power/
> frequency management decisions.
>
> This is partially inspired by a trick i915 does, but implemented
> via dma-fence for a couple of reasons:
>
> 1) To continue to be able to use the atomic helpers
> 2) To support cases where display and gpu are different drivers
>
> This iteration adds a dma-fence ioctl to set a deadline (both to
> support igt-tests, and compositors which delay decisions about which
> client buffer to display), and a sw_sync ioctl to read back the
> deadline.  IGT tests utilizing these can be found at:


I read through the series and didn't spot anything. Have a rather weak

Reviewed-by: Matt Turner 

Thanks!

Re: [PATCH v9 15/15] drm/i915: Add deadline based boost support

[Matt Turner]

On Fri, Mar 3, 2023 at 10:08 AM Tvrtko Ursulin
 wrote:
>
>
> On 03/03/2023 14:48, Rob Clark wrote:
> > On Fri, Mar 3, 2023 at 1:58 AM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 03/03/2023 03:21, Rodrigo Vivi wrote:
> >>> On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote:
>  From: Rob Clark 
> 
> >>>
> >>> missing some wording here...
> >>>
>  v2: rebase
> 
>  Signed-off-by: Rob Clark 
>  ---
> drivers/gpu/drm/i915/i915_request.c | 20 
> 1 file changed, 20 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/i915/i915_request.c 
>  b/drivers/gpu/drm/i915/i915_request.c
>  index 7503dcb9043b..44491e7e214c 100644
>  --- a/drivers/gpu/drm/i915/i915_request.c
>  +++ b/drivers/gpu/drm/i915/i915_request.c
>  @@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct 
>  dma_fence *fence)
>    return i915_request_enable_breadcrumb(to_request(fence));
> }
> 
>  +static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t 
>  deadline)
>  +{
>  +struct i915_request *rq = to_request(fence);
>  +
>  +if (i915_request_completed(rq))
>  +return;
>  +
>  +if (i915_request_started(rq))
>  +return;
> >>>
> >>> why do we skip the boost if already started?
> >>> don't we want to boost the freq anyway?
> >>
> >> I'd wager Rob is just copying the current i915 wait boost logic.
> >
> > Yup, and probably incorrectly.. Matt reported fewer boosts/sec
> > compared to your RFC, this could be the bug
>
> Hm, there I have preserved this same !i915_request_started logic.
>
> Presumably it's not just fewer boosts but lower performance. How is he
> setting the deadline? Somehow from clFlush or so?
>
> Regards,
>
> Tvrtko
>
> P.S. Take note that I did not post the latest version of my RFC. The one
> where I fix the fence chain and array misses you pointed out. I did not
> think it would be worthwhile given no universal love for it, but if
> people are testing with it more widely that I was aware perhaps I should.

Yep, that would be great. We're interested in it for ChromeOS. Please
Cc me on the series when you send it.

Re: gitlab.fd.o financial situation and impact on services

[Matt Turner]

On Fri, Feb 28, 2020 at 12:00 AM Daniel Stone  wrote:
>
> Hi Matt,
>
> On Thu, 27 Feb 2020 at 23:45, Matt Turner  wrote:
> > We're paying 75K USD for the bandwidth to transfer data from the
> > GitLab cloud instance. i.e., for viewing the https site, for
> > cloning/updating git repos, and for downloading CI artifacts/images to
> > the testing machines (AFAIU).
>
> I believe that in January, we had $2082 of network cost (almost
> entirely egress; ingress is basically free) and $1750 of cloud-storage
> cost (almost all of which was download). That's based on 16TB of
> cloud-storage (CI artifacts, container images, file uploads, Git LFS)
> egress and 17.9TB of other egress (the web service itself, repo
> activity). Projecting that out gives us roughly $45k of network
> activity alone, so it looks like this figure is based on a projected
> increase of ~50%.
>
> The actual compute capacity is closer to $1150/month.

Could we have the full GCP bill posted?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: gitlab.fd.o financial situation and impact on services

[Matt Turner]

On Thu, Feb 27, 2020 at 1:27 PM Daniel Vetter  wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes all the
> CI integration. Modern development process and tooling, yay!
>
> The bad news: The cost in growth has also been tremendous, and it's
> breaking our bank account. With reasonable estimates for continued
> growth we're expecting hosting expenses totalling 75k USD this year,
> and 90k USD next year. With the current sponsors we've set up we can't
> sustain that. We estimate that hosting expenses for gitlab.fd.o
> without any of the CI features enabled would total 30k USD, which is
> within X.org's ability to support through various sponsorships, mostly
> through XDC.
>
> Note that X.org does no longer sponsor any CI runners themselves,
> we've stopped that. The huge additional expenses are all just in
> storing and serving build artifacts and images to outside CI runners
> sponsored by various companies. A related topic is that with the
> growth in fd.o it's becoming infeasible to maintain it all on
> volunteer admin time. X.org is therefore also looking for admin
> sponsorship, at least medium term.
>
> Assuming that we want cash flow reserves for one year of gitlab.fd.o
> (without CI support) and a trimmed XDC and assuming no sponsor payment
> meanwhile, we'd have to cut CI services somewhere between May and June
> this year. The board is of course working on acquiring sponsors, but
> filling a shortfall of this magnitude is neither easy nor quick work,
> and we therefore decided to give an early warning as soon as possible.
> Any help in finding sponsors for fd.o is very much appreciated.

Some clarification I got from Daniel in a private conversation, since
I was confused about what the money was paying for exactly:

We're paying 75K USD for the bandwidth to transfer data from the
GitLab cloud instance. i.e., for viewing the https site, for
cloning/updating git repos, and for downloading CI artifacts/images to
the testing machines (AFAIU).

I was not aware that we were being charged for anything wrt GitLab
hosting yet (and neither was anyone on my team at Intel that I've
asked). This... kind of needs to be communicated.

A consistent concern put forth when we were discussing switching to
GitLab and building CI was... how do we pay for it. It felt like that
concern was always handwaved away. I heard many times that if we
needed more runners that we could just ask Google to spin up a few
more. If we needed testing machines they'd be donated. No one
mentioned that all the while we were paying for bandwidth... Perhaps
people building the CI would make different decisions about its
structure if they knew it was going to wipe out the bank account.

What percentage of the bandwidth is consumed by transferring CI
images, etc? Wouldn't 75K USD would be enough to buy all the testing
machines we need and host them within Google or wherever so we don't
need to pay for huge amounts of bandwidth?

I understand that self-hosting was attractive so that we didn't find
ourselves on the SourceForge-equivalent hosting platform of 2022, but
is that risk real enough to justify spending 75K+ per year? If we were
hosted on gitlab.com or github.com, we wouldn't be paying for
transferring CI images to CI test machines, etc, would we?

So what do we do now? Have we painted ourselves into a corner?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] XDC 2017 feedback

[Matt Turner]

On Wed, Sep 27, 2017 at 10:07 PM, Rob Clark  wrote:
> If you had known of the khr dates, and brought it up in Feb (or really
> somewhat earlier, given that XDC is roughly same time each year +/-
> few weeks), that *might* have been early enough to move things.

That's unfair. It's part of the X.Org board's responsibilities to plan
conferences and that means being aware of potential conflicts. In
February, six of the eight members of the X.Org board worked for
companies with Khronos access (that's not including Keith who I
suspect has access as well).

I replied to the 2017-03-02 minutes and noted the conflict, but as you
say that was too late. Unfortunately that was the first time a date
was publicly announced, so I'm not really sure what could have been
done from outside the X.Org board.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 21 March 2017 at 18:06, Matt Turner <matts...@gmail.com> wrote:
>> (1) Non-recursive automake is necessary for parallel build performance
> Fully agree
>
>> (2) Non-recursive automake is intractably unmaintainable for
>> sufficiently large projects
> Not sure I agree here. Do the src/intel/Makefile* files, seem unmaintainable ?

Not by itself.

src/intel only accounts for 70 thousand lines of code. Mesa is 1.25 million.

>> (3) Mesa is a sufficiently large project
>>
> Again - fully agree.
>
>> Therefore using automake will be either bad for parallel build
>> performance, unmaintainable, or both.
>>
>> Meson aims to be a build system actually capable of replacing
>> autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
>> cleaner domain specific language for writing the build rules, while
>> generating non-recursive ninja build files. It does not use libtool.
>> It supports Windows. It supports cross compilation.
>>
> Does it support, Darwin/MacOSX, Cygwin, any of the BSDs, Solaris (and
> alike) platforms,

Its website says "Linux, OSX, Windows, Gcc, Clang, Visual Studio and
others". I see Meson in FreeBSD's ports. It's written in python, so I
expect it will support any of the platforms we care about.

> How about Android - Android.mk or Blueprint.

We have gone over this.

> Does it have "dist", "check", "distcheck" or less commonly used

Our thinking is that by switching to a build system that doesn't
require large amounts of generated code (configure, Makefile.in, etc),
we will stop shipping the code generated by the build system in the
tarballs (which would just be created by git archive). None of that is
set in stone.

> "ctags" "cscope"  targets ?

I don't know.

>> And it has momentum: libepoxy already has a Meson build system. Others
>> in the X.Org community are experimenting with it for libinput, Wayland
>> and Weston, and the xserver.
>>
>> All of that makes Meson very compelling.
> That's the thing - I'm never said that it's _not_ a very compelling project.
> I'm saying that it's not there yet - mostly due to the list above.

Perfect. Since no one claimed it's "there yet" there is nothing to
disagree about.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 21 March 2017 at 15:57, Matt Turner <matts...@gmail.com> wrote:
>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.veli...@gmail.com> 
>> wrote:
>>> On 20 March 2017 at 18:30, Matt Turner <matts...@gmail.com> wrote:
>>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.veli...@gmail.com> 
>>>> wrote:
>>>>> Seems like we ended up all over the place, so let me try afresh.
>>>>>
>>>>> Above all:
>>>>>  - Saying "I don't care" about your users is arrogant - let us _not_
>>>>> do that, please ?
>>>>
>>>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>>>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>>>> GCC,
>>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>>> wasn't OpenBSD to blame here ;-)
>>>
>>>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>>>> NetBSD keep Mesa as part of the core operating system, and as such
>>>> don't suffer from these problems.
>>>>
>>>> For better or worse, they have made their choices and they get to live
>>>> with them. We are not beholden to them.
>>>>
>>> Overall this hunk seems misplaced. I go agree that we should not cater
>>> for all their needs. At the same time, intentionally, breaking things
>>> while we all can coexist is very strange.
>>>
>>>>> Even Linux distribution maintainers have responded that "upstream does
>>>>> not care us", which is indicative that we should be more careful what
>>>>> we say.
>>>>
>>>> Citation needed.
>>>>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>>> couple of instances where I've been contacted in private.
>>>
>>>>> For the rest - we're dealing with two orthogonal issues here:
>>>>>
>>>>> * Multiple build systems
>>>>> I believe we'll all agree that I might be the person who's been in all
>>>>> the build systems the most.
>>>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>>>
>>>> No one is advocating dropping all of the existing build systems yet.
>>>>
>>>> This patch is an RFC for a smaller project to start the discussion about 
>>>> Mesa.
>>>>
>>>>>  - [currently] there is no viable solution for Android
>>>>
>>>> Acknowledged. Dylan is going to see if this is something that can be
>>>> solved in upstream Meson.
>>>>
>>> I would suggest checking with Android people as well, as Meson.
>>> There's some plans on moving to yet another build system - Blueprint.
>>>
>>>>>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>>>> boat.
>>>>
>>>> Solaris is a closed source operating system whose developers do not
>>>> contribute to the project. We do not need to base our decisions on
>>>> them.
>>>>
>>>> Mesa is not subject to ridiculous requirements (like in the case of
>>>> OpenBSD) in FreeBSD and NetBSD.
>>> Again - not a requirement, but coexistence.
>>>
>>>> Mesa depends on gmake in FreeBSD's
>>>> ports, for instance.
>>>>
>>> That amongst others is a bug in their packaging.
>>
>> That is not even remotely the point.
>>
>> My point is that they are not subjecting themselves (and us by
>> extension, since you want to let them) to such ridiculous
>> requirements.
>>
> I will kindly ask you to keep these adjectives outside of what aims to
> be (?) technical discussion.

Huh?

Didn't you call us arrogant in this very thread? Didn't you suggest
we're immature?

> And on your question - 50-100 lines worth of compatibility changes
> across a 6.5kloc of build system is not that unreasonable, right ?

You're still not understanding my point.

>>>> So I don't think any of this is true.
>>>>
>>> I'd suggest giving it a try then - grab a non-GNU make, a release
>>> tarball and let me know if you spot any issues.
>>>
>>>>> These projects have been getting closer to upstream and "forcing" the

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 10:10 PM, Jonathan Gray <j...@jsg.id.au> wrote:
> On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.veli...@gmail.com> 
>> wrote:
>> > Seems like we ended up all over the place, so let me try afresh.
>> >
>> > Above all:
>> >  - Saying "I don't care" about your users is arrogant - let us _not_
>> > do that, please ?
>>
>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>> GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>> NetBSD keep Mesa as part of the core operating system, and as such
>> don't suffer from these problems.
>>
>> For better or worse, they have made their choices and they get to live
>> with them. We are not beholden to them.
>
> This isn't a situation like OpenSSH where people explicitly go out of
> their way to provide support for and test multiple systems and add
> support for horrible things like PAM.  It is more along the lines of
> considering integrating patches sent by others to make code build.

I think we (and you) have been able to deal with compiler problems
reasonably well. I don't have a particular problem taking patches for
things like that. GCC is just an example of the problem.

My core point is that OpenBSD has made choices to build Mesa with
tools and versions no one else uses. If we want to add a new build
dependency not in OpenBSD's core, I don't think it's fair for
OpenBSD's choices prevent us from moving forward.

>> > Even Linux distribution maintainers have responded that "upstream does
>> > not care us", which is indicative that we should be more careful what
>> > we say.
>>
>> Citation needed.
>>
>> > For the rest - we're dealing with two orthogonal issues here:
>> >
>> > * Multiple build systems
>> > I believe we'll all agree that I might be the person who's been in all
>> > the build systems the most.
>> > Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>
>> No one is advocating dropping all of the existing build systems yet.
>>
>> This patch is an RFC for a smaller project to start the discussion about 
>> Mesa.
>>
>> >  - [currently] there is no viable solution for Android
>>
>> Acknowledged. Dylan is going to see if this is something that can be
>> solved in upstream Meson.
>>
>> >  - dropping the Autotools will lead to OpenBSD and NetBSD having to
>> > write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>> > boat.
>>
>> Solaris is a closed source operating system whose developers do not
>> contribute to the project. We do not need to base our decisions on
>> them.
>
> So Mesa will remove support for libglvnd then?  I don't see a lot of
> open source non-Mesa alternatives for libGL.

Huh? libglvnd is free software.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 10:00 PM, Jonathan Gray <j...@jsg.id.au> wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner <matts...@gmail.com> wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.veli...@gmail.com> 
>> > > wrote:
>> > > > Seems like we ended up all over the place, so let me try afresh.
>> > > >
>> > > > Above all:
>> > > >  - Saying "I don't care" about your users is arrogant - let us _not_
>> > > > do that, please ?
>> > >
>> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
>> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
>> > > GCC,
>> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> > wasn't OpenBSD to blame here ;-)
>>
>> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
>> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>>
>> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
>> rather not go through the upgrade hassle if I don't have to."
>>
>> Followed by Jose "We're internally building and shipping Mesa compiled with
>> GCC 4.4 (more specifically 4.4.3).
>>
>> It's fine if you require GCC 4.8 on automake, but please leave support
>> for GCC 4.4.x in SCons."
>>
>> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
>> various features backported, from what I understand Mesa would not build on
>> a real GCC 4.2 release and we should not be using it as a min version. IMO
>> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
>> the min GCC version.
>>
>> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
>> deal with it if we move on.
>
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.

How can we reasonably do that? In the context of the patch you inlined
-- what would make us believe designated initializers aren't available
in some version of GCC and we should test for it? They're just a C99
feature AFAIK.

And what would we do if we check and they're not available? Presumably
you're not advocating for #ifdef'ing and having two pieces of the same
code.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 20 March 2017 at 18:30, Matt Turner <matts...@gmail.com> wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.veli...@gmail.com> 
>> wrote:
>>> Seems like we ended up all over the place, so let me try afresh.
>>>
>>> Above all:
>>>  - Saying "I don't care" about your users is arrogant - let us _not_
>>> do that, please ?
>>
>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>> GCC,
> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> wasn't OpenBSD to blame here ;-)
>
>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>> NetBSD keep Mesa as part of the core operating system, and as such
>> don't suffer from these problems.
>>
>> For better or worse, they have made their choices and they get to live
>> with them. We are not beholden to them.
>>
> Overall this hunk seems misplaced. I go agree that we should not cater
> for all their needs. At the same time, intentionally, breaking things
> while we all can coexist is very strange.
>
>>> Even Linux distribution maintainers have responded that "upstream does
>>> not care us", which is indicative that we should be more careful what
>>> we say.
>>
>> Citation needed.
>>
> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
> couple of instances where I've been contacted in private.
>
>>> For the rest - we're dealing with two orthogonal issues here:
>>>
>>> * Multiple build systems
>>> I believe we'll all agree that I might be the person who's been in all
>>> the build systems the most.
>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>
>> No one is advocating dropping all of the existing build systems yet.
>>
>> This patch is an RFC for a smaller project to start the discussion about 
>> Mesa.
>>
>>>  - [currently] there is no viable solution for Android
>>
>> Acknowledged. Dylan is going to see if this is something that can be
>> solved in upstream Meson.
>>
> I would suggest checking with Android people as well, as Meson.
> There's some plans on moving to yet another build system - Blueprint.
>
>>>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>> boat.
>>
>> Solaris is a closed source operating system whose developers do not
>> contribute to the project. We do not need to base our decisions on
>> them.
>>
>> Mesa is not subject to ridiculous requirements (like in the case of
>> OpenBSD) in FreeBSD and NetBSD.
> Again - not a requirement, but coexistence.
>
>> Mesa depends on gmake in FreeBSD's
>> ports, for instance.
>>
> That amongst others is a bug in their packaging.

That is not even remotely the point.

My point is that they are not subjecting themselves (and us by
extension, since you want to let them) to such ridiculous
requirements.

>> So I don't think any of this is true.
>>
> I'd suggest giving it a try then - grab a non-GNU make, a release
> tarball and let me know if you spot any issues.
>
>>> These projects have been getting closer to upstream and "forcing" the
>>> extra obstacle is effectively giving them the middle finger.
>>
>> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>>
> Can we stop with the GCC thing ? Can we point to a place where we want
> to use feature A introduced with GCC B and we don't ?

Are you freaking serious?!

This happens *all* the time. It happened like two days ago with commit
28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
happened at least once in the previous month, and every month before
that.

> The anonymous unions/structs for example require newer GCC and we use
> them extensively. If anything we have the workaround(s) for MSVC's
> lack of designated initializers.

We actually have

if test "x$USE_GNU99" = xyes; then
CFLAGS="$CFLAGS -std=gnu99"
else
CFLAGS="$CFLAGS -std=c99"
fi

in configure.ac to work around gcc-4.4 incompatibilities.

> Not to mention that some/many of the restrictions are imposed by very
> older enterprise linuxes.

which eventually go out of support and those requirements disappear.
Unlike OpenBSD's insistence on using the last GPLv2 GCC.

>>> * Slow build times
&g

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  wrote:
> Seems like we ended up all over the place, so let me try afresh.
>
> Above all:
>  - Saying "I don't care" about your users is arrogant - let us _not_
> do that, please ?

Let's be honest, the OpenBSD is subjecting itself to some pretty
arbitrary restrictions caused including Mesa in its core: 10+ year old
GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
NetBSD keep Mesa as part of the core operating system, and as such
don't suffer from these problems.

For better or worse, they have made their choices and they get to live
with them. We are not beholden to them.

> Even Linux distribution maintainers have responded that "upstream does
> not care us", which is indicative that we should be more careful what
> we say.

Citation needed.

> For the rest - we're dealing with two orthogonal issues here:
>
> * Multiple build systems
> I believe we'll all agree that I might be the person who's been in all
> the build systems the most.
> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:

No one is advocating dropping all of the existing build systems yet.

This patch is an RFC for a smaller project to start the discussion about Mesa.

>  - [currently] there is no viable solution for Android

Acknowledged. Dylan is going to see if this is something that can be
solved in upstream Meson.

>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> boat.

Solaris is a closed source operating system whose developers do not
contribute to the project. We do not need to base our decisions on
them.

Mesa is not subject to ridiculous requirements (like in the case of
OpenBSD) in FreeBSD and NetBSD. Mesa depends on gmake in FreeBSD's
ports, for instance.

So I don't think any of this is true.

> These projects have been getting closer to upstream and "forcing" the
> extra obstacle is effectively giving them the middle finger.

No. Requiring us to compile with a 10 year old GCC is giving a middle finger.

> * Slow build times
> Before we jump into "the next cool thing", let us properly utilise
> what we have at the moment.

It cannot be properly utilized. There is a patch on the list *today*
that is attempting to workaround the *design* of libtool. It's an
issue that's existed... since libtool?

https://bugzilla.redhat.com/show_bug.cgi?id=58664
https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html

>  - I've asked multiple times about numbers behind those "let's make
> the build faster" patches, but never got any :-\

What patches? The patches in this thread? What is your question?

>  - I can improve things but would need access to a fancy XX core
> system to do rudimentary benchmarks/checks and test patches.

Have you ever seen an autotools build system for a project as complex
as Mesa that is both non-recursive and comprehensible? I have not, and
I did a lot of searching. In my opinion, this is an intractable
problem.

... and with Meson it is tractable. And it doesn't use libtool. And it
can replace at least 2 and maybe all three of our build systems.

Those all seem extremely compelling to me, and I think I've done
enough work on Mesa's build system and on a downstream distribution to
have a valuable opinion on the matter.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[ANNOUNCE] libdrm 2.4.72

[Matt Turner]

Alex Deucher (1):
  amdgpu: check parameters in amdgpu_query_gpu_info

Chris Wilson (3):
  intel: Export raw GEM mmap interfaces
  intel: Migrate handle/name lookups from linear lists to hashtables
  intel: Look prime handle up in handle hash table

Eric Anholt (1):
  Silence runtime complaints on platform devices

Junwei Zhang (1):
  amdgpu: add the function to get the marketing name (v4)

Matt Turner (4):
  intel: Add uthash.h to Makefile.sources.
  amdgpu: Add amdgpu_asic_id.h to Makefile.sources.
  freedreno: Add fd_ringbuffer_flush2 to symbol check.
  Bump version for release

Michel Dänzer (3):
  headers: Sync drm{,_mode}.h with the kernel
  Add drmModePageFlipTarget
  intel: Add new symbols to intel-symbol-check

Neil Roberts (1):
  intel: Allow some codenames in INTEL_DEVID_OVERRIDE

Rob Clark (3):
  add libsync.h helper
  freedreno: sync uapi header
  freedreno: add fence fd support

Rob Herring (1):
  Return an -ENODEV from drmGetDevice() when no device was found.

git tag: libdrm-2.4.72

https://dri.freedesktop.org/libdrm/libdrm-2.4.72.tar.bz2
MD5:  5ca170c39609430a3c39f15906523448  libdrm-2.4.72.tar.bz2
SHA1: 371772e90a7db67a7544d6377e6e53b19d6eafe6  libdrm-2.4.72.tar.bz2
SHA256: 16295ef61a7dec87216fd74a06225f68e3ac3e95224cb31454d2577ac46ccc89  
libdrm-2.4.72.tar.bz2
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.72.tar.bz2.sig

https://dri.freedesktop.org/libdrm/libdrm-2.4.72.tar.gz
MD5:  74253ec3d33d2e1b440159f487abbd04  libdrm-2.4.72.tar.gz
SHA1: b8b5bb8483ec27e426e66c49b5a446f4be09e36a  libdrm-2.4.72.tar.gz
SHA256: aa41b8df7b9a2c6cbd710b36e8b556939762fdc1841af072fdedc1992ae2e900  
libdrm-2.4.72.tar.gz
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.72.tar.gz.sig

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161114/e1376930/attachment.sig>

[Intel-gfx] [PATCH mesa v3] i965/gen8+: bo in state base address must be in 32-bit address range

[Matt Turner]

On Fri, Aug 7, 2015 at 2:45 AM, Michel Thierry  
wrote:
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 54081a1..ca90784 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -409,11 +409,23 @@ bool
>  intel_batchbuffer_emit_reloc64(struct brw_context *brw,

This patch needs to be rebased on commit 09348c12f (committed more
than 3 weeks ago).

[PATCH libdrm] configure: Add flag to disable valgrind support.

[Matt Turner]

On Mon, Jun 22, 2015 at 10:07 AM, Emil Velikov  
wrote:
> On 22 June 2015 at 16:56, Matt Turner  wrote:
>> ---
>>  configure.ac | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 78a0010..dd6c0ab 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -403,7 +403,15 @@ else
>>  fi
>>  AM_CONDITIONAL([HAVE_MANPAGES_STYLESHEET], [test 
>> "x$HAVE_MANPAGES_STYLESHEET" = "xyes"])
>>
>> -PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
>> [have_valgrind=no])
>> +AC_ARG_ENABLE(valgrind,
>> +  AS_HELP_STRING([--disable-valgrind],
>> + [Disable valgrind support]),
>> + [use_valgrind=$enableval], [use_valgrind=yes])
>> +
>> +if test "x$use_valgrind" = "xyes"; then
>> +   PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
>> [have_valgrind=no])
>> +fi
>> +
> Any objections if we move this to "auto" rather than enabled by
> default (like we do with cairo) ? If you're ok I'll amend the patch
> before pushing.
>
> -Emil

Fine by me!

Thanks Emil.

[PATCH libdrm] configure: Add flag to disable valgrind support.

[Matt Turner]

---
 configure.ac | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 78a0010..dd6c0ab 100644
--- a/configure.ac
+++ b/configure.ac
@@ -403,7 +403,15 @@ else
 fi
 AM_CONDITIONAL([HAVE_MANPAGES_STYLESHEET], [test "x$HAVE_MANPAGES_STYLESHEET" 
= "xyes"])

-PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
+AC_ARG_ENABLE(valgrind,
+  AS_HELP_STRING([--disable-valgrind],
+ [Disable valgrind support]),
+ [use_valgrind=$enableval], [use_valgrind=yes])
+
+if test "x$use_valgrind" = "xyes"; then
+   PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
+fi
+
 if test "x$have_valgrind" = "xyes"; then
AC_DEFINE([HAVE_VALGRIND], 1, [Use valgrind intrinsics to suppress 
false warnings])
 fi
-- 
2.3.6

[PATCH] Add DRM_CAS for mips32

[Matt Turner]

On Thu, May 14, 2015 at 5:12 AM, Aleksey Kuleshov  wrote:
> Signed-off-by: Aleksey Kuleshov 
> ---

At least a few years ago, DRM_CAS was only used by DRI1 which is
pretty dead at this point. Has something changed?

What problem are you trying to solve?

[PATCH 2/4] drm/cache: Try to be smarter about clflushing on x86

[Matt Turner]

On Sat, Dec 13, 2014 at 7:08 PM, Ben Widawsky
 wrote:
> Any GEM driver which has very large objects and a slow CPU is subject to very
> long waits simply for clflushing incoherent objects. Generally, each 
> individual
> object is not a problem, but if you have very large objects, or very many
> objects, the flushing begins to show up in profiles. Because on x86 we know 
> the
> cache size, we can easily determine when an object will use all the cache, and
> forego iterating over each cacheline.
>
> We need to be careful when using wbinvd. wbinvd() is itself potentially slow
> because it requires synchronizing the flush across all CPUs so they have a
> coherent view of memory. This can result in either stalling work being done on
> other CPUs, or this call itself stalling while waiting for a CPU to accept the
> interrupt. Also, wbinvd() also has the downside of invalidating all 
> cachelines,
> so we don't want to use it unless we're sure we already own most of the
> cachelines.
>
> The current algorithm is very naive. I think it can be tweaked more, and it
> would be good if someone else gave it some thought. I am pretty confident in
> i915, we can even skip the IPI in the execbuf path with minimal code change 
> (or
> perhaps just some verifying of the existing code). It would be nice to hear 
> what
> other developers who depend on this code think.
>
> Cc: Intel GFX 
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/drm_cache.c | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index d7797e8..6009c2d 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -64,6 +64,20 @@ static void drm_cache_flush_clflush(struct page *pages[],
> drm_clflush_page(*pages++);
> mb();
>  }
> +
> +static bool
> +drm_cache_should_clflush(unsigned long num_pages)
> +{
> +   const int cache_size = boot_cpu_data.x86_cache_size;
> +
> +   /* For now the algorithm simply checks if the number of pages to be
> +* flushed is greater than the entire system cache. One could make the
> +* function more aware of the actual system (ie. if SMP, how large is
> +* the cache, CPU freq. etc. All those help to determine when to
> +* wbinvd() */
> +   WARN_ON_ONCE(!cache_size);
> +   return !cache_size || num_pages < (cache_size >> 2);
> +}
>  #endif
>
>  void
> @@ -71,7 +85,7 @@ drm_clflush_pages(struct page *pages[], unsigned long 
> num_pages)
>  {
>
>  #if defined(CONFIG_X86)
> -   if (cpu_has_clflush) {
> +   if (cpu_has_clflush && drm_cache_should_clflush(num_pages)) {
> drm_cache_flush_clflush(pages, num_pages);
> return;
> }
> @@ -104,7 +118,7 @@ void
>  drm_clflush_sg(struct sg_table *st)
>  {
>  #if defined(CONFIG_X86)
> -   if (cpu_has_clflush) {
> +   if (cpu_has_clflush && drm_cache_should_clflush(st->nents)) {
> struct sg_page_iter sg_iter;
>
> mb();
> @@ -128,7 +142,7 @@ void
>  drm_clflush_virt_range(void *addr, unsigned long length)
>  {
>  #if defined(CONFIG_X86)
> -   if (cpu_has_clflush) {
> +   if (cpu_has_clflush && drm_cache_should_clflush(length / PAGE_SIZE)) {

If length isn't a multiple of page size, isn't this ignoring the
remainder? Should it be rounding length up to the next multiple of
PAGE_SIZE, like ROUND_UP_TO?

[Mesa-dev] [PATCH] glx/dri3: Provide error diagnostics when DRI3 allocation fails

[Matt Turner]

On Tue, Sep 30, 2014 at 8:09 PM, Keith Packard  wrote:
> Instead of just segfaulting in the driver when a buffer allocation fails,
> report error messages indicating what went wrong so that we can debug things.
>
> As a simple example, chromium wraps Mesa in a sandbox which doesn't allow
> access to most syscalls, including the ability to create shared memory
> segments for fences. Before, you'd get a simple segfault in mesa and your 3D
> acceleration would fail. Now you get:
>
> $ chromium --disable-gpu-blacklist
> [10618:10643:0930/200525:ERROR:nss_util.cc(856)] After loading Root Certs, 
> loaded==false: NSS error code: -8018
> libGL: pci id for fd 12: 8086:0a16, driver i965
> libGL: OpenDriver: trying /local-miki/src/mesa/mesa/lib/i965_dri.so
> libGL: Can't open configuration file /home/keithp/.drirc: Operation not 
> permitted.
> libGL: Can't open configuration file /home/keithp/.drirc: Operation not 
> permitted.
> libGL error: DRI3 Fence object allocation failure Operation not permitted
> [10618:10618:0930/200525:ERROR:command_buffer_proxy_impl.cc(153)] Could not 
> send GpuCommandBufferMsg_Initialize.
> [10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(236)]
>  CommandBufferProxy::Initialize failed.
> [10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(256)]
>  Failed to initialize command buffer.
>
> This made it pretty easy to diagnose the problem in the referenced bug report.
>
> Bugzilla: https://code.google.com/p/chromium/issues/detail?id=415681
> Signed-off-by: Keith Packard 
> ---

Seems like a good plan.

Reviewed-by: Matt Turner 

Should we add a Cc: for the stable branch?

[PATCH] glx/dri3: Use four buffers until X driver supports async flips

[Matt Turner]

Cc'ing people who might be able to review.

looking for i915 direct programming sample application

[Matt Turner]

On Sat, Jun 7, 2014 at 3:45 PM, G?bor Bereczki
 wrote:
> did some  more research. Is the following correct?
> -OpenCL is not yet supported for Intel GPU on Linux

The Beignet project [1] supports OpenCL IvyBridge (and Haswell, I think).

I believe your time would be much better spent contributing to the
Beignet project than attempting what you're suggesting.

[1] http://www.freedesktop.org/wiki/Software/Beignet/

[PATCH 02/33] drm/vmwgfx: Update the svga3d register header file for new device version

[Matt Turner]

On Thu, Jan 16, 2014 at 12:38 PM, Thomas Hellstrom
 wrote:
> Reivewed-by: Zack Rusin 

Typo.

[Mesa-dev] rules for merging patches to libdrm

[Matt Turner]

On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie  wrote:
> Since we seemed to have some confusion over this I'll state it clearly here.
>
> You should not merge kernel interface and ioctls to libdrm until they
> have appeared in a git commit upstream with a stable id, this
> generally means drm-next, but can also mean drm-intel-next.

How does this interact with the rule that kernel interfaces require an
open source userspace? Is "here are the mesa/libdrm patches that use
it" sufficient to get the kernel interface merged?

libdrm is easy to change and its releases are cheap. What problem does
committing code that uses an in-progress kernel interface to libdrm
cause? I guess I'm not understanding something.

[PATCH] Fix build of swrast only without libdrm

[Matt Turner]

On Thu, Feb 28, 2013 at 3:58 AM, Daniel Martin  
wrote:
>
> Signed-off-by: Daniel Martin 
> ---
> There's a small logic error preventing mesa to be build with swrast only
> and not having libdrm.
>
>  configure.ac |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 5701f8a..aa1b38a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1089,7 +1089,7 @@ if test "x$enable_dri" = xyes; then
>  fi
>
>  # if we are building any dri driver other than swrast or using the dri 
> state tracker ...
> -if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast || test "x$enable_dri" 
> = xyes; then
> +if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast && test "x$enable_dri" 
> = xyes; then

While modifying this line of code, please change '&& test' to -a.

(mesa patches to go mesa-dev, not dri-devel)

Re: [PATCH] Fix build of swrast only without libdrm

[Matt Turner]

On Thu, Feb 28, 2013 at 3:58 AM, Daniel Martin consume.no...@gmail.com wrote:

 Signed-off-by: Daniel Martin consume.no...@gmail.com
 ---
 There's a small logic error preventing mesa to be build with swrast only
 and not having libdrm.

  configure.ac |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 5701f8a..aa1b38a 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1089,7 +1089,7 @@ if test x$enable_dri = xyes; then
  fi

  # if we are building any dri driver other than swrast or using the dri 
 state tracker ...
 -if test -n $DRI_DIRS -a x$DRI_DIRS != xswrast || test x$enable_dri 
 = xyes; then
 +if test -n $DRI_DIRS -a x$DRI_DIRS != xswrast  test x$enable_dri 
 = xyes; then

While modifying this line of code, please change ' test' to -a.

(mesa patches to go mesa-dev, not dri-devel)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

clang: warning: argument unused during compilation: '-fno-builtin-memcmp'

[Matt Turner]

On Thu, Jan 17, 2013 at 8:19 PM, Sedat Dilek  wrote:
> Hi,
>
> I am playing with llvm/clang v3.2 and mesa.
>
> It's annoying to see these hundreds of warnings...
>
> clang: warning: argument unused during compilation: '-fno-builtin-memcmp'
>
> NOTE: '-fno-builtin-memcmp' is a gcc-specific compiler-flag.
>
> I have done here a brutal solution, maybe someone else has a more elegant one.
>
> Thanks.
>
> Regards,
> - Sedat -

> mesa3d-dev at lists.sourceforge.net

Please send to mesa-dev at lists.freedesktop.org and not the sourceforge list.

-fno-builtin-memcmp is added to CFLAGS inside a block that checks if
the compiler is gcc:

dnl Add flags for gcc and g++
if test "x$GCC" = xyes; then
...
CFLAGS_FOR_BUILD="$CFLAGS_FOR_BUILD -fno-builtin-memcmp"
CFLAGS="$CFLAGS -fno-builtin-memcmp"
...
fi

Re: clang: warning: argument unused during compilation: '-fno-builtin-memcmp'

[Matt Turner]

On Thu, Jan 17, 2013 at 8:19 PM, Sedat Dilek sedat.di...@gmail.com wrote:
 Hi,

 I am playing with llvm/clang v3.2 and mesa.

 It's annoying to see these hundreds of warnings...

 clang: warning: argument unused during compilation: '-fno-builtin-memcmp'

 NOTE: '-fno-builtin-memcmp' is a gcc-specific compiler-flag.

 I have done here a brutal solution, maybe someone else has a more elegant one.

 Thanks.

 Regards,
 - Sedat -

 mesa3d-...@lists.sourceforge.net

Please send to mesa-...@lists.freedesktop.org and not the sourceforge list.

-fno-builtin-memcmp is added to CFLAGS inside a block that checks if
the compiler is gcc:

dnl Add flags for gcc and g++
if test x$GCC = xyes; then
...
CFLAGS_FOR_BUILD=$CFLAGS_FOR_BUILD -fno-builtin-memcmp
CFLAGS=$CFLAGS -fno-builtin-memcmp
...
fi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB).

[Matt Turner]

On Sat, Aug 11, 2012 at 2:32 AM, Huacai Chen  wrote:
> Signed-off-by: Huacai Chen 
> Signed-off-by: Hongliang Tao 
> Signed-off-by: Hua Yan 
> Cc: dri-devel at lists.freedesktop.org
> ---
>  include/drm/drm_sarea.h |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
> index ee5389d..1d1a858 100644
> --- a/include/drm/drm_sarea.h
> +++ b/include/drm/drm_sarea.h
> @@ -37,6 +37,8 @@
>  /* SAREA area needs to be at least a page */
>  #if defined(__alpha__)
>  #define SAREA_MAX   0x2000U
> +#elif defined(__mips__)
> +#define SAREA_MAX   0x4000U
>  #elif defined(__ia64__)
>  #define SAREA_MAX   0x1U   /* 64kB */
>  #else
> --
> 1.7.7.3

SAREA is a DRI-1 concept. The Radeon drivers you're using is DRI-2, so
what do you need this for? All the DRI-1 drivers have been removed
from Mesa, so I think the answer is nothing.

Re: [PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB).

[Matt Turner]

On Sat, Aug 11, 2012 at 2:32 AM, Huacai Chen chenhua...@gmail.com wrote:
 Signed-off-by: Huacai Chen che...@lemote.com
 Signed-off-by: Hongliang Tao ta...@lemote.com
 Signed-off-by: Hua Yan y...@lemote.com
 Cc: dri-devel@lists.freedesktop.org
 ---
  include/drm/drm_sarea.h |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h
 index ee5389d..1d1a858 100644
 --- a/include/drm/drm_sarea.h
 +++ b/include/drm/drm_sarea.h
 @@ -37,6 +37,8 @@
  /* SAREA area needs to be at least a page */
  #if defined(__alpha__)
  #define SAREA_MAX   0x2000U
 +#elif defined(__mips__)
 +#define SAREA_MAX   0x4000U
  #elif defined(__ia64__)
  #define SAREA_MAX   0x1U   /* 64kB */
  #else
 --
 1.7.7.3

SAREA is a DRI-1 concept. The Radeon drivers you're using is DRI-2, so
what do you need this for? All the DRI-1 drivers have been removed
from Mesa, so I think the answer is nothing.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] mgag200: initial g200se driver

[Matt Turner]

On Thu, Apr 26, 2012 at 9:48 AM, Dave Airlie  wrote:
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> new file mode 100644
> index 000..a74f946
> --- /dev/null
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -0,0 +1,1494 @@
> +/*
> + * Copyright 2000,2001 Sven Luther.

Here...

> + * Copyright 2010 Matt Turner.
> + * Copyright 2011 Red Hat 
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License version 2. See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * Authors: Matthew Garrett
> + * ? ? ? ? ? ? ? ? ? ? Matt Turner
> + * ? ? ? ? ? ? ? ? ? ? Sven Luther
> + * ? ? ? ? ? ? ? ? ? ? Thomas Witzel
> + * ? ? ? ? ? ? ? ? ? ? Alan Hourihane

and here, the copyrights and authorship for Sven Luther, Thomas
Witzel, and Alan Hourihane can be dropped. When I wrote glint_crtc.c,
I copied PM3DAC_CalculateClock from xf86-video-glint. With no remnants
of this function left, none of the code was written by them.

Re: [PATCH] mgag200: initial g200se driver

[Matt Turner]

On Thu, Apr 26, 2012 at 9:48 AM, Dave Airlie airl...@gmail.com wrote:
 diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
 b/drivers/gpu/drm/mgag200/mgag200_mode.c
 new file mode 100644
 index 000..a74f946
 --- /dev/null
 +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
 @@ -0,0 +1,1494 @@
 +/*
 + * Copyright 2000,2001 Sven Luther.

Here...

 + * Copyright 2010 Matt Turner.
 + * Copyright 2011 Red Hat m...@redhat.com
 + *
 + * This file is subject to the terms and conditions of the GNU General
 + * Public License version 2. See the file COPYING in the main
 + * directory of this archive for more details.
 + *
 + * Authors: Matthew Garrett
 + *                     Matt Turner
 + *                     Sven Luther
 + *                     Thomas Witzel
 + *                     Alan Hourihane

and here, the copyrights and authorship for Sven Luther, Thomas
Witzel, and Alan Hourihane can be dropped. When I wrote glint_crtc.c,
I copied PM3DAC_CalculateClock from xf86-video-glint. With no remnants
of this function left, none of the code was written by them.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Only build test programs with make check

[Matt Turner]

On Sat, Mar 17, 2012 at 2:35 PM, Jakob Bornecrantz  wrote:
> With my limited knowledge of automake I'm going to have
> to NACK this patch. Most of these programs are used during
> driver bring up to test things out, often we also modify
> them a bit to suit our need.
>
> If this patch doesn't make this any harder then
> disregard my NACK.

Harder, like having to run make check?

I'm not sure about modeprint, so I can drop that, but the rest look
like programs you'd want to run during make check.

[PATCH] Only build test programs with make check

[Matt Turner]

Signed-off-by: Matt Turner 
---
 tests/kmstest/Makefile.am   |2 +-
 tests/modeprint/Makefile.am |2 +-
 tests/modetest/Makefile.am  |2 +-
 tests/radeon/Makefile.am|2 +-
 tests/vbltest/Makefile.am   |2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/kmstest/Makefile.am b/tests/kmstest/Makefile.am
index ae562a1..10b9ef3 100644
--- a/tests/kmstest/Makefile.am
+++ b/tests/kmstest/Makefile.am
@@ -3,7 +3,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/libkms/ \
-I$(top_srcdir)

-noinst_PROGRAMS = \
+check_PROGRAMS = \
kmstest

 kmstest_SOURCES = \
diff --git a/tests/modeprint/Makefile.am b/tests/modeprint/Makefile.am
index c4862ac..4291dc5 100644
--- a/tests/modeprint/Makefile.am
+++ b/tests/modeprint/Makefile.am
@@ -2,7 +2,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)

-noinst_PROGRAMS = \
+check_PROGRAMS = \
modeprint

 modeprint_SOURCES = \
diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
index 2191242..dd43d0c 100644
--- a/tests/modetest/Makefile.am
+++ b/tests/modetest/Makefile.am
@@ -4,7 +4,7 @@ AM_CFLAGS = \
-I$(top_srcdir) \
$(CAIRO_CFLAGS)

-noinst_PROGRAMS = \
+check_PROGRAMS = \
modetest

 modetest_SOURCES = \
diff --git a/tests/radeon/Makefile.am b/tests/radeon/Makefile.am
index 1775669..d4f6755 100644
--- a/tests/radeon/Makefile.am
+++ b/tests/radeon/Makefile.am
@@ -4,7 +4,7 @@ AM_CFLAGS = \

 LDADD = $(top_builddir)/libdrm.la

-noinst_PROGRAMS = \
+check_PROGRAMS = \
radeon_ttm

 radeon_ttm_SOURCES = \
diff --git a/tests/vbltest/Makefile.am b/tests/vbltest/Makefile.am
index 77f9037..5886bd1 100644
--- a/tests/vbltest/Makefile.am
+++ b/tests/vbltest/Makefile.am
@@ -2,7 +2,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)

-noinst_PROGRAMS = \
+check_PROGRAMS = \
vbltest

 vbltest_SOURCES = \
-- 
1.7.3.4

[PATCH] Only build test programs with make check

[Matt Turner]

Signed-off-by: Matt Turner matts...@gmail.com
---
 tests/kmstest/Makefile.am   |2 +-
 tests/modeprint/Makefile.am |2 +-
 tests/modetest/Makefile.am  |2 +-
 tests/radeon/Makefile.am|2 +-
 tests/vbltest/Makefile.am   |2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/kmstest/Makefile.am b/tests/kmstest/Makefile.am
index ae562a1..10b9ef3 100644
--- a/tests/kmstest/Makefile.am
+++ b/tests/kmstest/Makefile.am
@@ -3,7 +3,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/libkms/ \
-I$(top_srcdir)
 
-noinst_PROGRAMS = \
+check_PROGRAMS = \
kmstest
 
 kmstest_SOURCES = \
diff --git a/tests/modeprint/Makefile.am b/tests/modeprint/Makefile.am
index c4862ac..4291dc5 100644
--- a/tests/modeprint/Makefile.am
+++ b/tests/modeprint/Makefile.am
@@ -2,7 +2,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)
 
-noinst_PROGRAMS = \
+check_PROGRAMS = \
modeprint
 
 modeprint_SOURCES = \
diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
index 2191242..dd43d0c 100644
--- a/tests/modetest/Makefile.am
+++ b/tests/modetest/Makefile.am
@@ -4,7 +4,7 @@ AM_CFLAGS = \
-I$(top_srcdir) \
$(CAIRO_CFLAGS)
 
-noinst_PROGRAMS = \
+check_PROGRAMS = \
modetest
 
 modetest_SOURCES = \
diff --git a/tests/radeon/Makefile.am b/tests/radeon/Makefile.am
index 1775669..d4f6755 100644
--- a/tests/radeon/Makefile.am
+++ b/tests/radeon/Makefile.am
@@ -4,7 +4,7 @@ AM_CFLAGS = \
 
 LDADD = $(top_builddir)/libdrm.la
 
-noinst_PROGRAMS = \
+check_PROGRAMS = \
radeon_ttm
 
 radeon_ttm_SOURCES = \
diff --git a/tests/vbltest/Makefile.am b/tests/vbltest/Makefile.am
index 77f9037..5886bd1 100644
--- a/tests/vbltest/Makefile.am
+++ b/tests/vbltest/Makefile.am
@@ -2,7 +2,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)
 
-noinst_PROGRAMS = \
+check_PROGRAMS = \
vbltest
 
 vbltest_SOURCES = \
-- 
1.7.3.4

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

Re: [PATCH] Only build test programs with make check

[Matt Turner]

On Sat, Mar 17, 2012 at 2:35 PM, Jakob Bornecrantz ja...@vmware.com wrote:
 With my limited knowledge of automake I'm going to have
 to NACK this patch. Most of these programs are used during
 driver bring up to test things out, often we also modify
 them a bit to suit our need.

 If this patch doesn't make this any harder then
 disregard my NACK.

Harder, like having to run make check?

I'm not sure about modeprint, so I can drop that, but the rest look
like programs you'd want to run during make check.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] Don't require pciaccess if Intel is disabled

[Matt Turner]

Signed-off-by: Matt Turner 
---
 configure.ac |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 97bbcb7..71a596c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -51,10 +51,6 @@ PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)
 AC_SUBST(PTHREADSTUBS_CFLAGS)
 AC_SUBST(PTHREADSTUBS_LIBS)

-PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
-AC_SUBST(PCIACCESS_CFLAGS)
-AC_SUBST(PCIACCESS_LIBS)
-
 pkgconfigdir=${libdir}/pkgconfig
 AC_SUBST(pkgconfigdir)
 AC_ARG_ENABLE([udev],
@@ -261,6 +257,12 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno"; then
 fi
 fi

+if test "x$INTEL" != "xno"; then
+   PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
+fi
+AC_SUBST(PCIACCESS_CFLAGS)
+AC_SUBST(PCIACCESS_LIBS)
+
 PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
 if test "x$have_valgrind" = "xyes"; then
AC_DEFINE([HAVE_VALGRIND], 1, [Use valgrind intrinsics to suppress 
false warnings])
-- 
1.7.3.4

[PATCH libdrm] Don't require pciaccess if Intel is disabled

[Matt Turner]

Signed-off-by: Matt Turner matts...@gmail.com
---
 configure.ac |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 97bbcb7..71a596c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -51,10 +51,6 @@ PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)
 AC_SUBST(PTHREADSTUBS_CFLAGS)
 AC_SUBST(PTHREADSTUBS_LIBS)
 
-PKG_CHECK_MODULES(PCIACCESS, [pciaccess = 0.10])
-AC_SUBST(PCIACCESS_CFLAGS)
-AC_SUBST(PCIACCESS_LIBS)
-
 pkgconfigdir=${libdir}/pkgconfig
 AC_SUBST(pkgconfigdir)
 AC_ARG_ENABLE([udev],
@@ -261,6 +257,12 @@ if test x$INTEL != xno -o x$RADEON != xno; then
 fi
 fi
 
+if test x$INTEL != xno; then
+   PKG_CHECK_MODULES(PCIACCESS, [pciaccess = 0.10])
+fi
+AC_SUBST(PCIACCESS_CFLAGS)
+AC_SUBST(PCIACCESS_LIBS)
+
 PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
 if test x$have_valgrind = xyes; then
AC_DEFINE([HAVE_VALGRIND], 1, [Use valgrind intrinsics to suppress 
false warnings])
-- 
1.7.3.4

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

[PATCH] drm/i915: use DDC_ADDR instead of hard-coding it

[Matt Turner]

Signed-off-by: Matt Turner 
---
 drivers/gpu/drm/i915/intel_modes.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_modes.c 
b/drivers/gpu/drm/i915/intel_modes.c
index 3b26a3b..ab534be 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include "drmP.h"
+#include "drm_edid.h"
 #include "intel_drv.h"
 #include "i915_drv.h"

@@ -41,13 +42,13 @@ bool intel_ddc_probe(struct intel_encoder *intel_encoder, 
int ddc_bus)
u8 buf[2];
struct i2c_msg msgs[] = {
{
-   .addr = 0x50,
+   .addr = DDC_ADDR,
.flags = 0,
.len = 1,
.buf = out_buf,
},
{
-   .addr = 0x50,
+   .addr = DDC_ADDR,
.flags = I2C_M_RD,
.len = 1,
.buf = buf,
-- 
1.7.3.4

[PATCH] drm/radeon: use DDC_ADDR instead of hard-coding it

[Matt Turner]

Signed-off-by: Matt Turner 
---
 drivers/gpu/drm/radeon/radeon_i2c.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c 
b/drivers/gpu/drm/radeon/radeon_i2c.c
index 6c111c1..37a6d38 100644
--- a/drivers/gpu/drm/radeon/radeon_i2c.c
+++ b/drivers/gpu/drm/radeon/radeon_i2c.c
@@ -24,6 +24,7 @@
  *  Alex Deucher
  */
 #include "drmP.h"
+#include "drm_edid.h"
 #include "radeon_drm.h"
 #include "radeon.h"
 #include "atom.h"
@@ -39,13 +40,13 @@ bool radeon_ddc_probe(struct radeon_connector 
*radeon_connector, bool requires_e
int ret;
struct i2c_msg msgs[] = {
{
-   .addr = 0x50,
+   .addr = DDC_ADDR,
.flags = 0,
.len = 1,
.buf = ,
},
{
-   .addr = 0x50,
+   .addr = DDC_ADDR,
.flags = I2C_M_RD,
.len = 1,
.buf = buf,
-- 
1.7.3.4

[PATCH] drm: remove unneeded redefinition of DDC_ADDR

[Matt Turner]

It's already defined in drm_edid.h.

Signed-off-by: Matt Turner 
---
 drivers/gpu/drm/drm_edid.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7425e5c..9fa8316 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -225,7 +225,6 @@ bool drm_edid_is_valid(struct edid *edid)
 }
 EXPORT_SYMBOL(drm_edid_is_valid);

-#define DDC_ADDR 0x50
 #define DDC_SEGMENT_ADDR 0x30
 /**
  * Get EDID information via I2C.
-- 
1.7.3.4

[PATCH] drm: remove unneeded redefinition of DDC_ADDR

[Matt Turner]

It's already defined in drm_edid.h.

Signed-off-by: Matt Turner matts...@gmail.com
---
 drivers/gpu/drm/drm_edid.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7425e5c..9fa8316 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -225,7 +225,6 @@ bool drm_edid_is_valid(struct edid *edid)
 }
 EXPORT_SYMBOL(drm_edid_is_valid);
 
-#define DDC_ADDR 0x50
 #define DDC_SEGMENT_ADDR 0x30
 /**
  * Get EDID information via I2C.
-- 
1.7.3.4

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

[PATCH] drm/radeon: use DDC_ADDR instead of hard-coding it

[Matt Turner]

Signed-off-by: Matt Turner matts...@gmail.com
---
 drivers/gpu/drm/radeon/radeon_i2c.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c 
b/drivers/gpu/drm/radeon/radeon_i2c.c
index 6c111c1..37a6d38 100644
--- a/drivers/gpu/drm/radeon/radeon_i2c.c
+++ b/drivers/gpu/drm/radeon/radeon_i2c.c
@@ -24,6 +24,7 @@
  *  Alex Deucher
  */
 #include drmP.h
+#include drm_edid.h
 #include radeon_drm.h
 #include radeon.h
 #include atom.h
@@ -39,13 +40,13 @@ bool radeon_ddc_probe(struct radeon_connector 
*radeon_connector, bool requires_e
int ret;
struct i2c_msg msgs[] = {
{
-   .addr = 0x50,
+   .addr = DDC_ADDR,
.flags = 0,
.len = 1,
.buf = out,
},
{
-   .addr = 0x50,
+   .addr = DDC_ADDR,
.flags = I2C_M_RD,
.len = 1,
.buf = buf,
-- 
1.7.3.4

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

[PATCH] drm/i915: use DDC_ADDR instead of hard-coding it

[Matt Turner]

Signed-off-by: Matt Turner matts...@gmail.com
---
 drivers/gpu/drm/i915/intel_modes.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_modes.c 
b/drivers/gpu/drm/i915/intel_modes.c
index 3b26a3b..ab534be 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -27,6 +27,7 @@
 #include linux/i2c.h
 #include linux/fb.h
 #include drmP.h
+#include drm_edid.h
 #include intel_drv.h
 #include i915_drv.h
 
@@ -41,13 +42,13 @@ bool intel_ddc_probe(struct intel_encoder *intel_encoder, 
int ddc_bus)
u8 buf[2];
struct i2c_msg msgs[] = {
{
-   .addr = 0x50,
+   .addr = DDC_ADDR,
.flags = 0,
.len = 1,
.buf = out_buf,
},
{
-   .addr = 0x50,
+   .addr = DDC_ADDR,
.flags = I2C_M_RD,
.len = 1,
.buf = buf,
-- 
1.7.3.4

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

Re: [PATCH] modeprint.c: use PRIu64 for printing uint64_t

[Matt Turner]

On Thu, Mar 3, 2011 at 9:04 PM, Matt Turner matts...@gmail.com wrote:
 Signed-off-by: Matt Turner matts...@gmail.com
 ---
  tests/modeprint/modeprint.c |    7 ---
  1 files changed, 4 insertions(+), 3 deletions(-)

 diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
 index 09b8df0..545ff40 100644
 --- a/tests/modeprint/modeprint.c
 +++ b/tests/modeprint/modeprint.c
 @@ -36,6 +36,7 @@
  #include stdint.h
  #include unistd.h
  #include string.h
 +#include inttypes.h

  #include xf86drm.h
  #include xf86drmMode.h
 @@ -101,7 +102,7 @@ int printProperty(int fd, drmModeResPtr res, 
 drmModePropertyPtr props, uint64_t
        if (props-count_values) {
                printf(\tvalues       :);
                for (j = 0; j  props-count_values; j++)
 -                       printf( %llu, props-values[j]);
 +                       printf( % PRIu64, props-values[j]);
                printf(\n);
        }

 @@ -116,7 +117,7 @@ int printProperty(int fd, drmModeResPtr res, 
 drmModePropertyPtr props, uint64_t
                        printf(blob is %d length, %08X\n, blob-length, 
 *(uint32_t *)blob-data);
                        drmModeFreePropertyBlob(blob);
                } else {
 -                       printf(error getting blob %llu\n, value);
 +                       printf(error getting blob % PRIu64 \n, value);
                }

        } else {
 @@ -132,7 +133,7 @@ int printProperty(int fd, drmModeResPtr res, 
 drmModePropertyPtr props, uint64_t
                if (props-count_enums  name) {
                        printf(\tcon_value    : %s\n, name);
                } else {
 -                       printf(\tcon_value    : %lld\n, value);
 +                       printf(\tcon_value    : % PRIu64 \n, value);
                }
        }

 --
 1.7.3.4

This patch still applies, and still fixes warnings. Please commit.

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

[PATCH 4/6] drm/radeon: Add a rmb() in IH processing

[Matt Turner]

On Wed, Jul 13, 2011 at 6:28 AM, Benjamin Herrenschmidt
 wrote:
> We should have a read memory barrier between reading the WPTR from
> memory and reading ring entries based on that value (ie, we need to
> ensure both loads are done in order by the CPU).
>
> It could be argued that the MMIO reads in r600_ack_irq() might be
> enough to get that barrier but I prefer keeping an explicit one just
> in case.
>
> Signed-off-by: Benjamin Herrenschmidt 
> ---
>
> (resent adding dri-devel to the CC list to hit patchwork)
>
> drivers/gpu/drm/radeon/r600.c | ? ?3 +++
> ?1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 3c86b15..7e5c801 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -3312,6 +3312,9 @@ int r600_irq_process(struct radeon_device *rdev)
> ? ? ? ?}
>
> ?restart_ih:
> + ? ? ? /* Order reading of wptr vs. reading of IH ring data */
> + ? ? ? wmb();
> +
> ? ? ? ?/* display interrupts */
> ? ? ? ?r600_irq_ack(rdev);

The subject line says rmb(), but this says wmb(). Just want to verify
what you have is correct.

Matt

[PATCH 0/3] alpha, drm: Update Alpha DRM support

[Matt Turner]

On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook  
wrote:
>
> This patch set fixes Alpha-specific support in the DRM code,
> allowing Radeon KMS and the MGA driver to work properly on
> Alpha-based machines.
>
> Jay
>
> Jay Estabrook (3):
> ?alpha, drm: Update Alpha DRM support
> ?alpha, drm: Cleanup Alpha support in DRM generic code
> ?alpha, drm: Remove obsolete Alpha support in MGA DRM code
> ?alpha, drm: Add Alpha support to Radeon DRM code
>
> ?drivers/gpu/drm/drm_bufs.c ? ? ? ? ?| ? ?3 ---
> ?drivers/gpu/drm/drm_vm.c ? ? ? ? ? ?| ? ?2 +-
> ?drivers/gpu/drm/mga/mga_drv.h ? ? ? | ? 19 ---
> ?drivers/gpu/drm/radeon/radeon_ttm.c | ? 23 +++
> ?4 files changed, 24 insertions(+), 23 deletions(-)

Patches 1 and 3 are

Tested-by: Matt Turner 

They also fix

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

In that report, Michel Danzer had some comments about the patch, so
I'm CC'ing him.

Thanks!
Matt

Re: [PATCH 0/3] alpha, drm: Update Alpha DRM support

[Matt Turner]

On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook jay.estabr...@gmail.com wrote:

 This patch set fixes Alpha-specific support in the DRM code,
 allowing Radeon KMS and the MGA driver to work properly on
 Alpha-based machines.

 Jay

 Jay Estabrook (3):
  alpha, drm: Update Alpha DRM support
  alpha, drm: Cleanup Alpha support in DRM generic code
  alpha, drm: Remove obsolete Alpha support in MGA DRM code
  alpha, drm: Add Alpha support to Radeon DRM code

  drivers/gpu/drm/drm_bufs.c          |    3 ---
  drivers/gpu/drm/drm_vm.c            |    2 +-
  drivers/gpu/drm/mga/mga_drv.h       |   19 ---
  drivers/gpu/drm/radeon/radeon_ttm.c |   23 +++
  4 files changed, 24 insertions(+), 23 deletions(-)

Patches 1 and 3 are

Tested-by: Matt Turner matts...@gmail.com

They also fix

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

In that report, Michel Danzer had some comments about the patch, so
I'm CC'ing him.

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

BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()

[Matt Turner]

On Wed, May 25, 2011 at 8:12 PM, Thierry Vignaud
 wrote:
> On 25 May 2011 17:43, Alex Deucher  wrote:
>>> Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes
>>> immediately upon start.
>>
>> Any reason you are not using kms?
>
> Any reason you are not respecting the netiquette ?
> Quoting nearly 1000 lines unrelated to your one line answer is quite rude :-(

So is being a troll.

Re: BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()

[Matt Turner]

On Wed, May 25, 2011 at 8:12 PM, Thierry Vignaud
thierry.vign...@gmail.com wrote:
 On 25 May 2011 17:43, Alex Deucher alexdeuc...@gmail.com wrote:
 Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes
 immediately upon start.

 Any reason you are not using kms?

 Any reason you are not respecting the netiquette ?
 Quoting nearly 1000 lines unrelated to your one line answer is quite rude :-(

So is being a troll.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Add a driver for kvm emulated Cirrus

[Matt Turner]

On Mon, Apr 18, 2011 at 4:04 PM, Matthew Garrett  wrote:
> qemu-kvm emulates a Cirrus GPU, including its acceleration engine. We
> typically then run a Cirrus-specific X driver on top of this, which
> turns requests into commands and sends them to the emulated accelerator.
> This all seems to be unnecessary overhead given that we're just going
> to end up writing to memory from the host instead, and performance is
> almost certainly going to be better using an unaccelerated framebuffer
> and a guest-side shadow.
>
> This patch provides a simple modesetting-only KMS driver for the hardware
> emulated in qemu-kvm. It's stripped down to the point where it's able to
> program the emulation, but would almost certainly fail miserably if asked
> to run on real hardware. It's intended to reduce virt overhead slightly,
> but also to serve as a template to writing a basic KMS driver.
>
> The code and structure are heavily derived from Matt Turner's glint
> driver, with the modesetting code cribbed from cirrusfb (hence the
> license).

Nice!

> +#define CIRRUS_DPMS_CLEARED (-1)

I wanted to add a DPMS_CLEARED to DRM, since it's duplicated in at
least Nouveau, glint, and now cirrusfb. I guess we should fix that at
some point.

The only other nit-pick I've got is that I named variables gfb and
gfbdev because I'm uncreative with variable names and because glint
started with a 'g'. Not important though.

Thanks, I'll have to give it a try. Please have a

Reviewed-by: Matt Turner 

Matt

Re: [PATCH] drm: Add a driver for kvm emulated Cirrus

[Matt Turner]

On Mon, Apr 18, 2011 at 4:04 PM, Matthew Garrett m...@redhat.com wrote:
 qemu-kvm emulates a Cirrus GPU, including its acceleration engine. We
 typically then run a Cirrus-specific X driver on top of this, which
 turns requests into commands and sends them to the emulated accelerator.
 This all seems to be unnecessary overhead given that we're just going
 to end up writing to memory from the host instead, and performance is
 almost certainly going to be better using an unaccelerated framebuffer
 and a guest-side shadow.

 This patch provides a simple modesetting-only KMS driver for the hardware
 emulated in qemu-kvm. It's stripped down to the point where it's able to
 program the emulation, but would almost certainly fail miserably if asked
 to run on real hardware. It's intended to reduce virt overhead slightly,
 but also to serve as a template to writing a basic KMS driver.

 The code and structure are heavily derived from Matt Turner's glint
 driver, with the modesetting code cribbed from cirrusfb (hence the
 license).

Nice!

 +#define CIRRUS_DPMS_CLEARED (-1)

I wanted to add a DPMS_CLEARED to DRM, since it's duplicated in at
least Nouveau, glint, and now cirrusfb. I guess we should fix that at
some point.

The only other nit-pick I've got is that I named variables gfb and
gfbdev because I'm uncreative with variable names and because glint
started with a 'g'. Not important though.

Thanks, I'll have to give it a try. Please have a

Reviewed-by: Matt Turner matts...@gmail.com

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

Future desktop on dumb frame buffers?

[Matt Turner]

On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox  wrote:
>> ? 1) inertia: fbdev has been around a lot longer, and provides most of
>> ? what embedded devices need anyway
>> ? 2) feature set: why bother doing a full KMS driver if you're not
>> ? going to use any of the additional features it would provide (output
>> ? management, memory management, execution management)
>
> 3) its got documentation

My summer of code project's purpose was to create something of a
tutorial for writing a KMS driver. The code, split out into something
like 15 step-by-step patches, and accompanying documentation are
available from Google's website.

http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz

My repository (doesn't include the documentation) is available here:
http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary

There's a 'rebased' branch that contains API changes required for the
code to work with 2.6.37~.

It's nothing fantastic, but I've had a number of people tell me that
it was useful for them.

Thanks,
Matt

Re: Future desktop on dumb frame buffers?

[Matt Turner]

On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
   1) inertia: fbdev has been around a lot longer, and provides most of
   what embedded devices need anyway
   2) feature set: why bother doing a full KMS driver if you're not
   going to use any of the additional features it would provide (output
   management, memory management, execution management)

 3) its got documentation

My summer of code project's purpose was to create something of a
tutorial for writing a KMS driver. The code, split out into something
like 15 step-by-step patches, and accompanying documentation are
available from Google's website.

http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz

My repository (doesn't include the documentation) is available here:
http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary

There's a 'rebased' branch that contains API changes required for the
code to work with 2.6.37~.

It's nothing fantastic, but I've had a number of people tell me that
it was useful for them.

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

[PATCH] don't try to build modetest without libkms

[Matt Turner]

Signed-off-by: Matt Turner 
---
 tests/Makefile.am |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index ebf4853..01ca8b4 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -16,9 +16,6 @@ if HAVE_LIBKMS
 SUBDIRS += kmstest
 endif

-if HAVE_INTEL
-endif
-
 if HAVE_LIBUDEV

 check_LTLIBRARIES = libdrmtest.la
@@ -50,9 +47,13 @@ TESTS =  \
 SUBDIRS += vbltest $(NULL)

 if HAVE_INTEL
+if HAVE_LIBKMS
+SUBDIRS += \
+   modetest
+endif
+
 SUBDIRS += \
modeprint   \
-   modetest\
$(NULL)

 TESTS +=   \
-- 
1.7.3.4

[PATCH] modeprint.c: use PRIu64 for printing uint64_t

[Matt Turner]

Signed-off-by: Matt Turner 
---
 tests/modeprint/modeprint.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 09b8df0..545ff40 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "xf86drm.h"
 #include "xf86drmMode.h"
@@ -101,7 +102,7 @@ int printProperty(int fd, drmModeResPtr res, 
drmModePropertyPtr props, uint64_t
if (props->count_values) {
printf("\tvalues   :");
for (j = 0; j < props->count_values; j++)
-   printf(" %llu", props->values[j]);
+   printf(" %" PRIu64, props->values[j]);
printf("\n");
}

@@ -116,7 +117,7 @@ int printProperty(int fd, drmModeResPtr res, 
drmModePropertyPtr props, uint64_t
printf("blob is %d length, %08X\n", blob->length, 
*(uint32_t *)blob->data);
drmModeFreePropertyBlob(blob);
} else {
-   printf("error getting blob %llu\n", value);
+   printf("error getting blob %" PRIu64 "\n", value);
}

} else {
@@ -132,7 +133,7 @@ int printProperty(int fd, drmModeResPtr res, 
drmModePropertyPtr props, uint64_t
if (props->count_enums && name) {
printf("\tcon_value: %s\n", name);
} else {
-   printf("\tcon_value: %lld\n", value);
+   printf("\tcon_value: %" PRIu64 "\n", value);
}
}

-- 
1.7.3.4

[PATCH] modeprint.c: use PRIu64 for printing uint64_t

[Matt Turner]

Signed-off-by: Matt Turner matts...@gmail.com
---
 tests/modeprint/modeprint.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 09b8df0..545ff40 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -36,6 +36,7 @@
 #include stdint.h
 #include unistd.h
 #include string.h
+#include inttypes.h
 
 #include xf86drm.h
 #include xf86drmMode.h
@@ -101,7 +102,7 @@ int printProperty(int fd, drmModeResPtr res, 
drmModePropertyPtr props, uint64_t
if (props-count_values) {
printf(\tvalues   :);
for (j = 0; j  props-count_values; j++)
-   printf( %llu, props-values[j]);
+   printf( % PRIu64, props-values[j]);
printf(\n);
}
 
@@ -116,7 +117,7 @@ int printProperty(int fd, drmModeResPtr res, 
drmModePropertyPtr props, uint64_t
printf(blob is %d length, %08X\n, blob-length, 
*(uint32_t *)blob-data);
drmModeFreePropertyBlob(blob);
} else {
-   printf(error getting blob %llu\n, value);
+   printf(error getting blob % PRIu64 \n, value);
}
 
} else {
@@ -132,7 +133,7 @@ int printProperty(int fd, drmModeResPtr res, 
drmModePropertyPtr props, uint64_t
if (props-count_enums  name) {
printf(\tcon_value: %s\n, name);
} else {
-   printf(\tcon_value: %lld\n, value);
+   printf(\tcon_value: % PRIu64 \n, value);
}
}
 
-- 
1.7.3.4

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

[PATCH] don't try to build modetest without libkms

[Matt Turner]

Signed-off-by: Matt Turner matts...@gmail.com
---
 tests/Makefile.am |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index ebf4853..01ca8b4 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -16,9 +16,6 @@ if HAVE_LIBKMS
 SUBDIRS += kmstest
 endif
 
-if HAVE_INTEL
-endif
-
 if HAVE_LIBUDEV
 
 check_LTLIBRARIES = libdrmtest.la
@@ -50,9 +47,13 @@ TESTS =  \
 SUBDIRS += vbltest $(NULL)
 
 if HAVE_INTEL
+if HAVE_LIBKMS
+SUBDIRS += \
+   modetest
+endif
+
 SUBDIRS += \
modeprint   \
-   modetest\
$(NULL)
 
 TESTS +=   \
-- 
1.7.3.4

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

[Bug 29842] Radeon runs very hot

[Matt Turner]

On Fri, Feb 25, 2011 at 5:11 PM, Phillip Susi  wrote:
> So I have been looking over the source code in drivers/gpu/drm/radeon.
> I see various functions to start/stop/resume/initialize "mc" and "cp".
> I assume those stand for microcode and control program? ?What exactly is
> the difference?

Memory Controller and Command Processor, I believe.

Matt

Re: [Bug 29842] Radeon runs very hot

[Matt Turner]

On Fri, Feb 25, 2011 at 5:11 PM, Phillip Susi ps...@cfl.rr.com wrote:
 So I have been looking over the source code in drivers/gpu/drm/radeon.
 I see various functions to start/stop/resume/initialize mc and cp.
 I assume those stand for microcode and control program?  What exactly is
 the difference?

Memory Controller and Command Processor, I believe.

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

[PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

[Matt Turner]

On Wed, Feb 9, 2011 at 7:12 AM, Alex Deucher  wrote:
> On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls  wrote:
>> On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote:
>>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil  wrote:
>>> > Just two quick notes. I'll try to do a full review this weekend.
>>> >
>>> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote:
>>> >> ==
>>> >> ?Introduction
>>> >> ==
>>> >>
>>> >> The purpose of this RFC is to discuss the driver for a TV output 
>>> >> interface
>>> >> available in upcoming Samsung SoC. The HW is able to generate digital and
>>> >> analog signals. Current version of the driver supports only digital 
>>> >> output.
>>> >>
>>> >> Internally the driver uses videobuf2 framework, and CMA memory allocator.
>>> > Not
>>> >> all of them are merged by now, but I decided to post the sources to start
>>> >> discussion driver's design.
>>
>>> >
>>> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to 
>>> > post
>>> > an RFC by the end of this month. We also have a proposal for CEC support 
>>> > in
>>> > the pipeline.
>>>
>>> Any reason to not use the drm kms APIs for modesetting, display
>>> configuration, and hotplug support? ?We already have the
>>> infrastructure in place for complex display configurations and
>>> generating events for hotplug interrupts. ?It would seem to make more
>>> sense to me to fix any deficiencies in the KMS APIs than to spin a new
>>> API. ?Things like CEC would be a natural fit since a lot of desktop
>>> GPUs support hdmi audio/3d/etc. and are already using kms.
>>>
>>> Alex
>>
>> I'll toss one out: lack of API documentation for driver or application
>> developers to use.
>>
>>
>> When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to
>> possibly get rid of reliance on the ivtv X video driver
>> http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation
>> was really sparse.
>>
>> DRM had the most documentation under Documentation/DocBook/drm.tmpl, but
>> the userland API wasn't fleshed out. ?GEM was talked about a bit in
>> there as well, IIRC.
>>
>> TTM documentation was essentially non-existant.
>>
>> I can't find any KMS documentation either.
>>
>> I recall having to read much of the drm code, and having to look at the
>> radeon driver, just to tease out what the DRM ioctls needed to do.
>>
>> Am I missing a Documentation source for the APIs?

Yes,

My summer of code project's purpose was to create something of a
tutorial for writing a KMS driver. The code, split out into something
like 15 step-by-step patches, and accompanying documentation are
available from Google's website.

http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz

My repository (doesn't include the documentation) is available here:
http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary

There's a 'rebased' branch that contains API changes required for the
code to work with 2.6.37~.

I hope it's useful to you.

I can't image how the lack of documentation of an used and tested API
could be a serious reason to write you own. That makes absolutely no
sense to me, so I hope you'll decide to use KMS.

Matt

Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

[Matt Turner]

On Wed, Feb 9, 2011 at 7:12 AM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls awa...@md.metrocast.net wrote:
 On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote:
 On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil hansv...@cisco.com wrote:
  Just two quick notes. I'll try to do a full review this weekend.
 
  On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote:
  ==
   Introduction
  ==
 
  The purpose of this RFC is to discuss the driver for a TV output 
  interface
  available in upcoming Samsung SoC. The HW is able to generate digital and
  analog signals. Current version of the driver supports only digital 
  output.
 
  Internally the driver uses videobuf2 framework, and CMA memory allocator.
  Not
  all of them are merged by now, but I decided to post the sources to start
  discussion driver's design.

 
  Cisco (i.e. a few colleagues and myself) are working on this. We hope to 
  post
  an RFC by the end of this month. We also have a proposal for CEC support 
  in
  the pipeline.

 Any reason to not use the drm kms APIs for modesetting, display
 configuration, and hotplug support?  We already have the
 infrastructure in place for complex display configurations and
 generating events for hotplug interrupts.  It would seem to make more
 sense to me to fix any deficiencies in the KMS APIs than to spin a new
 API.  Things like CEC would be a natural fit since a lot of desktop
 GPUs support hdmi audio/3d/etc. and are already using kms.

 Alex

 I'll toss one out: lack of API documentation for driver or application
 developers to use.


 When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to
 possibly get rid of reliance on the ivtv X video driver
 http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation
 was really sparse.

 DRM had the most documentation under Documentation/DocBook/drm.tmpl, but
 the userland API wasn't fleshed out.  GEM was talked about a bit in
 there as well, IIRC.

 TTM documentation was essentially non-existant.

 I can't find any KMS documentation either.

 I recall having to read much of the drm code, and having to look at the
 radeon driver, just to tease out what the DRM ioctls needed to do.

 Am I missing a Documentation source for the APIs?

Yes,

My summer of code project's purpose was to create something of a
tutorial for writing a KMS driver. The code, split out into something
like 15 step-by-step patches, and accompanying documentation are
available from Google's website.

http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz

My repository (doesn't include the documentation) is available here:
http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary

There's a 'rebased' branch that contains API changes required for the
code to work with 2.6.37~.

I hope it's useful to you.

I can't image how the lack of documentation of an used and tested API
could be a serious reason to write you own. That makes absolutely no
sense to me, so I hope you'll decide to use KMS.

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

[PATCH 2/2] amd-k7-agp: remove non-x86 code

[Matt Turner]

amd-k7-agp can't be built on Alpha anymore, so remove now unnecessary
code.

Signed-off-by: Matt Turner 
---
 drivers/char/agp/amd-k7-agp.c |   19 ---
 1 files changed, 0 insertions(+), 19 deletions(-)

diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c
index b1b4362..45681c0 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -41,22 +41,8 @@ static int amd_create_page_map(struct amd_page_map *page_map)
if (page_map->real == NULL)
return -ENOMEM;

-#ifndef CONFIG_X86
-   SetPageReserved(virt_to_page(page_map->real));
-   global_cache_flush();
-   page_map->remapped = ioremap_nocache(virt_to_phys(page_map->real),
-   PAGE_SIZE);
-   if (page_map->remapped == NULL) {
-   ClearPageReserved(virt_to_page(page_map->real));
-   free_page((unsigned long) page_map->real);
-   page_map->real = NULL;
-   return -ENOMEM;
-   }
-   global_cache_flush();
-#else
set_memory_uc((unsigned long)page_map->real, 1);
page_map->remapped = page_map->real;
-#endif

for (i = 0; i < PAGE_SIZE / sizeof(unsigned long); i++) {
writel(agp_bridge->scratch_page, page_map->remapped+i);
@@ -68,12 +54,7 @@ static int amd_create_page_map(struct amd_page_map *page_map)

 static void amd_free_page_map(struct amd_page_map *page_map)
 {
-#ifndef CONFIG_X86
-   iounmap(page_map->remapped);
-   ClearPageReserved(virt_to_page(page_map->real));
-#else
set_memory_wb((unsigned long)page_map->real, 1);
-#endif
free_page((unsigned long) page_map->real);
 }

-- 
1.7.2.2

[PATCH 1/2] Revert "agp: AMD AGP is used on UP1100 & UP1500 alpha boxen"

[Matt Turner]

This reverts commit f191f144079b0083c6fa7d01a4acbd7263fb5032.

The AMD 751 and 761 chipsets are used on the UP1000, UP1100, and UP1500
OEM motherboards, but they neglect to do anything to make AGP work.

According to Ivan Kokshaysky:
There is quite fundamental conflict between the Alpha architecture and
x86 AGP implementation - Alpha is entirely cache coherent by design,
while x86 AGP is not (I mean native AGP DMA transactions, not a PCI over
AGP). There are no such things as non-cacheable mappings or software
support for cache flushing/invalidation on Alpha, so x86 AGP code won't
work on Nautilus.

So there's no point in allowing this driver to be configured on Alpha.

Signed-off-by: Matt Turner 
---
 drivers/char/agp/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig
index fcd867d..d8b1b57 100644
--- a/drivers/char/agp/Kconfig
+++ b/drivers/char/agp/Kconfig
@@ -50,7 +50,7 @@ config AGP_ATI

 config AGP_AMD
tristate "AMD Irongate, 761, and 762 chipset support"
-   depends on AGP && (X86_32 || ALPHA)
+   depends on AGP && X86_32
help
  This option gives you AGP support for the GLX component of
  X on AMD Irongate, 761, and 762 chipsets.
-- 
1.7.2.2

[PATCH 2/2] amd-k7-agp: remove non-x86 code

[Matt Turner]

amd-k7-agp can't be built on Alpha anymore, so remove now unnecessary
code.

Signed-off-by: Matt Turner matts...@gmail.com
---
 drivers/char/agp/amd-k7-agp.c |   19 ---
 1 files changed, 0 insertions(+), 19 deletions(-)

diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c
index b1b4362..45681c0 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -41,22 +41,8 @@ static int amd_create_page_map(struct amd_page_map *page_map)
if (page_map-real == NULL)
return -ENOMEM;
 
-#ifndef CONFIG_X86
-   SetPageReserved(virt_to_page(page_map-real));
-   global_cache_flush();
-   page_map-remapped = ioremap_nocache(virt_to_phys(page_map-real),
-   PAGE_SIZE);
-   if (page_map-remapped == NULL) {
-   ClearPageReserved(virt_to_page(page_map-real));
-   free_page((unsigned long) page_map-real);
-   page_map-real = NULL;
-   return -ENOMEM;
-   }
-   global_cache_flush();
-#else
set_memory_uc((unsigned long)page_map-real, 1);
page_map-remapped = page_map-real;
-#endif
 
for (i = 0; i  PAGE_SIZE / sizeof(unsigned long); i++) {
writel(agp_bridge-scratch_page, page_map-remapped+i);
@@ -68,12 +54,7 @@ static int amd_create_page_map(struct amd_page_map *page_map)
 
 static void amd_free_page_map(struct amd_page_map *page_map)
 {
-#ifndef CONFIG_X86
-   iounmap(page_map-remapped);
-   ClearPageReserved(virt_to_page(page_map-real));
-#else
set_memory_wb((unsigned long)page_map-real, 1);
-#endif
free_page((unsigned long) page_map-real);
 }
 
-- 
1.7.2.2

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

[PATCH 1/2] Revert agp: AMD AGP is used on UP1100 UP1500 alpha boxen

[Matt Turner]

This reverts commit f191f144079b0083c6fa7d01a4acbd7263fb5032.

The AMD 751 and 761 chipsets are used on the UP1000, UP1100, and UP1500
OEM motherboards, but they neglect to do anything to make AGP work.

According to Ivan Kokshaysky:
There is quite fundamental conflict between the Alpha architecture and
x86 AGP implementation - Alpha is entirely cache coherent by design,
while x86 AGP is not (I mean native AGP DMA transactions, not a PCI over
AGP). There are no such things as non-cacheable mappings or software
support for cache flushing/invalidation on Alpha, so x86 AGP code won't
work on Nautilus.

So there's no point in allowing this driver to be configured on Alpha.

Signed-off-by: Matt Turner matts...@gmail.com
---
 drivers/char/agp/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig
index fcd867d..d8b1b57 100644
--- a/drivers/char/agp/Kconfig
+++ b/drivers/char/agp/Kconfig
@@ -50,7 +50,7 @@ config AGP_ATI
 
 config AGP_AMD
tristate AMD Irongate, 761, and 762 chipset support
-   depends on AGP  (X86_32 || ALPHA)
+   depends on AGP  X86_32
help
  This option gives you AGP support for the GLX component of
  X on AMD Irongate, 761, and 762 chipsets.
-- 
1.7.2.2

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

intelfb refuses to load

[Matt Turner]

On Sat, Dec 11, 2010 at 10:13 PM, Pavel Machek  wrote:

You want CONFIG_DRM_I915 and not CONFIG_FB_INTEL. The old framebuffer
driver should not be used in conjunction with xf86-video-intel.

Matt

Re: intelfb refuses to load

[Matt Turner]

On Sat, Dec 11, 2010 at 10:13 PM, Pavel Machek pa...@ucw.cz wrote:

You want CONFIG_DRM_I915 and not CONFIG_FB_INTEL. The old framebuffer
driver should not be used in conjunction with xf86-video-intel.

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

@tungstengraphics.com email addresses all over bugzilla

[Matt Turner]

We should update everyone's email addresses, now that
tungstengraphics.com is owned by squatters. Who let that happen, by
the way? :\

Matt

@tungstengraphics.com email addresses all over bugzilla

[Matt Turner]

We should update everyone's email addresses, now that
tungstengraphics.com is owned by squatters. Who let that happen, by
the way? :\

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

3Dfx KMS board needed

[Matt Turner]

On Wed, Nov 10, 2010 at 7:45 PM, James Simmons  
wrote:
> Looking to work on the 3Dfx KMS driver I discovered that it is very
> difficult to find a motherboard that supports AGP of 3.3V. So I discovered
> that the only 3Dfx card that supports this is the 3dfx Voodoo 4 4500 AGP
> Card which also is difficult to find. Does anyone have this card to send
> to me or a old working system with a 3.3V AGP bus. Thanks.

Sorry, I'm having a hard time understanding. If motherboards with 3.3V
AGP are difficult to find, why are you looking for a Voodoo 4 4500?
You must mean that the Voodoo 4 4500 is the only AGP card that also
supports 1.5V AGP signaling?

I see a very cheap Voodoo 4 4500 on eBay in the UK. Item # 110610063423.

Also, the 4500 and 5500 come in PCI.

I had trouble finding a suitable board to use with Permedia hardware
this summer. The last to support 3.3V AGP were the Athlon MP
motherboards, e.g., Tyan S246{0,2,6,8,9}. But at least you get dual
processors.

For reference, the last 3.3V supporting video cards were the R300
series (specifically Radeon 9800 Pro, but not 9800 XT) and the GeForce
7950 GT. Not that any of that's specifically related to your query.

Thanks,
Matt

Re: 3Dfx KMS board needed

[Matt Turner]

On Wed, Nov 10, 2010 at 7:45 PM, James Simmons jsimm...@infradead.org wrote:
 Looking to work on the 3Dfx KMS driver I discovered that it is very
 difficult to find a motherboard that supports AGP of 3.3V. So I discovered
 that the only 3Dfx card that supports this is the 3dfx Voodoo 4 4500 AGP
 Card which also is difficult to find. Does anyone have this card to send
 to me or a old working system with a 3.3V AGP bus. Thanks.

Sorry, I'm having a hard time understanding. If motherboards with 3.3V
AGP are difficult to find, why are you looking for a Voodoo 4 4500?
You must mean that the Voodoo 4 4500 is the only AGP card that also
supports 1.5V AGP signaling?

I see a very cheap Voodoo 4 4500 on eBay in the UK. Item # 110610063423.

Also, the 4500 and 5500 come in PCI.

I had trouble finding a suitable board to use with Permedia hardware
this summer. The last to support 3.3V AGP were the Athlon MP
motherboards, e.g., Tyan S246{0,2,6,8,9}. But at least you get dual
processors.

For reference, the last 3.3V supporting video cards were the R300
series (specifically Radeon 9800 Pro, but not 9800 XT) and the GeForce
7950 GT. Not that any of that's specifically related to your query.

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

[PATCH 1/4] drivers/gpu/drm/vmwgfx: Fix k.alloc switched arguments

[Matt Turner]

On Sun, Oct 31, 2010 at 6:33 PM, Joe Perches  wrote:
> Signed-off-by: Joe Perches 
> ---
> ?drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c ? ? | ? ?2 +-
> ?drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | ? ?2 +-
> ?2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> index a01c47d..29113c9 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> @@ -557,7 +557,7 @@ int vmw_kms_init_legacy_display_system(struct vmw_private 
> *dev_priv)
> ? ? ? ? ? ? ? ?return -EINVAL;
> ? ? ? ?}
>
> - ? ? ? dev_priv->ldu_priv = kmalloc(GFP_KERNEL, sizeof(*dev_priv->ldu_priv));
> + ? ? ? dev_priv->ldu_priv = kmalloc(sizeof(*dev_priv->ldu_priv), GFP_KERNEL);
>
> ? ? ? ?if (!dev_priv->ldu_priv)
> ? ? ? ? ? ? ? ?return -ENOMEM;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
> index df2036e..f1a52f9 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
> @@ -585,7 +585,7 @@ int vmw_overlay_init(struct vmw_private *dev_priv)
> ? ? ? ? ? ? ? ?return -ENOSYS;
> ? ? ? ?}
>
> - ? ? ? overlay = kmalloc(GFP_KERNEL, sizeof(*overlay));
> + ? ? ? overlay = kmalloc(sizeof(*overlay), GFP_KERNEL);
> ? ? ? ?if (!overlay)
> ? ? ? ? ? ? ? ?return -ENOMEM;
>
> --
> 1.7.3.1.g432b3.dirty

Oh! That's a bad one.

Reviewed-by: Matt Turner 

Re: [PATCH 1/4] drivers/gpu/drm/vmwgfx: Fix k.alloc switched arguments

[Matt Turner]

On Sun, Oct 31, 2010 at 6:33 PM, Joe Perches j...@perches.com wrote:
 Signed-off-by: Joe Perches j...@perches.com
 ---
  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c     |    2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |    2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
 b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
 index a01c47d..29113c9 100644
 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
 +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
 @@ -557,7 +557,7 @@ int vmw_kms_init_legacy_display_system(struct vmw_private 
 *dev_priv)
                return -EINVAL;
        }

 -       dev_priv-ldu_priv = kmalloc(GFP_KERNEL, sizeof(*dev_priv-ldu_priv));
 +       dev_priv-ldu_priv = kmalloc(sizeof(*dev_priv-ldu_priv), GFP_KERNEL);

        if (!dev_priv-ldu_priv)
                return -ENOMEM;
 diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c 
 b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
 index df2036e..f1a52f9 100644
 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
 +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
 @@ -585,7 +585,7 @@ int vmw_overlay_init(struct vmw_private *dev_priv)
                return -ENOSYS;
        }

 -       overlay = kmalloc(GFP_KERNEL, sizeof(*overlay));
 +       overlay = kmalloc(sizeof(*overlay), GFP_KERNEL);
        if (!overlay)
                return -ENOMEM;

 --
 1.7.3.1.g432b3.dirty

Oh! That's a bad one.

Reviewed-by: Matt Turner matts...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC libdrm] Use __sync_val_compare_and_swap to implement DRM_CAS

[Matt Turner]

Can we use gcc's __sync_val_compare_and_swap to implement DRM_CAS?
(If so, do we actually need the __sync_val version, or can we use
__sync_bool?)

I just threw the patch together in two minutes, so I've got no idea
if it's right, just looking for feedback. The purpose of this is to
remove a lot of inline assembly that hasn't been touched since the
file was added in 2004, including some awesome already-assembled
SPARC instructions.

Apparently someone had this idea before me. Way before me, as this
code already exists in the Itanium section, though commented out for
some reason long forgotten.

I don't have any idea when gcc added this. I just said 4.0, but this
must be wrong, given the previous paragraph.

http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html
---
 xf86drm.h |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/xf86drm.h b/xf86drm.h
index 9b89f56..1459b5a 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -333,7 +333,12 @@ typedef struct _drmSetVersion {
 #define DRM_LOCK_HELD  0x8000U /**< Hardware lock is held */
 #define DRM_LOCK_CONT  0x4000U /**< Hardware lock is contended */

-#if defined(__GNUC__) && (__GNUC__ >= 2)
+#if defined(__GNUC__) && (__GNUC__ >= 4)
+
+#define DRM_CAS(lock, old, new, __ret) \
+   __ret = __sync_val_compare_and_swap(i&__drm_dummy_lock(lock), (old), 
(new)) != (old)
+
+#elif defined(__GNUC__) && (__GNUC__ >= 2)
 # if defined(__i386) || defined(__AMD64__) || defined(__x86_64__) || 
defined(__amd64__)
/* Reflect changes here to drmP.h */
 #define DRM_CAS(lock,old,new,__ret)\
-- 
1.7.2.2

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 

[RFC libdrm] Use __sync_val_compare_and_swap to implement DRM_CAS

[Matt Turner]

Can we use gcc's __sync_val_compare_and_swap to implement DRM_CAS?
(If so, do we actually need the __sync_val version, or can we use
__sync_bool?)

I just threw the patch together in two minutes, so I've got no idea
if it's right, just looking for feedback. The purpose of this is to
remove a lot of inline assembly that hasn't been touched since the
file was added in 2004, including some awesome already-assembled
SPARC instructions.

Apparently someone had this idea before me. Way before me, as this
code already exists in the Itanium section, though commented out for
some reason long forgotten.

I don't have any idea when gcc added this. I just said 4.0, but this
must be wrong, given the previous paragraph.

http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html
---
 xf86drm.h |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/xf86drm.h b/xf86drm.h
index 9b89f56..1459b5a 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -333,7 +333,12 @@ typedef struct _drmSetVersion {
 #define DRM_LOCK_HELD  0x8000U /** Hardware lock is held */
 #define DRM_LOCK_CONT  0x4000U /** Hardware lock is contended */
 
-#if defined(__GNUC__)  (__GNUC__ = 2)
+#if defined(__GNUC__)  (__GNUC__ = 4)
+
+#define DRM_CAS(lock, old, new, __ret) \
+   __ret = __sync_val_compare_and_swap(i__drm_dummy_lock(lock), (old), 
(new)) != (old)
+
+#elif defined(__GNUC__)  (__GNUC__ = 2)
 # if defined(__i386) || defined(__AMD64__) || defined(__x86_64__) || 
defined(__amd64__)
/* Reflect changes here to drmP.h */
 #define DRM_CAS(lock,old,new,__ret)\
-- 
1.7.2.2



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

[PATCH] drm/radeon/kms: fix bad cast/shift in evergreen.c

[Matt Turner]

On Mon, Oct 11, 2010 at 12:41 PM, Alex Deucher  wrote:
> Missing parens.
>
> fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=30718
>
> Reported-by: Dave Gilbert 
> Signed-off-by: Alex Deucher 
> Cc: stable at kernel.org
> ---
> ?drivers/gpu/drm/radeon/evergreen.c | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 2d38eae..2117cf5 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1208,7 +1208,7 @@ static void evergreen_gpu_init(struct radeon_device 
> *rdev)
>
> ? ? ? ? ? ? ? ?WREG32(RCU_IND_INDEX, 0x203);
> ? ? ? ? ? ? ? ?efuse_straps_3 = RREG32(RCU_IND_DATA);
> - ? ? ? ? ? ? ? efuse_box_bit_127_124 = (u8)(efuse_straps_3 & 0xF000) >> 
> 28;
> + ? ? ? ? ? ? ? efuse_box_bit_127_124 = (u8)((efuse_straps_3 & 0xF000) >> 
> 28);
>
> ? ? ? ? ? ? ? ?switch(efuse_box_bit_127_124) {
> ? ? ? ? ? ? ? ?case 0x0:
> --
> 1.7.1.1

Reviewed-by: Matt Turner 

GSoC: modprobe glint - monitor loses signal

[Matt Turner]

I'll preface this response by saying that the driver is working now,
in very large part due to help I've received from Adam Jackson, Dave
Airlie, Alex Deucher, and Jerome Glisse.

On Thu, Aug 5, 2010 at 5:47 PM, Adam Jackson  wrote:
> On Thu, 2010-08-05 at 12:16 -0400, Matt Turner wrote:
>> Hi,
>> I've hit a snag and I'm not really sure how to debug it.
>>
>> Both xf86-video-glint/src/pm3_dac.c:Permedia3Init and
>> kernel/drivers/video/pm3fb.c:pm3fb_write_mode set the mode in
>> virtually identical ways. I'm trying to do the same, but I think some
>> of what I'm passing in from drm_display_mode is wrong, specifically
>>
>> WREG32(PM3HTotal, ?glint_shift_bpp(bpp, mode->htotal - 1));
>> WREG32(PM3HsEnd, ? glint_shift_bpp(bpp, mode->hsync_end - mode->hdisplay));
>> WREG32(PM3HsStart, glint_shift_bpp(bpp, mode->hsync_start - mode->hdisplay));
>> WREG32(PM3HbEnd, ? glint_shift_bpp(bpp, mode->htotal - mode->hdisplay));
>> WREG32(PM3HgEnd, ? glint_shift_bpp(bpp, mode->htotal - mode->hdisplay));
>> WREG32(PM3ScreenStride, glint_shift_bpp(bpp, crtc->fb->width));
>> WREG32(PM3VTotal, ?glint_shift_bpp(bpp, mode->vtotal - 1));
>> WREG32(PM3VsEnd, ? glint_shift_bpp(bpp, mode->vsync_end - 1));
>> WREG32(PM3VsStart, glint_shift_bpp(bpp, mode->vsync_start - 1));
>> WREG32(PM3VbEnd, ? glint_shift_bpp(bpp, mode->vtotal - mode->vdisplay));
>>
>> I printed the values that xf86-video-glint passes through here, and of
>> course they don't match with anything my driver has. I imagine guess
>> it's because they're all resolution-dependent?
>
> They are. ?What does the X driver print, and what mode are you trying to
> set?

I'm setting 1024x768x24 (32 bpp).

Timings set by my driver are
PM3HTotal: 335
PM3HsEnd: 40
PM3HsStart: 6
PM3HbEnd: 80
PM3HgEnd: 80
PM3ScreenStride: 256
PM3VTotal: 805
PM3VsEnd: 8
PM3VsStart: 2
PM3VbEnd: 38

Timings set by xf86-video-glint are (for the same mode)
PM3HTotal: 327
PM3HsEnd: 28
PM3HsStart: 4
PM3HbEnd: 72
PM3HgEnd: 72
PM3ScreenStride: 256
PM3VTotal: 799
PM3VsEnd: 3
PM3VsStart: 0
PM3VbEnd: 32

So, clearly very close.

The final thing I did to make it work was to set the PM3VideoControl
register to turn on hsync and vsync. So, of course without this I'm
not getting any signals to the monitor. :)

> This though:
>
> ? ?WREG32(PM3VsStart, glint_shift_bpp(bpp, mode->vsync_start - 1));
>
> Versus in the X driver:
>
> ? ?temp2 = mode->CrtcVSyncStart - mode->CrtcVDisplay;
> ? ?...
> ? ?STOREREG(PMVsStart, temp2 - 1);

Yes, you were right about this. I've changed them to
 - PM3VsEnd = mode->vsync_end - mode->vdisplay - 1
 - PM3VsStart = mode->vsync_start - mode->vdisplay - 1

I also noticed that I was using glint_shift_bpp on the vsync timings,
which isn't correct.

> For a mode like 1920x1200R, the former is going to be 1202, but the
> latter is going to be (1203 - 1200) - 1 == 2. ?So assuming the X driver
> is right, the hardware is looking for the distance in clocks between the
> various sync steps, and not their absolute offset from the beginning of
> the line/frame.

Yep, this appears to be the case. It also appears, and I could be
wrong, not to be what the documentation states. :)

> - ajax

Thanks again to everyone who helped me. Now I'll write up some
documentation to finish off the GSoC requirements and hopefully will
fix up the driver to a state where it can live in the kernel.

Matt

GSoC: modprobe glint - monitor loses signal

[Matt Turner]

Hi,
I've hit a snag and I'm not really sure how to debug it.

Both xf86-video-glint/src/pm3_dac.c:Permedia3Init and
kernel/drivers/video/pm3fb.c:pm3fb_write_mode set the mode in
virtually identical ways. I'm trying to do the same, but I think some
of what I'm passing in from drm_display_mode is wrong, specifically

WREG32(PM3HTotal,  glint_shift_bpp(bpp, mode->htotal - 1));
WREG32(PM3HsEnd,   glint_shift_bpp(bpp, mode->hsync_end - mode->hdisplay));
WREG32(PM3HsStart, glint_shift_bpp(bpp, mode->hsync_start - mode->hdisplay));
WREG32(PM3HbEnd,   glint_shift_bpp(bpp, mode->htotal - mode->hdisplay));
WREG32(PM3HgEnd,   glint_shift_bpp(bpp, mode->htotal - mode->hdisplay));
WREG32(PM3ScreenStride, glint_shift_bpp(bpp, crtc->fb->width));
WREG32(PM3VTotal,  glint_shift_bpp(bpp, mode->vtotal - 1));
WREG32(PM3VsEnd,   glint_shift_bpp(bpp, mode->vsync_end - 1));
WREG32(PM3VsStart, glint_shift_bpp(bpp, mode->vsync_start - 1));
WREG32(PM3VbEnd,   glint_shift_bpp(bpp, mode->vtotal - mode->vdisplay));

I printed the values that xf86-video-glint passes through here, and of
course they don't match with anything my driver has. I imagine guess
it's because they're all resolution-dependent?

Can anyone give me some advice?

Thanks,
Matt

Re: GSoC: modprobe glint - monitor loses signal

[Matt Turner]

I'll preface this response by saying that the driver is working now,
in very large part due to help I've received from Adam Jackson, Dave
Airlie, Alex Deucher, and Jerome Glisse.

On Thu, Aug 5, 2010 at 5:47 PM, Adam Jackson a...@redhat.com wrote:
 On Thu, 2010-08-05 at 12:16 -0400, Matt Turner wrote:
 Hi,
 I've hit a snag and I'm not really sure how to debug it.

 Both xf86-video-glint/src/pm3_dac.c:Permedia3Init and
 kernel/drivers/video/pm3fb.c:pm3fb_write_mode set the mode in
 virtually identical ways. I'm trying to do the same, but I think some
 of what I'm passing in from drm_display_mode is wrong, specifically

 WREG32(PM3HTotal,  glint_shift_bpp(bpp, mode-htotal - 1));
 WREG32(PM3HsEnd,   glint_shift_bpp(bpp, mode-hsync_end - mode-hdisplay));
 WREG32(PM3HsStart, glint_shift_bpp(bpp, mode-hsync_start - mode-hdisplay));
 WREG32(PM3HbEnd,   glint_shift_bpp(bpp, mode-htotal - mode-hdisplay));
 WREG32(PM3HgEnd,   glint_shift_bpp(bpp, mode-htotal - mode-hdisplay));
 WREG32(PM3ScreenStride, glint_shift_bpp(bpp, crtc-fb-width));
 WREG32(PM3VTotal,  glint_shift_bpp(bpp, mode-vtotal - 1));
 WREG32(PM3VsEnd,   glint_shift_bpp(bpp, mode-vsync_end - 1));
 WREG32(PM3VsStart, glint_shift_bpp(bpp, mode-vsync_start - 1));
 WREG32(PM3VbEnd,   glint_shift_bpp(bpp, mode-vtotal - mode-vdisplay));

 I printed the values that xf86-video-glint passes through here, and of
 course they don't match with anything my driver has. I imagine guess
 it's because they're all resolution-dependent?

 They are.  What does the X driver print, and what mode are you trying to
 set?

I'm setting 1024x768x24 (32 bpp).

Timings set by my driver are
PM3HTotal: 335
PM3HsEnd: 40
PM3HsStart: 6
PM3HbEnd: 80
PM3HgEnd: 80
PM3ScreenStride: 256
PM3VTotal: 805
PM3VsEnd: 8
PM3VsStart: 2
PM3VbEnd: 38

Timings set by xf86-video-glint are (for the same mode)
PM3HTotal: 327
PM3HsEnd: 28
PM3HsStart: 4
PM3HbEnd: 72
PM3HgEnd: 72
PM3ScreenStride: 256
PM3VTotal: 799
PM3VsEnd: 3
PM3VsStart: 0
PM3VbEnd: 32

So, clearly very close.

The final thing I did to make it work was to set the PM3VideoControl
register to turn on hsync and vsync. So, of course without this I'm
not getting any signals to the monitor. :)

 This though:

    WREG32(PM3VsStart, glint_shift_bpp(bpp, mode-vsync_start - 1));

 Versus in the X driver:

    temp2 = mode-CrtcVSyncStart - mode-CrtcVDisplay;
    ...
    STOREREG(PMVsStart, temp2 - 1);

Yes, you were right about this. I've changed them to
 - PM3VsEnd = mode-vsync_end - mode-vdisplay - 1
 - PM3VsStart = mode-vsync_start - mode-vdisplay - 1

I also noticed that I was using glint_shift_bpp on the vsync timings,
which isn't correct.

 For a mode like 1920x1200R, the former is going to be 1202, but the
 latter is going to be (1203 - 1200) - 1 == 2.  So assuming the X driver
 is right, the hardware is looking for the distance in clocks between the
 various sync steps, and not their absolute offset from the beginning of
 the line/frame.

Yep, this appears to be the case. It also appears, and I could be
wrong, not to be what the documentation states. :)

 - ajax

Thanks again to everyone who helped me. Now I'll write up some
documentation to finish off the GSoC requirements and hopefully will
fix up the driver to a state where it can live in the kernel.

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

[PATCH 1/4] drm: Remove drm_resource wrappers

[Matt Turner]

esource_start(dev, 0);
> + ? ? ? ? ? ? ? fb_base = pci_resource_start(dev->pdev, 0);
> ? ? ? ? ? ? ? ?fb_size = SAVAGE_FB_SIZE_S3;
> ? ? ? ? ? ? ? ?mmio_base = fb_base + SAVAGE_FB_SIZE_S3;
> ? ? ? ? ? ? ? ?aper_rsrc = 0;
> ? ? ? ? ? ? ? ?aperture_base = fb_base + SAVAGE_APERTURE_OFFSET;
> ? ? ? ? ? ? ? ?/* this should always be true */
> - ? ? ? ? ? ? ? if (drm_get_resource_len(dev, 0) == 0x0800) {
> + ? ? ? ? ? ? ? if (pci_resource_len(dev->pdev, 0) == 0x0800) {
> ? ? ? ? ? ? ? ? ? ? ? ?/* Don't make MMIO write-cobining! We need 3
> ? ? ? ? ? ? ? ? ? ? ? ? * MTRRs. */
> ? ? ? ? ? ? ? ? ? ? ? ?dev_priv->mtrr[0].base = fb_base;
> @@ -599,18 +599,19 @@ int savage_driver_firstopen(struct drm_device *dev)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dev_priv->mtrr[2].size, DRM_MTRR_WC);
> ? ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ? ? ? ?DRM_ERROR("strange pci_resource_len %08llx\n",
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (unsigned long 
> long)drm_get_resource_len(dev, 0));
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (unsigned long long)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pci_resource_len(dev->pdev, 0));
> ? ? ? ? ? ? ? ?}
> ? ? ? ?} else if (dev_priv->chipset != S3_SUPERSAVAGE &&
> ? ? ? ? ? ? ? ? ? dev_priv->chipset != S3_SAVAGE2000) {
> - ? ? ? ? ? ? ? mmio_base = drm_get_resource_start(dev, 0);
> + ? ? ? ? ? ? ? mmio_base = pci_resource_start(dev->pdev, 0);
> ? ? ? ? ? ? ? ?fb_rsrc = 1;
> - ? ? ? ? ? ? ? fb_base = drm_get_resource_start(dev, 1);
> + ? ? ? ? ? ? ? fb_base = pci_resource_start(dev->pdev, 1);
> ? ? ? ? ? ? ? ?fb_size = SAVAGE_FB_SIZE_S4;
> ? ? ? ? ? ? ? ?aper_rsrc = 1;
> ? ? ? ? ? ? ? ?aperture_base = fb_base + SAVAGE_APERTURE_OFFSET;
> ? ? ? ? ? ? ? ?/* this should always be true */
> - ? ? ? ? ? ? ? if (drm_get_resource_len(dev, 1) == 0x0800) {
> + ? ? ? ? ? ? ? if (pci_resource_len(dev->pdev, 1) == 0x0800) {
> ? ? ? ? ? ? ? ? ? ? ? ?/* Can use one MTRR to cover both fb and
> ? ? ? ? ? ? ? ? ? ? ? ? * aperture. */
> ? ? ? ? ? ? ? ? ? ? ? ?dev_priv->mtrr[0].base = fb_base;
> @@ -620,15 +621,16 @@ int savage_driver_firstopen(struct drm_device *dev)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dev_priv->mtrr[0].size, DRM_MTRR_WC);
> ? ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ? ? ? ?DRM_ERROR("strange pci_resource_len %08llx\n",
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (unsigned long 
> long)drm_get_resource_len(dev, 1));
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (unsigned long long)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pci_resource_len(dev->pdev, 1));
> ? ? ? ? ? ? ? ?}
> ? ? ? ?} else {
> - ? ? ? ? ? ? ? mmio_base = drm_get_resource_start(dev, 0);
> + ? ? ? ? ? ? ? mmio_base = pci_resource_start(dev->pdev, 0);
> ? ? ? ? ? ? ? ?fb_rsrc = 1;
> - ? ? ? ? ? ? ? fb_base = drm_get_resource_start(dev, 1);
> - ? ? ? ? ? ? ? fb_size = drm_get_resource_len(dev, 1);
> + ? ? ? ? ? ? ? fb_base = pci_resource_start(dev->pdev, 1);
> + ? ? ? ? ? ? ? fb_size = pci_resource_len(dev->pdev, 1);
> ? ? ? ? ? ? ? ?aper_rsrc = 2;
> - ? ? ? ? ? ? ? aperture_base = drm_get_resource_start(dev, 2);
> + ? ? ? ? ? ? ? aperture_base = pci_resource_start(dev->pdev, 2);
> ? ? ? ? ? ? ? ?/* Automatic MTRR setup will do the right thing. */
> ? ? ? ?}
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index c1b9871..8f7f5cb 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1273,10 +1273,6 @@ extern int drm_freebufs(struct drm_device *dev, void 
> *data,
> ?extern int drm_mapbufs(struct drm_device *dev, void *data,
> ? ? ? ? ? ? ? ? ? ? ? struct drm_file *file_priv);
> ?extern int drm_order(unsigned long size);
> -extern resource_size_t drm_get_resource_start(struct drm_device *dev,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned int resource);
> -extern resource_size_t drm_get_resource_len(struct drm_device *dev,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned int resource);
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* DMA support (drm_dma.h) */
> ?extern int drm_dma_setup(struct drm_device *dev);
> --
> 1.7.0.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Reviewed-by: Matt Turner 

(I think I sent my reviewed-by the last time this patch was sent.)

Re: Problems with alpha/pci + radeon/ttm

[Matt Turner]

On Sun, Jun 27, 2010 at 12:20 AM, FUJITA Tomonori
fujita.tomon...@lab.ntt.co.jp wrote:
 On Thu, 24 Jun 2010 10:53:52 -0400
 Matt Turner matts...@gmail.com wrote:

  Seems that the IOMMU can't find 128 pages. It's likely due to:
 
  - out of the IOMMU space (possibly someone doesn't free the IOMMU
   space).
 
  or
 
  - the mapping parameters (such as align) aren't appropriate so the
   IOMMU can't find space.
 
 
  Is this the cause of the bug we're seeing in the report [1]?
 
  Anyone know what's going wrong here?
 
 
  I've attached a patch to print the debug info about the mapping
  parameters.
 
 
  diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
  index d1dbd9a..17cf0d8 100644
  --- a/arch/alpha/kernel/pci_iommu.c
  +++ b/arch/alpha/kernel/pci_iommu.c
  @@ -187,6 +187,10 @@ iommu_arena_alloc(struct device *dev, struct 
  pci_iommu_arena *arena, long n,
         /* Search for N empty ptes */
         ptes = arena-ptes;
         mask = max(align, arena-align_entry) - 1;
  +
  +       printk(%s: %p, %p, %d, %ld, %lx, %u\n, __func__, dev, arena, 
  arena-size,
  +              n, mask, align);
  +
         p = iommu_arena_find_pages(dev, arena, n, mask);
         if (p  0) {
                 spin_unlock_irqrestore(arena-lock, flags);

 Using this patch, I log the attached output.

 Your system has 1GB iommu address space. I guess that it's enough for
 KSM?

I would definitely think so. The video card I'm using here is a 64MB
Radeon 9100 PCI, with a 128MB BAR.

 The parameters in the log looks good. But you got this log before you
 started X?

Yes, that's right.

I'll see if I can isolate where the first -ENOMEM is coming from.

Thanks Fujita for helping with this!

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

Problems with alpha/pci + radeon/ttm

[Matt Turner]

On Sun, Jun 27, 2010 at 12:20 AM, FUJITA Tomonori
 wrote:
> On Thu, 24 Jun 2010 10:53:52 -0400
> Matt Turner  wrote:
>
>> > Seems that the IOMMU can't find 128 pages. It's likely due to:
>> >
>> > - out of the IOMMU space (possibly someone doesn't free the IOMMU
>> > ?space).
>> >
>> > or
>> >
>> > - the mapping parameters (such as align) aren't appropriate so the
>> > ?IOMMU can't find space.
>> >
>> >
>> >> Is this the cause of the bug we're seeing in the report [1]?
>> >>
>> >> Anyone know what's going wrong here?
>> >
>> >
>> > I've attached a patch to print the debug info about the mapping
>> > parameters.
>> >
>> >
>> > diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
>> > index d1dbd9a..17cf0d8 100644
>> > --- a/arch/alpha/kernel/pci_iommu.c
>> > +++ b/arch/alpha/kernel/pci_iommu.c
>> > @@ -187,6 +187,10 @@ iommu_arena_alloc(struct device *dev, struct 
>> > pci_iommu_arena *arena, long n,
>> > ? ? ? ?/* Search for N empty ptes */
>> > ? ? ? ?ptes = arena->ptes;
>> > ? ? ? ?mask = max(align, arena->align_entry) - 1;
>> > +
>> > + ? ? ? printk("%s: %p, %p, %d, %ld, %lx, %u\n", __func__, dev, arena, 
>> > arena->size,
>> > + ? ? ? ? ? ? ?n, mask, align);
>> > +
>> > ? ? ? ?p = iommu_arena_find_pages(dev, arena, n, mask);
>> > ? ? ? ?if (p < 0) {
>> > ? ? ? ? ? ? ? ?spin_unlock_irqrestore(>lock, flags);
>>
>> Using this patch, I log the attached output.
>
> Your system has 1GB iommu address space. I guess that it's enough for
> KSM?

I would definitely think so. The video card I'm using here is a 64MB
Radeon 9100 PCI, with a 128MB BAR.

> The parameters in the log looks good. But you got this log before you
> started X?

Yes, that's right.

I'll see if I can isolate where the first -ENOMEM is coming from.

Thanks Fujita for helping with this!

Matt

Problems with alpha/pci + radeon/ttm

[Matt Turner]

On Thu, Jun 24, 2010 at 5:51 AM, Michael Cree  wrote:
> On 22/06/10 20:32, Dave Airlie wrote:
>>
>> On Tue, Jun 22, 2010 at 3:59 PM, FUJITA Tomonori
>>  ?wrote:
>>>
>>> On Mon, 21 Jun 2010 17:19:43 -0400
>>> Matt Turner ?wrote:
>>>
>>>> Michael Cree and I have been debugging FDO bug 26403 [1]. I tried
>>>> booting with `radeon.test=1` and found this, which I think is related:
>
> Note that my radeon card is PCI whereas I think Matt may be using an AGP
> card.

Actually, I'm using a plain Radeon 9100 PCI.

> My logs are very similar to Matt's except I don't see the following line:
>
>>>>> pci_map_single failed: could not allocate dma page tables
>
>
>>> This happens in the latest git, right?
>
> Indeed, testing 2.6.35-rc3 (plus a couple or so extra patches to fix
> unrelated compile errors).
>
>>> Is this a regression (what kernel version worked)?
>>>
>>> Seems that the IOMMU can't find 128 pages. It's likely due to:
>>>
>>> - out of the IOMMU space (possibly someone doesn't free the IOMMU
>>> ?space).
>>>
>>> or
>>>
>>> - the mapping parameters (such as align) aren't appropriate so the
>>> ?IOMMU can't find space.
>>
>> I don't think KMS drivers have ever worked on alpha so its not a
>> regression, they are working fine on x86 + powerpc and sparc has been
>> run at least once.
>
> KMS on the console boot up has worked since about 2.6.32, but starting up
> the X server has always failed and, in my case, the system becomes unstable
> and eventually OOPs.
>
>> I suspect we are simply hitting the limits of the iommu, how big an
>> address space does it handle? since generally graphics drivers try to
>> bind a lot of things to the GART.
>
> No idea on the address space limit. ?I applied the patch of Fujita that logs
> all IOMMU allocations, and also inserted some extra printks in the ttm
> kernel code so that I could see which routines failed and the error code
> returned. ?Running the radeon test on boot exhibits the following:
>
> [ ?238.712768] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset
> 0x1a312000
> [ ?239.281127] [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset
> 0x1a412000
> [ ?239.281127] ttm_tt_bind belched -12
> [ ?239.282104] ttm_bo_handle_move_mem belched -12
> [ ?239.282104] ttm_bo_move_buffer belched -12
> [ ?239.282104] ttm_bo_validate belched -12
> [ ?239.282104] radeon :01:00.0: object_init failed for (1048576,
> 0x0002) err=-12
> [ ?239.282104] [drm:radeon_test_moves] *ERROR* Failed to create GTT object
> 419
> [ ?239.399291] Error while testing BO move.
>
> Note that no IOMMU allocations are printed while radeon_test_moves is
> running so iommu_arena_alloc doesn't appear to be called. ?Also the error
> code returned up to radeon_test_moves is -12 which is ENOMEM. ?So does
> appear to be some memory limit.

I confirm that we're getting -ENOMEM. I don't know if it's coming from
radeon_gart_bind(), but if it is there's an interesting comment
immediately after the call to pci_map_page:

if (pci_dma_mapping_error(rdev->pdev, rdev->gart.pages_addr[p])) {
/* FIXME: failed to map page (return -ENOMEM?) */
radeon_gart_unbind(rdev, offset, pages);
return -ENOMEM;
}

>> It might be worth limiting the PCIGART in radeon to 32MB to see if the
>> lower limit helps.
>
> So, how does one do that?

Boot with `radeon.test=1 radeon.gartsize=`.
> Cheers
> Michael.

Thanks,
Matt

Problems with alpha/pci + radeon/ttm

[Matt Turner]

On Tue, Jun 22, 2010 at 1:59 AM, FUJITA Tomonori
 wrote:
> On Mon, 21 Jun 2010 17:19:43 -0400
> Matt Turner  wrote:
>
>> Michael Cree and I have been debugging FDO bug 26403 [1]. I tried
>> booting with `radeon.test=1` and found this, which I think is related:
>>
>> > [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x202000
>> > [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x302000
>> [snip]
>> > [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0xfd02000
>> > [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0xfe02000
>> > pci_map_single failed: could not allocate dma page tables
>> > [drm:radeon_ttm_backend_bind] *ERROR* failed to bind 128 pages at 
>> > 0x0FF02000
>> > [TTM] Couldn't bind backend.
>> > radeon :00:07.0: object_init failed for (1048576, 0x0002)
>> > [drm:radeon_test_moves] *ERROR* Failed to create GTT object 253
>> > Error while testing BO move.
>>
>> From what I can see, the call chain is
>> radeon_test_moves
>> ?(radeon_ttm_backend_bind called through callback function)
>> ?- radeon_ttm.c:radeon_ttm_backend_bind calls radeon_gart_bind
>> ? - radeon_gart.c:radeon_gart_bind calls pci_map_page
>> ? ?- pci_map_page is alpha_pci_map_page, which calls...
>> ? ? - alpha_pci_map_page calls pci_iommu.c:pci_map_single_1
>> ? ? ?- pci_map_single_1 calls iommu_arena_alloc
>> ? ? ? - iommu_arena_alloc calls iommu_arena_find_pages
>> ? ? ? ?- iommu_arena_find_pages returns non-0
>> ? ? ? - iommu_arena_alloc returns non-0
>> ? ? ?- pci_map_single_1 returns 0 after printing
>> ? ? ? ?"could not allocate dma page tables" error
>> ? ? - alpha_pci_map_page returns 0 from pci_map_single_1
>> ? - radeon_gart_bind returns non-0, error path prints
>> ? ? "*ERROR* failed to bind 128 pages at 0x0FF02000"
>
> This happens in the latest git, right?

I'm using 2.6.35-rc2, but I could try rc3 if you think it would make a
difference.

> Is this a regression (what kernel version worked)?

The framebuffer console has always worked, but I've never known X on
KMS to work. The radeon.test parameter hasn't existed the entire time,
but I could try still previous kernels.

> Seems that the IOMMU can't find 128 pages. It's likely due to:
>
> - out of the IOMMU space (possibly someone doesn't free the IOMMU
> ?space).
>
> or
>
> - the mapping parameters (such as align) aren't appropriate so the
> ?IOMMU can't find space.
>
>
>> Is this the cause of the bug we're seeing in the report [1]?
>>
>> Anyone know what's going wrong here?
>
>
> I've attached a patch to print the debug info about the mapping
> parameters.
>
>
> diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
> index d1dbd9a..17cf0d8 100644
> --- a/arch/alpha/kernel/pci_iommu.c
> +++ b/arch/alpha/kernel/pci_iommu.c
> @@ -187,6 +187,10 @@ iommu_arena_alloc(struct device *dev, struct 
> pci_iommu_arena *arena, long n,
> ? ? ? ?/* Search for N empty ptes */
> ? ? ? ?ptes = arena->ptes;
> ? ? ? ?mask = max(align, arena->align_entry) - 1;
> +
> + ? ? ? printk("%s: %p, %p, %d, %ld, %lx, %u\n", __func__, dev, arena, 
> arena->size,
> + ? ? ? ? ? ? ?n, mask, align);
> +
> ? ? ? ?p = iommu_arena_find_pages(dev, arena, n, mask);
> ? ? ? ?if (p < 0) {
> ? ? ? ? ? ? ? ?spin_unlock_irqrestore(>lock, flags);

Using this patch, I log the attached output.

Thanks for your help so far. :)

Matt
-- next part --
A non-text attachment was scrubbed...
Name: screenlog.0.gz
Type: application/x-gzip
Size: 13412 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100624/3441960e/attachment-0001.bin>

Re: Problems with alpha/pci + radeon/ttm

[Matt Turner]

On Tue, Jun 22, 2010 at 1:59 AM, FUJITA Tomonori
fujita.tomon...@lab.ntt.co.jp wrote:
 On Mon, 21 Jun 2010 17:19:43 -0400
 Matt Turner matts...@gmail.com wrote:

 Michael Cree and I have been debugging FDO bug 26403 [1]. I tried
 booting with `radeon.test=1` and found this, which I think is related:

  [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset 0x202000
  [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset 0x302000
 [snip]
  [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset 0xfd02000
  [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset 0xfe02000
  pci_map_single failed: could not allocate dma page tables
  [drm:radeon_ttm_backend_bind] *ERROR* failed to bind 128 pages at 
  0x0FF02000
  [TTM] Couldn't bind backend.
  radeon :00:07.0: object_init failed for (1048576, 0x0002)
  [drm:radeon_test_moves] *ERROR* Failed to create GTT object 253
  Error while testing BO move.

 From what I can see, the call chain is
 radeon_test_moves
  (radeon_ttm_backend_bind called through callback function)
  - radeon_ttm.c:radeon_ttm_backend_bind calls radeon_gart_bind
   - radeon_gart.c:radeon_gart_bind calls pci_map_page
    - pci_map_page is alpha_pci_map_page, which calls...
     - alpha_pci_map_page calls pci_iommu.c:pci_map_single_1
      - pci_map_single_1 calls iommu_arena_alloc
       - iommu_arena_alloc calls iommu_arena_find_pages
        - iommu_arena_find_pages returns non-0
       - iommu_arena_alloc returns non-0
      - pci_map_single_1 returns 0 after printing
        could not allocate dma page tables error
     - alpha_pci_map_page returns 0 from pci_map_single_1
   - radeon_gart_bind returns non-0, error path prints
     *ERROR* failed to bind 128 pages at 0x0FF02000

 This happens in the latest git, right?

I'm using 2.6.35-rc2, but I could try rc3 if you think it would make a
difference.

 Is this a regression (what kernel version worked)?

The framebuffer console has always worked, but I've never known X on
KMS to work. The radeon.test parameter hasn't existed the entire time,
but I could try still previous kernels.

 Seems that the IOMMU can't find 128 pages. It's likely due to:

 - out of the IOMMU space (possibly someone doesn't free the IOMMU
  space).

 or

 - the mapping parameters (such as align) aren't appropriate so the
  IOMMU can't find space.


 Is this the cause of the bug we're seeing in the report [1]?

 Anyone know what's going wrong here?


 I've attached a patch to print the debug info about the mapping
 parameters.


 diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
 index d1dbd9a..17cf0d8 100644
 --- a/arch/alpha/kernel/pci_iommu.c
 +++ b/arch/alpha/kernel/pci_iommu.c
 @@ -187,6 +187,10 @@ iommu_arena_alloc(struct device *dev, struct 
 pci_iommu_arena *arena, long n,
        /* Search for N empty ptes */
        ptes = arena-ptes;
        mask = max(align, arena-align_entry) - 1;
 +
 +       printk(%s: %p, %p, %d, %ld, %lx, %u\n, __func__, dev, arena, 
 arena-size,
 +              n, mask, align);
 +
        p = iommu_arena_find_pages(dev, arena, n, mask);
        if (p  0) {
                spin_unlock_irqrestore(arena-lock, flags);

Using this patch, I log the attached output.

Thanks for your help so far. :)

Matt


screenlog.0.gz
Description: GNU Zip compressed data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Problems with alpha/pci + radeon/ttm

[Matt Turner]

On Thu, Jun 24, 2010 at 5:51 AM, Michael Cree mc...@orcon.net.nz wrote:
 On 22/06/10 20:32, Dave Airlie wrote:

 On Tue, Jun 22, 2010 at 3:59 PM, FUJITA Tomonori
 fujita.tomon...@lab.ntt.co.jp  wrote:

 On Mon, 21 Jun 2010 17:19:43 -0400
 Matt Turnermatts...@gmail.com  wrote:

 Michael Cree and I have been debugging FDO bug 26403 [1]. I tried
 booting with `radeon.test=1` and found this, which I think is related:

 Note that my radeon card is PCI whereas I think Matt may be using an AGP
 card.

Actually, I'm using a plain Radeon 9100 PCI.

 My logs are very similar to Matt's except I don't see the following line:

 pci_map_single failed: could not allocate dma page tables


 This happens in the latest git, right?

 Indeed, testing 2.6.35-rc3 (plus a couple or so extra patches to fix
 unrelated compile errors).

 Is this a regression (what kernel version worked)?

 Seems that the IOMMU can't find 128 pages. It's likely due to:

 - out of the IOMMU space (possibly someone doesn't free the IOMMU
  space).

 or

 - the mapping parameters (such as align) aren't appropriate so the
  IOMMU can't find space.

 I don't think KMS drivers have ever worked on alpha so its not a
 regression, they are working fine on x86 + powerpc and sparc has been
 run at least once.

 KMS on the console boot up has worked since about 2.6.32, but starting up
 the X server has always failed and, in my case, the system becomes unstable
 and eventually OOPs.

 I suspect we are simply hitting the limits of the iommu, how big an
 address space does it handle? since generally graphics drivers try to
 bind a lot of things to the GART.

 No idea on the address space limit.  I applied the patch of Fujita that logs
 all IOMMU allocations, and also inserted some extra printks in the ttm
 kernel code so that I could see which routines failed and the error code
 returned.  Running the radeon test on boot exhibits the following:

 [  238.712768] [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset
 0x1a312000
 [  239.281127] [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset
 0x1a412000
 [  239.281127] ttm_tt_bind belched -12
 [  239.282104] ttm_bo_handle_move_mem belched -12
 [  239.282104] ttm_bo_move_buffer belched -12
 [  239.282104] ttm_bo_validate belched -12
 [  239.282104] radeon :01:00.0: object_init failed for (1048576,
 0x0002) err=-12
 [  239.282104] [drm:radeon_test_moves] *ERROR* Failed to create GTT object
 419
 [  239.399291] Error while testing BO move.

 Note that no IOMMU allocations are printed while radeon_test_moves is
 running so iommu_arena_alloc doesn't appear to be called.  Also the error
 code returned up to radeon_test_moves is -12 which is ENOMEM.  So does
 appear to be some memory limit.

I confirm that we're getting -ENOMEM. I don't know if it's coming from
radeon_gart_bind(), but if it is there's an interesting comment
immediately after the call to pci_map_page:

if (pci_dma_mapping_error(rdev-pdev, rdev-gart.pages_addr[p])) {
/* FIXME: failed to map page (return -ENOMEM?) */
radeon_gart_unbind(rdev, offset, pages);
return -ENOMEM;
}

 It might be worth limiting the PCIGART in radeon to 32MB to see if the
 lower limit helps.

 So, how does one do that?

Boot with `radeon.test=1 radeon.gartsize=size in MB`.
 Cheers
 Michael.

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

Problems with alpha/pci + radeon/ttm

[Matt Turner]

Michael Cree and I have been debugging FDO bug 26403 [1]. I tried
booting with `radeon.test=1` and found this, which I think is related:

 [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset 0x202000
 [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset 0x302000
[snip]
 [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset 0xfd02000
 [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset 0xfe02000
 pci_map_single failed: could not allocate dma page tables
 [drm:radeon_ttm_backend_bind] *ERROR* failed to bind 128 pages at 0x0FF02000
 [TTM] Couldn't bind backend.
 radeon :00:07.0: object_init failed for (1048576, 0x0002)
 [drm:radeon_test_moves] *ERROR* Failed to create GTT object 253
 Error while testing BO move.

From what I can see, the call chain is
radeon_test_moves
 (radeon_ttm_backend_bind called through callback function)
 - radeon_ttm.c:radeon_ttm_backend_bind calls radeon_gart_bind
  - radeon_gart.c:radeon_gart_bind calls pci_map_page
   - pci_map_page is alpha_pci_map_page, which calls...
- alpha_pci_map_page calls pci_iommu.c:pci_map_single_1
 - pci_map_single_1 calls iommu_arena_alloc
  - iommu_arena_alloc calls iommu_arena_find_pages
   - iommu_arena_find_pages returns non-0
  - iommu_arena_alloc returns non-0
 - pci_map_single_1 returns 0 after printing
   could not allocate dma page tables error
- alpha_pci_map_page returns 0 from pci_map_single_1
  - radeon_gart_bind returns non-0, error path prints
*ERROR* failed to bind 128 pages at 0x0FF02000

Is this the cause of the bug we're seeing in the report [1]?

Anyone know what's going wrong here?

Thanks!
Matt Turner

[1] https://bugs.freedesktop.org/show_bug.cgi?id=26403
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Problems with alpha/pci + radeon/ttm

[Matt Turner]

Michael Cree and I have been debugging FDO bug 26403 [1]. I tried
booting with `radeon.test=1` and found this, which I think is related:

> [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x202000
> [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x302000
[snip]
> [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0xfd02000
> [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0xfe02000
> pci_map_single failed: could not allocate dma page tables
> [drm:radeon_ttm_backend_bind] *ERROR* failed to bind 128 pages at 0x0FF02000
> [TTM] Couldn't bind backend.
> radeon :00:07.0: object_init failed for (1048576, 0x0002)
> [drm:radeon_test_moves] *ERROR* Failed to create GTT object 253
> Error while testing BO move.

[PATCH] DRM / radeon / KMS: Fix hibernation regression related to radeon PM (was: Re: [Regression, post-2.6.34] Hibernation broken on machines with radeon/KMS and r300)

[Matt Turner]

On Thu, Jun 17, 2010 at 7:02 PM, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> There is a regression from 2.6.34 related to the recent radeon power
> management changes, caused by attempting to cancel a delayed work
> item that's never been scheduled. ?However, the code as is has some
> other issues potentially leading to visible problems.
>
> First, the mutex around cancel_delayed_work() in radeon_pm_suspend()
> doesn't really serve any purpose, because cancel_delayed_work() only
> tries to delete the work's timer. ?Moreover, it doesn't prevent the
> work handler from running, so the handler can do some wrong things if
> it wins the race and in that case it will rearm itself to do some
> more wrong things going forward. ?So, I think it's better to wait for
> the handler to return in case it's already been queued up for
> execution. ?Also, it should be prevented from rearming itself in that
> case.
>
> Second, in radeon_set_pm_method() the cancel_delayed_work() is not
> sufficient to prevent the work handler from running and queing up
> itself for the next run (the failure scenario is that
> cancel_delayed_work() returns 0, so the handler is run, it waits on
> the mutex and then rearms itself after the mutex has been released),
> so again the work handler should be prevented from rearming itself in
> that case..
>
> Finally, there's a potential deadlock in radeon_pm_fini(), because
> cancel_delayed_work_sync() is called under rdev->pm.mutex, but the
> work handler tries to acquire the same mutex (if it wins the race).
>
> Fix the issues described above.
>
> Signed-off-by: Rafael J. Wysocki 
> Reviewed-by: Alex Deucher 
> ---
> ?drivers/gpu/drm/radeon/radeon.h ? ?| ? ?3 +-
> ?drivers/gpu/drm/radeon/radeon_pm.c | ? 41 
> ++---
> ?2 files changed, 36 insertions(+), 8 deletions(-)
>
> Index: linux-2.6/drivers/gpu/drm/radeon/radeon_pm.c
> ===
> --- linux-2.6.orig/drivers/gpu/drm/radeon/radeon_pm.c
> +++ linux-2.6/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -397,13 +397,20 @@ static ssize_t radeon_set_pm_method(stru
> ? ? ? ? ? ? ? ?rdev->pm.dynpm_planned_action = DYNPM_ACTION_DEFAULT;
> ? ? ? ? ? ? ? ?mutex_unlock(>pm.mutex);
> ? ? ? ?} else if (strncmp("profile", buf, strlen("profile")) == 0) {
> + ? ? ? ? ? ? ? bool flush_wq = false;
> +
> ? ? ? ? ? ? ? ?mutex_lock(>pm.mutex);
> - ? ? ? ? ? ? ? rdev->pm.pm_method = PM_METHOD_PROFILE;
> + ? ? ? ? ? ? ? if (rdev->pm.pm_method == PM_METHOD_DYNPM) {
> + ? ? ? ? ? ? ? ? ? ? ? cancel_delayed_work(>pm.dynpm_idle_work);
> + ? ? ? ? ? ? ? ? ? ? ? flush_wq = true;
> + ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ?/* disable dynpm */
> ? ? ? ? ? ? ? ?rdev->pm.dynpm_state = DYNPM_STATE_DISABLED;
> ? ? ? ? ? ? ? ?rdev->pm.dynpm_planned_action = DYNPM_ACTION_NONE;
> - ? ? ? ? ? ? ? cancel_delayed_work(>pm.dynpm_idle_work);
> + ? ? ? ? ? ? ? rdev->pm.pm_method = PM_METHOD_PROFILE;
> ? ? ? ? ? ? ? ?mutex_unlock(>pm.mutex);
> + ? ? ? ? ? ? ? if (flush_wq)
> + ? ? ? ? ? ? ? ? ? ? ? flush_workqueue(rdev->wq);
> ? ? ? ?} else {
> ? ? ? ? ? ? ? ?DRM_ERROR("invalid power method!\n");
> ? ? ? ? ? ? ? ?goto fail;
> @@ -418,9 +425,18 @@ static DEVICE_ATTR(power_method, S_IRUGO
>
> ?void radeon_pm_suspend(struct radeon_device *rdev)
> ?{
> + ? ? ? bool flush_wq = false;
> +
> ? ? ? ?mutex_lock(>pm.mutex);
> - ? ? ? cancel_delayed_work(>pm.dynpm_idle_work);
> + ? ? ? if (rdev->pm.pm_method == PM_METHOD_DYNPM) {
> + ? ? ? ? ? ? ? cancel_delayed_work(>pm.dynpm_idle_work);
> + ? ? ? ? ? ? ? if (rdev->pm.dynpm_state == DYNPM_STATE_ACTIVE)
> + ? ? ? ? ? ? ? ? ? ? ? rdev->pm.dynpm_state = DYNPM_STATE_SUSPENDED;
> + ? ? ? ? ? ? ? flush_wq = true;
> + ? ? ? }
> ? ? ? ?mutex_unlock(>pm.mutex);
> + ? ? ? if (flush_wq)
> + ? ? ? ? ? ? ? flush_workqueue(rdev->wq);
> ?}
>
> ?void radeon_pm_resume(struct radeon_device *rdev)
> @@ -432,6 +448,12 @@ void radeon_pm_resume(struct radeon_devi
> ? ? ? ?rdev->pm.current_sclk = rdev->clock.default_sclk;
> ? ? ? ?rdev->pm.current_mclk = rdev->clock.default_mclk;
> ? ? ? ?rdev->pm.current_vddc = 
> rdev->pm.power_state[rdev->pm.default_power_state_index].clock_info[0].voltage.voltage;
> + ? ? ? if (rdev->pm.pm_method == PM_METHOD_DYNPM
> + ? ? ? ? ? && rdev->pm.dynpm_state == DYNPM_STATE_SUSPENDED) {
> + ? ? ? ? ? ? ? rdev->pm.dynpm_state = DYNPM_STATE_ACTIVE;
> + ? ? ? ? ? ? ? queue_delayed_work(rdev->wq, >pm.dynpm_idle_work,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> msecs_to_jiffies(RADEON_IDLE_LOOP_MS));
> + ? ? ? }
> ? ? ? ?mutex_unlock(>pm.mutex);
> ? ? ? ?radeon_pm_compute_clocks(rdev);
> ?}
> @@ -486,6 +508,8 @@ int radeon_pm_init(struct radeon_device
> ?void radeon_pm_fini(struct radeon_device *rdev)
> ?{
> ? ? ? ?if (rdev->pm.num_power_states > 1) {
> + ? ? ? ? ? ? ? bool flush_wq = false;
> +
> ? ? ? ? ? ? ? ?mutex_lock(>pm.mutex);
> ? ? ? ? ? ? ? ?if (rdev->pm.pm_method == PM_METHOD_PROFILE) {
> ? ? ? ? ? ? ? ? ? ? ? ?rdev->pm.profile = PM_PROFILE_DEFAULT;

[PATCH] drm/radeon/kms: fix regressions in CS checker due to r6xx tiling changes

[Matt Turner]

On Wed, Jun 2, 2010 at 3:16 PM, Alex Deucher  wrote:
> On Wed, Jun 2, 2010 at 2:32 PM, Matt Turner  wrote:
>> On Wed, Jun 2, 2010 at 1:53 PM, Alex Deucher  
>> wrote:
>>> Fixes:
>>> https://bugs.freedesktop.org/show_bug.cgi?id=28327
>>>
>>> Signed-off-by: Alex Deucher 
>>> ---
>>> ?drivers/gpu/drm/radeon/r600_cs.c | ? 43 
>>> ++---
>>> ?1 files changed, 16 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
>>> b/drivers/gpu/drm/radeon/r600_cs.c
>>> index 133f0da..99c8f40 100644
>>> --- a/drivers/gpu/drm/radeon/r600_cs.c
>>> +++ b/drivers/gpu/drm/radeon/r600_cs.c
>>> @@ -184,28 +184,16 @@ static inline int r600_cs_track_validate_cb(struct 
>>> radeon_cs_parser *p, int i)
>>> ? ? ? ?/* pitch is the number of 8x8 tiles per row */
>>> ? ? ? ?pitch = G_028060_PITCH_TILE_MAX(track->cb_color_size[i]) + 1;
>>> ? ? ? ?slice_tile_max = G_028060_SLICE_TILE_MAX(track->cb_color_size[i]) + 
>>> 1;
>>> - ? ? ? if (!pitch) {
>>> - ? ? ? ? ? ? ? dev_warn(p->dev, "%s:%d cb pitch (%d) for %d invalid 
>>> (0x%08X)\n",
>>> - ? ? ? ? ? ? ? ? ? ? ? __func__, __LINE__, pitch, i, 
>>> track->cb_color_size[i]);
>>> - ? ? ? ? ? ? ? return -EINVAL;
>>> - ? ? ? }
>>> ? ? ? ?height = size / (pitch * 8 * bpe);
>>> ? ? ? ?if (height > 8192)
>>> ? ? ? ? ? ? ? ?height = 8192;
>>> - ? ? ? height &= ~0x7;
>>> - ? ? ? if (!height)
>>> - ? ? ? ? ? ? ? height = 8;
>>> ? ? ? ?switch (G_0280A0_ARRAY_MODE(track->cb_color_info[i])) {
>>> ? ? ? ?case V_0280A0_ARRAY_LINEAR_GENERAL:
>>> - ? ? ? ? ? ? ? if (height & 0x7) {
>>> - ? ? ? ? ? ? ? ? ? ? ? dev_warn(p->dev, "%s:%d cb height (%d) invalid\n",
>>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?__func__, __LINE__, height);
>>> - ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
>>> - ? ? ? ? ? ? ? }
>>> + ? ? ? ? ? ? ? /* technically height & 0x7 */
>>> ? ? ? ? ? ? ? ?break;
>>> ? ? ? ?case V_0280A0_ARRAY_LINEAR_ALIGNED:
>>> - ? ? ? ? ? ? ? pitch_align = (max((u32)64, (u32)(track->group_size / bpe)) 
>>> / 8) - 1;
>>> - ? ? ? ? ? ? ? if (pitch & pitch_align) {
>>> + ? ? ? ? ? ? ? pitch_align = max((u32)64, (u32)(track->group_size / bpe)) 
>>> / 8;
>>> + ? ? ? ? ? ? ? if (pitch & (pitch_align - 1)) {
>>
>> Maybe we should use the kernel's ALIGN macro here? ALIGN(pitch,
>> pitch_align). I don't know, it might just make it unclear.
>
> We don't want to align the pitch, we want to check if it is aligned.

Ah, I meant IS_ALIGNED, in linux/kernel.h:

#define IS_ALIGNED(x, a)(((x) & ((typeof(x))(a) - 1)) == 0)

Should definitely be using it here, instead.

Matt

> Alex
>
>>
>>> ? ? ? ? ? ? ? ? ? ? ? ?dev_warn(p->dev, "%s:%d cb pitch (%d) invalid\n",
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? __func__, __LINE__, pitch);
>>> ? ? ? ? ? ? ? ? ? ? ? ?return -EINVAL;
>>> @@ -217,8 +205,8 @@ static inline int r600_cs_track_validate_cb(struct 
>>> radeon_cs_parser *p, int i)
>>> ? ? ? ? ? ? ? ?}
>>> ? ? ? ? ? ? ? ?break;
>>> ? ? ? ?case V_0280A0_ARRAY_1D_TILED_THIN1:
>>> - ? ? ? ? ? ? ? pitch_align = (max((u32)8, (u32)(track->group_size / (8 * 
>>> bpe * track->nsamples))) / 8) - 1;
>>> - ? ? ? ? ? ? ? if (pitch & pitch_align) {
>>> + ? ? ? ? ? ? ? pitch_align = max((u32)8, (u32)(track->group_size / (8 * 
>>> bpe * track->nsamples))) / 8;
>>> + ? ? ? ? ? ? ? if (pitch & (pitch_align - 1)) {
>>> ? ? ? ? ? ? ? ? ? ? ? ?dev_warn(p->dev, "%s:%d cb pitch (%d) invalid\n",
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? __func__, __LINE__, pitch);
>>> ? ? ? ? ? ? ? ? ? ? ? ?return -EINVAL;
>>> @@ -231,8 +219,8 @@ static inline int r600_cs_track_validate_cb(struct 
>>> radeon_cs_parser *p, int i)
>>> ? ? ? ? ? ? ? ?break;
>>> ? ? ? ?case V_0280A0_ARRAY_2D_TILED_THIN1:
>>> ? ? ? ? ? ? ? ?pitch_align = max((u32)track->nbanks,
>>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (u32)(((track->group_size / 8) / (bpe * 
>>> track->nsamples)) * track->nbanks)) - 1;
>>> - ? ? ? ? ? ? ? if (pitch & pitch_align) {
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (u32)(((track->group_size / 8) / (bpe * 
>>> track->nsamples)) * track->nbanks));
>>> + ? ? ? ? ? ? ? if (pitch & (pitch_align - 1)) {
>>> ? ? ? ? ? ? ? ? ? ? ? ?dev_warn(p->dev

[PATCH] drm/radeon/kms: fix regressions in CS checker due to r6xx tiling changes

[Matt Turner]

On Wed, Jun 2, 2010 at 1:53 PM, Alex Deucher  wrote:
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=28327
>
> Signed-off-by: Alex Deucher 
> ---
> ?drivers/gpu/drm/radeon/r600_cs.c | ? 43 ++---
> ?1 files changed, 16 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
> b/drivers/gpu/drm/radeon/r600_cs.c
> index 133f0da..99c8f40 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -184,28 +184,16 @@ static inline int r600_cs_track_validate_cb(struct 
> radeon_cs_parser *p, int i)
> ? ? ? ?/* pitch is the number of 8x8 tiles per row */
> ? ? ? ?pitch = G_028060_PITCH_TILE_MAX(track->cb_color_size[i]) + 1;
> ? ? ? ?slice_tile_max = G_028060_SLICE_TILE_MAX(track->cb_color_size[i]) + 1;
> - ? ? ? if (!pitch) {
> - ? ? ? ? ? ? ? dev_warn(p->dev, "%s:%d cb pitch (%d) for %d invalid 
> (0x%08X)\n",
> - ? ? ? ? ? ? ? ? ? ? ? __func__, __LINE__, pitch, i, 
> track->cb_color_size[i]);
> - ? ? ? ? ? ? ? return -EINVAL;
> - ? ? ? }
> ? ? ? ?height = size / (pitch * 8 * bpe);
> ? ? ? ?if (height > 8192)
> ? ? ? ? ? ? ? ?height = 8192;
> - ? ? ? height &= ~0x7;
> - ? ? ? if (!height)
> - ? ? ? ? ? ? ? height = 8;
> ? ? ? ?switch (G_0280A0_ARRAY_MODE(track->cb_color_info[i])) {
> ? ? ? ?case V_0280A0_ARRAY_LINEAR_GENERAL:
> - ? ? ? ? ? ? ? if (height & 0x7) {
> - ? ? ? ? ? ? ? ? ? ? ? dev_warn(p->dev, "%s:%d cb height (%d) invalid\n",
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?__func__, __LINE__, height);
> - ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
> - ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? /* technically height & 0x7 */
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case V_0280A0_ARRAY_LINEAR_ALIGNED:
> - ? ? ? ? ? ? ? pitch_align = (max((u32)64, (u32)(track->group_size / bpe)) / 
> 8) - 1;
> - ? ? ? ? ? ? ? if (pitch & pitch_align) {
> + ? ? ? ? ? ? ? pitch_align = max((u32)64, (u32)(track->group_size / bpe)) / 
> 8;
> + ? ? ? ? ? ? ? if (pitch & (pitch_align - 1)) {

Maybe we should use the kernel's ALIGN macro here? ALIGN(pitch,
pitch_align). I don't know, it might just make it unclear.

> ? ? ? ? ? ? ? ? ? ? ? ?dev_warn(p->dev, "%s:%d cb pitch (%d) invalid\n",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? __func__, __LINE__, pitch);
> ? ? ? ? ? ? ? ? ? ? ? ?return -EINVAL;
> @@ -217,8 +205,8 @@ static inline int r600_cs_track_validate_cb(struct 
> radeon_cs_parser *p, int i)
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case V_0280A0_ARRAY_1D_TILED_THIN1:
> - ? ? ? ? ? ? ? pitch_align = (max((u32)8, (u32)(track->group_size / (8 * bpe 
> * track->nsamples))) / 8) - 1;
> - ? ? ? ? ? ? ? if (pitch & pitch_align) {
> + ? ? ? ? ? ? ? pitch_align = max((u32)8, (u32)(track->group_size / (8 * bpe 
> * track->nsamples))) / 8;
> + ? ? ? ? ? ? ? if (pitch & (pitch_align - 1)) {
> ? ? ? ? ? ? ? ? ? ? ? ?dev_warn(p->dev, "%s:%d cb pitch (%d) invalid\n",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? __func__, __LINE__, pitch);
> ? ? ? ? ? ? ? ? ? ? ? ?return -EINVAL;
> @@ -231,8 +219,8 @@ static inline int r600_cs_track_validate_cb(struct 
> radeon_cs_parser *p, int i)
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case V_0280A0_ARRAY_2D_TILED_THIN1:
> ? ? ? ? ? ? ? ?pitch_align = max((u32)track->nbanks,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (u32)(((track->group_size / 8) / (bpe * 
> track->nsamples)) * track->nbanks)) - 1;
> - ? ? ? ? ? ? ? if (pitch & pitch_align) {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (u32)(((track->group_size / 8) / (bpe * 
> track->nsamples)) * track->nbanks));
> + ? ? ? ? ? ? ? if (pitch & (pitch_align - 1)) {
> ? ? ? ? ? ? ? ? ? ? ? ?dev_warn(p->dev, "%s:%d cb pitch (%d) invalid\n",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?__func__, __LINE__, pitch);
> ? ? ? ? ? ? ? ? ? ? ? ?return -EINVAL;
> @@ -250,9 +238,9 @@ static inline int r600_cs_track_validate_cb(struct 
> radeon_cs_parser *p, int i)
> ? ? ? ? ? ? ? ?return -EINVAL;
> ? ? ? ?}
> ? ? ? ?/* check offset */
> - ? ? ? tmp = height * pitch * 8;
> + ? ? ? tmp = height * pitch * 8 * bpe;
> ? ? ? ?if ((tmp + track->cb_color_bo_offset[i]) > 
> radeon_bo_size(track->cb_color_bo[i])) {
> - ? ? ? ? ? ? ? dev_warn(p->dev, "%s offset[%d] %d to big\n", __func__, i, 
> track->cb_color_bo_offset[i]);
> + ? ? ? ? ? ? ? dev_warn(p->dev, "%s offset[%d] %d too big\n", __func__, i, 
> track->cb_color_bo_offset[i]);
> ? ? ? ? ? ? ? ?return -EINVAL;
> ? ? ? ?}
> ? ? ? ?if (track->cb_color_bo_offset[i] & (track->group_size - 1)) {
> @@ -1130,11 +1118,12 @@ static inline int r600_check_texture_resource(struct 
> radeon_cs_parser *p, ?u32 i
> ? ? ? ?pitch = G_038000_PITCH(word0) + 1;
> ? ? ? ?switch (G_038000_TILE_MODE(word0)) {
> ? ? ? ?case V_038000_ARRAY_LINEAR_GENERAL:
> + ? ? ? ? ? ? ? pitch_align = 1;
> ? ? ? ? ? ? ? ?/* XXX check height align */
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case V_038000_ARRAY_LINEAR_ALIGNED:
> - ? ? ? ? ? ? ? pitch_align = (max((u32)64, (u32)(track->group_size / bpe)) / 
> 8) - 1;
> - ? ? ? ? ? ? ? if (pitch & pitch_align) {
> + ? ? ? ? ? ? ? pitch_align = max((u32)64, (u32)(track->group_size / bpe)) / 
> 

Re: [PATCH] drm/radeon/kms: fix regressions in CS checker due to r6xx tiling changes

[Matt Turner]

On Wed, Jun 2, 2010 at 1:53 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 Fixes:
 https://bugs.freedesktop.org/show_bug.cgi?id=28327

 Signed-off-by: Alex Deucher alexdeuc...@gmail.com
 ---
  drivers/gpu/drm/radeon/r600_cs.c |   43 ++---
  1 files changed, 16 insertions(+), 27 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
 b/drivers/gpu/drm/radeon/r600_cs.c
 index 133f0da..99c8f40 100644
 --- a/drivers/gpu/drm/radeon/r600_cs.c
 +++ b/drivers/gpu/drm/radeon/r600_cs.c
 @@ -184,28 +184,16 @@ static inline int r600_cs_track_validate_cb(struct 
 radeon_cs_parser *p, int i)
        /* pitch is the number of 8x8 tiles per row */
        pitch = G_028060_PITCH_TILE_MAX(track-cb_color_size[i]) + 1;
        slice_tile_max = G_028060_SLICE_TILE_MAX(track-cb_color_size[i]) + 1;
 -       if (!pitch) {
 -               dev_warn(p-dev, %s:%d cb pitch (%d) for %d invalid 
 (0x%08X)\n,
 -                       __func__, __LINE__, pitch, i, 
 track-cb_color_size[i]);
 -               return -EINVAL;
 -       }
        height = size / (pitch * 8 * bpe);
        if (height  8192)
                height = 8192;
 -       height = ~0x7;
 -       if (!height)
 -               height = 8;
        switch (G_0280A0_ARRAY_MODE(track-cb_color_info[i])) {
        case V_0280A0_ARRAY_LINEAR_GENERAL:
 -               if (height  0x7) {
 -                       dev_warn(p-dev, %s:%d cb height (%d) invalid\n,
 -                                __func__, __LINE__, height);
 -                       return -EINVAL;
 -               }
 +               /* technically height  0x7 */
                break;
        case V_0280A0_ARRAY_LINEAR_ALIGNED:
 -               pitch_align = (max((u32)64, (u32)(track-group_size / bpe)) / 
 8) - 1;
 -               if (pitch  pitch_align) {
 +               pitch_align = max((u32)64, (u32)(track-group_size / bpe)) / 
 8;
 +               if (pitch  (pitch_align - 1)) {

Maybe we should use the kernel's ALIGN macro here? ALIGN(pitch,
pitch_align). I don't know, it might just make it unclear.

                        dev_warn(p-dev, %s:%d cb pitch (%d) invalid\n,
                                 __func__, __LINE__, pitch);
                        return -EINVAL;
 @@ -217,8 +205,8 @@ static inline int r600_cs_track_validate_cb(struct 
 radeon_cs_parser *p, int i)
                }
                break;
        case V_0280A0_ARRAY_1D_TILED_THIN1:
 -               pitch_align = (max((u32)8, (u32)(track-group_size / (8 * bpe 
 * track-nsamples))) / 8) - 1;
 -               if (pitch  pitch_align) {
 +               pitch_align = max((u32)8, (u32)(track-group_size / (8 * bpe 
 * track-nsamples))) / 8;
 +               if (pitch  (pitch_align - 1)) {
                        dev_warn(p-dev, %s:%d cb pitch (%d) invalid\n,
                                 __func__, __LINE__, pitch);
                        return -EINVAL;
 @@ -231,8 +219,8 @@ static inline int r600_cs_track_validate_cb(struct 
 radeon_cs_parser *p, int i)
                break;
        case V_0280A0_ARRAY_2D_TILED_THIN1:
                pitch_align = max((u32)track-nbanks,
 -                                 (u32)(((track-group_size / 8) / (bpe * 
 track-nsamples)) * track-nbanks)) - 1;
 -               if (pitch  pitch_align) {
 +                                 (u32)(((track-group_size / 8) / (bpe * 
 track-nsamples)) * track-nbanks));
 +               if (pitch  (pitch_align - 1)) {
                        dev_warn(p-dev, %s:%d cb pitch (%d) invalid\n,
                                __func__, __LINE__, pitch);
                        return -EINVAL;
 @@ -250,9 +238,9 @@ static inline int r600_cs_track_validate_cb(struct 
 radeon_cs_parser *p, int i)
                return -EINVAL;
        }
        /* check offset */
 -       tmp = height * pitch * 8;
 +       tmp = height * pitch * 8 * bpe;
        if ((tmp + track-cb_color_bo_offset[i])  
 radeon_bo_size(track-cb_color_bo[i])) {
 -               dev_warn(p-dev, %s offset[%d] %d to big\n, __func__, i, 
 track-cb_color_bo_offset[i]);
 +               dev_warn(p-dev, %s offset[%d] %d too big\n, __func__, i, 
 track-cb_color_bo_offset[i]);
                return -EINVAL;
        }
        if (track-cb_color_bo_offset[i]  (track-group_size - 1)) {
 @@ -1130,11 +1118,12 @@ static inline int r600_check_texture_resource(struct 
 radeon_cs_parser *p,  u32 i
        pitch = G_038000_PITCH(word0) + 1;
        switch (G_038000_TILE_MODE(word0)) {
        case V_038000_ARRAY_LINEAR_GENERAL:
 +               pitch_align = 1;
                /* XXX check height align */
                break;
        case V_038000_ARRAY_LINEAR_ALIGNED:
 -               pitch_align = (max((u32)64, (u32)(track-group_size / bpe)) / 
 8) - 1;
 -               if (pitch  pitch_align) {
 +               pitch_align = max((u32)64, (u32)(track-group_size / bpe)) / 
 8;
 +               if (pitch  (pitch_align - 1)) {
                        dev_warn(p-dev, %s:%d tex pitch (%d) invalid\n,
 

Re: [PATCH] drm/radeon/kms: fix regressions in CS checker due to r6xx tiling changes

[Matt Turner]

On Wed, Jun 2, 2010 at 3:16 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Wed, Jun 2, 2010 at 2:32 PM, Matt Turner matts...@gmail.com wrote:
 On Wed, Jun 2, 2010 at 1:53 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 Fixes:
 https://bugs.freedesktop.org/show_bug.cgi?id=28327

 Signed-off-by: Alex Deucher alexdeuc...@gmail.com
 ---
  drivers/gpu/drm/radeon/r600_cs.c |   43 
 ++---
  1 files changed, 16 insertions(+), 27 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
 b/drivers/gpu/drm/radeon/r600_cs.c
 index 133f0da..99c8f40 100644
 --- a/drivers/gpu/drm/radeon/r600_cs.c
 +++ b/drivers/gpu/drm/radeon/r600_cs.c
 @@ -184,28 +184,16 @@ static inline int r600_cs_track_validate_cb(struct 
 radeon_cs_parser *p, int i)
        /* pitch is the number of 8x8 tiles per row */
        pitch = G_028060_PITCH_TILE_MAX(track-cb_color_size[i]) + 1;
        slice_tile_max = G_028060_SLICE_TILE_MAX(track-cb_color_size[i]) + 
 1;
 -       if (!pitch) {
 -               dev_warn(p-dev, %s:%d cb pitch (%d) for %d invalid 
 (0x%08X)\n,
 -                       __func__, __LINE__, pitch, i, 
 track-cb_color_size[i]);
 -               return -EINVAL;
 -       }
        height = size / (pitch * 8 * bpe);
        if (height  8192)
                height = 8192;
 -       height = ~0x7;
 -       if (!height)
 -               height = 8;
        switch (G_0280A0_ARRAY_MODE(track-cb_color_info[i])) {
        case V_0280A0_ARRAY_LINEAR_GENERAL:
 -               if (height  0x7) {
 -                       dev_warn(p-dev, %s:%d cb height (%d) invalid\n,
 -                                __func__, __LINE__, height);
 -                       return -EINVAL;
 -               }
 +               /* technically height  0x7 */
                break;
        case V_0280A0_ARRAY_LINEAR_ALIGNED:
 -               pitch_align = (max((u32)64, (u32)(track-group_size / bpe)) 
 / 8) - 1;
 -               if (pitch  pitch_align) {
 +               pitch_align = max((u32)64, (u32)(track-group_size / bpe)) 
 / 8;
 +               if (pitch  (pitch_align - 1)) {

 Maybe we should use the kernel's ALIGN macro here? ALIGN(pitch,
 pitch_align). I don't know, it might just make it unclear.

 We don't want to align the pitch, we want to check if it is aligned.

Ah, I meant IS_ALIGNED, in linux/kernel.h:

#define IS_ALIGNED(x, a)(((x)  ((typeof(x))(a) - 1)) == 0)

Should definitely be using it here, instead.

Matt

 Alex


                        dev_warn(p-dev, %s:%d cb pitch (%d) invalid\n,
                                 __func__, __LINE__, pitch);
                        return -EINVAL;
 @@ -217,8 +205,8 @@ static inline int r600_cs_track_validate_cb(struct 
 radeon_cs_parser *p, int i)
                }
                break;
        case V_0280A0_ARRAY_1D_TILED_THIN1:
 -               pitch_align = (max((u32)8, (u32)(track-group_size / (8 * 
 bpe * track-nsamples))) / 8) - 1;
 -               if (pitch  pitch_align) {
 +               pitch_align = max((u32)8, (u32)(track-group_size / (8 * 
 bpe * track-nsamples))) / 8;
 +               if (pitch  (pitch_align - 1)) {
                        dev_warn(p-dev, %s:%d cb pitch (%d) invalid\n,
                                 __func__, __LINE__, pitch);
                        return -EINVAL;
 @@ -231,8 +219,8 @@ static inline int r600_cs_track_validate_cb(struct 
 radeon_cs_parser *p, int i)
                break;
        case V_0280A0_ARRAY_2D_TILED_THIN1:
                pitch_align = max((u32)track-nbanks,
 -                                 (u32)(((track-group_size / 8) / (bpe * 
 track-nsamples)) * track-nbanks)) - 1;
 -               if (pitch  pitch_align) {
 +                                 (u32)(((track-group_size / 8) / (bpe * 
 track-nsamples)) * track-nbanks));
 +               if (pitch  (pitch_align - 1)) {
                        dev_warn(p-dev, %s:%d cb pitch (%d) invalid\n,
                                __func__, __LINE__, pitch);
                        return -EINVAL;
 @@ -250,9 +238,9 @@ static inline int r600_cs_track_validate_cb(struct 
 radeon_cs_parser *p, int i)
                return -EINVAL;
        }
        /* check offset */
 -       tmp = height * pitch * 8;
 +       tmp = height * pitch * 8 * bpe;
        if ((tmp + track-cb_color_bo_offset[i])  
 radeon_bo_size(track-cb_color_bo[i])) {
 -               dev_warn(p-dev, %s offset[%d] %d to big\n, __func__, i, 
 track-cb_color_bo_offset[i]);
 +               dev_warn(p-dev, %s offset[%d] %d too big\n, __func__, i, 
 track-cb_color_bo_offset[i]);
                return -EINVAL;
        }
        if (track-cb_color_bo_offset[i]  (track-group_size - 1)) {
 @@ -1130,11 +1118,12 @@ static inline int 
 r600_check_texture_resource(struct radeon_cs_parser *p,  u32 i
        pitch = G_038000_PITCH(word0) + 1;
        switch (G_038000_TILE_MODE(word0)) {
        case V_038000_ARRAY_LINEAR_GENERAL:
 +               pitch_align = 1;
                /* XXX check height align

[PATCH 1/3] r600: add span support for 2D tiling

[Matt Turner]

On Thu, May 27, 2010 at 7:52 PM, Alan Cox  wrote:
>> Look up tables have some hidden penalties but I think it might be a
>> win. Looks like we may have to benchmark the solutions against one
>> another to really know which is best in real life.
>
> For x86 and ppc the single assembler instruction is fastest. Can you wire
> an R600 to anything else ?

2400HD and 4350HD are available as PCI, so I could get one in an
Alpha, but I haven't yet.

(Alpha has count-{leading,trailing} zero instructions too)

Matt

[PATCH 1/4] drm: Remove drm_resource wrappers

[Matt Turner]

Seems like a good simplification.

Reviewed-by: Matt Turner 

[PATCH 1/3] r600: add span support for 2D tiling

[Matt Turner]

> +static inline GLint r600_log2(GLint n)
> +{
> + ? ? ? GLint log2 = 0;
> +
> + ? ? ? while (n >>= 1)
> + ? ? ? ? ? ? ? ++log2;
> + ? ? ? return log2;
> +}

Does mesa not provide something like this?

Matt

[PATCH 2/20] drivers/gpu/drm: Use kzalloc

[Matt Turner]

On Thu, May 13, 2010 at 3:58 PM, Julia Lawall  wrote:
> From: Julia Lawall 
>
> Use kzalloc rather than the combination of kmalloc and memset.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // 
> @@
> expression x,size,flags;
> statement S;
> @@
>
> -x = kmalloc(size,flags);
> +x = kzalloc(size,flags);
> ?if (x == NULL) S
> -memset(x, 0, size);
> // 
>
> Signed-off-by: Julia Lawall 
>
> ---
> ?drivers/gpu/drm/drm_auth.c ? ? ? ? ?| ? ?3 +--
> ?drivers/gpu/drm/drm_dma.c ? ? ? ? ? | ? ?4 +---
> ?drivers/gpu/drm/drm_fops.c ? ? ? ? ?| ? ?3 +--
> ?drivers/gpu/drm/savage/savage_bci.c | ? ?3 +--
> ?4 files changed, 4 insertions(+), 9 deletions(-)
>
> diff -u -p a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -79,10 +79,9 @@ static int drm_add_magic(struct drm_mast
> ? ? ? ?struct drm_device *dev = master->minor->dev;
> ? ? ? ?DRM_DEBUG("%d\n", magic);
>
> - ? ? ? entry = kmalloc(sizeof(*entry), GFP_KERNEL);
> + ? ? ? entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> ? ? ? ?if (!entry)
> ? ? ? ? ? ? ? ?return -ENOMEM;
> - ? ? ? memset(entry, 0, sizeof(*entry));
> ? ? ? ?entry->priv = priv;
> ? ? ? ?entry->hash_item.key = (unsigned long)magic;
> ? ? ? ?mutex_lock(>struct_mutex);
> diff -u -p a/drivers/gpu/drm/drm_dma.c b/drivers/gpu/drm/drm_dma.c
> --- a/drivers/gpu/drm/drm_dma.c
> +++ b/drivers/gpu/drm/drm_dma.c
> @@ -47,12 +47,10 @@ int drm_dma_setup(struct drm_device *dev
> ?{
> ? ? ? ?int i;
>
> - ? ? ? dev->dma = kmalloc(sizeof(*dev->dma), GFP_KERNEL);
> + ? ? ? dev->dma = kzalloc(sizeof(*dev->dma), GFP_KERNEL);
> ? ? ? ?if (!dev->dma)
> ? ? ? ? ? ? ? ?return -ENOMEM;
>
> - ? ? ? memset(dev->dma, 0, sizeof(*dev->dma));
> -
> ? ? ? ?for (i = 0; i <= DRM_MAX_ORDER; i++)
> ? ? ? ? ? ? ? ?memset(>dma->bufs[i], 0, sizeof(dev->dma->bufs[0]));
>
> diff -u -p a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -243,11 +243,10 @@ static int drm_open_helper(struct inode
>
> ? ? ? ?DRM_DEBUG("pid = %d, minor = %d\n", task_pid_nr(current), minor_id);
>
> - ? ? ? priv = kmalloc(sizeof(*priv), GFP_KERNEL);
> + ? ? ? priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> ? ? ? ?if (!priv)
> ? ? ? ? ? ? ? ?return -ENOMEM;
>
> - ? ? ? memset(priv, 0, sizeof(*priv));
> ? ? ? ?filp->private_data = priv;
> ? ? ? ?priv->filp = filp;
> ? ? ? ?priv->uid = current_euid();
> diff -u -p a/drivers/gpu/drm/savage/savage_bci.c 
> b/drivers/gpu/drm/savage/savage_bci.c
> --- a/drivers/gpu/drm/savage/savage_bci.c
> +++ b/drivers/gpu/drm/savage/savage_bci.c
> @@ -539,11 +539,10 @@ int savage_driver_load(struct drm_device
> ?{
> ? ? ? ?drm_savage_private_t *dev_priv;
>
> - ? ? ? dev_priv = kmalloc(sizeof(drm_savage_private_t), GFP_KERNEL);
> + ? ? ? dev_priv = kzalloc(sizeof(drm_savage_private_t), GFP_KERNEL);
> ? ? ? ?if (dev_priv == NULL)
> ? ? ? ? ? ? ? ?return -ENOMEM;
>
> - ? ? ? memset(dev_priv, 0, sizeof(drm_savage_private_t));
> ? ? ? ?dev->dev_private = (void *)dev_priv;
>
> ? ? ? ?dev_priv->chipset = (enum savage_family)chipset;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Reviewed-by: Matt Turner 

Re: [PATCH 2/20] drivers/gpu/drm: Use kzalloc

[Matt Turner]

On Thu, May 13, 2010 at 3:58 PM, Julia Lawall ju...@diku.dk wrote:
 From: Julia Lawall ju...@diku.dk

 Use kzalloc rather than the combination of kmalloc and memset.

 The semantic patch that makes this change is as follows:
 (http://coccinelle.lip6.fr/)

 // smpl
 @@
 expression x,size,flags;
 statement S;
 @@

 -x = kmalloc(size,flags);
 +x = kzalloc(size,flags);
  if (x == NULL) S
 -memset(x, 0, size);
 // /smpl

 Signed-off-by: Julia Lawall ju...@diku.dk

 ---
  drivers/gpu/drm/drm_auth.c          |    3 +--
  drivers/gpu/drm/drm_dma.c           |    4 +---
  drivers/gpu/drm/drm_fops.c          |    3 +--
  drivers/gpu/drm/savage/savage_bci.c |    3 +--
  4 files changed, 4 insertions(+), 9 deletions(-)

 diff -u -p a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
 --- a/drivers/gpu/drm/drm_auth.c
 +++ b/drivers/gpu/drm/drm_auth.c
 @@ -79,10 +79,9 @@ static int drm_add_magic(struct drm_mast
        struct drm_device *dev = master-minor-dev;
        DRM_DEBUG(%d\n, magic);

 -       entry = kmalloc(sizeof(*entry), GFP_KERNEL);
 +       entry = kzalloc(sizeof(*entry), GFP_KERNEL);
        if (!entry)
                return -ENOMEM;
 -       memset(entry, 0, sizeof(*entry));
        entry-priv = priv;
        entry-hash_item.key = (unsigned long)magic;
        mutex_lock(dev-struct_mutex);
 diff -u -p a/drivers/gpu/drm/drm_dma.c b/drivers/gpu/drm/drm_dma.c
 --- a/drivers/gpu/drm/drm_dma.c
 +++ b/drivers/gpu/drm/drm_dma.c
 @@ -47,12 +47,10 @@ int drm_dma_setup(struct drm_device *dev
  {
        int i;

 -       dev-dma = kmalloc(sizeof(*dev-dma), GFP_KERNEL);
 +       dev-dma = kzalloc(sizeof(*dev-dma), GFP_KERNEL);
        if (!dev-dma)
                return -ENOMEM;

 -       memset(dev-dma, 0, sizeof(*dev-dma));
 -
        for (i = 0; i = DRM_MAX_ORDER; i++)
                memset(dev-dma-bufs[i], 0, sizeof(dev-dma-bufs[0]));

 diff -u -p a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -243,11 +243,10 @@ static int drm_open_helper(struct inode

        DRM_DEBUG(pid = %d, minor = %d\n, task_pid_nr(current), minor_id);

 -       priv = kmalloc(sizeof(*priv), GFP_KERNEL);
 +       priv = kzalloc(sizeof(*priv), GFP_KERNEL);
        if (!priv)
                return -ENOMEM;

 -       memset(priv, 0, sizeof(*priv));
        filp-private_data = priv;
        priv-filp = filp;
        priv-uid = current_euid();
 diff -u -p a/drivers/gpu/drm/savage/savage_bci.c 
 b/drivers/gpu/drm/savage/savage_bci.c
 --- a/drivers/gpu/drm/savage/savage_bci.c
 +++ b/drivers/gpu/drm/savage/savage_bci.c
 @@ -539,11 +539,10 @@ int savage_driver_load(struct drm_device
  {
        drm_savage_private_t *dev_priv;

 -       dev_priv = kmalloc(sizeof(drm_savage_private_t), GFP_KERNEL);
 +       dev_priv = kzalloc(sizeof(drm_savage_private_t), GFP_KERNEL);
        if (dev_priv == NULL)
                return -ENOMEM;

 -       memset(dev_priv, 0, sizeof(drm_savage_private_t));
        dev-dev_private = (void *)dev_priv;

        dev_priv-chipset = (enum savage_family)chipset;
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


Reviewed-by: Matt Turner matts...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: Fix sparc regression in r300_scratch()

[Matt Turner]

On Mon, Apr 26, 2010 at 5:55 AM, David Miller da...@davemloft.net wrote:

 Commit b4fe945405e477cded91772b4fec854705443dd5 (drm/radeon: Fix
 memory allocation failures in the preKMS command stream checking.)
 added a regression in that it completely tossed the get_unaligned()
 done by r300_scratch() which we added in commit
 958a6f8ccb1964adc3eec84cf401c5baeb4fbca0 (drm: radeon: Fix unaligned
 access in r300_scratch().).

 Put it back.

 Signed-off-by: David S. Miller da...@davemloft.net

 diff --git a/drivers/gpu/drm/radeon/r300_cmdbuf.c 
 b/drivers/gpu/drm/radeon/r300_cmdbuf.c
 index ea46d55..c5c2742 100644
 --- a/drivers/gpu/drm/radeon/r300_cmdbuf.c
 +++ b/drivers/gpu/drm/radeon/r300_cmdbuf.c
 @@ -921,7 +921,7 @@ static int r300_scratch(drm_radeon_private_t *dev_priv,

        ptr_addr = drm_buffer_read_object(cmdbuf-buffer,
                        sizeof(stack_ptr_addr), stack_ptr_addr);
 -       ref_age_base = (u32 *)(unsigned long)*ptr_addr;
 +       ref_age_base = (u32 *)(unsigned long)get_unaligned(ptr_addr);

        for (i=0; i  header.scratch.n_bufs; i++) {
                buf_idx = drm_buffer_pointer_to_dword(cmdbuf-buffer, 0);
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


Should help Alpha as well.

Acked-by: Matt Turner matts...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] agp: use scratch page on memory remove and at GATT creation V4

[Matt Turner]

On Thu, Apr 22, 2010 at 6:30 AM, Jerome Glisse  wrote:
> On Thu, Apr 22, 2010 at 11:27:11AM +0200, Daniel Vetter wrote:
>> On Tue, Apr 20, 2010 at 05:43:34PM +0200, Jerome Glisse wrote:
>> > Convert most AGP chipset to use scratch page as default entries.
>> > This help avoiding GPU querying 0 address and trigger computer
>> > fault. With KMS and memory manager we bind/unbind AGP memory
>> > constantly and it seems that some GPU are still doing AGP
>> > traffic even after GPU report being idle with the memory segment.
>> >
>> > Tested (radeon GPU KMS + Xorg + compiz + glxgears + quake3) on :
>> > - SIS 1039:0001 & 1039:0003
>> > - Intel 865 8086:2571
>> >
>> > Compile tested for other bridges
>> >
>> > V2 enable scratch page on uninorth
>> > V3 fix unbound check in uninorth insert memory (Michel D?nzer)
>> > V4 rebase on top of drm-next branch with the lastest intel AGP
>> > ? ?changeset (stable should use version V3 of the patch)
>>
>> Nope, v3 still contains the bogus changes to the intel gtt driver (only
>> used by intel igds). In this patch, the intel parts look good.
>>
>> While looking add this I've found some more stuff to nit-pick over ;)
>> Instead of splattering needs_scratch_page = true all over the agp drivers,
>> why not do the changes in the agp core (and the few fixups required in the
>> drivers) and simply kill this variable? If using a scratch page is
>> required by upper layers (drm/radeon), then keeping around this "looks
>> optional, but is very much a core requirement" thing lingering around is
>> quite a call for trouble, IMHO.
>>
>> Yours, Daniel
>> --
>> Daniel Vetter
>> Mail: daniel at ffwll.ch
>> Mobile: +41 (0)79 365 57 48
>
> V4 is ok it apply on top of drm-next, and no i don't kill
> needs_scratch_page because i don't want to touch Alpha AGP
> code (i think it should die, i don't think alpha got AGP
> hw we care about or even support).
>
> Cheers,
> Jerome

(Working) AGP is only available on high-end systems [1].

I've been working on Alpha things for two years now, and I've talked
to only a single person with one of these systems, and he worked at HP
at the time. I'd certainly like to keep these supported, in the case
someone decides to donate one to me. :)

If you want to have any changes against Alpha AGP checked, Ivan
Kokshaysky is your guy.

Matt

[1] http://alphalinux.org/wiki/index.php/User:Mattst88/Alphas_with_AGP