Re: help getting SPI interface to work
dty...@anduin.org.uk (Dave Tyson) writes: >/dev/spi0 is defined which is a good start:: >[ 1.03] sun4ispi0 at simplebus1: SPI >[ 1.03] sun4ispi0: interrupting on GIC irq 42 >[ 1.03] spi0 at sun4ispi0: SPI bus >The board has the SPI mos1/miso/clk together with cs0 and cs1. >Looking at spi(4) there is no mention of a way to control cs0/1 to select >devices so I guess this is down to using gpio commands to pull the appropriate >pin low. The spi driver gets an address parameter that may control which cs line is asserted. It depends on the hardware if that is actually used. On these devices, the SPI controller is multiplexed on GPIO pins. You need to activate the function. This can be done by providing the proper DTB file or overlay, it _could_ also be done with the gpio driver (selecting an alt mode), but the sunxi gpio driver doesn't support that. >command = 0 ; /*we are not sending anything */ >spit.sit_addr = 0x00 ; >spit.sit_send = &command ; if you don't send anything, use NULL. >The device just needs the register address sending and should return a single >byte with the contents. Not sure what you want to control, but most devices require a read command to actually send data. The read command then usually includes the register address, sit_addr is not the register address but selects a slave device.
Re: Help with libcurses and lynx under NetBSD-9 and -current?
On Mon, Sep 20, 2021 at 07:37:55 +0930, Brett Lymn wrote: > On Fri, Sep 17, 2021 at 02:32:39PM +0300, Valery Ushakov wrote: > > > > Huh?! ^J does NOT have that side effect, ttys onlcr does. Which > > should be turned off for curses output, shouldn't it? > > > > Not always. You are right it is ttys that is doing it. The bug was > that cursor down with onlcr on always moved the cursor to the first > column of the next line. Right, right, and my question is: why do we have onlcr on for curses output? > Window(1) doesn't use ^J for cursor down so the output was > stair-stepping. Do you mean curses code was running with onlcr and was compensating for its own bug? -uwe
Re: help getting SPI interface to work
On Monday 20 Sep 2021 09:34:21 Michael van Elst wrote: > dty...@anduin.org.uk (Dave Tyson) writes: > >/dev/spi0 is defined which is a good start:: > > > >[ 1.03] sun4ispi0 at simplebus1: SPI > >[ 1.03] sun4ispi0: interrupting on GIC irq 42 > >[ 1.03] spi0 at sun4ispi0: SPI bus > > > >The board has the SPI mos1/miso/clk together with cs0 and cs1. > > > >Looking at spi(4) there is no mention of a way to control cs0/1 to select > >devices so I guess this is down to using gpio commands to pull the > >appropriate pin low. > > The spi driver gets an address parameter that may control which cs line > is asserted. It depends on the hardware if that is actually used. > > On these devices, the SPI controller is multiplexed on GPIO pins. You > need to activate the function. This can be done by providing the > proper DTB file or overlay, it _could_ also be done with the gpio > driver (selecting an alt mode), but the sunxi gpio driver doesn't > support that. > > >command = 0 ; /*we are not sending anything */ > >spit.sit_addr = 0x00 ; > >spit.sit_send = &command ; > > if you don't send anything, use NULL. > > >The device just needs the register address sending and should return a > >single byte with the contents. > > Not sure what you want to control, but most devices require a > read command to actually send data. The read command then usually > includes the register address, sit_addr is not the register address > but selects a slave device. Thanks to the info - I hadn't realised the sit_addr selected the slave device - will have a look at the DTB file and look to see how things are wired up in the kernel. Cheers, Dave
Re: Help with libcurses and lynx under NetBSD-9 and -current?
On Mon, Sep 20, 2021 at 02:44:21PM +0300, Valery Ushakov wrote: > > > > Not always. You are right it is ttys that is doing it. The bug was > > that cursor down with onlcr on always moved the cursor to the first > > column of the next line. > > Right, right, and my question is: why do we have onlcr on for curses > output? > That is a good question, onlcr is explicitly set/unset in a few places so it appears to be deliberate. > > > Window(1) doesn't use ^J for cursor down so the output was > > stair-stepping. > > Do you mean curses code was running with onlcr and was compensating > for its own bug? > It would appear so and has been doing this since before NetbSD which is not a justification, just an observation. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
daily CVS update output
Updating src tree: P src/sys/arch/arm/cortex/gic_splfuncs.c P src/sys/arch/arm/fdt/fdt_intr.h P src/sys/arch/arm/pic/pic_splfuncs.c P src/sys/arch/arm/pic/picvar.h P src/sys/arch/luna68k/dev/lunaws.c P src/sys/dev/pci/if_mcx.c P src/sys/dev/pci/if_msk.c P src/sys/kern/sys_eventfd.c P src/sys/kern/sys_timerfd.c P src/usr.bin/patch/patch.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 45449333 Sep 21 03:04 ls-lRA.gz
eventfd(2) definition in /usr/include/sys/eventfd.h
Hi, Thanks for your great work!!! C++ programs, for example pkgsrc/net/zeromq, use eventfd(2) however /usr/include/sys/eventfd.h does not support C++ use. Could you use __BEGIN_DECLS/__END_DECLS? My idea is as follows: Index: sys/sys/eventfd.h === RCS file: /cvsroot/src/sys/sys/eventfd.h,v retrieving revision 1.2 diff -u -r1.2 eventfd.h --- sys/sys/eventfd.h 19 Sep 2021 15:51:27 - 1.2 +++ sys/sys/eventfd.h 21 Sep 2021 03:33:25 - @@ -49,9 +49,11 @@ struct lwp; intdo_eventfd(struct lwp *, unsigned int, int, register_t *); #else /* ! _KERNEL */ +__BEGIN_DECLS inteventfd(unsigned int, int); inteventfd_read(int, eventfd_t *); inteventfd_write(int, eventfd_t); +__END_DECLS #endif /* _KERNEL */ #endif /* _SYS_EVENTFD_H_ */ Thank you very much. -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: eventfd(2) definition in /usr/include/sys/eventfd.h
> On Sep 20, 2021, at 8:42 PM, Ryo ONODERA wrote: > > Hi, > > Thanks for your great work!!! > > C++ programs, for example pkgsrc/net/zeromq, use eventfd(2) > however /usr/include/sys/eventfd.h does not support C++ use. > > Could you use __BEGIN_DECLS/__END_DECLS? Oh! Yes, please feel free to add these to the eventfd.h and timerfd.h headers as needed! Sorry for the oversight! > > My idea is as follows: > > Index: sys/sys/eventfd.h > === > RCS file: /cvsroot/src/sys/sys/eventfd.h,v > retrieving revision 1.2 > diff -u -r1.2 eventfd.h > --- sys/sys/eventfd.h 19 Sep 2021 15:51:27 - 1.2 > +++ sys/sys/eventfd.h 21 Sep 2021 03:33:25 - > @@ -49,9 +49,11 @@ > struct lwp; > int do_eventfd(struct lwp *, unsigned int, int, register_t *); > #else /* ! _KERNEL */ > +__BEGIN_DECLS > int eventfd(unsigned int, int); > int eventfd_read(int, eventfd_t *); > int eventfd_write(int, eventfd_t); > +__END_DECLS > #endif /* _KERNEL */ > > #endif /* _SYS_EVENTFD_H_ */ > > Thank you very much. > > -- > Ryo ONODERA // r...@tetera.org > PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3 -- thorpej
Re: Help with libcurses and lynx under NetBSD-9 and -current?
On Tue, Sep 21, 2021 at 07:43:28 +0930, Brett Lymn wrote: > On Mon, Sep 20, 2021 at 02:44:21PM +0300, Valery Ushakov wrote: > > > > > > Not always. You are right it is ttys that is doing it. The bug was > > > that cursor down with onlcr on always moved the cursor to the first > > > column of the next line. > > > > Right, right, and my question is: why do we have onlcr on for curses > > output? > > That is a good question, onlcr is explicitly set/unset in a few places > so it appears to be deliberate. > > > > Window(1) doesn't use ^J for cursor down so the output was > > > stair-stepping. > > > > Do you mean curses code was running with onlcr and was compensating > > for its own bug? > > It would appear so and has been doing this since before NetBSD which is > not a justification, just an observation. nl/nonl are defined to affect *input* translation, turning off ICRNL, so that apps can distinguish carriage return key. I *guess* that the code changes ONLCR in lockstep out of lazyness, so that for apps that run with echo/nl the nl->cr+nl on output is done by tty(4). Of course that bites back by messing up cud1. I would say this is saving a penny losing a pound. PS: From a quick look at xcurses - it seems to say that cbreak mode implies ICRNL cleared: cbreak Mode - [...] This mode achieves the same effect as non-canonical-mode, Case B input processing (with MIN set to 1 and ICRNL cleared) as specified in the XBD specification. -uwe
