[PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550

[PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550

[Milan Plzik]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

  Good day,

  recently I've been trying to get working PCMCIA interface on H5000
ipaq series, using dual PCMCIA sleeve. So far things work correctly, but
I had to do one modification to drivers/pcmcia/pxa2xx_base.c to get the
interface working with orinoco gold PCMCIA card (wired pcnet_cs ethernet
card worked even without this modification). Patch attached.

  The issue has something to do with assert time on PCMCIA bus, but I'm
not really sure what -- I found the working value just by trial&error
approach. I'm not sure how is the assert value in pxa2xx_mcxx_asst
calculated (I know, simple formula, but the reason why is it calculated
that way is not obvious for me), neither that my modification is
correct. It just works with iPAQ. 

  Please include me in Cc, as I'm not subscribed to neither of mailing
lists.

  Best regards,
	Milan Plzik


[-- Attachment #2: pcmcia_timing_fix.patch --]
[-- Type: text/x-patch, Size: 629 bytes --]

Index: drivers/pcmcia/pxa2xx_base.c
===================================================================
RCS file: /cvs/linux/kernel26/drivers/pcmcia/pxa2xx_base.c,v
retrieving revision 1.12
diff -a -u -r1.12 pxa2xx_base.c
--- drivers/pcmcia/pxa2xx_base.c	10 Mar 2007 11:46:02 -0000	1.12
+++ drivers/pcmcia/pxa2xx_base.c	3 Aug 2007 20:04:10 -0000
@@ -59,7 +59,7 @@
 				     u_int mem_clk_10khz)
 {
 	u_int code = pcmcia_cycle_ns * mem_clk_10khz;
-	return (code / 300000) + ((code % 300000) ? 1 : 0) - 1;
+	return (code / 300000) + ((code % 300000) ? 1 : 0) + 1;
 }
 
 static inline u_int pxa2xx_mcxx_setup(u_int pcmcia_cycle_ns,

Re: [PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550

[Steven Newbury]

--- Milan Plzik <milan.plzik@gmail.com> wrote:

>   Good day,
> 
>   recently I've been trying to get working PCMCIA interface on H5000
> ipaq series, using dual PCMCIA sleeve. So far things work correctly, but
> I had to do one modification to drivers/pcmcia/pxa2xx_base.c to get the
> interface working with orinoco gold PCMCIA card (wired pcnet_cs ethernet
> card worked even without this modification). Patch attached.
> 
>   The issue has something to do with assert time on PCMCIA bus, but I'm
> not really sure what -- I found the working value just by trial&error
> approach. I'm not sure how is the assert value in pxa2xx_mcxx_asst
> calculated (I know, simple formula, but the reason why is it calculated
> that way is not obvious for me), neither that my modification is
> correct. It just works with iPAQ. 
> 
I posted a patch to linux-arm-kernel which reworked the timing code.  The
existing is/was IMHO wrong and this showed up for me with frequency scaling
where the code would not keep the PCMCIA timings constant with changes to the
core frequency.  Here it is:
http://marc.info/?l=linux-arm-kernel&m=116861295404294&w=2


Steve


      ___________________________________________________________
For email that puts you in control, choose Yahoo! Mail.
http://uk.docs.yahoo.com/mail/addressguard2.html

Re: [PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550

[Milan Plzik]

On Št, 2007-08-09 at 16:06 +0100, Steven Newbury wrote:
> --- Milan Plzik <milan.plzik@gmail.com> wrote:
> 
> >   Good day,
> > 
> >   recently I've been trying to get working PCMCIA interface on H5000
> > ipaq series, using dual PCMCIA sleeve. So far things work correctly, but
> > I had to do one modification to drivers/pcmcia/pxa2xx_base.c to get the
> > interface working with orinoco gold PCMCIA card (wired pcnet_cs ethernet
> > card worked even without this modification). Patch attached.
> > 
> >   The issue has something to do with assert time on PCMCIA bus, but I'm
> > not really sure what -- I found the working value just by trial&error
> > approach. I'm not sure how is the assert value in pxa2xx_mcxx_asst
> > calculated (I know, simple formula, but the reason why is it calculated
> > that way is not obvious for me), neither that my modification is
> > correct. It just works with iPAQ. 
> > 
> I posted a patch to linux-arm-kernel which reworked the timing code.  The
> existing is/was IMHO wrong and this showed up for me with frequency scaling
> where the code would not keep the PCMCIA timings constant with changes to the
> core frequency.  Here it is:
> http://marc.info/?l=linux-arm-kernel&m=116861295404294&w=2

  I found out that drivers/pcmcia/pxa2xx_base.c from handhelds.org tree
was a bit modified. I tried both vanilla kernel tree and vanilla+this
patch -- both worked with pcnet_cs, and neither one with orinoco card.
As far as I understand, handhelds.org modification makes use of memory
clock instead of cpu clock for calculations. But even when using old
handhelds.org driver with modified formulas, orinoco card won't
initialize.

  I'm not really sure how things should be calculated, I'll try ask
folks who modified the hh.org driverto see what could cause the
problems.

> 
> 
> Steve
> 

	Milan

> 
>       ___________________________________________________________
> For email that puts you in control, choose Yahoo! Mail.
> http://uk.docs.yahoo.com/mail/addressguard2.html

Re: [PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550

[Steven Newbury]

--- Milan Plzik <milan.plzik@gmail.com> wrote:

> On Å t, 2007-08-09 at 16:06 +0100, Steven Newbury wrote:
> > --- Milan Plzik <milan.plzik@gmail.com> wrote:
> > 
> > >   Good day,
> > > 
> > >   recently I've been trying to get working PCMCIA interface on H5000
> > > ipaq series, using dual PCMCIA sleeve. So far things work correctly, but
> > > I had to do one modification to drivers/pcmcia/pxa2xx_base.c to get the
> > > interface working with orinoco gold PCMCIA card (wired pcnet_cs ethernet
> > > card worked even without this modification). Patch attached.
> > > 
> > >   The issue has something to do with assert time on PCMCIA bus, but I'm
> > > not really sure what -- I found the working value just by trial&error
> > > approach. I'm not sure how is the assert value in pxa2xx_mcxx_asst
> > > calculated (I know, simple formula, but the reason why is it calculated
> > > that way is not obvious for me), neither that my modification is
> > > correct. It just works with iPAQ. 
> > > 
> > I posted a patch to linux-arm-kernel which reworked the timing code.  The
> > existing is/was IMHO wrong and this showed up for me with frequency scaling
> > where the code would not keep the PCMCIA timings constant with changes to
> the
> > core frequency.  Here it is:
> > http://marc.info/?l=linux-arm-kernel&m=116861295404294&w=2
> 
>   I found out that drivers/pcmcia/pxa2xx_base.c from handhelds.org tree
> was a bit modified. I tried both vanilla kernel tree and vanilla+this
> patch -- both worked with pcnet_cs, and neither one with orinoco card.
> As far as I understand, handhelds.org modification makes use of memory
> clock instead of cpu clock for calculations. But even when using old
> handhelds.org driver with modified formulas, orinoco card won't
> initialize.
> 
What actually happens?  I'm using a spectrum24 and it works fine on my Zaurus
SL-C3100.  Is it trying to load the firmware?  I'm still using 2.6.20, so if
something has broken since I don't know about it.

>   I'm not really sure how things should be calculated, I'll try ask
> folks who modified the hh.org driverto see what could cause the
> problems.
> 
It is all detailed in the PXA2xx manuals.  I did try to enough details in my
comments to make sense of the calculation.  As was commented on when I posted
it, it isn't ideal since it uses divides which are relatively slow on ARMs.


Steve


      ___________________________________________________________ 
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good  http://uk.promotions.yahoo.com/forgood/environment.html

Re: [PATCH] pxa2xx PCMCIA timing issue on iPAQ H5550

[Milan Plzik]

On Pi, 2007-08-17 at 00:48 +0100, Steven Newbury wrote:
> --- Milan Plzik <milan.plzik@gmail.com> wrote:
> 
> > On Å t, 2007-08-09 at 16:06 +0100, Steven Newbury wrote:
> > > --- Milan Plzik <milan.plzik@gmail.com> wrote:
> > > 
> > > >   Good day,
> > > > 
> > > >   recently I've been trying to get working PCMCIA interface on H5000
> > > > ipaq series, using dual PCMCIA sleeve. So far things work correctly, but
> > > > I had to do one modification to drivers/pcmcia/pxa2xx_base.c to get the
> > > > interface working with orinoco gold PCMCIA card (wired pcnet_cs ethernet
> > > > card worked even without this modification). Patch attached.
> > > > 
> > > >   The issue has something to do with assert time on PCMCIA bus, but I'm
> > > > not really sure what -- I found the working value just by trial&error
> > > > approach. I'm not sure how is the assert value in pxa2xx_mcxx_asst
> > > > calculated (I know, simple formula, but the reason why is it calculated
> > > > that way is not obvious for me), neither that my modification is
> > > > correct. It just works with iPAQ. 
> > > > 
> > > I posted a patch to linux-arm-kernel which reworked the timing code.  The
> > > existing is/was IMHO wrong and this showed up for me with frequency scaling
> > > where the code would not keep the PCMCIA timings constant with changes to
> > the
> > > core frequency.  Here it is:
> > > http://marc.info/?l=linux-arm-kernel&m=116861295404294&w=2
> > 
> >   I found out that drivers/pcmcia/pxa2xx_base.c from handhelds.org tree
> > was a bit modified. I tried both vanilla kernel tree and vanilla+this
> > patch -- both worked with pcnet_cs, and neither one with orinoco card.
> > As far as I understand, handhelds.org modification makes use of memory
> > clock instead of cpu clock for calculations. But even when using old
> > handhelds.org driver with modified formulas, orinoco card won't
> > initialize.
> > 
> What actually happens?  I'm using a spectrum24 and it works fine on my Zaurus
> SL-C3100.  Is it trying to load the firmware?  I'm still using 2.6.20, so if
> something has broken since I don't know about it.

  The orinoco_cs driver fails to initialize the card, it doesn't read
proper value from SWSUPPORT0 register (or something like that, I don't
remember exactly). Driver sets some magic value there and expects to
read it back correctly, but that doesn't happen.

> 
> >   I'm not really sure how things should be calculated, I'll try ask
> > folks who modified the hh.org driverto see what could cause the
> > problems.
> > 
> It is all detailed in the PXA2xx manuals.  I did try to enough details in my
> comments to make sense of the calculation.  As was commented on when I posted
> it, it isn't ideal since it uses divides which are relatively slow on ARMs.

  Err, I did not mean your code, but handhelds.org one:). I need to ask
why it has been changed to the actual state -- precisely why it doesn't
use pxa core frequency, but memclk.

> 
> 
> Steve
> 
> 

	Milan

>       ___________________________________________________________ 
> Want ideas for reducing your carbon footprint? Visit Yahoo! For Good  http://uk.promotions.yahoo.com/forgood/environment.html