From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 75CDDE008D7; Mon, 13 Jul 2015 09:04:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mx2.mail.bg (mx2.mail.bg [193.201.172.118]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 216A5E00895 for ; Mon, 13 Jul 2015 09:04:36 -0700 (PDT) Received: from [192.168.0.62] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.mail.bg (Postfix) with ESMTPSA id F208C60009A9; Mon, 13 Jul 2015 19:04:34 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1436803475; bh=jQ3zrokH1DAt/MsIIR0E9uEVwKt0iFAHinIqhuWZjVQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=8L8iYFN91x1cuQDEsOSfsT1/1VktzkB9HBWiBfz/3DMTdkS0GkdP3EEt9WqW/3e8r ztgQVuEQSQjBuLlvKk99/AfymkWV55ai3ZVZz+J+VKzkgYKNxYw8Ev5KNDxX+DT3mq 2olbn0nQkxzTCy5xpryPGhbqc0/ElrZZWQG3dnJs= Message-ID: <55A3E192.2030700@mail.bg> Date: Mon, 13 Jul 2015 19:04:34 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Gary Thomas , meta-freescale@yoctoproject.org References: <406TgmPNY6832S04.1436800490@web04.cms.usa.net> <55A3D6D3.4050109@mlbassoc.com> <55A3DF01.5000808@mlbassoc.com> In-Reply-To: <55A3DF01.5000808@mlbassoc.com> Subject: Re: Device tree question X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 16:04:40 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Gary, On 07/13/2015 06:53 PM, Gary Thomas wrote: > On 2015-07-13 09:18, Gary Thomas wrote: >> On 2015-07-13 09:14, Robin Findley wrote: >>> On 07/13/2015 10:37 AM, Gary Thomas wrote: >>>> A bit off topic, but perhaps someone here knows the answer :-) >>>> >>>> If my device tree has a device/element that is enabled, why would >>>> that device be disabled when I boot? I have this on my (LS1021) board: >>>> quadspi@1550000 { >>>> compatible = "fsl,ls1-qspi"; >>>> #address-cells = <0x00000001>; >>>> #size-cells = <0x00000000>; >>>> reg = <0x00000000 0x01550000 0x00000000 0x00010000 >>>> 0x00000000 >>> 0x40000000 0x00000000 0x04000000>; >>>> reg-names = "QuadSPI", "QuadSPI-memory"; >>>> interrupts = <0x00000000 0x00000083 0x00000004>; >>>> clock-names = "qspi_en", "qspi"; >>>> clocks = <0x00000003 0x00000001 0x00000003 0x00000001>; >>>> big-endian; >>>> amba-base = <0x40000000>; >>>> num-cs = <0x00000002>; >>>> status = "okay"; >>>> s70fl01gs@0 { >>>> #address-cells = <0x00000001>; >>>> #size-cells = <0x00000001>; >>>> compatible = "spansion,s70fl01gs"; >>>> spi-max-frequency = <0x02faf080>; >>>> reg = <0x00000000>; >>>> partition@0 { >>>> label = "s70fl01gs-0"; >>>> reg = <0x00000000 0x04000000>; >>>> }; >>>> }; >>>> }; >>>> >>>> However when I boot the system, this device is disabled. >>>> # cat /proc/device-tree/soc/quadspi@1550000/status >>>> disabled >>>> I know this must happen very early on as the device driver >>>> for this device is never even probed. >>>> >>>> Any ideas where/why this becomes disabled and how I keep that >>>> from happening? >>> >>> >>> Have you checked the rest of your device tree files (top-level and >>> includes) >>> to see if quadspi is referenced anywhere else? A later assignment can >>> override an earlier one. >> >> Yes and no, there are no overrides. >> >> Besides, the listing above is from dumping the compiled device >> tree using fdtdump, so includes and multiple sections addressing >> the same element have been collapsed. > > I found the culprit! My quadspi element was being disabled > by U-Boot (not sure why, this was just part of the LS102x common code) > That's cool. I was just about to suggest you to debug your driver's probe function :D. Have a great day! Regards, Nikolay