date:20090508

Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

2009-05-08 Thread Hemanth V

- Original Message - 
From: Shilimkar, Santosh santosh.shilim...@ti.com
To: V, Hemanth heman...@ti.com; 
linux-arm-ker...@lists.arm.linux.org.uk

Cc: linux-omap@vger.kernel.org
Sent: Friday, May 08, 2009 11:18 AM
Subject: RE: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files



-Original Message-
From: V, Hemanth
Sent: Friday, May 08, 2009 11:16 AM
To: Shilimkar, Santosh; linux-arm-ker...@lists.arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

 Original Message - 
From: Santosh Shilimkar santosh.shilim...@ti.com

Subject: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files


 diff --git a/arch/arm/mach-omap2/omap-headsmp.S
 b/arch/arm/mach-omap2/omap-headsmp.S
 new file mode 100644
 index 000..0afe039
 --- /dev/null
 +++ b/arch/arm/mach-omap2/omap-headsmp.S
 @@ -0,0 +1,49 @@
 +/*
 + * Secondary CPU startup routine source file.
 + *
 + * Copyright (C) 2009 Texas Instruments, Inc.
 + *
 + * Author:
 + *  Santosh Shilimkar santosh.shilim...@ti.com
 + *
 + * Interface functions needed for the SMP. This file is
based on arm
 + * realview smp platform.
 + * Copyright (c) 2003 ARM Limited.
 + *
 + * 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 linux/linkage.h
 +#include linux/init.h
 +
 + __INIT
 +
 +/*
 + * OMAP4 specific entry point for secondary CPU to jump from ROM
 + * code.  This routine also provides a holding flag into which
 + * secondary core is held until we're ready for it to initialise.
 + * The primary core will update the this flag using a hardware
 + * register AuxCoreBoot1.
 + */

Is initialization done by u-boot like icache_enable taken
care somewhere
for the secondary cpu.


U-boot has no knowledge of secondary CPUs. Kernel takes care of it with 
help of ROM code.


For my information could you pl point to the routine which does this, i.e 
enable instruction cache on the secondary cpu. 


--
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: Status of Beagle Board

2009-05-08 Thread Hiremath, Vaibhav

 -Original Message-
 From: George.Qiao [mailto:qiao_shans...@visualon.com]
 Sent: Friday, May 08, 2009 11:57 AM
 To: Hiremath, Vaibhav
 Cc: Syed Mohammed, Khasim; Shah, Hardik; wan_jin...@visualon.com;
 Bill Lin; shawnofarr...@visualon.com; Chatterjee, Amit; Andrews,
 Gerard; Kridner, Jason; 'Bangfei Jin'; 'Xuejun Dong'; 'YangCai';
 linux-omap@vger.kernel.org
 Subject: Re: Status of Beagle Board

 Hi Vaibhav Hiremath,

 My application can work in OMAP3 EVM and other v4l2 platform, but
 there
 is another issue in beagle board. as follow:

[Hiremath, Vaibhav] Are you saying, same application works on OMAP3EVM but 
fails on beagle board?

 1. NormalSize() - RequestBuffer() - mmap()
 2. playing...
 3. FullScreen() - VIDIOC_STREAMOFF
   - munmap()
   - VIDIOC_REQBUFS
   - VIDIOC_QUERYBUF
   - RequestBuffer() - mmap()
   - VIDIOC_S_CROP
   - VIDIOC_S_FMT
   - VIDIOC_QBUF
   - VIDIOC_STREAMON

 When I want to call VIDIOC_REQBUFS in FullScreen(), it always fail.

[Hiremath, Vaibhav] Is it possible for you to share your application, so that I 
can give try here at my end?

Thanks,
Vaibhav Hiremath

 Best Regards,
 George.Qiao

  Great, please see my comments in-lined below -

  Thanks,
  Vaibhav Hiremath
  Platform Support Products
  Texas Instruments Inc
  Ph: +91-80-25099927

  -Original Message-
  From: George.Qiao [mailto:qiao_shans...@visualon.com]
  Sent: Thursday, May 07, 2009 3:51 PM
  To: Hiremath, Vaibhav
  Cc: Syed Mohammed, Khasim; Shah, Hardik; wan_jin...@visualon.com;
  Bill Lin; shawnofarr...@visualon.com; Chatterjee, Amit; Andrews,
  Gerard; Kridner, Jason; 'Bangfei Jin'; 'Xuejun Dong'; 'YangCai';
  linux-omap-open-sou...@linux.omap.com
  Subject: Re: Status of Beagle Board

  Dear Vaibhav Hiremath,

  I can play video by v4l2 now!  Thank you!

  I have add code in board-omap3beagle.c :

  #ifdef CONFIG_FB_OMAP2
  static struct resource omap3beagle_vout_resource[3 -
  CONFIG_FB_OMAP2_NUM_FBS] = {
  };
  #else
  static struct resource omap3beagle_vout_resource[2] = {
  };
  #endif

  static struct platform_device omap3beagle_vout_device = {
 .name   = omap_vout,
 .num_resources  = ARRAY_SIZE(omap3beagle_vout_resource),
 .resource   = omap3beagle_vout_resource[0],
 .id = -1,
  };

  static struct platform_device *omap3_beagle_devices[] __initdata
 = {
  beagle_dss_device,
  leds_gpio,
  keys_gpio,
  omap3beagle_vout_device,
  };

  I have got some omapdss error and voutBuffer Size. as follow:

  omapdss: Could not find exact pixel clock. Requested 23500 kHz,
 got
  24000 kHz
  omapdss error: display already enabled
  omap_voutDisplay already enabled
  omapdss error: display already enabled
  omap_voutDisplay already enabled

  [Hiremath, Vaibhav] This is not an error as such, it warning
 message. Actually here we are trying to enable the display which has
 already been enabled by Fbdev.
  We can suppress this message, atleast during init.

  omap_voutBuffer Size = 3686400
  omap_vout: registered and initialized video device 0 [v4l2]
  omap_voutBuffer Size = 3686400
  omap_vout: registered and initialized video device 1 [v4l2]

  [Hiremath, Vaibhav] This is just a debug massage; it is neither a
 error nor a warning. So don't worry.

  Can you share the code-base or submit the patches to the list, so
 that interested people can use it.

  Could I change 'voutBuffer Size'?  How to fix it?

  Best Regards,
  George.Qiao

  ===

  Yes Definitely this is the issue. If the platform_device.name

  doesn't match with the platform_driver.driver.name then your
 probe
  function will not be called at all.

  Can you just copy the board-omap3evm.c changes related to

  V4L2/DSS2 and give a shot? I think it should work straight away.

  Please let me know if you need any further clarification or
 help.

  Thanks,
  Vaibhav Hiremath
  Platform Support Products
  Texas Instruments Inc
  Ph: +91-80-25099927

  -Original Message-
  From: George.Qiao [mailto:qiao_shans...@visualon.com]
  Sent: Thursday, May 07, 2009 12:55 PM
  To: Hiremath, Vaibhav
  Cc: Syed Mohammed, Khasim; Shah, Hardik;
 wan_jin...@visualon.com;
  Bill Lin; shawnofarr...@visualon.com; Chatterjee, Amit;
 Andrews,
  Gerard; Kridner, Jason; 'Bangfei Jin'; 'Xuejun Dong';
 'YangCai';
  linux-omap-open-sou...@linux.omap.com
  Subject: Re: Status of Beagle Board

  Hi Hiremath, Vaibhav,

  Thank you very much for your instant response!

  I've checked the file 'board-omap3beagle.c' and found nothing
  looking
  like omap_vout in it, no platform_device, either. And I've also
  compared
  it with board-omap3evm.c.

  Below is some difference between

Re: Status of Beagle Board

2009-05-08 Thread George.Qiao


Hi Vaibhav Hiremath,

My application can work in OMAP3 EVM and other v4l2 platform, but there 
is another issue in beagle board. as follow:


1. NormalSize() - RequestBuffer() - mmap()
2. playing...
3. FullScreen() - VIDIOC_STREAMOFF
 - munmap()
 - VIDIOC_REQBUFS
 - VIDIOC_QUERYBUF
 - RequestBuffer() - mmap()
 - VIDIOC_S_CROP
 - VIDIOC_S_FMT
 - VIDIOC_QBUF
 - VIDIOC_STREAMON

When I want to call VIDIOC_REQBUFS in FullScreen(), it always fail.


Best Regards,
George.Qiao


Great, please see my comments in-lined below - 



Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927

  

-Original Message-
From: George.Qiao [mailto:qiao_shans...@visualon.com]
Sent: Thursday, May 07, 2009 3:51 PM
To: Hiremath, Vaibhav
Cc: Syed Mohammed, Khasim; Shah, Hardik; wan_jin...@visualon.com;
Bill Lin; shawnofarr...@visualon.com; Chatterjee, Amit; Andrews,
Gerard; Kridner, Jason; 'Bangfei Jin'; 'Xuejun Dong'; 'YangCai';
linux-omap-open-sou...@linux.omap.com
Subject: Re: Status of Beagle Board

Dear Vaibhav Hiremath,

I can play video by v4l2 now!  Thank you!

I have add code in board-omap3beagle.c :

#ifdef CONFIG_FB_OMAP2
static struct resource omap3beagle_vout_resource[3 -
CONFIG_FB_OMAP2_NUM_FBS] = {
};
#else
static struct resource omap3beagle_vout_resource[2] = {
};
#endif

static struct platform_device omap3beagle_vout_device = {
   .name   = omap_vout,
   .num_resources  = ARRAY_SIZE(omap3beagle_vout_resource),
   .resource   = omap3beagle_vout_resource[0],
   .id = -1,
};

static struct platform_device *omap3_beagle_devices[] __initdata = {
beagle_dss_device,
leds_gpio,
keys_gpio,
omap3beagle_vout_device,
};


I have got some omapdss error and voutBuffer Size. as follow:

omapdss: Could not find exact pixel clock. Requested 23500 kHz, got
24000 kHz
omapdss error: display already enabled
omap_voutDisplay already enabled
omapdss error: display already enabled
omap_voutDisplay already enabled




[Hiremath, Vaibhav] This is not an error as such, it warning message. Actually here we are trying to enable the display which has already been enabled by Fbdev. 
We can suppress this message, atleast during init.


  

omap_voutBuffer Size = 3686400
omap_vout: registered and initialized video device 0 [v4l2]
omap_voutBuffer Size = 3686400
omap_vout: registered and initialized video device 1 [v4l2]




[Hiremath, Vaibhav] This is just a debug massage; it is neither a error nor a 
warning. So don't worry.

Can you share the code-base or submit the patches to the list, so that 
interested people can use it.

  

Could I change 'voutBuffer Size'?  How to fix it?

Best Regards,
George.Qiao

===


Yes Definitely this is the issue. If the platform_device.name
  

doesn't match with the platform_driver.driver.name then your probe
function will not be called at all.


Can you just copy the board-omap3evm.c changes related to
  

V4L2/DSS2 and give a shot? I think it should work straight away.


Please let me know if you need any further clarification or help.

Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927


  

-Original Message-
From: George.Qiao [mailto:qiao_shans...@visualon.com]
Sent: Thursday, May 07, 2009 12:55 PM
To: Hiremath, Vaibhav
Cc: Syed Mohammed, Khasim; Shah, Hardik; wan_jin...@visualon.com;
Bill Lin; shawnofarr...@visualon.com; Chatterjee, Amit; Andrews,
Gerard; Kridner, Jason; 'Bangfei Jin'; 'Xuejun Dong'; 'YangCai';
linux-omap-open-sou...@linux.omap.com
Subject: Re: Status of Beagle Board

Hi Hiremath, Vaibhav,

Thank you very much for your instant response!

I've checked the file 'board-omap3beagle.c' and found nothing
looking
like omap_vout in it, no platform_device, either. And I've also
compared
it with board-omap3evm.c.

Below is some difference between them:

board-omap3evm.c has:
*+static struct platform_device omap3evm_vout_device = {
**+   .name   = omap_vout,
...
}
*
But 'board-omap3beagle.c' does not have anything looking like:

*+static struct platform_device omap3beagle_vout_device = {*
*+   .name   = omap_vout,
...
}
*
So, I think there's no patch on V4L2 for beagle done and this is


the


root cause of this issue. Do you agree with me? Thanks a lot.


Best Regards,
George.Qiao
===




Hi George,

I have looked into your config file and it looks ok to me.

Can you conform that, you have added platform_device
  

definitions


in board-omap3beagle.c?



Can you please create complete patch on top of your baseline (O-
  

L


and Tomi's tree), so

RE: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

2009-05-08 Thread Shilimkar, Santosh

 Subject: RE: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

  -Original Message-
  From: V, Hemanth
  Sent: Friday, May 08, 2009 11:16 AM
  To: Shilimkar, Santosh; linux-arm-ker...@lists.arm.linux.org.uk
  Cc: linux-omap@vger.kernel.org
  Subject: Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

 U-boot has no knowledge of secondary CPUs. Kernel takes 
 care of it with 
 help of ROM code.

 For my information could you pl point to the routine which 
 does this, i.e 
 enable instruction cache on the secondary cpu. 
This is done using __enable_mmu in head.S. Bye the way even if the u-boot don't 
enable I-cache , D-caches, kernel does that anyways depending on settings.--
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: Beagleboard rev C memory timings suspend/resume

2009-05-08 Thread Jean Pihet

Paul,

On Thursday 07 May 2009 20:59:43 Paul Walmsley wrote:
 Hello Jean

 On Thu, 7 May 2009, Jean Pihet wrote:
  From the OMAP datasheet it looks like the ARCV setting is off: shouldn't
  it be (tREFI/tCK)+50=(7800/6)+50=0x546?

 Could you elaborate further what you're seeing?  It would help to
 see the register value that you're using to come to this conclusion.
The SDRC_RFR_CTRL_p registers are now programmed with 0x4dc01, which means the 
fiel ARCV has the value 0x4dc=1244.
From the DDR datasheet we need an average refresh period of 7.8us and a clock 
period of 6ns (166MHz). From the definition of the ARCV field in the OMAP TRM 
I need to program ARCV with: (tREFI/tCK)+50 = (7800/6)+50=1350=0x546.
The SDRC_RFR_CTRL_p registers would then have the value of 0x54601.

Does that make sense? Am I wrong with the calculation?


 - Paul
Regards,
Jean

  Is there a way to know if the self refresh works on both parts?
 
  Regards,
  Jean
 
  On Thursday 07 May 2009 13:18:30 Jean Pihet wrote:
   Hi Paul,
  
   On Thursday 07 May 2009 01:39:02 Paul Walmsley wrote:
Hello Jean,
   
sorry about the delay,
  
   Thanks for replying!
  
On Wed, 29 Apr 2009, Jean Pihet wrote:
 The suspend/resume on Beagleboard has some problem due to bad
 memory timings. Suspending for more than 5 to 10 seconds shows
 memory corruption.

 The new chips on rev Cx boards are using 2 DDR chip selects and it
 looks like the 2nd memory part is not correctly put into self
 refresh. As an experimentation I tried the same kernel with
 'mem=128M' and it resumes correctly after 1 min in suspend.
   
Nice work, this seems likely to be the cause.
   
 I could not find the latest DDR detailed specs from Micron. The
 part number is MT29C2G48MAKLCJI-6 IT. Are those available? Is this
 part identical to 2 1Gb parts?
   
The combined part's web page is:
   
http://www.micron.com/products/partdetail?part=MT29C2G48MAKLCJI-6%20I
   T
   
The SDRAM datasheet is the same that is used for all the other Micron
parts that we've run across so far:
   
http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_
   sdra m_ t48m.pdf
  
   Ok so we have 2 DDRs combined.
   That does not explain why the self-refresh is ok with only 1 part while
   it fails with the 2 parts.
   Could it be that the timings are too tight? Is there something special
   for the SDRC to support the 2 CSes correctly?
  
   We already have used the self refresh with 2 parts hooked on a 3430,
   not Micron parts though, so the code looks correct.
  
   I think we need help from the HW vendors here to identify the root
   cause: SDRC, DDR parts, connections?
  
 Now for the code in the kernel, there are some changes needed to
 support 2 CS'es:
 - the SDRC parameters need to be updated for the new memory part
 - the SDRC parameters need to include the ACTIM_CTRL_A_0,
 ACTIM_CTRL_A_1, ACTIM_CTRL_B_0, ACTIM_CTRL_B_1, RFR_CTRL_0 and
 RFR_CTRL_1 registers. Since the parameters for the 2nd CS are the
 same, this can be avoided by writing the same values to the 2 sets
 of registers
 - is there a need to differentiate between 1Gb and 2Gb chips, or
 can we just write the same params for both CS'es even if only one
 is being used? - the 'configure_sdrc' function in
 arch/arm/mach-omap2/sram34xx.S needs to program the 2 sets of
 registers. Here is a patch excerpt below. This patch only does not
 help the suspend/resume though.

 Any idea or suggestion?
   
Looks like a good start.  Since the two SDRC chip-selects can
technically address parts with different timings, we should not
assume that the two chip selects will be the same.  Admittedly this
seems like an unlikely situation, but it's not impossible for non-POP
OMAPs.
  
   Makes sense. It is better to have correct and generic code.
  
Re: suspend/resume, if you're talking about the code in sleep34xx.S,
it looks like this is already in good shape.
   
Re: board  SDRC changes: would suggest modifying omap2_sdrc_init()
to take either two struct omap_sdrc_params pointers, or one struct
with two pointers.  omap2_init_common_hw() will also need to be
updated for that, and all of the board-*.c files also.
   
Sound reasonable?
  
   Sure. I can write the new code, but I prefer to have the self refresh
   working first.
  
 ldr r11, omap3_sdrc_mr_0
 str r6, [r11]
 ldr r6, [r11]   @ posted-write barrier for
 SDRC +   ldr r11, omap3_sdrc_mr_1
 +   str r6, [r11]
 +   ldr r6, [r11]   @ posted-write barrier for
 SDRC bx  lr
   
By the way, there's no need to duplicate the posted-write barrier. 
There should only be one, appearing right before the 'bx lr'.
  
   Ok I will take it into account.
  
regards,
   
- Paul
  
   Regards,

Re: McBSP in Multi Channel mode

2009-05-08 Thread Peter Ujfalusi

Hello,


On Thursday 07 May 2009 21:18:34 ext Fernando Governatore wrote:
 Hello,

 I'm new to kernel development and so I'm a bit confused on how to do
 things here. I need to use the McBSP with Multi-Channel enabled and
 using DMA to transfer the data.

 The data will be PCM sound and I will have 4 cards attached to this
 McBSP. I'm using OMAP35xx.

 From what I've seen, I have to change the files:
  - arch/arm/plat-omap/mcbsp.c
  - arch/arm/mach-omap2/mcbsp.c
 to support multi channel. Is that it? or I would need more changes?

 Is there something that I would need to change in DMA implementation?
 Do you know where I can get an example or documentation?

Take a look at the sound-2.6 tree's topic/asoc branch:
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=shortlog;h=topic/asoc

The omap3beagle has support for 4 channel audio playback (combination of 
McBSP+TWL4030 codec).
Files that could be interesting for you:
sound/soc/omap/omap3beagle.c
sound/soc/omap/omap-mcbsp.c
sound/soc/codecs/twl4030.c


 Thanks,
 Fernando

-- 
Péter
--
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: Beagleboard rev C memory timings suspend/resume

2009-05-08 Thread Jean Pihet

On Thursday 07 May 2009 21:18:41 Paul Walmsley wrote:
 Hello Jean,

 one other suggestion.  You mentioned that you had self-refresh working on
 another OMAP3430 board with two SDRAM chip-selects.  You might consider
 dumping the SDRC registers from that board, and dumping the SDRC registers
 on Beagle rev C, and comparing.  It could be that the bootloader on your
 other board is setting some important bit.
The comparison gives the following:
- the timings are slightly different but given that the parts are not the same 
I do not think it is a problem
- the fields FIXEDDELAY and MODEFIXEDDELAYINITLAT are set in SDRC_DLLA_CTRL, 
the register value is 0x260A. Does that affect the 166MHz operation?
- the field DEEPPD of SDRC_MCFG_p is set to 0. That setting could affect the 
suspend/resume
- the MUX scheme is different: ADDRMUXLEGACY is set to 0
- the field BANKALLOCATION of SDRC_MCFG_p is set to 0 instead of 2

I tried to change those fields on the Beagleboard but still suspending for 
more than 10sec corrupts the memory.

 - Paul

Regards,
Jean
--
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: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration

2009-05-08 Thread Felipe Contreras

On Fri, May 8, 2009 at 7:14 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
 Hi Felipe,

 From: ext Felipe Contreras felipe.contre...@gmail.com
 Subject: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration
 Date: Thu, 7 May 2009 22:11:06 +0200

 This patch series cleanups up a bit the opap3-iommu device registration and
 then allows registration from other parts of the code.

 I think that this part of code is just a simple conventional
 platform_device registration and there may be no need to add more
 complexicity by introducing a new special structure/function just for
 a workaround of a client module(tidspbridge). Also having these
 device registrations here and there doesn't look so nice, looking at
 other ones around kernel.

First of all, it's not a workaround. Fake dependencies are bad. iommu
should not depend on isp or iva2 (or how they are implemented), it's
the other way around.

Let's say you disable isp, do you want iommu to add the isp iommu
device (same for iva2)? What happens if you don't want either isp or
iva2 in the kernel, what is the point of having iommu?

Second, it's not introducing any new structure, the structure is
internal, you can remove it if you want and implement the same with a
select or any way you want, I just thought an internal structure was
easier to follow.

And third, this kind of device registration is used all over the place, look at:
omap_mmc_add
pxa2xx_set_spi_info
at32_add_device_psif
at32_add_device_twi
at32_add_device_mci
at32_add_device_pwm
at32_add_device_usba
at32_add_device_ide
at32_add_device_cf
at32_add_device_nand
at32_add_device_ac97c
at32_add_device_abdac
txx9_ethaddr_init
txx9_physmap_flash_init
txx9_iocled_init
mv64x60_mpsc_device_setup
mv64x60_eth_device_setup
mv64x60_i2c_device_setup
mv64x60_wdt_device_setup
ipmi_bmc_register
aem_init_aem1_inst
aem_init_aem2_inst
w1_ds2760_add_slave
of_snd_soc_register_device

 Currently the iva2 code (tidspbridge) is not using iommu, therefore it can't 
 be
 used as-is with the current omap iommu. By allowing devies to be registered
 externaly (either isp, or iva2) this problem goes away.

 Fixing tidspbridge itself is the way to go, and it seems that Hari has
 already verified this iommu with tidspbridge and he's pointed out some
 of missing features(*1). I hope that tidspbridge will start to use
 iommu soon.

Yes, definitely, but that's not an excuse not to make iommu more
extensible. With my patch the iommu can be merged as is and would not
*require* any change in tidspbridge. When the tidspbridge is ready, it
would be a matter of adding one line.

Also, it's better to have independent branches. It would be ugly to
modify iommu code from the tidspbridge branch depending on whether or
not the migration to iommu have happened.

And finally, suppose you load the bridgedriver on-demand, with my
patch the iva2 iommu device will be created *only* when the
bridgedriver is loaded, and when the bridgedriver itself is unloaded
it can remove the iva2 iommu device. So essentially we'll have only
the iommu devices that we really need.

Now I ask the question the other way around, what do we loose if we
apply these patches?

-- 
Felipe Contreras
--
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: [PATCH 1/1] ASoC: Added OMAP3 EVM support in ASoC.

2009-05-08 Thread Aggarwal, Anuj

 -Original Message-
 From: Arun KS [mailto:getaru...@gmail.com]
 Sent: Friday, May 08, 2009 10:13 AM
 To: Aggarwal, Anuj
 Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org
 Subject: Re: [PATCH 1/1] ASoC: Added OMAP3 EVM support in ASoC.
 
 On Thu, May 7, 2009 at 9:38 PM, Anuj Aggarwal anuj.aggar...@ti.com
 wrote:
 
  Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
  ---
   sound/soc/omap/Kconfig    |    8 +++
   sound/soc/omap/Makefile   |    2 +
   sound/soc/omap/omap3evm.c |  147
 +
   3 files changed, 157 insertions(+), 0 deletions(-)
   create mode 100644 sound/soc/omap/omap3evm.c
 
  diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
  index 675732e..b771238 100644
  --- a/sound/soc/omap/Kconfig
  +++ b/sound/soc/omap/Kconfig
  @@ -39,6 +39,14 @@ config SND_OMAP_SOC_OMAP2EVM
         help
           Say Y if you want to add support for SoC audio on the omap2evm
 board.
 
  +config SND_OMAP_SOC_OMAP3EVM
  +       tristate SoC Audio support for OMAP3EVM board
  +       depends on TWL4030_CORE  SND_OMAP_SOC 
 MACH_OMAP3EVM
  +       select SND_OMAP_SOC_MCBSP
  +       select SND_SOC_TWL4030
  +       help
  +         Say Y if you want to add support for SoC audio on the omap3evm
 board.
  +
   config SND_OMAP_SOC_SDP3430
         tristate SoC Audio support for Texas Instruments SDP3430
         depends on TWL4030_CORE  SND_OMAP_SOC 
 MACH_OMAP_3430SDP
  diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
  index 0c9e4ac..a37f498 100644
  --- a/sound/soc/omap/Makefile
  +++ b/sound/soc/omap/Makefile
  @@ -10,6 +10,7 @@ snd-soc-n810-objs := n810.o
   snd-soc-osk5912-objs := osk5912.o
   snd-soc-overo-objs := overo.o
   snd-soc-omap2evm-objs := omap2evm.o
  +snd-soc-omap3evm-objs := omap3evm.o
   snd-soc-sdp3430-objs := sdp3430.o
   snd-soc-omap3pandora-objs := omap3pandora.o
   snd-soc-omap3beagle-objs := omap3beagle.o
  @@ -18,6 +19,7 @@ obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-
 n810.o
   obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o
   obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o
   obj-$(CONFIG_MACH_OMAP2EVM) += snd-soc-omap2evm.o
  +obj-$(CONFIG_MACH_OMAP3EVM) += snd-soc-omap3evm.o
   obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o
   obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-
 omap3pandora.o
   obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-
 omap3beagle.o
  diff --git a/sound/soc/omap/omap3evm.c b/sound/soc/omap/omap3evm.c
  new file mode 100644
  index 000..2af5d93
  --- /dev/null
  +++ b/sound/soc/omap/omap3evm.c
  @@ -0,0 +1,147 @@
  +/*
  + * omap3evm.c  -- ALSA SoC support for OMAP3 EVM
  + *
  + * Author: Anuj Aggarwal anuj.aggar...@ti.com
  + *
  + * Based on sound/soc/omap/beagle.c by Steve Sakoman
  + *
  + * Copyright (C) 2008 Texas Instruments, Incorporated
  + *
  + * 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 version 2.
  + *
  + * This program is distributed as is WITHOUT ANY WARRANTY of any
 kind,
  + * whether express or implied; without even the implied warranty of
  + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 GNU
  + * General Public License for more details.
  + */
  +
  +#include linux/clk.h
  +#include linux/platform_device.h
  +#include sound/core.h
  +#include sound/pcm.h
  +#include sound/soc.h
  +#include sound/soc-dapm.h
  +
  +#include asm/mach-types.h
  +#include mach/hardware.h
  +#include mach/gpio.h
  +#include mach/mcbsp.h
  +
  +#include omap-mcbsp.h
  +#include omap-pcm.h
  +#include ../codecs/twl4030.h
  +
  +static int omap3evm_hw_params(struct snd_pcm_substream *substream,
  +       struct snd_pcm_hw_params *params)
  +{
  +       struct snd_soc_pcm_runtime *rtd = substream-private_data;
  +       struct snd_soc_dai *codec_dai = rtd-dai-codec_dai;
  +       struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
  +       int ret;
  +
  +       /* Set codec DAI configuration */
  +       ret = snd_soc_dai_set_fmt(codec_dai,
  +                                 SND_SOC_DAIFMT_I2S |
  +                                 SND_SOC_DAIFMT_NB_NF |
  +                                 SND_SOC_DAIFMT_CBM_CFM);
  +       if (ret  0) {
  +               printk(KERN_ERR Can't set codec DAI configuration\n);
  +               return ret;
  +       }
  +
  +       /* Set cpu DAI configuration */
  +       ret = snd_soc_dai_set_fmt(cpu_dai,
  +                                 SND_SOC_DAIFMT_I2S |
  +                                 SND_SOC_DAIFMT_NB_NF |
  +                                 SND_SOC_DAIFMT_CBM_CFM);
  +       if (ret  0) {
  +               printk(KERN_ERR Can't set cpu DAI configuration\n);
  +               return ret;
  +       }
  +
  +       /* Set the codec system clock for DAC and ADC */
  +       ret = snd_soc_dai_set_sysclk(codec_dai, 0, 2600,
  +

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

2009-05-08 Thread stanley.miao


Gadiyar, Anand wrote:

Stanley.miao wrote:
  

Russell King - ARM Linux wrote:


On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
  
  

Hi, Tony,

Now the kernel can't boot on LDP. The attached file is the boot log.



No boot log found.


  
  

Sorry, forgot to attach the boot log.

It is linux-omap master branch.

Stanley.



Looks like you used the CodeSourcery 2007q3 toolchain. This had been
reported earlier. Switching to 2008q3 works.

- Anand



  

Yeah, Now the kernel booted. it's compiler's problem.

Linux version 2.6.30-rc4-omap1-05873-g2489dcb (stan...@stanley-desktop) 
(gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #2 Fri May 8 17:06:34 
CST 2009

CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP LDP board


Hi, Tony,

LCD still works.
The code I tested is the master branch of linux-omap. Is it right ?

Stanley.

--
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: [alsa-devel] [PATCH 1/1] ASoC: Added OMAP3 EVM support in ASoC.

2009-05-08 Thread Mark Brown

On Thu, May 07, 2009 at 09:38:47PM +0530, Anuj Aggarwal wrote:

 + if (!machine_is_omap3evm()) {
 + pr_debug(Not OMAP3 EVM!\n);
 + return -ENODEV;
 + }

Since you've said you'll be resubmitting perhaps this should be an error
rather than debug message?
--
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

[PATCH 0/3] Support multiple PMICs in Voltage Regulator Framework

2009-05-08 Thread Anuj Aggarwal

Based on the discussion we had at:

http://marc.info/?l=linux-omapm=124083364321017w=2

I am sending the following patches which allows one to move the board-dependent
regulator-specific code to a newly created file drivers\regulator\pmic.c. This
file will have the board specific information for different regulators and
it will do the regulator initialization depending on one which is available.

Anuj Aggarwal (3):
  Regulator: Add pmic.c file to regulator framework
  Regulator: Add TPS65023 Regulator Driver
  Regulator: Added board-dependent code for TPS65023

 drivers/regulator/Kconfig  |8 +
 drivers/regulator/Makefile |3 +-
 drivers/regulator/pmic.c   |  195 
 drivers/regulator/tps65023-regulator.c |  510 
 include/linux/regulator/pmic.h |   29 ++
 5 files changed, 744 insertions(+), 1 deletions(-)
 create mode 100644 drivers/regulator/pmic.c
 create mode 100644 drivers/regulator/tps65023-regulator.c
 create mode 100644 include/linux/regulator/pmic.h

--
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

[PATCH 1/3] Regulator: Add pmic.c file to regulator framework

2009-05-08 Thread Anuj Aggarwal

Added drivers\regulator\pmic.c file to the regulator framework which will
have the board specific information for different regulators and will do the
regulator initialization depending on one which is available.

Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
 drivers/regulator/Makefile |2 +-
 drivers/regulator/pmic.c   |  103 
 include/linux/regulator/pmic.h |   29 +++
 3 files changed, 133 insertions(+), 1 deletions(-)
 create mode 100644 drivers/regulator/pmic.c
 create mode 100644 include/linux/regulator/pmic.h

diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index bac133a..c0d87bf 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -3,7 +3,7 @@
 #


-obj-$(CONFIG_REGULATOR) += core.o
+obj-$(CONFIG_REGULATOR) += core.o pmic.o
 obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
 obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o

diff --git a/drivers/regulator/pmic.c b/drivers/regulator/pmic.c
new file mode 100644
index 000..36ed341
--- /dev/null
+++ b/drivers/regulator/pmic.c
@@ -0,0 +1,103 @@
+/*
+ * pmic.c
+ *
+ * Supports run-time detection of different Power Management ICs.
+ *
+ * Copyright (C) 2009 Texas Instrument Incorporated - http://www.ti.com/
+ *
+ * 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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include mach/common.h
+
+/*
+ * Definitions specific to TWL4030
+ */
+
+/*
+ * Definitions specific to TPS62350
+ */
+
+/*
+ * Definitions specific to TPS65023
+ */
+
+static int flag_pmic_twl4030;
+static int flag_pmic_tps6235x;
+static int flag_pmic_tps65023;
+
+/*
+ * Detect the current PMIC, set one of the flags
+ */
+static inline int detect_pmic(void)
+{
+   /* How? Any suggestions?? This is a temporary solution. */
+#if defined(CONFIG_TWL4030_CORE)
+   flag_pmic_twl4030 = 1;
+#endif
+
+#if defined(CONFIG_OMAP3EVM_TPS6235X)
+   flag_pmic_tps6235x = 1;
+#endif
+
+#if defined(CONFIG_OMAP3EVM_TPS65023)
+   flag_pmic_tps65023 = 1;
+#endif
+
+   return 0;
+}
+
+/* Functions to detect which PMIC is present */
+
+int pmic_is_twl4030(void)
+{
+   return flag_pmic_twl4030;
+}
+
+int pmic_is_tps6235x(void)
+{
+   return flag_pmic_tps6235x;
+}
+
+int pmic_is_tps65020(void) { return 0; }
+
+int pmic_is_tps65021(void) { return 0; }
+
+int pmic_is_tps65022(void) { return 0; }
+
+int pmic_is_tps65023(void)
+{
+   return flag_pmic_tps65023;
+}
+
+int pmic_is_tps65950(void)
+{
+   return flag_pmic_twl4030;
+}
+
+/* Detects the PMIC and initializes it accordingly */
+int pmic_init(void)
+{
+#if defined(CONFIG_TWL4030_CORE)
+   /* do stuff specific to TWL4030 */
+#endif
+
+#if defined(CONFIG_OMAP3EVM_TPS6235X)
+   /* do stuff specific to TPS62350 */
+#endif
+
+#if defined(CONFIG_OMAP3EVM_TPS65023)
+   /* do stuff specific to TPS65023 */
+#endif
+
+   return 0;
+}
+
diff --git a/include/linux/regulator/pmic.h b/include/linux/regulator/pmic.h
new file mode 100644
index 000..5956740
--- /dev/null
+++ b/include/linux/regulator/pmic.h
@@ -0,0 +1,29 @@
+/*
+ * pmic.h
+ *
+ * Supports run-time detection of different Power Management ICs.
+ *
+ * Copyright (C) 2009 Texas Instrument Incorporated  http://www.ti.com/
+ *
+ * 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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind, whether
+ * express or implied; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+/* Functions to detect which PMIC is present */
+int pmic_is_twl4030(void);
+int pmic_is_tps6235x(void);
+int pmic_is_tps65020(void);
+int pmic_is_tps65021(void);
+int pmic_is_tps65022(void);
+int pmic_is_tps65023(void);
+int pmic_is_tps65950(void);
+
+/* Detects the PMIC and initializes it accordingly */
+int pmic_init(void);
+
--
1.6.2.4

--
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

[PATCH 2/3] Regulator: Add TPS65023 Regulator Driver

2009-05-08 Thread Anuj Aggarwal

Added regulator driver for TPS65023 and modified the Kconfig and Makefile for
the same.

Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
 drivers/regulator/Kconfig  |8 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/tps65023-regulator.c |  510 
 3 files changed, 519 insertions(+), 0 deletions(-)
 create mode 100644 drivers/regulator/tps65023-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index e58c0ce..28109e1 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -91,4 +91,12 @@ config REGULATOR_PCF50633
 Say Y here to support the voltage regulators and convertors
 on PCF50633

+config REGULATOR_TPS65023
+   tristate TI TPS65023 Power regulators
+   depends on OMAP3EVM_TPS65023
+   help
+ This driver supports TPS65023 voltage regulator chips. TPS65023 
provides
+ three step-down converters and two general-purpose LDO voltage 
regulators.
+ It supports TI's software based Class-2 SmartReflex implementation.
+
 endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index c0d87bf..28235b9 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -13,5 +13,6 @@ obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
 obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
 obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
 obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65023) += tps65023-regulator.o

 ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
diff --git a/drivers/regulator/tps65023-regulator.c 
b/drivers/regulator/tps65023-regulator.c
new file mode 100644
index 000..657c0c3
--- /dev/null
+++ b/drivers/regulator/tps65023-regulator.c
@@ -0,0 +1,510 @@
+/*
+ * tps65023-regulator.c -- Supports TPS65023 regulator
+ *
+ * Author : Anuj Aggarwalanuj.aggar...@ti.com
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/i2c.h
+#include linux/delay.h
+
+/* Register definitions */
+#defineTPS65023_REG_VERSION0
+#defineTPS65023_REG_PGOODZ 1
+#defineTPS65023_REG_MASK   2
+#defineTPS65023_REG_REG_CTRL   3
+#defineTPS65023_REG_CON_CTRL   4
+#defineTPS65023_REG_CON_CTRL2  5
+#defineTPS65023_REG_DEF_CORE   6
+#defineTPS65023_REG_DEFSLEW7
+#defineTPS65023_REG_LDO_CTRL   8
+
+/* PGOODZ bitfields */
+#defineTPS65023_PGOODZ_PWRFAILZBIT(7)
+#defineTPS65023_PGOODZ_LOWBATTZBIT(6)
+#defineTPS65023_PGOODZ_VDCDC1  BIT(5)
+#defineTPS65023_PGOODZ_VDCDC2  BIT(4)
+#defineTPS65023_PGOODZ_VDCDC3  BIT(3)
+#defineTPS65023_PGOODZ_LDO2BIT(2)
+#defineTPS65023_PGOODZ_LDO1BIT(1)
+
+/* MASK bitfields */
+#defineTPS65023_MASK_PWRFAILZ  BIT(7)
+#defineTPS65023_MASK_LOWBATTZ  BIT(6)
+#defineTPS65023_MASK_VDCDC1BIT(5)
+#defineTPS65023_MASK_VDCDC2BIT(4)
+#defineTPS65023_MASK_VDCDC3BIT(3)
+#defineTPS65023_MASK_LDO2  BIT(2)
+#defineTPS65023_MASK_LDO1  BIT(1)
+
+/* REG_CTRL bitfields */
+#define TPS65023_REG_CTRL_VDCDC1_ENBIT(5)
+#define TPS65023_REG_CTRL_VDCDC2_ENBIT(4)
+#define TPS65023_REG_CTRL_VDCDC3_ENBIT(3)
+#define TPS65023_REG_CTRL_LDO2_EN  BIT(2)
+#define TPS65023_REG_CTRL_LDO1_EN  BIT(1)
+
+/* LDO_CTRL bitfields */
+#define TPS65023_LDO_CTRL_LDOx_SHIFT   4
+#define TPS65023_LDO_CTRL_LDOx_MASK(ldo_id)(0xF0  (ldo_id*4))
+
+/* Number of step-down converters available */
+#define TPS65023_NUM_DCDC  3
+/* Number of LDO voltage regulators  available */
+#define TPS65023_NUM_LDO   2
+/* Number of total regulators available */
+#define TPS65023_NUM_REGULATOR (TPS65023_NUM_DCDC + TPS65023_NUM_LDO)
+
+struct tps_info {
+   const char  *name;
+   unsignedmin_uV;
+   unsignedmax_uV;
+   boolfixed;
+   u8  table_len;
+   const u16   *table;
+};
+
+struct tps {
+   struct regulator_desc   desc[TPS65023_NUM_REGULATOR];
+   struct i2c_client   *client;
+   struct regulator_dev*rdev[TPS65023_NUM_REGULATOR];
+   const struct tps_info   *info[TPS65023_NUM_REGULATOR];
+};
+
+static inline int

Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

2009-05-08 Thread Tony Lindgren

* Shilimkar, Santosh santosh.shilim...@ti.com [090507 22:10]:
  -Original Message-
  From: Tony Lindgren [mailto:t...@atomide.com] 
  Sent: Friday, May 08, 2009 2:17 AM
  To: Shilimkar, Santosh
  Cc: linux-arm-ker...@lists.arm.linux.org.uk; 
  linux-omap@vger.kernel.org
  Subject: Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files
  
  * Santosh Shilimkar santosh.shilim...@ti.com [090507 00:29]:
   This patch adds SMP platform files support for OMAP4430SDP. 
  TI's OMAP4430
   SOC is based on ARM Cortex-A9 SMP architecture. It's a dual core SOC
   with GIC used for interrupt handling and SCU for cache coherency.
   
   Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
   ---
arch/arm/mach-omap2/omap-headsmp.S|   49 +++
arch/arm/mach-omap2/omap-smp.c|  238 
  +
arch/arm/plat-omap/include/mach/scu.h |   28 
arch/arm/plat-omap/include/mach/smp.h |   56 
4 files changed, 371 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap-headsmp.S
create mode 100644 arch/arm/mach-omap2/omap-smp.c
create mode 100644 arch/arm/plat-omap/include/mach/scu.h
create mode 100644 arch/arm/plat-omap/include/mach/smp.h
  
  snip snip
   
   --- /dev/null
   +++ b/arch/arm/mach-omap2/omap-smp.c
   @@ -0,0 +1,238 @@
   +/*
   + * OMAP4 SMP source file. It contains platform specific fucntions
   + * needed for the linux smp kernel.
   + *
   + * Copyright (C) 2009 Texas Instruments, Inc.
   + *
   + * Author:
   + *  Santosh Shilimkar santosh.shilim...@ti.com
   + *
   + * Platform file needed for the OMAP4 SMP. This file is 
  based on arm
   + * realview smp platform.
   + * * Copyright (c) 2002 ARM Limited.
   + *
   + * 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 linux/init.h
   +#include linux/errno.h
   +#include linux/delay.h
   +#include linux/device.h
   +#include linux/jiffies.h
   +#include linux/smp.h
   +#include linux/io.h
   +
   +#include asm/cacheflush.h
   +#include mach/scu.h
   +#include mach/hardware.h
   +#include asm/mach-types.h
   +
   +/* Registers used for communicating startup information */
   +#define OMAP4_AUXCOREBOOT_REG0   
  (OMAP44XX_VA_WKUPGEN_BASE + 0x800)
   +#define OMAP4_AUXCOREBOOT_REG1   
  (OMAP44XX_VA_WKUPGEN_BASE + 0x804)
   +
   +/* FIXME: Move to a common header file */
   +extern void omap_secondary_startup(void);
  
  How about move this to cpu.h?
  
 Possible. The thing is this functions should be available only for OMAP4 SMP. 
 We may need #ifdef ARCH_OMAP4. Is that ok ? 

Please rathar have a ifdef section in cpu.h for CONFIG_SMP.

Regards,

Tony
--
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: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

2009-05-08 Thread Tony Lindgren

* stanley.miao stanley.m...@windriver.com [090508 02:15]:
 Gadiyar, Anand wrote:
 Stanley.miao wrote:
   
 Russell King - ARM Linux wrote:
 
 On Thu, May 07, 2009 at 11:01:35PM +0800, stanley.miao wrote:
 
 Hi, Tony,

 Now the kernel can't boot on LDP. The attached file is the boot log.
 
 No boot log found.


 
 Sorry, forgot to attach the boot log.

 It is linux-omap master branch.

 Stanley.
 

 Looks like you used the CodeSourcery 2007q3 toolchain. This had been
 reported earlier. Switching to 2008q3 works.

 - Anand



   
 Yeah, Now the kernel booted. it's compiler's problem.

 Linux version 2.6.30-rc4-omap1-05873-g2489dcb (stan...@stanley-desktop)  
 (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #2 Fri May 8 17:06:34  
 CST 2009
 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
 CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
 Machine: OMAP LDP board


 Hi, Tony,

 LCD still works.
 The code I tested is the master branch of linux-omap. Is it right ?

Well the goal here is to get the mainline code to work for the LCD.

I'll post few patches for you to test after trying them out on 3430sdp.

Regards,

Tony
--
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: [PATCH 0/5] More header clean-up

2009-05-08 Thread Tony Lindgren

* Shilimkar, Santosh santosh.shilim...@ti.com [090507 22:20]:
 If this series is planned for this window then OMAP4 series also needs few 
 changes. Is it ?

Yeah. For omap4 those changes should be trivial though.

Maybe do a test rebase on top of these patches to see which ones
you need to rename?

But when posting patches to mailings lists, please keep them against
the mainline. I should be able to deal with the conflicts pretty easily
when adding them to for-next.

Regards,

Tony

 
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org 
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
  Sent: Friday, May 08, 2009 2:12 AM
  To: linux-omap@vger.kernel.org
  Subject: [PATCH 0/5] More header clean-up
  
  Hi all,
  
  This series cleans up the conflicting defines a bit more.
  Now the biggest problem is till in clock24xx.h, but at least the
  conflict is local. Now changing the processors should not cause
  everything to be rebuilt..
  
  The first patch also fixes the CONFIG_SPINLOCK_DEBUG problem where
  sched_clock was called before we have things initialized.
  
  This series causes some updates to the other pending patch series,
  like the PM series. But it would be nice to get in before we add
  more code.
  
  Kevin, the 2/5 is improved version of what I sent you earlier,
  the earlier version had issues between 2420 vs 2430. Let me
  know if the other patches cause big headaches for your PM
  series.
  
  Regards,
  
  Tony
  
  ---
  
  Tony Lindgren (5):
ARM: OMAP2/3: Remove OMAP_CM_REGADDR
ARM: OMAP2/3: Remove OMAP2_PRCM_BASE
ARM: OMAP2/3: Move define of OMAP2_VA_IC_BASE to be 
  local to entry-macro.S
ARM: OMAP2/3: Remove OMAP_PRM_REGADDR and OMAP2_PRM_BASE
ARM: OMAP2/3: Remove OMAP2_32KSYNCT_BASE
  
  
   arch/arm/mach-omap2/clock24xx.c   |   21 ++--
   arch/arm/mach-omap2/clock24xx.h   |   11 ++
   arch/arm/mach-omap2/clock34xx.h   |2 
   arch/arm/mach-omap2/cm.h  |5 -
   arch/arm/mach-omap2/prm.h |  136 
  +
   arch/arm/mach-omap2/sdrc2xxx.c|5 +
   arch/arm/mach-omap2/sram242x.S|4 -
   arch/arm/mach-omap2/sram243x.S|4 -
   arch/arm/plat-omap/common.c   |   69 +++--
   arch/arm/plat-omap/include/mach/entry-macro.S |9 +-
   arch/arm/plat-omap/include/mach/omap24xx.h|   18 ---
   arch/arm/plat-omap/include/mach/omap34xx.h|9 --
   12 files changed, 170 insertions(+), 123 deletions(-)
  
  -- 
  Signature
  --
  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
  
  
--
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: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

2009-05-08 Thread Shilimkar, Santosh


 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
 Sent: Friday, May 08, 2009 8:48 PM
 To: Shilimkar, Santosh
 Cc: linux-arm-ker...@lists.arm.linux.org.uk; 
 linux-omap@vger.kernel.org
 Subject: Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files
 
 * Shilimkar, Santosh santosh.shilim...@ti.com [090507 22:10]:
   -Original Message-
   From: Tony Lindgren [mailto:t...@atomide.com] 
   Sent: Friday, May 08, 2009 2:17 AM
   To: Shilimkar, Santosh
   Cc: linux-arm-ker...@lists.arm.linux.org.uk; 
   linux-omap@vger.kernel.org
   Subject: Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files
   
   * Santosh Shilimkar santosh.shilim...@ti.com [090507 00:29]:
This patch adds SMP platform files support for OMAP4430SDP. 
   TI's OMAP4430
SOC is based on ARM Cortex-A9 SMP architecture. It's a 
 dual core SOC
with GIC used for interrupt handling and SCU for cache 
 coherency.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/omap-headsmp.S|   49 +++
 arch/arm/mach-omap2/omap-smp.c|  238 
   +
 arch/arm/plat-omap/include/mach/scu.h |   28 
 arch/arm/plat-omap/include/mach/smp.h |   56 
 4 files changed, 371 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/omap-headsmp.S
 create mode 100644 arch/arm/mach-omap2/omap-smp.c
 create mode 100644 arch/arm/plat-omap/include/mach/scu.h
 create mode 100644 arch/arm/plat-omap/include/mach/smp.h
   
   snip snip

--- /dev/null
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -0,0 +1,238 @@
+/*
+ * OMAP4 SMP source file. It contains platform 
 specific fucntions
+ * needed for the linux smp kernel.
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Author:
+ *  Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Platform file needed for the OMAP4 SMP. This file is 
   based on arm
+ * realview smp platform.
+ * * Copyright (c) 2002 ARM Limited.
+ *
+ * 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 linux/init.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/jiffies.h
+#include linux/smp.h
+#include linux/io.h
+
+#include asm/cacheflush.h
+#include mach/scu.h
+#include mach/hardware.h
+#include asm/mach-types.h
+
+/* Registers used for communicating startup information */
+#define OMAP4_AUXCOREBOOT_REG0 
   (OMAP44XX_VA_WKUPGEN_BASE + 0x800)
+#define OMAP4_AUXCOREBOOT_REG1 
   (OMAP44XX_VA_WKUPGEN_BASE + 0x804)
+
+/* FIXME: Move to a common header file */
+extern void omap_secondary_startup(void);
   
   How about move this to cpu.h?
   
  Possible. The thing is this functions should be available 
 only for OMAP4 SMP. We may need #ifdef ARCH_OMAP4. Is that ok ? 
 
 Please rathar have a ifdef section in cpu.h for CONFIG_SMP.

Perfect !!

Regards
Santosh
--
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: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

2009-05-08 Thread Kalle Valo

stanley.miao stanley.m...@windriver.com writes:

 Looks like you used the CodeSourcery 2007q3 toolchain. This had been
 reported earlier. Switching to 2008q3 works.

 Yeah, Now the kernel booted. it's compiler's problem.

I was bitten by the same problem few weeks ago. Any chance of getting a
warning/error if using 2007q3 compiler until the problem is fixed?

-- 
Kalle Valo
--
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: [PATCH 0/5] More header clean-up

2009-05-08 Thread Shilimkar, Santosh

 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com] 
 Sent: Friday, May 08, 2009 8:51 PM
 To: Shilimkar, Santosh
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [PATCH 0/5] More header clean-up

 * Shilimkar, Santosh santosh.shilim...@ti.com [090507 22:20]:
  If this series is planned for this window then OMAP4 series 
 also needs few changes. Is it ?

 Yeah. For omap4 those changes should be trivial though.

 Maybe do a test rebase on top of these patches to see which ones
 you need to rename?

 But when posting patches to mailings lists, please keep them against
 the mainline. I should be able to deal with the conflicts 
 pretty easily
 when adding them to for-next.

Sure.. I will keep you posted with delta changes.

Regards,
Santosh--
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: [PATCH 3/6] omap iommu: omap3 iommu device registration

2009-05-08 Thread Aguirre Rodriguez, Sergio Alberto

Hi,

Just one comment below:

  Does the following make sense?
 
  +#define NR_IOMMU_RES 2
 
  
 
  +               err = platform_device_add_resources(pdev,
  +                                   omap3_iommu_res +  i * NR_IOMMU_RES,
 NR_IOMMU_RES);
 
 Yeap, also:
 
  +   err = platform_device_add_resources(pdev,
 omap3_iommu_res +  i * 2, 2);

IMHO, I don't think it's a good idea to add magical numbers to any code in the 
kernel. Why is it better to NOT use a define?

Regards,
Sergio
--
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: [PATCH 0/3] Support multiple PMICs in Voltage Regulator Framework

2009-05-08 Thread Mark Brown

On Fri, May 08, 2009 at 08:41:13PM +0530, Anuj Aggarwal wrote:
 Based on the discussion we had at:
 
 http://marc.info/?l=linux-omapm=124083364321017w=2
 
 I am sending the following patches which allows one to move the 
 board-dependent
 regulator-specific code to a newly created file drivers\regulator\pmic.c. This
 file will have the board specific information for different regulators and
 it will do the regulator initialization depending on one which is available.

You really need to submit changes like this to the relevant subsystem
maintainers and mailing lists rather than linux-omap - changes to kernel
subsystems will affect all users of the kernel, not just OMAP.

In this case your proposal should have been sent to myself, Liam
Girdwood (CCed) and linux-kernel.
--
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: [PATCH 1/3] Regulator: Add pmic.c file to regulator framework

2009-05-08 Thread Mark Brown

On Fri, May 08, 2009 at 08:42:06PM +0530, Anuj Aggarwal wrote:

 Added drivers\regulator\pmic.c file to the regulator framework which will

I suspect you mean / there :)

 have the board specific information for different regulators and will do the
 regulator initialization depending on one which is available.

 Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com

I'm really not sure what the abstraction that you're attempting to
introduce here is intended to do that can't handled by the existing
kernel features - could you go into more detail about the problem that
this patch is intended to solve, please?

The kernel already provides facilities for detecting the presence of
devices.  In cases where it is possible to do a generic check for a
device (for example, by reading back ID registers on the device and
checking the values) then the device driver can do so in its probe
routine and the board can unconditionally declare that the device is
there, allowing the probe to fail.  In cases where something board
specific needs to be done (such as checking for fit resistors or
information provided by the bootloader) then that'd need to be handled
in the board code anyway - it's not going to apply on generic systems.
There will also be cases where it's just not possible to determine
what's fitted at runtime, especially for simple devices with GPIO only
control.

If there is initialisation which can always be done for a chip no matter
what board it's on then I'd expect the driver to just handle that when
it is starting up without needing separate code - if there's something
preventing that then we should definitely fix that, probably in a way
that's not specific to the regulator framework since I'd expect other
subsystems to be running into similar issues.

Another thing here is that the code appears to assume that there will be
only one regulator device in the system which isn't always true.  Some
designs will use a series of discrete regulators rather than integrated
chips while others will use several integrated PMICs for reasons such as
ease of layout or power distribution.

Based on experience with the OMAP audio drivers I suspect the problem
the patch is trying to solve may be that there are a lot of designs out
there which are based on the reference platforms which TI have produced
and are therefore have very repetitive board code.  Perhaps this might
be best handled by having some utility routines in the OMAP code which
the machine drivers can use to say that they have the same PMIC setup as
a given reference design?

CCing in Liam so I've not deleted any of the text.

 ---
  drivers/regulator/Makefile |2 +-
  drivers/regulator/pmic.c   |  103 
 
  include/linux/regulator/pmic.h |   29 +++
  3 files changed, 133 insertions(+), 1 deletions(-)
  create mode 100644 drivers/regulator/pmic.c
  create mode 100644 include/linux/regulator/pmic.h
 
 diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
 index bac133a..c0d87bf 100644
 --- a/drivers/regulator/Makefile
 +++ b/drivers/regulator/Makefile
 @@ -3,7 +3,7 @@
  #
 
 
 -obj-$(CONFIG_REGULATOR) += core.o
 +obj-$(CONFIG_REGULATOR) += core.o pmic.o
  obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
  obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
 
 diff --git a/drivers/regulator/pmic.c b/drivers/regulator/pmic.c
 new file mode 100644
 index 000..36ed341
 --- /dev/null
 +++ b/drivers/regulator/pmic.c
 @@ -0,0 +1,103 @@
 +/*
 + * pmic.c
 + *
 + * Supports run-time detection of different Power Management ICs.
 + *
 + * Copyright (C) 2009 Texas Instrument Incorporated - http://www.ti.com/
 + *
 + * 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 version 2.
 + *
 + * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
 + * whether express or implied; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 + * General Public License for more details.
 + */
 +#include linux/regulator/driver.h
 +#include linux/regulator/machine.h
 +#include mach/common.h
 +
 +/*
 + * Definitions specific to TWL4030
 + */
 +
 +/*
 + * Definitions specific to TPS62350
 + */
 +
 +/*
 + * Definitions specific to TPS65023
 + */
 +
 +static int flag_pmic_twl4030;
 +static int flag_pmic_tps6235x;
 +static int flag_pmic_tps65023;
 +
 +/*
 + * Detect the current PMIC, set one of the flags
 + */
 +static inline int detect_pmic(void)
 +{
 + /* How? Any suggestions?? This is a temporary solution. */
 +#if defined(CONFIG_TWL4030_CORE)
 + flag_pmic_twl4030 = 1;
 +#endif
 +
 +#if defined(CONFIG_OMAP3EVM_TPS6235X)
 + flag_pmic_tps6235x = 1;
 +#endif
 +
 +#if defined(CONFIG_OMAP3EVM_TPS65023)
 + flag_pmic_tps65023 = 1;
 +#endif
 +
 + return 0;
 +}
 +
 +/* Functions to detect which PMIC is present */
 +

[PATCH 0/3] Getting omap3 frambuffer to work in mainline

2009-05-08 Thread Tony Lindgren

Hi all,

Here are few patches to make omap3 framebuffer to work in the
mainline kernel. I've just updated the clocks handling and
added two missing LCD files. Still waiting for Imre to send
all the other fixes..

Stanley, can you give it a try on your LDP?

Anybody want to try to produce a similar patch for Beagle
for this series?

Regards,

Tony

---

Stanley Miao (1):
  OMAP_LDP: Support LCD display as a FB device on ZOOM MDK

Tony Lindgren (2):
  ARM: OMAP3: Add more devices for omap3430sdp
  ARM: OMAP2/3: Change omapfb to use clkdev for dispc and rfbi


 arch/arm/configs/omap_3430sdp_defconfig |   10 ++
 arch/arm/configs/omap_ldp_defconfig |   63 +-
 arch/arm/mach-omap2/board-2430sdp.c |6 +
 arch/arm/mach-omap2/board-ldp.c |   11 ++
 arch/arm/mach-omap2/clock24xx.c |8 +
 arch/arm/mach-omap2/clock34xx.c |   10 +-
 drivers/video/omap/Kconfig  |4 +
 drivers/video/omap/Makefile |5 +
 drivers/video/omap/dispc.c  |   11 +-
 drivers/video/omap/lcd_2430sdp.c|  199 +++
 drivers/video/omap/lcd_ldp.c|  200 +++
 drivers/video/omap/rfbi.c   |4 -
 12 files changed, 512 insertions(+), 19 deletions(-)
 create mode 100644 drivers/video/omap/lcd_2430sdp.c
 create mode 100644 drivers/video/omap/lcd_ldp.c

-- 
Signature
--
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

[PATCH 1/3] ARM: OMAP2/3: Change omapfb to use clkdev for dispc and rfbi

2009-05-08 Thread Tony Lindgren

This also makes the framebuffer work on omap3.

Cc: Imre Deak imre.d...@nokia.com
Cc: linux-fbdev-de...@lists.sourceforge.net
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/clock24xx.c |8 
 arch/arm/mach-omap2/clock34xx.c |   10 +-
 drivers/video/omap/dispc.c  |   11 +--
 drivers/video/omap/rfbi.c   |4 ++--
 4 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 54b8671..3159511 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -103,10 +103,10 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL,   mdm_ick,  mdm_ick,   CK_243X),
CLK(NULL,   mdm_osc_ck,   mdm_osc_ck,CK_243X),
/* DSS domain clocks */
-   CLK(NULL,   dss_ick,  dss_ick,   CK_243X | CK_242X),
-   CLK(NULL,   dss1_fck, dss1_fck,  CK_243X | CK_242X),
-   CLK(NULL,   dss2_fck, dss2_fck,  CK_243X | CK_242X),
-   CLK(NULL,   dss_54m_fck,  dss_54m_fck,   CK_243X | CK_242X),
+   CLK(omapfb,   ick,  dss_ick,   CK_243X | CK_242X),
+   CLK(omapfb,   dss1_fck, dss1_fck,  CK_243X | CK_242X),
+   CLK(omapfb,   dss2_fck, dss2_fck,  CK_243X | CK_242X),
+   CLK(omapfb,   tv_fck,   dss_54m_fck,   CK_243X | CK_242X),
/* L3 domain clocks */
CLK(NULL,   core_l3_ck,   core_l3_ck,CK_243X | CK_242X),
CLK(NULL,   ssi_fck,  ssi_ssr_sst_fck, CK_243X | CK_242X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 0a14dca..9068c4d 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -197,11 +197,11 @@ static struct omap_clk omap34xx_clks[] = {
CLK(omap_rng, ick,  rng_ick,   CK_343X),
CLK(NULL,   sha11_ick,sha11_ick, CK_343X),
CLK(NULL,   des1_ick, des1_ick,  CK_343X),
-   CLK(NULL,   dss1_alwon_fck, dss1_alwon_fck, CK_343X),
-   CLK(NULL,   dss_tv_fck,   dss_tv_fck,CK_343X),
-   CLK(NULL,   dss_96m_fck,  dss_96m_fck,   CK_343X),
-   CLK(NULL,   dss2_alwon_fck, dss2_alwon_fck, CK_343X),
-   CLK(NULL,   dss_ick,  dss_ick,   CK_343X),
+   CLK(omapfb,   dss1_fck, dss1_alwon_fck, CK_343X),
+   CLK(omapfb,   tv_fck,   dss_tv_fck,CK_343X),
+   CLK(omapfb,   video_fck,dss_96m_fck,   CK_343X),
+   CLK(omapfb,   dss2_fck, dss2_alwon_fck, CK_343X),
+   CLK(omapfb,   ick,  dss_ick,   CK_343X),
CLK(NULL,   cam_mclk, cam_mclk,  CK_343X),
CLK(NULL,   cam_ick,  cam_ick,   CK_343X),
CLK(NULL,   csi2_96m_fck, csi2_96m_fck,  CK_343X),
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index dfb72f5..bfeecf2 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -880,8 +880,8 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void 
*dev)
 
 static int get_dss_clocks(void)
 {
-   if (IS_ERR((dispc.dss_ick = clk_get(dispc.fbdev-dev, dss_ick {
-   dev_err(dispc.fbdev-dev, can't get dss_ick\n);
+   if (IS_ERR((dispc.dss_ick = clk_get(dispc.fbdev-dev, ick {
+   dev_err(dispc.fbdev-dev, can't get ick\n);
return PTR_ERR(dispc.dss_ick);
}
 
@@ -891,12 +891,11 @@ static int get_dss_clocks(void)
return PTR_ERR(dispc.dss1_fck);
}
 
-   if (IS_ERR((dispc.dss_54m_fck =
-   clk_get(dispc.fbdev-dev, dss_54m_fck {
-   dev_err(dispc.fbdev-dev, can't get dss_54m_fck\n);
+   if (IS_ERR(dispc.dss_54m_fck = clk_get(dispc.fbdev-dev, tv_fck))) {
+   dev_err(dispc.fbdev-dev, can't get tv_fck\n);
clk_put(dispc.dss_ick);
clk_put(dispc.dss1_fck);
-   return PTR_ERR(dispc.dss_54m_fck);
+
}
 
return 0;
diff --git a/drivers/video/omap/rfbi.c b/drivers/video/omap/rfbi.c
index a13c8dc..ee199f5 100644
--- a/drivers/video/omap/rfbi.c
+++ b/drivers/video/omap/rfbi.c
@@ -83,8 +83,8 @@ static inline u32 rfbi_read_reg(int idx)
 
 static int rfbi_get_clocks(void)
 {
-   if (IS_ERR((rfbi.dss_ick = clk_get(rfbi.fbdev-dev, dss_ick {
-   dev_err(rfbi.fbdev-dev, can't get dss_ick\n);
+   if (IS_ERR((rfbi.dss_ick = clk_get(rfbi.fbdev-dev, ick {
+   dev_err(rfbi.fbdev-dev, can't get ick\n);
return PTR_ERR(rfbi.dss_ick);
}
 

--
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

[PATCH 2/3] ARM: OMAP3: Add more devices for omap3430sdp

2009-05-08 Thread Tony Lindgren

Add more devices for omap3430sdp

Cc: Imre Deak imre.d...@nokia.com
Cc: linux-fbdev-de...@lists.sourceforge.net
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/configs/omap_3430sdp_defconfig |   10 ++
 arch/arm/mach-omap2/board-2430sdp.c |6 +
 drivers/video/omap/Kconfig  |4 +
 drivers/video/omap/Makefile |4 +
 drivers/video/omap/lcd_2430sdp.c|  199 +++
 5 files changed, 223 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap/lcd_2430sdp.c

diff --git a/arch/arm/configs/omap_3430sdp_defconfig 
b/arch/arm/configs/omap_3430sdp_defconfig
index 8fb918d..2be930c 100644
--- a/arch/arm/configs/omap_3430sdp_defconfig
+++ b/arch/arm/configs/omap_3430sdp_defconfig
@@ -1331,6 +1331,16 @@ CONFIG_DISPLAY_SUPPORT=y
 #
 # CONFIG_VGA_CONSOLE is not set
 CONFIG_DUMMY_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
+# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
+# CONFIG_FONTS is not set
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
+CONFIG_LOGO=y
+CONFIG_LOGO_LINUX_MONO=y
+CONFIG_LOGO_LINUX_VGA16=y
+CONFIG_LOGO_LINUX_CLUT224=y
 CONFIG_SOUND=y
 CONFIG_SOUND_OSS_CORE=y
 CONFIG_SND=y
diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 2214365..017bebf 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -112,6 +112,11 @@ static struct resource sdp2430_smc91x_resources[] = {
},
 };
 
+static struct platform_device sdp2430_lcd_device = {
+   .name   = sdp2430_lcd,
+   .id = -1,
+};
+
 static struct platform_device sdp2430_smc91x_device = {
.name   = smc91x,
.id = -1,
@@ -122,6 +127,7 @@ static struct platform_device sdp2430_smc91x_device = {
 static struct platform_device *sdp2430_devices[] __initdata = {
sdp2430_smc91x_device,
sdp2430_flash_device,
+   sdp2430_lcd_device,
 };
 
 static inline void __init sdp2430_init_smc91x(void)
diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index 4440885..7ca848c 100644
--- a/drivers/video/omap/Kconfig
+++ b/drivers/video/omap/Kconfig
@@ -7,6 +7,10 @@ config FB_OMAP
help
   Frame buffer driver for OMAP based boards.
 
+config FB_OMAP_LCD_VGA
+bool Use LCD in VGA mode
+ depends on MACH_OMAP_3430SDP
+
 config FB_OMAP_BOOTLOADER_INIT
bool Check bootloader initialization
depends on FB_OMAP
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index ed13889..e6d52f3 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -8,6 +8,7 @@ objs-yy := omapfb_main.o
 
 objs-y$(CONFIG_ARCH_OMAP1) += lcdc.o
 objs-y$(CONFIG_ARCH_OMAP2) += dispc.o
+objs-y$(CONFIG_ARCH_OMAP3) += dispc.o
 
 objs-$(CONFIG_ARCH_OMAP1)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
 objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += rfbi.o
@@ -24,5 +25,8 @@ objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += 
lcd_inn1610.o
 objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
 objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
 
+objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
+objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
+
 omapfb-objs := $(objs-yy)
 
diff --git a/drivers/video/omap/lcd_2430sdp.c b/drivers/video/omap/lcd_2430sdp.c
new file mode 100644
index 000..a22b452
--- /dev/null
+++ b/drivers/video/omap/lcd_2430sdp.c
@@ -0,0 +1,199 @@
+/*
+ * LCD panel support for the TI 2430SDP board
+ *
+ * Copyright (C) 2007 MontaVista
+ * Author: Hunyue Yau h...@mvista.com
+ *
+ * Derived from drivers/video/omap/lcd-apollon.c
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/i2c/twl4030.h
+
+#include mach/mux.h
+#include mach/omapfb.h
+#include asm/mach-types.h
+
+#define SDP2430_LCD_PANEL_BACKLIGHT_GPIO   91
+#define SDP2430_LCD_PANEL_ENABLE_GPIO  154
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO   24
+#define SDP3430_LCD_PANEL_ENABLE_GPIO  28
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+
+#define LCD_PIXCLOCK_MAX   5400 /*

[PATCH 3/3] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK

2009-05-08 Thread Tony Lindgren

From: Stanley Miao stanley.m...@windriver.com

Add glue to control the OMAP_LDP LCD as a frame buffer device
using the existing dispc.c driver under omapfb.

Patch updated for mainline kernel. Note that the
drivers/video/omap should be updated to pass omap_lcd_config
in platform_data. The patch should also be updated to compile
if twl4030 is not selected, and eventually to use the regulator
framework.

Cc: Imre Deak imre.d...@nokia.com
Cc: linux-fbdev-de...@lists.sourceforge.net
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/configs/omap_ldp_defconfig |   63 +++
 arch/arm/mach-omap2/board-ldp.c |   11 ++
 drivers/video/omap/Kconfig  |2 
 drivers/video/omap/Makefile |1 
 drivers/video/omap/lcd_ldp.c|  200 +++
 5 files changed, 274 insertions(+), 3 deletions(-)
 create mode 100644 drivers/video/omap/lcd_ldp.c

diff --git a/arch/arm/configs/omap_ldp_defconfig 
b/arch/arm/configs/omap_ldp_defconfig
index 679a4a3..8a979cd 100644
--- a/arch/arm/configs/omap_ldp_defconfig
+++ b/arch/arm/configs/omap_ldp_defconfig
@@ -685,11 +685,16 @@ CONFIG_GPIOLIB=y
 # CONFIG_GPIO_SYSFS is not set
 
 #
+# Memory mapped GPIO expanders:
+#
+
+#
 # I2C GPIO expanders:
 #
 # CONFIG_GPIO_MAX732X is not set
 # CONFIG_GPIO_PCA953X is not set
 # CONFIG_GPIO_PCF857X is not set
+CONFIG_GPIO_TWL4030=y
 
 #
 # PCI GPIO expanders:
@@ -740,12 +745,19 @@ CONFIG_SSB_POSSIBLE=y
 #
 # CONFIG_MFD_CORE is not set
 # CONFIG_MFD_SM501 is not set
+# CONFIG_MFD_ASIC3 is not set
 # CONFIG_HTC_EGPIO is not set
 # CONFIG_HTC_PASIC3 is not set
+# CONFIG_TPS65010 is not set
+CONFIG_TWL4030_CORE=y
 # CONFIG_MFD_TMIO is not set
 # CONFIG_MFD_T7L66XB is not set
 # CONFIG_MFD_TC6387XB is not set
 # CONFIG_MFD_TC6393XB is not set
+# CONFIG_PMIC_DA903X is not set
+# CONFIG_MFD_WM8400 is not set
+# CONFIG_MFD_WM8350_I2C is not set
+# CONFIG_MFD_PCF50633 is not set
 
 #
 # Multimedia devices
@@ -767,8 +779,45 @@ CONFIG_DAB=y
 #
 # CONFIG_VGASTATE is not set
 CONFIG_VIDEO_OUTPUT_CONTROL=m
-# CONFIG_FB is not set
-# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+CONFIG_FB=y
+CONFIG_FIRMWARE_EDID=y
+# CONFIG_FB_DDC is not set
+# CONFIG_FB_BOOT_VESA_SUPPORT is not set
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+# CONFIG_FB_SYS_FILLRECT is not set
+# CONFIG_FB_SYS_COPYAREA is not set
+# CONFIG_FB_SYS_IMAGEBLIT is not set
+# CONFIG_FB_FOREIGN_ENDIAN is not set
+# CONFIG_FB_SYS_FOPS is not set
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+CONFIG_FB_MODE_HELPERS=y
+CONFIG_FB_TILEBLITTING=y
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_S1D13XXX is not set
+# CONFIG_FB_VIRTUAL is not set
+# CONFIG_FB_METRONOME is not set
+CONFIG_FB_OMAP=y
+CONFIG_FB_OMAP_LCD_VGA=y
+# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set
+# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
+CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=4
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_CLASS_DEVICE=y
+# CONFIG_LCD_LTV350QV is not set
+# CONFIG_LCD_ILI9320 is not set
+# CONFIG_LCD_TDO24M is not set
+# CONFIG_LCD_VGG2432A4 is not set
+CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+# CONFIG_BACKLIGHT_CORGI is not set
 
 #
 # Display device support
@@ -780,6 +829,16 @@ CONFIG_VIDEO_OUTPUT_CONTROL=m
 #
 # CONFIG_VGA_CONSOLE is not set
 CONFIG_DUMMY_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
+# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
+# CONFIG_FONTS is not set
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
+CONFIG_LOGO=y
+CONFIG_LOGO_LINUX_MONO=y
+CONFIG_LOGO_LINUX_VGA16=y
+CONFIG_LOGO_LINUX_CLUT224=y
 CONFIG_SOUND=y
 CONFIG_SND=y
 # CONFIG_SND_SEQUENCER is not set
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index da57b0f..abbbdfc 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -77,8 +77,14 @@ static struct platform_device ldp_smsc911x_device = {
},
 };
 
+static struct platform_device ldp_lcd_device = {
+   .name   = ldp_lcd,
+   .id = -1,
+};
+
 static struct platform_device *ldp_devices[] __initdata = {
ldp_smsc911x_device,
+   ldp_lcd_device,
 };
 
 static inline void __init ldp_init_smsc911x(void)
@@ -122,8 +128,13 @@ static struct omap_uart_config ldp_uart_config __initdata 
= {
.enabled_uarts  = ((1  0) | (1  1) | (1  2)),
 };
 
+static struct omap_lcd_config ldp_lcd_config __initdata = {
+   .ctrl_name  = internal,
+};
+
 static struct omap_board_config_kernel ldp_config[] __initdata = {
{ OMAP_TAG_UART,ldp_uart_config },
+   { OMAP_TAG_LCD, ldp_lcd_config },
 };
 
 static struct twl4030_gpio_platform_data ldp_gpio_data = {
diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
index 7ca848c..6c86ec0 100644
---

Re: [PATCH 0/3] Getting omap3 frambuffer to work in mainline

2009-05-08 Thread Tony Lindgren

* Tony Lindgren t...@atomide.com [090508 12:21]:
 Hi all,
 
 Here are few patches to make omap3 framebuffer to work in the
 mainline kernel. I've just updated the clocks handling and
 added two missing LCD files. Still waiting for Imre to send
 all the other fixes..
 
 Stanley, can you give it a try on your LDP?
 
 Anybody want to try to produce a similar patch for Beagle
 for this series?

Forgot to mention that I quickly tested this on SDP, and
the penguin shows up ok.
 
 Regards,
 
 Tony
 
 ---
 
 Stanley Miao (1):
   OMAP_LDP: Support LCD display as a FB device on ZOOM MDK
 
 Tony Lindgren (2):
   ARM: OMAP3: Add more devices for omap3430sdp
   ARM: OMAP2/3: Change omapfb to use clkdev for dispc and rfbi
 
 
  arch/arm/configs/omap_3430sdp_defconfig |   10 ++
  arch/arm/configs/omap_ldp_defconfig |   63 +-
  arch/arm/mach-omap2/board-2430sdp.c |6 +
  arch/arm/mach-omap2/board-ldp.c |   11 ++
  arch/arm/mach-omap2/clock24xx.c |8 +
  arch/arm/mach-omap2/clock34xx.c |   10 +-
  drivers/video/omap/Kconfig  |4 +
  drivers/video/omap/Makefile |5 +
  drivers/video/omap/dispc.c  |   11 +-
  drivers/video/omap/lcd_2430sdp.c|  199 
 +++
  drivers/video/omap/lcd_ldp.c|  200 
 +++
  drivers/video/omap/rfbi.c   |4 -
  12 files changed, 512 insertions(+), 19 deletions(-)
  create mode 100644 drivers/video/omap/lcd_2430sdp.c
  create mode 100644 drivers/video/omap/lcd_ldp.c
 
 -- 
 Signature
 --
 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
--
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: [PATCH 2/3] Regulator: Add TPS65023 Regulator Driver

2009-05-08 Thread Mark Brown

On Fri, May 08, 2009 at 08:42:12PM +0530, Anuj Aggarwal wrote:
 Added regulator driver for TPS65023 and modified the Kconfig and Makefile for
 the same.
 
 Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com

This looks pretty good.  I've spotted a few issues, mostly to do with
error handling or nitpicky stuff that it's nice to have but which
shouldn't be a blocker to merge.  It would be good to get the initcall
ordering addressed, though.

CCing in Liam and not deleting any text as a result.

 ---
  drivers/regulator/Kconfig  |8 +
  drivers/regulator/Makefile |1 +
  drivers/regulator/tps65023-regulator.c |  510 
 
  3 files changed, 519 insertions(+), 0 deletions(-)
  create mode 100644 drivers/regulator/tps65023-regulator.c
 
 diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
 index e58c0ce..28109e1 100644
 --- a/drivers/regulator/Kconfig
 +++ b/drivers/regulator/Kconfig
 @@ -91,4 +91,12 @@ config REGULATOR_PCF50633
Say Y here to support the voltage regulators and convertors
on PCF50633
 
 +config REGULATOR_TPS65023
 + tristate TI TPS65023 Power regulators
 + depends on OMAP3EVM_TPS65023
 + help
 +   This driver supports TPS65023 voltage regulator chips. TPS65023 
 provides
 +   three step-down converters and two general-purpose LDO voltage 
 regulators.
 +   It supports TI's software based Class-2 SmartReflex implementation.
 +
  endif
 diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
 index c0d87bf..28235b9 100644
 --- a/drivers/regulator/Makefile
 +++ b/drivers/regulator/Makefile
 @@ -13,5 +13,6 @@ obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
  obj-$(CONFIG_REGULATOR_DA903X)   += da903x.o
  obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
 +obj-$(CONFIG_REGULATOR_TPS65023) += tps65023-regulator.o
 
  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
 diff --git a/drivers/regulator/tps65023-regulator.c 
 b/drivers/regulator/tps65023-regulator.c
 new file mode 100644
 index 000..657c0c3
 --- /dev/null
 +++ b/drivers/regulator/tps65023-regulator.c
 @@ -0,0 +1,510 @@
 +/*
 + * tps65023-regulator.c -- Supports TPS65023 regulator
 + *
 + * Author : Anuj Aggarwalanuj.aggar...@ti.com
 + *
 + * 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.
 + */
 +
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/init.h
 +#include linux/err.h
 +#include linux/platform_device.h
 +#include linux/regulator/driver.h
 +#include linux/regulator/machine.h
 +#include linux/i2c.h
 +#include linux/delay.h
 +
 +/* Register definitions */
 +#define  TPS65023_REG_VERSION0
 +#define  TPS65023_REG_PGOODZ 1
 +#define  TPS65023_REG_MASK   2
 +#define  TPS65023_REG_REG_CTRL   3
 +#define  TPS65023_REG_CON_CTRL   4
 +#define  TPS65023_REG_CON_CTRL2  5
 +#define  TPS65023_REG_DEF_CORE   6
 +#define  TPS65023_REG_DEFSLEW7
 +#define  TPS65023_REG_LDO_CTRL   8
 +
 +/* PGOODZ bitfields */
 +#define  TPS65023_PGOODZ_PWRFAILZBIT(7)
 +#define  TPS65023_PGOODZ_LOWBATTZBIT(6)
 +#define  TPS65023_PGOODZ_VDCDC1  BIT(5)
 +#define  TPS65023_PGOODZ_VDCDC2  BIT(4)
 +#define  TPS65023_PGOODZ_VDCDC3  BIT(3)
 +#define  TPS65023_PGOODZ_LDO2BIT(2)
 +#define  TPS65023_PGOODZ_LDO1BIT(1)
 +
 +/* MASK bitfields */
 +#define  TPS65023_MASK_PWRFAILZ  BIT(7)
 +#define  TPS65023_MASK_LOWBATTZ  BIT(6)
 +#define  TPS65023_MASK_VDCDC1BIT(5)
 +#define  TPS65023_MASK_VDCDC2BIT(4)
 +#define  TPS65023_MASK_VDCDC3BIT(3)
 +#define  TPS65023_MASK_LDO2  BIT(2)
 +#define  TPS65023_MASK_LDO1  BIT(1)
 +
 +/* REG_CTRL bitfields */
 +#define TPS65023_REG_CTRL_VDCDC1_EN  BIT(5)
 +#define TPS65023_REG_CTRL_VDCDC2_EN  BIT(4)
 +#define TPS65023_REG_CTRL_VDCDC3_EN  BIT(3)
 +#define TPS65023_REG_CTRL_LDO2_ENBIT(2)
 +#define TPS65023_REG_CTRL_LDO1_ENBIT(1)
 +
 +/* LDO_CTRL bitfields */
 +#define TPS65023_LDO_CTRL_LDOx_SHIFT 4
 +#define TPS65023_LDO_CTRL_LDOx_MASK(ldo_id)  (0xF0  (ldo_id*4))
 +
 +/* Number of step-down converters available */
 +#define TPS65023_NUM_DCDC3
 +/* Number of LDO voltage regulators  available */
 +#define TPS65023_NUM_LDO 2
 +/* Number of total regulators available */
 +#define TPS65023_NUM_REGULATOR   (TPS65023_NUM_DCDC + TPS65023_NUM_LDO)
 +
 +struct tps_info {
 + const char  *name;
 + unsignedmin_uV;
 + unsignedmax_uV;
 +

Re: [PATCH 2/3] ARM: OMAP3: Add more devices for omap3430sdp

2009-05-08 Thread Tony Lindgren

* Tony Lindgren t...@atomide.com [090508 12:21]:
 Add more devices for omap3430sdp

This patch should be credited for Hunyue Yau h...@mvista.com.

Tony
 
 Cc: Imre Deak imre.d...@nokia.com
 Cc: linux-fbdev-de...@lists.sourceforge.net
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/configs/omap_3430sdp_defconfig |   10 ++
  arch/arm/mach-omap2/board-2430sdp.c |6 +
  drivers/video/omap/Kconfig  |4 +
  drivers/video/omap/Makefile |4 +
  drivers/video/omap/lcd_2430sdp.c|  199 
 +++
  5 files changed, 223 insertions(+), 0 deletions(-)
  create mode 100644 drivers/video/omap/lcd_2430sdp.c
 
 diff --git a/arch/arm/configs/omap_3430sdp_defconfig 
 b/arch/arm/configs/omap_3430sdp_defconfig
 index 8fb918d..2be930c 100644
 --- a/arch/arm/configs/omap_3430sdp_defconfig
 +++ b/arch/arm/configs/omap_3430sdp_defconfig
 @@ -1331,6 +1331,16 @@ CONFIG_DISPLAY_SUPPORT=y
  #
  # CONFIG_VGA_CONSOLE is not set
  CONFIG_DUMMY_CONSOLE=y
 +CONFIG_FRAMEBUFFER_CONSOLE=y
 +# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
 +# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
 +# CONFIG_FONTS is not set
 +CONFIG_FONT_8x8=y
 +CONFIG_FONT_8x16=y
 +CONFIG_LOGO=y
 +CONFIG_LOGO_LINUX_MONO=y
 +CONFIG_LOGO_LINUX_VGA16=y
 +CONFIG_LOGO_LINUX_CLUT224=y
  CONFIG_SOUND=y
  CONFIG_SOUND_OSS_CORE=y
  CONFIG_SND=y
 diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
 b/arch/arm/mach-omap2/board-2430sdp.c
 index 2214365..017bebf 100644
 --- a/arch/arm/mach-omap2/board-2430sdp.c
 +++ b/arch/arm/mach-omap2/board-2430sdp.c
 @@ -112,6 +112,11 @@ static struct resource sdp2430_smc91x_resources[] = {
   },
  };
  
 +static struct platform_device sdp2430_lcd_device = {
 + .name   = sdp2430_lcd,
 + .id = -1,
 +};
 +
  static struct platform_device sdp2430_smc91x_device = {
   .name   = smc91x,
   .id = -1,
 @@ -122,6 +127,7 @@ static struct platform_device sdp2430_smc91x_device = {
  static struct platform_device *sdp2430_devices[] __initdata = {
   sdp2430_smc91x_device,
   sdp2430_flash_device,
 + sdp2430_lcd_device,
  };
  
  static inline void __init sdp2430_init_smc91x(void)
 diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig
 index 4440885..7ca848c 100644
 --- a/drivers/video/omap/Kconfig
 +++ b/drivers/video/omap/Kconfig
 @@ -7,6 +7,10 @@ config FB_OMAP
   help
Frame buffer driver for OMAP based boards.
  
 +config FB_OMAP_LCD_VGA
 +bool Use LCD in VGA mode
 +   depends on MACH_OMAP_3430SDP
 +
  config FB_OMAP_BOOTLOADER_INIT
   bool Check bootloader initialization
   depends on FB_OMAP
 diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
 index ed13889..e6d52f3 100644
 --- a/drivers/video/omap/Makefile
 +++ b/drivers/video/omap/Makefile
 @@ -8,6 +8,7 @@ objs-yy := omapfb_main.o
  
  objs-y$(CONFIG_ARCH_OMAP1) += lcdc.o
  objs-y$(CONFIG_ARCH_OMAP2) += dispc.o
 +objs-y$(CONFIG_ARCH_OMAP3) += dispc.o
  
  objs-$(CONFIG_ARCH_OMAP1)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
  objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += rfbi.o
 @@ -24,5 +25,8 @@ objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) 
 += lcd_inn1610.o
  objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o
  objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o
  
 +objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
 +objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
 +
  omapfb-objs := $(objs-yy)
  
 diff --git a/drivers/video/omap/lcd_2430sdp.c 
 b/drivers/video/omap/lcd_2430sdp.c
 new file mode 100644
 index 000..a22b452
 --- /dev/null
 +++ b/drivers/video/omap/lcd_2430sdp.c
 @@ -0,0 +1,199 @@
 +/*
 + * LCD panel support for the TI 2430SDP board
 + *
 + * Copyright (C) 2007 MontaVista
 + * Author: Hunyue Yau h...@mvista.com
 + *
 + * Derived from drivers/video/omap/lcd-apollon.c
 + *
 + * 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.
 + *
 + * This program is distributed in the hope that it will be useful, but
 + * WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 + * General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License along
 + * with this program; if not, write to the Free Software Foundation, Inc.,
 + * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
 + */
 +
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/delay.h
 +#include linux/gpio.h
 +#include linux/i2c/twl4030.h
 +
 +#include mach/mux.h
 +#include mach/omapfb.h
 +#include asm/mach-types.h
 +
 +#define SDP2430_LCD_PANEL_BACKLIGHT_GPIO 91
 +#define

Re: [PATCH 3/3] Regulator: Added board-dependent code for TPS65023

2009-05-08 Thread Mark Brown

On Fri, May 08, 2009 at 08:42:16PM +0530, Anuj Aggarwal wrote:
 Added OMAP3 EVM specific code for TPS65023 in pmic.c file.
 
 Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com

CCing in Liam again.

 ---
  drivers/regulator/pmic.c |   92 
 ++
  1 files changed, 92 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/regulator/pmic.c b/drivers/regulator/pmic.c
 index 36ed341..6e7276a 100644
 --- a/drivers/regulator/pmic.c
 +++ b/drivers/regulator/pmic.c
 @@ -29,6 +29,96 @@
  /*
   * Definitions specific to TPS65023
   */
 +#if defined(CONFIG_OMAP3EVM_TPS65023)
 +/* MPU voltage regulator of DCDC type */
 +struct regulator_consumer_supply tps65023_mpu_consumers = {
 + .supply = vdd1,
 +};

This comes back to my questions about pmic.c but I'd expect this all to
appear in the OMAP3 EVM code.

 +
 +/* CORE voltage regulator of DCDC type */
 +struct regulator_consumer_supply tps65023_core_consumers = {
 + .supply = vdd2,
 +};
 +
 +/* SRAM/MEM/WKUP_BG voltage regulator of DCDC type */
 +struct regulator_consumer_supply tps65023_vdds_consumers = {
 + .supply = vdds,
 +};
 +
 +/* DPLL voltage regulator of LDO type */
 +struct regulator_consumer_supply tps65023_dpll_consumers = {
 + .supply = dpll,
 +};
 +
 +/* MMC voltage regulator of LDO type */
 +struct regulator_consumer_supply tps65023_mmc_consumers = {
 + .supply = mmc,
 +};
 +
 +struct regulator_init_data tps65023_regulator_data[] = {
 + {
 + .constraints = {
 + .min_uV = 80,
 + .max_uV = 160,
 + .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
 + REGULATOR_CHANGE_STATUS),
 + .boot_on = 1,
 + },
 + .num_consumer_supplies  = 1,
 + .consumer_supplies  = tps65023_mpu_consumers,
 + },
 + {
 + .constraints = {
 + .min_uV = 180,
 + .max_uV = 330,
 + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
 + .boot_on = 1,
 + },
 + .num_consumer_supplies  = 1,
 + .consumer_supplies  = tps65023_core_consumers,
 + },
 + {
 + .constraints = {
 + .min_uV = 180,
 + .max_uV = 330,
 + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
 + .boot_on = 1,
 + },
 + .num_consumer_supplies  = 1,
 + .consumer_supplies  = tps65023_vdds_consumers,
 + },
 + {
 + .constraints = {
 + .min_uV = 100,
 + .max_uV = 315,
 + .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
 + REGULATOR_CHANGE_STATUS),
 + .boot_on = 1,
 + },
 + .num_consumer_supplies  = 1,
 + .consumer_supplies  = tps65023_dpll_consumers,
 + },
 + {
 + .constraints = {
 + .min_uV = 105,
 + .max_uV = 330,
 + .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
 + REGULATOR_CHANGE_STATUS),
 + .boot_on = 1,
 + },
 + .num_consumer_supplies  = 1,
 + .consumer_supplies  = tps65023_mmc_consumers,
 + },
 +};
 +
 +static struct i2c_board_info __initdata board_tps65023_instances[] = {
 + {
 + I2C_BOARD_INFO(tps65023, 0x48),
 + .flags = I2C_CLIENT_WAKE,
 + .platform_data = tps65023_regulator_data[0],
 + },
 +};
 +#endif
 
  static int flag_pmic_twl4030;
  static int flag_pmic_tps6235x;
 @@ -96,6 +186,8 @@ int pmic_init(void)
 
  #if defined(CONFIG_OMAP3EVM_TPS65023)
   /* do stuff specific to TPS65023 */
 + omap_register_i2c_bus(1, 400, board_tps65023_instances,
 + ARRAY_SIZE(board_tps65023_instances));
  #endif
 
   return 0;
 --
 1.6.2.4
 
 --
 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
 

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.
--
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: [PATCH 3/6] omap iommu: omap3 iommu device registration

2009-05-08 Thread Felipe Contreras

On Fri, May 8, 2009 at 8:21 PM, Aguirre Rodriguez, Sergio Alberto
saagui...@ti.com wrote:
 Hi,

 Just one comment below:

  Does the following make sense?
 
  +#define NR_IOMMU_RES 2
 
  
 
  +               err = platform_device_add_resources(pdev,
  +                                   omap3_iommu_res +  i * NR_IOMMU_RES,
 NR_IOMMU_RES);

 Yeap, also:

  +               err = platform_device_add_resources(pdev,
 omap3_iommu_res +  i * 2, 2);

 IMHO, I don't think it's a good idea to add magical numbers to any code in 
 the kernel. Why is it better to NOT use a define?

I agree, but even a define is not good enough. For example you can
update the array without updating the define.

A better solution is to do what I did on my follow up patch series:

+   struct resource res[] = {
+   { .flags = IORESOURCE_MEM },
+   { .flags = IORESOURCE_IRQ },
+   };

+   err = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));

No need for a define, and as soon as the array is updated so will the
second argument sent to platform_device_add_resources.

-- 
Felipe Contreras
--
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: Beagleboard rev C memory timings suspend/resume

2009-05-08 Thread Paul Walmsley

Hello Jean,

On Fri, 8 May 2009, Jean Pihet wrote:

 On Thursday 07 May 2009 20:59:43 Paul Walmsley wrote:
  On Thu, 7 May 2009, Jean Pihet wrote:
   From the OMAP datasheet it looks like the ARCV setting is off: shouldn't
   it be (tREFI/tCK)+50=(7800/6)+50=0x546?
 
  Could you elaborate further what you're seeing?  It would help to
  see the register value that you're using to come to this conclusion.
 The SDRC_RFR_CTRL_p registers are now programmed with 0x4dc01, which means 
 the 
 fiel ARCV has the value 0x4dc=1244.
 From the DDR datasheet we need an average refresh period of 7.8us and a clock 
 period of 6ns (166MHz). From the definition of the ARCV field in the OMAP TRM 
 I need to program ARCV with: (tREFI/tCK)+50 = (7800/6)+50=1350=0x546.
 The SDRC_RFR_CTRL_p registers would then have the value of 0x54601.
 
 Does that make sense? Am I wrong with the calculation?

According to the TRM, the 50 cycles should be subtracted rather than added 
(section 11.2.6.3.3.4).  One other thing is that the bootloaders I've seen 
program DPLL3 such that the SDRC clock is 16600 Hz, rather than 
1 Hz, so tCK winds up being something like 6.024... ns.

Auto-refresh is only used while the SDRC is active, though.  So unless 
memory corruption is evident outside of suspend, the ARCV value is 
unlikely to be the problem.  

It sounds like the problem is related to self-refresh, that the SDRAM bank 
on one of the chipselects either can't enter or exit self-refresh.  You 
have self-refresh working on a different board with both SDRC CS0 and CS1 
in use, correct?  Is that with an ES2 or ES3 chip?

One possibility: perhaps the problem is with Beagle's pin mux settings.  
You might want to boot with mem=128M and make sure 
CONTROL_PADCONF_SAD2D_SBUSFLAG and CONTROL_PADCONF_SDRC_CKE1 are in mode 0 
before suspend and after resume.

Another thought: it could be that the ROM code on Beagle is not 
programming the correct SDRC register values after resume.  You might try 
booting with mem=128M and dumping the SDRC register values before suspend 
and after resume.


- Paul

--
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: Beagleboard rev C memory timings suspend/resume

2009-05-08 Thread Paul Walmsley

On Fri, 8 May 2009, Jean Pihet wrote:

 On Thursday 07 May 2009 21:18:41 Paul Walmsley wrote:
  Hello Jean,
 
  one other suggestion.  You mentioned that you had self-refresh working on
  another OMAP3430 board with two SDRAM chip-selects.  You might consider
  dumping the SDRC registers from that board, and dumping the SDRC registers
  on Beagle rev C, and comparing.  It could be that the bootloader on your
  other board is setting some important bit.
 The comparison gives the following:
 - the timings are slightly different but given that the parts are not the 
 same 
 I do not think it is a problem
 - the fields FIXEDDELAY and MODEFIXEDDELAYINITLAT are set in SDRC_DLLA_CTRL, 
 the register value is 0x260A. Does that affect the 166MHz operation?

It shouldn't.

 - the field DEEPPD of SDRC_MCFG_p is set to 0. That setting could affect the 
 suspend/resume

I don't think this should matter, since we never power off the SDRAM.

 - the MUX scheme is different: ADDRMUXLEGACY is set to 0
 - the field BANKALLOCATION of SDRC_MCFG_p is set to 0 instead of 2

- Paul
--
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: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

RE: Status of Beagle Board

Re: Status of Beagle Board

RE: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

Re: Beagleboard rev C memory timings suspend/resume

Re: McBSP in Multi Channel mode

Re: Beagleboard rev C memory timings suspend/resume

Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration

RE: [PATCH 1/1] ASoC: Added OMAP3 EVM support in ASoC.

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

Re: [alsa-devel] [PATCH 1/1] ASoC: Added OMAP3 EVM support in ASoC.

[PATCH 0/3] Support multiple PMICs in Voltage Regulator Framework

[PATCH 1/3] Regulator: Add pmic.c file to regulator framework

[PATCH 2/3] Regulator: Add TPS65023 Regulator Driver

Re: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

Re: [PATCH 0/5] More header clean-up

RE: [PATCH 1/3] OMAP4: SMP: Add OMAP4430 SMP board files

Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)

RE: [PATCH 0/5] More header clean-up

RE: [PATCH 3/6] omap iommu: omap3 iommu device registration

Re: [PATCH 0/3] Support multiple PMICs in Voltage Regulator Framework

Re: [PATCH 1/3] Regulator: Add pmic.c file to regulator framework

[PATCH 0/3] Getting omap3 frambuffer to work in mainline

[PATCH 1/3] ARM: OMAP2/3: Change omapfb to use clkdev for dispc and rfbi

[PATCH 2/3] ARM: OMAP3: Add more devices for omap3430sdp

[PATCH 3/3] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK

Re: [PATCH 0/3] Getting omap3 frambuffer to work in mainline

Re: [PATCH 2/3] Regulator: Add TPS65023 Regulator Driver

Re: [PATCH 2/3] ARM: OMAP3: Add more devices for omap3430sdp

Re: [PATCH 3/3] Regulator: Added board-dependent code for TPS65023

Re: [PATCH 3/6] omap iommu: omap3 iommu device registration

Re: Beagleboard rev C memory timings suspend/resume

Re: Beagleboard rev C memory timings suspend/resume

34 matches

Site Navigation

Mail list logo

Footer information