All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Tony Lindgren <tony@atomide.com>, balbi@ti.com
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, linux-omap@vger.kernel.org,
	nsekhar@ti.com, gregkh@linuxfoundation.org
Subject: Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register
Date: Thu, 20 Aug 2015 12:05:20 +0530	[thread overview]
Message-ID: <55D57528.1080207@ti.com> (raw)
In-Reply-To: <20150806084716.GB4215@atomide.com>

Hi,

On Thursday 06 August 2015 02:17 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kishon@ti.com> [150805 07:10]:
>> On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote:
>>>
>>> We don't have syscon-otghs and to me it seems we need a PHY driver
>>> as I pointed out at:
>>
>> If *syscon-otghs* is not present, then it'll fall-back to using the *ctrl-module*.
> 
> OK great.
> 
>>>
>>> https://lkml.org/lkml/2015/6/24/231
>>
>> Maybe I should have explained this in the previous thread. The *otghs* register
>> that we are trying to access here does _not_ belong to the PHY. It acts as
>> mailbox register from MUSB glue (TI integration layer) to MUSB core. That's why
>> it's programmed in the TI glue layer (omap2430.c).
>>
>> Even when we were using the older API [omap_control_usb_set_mode()], we first
>> call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c,
>> phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the
>> control module instead of PHY drivers directly calling omap_control_usb_set_mode().
> 
> Hmm looking at "Table 18-204. CONTROL_USBOTGHS_CONTROL" it seems to mention
> "transceiver" for quite a few bitfields :) Probably what that register does
> is control a PHY over ULPI.

OMAP4 uses UTMI PHY and it uses CONTROL_USBOTGHS_CONTROL too.
> 
> So from Linux kernel point of view we're best off treating it as a PHY.
> It seems it should have a minimal PHY driver similar to what we have for
> dm816x control module in drivers/phy/phy-dm816x-usb.c.

hmm.. IMHO CONTROL_USBOTGHS_CONTROL register belongs to the TI MUSB glue and
should be programmed in omap2430.c. It's better to get the opinion of Felipe
here. Felipe?
> 
> For reference, here is the register bitfields pasted from 4460 TRM:
> 
> Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972
> Physical Address 0x4A00 233C
> 
> BIT	NAME		DESCIPTION
> 8	DISCHRGVBUS	... OTG transceiver does (not) discharge VBUS ...
> 7	CHRGVBUS	... OTG transceiver does (not) charge VBUS ...
> 6	IDPULLUP	... OTG transceiver does (not) drive VBUS ...
> 4	IDDIG		... OTG transceiver does (not) apply a pullup to ID ...
> 3	SESSEND		... VBUS voltage is above/below VB_SESS_END ...	
> 2	VBUSVALID	... VBUS is above the threshold ...
> 1	BVALID		... VBUS voltage is above/below VB_SESS_VLD ...
> 0	AVALID		... BUS voltage is above/below VA_SESS_VLD ...
> 
> So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing
> drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us
> to completely get rid of the custom mailbox stuff for MUSB 2430 support?

Not in phy-omap-usb2.c. It's the UTMI PHY driver and is not used by OMAP3 based
boards (uses twl4030 ULPI PHY). CONTROL_USBOTGHS_CONTROL has to be programmed
for OMAP3 also.

Thanks
Kishon

WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Tony Lindgren <tony@atomide.com>, <balbi@ti.com>
Cc: <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-usb@vger.kernel.org>, <linux-omap@vger.kernel.org>,
	<nsekhar@ti.com>, <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register
Date: Thu, 20 Aug 2015 12:05:20 +0530	[thread overview]
Message-ID: <55D57528.1080207@ti.com> (raw)
In-Reply-To: <20150806084716.GB4215@atomide.com>

Hi,

On Thursday 06 August 2015 02:17 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kishon@ti.com> [150805 07:10]:
>> On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote:
>>>
>>> We don't have syscon-otghs and to me it seems we need a PHY driver
>>> as I pointed out at:
>>
>> If *syscon-otghs* is not present, then it'll fall-back to using the *ctrl-module*.
> 
> OK great.
> 
>>>
>>> https://lkml.org/lkml/2015/6/24/231
>>
>> Maybe I should have explained this in the previous thread. The *otghs* register
>> that we are trying to access here does _not_ belong to the PHY. It acts as
>> mailbox register from MUSB glue (TI integration layer) to MUSB core. That's why
>> it's programmed in the TI glue layer (omap2430.c).
>>
>> Even when we were using the older API [omap_control_usb_set_mode()], we first
>> call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c,
>> phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the
>> control module instead of PHY drivers directly calling omap_control_usb_set_mode().
> 
> Hmm looking at "Table 18-204. CONTROL_USBOTGHS_CONTROL" it seems to mention
> "transceiver" for quite a few bitfields :) Probably what that register does
> is control a PHY over ULPI.

OMAP4 uses UTMI PHY and it uses CONTROL_USBOTGHS_CONTROL too.
> 
> So from Linux kernel point of view we're best off treating it as a PHY.
> It seems it should have a minimal PHY driver similar to what we have for
> dm816x control module in drivers/phy/phy-dm816x-usb.c.

hmm.. IMHO CONTROL_USBOTGHS_CONTROL register belongs to the TI MUSB glue and
should be programmed in omap2430.c. It's better to get the opinion of Felipe
here. Felipe?
> 
> For reference, here is the register bitfields pasted from 4460 TRM:
> 
> Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972
> Physical Address 0x4A00 233C
> 
> BIT	NAME		DESCIPTION
> 8	DISCHRGVBUS	... OTG transceiver does (not) discharge VBUS ...
> 7	CHRGVBUS	... OTG transceiver does (not) charge VBUS ...
> 6	IDPULLUP	... OTG transceiver does (not) drive VBUS ...
> 4	IDDIG		... OTG transceiver does (not) apply a pullup to ID ...
> 3	SESSEND		... VBUS voltage is above/below VB_SESS_END ...	
> 2	VBUSVALID	... VBUS is above the threshold ...
> 1	BVALID		... VBUS voltage is above/below VB_SESS_VLD ...
> 0	AVALID		... BUS voltage is above/below VA_SESS_VLD ...
> 
> So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing
> drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us
> to completely get rid of the custom mailbox stuff for MUSB 2430 support?

Not in phy-omap-usb2.c. It's the UTMI PHY driver and is not used by OMAP3 based
boards (uses twl4030 ULPI PHY). CONTROL_USBOTGHS_CONTROL has to be programmed
for OMAP3 also.

Thanks
Kishon

  reply	other threads:[~2015-08-20  6:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-04 14:06 [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register Kishon Vijay Abraham I
2015-08-04 14:06 ` Kishon Vijay Abraham I
2015-08-04 15:58 ` Felipe Balbi
2015-08-04 15:58   ` Felipe Balbi
2015-08-05 13:50   ` Kishon Vijay Abraham I
2015-08-05 13:50     ` Kishon Vijay Abraham I
2015-08-05  8:01 ` Tony Lindgren
     [not found]   ` <20150805080113.GV16878-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2015-08-05 14:07     ` Kishon Vijay Abraham I
2015-08-05 14:07       ` Kishon Vijay Abraham I
     [not found]       ` <55C21885.6000902-l0cyMroinI0@public.gmane.org>
2015-08-06  8:47         ` Tony Lindgren
2015-08-06  8:47           ` Tony Lindgren
2015-08-20  6:35           ` Kishon Vijay Abraham I [this message]
2015-08-20  6:35             ` Kishon Vijay Abraham I
2015-08-21  7:00             ` Tony Lindgren

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=55D57528.1080207@ti.com \
    --to=kishon@ti.com \
    --cc=balbi@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --cc=tony@atomide.com \
    /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.