From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Rob Clark <robdclark@gmail.com>
Cc: Dave Airlie <airlied@gmail.com>,
dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, patches@linaro.org
Subject: Re: [RFC 0/4] TI LCDC DRM driver
Date: Fri, 11 Jan 2013 10:43:47 +0100 [thread overview]
Message-ID: <3774584.dvuStQDo3V@avalon> (raw)
In-Reply-To: <CAF6AEGu4KJ27R6P7CiewVYSP22ZX+2=s6ZeNJv+Voh06gntBzg@mail.gmail.com>
Hi Rob,
On Thursday 10 January 2013 21:15:26 Rob Clark wrote:
> On Thu, Jan 10, 2013 at 6:05 PM, Laurent Pinchart wrote:
> > On Thursday 10 January 2013 10:16:10 Dave Airlie wrote:
> >> On Wed, Jan 9, 2013 at 2:11 PM, Rob Clark <robdclark@gmail.com> wrote:
> >> > Updated version of DRM driver for TI LCD Controller. Since the initial
> >> > version of the patch, which only supported TFP410 DVI output, I've
> >> > added
> >> > an output driver for LCD panels (for example, LCD3 or LCD7 cape for the
> >> > beagle-bone), and initial support for HDMI output via NXP TDA19988 HDMI
> >> > encoder (via i2c encoder-slave output driver).
> >> >
> >> > At this point, I think the basic lcdc drm driver plus TFP410 DVI output
> >> > (first patch) is in reasonable shape (barring potential rename, if lcdc
> >> > is too generic of a name... but I was not feeling creative enough yet
> >> > to
> >> > pick a new name).
> >>
> >> I'd like at least tilcdc :-)
> >
> > So do I :-) The Renesas LCD controller is also called LCDC, and they
> > called the fbdev driver sh_mobile_lcdcfb. tilcdc isn't *that* long in
> > comparison :-)
>
> next version will be 'tilcdc' :-)
>
> I would appreciate some thoughts about more generic devicetree lcd
> panel parameters for the (ti)lcdc_panel patch.. from a functional
> standpoint, I think the lcd panel support part is also pretty much
> ready to go (I've added backlight support since the last version I
> sent), but I'm not really happy with the DT bindings for that because
> they seem to me a bit too hw specific, but I'm not really sure how
> they should look.
How urgent is that ? I will be offline next week, can it wait until I come
back ? (That's more of a rhetorical question I'm afraid, as I'm pretty sure I
won't have time to review that today :-S)
> Fwiw, on the CDF <-> KMS end of things, I'm sort of thinking the i2c
> encoder slave is not too far off.. just needs to be a bit decoupled
> from i2c.
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: laurent.pinchart@ideasonboard.com (Laurent Pinchart)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 0/4] TI LCDC DRM driver
Date: Fri, 11 Jan 2013 10:43:47 +0100 [thread overview]
Message-ID: <3774584.dvuStQDo3V@avalon> (raw)
In-Reply-To: <CAF6AEGu4KJ27R6P7CiewVYSP22ZX+2=s6ZeNJv+Voh06gntBzg@mail.gmail.com>
Hi Rob,
On Thursday 10 January 2013 21:15:26 Rob Clark wrote:
> On Thu, Jan 10, 2013 at 6:05 PM, Laurent Pinchart wrote:
> > On Thursday 10 January 2013 10:16:10 Dave Airlie wrote:
> >> On Wed, Jan 9, 2013 at 2:11 PM, Rob Clark <robdclark@gmail.com> wrote:
> >> > Updated version of DRM driver for TI LCD Controller. Since the initial
> >> > version of the patch, which only supported TFP410 DVI output, I've
> >> > added
> >> > an output driver for LCD panels (for example, LCD3 or LCD7 cape for the
> >> > beagle-bone), and initial support for HDMI output via NXP TDA19988 HDMI
> >> > encoder (via i2c encoder-slave output driver).
> >> >
> >> > At this point, I think the basic lcdc drm driver plus TFP410 DVI output
> >> > (first patch) is in reasonable shape (barring potential rename, if lcdc
> >> > is too generic of a name... but I was not feeling creative enough yet
> >> > to
> >> > pick a new name).
> >>
> >> I'd like at least tilcdc :-)
> >
> > So do I :-) The Renesas LCD controller is also called LCDC, and they
> > called the fbdev driver sh_mobile_lcdcfb. tilcdc isn't *that* long in
> > comparison :-)
>
> next version will be 'tilcdc' :-)
>
> I would appreciate some thoughts about more generic devicetree lcd
> panel parameters for the (ti)lcdc_panel patch.. from a functional
> standpoint, I think the lcd panel support part is also pretty much
> ready to go (I've added backlight support since the last version I
> sent), but I'm not really happy with the DT bindings for that because
> they seem to me a bit too hw specific, but I'm not really sure how
> they should look.
How urgent is that ? I will be offline next week, can it wait until I come
back ? (That's more of a rhetorical question I'm afraid, as I'm pretty sure I
won't have time to review that today :-S)
> Fwiw, on the CDF <-> KMS end of things, I'm sort of thinking the i2c
> encoder slave is not too far off.. just needs to be a bit decoupled
> from i2c.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2013-01-11 9:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 4:11 [RFC 0/4] TI LCDC DRM driver Rob Clark
2013-01-09 4:11 ` Rob Clark
2013-01-09 4:11 ` [PATCH 1/4] RFC: drm/lcdc: add TI LCD Controller DRM driver (v2) Rob Clark
2013-01-09 4:11 ` Rob Clark
2013-01-09 4:11 ` [PATCH 2/4] RFC: drm/lcdc: add support for LCD panels (v2) Rob Clark
2013-01-09 4:11 ` Rob Clark
2013-01-11 13:13 ` Sascha Hauer
2013-01-11 13:13 ` Sascha Hauer
2013-01-09 4:11 ` [PATCH 3/4] RFC: drm/i2c: nxp-tda998x Rob Clark
2013-01-09 4:11 ` Rob Clark
2013-01-09 4:11 ` [PATCH 4/4] RFC: drm/lcdc: add encoder slave Rob Clark
2013-01-09 4:11 ` Rob Clark
2013-01-10 0:16 ` [RFC 0/4] TI LCDC DRM driver Dave Airlie
2013-01-10 0:16 ` Dave Airlie
2013-01-11 0:05 ` Laurent Pinchart
2013-01-11 0:05 ` Laurent Pinchart
2013-01-11 3:15 ` Rob Clark
2013-01-11 3:15 ` Rob Clark
2013-01-11 9:43 ` Laurent Pinchart [this message]
2013-01-11 9:43 ` Laurent Pinchart
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=3774584.dvuStQDo3V@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=patches@linaro.org \
--cc=robdclark@gmail.com \
/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.