[PATCH v6 15/20] tegra: fdt: Add function to return peripheral/clock ID

Simon Glass sjg at chromium.org
Wed Feb 29 05:44:05 EST 2012


Hi Stephen,

On Tue, Feb 28, 2012 at 10:37 AM, Stephen Warren <swarren at nvidia.com> wrote:
> Simon Glass wrote at Tuesday, February 28, 2012 10:46 AM:
>> On Mon, Feb 27, 2012 at 3:41 PM, Stephen Warren <swarren at nvidia.com> wrote:
>> > On 02/27/2012 01:52 PM, Simon Glass wrote:
>> >> A common requirement is to find the clock ID for a peripheral. This is the
>> >> second cell of the 'clocks' property (the first being the phandle itself).
>> >
>> >> +int clock_decode_periph_id(const void *blob, int node)
>> >
>> >> +     valid = clock_periph_id_isvalid(id);
>> >
>> > clock_periph_id_isvalid() is not the correct function to use here; the
>> > code should be checking for invalid IDs in the CAR binding, not invalid
>> > IDs in the HW periph ID definition. They're different.
>> >
>> > Just to be explicit, the function you need here would be:
>> >
>> > int clkid_to_periphid(int clkid)
>> > {
>> >    if (clk_id > 95)
>> >        return -1;
>> >    switch (clk_id) {
>> >    case 1:
>> >    case 2:
>> >    case 7:
>> >    case 10:
>> >    case 20:
>> >    case 30:
>> >    case 35:
>> >    case 49:
>> >    case 56:
>> >    case 74:
>> >    case 77:
>> >    case 78:
>> >    case 79:
>> >    case 80:
>> >    case 81:
>> >    case 82:
>> >    case 83:
>> >    case 91:
>> >    case 95:
>> >        return -1;
>> >    default:
>> >        return clkid;
>> >    }
>> > }
>>
>> Ick.
>>
>> Why is 7 in there,
>
> 7 affects both the UART2 and VFIR clocks/blocks.
>
>> and did you miss 76?
>
> No, that's the undocumented "la" clock.
>
>> Also U-Boot only goes up to 88
>> at present so should I change the first test to match?
>
> No, clocks 89, 90, 92, 93, and 94 are defined in the binding, which
> matches the CLK_OUT_ENB registers in the Tegra CAR HW (albeit not the
> CLK_RST registers, since there are some differences between the two).

For both of your comments, since they aren't used in U-Boot, wouldn't
it be more correct to flag these as errors also? We would have to
update at least the clock.h header to support them.

Regards,
Simon

>
> --
> nvpublic
>


More information about the devicetree-discuss mailing list