pxa2xx_spi suspend/resume

pxa2xx_spi suspend/resume

[Daniel Ribeiro]

Hello linux spi experts.

I'm trying to get suspend/resume working on my pxa27x board, but resume
freezes waiting for SPI I/O.

After correcting suspend/resume ordering (i need MCI and UDC to resume
after SPI, PMIC and USB transceiver on the SPI bus), it still freezes at
the first SPI transfer.

I added some debug code to pxa2xx_spi.c as follows:

@@ -1095,6 +1097,14 @@ static void pump_transfers(unsigned long data)
        /* after chip select, release the data by enabling service
         * requests and interrupts, without changing any mode bits */
        write_SSCR1(cr1, reg);
+       mdebug("pump_transfersA SSCR0=%08x SSCR1=%08x SSTO=%08x SSPSP=%08x SSSR=%08x\n",
+               read_SSCR0(drv_data->ioaddr), read_SSCR1(drv_data->ioaddr),
+               read_SSTO(drv_data->ioaddr), read_SSPSP(drv_data->ioaddr), read_SSSR(drv_data->ioaddr));
+       udelay(200);
+       mdebug("pump_transfersB SSCR0=%08x SSCR1=%08x SSTO=%08x SSPSP=%08x SSSR=%08x\n",
+               read_SSCR0(drv_data->ioaddr), read_SSCR1(drv_data->ioaddr),
+               read_SSTO(drv_data->ioaddr), read_SSPSP(drv_data->ioaddr), read_SSSR(drv_data->ioaddr));
+
 }
 
 static void pump_messages(struct work_struct *work)
@@ -1626,11 +1636,16 @@ static int pxa2xx_spi_suspend(struct platform_device *pdev, pm_message_t state)
        int status = 0;
 
        status = stop_queue(drv_data);
-       if (status != 0)
+       if (status != 0) {
+               mdebug("spi suspend: status error!\n");
                return status;
+       }
        write_SSCR0(0, drv_data->ioaddr);
        clk_disable(ssp->clk);
-
+       mdebug("spi suspend ok\n");
+       mdebug("SUSPEND SSCR0=%08x SSCR1=%08x SSTO=%08x SSPSP=%08x\n",
+               read_SSCR0(drv_data->ioaddr), read_SSCR1(drv_data->ioaddr),
+               read_SSTO(drv_data->ioaddr), read_SSPSP(drv_data->ioaddr));
        return 0;
 }
@@ -1649,6 +1665,9 @@ static int pxa2xx_spi_resume(struct platform_device *pdev)
                dev_err(&pdev->dev, "problem starting queue (%d)\n", status);
                return status;
        }
+       mdebug("RESUME SSCR0=%08x SSCR1=%08x SSTO=%08x SSPSP=%08x\n",
+               read_SSCR0(drv_data->ioaddr), read_SSCR1(drv_data->ioaddr),
+               read_SSTO(drv_data->ioaddr), read_SSPSP(drv_data->ioaddr));
 
        return 0;
 }

 
And this generates the following debug output:

I/O before suspend:
ezx_pcap_putget: W 9c0253d2
pump_transfersA SSCR0=0010008f SSCR1=00380740 SSTO=00000064 SSPSP=00000000 SSSR=0000f034
pump_transfersB SSCR0=0010008f SSCR1=00000740 SSTO=00000000 SSPSP=00000000 SSSR=0000f024
ezx_pcap_putget: R 000253d2

Suspend/Resume:
spi suspend ok
SUSPEND SSCR0=00000000 SSCR1=00000740 SSTO=00000000 SSPSP=00000000
RESUME SSCR0=00000000 SSCR1=00000740 SSTO=00000000 SSPSP=00000000

I/O after resume:
ezx_mci_setpower: 23
ezx_pcap_putget: W 1c000000
pump_transfersA SSCR0=0010008f SSCR1=00380740 SSTO=00000064 SSPSP=00000000 SSSR=0000f024
pump_transfersB SSCR0=0010008f SSCR1=00380740 SSTO=00000064 SSPSP=00000000 SSSR=0000f024


>From my limited knowledge on this, it looks like there is no SSP
peripheral clock after resume,  SSTO is not decremented after 200us.

Any pointer on how to fix this? Or other tests i should do?


-- 
Daniel Ribeiro


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

Re: pxa2xx_spi suspend/resume

[Ned Forrester]

Daniel Ribeiro wrote:
> Hello linux spi experts.
> 
> I'm trying to get suspend/resume working on my pxa27x board, but resume
> freezes waiting for SPI I/O.
> 
> After correcting suspend/resume ordering (i need MCI and UDC to resume
> after SPI, PMIC and USB transceiver on the SPI bus), it still freezes at
> the first SPI transfer.
> 
> I added some debug code to pxa2xx_spi.c as follows:

[snip]

> From my limited knowledge on this, it looks like there is no SSP
> peripheral clock after resume,  SSTO is not decremented after 200us.
> 
> Any pointer on how to fix this? Or other tests i should do?

I did not look your report carefully, but I wonder what kernel you are
using.  A patch for failure to re-enable the clock was merged in
pxa2xx_spi.c on 2008-05-13, which would have been released in kernel
version 2.6.26, I think.

-- 
Ned Forrester                                       nforrester-/d+BM93fTQY@public.gmane.org
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

Re: pxa2xx_spi suspend/resume

[Daniel Ribeiro]

Em Qua, 2009-03-11 às 09:53 -0400, Ned Forrester escreveu:
> I did not look your report carefully, but I wonder what kernel you are
> using.  A patch for failure to re-enable the clock was merged in
> pxa2xx_spi.c on 2008-05-13, which would have been released in kernel
> version 2.6.26, I think.
> 
Please, look carefully. I had a lot of work to get these debug messages
without the framebuffer, and with the kernel frozen. ;)

root@a780:~# uname -a
Linux a780 2.6.29-rc5-ezx200902180753 #77 PREEMPT Wed Mar 11 07:20:29
BRT 2009 armv5tel unknown


-- 
Daniel Ribeiro


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: pxa2xx_spi suspend/resume

[Daniel Ribeiro]

Em Qua, 2009-03-11 às 09:53 -0400, Ned Forrester escreveu:
> > From my limited knowledge on this, it looks like there is no SSP
> > peripheral clock after resume,  SSTO is not decremented after 200us.
> > 
> > Any pointer on how to fix this? Or other tests i should do?
> 
> I did not look your report carefully, but I wonder what kernel you are
> using.  A patch for failure to re-enable the clock was merged in
> pxa2xx_spi.c on 2008-05-13, which would have been released in kernel
> version 2.6.26, I think.

Ahh! I forgot to mention on the previous email, but i think its worth to
inform you that with pm_test set to "core" i can suspend/resume just
fine. Its only when PXA is really put to sleep that pxa2xx-spi
misbehaves.

-- 
Daniel Ribeiro


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: pxa2xx_spi suspend/resume

[Ned Forrester]

Daniel Ribeiro wrote:
> Hello linux spi experts.
> 
> I'm trying to get suspend/resume working on my pxa27x board, but resume
> freezes waiting for SPI I/O.
> 
> After correcting suspend/resume ordering (i need MCI and UDC to resume
> after SPI, PMIC and USB transceiver on the SPI bus), it still freezes at
> the first SPI transfer.
> 
> I added some debug code to pxa2xx_spi.c as follows:
> 
> @@ -1095,6 +1097,14 @@ static void pump_transfers(unsigned long data)
>         /* after chip select, release the data by enabling service
>          * requests and interrupts, without changing any mode bits */
>         write_SSCR1(cr1, reg);
> +       mdebug("pump_transfersA SSCR0=%08x SSCR1=%08x SSTO=%08x SSPSP=%08x SSSR=%08x\n",
> +               read_SSCR0(drv_data->ioaddr), read_SSCR1(drv_data->ioaddr),
> +               read_SSTO(drv_data->ioaddr), read_SSPSP(drv_data->ioaddr), read_SSSR(drv_data->ioaddr));
> +       udelay(200);
> +       mdebug("pump_transfersB SSCR0=%08x SSCR1=%08x SSTO=%08x SSPSP=%08x SSSR=%08x\n",
> +               read_SSCR0(drv_data->ioaddr), read_SSCR1(drv_data->ioaddr),
> +               read_SSTO(drv_data->ioaddr), read_SSPSP(drv_data->ioaddr), read_SSSR(drv_data->ioaddr));
> +
>  }
>  
>  static void pump_messages(struct work_struct *work)
> @@ -1626,11 +1636,16 @@ static int pxa2xx_spi_suspend(struct platform_device *pdev, pm_message_t state)
>         int status = 0;
>  
>         status = stop_queue(drv_data);
> -       if (status != 0)
> +       if (status != 0) {
> +               mdebug("spi suspend: status error!\n");
>                 return status;
> +       }
>         write_SSCR0(0, drv_data->ioaddr);
>         clk_disable(ssp->clk);
> -
> +       mdebug("spi suspend ok\n");
> +       mdebug("SUSPEND SSCR0=%08x SSCR1=%08x SSTO=%08x SSPSP=%08x\n",
> +               read_SSCR0(drv_data->ioaddr), read_SSCR1(drv_data->ioaddr),
> +               read_SSTO(drv_data->ioaddr), read_SSPSP(drv_data->ioaddr));
>         return 0;
>  }
> @@ -1649,6 +1665,9 @@ static int pxa2xx_spi_resume(struct platform_device *pdev)
>                 dev_err(&pdev->dev, "problem starting queue (%d)\n", status);
>                 return status;
>         }
> +       mdebug("RESUME SSCR0=%08x SSCR1=%08x SSTO=%08x SSPSP=%08x\n",
> +               read_SSCR0(drv_data->ioaddr), read_SSCR1(drv_data->ioaddr),
> +               read_SSTO(drv_data->ioaddr), read_SSPSP(drv_data->ioaddr));
>  
>         return 0;
>  }
> 
>  
> And this generates the following debug output:
> 
> I/O before suspend:
> ezx_pcap_putget: W 9c0253d2
> pump_transfersA SSCR0=0010008f SSCR1=00380740 SSTO=00000064 SSPSP=00000000 SSSR=0000f034
> pump_transfersB SSCR0=0010008f SSCR1=00000740 SSTO=00000000 SSPSP=00000000 SSSR=0000f024
> ezx_pcap_putget: R 000253d2
> 
> Suspend/Resume:
> spi suspend ok
> SUSPEND SSCR0=00000000 SSCR1=00000740 SSTO=00000000 SSPSP=00000000
> RESUME SSCR0=00000000 SSCR1=00000740 SSTO=00000000 SSPSP=00000000
> 
> I/O after resume:
> ezx_mci_setpower: 23
> ezx_pcap_putget: W 1c000000
> pump_transfersA SSCR0=0010008f SSCR1=00380740 SSTO=00000064 SSPSP=00000000 SSSR=0000f024
> pump_transfersB SSCR0=0010008f SSCR1=00380740 SSTO=00000064 SSPSP=00000000 SSSR=0000f024
> 
> 
>>From my limited knowledge on this, it looks like there is no SSP
> peripheral clock after resume,  SSTO is not decremented after 200us.
> 
> Any pointer on how to fix this? Or other tests i should do?

I think that SSTO does not decrement during operation.  It is a value to
which the internal timer is reset each time there is RX activity.  The
reason it becomes zero in the pre-suspend example, is that it is
explicitly set to zero (disabled) during the end-of-transfer actions of
dma_transfer() and int_transfer_complete().  It looks like you are using
DMA mode (thus dma_transfer()) because RSRE and TSRE bits are set in
SSCR1, and the RIE and TIE bits are clear.

I think the interesting feature is that the BSY bit in SSSR is never set
after resume.  This bit is set automatically when the SSP is busy.  The
developer's manual is not exactly clear about what is required for this
bit to be set.  I expect that not loading data in the TX FIFO would
cause the SSP to not be busy, but I don't see how this would be
possible, because the loading of the TX FIFO is controlled by DMA.

I don't know if lack of clock would do prevent setting BSY or not. You
could directly read the CKEN register to see if the relevant clock
enable bits for your SSP port are set (one of bits 23, 3 or 4, for SSP1,
SSP2 or SSP3, respectively).  I can't find anything in the dev man that
says there needs to be a delay between enabling the clock and starting
operations on the SSP, but you might try introducing a short delay in
resume after enabling the clock.  The dev man does say that the clock
must be disabled before changing any of the clock selection bits in the
SSP registers (section 8.4.10), so you might check that none of these
bits are being changed after enabling the clock.

You may want to check DCSR to make sure the run bits are set for the
assigned dma channels.  You will probably need more printk's just to
find out what channels were assigned; they are assigned in
pxa2xx_spi_probe().  It's hard to believe that these would not be set,
as it is done pump_transfers(), and you know execution is going there.

That's about all I can think of for now.  I don't use suspend/resume in
my application on a PXA255, and I don't specifically know of anyone who
has used it.  I think the last suspend/resume bug fix may be been
discovered by inspection, not by someone trying it, but I'm not sure
about that.

-- 
Ned Forrester                                       nforrester-/d+BM93fTQY@public.gmane.org
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

Re: pxa2xx_spi suspend/resume

[Daniel Ribeiro]

Em Qui, 2009-03-12 às 10:38 -0400, Ned Forrester escreveu:
> You may want to check DCSR to make sure the run bits are set for the
> assigned dma channels.  You will probably need more printk's just to
> find out what channels were assigned; they are assigned in
> pxa2xx_spi_probe().  It's hard to believe that these would not be set,
> as it is done pump_transfers(), and you know execution is going there.

Indeed, i tried using the driver on PIO mode, and suspend/resume works!

Here is what i get with a little more debug and DMA enabled..

SUSPEND DRCMR_TX=00000084 DRCMR_RX=00000084
RESUME DRCMR_TX=00000000 DRCMR_RX=00000000

Should i cook a patch to store DRCMR on suspend and restore on resume?
Or is the proper fix something else?

-- 
Daniel Ribeiro


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: pxa2xx_spi suspend/resume

[Ned Forrester]

Daniel Ribeiro wrote:
> Em Qui, 2009-03-12 Ã s 10:38 -0400, Ned Forrester escreveu:
>> You may want to check DCSR to make sure the run bits are set for the
>> assigned dma channels.  You will probably need more printk's just to
>> find out what channels were assigned; they are assigned in
>> pxa2xx_spi_probe().  It's hard to believe that these would not be set,
>> as it is done pump_transfers(), and you know execution is going there.
> 
> Indeed, i tried using the driver on PIO mode, and suspend/resume works!
> 
> Here is what i get with a little more debug and DMA enabled..
> 
> SUSPEND DRCMR_TX=00000084 DRCMR_RX=00000084
> RESUME DRCMR_TX=00000000 DRCMR_RX=00000000
> 
> Should i cook a patch to store DRCMR on suspend and restore on resume?
> Or is the proper fix something else?

Hmmm... This looks scary.  If the DRCMR registers went to zero, what
else has changed in the DMA setup?  A call to pxa2xx_spi_remove() would
have cleared these, but that should not be called for suspend/resume.
Have you checked all the other DMA related registers that are assigned
to the SSP device?  Are these the only ones that are anomalous, or are
these just the first ones you found?

Actually, I don't think there are any other registers, save the ones
that will be set up by pump_transfers(), anyway.  The PXA270 has a few
more DMA related registers than the PXA255, but I don't see anything
that looks like trouble, other than what you found above.

I would not jump to the conclusion (perhaps you haven't, but I don't
have the whole picture) that we just need to restore these two
registers.  You need to make sure that the assigned DMA channels are
still allocated.  I wonder what process cleared these registers and what
that might mean about the possibility that DMA channel assignments were
purged on resume.

There is code in arch/arm/mach-pxa/ssp.c ssp_probe() that assigns DMA
request numbers for each SSP channel.  I think, but I am not sure, that
these are really fixed numbers determined by the hardware wiring of
peripheral devices to DMA requests (see tables 5-9 and 5-21 of the dev
man).  If so, then the value passed is a constant anyway, and thus it
must still be valid.

In drivers/spi/pxa2xx_spi.c pxa2xx_spi_probe(), the DMA channel numbers
are allocated.  These are definitely not constants, as they are a
limited resource.  The channel numbers are then loaded into the DRCMR
registers to map the request to the channel.  I don't know how to check
that the previous assignment of DMA channels is still valid.

You could try a patch to restore DRCMR registers to see if that fixes
the problem or just makes things worse.  I don't recommend submitting
such a patch without guidance from someone more knowledgeable about DMA
and suspend/resume.

David, do you have any knowledge of what is happening to the DMA
request-to-channel assignment registers in the PXA, during suspend/resume?

--

In the process of searching for inspiration on this matter, I was
reminded of another poster who has tried getting suspend/resume to work.
 I don't think that the thread:

http://osdir.com/ml/linux.kernel.spi.devel/2008-02/msg00075.html

has any useful info for you, unless you find that the problem you
discovered has the same symptoms as Zeke described. He was on the wrong
track to fix, but maybe you have found the cause.  Unfortunately he had
to drop the problem before it got fixed.

-- 
Ned Forrester                                       nforrester-/d+BM93fTQY@public.gmane.org
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

Re: pxa2xx_spi suspend/resume

[Daniel Ribeiro]

Em Qui, 2009-03-12 às 23:35 -0400, Ned Forrester escreveu:
> Hmmm... This looks scary.  If the DRCMR registers went to zero, what
> else has changed in the DMA setup?  A call to pxa2xx_spi_remove() would
> have cleared these, but that should not be called for suspend/resume.
> Have you checked all the other DMA related registers that are assigned
> to the SSP device?  Are these the only ones that are anomalous, or are
> these just the first ones you found?
> 
> Actually, I don't think there are any other registers, save the ones
> that will be set up by pump_transfers(), anyway.  The PXA270 has a few
> more DMA related registers than the PXA255, but I don't see anything
> that looks like trouble, other than what you found above.

Everything else is OK. DRCMR is the only thing that gets nuked and is
not restored by pump_transfers().

> I would not jump to the conclusion (perhaps you haven't, but I don't
> have the whole picture) that we just need to restore these two
> registers.  You need to make sure that the assigned DMA channels are
> still allocated.  I wonder what process cleared these registers and what
> that might mean about the possibility that DMA channel assignments were
> purged on resume.

Currently i am restoring them to their probe() values on resume(), only
if rx_channel and tx_channel are != -1 (dma enabled). It seems to be
working fine. Im not sure if this is all that is needed, but i suspect
its enough.

And i think that its not software that is nuking DRCMR, as i said on a
previous email, i dont need to restore DRCMR if i use the "core" pm_test
mode. (the core pm_test executes the suspend/resume routines just as if
it was a normal suspend/resume, the only difference is that PXA will not
be really suspend).

There is still a chance that my bootloader is nuking these registers on
resume before giving control to kernel, i will check the bootloader code
and see if this is the case. I suspect it isn't.

> You could try a patch to restore DRCMR registers to see if that fixes
> the problem or just makes things worse.  I don't recommend submitting
> such a patch without guidance from someone more knowledgeable about DMA
> and suspend/resume.

It fixes the problem here, im not sure if its all that is needed, so,
lets wait for more comments on this before i submit the patch.

> In the process of searching for inspiration on this matter, I was
> reminded of another poster who has tried getting suspend/resume to work.
>  I don't think that the thread:

I googled the ML archives before posting and found this thread. And
altough it has the same symptoms, i think it may be a different problem.
I discarded his fix proposal at the first debug run, because my SSP
registers are exactly what i expected on resume(), and exactly the same
as they were on suspend().

-- 
Daniel Ribeiro


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: pxa2xx_spi suspend/resume

[Ned Forrester]

Daniel Ribeiro wrote:
> Em Qui, 2009-03-12 Ã s 23:35 -0400, Ned Forrester escreveu:
> Everything else is OK. DRCMR is the only thing that gets nuked and is
> not restored by pump_transfers().

OK.  It would really be nice to know what is zeroing DRCMR.
pump_transfers() is assuming that once DMA channels have been allocated
and setup then the stay that way.  Obviously that is not a valid assumption.

>> I would not jump to the conclusion (perhaps you haven't, but I don't
>> have the whole picture) that we just need to restore these two
>> registers.  You need to make sure that the assigned DMA channels are
>> still allocated.  I wonder what process cleared these registers and what
>> that might mean about the possibility that DMA channel assignments were
>> purged on resume.
> 
> Currently I am restoring them to their probe() values on resume(), only
> if rx_channel and tx_channel are != -1 (dma enabled). It seems to be
> working fine. I'm not sure if this is all that is needed, but I suspect
> it's enough.

OK.  That's good.

> And I think that it's not software that is nuking DRCMR, as I said on a
> previous email, I dont need to restore DRCMR if I use the "core" pm_test
> mode. (the core pm_test executes the suspend/resume routines just as if
> it was a normal suspend/resume, the only difference is that PXA will not
> be really suspend).

I'm not familiar with the core pm test, but I can see that it is useful.
 I could not find anything in the PXA270 developer's manual that
mentions the value of DRCMR being altered by any hardware action
involving suspend; however, I have found other omissions in the past.

> There is still a chance that my bootloader is nuking these registers on
> resume before giving control to kernel, I will check the bootloader code
> and see if this is the case. I suspect it isn't.

Interesting possibility.  I thought suspend/resume was just a low power
state that awakens by restarting the clocks.  Does the boot loader
actually run a bit on resume before discovering that memory is already
loaded?

>> You could try a patch to restore DRCMR registers to see if that fixes
>> the problem or just makes things worse.  I don't recommend submitting
>> such a patch without guidance from someone more knowledgeable about DMA
>> and suspend/resume.
> 
> It fixes the problem here, I'm not sure if it's all that is needed, so,
> lets wait for more comments on this before I submit the patch.

Hopefully Dave, or someone else knowledgeable will speak up.  Otherwise,
go ahead with submitting the patch.  And thanks for tracking this down.

-- 
Ned Forrester                                       nforrester-/d+BM93fTQY@public.gmane.org
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

Re: pxa2xx_spi suspend/resume

[Daniel Ribeiro]

Em Sex, 2009-03-13 às 09:32 -0400, Ned Forrester escreveu:
> Interesting possibility.  I thought suspend/resume was just a low power
> state that awakens by restarting the clocks.  Does the boot loader
> actually run a bit on resume before discovering that memory is already
> loaded?

Linux supports the standby and the sleep PXA modes. The manual says that
on the sleep (suspend/resume) mode all processor state is lost and a new
boot sequence is needed.

I checked my bootloader, when its coming back from resume it executes
less than 30 instructions, and it doesn't touch DRCMR. So i think that
we really need to restore DRCMR on resume.

> Hopefully Dave, or someone else knowledgeable will speak up.  Otherwise,
> go ahead with submitting the patch.  And thanks for tracking this down.

Thank you for mentoring this! :)
I will submit the patch tomorrow morning.

-- 
Daniel Ribeiro


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general