 Hello, everyone. Welcome to open source in Japan. Today, I'm going to talk about supporting complex nuclear safe beaches in Linux system. Let me tell you about myself. I'm basically an embedded Linux engineer. I work for various embedded Linux products and software development since from last 12 and a half years. I have founded a company in India called Amurda Solutions. Here we are developing open source Linux software solutions to the customers all over the world. Technically, I'm more interested towards open source in-house, so I have given my talks, paper presentations, and technical demos on various embedded Linux conferences throughout the world since from 2013. I myself support several contributions in Ubuntu and Linux closets. And then I have some key subsystems in those projects areas as well. Come to the actual topic. This is one of the topics that we are working right now. It's our embedded customers in industries. So far from since almost two and a half years. All this presentation is purely demonstrated by technical requirements like we have given all this information based on our real-time experiences rather than theoretical ones. So most of the hardware and software that we are developing are mostly for consumer and industrial based embedded systems, which uses MAPDSI. So I will first talk about why these MAPDSI switches are required and what are those switches basically in the hardware point of view. Like how those switches can be used in the hardware point of view in the products. And then I will start about how those hardware switches has been developing in the Linux software with the help of Linux DRM core. I will further explain each and every part of DSA switches so far in the technology as per the MAPD standard. And I can start giving the various implementations of these switches in the Linux kernel. And finally I will give an information of how these switches has been proving or enumerating in the Linux boot processor in the module perspective. As I said before, all this information I have given is strictly based on my experience. Something which may phase in issues are not related to in this presentation. Like as per my knowledge and as per my experience so far with the Linux DRM bridge. Let us start with the MAPDSI switches. Why MAPDSI switches are required basically? If you understand the embedded perspective, MAPDSI is one of the display interface standard. Like we have parallel communication or parallel RGB and we have another technology called LVDS, HDMI, display port, all these sort of display interfaces. MAPDSI is a versatile one which has its own several advantages with respect to embedded word mostly because these switches are powered by low power and high performance. Even the protocol perspective, this is pretty much simple what we have been master slave communication that is done by normal networking. Like master is sending the data by with handshake and slave can receive that data and give an update based on the react connect, something like that. So why exactly these switches are required in the consumer end result perspective? I have catalyzed based on my experience and these are the switches that I have been seen so far with respect to my working and even for the technological perspective. One is the complexity of host display controllers. If you see these nowadays all these exclusive vendors are coming up with a simple display interface controller give the overhead or headache to the end user so that they can use their respective display interface. What I mean to say is they go with the generic display interface like MAPDSI. So they don't need to handle any controllers for LVDS or HDMI, even for other IPs, other display IPs. So the consumer can take use of a SOC with MAPDSI. They can make use of different interfaces like LVDS, HDMI by using some kind of a bridges to convert them basically. That is another point where the complicity of host display controller is coming to picture. Take an example of IMX-80 Mini and Exynos-54. Both have implemented their own DSA host controllers, even the protocol is a repeat standard. So it is a redundant technique to make use of the same IPs even though it's a different SOCs. That is where one of the complexities occurs basically. If there is some other SOC wanted to use some other display host controller, they need to re-implement everything. And at the end of the day it is almost 8 to 90% of identity as part of the MAPDSI stack. So there is a complexity occur. That is one point. Another point where if SOC has DSA but the end user wants to have a different display interface, say for example, HDMI or LVDS. In that case, there is a proximity of problem like MAPDSI cannot send HDMI data, something like that. That is one of the interface conversation and compatibility. And there is other use case where one single interface can output into two multiple outputs, rather than a single output. Say the typical example of this was like the same controller can make use of two different identical outputs so that they can use two different display interfaces. That is where one of the key requirements of this DSA is required. The other perspective, this is one of the things that has been recently observed. There is a concept called switching, that DSA switching, where basically we need to output only one display interface. But the consumer or end user wants to have multiple outputs in a single instance. Like they want to support LVDS and HDMI on their own. Of course they cannot use both interfaces at the same time, but they wanted to do some kind of switching. Like I want to turn on the other, something like that. And there is another requirement where apart from the standalone displays, there is another kind of display called the productors. And the typical example of embedded is DLP productors. There is a huge advantage over MAPDSA because of this particular advantage like low power, high power once, as I've said before. So this is also one of the key areas where MAPDSA is coming to picture basically. Coming to the real implementations of those, if you see the host complexity can be avoided by using the DSA host bridge. Take an example of this IMX item and X064. Both they use their own device. Of course, the pilot is most likely relevant to that particular shock. But they come up with a common bridge basically. That is Samsung MAPDSA bridge. So the common bridge can, what I'm saying to what I'm going to say here was like, the host bridge can be compatible with the different approaches. So the same IP can be written and we use for the several shocks. This is because of the MAPDSA specifications. Because the bridge itself is designed based on the spec. So the complexity of using the several DSA hosts. That is a display interface output where DSA to HDMI converter. This is one of the kind like converter bridge. And the other one is something like giving a multiple outputs like taking the single input from the shock and giving multiple outputs. This is one of the other bridge example like multi-output bridge. There are some real use cases about these basically. There are other kind of other interface type like display interface switch. It has mentioned like I need to switch the several interfaces each at a single time. That is another category of a DSA bridge switch. Finally there is another advantage with respect to the non-standalone panels like DSA projectiles. They have a DLP technology from Texas Instrument. That would come up with DSA DLP bridges. These are the different category types of different MAPDSA bridges. So far I have seen in the technology usage perspective. These are the things I am merely called as based on my understanding. But the meaning of these are more or less similar to what we have there in the spec basically. The first one I called it as a host bridge. Since it is not used in the slaves. So it is strictly an option for ASSO seconders. Because here NXP and Samsung have both have been using the same DSM bridge on their socks. They have used a common bridge to access their ASSOC display interfaces. Another one is a converter bridge. There is another bridge that converts DSA to HDMI. Right now I am working on this particular bridge where it takes the MAPDs input and converts to HDMI transmit. That is used for HDMI display monitors. And there is another bridge which has already been submitted in the mainline. That is called SN65DS84 from Texas Instrument. But it takes the single input from the sock and it will convert it into multiple outputs. Like two outputs. So you can drive two different display interfaces of LVDS. This is also kind of a converter but it converts DSA to multi LVDS. There is another type of the bridge where bridges switching can happen from LT8912. There are several challenges going to happen with respect to bridges. It wants to switch the LVDS into HDMI and it eats it every time. In a single time basically. The last bridge is DLP3433 that is from Texas Instrument. It is widely used on DLP projectors. So you can be able to use those projectors on the DLP bridge. So the project will have a high performance and low power with the technologies. Let me talk about briefly on the hardware prospect to how these can be implemented to internalize the protocol here. Start with the Samsung DSA MS bridge. This is a purely host bridge. Here you can see the host can connect to the interface controller. Like here I am connecting one interface controller IC with the DSA panel. Here is the data communication. As I said the MIPP DSA protocol standard is like master slave communication. Master can send the data with respect to a data lane along with the clock lane latch. And slave can receive the data with respect to real master or behave. Something like a hand shaking kind of a communication. This is a typical example connection on how this host DSMI bridge has happened basically. This is the IT6161 converter bridge. The host is like a MIPP DSA host. It can send the data with the VSA bus. IT6161 will convert the data to HDMI. Like they have a protocol internal protocol standard layer. All the data lanes must be converted to TDMI signals like for the HDMI display to monitor the process basically. This is one kind of a converter bridge example. There is a multi-output bridge as I said before. This is a real-time example of host bridge. This bridge will take the lanes data from the DSA host. And it converts and pumps the data to respect to LVDS outputs. At the time it can drive through LVDS outputs. So the lane switching can happen internally to this bridge. And then can send the data based on what host is going to send. There is another bridge called multi-bridge switch. Unlike SN65 DSA power, it can support two output display interfaces. But at a time only one can be able to drive the output data. So the user can be able to switch the display interface by using some AP switch inside to this bridge basically. This is another example of those kind of a bridge. What I mentioned before, this is internal implementation. Take an example of some kind of a bridge switch that takes the data from the Samsung host. And it can drive through two different bridges on which for LVDS output and our bridges for HDMI. This bridge switch is going to switch the data. Like there would be data enable pin or even a select pin. So it can drive the data coming from the particular host to the respect to bridge at a time. Because we can be able to access the single bridge at a time basically. This is an example of your connection on this aspect use case. The final is the last bridge. It is like the bridge that is used for projectors. That I mentioned earlier that you like DLP projectors. Similar to what the converter does. But here the DLP 3-4-2-3 can take the data from the host. But the data need to convert from DSI to DMD. Like the data we are processing to projectors we call it as a DMD data. Unlike LVDS and DPI. This particular DMD data can be driven from the DLP 3-4-2-3. So the internal ICs can be able to take care of those data. And that can send the data to the projector and the projector will grow basically. What it mentioned clearly like the master of this projectors system is the DLP 3-4-2-3. It can act to drive the data and convert the data of DSI to DMD to process the projector lens. That is what the overall picture of this particular bridge is basically. Let us talk about how these bridges have been implemented in software perspective like in Linux DRM subsystem. Basically if you want internal details how this Linux DRM bridge subsystem has a stack. Basically how this DRM core is resisting to DRM host drivers. How this DSI host drivers are resisting DSI core DRM core DRM panel and DRM bridge something like that. There is a big functional block diagram that has already been discussed in the last Linux conference by me. If you want any information on that respective regards please take a look into this. We can be able to understand the overall perspective of those DSI and DRM subsystems how they look basically. Because most of the DSI subsystem is similar to what I discussed before except from API changes in recent kernels. But apart from that the entire block diagram that I mentioned earlier like how the DRM panel works with respect to bridge and how DRM bridges works with respect to DRM panel and how the host bridge is resisting to DRM subsystem and how the host DSI bridge is resisting to DSI core is something very similar to what we have right now. I will talk a little bit about the DRM bridge basically like DRM bridge is one of the components of Linux DRM. So only this is one of the prospect to have been introduced in the last million years. So that the IDA has to move the encoder drivers towards the bridge side because bridge has its own advantages basically. In the Linux prospect to bridge is something like a tree like each tree has a tail. So each bridge has its own bridge. The bridge always start from the encoder. Say for example, a pure bridge driver should have one encoder that is a head. So what are the bridges that are connected in that pipeline should have bridge forward bridge forward bridge. Take an example of a host in the Samsung DSI. Host is a bridge if I wanted to add another bridge say for example host bridge is called as a host with a bridge here. And second bridge if I wanted to add it is 262 that convert the DSI to HDMI. So that can be called as a bridge be and each bridge can have its own connector like bridge connectors and that bridge can output to another bridge like or it can be a panel but in the panel also it we treated as a panel bridge basically instead of having a direct panel. It's panel which is software implementation of panels which are downstreaming the bridge basically. What I'm saying what I mean to say here was like there should be encoder first. The encoder can be a dump encoder. So earlier the encoder has encoder operation but right now there is no encoder operation just exposed to user space that there is encoder to understand the legacy use case. The encoder here is a dump but what are the subsystems followed by the encoders should be treated as a bridges. So each bridge connected as a tree fashion area. Bridge A bridge C something like up to song basically that is how this particular slide is been prepared basically earlier there was a DM encoder. There is no bridge at all that is frame buffer is connected to CRTC and that CRTC connected to encoder and encoder connected to connect connector something like that. But it's a DRM bridge but what I mean to say is each encoder you know we do have a multiple encoders because each and every every pipeline video pipeline area we call it as encoders but here we call it as a bridge bridges. To understand the bridge topology. We don't have a bridge connector. Those we don't have an earlier DRM connectors. It can be easily replaced with bridge connectors. So what are the bridges having a connectors connectors can have several advantages with respect to hard applicable. The connectors have a flag something like EDID in HDMI and connectors we don't need a connector something like that. So the bridge connectors has some advantages or while handling the bridge is alone basically. So the overall what I mean to say was like if you want to write in new drivers the Linux DRM that the drivers need to have some kind of a bridge structures rather than the encoders which are now onwards basically. Due to the framework changes in the recent discussions and diver changes. So let us discuss more about how these several bridges has been implemented in Linux DRM bridge using DRM bridge APIs. Like how these drivers has been written basically. I will give you the clear overview. And most of the drivers look similar but internal resistive handling might differ but the main core protocol standard is the same. As I said this bridge system implementation is still going to be more mature because we do have several issues like what other stacks do have. But it's ongoing work and it can give some information about how these bridges are working at least from my perspective. Let us talk about host bridge. The first one I have categories in the three different areas like how the physical connection is going to happen. And how those physical connections are connected in the DTS the diversity. So if it is a diversity how we are going to write the particular bridge driver Linux to access their downstream bridges as well as upstream encoders. Let us talk about host bridge. The host here is a physical connection of Samsung DSA host. That host you can directly connect to the DSA panel like you can enable to send the video data via those panel. You can even send you can even connect that host with some kind of a DSA bridge as I mentioned before. The bridge we can have a converter bridge or it can be a DLP bridge or it can be switch something like that. That is how the physical connection is going to have basically. In the diversity pipeline we have a LCD interface node that node has an output port that port can connect to DSA. And the DSA port has one input that is connected to LCD interface. The output of the port can be a panel or it can be a bridge. If it is a bridge with just two outputs or input is DSA host and the output could be a panel or some kind of encoder or even some kind of HDMI connector something like that. Here in case we have an ampere quality simple panel. So this is a bridge perspective of how this DSA is host handling. But in case of panel you don't have any port on the output panel because the port is the end of the terminal basically. And as I said the DPI we do have a pipeline in the DSA host node in to attach panel DPI. So how this particular host bridge level is going to fit or what are the different protocols or different areas need to look into it. First one is a probe area. Here we need to host when I say host you should have host ops. The host ops operation need to hook and we need to register the bridge because it is itself is a bit DSA host itself is a bridge. So you need to register the history tell the bridge. In the host attach we do have a by listing the bridge you do have a bridge operations and host operations in the host attach. We do have a PEDSA attach and that attached can trigger the slave bridge or save a panel basically. So from there you can find there is a panel connected to the DSA host or there is a bridge connected to the DSA or something like that. I will give those probing overview on the next slides but more or less the driver looks save on the probe area. And we have a bridge attach. Once you find the panel from the bridge you need to find the panel and even we need to find the panel from the host attach but it's one of the advantages basically. And let us talk about how host which attach like that it could be the downstream or bridge or downstream panel. The panel can ask about my PDSA attach. So the host attach will get pro and it can find out that there is a slave panel or slave host bridge is connected slow. Host can identify there is a slave connected basically assuming there is assuming the connection is about panel. So once it finds that there is a panel the pipeline starts from the LCD LCD interface it start attaching the each and every pipeline start attaching the bridge like in the host bridge and it can attach panel bridge. Here in case the panel we call it as the panel bridge in the bridge perspective if it is a bridge that is connected to a panel. From there the data transfer happened in the host transfer area like the panel sends the data to the host via DSA command something like that. If it is a direct panel if it is a direct panel the host attach identifies the panel so it can create the panel bridge. So host widget as easy happen all the widget as as done once all the widget task is done the host is start sending the data to the panel and their panel communicate the data. That is how it is done in the transfer call. Let's just talk about the converter bridge. In this converter bridge we have physical connection of about all of us and x50, dpi, all of us and host bridge. Host controller can be but we need to have a bridge which support to handle the bridges. So I can connect it 6.6 and bridge where it can convert VPRX data to HDMTX. The pipeline looks similar to before but here in case there is one fundamental at one fundamental reference is like this type of bridge we need to interface with I2C. Like the slave can be interface via I2C but the actual data transfer can happen in those lanes basically. That is how the pipeline going to create. The Ticon can output the DSA, DSA output to I2C and 6.6 and I2C output to HDMA character. The I2C and 6.1 input to DSA output. DSA output to HDC input something like that. There is no host because it is not a host bridge. It is purely a converter bridge that is a slave bridge. So we need to pass the bridge. Some of the bridges has been passed in the probe but it itself can be able to pass the bridge. We can pass the bridge and identify the bridge I2C and 6.6 and bridge. So create the bridge jobs and add the bridge and attach the VPDSA attach. But in this case the host will attach will get scarred. From there the actual data transfer is going to happen in the bridge operation perspective. The host operation still exists but it cannot be directly proportional like what you have in the host bridge. So all this command communication is done by I2C commands so it can configure I2C commands and do the data transfer by sending the configured commands. Why I'm causing the host ops is like I'm causing the host transfer call because the transfer is not required in this particular slave bridge perspective because in order to send the I2C configured data we need to have a bridge operations but in DSA commands we need to have a host transfer. The next one is multi-output bridge that is similar to what we have discussed so far. But here in cave we need to probe the two different panels and switch the panels and outputting those panels into the communication model. As I said before the probe will identify the panels and understand there is a panel has sorry identify the bridge understand there are the panels so create a panel bridge attach sorry panel bridge add and try to hook the bridge ops and host ops. Once the pipeline is attached host need to slave scar sending data via I2C host can take those data transfers and pump the video signal to the respective panels. This is how the how the actual 84 two different elevators has been taken care. Then there is another bridge that is multi-out switch bridge. Similar to SN84, 64, 84 but in this particular switch we can turn on the switch and particular connection and turn off the switch we cannot access the both at the same time. This is one of the use case where their industries wants to have a common LVDS connector and sometimes they wanted to take the data in the HDMI connector something like that. So this LT8912 has an internal bridge the PCSA switch implementation so it can take care of enabling the particular parts and disabling the other parts something like that. There is a driver pardon me I have a mistake on the slides there is a driver in the Linux channel with 8912 but it do support HDMI but I am not sure whether it is supporting LVDS at the same time. But actual bridge switching is still under implementation. You can able to get those information in the coming slides. Yes this is an internal point of view what I have discussed in the earlier slide like a multi-out switch. This is what internally happened basically. The host DSI can send the data transfer to the respective protocol interfaces in the form of conversions like HDMI, DSI to HDMI, DSI to LVDS. Something like that with the help of MIPVDS switch. And right now I am working on trying to connect this particular pipeline. Since the pipeline can access only one output but here we have two outputs. We need to have a switch to implement those outputs. This particular use case still under discussion. In working with it is still under working process. What I want to go into is like I need to create a pipeline where output of DSI, basically output of DSI is single. Like we can access only port one with only one end point. But here I need to access two bridges in the form of two end points with single port one. And alter those ports based on the HDMI interrupt or based on some kind of a hard plug while interrupt. So that the switch is going to happen. I am not sure whether this particular thing or future is going to enable or accept by the moment. But there is a challenging to make this switch into pipeline steam because it is very hard to include a non video thing to video pipeline. That is where I have been still in the discussion, basically. The final bridge implementation of DLP bridge. This is how the similar what we have so far. I do see bridges, this particular bridge, but this is better which will convert the DSI data to DLP sector. Similar to what we have in normal converter bridges. But instead of connecting standard and panel, we need to connect a projector. Even in the latest perspective project is also called as a simple panel. So we need to have a projector timings like what you have a display timings in the panel side. So we need to identify those timings and we can attach those timings into the pipeline. We can treat it as a panel simple. So the output of the DSI is connected to input of the DLP VAC 3 4 W3. Output of DLP 3 4 W3 is connected to DMD projector. Like it is a simple panel. Once the pipeline is established, once it identifies the projector, it can establish the pipeline, it starts the pipeline attaching. And the actual data transfer is always going to happen in BII to see commands. Yeah, I have these libraries right now and the implementation for send it on mainly. I need to resolve some commands to make it more proper to upstate. Let us discuss the last topic about how these pictures have been probing. This is one of the sections where a lot of stack implementation is like incompatibility. Because DSI probing is more difficult because 2D is lack of enumeration unlike HDMI and others. But this particular DSI probe has been a lot of things need to take care not to do probe. Because we need to understand the pipeline and we need to create a proper pipeline setup in order to probe the pipeline devices, something like that. Let us talk about how this probing is happening in a pure bridge. A pure bridge, it can be a host bridge or it can be a slave bridge. But it cannot be a direct panel, that is what I am saying. So the pure bridge, you can connect a simple panel and even you can connect that bridge with a HDMI connector. Even that panel you can connect another LVDS encoder or another DPA encoder, something like that. That is what I call a pure bridge. There was an IIT 6161, which basically I have taken that part here. So the pipeline as I mentioned it, LCD interface is connected to DSI, Samsung DSI, which something like that is okay. So in the probe starting point of view, what the probe is like, the slave probe of IIT 6161. It is trying to attach the host. So host will find out whether there is a bridge is connected or a panel is connected. But here this slide is strictly connected to bridge. So I found the bridge, IIT 6161 bridge. Once it found the bridge, the host ends and the probe ends. But actual pipeline of the bridge attach will start from the LCD. That pipeline attach will internally call it as Samsung host attach. That internal calls to the slave attach, IIT 6161 attach. So all these bridges attachment is something like stacking the individual bridges. If you see all these bridges is going to happen like in a stack. The bridges that gets pushed or lost can get enabled first. Like each and every bridge has a bridge operations. So those operations can be taken in a stack fashion. In the right side, we have a, say for example, we can have connected HDMI connector. The HDMI connector is the last one in the stack. So it gets started like bridge operations of HDMI enable, pre-enable started. And those enable will start IIT 6161, those enable will start DSM 6161. Those enable will start with MXFB, something like that. In the stack fashion. If you connect bridges in normal panel, it can be treated as a panel bridge. The panel bridge enable call it as a IIT 6161 enable and DSM enable and MXFB enable something like that. That is how the probing is happening basically. In a simple panel, in simple panel, we have a panel that is attached basically. It cannot be a panel bridge, it can be a direct panel, STC, the ground zero panel. So the panel start attaching the host, host identifies the panel. Okay, there is a panel, attach it and bend and LCD interface start attaching. And it will start the same thing with attach and it can finally attach the panel bridge attach. Something that is how the internal pipeline attach is going to happen basically. So those panel attach will called as a panel operations. Since it is not a simple panel, it going to call the panel operations of STC on DSM 6161. The main fundamental differences between the bridge road versus panel probably is like we don't have a exclusive bridge driver here. The panel bridge itself acts as a bridge here basically. From the Linux DRM bridge point of view panel bridge is a virtual bridge for those who are connected as a panel to be treated as a bridge. Something like that. This is how the physical connection of my various bridge on my setup. There are many, but these are the typical ones that are gathered basically. The left one is more or less as a normal bridge. It's all been there. And the middle one is like a SIN 6854 DC bridge. The last one is a typical DLP bridge basically. So far these are the bridge limitations and we are trying to segregate all these stuffs to the main line. If you have any specific questions on this aspect of work on my contributions, you can easily shoot an email. And we have even the QR code we chat. If anyone wants to connect to me, you can connect via this. There are couple of things still under my line because of various blockages. I'm still working on it. I'm trying to close them as soon as possible to move the further. And there are couple of things already been upstream basically to support which is functionalities in order to understand all these pipeline constraints. That is how overall work of my thing is happened. If you have any specific questions and please let us know where you may run the chat. I'm here to help. Thank you. Thanks for your patience. Goodbye.