Hi Laurent,
Thanks for the reply.
On 17 December 2012 20:55, Laurent Pinchart < laurent.pinchart@ideasonboard.com> wrote:
DSI support in CDF.
o MIPI DSI support as part of CDF framework will expose
§ mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c file )
§ mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from platform specific init driver call )
· bus ops will be
o read data
o write data
o write command
§ MIPI DSI will be registered as bus_register()
When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will initialize the MIPI DSI HW IP.
This probe will also parse the DT file for MIPI DSI based panel, add the panel device (device_add() ) to kernel and register the display entity with its control and video ops with CDF.
I can give this a try. Does the existing Exynos 5250 driver support MIPI
i think device documentation is NOT available publicly.
--
Thanks and Regards Vikas Sajjan
Hi All,
On 17 December 2012 20:55, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Yeah, i was also thinking in similar lines, below is my though for MIPI DSI support in CDF.
o MIPI DSI support as part of CDF framework will expose
> mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c file )
mipi_dsi_register_driver(mipi_driver, bus ops) (will be called
from platform specific init driver call )
· bus ops will be o read data o write data o write command
MIPI DSI will be registered as bus_register()
When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will initialize the MIPI DSI HW IP.
This probe will also parse the DT file for MIPI DSI based panel, add the panel device (device_add() ) to kernel and register the display entity with its control and video ops with CDF.
yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP. i think device documentation is NOT available publicly.
Hi Vikas,
On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I have most of the work done, I have just to solve several remaining problems.
Best regards,
Hi Tomasz,
On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
Do you already have code that you can publish ? I'm particularly interested (and I think Tomi Valkeinen would be as well) in looking at the DSI operations you expose to DSI sinks (panels, transceivers, ...).
Hi Laurent,
On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
Well, I'm afraid this might be little below your expectations, but here's an initial RFC of the part defining just the DSI bus. I need a bit more time for patches for Exynos MIPI DSI master and s6e8ax0 LCD.
The implementation is very simple and heavily based on your MIPI DBI support and existing Exynos MIPI DSIM framework. Provided operation set is based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately this is my only source of information about MIPI DSI.
Best regards,
On 27 December 2012 20:13, Tomasz Figa t.figa@samsung.com wrote:
As per the discussion what Laurent and Tomi had ( http://lists.freedesktop.org/archives/dri-devel/2012-December/032038.html), both DSI and DBI doesn't need to be registered as real bus. Please refer to Tomi's pacthset for DSI support. ( git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model-cdf )
anyways i am working on Exynos MIPI DSI as per the new CDF proposed by Tomi and Laurent.
-- Thanks and Regards Vikas Sajjan
Hi Tomasz,
On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote:
No worries. I was particularly interested in the DSI operations you needed to export, they seem pretty simple. Thank you for sharing the code.
On 01/08/2013 09:18 AM, Laurent Pinchart wrote:
FYI, here is STE "DSI API": http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=inc...
But it is not perfect. After a couple of products we realized that most panel drivers want an easy way to send a bunch of init commands in one go. So I think it should be an op for sending an array of commands at once. Something like
struct dsi_cmd { enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */ u8 cmd; int dataLen; u8 *data; } struct dsi_ops { int dsi_write(source, int num_cmds, struct dsi_cmd *cmds); ... }
The rest of "DSI write API" could be made helpers on top of this one op. This grouping also allows driver to describe intent to send a bunch of commands together which might be of interest with mode set (if you need to synchronize a bunch of commands with a mode set, like setting smart panel rotation in synch with new framebuffer in dsi video mode).
I also looked at the video source in Tomi's git tree (http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf/incl...). I think I would prefer a single "setup" op taking a "struct dsi_config" as argument. Then each DSI formatter/encoder driver could decide best way to set that up. We have something similar at http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=inc...
And I think I still prefer the dsi_bus in favor of the abstract video source. It just looks like a home made bus with bus-ops ... can't you do something similar using the normal driver framework? enable/disable looks like suspend/resume, register/unregister_vid_src is like bus_(un)register_device, ... the video source anyway seems unattached to the panel stuff with the find_video_source call.
/BR /Marcus
On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
wrote:
wrote:
Yes, this should be flexible enough to cover most of (or even whole) DSI specification.
However I'm not sure whether the dsi_write name would be appropriate, since DSI packet types include also read and special transactions. So, according to DSI terminology, maybe dsi_transaction would be better?
Yes, this would be definitely better, because such configuration changes usually come together (i.e. display connected, which needs complete reconfiguration of all parameters).
DSI needs specific power management. It's necessary to power up the panel first to make it wait for Tinit event and then enable DSI master to trigger such event. Only then rest of panel initialization can be completed.
Also, as discussed in previous posts, some panels might use DSI only for video data and another interface (I2C, SPI) for control data. In such case it would be impossible to represent such device in a reasonable way using current driver model.
Best regards,
On 01/08/2013 05:36 PM, Tomasz Figa wrote:
I think read should still be separate. At least on my HW read and write are quite different. But all "transactions" are very much the same in HW setup. The ... was dsi_write etc ;) Like set_max_packet_size should maybe be an ops. Since only the implementer of the "video source" will know what the max read return packet size for that DSI IP is. The panels don't know that. Maybe another ops to retrieve some info about the caps of the video source would help that. Then a helper could call that and then the dsi_write one.
I know, we have a very complex sequence for our HDMI encoder which uses sort of continuous DSI cmmand mode. And power/clock on sequences are tricky to get right in our current "CDF" API (mcde_display). But I fail to see how the current video source API is different from just using the bus/device APIs.
I understand that you need to get hold of both the control and data bus device in the driver. (Toshiba DSI-LVDS bridge is a good example and commonly used "encoder" that can use both DSI and I2C control interface.) But the control bus you get from device probe, and I guess you could call bus_find_device_by_name(dsi_bus, "mydev") and return the "datadev" which will have access to dsi bus ops just as you call find_video_source("mysource") to access the "databus" ops directly with a logical device (display entity). I'm not saying I would refuse to use video sources. I just think the two models are so similar so it would be worth exploring how a device model style API would look like and to compare against.
/BR /Marcus
Hi Marcus,
On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote:
On 01/08/2013 05:36 PM, Tomasz Figa wrote:
On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
[snip]
Thank you.
Do you have DSI IP(s) that can handle a list of commands ? Or would all DSI transmitter drivers need to iterate over the commands manually ? In the later case a lower-level API might be easier to implement in DSI transmitter drivers. Helper functions could provide the higher-level API you proposed.
Or dsi_transfer or dsi_xfer ? Does the DSI bus have a concept of transactions ?
If panels (or helper functions) need information about the DSI transmitter capabilities, sure, we can add an op.
The Linux driver framework is based on control busses. DSI usually handles both control and video transfer, but the control and data busses can also be separate (think DPI + SPI/I2C for instance). In that case the panel will be a child of its control bus master, and will need a separate interface to access video data operations. As a separate video interface is thus needed, I think we should use it for DSI as well.
My initial proposal included a DBI bus (as I don't have any DSI hardware - DBI and DSI can be used interchangeably in this discussions, they both share the caracteristic of having a common control + data bus), and panels were children of the DBI bus master. The DBI bus API was only used for control, not for data transfers. Tomi then removed the DBI bus and moved the control operations to the video source, turning the DBI panels into platform devices. I still favor my initial approach, but I can agree to drop the DBI bus if there's a consensus on that. Video bus operations will be separate in any case.
As mentioned above, the video source API handles video transfers, while the bus/device API handles control transfers. Operations such as "start the video stream" will thus be video source APIs. Operations such as "enable the DSI master", used to trigger the Tinit event (whatever that is :-)) at power up time would probably be DSI bus operations.
I don't think we should use the Linux device model for data busses. It hasn't been designed for that use case, and definitely doesn't support devices that would be children of two separate masters (control and data). For shared bus devices such as DSI, having a DSI bus was my preference to start with, as mentioned above :-) However, even in that case, I think it would still make sense to use video sources to control the video operations. As usual the devil is in the details, so there will probably be some tricky problems we'll need to solve, but that will require coding the proposed solution.
On 02/02/2013 12:35 AM, Laurent Pinchart wrote:
[...]
The HW has a FIFO, so it can handle a few. Currently we use the low level type of call with one call per command. But we have found DSI command mode panels that don't accept any commands during the "update" (write start+continues). And so we must use a mutex/state machine to exclude any async calls to send DSI commands during update. But if you need to send more than one command per frame this will be hard (like CABC and backlight commands). It will be a ping pong between update and command calls. One option is to expose the mutex to the caller so it can make many calls before the next update grabs the mutex again. So maybe we could create a helper that handle the op for list of commands and another op for single command that you actually have to implement.
No transactions. And I don't want to mix reads and writes. It should be similar to I2C and other stream control busses. So one read and one write should be fine. And then a bunch of helpers on top for callers to use, like one per major DSI packet type.
Yes, a "video source" op for getting caps would be ok too. But so far the only limits I have found is the read/write sizes. But if anyone else has other limits, please list them so we could add them to this struct dsi_host_caps.
As discussed at FOSDEM I will give DSI bus with full feature set a try.
BTW. Who got the action to ask Greg about devices with multiple parents/buses?
I will give it a try after asking Greg for guidelines.
/BR /Marcus
On Monday 04 February 2013 03:35 PM, Marcus Lorentzon wrote:
fyi, the DSI IP on OMAP3+ SoCs also has a FIFO. It can provide interrupts after each command is pushed out, and also when the FIFO gets empty(all commands are pushed). The only thing to take care is to not overflow FIFO.
DSI video mode panels generally have a few dozen internal registers which need to be configured via DSI commands. It's more fast(and convenient) to configure a handful of internal registers in one shot, and then perform a single BTA to know from the panel whether the commands were received correctly.
Regards, Archit
On 2013-02-04 12:05, Marcus Lorentzon wrote:
As discussed at FOSDEM I will give DSI bus with full feature set a try.
Please do, but as a reminder I want to raise the issues I see with a DSI bus:
- A device can be a child of only one bus. So if DSI is used only for video, the device is a child of, say, i2c bus, and thus there's no DSI bus. How to configure and use DSI in this case?
- If DSI is used for both control and video, we have two separate APIs for the bus. What I mean here is that for the video-only case above, we need a video-only-API for DSI. This API should contain all necessary methods to configure DSI. But we need similar methods for the control API also.
So, I hope you come up with some solution for this, but as I see it, it's easily the most simple and clear option to have one video_source style entity for the DSI bus itself, which is used for both control and video.
Tomi
On 02/08/2013 11:51 AM, Tomi Valkeinen wrote:
Thanks, it is not that I'm totally against the video source stuff. And I share your concerns, none of the solutions are perfect. It just doesn't feel right to create this dummy source "device" without investigating the DSI bus route. But I will try to write up some history/problem description and ask Greg KH for guidance. If he has a strong opinion either way, there is not much more to discuss ;)
/BR /Marcus
Hi Marcus,
On Tuesday 08 January 2013 11:12:26 Marcus Lorentzon wrote:
[snip]
A single setup function indeed seems easier, but I don't have enough experience with DSI to have a strong opinion on that. We'll have to compare implementations if there's a disagreement on this.
Hi Vikas,
On Tuesday 18 December 2012 08:31:30 Vikas Sajjan wrote:
After discussing the DBI/DSI busses with Tomi Valkeinen we concluded that creating a real bus for DBI and DSI, although possible, wasn't required. DSI operations should thus be provided through display entity video source operations. You can find a proposed implementation in Tomi's patch set.
dri-devel@lists.freedesktop.org
-
Archit Taneja -
Laurent Pinchart -
Marcus Lorentzon -
Tomasz Figa -
Tomi Valkeinen -
Vikas Sajjan