Currently the registration and free of beep input device was done
manually from the register and the disconnect callbacks of the
assigned codec object. This seems working in most cases, but this may
be a cause of some races at probe. Moreover, due to these manual
calls, the total code became unnecessarily lengthy.
This patch rewrites the beep registration code to follow the standard
sound device object style. This allows us reducing the code, in
addition to avoiding the nested device registration calls.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As suggested by Takashi, move this header file to make it easier
to include from e.g. the Intel Skylake driver in follow-up patches
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As the widget PM may turn off the pins, this might lead to the silent
output for beep when no explicit paths are given. This patch adds
fake output paths for the beep widget so that the output pins are
dynamically powered upon beep on/off.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The beep input device is registered via input_register_device(), but
this is called in snd_hda_attach_beep_device() where the sound devices
aren't registered yet. This leads to the binding to non-existing
object, thus results in failure. And, even if the binding worked
(against the PCI object), it's still racy; the input device appears
before the sound objects.
For fixing this, register the input device properly at dev_register
ops of the codec object it's bound with. Also, call
snd_hda_detach_beep_device() at dev_disconnection so that it's
detached at the right timing. As a bonus, since it's called in the
codec's ops, we can get rid of the further call from the other codec
drivers.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
While playing the digital beep tone, the codec shouldn't be turned
off. This patch adds proper snd_hda_power_up()/down() calls at each
time when the beep is played or off.
Also, this fixes automatically an unnecessary codec power-up at
detaching the beep device when the beep isn't being played.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It's no longer necessary since beep_mode=2 option was dropped.
It can be checked simply via codec->beep != NULL.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The beep_mode=2 option was introduced to make the beep mixer
controlling the beep input allocation/deallocation dynamically, so
that a user can switch between HD-audio codec digital beep and the
system beep only via mixer API. This was necessary because the
keyboard driver took only the first input beep instance at that time.
However, the recent keyboard driver already processes the multiple
input instances, thus there is no point to keep this mode.
Let's remove it.
Acked-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Using static inline functions can reduce compilation messages
and macro misuse.
sound/pci/hda/patch_conexant.c: In function ‘patch_cxt5045’:
sound/pci/hda/patch_conexant.c:1232:3: warning: statement with no effect
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The beep_mode option value was wrongly defined: it must be 0 = off and
1 = on.
Also, evaluate the beep_mode value at snd_hda_attach_beep_device()
properly so that no device is created when beep_mode=0 is given.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The beep_mode parameter for snd-hda-intel module allows to choose among
different digital beep device registation to the input layer.
0 = do not register to the input layer
1 = register to the input layer all time
2 = use "Beep Switch" control exported to user space mixer applications
Also, introduce CONFIG_SND_HDA_INPUT_BEEP_MODE for default value.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The massive register/unregister calls for input device layer might be
overkill. Delay unregister call by one HZ as workaround.
Also, as benefit, beep->enabled variable is changed immediately now
(not from workqueue).
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Original implementation was keeping registered input device for SND_BEEP
and SND_TONE events all time. This patch changes this behaviour:
If digital PC Beep is turned off using universal control switch,
the input device is unregistered.
Explanation: The kd_mksound() send SND_BEEP and SND_TONE only to last
registered device acceping those events. It means that the HDA Intel
audio driver blocks also the internal PC Speaker device (pcspkr.c
driver) even if the HDA Beep is muted. The user can easy disable
all beeps using 'setterm -blength 0' or 'xset b off' command.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The digital beep tone is calculated in two different ways depending
on the codec chip. The standard one is using a divider, and another
one is a linear tone for IDT/STAC codecs. Currently, only the
latter type is used for all codecs, which resulted in a wrong tone
pitch.
This patch adds the calculation of the standard HD-audio type.
Also clean-up the fields in hda_beep struct.
Reference: bko#13162
http://bugzilla.kernel.org/show_bug.cgi?id=13162
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A digital beep generator can be used via input layer.
Signed-off-by: Kusanagi Kouichi <slash@ma.neweb.ne.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The digital beep widget may have no mute control, and always enabling
the beep is ofen pretty annoying, especially on laptops.
This patch adds a mixer control "PC Beep Playback Switch" when there
is no mixer amp mute is found, and controls it on software.
Reference: Novell bnc#444572
https://bugzilla.novell.com/show_bug.cgi?id=444572
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Added digital pc-beep support using linear tone generation for hd-codecs along
with initial support for several IDT codecs.
Signed-off-by: Matthew Ranostay <mranostay@embeddedalley.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
