[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Marek Vasut]

On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh wrote:
> Hi Marex,
> 
> Following u-boot patch is pending for your review for some time. Please let
> me know if you have any concerns. fsl/usb: Add USB XHCI support:
> http://patchwork.ozlabs.org/patch/373593/

I missed the patch completely, sorry. Next time, please keep me on CC when 
submitting the patches, that helps a lot.

As for the board_usb_init, you can drop the inline and the __board_usb_init()
and do:

__weak int board_usb_init(int index, enum usb_init_type init)
{
	return 0;
}

The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut down
the controller, which I don't see happening. Why?

Thanks!

Best regards,
Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Ramneek Mehresh]

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Thursday, December 18, 2014 4:46 PM
> To: u-boot
> Cc: Mehresh Ramneek-B31383
> Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> 
> On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh wrote:
> > Hi Marex,
> >
> > Following u-boot patch is pending for your review for some time.
> > Please let me know if you have any concerns. fsl/usb: Add USB XHCI
> support:
> > http://patchwork.ozlabs.org/patch/373593/
> 
> I missed the patch completely, sorry. Next time, please keep me on CC when
> submitting the patches, that helps a lot.
> 
> As for the board_usb_init, you can drop the inline and the
> __board_usb_init() and do:
> 
> __weak int board_usb_init(int index, enum usb_init_type init) {
> 	return 0;
> }
> 
Will do

> The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut down
> the controller, which I don't see happening. Why?
> 
I could not locate any such requirement in IP documentation. Have contacted local
IP/PHY team for the same. Waiting for response from them
- Ramneek
> Thanks!
> 
> Best regards,
> Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Marek Vasut]

On Monday, January 12, 2015 at 06:26:24 AM, Ramneek Mehresh wrote:
> > -----Original Message-----
> > From: Marek Vasut [mailto:marex at denx.de]
> > Sent: Thursday, December 18, 2014 4:46 PM
> > To: u-boot
> > Cc: Mehresh Ramneek-B31383
> > Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> > 
> > On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh wrote:
> > > Hi Marex,
> > > 
> > > Following u-boot patch is pending for your review for some time.
> > > Please let me know if you have any concerns. fsl/usb: Add USB XHCI
> > 
> > support:
> > > http://patchwork.ozlabs.org/patch/373593/
> > 
> > I missed the patch completely, sorry. Next time, please keep me on CC
> > when submitting the patches, that helps a lot.
> > 
> > As for the board_usb_init, you can drop the inline and the
> > __board_usb_init() and do:
> > 
> > __weak int board_usb_init(int index, enum usb_init_type init) {
> > 
> > 	return 0;
> > 
> > }
> 
> Will do
> 
> > The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut
> > down the controller, which I don't see happening. Why?
> 
> I could not locate any such requirement in IP documentation. Have contacted
> local IP/PHY team for the same. Waiting for response from them

This is needed, so you don't start Linux with a running USB controller.

Thanks!

Best regards,
Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Ramneek Mehresh]

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Monday, January 12, 2015 8:00 PM
> To: Mehresh Ramneek-B31383
> Cc: u-boot
> Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> 
> On Monday, January 12, 2015 at 06:26:24 AM, Ramneek Mehresh wrote:
> > > -----Original Message-----
> > > From: Marek Vasut [mailto:marex at denx.de]
> > > Sent: Thursday, December 18, 2014 4:46 PM
> > > To: u-boot
> > > Cc: Mehresh Ramneek-B31383
> > > Subject: Re: Regarding patch:
> > > http://patchwork.ozlabs.org/patch/373593/
> > >
> > > On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh
> wrote:
> > > > Hi Marex,
> > > >
> > > > Following u-boot patch is pending for your review for some time.
> > > > Please let me know if you have any concerns. fsl/usb: Add USB XHCI
> > >
> > > support:
> > > > http://patchwork.ozlabs.org/patch/373593/
> > >
> > > I missed the patch completely, sorry. Next time, please keep me on
> > > CC when submitting the patches, that helps a lot.
> > >
> > > As for the board_usb_init, you can drop the inline and the
> > > __board_usb_init() and do:
> > >
> > > __weak int board_usb_init(int index, enum usb_init_type init) {
> > >
> > > 	return 0;
> > >
> > > }
> >
> > Will do
> >
> > > The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must
> > > shut down the controller, which I don't see happening. Why?
> >
> > I could not locate any such requirement in IP documentation. Have
> > contacted local IP/PHY team for the same. Waiting for response from
> > them
> 
> This is needed, so you don't start Linux with a running USB controller.
> 
xhci controller is already stopped in usb_stop->usb_lowlevel_stop->xhci_reset(). 
I could see CMD_RUN bit getting reset in this function before the controller is reset.
So, from your previously stated requirement, controller is halted when Linux is started.

Other people are shutting down PHY as part of xhci_core_exit(), not the controller!!
We would not like to re-start and re-configure PHY inside Linux, and take phy initialization
inside bootloader. I got word from hw team that they do not support phy
shutting down from sw. hence, we do not have any sequence for current socs to
shut down phy from sw. if required, I'll put forward a request to provide
this control in future socs.
 
> Thanks!
> 
> Best regards,
> Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Marek Vasut]

On Monday, April 06, 2015 at 10:58:30 AM, Ramneek Mehresh wrote:

[...]

> > > > The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must
> > > > shut down the controller, which I don't see happening. Why?
> > > 
> > > I could not locate any such requirement in IP documentation. Have
> > > contacted local IP/PHY team for the same. Waiting for response from
> > > them
> > 
> > This is needed, so you don't start Linux with a running USB controller.
> 
> xhci controller is already stopped in
> usb_stop->usb_lowlevel_stop->xhci_reset(). I could see CMD_RUN bit getting
> reset in this function before the controller is reset. So, from your
> previously stated requirement, controller is halted when Linux is started.
> 
> Other people are shutting down PHY as part of xhci_core_exit(), not the
> controller!! We would not like to re-start and re-configure PHY inside
> Linux, and take phy initialization inside bootloader. I got word from hw
> team that they do not support phy shutting down from sw. hence, we do not
> have any sequence for current socs to shut down phy from sw. if required,
> I'll put forward a request to provide this control in future socs.

Hi,

Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6,
the bug is that you cannot reset the PCIe and PCIe PHY from software, which 
means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. 
Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in 
Linux even if PCIe is not used in U-Boot at all.

Is this the same type of hardware screwup where the design team didn't think 
reset was necessary?

Best regards,
Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Ramneek Mehresh]

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Monday, April 06, 2015 8:42 PM
> To: Mehresh Ramneek-B31383
> Cc: u-boot; sr at denx.de
> Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> 
> On Monday, April 06, 2015 at 10:58:30 AM, Ramneek Mehresh wrote:
> 
> [...]
> 
> > > > > The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci)
> > > > > must shut down the controller, which I don't see happening. Why?
> > > >
> > > > I could not locate any such requirement in IP documentation. Have
> > > > contacted local IP/PHY team for the same. Waiting for response
> > > > from them
> > >
> > > This is needed, so you don't start Linux with a running USB controller.
> >
> > xhci controller is already stopped in
> > usb_stop->usb_lowlevel_stop->xhci_reset(). I could see CMD_RUN bit
> > getting reset in this function before the controller is reset. So,
> > from your previously stated requirement, controller is halted when Linux is
> started.
> >
> > Other people are shutting down PHY as part of xhci_core_exit(), not
> > the controller!! We would not like to re-start and re-configure PHY
> > inside Linux, and take phy initialization inside bootloader. I got
> > word from hw team that they do not support phy shutting down from sw.
> > hence, we do not have any sequence for current socs to shut down phy
> > from sw. if required, I'll put forward a request to provide this control in
> future socs.
> 
> Hi,
> 
> Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6,
> the bug is that you cannot reset the PCIe and PCIe PHY from software, which
> means that if you start PCIe in U-Boot, you cannot reliably use it in Linux.
> Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in
> Linux even if PCIe is not used in U-Boot at all.
> 
> Is this the same type of hardware screwup where the design team didn't
> think reset was necessary?
> 
I have raised request for this feature in up-coming socs, and they have agreed to
provide phy shut-down in future revs. However, this support is not available in current
revs for which the code is sent. What do you suggest we should do for current socs?

> Best regards,
> Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Marek Vasut]

On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:

[...]

> > Hi,
> > 
> > Is this similar hardware bug to the one which MX6 PCIe is suffering ? On
> > MX6, the bug is that you cannot reset the PCIe and PCIe PHY from
> > software, which means that if you start PCIe in U-Boot, you cannot
> > reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you
> > cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot
> > at all.
> > 
> > Is this the same type of hardware screwup where the design team didn't
> > think reset was necessary?
> 
> I have raised request for this feature in up-coming socs, and they have
> agreed to provide phy shut-down in future revs. However, this support is
> not available in current revs for which the code is sent. What do you
> suggest we should do for current socs?

Hi,

I don't know, but doesn't leaving the USB running cause trouble to Linux?
I think you should at least document the reasoning why the USB stop is not
implemented for this broken hardware.

Best regards,
Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Ramneek Mehresh]

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Tuesday, April 07, 2015 7:22 PM
> To: Mehresh Ramneek-B31383
> Cc: u-boot; sr at denx.de
> Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> 
> On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> 
> [...]
> 
> > > Hi,
> > >
> > > Is this similar hardware bug to the one which MX6 PCIe is suffering
> > > ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY
> > > from software, which means that if you start PCIe in U-Boot, you
> > > cannot reliably use it in Linux. Furthermore, if you reset the MX6
> > > via WDT, you cannot start PCIe reliably in Linux even if PCIe is not
> > > used in U-Boot at all.
> > >
> > > Is this the same type of hardware screwup where the design team
> > > didn't think reset was necessary?
> >
> > I have raised request for this feature in up-coming socs, and they
> > have agreed to provide phy shut-down in future revs. However, this
> > support is not available in current revs for which the code is sent.
> > What do you suggest we should do for current socs?
> 
> Hi,
> 
> I don't know, but doesn't leaving the USB running cause trouble to Linux?
> I think you should at least document the reasoning why the USB stop is not
> implemented for this broken hardware.
> 
Hi Marek, it's not USB controller stop, it's Phy stop which is not supported.
Controller stopping is supported. 

> Best regards,
> Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Marek Vasut]

On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > -----Original Message-----
> > From: Marek Vasut [mailto:marex at denx.de]
> > Sent: Tuesday, April 07, 2015 7:22 PM
> > To: Mehresh Ramneek-B31383
> > Cc: u-boot; sr at denx.de
> > Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> > 
> > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> > 
> > [...]
> > 
> > > > Hi,
> > > > 
> > > > Is this similar hardware bug to the one which MX6 PCIe is suffering
> > > > ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY
> > > > from software, which means that if you start PCIe in U-Boot, you
> > > > cannot reliably use it in Linux. Furthermore, if you reset the MX6
> > > > via WDT, you cannot start PCIe reliably in Linux even if PCIe is not
> > > > used in U-Boot at all.
> > > > 
> > > > Is this the same type of hardware screwup where the design team
> > > > didn't think reset was necessary?
> > > 
> > > I have raised request for this feature in up-coming socs, and they
> > > have agreed to provide phy shut-down in future revs. However, this
> > > support is not available in current revs for which the code is sent.
> > > What do you suggest we should do for current socs?
> > 
> > Hi,
> > 
> > I don't know, but doesn't leaving the USB running cause trouble to Linux?
> > I think you should at least document the reasoning why the USB stop is
> > not implemented for this broken hardware.
> 
> Hi Marek, it's not USB controller stop, it's Phy stop which is not
> supported. Controller stopping is supported.

OK, does it pose a problem for Linux ? If not, then please just document
it and let's stick with what there now.

Best regards,
Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Ramneek Mehresh]

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Tuesday, April 07, 2015 7:44 PM
> To: Mehresh Ramneek-B31383
> Cc: u-boot; sr at denx.de
> Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> 
> On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > > -----Original Message-----
> > > From: Marek Vasut [mailto:marex at denx.de]
> > > Sent: Tuesday, April 07, 2015 7:22 PM
> > > To: Mehresh Ramneek-B31383
> > > Cc: u-boot; sr at denx.de
> > > Subject: Re: Regarding patch:
> > > http://patchwork.ozlabs.org/patch/373593/
> > >
> > > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> > >
> > > [...]
> > >
> > > > > Hi,
> > > > >
> > > > > Is this similar hardware bug to the one which MX6 PCIe is
> > > > > suffering ? On MX6, the bug is that you cannot reset the PCIe
> > > > > and PCIe PHY from software, which means that if you start PCIe
> > > > > in U-Boot, you cannot reliably use it in Linux. Furthermore, if
> > > > > you reset the MX6 via WDT, you cannot start PCIe reliably in
> > > > > Linux even if PCIe is not used in U-Boot at all.
> > > > >
> > > > > Is this the same type of hardware screwup where the design team
> > > > > didn't think reset was necessary?
> > > >
> > > > I have raised request for this feature in up-coming socs, and they
> > > > have agreed to provide phy shut-down in future revs. However, this
> > > > support is not available in current revs for which the code is sent.
> > > > What do you suggest we should do for current socs?
> > >
> > > Hi,
> > >
> > > I don't know, but doesn't leaving the USB running cause trouble to Linux?
> > > I think you should at least document the reasoning why the USB stop
> > > is not implemented for this broken hardware.
> >
> > Hi Marek, it's not USB controller stop, it's Phy stop which is not
> > supported. Controller stopping is supported.
> 
> OK, does it pose a problem for Linux ? If not, then please just document it
> and let's stick with what there now.
> 
No, it won't create issue in Linux because Linux usb driver resets the controller
(which in turn resets the phy). Please suggest what's the best place to document this.
Shall I document this inside some u-boot doc file?

> Best regards,
> Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Marek Vasut]

On Tuesday, April 07, 2015 at 04:42:36 PM, Ramneek Mehresh wrote:
> > -----Original Message-----
> > From: Marek Vasut [mailto:marex at denx.de]
> > Sent: Tuesday, April 07, 2015 7:44 PM
> > To: Mehresh Ramneek-B31383
> > Cc: u-boot; sr at denx.de
> > Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> > 
> > On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > > > -----Original Message-----
> > > > From: Marek Vasut [mailto:marex at denx.de]
> > > > Sent: Tuesday, April 07, 2015 7:22 PM
> > > > To: Mehresh Ramneek-B31383
> > > > Cc: u-boot; sr at denx.de
> > > > Subject: Re: Regarding patch:
> > > > http://patchwork.ozlabs.org/patch/373593/
> > > > 
> > > > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > Is this similar hardware bug to the one which MX6 PCIe is
> > > > > > suffering ? On MX6, the bug is that you cannot reset the PCIe
> > > > > > and PCIe PHY from software, which means that if you start PCIe
> > > > > > in U-Boot, you cannot reliably use it in Linux. Furthermore, if
> > > > > > you reset the MX6 via WDT, you cannot start PCIe reliably in
> > > > > > Linux even if PCIe is not used in U-Boot at all.
> > > > > > 
> > > > > > Is this the same type of hardware screwup where the design team
> > > > > > didn't think reset was necessary?
> > > > > 
> > > > > I have raised request for this feature in up-coming socs, and they
> > > > > have agreed to provide phy shut-down in future revs. However, this
> > > > > support is not available in current revs for which the code is
> > > > > sent. What do you suggest we should do for current socs?
> > > > 
> > > > Hi,
> > > > 
> > > > I don't know, but doesn't leaving the USB running cause trouble to
> > > > Linux? I think you should at least document the reasoning why the
> > > > USB stop is not implemented for this broken hardware.
> > > 
> > > Hi Marek, it's not USB controller stop, it's Phy stop which is not
> > > supported. Controller stopping is supported.
> > 
> > OK, does it pose a problem for Linux ? If not, then please just document
> > it and let's stick with what there now.
> 
> No, it won't create issue in Linux because Linux usb driver resets the
> controller (which in turn resets the phy). Please suggest what's the best
> place to document this. Shall I document this inside some u-boot doc file?

A comment in the driver source would be fine.

Best regards,
Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Ramneek Mehresh]

> -----Original Message-----
> From: Mehresh Ramneek-B31383
> Sent: Tuesday, April 07, 2015 8:12 PM
> To: 'Marek Vasut'
> Cc: u-boot; sr at denx.de
> Subject: RE: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> 
> 
> 
> > -----Original Message-----
> > From: Marek Vasut [mailto:marex at denx.de]
> > Sent: Tuesday, April 07, 2015 7:44 PM
> > To: Mehresh Ramneek-B31383
> > Cc: u-boot; sr at denx.de
> > Subject: Re: Regarding patch:
> > http://patchwork.ozlabs.org/patch/373593/
> >
> > On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > > > -----Original Message-----
> > > > From: Marek Vasut [mailto:marex at denx.de]
> > > > Sent: Tuesday, April 07, 2015 7:22 PM
> > > > To: Mehresh Ramneek-B31383
> > > > Cc: u-boot; sr at denx.de
> > > > Subject: Re: Regarding patch:
> > > > http://patchwork.ozlabs.org/patch/373593/
> > > >
> > > > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> > > >
> > > > [...]
> > > >
> > > > > > Hi,
> > > > > >
> > > > > > Is this similar hardware bug to the one which MX6 PCIe is
> > > > > > suffering ? On MX6, the bug is that you cannot reset the PCIe
> > > > > > and PCIe PHY from software, which means that if you start PCIe
> > > > > > in U-Boot, you cannot reliably use it in Linux. Furthermore,
> > > > > > if you reset the MX6 via WDT, you cannot start PCIe reliably
> > > > > > in Linux even if PCIe is not used in U-Boot at all.
> > > > > >
> > > > > > Is this the same type of hardware screwup where the design
> > > > > > team didn't think reset was necessary?
> > > > >
> > > > > I have raised request for this feature in up-coming socs, and
> > > > > they have agreed to provide phy shut-down in future revs.
> > > > > However, this support is not available in current revs for which the
> code is sent.
> > > > > What do you suggest we should do for current socs?
> > > >
> > > > Hi,
> > > >
> > > > I don't know, but doesn't leaving the USB running cause trouble to
> Linux?
> > > > I think you should at least document the reasoning why the USB
> > > > stop is not implemented for this broken hardware.
> > >
> > > Hi Marek, it's not USB controller stop, it's Phy stop which is not
> > > supported. Controller stopping is supported.
> >
> > OK, does it pose a problem for Linux ? If not, then please just
> > document it and let's stick with what there now.
> >
> No, it won't create issue in Linux because Linux usb driver resets the
> controller (which in turn resets the phy). Please suggest what's the best
> place to document this.
> Shall I document this inside some u-boot doc file?
> 
I can document this inside xhci_stop() part of fsl driver. In addition,
this will also be documented in FSL USB driver documentation.
Please tell if this is ok.

> > Best regards,
> > Marek Vasut

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Marek Vasut]

On Tuesday, April 07, 2015 at 04:52:09 PM, Ramneek Mehresh wrote:
> > -----Original Message-----
> > From: Mehresh Ramneek-B31383
> > Sent: Tuesday, April 07, 2015 8:12 PM
> > To: 'Marek Vasut'
> > Cc: u-boot; sr at denx.de
> > Subject: RE: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> > 
> > > -----Original Message-----
> > > From: Marek Vasut [mailto:marex at denx.de]
> > > Sent: Tuesday, April 07, 2015 7:44 PM
> > > To: Mehresh Ramneek-B31383
> > > Cc: u-boot; sr at denx.de
> > > Subject: Re: Regarding patch:
> > > http://patchwork.ozlabs.org/patch/373593/
> > > 
> > > On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > > > > -----Original Message-----
> > > > > From: Marek Vasut [mailto:marex at denx.de]
> > > > > Sent: Tuesday, April 07, 2015 7:22 PM
> > > > > To: Mehresh Ramneek-B31383
> > > > > Cc: u-boot; sr at denx.de
> > > > > Subject: Re: Regarding patch:
> > > > > http://patchwork.ozlabs.org/patch/373593/
> > > > > 
> > > > > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Is this similar hardware bug to the one which MX6 PCIe is
> > > > > > > suffering ? On MX6, the bug is that you cannot reset the PCIe
> > > > > > > and PCIe PHY from software, which means that if you start PCIe
> > > > > > > in U-Boot, you cannot reliably use it in Linux. Furthermore,
> > > > > > > if you reset the MX6 via WDT, you cannot start PCIe reliably
> > > > > > > in Linux even if PCIe is not used in U-Boot at all.
> > > > > > > 
> > > > > > > Is this the same type of hardware screwup where the design
> > > > > > > team didn't think reset was necessary?
> > > > > > 
> > > > > > I have raised request for this feature in up-coming socs, and
> > > > > > they have agreed to provide phy shut-down in future revs.
> > > > > > However, this support is not available in current revs for which
> > > > > > the
> > 
> > code is sent.
> > 
> > > > > > What do you suggest we should do for current socs?
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I don't know, but doesn't leaving the USB running cause trouble to
> > 
> > Linux?
> > 
> > > > > I think you should at least document the reasoning why the USB
> > > > > stop is not implemented for this broken hardware.
> > > > 
> > > > Hi Marek, it's not USB controller stop, it's Phy stop which is not
> > > > supported. Controller stopping is supported.
> > > 
> > > OK, does it pose a problem for Linux ? If not, then please just
> > > document it and let's stick with what there now.
> > 
> > No, it won't create issue in Linux because Linux usb driver resets the
> > controller (which in turn resets the phy). Please suggest what's the best
> > place to document this.
> > Shall I document this inside some u-boot doc file?
> 
> I can document this inside xhci_stop() part of fsl driver. In addition,
> this will also be documented in FSL USB driver documentation.
> Please tell if this is ok.

Yes, thanks!

[U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/

[Paul Kocialkowski]

Hi, 

Le jeudi 18 d?cembre 2014 ? 12:16 +0100, Marek Vasut a ?crit :
> On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh wrote:
> > Hi Marex,
> > 
> > Following u-boot patch is pending for your review for some time. Please let
> > me know if you have any concerns. fsl/usb: Add USB XHCI support:
> > http://patchwork.ozlabs.org/patch/373593/
> 
> I missed the patch completely, sorry. Next time, please keep me on CC when 
> submitting the patches, that helps a lot.
> 
> As for the board_usb_init, you can drop the inline and the __board_usb_init()
> and do:
> 
> __weak int board_usb_init(int index, enum usb_init_type init)
> {
> 	return 0;
> }
> 
> The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut down
> the controller, which I don't see happening. Why?

By the way, this is already defined in common/usb.c, so it's probably
not worth duplicating it. On the other hand, it means that *HCI support
would be broken (it applies to all other drivers usb board_usb_init)
when not using CMD_USB, which I'm not sure is a good thing.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150407/8568f5ea/attachment.sig>