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

Re: [alsa-devel] [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
by Ricardo Neri 23 Nov '12

23 Nov '12

On 11/22/2012 06:52 AM, Tomi Valkeinen wrote: > On 2012-11-22 02:20, Ricardo Neri wrote: >> Hi Tomi, Mark, >> >> On 11/19/2012 07:15 PM, Mark Brown wrote: >>> On Mon, Nov 19, 2012 at 02:58:41PM +0200, Tomi Valkeinen wrote: >>> >>>> I still don't understand why the codec and machine drivers need to be >>>> created in the board file. That just forces us to replicate the same >>>> code for all OMAP boards that have OMAP HDMI output. Why not create the >>>> devices in some common code, for example arch/arm/mach-omap2/display.c? >>> >>> Yes, this would be more sensible if there's no board specifics involved. >> >> I think they are truly board-specific. For instance, there could be some > > I don't =). > >> board that does not have the OMAP HDMI IP wired to an external >> connector. We don't want the drivers to be probed in that case. If they >> are in common code, the devices will be created even if a board does not >> have HDMI output. > > The HDMI devices are still there in the HW even if we don't have a HDMI > connector. I don't see any problem with probing the HDMI audio driver > even in that case. > > But of course the user space shouldn't see a usable HDMI display/audio > if there's no connector. For display side this is managed so that the > HDMI IP driver is always loaded, but a HDMI panel driver is only there > if the board file tells that we have a connector. > > I guess this could be optimized by having a "disabled" flag for HDMI IP > driver, so that it wouldn't even need to allocate any private data > structures of such. But the savings would be quite minimal. Maybe, just create the devices for ASoC only if it sees a HDMI dss device in the omapdss_board_info? > >>>> With DT this should be similar: OMAP's hdmi devices should be presented >>>> in the omap4.dtsi file, not in each individual board dts. Although the >>>> DT data should represent the hardware, and if the code and machine >>>> devices are not really there in the HW, then... I don't know =). >>> >>> Well, in a case like this where the sound card is essentially autoprobed >>> based on the detection of the hardware at runtime the sound card >>> probably shouldn't appear in the device tree at all - you'll probably >>> want something to say there's a physical HDMI port it's worth looking at >>> there but everything else should be figured out at runtime. >> >> Yes, I was planning to rely on the DSS DT entries in the omap4.dtsi >> file. However, no HDMI audio support should be probed if the board does >> not have an HDMI connector. Also, the TPD chip should appear on the >> Pandaboard/SDP4430 dts files. Only if both conditions are met, probe the >> HDMI audio drivers, this conditions will be checked at run time by the >> ASoC HDMI machine driver. >> >> Something like this: >> >> sound_hdmi { >> compatible = "ti,omap-hdmi-card-audio"; >> ti,model = "OMAP4HDMI"; >> >> ti,hdmi_audio = <&hdmi>; >> ti,level_shifter = <&tpd12s015>; >> }; >> >> The ASoC machine driver would create the platform device for the HDMI >> codec if the DT has the required nodes. > > The TPD chip really shouldn't be here in. It's an external component, > not related to audio in any way. I think the HDMI audio driver should be > only concerned about the HDMI IP. OK. So display code will handle all the DT details for the audio drivers to use. > The HDMI IP video driver shouldn't > care about TPD chip either, but for now we need to manage it somewhere, > and that's the easiest place for it. BTW, I have a draft for this, but more urgent things have been consuming my bandwidth. :/ BR, Ricardo > > So... I'm not sure how this should be managed, but I am 99% sure that > there's nothing board specific with HDMI audio, and thus it should be > managed in common .c files in arch code or dss code, or .dts files. If > we add the hdmi display in the .dts files, I think the audio should just > work. > > Or is there something in ASoC that forces us to represent it in the > .dts? I don't think there's really anything related to HW to describe > there related to HDMI audio. If we have HDMI video output, we also have > the audio, as simple as that. > > Tomi > >

1 0

Re: [alsa-devel] [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
by Mark Brown 23 Nov '12

23 Nov '12

On Thu, Nov 22, 2012 at 02:52:50PM +0200, Tomi Valkeinen wrote: > Or is there something in ASoC that forces us to represent it in the > .dts? I don't think there's really anything related to HW to describe There shouldn't be.

1 0

Re: [alsa-devel] [PATCH 0/10] Kirkwood ASoC drivers fixes and improvements
by Mark Brown 23 Nov '12

23 Nov '12

On Thu, Nov 22, 2012 at 04:29:22PM +0100, Arnaud Patard wrote: > Russell King - ARM Linux <linux(a)arm.linux.org.uk> writes: > > Argh. Just noticed the driver author is _not_ listed in MAINTAINTERS. > hm. right. sorry. I tend to always forget this. Is this still really > usefull given that there's get_maintainer.pl ? Yes, get_maintainer.pl is far too prone to problems like false positives and other issues when it guesses based on git - real information helps it a lot.

1 0

Re: [alsa-devel] [PATCH 0/10] Kirkwood ASoC drivers fixes and improvements
by Mark Brown 23 Nov '12

23 Nov '12

On Thu, Nov 22, 2012 at 02:06:14PM +0000, Russell King - ARM Linux wrote: > Instead, a DT description will just declare there to be one I2S device > with its relevant resources. Yes, this is exactly the sort of thing all the existing platforms using DT are doing in their ASoC drivers - there's normally some grouping or sharing at the hardware level that doesn't map exactly onto Linux models. We're already at the point you're trying to get to here. > Such a description is _inherently_ incompatible with ASoC as long as > ASoC insists that there is this artificial distinction. > What Mark is telling me is that he requires yet more board files to > spring up under sound/soc/ which create these artificial platform > devices. Not only does that go against the direction which we're heading What I said was that you should just register everything from the DT nodes that describe the hardware and not create dummy devices in the DT for the Linux internals. The drivers instantiated from DT should take care of mapping the hardware into Linux, instantiating everything they need to from code. The approach the existing drivers in mainline are taking is to register multiple ASoC functions from a single device model device which seems like the logical approach to doing the mapping to me. Some of the remarks you've made on IRC and code you've pointed me at suggest that you have formed the impression that there needs to be a 1:1 mapping between device model devices and ASoC function drivers. This is not the case. A driver for a device model device can register as many different ASoC functions of whatever type it sees fit from a single device model device. > on ARM (at Linus' insistance) to get rid of board files, but it perpetuates > this silly idea that every audio interface should be split up whether > there's a distinction there or not. I'm not entirely convinced that modelling different areas of functionality with different ops structures (which is essentially what is happening here) is a massive design flaw. > We need to have solutions which do not require artificial breakup of > drivers; we need solutions where hardware can be described by DT and > that DT description be used by the kernel with the minimum of code. > What we don't need are yet more board files appearing in some other > random part of the kernel tree. This is the current situation, none of the existing DT using platforms have had any need to do that. Nothing about Kirkwood audio seems to be at all unusual here. We *do* have board files for the linkage between the various components since (as discussed previously ad nauseum) a lot of embedded audio hardware is interesting enough to warrant having a driver itself. There has been some work on generic drivers for simpler systems which should be useful and can be built on, though we do need the problems with the clock framework availability to be addressed (both getting it available on all platforms and ensuring that the platforms with custom frameworks move to the genric one). These drivers are separate to the issue you are discussing.

1 0

Re: [alsa-devel] [Alsa-user] Ticks when playing to USB DAC at high sample rates
by Daniel Mack 22 Nov '12

22 Nov '12

On 07.11.2012 18:05, Jeffrey Barish wrote: > On Wed 07 November 2012 10:04:14 Daniel Mack wrote: >> On 07.11.2012 10:01, Daniel Mack wrote: >>> On 07.11.2012 00:54, Jeffrey Barish wrote: >>>> I guess that snd_usb_pcm_prepare is called by the core usb system to >>>> prepare the snd driver. Anyway, snd_usb_pcm_prepare calls >>>> configure_endpoint with a substream. Then configure_endpoint calls >>>> snd_usb_endpoint_set_params with the data endpoint that corresponds to >>>> the substream. snd_usb_endpoint_set_params calls data_ep_set_params >>>> with the data ep and data_ep_set_params sets nurbs to 2 for the data >>>> endpoint. >>>> >>>> snd_usb_endpoint_set_params has code to call sync_ep_set_params when the >>>> endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). >>>> However, snd_usb_endpoint_set_params never invokes the call to >>>> sync_ep_set_params because ep->type is always data. Back up: >>>> snd_usb_endpoint_set_params is called from configure_endpoint. It is >>>> called from an if block contingent on the substream's having a sync >>>> endpoint. It does. However, the call to snd_usb_endpoint_set_params >>>> passes subs->data_endpoint as the first argument, so >>>> snd_usb_endpoint_set_params simply repeats the operations it performed >>>> as a result of the previous invocation. I presume that the first >>>> argument to the second call to snd_usb_endpoint_set_params should be >>>> subs->sync_endpoint.> >>> Eh. You clearly spotted a bug here. The rally interesting thing is that >>> that it didn't bite us earlier, as it's in since 3.6. >>> >>>> I >>>> >>>> made that change. Now freqm does change. However, I am getting tons of >>>> ticks. Now it sounds as if the payload size is always wrong. >>>> >>>> Oh, 44.1 kHz works. 48 kHz works. 88.2 and 96 don't work. >>> >>> That's a different issue. Would you like to prepare a patch for the >>> issue above please? > > I don't know how to prepare a patch, so I'm inclined to fix the remaining > problem before stopping to figure out the patch problem. > > I didn't get your previous email. I hope that it contained some suggestions > on what to look for to solve the remaining problem. Please send it again. > The problem seems to be related to timing considering that the driver works > perfectly 5-10% of the time, but timing of what? I don't know what to look > for. So with the first problem sorted out, I guess the other one is related to to inexactly reported data feedback from the device. Some explanation about the current code. The code in the lower half in snd_usb_handle_sync_urb(), endpoint.c does some auto-detection of the feedback rate format. This is done in order to cope with all the many devices use have all sorts of rate formats. When called for the first time after a stream start, it shifts the received value until it matches the nominal sampling frequency with an accuracy of +50% or -25%. Once the shift value is determined, it is saved for later reference. In case the values get badly of of bounds over subsequent calls, the code falls back to the auto-detection mode again. In other words: if the device reports a bogus value in the very first feedback packet, but stays inside the limits of the thresholds that would make it fall back to auto-detection, the shift value will always be wrong for the duration of that stream, resulting in bogus data rates produced by the driver. This is where I would have a look. Add some printk()s in the "if (unlikely(ep->freqshift == INT_MIN))" case and dump the values that are detected, for both a working and non-working case. Let me know if that brings you anywhere :) Daniel

1 1

[alsa-devel] [sound:for-next 70/72] sound/pci/rme9652/hdsp.c:5103:4: error: implicit declaration of function 'vmalloc'
by kbuild test robot 22 Nov '12

22 Nov '12

tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-next head: 4f86f120d9d65b3a8f17e48dca1f991d861b5cd7 commit: 90caaef6a1ce2ec6675b1dc5afd57767954ab7e8 [70/72] ALSA: hdsp: improve firmware caching config: make ARCH=powerpc allmodconfig All error/warnings: sound/pci/rme9652/hdsp.c: In function 'snd_hdsp_hwdep_ioctl': sound/pci/rme9652/hdsp.c:5103:4: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration] sound/pci/rme9652/hdsp.c:5103:22: warning: assignment makes pointer from integer without a cast [enabled by default] sound/pci/rme9652/hdsp.c:5110:4: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors vim +5103 +/vmalloc sound/pci/rme9652/hdsp.c ^1da177e Linus Torvalds 2005-04-16 5097 return -EFAULT; f9ffc5d6 Tim Blechmann 2009-02-20 5098 b0b98119 Takashi Iwai 2005-10-20 5099 if (hdsp_check_for_iobox (hdsp)) ^1da177e Linus Torvalds 2005-04-16 5100 return -EIO; ^1da177e Linus Torvalds 2005-04-16 5101 90caaef6 Takashi Iwai 2012-11-22 5102 if (!hdsp->fw_uploaded) { 90caaef6 Takashi Iwai 2012-11-22 @5103 hdsp->fw_uploaded = vmalloc(HDSP_FIRMWARE_SIZE); 90caaef6 Takashi Iwai 2012-11-22 5104 if (!hdsp->fw_uploaded) 90caaef6 Takashi Iwai 2012-11-22 5105 return -ENOMEM; 90caaef6 Takashi Iwai 2012-11-22 5106 } 90caaef6 Takashi Iwai 2012-11-22 5107 90caaef6 Takashi Iwai 2012-11-22 5108 if (copy_from_user(hdsp->fw_uploaded, firmware_data, 90caaef6 Takashi Iwai 2012-11-22 5109 HDSP_FIRMWARE_SIZE)) { 90caaef6 Takashi Iwai 2012-11-22 @5110 vfree(hdsp->fw_uploaded); 90caaef6 Takashi Iwai 2012-11-22 5111 hdsp->fw_uploaded = NULL; ^1da177e Linus Torvalds 2005-04-16 5112 return -EFAULT; 90caaef6 Takashi Iwai 2012-11-22 5113 } --- 0-DAY kernel build testing backend Open Source Technology Center Fengguang Wu, Yuanhan Liu Intel Corporation

2 1

Re: [alsa-devel] [Alsa-user] Ticks when playing to USB DAC at high sample rates
by Daniel Mack 22 Nov '12

22 Nov '12

Hi Jeffrey, sorry for the late reply. On 08.11.2012 19:54, Jeffrey Barish wrote: > On Wed 07 November 2012 10:01:14 Daniel Mack wrote: >> On 07.11.2012 00:54, Jeffrey Barish wrote: >>> I guess that snd_usb_pcm_prepare is called by the core usb system to >>> prepare the snd driver. Anyway, snd_usb_pcm_prepare calls >>> configure_endpoint with a substream. Then configure_endpoint calls >>> snd_usb_endpoint_set_params with the data endpoint that corresponds to >>> the substream. snd_usb_endpoint_set_params calls data_ep_set_params with >>> the data ep and data_ep_set_params sets nurbs to 2 for the data endpoint. >>> >>> snd_usb_endpoint_set_params has code to call sync_ep_set_params when the >>> endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). >>> However, snd_usb_endpoint_set_params never invokes the call to >>> sync_ep_set_params because ep->type is always data. Back up: >>> snd_usb_endpoint_set_params is called from configure_endpoint. It is >>> called from an if block contingent on the substream's having a sync >>> endpoint. It does. However, the call to snd_usb_endpoint_set_params >>> passes subs->data_endpoint as the first argument, so >>> snd_usb_endpoint_set_params simply repeats the operations it performed as >>> a result of the previous invocation. I presume that the first argument >>> to the second call to snd_usb_endpoint_set_params should be >>> subs->sync_endpoint. >> Eh. You clearly spotted a bug here. The rally interesting thing is that >> that it didn't bite us earlier, as it's in since 3.6. > > Here's the diff. I can't figure out how to submit a patch. > > --- sound/usb/pcm.c.orig 2012-11-08 11:43:57.309732860 -0700 > +++ sound/usb/pcm.c 2012-11-08 11:41:06.512420658 -0700 > @@ -456,7 +456,7 @@ static int configure_endpoint(struct snd > return ret; > > if (subs->sync_endpoint) > - ret = snd_usb_endpoint_set_params(subs->data_endpoint, > + ret = snd_usb_endpoint_set_params(subs->sync_endpoint, > subs->pcm_format, > subs->channels, > subs->period_bytes, Thanks - I just sent out a patch for this. Daniel

1 0

[alsa-devel] [PATCH] ALSA: hda - Don't overwrite the pin default configs
by Takashi Iwai 22 Nov '12

22 Nov '12

Since we keep the pin default config values anyway internally, we don't have to set the values in the codec. This patch removes the code writing the pincfg values. As a gratis bonus, we can remove also the code restoring the original pincfg values at PM resume or module free. This will give us more benefit, as it can reduce the unnecessary power-up of codecs. This won't change the driver functionality. The only difference would be that the codec proc file will show the original pincfg values instead of the actually referred values. The actually referred values can be determined from sysfs *_pin_configs files. (Also hda-emu was updated to follow this change.) Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- David, this change may hit your QA test. As mentioned, the only difference is the default pincfg outputs in proc files. sound/pci/hda/hda_codec.c | 45 +++------------------------------------------ 1 file changed, 3 insertions(+), 42 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index d9fd439..c8f6c3b 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -991,19 +991,6 @@ static struct hda_pincfg *look_up_pincfg(struct hda_codec *codec, return NULL; } -/* write a config value for the given NID */ -static void set_pincfg(struct hda_codec *codec, hda_nid_t nid, - unsigned int cfg) -{ - int i; - for (i = 0; i < 4; i++) { - snd_hda_codec_write(codec, nid, 0, - AC_VERB_SET_CONFIG_DEFAULT_BYTES_0 + i, - cfg & 0xff); - cfg >>= 8; - } -} - /* set the current pin config value for the given NID. * the value is cached, and read via snd_hda_codec_get_pincfg() */ @@ -1011,12 +998,10 @@ int snd_hda_add_pincfg(struct hda_codec *codec, struct snd_array *list, hda_nid_t nid, unsigned int cfg) { struct hda_pincfg *pin; - unsigned int oldcfg; if (get_wcaps_type(get_wcaps(codec, nid)) != AC_WID_PIN) return -EINVAL; - oldcfg = snd_hda_codec_get_pincfg(codec, nid); pin = look_up_pincfg(codec, list, nid); if (!pin) { pin = snd_array_new(list); @@ -1025,13 +1010,6 @@ int snd_hda_add_pincfg(struct hda_codec *codec, struct snd_array *list, pin->nid = nid; } pin->cfg = cfg; - - /* change only when needed; e.g. if the pincfg is already present - * in user_pins[], don't write it - */ - cfg = snd_hda_codec_get_pincfg(codec, nid); - if (oldcfg != cfg) - set_pincfg(codec, nid, cfg); return 0; } @@ -1080,17 +1058,6 @@ unsigned int snd_hda_codec_get_pincfg(struct hda_codec *codec, hda_nid_t nid) } EXPORT_SYMBOL_HDA(snd_hda_codec_get_pincfg); -/* restore all current pin configs */ -static void restore_pincfgs(struct hda_codec *codec) -{ - int i; - for (i = 0; i < codec->init_pins.used; i++) { - struct hda_pincfg *pin = snd_array_elem(&codec->init_pins, i); - set_pincfg(codec, pin->nid, - snd_hda_codec_get_pincfg(codec, pin->nid)); - } -} - /** * snd_hda_shutup_pins - Shut up all pins * @codec: the HDA codec @@ -1152,17 +1119,13 @@ static void init_hda_cache(struct hda_cache_rec *cache, unsigned int record_size); static void free_hda_cache(struct hda_cache_rec *cache); -/* restore the initial pin cfgs and release all pincfg lists */ -static void restore_init_pincfgs(struct hda_codec *codec) +/* release all pincfg lists */ +static void free_init_pincfgs(struct hda_codec *codec) { - /* first free driver_pins and user_pins, then call restore_pincfg - * so that only the values in init_pins are restored - */ snd_array_free(&codec->driver_pins); #ifdef CONFIG_SND_HDA_HWDEP snd_array_free(&codec->user_pins); #endif - restore_pincfgs(codec); snd_array_free(&codec->init_pins); } @@ -1205,7 +1168,7 @@ static void snd_hda_codec_free(struct hda_codec *codec) return; cancel_delayed_work_sync(&codec->jackpoll_work); snd_hda_jack_tbl_clear(codec); - restore_init_pincfgs(codec); + free_init_pincfgs(codec); #ifdef CONFIG_PM cancel_delayed_work(&codec->power_work); flush_workqueue(codec->bus->workq); @@ -2394,7 +2357,6 @@ int snd_hda_codec_reset(struct hda_codec *codec) init_hda_cache(&codec->cmd_cache, sizeof(struct hda_cache_head)); /* free only driver_pins so that init_pins + user_pins are restored */ snd_array_free(&codec->driver_pins); - restore_pincfgs(codec); snd_array_free(&codec->cvt_setups); snd_array_free(&codec->spdif_out); codec->num_pcms = 0; @@ -3687,7 +3649,6 @@ static void hda_call_codec_resume(struct hda_codec *codec) */ hda_keep_power_on(codec); hda_set_power_state(codec, AC_PWRST_D0); - restore_pincfgs(codec); /* restore all current pin configs */ restore_shutup_pins(codec); hda_exec_init_verbs(codec); if (codec->patch_ops.resume) -- 1.8.0

2 2

[alsa-devel] [PATCH 0/8] Misc cleanups wrt firmware loading
by Takashi Iwai 22 Nov '12

22 Nov '12

Hi, this is a series of clean up patches wrt firmware loading in various driver codes. Most of them are simply to concentrate on the standard f/w loading and drop the obsoleted code, and improvements of f/w caching. Also a few emu1010 fw loading code fixes are included. Takashi

1 8

[alsa-devel] [PATCH 1/2] mfd: wm8994: Store platform data in device
by Mark Brown 22 Nov '12

22 Nov '12

This is better style as platform data is supposed to be discardable after init (though hotplug usually prevents this) and will ease implementation of device tree property bindings. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- Patch 2 which uses this is going to collide with some other ASoC changes - is it OK to merge this one via the ASoC tree as well? drivers/mfd/wm8994-core.c | 35 +++++++++++++++++++---------------- include/linux/mfd/wm8994/core.h | 4 ++++ 2 files changed, 23 insertions(+), 16 deletions(-) diff --git a/drivers/mfd/wm8994-core.c b/drivers/mfd/wm8994-core.c index 5964d6a..7f0c2ba 100644 --- a/drivers/mfd/wm8994-core.c +++ b/drivers/mfd/wm8994-core.c @@ -401,13 +401,19 @@ static const __devinitconst struct reg_default wm1811_reva_patch[] = { */ static __devinit int wm8994_device_init(struct wm8994 *wm8994, int irq) { - struct wm8994_pdata *pdata = wm8994->dev->platform_data; + struct wm8994_pdata *pdata; struct regmap_config *regmap_config; const struct reg_default *regmap_patch = NULL; const char *devname; int ret, i, patch_regs; int pulls = 0; + if (dev_get_platdata(wm8994->dev)) { + pdata = dev_get_platdata(wm8994->dev); + wm8994->pdata = *pdata; + } + pdata = &wm8994->pdata; + dev_set_drvdata(wm8994->dev, wm8994); /* Add the on-chip regulators first for bootstrapping */ @@ -604,24 +610,21 @@ static __devinit int wm8994_device_init(struct wm8994 *wm8994, int irq) } } - if (pdata) { - wm8994->irq_base = pdata->irq_base; - wm8994->gpio_base = pdata->gpio_base; - - /* GPIO configuration is only applied if it's non-zero */ - for (i = 0; i < ARRAY_SIZE(pdata->gpio_defaults); i++) { - if (pdata->gpio_defaults[i]) { - wm8994_set_bits(wm8994, WM8994_GPIO_1 + i, - 0xffff, - pdata->gpio_defaults[i]); - } + wm8994->irq_base = pdata->irq_base; + wm8994->gpio_base = pdata->gpio_base; + + /* GPIO configuration is only applied if it's non-zero */ + for (i = 0; i < ARRAY_SIZE(pdata->gpio_defaults); i++) { + if (pdata->gpio_defaults[i]) { + wm8994_set_bits(wm8994, WM8994_GPIO_1 + i, + 0xffff, pdata->gpio_defaults[i]); } + } - wm8994->ldo_ena_always_driven = pdata->ldo_ena_always_driven; + wm8994->ldo_ena_always_driven = pdata->ldo_ena_always_driven; - if (pdata->spkmode_pu) - pulls |= WM8994_SPKMODE_PU; - } + if (pdata->spkmode_pu) + pulls |= WM8994_SPKMODE_PU; /* Disable unneeded pulls */ wm8994_set_bits(wm8994, WM8994_PULL_CONTROL_2, diff --git a/include/linux/mfd/wm8994/core.h b/include/linux/mfd/wm8994/core.h index 1f17330..ae5c249 100644 --- a/include/linux/mfd/wm8994/core.h +++ b/include/linux/mfd/wm8994/core.h @@ -19,6 +19,8 @@ #include <linux/interrupt.h> #include <linux/regmap.h> +#include <linux/mfd/wm8994/pdata.h> + enum wm8994_type { WM8994 = 0, WM8958 = 1, @@ -55,6 +57,8 @@ struct regulator_bulk_data; struct wm8994 { struct mutex irq_lock; + struct wm8994_pdata pdata; + enum wm8994_type type; int revision; int cust_id; -- 1.7.10.4

1 1