From: Min Guo <min.guo@mediatek.com>
To: Rob Herring <robh@kernel.org>
Cc: Bin Liu <b-liu@ti.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
"Chunfeng Yun" <chunfeng.yun@mediatek.com>,
Linux USB List <linux-usb@vger.kernel.org>,
<devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH 1/4] dt-bindings: usb: musb: Add support for MediaTek musb controller
Date: Mon, 7 Jan 2019 15:31:32 +0800 [thread overview]
Message-ID: <1546846292.4433.24.camel@mhfsdcap03> (raw)
In-Reply-To: <CAL_JsqK5x8=b6gXfBStZwHbq4zvuCuHCLAwsSqFEMJtSffC3BQ@mail.gmail.com>
On Fri, 2019-01-04 at 10:10 -0600, Rob Herring wrote:
> On Thu, Jan 3, 2019 at 9:00 PM Min Guo <min.guo@mediatek.com> wrote:
> >
> > On Thu, 2019-01-03 at 16:14 -0600, Rob Herring wrote:
> > > On Thu, Dec 27, 2018 at 03:34:23PM +0800, min.guo@mediatek.com wrote:
> > > > From: Min Guo <min.guo@mediatek.com>
> > > >
> > > > This adds support for MediaTek musb controller in
> > > > host, peripheral and otg mode
>
> [...]
>
> > > > + - interrupts : interrupt used by musb controller
> > > > + - interrupt-names : must be "mc"
> > >
> > > -names is pointless when there is only one.
> > The MUSB core driver has two interrupts, one is for MAC, another for DMA,
> > but on MTK platform, there is only a MAC interrupt, here following the binding
> > of MUSB core driver.
>
> You should probably be listing the same interrupt number twice if 2
> interrupts are combined.
If only one interrupt is regisetred in driver, dose still need list the
same interrupt number twice in dtsi?
> > > > +Optional properties:
> > > > + - extcon : external connector for VBUS and IDPIN changes detection,
> > > > + needed when supports dual-role mode.
> > >
> > > Don't use extcon for new bindings. The usb-connector binding should be
> > > used instead.
> > This is used to detect the changes of the IDPIN and VBUS, the change
> > events are provided by other drivers, such as extcon-usb-gpio.c, and
> > then switch MUSB controller to host or device mode, but the
> > usb-connector can't detect these changes.
>
> To repeat, do not use extcon binding for new bindings. It is poorly
> designed as it reflects extcon driver needs, not a description of the
> hardware. If you have ID on GPIO, then that belongs in a usb-connector
> node because that GPIO goes to the connector. For Vbus, you should
> have a vbus-supply in the connector and use a gpio-regulator if it is
> GPIO controlled.
Sorry, I didn't find a common driver describing the usb-connector. Is
there any driver that I can refer to, specially the way to switch MUSB
controller between host and device mode?
> > > > + - vbus-supply : reference to the VBUS regulator, needed when supports
> > > > + dual-role mode.
> > >
> > > The controller is powered from Vbus? Probably not. This belongs in the
> > > connector or maybe the phy (if the phy is powered from Vbus).
> > The Vbus is used to provide 5V voltage to the connected device when the
> > controller works as host mode.
>
> I know what Vbus is. Unless Vbus is providing power to the host
> controller, putting the Vbus supply in the controller node is not a
> accurate representation of the hardware.
I will put vbus-supply in usb-connector after implement it.
> Rob
WARNING: multiple messages have this Message-ID (diff)
From: Min Guo <min.guo@mediatek.com>
To: Rob Herring <robh@kernel.org>
Cc: Bin Liu <b-liu@ti.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
Chunfeng Yun <chunfeng.yun@mediatek.com>,
Linux USB List <linux-usb@vger.kernel.org>,
devicetree@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH 1/4] dt-bindings: usb: musb: Add support for MediaTek musb controller
Date: Mon, 7 Jan 2019 15:31:32 +0800 [thread overview]
Message-ID: <1546846292.4433.24.camel@mhfsdcap03> (raw)
In-Reply-To: <CAL_JsqK5x8=b6gXfBStZwHbq4zvuCuHCLAwsSqFEMJtSffC3BQ@mail.gmail.com>
On Fri, 2019-01-04 at 10:10 -0600, Rob Herring wrote:
> On Thu, Jan 3, 2019 at 9:00 PM Min Guo <min.guo@mediatek.com> wrote:
> >
> > On Thu, 2019-01-03 at 16:14 -0600, Rob Herring wrote:
> > > On Thu, Dec 27, 2018 at 03:34:23PM +0800, min.guo@mediatek.com wrote:
> > > > From: Min Guo <min.guo@mediatek.com>
> > > >
> > > > This adds support for MediaTek musb controller in
> > > > host, peripheral and otg mode
>
> [...]
>
> > > > + - interrupts : interrupt used by musb controller
> > > > + - interrupt-names : must be "mc"
> > >
> > > -names is pointless when there is only one.
> > The MUSB core driver has two interrupts, one is for MAC, another for DMA,
> > but on MTK platform, there is only a MAC interrupt, here following the binding
> > of MUSB core driver.
>
> You should probably be listing the same interrupt number twice if 2
> interrupts are combined.
If only one interrupt is regisetred in driver, dose still need list the
same interrupt number twice in dtsi?
> > > > +Optional properties:
> > > > + - extcon : external connector for VBUS and IDPIN changes detection,
> > > > + needed when supports dual-role mode.
> > >
> > > Don't use extcon for new bindings. The usb-connector binding should be
> > > used instead.
> > This is used to detect the changes of the IDPIN and VBUS, the change
> > events are provided by other drivers, such as extcon-usb-gpio.c, and
> > then switch MUSB controller to host or device mode, but the
> > usb-connector can't detect these changes.
>
> To repeat, do not use extcon binding for new bindings. It is poorly
> designed as it reflects extcon driver needs, not a description of the
> hardware. If you have ID on GPIO, then that belongs in a usb-connector
> node because that GPIO goes to the connector. For Vbus, you should
> have a vbus-supply in the connector and use a gpio-regulator if it is
> GPIO controlled.
Sorry, I didn't find a common driver describing the usb-connector. Is
there any driver that I can refer to, specially the way to switch MUSB
controller between host and device mode?
> > > > + - vbus-supply : reference to the VBUS regulator, needed when supports
> > > > + dual-role mode.
> > >
> > > The controller is powered from Vbus? Probably not. This belongs in the
> > > connector or maybe the phy (if the phy is powered from Vbus).
> > The Vbus is used to provide 5V voltage to the connected device when the
> > controller works as host mode.
>
> I know what Vbus is. Unless Vbus is providing power to the host
> controller, putting the Vbus supply in the controller node is not a
> accurate representation of the hardware.
I will put vbus-supply in usb-connector after implement it.
> Rob
WARNING: multiple messages have this Message-ID (diff)
From: min.guo@mediatek.com
To: Rob Herring <robh@kernel.org>
Cc: Bin Liu <b-liu@ti.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
Chunfeng Yun <chunfeng.yun@mediatek.com>,
Linux USB List <linux-usb@vger.kernel.org>,
devicetree@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>
Subject: [1/4] dt-bindings: usb: musb: Add support for MediaTek musb controller
Date: Mon, 7 Jan 2019 15:31:32 +0800 [thread overview]
Message-ID: <1546846292.4433.24.camel@mhfsdcap03> (raw)
On Fri, 2019-01-04 at 10:10 -0600, Rob Herring wrote:
> On Thu, Jan 3, 2019 at 9:00 PM Min Guo <min.guo@mediatek.com> wrote:
> >
> > On Thu, 2019-01-03 at 16:14 -0600, Rob Herring wrote:
> > > On Thu, Dec 27, 2018 at 03:34:23PM +0800, min.guo@mediatek.com wrote:
> > > > From: Min Guo <min.guo@mediatek.com>
> > > >
> > > > This adds support for MediaTek musb controller in
> > > > host, peripheral and otg mode
>
> [...]
>
> > > > + - interrupts : interrupt used by musb controller
> > > > + - interrupt-names : must be "mc"
> > >
> > > -names is pointless when there is only one.
> > The MUSB core driver has two interrupts, one is for MAC, another for DMA,
> > but on MTK platform, there is only a MAC interrupt, here following the binding
> > of MUSB core driver.
>
> You should probably be listing the same interrupt number twice if 2
> interrupts are combined.
If only one interrupt is regisetred in driver, dose still need list the
same interrupt number twice in dtsi?
> > > > +Optional properties:
> > > > + - extcon : external connector for VBUS and IDPIN changes detection,
> > > > + needed when supports dual-role mode.
> > >
> > > Don't use extcon for new bindings. The usb-connector binding should be
> > > used instead.
> > This is used to detect the changes of the IDPIN and VBUS, the change
> > events are provided by other drivers, such as extcon-usb-gpio.c, and
> > then switch MUSB controller to host or device mode, but the
> > usb-connector can't detect these changes.
>
> To repeat, do not use extcon binding for new bindings. It is poorly
> designed as it reflects extcon driver needs, not a description of the
> hardware. If you have ID on GPIO, then that belongs in a usb-connector
> node because that GPIO goes to the connector. For Vbus, you should
> have a vbus-supply in the connector and use a gpio-regulator if it is
> GPIO controlled.
Sorry, I didn't find a common driver describing the usb-connector. Is
there any driver that I can refer to, specially the way to switch MUSB
controller between host and device mode?
> > > > + - vbus-supply : reference to the VBUS regulator, needed when supports
> > > > + dual-role mode.
> > >
> > > The controller is powered from Vbus? Probably not. This belongs in the
> > > connector or maybe the phy (if the phy is powered from Vbus).
> > The Vbus is used to provide 5V voltage to the connected device when the
> > controller works as host mode.
>
> I know what Vbus is. Unless Vbus is providing power to the host
> controller, putting the Vbus supply in the controller node is not a
> accurate representation of the hardware.
I will put vbus-supply in usb-connector after implement it.
> Rob
WARNING: multiple messages have this Message-ID (diff)
From: Min Guo <min.guo@mediatek.com>
To: Rob Herring <robh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux USB List <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
Chunfeng Yun <chunfeng.yun@mediatek.com>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>, Bin Liu <b-liu@ti.com>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/4] dt-bindings: usb: musb: Add support for MediaTek musb controller
Date: Mon, 7 Jan 2019 15:31:32 +0800 [thread overview]
Message-ID: <1546846292.4433.24.camel@mhfsdcap03> (raw)
In-Reply-To: <CAL_JsqK5x8=b6gXfBStZwHbq4zvuCuHCLAwsSqFEMJtSffC3BQ@mail.gmail.com>
On Fri, 2019-01-04 at 10:10 -0600, Rob Herring wrote:
> On Thu, Jan 3, 2019 at 9:00 PM Min Guo <min.guo@mediatek.com> wrote:
> >
> > On Thu, 2019-01-03 at 16:14 -0600, Rob Herring wrote:
> > > On Thu, Dec 27, 2018 at 03:34:23PM +0800, min.guo@mediatek.com wrote:
> > > > From: Min Guo <min.guo@mediatek.com>
> > > >
> > > > This adds support for MediaTek musb controller in
> > > > host, peripheral and otg mode
>
> [...]
>
> > > > + - interrupts : interrupt used by musb controller
> > > > + - interrupt-names : must be "mc"
> > >
> > > -names is pointless when there is only one.
> > The MUSB core driver has two interrupts, one is for MAC, another for DMA,
> > but on MTK platform, there is only a MAC interrupt, here following the binding
> > of MUSB core driver.
>
> You should probably be listing the same interrupt number twice if 2
> interrupts are combined.
If only one interrupt is regisetred in driver, dose still need list the
same interrupt number twice in dtsi?
> > > > +Optional properties:
> > > > + - extcon : external connector for VBUS and IDPIN changes detection,
> > > > + needed when supports dual-role mode.
> > >
> > > Don't use extcon for new bindings. The usb-connector binding should be
> > > used instead.
> > This is used to detect the changes of the IDPIN and VBUS, the change
> > events are provided by other drivers, such as extcon-usb-gpio.c, and
> > then switch MUSB controller to host or device mode, but the
> > usb-connector can't detect these changes.
>
> To repeat, do not use extcon binding for new bindings. It is poorly
> designed as it reflects extcon driver needs, not a description of the
> hardware. If you have ID on GPIO, then that belongs in a usb-connector
> node because that GPIO goes to the connector. For Vbus, you should
> have a vbus-supply in the connector and use a gpio-regulator if it is
> GPIO controlled.
Sorry, I didn't find a common driver describing the usb-connector. Is
there any driver that I can refer to, specially the way to switch MUSB
controller between host and device mode?
> > > > + - vbus-supply : reference to the VBUS regulator, needed when supports
> > > > + dual-role mode.
> > >
> > > The controller is powered from Vbus? Probably not. This belongs in the
> > > connector or maybe the phy (if the phy is powered from Vbus).
> > The Vbus is used to provide 5V voltage to the connected device when the
> > controller works as host mode.
>
> I know what Vbus is. Unless Vbus is providing power to the host
> controller, putting the Vbus supply in the controller node is not a
> accurate representation of the hardware.
I will put vbus-supply in usb-connector after implement it.
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-07 7:31 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-27 7:34 [PATCH 0/4] Add MediaTek MUSB Controller Driver min.guo
2018-12-27 7:34 ` min.guo
2018-12-27 7:34 ` min.guo
2018-12-27 7:34 ` [PATCH 1/4] dt-bindings: usb: musb: Add support for MediaTek musb controller min.guo
2018-12-27 7:34 ` min.guo
2018-12-27 7:34 ` [1/4] " min.guo
2018-12-27 7:34 ` [PATCH 1/4] " min.guo
2019-01-03 22:14 ` Rob Herring
2019-01-03 22:14 ` Rob Herring
2019-01-03 22:14 ` [1/4] " Rob Herring
2019-01-04 3:00 ` [PATCH 1/4] " Min Guo
2019-01-04 3:00 ` Min Guo
2019-01-04 3:00 ` [1/4] " min.guo
2019-01-04 3:00 ` [PATCH 1/4] " Min Guo
2019-01-04 16:10 ` Rob Herring
2019-01-04 16:10 ` Rob Herring
2019-01-04 16:10 ` [1/4] " Rob Herring
2019-01-04 16:10 ` [PATCH 1/4] " Rob Herring
2019-01-07 7:31 ` Min Guo [this message]
2019-01-07 7:31 ` Min Guo
2019-01-07 7:31 ` [1/4] " min.guo
2019-01-07 7:31 ` [PATCH 1/4] " Min Guo
2019-01-08 14:05 ` Rob Herring
2019-01-07 20:40 ` Bin Liu
2019-01-07 20:40 ` Bin Liu
2019-01-07 20:40 ` [1/4] " Bin Liu
2019-01-07 20:40 ` [PATCH 1/4] " Bin Liu
2019-01-08 1:30 ` Min Guo
2019-01-08 1:30 ` Min Guo
2019-01-08 1:30 ` [1/4] " min.guo
2019-01-08 1:30 ` [PATCH 1/4] " Min Guo
2018-12-27 7:34 ` [PATCH 2/4] arm: dts: mt2701: Add usb2 device nodes min.guo
2018-12-27 7:34 ` min.guo
2018-12-27 7:34 ` [2/4] " min.guo
2018-12-27 7:34 ` [PATCH 2/4] " min.guo
2018-12-27 7:34 ` [PATCH 3/4] usb: musb: Move musbhsdma macro definition to musb_dma.h min.guo
2018-12-27 7:34 ` min.guo
2018-12-27 7:34 ` [3/4] " min.guo
2018-12-27 7:34 ` [PATCH 3/4] " min.guo
2018-12-27 7:34 ` [PATCH 4/4] usb: musb: Add support for MediaTek musb controller min.guo
2018-12-27 7:34 ` min.guo
2018-12-27 7:34 ` [4/4] " min.guo
2018-12-27 7:34 ` [PATCH 4/4] " min.guo
2019-01-08 15:44 ` Bin Liu
2019-01-08 15:44 ` Bin Liu
2019-01-08 15:44 ` [4/4] " Bin Liu
2019-01-08 15:44 ` [PATCH 4/4] " Bin Liu
2019-01-09 12:31 ` Min Guo
2019-01-09 12:31 ` Min Guo
2019-01-09 12:31 ` [4/4] " min.guo
2019-01-09 12:31 ` [PATCH 4/4] " Min Guo
2019-01-09 14:01 ` Bin Liu
2019-01-09 14:01 ` Bin Liu
2019-01-09 14:01 ` [4/4] " Bin Liu
2019-01-09 14:01 ` [PATCH 4/4] " Bin Liu
2019-01-10 7:24 ` Min Guo
2019-01-10 7:24 ` Min Guo
2019-01-10 7:24 ` [4/4] " min.guo
2019-01-10 7:24 ` [PATCH 4/4] " Min Guo
2019-01-10 14:18 ` Bin Liu
2019-01-10 14:18 ` Bin Liu
2019-01-10 14:18 ` [4/4] " Bin Liu
2019-01-10 14:18 ` [PATCH 4/4] " Bin Liu
2019-01-11 1:18 ` Min Guo
2019-01-11 1:18 ` Min Guo
2019-01-11 1:18 ` [4/4] " min.guo
2019-01-11 1:18 ` [PATCH 4/4] " Min Guo
2019-01-11 5:24 ` Min Guo
2019-01-11 5:24 ` Min Guo
2019-01-11 5:24 ` [4/4] " min.guo
2019-01-11 5:24 ` [PATCH 4/4] " Min Guo
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=1546846292.4433.24.camel@mhfsdcap03 \
--to=min.guo@mediatek.com \
--cc=b-liu@ti.com \
--cc=chunfeng.yun@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=robh@kernel.org \
--cc=stern@rowland.harvard.edu \
/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.