Re: [U-Boot] [PATCH 3/3] imx: mx6sllevk: add usb support

2016-12-22 Thread Marek Vasut
On 12/22/2016 09:38 AM, Peng Fan wrote:
> 
> 
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Thursday, December 22, 2016 3:12 PM
>> To: Peng Fan ; sba...@denx.de
>> Cc: u-boot@lists.denx.de; van.free...@gmail.com
>> Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support
>>
>> On 12/22/2016 07:38 AM, Peng Fan wrote:
>>>
>>>
 -Original Message-
 From: Marek Vasut [mailto:ma...@denx.de]
 Sent: Thursday, December 22, 2016 2:12 PM
 To: Peng Fan ; sba...@denx.de
 Cc: u-boot@lists.denx.de; van.free...@gmail.com
 Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support

 On 12/22/2016 07:03 AM, Peng Fan wrote:
>
> Hi Marek,
>
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Thursday, December 22, 2016 12:40 PM
>> To: Peng Fan ; sba...@denx.de
>> Cc: u-boot@lists.denx.de; van.free...@gmail.com
>> Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support
>>
>> On 12/22/2016 02:13 AM, Peng Fan wrote:
>>>
>>>
 -Original Message-
 From: Marek Vasut [mailto:ma...@denx.de]
 Sent: Wednesday, December 21, 2016 10:10 PM
 To: Peng Fan ; sba...@denx.de
 Cc: u-boot@lists.denx.de; van.free...@gmail.com
 Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support

 On 12/21/2016 09:14 AM, Peng Fan wrote:
> Add usb support for mx6sllevk board.
>
> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> ---
>>> [..]
>>>
> +
> +#define USB_OTHERREGS_OFFSET   0x800
> +#define UCTRL_PWR_POL  (1 << 9)
> +
> +int board_ehci_hcd_init(int port) {
> + u32 *usbnc_usb_ctrl;
> +
> + if (port > 1)
> + return -EINVAL;
> +
> + usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR +
 USB_OTHERREGS_OFFSET
 +
> +  port * 4);
> +
> + /* Set Power polarity */
> + setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL);
> + return 0;
> +}

 Is this function similar to what usb_oc_config() does ?
>>>
>>> No, this bit is not for overcurrent. According to RM, this is OTG
>>> Power Polarity This bit should be set according to power switch's
>>> enable
>> polarity.
>>> 1 Power switch has an active-high enable input
>>> 0 Power switch has an active-low enable input
>>>
>>> This is board specific.
>>
>> Great, except it should also be part of the driver , the same way
>> as polarity is configured, yes ?
>
> I just found that there is code for mx7,
> http://lists.denx.de/pipermail/u-boot/2016-July/260321.html
>
> Then do you agree I add such piece code in usb_power_config for mx6?
> "
> #ifdef CONFIG_MXC_USB_OTG_HACTIVE
> setbits_le32(ctrl, UCTRL_PWR_POL); #else
> clrbits_le32(ctrl, UCTRL_PWR_POL); #endif "

 Didn't you add DT support in a patch sent like ... yesterday ? :)
 Just use DT property instead of ifdef.
>>>
>>> There is no property for otg power polatiry in upstream Linux. I would
>>> not like to introduce one in U-Boot. We can drop the ifdef when there is an
>> property in upstream. What do you think?
>>
>> So uh, how can the USB work in mainline Linux on that board ?
> 
> Confirmed with IC, if using gpio to control vbus power, no need to configure 
> this bit.
> Since in dts, we are using gpio regulator to control vbus, this piece code in 
> patch 3/3
> can be discarded. I'll drop it in V2.

Hum, OK. Let's revisit this when we need this then ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] imx: mx6sllevk: add usb support

2016-12-22 Thread Marek Vasut
On 12/22/2016 09:55 AM, Peng Fan wrote:
> 
> 
>>> +#define USB_OTHERREGS_OFFSET   0x800
>>> +#define UCTRL_PWR_POL  (1 << 9)
>>> +
>>> +int board_ehci_hcd_init(int port) {
>>> +   u32 *usbnc_usb_ctrl;
>>> +
>>> +   if (port > 1)
>>> +   return -EINVAL;
>>> +
>>> +   usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR +
>> USB_OTHERREGS_OFFSET
>> +
>>> +port * 4);
>>> +
>>> +   /* Set Power polarity */
>>> +   setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL);
>>> +   return 0;
>>> +}
>>
>> Is this function similar to what usb_oc_config() does ?
>
> No, this bit is not for overcurrent. According to RM, this is
> OTG Power Polarity This bit should be set according to power
> switch's enable
 polarity.
> 1 Power switch has an active-high enable input
> 0 Power switch has an active-low enable input
>
> This is board specific.

 Great, except it should also be part of the driver , the same way
 as polarity is configured, yes ?
>>>
>>> I just found that there is code for mx7,
>>> http://lists.denx.de/pipermail/u-boot/2016-July/260321.html
>>>
>>> Then do you agree I add such piece code in usb_power_config for mx6?
>>> "
>>> #ifdef CONFIG_MXC_USB_OTG_HACTIVE
>>> setbits_le32(ctrl, UCTRL_PWR_POL); #else
>>> clrbits_le32(ctrl, UCTRL_PWR_POL); #endif "
>>
>> Didn't you add DT support in a patch sent like ... yesterday ? :)
>> Just use DT property instead of ifdef.
>
> There is no property for otg power polatiry in upstream Linux. I
> would not like to introduce one in U-Boot. We can drop the ifdef
> when there is an
 property in upstream. What do you think?

 So uh, how can the USB work in mainline Linux on that board ?
>>>
>>> Confirmed with IC, if using gpio to control vbus power, no need to configure
>> this bit.
>>> Since in dts, we are using gpio regulator to control vbus, this piece
>>> code in patch 3/3 can be discarded. I'll drop it in V2.
>>
>> Hum, OK. Let's revisit this when we need this then ?
> 
> Take i.MX6SLL as an example,
> The pin key_col4 can be configured with the two functions.
> [1] MX6_PAD_KEY_COL4__USB_OTG1_PWR 
> [2] MX6_PAD_KEY_COL4__GPIO4_IO00
> 
> In fsl i.mx uboot code, the common way is to use [1] and configure the 
> polarity to enable the vbus power.
> But in kernel, it is configured as [2] and use gpio regulator to enable the 
> vbus power.
> 
> This is board specific. There is no upstream property for this bit. When 
> there is an upstream property for this,
> We could add it in probe function for those that use [1] in dts pinmux.
> 
> Now I am using the same dts from kernel which this pinmux configured as [2], 
> so this piece code is not needed for now.

Well, can you submit a proposal with the new prop for devicetree@ ?
It can then be improved in linux too ...

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 2/3] usb: ehci-mx6: handle vbus-supply

2016-12-22 Thread Marek Vasut
On 12/22/2016 10:06 AM, Peng Fan wrote:
> Drop board_ehci_power when dm usb used and switch to use
> regulator api to handle vbus.
> 
> Signed-off-by: Peng Fan 
> Cc: Marek Vasut 
> Cc: Simon Glass 
> Cc: Stefano Babic 

Acked-by: Marek Vasut 

I'd like a R-B from Simon on this one.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 1/3] usb: ehci-mx6: implement ofdata_to_platdata

2016-12-22 Thread Marek Vasut
On 12/22/2016 10:06 AM, Peng Fan wrote:
> Implement ofdata_to_platdata to set the type to host or device.
>  - Check "dr-mode" property.
>  - If there is no "dr-mode", check phy_ctrl for i.MX6
>and phy_status for i.MX7
> 
> Signed-off-by: Peng Fan 
> Cc: Marek Vasut 
> Cc: Simon Glass 
> Cc: Stefano Babic 
> ---
> 
> V2:
>   Add a ehci_usb_phy_mode function to check phy mode when dr-mode is otg,
>   or no mode property provided.
> 
>  drivers/usb/host/ehci-mx6.c | 75 
> +
>  1 file changed, 75 insertions(+)
> 
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 48889c1..18b7fc3 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -15,10 +15,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "ehci.h"
>  
> +DECLARE_GLOBAL_DATA_PTR;
> +
>  #define USB_OTGREGS_OFFSET   0x000
>  #define USB_H1REGS_OFFSET0x200
>  #define USB_H2REGS_OFFSET0x400
> @@ -48,6 +51,7 @@
>  #define ANADIG_USB2_PLL_480_CTRL_EN_USB_CLKS 0x0040
>  
>  #define USBNC_OFFSET 0x200
> +#define USBNC_PHY_STATUS_OFFSET  0x23C
>  #define USBNC_PHYSTATUS_ID_DIG   (1 << 4) /* otg_id status */
>  #define USBNC_PHYCFG2_ACAENB (1 << 4) /* otg_id detection enable */
>  #define UCTRL_PWR_POL(1 << 9) /* OTG Polarity of Power Pin */
> @@ -417,6 +421,76 @@ static const struct ehci_ops mx6_ehci_ops = {
>   .init_after_reset = mx6_init_after_reset
>  };
>  
> +static int ehci_usb_phy_mode(struct udevice *dev)
> +{
> + struct usb_platdata *plat = dev_get_platdata(dev);
> + void *__iomem addr = (void *__iomem)dev_get_addr(dev);
> + void *__iomem phy_ctrl, *__iomem phy_status;
> + const void *blob = gd->fdt_blob;
> + int offset = dev->of_offset, phy_off;
> + u32 val;
> +
> + /*
> +  * About fsl,usbphy, Refer to
> +  * Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt.
> +  */
> + if (is_mx6()) {
> + phy_off = fdtdec_lookup_phandle(blob,
> + offset,
> + "fsl,usbphy");

This could be on a single line IMO.

> + if (phy_off < 0)
> + return -EINVAL;
> +
> + addr = (void __iomem *)fdtdec_get_addr(blob, phy_off,
> +"reg");

Same here, shouldn't be over 80.

Otherwise:
Acked-by: Marek Vasut 

> + if ((fdt_addr_t)addr == FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> + phy_ctrl = (void __iomem *)(addr + USBPHY_CTRL);
> + val = readl(phy_ctrl);
> +
> + if (val & USBPHY_CTRL_OTG_ID)
> + plat->init_type = USB_INIT_DEVICE;
> + else
> + plat->init_type = USB_INIT_HOST;
> + } else if (is_mx7()) {
> + phy_status = (void __iomem *)(addr +
> +   USBNC_PHY_STATUS_OFFSET);
> + val = readl(phy_status);
> +
> + if (val & USBNC_PHYSTATUS_ID_DIG)
> + plat->init_type = USB_INIT_DEVICE;
> + else
> + plat->init_type = USB_INIT_HOST;
> + } else {
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int ehci_usb_ofdata_to_platdata(struct udevice *dev)
> +{
> + struct usb_platdata *plat = dev_get_platdata(dev);
> + const char *mode;
> +
> + mode = fdt_getprop(gd->fdt_blob, dev->of_offset, "dr_mode", NULL);
> + if (mode) {
> + if (strcmp(mode, "peripheral") == 0)
> + plat->init_type = USB_INIT_DEVICE;
> + else if (strcmp(mode, "host") == 0)
> + plat->init_type = USB_INIT_HOST;
> + else if (strcmp(mode, "otg") == 0)
> + return ehci_usb_phy_mode(dev);
> + else
> + return -EINVAL;
> +
> + return 0;
> + }
> +
> + return ehci_usb_phy_mode(dev);
> +}
> +
>  static int ehci_usb_probe(struct udevice *dev)
>  {
>   struct usb_platdata *plat = dev_get_platdata(dev);
> @@ -460,6 +534,7 @@ U_BOOT_DRIVER(usb_mx6) = {
>   .name   = "ehci_mx6",
>   .id = UCLASS_USB,
>   .of_match = mx6_usb_ids,
> + .ofdata_to_platdata = ehci_usb_ofdata_to_platdata,
>   .probe  = ehci_usb_probe,
>   .remove = ehci_deregister,
>   .ops= &ehci_usb_ops,
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/3] dm: goni: support the DM PMIC

2016-12-22 Thread Minkyu Kang
2016년 12월 22일 (목) 07:03, Jaehoon Chung 님이 작성:

> Hi,
>
>
>
> On 12/21/2016 11:54 PM, Minkyu Kang wrote:
>
> > Hi,
>
> >
>
> > On 15 December 2016 at 18:21, Jaehoon Chung 
> wrote:
>
> >
>
> >> This patchest is for supporting pmic driver-model on Goni board.
>
> >> (Goni board is S5PC110.)
>
> >>
>
> >> For using that, add the new file as max8998.c for only driver-model.
>
> >> pmic_max8998.c is remained for legacy.
>
> >> In future, it might be removed. Instead, max8998 should be used.
>
> >>
>
> >> *dm tree
>
> >>  serial  [ + ]|-- serial@e2900800
>
> >>  i2c [   ]`-- i2c-pmic
>
> >>  pmic[   ]`-- pmic@66
>
> >>
>
> >> *dm uclass
>
> >> uclass 20: i2c
>
> >> - * i2c-pmic @ 47f6c6d0, seq 3, (req 3)
>
> >>
>
> >> uclass 22: i2c_generic
>
> >> uclass 42: pmic
>
> >> - * pmic@66 @ 47f6c748, seq 0, (req -1)
>
> >>
>
> >> * After using pmic command.
>
> >> Goni # pmic list
>
> >> | Name| Parent name | Parent uclass
> @
>
> >> seq
>
> >> | pmic@66 | i2c-pmic| i2c @ 3
>
> >>
>
> >> Node, it needs to implement the regulator driver for using regulator
>
> >> framework.
>
> >>
>
> >> Jaehoon Chung (3):
>
> >>   power: pmic: add the max8998 controller for DM
>
> >>   arm: dts: s5pc1xx-goni: add the pmic node for using DM
>
> >>   configs: enable the DM_PMIC and DM_I2C_GPIO for max8998 pmic
>
> >>
>
> >>  arch/arm/dts/s5pc1xx-goni.dts | 165 ++
>
> >> 
>
> >>  configs/s5p_goni_defconfig|   3 +
>
> >>  drivers/power/pmic/Kconfig|   7 ++
>
> >>  drivers/power/pmic/Makefile   |   1 +
>
> >>  drivers/power/pmic/max8998.c  |  61 
>
> >>  5 files changed, 237 insertions(+)
>
> >>  create mode 100644 drivers/power/pmic/max8998.c
>
> >>
>
> >> --
>
> >> 2.10.2
>
> >>
>
> >> ___
>
> >> U-Boot mailing list
>
> >> U-Boot@lists.denx.de
>
> >> http://lists.denx.de/mailman/listinfo/u-boot
>
> >>
>
> >
>
> >
>
> > This patchset seems to ready to submit.
>
> > Who will pick this up? power? DM? or samsang?
>
>
>
> Delegated to you (Minkyu), Could you apply on u-boot-samsung?
>
> There is no Power maintainer, now.
>
> I sent the patch for updating Power maintainer, but i didn't reply
> anything.
>
>
>
> Best Regards,
>
> Jaehoon Chung
>
>
>
> >
>
> >
>
> > Thanks,
>
> >


> applied to u-boot-samsung


> Thanks

Minkyu Kang.
>
>
>
> --
Thanks. Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 3/3] imx: mx6sllevk: add usb support

2016-12-22 Thread Peng Fan
Add usb support for mx6sllevk board.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
---

V2:
 Drop the polarity setting and CONFIG_USB_MAX_CONTROLLER_COUNT

 configs/mx6sllevk_defconfig| 5 +
 configs/mx6sllevk_plugin_defconfig | 5 +
 include/configs/mx6sllevk.h| 8 
 3 files changed, 18 insertions(+)

diff --git a/configs/mx6sllevk_defconfig b/configs/mx6sllevk_defconfig
index 8ae049e..267cdc6 100644
--- a/configs/mx6sllevk_defconfig
+++ b/configs/mx6sllevk_defconfig
@@ -10,6 +10,7 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
@@ -34,3 +35,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_STORAGE=y
diff --git a/configs/mx6sllevk_plugin_defconfig 
b/configs/mx6sllevk_plugin_defconfig
index e6be979..63d5bbc 100644
--- a/configs/mx6sllevk_plugin_defconfig
+++ b/configs/mx6sllevk_plugin_defconfig
@@ -11,6 +11,7 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
@@ -35,3 +36,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_STORAGE=y
diff --git a/include/configs/mx6sllevk.h b/include/configs/mx6sllevk.h
index b9f25cf..be4d147 100644
--- a/include/configs/mx6sllevk.h
+++ b/include/configs/mx6sllevk.h
@@ -149,4 +149,12 @@
 
 #define CONFIG_IOMUX_LPSR
 
+/* USB Configs */
+#ifdef CONFIG_CMD_USB
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+#define CONFIG_USB_ETHER_RTL8152
+#define CONFIG_MXC_USB_PORTSC  (PORT_PTS_UTMI | PORT_PTS_PTW)
+#endif
+
 #endif /* __CONFIG_H */
-- 
2.6.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] imx: mx6sllevk: add usb support

2016-12-22 Thread Peng Fan


> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Thursday, December 22, 2016 3:12 PM
> To: Peng Fan ; sba...@denx.de
> Cc: u-boot@lists.denx.de; van.free...@gmail.com
> Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support
> 
> On 12/22/2016 07:38 AM, Peng Fan wrote:
> >
> >
> >> -Original Message-
> >> From: Marek Vasut [mailto:ma...@denx.de]
> >> Sent: Thursday, December 22, 2016 2:12 PM
> >> To: Peng Fan ; sba...@denx.de
> >> Cc: u-boot@lists.denx.de; van.free...@gmail.com
> >> Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support
> >>
> >> On 12/22/2016 07:03 AM, Peng Fan wrote:
> >>>
> >>> Hi Marek,
> >>>
>  -Original Message-
>  From: Marek Vasut [mailto:ma...@denx.de]
>  Sent: Thursday, December 22, 2016 12:40 PM
>  To: Peng Fan ; sba...@denx.de
>  Cc: u-boot@lists.denx.de; van.free...@gmail.com
>  Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support
> 
>  On 12/22/2016 02:13 AM, Peng Fan wrote:
> >
> >
> >> -Original Message-
> >> From: Marek Vasut [mailto:ma...@denx.de]
> >> Sent: Wednesday, December 21, 2016 10:10 PM
> >> To: Peng Fan ; sba...@denx.de
> >> Cc: u-boot@lists.denx.de; van.free...@gmail.com
> >> Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support
> >>
> >> On 12/21/2016 09:14 AM, Peng Fan wrote:
> >>> Add usb support for mx6sllevk board.
> >>>
> >>> Signed-off-by: Peng Fan 
> >>> Cc: Stefano Babic 
> >>> ---
> > [..]
> >
> >>> +
> >>> +#define USB_OTHERREGS_OFFSET   0x800
> >>> +#define UCTRL_PWR_POL  (1 << 9)
> >>> +
> >>> +int board_ehci_hcd_init(int port) {
> >>> + u32 *usbnc_usb_ctrl;
> >>> +
> >>> + if (port > 1)
> >>> + return -EINVAL;
> >>> +
> >>> + usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR +
> >> USB_OTHERREGS_OFFSET
> >> +
> >>> +  port * 4);
> >>> +
> >>> + /* Set Power polarity */
> >>> + setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL);
> >>> + return 0;
> >>> +}
> >>
> >> Is this function similar to what usb_oc_config() does ?
> >
> > No, this bit is not for overcurrent. According to RM, this is OTG
> > Power Polarity This bit should be set according to power switch's
> > enable
>  polarity.
> > 1 Power switch has an active-high enable input
> > 0 Power switch has an active-low enable input
> >
> > This is board specific.
> 
>  Great, except it should also be part of the driver , the same way
>  as polarity is configured, yes ?
> >>>
> >>> I just found that there is code for mx7,
> >>> http://lists.denx.de/pipermail/u-boot/2016-July/260321.html
> >>>
> >>> Then do you agree I add such piece code in usb_power_config for mx6?
> >>> "
> >>> #ifdef CONFIG_MXC_USB_OTG_HACTIVE
> >>> setbits_le32(ctrl, UCTRL_PWR_POL); #else
> >>> clrbits_le32(ctrl, UCTRL_PWR_POL); #endif "
> >>
> >> Didn't you add DT support in a patch sent like ... yesterday ? :)
> >> Just use DT property instead of ifdef.
> >
> > There is no property for otg power polatiry in upstream Linux. I would
> > not like to introduce one in U-Boot. We can drop the ifdef when there is an
> property in upstream. What do you think?
> 
> So uh, how can the USB work in mainline Linux on that board ?

Confirmed with IC, if using gpio to control vbus power, no need to configure 
this bit.
Since in dts, we are using gpio regulator to control vbus, this piece code in 
patch 3/3
can be discarded. I'll drop it in V2.

Thanks,
Peng.

> 
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID

2016-12-22 Thread Chen-Yu Tsai
On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede  wrote:
> Hi,
>
>
> On 19-12-16 17:06, Icenowy Zheng wrote:
>>
>>
>>
>> 19.12.2016, 23:30, "Hans de Goede" :
>>>
>>> Hi,
>>>
>>> On 19-12-16 16:22, Icenowy Zheng wrote:

  Hi everyone,

  Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
  controller of H3 (incl. H2+).

  See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

  Two read method of the H3 eFUSE is used in the BSP: by register
 accessing, or
  directly access 0x01c14200.

  From http://linux-sunxi.org/SID_Register_Guide we can see a difference
 between
  the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2
 (in
  legacy kernel).

  According to the source of H2+ BSP[1], H2+ and H3 can be differed by
 the last
  byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is
 H3,
  0x58 is H3D (currently not known SoC) )

  However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3,
 start
  with 0x02004620, which do not match this rule.

  The readout by devmem2 is satisfying this rule: their first word is
  0x02c00081, matches H3.

  Then I found the SID-reading code from BSP U-Boot[2], which is based on
  register operations. With this kind of code (I wrote one prototype in
  userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e"
 on
  my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel
 sid)
  And, after accessing to the SID by registers, the value of *0x01c14200
 become
  also "02c00081".

  With direct access to 0x01c14200 after boot with mainline kernel, I got
 also
  "02004620".

  Then I altered the program to do the register operations with
 sunxi-fel, the
  result is also "02c00081", and changed `sunxi-fel sid` result to
 "02c00081".

  Summary:

  +---++
  | Read situation | The first word |
  +---++
  | Direct read by sunxi-fel | 02004620 |
  | Direct read in mainline /dev/mem | 02004620 |
  | Direct read in legacy /dev/mem | 02c00081 |
  | Register access in FEL | 02c00081 |
  | Register access in mainline | 02c00081 |
  | Direct read after register access in FEL | 02c00081 |
  | Direct read after register access in mainline | 02c00081 |
  +---++

  According to some facts:
  - The register based access to SID is weird: it needs ~5 register
operations per word of SID.
  - Reading via register access will change the value when reading by
 accessing
0x01c14200.
  - In the u-boot code[2] there's some functions which read out the SID
 by
registers and then abandoned the value.
  - This mismatch do not exist on A64.

  I think that: Allwinner designed a "cache" to the SID to make the
 simplify the
  code to read it, and it automatically loaded the cache when booting;
 however,
  when doing first cache on H3, some byte shifts occured, and the value
 become
  wrong. A manual read on H3 can make the cache right again. This is a
 silicon
  bug, and fixed in A64.

  This raises a problem: currently many systems has used the misread SID
 value to
  generated lots of MAC addresses, and workaround this SID bug will
 change them.

  However, if this bug is not workarounded, the sun8i-ths driver won't
 work well
  (as some calibartion value lies in eFUSE). I think some early user of
 this
  driver has already experienced bad readout value.
  (The calibration value differs on my opi1 and KotCzarny's opipc)

  And many wrong SID values have been generated by `sunxi-fel sid`.
 (Although I
  think sunxi-fel must have the workaround)

  Note: in this email, "SID" and "eFUSE" both indicate the controller on
 H3/A64
  at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

  Furthermore, A83T may also have this problem, testers are welcome!

  [1]
 http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
  [2]
 http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c

  Experiments:
  - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
A SID readout shell script via FEL with register access.
  - https://31.135.195.151:20281/d/efuse/
A SID readout program via /dev/mem with register access by KotCzarny.
(with statically compiled binary)
>>>
>>>
>>> Good detective work!
>>>
>>> I believe this would best be fixed by making u-boot use th

Re: [U-Boot] [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID

2016-12-22 Thread Hans de Goede

Hi,

On 22-12-16 11:31, Chen-Yu Tsai wrote:

On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede  wrote:

Hi,


On 19-12-16 17:06, Icenowy Zheng wrote:




19.12.2016, 23:30, "Hans de Goede" :


Hi,

On 19-12-16 16:22, Icenowy Zheng wrote:


 Hi everyone,

 Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
 controller of H3 (incl. H2+).

 See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

 Two read method of the H3 eFUSE is used in the BSP: by register
accessing, or
 directly access 0x01c14200.

 From http://linux-sunxi.org/SID_Register_Guide we can see a difference
between
 the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2
(in
 legacy kernel).

 According to the source of H2+ BSP[1], H2+ and H3 can be differed by
the last
 byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is
H3,
 0x58 is H3D (currently not known SoC) )

 However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3,
start
 with 0x02004620, which do not match this rule.

 The readout by devmem2 is satisfying this rule: their first word is
 0x02c00081, matches H3.

 Then I found the SID-reading code from BSP U-Boot[2], which is based on
 register operations. With this kind of code (I wrote one prototype in
 userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e"
on
 my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel
sid)
 And, after accessing to the SID by registers, the value of *0x01c14200
become
 also "02c00081".

 With direct access to 0x01c14200 after boot with mainline kernel, I got
also
 "02004620".

 Then I altered the program to do the register operations with
sunxi-fel, the
 result is also "02c00081", and changed `sunxi-fel sid` result to
"02c00081".

 Summary:

 +---++
 | Read situation | The first word |
 +---++
 | Direct read by sunxi-fel | 02004620 |
 | Direct read in mainline /dev/mem | 02004620 |
 | Direct read in legacy /dev/mem | 02c00081 |
 | Register access in FEL | 02c00081 |
 | Register access in mainline | 02c00081 |
 | Direct read after register access in FEL | 02c00081 |
 | Direct read after register access in mainline | 02c00081 |
 +---++

 According to some facts:
 - The register based access to SID is weird: it needs ~5 register
   operations per word of SID.
 - Reading via register access will change the value when reading by
accessing
   0x01c14200.
 - In the u-boot code[2] there's some functions which read out the SID
by
   registers and then abandoned the value.
 - This mismatch do not exist on A64.

 I think that: Allwinner designed a "cache" to the SID to make the
simplify the
 code to read it, and it automatically loaded the cache when booting;
however,
 when doing first cache on H3, some byte shifts occured, and the value
become
 wrong. A manual read on H3 can make the cache right again. This is a
silicon
 bug, and fixed in A64.

 This raises a problem: currently many systems has used the misread SID
value to
 generated lots of MAC addresses, and workaround this SID bug will
change them.

 However, if this bug is not workarounded, the sun8i-ths driver won't
work well
 (as some calibartion value lies in eFUSE). I think some early user of
this
 driver has already experienced bad readout value.
 (The calibration value differs on my opi1 and KotCzarny's opipc)

 And many wrong SID values have been generated by `sunxi-fel sid`.
(Although I
 think sunxi-fel must have the workaround)

 Note: in this email, "SID" and "eFUSE" both indicate the controller on
H3/A64
 at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

 Furthermore, A83T may also have this problem, testers are welcome!

 [1]
http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
 [2]
http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c

 Experiments:
 - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
   A SID readout shell script via FEL with register access.
 - https://31.135.195.151:20281/d/efuse/
   A SID readout program via /dev/mem with register access by KotCzarny.
   (with statically compiled binary)



Good detective work!

I believe this would best be fixed by making u-boot use the register
access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.



Yes.

However, what I considered is that fixing this bug will change H3 devices'
MAC addresses, as they are derived from SID.



I know, but I think we will just need to accept this onetime change
of the fixed MAC addresses to fix this bug. I don't think this is
a big problem since the driver for the H3 ethernet has not been
merged into the mainline kernel yet.


Do we still need to do the CRC32 across the SID values to generate
the MAC addresses?

[U-Boot] [PATCH V2 1/3] usb: ehci-mx6: implement ofdata_to_platdata

2016-12-22 Thread Peng Fan
Implement ofdata_to_platdata to set the type to host or device.
 - Check "dr-mode" property.
 - If there is no "dr-mode", check phy_ctrl for i.MX6
   and phy_status for i.MX7

Signed-off-by: Peng Fan 
Cc: Marek Vasut 
Cc: Simon Glass 
Cc: Stefano Babic 
---

V2:
  Add a ehci_usb_phy_mode function to check phy mode when dr-mode is otg,
  or no mode property provided.

 drivers/usb/host/ehci-mx6.c | 75 +
 1 file changed, 75 insertions(+)

diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 48889c1..18b7fc3 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -15,10 +15,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "ehci.h"
 
+DECLARE_GLOBAL_DATA_PTR;
+
 #define USB_OTGREGS_OFFSET 0x000
 #define USB_H1REGS_OFFSET  0x200
 #define USB_H2REGS_OFFSET  0x400
@@ -48,6 +51,7 @@
 #define ANADIG_USB2_PLL_480_CTRL_EN_USB_CLKS   0x0040
 
 #define USBNC_OFFSET   0x200
+#define USBNC_PHY_STATUS_OFFSET0x23C
 #define USBNC_PHYSTATUS_ID_DIG (1 << 4) /* otg_id status */
 #define USBNC_PHYCFG2_ACAENB   (1 << 4) /* otg_id detection enable */
 #define UCTRL_PWR_POL  (1 << 9) /* OTG Polarity of Power Pin */
@@ -417,6 +421,76 @@ static const struct ehci_ops mx6_ehci_ops = {
.init_after_reset = mx6_init_after_reset
 };
 
+static int ehci_usb_phy_mode(struct udevice *dev)
+{
+   struct usb_platdata *plat = dev_get_platdata(dev);
+   void *__iomem addr = (void *__iomem)dev_get_addr(dev);
+   void *__iomem phy_ctrl, *__iomem phy_status;
+   const void *blob = gd->fdt_blob;
+   int offset = dev->of_offset, phy_off;
+   u32 val;
+
+   /*
+* About fsl,usbphy, Refer to
+* Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt.
+*/
+   if (is_mx6()) {
+   phy_off = fdtdec_lookup_phandle(blob,
+   offset,
+   "fsl,usbphy");
+   if (phy_off < 0)
+   return -EINVAL;
+
+   addr = (void __iomem *)fdtdec_get_addr(blob, phy_off,
+  "reg");
+   if ((fdt_addr_t)addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   phy_ctrl = (void __iomem *)(addr + USBPHY_CTRL);
+   val = readl(phy_ctrl);
+
+   if (val & USBPHY_CTRL_OTG_ID)
+   plat->init_type = USB_INIT_DEVICE;
+   else
+   plat->init_type = USB_INIT_HOST;
+   } else if (is_mx7()) {
+   phy_status = (void __iomem *)(addr +
+ USBNC_PHY_STATUS_OFFSET);
+   val = readl(phy_status);
+
+   if (val & USBNC_PHYSTATUS_ID_DIG)
+   plat->init_type = USB_INIT_DEVICE;
+   else
+   plat->init_type = USB_INIT_HOST;
+   } else {
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int ehci_usb_ofdata_to_platdata(struct udevice *dev)
+{
+   struct usb_platdata *plat = dev_get_platdata(dev);
+   const char *mode;
+
+   mode = fdt_getprop(gd->fdt_blob, dev->of_offset, "dr_mode", NULL);
+   if (mode) {
+   if (strcmp(mode, "peripheral") == 0)
+   plat->init_type = USB_INIT_DEVICE;
+   else if (strcmp(mode, "host") == 0)
+   plat->init_type = USB_INIT_HOST;
+   else if (strcmp(mode, "otg") == 0)
+   return ehci_usb_phy_mode(dev);
+   else
+   return -EINVAL;
+
+   return 0;
+   }
+
+   return ehci_usb_phy_mode(dev);
+}
+
 static int ehci_usb_probe(struct udevice *dev)
 {
struct usb_platdata *plat = dev_get_platdata(dev);
@@ -460,6 +534,7 @@ U_BOOT_DRIVER(usb_mx6) = {
.name   = "ehci_mx6",
.id = UCLASS_USB,
.of_match = mx6_usb_ids,
+   .ofdata_to_platdata = ehci_usb_ofdata_to_platdata,
.probe  = ehci_usb_probe,
.remove = ehci_deregister,
.ops= &ehci_usb_ops,
-- 
2.6.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] imx: mx6sllevk: add usb support

2016-12-22 Thread Peng Fan


> > +#define USB_OTHERREGS_OFFSET   0x800
> > +#define UCTRL_PWR_POL  (1 << 9)
> > +
> > +int board_ehci_hcd_init(int port) {
> > +   u32 *usbnc_usb_ctrl;
> > +
> > +   if (port > 1)
> > +   return -EINVAL;
> > +
> > +   usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR +
>  USB_OTHERREGS_OFFSET
>  +
> > +port * 4);
> > +
> > +   /* Set Power polarity */
> > +   setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL);
> > +   return 0;
> > +}
> 
>  Is this function similar to what usb_oc_config() does ?
> >>>
> >>> No, this bit is not for overcurrent. According to RM, this is
> >>> OTG Power Polarity This bit should be set according to power
> >>> switch's enable
> >> polarity.
> >>> 1 Power switch has an active-high enable input
> >>> 0 Power switch has an active-low enable input
> >>>
> >>> This is board specific.
> >>
> >> Great, except it should also be part of the driver , the same way
> >> as polarity is configured, yes ?
> >
> > I just found that there is code for mx7,
> > http://lists.denx.de/pipermail/u-boot/2016-July/260321.html
> >
> > Then do you agree I add such piece code in usb_power_config for mx6?
> > "
> > #ifdef CONFIG_MXC_USB_OTG_HACTIVE
> > setbits_le32(ctrl, UCTRL_PWR_POL); #else
> > clrbits_le32(ctrl, UCTRL_PWR_POL); #endif "
> 
>  Didn't you add DT support in a patch sent like ... yesterday ? :)
>  Just use DT property instead of ifdef.
> >>>
> >>> There is no property for otg power polatiry in upstream Linux. I
> >>> would not like to introduce one in U-Boot. We can drop the ifdef
> >>> when there is an
> >> property in upstream. What do you think?
> >>
> >> So uh, how can the USB work in mainline Linux on that board ?
> >
> > Confirmed with IC, if using gpio to control vbus power, no need to configure
> this bit.
> > Since in dts, we are using gpio regulator to control vbus, this piece
> > code in patch 3/3 can be discarded. I'll drop it in V2.
> 
> Hum, OK. Let's revisit this when we need this then ?

Take i.MX6SLL as an example,
The pin key_col4 can be configured with the two functions.
[1] MX6_PAD_KEY_COL4__USB_OTG1_PWR 
[2] MX6_PAD_KEY_COL4__GPIO4_IO00

In fsl i.mx uboot code, the common way is to use [1] and configure the polarity 
to enable the vbus power.
But in kernel, it is configured as [2] and use gpio regulator to enable the 
vbus power.

This is board specific. There is no upstream property for this bit. When there 
is an upstream property for this,
We could add it in probe function for those that use [1] in dts pinmux.

Now I am using the same dts from kernel which this pinmux configured as [2], so 
this piece code is not needed for now.

Thanks,
Peng.
> 
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 2/3] usb: ehci-mx6: handle vbus-supply

2016-12-22 Thread Peng Fan
Drop board_ehci_power when dm usb used and switch to use
regulator api to handle vbus.

Signed-off-by: Peng Fan 
Cc: Marek Vasut 
Cc: Simon Glass 
Cc: Stefano Babic 
---

V2:
 None

 drivers/usb/host/ehci-mx6.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 18b7fc3..7b309b7 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ehci.h"
 
@@ -388,6 +389,7 @@ int ehci_hcd_stop(int index)
 struct ehci_mx6_priv_data {
struct ehci_ctrl ctrl;
struct usb_ehci *ehci;
+   struct udevice *vbus_supply;
enum usb_init_type init_type;
int portnr;
 };
@@ -403,7 +405,15 @@ static int mx6_init_after_reset(struct ehci_ctrl *dev)
if (ret)
return ret;
 
-   board_ehci_power(priv->portnr, (type == USB_INIT_DEVICE) ? 0 : 1);
+   if (priv->vbus_supply) {
+   ret = regulator_set_enable(priv->vbus_supply,
+  (type == USB_INIT_DEVICE) ?
+  false : true);
+   if (ret) {
+   puts("Error enabling VBUS supply\n");
+   return ret;
+   }
+   }
 
if (type == USB_INIT_DEVICE)
return 0;
@@ -496,19 +506,33 @@ static int ehci_usb_probe(struct udevice *dev)
struct usb_platdata *plat = dev_get_platdata(dev);
struct usb_ehci *ehci = (struct usb_ehci *)dev_get_addr(dev);
struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
+   enum usb_init_type type = plat->init_type;
struct ehci_hccr *hccr;
struct ehci_hcor *hcor;
int ret;
 
priv->ehci = ehci;
priv->portnr = dev->seq;
-   priv->init_type = plat->init_type;
+   priv->init_type = type;
+
+   ret = device_get_supply_regulator(dev, "vbus-supply",
+ &priv->vbus_supply);
+   if (ret)
+   debug("%s: No vbus supply\n", dev->name);
 
ret = ehci_mx6_common_init(ehci, priv->portnr);
if (ret)
return ret;
 
-   board_ehci_power(priv->portnr, (priv->init_type == USB_INIT_DEVICE) ? 0 
: 1);
+   if (priv->vbus_supply) {
+   ret = regulator_set_enable(priv->vbus_supply,
+  (type == USB_INIT_DEVICE) ?
+  false : true);
+   if (ret) {
+   puts("Error enabling VBUS supply\n");
+   return ret;
+   }
+   }
 
if (priv->init_type == USB_INIT_HOST) {
setbits_le32(&ehci->usbmode, CM_HOST);
-- 
2.6.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/2] i2c: cdns: Add additional compatible string for r1p14 of the IP.

2016-12-22 Thread Moritz Fischer
Adding additional compatible string for version 1.4 of the IP block.

Signed-off-by: Moritz Fischer 
Cc: Michal Simek 
Cc: Heiko Schocher 
---
 drivers/i2c/i2c-cdns.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
index f49f60b..ef85a70 100644
--- a/drivers/i2c/i2c-cdns.c
+++ b/drivers/i2c/i2c-cdns.c
@@ -366,6 +366,7 @@ static const struct dm_i2c_ops cdns_i2c_ops = {
 
 static const struct udevice_id cdns_i2c_of_match[] = {
{ .compatible = "cdns,i2c-r1p10" },
+   { .compatible = "cdns,i2c-r1p14" },
{ /* end of table */ }
 };
 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 2/2] ARM64: zynqmp: Fix i2c node's compatible string

2016-12-22 Thread Moritz Fischer
The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core
which fixes some silicon bugs that needed software workarounds
in Version 1.0 that was used on Zynq systems.

Signed-off-by: Moritz Fischer 
Cc: Michal Simek 
Cc: Heiko Schocher 
---
 arch/arm/dts/zynqmp.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index ab5c243..20c5efc 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -619,7 +619,7 @@
};
 
i2c0: i2c@ff02 {
-   compatible = "cdns,i2c-r1p10";
+   compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 17 4>;
@@ -630,7 +630,7 @@
};
 
i2c1: i2c@ff03 {
-   compatible = "cdns,i2c-r1p10";
+   compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 18 4>;
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] imx: mx6sllevk: add usb support

2016-12-22 Thread Peng Fan

Hi Marek,
> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Thursday, December 22, 2016 4:58 PM
> To: Peng Fan ; sba...@denx.de
> Cc: u-boot@lists.denx.de; van.free...@gmail.com
> Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support
> 
> On 12/22/2016 09:55 AM, Peng Fan wrote:
> >
> >
> >>> +#define USB_OTHERREGS_OFFSET   0x800
> >>> +#define UCTRL_PWR_POL  (1 << 9)
> >>> +
> >>> +int board_ehci_hcd_init(int port) {
> >>> + u32 *usbnc_usb_ctrl;
> >>> +
> >>> + if (port > 1)
> >>> + return -EINVAL;
> >>> +
> >>> + usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR +
> >> USB_OTHERREGS_OFFSET
> >> +
> >>> +  port * 4);
> >>> +
> >>> + /* Set Power polarity */
> >>> + setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL);
> >>> + return 0;
> >>> +}
> >>
> >> Is this function similar to what usb_oc_config() does ?
> >
> > No, this bit is not for overcurrent. According to RM, this is
> > OTG Power Polarity This bit should be set according to power
> > switch's enable
>  polarity.
> > 1 Power switch has an active-high enable input
> > 0 Power switch has an active-low enable input
> >
> > This is board specific.
> 
>  Great, except it should also be part of the driver , the same
>  way as polarity is configured, yes ?
> >>>
> >>> I just found that there is code for mx7,
> >>> http://lists.denx.de/pipermail/u-boot/2016-July/260321.html
> >>>
> >>> Then do you agree I add such piece code in usb_power_config for
> mx6?
> >>> "
> >>> #ifdef CONFIG_MXC_USB_OTG_HACTIVE
> >>> setbits_le32(ctrl, UCTRL_PWR_POL); #else
> >>> clrbits_le32(ctrl, UCTRL_PWR_POL); #endif "
> >>
> >> Didn't you add DT support in a patch sent like ... yesterday ? :)
> >> Just use DT property instead of ifdef.
> >
> > There is no property for otg power polatiry in upstream Linux. I
> > would not like to introduce one in U-Boot. We can drop the ifdef
> > when there is an
>  property in upstream. What do you think?
> 
>  So uh, how can the USB work in mainline Linux on that board ?
> >>>
> >>> Confirmed with IC, if using gpio to control vbus power, no need to
> >>> configure
> >> this bit.
> >>> Since in dts, we are using gpio regulator to control vbus, this
> >>> piece code in patch 3/3 can be discarded. I'll drop it in V2.
> >>
> >> Hum, OK. Let's revisit this when we need this then ?
> >
> > Take i.MX6SLL as an example,
> > The pin key_col4 can be configured with the two functions.
> > [1] MX6_PAD_KEY_COL4__USB_OTG1_PWR
> > [2] MX6_PAD_KEY_COL4__GPIO4_IO00
> >
> > In fsl i.mx uboot code, the common way is to use [1] and configure the
> polarity to enable the vbus power.
> > But in kernel, it is configured as [2] and use gpio regulator to enable the 
> > vbus
> power.
> >
> > This is board specific. There is no upstream property for this bit.
> > When there is an upstream property for this, We could add it in probe
> function for those that use [1] in dts pinmux.
> >
> > Now I am using the same dts from kernel which this pinmux configured as [2],
> so this piece code is not needed for now.
> 
> Well, can you submit a proposal with the new prop for devicetree@ ?
> It can then be improved in linux too ...

I'll talk with our internal Linux usb maintainer to see whether he has plan to 
do this.

Thanks,
Peng.
> 
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3 2/2] spl: move RAM boot support in separate file

2016-12-22 Thread Stefan Agner
From: Stefan Agner 

Add a new top-level config option so support booting an image stored
in RAM. This allows to move the RAM boot support into a sparate file
and having a single condition to compile that file.

Signed-off-by: Stefan Agner 
---
The series has been build tested using buildman.

$ ./tools/buildman/buildman
...
Building current source for 1245 boards (8 threads, 1 job per thread)
 10340  211 /1245   0:00:03  : P1022DS_NAND

--
Stefan

Changes in v3:
- Use default y in ...

Changes in v2:
- Added missing new file spl_ram.c
- Add new config also to defconfig file

 common/spl/Kconfig   | 12 +++--
 common/spl/Makefile  |  1 +
 common/spl/spl.c | 58 -
 common/spl/spl_ram.c | 73 
 4 files changed, 84 insertions(+), 60 deletions(-)
 create mode 100644 common/spl/spl_ram.c

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index ea084f462b..b1aa1483c9 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -449,9 +449,17 @@ config SPL_POWER_SUPPORT
  in drivers/power, drivers/power/pmic and drivers/power/regulator
  as part of an SPL build.
 
+config SPL_RAM_SUPPORT
+   bool "Support booting from RAM"
+   depends on SPL
+   default y if MICROBLAZE || ARCH_SOCFPGA || TEGRA || ARCH_ZYNQ
+   help
+ Enable booting of an image in RAM. The image can be preloaded or
+ it can be loaded by SPL directly into RAM (e.g. using USB).
+
 config SPL_RAM_DEVICE
bool "Support booting from preloaded image in RAM"
-   depends on SPL
+   depends on SPL_RAM_SUPPORT
default y if MICROBLAZE || ARCH_SOCFPGA || TEGRA || ARCH_ZYNQ
help
  Enable booting of an image already loaded in RAM. The image has to
@@ -558,7 +566,7 @@ choice
 
 config SPL_DFU_RAM
bool "RAM device"
-   depends on SPL_DFU_SUPPORT
+   depends on SPL_DFU_SUPPORT && SPL_RAM_SUPPORT
help
 select RAM/DDR memory device for loading binary images
 (u-boot/kernel) to the selected device partition using
diff --git a/common/spl/Makefile b/common/spl/Makefile
index ed02635e72..1933cbdfed 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -26,4 +26,5 @@ obj-$(CONFIG_SPL_EXT_SUPPORT) += spl_ext.o
 obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o
 obj-$(CONFIG_SPL_DFU_SUPPORT) += spl_dfu.o
 obj-$(CONFIG_SPL_SPI_LOAD) += spl_spi.o
+obj-$(CONFIG_SPL_RAM_SUPPORT) += spl_ram.o
 endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index f7df834e32..2f3b6a47f8 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -170,64 +170,6 @@ __weak void __noreturn jump_to_image_no_args(struct 
spl_image_info *spl_image)
image_entry();
 }
 
-#ifndef CONFIG_SPL_LOAD_FIT_ADDRESS
-# define CONFIG_SPL_LOAD_FIT_ADDRESS   0
-#endif
-
-#if defined(CONFIG_SPL_RAM_DEVICE) || defined(CONFIG_SPL_DFU_SUPPORT)
-static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
-  ulong count, void *buf)
-{
-   debug("%s: sector %lx, count %lx, buf %lx\n",
- __func__, sector, count, (ulong)buf);
-   memcpy(buf, (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + sector), count);
-   return count;
-}
-
-static int spl_ram_load_image(struct spl_image_info *spl_image,
- struct spl_boot_device *bootdev)
-{
-   struct image_header *header;
-
-   header = (struct image_header *)CONFIG_SPL_LOAD_FIT_ADDRESS;
-
-#if defined(CONFIG_SPL_DFU_SUPPORT)
-   if (bootdev->boot_device == BOOT_DEVICE_DFU)
-   spl_dfu_cmd(0, "dfu_alt_info_ram", "ram", "0");
-#endif
-
-   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
-   image_get_magic(header) == FDT_MAGIC) {
-   struct spl_load_info load;
-
-   debug("Found FIT\n");
-   load.bl_len = 1;
-   load.read = spl_ram_load_read;
-   spl_load_simple_fit(spl_image, &load, 0, header);
-   } else {
-   debug("Legacy image\n");
-   /*
-* Get the header.  It will point to an address defined by
-* handoff which will tell where the image located inside
-* the flash. For now, it will temporary fixed to address
-* pointed by U-Boot.
-*/
-   header = (struct image_header *)
-   (CONFIG_SYS_TEXT_BASE - sizeof(struct image_header));
-
-   spl_parse_image_header(spl_image, header);
-   }
-
-   return 0;
-}
-#if defined(CONFIG_SPL_RAM_DEVICE)
-SPL_LOAD_IMAGE_METHOD("RAM", 0, BOOT_DEVICE_RAM, spl_ram_load_image);
-#endif
-#if defined(CONFIG_SPL_DFU_SUPPORT)
-SPL_LOAD_IMAGE_METHOD("USB DFU", 0, BOOT_DEVICE_DFU, spl_ram_load_image);
-#endif
-#endif
-
 int spl_init(void)
 {
int ret;
diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c
new file mode 100644
index 00..b2645a1948
--- /dev/null
+++ b/common/spl/sp

[U-Boot] [PATCH v3 1/2] Convert CONFIG_SPL_RAM_DEVICE to defconfig

2016-12-22 Thread Stefan Agner
From: Stefan Agner 

This converts the following to Kconfig:
  CONFIG_SPL_RAM_DEVICE

Signed-off-by: Stefan Agner 
---

Changes in v3: None
Changes in v2: None

 common/spl/Kconfig   | 9 +
 include/configs/microblaze-generic.h | 1 -
 include/configs/socfpga_common.h | 1 -
 include/configs/tegra-common.h   | 1 -
 include/configs/xilinx_zynqmp.h  | 1 -
 include/configs/zynq-common.h| 1 -
 6 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index cba51f5df6..ea084f462b 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -449,6 +449,15 @@ config SPL_POWER_SUPPORT
  in drivers/power, drivers/power/pmic and drivers/power/regulator
  as part of an SPL build.
 
+config SPL_RAM_DEVICE
+   bool "Support booting from preloaded image in RAM"
+   depends on SPL
+   default y if MICROBLAZE || ARCH_SOCFPGA || TEGRA || ARCH_ZYNQ
+   help
+ Enable booting of an image already loaded in RAM. The image has to
+ be already in memory when SPL takes over, e.g. loaded by the boot
+ ROM.
+
 config SPL_SATA_SUPPORT
bool "Support loading from SATA"
depends on SPL
diff --git a/include/configs/microblaze-generic.h 
b/include/configs/microblaze-generic.h
index 7abffdb2ef..cc90b73fa1 100644
--- a/include/configs/microblaze-generic.h
+++ b/include/configs/microblaze-generic.h
@@ -284,7 +284,6 @@
 
 #define CONFIG_SPL_LDSCRIPT"arch/microblaze/cpu/u-boot-spl.lds"
 
-#define CONFIG_SPL_RAM_DEVICE
 #ifdef CONFIG_SYS_FLASH_BASE
 # define CONFIG_SYS_UBOOT_BASE CONFIG_SYS_FLASH_BASE
 #endif
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 58a6550844..7292469433 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -309,7 +309,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
  * 0x_FF00 .. End of SRAM
  */
 #define CONFIG_SPL_FRAMEWORK
-#define CONFIG_SPL_RAM_DEVICE
 #define CONFIG_SPL_TEXT_BASE   CONFIG_SYS_INIT_RAM_ADDR
 #define CONFIG_SPL_MAX_SIZE(64 * 1024)
 
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h
index 23a0e782e0..f30fec84a2 100644
--- a/include/configs/tegra-common.h
+++ b/include/configs/tegra-common.h
@@ -98,7 +98,6 @@
 
 /* Defines for SPL */
 #define CONFIG_SPL_FRAMEWORK
-#define CONFIG_SPL_RAM_DEVICE
 #define CONFIG_SPL_BOARD_INIT
 #define CONFIG_SPL_NAND_SIMPLE
 #define CONFIG_SPL_MAX_FOOTPRINT   (CONFIG_SYS_TEXT_BASE - \
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index fb4f6d6806..8845ff425d 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -260,7 +260,6 @@
 
 #define CONFIG_SPL_FRAMEWORK
 #define CONFIG_SPL_BOARD_INIT
-#define CONFIG_SPL_RAM_DEVICE
 
 /* u-boot is like dtb */
 #define CONFIG_SPL_FS_LOAD_ARGS_NAME   "u-boot.bin"
diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 953e7311a6..e04be5c18c 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -296,7 +296,6 @@
 #define CONFIG_CMD_SPL
 #define CONFIG_SPL_FRAMEWORK
 #define CONFIG_SPL_BOARD_INIT
-#define CONFIG_SPL_RAM_DEVICE
 
 #define CONFIG_SPL_LDSCRIPT"arch/arm/mach-zynq/u-boot-spl.lds"
 
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot