On úterý 30. ledna 2018 16:54:09 CET, Mark Brown wrote:
You can't physically design working hardware for a system with this
limitation that doesn't have a free chip select somehow - if the
hardware requires that it controls an internal chip select line then
using a GPIO chip select is going to require that there's some internal
chip select line that's getting controlled so you need one that's not
connected to an actual device that can be used for this purpose.
Hi Mark,
yes, I understand that. Sorry if I confused things by trying to explain why
a modulo-algorithm won't work.
I have an unused CS lane. It's just that the spi-orion driver currently
hardcodes HW CS#0, and that one is not free on my board.
The latest version of my patch [1] finds the first *GPIO* CS number. As you
pointed out, this allocation means that a HW CS signal with the same number
is definitely not connected to any other slave's CS. My patch therefore
drives this "unused" HW CS whenever a GPIO CS is needed. This is similar to
what e.g. spi-sh-msiof.c is doing now.
Should I perhaps improve the patch description? I'm open to all comments
here.
I see that it might be a bit confusing that I also changed spi-orion.c so
that it claims/requests/registers/allocates the GPIO for CS. Without that
patch , spi-orion is different from other SPI masters; I have to manually
create a gpio-hog for my CS GPIO. I'll be happy to rework my changes into
two separate patches.
Also, the spi-orion driver currently hard-codes that each and
every model is
supposed to have exactly eight HW CS pins. That's not true for my SoC
(Marvell Armada 388, the Solidrun Clearfog Base board); the
88F6828 CPU only
has four SPI CS signals.
What my patch does is simply picking the *first* unused CS and going with
that one because that looks like the easiest and also safest option.
I would expect that you want to have this selected by the board designer
(unless there's something convenient like a chip select present in the
controller but not routed out of the IP you can guarantee will never be
used). That will avoid issues if for example the DT is still not
complete.
That's the approach that I used in my first version of this patch [2], but
Geert suggested to follow some other SPI master's code and implement
autodiscovery. I don't really care. Which approach is better from your
point of view?
I understand the preference to specify the "fake" HW CS manually. My board
has a flash at CS#0, and it is marked as disabled in a default DT. But
perhaps that's a special case. Your call, anyway.
With kind regards,
Jan
[1] https://patchwork.kernel.org/patch/10187175/
[2] https://patchwork.kernel.org/patch/10182583/
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
