Created attachment 232181 [details] DSDT (decompiled) Device: Intel Atom x5-z8300 based laptop. All details and logs are attached. Problem started as: intel_sst_acpi 808622A8:00: No matching machine driver found After going through the code, i found that the problem is with From file sound/soc/intel/common/sst-match-acpi.c: struct sst_acpi_mach *sst_acpi_find_machine(struct sst_acpi_mach *machines) { struct sst_acpi_mach *mach; bool found = false; for (mach = machines; mach->id[0]; mach++) { if (ACPI_SUCCESS(acpi_get_devices(mach->id, sst_acpi_mach_match, &found, NULL)) && found) return mach; } return NULL; } Observation: acpi_get_devices() is always reporting FAILURE status. But the device is available on the HID. I bypassed the function by disregarding the function return and the device starts to initialize only to be later tripped by const char *sst_acpi_find_name_from_hid(const u8 hid[ACPI_ID_LEN]) { const char *name = NULL; acpi_status status; status = acpi_get_devices(hid, sst_acpi_find_name, NULL, (void **)&name); if (ACPI_FAILURE(status) || name[0] == '\0') return NULL; return name; } Again acpi_get_devices() reports FAILURE status. At this point I'm stuck as to why this is happening. From file drivers/acpi/acpia/nsxfeval.c acpi_status acpi_get_devices(const char *HID, acpi_walk_callback user_function, void *context, void **return_value) { acpi_status status; struct acpi_get_devices_info info; ACPI_FUNCTION_TRACE(acpi_get_devices); /* Parameter validation */ if (!user_function) { return_ACPI_STATUS(AE_BAD_PARAMETER); } /* * We're going to call their callback from OUR callback, so we need * to know what it is, and their context parameter. */ info.hid = HID; info.context = context; info.user_function = user_function; /* * Lock the namespace around the walk. * The namespace will be unlocked/locked around each call * to the user function - since this function * must be allowed to make Acpi calls itself. */ status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE); if (ACPI_FAILURE(status)) { return_ACPI_STATUS(status); } status = acpi_ns_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, ACPI_UINT32_MAX, ACPI_NS_WALK_UNLOCK, acpi_ns_get_device_callback, NULL, &info, return_value); (void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE); return_ACPI_STATUS(status); } Could the tripping be because of the mutex ACPI_MTX_NAMESPACE not being acquired? Don't know if this is of any relavance, I've attached DMESG in which it could be seen that there was a PUNIT semaphore timeout and bus ownership couldn't be acquired. I don't know how to proceed. Could someone assist?
Created attachment 232191 [details] LSHW
Created attachment 232201 [details] DSDT (decompiled)
Created attachment 232211 [details] DMESG
Created attachment 232221 [details] DSDT (decompiled)
Created attachment 232231 [details] FACP (decompiled)
please attach the output of "grep . /sys/bus/acpi/devices/*/*"
ACPI_NS_WALK_UNLOCK is correct here. The facility is: lock mutex for_each_namespace_node { unlock mutex invoke callback lock mutex ] unlock mutex So that any locks can be held in callback. Due to namespace node won't be deleted after loading the table, this is safe for now. For the reported issue, I haven't looked into the details. The returning value might be a problem of the walk_namespace status. The walk_namespace may return some special non AE_OK value indicating termination of the walk. Which may erroneously have been handled as failure.
Created attachment 232311 [details] acpi_devs (In reply to Zhang Rui from comment #6) > please attach the output of "grep . /sys/bus/acpi/devices/*/*" Here
(In reply to Lv Zheng from comment #7) > ACPI_NS_WALK_UNLOCK is correct here. > The facility is: > lock mutex > for_each_namespace_node { > unlock mutex > invoke callback > lock mutex > ] > unlock mutex > So that any locks can be held in callback. Due to namespace node won't be > deleted after loading the table, this is safe for now. > > For the reported issue, I haven't looked into the details. > The returning value might be a problem of the walk_namespace status. > The walk_namespace may return some special non AE_OK value indicating > termination of the walk. > Which may erroneously have been handled as failure. I'll try and debug to find the return value.
/sys/bus/acpi/devices/10EC5640:00/adr:0x00000000 /sys/bus/acpi/devices/10EC5640:00/hid:10EC5640 /sys/bus/acpi/devices/10EC5640:00/modalias:acpi:10EC5640:10EC5640: /sys/bus/acpi/devices/10EC5640:00/path:\_SB_.PCI0.I2C2.RTEK /sys/bus/acpi/devices/10EC5640:00/status:0 /sys/bus/acpi/devices/10EC5640:00/uevent:MODALIAS=acpi:10EC5640:10EC5640: /sys/bus/acpi/devices/10EC5640:00/uid:1 /sys/bus/acpi/devices/10EC5645:00/adr:0x00000000 /sys/bus/acpi/devices/10EC5645:00/hid:10EC5645 /sys/bus/acpi/devices/10EC5645:00/modalias:acpi:10EC5645:10EC5645: /sys/bus/acpi/devices/10EC5645:00/path:\_SB_.PCI0.I2C2.RTK2 /sys/bus/acpi/devices/10EC5645:00/status:0 /sys/bus/acpi/devices/10EC5645:00/uevent:MODALIAS=acpi:10EC5645:10EC5645: /sys/bus/acpi/devices/10EC5645:00/uid:2 you're trying to bind the Realtek codec in sst_acpi driver, but unfortunately, the devices' _STA returns 0, which mean the device does not exist. And I think this explains why you failed to find the realtek codec.
I don't know what the rootcause is, but it does not seem to be an ACPI problem to me. CC the snd expert. :)
(In reply to Zhang Rui from comment #10) > /sys/bus/acpi/devices/10EC5640:00/adr:0x00000000 > /sys/bus/acpi/devices/10EC5640:00/hid:10EC5640 > /sys/bus/acpi/devices/10EC5640:00/modalias:acpi:10EC5640:10EC5640: > /sys/bus/acpi/devices/10EC5640:00/path:\_SB_.PCI0.I2C2.RTEK > /sys/bus/acpi/devices/10EC5640:00/status:0 > /sys/bus/acpi/devices/10EC5640:00/uevent:MODALIAS=acpi:10EC5640:10EC5640: > /sys/bus/acpi/devices/10EC5640:00/uid:1 > /sys/bus/acpi/devices/10EC5645:00/adr:0x00000000 > /sys/bus/acpi/devices/10EC5645:00/hid:10EC5645 > /sys/bus/acpi/devices/10EC5645:00/modalias:acpi:10EC5645:10EC5645: > /sys/bus/acpi/devices/10EC5645:00/path:\_SB_.PCI0.I2C2.RTK2 > /sys/bus/acpi/devices/10EC5645:00/status:0 > /sys/bus/acpi/devices/10EC5645:00/uevent:MODALIAS=acpi:10EC5645:10EC5645: > /sys/bus/acpi/devices/10EC5645:00/uid:2 > > you're trying to bind the Realtek codec in sst_acpi driver, but > unfortunately, the devices' _STA returns 0, which mean the device does not > exist. > > And I think this explains why you failed to find the realtek codec. I've examined the code. The driver is tripping long before the selection of audio codec. It first has to identify which chipset the device is> It is failing at that very stage. It's failing at the stage where it is requesting the device details from the acpi tables. As the above mentioned function always reports failure, it is failing to bind SND_INTEL_SST_ACPI itself. If it does that, then somes the stage where it has to select codec. hid:10EC5640 is codec but now the problem is with hid:808622A8
(In reply to Zhang Rui from comment #11) > I don't know what the rootcause is, but it does not seem to be an ACPI > problem to me. > > CC the snd expert. :) Actually, the snd driver is fine. It simply is not getting the device info from acpi tables when it probe for said device. As I said earlier, the function always reports failure.
I'll check with what status acpi_get_devices() is failing. Perhaps we could know more from that.
I've checked the return status of the function. acpi_status = AE_OK But the user callback function is not being invoked by acpi_get_devices(). Hence the context or the return value are not being set by the callback function. The user callback function is as follows: static acpi_status sst_acpi_mach_match(acpi_handle handle, u32 level, void *context, void **ret) { unsigned long long sta; acpi_status status; *(bool *)context = true; status = acpi_evaluate_integer(handle, "_STA", NULL, &sta); if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_PRESENT)) { *(bool *)context = false; } return AE_OK; } It is not being invoked by acpi_get_devices(). The acpi_get_devices() function is mentioned in the #Description. The following is a snippet from it. * We're going to call their callback from OUR callback, so we need * to know what it is, and their context parameter. */ info.hid = HID; info.context = context; info.user_function = user_function; /* * Lock the namespace around the walk. * The namespace will be unlocked/locked around each call * to the user function - since this function * must be allowed to make Acpi calls itself. */ status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE); if (ACPI_FAILURE(status)) { return_ACPI_STATUS(status); } status = acpi_ns_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, ACPI_UINT32_MAX, ACPI_NS_WALK_UNLOCK, acpi_ns_get_device_callback, NULL, &info, return_value); (void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE); return_ACPI_STATUS(status); The status being returned by acpi_status is AE_OK but 'acpi_ns_get_device_callback' is supposed to call user callback function which is 'info.user_function'. But it simply isn't. The 'return_value' is NULL, '&info' isn't being touched. Could 'acpi_status' = AE_OK just be an anomaly? Any analysis please?
(In reply to tagorereddy from comment #15) > I've checked the return status of the function. > > acpi_status = AE_OK > which function? > But the user callback function is not being invoked by acpi_get_devices(). how do you know? have you add some debug info in the user callback function? > Hence the context or the return value are not being set by the callback > function. > > The user callback function is as follows: > > static acpi_status sst_acpi_mach_match(acpi_handle handle, u32 level, > void *context, void **ret) > { > unsigned long long sta; > acpi_status status; > > *(bool *)context = true; > status = acpi_evaluate_integer(handle, "_STA", NULL, &sta); > > if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_PRESENT)) > { > *(bool *)context = false; > } > return AE_OK; > } > > It is not being invoked by acpi_get_devices(). > > The acpi_get_devices() function is mentioned in the #Description. > The following is a snippet from it. > > > * We're going to call their callback from OUR callback, so we need > * to know what it is, and their context parameter. > */ > info.hid = HID; > info.context = context; > info.user_function = user_function; > > /* > * Lock the namespace around the walk. > * The namespace will be unlocked/locked around each call > * to the user function - since this function > * must be allowed to make Acpi calls itself. > */ > status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE); > if (ACPI_FAILURE(status)) { > return_ACPI_STATUS(status); > } > > status = acpi_ns_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, > ACPI_UINT32_MAX, > ACPI_NS_WALK_UNLOCK, > acpi_ns_get_device_callback, NULL, > &info, return_value); > > (void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE); > return_ACPI_STATUS(status); > > > The status being returned by acpi_status is AE_OK but > 'acpi_ns_get_device_callback' is supposed to call user callback function > which is 'info.user_function'. But it simply isn't. The 'return_value' is > NULL, '&info' isn't being touched. Could 'acpi_status' = AE_OK just be an > anomaly? acpi_status = AE_OK is right, because it successfully walked all the acpi namespace. In acpi_ns_get_device_callback(), please check where it returns,
btw, please attach the output of "grep . /sys/bus/acpi/devices/*/*"
(In reply to Zhang Rui from comment #17) > btw, please attach the output of "grep . /sys/bus/acpi/devices/*/*" I did. Please refer to Commment #8
(In reply to Zhang Rui from comment #16) > acpi_status = AE_OK is right, because it successfully walked all the acpi > namespace. > > In acpi_ns_get_device_callback(), please check where it returns, I'm on it. I'm starting from acpi_ns_walk_namespace(). There's fair chance that the acpi_ns_get_device_callback() isn't being invoked at all.
Created attachment 232491 [details] debug patch IMO, you should use something like the debug patch attached. I didn't test the patch, but the general idea is to check if acpi_ns_get_device_callback is invoked, and if yes, if it returns abnormally.
(In reply to Zhang Rui from comment #20) > Created attachment 232491 [details] > debug patch > > IMO, you should use something like the debug patch attached. > I didn't test the patch, but the general idea is to check if > acpi_ns_get_device_callback is invoked, and if yes, if it returns abnormally. I'll test it
Has the function been invoked in parallel with other namespace modification functionalities?
The function is designed to be invoked in boot stage, and propobably coulnd't be invoked in a multi-threading environment. In order to enable it for multi-threading environment, there are 2 possible solutions: 1. snapshot walked nodes, here is the code proven to be working: https://sourceforge.net/p/sdfirm/code/ci/master/tree/kernel/acpi/acpi_space.c 2. ensure walke is done seriallly with any other walks and namespace modifications (probably cannot be achieved due to the parallel requirement). I'm not sure if your case is related to this known issue. Thanks and best regards Lv
The kernel I was testing on was not Debug enabled. But I built the patched ACPICA core driver with Debug enabled. But It would output nothing on dmesg. I tried printk(), ACPI_DEBUG_PRINT() but no use. But somehow unpatched kernel's debug is being logged. Its as if the ACPICA module I replaced have no effect. So, I had to go with trace_debug with all acpi debug flags set and it helped. I found that every function is being called as it is supposed to be. The system walks through ACPI tables perfectly normally until the following happens: LPEA: _HID=808622A8 is the Audio Controller. RTK2: _HID=10EC5645 is the Audio Codec device. System finds RTK2 and walks to ACPI_DEPTH \_SB.PCI0.I2C2.RTK2._STA and starts to execute _STA as referenced in drivers/acpi/acpia/nsxfeval.c The normal expected condition is _STA execution runs fine and returns AE_OK and the object of the ACPI_TYPE. But here I get NULL return object. The reason is drivers/acpi/acpia/uteval.c finds that the return_object->common.type is (acpi_gbl_enable_interpreter_slack) && (!expected_return_btypes) So it simply deletes the return_object and returns AE_OK. The code for it as follows: #include <acpi/acpi.h> #include "accommon.h" #include "acnamesp.h" #define _COMPONENT ACPI_UTILITIES ACPI_MODULE_NAME("uteval") /******************************************************************************* * * FUNCTION: acpi_ut_evaluate_object * * PARAMETERS: prefix_node - Starting node * path - Path to object from starting node * expected_return_types - Bitmap of allowed return types * return_desc - Where a return value is stored * * RETURN: Status * * DESCRIPTION: Evaluates a namespace object and verifies the type of the * return object. Common code that simplifies accessing objects * that have required return objects of fixed types. * * NOTE: Internal function, no parameter validation * ******************************************************************************/ acpi_status acpi_ut_evaluate_object(struct acpi_namespace_node *prefix_node, const char *path, u32 expected_return_btypes, union acpi_operand_object **return_desc) { struct acpi_evaluate_info *info; acpi_status status; u32 return_btype; ACPI_FUNCTION_TRACE(ut_evaluate_object); /* Allocate the evaluation information block */ info = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_evaluate_info)); if (!info) { return_ACPI_STATUS(AE_NO_MEMORY); } info->prefix_node = prefix_node; info->relative_pathname = path; /* Evaluate the object/method */ status = acpi_ns_evaluate(info); if (ACPI_FAILURE(status)) { if (status == AE_NOT_FOUND) { ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "[%4.4s.%s] was not found\n", acpi_ut_get_node_name(prefix_node), path)); } else { ACPI_ERROR_METHOD("Method execution failed", prefix_node, path, status); } goto cleanup; } /* Did we get a return object? */ if (!info->return_object) { if (expected_return_btypes) { ACPI_ERROR_METHOD("No object was returned from", prefix_node, path, AE_NOT_EXIST); status = AE_NOT_EXIST; } goto cleanup; } /* Map the return object type to the bitmapped type */ switch ((info->return_object)->common.type) { case ACPI_TYPE_INTEGER: return_btype = ACPI_BTYPE_INTEGER; break; case ACPI_TYPE_BUFFER: return_btype = ACPI_BTYPE_BUFFER; break; case ACPI_TYPE_STRING: return_btype = ACPI_BTYPE_STRING; break; case ACPI_TYPE_PACKAGE: return_btype = ACPI_BTYPE_PACKAGE; break; default: return_btype = 0; break; } if ((acpi_gbl_enable_interpreter_slack) && (!expected_return_btypes)) { /* * We received a return object, but one was not expected. This can * happen frequently if the "implicit return" feature is enabled. * Just delete the return object and return AE_OK. */ acpi_ut_remove_reference(info->return_object); goto cleanup; } /* Is the return object one of the expected types? */ if (!(expected_return_btypes & return_btype)) { ACPI_ERROR_METHOD("Return object type is incorrect", prefix_node, path, AE_TYPE); ACPI_ERROR((AE_INFO, "Type returned from %s was incorrect: %s, expected Btypes: 0x%X", path, acpi_ut_get_object_type_name(info->return_object), expected_return_btypes)); /* On error exit, we must delete the return object */ acpi_ut_remove_reference(info->return_object); status = AE_TYPE; goto cleanup; } /* Object type is OK, return it */ *return_desc = info->return_object; cleanup: ACPI_FREE(info); return_ACPI_STATUS(status); } /******************************************************************************* * * FUNCTION: acpi_ut_evaluate_numeric_object * * PARAMETERS: object_name - Object name to be evaluated * device_node - Node for the device * value - Where the value is returned * * RETURN: Status * * DESCRIPTION: Evaluates a numeric namespace object for a selected device * and stores result in *Value. * * NOTE: Internal function, no parameter validation * ******************************************************************************/ acpi_status acpi_ut_evaluate_numeric_object(const char *object_name, struct acpi_namespace_node *device_node, u64 *value) { union acpi_operand_object *obj_desc; acpi_status status; ACPI_FUNCTION_TRACE(ut_evaluate_numeric_object); status = acpi_ut_evaluate_object(device_node, object_name, ACPI_BTYPE_INTEGER, &obj_desc); if (ACPI_FAILURE(status)) { return_ACPI_STATUS(status); } /* Get the returned Integer */ *value = obj_desc->integer.value; /* On exit, we must delete the return object */ acpi_ut_remove_reference(obj_desc); return_ACPI_STATUS(status); } /******************************************************************************* * * FUNCTION: acpi_ut_execute_STA * * PARAMETERS: device_node - Node for the device * flags - Where the status flags are returned * * RETURN: Status * * DESCRIPTION: Executes _STA for selected device and stores results in * *Flags. If _STA does not exist, then the device is assumed * to be present/functional/enabled (as per the ACPI spec). * * NOTE: Internal function, no parameter validation * ******************************************************************************/ acpi_status acpi_ut_execute_STA(struct acpi_namespace_node *device_node, u32 * flags) { union acpi_operand_object *obj_desc; acpi_status status; ACPI_FUNCTION_TRACE(ut_execute_STA); status = acpi_ut_evaluate_object(device_node, METHOD_NAME__STA, ACPI_BTYPE_INTEGER, &obj_desc); if (ACPI_FAILURE(status)) { if (AE_NOT_FOUND == status) { /* * if _STA does not exist, then (as per the ACPI specification), * the returned flags will indicate that the device is present, * functional, and enabled. */ ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "_STA on %4.4s was not found, assuming device is present\n", acpi_ut_get_node_name(device_node))); *flags = ACPI_UINT32_MAX; status = AE_OK; } return_ACPI_STATUS(status); } /* Extract the status flags */ *flags = (u32) obj_desc->integer.value; /* On exit, we must delete the return object */ acpi_ut_remove_reference(obj_desc); return_ACPI_STATUS(status); } /******************************************************************************* * * FUNCTION: acpi_ut_execute_power_methods * * PARAMETERS: device_node - Node for the device * method_names - Array of power method names * method_count - Number of methods to execute * out_values - Where the power method values are returned * * RETURN: Status, out_values * * DESCRIPTION: Executes the specified power methods for the device and returns * the result(s). * * NOTE: Internal function, no parameter validation * ******************************************************************************/ acpi_status acpi_ut_execute_power_methods(struct acpi_namespace_node *device_node, const char **method_names, u8 method_count, u8 *out_values) { union acpi_operand_object *obj_desc; acpi_status status; acpi_status final_status = AE_NOT_FOUND; u32 i; ACPI_FUNCTION_TRACE(ut_execute_power_methods); for (i = 0; i < method_count; i++) { /* * Execute the power method (_sx_d or _sx_w). The only allowable * return type is an Integer. */ status = acpi_ut_evaluate_object(device_node, ACPI_CAST_PTR(char, method_names[i]), ACPI_BTYPE_INTEGER, &obj_desc); if (ACPI_SUCCESS(status)) { out_values[i] = (u8)obj_desc->integer.value; /* Delete the return object */ acpi_ut_remove_reference(obj_desc); final_status = AE_OK; /* At least one value is valid */ continue; } out_values[i] = ACPI_UINT8_MAX; if (status == AE_NOT_FOUND) { continue; /* Ignore if not found */ } ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "Failed %s on Device %4.4s, %s\n", ACPI_CAST_PTR(char, method_names[i]), acpi_ut_get_node_name(device_node), acpi_format_exception(status))); } return_ACPI_STATUS(final_status); } The return value is passed to _STA execution. Could there be problem with the BIOS acpi tables in bios?
My apologies for including other functions from uteval.c. The only one of significance here is acpi_ut_evaluate_object() at the top.
According to your description, I have one thing uncleared. Let me ask a simple question. Do you mean the following code path? acpi_get_devices acpi_ns_get_device_callback acpi_ut_execute_STA acpi_ut_evaluate_object(ACPI_BTYPE_INTEGER) And the following code causes problems: if ((acpi_gbl_enable_interpreter_slack) && (!expected_return_btypes)) { acpi_ut_remove_reference(info->return_object); goto cleanup; } 1. acpi_gbl_enable_interpreter_slack is true for Linux x86 architecture, false for other architectures，and 2. expected_return_btypes is ACPI_BTYPE_INTEGER here. How can the condition be true to cause acpi_ut_remove_referece() invoked?
I think it may simply just because _STA returns "not present" or "not functioning". You need to check your BIOS configuration to enable some settings (for example, ACPI enumeration).
(In reply to Lv Zheng from comment #26) > According to your description, I have one thing uncleared. > Let me ask a simple question. > > Do you mean the following code path? > acpi_get_devices > acpi_ns_get_device_callback > acpi_ut_execute_STA > acpi_ut_evaluate_object(ACPI_BTYPE_INTEGER) > > And the following code causes problems: > if ((acpi_gbl_enable_interpreter_slack) && (!expected_return_btypes)) { > acpi_ut_remove_reference(info->return_object); > goto cleanup; > } > > 1. acpi_gbl_enable_interpreter_slack is true for Linux x86 architecture, > false for other architectures，and > 2. expected_return_btypes is ACPI_BTYPE_INTEGER here. > How can the condition be true to cause acpi_ut_remove_referece() invoked? Good question. tagorereddy, My understanding of the problem is that the rootcause is that REK2._STA returns 0, and this causes 808022a8 fails to find matching machine driver. But you are still insisting that evaluating RTK2._STA fails/breaks in ACPICA, right? TBH, I really don't know how this would happen.
(In reply to Lv Zheng from comment #26) > According to your description, I have one thing uncleared. > Let me ask a simple question. > > Do you mean the following code path? > acpi_get_devices > acpi_ns_get_device_callback > acpi_ut_execute_STA > acpi_ut_evaluate_object(ACPI_BTYPE_INTEGER) > > 1. acpi_gbl_enable_interpreter_slack is true for Linux x86 architecture, > false for other architectures，and > 2. expected_return_btypes is ACPI_BTYPE_INTEGER here. > How can the condition be true to cause acpi_ut_remove_referece() invoked? You are right about code execution path. I think the return_btype ia simply being set to default value of zero. Which is causing the condition to be true.
I've checked DSDT again, and fair few report Address as zero. Is that normal?
(In reply to Lv Zheng from comment #27) > I think it may simply just because _STA returns "not present" or "not > functioning". > You need to check your BIOS configuration to enable some settings (for > example, ACPI enumeration). I'm sure the BIOS settings are fine. Windows installatiom detects every address and runs smoothly. But these BIOS settings sure are complicated. Every device on \SB can be set to run in ACPI mode or PCI mode. Right now its set to default ACPI mode. I also think there may be an issue with I2C bus. As I mentioned in the begining, there's a PUNiT semaphore timeout and failure to acquire bus ownership. That may be why most of the devices on I2C bus aren't funtioning. The bus isn't being shared. I'll more into it.
Thanks gentlemen for for assistance. You've very helpful. The issue looks more complicated than initially thought. i'll report of new developments.
Hi, _STA of RTK2 is: Method (_STA, 0, NotSerialized) // _STA: Status { If ((BDID == One)) { Return (Zero) } If ((OSID == 0x04)) { Return (Zero) } If ((AUCD == One)) { Return (0x0F) } Return (Zero) } The only case to make it returning 0x0F is AUCD is One. AUCD is an BIOS configuration item: OperationRegion (GNVS, SystemMemory, 0x732DA000, 0x036C) Field (GNVS, AnyAcc, Lock, Preserve) { ... AUCD, 8, ... } It's from NVRAM. I really think you need to check your BIOS settings. As there is no one in DSDT modifying AUCD. There is another device RTEK， which has opposite _STA returning value condition than RTK2: Method (_STA, 0, NotSerialized) // _STA: Status { If ((BDID == One)) { Return (Zero) } If ((OSID != One)) { Return (Zero) } If ((OSID == 0x04)) { Return (Zero) } If ((AUCD == Zero)) { Return (0x0F) } Return (Zero) } I think on your platform, this device should have been working. This makes me start to wonder: [ 26.754198] intel_sst_acpi 808622A8:00: No matching machine driver found How can this log occur? Why ACPI driver core was trying to match a driver for RTK2? Was the BIOS trying to modify AUCD during runtime in order to confuse OSPM? Thanks Lv
According to the ACPI device scanning result: /sys/bus/acpi/devices/10EC5640:00/path:\_SB_.PCI0.I2C2.RTEK /sys/bus/acpi/devices/10EC5640:00/status:0 /sys/bus/acpi/devices/10EC5645:00/path:\_SB_.PCI0.I2C2.RTK2 /sys/bus/acpi/devices/10EC5645:00/status:0 _STA for both RTEK and RTK2 devices returned 0. So I guess you need to check BDID, OSID settings. They are all NVRAM variables: OperationRegion (GNVS, SystemMemory, 0x732DA000, 0x036C) Field (GNVS, AnyAcc, Lock, Preserve) { ... OSID, 8, ^^^^ ... BDID, 8, ^^^^ ... AUCD, 8, ^^^^ ... } Please check your board settings. Thanks Lv
Sure, Thanks. I'll get back to you with more details. Since Windows runs perfectly on this device, I'll see how Windows is interpreting ACPI tables.
This becomes more a BIOS problem, or sst driver problem. ACPI is doing everything right. Thus bug reassigned.
(In reply to Zhang Rui from comment #36) > This becomes more a BIOS problem, or sst driver problem. > ACPI is doing everything right. > > Thus bug reassigned. Yes. I agree with you. The BIOS of this device sure is strange. Although Surface Book 3 had similar issues. BIOS reporting wrong data. Thank you Zhang Rui, Lv Zheng for your time.
(In reply to tagorereddy from comment #0) > Created attachment 232181 [details] > DSDT (decompiled) > > Device: Intel Atom x5-z8300 based laptop. > All details and logs are attached. > > Problem started as: > > intel_sst_acpi 808622A8:00: No matching machine driver found This simply means that machine is NOT found. This can be due to a) missing codec entry b) missing machine entry For CHV we have both codec entries but with fixup for Surface3. First can you confirm which codec you have. Looking at discussion looks like both codec entries exist but _STA is returning 0.
(In reply to Vinod Koul from comment #38) > > This simply means that machine is NOT found. This can be due to > a) missing codec entry > b) missing machine entry > > For CHV we have both codec entries but with fixup for Surface3. > > First can you confirm which codec you have. Looking at discussion looks like > both codec entries exist but _STA is returning 0. It looks like it has ESSX Codec Controller.
I am ready to bet it's again the BIOS using the wrong codec: Name (_HID, "10EC5645") // _HID: Hardware ID Name (_CID, "10EC5645") // _CID: Compatible ID Name (_DDN, "ALC5642") // _DDN: DOS Device Name but at the same time the fact that all status is zero is puzzling. If the devices are not present then there is nothing the drivers can do really. Can you look in Windows and let us know which codec is used (along with its HID). This can be done with Device Manager, look in sound/details.
Created attachment 248901 [details] dmesg4.10 Hi, i'm using odys vario pro 12, ive patched some bugs, like the semaphore bug and so on, but this still seems a problem here, because i get the same error in dmesg and have no sound :( Using 4.10-git with patches from https://bugzilla.kernel.org/show_bug.cgi?id=155241 Please help, no sound really sucks :/ I can set PCI/ACPI and 2 different codecs on Bios: 5640 and 5645/5672 actually its default set on acpi with 5640 codec.
(In reply to jahn from comment #41) > Created attachment 248901 [details] > dmesg4.10 > > Hi, > i'm using odys vario pro 12, > ive patched some bugs, like the semaphore bug and so on, > but this still seems a problem here, because i get the same error in dmesg > and have no sound :( > Using 4.10-git with patches from > https://bugzilla.kernel.org/show_bug.cgi?id=155241 > > Please help, no sound really sucks :/ > I can set PCI/ACPI and 2 different codecs on Bios: 5640 and 5645/5672 > actually its default set on acpi with 5640 codec. You need to provide more information if you want to be helped. 0. alsa-info.sh 1. DSDT 2. output of cat /sys/bus/acpi/devices/10EC*/status
Hello,thanks for helping, here is alsainfo: http://www.alsa-project.org/db/?f=70e33979c159a980aa2919c2b859033fccc76400
Created attachment 249071 [details] DSDT_new_410 DSDT/ACPIDUMP
Created attachment 249081 [details] 10EC*
/sys/bus/acpi/devices/10EC5640:00/status /sys/bus/acpi/devices/10EC5640:01/status /sys/bus/acpi/devices/10EC5651:00/status /sys/bus/acpi/devices/10EC5670:00/status 0 0 15 0 -> assuming this is the same order, you have a realtek 5651 in your device and you need to enable the BYTCR_RT5651 Kconfig options. we added this driver last year so it should just work.
Hello, thanks fo helping me :) /proc/config tells me, that the following is configured: CONFIG_SND_SOC_INTEL_BYTCR_RT5651_MACH=m CONFIG_SND_SOC_RT5651=m Which should mean it's enabled ;) i've compiled the kernel and enabled every baytrail/cherrytrail thing i could. But it's simply not just working :( Thank you
Could this be a CherryTrail machine, I see references to 22a8 which is CherryTrail If yes you would need to add the patch below (untested). You would also need additional patches that I was working on my https://github.com/plbossart/sound/commits/experimental/codecs branch to get the MCLK working and get a better sound. There is also a baseline UCM file at https://github.com/plbossart/sound/commits/experimental/codecs. To get full audio support we'd need to get the schematics since there are lots of variations. Let me know what works for you. Happy New Year. diff --git a/sound/soc/intel/atom/sst/sst_acpi.c b/sound/soc/intel/atom/sst/sst_acpi.c index 40f9372..502f5db 100644 --- a/sound/soc/intel/atom/sst/sst_acpi.c +++ b/sound/soc/intel/atom/sst/sst_acpi.c @@ -510,6 +510,9 @@ static struct sst_acpi_mach sst_acpi_chv[] = { /* some CHT-T platforms rely on RT5640, use Baytrail machine driver */ {"10EC5640", "bytcr_rt5640", "intel/fw_sst_22a8.bin", "bytcr_rt5640", cht_quirk, &chv_platform_data }, + /* some CHT-T platforms rely on RT5651, use Baytrail machine driver */ + {"10EC5651", "bytcr_rt5651", "intel/fw_sst_22a8.bin", "bytcr_rt5651", NULL, + {}, };
Created attachment 249361 [details] Dmesg with patch Hey, thanks for this patch ;) I fixed the last + line with adding &chv_platform_data }, and used your branch for testing, fixed some not commented out "&chv_platform_data }," ;) There is some improvements in detecting the soundcard, and the main error is gone, but it's not really working :( Attached you'll find the new dmesg from your branch with this fix and the new errors ;) Hope you can help further :) Thank you, and have a nice new year.
[ 3.414424] bytcr_rt5651 bytcr_rt5651: snd-soc-dummy-dai <-> media-cpu-dai mapping ok [ 3.414496] bytcr_rt5651 bytcr_rt5651: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok [ 3.414542] compress asoc: snd-soc-dummy-dai <-> compress-cpu-dai mapping ok [ 3.414556] bytcr_rt5651 bytcr_rt5651: ASoC: no sink widget found for DMIC1 [ 3.414661] bytcr_rt5651 bytcr_rt5651: ASoC: Failed to add route Internal Mic -> direct -> DMIC1 [ 3.414775] bytcr_rt5651 bytcr_rt5651: ASoC: failed to init SSP2-Codec: -19 [ 3.414864] bytcr_rt5651 bytcr_rt5651: ASoC: failed to instantiate card -19 [ 3.415412] bytcr_rt5651 bytcr_rt5651: devm_snd_soc_register_card failed -19 so the card is detected but the DAPM paths are wrong for the capture. please remove this patch for now, we'll fix it later https://github.com/plbossart/sound/commit/f77618c6ff93ed44d448a2ccd09f61c741788b69
Created attachment 249731 [details] dmesg_with_patch2 Hey, i've removed the patch you mentioned. Here is what i get now: (Ignore the i2c baytrail errors, they are from other patches which won't work that well :/) Tell me how i can help you further :) Thank you for your time looking in this.
Well there's progress but I am not sure why there is a oops here... Can you change this static unsigned long byt_rt5651_quirk = BYT_RT5651_DMIC1_MAP | BYT_RT5651_DMIC_EN | BYT_RT5651_MCLK_EN; to static unsigned long byt_rt5651_quirk = BYT_RT5651_DMIC1_MAP | BYT_RT5651_DMIC_EN; to help us track the issue?
Created attachment 250031 [details] dmesg_with_patch3_debug Hello, so here is the new Kernel with the this change. It also has acpi_debug on and some acpi traces activated for other bug fixing, hope it this won't disturb you ;) Thanks
I am not sure if the traces are errors, it could be that the mixers on capture are not set. I never tested capture on my side so no idea why the issue is. Also was the card created at all or does the codec driver fail silently?
Hello, no card is create as far as i can see. There should be one in /proc/asound/cards if it would work right?
yes and you should also see a log of card registration in dmesg Can you revert to Mark Brown's tree or 4.9 (with your changes on top), something's not right but I can't figure out why. Also make sure you have PINCTRL_CHV set up in your options.
Created attachment 250061 [details] dmesg_with_patch3_debug_new Hi, i just rebooted with same kernel for some tests, and i got a card now(without nothing changed before.. wtf..) Here is the dmesg and alsa-info.sh I tested playing some sound, but this didn't worked, just the card is there ;) http://www.alsa-project.org/db/?f=81435fc5e0f5cb45f12bbf8a101b17ac5b2213c4
the error below is a config issue [ 58.630126] Audio Port: ASoC: no backend DAIs enabled for Audio Port It means you didn't set up the mixer parts. Please use the UCM file at https://github.com/plbossart/UCM/commits/master take the bytcr_rt5651 directory and copy it under /usr/share/alsa/ucm, then restart pulseaudio.
Created attachment 250071 [details] dmesg_ucm Hey, i searched for them before, but didn't find them the above links din't pointed to the right ones^^ So now i copied them to the right directory on my working kernel and startet the patched kernel, i got the attached dmesg :( Maybe i should try a clean version from your branch with the last fixes you posted to reproduce it. The main problems for me are, that all kernels after 4.4 don't work well on this machine, i have regressions with touchpad and touchscreen (see my other bugs) and it does boot only every third time, reproducable, it freezes two times, and the third time it works some times... So what i did this time was booting, getting the dmesg for you, than try playing some sound via aplay which freezed the machine complety.. The last successfull boot before was also with ucm files present i got the same errors as before, then i copyed the asound.state from your ucm directoy to /var/lib/alsa, restarted pulseaudio and the machine freezed immediately, so i couldn't get logs for you.. I will build your branch again just with your latest fixes (without the other ones for i2c_designware and so on) and get you the dmesg, but i doubt this will diff from this one that much.. This will take some time now, because it's my girlfriends device and she needs it for her exames, so i can only do something sometimes.. and she has to use 4.4 kernel because it's the only one which almost works.. (with no sound/network). Thanks for your time and let me know how i can help further to get sound to this nice devices with so many bugs/missing things i've never seen before :D
CherryTrail devices work actually better with newer kernels. There are for examples fixes coming for I2C issues. http://www.spinics.net/lists/linux-i2c/msg27460.html I would recommend you update and use my latest branch plus those I2C patches.
Created attachment 250441 [details] Dmesg Hi, so i've rebuild your branch with the i2c fixes and the patches and things you said here.Just from scratch freshly for you ;) Here are the logs from it, 2 times booted, dmesg, journalctl and alsa-info. First boot was with a buggy network driver, so ignore the errors in dmesg from it, second boot i disabled it for better logs ;) UCM files are applied from your repo as you said, i killed pulseaudio some times in the logs and tried one time to play sound via aplay. Alsamixer shows me a lot things, no idea what to configure there exactly.. All i can here is a loud noise at restarting pulseaudio. Alsa-info here: http://www.alsa-project.org/db/?f=091351005f40a2ab5529c63ace9d52197e1175d2 Thanks for your work :)
If you look at the UCM file, you'll see that I only tested on a headphone output using a rt5651 evaluation board which didn't come with speakers. I would try listing everything related to speakers and try to enable the path and volume, e.g. amixer controls | grep Speaker amixer controls | grep Volume make sure the volumes are set low to avoid blowing your speakers!
Hi, thanks for your help :) I managed to get sound working on headphone and speaker, you can easily switch it in alsamixer. Here is the alsa-info.sh http://www.alsa-project.org/db/?f=bcd644109e78f60b4b8c8500728659ad7eb96947 Sound is working now, but not really good quality,you can hear loud period cracks, which i think won't be that good for the loudspeaker/headphones. I can hear them even when nothing is played and louder and more wehn somtehing is played. I can force hearing them when i change some "Gain 0" things in alsamixer like "codec_0 Gain0" above 30%, 25 seems to be a good balance between cracks and the sound i like to hear :D Dmesg now shows me only the following errors related to sound: [ 3.746570] rt5651 i2c-10EC5651:00: ASoC: mux INL1 Mux has no paths [ 3.749669] rt5651 i2c-10EC5651:00: ASoC: mux INR1 Mux has no paths [ 3.752905] rt5651 i2c-10EC5651:00: ASoC: mux INL2 Mux has no paths [ 3.755326] rt5651 i2c-10EC5651:00: ASoC: mux INR2 Mux has no paths Many thanks for getting it to this state, please tell me how i can help to get it working without this annyoing cracks ;) I'll do what i can and I'm willing to try new patches/ ideas from you ;) Thanks
*** Bug 191421 has been marked as a duplicate of this bug. ***
*** Bug 155271 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 189261 ***