[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <518D52CA.7000100@wwwdotorg.org>
Date: Fri, 10 May 2013 14:04:26 -0600
From: Stephen Warren <swarren@...dotorg.org>
To: Venu Byravarasu <vbyravarasu@...dia.com>
CC: gregkh@...uxfoundation.org, balbi@...com,
stern@...land.harvard.edu, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v3 10/10] Usb: Move PORTSC access to PHY
On 05/10/2013 07:54 AM, Venu Byravarasu wrote:
> Changes with this patch:
> 1. As PHY is being registered as separate platform driver & EHCI Tegra
> is no more calling PHY open, moved tegra_ehci_set_pts & tegra_ehci_set_phcd
> functions to PHY driver,
>
> 2. Removed unused defines for multiple USB port base addresses
This patch (mostly?) is a revert of bbdabdb "usb: add APIs to access
host registers from Tegra PHY". I don't think we want to revert this[1].
Instead, once patch 9/10 in this series is applied, the Tegra EHCI
module should no longer directly reference any symbols in the Tegra USB
PHY module. This is because the functions exposed by the Tegra PHY
module are now accessed using the new standard PHY APIs, rather than
directly by symbol name.
Assuming that's true, it is then permissible for the Tegra PHY module to
once again directly reference symbols exported by the Tegra EHCI module.
So, instead of moving the functions from the EHCI code to the PHY code,
keep them in the EHCI code, and call them from the PHY code, but call
them by function name instead of by function pointer. That way, there's
no need to pass the function pointers during initialization.
You will have to roll that change into patch 9/10 to make git bisect work.
[1] The background is that NVIDIA HW has added some non-standard
register bits to the PORTSC register, related to PHY control. The PHY
driver needs to control those bits, but they're in the EHCI register
space. Since the non-standard bits are controlled by read-modify-write,
the EHCI driver should implement the register accesses, so the it can
implement locking against its own read-modify-write of that register if
required.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists