Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Acked-by: NWolfgang Grandegger <wg@grandegger.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

There is no point to toggle the RX led for every packet. Especially if
we have a full FIFO we want to avoid everything we can.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The function loads the message object from the hardware to get the
payload length. The previous patch stores that information in an
array, so we can avoid the hardware access.

Remove the hardware access and move the led toggle outside of the
spinlocked region. Toggle the led only once when at least one packet
has been received.

Binary size shrinks along with the code
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

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>

commit 4ce78a83 (can: c_can: Speed up rx_poll function) hyped a
performance improvement by reducing the access to the interrupt
pending register from a dual 16 bit to a single 16 bit access. Wow!

Thereby it crippled the driver to cast the 16 msg objects in stone,
which is completly braindead as contemporary hardware has up to 128
message objects. Supporting larger object buffers is a major surgery,
but it'd be definitely worth it especially as the driver does not
support HW message filtering ....

The logic of the "FIFO" implementation is to split the FIFO in half.

For the lower half we read the buffers and clear the interrupt pending
bit, but keep the newdat bit set, so the HW will queue above those
buffers.

When we read out the last low buffer then we reenable all the low half
buffers by clearing the newdat bit.

The upper half buffers clear the newdat and the interrupt pending bit
right away as we know that the lower half bits are clear and give us a
headstart against the hardware.

Now the implementation is:

    transfer_message_object()
    read_object_and_put_into_skb();

    if (obj < END_OF_LOW_BUF)
       clear_intpending(obj)
    else if (obj > END_OF_LOW_BUF)
       clear_intpending_and_newdat(obj)
    else if (obj == END_OF_LOW_BUF)
       clear_newdat_of_all_low_objects()

The hardware allows to avoid most of the mess simply because we can
tell the transfer_message_object() function to clear bits right away.

So we can be clever and do:

   if (obj <= END_OF_LOW_BUF)
      ctrl = TRANSFER_MSG | CLEAR_INTPND;
   else
      ctrl = TRANSFER_MSG | CLEAR_INTPND | CLEAR_NEWDAT;

    transfer_message_object(ctrl)
    read_object_and_put_into_skb();

    if (obj == END_OF_LOW_BUF)
       clear_newdat_of_all_low_objects()

So we save a complete control operation on all message objects except
the one which is the end of the low buffer. That's a few micro seconds
per object.

I'm not adding a boasting profile to that, simply because it's self
explaining.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
[mkl: adjusted subject and commit message]
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

If every other line contains line breaks, that's a clear sign for
indentation level madness. Split out the inner loop and move the code
to a separate function. gcc creates slightly worse code for that, but
we'll fix that in the next step.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
[mkl: adjusted subject]
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

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>

The rx_poll code has the following gem:

	if (msg_ctrl_save & IF_MCONT_EOB)
		return num_rx_pkts;

The EOB bit is the indicator for the hardware that this is the last
configured FIFO object. But this object can contain valid data, if we
manage to free up objects before the overrun case hits.

Now if the code exits due to the EOB bit set, then this buffer is
stale and the interrupt bit and NewDat bit of the buffer are still
set. Results in a nice interrupt storm unless we come into an overrun
situation where the MSGLST bit gets set.

     ksoftirqd/0-3     [000] ..s.    79.124101: c_can_poll: rx_poll: val: 00008001 pend 00008001
     ksoftirqd/0-3     [000] ..s.    79.124176: c_can_poll: rx_poll: val: 00008000 pend 00008000
     ksoftirqd/0-3     [000] ..s.    79.124187: c_can_poll: rx_poll: val: 00008002 pend 00008002
     ksoftirqd/0-3     [000] ..s.    79.124256: c_can_poll: rx_poll: val: 00008000 pend 00008000
     ksoftirqd/0-3     [000] ..s.    79.124267: c_can_poll: rx_poll: val: 00008000 pend 00008000

The amazing thing is that the check of the MSGLST (aka overrun bit)
used to be after the check of the EOB bit. That was "fixed" in commit
5d0f801a(can: c_can: Fix RX message handling, handle lost message
before EOB). But the author of this "fix" did not even understand that
the EOB check is broken as well.

Again a simple solution: Remove
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
[mkl: adjusted subject and commit message]
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The lost message handling is broken in several ways.

1) Clearing the message lost flag is done by writing 0 to the
   message control register of the object.

   #define IF_MCONT_CLR_MSGLST    (0 << 14)

   That clears the object buffer configuration in the worst case,
   which results in a loss of the EOB flag. That leaves the FIFO chain
   without a limit and causes a complete lockup of the HW

2) In case that the error skb allocation fails, the code happily
   claims that it handed down a packet. Just an accounting bug, but ....

3) The code adds a lot of pointless overhead to that error case, where
   we need to get stuff done as fast as possible to avoid more packet
   loss.

   - printk an annoying error message
   - reread the object buffer for nothing

Fix is simple again:

  - Use the already known MSGCTRL content and only clear the MSGLST bit
  - Fix the buffer accounting by adding a proper return code
  - Remove the pointless operations
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The buffer handling of c_can has been broken forever. That leads to
message reordering:

ksoftirqd/0-3     [000] ..s.    79.123776: c_can_poll: rx_poll: val: 00007fff
ksoftirqd/0-3     [000] ..s.    79.124101: c_can_poll: rx_poll: val: 00008001

What happens is:

CPU				HW
				queue new packet into obj 16 (0-15 are busy)
read obj 1-15
return because pending is 0
				set pending obj 16 -> pending reg 8000
				queue new packet into obj 1
				set pending obj 1 -> pending reg 8001

So the current algorithmus reads the newest message first, which
violates the ordering rules of CAN.

Add proper handling of that situation by analyzing the contents of the
pending register for gaps.

This does NOT fix the message object corruption which can lead to
interrupt storms. Thats addressed in the next patches.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
[mkl: adjusted subject]
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The hardware has two message control interfaces, but the code only uses the
first one. So on SMP the following can be observed:

CPU0 	       	CPU1
rx_poll()
  write IF1	xmit()
		write IF1
  write IF1

That results in corrupted message object configurations. The TX/RX is not
globally serialized it's only serialized on a core.

Simple solution: Let RX use IF1 and TX use IF2 and all is good.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The function is broken in several ways:

    - The function does not wait for the init to complete.
      That can take quite some microseconds.

    - No protection against being called for two chips at the same
      time. SMP is such a new thing, right?

Clear the start and the init done bit unconditionally and wait for both bits to
be clear.

In the enable path set the init bit and wait for the init done bit.

Add proper locking.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

According to the documentation the CPU must wait for CONTROL_INIT to
be cleared before writing to the baudrate registers.
Signed-off-by: NBenedikt Spranger <b.spranger@linutronix.de>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch adds return value checking to all direct and indirect users of
c_can_set_bittiming().
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch adds the missing netif_napi_del() to the free_c_can_dev() function.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

CAN interfaces only support MTU values of 16 (CAN 2.0) and 72 (CAN FD).
Setting the MTU to other values is pointless but it does not really hurt.
With the introduction of the CAN FD support in drivers/net/can a new
function to switch the MTU for CAN FD has been introduced.

This patch makes use of this can_change_mtu() function to check for correct
MTU settings also in legacy CAN (2.0) devices.
Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch speeds up the rx_poll function by reducing the number of
register reads.

Replace the 32bit register read by a 16bit register read. Currently
the 32bit register read is implemented by using 2 16bit reads. This is
inefficient as we only use the lower 16bit in rx_poll.

The for loop reads the pending interrupts in every iteration. This
leads up to 16 reads of pending interrupts. The patch introduces a new
outer loop to read the pending interrupts as long as 'quota' is above 0.
This reduces the total number of reads.

The third change is to replace the for-loop by a ffs loop.

Tested on AM335x. I removed all 'static' and 'inline' from c_can.c to
see the timings for all functions. I used the function tracer with
trace_stats.

125kbit:
  Function                               Hit    Time            Avg             s^2
  --------                               ---    ----            ---             ---
  c_can_do_rx_poll                     63960    10168178 us     158.977 us      1493056 us
With patch:
  c_can_do_rx_poll                     63941    3764057 us      58.867 us       776162.2 us

1Mbit:
  Function                               Hit    Time            Avg             s^2
  --------                               ---    ----            ---             ---
  c_can_do_rx_poll                     69489    30049498 us     432.435 us      9271851 us
With patch:
  c_can_do_rx_poll                    207109    24322185 us     117.436 us      171469047 us
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The number of bytes transmitted was not updated correctly, if several CAN
messages (with different length) were transmitted in one 'bunch'. Thus
programs like 'ifconfig' showed wrong transmit byte counts. Reason was, that
the message object whose DLC is to be read was not necessarily the active one
at the time when

    priv->read_reg(priv, C_CAN_IFACE(MSGCTRL_REG, 0)) & IF_MCONT_DLC_MASK;

was executed.
Signed-off-by: NHolger Bechtold <Holger.Bechtold@gmx.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The c_can driver contians a callpath (c_can_poll -> c_can_state_change ->
c_can_get_berr_counter) which may call pm_runtime_get_sync() from the IRQ
handler, which is not allowed and results in "BUG: scheduling while atomic".

This problem is fixed by introducing __c_can_get_berr_counter, which will not
call pm_runtime_get_sync().
Reported-by: NAndrew Glen <AGlen@bepmarine.com>
Tested-by: NAndrew Glen <AGlen@bepmarine.com>
Signed-off-by: NAndrew Glen <AGlen@bepmarine.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

If we handle end of block messages with higher priority than a lost message,
we can run into an endless interrupt loop.

This is reproducable with a am335x processor and "cansequence -r" at 1Mbit.
As soon as we loose a packet we can't escape from an interrupt loop.

This patch fixes the problem by handling lost packets before EOB packets.

Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The data structure of_match_ptr() protects is always compiled in.
Hence of_match_ptr() is not needed.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch adds a type cast from 'unsigned int' to 'int'.

'priv->instance' may less than zero, so need a type cast, the related
warnings (allmodconfig, "EXTRA_CFLAGS=-W"):

  drivers/net/can/c_can/c_can_platform.c:198:3: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
Signed-off-by: NChen Gang <gang.chen@asianux.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Since commit ab78029e (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.

Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13)
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 75096579 ("lib: devres: Introduce devm_ioremap_resource()")
introduced devm_ioremap_resource() and deprecated the use of
devm_request_and_ioremap().
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
CC: netdev@vger.kernel.org
CC: linux-can@vger.kernel.org
CC: Marc Kleine-Budde <mkl@pengutronix.de>
CC: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d063
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

According to C_CAN documentation, the reserved bit in IFx_MASK2 register is
fixed 1.

Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Errors in CAN protocol (location) are reported in data[3] of the can
frame instead of data[2].

Cc: linux-stable <stable@vger.kernel.org>
Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: NOlivier Sobrie <olivier@sobrie.be>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Add support for canbus activity led indicators on c_can devices by
calling appropriate can_led functions.

These are only enabled when CONFIG_CAN_LEDS is Y, becomes no-op
otherwise.

Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
Cc: AnilKumar Ch <anilkumar@ti.com>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NFabio Baltieri <fabio.baltieri@gmail.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch adds an 'if CAN_DEV...endif' Block around the CAN driver
symbols in drivers/net/can/Kconfig. So the 'depends on CAN' dependencies
can be removed.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The __dev* removal patches for the network drivers ended up messing up
the function prototypes for a bunch of drivers.  This patch fixes all of
them back up to be properly aligned.

Bonus is that this almost removes 100 lines of code, always a nice
surprise.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

CONFIG_HOTPLUG is going away as an option.  As result the __dev*
markings will be going away.

Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds a MODULE_DEVICE_TABLE for the of and platform bindings, so that
the module can be loaded automatically by udev.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

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>

This patch fixes an oops which occurs during unloading the driver.
unregister_c_can_dev() is doing c_can/d_can module interrupts disable, which
requires module clock enable. c_can/d_can interrupts enable/disable is handled
properly in c_can_start and c_can_stop, so removing from
unregister_c_can_dev().

The problem was triggered by adding runtime PM support to the c_can driver by
this commit:

4cdd34b2 can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
Signed-off-by: NAnilKumar Ch <anilkumar@ti.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Adopt pinctrl support to c_can driver based on c_can device
pointer, pinctrl driver configure SoC pins to d_can mode
according to definitions provided in .dts file.

In device specific device tree file 'pinctrl-names = "default";'
and 'pinctrl-0 = <&d_can1_pins>;' needs to add to configure pins
from c_can driver. d_can1_pins node contains the pinmux/config
details of d_can L/H pins.
Signed-off-by: NAnilKumar Ch <anilkumar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

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>

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>

Add device tree support to C_CAN/D_CAN controller and usage details
are added to device tree documentation. Driver was tested on AM335x
EVM.
Signed-off-by: NAnilKumar Ch <anilkumar@ti.com>
For the of binding doc:
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

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>