In the process of adding GEM support for OMAP DRM driver, I noticed that
I was adding code for creating/freeing mmap offsets which was virtually
identical to what was already duplicated in i915 and gma500 drivers.
Rather than duplicating the code a 3rd time, it seemed like a good idea
to move it t
These patches along with the drm and ddx patches enable tiling
on r6xx/r7xx hardware.
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark wrote:
> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
> wrote:
>> On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote:
>>> In the process of adding GEM support for OMAP DRM driver, I noticed that
>>> I was adding code for creating/freeing mmap offsets
>> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
>> wrote:
>>> My only concern is that for the common functions the mmap_offset to create
>>> should be passed in a parameter, so that we could support more than one
>>> mapping for an object.
[ snip ]
> On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark
These patches along with the drm and ddx patches enable tiling
on r6xx/r7xx hardware.
Alex
On Wed, Oct 09, 2013 at 02:54:07PM +0300, Arto Merilainen wrote:
> The host1x driver uses currently syncpoints statically from host1x point of
> view. If we do a wait inside a job, it always has a constant value to wait.
> host1x supports also doing relative syncpoint waits with respect to syncpoin
2012/4/30 Rafał Miłecki :
> This is one more patchset bringing minor improvements to the current
> HDMI implementation. I think after this step I'll start working on
> moving Evergreen HDMI code to the separated file. Some cleanups and
> making ACR re-usable were needed before that.
>
> Patches dep
Hi,
here is the updated patches including the conversion to struct
vga_switcheroo_client_ops.
The patches can be pulled from
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
topic/vga-switcheroo
[background info if anyone hasn't read v1 patch series:
this is for allowing to hand
Hi all,
This patch set adds iommu support for exynos drm framework
and also relevant drivers, fimd and hdmi.
Exynos4xxx SoC and later have some iommu hardware units for
video codec, Camera, Post Processer(FIMC and GScaler), FIMD, HDMI,
Graphics 2D and so on. In other words, each device has its ow
[Dropped lkml, added intel-gfx]
Hi Yuly, here's a slightly modified version of your patch, rebased on
drm-intel-next-queued. I kept your authorship, but any new errors are
totally mine...
These are compile tested only; I'd appreciate if you could check it
still does what it says on the box!
BR,
On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> Hello,
>
> Here's a new DRM driver for the Renesas R-Car Display Unit (DU).
>
> The DU features two superposition processors (modeled as CRTCs) and eight
> planes that can be shared between the superposition processors.
>
> The
Hi Simon,
On Thursday 31 January 2013 15:38:38 Simon Horman wrote:
> On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> > Hello,
> >
> > Here's a new DRM driver for the Renesas R-Car Display Unit (DU).
> >
> > The DU features two superposition processors (modeled as CRTCs) and e
On Fri, Feb 01, 2013 at 04:15:31AM +0100, Laurent Pinchart wrote:
> Hi Simon,
>
> On Thursday 31 January 2013 15:38:38 Simon Horman wrote:
> > On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> > > Hello,
> > >
> > > Here's a new DRM driver for the Renesas R-Car Display Unit (DU)
Patch one is a simple bug fix for G200ER cards.
Patch two doesn't change any code
Patch three makes the mgag200 driver use managed devices where
possible. I'm not too sure how to test this one properly, other than
to just boot a bunch of boards and stare at the code changes for a
long while. Any
Hi all,
This series here implements an interface to enable cpu access from the kernel
context to dma_buf objects. The main design goal of this interface proposal is
to enable buffer objects that reside in highmem.
Comments, flames, ideas and questions highly welcome. Althouhg I might be a bit
slo
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
Hi all,
This patch set adds iommu support for exynos drm framework
and also relevant drivers, fimd and hdmi.
Exynos4xxx SoC and later have some iommu hardware units for
video codec, Camera, Post Processer(FIMC and GScaler), FIMD, HDMI,
Graphics 2D and so on. In other words, each device has its ow
[Dropped lkml, added intel-gfx]
Hi Yuly, here's a slightly modified version of your patch, rebased on
drm-intel-next-queued. I kept your authorship, but any new errors are
totally mine...
These are compile tested only; I'd appreciate if you could check it
still does what it says on the box!
BR,
Hi all,
This series here implements an interface to enable cpu access from the kernel
context to dma_buf objects. The main design goal of this interface proposal is
to enable buffer objects that reside in highmem.
Comments, flames, ideas and questions highly welcome. Althouhg I might be a bit
slo
2012/4/30 Rafał Miłecki :
> This is one more patchset bringing minor improvements to the current
> HDMI implementation. I think after this step I'll start working on
> moving Evergreen HDMI code to the separated file. Some cleanups and
> making ACR re-usable were needed before that.
>
> Patches dep
Hi,
here is the updated patches including the conversion to struct
vga_switcheroo_client_ops.
The patches can be pulled from
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
topic/vga-switcheroo
[background info if anyone hasn't read v1 patch series:
this is for allowing to hand
On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> Hello,
>
> Here's a new DRM driver for the Renesas R-Car Display Unit (DU).
>
> The DU features two superposition processors (modeled as CRTCs) and eight
> planes that can be shared between the superposition processors.
>
> The
Hi Simon,
On Thursday 31 January 2013 15:38:38 Simon Horman wrote:
> On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> > Hello,
> >
> > Here's a new DRM driver for the Renesas R-Car Display Unit (DU).
> >
> > The DU features two superposition processors (modeled as CRTCs) and e
On Fri, Feb 01, 2013 at 04:15:31AM +0100, Laurent Pinchart wrote:
> Hi Simon,
>
> On Thursday 31 January 2013 15:38:38 Simon Horman wrote:
> > On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> > > Hello,
> > >
> > > Here's a new DRM driver for the Renesas R-Car Display Unit (DU)
On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook wrote:
>
> This patch set fixes Alpha-specific support in the DRM code,
> allowing Radeon KMS and the MGA driver to work properly on
> Alpha-based machines.
>
> Jay
>
> Jay Estabrook (3):
> alpha, drm: Update Alpha DRM support
> alpha, drm: Cleanup A
In the process of adding GEM support for OMAP DRM driver, I noticed that
I was adding code for creating/freeing mmap offsets which was virtually
identical to what was already duplicated in i915 and gma500 drivers.
Rather than duplicating the code a 3rd time, it seemed like a good idea
to move it t
These patches along with the drm and ddx patches enable tiling
on r6xx/r7xx hardware.
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
Patch one is a simple bug fix for G200ER cards.
Patch two doesn't change any code
Patch three makes the mgag200 driver use managed devices where
possible. I'm not too sure how to test this one properly, other than
to just boot a bunch of boards and stare at the code changes for a
long while. Any
These patches along with the drm and ddx patches enable tiling
on r6xx/r7xx hardware.
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook wrote:
>
> This patch set fixes Alpha-specific support in the DRM code,
> allowing Radeon KMS and the MGA driver to work properly on
> Alpha-based machines.
>
> Jay
>
> Jay Estabrook (3):
> alpha, drm: Update Alpha DRM support
> alpha, drm: Cleanup A
On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark wrote:
> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
> wrote:
>> On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote:
>>> In the process of adding GEM support for OMAP DRM driver, I noticed that
>>> I was adding code for creating/freeing mmap offsets
>> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
>> wrote:
>>> My only concern is that for the common functions the mmap_offset to create
>>> should be passed in a parameter, so that we could support more than one
>>> mapping for an object.
[ snip ]
> On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark
On Wed, Oct 09, 2013 at 02:54:07PM +0300, Arto Merilainen wrote:
> The host1x driver uses currently syncpoints statically from host1x point of
> view. If we do a wait inside a job, it always has a constant value to wait.
> host1x supports also doing relative syncpoint waits with respect to syncpoin
These patches along with the drm and ddx patches enable tiling
on r6xx/r7xx hardware.
Alex
On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> Hello,
>
> Here's a new DRM driver for the Renesas R-Car Display Unit (DU).
>
> The DU features two superposition processors (modeled as CRTCs) and eight
> planes that can be shared between the superposition processors.
>
> The
Hi Simon,
On Thursday 31 January 2013 15:38:38 Simon Horman wrote:
> On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> > Hello,
> >
> > Here's a new DRM driver for the Renesas R-Car Display Unit (DU).
> >
> > The DU features two superposition processors (modeled as CRTCs) and e
On Fri, Feb 01, 2013 at 04:15:31AM +0100, Laurent Pinchart wrote:
> Hi Simon,
>
> On Thursday 31 January 2013 15:38:38 Simon Horman wrote:
> > On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> > > Hello,
> > >
> > > Here's a new DRM driver for the Renesas R-Car Display Unit (DU)
Hi all,
This patch set adds iommu support for exynos drm framework
and also relevant drivers, fimd and hdmi.
Exynos4xxx SoC and later have some iommu hardware units for
video codec, Camera, Post Processer(FIMC and GScaler), FIMD, HDMI,
Graphics 2D and so on. In other words, each device has its ow
[Dropped lkml, added intel-gfx]
Hi Yuly, here's a slightly modified version of your patch, rebased on
drm-intel-next-queued. I kept your authorship, but any new errors are
totally mine...
These are compile tested only; I'd appreciate if you could check it
still does what it says on the box!
BR,
In the process of adding GEM support for OMAP DRM driver, I noticed that
I was adding code for creating/freeing mmap offsets which was virtually
identical to what was already duplicated in i915 and gma500 drivers.
Rather than duplicating the code a 3rd time, it seemed like a good idea
to move it t
2012/4/30 Rafał Miłecki :
> This is one more patchset bringing minor improvements to the current
> HDMI implementation. I think after this step I'll start working on
> moving Evergreen HDMI code to the separated file. Some cleanups and
> making ACR re-usable were needed before that.
>
> Patches dep
Hi,
here is the updated patches including the conversion to struct
vga_switcheroo_client_ops.
The patches can be pulled from
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
topic/vga-switcheroo
[background info if anyone hasn't read v1 patch series:
this is for allowing to hand
Hi all,
This series here implements an interface to enable cpu access from the kernel
context to dma_buf objects. The main design goal of this interface proposal is
to enable buffer objects that reside in highmem.
Comments, flames, ideas and questions highly welcome. Althouhg I might be a bit
slo
Patch one is a simple bug fix for G200ER cards.
Patch two doesn't change any code
Patch three makes the mgag200 driver use managed devices where
possible. I'm not too sure how to test this one properly, other than
to just boot a bunch of boards and stare at the code changes for a
long while. Any
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
On Wed, Oct 09, 2013 at 02:54:07PM +0300, Arto Merilainen wrote:
> The host1x driver uses currently syncpoints statically from host1x point of
> view. If we do a wait inside a job, it always has a constant value to wait.
> host1x supports also doing relative syncpoint waits with respect to syncpoin
On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark wrote:
> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
> wrote:
>> On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote:
>>> In the process of adding GEM support for OMAP DRM driver, I noticed that
>>> I was adding code for creating/freeing mmap offsets
>> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
>> wrote:
>>> My only concern is that for the common functions the mmap_offset to create
>>> should be passed in a parameter, so that we could support more than one
>>> mapping for an object.
[ snip ]
> On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark
Patch one is a simple bug fix for G200ER cards.
Patch two doesn't change any code
Patch three makes the mgag200 driver use managed devices where
possible. I'm not too sure how to test this one properly, other than
to just boot a bunch of boards and stare at the code changes for a
long while. Any
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
On Wed, Oct 09, 2013 at 02:54:07PM +0300, Arto Merilainen wrote:
> The host1x driver uses currently syncpoints statically from host1x point of
> view. If we do a wait inside a job, it always has a constant value to wait.
> host1x supports also doing relative syncpoint waits with respect to syncpoin
On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook wrote:
>
> This patch set fixes Alpha-specific support in the DRM code,
> allowing Radeon KMS and the MGA driver to work properly on
> Alpha-based machines.
>
> Jay
>
> Jay Estabrook (3):
> alpha, drm: Update Alpha DRM support
> alpha, drm: Cleanup A
On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark wrote:
> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
> wrote:
>> On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote:
>>> In the process of adding GEM support for OMAP DRM driver, I noticed that
>>> I was adding code for creating/freeing mmap offsets
>> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
>> wrote:
>>> My only concern is that for the common functions the mmap_offset to create
>>> should be passed in a parameter, so that we could support more than one
>>> mapping for an object.
[ snip ]
> On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark
These patches along with the drm and ddx patches enable tiling
on r6xx/r7xx hardware.
Alex
Hi all,
This patch set adds iommu support for exynos drm framework
and also relevant drivers, fimd and hdmi.
Exynos4xxx SoC and later have some iommu hardware units for
video codec, Camera, Post Processer(FIMC and GScaler), FIMD, HDMI,
Graphics 2D and so on. In other words, each device has its ow
[Dropped lkml, added intel-gfx]
Hi Yuly, here's a slightly modified version of your patch, rebased on
drm-intel-next-queued. I kept your authorship, but any new errors are
totally mine...
These are compile tested only; I'd appreciate if you could check it
still does what it says on the box!
BR,
In the process of adding GEM support for OMAP DRM driver, I noticed that
I was adding code for creating/freeing mmap offsets which was virtually
identical to what was already duplicated in i915 and gma500 drivers.
Rather than duplicating the code a 3rd time, it seemed like a good idea
to move it t
2012/4/30 Rafał Miłecki :
> This is one more patchset bringing minor improvements to the current
> HDMI implementation. I think after this step I'll start working on
> moving Evergreen HDMI code to the separated file. Some cleanups and
> making ACR re-usable were needed before that.
>
> Patches dep
Hi,
here is the updated patches including the conversion to struct
vga_switcheroo_client_ops.
The patches can be pulled from
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
topic/vga-switcheroo
[background info if anyone hasn't read v1 patch series:
this is for allowing to hand
Hi all,
This series here implements an interface to enable cpu access from the kernel
context to dma_buf objects. The main design goal of this interface proposal is
to enable buffer objects that reside in highmem.
Comments, flames, ideas and questions highly welcome. Althouhg I might be a bit
slo
These patches along with the drm and ddx patches enable tiling
on r6xx/r7xx hardware.
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
These patches along with the drm and ddx patches enable tiling
on r6xx/r7xx hardware.
Alex
On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark wrote:
> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
> wrote:
>> On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote:
>>> In the process of adding GEM support for OMAP DRM driver, I noticed that
>>> I was adding code for creating/freeing mmap offsets
>> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
>> wrote:
>>> My only concern is that for the common functions the mmap_offset to create
>>> should be passed in a parameter, so that we could support more than one
>>> mapping for an object.
[ snip ]
> On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark
These patches along with the drm and ddx patches enable tiling
on r6xx/r7xx hardware.
Alex
On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> Hello,
>
> Here's a new DRM driver for the Renesas R-Car Display Unit (DU).
>
> The DU features two superposition processors (modeled as CRTCs) and eight
> planes that can be shared between the superposition processors.
>
> The
Hi Simon,
On Thursday 31 January 2013 15:38:38 Simon Horman wrote:
> On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> > Hello,
> >
> > Here's a new DRM driver for the Renesas R-Car Display Unit (DU).
> >
> > The DU features two superposition processors (modeled as CRTCs) and e
On Fri, Feb 01, 2013 at 04:15:31AM +0100, Laurent Pinchart wrote:
> Hi Simon,
>
> On Thursday 31 January 2013 15:38:38 Simon Horman wrote:
> > On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> > > Hello,
> > >
> > > Here's a new DRM driver for the Renesas R-Car Display Unit (DU)
Hi all,
This patch set adds iommu support for exynos drm framework
and also relevant drivers, fimd and hdmi.
Exynos4xxx SoC and later have some iommu hardware units for
video codec, Camera, Post Processer(FIMC and GScaler), FIMD, HDMI,
Graphics 2D and so on. In other words, each device has its ow
[Dropped lkml, added intel-gfx]
Hi Yuly, here's a slightly modified version of your patch, rebased on
drm-intel-next-queued. I kept your authorship, but any new errors are
totally mine...
These are compile tested only; I'd appreciate if you could check it
still does what it says on the box!
BR,
In the process of adding GEM support for OMAP DRM driver, I noticed that
I was adding code for creating/freeing mmap offsets which was virtually
identical to what was already duplicated in i915 and gma500 drivers.
Rather than duplicating the code a 3rd time, it seemed like a good idea
to move it t
2012/4/30 Rafał Miłecki :
> This is one more patchset bringing minor improvements to the current
> HDMI implementation. I think after this step I'll start working on
> moving Evergreen HDMI code to the separated file. Some cleanups and
> making ACR re-usable were needed before that.
>
> Patches dep
Hi,
here is the updated patches including the conversion to struct
vga_switcheroo_client_ops.
The patches can be pulled from
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
topic/vga-switcheroo
[background info if anyone hasn't read v1 patch series:
this is for allowing to hand
Hi all,
This series here implements an interface to enable cpu access from the kernel
context to dma_buf objects. The main design goal of this interface proposal is
to enable buffer objects that reside in highmem.
Comments, flames, ideas and questions highly welcome. Althouhg I might be a bit
slo
Patch one is a simple bug fix for G200ER cards.
Patch two doesn't change any code
Patch three makes the mgag200 driver use managed devices where
possible. I'm not too sure how to test this one properly, other than
to just boot a bunch of boards and stare at the code changes for a
long while. Any
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
For various revision of chipset if the signal pattern is changed for every
board, then the phy setting need to be updated correspondingly by measuring
the signal.
With the hdmiphy settings fixed in the driver the only way currently is to
either add a new structure or add compile time option.
To av
On Wed, Oct 09, 2013 at 02:54:07PM +0300, Arto Merilainen wrote:
> The host1x driver uses currently syncpoints statically from host1x point of
> view. If we do a wait inside a job, it always has a constant value to wait.
> host1x supports also doing relative syncpoint waits with respect to syncpoin
These patches along with the drm and ddx patches enable tiling
on r6xx/r7xx hardware.
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook wrote:
>
> This patch set fixes Alpha-specific support in the DRM code,
> allowing Radeon KMS and the MGA driver to work properly on
> Alpha-based machines.
>
> Jay
>
> Jay Estabrook (3):
> alpha, drm: Update Alpha DRM support
> alpha, drm: Cleanup A
On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> Hello,
>
> Here's a new DRM driver for the Renesas R-Car Display Unit (DU).
>
> The DU features two superposition processors (modeled as CRTCs) and eight
> planes that can be shared between the superposition processors.
>
> The
Hi Simon,
On Thursday 31 January 2013 15:38:38 Simon Horman wrote:
> On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> > Hello,
> >
> > Here's a new DRM driver for the Renesas R-Car Display Unit (DU).
> >
> > The DU features two superposition processors (modeled as CRTCs) and e
On Fri, Feb 01, 2013 at 04:15:31AM +0100, Laurent Pinchart wrote:
> Hi Simon,
>
> On Thursday 31 January 2013 15:38:38 Simon Horman wrote:
> > On Thu, Jan 31, 2013 at 02:45:00AM +0100, Laurent Pinchart wrote:
> > > Hello,
> > >
> > > Here's a new DRM driver for the Renesas R-Car Display Unit (DU)
On Mon, 18 Jul 2011 19:20:56 -0500
Rob Clark wrote:
> In the process of adding GEM support for OMAP DRM driver, I noticed that
> I was adding code for creating/freeing mmap offsets which was virtually
> identical to what was already duplicated in i915 and gma500 drivers.
The gma500 one was taken
On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote:
> In the process of adding GEM support for OMAP DRM driver, I noticed that
> I was adding code for creating/freeing mmap offsets which was virtually
> identical to what was already duplicated in i915 and gma500 drivers.
>
> Rather than duplicat
On Tue, Jul 19, 2011 at 3:57 AM, Alan Cox wrote:
> On Mon, 18 Jul 2011 19:20:56 -0500
> Rob Clark wrote:
>
>> In the process of adding GEM support for OMAP DRM driver, I noticed that
>> I was adding code for creating/freeing mmap offsets which was virtually
>> identical to what was already duplic
On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson
wrote:
> On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote:
>> In the process of adding GEM support for OMAP DRM driver, I noticed that
>> I was adding code for creating/freeing mmap offsets which was virtually
>> identical to what was already dupl
> ahh, ok.. I should check this out (although I'm not entirely sure
> where your gma500 staging tree is)
Its in GregKH's staging tree or linux-next. It's basically what you've
done so if your patch is submitted it'll take me 2 minutes to fix the
gma500 tree.
> I'm already using your patch to add
This series fixes some checkpatch warnings and errors in drm_fb_helper.c file.
Build tested using the linux-next tree of 20121114.
Sachin Kamat (3):
drm/fb_helper: Fix checkpatch errors
drm/fb_helper: Convert printk to pr_* and dev_*
drm/drm_fb_helper: Remove unnecessary braces
drivers/gpu
701 - 800 of 1231 matches
Mail list logo
