On 10/19/2017 09:55 AM, Marc Kleine-Budde wrote:
> On 10/19/2017 03:54 PM, Franklin S Cooper Jr wrote:
>> On 10/19/2017 06:32 AM, Marc Kleine-Budde wrote:
>>> On 10/19/2017 01:09 PM, Sekhar Nori wrote:
>>>> On Thursday 19 October 2017 02:43 PM, Marc Kleine-Budde wr
On 10/19/2017 06:32 AM, Marc Kleine-Budde wrote:
> On 10/19/2017 01:09 PM, Sekhar Nori wrote:
>> On Thursday 19 October 2017 02:43 PM, Marc Kleine-Budde wrote:
>>> On 10/19/2017 07:07 AM, Sekhar Nori wrote:
>>> Sounds reasonable. What's the status of this series?
>>
>> I have had
On 10/18/2017 08:24 AM, Sekhar Nori wrote:
> Hi Marc,
>
> On Wednesday 18 October 2017 06:14 PM, Marc Kleine-Budde wrote:
>> On 09/21/2017 02:48 AM, Franklin S Cooper Jr wrote:
>>>
>>>
>>> On 09/20/2017 04:37 PM, Mario Hüttel wrote:
>>>>
On 09/21/2017 09:08 AM, Sekhar Nori wrote:
> On Thursday 21 September 2017 06:01 AM, Franklin S Cooper Jr wrote:
>>
>>
>> On 08/24/2017 03:00 AM, Sekhar Nori wrote:
>>> + some OMAP folks and Linux OMAP list
>>>
>>> On Tuesday 25 July 2017 04:21 AM
On 09/20/2017 04:37 PM, Mario Hüttel wrote:
>
>
> On 09/20/2017 10:19 PM, Franklin S Cooper Jr wrote:
>> Hi Wenyou,
>>
>> On 09/17/2017 10:47 PM, Yang, Wenyou wrote:
>>>
>>> On 2017/9/14 13:06, Sekhar Nori wrote:
>>>> On Thursd
sed devices to handle clock management.
>> Therefore, this allows future Texas Instruments SoCs that have the MCAN IP
>> to work with this driver.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>
> Thanks,
> Sekhar
>
>> ---
>> driv
re a restriction in OMAP architecture against passing the
> interface clock also in the 'clocks' property in DT. I have not tried it
> myself, but wonder if you hit an issue that led to this patch.
No but not passing the interface clock is typical.
>
>>
>> Signed-off-by: Fr
al clock. However, I haven't seen drivers verify
that this kind of constraint is properly met. Personally I think its a
valid fault but one that can be ignored from the driver perspective.
>
> Regards
>
> Mario
>
>>
>> Signed-off-by: Franklin S Cooper Jr <fcoo...@
Hi Wenyou,
On 09/17/2017 10:47 PM, Yang, Wenyou wrote:
>
>
> On 2017/9/14 13:06, Sekhar Nori wrote:
>> On Thursday 14 September 2017 03:28 AM, Franklin S Cooper Jr wrote:
>>>
>>> On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
>>>> During test
On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
> During test transmitting using CAN-FD at high bitrates (4 Mbps) only
> resulted in errors. Scoping the signals I noticed that only a single bit
> was being transmitted and with a bit more investigation realized the actual
> MCAN
Add documentation to describe usage of the new can-transceiver binding.
This new binding is applicable for any CAN device therefore it exists as
its own document.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
Acked-by: Rob Herring <r...@kernel.org>
---
Version 5 changes:
Rem
a subnode and not a property in
documentation
Version 3 changes:
Switch from having two "max bitrates" to one universal bitrate.
Version 2 changes:
Rename function
Define proper variable default
Drop unit address
Move check to changelink function
Reword commit message
Reword documentation
Fra
Add call to new generic functions that provides support via a binding
to limit the arbitration rate and/or data rate imposed by the physical
transceiver connected to the MCAN peripheral.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file c
Add information regarding can-transceiver binding. This is especially
important for MCAN since the IP allows CAN FD mode to run significantly
faster than what most transceivers are capable of.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
Acked-by: Rob Herring <r...@kernel.org>
for a can-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.
/dbitrate)/2*(Func Clk Freq).
Additional CAN-CIA's "Bit Time Requirements for CAN FD" document indicates
that this TDC mode is only needed for data bit rates above 2.5 Mbps.
Therefore, only enable this mode and only set TDCO when the data bit rate
is above 2.5 Mbps.
Signed-off-by: Franklin S
Hi,
On 08/10/2017 10:29 AM, Marc Kleine-Budde wrote:
> Hello,
>
> sorry for stepping in late
>
> On 08/10/2017 02:59 AM, Franklin S Cooper Jr wrote:
>> Various CAN or CAN-FD IP may be able to run at a faster rate than
>> what the transceiver the CAN node is
On 08/10/2017 05:05 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 8/10/2017 3:59 AM, Franklin S Cooper Jr wrote:
>
>> Various CAN or CAN-FD IP may be able to run at a faster rate than
>> what the transceiver the CAN node is connected to. This can lead to
>> u
Hi Rob,
On 08/03/2017 12:07 PM, Rob Herring wrote:
> On Mon, Jul 24, 2017 at 06:05:20PM -0500, Franklin S Cooper Jr wrote:
>> Add information regarding fixed transceiver binding. This is especially
>> important for MCAN since the IP allows CAN FD mode to run significantly
>>
Add call to new generic functions that provides support via a binding
to limit the arbitration rate and/or data rate imposed by the physical
transceiver connected to the MCAN peripheral.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file c
Hi Sergei,
On 08/03/2017 10:38 AM, Franklin S Cooper Jr wrote:
>
>
> On 08/03/2017 07:22 AM, Sergei Shtylyov wrote:
>> On 08/03/2017 12:48 PM, Franklin S Cooper Jr wrote:
>>
>>>>> Add documentation to describe usage of the new fixed transceiver
&
Add documentation to describe usage of the new can-transceiver binding.
This new binding is applicable for any CAN device therefore it exists as
its own document.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Version 4 changes:
Drop unit address.
Switch from using fixed-trans
itrates" to one universal bitrate.
Version 2 changes:
Rename function
Define proper variable default
Drop unit address
Move check to changelink function
Reword commit message
Reword documentation
Franklin S Cooper Jr (4):
can: dev: Add support for limiting configured bitrate
dt-bindings:
for a can-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.
Add information regarding can-transceiver binding. This is especially
important for MCAN since the IP allows CAN FD mode to run significantly
faster than what most transceivers are capable of.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Drop unit address.
Switch from using
Hi Santosh,
On 08/04/2017 12:07 PM, Santosh Shilimkar wrote:
> Hi Franklin,
>
> On 8/2/2017 1:18 PM, Franklin S Cooper Jr wrote:
>> Add D CAN nodes to 66AK2G based SoC dtsi.
>>
>> Franklin S Cooper Jr (2):
>>dt-bindings: net: c_can: Update binding for clock a
On 08/03/2017 07:22 AM, Sergei Shtylyov wrote:
> On 08/03/2017 12:48 PM, Franklin S Cooper Jr wrote:
>
>>>> Add documentation to describe usage of the new fixed transceiver
>>>> binding.
>>>> This new binding is applicable for any CAN device therefo
On 08/03/2017 04:20 AM, Sergei Shtylyov wrote:
> On 8/3/2017 3:51 AM, Franklin S Cooper Jr wrote:
>
>> Add information regarding fixed transceiver binding. This is especially
>> important for MCAN since the IP allows CAN FD mode to run significantly
>> faster tha
On 08/03/2017 04:18 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 8/3/2017 3:51 AM, Franklin S Cooper Jr wrote:
>
>> Add documentation to describe usage of the new fixed transceiver binding.
>> This new binding is applicable for any CAN device therefore it exist
Add call to new generic functions that provides support via a binding
to limit the arbitration rate and/or data rate imposed by the physical
transceiver connected to the MCAN peripheral.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file c
for a fixed-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.
Add information regarding fixed transceiver binding. This is especially
important for MCAN since the IP allows CAN FD mode to run significantly
faster than what most transceivers are capable of.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Documentation/devicetree/bindings/n
user does not have to define it in their
device tree.
Version 3 changes:
Switch from having two "max bitrates" to one universal bitrate.
Version 2 changes:
Rename function
Define proper variable default
Drop unit address
Move check to changelink function
Reword commit message
Reword docum
Add documentation to describe usage of the new fixed transceiver binding.
This new binding is applicable for any CAN device therefore it exists as
its own document.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
.../bindings/net/can/fixed-transceiver.txt
Enable C_CAN/D_CAN driver supported by 66AK2G
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
arch/arm/configs/keystone_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/keystone_defconfig
b/arch/arm/configs/keystone_defconfig
index d47ea43..4
subject and commit message. Misc minor updates]
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
arch/arm/boot/dts/keystone-k2g.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi
b/arch/arm/boot/dts/keystone-k2g.dtsi
index
Add D CAN nodes to 66AK2G based SoC dtsi.
Franklin S Cooper Jr (2):
dt-bindings: net: c_can: Update binding for clock and power-domains
property
ARM: configs: keystone: Enable D_CAN driver
Lokesh Vutla (1):
ARM: dts: k2g: Add DCAN nodes
Documentation/devicetree/bindings/net/can
s property
require for that SoC.
66AK2G requires a new property. Therefore, update the binding to also make
this property requirement clear. Also clarify that for OMAP based SoCs
ti,hwmod is a required property.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Documentation/devicetree/
On 07/28/2017 01:33 PM, Oliver Hartkopp wrote:
> Hi Kurt,
>
> On 07/28/2017 03:02 PM, Kurt Van Dijck wrote:
>
The word 'max-arbitration-bitrate' makes the difference very clear.
>>>
>>> I think you are mixing up ISO layer 1 and ISO layer 2.
>>
>> In order to provide higher data throughput
On 07/27/2017 01:47 PM, Oliver Hartkopp wrote:
> On 07/26/2017 08:29 PM, Franklin S Cooper Jr wrote:
>>
>
>> I'm fine with switching to using bitrate instead of speed. Kurk was
>> originally the one that suggested to use the term arbitration and data
>> s
Hi Kurt,
On 07/26/2017 03:04 PM, Kurt Van Dijck wrote:
> Hi,
>
> I know my response is late ...
>
>> Hi Oliver
>> On 07/20/2017 02:43 AM, Oliver Hartkopp wrote:
>>> Hi Franklin,
>>>
>>> On 07/20/2017 01:36 AM, Franklin S Coo
On 07/26/2017 12:05 PM, Oliver Hartkopp wrote:
> On 07/26/2017 06:41 PM, Andrew Lunn wrote:
>> On Mon, Jul 24, 2017 at 06:05:19PM -0500, Franklin S Cooper Jr wrote:
>
>>> +
>>> +Optional:
>>> + max-arbitration-speed: a positive non 0 value that determines
On 07/25/2017 11:32 AM, Oliver Hartkopp wrote:
>
>> + max-data-speed:a positive non 0 value that determines the max
>> data rate
>> +that can be used in CAN-FD mode. A value of -1 implies
>> +CAN-FD is not supported by the transceiver.
>> +
>> +Examples:
>
> (..)
>
Add call to new generic functions that provides support via a binding
to limit the arbitration rate and/or data rate imposed by the physical
transceiver connected to the MCAN peripheral.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file c
Add information regarding fixed transceiver binding. This is especially
important for MCAN since the IP allows CAN FD mode to run significantly
faster than what most transceivers are capable of.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Version 2 changes:
Drop unit a
r the user does not have to define it in their
device tree.
Version 2 changes:
Rename function
Define proper variable default
Drop unit address
Move check to changelink function
Reword commit message
Reword documentation
Franklin S Cooper Jr (4):
can: dev: Add support for limiting configured bit
for a fixed-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.
Add documentation to describe usage of the new fixed transceiver binding.
This new binding is applicable for any CAN device therefore it exists as
its own document.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Version 2:
Tweak commit message working
Tweak wording for propertie
the driver shouldn't fail if this clock isn't found.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Version 2 changes:
Used NULL instead of 0 for unused hclk handle
drivers/net/can/m_can/m_can.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/n
Add PM runtime support to the MCAN driver. To support devices that don't
use PM runtime leave the original clk calls in the driver. Perhaps in the
future when it makes sense we can remove these non pm runtime clk calls.
Version 2 changes:
Used NULL instead of 0 for unused hclk handle
Franklin S
SoCs that have the MCAN IP
to work with this driver.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
drivers/net/can/m_can/m_can.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index ea48e59..93e23f5
Update the documentation to reflect that hclk is now an optional clock.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
Acked-by: Rob Herring <r...@kernel.org>
---
Documentation/devicetree/bindings/net/can/m_can.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On 07/20/2017 04:52 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 7/20/2017 2:36 AM, Franklin S Cooper Jr wrote:
>
>> Various CAN or CAN-FD IP may be able to run at a faster rate than
>> what the transceiver the CAN node is connected to. This can lead to
>> u
Hi Oliver
On 07/20/2017 02:43 AM, Oliver Hartkopp wrote:
> Hi Franklin,
>
> On 07/20/2017 01:36 AM, Franklin S Cooper Jr wrote:
>
>> +#ifdef CONFIG_OF
>> +void of_transceiver_is_fixed(struct net_device *dev)
>> +{
>
> (..)
>
>> +}
>>
r the user does not have to define it in their
device tree.
Franklin S Cooper Jr (4):
can: dev: Add support for limiting configured bitrate
can: fixed-transceiver: Add documentation for CAN fixed transceiver
bindings
can: m_can: Update documentation to mention new fixed transceiver
for a fixed-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.
Add call to new generic functions that provides support via a binding
to limit the arbitration rate and/or data rate imposed by the physical
transceiver connected to the MCAN peripheral.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file c
Add information regarding fixed transceiver binding. This is especially
important for MCAN since the IP allows CAN FD mode to run significantly
faster than what most transceivers are capable of.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Documentation/devicetree/bindings/n
Add documentation to describe usage of the new fixed transceiver binding.
This new binding is applicable for any CAN device therefore it exist as
its own document.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
.../bindings/net/can/fixed-transceiver.txt
the driver shouldn't fail if this clock isn't found.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
drivers/net/can/m_can/m_can.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index f
SoCs that have the MCAN IP
to work with this driver.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
drivers/net/can/m_can/m_can.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 7fe9145..eb45cd5
Update the documentation to reflect that hclk is now an optional clock.
Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Documentation/devicetree/bindings/net/can/m_can.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/n
Add PM runtime support to the MCAN driver. To support devices that don't use
PM runtime leave the original clk calls in the driver. Perhaps in the future
when it makes sense we can remove these non pm runtime clk calls.
Franklin S Cooper Jr (3):
can: m_can: Make hclk optional
can: m_can
Hi Kurt,
On 06/30/2017 03:09 AM, Kurt Van Dijck wrote:
>> On 06/29/2017 05:36 PM, Kurt Van Dijck wrote:
>>
>> mcan@0 {
>> ...
>> fixed-transceiver {
>>max-canfd-speed = <2000>
>> };
>> ...
>> };
>>>
>>> Since when would a transceiver support different
On 06/29/2017 05:36 PM, Kurt Van Dijck wrote:
mcan@0 {
...
fixed-transceiver {
max-canfd-speed = <2000>
};
...
};
>
> Since when would a transceiver support different speeds for CAN & CANFD?
When I say CAN I'm referring to CAN 2.0
+device tree mailing list
Hi Andrew
On 06/29/2017 10:41 AM, Andrew Lunn wrote:
>> Transceivers for CAN are not apart of any model. Traditional CAN didn't
>> have a problem because all transceivers from my understanding supported
>> the maximum speed of 1 Mbps defined by the spec. However, with
Hi Andrew
On 06/29/2017 09:21 AM, Andrew Lunn wrote:
> On Wed, Jun 28, 2017 at 05:14:42PM -0500, Franklin S Cooper Jr wrote:
>> Hi All,
>>
>> The various CAN transceivers I've seen that support CAN-FD appear to be
>> fairly limited in terms of their supporte
Hi All,
The various CAN transceivers I've seen that support CAN-FD appear to be
fairly limited in terms of their supported max speed. I've seen some
transceivers that only support upto 2 Mbps while others support up to 5
Mbps. This is a problem when the SoC's CAN IP can support even higher
On 04/06/2016 09:22 PM, Willem de Bruijn wrote:
> On Wed, Apr 6, 2016 at 7:12 PM, Franklin S Cooper Jr. <fcoo...@ti.com> wrote:
>> Hi All,
>>
>> Currently linux-next is failing to boot via NFS on my AM335x GP evm,
>> AM437x GP evm and Beagle X15. I bisected the p
Hi All,
Currently linux-next is failing to boot via NFS on my AM335x GP evm,
AM437x GP evm and Beagle X15. I bisected the problem down to the commit
"udp: remove headers from UDP packets before queueing".
I had to revert the following three commits to get things working again:
On 02/02/2016 07:19 PM, Franklin S Cooper Jr. wrote:
>
> On 02/02/2016 05:26 PM, Arnd Bergmann wrote:
>> On Tuesday 02 February 2016 16:59:34 Franklin Cooper wrote:
>>> On 02/02/2016 03:26 PM, Arnd Bergmann wrote:
>>>> On Tuesday 02 February 2016 15:01:33 Frank
On 02/03/2016 08:21 AM, Grygorii Strashko wrote:
> Hi Arnd,
>
> On 02/03/2016 04:11 PM, Franklin S Cooper Jr. wrote:
>> On 02/02/2016 07:19 PM, Franklin S Cooper Jr. wrote:
>>> On 02/02/2016 05:26 PM, Arnd Bergmann wrote:
>>>> On Tuesday 02 February
On 02/02/2016 02:41 PM, Arnd Bergmann wrote:
> On Tuesday 02 February 2016 10:50:41 Franklin S Cooper Jr. wrote:
>> Latest mainline is currently failing to boot for Keystone 2
>> Hawking but I'm assuming its true for other Keystone 2
>> boards. Bisect shows that this
On 02/02/2016 05:26 PM, Arnd Bergmann wrote:
> On Tuesday 02 February 2016 16:59:34 Franklin Cooper wrote:
>> On 02/02/2016 03:26 PM, Arnd Bergmann wrote:
>>> On Tuesday 02 February 2016 15:01:33 Franklin S Cooper Jr. wrote:
>>>> Yes. Here is a boot log on th
Hi All,
Latest mainline is currently failing to boot for Keystone 2
Hawking but I'm assuming its true for other Keystone 2
boards. Bisect shows that this issue popped up after the
patch "netcp: try to reduce type confusion in descriptors"
(commit 89907779) was introduced. There was another patch
75 matches
Mail list logo
