[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120524222102.GP5361@opensource.wolfsonmicro.com>
Date: Thu, 24 May 2012 23:21:03 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: philippe.retornaz@...l.ch
Cc: Fabio Estevam <festevam@...il.com>,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>, marc@...esign.com.au,
Shawn Guo <shawn.guo@...escale.com>,
Samuel Ortiz <sameo@...ux.intel.com>,
Sascha Hauer <kernel@...gutronix.de>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: mc13xxx-core: kernel hangs after 'regmap_read'
On Thu, May 24, 2012 at 09:42:29PM +0200, philippe.retornaz@...l.ch wrote:
> Sadly, after looking at the imx31 datasheet it seems it's a hardware
> limitation. We could maybe workaround it by using DMA to access the
> CSPI but even with dma, this would need a single transfer in order
> to keep the CS signal asserted.
Oh dear, though the DMA approach sounds like it might be doable...
> Thus, we need to workaround this in the regmap-spi or mc13783-spi driver.
> Either we find a way to have regmap-spi to use 32bits transfert or
> we implement a custom bus inside mc13783-spi.
Like I said in my previous message the ideal thing would be that the SPI
driver would handle this, that'll ensure that the fix gets propagated to
the maximum possible set of users and is nicer from an abstraction point
of view.
A regmap internal workaround can possibly use Stephen Warren's stuff for
allowing buses to specify endianness stuff that was posted earlier today
though there's a few more tricks needed since this combines reads and
writes. We may also need to extend the SPI bus to make the capabilities
of the controller discoverable, right now I'm not sure that regmap can
discover when it could activate any more complex stuff. If we can make
it cheap enough to decide it'd probably be a small performance win even
where the controllers don't have issues.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists