[MinnowBoard] SPI questions
John Hawley
john.hawley at intel.com
Thu Jan 29 22:23:41 UTC 2015
Ok this might be where some confusion is coming into play. That pin is
muxed to GPIO / SPI chip select. When it's set as SPI chip select it
can't be used as a GPIO, and vice versa. To change which function is
setup for the pin you need to jump into the firmware:
http://elinux.org/Minnowboard:MaxBios#LPSS_.26_SCC_Configuration
and change
LPSS SPI Support
(the default is enabled, clearly I need to update that page on the wiki).
When it's enabled physical pins #5, #7, #9, #11 are SPI related. When
disabled they all revert to GPIO.
I'm not sure how to interact with the CS line when it's set as CS, I'd
have to go check with the driver and/or the spi kernel mailing list.
- John
On 1/29/2015 2:09 PM, Kevin Shelton wrote:
> Yeah, pin 5 should be 220 which matches what is in the wiki. Even
> without my module involved (fresh boot into a 3.17) I cannot seem to
> control GPIO 220. I confirmed I was able to manipulate one of the
> other GPIO pins on the low-speed-expansion header. I am using the
> latest (rev 76) fw.
>
> So, with a clean boot (my module nowhere to be found) when I
> root at minnow-fe-37-9a:~# echo 220 > /sys/class/gpio/export
>
> I get:
> [ 608.068793] byt_gpio INT33FC:00: pin 66 cannot be used as GPIO.
>
> has anyone successfully used pin 5 as GPIO with rev 76 fw?
>
> On Thu, Jan 29, 2015 at 1:09 PM, John "Warthog9" Hawley
> <warthog9 at eaglescrag.net> wrote:
>> On January 29, 2015 11:51:33 AM PST, Kevin Shelton <kmshelton at gmail.com> wrote:
>>> Looks like my gpio number was wrong for my 3.17 system. I confirmed
>>> on the datasheet that SIO_SPI_CS# goes to GPIO_S0_SC[66], which should
>>> be the 67th GPIO in the block of 102 GPIOs beginning at 154 on my
>>> system (so that checks out to the 220 on the wiki). However, I run
>>> into:
>>>
>>> [ 143.049918] byt_gpio INT33FC:00: pin 66 cannot be used as GPIO.
>>> [ 143.056556] spi spi0.0: failed to request chip select GPIO220
>>> [ 143.063007] pxa2xx-spi 80860F0E:00: can't setup spi0.0, status -22
>>>
>>> On Thu, Jan 29, 2015 at 2:01 AM, Kevin Shelton <kmshelton at gmail.com>
>>> wrote:
>>>> pin 5 still idling high at 3.3V after the pxa2xx_spi_chip addition
>>>>
>>>> On Thu, Jan 29, 2015 at 1:06 AM, Kevin Shelton <kmshelton at gmail.com>
>>> wrote:
>>>>> added the following to my board file:
>>>>>
>>>>> #include <linux/spi/pxa2xx_spi.h>
>>>>>
>>>>> static struct pxa2xx_spi_chip mbm = {
>>>>> .gpio_cs = 476
>>>>> };
>>>>>
>>>>> as well as
>>>>> .controller_data = &mbm
>>>>> to the spi_board_info struct
>>>>>
>>>>> And now my module no longer returns from cs_setup before getting to
>>>>> the cs polarity logic (at least in ACPI mode, not yet tested in PCI
>>>>> mode). I've also yet to confirm that my SPI device is actually
>>>>> working, but I think this is on the right track.
>>>>>
>>>>> On Wed, Jan 28, 2015 at 11:31 PM, Kevin Shelton
>>> <kmshelton at gmail.com> wrote:
>>>>>> My board file loads, but with a NULL chip_info when I'm in ACPI
>>> mode
>>>>>> for LPSS & SCC Devices Mode (so IIUC, the NULL chip_info prevents
>>>>>> spi-pxa2xx.c from flipping the polarity on the SS line).
>>>>>>
>>>>>> My module will explode when in PCI mode (tried in PCI mode because
>>>>>> spi-pxa2xx.c has a comment "Slave devices enumerated from ACPI
>>>>>> namespace don't usually have chip_info") with:
>>>>>>
>>>>>> [ 559.236046] divide error: 0000 [#1] PREEMPT SMP
>>>>>> [ 559.241217] Modules linked in: low_speed_spidev(O+)
>>>>>> [ 559.246686] CPU: 0 PID: 11980 Comm: insmod Tainted: G
>>> O
>>>>>> 3.17.0-rc4-yocto-standard+ #13
>>>>>> [ 559.256712] Hardware name: Circuitco MinnowBoard MAX B3
>>>>>> PLATFORM/MinnowBoard MAX, BIOS MNW2MAX1.X64.0076.R01.1412081258
>>>>>> 12/08/2014
>>>>>> [ 559.269850] task: ffff880073e5dfc0 ti: ffff880078f30000 task.ti:
>>>>>> ffff880078f30000
>>>>>> [ 559.278222] RIP: 0010:[<ffffffff8148c57d>] [<ffffffff8148c57d>]
>>>>>> ssp_get_clk_div+0x3b/0x4a
>>>>>> [ 559.287481] RSP: 0018:ffff880078f33c80 EFLAGS: 00010246
>>>>>> [ 559.293422] RAX: 0000000000000000 RBX: ffff880073f4b660 RCX:
>>> 000000000000003f
>>>>>> [ 559.301405] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
>>> ffff880073e54428
>>>>>> [ 559.309388] RBP: ffff880078f33c80 R08: 00000000000000df R09:
>>> ffffffff82075580
>>>>>> [ 559.317370] R10: 0000000000000000 R11: 0000000000000000 R12:
>>> ffff880078578400
>>>>>> [ 559.325353] R13: 0000000000000000 R14: ffff880073e54428 R15:
>>> 0000000000002710
>>>>>> [ 559.333338] FS: 00007f8296dcd700(0000)
>>> GS:ffff880079200000(0000)
>>>>>> knlGS:0000000000000000
>>>>>> [ 559.342392] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>>>>> [ 559.348819] CR2: 00007f8296dc9000 CR3: 000000007418b000 CR4:
>>> 00000000001007f0
>>>>>> [ 559.356801] Stack:
>>>>>> [ 559.359046] ffff880078f33cc0 ffffffff8148caa8 000000e000000040
>>>>>> ffff880078578400
>>>>>> [ 559.367334] 0000000000000000 0000000000000000 ffff880073e54000
>>>>>> 0000000000000000
>>>>>> [ 559.375628] ffff880078f33d10 ffffffff814888e6 0000000000000000
>>>>>> ffff880078f33d10
>>>>>> [ 559.383923] Call Trace:
>>>>>> [ 559.386660] [<ffffffff8148caa8>] setup+0x1fb/0x4b8
>>>>>> [ 559.392119] [<ffffffff814888e6>] spi_setup+0xfd/0x1ad
>>>>>> [ 559.397871] [<ffffffff8143b32f>] ? bus_for_each_dev+0x63/0x85
>>>>>> [ 559.404399] [<ffffffff81488aa4>] spi_add_device+0x10e/0x1a6
>>>>>> [ 559.410732] [<ffffffff81489062>] spi_new_device+0xb5/0xcb
>>>>>> [ 559.416874] [<ffffffffa00030bf>]
>>>>>> low_speed_spidev_module_init+0xbf/0x133 [low_speed_spidev]
>>>>>> [ 559.426318] [<ffffffffa0003000>] ? 0xffffffffa0003000
>>>>>> [ 559.432070] [<ffffffff8100032d>] do_one_initcall+0xff/0x185
>>>>>> [ 559.438404] [<ffffffff8110172a>] ? __vunmap+0xa9/0xaf
>>>>>> [ 559.444155] [<ffffffff8108e4fb>] load_module+0x1756/0x1ef0
>>>>>> [ 559.450392] [<ffffffff8108bfd3>] ?
>>> free_modinfo_version+0x27/0x27
>>>>>> [ 559.457311] [<ffffffff8108ed57>] SyS_init_module+0xc2/0xcf
>>>>>> [ 559.463550] [<ffffffff8175fed2>] system_call_fastpath+0x16/0x1b
>>>>>>
>>>>>> I notice the below that sounds a little curious when I'm in PCI
>>> mode
>>>>>> (these are present for other devices, but from looking at
>>>>>> /sys/class/spi_master it seems that pci0000:00/0000:00:1e.5 is the
>>>>>> pxa2xx).
>>>>>>
>>>>>> [ 1.282369] pci 0000:00:1e.5: BAR 0: reserving [mem
>>>>>> 0x9093c000-0x9093cfff flags 0x40200] (d=0, p=0)
>>>>>> [ 1.282377] pci 0000:00:1e.5: can't claim BAR 0 [mem
>>>>>> 0x9093c000-0x9093cfff]: no compatible bridge window
>>>>>> [ 1.292998] pci 0000:00:1e.5: BAR 1: reserving [mem
>>>>>> 0x9093d000-0x9093dfff flags 0x40200] (d=0, p=0)
>>>>>> [ 1.293007] pci 0000:00:1e.5: can't claim BAR 1 [mem
>>>>>> 0x9093d000-0x9093dfff]: no compatible bridge window
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 28, 2015 at 4:19 PM, Kevin Shelton
>>> <kmshelton at gmail.com> wrote:
>>>>>>> through liberal sprinkling of printks I find that when
>>> spi_new_device
>>>>>>> gets called in my board file, eventually setup_cs gets called in
>>>>>>> drivers/spi/spi-pxa2xx.c, but setup_cs returns before it can set
>>>>>>> gpio_cs_inverted because chip_info is NULL
>>>>>>>
>>>>>>> Should board files define a pxa2xx_spi_chip struct (I see this
>>> done in
>>>>>>> arch/arm/mach-pxa/hx4700.c)?
>>>>>>>
>>>>>>> Am I correct in calling hx4700.c a board file?
>>>>>>>
>>>>>>> On Tue, Jan 27, 2015 at 9:21 PM, Darren Hart
>>> <dvhart at linux.intel.com> wrote:
>>>>>>>> This changes the mechanism used to enumerate the hardware device
>>> to the
>>>>>>>> OS. Recent Linux kernels 3.16+ support for ACPI and PCI
>>> enumeration. ACPI
>>>>>>>> is supported since 3.14. Either should work for a board-file.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Darren
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/27/15, 3:13 PM, "Kevin Shelton" <kmshelton at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> sorry for the not clear writing: I meant to say ACPI mode for the
>>>>>>>>> "LPSS & SCC Devices Mode" setting
>>>>>>>>>
>>>>>>>>> On Tue, Jan 27, 2015 at 3:11 PM, Kevin Shelton
>>> <kmshelton at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> I realized that in my BIOS settings, I was in ACPI mode. Do I
>>> need to
>>>>>>>>>> be in PCI mode to use a board file? What does that ACPI-PCI
>>> switch in
>>>>>>>>>> the BIOS do? thanks for all the help
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 26, 2015 at 11:35 PM, Darren Hart
>>> <dvhart at linux.intel.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> The SPI bus controlled by the pxa2xx driver is on the LPSS,
>>> which, yes,
>>>>>>>>>>> corresponds to the Low Power IO Controller in that block
>>> diagram.
>>>>>>>>>>>
>>>>>>>>>>> On 1/26/15, 10:38 PM, "Kevin Shelton" <kmshelton at gmail.com>
>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Thanks John and Darren. I will play with spid_devtest and
>>> have
>>>>>>>>>>>> reached out to linux-spi at vger.kernel.org.
>>>>>>>>>>>>
>>>>>>>>>>>> A minnowmax-specific question: In the Baytrail block diagram
>>> at
>>>>>>>>>>>> http://media.bestofmicro.com/Y/3/400395/original/bay-trail-soc.jpg
>>>>>>>>>>>> does the Marvell pxa27x correspond to the "Low Power IO
>>> Controller"?
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jan 26, 2015 at 6:33 PM, Darren Hart
>>> <dvhart at linux.intel.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On 1/26/15, 5:52 PM, "John Hawley" <john.hawley at intel.com>
>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 01/26/2015 05:47 PM, Kevin Shelton wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Jan 23, 2015 at 2:41 PM, John Hawley
>>> <john.hawley at intel.com
>>>>>>>>>>>>>>> <mailto:john.hawley at intel.com>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > I saw the thread 'Adding an SPI device to the
>>> Minnowboard'
>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>> late
>>>>>>>>>>>>>>> > 2013 and 'SPI support on minnowboard v1' from Aug
>>> 2014.
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > Darren Hart notes:
>>>>>>>>>>>>>>> > Ultimately we want to do things like this without
>>> board
>>>>>>>>>>>>>>> files by
>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>> > the _DSD mechanisms introduced by the ACPI 5.1
>>> specification
>>>>>>>>>>>>>>> last
>>>>>>>>>>>>>>> week
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > I just wanted to confirm the ACPI mechanism is not
>>> the
>>>>>>>>>>>>>>> recommended way
>>>>>>>>>>>>>>> > yet, and that using low-speed-spidev.c as a template
>>> is still
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> way to go.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The answer to that will depend on what kernel you are
>>>>>>>>>>>>>>> intending to
>>>>>>>>>>>>>>> target. Kernel's with ACPI 5.1 _DSD support, I think
>>> you'd
>>>>>>>>>>>>>>> want
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> push
>>>>>>>>>>>>>>> on that. Older kernels without that, likely spidev or
>>> a more
>>>>>>>>>>>>>>> targeted
>>>>>>>>>>>>>>> driver.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Currently, I am targeting 3.17. 3.17 does not have ACPI
>>> 5.1 _DSD
>>>>>>>>>>>>>>> support, correct?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Off the top of my head that came in in 3.18, so yes that's
>>> correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3.19 iirc.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, using _DSD required a firmware change, or at least a
>>> DSDT
>>>>>>>>>>>>> update.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > Additional q:
>>>>>>>>>>>>>>> > How do you tell the SPI controller that you have an
>>>>>>>>>>>>>>> active-high
>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>> > of the usual active-low device? Is it correct to do
>>> a
>>>>>>>>>>>>>>> bitwise
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> > SPI_CS_HIGH (0x4) with your SPI_MODE in your
>>> spi_board_info
>>>>>>>>>>>>>>> struct, like:
>>>>>>>>>>>>>>> > .mode = SPI_MODE_0 | SPI_CS_HIGH
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That should work, but take my statement with a grain
>>> of salt
>>>>>>>>>>>>>>> as I
>>>>>>>>>>>>>>> haven't tried it with a device.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It seems to have no effect that I can discern. Pin 5
>>> idles at 3.3V
>>>>>>>>>>>>>>> whether I have
>>>>>>>>>>>>>>> .mode = SPI_MODE_3 | SPI_CS_HIGH
>>>>>>>>>>>>>>> -or-
>>>>>>>>>>>>>>> .mode = SPI_MODE_3
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I threw in a
>>>>>>>>>>>>>>> pr_info("SPI mode=%i\n", cod_spi_board_info.mode);
>>>>>>>>>>>>>>> to sanity check that I am setting the mode to what I think
>>> I am (3
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>> 7).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any debugging ideas?
>>>>>>>>>>>>>>> What is the best way to learn more about the SPI master?
>>> It's
>>>>>>>>>>>>>>> built
>>>>>>>>>>>>>>> into the CPU, correct?
>>>>>>>>>>>>>>> This smells in the ballpark of
>>>>>>>>>>>>>>> relatedness:
>>>>>>>>>>>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/2634
>>>>>>>>>>>>>>> 67.
>>>>>>>>>>>>>>> ht
>>>>>>>>>>>>>>> ml
>>>>>>>>>>>>>>> I don't grok that patch, but I confirmed my version of
>>> pxa2xx.c in
>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>> 3.17 tree appears to contain that change.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The SPI interface is indeed built into the CPU. It's the
>>> pxa2xx
>>>>>>>>>>>>>> core,
>>>>>>>>>>>>>> which it looks like you've found. I'd have to punt to
>>> someone else,
>>>>>>>>>>>>>> as
>>>>>>>>>>>>>> I'll admit, I don't know the SPI code well enough to say
>>> what's going
>>>>>>>>>>>>>> on. I've CC'ed Darren Hart, he might know who to check with
>>> next.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Those are some very specific SPI usage questions that I
>>> don't know
>>>>>>>>>>>>> the
>>>>>>>>>>>>> answer to off the top of my head. To find out, I would:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) Search for other drivers in tree and externally that use
>>>>>>>>>>>>> active-high
>>>>>>>>>>>>>
>>>>>>>>>>>>> First hit looks interesting:
>>>>>>>>>>>>> https://www.kernel.org/doc/Documentation/spi/spidev_test.c
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) Lookup the right mailing lists for SPI Linux kernel
>>> development
>>>>>>>>>>>>> and
>>>>>>>>>>>>> ask
>>>>>>>>>>>>> the same question there
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Darren Hart
>>>>>>>>>>>>> Intel Open Source Technology Center
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> elinux-MinnowBoard mailing list
>>>>>>>>>>>>> elinux-MinnowBoard at lists.elinux.org
>>>>>>>>>>>>> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Darren Hart
>>>>>>>>>>> Intel Open Source Technology Center
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Darren Hart
>>>>>>>> Intel Open Source Technology Center
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>> _______________________________________________
>>> elinux-MinnowBoard mailing list
>>> elinux-MinnowBoard at lists.elinux.org
>>> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
>>
>> Check http://elinux.org/Minnowboard:MinnowMax#Low_Speed_Expansion_.28Top.29 for the Linux GPIO numbers we are expecting.
>>
>> - John
> _______________________________________________
> elinux-MinnowBoard mailing list
> elinux-MinnowBoard at lists.elinux.org
> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
>
More information about the elinux-MinnowBoard
mailing list