Sonic, In PCMCIA mode the Pull-Up is right - and doesn't need to be changed.
BUG: [uclinux-dist Bugs Item #5374] Bluetooth kernel crashed in bf537-stamp with cf extender Is caused by the CONFIG_DEBUG_SHIRQ option being enabled. The bluecard_cs card service driver is not prepared for spurious interrupts caused by CONFIG_DEBUG_SHIRQ. So the bluecard_cs card service driver needs to be fixed. Return IRQ_NONE instead of BUG_ON(). -Michael >-----Original Message----- >From: Zhang, Sonic >Sent: Tuesday, July 21, 2009 11:33 AM >To: Hennerich, Michael; Song, Barry; Mike Frysinger >Cc: [email protected]; [email protected] >Subject: RE: [Linux-kernel-commits] [6960] trunk/drivers/ata/libata-core.c:1. > >Then, how to deal with the bluetooth CF interface? Which PIN should be pull >down? > >Sonic > >-----Original Message----- >From: [email protected] >[mailto:linux-kernel-commits- >[email protected]] On Behalf Of Hennerich, Michael >Sent: Tuesday, July 21, 2009 4:53 PM >To: Song, Barry; Mike Frysinger >Cc: [email protected]; [email protected] >Subject: Re: [Linux-kernel-commits] [6960] trunk/drivers/ata/libata-core.c:1. > >Hi Barry, > >I don't understand. >Why do you think CPLD Interrupt Output Tristate (Blackfin GPIO INT) would help >here? >The GPIO interrupt would be floating, when not driven active! >And I'm not aware of dedicated Pull/Ups/Downs on the STAMP board itself. > >Did you add the resistor to the IDE_INTRQ on the IDE connector? >For me this workaround works perfectly. >See attached picture. > >For the CF-Card slot this won't work - since when used in TRUE IDE MODE we >need a Pull Down - and >otherwise a Pull Up. > >Answering your question - >The CPLD logic schematic sheets are also available on GFORGE. > >The Logic Relationship between >IDE_INTRQ and BFIN_GPIO2 (PF5) is simple > >IDE_INTRQ = BFIN_GPIO2 > > >-Michael > > > >________________________________________ >From: Song, Barry >Sent: Tuesday, July 21, 2009 9:22 AM >To: Hennerich, Michael; Mike Frysinger >Cc: [email protected]; [email protected] >Subject: RE: [Linux-kernel-commits] [6960] trunk/drivers/ata/libata-core.c: 1. > >Hi Michael, >What's the logic relationship between the CF/ATA signals and signals to >blackfin you set in the CPLD? >Even after we connect a 1000Ohm res to ground, the interrupt output to >blackfin is still high. It >seems the CPLD is outputing high but not keep tristate in default status. So >we have to keep the >probe-polling patch until the CPLD logic is fixed. >Thanks >Barry > >-----Original Message----- >From: Hennerich, Michael [mailto:[email protected]] >Sent: Friday, July 10, 2009 11:18 PM >To: Mike Frysinger >Cc: [email protected]; [email protected] >Subject: RE: [Linux-kernel-commits] [6960] trunk/drivers/ata/libata-core.c: 1. > > >>it sounds like we just have to pop off a resistor ? > >Well not that easy - I used a 0603 type 10k Resistor Pack including 4 >resistors. > >One trick could be to leave the PULL-Ups as is and add a stronger Pull-Down to >the INTRQ - lets say >something between 500 Ohm and 1kOhm . > >-Michael > >>-----Original Message----- >>From: Mike Frysinger [mailto:[email protected]] >>Sent: Friday, July 10, 2009 5:07 PM >>To: Hennerich, Michael >>Cc: [email protected]; >[email protected] >>Subject: Re: [Linux-kernel-commits] [6960] >trunk/drivers/ata/libata-core.c: 1. >> >>On Fri, Jul 10, 2009 at 11:00, Hennerich, Michael wrote: >>> I think this issue is caused by a Pull-Up resistor on the INTRQ line >on >>> the CF-IDE-NAND Card. >>> >>> Read this: >>> http://www.mail-archive.com/[email protected]/msg00418.html >>> >>> On the CF Card socket we also have that pull-up - but there we had no >>> choice since in PC-Card IO mode the Interrupt is asserted Low. So >this >>> was a tradeoff, and at the time doing the card - it worked without >>> errors. >>> >>> The problem here is that the INTRQ signal output line has a high >>> impedance when no devices are selected or interruption is disabled. >>> >>> Like you noticed, recent Linux libata assumes the INTRQ staying >inactive >>> the time between the IRQ is requested and the device is configured. >>> >>> If this fix isn't acceptable to mainline we should revert - and fix >the >>> HW. >> >>can the simple instructions of how to patch the card be added to the >>wiki ? it sounds like we just have to pop off a resistor ? >>-mike _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
