From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chen Baozi Subject: Re: Problems when using latest git tree to boot xen on OMAP5 Date: Wed, 9 Oct 2013 17:09:39 +0800 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> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1381306276.9920.21.camel@kazak.uk.xensource.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: Ian Campbell Cc: Julien Grall , List Xen Developer List-Id: xen-devel@lists.xenproject.org On Oct 9, 2013, at 4:11 PM, 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. I guess when TI implemented omap_hwmod, DT is still not widely accepted on ARM platform. So when omap_hwmod doing initialization, it doesn't follow ePAPR standard strictly. Maybe we can call this a historical issue? The TI people said they have addressed proposals that those resets will be removed to avoid our issue. But it seems this won't be too soon I guess... Cheers, Baozi > > 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? > > Ian. >