Hi Stephen,
On Tue, Feb 28, 2012 at 10:37 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote:
> Simon Glass wrote at Tuesday, February 28, 2012 10:46 AM:
>> On Mon, Feb 27, 2012 at 3:41 PM, Stephen Warren <swarren@xxxxxxxxxx> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
