From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support Date: Tue, 20 Aug 2013 15:26:50 +0200 Message-ID: <1594362.r0V5lgAQ07@avalon> References: <1376068510-30363-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> <1376068510-30363-9-git-send-email-laurent.pinchart+renesas@ideasonboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [95.142.166.194]) by gabe.freedesktop.org (Postfix) with ESMTP id 9EB50E6EE5 for ; Tue, 20 Aug 2013 06:25:38 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Rob Clark Cc: linux-fbdev@vger.kernel.org, Benjamin Gaignard , dri-devel@lists.freedesktop.org, Jesse Barnes , Sebastien Guiriec , Laurent Pinchart , Tom Gall , Ragesh Radhakrishnan , Tomi Valkeinen , linux-media@vger.kernel.org, Stephen Warren , Mark Zhang , =?ISO-8859-1?Q?St=E9phane?= Marchesin , Alexandre Courbot , Thomas Petazzoni , Sunil Joshi , Kyungmin Park , Maxime Ripard , Vikas Sajjan , Marcus Lorentzon List-Id: dri-devel@lists.freedesktop.org Hi Rob, On Tuesday 13 August 2013 20:52:15 Rob Clark wrote: > On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote: > > MIPI DBI is a configurable-width parallel display bus that transmits > > commands and data. > > > > Add a new DBI Linux bus type that implements the usual bus > > infrastructure (including devices and drivers (un)registration and > > matching, and bus configuration and access functions). > > > > Signed-off-by: Laurent Pinchart > > --- > > > > drivers/video/display/Kconfig | 8 ++ > > drivers/video/display/Makefile | 1 + > > drivers/video/display/mipi-dbi-bus.c | 234 ++++++++++++++++++++++++++++++ > > include/video/display.h | 4 + > > include/video/mipi-dbi-bus.h | 125 +++++++++++++++++++ > > 5 files changed, 372 insertions(+) > > create mode 100644 drivers/video/display/mipi-dbi-bus.c > > create mode 100644 include/video/mipi-dbi-bus.h [snip] > > diff --git a/include/video/mipi-dbi-bus.h b/include/video/mipi-dbi-bus.h > > new file mode 100644 > > index 0000000..876b69d > > --- /dev/null > > +++ b/include/video/mipi-dbi-bus.h [snip] > > +struct mipi_dbi_device { > > + const char *name; > > + int id; > > + struct device dev; > > just fwiw, we need the "framework" to be agnostic of the association between > devices and entities in the framework. Some things that are multiple > entities may actually map to a single device in hw I haven't written down that requirement, but I've kept it in mind while designing CDF. We have similar use cases in V4L2. > (and possibly visa versa?). I don't think that would be needed, but if you can think of a use case I'm all ears. > Otherwise we end up having to create fake devices in some cases. Really the > entities, or objects, or whatever you call 'em should just extend some > kref'd base class. Sort of like how existing kms objects extend > drm_mode_object. struct display_entity { struct list_head list; struct device *dev; struct module *owner; struct kref ref; char name[32]; struct media_entity entity; const struct display_entity_ops *ops; void(*release)(struct display_entity *ent); }; (from patch 02/19) > So any 'struct device' moves down into the derived class, not in the base > class. Configuration data is passed in separate, not grabbed out of dev-> > platform_data, etc. Probably there is room for some helpers to pull stuff > out of DT/ACPI/whatever. struct mipi_dbi_device is not a display entity, it's a physical device plugged on a DBI bus. It's thus similar in purpose to struct pci_device or struct platform_device. The DBI device driver will then create one or more display entities depending on its needs. > > + const struct mipi_dbi_device_id *id_entry; > > + struct mipi_dbi_bus *bus; > > + > > + unsigned int flags; > > + unsigned int bus_width; > > + unsigned int data_width; > > +}; -- Regards, Laurent Pinchart