On Tue, Jul 24, 2012 at 5:36 PM, Manuel Lauss <manuel.lauss@xxxxxxxxx> wrote: > On Tue, Jul 24, 2012 at 5:25 PM, Bruno Randolf <br1@xxxxxxxxxxx> wrote: >> On 07/24/2012 04:20 PM, Manuel Lauss wrote: >>> >>> On Tue, Jul 24, 2012 at 5:13 PM, Bruno Randolf <br1@xxxxxxxxxxx> wrote: >>>> >>>> Hello? Any feedback? >>>> >>>> I know the description is not very good, but this patch is necessary for >>>> PCI >>>> to work on the Surfbox. >>>> >>>> Thanks, >>>> bruno >>>> >>>> >>>> On 07/12/2012 09:54 PM, Bruno Randolf wrote: >>>>> >>>>> >>>>> Without this udelay(1) PCI idsel does not work correctly on the >>>>> "singleboard" >>>>> (T-Mobile Surfbox) for the MiniPCI device. The result is that PCI >>>>> configuration >>>>> fails and the MiniPCI card is not detected correctly. Instead of >>>>> >>>>> PCI host bridge to bus 0000:00 >>>>> pci_bus 0000:00: root bus resource [mem 0x40000000-0x4fffffff] >>>>> pci_bus 0000:00: root bus resource [io 0x1000-0xffff] >>>>> pci 0000:00:03.0: BAR 0: assigned [mem 0x40000000-0x4000ffff] >>>>> pci 0000:00:00.0: BAR 0: assigned [mem 0x40010000-0x40010fff] >>>>> pci 0000:00:00.1: BAR 0: assigned [mem 0x40011000-0x40011fff] >>>>> >>>>> We see only the CardBus device: >>>>> >>>>> PCI host bridge to bus 0000:00 >>>>> pci_bus 0000:00: root bus resource [mem 0x40000000-0x4fffffff] >>>>> pci_bus 0000:00: root bus resource [io 0x1000-0xffff] >>>>> pci 0000:00:00.0: BAR 0: assigned [mem 0x40000000-0x40000fff] >>>>> pci 0000:00:00.1: BAR 0: assigned [mem 0x40001000-0x40001fff] >>>>> >>>>> Later the device driver shows this error: >>>>> >>>>> ath5k 0000:00:03.0: cannot remap PCI memory region >>>>> ath5k: probe of 0000:00:03.0 failed with error -5 >>>>> >>>>> I assume that the logic chip which usually supresses the signal to the >>>>> CardBus >>>>> card has some settling time and without the delay it would still let the >>>>> Cardbus interfere with the response from the MiniPCI card. >>>>> >>>>> What I cannot explain is why this behaviour shows up now and not in >>>>> earlier >>>>> kernel versions before. Maybe older PCI code was slower? >>>>> >>>>> Signed-off-by: Bruno Randolf <br1@xxxxxxxxxxx> >>>>> --- >>>>> arch/mips/alchemy/board-mtx1.c | 2 ++ >>>>> 1 file changed, 2 insertions(+) >>>>> >>>>> diff --git a/arch/mips/alchemy/board-mtx1.c >>>>> b/arch/mips/alchemy/board-mtx1.c >>>>> index 295f1a9..e107a2f 100644 >>>>> --- a/arch/mips/alchemy/board-mtx1.c >>>>> +++ b/arch/mips/alchemy/board-mtx1.c >>>>> @@ -228,6 +228,8 @@ static int mtx1_pci_idsel(unsigned int devsel, int >>>>> assert) >>>>> * adapter on the mtx-1 "singleboard" variant. It triggers a >>>>> custom >>>>> * logic chip connected to EXT_IO3 (GPIO1) to suppress IDSEL >>>>> signals. >>>>> */ >>>>> + udelay(1); >>>>> + >>>>> if (assert && devsel != 0) >>>>> /* Suppress signal to Cardbus */ >>>>> alchemy_gpio_set_value(1, 0); /* set EXT_IO3 OFF */ >>>>> >>> >>> Why don't you increase the delay value in the udelay() immediately >>> following >>> this part? >> >> >> Yes that would be logical and was my first try. Unfortunately it does not >> work. It's weird, but the delay needs to be before as well. > > I don't get it. I suppose the activation phase of the signal is too short, yes? > Maybe a _much_ larger value (100/1000) would do the trick? Do you have an > oscilloscope to check the duty cycle? Ignore that. After thinking more about it (and remembering VHDL/Verilog classes) I now understand what's going on and the original patch is okay. Manuel
