> 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, meani
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 share the same semanti
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() means two different th
> 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 val
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 duplex,
>> if possible
> > 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 tw
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 for a
>> new SoC, and as
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 circumvents
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 coreb
9 matches
Mail list logo