On 10/22/2014 04:20 PM, Russell King - ARM Linux wrote: > On Wed, Oct 22, 2014 at 04:01:26PM -0700, Stephen Boyd wrote: >> Where did this end up? When we talked at Connect I think we settled on >> exploring a driver core specific API like dev_get_localbus_address() >> that calls of_get_localbus_address() for devices with an of_node and in >> the future it could call something like acpi_get_localbus_address() when >> there's an acpi_node. I believe the biggest concern is that we're making >> an API that is OF or platform bus specific when it doesn't need to be. >> Making a driver core specific API avoids this problem by making it bus >> agnostic. > Given how little information there is in the original patch as to exactly > what problem this is addressing, I could be getting the wrong end of the > stick here. > > Is this about trying to have a way to obtain the bus local addresses > associated with CPU-view resources? > > If so, how about looking towards PCI, which has had this problem for the > last 15+ years, where PCI bus addresses are not necessarily the same as > CPU physical addresses? > > There, we don't end up with multiple addresses specified in resources. > We instead have a way to translate between resources and bus-local > addresses, which IMHO is far nicer and less error-prone than having to > specify the same information twice, once with an offset and once without. > Not really. This is about giving the address of a sub device on a pmic to a platform driver for that sub device. There is no CPU view. The addresses are offsets in a register space for a PMIC or other MFD that lives on i2c/spi or some similar sort of bus. So perhaps 0x20 corresponds to the start of the register space for an RTC and 0x38 corresponds to the start of the register space for a regulator. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
