From: Tomi Valkeinen <tomi.valkeinen@ti.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-leds@vger.kernel.org, linux-media@vger.kernel.org, Bryan Wu <bryan.wu@canonical.com>, Richard Purdie <rpurdie@rpsys.net>, Marcus Lorentzon <marcus.lorentzon@linaro.org>, Sumit Semwal <sumit.semwal@ti.com>, Archit Taneja <archit@ti.com>, Sebastien Guiriec <s-guiriec@ti.com>, Inki Dae <inki.dae@samsung.com>, Kyungmin Park <kyungmin.park@samsung.com> Subject: Re: [RFC 0/5] Generic panel framework Date: Fri, 17 Aug 2012 14:42:31 +0300 [thread overview] Message-ID: <1345203751.3158.99.camel@deskari> (raw) In-Reply-To: <15644929.x7ZB0fPYJx@avalon> [-- Attachment #1: Type: text/plain, Size: 4644 bytes --] On Fri, 2012-08-17 at 13:10 +0200, Laurent Pinchart wrote: > What kind of directory structure do you have in mind ? Panels are already > isolated in drivers/video/panel/ so we could already ditch the panel- prefix > in drivers. The same directory also contains files for the framework and buses. But perhaps there's no need for additional directories if the amount of non-panel files is small. And you can easily see from the name that they are not panel drivers (e.g. mipi_dbi_bus.c). > Would you also create include/video/panel/ ? Perhaps that would be good. Well, having all the files prefixed with panel- is not bad as such, but just feel extra. > > --- > > > > Should we aim for DT only solution from the start? DT is the direction we > > are going, and I feel the older platform data stuff would be deprecated > > soon. > > Don't forget about non-ARM architectures :-/ We need panel drivers for SH as > well, which doesn't use DT. I don't think that would be a big issue, a DT- > compliant solution should be easy to use through board code and platform data > as well. I didn't forget about them as I didn't even think about them ;). I somehow had the impression that other architectures would also use DT, sooner or later. I could be mistaken, though. And true, it's not a big issue to support both DT and non-DT versions, but I've been porting omap stuff for DT and keeping the old platform data stuff also there, and it just feels burdensome. For very simple panels it's easy, but when you've passing lots of parameters the code starts to get longer. > > This one would be rather impossible with the upper layer handling the > > enabling of the video stream. Thus I see that the panel driver needs to > > control the sequences, and the Sharp panel driver's enable would look > > something like: > > > > regulator_enable(...); > > sleep(); > > dpi_enable_video(); > > sleep(); > > gpip_set(..); > > I have to admit I have no better solution to propose at the moment, even if I > don't really like making the panel control the video stream. When several > devices will be present in the chain all of them might have similar annoying > requirements, and my feeling is that the resulting code will be quite messy. > At the end of the day the only way to really find out is to write an > implementation. If we have a chain of devices, and each device uses the bus interface from the previous device in the chain, there shouldn't be a problem. In that model each device can handle the task however is best for it. I think the problems come from the divided control we'll have. I mean, if the panel driver would decide itself what to send to its output, and it would provide the data (think of an i2c device), this would be very simple. And it actually is for things like configuration data etc, but not so for video stream. > > It could cause some locking issues, though. First the panel's remove > > could take a lock, but the remove sequence would cause the display > > driver to call disable on the panel, which could again try to take the > > same lock... > > We have two possible ways of calling panel operations, either directly (panel- > >bus->ops->enable(...)) or indirectly (panel_enable(...)). > > The former is what V4L2 currently does with subdevs, and requires display > drivers to hold a reference to the panel. The later can do without a direct > reference only if we use a global lock, which is something I would like to Wouldn't panel_enable() just do the same panel->bus->ops->enable() anyway, and both require a panel reference? I don't see the difference. > avoid. A panel-wide lock wouldn't work, as the access function would need to > take the lock on a panel instance that can be removed at any time. Can't this be handled with some kind of get/put refcounting? If there's a ref, it can't be removed. Generally about locks, if we define that panel ops may only be called exclusively, does it simplify things? I think we can make such requirements, as there should be only one display framework that handles the panel. Then we don't need locking for things like enable/disable. Of course we need to be careful about things where calls come from "outside" the display framework. I guess one such thing is rmmod, but if that causes a notification to the display framework, which again handles locking, it shouldn't be a problem. Another thing to be careful about is if the panel internally uses irqs, workqueues, sysfs files or such. In that case it needs to handle locking. Tomi [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-leds@vger.kernel.org, linux-media@vger.kernel.org, Bryan Wu <bryan.wu@canonical.com>, Richard Purdie <rpurdie@rpsys.net>, Marcus Lorentzon <marcus.lorentzon@linaro.org>, Sumit Semwal <sumit.semwal@ti.com>, Archit Taneja <archit@ti.com>, Sebastien Guiriec <s-guiriec@ti.com>, Inki Dae <inki.dae@samsung.com>, Kyungmin Park <kyungmin.park@samsung.com> Subject: Re: [RFC 0/5] Generic panel framework Date: Fri, 17 Aug 2012 11:42:31 +0000 [thread overview] Message-ID: <1345203751.3158.99.camel@deskari> (raw) In-Reply-To: <15644929.x7ZB0fPYJx@avalon> [-- Attachment #1: Type: text/plain, Size: 4644 bytes --] On Fri, 2012-08-17 at 13:10 +0200, Laurent Pinchart wrote: > What kind of directory structure do you have in mind ? Panels are already > isolated in drivers/video/panel/ so we could already ditch the panel- prefix > in drivers. The same directory also contains files for the framework and buses. But perhaps there's no need for additional directories if the amount of non-panel files is small. And you can easily see from the name that they are not panel drivers (e.g. mipi_dbi_bus.c). > Would you also create include/video/panel/ ? Perhaps that would be good. Well, having all the files prefixed with panel- is not bad as such, but just feel extra. > > --- > > > > Should we aim for DT only solution from the start? DT is the direction we > > are going, and I feel the older platform data stuff would be deprecated > > soon. > > Don't forget about non-ARM architectures :-/ We need panel drivers for SH as > well, which doesn't use DT. I don't think that would be a big issue, a DT- > compliant solution should be easy to use through board code and platform data > as well. I didn't forget about them as I didn't even think about them ;). I somehow had the impression that other architectures would also use DT, sooner or later. I could be mistaken, though. And true, it's not a big issue to support both DT and non-DT versions, but I've been porting omap stuff for DT and keeping the old platform data stuff also there, and it just feels burdensome. For very simple panels it's easy, but when you've passing lots of parameters the code starts to get longer. > > This one would be rather impossible with the upper layer handling the > > enabling of the video stream. Thus I see that the panel driver needs to > > control the sequences, and the Sharp panel driver's enable would look > > something like: > > > > regulator_enable(...); > > sleep(); > > dpi_enable_video(); > > sleep(); > > gpip_set(..); > > I have to admit I have no better solution to propose at the moment, even if I > don't really like making the panel control the video stream. When several > devices will be present in the chain all of them might have similar annoying > requirements, and my feeling is that the resulting code will be quite messy. > At the end of the day the only way to really find out is to write an > implementation. If we have a chain of devices, and each device uses the bus interface from the previous device in the chain, there shouldn't be a problem. In that model each device can handle the task however is best for it. I think the problems come from the divided control we'll have. I mean, if the panel driver would decide itself what to send to its output, and it would provide the data (think of an i2c device), this would be very simple. And it actually is for things like configuration data etc, but not so for video stream. > > It could cause some locking issues, though. First the panel's remove > > could take a lock, but the remove sequence would cause the display > > driver to call disable on the panel, which could again try to take the > > same lock... > > We have two possible ways of calling panel operations, either directly (panel- > >bus->ops->enable(...)) or indirectly (panel_enable(...)). > > The former is what V4L2 currently does with subdevs, and requires display > drivers to hold a reference to the panel. The later can do without a direct > reference only if we use a global lock, which is something I would like to Wouldn't panel_enable() just do the same panel->bus->ops->enable() anyway, and both require a panel reference? I don't see the difference. > avoid. A panel-wide lock wouldn't work, as the access function would need to > take the lock on a panel instance that can be removed at any time. Can't this be handled with some kind of get/put refcounting? If there's a ref, it can't be removed. Generally about locks, if we define that panel ops may only be called exclusively, does it simplify things? I think we can make such requirements, as there should be only one display framework that handles the panel. Then we don't need locking for things like enable/disable. Of course we need to be careful about things where calls come from "outside" the display framework. I guess one such thing is rmmod, but if that causes a notification to the display framework, which again handles locking, it shouldn't be a problem. Another thing to be careful about is if the panel internally uses irqs, workqueues, sysfs files or such. In that case it needs to handle locking. Tomi [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-08-17 11:42 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-08-17 0:49 [RFC 0/5] Generic panel framework Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-08-17 0:49 ` [RFC 1/5] video: Add generic display panel core Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-09-04 9:24 ` Sascha Hauer 2012-09-04 9:24 ` Sascha Hauer 2012-09-13 1:40 ` Laurent Pinchart 2012-09-13 1:40 ` Laurent Pinchart 2012-09-13 11:29 ` Sascha Hauer 2012-09-13 11:29 ` Sascha Hauer 2012-09-13 19:32 ` Robert Schwebel 2012-09-13 19:32 ` Robert Schwebel 2012-08-17 0:49 ` [RFC 2/5] video: panel: Add dummy panel support Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-08-17 0:49 ` [RFC 3/5] video: panel: Add MIPI DBI bus support Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-08-17 9:03 ` Tomi Valkeinen 2012-08-17 9:03 ` Tomi Valkeinen 2012-08-17 10:02 ` Laurent Pinchart 2012-08-17 10:02 ` Laurent Pinchart 2012-08-17 10:51 ` Tomi Valkeinen 2012-08-17 10:51 ` Tomi Valkeinen 2012-08-17 12:33 ` Laurent Pinchart 2012-08-17 12:33 ` Laurent Pinchart 2012-08-17 13:06 ` Tomi Valkeinen 2012-08-17 13:06 ` Tomi Valkeinen 2012-08-17 14:06 ` Laurent Pinchart 2012-08-17 14:06 ` Laurent Pinchart 2012-08-17 0:49 ` [RFC 4/5] video: panel: Add R61505 panel support Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-08-17 0:49 ` [RFC 5/5] video: panel: Add R61517 " Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-08-17 1:33 ` [RFC 0/5] Generic panel framework Jingoo Han 2012-08-17 1:33 ` Jingoo Han 2012-08-17 8:38 ` Tomi Valkeinen 2012-08-17 8:38 ` Tomi Valkeinen 2012-08-17 11:10 ` Laurent Pinchart 2012-08-17 11:10 ` Laurent Pinchart 2012-08-17 11:42 ` Tomi Valkeinen [this message] 2012-08-17 11:42 ` Tomi Valkeinen 2012-08-18 1:16 ` Laurent Pinchart 2012-08-18 1:16 ` Laurent Pinchart 2012-08-18 1:16 ` Laurent Pinchart 2012-08-20 11:39 ` Tomi Valkeinen 2012-08-20 11:39 ` Tomi Valkeinen 2012-08-20 23:29 ` Laurent Pinchart 2012-08-20 23:29 ` Laurent Pinchart 2012-08-20 23:29 ` Laurent Pinchart 2012-08-21 5:49 ` Tomi Valkeinen 2012-08-21 5:49 ` Tomi Valkeinen 2012-08-21 9:23 ` Laurent Pinchart 2012-08-21 9:23 ` Laurent Pinchart 2012-08-23 6:23 ` Jun Nie 2012-08-23 6:23 ` Jun Nie 2012-09-04 8:20 ` Zhou Zhu 2012-09-04 8:20 ` Zhou Zhu 2012-10-30 16:35 ` Laurent Pinchart 2012-10-30 16:35 ` Laurent Pinchart 2012-10-30 16:23 ` Laurent Pinchart 2012-10-30 16:23 ` Laurent Pinchart 2012-10-20 14:18 ` Inki Dae 2012-10-20 14:18 ` Inki Dae 2012-09-19 11:45 ` Tomi Valkeinen 2012-09-19 11:45 ` Tomi Valkeinen 2012-10-31 13:13 ` Laurent Pinchart 2012-10-31 13:13 ` Laurent Pinchart 2012-10-31 14:20 ` Tomi Valkeinen 2012-10-31 14:20 ` Tomi Valkeinen 2012-10-31 14:20 ` Tomi Valkeinen 2012-10-20 13:10 ` Inki Dae 2012-10-20 13:10 ` Inki Dae 2012-10-20 14:22 ` Inki Dae 2012-10-20 14:22 ` Inki Dae 2012-10-31 13:28 ` Laurent Pinchart 2012-10-31 13:28 ` 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=1345203751.3158.99.camel@deskari \ --to=tomi.valkeinen@ti.com \ --cc=archit@ti.com \ --cc=bryan.wu@canonical.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=inki.dae@samsung.com \ --cc=kyungmin.park@samsung.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-leds@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=marcus.lorentzon@linaro.org \ --cc=rpurdie@rpsys.net \ --cc=s-guiriec@ti.com \ --cc=sumit.semwal@ti.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: linkBe 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.