* [PATCH v12 0/3] add the GPMI controller driver for IMX23/IMX28
From: Huang Shijie @ 2011-09-15 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20081.44941.12535.496764@ipc1.ka-ro>
Hi,
add more CC.
> Hi,
>
> Huang Shijie writes:
>> The patch set is based on Artem's tree:
>> http://git.infradead.org/users/dedekind/l2-mtd-2.6.git
>>
>> The general-purpose media interface(GPMI) controller is a flexible interface
>> to up to several NAND flashs.
>>
>> The Bose Ray-Choudhury Hocquenghem(BCH) module is a hardware ECC accelerator.
>>
>> With the help of BCH, the GPMI controller can choose to do the hardware ECC or
>> not.
>>
>> This driver is a _pure_ MTD NAND controller driver now.
>>
>>
>> The driver depends on another GPMI-NAND device patch set, you can find them at :
>> [1] http://marc.info/?l=linux-arm-kernel&m=131416901319573&w=2
>> [2] http://marc.info/?l=linux-arm-kernel&m=131416912319668&w=2
>> [3] http://marc.info/?l=linux-arm-kernel&m=131416891119504&w=2
>> [4] http://marc.info/?l=linux-arm-kernel&m=131416896219539&w=2
>>
>> Test environment:
>> Using imx23 and imx28 boards for test.
>>
>> imx23 :
>> console=ttyAMA0,115200 mtdparts=gpmi-nfc:20m(boot),-(user)
>> Tested by USB boot and NAND boot.
>>
>> imx28 :
>> #console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait
>> Tested by SD card boot mode.
>>
> How did you perform your tests?
>
> I tried this driver on our TX28 board with the result that with
The nand conflicats with SD card1. You will get the DMA timeout if you
use it.
Do you use sd card0 or sd card1?
BTW:I tested the gpmi driver with SD card0. It works fine.
Best Regards
Huang Shijie
> concurrent access of the SD card and the NAND flash, I still get the
> dreaded DMA timeouts within seconds:
> DMA timeout, last DMA :1
> GPMI regs:
> HW_GPMI_CTRL0[000]=21800001
> HW_GPMI_COMPARE[010]=00000000
> HW_GPMI_ECCCTRL[020]=00000000
> HW_GPMI_ECCCOUNT[030]=00000840
> HW_GPMI_PAYLOAD[040]=46578000
> HW_GPMI_AUXILIARY[050]=46578800
> HW_GPMI_CTRL1[060]=0004000c
> HW_GPMI_TIMING0[070]=00010203
> HW_GPMI_TIMING1[080]=05000000
> HW_GPMI_TIMING2[090]=09020101
> HW_GPMI_STAT[0b0]=0d000003
> HW_GPMI_DEBUG[0c0]=01000000
> BCH regs:
> HW_BCH_CTRL[000]=00000100
> HW_BCH_STATUS0[010]=00000010
> HW_BCH_MODE[020]=00000000
> HW_BCH_ENCODEPTR[030]=00000000
> HW_BCH_DATAPTR[040]=00000000
> HW_BCH_METAPTR[050]=00000000
> HW_BCH_LAYOUTSELECT[070]=00000000
> HW_BCH_FLASH0LAYOUT0[080]=030a4200
> HW_BCH_FLASH0LAYOUT1[090]=08404200
> HW_BCH_DEBUG0[100]=00000000
> DMA regs:
> HW_APBHX_CTRL0[000]=30000000
> HW_APBHX_CTRL1[010]=ffff0000
> HW_APBHX_CTRL2[020]=00000000
> HW_APBHX_CHANNEL_CTRL[030]=00000000
> HW_APBHX_CHn_CURCMDAR(0)[100]=46e1c000
> HW_APBHX_CHn_NXTCMDAR(0)[110]=46e1c04c
> HW_APBHX_CHn_CMD(0)[120]=000001c8
> HW_APBHX_CHn_BAR(0)[130]=00000000
> HW_APBHX_CHn_SEMA(0)[140]=00000000
> HW_APBHX_CHn_DEBUG1(0)[150]=00a0001e
> HW_APBHX_CHn_DEBUG2(0)[160]=00000000
> HW_APBHX_CHn_CURCMDAR(4)[2c0]=4652c098
> HW_APBHX_CHn_NXTCMDAR(4)[2d0]=4652c0e4
> HW_APBHX_CHn_CMD(4)[2e0]=000001c9
> HW_APBHX_CHn_BAR(4)[2f0]=46553241
> HW_APBHX_CHn_SEMA(4)[300]=00010000
> HW_APBHX_CHn_DEBUG1(4)[310]=27a00015
> HW_APBHX_CHn_DEBUG2(4)[320]=00000000
> BCH Geometry :
> GF length : 13
> ECC Strength : 8
> Page Size in Bytes : 2112
> Metadata Size in Bytes : 10
> ECC Chunk Size in Bytes: 512
> ECC Chunk Count : 4
> Payload Size in Bytes : 2048
> Auxiliary Size in Bytes: 16
> Auxiliary Status Offset: 12
> Block Mark Byte Offset : 1999
> Block Mark Bit Offset : 0
>
> I'm doing a:
> dd if=/dev/mtd0> /dev/null& dd if=/dev/mmcblk0> /dev/null
> Sometimes the 'dd' accessing the SD card will stall indefinitely.
> Also copying data from SD card to flash will produce the error, though
> less likely.
>
> This looks like the problem arises in the DMA driver when multiple
> channels are being used concurrently. The GPMI driver will bail out
> with the timeout error while the MMC driver obviously has no timeout
> check for this situation.
>
> I can mostly rule out HW problems, because the same board works
> perfectly well with WindowsCE (tested with a copy operation between
> flash and SD card).
>
>
> Lothar Wa?mann
^ permalink raw reply
* [PATCH v12 0/3] add the GPMI controller driver for IMX23/IMX28
From: Huang Shijie @ 2011-09-15 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20081.44941.12535.496764@ipc1.ka-ro>
Hi,
> Hi,
>
> Huang Shijie writes:
>> The patch set is based on Artem's tree:
>> http://git.infradead.org/users/dedekind/l2-mtd-2.6.git
>>
>> The general-purpose media interface(GPMI) controller is a flexible interface
>> to up to several NAND flashs.
>>
>> The Bose Ray-Choudhury Hocquenghem(BCH) module is a hardware ECC accelerator.
>>
>> With the help of BCH, the GPMI controller can choose to do the hardware ECC or
>> not.
>>
>> This driver is a _pure_ MTD NAND controller driver now.
>>
>>
>> The driver depends on another GPMI-NAND device patch set, you can find them at :
>> [1] http://marc.info/?l=linux-arm-kernel&m=131416901319573&w=2
>> [2] http://marc.info/?l=linux-arm-kernel&m=131416912319668&w=2
>> [3] http://marc.info/?l=linux-arm-kernel&m=131416891119504&w=2
>> [4] http://marc.info/?l=linux-arm-kernel&m=131416896219539&w=2
>>
>> Test environment:
>> Using imx23 and imx28 boards for test.
>>
>> imx23 :
>> console=ttyAMA0,115200 mtdparts=gpmi-nfc:20m(boot),-(user)
>> Tested by USB boot and NAND boot.
>>
>> imx28 :
>> #console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait
>> Tested by SD card boot mode.
>>
> How did you perform your tests?
>
> I tried this driver on our TX28 board with the result that with
> concurrent access of the SD card and the NAND flash, I still get the
The nand conflicats with SD card1. You will get the DMA timeout if you
use it.
Do you use sd card0 or sd card1?
BTW:I tested the gpmi driver with SD card0.
Best Regards
Huang Shijie
> dreaded DMA timeouts within seconds:
> DMA timeout, last DMA :1
> GPMI regs:
> HW_GPMI_CTRL0[000]=21800001
> HW_GPMI_COMPARE[010]=00000000
> HW_GPMI_ECCCTRL[020]=00000000
> HW_GPMI_ECCCOUNT[030]=00000840
> HW_GPMI_PAYLOAD[040]=46578000
> HW_GPMI_AUXILIARY[050]=46578800
> HW_GPMI_CTRL1[060]=0004000c
> HW_GPMI_TIMING0[070]=00010203
> HW_GPMI_TIMING1[080]=05000000
> HW_GPMI_TIMING2[090]=09020101
> HW_GPMI_STAT[0b0]=0d000003
> HW_GPMI_DEBUG[0c0]=01000000
> BCH regs:
> HW_BCH_CTRL[000]=00000100
> HW_BCH_STATUS0[010]=00000010
> HW_BCH_MODE[020]=00000000
> HW_BCH_ENCODEPTR[030]=00000000
> HW_BCH_DATAPTR[040]=00000000
> HW_BCH_METAPTR[050]=00000000
> HW_BCH_LAYOUTSELECT[070]=00000000
> HW_BCH_FLASH0LAYOUT0[080]=030a4200
> HW_BCH_FLASH0LAYOUT1[090]=08404200
> HW_BCH_DEBUG0[100]=00000000
> DMA regs:
> HW_APBHX_CTRL0[000]=30000000
> HW_APBHX_CTRL1[010]=ffff0000
> HW_APBHX_CTRL2[020]=00000000
> HW_APBHX_CHANNEL_CTRL[030]=00000000
> HW_APBHX_CHn_CURCMDAR(0)[100]=46e1c000
> HW_APBHX_CHn_NXTCMDAR(0)[110]=46e1c04c
> HW_APBHX_CHn_CMD(0)[120]=000001c8
> HW_APBHX_CHn_BAR(0)[130]=00000000
> HW_APBHX_CHn_SEMA(0)[140]=00000000
> HW_APBHX_CHn_DEBUG1(0)[150]=00a0001e
> HW_APBHX_CHn_DEBUG2(0)[160]=00000000
> HW_APBHX_CHn_CURCMDAR(4)[2c0]=4652c098
> HW_APBHX_CHn_NXTCMDAR(4)[2d0]=4652c0e4
> HW_APBHX_CHn_CMD(4)[2e0]=000001c9
> HW_APBHX_CHn_BAR(4)[2f0]=46553241
> HW_APBHX_CHn_SEMA(4)[300]=00010000
> HW_APBHX_CHn_DEBUG1(4)[310]=27a00015
> HW_APBHX_CHn_DEBUG2(4)[320]=00000000
> BCH Geometry :
> GF length : 13
> ECC Strength : 8
> Page Size in Bytes : 2112
> Metadata Size in Bytes : 10
> ECC Chunk Size in Bytes: 512
> ECC Chunk Count : 4
> Payload Size in Bytes : 2048
> Auxiliary Size in Bytes: 16
> Auxiliary Status Offset: 12
> Block Mark Byte Offset : 1999
> Block Mark Bit Offset : 0
>
> I'm doing a:
> dd if=/dev/mtd0> /dev/null& dd if=/dev/mmcblk0> /dev/null
> Sometimes the 'dd' accessing the SD card will stall indefinitely.
> Also copying data from SD card to flash will produce the error, though
> less likely.
>
> This looks like the problem arises in the DMA driver when multiple
> channels are being used concurrently. The GPMI driver will bail out
> with the timeout error while the MMC driver obviously has no timeout
> check for this situation.
>
> I can mostly rule out HW problems, because the same board works
> perfectly well with WindowsCE (tested with a copy operation between
> flash and SD card).
>
>
> Lothar Wa?mann
^ permalink raw reply
* [PATCH] arm: sched_clock: Enable HAVE_SCHED_CLOCK support without init_sched_clock
From: Russell King - ARM Linux @ 2011-09-15 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915073511.GA31732@july>
On Thu, Sep 15, 2011 at 04:35:12PM +0900, Kyungmin Park wrote:
> From: Kyungmin Park <kyungmin.park@samsung.com>
>
> On Samsung Exynos4 series, EVT0 chip uses the s5p_timer with HAVE_SCHED_CLOCK and remains use the MCT timer without init_sched_clock.
So in other words, sched_clock on exynos4 is broken because the update
function won't be called, and it'll wrap well below the 64-bit ns range
required of it.
NAK.
^ permalink raw reply
* [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
From: Thomas Hellstrom @ 2011-09-15 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000701cc7345$b03c9600$10b5c200$%dae@samsung.com>
On 09/15/2011 03:20 AM, Inki Dae wrote:
> Hi, Thomas.
>
>
>> -----Original Message-----
>> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
>> Sent: Wednesday, September 14, 2011 4:57 PM
>> To: Inki Dae
>> Cc: 'Rob Clark'; kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-
>> arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
>> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>>
>> On 09/14/2011 07:55 AM, Inki Dae wrote:
>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rob Clark [mailto:robdclark at gmail.com]
>>>> Sent: Wednesday, September 14, 2011 11:26 AM
>>>> To: Inki Dae
>>>> Cc: Thomas Hellstrom; kyungmin.park at samsung.com;
>>>>
> sw0312.kim at samsung.com;
>
>>>> linux-arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
>>>> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>>>>
>>>> On Tue, Sep 13, 2011 at 9:03 PM, Inki Dae<inki.dae@samsung.com> wrote:
>>>>
>>>>
>>>>> Hi Thomas.
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
>>>>>> Sent: Monday, September 12, 2011 3:32 PM
>>>>>> To: Rob Clark
>>>>>> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com;
>>>>>>
>> linux-
>>
>>>>>> arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
>>>>>> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC
>>>>>>
>> EXYNOS4210.
>>
>>>>>> On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
>>>>>>
>>>>>>
>>>>>>> On 09/10/2011 07:31 PM, Rob Clark wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Sat, Sep 10, 2011 at 9:04 AM, Thomas
>>>>>>>> Hellstrom<thomas@shipmail.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 09/09/2011 01:38 PM, Inki Dae wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> This patch is a DRM Driver for Samsung SoC Exynos4210 and now
>>>>>>>>>>
>>>>>>>>>>
>>>> enables
>>>>
>>>>
>>>>>>>>>> only FIMD yet but we will add HDMI support also in the future.
>>>>>>>>>>
>>>>>>>>>> from now on, I will remove RFC prefix because I think we have got
>>>>>>>>>> comments
>>>>>>>>>> enough.
>>>>>>>>>>
>>>>>>>>>> this patch is based on git repository below:
>>>>>>>>>>
>>>>>>>>>>
> git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
>
>>>>>>>>>> branch name: drm-next
>>>>>>>>>> commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
>>>>>>>>>>
>>>>>>>>>> you can refer to our working repository below:
>>>>>>>>>> http://git.infradead.org/users/kmpark/linux-2.6-samsung
>>>>>>>>>> branch name: samsung-drm
>>>>>>>>>>
>>>>>>>>>> We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
>>>>>>>>>> based on Linux framebuffer) but couldn't so because lowlevel
>>>>>>>>>>
>> codes
>>
>>>>>>>>>> of s3c-fb.c are included internally and so FIMD module of this
>>>>>>>>>> driver has
>>>>>>>>>> its own lowlevel codes.
>>>>>>>>>>
>>>>>>>>>> We used GEM framework for buffer management and DMA
>>>>>>>>>>
>>>>>>>>>>
>>>> APIs(dma_alloc_*)
>>>>
>>>>
>>>>>>>>>> for buffer allocation. by using DMA API, we could use CMA later.
>>>>>>>>>>
>>>>>>>>>> Refer to this link for CMA(Continuous Memory Allocator):
>>>>>>>>>> http://lkml.org/lkml/2011/7/20/45
>>>>>>>>>>
>>>>>>>>>> this driver supports only physically continuous
>>>>>>>>>>
> memory(non-iommu).
>
>>>>>>>>>> Links to previous versions of the patchset:
>>>>>>>>>> v1:< https://lwn.net/Articles/454380/>
>>>>>>>>>> v2:< http://www.spinics.net/lists/kernel/msg1224275.html>
>>>>>>>>>> v3:< http://www.gossamer-
>>>>>>>>>>
>>>>>>>>>>
>>>> threads.com/lists/linux/kernel/1423684>
>>>>
>>>>
>>>>>>>>>> Changelog v2:
>>>>>>>>>> DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
>>>>>>>>>>
>>>>>>>>>> this feature maps user address space to physical memory
>>>>>>>>>>
>>>>>>>>>>
>>>> region
>>>>
>>>>
>>>>>>>>>> once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP
>>>>>>>>>>
>>>>>>>>>>
>>>> ioctl.
>>>>
>>>>
>>>>>>>>>> DRM: code clean and add exception codes.
>>>>>>>>>>
>>>>>>>>>> Changelog v3:
>>>>>>>>>> DRM: Support multiple irq.
>>>>>>>>>>
>>>>>>>>>> FIMD and HDMI have their own irq handler but DRM Framework
>>>>>>>>>>
>>>>>>>>>>
>>>> can
>>>>
>>>>
>>>>>>>>>> regiter
>>>>>>>>>> only one irq handler this patch supports mutiple irq for
>>>>>>>>>> Samsung SoC.
>>>>>>>>>>
>>>>>>>>>> DRM: Consider modularization.
>>>>>>>>>>
>>>>>>>>>> each DRM, FIMD could be built as a module.
>>>>>>>>>>
>>>>>>>>>> DRM: Have indenpendent crtc object.
>>>>>>>>>>
>>>>>>>>>> crtc isn't specific to SoC Platform so this patch gets a
>>>>>>>>>>
>> crtc
>>
>>>>>>>>>> to be used as common object.
>>>>>>>>>> created crtc could be attached to any encoder object.
>>>>>>>>>>
>>>>>>>>>> DRM: code clean and add exception codes.
>>>>>>>>>>
>>>>>>>>>> Changelog v4:
>>>>>>>>>> DRM: remove is_defult from samsung_fb.
>>>>>>>>>>
>>>>>>>>>> is_default isn't used for default framebuffer.
>>>>>>>>>>
>>>>>>>>>> DRM: code refactoring to fimd module.
>>>>>>>>>> this patch is be considered with multiple display objects
>>>>>>>>>>
>> and
>>
>>>>>>>>>> would use its own request_irq() to register a irq handler
>>>>>>>>>> instead of
>>>>>>>>>> drm framework's one.
>>>>>>>>>>
>>>>>>>>>> DRM: remove find_samsung_drm_gem_object()
>>>>>>>>>>
>>>>>>>>>> DRM: move kernel private data structures and definitions to
>>>>>>>>>>
>> driver
>>
>>>>>>>>>> folder.
>>>>>>>>>>
>>>>>>>>>> samsung_drm.h would contain only public information for
>>>>>>>>>>
>>>>>>>>>>
>>>>> userspace
>>>>>
>>>>>
>>>>>>>>>> ioctl interface.
>>>>>>>>>>
>>>>>>>>>> DRM: code refactoring to gem modules.
>>>>>>>>>> buffer module isn't dependent of gem module anymore.
>>>>>>>>>>
>>>>>>>>>> DRM: fixed security issue.
>>>>>>>>>>
>>>>>>>>>> DRM: remove encoder porinter from specific connector.
>>>>>>>>>>
>>>>>>>>>> samsung connector doesn't need to have generic encoder.
>>>>>>>>>>
>>>>>>>>>> DRM: code clean and add exception codes.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Inki Dae<inki.dae@samsung.com>
>>>>>>>>>> Signed-off-by: Joonyoung Shim<jy0922.shim@samsung.com>
>>>>>>>>>> Signed-off-by: SeungWoo Kim<sw0312.kim@samsung.com>
>>>>>>>>>> Signed-off-by: kyungmin.park<kyungmin.park@samsung.com>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> +static struct drm_ioctl_desc samsung_ioctls[] = {
>>>>>>>>>> + DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
>>>>>>>>>> samsung_drm_gem_create_ioctl,
>>>>>>>>>> + DRM_UNLOCKED | DRM_AUTH),
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> With reference my previous security comment.
>>>>>>>>>
>>>>>>>>> Let's say you have a compromised video player running as a DRM
>>>>>>>>> client, that
>>>>>>>>> tries to repeatedly allocate huge GEM buffers...
>>>>>>>>>
>>>>>>>>> What will happen when all DMA memory is exhausted? Will this cause
>>>>>>>>> other
>>>>>>>>> device drivers to see an OOM, or only DRM?
>>>>>>>>>
>>>>>>>>> The old DRI model basically allowed any authorized DRI client to
>>>>>>>>> exhaust
>>>>>>>>> video ram or AGP memory, but never system memory. Newer DRI
>>>>>>>>>
>> drivers
>>
>>>>>>>>> typically only allow DRI masters to do that.
>>>>>>>>> as
>>>>>>>>>
>>>>>>>>> I don't think an authorized DRI client should be able to easily
>>>>>>>>>
>>>>>>>>>
>>>>>> exhaust
>>>>>>
>>>>>>
>>>>>>>>> resources (DMA memory) used by other device drivers causing them
>>>>>>>>>
>> to
>>
>>>>>>>>> fail.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I'm not entirely sure what else can be done, other than have a
>>>>>>>> threshold on max MB allocatable of buffer memory..
>>>>>>>>
>>>>>>>>
>>>>>>> Yes, I think that's what needs to be done, and that threshold should
>>>>>>> be low enough to keep other device drivers running in the worst
>>>>>>> allocation case.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> In the samsung driver case, he is only allocating scanout memory
>>>>>>>>
>>>>>>>>
>>>> from
>>>>
>>>>
>>>>>>>> CMA, so the limit will be the CMA region size.. beyond that you
>>>>>>>>
>>>>>>>>
>>>> can't
>>>>
>>>>
>>>>>>>> get physically contiguous memory. So I think this driver is safe.
>>>>>>>>
>>>>>>>>
>>>>>>> It's not really what well-behaved user-space drivers do that should
>>>>>>>
>>>>>>>
>>>> be
>>>>
>>>>
>>>>>>> a concern, but what compromized application *might* do that is a
>>>>>>>
>>>>>>>
>>>>> concern.
>>>>>
>>>>>
>>>>>> Hmm. I might have missed your point here. If the buffer allocation
>>>>>>
>>>>>>
>>>> ioctl
>>>>
>>>>
>>>>>> only allows allocating CMA memory, then I agree the driver fits the
>>>>>>
>> old
>>
>>>>>> DRI security model, as long as no other devices on the platform will
>>>>>> ever use CMA.
>>>>>>
>>>>>> But in that case, there really should be a way for the driver to say
>>>>>> "Hey, all CMA memory on this system is mine", in the same way
>>>>>> traditional video drivers can claim the VRAM PCI resource.
>>>>>>
>>>>>>
>>>>>>
>>>>> CMA could reserve memory region for a specific driver so DRM Client
>>>>>
>>>>>
>>>> could
>>>>
>>>>
>>>>> request memory allocation from only the region.
>>>>>
>>>>>
>>>>>
>>>>>> This is to avoid the possibility that future drivers that need CMA
>>>>>>
>> will
>>
>>>>>> be vulnerable to DOS-attacks from ill-behaved DRI clients.
>>>>>>
>>>>>>
>>>>>>
>>>>> Thomas, if any application has root authority for ill-purpose then
>>>>>
>> isn't
>>
>>>>>
>>>> it
>>>>
>>>>
>>>>> possible to be vulnerable to DOS-attacks? I think DRM_AUTH means root
>>>>> authority. I know DRM Framework gives any root application DRM_AUTH
>>>>> authority for compatibility.
>>>>>
>>>>>
>>>> DRM_AUTH just means that the client has authenticated w/ X11 (meaning
>>>> that it has permission to connect to x server)..
>>>>
>>>>
>>>>
>>> Yes, I understood so. but see drm_open_helper() of drm_fops.c file
>>>
>> please.
>>
>>> in this function, you can see a line below.
>>> /* for compatibility root is always authenticated */
>>> priv->authenticated = capable(CAP_SYS_ADMIN)
>>>
>>> I think the code above says that any application with root permission is
>>> authenticated.
>>>
>>>
>>>
>> Yes, that is true. A root client may be assumed to have AUTH
>> permissions, but the inverse does not hold, meaning that an AUTH client
>> may *not* be assumed to have root permissions. I think there is a
>> ROOT_ONLY ioctl flag for that.
>>
>> The problem I'm seeing compared to other drivers is the following:
>>
>> Imagine for example that you have a disc driver that allocates temporary
>> memory out of the same DMA pool as the DRM driver.
>>
>> Now you have a video player that is a DRM client. It contains a security
>> flaw and is compromized by somebody trying to play a specially crafted
>> video stream. The video player starts to allocate gem buffers until it
>> receives an -ENOMEM. Then it stops allocating and does nothing.
>>
>> Now the system tries an important disc access (paging for example). This
>> fails, because the video player has exhausted all DMA memory and the
>> disc driver fails to allocate.
>>
>> The system is dead.
>>
>>
> Ok, I understood. but in case of using CMA, DRM driver would have private
> memory pool which is reserved only for itself. so although the video player
> requested gem buffer allocation until it receives an -ENOMEM and then the
> system is try to access the disc, it would work fine. because the region
> requested by system and the region requested by DRM driver could entirely be
> separated. DRM driver wouldn't have implications for the system region.
>
>
>> The point is:
>>
>> If there is a chance that other drivers will use the same DMA/CMA pool
>> as the DRM driver, DRM must leave enough DMA/CMA memory for those
>> drivers to work.
>>
>> The difference compared to other drm drivers:
>>
>> There are other drm drivers that work the same way, with a static
>> allocator. For example "via" and "sis". But those drivers completely
>> claim the resources they are using. Nobody else is expected to use VRAM
>> / AGP.
>>
>>
> I think if we use private cma region for DRM driver then it is similar to
> via and sis way.
>
>
In that case, I agree the driver should be OK.
...
Thanks,
Thomas
^ permalink raw reply
* [PATCH] ARM: exynos4: use the variable for S5P_VA_SYSRAM
From: Kyungmin Park @ 2011-09-15 7:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Kyungmin Park <kyungmin.park@samsung.com>
The CPU1_BOOT_REG and S5P_VA_SYSRAM is used mixed for setup secondary_startup.
Make it consistent statement for setup.
It's also helpful for EVT0 which has another SYSRAM address handling.
if (soc_is_exynos4210_evt0())
sysram = ioremap(EXYNOS4210_EVT0_SYSRAM, SZ_4K);
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
diff --git a/arch/arm/mach-exynos4/platsmp.c b/arch/arm/mach-exynos4/platsmp.c
index 7c2282c..6cdb750 100644
--- a/arch/arm/mach-exynos4/platsmp.c
+++ b/arch/arm/mach-exynos4/platsmp.c
@@ -32,7 +32,7 @@
extern void exynos4_secondary_startup(void);
-#define CPU1_BOOT_REG S5P_VA_SYSRAM
+static void __iomem *sysram;
/*
* control for which core is the next to come out of the secondary
@@ -160,7 +160,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
smp_rmb();
__raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)),
- CPU1_BOOT_REG);
+ sysram);
gic_raise_softirq(cpumask_of(cpu), 1);
if (pen_release == -1)
@@ -207,6 +207,7 @@ void __init smp_init_cpus(void)
void __init platform_smp_prepare_cpus(unsigned int max_cpus)
{
+ sysram = S5P_VA_SYSRAM;
scu_enable(scu_base_addr());
@@ -216,5 +217,5 @@ void __init platform_smp_prepare_cpus(unsigned int max_cpus)
* until it receives a soft interrupt, and then the
* secondary CPU branches to this address.
*/
- __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)), S5P_VA_SYSRAM);
+ __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)), sysram);
}
^ permalink raw reply related
* [PATCH v12 0/3] add the GPMI controller driver for IMX23/IMX28
From: Lothar Waßmann @ 2011-09-15 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315450031-6371-1-git-send-email-b32955@freescale.com>
Hi,
Huang Shijie writes:
> The patch set is based on Artem's tree:
> http://git.infradead.org/users/dedekind/l2-mtd-2.6.git
>
> The general-purpose media interface(GPMI) controller is a flexible interface
> to up to several NAND flashs.
>
> The Bose Ray-Choudhury Hocquenghem(BCH) module is a hardware ECC accelerator.
>
> With the help of BCH, the GPMI controller can choose to do the hardware ECC or
> not.
>
> This driver is a _pure_ MTD NAND controller driver now.
>
>
> The driver depends on another GPMI-NAND device patch set, you can find them at :
> [1] http://marc.info/?l=linux-arm-kernel&m=131416901319573&w=2
> [2] http://marc.info/?l=linux-arm-kernel&m=131416912319668&w=2
> [3] http://marc.info/?l=linux-arm-kernel&m=131416891119504&w=2
> [4] http://marc.info/?l=linux-arm-kernel&m=131416896219539&w=2
>
> Test environment:
> Using imx23 and imx28 boards for test.
>
> imx23 :
> console=ttyAMA0,115200 mtdparts=gpmi-nfc:20m(boot),-(user)
> Tested by USB boot and NAND boot.
>
> imx28 :
> #console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait
> Tested by SD card boot mode.
>
How did you perform your tests?
I tried this driver on our TX28 board with the result that with
concurrent access of the SD card and the NAND flash, I still get the
dreaded DMA timeouts within seconds:
DMA timeout, last DMA :1
GPMI regs:
HW_GPMI_CTRL0[000]=21800001
HW_GPMI_COMPARE[010]=00000000
HW_GPMI_ECCCTRL[020]=00000000
HW_GPMI_ECCCOUNT[030]=00000840
HW_GPMI_PAYLOAD[040]=46578000
HW_GPMI_AUXILIARY[050]=46578800
HW_GPMI_CTRL1[060]=0004000c
HW_GPMI_TIMING0[070]=00010203
HW_GPMI_TIMING1[080]=05000000
HW_GPMI_TIMING2[090]=09020101
HW_GPMI_STAT[0b0]=0d000003
HW_GPMI_DEBUG[0c0]=01000000
BCH regs:
HW_BCH_CTRL[000]=00000100
HW_BCH_STATUS0[010]=00000010
HW_BCH_MODE[020]=00000000
HW_BCH_ENCODEPTR[030]=00000000
HW_BCH_DATAPTR[040]=00000000
HW_BCH_METAPTR[050]=00000000
HW_BCH_LAYOUTSELECT[070]=00000000
HW_BCH_FLASH0LAYOUT0[080]=030a4200
HW_BCH_FLASH0LAYOUT1[090]=08404200
HW_BCH_DEBUG0[100]=00000000
DMA regs:
HW_APBHX_CTRL0[000]=30000000
HW_APBHX_CTRL1[010]=ffff0000
HW_APBHX_CTRL2[020]=00000000
HW_APBHX_CHANNEL_CTRL[030]=00000000
HW_APBHX_CHn_CURCMDAR(0)[100]=46e1c000
HW_APBHX_CHn_NXTCMDAR(0)[110]=46e1c04c
HW_APBHX_CHn_CMD(0)[120]=000001c8
HW_APBHX_CHn_BAR(0)[130]=00000000
HW_APBHX_CHn_SEMA(0)[140]=00000000
HW_APBHX_CHn_DEBUG1(0)[150]=00a0001e
HW_APBHX_CHn_DEBUG2(0)[160]=00000000
HW_APBHX_CHn_CURCMDAR(4)[2c0]=4652c098
HW_APBHX_CHn_NXTCMDAR(4)[2d0]=4652c0e4
HW_APBHX_CHn_CMD(4)[2e0]=000001c9
HW_APBHX_CHn_BAR(4)[2f0]=46553241
HW_APBHX_CHn_SEMA(4)[300]=00010000
HW_APBHX_CHn_DEBUG1(4)[310]=27a00015
HW_APBHX_CHn_DEBUG2(4)[320]=00000000
BCH Geometry :
GF length : 13
ECC Strength : 8
Page Size in Bytes : 2112
Metadata Size in Bytes : 10
ECC Chunk Size in Bytes: 512
ECC Chunk Count : 4
Payload Size in Bytes : 2048
Auxiliary Size in Bytes: 16
Auxiliary Status Offset: 12
Block Mark Byte Offset : 1999
Block Mark Bit Offset : 0
I'm doing a:
dd if=/dev/mtd0 > /dev/null & dd if=/dev/mmcblk0 > /dev/null
Sometimes the 'dd' accessing the SD card will stall indefinitely.
Also copying data from SD card to flash will produce the error, though
less likely.
This looks like the problem arises in the DMA driver when multiple
channels are being used concurrently. The GPMI driver will bail out
with the timeout error while the MMC driver obviously has no timeout
check for this situation.
I can mostly rule out HW problems, because the same board works
perfectly well with WindowsCE (tested with a copy operation between
flash and SD card).
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Thomas Abraham @ 2011-09-15 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316017900-19918-6-git-send-email-robherring2@gmail.com>
Hi Rob,
On 14 September 2011 22:01, Rob Herring <robherring2@gmail.com> wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
>
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
> ?Documentation/devicetree/bindings/arm/gic.txt | ? 53 ++++++++++++++++++++++++
> ?arch/arm/common/gic.c ? ? ? ? ? ? ? ? ? ? ? ? | ? 55 +++++++++++++++++++++++--
> ?arch/arm/include/asm/hardware/gic.h ? ? ? ? ? | ? 10 +++++
> ?3 files changed, 114 insertions(+), 4 deletions(-)
> ?create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
[...]
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index d1ccc72..14de380 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
[...]
> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
> +{
> + ? ? ? void __iomem *cpu_base;
> + ? ? ? void __iomem *dist_base;
> + ? ? ? int irq;
> + ? ? ? struct irq_domain *domain = &gic_data[gic_cnt].domain;
> +
> + ? ? ? if (WARN_ON(!node))
> + ? ? ? ? ? ? ? return;
> +
> + ? ? ? dist_base = of_iomap(node, 0);
> + ? ? ? WARN(!dist_base, "unable to map gic dist registers\n");
> +
> + ? ? ? cpu_base = of_iomap(node, 1);
> + ? ? ? WARN(!cpu_base, "unable to map gic cpu registers\n");
> +
> + ? ? ? domain->nr_irq = gic_irq_count(dist_base);
> + ? ? ? domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
For exynos4, all the interrupts originating from GIC are statically
mapped to start from 32 in the linux virq space (GIC SPI interrupts
start from 64). In the above code, since irq_base would be 0 for
exynos4, the interrupt mapping is not working correctly. In your
previous version of the patch, you have given a option to the platform
code to choose the offset. Could that option be added to this series
also. Or a provision to use platform specific translate function
instead of the irq_domain_simple translator.
Thanks,
Thomas.
[...]
^ permalink raw reply
* [PATCH 2/2] ARM: Exynos4: use s5p-timer for UniversalC210 board
From: Kyungmin Park @ 2011-09-15 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00aa01cc737a$76d75690$648603b0$%kim@samsung.com>
On Thu, Sep 15, 2011 at 4:38 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Kyungmin Park wrote:
>>
>> On Thu, Sep 15, 2011 at 3:03 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>> > Kukjin Kim wrote:
>> >>
>> >> Kyungmin Park wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > It's required for boot universal c210 w/ EVT0 chip.
>> >> > Can you include it at 3.1 fixed branch?
>> >> >
>> >> Sure, will apply into samsung-fixes for 3.1.
>> >
>> > Unfortunately, it happens boot failure with this patch on other
> EXYNOS4210
>> > boards and it is due to HAVE_SCHED_CLOCK.
>> >
>> >> > > + ? ? ? select HAVE_SCHED_CLOCK
>> >
>> > I think, we need to sort out the method...
>> As sched_clock_postinit is called at generic time code by
>> HAVE_SCHED_CLOCK. and there's no sched_clock_update_fn() is defined.
>> As a work-around, you can test it.
>>
>> static void sched_clock_poll(unsigned long wrap_ticks)
>> {
>> ? ? ? ? mod_timer(&sched_clock_timer, round_jiffies(jiffies +
> wrap_ticks));
>> ? ? ? ? if (sched_clock_update_fn)
>> ? ? ? ? ? ? ? ? sched_clock_update_fn();
>> }
>>
>
> Following is better than above but need Russell's review
Right, during the make a patch, I also found it. Check the patch
And boot tested both EVT0 and others.
>
> diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
> index 9a46370..b1a1283 100644
> --- a/arch/arm/kernel/sched_clock.c
> +++ b/arch/arm/kernel/sched_clock.c
> @@ -70,5 +70,6 @@ void __init init_sched_clock(struct clock_data *cd, void
> (*update)(void),
>
> ?void __init sched_clock_postinit(void)
> ?{
> - ? ? ? sched_clock_poll(sched_clock_timer.data);
> + ? ? ? if (sched_clock_update_fn)
> + ? ? ? ? ? ? ? sched_clock_poll(sched_clock_timer.data);
> ?}
>
>
>> To solve the problem correctly. you can add init_sched_clock at
>> "arch/arm/mach-exynos4/mct.c" properly
>>
>> Please test the work-around and share the result. I'll try to find the
>> proper place to add init_sched_clock at mct.c
>>
>> Thank you,
>> Kyungmin Park
>>
>>
>> >
>> > Thanks.
>> >
>> > Best regards,
>> > Kgene.
>> > --
>> > Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
>> > SW Solution Development Team, Samsung Electronics Co., Ltd.
>> >
>> >>
>> >> > Thank you,
>> >> > Kyungmin Park
>> >> >
>> >> > On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski
>> >> > <m.szyprowski@samsung.com> wrote:
>> >> > > Commit 069d4e743 removed support for local timers and forced to use
>> > MCT
>> >> as
>> >> > > event source. However MCT is not operating properly on early
> revision
>> > (EVT0)
>> >> > > of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4
> EVT0,
>> > so
>> >> > that
>> >> > > commit broke support for it. This patch provides a workaround that
>> > enables
>> >> > > UniversalC210 boards to boot again. s5p-timer is used as an event
>> > source.
>> >> > >
>> >> > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> >> > > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>> >> > > ---
>> >> > > ?arch/arm/mach-exynos4/Kconfig ? ? ? ? ? ? ? | ? ?3 +++
>> >> > > ?arch/arm/mach-exynos4/mach-universal_c210.c | ? ?4 +++-
>> >> > > ?2 files changed, 6 insertions(+), 1 deletions(-)
>> >> > >
>> >> > > diff --git a/arch/arm/mach-exynos4/Kconfig
>> > b/arch/arm/mach-exynos4/Kconfig
>> >> > > index 9d62e13..2aad73f 100644
>> >> > > --- a/arch/arm/mach-exynos4/Kconfig
>> >> > > +++ b/arch/arm/mach-exynos4/Kconfig
>> >> > > @@ -173,6 +173,9 @@ config MACH_ARMLEX4210
>> >> > > ?config MACH_UNIVERSAL_C210
>> >> > > ? ? ? ?bool "Mobile UNIVERSAL_C210 Board"
>> >> > > ? ? ? ?select CPU_EXYNOS4210
>> >> > > + ? ? ? select S5P_HRT
>> >> > > + ? ? ? select CLKSRC_MMIO
>> >> > > + ? ? ? select HAVE_SCHED_CLOCK
>> >> > > ? ? ? ?select S5P_GPIO_INT
>> >> > > ? ? ? ?select S5P_DEV_FIMC0
>> >> > > ? ? ? ?select S5P_DEV_FIMC1
>> >> > > diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c
>> > b/arch/arm/mach-
>> >> > exynos4/mach-universal_c210.c
>> >> > > index 0e280d1..ca9e7b7 100644
>> >> > > --- a/arch/arm/mach-exynos4/mach-universal_c210.c
>> >> > > +++ b/arch/arm/mach-exynos4/mach-universal_c210.c
>> >> > > @@ -34,6 +34,7 @@
>> >> > > ?#include <plat/mfc.h>
>> >> > > ?#include <plat/sdhci.h>
>> >> > > ?#include <plat/pd.h>
>> >> > > +#include <plat/s5p-time.h>
>> >> > >
>> >> > > ?#include <mach/map.h>
>> >> > >
>> >> > > @@ -730,6 +731,7 @@ static void __init universal_map_io(void)
>> >> > > ? ? ? ?s5p_init_io(NULL, 0, S5P_VA_CHIPID);
>> >> > > ? ? ? ?s3c24xx_init_clocks(24000000);
>> >> > > ? ? ? ?s3c24xx_init_uarts(universal_uartcfgs,
>> > ARRAY_SIZE(universal_uartcfgs));
>> >> > > + ? ? ? s5p_set_timer_source(S5P_PWM2, S5P_PWM4);
>> >> > > ?}
>> >> > >
>> >> > > ?static void __init universal_reserve(void)
>> >> > > @@ -766,6 +768,6 @@ MACHINE_START(UNIVERSAL_C210,
>> >> > "UNIVERSAL_C210")
>> >> > > ? ? ? ?.init_irq ? ? ? = exynos4_init_irq,
>> >> > > ? ? ? ?.map_io ? ? ? ? = universal_map_io,
>> >> > > ? ? ? ?.init_machine ? = universal_machine_init,
>> >> > > - ? ? ? .timer ? ? ? ? ?= &exynos4_timer,
>> >> > > + ? ? ? .timer ? ? ? ? ?= &s5p_timer,
>> >> > > ? ? ? ?.reserve ? ? ? ?= &universal_reserve,
>> >> > > ?MACHINE_END
>> >> > > --
>> >> > > 1.7.1.569.g6f426
>> >> > >
>> >> > > --
>
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 2/2] ARM: Exynos4: use s5p-timer for UniversalC210 board
From: Kukjin Kim @ 2011-09-15 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2UKh5poAVFoXbEL0N9Afj3D16nuMYWEmeFRNL47P5onpw@mail.gmail.com>
Kyungmin Park wrote:
>
> On Thu, Sep 15, 2011 at 3:03 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> > Kukjin Kim wrote:
> >>
> >> Kyungmin Park wrote:
> >> >
> >> > Hi,
> >> >
> >> > It's required for boot universal c210 w/ EVT0 chip.
> >> > Can you include it at 3.1 fixed branch?
> >> >
> >> Sure, will apply into samsung-fixes for 3.1.
> >
> > Unfortunately, it happens boot failure with this patch on other
EXYNOS4210
> > boards and it is due to HAVE_SCHED_CLOCK.
> >
> >> > > + ? ? ? select HAVE_SCHED_CLOCK
> >
> > I think, we need to sort out the method...
> As sched_clock_postinit is called at generic time code by
> HAVE_SCHED_CLOCK. and there's no sched_clock_update_fn() is defined.
> As a work-around, you can test it.
>
> static void sched_clock_poll(unsigned long wrap_ticks)
> {
> mod_timer(&sched_clock_timer, round_jiffies(jiffies +
wrap_ticks));
> if (sched_clock_update_fn)
> sched_clock_update_fn();
> }
>
Following is better than above but need Russell's review
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 9a46370..b1a1283 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -70,5 +70,6 @@ void __init init_sched_clock(struct clock_data *cd, void
(*update)(void),
void __init sched_clock_postinit(void)
{
- sched_clock_poll(sched_clock_timer.data);
+ if (sched_clock_update_fn)
+ sched_clock_poll(sched_clock_timer.data);
}
> To solve the problem correctly. you can add init_sched_clock at
> "arch/arm/mach-exynos4/mct.c" properly
>
> Please test the work-around and share the result. I'll try to find the
> proper place to add init_sched_clock at mct.c
>
> Thank you,
> Kyungmin Park
>
>
> >
> > Thanks.
> >
> > Best regards,
> > Kgene.
> > --
> > Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> > SW Solution Development Team, Samsung Electronics Co., Ltd.
> >
> >>
> >> > Thank you,
> >> > Kyungmin Park
> >> >
> >> > On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski
> >> > <m.szyprowski@samsung.com> wrote:
> >> > > Commit 069d4e743 removed support for local timers and forced to use
> > MCT
> >> as
> >> > > event source. However MCT is not operating properly on early
revision
> > (EVT0)
> >> > > of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4
EVT0,
> > so
> >> > that
> >> > > commit broke support for it. This patch provides a workaround that
> > enables
> >> > > UniversalC210 boards to boot again. s5p-timer is used as an event
> > source.
> >> > >
> >> > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >> > > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> >> > > ---
> >> > > ?arch/arm/mach-exynos4/Kconfig ? ? ? ? ? ? ? | ? ?3 +++
> >> > > ?arch/arm/mach-exynos4/mach-universal_c210.c | ? ?4 +++-
> >> > > ?2 files changed, 6 insertions(+), 1 deletions(-)
> >> > >
> >> > > diff --git a/arch/arm/mach-exynos4/Kconfig
> > b/arch/arm/mach-exynos4/Kconfig
> >> > > index 9d62e13..2aad73f 100644
> >> > > --- a/arch/arm/mach-exynos4/Kconfig
> >> > > +++ b/arch/arm/mach-exynos4/Kconfig
> >> > > @@ -173,6 +173,9 @@ config MACH_ARMLEX4210
> >> > > ?config MACH_UNIVERSAL_C210
> >> > > ? ? ? ?bool "Mobile UNIVERSAL_C210 Board"
> >> > > ? ? ? ?select CPU_EXYNOS4210
> >> > > + ? ? ? select S5P_HRT
> >> > > + ? ? ? select CLKSRC_MMIO
> >> > > + ? ? ? select HAVE_SCHED_CLOCK
> >> > > ? ? ? ?select S5P_GPIO_INT
> >> > > ? ? ? ?select S5P_DEV_FIMC0
> >> > > ? ? ? ?select S5P_DEV_FIMC1
> >> > > diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c
> > b/arch/arm/mach-
> >> > exynos4/mach-universal_c210.c
> >> > > index 0e280d1..ca9e7b7 100644
> >> > > --- a/arch/arm/mach-exynos4/mach-universal_c210.c
> >> > > +++ b/arch/arm/mach-exynos4/mach-universal_c210.c
> >> > > @@ -34,6 +34,7 @@
> >> > > ?#include <plat/mfc.h>
> >> > > ?#include <plat/sdhci.h>
> >> > > ?#include <plat/pd.h>
> >> > > +#include <plat/s5p-time.h>
> >> > >
> >> > > ?#include <mach/map.h>
> >> > >
> >> > > @@ -730,6 +731,7 @@ static void __init universal_map_io(void)
> >> > > ? ? ? ?s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> >> > > ? ? ? ?s3c24xx_init_clocks(24000000);
> >> > > ? ? ? ?s3c24xx_init_uarts(universal_uartcfgs,
> > ARRAY_SIZE(universal_uartcfgs));
> >> > > + ? ? ? s5p_set_timer_source(S5P_PWM2, S5P_PWM4);
> >> > > ?}
> >> > >
> >> > > ?static void __init universal_reserve(void)
> >> > > @@ -766,6 +768,6 @@ MACHINE_START(UNIVERSAL_C210,
> >> > "UNIVERSAL_C210")
> >> > > ? ? ? ?.init_irq ? ? ? = exynos4_init_irq,
> >> > > ? ? ? ?.map_io ? ? ? ? = universal_map_io,
> >> > > ? ? ? ?.init_machine ? = universal_machine_init,
> >> > > - ? ? ? .timer ? ? ? ? ?= &exynos4_timer,
> >> > > + ? ? ? .timer ? ? ? ? ?= &s5p_timer,
> >> > > ? ? ? ?.reserve ? ? ? ?= &universal_reserve,
> >> > > ?MACHINE_END
> >> > > --
> >> > > 1.7.1.569.g6f426
> >> > >
> >> > > --
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply related
* [PATCH] arm: sched_clock: Enable HAVE_SCHED_CLOCK support without init_sched_clock
From: Kyungmin Park @ 2011-09-15 7:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Kyungmin Park <kyungmin.park@samsung.com>
On Samsung Exynos4 series, EVT0 chip uses the s5p_timer with HAVE_SCHED_CLOCK and remains use the MCT timer without init_sched_clock.
The similar combination will be happend with other SOCs. some board use HAVE_SCHED_CLOCK or others are not.
To co-exist the these boards. check the sched_clock_update_fn when sched_clock_postinit is called and return if not defined.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 9a46370..12c6b6b 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -70,5 +70,8 @@ void __init init_sched_clock(struct clock_data *cd, void (*update)(void),
void __init sched_clock_postinit(void)
{
+ /* If init_sched_clock is not called, just return */
+ if (!sched_clock_update_fn)
+ return;
sched_clock_poll(sched_clock_timer.data);
}
^ permalink raw reply related
* [PATCH v2 0/4] S3C2416: Enable IIS and HSSPI clocks
From: Heiko Stübner @ 2011-09-15 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201108282006.31667.heiko@sntech.de>
Am Sonntag, 28. August 2011, 20:06:31 schrieb Heiko St?bner:
> S3C2416/2450 (probably S3C2443 too) can use the newer style
> kernel-drivers made for S3C64xx and above for their I2S and
> HS-SPI controllers.
>
> So as a first step in this direction, these patches add their
> respective clocks.
ping? Any comments?
Thanks
Heiko
^ permalink raw reply
* gpio_ensure_requested error on mx31pdk boot
From: Uwe Kleine-König @ 2011-09-15 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AmM2yd5FopjNO9QsPNLZiBNH3U29_xXPV3cnZnB9EjtQ@mail.gmail.com>
On Thu, Sep 15, 2011 at 12:39:07AM -0300, Fabio Estevam wrote:
> Hi,
>
> On a MX31PDK running 3.1-rc3 from Pengutronix's imx-features branch I
> get the following:
>
> Registering mxc_nand as whole device
> ------------[ cut here ]------------
> WARNING: at drivers/gpio/gpiolib.c:101 gpio_ensure_requested+0x4c/0xf4()
> autorequest GPIO-0
> Modules linked in:
> [<c0014410>] (unwind_backtrace+0x0/0xf4) from [<c0025754>] (warn_slowpath_common
> +0x4c/0x64)
> [<c0025754>] (warn_slowpath_common+0x4c/0x64) from [<c0025800>] (warn_slowpath_f
> mt+0x30/0x40)
> [<c0025800>] (warn_slowpath_fmt+0x30/0x40) from [<c0198688>] (gpio_ensure_reques
> ted+0x4c/0xf4)
> [<c0198688>] (gpio_ensure_requested+0x4c/0xf4) from [<c01988c8>] (gpio_direction
> _output+0xa0/0x138)
> [<c01988c8>] (gpio_direction_output+0xa0/0x138) from [<c01ed198>] (spi_imx_setup
> +0x38/0x4c)
> [<c01ed198>] (spi_imx_setup+0x38/0x4c) from [<c01eb5d0>] (spi_setup+0x38/0x50)
> [<c01eb5d0>] (spi_setup+0x38/0x50) from [<c01eb85c>] (spi_add_device+0x94/0x124)
> [<c01eb85c>] (spi_add_device+0x94/0x124) from [<c01eb960>] (spi_new_device+0x74/
> 0xac)
> [<c01eb960>] (spi_new_device+0x74/0xac) from [<c01eb9b8>] (spi_match_master_to_b
> oardinfo+0x20/0x40)
> [<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40) from [<c01eba88>] (spi_re
> gister_master+0xb0/0x104)
> [<c01eba88>] (spi_register_master+0xb0/0x104) from [<c01ec0b4>] (spi_bitbang_sta
> rt+0x104/0x17c)
> [<c01ec0b4>] (spi_bitbang_start+0x104/0x17c) from [<c02c2c4c>] (spi_imx_probe+0x
> 2fc/0x404)
> [<c02c2c4c>] (spi_imx_probe+0x2fc/0x404) from [<c01c2498>] (platform_drv_probe+0
> x18/0x1c)
> [<c01c2498>] (platform_drv_probe+0x18/0x1c) from [<c01c1058>] (driver_probe_devi
> ce+0x78/0x174)
> [<c01c1058>] (driver_probe_device+0x78/0x174) from [<c01c11e0>] (__driver_attach
> +0x8c/0x90)
> [<c01c11e0>] (__driver_attach+0x8c/0x90) from [<c01c0860>] (bus_for_each_dev+0x6
> 0/0x8c)
> [<c01c0860>] (bus_for_each_dev+0x60/0x8c) from [<c01c0088>] (bus_add_driver+0xa0
> /0x288)
> [<c01c0088>] (bus_add_driver+0xa0/0x288) from [<c01c179c>] (driver_register+0x78
> /0x18c)
> [<c01c179c>] (driver_register+0x78/0x18c) from [<c0008490>] (do_one_initcall+0x3
> 4/0x178)
> [<c0008490>] (do_one_initcall+0x34/0x178) from [<c03a5204>] (kernel_init+0x74/0x
> 118)
> [<c03a5204>] (kernel_init+0x74/0x118) from [<c000f65c>] (kernel_thread_exit+0x0/
> 0x8)
> ---[ end trace 759f924b30fd5a44 ]---
>
> I have not started debugging yet, but just wondering if anyone else
> has seen this.
I havn't seen it. Just in case you don't know, that means a gpio was
used without being (successfully) requested. On the other hand I wonder
if GPIO-0 is correct here?!
BTW, the master branch on the imx repo contains all current work, that
is for-next + two fixes that won't enter mainline via the imx repo.
That's probably the better branch to use.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [RFC PATCH-V2 0/4] Introducing TI's New SoC/board AM335XEVM
From: Hiremath, Vaibhav @ 2011-09-15 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915003210.GC30941@atomide.com>
> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Thursday, September 15, 2011 6:02 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap at vger.kernel.org; Hilman, Kevin; paul at pwsan.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [RFC PATCH-V2 0/4] Introducing TI's New SoC/board AM335XEVM
>
> * hvaibhav at ti.com <hvaibhav@ti.com> [110829 05:52]:
> > From: Vaibhav Hiremath <hvaibhav@ti.com>
> >
> > This patch set adds support for AM335x device having
> > Cortex-A8 MPU.
> >
> > AM335X is treated as another OMAP3 variant, where,
> > along with existing cpu class OMAP34XX, new cpu class AM33XX is created
> > and the respective type is AM335X, which is newly added device in the
> family.
> > This means, cpu_is_omap34xx(), cpu_is_am33xx() and
> > cpu_is_am335x() checks return success for AM335X.
> >
> > Currently submitting this patch series as a RFC (V2), to initiate the
> > discussion on the approach we have chosen for AM335x device support.
> > Based on the feedback, will submit the final version of patch series
> > immediately.
>
> Can you please rebase these on Paul's CHIP_IS removal series?
>
> Those patches are available at:
>
> git://git.pwsan.com/linux-2.6 omap_chip_remove_cleanup_3.2
>
[Hiremath, Vaibhav] Thanks Tony for your comments,
Yeah, I will rebase and submit it again ASAP.
Thanks,
Vaibhav
> Regards,
>
> Tony
^ permalink raw reply
* [PATCH 2/2] ARM: Exynos4: use s5p-timer for UniversalC210 board
From: Kyungmin Park @ 2011-09-15 6:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00a301cc736d$2d9c4fb0$88d4ef10$%kim@samsung.com>
On Thu, Sep 15, 2011 at 3:03 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Kukjin Kim wrote:
>>
>> Kyungmin Park wrote:
>> >
>> > Hi,
>> >
>> > It's required for boot universal c210 w/ EVT0 chip.
>> > Can you include it at 3.1 fixed branch?
>> >
>> Sure, will apply into samsung-fixes for 3.1.
>
> Unfortunately, it happens boot failure with this patch on other EXYNOS4210
> boards and it is due to HAVE_SCHED_CLOCK.
>
>> > > + ? ? ? select HAVE_SCHED_CLOCK
>
> I think, we need to sort out the method...
As sched_clock_postinit is called at generic time code by
HAVE_SCHED_CLOCK. and there's no sched_clock_update_fn() is defined.
As a work-around, you can test it.
static void sched_clock_poll(unsigned long wrap_ticks)
{
mod_timer(&sched_clock_timer, round_jiffies(jiffies + wrap_ticks));
if (sched_clock_update_fn)
sched_clock_update_fn();
}
To solve the problem correctly. you can add init_sched_clock at
"arch/arm/mach-exynos4/mct.c" properly
Please test the work-around and share the result. I'll try to find the
proper place to add init_sched_clock at mct.c
Thank you,
Kyungmin Park
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>>
>> > Thank you,
>> > Kyungmin Park
>> >
>> > On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski
>> > <m.szyprowski@samsung.com> wrote:
>> > > Commit 069d4e743 removed support for local timers and forced to use
> MCT
>> as
>> > > event source. However MCT is not operating properly on early revision
> (EVT0)
>> > > of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4 EVT0,
> so
>> > that
>> > > commit broke support for it. This patch provides a workaround that
> enables
>> > > UniversalC210 boards to boot again. s5p-timer is used as an event
> source.
>> > >
>> > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> > > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>> > > ---
>> > > ?arch/arm/mach-exynos4/Kconfig ? ? ? ? ? ? ? | ? ?3 +++
>> > > ?arch/arm/mach-exynos4/mach-universal_c210.c | ? ?4 +++-
>> > > ?2 files changed, 6 insertions(+), 1 deletions(-)
>> > >
>> > > diff --git a/arch/arm/mach-exynos4/Kconfig
> b/arch/arm/mach-exynos4/Kconfig
>> > > index 9d62e13..2aad73f 100644
>> > > --- a/arch/arm/mach-exynos4/Kconfig
>> > > +++ b/arch/arm/mach-exynos4/Kconfig
>> > > @@ -173,6 +173,9 @@ config MACH_ARMLEX4210
>> > > ?config MACH_UNIVERSAL_C210
>> > > ? ? ? ?bool "Mobile UNIVERSAL_C210 Board"
>> > > ? ? ? ?select CPU_EXYNOS4210
>> > > + ? ? ? select S5P_HRT
>> > > + ? ? ? select CLKSRC_MMIO
>> > > + ? ? ? select HAVE_SCHED_CLOCK
>> > > ? ? ? ?select S5P_GPIO_INT
>> > > ? ? ? ?select S5P_DEV_FIMC0
>> > > ? ? ? ?select S5P_DEV_FIMC1
>> > > diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c
> b/arch/arm/mach-
>> > exynos4/mach-universal_c210.c
>> > > index 0e280d1..ca9e7b7 100644
>> > > --- a/arch/arm/mach-exynos4/mach-universal_c210.c
>> > > +++ b/arch/arm/mach-exynos4/mach-universal_c210.c
>> > > @@ -34,6 +34,7 @@
>> > > ?#include <plat/mfc.h>
>> > > ?#include <plat/sdhci.h>
>> > > ?#include <plat/pd.h>
>> > > +#include <plat/s5p-time.h>
>> > >
>> > > ?#include <mach/map.h>
>> > >
>> > > @@ -730,6 +731,7 @@ static void __init universal_map_io(void)
>> > > ? ? ? ?s5p_init_io(NULL, 0, S5P_VA_CHIPID);
>> > > ? ? ? ?s3c24xx_init_clocks(24000000);
>> > > ? ? ? ?s3c24xx_init_uarts(universal_uartcfgs,
> ARRAY_SIZE(universal_uartcfgs));
>> > > + ? ? ? s5p_set_timer_source(S5P_PWM2, S5P_PWM4);
>> > > ?}
>> > >
>> > > ?static void __init universal_reserve(void)
>> > > @@ -766,6 +768,6 @@ MACHINE_START(UNIVERSAL_C210,
>> > "UNIVERSAL_C210")
>> > > ? ? ? ?.init_irq ? ? ? = exynos4_init_irq,
>> > > ? ? ? ?.map_io ? ? ? ? = universal_map_io,
>> > > ? ? ? ?.init_machine ? = universal_machine_init,
>> > > - ? ? ? .timer ? ? ? ? ?= &exynos4_timer,
>> > > + ? ? ? .timer ? ? ? ? ?= &s5p_timer,
>> > > ? ? ? ?.reserve ? ? ? ?= &universal_reserve,
>> > > ?MACHINE_END
>> > > --
>> > > 1.7.1.569.g6f426
>> > >
>> > > --
>> > > To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
>> > > the body of a message to majordomo at vger.kernel.org
>> > > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>> > >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 2/2] ARM: Exynos4: use s5p-timer for UniversalC210 board
From: Kukjin Kim @ 2011-09-15 6:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2V6Sfjmjupj5oBd_5vziBa4iezBpRfK9tNECrFO5sSfLw@mail.gmail.com>
Kukjin Kim wrote:
>
> Kyungmin Park wrote:
> >
> > Hi,
> >
> > It's required for boot universal c210 w/ EVT0 chip.
> > Can you include it at 3.1 fixed branch?
> >
> Sure, will apply into samsung-fixes for 3.1.
Unfortunately, it happens boot failure with this patch on other EXYNOS4210
boards and it is due to HAVE_SCHED_CLOCK.
> > > + select HAVE_SCHED_CLOCK
I think, we need to sort out the method...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> > Thank you,
> > Kyungmin Park
> >
> > On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski
> > <m.szyprowski@samsung.com> wrote:
> > > Commit 069d4e743 removed support for local timers and forced to use
MCT
> as
> > > event source. However MCT is not operating properly on early revision
(EVT0)
> > > of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4 EVT0,
so
> > that
> > > commit broke support for it. This patch provides a workaround that
enables
> > > UniversalC210 boards to boot again. s5p-timer is used as an event
source.
> > >
> > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > > ---
> > > ?arch/arm/mach-exynos4/Kconfig ? ? ? ? ? ? ? | ? ?3 +++
> > > ?arch/arm/mach-exynos4/mach-universal_c210.c | ? ?4 +++-
> > > ?2 files changed, 6 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-exynos4/Kconfig
b/arch/arm/mach-exynos4/Kconfig
> > > index 9d62e13..2aad73f 100644
> > > --- a/arch/arm/mach-exynos4/Kconfig
> > > +++ b/arch/arm/mach-exynos4/Kconfig
> > > @@ -173,6 +173,9 @@ config MACH_ARMLEX4210
> > > ?config MACH_UNIVERSAL_C210
> > > ? ? ? ?bool "Mobile UNIVERSAL_C210 Board"
> > > ? ? ? ?select CPU_EXYNOS4210
> > > + ? ? ? select S5P_HRT
> > > + ? ? ? select CLKSRC_MMIO
> > > + ? ? ? select HAVE_SCHED_CLOCK
> > > ? ? ? ?select S5P_GPIO_INT
> > > ? ? ? ?select S5P_DEV_FIMC0
> > > ? ? ? ?select S5P_DEV_FIMC1
> > > diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c
b/arch/arm/mach-
> > exynos4/mach-universal_c210.c
> > > index 0e280d1..ca9e7b7 100644
> > > --- a/arch/arm/mach-exynos4/mach-universal_c210.c
> > > +++ b/arch/arm/mach-exynos4/mach-universal_c210.c
> > > @@ -34,6 +34,7 @@
> > > ?#include <plat/mfc.h>
> > > ?#include <plat/sdhci.h>
> > > ?#include <plat/pd.h>
> > > +#include <plat/s5p-time.h>
> > >
> > > ?#include <mach/map.h>
> > >
> > > @@ -730,6 +731,7 @@ static void __init universal_map_io(void)
> > > ? ? ? ?s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> > > ? ? ? ?s3c24xx_init_clocks(24000000);
> > > ? ? ? ?s3c24xx_init_uarts(universal_uartcfgs,
ARRAY_SIZE(universal_uartcfgs));
> > > + ? ? ? s5p_set_timer_source(S5P_PWM2, S5P_PWM4);
> > > ?}
> > >
> > > ?static void __init universal_reserve(void)
> > > @@ -766,6 +768,6 @@ MACHINE_START(UNIVERSAL_C210,
> > "UNIVERSAL_C210")
> > > ? ? ? ?.init_irq ? ? ? = exynos4_init_irq,
> > > ? ? ? ?.map_io ? ? ? ? = universal_map_io,
> > > ? ? ? ?.init_machine ? = universal_machine_init,
> > > - ? ? ? .timer ? ? ? ? ?= &exynos4_timer,
> > > + ? ? ? .timer ? ? ? ? ?= &s5p_timer,
> > > ? ? ? ?.reserve ? ? ? ?= &universal_reserve,
> > > ?MACHINE_END
> > > --
> > > 1.7.1.569.g6f426
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe
linux-samsung-soc" in
> > > the body of a message to majordomo at vger.kernel.org
> > > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> > >
^ permalink raw reply
* [PATCH] arm: exynos4: fix incorrect pad configuration for keypad row lines
From: Kukjin Kim @ 2011-09-15 5:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315129244-26489-1-git-send-email-thomas.abraham@linaro.org>
Thomas Abraham wrote:
>
> The keypad controller requires a external pull-up for all the keypad
> row lines. Fix the incorrect pad configuration for keypad controller
> row lines by enabling the pad pull-up for the all row lines of the
> keypad controller.
>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> SMDKV310 board does not have pull-up resistors populated for the keypad
> row lines (unlike the smdk boards for the previous Samsung SoC's). So
> the pad pull-up for all keypad row lines should be enabled for
> smdkv310 board.
>
> The default requirement for the keypad controller is to enable the
> pull-up for all the keypad row lines. If a exynos4 based board has
> on-board pull-up's populated for keypad row lines, this patch would
> cause no harm. And in such cases, if internal pad pull-up is to be
> disabled (to reduce some power consumption), an alternative gpio
> configuration function can be supplied that does not enable the
> internal pad pull-up.
> ---
> arch/arm/mach-exynos4/setup-keypad.c | 11 ++++++-----
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/setup-keypad.c b/arch/arm/mach-
> exynos4/setup-keypad.c
> index 1ee0ebf..7862bfb 100644
> --- a/arch/arm/mach-exynos4/setup-keypad.c
> +++ b/arch/arm/mach-exynos4/setup-keypad.c
> @@ -19,15 +19,16 @@ void samsung_keypad_cfg_gpio(unsigned int rows,
> unsigned int cols)
>
> if (rows > 8) {
> /* Set all the necessary GPX2 pins: KP_ROW[0~7] */
> - s3c_gpio_cfgrange_nopull(EXYNOS4_GPX2(0), 8,
> S3C_GPIO_SFN(3));
> + s3c_gpio_cfgall_range(EXYNOS4_GPX2(0), 8,
> S3C_GPIO_SFN(3),
> + S3C_GPIO_PULL_UP);
>
> /* Set all the necessary GPX3 pins: KP_ROW[8~] */
> - s3c_gpio_cfgrange_nopull(EXYNOS4_GPX3(0), (rows - 8),
> - S3C_GPIO_SFN(3));
> + s3c_gpio_cfgall_range(EXYNOS4_GPX3(0), (rows - 8),
> + S3C_GPIO_SFN(3),
> S3C_GPIO_PULL_UP);
> } else {
> /* Set all the necessary GPX2 pins: KP_ROW[x] */
> - s3c_gpio_cfgrange_nopull(EXYNOS4_GPX2(0), rows,
> - S3C_GPIO_SFN(3));
> + s3c_gpio_cfgall_range(EXYNOS4_GPX2(0), rows,
> S3C_GPIO_SFN(3),
> + S3C_GPIO_PULL_UP);
> }
>
> /* Set all the necessary GPX1 pins to special-function 3: KP_COL[x]
*/
> --
> 1.6.6.rc2
Oops, you're right, applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver
From: DebBarma, Tarun Kanti @ 2011-09-15 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914214533.GA30941@atomide.com>
On Thu, Sep 15, 2011 at 3:15 AM, Tony Lindgren <tony@atomide.com> wrote:
> Hi,
>
> * Tarun Kanti DebBarma <tarun.kanti@ti.com> [110908 13:36]:
>> Register timer devices by going through hwmod database using
>> hwmod API. The driver probes each of the registered devices.
>> Functionality which are already performed by hwmod framework
>> are removed from timer code. New set of timers present on
>> OMAP4 are now supported.
>
> Adding the support for the different offsets on some omap4
> timers should be a separate patch.
>
> Also, as we don't need the support for different register offsets
> for the first two omap4 timers, please rather implement support
> for the new timers and the timeouts directly in plat-omap/dmtimer.c.
>
> That way we can still keep the minimal timer support simple
> for clocksource and clockevent. Of course this means that we'll
> be only supporting the first two timers as system timers on
> omap4, but that's fine.
Ok, I can make the change!
But, do we have to keep OMAP5 in mind right now where even timers[1,2]
require addition of offsets?
--
Tarun
[...]
^ permalink raw reply
* gpio_ensure_requested error on mx31pdk boot
From: Fabio Estevam @ 2011-09-15 3:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On a MX31PDK running 3.1-rc3 from Pengutronix's imx-features branch I
get the following:
Registering mxc_nand as whole device
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:101 gpio_ensure_requested+0x4c/0xf4()
autorequest GPIO-0
Modules linked in:
[<c0014410>] (unwind_backtrace+0x0/0xf4) from [<c0025754>] (warn_slowpath_common
+0x4c/0x64)
[<c0025754>] (warn_slowpath_common+0x4c/0x64) from [<c0025800>] (warn_slowpath_f
mt+0x30/0x40)
[<c0025800>] (warn_slowpath_fmt+0x30/0x40) from [<c0198688>] (gpio_ensure_reques
ted+0x4c/0xf4)
[<c0198688>] (gpio_ensure_requested+0x4c/0xf4) from [<c01988c8>] (gpio_direction
_output+0xa0/0x138)
[<c01988c8>] (gpio_direction_output+0xa0/0x138) from [<c01ed198>] (spi_imx_setup
+0x38/0x4c)
[<c01ed198>] (spi_imx_setup+0x38/0x4c) from [<c01eb5d0>] (spi_setup+0x38/0x50)
[<c01eb5d0>] (spi_setup+0x38/0x50) from [<c01eb85c>] (spi_add_device+0x94/0x124)
[<c01eb85c>] (spi_add_device+0x94/0x124) from [<c01eb960>] (spi_new_device+0x74/
0xac)
[<c01eb960>] (spi_new_device+0x74/0xac) from [<c01eb9b8>] (spi_match_master_to_b
oardinfo+0x20/0x40)
[<c01eb9b8>] (spi_match_master_to_boardinfo+0x20/0x40) from [<c01eba88>] (spi_re
gister_master+0xb0/0x104)
[<c01eba88>] (spi_register_master+0xb0/0x104) from [<c01ec0b4>] (spi_bitbang_sta
rt+0x104/0x17c)
[<c01ec0b4>] (spi_bitbang_start+0x104/0x17c) from [<c02c2c4c>] (spi_imx_probe+0x
2fc/0x404)
[<c02c2c4c>] (spi_imx_probe+0x2fc/0x404) from [<c01c2498>] (platform_drv_probe+0
x18/0x1c)
[<c01c2498>] (platform_drv_probe+0x18/0x1c) from [<c01c1058>] (driver_probe_devi
ce+0x78/0x174)
[<c01c1058>] (driver_probe_device+0x78/0x174) from [<c01c11e0>] (__driver_attach
+0x8c/0x90)
[<c01c11e0>] (__driver_attach+0x8c/0x90) from [<c01c0860>] (bus_for_each_dev+0x6
0/0x8c)
[<c01c0860>] (bus_for_each_dev+0x60/0x8c) from [<c01c0088>] (bus_add_driver+0xa0
/0x288)
[<c01c0088>] (bus_add_driver+0xa0/0x288) from [<c01c179c>] (driver_register+0x78
/0x18c)
[<c01c179c>] (driver_register+0x78/0x18c) from [<c0008490>] (do_one_initcall+0x3
4/0x178)
[<c0008490>] (do_one_initcall+0x34/0x178) from [<c03a5204>] (kernel_init+0x74/0x
118)
[<c03a5204>] (kernel_init+0x74/0x118) from [<c000f65c>] (kernel_thread_exit+0x0/
0x8)
---[ end trace 759f924b30fd5a44 ]---
I have not started debugging yet, but just wondering if anyone else
has seen this.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 18/25] OMAP4: suspend: Add MPUSS power domain RETENTION support
From: Santosh @ 2011-09-15 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ty8e8xam.fsf@ti.com>
On Thursday 15 September 2011 05:57 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> This patch adds MPUSS(MPU Sub System) power domain
>> CSWR(Close Switch Retention) support to system wide suspend.
>> For both MPUSS RET support, CPUs are programmed to OFF state.
>
> is 'both' in the wrong place in this sentence? I think you meant:
>
You are right.
> For MPUSS retention support, both CPUs are programmed to OFF state.
>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman <khilman@ti.com>
>> ---
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 16 +++++++
>> arch/arm/mach-omap2/pm44xx.c | 71 +++++++++++++++++++++++++++--
>> 2 files changed, 82 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index 9d68abf..9f632fe 100644
>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> @@ -66,6 +66,7 @@ struct omap4_cpu_pm_info {
>> };
>>
>> static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
>> +static struct powerdomain *mpuss_pd;
>>
>> /*
>> * Program the wakeup routine address for the CPU0 and CPU1
>> @@ -140,6 +141,13 @@ static void scu_pwrst_prepare(unsigned int cpu_id, unsigned int cpu_state)
>> * of OMAP4 MPUSS subsystem
>> * @cpu : CPU ID
>> * @power_state: Low power state.
>> + *
>> + * MPUSS states for the context save:
>> + * save_state =
>> + * 0 - Nothing lost and no need to save: MPUSS INACTIVE
>> + * 1 - CPUx L1 and logic lost: MPUSS CSWR
>> + * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
>> + * 3 - CPUx L1 and logic lost + GIC + L2 lost: DEVICE OFF
>> */
>> int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>> {
>> @@ -169,6 +177,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>> return -ENXIO;
>> }
>>
>> + pwrdm_clear_all_prev_pwrst(mpuss_pd);
>> clear_cpu_prev_pwrst(cpu);
>> set_cpu_next_pwrst(cpu, power_state);
>> set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
>> @@ -270,6 +279,13 @@ int __init omap4_mpuss_init(void)
>> /* Initialise CPU1 power domain state to ON */
>> pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
>>
>> + mpuss_pd = pwrdm_lookup("mpu_pwrdm");
>> + if (!mpuss_pd) {
>> + pr_err("Failed to lookup MPUSS power domain\n");
>> + return -ENODEV;
>> + }
>> + pwrdm_clear_all_prev_pwrst(mpuss_pd);
>> +
>> /* Save device type on scratchpad for low level code to use */
>> if (omap_type() != OMAP2_DEVICE_TYPE_GP)
>> __raw_writel(1, sar_base + OMAP_TYPE_OFFSET);
>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
>> index 4f39de5..63e8f9b 100644
>> --- a/arch/arm/mach-omap2/pm44xx.c
>> +++ b/arch/arm/mach-omap2/pm44xx.c
>> @@ -1,8 +1,9 @@
>> /*
>> * OMAP4 Power Management Routines
>> *
>> - * Copyright (C) 2010 Texas Instruments, Inc.
>> + * Copyright (C) 2010-2011 Texas Instruments, Inc.
>> * Rajendra Nayak <rnayak@ti.com>
>> + * Santosh Shilimkar <santosh.shilimkar@ti.com>
>> *
>> * 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
>> @@ -16,9 +17,11 @@
>> #include <linux/err.h>
>> #include <linux/slab.h>
>>
>> +#include <mach/omap4-common.h>
>> +
>> #include "powerdomain.h"
>> #include "clockdomain.h"
>> -#include <mach/omap4-common.h>
>> +#include "pm.h"
>>
>> struct power_state {
>> struct powerdomain *pwrdm;
>> @@ -34,7 +37,48 @@ static LIST_HEAD(pwrst_list);
>> #ifdef CONFIG_SUSPEND
>> static int omap4_pm_suspend(void)
>> {
>> - omap_do_wfi();
>> + struct power_state *pwrst;
>> + int state, ret = 0;
>> + u32 cpu_id = smp_processor_id();
>> +
>> + /* Save current powerdomain state */
>> + list_for_each_entry(pwrst, &pwrst_list, node) {
>> + pwrst->saved_state = pwrdm_read_next_pwrst(pwrst->pwrdm);
>> + }
>> +
>> + /* Set targeted power domain states by suspend */
>> + list_for_each_entry(pwrst, &pwrst_list, node) {
>> + omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
>> + }
>> +
>> + /*
>> + * For MPUSS to hit power domain retention(CSWR or OSWR),
>> + * CPU0 and CPU1 power domain needs to be in OFF or DORMANT
>
> s/domain needs/domains need/
>
ok
>> + * state. For MPUSS to reach off-mode. CPU0 and CPU1 power domain
>> + * should be in off state.
>
> nit: please be consistent with naming of power states (e.g. OFF vs. off)
>
ok.
>> + * Only master CPU followes suspend path. All other CPUs follow
>> + * cpu-hotplug path in system wide suspend. On OMAP4, CPU power
>> + * domain CSWR is not supported by hardware.
>
> I think this sentence belongs a little earlier. E.g. something like
> ...CPU0 and CPU1 power domains need to be in OFF or DORMANT state, since
> CPU power domain CSWR is not supported by hardware.
>
Looks better.
>> + * More details can be found in OMAP4430 TRM section 4.3.4.2.
>> + */
>> + omap4_enter_lowpower(cpu_id, PWRDM_POWER_OFF);
>> +
>> + /* Restore next powerdomain state */
>> + list_for_each_entry(pwrst, &pwrst_list, node) {
>> + state = pwrdm_read_prev_pwrst(pwrst->pwrdm);
>> + if (state > pwrst->next_state) {
>> + pr_info("Powerdomain (%s) didn't enter "
>> + "target state %d\n",
>> + pwrst->pwrdm->name, pwrst->next_state);
>> + ret = -1;
>> + }0001
>> + omap_set_pwrdm_state(pwrst->pwrdm, pwrst->saved_state);
>> + }
>> + if (ret)
>> + pr_err("Could not enter target state in pm_suspend\n");
>
> Without more details, this isn't terribly useful. I'd suggest just
> making the per-state one above pr_err().
>
You mean pr_crit ?
>> + else
>> + pr_err("Successfully put all powerdomains to target state\n");
>
> and this one pr_info.
>
>> return 0;
>> }
>>
>> @@ -97,14 +141,31 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
>> if (!pwrdm->pwrsts)
>> return 0;
>>
>> + /*
>> + * Skip CPU0 and CPU1 power domains. CPU1 is programmed
>> + * through hotplug path and CPU0 explicitly programmed
>> + * further down in the code path
>> + */
>> + if ((!strcmp(pwrdm->name, "cpu0_pwrdm")) ||
>> + (!strcmp(pwrdm->name, "cpu1_pwrdm")))
>
> or just one compare using strncmp(pwrdm->name, "cpu", 3)
>
Let me check this.
Regards
Santosh
^ permalink raw reply
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
From: Santosh @ 2011-09-15 2:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914190433.GP24252@atomide.com>
On Thursday 15 September 2011 12:34 AM, Tony Lindgren wrote:
> * Santosh <santosh.shilimkar@ti.com> [110914 09:49]:
>> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
>>> * Santosh<santosh.shilimkar@ti.com> [110914 09:40]:
>>>> On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
>>>>> * Santosh<santosh.shilimkar@ti.com> [110914 09:16]:
>>>>>
>>>>> Thanks for the clarification. It seems to me the spec is most likely
>>>>> wrong as we've had the GIC working for over two years now without
>>>>> doing anything with the wakeup gen registers :)
>>>>>
>>>> It's working because CPU clockdomain are never put under HW
>>>> supervised mode and they are kept in force wakeup. Clock-domain
>>>> never idles on mainline code. PM series will put the clock-domains
>>>> under HW supervison as needed to achieve any low power states and
>>>> then all sorts of corner cases will come out.
>>>
>>> But again the wakeup gen triggers only do something when hitting
>>> idle. There should be no use for them during runtime, right?
>>>
>> You missed my point in the description. Clockdomain inactive
>> doesn't depend on idle or WFI execution. Under HW supervison
>> CPU clock domain can get into inactive when CPU is stalled and
>> waiting for a read response from slow interconnect.
>
> Ah OK. If it's needed during runtime too then that explains why
> the registers need to be kept in sync.
>
>> One thing for sure. Designers has chosen a wrong name to this
>> IP. Wakeugen apears like needed only for low power wakeup which
>> not seems to be entirely correct as per specs
>
> Yes it's not obvious reading the TRM either. Maybe add some
> comment about that to the patch?
>
You are right. Documentation isn't clear about this. Will
add the above point in change log.
btw, thanks for the good discussion on this topic.
Regards
Santosh
^ permalink raw reply
* Tasks schedule/migration issue with CPU hotplug?
From: TAO HU @ 2011-09-15 2:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110908073943.GC11124@zhy>
Hi, Yong
You're right. We figured out something is wrong (is negative) with
vruntime of certain processes.
Below link describes the same issue we observed.
http://lkml.indiana.edu/hypermail/linux/kernel/1101.2/00333.html
And the commite indicated by you is exactly the fix.
Appreciate it!.
On Thu, Sep 8, 2011 at 3:39 PM, Yong Zhang <yong.zhang0@gmail.com> wrote:
> On Thu, Sep 08, 2011 at 03:28:01PM +0800, Yong Zhang wrote:
>> On Thu, Sep 08, 2011 at 02:47:08PM +0800, TAO HU wrote:
>> > Resend with linux-kernel mail list included.
>>
>> Hmm, could you give a try with commit da7a735e?
>>
>> Thanks,
>> Yong
>>
>> ---
>> commit da7a735e51f9622eb3e1672594d4a41da01d7e4f
>> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
>> Date: ? Mon Jan 17 17:03:27 2011 +0100
>>
>> ? ? sched: Fix switch_from_fair()
>>
>> ? ? When a task is taken out of the fair class we must ensure the vruntime
>> ? ? is properly normalized because when we put it back in it will assume
>> ? ? to be normalized.
>>
>> ? ? The case that goes wrong is when changing away from the fair class
>> ? ? while sleeping. Sleeping tasks have non-normalized vruntime in order
>> ? ? to make sleeper-fairness work. So treat the switch away from fair as a
>> ? ? wakeup and preserve the relative vruntime.
>>
>> ? ? Also update sysrq-n to call the ->switch_{to,from} methods.
>>
>> ? ? Reported-by: Onkalo Samu <samu.p.onkalo@nokia.com>
>> ? ? Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>> ? ? LKML-Reference: <new-submission>
>> ? ? Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>
>> >
>> > On Wed, Sep 7, 2011 at 10:22 PM, TAO HU <tghk48@motorola.com> wrote:
>> > > <4>[ 6950.136230] cfs_rq[0]:/
>> > > <4>[ 6950.136230] ? .exec_clock ? ? ? ? ? ? ? ? ? ?: 6520265.283900
>> > > <4>[ 6950.136260] ? .MIN_vruntime ? ? ? ? ? ? ? ? ?: 2223057.428522
>> > > <4>[ 6950.136260] ? .min_vruntime ? ? ? ? ? ? ? ? ?: 2223057.428522
>> > > <4>[ 6950.136291] ? .max_vruntime ? ? ? ? ? ? ? ? ?: 2223114.709956
>> > > <4>[ 6950.136291] ? .spread ? ? ? ? ? ? ? ? ? ? ? ?: 57.281434
>> > > <4>[ 6950.136291] ? .spread0 ? ? ? ? ? ? ? ? ? ? ? : 0.000000
>> > > <4>[ 6950.136322] ? .nr_running ? ? ? ? ? ? ? ? ? ?: 212
>> > > <4>[ 6950.136322] ? .load ? ? ? ? ? ? ? ? ? ? ? ? ?: 217650
>> > > <4>[ 6950.136352] ? .nr_spread_over ? ? ? ? ? ? ? ?: 125034
>> > > <4>[ 6950.136352] ? .shares ? ? ? ? ? ? ? ? ? ? ? ?: 0
>> > > <4>[ 6950.136352]
>> > > <4>[ 6950.136566] runnable tasks:
>> > > <4>[ 6950.136566] ? ? ? ? ? ? task ? PID ? ? ? ? tree-key ?switches
>> > > prio ? ? exec-runtime ? ? ? ? sum-exec ? ? ? ?sum-sleep
>> > > <4>[ 6950.136596]
>> > > ----------------------------------------------------------------------------------------------------------
>> > > <4>[ 6950.136627] ? ? ?omap2_mcspi ? ?21 ? 2223062.886210 ?29451523
>
> The tree-key(2223062.886210) almost equals to cfs_rq.min_vruntime,
> so maybe you hit the bug which is cured by the mentioned commit.
>
> Thanks,
> Yong
>
--
Best Regards
Hu Tao
^ permalink raw reply
* [PATCH V3 3/6] MTD : add the database for the NANDs
From: Huang Shijie @ 2011-09-15 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN8TOE9-iEPyWXLsxddeofazgrCWDWKgrx6eBkr7vdKErfgeCA@mail.gmail.com>
Hi Brian:
> Hi,
>
> I see nothing has happened with this thread recently. It doesn't
> deserve to die though.
>
> On Thu, Mar 31, 2011 at 10:17 AM, Huang Shijie<shijie8@gmail.com> wrote:
>> 2011/3/31 Artem Bityutskiy<dedekind1@gmail.com>:
>>>>> If you have new chips to support in the future, you should add them in
>>>>> drivers/mtd/nand/nand_ids.c and not keep this file.
>>>>>
>>>> The data structure nand_flash_dev{} does not contain enough information.
>>>> So I want to the nand_device_info{} to replace it in future.
>>> Just add this information, if it is of generic nature (like SLC/MLC
>>> flag, required ECC strength, etc).
> Are SLC/MLC and ECC strength necessary to track? I don't see a good
> benefit to cost ratio of trying to detect ECC strength especially,
> since the levels specified in data sheets vary without much pattern
> and nobody provides a way for decoding this from ID; do you really
> want to have to make separate chip entries for every single chip that
> comes around?
I do not need the SLC/MCL info. But i do need the ECC strength for the BCH.
Currently i compute it myself based on the ECC chunk size to be 512 bytes.
It's ok now.
But the ONFI nand MAYBE has its own requirements, such as some ONFI nand
requires '24-bit ECC per 1080 bytes of data'(see
MT29F64G08CBAAA,MT29F128G08CEAAA).
In this case, setting the ECC chunk size to 512 bytes maybe is not
proper. It's better to
set the ECC chunk size to 1k, and set ECC strength to 24bit.
So, add the ECC strength to nand is worthful ( at least, it's useful for
ONFI nand) .
>>>>> I still do not understand why this would be needed, is it because the generic
>>>>> code does not provide enough informations for your driver?
>>>>>
>>>> yes.
>>>>
>>>> IMHO, the generic code is somehow trapped in a wrong way. :(
> I may agree, but can you be more specific on the trap?
>
I meant the parsing id code is not good.
Maybe i am wrong.
>>>> Paring the id bytes is not sufficient to get all the information you
>>>> need which is faced by me.
> What's an alternative to "paring the id bytes"?
>
I meant the the code can not get sufficient info for ONFI nand.
But the current code can parse out the info for ONFI nand now.
though it does not parse out all the info.
>>>> What's more, I think the paring code is ugly, see the nand_get_flash_type().
>>> You are welcome to fix this. There is _a lot_ of ugly code in MTD
>>> because no one loves it. Give it some love :-)
> While I agree that a lot of this is ugly, it is mostly a matter of
> necessity. NAND manufacturers do not have a standard (ONFI doesn't
> really count, since there's basically 1 manufacturer using it), and so
> the most "generic" code is to have different code paths for different
> manufacturers (often with exceptions to each rule, since even a single
> manufacturer changes its standards arbitrarily). Then you find
> manufacturers like Toshiba that recently don't have any (published)
> pattern at all for detecting OOB size generically.
>
> Thus, it seems to me like we will need some form of the approach
> provided by Huang. As I've found, there are some things that just
> can't be decoded from the ID these days, so our ID table will need to
> be able to track:
> * full ID string (not just the 2nd byte "Device ID")
The same idea as mine. :) I also thought it's better to store all the
ID bytes.
> * relevant bad block scanning options
>
> FWIW, we already implement an exception table in our own driver that
> includes the above 2 items, for chips that can't be handled with the
> table/detection structure as-is. We don't particularly need SLC/MLC
> but I don't object to recording it if we can determine it reliably,
> and while ECC level could be useful, it is difficult to discover
> generically, as I mentioned above.
>
at least the ECC strength is needed.
>>>> Why not create a new database which contains all the necessary
>>>> information for a nand, and can be easy
>>>> find by the id bytes as the keyword?
>>> You can create this database by extending/improving/cleaning up the
>>> existing code base with a nice series of patches.
>>>
>> ok. I will try to fix the generic code before my driver is submitted.
> What happened to this statement? I see that your driver was submitted,
> but no efforts were made for chip detection cleanup. Were you
> satisfied with the current detection?
I am not satisfied with the current code.
I wish I could add the code to parsing out the ECC strength of ONFI,
and something else.
But I have no time to do this. :(
feel bad.
> While we're on the subject, I'll direct your attention to this NAND
> data table that I've worked on. It should provide a decent summary of
> most of the data sheets I have sorted through. It should also show you
> that certain things are going to be very hard to detect (e.g., ECC
only the ONFI nand's ECC strength is useful now.
You can ignore the normal NANDs, i can compute it myself.
> level). It should also show that while some chips are not supported by
> standard code (e.g., weird bad block scanning features that haven't
> been supported, non-standard OOB sizes with no given pattern in the
> datasheets), the vast majority of the chips I've come across should be
> detected properly:
>
> http://linux-mtd.infradead.org/nand-data/nanddata.html
>
very good!
Huang Shijie
> And of course, please contribute to
> git://git.infradead.org/mtd-www.git if you have additions or edits for
> the table. It's not perfect, but it can help for sorting through
> different chips.
>
> Brian
>
^ permalink raw reply
* [PATCH 3/3] ARM: EXYNOS4: Support suspend/resume for EXYNOS4212
From: Jongpill Lee @ 2011-09-15 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316052239-8361-1-git-send-email-boyko.lee@samsung.com>
This patch adds suspend and resume function for EXYNOS4212.
Signed-off-by: Jongpill Lee <boyko.lee@samsung.com>
---
arch/arm/mach-exynos4/pm.c | 7 +++
arch/arm/mach-exynos4/pmu.c | 121 +++++++++++++++++++++++++++++++++++++++++-
2 files changed, 125 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos4/pm.c b/arch/arm/mach-exynos4/pm.c
index 62e4f43..509a435 100644
--- a/arch/arm/mach-exynos4/pm.c
+++ b/arch/arm/mach-exynos4/pm.c
@@ -339,6 +339,13 @@ static int exynos4_pm_suspend(void)
tmp &= ~S5P_CENTRAL_LOWPWR_CFG;
__raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+ if (soc_is_exynos4212()) {
+ tmp = __raw_readl(S5P_CENTRAL_SEQ_OPTION);
+ tmp &= ~(S5P_USE_STANDBYWFI_ISP_ARM |
+ S5P_USE_STANDBYWFE_ISP_ARM);
+ __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
+ }
+
/* Save Power control register */
asm ("mrc p15, 0, %0, c15, c0, 0"
: "=r" (tmp) : : "cc");
diff --git a/arch/arm/mach-exynos4/pmu.c b/arch/arm/mach-exynos4/pmu.c
index 0210231..a849b23 100644
--- a/arch/arm/mach-exynos4/pmu.c
+++ b/arch/arm/mach-exynos4/pmu.c
@@ -95,6 +95,113 @@ static struct exynos4_pmu_conf exynos4210_pmu_config[] = {
{ S5P_GPS_ALIVE_LOWPWR, { 0x7, 0x0, 0x0 } },
};
+static struct exynos4_pmu_conf exynos4212_pmu_config[] = {
+ { S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
+ { S5P_DIS_IRQ_CORE0, { 0x0, 0x0, 0x0 } },
+ { S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
+ { S5P_ARM_CORE1_LOWPWR, { 0x0, 0x0, 0x2 } },
+ { S5P_DIS_IRQ_CORE1, { 0x0, 0x0, 0x0 } },
+ { S5P_DIS_IRQ_CENTRAL1, { 0x0, 0x0, 0x0 } },
+ { S5P_ISP_ARM_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_DIS_IRQ_ISP_ARM_LOCAL_LOWPWR, { 0x0, 0x0, 0x0 } },
+ { S5P_DIS_IRQ_ISP_ARM_CENTRAL_LOWPWR, { 0x0, 0x0, 0x0 } },
+ { S5P_ARM_COMMON_LOWPWR, { 0x0, 0x0, 0x2 } },
+ { S5P_L2_0_LOWPWR, { 0x0, 0x0, 0x3 } },
+ /* XXX_OPTION register should be set other field */
+ { S5P_ARM_L2_0_OPTION, { 0x10, 0x10, 0x0 } },
+ { S5P_L2_1_LOWPWR, { 0x0, 0x0, 0x3 } },
+ { S5P_ARM_L2_1_OPTION, { 0x10, 0x10, 0x0 } },
+ { S5P_CMU_ACLKSTOP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_SCLKSTOP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_DRAM_FREQ_DOWN_LOWPWR, { 0x1, 0x1, 0x1 } },
+ { S5P_DDRPHY_DLLOFF_LOWPWR, { 0x1, 0x1, 0x1 } },
+ { S5P_LPDDR_PHY_DLL_LOCK_LOWPWR, { 0x1, 0x1, 0x1 } },
+ { S5P_CMU_ACLKSTOP_COREBLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_SCLKSTOP_COREBLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_COREBLK_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_APLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_MPLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_VPLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_EPLL_SYSCLK_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_MPLLUSER_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_CLKSTOP_GPS_ALIVE_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_GPSALIVE_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_CLKSTOP_CAM_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_CLKSTOP_TV_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_CLKSTOP_MFC_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_CLKSTOP_G3D_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_CLKSTOP_LCD0_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_CLKSTOP_ISP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_CLKSTOP_MAUDIO_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_CLKSTOP_GPS_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_CAM_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_TV_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_MFC_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_G3D_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_LCD0_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_ISP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_MAUDIO_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_GPS_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_TOP_BUS_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_TOP_RETENTION_LOWPWR, { 0x1, 0x0, 0x1 } },
+ { S5P_TOP_PWR_LOWPWR, { 0x3, 0x0, 0x3 } },
+ { S5P_TOP_BUS_COREBLK_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_TOP_RETENTION_COREBLK_LOWPWR, { 0x1, 0x0, 0x1 } },
+ { S5P_TOP_PWR_COREBLK_LOWPWR, { 0x3, 0x0, 0x3 } },
+ { S5P_LOGIC_RESET_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_OSCCLK_GATE_LOWPWR, { 0x1, 0x0, 0x1 } },
+ { S5P_LOGIC_RESET_COREBLK_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_OSCCLK_GATE_COREBLK_LOWPWR, { 0x1, 0x0, 0x1 } },
+ { S5P_ONENAND_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_ONENAND_MEM_OPTION, { 0x10, 0x10, 0x0 } },
+ { S5P_HSI_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_HSI_MEM_OPTION, { 0x10, 0x10, 0x0 } },
+ { S5P_G2D_ACP_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_G2D_ACP_MEM_OPTION, { 0x10, 0x10, 0x0 } },
+ { S5P_USBOTG_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_USBOTG_MEM_OPTION, { 0x10, 0x10, 0x0 } },
+ { S5P_HSMMC_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_HSMMC_MEM_OPTION, { 0x10, 0x10, 0x0 } },
+ { S5P_CSSYS_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_CSSYS_MEM_OPTION, { 0x10, 0x10, 0x0 } },
+ { S5P_SECSS_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_SECSS_MEM_OPTION, { 0x10, 0x10, 0x0 } },
+ { S5P_ROTATOR_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_ROTATOR_MEM_OPTION, { 0x10, 0x10, 0x0 } },
+ { S5P_PAD_RETENTION_DRAM_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_MAUDIO_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_PAD_RETENTION_GPIO_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_UART_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_MMCA_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_MMCB_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_EBIA_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_EBIB_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_GPIO_COREBLK_LOWPWR,{ 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_ISOLATION_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_ISOLATION_COREBLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_ALV_SEL_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_XUSBXTI_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_XXTI_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_EXT_REGULATOR_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_GPIO_MODE_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_GPIO_MODE_COREBLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_GPIO_MODE_MAUDIO_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_TOP_ASB_RESET_LOWPWR, { 0x1, 0x1, 0x1 } },
+ { S5P_TOP_ASB_ISOLATION_LOWPWR, { 0x1, 0x0, 0x1 } },
+ { S5P_CAM_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_TV_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_MFC_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_G3D_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_LCD0_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_ISP_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_MAUDIO_LOWPWR, { 0x7, 0x7, 0x0 } },
+ { S5P_GPS_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_GPS_ALIVE_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_CMU_SYSCLK_ISP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_SYSCLK_GPS_LOWPWR, { 0x1, 0x0, 0x0 } },
+};
+
void exynos4_sys_powerdown_conf(enum sys_powerdown mode)
{
unsigned int count = exynos4_pmu_entry_cnt;
@@ -106,9 +213,17 @@ void exynos4_sys_powerdown_conf(enum sys_powerdown mode)
static int __init exynos4_pmu_init(void)
{
- exynos4_pmu_config = exynos4210_pmu_config;
- exynos4_pmu_entry_cnt = ARRAY_SIZE(exynos4210_pmu_config);
- printk(KERN_INFO "EXYNOS4210 PMU Initialize\n");
+ if (soc_is_exynos4210()) {
+ exynos4_pmu_config = exynos4210_pmu_config;
+ exynos4_pmu_entry_cnt = ARRAY_SIZE(exynos4210_pmu_config);
+ printk(KERN_INFO "EXYNOS4210 PMU Initialize\n");
+ } else if (soc_is_exynos4212()) {
+ exynos4_pmu_config = exynos4212_pmu_config;
+ exynos4_pmu_entry_cnt = ARRAY_SIZE(exynos4212_pmu_config);
+ printk(KERN_INFO "EXYNOS4212 PMU Initialize\n");
+ } else {
+ printk(KERN_INFO "EXYNOS4: PMU not supported\n");
+ }
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] ARM: EXYNOS4: Add PMU register definition for EXYNOS4212
From: Jongpill Lee @ 2011-09-15 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316052239-8361-1-git-send-email-boyko.lee@samsung.com>
This patch adds PMU register definition for Exynos4212
Signed-off-by: Jongpill Lee <boyko.lee@samsung.com>
---
arch/arm/mach-exynos4/include/mach/regs-pmu.h | 69 +++++++++++++++++++++----
1 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-exynos4/include/mach/regs-pmu.h b/arch/arm/mach-exynos4/include/mach/regs-pmu.h
index 7fa44b9..6fab38e 100644
--- a/arch/arm/mach-exynos4/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos4/include/mach/regs-pmu.h
@@ -25,8 +25,10 @@
#define S5P_USE_STANDBY_WFI0 (1 << 16)
#define S5P_USE_STANDBY_WFI1 (1 << 17)
+#define S5P_USE_STANDBYWFI_ISP_ARM (1 << 18)
#define S5P_USE_STANDBY_WFE0 (1 << 24)
#define S5P_USE_STANDBY_WFE1 (1 << 25)
+#define S5P_USE_STANDBYWFE_ISP_ARM (1 << 26)
#define S5P_SWRESET S5P_PMUREG(0x0400)
@@ -34,15 +36,11 @@
#define S5P_EINT_WAKEUP_MASK S5P_PMUREG(0x0604)
#define S5P_WAKEUP_MASK S5P_PMUREG(0x0608)
-#define S5P_USBHOST_PHY_CONTROL S5P_PMUREG(0x0708)
-#define S5P_USBHOST_PHY_ENABLE (1 << 0)
-
#define S5P_MIPI_DPHY_CONTROL(n) S5P_PMUREG(0x0710 + (n) * 4)
#define S5P_MIPI_DPHY_ENABLE (1 << 0)
#define S5P_MIPI_DPHY_SRESETN (1 << 1)
#define S5P_MIPI_DPHY_MRESETN (1 << 2)
-#define S5P_PMU_SATA_PHY_CONTROL S5P_PMUREG(0x0720)
#define S5P_INFORM0 S5P_PMUREG(0x0800)
#define S5P_INFORM1 S5P_PMUREG(0x0804)
#define S5P_INFORM2 S5P_PMUREG(0x0808)
@@ -75,7 +73,6 @@
#define S5P_CMU_CLKSTOP_MFC_LOWPWR S5P_PMUREG(0x1148)
#define S5P_CMU_CLKSTOP_G3D_LOWPWR S5P_PMUREG(0x114C)
#define S5P_CMU_CLKSTOP_LCD0_LOWPWR S5P_PMUREG(0x1150)
-#define S5P_CMU_CLKSTOP_LCD1_LOWPWR S5P_PMUREG(0x1154)
#define S5P_CMU_CLKSTOP_MAUDIO_LOWPWR S5P_PMUREG(0x1158)
#define S5P_CMU_CLKSTOP_GPS_LOWPWR S5P_PMUREG(0x115C)
#define S5P_CMU_RESET_CAM_LOWPWR S5P_PMUREG(0x1160)
@@ -83,7 +80,6 @@
#define S5P_CMU_RESET_MFC_LOWPWR S5P_PMUREG(0x1168)
#define S5P_CMU_RESET_G3D_LOWPWR S5P_PMUREG(0x116C)
#define S5P_CMU_RESET_LCD0_LOWPWR S5P_PMUREG(0x1170)
-#define S5P_CMU_RESET_LCD1_LOWPWR S5P_PMUREG(0x1174)
#define S5P_CMU_RESET_MAUDIO_LOWPWR S5P_PMUREG(0x1178)
#define S5P_CMU_RESET_GPS_LOWPWR S5P_PMUREG(0x117C)
#define S5P_TOP_BUS_LOWPWR S5P_PMUREG(0x1180)
@@ -91,14 +87,11 @@
#define S5P_TOP_PWR_LOWPWR S5P_PMUREG(0x1188)
#define S5P_LOGIC_RESET_LOWPWR S5P_PMUREG(0x11A0)
#define S5P_ONENAND_MEM_LOWPWR S5P_PMUREG(0x11C0)
-#define S5P_MODIMIF_MEM_LOWPWR S5P_PMUREG(0x11C4)
#define S5P_G2D_ACP_MEM_LOWPWR S5P_PMUREG(0x11C8)
#define S5P_USBOTG_MEM_LOWPWR S5P_PMUREG(0x11CC)
#define S5P_HSMMC_MEM_LOWPWR S5P_PMUREG(0x11D0)
#define S5P_CSSYS_MEM_LOWPWR S5P_PMUREG(0x11D4)
#define S5P_SECSS_MEM_LOWPWR S5P_PMUREG(0x11D8)
-#define S5P_PCIE_MEM_LOWPWR S5P_PMUREG(0x11E0)
-#define S5P_SATA_MEM_LOWPWR S5P_PMUREG(0x11E4)
#define S5P_PAD_RETENTION_DRAM_LOWPWR S5P_PMUREG(0x1200)
#define S5P_PAD_RETENTION_MAUDIO_LOWPWR S5P_PMUREG(0x1204)
#define S5P_PAD_RETENTION_GPIO_LOWPWR S5P_PMUREG(0x1220)
@@ -119,7 +112,6 @@
#define S5P_MFC_LOWPWR S5P_PMUREG(0x1388)
#define S5P_G3D_LOWPWR S5P_PMUREG(0x138C)
#define S5P_LCD0_LOWPWR S5P_PMUREG(0x1390)
-#define S5P_LCD1_LOWPWR S5P_PMUREG(0x1394)
#define S5P_MAUDIO_LOWPWR S5P_PMUREG(0x1398)
#define S5P_GPS_LOWPWR S5P_PMUREG(0x139C)
#define S5P_GPS_ALIVE_LOWPWR S5P_PMUREG(0x13A0)
@@ -155,7 +147,6 @@
#define S5P_PMU_MFC_CONF S5P_PMUREG(0x3C40)
#define S5P_PMU_G3D_CONF S5P_PMUREG(0x3C60)
#define S5P_PMU_LCD0_CONF S5P_PMUREG(0x3C80)
-#define S5P_PMU_LCD1_CONF S5P_PMUREG(0x3CA0)
#define S5P_PMU_GPS_CONF S5P_PMUREG(0x3CE0)
#define S5P_PMU_SATA_PHY_CONTROL_EN 0x1
@@ -164,4 +155,60 @@
#define S5P_CHECK_SLEEP 0x00000BAD
+/* Only for EXYNOS4210 */
+#define S5P_USBHOST_PHY_CONTROL S5P_PMUREG(0x0708)
+#define S5P_USBHOST_PHY_ENABLE (1 << 0)
+
+#define S5P_PMU_SATA_PHY_CONTROL S5P_PMUREG(0x0720)
+
+#define S5P_CMU_CLKSTOP_LCD1_LOWPWR S5P_PMUREG(0x1154)
+#define S5P_CMU_RESET_LCD1_LOWPWR S5P_PMUREG(0x1174)
+#define S5P_MODIMIF_MEM_LOWPWR S5P_PMUREG(0x11C4)
+#define S5P_PCIE_MEM_LOWPWR S5P_PMUREG(0x11E0)
+#define S5P_SATA_MEM_LOWPWR S5P_PMUREG(0x11E4)
+#define S5P_LCD1_LOWPWR S5P_PMUREG(0x1394)
+
+#define S5P_PMU_LCD1_CONF S5P_PMUREG(0x3CA0)
+
+/* Only for EXYNOS4212 */
+#define S5P_ISP_ARM_LOWPWR S5P_PMUREG(0x1050)
+#define S5P_DIS_IRQ_ISP_ARM_LOCAL_LOWPWR S5P_PMUREG(0x1054)
+#define S5P_DIS_IRQ_ISP_ARM_CENTRAL_LOWPWR S5P_PMUREG(0x1058)
+#define S5P_CMU_ACLKSTOP_COREBLK_LOWPWR S5P_PMUREG(0x1110)
+#define S5P_CMU_SCLKSTOP_COREBLK_LOWPWR S5P_PMUREG(0x1114)
+#define S5P_CMU_RESET_COREBLK_LOWPWR S5P_PMUREG(0x111C)
+#define S5P_MPLLUSER_SYSCLK_LOWPWR S5P_PMUREG(0x1130)
+#define S5P_CMU_CLKSTOP_ISP_LOWPWR S5P_PMUREG(0x1154)
+#define S5P_CMU_RESET_ISP_LOWPWR S5P_PMUREG(0x1174)
+#define S5P_TOP_BUS_COREBLK_LOWPWR S5P_PMUREG(0x1190)
+#define S5P_TOP_RETENTION_COREBLK_LOWPWR S5P_PMUREG(0x1194)
+#define S5P_TOP_PWR_COREBLK_LOWPWR S5P_PMUREG(0x1198)
+#define S5P_OSCCLK_GATE_LOWPWR S5P_PMUREG(0x11A4)
+#define S5P_LOGIC_RESET_COREBLK_LOWPWR S5P_PMUREG(0x11B0)
+#define S5P_OSCCLK_GATE_COREBLK_LOWPWR S5P_PMUREG(0x11B4)
+#define S5P_HSI_MEM_LOWPWR S5P_PMUREG(0x11C4)
+#define S5P_ROTATOR_MEM_LOWPWR S5P_PMUREG(0x11DC)
+#define S5P_PAD_RETENTION_GPIO_COREBLK_LOWPWR S5P_PMUREG(0x123C)
+#define S5P_PAD_ISOLATION_COREBLK_LOWPWR S5P_PMUREG(0x1250)
+#define S5P_GPIO_MODE_COREBLK_LOWPWR S5P_PMUREG(0x1320)
+#define S5P_TOP_ASB_RESET_LOWPWR S5P_PMUREG(0x1344)
+#define S5P_TOP_ASB_ISOLATION_LOWPWR S5P_PMUREG(0x1348)
+#define S5P_ISP_LOWPWR S5P_PMUREG(0x1394)
+#define S5P_DRAM_FREQ_DOWN_LOWPWR S5P_PMUREG(0x13B0)
+#define S5P_DDRPHY_DLLOFF_LOWPWR S5P_PMUREG(0x13B4)
+#define S5P_CMU_SYSCLK_ISP_LOWPWR S5P_PMUREG(0x13B8)
+#define S5P_CMU_SYSCLK_GPS_LOWPWR S5P_PMUREG(0x13BC)
+#define S5P_LPDDR_PHY_DLL_LOCK_LOWPWR S5P_PMUREG(0x13C0)
+
+#define S5P_ARM_L2_0_OPTION S5P_PMUREG(0x2608)
+#define S5P_ARM_L2_1_OPTION S5P_PMUREG(0x2628)
+#define S5P_ONENAND_MEM_OPTION S5P_PMUREG(0x2E08)
+#define S5P_HSI_MEM_OPTION S5P_PMUREG(0x2E28)
+#define S5P_G2D_ACP_MEM_OPTION S5P_PMUREG(0x2E48)
+#define S5P_USBOTG_MEM_OPTION S5P_PMUREG(0x2E68)
+#define S5P_HSMMC_MEM_OPTION S5P_PMUREG(0x2E88)
+#define S5P_CSSYS_MEM_OPTION S5P_PMUREG(0x2EA8)
+#define S5P_SECSS_MEM_OPTION S5P_PMUREG(0x2EC8)
+#define S5P_ROTATOR_MEM_OPTION S5P_PMUREG(0x2F48)
+
#endif /* __ASM_ARCH_REGS_PMU_H */
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3] ARM: EXYNOS4: Modify PMU register setting function
From: Jongpill Lee @ 2011-09-15 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316052239-8361-1-git-send-email-boyko.lee@samsung.com>
This patch modifies PMU register setting function to support the other Exynos4 series.
Signed-off-by: Jongpill Lee <boyko.lee@samsung.com>
---
arch/arm/mach-exynos4/include/mach/pmu.h | 5 +
arch/arm/mach-exynos4/include/mach/regs-pmu.h | 1 -
arch/arm/mach-exynos4/pmu.c | 238 +++++++++---------------
3 files changed, 94 insertions(+), 150 deletions(-)
diff --git a/arch/arm/mach-exynos4/include/mach/pmu.h b/arch/arm/mach-exynos4/include/mach/pmu.h
index a952904..430e917 100644
--- a/arch/arm/mach-exynos4/include/mach/pmu.h
+++ b/arch/arm/mach-exynos4/include/mach/pmu.h
@@ -20,6 +20,11 @@ enum sys_powerdown {
NUM_SYS_POWERDOWN,
};
+struct exynos4_pmu_conf {
+ void __iomem *reg;
+ unsigned long val[NUM_SYS_POWERDOWN];
+};
+
extern void exynos4_sys_powerdown_conf(enum sys_powerdown mode);
#endif /* __ASM_ARCH_PMU_H */
diff --git a/arch/arm/mach-exynos4/include/mach/regs-pmu.h b/arch/arm/mach-exynos4/include/mach/regs-pmu.h
index cdf9b47..7fa44b9 100644
--- a/arch/arm/mach-exynos4/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos4/include/mach/regs-pmu.h
@@ -27,7 +27,6 @@
#define S5P_USE_STANDBY_WFI1 (1 << 17)
#define S5P_USE_STANDBY_WFE0 (1 << 24)
#define S5P_USE_STANDBY_WFE1 (1 << 25)
-#define S5P_USE_MASK ((0x3 << 16) | (0x3 << 24))
#define S5P_SWRESET S5P_PMUREG(0x0400)
diff --git a/arch/arm/mach-exynos4/pmu.c b/arch/arm/mach-exynos4/pmu.c
index 7ea9eb2..0210231 100644
--- a/arch/arm/mach-exynos4/pmu.c
+++ b/arch/arm/mach-exynos4/pmu.c
@@ -16,160 +16,100 @@
#include <mach/regs-clock.h>
#include <mach/pmu.h>
-static void __iomem *sys_powerdown_reg[] = {
- S5P_ARM_CORE0_LOWPWR,
- S5P_DIS_IRQ_CORE0,
- S5P_DIS_IRQ_CENTRAL0,
- S5P_ARM_CORE1_LOWPWR,
- S5P_DIS_IRQ_CORE1,
- S5P_DIS_IRQ_CENTRAL1,
- S5P_ARM_COMMON_LOWPWR,
- S5P_L2_0_LOWPWR,
- S5P_L2_1_LOWPWR,
- S5P_CMU_ACLKSTOP_LOWPWR,
- S5P_CMU_SCLKSTOP_LOWPWR,
- S5P_CMU_RESET_LOWPWR,
- S5P_APLL_SYSCLK_LOWPWR,
- S5P_MPLL_SYSCLK_LOWPWR,
- S5P_VPLL_SYSCLK_LOWPWR,
- S5P_EPLL_SYSCLK_LOWPWR,
- S5P_CMU_CLKSTOP_GPS_ALIVE_LOWPWR,
- S5P_CMU_RESET_GPSALIVE_LOWPWR,
- S5P_CMU_CLKSTOP_CAM_LOWPWR,
- S5P_CMU_CLKSTOP_TV_LOWPWR,
- S5P_CMU_CLKSTOP_MFC_LOWPWR,
- S5P_CMU_CLKSTOP_G3D_LOWPWR,
- S5P_CMU_CLKSTOP_LCD0_LOWPWR,
- S5P_CMU_CLKSTOP_LCD1_LOWPWR,
- S5P_CMU_CLKSTOP_MAUDIO_LOWPWR,
- S5P_CMU_CLKSTOP_GPS_LOWPWR,
- S5P_CMU_RESET_CAM_LOWPWR,
- S5P_CMU_RESET_TV_LOWPWR,
- S5P_CMU_RESET_MFC_LOWPWR,
- S5P_CMU_RESET_G3D_LOWPWR,
- S5P_CMU_RESET_LCD0_LOWPWR,
- S5P_CMU_RESET_LCD1_LOWPWR,
- S5P_CMU_RESET_MAUDIO_LOWPWR,
- S5P_CMU_RESET_GPS_LOWPWR,
- S5P_TOP_BUS_LOWPWR,
- S5P_TOP_RETENTION_LOWPWR,
- S5P_TOP_PWR_LOWPWR,
- S5P_LOGIC_RESET_LOWPWR,
- S5P_ONENAND_MEM_LOWPWR,
- S5P_MODIMIF_MEM_LOWPWR,
- S5P_G2D_ACP_MEM_LOWPWR,
- S5P_USBOTG_MEM_LOWPWR,
- S5P_HSMMC_MEM_LOWPWR,
- S5P_CSSYS_MEM_LOWPWR,
- S5P_SECSS_MEM_LOWPWR,
- S5P_PCIE_MEM_LOWPWR,
- S5P_SATA_MEM_LOWPWR,
- S5P_PAD_RETENTION_DRAM_LOWPWR,
- S5P_PAD_RETENTION_MAUDIO_LOWPWR,
- S5P_PAD_RETENTION_GPIO_LOWPWR,
- S5P_PAD_RETENTION_UART_LOWPWR,
- S5P_PAD_RETENTION_MMCA_LOWPWR,
- S5P_PAD_RETENTION_MMCB_LOWPWR,
- S5P_PAD_RETENTION_EBIA_LOWPWR,
- S5P_PAD_RETENTION_EBIB_LOWPWR,
- S5P_PAD_RETENTION_ISOLATION_LOWPWR,
- S5P_PAD_RETENTION_ALV_SEL_LOWPWR,
- S5P_XUSBXTI_LOWPWR,
- S5P_XXTI_LOWPWR,
- S5P_EXT_REGULATOR_LOWPWR,
- S5P_GPIO_MODE_LOWPWR,
- S5P_GPIO_MODE_MAUDIO_LOWPWR,
- S5P_CAM_LOWPWR,
- S5P_TV_LOWPWR,
- S5P_MFC_LOWPWR,
- S5P_G3D_LOWPWR,
- S5P_LCD0_LOWPWR,
- S5P_LCD1_LOWPWR,
- S5P_MAUDIO_LOWPWR,
- S5P_GPS_LOWPWR,
- S5P_GPS_ALIVE_LOWPWR,
-};
+static struct exynos4_pmu_conf *exynos4_pmu_config;
+
+static unsigned int exynos4_pmu_entry_cnt;
-static const unsigned int sys_powerdown_val[][NUM_SYS_POWERDOWN] = {
- /* { AFTR, LPA, SLEEP }*/
- { 0, 0, 2 }, /* ARM_CORE0 */
- { 0, 0, 0 }, /* ARM_DIS_IRQ_CORE0 */
- { 0, 0, 0 }, /* ARM_DIS_IRQ_CENTRAL0 */
- { 0, 0, 2 }, /* ARM_CORE1 */
- { 0, 0, 0 }, /* ARM_DIS_IRQ_CORE1 */
- { 0, 0, 0 }, /* ARM_DIS_IRQ_CENTRAL1 */
- { 0, 0, 2 }, /* ARM_COMMON */
- { 2, 2, 3 }, /* ARM_CPU_L2_0 */
- { 2, 2, 3 }, /* ARM_CPU_L2_1 */
- { 1, 0, 0 }, /* CMU_ACLKSTOP */
- { 1, 0, 0 }, /* CMU_SCLKSTOP */
- { 1, 1, 0 }, /* CMU_RESET */
- { 1, 0, 0 }, /* APLL_SYSCLK */
- { 1, 0, 0 }, /* MPLL_SYSCLK */
- { 1, 0, 0 }, /* VPLL_SYSCLK */
- { 1, 1, 0 }, /* EPLL_SYSCLK */
- { 1, 1, 0 }, /* CMU_CLKSTOP_GPS_ALIVE */
- { 1, 1, 0 }, /* CMU_RESET_GPS_ALIVE */
- { 1, 1, 0 }, /* CMU_CLKSTOP_CAM */
- { 1, 1, 0 }, /* CMU_CLKSTOP_TV */
- { 1, 1, 0 }, /* CMU_CLKSTOP_MFC */
- { 1, 1, 0 }, /* CMU_CLKSTOP_G3D */
- { 1, 1, 0 }, /* CMU_CLKSTOP_LCD0 */
- { 1, 1, 0 }, /* CMU_CLKSTOP_LCD1 */
- { 1, 1, 0 }, /* CMU_CLKSTOP_MAUDIO */
- { 1, 1, 0 }, /* CMU_CLKSTOP_GPS */
- { 1, 1, 0 }, /* CMU_RESET_CAM */
- { 1, 1, 0 }, /* CMU_RESET_TV */
- { 1, 1, 0 }, /* CMU_RESET_MFC */
- { 1, 1, 0 }, /* CMU_RESET_G3D */
- { 1, 1, 0 }, /* CMU_RESET_LCD0 */
- { 1, 1, 0 }, /* CMU_RESET_LCD1 */
- { 1, 1, 0 }, /* CMU_RESET_MAUDIO */
- { 1, 1, 0 }, /* CMU_RESET_GPS */
- { 3, 0, 0 }, /* TOP_BUS */
- { 1, 0, 1 }, /* TOP_RETENTION */
- { 3, 0, 3 }, /* TOP_PWR */
- { 1, 1, 0 }, /* LOGIC_RESET */
- { 3, 0, 0 }, /* ONENAND_MEM */
- { 3, 0, 0 }, /* MODIMIF_MEM */
- { 3, 0, 0 }, /* G2D_ACP_MEM */
- { 3, 0, 0 }, /* USBOTG_MEM */
- { 3, 0, 0 }, /* HSMMC_MEM */
- { 3, 0, 0 }, /* CSSYS_MEM */
- { 3, 0, 0 }, /* SECSS_MEM */
- { 3, 0, 0 }, /* PCIE_MEM */
- { 3, 0, 0 }, /* SATA_MEM */
- { 1, 0, 0 }, /* PAD_RETENTION_DRAM */
- { 1, 1, 0 }, /* PAD_RETENTION_MAUDIO */
- { 1, 0, 0 }, /* PAD_RETENTION_GPIO */
- { 1, 0, 0 }, /* PAD_RETENTION_UART */
- { 1, 0, 0 }, /* PAD_RETENTION_MMCA */
- { 1, 0, 0 }, /* PAD_RETENTION_MMCB */
- { 1, 0, 0 }, /* PAD_RETENTION_EBIA */
- { 1, 0, 0 }, /* PAD_RETENTION_EBIB */
- { 1, 0, 0 }, /* PAD_RETENTION_ISOLATION */
- { 1, 0, 0 }, /* PAD_RETENTION_ALV_SEL */
- { 1, 1, 0 }, /* XUSBXTI */
- { 1, 1, 0 }, /* XXTI */
- { 1, 1, 0 }, /* EXT_REGULATOR */
- { 1, 0, 0 }, /* GPIO_MODE */
- { 1, 1, 0 }, /* GPIO_MODE_MAUDIO */
- { 7, 0, 0 }, /* CAM */
- { 7, 0, 0 }, /* TV */
- { 7, 0, 0 }, /* MFC */
- { 7, 0, 0 }, /* G3D */
- { 7, 0, 0 }, /* LCD0 */
- { 7, 0, 0 }, /* LCD1 */
- { 7, 7, 0 }, /* MAUDIO */
- { 7, 0, 0 }, /* GPS */
- { 7, 0, 0 }, /* GPS_ALIVE */
+static struct exynos4_pmu_conf exynos4210_pmu_config[] = {
+ /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
+ { S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
+ { S5P_DIS_IRQ_CORE0, { 0x0, 0x0, 0x0 } },
+ { S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
+ { S5P_ARM_CORE1_LOWPWR, { 0x0, 0x0, 0x2 } },
+ { S5P_DIS_IRQ_CORE1, { 0x0, 0x0, 0x0 } },
+ { S5P_DIS_IRQ_CENTRAL1, { 0x0, 0x0, 0x0 } },
+ { S5P_ARM_COMMON_LOWPWR, { 0x0, 0x0, 0x2 } },
+ { S5P_L2_0_LOWPWR, { 0x2, 0x2, 0x3 } },
+ { S5P_L2_1_LOWPWR, { 0x2, 0x2, 0x3 } },
+ { S5P_CMU_ACLKSTOP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_SCLKSTOP_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_CMU_RESET_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_APLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_MPLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_VPLL_SYSCLK_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_EPLL_SYSCLK_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_GPS_ALIVE_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_GPSALIVE_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_CAM_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_TV_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_MFC_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_G3D_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_LCD0_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_LCD1_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_MAUDIO_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_CLKSTOP_GPS_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_CAM_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_TV_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_MFC_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_G3D_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_LCD0_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_LCD1_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_MAUDIO_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CMU_RESET_GPS_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_TOP_BUS_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_TOP_RETENTION_LOWPWR, { 0x1, 0x0, 0x1 } },
+ { S5P_TOP_PWR_LOWPWR, { 0x3, 0x0, 0x3 } },
+ { S5P_LOGIC_RESET_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_ONENAND_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_MODIMIF_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_G2D_ACP_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_USBOTG_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_HSMMC_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_CSSYS_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_SECSS_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_PCIE_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_SATA_MEM_LOWPWR, { 0x3, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_DRAM_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_MAUDIO_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_PAD_RETENTION_GPIO_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_UART_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_MMCA_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_MMCB_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_EBIA_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_EBIB_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_ISOLATION_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_PAD_RETENTION_ALV_SEL_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_XUSBXTI_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_XXTI_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_EXT_REGULATOR_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_GPIO_MODE_LOWPWR, { 0x1, 0x0, 0x0 } },
+ { S5P_GPIO_MODE_MAUDIO_LOWPWR, { 0x1, 0x1, 0x0 } },
+ { S5P_CAM_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_TV_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_MFC_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_G3D_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_LCD0_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_LCD1_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_MAUDIO_LOWPWR, { 0x7, 0x7, 0x0 } },
+ { S5P_GPS_LOWPWR, { 0x7, 0x0, 0x0 } },
+ { S5P_GPS_ALIVE_LOWPWR, { 0x7, 0x0, 0x0 } },
};
void exynos4_sys_powerdown_conf(enum sys_powerdown mode)
{
- unsigned int count = ARRAY_SIZE(sys_powerdown_reg);
+ unsigned int count = exynos4_pmu_entry_cnt;
for (; count > 0; count--)
- __raw_writel(sys_powerdown_val[count - 1][mode],
- sys_powerdown_reg[count - 1]);
+ __raw_writel(exynos4_pmu_config[count - 1].val[mode],
+ exynos4_pmu_config[count - 1].reg);
+}
+
+static int __init exynos4_pmu_init(void)
+{
+ exynos4_pmu_config = exynos4210_pmu_config;
+ exynos4_pmu_entry_cnt = ARRAY_SIZE(exynos4210_pmu_config);
+ printk(KERN_INFO "EXYNOS4210 PMU Initialize\n");
+
+ return 0;
}
+arch_initcall(exynos4_pmu_init);
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox