Re: [PATCH v2 3/5] ARM: bcm2835: add rpi power domain driver

[Kevin Hilman]

Hi Eric,

Eric Anholt <eric@xxxxxxxxxx> writes:

> Kevin Hilman <khilman@xxxxxxxxxx> writes:
>
>> Eric Anholt <eric@xxxxxxxxxx> writes:
>>
>>> From: Alexander Aring <alex.aring@xxxxxxxxx>
>>>
>>> This patch adds support for several power domains on Raspberry Pi,
>>> including USB (so it can be enabled even if the bootloader didn't do
>>> it), and graphics.
>>>
>>> This patch is the combined work of Eric Anholt (who wrote USB support
>>> inside of the Raspberry Pi firmware driver, and wrote the non-USB
>>> domain support) and Alexander Aring (who separated the original USB
>>> work out from the firmware driver).
>>>
>>> Signed-off-by: Alexander Aring <alex.aring@xxxxxxxxx>
>>> Signed-off-by: Eric Anholt <eric@xxxxxxxxxx>
>>> ---
>>>
>>> v2: Add support for power domains other than USB, using the new
>>>     firmware interface, reword commit message (changes by Eric)
>>
>> [...]
>>
>>> +/*
>>> + * Firmware indices for the old power domains interface.  Only a few
>>> + * of them were actually implemented.
>>> + */
>>> +#define RPI_OLD_POWER_DOMAIN_USB		3
>>> +#define RPI_OLD_POWER_DOMAIN_V3D		10
>>> +
>>
>> Is "old" the right word here?  Are there firmware versions that could be
>> used instead?  What happens when the firwmware is updated next time?
>
> Old is a good word.  It's the old interface.

Sure, but "old" is relative and based on experience, folks come to
regret those kinds of names.

> As for what happens when the firmware is updated: Nothing.  The firmware
> is updated all the time, and it maintains backwards compatibility.
> Unless you mean "what happens when a newer, fancier power domain
> interface is created and we need a name for the newer one" and the
> answer is "this is a define entirely within the driver, and we can just
> rename it when we want to."

Sure, it's very contained in this driver, so it's ultimately up to you.
It's not something worth blocking this about, I just wanted to be sure
since I'm not very familiar with how the rpi firmware evolves.

>> [...]
>>
>>> +	/*
>>> +	 * Use the old firmware interface for USB power, so that we
>>> +	 * can turn it on even if the firmware hasn't been updated.
>>> +	 */
>>> +	rpi_init_old_power_domain(rpi_domains, RPI_POWER_DOMAIN_USB,
>>> +				  RPI_OLD_POWER_DOMAIN_USB, "USB");
>>
>> This seems a bit restrictive.
>>
>> To me, it seems that determining "old" or "new" (or revision of fw
>> interface to use) should be described in DT, not hard-coded in the power
>> domain driver.
>>
>> What about an additional DT property to describe that? or possibly
>> another cell in the domain which could be used to optionally set
>> old/legacy.
>
> As the author and maintainer of the code, I don't feel it's restrictive.
> The firmware protocol is defined and is guaranteed to continue to exist,
> it's only useful for this platform, and defining a new set of custom
> devicetree properties for it would only obfuscate the implementation.
> DT is a useful tool for separating out the between-board differences for
> the same piece of hardware across multiple implementations at different
> addresses, while this is neither hardware nor in multiple
> implementations at different addresses.

That being said, firmware revisions are also very often something that
qualifies as a difference between boards.

Anyways, as I said above, I think this is a potential future problem,
but it's not a big deal to me since it's very self contained.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/