[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1524795811-21399-1-git-send-email-sdias@codeaurora.org>
Date: Thu, 26 Apr 2018 19:23:27 -0700
From: Sujeev Dias <sdias@...eaurora.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arnd Bergmann <arnd@...db.de>
Cc: Sujeev Dias <sdias@...eaurora.org>, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, Tony Truong <truong@...eaurora.org>
Subject: MHI initial design review
Hi Greg Kroah-Hartman\All
This is the initial submit of Modem Host Interface (MHI) stack for upstream
consideration. MHI is a communication protocol to communicate with external
Qualcomm modems and Wi-Fi chipsets over high speed peripheral buses. Even
though MHI doesn’t dictate underlying physical layer, protocol and mhi stack
is structured for PCIe based devices.
For additional details related to MHI interface please see Documentation/mhi.txt.
MHI stack partitioned into three main components:
1. Core layer handles all MHI protocol specific actions such as firmware download,
and data transfer
/drivers/bus/mhi/core/*
2. Control layer bus master, manages power transitions of external modem.
/drivers/bus/mhi/controllers/*
3. Device drivers MHI channels (physical transport channels) exposed as mhi devices
for clients to send and receive data.
/drivers/bus/mhi/device/*
There are three ways which clients can interface with MHI framework to send and receive
data from external modem.
1. Register directly with mhi core layer as a mhi device driver
2. User space clients can interface via mhi_uci driver.
3. For net traffic, mhi_netdev can be used.
Can you please do a high-level design review of the MHI driver and let me know if I need to
make any design changes before the drivers can be considered for upstream.
Thanks
Sujeev
Powered by blists - more mailing lists