lkml.org 
[lkml]   [2024]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v1 00/16] Add missing features to FastRPC driver
From

On 2/2/2024 1:41 PM, neil.armstrong@linaro.org wrote:
> Hi,
>
> On 02/02/2024 07:40, Ekansh Gupta wrote:
>> This patch series adds the listed features that have been missing
>> in upstream fastRPC driver.
>>
>> - Redesign and improve remote heap management.
>> - Add static PD restart support for audio and sensors PD using
>>    PDR framework.
>> - Add changes to support multimode invocation ioctl request. This
>>    ioctl call facilitates multiple types of requests from user including
>>    CRC check, performance counters, shared context bank usage, etc.
>>    This series also carries patch to save and restore interrupted
>>    context.
>> - Add early wakeup support to allow DSP user to send early response
>>    to CPU and improve fastrpc performance.
>> - Add polling mode support with which driver polls on memory to avoid
>>    CPU from going to low power modes.
>> - Add notifications frameworks to provide users with the DSP PD status
>>    notifications.
>> - Add a control mechanism to allow users to clean up DSP user PD
>> - Add wakelock management support
>> - Add DSP signalling support
>> - Add check for untrusted applications and allow trusted processed to
>>    offload to system unsigned PD.
>
> Could you precise:
> - Which workload are you fixing
> - Which platforms are concerned
> - Which platforms were tested
>
1. This patch mostly consists of missing features from fastrpc driver and it doesn't
carry any bug fixes.
2. We are not targeting these changes for any specific platform. These features are
applicable for most of the recent platforms .
3. These changes were tested on SM8650 and QCM6490 platforms.

> So far I've been trying to run the "getserial" on SM8550-QRD and
> SM8650-QRD without
> success, would those changes fix this ?

Can you please help me with the "getserial" failure details? Or the steps that you are
running to get to the failure? I can have a look at that to understand the reason for
failure.

> Is there any chance we could get an open-source minimal implementation
> of a fastRPC SDK using
> the open-source Hexagon LLVM like we have for the AIC100 ?
> It would definitely help validating the upstream fastRPC implementation.

Generally Hexagon SDK is used to write and test fastRPC use-cases which is well documented.
Is there anything else that you can suggest would help here?

>
> Thanks,
> Neil
>
Hi Neil, added my comments.

--ekansh

>>
>> Ekansh Gupta (16):
>>    misc: fastrpc: Redesign remote heap management
>>    misc: fastrpc: Add support for unsigned PD
>>    misc: fastrpc: Add static PD restart support
>>    misc: fastrpc: Add fastrpc multimode invoke request support
>>    misc: fastrpc: Add CRC support for remote buffers
>>    misc: fastrpc: Capture kernel and DSP performance counters
>>    misc: fastrpc: Add support to save and restore interrupted
>>    misc: fastrpc: Add support to allocate shared context bank
>>    misc: fastrpc: Add early wakeup support for fastRPC driver
>>    misc: fastrpc: Add polling mode support for fastRPC driver
>>    misc: fastrpc: Add DSP PD notification support
>>    misc: fastrpc: Add support for users to clean up DSP user PD
>>    misc: fastrpc: Add wakelock management support
>>    misc: fastrpc: Add DSP signal support
>>    misc: fastrpc: Restrict untrusted apk to spawn privileged PD
>>    misc: fastrpc: Add system unsigned PD support
>>
>>   drivers/misc/fastrpc.c      | 1949 +++++++++++++++++++++++++++++++----
>>   include/uapi/misc/fastrpc.h |  112 ++
>>   2 files changed, 1844 insertions(+), 217 deletions(-)
>>
>

\
 
 \ /
  Last update: 2024-05-27 14:51    [W:0.429 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site