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 some
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 Thursday 14 Sept
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
>
> Thanks,
> Sekhar
>
>> ---
>> drivers/net/can/m_can/m_ca
rom it?
>
> Is there 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.
>
similar constraints when there is an
interface and functional 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
>
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
Acked-by: Rob Herring
---
Version 5 changes:
Remove @ symbol from can-transceiver example
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
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file changed, 2 insertions
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
Acked-by: Rob Herring
---
Remove @ symbol from can-transceiver
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
---
Version 5
set to (1/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
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 con
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
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file changed, 2 insertions
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
---
Version 4 changes:
Drop unit address.
Switch from using fixed-transceiver to can-transceiver
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
---
Version 4
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
---
Drop unit address.
Switch from using fixed-transceiver to can
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 than wh
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
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file changed, 2 insertions
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
---
drivers/net
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
---
Documentation/devicetree/bindings/net/can/m_can.txt | 9
r 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
---
.../bindings/net/can/fixed-transceiver.txt | 24 ++
1 file
Enable C_CAN/D_CAN driver supported by 66AK2G
Signed-off-by: Franklin S Cooper Jr
---
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..47be99e 100644
--- a/arch
From: Lokesh Vutla
Add nodes for the two DCAN instances included in 66AK2G
Signed-off-by: Lokesh Vutla
[d-gerl...@ti.com: add power-domains and clock information]
Signed-off-by: Dave Gerlach
[fcoo...@ti.com: update subject and commit message. Misc minor updates]
Signed-off-by: Franklin S
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
clocks 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
---
Documentation/devicetree/bindings/net/can
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
>> si
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
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file changed, 2 insertions
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
---
Version 2 changes:
Drop unit address
Documentation
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
---
Version 2
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
---
Version 2:
Tweak commit message working
Tweak wording for properties
Drop unit addressing
T
and thus the driver shouldn't fail if this clock isn't found.
Signed-off-by: Franklin S Cooper Jr
---
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/net
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
Frank
SoCs that have the MCAN IP
to work with this driver.
Signed-off-by: Franklin S Cooper Jr
---
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 100644
--- a/drivers
Update the documentation to reflect that hclk is now an optional clock.
Signed-off-by: Franklin S Cooper Jr
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/net/can/m_can.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net
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
---
drivers/net
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
---
drivers/net/can/m_can/m_can.c | 2 ++
1 file changed, 2 insertions
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
---
Documentation/devicetree/bindings/net/can/m_can.txt | 10
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
---
.../bindings/net/can/fixed-transceiver.txt | 31 ++
1 file
T
and thus the driver shouldn't fail if this clock isn't found.
Signed-off-by: Franklin S Cooper Jr
---
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 f4947a7..
SoCs that have the MCAN IP
to work with this driver.
Signed-off-by: Franklin S Cooper Jr
---
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 100644
--- a/drivers
Update the documentation to reflect that hclk is now an optional clock.
Signed-off-by: Franklin S Cooper Jr
---
Documentation/devicetree/bindings/net/can/m_can.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt
b
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:
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 sp
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 spe
+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 the
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 sup
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
values
On 04/06/2016 09:22 PM, Willem de Bruijn wrote:
> On Wed, Apr 6, 2016 at 7:12 PM, Franklin S Cooper Jr. 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 problem down to the com
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:
e6afc8ace6dd5cef5e
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 2016 16:5
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/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
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
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
