Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 31 December 2014 at 19:22, Rob Herring <robherring2@xxxxxxxxx> wrote:
> On Wed, Dec 31, 2014 at 10:13 AM, Peter Maydell
> <peter.maydell@xxxxxxxxxx> wrote:
>> Why would you want to get the bootloader to do this for you when
>> the hardware provides a perfectly good mechanism for probing
>> for the existence of the hardware? "Ask the hardware" is always
>> going to be a more reliable and foolproof way to get the answer
>> if you can do it -- device tree should just be for the cases where
>> there is no way to probe. In any case the only way for the boot
>> loader to determine the correct value to put into the device tree
>> would be to read the register itself.
>
> Only that it is nice to hide all the ugly bits in the
> bootloader/firmware and DT already provides a standard way to enable
> or disable h/w. This h/w is not probeable in any sort of standard way.

This is an embedded system, you were expecting some kind of
standard? :-) I believe that SYS_PCICTL tells you whether
you're going to find the PCI controller or a decode error
at the addresses in the memory map where the PCI controller
usually lives, so robustness suggests it's worth retaining
the check in the kernel. [I'd want to check this on hardware
but my current belief is that if there's no backplane attached
then the register will read zero and the PCI controller register
space will abort with decode errors.]

> From Table 4.4, I came to the conclusion that the write wasn't really necessary:
>
> SYS_PCICTL  0x10000044  Read only  -Read returns a HIGH in bit [0] if
> a PCI board is present in the expansion backplane.
>
> I'll add it back.

The self-contradictory VersatilePB docs strike again, I see.
Interestingly, in the PB1176 docs this register is documented
as definitely read/only:

# [1]Read only: Reserved.
#
# Note
#
# On the RealView Platform Baseboard for ARM926EJ-S, this bit
# was PCICONTROLIN signal and indicated that 66MHz mode was
# enabled. The PB1176JZF-S only supports 33MHz operation.
#
# [0]Read only: Status of P_DETECT pin.

...and in passing provides some info about the 926 board that
isn't in the docs for the 926!

A little digging suggests that it may in fact be the case
that the 1176 docs are correct and the write to bit 0 does
nothing. However the safest thing here is to keep doing
what the old kernel did, I think.

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux