On 02/05/2013 05:56 PM, Sean Paul wrote:
> On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote:
>> On 02/05/2013 05:37 PM, Sean Paul wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren
>>> wrote:
>>>> n 02/05/2013 04:42 PM, Sean Paul wrote:
>&g
From: Stephen Warren
ARCH_TEGRA always enabled OF, so there's no need for any driver to
depend on it.
Signed-off-by: Stephen Warren
---
drivers/gpu/drm/tegra/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/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 37
On 02/19/2013 11:56 AM, Daniel Vetter wrote:
> On Tue, Feb 19, 2013 at 6:48 PM, Stephen Warren wrote:
>> Daniel,
>>
>> Commit 6aed8ec "drm: review locking for
>> drm_fb_helper_restore_fbdev_mode" (now in next-20130218 and later)
>> causes build failures
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 drivers/gp
From: Stephen Warren
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 option to match a
From: Stephen Warren
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
Signed-off-by: Stephen Warren
---
MAINTAINERS
From: Stephen Warren
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 option to match a
From: Stephen Warren
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
Signed-off-by: Stephen Warren
---
MAINTAINERS
From: Stephen Warren
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, an
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
>>
>> This reverts most of eb90d08 "get_maintainer: allow keywords to match
>> filenames"; all except the parts that are required
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
>>>>
>>>&g
From: Stephen Warren
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 option to match a
On 03/11/2013 03:36 PM, Marcin Ślusarz wrote:
>
> 11 mar 2013 21:19, "Stephen Warren" <mailto:swar...@wwwdotorg.org>> napisał(a):
>> Create a new N: entry type in MAINTAINERS which performs a regex match
>> against filenames; either those extracted fro
From: Stephen Warren
ARCH_TEGRA always enabled OF, so there's no need for any driver to
depend on it.
Signed-off-by: Stephen Warren
---
drivers/gpu/drm/tegra/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/
From: Stephen Warren
ARCH_TEGRA always enabled OF, so there's no need for any driver to
depend on it.
Signed-off-by: Stephen Warren
Acked-by: Thierry Reding
---
drivers/gpu/drm/tegra/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/Kc
On 03/21/2013 01:02 PM, Rob Clark wrote:
> How far away are we from supporting tegradrm with ARCH_MULTIPLATFORM?
> It would be nice to be able to at least compile-test drm core changes
> with all the arm drivers in one shot..
Pretty close. It might happen in 3.10 if I get time, otherwise it should
; definately conistency, especiall in its usage.
...
The Tegra parts in patches 4, 5, 8, 15, 16, 17, 29 all,
Acked-by: Stephen Warren
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 06/13/2013 03:53 AM, Mayuresh Kulkarni wrote:
Patch description?
> diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
> +#ifdef CONFIG_PM_RUNTIME
> + pm_runtime_enable(&pdev->dev);
> + pm_runtime_get_sync(&pdev->dev);
> +#else
> err = clk_prepare_enable(
On 06/13/2013 12:49 PM, Thierry Reding wrote:
> On Thu, Jun 13, 2013 at 03:23:37PM +0530, Mayuresh Kulkarni wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/drm/dc.c
>> b/drivers/gpu/host1x/drm/dc.c
> [...]
>> @@ -1128,9 +1129,7 @@ static int tegra_dc_probe(struct
>> platform_device *pdev) return
On 06/24/2013 04:27 PM, David Herrmann wrote:
> If we create proper platform-devices in x86 boot-code, we can use simplefb
> for VBE or EFI framebuffers, too. However, there is normally no OF support
> so we introduce a platform_data object so x86 boot-code can pass the
> paramaters via plain old p
On 06/24/2013 04:27 PM, David Herrmann wrote:
> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
> x86 causes troubles when loading multiple fbdev drivers. The global
> "struct screen_info" does not provide any state-tracking about which
> drivers use the FBs. request_mem_r
On 06/24/2013 04:27 PM, David Herrmann wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create one dumb-buffer and attach it to the CRTC. Only if
>
On 06/24/2013 04:27 PM, David Herrmann wrote:
> Create a simple fbdev device during SimpleDRM setup so legacy user-space
> and fbcon can use it.
>
> fbdev deletion is quite buggy. A unregister_framebuffer() call followed by
> a printk() causes NULL-derefs in hide_cursor() and other places in the V
On 06/24/2013 04:27 PM, David Herrmann wrote:
> Hi
>
> This is my second revision of the dvbe driver. I renamed it to SimpleDRM to
> show the resemblence with the recently introduced simplefb.c fbdev driver. The
> driver is supposed to be the most basic DRM driver similar to efifb.c,
> vesafb.c,
On 06/28/2013 04:11 AM, David Herrmann wrote:
> Hi
>
> On Wed, Jun 26, 2013 at 10:49 PM, Stephen Warren
> wrote:
>> On 06/24/2013 04:27 PM, David Herrmann wrote:
>>> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
>>> x86 causes
> framebuffers.
> So why not use it on x86, too?
Tested-by: Stephen Warren
(This time I didn't see any issue with the FB content being blank; I
must have forgotten a console= command-line parameter or something the
last time around)
"struct screen_info" to
> the right format-name.
Patches 1 and 5,
Reviewed-by: Stephen Warren
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
In next-20130808, building tegra_defconfig for ARM yields:
> drivers/built-in.o: In function `drm_lastclose':
> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198:
> undefined reference to `drm_agp_clear'
That's because drm_agp_clear() is called unconditionally, yet is o
On 08/08/2013 12:13 PM, David Herrmann wrote:
> Hi
>
> On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote:
>> In next-20130808, building tegra_defconfig for ARM yields:
>>
>>> drivers/built-in.o: In function `drm_lastclose':
>>> /home/swarren/sha
> Fixes a build-regression introduced by:
>
> commit 28ec711cd427f8b61f73712a43b8100ba8ca933b
> Author: David Herrmann
> Date: Sat Jul 27 16:37:00 2013 +0200
>
> drm/agp: move AGP cleanup paths to drm_agpsupport.c
Tested-by: Stephen Warren
__
On 08/09/2013 07:15 AM, Tomasz Figa wrote:
> Hi Chanho,
>
> On Friday 09 of August 2013 16:40:53 Chanho Park wrote:
>> This patch describes each nodes of rotator and specifies a example how to
>> bind it.
>> diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
>> +* Samsung Ima
On 08/23/2013 04:19 AM, Dan Carpenter wrote:
> There is a mistake here so it returns PTR_ERR(NULL) which is success
> instead of -ENOMEM.
>
> Signed-off-by: Dan Carpenter
> ---
> I can't compile this.
For the record, just do:
export CROSS_COMPILE=xxx
make ARCH=arm tegra_defconfig
make ARCH=arm
On 08/30/2013 09:25 AM, Thierry Reding wrote:
> Add a driver for simple panels. Such panels can have a regulator that
> provides the supply voltage and a separate GPIO to enable the panel.
> Optionally the panels can have a backlight associated with them so it
> can be enabled or disabled according
On 08/30/2013 01:24 PM, Kumar Gala wrote:
>
> On Aug 30, 2013, at 10:25 AM, Thierry Reding wrote:
>
>> Add a driver for simple panels. Such panels can have a regulator that
>> provides the supply voltage and a separate GPIO to enable the panel.
>> Optionally the panels can have a backlight associ
On 08/28/2013 09:48 AM, Mikko Perttunen wrote:
> Add Tegra114 TMDS configuration, add new peak_current field and
> use new place for drive current override bit on Tegra114 platform.
> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
> static struct of_device_id host1x_of_match[]
On 08/28/2013 09:48 AM, Mikko Perttunen wrote:
> Use EDID data to determine whether the display supports HDMI or just DVI.
> This used to be hardcoded to be HDMI, which broke support for DVI displays
> that couldn't understand the interspersed audio/other data.
>
> If the EDID data isn't available
On 08/28/2013 09:48 AM, Mikko Perttunen wrote:
> The Vdd regulator used to be enabled only at tegra_output_hdmi_enable,
> which is called after a sink is detected. However, the HDMI hotplug pin
> works by returning the voltage supplied by the Vdd pin, so this meant
> that the hotplug pin was never
On 08/28/2013 09:48 AM, Mikko Perttunen wrote:
> Add host1x, disp1 and disp2 clocks to the clock initialization table.
> These clocks are required for HDMI support.
This patch should be sent to Mike Turquette so it can be taken through
the clock tree.
__
On 08/28/2013 09:48 AM, Mikko Perttunen wrote:
> Add host1x, DC (display controller) and HDMI devices to Tegra114
> device tree.
Patches 5 and 6 should be sent separately to the Tegra maintainer (me)
to be taken through the Tegra tree.
___
dri-devel mail
On 09/04/2013 04:03 PM, Mikko Perttunen wrote:
> On 09/04/2013 09:44 PM, Stephen Warren wrote:
>> On 08/28/2013 09:48 AM, Mikko Perttunen wrote:
>>> The Vdd regulator used to be enabled only at tegra_output_hdmi_enable,
>>> which is called after a sink is detected. Ho
On 09/24/2013 06:05 AM, Arto Merilainen wrote:
> From: Mayuresh Kulkarni
>
> This far we have enabled gr2d clock on device probe and disabled
> it on device deinitialisation. This patch adds runtime pm support
> for the hardware unit allowing dynamic power management. If pm
> runtime is not enabl
On 09/24/2013 06:05 AM, Arto Merilainen wrote:
> From: Mayuresh Kulkarni
>
> This patch adds runtime pm support for host1x hardware unit. This
> allows host1x clock to be turned off when it is idle. If pm runtime
> is not configured, we enable host1x clock in device probe and disable
> it in remo
allback to resurrect it? The framebuffer itself is still registered
until the device's remove, yet after .fb_destroy, the memory is
unmapped, which would be dangerous if the FB can be re-started.
If that's not an issue, this patch seems fine, so
Acked-by: Stephen Warren
> I know that simpl
the series and hence
> I will continue working on the patches.
The series, briefly,
Reviewed-by: Stephen Warren
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> In order to subsystem-wide changes easier, move the Tegra DRM driver
^^ make ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> Tegra114 uses a slightly updated version of host1x with an additional
> syncpoint.
> drivers/gpu/host1x/hw/host1x02.c| 42 +
> drivers/gpu/host1x/hw/host1x02.h| 26 +++
> drivers/gpu/host1x/hw/hw_host1x02_channel.h | 12
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> From: Mikko Perttunen
>
> The Tegra114 display controller is backwards-compatible with previous
> generations of the Tegra SoC. No code changes are required.
If the HW is backwards-compatible, then there's no need to add extra
compatible values to
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> From: Mikko Perttunen
>
> Tegra114 TMDS configuration requires a new peak_current field and the
> driver current override bit has changed position.
> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
> static const struct t
On 10/11/2013 04:19 PM, Stephen Warren wrote:
> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>> From: Mikko Perttunen
>>
>> Tegra114 TMDS configuration requires a new peak_current field and the
>> driver current override bit has changed position.
>
>> diff --
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> Add a driver for simple panels. Such panels can have a regulator that
> provides the supply voltage and a separate GPIO to enable the panel.
> Optionally the panels can have a backlight associated with them so it
> can be enabled or disabled according
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> This driver adds support to perform calibration of the MIPI pads for CSI
> and DSI.
> diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
> +int tegra_mipi_calibrate(struct device *device)
...
> + err = of_parse_phandle_with_args(
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> This commit adds support for both DSI outputs found on Tegra. Only very
> minimal functionality is implemented, so advanced features like ganged
> mode won't work.
>
> Due to the lack of other test hardware, some sections of the driver are
> hardcode
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and
> Tegra30. No functionaly changes are required.
Similarly here, if the HW is 100% backwards-compatible, there's no need
to add compatible values to the driver.
_
On 10/12/2013 05:32 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:14:27PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> From: Mikko Perttunen
>>>
>>> The Tegra114 display controller is backwards-compatible with
&
On 10/12/2013 05:24 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:13:07PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> Tegra114 uses a slightly updated version of host1x with an
>>> additional syncpoint.
>>
>
On 10/12/2013 05:41 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:19:19PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> From: Mikko Perttunen
>>>
>>> Tegra114 TMDS configuration requires a new peak_current field
>
On 10/13/2013 11:58 PM, Terje Bergström wrote:
> On 12.10.2013 01:43, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and
>>> Tegra30. No functionaly changes are required.
>>
On 10/14/2013 08:00 AM, Thierry Reding wrote:
> On Mon, Oct 14, 2013 at 08:58:34AM +0300, Terje Bergström wrote:
>> On 12.10.2013 01:43, Stephen Warren wrote:
>>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>>> The gr2d hardware in Tegra114 is compatible with th
On 10/14/2013 07:55 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:43:35PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> This commit adds support for both DSI outputs found on Tegra. Only very
>>> minimal functionality
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 fiel
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 fiel
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 fiel
the series and hence
> I will continue working on the patches.
The series, briefly,
Reviewed-by: Stephen Warren
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> In order to subsystem-wide changes easier, move the Tegra DRM driver
^^ make ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> Tegra114 uses a slightly updated version of host1x with an additional
> syncpoint.
> drivers/gpu/host1x/hw/host1x02.c| 42 +
> drivers/gpu/host1x/hw/host1x02.h| 26 +++
> drivers/gpu/host1x/hw/hw_host1x02_channel.h | 12
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> From: Mikko Perttunen
>
> The Tegra114 display controller is backwards-compatible with previous
> generations of the Tegra SoC. No code changes are required.
If the HW is backwards-compatible, then there's no need to add extra
compatible values to
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> From: Mikko Perttunen
>
> Tegra114 TMDS configuration requires a new peak_current field and the
> driver current override bit has changed position.
> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
> static const struct t
On 10/11/2013 04:19 PM, Stephen Warren wrote:
> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>> From: Mikko Perttunen
>>
>> Tegra114 TMDS configuration requires a new peak_current field and the
>> driver current override bit has changed position.
>
>> diff --
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> Add a driver for simple panels. Such panels can have a regulator that
> provides the supply voltage and a separate GPIO to enable the panel.
> Optionally the panels can have a backlight associated with them so it
> can be enabled or disabled according
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> This driver adds support to perform calibration of the MIPI pads for CSI
> and DSI.
> diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
> +int tegra_mipi_calibrate(struct device *device)
...
> + err = of_parse_phandle_with_args(
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> This commit adds support for both DSI outputs found on Tegra. Only very
> minimal functionality is implemented, so advanced features like ganged
> mode won't work.
>
> Due to the lack of other test hardware, some sections of the driver are
> hardcode
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and
> Tegra30. No functionaly changes are required.
Similarly here, if the HW is 100% backwards-compatible, there's no need
to add compatible values to the driver.
_
On 10/12/2013 05:32 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:14:27PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> From: Mikko Perttunen
>>>
>>> The Tegra114 display controller is backwards-compatible with
&
On 10/12/2013 05:24 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:13:07PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> Tegra114 uses a slightly updated version of host1x with an
>>> additional syncpoint.
>>
>
On 10/12/2013 05:41 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:19:19PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> From: Mikko Perttunen
>>>
>>> Tegra114 TMDS configuration requires a new peak_current field
>
On 10/13/2013 11:58 PM, Terje Bergström wrote:
> On 12.10.2013 01:43, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and
>>> Tegra30. No functionaly changes are required.
>>
On 10/14/2013 08:00 AM, Thierry Reding wrote:
> On Mon, Oct 14, 2013 at 08:58:34AM +0300, Terje Bergström wrote:
>> On 12.10.2013 01:43, Stephen Warren wrote:
>>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>>> The gr2d hardware in Tegra114 is compatible with th
On 10/14/2013 07:55 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:43:35PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> This commit adds support for both DSI outputs found on Tegra. Only very
>>> minimal functionality
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 +
> dri
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 li
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
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/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&qu
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 ha
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>;
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 th
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 t
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 s
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>;
>> +
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 th
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>; interr
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 integr
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 writi
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 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: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
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 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 th
101 - 200 of 966 matches
Mail list logo
