Re: [Xen-devel] Problems when using latest git tree to boot xen on OMAP5

[Chen Baozi <baozich@xxxxxxxxx>]

On Oct 9, 2013, at 4:11 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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.

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.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel