On 07/02/2014 09:10 PM, Alexandre Courbot wrote:
> On 07/03/2014 12:55 AM, Stephen Warren wrote:
>> On 07/02/2014 06:19 AM, Alexandre Courbot wrote:
>>> DSI support has been fixed to support continuous clock behavior that the
>>> panel used on SHIELD requires, so final
On 06/18/2014 04:21 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> When tegra-drm.ko is built as a module, these MODULE_DEVICE_TABLEs allow
> the module to be auto-loaded since the module will match the devices
> instantiated from device tree.
>
> (Notes for stable:
On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
> Adds functionality for registering memory bandwidth needs and setting
> the EMC clock rate based on that.
>
> Also adds API for setting floor and ceiling frequency rates.
> diff --git
> a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra124-em
On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
> Request it based solely on the current mode's refresh rate. More
> accurate requirements can be requested in future patches.
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> + bandwidth = mode->clock * window.bits_per_pixel
On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
> On 06/16/2014 10:02 PM, Stephen Warren wrote:
>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>> This binding looks quite anaemic vs.
>> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt; I
>> would expect
On 06/18/2014 11:23 AM, Tomeu Vizoso wrote:
> On 06/17/2014 06:15 PM, Stephen Warren wrote:
>> On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
>>> On 06/16/2014 10:02 PM, Stephen Warren wrote:
>>>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>>>&g
From: Stephen Warren
When tegra-drm.ko is built as a module, these MODULE_DEVICE_TABLEs allow
the module to be auto-loaded since the module will match the devices
instantiated from device tree.
(Notes for stable: in 3.14+, just git rm any conflicting file, since they
are added in later kernels
On 06/18/2014 04:03 PM, Thierry Reding wrote:
> On Wed, Jun 18, 2014 at 11:46:49AM -0600, Stephen Warren wrote:
>> On 06/18/2014 11:23 AM, Tomeu Vizoso wrote:
>>> On 06/17/2014 06:15 PM, Stephen Warren wrote:
>>>> On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
>>
On 06/18/2014 03:51 PM, Thierry Reding wrote:
> On Wed, Jun 18, 2014 at 03:19:15PM -0600, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> When tegra-drm.ko is built as a module, these MODULE_DEVICE_TABLEs allow
>> the module to be auto-loaded since the mo
From: Stephen Warren
When tegra-drm.ko is built as a module, these MODULE_DEVICE_TABLEs allow
the module to be auto-loaded since the module will match the devices
instantiated from device tree.
(Notes for stable: in 3.14+, just git rm any conflicting file, since they
are added in later kernels
On 06/18/2014 04:19 PM, St?phane Marchesin wrote:
> On Wed, Jun 18, 2014 at 3:00 PM, Thierry Reding
> wrote:
>> On Wed, Jun 18, 2014 at 07:23:47PM +0200, Tomeu Vizoso wrote:
>>> On 06/17/2014 06:15 PM, Stephen Warren wrote:
>>>> On 06/17/2014 06:16 AM, Tomeu Viz
On 06/18/2014 05:14 PM, Thierry Reding wrote:
> On Wed, Jun 18, 2014 at 04:09:06PM -0600, Stephen Warren wrote:
>> On 06/18/2014 04:03 PM, Thierry Reding wrote:
...
>>> From what I remember, Mike was fairly strongly opposing the idea of
>>> virtual clocks, but what y
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
On 05/15/2014 03:41 PM, Thierry Reding wrote:
> On Thu, May 15, 2014 at 09:54:07AM -0600, Stephen Warren wrote:
>> On 05/15/2014 04:54 AM, Thierry Reding wrote:
>>> On Thu, May 15, 2014 at 12:25:47PM +0200, Philipp Zabel wrote:
>>>> The EDT ETM0700G0DH6 and ET0
On 05/19/2014 03:24 AM, Alexandre Courbot wrote:
> Add the device tree binding documentation for the GK20A GPU used in
> Tegra K1 SoCs.
A few minor nits, but otherwise,
Acked-by: Stephen Warren
> diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
> b/Documentatio
On 05/19/2014 03:24 AM, Alexandre Courbot wrote:
> From: Thierry Reding
>
> Add the GK20A device node to Tegra124's device tree.
At a quick glance, patches 3-5 look fine too. I'll hold off on applying
them until patches 1-2 have been applied to the DRM/... tree.
On 08/12/2015 06:56 PM, Eric Anholt wrote:
> This is the start of a full VC4 driver. Right now this just supports
> configuring the display using a pre-existing video mode (because
> changing the pixel clock isn't available yet, and doesn't work when it
> is). However, this is enough for fbcon an
On 08/12/2015 06:56 PM, Eric Anholt wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> +DRM DRIVERS FOR VC4
> +M: Eric Anholt
> +T: git git://github.com/anholt/linux
> +S: Maintained
> +F: drivers/gpu/drm/vc4/*
S: Supported
?
On 08/12/2015 06:56 PM, Eric Anholt wrote:
> Signed-off-by: Eric Anholt
This one definitely needs a patch description, since someone might not
know what a VC4 is, and "git log" won't show the text from the binding
doc itself. I'd suggest adding the initial paragraph of the binding doc
as the patc
On 08/12/2015 06:56 PM, Eric Anholt wrote:
> We need to use it for getting video modes over HDMI.
> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
> + i2c2: i2c at 7e805000 {
> + compatible = "brcm,bcm2835-i2c";
> +
On 08/12/2015 06:56 PM, Eric Anholt wrote:
> Signed-off-by: Eric Anholt
Patch description?
> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
> arm-pmu {
> compatible = "arm,arm1176-pmu";
> };
> +
> + hdm
On 08/18/2015 03:54 PM, Eric Anholt wrote:
> We need to use it for getting video modes over HDMI.
This patch,
Acked-by: Stephen Warren
On 08/18/2015 03:54 PM, Eric Anholt wrote:
> VC4 is the GPU (display and 3D) present on the 2835.
This patch and patch 1 seem OK to me, although I'll withhold any ack
until the DT binding design discussion with Rob has been resolved. I
haven't looked at the OF graph bindings he mentioned so have n
On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> Playing a bit with todays linux-next on my jetson, it seems this patch is
> still required for enabling the GPU. Is there anything blocking it (firmware
> not available yet in liux-firmware?)
I think initially I was waiting for the DRM patch "drm/nouv
On 09/25/2014 10:41 AM, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
>> On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
>>> Playing a bit with todays linux-next on my jetson, it seems this patch is
>>> still required for enabling
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 11/15/2013 01:53 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> This series implements a common reset framework driver for Tegra, and
> updates all relevant Tegra drivers to use it. It also removes the custom
> DMA bindings and replaced them with the standard
From: Stephen Warren
With CONFIG_DYNAMIC_DEBUG=y, the followin compile error occurs:
drivers/gpu/drm/tegra/mipi-phy.c: In function ?mipi_dphy_timing_validate?:
drivers/gpu/drm/tegra/mipi-phy.c:69:11: error: ?EINVAL? undeclared (first use
in this function)
drivers/gpu/drm/tegra/mipi-phy.c:69:11
On 03/04/2016 01:32 PM, Eric Anholt wrote:
> VC4 is the GPU (display and 3D) present on the 283x.
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> +&hdmi {
> + hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
> +};
Isn't that the same everywhere?
On 03/08/2016 11:04 AM, Eric Anholt wrote:
> Stephen Warren writes:
>
>> On 03/04/2016 01:32 PM, Eric Anholt wrote:
>>> VC4 is the GPU (display and 3D) present on the 283x.
>>
>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
>>> b/arch/arm/
nt 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 LC
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 patch
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 t
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/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
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
> +L: dri-devel at lists.freedesktop.org
Should linux-tegra at vger.kernel.org also be CC'd so that everything
Te
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 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 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_STRID
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 bind
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/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 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/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 videomode_from_timing(
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/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/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
&
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,
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
select
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
>
;ve also 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)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http:
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, but
(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).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
nt 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 LC
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 patch
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 t
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/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
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
> +L: dri-devel@lists.freedesktop.org
Should linux-te...@vger.kernel.org also be CC'd so that everything
Tegra-rela
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 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 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_STRID
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 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 host1x
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/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 relo
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 d
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-dr
On 12/16/2012 09:37 AM, Terje Bergström wrote:
...
> ... Sure we could tell DC to ask its parent
> (host1x), and call host1x driver with platform_device pointer found that
> way, and host1x would return a pointer to tegradrm's data. Hanging the
> data onto host1x driver is just a more complicated w
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
On 12/20/2012 10:46 AM, Terje Bergström wrote:
> On 20.12.2012 19:14, Stephen Warren wrote:
>> I'm not sure that sounds right. drvdata is something that a driver
>> should manage itself.
>>
>> What's wrong with just having each device ask the host1x (its p
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 sta
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
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
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
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
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
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
> b/Documentation/devicet
On 01/07/2013 04:12 PM, Sean Paul wrote:
>
> On Jan 7, 2013 5:32 PM, "Stephen Warren" <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
&
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 wi
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
On 01/16/2013 01:10 AM, Terje Bergström wrote:
> On 15.01.2013 20:44, Stephen Warren wrote:
>> 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.
>>
>&
From: Stephen Warren
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 mono_tim
1 - 100 of 360 matches
Mail list logo
