public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: tony@atomide.com
To: Brian Swetland <swetland@google.com>
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: patches for fsample/850
Date: Sun, 9 Apr 2006 11:36:17 -0700	[thread overview]
Message-ID: <20060409183557.GF5032@atomide.com> (raw)
In-Reply-To: <20060408154425.GA24843@localhost.localdomain>

Hi,

Few comments below.

* Brian Swetland <swetland@google.com> [060408 08:45]:
> --- linux-omap-2.6/arch/arm/mach-omap1/clock.h	2006-04-05 10:33:20.000000000 -0700
> +++ linux-omap-fsample/arch/arm/mach-omap1/clock.h	2006-04-06 13:15:34.000000000 -0700
> @@ -101,44 +101,50 @@
>  /*-------------------------------------------------------------------------
>   * Omap1 MPU rate table
>   *-------------------------------------------------------------------------*/
> +#if defined(CONFIG_ARCH_OMAP730)
> +	#define CKCTL_RESERVED_1_MASK (0x2000)
> +#else
> +	#define CKCTL_RESERVED_1_MASK (0x0000)
> +#endif

This addds yet another extra hurdle compiling 730 in with 15xx and 16xx.
Although we cannot do it because of the interrupt handler, maybe we'll
fix that someday. So let's try not to add more hurdles if we can avoid
it.

How about doing the masking when the CKCTL value is written based on the
cpu_is_omap730()?

> --- linux-omap-2.6/arch/arm/mach-omap1/pm.c	2006-04-05 10:33:20.000000000 -0700
> +++ linux-omap-fsample/arch/arm/mach-omap1/pm.c	2006-04-06 13:15:34.000000000 -0700
> @@ -326,8 +326,10 @@
>  	/* stop DSP */
>  	omap_writew(omap_readw(ARM_RSTCT1) & ~(1 << DSP_EN), ARM_RSTCT1);
>  
> +#if !defined(CONFIG_ARCH_OMAP730)
>  	/* shut down dsp_ck */
>  	omap_writew(omap_readw(ARM_CKCTL) & ~(1 << EN_DSPCK), ARM_CKCTL);
> +#endif

This too would be better with if (!cpu_is_omap730()).
 
> @@ -189,8 +197,6 @@
>  	omap_writel(value, OMAP730_IO_CONF_4);
>  
>  	omap_uwire_configure_mode(0,16);
> -
> -	omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_DISOFF, 9, 0,NULL,1);
>  	omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_SLPIN, 9, 0,NULL,1);
>  	omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_DISNOR, 9, 0,NULL,1);
>  	omap_uwire_data_transfer(LCD_UWIRE_CS, LCD_GSSET, 9, 0,NULL,1);

Is the removal of one of the omap_uwire_data_transfer() calls intended?

Then does it compile and boot for p2 and fsample both selected?

Also, could you please do one patch for the core support, and then
another patch for files that don't touch the omap core files?

That way we can send you patch directly upstream when we merge next
time. Otherwise I have to redo the patch to strip out the drivers when
we merge as not many omap drivers are yet merged with the mainline tree.

Core files being arch/arm/*omap* and include/asm-arm/arch-omap:

arch/arm/mach-omap1/Kconfig
arch/arm/mach-omap1/Makefile
arch/arm/mach-omap1/board-fsample.c
arch/arm/mach-omap1/clock.c
arch/arm/mach-omap1/clock.h
arch/arm/mach-omap1/pm.c
arch/arm/mach-omap1/time.c
arch/arm/plat-omap/devices.c
include/asm-arm/arch-omap/board-fsample.h
include/asm-arm/arch-omap/hardware.h

Regards,

Tony

  reply	other threads:[~2006-04-09 18:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-07 22:06 patches for fsample/850 Brian Swetland
2006-04-08 11:00 ` Komal Shah
2006-04-08 15:44   ` Brian Swetland
2006-04-09 18:36     ` tony [this message]
2006-04-09 21:05       ` Brian Swetland
2006-04-13 10:17         ` tony
2006-04-13 17:40           ` Brian Swetland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060409183557.GF5032@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-omap-open-source@linux.omap.com \
    --cc=swetland@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox