Hi Luke,
Thank you for replying.
I tried with the patch applied and what I thought was correct setup (in driver):
- without my DSD table additions (in acpi)
- With the CS part added (in acpi)
- With my full DSD table added (in acpi)
all 3 instances failed with:
cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: OTP Boot status 80000000 error: 0 cs35l41-hda: probe of spi1-CSC3551:00-cs35l41-hda.0 failed with error -5
I see that you have some problem on making a working fixup table entry, with your key concern being the three fields you pointed out:
The key thing I am concerned about is how the values for the following are gained:
- .reset_gpio_idx = {0, 0},
- .reset_gpio_flags = {GPIOD_OUT_LOW, GPIOD_OUT_LOW},
- .spkid_gpio_idx = {1, 1},
As I could see you have written an incorrect fixup entry when compared with the ACPI patch you provided:
1. For the .reset_gpio_idx field, from your ACPI patch:
Package () { "reset-gpios", Package () { SPK1, One, Zero, Zero, SPK1, One, Zero, Zero } },
for your machine, the index of the reset GpioIo resource is 1, which means the correct form would be .reset_gpio_idx = {1, 1}. You could find this index by looking for the GpioIo resource descriptor that has a "IoRestrictionOutputOnly" IORestriction argument in your ACPI CSC3551 _CRS method, and I suppose this reset gpio should has the only GpioIo descriptor with this "IoRestrictionOutputOnly" argument. Besides, having taking this into consideration, the error you get is probably due to a incorrect reset.
2. For the value of .reset_gpio_flags, it needs more or less some guessing: it's common for chips to have their reset to be pin active low and this polarity can also be checked by reading the gpio resource buffer with kernel acpica infrastructures. Anyway, I think for most cases, .reset_gpio_flags = {GPIOD_OUT_LOW, GPIOD_OUT_LOW} is good.
3. For the value of .spkid_gpio_idx, by investigating the CSC3551 ACPI _CRS method and the driver code, my shallow thought is that it has 3 pins, with one being the reset pin which we have dealt with, one being the interrupt pin, which usually is declared with "GpioInt" if the pin is connected to PCH GPIO and is considered to be one of the cs35l41's configurable GPIO, and another one configurable GPIO whose function is usually assigned with "VSPK_SWITCH". For the spkid to be honest I still have not figured out how it was designed. I suspect that the spkid gpio is acually a reused funcion of one of the three gpios I mentioned. From the driver implementation, the .spkid_gpio_idx field should be the index of the GpioIo resource descriptor in the _CRS returned buffer. However also from the implementation of the driver, whether this field is configured correctly should not be the major factor affecting if the speakers would work, it only affects the selection of the cs35l41 firmware. Anyway, from your working ACPI patch:
Package () { "spk-id-gpios", Package () { SPK1, 0x02, Zero, Zero, SPK1, 0x02, Zero, Zero } },
you may try setting .spkid_gpio_idx = {2, 2}. If that still does not work you could try setting .spkid_gpio_idx = {-1, -1}, and this would make the driver try to find the "spk-id-gpios" package from the ACPI table. (however even though you did not provide this by patching the ACPI table and it fails to get it, the driver still should not fail.)
Please try to modify the fixup entry as the advice above to see if it works. If still not, feel free to futher reply me, and I think it would be very beneficial for me to help solving your problem if you could post your orignial CSC3551 ACPI table.