From: david@lechnology.com (David Lechner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources
Date: Tue, 15 Mar 2016 23:57:43 -0500 [thread overview]
Message-ID: <56E8E7C7.70901@lechnology.com> (raw)
In-Reply-To: <56E8D720.7000508@lechnology.com>
On 03/15/2016 10:46 PM, David Lechner wrote:
> On 03/15/2016 05:45 PM, Sergei Shtylyov wrote:
>>
>> No, this register is shared b/w MUSB and OHCI. The proper thing to
>> do is to write the PHY driver and let it control this shared register.
>>
>
> OK. I've started working on this. I am looking at using struct usb_phy,
> however, enum usb_phy_type only has USB_PHY_TYPE_UNDEFINED,
> USB_PHY_TYPE_USB2, and USB_PHY_TYPE_USB3. Would it be acceptable to use
> USB_PHY_TYPE_UNDEFINED for the ohci since it is USB 1.1? Or perhaps I
> should use the more generic struct phy for that one?
>
Also, I am not finding any existing data structure to pass the musb
set_mode function to the phy in either usb_phy or usb_otg. Setting the
mode (host/peripheral/otg) is done in the same PHY register, so it seems
like it should be implemented in the new phy driver as well.
I guess I could use a generic phy instead and use phy_set_drvdata() to
share data between the phy driver and the musb driver. Does this sound
like a reasonable thing to do?
WARNING: multiple messages have this Message-ID (diff)
From: David Lechner <david@lechnology.com>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
Sekhar Nori <nsekhar@ti.com>, Kevin Hilman <khilman@kernel.org>,
Alan Stern <stern@rowland.harvard.edu>, Bin Liu <b-liu@ti.com>,
Petr Kulhavy <petr@barix.com>
Cc: Russell King <linux@arm.linux.org.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Felipe Balbi <balbi@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources
Date: Tue, 15 Mar 2016 23:57:43 -0500 [thread overview]
Message-ID: <56E8E7C7.70901@lechnology.com> (raw)
In-Reply-To: <56E8D720.7000508@lechnology.com>
On 03/15/2016 10:46 PM, David Lechner wrote:
> On 03/15/2016 05:45 PM, Sergei Shtylyov wrote:
>>
>> No, this register is shared b/w MUSB and OHCI. The proper thing to
>> do is to write the PHY driver and let it control this shared register.
>>
>
> OK. I've started working on this. I am looking at using struct usb_phy,
> however, enum usb_phy_type only has USB_PHY_TYPE_UNDEFINED,
> USB_PHY_TYPE_USB2, and USB_PHY_TYPE_USB3. Would it be acceptable to use
> USB_PHY_TYPE_UNDEFINED for the ohci since it is USB 1.1? Or perhaps I
> should use the more generic struct phy for that one?
>
Also, I am not finding any existing data structure to pass the musb
set_mode function to the phy in either usb_phy or usb_otg. Setting the
mode (host/peripheral/otg) is done in the same PHY register, so it seems
like it should be implemented in the new phy driver as well.
I guess I could use a generic phy instead and use phy_set_drvdata() to
share data between the phy driver and the musb driver. Does this sound
like a reasonable thing to do?
next prev parent reply other threads:[~2016-03-16 4:57 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 22:37 [PATCH 1/5] ARM: davinci: defined missing CFGCHIP2_REFFREQ_* macros for MUSB PHY David Lechner
2016-03-15 22:37 ` David Lechner
2016-03-15 22:37 ` [PATCH 2/5] ARM: davinci: da8xx: add usb phy clocks David Lechner
2016-03-15 22:37 ` David Lechner
2016-03-16 12:27 ` Sergei Shtylyov
2016-03-16 12:27 ` Sergei Shtylyov
2016-03-16 17:58 ` David Lechner
2016-03-16 17:58 ` David Lechner
2016-03-16 18:04 ` Sergei Shtylyov
2016-03-16 18:04 ` Sergei Shtylyov
2016-03-16 18:21 ` David Lechner
2016-03-16 18:21 ` David Lechner
2016-03-15 22:37 ` [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources David Lechner
2016-03-15 22:37 ` David Lechner
2016-03-15 22:45 ` Sergei Shtylyov
2016-03-15 22:45 ` Sergei Shtylyov
2016-03-16 3:46 ` David Lechner
2016-03-16 3:46 ` David Lechner
2016-03-16 4:57 ` David Lechner [this message]
2016-03-16 4:57 ` David Lechner
2016-03-16 17:38 ` Sergei Shtylyov
2016-03-16 17:38 ` Sergei Shtylyov
2016-03-16 18:14 ` David Lechner
2016-03-16 18:14 ` David Lechner
2016-03-16 18:22 ` Sergei Shtylyov
2016-03-16 18:22 ` Sergei Shtylyov
2016-03-16 18:27 ` Sergei Shtylyov
2016-03-16 18:27 ` Sergei Shtylyov
2016-03-16 18:27 ` David Lechner
2016-03-16 18:27 ` David Lechner
2016-03-16 11:34 ` Sergei Shtylyov
2016-03-16 11:34 ` Sergei Shtylyov
2016-03-15 22:37 ` [PATCH 4/5] usb: ohci-da8xx: Remove clock code that references mach David Lechner
2016-03-15 22:37 ` David Lechner
2016-03-16 14:50 ` Alan Stern
2016-03-16 18:00 ` David Lechner
2016-03-16 18:00 ` David Lechner
2016-03-15 22:37 ` [PATCH 5/5] usb: musb-da8xx: remove board-specific clock handling David Lechner
2016-03-15 22:37 ` David Lechner
2016-03-16 11:57 ` Sergei Shtylyov
2016-03-16 11:57 ` Sergei Shtylyov
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=56E8E7C7.70901@lechnology.com \
--to=david@lechnology.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.