On Fri, Sep 04, 2015 at 03:32:03PM +0200, Christian Hartmann wrote:
Hi,
2015-09-02 10:13 GMT+02:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
On Tue, Sep 01, 2015 at 11:45:31AM +0200, Christian Hartmann wrote:
hi
2015-08-28 11:50 GMT+02:00 Christian Hartmann cornogle@googlemail.com:
The chip select being wrong could well be the issue, perhaps the Windows driver supports multiple chipselects where as the Linux one doesn't? Do you have access to any datasheets for the SPI on the AP? Alternatively you could try hacking it to use chip select 0 and see if that makes the system work, seems like a long shot but perhaps worth a quick go.
Thanks, Charles
ok, that was a one-shot, in effect nothing changed . I did set the num_chipsselect = 1 (as in vanilla kernels, so its more a revert) and changed the cs value from 1 to 0 (as a testpatch). as soon as the SPI device WM510205:00 is allocated, it tries to add the acpi_resource and in the case of the wrong SPI chip_select with the value 1 from the DSDT ACPI table entry, but here I set it again to 0.
expected : chip id register can be read, but nothing changed. the logs are the same in the end. I saw also that acpi_add_resource tries to add an irq (init with -1), but fails
Not entirely unexpected I guess, but certainly my gut feel here is that this is a problem with the chip selects. I guess really trying to find any available documentation on the AP/SPI and tearing apart the SPI driver are the next steps from here. But afraid I don't really have any great ideas for diving much deeper. I will try to chase the Windows guys here again and see if I can gain any clues from them but I don't really know at what level these things are abstracted in Windows and thus if they can really help us much.
Thanks, Charles