From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id E147DB70B2 for ; Wed, 24 Jun 2009 02:31:16 +1000 (EST) Received: from mail.marel.is (mail.marel.is [213.167.134.96]) by ozlabs.org (Postfix) with ESMTP id 270D5DDDE9 for ; Wed, 24 Jun 2009 02:31:15 +1000 (EST) Message-ID: <4A410351.4050508@marel.com> Date: Tue, 23 Jun 2009 16:31:13 +0000 From: =?ISO-8859-1?Q?K=E1ri_Dav=ED=F0sson?= MIME-Version: 1.0 To: Grant Likely Subject: Re: [PATCH v4] powerpc/5200: Add mpc5200-spi (non-PSC) device driver References: <20090618025030.12363.69402.stgit@localhost.localdomain> <4A40E940.10201@marel.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Cc: "linuxppc-dev@ozlabs.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Lowered my SPI clock down to 1MHz (from 50MHz (in steps of 10MHz). At 1Mhz the driver stops starving the rest of the kernel. What is interesting is that due to the low duty cycle of the SPI port the transfer rate at 1MHz and 50Mhz is almost the same. I suggest that the driver simply limits max frequency to 1Mhz. This (very limited) SPI pherperial does not handle any more anyways. rg kd Grant Likely wrote: > On Tue, Jun 23, 2009 at 8:40 AM, K=E1ri Dav=ED=F0sson wrote: >> Hi, >> >> I have been testing this driver a little bit (on 2.6.29.3) >> >> What happens for me is that the driver starves the system while sending >> data over the SPI interface. >> >> I think the problem is in the function (interrupt handler) >> mpc52xx_spi_irq() that calls the function mpc52xx_spi_fsm_process() >> which again is an loop that iterates over the whole data to be sent. >=20 > Hmmm, the state machine is supposed to yield after each byte sent, but > on fast transfers I could see it becoming ready to run again > immediately. >=20 > Unfortunately it is not an easy problem. The SPI device can only > handle 1 byte at a time. Maybe it would be better for CPU fairness if > all the work was done in a thread. I didn't originally because I > didn't want to introduce a huge amount of scheduling overhead every > time a byte was transfered, and I wanted to keep transfers fast. I > need to think about this some more. >=20 > g. >=20