From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "Philippe Rétornaz" <philippe.retornaz@epfl.ch>,
marc@cpdesign.com.au, "Fabio Estevam" <festevam@gmail.com>,
"Shawn Guo" <shawn.guo@freescale.com>,
"Samuel Ortiz" <sameo@linux.intel.com>,
"Sascha Hauer" <kernel@pengutronix.de>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: mc13xxx-core: kernel hangs after 'regmap_read'
Date: Thu, 24 May 2012 18:41:01 +0200 [thread overview]
Message-ID: <20120524164101.GW3710@pengutronix.de> (raw)
In-Reply-To: <20120524163604.GM5361@opensource.wolfsonmicro.com>
On Thu, May 24, 2012 at 05:36:05PM +0100, Mark Brown wrote:
> On Thu, May 24, 2012 at 06:16:50PM +0200, Philippe Rétornaz wrote:
>
> > Well, I think I found out why it's not working on mc13783.
> > With regmap, each transfert is done with 8bits words. The SPI hardware assert
> > the SS signal only during 8 bits "register" transfert then deassert the SS.
> > Then the SS is asserted and 24bits (3 bytes) are transfered (datas).
> > This clearly violate the datasheet which say SS must be asserted for the
> > *whole* transfert: register + data.
>
> > This is why the old code used a 32bits word transfert, it ensured that the SPI
> > hardware was keeping SS asserted without interruptions.
>
> > Is there any way to tell regmap to use 32bits transfert with the following
> > configuration (or doing it in a single shot 4x8bits):
>
> I think this is just a plain bug in the SPI controller driver. I think
> I have seen it before in some FSL BSPs (I do remember having to fall
> back to the bitbanging driver), it's surprising that it's also present
> in the mainline driver so perhaps it's something different. The driver
> is deasserting chip select between transfers but it should only do so at
> the end of the message unless told otherwise by the caller setting
> cs_change. regmap-spi uses spi_write_then_read() which does a single
> spi_message for the write and read parts of the transfer.
>
> If this is actually the issue the usual fix for this if the SPI
> controller hardware can't be persuaded to do the right thing is to put
> the chip select pin in GPIO mode and manage it by hand, though looking
> at the driver it appears it should be doingn that already. If you
> change to using the bitbanging SPI driver it should do the right thing
> (but will obviously be hideously slow), that ought to be at least a good
> reference for expected behaviour here.
The imx spi driver can do both (GPIO and hardware CS) because not all
pins that can do hardware CS are available as GPIO.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2012-05-24 16:41 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-21 16:06 Fabio Estevam
2012-05-22 0:53 ` Marc Reilly
2012-05-22 9:25 ` Mark Brown
2012-05-22 11:40 ` Fabio Estevam
2012-05-22 12:48 ` Philippe Rétornaz
2012-05-22 14:45 ` Fabio Estevam
2012-05-23 1:12 ` Fabio Estevam
2012-05-23 2:05 ` Fabio Estevam
2012-05-23 8:49 ` Mark Brown
2012-05-23 14:18 ` Fabio Estevam
2012-05-23 15:29 ` Fabio Estevam
2012-05-23 17:36 ` Mark Brown
2012-05-23 19:32 ` Fabio Estevam
2012-05-23 16:42 ` Shawn Guo
2012-05-23 16:34 ` Fabio Estevam
2012-05-24 0:48 ` Shawn Guo
2012-05-24 4:07 ` Fabio Estevam
2012-05-24 6:04 ` Shawn Guo
2012-05-24 6:39 ` Shawn Guo
2012-05-24 6:46 ` Uwe Kleine-König
2012-05-24 7:33 ` Shawn Guo
2012-05-24 9:08 ` Marc Reilly
2012-05-24 10:37 ` Mark Brown
2012-05-24 11:22 ` Marc Reilly
2012-05-24 12:14 ` Mark Brown
2012-05-24 13:06 ` Marc Reilly
2012-05-24 16:37 ` Mark Brown
2012-05-24 13:01 ` Fabio Estevam
2012-05-24 13:38 ` Marc Reilly
2012-05-24 16:16 ` Philippe Rétornaz
2012-05-24 16:36 ` Mark Brown
2012-05-24 16:41 ` Uwe Kleine-König [this message]
2012-05-24 17:39 ` Fabio Estevam
2012-05-24 18:03 ` Mark Brown
2012-05-24 19:42 ` philippe.retornaz
2012-05-24 22:21 ` Mark Brown
2012-05-25 8:56 ` Shawn Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120524164101.GW3710@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marc@cpdesign.com.au \
--cc=philippe.retornaz@epfl.ch \
--cc=sameo@linux.intel.com \
--cc=shawn.guo@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®