November 2011 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] [RFC] hda - is_jack_detectable()
by Raymond Yau 27 Dec '11

27 Dec '11

2011/11/14 Takashi Iwai <tiwai(a)suse.de>: > At Sat, 12 Nov 2011 19:31:20 +0800, > Raymond Yau wrote: >> >> 2011/11/9 Takashi Iwai <tiwai(a)suse.de>: >> > At Wed, 09 Nov 2011 08:08:17 +0100, >> > Takashi Iwai wrote: >> >> >> >> At Wed, 9 Nov 2011 12:06:04 +0800, >> >> Raymond Yau wrote: >> >> > >> >> > 2011/11/6 Takashi Iwai <tiwai(a)suse.de>: >> >> > > At Sat, 5 Nov 2011 13:30:21 +0800, >> >> > > Raymond Yau wrote: >> >> > >> >> >> > >> 2011/11/2 Takashi Iwai <tiwai(a)suse.de>: >> >> > >> > At Tue, 01 Nov 2011 17:03:29 -0400, >> >> > >> > David Henningsson wrote: >> >> > >> >> >> >> > >> >> 2011-10-24 23:31, Raymond Yau skrev: >> >> > >> >> > sorry, it should be >> >> > >> >> > >> >> > >> >> > static inline bool is_jack_detectable(struct hda_codec *codec, hda_nid_t nid) >> >> > >> >> > { >> >> > >> >> > return (snd_hda_query_pin_caps(codec, nid)& AC_PINCAP_PRES_DETECT)&& >> >> > >> >> > + !(get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid) >> >> > >> >> > & AC_DEFCFG_MISC_NO_PRESENCE))&& >> >> > >> >> > (get_wcaps(codec, nid)& AC_WCAP_UNSOL_CAP); >> >> > >> >> > } >> >> > >> >> > >> >> > >> >> I also think it is a good idea, in fact I thought it was this way >> >> > >> >> already. Can we merge this patch? >> >> > >> > >> >> > >> > OK, I checked through alsa-info series and confirmed that this causes >> >> > >> > no harm, so I merged it now. >> >> > >> > >> >> > >> > >> >> > >> > thanks, >> >> > >> > >> >> > >> > Takashi >> >> > >> > >> >> > >> > >> >> > >> >> >> > >> Sorry the previous patch is wrong >> >> > > >> >> > > Ugh, so actually changing it would may bring too many changes, and >> >> > > most likely regressions, too. I disabled the code for now for 3.2-rc1. >> >> > > Once when we cover all test cases and fix broken BIOS devices enough, >> >> > > we can re-enable it in near future. >> >> > > >> >> > >> attach the patch and test cases (pins 0x11 and 0x14) front panel >> >> > >> green and pink jacks when set Front Audio Panel to AC97 or HD in BIOS >> >> > >> setup >> >> > > >> >> > > OK, thanks, we can refer to this for more tests. >> >> > > >> >> > > >> >> > > Takashi >> >> > > >> >> > >> >> > If bit 0 is set, it indicates that the jack has no presence detect capability >> >> > >> >> > >> >> > The Configuration Default register is defined as shown in Figure 66. >> >> > 31:30 29:24 23:20 19:16 15:12 11:8 >> >> > 7:4 3:0 >> >> > Port Location Default Connection Color Misc >> >> > Default Sequence >> >> > Connectivity Device Type Association >> >> > Figure 66. Configuration Data Structure >> >> > >> >> > >> >> > This mean that bit 0 of Misc is bit 8 of the Configuration Default register >> >> > >> >> > >> >> > !(get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) >> >> > & AC_DEFCFG_MISC_NO_PRESENCE)&& >> >> > >> >> >> >> Yeah, I already tried it and it still gives too many false-positives. >> >> Many ASUS laptops (also mobo) set this bit to all pins no matter >> >> whether it's an obviously detectable jack or not. Some Toshiba >> >> laptops do so, too. >> >> >> >> That being said, checking this bit alone isn't reliable because of too >> >> many BIOS bugs. A bit more clever test is necessary. >> > >> > It seems that a broken BIOS sets this bit on all pins in general. >> > So, the patch below (against the latest sound git tree or 3.2-rc1 >> > kernel) seems working well by filtering out such a brokenness. >> > >> > Let me know if this works. If it's OK, I'll try to merge it for >> > 3.2-rc2. >> > >> >> The patch seem ok >> >> Need a hack to build the hda-jack branch >> >> It is quite simple to enable unsolicited event for all proper jacks by >> >> snd_hda_jack_add_kctrls(codec,(codec->spec->autocfg)); >> >> and >> >> static void ad1988_unsol_event(struct hda_codec *codec, unsigned int res) >> { >> struct ad198x_spec *spec = codec->spec; >> struct hda_jack_tbl *jack; >> u32 sense, caps; >> int pin; >> jack = snd_hda_jack_tbl_get_from_tag(codec, res >> 26); >> pin = jack->nid; >> caps = snd_hda_codec_get_pincfg(codec, pin); >> sense = snd_hda_codec_read(codec, pin, 0, AC_VERB_GET_PIN_SENSE, 0); >> if (sense & AC_PINSENSE_PRESENCE) >> snd_printdd("Pin 0x%x pd=1 imp=%d %s at %s %s %s\n", >> pin, >> sense & AC_PINSENSE_IMPEDANCE_MASK, >> snd_hda_get_jack_type(caps), >> snd_hda_get_jack_connectivity(caps), >> snd_hda_get_jack_location(caps), >> get_jack_color(caps)); >> else >> snd_printdd("Pin 0x%x pd=0 %s at %s %s %s\n", >> pin, >> snd_hda_get_jack_type(caps), >> snd_hda_get_jack_connectivity(caps), >> snd_hda_get_jack_location(caps), >> get_jack_color(caps)); >> >> if (pin == spec->autocfg.hp_pins[0] && !spec->independent_hp) >> ad198x_hp_automute(codec); >> if (pin == spec->ext_mic_pin) >> ad198x_mic_automute(codec); >> } >> >> >> However it seem that result is different in kctl >> >> >> amixer -c1 contents >> numid=5,iface=CARD,name='Front Headphone Jack' >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=6,iface=CARD,name='Front Mic Jack' >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=8,iface=CARD,name='Line Jack' >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=1,iface=CARD,name='Line-Out Jack' >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=2,iface=CARD,name='Line-Out Jack',index=1 >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=3,iface=CARD,name='Line-Out Jack',index=2 >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=4,iface=CARD,name='Line-Out Jack',index=3 >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> numid=7,iface=CARD,name='Rear Mic Jack' >> ; type=BOOLEAN,access=r-------,values=1 >> : values=off >> >> >> >> >> ./hda-jack-sense-test.py -c1 >> Pin 0x11 Green HP Out (Ext Front): Present = NO >> Pin 0x12 Green Line Out (Ext Rear): Present = YES Impedance = 19 >> Pin 0x14 Pink Mic (Ext Front): Present = NO >> Pin 0x15 Blue Line In (Ext Rear): Present = NO >> Pin 0x16 Black Line Out (Ext Rear): Present = YES Impedance = 3200 >> Pin 0x17 Pink Mic (Ext Rear): Present = YES Impedance = 896 >> Pin 0x18 Black CD (Int ATAPI): No jack detect capability >> Pin 0x1a Other (Int ATAPI): No jack detect capability >> Pin 0x1b Other SPDIF Out (Ext Rear): No jack detect capability >> Pin 0x24 Orange Line Out (Ext Rear): Present = NO >> Pin 0x25 Grey Line Out (Ext Rear): Present = YES Impedance = 3200 >> >> >> It need "SET_PIN_SENSE" and some delay to get the correct impedance >> of the jacks during driver load >> >> >> int snd_hda_jack_detect_enable(struct hda_codec *codec, hda_nid_t nid, >> unsigned char action) >> { >> + int ret; >> struct hda_jack_tbl *jack = snd_hda_jack_tbl_new(codec, nid); >> if (!jack) >> return -ENOMEM; >> if (jack->jack_detect) >> return 0; /* already registered */ >> jack->jack_detect = 1; >> if (action) >> jack->action = action; >> + ret = snd_hda_codec_write_cache(codec, nid, 0, >> + AC_VERB_SET_UNSOLICITED_ENABLE, >> + AC_USRSP_EN | jack->tag); >> + if (snd_hda_query_pin_caps(codec, nid) & AC_PINCAP_IMP_SENSE) { >> snd_hda_codec_read(codec, nid, 0, >> AC_VERB_SET_PIN_SENSE, 0); >> + msleep(200); >> + } >> + return ret; > > The lack of the initial pin-state of kclts was fixed in a different > patch now. But, the need of 200ms delay worries me whether it's > needed generically at each pin-sense reading or it's just only for the > initial reading. > > Does the pin-sense reading work in general after loading the driver > stably? > > > Presence detect bit is alway correct, without the delay. the only issue is the impedance measurement of the plugged jacks at computer boot need a delay 200ms For the user application to know the impedance , it seem the client application have to issue 1) set_pin_sense 2) delay 3) get_pin_sense to get the correct impedance of the attached device just like my modified hda-jack-sense-test in previous email Can it measure the impedance of the jacks of your computer ?

2 4

[alsa-devel] [RFC 0/5] compress: add compress data API to ALSA kernel
by Vinod Koul 23 Dec '11

23 Dec '11

As agreed during the ASoC workshop in May 2011, this set of patches are a proposal from Intel to add a new compressed data interface to ALSA. This proposal builds on the existing Intel solution and the experience gathered over two years with Meego and Android solutions. This proposal is no longer Intel-specific and was generalized with the addition of a basic core; codec-related definitions are based on the vendor-neutral OpenMAX AL standard. The code as is isn't functional and will need low-level hardware-specific drivers and a tighter integration with ALSA and ASoC. The main ideas will be presented during the Linux Plumbers Conference on September 9. Feedback through the mailing list would be greatly appreciated as well. Future versions will include support for capture, mmap, integration with alsa, asoc, dsp etc Support for effects is beyond the scope of this interface. Vinod Koul (5): compress API documentation compress: add compress parameter definations compress: add API header and driver header files compress: add the core file compress: add makefile and kconfig file .../sound/alsa/compress/snd_compress_data.txt | 186 ++++++ include/sound/compress_driver.h | 138 +++++ include/sound/compress_offload.h | 137 +++++ include/sound/snd_compress_params.h | 396 ++++++++++++ sound/Kconfig | 2 + sound/Makefile | 3 +- sound/compress_offload/Kconfig | 12 + sound/compress_offload/Makefile | 3 + sound/compress_offload/core.c | 632 ++++++++++++++++++++ 9 files changed, 1508 insertions(+), 1 deletions(-) create mode 100644 Documentation/sound/alsa/compress/snd_compress_data.txt create mode 100644 include/sound/compress_driver.h create mode 100644 include/sound/compress_offload.h create mode 100644 include/sound/snd_compress_params.h create mode 100644 sound/compress_offload/Kconfig create mode 100644 sound/compress_offload/Makefile create mode 100644 sound/compress_offload/core.c

9 110

[alsa-devel] [PATCH 0/5] RFC v2 for snd-usb endpoint logic rework
by Daniel Mack 19 Dec '11

19 Dec '11

This is v2 of the patch bulk I posted some weeks ago, which incoporates the points that were discussed. Thanks to everyone who commented and helped with sugesstions. This version work really well here, but as last time, it needs a lot more testing. What's still missing are some cleanups and more documentation, I'll do that once the acutal content is agreed upon. Patches should apply cleanly to the latest mainline git + Takashi's sound tree. Thanks for any feedback for this next round, Daniel Daniel Mack (5): ALSA: snd-usb: add snd_usb_audio-wide mutex ALSA: snd-usb: implement new endpoint streaming model ALSA: snd-usb: switch over to new endpoint streaming logic ALSA: snd-usb: remove old streaming logic ALSA: snd-usb: add support for implicit feedback sound/usb/card.c | 8 +- sound/usb/card.h | 65 +++ sound/usb/endpoint.c | 1434 +++++++++++++++++++++++++------------------------- sound/usb/endpoint.h | 31 +- sound/usb/pcm.c | 444 +++++++++++++--- sound/usb/stream.c | 31 +- sound/usb/usbaudio.h | 2 + 7 files changed, 1214 insertions(+), 801 deletions(-) -- 1.7.5.4

2 10

[alsa-devel] [PATCH v4 0/5] Support for OMAP4 Digital Microphone interface
by Peter Ujfalusi 16 Dec '11

16 Dec '11

Hello, The following series will add support for OMAP4 DMIC interface, and enable them on sdp4430/Blaze boards. Changes since v3: - dmic clk divider selection moved to hw_params phase to allow fixed rate configuration from machine driver init. Changes since v2: - Use module_platform_driver - convert to use devm_ - Add clk_id for the output clock - Extend the comment to explain why the driven can change the divider for 192KHz sampling rate. Changes since v1: - 192KHz rate support fixed (need to use different divider) - Hold reference for dmic_fclk over the lifetime of the driver - Removed the clkdiv callback, and replaced with frequency based configuration for the external components (dmic frequency) Regards, Peter --- Peter Ujfalusi (5): OMAP4: hwmod: Add names for DMIC memory address space ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC OMAP4: devices: Register OMAP4 DMIC platform device OMAP4: board-4430sdp: Register platform device for digimic codec ASoC: sdp4430: Add support for digital microphones arch/arm/mach-omap2/board-4430sdp.c | 6 + arch/arm/mach-omap2/devices.c | 22 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 + sound/soc/omap/Kconfig | 5 + sound/soc/omap/Makefile | 2 + sound/soc/omap/omap-dmic.c | 549 ++++++++++++++++++++++++++++ sound/soc/omap/omap-dmic.h | 69 ++++ sound/soc/omap/sdp4430.c | 85 ++++- 8 files changed, 729 insertions(+), 11 deletions(-) create mode 100644 sound/soc/omap/omap-dmic.c create mode 100644 sound/soc/omap/omap-dmic.h -- 1.7.8.rc3

5 10

[alsa-devel] Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)
by Colomban Wendling 14 Dec '11

14 Dec '11

Hi, Back to 3.0, the sound on my soundcard [1] started to be choppy, I reported it [2] and it got fixed (thanks to Takashi Iwai!). However, the story repeated with 3.1 (and probably 3.0.8 or before [3]): I've got similar choppy sound again. I bisected the few commits that happened on sound/pci/hda/patch_realtek.c, and finally found the villain: "8974bd51 ALSA: hda/realtek - Fix auto-mute with HP+LO configuration" Reverting it from v3.1 fixes the problem. master (94956ee) also suffers of the problem, but I couldn't test without that commit because reverting it fails, too much changes happened. Thanks for your attention, and if you need any extra information (although many are already available in my previous report [2]) or testing, please let me know. Regards, Colomban [1] Realtek ALC889 on an MSI H55M-E33 [2] bugs.debian.org/cgi-bin/bugreport.cgi?bug=635362, http://mailman.alsa-project.org/pipermail/alsa-devel/2011-July/042250.html (though I can't find my original message here) [3] I first saw the problem in Debian's 3.0.0-6 which includes 3.0 up to .8 -- but the debugging I did was on vanilla kernel from git://github.com/torvalds/linux.git.

2 4

Re: [alsa-devel] [PATCH 3/3] sound/soc/lapis: add platform driver
by Mark Brown 13 Dec '11

13 Dec '11

On Mon, Nov 21, 2011 at 01:08:52PM +0900, Tomoya MORINAGA wrote: > +/* =================== I2S CH0 config =================== */ > +#define I2S_CH0_MCLK (12288000) /* Master Clock Frequency[Hz] */ This looks like it should be board specific? > + #if IOH_I2S_USE_PARAM > + #define I2S_CH0_FS_16000 16000 > + #define I2S_CH0_FS_32000 32000 > + #define I2S_CH0_FS_48000 48000 > + #else > + #define I2S_CH0_FS_8000 8000 > + #define I2S_CH0_FS_11025 11025 > + #define I2S_CH0_FS_22050 22050 > + #define I2S_CH0_FS_44100 44100 > + #endif What are these ifdefs for? This should be configured at runtime. > +/* select master or slave. The value is ioh_mssel_t */ > +#define I2S_CH0_MSSEL (ioh_mssel_master) > +/* select MCLK or MLBCLK into Master Clock. The value is enum ioh_masterclk_t */ > +#define I2S_CH0_MASTERCLKSEL (ioh_masterclksel_mclk) This and most of the following defines also look like compile time configuration for things that should be runtime configured. As with the previous patches in the series the big picture issue here is that you need to update your code to reflect the practices of modern mainline Linux code - here the major issue is that you appear to be doing all your configuration with #defines rather than by using runtime configuration from the machine driver as is normal for ASoC code. I got through a bunch more defines but stopped reviewing at some point as there was so much of this issue.

2 4

[alsa-devel] ASoC: Dynamic CODEC DAI
by Patrick Lai 05 Dec '11

05 Dec '11

Problem overview: The CODEC which I am working on transports digital audio through SLIMBUS instead of I2S. The concept of CODEC DAI does not apply too well with SLIMBUS architecture as CODEC DAIs are typically defined base on a set of I2S digital audio interface(bit clock, world select, sd lines). On the CODEC, there are 10 digital capture ports. They can be independently configured as mono channels or can be run-time grouped together to function like multi-channel CODEC DAIs. On top of that, only some ports out of 10 ports can accept all analog mic inputs or digital mic inputs. Hence, even though the CODEC satisfies the concurrent use cases it was designed for, software would have to be articulate on grouping the ports in order to utilize all ports. So, I cannot simply code up CODEC DAI definitions in the CODEC driver for a particular machine. For now, I am looking for compile time grouping of these ports as use cases are known at the time machine is designed. Proposal: I want to minimize amount of change to soc framework at the same time meeting my requirement. Here is my proposed design In CODEC driver, I will declare codec dai for each port. Then, I will enhance ASoC framework to take a list of CODEC DAIs and pass list of CODEC DAIs back to callback function such as startup, hw_param, prepare, trigger. I believe this approach will not require massive amount of change to framework. Your feedback is appreciated. Thanks Patrick -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

4 8

[alsa-devel] Clevo P170HM / Sager NP8170 audio
by Andrew Mahone 04 Dec '11

04 Dec '11

This laptop is detected as ALC892 audio (and by the codec ID this seems to be valid), but none of the configurations for it quite match this device. I've been working on documenting the connections with HDA Analyzer. alsa-info output: http://www.alsa-project.org/db/?f=b86e4c6447867fbd129a36d8a63e2f5caa836c52 The laptop has built-in 5.1, and 5.1 or 7.1 output via jacks. DAC NIDs: 0x02 front 0x03 rear 0x04 clfe 0x05 side internal mixers: 0x0c front 0x0d rear 0x0e clfe 0x0f side internal speaker pins: 0x14 front 0x15 "rear" (front of laptop) 0x16 clfe external ports: fixed route: 0x17 side can select any output: 0x18 mic / output 0x1a line-in / output 0x1b headphone I've been experimenting with patch_realtek.c to add the extra DAC NID, and have had some success with a 6-channel mode for the built-in speakers and an 8-channel mode that mutes all internal speakers and sets the jacks up for output. I still need to manually connect pins 0x18, 0x1a, 0x1b to the correct internal mixers for 7.1 to work, and headphone plugin does not mute internal speakers in 5.1 mode. I have not added a plain stereo mode for internal speakers, although it appears that i can probably configure the codec to mix the front channels to center and LFE. Are there any suggestions for what to do next? My current state as a patch against the linux-3.0.y repository is at http://pastie.org/2400649 -- Andrew Mahone andrew DOT mahone AT gmail DOT com Q: How many voters does it take to change a lightbulb? A: None - if voting could change anything they'd make it illegal

3 29

Re: [alsa-devel] [patch][saa7134] do not change mute state for capturing audio
by Mauro Carvalho Chehab 03 Dec '11

03 Dec '11

Em 24-07-2011 14:45, Stas Sergeev escreveu: > 23.07.2011 19:09, Mauro Carvalho Chehab wrote: >> > In this case, it will not be autounmuted after tuning. >> Hard to tell about your solution without seeing a patch. > OK, it turns out the automute code is already there, > but it doesn't work. The driver for some reasons > starts the scan on initialization, finds the carrier: > --- > saa7134[0]/audio: found PAL main sound carrier @ 6.000 MHz [3969/324] > --- > and, because of that, disables the automute. If the > real mute is not enabled at that point, you get the > white noise right away. The automute code works fine. Maybe you have a strong interference at the default tuning frequency, leading into saa7134 miss-detection. For saa7134 driver: 1) There is an audio carrier; 2) an application wants to listen audio; 3) the device is at automute mode. So, when there's an audio carrier, it will unmute the audio at streaming start. The driver is doing the _right_ thing by letting the audio to flow to PA, when it starts the capture. Unfortunately, on your specific device, starting audio capture also enables audio at the audio output pin. So, you're noticing a problem. People with a saa7134 device without alsa stream won't notice it (old devices). People with alsa stream without anything connected to the LINE OUT people aren't noticing it, if PA is not copying the saa7134 PCM IN stream to the sound card PCM out device (the default, for PA). So, only people that has saa7134 with alsa stream that opted to wire the saa7134 device to the sound card, and with a strong interference at the default tunning frequency (400 MHz) would notice a problem. > Since I have no idea why it finds some carrier, I can't > fix that in any way. Or, maybe, not to call the scan > on driver init? What will that break? Analog tuners need to be tuned at the device init on a high frequency according with their datasheets, otherwise the PLL may fail. > Anyway, as long as the automute code is broken, > we should either start fixing it, or fix PA, or fix mplayer... As I always said, the fix should be at PA, as it makes no sense to start capturing at saa7134 without first configuring it. So, or PA should be converted into a V4L2-aware application, in order to properly init the device (with seems to be the wrong approach) or it _SHOULD_NOT_ automatically enable capture on those devices, as this may cause undesired side effects, on the devices that have the capture pin directly wired to the output pin, witch seems to be the case of your device. PS.: it seems that you've removed Lennart/alsa people from the c/c. I'm re-adding them, as I'm expecting a fix from their side. > Dunno. I wonder how come so many bugs left unfixed > for so long, resulting in a white noise to people... You're the first one that reported it, and the code is there for _years_. So, this is not a commonly noticed problem at all. Mauro.

2 15

Re: [alsa-devel] [PATCH 2/3] sound/soc/lapis: add machine driver
by Mark Brown 02 Dec '11

02 Dec '11

On Mon, Nov 21, 2011 at 01:08:51PM +0900, Tomoya MORINAGA wrote: > Add machine driver for LAPIS Semiconductor ML7213 IOH. This needs to come after you add the base platform support in the series - clearly this won't work without the CPU side drivers it depends on. As with the CODEC driver you really should be looking at the standards for modern drivers and following them. > @@ -60,6 +60,7 @@ source "sound/soc/s6000/Kconfig" > source "sound/soc/sh/Kconfig" > source "sound/soc/tegra/Kconfig" > source "sound/soc/txx9/Kconfig" > +source "sound/soc/lapis/Kconfig" Keep the Makefile and Kconfig entries sorted. > +static struct snd_soc_dai_link ioh_i2s_dai = { > + .name = "I2S", > + .stream_name = "I2S HiFi", > + .cpu_dai_name = "ml7213ioh-i2s", > + .codec_dai_name = "ml7213ioh-hifi", I'm very surprised this works... If nothing else I'd expec the CODEC DAI to have a different name to the CPU. > +static int __init ioh_i2s_probe(struct platform_device *pdev) > +{ > + int ret; > + > + soc_pdev = platform_device_alloc("soc-audio", -1); > + if (!soc_pdev) > + return -ENOMEM; You should register the card as a standard platform device for new drivers and use snd_soc_register_card(). > +static struct platform_driver ioh_i2s_driver = { > + .remove = ioh_i2s_remove, > + .driver = { > + .name = "ml7213ioh-machine", > + .owner = THIS_MODULE, > + }, > +}; You're already doing the platform device bit so it should be be a case of changing the body of probe() and remove(). > +static int __init ioh_i2s_init(void) > +{ > + return platform_driver_probe(&ioh_i2s_driver, > + ioh_i2s_probe); > +} Just make this a standard platform_driver_register().

3 5