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
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
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/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/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 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 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 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 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 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
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/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 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/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 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/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,
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/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
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/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 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/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/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/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/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
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
,
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/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
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
,
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
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
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/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/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/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 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/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/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/20/2012 02:17 AM, Terje Bergström wrote:
On 16.12.2012 14:16, Thierry Reding wrote:
Okay, so we're back on the topic of using globals. I need to assert
again that this is not an option. If we were to use globals, then we
could just as well leave out the dummy device and just do all of
On 12/20/2012 02:34 PM, Terje Bergström wrote:
On 20.12.2012 22:30, Thierry Reding wrote:
The problem with your proposed solution is that, even any of Stephen's
valid objections aside, it won't work. Once the tegra-drm module is
unloaded, the driver's data will be left in the current state and
On 12/20/2012 02:50 PM, Thierry Reding wrote:
On Thu, Dec 20, 2012 at 11:34:26PM +0200, Terje Bergström wrote:
On 20.12.2012 22:30, Thierry Reding wrote:
The problem with your proposed solution is that, even any of
Stephen's valid objections aside, it won't work. Once the
tegra-drm module is
On 12/21/2012 01:57 AM, Arto Merilainen wrote:
On 12/20/2012 07:14 PM, Stephen Warren wrote:
What's wrong with just having each device ask the host1x (its parent)
for a pointer to the (dummy) tegradrm device. That seems extremely
We are talking about creating a dummy device because:
- we
On 12/21/2012 11:50 PM, Terje Bergström wrote:
On 21.12.2012 16:36, Thierry Reding wrote:
On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
+static struct platform_driver tegra_drm_platform_driver = {
+ .driver = {
+ .name = tegradrm,
This should be tegra-drm to
On 01/04/2013 03:09 AM, Terje Bergström wrote:
...
I think we have now two ways to go forward with cons and pros:
1) Keep host1x and tegra-drm as separate driver
+ Code almost done
- we need dummy device and dummy driver
- extra code and API when host1x creates dummy device and its
On 01/07/2013 01:20 AM, Terje Bergström wrote:
On 04.01.2013 22:25, Stephen Warren wrote:
On 01/04/2013 03:09 AM, Terje Bergström wrote:
...
I think we have now two ways to go forward with cons and pros:
1) Keep host1x and tegra-drm as separate driver
+ Code almost done
- we need
On 01/07/2013 01:43 PM, Sean Paul wrote:
Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just defaulting to v1.4 with the existence of
the dt node.
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
On 01/07/2013 04:12 PM, Sean Paul wrote:
On Jan 7, 2013 5:32 PM, Stephen Warren swar...@wwwdotorg.org
mailto:swar...@wwwdotorg.org wrote:
On 01/07/2013 01:43 PM, Sean Paul wrote:
Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just
On 01/08/2013 01:16 PM, Sean Paul wrote:
Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just defaulting to v1.4 with the existence of
the dt node.
I guess this seems OK to me if required, although I'd certainly like to
see someone familiar with
On 01/15/2013 04:26 AM, Terje Bergstrom wrote:
Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
of 2D clock to that driver alias.
FYI on this one patch - it won't be applied to the Tegra tree until
after Prashant's common clock framework changes are applied. As such, it
will
From: Stephen Warren swar...@nvidia.com
Silence the following:
drivers/gpu/drm/drm_irq.c: In function 'drm_calc_vbltimestamp_from_scanoutpos':
drivers/gpu/drm/drm_irq.c:583:24: warning: 'mono_time_offset.tv64' may be used
uninitialized in this function
... by always initializing
On 01/30/2013 06:16 PM, Inki Dae wrote:
2013/1/30 Sylwester Nawrocki sylvester.nawro...@gmail.com:
Hi,
On 01/08/2013 11:56 PM, Stephen Warren wrote:
On 01/08/2013 01:16 PM, Sean Paul wrote:
Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead
On 01/31/2013 06:27 PM, Inki Dae wrote:
Hi Kukjin,
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Kukjin Kim
Sent: Friday, February 01, 2013 9:15 AM
To: 'Sylwester Nawrocki'; 'Inki Dae'
Cc: 'Sachin Kamat';
On 01/31/2013 10:36 AM, Stephen Warren wrote:
On 01/31/2013 08:04 AM, Sean Paul wrote:
...
I think if we take a step back, we're really not discussing HDMI
version 1.3 vs. 1.4, we're really talking about the HDMI IP block
version.
Absolutely.
The blocks just happen to implement
On 02/04/2013 04:26 AM, Thierry Reding wrote:
On Tue, Jan 15, 2013 at 01:44:03PM +0200, Terje Bergstrom wrote:
Add a driver alias gr2d for Tegra 2D device, and assign a
duplicate of 2D clock to that driver alias.
Signed-off-by: Terje Bergstrom tbergst...@nvidia.com ---
n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes the
references from v13 to 4210 and v14 to 4212 to reflect the IP
block version instead of the HDMI version.
diff --git
On 02/05/2013 05:37 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren swar...@wwwdotorg.org wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes
On 02/05/2013 05:56 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/05/2013 05:37 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
Use
From: Stephen Warren swar...@nvidia.com
ARCH_TEGRA always enabled OF, so there's no need for any driver to
depend on it.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/gpu/drm/tegra/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
Daniel,
Commit 6aed8ec drm: review locking for
drm_fb_helper_restore_fbdev_mode (now in next-20130218 and later)
causes build failures for tegra_defconfig. The issue is this part of the
patch:
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index
On 03/06/2013 12:14 PM, Marcin Slusarz wrote:
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote:
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
Dropping Tegra ML, it's not the place where Nouveau mails should go.
$ ./scripts/get_maintainer.pl -f
From: Stephen Warren swar...@nvidia.com
Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.
This provides the same benefits as using a K: regex
From: Stephen Warren swar...@nvidia.com
This causes the regex to be applied to filenames only, and not patch or
file content (such as comments). This should prevent e.g.
drivers/gpu/drm/nouveau/nv50_display.c from matching this entry.
Reported-by: Marcin Slusarz marcin.slus...@gmail.com
Signed
From: Stephen Warren swar...@nvidia.com
Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.
This provides the same benefits as using a K: regex
From: Stephen Warren swar...@nvidia.com
This causes the regex to be applied to filenames only, and not patch or
file content (such as comments). This should prevent e.g.
drivers/gpu/drm/nouveau/nv50_display.c from matching this entry.
Reported-by: Marcin Slusarz marcin.slus...@gmail.com
Signed
From: Stephen Warren swar...@nvidia.com
This reverts most of eb90d08 get_maintainer: allow keywords to match
filenames; all except the parts that are required to implement the new
N: entry type.
The rationale is that it's better to have K: match just patch or file
content as it previously did
On 03/06/2013 05:30 PM, Joe Perches wrote:
On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This reverts most of eb90d08 get_maintainer: allow keywords to match
filenames; all except the parts that are required to implement the new
N: entry
On 03/06/2013 05:40 PM, Joe Perches wrote:
On Wed, 2013-03-06 at 17:34 -0700, Stephen Warren wrote:
On 03/06/2013 05:30 PM, Joe Perches wrote:
On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This reverts most of eb90d08 get_maintainer: allow
1 - 100 of 347 matches
Mail list logo
