* Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
@ 2018-06-07 15:20 Jonas Mark (BT-FIR/ENG1)
0 siblings, 0 replies; 9+ messages in thread
From: Jonas Mark (BT-FIR/ENG1) @ 2018-06-07 15:20 UTC (permalink / raw)
To: Oliver Hartkopp, Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can, netdev, linux-kernel, hs, ZHU Yi (BT-FIR/ENG1-Zhu)
Hi Oliver,
> >> Please place the companion driver in
> >>
> >> drivers/net/can/spi/companion.c
> >>
> >> It also makes more sense in the Kconfig structure.
> >>
> >> Probably this naming scheme also makes sense for
> >>
> >> linux/drivers/char/spi/companion.c
> >>
> >> then ...
> >>
> >> If not it should be named at least
> >>
> >> drivers/char/companion-spi.c
> >>
> >> or
> >>
> >> drivers/char/spi-companion.c
> >
> > We intentionally left out the spi in the driver path / name because
> > only the drivers/spi/companion/* driver knows that that it is connected
> > to SPI. The others (drivers/net/can/companion-can.c and
> > drivers/char/companion-char.c) only know the API. This could also be
> > supplied by a driver which talks to the Companion via a different
> > interface. Actually, we started with a UART connection but switched to
> > SPI due to latency issues.
>
> Ok, got it.
>
> > Should we still change it?
>
> At least I would then vote for
>
> drivers/char/companion.c
> drivers/net/can/companion.c
>
> instead of
>
> drivers/char/companion-char.c
> drivers/net/can/companion-can.c
Sounds good, will be changed.
> as you would have companion-users in different driver subsystems that
> are already clearly referenced by their path.
>
> The modules itself should still be named with companion-can of course
> (as-is right now).
>
> Btw.
>
> +#define DRIVER_NAME "bosch,companion-can"
>
> +static const struct can_bittiming_const companion_can_bittiming_const = {
> + .name = "bosch,companion",
>
>
> Is there any reason why it's not only "companion-can" or "companion"?
> The fact that the driver is provided by Bosch is visible in the source code.
Hmm, I guess we mixed up the naming scheme used in devicetree. We will
sleep a night over it and then clean it up. I think the result will be
that the devicetree entry is "bosch,companion-can" and all other uses
are "companion-can".
Greetings,
Mark
Building Technologies, Panel Software Fire (BT-FIR/ENG1)
Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118
Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
2018-06-07 15:14 Jonas Mark (BT-FIR/ENG1)
@ 2018-06-11 4:41 ` Oleksij Rempel
0 siblings, 0 replies; 9+ messages in thread
From: Oleksij Rempel @ 2018-06-11 4:41 UTC (permalink / raw)
To: Jonas Mark (BT-FIR/ENG1), Andy Shevchenko
Cc: Wolfgang Grandegger, Marc Kleine-Budde, linux-can, netdev,
Linux Kernel Mailing List, Heiko Schocher,
ZHU Yi (BT-FIR/ENG1-Zhu)
[-- Attachment #1.1: Type: text/plain, Size: 2007 bytes --]
Hi,
On 07.06.2018 17:14, Jonas Mark (BT-FIR/ENG1) wrote:
> Hi Andy,
>
>>> The functionality bases on an external peripheral chip named Companion.
>>> It offers two CAN interfaces, each has 8 prioritized transmit FIFOs as
>>> well as one receive FIFO. Besides CAN, undisclosed additional functions
>>> can be accessed through the char device.
>>>
>>> A standard SPI interface with two additional lines for flow control is
>>> used. The Companion chip is the SPI slave.
>>
>> Can remoteproc API be utilized here?
>
> So far I wasn't aware of the remoteproc API. It appears to me that is
> limited to power on/off and loading firmware in an AMP scenario. Here,
> the Companion has a fixed firmware in it. It must already be running
> quickly after power-up, even before the boot loader.
yes, remoteproc is not quite suitable for this task.
> Does remoteproc also contain a communication framework?
it is using VirtIO
> Do you mean rpmsg? Here, I do not see how we could benefit from it.
using same message format instead of inventing new one will be really
good step:
https://github.com/OpenAMP/open-amp/wiki/RPMsg-Messaging-Protocol
(less code duplicating same functionality)
Looks like every company trying to solve the same problem over and over
again. We have point to point link between two systems. Each system has
multiple functionalities/applications so we should be able to address
this functionality. So we end to some thing with source address and
destination address. In all protocols used for inter processor/chip
communication, the difference is only the layout of 3 common fields:
source, destination and size. In many cases the ISO/OSI layer model is
badly broken and
> Can you point me to an example where rpmsg is used over SPI?
RPMsg is just transport layer, 5 or 6 wire SPI is in this case Physical
layer with flow control support. Currently i'm not sure if VirtIO with
queue support do make sense here.
> Greetings,
> Mark
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
@ 2018-06-07 15:14 Jonas Mark (BT-FIR/ENG1)
2018-06-11 4:41 ` Oleksij Rempel
0 siblings, 1 reply; 9+ messages in thread
From: Jonas Mark (BT-FIR/ENG1) @ 2018-06-07 15:14 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Wolfgang Grandegger, Marc Kleine-Budde, linux-can, netdev,
Linux Kernel Mailing List, Heiko Schocher,
ZHU Yi (BT-FIR/ENG1-Zhu)
Hi Andy,
> > The functionality bases on an external peripheral chip named Companion.
> > It offers two CAN interfaces, each has 8 prioritized transmit FIFOs as
> > well as one receive FIFO. Besides CAN, undisclosed additional functions
> > can be accessed through the char device.
> >
> > A standard SPI interface with two additional lines for flow control is
> > used. The Companion chip is the SPI slave.
>
> Can remoteproc API be utilized here?
So far I wasn't aware of the remoteproc API. It appears to me that is
limited to power on/off and loading firmware in an AMP scenario. Here,
the Companion has a fixed firmware in it. It must already be running
quickly after power-up, even before the boot loader.
Does remoteproc also contain a communication framework?
Do you mean rpmsg? Here, I do not see how we could benefit from it.
Can you point me to an example where rpmsg is used over SPI?
Greetings,
Mark
Building Technologies, Panel Software Fire (BT-FIR/ENG1)
Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118
Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
2018-06-07 8:06 Jonas Mark (BT-FIR/ENG1)
@ 2018-06-07 9:49 ` Oliver Hartkopp
0 siblings, 0 replies; 9+ messages in thread
From: Oliver Hartkopp @ 2018-06-07 9:49 UTC (permalink / raw)
To: Jonas Mark (BT-FIR/ENG1), Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can, netdev, linux-kernel, hs, ZHU Yi (BT-FIR/ENG1-Zhu)
On 06/07/2018 10:06 AM, Jonas Mark (BT-FIR/ENG1) wrote:
> Hi Oliver,
>
>>> The driver suite consists of three separate drivers. The following
>>> diagram illustrates the dependencies in layers.
>>>
>>> /dev/companion SocketCAN User Space
>>> -------------------------------------------------------------------
>>> +----------------+ +---------------+
>>> | companion-char | | companion-can |
>>> +----------------+ +---------------+
>>> +----------------------------------+
>>> | companion-spi |
>>> +----------------------------------+
>>> +----------------------------------+
>>> | standard SPI subsystem |
>>> +----------------------------------+ Linux Kernel
>>> -------------------------------------------------------------------
>>> | | | | | | Hardware
>>> CS-+ | | | | +-BUSY
>>> CLK--+ | | +---REQUEST
>>> MOSI---+ |
>>> MISO-----+
>>>
>>> companion-spi
>>> core.c: handles SPI, sysfs entry and interface to upper layer
>>> protocol-manager.c: handles protocol with the SPI HW
>>> queue-manager.c: handles buffering and packets scheduling
>>>
>>> companion-can
>>> makes use of multi-queue support and allows to use tc to configure
>>> the queuing discipline (e.g. mqprio). Together with the SO_PRIORITY
>>> socket option this allows to specify the FIFO a CAN frame shall be
>>> sent to.
>>>
>>> companion-char
>>> handles messages to other undisclosed functionality beyond CAN.
>
>>> .../devicetree/bindings/spi/bosch,companion.txt | 82 ++
>>> drivers/char/Kconfig | 7 +
>>> drivers/char/Makefile | 2 +
>>> drivers/char/companion-char.c | 367 ++++++
>>> drivers/net/can/Kconfig | 8 +
>>> drivers/net/can/Makefile | 1 +
>>> drivers/net/can/companion-can.c | 694 ++++++++++++
>>
>> Please place the companion driver in
>>
>> drivers/net/can/spi/companion.c
>>
>> It also makes more sense in the Kconfig structure.
>>
>> Probably this naming scheme also makes sense for
>>
>> linux/drivers/char/spi/companion.c
>>
>> then ...
>>
>> If not it should be named at least
>>
>> drivers/char/companion-spi.c
>>
>> or
>>
>> drivers/char/spi-companion.c
>
> We intentionally left out the spi in the driver path / name because
> only the drivers/spi/companion/* driver knows that that it is connected
> to SPI. The others (drivers/net/can/companion-can.c and
> drivers/char/companion-char.c) only know the API. This could also be
> supplied by a driver which talks to the Companion via a different
> interface. Actually, we started with a UART connection but switched to
> SPI due to latency issues.
Ok, got it.
> Should we still change it?
At least I would then vote for
drivers/char/companion.c
drivers/net/can/companion.c
instead of
drivers/char/companion-char.c
drivers/net/can/companion-can.c
as you would have companion-users in different driver subsystems that
are already clearly referenced by their path.
The modules itself should still be named with companion-can of course
(as-is right now).
Btw.
+#define DRIVER_NAME "bosch,companion-can"
+static const struct can_bittiming_const companion_can_bittiming_const = {
+ .name = "bosch,companion",
Is there any reason why it's not only "companion-can" or "companion"?
The fact that the driver is provided by Bosch is visible in the source code.
Best regards,
Oliver
>
>>> drivers/net/can/dev.c | 8 +-
>>> drivers/spi/Kconfig | 2 +
>>> drivers/spi/Makefile | 2 +
>>> drivers/spi/companion/Kconfig | 5 +
>>> drivers/spi/companion/Makefile | 2 +
>>> drivers/spi/companion/core.c | 1189 ++++++++++++++++++++
>>> drivers/spi/companion/protocol-manager.c | 1035 +++++++++++++++++
>>> drivers/spi/companion/protocol-manager.h | 348 ++++++
>>> drivers/spi/companion/protocol.h | 273 +++++
>>> drivers/spi/companion/queue-manager.c | 146 +++
>>> drivers/spi/companion/queue-manager.h | 245 ++++
>>> include/linux/can/dev.h | 7 +-
>>> include/linux/companion.h | 258 +++++
>>> 20 files changed, 4677 insertions(+), 4 deletions(-)
>>> create mode 100644
>> Documentation/devicetree/bindings/spi/bosch,companion.txt
>>> create mode 100644 drivers/char/companion-char.c
>>> create mode 100644 drivers/net/can/companion-can.c
>>> create mode 100644 drivers/spi/companion/Kconfig
>>> create mode 100644 drivers/spi/companion/Makefile
>>> create mode 100644 drivers/spi/companion/core.c
>>> create mode 100644 drivers/spi/companion/protocol-manager.c
>>> create mode 100644 drivers/spi/companion/protocol-manager.h
>>> create mode 100644 drivers/spi/companion/protocol.h
>>> create mode 100644 drivers/spi/companion/queue-manager.c
>>> create mode 100644 drivers/spi/companion/queue-manager.h
>>> create mode 100644 include/linux/companion.h
>
> Greetings,
> Mark
>
> Building Technologies, Panel Software Fire (BT-FIR/ENG1)
> Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com
>
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118
> Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
@ 2018-06-07 8:06 Jonas Mark (BT-FIR/ENG1)
2018-06-07 9:49 ` Oliver Hartkopp
0 siblings, 1 reply; 9+ messages in thread
From: Jonas Mark (BT-FIR/ENG1) @ 2018-06-07 8:06 UTC (permalink / raw)
To: Oliver Hartkopp, Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can, netdev, linux-kernel, hs, ZHU Yi (BT-FIR/ENG1-Zhu)
Hi Oliver,
> > The driver suite consists of three separate drivers. The following
> > diagram illustrates the dependencies in layers.
> >
> > /dev/companion SocketCAN User Space
> > -------------------------------------------------------------------
> > +----------------+ +---------------+
> > | companion-char | | companion-can |
> > +----------------+ +---------------+
> > +----------------------------------+
> > | companion-spi |
> > +----------------------------------+
> > +----------------------------------+
> > | standard SPI subsystem |
> > +----------------------------------+ Linux Kernel
> > -------------------------------------------------------------------
> > | | | | | | Hardware
> > CS-+ | | | | +-BUSY
> > CLK--+ | | +---REQUEST
> > MOSI---+ |
> > MISO-----+
> >
> > companion-spi
> > core.c: handles SPI, sysfs entry and interface to upper layer
> > protocol-manager.c: handles protocol with the SPI HW
> > queue-manager.c: handles buffering and packets scheduling
> >
> > companion-can
> > makes use of multi-queue support and allows to use tc to configure
> > the queuing discipline (e.g. mqprio). Together with the SO_PRIORITY
> > socket option this allows to specify the FIFO a CAN frame shall be
> > sent to.
> >
> > companion-char
> > handles messages to other undisclosed functionality beyond CAN.
> > .../devicetree/bindings/spi/bosch,companion.txt | 82 ++
> > drivers/char/Kconfig | 7 +
> > drivers/char/Makefile | 2 +
> > drivers/char/companion-char.c | 367 ++++++
> > drivers/net/can/Kconfig | 8 +
> > drivers/net/can/Makefile | 1 +
> > drivers/net/can/companion-can.c | 694 ++++++++++++
>
> Please place the companion driver in
>
> drivers/net/can/spi/companion.c
>
> It also makes more sense in the Kconfig structure.
>
> Probably this naming scheme also makes sense for
>
> linux/drivers/char/spi/companion.c
>
> then ...
>
> If not it should be named at least
>
> drivers/char/companion-spi.c
>
> or
>
> drivers/char/spi-companion.c
We intentionally left out the spi in the driver path / name because
only the drivers/spi/companion/* driver knows that that it is connected
to SPI. The others (drivers/net/can/companion-can.c and
drivers/char/companion-char.c) only know the API. This could also be
supplied by a driver which talks to the Companion via a different
interface. Actually, we started with a UART connection but switched to
SPI due to latency issues.
Should we still change it?
> > drivers/net/can/dev.c | 8 +-
> > drivers/spi/Kconfig | 2 +
> > drivers/spi/Makefile | 2 +
> > drivers/spi/companion/Kconfig | 5 +
> > drivers/spi/companion/Makefile | 2 +
> > drivers/spi/companion/core.c | 1189 ++++++++++++++++++++
> > drivers/spi/companion/protocol-manager.c | 1035 +++++++++++++++++
> > drivers/spi/companion/protocol-manager.h | 348 ++++++
> > drivers/spi/companion/protocol.h | 273 +++++
> > drivers/spi/companion/queue-manager.c | 146 +++
> > drivers/spi/companion/queue-manager.h | 245 ++++
> > include/linux/can/dev.h | 7 +-
> > include/linux/companion.h | 258 +++++
> > 20 files changed, 4677 insertions(+), 4 deletions(-)
> > create mode 100644
> Documentation/devicetree/bindings/spi/bosch,companion.txt
> > create mode 100644 drivers/char/companion-char.c
> > create mode 100644 drivers/net/can/companion-can.c
> > create mode 100644 drivers/spi/companion/Kconfig
> > create mode 100644 drivers/spi/companion/Makefile
> > create mode 100644 drivers/spi/companion/core.c
> > create mode 100644 drivers/spi/companion/protocol-manager.c
> > create mode 100644 drivers/spi/companion/protocol-manager.h
> > create mode 100644 drivers/spi/companion/protocol.h
> > create mode 100644 drivers/spi/companion/queue-manager.c
> > create mode 100644 drivers/spi/companion/queue-manager.h
> > create mode 100644 include/linux/companion.h
Greetings,
Mark
Building Technologies, Panel Software Fire (BT-FIR/ENG1)
Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118
Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
2018-06-05 18:43 ` Mark Jonas
(?)
(?)
@ 2018-06-07 7:22 ` Oliver Hartkopp
-1 siblings, 0 replies; 9+ messages in thread
From: Oliver Hartkopp @ 2018-06-07 7:22 UTC (permalink / raw)
To: Mark Jonas, Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can, netdev, linux-kernel, hs, yi.zhu5
On 06/05/2018 08:43 PM, Mark Jonas wrote:
> Upon request by Marc Kleine-Budde this patch series does not only
> contain our patch to enable enable multi-queue for SocketCAN devices
> but also a driver (Companion driver suite) which makes active use of
> this feature.
>
> The driver suite implements
> - two CAN interfaces
> - one generic command interfaces
> and offers a SocketCAN as well as a char device interface. The
> SocketCAN interface supports multi-queue.
>
> The functionality bases on an external peripheral chip named Companion.
> It offers two CAN interfaces, each has 8 prioritized transmit FIFOs as
> well as one receive FIFO. Besides CAN, undisclosed additional functions
> can be accessed through the char device.
>
> A standard SPI interface with two additional lines for flow control is
> used. The Companion chip is the SPI slave.
>
> The driver suite consists of three separate drivers. The following
> diagram illustrates the dependencies in layers.
>
> /dev/companion SocketCAN User Space
> -------------------------------------------------------------------
> +----------------+ +---------------+
> | companion-char | | companion-can |
> +----------------+ +---------------+
> +----------------------------------+
> | companion-spi |
> +----------------------------------+
> +----------------------------------+
> | standard SPI subsystem |
> +----------------------------------+ Linux Kernel
> -------------------------------------------------------------------
> | | | | | | Hardware
> CS-+ | | | | +-BUSY
> CLK--+ | | +---REQUEST
> MOSI---+ |
> MISO-----+
>
> companion-spi
> core.c: handles SPI, sysfs entry and interface to upper layer
> protocol-manager.c: handles protocol with the SPI HW
> queue-manager.c: handles buffering and packets scheduling
>
> companion-can
> makes use of multi-queue support and allows to use tc to configure
> the queuing discipline (e.g. mqprio). Together with the SO_PRIORITY
> socket option this allows to specify the FIFO a CAN frame shall be
> sent to.
>
> companion-char
> handles messages to other undisclosed functionality beyond CAN.
>
> Zhu Yi (5):
> can: enable multi-queue for SocketCAN devices
> spi: implement companion-spi driver
> char: implement companion-char driver
> can: implement companion-can driver
> spi,can,char: add companion DT binding documentation
>
> .../devicetree/bindings/spi/bosch,companion.txt | 82 ++
> drivers/char/Kconfig | 7 +
> drivers/char/Makefile | 2 +
> drivers/char/companion-char.c | 367 ++++++
> drivers/net/can/Kconfig | 8 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/companion-can.c | 694 ++++++++++++
Please place the companion driver in
drivers/net/can/spi/companion.c
It also makes more sense in the Kconfig structure.
Probably this naming scheme also makes sense for
linux/drivers/char/spi/companion.c
then ...
If not it should be named at least
drivers/char/companion-spi.c
or
drivers/char/spi-companion.c
BR Oliver
> drivers/net/can/dev.c | 8 +-
> drivers/spi/Kconfig | 2 +
> drivers/spi/Makefile | 2 +
> drivers/spi/companion/Kconfig | 5 +
> drivers/spi/companion/Makefile | 2 +
> drivers/spi/companion/core.c | 1189 ++++++++++++++++++++
> drivers/spi/companion/protocol-manager.c | 1035 +++++++++++++++++
> drivers/spi/companion/protocol-manager.h | 348 ++++++
> drivers/spi/companion/protocol.h | 273 +++++
> drivers/spi/companion/queue-manager.c | 146 +++
> drivers/spi/companion/queue-manager.h | 245 ++++
> include/linux/can/dev.h | 7 +-
> include/linux/companion.h | 258 +++++
> 20 files changed, 4677 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/bosch,companion.txt
> create mode 100644 drivers/char/companion-char.c
> create mode 100644 drivers/net/can/companion-can.c
> create mode 100644 drivers/spi/companion/Kconfig
> create mode 100644 drivers/spi/companion/Makefile
> create mode 100644 drivers/spi/companion/core.c
> create mode 100644 drivers/spi/companion/protocol-manager.c
> create mode 100644 drivers/spi/companion/protocol-manager.h
> create mode 100644 drivers/spi/companion/protocol.h
> create mode 100644 drivers/spi/companion/queue-manager.c
> create mode 100644 drivers/spi/companion/queue-manager.h
> create mode 100644 include/linux/companion.h
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
2018-06-05 18:43 ` Mark Jonas
(?)
@ 2018-06-06 18:06 ` Andy Shevchenko
-1 siblings, 0 replies; 9+ messages in thread
From: Andy Shevchenko @ 2018-06-06 18:06 UTC (permalink / raw)
To: Mark Jonas
Cc: Wolfgang Grandegger, Marc Kleine-Budde, linux-can, netdev,
Linux Kernel Mailing List, Heiko Schocher, Zhu Yi
On Tue, Jun 5, 2018 at 9:43 PM, Mark Jonas <mark.jonas@de.bosch.com> wrote:
> Upon request by Marc Kleine-Budde this patch series does not only
> contain our patch to enable enable multi-queue for SocketCAN devices
> but also a driver (Companion driver suite) which makes active use of
> this feature.
>
> The driver suite implements
> - two CAN interfaces
> - one generic command interfaces
> and offers a SocketCAN as well as a char device interface. The
> SocketCAN interface supports multi-queue.
>
> The functionality bases on an external peripheral chip named Companion.
> It offers two CAN interfaces, each has 8 prioritized transmit FIFOs as
> well as one receive FIFO. Besides CAN, undisclosed additional functions
> can be accessed through the char device.
>
> A standard SPI interface with two additional lines for flow control is
> used. The Companion chip is the SPI slave.
Can remoteproc API be utilized here?
>
> The driver suite consists of three separate drivers. The following
> diagram illustrates the dependencies in layers.
>
> /dev/companion SocketCAN User Space
> -------------------------------------------------------------------
> +----------------+ +---------------+
> | companion-char | | companion-can |
> +----------------+ +---------------+
> +----------------------------------+
> | companion-spi |
> +----------------------------------+
> +----------------------------------+
> | standard SPI subsystem |
> +----------------------------------+ Linux Kernel
> -------------------------------------------------------------------
> | | | | | | Hardware
> CS-+ | | | | +-BUSY
> CLK--+ | | +---REQUEST
> MOSI---+ |
> MISO-----+
>
> companion-spi
> core.c: handles SPI, sysfs entry and interface to upper layer
> protocol-manager.c: handles protocol with the SPI HW
> queue-manager.c: handles buffering and packets scheduling
>
> companion-can
> makes use of multi-queue support and allows to use tc to configure
> the queuing discipline (e.g. mqprio). Together with the SO_PRIORITY
> socket option this allows to specify the FIFO a CAN frame shall be
> sent to.
>
> companion-char
> handles messages to other undisclosed functionality beyond CAN.
>
> Zhu Yi (5):
> can: enable multi-queue for SocketCAN devices
> spi: implement companion-spi driver
> char: implement companion-char driver
> can: implement companion-can driver
> spi,can,char: add companion DT binding documentation
>
> .../devicetree/bindings/spi/bosch,companion.txt | 82 ++
> drivers/char/Kconfig | 7 +
> drivers/char/Makefile | 2 +
> drivers/char/companion-char.c | 367 ++++++
> drivers/net/can/Kconfig | 8 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/companion-can.c | 694 ++++++++++++
> drivers/net/can/dev.c | 8 +-
> drivers/spi/Kconfig | 2 +
> drivers/spi/Makefile | 2 +
> drivers/spi/companion/Kconfig | 5 +
> drivers/spi/companion/Makefile | 2 +
> drivers/spi/companion/core.c | 1189 ++++++++++++++++++++
> drivers/spi/companion/protocol-manager.c | 1035 +++++++++++++++++
> drivers/spi/companion/protocol-manager.h | 348 ++++++
> drivers/spi/companion/protocol.h | 273 +++++
> drivers/spi/companion/queue-manager.c | 146 +++
> drivers/spi/companion/queue-manager.h | 245 ++++
> include/linux/can/dev.h | 7 +-
> include/linux/companion.h | 258 +++++
> 20 files changed, 4677 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/bosch,companion.txt
> create mode 100644 drivers/char/companion-char.c
> create mode 100644 drivers/net/can/companion-can.c
> create mode 100644 drivers/spi/companion/Kconfig
> create mode 100644 drivers/spi/companion/Makefile
> create mode 100644 drivers/spi/companion/core.c
> create mode 100644 drivers/spi/companion/protocol-manager.c
> create mode 100644 drivers/spi/companion/protocol-manager.h
> create mode 100644 drivers/spi/companion/protocol.h
> create mode 100644 drivers/spi/companion/queue-manager.c
> create mode 100644 drivers/spi/companion/queue-manager.h
> create mode 100644 include/linux/companion.h
>
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 0/5] can: enable multi-queue for SocketCAN devices
@ 2018-06-05 18:43 ` Mark Jonas
0 siblings, 0 replies; 9+ messages in thread
From: Mark Jonas @ 2018-06-05 18:43 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can, netdev, linux-kernel, hs, yi.zhu5, Mark Jonas
Upon request by Marc Kleine-Budde this patch series does not only
contain our patch to enable enable multi-queue for SocketCAN devices
but also a driver (Companion driver suite) which makes active use of
this feature.
The driver suite implements
- two CAN interfaces
- one generic command interfaces
and offers a SocketCAN as well as a char device interface. The
SocketCAN interface supports multi-queue.
The functionality bases on an external peripheral chip named Companion.
It offers two CAN interfaces, each has 8 prioritized transmit FIFOs as
well as one receive FIFO. Besides CAN, undisclosed additional functions
can be accessed through the char device.
A standard SPI interface with two additional lines for flow control is
used. The Companion chip is the SPI slave.
The driver suite consists of three separate drivers. The following
diagram illustrates the dependencies in layers.
/dev/companion SocketCAN User Space
-------------------------------------------------------------------
+----------------+ +---------------+
| companion-char | | companion-can |
+----------------+ +---------------+
+----------------------------------+
| companion-spi |
+----------------------------------+
+----------------------------------+
| standard SPI subsystem |
+----------------------------------+ Linux Kernel
-------------------------------------------------------------------
| | | | | | Hardware
CS-+ | | | | +-BUSY
CLK--+ | | +---REQUEST
MOSI---+ |
MISO-----+
companion-spi
core.c: handles SPI, sysfs entry and interface to upper layer
protocol-manager.c: handles protocol with the SPI HW
queue-manager.c: handles buffering and packets scheduling
companion-can
makes use of multi-queue support and allows to use tc to configure
the queuing discipline (e.g. mqprio). Together with the SO_PRIORITY
socket option this allows to specify the FIFO a CAN frame shall be
sent to.
companion-char
handles messages to other undisclosed functionality beyond CAN.
Zhu Yi (5):
can: enable multi-queue for SocketCAN devices
spi: implement companion-spi driver
char: implement companion-char driver
can: implement companion-can driver
spi,can,char: add companion DT binding documentation
.../devicetree/bindings/spi/bosch,companion.txt | 82 ++
drivers/char/Kconfig | 7 +
drivers/char/Makefile | 2 +
drivers/char/companion-char.c | 367 ++++++
drivers/net/can/Kconfig | 8 +
drivers/net/can/Makefile | 1 +
drivers/net/can/companion-can.c | 694 ++++++++++++
drivers/net/can/dev.c | 8 +-
drivers/spi/Kconfig | 2 +
drivers/spi/Makefile | 2 +
drivers/spi/companion/Kconfig | 5 +
drivers/spi/companion/Makefile | 2 +
drivers/spi/companion/core.c | 1189 ++++++++++++++++++++
drivers/spi/companion/protocol-manager.c | 1035 +++++++++++++++++
drivers/spi/companion/protocol-manager.h | 348 ++++++
drivers/spi/companion/protocol.h | 273 +++++
drivers/spi/companion/queue-manager.c | 146 +++
drivers/spi/companion/queue-manager.h | 245 ++++
include/linux/can/dev.h | 7 +-
include/linux/companion.h | 258 +++++
20 files changed, 4677 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/bosch,companion.txt
create mode 100644 drivers/char/companion-char.c
create mode 100644 drivers/net/can/companion-can.c
create mode 100644 drivers/spi/companion/Kconfig
create mode 100644 drivers/spi/companion/Makefile
create mode 100644 drivers/spi/companion/core.c
create mode 100644 drivers/spi/companion/protocol-manager.c
create mode 100644 drivers/spi/companion/protocol-manager.h
create mode 100644 drivers/spi/companion/protocol.h
create mode 100644 drivers/spi/companion/queue-manager.c
create mode 100644 drivers/spi/companion/queue-manager.h
create mode 100644 include/linux/companion.h
--
2.7.4
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 0/5] can: enable multi-queue for SocketCAN devices
@ 2018-06-05 18:43 ` Mark Jonas
0 siblings, 0 replies; 9+ messages in thread
From: Mark Jonas @ 2018-06-05 18:43 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can, netdev, linux-kernel, hs, yi.zhu5, Mark Jonas
Upon request by Marc Kleine-Budde this patch series does not only
contain our patch to enable enable multi-queue for SocketCAN devices
but also a driver (Companion driver suite) which makes active use of
this feature.
The driver suite implements
- two CAN interfaces
- one generic command interfaces
and offers a SocketCAN as well as a char device interface. The
SocketCAN interface supports multi-queue.
The functionality bases on an external peripheral chip named Companion.
It offers two CAN interfaces, each has 8 prioritized transmit FIFOs as
well as one receive FIFO. Besides CAN, undisclosed additional functions
can be accessed through the char device.
A standard SPI interface with two additional lines for flow control is
used. The Companion chip is the SPI slave.
The driver suite consists of three separate drivers. The following
diagram illustrates the dependencies in layers.
/dev/companion SocketCAN User Space
-------------------------------------------------------------------
+----------------+ +---------------+
| companion-char | | companion-can |
+----------------+ +---------------+
+----------------------------------+
| companion-spi |
+----------------------------------+
+----------------------------------+
| standard SPI subsystem |
+----------------------------------+ Linux Kernel
-------------------------------------------------------------------
| | | | | | Hardware
CS-+ | | | | +-BUSY
CLK--+ | | +---REQUEST
MOSI---+ |
MISO-----+
companion-spi
core.c: handles SPI, sysfs entry and interface to upper layer
protocol-manager.c: handles protocol with the SPI HW
queue-manager.c: handles buffering and packets scheduling
companion-can
makes use of multi-queue support and allows to use tc to configure
the queuing discipline (e.g. mqprio). Together with the SO_PRIORITY
socket option this allows to specify the FIFO a CAN frame shall be
sent to.
companion-char
handles messages to other undisclosed functionality beyond CAN.
Zhu Yi (5):
can: enable multi-queue for SocketCAN devices
spi: implement companion-spi driver
char: implement companion-char driver
can: implement companion-can driver
spi,can,char: add companion DT binding documentation
.../devicetree/bindings/spi/bosch,companion.txt | 82 ++
drivers/char/Kconfig | 7 +
drivers/char/Makefile | 2 +
drivers/char/companion-char.c | 367 ++++++
drivers/net/can/Kconfig | 8 +
drivers/net/can/Makefile | 1 +
drivers/net/can/companion-can.c | 694 ++++++++++++
drivers/net/can/dev.c | 8 +-
drivers/spi/Kconfig | 2 +
drivers/spi/Makefile | 2 +
drivers/spi/companion/Kconfig | 5 +
drivers/spi/companion/Makefile | 2 +
drivers/spi/companion/core.c | 1189 ++++++++++++++++++++
drivers/spi/companion/protocol-manager.c | 1035 +++++++++++++++++
drivers/spi/companion/protocol-manager.h | 348 ++++++
drivers/spi/companion/protocol.h | 273 +++++
drivers/spi/companion/queue-manager.c | 146 +++
drivers/spi/companion/queue-manager.h | 245 ++++
include/linux/can/dev.h | 7 +-
include/linux/companion.h | 258 +++++
20 files changed, 4677 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/bosch,companion.txt
create mode 100644 drivers/char/companion-char.c
create mode 100644 drivers/net/can/companion-can.c
create mode 100644 drivers/spi/companion/Kconfig
create mode 100644 drivers/spi/companion/Makefile
create mode 100644 drivers/spi/companion/core.c
create mode 100644 drivers/spi/companion/protocol-manager.c
create mode 100644 drivers/spi/companion/protocol-manager.h
create mode 100644 drivers/spi/companion/protocol.h
create mode 100644 drivers/spi/companion/queue-manager.c
create mode 100644 drivers/spi/companion/queue-manager.h
create mode 100644 include/linux/companion.h
--
2.7.4
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-06-11 4:41 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-07 15:20 [PATCH 0/5] can: enable multi-queue for SocketCAN devices Jonas Mark (BT-FIR/ENG1)
-- strict thread matches above, loose matches on Subject: below --
2018-06-07 15:14 Jonas Mark (BT-FIR/ENG1)
2018-06-11 4:41 ` Oleksij Rempel
2018-06-07 8:06 Jonas Mark (BT-FIR/ENG1)
2018-06-07 9:49 ` Oliver Hartkopp
2018-06-05 18:43 Mark Jonas
2018-06-05 18:43 ` Mark Jonas
2018-06-06 18:06 ` Andy Shevchenko
2018-06-07 7:22 ` Oliver Hartkopp
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.