Re: [PATCH v8 1/2] usb: phy: samsung: Introducing usb phy driver for hsotg
.compatible = "samsung,exynos4210-usbphy",
> + .data = (void *)TYPE_EXYNOS4210,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, samsung_usbphy_dt_match);
> +#else
> +#define samsung_usbphy_dt_match NULL
> +#endif
Instead of using else and defining samsung_usbphy_dt_match manually,
instead you can use of_match_ptr macro. (See my next comment.)
> +
> +static struct platform_device_id samsung_usbphy_driver_ids[] = {
> + {
> + .name = "s3c64xx-usbphy",
> + .driver_data= TYPE_S3C64XX,
> + }, {
> + .name = "exynos4210-usbphy",
> + .driver_data= TYPE_EXYNOS4210,
> + },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(platform, samsung_usbphy_driver_ids);
> +
> +static struct platform_driver samsung_usbphy_driver = {
> + .probe = samsung_usbphy_probe,
> + .remove = __devexit_p(samsung_usbphy_remove),
> + .id_table = samsung_usbphy_driver_ids,
> + .driver = {
> + .name = "samsung-usbphy",
> + .owner = THIS_MODULE,
> + .of_match_table = samsung_usbphy_dt_match,
.of_match_table = of_match_ptr(samsung_usbphy_dt_match),
> + },
> +};
> +
> +module_platform_driver(samsung_usbphy_driver);
> +
> +MODULE_DESCRIPTION("Samsung USB phy controller");
> +MODULE_AUTHOR("Praveen Paneri ");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:samsung-usbphy");
> diff --git a/include/linux/platform_data/samsung-usbphy.h
> b/include/linux/platform_data/samsung-usbphy.h new file mode 100644
> index 000..1bd24cb
> --- /dev/null
> +++ b/include/linux/platform_data/samsung-usbphy.h
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (C) 2012 Samsung Electronics Co.Ltd
> + * http://www.samsung.com/
> + * Author: Praveen Paneri
> + *
> + * Defines platform data for samsung usb phy driver.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it + * under the terms of the GNU General Public License as
> published by the + * Free Software Foundation; either version 2 of the
> License, or (at your + * option) any later version.
> + */
> +
> +#ifndef __SAMSUNG_USBPHY_PLATFORM_H
> +#define __SAMSUNG_USBPHY_PLATFORM_H
> +
> +/**
> + * samsung_usbphy_data - Platform data for USB PHY driver.
> + * @pmu_isolation: Function to control usb phy isolation in PMU.
> + */
> +struct samsung_usbphy_data {
> + void (*pmu_isolation)(int on);
I believe this should be named in a generic way. This is called PMU
isolation on Exynos SoCs, but on S3C64xx it's USB PHY mask.
Best regards,
Tomasz Figa
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/2] usb: s3c-hsotg: Adding phy driver support
Hi Praveen,
On Wednesday 14 of November 2012 15:57:16 Praveen Paneri wrote:
> Adding the transceiver to hsotg driver. Keeping the platform data
> for continuing the smooth operation for boards which still uses it
>
> Signed-off-by: Praveen Paneri
> Acked-by: Kyungmin Park
> ---
> drivers/usb/gadget/s3c-hsotg.c | 37
> +++-- 1 files changed, 27
> insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/gadget/s3c-hsotg.c
> b/drivers/usb/gadget/s3c-hsotg.c index 6f696ee..bc30a2d 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -32,6 +32,7 @@
>
> #include
> #include
> +#include
> #include
>
> #include
> @@ -133,7 +134,9 @@ struct s3c_hsotg_ep {
> * struct s3c_hsotg - driver state.
> * @dev: The parent device supplied to the probe function
> * @driver: USB gadget driver
> - * @plat: The platform specific configuration data.
> + * @phy: The otg phy transceiver structure for phy control.
> + * @plat: The platform specific configuration data. This can be removed
> once + * all SoCs support usb transceiver.
> * @regs: The memory area mapped for accessing registers.
> * @irq: The IRQ number we are using
> * @supplies: Definition of USB power supplies
> @@ -153,6 +156,7 @@ struct s3c_hsotg_ep {
> struct s3c_hsotg {
> struct device*dev;
> struct usb_gadget_driver *driver;
> + struct usb_phy *phy;
> struct s3c_hsotg_plat*plat;
>
> spinlock_t lock;
> @@ -2854,7 +2858,10 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg
> *hsotg) struct platform_device *pdev = to_platform_device(hsotg->dev);
>
> dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
> - if (hsotg->plat->phy_init)
> +
> + if (hsotg->phy)
> + usb_phy_init(hsotg->phy);
> + else if (hsotg->plat->phy_init)
> hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
> }
>
> @@ -2869,7 +2876,9 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg
> *hsotg) {
> struct platform_device *pdev = to_platform_device(hsotg->dev);
>
> - if (hsotg->plat->phy_exit)
> + if (hsotg->phy)
> + usb_phy_shutdown(hsotg->phy);
> + else if (hsotg->plat->phy_exit)
> hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
> }
>
> @@ -3493,6 +3502,7 @@ static void s3c_hsotg_release(struct device *dev)
> static int __devinit s3c_hsotg_probe(struct platform_device *pdev)
> {
> struct s3c_hsotg_plat *plat = pdev->dev.platform_data;
> + struct usb_phy *phy;
> struct device *dev = &pdev->dev;
> struct s3c_hsotg_ep *eps;
> struct s3c_hsotg *hsotg;
> @@ -3501,20 +3511,27 @@ static int __devinit s3c_hsotg_probe(struct
> platform_device *pdev) int ret;
> int i;
>
> - plat = pdev->dev.platform_data;
> - if (!plat) {
> - dev_err(&pdev->dev, "no platform data defined\n");
> - return -EINVAL;
> - }
> -
> hsotg = devm_kzalloc(&pdev->dev, sizeof(struct s3c_hsotg),
> GFP_KERNEL); if (!hsotg) {
> dev_err(dev, "cannot get memory\n");
> return -ENOMEM;
> }
>
> + phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> + if (IS_ERR_OR_NULL(phy)) {
> + /* Fallback for pdata */
> + plat = pdev->dev.platform_data;
> + if (!plat) {
> + dev_err(&pdev->dev, "no platform data or transceiver
defined\n");
> + return -EPROBE_DEFER;
> + } else {
> + hsotg->plat = plat;
> + }
nitpick: The hsotg->plat = plat; assignment can be made without the else
statement as well.
Best regards,
Tomasz Figa
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 1/2] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi Praveen,
On Friday 23 of November 2012 09:56:37 Praveen Paneri wrote:
> >> +static void samsung_usbphy_enable(struct samsung_usbphy *sphy)
> >> +{
> >> + void __iomem *regs = sphy->regs;
> >> + u32 phypwr;
> >> + u32 phyclk;
> >> + u32 rstcon;
> >> +
> >> + /* set clock frequency for PLL */
> >> + phyclk = sphy->ref_clk_freq;
> >> + phypwr = readl(regs + SAMSUNG_PHYPWR);
> >> + rstcon = readl(regs + SAMSUNG_RSTCON);
> >> +
> >> + switch (sphy->cpu_type) {
> >> + case TYPE_S3C64XX:
> >> + phyclk &= ~PHYCLK_COMMON_ON_N;
> >> + phypwr &= ~PHYPWR_NORMAL_MASK;
> >> + rstcon |= RSTCON_SWRST;
> >> + break;
> >> + case TYPE_EXYNOS4210:
> >> + phypwr &= ~PHYPWR_NORMAL_MASK_PHY0;
> >> + rstcon |= RSTCON_SWRST;
> >> + default:
> >> + break;
> >> + }
> >> +
> >> + writel(phyclk, regs + SAMSUNG_PHYCLK);
> >> + /* set to normal of PHY0 */
> >
> > I don't understand this comment.
>
> Will change it to " Configure PHY0 for normal operation"
> That should be more clear, I suppose.
Yes, much better.
> >> + */
> >> +
> >> +#ifndef __SAMSUNG_USBPHY_PLATFORM_H
> >> +#define __SAMSUNG_USBPHY_PLATFORM_H
> >> +
> >> +/**
> >> + * samsung_usbphy_data - Platform data for USB PHY driver.
> >> + * @pmu_isolation: Function to control usb phy isolation in PMU.
> >> + */
> >> +struct samsung_usbphy_data {
> >> + void (*pmu_isolation)(int on);
> >
> > I believe this should be named in a generic way. This is called PMU
> > isolation on Exynos SoCs, but on S3C64xx it's USB PHY mask.
>
> Yes! I am aware of it. The fact that this ( MASK or ISOLATION) has
> always been part of the PMU, pmu_isolation seems quite generic that
> way. Though you can suggest a better name.
What do you think about set_isolation(int on) or power_isolation(int on)?
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/2] usb: s3c-hsotg: Adding phy driver support
Hi Praveen, On Friday 23 of November 2012 09:54:51 Praveen Paneri wrote: > We will anyway remove the platform data part soon. If you say I can > resend it again. I think that the requirement for platform data on DT-enabled systems should be removed before this series get merged, because there are already patches being worked on to remove auxdata tables (common clock framework support by Thomas Abraham). Adding next auxdata entry (containing platform data that must be provided) would make them depend on phy platform data removal patch, which would complicate things. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/4] ARM: Exynos5250: Enabling ohci-exynos driver
Hi Vivek,
On Tuesday 15 of January 2013 19:08:30 Vivek Gautam wrote:
> Adding OHCI device tree node for Exynos5250 along with
> the device base address.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> Acked-by: Grant Likely
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 15
> +++ arch/arm/boot/dts/exynos5250.dtsi |
> 6 ++ 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt index
> e8bbb47..f66fcdd 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -23,3 +23,18 @@ Example:
> interrupts = <0 71 0>;
> samsung,vbus-gpio = <&gpx2 6 1 3 3>;
> };
> +
> +OHCI
> +Required properties:
> + - compatible: should be "samsung,exynos4210-ohci" for USB 2.0
> + OHCI companion controller in host mode.
> + - reg: physical base address of the controller and length of memory
> mapped + region.
> + - interrupts: interrupt number to the cpu.
> +
> +Example:
> + usb@1212 {
> + compatible = "samsung,exynos4210-ohci";
> + reg = <0x1212 0x100>;
> + interrupts = <0 71 0>;
> + };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi index 2cbe53e..ebb0907 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -281,6 +281,12 @@
> interrupts = <0 71 0>;
> };
>
> + usb@1212 {
> + compatible = "samsung,exynos4210-ohci";
> + reg = <0x1212 0x100>;
> + interrupts = <0 71 0>;
For Samsung platforms we decided per board enabling of nodes and so this
node should also contain:
status = "disabled";
while in dts file of board using ohci there would be an overriding entry:
usb@1212 {
status = "okay";
};
I know that Exynos5250 has not been yet converted into this convention,
but using it when adding new devices will simplify the process.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] ARM: Exynos5250: Add clock information for dwc3-exynos
Hi Vivek,
Don't you need also some clkdev lookup entry to make the clock available
in the driver?
Best regards,
Tomasz
On Tuesday 15 of January 2013 19:08:31 Vivek Gautam wrote:
> Adding necessary device clock to exynos5 needed for
> the DWC3 controller.
>
> Signed-off-by: Vivek Gautam
> ---
> arch/arm/mach-exynos/clock-exynos5.c | 24
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/clock-exynos5.c
> b/arch/arm/mach-exynos/clock-exynos5.c index 0208c3a..13af020 100644
> --- a/arch/arm/mach-exynos/clock-exynos5.c
> +++ b/arch/arm/mach-exynos/clock-exynos5.c
> @@ -757,6 +757,11 @@ static struct clk exynos5_init_clocks_off[] = {
> .enable = exynos5_clk_ip_fsys_ctrl ,
> .ctrlbit= (1 << 18),
> }, {
> + .name = "usbdrd30",
> + .parent = &exynos5_clk_aclk_200.clk,
> + .enable = exynos5_clk_ip_fsys_ctrl,
> + .ctrlbit= (1 << 19),
> + }, {
> .name = "usbotg",
> .enable = exynos5_clk_ip_fsys_ctrl,
> .ctrlbit= (1 << 7),
> @@ -1035,6 +1040,16 @@ static struct clksrc_sources exynos5_clkset_group
> = { .nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
> };
>
> +struct clk *exynos5_clkset_usbdrd30_list[] = {
> + [0] = &exynos5_clk_mout_mpll.clk,
> + [1] = &exynos5_clk_mout_cpll.clk,
> +};
> +
> +struct clksrc_sources exynos5_clkset_usbdrd30 = {
> + .sources= exynos5_clkset_usbdrd30_list,
> + .nr_sources = ARRAY_SIZE(exynos5_clkset_usbdrd30_list),
> +};
> +
> /* Possible clock sources for aclk_266_gscl_sub Mux */
> static struct clk *clk_src_gscl_266_list[] = {
> [0] = &clk_ext_xtal_mux,
> @@ -1329,6 +1344,15 @@ static struct clksrc_clk exynos5_clksrcs[] = {
> .parent = &exynos5_clk_mout_cpll.clk,
> },
> .reg_div = { .reg = EXYNOS5_CLKDIV_GEN, .shift = 4, .size = 3
},
> + }, {
> + .clk= {
> + .name = "sclk_usbdrd30",
> + .enable = exynos5_clksrc_mask_fsys_ctrl,
> + .ctrlbit= (1 << 28),
> + },
> + .sources = &exynos5_clkset_usbdrd30,
> + .reg_src = { .reg = EXYNOS5_CLKSRC_FSYS, .shift = 28, .size =
1 },
> + .reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 24, .size =
4 },
> },
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] ARM: Exynos5250: Enabling dwc3-exynos driver
Hi Vivek,
Same comment as for patch 2.
Best regards,
Tomasz
On Tuesday 15 of January 2013 19:08:32 Vivek Gautam wrote:
> Adding DWC3 device tree node for Exynos5250 needed to
> parse device tree data.
> Also enabling XHCI support on exynos5250.
>
> Signed-off-by: Vivek Gautam
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 14
> ++ arch/arm/boot/dts/exynos5250.dtsi |
> 6 ++ arch/arm/mach-exynos/Kconfig |1 +
> 3 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt index
> f66fcdd..d660410 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -38,3 +38,17 @@ Example:
> reg = <0x1212 0x100>;
> interrupts = <0 71 0>;
> };
> +
> +DWC3
> +Required properties:
> + - compatible: should be "samsung,exynos5250-dwc3" for USB 3.0 DWC3
> controller. + - reg: physical base address of the controller and length
> of memory mapped + region.
> + - interrupts: interrupt number to the cpu.
> +
> +Example:
> + usb@1200 {
> + compatible = "samsung,exynos5250-dwc3";
> + reg = <0x1200 0x1>;
> + interrupts = <0 72 0>;
> + };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi index ebb0907..a747524 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -275,6 +275,12 @@
> #size-cells = <0>;
> };
>
> + usb@1200 {
> + compatible = "samsung,exynos5250-dwc3";
> + reg = <0x1200 0x1>;
> + interrupts = <0 72 0>;
> + };
> +
> usb@1211 {
> compatible = "samsung,exynos4210-ehci";
> reg = <0x1211 0x100>;
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index d26c9f9..e62fd20 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -428,6 +428,7 @@ config MACH_EXYNOS5_DT
> depends on ARCH_EXYNOS5
> select ARM_AMBA
> select USE_OF
> + select USB_ARCH_HAS_XHCI
> help
> Machine support for Samsung EXYNOS5 machine with device tree
> enabled. Select this if a fdt blob is available for the EXYNOS5 SoC
> based board.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/4] ARM: Exynos5250: Enabling ehci-s5p driver
Hi Vivek,
Same comment as for patch 2.
Best regards,
Tomasz
On Wednesday 16 of January 2013 11:15:43 Vivek Gautam wrote:
> Adding EHCI device tree node for Exynos5250 along with
> the device base adress and gpio line for vbus.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> Acked-by: Grant Likely
> ---
>
> Changes from v4:
> - Added gpio line for VBUS of USB2.0 on snow board.
>
> .../devicetree/bindings/usb/exynos-usb.txt | 25
> arch/arm/boot/dts/exynos5250-smdk5250.dts
> |4 +++ arch/arm/boot/dts/exynos5250-snow.dts |4
> +++ arch/arm/boot/dts/exynos5250.dtsi |6 4
> files changed, 39 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt new file mode
> 100644
> index 000..e8bbb47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -0,0 +1,25 @@
> +Samsung Exynos SoC USB controller
> +
> +The USB devices interface with USB controllers on Exynos SOCs.
> +The device node has following properties.
> +
> +EHCI
> +Required properties:
> + - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
> + EHCI controller in host mode.
> + - reg: physical base address of the controller and length of memory
> mapped + region.
> + - interrupts: interrupt number to the cpu.
> +
> +Optional properties:
> + - samsung,vbus-gpio: if present, specifies the GPIO that
> + needs to be pulled up for the bus to be powered.
> +
> +Example:
> +
> + usb@1211 {
> + compatible = "samsung,exynos4210-ehci";
> + reg = <0x1211 0x100>;
> + interrupts = <0 71 0>;
> + samsung,vbus-gpio = <&gpx2 6 1 3 3>;
> + };
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts index 942d576..7363e14
> 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -204,4 +204,8 @@
> samsung,mfc-r = <0x4300 0x80>;
> samsung,mfc-l = <0x5100 0x80>;
> };
> +
> + usb@1211 {
> + samsung,vbus-gpio = <&gpx2 6 1 3 3>;
> + };
> };
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts index 17dd951..47b6b84 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -40,4 +40,8 @@
> <&gpc4 5 2 3 0>, <&gpc4 6 2 3 0>;
> };
> };
> +
> + usb@1211 {
> + samsung,vbus-gpio = <&gpx1 1 1 3 3>;
> + };
> };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi index 30485de..2cbe53e 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -275,6 +275,12 @@
> #size-cells = <0>;
> };
>
> + usb@1211 {
> + compatible = "samsung,exynos4210-ehci";
> + reg = <0x1211 0x100>;
> + interrupts = <0 71 0>;
> + };
> +
> amba {
> #address-cells = <1>;
> #size-cells = <1>;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v9 0/2] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
On Friday 18 of January 2013 14:30:21 Praveen Paneri wrote: > Changes from v8: > Resending this patch series after rebasing to the latest usb-next > branch. Rewording inline comments for better readability. > Removed IS_ENABLED(CONFIG_OF) as pdev->dev.of_node is enough to check > for dt support. Using of_match_ptr to add of_match_table to > platform_driver structure. Removed unnecessary variables. > > Changes from v7: > Rebased to the latest usb-next branch. > Separating arch patches from these driver patches. > > Changes from v6: > Modified register definitions according to the existing ones. > Changed default PHY clk selection for SoCs. > Improved binding text and rebased to the latest usb-next. > > Changes from v5: > Moved clk_get() to driver's probe function. Now reference clock > frequency selection value is stored in samsung_usbphy structure for > later use. Used IS_ENABLED() instead of #ifdef in > samsung_usbphy_get_driver_data(). > > Changes from v4: > Moved header file contents to driver's source file > Removed unnecessary print message from driver's probe function > Dropped the Free Software Foundation address from the header > > Changes from v3: > Replaced susbsys_initcall()/module_exit() by module_platform_driver(). > Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver > is registered > Removed unnecessary devm_usb_put_phy() call from the hsotg driver > remove. > > Changes from v2: > Changed the driver filenames to samsung-usbphy > Rectified coding style related errors > > Changes from v1: > Rebased patches to latest usb-next branch > Changed the name 'sec_usbphy' to 'samsung_usbphy' > > This patch set introduces a phy driver for samsung SoCs. It uses the > existing transceiver infrastructure to provide phy control functions. > Use of this driver can be extended for usb host phy as well. Over the > period of time all the phy related code for most of the samsung SoCs > can be integrated here. Removing the existing phy code from > mach-s3c64xx. Same can be done for other SoCs when they start > supporting this phy driver. > This driver is tested with smdk6410 and Exynos4210(with DT). > > Praveen Paneri (2): > usb: phy: samsung: Introducing usb phy driver for hsotg > usb: s3c-hsotg: Adding phy driver support > > .../devicetree/bindings/usb/samsung-usbphy.txt | 11 + > drivers/usb/gadget/s3c-hsotg.c | 37 ++- > drivers/usb/phy/Kconfig|8 + > drivers/usb/phy/Makefile |1 + > drivers/usb/phy/samsung-usbphy.c | 354 > include/linux/platform_data/samsung-usbphy.h > | 27 ++ > 6 files changed, 428 insertions(+), 10 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode > 100644 drivers/usb/phy/samsung-usbphy.c > create mode 100644 include/linux/platform_data/samsung-usbphy.h > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-samsung-soc" in the body of a message to > majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Tested on Exynos4210-Trats. Tested-by: Tomasz Figa I also have patches for Exynos 4x12, which I will send once this series and generic PMU isolation setting patches get merged. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 32/32] usb: gadget: drop now unnecessary flag
Hi Felipe,
On Thursday 24 of January 2013 17:46:10 Felipe Balbi wrote:
> We don't need the ->register_my_device flag
> anymore because all UDC drivers have been
> properly converted.
>
> Let's remove every history of it.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/chipidea/udc.c | 1 -
> drivers/usb/dwc3/gadget.c | 1 -
> drivers/usb/gadget/amd5536udc.c| 1 -
> drivers/usb/gadget/at91_udc.c | 1 -
> drivers/usb/gadget/atmel_usba_udc.c| 1 -
> drivers/usb/gadget/bcm63xx_udc.c | 1 -
> drivers/usb/gadget/dummy_hcd.c | 1 -
> drivers/usb/gadget/fsl_qe_udc.c| 1 -
> drivers/usb/gadget/fsl_udc_core.c | 1 -
> drivers/usb/gadget/fusb300_udc.c | 1 -
> drivers/usb/gadget/goku_udc.c | 1 -
> drivers/usb/gadget/imx_udc.c | 1 -
> drivers/usb/gadget/lpc32xx_udc.c | 1 -
> drivers/usb/gadget/m66592-udc.c| 1 -
> drivers/usb/gadget/mv_u3d_core.c | 1 -
> drivers/usb/gadget/mv_udc_core.c | 1 -
> drivers/usb/gadget/net2272.c | 1 -
> drivers/usb/gadget/net2280.c | 1 -
> drivers/usb/gadget/omap_udc.c | 1 -
> drivers/usb/gadget/pch_udc.c | 1 -
> drivers/usb/gadget/pxa25x_udc.c| 1 -
> drivers/usb/gadget/pxa27x_udc.c| 1 -
> drivers/usb/gadget/r8a66597-udc.c | 1 -
> drivers/usb/gadget/s3c-hsotg.c | 1 -
> drivers/usb/gadget/s3c-hsudc.c | 1 -
> drivers/usb/gadget/s3c2410_udc.c | 1 -
> drivers/usb/gadget/udc-core.c | 3 ---
> drivers/usb/musb/musb_gadget.c | 1 -
> drivers/usb/renesas_usbhs/mod_gadget.c | 1 -
> include/linux/usb/gadget.h | 4
> 30 files changed, 35 deletions(-)
>
[snip]
> diff --git a/drivers/usb/gadget/udc-core.c
> b/drivers/usb/gadget/udc-core.c index 9195054..4ee0efc 100644
> --- a/drivers/usb/gadget/udc-core.c
> +++ b/drivers/usb/gadget/udc-core.c
> @@ -173,7 +173,6 @@ int usb_add_gadget_udc(struct device *parent, struct
> usb_gadget *gadget) if (!udc)
> goto err1;
>
> - if (gadget->register_my_device) {
> dev_set_name(&gadget->dev, "gadget");
>
> ret = device_register(&gadget->dev);
> @@ -211,7 +210,6 @@ err3:
> put_device(&udc->dev);
>
> err2:
> - if (gadget->register_my_device)
> put_device(&gadget->dev);
> err1:
> return ret;
> @@ -267,7 +265,6 @@ found:
> kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
> device_unregister(&udc->dev);
>
> - if (gadget->register_my_device)
> device_unregister(&gadget->dev);
Correct me if I am wrong, but doesn't this patch leave us with incorrect
indentation?
Otherwise looks good.
Best regards,
Tomasz Figa
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 01/32] usb: gadget: udc-core: allow udc class register gadget device
Hi Felipe,
On Thursday 24 of January 2013 17:45:39 Felipe Balbi wrote:
> Currently all UDC drivers are calling
> device_register() before calling
> usb_add_gadget_udc(). In order to avoid
> code duplication, we can allow udc-core.c
> register that device.
>
> However that would become a really large patch,
> so to cope with the meanwhile and allow us
> to write bite-sized patches, we're adding
> a flag which will be set by UDC driver once
> it removes the code for registering the
> gadget device.
>
> Once all are converted, the new flag will
> be removed.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc-core.c | 23 +++
> include/linux/usb/gadget.h| 4
> 2 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc-core.c
> b/drivers/usb/gadget/udc-core.c index 2a9cd36..9195054 100644
> --- a/drivers/usb/gadget/udc-core.c
> +++ b/drivers/usb/gadget/udc-core.c
> @@ -173,6 +173,14 @@ int usb_add_gadget_udc(struct device *parent,
> struct usb_gadget *gadget) if (!udc)
> goto err1;
>
> + if (gadget->register_my_device) {
> + dev_set_name(&gadget->dev, "gadget");
> +
> + ret = device_register(&gadget->dev);
> + if (ret)
> + goto err2;
> + }
> +
> device_initialize(&udc->dev);
> udc->dev.release = usb_udc_release;
> udc->dev.class = udc_class;
> @@ -180,7 +188,7 @@ int usb_add_gadget_udc(struct device *parent, struct
> usb_gadget *gadget) udc->dev.parent = parent;
> ret = dev_set_name(&udc->dev, "%s", kobject_name(&parent->kobj));
> if (ret)
> - goto err2;
> + goto err3;
Just a nitpick: If you are at changing labels of error path, wouldn't it
be better to give them some meaningful names? Like err_del_unlock,
err_put_udc, err_put_gadget, err_ret.
Otherwise looks good. Nice idea.
Reviewed-by: Tomasz Figa
Best regards,
Tomasz Figa
> udc->gadget = gadget;
>
> @@ -189,18 +197,22 @@ int usb_add_gadget_udc(struct device *parent,
> struct usb_gadget *gadget)
>
> ret = device_add(&udc->dev);
> if (ret)
> - goto err3;
> + goto err4;
>
> mutex_unlock(&udc_lock);
>
> return 0;
> -err3:
> +
> +err4:
> list_del(&udc->list);
> mutex_unlock(&udc_lock);
>
> -err2:
> +err3:
> put_device(&udc->dev);
>
> +err2:
> + if (gadget->register_my_device)
> + put_device(&gadget->dev);
> err1:
> return ret;
> }
> @@ -254,6 +266,9 @@ found:
>
> kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
> device_unregister(&udc->dev);
> +
> + if (gadget->register_my_device)
> + device_unregister(&gadget->dev);
> }
> EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
>
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 2e297e8..fcd9ef8 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -494,6 +494,9 @@ struct usb_gadget_ops {
> * only supports HNP on a different root port.
> * @b_hnp_enable: OTG device feature flag, indicating that the A-Host
> * enabled HNP support.
> + * @register_my_device: Flag telling udc-core that UDC driver didn't
> + * register the gadget device to the driver model. Temporary until
> + * all UDC drivers are fixed up properly.
> * @name: Identifies the controller hardware type. Used in diagnostics
> * and sometimes configuration.
> * @dev: Driver model state for this abstract device.
> @@ -531,6 +534,7 @@ struct usb_gadget {
> unsignedb_hnp_enable:1;
> unsigneda_hnp_support:1;
> unsigneda_alt_hnp_support:1;
> + unsignedregister_my_device:1;
> const char *name;
> struct device dev;
> unsignedout_epnum;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 24/32] usb: gadget: s3c-hsotg: let udc-core manage gadget->dev
Hi Felipe,
On Thursday 24 of January 2013 17:46:02 Felipe Balbi wrote:
> By simply setting a flag, we can drop some
> boilerplate code.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/gadget/s3c-hsotg.c | 14 +-
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/usb/gadget/s3c-hsotg.c
> b/drivers/usb/gadget/s3c-hsotg.c index 833d85b..bd8292d 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -3552,17 +3552,13 @@ static int s3c_hsotg_probe(struct
> platform_device *pdev)
>
> dev_info(dev, "regs %p, irq %d\n", hsotg->regs, hsotg->irq);
>
> - device_initialize(&hsotg->gadget.dev);
> -
> - dev_set_name(&hsotg->gadget.dev, "gadget");
> -
> hsotg->gadget.max_speed = USB_SPEED_HIGH;
> hsotg->gadget.ops = &s3c_hsotg_gadget_ops;
> hsotg->gadget.name = dev_name(dev);
> -
> hsotg->gadget.dev.parent = dev;
> hsotg->gadget.dev.dma_mask = dev->dma_mask;
> hsotg->gadget.dev.release = s3c_hsotg_release;
> + hsotg->gadget.register_my_device = true;
>
> /* reset the system */
>
> @@ -3643,12 +3639,6 @@ static int s3c_hsotg_probe(struct platform_device
> *pdev)
>
> s3c_hsotg_phy_disable(hsotg);
>
> - ret = device_add(&hsotg->gadget.dev);
> - if (ret) {
> - put_device(&hsotg->gadget.dev);
> - goto err_ep_mem;
> - }
> -
> ret = usb_add_gadget_udc(&pdev->dev, &hsotg->gadget);
> if (ret)
> goto err_ep_mem;
> @@ -3687,10 +3677,8 @@ static int s3c_hsotg_remove(struct
> platform_device *pdev) }
>
> s3c_hsotg_phy_disable(hsotg);
> -
> clk_disable_unprepare(hsotg->clk);
>
> - device_unregister(&hsotg->gadget.dev);
> return 0;
> }
Looks good.
Reviewed-by: Tomasz Figa
Best regards,
Tomasz Figa
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v9 0/2] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
On Wednesday 27 of February 2013 14:00:25 Vivek Gautam wrote: > Hi Balbi, > > On Wed, Feb 27, 2013 at 1:45 PM, Felipe Balbi wrote: > > Hi, > > > > On Fri, Jan 18, 2013 at 02:30:21PM +0530, Praveen Paneri wrote: > >> Changes from v8: > >> Resending this patch series after rebasing to the latest usb-next > >> branch. Rewording inline comments for better readability. > >> Removed IS_ENABLED(CONFIG_OF) as pdev->dev.of_node is enough to check > >> for dt support. Using of_match_ptr to add of_match_table to > >> platform_driver structure. Removed unnecessary variables. > > > > trying applying these but it doesn't apply unfortunately. > > Already present in 3.8.0 ? ;-) That's great. I will send my patch adding Exynos 4x12 support in next days. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi Praveen, Marc,
On Wednesday 12 of September 2012 13:08:26 Marc Kleine-Budde wrote:
> > +static const struct of_device_id samsung_usbphy_dt_match[];
> > +
> > +static inline int samsung_usbphy_get_driver_data(struct
> > platform_device *pdev) +{
> > +#ifdef CONFIG_OF
>
> if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
Is this check needed at all?
In case of CONFIG_OF disabled, of_node should always be NULL and there is a
dummy macro provided for of_match_node, so it should compile and work just
fine.
--
Best regards,
Tomasz Figa
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] Common Clock Framework support for Samsung S3C64xx
This series is an attempt to move clock support on Samsung S3C64xx SoCs to Common Clock Framework. First, support for PLL types present on S3C64xx SoCs is added to Samsung Common Clock Framework driver. Then the main clock driver for mentioned SoCs is introduced. Further patches contain fixes for drivers to make them compliant with CCF semantics, migration of platform code to use the new clock driver and removal of old clock management code. Depends on: - [PATCH 0/6] Samsung watchdog support clean-up http://thread.gmane.org/gmane.linux.kernel.samsung-soc/18736/focus=18989 - [PATCH 00/15] Final Samsung PWM support cleanup http://www.spinics.net/lists/arm-kernel/msg248725.html On S3C6410-based Tiny6410 board (Mini6410-compatible): Tested-by: Tomasz Figa Tomasz Figa (7): clk: samsung: pll: Add support for PLL6552 and PLL6553 clk: samsung: Add clock driver for S3C64xx SoCs ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare ARM: s3c64xx: Migrate clock handling to Common Clock Framework ARM: s3c64xx: Remove old clock management code .../bindings/clock/samsung,s3c64xx-clock.txt | 48 + arch/arm/Kconfig |2 +- arch/arm/mach-s3c64xx/Makefile |2 +- arch/arm/mach-s3c64xx/clock.c | 1007 arch/arm/mach-s3c64xx/common.c | 21 +- arch/arm/mach-s3c64xx/common.h | 12 +- arch/arm/mach-s3c64xx/dma.c|4 +- arch/arm/mach-s3c64xx/include/mach/regs-clock.h| 132 +-- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-smartq.c| 11 +- arch/arm/mach-s3c64xx/mach-smdk6400.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s3c64xx/pm.c | 21 - arch/arm/mach-s3c64xx/s3c6400.c|6 - arch/arm/mach-s3c64xx/s3c6410.c|7 - arch/arm/plat-samsung/include/plat/cpu.h |4 + drivers/clk/samsung/Makefile |1 + drivers/clk/samsung/clk-pll.c | 160 drivers/clk/samsung/clk-pll.h |4 + drivers/clk/samsung/clk-s3c64xx.c | 503 ++ drivers/usb/host/ohci-s3c2410.c|8 +- include/dt-bindings/clock/samsung,s3c64xx-clock.h | 144 +++ 26 files changed, 907 insertions(+), 1204 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt delete mode 100644 arch/arm/mach-s3c64xx/clock.c create mode 100644 drivers/clk/samsung/clk-s3c64xx.c create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] clk: samsung: pll: Add support for PLL6552 and PLL6553
This patch adds support for PLL6552 and PLL6553 PLLs present on Samsung
S3C64xx SoCs.
Signed-off-by: Tomasz Figa
---
drivers/clk/samsung/clk-pll.c | 160 ++
drivers/clk/samsung/clk-pll.h | 4 ++
2 files changed, 164 insertions(+)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 89135f6..cef0bb9 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -336,6 +336,166 @@ struct clk * __init samsung_clk_register_pll46xx(const
char *name,
}
/*
+ * PLL6552 Clock Type
+ */
+
+#define PLL6552_LOCK_REG 0x00
+#define PLL6552_CON_REG0x0c
+
+#define PLL6552_MDIV_MASK 0x3ff
+#define PLL6552_PDIV_MASK 0x3f
+#define PLL6552_SDIV_MASK 0x7
+#define PLL6552_MDIV_SHIFT 16
+#define PLL6552_PDIV_SHIFT 8
+#define PLL6552_SDIV_SHIFT 0
+
+struct samsung_clk_pll6552 {
+ struct clk_hw hw;
+ void __iomem *reg_base;
+};
+
+#define to_clk_pll6552(_hw) container_of(_hw, struct samsung_clk_pll6552, hw)
+
+static unsigned long samsung_pll6552_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll6552 *pll = to_clk_pll6552(hw);
+ u32 mdiv, pdiv, sdiv, pll_con;
+ u64 fvco = parent_rate;
+
+ pll_con = __raw_readl(pll->reg_base + PLL6552_CON_REG);
+ mdiv = (pll_con >> PLL6552_MDIV_SHIFT) & PLL6552_MDIV_MASK;
+ pdiv = (pll_con >> PLL6552_PDIV_SHIFT) & PLL6552_PDIV_MASK;
+ sdiv = (pll_con >> PLL6552_SDIV_SHIFT) & PLL6552_SDIV_MASK;
+
+ fvco *= mdiv;
+ do_div(fvco, (pdiv << sdiv));
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6552_clk_ops = {
+ .recalc_rate = samsung_pll6552_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll6552(const char *name,
+ const char *pname, void __iomem *base)
+{
+ struct samsung_clk_pll6552 *pll;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+ if (!pll) {
+ pr_err("%s: could not allocate pll clk %s\n", __func__, name);
+ return NULL;
+ }
+
+ init.name = name;
+ init.ops = &samsung_pll6552_clk_ops;
+ init.parent_names = &pname;
+ init.num_parents = 1;
+
+ pll->hw.init = &init;
+ pll->reg_base = base;
+
+ clk = clk_register(NULL, &pll->hw);
+ if (IS_ERR(clk)) {
+ pr_err("%s: failed to register pll clock %s\n", __func__,
+ name);
+ kfree(pll);
+ }
+
+ if (clk_register_clkdev(clk, name, NULL))
+ pr_err("%s: failed to register lookup for %s", __func__, name);
+
+ return clk;
+}
+
+/*
+ * PLL6553 Clock Type
+ */
+
+#define PLL6553_LOCK_REG 0x00
+#define PLL6553_CON0_REG 0x0c
+#define PLL6553_CON1_REG 0x10
+
+#define PLL6553_MDIV_MASK 0xff
+#define PLL6553_PDIV_MASK 0x3f
+#define PLL6553_SDIV_MASK 0x7
+#define PLL6553_KDIV_MASK 0x
+#define PLL6553_MDIV_SHIFT 16
+#define PLL6553_PDIV_SHIFT 8
+#define PLL6553_SDIV_SHIFT 0
+#define PLL6553_KDIV_SHIFT 0
+
+struct samsung_clk_pll6553 {
+ struct clk_hw hw;
+ void __iomem *reg_base;
+};
+
+#define to_clk_pll6553(_hw) container_of(_hw, struct samsung_clk_pll6553, hw)
+
+static unsigned long samsung_pll6553_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll6553 *pll = to_clk_pll6553(hw);
+ u32 mdiv, pdiv, sdiv, kdiv, pll_con0, pll_con1;
+ u64 fvco = parent_rate;
+
+ pll_con0 = __raw_readl(pll->reg_base + PLL6553_CON0_REG);
+ pll_con1 = __raw_readl(pll->reg_base + PLL6553_CON1_REG);
+ mdiv = (pll_con0 >> PLL6553_MDIV_SHIFT) & PLL6553_MDIV_MASK;
+ pdiv = (pll_con0 >> PLL6553_PDIV_SHIFT) & PLL6553_PDIV_MASK;
+ sdiv = (pll_con0 >> PLL6553_SDIV_SHIFT) & PLL6553_SDIV_MASK;
+ kdiv = (pll_con1 >> PLL6553_KDIV_SHIFT) & PLL6553_KDIV_MASK;
+
+ fvco *= (mdiv << 16) + kdiv;
+ do_div(fvco, (pdiv << sdiv));
+ fvco >>= 16;
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6553_clk_ops = {
+ .recalc_rate = samsung_pll6553_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll6553(const char *name,
+ const char *pname, void __iomem *base)
+{
+ struct samsung_clk_pll6553 *pll;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+ if (!pll) {
+ pr_err("%s: could not allocate pll clk %s\n", __func__, name);
+
[PATCH 6/7] ARM: s3c64xx: Migrate clock handling to Common Clock Framework
This patch migrates the s3c64xx platform to use the new clock driver
using Common Clock Framework.
Signed-off-by: Tomasz Figa
---
arch/arm/Kconfig | 2 +-
arch/arm/mach-s3c64xx/Makefile| 2 +-
arch/arm/mach-s3c64xx/common.c| 21 +
arch/arm/mach-s3c64xx/common.h| 10 +-
arch/arm/mach-s3c64xx/mach-anw6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-crag6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-hmt.c | 2 +-
arch/arm/mach-s3c64xx/mach-mini6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-ncp.c | 2 +-
arch/arm/mach-s3c64xx/mach-smartq.c | 11 ++-
arch/arm/mach-s3c64xx/mach-smdk6400.c | 2 +-
arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +-
arch/arm/mach-s3c64xx/s3c6400.c | 6 --
arch/arm/mach-s3c64xx/s3c6410.c | 7 ---
drivers/clk/samsung/Makefile | 2 --
15 files changed, 33 insertions(+), 42 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 64d3ff9..5d29ae9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -717,6 +717,7 @@ config ARCH_S3C64XX
select ARM_VIC
select CLKDEV_LOOKUP
select CLKSRC_MMIO
+ select COMMON_CLK
select CPU_V6
select GENERIC_CLOCKEVENTS
select HAVE_CLK
@@ -728,7 +729,6 @@ config ARCH_S3C64XX
select PLAT_SAMSUNG
select S3C_DEV_NAND
select S3C_GPIO_TRACK
- select SAMSUNG_CLKSRC
select SAMSUNG_GPIOLIB_4BIT
select SAMSUNG_WDT_RESET
select USB_ARCH_HAS_OHCI
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 31d0c91..645a8fe 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -12,7 +12,7 @@ obj- :=
# Core
-obj-y += common.o clock.o
+obj-y += common.o
# Core support
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 0b33683..bf00e60 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -37,7 +38,6 @@
#include
#include
-#include
#include
#include
#include
@@ -49,6 +49,19 @@
#include "common.h"
+/* External clock frequency */
+static unsigned long xtal_f = 1200, xusbxti_f = 4800;
+
+void __init s3c64xx_set_xtal_freq(unsigned long freq)
+{
+ xtal_f = freq;
+}
+
+void __init s3c64xx_set_xusbxti_freq(unsigned long freq)
+{
+ xusbxti_f = freq;
+}
+
/* uart registration process */
static void __init s3c64xx_init_uarts(struct s3c2410_uartcfg *cfg, int no)
@@ -66,7 +79,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = S3C6400_CPU_ID,
.idmask = S3C64XX_CPU_MASK,
.map_io = s3c6400_map_io,
- .init_clocks= s3c6400_init_clocks,
.init_uarts = s3c64xx_init_uarts,
.init = s3c6400_init,
.name = name_s3c6400,
@@ -74,7 +86,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = S3C6410_CPU_ID,
.idmask = S3C64XX_CPU_MASK,
.map_io = s3c6410_map_io,
- .init_clocks= s3c6410_init_clocks,
.init_uarts = s3c64xx_init_uarts,
.init = s3c6410_init,
.name = name_s3c6410,
@@ -212,8 +223,10 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32
vic1_valid)
{
/*
* FIXME: there is no better place to put this at the moment
-* (samsung_wdt_reset_init needs clocks)
+* (s3c64xx_clk_init needs ioremap and must happen before init_time
+* samsung_wdt_reset_init needs clocks)
*/
+ s3c64xx_clk_init(NULL, xtal_f, xusbxti_f, soc_is_s3c6400(), S3C_VA_SYS);
samsung_wdt_reset_init(S3C_VA_WATCHDOG);
printk(KERN_DEBUG "%s: initialising interrupts\n", __func__);
diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h
index 6cfc99b..76ce4fe 100644
--- a/arch/arm/mach-s3c64xx/common.h
+++ b/arch/arm/mach-s3c64xx/common.h
@@ -20,18 +20,19 @@
void s3c64xx_init_irq(u32 vic0, u32 vic1);
void s3c64xx_init_io(struct map_desc *mach_desc, int size);
-void s3c64xx_register_clocks(unsigned long xtal, unsigned armclk_limit);
-void s3c64xx_setup_clocks(void);
-
void s3c64xx_restart(char mode, const char *cmd);
void s3c64xx_init_late(void);
+void s3c64xx_clk_init(struct device_node *np, unsigned long xtal_f,
+ unsigned long xusbxti_f, bool is_s3c6400, void __iomem *reg_base);
+void s3c64xx_set_xtal_freq(unsigned long freq);
+void s3c64xx_set_xusbxti_freq(unsigned long freq);
+
#ifdef CONFIG_CPU_S3C6400
extern int s3c6400_init(void);
extern void s3c6400_init_irq(void);
extern void s3c6400_map_io
[PATCH 5/7] usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare
This patch modifies the ohci-s3c2410 driver to prepare and unprepare
clocks in addition to enabling and disabling, since it is required
by common clock framework.
Signed-off-by: Tomasz Figa
---
drivers/usb/host/ohci-s3c2410.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index e125770..db096bf 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -47,10 +47,10 @@ static void s3c2410_start_hc(struct platform_device *dev,
struct usb_hcd *hcd)
dev_dbg(&dev->dev, "s3c2410_start_hc:\n");
- clk_enable(usb_clk);
+ clk_prepare_enable(usb_clk);
mdelay(2); /* let the bus clock stabilise */
- clk_enable(clk);
+ clk_prepare_enable(clk);
if (info != NULL) {
info->hcd = hcd;
@@ -75,8 +75,8 @@ static void s3c2410_stop_hc(struct platform_device *dev)
(info->enable_oc)(info, 0);
}
- clk_disable(clk);
- clk_disable(usb_clk);
+ clk_disable_unprepare(clk);
+ clk_disable_unprepare(usb_clk);
}
/* ohci_s3c2410_hub_status_data
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] clk: samsung: Add clock driver for S3C64xx SoCs
This patch adds new, Common Clock Framework-based clock driver for Samsung
S3C64xx SoCs. The driver is just added, without actually letting the
platforms use it yet, since this requires more intermediate steps.
Signed-off-by: Tomasz Figa
---
.../bindings/clock/samsung,s3c64xx-clock.txt | 48 ++
drivers/clk/samsung/Makefile | 3 +
drivers/clk/samsung/clk-s3c64xx.c | 503 +
include/dt-bindings/clock/samsung,s3c64xx-clock.h | 144 ++
4 files changed, 698 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
create mode 100644 drivers/clk/samsung/clk-s3c64xx.c
create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
new file mode 100644
index 000..278ab6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
@@ -0,0 +1,48 @@
+* Samsung S3C64xx Clock Controller
+
+The S3C64xx clock controller generates and supplies clock to various
controllers
+within the SoC. The clock binding described here is applicable to all SoCs in
+the S3C64xx family.
+
+Required Properties:
+
+- comptible: should be one of the following.
+ - "samsung,s3c6400-clock" - controller compatible with S3C6400 SoC.
+ - "samsung,s3c6410-clock" - controller compatible with S3C6410 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular S3C64xx SoC and this is specified where applicable.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/samsung,s3c64xx-clock.h header and can be used in device
+tree sources.
+
+Example: Clock controller node:
+
+ clocks: clock-controller@7e00f000 {
+ compatible = "samsung,s3c6410-clock";
+ reg = <0x7e00f000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller (refer to the standard clock bindings for information about
+ "clocks" and "clock-names" properties):
+
+ uart0: serial@7f005000 {
+ compatible = "samsung,s3c6400-uart";
+ reg = <0x7f005000 0x100>;
+ interrupt-parent = <&vic1>;
+ interrupts = <5>;
+ clock-names = "uart", "clk_uart_baud2",
+ "clk_uart_baud3";
+ clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
+ <&clocks SCLK_UART>;
+ status = "disabled";
+ };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index b7c232e..c023474 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -6,3 +6,6 @@ obj-$(CONFIG_COMMON_CLK)+= clk.o clk-pll.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
+ifdef CONFIG_COMMON_CLK
+obj-$(CONFIG_ARCH_S3C64XX) += clk-s3c64xx.o
+endif
diff --git a/drivers/clk/samsung/clk-s3c64xx.c
b/drivers/clk/samsung/clk-s3c64xx.c
new file mode 100644
index 000..253a972
--- /dev/null
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -0,0 +1,503 @@
+/*
+ * Copyright (c) 2013 Tomasz Figa
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for all S3C64xx SoCs.
+*/
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "clk.h"
+#include "clk-pll.h"
+
+/* S3C64xx clock controller register offsets. */
+#define APLL_LOCK 0x000
+#define MPLL_LOCK 0x004
+#define EPLL_LOCK 0x008
+#define APLL_CON 0x00c
+#define MPLL_CON 0x010
+#define EPLL_CON0 0x014
+#define EPLL_CON1 0x018
+#define CLK_SRC0x01c
+#define CLK_DIV0 0x020
+#define CLK_DIV1 0x024
+#define CLK_DIV2 0x028
+#define HCLK_GATE 0x030
+#define PCLK_GATE 0x034
+#define SCLK_GATE 0x038
+#define MEM0_GATE 0x03c
+#define CLK_SRC2 0x10c
+#define OTHERS 0x900
+
+/* Special bitfield
[PATCH 3/7] ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros
This patch adds soc_is_s3c6400() and soc_is_s3c6410() macros that allow to distinguish between specific SoCs from s3c64xx series that is needed to handle differences between them. Signed-off-by: Tomasz Figa --- arch/arm/plat-samsung/include/plat/cpu.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/plat-samsung/include/plat/cpu.h b/arch/arm/plat-samsung/include/plat/cpu.h index 989fefe..8e55196 100644 --- a/arch/arm/plat-samsung/include/plat/cpu.h +++ b/arch/arm/plat-samsung/include/plat/cpu.h @@ -85,8 +85,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK) #endif #if defined(CONFIG_CPU_S3C6400) || defined(CONFIG_CPU_S3C6410) +# define soc_is_s3c6400() is_samsung_s3c6400() +# define soc_is_s3c6410() is_samsung_s3c6410() # define soc_is_s3c64xx() (is_samsung_s3c6400() || is_samsung_s3c6410()) #else +# define soc_is_s3c6400() 0 +# define soc_is_s3c6410() 0 # define soc_is_s3c64xx() 0 #endif -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] ARM: s3c64xx: Remove old clock management code
This patch removes old clock management code of S3C64xx, since the platform has been already moved to the new clock driver using Common Clock Framework. Signed-off-by: Tomasz Figa --- arch/arm/mach-s3c64xx/clock.c | 1007 --- arch/arm/mach-s3c64xx/common.h |2 - arch/arm/mach-s3c64xx/include/mach/regs-clock.h | 132 +-- arch/arm/mach-s3c64xx/pm.c | 21 - 4 files changed, 4 insertions(+), 1158 deletions(-) delete mode 100644 arch/arm/mach-s3c64xx/clock.c diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c deleted file mode 100644 index c1bcc4a..000 diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h index 76ce4fe..0184abf 100644 --- a/arch/arm/mach-s3c64xx/common.h +++ b/arch/arm/mach-s3c64xx/common.h @@ -35,7 +35,6 @@ extern void s3c6400_init_irq(void); extern void s3c6400_map_io(void); #else -#define s3c6400_init_clocks NULL #define s3c6400_map_io NULL #define s3c6400_init NULL #endif @@ -47,7 +46,6 @@ extern void s3c6410_init_irq(void); extern void s3c6410_map_io(void); #else -#define s3c6410_init_clocks NULL #define s3c6410_map_io NULL #define s3c6410_init NULL #endif diff --git a/arch/arm/mach-s3c64xx/include/mach/regs-clock.h b/arch/arm/mach-s3c64xx/include/mach/regs-clock.h index 05332b9..4f44aac 100644 --- a/arch/arm/mach-s3c64xx/include/mach/regs-clock.h +++ b/arch/arm/mach-s3c64xx/include/mach/regs-clock.h @@ -15,145 +15,21 @@ #ifndef __PLAT_REGS_CLOCK_H #define __PLAT_REGS_CLOCK_H __FILE__ +/* + * FIXME: Remove remaining definitions + */ + #define S3C_CLKREG(x) (S3C_VA_SYS + (x)) -#define S3C_APLL_LOCK S3C_CLKREG(0x00) -#define S3C_MPLL_LOCK S3C_CLKREG(0x04) -#define S3C_EPLL_LOCK S3C_CLKREG(0x08) -#define S3C_APLL_CON S3C_CLKREG(0x0C) -#define S3C_MPLL_CON S3C_CLKREG(0x10) -#define S3C_EPLL_CON0 S3C_CLKREG(0x14) -#define S3C_EPLL_CON1 S3C_CLKREG(0x18) -#define S3C_CLK_SRCS3C_CLKREG(0x1C) -#define S3C_CLK_DIV0 S3C_CLKREG(0x20) -#define S3C_CLK_DIV1 S3C_CLKREG(0x24) -#define S3C_CLK_DIV2 S3C_CLKREG(0x28) -#define S3C_CLK_OUTS3C_CLKREG(0x2C) -#define S3C_HCLK_GATE S3C_CLKREG(0x30) #define S3C_PCLK_GATE S3C_CLKREG(0x34) -#define S3C_SCLK_GATE S3C_CLKREG(0x38) -#define S3C_MEM0_GATE S3C_CLKREG(0x3C) #define S3C6410_CLK_SRC2 S3C_CLKREG(0x10C) #define S3C_MEM_SYS_CFGS3C_CLKREG(0x120) -/* CLKDIV0 */ -#define S3C6400_CLKDIV0_PCLK_MASK (0xf << 12) -#define S3C6400_CLKDIV0_PCLK_SHIFT (12) -#define S3C6400_CLKDIV0_HCLK2_MASK (0x7 << 9) -#define S3C6400_CLKDIV0_HCLK2_SHIFT(9) -#define S3C6400_CLKDIV0_HCLK_MASK (0x1 << 8) -#define S3C6400_CLKDIV0_HCLK_SHIFT (8) -#define S3C6400_CLKDIV0_MPLL_MASK (0x1 << 4) -#define S3C6400_CLKDIV0_MPLL_SHIFT (4) - -#define S3C6400_CLKDIV0_ARM_MASK (0x7 << 0) -#define S3C6410_CLKDIV0_ARM_MASK (0xf << 0) -#define S3C6400_CLKDIV0_ARM_SHIFT (0) - -/* HCLK GATE Registers */ -#define S3C_CLKCON_HCLK_3DSE (1<<31) -#define S3C_CLKCON_HCLK_UHOST (1<<29) -#define S3C_CLKCON_HCLK_SECUR (1<<28) -#define S3C_CLKCON_HCLK_SDMA1 (1<<27) -#define S3C_CLKCON_HCLK_SDMA0 (1<<26) -#define S3C_CLKCON_HCLK_IROM (1<<25) -#define S3C_CLKCON_HCLK_DDR1 (1<<24) -#define S3C_CLKCON_HCLK_DDR0 (1<<23) -#define S3C_CLKCON_HCLK_MEM1 (1<<22) -#define S3C_CLKCON_HCLK_MEM0 (1<<21) -#define S3C_CLKCON_HCLK_USB(1<<20) -#define S3C_CLKCON_HCLK_HSMMC2 (1<<19) -#define S3C_CLKCON_HCLK_HSMMC1 (1<<18) -#define S3C_CLKCON_HCLK_HSMMC0 (1<<17) -#define S3C_CLKCON_HCLK_MDP(1<<16) -#define S3C_CLKCON_HCLK_DHOST (1<<15) -#define S3C_CLKCON_HCLK_IHOST (1<<14) -#define S3C_CLKCON_HCLK_DMA1 (1<<13) -#define S3C_CLKCON_HCLK_DMA0 (1<<12) -#define S3C_CLKCON_HCLK_JPEG (1<<11) -#define S3C_CLKCON_HCLK_CAMIF (1<<10) -#define S3C_CLKCON_HCLK_SCALER (1<<9) -#define S3C_CLKCON_HCLK_2D (1<<8) -#define S3C_CLKCON_HCLK_TV (1<<7) -#define S3C_CLKCON_HCLK_POST0 (1<<5) -#define S3C_CLKCON_HCLK_ROT(1<<4) -#define S3C_CLKCON_HCLK_LCD(1<<3) -#define S3C_CLKCON_HCLK_TZIC (1<<2) -#define S3C_CLKCON_HCLK_INTC (1<<1) -#define S3C_CLKCON_HCLK_MFC(1<<0) - /* PCLK GATE Registers */ -#define S3C6410_CLKCON_PCLK_I2C1 (1<<27) -#define S3C6410_CLKCON_PCLK_IIS2 (1<<26) -#define S3C_CLKCON_PCLK_SKEY (1<<24) -#define S3C_CLKCON_PCLK_CHIPID (1<<23) -#define S3C_CLKCON_PCLK_SPI1 (1<<22) -#define S3C_CLKCON_PCLK_SPI0 (1<<21) -#define S3C_CLKCON_PCLK_HSIRX (1<<20) -#define S3C_CLKCON_PCLK_HSI
[PATCH 4/7] ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare
This patch modifies s3c64xx DMA driver to prepare and unprepare clocks in addition to enableind and disabling, since it is required by common clock framework. Signed-off-by: Tomasz Figa --- arch/arm/mach-s3c64xx/dma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-s3c64xx/dma.c b/arch/arm/mach-s3c64xx/dma.c index 759846c..c511dfa 100644 --- a/arch/arm/mach-s3c64xx/dma.c +++ b/arch/arm/mach-s3c64xx/dma.c @@ -677,7 +677,7 @@ static int s3c64xx_dma_init1(int chno, enum dma_ch chbase, goto err_map; } - clk_enable(dmac->clk); + clk_prepare_enable(dmac->clk); dmac->regs = regs; dmac->chanbase = chbase; @@ -711,7 +711,7 @@ static int s3c64xx_dma_init1(int chno, enum dma_ch chbase, return 0; err_clk: - clk_disable(dmac->clk); + clk_disable_unprepare(dmac->clk); clk_put(dmac->clk); err_map: iounmap(regs); -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] clk: samsung: Add clock driver for S3C64xx SoCs
Hi Mike,
On Tuesday 11 of June 2013 19:54:51 Mike Turquette wrote:
> Quoting Tomasz Figa (2013-06-05 16:57:26)
>
> > This patch adds new, Common Clock Framework-based clock driver for
> > Samsung S3C64xx SoCs. The driver is just added, without actually
> > letting the platforms use it yet, since this requires more
> > intermediate steps.
> It seems like there is an awful lot of clock data here that exists
> alongside the stuff in DT. Is this how you plan to keep things going
> forward or is this conversion just an intermediate step?
Current S3C64xx support contains a lot of boards, for which I don't see
any chance for DT conversion in any time soon, so the driver must cover
both DT and non-DT cases. (Not even saying that DT support for S3C64xx is
not yet submitted, as I want to get all the dependencies merged, or at
least acked, first.)
Also, personally, I don't see anything wrong with having those clocks
defined in the driver. The binding specifies the exact mapping between
clock IDs inside the clock provider and hardware clocks and not all clocks
need to be exported (most of muxes and divs don't need to), so I find it
more reasonable to define them in the driver instead.
Another thing is that it's unlikely for any new SoC from S3C64xx series to
show up, so basically the clock list is fixed.
Best regards,
Tomasz
> Regards,
> Mike
>
> > Signed-off-by: Tomasz Figa
> > ---
> >
> > .../bindings/clock/samsung,s3c64xx-clock.txt | 48 ++
> > drivers/clk/samsung/Makefile | 3 +
> > drivers/clk/samsung/clk-s3c64xx.c | 503
> > +
> > include/dt-bindings/clock/samsung,s3c64xx-clock.h | 144 ++ 4
> > files changed, 698 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
> > create mode 100644 drivers/clk/samsung/clk-s3c64xx.c
> > create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
> > b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
> > new file mode 100644
> > index 000..278ab6e
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
> > @@ -0,0 +1,48 @@
> > +* Samsung S3C64xx Clock Controller
> > +
> > +The S3C64xx clock controller generates and supplies clock to various
> > controllers +within the SoC. The clock binding described here is
> > applicable to all SoCs in +the S3C64xx family.
> > +
> > +Required Properties:
> > +
> > +- comptible: should be one of the following.
> > + - "samsung,s3c6400-clock" - controller compatible with S3C6400 SoC.
> > + - "samsung,s3c6410-clock" - controller compatible with S3C6410 SoC.
> > +
> > +- reg: physical base address of the controller and length of memory
> > mapped + region.
> > +
> > +- #clock-cells: should be 1.
> > +
> > +Each clock is assigned an identifier and client nodes can use this
> > identifier +to specify the clock which they consume. Some of the
> > clocks are available only +on a particular S3C64xx SoC and this is
> > specified where applicable. +
> > +All available clocks are defined as preprocessor macros in
> > +dt-bindings/clock/samsung,s3c64xx-clock.h header and can be used in
> > device +tree sources.
> > +
> > +Example: Clock controller node:
> > +
> > + clocks: clock-controller@7e00f000 {
> > + compatible = "samsung,s3c6410-clock";
> > + reg = <0x7e00f000 0x1000>;
> > + #clock-cells = <1>;
> > + };
> > +
> > +Example: UART controller node that consumes the clock generated by
> > the clock + controller (refer to the standard clock bindings for
> > information about + "clocks" and "clock-names" properties):
> > +
> > + uart0: serial@7f005000 {
> > + compatible = "samsung,s3c6400-uart";
> > + reg = <0x7f005000 0x100>;
> > + interrupt-parent = <&vic1>;
> > + interrupts = <5>;
> > + clock-names = "uart", "clk_uart_baud2",
> > + "clk_uart_baud3";
> > + clocks = <&clocks PCLK_UART0>, <&clocks
> > PCLK_UART0>, + <&clocks
> > S
Re: [PATCH V2 05/10] USB: OHCI: Properly handle ohci-exynos suspend
Hi Manjunath,
On Thursday 13 of June 2013 14:46:24 Manjunath Goudar wrote:
> Suspend scenario in case of ohci-exynos glue was not
> properly handled as it was not suspending generic part
> of ohci controller.Calling explicitly the ohci_suspend()
> routine in exynos_ohci_suspend() will ensure proper
> handling of suspend scenario.
>
> V2:
> -Incase ohci_suspend() fails, return right away without
> executing further.
>
> Signed-off-by: Manjunath Goudar
> Cc: Arnd Bergmann
> Cc: Alan Stern
> Cc: Greg KH
> Cc: linux-usb@vger.kernel.org
> ---
> drivers/usb/host/ohci-exynos.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/usb/host/ohci-exynos.c
> b/drivers/usb/host/ohci-exynos.c index 6ff830c..8fecb6a 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -203,9 +203,17 @@ static int exynos_ohci_suspend(struct device *dev)
> struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
> struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> struct platform_device *pdev = to_platform_device(dev);
> + bool do_wakeup = device_may_wakeup(dev);
> unsigned long flags;
> int rc = 0;
>
> + rc = ohci_suspend(hcd, do_wakeup);
> + if (rc == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
> + ohci_resume(hcd, false);
> + rc = -EBUSY;
> + }
I'm not into USB host subsystem, so I might just ask a stupid question.
Can't we make ohci_suspend check this for us, so the drivers would just
check for error code? It seems like in all your patches this part of code
is duplicated, looking as a good candidate to be generic.
Best regards,
Tomasz
> + if (rc)
> + return rc;
> /*
>* Root hub was already suspended. Disable irq emission and
>* mark HW unaccessible, bail out if RH has been resumed. Use
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Common Clock Framework support for Samsung S3C64xx
On Wednesday 19 of June 2013 23:17:06 Kukjin Kim wrote: > On 06/06/13 08:57, Tomasz Figa wrote: > > This series is an attempt to move clock support on Samsung S3C64xx SoCs > > to Common Clock Framework. > > Looks good :) Thanks. > > First, support for PLL types present on S3C64xx SoCs is added to > > Samsung > > Common Clock Framework driver. Then the main clock driver for mentioned > > SoCs is introduced. Further patches contain fixes for drivers to make > > them compliant with CCF semantics, migration of platform code to use > > the new clock driver and removal of old clock management code. > > > > Depends on: > > - [PATCH 0/6] Samsung watchdog support clean-up > > > > http://thread.gmane.org/gmane.linux.kernel.samsung-soc/18736/focus= > > 18989 > > > > - [PATCH 00/15] Final Samsung PWM support cleanup > > > > http://www.spinics.net/lists/arm-kernel/msg248725.html > > BTW, Tomasz, so how was going on above PWM patches? > I have them ready now, but the PWM maintainer has some objections, which will hopefully be resolved soon. Best regards, Tomasz > > On S3C6410-based Tiny6410 board (Mini6410-compatible): > > > > Tested-by: Tomasz Figa > > > > Tomasz Figa (7): > >clk: samsung: pll: Add support for PLL6552 and PLL6553 > >clk: samsung: Add clock driver for S3C64xx SoCs > >ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros > >ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare > >usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare > >ARM: s3c64xx: Migrate clock handling to Common Clock Framework > >ARM: s3c64xx: Remove old clock management code > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-samsung-soc" in the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] usb: gadget: s3c-hsotg: Allow driver instantiation using device tree
This patch adds OF match table to the driver to allow instantiating it
using device tree.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
.../devicetree/bindings/usb/samsung-hsotg.txt | 40 ++
drivers/usb/gadget/s3c-hsotg.c | 10 ++
2 files changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/samsung-hsotg.txt
diff --git a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
new file mode 100644
index 000..b83d428
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
@@ -0,0 +1,40 @@
+Samsung High Speed USB OTG controller
+-
+
+The Samsung HSOTG IP can be found on Samsung SoCs, from S3C6400 onwards.
+It gives functionality of OTG-compliant USB 2.0 host and device with
+support for USB 2.0 high-speed (480Mbps) and full-speed (12 Mbps)
+operation.
+
+Currently only device mode is supported.
+
+Binding details
+-
+
+Required properties:
+- compatible: "samsung,s3c6400-hsotg" should be used for all currently
+supported SoC,
+- interrupt-parent: phandle for the interrupt controller to which the
+interrupt signal of the HSOTG block is routed,
+- interrupts: specifier of interrupt signal of interrupt controller,
+according to bindings of interrupt controller,
+- clocks: contains an array of clock specifiers:
+- first entry: OTG clock
+- clock-names: contains array of clock names:
+- first entry: must be "otg"
+- vusb_d-supply: phandle to voltage regulator of digital section,
+- vusb_a-supply: phandle to voltage regulator of analog section.
+
+Example
+-
+
+ hsotg@1248 {
+ compatible = "samsung,s3c6400-hsotg";
+ reg = <0x1248 0x2>;
+ interrupts = <0 71 0>;
+ clocks = <&clock 305>;
+ clock-names = "otg";
+ vusb_d-supply = <&vusb_reg>;
+ vusb_a-supply = <&vusbdac_reg>;
+ };
+
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index af22f24..616ed51 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -3648,10 +3649,19 @@ static int s3c_hsotg_remove(struct platform_device
*pdev)
#define s3c_hsotg_resume NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id s3c_hsotg_of_ids[] = {
+ { .compatible = "samsung,s3c6400-hsotg", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, s3c_hsotg_of_ids);
+#endif
+
static struct platform_driver s3c_hsotg_driver = {
.driver = {
.name = "s3c-hsotg",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(s3c_hsotg_of_ids),
},
.probe = s3c_hsotg_probe,
.remove = s3c_hsotg_remove,
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: exynos4: Add nodes for USB PHY block
This patch adds device tree nodes for USB OTG PHYs of Exynos4210 and
Exynos4x12 SoCs.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4210.dtsi | 15 +++
arch/arm/boot/dts/exynos4x12.dtsi | 15 +++
2 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 54710de..3c71ea5 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -114,6 +114,21 @@
interrupts = <2 4>;
};
+ usbphy@125B {
+ compatible = "samsung,exynos4210-usb2phy";
+ reg = <0x125B 0x100>;
+ clocks = <&clock 305>;
+ clock-names = "otg";
+ status = "disabled";
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ usbphy-sys {
+ reg = <0x10020704 0x8>;
+ };
+ };
+
g2d@1280 {
compatible = "samsung,s5pv210-g2d";
reg = <0x1280 0x1000>;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index e3380a7..267ed95 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -79,4 +79,19 @@
interrupts = <0 89 0>;
status = "disabled";
};
+
+ usbphy@125B {
+ compatible = "samsung,exynos4x12-usb2phy";
+ reg = <0x125B 0x100>;
+ clocks = <&clock 305>;
+ clock-names = "otg";
+ status = "disabled";
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ usbphy-sys {
+ reg = <0x10020704 0x8>;
+ };
+ };
};
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Add support for Samsung HSOTG on DT-enabled platforms
This series enables platforms booting with Device Tree to use the Samsung HSOTG IP. Since USB PHY support has been already added, it's just a matter of adding an OF match table to the driver and respective device tree nodes to dts files. [On Samsung Trats board based on Exynos 4210] Tested-by: Tomasz Figa Tomasz Figa (4): usb: gadget: s3c-hsotg: Allow driver instantiation using device tree ARM: dts: exynos4: Add node for hsotg ARM: dts: exynos4: Add nodes for USB PHY block ARM: dts: exynos4210-trats: Enable USB gadget functionality .../devicetree/bindings/usb/samsung-hsotg.txt | 40 ++ arch/arm/boot/dts/exynos4.dtsi | 9 + arch/arm/boot/dts/exynos4210-trats.dts | 10 ++ arch/arm/boot/dts/exynos4210.dtsi | 15 arch/arm/boot/dts/exynos4x12.dtsi | 15 drivers/usb/gadget/s3c-hsotg.c | 10 ++ 6 files changed, 99 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/samsung-hsotg.txt -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: exynos4210-trats: Enable USB gadget functionality
This patch adds device tree nodes necessary to enable USB gadget
functionality on Exynos4210-based Trats board.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4210-trats.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 9a14484..d2ce1cf 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -39,6 +39,12 @@
enable-active-high;
};
+ hsotg@1248 {
+ vusb_d-supply = <&vusb_reg>;
+ vusb_a-supply = <&vusbdac_reg>;
+ status = "okay";
+ };
+
sdhci_emmc: sdhci@1251 {
bus-width = <8>;
non-removable;
@@ -48,6 +54,10 @@
status = "okay";
};
+ usbphy@125B {
+ status = "okay";
+ };
+
serial@1380 {
status = "okay";
};
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: exynos4: Add node for hsotg
This patch adds device tree node for USB HSOTG controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 359694c..d53b9da 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -119,6 +119,15 @@
status = "disabled";
};
+ hsotg@1248 {
+ compatible = "samsung,s3c6400-hsotg";
+ reg = <0x1248 0x2>;
+ interrupts = <0 71 0>;
+ clocks = <&clock 305>;
+ clock-names = "otg";
+ status = "disabled";
+ };
+
sdhci@1251 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x1251 0x100>;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: gadget: s3c-hsotg: Allow driver instantiation using device tree
On Tuesday 25 of June 2013 23:46:32 Felipe Balbi wrote: > On Tue, Jun 25, 2013 at 05:38:23PM +0200, Tomasz Figa wrote: > > This patch adds OF match table to the driver to allow instantiating it > > using device tree. > > > > Signed-off-by: Tomasz Figa > > Signed-off-by: Kyungmin Park > > when will this driver get merged into dwc2 ? What's dwc2? I can only see dwc3 in mainline kernel tree and it doesn't seem to be compatible with s3c-hsotg. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: gadget: s3c-hsotg: Allow driver instantiation using device tree
On Wednesday 26 of June 2013 00:00:44 Felipe Balbi wrote: > On Tue, Jun 25, 2013 at 10:57:06PM +0200, Tomasz Figa wrote: > > On Tuesday 25 of June 2013 23:46:32 Felipe Balbi wrote: > > > On Tue, Jun 25, 2013 at 05:38:23PM +0200, Tomasz Figa wrote: > > > > This patch adds OF match table to the driver to allow > > > > instantiating it > > > > using device tree. > > > > > > > > Signed-off-by: Tomasz Figa > > > > Signed-off-by: Kyungmin Park > > > > > > when will this driver get merged into dwc2 ? > > > > What's dwc2? I can only see dwc3 in mainline kernel tree and it > > doesn't > > seem to be compatible with s3c-hsotg. > > drivers/staging/dwc2/ Oh right, staging, I forgot to check there. > That's the same IP you're using Paul Zimmerman (now in Cc) is working > towards getting that out of staging. It currently has only host mode, so > plugging your code in there shouldn't be too difficult. > > OTOH, it might be better to make your code a device-only version of dwc2 > (drivers/usb/dwc2) and have Paul move his host side to that instead. Hmm, I believe Lukasz Majewski and Marek Szyprowski (both on CC) should be able to say something more on this topic as I'm not really into USB drivers and just doing Device Tree enablement here. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree
Hi, On Friday 12 of July 2013 09:48:54 Jingoo Han wrote: > On Friday, July 12, 2013 6:46 AM, Julius Werner wrote: > > Hi Jingoo, > > > > Yeah, I followed that discussion back then, but it seems to have > > stalled a little (at least the HSIC patches haven't been picked up in > > any kernel.org repo yet to my knowledge). > > > > The problem is that I think these approaches cannot work reliably. I > > agree that it would be nice to control the HSIC device from its own > > driver, and have spent quite some time playing around with the > > usb/misc/usb3503.c driver to try to make this work... but there's a > > timing dependency here that you just can't model correctly with > > independent drivers. > > > > If the HSIC device is already active during boot (e.g. because it was > > used by firmware), there's always a chance that the USB stack will > > come up before the driver that resets it does. The device will be > > enumerated as normal, and when the other driver later pulls the reset > > signal the USB stack will not notice because there is no real > > disconnect detection on HSIC. Only when you eventually try to send > > another transfer to the device will you start to get timeouts, and the > > newly reset device will not be able to reenumerate because the host > > never asks it to. > > > > I really don't see how you could solve this without putting some kind > > of synchronization mechanism in the USB drivers. So this leaves > > ehci-s5p and phy-samsung-usb2 as the only possible places, and I chose > > the latter since all the host-side HSIC initialization is also there > > already. I think if you think of it as "reset whatever is on the other > > side of this PHY", it's okay to put it as an optional feature into the > > PHY driver. > > CC'ed Tomasz Figa, Dongjin Kim, Yulgon Kim > > > Hi Tomasz, Dongjin, > > Julius Werner wants to put 'SMSC 3503 hub reset on Arndale board' > to 'phy-samsung-usb*.c' files, because there is a timing dependency > above mentioned. > The following is the original patch sent by Julius Werner two day ago. > (http://www.spinics.net/lists/linux-samsung-soc/msg20250.html) Well, I think this is simply broken. Following are the reasons why I think so: a) you can use the smsc3503 chip on any USB/HSIC controller and with any USB/HSIC PHY, so you would have to add such reset GPIO to _every_ PHY or controller driver, b) you might want to use other USB/HSIC hubs like this one that requires some initialization sequence, other than just toggling a GPIO, so you would have to add cases for all of those hubs or other chips in _every_ PHY or controller driver. > Previously, Olof mentioned that 'drivers/platform/arm/' would be used. > (http://patches.linaro.org/16856/) > > Also, another way was mentioned by Fabio Estevam, using > 'drivers/reset/gpio-reset.c' which is not merged yet. > (http://permalink.gmane.org/gmane.linux.drivers.devicetree/36830) > > I think that 'phy-samsung-usb*.c' files are not a good place. > However, Julius Werner's comment looks reasonable enough. I can see this problem almost equivalent to the problem with on-board WLAN adapters connected using SDIO. Those adapters require some kind of power on sequence before they can be enumerated using standard MMC/SDIO mechanisms and so does this USB/HSIC hub. So basically this is a thing that we should consider on a more generic level, not just for this particular single chip. CCing some extra people to increase chance of getting more opinions on this. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> > On Sat, 20 Jul 2013, Greg KH wrote:
> > > > >>That should be passed using platform data.
> > > > >
> > > > >Ick, don't pass strings around, pass pointers. If you have
> > > > >platform
> > > > >data you can get to, then put the pointer there, don't use a
> > > > >"name".
> > > >
> > > > I don't think I understood you here :-s We wont have phy pointer
> > > > when we create the device for the controller no?(it'll be done in
> > > > board file). Probably I'm missing something.
> > >
> > > Why will you not have that pointer? You can't rely on the "name" as
> > > the device id will not match up, so you should be able to rely on
> > > the pointer being in the structure that the board sets up, right?
> > >
> > > Don't use names, especially as ids can, and will, change, that is
> > > going
> > > to cause big problems. Use pointers, this is C, we are supposed to
> > > be
> > > doing that :)
> >
> > Kishon, I think what Greg means is this: The name you are using must
> > be stored somewhere in a data structure constructed by the board file,
> > right? Or at least, associated with some data structure somehow.
> > Otherwise the platform code wouldn't know which PHY hardware
> > corresponded to a particular name.
> >
> > Greg's suggestion is that you store the address of that data structure
> > in the platform data instead of storing the name string. Have the
> > consumer pass the data structure's address when it calls phy_create,
> > instead of passing the name. Then you don't have to worry about two
> > PHYs accidentally ending up with the same name or any other similar
> > problems.
>
> Close, but the issue is that whatever returns from phy_create() should
> then be used, no need to call any "find" functions, as you can just use
> the pointer that phy_create() returns. Much like all other class api
> functions in the kernel work.
I think there is a confusion here about who registers the PHYs.
All platform code does is registering a platform/i2c/whatever device,
which causes a driver (located in drivers/phy/) to be instantiated. Such
drivers call phy_create(), usually in their probe() callbacks, so
platform_code has no way (and should have no way, for the sake of
layering) to get what phy_create() returns.
IMHO we need a lookup method for PHYs, just like for clocks, regulators,
PWMs or even i2c busses because there are complex cases when passing just
a name using platform data will not work. I would second what Stephen said
[1] and define a structure doing things in a DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
/* etc... */
};
static void my_machine_init(void)
{
/* ... */
phy_register_lookup(my_phy_lookup, ARRAY_SIZE(my_phy_lookup));
/* ... */
}
/* Notice nothing stuffed in platform data. */
[provider code - samsung-usbphy driver]
static int samsung_usbphy_probe(...)
{
/* ... */
for (i = 0; i < PHY_COUNT; ++i) {
usbphy->phy[i].name = "phy";
usbphy->phy[i].id = i;
/* ... */
ret = phy_create(&usbphy->phy);
/* err handling */
}
/* ... */
}
[consumer code - s3c-hsotg driver]
static int s3c_hsotg_probe(...)
{
/* ... */
phy = phy_get(&pdev->dev, "otg");
/* ... */
}
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
> Hi,
>
> On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
> > Hi,
> >
> > On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
> >> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> >>> On Sat, 20 Jul 2013, Greg KH wrote:
> >>>>>>> That should be passed using platform data.
> >>>>>>
> >>>>>> Ick, don't pass strings around, pass pointers. If you have
> >>>>>> platform
> >>>>>> data you can get to, then put the pointer there, don't use a
> >>>>>> "name".
> >>>>>
> >>>>> I don't think I understood you here :-s We wont have phy pointer
> >>>>> when we create the device for the controller no?(it'll be done in
> >>>>> board file). Probably I'm missing something.
> >>>>
> >>>> Why will you not have that pointer? You can't rely on the "name"
> >>>> as
> >>>> the device id will not match up, so you should be able to rely on
> >>>> the pointer being in the structure that the board sets up, right?
> >>>>
> >>>> Don't use names, especially as ids can, and will, change, that is
> >>>> going
> >>>> to cause big problems. Use pointers, this is C, we are supposed to
> >>>> be
> >>>> doing that :)
> >>>
> >>> Kishon, I think what Greg means is this: The name you are using
> >>> must
> >>> be stored somewhere in a data structure constructed by the board
> >>> file,
> >>> right? Or at least, associated with some data structure somehow.
> >>> Otherwise the platform code wouldn't know which PHY hardware
> >>> corresponded to a particular name.
> >>>
> >>> Greg's suggestion is that you store the address of that data
> >>> structure
> >>> in the platform data instead of storing the name string. Have the
> >>> consumer pass the data structure's address when it calls phy_create,
> >>> instead of passing the name. Then you don't have to worry about two
> >>> PHYs accidentally ending up with the same name or any other similar
> >>> problems.
> >>
> >> Close, but the issue is that whatever returns from phy_create()
> >> should
> >> then be used, no need to call any "find" functions, as you can just
> >> use
> >> the pointer that phy_create() returns. Much like all other class api
> >> functions in the kernel work.
> >
> > I think there is a confusion here about who registers the PHYs.
> >
> > All platform code does is registering a platform/i2c/whatever device,
> > which causes a driver (located in drivers/phy/) to be instantiated.
> > Such drivers call phy_create(), usually in their probe() callbacks,
> > so platform_code has no way (and should have no way, for the sake of
> > layering) to get what phy_create() returns.
>
> right.
>
> > IMHO we need a lookup method for PHYs, just like for clocks,
> > regulators, PWMs or even i2c busses because there are complex cases
> > when passing just a name using platform data will not work. I would
> > second what Stephen said [1] and define a structure doing things in a
> > DT-like way.
> >
> > Example;
> >
> > [platform code]
> >
> > static const struct phy_lookup my_phy_lookup[] = {
> >
> > PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
>
> The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
> creating the device, the ids in the device name would change and
> PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods already
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] Common Clock Framework support for Samsung S3C64xx
This series is an attempt to move clock support on Samsung S3C64xx SoCs to Common Clock Framework. First, support for PLL types present on S3C64xx SoCs is added to Samsung Common Clock Framework driver. Then the main clock driver for mentioned SoCs is introduced. Further patches contain fixes for drivers to make them compliant with CCF semantics, migration of platform code to use the new clock driver and removal of old clock management code. Depends on: - [PATCH v4 00/20] Samsung PWM support cleanup http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20856 On S3C6410-based Tiny6410 board (Mini6410-compatible): Tested-by: Tomasz Figa For v1: Acked-by: Mike Turquette Changes since v1: - added patch for read-only muxes, - exported configurable muxes and dividers, - defined mout_syncmux as read-only mux, - in DT-enabled case fixed-clock binding is used to define external clocks. Tomasz Figa (8): clk: mux: Add support for read-only muxes. clk: samsung: pll: Add support for PLL6552 and PLL6553 clk: samsung: Add clock driver for S3C64xx SoCs ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare ARM: s3c64xx: Migrate clock handling to Common Clock Framework ARM: s3c64xx: Remove old clock management code .../bindings/clock/samsung,s3c64xx-clock.txt | 77 ++ arch/arm/Kconfig |2 +- arch/arm/mach-s3c64xx/Makefile |2 +- arch/arm/mach-s3c64xx/clock.c | 1007 arch/arm/mach-s3c64xx/common.c | 21 +- arch/arm/mach-s3c64xx/common.h | 12 +- arch/arm/mach-s3c64xx/dma.c|4 +- arch/arm/mach-s3c64xx/include/mach/regs-clock.h| 132 +-- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-smartq.c| 11 +- arch/arm/mach-s3c64xx/mach-smdk6400.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s3c64xx/pm.c | 21 - arch/arm/mach-s3c64xx/s3c6400.c|6 - arch/arm/mach-s3c64xx/s3c6410.c|7 - arch/arm/plat-samsung/include/plat/cpu.h |4 + drivers/clk/clk-mux.c | 10 +- drivers/clk/samsung/Makefile |1 + drivers/clk/samsung/clk-pll.c | 160 drivers/clk/samsung/clk-pll.h |4 + drivers/clk/samsung/clk-s3c64xx.c | 465 + drivers/usb/host/ohci-s3c2410.c|8 +- include/dt-bindings/clock/samsung,s3c64xx-clock.h | 178 include/linux/clk-provider.h |2 + 28 files changed, 943 insertions(+), 1205 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt delete mode 100644 arch/arm/mach-s3c64xx/clock.c create mode 100644 drivers/clk/samsung/clk-s3c64xx.c create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/8] clk: mux: Add support for read-only muxes.
Some platforms have read-only clock muxes that are preconfigured at
reset and cannot be changed at runtime. This patch extends mux clock
driver to allow handling such read-only muxes by adding new
CLK_MUX_READ_ONLY mux flag.
Signed-off-by: Tomasz Figa
---
drivers/clk/clk-mux.c| 10 +-
include/linux/clk-provider.h | 2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 61c..92f1a1b 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -107,6 +107,11 @@ const struct clk_ops clk_mux_ops = {
};
EXPORT_SYMBOL_GPL(clk_mux_ops);
+const struct clk_ops clk_mux_ro_ops = {
+ .get_parent = clk_mux_get_parent,
+};
+EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
+
struct clk *clk_register_mux_table(struct device *dev, const char *name,
const char **parent_names, u8 num_parents, unsigned long flags,
void __iomem *reg, u8 shift, u32 mask,
@@ -133,7 +138,10 @@ struct clk *clk_register_mux_table(struct device *dev,
const char *name,
}
init.name = name;
- init.ops = &clk_mux_ops;
+ if (clk_mux_flags & CLK_MUX_READ_ONLY)
+ init.ops = &clk_mux_ro_ops;
+ else
+ init.ops = &clk_mux_ops;
init.flags = flags | CLK_IS_BASIC;
init.parent_names = parent_names;
init.num_parents = num_parents;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1ec14a7..9487b96 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -327,8 +327,10 @@ struct clk_mux {
#define CLK_MUX_INDEX_ONE BIT(0)
#define CLK_MUX_INDEX_BIT BIT(1)
#define CLK_MUX_HIWORD_MASKBIT(2)
+#define CLK_MUX_READ_ONLY BIT(3) /* mux setting cannot be changed */
extern const struct clk_ops clk_mux_ops;
+extern const struct clk_ops clk_mux_ro_ops;
struct clk *clk_register_mux(struct device *dev, const char *name,
const char **parent_names, u8 num_parents, unsigned long flags,
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/8] clk: samsung: pll: Add support for PLL6552 and PLL6553
This patch adds support for PLL6552 and PLL6553 PLLs present on Samsung
S3C64xx SoCs.
Signed-off-by: Tomasz Figa
Acked-by: Mike Turquette
---
drivers/clk/samsung/clk-pll.c | 160 ++
drivers/clk/samsung/clk-pll.h | 4 ++
2 files changed, 164 insertions(+)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 362f12d..698e562 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -337,6 +337,166 @@ struct clk * __init samsung_clk_register_pll46xx(const
char *name,
}
/*
+ * PLL6552 Clock Type
+ */
+
+#define PLL6552_LOCK_REG 0x00
+#define PLL6552_CON_REG0x0c
+
+#define PLL6552_MDIV_MASK 0x3ff
+#define PLL6552_PDIV_MASK 0x3f
+#define PLL6552_SDIV_MASK 0x7
+#define PLL6552_MDIV_SHIFT 16
+#define PLL6552_PDIV_SHIFT 8
+#define PLL6552_SDIV_SHIFT 0
+
+struct samsung_clk_pll6552 {
+ struct clk_hw hw;
+ void __iomem *reg_base;
+};
+
+#define to_clk_pll6552(_hw) container_of(_hw, struct samsung_clk_pll6552, hw)
+
+static unsigned long samsung_pll6552_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll6552 *pll = to_clk_pll6552(hw);
+ u32 mdiv, pdiv, sdiv, pll_con;
+ u64 fvco = parent_rate;
+
+ pll_con = __raw_readl(pll->reg_base + PLL6552_CON_REG);
+ mdiv = (pll_con >> PLL6552_MDIV_SHIFT) & PLL6552_MDIV_MASK;
+ pdiv = (pll_con >> PLL6552_PDIV_SHIFT) & PLL6552_PDIV_MASK;
+ sdiv = (pll_con >> PLL6552_SDIV_SHIFT) & PLL6552_SDIV_MASK;
+
+ fvco *= mdiv;
+ do_div(fvco, (pdiv << sdiv));
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6552_clk_ops = {
+ .recalc_rate = samsung_pll6552_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll6552(const char *name,
+ const char *pname, void __iomem *base)
+{
+ struct samsung_clk_pll6552 *pll;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+ if (!pll) {
+ pr_err("%s: could not allocate pll clk %s\n", __func__, name);
+ return NULL;
+ }
+
+ init.name = name;
+ init.ops = &samsung_pll6552_clk_ops;
+ init.parent_names = &pname;
+ init.num_parents = 1;
+
+ pll->hw.init = &init;
+ pll->reg_base = base;
+
+ clk = clk_register(NULL, &pll->hw);
+ if (IS_ERR(clk)) {
+ pr_err("%s: failed to register pll clock %s\n", __func__,
+ name);
+ kfree(pll);
+ }
+
+ if (clk_register_clkdev(clk, name, NULL))
+ pr_err("%s: failed to register lookup for %s", __func__, name);
+
+ return clk;
+}
+
+/*
+ * PLL6553 Clock Type
+ */
+
+#define PLL6553_LOCK_REG 0x00
+#define PLL6553_CON0_REG 0x0c
+#define PLL6553_CON1_REG 0x10
+
+#define PLL6553_MDIV_MASK 0xff
+#define PLL6553_PDIV_MASK 0x3f
+#define PLL6553_SDIV_MASK 0x7
+#define PLL6553_KDIV_MASK 0x
+#define PLL6553_MDIV_SHIFT 16
+#define PLL6553_PDIV_SHIFT 8
+#define PLL6553_SDIV_SHIFT 0
+#define PLL6553_KDIV_SHIFT 0
+
+struct samsung_clk_pll6553 {
+ struct clk_hw hw;
+ void __iomem *reg_base;
+};
+
+#define to_clk_pll6553(_hw) container_of(_hw, struct samsung_clk_pll6553, hw)
+
+static unsigned long samsung_pll6553_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll6553 *pll = to_clk_pll6553(hw);
+ u32 mdiv, pdiv, sdiv, kdiv, pll_con0, pll_con1;
+ u64 fvco = parent_rate;
+
+ pll_con0 = __raw_readl(pll->reg_base + PLL6553_CON0_REG);
+ pll_con1 = __raw_readl(pll->reg_base + PLL6553_CON1_REG);
+ mdiv = (pll_con0 >> PLL6553_MDIV_SHIFT) & PLL6553_MDIV_MASK;
+ pdiv = (pll_con0 >> PLL6553_PDIV_SHIFT) & PLL6553_PDIV_MASK;
+ sdiv = (pll_con0 >> PLL6553_SDIV_SHIFT) & PLL6553_SDIV_MASK;
+ kdiv = (pll_con1 >> PLL6553_KDIV_SHIFT) & PLL6553_KDIV_MASK;
+
+ fvco *= (mdiv << 16) + kdiv;
+ do_div(fvco, (pdiv << sdiv));
+ fvco >>= 16;
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6553_clk_ops = {
+ .recalc_rate = samsung_pll6553_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll6553(const char *name,
+ const char *pname, void __iomem *base)
+{
+ struct samsung_clk_pll6553 *pll;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+ if (!pll) {
+ pr_err("%s: could not allocate pll clk %s\n&qu
[PATCH v2 4/8] ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros
This patch adds soc_is_s3c6400() and soc_is_s3c6410() macros that allow to distinguish between specific SoCs from s3c64xx series that is needed to handle differences between them. Signed-off-by: Tomasz Figa --- arch/arm/plat-samsung/include/plat/cpu.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/plat-samsung/include/plat/cpu.h b/arch/arm/plat-samsung/include/plat/cpu.h index 4fb1f03..335beb3 100644 --- a/arch/arm/plat-samsung/include/plat/cpu.h +++ b/arch/arm/plat-samsung/include/plat/cpu.h @@ -87,8 +87,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK) #endif #if defined(CONFIG_CPU_S3C6400) || defined(CONFIG_CPU_S3C6410) +# define soc_is_s3c6400() is_samsung_s3c6400() +# define soc_is_s3c6410() is_samsung_s3c6410() # define soc_is_s3c64xx() (is_samsung_s3c6400() || is_samsung_s3c6410()) #else +# define soc_is_s3c6400() 0 +# define soc_is_s3c6410() 0 # define soc_is_s3c64xx() 0 #endif -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/8] clk: samsung: Add clock driver for S3C64xx SoCs
This patch adds new, Common Clock Framework-based clock driver for Samsung
S3C64xx SoCs. The driver is just added, without actually letting the
platforms use it yet, since this requires more intermediate steps.
Signed-off-by: Tomasz Figa
Acked-by: Mike Turquette
---
.../bindings/clock/samsung,s3c64xx-clock.txt | 77
drivers/clk/samsung/Makefile | 3 +
drivers/clk/samsung/clk-s3c64xx.c | 465 +
include/dt-bindings/clock/samsung,s3c64xx-clock.h | 178
4 files changed, 723 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
create mode 100644 drivers/clk/samsung/clk-s3c64xx.c
create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
new file mode 100644
index 000..fa171dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
@@ -0,0 +1,77 @@
+* Samsung S3C64xx Clock Controller
+
+The S3C64xx clock controller generates and supplies clock to various
controllers
+within the SoC. The clock binding described here is applicable to all SoCs in
+the S3C64xx family.
+
+Required Properties:
+
+- compatible: should be one of the following.
+ - "samsung,s3c6400-clock" - controller compatible with S3C6400 SoC.
+ - "samsung,s3c6410-clock" - controller compatible with S3C6410 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular S3C64xx SoC and this is specified where applicable.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/samsung,s3c64xx-clock.h header and can be used in device
+tree sources.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "fin_pll" - PLL input clock (xtal/extclk) - required,
+ - "xusbxti" - USB xtal - required,
+ - "iiscdclk0" - I2S0 codec clock - optional,
+ - "iiscdclk1" - I2S1 codec clock - optional,
+ - "iiscdclk2" - I2S2 codec clock - optional,
+ - "pcmcdclk0" - PCM0 codec clock - optional,
+ - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
+
+Example: Clock controller node:
+
+ clock: clock-controller@7e00f000 {
+ compatible = "samsung,s3c6410-clock";
+ reg = <0x7e00f000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+Example: Required external clocks:
+
+ fin_pll: clock-fin-pll {
+ compatible = "fixed-clock";
+ clock-output-names = "fin_pll";
+ clock-frequency = <1200>;
+ #clock-cells = <0>;
+ };
+
+ xusbxti: clock-xusbxti {
+ compatible = "fixed-clock";
+ clock-output-names = "xusbxti";
+ clock-frequency = <4800>;
+ #clock-cells = <0>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller (refer to the standard clock bindings for information about
+ "clocks" and "clock-names" properties):
+
+ uart0: serial@7f005000 {
+ compatible = "samsung,s3c6400-uart";
+ reg = <0x7f005000 0x100>;
+ interrupt-parent = <&vic1>;
+ interrupts = <5>;
+ clock-names = "uart", "clk_uart_baud2",
+ "clk_uart_baud3";
+ clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>,
+ <&clock SCLK_UART>;
+ status = "disabled";
+ };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 5d4d432..3413380 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -8,3 +8,6 @@ obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
+ifdef CONFIG_COMMON_CLK
+obj-$(CONFIG_ARCH_S3C64XX) += clk-s3c64xx.o
+endif
diff --git a/drivers/clk/samsung/clk-s3c64xx.c
b/drivers/clk/samsung/clk-s3c64xx.c
new file mode 100644
index 000..6511f78
--- /dev/null
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -0,0 +1,46
[PATCH v2 7/8] ARM: s3c64xx: Migrate clock handling to Common Clock Framework
This patch migrates the s3c64xx platform to use the new clock driver
using Common Clock Framework.
Signed-off-by: Tomasz Figa
---
arch/arm/Kconfig | 2 +-
arch/arm/mach-s3c64xx/Makefile| 2 +-
arch/arm/mach-s3c64xx/common.c| 21 +
arch/arm/mach-s3c64xx/common.h| 10 +-
arch/arm/mach-s3c64xx/mach-anw6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-crag6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-hmt.c | 2 +-
arch/arm/mach-s3c64xx/mach-mini6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-ncp.c | 2 +-
arch/arm/mach-s3c64xx/mach-smartq.c | 11 ++-
arch/arm/mach-s3c64xx/mach-smdk6400.c | 2 +-
arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +-
arch/arm/mach-s3c64xx/s3c6400.c | 6 --
arch/arm/mach-s3c64xx/s3c6410.c | 7 ---
drivers/clk/samsung/Makefile | 2 --
15 files changed, 33 insertions(+), 42 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fa7ffca..cfa7e59 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -724,6 +724,7 @@ config ARCH_S3C64XX
select ARM_VIC
select CLKDEV_LOOKUP
select CLKSRC_SAMSUNG_PWM
+ select COMMON_CLK
select CPU_V6
select GENERIC_CLOCKEVENTS
select GPIO_SAMSUNG
@@ -737,7 +738,6 @@ config ARCH_S3C64XX
select S3C_DEV_NAND
select S3C_GPIO_TRACK
select SAMSUNG_ATAGS
- select SAMSUNG_CLKSRC
select SAMSUNG_GPIOLIB_4BIT
select SAMSUNG_WDT_RESET
select USB_ARCH_HAS_OHCI
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 31d0c91..645a8fe 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -12,7 +12,7 @@ obj- :=
# Core
-obj-y += common.o clock.o
+obj-y += common.o
# Core support
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 73d79cf..7d3cb58 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -38,7 +39,6 @@
#include
#include
-#include
#include
#include
#include
@@ -50,6 +50,19 @@
#include "common.h"
+/* External clock frequency */
+static unsigned long xtal_f = 1200, xusbxti_f = 4800;
+
+void __init s3c64xx_set_xtal_freq(unsigned long freq)
+{
+ xtal_f = freq;
+}
+
+void __init s3c64xx_set_xusbxti_freq(unsigned long freq)
+{
+ xusbxti_f = freq;
+}
+
/* uart registration process */
static void __init s3c64xx_init_uarts(struct s3c2410_uartcfg *cfg, int no)
@@ -67,7 +80,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = S3C6400_CPU_ID,
.idmask = S3C64XX_CPU_MASK,
.map_io = s3c6400_map_io,
- .init_clocks= s3c6400_init_clocks,
.init_uarts = s3c64xx_init_uarts,
.init = s3c6400_init,
.name = name_s3c6400,
@@ -75,7 +87,6 @@ static struct cpu_table cpu_ids[] __initdata = {
.idcode = S3C6410_CPU_ID,
.idmask = S3C64XX_CPU_MASK,
.map_io = s3c6410_map_io,
- .init_clocks= s3c6410_init_clocks,
.init_uarts = s3c64xx_init_uarts,
.init = s3c6410_init,
.name = name_s3c6410,
@@ -213,8 +224,10 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32
vic1_valid)
{
/*
* FIXME: there is no better place to put this at the moment
-* (samsung_wdt_reset_init needs clocks)
+* (s3c64xx_clk_init needs ioremap and must happen before init_time
+* samsung_wdt_reset_init needs clocks)
*/
+ s3c64xx_clk_init(NULL, xtal_f, xusbxti_f, soc_is_s3c6400(), S3C_VA_SYS);
samsung_wdt_reset_init(S3C_VA_WATCHDOG);
printk(KERN_DEBUG "%s: initialising interrupts\n", __func__);
diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h
index e8f990b..a2af0e1 100644
--- a/arch/arm/mach-s3c64xx/common.h
+++ b/arch/arm/mach-s3c64xx/common.h
@@ -22,18 +22,19 @@
void s3c64xx_init_irq(u32 vic0, u32 vic1);
void s3c64xx_init_io(struct map_desc *mach_desc, int size);
-void s3c64xx_register_clocks(unsigned long xtal, unsigned armclk_limit);
-void s3c64xx_setup_clocks(void);
-
void s3c64xx_restart(enum reboot_mode mode, const char *cmd);
void s3c64xx_init_late(void);
+void s3c64xx_clk_init(struct device_node *np, unsigned long xtal_f,
+ unsigned long xusbxti_f, bool is_s3c6400, void __iomem *reg_base);
+void s3c64xx_set_xtal_freq(unsigned long freq);
+void s3c64xx_set_xusbxti_freq(unsigned long freq);
+
#ifdef CONFIG_CPU_S3C6400
extern int s3c6400_init(void);
extern void s3c6400_init_irq(void);
extern
[PATCH v2 6/8] usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare
This patch modifies the ohci-s3c2410 driver to prepare and unprepare
clocks in addition to enabling and disabling, since it is required
by common clock framework.
Signed-off-by: Tomasz Figa
---
drivers/usb/host/ohci-s3c2410.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index e125770..db096bf 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -47,10 +47,10 @@ static void s3c2410_start_hc(struct platform_device *dev,
struct usb_hcd *hcd)
dev_dbg(&dev->dev, "s3c2410_start_hc:\n");
- clk_enable(usb_clk);
+ clk_prepare_enable(usb_clk);
mdelay(2); /* let the bus clock stabilise */
- clk_enable(clk);
+ clk_prepare_enable(clk);
if (info != NULL) {
info->hcd = hcd;
@@ -75,8 +75,8 @@ static void s3c2410_stop_hc(struct platform_device *dev)
(info->enable_oc)(info, 0);
}
- clk_disable(clk);
- clk_disable(usb_clk);
+ clk_disable_unprepare(clk);
+ clk_disable_unprepare(usb_clk);
}
/* ohci_s3c2410_hub_status_data
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/8] ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare
This patch modifies s3c64xx DMA driver to prepare and unprepare clocks in addition to enableind and disabling, since it is required by common clock framework. Signed-off-by: Tomasz Figa --- arch/arm/mach-s3c64xx/dma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-s3c64xx/dma.c b/arch/arm/mach-s3c64xx/dma.c index 759846c..c511dfa 100644 --- a/arch/arm/mach-s3c64xx/dma.c +++ b/arch/arm/mach-s3c64xx/dma.c @@ -677,7 +677,7 @@ static int s3c64xx_dma_init1(int chno, enum dma_ch chbase, goto err_map; } - clk_enable(dmac->clk); + clk_prepare_enable(dmac->clk); dmac->regs = regs; dmac->chanbase = chbase; @@ -711,7 +711,7 @@ static int s3c64xx_dma_init1(int chno, enum dma_ch chbase, return 0; err_clk: - clk_disable(dmac->clk); + clk_disable_unprepare(dmac->clk); clk_put(dmac->clk); err_map: iounmap(regs); -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/8] ARM: s3c64xx: Remove old clock management code
This patch removes old clock management code of S3C64xx, since the
platform has been already moved to the new clock driver using Common
Clock Framework.
Signed-off-by: Tomasz Figa
---
arch/arm/mach-s3c64xx/clock.c | 1007 ---
arch/arm/mach-s3c64xx/common.h |2 -
arch/arm/mach-s3c64xx/include/mach/regs-clock.h | 132 +--
arch/arm/mach-s3c64xx/pm.c | 21 -
4 files changed, 4 insertions(+), 1158 deletions(-)
delete mode 100644 arch/arm/mach-s3c64xx/clock.c
diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
deleted file mode 100644
index c1bcc4a..000
--- a/arch/arm/mach-s3c64xx/clock.c
+++ /dev/null
@@ -1,1007 +0,0 @@
-/* linux/arch/arm/plat-s3c64xx/clock.c
- *
- * Copyright 2008 Openmoko, Inc.
- * Copyright 2008 Simtec Electronics
- * Ben Dooks
- * http://armlinux.simtec.co.uk/
- *
- * S3C64XX Base clock support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "regs-sys.h"
-
-/* fin_apll, fin_mpll and fin_epll are all the same clock, which we call
- * ext_xtal_mux for want of an actual name from the manual.
-*/
-
-static struct clk clk_ext_xtal_mux = {
- .name = "ext_xtal",
-};
-
-#define clk_fin_apll clk_ext_xtal_mux
-#define clk_fin_mpll clk_ext_xtal_mux
-#define clk_fin_epll clk_ext_xtal_mux
-
-#define clk_fout_mpll clk_mpll
-#define clk_fout_epll clk_epll
-
-struct clk clk_h2 = {
- .name = "hclk2",
- .rate = 0,
-};
-
-struct clk clk_27m = {
- .name = "clk_27m",
- .rate = 2700,
-};
-
-static int clk_48m_ctrl(struct clk *clk, int enable)
-{
- unsigned long flags;
- u32 val;
-
- /* can't rely on clock lock, this register has other usages */
- local_irq_save(flags);
-
- val = __raw_readl(S3C64XX_OTHERS);
- if (enable)
- val |= S3C64XX_OTHERS_USBMASK;
- else
- val &= ~S3C64XX_OTHERS_USBMASK;
-
- __raw_writel(val, S3C64XX_OTHERS);
- local_irq_restore(flags);
-
- return 0;
-}
-
-struct clk clk_48m = {
- .name = "clk_48m",
- .rate = 4800,
- .enable = clk_48m_ctrl,
-};
-
-struct clk clk_xusbxti = {
- .name = "xusbxti",
- .rate = 4800,
-};
-
-static int inline s3c64xx_gate(void __iomem *reg,
- struct clk *clk,
- int enable)
-{
- unsigned int ctrlbit = clk->ctrlbit;
- u32 con;
-
- con = __raw_readl(reg);
-
- if (enable)
- con |= ctrlbit;
- else
- con &= ~ctrlbit;
-
- __raw_writel(con, reg);
- return 0;
-}
-
-static int s3c64xx_pclk_ctrl(struct clk *clk, int enable)
-{
- return s3c64xx_gate(S3C_PCLK_GATE, clk, enable);
-}
-
-static int s3c64xx_hclk_ctrl(struct clk *clk, int enable)
-{
- return s3c64xx_gate(S3C_HCLK_GATE, clk, enable);
-}
-
-int s3c64xx_sclk_ctrl(struct clk *clk, int enable)
-{
- return s3c64xx_gate(S3C_SCLK_GATE, clk, enable);
-}
-
-static struct clk init_clocks_off[] = {
- {
- .name = "nand",
- .parent = &clk_h,
- }, {
- .name = "rtc",
- .parent = &clk_p,
- .enable = s3c64xx_pclk_ctrl,
- .ctrlbit= S3C_CLKCON_PCLK_RTC,
- }, {
- .name = "adc",
- .parent = &clk_p,
- .enable = s3c64xx_pclk_ctrl,
- .ctrlbit= S3C_CLKCON_PCLK_TSADC,
- }, {
- .name = "i2c",
- .devname= "s3c2440-i2c.0",
- .parent = &clk_p,
- .enable = s3c64xx_pclk_ctrl,
- .ctrlbit= S3C_CLKCON_PCLK_IIC,
- }, {
- .name = "i2c",
- .devname= "s3c2440-i2c.1",
- .parent = &clk_p,
- .enable = s3c64xx_pclk_ctrl,
- .ctrlbit= S3C6410_CLKCON_PCLK_I2C1,
- }, {
- .name = "keypad",
- .parent = &clk_p,
- .enable = s3c64xx_pclk_ctrl,
- .ctrlbit= S3C_CLKCON_PCLK_KEYPAD,
- }, {
- .name = "spi",
-
Re: [PATCH v2 6/8] usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare
On Monday 22 of July 2013 21:15:12 Fabio Estevam wrote: > On Mon, Jul 22, 2013 at 8:49 PM, Tomasz Figa wrote: > > dev_dbg(&dev->dev, "s3c2410_start_hc:\n"); > > > > - clk_enable(usb_clk); > > + clk_prepare_enable(usb_clk); > > clk_prepare_enable may fail, so you would better check its return > value. Well, ideally yes, but since this driver doesn't have any error path here anyway and on Samsung platforms clk_prepare_enable() simply can't fail, I'd keep it this way until somebody fixes this driver, as it has more issues than just this one. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Alan,
On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
> On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
> > > The PHY and the controller it is attached to are both physical
> > > devices.
> > >
> > > The connection between them is hardwired by the system
> > > manufacturer and cannot be changed by software.
> > >
> > > PHYs are generally described by fixed system-specific board
> > > files or by Device Tree information. Are they ever discovered
> > > dynamically?
> >
> > No. They are created just like any other platform devices are created.
>
> Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
> > > Is the same true for the controllers attached to the PHYs?
> > > If not -- if both a PHY and a controller are discovered
> > > dynamically -- how does the kernel know whether they are
> > > connected to each other?
> >
> > No differences here. Both PHY and controller will have dt information
> > or hwmod data using which platform devices will be created.
> >
> > > The kernel needs to know which controller is attached to which
> > > PHY. Currently this information is represented by name or ID
> > > strings embedded in platform data.
> >
> > right. It's embedded in the platform data of the controller.
>
> It must also be embedded in the PHY's platform data somehow.
> Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous replies.
Without any extra data in platform data. (I have even posted a code
example.)
> > > The PHY's driver (the supplier) uses the platform data to
> > > construct a platform_device structure that represents the PHY.
> >
> > Currently the driver assigns static labels (corresponding to the label
> > used in the platform data of the controller).
> >
> > > Until this is done, the controller's driver (the client) cannot
> > > use the PHY.
> >
> > right.
> >
> > > Since there is no parent-child relation between the PHY and the
> > > controller, there is no guarantee that the PHY's driver will be
> > > ready when the controller's driver wants to use it. A deferred
> > > probe may be needed.
> >
> > right.
> >
> > > The issue (or one of the issues) in this discussion is that
> > > Greg does not like the idea of using names or IDs to associate
> > > PHYs with controllers, because they are too prone to
> > > duplications or other errors. Pointers are more reliable.
> > >
> > > But pointers to what? Since the only data known to be
> > > available to both the PHY driver and controller driver is the
> > > platform data, the obvious answer is a pointer to platform data
> > > (either for the PHY or for the controller, or maybe both).
> >
> > hmm.. it's not going to be simple though as the platform device for
> > the PHY and controller can be created in entirely different places.
> > e.g., in some cases the PHY device is a child of some mfd core device
> > (the device will be created in drivers/mfd) and the controller driver
> > (usually) is created in board file. I guess then we have to come up
> > with something to share a pointer in two different files.
>
> The ability for two different source files to share a pointer to a data
> item defined in a third source file has been around since long before
> the C language was invented. :-)
>
> In this case, it doesn't matter where the platform_device structures
> are created or where the driver source code is. Let's take a simple
> example. Suppose the system design includes a PHY named "foo". Then
> the board file could contain:
>
> struct phy_info { ... } phy_foo;
> EXPORT_SYMBOL_GPL(phy_foo);
>
> and a header file would contain:
>
> extern struct phy_info phy_foo;
>
> The PHY supplier could then call phy_create(&phy_foo), and the PHY
> client could call phy_find(&phy_foo). Or something like that; make up
> your own structure tags and function names.
>
> It's still possible to have conflicts, but now two PHYs with the same
> name (or a misspelled name somewhere) will cause an error at link time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host drivers.
This means you would have to export symbol with the same name from both
PHY drivers, which obviously would not work in this case, because having
both drivers enabled (in a multiplatform aware configuration) would lead
to linking conflict.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
[Fixed address of devicetree mailing list and added more people on CC.] For reference, full thread can be found under following link: http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813 Best regards, Tomasz On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote: > Hi Alan, > > On Monday 22 of July 2013 10:44:39 Alan Stern wrote: > > On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote: > > > > The PHY and the controller it is attached to are both physical > > > > devices. > > > > > > > > The connection between them is hardwired by the system > > > > manufacturer and cannot be changed by software. > > > > > > > > PHYs are generally described by fixed system-specific board > > > > files or by Device Tree information. Are they ever discovered > > > > dynamically? > > > > > > No. They are created just like any other platform devices are > > > created. > > > > Okay. Are PHYs _always_ platform devices? > > They can be i2c, spi or any other device types as well. > > > > > Is the same true for the controllers attached to the PHYs? > > > > If not -- if both a PHY and a controller are discovered > > > > dynamically -- how does the kernel know whether they are > > > > connected to each other? > > > > > > No differences here. Both PHY and controller will have dt > > > information > > > or hwmod data using which platform devices will be created. > > > > > > > The kernel needs to know which controller is attached to which > > > > PHY. Currently this information is represented by name or ID > > > > strings embedded in platform data. > > > > > > right. It's embedded in the platform data of the controller. > > > > It must also be embedded in the PHY's platform data somehow. > > Otherwise, how would the kernel know which PHY to use? > > By using a PHY lookup as Stephen and I suggested in our previous > replies. Without any extra data in platform data. (I have even posted a > code example.) > > > > > The PHY's driver (the supplier) uses the platform data to > > > > construct a platform_device structure that represents the PHY. > > > > > > Currently the driver assigns static labels (corresponding to the > > > label > > > used in the platform data of the controller). > > > > > > > Until this is done, the controller's driver (the client) cannot > > > > use the PHY. > > > > > > right. > > > > > > > Since there is no parent-child relation between the PHY and the > > > > controller, there is no guarantee that the PHY's driver will be > > > > ready when the controller's driver wants to use it. A deferred > > > > probe may be needed. > > > > > > right. > > > > > > > The issue (or one of the issues) in this discussion is that > > > > Greg does not like the idea of using names or IDs to associate > > > > PHYs with controllers, because they are too prone to > > > > duplications or other errors. Pointers are more reliable. > > > > > > > > But pointers to what? Since the only data known to be > > > > available to both the PHY driver and controller driver is the > > > > platform data, the obvious answer is a pointer to platform data > > > > (either for the PHY or for the controller, or maybe both). > > > > > > hmm.. it's not going to be simple though as the platform device for > > > the PHY and controller can be created in entirely different places. > > > e.g., in some cases the PHY device is a child of some mfd core > > > device > > > (the device will be created in drivers/mfd) and the controller > > > driver > > > (usually) is created in board file. I guess then we have to come up > > > with something to share a pointer in two different files. > > > > The ability for two different source files to share a pointer to a > > data > > item defined in a third source file has been around since long before > > the C language was invented. :-) > > > > In this case, it doesn't matter where the platform_device structures > > are
Re: [PATCH 6/6] USB: OHCI: make ohci-s3c2410 a separate driver
Hi Manjunath,
Please see some comments inline.
On Monday 22 of July 2013 14:49:30 Manjunath Goudar wrote:
> Separate the Samsung OHCI S3C host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.12.
>
> Signed-off-by: Manjunath Goudar
> Acked-by: Alan Stern
> Cc: Arnd Bergmann
> Cc: Greg KH
> Cc: linux-usb@vger.kernel.org
>
> V2:
> -Set non-standard fields in ohci_s3c2410_hc_driver manually, rather
> than relying on an expanded struct ohci_driver_overrides.
> -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
> relying on ohci_hub_control and hub_status_data being exported.
>
> V3:
> -Kconfig wrong parentheses discription fixed.
> -ohci_setup() has been removed because it is called in .reset member
> of the ohci_hc_driver structure.
>
> V4:
> - Removed extra space before the '='.
> - Moved /* forward definitions */ line before the declarations of
> functions. ---
> drivers/usb/host/Kconfig|8 +++
> drivers/usb/host/Makefile |1 +
> drivers/usb/host/ohci-hcd.c | 18 --
> drivers/usb/host/ohci-s3c2410.c | 128
> +-- 4 files changed, 66
> insertions(+), 89 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 693560a..795d14d 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
>Enables support for the on-chip OHCI controller on
>ST SPEAr chips.
>
> +config USB_OHCI_HCD_S3C
> +tristate "Support for S3C on-chip OHCI USB controller"
> +depends on USB_OHCI_HCD && (ARCH_S3C24XX || ARCH_S3C64XX)
> +default y
> +---help---
> + Enables support for the on-chip OHCI controller on
> + S3C chips.
> +
Please keep the name s3c2410 for consistency. Having all the names come
from the first SoC with this hardware is somewhat deterministic as opposed
to some other naming methods, e.g. ohci-exynos2, while later on a
different SoC from Exynos 2 shows up that needs a different driver.
> config USB_OHCI_HCD_AT91
> tristate "Support for Atmel on-chip OHCI USB controller"
> depends on USB_OHCI_HCD && ARCH_AT91
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index a70b044..9dffe81 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP1)+= ohci-omap.o
> obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o
> obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o
> obj-$(CONFIG_USB_OHCI_HCD_AT91) += ohci-at91.o
> +obj-$(CONFIG_USB_OHCI_HCD_S3C) += ohci-s3c2410.o
>
> obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
> obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index b48c892..b69a49e 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -1177,11 +1177,6 @@ MODULE_LICENSE ("GPL");
> #define SA_DRIVERohci_hcd_sa_driver
> #endif
>
> -#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
> -#include "ohci-s3c2410.c"
> -#define S3C2410_PLATFORM_DRIVER ohci_hcd_s3c2410_driver
> -#endif
> -
> #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
> #include "ohci-pxa27x.c"
> #define PLATFORM_DRIVER ohci_hcd_pxa27x_driver
> @@ -1293,12 +1288,6 @@ static int __init ohci_hcd_mod_init(void)
> goto error_tmio;
> #endif
>
> -#ifdef S3C2410_PLATFORM_DRIVER
> - retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
> - if (retval < 0)
> - goto error_s3c2410;
> -#endif
> -
> #ifdef EP93XX_PLATFORM_DRIVER
> retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
> if (retval < 0)
> @@ -1332,10 +1321,6 @@ static int __init ohci_hcd_mod_init(void)
> platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
> error_ep93xx:
> #endif
> -#ifdef S3C2410_PLATFORM_DRIVER
> - platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
> - error_s3c2410:
> -#endif
> #ifdef TMIO_OHCI_DRIVER
> platform_driver_unregister(&TMIO_OHCI_DRIVER);
> error_tmio:
> @@ -1382,9 +1367,6 @@ static void __exit ohci_hcd_mod_exit(void)
> #ifdef EP93XX_PLATFORM_DRIVER
> platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
> #endif
> -#ifdef S3C2410_PLATFORM_DRIVER
> - platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
> -#endif
> #ifdef TMIO_OHCI_DRIVER
> platform_driver_unregister(&TMIO_OHCI_DRIVER);
> #endif
> diff --git a/drivers/usb/host/ohci-s3c2410.c
> b/drivers/usb/host/ohci-s3c2410.c index e125770..48b5948 100644
> --- a/drivers/usb/host/ohci-s3c2410.c
> +++ b/drivers/usb/host/ohci-s3c2410.c
> @@ -19,19 +19,36 @@
> * This file is licenced under the GPL.
> */
>
>
Re: [PATCH v2 1/8] clk: mux: Add support for read-only muxes.
Hi Sergei,
On Tuesday 23 of July 2013 15:22:44 Sergei Shtylyov wrote:
> Hello.
>
> On 23-07-2013 3:49, Tomasz Figa wrote:
> > Some platforms have read-only clock muxes that are preconfigured at
> > reset and cannot be changed at runtime. This patch extends mux clock
> > driver to allow handling such read-only muxes by adding new
> > CLK_MUX_READ_ONLY mux flag.
> >
> > Signed-off-by: Tomasz Figa
>
> [...]
>
> > diff --git a/include/linux/clk-provider.h
> > b/include/linux/clk-provider.h
> > index 1ec14a7..9487b96 100644
> > --- a/include/linux/clk-provider.h
> > +++ b/include/linux/clk-provider.h
> > @@ -327,8 +327,10 @@ struct clk_mux {
> > #define CLK_MUX_INDEX_ONE BIT(0)
> > #define CLK_MUX_INDEX_BIT BIT(1)
> > #define CLK_MUX_HIWORD_MASK BIT(2)
> > +#define CLK_MUX_READ_ONLY BIT(3) /* mux setting cannot be changed */
>
> Please align BIT(3) with the above BIT() invocations.
Different indentation was intended here to fit the comment, like in case of
generic flags. IMHO remaining flags should be changed to this way as well,
but this is probably material for another patch.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 10:37:05 Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > > Hi Alan,
>
> Thanks for helping to clarify the issues here.
>
> > > > Okay. Are PHYs _always_ platform devices?
> > >
> > > They can be i2c, spi or any other device types as well.
>
> In those other cases, presumably there is no platform data associated
> with the PHY since it isn't a platform device. Then how does the
> kernel know which controller is attached to the PHY? Is this spelled
> out in platform data associated with the PHY's i2c/spi/whatever parent?
>
> > > > > > PHY. Currently this information is represented by name or
> >
> > ID
> >
> > > > > > strings embedded in platform data.
> > > > >
> > > > > right. It's embedded in the platform data of the controller.
> > > >
> > > > It must also be embedded in the PHY's platform data somehow.
> > > > Otherwise, how would the kernel know which PHY to use?
> > >
> > > By using a PHY lookup as Stephen and I suggested in our previous
> > > replies. Without any extra data in platform data. (I have even posted
> > > a
> > > code example.)
>
> I don't understand, because I don't know what "a PHY lookup" does.
I have provided a code example in [1]. Feel free to ask questions about
those code snippets.
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=20889
> > > > In this case, it doesn't matter where the platform_device
> > > > structures
> > > > are created or where the driver source code is. Let's take a
> > > > simple
> > > > example. Suppose the system design includes a PHY named "foo".
> > > > Then
> > > > the board file could contain:
> > > >
> > > > struct phy_info { ... } phy_foo;
> > > > EXPORT_SYMBOL_GPL(phy_foo);
> > > >
> > > > and a header file would contain:
> > > >
> > > > extern struct phy_info phy_foo;
> > > >
> > > > The PHY supplier could then call phy_create(&phy_foo), and the PHY
> > > > client could call phy_find(&phy_foo). Or something like that; make
> > > > up
> > > > your own structure tags and function names.
> > > >
> > > > It's still possible to have conflicts, but now two PHYs with the
> > > > same
> > > > name (or a misspelled name somewhere) will cause an error at link
> > > > time.
> > >
> > > This is incorrect, sorry. First of all it's a layering violation -
> > > you
> > > export random driver-specific symbols from one driver to another.
> > > Then
>
> No, that's not what I said. Neither the PHY driver nor the controller
> driver exports anything to the other. Instead, both drivers use data
> exported by the board file.
It's still a random, driver-specific global symbol exported from board file
to drivers.
> > > imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
> > > and
> > > there are two types of consumer drivers (e.g. USB host controllers).
> > > Now
> > > consider following mapping:
> > >
> > > SoC PHY consumer
> > > A PHY1HOST1
> > > B PHY1HOST2
> > > C PHY2HOST1
> > > D PHY2HOST2
> > >
> > > So we have to be able to use any of the PHYs with any of the host
> > > drivers. This means you would have to export symbol with the same
> > > name
> > > from both PHY drivers, which obviously would not work in this case,
> > > because having both drivers enabled (in a multiplatform aware
> > > configuration) would lead to linking conflict.
>
> You're right; the scheme was too simple. Instead, the board file must
> export two types of data structures, one for PHYs and one for
> controllers. Like this:
>
> struct phy_info {
> /* Info for the controller attached to this PHY */
> struct controller_info *hinfo;
> };
>
> struct controller_info {
> /* Info for the PHY which this controller is attached to */
> struct phy_info *pinfo;
> };
>
> The board file for SoC A would contain:
>
> struct phy_info phy1 = {&host1);
> EXPORT_SYMBOL(phy1);
> struct controller_info host1 = {&phy1};
> EXPORT_SYMBOL(host1);
>
> The board file for SoC B would contain:
>
> struct phy_info phy1 = {&host2);
> EXPORT_SYMBOL(phy1);
> struct controller_info host2 = {&phy1};
> EXPORT_SYMBOL(host2);
>
> And so on. This explicitly gives the connection between PHYs and
> controllers. The PHY providers would use &phy1 or &phy2, and the PHY
> consumers would use &host1 or &host2.
This could work assuming that only one SoC and one board is supported in
single kernel image. However it's not the case.
We've used to support multiple boards since a long time already and now for
selected platforms we even support multiplatform, i.e. multiple SoCs in
single zImage. Such solution will not work.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 09:18:46 Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > >> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > >>> Hi Alan,
> > >
> > > Thanks for helping to clarify the issues here.
> > >
> > >>>> Okay. Are PHYs _always_ platform devices?
> > >>>
> > >>> They can be i2c, spi or any other device types as well.
> > >
> > > In those other cases, presumably there is no platform data associated
> > > with the PHY since it isn't a platform device. Then how does the
> > > kernel know which controller is attached to the PHY? Is this spelled
> > > out in platform data associated with the PHY's i2c/spi/whatever
> > > parent?
> >
> > Yes. I think we could use i2c_board_info for passing platform data.
> >
> > >>>>>> PHY. Currently this information is represented by name or
> > >>
> > >> ID
> > >>
> > >>>>>> strings embedded in platform data.
> > >>>>>
> > >>>>> right. It's embedded in the platform data of the controller.
> > >>>>
> > >>>> It must also be embedded in the PHY's platform data somehow.
> > >>>> Otherwise, how would the kernel know which PHY to use?
> > >>>
> > >>> By using a PHY lookup as Stephen and I suggested in our previous
> > >>> replies. Without any extra data in platform data. (I have even
> > >>> posted a
> > >>> code example.)
> > >
> > > I don't understand, because I don't know what "a PHY lookup" does.
> >
> > It is how the PHY framework finds a PHY, when the controller (say
> > USB)requests a PHY from the PHY framework.
> >
> > >>>> In this case, it doesn't matter where the platform_device
> > >>>> structures
> > >>>> are created or where the driver source code is. Let's take a
> > >>>> simple
> > >>>> example. Suppose the system design includes a PHY named "foo".
> > >>>> Then
> > >>>> the board file could contain:
> > >>>>
> > >>>> struct phy_info { ... } phy_foo;
> > >>>> EXPORT_SYMBOL_GPL(phy_foo);
> > >>>>
> > >>>> and a header file would contain:
> > >>>>
> > >>>> extern struct phy_info phy_foo;
> > >>>>
> > >>>> The PHY supplier could then call phy_create(&phy_foo), and the PHY
> > >>>> client could call phy_find(&phy_foo). Or something like that;
> > >>>> make up
> > >>>> your own structure tags and function names.
> > >>>>
> > >>>> It's still possible to have conflicts, but now two PHYs with the
> > >>>> same
> > >>>> name (or a misspelled name somewhere) will cause an error at link
> > >>>> time.
> > >>>
> > >>> This is incorrect, sorry. First of all it's a layering violation -
> > >>> you
> > >>> export random driver-specific symbols from one driver to another.
> > >>> Then
> > >
> > > No, that's not what I said. Neither the PHY driver nor the
> > > controller
> > > driver exports anything to the other. Instead, both drivers use data
> > > exported by the board file.
> >
> > I think instead we can use the same data while creating the platform
> > data of the controller and the PHY.
> > The PHY driver while creating the PHY (using PHY framework) will also
> > pass the *data* it actually got from the platform data to the
> > framework. The PHY user driver (USB), while requesting for the PHY
> > (from the PHY framework) will pass the *data* it got from its platform
> > data.
> > The PHY framework can do a comparison of the *data* pointers it has and
> > return the appropriate PHY to the controller.
> >
> > >>> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
> > >>> and
> > >>> there are two types of consumer drivers (e.g. USB host
> > >>> controllers). Now
> > >>> consider fo
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > Ick, no. Why can't you just pass the pointer to the phy itself? If
> > > you
> > > had a "priv" pointer to search from, then you could have just passed
> > > the
> > > original phy pointer in the first place, right?
> >
> > IMHO it would be better if you provided some code example, but let's
> > try to check if I understood you correctly.
>
> It's not my code that I want to have added, so I don't have to write
> examples, I just get to complain about the existing stuff :)
Still, I think that some small code snippets illustrating the idea are
really helpful.
> > 8><
> >
> >
> > [Board file]
> >
> > static struct phy my_phy;
> >
> > static struct platform_device phy_pdev = {
> >
> > /* ... */
> > .platform_data = &my_phy;
> > /* ... */
> >
> > };
> >
> > static struct platform_device phy_pdev = {
> >
> > /* ... */
> > .platform_data = &my_phy;
> > /* ... */
> >
> > };
> >
> > [Provider driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_create(phy);
> >
> > [Consumer driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_get(&pdev->dev, phy);
> >
> > ---
> > -><8
> >
> > Is this what you mean?
>
> No. Well, kind of. What's wrong with using the platform data structure
> unique to the board to have the pointer?
>
> For example (just randomly picking one), the ata-pxa driver would change
> include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
>
> struct phy;
>
> struct pata_pxa_pdata {
> /* PXA DMA DREQ<0:2> pin */
> uint32_tdma_dreq;
> /* Register shift */
> uint32_treg_shift;
> /* IRQ flags */
> uint32_tirq_flags;
> /* PHY */
> struct phy *phy;
> };
>
> Then, when you create the platform, set the phy* pointer with a call to
> phy_create(). Then you can use that pointer wherever that plaform data
> is available (i.e. whereever platform_data is at).
Hmm? So, do you suggest to call phy_create() from board file? What phy_ops
struct and other hardware parameters would it take?
> > > The issue is that a string "name" is not going to scale at all, as it
> > > requires hard-coded information that will change over time (as the
> > > existing clock interface is already showing.)
> >
> > I fully agree that a simple, single string will not scale even in some,
> > not so uncommon cases, but there is already a lot of existing lookup
> > solutions over the kernel and so there is no point in introducing
> > another one.
> I'm trying to get _rid_ of lookup "solutions" and just use a real
> pointer, as you should. I'll go tackle those other ones after this one
> is taken care of, to show how the others should be handled as well.
There was a reason for introducing lookup solutions. The reason was that in
board file there is no way to get a pointer to something that is going to be
created much later in time. We don't do time travel ;-).
> > > Please just pass the real "phy" pointer around, that's what it is
> > > there
> > > for. Your "board binding" logic/code should be able to handle this,
> > > as
> > > it somehow was going to do the same thing with a "name".
> >
> > It's technically correct, but quality of this solution isn't really
> > nice, because it's a layering violation (at least if I understood what
> > you mean). This is because you need to have full definition of struct
> > phy in board file and a structure that is used as private data in PHY
> > core comes from platform code.
>
> No, just a pointer, you don't need the "full" structure until you get to
> some .c code that actually manipulates the phy itself, for all other
> places, you are just dealing with a pointer and a structure you never
> reference.
>
> Does that make more sense?
Well, to the point that I think I now understood your suggestion.
Unfortunately the suggestion alone isn't really something that can be done,
considering how driver core and generic frameworks work.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > You don't "know" the id of the device you are looking up, due to
> > > multiple devices being in the system (dynamic ids, look back earlier
> > > in
> > > this thread for details about that.)
> >
> > I got copied in very late so don't have most of the thread I'm afraid,
> > I did try looking at web archives but didn't see a clear problem
> > statement. In any case this is why the APIs doing lookups do the
> > lookups in the context of the requesting device - devices ask for
> > whatever name they use locally.
>
> What do you mean by "locally"?
>
> The problem with the api was that the phy core wanted a id and a name to
> create a phy, and then later other code was doing a "lookup" based on
> the name and id (mushed together), because it "knew" that this device
> was the one it wanted.
>
> Just like the clock api, which, for multiple devices, has proven to
> cause problems. I don't want to see us accept an api that we know has
> issues in it now, I'd rather us fix it up properly.
>
> Subsystems should be able to create ids how ever they want to, and not
> rely on the code calling them to specify the names of the devices that
> way, otherwise the api is just too fragile.
>
> I think, that if you create a device, then just carry around the pointer
> to that device (in this case a phy) and pass it to whatever other code
> needs it. No need to do lookups on "known names" or anything else,
> just normal pointers, with no problems for multiple devices, busses, or
> naming issues.
PHY object is not a device, it is something that a device driver creates
(one or more instances of) when it is being probed. You don't have a clean
way to export this PHY object to other driver, other than keeping this PHY
on a list inside PHY core with some well-known ID (e.g. device name +
consumer port name/index, like in regulator core) and then to use this
well-known ID inside consumer driver as a lookup key passed to phy_get();
Actually I think for PHY case, exactly the same way as used for regulators
might be completely fine:
1. Each PHY would have some kind of platform, non-unique name, that is
just used to print some messages (like the platform/board name of a
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would
consist of consumer device name and consumer port name - just like in
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside its
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and wouldn't
receive any information about PHYs from platform code.
Code example:
[Board file]
static const struct phy_consumer_data usb_20_phy0_consumers[] = {
{
.devname = "foo-ehci",
.port = "usbphy",
},
};
static const struct phy_consumer_data usb_20_phy1_consumers[] = {
{
.devname = "foo-otg",
.port = "otgphy",
},
};
static const struct phy_init_data my_phys[] = {
{
.name = "USB 2.0 PHY 0",
.consumers = usb_20_phy0_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
},
{
.name = "USB 2.0 PHY 1",
.consumers = usb_20_phy1_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
},
{ }
};
static const struct platform_device usb_phy_pdev = {
.name = "foo-usbphy",
.id = -1,
.dev = {
.platform_data = my_phys,
},
};
[PHY driver]
static int foo_usbphy_probe(pdev)
{
struct foo_usbphy *foo;
struct phy_init_data *init_data = pdev->dev.platform_data;
/* ... */
// for each PHY in init_data {
phy_register(&foo->phy[i], &init_data[i]);
// }
/* ... */
}
[EHCI driver]
static int foo_ehci_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(&pdev->dev, "usbphy");
/* ... */
}
[OTG driver]
static int foo_otg_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(&pdev->dev, "otgphy");
/* ... */
}
> > > > Having to write platform data for everything gets old fast and the
> > > > code
> > > > duplication is pretty tedious...
> > >
> > > Adding a single pointer is "tedious"? Where is the "name" that you
> > > are
> > > going to lookup going to come from? That code doesn't write
> > > itself...
> >
> > It's adding platform data in the first place that gets tedious - and
> > of
> > course there's also DT and ACPI to worry about, it's not just a case
> > of
> > platform data and then you're done. Pushing the lookup into library
> > code means that drivers don't have to worry about any of this stuff.
>
> I agree, so just pass around the pointer to the phy and all
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 15:36:00 Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > IMHO it would be better if you provided some code example, but let's
> > try to check if I understood you correctly.
> >
> > 8><---
> > -
> >
> > [Board file]
> >
> > static struct phy my_phy;
> >
> > static struct platform_device phy_pdev = {
> >
> > /* ... */
> > .platform_data = &my_phy;
> > /* ... */
> >
> > };
> >
> > static struct platform_device phy_pdev = {
>
> This should be controller_pdev, not phy_pdev, yes?
Right. A copy-pasto.
>
> > /* ... */
> > .platform_data = &my_phy;
> > /* ... */
> >
> > };
> >
> > [Provider driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_create(phy);
> >
> > [Consumer driver]
> >
> > struct phy *phy = pdev->dev.platform_data;
> >
> > ret = phy_get(&pdev->dev, phy);
>
> Or even just phy_get(&pdev->dev), because phy_get() could be smart
> enough to to set phy = dev->platform_data.
Unless you need more than one PHY in this driver...
>
> > --
> > --><8
> >
> > Is this what you mean?
>
> That's what I was going to suggest too. The struct phy is defined in
> the board file, which already knows about all the PHYs that exist in
> the system. (Or perhaps it is allocated dynamically, so that when many
> board files are present in the same kernel, only the entries listed in
> the board file for the current system get created.)
Well, such dynamic allocation is a must. We don't accept non-multiplatform
aware code anymore, not even saying about multiboard.
> Then the
> structure's address is stored in the platform data and made available
> to both the provider and the consumer.
Yes, technically this can work. You would still have to perform some kind
of synchronization to make sure that the PHY bound to this structure is
actually present. This is again technically doable (e.g. a list of
registered struct phys inside PHY core).
> Even though the struct phy is defined (or allocated) in the board file,
> its contents don't get filled in until the PHY driver provides the
> details.
You can't assure this. Board file is free to do whatever it wants with
this struct. A clean solution would prevent this.
> > It's technically correct, but quality of this solution isn't really
> > nice, because it's a layering violation (at least if I understood
> > what you mean). This is because you need to have full definition of
> > struct phy in board file and a structure that is used as private data
> > in PHY core comes from platform code.
>
> You don't have to have a full definition in the board file. Just a
> partial definition -- most of the contents can be filled in later, when
> the PHY driver is ready to store the private data.
>
> It's not a layering violation for one region of the kernel to store
> private data in a structure defined by another part of the kernel.
> This happens all the time (e.g., dev_set_drvdata).
Not really. The phy struct is something that _is_ private data of PHY
subsystem, not something that can store private data of PHY subsystem
(sure it can store private data of particular PHY driver, but that's
another story) and only PHY subsystem should have access to its contents.
By the way, we need to consider other cases here as well, for example it
would be nice to have a single phy_get() function that works for both non-
DT and DT cases to make the consumer driver not have to worry whether it's
being probed from DT or not.
I'd suggest simply reusing the lookup method of regulator framework, just
as I suggested here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=101661
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 11:04:14 Greg KH wrote:
> On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> > > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > > > Ick, no. Why can't you just pass the pointer to the phy itself?
> > > > > If
> > > > > you
> > > > > had a "priv" pointer to search from, then you could have just
> > > > > passed
> > > > > the
> > > > > original phy pointer in the first place, right?
> > > >
> > > > IMHO it would be better if you provided some code example, but
> > > > let's
> > > > try to check if I understood you correctly.
> > >
> > > It's not my code that I want to have added, so I don't have to write
> > > examples, I just get to complain about the existing stuff :)
> >
> > Still, I think that some small code snippets illustrating the idea are
> > really helpful.
> >
> > > > 8><---
> > > > -
> > > >
> > > >
> > > > [Board file]
> > > >
> > > > static struct phy my_phy;
> > > >
> > > > static struct platform_device phy_pdev = {
> > > >
> > > > /* ... */
> > > > .platform_data = &my_phy;
> > > > /* ... */
> > > >
> > > > };
> > > >
> > > > static struct platform_device phy_pdev = {
> > > >
> > > > /* ... */
> > > > .platform_data = &my_phy;
> > > > /* ... */
> > > >
> > > > };
> > > >
> > > > [Provider driver]
> > > >
> > > > struct phy *phy = pdev->dev.platform_data;
> > > >
> > > > ret = phy_create(phy);
> > > >
> > > > [Consumer driver]
> > > >
> > > > struct phy *phy = pdev->dev.platform_data;
> > > >
> > > > ret = phy_get(&pdev->dev, phy);
> > > >
> > > > --
> > > > -
> > > > -><8
> > > >
> > > > Is this what you mean?
> > >
> > > No. Well, kind of. What's wrong with using the platform data
> > > structure unique to the board to have the pointer?
> > >
> > > For example (just randomly picking one), the ata-pxa driver would
> > > change include/linux/platform_data/ata-pxa.h to have a phy pointer
> > > in it:
> > >
> > > struct phy;
> > >
> > > struct pata_pxa_pdata {
> > >
> > > /* PXA DMA DREQ<0:2> pin */
> > > uint32_tdma_dreq;
> > > /* Register shift */
> > > uint32_treg_shift;
> > > /* IRQ flags */
> > > uint32_tirq_flags;
> > > /* PHY */
> > > struct phy *phy;
> > >
> > > };
> > >
> > > Then, when you create the platform, set the phy* pointer with a call
> > > to
> > > phy_create(). Then you can use that pointer wherever that plaform
> > > data
> > > is available (i.e. whereever platform_data is at).
> >
> > Hmm? So, do you suggest to call phy_create() from board file? What
> > phy_ops struct and other hardware parameters would it take?
> >
> > > > > The issue is that a string "name" is not going to scale at all,
> > > > > as it
> > > > > requires hard-coded information that will change over time (as
> > > > > the
> > > > > existing clock interface is already showing.)
> > > >
> > > > I fully agree that a simple, single string will not scale even in
> > > > some,
> > > > not so uncommon cases, but there is already a lot of existing
> > > > lookup
> > > > solutions over the kernel and so there is no point in introducing
> > > > another one.
> > >
> > > I'm trying to get _rid_ of lookup "solutions" and just use a real
> > > pointer, as you should. I'll go tackle those other ones after this
> > > one
> > > is taken care of, to show how the others should be handled as well.
> >
> > There was a reason for introducing lookup solutions. The re
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 16:53:55 Alan Stern wrote: > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > That's what I was going to suggest too. The struct phy is defined > > > in > > > the board file, which already knows about all the PHYs that exist in > > > the system. (Or perhaps it is allocated dynamically, so that when > > > many > > > board files are present in the same kernel, only the entries listed > > > in > > > the board file for the current system get created.) > > > > Well, such dynamic allocation is a must. We don't accept > > non-multiplatform aware code anymore, not even saying about > > multiboard. > > > > > Then the > > > structure's address is stored in the platform data and made > > > available > > > to both the provider and the consumer. > > > > Yes, technically this can work. You would still have to perform some > > kind of synchronization to make sure that the PHY bound to this > > structure is actually present. This is again technically doable (e.g. > > a list of registered struct phys inside PHY core). > > The synchronization takes place inside phy_get. If phy_create hasn't > been called for this structure by the time phy_get runs, phy_get will > return an error. Yes, this is the solution that I had in mind when saying that this is doable. > > > Even though the struct phy is defined (or allocated) in the board > > > file, > > > its contents don't get filled in until the PHY driver provides the > > > details. > > > > You can't assure this. Board file is free to do whatever it wants with > > this struct. A clean solution would prevent this. > > I'm not sure what you mean here. Of course I can't prevent a board > file from messing up a data structure. I can't prevent it from causing > memory access violations either; in fact, I can't prevent any bugs in > other people's code. > > Besides, why do you say the board file is free to do whatever it wants > with the struct phy? Currently the struct phy is created by the PHY > provider and the PHY core, right? It's not even mentioned in the board > file. I mean, if you have a struct type of which full declaration is available for some code, this code can access any memeber of it without any hacks, which is not something that we want to have in board files. The phy struct should be opaque for them. > > > > It's technically correct, but quality of this solution isn't > > > > really > > > > nice, because it's a layering violation (at least if I understood > > > > what you mean). This is because you need to have full definition > > > > of > > > > struct phy in board file and a structure that is used as private > > > > data > > > > in PHY core comes from platform code. > > > > > > You don't have to have a full definition in the board file. Just a > > > partial definition -- most of the contents can be filled in later, > > > when > > > the PHY driver is ready to store the private data. > > > > > > It's not a layering violation for one region of the kernel to store > > > private data in a structure defined by another part of the kernel. > > > This happens all the time (e.g., dev_set_drvdata). > > > > Not really. The phy struct is something that _is_ private data of PHY > > subsystem, not something that can store private data of PHY subsystem > > (sure it can store private data of particular PHY driver, but that's > > another story) and only PHY subsystem should have access to its > > contents. > If you want to keep the phy struct completely separate from the board > file, there's an easy way to do it. Let's say the board file knows > about N different PHYs in the system. Then you define an array of N > pointers to phys: > > struct phy *(phy_address[N]); > > In the platform data for both PHY j and its controller, store > &phy_address[j]. The PHY provider passes this cookie to phy_create: > > cookie = pdev->dev.platform_data; > ret = phy_create(phy, cookie); > > and phy_create simply stores: *cookie = phy. The PHY consumer does > much the same the same thing: > > cookie = pdev->dev.platform_data; > phy = phy_get(cookie); > > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. OK, this can work. Again, just technically, because it's rather ugly. > > By the way, we need to consider other cases here as well, for example &
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 13:50:07 Greg KH wrote:
> On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> > > On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > > > You don't "know" the id of the device you are looking up, due to
> > > > > multiple devices being in the system (dynamic ids, look back
> > > > > earlier
> > > > > in
> > > > > this thread for details about that.)
> > > >
> > > > I got copied in very late so don't have most of the thread I'm
> > > > afraid,
> > > > I did try looking at web archives but didn't see a clear problem
> > > > statement. In any case this is why the APIs doing lookups do the
> > > > lookups in the context of the requesting device - devices ask for
> > > > whatever name they use locally.
> > >
> > > What do you mean by "locally"?
> > >
> > > The problem with the api was that the phy core wanted a id and a
> > > name to create a phy, and then later other code was doing a
> > > "lookup" based on the name and id (mushed together), because it
> > > "knew" that this device was the one it wanted.
> > >
> > > Just like the clock api, which, for multiple devices, has proven to
> > > cause problems. I don't want to see us accept an api that we know
> > > has
> > > issues in it now, I'd rather us fix it up properly.
> > >
> > > Subsystems should be able to create ids how ever they want to, and
> > > not
> > > rely on the code calling them to specify the names of the devices
> > > that
> > > way, otherwise the api is just too fragile.
> > >
> > > I think, that if you create a device, then just carry around the
> > > pointer to that device (in this case a phy) and pass it to whatever
> > > other code needs it. No need to do lookups on "known names" or
> > > anything else, just normal pointers, with no problems for multiple
> > > devices, busses, or naming issues.
> >
> > PHY object is not a device, it is something that a device driver
> > creates (one or more instances of) when it is being probed.
>
> But you created a 'struct device' for it, so I think of it as a "device"
> be it "virtual" or "real" :)
Keep in mind that those virtual devices are created by PHY driver bound to
a real device and one real device can have multiple virtual devices behind
it.
> > You don't have a clean way to export this PHY object to other driver,
> > other than keeping this PHY on a list inside PHY core with some
> > well-known ID (e.g. device name + consumer port name/index, like in
> > regulator core) and then to use this well-known ID inside consumer
> > driver as a lookup key passed to phy_get();
> >
> > Actually I think for PHY case, exactly the same way as used for
> > regulators might be completely fine:
> >
> > 1. Each PHY would have some kind of platform, non-unique name, that is
> > just used to print some messages (like the platform/board name of a
> > regulator).
> > 2. Each PHY would have an array of consumers. Consumer specifier would
> > consist of consumer device name and consumer port name - just like in
> > regulator subsystem.
> > 3. PHY driver receives an array of, let's say, phy_init_data inside
> > its
> > platform data that it would use to register its PHYs.
> > 4. Consumer drivers would have constant consumer port names and
> > wouldn't receive any information about PHYs from platform code.
> >
> > Code example:
> >
> > [Board file]
> >
> > static const struct phy_consumer_data usb_20_phy0_consumers[] = {
> >
> > {
> >
> > .devname = "foo-ehci",
> > .port = "usbphy",
> >
> > },
> >
> > };
> >
> > static const struct phy_consumer_data usb_20_phy1_consumers[] = {
> >
> > {
> >
> > .devname = "foo-otg",
> > .port = "otgphy",
> >
> > },
> >
> > };
> >
> > static const struct phy_init_data my_phys[] = {
> >
> > {
> >
> > .name = "USB 2.0 PHY 0",
> > .consumers = usb_20_phy0_consumers,
> > .num_consumers = ARRAY_SIZE(usb
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > On Tue, 23 Jul 2013, Tomasz Figa wrote: > > > If you want to keep the phy struct completely separate from the > > > board > > > file, there's an easy way to do it. Let's say the board file knows > > > about N different PHYs in the system. Then you define an array of N > > > pointers to phys: > > > > > > struct phy *(phy_address[N]); > > > > > > In the platform data for both PHY j and its controller, store > > > > > > &phy_address[j]. The PHY provider passes this cookie to phy_create: > > > cookie = pdev->dev.platform_data; > > > ret = phy_create(phy, cookie); > > > > > > and phy_create simply stores: *cookie = phy. The PHY consumer does > > > > > > much the same the same thing: > > > cookie = pdev->dev.platform_data; > > > phy = phy_get(cookie); > > > > > > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. > > > > OK, this can work. Again, just technically, because it's rather ugly. > > There's no reason the phy_address things have to be arrays. A separate > individual pointer for each PHY would work just as well. > > > Where would you want to have those phy_address arrays stored? There > > are no board files when booting with DT. Not even saying that you > > don't need to use any hacky schemes like this when you have DT that > > nicely specifies relations between devices. > > If everybody agrees DT has a nice scheme for specifying relations > between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. > > Anyway, board file should not be considered as a method to exchange > > data between drivers. It should be used only to pass data from it to > > drivers, not the other way. Ideally all data in a board file should > > be marked as const and __init and dropped after system > > initialization. > > The phy_address things don't have to be defined or allocated in the > board file; they could be set up along with the platform data. There is no platform data when booting with DT. > In any case, this was simply meant to be a suggestion to show that it > is relatively easy to do what you need without using name or ID > strings. Sure. It's good to have different options discussed as well. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/8] clk: samsung: pll: Add support for PLL6552 and PLL6553
This patch adds support for PLL6552 and PLL6553 PLLs present on Samsung
S3C64xx SoCs.
Signed-off-by: Tomasz Figa
Acked-by: Mike Turquette
---
drivers/clk/samsung/clk-pll.c | 77 +++
drivers/clk/samsung/clk-pll.h | 2 ++
2 files changed, 79 insertions(+)
Changes since v2:
- Reworked to use new PLL registration method introduced by Yadwinder
Singh Brar's patch series:
( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 )
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index f80efb6..7572d1d 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -438,6 +438,77 @@ struct clk * __init samsung_clk_register_pll46xx(const
char *name,
}
/*
+ * PLL6552 Clock Type
+ */
+
+#define PLL6552_MDIV_MASK 0x3ff
+#define PLL6552_PDIV_MASK 0x3f
+#define PLL6552_SDIV_MASK 0x7
+#define PLL6552_MDIV_SHIFT 16
+#define PLL6552_PDIV_SHIFT 8
+#define PLL6552_SDIV_SHIFT 0
+
+static unsigned long samsung_pll6552_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
+ u32 mdiv, pdiv, sdiv, pll_con;
+ u64 fvco = parent_rate;
+
+ pll_con = __raw_readl(pll->con_reg);
+ mdiv = (pll_con >> PLL6552_MDIV_SHIFT) & PLL6552_MDIV_MASK;
+ pdiv = (pll_con >> PLL6552_PDIV_SHIFT) & PLL6552_PDIV_MASK;
+ sdiv = (pll_con >> PLL6552_SDIV_SHIFT) & PLL6552_SDIV_MASK;
+
+ fvco *= mdiv;
+ do_div(fvco, (pdiv << sdiv));
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6552_clk_ops = {
+ .recalc_rate = samsung_pll6552_recalc_rate,
+};
+
+/*
+ * PLL6553 Clock Type
+ */
+
+#define PLL6553_MDIV_MASK 0xff
+#define PLL6553_PDIV_MASK 0x3f
+#define PLL6553_SDIV_MASK 0x7
+#define PLL6553_KDIV_MASK 0x
+#define PLL6553_MDIV_SHIFT 16
+#define PLL6553_PDIV_SHIFT 8
+#define PLL6553_SDIV_SHIFT 0
+#define PLL6553_KDIV_SHIFT 0
+
+static unsigned long samsung_pll6553_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
+ u32 mdiv, pdiv, sdiv, kdiv, pll_con0, pll_con1;
+ u64 fvco = parent_rate;
+
+ pll_con0 = __raw_readl(pll->con_reg);
+ pll_con1 = __raw_readl(pll->con_reg + 0x4);
+ mdiv = (pll_con0 >> PLL6553_MDIV_SHIFT) & PLL6553_MDIV_MASK;
+ pdiv = (pll_con0 >> PLL6553_PDIV_SHIFT) & PLL6553_PDIV_MASK;
+ sdiv = (pll_con0 >> PLL6553_SDIV_SHIFT) & PLL6553_SDIV_MASK;
+ kdiv = (pll_con1 >> PLL6553_KDIV_SHIFT) & PLL6553_KDIV_MASK;
+
+ fvco *= (mdiv << 16) + kdiv;
+ do_div(fvco, (pdiv << sdiv));
+ fvco >>= 16;
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6553_clk_ops = {
+ .recalc_rate = samsung_pll6553_recalc_rate,
+};
+
+/*
* PLL2550x Clock Type
*/
@@ -572,6 +643,12 @@ static void __init _samsung_clk_register_pll(struct
samsung_pll_clock *pll_clk,
else
init.ops = &samsung_pll36xx_clk_ops;
break;
+ case pll_6552:
+ init.ops = &samsung_pll6552_clk_ops;
+ break;
+ case pll_6553:
+ init.ops = &samsung_pll6553_clk_ops;
+ break;
default:
pr_warn("%s: Unknown pll type for pll clk %s\n",
__func__, pll_clk->name);
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index 95ae23d..cd11037 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -17,6 +17,8 @@ enum samsung_pll_type {
pll_36xx,
pll_2550,
pll_2650,
+ pll_6552,
+ pll_6553,
};
#define PLL_35XX_RATE(_rate, _m, _p, _s) \
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/8] clk: samsung: Add clock driver for S3C64xx SoCs
This patch adds new, Common Clock Framework-based clock driver for Samsung
S3C64xx SoCs. The driver is just added, without actually letting the
platforms use it yet, since this requires more intermediate steps.
Signed-off-by: Tomasz Figa
Acked-by: Mike Turquette
---
.../bindings/clock/samsung,s3c64xx-clock.txt | 77
drivers/clk/samsung/Makefile | 3 +
drivers/clk/samsung/clk-s3c64xx.c | 473 +
include/dt-bindings/clock/samsung,s3c64xx-clock.h | 178
4 files changed, 731 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
create mode 100644 drivers/clk/samsung/clk-s3c64xx.c
create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h
Changes since v2:
- Reworked to use new PLL registration method introduced by Yadwinder
Singh Brar's patch series:
( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 )
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
new file mode 100644
index 000..fa171dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
@@ -0,0 +1,77 @@
+* Samsung S3C64xx Clock Controller
+
+The S3C64xx clock controller generates and supplies clock to various
controllers
+within the SoC. The clock binding described here is applicable to all SoCs in
+the S3C64xx family.
+
+Required Properties:
+
+- compatible: should be one of the following.
+ - "samsung,s3c6400-clock" - controller compatible with S3C6400 SoC.
+ - "samsung,s3c6410-clock" - controller compatible with S3C6410 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular S3C64xx SoC and this is specified where applicable.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/samsung,s3c64xx-clock.h header and can be used in device
+tree sources.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "fin_pll" - PLL input clock (xtal/extclk) - required,
+ - "xusbxti" - USB xtal - required,
+ - "iiscdclk0" - I2S0 codec clock - optional,
+ - "iiscdclk1" - I2S1 codec clock - optional,
+ - "iiscdclk2" - I2S2 codec clock - optional,
+ - "pcmcdclk0" - PCM0 codec clock - optional,
+ - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
+
+Example: Clock controller node:
+
+ clock: clock-controller@7e00f000 {
+ compatible = "samsung,s3c6410-clock";
+ reg = <0x7e00f000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+Example: Required external clocks:
+
+ fin_pll: clock-fin-pll {
+ compatible = "fixed-clock";
+ clock-output-names = "fin_pll";
+ clock-frequency = <1200>;
+ #clock-cells = <0>;
+ };
+
+ xusbxti: clock-xusbxti {
+ compatible = "fixed-clock";
+ clock-output-names = "xusbxti";
+ clock-frequency = <4800>;
+ #clock-cells = <0>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller (refer to the standard clock bindings for information about
+ "clocks" and "clock-names" properties):
+
+ uart0: serial@7f005000 {
+ compatible = "samsung,s3c6400-uart";
+ reg = <0x7f005000 0x100>;
+ interrupt-parent = <&vic1>;
+ interrupts = <5>;
+ clock-names = "uart", "clk_uart_baud2",
+ "clk_uart_baud3";
+ clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>,
+ <&clock SCLK_UART>;
+ status = "disabled";
+ };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 5d4d432..3413380 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -8,3 +8,6 @@ obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
+ifdef CONFIG_COMMON_CLK
+obj-$(CONFIG_ARCH_S3C64XX) += clk-s3c64xx.o
+endif
dif
Re: [PATCH v2 1/8] clk: mux: Add support for read-only muxes.
Hi Mike,
On Tuesday 23 of July 2013 01:49:18 Tomasz Figa wrote:
> Some platforms have read-only clock muxes that are preconfigured at
> reset and cannot be changed at runtime. This patch extends mux clock
> driver to allow handling such read-only muxes by adding new
> CLK_MUX_READ_ONLY mux flag.
>
> Signed-off-by: Tomasz Figa
> ---
> drivers/clk/clk-mux.c| 10 +-
> include/linux/clk-provider.h | 2 ++
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
> index 61c..92f1a1b 100644
> --- a/drivers/clk/clk-mux.c
> +++ b/drivers/clk/clk-mux.c
> @@ -107,6 +107,11 @@ const struct clk_ops clk_mux_ops = {
> };
> EXPORT_SYMBOL_GPL(clk_mux_ops);
>
> +const struct clk_ops clk_mux_ro_ops = {
> + .get_parent = clk_mux_get_parent,
> +};
> +EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
> +
> struct clk *clk_register_mux_table(struct device *dev, const char
> *name, const char **parent_names, u8 num_parents, unsigned long flags,
> void __iomem *reg, u8 shift, u32 mask,
> @@ -133,7 +138,10 @@ struct clk *clk_register_mux_table(struct device
> *dev, const char *name, }
>
> init.name = name;
> - init.ops = &clk_mux_ops;
> + if (clk_mux_flags & CLK_MUX_READ_ONLY)
> + init.ops = &clk_mux_ro_ops;
> + else
> + init.ops = &clk_mux_ops;
> init.flags = flags | CLK_IS_BASIC;
> init.parent_names = parent_names;
> init.num_parents = num_parents;
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 1ec14a7..9487b96 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -327,8 +327,10 @@ struct clk_mux {
> #define CLK_MUX_INDEX_ONEBIT(0)
> #define CLK_MUX_INDEX_BITBIT(1)
> #define CLK_MUX_HIWORD_MASK BIT(2)
> +#define CLK_MUX_READ_ONLYBIT(3) /* mux setting cannot be changed */
>
> extern const struct clk_ops clk_mux_ops;
> +extern const struct clk_ops clk_mux_ro_ops;
>
> struct clk *clk_register_mux(struct device *dev, const char *name,
> const char **parent_names, u8 num_parents, unsigned long
flags,
What do you think about this?
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/8] clk: samsung: pll: Add support for PLL6552 and PLL6553
On Sunday 28 of July 2013 13:30:51 Mark Brown wrote: > On Wed, Jul 24, 2013 at 01:52:19AM +0200, Tomasz Figa wrote: > > Changes since v2: > > - Reworked to use new PLL registration method introduced by Yadwinder > > > >Singh Brar's patch series: > >( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 ) > > I'm not able to test this series since that lot isn't in -next and I > didn't get a copy. Hmm, I wonder what happened with that series, as Mike was supposed to try applying it to clk tree [1]. Mike, could you shed some light on this? Best regards, Tomasz [1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041/focus=21003 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/8] usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare
Alan, Greg,
On Tuesday 23 of July 2013 01:49:23 Tomasz Figa wrote:
> This patch modifies the ohci-s3c2410 driver to prepare and unprepare
> clocks in addition to enabling and disabling, since it is required
> by common clock framework.
>
> Signed-off-by: Tomasz Figa
> ---
> drivers/usb/host/ohci-s3c2410.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-s3c2410.c
> b/drivers/usb/host/ohci-s3c2410.c index e125770..db096bf 100644
> --- a/drivers/usb/host/ohci-s3c2410.c
> +++ b/drivers/usb/host/ohci-s3c2410.c
> @@ -47,10 +47,10 @@ static void s3c2410_start_hc(struct platform_device
> *dev, struct usb_hcd *hcd)
>
> dev_dbg(&dev->dev, "s3c2410_start_hc:\n");
>
> - clk_enable(usb_clk);
> + clk_prepare_enable(usb_clk);
> mdelay(2); /* let the bus clock stabilise */
>
> - clk_enable(clk);
> + clk_prepare_enable(clk);
>
> if (info != NULL) {
> info->hcd = hcd;
> @@ -75,8 +75,8 @@ static void s3c2410_stop_hc(struct platform_device
> *dev) (info->enable_oc)(info, 0);
> }
>
> - clk_disable(clk);
> - clk_disable(usb_clk);
> + clk_disable_unprepare(clk);
> + clk_disable_unprepare(usb_clk);
> }
>
> /* ohci_s3c2410_hub_status_data
Any chance to get your ack on this?
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] Common Clock Framework support for Samsung S3C64xx
On Monday 05 of August 2013 12:02:16 Mike Turquette wrote: > Quoting Kukjin Kim (2013-08-05 11:13:55) > > > On 08/06/13 03:06, Mike Turquette wrote: > > > Quoting Kukjin Kim (2013-08-05 10:01:36) > > > > > >> On 07/23/13 08:49, Tomasz Figa wrote: > > >>> This series is an attempt to move clock support on Samsung S3C64xx > > >>> SoCs > > >>> to Common Clock Framework. > > >>> > > >>> First, support for PLL types present on S3C64xx SoCs is added to > > >>> Samsung Common Clock Framework driver. Then the main clock driver > > >>> for mentioned SoCs is introduced. Further patches contain fixes > > >>> for drivers to make them compliant with CCF semantics, migration > > >>> of platform code to use the new clock driver and removal of old > > >>> clock management code. > > >>> > > >>> Depends on: > > >>>- [PATCH v4 00/20] Samsung PWM support cleanup > > >>> > > >>> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20856 > > >>> > > >>> On S3C6410-based Tiny6410 board (Mini6410-compatible): > > >>> > > >>> Tested-by: Tomasz Figa > > >>> > > >>> For v1: > > >>> > > >>> Acked-by: Mike Turquette > > >>> > > >>> Changes since v1: > > >>>- added patch for read-only muxes, > > >>>- exported configurable muxes and dividers, > > >>>- defined mout_syncmux as read-only mux, > > >>>- in DT-enabled case fixed-clock binding is used to define > > >>>external clocks.> >>> > > >>> Tomasz Figa (8): > > >>> clk: mux: Add support for read-only muxes. > > >>> clk: samsung: pll: Add support for PLL6552 and PLL6553 > > >>> clk: samsung: Add clock driver for S3C64xx SoCs > > >>> ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros > > >>> ARM: s3c64xx: dma: Use > > >>> clk_prepare_enable/clk_disable_unprepare > > >>> usb: host: ohci-s3c2410 Use > > >>> clk_prepare_enable/clk_disable_unprepare > > >>> ARM: s3c64xx: Migrate clock handling to Common Clock Framework > > >>> ARM: s3c64xx: Remove old clock management code > > >>> > > >>>.../bindings/clock/samsung,s3c64xx-clock.txt | 77 ++ > > >>>arch/arm/Kconfig |2 +- > > >>>arch/arm/mach-s3c64xx/Makefile |2 +- > > >>>arch/arm/mach-s3c64xx/clock.c | 1007 > > >>> arch/arm/mach-s3c64xx/common.c > > >>> | 21 +- > > >>>arch/arm/mach-s3c64xx/common.h | 12 +- > > >>>arch/arm/mach-s3c64xx/dma.c|4 +- > > >>>arch/arm/mach-s3c64xx/include/mach/regs-clock.h| 132 +-- > > >>>arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- > > >>>arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- > > >>>arch/arm/mach-s3c64xx/mach-hmt.c |2 +- > > >>>arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- > > >>>arch/arm/mach-s3c64xx/mach-ncp.c |2 +- > > >>>arch/arm/mach-s3c64xx/mach-smartq.c| 11 +- > > >>>arch/arm/mach-s3c64xx/mach-smdk6400.c |2 +- > > >>>arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- > > >>>arch/arm/mach-s3c64xx/pm.c | 21 - > > >>>arch/arm/mach-s3c64xx/s3c6400.c|6 - > > >>>arch/arm/mach-s3c64xx/s3c6410.c|7 - > > >>>arch/arm/plat-samsung/include/plat/cpu.h |4 + > > >>>drivers/clk/clk-mux.c | 10 +- > > >>>drivers/clk/samsung/Makefile |1 + > > >>>drivers/clk/samsung/clk-pll.c | 160 > > >>>drivers/clk/samsung/clk-pll.h |4 + > > >>>drivers/clk/samsung/clk-s3c64xx.c | 465 > > >>>+ > > >>>drivers/usb/ho
Re: [PATCH v2 0/8] Common Clock Framework support for Samsung S3C64xx
On Tuesday 06 of August 2013 12:47:51 Mike Turquette wrote: > Quoting Tomasz Figa (2013-08-05 16:42:16) > > > On Monday 05 of August 2013 12:02:16 Mike Turquette wrote: > > > Quoting Kukjin Kim (2013-08-05 11:13:55) > > > > > > > On 08/06/13 03:06, Mike Turquette wrote: > > > > > Quoting Kukjin Kim (2013-08-05 10:01:36) > > > > > > > > > >> On 07/23/13 08:49, Tomasz Figa wrote: > > > > >>> This series is an attempt to move clock support on Samsung > > > > >>> S3C64xx > > > > >>> SoCs > > > > >>> to Common Clock Framework. > > > > >>> > > > > >>> First, support for PLL types present on S3C64xx SoCs is added > > > > >>> to > > > > >>> Samsung Common Clock Framework driver. Then the main clock > > > > >>> driver > > > > >>> for mentioned SoCs is introduced. Further patches contain > > > > >>> fixes > > > > >>> for drivers to make them compliant with CCF semantics, > > > > >>> migration > > > > >>> of platform code to use the new clock driver and removal of > > > > >>> old > > > > >>> clock management code. > > > > >>> > > > > >>> Depends on: > > > > >>>- [PATCH v4 00/20] Samsung PWM support cleanup > > > > >>> > > > > >>> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20 > > > > >>> 856 > > > > >>> > > > > >>> On S3C6410-based Tiny6410 board (Mini6410-compatible): > > > > >>> > > > > >>> Tested-by: Tomasz Figa > > > > >>> > > > > >>> For v1: > > > > >>> > > > > >>> Acked-by: Mike Turquette > > > > >>> > > > > >>> Changes since v1: > > > > >>>- added patch for read-only muxes, > > > > >>>- exported configurable muxes and dividers, > > > > >>>- defined mout_syncmux as read-only mux, > > > > >>>- in DT-enabled case fixed-clock binding is used to define > > > > >>>external clocks.> >>> > > > > >>> > > > > >>> Tomasz Figa (8): > > > > >>> clk: mux: Add support for read-only muxes. > > > > >>> clk: samsung: pll: Add support for PLL6552 and PLL6553 > > > > >>> clk: samsung: Add clock driver for S3C64xx SoCs > > > > >>> ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros > > > > >>> ARM: s3c64xx: dma: Use > > > > >>> clk_prepare_enable/clk_disable_unprepare > > > > >>> usb: host: ohci-s3c2410 Use > > > > >>> clk_prepare_enable/clk_disable_unprepare > > > > >>> ARM: s3c64xx: Migrate clock handling to Common Clock > > > > >>> Framework > > > > >>> ARM: s3c64xx: Remove old clock management code > > > > >>> > > > > >>>.../bindings/clock/samsung,s3c64xx-clock.txt | 77 > > > > >>>++ > > > > >>>arch/arm/Kconfig |2 > > > > >>>+- > > > > >>>arch/arm/mach-s3c64xx/Makefile |2 > > > > >>>+- > > > > >>>arch/arm/mach-s3c64xx/clock.c | 1007 > > > > >>> arch/arm/mach-s3c64xx/common.c > > > > >>> > > > > >>> | 21 +- > > > > >>> > > > > >>>arch/arm/mach-s3c64xx/common.h | 12 > > > > >>>+- > > > > >>>arch/arm/mach-s3c64xx/dma.c|4 > > > > >>>+- > > > > >>>arch/arm/mach-s3c64xx/include/mach/regs-clock.h| 132 > > > > >>>+-- > > > > >>>arch/arm/mach-s3c64xx/mach-anw6410.c |2 > > > > >>>+- > > > > >>>arch/arm/mach-s3c64xx/mach-crag6410.c |2 > > > > >>>+- > > >
Re: [PATCH v2 0/8] Common Clock Framework support for Samsung S3C64xx
On Wednesday 07 of August 2013 07:11:40 Kukjin Kim wrote: > On 08/07/13 07:06, Tomasz Figa wrote: > > On Tuesday 06 of August 2013 12:47:51 Mike Turquette wrote: > >> Quoting Tomasz Figa (2013-08-05 16:42:16) > >> > >>> On Monday 05 of August 2013 12:02:16 Mike Turquette wrote: > >>>> Quoting Kukjin Kim (2013-08-05 11:13:55) > >>>> > >>>>> On 08/06/13 03:06, Mike Turquette wrote: > >>>>>> Quoting Kukjin Kim (2013-08-05 10:01:36) > >>>>>> > >>>>>>> On 07/23/13 08:49, Tomasz Figa wrote: > >>>>>>>> This series is an attempt to move clock support on Samsung > >>>>>>>> S3C64xx > >>>>>>>> SoCs > >>>>>>>> to Common Clock Framework. > >>>>>>>> > >>>>>>>> First, support for PLL types present on S3C64xx SoCs is added > >>>>>>>> to > >>>>>>>> Samsung Common Clock Framework driver. Then the main clock > >>>>>>>> driver > >>>>>>>> for mentioned SoCs is introduced. Further patches contain > >>>>>>>> fixes > >>>>>>>> for drivers to make them compliant with CCF semantics, > >>>>>>>> migration > >>>>>>>> of platform code to use the new clock driver and removal of > >>>>>>>> old > >>>>>>>> clock management code. > >>>>>>>> > >>>>>>>> Depends on: > >>>>>>>> - [PATCH v4 00/20] Samsung PWM support cleanup > >>>>>>>> > >>>>>>>> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20 > >>>>>>>> 856 > >>>>>>>> > >>>>>>>> On S3C6410-based Tiny6410 board (Mini6410-compatible): > >>>>>>>> > >>>>>>>> Tested-by: Tomasz Figa > >>>>>>>> > >>>>>>>> For v1: > >>>>>>>> > >>>>>>>> Acked-by: Mike Turquette > >>>>>>>> > >>>>>>>> Changes since v1: > >>>>>>>> - added patch for read-only muxes, > >>>>>>>> - exported configurable muxes and dividers, > >>>>>>>> - defined mout_syncmux as read-only mux, > >>>>>>>> - in DT-enabled case fixed-clock binding is used to define > >>>>>>>> external clocks.> >>> > >>>>>>>> > >>>>>>>> Tomasz Figa (8): > >>>>>>>> clk: mux: Add support for read-only muxes. > >>>>>>>> clk: samsung: pll: Add support for PLL6552 and PLL6553 > >>>>>>>> clk: samsung: Add clock driver for S3C64xx SoCs > >>>>>>>> ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros > >>>>>>>> ARM: s3c64xx: dma: Use > >>>>>>>> clk_prepare_enable/clk_disable_unprepare > >>>>>>>> usb: host: ohci-s3c2410 Use > >>>>>>>> clk_prepare_enable/clk_disable_unprepare > >>>>>>>> ARM: s3c64xx: Migrate clock handling to Common Clock > >>>>>>>> Framework > >>>>>>>> ARM: s3c64xx: Remove old clock management code > >>>>>>>> > >>>>>>>> .../bindings/clock/samsung,s3c64xx-clock.txt | 77 > >>>>>>>> ++ > >>>>>>>> arch/arm/Kconfig |2 > >>>>>>>> +- > >>>>>>>> arch/arm/mach-s3c64xx/Makefile |2 > >>>>>>>> +- > >>>>>>>> arch/arm/mach-s3c64xx/clock.c | 1007 > >>>>>>>> arch/arm/mach-s3c64xx/common.c > >>>>>>>> > >>>>>>>> | 21 +- > >>>>>>>> > >>>>>>>> arch/arm/mach-s3c64xx/common.h | 12 > >>>>>>>> +- > &
Re: [PATCH 1/3 v5] usb: phy-samsung-usb: Simplify PMU register handling
Hi Julius, On Thursday 08 of August 2013 11:06:54 Julius Werner wrote: > > I'm not sure I understand. The old documentation referred to the > > USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and > > your new version only refers to (usb device) PHY_CONTROL. Regardless > > of > > multiple phys, you're suggesting that we describe less of each phy. > > That seems like taking away usable information. Unless I've > > misunderstood? > > Well that's just the thing that's confusing right now, and which I am > trying to fix: every PHY is either DEVICE or HOST and thus has only > one PMU register. The current code describes the PMU register space > for all PHYs on the system in the DT entry of every PHY and then > calculates which register to use with hardcoded offsets. I think it > makes much more sense if every PHY only describes its own register and > doesn't need to do address arithmetic later on. > > As Vivek said there is one exception in an old Exynos4, Not that old yet. :) > but that is > currently not implemented in the upstream kernel anyway Sorry, I don't understand what is not implemented. Without your patch, the PHY driver handles both PMU registers of Exynos4. Best regards, Tomasz > , and if it > ever will be it's still much easier to special case one weird chip > than to have a super complicated and confusing mechanism for all of > them. > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 6/6] USB: OHCI: make ohci-s3c2410 a separate driver
Hi Manjunath,
On Saturday 10 of August 2013 13:07:36 Manjunath Goudar wrote:
> Separate the Samsung OHCI S3C host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.12.
>
> Signed-off-by: Manjunath Goudar
> Signed-off-by: Deepak Saxena
> Acked-by: Alan Stern
> Cc: Arnd Bergmann
> Cc: Greg KH
> Cc: linux-usb@vger.kernel.org
>
> V2:
> -Set non-standard fields in ohci_s3c2410_hc_driver manually, rather
> than relying on an expanded struct ohci_driver_overrides.
> -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
> relying on ohci_hub_control and hub_status_data being exported.
>
> V3:
> -Kconfig wrong parentheses discription fixed.
> -ohci_setup() has been removed because it is called in .reset member
> of the ohci_hc_driver structure.
>
> V4:
> - Removed extra space before the '='.
> - Moved /* forward definitions */ line before the declarations of
> functions. ---
> drivers/usb/host/Kconfig|8 +++
> drivers/usb/host/Makefile |1 +
> drivers/usb/host/ohci-hcd.c | 18 --
> drivers/usb/host/ohci-s3c2410.c | 128
> +-- 4 files changed, 66
> insertions(+), 89 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 693560a..795d14d 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
>Enables support for the on-chip OHCI controller on
>ST SPEAr chips.
>
> +config USB_OHCI_HCD_S3C
> +tristate "Support for S3C on-chip OHCI USB controller"
As far as I remember, you were supposed to keep the original name of this
driver, as I suggested in previous iteration of this patch and you agreed.
S3C is totally confusing when it's about Samsung SoC naming.
So here the config entry would be USB_OHCI_HCD_S3C2410 and I would call it
"OHCI support for Samsung S3C24xx/S3C64xx SoC series".
> +depends on USB_OHCI_HCD && (ARCH_S3C24XX || ARCH_S3C64XX)
> +default y
> +---help---
> + Enables support for the on-chip OHCI controller on
> + S3C chips.
S3C24xx/S3C64xx chips
> +
> config USB_OHCI_HCD_AT91
> tristate "Support for Atmel on-chip OHCI USB controller"
> depends on USB_OHCI_HCD && ARCH_AT91
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index a0ac663..d3e9e66 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -49,6 +49,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP1)+= ohci-omap.o
> obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o
> obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o
> obj-$(CONFIG_USB_OHCI_HCD_AT91) += ohci-at91.o
> +obj-$(CONFIG_USB_OHCI_HCD_S3C) += ohci-s3c2410.o
CONFIG_USB_OHCI_HCD_S3C2410
>
> obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
> obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index b48c892..b69a49e 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -1177,11 +1177,6 @@ MODULE_LICENSE ("GPL");
> #define SA_DRIVERohci_hcd_sa_driver
> #endif
>
> -#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
> -#include "ohci-s3c2410.c"
> -#define S3C2410_PLATFORM_DRIVER ohci_hcd_s3c2410_driver
> -#endif
> -
> #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
> #include "ohci-pxa27x.c"
> #define PLATFORM_DRIVER ohci_hcd_pxa27x_driver
> @@ -1293,12 +1288,6 @@ static int __init ohci_hcd_mod_init(void)
> goto error_tmio;
> #endif
>
> -#ifdef S3C2410_PLATFORM_DRIVER
> - retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
> - if (retval < 0)
> - goto error_s3c2410;
> -#endif
> -
> #ifdef EP93XX_PLATFORM_DRIVER
> retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
> if (retval < 0)
> @@ -1332,10 +1321,6 @@ static int __init ohci_hcd_mod_init(void)
> platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
> error_ep93xx:
> #endif
> -#ifdef S3C2410_PLATFORM_DRIVER
> - platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
> - error_s3c2410:
> -#endif
> #ifdef TMIO_OHCI_DRIVER
> platform_driver_unregister(&TMIO_OHCI_DRIVER);
> error_tmio:
> @@ -1382,9 +1367,6 @@ static void __exit ohci_hcd_mod_exit(void)
> #ifdef EP93XX_PLATFORM_DRIVER
> platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
> #endif
> -#ifdef S3C2410_PLATFORM_DRIVER
> - platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
> -#endif
> #ifdef TMIO_OHCI_DRIVER
> platform_driver_unregister(&TMIO_OHCI_DRIVER);
> #endif
> diff --git a/drivers/usb/host/ohci-s3c2410.c
> b/drivers/usb/host/ohci-s3c2410.c index e125770..48b5948 100644
> --- a/drivers/usb/host/ohci-s3c24
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
> >>> IMHO we need a lookup method for PHYs, just like for clocks,
> >>> regulators, PWMs or even i2c busses because there are complex
> >>> cases
> >>> when passing just a name using platform data will not work. I
> >>> would
> >>> second what Stephen said [1] and define a structure doing things
> >>> in a
> >>> DT-like way.
> >>>
> >>> Example;
> >>>
> >>> [platform code]
> >>>
> >>> static const struct phy_lookup my_phy_lookup[] = {
> >>>
> >>> PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
> >>
> >> The only problem here is that if *PLATFORM_DEVID_AUTO* is used
> >> while
> >> creating the device, the ids in the device name would change and
> >> PHY_LOOKUP wont be useful.
> >
> > I don't think this is a problem. All the existing lookup methods
> > already
> > use ID to identify devices (see regulators, clkdev, PWMs, i2c,
> > ...). You
> > can simply add a requirement that the ID must be assigned manually,
> > without using PLATFORM_DEVID_AUTO to use PHY lookup.
>
> And I'm saying that this idea, of using a specific name and id, is
> frought with fragility and will break in the future in various ways
> when
> devices get added to systems, making these strings constantly have
> to be
> kept up to date with different board configurations.
>
> People, NEVER, hardcode something like an id. The fact that this
> happens today with the clock code, doesn't make it right, it makes
> the
> clock code wrong. Others have already said that this is wrong there
> as
> well, as systems change and dynamic ids get used more and more.
>
> Let's not repeat the same mistakes of the past just because we
> refuse to
> learn from them...
>
> So again, the "find a phy by a string" functions should be removed,
> the
> device id should be automatically created by the phy core just to
> make
> things unique in sysfs, and no driver code should _ever_ be reliant
> on
> the number that is being created, and the pointer to the phy
> structure
> should be used everywhere instead.
>
> With those types of changes, I will consider merging this subsystem,
> but
> without them, sorry, I will not.
> >>>
> >>> I'll agree with Greg here, the very fact that we see people trying to
> >>> add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
> >>> to a
> >>> big problem in the framework.
> >>>
> >>> The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
> >>> adding similar infrastructure to the driver themselves to make sure
> >>> we
> >>> don't end up with duplicate names in sysfs in case we have multiple
> >>> instances of the same IP in the SoC (or several of the same PCIe
> >>> card).
> >>> I really don't want to go back to that.
> >>
> >> If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
> >> give the correct binding information to the PHY framework. I think we
> >> can drop having this non-dt support in PHY framework? I see only one
> >> platform (OMAP3) going to be needing this non-dt support and we can
> >> use the USB PHY library for it.>
> > you shouldn't drop support for non-DT platform, in any case we lived
> > without DT (and still do) for years. Gotta find a better way ;-)
>
> hmm..
>
> how about passing the device names of PHY in platform data of the
> controller? It should be deterministic as the PHY framework assigns its
> own id and we *don't* want to add any requirement that the ID must be
> assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
> *phy_init_data* in the v10 patch series.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
> W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
> > On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
> >> On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
> >>> On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
> >>>> On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
wrote:
> >>>>>>>>>> IMHO we need a lookup method for PHYs, just like for clocks,
> >>>>>>>>>> regulators, PWMs or even i2c busses because there are complex
> >>>>>>>>>> cases
> >>>>>>>>>> when passing just a name using platform data will not work. I
> >>>>>>>>>> would
> >>>>>>>>>> second what Stephen said [1] and define a structure doing
> >>>>>>>>>> things
> >>>>>>>>>> in a
> >>>>>>>>>> DT-like way.
> >>>>>>>>>>
> >>>>>>>>>> Example;
> >>>>>>>>>>
> >>>>>>>>>> [platform code]
> >>>>>>>>>>
> >>>>>>>>>> static const struct phy_lookup my_phy_lookup[] = {
> >>>>>>>>>>
> >>>>>>>>>>PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1",
> >>>>>>>>>>"phy.2"),
> >>>>>>>>>
> >>>>>>>>> The only problem here is that if *PLATFORM_DEVID_AUTO* is used
> >>>>>>>>> while
> >>>>>>>>> creating the device, the ids in the device name would change
> >>>>>>>>> and
> >>>>>>>>> PHY_LOOKUP wont be useful.
> >>>>>>>>
> >>>>>>>> I don't think this is a problem. All the existing lookup
> >>>>>>>> methods
> >>>>>>>> already
> >>>>>>>> use ID to identify devices (see regulators, clkdev, PWMs, i2c,
> >>>>>>>> ...). You
> >>>>>>>> can simply add a requirement that the ID must be assigned
> >>>>>>>> manually,
> >>>>>>>> without using PLATFORM_DEVID_AUTO to use PHY lookup.
> >>>>>>>
> >>>>>>> And I'm saying that this idea, of using a specific name and id,
> >>>>>>> is
> >>>>>>> frought with fragility and will break in the future in various
> >>>>>>> ways
> >>>>>>> when
> >>>>>>> devices get added to systems, making these strings constantly
> >>>>>>> have
> >>>>>>> to be
> >>>>>>> kept up to date with different board configurations.
> >>>>>>>
> >>>>>>> People, NEVER, hardcode something like an id. The fact that
> >>>>>>> this
> >>>>>>> happens today with the clock code, doesn't make it right, it
> >>>>>>> makes
> >>>>>>> the
> >>>>>>> clock code wrong. Others have already said that this is wrong
> >>>>>>> there
> >>>>>>> as
> >>>>>>> well, as systems change and dynamic ids get used more and more.
> >>>>>>>
> >>>>>>> Let's not repeat the same mistakes of the past just because we
> >>>>>>> refuse to
> >>>>>>> learn from them...
> >>>>>>>
> >>>>>>> So again, the "find a phy by a string" functions should be
> >>>>>>> removed,
> >>>>>>> the
> >>>>>>> device id should be automatically created by the phy core just
> >>>>>>> to
> >>>>>>> make
> >>>>>>> things unique in sysfs, and no driver code should _ever_ be
> >>>>>>> reliant
> >>>>>>> on
> >>>>>>> the number that is being created, and the pointer to the phy
> >>>>>>> structure
> >>>>>>> should be used everyw
Re: [PATCH v2 0/8] Common Clock Framework support for Samsung S3C64xx
Hi Mike, On Monday 05 of August 2013 11:06:25 Mike Turquette wrote: > Quoting Kukjin Kim (2013-08-05 10:01:36) > > > On 07/23/13 08:49, Tomasz Figa wrote: > > > This series is an attempt to move clock support on Samsung S3C64xx > > > SoCs > > > to Common Clock Framework. > > > > > > First, support for PLL types present on S3C64xx SoCs is added to > > > Samsung > > > Common Clock Framework driver. Then the main clock driver for > > > mentioned > > > SoCs is introduced. Further patches contain fixes for drivers to make > > > them compliant with CCF semantics, migration of platform code to use > > > the new clock driver and removal of old clock management code. > > > > > > Depends on: > > > - [PATCH v4 00/20] Samsung PWM support cleanup > > > > > > http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20856 > > > > > > On S3C6410-based Tiny6410 board (Mini6410-compatible): > > > > > > Tested-by: Tomasz Figa > > > > > > For v1: > > > > > > Acked-by: Mike Turquette > > > > > > Changes since v1: > > > - added patch for read-only muxes, > > > - exported configurable muxes and dividers, > > > - defined mout_syncmux as read-only mux, > > > - in DT-enabled case fixed-clock binding is used to define external > > > clocks.> > > > > Tomasz Figa (8): > > >clk: mux: Add support for read-only muxes. > > >clk: samsung: pll: Add support for PLL6552 and PLL6553 > > >clk: samsung: Add clock driver for S3C64xx SoCs > > >ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros > > >ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare > > >usb: host: ohci-s3c2410 Use > > >clk_prepare_enable/clk_disable_unprepare > > >ARM: s3c64xx: Migrate clock handling to Common Clock Framework > > >ARM: s3c64xx: Remove old clock management code > > > > > > .../bindings/clock/samsung,s3c64xx-clock.txt | 77 ++ > > > arch/arm/Kconfig |2 +- > > > arch/arm/mach-s3c64xx/Makefile |2 +- > > > arch/arm/mach-s3c64xx/clock.c | 1007 > > > arch/arm/mach-s3c64xx/common.c > > >| 21 +- > > > arch/arm/mach-s3c64xx/common.h | 12 +- > > > arch/arm/mach-s3c64xx/dma.c|4 +- > > > arch/arm/mach-s3c64xx/include/mach/regs-clock.h| 132 +-- > > > arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- > > > arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- > > > arch/arm/mach-s3c64xx/mach-hmt.c |2 +- > > > arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- > > > arch/arm/mach-s3c64xx/mach-ncp.c |2 +- > > > arch/arm/mach-s3c64xx/mach-smartq.c| 11 +- > > > arch/arm/mach-s3c64xx/mach-smdk6400.c |2 +- > > > arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- > > > arch/arm/mach-s3c64xx/pm.c | 21 - > > > arch/arm/mach-s3c64xx/s3c6400.c|6 - > > > arch/arm/mach-s3c64xx/s3c6410.c|7 - > > > arch/arm/plat-samsung/include/plat/cpu.h |4 + > > > drivers/clk/clk-mux.c | 10 +- > > > drivers/clk/samsung/Makefile |1 + > > > drivers/clk/samsung/clk-pll.c | 160 > > > drivers/clk/samsung/clk-pll.h |4 + > > > drivers/clk/samsung/clk-s3c64xx.c | 465 + > > > drivers/usb/host/ohci-s3c2410.c|8 +- > > > include/dt-bindings/clock/samsung,s3c64xx-clock.h | 178 > > > include/linux/clk-provider.h |2 + > > > 28 files changed, 943 insertions(+), 1205 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt > > > delete mode 100644 arch/arm/mach-s3c64xx/clock.c > > > create mode 100644 drivers/clk/samsung/clk-s3c64xx.c > > > create mode 100644 > > > include/dt-bindings/clock/samsung,s3c64xx-clock.h > > > > Basically, this series looks good to me, but I'm not sure how this > > should be handled because of d
Re: [PATCH v2 0/8] Common Clock Framework support for Samsung S3C64xx
On Friday 16 of August 2013 14:02:03 Mike Turquette wrote: > Quoting Tomasz Figa (2013-08-16 03:44:44) > > > Hi Mike, > > > > On Monday 05 of August 2013 11:06:25 Mike Turquette wrote: > > > Quoting Kukjin Kim (2013-08-05 10:01:36) > > > > > > > On 07/23/13 08:49, Tomasz Figa wrote: > > > > > This series is an attempt to move clock support on Samsung > > > > > S3C64xx > > > > > SoCs > > > > > to Common Clock Framework. > > > > > > > > > > First, support for PLL types present on S3C64xx SoCs is added to > > > > > Samsung > > > > > Common Clock Framework driver. Then the main clock driver for > > > > > mentioned > > > > > SoCs is introduced. Further patches contain fixes for drivers to > > > > > make > > > > > them compliant with CCF semantics, migration of platform code to > > > > > use > > > > > the new clock driver and removal of old clock management code. > > > > > > > > > > Depends on: > > > > > - [PATCH v4 00/20] Samsung PWM support cleanup > > > > > > > > > > http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20856 > > > > > > > > > > On S3C6410-based Tiny6410 board (Mini6410-compatible): > > > > > > > > > > Tested-by: Tomasz Figa > > > > > > > > > > For v1: > > > > > > > > > > Acked-by: Mike Turquette > > > > > > > > > > Changes since v1: > > > > > - added patch for read-only muxes, > > > > > - exported configurable muxes and dividers, > > > > > - defined mout_syncmux as read-only mux, > > > > > - in DT-enabled case fixed-clock binding is used to define > > > > > external > > > > > clocks.> > > > > > > > > > > > Tomasz Figa (8): > > > > >clk: mux: Add support for read-only muxes. > > > > >clk: samsung: pll: Add support for PLL6552 and PLL6553 > > > > >clk: samsung: Add clock driver for S3C64xx SoCs > > > > >ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros > > > > >ARM: s3c64xx: dma: Use > > > > >clk_prepare_enable/clk_disable_unprepare > > > > >usb: host: ohci-s3c2410 Use > > > > >clk_prepare_enable/clk_disable_unprepare > > > > >ARM: s3c64xx: Migrate clock handling to Common Clock > > > > >Framework > > > > >ARM: s3c64xx: Remove old clock management code > > > > > > > > > > .../bindings/clock/samsung,s3c64xx-clock.txt | 77 ++ > > > > > arch/arm/Kconfig |2 +- > > > > > arch/arm/mach-s3c64xx/Makefile |2 +- > > > > > arch/arm/mach-s3c64xx/clock.c | 1007 > > > > > arch/arm/mach-s3c64xx/common.c > > > > > > > > > >| 21 +- > > > > > > > > > > arch/arm/mach-s3c64xx/common.h | 12 +- > > > > > arch/arm/mach-s3c64xx/dma.c|4 +- > > > > > arch/arm/mach-s3c64xx/include/mach/regs-clock.h| 132 +-- > > > > > arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- > > > > > arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- > > > > > arch/arm/mach-s3c64xx/mach-hmt.c |2 +- > > > > > arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- > > > > > arch/arm/mach-s3c64xx/mach-ncp.c |2 +- > > > > > arch/arm/mach-s3c64xx/mach-smartq.c| 11 +- > > > > > arch/arm/mach-s3c64xx/mach-smdk6400.c |2 +- > > > > > arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- > > > > > arch/arm/mach-s3c64xx/pm.c | 21 - > > > > > arch/arm/mach-s3c64xx/s3c6400.c|6 - > > > > > arch/arm/mach-s3c64xx/s3c6410.c|7 - > > > > > arch/arm/plat-samsung/include/plat/cpu.h |4 + > > > > > drivers/clk/clk-mux.c | 10 +- > > > > > drivers/clk/samsung/Makefile
Re: [PATCH V5 6/6] USB: OHCI: make ohci-s3c2410 a separate driver
-532,4 +483,39 @@ static struct platform_driver
> ohci_hcd_s3c2410_driver = { },
> };
>
> +static int __init ohci_s3c2410_init(void)
> +{
> + if (usb_disabled())
> + return -ENODEV;
> +
> + pr_info("%s: " DRIVER_DESC "\n", hcd_name);
> + ohci_init_driver(&ohci_s3c2410_hc_driver, NULL);
> +
> + /*
> + * The Samsung HW has some unusual quirks, which require
> + * Sumsung-specific workarounds. We override certain hc_driver
> + * functions here to achieve that. We explicitly do not enhance
> + * ohci_driver_overrides to allow this more easily, since this
> + * is an unusual case, and we don't want to encourage others to
> + * override these functions by making it too easy.
> + */
> +
> + orig_ohci_hub_control = ohci_s3c2410_hc_driver.hub_control;
> + orig_ohci_hub_status_data =
ohci_s3c2410_hc_driver.hub_status_data;
> +
> + ohci_s3c2410_hc_driver.hub_status_data =
ohci_s3c2410_hub_status_data;
> + ohci_s3c2410_hc_driver.hub_control =
ohci_s3c2410_hub_control; +
> + return platform_driver_register(&ohci_hcd_s3c2410_driver);
> +}
> +module_init(ohci_s3c2410_init);
> +
> +static void __exit ohci_s3c2410_cleanup(void)
> +{
> + platform_driver_unregister(&ohci_hcd_s3c2410_driver);
> +}
> +module_exit(ohci_s3c2410_cleanup);
> +
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_LICENSE("GPL");
> MODULE_ALIAS("platform:s3c2410-ohci");
Looks good.
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: samsung: pll: Use new registration method for PLL6552 and PLL6553
This patch modifies PLL6552 and PLL6553 clock drivers to use recently
added common Samsung PLL registration method.
Signed-off-by: Tomasz Figa
---
drivers/clk/samsung/clk-pll.c | 105 +-
drivers/clk/samsung/clk-pll.h | 6 +--
2 files changed, 13 insertions(+), 98 deletions(-)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 0775554..7572d1d 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -441,9 +441,6 @@ struct clk * __init samsung_clk_register_pll46xx(const char
*name,
* PLL6552 Clock Type
*/
-#define PLL6552_LOCK_REG 0x00
-#define PLL6552_CON_REG0x0c
-
#define PLL6552_MDIV_MASK 0x3ff
#define PLL6552_PDIV_MASK 0x3f
#define PLL6552_SDIV_MASK 0x7
@@ -451,21 +448,14 @@ struct clk * __init samsung_clk_register_pll46xx(const
char *name,
#define PLL6552_PDIV_SHIFT 8
#define PLL6552_SDIV_SHIFT 0
-struct samsung_clk_pll6552 {
- struct clk_hw hw;
- void __iomem *reg_base;
-};
-
-#define to_clk_pll6552(_hw) container_of(_hw, struct samsung_clk_pll6552, hw)
-
static unsigned long samsung_pll6552_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
- struct samsung_clk_pll6552 *pll = to_clk_pll6552(hw);
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
u32 mdiv, pdiv, sdiv, pll_con;
u64 fvco = parent_rate;
- pll_con = __raw_readl(pll->reg_base + PLL6552_CON_REG);
+ pll_con = __raw_readl(pll->con_reg);
mdiv = (pll_con >> PLL6552_MDIV_SHIFT) & PLL6552_MDIV_MASK;
pdiv = (pll_con >> PLL6552_PDIV_SHIFT) & PLL6552_PDIV_MASK;
sdiv = (pll_con >> PLL6552_SDIV_SHIFT) & PLL6552_SDIV_MASK;
@@ -480,48 +470,10 @@ static const struct clk_ops samsung_pll6552_clk_ops = {
.recalc_rate = samsung_pll6552_recalc_rate,
};
-struct clk * __init samsung_clk_register_pll6552(const char *name,
- const char *pname, void __iomem *base)
-{
- struct samsung_clk_pll6552 *pll;
- struct clk *clk;
- struct clk_init_data init;
-
- pll = kzalloc(sizeof(*pll), GFP_KERNEL);
- if (!pll) {
- pr_err("%s: could not allocate pll clk %s\n", __func__, name);
- return NULL;
- }
-
- init.name = name;
- init.ops = &samsung_pll6552_clk_ops;
- init.parent_names = &pname;
- init.num_parents = 1;
-
- pll->hw.init = &init;
- pll->reg_base = base;
-
- clk = clk_register(NULL, &pll->hw);
- if (IS_ERR(clk)) {
- pr_err("%s: failed to register pll clock %s\n", __func__,
- name);
- kfree(pll);
- }
-
- if (clk_register_clkdev(clk, name, NULL))
- pr_err("%s: failed to register lookup for %s", __func__, name);
-
- return clk;
-}
-
/*
* PLL6553 Clock Type
*/
-#define PLL6553_LOCK_REG 0x00
-#define PLL6553_CON0_REG 0x0c
-#define PLL6553_CON1_REG 0x10
-
#define PLL6553_MDIV_MASK 0xff
#define PLL6553_PDIV_MASK 0x3f
#define PLL6553_SDIV_MASK 0x7
@@ -531,22 +483,15 @@ struct clk * __init samsung_clk_register_pll6552(const
char *name,
#define PLL6553_SDIV_SHIFT 0
#define PLL6553_KDIV_SHIFT 0
-struct samsung_clk_pll6553 {
- struct clk_hw hw;
- void __iomem *reg_base;
-};
-
-#define to_clk_pll6553(_hw) container_of(_hw, struct samsung_clk_pll6553, hw)
-
static unsigned long samsung_pll6553_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
- struct samsung_clk_pll6553 *pll = to_clk_pll6553(hw);
+ struct samsung_clk_pll *pll = to_clk_pll(hw);
u32 mdiv, pdiv, sdiv, kdiv, pll_con0, pll_con1;
u64 fvco = parent_rate;
- pll_con0 = __raw_readl(pll->reg_base + PLL6553_CON0_REG);
- pll_con1 = __raw_readl(pll->reg_base + PLL6553_CON1_REG);
+ pll_con0 = __raw_readl(pll->con_reg);
+ pll_con1 = __raw_readl(pll->con_reg + 0x4);
mdiv = (pll_con0 >> PLL6553_MDIV_SHIFT) & PLL6553_MDIV_MASK;
pdiv = (pll_con0 >> PLL6553_PDIV_SHIFT) & PLL6553_PDIV_MASK;
sdiv = (pll_con0 >> PLL6553_SDIV_SHIFT) & PLL6553_SDIV_MASK;
@@ -563,40 +508,6 @@ static const struct clk_ops samsung_pll6553_clk_ops = {
.recalc_rate = samsung_pll6553_recalc_rate,
};
-struct clk * __init samsung_clk_register_pll6553(const char *name,
- const char *pname, void __iomem *base)
-{
- struct samsung_clk_pll6553 *pll;
- struct clk *clk;
- struct clk_init_data init;
-
- pll = kzalloc(sizeof(*pll), GFP_KERNEL);
- if (!pll) {
- pr_err("%s: could not allocate pll
Re: [PATCH 1/3 v5] usb: phy-samsung-usb: Simplify PMU register handling
Hi Felipe, On Tuesday 17 of September 2013 10:36:16 Felipe Balbi wrote: > Hi, > > On Tue, Aug 27, 2013 at 01:27:48PM -0700, Julius Werner wrote: > > *Ping!* > > > > Are there still unanswered concerns left with this patch? I hope my > > prior mails could clear up why I think that the PMU register > > description in the device tree for a specific PHY is represents the > > hardware more accurately after my patch, and my analysis of the > > Exynos4 situation currently not being implemented (and therefore not > > needing to be addressed by this patch) was correct. Please let me know > > if you have further objections... and if not, could we agree to have > > this picked up somewhere? > > I need acks for DTS part... This patch breaks Exynos 4, so it's a NAK from me. Anyway, a new, completely redesigned PHY driver supporting most of the PHY features (as opposed to only the basic subset currently) developed by Kamil Debski should show up soon, so I don't think there is any reason to apply any patches to this old driver. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: OHCI: Check the overrides pointer for NULL in ohci_init_driver()
A series of commit starting at
50a97e059b USB: OHCI: make ohci-exynos a separate driver
and ending at
b8ad5c3706 USB: OHCI: make ohci-pxa27x a separate driver
introduced the concept of separate OHCI drivers for particular
controllers. Respective drivers need to call ohci_init_driver() to
initialize hc_driver struct with generic data and to certain extent
with platform specific overrides through ohci_driver_overrides struct
passed as second argument to this function. However the code does not
check if the ohci_driver_overrides struct pointer is non-NULL, which
leads for a NULL pointer dereference for drivers that do not need any
overrides.
This patch fixes the problem by dereferencing the passed pointer to
ohci_driver_overrides struct only if it is non-NULL.
Signed-off-by: Tomasz Figa
---
drivers/usb/host/ohci-hcd.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 21d937a..8ada13f 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1161,10 +1161,12 @@ void ohci_init_driver(struct hc_driver *drv,
/* Copy the generic table to drv and then apply the overrides */
*drv = ohci_hc_driver;
- drv->product_desc = over->product_desc;
- drv->hcd_priv_size += over->extra_priv_size;
- if (over->reset)
- drv->reset = over->reset;
+ if (over) {
+ drv->product_desc = over->product_desc;
+ drv->hcd_priv_size += over->extra_priv_size;
+ if (over->reset)
+ drv->reset = over->reset;
+ }
}
EXPORT_SYMBOL_GPL(ohci_init_driver);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: OHCI: Check the overrides pointer for NULL in ohci_init_driver()
On Saturday 28 of September 2013 23:00:27 Alan Stern wrote:
> On Sat, 28 Sep 2013, Tomasz Figa wrote:
> > A series of commit starting at
> >
> > 50a97e059b USB: OHCI: make ohci-exynos a separate driver
> >
> > and ending at
> >
> > b8ad5c3706 USB: OHCI: make ohci-pxa27x a separate driver
> >
> > introduced the concept of separate OHCI drivers for particular
> > controllers. Respective drivers need to call ohci_init_driver() to
> > initialize hc_driver struct with generic data and to certain extent
> > with platform specific overrides through ohci_driver_overrides struct
> > passed as second argument to this function. However the code does not
> > check if the ohci_driver_overrides struct pointer is non-NULL, which
> > leads for a NULL pointer dereference for drivers that do not need any
> > overrides.
> >
> > This patch fixes the problem by dereferencing the passed pointer to
> > ohci_driver_overrides struct only if it is non-NULL.
> >
> > Signed-off-by: Tomasz Figa
> > ---
> >
> > drivers/usb/host/ohci-hcd.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> > index 21d937a..8ada13f 100644
> > --- a/drivers/usb/host/ohci-hcd.c
> > +++ b/drivers/usb/host/ohci-hcd.c
> > @@ -1161,10 +1161,12 @@ void ohci_init_driver(struct hc_driver *drv,
> >
> > /* Copy the generic table to drv and then apply the overrides */
> > *drv = ohci_hc_driver;
> >
> > - drv->product_desc = over->product_desc;
> > - drv->hcd_priv_size += over->extra_priv_size;
> > - if (over->reset)
> > - drv->reset = over->reset;
> > + if (over) {
> > + drv->product_desc = over->product_desc;
> > + drv->hcd_priv_size += over->extra_priv_size;
> > + if (over->reset)
> > + drv->reset = over->reset;
> > + }
> >
> > }
> > EXPORT_SYMBOL_GPL(ohci_init_driver);
>
> You were scooped by Kevin Hilman:
>
> http://marc.info/?l=linux-usb&m=138029463906143&w=2
Happens. :)
Nice to have this fixed anyway.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] phy: Add new Exynos USB PHY driver
Hi Kamil,
On Monday 28 of October 2013 14:52:19 Kamil Debski wrote:
> Hi Kishon,
>
> Thank you for your review! I will answer your comments below.
[snip]
> > > +
> > > + switch (drv->cfg->cpu) {
> > > + case TYPE_EXYNOS4210:
> >
> > > + case TYPE_EXYNOS4212:
> > Lets not add such cpu checks inside driver.
>
> Some SoC have a special register, which switches the OTG lines between
> device and host modes. I understand that it might not be the prettiest
> code. I see this as a good compromise between having a single huge
> driver for all Exynos SoCs and having a multiple drivers for each SoC
> version. PHY IPs in these chips very are similar but have to be handled
> differently. Any other ideas to solve this issue?
Maybe adding a flag in drv->cfg called, for example, .has_mode_switch
could solve this problem without having to check the SoC type explicitly?
[snip]
> > > +#ifdef CONFIG_PHY_EXYNOS4210_USB
> >
> > Do we really need this?
>
> No we don't. The driver can always support all Exynos SoC versions.
> These config options were added for flexibility.
>
> > > +extern const struct uphy_config exynos4210_uphy_config; #endif
> > > +
> > > +#ifdef CONFIG_PHY_EXYNOS4212_USB
> >
> > Same here.
> >
> > > +extern const struct uphy_config exynos4212_uphy_config; #endif
> > > +
> > > +static const struct of_device_id exynos_uphy_of_match[] = { #ifdef
> > > +CONFIG_PHY_EXYNOS4210_USB
> >
> > #if not needed here.
>
> If the #ifdef CONFIG_PHY_EXYNOS4210_USB is removed then yes. Otherwise
> it is necessary - exynos4210_uphy_config may be undefined.
I believe this and other ifdefs below are needed, otherwise, with support
for one of the SoCs disabled, the driver could still bind to its
compatible value.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/9] usb: gadget: s3c-hsotg: enable generic phy support
Hi Matt. On Friday 01 of November 2013 15:45:54 Matt Porter wrote: > Adds support for the generic PHY subsystem. Generic PHY > support is probed and then the driver falls back to checking > for an old style USB PHY and pdata if not found. > > Signed-off-by: Matt Porter > --- > drivers/usb/gadget/s3c-hsotg.c | 54 > -- 1 file changed, 36 > insertions(+), 18 deletions(-) Patches that convert the driver to generic PHY have been already posted by Kamil Debski, as a part of a series[1] adding generic PHY drivers for S5P and Exynos SoCs. After that series, there will be no need to support the usb_phy subsystem in this driver anymore. [1] http://www.mail-archive.com/linux-usb@vger.kernel.org/msg31189.html Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
Hi Matt, On Friday 01 of November 2013 15:45:50 Matt Porter wrote: > This adds a pair of APIs that allows the generic PHY subsystem to > provide information on the PHY bus width. The PHY provider driver may > use phy_set_bus_width() to set the bus width that the PHY supports. > The controller driver may then use phy_get_bus_width() to fetch the > PHY bus width in order to properly configure the controller. I somehow does not like this. If we take this path for any further properties that we may need, we will end up with a lot of consumer specific properties stored in a PHY object having their own accessor functions. Since this is just an integration detail, what about simply adding this as a property in device tree node of the OTG controller (and pdata if considering non-DT support)? Another option would be some framework for retrieving arbitrary properties from the PHY, but I'm not really sure there is a need for such. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
On Saturday 02 of November 2013 13:47:09 Matt Porter wrote:
> On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
> > Hi Tomasz,
> >
> > On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> > >Hi Matt,
> > >
> > >On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> > >>This adds a pair of APIs that allows the generic PHY subsystem to
> > >>provide information on the PHY bus width. The PHY provider driver
> > >>may
> > >>use phy_set_bus_width() to set the bus width that the PHY supports.
> > >>The controller driver may then use phy_get_bus_width() to fetch the
> > >>PHY bus width in order to properly configure the controller.
> > >
> > >I somehow does not like this. If we take this path for any further
> > >properties that we may need, we will end up with a lot of consumer
> > >specific properties stored in a PHY object having their own accessor
> > >functions.
> >
> > Only after all of us feel that a property is *generic* enough, we
> > allow it to be added in the PHY object.
>
> I also want to note that this was discussed over in another thread [2]
> where you did consider my rough stab at a more generic attribute
> accessor. It was definitely my first reaction as the way to do it like
> Tomasz has said. The specific accessors are more readable to me besides
> the justification you mention above.
>
> [2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html
Personally I like that version much better, but still it would need to be
polished a bit.
How I imagine such interface to be implemented:
phy.h:
struct phy {
// ...
const struct phy_attrs *attrs;
// ...
};
static inline const struct phy_attrs *phy_get_attrs(struct phy *phy) {
return phy->attrs;
};
phy driver:
static const struct phy_attrs my_phy_attrs = {
// ...
};
static int my_phy_probe(...)
{
// ...
phy = devm_phy_create_attrs(dev, &ops, &my_phy_attrs, NULL);
// ...
}
phy consumer:
// ...
const struct phy_attrs *phy_attrs;
phy_attrs = phy_get_attrs(phy);
// ...
Why I think it is better than what I've seen in this and previous instance
of this thread? (in random order)
a) Only the PHY driver can set the attrs.
b) PHY consumer has access only to a const pointer.
c) PHY attributes can be placed in a static struct inside a driver file,
without the need to call any functions to set particular attributes.
d) Can be extended with more attributes easily.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Kishon, On Monday 04 of November 2013 12:24:42 Kishon Vijay Abraham I wrote: > Hi Vivek, > > On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote: > > Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. > > The new driver uses the generic PHY framework and will interact > > with DWC3 controller present on Exynos5 series of SoCs. > > In Exynos, you have a single IP that supports both USB3 and USB2 PHY > right? I think that needs to be mentioned here. Nope. There are two separate, different IPs. > Do you have separate registers that should be used for > initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy? If > so, then you should model this driver as a single driver that supports > two PHYs similar to what Sylwester has done before? Sylwester's MIPI PHY uses such model because it has a single register that controls both PHYs. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
On Tuesday 05 of November 2013 12:50:18 Vivek Gautam wrote: > Hi Kishon, > > On Mon, Nov 4, 2013 at 6:42 PM, Kishon Vijay Abraham I wrote: > > Hi, > > > > On Monday 04 November 2013 03:45 PM, Kamil Debski wrote: > >> Hi Kishon, > >> > >>> From: Kishon Vijay Abraham I [mailto:kis...@ti.com] > >>> Sent: Monday, November 04, 2013 7:55 AM > >>> > >>> Hi Vivek, > >>> > >>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote: > Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. > The new driver uses the generic PHY framework and will interact > with > DWC3 controller present on Exynos5 series of SoCs. > >>> > >>> In Exynos, you have a single IP that supports both USB3 and USB2 PHY > >>> right? I think that needs to be mentioned here. > >> > >> As far as I know the IP is different. > > > > Ok. Sometime back Vivek was mentioning about a single IP for both USB3 > > and USB2. Thought it should be this driver. Anyway thanks for the > > clarification. > Right Kishon, I had mentioned that Exynos5's dwc3 controller have a > single IP for USB2 and USB3 phy. > From what i see, on exynos5 systems the dwc3 controller uses a combo > of usb 2 (utmi+) and usb 3 (pipe 3) phy > (with base address starting 0x1210). I meant there is a single PHY used with the USB 3.0 controller (dwc3) and it is different from the PHY used with the USB 2.0 controller (s3c-hsotg aka dwc2). The USB 3.0 PHY and controller blocks also support USB 2.0 operation, though. So we were both right. ;) Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] phy: Add new Exynos USB PHY driver
Hi Kishon
On Wednesday 06 of November 2013 13:48:13 Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 05 November 2013 09:43 PM, Kamil Debski wrote:
> > Add a new driver for the Exynos USB PHY. The new driver uses the generic
> > PHY framework. The driver includes support for the Exynos 4x10 and 4x12
> > SoC families.
> >
> > Signed-off-by: Kamil Debski
> > Signed-off-by: Kyungmin Park
> > ---
> > .../devicetree/bindings/phy/samsung-usbphy.txt | 52
> > drivers/phy/Kconfig| 23 +-
> > drivers/phy/Makefile |4 +
> > drivers/phy/phy-exynos-usb2.c | 234 ++
> > drivers/phy/phy-exynos-usb2.h | 87 ++
> > drivers/phy/phy-exynos4210-usb2.c | 272
> > drivers/phy/phy-exynos4212-usb2.c | 324
> >
> > 7 files changed, 995 insertions(+), 1 deletion(-)
> > create mode 100644
> > Documentation/devicetree/bindings/phy/samsung-usbphy.txt
> > create mode 100644 drivers/phy/phy-exynos-usb2.c
> > create mode 100644 drivers/phy/phy-exynos-usb2.h
> > create mode 100644 drivers/phy/phy-exynos4210-usb2.c
> > create mode 100644 drivers/phy/phy-exynos4212-usb2.c
[snip]
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index a344f3d..bdf0fab 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
[snip]
> > @@ -51,4 +51,25 @@ config PHY_EXYNOS_DP_VIDEO
> > help
> > Support for Display Port PHY found on Samsung EXYNOS SoCs.
> >
> > +config PHY_EXYNOS_USB2
> > + tristate "Samsung USB 2.0 PHY driver"
> > + help
> > + Enable this to support Samsung USB phy helper driver for Samsung SoCs.
> > + This driver provides common interface to interact, for Samsung
> > + USB 2.0 PHY driver.
>
> I still think we can get rid of this helper driver and have a single
> driver for both PHY_EXYNOS4210_USB2 and PHY_EXYNOS4212_USB2.
This helper driver is a really nice way to avoid code duplication, while
still leaving the code clean and readable.
All the Samsung USB 2.0 PHYs require exactly the same semantics
(isolation, reference rate configuration, power up, power on), but each
one has completely different layout of registers and bits inside
registers.
Making a big single driver would end up being identical to the old Exynos
USB2PHY driver with a lot of if and switch statements inside most of
functions, which is not only ugly but makes any further extension hard.
In addition, this approach makes it possible to disable support for SoCs
that are not needed in particular use cases, allowing smaller kernel
images.
> > +
> > +config PHY_EXYNOS4210_USB2
> > + bool "Support for Exynos 4210"
> > + depends on PHY_EXYNOS_USB2
> > + depends on CPU_EXYNOS4210
> > + help
> > + Enable USB PHY support for Exynos 4210
> > +
> > +config PHY_EXYNOS4212_USB2
> > + bool "Support for Exynos 4212"
> > + depends on PHY_EXYNOS_USB2
> > + depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412)
> > + help
> > + Enable USB PHY support for Exynos 4212
> > +
> > endmenu
[snip]
> > +extern const struct usb2_phy_config exynos4210_usb2_phy_config;
> > +extern const struct usb2_phy_config exynos4212_usb2_phy_config;
> > +
> > +static const struct of_device_id exynos_usb2_phy_of_match[] = {
> > +#ifdef CONFIG_PHY_EXYNOS4210_USB2
>
> I don't think you'll need #ifdef here. Anyways the driver data can be
> obtained using the appropriate compatible value in dt data no?
Huh?
This is not about driver data, but rather about the ability to match the
driver only to devices that are actually supported with selected Kconfig
options.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] phy: Add new Exynos USB PHY driver
On Wednesday 06 of November 2013 18:20:36 Kishon Vijay Abraham I wrote: > Hi, > > On Wednesday 06 November 2013 05:08 PM, Tomasz Figa wrote: > > Hi Kishon > > > > On Wednesday 06 of November 2013 13:48:13 Kishon Vijay Abraham I wrote: > >> Hi, > >> > >> On Tuesday 05 November 2013 09:43 PM, Kamil Debski wrote: > >>> Add a new driver for the Exynos USB PHY. The new driver uses the generic > >>> PHY framework. The driver includes support for the Exynos 4x10 and 4x12 > >>> SoC families. > >>> > >>> Signed-off-by: Kamil Debski > >>> Signed-off-by: Kyungmin Park > >>> --- > >>>.../devicetree/bindings/phy/samsung-usbphy.txt | 52 > >>>drivers/phy/Kconfig| 23 +- > >>>drivers/phy/Makefile |4 + > >>>drivers/phy/phy-exynos-usb2.c | 234 > >>> ++ > >>>drivers/phy/phy-exynos-usb2.h | 87 ++ > >>>drivers/phy/phy-exynos4210-usb2.c | 272 > >>> > >>>drivers/phy/phy-exynos4212-usb2.c | 324 > >>> > >>>7 files changed, 995 insertions(+), 1 deletion(-) > >>>create mode 100644 > >>> Documentation/devicetree/bindings/phy/samsung-usbphy.txt > >>>create mode 100644 drivers/phy/phy-exynos-usb2.c > >>>create mode 100644 drivers/phy/phy-exynos-usb2.h > >>>create mode 100644 drivers/phy/phy-exynos4210-usb2.c > >>>create mode 100644 drivers/phy/phy-exynos4212-usb2.c > > [snip] > >>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > >>> index a344f3d..bdf0fab 100644 > >>> --- a/drivers/phy/Kconfig > >>> +++ b/drivers/phy/Kconfig > > [snip] > >>> @@ -51,4 +51,25 @@ config PHY_EXYNOS_DP_VIDEO > >>> help > >>> Support for Display Port PHY found on Samsung EXYNOS SoCs. > >>> > >>> +config PHY_EXYNOS_USB2 > >>> + tristate "Samsung USB 2.0 PHY driver" > >>> + help > >>> + Enable this to support Samsung USB phy helper driver for Samsung SoCs. > >>> + This driver provides common interface to interact, for Samsung > >>> + USB 2.0 PHY driver. > >> > >> I still think we can get rid of this helper driver and have a single > >> driver for both PHY_EXYNOS4210_USB2 and PHY_EXYNOS4212_USB2. > > > > This helper driver is a really nice way to avoid code duplication, while > > still leaving the code clean and readable. > > > > All the Samsung USB 2.0 PHYs require exactly the same semantics > > (isolation, reference rate configuration, power up, power on), but each > > one has completely different layout of registers and bits inside > > registers. > > I just did a diff of registers in exynos 4210 and 4212 PHY drivers [1] > and couldn't find that big a difference in register layout. Of course > there are a few changes in HSIC bit fields and PHYFSEL but that's only > minimal and could well be handled in a single driver. > > [1] -> http://diffchecker.com/py3tp68m This is quite a lot of differences, especially including shifted bitfields... In addition there is another set of available PHYs and inter-dependencies between them. > > > > Making a big single driver would end up being identical to the old Exynos > > USB2PHY driver with a lot of if and switch statements inside most of > > functions, which is not only ugly but makes any further extension hard. > > Probably we shouldn't try to over design and just convert the old exynos > usb2 phy driver to the generic phy framework to begin with? The old exynos USB2 PHY driver is incomplete and has very limited functionality. It needs a complete redesign to support remaining features and this is the reason we decided to develop a new driver from scratch. I believe the way Kamil's driver is designed is definitely the way to go with Samsung's USB2 PHY drivers, especially considering that support for more SoCs using the same framework will be added - S3C64xx, S5PV210, and Exynos5250. Best regards. Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] phy: Add new Exynos USB PHY driver
Hi David, On Wednesday 06 of November 2013 13:03:45 David Laight wrote: > > > I just did a diff of registers in exynos 4210 and 4212 PHY drivers [1] > > > and couldn't find that big a difference in register layout. Of course > > > there are a few changes in HSIC bit fields and PHYFSEL but that's only > > > minimal and could well be handled in a single driver. > > > > > > [1] -> http://diffchecker.com/py3tp68m > > > > This is quite a lot of differences, especially including shifted > > bitfields... In addition there is another set of available PHYs > > and inter-dependencies between them. > > Might be worth feeding both files through "sed -e 's/_421[02]_/_421x_/'" > prior to doing the diff. > And maybe changing the order of some definitions so they match. > Then the actual differences will be more obvious. I have fed it already through my built-in sed when reading. Still despite many similarities, I think there is enough difference to justify having different callback functions for both, especially based on my experience with the old Exynos USB2 PHY driver in drivers/usb/phy, when trying to make it more complete. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Vivek,
On Thursday 31 of October 2013 13:15:41 Vivek Gautam wrote:
> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> The new driver uses the generic PHY framework and will interact
> with DWC3 controller present on Exynos5 series of SoCs.
>
> Signed-off-by: Vivek Gautam
> ---
> .../devicetree/bindings/phy/samsung-phy.txt| 20 +
> drivers/phy/Kconfig|7 +
> drivers/phy/Makefile |1 +
> drivers/phy/phy-exynos5-usb3.c | 562
>
> 4 files changed, 590 insertions(+), 0 deletions(-)
> create mode 100644 drivers/phy/phy-exynos5-usb3.c
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index c0fccaa..9b5c111 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -20,3 +20,23 @@ Required properties:
> - compatible : should be "samsung,exynos5250-dp-video-phy";
> - reg : offset and length of the Display Port PHY register set;
> - #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Samsung Exynos5 SoC seiries USB 3.0 PHY controller
typo: s/seiries/series/
> +--
> +
> +Required properties:
> +- compatible :
> + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC
> + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC
I'd slightly change this into something like this:
- compatible: Should be set to one of following supported values:
- "samsung,exynos5250-usb3phy" - for Exynos5250 SoC,
- "samsung,exynos5420-usb3phy" - for Exynos5420 SoC.
> +- reg : Register offset and length array
> + - first field corresponds to USB 3.0 PHY register set;
> + - second field corresponds to PHY power isolation register
> + present in PMU;
For consistency and to make things more future-proof, you should consider
using the PMU indirectly, through the syscon interface, as done in Leela
Krishna Amudala's series[1] in case of watchdog driver.
I will tell Kamil to do the same for USB 2.0 PHY as well.
[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/24652
> +- clocks: Clock IDs array as required by the controller
> +- clock-names: names of clocks correseponding to IDs in the clock property;
> + Required clocks:
> + - first clock is main PHY clock (same as USB 3.0 controller IP clock)
> + - second clock is reference clock (usually crystal clock)
> + optional clock:
> + - third clock is special clock used by PHY for operation
Is this clock really optional? It looks like it's required for Exynos5420.
If so, you should instead change this to:
"Additional clocks required for Exynos5420:"
Also you have not specified names of the clocks, just what they are.
Please remember that those are input names, so you can imagine them as
names of clock input pins of the IP block, not SoC-level clock names.
> +- #phy-cells : from the generic PHY bindings, must be 0;
I'd also add an example of correct USB 3.0 PHY device tree node here.
> diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c
> new file mode 100644
> index 000..b9a2674
> --- /dev/null
> +++ b/drivers/phy/phy-exynos5-usb3.c
> @@ -0,0 +1,562 @@
[snip]
> +#define EXYNOS5_DRD_PHYRESUME(0x34)
> +#define EXYNOS5_DRD_LINKPORT (0x44)
> +
> +
nit: Duplicate blank line.
> +/* Isolation, configured in the power management unit */
> +#define EXYNOS5_USB_ISOL_DRD (1 << 0)
> +
> +#define CLKSEL_ERROR -1
What's this?
> +
> +#ifndef KHZ
> +#define KHZ 1000
> +#endif
> +
> +#ifndef MHZ
> +#define MHZ (KHZ * KHZ)
> +#endif
Do you really need the #ifndef's above?
> +
> +enum samsung_cpu_type {
> + TYPE_EXYNOS5250,
> + TYPE_EXYNOS5420,
> +};
Instead of using this kind of enumeration, I'd rather introduce a struct
that describes the differences between all supported types.
> +
> +enum usb3phy_state {
> + STATE_OFF,
> + STATE_ON,
> +};
Hmm, isn't it a simple boolean value - false and true?
> +
> +struct usb3phy_config {
> + enum samsung_cpu_type cpu;
> + bool has_sclk_usbphy30;
> +};
Oh, you already have such struct, so there is even a bigger reason to drop
the samsung_cpu_type enum above.
> +
> +struct usb3phy_instance {
> + char *label;
> + struct usb3phy_driver *drv;
> + struct phy *phy;
> + enum usb3phy_state state;
> + u32 clk;
> + unsigned long rate;
> +};
You seem to have just one instance in this driver. Do you really
need this struct?
> +
> +struct usb3phy_driver {
> + struct device *dev;
> + void __iomem *reg_phy;
> + void __iomem *reg_isol;
> + struct clk *clk;
> + struct clk *sclk_usbphy30;
> + struct usb3phy_instance instance;
Fields from that struct could be simply move
Re: [PATCH 2/4] dt: exynos5250: Enable support for generic USB 3.0 phy
Hi Vivek,
On Thursday 31 of October 2013 13:15:42 Vivek Gautam wrote:
> Update device tree bindings for DWC3 controller and
> USB 3.0 phy present on Exynos 5250 SoC, to start using
> the phy driver based on generic phy framework.
>
> Signed-off-by: Vivek Gautam
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 17 ++---
> 1 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index bbac42a..31a6595 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -472,22 +472,17 @@
> compatible = "synopsys,dwc3";
> reg = <0x1200 0x1>;
> interrupts = <0 72 0>;
> - usb-phy = <&usb2_phy &usb3_phy>;
> + phys = <&usb3_phy>;
> + phy-names = "usb3-phy";
Does the driver already support generic PHY framework?
Also it looks like originally it required two PHYs, while your patch
changes it to just one.
> };
> };
>
> usb3_phy: usbphy@1210 {
> compatible = "samsung,exynos5250-usb3phy";
Hmm, this is not fully right. The new bindings should have new compatible
value. This is also a comment to patch 1/1. This is because a device tree
binding associated with specific compatible value is an ABI and should not
be changed in a way that breaks backwards compatibility.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] phy: Add new Exynos USB PHY driver
Hi Kamil,
Please see my comments inline.
On Tuesday 05 of November 2013 17:13:19 Kamil Debski wrote:
> Add a new driver for the Exynos USB PHY. The new driver uses the generic
> PHY framework. The driver includes support for the Exynos 4x10 and 4x12
> SoC families.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> ---
> .../devicetree/bindings/phy/samsung-usbphy.txt | 52
> drivers/phy/Kconfig| 23 +-
> drivers/phy/Makefile |4 +
> drivers/phy/phy-exynos-usb2.c | 234 ++
> drivers/phy/phy-exynos-usb2.h | 87 ++
> drivers/phy/phy-exynos4210-usb2.c | 272
> drivers/phy/phy-exynos4212-usb2.c | 324
>
> 7 files changed, 995 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/phy/samsung-usbphy.txt
> create mode 100644 drivers/phy/phy-exynos-usb2.c
> create mode 100644 drivers/phy/phy-exynos-usb2.h
> create mode 100644 drivers/phy/phy-exynos4210-usb2.c
> create mode 100644 drivers/phy/phy-exynos4212-usb2.c
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
> b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
> new file mode 100644
> index 000..c8fbc70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
> @@ -0,0 +1,52 @@
> +Samsung S5P/EXYNOS SoC series USB PHY
I would not limit this only to S5P and newer series, especially that
I'm planning to add support for S3C64xx using this framework.
Instead I would call it Samsung SoC USB 1.1/2.0 PHY.
> +-
> +
> +Required properties:
> +- compatible : should be one of the listed compatibles:
> + - "samsung,exynos4210-usbphy"
> + - "samsung,exynos4212-usbphy"
> +- reg : a list of registers used by phy driver
> + - first and obligatory is the location of phy modules registers
> + - second and also required is the location of isolation registers
> + (isolation registers control the physical connection between the in
> + SoC modules and outside of the SoC, this also can be called enable
> + control in the documentation of the SoC)
> + - third is the location of the mode switch register, this only applies
> + to SoCs that have such a feature; mode switching enables to have
> + both host and device used the same SoC pins and is commonly used
> + when OTG is supported
You should consider using the PMU registers indirectly, as done in Leela
Krisha Amudala's series[1] adding PMU register handling to the watchdog
driver.
[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/24652
> +- #phy-cells : from the generic phy bindings, must be 1;
> +- clocks and clock-names:
> + - the "phy" clocks is required by the phy module
> + - other clocks are associated by name with their respective phys and
> + are used to determine the value of the clock settings register
Those names should be explicitly listed.
> +
> +The second cell in the PHY specifier identifies the PHY, its meaning is
It should say "The first cell", I think?
> +compatible dependent. For the currently supported SoCs (Exynos 4210 and
> +Exynos 4212) it is as follows:
> + 0 - USB device,
> + 1 - USB host,
> + 2 - HSIC0,
> + 3 - HSIC1,
> +
> +Example:
> +
> +For Exynos 4412 (compatible with Exynos 4212):
> +
> +exynos_usbphy: exynos-usbphy@125B {
nit: Node names should be generic and the label is slightly too long, so
a better example would be:
usbphy: phy@125B {
> + compatible = "samsung,exynos4212-usbphy";
> + reg = <0x125B 0x100 0x10020704 0x0c 0x1001021c 0x4>;
> + clocks = <&clock 305>, <&clock 2>, <&clock 2>, <&clock 2>,
> + <&clock 2>;
> + clock-names = "phy", "device", "host", "hsic0", "hsic1";
> + status = "okay";
> + #phy-cells = <1>;
> +};
> +
> +Then the PHY can be used in other nodes such as:
> +
> +ehci@1258 {
> + status = "okay";
> + phys = <&exynos_usbphy 2>;
> + phy-names = "hsic0";
> +};
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index a344f3d..bdf0fab 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -14,7 +14,7 @@ config GENERIC_PHY
> API by which phy drivers can create PHY using the phy framework and
> phy users can obtain reference to the PHY. All the users of this
> framework should select this config.
> -
> +
Stray white space added.
> config PHY_EXYNOS_MIPI_VIDEO
> tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
> help
> @@ -51,4 +51,25 @@ config PHY_EXYNOS_DP_VIDEO
> help
> Support for Display Port PHY found on Samsung EXYNOS SoCs.
>
> +config PHY_EXYNOS_USB2
Wouldn't PHY_SAMSUNG_USB2 be better here?
> + tristate "Samsun
Re: [PATCH v3 2/3] usb: ehci-s5p: Change to use phy provided by the generic phy framework
Hi Kamil,
On Tuesday 05 of November 2013 17:13:20 Kamil Debski wrote:
> Change the phy provider used from the old usb phy specific to a new one
> using the generic phy framework.
I believe that until Exynos5250 also gets converted to the new PHY driver,
support for the old USB PHY API should remain in this driver.
As for the patch itself, please see my comments inline.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> ---
> drivers/usb/host/ehci-exynos.c | 34 +++---
> 1 file changed, 11 insertions(+), 23 deletions(-)
>
This patch is changing a DT binding, but there is no update to the
documentation.
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index 8898c01..974001b 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -19,12 +19,12 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> -#include
>
> #include "ehci.h"
>
> @@ -44,8 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
>
> struct exynos_ehci_hcd {
> struct clk *clk;
> - struct usb_phy *phy;
> - struct usb_otg *otg;
> + struct phy *phy;
> };
>
> #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd
> *)(hcd_to_ehci(hcd)->priv)
> @@ -75,7 +74,8 @@ static int exynos_ehci_probe(struct platform_device *pdev)
> struct usb_hcd *hcd;
> struct ehci_hcd *ehci;
> struct resource *res;
> - struct usb_phy *phy;
> + struct phy *phy;
> + const char *phy_name;
> int irq;
> int err;
>
> @@ -98,12 +98,12 @@ static int exynos_ehci_probe(struct platform_device *pdev)
> return -ENOMEM;
> }
> exynos_ehci = to_exynos_ehci(hcd);
> -
> if (of_device_is_compatible(pdev->dev.of_node,
> "samsung,exynos5440-ehci"))
> goto skip_phy;
>
> - phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
> + phy_name = of_get_property(pdev->dev.of_node, "phy-names", NULL);
> + phy = devm_phy_get(&pdev->dev, phy_name);
This is definitely not the way you should parse PHY DT bindings. PHY names
are supposed to be fixed in the binding for each compatible value, which
means that you should call here devm_phy_get() with a static name.
Moreover, this driver needs one PHY per port, not just one PHY, so the
design needs to be completely changed and this patch is not really enough
to correctly support USB 2.0 on Exynos.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] usb: s3c-hsotg: Use the new Exynos USB phy driver with the generic phy framework
Hi Kamil,
This patch is changing a DT binding, but you haven't updated relevant
documentation. Please remember about it in next version.
On Tuesday 05 of November 2013 17:13:21 Kamil Debski wrote:
> Change the used phy driver to the new Exynos USB phy driver that uses the
> generic phy framework.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> ---
> drivers/usb/gadget/s3c-hsotg.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
> index bb31262..dc7f20c 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -162,7 +163,7 @@ struct s3c_hsotg_ep {
> struct s3c_hsotg {
> struct device*dev;
> struct usb_gadget_driver *driver;
> - struct usb_phy *phy;
> + struct phy *phy;
> struct s3c_hsotg_plat*plat;
>
> spinlock_t lock;
> @@ -2905,9 +2906,10 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg
> *hsotg)
> dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
>
> if (hsotg->phy)
> - usb_phy_init(hsotg->phy);
> + phy_power_on(hsotg->phy);
> else if (hsotg->plat->phy_init)
> hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
> +
nit: Stray blank line.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Exynos5250: Enabling dwc3-exynos driver
Hi Vivek, Felipe,
On Wednesday 07 of November 2012 18:43:22 Felipe Balbi wrote:
> Hi,
>
> On Wed, Nov 07, 2012 at 06:55:03PM +0530, Vivek Gautam wrote:
> > Hi,
> >
> > On Tue, Nov 6, 2012 at 10:13 PM, Felipe Balbi wrote:
> > > On Tue, Nov 06, 2012 at 08:58:49PM +0530, Vivek Gautam wrote:
> > >> Adding DWC3 device tree node for Exynos5250 along with the
> > >> device address and clock support needed for the controller.
> > >>
> > >> Signed-off-by: Vivek Gautam
> > >> ---
> > >>
> > >> arch/arm/boot/dts/exynos5250.dtsi |6 ++
> > >> arch/arm/mach-exynos/clock-exynos5.c| 24
> > >>
> > >> arch/arm/mach-exynos/include/mach/map.h |1 +
> > >> arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++
> > >> drivers/usb/Kconfig |1 +
> > >> 5 files changed, 34 insertions(+), 0 deletions(-)
> > >>
> > >> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> > >> b/arch/arm/boot/dts/exynos5250.dtsi index cf6a02d..52bca54 100644
> > >> --- a/arch/arm/boot/dts/exynos5250.dtsi
> > >> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> > >> @@ -68,6 +68,12 @@
> > >>
> > >> interrupts = <0 96 0>;
> > >>
> > >> };
> > >>
> > >> + dwc3 {
> > >
> > > shouldn't this be usb@1200 ??
> >
> > Kept this in accordance with controller's name, similar to the change
> > in following:
> > http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg12800.
> > html
> >
> > Needs to be changed ?
>
> I'll leave it to DT experts, but I was under the impression that we
> should be using generic functionality names (usb, i2c, spi, uart, gpio,
> etc) instead of the IP name. IP name is something more for compatible
> flag.
>
> Don't take my word for it though :-) DT experts are the ones with final
> saying
Wrt node name, as far as I am aware of, there is no strict convention of
naming nodes, but the way you suggested is better in terms of readability -
you don't have to know this particular IP to find out what it is used for.
Similar thing is with @addr in node names. I've been always adding @addr to
the name whenever the node had reg property inside (with the same address
of course), but I'm not sure if there is a strict convention here.
Best regards,
Tomasz Figa
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] Samsung USB PHY SoC support cleanup
This patch series intends to improve handling of SoC-specific differences in Samsung USB PHY drivers, by reducing the need to explicitly check SoC type using if and switch statements. In addition, last patch adds support for Exynos 4x12, as this is simply a matter of adding appropriate driver data and additional case in two switches. Tested on Exynos4210-based Trats board and Exynos4412-based internal Samsung board. Tomasz Figa (6): usb: phy: samsung: Select common driver part implicitly usb: phy: samsung: Use clk_get to get reference clock usb: phy: samsung: Consolidate reference clock rate handling usb: phy: samsung: Pass set_isolation callback through driver data usb: phy: samsung: Pass enable/disable callbacks through driver data usb: phy: samsung: Add support for USB 2.0 PHY on Exynos 4x12 drivers/usb/phy/Kconfig| 2 +- drivers/usb/phy/phy-samsung-usb.c | 154 ++--- drivers/usb/phy/phy-samsung-usb.h | 14 +++- drivers/usb/phy/phy-samsung-usb2.c | 53 + drivers/usb/phy/phy-samsung-usb3.c | 23 -- 5 files changed, 146 insertions(+), 100 deletions(-) -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] usb: phy: samsung: Select common driver part implicitly
Since phy-samsung-usb library can be used only by phy-samsung-usb2 and phy-samsung-usb3 drivers, there is no need to give explicit control over its Kconfig symbol. This patch makes CONFIG_SAMSUNG_USBPHY symbol hidden and selected implicitly by CONFIG_SAMSUNG_USB2PHY and CONFIG_SAMSUNG_USB3PHY. Signed-off-by: Tomasz Figa Signed-off-by: Kyungmin Park --- drivers/usb/phy/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 7e8fe0f..5fb0939 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -86,7 +86,7 @@ config OMAP_USB3 on/off the PHY. config SAMSUNG_USBPHY - tristate "Samsung USB PHY Driver" + tristate help Enable this to support Samsung USB phy helper driver for Samsung SoCs. This driver provides common interface to interact, for Samsung USB 2.0 PHY -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] usb: phy: samsung: Use clk_get to get reference clock
There is no need to use devm_clk_get to get a clock that is being put
at the end of the function.
This patch changes the code getting reference clock to use clk_get
instead of useless in this case devm_clk_get.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
drivers/usb/phy/phy-samsung-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-samsung-usb.c
b/drivers/usb/phy/phy-samsung-usb.c
index 7b118ee5..62cdb7e 100644
--- a/drivers/usb/phy/phy-samsung-usb.c
+++ b/drivers/usb/phy/phy-samsung-usb.c
@@ -175,9 +175,9 @@ int samsung_usbphy_get_refclk_freq(struct samsung_usbphy
*sphy)
* external crystal clock XXTI
*/
if (sphy->drv_data->cpu_type == TYPE_EXYNOS5250)
- ref_clk = devm_clk_get(sphy->dev, "ext_xtal");
+ ref_clk = clk_get(sphy->dev, "ext_xtal");
else
- ref_clk = devm_clk_get(sphy->dev, "xusbxti");
+ ref_clk = clk_get(sphy->dev, "xusbxti");
if (IS_ERR(ref_clk)) {
dev_err(sphy->dev, "Failed to get reference clock\n");
return PTR_ERR(ref_clk);
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] usb: phy: samsung: Consolidate reference clock rate handling
This patch cleans up handling of reference clock rate in Samsung USB PHY
drivers. It is mostly a cosmetic change but improves error handling in
case of failing to get reference clock or invalid clock rate.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
drivers/usb/phy/phy-samsung-usb.c | 114 ++---
drivers/usb/phy/phy-samsung-usb.h | 7 +++
drivers/usb/phy/phy-samsung-usb2.c | 8 ++-
drivers/usb/phy/phy-samsung-usb3.c | 6 +-
4 files changed, 86 insertions(+), 49 deletions(-)
diff --git a/drivers/usb/phy/phy-samsung-usb.c
b/drivers/usb/phy/phy-samsung-usb.c
index 62cdb7e..c40ea32 100644
--- a/drivers/usb/phy/phy-samsung-usb.c
+++ b/drivers/usb/phy/phy-samsung-usb.c
@@ -162,13 +162,76 @@ int samsung_usbphy_set_type(struct usb_phy *phy,
}
EXPORT_SYMBOL_GPL(samsung_usbphy_set_type);
+int samsung_usbphy_rate_to_clksel_64xx(struct samsung_usbphy *sphy,
+ unsigned long rate)
+{
+ unsigned int clksel;
+
+ switch (rate) {
+ case 12 * MHZ:
+ clksel = PHYCLK_CLKSEL_12M;
+ break;
+ case 24 * MHZ:
+ clksel = PHYCLK_CLKSEL_24M;
+ break;
+ case 48 * MHZ:
+ clksel = PHYCLK_CLKSEL_48M;
+ break;
+ default:
+ dev_err(sphy->dev,
+ "Invalid reference clock frequency: %lu\n", rate);
+ return -EINVAL;
+ }
+
+ return clksel;
+}
+EXPORT_SYMBOL_GPL(samsung_usbphy_rate_to_clksel_64xx);
+
+int samsung_usbphy_rate_to_clksel_4x12(struct samsung_usbphy *sphy,
+ unsigned long rate)
+{
+ unsigned int clksel;
+
+ switch (rate) {
+ case 9600 * KHZ:
+ clksel = FSEL_CLKSEL_9600K;
+ break;
+ case 10 * MHZ:
+ clksel = FSEL_CLKSEL_10M;
+ break;
+ case 12 * MHZ:
+ clksel = FSEL_CLKSEL_12M;
+ break;
+ case 19200 * KHZ:
+ clksel = FSEL_CLKSEL_19200K;
+ break;
+ case 20 * MHZ:
+ clksel = FSEL_CLKSEL_20M;
+ break;
+ case 24 * MHZ:
+ clksel = FSEL_CLKSEL_24M;
+ break;
+ case 50 * MHZ:
+ clksel = FSEL_CLKSEL_50M;
+ break;
+ default:
+ dev_err(sphy->dev,
+ "Invalid reference clock frequency: %lu\n", rate);
+ return -EINVAL;
+ }
+
+ return clksel;
+}
+EXPORT_SYMBOL_GPL(samsung_usbphy_rate_to_clksel_4x12);
+
/*
* Returns reference clock frequency selection value
*/
int samsung_usbphy_get_refclk_freq(struct samsung_usbphy *sphy)
{
struct clk *ref_clk;
- int refclk_freq = 0;
+ unsigned long rate;
+ int refclk_freq;
/*
* In exynos5250 USB host and device PHY use
@@ -183,52 +246,9 @@ int samsung_usbphy_get_refclk_freq(struct samsung_usbphy
*sphy)
return PTR_ERR(ref_clk);
}
- if (sphy->drv_data->cpu_type == TYPE_EXYNOS5250) {
- /* set clock frequency for PLL */
- switch (clk_get_rate(ref_clk)) {
- case 9600 * KHZ:
- refclk_freq = FSEL_CLKSEL_9600K;
- break;
- case 10 * MHZ:
- refclk_freq = FSEL_CLKSEL_10M;
- break;
- case 12 * MHZ:
- refclk_freq = FSEL_CLKSEL_12M;
- break;
- case 19200 * KHZ:
- refclk_freq = FSEL_CLKSEL_19200K;
- break;
- case 20 * MHZ:
- refclk_freq = FSEL_CLKSEL_20M;
- break;
- case 50 * MHZ:
- refclk_freq = FSEL_CLKSEL_50M;
- break;
- case 24 * MHZ:
- default:
- /* default reference clock */
- refclk_freq = FSEL_CLKSEL_24M;
- break;
- }
- } else {
- switch (clk_get_rate(ref_clk)) {
- case 12 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_12M;
- break;
- case 24 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_24M;
- break;
- case 48 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_48M;
- break;
- default:
- if (sphy->drv_data->cpu_type == TYPE_S3C64XX)
- refclk_freq = PHYCLK_CLKSEL_48M;
- else
- refclk_freq = PHYCLK_CLKSEL_24M;
- break;
- }
- }
+ rate = clk_get_rat
[PATCH 4/6] usb: phy: samsung: Pass set_isolation callback through driver data
This patch extends driver data structure with set_isolation callback,
which allows to remove the need for checking for SoC type in a switch
statement.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
drivers/usb/phy/phy-samsung-usb.c | 36
drivers/usb/phy/phy-samsung-usb.h | 4 +++-
drivers/usb/phy/phy-samsung-usb2.c | 11 +++
drivers/usb/phy/phy-samsung-usb3.c | 7 +--
4 files changed, 23 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/phy/phy-samsung-usb.c
b/drivers/usb/phy/phy-samsung-usb.c
index c40ea32..7a1ed90 100644
--- a/drivers/usb/phy/phy-samsung-usb.c
+++ b/drivers/usb/phy/phy-samsung-usb.c
@@ -73,7 +73,7 @@ EXPORT_SYMBOL_GPL(samsung_usbphy_parse_dt);
* Here 'on = true' would mean USB PHY block is isolated, hence
* de-activated and vice-versa.
*/
-void samsung_usbphy_set_isolation(struct samsung_usbphy *sphy, bool on)
+void samsung_usbphy_set_isolation_4210(struct samsung_usbphy *sphy, bool on)
{
void __iomem *reg = NULL;
u32 reg_val;
@@ -84,32 +84,12 @@ void samsung_usbphy_set_isolation(struct samsung_usbphy
*sphy, bool on)
return;
}
- switch (sphy->drv_data->cpu_type) {
- case TYPE_S3C64XX:
- /*
-* Do nothing: We will add here once S3C64xx goes for DT support
-*/
- break;
- case TYPE_EXYNOS4210:
- /*
-* Fall through since exynos4210 and exynos5250 have similar
-* register architecture: two separate registers for host and
-* device phy control with enable bit at position 0.
-*/
- case TYPE_EXYNOS5250:
- if (sphy->phy_type == USB_PHY_TYPE_DEVICE) {
- reg = sphy->pmuregs +
- sphy->drv_data->devphy_reg_offset;
- en_mask = sphy->drv_data->devphy_en_mask;
- } else if (sphy->phy_type == USB_PHY_TYPE_HOST) {
- reg = sphy->pmuregs +
- sphy->drv_data->hostphy_reg_offset;
- en_mask = sphy->drv_data->hostphy_en_mask;
- }
- break;
- default:
- dev_err(sphy->dev, "Invalid SoC type\n");
- return;
+ if (sphy->phy_type == USB_PHY_TYPE_DEVICE) {
+ reg = sphy->pmuregs + sphy->drv_data->devphy_reg_offset;
+ en_mask = sphy->drv_data->devphy_en_mask;
+ } else if (sphy->phy_type == USB_PHY_TYPE_HOST) {
+ reg = sphy->pmuregs + sphy->drv_data->hostphy_reg_offset;
+ en_mask = sphy->drv_data->hostphy_en_mask;
}
reg_val = readl(reg);
@@ -121,7 +101,7 @@ void samsung_usbphy_set_isolation(struct samsung_usbphy
*sphy, bool on)
writel(reg_val, reg);
}
-EXPORT_SYMBOL_GPL(samsung_usbphy_set_isolation);
+EXPORT_SYMBOL_GPL(samsung_usbphy_set_isolation_4210);
/*
* Configure the mode of working of usb-phy here: HOST/DEVICE.
diff --git a/drivers/usb/phy/phy-samsung-usb.h
b/drivers/usb/phy/phy-samsung-usb.h
index 0336f6b..5203784 100644
--- a/drivers/usb/phy/phy-samsung-usb.h
+++ b/drivers/usb/phy/phy-samsung-usb.h
@@ -271,6 +271,7 @@ struct samsung_usbphy_drvdata {
u32 devphy_reg_offset;
u32 hostphy_reg_offset;
int (*rate_to_clksel)(struct samsung_usbphy *, unsigned long);
+ void (*set_isolation)(struct samsung_usbphy *, bool);
};
/*
@@ -323,7 +324,8 @@ static inline const struct samsung_usbphy_drvdata
}
extern int samsung_usbphy_parse_dt(struct samsung_usbphy *sphy);
-extern void samsung_usbphy_set_isolation(struct samsung_usbphy *sphy, bool on);
+extern void samsung_usbphy_set_isolation_4210(struct samsung_usbphy *sphy,
+ bool on);
extern void samsung_usbphy_cfg_sel(struct samsung_usbphy *sphy);
extern int samsung_usbphy_set_type(struct usb_phy *phy,
enum samsung_usb_phy_type phy_type);
diff --git a/drivers/usb/phy/phy-samsung-usb2.c
b/drivers/usb/phy/phy-samsung-usb2.c
index 802e738..ae6da68 100644
--- a/drivers/usb/phy/phy-samsung-usb2.c
+++ b/drivers/usb/phy/phy-samsung-usb2.c
@@ -284,8 +284,8 @@ static int samsung_usb2phy_init(struct usb_phy *phy)
/* Disable phy isolation */
if (sphy->plat && sphy->plat->pmu_isolation)
sphy->plat->pmu_isolation(false);
- else
- samsung_usbphy_set_isolation(sphy, false);
+ else if (sphy->drv_data->set_isolation)
+ sphy->drv_data->set_isolation(sphy, false);
/* Selecting Host/OTG mode; After reset USB2.0PHY_CFG: HOST */
samsung_usbphy_cfg_sel(sphy);
@@ -342,8 +342,8 @@ static void samsung_usb2phy_shutdown
[PATCH 5/6] usb: phy: samsung: Pass enable/disable callbacks through driver data
To remove unnecessary if statements, this patch introduces phy_enable
and phy_disable callbacks in driver data structure that implement
SoC-specific PHY initialization and deinitialization.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
drivers/usb/phy/phy-samsung-usb.h | 2 ++
drivers/usb/phy/phy-samsung-usb2.c | 16
drivers/usb/phy/phy-samsung-usb3.c | 10 +-
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/phy/phy-samsung-usb.h
b/drivers/usb/phy/phy-samsung-usb.h
index 5203784..31e2ec3 100644
--- a/drivers/usb/phy/phy-samsung-usb.h
+++ b/drivers/usb/phy/phy-samsung-usb.h
@@ -272,6 +272,8 @@ struct samsung_usbphy_drvdata {
u32 hostphy_reg_offset;
int (*rate_to_clksel)(struct samsung_usbphy *, unsigned long);
void (*set_isolation)(struct samsung_usbphy *, bool);
+ void (*phy_enable)(struct samsung_usbphy *);
+ void (*phy_disable)(struct samsung_usbphy *);
};
/*
diff --git a/drivers/usb/phy/phy-samsung-usb2.c
b/drivers/usb/phy/phy-samsung-usb2.c
index ae6da68..b81347b 100644
--- a/drivers/usb/phy/phy-samsung-usb2.c
+++ b/drivers/usb/phy/phy-samsung-usb2.c
@@ -291,10 +291,7 @@ static int samsung_usb2phy_init(struct usb_phy *phy)
samsung_usbphy_cfg_sel(sphy);
/* Initialize usb phy registers */
- if (sphy->drv_data->cpu_type == TYPE_EXYNOS5250)
- samsung_exynos5_usb2phy_enable(sphy);
- else
- samsung_usb2phy_enable(sphy);
+ sphy->drv_data->phy_enable(sphy);
spin_unlock_irqrestore(&sphy->lock, flags);
@@ -334,10 +331,7 @@ static void samsung_usb2phy_shutdown(struct usb_phy *phy)
}
/* De-initialize usb phy registers */
- if (sphy->drv_data->cpu_type == TYPE_EXYNOS5250)
- samsung_exynos5_usb2phy_disable(sphy);
- else
- samsung_usb2phy_disable(sphy);
+ sphy->drv_data->phy_disable(sphy);
/* Enable phy isolation */
if (sphy->plat && sphy->plat->pmu_isolation)
@@ -448,6 +442,8 @@ static const struct samsung_usbphy_drvdata usb2phy_s3c64xx
= {
.devphy_en_mask = S3C64XX_USBPHY_ENABLE,
.rate_to_clksel = samsung_usbphy_rate_to_clksel_64xx,
.set_isolation = NULL, /* TODO */
+ .phy_enable = samsung_usb2phy_enable,
+ .phy_disable= samsung_usb2phy_disable,
};
static const struct samsung_usbphy_drvdata usb2phy_exynos4 = {
@@ -456,6 +452,8 @@ static const struct samsung_usbphy_drvdata usb2phy_exynos4
= {
.hostphy_en_mask= EXYNOS_USBPHY_ENABLE,
.rate_to_clksel = samsung_usbphy_rate_to_clksel_64xx,
.set_isolation = samsung_usbphy_set_isolation_4210,
+ .phy_enable = samsung_usb2phy_enable,
+ .phy_disable= samsung_usb2phy_disable,
};
static struct samsung_usbphy_drvdata usb2phy_exynos5 = {
@@ -464,6 +462,8 @@ static struct samsung_usbphy_drvdata usb2phy_exynos5 = {
.hostphy_reg_offset = EXYNOS_USBHOST_PHY_CTRL_OFFSET,
.rate_to_clksel = samsung_usbphy_rate_to_clksel_4x12,
.set_isolation = samsung_usbphy_set_isolation_4210,
+ .phy_enable = samsung_exynos5_usb2phy_enable,
+ .phy_disable= samsung_exynos5_usb2phy_disable,
};
#ifdef CONFIG_OF
diff --git a/drivers/usb/phy/phy-samsung-usb3.c
b/drivers/usb/phy/phy-samsung-usb3.c
index a4f4fa6..a7242e6 100644
--- a/drivers/usb/phy/phy-samsung-usb3.c
+++ b/drivers/usb/phy/phy-samsung-usb3.c
@@ -65,7 +65,7 @@ static u32 samsung_usb3phy_set_refclk(struct samsung_usbphy
*sphy)
return reg;
}
-static int samsung_exynos5_usb3phy_enable(struct samsung_usbphy *sphy)
+static void samsung_exynos5_usb3phy_enable(struct samsung_usbphy *sphy)
{
void __iomem *regs = sphy->regs;
u32 phyparam0;
@@ -133,8 +133,6 @@ static int samsung_exynos5_usb3phy_enable(struct
samsung_usbphy *sphy)
phyclkrst &= ~(PHYCLKRST_PORTRESET);
writel(phyclkrst, regs + EXYNOS5_DRD_PHYCLKRST);
-
- return 0;
}
static void samsung_exynos5_usb3phy_disable(struct samsung_usbphy *sphy)
@@ -188,7 +186,7 @@ static int samsung_usb3phy_init(struct usb_phy *phy)
sphy->drv_data->set_isolation(sphy, false);
/* Initialize usb phy registers */
- samsung_exynos5_usb3phy_enable(sphy);
+ sphy->drv_data->phy_enable(sphy);
spin_unlock_irqrestore(&sphy->lock, flags);
@@ -219,7 +217,7 @@ static void samsung_usb3phy_shutdown(struct usb_phy *phy)
samsung_usbphy_set_type(&sphy->phy, USB_PHY_TYPE_DEVICE);
/* De-initialize usb phy registers */
- samsung_exynos5_usb3phy_disable(sphy);
+ sphy->drv_data->phy_disable(sphy);
/* Enable phy isolation */
if (sphy->drv_dat
[PATCH 6/6] usb: phy: samsung: Add support for USB 2.0 PHY on Exynos 4x12
This patch adds driver data for Exynos 4x12 USB 2.0 PHY.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
drivers/usb/phy/phy-samsung-usb.h | 1 +
drivers/usb/phy/phy-samsung-usb2.c | 18 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/usb/phy/phy-samsung-usb.h
b/drivers/usb/phy/phy-samsung-usb.h
index 31e2ec3..585d12f 100644
--- a/drivers/usb/phy/phy-samsung-usb.h
+++ b/drivers/usb/phy/phy-samsung-usb.h
@@ -241,6 +241,7 @@
enum samsung_cpu_type {
TYPE_S3C64XX,
TYPE_EXYNOS4210,
+ TYPE_EXYNOS4X12,
TYPE_EXYNOS5250,
};
diff --git a/drivers/usb/phy/phy-samsung-usb2.c
b/drivers/usb/phy/phy-samsung-usb2.c
index b81347b..381f8d4 100644
--- a/drivers/usb/phy/phy-samsung-usb2.c
+++ b/drivers/usb/phy/phy-samsung-usb2.c
@@ -177,6 +177,7 @@ static void samsung_usb2phy_enable(struct samsung_usbphy
*sphy)
rstcon |= RSTCON_SWRST;
break;
case TYPE_EXYNOS4210:
+ case TYPE_EXYNOS4X12:
phypwr &= ~PHYPWR_NORMAL_MASK_PHY0;
rstcon |= RSTCON_SWRST;
default:
@@ -240,6 +241,7 @@ static void samsung_usb2phy_disable(struct samsung_usbphy
*sphy)
phypwr |= PHYPWR_NORMAL_MASK;
break;
case TYPE_EXYNOS4210:
+ case TYPE_EXYNOS4X12:
phypwr |= PHYPWR_NORMAL_MASK_PHY0;
default:
break;
@@ -456,6 +458,16 @@ static const struct samsung_usbphy_drvdata usb2phy_exynos4
= {
.phy_disable= samsung_usb2phy_disable,
};
+static const struct samsung_usbphy_drvdata usb2phy_exynos4x12 = {
+ .cpu_type = TYPE_EXYNOS4X12,
+ .devphy_en_mask = EXYNOS_USBPHY_ENABLE,
+ .hostphy_en_mask= EXYNOS_USBPHY_ENABLE,
+ .rate_to_clksel = samsung_usbphy_rate_to_clksel_4x12,
+ .set_isolation = samsung_usbphy_set_isolation_4210,
+ .phy_enable = samsung_usb2phy_enable,
+ .phy_disable= samsung_usb2phy_disable,
+};
+
static struct samsung_usbphy_drvdata usb2phy_exynos5 = {
.cpu_type = TYPE_EXYNOS5250,
.hostphy_en_mask= EXYNOS_USBPHY_ENABLE,
@@ -475,6 +487,9 @@ static const struct of_device_id samsung_usbphy_dt_match[]
= {
.compatible = "samsung,exynos4210-usb2phy",
.data = &usb2phy_exynos4,
}, {
+ .compatible = "samsung,exynos4x12-usb2phy",
+ .data = &usb2phy_exynos4x12,
+ }, {
.compatible = "samsung,exynos5250-usb2phy",
.data = &usb2phy_exynos5
},
@@ -491,6 +506,9 @@ static struct platform_device_id
samsung_usbphy_driver_ids[] = {
.name = "exynos4210-usb2phy",
.driver_data= (unsigned long)&usb2phy_exynos4,
}, {
+ .name = "exynos4x12-usb2phy",
+ .driver_data= (unsigned long)&usb2phy_exynos4x12,
+ }, {
.name = "exynos5250-usb2phy",
.driver_data= (unsigned long)&usb2phy_exynos5,
},
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] usb: phy: samsung: Consolidate reference clock rate handling
Hi Felipe,
On Wednesday 27 of March 2013 15:19:58 Felipe Balbi wrote:
> Hi,
>
> On Tue, Mar 26, 2013 at 03:53:12PM +0100, Tomasz Figa wrote:
> > @@ -307,6 +310,7 @@ static int samsung_usb3phy_remove(struct
> > platform_device *pdev)>
> > static struct samsung_usbphy_drvdata usb3phy_exynos5 = {
> >
> > .cpu_type = TYPE_EXYNOS5250,
> > .devphy_en_mask = EXYNOS_USBPHY_ENABLE,
> >
> > + .rate_to_clksel = samsung_usbphy_rate_to_clksel_4x12,
>
> why isn't this just a clk_get_rate() ???
As the name suggests, this is a function to get appropriate CLKSEL value to
write into PHYCLK register for reference clock rate on particular platform
(clk_get_rate is used inside to get the rate).
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
