Michael,
Thanks a lot!
Barry
-----Original Message-----
From: Hennerich, Michael
Sent: Tuesday, July 21, 2009 6:54 PM
To: Song, Barry; 'Mike Frysinger'
Cc: '[email protected]'; '[email protected]'
Subject: RE: [Linux-kernel-commits] [6960] trunk/drivers/ata/libata-core.c: 1.
>Is it possible for you to point out the direction for all related
>CF/IDE/Bluetooth pins in CPLD and "and/or/not" logic between them. We can't
>figure out them only by checking the schematics.
Barry,
When I said CPLD schematics I didn't meant the CF-IDE-NAND card schematics!
I would say the CPLD schematics are easier to read as those equations below.
-Michael
BF_ARDY <= (CF_WAIT_IORDY AND IDE_IORDY);
BF_GPIO0 <= nNAND_RB;
BF_GPIO1 <= CF_INT_WAIT;
BF_GPIO2 <= IDE_INTRQ;
BF_GPIO3 <= (NOT nCF_CD2 AND NOT nCF_CD1);
CF_A0 <= BF_A13;
CF_RESET <= NOT (XLXI_14/XLXN_794
XOR
CF_RESET <= NOT (nBF_RESET);
NAND_AL <= BF_A1;
NAND_CL <= BF_A2;
FDCPE_XLXI_14/XLXN_794: FDCPE port map
(XLXI_14/XLXN_794,BF_A1,XLXI_14/XLXN_794_C,NOT nBF_RESET,'0');
XLXI_14/XLXN_794_C <= (NOT BF_A15 AND NOT nBF_AMS3 AND BF_A16 AND BF_A12 AND
BF_A11 AND
NOT nBF_AWE);
FDCPE_XLXI_302/XLXN_100: FDCPE port map
(XLXI_302/XLXN_100,XLXI_302/XLXN_100_D,G_CLK,'0','0');
XLXI_302/XLXN_100_D <= ((NOT nBF_AMS3 AND NOT nBF_AWE)
OR (NOT nBF_AMS2 AND NOT nBF_AWE));
FDCPE_XLXI_302/XLXN_57: FDCPE port map
(XLXI_302/XLXN_57,XLXI_302/XLXN_57_D,G_CLK,'0','0');
XLXI_302/XLXN_57_D <= ((NOT nBF_AMS3 AND NOT nBF_ARE)
OR (NOT nBF_AMS2 AND NOT nBF_ARE));
FDCPE_XLXI_302/XLXN_58: FDCPE port map
(XLXI_302/XLXN_58,XLXI_302/XLXN_58_D,G_CLK,'0','0');
XLXI_302/XLXN_58_D <= ((NOT XLXI_302/XLXN_57)
OR (nBF_AMS3 AND nBF_AMS2)
OR (nBF_AWE AND nBF_ARE));
FDCPE_XLXI_302/XLXN_99: FDCPE port map
(XLXI_302/XLXN_99,XLXI_302/XLXN_99_D,G_CLK,'0','0');
XLXI_302/XLXN_99_D <= ((NOT XLXI_302/XLXN_100)
OR (nBF_AMS3 AND nBF_AMS2)
OR (nBF_AWE AND nBF_ARE));
nCF_CE1_CS0 <= NOT (((NOT BF_A14 AND NOT nBF_AMS3 AND BF_A16 AND NOT BF_A12 AND
NOT BF_ABE0)
OR (NOT nBF_AMS3 AND BF_A16 AND BF_A12 AND NOT BF_A11 AND NOT BF_ABE0)
OR (BF_A16 AND BF_A12 AND BF_A11 AND NOT nBF_AMS2 AND NOT BF_ABE0)
OR (BF_A14 AND BF_A5 AND NOT BF_A4 AND BF_A15 AND NOT nBF_AMS3 AND
BF_A16)));
nCF_CE2_CS1 <= NOT (((NOT BF_A14 AND NOT nBF_AMS3 AND BF_A16 AND NOT BF_A12 AND
NOT BF_ABE1)
OR (NOT nBF_AMS3 AND BF_A16 AND BF_A12 AND NOT BF_A11 AND NOT BF_ABE1)
OR (BF_A16 AND BF_A12 AND BF_A11 AND NOT nBF_AMS2 AND NOT BF_ABE1)
OR (BF_A14 AND NOT BF_A5 AND BF_A4 AND BF_A15 AND NOT nBF_AMS3 AND
BF_A16)));
nCF_IORD <= NOT (((NOT nBF_AMS3 AND BF_A16 AND NOT BF_A12 AND NOT nIDE_DIOR)
OR (BF_A16 AND NOT BF_A12 AND NOT nBF_AMS2 AND NOT nIDE_DIOR)));
nCF_IOWR <= NOT (((NOT nBF_AMS3 AND BF_A16 AND NOT BF_A12 AND NOT nIDE_DIOW)
OR (BF_A16 AND NOT BF_A12 AND NOT nBF_AMS2 AND NOT nIDE_DIOW)));
nCF_OE <= NOT (((XLXI_14/XLXN_794)
OR (BF_A16 AND BF_A12 AND NOT nBF_AMS2 AND NOT nBF_ARE)
OR (NOT nBF_AMS3 AND BF_A16 AND BF_A12 AND nBF_AMS2 AND
NOT nIDE_DIOR)));
nCF_REG <= NOT ((NOT BF_A11 AND NOT XLXI_14/XLXN_794));
nCF_WE <= NOT (((BF_A16 AND BF_A12 AND NOT nBF_AMS2 AND NOT nBF_AWE)
OR (NOT nBF_AMS3 AND BF_A16 AND BF_A12 AND nBF_AMS2 AND
NOT nIDE_DIOW)));
nIDE_CS0 <= NOT ((BF_A14 AND BF_A5 AND NOT nBF_AMS3 AND BF_A16));
nIDE_CS1 <= NOT ((BF_A14 AND BF_A4 AND NOT nBF_AMS3 AND BF_A16));
FDCPE_nIDE_DIOR: FDCPE port map (nIDE_DIOR,nIDE_DIOR_D,G_CLK,'0','0');
nIDE_DIOR_D <= ((NOT XLXI_302/XLXN_58)
OR (nBF_AMS3 AND nBF_AMS2)
OR (nBF_AWE AND nBF_ARE));
FDCPE_nIDE_DIOW: FDCPE port map (nIDE_DIOW,nIDE_DIOW_D,G_CLK,'0','0');
nIDE_DIOW_D <= ((NOT XLXI_302/XLXN_99)
OR (nBF_AMS3 AND nBF_AMS2)
OR (nBF_AWE AND nBF_ARE));
nIDE_RESET <= nBF_RESET;
nNAND_Enable <= NOT ((BF_A13 AND BF_A16 AND NOT BF_A12 AND NOT BF_A11 AND NOT
nBF_AMS2));
nNAND_RD <= nBF_ARE;
nNAND_WP <= nBF_RESET;
nNAND_WR <= nBF_AWE;
nQS_BE <= (nBF_AMS3 AND nBF_AMS2);
>-----Original Message-----
>From: Song, Barry
>Sent: Tuesday, July 21, 2009 11:46 AM
>To: Hennerich, Michael; 'Mike Frysinger'
>Cc: '[email protected]'; '[email protected]'
>Subject: RE: [Linux-kernel-commits] [6960] trunk/drivers/ata/libata-core.c: 1.
>
>Ok. I see. Thanks.
>Is it possible for you to point out the direction for all related
>CF/IDE/Bluetooth pins in CPLD and
>"and/or/not" logic between them. We can't figure out them only by checking the
>schematics.
>Thanks
>Barry
>
>-----Original Message-----
>From: Hennerich, Michael
>Sent: Tuesday, July 21, 2009 5:43 PM
>To: Song, Barry; 'Mike Frysinger'
>Cc: '[email protected]'; '[email protected]'
>Subject: RE: [Linux-kernel-commits] [6960] trunk/drivers/ata/libata-core.c: 1.
>
>>I am pulling-down the interrupt output from CPLD to blackfin. It seems
>>you are connecting interrupt input from IDE to CPLD?
>
>The CPLD drives either LOW or HIGH - a Pull Down behind the CPLD is pointless!
>You need to add the Pull Down to the INTRQ input!
>
>-Michael
>
>>-----Original Message-----
>>From: Song, Barry
>>Sent: Tuesday, July 21, 2009 11:32 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,
>>I am pulling-down the interrupt output from CPLD to blackfin. It seems
>>you are connecting interrupt input from IDE to CPLD? Is it? Then I will make
>>a try.
>>Thanks
>>Barry
>>
>>-----Original Message-----
>>From: 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
