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

[Julien Grall <julien.grall@linaro.org>]

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.

-- 
Julien Grall