 My name is Kenyatta Mouton, working for the RMSS Substance Team. It's a great pleasure for me to have a presentation today. Today's my topic is history of the RSA as a framework and it's a generic sound card. How many people are working for the RSA, or framework, driver, leading lighting? OK, good. Thank you. Thank you so much. Today's topic is a framework of generic sound card drivers. We have three drivers, three generic drivers. Today is why this generic card is added and how this is added. To be honest, it's three generic cards. Why we have three generic cards? This is a topic. It's history. Why this kind of thing is happening? So what is RSA? RSA SOC. RENAX is now using the RSA sound system with the sound. RSA is embedded RENAX sound architecture. Before RSA, we used OSS, open sound system before. I don't explain it yet here. But the original RSA is assuming this kind of systems. It is one type of one system, which is controlling the RSA system, sorry, sound system. It's very normal, not special, very easy. But in these days, the hardware is becoming more specific, having more specific features. So we need to create a more complex system like this. In this system, we need to control all chips. And this means we need to have many drivers. Handling this system is RSA SOC, which is a topic. And each device has a role, like here is a CPU chip and a codec chip. And in other words, here, the one is called a digital data handling. And here, one is another good data handling. We need to control these kind of chips and drivers. And handling this total handling is a generic sound cloud. And the background, I want to explain the background work concept of the RSA. Otherwise, it is very difficult to understand the topic. In normal RSA's case, I will explain the normal RSA's behavior. If you play back the sound, and your sound player will code RSA libraries. And the RSA library is called the RSA subsystems through the Linux kernel. And it will select the specified drivers. And this driver calls a handling device. And you can play back or capturing the sound. This is very similar. Sorry, this is very common, not special. And this is RSA normal concept. But if you want to use a more complex system like RSA SOC, you need to use the RSA SOC framework, subframework. And from a user side point of view, it is nothing changed in RSA and RSA SOC, of course. If you play back the RSA SOC drivers, you have to play out the RSA libraries, and it will call the RSA through the Linux kernel. Nothing changes so far, same as before. Now, to be honest, RSA SOC framework looks like normal RSA from the RSA point of view. But the inside was different. And it selected the RSA SOC drivers selected. It will code each drivers inside. And it will select the same command to each drivers, like play, play, play, stop, stop, or something like that. And each driver controls each devices. And you can control all systems in this system. This is not so super special, not common, but not special. Maybe the video side is using a similar system, before the time. This card driver, using RSA SOC, you need to create, you need to handle the GenX sound card drivers, sorry, the SOC card drivers, and platform and CPU codec drivers, total four drivers you need to prepare. Now, one note is this is almost 10 years ago, not currently, not almost 10 years ago. And the biggest main point isn't here, die. This is digital audio interface. This is not common, RSA specific name, not common name. This is the main things, and it is controlling here, handling this, how to send the digital data, how to receive the digital data from another two devices. And this is data structure. And this platform, what does the platform means is this is handling the DMA transfer, and here is the DMA transfer to CPU from the memories. In general, the CPU chips is also handling the DMA by itself. But some chips or some system need to, a special DMA transfer solution is required. And this platform is used for such kind of purposes. And the platform, as you can see, in the platform and the codec, has each own special data structures. I don't know why this kind of, oh, sorry. But the CPU doesn't have its own data structure. I don't know why, but maybe, I guess, the super beginning was, only die was added to the SOC. And maybe people added the codec after that. And maybe people added platform. But no one added the CPU data structures. So maybe, I don't know the idea, but maybe such kind of things happened before. Now, again, this is, no, 10 years ago. The handling of the SOC, you need to control four drivers, like card, platform, CPU, but how to connect and select the drivers is, if you can boot the kernels, it is including the main drivers. And this is indicating the main, such kind of things. It is probing the two codec drivers, two CPU drivers, two platform drivers. For example, if you were to probe each drivers, the probe driver is listed into the RSI SOC framework. And as you can see, each drivers on each data structure is including its own name, like this. DA something, something, or AK something, something. Such kind of naming all drivers have. And when you select and connect each necessary drivers into the kernels, this is, the user is name matching. For example, this case, and this card request, this platform, find it from the listed RSI SOC, and find it is unconnected. And a similar thing happened here, like this is a required CPU name, and find it from the listed one, unconnected and codec one. And this kind of thing. Because of this data structures and concept, this layer allows us to create a platform. As you can see, each platform has different style, different codecs are used. So because of that, necessary driver name is of course different for each platforms. In such case, in 10 years ago, in such case, we need to create each sound card driver for each boot. So this case, we need to create a three sound card drivers. But what is the difference is, just the required driver naming only, nothing changes, but we need to create such kind of drivers. So this is waste of the disk or waste of the time. Make no sense for me. This is a background. So I wanted to create a more common or generic drivers. So the first time I have created a RuneSense common sound card drivers. And this driver is required, the parameter for each drivers. This can be the parameters. Well, if we can use this kind of system, we can share the same drivers, but using the different parameters, that's make sense. I have created this kind of systems and posted the patches to the mailing list. But there are some maintainers, and the Mac Brown said, oh, sorry, this is a good idea. But this is not only RuneSense issues, it's common issues. So please share it to the more generic part, not only RuneSense. Okay, I can do this. But as you know, I'm Japanese, not English speakers, native speakers, so I have asked to Mark, what is a good name? Okay, so how about a simple audio card? It's very simple. Okay, I can do that. That's the reason why this driver's name does a simple audio card. This is a history. Name owner is not me, Mac Brown. So I have created this. I'm very happy, and people started to use this because I'm a giant. I was very happy about that, but something happened after that. It's a device tree. As you know, RuneSense requests using a device tree, especially for the armed peoples. But using the device tree, switch to the device tree style, we need to update the drivers, for each driver, of course, this simple card too. Of course, I created such kind of patch and posted it. It was very small one patch, as a first step, but something happened. The problem is, this kind of data mismatching was very big issues. As you know, the device tree is indicating the device connections. It is not for software configurations, but from our side, data structure is this kind of unbalanced connection is used because of that. Getting each driver naming from the device connection is was impossible, was super difficult, mainly impossible. One RSS was the expert pointing it, and my positive patch was not good for the device tree design, so we need to solve the issues. But it was very difficult. We have discussed how to solve it, what is required data, and how to switch it, how to solve it, it is almost one year we have discussed on the mailing list. And the final answer is, let's merge each specific, special data structure, like codec and platform into the one data structure, new data structure, because some features are duplicated between these two. Let's name it as a component, and let's use this new component to this CPU, because we are missing it. Because of this, we have discussed on this, and we created, we merged it, and created a switch to the new style we decided, but that's how it should happen. As you know, if you, maybe people don't like one big patch, like this patch changes everything, bang, everything changes, everything changes, everything is changed, people don't like this, right? All the people love is the small change patch set. This is understandable, but if I did it to the framework, the RSI source is already used from almost 200 drivers. So this means if I use a small patch set, small changes, one patch, one framework patch, becoming almost 200 drivers patches, it is not so good, patch bone coming to the mailing list. People don't like it. So how to switch to the new style is, we decided it's inside RSI source C, start to use a new style, but the interface to the drivers is keep the compatibility or nothing changed, but inside we switch it to the new style. And we created and merged the new platform and codec into a new component one by one, and maybe, I don't remember, but maybe 100 or 200 patches require to switch to the new style. And if the old framework or new feature, all features are switched to new style inside RSI source C, finally we started, I started sending a patch to folder each drivers to switch to the new style. Of course, from the one drivers point of view, everything changed in one patches, but it can't help. But we can keep the very small patch sets in the mailing list with the people. So now we can use, now we could switch to the new device on the simple card. Now people, I was a bit happy and people may be also happy, and people started to use the simple card, but there are issues kind. So I needed to create a new drivers, new generic card. So what's happened? It is HDMI. As you know, the HDMI, Ronasas want to use HDMI support in the kernel. Of course it is already working, nothing special. No problems, but the problem is, oh sorry, the HDMI needs, as you know, video and sound, V4 sound is also required. But what is the problem is, that's the best way. Because V4, too, and the other are using a completely different style for each, especially video side is already using an over graph style. This is very new ideas. I don't explain detail no matter what is the over graph today, but the basic idea is like this. If you have a system and you can connect to the panel, and through this common connectors, in such cases, of course you can try many kind of panels, but how to indicate it in the device tree? In the device tree, it is possible to use a P-handle style. But if we are indicating this kind of connection in the P-handle, it is very difficult to understand. It is switchable or required, or how to know to switch on the existing P-handle. This is mainly the video people's side issues. So they created a new over graph style. It is possible to selecting and indicating this kind of system on the device tree. Because the device tree is indicating the device connections, the HDMI issues use the same style with the other side to see the device issues for all the video or boyfriend to side style. This means over graph. But supporting the over graph on the simple car driver was very difficult or impossible. The reason is binary compatibility. Because the over graph style and original sound, simple sound and car style are completely different. And of course, adding such kind of feature on the simple car itself is not so super difficult, but it is very difficult to the binary compatibility. And creating such kind of very complex system and complex drivers, it is easy to have a bug inside. So I don't like it. So I decided to create a new style, a new driver, new genetic driver, new genetic drivers. The creating like this is not difficult. The difference between the simple car and the new drivers is passing a device tree only. After that is everything, nothing change it. So I created a shared library, sorry, a shared code as a utility, a simple car utility. And the passing part and the main part are separated. And the passing part is a new one. So I have created such kind of new drivers and posted it as a simple graph card. But how they should come in? It's over graph maintainer said, no, this is not a good name. I have explained why this is called as a simple audio card is what I explained because we already have a simple audio card. So I want to follow that similar naming. But the over graph maintainer said, no, I don't like it. So what is a good name? I asked him, he said, how about the audio graph card? Okay, I can accept. Well, this is the reason why it is named as an audio graph card. The name owner is not me, but the over graph maintainer. Now there's a simple card is putting normal platform data style and device to the style. And the audio graph card is supporting the device to the style, sorry, over graph style. As I already explained, the difference is only the passing part only, the device to the passing part only. Now everything is very similar or almost same. So if you compare these two drivers, it is easy to understand what is the difference of what is the difference. And maybe you can understand it is very similar each drivers. So this is, I'm happy, I have created, I'm very happy about that. But something other issue happens. So what is that? Yes, RSI SOC connections. Now to be honest, RSI SOC framework is supporting too many device connections. Very complex one is included. This is very normal. It is included a normal style connection that I have already explained. And this is already supported in the post existing simple card and audio graph card. It's a very common, very basic style, but RSI SOC is supporting more complex one like multi CPU or multi codecs. This picture is indicating is this, is for example, if we want to play it a six channel sound on some chip is possible to output three or two channels like this. In this style, you need to use a special format in RSI SOC, but it is not supported on the existing drivers. It is very difficult to update it to support it on existing one. Or like this is DPCM. This is in some chips is having the DSP inside. And sometimes you can use like mixing, like two input mixing to one output. Or you can switch the output like from here or from here, from here you can switch it by using this DSP. But in supporting this, supporting to use this, you need to use a special feature which is called as DPCM. But this is not supported in the previous genic card. Here is a more complex one. DPCM with a multi CPU or multi codecs. If you want to use six channels with mixing, you need to use a more complex system. Sometimes people want to use a codec input sound to directly connect to the playback side. Loop back. And this kind of system is not assumed in the normal RSI SOC system, but it is supported. But to use this system, you need to use a very special handling as required. More complex one is codec to codec with multi system. This is nightmare for me, but some of them want to use this. But the RSI SOC are supporting this kind of systems but existing the generic card, simple card and audio or graph card doesn't support this complex system. But people want to use the generic card to support it. So I have, yes, supporting this with keeping a binary compatibility for the device today is very difficult or impossible. Or maybe possible, but it can be a buggy and I don't like it and people don't like it. So I decided to create a new one, new drivers. I have created such kind of drivers named as audio graph card two. And post it in the mailing list. But the RSI SOC maintainer didn't accept it, reject it. Now he mentioned this, how about to use that? And then this was the naming. He said how about to use the rich graph card? That's okay. But the RSI SOC, some expert claim it. So does it mean if the known rich graph card is poor? Of course not. So the naming was not so good. And I have explained that the reason why I have added the audio graph card two was because we don't know in the future. Maybe some other feature are added in the future and maybe it is difficult to keep the compatibility. In such cases, we shouldn't hesitate to add a new device style. So because of us, I have added, it is named as sound audio graph card two. So this means in the future, if the more complex hardware are coming or new ideas are coming into the RSI SOC CSM, maybe we want to have like card three or card four in the future. I have explained this to the maintainer and understand my idea and accepted it. So this is the reason why it is named as audio graph card two. One of the big problem in the genetics card is customizing because it is very genetic but some board or some platform or some board want to have, want to handling the board specific features somehow. But it is implementing on the genetic card is very difficult or impossible. So the audio graph card and graph card two is supporting the customization of features. And I added that it's sample code into the GeneX counter. You can find it. And you can find it. And this is in the sample of the customizing. It is easy to use. Normal GeneX and card style. And you can add new customization features in here. And as I have indicated, the RSI SOC is supporting the very complex connections and card two is supporting it. But this means that the device style is becoming more complex. So I have added sample code, sample device DT settings here. You can see that each image is and how to handle it into this sample of code. It is a bit complex, but better than nothing. You can use it, please use this. And of course you can test it without a specific hardware. It works by using dummy drivers. If you don't have any special reasons, they're using a simple genetic card like a simple audio card or audio graph card is required by the main channel. Please use it, it's very useful to the people. Thank you for listening. This is my presentation. Thank you. And it's time to end. Any questions? No? Okay, thank you. Thank you very much.