All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: shmobile: r8a7790: link PCI USb devices to USB PHY
Date: Fri, 11 Apr 2014 11:39:12 +0000	[thread overview]
Message-ID: <5347D460.3070803@cogentembedded.com> (raw)
In-Reply-To: <CANqRtoSub2TULO2rURiODz1VFXNUqe5gi488mkPtq_F+Oje2cQ@mail.gmail.com>

On 11.04.2014 9:48, Magnus Damm wrote:

>>>> Thanks for this patch, good to see that the relationship between the
>>>> USB Host and the PHY is described via DT.

>>>> This patch seems to cover USB0 and USB2 that both require special
>>>> control in the PHY. How about USB1? Can you explain about the reason
>>>> why you omit that?

>>>      Because the driver does nothing for USB1 anyway.

>>     Looks like I should have tested that last minute change: kernel oopses
>> due to NULL pointer dereference somewhere in phy_get() once it gets called
>> for EHCI on the channel #1. At least doesn't seem to be my mistake...

> No worries, thanks for looking into fixing that.

> Regarding the USB ports on R-Car Gen2 in general and especially USB1,
> it is my impression that even though there is no USB controller
> selection available for USB1 I still believe the UGCTL.CONNECT bit
> shall be used for power management purpose.

    I don't think so. As I said the EHCI driver happily works without touching 
this bit.

> I may of course be wrong, but since the PHY hardware is shared between
> USB0, USB1 and USB2

    I believe it's a wrong impression (which probably my and Valentine's PHY 
drivers have created). The PHY actually belongs to USBHS only; UGCTRL2 
register is some kind of ad-hockery in this PHY.

> it makes sense to have some kind of usage counter

    Generic PHY core already maintains such counters for phy_{init|exit}() and 
phy_power_{on|off}() calls.

> and manage the hardware enable bit based on registered users somehow.
> There is no need to manage this bit at this point IMO, but in the
> future we may want to add such handling to improve power management.

    I handle this bit but only for USBHS. What is actually necessary for all 
USB controllers is enabling the USBHS clocks in order for UGCTRL2 to work.

> And that can only happen if DT is used to connect all USB controllers
> with the PHY, so please make sure to describe the complete
> dependencies in DT.

    I cannnot represent USBHS in the device tree yet. I think I can represent 
xHCI there but I was told it needs the firmware in order to work -- which we 
don't have, so I'm not sure about xHCI testing.

> Thanks,

> / magnus

WBR, Sergei


WARNING: multiple messages have this Message-ID (diff)
From: sergei.shtylyov@cogentembedded.com (Sergei Shtylyov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: shmobile: r8a7790: link PCI USb devices to USB PHY
Date: Fri, 11 Apr 2014 15:39:12 +0400	[thread overview]
Message-ID: <5347D460.3070803@cogentembedded.com> (raw)
In-Reply-To: <CANqRtoSub2TULO2rURiODz1VFXNUqe5gi488mkPtq_F+Oje2cQ@mail.gmail.com>

On 11.04.2014 9:48, Magnus Damm wrote:

>>>> Thanks for this patch, good to see that the relationship between the
>>>> USB Host and the PHY is described via DT.

>>>> This patch seems to cover USB0 and USB2 that both require special
>>>> control in the PHY. How about USB1? Can you explain about the reason
>>>> why you omit that?

>>>      Because the driver does nothing for USB1 anyway.

>>     Looks like I should have tested that last minute change: kernel oopses
>> due to NULL pointer dereference somewhere in phy_get() once it gets called
>> for EHCI on the channel #1. At least doesn't seem to be my mistake...

> No worries, thanks for looking into fixing that.

> Regarding the USB ports on R-Car Gen2 in general and especially USB1,
> it is my impression that even though there is no USB controller
> selection available for USB1 I still believe the UGCTL.CONNECT bit
> shall be used for power management purpose.

    I don't think so. As I said the EHCI driver happily works without touching 
this bit.

> I may of course be wrong, but since the PHY hardware is shared between
> USB0, USB1 and USB2

    I believe it's a wrong impression (which probably my and Valentine's PHY 
drivers have created). The PHY actually belongs to USBHS only; UGCTRL2 
register is some kind of ad-hockery in this PHY.

> it makes sense to have some kind of usage counter

    Generic PHY core already maintains such counters for phy_{init|exit}() and 
phy_power_{on|off}() calls.

> and manage the hardware enable bit based on registered users somehow.
> There is no need to manage this bit at this point IMO, but in the
> future we may want to add such handling to improve power management.

    I handle this bit but only for USBHS. What is actually necessary for all 
USB controllers is enabling the USBHS clocks in order for UGCTRL2 to work.

> And that can only happen if DT is used to connect all USB controllers
> with the PHY, so please make sure to describe the complete
> dependencies in DT.

    I cannnot represent USBHS in the device tree yet. I think I can represent 
xHCI there but I was told it needs the firmware in order to work -- which we 
don't have, so I'm not sure about xHCI testing.

> Thanks,

> / magnus

WBR, Sergei

WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: "Simon Horman [Horms]" <horms@verge.net.au>,
	SH-Linux <linux-sh@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	robh+dt@kernel.org, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	ijc+devicetree@hellion.org.uk, Kumar Gala <galak@codeaurora.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: shmobile: r8a7790: link PCI USb devices to USB PHY
Date: Fri, 11 Apr 2014 15:39:12 +0400	[thread overview]
Message-ID: <5347D460.3070803@cogentembedded.com> (raw)
In-Reply-To: <CANqRtoSub2TULO2rURiODz1VFXNUqe5gi488mkPtq_F+Oje2cQ@mail.gmail.com>

On 11.04.2014 9:48, Magnus Damm wrote:

>>>> Thanks for this patch, good to see that the relationship between the
>>>> USB Host and the PHY is described via DT.

>>>> This patch seems to cover USB0 and USB2 that both require special
>>>> control in the PHY. How about USB1? Can you explain about the reason
>>>> why you omit that?

>>>      Because the driver does nothing for USB1 anyway.

>>     Looks like I should have tested that last minute change: kernel oopses
>> due to NULL pointer dereference somewhere in phy_get() once it gets called
>> for EHCI on the channel #1. At least doesn't seem to be my mistake...

> No worries, thanks for looking into fixing that.

> Regarding the USB ports on R-Car Gen2 in general and especially USB1,
> it is my impression that even though there is no USB controller
> selection available for USB1 I still believe the UGCTL.CONNECT bit
> shall be used for power management purpose.

    I don't think so. As I said the EHCI driver happily works without touching 
this bit.

> I may of course be wrong, but since the PHY hardware is shared between
> USB0, USB1 and USB2

    I believe it's a wrong impression (which probably my and Valentine's PHY 
drivers have created). The PHY actually belongs to USBHS only; UGCTRL2 
register is some kind of ad-hockery in this PHY.

> it makes sense to have some kind of usage counter

    Generic PHY core already maintains such counters for phy_{init|exit}() and 
phy_power_{on|off}() calls.

> and manage the hardware enable bit based on registered users somehow.
> There is no need to manage this bit at this point IMO, but in the
> future we may want to add such handling to improve power management.

    I handle this bit but only for USBHS. What is actually necessary for all 
USB controllers is enabling the USBHS clocks in order for UGCTRL2 to work.

> And that can only happen if DT is used to connect all USB controllers
> with the PHY, so please make sure to describe the complete
> dependencies in DT.

    I cannnot represent USBHS in the device tree yet. I think I can represent 
xHCI there but I was told it needs the firmware in order to work -- which we 
don't have, so I'm not sure about xHCI testing.

> Thanks,

> / magnus

WBR, Sergei


  reply	other threads:[~2014-04-11 11:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-09 19:18 [PATCH] ARM: shmobile: r8a7790: link PCI USb devices to USB PHY Sergei Shtylyov
2014-04-09 19:18 ` Sergei Shtylyov
2014-04-09 19:18 ` Sergei Shtylyov
2014-04-10  7:07 ` Magnus Damm
2014-04-10  7:07   ` Magnus Damm
2014-04-10  7:07   ` Magnus Damm
2014-04-10 10:38   ` Sergei Shtylyov
2014-04-10 10:38     ` Sergei Shtylyov
2014-04-10 10:38     ` Sergei Shtylyov
2014-04-10 18:46     ` Sergei Shtylyov
2014-04-10 18:46       ` Sergei Shtylyov
2014-04-10 18:46       ` Sergei Shtylyov
2014-04-11  5:48       ` Magnus Damm
2014-04-11  5:48         ` Magnus Damm
2014-04-11  5:48         ` Magnus Damm
2014-04-11 11:39         ` Sergei Shtylyov [this message]
2014-04-11 11:39           ` Sergei Shtylyov
2014-04-11 11:39           ` 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=5347D460.3070803@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.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.