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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I'm currently writing drivers for different clickboards (Mikroelektronika).= The cape for Beaglebone black https://www.mikroe.com/beaglebone-mikrobus-ca= pe use an ordinary GPIO(P8_10) as chipselect=C2=A0 for one of the mikrobus = slots. I follow the gpio pin assignment code from arm/freescale/imx/imx_spi.c wit= h minor modification. (patch-src_sys_arm_ti_ti__spi.c and=C2=A0patch-src_sys_arm_ti_ti__spivar.h) The cs-gpios are described here: https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-contro= ller.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_sub= r.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=20 ... spi0: mem 0x48030000-0x480303ff irq 36 on simplebus0=C2=A0 After the introduction of ti_sysc (dts 5.x) it seems that the devices are a= ttached by the location in memory (the order follow more or less whats desc= ribed 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_sysc= 1...spi0: <TI McSPI controller> mem 0-0x3ff irq 24 on ti_sysc12...gpio1: <T= I 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_sysc= 31gpio3: <TI AM335x General Purpose I/O (GPIO)> mem 0-0xfff irq 45 on ti_sy= sc32 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 a= cquiring the pin and it fails.=20 My solution is to use the config_intrhook_oneshot to delay the setup of GPI= O Pin as CS - is there another way? If a IO expander are attached to the SPI bus (of course with gpio as CS) an= d 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 { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 target-path=3D"/leds= "; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __overlay__ { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 mcp23_led@0 { =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 label =3D "d1"= ; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gpios= =3D <&mcp23s17ioexp1 15 0>; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defau= lt-state =3D "off"; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 };=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 };}; Of course this will fail because the gpioled driver are probed&attached bef= ore the IO expander is available. It doesnt feel right to change the gpiole= d driver to use config_intrhook_oneshot().(patch-src_sys_dev_gpio_gpioled_f= dt.c) Do you have any ideas how to address this situation? --=20 B=C3=A4sta H=C3=A4lsningar 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?444868997.1789504.1566751699269>