[MinnowBoard] SPI questions
John "Warthog9" Hawley
warthog9 at eaglescrag.net
Thu Jan 29 21:09:34 UTC 2015
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
More information about the elinux-MinnowBoard
mailing list