Re: [coreboot] How is our SPI API supposed to work?

> While you guys are at it, it might be worth folding spi_claim_bus() > and spi_release_bus() into these changes so that CS is managed > automatically for things like SPI flash transactions. Right now they > return 0 for controllers that don't define ctrlr->claim_bus and > ctrlr->release_bus,

Re: [coreboot] How is our SPI API supposed to work?

On Thu, Apr 19, 2018 at 3:54 PM, Aaron Durbin wrote: > >> OK. It's just moving code around. > > > > Yeah, I just want to shuffle code around. Nothing is broken right now, it's > > just working in a confusing and inconsistent way. We should have an API > > where the callbacks

Re: [coreboot] How is our SPI API supposed to work?

On Thu, Apr 19, 2018 at 4:51 PM, Julius Werner wrote: >> How does it mean two different things? The pairing of a controller and >> device where a full duplex operation is needed but the controller >> doesn't support things should indeed fail. I do not undertand how >> xfer()

Re: [coreboot] How is our SPI API supposed to work?

> How does it mean two different things? The pairing of a controller and > device where a full duplex operation is needed but the controller > doesn't support things should indeed fail. I do not undertand how > xfer() means two different things. Whenever pairing hardware together > one needs to

Re: [coreboot] How is our SPI API supposed to work?

On Thu, Apr 19, 2018 at 4:06 PM, Julius Werner wrote: >> > My question is basically what happens when bytesout and bytesin are both >> > non-zero. My previous understanding was always that the SPI controller > >> It's up to the spi controller itself. They should support full

Re: [coreboot] How is our SPI API supposed to work?

> > My question is basically what happens when bytesout and bytesin are both > > non-zero. My previous understanding was always that the SPI controller > It's up to the spi controller itself. They should support full duplex, > if possible. And if not? The problem is that right now xfer() means

Re: [coreboot] How is our SPI API supposed to work?

Sorry to interrupt, but it seems that there are conflicting definitions of full-duplex... On 19.04.2018 05:39, Aaron Durbin via coreboot wrote: > On Wed, Apr 18, 2018 at 8:46 PM, Julius Werner wrote: >> I was trying to understand how to best implement the coreboot SPI API

[coreboot] Lenovo X201i not booting and not resuming from S3 due to SMM finalize

Hello, I found that after updating my Lenovo X201i the commit d533b16669a3bacb19b2824e6b4bc76a2a18c92a [1] causes a freeze during boot. Additionally, if INTEL_CHIPSET_LOCKDOWN is disabled (and thus booting works), resuming from S3 does not work anymore. I found that the following patch

Re: [coreboot] asrock-B75-pro3-m

Hi, your message was weird, I added some quotes back in. Somehow you dropped them and then asked for context? On 18.04.2018 06:06, taii...@gmx.com wrote: > On 04/17/2018 06:11 PM, Nico Huber wrote: >> On 17.04.2018 22:00, taii...@gmx.com wrote: >>> On 04/14/2018 06:45 PM, CarlosGonzalez via