From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2993AC4743D for ; Fri, 4 Jun 2021 21:13:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0389B613AC for ; Fri, 4 Jun 2021 21:13:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229964AbhFDVPW (ORCPT ); Fri, 4 Jun 2021 17:15:22 -0400 Received: from mail-pg1-f178.google.com ([209.85.215.178]:36649 "EHLO mail-pg1-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229665AbhFDVPW (ORCPT ); Fri, 4 Jun 2021 17:15:22 -0400 Received: by mail-pg1-f178.google.com with SMTP id 27so8852573pgy.3 for ; Fri, 04 Jun 2021 14:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QvSj42IC9X/VM/7EZXZImoBUhNSJheUuiCLl0IF75NU=; b=irc52CX95MAUzx3FMzgKRXeLnDxX6Muc8b9w+xbVcfiMOf2H6X8pnfDd+DffnZ5vWE obYIvUsRO6ioqnIW9wH46dLgIi7/JwULyVlJfkrblDTozqN43O3LBQChm/wJnB6QYZbP oZZ1OV8dOq2cPon4KUlBCLvCBiBBbLKKYlZeXVk2DsLtdnSG1ib9arvcvbUjaGbxxvIh 1kVyhFMWmhMWWjT1qxryRhBH90VZKUPMwHe8yF3GSow1U7fc2Q/vZZCJBQp9PcllbYy6 Is9on6kheUi1Wrv19nGEOLt2fbbZrKvTDQZ7fe6BfCGBO51hU2aWip+GQArOv2vWOIkL yXxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QvSj42IC9X/VM/7EZXZImoBUhNSJheUuiCLl0IF75NU=; b=D/0K50b1Qot8PxOhIadDO7ex9pgOk52lLjLTM/Qw5KsqeTUYhJ779Z2c2IPjwvDo7a EqeVnJeW3dBhTGWGDRz/JEKZbkbaFZdWsGcfLoyZoHlwVZov+DbfglSAhwV8kKS4Up8y DUw4QYRR5g17Fq0q3Wk2gtzKqflp/2NOOkdmmVCN+WEG9ghao3H4t5YwcKGuzw5EWdc4 lx96XKEObwc6EsQOus+biAAJtU6hR4xIgxewCK3vVDU/ybXw+RdJgcNLikOS9+oEa7yh hf6tluF3iCSdvlujdmVlOHYIkkV8r421cmgGitQIPlQZ5hM0uzgrKxNej/PVs/MiTCYg EF3A== X-Gm-Message-State: AOAM530jF+gLJFYpM7ymgI1hJpMLe1rcRcC+vLye6RJfgDU7iY6S2v/A 4zNBlgK6C+hBnFesmbdxN9ja5VZaXyAUN44xsoxjRA== X-Google-Smtp-Source: ABdhPJxZZNEEkPnqpVn7w/PtQ4RDsCPYfS+XUYeyuJ7k9JwElrcA87HSuGrHQ+ApctjxsIQnSSKDTyEpP+Dr4832G8s= X-Received: by 2002:a63:e309:: with SMTP id f9mr6771394pgh.443.1622841141722; Fri, 04 Jun 2021 14:12:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Loic Poulain Date: Fri, 4 Jun 2021 23:11:45 +0200 Message-ID: Subject: Re: [RFC] Integrate RPMSG/SMD into WWAN subsystem To: Stephan Gerhold Cc: Bjorn Andersson , Aleksander Morgado , Network Development , linux-remoteproc@vger.kernel.org, linux-arm-msm , "David S. Miller" , Jakub Kicinski , Ohad Ben-Cohen , Mathieu Poirier Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi Stephan, On Wed, 2 Jun 2021 at 20:20, Stephan Gerhold wrote: > > Hi Loic, Hi Bjorn, > > I've been thinking about creating some sort of "RPMSG" driver for the > new WWAN subsystem; this would be used as a QMI/AT channel to the > integrated modem on some older Qualcomm SoCs such as MSM8916 and MSM8974. > > It's easy to confuse all the different approaches that Qualcomm has to > talk to their modems, so I will first try to briefly give an overview > about those that I'm familiar with: > > --- > There is USB and MHI that are mainly used to talk to "external" modems. > > For the integrated modems in many Qualcomm SoCs there is typically > a separate control and data path. They are not really related to each > other (e.g. currently no common parent device in sysfs). > > For the data path (network interface) there is "IPA" (drivers/net/ipa) > on newer SoCs or "BAM-DMUX" on some older SoCs (e.g. MSM8916/MSM8974). > I have a driver for BAM-DMUX that I hope to finish up and submit soon. > > The connection is set up via QMI. The messages are either sent via > a shared RPMSG channel (net/qrtr sockets in Linux) or via standalone > SMD/RPMSG channels (e.g. "DATA5_CNTL" for QMI and "DATA1" for AT). > > This gives a lot of possible combinations like BAM-DMUX+RPMSG > (MSM8916, MSM8974), or IPA+QRTR (SDM845) but also other funny > combinations like IPA+RPMSG (MSM8994) or BAM-DMUX+QRTR (MSM8937). > > Simply put, supporting all these in userspace like ModemManager > is a mess (Aleksander can probably confirm). > It would be nice if this could be simplified through the WWAN subsystem. > > It's not clear to me if or how well QRTR sockets can be mapped to a char > device for the WWAN subsystem, so for now I'm trying to focus on the > standalone RPMSG approach (for MSM8916, MSM8974, ...). > --- > > Currently ModemManager uses the RPMSG channels via the rpmsg-chardev > (drivers/rpmsg/rpmsg_char.c). It wasn't my idea to use it like this, > I just took that over from someone else. Realistically speaking, the > current approach isn't too different from the UCI "backdoor interface" > approach that was rejected for MHI... > > I kind of expected that I can just trivially copy some code from > rpmsg_char.c into a WWAN driver since they both end up as a simple char > device. But it looks like the abstractions in wwan_core are kind of > getting in the way here... As far as I can tell, they don't really fit > together with the RPMSG interface. > > For example there is rpmsg_send(...) (blocking) and rpmsg_trysend(...) > (non-blocking) and even a rpmsg_poll(...) [1] but I don't see a way to > get notified when the TX queue is full or no longer full so I can call > wwan_port_txon/off(). > > Any suggestions or other thoughts? It would be indeed nice to get this in the WWAN framework. I don't know much about rpmsg but I think it is straightforward for the RX path, the ept_cb can simply forward the buffers to wwan_port_rx. For tx, simply call rpmsg_trysend() in the wwan tx callback and don't use the txon/off helpers. In short, keep it simple and check if you observe any issues. And for sure you can propose changes in the WWAN framework if you think something is missing to support your specific case. Regards, Loic