* spi_async and heavy CPU occupation by ksoftirqd @ 2007-08-08 8:21 llandre [not found] ` <46B97D01.5000208-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: llandre @ 2007-08-08 8:21 UTC (permalink / raw) To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f I'm facing the following problem. I have to poll a SPI device periodically (around ten times a second). Both command and response are 1 byte. To do the job I created a work that looks like this: work(...) { sets debug_pin poll the device err = queue_delayed_work(wq, work, (HZ / 10)); clears debug_pin } The actual SPI transaction is perfomed by invoking spi_async. SPI transactions work fine but the kernel daemon ksoftirqd eats about 18% of CPU time. With the help of debug pin, I measured the execution time of function work that is around 70us. Then I commented out the call of spi_async and the ksoftirqd CPU occupation drops to 0%. Am I doing something wrong? I'm working with kernel 2.6.21.3 on iMXL ARM9 processor. TIA, llandre DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <46B97D01.5000208-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org>]
* Re: spi_async and heavy CPU occupation by ksoftirqd [not found] ` <46B97D01.5000208-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> @ 2007-08-08 16:27 ` David Brownell [not found] ` <200708080927.36737.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: David Brownell @ 2007-08-08 16:27 UTC (permalink / raw) To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Wednesday 08 August 2007, llandre wrote: > The actual SPI transaction is perfomed by invoking spi_async. SPI > transactions work fine but the kernel daemon ksoftirqd eats about 18% of > CPU time. That's excessive. > With the help of debug pin, I measured the execution time of > function work that is around 70us. Then I commented out the call of > spi_async and the ksoftirqd CPU occupation drops to 0%. Am I doing > something wrong? Are your transfers large enough to kick in DMA, or is it doing PIO? At a first glance, I wonder if you're not spending too much time in the spi_imx "pump_transfers" tasklet. I have no idea how well tuned that driver is... I'd expect that using spi_sync() wouldn't save much, but it might be worth verifying that. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <200708080927.36737.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]
* Re: spi_async and heavy CPU occupation by ksoftirqd [not found] ` <200708080927.36737.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> @ 2007-08-09 14:05 ` llandre [not found] ` <46BB1F10.3030608-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: llandre @ 2007-08-09 14:05 UTC (permalink / raw) To: David Brownell; +Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f >> With the help of debug pin, I measured the execution time of >> function work that is around 70us. Then I commented out the call of >> spi_async and the ksoftirqd CPU occupation drops to 0%. Am I doing >> something wrong? > > Are your transfers large enough to kick in DMA, or is it doing PIO? I transfer just 1 byte every time the work is executed (HZ/10). I tried to turn on and off DMA by setting/clearing enable_dma field but nothing changed: /* SPI Controller configuration */ static struct spi_imx_master spi_imx1_master_info = { .num_chipselect = SPI_NUM_CHIPSELECT, .enable_dma = 0 }; > At a first glance, I wonder if you're not spending too much time > in the spi_imx "pump_transfers" tasklet. I have no idea how well > tuned that driver is... Hmmm ... how do you suggest me to investigate around this tasklet? Do I need to use the toggling pin technique or does the kernel provides some tools to do that? Could oprofile come to help? > I'd expect that using spi_sync() wouldn't save much, but it might > be worth verifying that. Initially my driver used spi_sync. When I realized the huge CPU occupation I modified it in order to use spi_async instead but, again, nothing changed. -- llandre DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <46BB1F10.3030608-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org>]
* Re: spi_async and heavy CPU occupation by ksoftirqd [not found] ` <46BB1F10.3030608-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> @ 2007-08-09 15:23 ` David Brownell [not found] ` <200708090823.29708.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: David Brownell @ 2007-08-09 15:23 UTC (permalink / raw) To: llandre; +Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Thursday 09 August 2007, llandre wrote: > > At a first glance, I wonder if you're not spending too much time > > in the spi_imx "pump_transfers" tasklet. I have no idea how well > > tuned that driver is... > > Hmmm ... how do you suggest me to investigate around this tasklet? Do I > need to use the toggling pin technique That seems to be the most precise tool you have, unless you have access to the JTAG-style hardware tools giving access to the on-chip instruction trace buffers found in many ARMs. > or does the kernel provides some > tools to do that? Could oprofile come to help? Statistical profiling probably wouldn't help. I'm not sure that anything like gprof is working in the kernel. Folk that I know have done that level analysis tend to rely on hardware trace tools. > > I'd expect that using spi_sync() wouldn't save much, but it might > > be worth verifying that. > > Initially my driver used spi_sync. When I realized the huge CPU > occupation I modified it in order to use spi_async instead but, again, > nothing changed. And that should have been a HUGE clue that the way you were calling it wasn't a factor at all. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <200708090823.29708.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]
* Re: spi_async and heavy CPU occupation by ksoftirqd [not found] ` <200708090823.29708.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> @ 2007-08-10 8:52 ` llandre [not found] ` <46BC2732.5070504-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: llandre @ 2007-08-10 8:52 UTC (permalink / raw) To: David Brownell Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Andrea Paterniani > That seems to be the most precise tool you have, unless you > have access to the JTAG-style hardware tools giving access > to the on-chip instruction trace buffers found in many ARMs. Unfortunatley trace port is not available so I have to use the old fashioned debug pin technique. >> or does the kernel provides some >> tools to do that? Could oprofile come to help? > > Statistical profiling probably wouldn't help. I'm not sure that > anything like gprof is working in the kernel. Folk that I know > have done that level analysis tend to rely on hardware trace tools. I see. >>> I'd expect that using spi_sync() wouldn't save much, but it might >>> be worth verifying that. >> Initially my driver used spi_sync. When I realized the huge CPU >> occupation I modified it in order to use spi_async instead but, again, >> nothing changed. > > And that should have been a HUGE clue that the way you were calling > it wasn't a factor at all. I moved the set/clear pin functions inside the iMXL master driver and I found the problem is at line 804 inside the interrupt handler: qt510_debug_pin(1); while ((read(drv_data) == 0) && limit--); qt510_debug_pin(0); Usually the high pulse lasts about 10ms. Occasionally (about 1 time out of 3) it lasts about 300 ms ! That would explain the ksoftirqd abnormal CPU occupation. I hope Andrea can come to help. -- llandre DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <46BC2732.5070504-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org>]
* Re: spi_async and heavy CPU occupation by ksoftirqd [not found] ` <46BC2732.5070504-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> @ 2007-08-10 10:29 ` Andrea Paterniani [not found] ` <FLEPLOLKEPNLMHOILNHPMEKGDKAA.a.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Andrea Paterniani @ 2007-08-10 10:29 UTC (permalink / raw) To: llandre, David Brownell Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Is there any logged error message? May be that limit reaches 0 but in this case an error is logged (trailing bytes read failed). - Andrea > -----Messaggio originale----- > Da: llandre [mailto:r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org] > Inviato: venerdì 10 agosto 2007 10.52 > A: David Brownell > Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Andrea Paterniani > Oggetto: Re: [spi-devel-general] spi_async and heavy CPU occupation by > ksoftirqd > > > > That seems to be the most precise tool you have, unless you > > have access to the JTAG-style hardware tools giving access > > to the on-chip instruction trace buffers found in many ARMs. > Unfortunatley trace port is not available so I have to use the old > fashioned debug pin technique. > > >> or does the kernel provides some > >> tools to do that? Could oprofile come to help? > > > > Statistical profiling probably wouldn't help. I'm not sure that > > anything like gprof is working in the kernel. Folk that I know > > have done that level analysis tend to rely on hardware trace tools. > I see. > > >>> I'd expect that using spi_sync() wouldn't save much, but it might > >>> be worth verifying that. > >> Initially my driver used spi_sync. When I realized the huge CPU > >> occupation I modified it in order to use spi_async instead but, again, > >> nothing changed. > > > > And that should have been a HUGE clue that the way you were calling > > it wasn't a factor at all. > I moved the set/clear pin functions inside the iMXL master driver and I > found the problem is at line 804 inside the interrupt handler: > > qt510_debug_pin(1); > while ((read(drv_data) == 0) && limit--); > qt510_debug_pin(0); > > Usually the high pulse lasts about 10ms. Occasionally (about 1 time out > of 3) it lasts about 300 ms ! That would explain the ksoftirqd abnormal > CPU occupation. > I hope Andrea can come to help. > > > > -- > llandre > > DAVE Electronics System House - R&D Department > web: http://www.dave-tech.it > email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <FLEPLOLKEPNLMHOILNHPMEKGDKAA.a.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org>]
* Re: spi_async and heavy CPU occupation by ksoftirqd [not found] ` <FLEPLOLKEPNLMHOILNHPMEKGDKAA.a.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org> @ 2007-08-10 11:32 ` llandre [not found] ` <46BC4CD3.5090304-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: llandre @ 2007-08-10 11:32 UTC (permalink / raw) To: Andrea Paterniani Cc: David Brownell, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f I think I found the cause. Since I needed to enable the RDY control (SPI_CONTROL_DRCTL_2) as required by the SPI slave (Quantum QT510), the actual SPI transactions may occur after the driver wrote the TX FIFO (if (write(drv_data))). Thus while ((read(drv_data) == 0) && limit--); waits until the actual transaction have been completed, that happens when the slave is ready to accept data. So I'm afraid I need modify the MXL driver in order to support this case. -- llandre DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org > Is there any logged error message? > May be that limit reaches 0 but in this case an error is logged (trailing bytes read failed). > > - Andrea > > > > > >> -----Messaggio originale----- >> Da: llandre [mailto:r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org] >> Inviato: venerdì 10 agosto 2007 10.52 >> A: David Brownell >> Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Andrea Paterniani >> Oggetto: Re: [spi-devel-general] spi_async and heavy CPU occupation by >> ksoftirqd >> >> >>> That seems to be the most precise tool you have, unless you >>> have access to the JTAG-style hardware tools giving access >>> to the on-chip instruction trace buffers found in many ARMs. >> Unfortunatley trace port is not available so I have to use the old >> fashioned debug pin technique. >> >>>> or does the kernel provides some >>>> tools to do that? Could oprofile come to help? >>> Statistical profiling probably wouldn't help. I'm not sure that >>> anything like gprof is working in the kernel. Folk that I know >>> have done that level analysis tend to rely on hardware trace tools. >> I see. >> >>>>> I'd expect that using spi_sync() wouldn't save much, but it might >>>>> be worth verifying that. >>>> Initially my driver used spi_sync. When I realized the huge CPU >>>> occupation I modified it in order to use spi_async instead but, again, >>>> nothing changed. >>> And that should have been a HUGE clue that the way you were calling >>> it wasn't a factor at all. >> I moved the set/clear pin functions inside the iMXL master driver and I >> found the problem is at line 804 inside the interrupt handler: >> >> qt510_debug_pin(1); >> while ((read(drv_data) == 0) && limit--); >> qt510_debug_pin(0); >> >> Usually the high pulse lasts about 10ms. Occasionally (about 1 time out >> of 3) it lasts about 300 ms ! That would explain the ksoftirqd abnormal >> CPU occupation. >> I hope Andrea can come to help. >> >> >> >> -- >> llandre >> >> DAVE Electronics System House - R&D Department >> web: http://www.dave-tech.it >> email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <46BC4CD3.5090304-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org>]
* R: spi_async and heavy CPU occupation by ksoftirqd [not found] ` <46BC4CD3.5090304-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> @ 2007-08-10 12:27 ` Andrea Paterniani [not found] ` <FLEPLOLKEPNLMHOILNHPIEKIDKAA.a.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Andrea Paterniani @ 2007-08-10 12:27 UTC (permalink / raw) To: llandre Cc: David Brownell, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f You're right the current version of the driver doesn't support RDY control. Infact SPI_DEFAULT_CONTROL is defined with SPI_CONTROL_DRCTL_0. Also setup function doesn't managed DRCTL changes. Then you probably changes SPI_DEFAULT_CONTROL to use SPI_CONTROL_DRCTL_2. Please do your suggestions for driver modification in order to release a driver patch. - Andrea > -----Messaggio originale----- > Da: llandre [mailto:r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org] > Inviato: venerdì 10 agosto 2007 13.33 > A: Andrea Paterniani > Cc: David Brownell; spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > Oggetto: Re: [spi-devel-general] spi_async and heavy CPU occupation by > ksoftirqd > > > I think I found the cause. > Since I needed to enable the RDY control (SPI_CONTROL_DRCTL_2) as > required by the SPI slave (Quantum QT510), the actual SPI transactions > may occur after the driver wrote the TX FIFO (if (write(drv_data))). > Thus > > while ((read(drv_data) == 0) && limit--); > > waits until the actual transaction have been completed, that happens > when the slave is ready to accept data. > So I'm afraid I need modify the MXL driver in order to support this case. > > -- > llandre > > DAVE Electronics System House - R&D Department > web: http://www.dave-tech.it > email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org > > > > Is there any logged error message? > > May be that limit reaches 0 but in this case an error is logged (trailing bytes read failed). > > > > - Andrea > > > > > > > > > > > >> -----Messaggio originale----- > >> Da: llandre [mailto:r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org] > >> Inviato: venerdì 10 agosto 2007 10.52 > >> A: David Brownell > >> Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Andrea Paterniani > >> Oggetto: Re: [spi-devel-general] spi_async and heavy CPU occupation by > >> ksoftirqd > >> > >> > >>> That seems to be the most precise tool you have, unless you > >>> have access to the JTAG-style hardware tools giving access > >>> to the on-chip instruction trace buffers found in many ARMs. > >> Unfortunatley trace port is not available so I have to use the old > >> fashioned debug pin technique. > >> > >>>> or does the kernel provides some > >>>> tools to do that? Could oprofile come to help? > >>> Statistical profiling probably wouldn't help. I'm not sure that > >>> anything like gprof is working in the kernel. Folk that I know > >>> have done that level analysis tend to rely on hardware trace tools. > >> I see. > >> > >>>>> I'd expect that using spi_sync() wouldn't save much, but it might > >>>>> be worth verifying that. > >>>> Initially my driver used spi_sync. When I realized the huge CPU > >>>> occupation I modified it in order to use spi_async instead but, again, > >>>> nothing changed. > >>> And that should have been a HUGE clue that the way you were calling > >>> it wasn't a factor at all. > >> I moved the set/clear pin functions inside the iMXL master driver and I > >> found the problem is at line 804 inside the interrupt handler: > >> > >> qt510_debug_pin(1); > >> while ((read(drv_data) == 0) && limit--); > >> qt510_debug_pin(0); > >> > >> Usually the high pulse lasts about 10ms. Occasionally (about 1 time out > >> of 3) it lasts about 300 ms ! That would explain the ksoftirqd abnormal > >> CPU occupation. > >> I hope Andrea can come to help. > >> > >> > >> > >> -- > >> llandre > >> > >> DAVE Electronics System House - R&D Department > >> web: http://www.dave-tech.it > >> email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org > > > > > > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <FLEPLOLKEPNLMHOILNHPIEKIDKAA.a.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org>]
* Re: R: spi_async and heavy CPU occupation by ksoftirqd [not found] ` <FLEPLOLKEPNLMHOILNHPIEKIDKAA.a.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org> @ 2007-08-14 8:29 ` llandre [not found] ` <46C167F0.4040100-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: llandre @ 2007-08-14 8:29 UTC (permalink / raw) To: Andrea Paterniani Cc: David Brownell, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f AFAIK introducing support for RDY in the driver is not a trivial matter. Since a) I just need to perform 1-byte transactions to communicate with Quantum QT510 b) I don't have much time to spend on this issue (customer needs to assemble a demo quickly) I'm afraid I'll have to write a dirty patch just to make my specific configuration work. I'll keep you informed anyway. Regards, llandre DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org > You're right the current version of the driver doesn't support RDY control. > Infact SPI_DEFAULT_CONTROL is defined with SPI_CONTROL_DRCTL_0. > Also setup function doesn't managed DRCTL changes. > > Then you probably changes SPI_DEFAULT_CONTROL to use SPI_CONTROL_DRCTL_2. > > Please do your suggestions for driver modification in order to release a driver patch. > > - Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <46C167F0.4040100-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org>]
* Re: R: spi_async and heavy CPU occupation by ksoftirqd [not found] ` <46C167F0.4040100-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> @ 2007-08-14 9:43 ` llandre 0 siblings, 0 replies; 10+ messages in thread From: llandre @ 2007-08-14 9:43 UTC (permalink / raw) To: Andrea Paterniani Cc: David Brownell, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f [-- Attachment #1: Type: text/plain, Size: 1893 bytes --] Atatched is a dirty ugly patch that seems to work for 1-byte transfers I use with QT510. In case RDY control is enabled, transfer is completed by interrupt_data_ready (new irq handler) pump_transfers (tasklet) in this order. Regards, llandre DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org > AFAIK introducing support for RDY in the driver is not a trivial matter. > Since > a) I just need to perform 1-byte transactions to communicate with > Quantum QT510 > b) I don't have much time to spend on this issue (customer needs to > assemble a demo quickly) > I'm afraid I'll have to write a dirty patch just to make my specific > configuration work. > > I'll keep you informed anyway. > > Regards, > llandre > > DAVE Electronics System House - R&D Department > web: http://www.dave-tech.it > email: r&d2-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org > > > >> You're right the current version of the driver doesn't support RDY control. >> Infact SPI_DEFAULT_CONTROL is defined with SPI_CONTROL_DRCTL_0. >> Also setup function doesn't managed DRCTL changes. >> >> Then you probably changes SPI_DEFAULT_CONTROL to use SPI_CONTROL_DRCTL_2. >> >> Please do your suggestions for driver modification in order to release a driver patch. >> >> - Andrea > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > spi-devel-general mailing list > spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/spi-devel-general > > [-- Attachment #2: spi-imx-rdy.patch --] [-- Type: text/plain, Size: 4151 bytes --] diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c index 25c22ff..2b9ab9c 100644 --- a/drivers/spi/spi_imx.c +++ b/drivers/spi/spi_imx.c @@ -148,6 +148,7 @@ #define SPI_DEFAULT_ENABLE_LOOPBACK (0) #define SPI_DEFAULT_ENABLE_DMA (0) #define SPI_DEFAULT_PERIOD_WAIT (8) +#define SPI_IS_RDY_ENABLED ((SPI_DEFAULT_CONTROL & SPI_CONTROL_DRCTL_2) ? 1 : 0) /*-------------------------------------------------------------------------*/ @@ -281,7 +282,7 @@ static int flush(struct driver_data *drv_data) while (readl(regs + SPI_INT_STATUS) & SPI_STATUS_RR) d = readl(regs + SPI_RXDATA); } while ((readl(regs + SPI_CONTROL) & SPI_CONTROL_XCH) && limit--); - + return limit; } @@ -754,6 +755,20 @@ static irqreturn_t interrupt_wronly_transfer(struct driver_data *drv_data) return handled; } +static irqreturn_t interrupt_data_ready(struct driver_data *drv_data){ + void __iomem *regs = drv_data->regs; + + /* Read rx data */ + read(drv_data); + /* Disable irq */ + writel(readl(regs + SPI_INT_STATUS) & ~SPI_INTEN, + regs + SPI_INT_STATUS); + /* Schedule transfer tasklet */ + tasklet_schedule(&drv_data->pump_transfers); + + return IRQ_HANDLED; +} + static irqreturn_t interrupt_transfer(struct driver_data *drv_data) { struct spi_message *msg = drv_data->cur_msg; @@ -763,7 +778,7 @@ static irqreturn_t interrupt_transfer(struct driver_data *drv_data) unsigned long limit; status = readl(regs + SPI_INT_STATUS); - + while (status & (SPI_STATUS_TH | SPI_STATUS_RO)) { dev_dbg(&drv_data->pdev->dev, "interrupt_transfer - status = 0x%08X\n", status); @@ -785,23 +800,30 @@ static irqreturn_t interrupt_transfer(struct driver_data *drv_data) msg->state = ERROR_STATE; tasklet_schedule(&drv_data->pump_transfers); - + return IRQ_HANDLED; } /* Pump data */ read(drv_data); if (write(drv_data)) { - writel(readl(regs + SPI_INT_STATUS) & ~SPI_INTEN, - regs + SPI_INT_STATUS); + if (SPI_IS_RDY_ENABLED) { + /* RX IRQ handler will complete the transfer */ + drv_data->transfer_handler = interrupt_data_ready; + writel((readl(regs + SPI_INT_STATUS) & ~SPI_INTEN) | SPI_INTEN_RE, + regs + SPI_INT_STATUS); + goto skip_rx_poll; + } else { + writel(readl(regs + SPI_INT_STATUS) & ~SPI_INTEN, + regs + SPI_INT_STATUS); + } dev_dbg(&drv_data->pdev->dev, "interrupt_transfer - end of tx\n"); - + /* Read trailing bytes */ limit = loops_per_jiffy << 1; while ((read(drv_data) == 0) && limit--); - if (limit == 0) dev_err(&drv_data->pdev->dev, "interrupt_transfer - " @@ -810,6 +832,7 @@ static irqreturn_t interrupt_transfer(struct driver_data *drv_data) dev_dbg(&drv_data->pdev->dev, "interrupt_transfer - end of rx\n"); +skip_rx_poll: /* End of transfer, update total byte transfered */ msg->actual_length += drv_data->len; @@ -821,9 +844,11 @@ static irqreturn_t interrupt_transfer(struct driver_data *drv_data) /* Move to next transfer */ msg->state = next_transfer(drv_data); - /* Schedule transfer tasklet */ - tasklet_schedule(&drv_data->pump_transfers); - + if (!SPI_IS_RDY_ENABLED) { + /* Schedule transfer tasklet */ + tasklet_schedule(&drv_data->pump_transfers); + } + return IRQ_HANDLED; } @@ -832,7 +857,7 @@ static irqreturn_t interrupt_transfer(struct driver_data *drv_data) /* We did something */ handled = IRQ_HANDLED; } - + return handled; } @@ -949,7 +974,7 @@ static void pump_transfers(unsigned long data) /* Assert device chip-select */ drv_data->cs_control(SPI_CS_ASSERT); - + /* DMA cannot read/write SPI FIFOs other than 16 bits at a time; hence if bits_per_word is less or equal 8 PIO transfers are performed. Moreover DMA is convinient for transfer length bigger than FIFOs @@ -1089,7 +1114,7 @@ static void pump_messages(struct work_struct *work) /* Setup the SPI using the per chip configuration */ drv_data->cur_chip = spi_get_ctldata(drv_data->cur_msg->spi); restore_state(drv_data); - + /* Mark as busy and launch transfers */ tasklet_schedule(&drv_data->pump_transfers); } [-- Attachment #3: Type: text/plain, Size: 315 bytes --] ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ [-- Attachment #4: Type: text/plain, Size: 210 bytes --] _______________________________________________ spi-devel-general mailing list spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/spi-devel-general ^ permalink raw reply related [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-08-14 9:43 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-08-08 8:21 spi_async and heavy CPU occupation by ksoftirqd llandre [not found] ` <46B97D01.5000208-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> 2007-08-08 16:27 ` David Brownell [not found] ` <200708080927.36737.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> 2007-08-09 14:05 ` llandre [not found] ` <46BB1F10.3030608-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> 2007-08-09 15:23 ` David Brownell [not found] ` <200708090823.29708.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> 2007-08-10 8:52 ` llandre [not found] ` <46BC2732.5070504-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> 2007-08-10 10:29 ` Andrea Paterniani [not found] ` <FLEPLOLKEPNLMHOILNHPMEKGDKAA.a.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org> 2007-08-10 11:32 ` llandre [not found] ` <46BC4CD3.5090304-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> 2007-08-10 12:27 ` R: " Andrea Paterniani [not found] ` <FLEPLOLKEPNLMHOILNHPIEKIDKAA.a.paterniani-03BXCEkGbFHYGGNLXY5/rw@public.gmane.org> 2007-08-14 8:29 ` llandre [not found] ` <46C167F0.4040100-4VKA1VU3ct/j+vYz1yj4TQ@public.gmane.org> 2007-08-14 9:43 ` llandre
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).