Re: [RESEND PATCH 2/4] omap: igep0020: minor refactoring
2011/5/15 Arnd Bergmann : > On Sunday 15 May 2011, m...@compulab.co.il wrote: >> We can keep all the data structures that differ between IGEP2 and IGEP3. >> However, this significantly reduces the benifit of the series. >> There's already code in the IGEP2 that differentiates between HW >> revisions, so anyway the board support will require some work for >> devicetree transition. Eventually, when devicetree will be usable on >> OMAPs, most of the code currently found in arch/arm/mach-omap2/board* >> will require some work and I hardly believe that the transition can be >> automated... > > True. Let's just use the version you posted then. > > Arnd > Acked-by: Enric Balletbo i Serra -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 2/4] omap: igep0020: minor refactoring
On Sunday 15 May 2011, m...@compulab.co.il wrote: > We can keep all the data structures that differ between IGEP2 and IGEP3. > However, this significantly reduces the benifit of the series. > There's already code in the IGEP2 that differentiates between HW > revisions, so anyway the board support will require some work for > devicetree transition. Eventually, when devicetree will be usable on > OMAPs, most of the code currently found in arch/arm/mach-omap2/board* > will require some work and I hardly believe that the transition can be > automated... True. Let's just use the version you posted then. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 2/4] omap: igep0020: minor refactoring
On Fri, May 13, 2011 at 08:44:38PM +0200, Arnd Bergmann wrote:
> On Thursday 12 May 2011, Mike Rapoport wrote:
> > @@ -299,17 +299,14 @@ static struct omap2_hsmmc_info mmc[] = {
> > static struct gpio_led igep_gpio_leds[] = {
> > [0] = {
> > .name = "gpio-led:red:d0",
> > - .gpio = IGEP2_GPIO_LED0_RED,
> > .default_trigger= "default-off"
> > },
> > [1] = {
> > .name = "gpio-led:green:d0",
> > - .gpio = IGEP2_GPIO_LED0_GREEN,
> > .default_trigger= "default-off",
> > },
> > [2] = {
> > .name = "gpio-led:red:d1",
> > - .gpio = IGEP2_GPIO_LED1_RED,
> > .default_trigger= "default-off",
> > },
> > [3] = {
> > @@ -335,6 +332,10 @@ static struct platform_device igep_led_device = {
> >
> > static void __init igep_leds_init(void)
> > {
> > + igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
> > + igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
> > + igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
> > +
> > platform_device_register(&igep_led_device);
> > }
>
> Hi Mike,
>
> Overall, the series looks great, but I'm somewhat worried by the fact that you
> have to replace data structures with code in order to get there. Are there any
> other options to do this?
We can keep all the data structures that differ between IGEP2 and IGEP3.
However, this significantly reduces the benifit of the series.
There's already code in the IGEP2 that differentiates between HW
revisions, so anyway the board support will require some work for
devicetree transition. Eventually, when devicetree will be usable on
OMAPs, most of the code currently found in arch/arm/mach-omap2/board*
will require some work and I hardly believe that the transition can be
automated...
> Arnd
>
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 2/4] omap: igep0020: minor refactoring
On Thursday 12 May 2011, Mike Rapoport wrote:
> @@ -299,17 +299,14 @@ static struct omap2_hsmmc_info mmc[] = {
> static struct gpio_led igep_gpio_leds[] = {
> [0] = {
> .name = "gpio-led:red:d0",
> - .gpio = IGEP2_GPIO_LED0_RED,
> .default_trigger= "default-off"
> },
> [1] = {
> .name = "gpio-led:green:d0",
> - .gpio = IGEP2_GPIO_LED0_GREEN,
> .default_trigger= "default-off",
> },
> [2] = {
> .name = "gpio-led:red:d1",
> - .gpio = IGEP2_GPIO_LED1_RED,
> .default_trigger= "default-off",
> },
> [3] = {
> @@ -335,6 +332,10 @@ static struct platform_device igep_led_device = {
>
> static void __init igep_leds_init(void)
> {
> + igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
> + igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
> + igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
> +
> platform_device_register(&igep_led_device);
> }
Hi Mike,
Overall, the series looks great, but I'm somewhat worried by the fact that you
have to replace data structures with code in order to get there. Are there any
other options to do this?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
