[U-Boot] Fw: Re: Re: [PATCH] add u-boot sja1000/can support

[miaofng <miaofng@gmail.com>]

Hi mike,
It seems there's a big difference between my current project
and u-boot common usage. I can only enjoy the patch myself now

i want to get a packet from usb/network, then redirect it to can bus.
So blocked write/read of can is not allowed.

On Monday 26 October 2009 00:48:39 miaofng wrote:
> Thanks for careful review. I'll resend the patch according to your remarks
>  except follwing: 1)
> 
> > +int register_candev(struct can_device *dev)
> 
> use "can" or "candev", dont mix the two
> 
> answer: register_candev is origin from register_netdev(...). CAN is
>  something like network, it may has high level protocols such as open-can
>  and etc, so i want to keep that story.
i know what CAN is.  the Linux approach makes sense because they've 
architected CAN at the socket() layer, and all of the network layers are 
written with common coding style.  but there is no such socket/network layer 
in u-boot so the can/candev distinction isnt necessary.
> > +int sja1000_interrupt(struct can_device *dev)
> 
> u-boot is a polled architecture, not an interrupt based one.  i guess this
> driver needs rewriting to do that.
> 
> answer: no, i want to keep that structure. Then linux drivers can be ported
>  to u-boot easily. take an example, in sja1000, i only need to replace
>  "_net" to "_can" at most of time. To gain this convience, i added the wrap
>  layer of can_core.c.
the convenience factor doesnt mean you can ignore u-boot design principles.  
the default behavior for all frameworks/drivers is a polled mode because it's 
simple and straightforward.  not all u-boot ports even support interrupts
>  In order to work in u-boot polled mode, people only
>  need to call sja1000_interrupt periodly. It works fine on my board.
erm, no, that's not how things work in u-boot.  u-boot processes commands 
given to it (either via scripts or from user input), and each command does not 
return until it is completely done processing.  there is no "backgrounding" of 
drivers -- u-boot is not an OS and it is not threaded.  that means any CAN 
operation does not return until it has finished sending/receiving everything 
it was told to.
-mike