Hi Matteo,
On Wed, Mar 12, 2008 at 02:26:42AM +0100, Matteo Croce wrote:
> + switch (dev->divisor) {
> + case vlynq_div_auto:
> + /* Only try locally supplied clock, others cause problems */
i have a platform (AR7VWi - Leonardo Board) which has an external
supplied clock from an ACX111 so the div_auto autoprobing will not work.
I put the vlynq_div_external code in front of this which should
simply listen on the vlynq if there is a clock and use it. This solved
one of the issues for me. Can you elaborate on the above comment where
caused problems? I have seen multiple implementations of this, all of
them did autoprobing first by listening on the remote clock first.
> + vlynq_reg_write(dev->remote->control, 0);
> + for (i = vlynq_ldiv2; i <= vlynq_ldiv8; i++) {
> + vlynq_reg_write(dev->local->control,
> + VLYNQ_CTRL_CLOCK_INT |
> + VLYNQ_CTRL_CLOCK_DIV(i - vlynq_ldiv1));
> + if (vlynq_linked(dev)) {
> + printk(KERN_DEBUG
> + "%s: using local clock divisor %d\n",
> + dev->dev.bus_id, i - vlynq_ldiv1 + 1);
> + dev->divisor = i;
> + return 0;
> + }
> + }
What i found in the TI code is that FIRST the local->control needs to
get set before issueing a remote access so shouldnd the
vlynq_reg_write(dev->remote ... )
move behind the dev->local ? I mean the logic is to set a local clock
divisor - try to access something on the remote end and see if the link
got up ?!?
Flo
--
Florian Lohoff flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
signature.asc
Description: Digital signature
|