From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
Date: Wed, 27 Aug 2014 11:50:50 -0600 [thread overview]
Message-ID: <53FE1A7A.4010906@wwwdotorg.org> (raw)
In-Reply-To: <CAL1qeaERHeKKNpqh9qHOppgT7ymvntisdjVvZheP78U6NaPz-A@mail.gmail.com>
On 08/27/2014 11:38 AM, Andrew Bresticker wrote:
> On Mon, Aug 25, 2014 at 12:01 PM, Stephen Warren <swarren@wwwdotorg•org> wrote:
>> On 08/18/2014 11:08 AM, Andrew Bresticker wrote:
>>>
>>> The Tegra xHCI controller's firmware communicates requests to the host
>>> processor through a mailbox interface. While there is only a single
>>> communication channel, messages sent by the controller can be divided
>>> into two groups: those intended for the PHY driver and those intended
>>> for the host-controller driver. This mailbox driver exposes the two
>>> channels and routes incoming messages to the appropriate channel based
>>> on the command encoded in the message.
>>
>>
>>> diff --git a/drivers/mailbox/tegra-xusb-mailbox.c
>>> b/drivers/mailbox/tegra-xusb-mailbox.c
>>> +static struct mbox_chan *mbox_cmd_to_chan(struct tegra_xusb_mbox *mbox,
>>> u32 cmd)
>>> +{
>>> + switch (cmd) {
>>> + case MBOX_CMD_INC_FALC_CLOCK:
>>> + case MBOX_CMD_DEC_FALC_CLOCK:
>>> + case MBOX_CMD_INC_SSPI_CLOCK:
>>> + case MBOX_CMD_DEC_SSPI_CLOCK:
>>> + case MBOX_CMD_SET_BW:
>>> + return &mbox->mbox.chans[TEGRA_XUSB_MBOX_CHAN_HOST];
>>> + case MBOX_CMD_SAVE_DFE_CTLE_CTX:
>>> + case MBOX_CMD_START_HSIC_IDLE:
>>> + case MBOX_CMD_STOP_HSIC_IDLE:
>>> + return &mbox->mbox.chans[TEGRA_XUSB_MBOX_CHAN_PHY];
>>> + default:
>>> + return NULL;
>>> + }
>>> +}
>>
>>
>> This makes me think that the CHAN_HOST/CHAN_PHY values are purely a facet of
>> the Linux driver's message de-multiplexing, rather than anything to do with
>> the HW.
>
> Yup, they are...
>
>> I'm not even sure if it's appropriate for the low-level mailbox driver to
>> know about the semantics of the message, rather than simply sending them on
>> to the client driver? Perhaps when drivers register(?) for callbacks(?) for
>> messages, they should state which types of messages they want to listen to?
>
> So there's not really a way for the client driver to tell the mailbox
> driver which types of messages it wants to listen to on a particular
> channel with the mailbox framework - it simply provides a way for
> clients to bind with channels. I think there are a couple of options
> here, either: a) have a channel per message (as you mentioned in the
> previous patch), which allows the client to only register for messages
> (channels) it wants to handle, or b) extend the mailbox framework to
> allow shared channels so that both clients can receive messages on the
> single channel and handle messages appropriately. The disadvantage
> of (a) is that the commands are firmware defined and could
> theoretically change between releases of the firmware, though I'm not
> sure how common that is in practice. So that leaves (b) - Jassi, what
> do you think about having shared (non-exclusive) channels?
Another alternative might be for each client driver to hard-code a
unique dummy channel ID so that each client still gets a separate
exclusive channel, but then have the mbox driver broadcast each message
to each of those channels. I'm not sure that would be any better though;
adding (b) as an explicit option to the mbox subsystem would almost
certainly be cleaner.
>>> +static int tegra_xusb_mbox_probe(struct platform_device *pdev)
>>
>>
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>
>>> + if (!res)
>>> + return -ENODEV;
>>
>>
>> Should devm_request_mem_region() be called here to claim the region?
>
> No, the xHCI host driver also needs to map these registers, so they
> cannot be mapped exclusively here.
That's unfortunate. Having multiple drivers with overlapping register
regions is not a good idea. Can we instead have a top-level driver map
all the IO regions, then instantiate the various different
sub-components internally, and divide up the address space. Probably via
MFD or similar. That would prevent multiple drivers from touching the
same register region.
next prev parent reply other threads:[~2014-08-27 17:50 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-18 17:08 [PATCH v2 0/9] Tegra xHCI support Andrew Bresticker
2014-08-18 17:08 ` [PATCH v2 1/9] of: Add NVIDIA Tegra XUSB mailbox binding Andrew Bresticker
2014-08-25 18:48 ` Stephen Warren
2014-08-25 19:06 ` Stephen Warren
2014-08-27 16:33 ` Andrew Bresticker
2014-08-18 17:08 ` [PATCH v2 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver Andrew Bresticker
2014-08-25 19:01 ` Stephen Warren
2014-08-26 6:57 ` Thierry Reding
2014-08-26 7:43 ` Arnd Bergmann
2014-08-26 7:50 ` Thierry Reding
2014-08-26 8:09 ` Arnd Bergmann
2014-08-26 9:08 ` Thierry Reding
2014-08-26 9:54 ` Arnd Bergmann
2014-08-26 10:20 ` Thierry Reding
2014-08-26 11:35 ` Arnd Bergmann
2014-08-26 11:45 ` Thierry Reding
2014-08-26 8:54 ` David Laight
2014-08-26 10:04 ` Arnd Bergmann
2014-08-27 17:38 ` Andrew Bresticker
2014-08-27 17:50 ` Stephen Warren [this message]
2014-08-27 18:13 ` Andrew Bresticker
2014-08-27 18:19 ` Stephen Warren
2014-08-27 21:56 ` Andrew Bresticker
2014-08-27 22:30 ` Stephen Warren
2014-08-27 19:26 ` Jassi Brar
2014-08-18 17:08 ` [PATCH v2 3/9] of: Update Tegra XUSB pad controller binding for USB Andrew Bresticker
2014-08-25 19:12 ` Stephen Warren
2014-08-27 16:36 ` Andrew Bresticker
2014-08-27 16:42 ` Stephen Warren
2014-08-18 17:08 ` [PATCH v2 4/9] pinctrl: tegra-xusb: Add USB PHY support Andrew Bresticker
2014-08-25 19:22 ` Stephen Warren
2014-08-26 7:29 ` Mikko Perttunen
2014-08-27 16:44 ` Andrew Bresticker
2014-08-29 13:36 ` Linus Walleij
2014-08-18 17:08 ` [PATCH v2 5/9] of: Add NVIDIA Tegra xHCI controller binding Andrew Bresticker
2014-08-25 19:26 ` Stephen Warren
2014-08-18 17:08 ` [PATCH v2 6/9] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver Andrew Bresticker
2014-08-25 19:36 ` Stephen Warren
2014-08-30 21:15 ` Greg Kroah-Hartman
2014-08-31 19:04 ` Andrew Bresticker
2014-08-18 17:08 ` [PATCH v2 7/9] ARM: tegra: Add Tegra124 XUSB mailbox and xHCI controller Andrew Bresticker
2014-08-18 17:08 ` [PATCH v2 8/9] ARM: tegra: jetson-tk1: Add xHCI support Andrew Bresticker
2014-08-18 17:08 ` [PATCH v2 9/9] ARM: tegra: venice2: " Andrew Bresticker
2014-08-18 17:30 ` [PATCH v2 0/9] Tegra " Stephen Warren
2014-08-18 19:35 ` Andrew Bresticker
2014-08-21 13:34 ` Tomeu Vizoso
2014-08-21 17:26 ` Andrew Bresticker
2014-08-22 11:23 ` Tomeu Vizoso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53FE1A7A.4010906@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox