linux-kernel - Re: FYI: misc: visconti: Toshiba Visconti DSP accelerator driver sample

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 8 Aug 2022 23:27:34 +0300
From:   Oded Gabbay <oded.gabbay@...il.com>
To:     Yuji Ishikawa <yuji2.ishikawa@...hiba.co.jp>
Cc:     Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "list@....net:IOMMU DRIVERS <iommu@...ts.linux-foundation.org>, Joerg
        Roedel <joro@...tes.org>," <linux-arm-kernel@...ts.infradead.org>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Maling list - DRI developers 
        <dri-devel@...ts.freedesktop.org>,
        "moderated list:DMA BUFFER SHARING FRAMEWORK" 
        <linaro-mm-sig@...ts.linaro.org>
Subject: Re: FYI: misc: visconti: Toshiba Visconti DSP accelerator driver sample

On Fri, Aug 5, 2022 at 1:41 PM Yuji Ishikawa
<yuji2.ishikawa@...hiba.co.jp> wrote:
>
> Hello Odded
>
> This is a sample (wip) driver for a DSP found on Toshiba Visconti SoC.
> The DSP typically accepts some images, apply an algorithm on them and yields resulting one.
> Therefore (image-in, image-out), they say this driver should be classified to media driver category.
> However, it can handle various data format (wider than v4l2 officially supports)
> if userland provide firmware (=algorithm) for its own.
>
> Yes, this rough implementation is the first step only our staff could go.
> I'm not for sure whether we could carry out experiments earlier if we chose to use existing frameworks,
> instead of writing our own routine for handling DMA-BUFs and interrupts.
> I hope this post will help your case-study.
>
> Regards
>         Yuji Ishikawa
>
Thanks Yuji.

I've gone over the IOCTLs and they seem fairly straightforward. I
think that we will be able to accommodate at least part of them in the
common code of an accel subsystem.
Oded