On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
...
I think that there are 2 cases:
(1) discontiguous memory with IOMMU
(2) contiguous memory without IOMMU(called carveout in general?)
...
For (2), although memory is mostly anonymous one, we may need to know
how much to allocate, where we
On 06/28/2012 12:18 AM, Hiroshi Doyu wrote:
On Wed, 27 Jun 2012 16:44:14 +0200
Thierry Reding thierry.red...@avionic-design.de wrote:
I think that coherent_pool can be used only when the amount of
contiguous memory is short in your system. Otherwise even unnecessary.
Could you explain a
On 06/28/2012 05:12 AM, Thierry Reding wrote:
On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
...
In the ideal case I would want to not have a carveout size at
all. However there may be situations where you need to
On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
...
> I think that there are 2 cases:
>
> (1) discontiguous memory with IOMMU
> (2) contiguous memory without IOMMU(called "carveout" in general?)
...
> For (2), although memory is mostly anonymous one, we may need to know
> how much to allocate,
On 06/27/2012 08:29 AM, Hiroshi Doyu wrote:
> Could you explain a bit more why you want carveout size on per-board basis?
Different boards have different amounts of memory, and are sometimes
targeted at different use-cases (e.g. server with simple display buffer,
vs. consumer-oriented device
On 06/26/2012 11:07 PM, Thierry Reding wrote:
> On Tue, Jun 26, 2012 at 04:48:14PM -0600, Stephen Warren wrote:
...
> I actually like what you proposed above a lot, so if you don't
> mind either way I'll go with that proposal. Keeping the connector
> nodes as children of the
On 06/26/2012 01:51 PM, Thierry Reding wrote:
On Tue, Jun 26, 2012 at 12:10:42PM -0600, Stephen Warren wrote:
On 06/26/2012 04:55 AM, Thierry Reding wrote:
Hi,
while I haven't got much time to work on the actual code right
now, I think it might still be useful if we could get the
device
On 06/26/2012 07:46 PM, Mark Zhang wrote:
On Tue, 26 Jun 2012 12:55:13 +0200
Thierry Reding thierry.red...@avionic-design.de wrote:
...
I'm not sure I understand how information about the carveout would be
obtained from the IOMMU API, though.
I think that can be similar with current gart
On 06/26/2012 08:32 PM, Mark Zhang wrote:
On 06/26/2012 07:46 PM, Mark Zhang wrote:
On Tue, 26 Jun 2012 12:55:13 +0200
Thierry Reding thierry.red...@avionic-design.de wrote:
...
I'm not sure I understand how information about the carveout would be
obtained from the IOMMU API, though.
I
On 06/26/2012 08:32 PM, Mark Zhang wrote:
>> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> On Tue, 26 Jun 2012 12:55:13 +0200
> Thierry Reding wrote:
>> ...
I'm not sure I understand how information about the carveout would be
obtained from the IOMMU API, though.
>>>
>>> I think
On 06/26/2012 07:46 PM, Mark Zhang wrote:
>>> On Tue, 26 Jun 2012 12:55:13 +0200
>>> Thierry Reding wrote:
...
>> I'm not sure I understand how information about the carveout would be
>> obtained from the IOMMU API, though.
>
> I think that can be similar with current gart implementation. Define
On 06/26/2012 01:31 PM, Thierry Reding wrote:
> On Tue, Jun 26, 2012 at 11:43:38AM -0600, Stephen Warren wrote:
>> On 06/26/2012 07:41 AM, Thierry Reding wrote:
>>> On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergstr?m
>>> wrote:
>>>> On
On 06/26/2012 01:27 PM, Thierry Reding wrote:
> On Tue, Jun 26, 2012 at 11:41:43AM -0600, Stephen Warren wrote:
>> On 06/26/2012 08:02 AM, Terje Bergstr?m wrote:
>>> On 26.06.2012 16:41, Thierry Reding wrote:
>>>
>>>> On Tue, Jun 26, 2012 at 04:01:05PM +030
On 06/26/2012 04:55 AM, Thierry Reding wrote:
> Hi,
>
> while I haven't got much time to work on the actual code right now, I
> think it might still be useful if we could get the device tree binding
> to a point where everybody is happy with it. That'll also save me some
> time once I get to
On 06/26/2012 07:01 AM, Terje Bergstr?m wrote:
> On 26.06.2012 13:55, Thierry Reding wrote:
...
>> An alternative would be to call of_platform_populate() from the host1x
[alternative to making the host1x node contain compatible="simple-bus".]
>> driver. This has the advantage that it could
On 06/26/2012 07:41 AM, Thierry Reding wrote:
> On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergstr?m wrote:
>> On 26.06.2012 13:55, Thierry Reding wrote:
...
>>> status = "disabled";
>>>
>>> gart = <>;
>>>
>>> /* video-encoding/decoding */ mpe { reg = <0x5404
>>> 0x0004>; interrupts
On 06/26/2012 08:02 AM, Terje Bergstr?m wrote:
> On 26.06.2012 16:41, Thierry Reding wrote:
>
>> On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergstr?m wrote:
>>> We also assign certain host1x common resources per device by convention,
>>> f.ex. sync points, channels etc. We currently encode
On 06/26/2012 08:02 AM, Terje Bergström wrote:
On 26.06.2012 16:41, Thierry Reding wrote:
On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergström wrote:
We also assign certain host1x common resources per device by convention,
f.ex. sync points, channels etc. We currently encode that
On 06/26/2012 07:41 AM, Thierry Reding wrote:
On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergström wrote:
On 26.06.2012 13:55, Thierry Reding wrote:
...
status = disabled;
gart = gart;
/* video-encoding/decoding */ mpe { reg = 0x5404
0x0004; interrupts = 0 68 0x04; status =
On 06/26/2012 07:01 AM, Terje Bergström wrote:
On 26.06.2012 13:55, Thierry Reding wrote:
...
An alternative would be to call of_platform_populate() from the host1x
[alternative to making the host1x node contain compatible=simple-bus.]
driver. This has the advantage that it could integrate
On 06/26/2012 04:55 AM, Thierry Reding wrote:
Hi,
while I haven't got much time to work on the actual code right now, I
think it might still be useful if we could get the device tree binding
to a point where everybody is happy with it. That'll also save me some
time once I get to writing
On 06/26/2012 01:27 PM, Thierry Reding wrote:
On Tue, Jun 26, 2012 at 11:41:43AM -0600, Stephen Warren wrote:
On 06/26/2012 08:02 AM, Terje Bergström wrote:
On 26.06.2012 16:41, Thierry Reding wrote:
On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergström
wrote:
We also assign certain
On 06/26/2012 01:31 PM, Thierry Reding wrote:
On Tue, Jun 26, 2012 at 11:43:38AM -0600, Stephen Warren wrote:
On 06/26/2012 07:41 AM, Thierry Reding wrote:
On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergström
wrote:
On 26.06.2012 13:55, Thierry Reding wrote:
...
status = disabled
On 05/07/2012 02:50 AM, Terje Bergström wrote:
On 25.04.2012 12:45, Thierry Reding wrote:
+/ {
+ ...
+
+ /* host1x */
+ host1x: host1x@5000 {
+ compatible = nvidia,tegra20-host1x;
+ reg = 0x5000 0x00024000;
+ interrupts
On 05/07/2012 02:50 AM, Terje Bergstr?m wrote:
> On 25.04.2012 12:45, Thierry Reding wrote:
>
>> +/ {
>> + ...
>> +
>> + /* host1x */
>> + host1x: host1x at 5000 {
>> + compatible = "nvidia,tegra20-host1x";
>> + reg = <0x5000 0x00024000>;
>> +
On 04/25/2012 03:45 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.
>
> HDMI
On 04/25/2012 03:45 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.
HDMI
On 04/25/2012 03:45 AM, Thierry Reding wrote:
This function resolves an OF device node to an I2C adapter registered
with the I2C core.
I think this is doing the same thing as a patch I posted recently:
http://www.spinics.net/lists/linux-i2c/msg07808.html
What's the advantage of one way over
On 04/25/2012 03:45 AM, Thierry Reding wrote:
> This function resolves an OF device node to an I2C adapter registered
> with the I2C core.
I think this is doing the same thing as a patch I posted recently:
http://www.spinics.net/lists/linux-i2c/msg07808.html
What's the advantage of one way over
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.
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?
>>
>>
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 node
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 hardwar
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"
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
>>
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 04/11/2012 06:10 AM, Thierry Reding wrote:
> This commit is taken from the Chromium tree and was originally written
> by Robert Morell.
Maybe just cherry-pick it from there? That way, the git authorship will
show up as Robert.
On 04/11/2012 06:10 AM, Thierry Reding wrote:
> This commit adds device tree support for the GART hardware available on
> NVIDIA Tegra 20 SoCs.
>
> Signed-off-by: Thierry Reding
> ---
> arch/arm/boot/dts/tegra20.dtsi |6 ++
> arch/arm/mach-tegra/board-dt-tegra20.c |1 +
>
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds device tree support for the GART hardware available on
NVIDIA Tegra 20 SoCs.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
arch/arm/boot/dts/tegra20.dtsi |6 ++
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit is taken from the Chromium tree and was originally written
by Robert Morell.
Maybe just cherry-pick it from there? That way, the git authorship will
show up as Robert.
___
dri-devel mailing
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
Wu Fengguang wrote at Friday, August 05, 2011 6:50 AM:
> On Fri, Aug 05, 2011 at 02:03:41AM +0800, Keith Packard wrote:
> > On Thu, 4 Aug 2011 17:40:24 +0800, Wu Fengguang
> > wrote:
...
> > > You may wonder why the mode parameter is needed in intel_write_eld().
> > > This is because the ELD
Wu Fengguang wrote at Friday, August 05, 2011 6:50 AM:
On Fri, Aug 05, 2011 at 02:03:41AM +0800, Keith Packard wrote:
On Thu, 4 Aug 2011 17:40:24 +0800, Wu Fengguang fengguang...@intel.com
wrote:
...
You may wonder why the mode parameter is needed in intel_write_eld().
This is because
301 - 347 of 347 matches
Mail list logo
