On 12/13/2012 11:09 PM, Terje Bergstr?m wrote:
> On 13.12.2012 19:58, Stephen Warren wrote:
>> On 12/13/2012 01:57 AM, Thierry Reding wrote:
>>> After some more discussion with Stephen on IRC we came to the
>>> conclusion that the easiest might be to have teg
On 12/13/2012 11:09 PM, Terje Bergström wrote:
On 13.12.2012 19:58, Stephen Warren wrote:
On 12/13/2012 01:57 AM, Thierry Reding wrote:
After some more discussion with Stephen on IRC we came to the
conclusion that the easiest might be to have tegra-drm call into
host1x with something like
On 12/13/2012 01:57 AM, Thierry Reding wrote:
> On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergstr?m wrote:
>> On 12.12.2012 18:08, Thierry Reding wrote:
>>> I've briefly discussed this with Stephen on IRC because I
>>> thought I had remembered him objecting to the idea of adding a
>>> dummy
On 12/13/2012 01:57 AM, Thierry Reding wrote:
On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergström wrote:
On 12.12.2012 18:08, Thierry Reding wrote:
I've briefly discussed this with Stephen on IRC because I
thought I had remembered him objecting to the idea of adding a
dummy device just
On 12/06/2012 01:13 AM, Mark Zhang wrote:
> On 12/06/2012 04:00 PM, Lucas Stach wrote:
>> Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang:
> [...]
>>>
>>> OK. So these relocation addresses are used to let userspace tells kernel
>>> which buffers mentioned in the command should be
On 12/06/2012 01:13 AM, Mark Zhang wrote:
On 12/06/2012 04:00 PM, Lucas Stach wrote:
Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang:
[...]
OK. So these relocation addresses are used to let userspace tells kernel
which buffers mentioned in the command should be relocated to
On 12/03/2012 08:00 PM, Mark Zhang wrote:
> On 11/28/2012 02:37 PM, Mark Zhang wrote:
>> On 11/28/2012 05:39 AM, Stephen Warren wrote:
>>> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>>>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>>>>> On 11/27/2012
On 12/01/2012 07:58 AM, Thierry Reding wrote:
> On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergstr?m wrote:
...
>> I was thinking of definitions like this:
>>
>> static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_addr_f(u32 v) {
>> return (v & 0x1ff) << 0; }
>>
>> versus
>>
>> #define
On 11/30/2012 03:38 AM, Thierry Reding wrote:
> On Fri, Nov 30, 2012 at 10:56:39AM +0200, Terje Bergstr?m wrote:
>> On 29.11.2012 13:47, Thierry Reding wrote:
>>> On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergstr?m
>>> wrote:
Tegra20 and Tegra30 are compatible, but future chips are not.
On 11/30/2012 03:38 AM, Thierry Reding wrote:
On Fri, Nov 30, 2012 at 10:56:39AM +0200, Terje Bergström wrote:
On 29.11.2012 13:47, Thierry Reding wrote:
On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström
wrote:
Tegra20 and Tegra30 are compatible, but future chips are not.
I was
On 12/01/2012 07:58 AM, Thierry Reding wrote:
On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergström wrote:
...
I was thinking of definitions like this:
static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_addr_f(u32 v) {
return (v 0x1ff) 0; }
versus
#define
On 12/03/2012 08:00 PM, Mark Zhang wrote:
On 11/28/2012 02:37 PM, Mark Zhang wrote:
On 11/28/2012 05:39 AM, Stephen Warren wrote:
On 11/27/2012 11:17 AM, Stephen Warren wrote:
On 11/26/2012 08:16 PM, Mark Zhang wrote:
On 11/27/2012 06:37 AM, Stephen Warren wrote:
On 11/22/2012 12:37 PM
On 11/29/2012 01:44 AM, Thierry Reding wrote:
> On Mon, Nov 26, 2012 at 03:19:08PM +0200, Terje Bergstrom wrote:
>> diff --git a/drivers/video/tegra/host/host1x/host1x_intr.c
>> b/drivers/video/tegra/host/host1x/host1x_intr.c
> [...]
>> +/* Spacing between sync registers */ +#define
On 11/29/2012 04:47 AM, Thierry Reding wrote:
> On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergstr?m wrote:
>> On 28.11.2012 23:23, Thierry Reding wrote:
>>> This could be problematic. Since drivers/video and
>>> drivers/gpu/drm are separate trees, this would entail a
>>> continuous burden on
On 11/29/2012 03:21 AM, Terje Bergstr?m wrote:
> On 28.11.2012 23:23, Thierry Reding wrote:
...
>>> + regs = platform_get_resource(dev, IORESOURCE_MEM, 0);
>>> + intr0 = platform_get_resource(dev, IORESOURCE_IRQ, 0);
>>> + intr1 = platform_get_resource(dev, IORESOURCE_IRQ, 1);
>>> +
On 11/29/2012 03:21 AM, Terje Bergström wrote:
On 28.11.2012 23:23, Thierry Reding wrote:
...
+ regs = platform_get_resource(dev, IORESOURCE_MEM, 0);
+ intr0 = platform_get_resource(dev, IORESOURCE_IRQ, 0);
+ intr1 = platform_get_resource(dev, IORESOURCE_IRQ, 1);
+
+ if
On 11/29/2012 04:47 AM, Thierry Reding wrote:
On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström wrote:
On 28.11.2012 23:23, Thierry Reding wrote:
This could be problematic. Since drivers/video and
drivers/gpu/drm are separate trees, this would entail a
continuous burden on keeping
On 11/29/2012 01:44 AM, Thierry Reding wrote:
On Mon, Nov 26, 2012 at 03:19:08PM +0200, Terje Bergstrom wrote:
diff --git a/drivers/video/tegra/host/host1x/host1x_intr.c
b/drivers/video/tegra/host/host1x/host1x_intr.c
[...]
+/* Spacing between sync registers */ +#define REGISTER_STRIDE 4
On 11/28/2012 12:18 PM, Thierry Reding wrote:
> Add myself as the maintainer of the NVIDIA Tegra DRM driver.
Aside from one comment below,
Acked-by: Stephen Warren
> +L: dri-devel at lists.freedesktop.org
Should linux-tegra at vger.kernel.org also be CC'd so that everything
Tegra-r
On 11/28/2012 07:45 AM, Terje Bergstr?m wrote:
> On 28.11.2012 16:06, Lucas Stach wrote:
>> Why do even need/use dma-buf for this use case? This is all one DRM
>> device, even if we separate host1x and gr2d as implementation modules.
>
> I didn't want to implement dependency to drm gem objects in
On 11/28/2012 07:45 AM, Terje Bergström wrote:
On 28.11.2012 16:06, Lucas Stach wrote:
Why do even need/use dma-buf for this use case? This is all one DRM
device, even if we separate host1x and gr2d as implementation modules.
I didn't want to implement dependency to drm gem objects in
On 11/28/2012 12:18 PM, Thierry Reding wrote:
Add myself as the maintainer of the NVIDIA Tegra DRM driver.
Aside from one comment below,
Acked-by: Stephen Warren swar...@nvidia.com
+L: dri-devel@lists.freedesktop.org
Should linux-te...@vger.kernel.org also be CC'd so that everything
Tegra
On 11/27/2012 11:17 AM, Stephen Warren wrote:
> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>>>> Instead of using the stride derived from the display mode,
On 11/26/2012 08:16 PM, Mark Zhang wrote:
> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>>> Instead of using the stride derived from the display mode, use the pitch
>>> associated with the currently active framebuf
On 11/26/2012 11:33 PM, Terje Bergstr?m wrote:
> On 27.11.2012 01:39, Stephen Warren wrote:
>> Clock names shouldn't be passed in platform data; instead, clk_get()
>> should be passed the device object and device-relative (i.e. not global)
>> clock name. I expect if the dr
On 11/26/2012 11:33 PM, Terje Bergström wrote:
On 27.11.2012 01:39, Stephen Warren wrote:
Clock names shouldn't be passed in platform data; instead, clk_get()
should be passed the device object and device-relative (i.e. not global)
clock name. I expect if the driver is fixed to make
On 11/26/2012 08:16 PM, Mark Zhang wrote:
On 11/27/2012 06:37 AM, Stephen Warren wrote:
On 11/22/2012 12:37 PM, Thierry Reding wrote:
Instead of using the stride derived from the display mode, use the pitch
associated with the currently active framebuffer. This fixes a bug where
the LCD
On 11/27/2012 11:17 AM, Stephen Warren wrote:
On 11/26/2012 08:16 PM, Mark Zhang wrote:
On 11/27/2012 06:37 AM, Stephen Warren wrote:
On 11/22/2012 12:37 PM, Thierry Reding wrote:
Instead of using the stride derived from the display mode, use the pitch
associated with the currently active
On 11/26/2012 06:19 AM, Terje Bergstrom wrote:
> Add SoC specific auxiliary data to host1x and gr2d. nvhost uses
> this data.
>
> Signed-off-by: Terje Bergstrom
> Signed-off-by: Arto Merilainen
Arto's S-o-b really should be first and yours last since you're (Terje)
the one who touched the
fferent from that of the LCD.
This patch certainly doesn't cause any additional issues for me, so:
Tested-by: Stephen Warren
Howwever, it still doesn't allow both Cardhu's LCD panel and external
HDMI port (1080p) to be active at once. If I boot with both enabled, or
boot with just the LCD enabled and h
that of the LCD.
This patch certainly doesn't cause any additional issues for me, so:
Tested-by: Stephen Warren swar...@nvidia.com
Howwever, it still doesn't allow both Cardhu's LCD panel and external
HDMI port (1080p) to be active at once. If I boot with both enabled, or
boot with just the LCD enabled
On 11/26/2012 06:19 AM, Terje Bergstrom wrote:
Add SoC specific auxiliary data to host1x and gr2d. nvhost uses
this data.
Signed-off-by: Terje Bergstrom tbergst...@nvidia.com
Signed-off-by: Arto Merilainen amerilai...@nvidia.com
Arto's S-o-b really should be first and yours last since
pplied (due to the whitespace issues I
mentioned earlier), and this ordering issue fixed,
Tested-by: Stephen Warren
(On Cardhu, with no HDMI plugged in; see my next email for details).
On 11/15/2012 09:58 PM, Mark Zhang wrote:
> This patch is based on Thierry's drm patch for Tegra20:
> - [PATCH v2 0/6] Device tree updates for host1x support
> - [PATCH v3 0/2] NVIDIA Tegra DRM driver
>
> It adds the support for NVIDIA Tegra30.
Mark, I tried to apply this for testing locally,
,
Tested-by: Stephen Warren swar...@nvidia.com
(On Cardhu, with no HDMI plugged in; see my next email for details).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
lso put the two patches in this series into the tegra/drm/for-3.8
> branch of my repository on gitorious[0].
The series,
Tested-by: Stephen Warren
(on Harmony, using the HDMI output)
in this series into the tegra/drm/for-3.8
branch of my repository on gitorious[0].
The series,
Tested-by: Stephen Warren swar...@nvidia.com
(on Harmony, using the HDMI output)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
On 11/13/2012 04:08 AM, Thierry Reding wrote:
> On Mon, Nov 12, 2012 at 04:37:02PM +0100, Steffen Trumtrar wrote:
>> This adds support for reading display timings from DT or/and
>> convert one of those timings to a videomode. The
>> of_display_timing implementation supports multiple children where
On 11/12/2012 11:47 PM, Thierry Reding wrote:
> On Mon, Nov 12, 2012 at 05:17:18PM -0700, Stephen Warren wrote:
>> On 11/12/2012 02:55 PM, Thierry Reding wrote:
>>> This second version of this patch series addresses all the
>>> comments received so far. Most
On 11/13/2012 02:37 AM, Thierry Reding wrote:
> On Tue, Nov 13, 2012 at 04:49:24PM +0800, Mark Zhang wrote:
>> On 11/13/2012 03:48 PM, Thierry Reding wrote:
>>> * PGP Signed by an unknown key
>>>
>>> On Tue, Nov 13, 2012 at 03:15:47PM +0800, Mark Zhang wrote:
On 11/13/2012 05:55 AM, Thierry
On 11/13/2012 12:15 AM, Mark Zhang wrote:
> On 11/13/2012 05:55 AM, Thierry Reding wrote:
>> This commit adds a KMS driver for the Tegra20 SoC. This includes basic
>> support for host1x and the two display controllers found on the Tegra20
>> SoC. Each display controller can drive a separate
On 11/13/2012 12:15 AM, Mark Zhang wrote:
On 11/13/2012 05:55 AM, Thierry Reding wrote:
This commit adds a KMS driver for the Tegra20 SoC. This includes basic
support for host1x and the two display controllers found on the Tegra20
SoC. Each display controller can drive a separate RGB/LVDS
On 11/13/2012 02:37 AM, Thierry Reding wrote:
On Tue, Nov 13, 2012 at 04:49:24PM +0800, Mark Zhang wrote:
On 11/13/2012 03:48 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Nov 13, 2012 at 03:15:47PM +0800, Mark Zhang wrote:
On 11/13/2012 05:55 AM, Thierry Reding wrote:
On 11/12/2012 11:47 PM, Thierry Reding wrote:
On Mon, Nov 12, 2012 at 05:17:18PM -0700, Stephen Warren wrote:
On 11/12/2012 02:55 PM, Thierry Reding wrote:
This second version of this patch series addresses all the
comments received so far. Most notably it takes advantage of
the debugfs
On 11/13/2012 04:08 AM, Thierry Reding wrote:
On Mon, Nov 12, 2012 at 04:37:02PM +0100, Steffen Trumtrar wrote:
This adds support for reading display timings from DT or/and
convert one of those timings to a videomode. The
of_display_timing implementation supports multiple children where
each
around of #defines and the device tree
> bindings documentation. Finally the driver now uses the DRM core's
> drm_compat_ioctl() instead of a custom and unimplemented (!) version.
The series,
Tested-by: Stephen Warren
(on the Harmony board's HDMI output; I'll test other boards/outputs later).
ee bindings look reasonable to me, so,
Acked-by: Stephen Warren
,
Acked-by: Stephen Warren swar...@nvidia.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
documentation. Finally the driver now uses the DRM core's
drm_compat_ioctl() instead of a custom and unimplemented (!) version.
The series,
Tested-by: Stephen Warren swar...@nvidia.com
(on the Harmony board's HDMI output; I'll test other boards/outputs later
On 11/09/2012 06:59 AM, Thierry Reding wrote:
> This commit adds a KMS driver for the Tegra20 SoC. This includes basic
> support for host1x and the two display controllers found on the Tegra20
> SoC. Each display controller can drive a separate RGB/LVDS output.
I applied these two patches and the
t;drm" is a Linux-specific term, so shouldn't really be used as the
directory name for a binding. bindings/gpu/nvidia,tegra20-host1x.txt
would probably be just fine.
Aside from that, the bindings,
Acked-by: Stephen Warren
I don't really know anything about DRM or our display HW, so I haven
really be used as the
directory name for a binding. bindings/gpu/nvidia,tegra20-host1x.txt
would probably be just fine.
Aside from that, the bindings,
Acked-by: Stephen Warren swar...@nvidia.com
I don't really know anything about DRM or our display HW, so I haven't
reviewed the code at all. I
On 11/09/2012 06:59 AM, Thierry Reding wrote:
This commit adds a KMS driver for the Tegra20 SoC. This includes basic
support for host1x and the two display controllers found on the Tegra20
SoC. Each display controller can drive a separate RGB/LVDS output.
I applied these two patches and the
On 10/31/2012 03:28 AM, Steffen Trumtrar wrote:
Patch description? The patch defines the DT binding as well, which isn't
mentioned in the patch subject.
> new file mode 100644
> index 000..04c94a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt
> +Usage
On 10/31/2012 03:28 AM, Steffen Trumtrar wrote:
Patch description? The patch defines the DT binding as well, which isn't
mentioned in the patch subject.
new file mode 100644
index 000..04c94a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timings.txt
+Usage in
On 10/08/2012 06:20 AM, Tomi Valkeinen wrote:
> On Mon, 2012-10-08 at 14:04 +0200, Laurent Pinchart wrote:
>> On Monday 08 October 2012 12:01:18 Tomi Valkeinen wrote:
>>> On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski
>>> wrote:
...
>>> Of course, if this is about describing the
On 10/08/2012 02:25 AM, Guennadi Liakhovetski wrote:
> On Fri, 5 Oct 2012, Stephen Warren wrote:
>
>> On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
>>> Hi Steffen
>>>
>>> Sorry for chiming in so late in the game, but I've long been wanting to
>&g
On 10/08/2012 02:25 AM, Guennadi Liakhovetski wrote:
On Fri, 5 Oct 2012, Stephen Warren wrote:
On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
Hi Steffen
Sorry for chiming in so late in the game, but I've long been wanting to
have a look at this and compare with what we do for V4L2
On 10/08/2012 06:20 AM, Tomi Valkeinen wrote:
On Mon, 2012-10-08 at 14:04 +0200, Laurent Pinchart wrote:
On Monday 08 October 2012 12:01:18 Tomi Valkeinen wrote:
On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski
wrote:
...
Of course, if this is about describing the hardware, the
On 10/05/2012 10:16 AM, Steffen Trumtrar wrote:
> On Thu, Oct 04, 2012 at 12:47:16PM -0600, Stephen Warren wrote:
>> On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
...
>>> + for_each_child_of_node(timings_np, entry) {
>>> + struct signal_timing *s
On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
> Hi Steffen
>
> Sorry for chiming in so late in the game, but I've long been wanting to
> have a look at this and compare with what we do for V4L2, so, this seems a
> great opportunity to me:-)
>
> On Thu, 4 Oct 2012, Steffen Trumtrar
On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
Hi Steffen
Sorry for chiming in so late in the game, but I've long been wanting to
have a look at this and compare with what we do for V4L2, so, this seems a
great opportunity to me:-)
On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
> Get videomode from devicetree in a format appropriate for the
> backend. drm_display_mode and fb_videomode are supported atm.
> Uses the display signal timings from of_display_timings
> +++ b/drivers/of/of_videomode.c
> +int
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
A patch description would be useful for something like this.
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt
> b/Documentation/devicetree/bindings/video/display-timings.txt
> new file mode 100644
...
> +Usage in backend
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
A patch description would be useful for something like this.
diff --git a/Documentation/devicetree/bindings/video/display-timings.txt
b/Documentation/devicetree/bindings/video/display-timings.txt
new file mode 100644
...
+Usage in backend
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
Get videomode from devicetree in a format appropriate for the
backend. drm_display_mode and fb_videomode are supported atm.
Uses the display signal timings from of_display_timings
+++ b/drivers/of/of_videomode.c
+int
On 10/02/2012 10:06 PM, Leela Krishna Amudala wrote:
> On Mon, Oct 1, 2012 at 9:50 PM, Stephen Warren
> wrote:
>> On 09/30/2012 11:29 PM, Leela Krishna Amudala wrote:
>>> Hello Stephen Warren,
>>>
>>> The binding names that I use in my dts file should matc
On 10/02/2012 10:06 PM, Leela Krishna Amudala wrote:
On Mon, Oct 1, 2012 at 9:50 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 09/30/2012 11:29 PM, Leela Krishna Amudala wrote:
Hello Stephen Warren,
The binding names that I use in my dts file should match with the
names given in
http
On 10/01/2012 01:16 PM, Mitch Bradley wrote:
> On 10/1/2012 6:53 AM, Stephen Warren wrote:
>> On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
>>> Parse a display-node with timings and hardware-specs from devictree.
>>
>>> diff --git a/Documentation/devicet
On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
> Parse a display-node with timings and hardware-specs from devictree.
> diff --git a/Documentation/devicetree/bindings/video/display
> b/Documentation/devicetree/bindings/video/display
> new file mode 100644
> index 000..722766a
> ---
On 09/30/2012 11:29 PM, Leela Krishna Amudala wrote:
> Hello Stephen Warren,
>
> The binding names that I use in my dts file should match with the
> names given in
> http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
> right?
I don't think so; the bi
On 09/30/2012 11:29 PM, Leela Krishna Amudala wrote:
Hello Stephen Warren,
The binding names that I use in my dts file should match with the
names given in
http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
right?
I don't think so; the binding in that link
On 09/24/2012 09:35 AM, Steffen Trumtrar wrote:
Parse a display-node with timings and hardware-specs from devictree.
diff --git a/Documentation/devicetree/bindings/video/display
b/Documentation/devicetree/bindings/video/display
new file mode 100644
index 000..722766a
--- /dev/null
+++
On 09/24/2012 12:26 PM, Rob Herring wrote:
> On 09/24/2012 10:45 AM, Stephen Warren wrote:
>> On 09/24/2012 07:42 AM, Rob Herring wrote:
>>> On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
>>>> This patch adds a helper function for parsing videomodes from the
>&
On 09/24/2012 07:42 AM, Rob Herring wrote:
> On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
>> This patch adds a helper function for parsing videomodes from the devicetree.
>> The videomode can be either converted to a struct drm_display_mode or a
>> struct fb_videomode.
>> +++
On 09/24/2012 07:42 AM, Rob Herring wrote:
On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
+++
On 09/21/2012 01:22 AM, Inki Dae wrote:
> 2012/9/21 Stephen Warren :
>> On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
>>> This patch adds device tree based discovery support for exynos DRM-FIMD
>>> driver which includes driver modification to handle platform
On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
> This patch adds device tree based discovery support for exynos DRM-FIMD
> driver which includes driver modification to handle platform data in
> both the cases with DT and non-DT, Also adds the documentation for bindings.
> diff --git
On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
This patch adds device tree based discovery support for exynos DRM-FIMD
driver which includes driver modification to handle platform data in
both the cases with DT and non-DT, Also adds the documentation for bindings.
diff --git
On 09/21/2012 01:22 AM, Inki Dae wrote:
2012/9/21 Stephen Warren swar...@wwwdotorg.org:
On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
This patch adds device tree based discovery support for exynos DRM-FIMD
driver which includes driver modification to handle platform data in
both
With respect to the following commits:
df0b344 drm/usb: select USB_SUPPORT in Kconfig
8f057d7 gpu/mfd/usb: Fix USB randconfig problems
... which end up with the following in next-20120904:
config DRM_USB
depends on DRM
depends on USB_ARCH_HAS_HCD
select USB
On 09/04/2012 02:00 PM, Guenter Roeck wrote:
On Tue, Sep 04, 2012 at 01:19:12PM -0600, Stephen Warren wrote:
With respect to the following commits:
df0b344 drm/usb: select USB_SUPPORT in Kconfig
8f057d7 gpu/mfd/usb: Fix USB randconfig problems
... which end up with the following in next
On 09/04/2012 02:00 PM, Guenter Roeck wrote:
> On Tue, Sep 04, 2012 at 01:19:12PM -0600, Stephen Warren wrote:
>> With respect to the following commits:
>>
>> df0b344 drm/usb: select USB_SUPPORT in Kconfig
>> 8f057d7 gpu/mfd/usb: Fix USB randconfig prob
With respect to the following commits:
df0b344 drm/usb: select USB_SUPPORT in Kconfig
8f057d7 gpu/mfd/usb: Fix USB randconfig problems
... which end up with the following in next-20120904:
config DRM_USB
depends on DRM
depends on USB_ARCH_HAS_HCD
select USB
On 08/23/2012 07:44 PM, Ricardo Neri wrote:
On 08/22/2012 02:55 AM, Takashi Iwai wrote:
At Tue, 21 Aug 2012 19:58:02 -0500,
Ricardo Neri wrote:
...
Maybe the lack of audio support in drm is because the audio users should
not talk to drm directly but to a lower level component (omapdrm,
On 08/23/2012 07:44 PM, Ricardo Neri wrote:
> On 08/22/2012 02:55 AM, Takashi Iwai wrote:
>> At Tue, 21 Aug 2012 19:58:02 -0500,
>> Ricardo Neri wrote:
...
>>> Maybe the lack of audio support in drm is because the audio users should
>>> not talk to drm directly but to a lower level component
On 08/03/2012 01:38 AM, Sascha Hauer wrote:
Hi Stephen,
On Thu, Aug 02, 2012 at 01:35:40PM -0600, Stephen Warren wrote:
On 07/04/2012 01:56 AM, Sascha Hauer wrote:
This patch adds a helper function for parsing videomodes from the
devicetree.
The videomode can be either converted
On 08/03/2012 01:38 AM, Sascha Hauer wrote:
> Hi Stephen,
>
> On Thu, Aug 02, 2012 at 01:35:40PM -0600, Stephen Warren wrote:
>> On 07/04/2012 01:56 AM, Sascha Hauer wrote:
>>> This patch adds a helper function for parsing videomodes from the
>>> devicetree
On 07/05/2012 08:51 AM, Rob Herring wrote:
> On 07/04/2012 02:56 AM, Sascha Hauer wrote:
>> This patch adds a helper function for parsing videomodes from the devicetree.
>> The videomode can be either converted to a struct drm_display_mode or a
>> struct fb_videomode.
>> diff --git
On 07/04/2012 01:56 AM, Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the devicetree.
> The videomode can be either converted to a struct drm_display_mode or a
> struct fb_videomode.
> diff --git a/Documentation/devicetree/bindings/video/displaymode
>
On 07/04/2012 01:56 AM, Sascha Hauer wrote:
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
diff --git a/Documentation/devicetree/bindings/video/displaymode
On 07/05/2012 08:51 AM, Rob Herring wrote:
On 07/04/2012 02:56 AM, Sascha Hauer wrote:
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
diff --git
On 07/05/2012 06:15 AM, Thierry Reding wrote:
> Here's a new proposal that should address all issues collected
> during the discussion of the previous one:
>
> From tegra20.dtsi:
...
At a quick glance, that all seems pretty reasonable now.
> One problem I've come across when trying to get some
On 07/05/2012 06:15 AM, Thierry Reding wrote:
Here's a new proposal that should address all issues collected
during the discussion of the previous one:
From tegra20.dtsi:
...
At a quick glance, that all seems pretty reasonable now.
One problem I've come across when trying to get some
On 06/28/2012 11:19 AM, Lucas Stach wrote:
...
CMA is just a way of providing large contiguous address space blocks in
a dynamic fashion. ...
TTM though solves more advanced matters, like buffer synchronisation
between 3D and 2D block of hardware ...
IMHO the best solution would be to use
On 06/28/2012 11:19 AM, Lucas Stach wrote:
...
> CMA is just a way of providing large contiguous address space blocks in
> a dynamic fashion. ...
>
> TTM though solves more advanced matters, like buffer synchronisation
> between 3D and 2D block of hardware ...
>
> IMHO the best solution would be
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
On 06/28/2012 12:18 AM, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 16:44:14 +0200
> Thierry Reding 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 bit more why you
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 outputs has the advantage
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
201 - 300 of 347 matches
Mail list logo
