On 04/15/2012 02:39 AM, Thierry Reding wrote:
* Stephen Warren wrote:
On 04/13/2012 03:14 AM, Thierry Reding wrote:
display-controllers = disp1 disp2;
outputs = lvds hdmi tvo dsi;
I don't think you need both the child nodes and those two properties.
In other words,
* Stephen Warren wrote:
On 04/15/2012 02:39 AM, Thierry Reding wrote:
I think I like the former better. The way I understand it the children of
the
graphics node will have to be registered explicitly by the DRM driver
because
of_platform_populate() doesn't work recursively. That would
On 04/16/2012 12:48 PM, Thierry Reding wrote:
* Stephen Warren wrote:
...
Has there been any discussion as to how EDID data would best be represented
in DT? Should it just be a binary blob or rather some textual
representation?
I think a binary blob makes sense - that's the exact same
* Stephen Warren wrote:
On 04/16/2012 12:48 PM, Thierry Reding wrote:
* Stephen Warren wrote:
...
Has there been any discussion as to how EDID data would best be
represented
in DT? Should it just be a binary blob or rather some textual
representation?
I think a binary blob makes
On 04/16/2012 01:03 PM, Thierry Reding wrote:
...
I've been looking about for tools to generate EDID data but didn't find
anything useful. Does anyone know of any tool that's more convenient than
manually filling a struct edid and writing that to a file?
Sorry, no.
* Stephen Warren wrote:
On 04/13/2012 03:14 AM, Thierry Reding wrote:
display-controllers = disp1 disp2;
outputs = lvds hdmi tvo dsi;
I don't think you need both the child nodes and those two properties.
In other words, I think you either want:
* Stephen Warren wrote:
On 04/12/2012 11:44 AM, Thierry Reding wrote:
[...]
And given that, I don't think we should name the node after some
OS-specific software concept. Device tree is intended to model hardware.
[...]
Maybe one solution would be to have a top-level DRM device with a
* Arnd Bergmann wrote:
On Wednesday 11 April 2012, Thierry Reding wrote:
Daniel Vetter wrote:
Well, you use the iommu api to map/unmap memory into the iommu for tegra,
whereas usually device drivers just use the dma api to do that. The usual
interface is dma_map_sg/dma_unmap_sg, but
* Stephen Warren wrote:
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
Only the RGB output
Hi Thierry,
On Thursday, April 12, 2012 9:18 AM Thierry Reding wrote:
* Arnd Bergmann wrote:
On Wednesday 11 April 2012, Thierry Reding wrote:
Daniel Vetter wrote:
Well, you use the iommu api to map/unmap memory into the iommu for
tegra,
whereas usually device drivers just use
On Wed, Apr 11, 2012 at 12:12:14PM -0600, Stephen Warren wrote:
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the
On Thursday 12 April 2012, Marek Szyprowski wrote:
Scatter lists were initially designed for the disk based block io operations,
hence the presence of the in-page offsets and lengths for each chunk. For
multimedia use cases providing an array of struct pages and asking
dma-mapping
to map
* Alex Deucher wrote:
On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
In other words I would like to use the Tegra hardware to render content into
a framebuffer (using potentially the 3D engine or HW accelerated video
decoding blocks) but display
Hi Thierry,
On Thursday, April 12, 2012 3:42 PM Thierry Reding wrote:
Also this doesn't yet solve the vmap() problem that is needed for the
kernel
virtual mapping. I did try using dma_alloc_writecombine(), but that only
works for chunks of 2 MB or smaller, unless I use
On 04/12/2012 12:50 AM, Thierry Reding wrote:
* Stephen Warren wrote:
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the
* Alex Deucher wrote:
On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
Then again, having user-space control this may be more flexible.
Performance-
wise both should be about the same, right? What I don't quite
* Stephen Warren wrote:
On 04/12/2012 12:50 AM, Thierry Reding wrote:
drm {
compatible = nvidia,tegra20-drm;
I'm don't think having an explicit drm node is the right approach; drm
is after all a SW term and the DT should be describing HW. Having some
kind of top-level
On 04/12/2012 11:44 AM, Thierry Reding wrote:
* Stephen Warren wrote:
On 04/12/2012 12:50 AM, Thierry Reding wrote:
drm {
compatible = nvidia,tegra20-drm;
I'm don't think having an explicit drm node is the right approach; drm
is after all a SW term and the DT should be
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and
Hm, in that case it looks like your iommu works more like the gtt on intel
chips
Don't overgeneralize there - on the GMA500/600 the GTT doesn't allow CPU
side access of the GTT map (ie you can't use it to linearise pages for
CPU view) and the 3600 is even stranger
Alan
Maybe your question is answered by my reply to Alan's comment. The mapping
is actually done to get a linear view for the display controller which
doesn't support SG transfers. The kernel and user-space already have virtual
linear buffers.
The framebuffer currently needs a physically
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 04:11:08PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds
* Alan Cox wrote:
Maybe your question is answered by my reply to Alan's comment. The mapping
is actually done to get a linear view for the display controller which
doesn't support SG transfers. The kernel and user-space already have virtual
linear buffers.
The framebuffer currently
Heh, vmap() is exactly what I do. =) Would you mind explaining why exactly it
is hideous?
On x86 we don't have a vast amount of address space available for virtual
remappings and the framebuffer then eats over 8MB of it.
The ideal case is that the fb layer can be taught to do page/offset
On Wednesday 11 April 2012, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
* Daniel Vetter wrote:
On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
Only the RGB output is supported. Quite a lot of
26 matches
Mail list logo
