[PATCH] qxl: avoid an oops in the deferred io code.
From: Dave Airlie If we are using deferred io due to plymouth or X.org fbdev driver we will oops in memcpy due to this pointless multiply here, removing it fixes fbdev to start and not oops. Signed-off-by: Dave Airlie --- drivers/gpu/drm/qxl/qxl_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c index 88722f2..f437b30 100644 --- a/drivers/gpu/drm/qxl/qxl_fb.c +++ b/drivers/gpu/drm/qxl/qxl_fb.c @@ -108,7 +108,7 @@ static void qxl_fb_dirty_flush(struct fb_info *info) u32 x1, x2, y1, y2; /* TODO: hard coding 32 bpp */ - int stride = qfbdev->qfb.base.pitches[0] * 4; + int stride = qfbdev->qfb.base.pitches[0]; x1 = qfbdev->dirty.x1; x2 = qfbdev->dirty.x2; -- 1.8.3.1
[PATCH v3 02/32] drm/exynos: Merge overlay_ops into manager_ops
2013/11/2 Tomasz Figa :
> Hi Sean,
>
> On Friday 01 of November 2013 15:50:05 Sean Paul wrote:
>> On Thu, Oct 31, 2013 at 7:39 PM, Tomasz Figa
> wrote:
>> > Hi Sean,
>> >
>> > On Tuesday 29 of October 2013 12:12:48 Sean Paul wrote:
> [snip]
>> >> -static void fimd_wait_for_vblank(struct device *dev)
>> >> -{
>> >> - struct fimd_context *ctx = get_fimd_context(dev);
>> >> -
>> >> - if (ctx->suspended)
>> >> - return;
>> >> -
>> >> - atomic_set(&ctx->wait_vsync_event, 1);
>> >> -
>> >> - /*
>> >> - * wait for FIMD to signal VSYNC interrupt or return after
>> >> - * timeout which is set to 50ms (refresh rate of 20).
>> >> - */
>> >> - if (!wait_event_timeout(ctx->wait_vsync_queue,
>> >> - !atomic_read(&ctx->wait_vsync_event),
>> >> - DRM_HZ/20))
>> >> - DRM_DEBUG_KMS("vblank wait timed out.\n");
>> >> -}
>> >
>> > Do you need all the churn of moving all the functions above? I believe
>> > it would be enough to simply move the structure. This would greatly
>> > decrease the diffstat and chances of possible merge conflicts.
>>
>> Hi Tomasz,
>> I've done as you suggest,
>
> Thanks.
>
>> I'll post a new version once we settle on
>> the other issues you brought up.
>
> Okay.
>
> I'm yet to review remaining patches from this series (I hope to review
> next 5-7 patches later today), as it is quite a lot of changes, so stay
> tuned for further comments. ;)
>
Hi Tomasz,
Are you reviewing yet? I have looked into this patch series but I
couldn't find any big issues excepting bridge and eDP related patches
so I wanted to merge them as is, and then fix them up later.
Do you and Sean prefer this patch series to be more reviewed? If so or
If there are quite big issues to should be fixed then I will not merge
all patch series this time so that we can have enough time for more
detailed reviews including bridge, eDP related patches, dt support to
hdmi phy config, and so on.
Thanks,
Inki Dae
> Best regards,
> Tomasz
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
dma-buf non-coherent mmap
On 11/01/2013 02:32 PM, Lucas Stach wrote: > Am Freitag, den 01.11.2013, 09:22 -0400 schrieb Rob Clark: >> On Fri, Nov 1, 2013 at 6:17 AM, Daniel Vetter >> wrote: >>> On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach >>> wrote: >>>> GStreamer needs _some_ way of accessing the buffer contents with the >>>> CPU, this doesn't necessarily have to be the dumb mmap we have right >>>> now. >>>> DMA-BUF support in GSt is not really finished (I know we have a lot of >>>> patches internally to make it actually work with anything, which are >>>> trickling upstream right now), so this might be a good time to hammer >>>> out how it should be done, so we can adapt GSt before people start to >>>> rely on the dma-buf fallback mmap. >>>> >>>> I would think the bracketed mmap idea that was thrown around by Rob some >>>> time ago when the mmap topic first surfaced is simple enough that we >>>> don't need additional userspace helpers and should be enough to make the >>>> coherency issue disappear. >>> Yeah, if we add a BEGIN_MMAP/END_MMAP ioctl or so to the dma-buf mmap >>> stuff and simply demand that userspace calls that we'd have something >>> half-sane at least. Since we currently don't really have any real >>> users we could still do this abi change I think. >>> >>> One open issue is whether the BEGIN_MMAP ioctl should also synchronize >>> with any outstanding gpu access. Imo it should, since that's pretty >>> much how all the current drm drivers work, but maybe we should reserve >>> space for a few flags so that this can be extended later on - Android >>> seems to be pretty insistent on using explicit syncpoints everywhere >>> instead of implicit synchronization. Or maybe we should have the flag >>> already, but reject implicit syncing until Maarten's dma_fence stuff >>> is in and enabled, dunno. Adding him to cc. > I don't think we need that right now. We may prepare for implicit sync > by having the flag ready in the API, but don't force the exporters to > implement it right now. > >> I suppose I wouldn't mind if we made BEGIN/END_MMAP as sort of clones >> of the CPU_PREP/FINI ioctls I have in msm.. where the CPU_PREP takes a >> flag/bitmask to indicate READ/WRITE/NOSYNC >> >> That doesn't really help with partial buffer access, like you'd get if >> you were using the buffer for vertex upload. Although not really sure >> if we'd be seeing dmabuf's for that sort of use-case. We could make a >> more elaborate kernel interface that maps better to all the different >> cases in pipe_transfer. Or we could just say that that is overkill. >> I don't really have strong opinion about that (so someone who does, >> send an RFC). But I do agree with the "barriers only, not locks". >> > I just checked back with our GStreamer guy and he thinks that for the > use-cases he sees today it would make a lot of sense to have some way to > indicate that userspace is only going to access a partial range of the > buffer. I think this may be a crucial optimization on all kinds of > devices where you have to ensure coherency manually. > > Personally I would like to have the same kind of partial access > indicators in DRMs cpu_prep/fini to optimize all the userspace > suballocations we have today. > > I think we are all on the same page with the barriers only thing. > > Regards, > Lucas > OK, so I've attached something that would work on top of the current mmap() interface, and that would basically be NOPs on coherent architectures. Comment welcome. In order for this to be meaningful, we would need to make it mandatory if mmap is implemented. One outstanding issue Is how this might play with cache line alignment. We might be able to require the implementation to handle this, making sure that synced regions align both to the device cache and the cpu cache, and that, for example, a sync_for_cpu(DMA_TO_DEVICE) may actually result in device caches in the pad area being flushed... Region pwrites / preads having basically an identical interface (except the linear flag) but also taking a user pointer and stride, would also work just fine. Linear preads / pwrites could, I guess, be implemented the intended way using write / read syscalls on the file-descriptor. Still, I must say I'd prefer if we could just avoid mmap and the major drivers didn't implement it. Second on my list is probably pwrites / preads, and third this proposed interface. My preference order is based on the way vmwgfx handles this stuff from the Xorg driver today, doing unsynchronized region preads / pwrites from a shadow user-space buffer, keeping track on dirtied regions on both sides. (If it works for the Xorg driver, it should work for anything else :)). Thanks, /Thomas -- next part -- A non-text attachment was scrubbed... Name: dma-buf-ioctl.h Type: text/x-chdr Size: 2400 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/530d8534/attachment.h>
[PATCH 03/19] drm/imx: directly call drm_put_dev in ->remove
On Sun, Nov 03, 2013 at 02:31:09PM +0100, Daniel Vetter wrote:
> Again no apparent user of the driver data field.
>
> Cc: Sascha Hauer
> Cc: Greg Kroah-Hartman
> Signed-off-by: Daniel Vetter
Acked-by: Sascha Hauer
Sascha
> ---
> drivers/staging/imx-drm/imx-drm-core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/imx-drm/imx-drm-core.c
> b/drivers/staging/imx-drm/imx-drm-core.c
> index c1014eb2907d..8ffd4a900bb9 100644
> --- a/drivers/staging/imx-drm/imx-drm-core.c
> +++ b/drivers/staging/imx-drm/imx-drm-core.c
> @@ -432,6 +432,8 @@ static int imx_drm_driver_load(struct drm_device *drm,
> unsigned long flags)
> if (!imx_drm_device_get())
> ret = -EINVAL;
>
> + platform_set_drvdata(drm->platformdev, drm);
> +
> ret = 0;
>
> err_init:
> @@ -807,7 +809,7 @@ static int imx_drm_platform_probe(struct platform_device
> *pdev)
>
> static int imx_drm_platform_remove(struct platform_device *pdev)
> {
> - drm_platform_exit(&imx_drm_driver, pdev);
> + drm_put_dev(platform_get_drvdata(pdev));
>
> return 0;
> }
> --
> 1.8.4.rc3
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 --- Comment #24 from Laurent carlier --- Fixed since llvm-3.4svn rev193971. Now the default behavior in LLVM is to have PrettyStackTrace disabled. Mesa needs also the following patches to build: http://lists.freedesktop.org/archives/mesa-dev/2013-November/047501.html http://lists.freedesktop.org/archives/mesa-dev/2013-November/047625.html -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/d89d12df/attachment.html>
[PATCH 07/19] drm/host1x: Call drm_put_dev directly instead of drm_platform_exit
On Sun, Nov 03, 2013 at 02:31:13PM +0100, Daniel Vetter wrote: > I'm a bit confused about how this all works wrt host1x clients, but > this patch looks like the right thing to me. > > Cc: Thierry Reding > Signed-off-by: Daniel Vetter > --- > drivers/gpu/host1x/drm/drm.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) This has been largely rewritten in the code that I submitted in my 3.13 pull request. In fact Tegra DRM no longer uses drm_platform, but a custom bus type to deal with the quirkiness of the multi-driver architecture. So if you really want to get rid of drm_bus altogether I'd appreciate a heads-up so I know what's coming and can prepare. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/5ef497dd/attachment.pgp>
[PATCH 07/19] drm/host1x: Call drm_put_dev directly instead of drm_platform_exit
On Mon, Nov 04, 2013 at 10:10:38AM +0100, Thierry Reding wrote: > On Sun, Nov 03, 2013 at 02:31:13PM +0100, Daniel Vetter wrote: > > I'm a bit confused about how this all works wrt host1x clients, but > > this patch looks like the right thing to me. > > > > Cc: Thierry Reding > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/host1x/drm/drm.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > This has been largely rewritten in the code that I submitted in my 3.13 > pull request. In fact Tegra DRM no longer uses drm_platform, but a > custom bus type to deal with the quirkiness of the multi-driver > architecture. And for what it's worth, there's a drm_host1x_exit() that actually does only drm_put_dev(), which I guess could be simplified in the way that you've done here, but I sort of liked the symmetry between an *_init()/ *_exit() pair of functions. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/1f65809d/attachment.pgp>
[PATCH 11/19] drm: restrict the device list for shadow attached drivers
On Sun, Nov 03, 2013 at 03:14:16PM +0100, Daniel Vetter wrote:
> On Sun, Nov 3, 2013 at 3:05 PM, David Herrmann
> wrote:
> > On Sun, Nov 3, 2013 at 2:31 PM, Daniel Vetter
> > wrote:
> >> There's really no need for the drm core to keep a list of all
> >> devices of a given driver - the linux device model keeps perfect
> >> track of this already for us.
> >>
> >> The exception is old legacy ums drivers using pci shadow attaching.
> >> So rename the lists to make the use case clearer and rip out everything
> >> else.
> >>
> >> v2: Rebase on top of David Herrmann's drm device register changes.
> >> Also drop the bogus dev_set_drvdata for platform drivers that somehow
> >> crept into the original version - drivers really should be in full
> >> control of that field.
> >
> > You didn't really change any dev_set_drvdata, did you? And I guess you
> > mean pci_set_drvdata()? I had to keep it in place in drm_pci.c as it
> > has been there before my device-registration changes. However, with
> > your series you added the pci_set_drvdata() everywhere yourself, so
> > yes, please remove it.
>
> That was a bogus hunk in v1 of this patch, which iirc I've never
> posted onto the list anywhere. I added a platfrom_set_drvdata call,
> but with the previous series to make sure that each driver has that
> it's a bit redundant.
>
> Long term, when we split up the drm init code I think the drvdata
> assignment should be the driver's job.
I remember submitting a patch for that a while ago. It was applied about
a year ago, see commit a16d4f86019a ('drm: platform: Don't initialize
driver-private data'). The issue at the time was that I needed the
drvdata for other purposes and drm_platform_init() kept overwriting it,
which had me confused for days.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/2a2e85cb/attachment.pgp>
[Linaro-mm-sig] thoughts of looking at android fences
op 02-11-13 22:36, Colin Cross schreef:
> On Wed, Oct 30, 2013 at 5:17 AM, Maarten Lankhorst
> wrote:
>> op 24-10-13 14:13, Maarten Lankhorst schreef:
>>> So I actually tried to implement it now. I killed all the deprecated
>>> members and assumed a linear timeline.
>>> This means that syncpoints can only be added at the end, not in between. In
>>> particular it means sw_sync
>>> might be slightly broken.
>>>
>>> I only tested it with a simple program I wrote called ufence.c, it's in
>>> drivers/staging/android/ufence.c in the following tree:
>>>
>>> http://cgit.freedesktop.org/~mlankhorst/linux
>>>
>>> the "rfc: convert android to fence api" has all the changes from my
>>> dma-fence proposal to what android would need,
>>> it also converts the userspace fence api to use the dma-fence api.
>>>
>>> sync_pt is implemented as fence too. This meant not having to convert all
>>> of android right away, though I did make some changes.
>>> I killed the deprecated members and made all the fence calls forward to the
>>> sync_timeline_ops. dup and compare are no longer used.
>>>
>>> I haven't given this a spin on a full android kernel, only with the
>>> components that are in mainline kernel under staging and my dumb test
>>> program.
>>>
>>> ~Maarten
>>>
>>> PS: The nomenclature is very confusing. I want to rename dma-fence to
>>> syncpoint, but I want some feedback from the android devs first. :)
>>>
>> Come on, any feedback? I want to move the discussion forward.
>>
>> ~Maarten
> I experimented with it a little on a device that uses sync and came
> across a few bugs:
> 1. sync_timeline_signal needs to call __fence_signal on all signaled
> points on the timeline, not just the first
> 2. fence_add_callback doesn't always initialize cb.node
> 3. sync_fence_wait should take ms
> 4. sync_print_pt status printing was incorrect
> 5. there is a deadlock:
>sync_print_obj takes obj->child_list_lock
>sync_print_pt
>fence_is_signaled
>fence_signal takes fence->lock == obj->child_list_lock
> 6. freeing a timeline before all the fences holding points on that
> timeline have timed out results in a crash
>
> With the attached patch to fix these issues, our libsync and sync_test
> give the same results as with our sync code. I haven't tested against
> the full Android framework yet.
>
> The compare op and timeline ordering is critical to the efficiency of
> sync points on Android. The compare op is used when merging fences to
> drop all but the latest point on the same timeline. This is necessary
> for example when the same buffer is submitted to the display on
> multiple frames, like when there is a live wallpaper in the background
> updating at 60 fps and a static screen of widgets on top of it. The
> static widget buffer is submitted on every frame, returning a new
> fence each time. The compositor merges the new fence with the fence
> for the previous buffer, and because they are on the same timeline it
> merges down to a single point. I experimented with disabling the
> merge optimization on a Nexus 10, and found that leaving the screen on
> running a live wallpaper eventually resulted in 100k outstanding sync
> points.
Hey,
fence_add_callback will now always initialize cb->node, even on failure.
I added __fence_is_signaled, to be used with the lock held.
sync_print_pt didn't work when the fence was signaled with an error, I fixed
that.
So I reworked patch below, no merge optimization yet. It will be done as a
separate patch. :)
---
diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index 89c89ae19f58..9e7a63c4b07f 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -185,8 +185,10 @@ int fence_add_callback(struct fence *fence, struct
fence_cb *cb,
if (WARN_ON(!fence || !func))
return -EINVAL;
- if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
+ LIST_INIT_HEAD(&cb->node);
return -ENOENT;
+ }
spin_lock_irqsave(fence->lock, flags);
@@ -202,7 +204,8 @@ int fence_add_callback(struct fence *fence, struct fence_cb
*cb,
if (!ret) {
cb->func = func;
list_add_tail(&cb->node, &fence->cb_list);
- }
+ } else
+ LIST_INIT_HEAD(&cb->node);
spin_unlock_irqrestore(fence->lock, flags);
return ret;
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 110a9e99cb71..2c7fd3f2ab23 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -74,6 +74,16 @@ static void sync_timeline_free(struct kref *kref)
kfree(obj);
}
+static void sync_timeline_get(struct sync_timeline *obj)
+{
+ kref_get(&obj->kref);
+}
+
+static void sync_timeline_put(struct sync_timeline *obj)
+{
+ kref_put(&obj->kref, sync_timeline_free);
+}
+
void sync_timeline_destroy(struct sync_timeline *obj)
{
obj->de
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Wed, Oct 23, 2013 at 04:22:11PM +0100, Dave Airlie wrote: > On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul wrote: > > On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie wrote: > >>> As I mentioned earlier, display_ops is needed to have no any > >>> dependency of drm framework directly like below, > >>> > >>> DRM Framework > >>>| > >>> Exynos DRM Framework > >>> / | \ > >>> Real device drivers > >>> > >>> In particular, in case of ARM based DRM drivers with separated > >>> devices, I still tend to think it's better design than that device > >>> drivers implement the connector callbacks directly, but I will try to > >>> consider what is the better way. > >>> > >> > >> I think we need to start considering a framework where subdrivers just > >> add drm objects themselves, then the toplevel node is responsible for > >> knowing that everything for the current configuration is loaded. > >> > > > > It would be nice to specify the various pieces in dt, then have some > > type of drm notifier to the toplevel node when everything has been > > probed. Doing it in the dt would allow standalone drm_bridge/drm_panel > > drivers to be transparent as far as the device's drm driver is > > concerned. > > > > Sean > > > > > >> I realise we may need to make changes to the core drm to allow this > >> but we should probably start to create a strategy for fixing the API > >> issues that this throws up. > >> > >> Note I'm not yet advocating for dynamic addition of nodes once the > >> device is in use, or removing them. > >> > > I do wonder if we had some sort of tag in the device tree for any nodes > involved in the display, and the core drm layer would read that list, > and when every driver registers tick things off, and when the last one > joins we get a callback and init the drm layer, we'd of course have the > basic drm layer setup prior to that so we can add the objects as the > drivers load. It might make development a bit trickier as you'd need > to make sure someone claimed ownership of all the bits for init to proceed. I'm curious whether anyone actually ever bothered to look at the Tegra driver. It pretty much does all of this already. Granted the hardware may be more friendly than on most other SoCs, but essentially the problem is the same. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/bf142b30/attachment.pgp>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Tue, Oct 29, 2013 at 05:29:55PM -0400, Rob Clark wrote: > On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote: [...] > > I believe this is a huge step backwards from current kernel design > > standards, which prefer modularity. > > But it makes things behave in the way that userspace expects, which is > more important. Why would userspace care about the modularity of kernel drivers? The only thing that userspace should care about is whether there's a DRM device or not. How the kernel makes that happen should be completely irrelevant to userspace. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/415173b1/attachment.pgp>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
Hi Sean,
Sorry for the late reply.
On Wednesday 30 October 2013 11:56:18 Sean Paul wrote:
> On Wed, Oct 30, 2013 at 11:45 AM, Laurent Pinchart wrote:
> > On Wednesday 30 October 2013 11:32:24 Sean Paul wrote:
> >> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> >> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> > [snip]
> >
> >> >> An example: exynos_drm_drv would be a platform_driver which implements
> >> >> drm_driver. On drm_load, it would enumerate the various dt nodes for
> >> >> its IP blocks and initialize them with direct calls (like
> >> >> exynos_drm_fimd_initialize). If the board uses a bridge (say for
> >> >> eDP->LVDS), that bridge driver would be a real driver with its own
> >> >> probe.
> >> >>
> >> >> I think the ideal situation would be for the drm layer to manage the
> >> >> standalone drivers in a way that is transparent to the main driver,
> >> >> such that it doesn't need to know which type of hardware can hang off
> >> >> it. It will need to know if one exists since it might need to forego
> >> >> creating a connector, but it need not know anything else about it.
> >> >>
> >> >> To accomplish this, I think we need:
> >> >> (1) Some way for drm to enumerate the standalone drivers, so it can
> >> >> know when all of them have been probed
> >> >>
> >> >> (2) A drm registration function that's called by the standalone
> >> >> drivers once they're probed, and a hook with drm_device pointer called
> >> >> during drm_load for them to register their drm_* implementations
> >> >>
> >> >> (3) Something that will allow for deferred probe if the main driver
> >> >> kicks off before the standalones are in, it would need to be called
> >> >> before drm_platform/pci_init
> >> >>
> >> >> I think we'll need to expand on the media bindings to achieve (1).
> >> >
> >> > Could you elaborate on why you think so?
> >> >
> >> > I believe the video interface bindings contain everything needed for
> >> > this
> >> > case, except, of course, some device/bus specific parts, but those are
> >> > to
> >> > be defined by separate device/bus specific bindings.
> >>
> >> AFAICT, there is no way for drm to enumerate all of the pieces that
> >> need probing before it loads (ie: how do you enumerate all device
> >> nodes with pipe {} subnode[s]). I've given this more thought, and I
> >> think the following could work without forcing unified/split drivers
> >> (ie: it can be left to the driver author to choose).
> >>
> >> If there was some way for drm to know all of the pieces that need to
> >> be probed/initialized before calling drm_load, it could provide an API
> >> for various drivers to "claim" nodes. This API would accept the
> >> device_node being claimed as well as an initialize hook that will be
> >> called back to give the standalone driver a pointer to the drm_device.
> >>
> >> The main drm driver, which is responsible for calling
> >> drm_platform/pci_init, would claim the nodes it plans on implementing
> >> in the probe. It would then check drm to see if all requred nodes had
> >> been claimed. If they have not been claimed, that probe would defer
> >> and try again later.
> >>
> >> Once all required nodes have been "claimed", the main driver's probe
> >> would call drm_platform/pci_init to kick off load(). After load() has
> >> finished, the drm layer would then call the various standalone driver
> >> hooks that were previously registered when it claimed its node. These
> >> hooks would allow the driver to register its
> >> crtc/encoder/bridge/connector.
> >>
> >> Multi-driver solutions could work within this framework, as could
> >> integrated ones. This would also allow things like bridge drivers to
> >> be completely transparent.
> >
> > Have you all configured your spam filters to reject anything that is or
> > has
> > been related to CDF ?
> >
> > Split in two patches, the first one adding the infrastructure, the second
> > one adding OF support.
> >
> > http://git.linuxtv.org/pinchartl/fbdev.git/commitdiff/2d19e74ab8d86aaf5d54
> > c34c6bc940508f793512
> > http://git.linuxtv.org/pinchartl/fbdev.git/commitdiff/e8c4380ca4a6a62fa9d
> > 8bc340a6dcbd123b4f674
> >
> > The code can be extracted as a stand-alone solution, either specific to
> > DRM, or at the struct device level. As the problem is not DRM-specific,
> > the later would probably make more sense (if I'm not mistaken Grant
> > Likely - CCed- mentioned during the kernel summit was in favor of adding
> > the code in the device core).
> >
> > We've solved the exact same problem in V4L, do we *really* need to adopt
> > the NIH approach and reinvent the wheel ?
>
> Laurent,
> I really don't care how the functionality gets in, or what form it takes.
> This isn't NIH, I just want something that can be merged.
Great :-)
> When we talked about CDF at plumbers, I thought the plan was to split it up
> into the logical pieces and integrate it into drm. I haven't seen any
> movement on this front, is that still your in
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
Hi Daniel, On Wednesday 30 October 2013 16:53:22 Daniel Vetter wrote: > On Wed, Oct 30, 2013 at 4:32 PM, Sean Paul wrote: > > Once all required nodes have been "claimed", the main driver's probe > > would call drm_platform/pci_init to kick off load(). After load() has > > finished, the drm layer would then call the various standalone driver > > hooks that were previously registered when it claimed its node. These > > hooks would allow the driver to register its > > crtc/encoder/bridge/connector. > > Just a quick comment on calling the ->driver_load callback: I plan to > look again my "kill drm midlayer" series so that drivers are in full > control of the load sequence. Then they could do whatever delayed > loading the need to do by calling into optional helpers (hopefully > shared with asoc and v4l and other aggregate devices madness) and the > drm core simply does not need to care: The driver only > registers/allocates the drm_device once it's ready to do so. That would be great ! Please let me know if you would like me to test patches with the R-Car DU driver. -- Regards, Laurent Pinchart
[PATCH 07/19] drm/host1x: Call drm_put_dev directly instead of drm_platform_exit
On Mon, Nov 4, 2013 at 10:10 AM, Thierry Reding wrote: > On Sun, Nov 03, 2013 at 02:31:13PM +0100, Daniel Vetter wrote: >> I'm a bit confused about how this all works wrt host1x clients, but >> this patch looks like the right thing to me. >> >> Cc: Thierry Reding >> Signed-off-by: Daniel Vetter >> --- >> drivers/gpu/host1x/drm/drm.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) > > This has been largely rewritten in the code that I submitted in my 3.13 > pull request. In fact Tegra DRM no longer uses drm_platform, but a > custom bus type to deal with the quirkiness of the multi-driver > architecture. > > So if you really want to get rid of drm_bus altogether I'd appreciate a > heads-up so I know what's coming and can prepare. It's almost completely gone now, the one thing left to do is rip out bus->set_busid. But I have that planned already. http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-init-cleanup I guess I get to rebase the entire thing again, meh. It'd be awesome of other drm drivers would submit their stuff a bit earlier, atm there's absolutely nothing in drm-next beside all of intel and a few things for armada... Maybe we need to have a drm integration tree to make this a bit less frustrating. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 13/27] drm/tegra: Move subdevice infrastructure to host1x
On Mon, Oct 07, 2013 at 10:34:30AM +0200, Thierry Reding wrote:
> +static struct drm_bus drm_host1x_bus = {
> + .bus_type = DRIVER_BUS_HOST1X,
> + .set_busid = drm_host1x_set_busid,
> +};
Imo this needs to die asap, i.e. before it lands in drm-next. I've just
spent a bit of time trying to rid ourselves of this midlayer
brain-damange, and now new stuff crops up. See
http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-init-cleanup
drm_bus is a terribly midlayer madness disaster and needs to just burn
down. So what exactly is the reason here to not go with the drm_platform.c
stuff until I've gotten around to completely rip it all out?
Adding Dave.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
earing/disappearing. > > Perhaps there are ways to improve that, but I haven't come across > > hardware where the hdmi block can actually be dynamically removed. > > Userspace will need to prepare for that in the longer term, as we'll likely > see more needs for highly dynamic pipelines (one such use case is partial > reconfiguration in FPGA: albeit marginal today, we can't just ignore it in > the > long term). I don't want to solve this problem now though (even CDF made no > attempt at doing so ;-)). > > > > Not even saying that from development perspective, a huge single driver > > > would be much more difficult to test and debug, than several smaller > > > drivers, which could be developed separately. > > > > > > Unless there is a misunderstanding here, I think this is broken. > > > > > >> An example: exynos_drm_drv would be a platform_driver which implements > > >> drm_driver. On drm_load, it would enumerate the various dt nodes for > > >> its IP blocks and initialize them with direct calls (like > > >> exynos_drm_fimd_initialize). If the board uses a bridge (say for > > >> eDP->LVDS), that bridge driver would be a real driver with its own > > >> probe. > > >> > > >> I think the ideal situation would be for the drm layer to manage the > > >> standalone drivers in a way that is transparent to the main driver, > > >> such that it doesn't need to know which type of hardware can hang off > > >> it. It will need to know if one exists since it might need to forego > > >> creating a connector, but it need not know anything else about it. > > >> > > >> To accomplish this, I think we need: > > >> > > >> (1) Some way for drm to enumerate the standalone drivers, so it can > > >> know when all of them have been probed > > >> > > >> (2) A drm registration function that's called by the standalone > > >> drivers once they're probed, and a hook with drm_device pointer called > > >> during drm_load for them to register their drm_* implementations > > >> > > >> (3) Something that will allow for deferred probe if the main driver > > >> kicks off before the standalones are in, it would need to be called > > >> before drm_platform/pci_init > > I believe we should defer probing of the sub-drivers only, as we could run > into a circular dependency issue if we defer probing on all sides. The main > driver should use a notification mechanism instead. This idea has been > discussed during the kernel summit and seemed to not have caused a strong > disagreement. > > I will give this a try, given that I already have a working implementation as > part of my CDF RFC. I "just" need to extract it as a standalone change (BTW, > I > wish people would have read the CDF RFC in a bit more details, as it contains > ideas that have been proposed on the list by other developers during the last > couple of weeks. It's both saddening and slightly offending to post ideas > that > get ignored because of disagreements on the big picture and see them proposed > as brand new later on). I'll join in your whining. The Tegra DRM driver has implemented most of the ideas discussed here since the beginning. Oh... and that even predates CDF by a few months. Then again, perhaps I shouldn't complain all that loudly about people not looking at my driver since I don't look at most other DRM drivers either. Perhaps we should have a poll: who on this list has actually looked at any of the other DRM drivers? It seems to me like we really ought to improve how we cooperate. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/b0fa8af4/attachment.pgp>
[PULL] drm/tegra: Changes for v3.13-rc1
On Thu, Oct 31, 2013 at 10:17:28AM +0100, Thierry Reding wrote:
> Hi Dave,
>
> The following changes since commit 14c8d110e083d3a09ccf8cfe18ad22fe1450c2e9:
>
> drm/i915: abstract the conversion of device->minor out to a macro
> (2013-10-15 18:06:06 +1000)
>
> are available in the git repository at:
>
> git://anongit.freedesktop.org/tegra/linux tags/drm/for-3.13-rc1
>
> for you to fetch changes up to 977386a04bae2a5a5092c965c92c7c4d36eed23f:
>
> drm/tegra: Reserve syncpoint base for gr3d (2013-10-31 09:55:49 +0100)
>
> I decided to leave out the more controversial parts, such as DSI and
> panel support because of all the recent discussions and new rules for
> device tree bindings. My hope would be that we can get those issues
> worked out during the 3.13 release cycle so that we can finally have
> panel support for 3.14.
>
> Thanks,
> Thierry
>
>
> drm/tegra: Changes for v3.13-rc1
>
> The biggest part of the changes is the decoupling of the host1x and DRM
> drivers followed by the move of Tegra DRM back to drivers/gpu/drm/tegra
> from whence it came. There is a lot of cleanup as well, and the drivers
> can now be properly unloaded and reloaded.
>
> HDMI support for the Tegra114 SoC was contributed by Mikko Perttunen.
>
> gr2d support was extended to Tegra114 and the gr3d driver that has been
> in the works for quite some time finally made it in. All pieces to run
> an OpenGL driver on top of an upstream kernel are now available.
>
> Support for syncpoint bases was added by Arto Merilainen. This is useful
> for synchronizing between command streams from different engines such as
> gr2d and gr3d.
>
> Erik Faye-Lund and Wei Yongjun contributed various small fixes. Thanks!
>
>
> Arto Merilainen (4):
> gpu: host1x: Add 'flags' field to syncpt request
> gpu: host1x: Add syncpoint base support
> drm/tegra: Deliver syncpoint base to user space
> drm/tegra: Reserve base for gr2d
>
> Erik Faye-Lund (1):
> gpu: host1x: check relocs after all gathers are consumed
>
> Mikko Perttunen (3):
> drm/tegra: Add Tegra114 HDMI support
> drm/tegra: hdmi: Detect DVI-only displays
> drm/tegra: hdmi: Enable VDD earlier for hotplug/DDC
>
> Thierry Reding (35):
> drm: Track the proper DPMS mode of connectors
> drm: Fix typo in debug message
> gpu: host1x: Remove unused Makefile
> drm/tegra: Remove unused fields
> drm/tegra: Cleanup tegra_dc structure
> drm/tegra: Rename host1x_drm structure to tegra_drm
> drm/tegra: Rename host1x_drm_file to tegra_drm_file
> drm/tegra: Rename host1x_drm_context to tegra_drm_context
> gpu: host1x: Cleanup includes
> gpu: host1x: Do not discard .remove()
> gpu: host1x: Fix alignment of function arguments
> gpu: host1x: firewall: Rename cmdbuf_id -> cmdbuf
> gpu: host1x: firewall: Refactor register check
> drm/tegra: gr2d: Miscellaneous cleanups
> drm/tegra: Rename gr2d to tegra-gr2d
> drm/tegra: gem: Miscellaneous cleanups
> gpu: host1x: Make host1x header file public
> drm/tegra: Introduce tegra_drm_client structure
> gpu: host1x: Expose syncpt and channel functionality
> drm/tegra: Move subdevice infrastructure to host1x
I've just shot at this patch on the m-l, but I'd be rather unhappy if the
new drm_bus madness this add gets into drm-next. Would be a definite step
backwards imo for the drm core. Also more work for me to fix it all up ...
-Daniel
> gpu: host1x: Use relative include paths
> drm/tegra: Move driver to DRM tree
> drm/tegra: Properly cleanup and zero out resources
> drm/tegra: Allocate resources at probe time
> gpu: host1x: Add support for Tegra114
> drm/tegra: hdmi: Rename tegra{2,3} to tegra{20,30}
> drm/tegra: hdmi: Parameterize based on compatible property
> drm/tegra: hdmi: Fix build warnings
> drm/tegra: Start connectors with correct DPMS mode
> drm/tegra: Use symbolic names for gr2d registers
> drm/tegra: Introduce tegra_drm_submit()
> drm/tegra: Add 3D support
> drm/tegra: Add support for tiled buffer objects
> drm/tegra: Support bottom-up buffer objects
> drm/tegra: Reserve syncpoint base for gr3d
>
> Wei Yongjun (2):
> gpu: host1x: Disable clock on probe failure
> drm/tegra: Disable clock on probe failure
>
> MAINTAINERS| 2 +
> drivers/gpu/drm/Kconfig| 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_crtc_helper.c | 8
> drivers/gpu/drm/drm_drv.c | 2 +-
> drivers/gpu/{host1x/drm => drm/tegra}/Kconfig | 12 +++---
> drivers/gpu/drm/tegra/Makefile | 15 +++
> drivers/gpu/drm/tegra/bus.c
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
5 we have dynamic clock generator
> > > >> > to
> > > >> > crtc to encoder setups, so I worry about static lists per-pipe, so
> > > >> > I
> > > >> > still think just stating all these devices are needed for display
> > > >> > and
> > > >> > a list of valid interconnections between them, then we can have the
> > > >> > generic code model drm crtc/encoders/connectors on that list, and
> > > >> > construct the possible_crtcs /possible_clones etc at that stage.
> > > >>
> > > >> I'm, without excuse, hopeless at devicetree, so there are probably
> > > >> some violations, but something like:
> > > >>
> > > >> display-pipelines {
> > > >>
> > > >> required-elements = <&bridge-a &panel-a &encoder-x &encoder-y
> > > >>
> > > >> &crtc-x &crtc-y>;
> > > >>
> > > >> pipe1 {
> > > >>
> > > >> bridge = <&bridge-a>;
> > > >> encoder = <&encoder-x>;
> > > >> crtc = <&crtc-y>;
> > > >>
> > > >> };
> > > >> pipe2 {
> > > >>
> > > >> encoder = <&encoder-x>;
> > > >> crtc = <&crtc-x>;
> > > >>
> > > >> };
> > > >> pipe3 {
> > > >>
> > > >> panel = <&panel-a>;
> > > >> encoder = <&encoder-y>;
> > > >> crtc = <&crtc-y>;
> > > >>
> > > >> };
> > > >>
> > > >> };
> > > >>
> > > >> I'm tempted to add connector to the pipe nodes as well, so it's
> > > >> obvious which connector should be used in cases where multiple
> > > >> entities in the pipe implement drm_connector. However, I'm not sure
> > > >> if
> > > >> that would be NACKed by dt people.
> > > >>
> > > >> I'm also not sure if there are too many combinations for i915 and
> > > >> radeon to make this unreasonable. I suppose those devices could just
> > > >> use required-elements and leave the pipe nodes out.
> > > >
> > > > Just to put my two cents in, as one of the people involved into "the
> > > > device tree movement", I'd say that instead of creating artifical
> > > > entities, such as display-pipelines and all of the pipeX'es, device
> > > > tree should represent relations between nodes.
> > > >
> > > > According to the generic DT bindings we already have for
> > > > video-interfaces
> > > > [1] your example connection layout would look as follows:
> > > Hi Tomasz
> > > Thanks for sending this along.
> > >
> > > I think the general consensus is that each drm driver should be
> > > implemented as a singular driver. That is, N:1 binding to driver
> > > mapping, where there are N IP blocks. Optional devices (such as
> > > bridges, panels) probably make sense to spin off as standalone
> > > drivers.
> >
> > I believe this is a huge step backwards from current kernel design
> > standards, which prefer modularity.
> >
> > Having multiple IPs being part of the DRM subsystem in a SoC, it would be
> > nice to have the possibility to compile just a subset of support for them
> > into the kernel and load rest of them as modules. (e.g. basic LCD
> > controller on a mobile phone compiled in and external connectors, like
> > HDMI as modules)
> >
> > Not even saying that from development perspective, a huge single driver
> > would be much more difficult to test and debug, than several smaller
> > drivers, which could be developed separately.
> >
>
> This is the opposite of our experience, though. A series of small drivers
> like what's in drm/exynos can become really tedious/difficult to
> coordinate. If you have separate drivers, everything needs to be
> synchronized, but also has to account for potentially different loading
> order.
>
> It seems you're only thinking about the basic case, where you only support
> a single resolution, no dpms, no suspend to ram... But when you want full
> fledged functionality, then the issues I described become much more
> prevalent.
I fail to see how this is relevant here. It's fairly clear that even if
a DRM driver is composed of more than a single platform driver, there's
still a single point of coordination (the DRM driver). How does that
have any impact on what features the driver can support? All of the
features will be exposed via DRM, whether you use multiple drivers or a
single monolithic one underneath is completely irrelevant.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/c7658fa1/attachment-0001.pgp>
dma-buf non-coherent mmap
Hi Thomas,
I inlined the patch, to discuss more easily.
Am Montag, den 04.11.2013, 08:53 +0100 schrieb Thomas Hellstrom:
> enum dma_buf_data_direction {
> DMA_BUF_BIDIRECTIONAL,
> DMA_BUF_TO_DEVICE,
> DMA_BUF_FROM_DEVICE
> };
I don't think the DMA API semantic makes much sense here. Doing a sync
from device is at least a bit complicated, as we would have to track
down the device in which domain the buffer is currently residing for
write. This may be doable by bouncing the sync op from the exporter to
the right attachment.
The other way around is even more messier: a DMA-BUF is by definition
shared between multiple devices, so which of them should you sync to?
All of them?
I think the API used for userspace access should only be concerned with
making sure the CPU gets a coherent view to the resource at the point of
sharing i.e. sysmem. All DMA-BUF users should make sure that they sync
their writes to the point of sharing strictly before signaling that they
are done with the buffer.
Maybe this is just a naming problem, but IMHO the API should make it
really clear that the sync only makes sure that the data reaches the
point of sharing.
>
> /**
> * struct dma_buf_sync_arg - Argument to
> *
> * @start_x: Upper left X coordinate of area to be synced.
> * Unit is format-dependent
> * @start_y: Upper left Y coordinate of area to be synced.
> * Unit is format-dependent.
> * @width: Width of area to be synced. Grows to the right.
> * Unit is format-dependent.
> * @height:Height of area to be synced. Grows downwards.
> * Unit is format-dependent.
While I see why you would need this I don't really like the concept of a
two dimensional resource pushed into the API. You already need the
linear flag to make this work with 1D resources and I don't see what
happens when you encounter 3D or array resources.
Don't take this as a strong rejection as I see why this is useful, but I
don't like how the interface looks like right now.
> * @direction: Intended transfer direction of data.
> * @flags: Flags to tune the synchronizing behaviour.
> */
>
> struct dma_buf_sync_region_arg {
> __u32 buf_identifier;
> __u32 start_x;
> __u32 start_y;
> __u32 width;
> __u32 height;
> enum dma_buf_data_direction direction;
> __u32 flags;
> __u32 pad;
> };
>
> /**
> * Force sync any outstanding rendering of the exporter before
> returning.
> * This is strictly a performance hint. The user may omit this flag to
> * speed up execution of the call, if it is known that previous
> rendering
> * affecting (by read or write) the synchronized area has already
> finished.
> */
> #define DMA_BUF_SYNC_FLAG_SYNC (1 << 0);
>
> /**
> * Treat @start_x as byte offset into buffer and @width as byte
> * synchronization length. The values of @start_y and @height are
> ignored.
> * (Separate ioctl?)
> */
> #define DMA_BUF_SYNC_FLAG_LINEAR (1 << 1);
>
> /**
> * Allow the implementation to coalesce sync_for_device calls, until
> either
> * a) An explicit flush
> * b) A sync for cpu call with DMA_BUF_BIDIRECTIONAL or
> DMA_BUF_TO_DEVICE
> *
> * Note: An implementation may choose to ignore this flag.
> */
> #define DMA_BUF_SYNC_FLAG_COALESCE (1 << 2);
>
> /**
> * IOCTLS-
> *
> * Kernel waits should, if possible, be performed interruptible, and
> the
> * ioctl may sett errno to EINTR if the ioctl needs to be restarted.
> * To be discussed: Any sync operation may not affect areas outside
> the
> * region indicated. (Good for vmwgfx, but plays ill with cache line
> alignment)
> */
>
> /**
> * Sync for CPU.
> */
> #define DMA_BUF_SYNC_REGION_FOR_CPU \
> _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync_region_arg)
>
> /**
> * Sync for device. This is the default state of a dma-buf.
> */
> #define DMA_BUF_SYNC_REGION_FOR_DEVICE \
> _IOW(DMA_BUF_BASE, 1, struct dma_buf_sync_region_arg)
>
> /**
> * Flush any coalesced SYNC_REGION_FOR_DEVICE
> */
> #define DMA_BUF_SYNC_REGION_FLUSH \
> _IOW(DMA_BUF_BASE, 2, __u32)
>
What is the use-case for this? Why don't you think that usespace could
be smart enough to coalesce the flush on its own?
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Linaro-mm-sig] thoughts of looking at android fences
op 02-11-13 22:36, Colin Cross schreef:
> On Wed, Oct 30, 2013 at 5:17 AM, Maarten Lankhorst
> wrote:
>> op 24-10-13 14:13, Maarten Lankhorst schreef:
>>> So I actually tried to implement it now. I killed all the deprecated
>>> members and assumed a linear timeline.
>>> This means that syncpoints can only be added at the end, not in between. In
>>> particular it means sw_sync
>>> might be slightly broken.
>>>
>>> I only tested it with a simple program I wrote called ufence.c, it's in
>>> drivers/staging/android/ufence.c in the following tree:
>>>
>>> http://cgit.freedesktop.org/~mlankhorst/linux
>>>
>>> the "rfc: convert android to fence api" has all the changes from my
>>> dma-fence proposal to what android would need,
>>> it also converts the userspace fence api to use the dma-fence api.
>>>
>>> sync_pt is implemented as fence too. This meant not having to convert all
>>> of android right away, though I did make some changes.
>>> I killed the deprecated members and made all the fence calls forward to the
>>> sync_timeline_ops. dup and compare are no longer used.
>>>
>>> I haven't given this a spin on a full android kernel, only with the
>>> components that are in mainline kernel under staging and my dumb test
>>> program.
>>>
>>> ~Maarten
>>>
>>> PS: The nomenclature is very confusing. I want to rename dma-fence to
>>> syncpoint, but I want some feedback from the android devs first. :)
>>>
>> Come on, any feedback? I want to move the discussion forward.
>>
>> ~Maarten
> I experimented with it a little on a device that uses sync and came
> across a few bugs:
> 1. sync_timeline_signal needs to call __fence_signal on all signaled
> points on the timeline, not just the first
> 2. fence_add_callback doesn't always initialize cb.node
> 3. sync_fence_wait should take ms
> 4. sync_print_pt status printing was incorrect
> 5. there is a deadlock:
>sync_print_obj takes obj->child_list_lock
>sync_print_pt
>fence_is_signaled
>fence_signal takes fence->lock == obj->child_list_lock
> 6. freeing a timeline before all the fences holding points on that
> timeline have timed out results in a crash
>
> With the attached patch to fix these issues, our libsync and sync_test
> give the same results as with our sync code. I haven't tested against
> the full Android framework yet.
>
> The compare op and timeline ordering is critical to the efficiency of
> sync points on Android. The compare op is used when merging fences to
> drop all but the latest point on the same timeline. This is necessary
> for example when the same buffer is submitted to the display on
> multiple frames, like when there is a live wallpaper in the background
> updating at 60 fps and a static screen of widgets on top of it. The
> static widget buffer is submitted on every frame, returning a new
> fence each time. The compositor merges the new fence with the fence
> for the previous buffer, and because they are on the same timeline it
> merges down to a single point. I experimented with disabling the
> merge optimization on a Nexus 10, and found that leaving the screen on
> running a live wallpaper eventually resulted in 100k outstanding sync
> points.
Well, here I did the same for dma-fence, can you take a look?
---
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 2c7fd3f2ab23..d1d89f1f8553 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -232,39 +232,62 @@ void sync_fence_install(struct sync_fence *fence, int fd)
}
EXPORT_SYMBOL(sync_fence_install);
+static void sync_fence_add_pt(struct sync_fence *fence, int *i, struct fence
*pt) {
+ fence->cbs[*i].sync_pt = pt;
+ fence->cbs[*i].fence = fence;
+
+ if (!fence_add_callback(pt, &fence->cbs[*i].cb, fence_check_cb_func)) {
+ fence_get(pt);
+ (*i)++;
+ }
+}
+
struct sync_fence *sync_fence_merge(const char *name,
struct sync_fence *a, struct sync_fence *b)
{
int num_fences = a->num_fences + b->num_fences;
struct sync_fence *fence;
- int i;
+ int i, i_a, i_b;
fence = sync_fence_alloc(offsetof(struct sync_fence, cbs[num_fences]),
name);
if (fence == NULL)
return NULL;
- fence->num_fences = num_fences;
atomic_set(&fence->status, num_fences);
- for (i = 0; i < a->num_fences; ++i) {
- struct fence *pt = a->cbs[i].sync_pt;
-
- fence_get(pt);
- fence->cbs[i].sync_pt = pt;
- fence->cbs[i].fence = fence;
- if (fence_add_callback(pt, &fence->cbs[i].cb,
fence_check_cb_func))
- atomic_dec(&fence->status);
+ /*
+* Assume sync_fence a and b are both ordered and have no
+* duplicates with the same context.
+*
+* If a sync_fence can only be created with sync_fence_merge
+* and sync_fence_create, this is a rea
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
arent to the main driver,
> >> such that it doesn't need to know which type of hardware can hang off
> >> it. It will need to know if one exists since it might need to forego
> >> creating a connector, but it need not know anything else about it.
> >>
> >> To accomplish this, I think we need:
> >> (1) Some way for drm to enumerate the standalone drivers, so it can
> >> know when all of them have been probed
> >> (2) A drm registration function that's called by the standalone
> >> drivers once they're probed, and a hook with drm_device pointer called
> >> during drm_load for them to register their drm_* implementations
> >> (3) Something that will allow for deferred probe if the main driver
> >> kicks off before the standalones are in, it would need to be called
> >> before drm_platform/pci_init
> >>
> >> I think we'll need to expand on the media bindings to achieve (1).
> >
> > Could you elaborate on why you think so?
> >
> > I believe the video interface bindings contain everything needed for this
> > case, except, of course, some device/bus specific parts, but those are to
> > be defined by separate device/bus specific bindings.
> >
>
> AFAICT, there is no way for drm to enumerate all of the pieces that
> need probing before it loads (ie: how do you enumerate all device
> nodes with pipe {} subnode[s]). I've given this more thought, and I
> think the following could work without forcing unified/split drivers
> (ie: it can be left to the driver author to choose).
>
> If there was some way for drm to know all of the pieces that need to
> be probed/initialized before calling drm_load, it could provide an API
> for various drivers to "claim" nodes. This API would accept the
> device_node being claimed as well as an initialize hook that will be
> called back to give the standalone driver a pointer to the drm_device.
>
> The main drm driver, which is responsible for calling
> drm_platform/pci_init, would claim the nodes it plans on implementing
> in the probe. It would then check drm to see if all requred nodes had
> been claimed. If they have not been claimed, that probe would defer
> and try again later.
>
> Once all required nodes have been "claimed", the main driver's probe
> would call drm_platform/pci_init to kick off load(). After load() has
> finished, the drm layer would then call the various standalone driver
> hooks that were previously registered when it claimed its node. These
> hooks would allow the driver to register its
> crtc/encoder/bridge/connector.
>
> Multi-driver solutions could work within this framework, as could
> integrated ones. This would also allow things like bridge drivers to
> be completely transparent.
>
> I hope that made sense ;)
I'll just go and repeat myself in the hope to increase chances of
someone reading it: I recommend looking at the Tegra DRM driver which
solves a lot of these issues already (in much the same way that you
suggest here).
The version in the tree that I've submitted for 3.13 (I think Dave
hasn't merged it yet) is improved in many ways. Unfortunately it isn't
quite as generic as I would've liked it to be and rather tied to how the
Tegra SoC is architected, but I've volunteered elsewhere to look into
further abstracting things away in order to turn it into something that
could even be used outside of DRM. I haven't received much feedback,
though, so I have close to no idea what the requirements for others are,
and hence it's difficult to know where to start.
In case anyone's interested, there's some code here:
http://cgit.freedesktop.org/tegra/linux/log/?h=drm/for-next
More specifically:
http://cgit.freedesktop.org/tegra/linux/tree/drivers/gpu/host1x/bus.c?h=drm/for-next
http://cgit.freedesktop.org/tegra/linux/tree/drivers/gpu/drm/tegra/bus.c?h=drm/for-next
http://cgit.freedesktop.org/tegra/linux/tree/drivers/gpu/drm/tegra/drm.c?h=drm/for-next
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/ebdb0612/attachment-0001.pgp>
[Bug 71212] New: [RadeonSI]: Unigine Heaven fails to launch with X error
https://bugs.freedesktop.org/show_bug.cgi?id=71212 Priority: medium Bug ID: 71212 Assignee: dri-devel at lists.freedesktop.org Summary: [RadeonSI]: Unigine Heaven fails to launch with X error Severity: major Classification: Unclassified OS: All Reporter: hysvats at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 88589 --> https://bugs.freedesktop.org/attachment.cgi?id=88589&action=edit Xorg.log Driver Stack Details: = 1)Kernel-3.11.0-12-generic 2)drm-2.4.46 3)Mesa-10.0.0-devel 4)Xorg-server-1.14.3 5)xf86-video-ati- git 6)glamor-0.5.1 7)LLVM-3.3 System Configuration: = Asic : Cape Veede Pro-683F O.S. : Ubuntu-13.10 (64 bit) Steps to Reproduce : = 1) Install Unigine Heaven with Phoronix-test-suite 2) phoronix-test-suite run unigine-heaven Observed: == Loading "/home/atitest/.phoronix-test-suite/installed-tests/pts/unigine-heaven-1.5.2/Unigine_Heaven-4.0/bin/../data/heaven_4.0.cfg"... Loading "libGPUMonitor_x64.so"... Loading "libGL.so.1"... Loading "libopenal.so.1"... Set 1920x1200 windowed video mode X Error of failed request: GLXBadFBConfig Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 34 () Serial number of failed request: 55 Current serial number in output stream: 54 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/95294236/attachment.html>
[Bug 71212] [RadeonSI]: Unigine Heaven fails to launch with X error
https://bugs.freedesktop.org/show_bug.cgi?id=71212 --- Comment #1 from samit vats --- Created attachment 88590 --> https://bugs.freedesktop.org/attachment.cgi?id=88590&action=edit dmesg.txt -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/b2c85ebb/attachment.html>
dma-buf non-coherent mmap
On 11/04/2013 11:22 AM, Lucas Stach wrote:
> Hi Thomas,
>
> I inlined the patch, to discuss more easily.
>
> Am Montag, den 04.11.2013, 08:53 +0100 schrieb Thomas Hellstrom:
>> enum dma_buf_data_direction {
>> DMA_BUF_BIDIRECTIONAL,
>> DMA_BUF_TO_DEVICE,
>> DMA_BUF_FROM_DEVICE
>> };
> I don't think the DMA API semantic makes much sense here. Doing a sync
> from device is at least a bit complicated, as we would have to track
> down the device in which domain the buffer is currently residing for
> write. This may be doable by bouncing the sync op from the exporter to
> the right attachment.
>
> The other way around is even more messier: a DMA-BUF is by definition
> shared between multiple devices, so which of them should you sync to?
> All of them?
>
> I think the API used for userspace access should only be concerned with
> making sure the CPU gets a coherent view to the resource at the point of
> sharing i.e. sysmem. All DMA-BUF users should make sure that they sync
> their writes to the point of sharing strictly before signaling that they
> are done with the buffer.
> Maybe this is just a naming problem, but IMHO the API should make it
> really clear that the sync only makes sure that the data reaches the
> point of sharing.
Good point. I think the options need to remain, but we could rename
DEVICE to STORAGE, or whatever In our case,
sync_for_cpu(DMA_BUF_TO_STORAGE) would be a no-op, whereas,
sync_for_cpu(DMA_BUF_BIDIRECTIONAL) would trigger a DMA read.
>
>> /**
>> * struct dma_buf_sync_arg - Argument to
>> *
>> * @start_x: Upper left X coordinate of area to be synced.
>> * Unit is format-dependent
>> * @start_y: Upper left Y coordinate of area to be synced.
>> * Unit is format-dependent.
>> * @width: Width of area to be synced. Grows to the right.
>> * Unit is format-dependent.
>> * @height:Height of area to be synced. Grows downwards.
>> * Unit is format-dependent.
> While I see why you would need this I don't really like the concept of a
> two dimensional resource pushed into the API. You already need the
> linear flag to make this work with 1D resources and I don't see what
> happens when you encounter 3D or array resources.
>
> Don't take this as a strong rejection as I see why this is useful, but I
> don't like how the interface looks like right now.
I understand. I don't think 1D only syncing options would suffice
performance-wise, as
the use-case I'm most afraid of is people trying to share 2D contents
between user-space
processes.
What do you think about supplying descriptor objects that could either
describe a
linear area, 2D area or whatever? Whenever (if) a new descriptor type is
added to the interface we could
have a legacy implementation that implements it in terms of 1D and 2D syncs.
>
>> * @direction: Intended transfer direction of data.
>> * @flags: Flags to tune the synchronizing behaviour.
>> */
>>
>> struct dma_buf_sync_region_arg {
>> __u32 buf_identifier;
>> __u32 start_x;
>> __u32 start_y;
>> __u32 width;
>> __u32 height;
>> enum dma_buf_data_direction direction;
>> __u32 flags;
>> __u32 pad;
>> };
>>
>> /**
>> * Force sync any outstanding rendering of the exporter before
>> returning.
>> * This is strictly a performance hint. The user may omit this flag to
>> * speed up execution of the call, if it is known that previous
>> rendering
>> * affecting (by read or write) the synchronized area has already
>> finished.
>> */
>> #define DMA_BUF_SYNC_FLAG_SYNC (1 << 0);
>>
>> /**
>> * Treat @start_x as byte offset into buffer and @width as byte
>> * synchronization length. The values of @start_y and @height are
>> ignored.
>> * (Separate ioctl?)
>> */
>> #define DMA_BUF_SYNC_FLAG_LINEAR (1 << 1);
>>
>> /**
>> * Allow the implementation to coalesce sync_for_device calls, until
>> either
>> * a) An explicit flush
>> * b) A sync for cpu call with DMA_BUF_BIDIRECTIONAL or
>> DMA_BUF_TO_DEVICE
>> *
>> * Note: An implementation may choose to ignore this flag.
>> */
>> #define DMA_BUF_SYNC_FLAG_COALESCE (1 << 2);
>>
>> /**
>> * IOCTLS-
>> *
>> * Kernel waits should, if possible, be performed interruptible, and
>> the
>> * ioctl may sett errno to EINTR if the ioctl needs to be restarted.
>> * To be discussed: Any sync operation may not affect areas outside
>> the
>> * region indicated. (Good for vmwgfx, but plays ill with cache line
>> alignment)
>> */
>>
>> /**
>> * Sync for CPU.
>> */
>> #define DMA_BUF_SYNC_REGION_FOR_CPU \
>> _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync_region_arg)
>>
>> /**
>> * Sync for device. This is the default state of a dma-buf.
>> */
>> #define DMA_BUF_SYNC_REGION_FOR_DEVICE \
>> _IOW(DMA_BUF_BASE, 1, struct dma_buf_sync_region_arg)
>>
>> /**
>> * Flush any coalesced SYNC_REGION_FOR_DEVICE
>> */
>> #define DMA_BUF_SYNC_R
[PATCH 07/19] drm/host1x: Call drm_put_dev directly instead of drm_platform_exit
On Mon, Nov 04, 2013 at 11:14:39AM +0100, Daniel Vetter wrote: > On Mon, Nov 4, 2013 at 10:10 AM, Thierry Reding > wrote: > > On Sun, Nov 03, 2013 at 02:31:13PM +0100, Daniel Vetter wrote: > >> I'm a bit confused about how this all works wrt host1x clients, but > >> this patch looks like the right thing to me. > >> > >> Cc: Thierry Reding > >> Signed-off-by: Daniel Vetter > >> --- > >> drivers/gpu/host1x/drm/drm.c | 3 +-- > >> 1 file changed, 1 insertion(+), 2 deletions(-) > > > > This has been largely rewritten in the code that I submitted in my 3.13 > > pull request. In fact Tegra DRM no longer uses drm_platform, but a > > custom bus type to deal with the quirkiness of the multi-driver > > architecture. > > > > So if you really want to get rid of drm_bus altogether I'd appreciate a > > heads-up so I know what's coming and can prepare. > > It's almost completely gone now, the one thing left to do is rip out > bus->set_busid. But I have that planned already. > > http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-init-cleanup > > I guess I get to rebase the entire thing again, meh. > > > It'd be awesome of other drm drivers would submit their stuff a bit > earlier, atm there's absolutely nothing in drm-next beside all of > intel and a few things for armada... Maybe we need to have a drm > integration tree to make this a bit less frustrating. > Yeah, I know. I had actually planned on sending out this pull request much earlier, but then all the discussion around DRM panel and device tree bindings started again... Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/929a9be8/attachment.pgp>
[PATCH v2 13/27] drm/tegra: Move subdevice infrastructure to host1x
On Mon, Nov 04, 2013 at 11:20:55AM +0100, Daniel Vetter wrote:
> On Mon, Oct 07, 2013 at 10:34:30AM +0200, Thierry Reding wrote:
> > +static struct drm_bus drm_host1x_bus = {
> > + .bus_type = DRIVER_BUS_HOST1X,
> > + .set_busid = drm_host1x_set_busid,
> > +};
>
> Imo this needs to die asap, i.e. before it lands in drm-next. I've just
> spent a bit of time trying to rid ourselves of this midlayer
> brain-damange, and now new stuff crops up. See
>
> http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-init-cleanup
>
> drm_bus is a terribly midlayer madness disaster and needs to just burn
> down. So what exactly is the reason here to not go with the drm_platform.c
> stuff until I've gotten around to completely rip it all out?
Dave asked me whether it was possible to move the Tegra DRM driver back
into drivers/gpu/drm (from drivers/gpu/host1x/drm) and introducing this
new bus was the only solution I saw (besides perhaps using cross-
subsystem global variables) to do that.
Now, I'm not a big fan at all of the whole drm_bus shebang myself, so
whatever help you need in getting rid of it, please let me know. The
drm_bus implementation that this adds is about 34 lines, so it shouldn't
be difficult to get rid of. If you throw out drm_driver.bus completely,
then it should be a matter of just deleting that code and the rest
should be able to continue working as is. The only reason I added it is
because the kernel crashes if its not there, depending on what userspace
is run.
So I find myself in the middle of controversy again... I seem to have a
knack for it.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/747793ca/attachment-0001.pgp>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
2013/11/4 Thierry Reding :
> On Tue, Oct 29, 2013 at 08:46:03PM -0700, St?phane Marchesin wrote:
>> On Tue, Oct 29, 2013 at 1:50 PM, Tomasz Figa
>> wrote:
>>
>> > Hi Sean,
>> >
>> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
>> > > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
>> > wrote:
>> > > > Hi,
>> > > >
>> > > > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>> > > >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie
>> > wrote:
>> > > >> > I think we need to start considering a framework where
>> > > >> > subdrivers
>> > > >> > just
>> > > >> > add drm objects themselves, then the toplevel node is
>> > > >> > responsible
>> > > >> > for
>> > > >> > knowing that everything for the current configuration is
>> > > >> > loaded.
>> > > >>
>> > > >> It would be nice to specify the various pieces in dt, then have
>> > > >> some
>> > > >> type of drm notifier to the toplevel node when everything has
>> > > >> been
>> > > >> probed. Doing it in the dt would allow standalone
>> > > >> drm_bridge/drm_panel
>> > > >> drivers to be transparent as far as the device's drm driver is
>> > > >> concerned.
>> > > >>
>> > > >> Sean
>> > > >>
>> > > >> > I realise we may need to make changes to the core drm to allow
>> > > >> > this
>> > > >> > but we should probably start to create a strategy for fixing
>> > > >> > the
>> > > >> > API
>> > > >> > issues that this throws up.
>> > > >> >
>> > > >> > Note I'm not yet advocating for dynamic addition of nodes once
>> > > >> > the
>> > > >> > device is in use, or removing them.
>> > > >> >>>
>> > > >> >>> I do wonder if we had some sort of tag in the device tree for any
>> > > >> >>> nodes
>> > > >> >>> involved in the display, and the core drm layer would read that
>> > > >> >>> list,
>> > > >> >>> and when every driver registers tick things off, and when the
>> > > >> >>> last
>> > > >> >>> one
>> > > >> >>> joins we get a callback and init the drm layer, we'd of course
>> > > >> >>> have
>> > > >> >>> the
>> > > >> >>> basic drm layer setup prior to that so we can add the objects as
>> > > >> >>> the
>> > > >> >>> drivers load. It might make development a bit trickier as you'd
>> > > >> >>> need
>> > > >> >>> to make sure someone claimed ownership of all the bits for init
>> > > >> >>> to
>> > > >> >>> proceed.>>
>> > > >> >>
>> > > >> >> Yeah, that's basically what the strawman looked like in my head.
>> > > >> >>
>> > > >> >> Instead of a property in each node, I was thinking of having a
>> > > >> >> separate gfx pipe nodes that would have dt pointers to the various
>> > > >> >> pieces involved in that pipe. This would allow us to associate
>> > > >> >> standalone entities like bridges and panels with encoders in dt
>> > > >> >> w/o
>> > > >> >> doing it in the drm code. I *think* this should be Ok with the dt
>> > > >> >> guys
>> > > >> >> since it is still describing the hardware, but I think we'd have
>> > > >> >> to
>> > > >> >> make sure it wasn't drm-specific.
>> > > >> >
>> > > >> > I suppose the question is how much dynamic pipeline construction
>> > > >> > there
>> > > >> > is,
>> > > >> >
>> > > >> > even on things like radeon and i915 we have dynamic clock generator
>> > > >> > to
>> > > >> > crtc to encoder setups, so I worry about static lists per-pipe, so
>> > > >> > I
>> > > >> > still think just stating all these devices are needed for display
>> > > >> > and
>> > > >> > a list of valid interconnections between them, then we can have the
>> > > >> > generic code model drm crtc/encoders/connectors on that list, and
>> > > >> > construct the possible_crtcs /possible_clones etc at that stage.
>> > > >>
>> > > >> I'm, without excuse, hopeless at devicetree, so there are probably
>> > > >> some violations, but something like:
>> > > >>
>> > > >> display-pipelines {
>> > > >>
>> > > >> required-elements = <&bridge-a &panel-a &encoder-x &encoder-y
>> > > >>
>> > > >> &crtc-x &crtc-y>;
>> > > >>
>> > > >> pipe1 {
>> > > >>
>> > > >> bridge = <&bridge-a>;
>> > > >> encoder = <&encoder-x>;
>> > > >> crtc = <&crtc-y>;
>> > > >>
>> > > >> };
>> > > >> pipe2 {
>> > > >>
>> > > >> encoder = <&encoder-x>;
>> > > >> crtc = <&crtc-x>;
>> > > >>
>> > > >> };
>> > > >> pipe3 {
>> > > >>
>> > > >> panel = <&panel-a>;
>> > > >> encoder = <&encoder-y>;
>> > > >> crtc = <&crtc-y>;
>> > > >>
>> > > >> };
>> > > >>
>> > > >> };
>> > > >>
>> > > >> I'm tempted to add connector to the pipe nodes as well, so it's
>> > > >> obvious which connector should be used in cases where multiple
>> > > >> entities in the pipe implement drm_connector. However, I'm not sure
>> > > >> if
>> > > >> that would be NACKed by dt people.
>> > > >>
>> > > >> I'm also not sure if there are too many combinations for i915 and
>> > > >> radeon to make this unreasonable. I suppose those devices could just
>>
[Bug 63181] Amilo Xi 2550: NMI trace after suspend/resume cycle
https://bugzilla.kernel.org/show_bug.cgi?id=63181 Alan changed: What|Removed |Added Product|Drivers |Platform Specific/Hardware Summary|Amilo Xi 2550: kernel panic |Amilo Xi 2550: NMI trace |during normal operation |after suspend/resume cycle Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Component|Video(DRI - non Intel) |i386 Resolution|--- |INSUFFICIENT_DATA Assignee|drivers_video-dri at kernel-bu |platform_i386 at kernel-bugs.o |gs.osdl.org |sdl.org --- Comment #2 from Alan --- No useful info in the dump really -- You are receiving this mail because: You are watching the assignee of the bug.
[PULL] drm/tegra: Changes for v3.13-rc1
On Mon, Nov 04, 2013 at 11:22:53AM +0100, Daniel Vetter wrote: > On Thu, Oct 31, 2013 at 10:17:28AM +0100, Thierry Reding wrote: [...] > > drm/tegra: Move subdevice infrastructure to host1x > > I've just shot at this patch on the m-l, but I'd be rather unhappy if the > new drm_bus madness this add gets into drm-next. Would be a definite step > backwards imo for the drm core. Also more work for me to fix it all up ... In all fairness, the patches were posted for review a while back (4 weeks ago) and I had no idea any such rework was in place, much less that anybody else considered drm_bus to be a bad idea. Perhaps we could maintain a list of TODO items somewhere with notes as to what's currently being worked on. Maybe such a list already exists and I'm just not aware of it? It'd be unfortunate if this series can't be merged for 3.13. The patch you object to is early in the list and everything after it depends on it, so if that doesn't make it in, then none of the rest will make it either. I've also explained elsewhere that the only thing drm_bus related that this adds is a new define for DRIVER_BUS_HOST1X and an implementation of .set_busid. The former should be trivial to remove, while the latter is the only one that you've kept in the cleanup tree you've posted. Also I'd like to reassert my offer to help. While working on this I've actually came across various oddities myself, like how the bus type was completely unused, and had added them to my TODO list of things to look into later. I really appreciate the work you do, but I think we could use some more coordination to avoid conflicts such as these and perhaps share the load of cleanup work. Is there anything in particular that I could do to help improve the situation? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/3a373e03/attachment.pgp>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Mon, Nov 4, 2013 at 5:10 AM, Thierry Reding wrote: > On Tue, Oct 29, 2013 at 05:29:55PM -0400, Rob Clark wrote: >> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa >> wrote: > [...] >> > I believe this is a huge step backwards from current kernel design >> > standards, which prefer modularity. >> >> But it makes things behave in the way that userspace expects, which is >> more important. > > Why would userspace care about the modularity of kernel drivers? The > only thing that userspace should care about is whether there's a DRM > device or not. How the kernel makes that happen should be completely > irrelevant to userspace. What I was referring to was userspace not expecting parts of the drm (crtcs/encoders/connectors) driver to show up incrementally. You can avoid that, but it is more of a hassle currently (ie. most drivers that need to do this, including a few that I've written, end up needing some form of stuff-devices-in-global-variables-that-main-driver-checks-for). BR, -R > Thierry
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Mon, Nov 04, 2013 at 07:14:27AM -0500, Rob Clark wrote: > On Mon, Nov 4, 2013 at 5:10 AM, Thierry Reding > wrote: > > On Tue, Oct 29, 2013 at 05:29:55PM -0400, Rob Clark wrote: > >> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa > >> wrote: > > [...] > >> > I believe this is a huge step backwards from current kernel design > >> > standards, which prefer modularity. > >> > >> But it makes things behave in the way that userspace expects, which is > >> more important. > > > > Why would userspace care about the modularity of kernel drivers? The > > only thing that userspace should care about is whether there's a DRM > > device or not. How the kernel makes that happen should be completely > > irrelevant to userspace. > > What I was referring to was userspace not expecting parts of the drm > (crtcs/encoders/connectors) driver to show up incrementally. You can > avoid that, but it is more of a hassle currently (ie. most drivers > that need to do this, including a few that I've written, end up > needing some form of > stuff-devices-in-global-variables-that-main-driver-checks-for). I must have misunderstood then. I don't think adding hotplug of DRM subdevices is something we would want. And I don't think there's a requirement for that, either. Embedded devices usually have well-defined use-cases, so the configuration is rather static at runtime. As for the global variables, you can do it properly. Granted, it might be more work than global variables, but keeping drivers separated does have advantages. Especially when the devices have completely separated register ranges or clocks or other resources, it's very natural to use one driver per device and glue them together with a composite device construct. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/c42c2f1c/attachment-0001.pgp>
[PATCH 1/2] drm/ttm: Enable the dma page pool also for intel IOMMUs
Used by the vmwgfx driver
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/ttm/Makefile |6 +-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |3 +++
include/drm/ttm/ttm_page_alloc.h | 11 ++-
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index b2b33dd..b433b9f 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -5,10 +5,6 @@ ccflags-y := -Iinclude/drm
ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
- ttm_bo_manager.o
-
-ifeq ($(CONFIG_SWIOTLB),y)
-ttm-y += ttm_page_alloc_dma.o
-endif
+ ttm_bo_manager.o ttm_page_alloc_dma.o
obj-$(CONFIG_DRM_TTM) += ttm.o
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 7957bee..fb8259f 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -33,6 +33,7 @@
* when freed).
*/
+#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
#define pr_fmt(fmt) "[TTM] " fmt
#include
@@ -1142,3 +1143,5 @@ int ttm_dma_page_alloc_debugfs(struct seq_file *m, void
*data)
return 0;
}
EXPORT_SYMBOL_GPL(ttm_dma_page_alloc_debugfs);
+
+#endif
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 706b962..d1f61bf 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -62,7 +62,7 @@ extern void ttm_pool_unpopulate(struct ttm_tt *ttm);
extern int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
-#ifdef CONFIG_SWIOTLB
+#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
/**
* Initialize pool allocator.
*/
@@ -94,6 +94,15 @@ static inline int ttm_dma_page_alloc_debugfs(struct seq_file
*m, void *data)
{
return 0;
}
+static inline int ttm_dma_populate(struct ttm_dma_tt *ttm_dma,
+ struct device *dev)
+{
+ return -ENOMEM;
+}
+static inline void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
+ struct device *dev)
+{
+}
#endif
#endif
--
1.7.10.4
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/2] Make the vmwgfx driver reasonably DMA-API compliant
These patches makes the vmwgfx driver use the DMA API to obtain valid device addresses rather than blindly using physical addresses. The main motivation is to be able to use a virtual IOMMU in the future. Other TTM drivers typically map pages one by one rather than using a scatter-gather list, but since we can benefit from having a single dma address region set up by the IOMMU, we use a scatter-gather list instead. Finally to be able to handle all the dma mapping modes, we locally extend the scatter-gather list page iterator to handle also the direct physical- and coherent cases. Finally, the TTM DMA page pool is enabled also when the Intel IOMMU is active -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/vmwgfx: Use the linux DMA api to get valid device addresses of pages
The code handles three different cases:
1) physical page addresses. The ttm page array is used.
2) DMA subsystem addresses. A scatter-gather list is used.
3) Coherent pages. The ttm dma pool is used, together with the dma_ttm
array os dma_addr_t
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 379 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 87 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 98 -
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c| 150 ++---
4 files changed, 620 insertions(+), 94 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
index 96dc84d..7776e6f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
@@ -141,37 +141,374 @@ struct ttm_placement vmw_srf_placement = {
};
struct vmw_ttm_tt {
- struct ttm_tt ttm;
+ struct ttm_dma_tt dma_ttm;
struct vmw_private *dev_priv;
int gmr_id;
+ struct sg_table sgt;
+ struct vmw_sg_table vsgt;
+ uint64_t sg_alloc_size;
+ bool mapped;
};
+/**
+ * Helper functions to advance a struct vmw_piter iterator.
+ *
+ * @viter: Pointer to the iterator.
+ *
+ * These functions return false if past the end of the list,
+ * true otherwise. Functions are selected depending on the current
+ * DMA mapping mode.
+ */
+static bool __vmw_piter_non_sg_next(struct vmw_piter *viter)
+{
+ return ++(viter->i) < viter->num_pages;
+}
+
+static bool __vmw_piter_sg_next(struct vmw_piter *viter)
+{
+ return __sg_page_iter_next(&viter->iter);
+}
+
+
+/**
+ * Helper functions to return a pointer to the current page.
+ *
+ * @viter: Pointer to the iterator
+ *
+ * These functions return a pointer to the page currently
+ * pointed to by @viter. Functions are selected depending on the
+ * current mapping mode.
+ */
+static struct page *__vmw_piter_non_sg_page(struct vmw_piter *viter)
+{
+ return viter->pages[viter->i];
+}
+
+static struct page *__vmw_piter_sg_page(struct vmw_piter *viter)
+{
+ return sg_page_iter_page(&viter->iter);
+}
+
+
+/**
+ * Helper functions to return the DMA address of the current page.
+ *
+ * @viter: Pointer to the iterator
+ *
+ * These functions return the DMA address of the page currently
+ * pointed to by @viter. Functions are selected depending on the
+ * current mapping mode.
+ */
+static dma_addr_t __vmw_piter_phys_addr(struct vmw_piter *viter)
+{
+ return page_to_phys(viter->pages[viter->i]);
+}
+
+static dma_addr_t __vmw_piter_dma_addr(struct vmw_piter *viter)
+{
+ return viter->addrs[viter->i];
+}
+
+static dma_addr_t __vmw_piter_sg_addr(struct vmw_piter *viter)
+{
+ return sg_page_iter_dma_address(&viter->iter);
+}
+
+
+/**
+ * vmw_piter_start - Initialize a struct vmw_piter.
+ *
+ * @viter: Pointer to the iterator to initialize
+ * @vsgt: Pointer to a struct vmw_sg_table to initialize from
+ *
+ * Note that we're following the convention of __sg_page_iter_start, so that
+ * the iterator doesn't point to a valid page after initialization; it has
+ * to be advanced one step first.
+ */
+void vmw_piter_start(struct vmw_piter *viter, const struct vmw_sg_table *vsgt,
+unsigned long p_offset)
+{
+ viter->i = p_offset - 1;
+ viter->num_pages = vsgt->num_pages;
+ switch (vsgt->mode) {
+ case vmw_dma_phys:
+ viter->next = &__vmw_piter_non_sg_next;
+ viter->dma_address = &__vmw_piter_phys_addr;
+ viter->page = &__vmw_piter_non_sg_page;
+ viter->pages = vsgt->pages;
+ break;
+ case vmw_dma_alloc_coherent:
+ viter->next = &__vmw_piter_non_sg_next;
+ viter->dma_address = &__vmw_piter_dma_addr;
+ viter->page = &__vmw_piter_non_sg_page;
+ viter->addrs = vsgt->addrs;
+ break;
+ case vmw_dma_map_populate:
+ case vmw_dma_map_bind:
+ viter->next = &__vmw_piter_sg_next;
+ viter->dma_address = &__vmw_piter_sg_addr;
+ viter->page = &__vmw_piter_sg_page;
+ __sg_page_iter_start(&viter->iter, vsgt->sgt->sgl,
+vsgt->sgt->orig_nents, p_offset);
+ break;
+ default:
+ BUG();
+ }
+}
+
+/**
+ * vmw_ttm_unmap_from_dma - unmap device addresses previsouly mapped for
+ * TTM pages
+ *
+ * @vmw_tt: Pointer to a struct vmw_ttm_backend
+ *
+ * Used to free dma mappings previously mapped by vmw_ttm_map_for_dma.
+ */
+static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
+{
+ struct device *dev = vmw_tt->dev_priv->dev->dev;
+
+ dma_unmap_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.nents,
+ DMA_BIDIRECTIONAL);
+ vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
+}
+
+/**
+ * vmw_ttm_map_for_dma - map TTM pages to get device addres
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #153 from Alex Deucher --- (In reply to comment #151) > I respect all the good work what has been done in the past for the AMD > driver. > But probably they have no hd3XXX card to test the driver. I would pay 20? > for getting them a card... I've got quite a few r6xx cards, however, all of the cards I have access to work fine with dpm. Unfortunately, r6xx cards are five generations old, so it's much harder to find people that remember or documents describing the details and quirks of dpm on these asics so even if I managed to get a problematic card, I'm not sure how much luck I'd have. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/99aa34d0/attachment.html>
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #45 from Alex Deucher --- (In reply to Tobias Droste from comment #44) > I see you want to enable DPM by default. Are there any news on this one? > Should I (we) try the drm-next branch to see if it is fixed? It's still an > issue on the drm-fixes branch from airlied. I don't know of any changes that would affect this. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64475] Slow work and no brightness adjustment in Euro Track Simulator II game with HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64475 Alex Deucher changed: What|Removed |Added CC||step2back+freedesktop at gmail ||.com --- Comment #5 from Alex Deucher --- *** Bug 71156 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/9e49f8c1/attachment.html>
[Bug 71156] [radeonsi] [r600g] Euro Truck Simulator 2 wrong color
https://bugs.freedesktop.org/show_bug.cgi?id=71156 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 64475 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/9a8adc05/attachment.html>
[Bug 69372] Render issues in some GTK widgets with Mesa 9+ RadeonSI drivers
https://bugs.freedesktop.org/show_bug.cgi?id=69372 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Alex Deucher --- I think this patch fixed the issue: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=0c921edf0162fed616cea9d02e168b719243bcd2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/8b2e7f49/attachment.html>
[Bug 71067] [drm:r600] UVD not responding OR failed testing IB on GFX ring
https://bugs.freedesktop.org/show_bug.cgi?id=71067 --- Comment #7 from Alex Deucher --- (In reply to comment #6) > Created attachment 88581 [details] > dmesg log - boot then freeze at random > > I managed to boot another time with modesetting enabled, but it quickly > froze. > > So far, every single new attempts to boot in Windows 7 have failed with a > BSOD . > > What's your take on this? Could it be hardware failure? Could be. Does powering down completely between booting different OSes help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/8e67d2f7/attachment.html>
[Bug 71067] [drm:r600] UVD not responding OR failed testing IB on GFX ring
https://bugs.freedesktop.org/show_bug.cgi?id=71067 --- Comment #8 from Christian K?nig --- >nov. 02 09:16:44 leviathan kernel: Memory corruption detected in low memory And directly after that the GPU gets into a reset loop. That indeed sounds like the system is somewhat broken. Please also try 3.12, but I would rather advise to replace the hardware. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/3ca61ec7/attachment-0001.html>
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Mon, Nov 4, 2013 at 6:30 AM, Inki Dae wrote:
> 2013/11/4 Thierry Reding :
>> On Tue, Oct 29, 2013 at 08:46:03PM -0700, St?phane Marchesin wrote:
>>> On Tue, Oct 29, 2013 at 1:50 PM, Tomasz Figa
>>> wrote:
>>>
>>> > Hi Sean,
>>> >
>>> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
>>> > > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
>>> > wrote:
>>> > > > Hi,
>>> > > >
>>> > > > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
>>> > > >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie
>>> > wrote:
>>> > > >> > I think we need to start considering a framework where
>>> > > >> > subdrivers
>>> > > >> > just
>>> > > >> > add drm objects themselves, then the toplevel node is
>>> > > >> > responsible
>>> > > >> > for
>>> > > >> > knowing that everything for the current configuration is
>>> > > >> > loaded.
>>> > > >>
>>> > > >> It would be nice to specify the various pieces in dt, then have
>>> > > >> some
>>> > > >> type of drm notifier to the toplevel node when everything has
>>> > > >> been
>>> > > >> probed. Doing it in the dt would allow standalone
>>> > > >> drm_bridge/drm_panel
>>> > > >> drivers to be transparent as far as the device's drm driver is
>>> > > >> concerned.
>>> > > >>
>>> > > >> Sean
>>> > > >>
>>> > > >> > I realise we may need to make changes to the core drm to allow
>>> > > >> > this
>>> > > >> > but we should probably start to create a strategy for fixing
>>> > > >> > the
>>> > > >> > API
>>> > > >> > issues that this throws up.
>>> > > >> >
>>> > > >> > Note I'm not yet advocating for dynamic addition of nodes once
>>> > > >> > the
>>> > > >> > device is in use, or removing them.
>>> > > >> >>>
>>> > > >> >>> I do wonder if we had some sort of tag in the device tree for any
>>> > > >> >>> nodes
>>> > > >> >>> involved in the display, and the core drm layer would read that
>>> > > >> >>> list,
>>> > > >> >>> and when every driver registers tick things off, and when the
>>> > > >> >>> last
>>> > > >> >>> one
>>> > > >> >>> joins we get a callback and init the drm layer, we'd of course
>>> > > >> >>> have
>>> > > >> >>> the
>>> > > >> >>> basic drm layer setup prior to that so we can add the objects as
>>> > > >> >>> the
>>> > > >> >>> drivers load. It might make development a bit trickier as you'd
>>> > > >> >>> need
>>> > > >> >>> to make sure someone claimed ownership of all the bits for init
>>> > > >> >>> to
>>> > > >> >>> proceed.>>
>>> > > >> >>
>>> > > >> >> Yeah, that's basically what the strawman looked like in my head.
>>> > > >> >>
>>> > > >> >> Instead of a property in each node, I was thinking of having a
>>> > > >> >> separate gfx pipe nodes that would have dt pointers to the various
>>> > > >> >> pieces involved in that pipe. This would allow us to associate
>>> > > >> >> standalone entities like bridges and panels with encoders in dt
>>> > > >> >> w/o
>>> > > >> >> doing it in the drm code. I *think* this should be Ok with the dt
>>> > > >> >> guys
>>> > > >> >> since it is still describing the hardware, but I think we'd have
>>> > > >> >> to
>>> > > >> >> make sure it wasn't drm-specific.
>>> > > >> >
>>> > > >> > I suppose the question is how much dynamic pipeline construction
>>> > > >> > there
>>> > > >> > is,
>>> > > >> >
>>> > > >> > even on things like radeon and i915 we have dynamic clock generator
>>> > > >> > to
>>> > > >> > crtc to encoder setups, so I worry about static lists per-pipe, so
>>> > > >> > I
>>> > > >> > still think just stating all these devices are needed for display
>>> > > >> > and
>>> > > >> > a list of valid interconnections between them, then we can have the
>>> > > >> > generic code model drm crtc/encoders/connectors on that list, and
>>> > > >> > construct the possible_crtcs /possible_clones etc at that stage.
>>> > > >>
>>> > > >> I'm, without excuse, hopeless at devicetree, so there are probably
>>> > > >> some violations, but something like:
>>> > > >>
>>> > > >> display-pipelines {
>>> > > >>
>>> > > >> required-elements = <&bridge-a &panel-a &encoder-x &encoder-y
>>> > > >>
>>> > > >> &crtc-x &crtc-y>;
>>> > > >>
>>> > > >> pipe1 {
>>> > > >>
>>> > > >> bridge = <&bridge-a>;
>>> > > >> encoder = <&encoder-x>;
>>> > > >> crtc = <&crtc-y>;
>>> > > >>
>>> > > >> };
>>> > > >> pipe2 {
>>> > > >>
>>> > > >> encoder = <&encoder-x>;
>>> > > >> crtc = <&crtc-x>;
>>> > > >>
>>> > > >> };
>>> > > >> pipe3 {
>>> > > >>
>>> > > >> panel = <&panel-a>;
>>> > > >> encoder = <&encoder-y>;
>>> > > >> crtc = <&crtc-y>;
>>> > > >>
>>> > > >> };
>>> > > >>
>>> > > >> };
>>> > > >>
>>> > > >> I'm tempted to add connector to the pipe nodes as well, so it's
>>> > > >> obvious which connector should be used in cases where multiple
>>> > > >> entities in the pipe implement drm_connector. However, I'm not sure
>>> > > >> if
>>> > > >> that would be NACKed by d
[PATCH v2 13/27] drm/tegra: Move subdevice infrastructure to host1x
On Mon, Nov 04, 2013 at 12:06:57PM +0100, Thierry Reding wrote:
> On Mon, Nov 04, 2013 at 11:20:55AM +0100, Daniel Vetter wrote:
> > On Mon, Oct 07, 2013 at 10:34:30AM +0200, Thierry Reding wrote:
> > > +static struct drm_bus drm_host1x_bus = {
> > > + .bus_type = DRIVER_BUS_HOST1X,
> > > + .set_busid = drm_host1x_set_busid,
> > > +};
> >
> > Imo this needs to die asap, i.e. before it lands in drm-next. I've just
> > spent a bit of time trying to rid ourselves of this midlayer
> > brain-damange, and now new stuff crops up. See
> >
> > http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-init-cleanup
> >
> > drm_bus is a terribly midlayer madness disaster and needs to just burn
> > down. So what exactly is the reason here to not go with the drm_platform.c
> > stuff until I've gotten around to completely rip it all out?
>
> Dave asked me whether it was possible to move the Tegra DRM driver back
> into drivers/gpu/drm (from drivers/gpu/host1x/drm) and introducing this
> new bus was the only solution I saw (besides perhaps using cross-
> subsystem global variables) to do that.
>
> Now, I'm not a big fan at all of the whole drm_bus shebang myself, so
> whatever help you need in getting rid of it, please let me know. The
> drm_bus implementation that this adds is about 34 lines, so it shouldn't
> be difficult to get rid of. If you throw out drm_driver.bus completely,
> then it should be a matter of just deleting that code and the rest
> should be able to continue working as is. The only reason I added it is
> because the kernel crashes if its not there, depending on what userspace
> is run.
Oh, so you actually need the bus->set_busid callback? Since that's one of
those old ugly dragons from the ums days and really shouldn't be used by
anything modern. E.g. rendernodes completely disallow it, and afaik the
x86 systems I have here also don't use it. So you've copy&pasted a piece
of lore that you _never_ should have used, and since I'm too late we now
have userspace that depends upon it :(
Aside: The reason we have drm_platform.c is to make the shadow-attach
possible that ums drm drivers needed. Luckily we've never merged an ARM
shadow-attaching ums drm driver, but unfortunately everyone just kept on
using the old crap without too much though.
If you just need to prevent the Oops (and please hunt down that piece of
userspace calling the setversion ioctl and figure out where it is, link to
sources highly appreciated) you can peek at drm_usb.c for the true noop
implementation. Would be great if you can figure this out before -rc1 - I
want to dump my current pile of patches onto Dave by then for 3.14.
Wrt the drm_put_dev in drm_host1x_exit I don't care one bit what you do in
your driver, as long as you call drm_put_dev directly ;-) It looks like
I'm lucky and can just drop the tegra patch as soon as your tree has
landed.
> So I find myself in the middle of controversy again... I seem to have a
> knack for it.
Looks like it's just a small one here ... you need to try harder.
Btw the longer-term plan is that you can embedd the struct drm_device into
whatever driver private struct is suitable and completely control it's
lifetime. That would allow us to ditch the drm_dev->usbdevice and
->platform_device pointers (killing dev->agp and dev->pdev is much harder
due to the big pile of legacy drives, but in principal not impossible for
someone with too much time).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
On Mon, Nov 04, 2013 at 01:52:33PM +0100, Thierry Reding wrote: > On Mon, Nov 04, 2013 at 07:14:27AM -0500, Rob Clark wrote: > > On Mon, Nov 4, 2013 at 5:10 AM, Thierry Reding > gmail.com> wrote: > > > On Tue, Oct 29, 2013 at 05:29:55PM -0400, Rob Clark wrote: > > >> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa > > >> wrote: > > > [...] > > >> > I believe this is a huge step backwards from current kernel design > > >> > standards, which prefer modularity. > > >> > > >> But it makes things behave in the way that userspace expects, which is > > >> more important. > > > > > > Why would userspace care about the modularity of kernel drivers? The > > > only thing that userspace should care about is whether there's a DRM > > > device or not. How the kernel makes that happen should be completely > > > irrelevant to userspace. > > > > What I was referring to was userspace not expecting parts of the drm > > (crtcs/encoders/connectors) driver to show up incrementally. You can > > avoid that, but it is more of a hassle currently (ie. most drivers > > that need to do this, including a few that I've written, end up > > needing some form of > > stuff-devices-in-global-variables-that-main-driver-checks-for). > > I must have misunderstood then. I don't think adding hotplug of DRM > subdevices is something we would want. And I don't think there's a > requirement for that, either. Embedded devices usually have well-defined > use-cases, so the configuration is rather static at runtime. > > As for the global variables, you can do it properly. Granted, it might > be more work than global variables, but keeping drivers separated does > have advantages. Especially when the devices have completely separated > register ranges or clocks or other resources, it's very natural to use > one driver per device and glue them together with a composite device > construct. I'm pretty short of ripping out all the midlayer disasters in the drm driver load path. As soon as that's done drivers can defer probing and do all kinds of trick until everything is set up, and then as the very last step register the drm device. Current wip stuff is at http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-init-cleanup Leftover todo items: - rip out bus->set_busid and block the setversion ioctl from doing stupid things on kms drivers. That's the last nail on the drm_bus coffin. - Convert udl over to embedding drm_device and driver-controlled setup sequence and rip out drm_dev->usbdevice as a proof of concept. That should be the death-spell to drm_usb.c I'll let you arm guys figure out how to the same for drm_platform.c ;-) On a quick look there's only very few drivers that use drm_dev->platform_device, which is the last piece to kill really. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so
https://bugs.freedesktop.org/show_bug.cgi?id=64810 --- Comment #31 from Rafael Castillo --- (In reply to comment #30) > Is this still an issue? > > (In reply to comment #29) > > I have a working memory saving patch but I am not authorised to publish it. > > What do you mean? yes is still an issue that Johannes Obermayr gave me a patch that fixed it but seems there is some issue with upstream and i don't have his autorization to publish the patch -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/76eedeab/attachment-0001.html>
[PULL] drm/tegra: Changes for v3.13-rc1
On Mon, Nov 04, 2013 at 01:11:46PM +0100, Thierry Reding wrote: > On Mon, Nov 04, 2013 at 11:22:53AM +0100, Daniel Vetter wrote: > > On Thu, Oct 31, 2013 at 10:17:28AM +0100, Thierry Reding wrote: > [...] > > > drm/tegra: Move subdevice infrastructure to host1x > > > > I've just shot at this patch on the m-l, but I'd be rather unhappy if the > > new drm_bus madness this add gets into drm-next. Would be a definite step > > backwards imo for the drm core. Also more work for me to fix it all up ... > > In all fairness, the patches were posted for review a while back (4 > weeks ago) and I had no idea any such rework was in place, much less > that anybody else considered drm_bus to be a bad idea. > > Perhaps we could maintain a list of TODO items somewhere with notes as > to what's currently being worked on. Maybe such a list already exists > and I'm just not aware of it? drm_bus goes back to the shadow attach horror stories of legacy drm drivers with ums. It was done for platform drivers due to some out-of-tree ARM drivers that luckily have never been merged. It's just part of the lore ;-) > It'd be unfortunate if this series can't be merged for 3.13. The patch > you object to is early in the list and everything after it depends on > it, so if that doesn't make it in, then none of the rest will make it > either. > > I've also explained elsewhere that the only thing drm_bus related that > this adds is a new define for DRIVER_BUS_HOST1X and an implementation of > .set_busid. The former should be trivial to remove, while the latter is > the only one that you've kept in the cleanup tree you've posted. It'll die soon, together with drm_bus. I've just grown a bit frustrated thinking that I'm too late at preventing old cruft from spreading ;-) > Also I'd like to reassert my offer to help. While working on this I've > actually came across various oddities myself, like how the bus type was > completely unused, and had added them to my TODO list of things to look > into later. After a bit of cooling of I've looked at the situation. See my reply to the patch itself, it should be easily fixed by just throwing a pretty tiny fixup patch on top. Then the host1x drm_bus is just a copy of the drm_bus, and so really easy to deal with. > I really appreciate the work you do, but I think we could use some more > coordination to avoid conflicts such as these and perhaps share the load > of cleanup work. Is there anything in particular that I could do to help > improve the situation? For better coordination I wonder whether we should have a drm-integration tree with all the driver wip stuff (lesser requirements than linux-next, so not just stuff ready for the next merge window) plus big cleanup branches like this and big features like the atomic modeset stuff rob is working on. But atm I'm still rather reluctant to try it out for fear of getting stuck with it ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFC 04/12] phy: Add simple-phy driver
Hi, On Friday 25 October 2013 01:21 PM, Tomasz Stanislawski wrote: > Hi, > Please refer to the comments below. > > On 10/24/2013 05:52 PM, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Monday 21 October 2013 07:48 PM, Tomasz Stanislawski wrote: >>> Add simple-phy driver to support a single register >>> PHY interfaces present on Exynos4 SoC. >> >> How are these PHY interfaces modelled in the SoC? Where does the register >> actually reside? > > Initially, I was planning to add PHY for HDMI_PHY register in > power management register set on s5pv310 soc. If that register is part of the power management register space, I don't think it justifies creating a PHY driver for it. > > However other PHYs use very similar interface (setting bit 0). > This includes DAC_PHY, ADC_PHY, PCIe_PHY, SATA_PHY. > Moreover it suits well to USBDEVICE_PHY, USBHOST_PHY. How is it currently being done for these drivers? Is it being done in the patches sent by Kamil or Vivek? Thanks Kishon
[PATCH 2/2] drm/vmwgfx: Use the linux DMA api to get valid device addresses of pages
On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote:
> The code handles three different cases:
> 1) physical page addresses. The ttm page array is used.
> 2) DMA subsystem addresses. A scatter-gather list is used.
> 3) Coherent pages. The ttm dma pool is used, together with the dma_ttm
> array os dma_addr_t
>
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Jakob Bornecrantz
For i915.ko use we've added page iterators which should walk the physical
backing storage.
commit a321e91b6d73ed011ffceed384c40d2785cf723b
Author: Imre Deak
Date: Wed Feb 27 17:02:56 2013 -0800
lib/scatterlist: add simple page iterator
Now we've unified all our backing storage handling around sg tables (even
for stolen memory), so maybe that's not useful for you guys. Just figured
I'll drop this here, it imo made our code look fairly tidy.
Cheers, Daniel
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 379
> ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 87 +++-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 98 -
> drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c| 150 ++---
> 4 files changed, 620 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> index 96dc84d..7776e6f 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> @@ -141,37 +141,374 @@ struct ttm_placement vmw_srf_placement = {
> };
>
> struct vmw_ttm_tt {
> - struct ttm_tt ttm;
> + struct ttm_dma_tt dma_ttm;
> struct vmw_private *dev_priv;
> int gmr_id;
> + struct sg_table sgt;
> + struct vmw_sg_table vsgt;
> + uint64_t sg_alloc_size;
> + bool mapped;
> };
>
> +/**
> + * Helper functions to advance a struct vmw_piter iterator.
> + *
> + * @viter: Pointer to the iterator.
> + *
> + * These functions return false if past the end of the list,
> + * true otherwise. Functions are selected depending on the current
> + * DMA mapping mode.
> + */
> +static bool __vmw_piter_non_sg_next(struct vmw_piter *viter)
> +{
> + return ++(viter->i) < viter->num_pages;
> +}
> +
> +static bool __vmw_piter_sg_next(struct vmw_piter *viter)
> +{
> + return __sg_page_iter_next(&viter->iter);
> +}
> +
> +
> +/**
> + * Helper functions to return a pointer to the current page.
> + *
> + * @viter: Pointer to the iterator
> + *
> + * These functions return a pointer to the page currently
> + * pointed to by @viter. Functions are selected depending on the
> + * current mapping mode.
> + */
> +static struct page *__vmw_piter_non_sg_page(struct vmw_piter *viter)
> +{
> + return viter->pages[viter->i];
> +}
> +
> +static struct page *__vmw_piter_sg_page(struct vmw_piter *viter)
> +{
> + return sg_page_iter_page(&viter->iter);
> +}
> +
> +
> +/**
> + * Helper functions to return the DMA address of the current page.
> + *
> + * @viter: Pointer to the iterator
> + *
> + * These functions return the DMA address of the page currently
> + * pointed to by @viter. Functions are selected depending on the
> + * current mapping mode.
> + */
> +static dma_addr_t __vmw_piter_phys_addr(struct vmw_piter *viter)
> +{
> + return page_to_phys(viter->pages[viter->i]);
> +}
> +
> +static dma_addr_t __vmw_piter_dma_addr(struct vmw_piter *viter)
> +{
> + return viter->addrs[viter->i];
> +}
> +
> +static dma_addr_t __vmw_piter_sg_addr(struct vmw_piter *viter)
> +{
> + return sg_page_iter_dma_address(&viter->iter);
> +}
> +
> +
> +/**
> + * vmw_piter_start - Initialize a struct vmw_piter.
> + *
> + * @viter: Pointer to the iterator to initialize
> + * @vsgt: Pointer to a struct vmw_sg_table to initialize from
> + *
> + * Note that we're following the convention of __sg_page_iter_start, so that
> + * the iterator doesn't point to a valid page after initialization; it has
> + * to be advanced one step first.
> + */
> +void vmw_piter_start(struct vmw_piter *viter, const struct vmw_sg_table
> *vsgt,
> + unsigned long p_offset)
> +{
> + viter->i = p_offset - 1;
> + viter->num_pages = vsgt->num_pages;
> + switch (vsgt->mode) {
> + case vmw_dma_phys:
> + viter->next = &__vmw_piter_non_sg_next;
> + viter->dma_address = &__vmw_piter_phys_addr;
> + viter->page = &__vmw_piter_non_sg_page;
> + viter->pages = vsgt->pages;
> + break;
> + case vmw_dma_alloc_coherent:
> + viter->next = &__vmw_piter_non_sg_next;
> + viter->dma_address = &__vmw_piter_dma_addr;
> + viter->page = &__vmw_piter_non_sg_page;
> + viter->addrs = vsgt->addrs;
> + break;
> + case vmw_dma_map_populate:
> + case vmw_dma_map_bind:
> + viter->next = &__vmw_piter_sg_next;
> + viter->dma_address = &__vmw_piter_sg_addr;
> + viter->page = &__vmw_piter_sg_page;
> + __sg_page_iter_start(&viter->iter,
[Bug 71226] New: Colors occasionally broken on DCE5 Barts (HD69xx)
https://bugs.freedesktop.org/show_bug.cgi?id=71226 Priority: medium Bug ID: 71226 Assignee: dri-devel at lists.freedesktop.org Summary: Colors occasionally broken on DCE5 Barts (HD69xx) Severity: normal Classification: Unclassified OS: All Reporter: zajec5 at gmail.com Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI >From time to time colors on my displays appear broken. It happens randomly and is pretty hard to reproduce. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/3c10ad44/attachment.html>
[Bug 71226] Colors occasionally broken on DCE5 Barts (HD69xx)
https://bugs.freedesktop.org/show_bug.cgi?id=71226 --- Comment #1 from Rafa? Mi?ecki --- Created attachment 88624 --> https://bugs.freedesktop.org/attachment.cgi?id=88624&action=edit Broken colors on HDMI-0 Right after xrandr --output HDMI-0 --auto -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/98fd4a50/attachment.html>
[Bug 71226] Colors occasionally broken on DCE5 Barts (HD69xx)
https://bugs.freedesktop.org/show_bug.cgi?id=71226 --- Comment #2 from Rafa? Mi?ecki --- Created attachment 88625 --> https://bugs.freedesktop.org/attachment.cgi?id=88625&action=edit Good colors on HDMI-0 After simple xrandr --output HDMI-0 --off xrandr --output HDMI-0 --auto routine from the broken case. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/8372e598/attachment.html>
[Bug 71226] Colors occasionally broken on DCE5 Barts (HD69xx)
https://bugs.freedesktop.org/show_bug.cgi?id=71226 --- Comment #3 from Rafa? Mi?ecki --- Created attachment 88626 --> https://bugs.freedesktop.org/attachment.cgi?id=88626&action=edit Broken colors on eDP After leaving perfectly working display for ~15 minutes, coming back and leaving screensaver I got that broken colors on panel display. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/ee5d659c/attachment.html>
[Bug 71226] Colors occasionally broken on DCE5 Barts (HD69xx)
https://bugs.freedesktop.org/show_bug.cgi?id=71226 --- Comment #4 from Rafa? Mi?ecki --- Created attachment 88627 --> https://bugs.freedesktop.org/attachment.cgi?id=88627&action=edit Good colors on eDP Reboot fixed colors on my panel. Usually waiting for some times also does (I don't remember if screensaver/power has to be involved). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/276f2784/attachment.html>
[PATCH 2/2] drm/vmwgfx: Use the linux DMA api to get valid device addresses of pages
On 11/04/2013 05:27 PM, Daniel Vetter wrote: > On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote: >> The code handles three different cases: >> 1) physical page addresses. The ttm page array is used. >> 2) DMA subsystem addresses. A scatter-gather list is used. >> 3) Coherent pages. The ttm dma pool is used, together with the dma_ttm >> array os dma_addr_t >> >> Signed-off-by: Thomas Hellstrom >> Reviewed-by: Jakob Bornecrantz > For i915.ko use we've added page iterators which should walk the physical > backing storage. > > commit a321e91b6d73ed011ffceed384c40d2785cf723b > Author: Imre Deak > Date: Wed Feb 27 17:02:56 2013 -0800 > > lib/scatterlist: add simple page iterator > > Yes, I saw those iterators, (nice stuff!) and my patch are using them as a "base class", handling also TTM page - and dma address arrays basically with the same interface. In the long run we might want to move ttm over to sg_tables as well. One problem, though, the page iterators break in the mapped case where sg_dma_len(sg) != sg_len(sg). An iommu implementation is allowed to reduce the sg list to a single segment, in which case those page iterators will fall apart. I was planning to see if I could fix that up, but unfortunately there is no generic dma_to_phys. It all works now because intel_iommu, amd_iommu and swiotlb all keep the number of entries in an sg list across mapping /Thomas -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/3] drm: drm_sysfs_connector_add() stuff
Most drivers don't appear to bother with checking drm_connector_sysfs_add() return value. That means the recent changes to drm_connector_sysfs_add() have left most drivers susceptible to oopsing on cleanup if drm_connector_sysfs_add() somehow failed. This series makes drm_connector_sysfs_remove() safe to call even if drm_connector_sysfs_add() failed. I also went a bit further and changed i915 to check the drm_connector_sysfs_add() return value. Not sure if we really want that patch now that the danger of oopsing is eliminated... Ville Syrj?l? (3): drm/sysfs: Remove stale comments about calling drm_sysfs_connector_add() multiple times drm/sysfs: Don't pollute connector->kdev if drm_connector_sysfs_add() fails drm/i915: Clean up if drm_sysfs_connector_add() fails drivers/gpu/drm/drm_sysfs.c | 49 --- drivers/gpu/drm/i915/intel_crt.c | 10 +++- drivers/gpu/drm/i915/intel_ddi.c | 5 +++- drivers/gpu/drm/i915/intel_dp.c | 6 - drivers/gpu/drm/i915/intel_drv.h | 2 +- drivers/gpu/drm/i915/intel_dsi.c | 9 ++- drivers/gpu/drm/i915/intel_dvo.c | 8 ++- drivers/gpu/drm/i915/intel_hdmi.c | 16 ++--- drivers/gpu/drm/i915/intel_lvds.c | 7 +- drivers/gpu/drm/i915/intel_sdvo.c | 36 ++-- drivers/gpu/drm/i915/intel_tv.c | 10 +++- 11 files changed, 116 insertions(+), 42 deletions(-)
[PATCH 1/3] drm/sysfs: Remove stale comments about calling drm_sysfs_connector_add() multiple times
From: Ville Syrj?l?
drm_connector_sysfs_add() explicitly checks if connector->kdev
is already populated and returns success. So it clearly now allows
being called multiple times. Remove some stale comments to the contrary.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_sysfs.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index db1c8f9..1a35ea5 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -366,11 +366,6 @@ static struct bin_attribute edid_attr = {
* properties (so far, connection status, dpms, mode list & edid) and
* generate a hotplug event so userspace knows there's a new connector
* available.
- *
- * Note:
- * This routine should only be called *once* for each registered connector.
- * A second call for an already registered connector will trigger the BUG_ON
- * below.
*/
int drm_sysfs_connector_add(struct drm_connector *connector)
{
@@ -383,7 +378,6 @@ int drm_sysfs_connector_add(struct drm_connector *connector)
if (connector->kdev)
return 0;
- /* We shouldn't get called more than once for the same connector */
connector->kdev = device_create(drm_class, dev->primary->kdev,
0, connector, "card%d-%s",
dev->primary->index,
drm_get_connector_name(connector));
--
1.8.1.5
[PATCH 2/3] drm/sysfs: Don't pollute connector->kdev if drm_connector_sysfs_add() fails
From: Ville Syrj?l?
Currently if drm_connector_sysfs_add() fails, it can leave connector->kdev
populated with an ERR_PTR value, or pointing to an already freed device.
Use a temporarary kdev pointer during drm_connector_sysfs_add(), and
only set connector->kdev if the function succeeds. This avoids oopsing
if drm_connector_sysfs_remove() gets called for a connector where
drm_connector_sysfs_add() previously failed.
Give drm_sysfs_device_add() the same treatment for the sake of
consistency.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_sysfs.c | 43 +--
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 1a35ea5..a82dc8b 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -370,6 +370,7 @@ static struct bin_attribute edid_attr = {
int drm_sysfs_connector_add(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
+ struct device *kdev;
int attr_cnt = 0;
int opt_cnt = 0;
int i;
@@ -378,22 +379,22 @@ int drm_sysfs_connector_add(struct drm_connector
*connector)
if (connector->kdev)
return 0;
- connector->kdev = device_create(drm_class, dev->primary->kdev,
- 0, connector, "card%d-%s",
- dev->primary->index,
drm_get_connector_name(connector));
+ kdev = device_create(drm_class, dev->primary->kdev,
+0, connector, "card%d-%s",
+dev->primary->index,
drm_get_connector_name(connector));
DRM_DEBUG("adding \"%s\" to sysfs\n",
drm_get_connector_name(connector));
- if (IS_ERR(connector->kdev)) {
- DRM_ERROR("failed to register connector device: %ld\n",
PTR_ERR(connector->kdev));
- ret = PTR_ERR(connector->kdev);
+ if (IS_ERR(kdev)) {
+ DRM_ERROR("failed to register connector device: %ld\n",
PTR_ERR(kdev));
+ ret = PTR_ERR(kdev);
goto out;
}
/* Standard attributes */
for (attr_cnt = 0; attr_cnt < ARRAY_SIZE(connector_attrs); attr_cnt++) {
- ret = device_create_file(connector->kdev,
&connector_attrs[attr_cnt]);
+ ret = device_create_file(kdev, &connector_attrs[attr_cnt]);
if (ret)
goto err_out_files;
}
@@ -410,7 +411,7 @@ int drm_sysfs_connector_add(struct drm_connector *connector)
case DRM_MODE_CONNECTOR_Component:
case DRM_MODE_CONNECTOR_TV:
for (opt_cnt = 0; opt_cnt <
ARRAY_SIZE(connector_attrs_opt1); opt_cnt++) {
- ret = device_create_file(connector->kdev,
&connector_attrs_opt1[opt_cnt]);
+ ret = device_create_file(kdev,
&connector_attrs_opt1[opt_cnt]);
if (ret)
goto err_out_files;
}
@@ -419,21 +420,23 @@ int drm_sysfs_connector_add(struct drm_connector
*connector)
break;
}
- ret = sysfs_create_bin_file(&connector->kdev->kobj, &edid_attr);
+ ret = sysfs_create_bin_file(&kdev->kobj, &edid_attr);
if (ret)
goto err_out_files;
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(dev);
+ connector->kdev = kdev;
+
return 0;
err_out_files:
for (i = 0; i < opt_cnt; i++)
- device_remove_file(connector->kdev, &connector_attrs_opt1[i]);
+ device_remove_file(kdev, &connector_attrs_opt1[i]);
for (i = 0; i < attr_cnt; i++)
- device_remove_file(connector->kdev, &connector_attrs[i]);
- device_unregister(connector->kdev);
+ device_remove_file(kdev, &connector_attrs[i]);
+ device_unregister(kdev);
out:
return ret;
@@ -501,6 +504,7 @@ EXPORT_SYMBOL(drm_sysfs_hotplug_event);
int drm_sysfs_device_add(struct drm_minor *minor)
{
char *minor_str;
+ struct device *kdev;
if (minor->type == DRM_MINOR_CONTROL)
minor_str = "controlD%d";
@@ -509,13 +513,16 @@ int drm_sysfs_device_add(struct drm_minor *minor)
else
minor_str = "card%d";
- minor->kdev = device_create(drm_class, minor->dev->dev,
- MKDEV(DRM_MAJOR, minor->index),
- minor, minor_str, minor->index);
- if (IS_ERR(minor->kdev)) {
- DRM_ERROR("device create failed %ld\n", PTR_ERR(minor->kdev));
- return PTR_ERR(minor->kdev);
+ kdev = device_create(drm_class, minor->dev->dev,
+MKDEV(DRM_MAJOR, minor->index),
+minor, minor_str, minor->index);
+
[PATCH 3/3] drm/i915: Clean up if drm_sysfs_connector_add() fails
From: Ville Syrj?l?
While we can now call drm_sysfs_connector_remove() even if
drm_connector_sysfs_add() failed, it would seem better for
the user to know that something went wrong. So instead of
ignoring drm_sysfs_connector_add() return value, checl it
and fail the whole connector registration.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_crt.c | 10 +-
drivers/gpu/drm/i915/intel_ddi.c | 5 -
drivers/gpu/drm/i915/intel_dp.c | 6 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_dsi.c | 9 -
drivers/gpu/drm/i915/intel_dvo.c | 8 +++-
drivers/gpu/drm/i915/intel_hdmi.c | 16 +---
drivers/gpu/drm/i915/intel_lvds.c | 7 ++-
drivers/gpu/drm/i915/intel_sdvo.c | 36 +---
drivers/gpu/drm/i915/intel_tv.c | 10 +-
10 files changed, 91 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 2e01bd3..be8a024 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -773,6 +773,7 @@ void intel_crt_init(struct drm_device *dev)
struct intel_crt *crt;
struct intel_connector *intel_connector;
struct drm_i915_private *dev_priv = dev->dev_private;
+ int error;
/* Skip machines without VGA that falsely report hotplug events */
if (dmi_check_system(intel_no_crt))
@@ -836,7 +837,14 @@ void intel_crt_init(struct drm_device *dev)
drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
- drm_sysfs_connector_add(connector);
+ error = drm_sysfs_connector_add(connector);
+ if (error) {
+ drm_encoder_cleanup(&crt->base.base);
+ drm_connector_cleanup(connector);
+ kfree(intel_connector);
+ kfree(crt);
+ return;
+ }
if (!I915_HAS_HOTPLUG(dev))
intel_connector->polled = DRM_CONNECTOR_POLL_CONNECT;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 31f4fe2..687e333 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1375,7 +1375,10 @@ intel_ddi_init_hdmi_connector(struct intel_digital_port
*intel_dig_port)
return NULL;
intel_dig_port->hdmi.hdmi_reg = DDI_BUF_CTL(port);
- intel_hdmi_init_connector(intel_dig_port, connector);
+ if (!intel_hdmi_init_connector(intel_dig_port, connector)) {
+ kfree(connector);
+ return NULL;
+ }
return connector;
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c8515bb..eb01be7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3603,7 +3603,11 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
ironlake_panel_vdd_work);
intel_connector_attach_encoder(intel_connector, intel_encoder);
- drm_sysfs_connector_add(connector);
+ error = drm_sysfs_connector_add(connector);
+ if (error) {
+ drm_connector_cleanup(connector);
+ return false;
+ }
if (HAS_DDI(dev))
intel_connector->get_hw_state =
intel_ddi_connector_get_hw_state;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9d2624f..a944d6e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -760,7 +760,7 @@ static inline void intel_fbdev_restore_mode(struct
drm_device *dev)
/* intel_hdmi.c */
void intel_hdmi_init(struct drm_device *dev, int hdmi_reg, enum port port);
-void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
+bool intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector);
struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
bool intel_hdmi_compute_config(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index d257b09..16684b5 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -535,6 +535,7 @@ bool intel_dsi_init(struct drm_device *dev)
struct drm_display_mode *fixed_mode = NULL;
const struct intel_dsi_device *dsi;
unsigned int i;
+ int error;
DRM_DEBUG_KMS("\n");
@@ -598,11 +599,17 @@ bool intel_dsi_init(struct drm_device *dev)
intel_connector_attach_encoder(intel_connector, intel_encoder);
- drm_sysfs_connector_add(connector);
+ error = drm_sysfs_connector_add(connector);
+ if (error) {
+ drm_connector_cleanup(connector);
+ goto err;
+ }
fixed_mode = dsi->dev_ops->get_modes(&intel_dsi->dev);
if (!fixed_mode) {
DRM_DEBUG_KMS("no fixed mode\n");
+ d
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #154 from Shawn Starr --- With the people getting hangs and GPU resets, with DPM on: are you using KDE or GNOME? I've noticed problems with KDE and the rv6xx and sometimes doing a soft power cycle of laptop will result in the display hanging when it attempts to set up kernel mode setting (KMS). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/e7c81d9f/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #155 from Paul Bodenbenner --- (In reply to comment #153) > I've got quite a few r6xx cards, however, all of the cards I have access to > work fine with dpm. Unfortunately, r6xx cards are five generations old, so > it's much harder to find people that remember or documents describing the > details and quirks of dpm on these asics so even if I managed to get a > problematic card, I'm not sure how much luck I'd have. Ok, thanks for the clarification! (In reply to comment #154) > With the people getting hangs and GPU resets, with DPM on: are you using KDE > or GNOME? > > I've noticed problems with KDE and the rv6xx and sometimes doing a soft > power cycle of laptop will result in the display hanging when it attempts to > set up kernel mode setting (KMS). I am not sure if there are also hangs, but I'm using GNOME Shell 3.10 by getting my previous described failures. Also I have to use "acpi_sleep=nonvs" as kernel parameter, otherwise system will reboot immediately instead of "trying" to wake up. With catalyst driver this worked well though. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/59c24edd/attachment.html>
[PATCH 0/2] Make the vmwgfx driver reasonably DMA-API compliant
On 11/04/2013 05:30 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Nov 04, 2013 at 05:57:37AM -0800, Thomas Hellstrom wrote: >> These patches makes the vmwgfx driver use the DMA API to obtain valid >> device addresses rather than blindly using physical addresses. >> >> The main motivation is to be able to use a virtual IOMMU in the future. > Ooooh. Neat! Are there any RFC patches available? > Nope, not yet. Thanks, Thomas -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/ttm: Enable the dma page pool also for intel IOMMUs
On 11/04/2013 05:34 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Nov 04, 2013 at 05:57:38AM -0800, Thomas Hellstrom wrote: >> Used by the vmwgfx driver > That looks OK to me. And baremetal should not be > affected as the Intel VT-d driver turns of the SWIOTLB > driver - so it will still use the classic ttm pool code. > > Reviewed-by: Konrad Rzeszutek Wilk > > Thanks for reviewing, Konrad. /Thomas -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/vmwgfx: Use the linux DMA api to get valid device addresses of pages
On 11/04/2013 05:40 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote: >> The code handles three different cases: >> 1) physical page addresses. The ttm page array is used. >> 2) DMA subsystem addresses. A scatter-gather list is used. >> 3) Coherent pages. The ttm dma pool is used, together with the dma_ttm >> array os dma_addr_t >> >> Signed-off-by: Thomas Hellstrom >> Reviewed-by: Jakob Bornecrantz > I looked at it from the TTM DMA perspective and it looks OK for me. > Great. Thanks, Thomas -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Mesa-dev] [PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2013 02:35 PM, Keith Packard wrote: > Kristian H?gsberg writes: > >> I sent a reply to the sourceforge addresses in the original >> emails, but I didn't see it show up in the archives. Trying >> again with the freedesktop addresses. > > (sorry for having an ancient shell script with sourceforge > addresses in it) > >>> +typedef uint32_t * +(*__DRIdri3Stamp)(__DRIdrawable >>> *drawable); >> >> This looks OK, as long as it's not tied into the xcb >> special_event semantics. From the way it's used, it looks like a >> loader can just increment this uint32_t when it needs to >> invalidate the buffer. Still seems like an odd API - a >> invalidate function would be simpler, but I'm guessing it's >> limited by what you can do if you receive the special event in a >> different thread. > > Yeah, I definitely do not want a callback function here. The API > was actually designed from the DRI2 side, not the xcb side as DRI2 > has this uint32_t already sitting there that just needed poking. > >> With those changes, we can reuse __DRIimage for DRI3 which makes >> a lot of sense. The GBM and Wayland backends already use >> __DRIimage for color buffers, but convert them to __DRI2buffer to >> be able to pass them into the DRI driver. Being able to pass a >> __DRIimage into the driver in getBuffers will simplify those >> backends, and it should be fairly simple to port them to the dri3 >> driver interface. > > Ok, so the first step would be to convert drivers from __DRI2buffer > to __DRIimage, at which point it should be trivial to use > __DRIimage to support DRI3? Or should I just take my existing > __DRI3buffer code and change that into a __DRIimage API and leave > the __DRI2buffer code around in the driver to support DRI2? I'd be in favor of the latter. > I'm game for either approach, but fixing the drivers to export a > single API that can support all of the window systems sure seems > like a better long-term plan... I'm not sure how we'd do that and maintain functionality between new libGL and old drivers (and vice versa). > ___ mesa-dev mailing > list mesa-dev at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) iEYEARECAAYFAlJ4Cu4ACgkQX1gOwKyEAw/F0ACfUI2NyxLo4t7LLxaiGsdv6QBD L48AnRfc347ZTiJmzhwvpdh+0Dd3sv0D =r+Kz -END PGP SIGNATURE-
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #156 from Sergey --- (In reply to comment #154) > With the people getting hangs and GPU resets, with DPM on: are you using KDE > or GNOME? > > I've noticed problems with KDE and the rv6xx and sometimes doing a soft > power cycle of laptop will result in the display hanging when it attempts to > set up kernel mode setting (KMS). I use Fluxbox and still see hand issue. Boot time hang is not likely to be related to DE, since it happens during KMS. Sometimes it hangs during ordinary work (video playing etc.), then it might recover but usually it don't. And you can see in dmesg that GPU was stuck. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/7364c500/attachment.html>
[Mesa3d-dev] [PATCH 3/6] dri/intel: Add explicit size parameter to intel_region_alloc_for_fd
On 10/31/2013 04:13 PM, Keith Packard wrote:
> Instead of assuming that the size will be height * pitch, have the caller pass
> in the size explicitly.
>
> Signed-off-by: Keith Packard
One nit below. With that changed,
Reviewed-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i915/intel_regions.c | 4 ++--
> src/mesa/drivers/dri/i915/intel_regions.h | 2 +-
> src/mesa/drivers/dri/i915/intel_screen.c | 2 +-
> src/mesa/drivers/dri/i965/intel_regions.c | 4 ++--
> src/mesa/drivers/dri/i965/intel_regions.h | 1 +
> src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
> 6 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i915/intel_regions.c
> b/src/mesa/drivers/dri/i915/intel_regions.c
> index 44f7030..9f5b89e 100644
> --- a/src/mesa/drivers/dri/i915/intel_regions.c
> +++ b/src/mesa/drivers/dri/i915/intel_regions.c
> @@ -209,6 +209,7 @@ struct intel_region *
> intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> + GLuint size,
>int fd, const char *name)
> {
> struct intel_region *region;
> @@ -216,8 +217,7 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
> int ret;
> uint32_t bit_6_swizzle, tiling;
>
> - buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr,
> - fd, height * pitch);
> + buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr, fd, size);
> if (buffer == NULL)
>return NULL;
> ret = drm_intel_bo_get_tiling(buffer, &tiling, &bit_6_swizzle);
> diff --git a/src/mesa/drivers/dri/i915/intel_regions.h
> b/src/mesa/drivers/dri/i915/intel_regions.h
> index 5c612a9..6bc4a42 100644
> --- a/src/mesa/drivers/dri/i915/intel_regions.h
> +++ b/src/mesa/drivers/dri/i915/intel_regions.h
> @@ -91,7 +91,7 @@ struct intel_region *
> intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> - int fd, const char *name);
> + GLuint size, int fd, const char *name);
>
> bool
> intel_region_flink(struct intel_region *region, uint32_t *name);
> diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
> b/src/mesa/drivers/dri/i915/intel_screen.c
> index 3f54752..085e894 100644
> --- a/src/mesa/drivers/dri/i915/intel_screen.c
> +++ b/src/mesa/drivers/dri/i915/intel_screen.c
> @@ -653,7 +653,7 @@ intel_create_image_from_fds(__DRIscreen *screen,
>return NULL;
>
> image->region = intel_region_alloc_for_fd(intelScreen,
> - 1, width, height,
> + 1, width, height, height *
> strides[0],
> strides[0], fds[0], "image");
> if (image->region == NULL) {
>free(image);
> diff --git a/src/mesa/drivers/dri/i965/intel_regions.c
> b/src/mesa/drivers/dri/i965/intel_regions.c
> index a6b80fd..3920f4f 100644
> --- a/src/mesa/drivers/dri/i965/intel_regions.c
> +++ b/src/mesa/drivers/dri/i965/intel_regions.c
> @@ -209,6 +209,7 @@ struct intel_region *
> intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> + GLuint size,
>int fd, const char *name)
> {
> struct intel_region *region;
> @@ -216,8 +217,7 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
> int ret;
> uint32_t bit_6_swizzle, tiling;
>
> - buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr,
> - fd, height * pitch);
> + buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr, fd, size);
> if (buffer == NULL)
>return NULL;
> ret = drm_intel_bo_get_tiling(buffer, &tiling, &bit_6_swizzle);
> diff --git a/src/mesa/drivers/dri/i965/intel_regions.h
> b/src/mesa/drivers/dri/i965/intel_regions.h
> index f08a113..05dfef3 100644
> --- a/src/mesa/drivers/dri/i965/intel_regions.h
> +++ b/src/mesa/drivers/dri/i965/intel_regions.h
> @@ -92,6 +92,7 @@ struct intel_region *
> intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> + GLuint size,
Since this isn't exposed to the GL API, use either unsigned or size_t.
>int fd, const char *name);
>
> bool
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index eafafa2..0bd0789 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -712,7 +712,7 @@ intel_create_image_from_fds(__DRIscreen *s
[PATCH 4/8] Define __DRI_IMAGE_FORMAT_SARGB8
This format will be used by the i965 driver
Signed-off-by: Keith Packard
---
include/GL/internal/dri_interface.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 48993b9..907aeca 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -996,6 +996,7 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_FORMAT_NONE 0x1008
#define __DRI_IMAGE_FORMAT_XRGB2101010 0x1009
#define __DRI_IMAGE_FORMAT_ARGB2101010 0x100a
+#define __DRI_IMAGE_FORMAT_SARGB8 0x100b
#define __DRI_IMAGE_USE_SHARE 0x0001
#define __DRI_IMAGE_USE_SCANOUT0x0002
--
1.8.4.2
[PATCH 1/8] drivers/dri/common: A few dri2 functions are not actually DRI2 specific
This just renames them so that they can be used with the DRI3 extension
without causing too much confusion.
Signed-off-by: Keith Packard
Reviewed-by: Kristian H?gsberg
---
src/mesa/drivers/dri/common/dri_util.c | 58 +-
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index c28b0fc..95c8b41 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -291,13 +291,13 @@ validate_context_version(__DRIscreen *screen,
/*@{*/
static __DRIcontext *
-dri2CreateContextAttribs(__DRIscreen *screen, int api,
-const __DRIconfig *config,
-__DRIcontext *shared,
-unsigned num_attribs,
-const uint32_t *attribs,
-unsigned *error,
-void *data)
+driCreateContextAttribs(__DRIscreen *screen, int api,
+const __DRIconfig *config,
+__DRIcontext *shared,
+unsigned num_attribs,
+const uint32_t *attribs,
+unsigned *error,
+void *data)
{
__DRIcontext *context;
const struct gl_config *modes = (config != NULL) ? &config->modes : NULL;
@@ -442,22 +442,22 @@ dri2CreateContextAttribs(__DRIscreen *screen, int api,
}
static __DRIcontext *
-dri2CreateNewContextForAPI(__DRIscreen *screen, int api,
- const __DRIconfig *config,
- __DRIcontext *shared, void *data)
+driCreateNewContextForAPI(__DRIscreen *screen, int api,
+ const __DRIconfig *config,
+ __DRIcontext *shared, void *data)
{
unsigned error;
-return dri2CreateContextAttribs(screen, api, config, shared, 0, NULL,
- &error, data);
+return driCreateContextAttribs(screen, api, config, shared, 0, NULL,
+ &error, data);
}
static __DRIcontext *
-dri2CreateNewContext(__DRIscreen *screen, const __DRIconfig *config,
- __DRIcontext *shared, void *data)
+driCreateNewContext(__DRIscreen *screen, const __DRIconfig *config,
+__DRIcontext *shared, void *data)
{
-return dri2CreateNewContextForAPI(screen, __DRI_API_OPENGL,
- config, shared, data);
+return driCreateNewContextForAPI(screen, __DRI_API_OPENGL,
+ config, shared, data);
}
/**
@@ -609,9 +609,9 @@ static void dri_put_drawable(__DRIdrawable *pdp)
}
static __DRIdrawable *
-dri2CreateNewDrawable(__DRIscreen *screen,
- const __DRIconfig *config,
- void *data)
+driCreateNewDrawable(__DRIscreen *screen,
+ const __DRIconfig *config,
+ void *data)
{
__DRIdrawable *pdraw;
@@ -698,7 +698,7 @@ dri2ConfigQueryf(__DRIscreen *screen, const char *var,
GLfloat *val)
}
static unsigned int
-dri2GetAPIMask(__DRIscreen *screen)
+driGetAPIMask(__DRIscreen *screen)
{
return screen->api_mask;
}
@@ -729,7 +729,7 @@ const __DRIcoreExtension driCoreExtension = {
.createNewDrawable = NULL,
.destroyDrawable= driDestroyDrawable,
.swapBuffers= driSwapBuffers, /* swrast */
-.createNewContext = dri2CreateNewContext, /* swrast */
+.createNewContext = driCreateNewContext, /* swrast */
.copyContext= driCopyContext,
.destroyContext = driDestroyContext,
.bindContext= driBindContext,
@@ -741,22 +741,22 @@ const __DRIdri2Extension driDRI2Extension = {
.base = { __DRI_DRI2, 4 },
.createNewScreen= dri2CreateNewScreen,
-.createNewDrawable = dri2CreateNewDrawable,
-.createNewContext = dri2CreateNewContext,
-.getAPIMask = dri2GetAPIMask,
-.createNewContextForAPI = dri2CreateNewContextForAPI,
+.createNewDrawable = driCreateNewDrawable,
+.createNewContext = driCreateNewContext,
+.getAPIMask = driGetAPIMask,
+.createNewContextForAPI = driCreateNewContextForAPI,
.allocateBuffer = dri2AllocateBuffer,
.releaseBuffer = dri2ReleaseBuffer,
-.createContextAttribs = dri2CreateContextAttribs,
+.createContextAttribs = driCreateContextAttribs,
.createNewScreen2 = dri2CreateNewScreen2,
};
const __DRIswrastExtension driSWRastExtension = {
{ __DRI_SWRAST, 4 },
driSWRastCreateNewScreen,
-dri2CreateNewDrawable,
-dri2CreateNewContextForAPI,
-dri2CreateContextAttribs,
+driCreateNewDrawable,
+driCreateNewContextForAPI,
+driCreateContextAttribs,
driSWRastCreateNewS
[PATCH 0/8] Add DRIimage-based DRI3/Present loader
This sequence first adds a a couple of new DRIimage extensions to the dri/common, dri/i915 and dri/i965 directories which define a loader-independent API for managing window system operations. The last patch adds a new DRI3000 loader using those new interfaces.
[PATCH 2/8] dri/intel: Split out DRI2 buffer update code to separate function
Make an easy place to splice in a DRI3 version of this function
Signed-off-by: Keith Packard
Reviewed-by: Kristian H?gsberg
---
src/mesa/drivers/dri/i915/intel_context.c | 90 +--
src/mesa/drivers/dri/i965/brw_context.c | 22 ++--
2 files changed, 68 insertions(+), 44 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_context.c
b/src/mesa/drivers/dri/i915/intel_context.c
index 2748514..1798bc7 100644
--- a/src/mesa/drivers/dri/i915/intel_context.c
+++ b/src/mesa/drivers/dri/i915/intel_context.c
@@ -133,15 +133,58 @@ intel_process_dri2_buffer(struct intel_context *intel,
struct intel_renderbuffer *rb,
const char *buffer_name);
-void
-intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
+static void
+intel_update_dri2_buffers(struct intel_context *intel, __DRIdrawable *drawable)
{
- struct gl_framebuffer *fb = drawable->driverPrivate;
- struct intel_renderbuffer *rb;
- struct intel_context *intel = context->driverPrivate;
__DRIbuffer *buffers = NULL;
int i, count;
const char *region_name;
+ struct intel_renderbuffer *rb;
+ struct gl_framebuffer *fb = drawable->driverPrivate;
+
+ intel_query_dri2_buffers(intel, drawable, &buffers, &count);
+
+ if (buffers == NULL)
+ return;
+
+ for (i = 0; i < count; i++) {
+ switch (buffers[i].attachment) {
+ case __DRI_BUFFER_FRONT_LEFT:
+ rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
+ region_name = "dri2 front buffer";
+ break;
+
+ case __DRI_BUFFER_FAKE_FRONT_LEFT:
+ rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
+ region_name = "dri2 fake front buffer";
+ break;
+
+ case __DRI_BUFFER_BACK_LEFT:
+ rb = intel_get_renderbuffer(fb, BUFFER_BACK_LEFT);
+ region_name = "dri2 back buffer";
+ break;
+
+ case __DRI_BUFFER_DEPTH:
+ case __DRI_BUFFER_HIZ:
+ case __DRI_BUFFER_DEPTH_STENCIL:
+ case __DRI_BUFFER_STENCIL:
+ case __DRI_BUFFER_ACCUM:
+ default:
+ fprintf(stderr,
+ "unhandled buffer attach event, attachment type %d\n",
+ buffers[i].attachment);
+ return;
+ }
+
+ intel_process_dri2_buffer(intel, drawable, &buffers[i], rb, region_name);
+ }
+}
+
+void
+intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
+{
+ struct intel_context *intel = context->driverPrivate;
+ __DRIscreen *screen = intel->intelScreen->driScrnPriv;
/* Set this up front, so that in case our buffers get invalidated
* while we're getting new buffers, we don't clobber the stamp and
@@ -151,42 +194,7 @@ intel_update_renderbuffers(__DRIcontext *context,
__DRIdrawable *drawable)
if (unlikely(INTEL_DEBUG & DEBUG_DRI))
fprintf(stderr, "enter %s, drawable %p\n", __func__, drawable);
- intel_query_dri2_buffers(intel, drawable, &buffers, &count);
-
- if (buffers == NULL)
- return;
-
- for (i = 0; i < count; i++) {
- switch (buffers[i].attachment) {
- case __DRI_BUFFER_FRONT_LEFT:
- rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
- region_name = "dri2 front buffer";
- break;
-
- case __DRI_BUFFER_FAKE_FRONT_LEFT:
- rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
- region_name = "dri2 fake front buffer";
- break;
-
- case __DRI_BUFFER_BACK_LEFT:
- rb = intel_get_renderbuffer(fb, BUFFER_BACK_LEFT);
- region_name = "dri2 back buffer";
- break;
-
- case __DRI_BUFFER_DEPTH:
- case __DRI_BUFFER_HIZ:
- case __DRI_BUFFER_DEPTH_STENCIL:
- case __DRI_BUFFER_STENCIL:
- case __DRI_BUFFER_ACCUM:
- default:
- fprintf(stderr,
- "unhandled buffer attach event, attachment type %d\n",
- buffers[i].attachment);
- return;
- }
-
- intel_process_dri2_buffer(intel, drawable, &buffers[i], rb,
region_name);
- }
+ intel_update_dri2_buffers(intel, drawable);
driUpdateFramebufferSize(&intel->ctx, drawable);
}
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 13569ad..2557d10 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -978,12 +978,11 @@ intel_process_dri2_buffer(struct brw_context *brw,
struct intel_renderbuffer *rb,
const char *buffer_name);
-void
-intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
+static void
+intel_update_dri2_buffers(struct brw_context *brw, __DRIdrawable *drawable)
{
struct gl_framebuffer *fb = drawable->driverPrivate;
struct intel_renderbuffer *rb;
- struct brw_context *brw = context->driverPrivate;
__DRIbuffer *buffers = NULL;
int i, count;
const char *region_name;
@@ -1033,6 +1032,23 @@ int
[PATCH 3/8] dri/intel: Add explicit size parameter to intel_region_alloc_for_fd
Instead of assuming that the size will be height * pitch, have the caller pass
in the size explicitly.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/i915/intel_regions.c | 4 ++--
src/mesa/drivers/dri/i915/intel_regions.h | 2 +-
src/mesa/drivers/dri/i915/intel_screen.c | 2 +-
src/mesa/drivers/dri/i965/intel_regions.c | 4 ++--
src/mesa/drivers/dri/i965/intel_regions.h | 1 +
src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
6 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_regions.c
b/src/mesa/drivers/dri/i915/intel_regions.c
index 44f7030..9f5b89e 100644
--- a/src/mesa/drivers/dri/i915/intel_regions.c
+++ b/src/mesa/drivers/dri/i915/intel_regions.c
@@ -209,6 +209,7 @@ struct intel_region *
intel_region_alloc_for_fd(struct intel_screen *screen,
GLuint cpp,
GLuint width, GLuint height, GLuint pitch,
+ GLuint size,
int fd, const char *name)
{
struct intel_region *region;
@@ -216,8 +217,7 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
int ret;
uint32_t bit_6_swizzle, tiling;
- buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr,
- fd, height * pitch);
+ buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr, fd, size);
if (buffer == NULL)
return NULL;
ret = drm_intel_bo_get_tiling(buffer, &tiling, &bit_6_swizzle);
diff --git a/src/mesa/drivers/dri/i915/intel_regions.h
b/src/mesa/drivers/dri/i915/intel_regions.h
index 5c612a9..6bc4a42 100644
--- a/src/mesa/drivers/dri/i915/intel_regions.h
+++ b/src/mesa/drivers/dri/i915/intel_regions.h
@@ -91,7 +91,7 @@ struct intel_region *
intel_region_alloc_for_fd(struct intel_screen *screen,
GLuint cpp,
GLuint width, GLuint height, GLuint pitch,
- int fd, const char *name);
+ GLuint size, int fd, const char *name);
bool
intel_region_flink(struct intel_region *region, uint32_t *name);
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 3f54752..085e894 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -653,7 +653,7 @@ intel_create_image_from_fds(__DRIscreen *screen,
return NULL;
image->region = intel_region_alloc_for_fd(intelScreen,
- 1, width, height,
+ 1, width, height, height *
strides[0],
strides[0], fds[0], "image");
if (image->region == NULL) {
free(image);
diff --git a/src/mesa/drivers/dri/i965/intel_regions.c
b/src/mesa/drivers/dri/i965/intel_regions.c
index a6b80fd..3920f4f 100644
--- a/src/mesa/drivers/dri/i965/intel_regions.c
+++ b/src/mesa/drivers/dri/i965/intel_regions.c
@@ -209,6 +209,7 @@ struct intel_region *
intel_region_alloc_for_fd(struct intel_screen *screen,
GLuint cpp,
GLuint width, GLuint height, GLuint pitch,
+ GLuint size,
int fd, const char *name)
{
struct intel_region *region;
@@ -216,8 +217,7 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
int ret;
uint32_t bit_6_swizzle, tiling;
- buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr,
- fd, height * pitch);
+ buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr, fd, size);
if (buffer == NULL)
return NULL;
ret = drm_intel_bo_get_tiling(buffer, &tiling, &bit_6_swizzle);
diff --git a/src/mesa/drivers/dri/i965/intel_regions.h
b/src/mesa/drivers/dri/i965/intel_regions.h
index f08a113..05dfef3 100644
--- a/src/mesa/drivers/dri/i965/intel_regions.h
+++ b/src/mesa/drivers/dri/i965/intel_regions.h
@@ -92,6 +92,7 @@ struct intel_region *
intel_region_alloc_for_fd(struct intel_screen *screen,
GLuint cpp,
GLuint width, GLuint height, GLuint pitch,
+ GLuint size,
int fd, const char *name);
bool
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index ce8124b..b89b1a5 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -718,7 +718,7 @@ intel_create_image_from_fds(__DRIscreen *screen,
return NULL;
image->region = intel_region_alloc_for_fd(intelScreen,
- 1, width, height,
+ 1, width, height, height *
strides[0],
strides[0], fds[0], "image");
if (image->region == NULL) {
free(image);
--
1.8.4.2
[PATCH 6/8] dri/i915, dri/i965: Use driGLFormatToImageFormat and driImageFormatToGLFormat
Remove private versions of these functions
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/i915/intel_screen.c | 53 ++-
src/mesa/drivers/dri/i965/intel_screen.c | 63 ++--
2 files changed, 8 insertions(+), 108 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 085e894..12113c7 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -244,32 +244,8 @@ intel_allocate_image(int dri_format, void *loaderPrivate)
image->dri_format = dri_format;
image->offset = 0;
-switch (dri_format) {
-case __DRI_IMAGE_FORMAT_RGB565:
- image->format = MESA_FORMAT_RGB565;
- break;
-case __DRI_IMAGE_FORMAT_XRGB:
- image->format = MESA_FORMAT_XRGB;
- break;
-case __DRI_IMAGE_FORMAT_ARGB:
- image->format = MESA_FORMAT_ARGB;
- break;
-case __DRI_IMAGE_FORMAT_ABGR:
- image->format = MESA_FORMAT_RGBA_REV;
- break;
-case __DRI_IMAGE_FORMAT_XBGR:
- image->format = MESA_FORMAT_RGBX_REV;
- break;
-case __DRI_IMAGE_FORMAT_R8:
- image->format = MESA_FORMAT_R8;
- break;
-case __DRI_IMAGE_FORMAT_GR88:
- image->format = MESA_FORMAT_GR88;
- break;
-case __DRI_IMAGE_FORMAT_NONE:
- image->format = MESA_FORMAT_NONE;
- break;
-default:
+image->format = driImageFormatToGLFormat(dri_format);
+if (image->format == 0) {
free(image);
return NULL;
}
@@ -318,27 +294,6 @@ intel_setup_image_from_dimensions(__DRIimage *image)
image->tile_y = 0;
}
-static inline uint32_t
-intel_dri_format(GLuint format)
-{
- switch (format) {
- case MESA_FORMAT_RGB565:
- return __DRI_IMAGE_FORMAT_RGB565;
- case MESA_FORMAT_XRGB:
- return __DRI_IMAGE_FORMAT_XRGB;
- case MESA_FORMAT_ARGB:
- return __DRI_IMAGE_FORMAT_ARGB;
- case MESA_FORMAT_RGBA_REV:
- return __DRI_IMAGE_FORMAT_ABGR;
- case MESA_FORMAT_R8:
- return __DRI_IMAGE_FORMAT_R8;
- case MESA_FORMAT_RG88:
- return __DRI_IMAGE_FORMAT_GR88;
- }
-
- return MESA_FORMAT_NONE;
-}
-
static __DRIimage *
intel_create_image_from_name(__DRIscreen *screen,
int width, int height, int format,
@@ -396,7 +351,7 @@ intel_create_image_from_renderbuffer(__DRIcontext *context,
image->data = loaderPrivate;
intel_region_reference(&image->region, irb->mt->region);
intel_setup_image_from_dimensions(image);
- image->dri_format = intel_dri_format(image->format);
+ image->dri_format = driGLFormatToImageFormat(image->format);
rb->NeedsFinishRenderTexture = true;
return image;
@@ -450,7 +405,7 @@ intel_create_image_from_texture(__DRIcontext *context, int
target,
image->format = obj->Image[face][level]->TexFormat;
image->data = loaderPrivate;
intel_setup_image_from_mipmap_tree(intel, image, iobj->mt, level, zoffset);
- image->dri_format = intel_dri_format(image->format);
+ image->dri_format = driGLFormatToImageFormat(image->format);
if (image->dri_format == MESA_FORMAT_NONE) {
*error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
free(image);
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index b89b1a5..f9339c1 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -298,38 +298,8 @@ intel_allocate_image(int dri_format, void *loaderPrivate)
image->dri_format = dri_format;
image->offset = 0;
-switch (dri_format) {
-case __DRI_IMAGE_FORMAT_RGB565:
- image->format = MESA_FORMAT_RGB565;
- break;
-case __DRI_IMAGE_FORMAT_XRGB:
- image->format = MESA_FORMAT_XRGB;
- break;
-case __DRI_IMAGE_FORMAT_ARGB2101010:
- image->format = MESA_FORMAT_ARGB2101010;
- break;
-case __DRI_IMAGE_FORMAT_XRGB2101010:
- image->format = MESA_FORMAT_XRGB2101010_UNORM;
- break;
-case __DRI_IMAGE_FORMAT_ARGB:
- image->format = MESA_FORMAT_ARGB;
- break;
-case __DRI_IMAGE_FORMAT_ABGR:
- image->format = MESA_FORMAT_RGBA_REV;
- break;
-case __DRI_IMAGE_FORMAT_XBGR:
- image->format = MESA_FORMAT_RGBX_REV;
- break;
-case __DRI_IMAGE_FORMAT_R8:
- image->format = MESA_FORMAT_R8;
- break;
-case __DRI_IMAGE_FORMAT_GR88:
- image->format = MESA_FORMAT_GR88;
- break;
-case __DRI_IMAGE_FORMAT_NONE:
- image->format = MESA_FORMAT_NONE;
- break;
-default:
+image->format = driImageFormatToGLFormat(dri_format);
+if (image->format == 0) {
free(image);
return NULL;
}
@@ -381,31 +351,6 @@ intel_setup_image_from_dimensions(__DRIimage *image)
image->has_depthstencil = false;
}
-static inline uint32_t
-intel_dri_format(GLuint format)
-
[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension
These provide an interface between the driver and the loader to allocate
color buffers through the DRIimage extension interface rather than through a
loader-specific extension (as is used by DRI2, for instance).
The driver uses the loader 'getBuffers' interface to allocate color buffers.
The loader uses the createNewScreen2, createNewDrawable, createNewContext,
getAPIMask and createContextAttribs APIS (mostly shared with DRI2).
This interface will work with the DRI3 loader, and should also work with GBM
and other loaders so that drivers need not be customized for each new loader
interface, as long as they provide this image interface.
Signed-off-by: Keith Packard
---
include/GL/internal/dri_interface.h | 112 +
src/mesa/drivers/dri/common/dri_util.c| 113 +
src/mesa/drivers/dri/common/dri_util.h| 6 ++
src/mesa/drivers/dri/i915/intel_context.c | 111 -
src/mesa/drivers/dri/i915/intel_mipmap_tree.c | 33
src/mesa/drivers/dri/i915/intel_mipmap_tree.h | 8 ++
src/mesa/drivers/dri/i915/intel_screen.c | 1 +
src/mesa/drivers/dri/i965/brw_context.c | 114 --
src/mesa/drivers/dri/i965/brw_context.h | 16 ++--
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 61 ++
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 8 ++
src/mesa/drivers/dri/i965/intel_screen.c | 5 +-
12 files changed, 568 insertions(+), 20 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 907aeca..8fc1fa6 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -86,6 +86,10 @@ typedef struct __DRIdri2LoaderExtensionRec
__DRIdri2LoaderExtension;
typedef struct __DRI2flushExtensionRec __DRI2flushExtension;
typedef struct __DRI2throttleExtensionRec __DRI2throttleExtension;
+
+typedef struct __DRIimageLoaderExtensionRec __DRIimageLoaderExtension;
+typedef struct __DRIimageDriverExtensionRec __DRIimageDriverExtension;
+
/*@}*/
@@ -1288,4 +1292,112 @@ typedef struct __DRIDriverVtableExtensionRec {
const struct __DriverAPIRec *vtable;
} __DRIDriverVtableExtension;
+/**
+ * Image Loader extension. Drivers use this to allocate color buffers
+ */
+
+#define __DRI_DRIVER_EXTENSIONS "__driDriverExtensions"
+
+enum __DRIimageBufferMask {
+ __DRI_IMAGE_BUFFER_BACK = (1 << 0),
+ __DRI_IMAGE_BUFFER_FRONT = (1 << 1)
+};
+
+struct __DRIimageList {
+ __DRIimage *back;
+ __DRIimage *front;
+};
+
+#define __DRI_IMAGE_LOADER "DRI_IMAGE_LOADER"
+#define __DRI_IMAGE_LOADER_VERSION 1
+
+struct __DRIimageLoaderExtensionRec {
+__DRIextension base;
+
+ /**
+* Allocate color buffers.
+*
+* \param driDrawable
+* \param width Width of allocated buffers
+* \param height Height of allocated buffers
+* \param format one of __DRI_IMAGE_FORMAT_*
+* \param stamp Address of variable to be updated when
+* getBuffers must be called again
+* \param loaderPrivate The loaderPrivate for driDrawable
+* \param buffer_maskSet of buffers to allocate
+* \param buffersReturned buffers
+*/
+ int (*getBuffers)(__DRIdrawable *driDrawable,
+ int *width, int *height,
+ unsigned int format,
+ uint32_t *stamp,
+ void *loaderPrivate,
+ uint32_t buffer_mask,
+ struct __DRIimageList *buffers);
+
+/**
+ * Flush pending front-buffer rendering
+ *
+ * Any rendering that has been performed to the
+ * fake front will be flushed to the front
+ *
+ * \param driDrawableDrawable whose front-buffer is to be flushed
+ * \param loaderPrivate Loader's private data that was previously passed
+ * into __DRIdri2ExtensionRec::createNewDrawable
+ */
+void (*flushFrontBuffer)(__DRIdrawable *driDrawable, void *loaderPrivate);
+};
+
+/**
+ * DRI extension.
+ */
+
+//struct gl_context;
+//struct dd_function_table;
+
+typedef __DRIscreen *
+(*__DRIcreateNewScreen2)(int screen, int fd,
+ const __DRIextension **extensions,
+ const __DRIextension **driver_extensions,
+ const __DRIconfig ***driver_configs,
+ void *loaderPrivate);
+
+typedef __DRIdrawable *
+(*__DRIcreateNewDrawable)(__DRIscreen *screen,
+ const __DRIconfig *config,
+ void *loaderPrivate);
+
+typedef __DRIcontext *
+(*__DRIcreateNewContext)(__DRIscreen *screen,
+ const __DRIconfig *config,
+ __DRIcontext *shared,
+ void *loaderPrivate);
+
+typedef __DRIcontext *
+(*__DRIcreateContextAttribs)(__DRIscr
[PATCH 8/8] Add DRI3+Present loader
Uses the __DRIimage loader interfaces. Signed-off-by: Keith Packard --- configure.ac | 12 +- src/glx/Makefile.am |2 + src/glx/dri3_common.c | 146 + src/glx/dri3_glx.c| 1722 + src/glx/dri3_priv.h | 199 ++ src/glx/glxclient.h |2 + src/glx/glxext.c |6 +- 7 files changed, 2085 insertions(+), 4 deletions(-) create mode 100644 src/glx/dri3_common.c create mode 100644 src/glx/dri3_glx.c create mode 100644 src/glx/dri3_priv.h diff --git a/configure.ac b/configure.ac index 0a25047..074368c 100644 --- a/configure.ac +++ b/configure.ac @@ -38,6 +38,9 @@ LIBDRM_NVVIEUX_REQUIRED=2.4.33 LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41" LIBDRM_FREEDRENO_REQUIRED=2.4.39 DRI2PROTO_REQUIRED=2.6 +DRI3PROTO_REQUIRED=1.0 +PRESENTPROTO_REQUIRED=1.0 +LIBUDEV_REQUIRED=151 GLPROTO_REQUIRED=1.4.14 LIBDRM_XORG_REQUIRED=2.4.24 LIBKMS_XORG_REQUIRED=1.0.0 @@ -820,10 +823,13 @@ xyesno) fi PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED]) GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED" +PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED]) +PKG_CHECK_MODULES([PRESENTPROTO], [presentproto >= $PRESENTPROTO_REQUIRED]) +PKG_CHECK_MODULES([LIBUDEV], [libudev >= $LIBUDEV_REQUIRED]) fi # find the DRI deps for libGL -dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2 >= 1.8" +dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2 >= 1.8 xcb-dri3 xcb-present xcb-sync xshmfence" # add xf86vidmode if available PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, HAVE_XF86VIDMODE=no) @@ -833,8 +839,8 @@ xyesno) PKG_CHECK_MODULES([DRIGL], [$dri_modules]) GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV $dri_modules" -X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS" -GL_LIB_DEPS="$DRIGL_LIBS" +X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS" +GL_LIB_DEPS="$DRIGL_LIBS $LIBUDEV_LIBS" # need DRM libs, $PTHREAD_LIBS, etc. GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS" diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am index f01709b..854025d 100644 --- a/src/glx/Makefile.am +++ b/src/glx/Makefile.am @@ -92,6 +92,8 @@ libglx_la_SOURCES = \ glxhash.c \ dri2_glx.c \ dri2.c \ + dri3_glx.c \ + dri3_common.c \ applegl_glx.c GL_LIBS = \ diff --git a/src/glx/dri3_common.c b/src/glx/dri3_common.c new file mode 100644 index 000..c758f96 --- /dev/null +++ b/src/glx/dri3_common.c @@ -0,0 +1,146 @@ +/* + * Copyright ? 2013 Keith Packard + * + * Permission to use, copy, modify, distribute, and sell this software and its + * documentation for any purpose is hereby granted without fee, provided that + * the above copyright notice appear in all copies and that both that copyright + * notice and this permission notice appear in supporting documentation, and + * that the name of the copyright holders not be used in advertising or + * publicity pertaining to distribution of the software without specific, + * written prior permission. The copyright holders make no representations + * about the suitability of this software for any purpose. It is provided "as + * is" without express or implied warranty. + * + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE + * OF THIS SOFTWARE. + */ + +/* + * This code is derived from src/egl/drivers/dri2/common.c which + * carries the following copyright: + * + * Copyright ? 2011 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OT
[PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_*
The __DRI_IMAGE_FORMAT codes are used by the image extension, drivers need to
be able to translate between them. Instead of duplicating this translation in
each driver, create a shared version.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/common/dri_util.c | 62 ++
src/mesa/drivers/dri/common/dri_util.h | 6
2 files changed, 68 insertions(+)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index 95c8b41..76c8ae5 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -792,3 +792,65 @@ driUpdateFramebufferSize(struct gl_context *ctx, const
__DRIdrawable *dPriv)
assert(fb->Height == dPriv->h);
}
}
+
+uint32_t
+driGLFormatToImageFormat(gl_format format)
+{
+ switch (format) {
+ case MESA_FORMAT_RGB565:
+ return __DRI_IMAGE_FORMAT_RGB565;
+ case MESA_FORMAT_XRGB:
+ return __DRI_IMAGE_FORMAT_XRGB;
+ case MESA_FORMAT_ARGB2101010:
+ return __DRI_IMAGE_FORMAT_ARGB2101010;
+ case MESA_FORMAT_XRGB2101010_UNORM:
+ return __DRI_IMAGE_FORMAT_XRGB2101010;
+ case MESA_FORMAT_ARGB:
+ return __DRI_IMAGE_FORMAT_ARGB;
+ case MESA_FORMAT_RGBA_REV:
+ return __DRI_IMAGE_FORMAT_ABGR;
+ case MESA_FORMAT_RGBX_REV:
+ return __DRI_IMAGE_FORMAT_XBGR;
+ case MESA_FORMAT_R8:
+ return __DRI_IMAGE_FORMAT_R8;
+ case MESA_FORMAT_GR88:
+ return __DRI_IMAGE_FORMAT_GR88;
+ case MESA_FORMAT_NONE:
+ return __DRI_IMAGE_FORMAT_NONE;
+ case MESA_FORMAT_SARGB8:
+ return __DRI_IMAGE_FORMAT_SARGB8;
+ default:
+ return 0;
+ }
+}
+
+gl_format
+driImageFormatToGLFormat(uint32_t image_format)
+{
+ switch (image_format) {
+ case __DRI_IMAGE_FORMAT_RGB565:
+ return MESA_FORMAT_RGB565;
+ case __DRI_IMAGE_FORMAT_XRGB:
+ return MESA_FORMAT_XRGB;
+ case __DRI_IMAGE_FORMAT_ARGB2101010:
+ return MESA_FORMAT_ARGB2101010;
+ case __DRI_IMAGE_FORMAT_XRGB2101010:
+ return MESA_FORMAT_XRGB2101010_UNORM;
+ case __DRI_IMAGE_FORMAT_ARGB:
+ return MESA_FORMAT_ARGB;
+ case __DRI_IMAGE_FORMAT_ABGR:
+ return MESA_FORMAT_RGBA_REV;
+ case __DRI_IMAGE_FORMAT_XBGR:
+ return MESA_FORMAT_RGBX_REV;
+ case __DRI_IMAGE_FORMAT_R8:
+ return MESA_FORMAT_R8;
+ case __DRI_IMAGE_FORMAT_GR88:
+ return MESA_FORMAT_GR88;
+ case __DRI_IMAGE_FORMAT_SARGB8:
+ return MESA_FORMAT_SARGB8;
+ case __DRI_IMAGE_FORMAT_NONE:
+ return MESA_FORMAT_NONE;
+ default:
+ return MESA_FORMAT_NONE;
+ }
+}
diff --git a/src/mesa/drivers/dri/common/dri_util.h
b/src/mesa/drivers/dri/common/dri_util.h
index 5b56061..fd40769 100644
--- a/src/mesa/drivers/dri/common/dri_util.h
+++ b/src/mesa/drivers/dri/common/dri_util.h
@@ -271,6 +271,12 @@ struct __DRIdrawableRec {
} dri2;
};
+extern uint32_t
+driGLFormatToImageFormat(gl_format format);
+
+extern gl_format
+driImageFormatToGLFormat(uint32_t image_format);
+
extern void
dri2InvalidateDrawable(__DRIdrawable *drawable);
--
1.8.4.2
[PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_*
Jordan Justen writes: > After patch 6, this will add SARGB8, right? So, maybe add this to the > commit message, or separate out adding SARGB8 into a separate commit? I added the SARGB8 define in patch 4; is there some other separation you think would be warranted? Oh, just so everyone knows -- krh and I chatted for a while this morning and decided that this whole __DRI_IMAGE_FORMAT_* stuff is just a bad idea and we should remove it all and just use __DRI_IMAGE_FOURCC_* everywhere. I didn't want to mix that change up with this series though. > Patches 1-6: Reviewed-by: Jordan Justen Thanks! -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/6f56960e/attachment.pgp>
[PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_*
On Mon, Nov 4, 2013 at 6:23 PM, Keith Packard wrote:
> The __DRI_IMAGE_FORMAT codes are used by the image extension, drivers need to
> be able to translate between them. Instead of duplicating this translation in
> each driver, create a shared version.
>
> Signed-off-by: Keith Packard
> ---
> src/mesa/drivers/dri/common/dri_util.c | 62
> ++
> src/mesa/drivers/dri/common/dri_util.h | 6
> 2 files changed, 68 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/common/dri_util.c
> b/src/mesa/drivers/dri/common/dri_util.c
> index 95c8b41..76c8ae5 100644
> --- a/src/mesa/drivers/dri/common/dri_util.c
> +++ b/src/mesa/drivers/dri/common/dri_util.c
> @@ -792,3 +792,65 @@ driUpdateFramebufferSize(struct gl_context *ctx, const
> __DRIdrawable *dPriv)
>assert(fb->Height == dPriv->h);
> }
> }
> +
> +uint32_t
> +driGLFormatToImageFormat(gl_format format)
> +{
> + switch (format) {
> + case MESA_FORMAT_RGB565:
> + return __DRI_IMAGE_FORMAT_RGB565;
> + case MESA_FORMAT_XRGB:
> + return __DRI_IMAGE_FORMAT_XRGB;
> + case MESA_FORMAT_ARGB2101010:
> + return __DRI_IMAGE_FORMAT_ARGB2101010;
> + case MESA_FORMAT_XRGB2101010_UNORM:
> + return __DRI_IMAGE_FORMAT_XRGB2101010;
> + case MESA_FORMAT_ARGB:
> + return __DRI_IMAGE_FORMAT_ARGB;
> + case MESA_FORMAT_RGBA_REV:
> + return __DRI_IMAGE_FORMAT_ABGR;
> + case MESA_FORMAT_RGBX_REV:
> + return __DRI_IMAGE_FORMAT_XBGR;
> + case MESA_FORMAT_R8:
> + return __DRI_IMAGE_FORMAT_R8;
> + case MESA_FORMAT_GR88:
> + return __DRI_IMAGE_FORMAT_GR88;
> + case MESA_FORMAT_NONE:
> + return __DRI_IMAGE_FORMAT_NONE;
> + case MESA_FORMAT_SARGB8:
> + return __DRI_IMAGE_FORMAT_SARGB8;
After patch 6, this will add SARGB8, right? So, maybe add this to the
commit message, or separate out adding SARGB8 into a separate commit?
Patches 1-6: Reviewed-by: Jordan Justen
-Jordan
> + default:
> + return 0;
> + }
> +}
> +
> +gl_format
> +driImageFormatToGLFormat(uint32_t image_format)
> +{
> + switch (image_format) {
> + case __DRI_IMAGE_FORMAT_RGB565:
> + return MESA_FORMAT_RGB565;
> + case __DRI_IMAGE_FORMAT_XRGB:
> + return MESA_FORMAT_XRGB;
> + case __DRI_IMAGE_FORMAT_ARGB2101010:
> + return MESA_FORMAT_ARGB2101010;
> + case __DRI_IMAGE_FORMAT_XRGB2101010:
> + return MESA_FORMAT_XRGB2101010_UNORM;
> + case __DRI_IMAGE_FORMAT_ARGB:
> + return MESA_FORMAT_ARGB;
> + case __DRI_IMAGE_FORMAT_ABGR:
> + return MESA_FORMAT_RGBA_REV;
> + case __DRI_IMAGE_FORMAT_XBGR:
> + return MESA_FORMAT_RGBX_REV;
> + case __DRI_IMAGE_FORMAT_R8:
> + return MESA_FORMAT_R8;
> + case __DRI_IMAGE_FORMAT_GR88:
> + return MESA_FORMAT_GR88;
> + case __DRI_IMAGE_FORMAT_SARGB8:
> + return MESA_FORMAT_SARGB8;
> + case __DRI_IMAGE_FORMAT_NONE:
> + return MESA_FORMAT_NONE;
> + default:
> + return MESA_FORMAT_NONE;
> + }
> +}
> diff --git a/src/mesa/drivers/dri/common/dri_util.h
> b/src/mesa/drivers/dri/common/dri_util.h
> index 5b56061..fd40769 100644
> --- a/src/mesa/drivers/dri/common/dri_util.h
> +++ b/src/mesa/drivers/dri/common/dri_util.h
> @@ -271,6 +271,12 @@ struct __DRIdrawableRec {
> } dri2;
> };
>
> +extern uint32_t
> +driGLFormatToImageFormat(gl_format format);
> +
> +extern gl_format
> +driImageFormatToGLFormat(uint32_t image_format);
> +
> extern void
> dri2InvalidateDrawable(__DRIdrawable *drawable);
>
> --
> 1.8.4.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/ttm: Enable the dma page pool also for intel IOMMUs
On Mon, Nov 04, 2013 at 05:57:38AM -0800, Thomas Hellstrom wrote:
> Used by the vmwgfx driver
That looks OK to me. And baremetal should not be
affected as the Intel VT-d driver turns of the SWIOTLB
driver - so it will still use the classic ttm pool code.
Reviewed-by: Konrad Rzeszutek Wilk
>
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Jakob Bornecrantz
> ---
> drivers/gpu/drm/ttm/Makefile |6 +-
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |3 +++
> include/drm/ttm/ttm_page_alloc.h | 11 ++-
> 3 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
> index b2b33dd..b433b9f 100644
> --- a/drivers/gpu/drm/ttm/Makefile
> +++ b/drivers/gpu/drm/ttm/Makefile
> @@ -5,10 +5,6 @@ ccflags-y := -Iinclude/drm
> ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
> ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
> ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
> - ttm_bo_manager.o
> -
> -ifeq ($(CONFIG_SWIOTLB),y)
> -ttm-y += ttm_page_alloc_dma.o
> -endif
> + ttm_bo_manager.o ttm_page_alloc_dma.o
>
> obj-$(CONFIG_DRM_TTM) += ttm.o
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index 7957bee..fb8259f 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -33,6 +33,7 @@
> * when freed).
> */
>
> +#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
> #define pr_fmt(fmt) "[TTM] " fmt
>
> #include
> @@ -1142,3 +1143,5 @@ int ttm_dma_page_alloc_debugfs(struct seq_file *m, void
> *data)
> return 0;
> }
> EXPORT_SYMBOL_GPL(ttm_dma_page_alloc_debugfs);
> +
> +#endif
> diff --git a/include/drm/ttm/ttm_page_alloc.h
> b/include/drm/ttm/ttm_page_alloc.h
> index 706b962..d1f61bf 100644
> --- a/include/drm/ttm/ttm_page_alloc.h
> +++ b/include/drm/ttm/ttm_page_alloc.h
> @@ -62,7 +62,7 @@ extern void ttm_pool_unpopulate(struct ttm_tt *ttm);
> extern int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
>
>
> -#ifdef CONFIG_SWIOTLB
> +#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
> /**
> * Initialize pool allocator.
> */
> @@ -94,6 +94,15 @@ static inline int ttm_dma_page_alloc_debugfs(struct
> seq_file *m, void *data)
> {
> return 0;
> }
> +static inline int ttm_dma_populate(struct ttm_dma_tt *ttm_dma,
> +struct device *dev)
> +{
> + return -ENOMEM;
> +}
> +static inline void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
> + struct device *dev)
> +{
> +}
> #endif
>
> #endif
> --
> 1.7.10.4
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/vmwgfx: Use the linux DMA api to get valid device addresses of pages
On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote:
> The code handles three different cases:
> 1) physical page addresses. The ttm page array is used.
> 2) DMA subsystem addresses. A scatter-gather list is used.
> 3) Coherent pages. The ttm dma pool is used, together with the dma_ttm
> array os dma_addr_t
>
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Jakob Bornecrantz
I looked at it from the TTM DMA perspective and it looks OK for me.
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 379
> ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 87 +++-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 98 -
> drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c| 150 ++---
> 4 files changed, 620 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> index 96dc84d..7776e6f 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> @@ -141,37 +141,374 @@ struct ttm_placement vmw_srf_placement = {
> };
>
> struct vmw_ttm_tt {
> - struct ttm_tt ttm;
> + struct ttm_dma_tt dma_ttm;
> struct vmw_private *dev_priv;
> int gmr_id;
> + struct sg_table sgt;
> + struct vmw_sg_table vsgt;
> + uint64_t sg_alloc_size;
> + bool mapped;
> };
>
> +/**
> + * Helper functions to advance a struct vmw_piter iterator.
> + *
> + * @viter: Pointer to the iterator.
> + *
> + * These functions return false if past the end of the list,
> + * true otherwise. Functions are selected depending on the current
> + * DMA mapping mode.
> + */
> +static bool __vmw_piter_non_sg_next(struct vmw_piter *viter)
> +{
> + return ++(viter->i) < viter->num_pages;
> +}
> +
> +static bool __vmw_piter_sg_next(struct vmw_piter *viter)
> +{
> + return __sg_page_iter_next(&viter->iter);
> +}
> +
> +
> +/**
> + * Helper functions to return a pointer to the current page.
> + *
> + * @viter: Pointer to the iterator
> + *
> + * These functions return a pointer to the page currently
> + * pointed to by @viter. Functions are selected depending on the
> + * current mapping mode.
> + */
> +static struct page *__vmw_piter_non_sg_page(struct vmw_piter *viter)
> +{
> + return viter->pages[viter->i];
> +}
> +
> +static struct page *__vmw_piter_sg_page(struct vmw_piter *viter)
> +{
> + return sg_page_iter_page(&viter->iter);
> +}
> +
> +
> +/**
> + * Helper functions to return the DMA address of the current page.
> + *
> + * @viter: Pointer to the iterator
> + *
> + * These functions return the DMA address of the page currently
> + * pointed to by @viter. Functions are selected depending on the
> + * current mapping mode.
> + */
> +static dma_addr_t __vmw_piter_phys_addr(struct vmw_piter *viter)
> +{
> + return page_to_phys(viter->pages[viter->i]);
> +}
> +
> +static dma_addr_t __vmw_piter_dma_addr(struct vmw_piter *viter)
> +{
> + return viter->addrs[viter->i];
> +}
> +
> +static dma_addr_t __vmw_piter_sg_addr(struct vmw_piter *viter)
> +{
> + return sg_page_iter_dma_address(&viter->iter);
> +}
> +
> +
> +/**
> + * vmw_piter_start - Initialize a struct vmw_piter.
> + *
> + * @viter: Pointer to the iterator to initialize
> + * @vsgt: Pointer to a struct vmw_sg_table to initialize from
> + *
> + * Note that we're following the convention of __sg_page_iter_start, so that
> + * the iterator doesn't point to a valid page after initialization; it has
> + * to be advanced one step first.
> + */
> +void vmw_piter_start(struct vmw_piter *viter, const struct vmw_sg_table
> *vsgt,
> + unsigned long p_offset)
> +{
> + viter->i = p_offset - 1;
> + viter->num_pages = vsgt->num_pages;
> + switch (vsgt->mode) {
> + case vmw_dma_phys:
> + viter->next = &__vmw_piter_non_sg_next;
> + viter->dma_address = &__vmw_piter_phys_addr;
> + viter->page = &__vmw_piter_non_sg_page;
> + viter->pages = vsgt->pages;
> + break;
> + case vmw_dma_alloc_coherent:
> + viter->next = &__vmw_piter_non_sg_next;
> + viter->dma_address = &__vmw_piter_dma_addr;
> + viter->page = &__vmw_piter_non_sg_page;
> + viter->addrs = vsgt->addrs;
> + break;
> + case vmw_dma_map_populate:
> + case vmw_dma_map_bind:
> + viter->next = &__vmw_piter_sg_next;
> + viter->dma_address = &__vmw_piter_sg_addr;
> + viter->page = &__vmw_piter_sg_page;
> + __sg_page_iter_start(&viter->iter, vsgt->sgt->sgl,
> + vsgt->sgt->orig_nents, p_offset);
> + break;
> + default:
> + BUG();
> + }
> +}
> +
> +/**
> + * vmw_ttm_unmap_from_dma - unmap device addresses previsouly mapped for
> + * TTM pages
> + *
> + * @vmw_tt: Pointer to a struct vmw_ttm_backend
> + *
> + * Used to free dma mappings previously mapped by vmw_ttm_map_for_d
[PATCH 0/2] Make the vmwgfx driver reasonably DMA-API compliant
On Mon, Nov 04, 2013 at 05:57:37AM -0800, Thomas Hellstrom wrote: > These patches makes the vmwgfx driver use the DMA API to obtain valid > device addresses rather than blindly using physical addresses. > > The main motivation is to be able to use a virtual IOMMU in the future. Ooooh. Neat! Are there any RFC patches available? > > Other TTM drivers typically map pages one by one rather than using a > scatter-gather list, but since we can benefit from having a single dma > address region set up by the IOMMU, we use a scatter-gather list instead. > > Finally to be able to handle all the dma mapping modes, we locally extend the > scatter-gather list page iterator to handle also the direct physical- and > coherent cases. > > Finally, the TTM DMA page pool is enabled also when the Intel IOMMU is active -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
