On 04/03/2012 04:29 PM, AnilKumar, Chimata wrote: >>>> Please explain why this CAN controller cannot be handled by the existing >>>> C_CAN driver, eventually with some extensions. The register layout seems >>>> almost identical, at least. >>>> >>>> Wolfgang. >>>> >>> >>> These are the some of the pointers I can say, why I had gone for separate >>> file instead of existing driver: >>> * In case of D_CAN driver we can see all the registers are 32bit length >>> but in case of C_CAN registers are in 16bit length. >> >> How many bits in these 32 bit registers are used? > > In some cases (D_CAN_TXRQ, D_CAN_INTPND, D_CAN_MSGVAL) I have used all the > bits, in some cases used few bits. > > Roughly I can say that its (higher 16bits) % of usages is similar as compare > to 16bits > > While checking the status of TXRequest registers and INT pending register, > which is a hot code path, we have to put if checks for register access. The c_can already has a c_can_read_reg32() function. It's for example used in the rx_poll function. You can make it a function pointer (i.e. pric->read_reg32()) for easy abstraction. >>> * Some of the registers, bit masks are different, so we have to add >>> checks on every API for differentiating the kind of device >> >> Which registers are this? Can you give us an example? > > I am pointing out some of the resisters > * Single registers in case of D_CAN but multiple register in case of C_CAN > So masks will change MASK, ARB, INTPND > * D_CAN_IFCMD is the combination of COMM request and COMM mask registers Maybe you can use the read_reg32 function on both c_can and d_can. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Attachment:
signature.asc
Description: OpenPGP digital signature
