On Fri, Jun 14, 2013 at 09:50:22PM +0200, Daniel Vetter wrote:
> On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
> wrote:
> > If you're happy with the patch I supplied, that's probably the minimal fix
> > which should go to stable kernels (I'm using 3.9 here) - this also counts
> > as a
On Fri, Jun 14, 2013 at 04:23:22PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2013 at 3:03 PM, Russell King - ARM Linux
> wrote:
> > There's a bigger issue here - if it's possible for
> > drm_crtc_helper_set_config()
> > to be called with set->fb set but set->mode NULL, then we overwrite
> > s
On Fri, Jun 14, 2013 at 03:53:41PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > > The deeper I look, the more bugs there seem to be in this DRM stuff,
> > > a
On Sat, Jun 15, 2013 at 12:15 AM, Russell King - ARM Linux
wrote:
> On Fri, Jun 14, 2013 at 09:50:22PM +0200, Daniel Vetter wrote:
>> On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
>> wrote:
>> > If you're happy with the patch I supplied, that's probably the minimal fix
>> > which shou
On Fri, Jun 14, 2013 at 09:50:22PM +0200, Daniel Vetter wrote:
> On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
> wrote:
> > If you're happy with the patch I supplied, that's probably the minimal fix
> > which should go to stable kernels (I'm using 3.9 here) - this also counts
> > as a
On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
wrote:
> On Fri, Jun 14, 2013 at 04:23:22PM +0200, Daniel Vetter wrote:
>> On Thu, Jun 13, 2013 at 3:03 PM, Russell King - ARM Linux
>> wrote:
>> > There's a bigger issue here - if it's possible for
>> > drm_crtc_helper_set_config()
>> >
On Thu, Jun 13, 2013 at 3:03 PM, Russell King - ARM Linux
wrote:
> On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
>> On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
>> > The deeper I look, the more bugs there seem to be in this DRM stuff,
>> > a
On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > The deeper I look, the more bugs there seem to be in this DRM stuff,
> > and I'm continuing to look because I'm chasing a framebuffer refcount
>
On Fri, Jun 14, 2013 at 04:23:22PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2013 at 3:03 PM, Russell King - ARM Linux
> wrote:
> > There's a bigger issue here - if it's possible for
> > drm_crtc_helper_set_config()
> > to be called with set->fb set but set->mode NULL, then we overwrite
> > s
On Sat, Jun 15, 2013 at 12:15 AM, Russell King - ARM Linux
wrote:
> On Fri, Jun 14, 2013 at 09:50:22PM +0200, Daniel Vetter wrote:
>> On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
>> wrote:
>> > If you're happy with the patch I supplied, that's probably the minimal fix
>> > which shou
On Fri, Jun 14, 2013 at 03:53:41PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > > The deeper I look, the more bugs there seem to be in this DRM stuff,
> > > a
On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
wrote:
> On Fri, Jun 14, 2013 at 04:23:22PM +0200, Daniel Vetter wrote:
>> On Thu, Jun 13, 2013 at 3:03 PM, Russell King - ARM Linux
>> wrote:
>> > There's a bigger issue here - if it's possible for
>> > drm_crtc_helper_set_config()
>> >
On Thu, Jun 13, 2013 at 3:03 PM, Russell King - ARM Linux
wrote:
> On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
>> On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
>> > The deeper I look, the more bugs there seem to be in this DRM stuff,
>> > a
On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > The deeper I look, the more bugs there seem to be in this DRM stuff,
> > and I'm continuing to look because I'm chasing a framebuffer refcount
>
On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > The deeper I look, the more bugs there seem to be in this DRM stuff,
> > and I'm continuing to look because I'm chasing a framebuffer refcount
>
On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> The deeper I look, the more bugs there seem to be in this DRM stuff,
> and I'm continuing to look because I'm chasing a framebuffer refcount
> bug.
So, this refcount bug - I think I've just found it. This is the flow of
r
And another issue...
What is drm_crtc_helper_set_mode() passed as the fb argument? Is it
the old fb, or the new fb?
bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
struct drm_display_mode *mode,
int x, int y,
On Thu, Jun 13, 2013 at 2:52 PM, Rob Clark wrote:
> most of the embedded drivers should ignore the old_fb.. the API is a
> bit odd but the purpose is to help drivers that need to pin/unpin the
> gem objects backing the fb. The ones that do, do something like:
>
> foo_pin(new_fb);
> foo_unpin(
On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > The deeper I look, the more bugs there seem to be in this DRM stuff,
> > and I'm continuing to look because I'm chasing a framebuffer refcount
>
On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> The deeper I look, the more bugs there seem to be in this DRM stuff,
> and I'm continuing to look because I'm chasing a framebuffer refcount
> bug.
So, this refcount bug - I think I've just found it. This is the flow of
r
And another issue...
What is drm_crtc_helper_set_mode() passed as the fb argument? Is it
the old fb, or the new fb?
bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
struct drm_display_mode *mode,
int x, int y,
On Thu, Jun 13, 2013 at 7:19 AM, Russell King - ARM Linux
wrote:
> And another issue...
>
> What is drm_crtc_helper_set_mode() passed as the fb argument? Is it
> the old fb, or the new fb?
>
> bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
> struct drm_display_
On Thu, Jun 13, 2013 at 2:52 PM, Rob Clark wrote:
> most of the embedded drivers should ignore the old_fb.. the API is a
> bit odd but the purpose is to help drivers that need to pin/unpin the
> gem objects backing the fb. The ones that do, do something like:
>
> foo_pin(new_fb);
> foo_unpin(
On Thu, Jun 13, 2013 at 7:19 AM, Russell King - ARM Linux
wrote:
> And another issue...
>
> What is drm_crtc_helper_set_mode() passed as the fb argument? Is it
> the old fb, or the new fb?
>
> bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
> struct drm_display_
And here's another one - look carefully at this path:
buf = dev->driver->gem_prime_export(dev, obj, flags);
if (IS_ERR(buf)) {
/* normally the created dma-buf takes ownership of the
ref,
* but if that fails then drop
And here's another one - look carefully at this path:
buf = dev->driver->gem_prime_export(dev, obj, flags);
if (IS_ERR(buf)) {
/* normally the created dma-buf takes ownership of the
ref,
* but if that fails then drop
On Wed, Jun 12, 2013 at 06:05:12PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> > > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> > > wrote:
> > > >
On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> > wrote:
> > > And having thought about this driver, DRM some more, I'm now of the
> > > opinion th
On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> wrote:
> > And having thought about this driver, DRM some more, I'm now of the
> > opinion that DRM is not suitable for driving hardware where the GPU is
> > an entirely separat
On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
> >> their requirements
> >>
On Wed, Jun 12, 2013 at 06:05:12PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> > > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> > > wrote:
> > > >
On Wed, Jun 12, 2013 at 7:00 PM, Russell King - ARM Linux
wrote:
> And here's another one - look carefully at this path:
>
> buf = dev->driver->gem_prime_export(dev, obj, flags);
> if (IS_ERR(buf)) {
> /* normally the created dma-buf takes ow
On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> > wrote:
> > > And having thought about this driver, DRM some more, I'm now of the
> > > opinion th
On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> wrote:
> > And having thought about this driver, DRM some more, I'm now of the
> > opinion that DRM is not suitable for driving hardware where the GPU is
> > an entirely separat
On Wed, Jun 12, 2013 at 7:00 PM, Russell King - ARM Linux
wrote:
> And here's another one - look carefully at this path:
>
> buf = dev->driver->gem_prime_export(dev, obj, flags);
> if (IS_ERR(buf)) {
> /* normally the created dma-buf takes ow
On Wed, Jun 12, 2013 at 1:05 PM, Russell King - ARM Linux
wrote:
> On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
>> On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
>> > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
>> > wrote:
>> > > And having t
On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
> >> their requirements
> >>
On Wed, Jun 12, 2013 at 1:05 PM, Russell King - ARM Linux
wrote:
> On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
>> On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
>> > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
>> > wrote:
>> > > And having t
On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
>> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
>> wrote:
>> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
>> >> I'd like to see all the AR
On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
>> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
>> wrote:
>> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
>> >> I'd like to see all the AR
On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> >>> On Sun, Jun 9, 2013 at 3:29 PM, Russell
On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
>> I'd like to see all the ARM based drivers based on CMA if it can meet
>> their requirements
>> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
>
On Mon, Jun 10, 2013 at 11:32:54PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> > On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > > wrote:
> > >> On Mon, Jun 10, 2013
>>
>> That makes the driver just be a dumb scanout only driver. Sorry,
>> that *really* does not interest me one bit, because the CPU doing
>> framebuffer accesses is pig slow.
>
> Well, yes that is basically what I am saying, unless we can find a
> different way (dmabuf? if there is some way to p
On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> >>> On Sun, Jun 9, 2013 at 3:29 PM, Russell
On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
> >> their requirements
> >>
On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> >> I guess in the short term, the best I can think is keep those phys
> >> ioctls as a small patch on top
On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> I'd like to see all the ARM based drivers based on CMA if it can meet
> their requirements
> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
> come an unmaintainable
> nightmare for everyone, but mostly for me.
I
On Mon, Jun 10, 2013 at 11:32:54PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> > On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > > wrote:
> > >> On Mon, Jun 10, 2013
On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> wrote:
>> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>>> wrote:
>>> > This patch adds support for the pair of LCD contr
On 06/10/2013 11:48 PM, Russell King - ARM Linux wrote:
> On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
>> On 06/09/13 21:29, Russell King wrote:
>>> +static const struct armada_output_type armada_drm_conn_slave = {
>>> + .connector_type = DRM_MODE_CONNECTOR_HDMIA,
>>
>>
On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> I guess in the short term, the best I can think is keep those phys
> ioctls as a small patch on top of the upstream driver. It is ok to
> leave place-holder ioctl #'s in the upstream driver so that the ioctl
> #'s don't shift when you re
On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> >>> On Sun, Jun 9, 2013 at 3:29 PM, Russell
On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
> >> their requirements
> >>
On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> >> I guess in the short term, the best I can think is keep those phys
> >> ioctls as a small patch on top
On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> I'd like to see all the ARM based drivers based on CMA if it can meet
> their requirements
> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
> come an unmaintainable
> nightmare for everyone, but mostly for me.
I
On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> I guess in the short term, the best I can think is keep those phys
> ioctls as a small patch on top of the upstream driver. It is ok to
> leave place-holder ioctl #'s in the upstream driver so that the ioctl
> #'s don't shift when you re
On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
> On 06/09/13 21:29, Russell King wrote:
>> +/*
>> + * The spec is unclear about the polarities of the syncs.
>> + * We assume their non-inverted state is active high.
>> + */
>
> nit: "We confirmed their non-inv
On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> >>> On Sun, Jun 9, 2013 at 3:29 PM, Russell
On 06/10/2013 11:48 PM, Russell King - ARM Linux wrote:
On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
On 06/09/13 21:29, Russell King wrote:
+static const struct armada_output_type armada_drm_conn_slave = {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
For a rew
On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
> On 06/09/13 21:29, Russell King wrote:
>> +/*
>> + * The spec is unclear about the polarities of the syncs.
>> + * We assume their non-inverted state is active high.
>> + */
>
> nit: "We confirmed their non-inv
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> wrote:
> > +/* The mode_config.mutex will be held for this call */
> > +static int armada_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int
> > y,
> > + struct drm_framebuffer
On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
> I would like to get at least some of the driver upstream. I'd hate
> for it to have to live completely out of tree. I can think of a
> couple possibilities.
>
> 1) the best would be, if there was some way for the drm driver to know
> t
On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> wrote:
> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
> > a chunk of physical memory allocated by other means (eg, the Vmeta stuff.)
> > This allows
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> wrote:
> > This patch adds support for the pair of LCD controllers on the Marvell
> > Armada 510 SoCs. This driver supports:
> > - multiple contiguous scanout buffers for video and graphics
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> wrote:
> > +/* The mode_config.mutex will be held for this call */
> > +static int armada_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int
> > y,
> > + struct drm_framebuffer
On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
> I would like to get at least some of the driver upstream. I'd hate
> for it to have to live completely out of tree. I can think of a
> couple possibilities.
>
> 1) the best would be, if there was some way for the drm driver to know
> t
On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> wrote:
> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
> > a chunk of physical memory allocated by other means (eg, the Vmeta stuff.)
> > This allows
On Mon, Jun 10, 2013 at 7:38 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
>> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
>> wrote:
>> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
>> >> I guess in the short term, the
On Mon, Jun 10, 2013 at 7:24 PM, Dave Airlie wrote:
>>>
>>> That makes the driver just be a dumb scanout only driver. Sorry,
>>> that *really* does not interest me one bit, because the CPU doing
>>> framebuffer accesses is pig slow.
>>
>> Well, yes that is basically what I am saying, unless we ca
On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
>> I guess in the short term, the best I can think is keep those phys
>> ioctls as a small patch on top of the upstream driver. It is ok to
>> leave place-holder ioctl #'s
On Mon, Jun 10, 2013 at 6:32 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
>> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
>> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>> > wrote:
>> >> On Mon, Jun 10, 2013 at 11:57:32
On Mon, Jun 10, 2013 at 5:15 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
>> I would like to get at least some of the driver upstream. I'd hate
>> for it to have to live completely out of tree. I can think of a
>> couple possibilities.
>>
>> 1)
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> wrote:
> > This patch adds support for the pair of LCD controllers on the Marvell
> > Armada 510 SoCs. This driver supports:
> > - multiple contiguous scanout buffers for video and graphics
On Mon, Jun 10, 2013 at 4:08 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
>> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>> wrote:
>> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
>> > a chunk of physica
On Mon, Jun 10, 2013 at 7:38 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
>> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
>> wrote:
>> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
>> >> I guess in the short term, the
On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
>> I'd like to see all the ARM based drivers based on CMA if it can meet
>> their requirements
>> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
>
On Mon, Jun 10, 2013 at 7:24 PM, Dave Airlie wrote:
>>>
>>> That makes the driver just be a dumb scanout only driver. Sorry,
>>> that *really* does not interest me one bit, because the CPU doing
>>> framebuffer accesses is pig slow.
>>
>> Well, yes that is basically what I am saying, unless we ca
>>
>> That makes the driver just be a dumb scanout only driver. Sorry,
>> that *really* does not interest me one bit, because the CPU doing
>> framebuffer accesses is pig slow.
>
> Well, yes that is basically what I am saying, unless we can find a
> different way (dmabuf? if there is some way to p
On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
>> I guess in the short term, the best I can think is keep those phys
>> ioctls as a small patch on top of the upstream driver. It is ok to
>> leave place-holder ioctl #'s
On Mon, Jun 10, 2013 at 6:32 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
>> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
>> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>> > wrote:
>> >> On Mon, Jun 10, 2013 at 11:57:32
On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>> wrote:
>> > This patch adds support for the pair of LCD controllers on the Marvell
>> > Armada 510 SoCs. This driver su
On Mon, Jun 10, 2013 at 5:15 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
>> I would like to get at least some of the driver upstream. I'd hate
>> for it to have to live completely out of tree. I can think of a
>> couple possibilities.
>>
>> 1)
On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> wrote:
>> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>>> wrote:
>>> > This patch adds support for the pair of LCD contr
On Mon, Jun 10, 2013 at 4:08 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
>> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>> wrote:
>> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
>> > a chunk of physica
On 06/09/13 21:29, Russell King wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs. This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
>acceler
On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>> wrote:
>> > This patch adds support for the pair of LCD controllers on the Marvell
>> > Armada 510 SoCs. This driver su
On Sun, Jun 9, 2013 at 3:29 PM, Russell King
wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs. This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GP
On Sun, Jun 9, 2013 at 3:29 PM, Russell King
wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs. This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GP
On 06/09/13 21:29, Russell King wrote:
This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 SoCs. This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
acceleration
-
This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 SoCs. This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
acceleration
- dual lcd0 and lcd1 crt operation
- video o
91 matches
Mail list logo
