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? Manuel
