Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Aug 2019 16:48:19 +0000 (UTC)
From:      Oskar Holmlund <oskar.holmlund@yahoo.com>
To:        "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   TI AM335x GPIO as chip select for SPI
Message-ID:  <444868997.1789504.1566751699269@mail.yahoo.com>
References:  <444868997.1789504.1566751699269.ref@mail.yahoo.com>

index | next in thread | previous in thread | raw e-mail

Hi,

I'm currently writing drivers for different clickboards (Mikroelektronika).The cape for Beaglebone black https://www.mikroe.com/beaglebone-mikrobus-cape use an ordinary GPIO(P8_10) as chipselect  for one of the mikrobus slots.
I follow the gpio pin assignment code from arm/freescale/imx/imx_spi.c  with minor modification.
(patch-src_sys_arm_ti_ti__spi.c and patch-src_sys_arm_ti_ti__spivar.h)
 The cs-gpios are described here:
https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-controller.yaml
To implement the "native cs" is it acceptable to change ofw_bus_parse_xref_list_internal() in sys/dev/ofw/ofw_bus_subr.c to be aware that pnode can be zero (and if its on the requested index report it to calling function)?
(patch-src_sys_dev_gpio_ofw__gpiobus.c andpatch-src_sys_dev_ofw_ofw_bus_subr.c)


 Before the introduction of ti_sysc: all GPIO modules was probed & attached at once and after a while the SPI was handled, example boot log:

---<<boot>>---
...
gpio0: mem 0x44e07000-0x44e07fff irq 7 on simplebus0
gpio1: mem 0x4804c000-0x4804cfff irq 8 on simplebus0
gpio2: mem 0x481ac000-0x481acfff irq 9 on simplebus0
gpio3: mem 0x481ae000-0x481aefff irq 10 on simplebus0 
...
spi0: mem 0x48030000-0x480303ff irq 36 on simplebus0 

After the introduction of ti_sysc (dts 5.x) it seems that the devices are attached by the location in memory (the order follow more or less whats described in TRM page 179 Table2-2. L4_WKUP Peripheral Memory Map.) ---<<boot>>---
...
gpio0: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 12 on ti_sysc1...spi0: <TI McSPI controller> mem 0-0x3ff irq 24 on ti_sysc12...gpio1: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 35 on ti_sysc21
...
spi1: <TI McSPI controller> mem 0-0x3ff irq 40 on ti_sysc27...
gpio2: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 44 on ti_sysc31gpio3: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 45 on ti_sysc32
 I'm fine with the initialization order but have an little problem. If the SPI0 uses one of the pins from GPIO1 its not initialized when the SPI0 is acquiring the pin and it fails. 
My solution is to use the config_intrhook_oneshot to delay the setup of GPIO Pin as CS - is there another way?


If a IO expander are attached to the SPI bus (of course with gpio as CS) and on the IO expander it is a LED and for some reasons it seems logic to use the gpioled driver. In this case the gpioled driver is not a child of the IO expander in the device tree but it uses the IO expander resource instead. For example:
fragment@0 {
          target-path="/leds";
          __overlay__ {
               mcp23_led@0 {
                         label = "d1";
                         gpios = <&mcp23s17ioexp1 15 0>;
                         default-state = "off";
               };        };};
Of course this will fail because the gpioled driver are probed&attached before the IO expander is available. It doesnt feel right to change the gpioled driver to use config_intrhook_oneshot().(patch-src_sys_dev_gpio_gpioled_fdt.c)
 Do you have any ideas how to address this situation?
-- 
Bästa Hälsningar
Oskar Holmlund
Tel 070-3220292
From owner-freebsd-arm@freebsd.org  Sun Aug 25 21:00:39 2019
Return-Path: <owner-freebsd-arm@freebsd.org>
Delivered-To: freebsd-arm@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7FB7CC3DE8
 for <freebsd-arm@mailman.nyi.freebsd.org>;
 Sun, 25 Aug 2019 21:00:39 +0000 (UTC)
 (envelope-from bugzilla-noreply@FreeBSD.org)
Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org
 [IPv6:2610:1c1:1:606c::19:3])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 server-signature RSA-PSS (4096 bits)
 client-signature RSA-PSS (4096 bits) client-digest SHA256)
 (Client CN "mxrelay.nyi.freebsd.org",
 Issuer "Let's Encrypt Authority X3" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 46GnbW1t6Rz4T2l
 for <freebsd-arm@FreeBSD.org>; Sun, 25 Aug 2019 21:00:39 +0000 (UTC)
 (envelope-from bugzilla-noreply@FreeBSD.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
 [IPv6:2610:1c1:1:606c::50:1d])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1A4C4234FA
 for <freebsd-arm@FreeBSD.org>; Sun, 25 Aug 2019 21:00:39 +0000 (UTC)
 (envelope-from bugzilla-noreply@FreeBSD.org)
Received: from kenobi.freebsd.org ([127.0.1.5])
 by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7PL0cOs012457
 for <freebsd-arm@FreeBSD.org>; Sun, 25 Aug 2019 21:00:38 GMT
 (envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
 by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7PL0cs0012448
 for freebsd-arm@FreeBSD.org; Sun, 25 Aug 2019 21:00:38 GMT
 (envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <201908252100.x7PL0cs0012448@kenobi.freebsd.org>
X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to
 bugzilla-noreply@FreeBSD.org using -f
From: bugzilla-noreply@FreeBSD.org
To: freebsd-arm@FreeBSD.org
Subject: Problem reports for freebsd-arm@FreeBSD.org that need special
 attention
Date: Sun, 25 Aug 2019 21:00:38 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>;
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Aug 2019 21:00:39 -0000

To view an individual PR, use:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).

The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off
Open        |    239673 | Spurious Interrupt message from /dev/led/led1

2 problems total for which you should take action.


home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?444868997.1789504.1566751699269>