On Thursday 26 February 2009, Kevin Hilman wrote: > How about this as a compromise, starting from this patch... > > This could be done in davinci_soc_init() or a new function in common.c: > > - drop the 'cpu_id' setting from the board files > - add 'jtag_id_base' and 'jtag_id' to davinci_soc_info > - read info->jtag_id_base to info->jtag_id > - add back something like the ids.c:davinci_ids[] to common.c, > but using your new defines as the 'type' field. > - use the jtag_id to set the cpu_id field
Seems plausible to me, but I don't have "this patch" any more. I'd have to see the combined result. Key point seems to be using *actual* chip ID info instead of static configuration that might not match the current minor revision of the board ... thereby keeping flexibility to handle chiprev changes affecting behavior. - Dave > For now, I don't think we need to bother with functions for reading > out the variant etc. Just checking the part_no and setting the cpu_id > accordingly should be fine for now. > > If, down the road, we need to get more CPU variant deatils, this could > be added to the <device>.c files as needed. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
