12 Oct, 2011

2 commits

  • nr_channels is defined in "struct pch_dma".
    and struct pch_dma_chan is defined in "struct pch_dma".
    So, "sizeof(struct pch_dma_chan) * nr_channels" is unnecessary.

    Signed-off-by: Tomoya MORINAGA
    Signed-off-by: Vinod Koul

    Tomoya MORINAGA
     
  • Currently, executing suspend/hibernation,
    memory access violation occurs.

    In pch_dma_save_regs() called by suspend(),
    you can see the following code.

    static void pch_dma_save_regs(struct pch_dma *pd)
    {
    snip...
    list_for_each_entry_safe(chan, _c, &pd->dma.channels, device_node) {
    pd_chan = to_pd_chan(chan);

    pd->ch_regs[i].dev_addr = channel_readl(pd_chan, DEV_ADDR);
    pd->ch_regs[i].mem_addr = channel_readl(pd_chan, MEM_ADDR);
    pd->ch_regs[i].size = channel_readl(pd_chan, SIZE);
    pd->ch_regs[i].next = channel_readl(pd_chan, NEXT);

    i++;
    }
    }

    Max loop count is 12 defined at pci_table.
    So, this caused memory access violation.

    This patch fixes the issue
    - Modify array size (MAX_CHAN_NR)

    Signed-off-by: Tomoya MORINAGA
    Signed-off-by: Vinod Koul

    Tomoya MORINAGA
     

20 Sep, 2011

1 commit


25 Jul, 2011

1 commit

  • Currently, Mode-Control register is accessed by read-modify-write.

    According to DMA hardware specifications datasheet, prohibits this method.
    Because this register resets to 0 by DMA HW after DMA transfer completes.
    Thus, current read-modify-write processing can cause unexpected behavior.

    The datasheet says in case of writing Mode-Control register, set the value for only target channel, the others must set '11b'.
    e.g. Set DMA0=01b DMA11=10b
    CTL0=33333331h
    CTL2=00002333h

    NOTE:
    CTL0 includes DMA0~7 Mode-Control register.
    CTL2 includes DMA8~11 Mode-Control register.

    This patch modifies the issue.

    Signed-off-by: Tomoya MORINAGA
    Signed-off-by: Vinod Koul

    Tomoya MORINAGA
     

14 Jul, 2011

1 commit

  • Fix for the following INFO message

    =================================
    [ INFO: inconsistent lock state ]
    2.6.39+ #89
    ---------------------------------
    inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
    rs232/822 [HC1[1]:SC0[0]:HE0:SE1] takes:
    (&(&pd_chan->lock)->rlock){?.....}, at: [] pdc_desc_get+0x16/0xab
    {HARDIRQ-ON-W} state was registered at:
    [] mark_irqflags+0xbd/0x11a
    [] __lock_acquire+0x501/0x6bb
    [] lock_acquire+0x63/0x7b
    [] _raw_spin_lock_bh+0x43/0x51
    [] pd_alloc_chan_resources+0x92/0x11e
    [] dma_chan_get+0x9b/0x107
    [] __dma_request_channel+0x61/0xdc
    [] pch_request_dma+0x61/0x19e
    [] pch_uart_startup+0x16a/0x1a2
    [] uart_startup+0x87/0x147
    [] uart_open+0x117/0x13e
    [] tty_open+0x23c/0x34c
    [] chrdev_open+0x140/0x15f
    [] __dentry_open.clone.14+0x14a/0x22b
    [] nameidata_to_filp+0x36/0x40
    [] do_last+0x513/0x635
    [] path_openat+0x9c/0x2aa
    [] do_filp_open+0x27/0x69
    [] do_sys_open+0xfd/0x184
    [] sys_open+0x24/0x2a
    [] sysenter_do_call+0x12/0x32
    irq event stamp: 2522
    hardirqs last enabled at (2521): [] _raw_spin_unlock_irqrestore+0x36/0x52
    hardirqs last disabled at (2522): [] common_interrupt+0x27/0x34
    softirqs last enabled at (2354): [] __do_softirq+0x10a/0x11a
    softirqs last disabled at (2299): [] do_softirq+0x57/0xa4

    other info that might help us debug this:
    2 locks held by rs232/822:
    #0: (&tty->atomic_write_lock){+.+.+.}, at: [] tty_write_lock+0x14/0x3c
    #1: (&port_lock_key){-.....}, at: [] pch_uart_interrupt+0x17/0x1e9

    stack backtrace:
    Pid: 822, comm: rs232 Not tainted 2.6.39+ #89
    Call Trace:
    [] ? printk+0x19/0x1b
    [] print_usage_bug+0x184/0x18f
    [] ? print_irq_inversion_bug+0x10e/0x10e
    [] mark_lock_irq+0xa5/0x1f6
    [] mark_lock+0x208/0x2d7
    [] mark_irqflags+0x55/0x11a
    [] __lock_acquire+0x501/0x6bb
    [] ? dump_trace+0x92/0xb6
    [] lock_acquire+0x63/0x7b
    [] ? pdc_desc_get+0x16/0xab
    [] _raw_spin_lock+0x3e/0x4c
    [] ? pdc_desc_get+0x16/0xab
    [] pdc_desc_get+0x16/0xab
    [] ? __lock_acquire+0x653/0x6bb
    [] pd_prep_slave_sg+0x7c/0x1cb
    [] ? nommu_map_sg+0x6e/0x81
    [] dma_handle_tx+0x2cf/0x344
    [] ? pch_uart_interrupt+0x17/0x1e9
    [] pch_uart_interrupt+0x160/0x1e9
    [] handle_irq_event_percpu+0x25/0x127
    [] handle_irq_event+0x2c/0x43
    [] ? handle_fasteoi_irq+0x84/0x84
    [] handle_edge_irq+0xac/0xce
    [] ? do_IRQ+0x38/0x9d
    [] ? common_interrupt+0x2e/0x34
    [] ? __lock_acquire+0x1f6/0x6bb
    [] ? _raw_spin_unlock_irqrestore+0x38/0x52
    [] ? uart_start+0x2d/0x32
    [] ? uart_flush_chars+0x8/0xa
    [] ? n_tty_write+0x12c/0x1c6
    [] ? try_to_wake_up+0x251/0x251
    [] ? tty_write+0x169/0x1dc
    [] ? n_tty_ioctl+0xb7/0xb7
    [] ? vfs_write+0x91/0x10d
    [] ? tty_write_lock+0x3c/0x3c
    [] ? sys_write+0x3e/0x63
    [] ? sysenter_do_call+0x12/0x32

    Signed-off-by: Alexander Stein
    Tested-by: Tomoya MORINAGA
    Signed-off-by: Vinod Koul

    Alexander Stein
     

01 Jun, 2011

1 commit

  • ISSUE: In case PCH_DMA with I2S communications with ch8~ch11, sometimes I2S data
    is not send correctly.
    CAUSE: The following patch I submitted before was not enough modification for
    supporting DMA ch8~ch11. The modification for status register of ch8~11 was not
    enough.

    pch_dma: Support I2S for ML7213 IOH
    author Tomoya MORINAGA
    Mon, 9 May 2011 07:09:38 +0000 (16:09 +0900)
    committer Vinod Koul
    Mon, 9 May 2011 11:42:23 +0000 (16:42 +0530)
    commit 194f5f2706c7472f9c6bb2d17fa788993606581f
    tree c9d4903ea02b18939a4f390956a48be1a3734517
    parent 60092d0bde4c8741198da4a69b693d3709385bf1

    This patch fixes the issue.
    We can confirm PCH_DMA with I2S communications with ch8~ch11 works well.

    Signed-off-by: Tomoya MORINAGA
    Signed-off-by: Vinod Koul

    Tomoya MORINAGA
     

09 May, 2011

6 commits


06 Apr, 2011

1 commit


07 Mar, 2011

1 commit

  • When CONFIG_PM=n, we get the following warning:

    drivers/dma/pch_dma.c:741: warning: ‘pch_dma_suspend’ defined but not used
    drivers/dma/pch_dma.c:755: warning: ‘pch_dma_resume’ defined but not used

    To fix it, wrap pch_dma_{suspend,resume} and
    pch_dma_{save,restore}_regs functions with CONFIG_PM.

    Signed-off-by: Rakib Mullick
    Signed-off-by: Vinod Koul

    Rakib Mullick
     

26 Feb, 2011

2 commits

  • set the number of array correctly.

    Signed-off-by: Tomoya MORINAGA
    Signed-off-by: Vinod Koul

    Tomoya MORINAGA
     
  • fix the following kernel error

    ------------[ cut here ]------------
    WARNING: at kernel/softirq.c:159 _local_bh_enable_ip.clone.5+0x35/0x71()
    Hardware name: To be filled by O.E.M.
    Modules linked in: pch_uart pch_dma fuse mga drm cpufreq_ondemand acpi_cpufreq mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec matroxfb_base snd_hwdep 8250_pnp snd_seq snd_seq_device matroxfb_DAC1064 snd_pcm joydev 8250 matroxfb_accel snd_timer matroxfb_Ti3026 ppdev pegasus parport_pc snd parport matroxfb_g450 g450_pll serial_core video output matroxfb_misc soundcore snd_page_alloc serio_raw pcspkr ext4 jbd2 crc16 sdhci_pci sdhci mmc_core floppy [last unloaded: scsi_wait_scan]
    Pid: 0, comm: swapper Not tainted 2.6.37.upstream_check+ #8
    Call Trace:
    [] warn_slowpath_common+0x65/0x7a
    [] ? _local_bh_enable_ip.clone.5+0x35/0x71
    [] warn_slowpath_null+0xf/0x13
    [] _local_bh_enable_ip.clone.5+0x35/0x71
    [] local_bh_enable_ip+0x8/0xa
    [] _raw_spin_unlock_bh+0x10/0x12
    [] pd_prep_slave_sg+0xba/0x200 [pch_dma]
    [] pch_uart_interrupt+0x44d/0x6aa [pch_uart]
    [] handle_IRQ_event+0x1d/0x9e
    [] handle_fasteoi_irq+0x90/0xc7
    [] ? handle_fasteoi_irq+0x0/0xc7
    [] ? do_IRQ+0x3e/0x89
    [] ? common_interrupt+0x29/0x30
    [] ? sys_getpriority+0x12d/0x1a2
    [] ? arch_local_irq_enable+0x5/0xb
    [] ? acpi_idle_enter_bm+0x22a/0x261
    [] ? cpuidle_idle_call+0x70/0xa1
    [] ? cpu_idle+0x49/0x6a
    [] ? rest_init+0x58/0x5a
    [] ? start_kernel+0x2d0/0x2d5
    [] ? i386_start_kernel+0xce/0xd5

    Signed-off-by: Tomoya MORINAGA
    Signed-off-by: Vinod Koul

    Tomoya MORINAGA
     

15 Jan, 2011

1 commit

  • Support new device OKI SEMICONDUCTOR's ML7213 IOH(Input/Output Hub) which is for
    IVI(In-Vehicle Infotainment) use.
    The ML7213 is companion chip for Intel Atom E6xx series.
    The ML7213 is completely compatible for Intel EG20T PCH.

    Signed-off-by: Tomoya MORINAGA
    Signed-off-by: Dan Williams

    Tomoya MORINAGA
     

08 Dec, 2010

1 commit

  • Currently, in case of using scatter/gather mode, head of data is not sent to

    destination. The cause is second descriptor address is set to NEXT.

    The NEXT must have head of descriptor address.

    This patch sets head of descriptor address to the NEXT.

    Acked-by: Yong Wang
    Signed-off-by: Tomoya MORINAGA
    [dan.j.williams@intel.com: fixed up usage of virt_to_phys()]
    Signed-off-by: Dan Williams

    Tomoya MORINAGA
     

27 Oct, 2010

1 commit


05 Aug, 2010

2 commits