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,
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
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/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
* 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.
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.
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
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 = < >;
>>> outputs = < >;
>>
>> I don't think you need both the child nodes and those two properties.
>>
>> In other words, I
* 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
* Stephen Warren wrote:
> On 04/13/2012 03:14 AM, Thierry Reding wrote:
> > display-controllers = < >;
> > outputs = < >;
>
> I don't think you need both the child nodes and those two properties.
>
> In other words, I think you either want:
>
> graphics at
* 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:
Oops, meant to put dri-devel on cc here.
Am Freitag, den 13.04.2012, 22:12 +0200 schrieb Lucas Stach:
> Am Freitag, den 13.04.2012, 08:33 +0100 schrieb Dave Airlie:
> > On Fri, Apr 13, 2012 at 12:10 AM, Lucas Stach wrote:
> > > Am Mittwoch, den 11.04.2012, 15:18 + schrieb Arnd Bergmann:
> >
On 04/13/2012 03:14 AM, Thierry Reding wrote:
* 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
On 04/13/2012 03:14 AM, Thierry Reding wrote:
> * 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
* 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
Am Mittwoch, den 11.04.2012, 15:18 + schrieb Arnd Bergmann:
> 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,
* 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
* 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
* Alex Deucher wrote:
> On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher
> 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
On Thu, Apr 12, 2012 at 11:18:19AM +, Arnd Bergmann wrote:
> 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
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 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
* Marek Szyprowski wrote:
> Hi Thierry,
>
> On Thursday, April 12, 2012 9:18 AM 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
* Marek Szyprowski wrote:
[...]
> We already have dma_map_page() and dma_map_single() which are very similar.
> Maybe adding dma_map_pages() won't be such a bad idea?
>
> If not maybe we should provide some kind of helper functions which converts
> page array to scatterlist and then maps them.
Hi Arnd,
On Thursday, April 12, 2012 1:18 PM Arnd Bergmann wrote:
> 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
> >
* Alex Deucher wrote:
> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
> 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 that framebuffer with a
On 04/11/2012 05:48 AM, 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 can run a console on the
>> framebuffer as well as X using the
* Sascha Hauer wrote:
> You might want to have a look at the sdrm patches I recently posted to
> dri-devel and arm Linux Kernel. Among other things they allow to
> register crtcs/connectors/encoders seperately so that each of them can
> have its own representation in the devicetree. I haven't
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
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
On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher wrote:
> On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
> wrote:
>> * Alex Deucher wrote:
>>> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
>>> wrote:
>>> > In other words I would like to use the Tegra hardware to render content
>>> > into
>>>
On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
wrote:
> * Alex Deucher wrote:
>> On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
>> 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
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
* 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
On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
wrote:
> * Sascha Hauer wrote:
>> You might want to have a look at the sdrm patches I recently posted to
>> dri-devel and arm Linux Kernel. Among other things they allow to
>> register crtcs/connectors/encoders seperately so that each of them can
>>
* 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
* 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
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
* Sascha Hauer wrote:
You might want to have a look at the sdrm patches I recently posted to
dri-devel and arm Linux Kernel. Among other things they allow to
register crtcs/connectors/encoders seperately so that each of them can
have its own representation in the devicetree. I haven't looked
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
On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* Sascha Hauer wrote:
You might want to have a look at the sdrm patches I recently posted to
dri-devel and arm Linux Kernel. Among other things they allow to
register crtcs/connectors/encoders seperately so
* 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
* Marek Szyprowski wrote:
[...]
We already have dma_map_page() and dma_map_single() which are very similar.
Maybe adding dma_map_pages() won't be such a bad idea?
If not maybe we should provide some kind of helper functions which converts
page array to scatterlist and then maps them.
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
Hi Arnd,
On Thursday, April 12, 2012 1:18 PM Arnd Bergmann wrote:
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
On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
* 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
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
thierry.red...@avionic-design.de wrote:
* Alex Deucher wrote:
On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
In other words I
On Thu, Apr 12, 2012 at 11:18:19AM +, Arnd Bergmann wrote:
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
* 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
Am Mittwoch, den 11.04.2012, 15:18 + schrieb Arnd Bergmann:
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
* 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
* 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:
> > > >
On Wed, Apr 11, 2012 at 03:43:09PM +0100, Alan Cox wrote:
> > 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
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 a very basic
> 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
* 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
> 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
> 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
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 can run a console on
* 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 can run a console on the
> > framebuffer as well as X using the xf86-video-modesetting
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
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 can run a console on the
> framebuffer as well as X using the xf86-video-modesetting driver.
> Only the RGB output is
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 things still need
to be worked out and there is a
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
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 can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
Only the RGB output is
* 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 can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
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 can run a console on the
* 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
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 a very basic DRM driver for
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
On Wed, Apr 11, 2012 at 03:43:09PM +0100, Alan Cox wrote:
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
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
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
77 matches
Mail list logo
