From: wg@grandegger.com (Wolfgang Grandegger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/1] can: add pruss CAN driver.
Date: Thu, 12 May 2011 09:04:40 +0200 [thread overview]
Message-ID: <4DCB8688.7070400@grandegger.com> (raw)
In-Reply-To: <201105112331.47954.arnd@arndb.de>
On 05/11/2011 11:31 PM, Arnd Bergmann wrote:
> On Tuesday 10 May 2011, Subhasish Ghosh wrote:
>>
>>>> Yes, In case if we allow the ALL implementation, it hogs the CPU.
>>>> In that case we do not need the PRU. The whole purpose of the PRU
>>>> is to offload the processor for any such implementations.
>>>
>>> So the kernel presumably needs to switch between using the PRU and native
>>> according to the number of ids being requested at the time ?
>>
>> All the IDs are programmed into the PRU data RAM.
>> The Kernel receives interrupts based upon these IDs.
>> I could not clearly follow "PRU and native", could you please elaborate.
>
> We would really like all CAN drivers to behave the same way. All other
> drivers are able to work without filters, so pruss_can should allow that
> too, even if it becomes a CPU hog at that time.
>
> It seems to me that the pruss can implementation has one thing backwards:
> it assumes a specific usage model for CAN that it is trying to do offload
> for. However, that usage model is currently not even supported by Socket
> CAN. If I understand Wolfgang correctly, it is in fact considered an
> unwanted limitation of the pruss can driver, instead of a useful feature.
"Unwanted" is not the right word. I see it as a piece of CAN hardware
with some serious limitations and I doubt that it will make real CAN
users happy. But well, I might be wrong.
> If that interpretation is right, I would seriously recommend rethinking
> the design of the CAN firmware for pruss, so you can start doing something
> useful with the offload engine that fits into the Socket CAN API, or that
> would be a useful extension to Socket CAN that is also implementable in
> the kernel for all other drivers in a meaningful way.
It would be really nice if they could provide a better firmware. Anyway,
the generic CAN hardware filter interface we spoke about in a previous
mail would fit for the PRUSS CAN hardware as well. It just needs to be
implemented.
Wolfgang.
WARNING: multiple messages have this Message-ID (diff)
From: Wolfgang Grandegger <wg@grandegger.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Subhasish Ghosh <subhasish@mistralsolutions.com>,
sachi@mistralsolutions.com,
davinci-linux-open-source@linux.davincidsp.com,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Netdev@vger.kernel.org, nsekhar@ti.com,
open list <linux-kernel@vger.kernel.org>,
CAN NETWORK DRIVERS <socketcan-core@lists.berlios.de>,
Marc Kleine-Budde <mkl@pengutronix.de>,
m-watkins@ti.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/1] can: add pruss CAN driver.
Date: Thu, 12 May 2011 09:04:40 +0200 [thread overview]
Message-ID: <4DCB8688.7070400@grandegger.com> (raw)
In-Reply-To: <201105112331.47954.arnd@arndb.de>
On 05/11/2011 11:31 PM, Arnd Bergmann wrote:
> On Tuesday 10 May 2011, Subhasish Ghosh wrote:
>>
>>>> Yes, In case if we allow the ALL implementation, it hogs the CPU.
>>>> In that case we do not need the PRU. The whole purpose of the PRU
>>>> is to offload the processor for any such implementations.
>>>
>>> So the kernel presumably needs to switch between using the PRU and native
>>> according to the number of ids being requested at the time ?
>>
>> All the IDs are programmed into the PRU data RAM.
>> The Kernel receives interrupts based upon these IDs.
>> I could not clearly follow "PRU and native", could you please elaborate.
>
> We would really like all CAN drivers to behave the same way. All other
> drivers are able to work without filters, so pruss_can should allow that
> too, even if it becomes a CPU hog at that time.
>
> It seems to me that the pruss can implementation has one thing backwards:
> it assumes a specific usage model for CAN that it is trying to do offload
> for. However, that usage model is currently not even supported by Socket
> CAN. If I understand Wolfgang correctly, it is in fact considered an
> unwanted limitation of the pruss can driver, instead of a useful feature.
"Unwanted" is not the right word. I see it as a piece of CAN hardware
with some serious limitations and I doubt that it will make real CAN
users happy. But well, I might be wrong.
> If that interpretation is right, I would seriously recommend rethinking
> the design of the CAN firmware for pruss, so you can start doing something
> useful with the offload engine that fits into the Socket CAN API, or that
> would be a useful extension to Socket CAN that is also implementable in
> the kernel for all other drivers in a meaningful way.
It would be really nice if they could provide a better firmware. Anyway,
the generic CAN hardware filter interface we spoke about in a previous
mail would fit for the PRUSS CAN hardware as well. It just needs to be
implemented.
Wolfgang.
WARNING: multiple messages have this Message-ID (diff)
From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org,
Subhasish Ghosh
<subhasish-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org>,
nsekhar-l0cyMroinI0@public.gmane.org,
open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
CAN NETWORK DRIVERS
<socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org>,
Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
m-watkins-l0cyMroinI0@public.gmane.org,
Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
Subject: Re: [PATCH v4 1/1] can: add pruss CAN driver.
Date: Thu, 12 May 2011 09:04:40 +0200 [thread overview]
Message-ID: <4DCB8688.7070400@grandegger.com> (raw)
In-Reply-To: <201105112331.47954.arnd-r2nGTMty4D4@public.gmane.org>
On 05/11/2011 11:31 PM, Arnd Bergmann wrote:
> On Tuesday 10 May 2011, Subhasish Ghosh wrote:
>>
>>>> Yes, In case if we allow the ALL implementation, it hogs the CPU.
>>>> In that case we do not need the PRU. The whole purpose of the PRU
>>>> is to offload the processor for any such implementations.
>>>
>>> So the kernel presumably needs to switch between using the PRU and native
>>> according to the number of ids being requested at the time ?
>>
>> All the IDs are programmed into the PRU data RAM.
>> The Kernel receives interrupts based upon these IDs.
>> I could not clearly follow "PRU and native", could you please elaborate.
>
> We would really like all CAN drivers to behave the same way. All other
> drivers are able to work without filters, so pruss_can should allow that
> too, even if it becomes a CPU hog at that time.
>
> It seems to me that the pruss can implementation has one thing backwards:
> it assumes a specific usage model for CAN that it is trying to do offload
> for. However, that usage model is currently not even supported by Socket
> CAN. If I understand Wolfgang correctly, it is in fact considered an
> unwanted limitation of the pruss can driver, instead of a useful feature.
"Unwanted" is not the right word. I see it as a piece of CAN hardware
with some serious limitations and I doubt that it will make real CAN
users happy. But well, I might be wrong.
> If that interpretation is right, I would seriously recommend rethinking
> the design of the CAN firmware for pruss, so you can start doing something
> useful with the offload engine that fits into the Socket CAN API, or that
> would be a useful extension to Socket CAN that is also implementable in
> the kernel for all other drivers in a meaningful way.
It would be really nice if they could provide a better firmware. Anyway,
the generic CAN hardware filter interface we spoke about in a previous
mail would fit for the PRUSS CAN hardware as well. It just needs to be
implemented.
Wolfgang.
next prev parent reply other threads:[~2011-05-12 7:04 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-22 12:11 [PATCH v4 0/1] pruss CAN driver Subhasish Ghosh
2011-04-22 12:11 ` [PATCH v4 1/1] can: add " Subhasish Ghosh
2011-04-22 12:11 ` Subhasish Ghosh
2011-04-22 15:50 ` Marc Kleine-Budde
2011-04-22 15:50 ` Marc Kleine-Budde
2011-04-25 20:06 ` Wolfgang Grandegger
2011-04-25 20:06 ` Wolfgang Grandegger
2011-04-25 20:06 ` Wolfgang Grandegger
2011-04-27 13:08 ` Subhasish Ghosh
2011-04-27 13:08 ` Subhasish Ghosh
2011-04-27 13:08 ` Subhasish Ghosh
2011-04-27 13:21 ` Marc Kleine-Budde
2011-04-27 13:21 ` Marc Kleine-Budde
2011-04-27 13:21 ` Marc Kleine-Budde
2011-04-27 13:25 ` Arnd Bergmann
2011-04-27 13:25 ` Arnd Bergmann
2011-04-27 13:25 ` Arnd Bergmann
2011-05-04 7:13 ` Subhasish Ghosh
2011-05-04 7:13 ` Subhasish Ghosh
2011-05-04 7:13 ` Subhasish Ghosh
2011-05-04 13:11 ` Arnd Bergmann
2011-05-04 13:11 ` Arnd Bergmann
2011-05-04 13:11 ` Arnd Bergmann
2011-05-04 14:33 ` Wolfgang Grandegger
2011-05-04 14:33 ` Wolfgang Grandegger
2011-05-04 14:33 ` Wolfgang Grandegger
2011-05-04 14:48 ` Arnd Bergmann
2011-05-04 14:48 ` Arnd Bergmann
2011-05-04 14:48 ` Arnd Bergmann
2011-05-04 16:00 ` Wolfgang Grandegger
2011-05-04 16:00 ` Wolfgang Grandegger
2011-05-04 16:00 ` Wolfgang Grandegger
2011-05-10 10:11 ` Subhasish Ghosh
2011-05-10 10:11 ` Subhasish Ghosh
2011-05-10 10:11 ` Subhasish Ghosh
2011-05-10 10:27 ` Alan Cox
2011-05-10 10:27 ` Alan Cox
2011-05-10 10:27 ` Alan Cox
2011-05-10 12:21 ` Subhasish Ghosh
2011-05-10 12:21 ` Subhasish Ghosh
2011-05-10 12:21 ` Subhasish Ghosh
2011-05-11 21:31 ` Arnd Bergmann
2011-05-11 21:31 ` Arnd Bergmann
2011-05-11 21:31 ` Arnd Bergmann
2011-05-11 21:44 ` Arnd Bergmann
2011-05-11 21:44 ` Arnd Bergmann
2011-05-11 21:44 ` Arnd Bergmann
2011-05-11 22:39 ` Marc Kleine-Budde
2011-05-11 22:39 ` Marc Kleine-Budde
2011-05-11 22:39 ` Marc Kleine-Budde
2011-05-11 22:56 ` Alan Cox
2011-05-11 22:56 ` Alan Cox
2011-05-11 22:56 ` Alan Cox
2011-05-12 3:03 ` can: hardware vs. software filter Kurt Van Dijck
2011-05-12 3:03 ` Kurt Van Dijck
2011-05-12 7:13 ` [PATCH v4 1/1] can: add pruss CAN driver Wolfgang Grandegger
2011-05-12 7:13 ` Wolfgang Grandegger
2011-05-12 7:13 ` Wolfgang Grandegger
2011-05-12 10:58 ` Kurt Van Dijck
2011-05-12 10:58 ` Kurt Van Dijck
2011-05-12 10:58 ` Kurt Van Dijck
2011-05-12 12:54 ` Arnd Bergmann
2011-05-12 12:54 ` Arnd Bergmann
2011-05-12 12:54 ` Arnd Bergmann
2011-05-12 13:04 ` Marc Kleine-Budde
2011-05-12 13:04 ` Marc Kleine-Budde
2011-05-12 13:04 ` Marc Kleine-Budde
2011-05-12 14:41 ` Oliver Hartkopp
2011-05-12 14:41 ` Oliver Hartkopp
2011-05-12 14:41 ` Oliver Hartkopp
2011-05-22 10:30 ` Arnd Bergmann
2011-05-22 10:30 ` Arnd Bergmann
2011-05-22 10:30 ` Arnd Bergmann
2011-05-23 6:21 ` Oliver Hartkopp
2011-05-23 6:21 ` Oliver Hartkopp
2011-05-23 6:21 ` Oliver Hartkopp
2011-05-23 8:23 ` Marc Kleine-Budde
2011-05-23 8:23 ` Marc Kleine-Budde
2011-05-23 8:23 ` Marc Kleine-Budde
2011-05-27 8:31 ` Wolfgang Grandegger
2011-05-27 8:31 ` Wolfgang Grandegger
2011-05-27 8:31 ` Wolfgang Grandegger
2011-05-12 7:04 ` Wolfgang Grandegger [this message]
2011-05-12 7:04 ` Wolfgang Grandegger
2011-05-12 7:04 ` Wolfgang Grandegger
2011-05-04 15:57 ` Kurt Van Dijck
2011-05-04 15:57 ` Kurt Van Dijck
2011-05-04 15:57 ` Kurt Van Dijck
2011-05-04 16:09 ` Wolfgang Grandegger
2011-05-04 16:09 ` Wolfgang Grandegger
2011-05-04 16:09 ` Wolfgang Grandegger
2011-05-04 20:55 ` Oliver Hartkopp
2011-05-04 20:55 ` Oliver Hartkopp
2011-05-04 20:55 ` Oliver Hartkopp
2011-04-27 13:28 ` Wolfgang Grandegger
2011-04-27 13:28 ` Wolfgang Grandegger
2011-04-27 13:28 ` Wolfgang Grandegger
2011-04-27 13:34 ` Wolfgang Grandegger
2011-04-27 13:34 ` Wolfgang Grandegger
2011-04-27 13:34 ` Wolfgang Grandegger
2011-04-24 11:13 ` Marc Kleine-Budde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DCB8688.7070400@grandegger.com \
--to=wg@grandegger.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.