All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Rob Clark <rob.clark@linaro.org>
Cc: dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org,
	patches@linaro.org, Greg KH <greg@kroah.com>,
	Andy Gross <andy.gross@ti.com>
Subject: Re: [PATCH] omap2+: add drm device
Date: Wed, 14 Mar 2012 15:07:45 +0200	[thread overview]
Message-ID: <1331730465.1542.8.camel@lappy> (raw)
In-Reply-To: <CAF6AEGvBB3AVrfXnpZwZCZGy48Re5sxm-jgLxSpH=nLzLKe0iA@mail.gmail.com>

On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
> On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > Hi,
> >
> > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
> >> From: Andy Gross <andy.gross@ti.com>
> >>
> >> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> >> the device to use for buffer allocation.  DMM is split into a
> >> separate device using hwmod.
> >
> > What's the diff with this and the previous one?
> 
> Moving drm.c to mach-omap2 (header could not move because
> omap_reserve() is in plat-omap.. but this seems to be the same as what
> is done for dspbridge).
> 
> > I see you still have the platform data there. You didn't comment on
> > that. Where is it used after the board files are gone when we use DT?
> 
> I was kind-of thinking that there would be some DT<->data-structure
> glue somewhere.. not sure if this goes in mach-omap2 or in the driver
> itself, but presumably it is needed somewhere.
> 
> It is only really special cases where some board specific device-tree
> data is needed, so it seems like this is ok to handle later.

Afaik DT data should only contain information about the hardware. This
is SW configuration, so I think DT people won't accept things like that.

> > And how about the size of the contiguous memory area, it was left a bit
> > unclear to me why it cannot be dynamic.
> 
> I don't think there is anything preventing adding a bootarg, but I
> think it is not essential so ok to add later

Well, maybe not essential to you =). But you are reserving 32MB memory,
which is quite a big amount. Even if the reserved memory can be used for
some other purposes, it's still a big chunk of "special" memory being
reserved even if the user doesn't use or have a display at all.

Well, it's not an issue for me either, but I just feel that doing things
like that without allowing the user to avoid it is a bit bad thing.

Btw, do you know why the dma_declare_contiguous() takes a dev pointer as
an argument, if the memory is not private to that device? (at least I
understood from you that the memory can be used for other purposes).

 Tomi



  reply	other threads:[~2012-03-14 13:07 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-13 20:34 [PATCH] omap2+: add drm device Rob Clark
2012-03-14 12:38 ` Tomi Valkeinen
2012-03-14 12:55   ` Rob Clark
2012-03-14 13:07     ` Tomi Valkeinen [this message]
2012-03-14 13:16       ` Rob Clark
2012-03-14 13:43         ` Tomi Valkeinen
2012-03-14 15:06           ` Rob Clark
2012-03-15  8:46             ` Tomi Valkeinen
2012-03-15 12:32               ` Rob Clark
2012-03-16 11:03                 ` Tomi Valkeinen
  -- strict thread matches above, loose matches on Subject: below --
2012-05-23 20:08 Andy Gross
2012-05-24  6:01 ` Tomi Valkeinen
2012-05-24  6:27   ` Clark, Rob
2012-05-24  7:05     ` Tomi Valkeinen
2012-05-24  7:21       ` Tomi Valkeinen
2012-05-24  8:44         ` Rob Clark
2012-05-24 12:13           ` Tomi Valkeinen
2012-05-24 15:09             ` Gross, Andy
2012-05-24 15:26               ` Tomi Valkeinen
2012-06-11 14:51                 ` Gross, Andy
2012-06-11 14:54                   ` Gross, Andy
2012-06-11 15:05                   ` Tomi Valkeinen
2012-05-24  8:35       ` Rob Clark
2012-05-24 12:10         ` Tomi Valkeinen
2012-05-24 14:22   ` Gross, Andy
2012-06-11 15:51 ` Rob Clark
2012-06-19 21:12   ` Gross, Andy
2012-07-03  7:09     ` Tony Lindgren
2012-03-05 16:54 Rob Clark
2012-03-06  0:10 ` Tony Lindgren
2012-03-06  1:42   ` Rob Clark
2012-03-06 13:26 ` Tomi Valkeinen
2012-03-06 14:01   ` Rob Clark
2012-03-06 14:35     ` Tomi Valkeinen
2012-03-06 15:29       ` Rob Clark
2012-03-07 11:59         ` Tomi Valkeinen
2012-03-07 13:06           ` Rob Clark
2012-03-07 13:11             ` Tomi Valkeinen
2012-03-06 15:50       ` Gross, Andy
2012-03-07 12:05         ` Tomi Valkeinen
2012-03-07 13:27           ` Rob Clark
2012-03-07 15:59           ` Gross, Andy
2012-03-08  7:47             ` Tomi Valkeinen
2012-01-13 19:41 Rob Clark
2012-01-13 19:46 ` Rob Clark
2012-01-13 19:49   ` Felipe Contreras
2012-01-13 19:53     ` Rob Clark
2012-01-13 20:23       ` Felipe Contreras
2012-01-13 20:25         ` Rob Clark
2012-01-13 19:51 ` Aguirre, Sergio
2012-01-13 19:54   ` Rob Clark
2012-01-13 20:29 ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1331730465.1542.8.camel@lappy \
    --to=tomi.valkeinen@ti.com \
    --cc=andy.gross@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=greg@kroah.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=rob.clark@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.