[alsa-devel] Developing a ti-pcm1863 (adc) codec driver
Hello Mr. Brown,
I have a soundcard which doesnt have a linux driver. Quick information it has a pcm1863 adc and a pcm5142 dac on it.
I began with the sample dt-overlay and edited it to get the playback working. No problem at all using the pcm512x.c codec driver.
After that I began with the development of the codec driver, i2c driver and a dt-overlay with 2 sound links as I need the record and playback functionality.
Right now the i2c driver seems to work since I get the hardware into the used state "UU" when executing the i2cdetect command and dmesg says "mapping okay". My codec driver has the codec driver and dai definitions and some more functions (here I am stuck). I know that I need the hw_params and some set functions to have the minimal functionality.
1. Question would be towards the dapm_widgets and dapm_routes definitions. When defining the dapm_adc widget do I put there the Capture stream or do I seperate it with "NULL" and then adding the dapm_routes definitions? Which one is correct since I have seen both possibilities (which ad-/disadventages do I have?)
2. Question in my layout plan I need to set the ADC to VIN4 l/r because only this one is connected to the microphone port. I have put it into the sound controls but how would I make this switch from the command line (arecord) or in the players (like vlc)
3. It seems that I have a bug in the code since I cant execute arecord right now it says file doesnt exist.
Furthermore I would really be interested in gaining more knowledge about the accesses and routines from e.g. the vlc player using alsa (?) and then the accesses to the hardware? Also the whole registering process in which order are which files executed to get into the state where the os knows my soundcard. Since in a stracktrace I dont see this high level functions executed. I have found some diagramms on a chinese blog which look not bad but it would be a lot better to find it out myself with the os if possible. Here is an example of this kind of diagramm: http://img.blog.csdn.net/20160127104235066?watermark/2/text/aHR0cDovL2Jsb2cu...
This is knowledge is right now optional but would be very helpful for the understanding.
I will attach the codec driver, codec driver-header, i2c driver, dt-overlay and a strack trace (ltrace just hangs up) so it would be possible to find out what is causing the problem right now. Please note that this is my first driver development and the code is work in progress :)
Thanks a lot for Your time and Your help! If an information is missing please ask for it and if possible I will try to provide it :)
Sanj3k
On Wed, Aug 23, 2017 at 06:32:03PM +0200, Oleksandr Müller wrote:
Hello Mr. Brown,
I have a soundcard which doesnt have a linux driver. Quick information it has a pcm1863 adc and a pcm5142 dac on it.
This looks like you've got most of a driver here, probably the easiest thing to do is submit it using the process outlined in SubmittingPatches. The code looks mostly fine so this shouldn't be too much of an issue.
- Question would be towards the dapm_widgets and dapm_routes definitions.
When defining the dapm_adc widget do I put there the Capture stream or do I seperate it with "NULL" and then adding the dapm_routes definitions? Which one is correct since I have seen both possibilities (which ad-/disadventages do I have?)
Use a route, that's the more modern way.
- Question in my layout plan I need to set the ADC to VIN4 l/r because only
this one is connected to the microphone port. I have put it into the sound controls but how would I make this switch from the command line (arecord) or in the players (like vlc)
I'm not sure I understand the question here.
Furthermore I would really be interested in gaining more knowledge about the accesses and routines from e.g. the vlc player using alsa (?) and then the accesses to the hardware? Also the whole registering process in which order are which files executed to get into the state where the os knows my soundcard. Since in a stracktrace I dont see this high level functions
You can see the card initialization in the code. There's no defined ordering for the device model probing, even if things are currently redicatable on your system you shouldn't rely on anything.
//Register Addresses
Please follow the kernel coding style.
static const struct snd_kcontrol_new pcm1863_controls[] = { SOC_SINGLE("ADC MUX VIN4L", PCM1863_ADC1_INPUT_SEL_L, //not possible with SOC_DOUBLE since PCM1863_SEL_L_VIN4, 1, 0), //two different register?
SOC_DOUBLE_R()
"Failed to enable clock divider autoset: %d\n", ret); return ret; }case SND_SOC_DAIFMT_CBM_CFM:
Missing break;
MODULE_DESCRIPTION("ASoC pcm1863 driver"); MODULE_AUTHOR("Dummy Name test@gmail.com");
Fill it in or omit it.
static const struct of_device_id pcm1863_of_match[] = { { .compatible = "ti,pcm1863", }, { } }; MODULE_DEVICE_TABLE(of, pcm1863_of_match);
You need a binding document for this.
Hello Mr. Brown,
Use a route, that's the more modern way.
Would then this be correct?
static const struct snd_soc_dapm_widget pcm1863_dapm_widgets[] = { SND_SOC_DAPM_ADC("ADC1", NULL, SND_SOC_NOPM, 0, 0), SND_SOC_DAPM_INPUT("SE_IN_L"), SND_SOC_DAPM_INPUT("SE_IN_R"), };
static const struct snd_soc_dapm_route pcm1863_dapm_routes[] = { { "ADC1", NULL, "SE_IN_L" }, { "ADC1", NULL, "SE_IN_R" }, { "SE_IN_L", NULL, "Capture" }, { "SE_IN_R", NULL, "Capture" }, };
I'm not sure I understand the question here.
I mean by default the adc takes VIN1 as an input and I need him to take VIN4. If I put my switch under sound controls do I have to trigger it, and if yes how? The corrected line should look like this?
static const struct snd_kcontrol_new pcm1863_controls[] = { SOC_DOUBLE_R("ADC MUX VIN4", PCM1863_ADC1_INPUT_SEL_L, PCM1863_ADC1_INPUT_SEL_R, 4, 1, 0), //I need an 8 viewed from the 0 position so shifting an "1" 4 times };
Please follow the kernel coding style.
Updated codec driver is attached, with a vim plugin it seems that this should be better now. I updated the missing break statements but I get the same error even now. Please take a look again.
This looks like you've got most of a driver here, probably the easiest thing to do is submit it using the process outlined in SubmittingPatches. The code looks mostly fine so this shouldn't be too much of an issue.
I dont know this process. At first I would want to get it working with my hardware before I would begin with a more detailed development with a lot more functionalities.
Sanj3k
On Fri, Aug 25, 2017 at 11:24:24AM +0200, Oleksandr Müller wrote:
Use a route, that's the more modern way.
Would then this be correct?
Yes.
I'm not sure I understand the question here.
I mean by default the adc takes VIN1 as an input and I need him to take VIN4. If I put my switch under sound controls do I have to trigger it, and if yes how? The corrected line should look like this?
That sounds like a DAPM mux?
This looks like you've got most of a driver here, probably the easiest thing to do is submit it using the process outlined in SubmittingPatches. The code looks mostly fine so this shouldn't be too much of an issue.
I dont know this process. At first I would want to get it working with my hardware before I would begin with a more detailed development with a lot more functionalities.
Like I say the process is documented in SubmittingPatches (in the kernel tree).
participants (2)
-
Mark Brown -
Oleksandr Müller