Hi Luke,
Thank you for replying.
> I tried with the patch applied and what I thought was correct setup
> (in driver):
> 1. without my DSD table additions (in acpi)
> 2. With the CS part added (in acpi)
> 3. 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.
