Re: [PATCH] mtx-1: add udelay to mtx1_pci_idsel

[Bruno Randolf <br1@einfach.org>]

On 07/24/2012 08:08 PM, Manuel Lauss wrote:
> On Tue, Jul 24, 2012 at 5:36 PM, Manuel Lauss <manuel.lauss@gmail.com> wrote:
>> On Tue, Jul 24, 2012 at 5:25 PM, Bruno Randolf <br1@einfach.org> wrote:
>>> On 07/24/2012 04:20 PM, Manuel Lauss wrote:
>>>>
>>>> On Tue, Jul 24, 2012 at 5:13 PM, Bruno Randolf <br1@einfach.org> 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@einfach.org>
>>>>>> ---
>>>>>>     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.

Thanks! Honestly I don't understand it, but I know it works only that 
way... ;) I tried a longer delay after (up to 100us for sure) and 
unfortunately I don't have an oscilloscope to see the signals.

Bruno