clk: divider: fix rate calculation for fractional rates

clk-divider.c does not calculate the rates consistently at the moment.

As an example, on OMAP3 we have a clock divider with a source clock of
864000000 Hz. With dividers 6, 7 and 8 the theoretical rates are:

6: 144000000
7: 123428571.428571...
8: 108000000

Calling clk_round_rate() with the rate in the first column will give the
rate in the second column:

144000000 -> 144000000
143999999 -> 123428571
123428572 -> 123428571
123428571 -> 108000000

Note how clk_round_rate() returns 123428571 for rates from 123428572 to
143999999, which is mathematically correct, but when clk_round_rate() is
called with 123428571, the returned value is surprisingly 108000000.

This means that the following code works a bit oddly:

rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);

As clk_set_rate() also does clock rate rounding, the result is that the
clock is set to the rate of 108000000, not 123428571 returned by the
clk_round_rate.

This patch changes the clk-divider.c to use DIV_ROUND_UP when
calculating the rate. This gives the following behavior which fixes the
inconsistency:

144000000 -> 144000000
143999999 -> 123428572
123428572 -> 123428572
123428571 -> 108000000

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
(cherry picked from commit b11d282dbea27db1788893115dfca8a7856bf205)
Signed-off-by: Mark Brown <broonie@kernel.org>
clk: divider: Fix best div calculation for power-of-two and table dividers

The divider returned by clk_divider_bestdiv() is likely to be invalid in case
of power-of-two and table dividers when CLK_SET_RATE_PARENT flag isn't set.

Fixes boot on STiH416 platform.

Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
[mturquette@linaro.org: trivial merge conflict & updated changelog]

(cherry picked from commit dd23c2cd38da2c64af381b19795d2c4f115e8ecb)
Signed-off-by: Mark Brown <broonie@kernel.org>
clk: divider: Add round to closest divider

In some cases, we want to be able to round the divider to the closest one,
instead than rounding up.

This patch adds a new CLK_DIVIDER_ROUND_CLOSEST flag to specify the divider
has to round to closest div, keeping rounding up as de default behaviour.

Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
(cherry picked from commit 774b514390b1eb8476bc759262790762bd1ef45a)
Signed-off-by: Mark Brown <broonie@kernel.org>
clk: divider: Fix table round up function

Commit 1d9fe6b97 ("clk: divider: Fix best div calculation for power-of-two and
table dividers") introduces a regression in its _table_round_up function.

When the divider passed to this function is greater than the max divider
available in the table, this function returns table's max divider.
Problem is that it causes an infinite loop in clk_divider_bestdiv() because
_next_div() will never return a value greater than maxdiv.

Instead of returning table's max divider, this patch returns INT_MAX.

Reported-by: Fabio Estevam <festevam@gmail.com>
Reported-by: Shawn Guo <shawn.guo@freescale.com>
Tested-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
(cherry picked from commit fe52e7505f8bf365d5ab0eeee19ababe406cbaaf)
Signed-off-by: Mark Brown <broonie@kernel.org>
clk: divider: Fix overflow in clk_divider_bestdiv

Commit c686078 ("clk: divider: Add round to closest divider") introduced
a helper function to check whether given divisor is the best one instead
of direct check. However due to int type used instead of unsigned long
for passing calculated rates to this function in certain cases an
overflow could occur, for example when trying to obtain maximum possible
clock rate by calling clk_round_rate(..., UINT_MAX).

This patch fixes this issue by changing the type of rate, now and best
arguments of the function to unsigned long, which is the type that
should be used for clock rates.

Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
(cherry picked from commit 3c17296f28820d2a9fa23e549a1e808a4df5dfc6)
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge remote-tracking branch 'lsk/v3.14/topic/clk-divider' into linux-linaro-lsk-v3.14
mtd: mtd_oobtest: get rid of unused variable in memcmpshow()

ret is never used to remove it from memcmpshow().

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
mtd: mtd_oobtest: Fix bitflip_limit usage in test case 3

In test case 3, we set vary_offset to write at different
offsets and lengths in the OOB available area. We need to
do the bitflip_limit check while checking for 0xff outside the
OOB offset + length area that we didn't modify during write.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
mtd: mtd_oobtest: Fix the address offset with vary_offset case

When vary_offset is set (e.g. test case 3), the offset is not always
zero so memcmpshow() will show the wrong offset in the print message.
To fix this we introduce a new function memcmpshowoffset() which takes
offset as a parameter and displays the right offset and use it in
the case where offset is non zero.

The old memcmpshow() functionality is preserved by converting it into
a macro with offset preset to 0.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  mtd: mtd_oobtest: Fix the address offset with vary_offset case
  mtd: mtd_oobtest: Fix bitflip_limit usage in test case 3
  mtd: mtd_oobtest: get rid of unused variable in memcmpshow()

Signed-off-by: Dan Murphy <DMurphy@ti.com>
ARM: dts: DRA74x: Add sub-mailbox nodes for all PRUSS1 & PRUSS2

Add the reference sub-mailbox nodes to communicate between MPU and
the PRU remote processor cores within the PRUSS1 and PRUSS2 processor
subsystems in AM57xx SoCs. Each PRUSS has two PRU cores, so one
sub-mailbox node is used per MPU-PRU.

The following are the assignments of mailbox fifos between MPU and
the remote PRU cores in each PRUSS:

                MPU Tx/PRU Rx   MPU Rx/PRU Tx
        PRU0    0               1
        PRU1    2               2

Mailbox 3 is utilized to communicate between MPU and PRUSS1, while
Mailbox 4 is used between MPU and PRUSS2. The PRUSS crossbar also
needs to be setup properly to achieve proper communication as the
Mailbox interrupts are not mapped to any of the existing events by
default.

All these sub-mailbox nodes are left in disabled state, and should
be enabled (and maybe modified) as per the individual product
configuration in the corresponding board dts files.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: beagle-x15: Enable the system mailboxes 3 and 4

Enable the System Mailboxes 3 and 4 and the corresponding child
sub-mailbox (legacy) nodes, in order to communicate with the
respective PRU remote cores in each of the PRUSS processor subsystem
from the host. It is assumed that the PRUSS crossbar is setup properly
on the PRU firmware side to receive the mailbox interrupts on one of
its input events.

Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox into rproc-linux-3.14.y

Pull in the updated mailbox feature branch into the remoteproc
tree for adding support to the PRU-ICSS PRU cores in AM572x SoC.

* 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox:
  ARM: dts: beagle-x15: Enable the system mailboxes 3 and 4
  ARM: dts: DRA74x: Add sub-mailbox nodes for all PRUSS1 & PRUSS2

Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/pruss: add support for PRU-ICSS subsystems on AM57xx SoCs

The AM57xx family of SoCs supports two PRU-ICSS instances, each of
which has two PRU processor cores. The two PRU-ICSS instances are
identical to each other, and are very similar to the PRU-ICSS1 of
AM33xx/AM43xx except for a few minor differences like the RAM sizes
and the number of interrupts coming into the MPU INTC. They also do
not have a programmable module reset line like those present in
AM33xx/AM43xx. The modules are reset just like any other IP with the
SoC's global cold/warm resets. Each PRU-ICSS's INTC is also preceded
by a Crossbar that enables multiple external events to be routed to
a specific number of input interrupt events. Any interrupt events
needs these crossbars to be setup properly on the firmware side.

The existing PRUSS remoteproc driver has been enhanced to support
these AM57xx PRU-ICSS instances through new AM57xx specific
compatibles for properly probing and booting the all the different
PRU cores in each PRU-ICSS processor subsystem. A build dependency
with SOC_DRA7XX is also added to enable the driver to be built in
AM57xx-only configuration (there is no separation Kconfig option
for AM57xx vs DRA7xx).

The auxdata lookup logic has to be adjusted for AM57xx as there are
more than one instance of the PRU-ICSS remote processor subsystem,
and the child PRU nodes and their respective platform data containing
the firmware image names will be different between the two PRU-ICSS
instances. The names for the firmware images are fixed for each PRU
core and is expected to be as follows:
     PRU-ICSS1 PRU0 Core: am57xx-pru1_0-fw
     PRU-ICSS1 PRU1 Core: am57xx-pru1_1-fw
     PRU-ICSS2 PRU0 Core: am57xx-pru2_0-fw
     PRU-ICSS2 PRU1 Core: am57xx-pru2_1-fw

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: DRA7: Add the PRU-ICSS nodes

Add the DT nodes for the PRU-ICSS1 and PRU-ICSS2 processor
subsystems that are present on AM57xx family of SoCs. The
two PRU-ICSSs are identical to each other. They are not
supported on DRA74x and DRA72x SoCs in general, so the
nodes are added in disabled state to the common dra7 DTS
file. They should be enabled only in the AM57xx related
board files.

The DT nodes uses all standard properties. The regs property
defines the addresses for various modules within the PRUSS,
including all the Data RAMs, the Instruction RAM per core,
the INTC, CFG, Debug and Control sub-modules. The two PRU
cores within the PRUSS are represented as child nodes (so
platform devices themselves) of the PRUSS parent node.

The PRU-ICSSs on AM57xx are very similar to the PRUSS in
AM33xx and AM437x except for variations in the RAM sizes
and the number of interrupts coming into the MPU INTC. The
interrupt events into the PRU-ICSS also requires programming
of the corresponding crossbars properly.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: beagle-x15: Add mailboxes to the PRU nodes

Add the optional 'mboxes' property to both the PRU cores in each
of PRU-ICSS1 and PRU-ICSS2 remote processor subsystems. This is
usually needed for running the Remote Processor Messaging (RPMsg)
stack between the host processor and each of the remote processors.

Each of the PRU cores uses a single sub-mailbox node, the chosen
sub-mailboxes should match the values used in the current firmware
images. The respective PRUSS crossbar also needs to be setup properly
on the firmware side to achieve proper communication as the Mailbox
interrupts are not mapped to any of the existing events by default.
This can be changed, if needed, as per the system integration needs
after making appropriate changes on the firmware side as well.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: DRA7: hwmod_data: Add PRU-ICSS data for AM57xx variants

The AM57xx family of SoCs have two PRU-ICSS remote processor
subsystems, each supporting two PRU processor cores. These
subsystems are not supported on the DRA7 family of SOCs. They
are very similar to the respective processor subsystems on
AM33xx/AM43xx SoCs except for a few differences. The relevant
hwmod classes and data structures have been added for the
PRU-ICSS1 and PRU-ICSS2 subsystems to enable support for
these on the AM57xx SoC variants.

Do note that these subsystems are not supported on the DRA7
do not have a programmable module reset line unlike those
present in AM33xx/AM43xx. The modules are reset just like
any other IP with the SoC's global cold/warm resets.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: beagle-x15: Enable PRU-ICSS and the child PRU nodes

The two PRU-ICSS processor subsystems nodes and their associated
child PRU remote processor nodes were left in disabled state in
the base dra7.dts file. The PRU-ICSSs are supported on only the
AM57xx SoCs, and are now enabled in the supported Beagle-X15
board.

These nodes can be disabled later on if there is no use-case
defined to use that remote PRU core or PRU-ICSS subsystem if
both its PRU cores are unused.

Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y

Pull in the updated remoteproc feature branch that enhances the support
in the PRUSS remoteproc driver to load the PRU cores on the two PRU-ICSS
subsystems present on AM57xx SoCs (on Beagle-X15 board).

* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: dts: beagle-x15: Enable PRU-ICSS and the child PRU nodes
  ARM: DRA7: hwmod_data: Add PRU-ICSS data for AM57xx variants
  ARM: dts: beagle-x15: Add mailboxes to the PRU nodes
  ARM: dts: DRA7: Add the PRU-ICSS nodes
  remoteproc/pruss: add support for PRU-ICSS subsystems on AM57xx SoCs
  ARM: dts: beagle-x15: Enable the system mailboxes 3 and 4
  ARM: dts: DRA74x: Add sub-mailbox nodes for all PRUSS1 & PRUSS2

Signed-off-by: Suman Anna <s-anna@ti.com>
drivers; net: cpsw: add port vlan support via switch config ioctl

Add port vlan support via switch config ioctl to configure port vlan
in the ports to add desired vlan to the packet when an untagged VLAN
packet arrives at the port.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>