From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Jul 2012 23:23:03 +0200 (CEST) Received: from postler.einfach.org ([86.59.21.13]:55474 "EHLO postler.einfach.org" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1903509Ab2GXVWz (ORCPT ); Tue, 24 Jul 2012 23:22:55 +0200 Received: from [192.168.2.106] (79.Red-193-153-81.dynamicIP.rima-tde.net [193.153.81.79]) by postler.einfach.org (Postfix) with ESMTPSA id DDC9221421EB; Tue, 24 Jul 2012 23:22:48 +0200 (CEST) Message-ID: <500F1226.1070500@einfach.org> Date: Tue, 24 Jul 2012 22:22:46 +0100 From: Bruno Randolf User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Manuel Lauss CC: linux-mips@linux-mips.org, manuel.lauss@googlemail.com, ralf@linux-mips.org, florian@openwrt.org Subject: Re: [PATCH] mtx-1: add udelay to mtx1_pci_idsel References: <1342126445-13408-1-git-send-email-br1@einfach.org> <500EBB99.5050209@einfach.org> <500EBE6F.5030208@einfach.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 33970 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: br1@einfach.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips Return-Path: On 07/24/2012 08:08 PM, Manuel Lauss wrote: > On Tue, Jul 24, 2012 at 5:36 PM, Manuel Lauss wrote: >> On Tue, Jul 24, 2012 at 5:25 PM, Bruno Randolf wrote: >>> On 07/24/2012 04:20 PM, Manuel Lauss wrote: >>>> >>>> On Tue, Jul 24, 2012 at 5:13 PM, Bruno Randolf 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 >>>>>> --- >>>>>> 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