From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vaibhav Bedia Subject: Re: Problems when using latest git tree to boot xen on OMAP5 Date: Thu, 10 Oct 2013 08:04:28 -0400 Message-ID: References: <936C837B-7005-4CE0-8265-7B7ACA7C78FD@gmail.com> <91879A6F-B459-4D10-A691-4A04915D82AA@gmail.com> <1381135195.21562.56.camel@kazak.uk.xensource.com> <525285B3.8010902@gmail.com> <52529404.8030909@linaro.org> <20131009074627.GA6342@cbz-workstation> <1381306276.9920.21.camel@kazak.uk.xensource.com> <20131010080524.GA10303@cbz-workstation> <52568A55.4030800@linaro.org> <5B6083DE-40DA-40C7-B809-0AFC9403E5EC@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5B6083DE-40DA-40C7-B809-0AFC9403E5EC@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Chen Baozi Cc: Julien Grall , Ian Campbell , List Xen Developer List-Id: xen-devel@lists.xenproject.org Hi, On Thu, Oct 10, 2013 at 7:36 AM, Chen Baozi wrote: > > On Oct 10, 2013, at 7:07 PM, Julien Grall wrote: > >> On 10/10/2013 09:05 AM, Chen Baozi wrote: >>> On Wed, Oct 09, 2013 at 09:11:16AM +0100, Ian Campbell wrote: >>>> On Wed, 2013-10-09 at 15:46 +0800, Chen Baozi wrote: >>>>> On Mon, Oct 07, 2013 at 11:59:16AM +0100, Julien Grall wrote: >>>>>> On 10/07/2013 10:58 AM, Chen Baozi wrote: >>>>>>> On 10/07/2013 04:39 PM, Ian Campbell wrote: >>>>>>>> >>>>>>>> It is certainly a bug in the kernel if it is accessing something which >>>>>>>> is disabled. It may also independently be a bug in the dts that this >>>>>>>> devices is disabled. >>>>>>>> >>>>>>>> However in v3.12-rc4 I don't see mmc@480d1000 being disabled in >>>>>>>> omap5-uevm.dts and I can't see anything in the history of that file >>>>>>>> either. Where did your copy come from? >>>>>>> >>>>>>> I'm currently working on the "omap5-v3.11-rc3" branch from >>>>>>> git://github.com/rogerq/linux.git, which contains a few necessary >>>>>>> platform patches not upstreamed. In omap5-uevm.dts, there are lines like: >>>>>>> >>>>>>> 253 &mmc4 { >>>>>>> 254 status = "disabled"; >>>>>>> 255 }; >>>>>>> 256 >>>>>>> 257 &mmc5 { >>>>>>> 258 status = "disabled"; >>>>>>> 259 }; >>>>>>> >>>>>>> the mmc4 refers to mmc@480d1000, which defines at omap5.dtsi: >>>>>>> >>>>>>> 417 mmc4: mmc@480d1000 { >>>>>>> >>>>>>> I checked Linus' mainline git tree. It is the same about disabled mmc4 >>>>>>> in omap5-uevm.dts. And the change is introduced in commit 5dd18b0 of the >>>>>>> mainline kernel. >>>>>>> >>>>>>> Anyway, I'll see what exactly happened in the dom0 kernel dealing with >>>>>>> those "disabled" regions. >>>>>> >>>>>> I looked at the Linux code. It will populate the different devices via >>>>>> the of_platform_populate (drivers/of/platform.c). >>>>>> >>>>>> This function checks in of_platform_create_pdata if the device is >>>>>> available. So the mmc driver (driver/mmc/host/omap_hsmmc.c) should not >>>>>> be called for mmc4. >>>>> >>>>> I've discuessed this issue on linux-omap@vger.kernel.org. The TI guy says >>>>> that "DT disabled" means that device won't be created but hwmod bus >>>>> initially would try to initialize all supported modules by doing reset >>>>> access in their io memory address regions. That's why dom0 have accessed >>>>> mmc4 address even though it has been disabled. >>>> >>>> ePAPR lists the option of "status = fail" which is "Indicates that the >>>> device is not operational. A serious error was detected in the device, >>>> and it is unlikely to become operational without repair." I'm not sure >>>> that is quite right though. >>>> >>>> Rather than whitelisting and mapping disabled devices through perhaps we >>>> should implement them as read 0xf (or 0x0) and write ignore? >>>> >>>> Or maybe we should just be mapping non-blacklisted disabled devices >>>> through to dom0, for it to use or ignore as it pleases. Julien, what was >>>> the reasoning here again? >>> >>> If we just simple don't pass the disabled node in DT to the dom0, anything >>> inpropriate? >> >> Few mails ago, you said there is hardcoded access in Linux for OMAP, >> right? I don't think removing the node from the Device Tree will change >> something with this problem. > > Oh, I just had a assumption about hardcoded stuffs then. However, after discussed > with TI guys, it turns out I've just made a wrong assumption. There is no > hard-coding rather a different requirement why omap_hwmod accesses the module's > io memory space, according to their explanation. Sorry for not making it clear > when I got the new explanation. > I think most of the hardcoded access has been removed. Kernel would just try to access the modules that are listed in DT and then attemtp to do a soft-reset to get those modules to a known state. I am still trying to wrap my head around how Xen works but from what i understood so far the soft reset in both Dom0 and DomU is the problem here?