* [PATCH] mtx-1: add udelay to mtx1_pci_idsel
@ 2012-07-12 20:54 Bruno Randolf
2012-07-24 15:13 ` Bruno Randolf
0 siblings, 1 reply; 7+ messages in thread
From: Bruno Randolf @ 2012-07-12 20:54 UTC (permalink / raw)
To: linux-mips; +Cc: manuel.lauss, ralf, florian, br1
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 */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] mtx-1: add udelay to mtx1_pci_idsel
2012-07-12 20:54 [PATCH] mtx-1: add udelay to mtx1_pci_idsel Bruno Randolf
@ 2012-07-24 15:13 ` Bruno Randolf
2012-07-24 15:20 ` Manuel Lauss
0 siblings, 1 reply; 7+ messages in thread
From: Bruno Randolf @ 2012-07-24 15:13 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linux-mips, manuel.lauss, ralf, florian
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 */
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] mtx-1: add udelay to mtx1_pci_idsel
2012-07-24 15:13 ` Bruno Randolf
@ 2012-07-24 15:20 ` Manuel Lauss
2012-07-24 15:25 ` Bruno Randolf
0 siblings, 1 reply; 7+ messages in thread
From: Manuel Lauss @ 2012-07-24 15:20 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linux-mips, manuel.lauss, ralf, florian
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?
Manuel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] mtx-1: add udelay to mtx1_pci_idsel
2012-07-24 15:20 ` Manuel Lauss
@ 2012-07-24 15:25 ` Bruno Randolf
2012-07-24 15:36 ` Manuel Lauss
0 siblings, 1 reply; 7+ messages in thread
From: Bruno Randolf @ 2012-07-24 15:25 UTC (permalink / raw)
To: Manuel Lauss; +Cc: linux-mips, manuel.lauss, ralf, florian
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.
bruno
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] mtx-1: add udelay to mtx1_pci_idsel
2012-07-24 15:25 ` Bruno Randolf
@ 2012-07-24 15:36 ` Manuel Lauss
2012-07-24 19:08 ` Manuel Lauss
0 siblings, 1 reply; 7+ messages in thread
From: Manuel Lauss @ 2012-07-24 15:36 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linux-mips, manuel.lauss, ralf, florian
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?
Manuel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] mtx-1: add udelay to mtx1_pci_idsel
2012-07-24 15:36 ` Manuel Lauss
@ 2012-07-24 19:08 ` Manuel Lauss
2012-07-24 21:22 ` Bruno Randolf
0 siblings, 1 reply; 7+ messages in thread
From: Manuel Lauss @ 2012-07-24 19:08 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linux-mips, manuel.lauss, ralf, florian
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.
Manuel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] mtx-1: add udelay to mtx1_pci_idsel
2012-07-24 19:08 ` Manuel Lauss
@ 2012-07-24 21:22 ` Bruno Randolf
0 siblings, 0 replies; 7+ messages in thread
From: Bruno Randolf @ 2012-07-24 21:22 UTC (permalink / raw)
To: Manuel Lauss; +Cc: linux-mips, manuel.lauss, ralf, florian
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-07-24 21:23 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-12 20:54 [PATCH] mtx-1: add udelay to mtx1_pci_idsel Bruno Randolf
2012-07-24 15:13 ` Bruno Randolf
2012-07-24 15:20 ` Manuel Lauss
2012-07-24 15:25 ` Bruno Randolf
2012-07-24 15:36 ` Manuel Lauss
2012-07-24 19:08 ` Manuel Lauss
2012-07-24 21:22 ` Bruno Randolf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox