Messages in this thread | | | Date | Fri, 25 Jul 2014 13:34:26 +0200 | From | Boris BREZILLON <> | Subject | Re: [PATCH] ARM: at91: at91sam9x5: sets NPCS0 (PA14) back to GPIO |
| |
On Fri, 25 Jul 2014 12:32:38 +0200 Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
> > > Dne 25.7.2014 v 12:18 Boris BREZILLON napsal(a): > >> / # devmem 0xfffff408 > >> 0xF0E04018 > >> / # devmem 0xfffff418 > >> 0xE0C04000 > >> / # devmem 0xfffff438 > >> 0x00C04000 > >> / # devmem 0xfffff43c > >> 0x13FFD7FB > >> / # devmem 0xfffff458 > >> 0x00000000 > >> / # devmem 0xfffff468 > >> 0xFF223B4E > >> / # devmem 0xfffff470 > >> 0x0F000000 > >> / # devmem 0xfffff474 > >> 0x00000000 > >> / # devmem 0xfffff498 > >> 0xFFFFFFFF > >> > >> I get thought if is possible that in time of probe fm25 (it's first) is not configured PA14 (it 's last)? > > > > Oh, nice catch! > > I think you've found the origin of this bug. > > Indeed each device is instantiated sequentially and thus when the first > > device is probed (CS0) the last one has not requested it's cs_gpio yet > > (and PA14 is still assigned to periph A). > > > > Declaring cs-pins and referencing them in pinctrl-0 solves the issue > > because in this case all CS pins are requested during controller probe. > > > So, what would be the right fix up? I my patch it's not good idea since some other driver can request pin for other > peripheral earlier than spi. In board dts it could be new investigating for someone else who don't know this issue. I > think the best way would be request all cs in early spi init since cs depends on each other and must be all of them in > right state before any communication on bus. They are part of bus, like miso, mosi, clk, not part of chips. Also they > are defined in parent spi node, not in child chip node. > Am I right?
Yes, you can take a look at [1] as an example.
[1]http://lxr.free-electrons.com/source/drivers/spi/spi-efm32.c#L361
-- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |