[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Problems when using latest git tree to boot xen on OMAP5
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@xxxxxxxxxxxxxxxx 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? Baozi. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |