- 01 4月, 2014 2 次提交
-
-
由 Thomas Gleixner 提交于
We can avoid the HW access in TX cleanup path for retrieving the DLC of the sent package if we store the DLC in a private array. Ideally this should be handled in the can_echo_skb functions, but I leave that exercise to the CAN folks. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 Thomas Gleixner 提交于
The network core does not serialize the access to the hardware. The xmit related code lets the following happen: CPU0 CPU1 interrupt() do_poll() c_can_do_tx() Fiddle with HW and xmit() internal data Fiddle with HW and internal data due the complete lack of serialization. Add proper locking. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
- 27 11月, 2012 1 次提交
-
-
由 AnilKumar Ch 提交于
Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM, which holds all the message objects during transmission or receiving of data. This initialization/de-initialization should be done in synchronous with D_CAN clock. In case of AM335X-EVM (current user of D_CAN driver) message RAM is controlled through control module register for both instances. So control module register details is required to initialization or de-initialization of message RAM according to instance number. Control module memory resource is obtained from D_CAN dt node and instance number obtained from device tree aliases node. This patch was tested on AM335x-EVM along with pinctrl data addition patch, d_can dt aliases addition and control module data addition. pinctrl data addition is not added to am335x-evm.dts (only supports CPLD profile#0) because d_can1 is supported under CPLD profile#1. Signed-off-by: NAnilKumar Ch <anilkumar@ti.com> [mkl: fix instance for non DT in probe, cleaned up raminit] Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
- 22 9月, 2012 3 次提交
-
-
由 AnilKumar Ch 提交于
Adds suspend resume support to DCAN driver which enables DCAN power down mode bit (PDR). Then DCAN will ack the local power-down mode by setting PDA bit in STATUS register. Signed-off-by: NAnilKumar Ch <anilkumar@ti.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 AnilKumar Ch 提交于
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM APIs control clocks for C_CAN/D_CAN IP and prevent access to the register of C_CAN/D_CAN IP when clock is turned off. Signed-off-by: NAnilKumar Ch <anilkumar@ti.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 AnilKumar Ch 提交于
Modify c_can device names from *_CAN_DEVTYPE to BOSCH_*_CAN to make use of same names for array indexes in c_can_id_table[] as well as device names. This patch also add indexes to c_can_id_table array. Signed-off-by: NAnilKumar Ch <anilkumar@ti.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
- 07 6月, 2012 2 次提交
-
-
由 AnilKumar Ch 提交于
This patch adds the support for D_CAN controller driver to the existing C_CAN driver. Bosch D_CAN controller is a full-CAN implementation which is compliant to CAN protocol version 2.0 part A and B. Bosch D_CAN user manual can be obtained from: http://www.semiconductors.bosch.de/media/en/pdf/ ipmodules_1/can/d_can_users_manual_111.pdf A new array is added for accessing the d_can registers, according to d_can controller register space. Current D_CAN implementation has following limitations, this is done to avoid large changes to the C_CAN driver. 1. Message objects are limited to 32, 16 for RX and 16 for TX. C_CAN IP supports upto 32 message objects but in case of D_CAN we can configure upto 128 message objects. 2. Using two 16bit reads/writes for accessing the 32bit D_CAN registers. 3. These patches have been tested on little endian machine, there might be some hidden endian-related issues due to the nature of the accesses (32-bit registers accessed as 2 16-bit registers). However, I do not have a big-endian D_CAN implementation to confirm. Signed-off-by: NAnilKumar Ch <anilkumar@ti.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
由 AnilKumar Ch 提交于
c_can uses overlay structure for accessing c_can module registers. With this kind of implementation it is difficult to add one more ip which is similar to c_can in functionality but different register offsets. This patch changes the overlay structure implementation to an array with register offset as index. This way we can overcome the above limitation. Signed-off-by: NAnilKumar Ch <anilkumar@ti.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
- 04 6月, 2012 1 次提交
-
-
由 AnilKumar Ch 提交于
This patch fixes an interrupt thrash issue with c_can driver. In c_can_isr() function interrupts are disabled and enabled only in c_can_poll() function. c_can_isr() & c_can_poll() both read the irqstatus flag. However, irqstatus is always read as 0 in c_can_poll() because all C_CAN interrupts are disabled in c_can_isr(). This causes all interrupts to be re-enabled in c_can_poll() which in turn causes another interrupt since the event is not really handled. This keeps happening causing a flood of interrupts. To fix this, read the irqstatus register in isr and use the same cached value in the poll function. Cc: stable@kernel.org # 2.6.39+ Signed-off-by: NAnilKumar Ch <anilkumar@ti.com> Acked-by: NWolfgang Grandegger <wg@grandegger.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
- 14 2月, 2011 1 次提交
-
-
由 Bhupesh Sharma 提交于
Bosch C_CAN controller is a full-CAN implementation which is compliant to CAN protocol version 2.0 part A and B. Bosch C_CAN user manual can be obtained from: http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/c_can/users_manual_c_can.pdf This patch adds the support for this controller. The following are the design choices made while writing the controller driver: 1. Interface Register set IF1 has be used only in the current design. 2. Out of the 32 Message objects available, 16 are kept aside for RX purposes and the rest for TX purposes. 3. NAPI implementation is such that both the TX and RX paths function in polling mode. Signed-off-by: NBhupesh Sharma <bhupesh.sharma@st.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-