Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
On 03/14/2013 06:54 PM, Tony Lindgren wrote: > * Roger Quadros [130314 08:45]: >> >> OK. Let me know how the below patch looks. After that, the board code >> will look like. >> >> static struct usbhs_phy_data phy_data[] = { >> { >> .reset_gpio = 147, >> .vcc_gpio = 148 >> .vcc_polarity = 1, >> .phy_id = "nop_usb_xceiv.2", >> }, >> {}, /* Terminator */ >> }; >> >> usbhs_init_phys(phy_data); > > Great, looks good to me. > >> Patch to implement usbhs_init_phys(); >> >> diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c >> index 5706bdc..b9d6bff 100644 >> --- a/arch/arm/mach-omap2/usb-host.c >> +++ b/arch/arm/mach-omap2/usb-host.c >> @@ -22,8 +22,12 @@ >> #include >> #include >> #include >> +#include >> +#include >> +#include >> >> #include >> +#include > > Please change these both to linux/io.h and linux/gpio.h. OK. > >> #include "soc.h" >> #include "omap_device.h" >> @@ -472,6 +476,141 @@ void __init setup_4430ohci_io_mux(const enum >> usbhs_omap_port_mode *port_mode) >> } >> } >> >> +static const char *reset_supply = "reset"; >> +static const char *vcc_supply = "vcc"; >> + >> +/* Template for PHY regulators */ >> +static struct regulator_consumer_supply hsusb_reg_supplies[] = { >> +{ /* .supply & .dev_name filled later */ }, >> +}; >> + >> +static struct regulator_init_data hsusb_reg_data = { >> +.constraints = { >> +.valid_ops_mask = REGULATOR_CHANGE_STATUS, >> +}, >> +.consumer_supplies = hsusb_reg_supplies, >> +.num_consumer_supplies = ARRAY_SIZE(hsusb_reg_supplies), >> +}; >> + >> +static struct fixed_voltage_config hsusb_reg_config = { >> +/* .supply_name filled later */ >> +.microvolts = 330, >> +.gpio = -1, /* updated later */ >> +.startup_delay = 7, /* 70msec */ >> +.enable_high = 1, /* updated later */ >> +.enabled_at_boot = 0, /* keep in RESET */ >> +/* .init_data filled later */ >> +}; >> + >> +static struct platform_device_info hsusb_reg_pdev_info = { >> +.name = "reg-fixed-voltage", >> +.id = PLATFORM_DEVID_AUTO, >> +}; >> + >> +int __init usbhs_init_phys(struct usbhs_phy_data *phy) >> +{ >> +struct regulator_consumer_supply *supplies; >> +struct regulator_init_data *reg_data; >> +struct fixed_voltage_config *config; >> +char *supply_name; >> +int i; >> + >> + >> +for (i = 1; i <= OMAP3_HS_USB_PORTS; i++) { > > Maybe pass the number of ports to initialize too to the > function? Might be more future proof, although it will only > be needed until we have converted to DT. > OK. I'll add a port index parameter to the usbhs_phy_data structure to indicate which port the data belongs to and a number of ports to usbhs_init_phys() board code can then do static struct usbhs_phy_data phy_data[] = { { .port = 1, /* First USB port */ .reset_gpio = 147, .vcc_gpio = 148 .vcc_polarity = 1, .phy_id = "nop_usb_xceiv.2", }, }; usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data)); >> + >> +if (!phy->phy_id) /* Terminator ? */ >> +break; >> + >> +if (!gpio_is_valid(phy->reset_gpio)) >> +goto check_vcc; >> + >> +supplies = kmemdup(hsusb_reg_supplies, >> +ARRAY_SIZE(hsusb_reg_supplies) * >> +sizeof(struct regulator_consumer_supply), >> +GFP_KERNEL); >> +if (!supplies) >> +return -ENOMEM; >> + >> +supplies->supply = reset_supply; >> +supplies->dev_name = phy->phy_id; >> + >> +reg_data = kmemdup(&hsusb_reg_data, sizeof(hsusb_reg_data), >> +GFP_KERNEL); >> +if (!reg_data) >> +return -ENOMEM; >> + >> +reg_data->consumer_supplies = supplies; >> + >> +config = kmemdup(&hsusb_reg_config, sizeof(hsusb_reg_config), >> +GFP_KERNEL); >> +if (!config) >> +return -ENOMEM; >> + >> +supply_name = kmalloc(14, GFP_KERNEL); >> +if (!supply_name) >> +return -ENOMEM; >> + >> +scnprintf(supply_name, 13, "hsusb%d_reset", i); >> +config->supply_name = supply_name; >> +config->gpio = phy->reset_gpio; >> +config->init_data = reg_data; >> + >> +hsusb_reg_pdev_info.data = config; >> +hsusb_reg_pdev_info.size_data = sizeof(hsusb_reg_config); >> +platform_device_register_full(&hsusb_reg_pdev_info); >> + >> +check_vcc: >> +if (!gpio_is_valid(phy->vcc_gpio)) >> +goto next; >> + >> +supplies = kmemdup(hsusb_reg_suppli
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros [130314 08:45]: > > OK. Let me know how the below patch looks. After that, the board code > will look like. > > static struct usbhs_phy_data phy_data[] = { > { > .reset_gpio = 147, > .vcc_gpio = 148 > .vcc_polarity = 1, > .phy_id = "nop_usb_xceiv.2", > }, > {}, /* Terminator */ > }; > > usbhs_init_phys(phy_data); Great, looks good to me. > Patch to implement usbhs_init_phys(); > > diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c > index 5706bdc..b9d6bff 100644 > --- a/arch/arm/mach-omap2/usb-host.c > +++ b/arch/arm/mach-omap2/usb-host.c > @@ -22,8 +22,12 @@ > #include > #include > #include > +#include > +#include > +#include > > #include > +#include Please change these both to linux/io.h and linux/gpio.h. > #include "soc.h" > #include "omap_device.h" > @@ -472,6 +476,141 @@ void __init setup_4430ohci_io_mux(const enum > usbhs_omap_port_mode *port_mode) > } > } > > +static const char *reset_supply = "reset"; > +static const char *vcc_supply = "vcc"; > + > +/* Template for PHY regulators */ > +static struct regulator_consumer_supply hsusb_reg_supplies[] = { > + { /* .supply & .dev_name filled later */ }, > +}; > + > +static struct regulator_init_data hsusb_reg_data = { > + .constraints = { > + .valid_ops_mask = REGULATOR_CHANGE_STATUS, > + }, > + .consumer_supplies = hsusb_reg_supplies, > + .num_consumer_supplies = ARRAY_SIZE(hsusb_reg_supplies), > +}; > + > +static struct fixed_voltage_config hsusb_reg_config = { > + /* .supply_name filled later */ > + .microvolts = 330, > + .gpio = -1, /* updated later */ > + .startup_delay = 7, /* 70msec */ > + .enable_high = 1, /* updated later */ > + .enabled_at_boot = 0, /* keep in RESET */ > + /* .init_data filled later */ > +}; > + > +static struct platform_device_info hsusb_reg_pdev_info = { > + .name = "reg-fixed-voltage", > + .id = PLATFORM_DEVID_AUTO, > +}; > + > +int __init usbhs_init_phys(struct usbhs_phy_data *phy) > +{ > + struct regulator_consumer_supply *supplies; > + struct regulator_init_data *reg_data; > + struct fixed_voltage_config *config; > + char *supply_name; > + int i; > + > + > + for (i = 1; i <= OMAP3_HS_USB_PORTS; i++) { Maybe pass the number of ports to initialize too to the function? Might be more future proof, although it will only be needed until we have converted to DT. > + > + if (!phy->phy_id) /* Terminator ? */ > + break; > + > + if (!gpio_is_valid(phy->reset_gpio)) > + goto check_vcc; > + > + supplies = kmemdup(hsusb_reg_supplies, > + ARRAY_SIZE(hsusb_reg_supplies) * > + sizeof(struct regulator_consumer_supply), > + GFP_KERNEL); > + if (!supplies) > + return -ENOMEM; > + > + supplies->supply = reset_supply; > + supplies->dev_name = phy->phy_id; > + > + reg_data = kmemdup(&hsusb_reg_data, sizeof(hsusb_reg_data), > + GFP_KERNEL); > + if (!reg_data) > + return -ENOMEM; > + > + reg_data->consumer_supplies = supplies; > + > + config = kmemdup(&hsusb_reg_config, sizeof(hsusb_reg_config), > + GFP_KERNEL); > + if (!config) > + return -ENOMEM; > + > + supply_name = kmalloc(14, GFP_KERNEL); > + if (!supply_name) > + return -ENOMEM; > + > + scnprintf(supply_name, 13, "hsusb%d_reset", i); > + config->supply_name = supply_name; > + config->gpio = phy->reset_gpio; > + config->init_data = reg_data; > + > + hsusb_reg_pdev_info.data = config; > + hsusb_reg_pdev_info.size_data = sizeof(hsusb_reg_config); > + platform_device_register_full(&hsusb_reg_pdev_info); > + > +check_vcc: > + if (!gpio_is_valid(phy->vcc_gpio)) > + goto next; > + > + supplies = kmemdup(hsusb_reg_supplies, > + ARRAY_SIZE(hsusb_reg_supplies) * > + sizeof(struct regulator_consumer_supply), > + GFP_KERNEL); > + if (!supplies) > + return -ENOMEM; > + > + supplies->supply = vcc_supply; > + supplies->dev_name = phy->phy_id; > + > + reg_data = kmemdup(&hsusb_reg_data, sizeof(hsusb_reg_data), > + GFP_KERNEL); > + if (!reg_data) > + return -ENOMEM; > + > + reg_data->consumer_supplies = supplies; > + >
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
On 03/13/2013 06:57 PM, Tony Lindgren wrote: > * Roger Quadros [130313 09:40]: >> On 03/13/2013 06:24 PM, Tony Lindgren wrote: >>> * Roger Quadros [130313 06:46]: On 03/12/2013 06:40 PM, Tony Lindgren wrote: > * Roger Quadros [130312 04:47]: >> Hi Tony, >> >> These patches provide the SoC side code required to support >> the changes in the OMAP USB Host drivers done in [1], [2] & [3]. > ... > >> arch/arm/mach-omap2/board-3430sdp.c| 97 >> +++- >> arch/arm/mach-omap2/board-3630sdp.c| 100 >> +++- >> arch/arm/mach-omap2/board-am3517crane.c| 95 >> +-- >> arch/arm/mach-omap2/board-am3517evm.c | 66 ++- >> arch/arm/mach-omap2/board-cm-t35.c | 95 >> ++- >> arch/arm/mach-omap2/board-cm-t3517.c | 97 >> +++- >> arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- >> arch/arm/mach-omap2/board-generic.c| 67 +++ >> arch/arm/mach-omap2/board-igep0020.c | 112 >> --- >> arch/arm/mach-omap2/board-omap3beagle.c| 93 >> +-- >> arch/arm/mach-omap2/board-omap3evm.c | 62 -- >> arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- >> arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- >> arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- >> arch/arm/mach-omap2/board-omap4panda.c | 122 >> ++-- >> arch/arm/mach-omap2/board-overo.c | 54 - >> arch/arm/mach-omap2/board-zoom.c | 56 - > > Can't you have some mach-omap2/ehci-common.c that takes care > of the initializiation to avoid this much addition to the > board-*.c files? You may be able to have just a common function > to do it and pass few parameters? Since we moved reset and power handling for the USB PHYs from omap-echi driver into the USB PHY driver we need to define the regulator data for RESET and Power line of each PHY. So most of the code added is just regulator data for the PHY rather than omap-ehci. >>> >>> It seems that you're now repeating minor variations of the same PHY >>> over and over again though. >> >> Yes it is the vcc and reset regulator data for the PHY that >> is getting repeated with variations in the GPIO number. >> >>> Instead of a common function, I can implement some macros that make it easier to define the regulators for the PHY in the board files. Does this sound OK? Personally I don't like such macros because it hides the implementation and is difficult to read/debug. >>> >>> I'd prefer a common function to initialize the PHY though as it sounds >>> like using macros would just allocate similar PHY many times which seems >>> unnecessary. >>> >> OK, so we want to create the regulator data at runtime to save some memory? >> I'll come up with something. > > Or I guess you can have just one instance that gets filled in by some PHY > platform init function. > OK. Let me know how the below patch looks. After that, the board code will look like. static struct usbhs_phy_data phy_data[] = { { .reset_gpio = 147, .vcc_gpio = 148 .vcc_polarity = 1, .phy_id = "nop_usb_xceiv.2", }, {}, /* Terminator */ }; usbhs_init_phys(phy_data); Patch to implement usbhs_init_phys(); diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c index 5706bdc..b9d6bff 100644 --- a/arch/arm/mach-omap2/usb-host.c +++ b/arch/arm/mach-omap2/usb-host.c @@ -22,8 +22,12 @@ #include #include #include +#include +#include +#include #include +#include #include "soc.h" #include "omap_device.h" @@ -472,6 +476,141 @@ void __init setup_4430ohci_io_mux(const enum usbhs_omap_port_mode *port_mode) } } +static const char *reset_supply = "reset"; +static const char *vcc_supply = "vcc"; + +/* Template for PHY regulators */ +static struct regulator_consumer_supply hsusb_reg_supplies[] = { + { /* .supply & .dev_name filled later */ }, +}; + +static struct regulator_init_data hsusb_reg_data = { + .constraints = { + .valid_ops_mask = REGULATOR_CHANGE_STATUS, + }, + .consumer_supplies = hsusb_reg_supplies, + .num_consumer_supplies = ARRAY_SIZE(hsusb_reg_supplies), +}; + +static struct fixed_voltage_config hsusb_reg_config = { + /* .supply_name filled later */ + .microvolts = 330, + .gpio = -1, /* updated later */ + .startup_delay = 7, /* 70msec */ + .enable_high = 1, /* updated later */ + .enabled_at_boot = 0, /* keep
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros [130313 09:40]: > On 03/13/2013 06:24 PM, Tony Lindgren wrote: > > * Roger Quadros [130313 06:46]: > >> On 03/12/2013 06:40 PM, Tony Lindgren wrote: > >>> * Roger Quadros [130312 04:47]: > Hi Tony, > > These patches provide the SoC side code required to support > the changes in the OMAP USB Host drivers done in [1], [2] & [3]. > >>> ... > >>> > arch/arm/mach-omap2/board-3430sdp.c| 97 > +++- > arch/arm/mach-omap2/board-3630sdp.c| 100 > +++- > arch/arm/mach-omap2/board-am3517crane.c| 95 > +-- > arch/arm/mach-omap2/board-am3517evm.c | 66 ++- > arch/arm/mach-omap2/board-cm-t35.c | 95 > ++- > arch/arm/mach-omap2/board-cm-t3517.c | 97 > +++- > arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- > arch/arm/mach-omap2/board-generic.c| 67 +++ > arch/arm/mach-omap2/board-igep0020.c | 112 > --- > arch/arm/mach-omap2/board-omap3beagle.c| 93 > +-- > arch/arm/mach-omap2/board-omap3evm.c | 62 -- > arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- > arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- > arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- > arch/arm/mach-omap2/board-omap4panda.c | 122 > ++-- > arch/arm/mach-omap2/board-overo.c | 54 - > arch/arm/mach-omap2/board-zoom.c | 56 - > >>> > >>> Can't you have some mach-omap2/ehci-common.c that takes care > >>> of the initializiation to avoid this much addition to the > >>> board-*.c files? You may be able to have just a common function > >>> to do it and pass few parameters? > >> > >> Since we moved reset and power handling for the USB PHYs from omap-echi > >> driver into the USB PHY driver we need to define the regulator data > >> for RESET and Power line of each PHY. So most of the code added is just > >> regulator data for the PHY rather than omap-ehci. > > > > It seems that you're now repeating minor variations of the same PHY > > over and over again though. > > Yes it is the vcc and reset regulator data for the PHY that > is getting repeated with variations in the GPIO number. > > > > >> Instead of a common function, I can implement some macros that make it > >> easier to define the regulators for the PHY in the board files. > >> Does this sound OK? > >> > >> Personally I don't like such macros because it hides the implementation > >> and is difficult to read/debug. > > > > I'd prefer a common function to initialize the PHY though as it sounds > > like using macros would just allocate similar PHY many times which seems > > unnecessary. > > > OK, so we want to create the regulator data at runtime to save some memory? > I'll come up with something. Or I guess you can have just one instance that gets filled in by some PHY platform init function. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
On 03/13/2013 06:24 PM, Tony Lindgren wrote: > * Roger Quadros [130313 06:46]: >> On 03/12/2013 06:40 PM, Tony Lindgren wrote: >>> * Roger Quadros [130312 04:47]: Hi Tony, These patches provide the SoC side code required to support the changes in the OMAP USB Host drivers done in [1], [2] & [3]. >>> ... >>> arch/arm/mach-omap2/board-3430sdp.c| 97 +++- arch/arm/mach-omap2/board-3630sdp.c| 100 +++- arch/arm/mach-omap2/board-am3517crane.c| 95 +-- arch/arm/mach-omap2/board-am3517evm.c | 66 ++- arch/arm/mach-omap2/board-cm-t35.c | 95 ++- arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- arch/arm/mach-omap2/board-generic.c| 67 +++ arch/arm/mach-omap2/board-igep0020.c | 112 --- arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- arch/arm/mach-omap2/board-omap3evm.c | 62 -- arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- arch/arm/mach-omap2/board-omap4panda.c | 122 ++-- arch/arm/mach-omap2/board-overo.c | 54 - arch/arm/mach-omap2/board-zoom.c | 56 - >>> >>> Can't you have some mach-omap2/ehci-common.c that takes care >>> of the initializiation to avoid this much addition to the >>> board-*.c files? You may be able to have just a common function >>> to do it and pass few parameters? >> >> Since we moved reset and power handling for the USB PHYs from omap-echi >> driver into the USB PHY driver we need to define the regulator data >> for RESET and Power line of each PHY. So most of the code added is just >> regulator data for the PHY rather than omap-ehci. > > It seems that you're now repeating minor variations of the same PHY > over and over again though. Yes it is the vcc and reset regulator data for the PHY that is getting repeated with variations in the GPIO number. > >> Instead of a common function, I can implement some macros that make it >> easier to define the regulators for the PHY in the board files. >> Does this sound OK? >> >> Personally I don't like such macros because it hides the implementation >> and is difficult to read/debug. > > I'd prefer a common function to initialize the PHY though as it sounds > like using macros would just allocate similar PHY many times which seems > unnecessary. > OK, so we want to create the regulator data at runtime to save some memory? I'll come up with something. cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros [130313 06:46]: > On 03/12/2013 06:40 PM, Tony Lindgren wrote: > > * Roger Quadros [130312 04:47]: > >> Hi Tony, > >> > >> These patches provide the SoC side code required to support > >> the changes in the OMAP USB Host drivers done in [1], [2] & [3]. > > ... > > > >> arch/arm/mach-omap2/board-3430sdp.c| 97 +++- > >> arch/arm/mach-omap2/board-3630sdp.c| 100 +++- > >> arch/arm/mach-omap2/board-am3517crane.c| 95 +-- > >> arch/arm/mach-omap2/board-am3517evm.c | 66 ++- > >> arch/arm/mach-omap2/board-cm-t35.c | 95 ++- > >> arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- > >> arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- > >> arch/arm/mach-omap2/board-generic.c| 67 +++ > >> arch/arm/mach-omap2/board-igep0020.c | 112 > >> --- > >> arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- > >> arch/arm/mach-omap2/board-omap3evm.c | 62 -- > >> arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- > >> arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- > >> arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- > >> arch/arm/mach-omap2/board-omap4panda.c | 122 > >> ++-- > >> arch/arm/mach-omap2/board-overo.c | 54 - > >> arch/arm/mach-omap2/board-zoom.c | 56 - > > > > Can't you have some mach-omap2/ehci-common.c that takes care > > of the initializiation to avoid this much addition to the > > board-*.c files? You may be able to have just a common function > > to do it and pass few parameters? > > Since we moved reset and power handling for the USB PHYs from omap-echi > driver into the USB PHY driver we need to define the regulator data > for RESET and Power line of each PHY. So most of the code added is just > regulator data for the PHY rather than omap-ehci. It seems that you're now repeating minor variations of the same PHY over and over again though. > Instead of a common function, I can implement some macros that make it > easier to define the regulators for the PHY in the board files. > Does this sound OK? > > Personally I don't like such macros because it hides the implementation > and is difficult to read/debug. I'd prefer a common function to initialize the PHY though as it sounds like using macros would just allocate similar PHY many times which seems unnecessary. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
On 03/12/2013 06:40 PM, Tony Lindgren wrote: > * Roger Quadros [130312 04:47]: >> Hi Tony, >> >> These patches provide the SoC side code required to support >> the changes in the OMAP USB Host drivers done in [1], [2] & [3]. > ... > >> arch/arm/mach-omap2/board-3430sdp.c| 97 +++- >> arch/arm/mach-omap2/board-3630sdp.c| 100 +++- >> arch/arm/mach-omap2/board-am3517crane.c| 95 +-- >> arch/arm/mach-omap2/board-am3517evm.c | 66 ++- >> arch/arm/mach-omap2/board-cm-t35.c | 95 ++- >> arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- >> arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- >> arch/arm/mach-omap2/board-generic.c| 67 +++ >> arch/arm/mach-omap2/board-igep0020.c | 112 >> --- >> arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- >> arch/arm/mach-omap2/board-omap3evm.c | 62 -- >> arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- >> arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- >> arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- >> arch/arm/mach-omap2/board-omap4panda.c | 122 >> ++-- >> arch/arm/mach-omap2/board-overo.c | 54 - >> arch/arm/mach-omap2/board-zoom.c | 56 - > > Can't you have some mach-omap2/ehci-common.c that takes care > of the initializiation to avoid this much addition to the > board-*.c files? You may be able to have just a common function > to do it and pass few parameters? Since we moved reset and power handling for the USB PHYs from omap-echi driver into the USB PHY driver we need to define the regulator data for RESET and Power line of each PHY. So most of the code added is just regulator data for the PHY rather than omap-ehci. Instead of a common function, I can implement some macros that make it easier to define the regulators for the PHY in the board files. Does this sound OK? Personally I don't like such macros because it hides the implementation and is difficult to read/debug. cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros [130312 04:47]: > Hi Tony, > > These patches provide the SoC side code required to support > the changes in the OMAP USB Host drivers done in [1], [2] & [3]. ... > arch/arm/mach-omap2/board-3430sdp.c| 97 +++- > arch/arm/mach-omap2/board-3630sdp.c| 100 +++- > arch/arm/mach-omap2/board-am3517crane.c| 95 +-- > arch/arm/mach-omap2/board-am3517evm.c | 66 ++- > arch/arm/mach-omap2/board-cm-t35.c | 95 ++- > arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- > arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- > arch/arm/mach-omap2/board-generic.c| 67 +++ > arch/arm/mach-omap2/board-igep0020.c | 112 --- > arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- > arch/arm/mach-omap2/board-omap3evm.c | 62 -- > arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- > arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- > arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- > arch/arm/mach-omap2/board-omap4panda.c | 122 > ++-- > arch/arm/mach-omap2/board-overo.c | 54 - > arch/arm/mach-omap2/board-zoom.c | 56 - Can't you have some mach-omap2/ehci-common.c that takes care of the initializiation to avoid this much addition to the board-*.c files? You may be able to have just a common function to do it and pass few parameters? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Tony, These patches provide the SoC side code required to support the changes in the OMAP USB Host drivers done in [1], [2] & [3]. Device tree support is added for Beagleboard and Panda. NOTE: The first patch needs to be shared between the OMAP tree and Felipe's USB tree. [1] MFD side changes to omap-usb-host and omap-usb-tll https://lkml.org/lkml/2013/3/12/179 [2] USB EHCI side changes to ehci-omap http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86265.html [3] USB PHY driver changes http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86293.html The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://github.com/rogerq/linux.git usbhost-arm-next Roger Quadros (24): usb: phy: nop: Add some parameters to platform data ARM: OMAP2+: omap4panda: Provide USB Host's PHY platform data ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes ARM: OMAP3: Beagle: Adapt to ehci-omap changes ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes ARM: OMAP: AM3517crane: Adapt to ehci-omap changes ARM: OMAP: AM3517evm: Adapt to ehci-omap changes ARM: OMAP3: cm-t35: Adapt to ehci-omap changes ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes ARM: OMAP: devkit8000: Adapt to ehci-omap changes ARM: OMAP3: igep0020: Adapt to ehci-omap changes ARM: OMAP3: omap3evm: Adapt to ehci-omap changes ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes ARM: OMAP3: overo: Adapt to ehci-omap changes ARM: OMAP: zoom: Adapt to ehci-omap changes ARM: dts: OMAP4: Add HS USB Host IP nodes ARM: dts: omap4-panda: Add USB Host support ARM: dts: OMAP3: Add HS USB Host IP nodes ARM: dts: omap3-beagle: Add USB Host support ARM: OMAP2+: Allow clock alias provision from device tree ARM: dts: omap4-panda: Add clock alias for USB PHY .../devicetree/bindings/clock/ti-clock-alias.txt | 26 arch/arm/boot/dts/omap3-beagle.dts | 71 +++ arch/arm/boot/dts/omap3.dtsi | 31 + arch/arm/boot/dts/omap4-panda.dts | 63 ++ arch/arm/boot/dts/omap4.dtsi | 30 + arch/arm/mach-omap2/board-3430sdp.c| 97 +++- arch/arm/mach-omap2/board-3630sdp.c| 100 +++- arch/arm/mach-omap2/board-am3517crane.c| 95 +-- arch/arm/mach-omap2/board-am3517evm.c | 66 ++- arch/arm/mach-omap2/board-cm-t35.c | 95 ++- arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- arch/arm/mach-omap2/board-generic.c| 67 +++ arch/arm/mach-omap2/board-igep0020.c | 112 --- arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- arch/arm/mach-omap2/board-omap3evm.c | 62 -- arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- arch/arm/mach-omap2/board-omap4panda.c | 122 ++-- arch/arm/mach-omap2/board-overo.c | 54 - arch/arm/mach-omap2/board-zoom.c | 56 - include/linux/usb/nop-usb-xceiv.h |5 + 23 files changed, 1377 insertions(+), 151 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti-clock-alias.txt -- cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss