On 7/25/18 11:22 AM, Vinod wrote:
On 25-07-18, 09:10, Pierre-Louis Bossart wrote:
On 7/25/18 6:11 AM, Vinod wrote:
.dpcm_playback = 1,.no_pcm = 1,- },
- {
.name = "iDisp2",.id = 2,.cpu_dai_name = "iDisp2 Pin",.codec_name = "ehdaudio0D2",.codec_dai_name = "intel-hdmi-hifi2",.platform_name = "0000:00:1f.3",.dpcm_playback = 1,.no_pcm = 1,- },
- {
.name = "iDisp3",.id = 3,shouldn't this be queried. not all will have 3 links
Not that I know of. I've always seen SKL+ with 3 audio streams to iDisp.
IIRC later ones (after KBL) have 5 CVTs and 4 pins (or vice-versa)
Let me check on this.
+static struct platform_driver skl_hda_audio = {
- .probe = skl_hda_audio_probe,
- .driver = {
.name = "skl_hda_dsp_generic",who creates this pdev, is it the board details (mach name?)
Not sure I understand your question, this part is similar to all other Intel machine drivers and the way by with the probe happens is also similar. There is nothing new here, the skylake platform driver finds an entry in a table, gets the driver name and creates the relevant device.
Okay sounds good. I was curious if the generic machine device is created generically or use the tables..
we anticipate that there will be quirks, e.g. a machine with an HDaudio codec but DMICs, and the idea is that those quirks would point a different table entry (or set a pdata field). For now we haven't done any work on those quirks, we'll deal with them as we see new variants.