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]
Message-ID: <CAFCwf10PL+kO5YcaBTmA1N34tSF18NJ0GLJoJ0L2VG5GuV-6XQ@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ