From owner-freebsd-mips@freebsd.org Mon May 20 14:44:02 2019 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D038B15AF178 for ; Mon, 20 May 2019 14:44:02 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E6198159D for ; Mon, 20 May 2019 14:44:01 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1558363434; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=n1+TRGyCy0EOZmGfYt1EjzQIE52pRcCb+lFzgsHZ1DWH/kWHgVrw50wJrSimrbakAYs3c+cdDw3j2 7rmNifFVNVzeYp5o6uj09MrX3rUNFbnhgN12UhVIs215wAB/ERazPNPr3rs6LwSGIfI6Wd2muMH8u2 RfixBNOOuc08CKMImvnP+jtX2CRDgIP2O5vRW+R0X+cmYmYI2cU0C/Kqas8RjYST56kaSw6PeAHKSk dsqfSrYqZ1L5WWF6HonWjj/LmSGd2byjoIobzajd2qor4zo7N7jZfP2kXnjDVh51EjZSf93mNtyKxk Q78QnN1nbxVmgEPSrilE0f+RFBptBkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=1KWf387FxvRG2jHFB28Q35KOAtlNSC1Sn6ZSCd8YQgo=; b=nlrioO+1wrDLQNDSa1ZyU8ITA+gRyo9egNtbSeyn84T7Rtacykggzwg5cMT9yVnXY2A4qkb35yBvQ mbq5m+aorqzATyFmHwMF6j1Mzbyvas+24e9j4x4vx+OKyGSVL4QqVC/XgI1gLzrgtv36fi3GRGKZnA rMXxXMucW8Pa9efXN+MpNhTwG/p2AvHip6ces7eeTpz//o3iS5Jc6SK9IulX14r0+ZFt1xxEdFJHBp Ags4MVCrjZhdqfk4OPmxfs56HGs+B88bCOUmgjgBduU5bhY3wH24wxCkIdXdts89uzqpNCHViyLuRr t1yy6FyqLWlyDMWK89yX7aN91ZWrTjg== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=1KWf387FxvRG2jHFB28Q35KOAtlNSC1Sn6ZSCd8YQgo=; b=AOuIfIPBGqVReaWcA2T1lnFbiY43oHyb/gL4upBYfldjdSuYZrEiHQZc7A7odKjFsEM7FfumGo78v /CRZP7PDVSe1RvODECss2+MFIiP32lJncGNHF6P3p7I/LR368Wgu3Gf1mEiwSDCJyU7ePRrvuL2EAt DPaPd26R3bEvG/41NSQ6eJ9b6wP3W0U8EnKuAXmQU131DLCzPLhra/DrbvI8lxnma4ZbQ2iqIdtCka Und8nPi6lYpZiGQU1lwzjycw/e0tOS0dqV+LH4QegYF79z72R/3QUXcnf/98csCtO/IOetczrPU1aQ 8+3mLjoiaBJ90AuABrpHy617uKYE+Qg== X-MHO-RoutePath: aGlwcGll X-MHO-User: ada453fd-7b0d-11e9-990f-673a89bc4518 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id ada453fd-7b0d-11e9-990f-673a89bc4518; Mon, 20 May 2019 14:43:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x4KEhl64024632; Mon, 20 May 2019 08:43:47 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <14cc3dfbfc7d7eb317129da8fe91485cf77b05af.camel@freebsd.org> Subject: Re: spigen problem From: Ian Lepore To: Adrian Chadd Cc: Mori Hiroki , Emmanuel Vadot , "freebsd-mips@freebsd.org" Date: Mon, 20 May 2019 08:43:47 -0600 In-Reply-To: References: <1991993923.530828.1556558314174.JavaMail.yahoo.ref@jws704008.mail.kks.yahoo.co.jp> <1991993923.530828.1556558314174.JavaMail.yahoo@jws704008.mail.kks.yahoo.co.jp> <22b68b094cbe7ab1b07673e43f6473906bd2d648.camel@freebsd.org> <20190429195750.409e9d13aea2ff1654a20d3c@bidouilliste.com> <20190429202357.79ac2d8dba8d0bed1caa8203@bidouilliste.com> <130153476.2287928.1556589558764.JavaMail.yahoo@jws700105.mail.ssk.yahoo.co.jp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1E6198159D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.991,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 14:44:03 -0000 On Sun, 2019-05-19 at 23:36 -0700, Adrian Chadd wrote: > On Sun, 19 May 2019 at 09:41, Ian Lepore wrote: > > > > On Sun, 2019-05-19 at 09:03 -0700, Adrian Chadd wrote: > > > hi! > > > > > > this looks ok to me. I'll go commit this tonight. > > > > > > > > > -a > > > > > > > I actually think it's horrible and we should fix the real problem > > of > > supporting hardware that can only do unidirectional > > transfers. But, > > doing so is a pretty big job. I've got some ideas on it, but it's > > not > > something that's going to get finished in a week or two. > > Do you mind if I commit this for now anyway? That at least unblocks > Mori to do other interesting hacks. > > What are your ideas? > > Sorry, I should have been more specific that my whining didn't amount to a blocking request, because I just don't have the spare time right now to even try to address the underlying problem. There probably should have been a rule for spi from day one that the controller driver has to supply a dummy buffer if the caller doesn't supply a buffer for one of the directions and the controller must do bidirectional transfers (like if dma is involved). Instead we went the other way and said callers always must supply bidirectional buffers even though the case of using both input and output data in one transfer is exceedingly rare. I think a minimal-changes idea that may work is to say that the callers must supply a buffer for both directions like they do now, but they are allowed to set either the tx or the rx length to zero to provide a clue to the controller driver that a transfer in that direction isn't needed if the hardware can't do it (or if not doing it speeds things up or makes things easier). We still have to examine and change every existing controller driver, but the changes would be minimal. -- Ian