linux_dsm_epyc7002/include/sound/intel-nhlt.h

156 lines
2.8 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0-only */
/*
* intel-nhlt.h - Intel HDA Platform NHLT header
*
* Copyright (c) 2015-2019 Intel Corporation
*/
#ifndef __INTEL_NHLT_H__
#define __INTEL_NHLT_H__
#include <linux/acpi.h>
#if IS_ENABLED(CONFIG_ACPI) && IS_ENABLED(CONFIG_SND_INTEL_NHLT)
struct wav_fmt {
u16 fmt_tag;
u16 channels;
u32 samples_per_sec;
u32 avg_bytes_per_sec;
u16 block_align;
u16 bits_per_sample;
u16 cb_size;
} __packed;
struct wav_fmt_ext {
struct wav_fmt fmt;
union samples {
u16 valid_bits_per_sample;
u16 samples_per_block;
u16 reserved;
} sample;
u32 channel_mask;
u8 sub_fmt[16];
} __packed;
enum nhlt_link_type {
NHLT_LINK_HDA = 0,
NHLT_LINK_DSP = 1,
NHLT_LINK_DMIC = 2,
NHLT_LINK_SSP = 3,
NHLT_LINK_INVALID
};
enum nhlt_device_type {
NHLT_DEVICE_BT = 0,
NHLT_DEVICE_DMIC = 1,
NHLT_DEVICE_I2S = 4,
NHLT_DEVICE_INVALID
};
struct nhlt_specific_cfg {
u32 size;
ALSA: Replace zero-length array with flexible-array The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200507192223.GA16335@embeddedor Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-05-08 02:22:23 +07:00
u8 caps[];
} __packed;
struct nhlt_fmt_cfg {
struct wav_fmt_ext fmt_ext;
struct nhlt_specific_cfg config;
} __packed;
struct nhlt_fmt {
u8 fmt_count;
ALSA: Replace zero-length array with flexible-array The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200507192223.GA16335@embeddedor Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-05-08 02:22:23 +07:00
struct nhlt_fmt_cfg fmt_config[];
} __packed;
struct nhlt_endpoint {
u32 length;
u8 linktype;
u8 instance_id;
u16 vendor_id;
u16 device_id;
u16 revision_id;
u32 subsystem_id;
u8 device_type;
u8 direction;
u8 virtual_bus_id;
struct nhlt_specific_cfg config;
} __packed;
struct nhlt_acpi_table {
struct acpi_table_header header;
u8 endpoint_count;
ALSA: Replace zero-length array with flexible-array The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200507192223.GA16335@embeddedor Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-05-08 02:22:23 +07:00
struct nhlt_endpoint desc[];
} __packed;
struct nhlt_resource_desc {
u32 extra;
u16 flags;
u64 addr_spc_gra;
u64 min_addr;
u64 max_addr;
u64 addr_trans_offset;
u64 length;
} __packed;
#define MIC_ARRAY_2CH 2
#define MIC_ARRAY_4CH 4
struct nhlt_device_specific_config {
u8 virtual_slot;
u8 config_type;
} __packed;
struct nhlt_dmic_array_config {
struct nhlt_device_specific_config device_config;
u8 array_type;
} __packed;
struct nhlt_vendor_dmic_array_config {
struct nhlt_dmic_array_config dmic_config;
u8 nb_mics;
/* TODO add vendor mic config */
} __packed;
ALSA: hda: intel-nhlt: verify config type [ Upstream commit a864e8f159b13babf552aff14a5fbe11abc017e4 ] Multiple bug reports report issues with the SOF and SST drivers when dealing with single microphone cases. We currently read the DMIC array information unconditionally but we don't check that the configuration type is actually a mic array. When the DMIC link does not rely on a mic array configuration, the recommendation is to check the format information to infer the maximum number of channels, and map this to the number of microphones. This leaves a potential for a mismatch between actual microphones available in hardware and what the ACPI table contains, but we have no other source of information. Note that single microphone configurations can alternatively be handled with a 'mic array' configuration along with a 'vendor-defined' geometry. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201251 BugLink: https://github.com/thesofproject/linux/issues/2725 Fixes: 7a33ea70e1868 ('ALSA: hda: intel-nhlt: handle NHLT VENDOR_DEFINED DMIC geometry') Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20210302000146.1177770-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-02 07:01:46 +07:00
enum {
NHLT_CONFIG_TYPE_GENERIC = 0,
NHLT_CONFIG_TYPE_MIC_ARRAY = 1
};
enum {
NHLT_MIC_ARRAY_2CH_SMALL = 0xa,
NHLT_MIC_ARRAY_2CH_BIG = 0xb,
NHLT_MIC_ARRAY_4CH_1ST_GEOM = 0xc,
NHLT_MIC_ARRAY_4CH_L_SHAPED = 0xd,
NHLT_MIC_ARRAY_4CH_2ND_GEOM = 0xe,
NHLT_MIC_ARRAY_VENDOR_DEFINED = 0xf,
};
struct nhlt_acpi_table *intel_nhlt_init(struct device *dev);
void intel_nhlt_free(struct nhlt_acpi_table *addr);
int intel_nhlt_get_dmic_geo(struct device *dev, struct nhlt_acpi_table *nhlt);
#else
struct nhlt_acpi_table;
static inline struct nhlt_acpi_table *intel_nhlt_init(struct device *dev)
{
return NULL;
}
static inline void intel_nhlt_free(struct nhlt_acpi_table *addr)
{
}
static inline int intel_nhlt_get_dmic_geo(struct device *dev,
struct nhlt_acpi_table *nhlt)
{
return 0;
}
#endif
#endif