ng 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
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
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 class
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
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.
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 avoi
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 --
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()
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
>> > w
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>
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/
n 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/
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
> ---
> sr
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.
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/gl
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 load
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/
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 +
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/
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
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
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 deleti
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.
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
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
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 P
7;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>
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>
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_bu
rom 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>
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>
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>
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 *de
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
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/76eedeab/attachment-0001.html>
lso 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/3c
e:
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>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/8b2e7f49/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/9e49f8c1/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131104/9a8adc05/attachment.html>
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 t
o 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-
t'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>
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_region
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>
-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.
>
> (s
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 registe
ature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/747793ca/attachment-0001.pgp>
https://bugzilla.kernel.org/show_bug.cgi?id=63181
Alan changed:
What|Removed |Added
Product|Drivers |Platform Specific/Hardware
Summary|Amil
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 -
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_D
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
robe 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>
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
>
>
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
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 t
ke 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>
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 reposito
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
t; >> 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>
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
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
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
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
erry
-- 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>
her 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>
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:
>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/b2c85ebb/attachment.html>
lt;http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/95294236/attachment.html>
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
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>
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>
;http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/5ef497dd/attachment.pgp>
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 cha
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>
dri-devel/attachments/20131104/d89d12df/attachment.html>
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.
>
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
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(+
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, bu
80 matches
Mail list logo
