LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* 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; 8+ 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] 8+ messages in thread

* Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
  2018-06-07 15:14 [PATCH 0/5] can: enable multi-queue for SocketCAN devices Jonas Mark (BT-FIR/ENG1)
@ 2018-06-11  4:41 ` Oleksij Rempel
  0 siblings, 0 replies; 8+ 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] 8+ messages in thread

* 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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
@ 2018-06-07  7:22 ` Oliver Hartkopp
  1 sibling, 0 replies; 8+ 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] 8+ 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
  2018-06-07  7:22 ` Oliver Hartkopp
  1 sibling, 0 replies; 8+ 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] 8+ messages in thread

* [PATCH 0/5] can: enable multi-queue for SocketCAN devices
@ 2018-06-05 18:43 Mark Jonas
  2018-06-06 18:06 ` Andy Shevchenko
  2018-06-07  7:22 ` Oliver Hartkopp
  0 siblings, 2 replies; 8+ 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] 8+ messages in thread

end of thread, other threads:[~2018-06-11  4:42 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-07 15:14 [PATCH 0/5] can: enable multi-queue for SocketCAN devices Jonas Mark (BT-FIR/ENG1)
2018-06-11  4:41 ` Oleksij Rempel
  -- strict thread matches above, loose matches on Subject: below --
2018-06-07 15:20 Jonas Mark (BT-FIR/ENG1)
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-06 18:06 ` Andy Shevchenko
2018-06-07  7:22 ` Oliver Hartkopp

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).