From: Marcin Slusarz <marcin.slusarz@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
stable@kernel.org, dri-devel@lists.freedesktop.org,
Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH] drm/radeon: Add early unregister of firmware fb's
Date: Wed, 6 Oct 2010 21:46:46 +0200 [thread overview]
Message-ID: <20101006194646.GB3640@joi.lan> (raw)
In-Reply-To: <20101006185412.GB3555@viiv.ffwll.ch>
On Wed, Oct 06, 2010 at 08:54:12PM +0200, Daniel Vetter wrote:
> On Wed, Oct 06, 2010 at 08:20:15PM +0200, Marcin Slusarz wrote:
> > On Wed, Oct 06, 2010 at 06:39:07PM +0200, Daniel Vetter wrote:
> > > +static void radeon_kick_out_firmware_fb(struct drm_device *ddev)
> > > +{
> > > + struct apertures_struct *ap;
> > > + bool primary = false;
> > > +
> > > + ap = alloc_apertures(1);
> > > + ap->ranges[0].base = pci_resource_start(ddev->pdev, 0);
> > > + ap->ranges[0].size = pci_resource_len(ddev->pdev, 0);
> >
> > Any reason why this range differs from the one in radeonfb_create?
> > Maybe it needs to be fixed there too?
>
> I've stumbled over that, too. It won't really matter at all because the
> fb subsystem does an intersection check. The values in radeonfb_create
> look more like the correct ones, but I can't get at them before the card
> is initialized.
I think regions passed to fb layer should be "memory I want exclusive access to",
not "memory where I want to have the framebuffer", because the first one is stronger -
you don't want other framebuffer to mess with your non-fb memory...
Marcin
next prev parent reply other threads:[~2010-10-06 19:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-06 16:39 [PATCH] drm/radeon: Add early unregister of firmware fb's Daniel Vetter
2010-10-06 18:20 ` Marcin Slusarz
2010-10-06 18:54 ` Daniel Vetter
2010-10-06 19:46 ` Marcin Slusarz [this message]
2010-10-31 15:47 ` Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2010-08-10 7:34 Benjamin Herrenschmidt
2010-08-16 7:00 ` Rafał Miłecki
2010-08-16 7:31 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101006194646.GB3640@joi.lan \
--to=marcin.slusarz@gmail.com \
--cc=airlied@redhat.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=stable@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.