08 Aug, 2013

1 commit


25 Jul, 2013

1 commit


12 Jul, 2013

1 commit

  • Add a command line option to route the ENET interrupts to the GPIO_1_6.
    To route the ENET interrupts to GPIO_6 add "enet_gpio_6" to the
    kernel command line.

    Also remove the CONFIG option (MX6_ENET_IRQ_TO_GPIO).

    This commit should be applied on top of following commits:
    72c86f0b9a953e91bb1ed31021b71f337050bc28
    808863866d2c17aeb3e70a7fcd094bd96db4b601
    bae4d40849f3acdd9663f5a0857c9415ed7e6d5d

    Signed-off-by: Ranjani Vaidyanathan

    Ranjani Vaidyanathan
     

11 Jul, 2013

1 commit


10 Jul, 2013

2 commits


19 Jun, 2013

1 commit


14 May, 2013

1 commit


16 Apr, 2013

2 commits

  • can_get_echo_skb() is usually called in the TX complete handler.
    The stats->tx_packets and stats->tx_bytes should be updated there, too.
    This patch simplifies to figure out the size of the sent CAN frame.

    Signed-off-by: Marc Kleine-Budde

    Marc Kleine-Budde
     
  • All of the interrupts from the ENET block are not routed to
    the GPC block. Hence ENET interrupts are not able to wake
    up the SOC when the system is in WAIT mode. And the ENET
    interrupt gets serviced only when another interrupt causes
    the SOC to exit WAIT mode. This impacts the ENET performance.

    To fix the issue two options:
    1. Route the ENET interrupt to a GPIO. Need to enable the
    CONFIG_MX6_ENET_IRQ_TO_GPIO in the config.
    2. If the GPIO mechanism cannot be used and is not enabled
    by the above mentioned config, the patch will disable entry
    to WAIT mode until ENET clock is active. When the ENET clock
    is disabled, WAIT mode will be automatically enetered.

    Signed-off-by: Ranjani Vaidyanathan

    Ranjani Vaidyanathan
     

15 Apr, 2013

1 commit

  • Use circle buf to replace old ringbuf mechanism.
    Change to use circle buffer in read, write, rx isr and tx isr functions.
    In first design of MLB, it's using it's own mechanism to manage ring
    buffer, like in mxc_mlb.c.
    And then, I saw that kernel already had a serials of circ buffer macros
    which can be used to manage ring buffers.
    This patch is to use circle buffer macros to manage mlb internal ring
    buffers.
    For detail of circle buffers, you can refer to
    linux-2.6-imx/Documentation/circular-buffers.txt.

    Signed-off-by: Terry Lv

    Terry Lv
     

10 Apr, 2013

1 commit

  • During the read of NOR, the kernel actually calls the inline_map_copy_from()
    to read the data out. And inline_map_copy_from() will use the memcpy_fromio()
    to do the real job.

    The memcpy_fromio macro maps _memcpy_fromio() in the current code.
    But the _memcpy_fromio() will use readb() to do the copy work one byte
    by one byte. This makes the read performance of NOR very slow(about 2~3MB/s).

    A similiar discussion could be found in:
    http://lists.infradead.org/pipermail/linux-arm-kernel/2009-November/003860.html

    This patch replace the memcpy_fromio with memcpy which is optimized by the
    kernel.

    The following is the result from mtd_speedtest with M29W256GL7AN6E:
    =================================================
    mtd_speedtest: MTD device: 2
    mtd_speedtest: not NAND flash, assume page size is 512 bytes.
    mtd_speedtest: MTD device size 4194304, eraseblock size 131072, page size 512,
    count of eraseblocks 32, pages per eraseblock 256, OOB size 0
    mtd_speedtest: testing eraseblock write speed
    mtd_speedtest: eraseblock write speed is 845 KiB/s
    mtd_speedtest: testing eraseblock read speed
    mtd_speedtest: eraseblock read speed is 19504 KiB/s
    mtd_speedtest: testing page write speed
    mtd_speedtest: page write speed is 845 KiB/s
    mtd_speedtest: testing page read speed
    mtd_speedtest: page read speed is 19140 KiB/s
    mtd_speedtest: testing 2 page write speed
    mtd_speedtest: 2 page write speed is 846 KiB/s
    mtd_speedtest: testing 2 page read speed
    mtd_speedtest: 2 page read speed is 19320 KiB/s
    mtd_speedtest: Testing erase speed
    mtd_speedtest: erase speed is 233 KiB/s
    mtd_speedtest: Testing 2x multi-block erase speed
    mtd_speedtest: 2x multi-block erase speed is 225 KiB/s
    mtd_speedtest: Testing 4x multi-block erase speed
    mtd_speedtest: 4x multi-block erase speed is 224 KiB/s
    mtd_speedtest: Testing 8x multi-block erase speed
    mtd_speedtest: 8x multi-block erase speed is 225 KiB/s
    mtd_speedtest: Testing 16x multi-block erase speed
    mtd_speedtest: 16x multi-block erase speed is 225 KiB/s
    mtd_speedtest: Testing 32x multi-block erase speed
    mtd_speedtest: 32x multi-block erase speed is 225 KiB/s
    mtd_speedtest: Testing 64x multi-block erase speed
    mtd_speedtest: 64x multi-block erase speed is 224 KiB/s
    mtd_speedtest: finished
    =================================================

    Signed-off-by: Huang Shijie

    Huang Shijie
     

09 Apr, 2013

1 commit


03 Apr, 2013

1 commit

  • All of the interrupts from the ENET block are not routed to
    the GPC block. Hence ENET interrupts are not able to wake
    up the SOC when the system is in WAIT mode. And the ENET
    interrupt gets serviced only when another interrupt causes
    the SOC to exit WAIT mode. This impacts the ENET performance.

    To fix the issue two options:
    1. Route the ENET interrupt to a GPIO. Need to enable the
    CONFIG_MX6_ENET_IRQ_TO_GPIO in the config.
    This patch provides support for routing the ENET interrupt
    to GPIO_1_6. Routing to this GPIO requires no HW board mods.
    If the GPIO_1_6 is being used for some other peripheral,
    this patch can be followed to route the ENET interrupt to
    any other GPIO though a HW mode maybe required.
    2. If the GPIO mechanism cannot be used and is not enabled
    by the above mentioned config, the patch will disable entry
    to WAIT mode until ENET clock is active. When the ENET clock
    is disabled, WAIT mode will be automatically enetered.

    Signed-off-by: Ranjani Vaidyanathan

    Ranjani Vaidyanathan
     

01 Mar, 2013

1 commit

  • There are so many retries happen on the per-cpu event device
    when run the command 'cat /proc/timer_list', as following:

    root@~$ cat /proc/timer_list
    Timer List Version: v0.6
    HRTIMER_MAX_CLOCK_BASES: 3
    now at 3297691988044 nsecs

    Tick Device: mode: 1
    Per CPU device: 0
    Clock Event Device: local_timer
    max_delta_ns: 8624432320
    min_delta_ns: 1000
    mult: 2138893713
    shift: 32
    mode: 3
    next_event: 3297700000000 nsecs
    set_next_event: twd_set_next_event
    set_mode: twd_set_mode
    event_handler: hrtimer_interrupt
    retries: 36383

    the reason is that the local timer will stop when enter C3 state,
    we need switch the local timer to bc timer when enter the state
    and switch back when exit from the that state.The code is like this:

    void arch_idle(void)
    {
    ....
    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
    enter_the_wait_mode();

    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
    }

    when the broadcast timer interrupt arrives(this interrupt just wakeup
    the ARM, and ARM has no chance to handle it since local irq is disabled.
    In fact it's disabled in cpu_idle() of arch/arm/kernel/process.c)

    the broadcast timer interrupt will wake up the CPU and run:

    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu); ->
    tick_broadcast_oneshot_control(...);
    ->
    tick_program_event(dev->next_event, 1);
    ->
    tick_dev_program_event(dev, expires, force);
    ->
    for (i = 0;;) {
    int ret = clockevents_program_event(dev, expires, now);
    if (!ret || !force)
    return ret;
    dev->retries++;
    ....
    now = ktime_get();
    expires = ktime_add_ns(now, dev->min_delta_ns);
    }
    clockevents_program_event(dev, expires, now);
    delta = ktime_to_ns(ktime_sub(expires, now));

    if (delta retries++ when retry to program the expired timer.

    Even under the worst case, after the re-program the expired timer,
    then CPU enter idle quickly before the re-progam timer expired,
    it will make system ping-pang forever if no interrupt happen.

    We have found the ping-pang issue during the video play-back test.
    system will freeze and video not playing for sometime until other interrupt
    occured to break the error condition.

    The detailed information, please refer to the LKML:https://lkml.org/lkml/2013/2/20/216
    which posted by Jason Liu.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Jason Liu
    Tested-by: Jason Liu
    Tested-by: Santosh Shilimkar
    Tested-by: Lorenzo Pieralisi

    Jason Liu
     

20 Feb, 2013

1 commit


23 Jan, 2013

1 commit


18 Jan, 2013

1 commit


08 Jan, 2013

1 commit


27 Nov, 2012

1 commit


15 Nov, 2012

1 commit

  • ASoC ESAI machine driver and pcm platform driver use the APIs from mxc_asrc.c,
    but once ASRC is used as a loadable module, these files can't find the APIs
    from this ko. In this patch, we use 'asrc_p2p_hook' to hook the APIs which will
    be used in ASoC ESAI machine driver and pcm platform driver.

    Signed-off-by: Ge Lei

    Ge Lei
     

14 Nov, 2012

1 commit


07 Nov, 2012

1 commit


06 Nov, 2012

6 commits

  • To finish a buffer convert in ASRC, user should 1. prepare input buffer,
    2. prepare output buffer 3. wait for output buffer's completion 4.wait
    for input buffer's comletion. The flow make user application ugly.

    In this patch, pack steps above to 1 stop: ASRC_CONVERT.

    Signed-off-by: Chen Liangjun

    Chen Liangjun
     
  • ASRC driver use DMA to transfer data from ASRC output FIFO to memory.
    However, DMA way require the data number in ASRC output FIFO being larger
    than watermark level. Thus a dma request can trigger a DMA burst. For
    the last period of output data, its number is possiblely less than output
    FIFO watermark level. In this case, the output DMA would pending for the
    last period of output data until timeout.

    In this patch:
    1 divide expected output data length into 2 parts: DMA part
    and poll part. Using DMA to get the DMA part data and poll mode to
    get the poll part.
    2 to prevent user from processing these 2 parts above, kernel
    buffers would be untouchable. User application only need send its data
    buffer address to driver instead of query the kernel buffer.

    Signed-off-by: Chen Liangjun

    Chen Liangjun
     
  • In the origin code, ASRC driver use cyclic way to process DMA task
    transfering data to/from ASRC input/output FIFO. In this case, it is
    necessary that user application should promise that the input buffer
    flow is continuous. If not, there would be 0 data be inserted into data
    flow. The output data would be noisy.

    In this patch,
    1 use scatter list instead of cyclic SDMA: with scatter list,
    SDMA would stop when the applied scatter list nents are finished.
    2 set stall bit for ASRC "memory->ASRC->memory" convert to stop
    ASRC convert when input data is not send into ASRC input FIFO in time.

    Signed-off-by: Chen Liangjun

    Chen Liangjun
     
  • For ASRC's "memory -> ASRC -> memory" using, new driver would support
    model below: user input one buffer into ASRC and an corresponding output
    buffer would be poped out. There is no timing requirement between this
    input buffer and next input buffer. Thus driver would not use the cyclic
    way to config SDMA and scatterlist is used. buffer allocated by
    dma_alloc_coherent() can't support scatterlist well.

    In this patch, use kzalloc to allocate buffer to support scatterlist.

    Signed-off-by: Chen Liangjun

    Chen Liangjun
     
  • SDMA driver can't promise receive all output data generated. Cause when
    the data in output FIFO is less than ASRC output FIFO watermark, there
    would be no DMA request generated and thus no SDMA transfer would
    happens.

    In this patch, add work struct to support ASRC driver receive last part
    of data in OUTPUT FIFO in polling way.

    Signed-off-by: Chen Liangjun

    Chen Liangjun
     
  • According to ASRC memory->ASRC->memory requirement, driver should
    satisfy the feature below: user application would passed into one buffer
    and waiting until the output buffer is generated. In this case, only one
    buffer is on processing and it is no necessary to use the queue to do
    the convert. What is worse, queue operation would make the ASRC driver
    hard to understand and maintain.

    In this patch, remove the queue operation in ASRC driver.

    Signed-off-by: Chen Liangjun

    Chen Liangjun
     

24 Oct, 2012

1 commit


15 Oct, 2012

1 commit

  • In the maxim 17135 driver, the power good is confirmed by the
    power good GPIO polarity change when comparing the status at
    the beginning of driver probe and display regulator enabled.
    However, it is not reliable since the initial value of the GPIO
    is not constant. Normally, it is 1 but it can be 0 after system reset
    unexpectedly. Now, it is changed to POK bit checking in FAULT register.

    Signed-off-by: Jack Lee

    Jack Lee
     

29 Sep, 2012

1 commit

  • - Added mxcfb_elcdif_register_mode function.
    - Create video mode list, and check default video mode
    with video mode list before setting.
    - Adjust elcdif pixel clock setting, reconfig elcdif pixel
    parent clock video pll, get more accurate pixel clock
    according video mode.
    - Added video mode dump function for debug

    Signed-off-by: Sandor Yu

    Sandor Yu
     

25 Sep, 2012

1 commit


20 Sep, 2012

1 commit


14 Sep, 2012

1 commit

  • When unplug, blank happens, HDMI audio can't play properly. So in
    driver, audio pcm would be disconnected when event above happens.
    However, pulse audio can't process disconnect event properly and if an
    blank or unplug event happens, HDMI sink would lost and can't be back
    again.

    In this patch, instead of disconnecting audio PCM stream, triggering
    stop audio pcm while unplug and blank, triggering start again while plug
    and unblank if the audio pcm is triggerd stop in the unplug/blank event.
    Signed-off-by: Chen Liangjun

    Chen Liangjun
     

12 Sep, 2012

1 commit


07 Sep, 2012

1 commit

  • New NAND controllers can perform read/write via HW engines which don't expose
    OOB data in their DMA mode. To reflect this, we should rework the nand_chip /
    nand_ecc_ctrl interfaces that assume that drivers will always read/write OOB
    data in the nand_chip.oob_poi buffer. A better interface includes a boolean
    argument that explicitly tells the callee when OOB data is requested by the
    calling layer (for reading/writing to/from nand_chip.oob_poi).

    This patch adds the 'oob_required' parameter to each relevant {read,write}_page
    interface; all 'oob_required' parameters are left unused for now. The next
    patch will set the parameter properly in the nand_base.c callers, and follow-up
    patches will make use of 'oob_required' in some of the callee functions.

    Note that currently, there is no harm in ignoring the 'oob_required' parameter
    and *always* utilizing nand_chip.oob_poi, but there can be
    performance/complexity/design benefits from avoiding filling oob_poi in the
    common case. I will try to implement this for some drivers which can be ported
    easily.

    Note: I couldn't compile-test all of these easily, as some had ARCH
    dependencies.

    [Huang Shijie: I remove the unused code for the other drivers.]

    [dwmw2: Merge later 1/0 vs. true/false cleanup]
    Signed-off-by: Brian Norris
    Reviewed-by: Shmulik Ladkani
    Acked-by: Jiandong Zheng
    Acked-by: Mike Dunn
    Signed-off-by: Artem Bityutskiy
    Signed-off-by: David Woodhouse
    Signed-off-by: Huang Shijie

    Huang Shijie
     

29 Aug, 2012

1 commit


22 Aug, 2012

1 commit

  • Test Env:
    1. MX6DL SabreSD board.
    2. On board eMMC (Sandisk: SDIN5C2-8G) running at 8-bit DDR @ 52MHz.
    3. Test commands:
    3.1 Writing command:
    # dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=100 conv=fsync
    3.2 Reading command:
    # echo 1 > /proc/sys/vm/drop_caches
    # echo 1 > /proc/sys/vm/drop_caches
    # sleep 1
    # dd if=/dev/mmcblk0 of=/dev/null bs=1M count=100

    Performance result with this patch:
    -------------------------------------------------------
    | CPU freq | SDMA (512KB) | SDMA (64KB) | ADMA |
    |----------+--------------+-------------+-------------|
    | 1Ghz | ~11MB/s (w) | ~5MB/s (w) | ~11MB/s (w) |
    | | ~25MB/s (r) | ~25MB/s (r) | ~23MB/s (r) |
    |----------+--------------+-------------+-------------|
    | 200Mhz | ~8MB/s (w) | ~5MB/s (w) | ~9MB/s (w) |
    | | ~16MB/s (r) | ~20MB/s (r) | ~13MB/s (r) |
    -------------------------------------------------------

    Performance result without this patch:
    -------------------------------------------------------
    | CPU freq | SDMA (512KB) | SDMA (64KB) | ADMA |
    |----------+--------------+-------------+-------------|
    | 1Ghz | ~10MB/s (w) | ~5MB/s (w) | ~10MB/s (w) |
    | | ~22MB/s (r) | ~23MB/s (r) | ~22MB/s (r) |
    |----------+--------------+-------------+-------------|
    | 200Mhz | ~8MB/s (w) | ~4MB/s (w) | ~8MB/s (w) |
    | | ~13MB/s (r) | ~16MB/s (r) | ~11MB/s (r) |
    -------------------------------------------------------

    Signed-off-by: Ryan QIAN

    Ryan QIAN
     

16 Aug, 2012

1 commit