Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1200508 > unrolled thread

Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register

Started byTony Lindgren <tony@atomide.com>
First post2015-08-05 10:10 +0200
Last post2015-08-06 10:50 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write  to mailbox register Tony Lindgren <tony@atomide.com> - 2015-08-05 10:10 +0200
    Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write  to mailbox register Kishon Vijay Abraham I <kishon@ti.com> - 2015-08-05 16:10 +0200
      Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write  to mailbox register Tony Lindgren <tony@atomide.com> - 2015-08-06 10:50 +0200

#1200508 — Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register

FromTony Lindgren <tony@atomide.com>
Date2015-08-05 10:10 +0200
SubjectRe: [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register
Message-ID<pU1VU-3PS-29@gated-at.bofh.it>
* Kishon Vijay Abraham I <kishon@ti.com> [150804 07:11]:
> Deprecate using phy-omap-control driver to write to the mailbox register
> and start using *syscon* framework to do the same.
..
> @@ -512,6 +558,40 @@ static const struct musb_platform_ops omap2430_ops = {
>  
>  static u64 omap2430_dmamask = DMA_BIT_MASK(32);
>  
> +static int omap2430_get_sys_ctrl(struct omap2430_glue *glue,
> +				 struct device_node *np)
> +{
> +	struct device_node *control_node;
> +	struct platform_device *control_pdev;
> +
> +	glue->syscon_otghs = syscon_regmap_lookup_by_phandle(np,
> +							     "syscon-otghs");
> +	if (IS_ERR(glue->syscon_otghs)) {
> +		dev_dbg(glue->dev, "can't get syscon, using control device\n");
> +		glue->syscon_otghs = NULL;
> +
> +		control_node = of_parse_phandle(np, "ctrl-module", 0);
> +		if (control_node) {
> +			control_pdev = of_find_device_by_node(control_node);
> +			if (!control_pdev) {
> +				dev_err(glue->dev,
> +					"Failed to get control device\n");
> +				return -EINVAL;
> +			}
> +			glue->control_otghs = &control_pdev->dev;
> +		}
> +	} else {
> +		if (of_property_read_u32_index(np, "syscon-otghs", 1,
> +					       &glue->otghs_reg)) {
> +			dev_err(glue->dev,
> +				"couldn't get otghs reg. offset\n");
> +			return -EINVAL;
> +		}
> +	}
> +
> +	return 0;
> +}

We don't have syscon-otghs and to me it seems we need a PHY driver
as I pointed out at:

https://lkml.org/lkml/2015/6/24/231

So let's sort that issue first. It also seems this just completely
breaks the MUSB support?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1200812

FromKishon Vijay Abraham I <kishon@ti.com>
Date2015-08-05 16:10 +0200
Message-ID<pU7yh-3zf-15@gated-at.bofh.it>
In reply to#1200508
Hi Tony,

On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kishon@ti.com> [150804 07:11]:
>> Deprecate using phy-omap-control driver to write to the mailbox register
>> and start using *syscon* framework to do the same.
> ..
>> @@ -512,6 +558,40 @@ static const struct musb_platform_ops omap2430_ops = {
>>  
>>  static u64 omap2430_dmamask = DMA_BIT_MASK(32);
>>  
>> +static int omap2430_get_sys_ctrl(struct omap2430_glue *glue,
>> +				 struct device_node *np)
>> +{
>> +	struct device_node *control_node;
>> +	struct platform_device *control_pdev;
>> +
>> +	glue->syscon_otghs = syscon_regmap_lookup_by_phandle(np,
>> +							     "syscon-otghs");
>> +	if (IS_ERR(glue->syscon_otghs)) {
>> +		dev_dbg(glue->dev, "can't get syscon, using control device\n");
>> +		glue->syscon_otghs = NULL;
>> +
>> +		control_node = of_parse_phandle(np, "ctrl-module", 0);
>> +		if (control_node) {
>> +			control_pdev = of_find_device_by_node(control_node);
>> +			if (!control_pdev) {
>> +				dev_err(glue->dev,
>> +					"Failed to get control device\n");
>> +				return -EINVAL;
>> +			}
>> +			glue->control_otghs = &control_pdev->dev;
>> +		}
>> +	} else {
>> +		if (of_property_read_u32_index(np, "syscon-otghs", 1,
>> +					       &glue->otghs_reg)) {
>> +			dev_err(glue->dev,
>> +				"couldn't get otghs reg. offset\n");
>> +			return -EINVAL;
>> +		}
>> +	}
>> +
>> +	return 0;
>> +}
> 
> 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*.
> 
> 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().
> 
> So let's sort that issue first. It also seems this just completely
> breaks the MUSB support?

Why do you think so? If *syscon-otghs* is not present in dt, then it'll
fall-back to using the *ctrl-module* and everything should work seamlessly.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1201581

FromTony Lindgren <tony@atomide.com>
Date2015-08-06 10:50 +0200
Message-ID<pUp2a-3HO-19@gated-at.bofh.it>
In reply to#1200812
* 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.

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.

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?

> > So let's sort that issue first. It also seems this just completely
> > breaks the MUSB support?
> 
> Why do you think so? If *syscon-otghs* is not present in dt, then it'll
> fall-back to using the *ctrl-module* and everything should work seamlessly.

OK that's good to hear. IMO drivers/phy/phy-omap4.c or similar should
manage the syscon-otghs syscon register, not MUSB driver.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web