Re: Problems when using latest git tree to boot xen on OMAP5

[Ian Campbell <Ian.Campbell@citrix.com>]

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?

Ian.