<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/mips, branch v3.6.1</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus</title>
<updated>2012-09-22T19:47:53+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-09-22T19:47:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e5e77cf9f9a275083f9a365a20d956fa8a67803e'/>
<id>e5e77cf9f9a275083f9a365a20d956fa8a67803e</id>
<content type='text'>
Pull MIPS fixes from Ralf Baechle:
 "Random fixes across arch/mips, essentially.

  One fix for an issue in get_user_pages_fast() which previously was
  discovered on x86, a miscalculation in the support for the MIPS MT
  hardware multithreading support, the RTC support for the Malta and a
  fix for a spurious interrupt issue that seems to bite only very
  special Malta configurations."

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: Malta: Don't crash on spurious interrupt.
  MIPS: Malta: Remove RTC Data Mode bootstrap breakage
  MIPS: mm: Add compound tail page _mapcount when mapped
  MIPS: CMP/SMTC: Fix tc_id calculation
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull MIPS fixes from Ralf Baechle:
 "Random fixes across arch/mips, essentially.

  One fix for an issue in get_user_pages_fast() which previously was
  discovered on x86, a miscalculation in the support for the MIPS MT
  hardware multithreading support, the RTC support for the Malta and a
  fix for a spurious interrupt issue that seems to bite only very
  special Malta configurations."

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: Malta: Don't crash on spurious interrupt.
  MIPS: Malta: Remove RTC Data Mode bootstrap breakage
  MIPS: mm: Add compound tail page _mapcount when mapped
  MIPS: CMP/SMTC: Fix tc_id calculation
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Malta: Don't crash on spurious interrupt.</title>
<updated>2012-09-17T00:04:29+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2012-09-16T23:23:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e376fdf42062e7373b82093b278f99aa2b547db7'/>
<id>e376fdf42062e7373b82093b278f99aa2b547db7</id>
<content type='text'>
48d480b0bde794781fcae9501fb043c1bac0e523 [[MIPS] Malta: Fix off by one bug in interrupt
handler.] did not take in account that irq_ffs() will also return 0 if for some reason
the set of pending interrupts happens to be empty.

This is trivial to trigger with a RM5261 CPU module running a 64-bit kernel and results
in something like the following:

CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff801772d0, ra == ffffffff8017ad24
Oops[#1]:
Cpu 0
$ 0   : 0000000000000000 ffffffff9000a4e0 ffffffff9000a4e0 ffffffff9000a4e0
$ 4   : ffffffff80592be0 0000000000000000 00000000000000d6 ffffffff80322ed0
$ 8   : ffffffff805fe538 0000000000000000 ffffffff9000a4e0 ffffffff80590000
$12   : 00000000000000d6 0000000000000000 ffffffff80600000 ffffffff805fe538
$16   : 0000000000000000 0000000000000010 ffffffff80592be0 0000000000000010
$20   : 0000000000000000 0000000000500001 0000000000000000 ffffffff8051e078
$24   : 0000000000000028 ffffffff803226e8
$28   : 9800000003828000 980000000382b900 ffffffff8051e060 ffffffff8017ad24
Hi    : 0000000000000000
Lo    : 0000006388974000
epc   : ffffffff801772d0 handle_irq_event_percpu+0x70/0x2f0
    Not tainted
ra    : ffffffff8017ad24 handle_percpu_irq+0x54/0x88
Status: 9000a4e2    KX SX UX KERNEL EXL
Cause : 00808008
BadVA : 0000000000000000
PrId  : 000028a0 (Nevada)
Modules linked in:
Process init (pid: 1, threadinfo=9800000003828000, task=9800000003827968, tls=0000000077087490)
Stack : ffffffff80592be0 ffffffff8058d248 0000000000000040 0000000000000000
        ffffffff80613340 0000000000500001 ffffffff805a0000 0000000000000882
        9800000003b89000 ffffffff8017ad24 00000000000000d5 0000000000000010
        ffffffff9000a4e1 ffffffff801769f4 ffffffff9000a4e0 ffffffff801037f8
        0000000000000000 ffffffff80101c44 0000000000000000 ffffffff9000a4e0
        0000000000000000 9000000018000000 90000000180003f9 0000000000000001
        0000000000000000 00000000000000ff 0000000000000018 0000000000000001
        0000000000000001 00000000003fffff 0000000000000020 ffffffff802cf7ac
        ffffffff80208918 000000007fdadf08 ffffffff80612d88 ffffffff9000a4e1
        0000000000000040 0000000000000000 ffffffff80613340 0000000000500001
        ...
Call Trace:
[&lt;ffffffff801772d0&gt;] handle_irq_event_percpu+0x70/0x2f0
[&lt;ffffffff8017ad24&gt;] handle_percpu_irq+0x54/0x88
[&lt;ffffffff801769f4&gt;] generic_handle_irq+0x44/0x60
[&lt;ffffffff801037f8&gt;] do_IRQ+0x48/0x70
[&lt;ffffffff80101c44&gt;] ret_from_irq+0x0/0x4
[&lt;ffffffff80326170&gt;] serial8250_startup+0x310/0x870
[&lt;ffffffff8032175c&gt;] uart_startup.part.7+0x9c/0x330
[&lt;ffffffff80321b4c&gt;] uart_open+0x15c/0x1b0
[&lt;ffffffff80302034&gt;] tty_open+0x1fc/0x720
[&lt;ffffffff801bffac&gt;] chrdev_open+0x7c/0x180
[&lt;ffffffff801b9ab8&gt;] do_dentry_open.isra.14+0x288/0x390
[&lt;ffffffff801bac5c&gt;] nameidata_to_filp+0x5c/0xc0
[&lt;ffffffff801ca700&gt;] do_last.isra.33+0x330/0x8f0
[&lt;ffffffff801caf3c&gt;] path_openat+0xbc/0x440
[&lt;ffffffff801cb3c8&gt;] do_filp_open+0x38/0xa8
[&lt;ffffffff801bade4&gt;] do_sys_open+0x124/0x218
[&lt;ffffffff80110538&gt;] handle_sys+0x118/0x13c

Code: 02d5a825  12800012  02a0b02d &lt;de820000&gt; de850008  0040f809  0220202d  0040a82d  40026000
---[ end trace 5d8e7b9a86badd2d ]---
Kernel panic - not syncing: Fatal exception in interrupt

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
48d480b0bde794781fcae9501fb043c1bac0e523 [[MIPS] Malta: Fix off by one bug in interrupt
handler.] did not take in account that irq_ffs() will also return 0 if for some reason
the set of pending interrupts happens to be empty.

This is trivial to trigger with a RM5261 CPU module running a 64-bit kernel and results
in something like the following:

CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff801772d0, ra == ffffffff8017ad24
Oops[#1]:
Cpu 0
$ 0   : 0000000000000000 ffffffff9000a4e0 ffffffff9000a4e0 ffffffff9000a4e0
$ 4   : ffffffff80592be0 0000000000000000 00000000000000d6 ffffffff80322ed0
$ 8   : ffffffff805fe538 0000000000000000 ffffffff9000a4e0 ffffffff80590000
$12   : 00000000000000d6 0000000000000000 ffffffff80600000 ffffffff805fe538
$16   : 0000000000000000 0000000000000010 ffffffff80592be0 0000000000000010
$20   : 0000000000000000 0000000000500001 0000000000000000 ffffffff8051e078
$24   : 0000000000000028 ffffffff803226e8
$28   : 9800000003828000 980000000382b900 ffffffff8051e060 ffffffff8017ad24
Hi    : 0000000000000000
Lo    : 0000006388974000
epc   : ffffffff801772d0 handle_irq_event_percpu+0x70/0x2f0
    Not tainted
ra    : ffffffff8017ad24 handle_percpu_irq+0x54/0x88
Status: 9000a4e2    KX SX UX KERNEL EXL
Cause : 00808008
BadVA : 0000000000000000
PrId  : 000028a0 (Nevada)
Modules linked in:
Process init (pid: 1, threadinfo=9800000003828000, task=9800000003827968, tls=0000000077087490)
Stack : ffffffff80592be0 ffffffff8058d248 0000000000000040 0000000000000000
        ffffffff80613340 0000000000500001 ffffffff805a0000 0000000000000882
        9800000003b89000 ffffffff8017ad24 00000000000000d5 0000000000000010
        ffffffff9000a4e1 ffffffff801769f4 ffffffff9000a4e0 ffffffff801037f8
        0000000000000000 ffffffff80101c44 0000000000000000 ffffffff9000a4e0
        0000000000000000 9000000018000000 90000000180003f9 0000000000000001
        0000000000000000 00000000000000ff 0000000000000018 0000000000000001
        0000000000000001 00000000003fffff 0000000000000020 ffffffff802cf7ac
        ffffffff80208918 000000007fdadf08 ffffffff80612d88 ffffffff9000a4e1
        0000000000000040 0000000000000000 ffffffff80613340 0000000000500001
        ...
Call Trace:
[&lt;ffffffff801772d0&gt;] handle_irq_event_percpu+0x70/0x2f0
[&lt;ffffffff8017ad24&gt;] handle_percpu_irq+0x54/0x88
[&lt;ffffffff801769f4&gt;] generic_handle_irq+0x44/0x60
[&lt;ffffffff801037f8&gt;] do_IRQ+0x48/0x70
[&lt;ffffffff80101c44&gt;] ret_from_irq+0x0/0x4
[&lt;ffffffff80326170&gt;] serial8250_startup+0x310/0x870
[&lt;ffffffff8032175c&gt;] uart_startup.part.7+0x9c/0x330
[&lt;ffffffff80321b4c&gt;] uart_open+0x15c/0x1b0
[&lt;ffffffff80302034&gt;] tty_open+0x1fc/0x720
[&lt;ffffffff801bffac&gt;] chrdev_open+0x7c/0x180
[&lt;ffffffff801b9ab8&gt;] do_dentry_open.isra.14+0x288/0x390
[&lt;ffffffff801bac5c&gt;] nameidata_to_filp+0x5c/0xc0
[&lt;ffffffff801ca700&gt;] do_last.isra.33+0x330/0x8f0
[&lt;ffffffff801caf3c&gt;] path_openat+0xbc/0x440
[&lt;ffffffff801cb3c8&gt;] do_filp_open+0x38/0xa8
[&lt;ffffffff801bade4&gt;] do_sys_open+0x124/0x218
[&lt;ffffffff80110538&gt;] handle_sys+0x118/0x13c

Code: 02d5a825  12800012  02a0b02d &lt;de820000&gt; de850008  0040f809  0220202d  0040a82d  40026000
---[ end trace 5d8e7b9a86badd2d ]---
Kernel panic - not syncing: Fatal exception in interrupt

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Malta: Remove RTC Data Mode bootstrap breakage</title>
<updated>2012-09-14T15:54:33+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@codesourcery.com</email>
</author>
<published>2012-09-13T20:23:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=636221b86ce0b3b1238c72bad7172d5227d408ac'/>
<id>636221b86ce0b3b1238c72bad7172d5227d408ac</id>
<content type='text'>
 YAMON requires and enforces the RTC Data Mode (Register B, DM bit) to
binary, that is the bit is set every time the board goes through the
firmware bootstrap sequence.  Likewise its calendar manipulation commands
interpret or set the RTC registers unconditionally as binary, never
actually checking what the value of the DM bit is, under the (correct)
assumption that it has been previously set, to indicate the binary mode.

 A change to Linux a while ago however introduced a platform-specific
tweak that clears that bit and therefore forces the data mode to BCD.
This causes clock corruption and misinterpretation that has to be fixed up
by user-mode tools in system startup scripts as the initial clock is often
incorrect according to the BCD interpretation forced.

 This change removes the hack; a comment included refers to alarm code,
but even if it was broken at one point by requiring the BCD mode, it
should have been trivially corrected and even if not, given how rarely the
alarm feature is used, that was not really a reasonable justification to
break the system clock that is indeed used by virtually everything.  And
either way the alarm code has been since fixed anyway.

Signed-off-by: Maciej W. Rozycki &lt;macro@codesourcery.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4336/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 YAMON requires and enforces the RTC Data Mode (Register B, DM bit) to
binary, that is the bit is set every time the board goes through the
firmware bootstrap sequence.  Likewise its calendar manipulation commands
interpret or set the RTC registers unconditionally as binary, never
actually checking what the value of the DM bit is, under the (correct)
assumption that it has been previously set, to indicate the binary mode.

 A change to Linux a while ago however introduced a platform-specific
tweak that clears that bit and therefore forces the data mode to BCD.
This causes clock corruption and misinterpretation that has to be fixed up
by user-mode tools in system startup scripts as the initial clock is often
incorrect according to the BCD interpretation forced.

 This change removes the hack; a comment included refers to alarm code,
but even if it was broken at one point by requiring the BCD mode, it
should have been trivially corrected and even if not, given how rarely the
alarm feature is used, that was not really a reasonable justification to
break the system clock that is indeed used by virtually everything.  And
either way the alarm code has been since fixed anyway.

Signed-off-by: Maciej W. Rozycki &lt;macro@codesourcery.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4336/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: mm: Add compound tail page _mapcount when mapped</title>
<updated>2012-08-27T14:10:21+00:00</updated>
<author>
<name>Jovi Zhang</name>
<email>bookjovi@gmail.com</email>
</author>
<published>2012-08-22T02:34:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=af89fa3986b9d034a286544ab1ed95096496a2f9'/>
<id>af89fa3986b9d034a286544ab1ed95096496a2f9</id>
<content type='text'>
See commit b6999b191 which did the same modification for x86's mm/gup,

Quote from commit b6999b191:
    "If compound pages are used and the page is a
    tail page, gup_huge_pmd() increases _mapcount to record tail page are
    mapped while gup_huge_pud does not do that."

[ralf@linux-mips.org: fixed rejects caused by the original patch getting
linewrapped.]

Signed-off-by: Jovi Zhang &lt;boojovi@gmail.com&gt;
Cc: Youquan Song &lt;youquan.song@intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Patchwork: https://patchwork.linux-mips.org/patch/4291/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
See commit b6999b191 which did the same modification for x86's mm/gup,

Quote from commit b6999b191:
    "If compound pages are used and the page is a
    tail page, gup_huge_pmd() increases _mapcount to record tail page are
    mapped while gup_huge_pud does not do that."

[ralf@linux-mips.org: fixed rejects caused by the original patch getting
linewrapped.]

Signed-off-by: Jovi Zhang &lt;boojovi@gmail.com&gt;
Cc: Youquan Song &lt;youquan.song@intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Patchwork: https://patchwork.linux-mips.org/patch/4291/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: CMP/SMTC: Fix tc_id calculation</title>
<updated>2012-08-27T14:10:13+00:00</updated>
<author>
<name>RongQing.Li</name>
<email>roy.qing.li@gmail.com</email>
</author>
<published>2012-07-02T04:34:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2bd4082776ff17a0d0d565852afb422931c2f6f2'/>
<id>2bd4082776ff17a0d0d565852afb422931c2f6f2</id>
<content type='text'>
Currently the tc_id code is:

  (read_c0_tcbind() &gt;&gt; TCBIND_CURTC_SHIFT) &amp; TCBIND_CURTC;

After processing this becomes:

  (read_c0_tcbind() &gt;&gt; 21) &amp; ((0xff) &lt;&lt; 21)

But it should be:

  (read_c0_tcbind() &amp; ((0xff)&lt;&lt; 21)) &gt;&gt; 21

Signed-off-by: RongQing.Li &lt;roy.qing.li@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4077/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently the tc_id code is:

  (read_c0_tcbind() &gt;&gt; TCBIND_CURTC_SHIFT) &amp; TCBIND_CURTC;

After processing this becomes:

  (read_c0_tcbind() &gt;&gt; 21) &amp; ((0xff) &lt;&lt; 21)

But it should be:

  (read_c0_tcbind() &amp; ((0xff)&lt;&lt; 21)) &gt;&gt; 21

Signed-off-by: RongQing.Li &lt;roy.qing.li@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4077/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: pci-ar724x: avoid data bus error due to a missing PCIe module</title>
<updated>2012-08-23T13:44:47+00:00</updated>
<author>
<name>Gabor Juhos</name>
<email>juhosg@openwrt.org</email>
</author>
<published>2012-08-23T13:35:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a1dca315ce3f78347bca8ce8befe3cc71ae63b7e'/>
<id>a1dca315ce3f78347bca8ce8befe3cc71ae63b7e</id>
<content type='text'>
If the controller has no PCIe module attached, accessing of the device
configuration space causes a data bus error. Avoid this by checking the
status of the PCIe link in advance, and indicate an error if the link
is down.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Cc: stable@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4293/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the controller has no PCIe module attached, accessing of the device
configuration space causes a data bus error. Avoid this by checking the
status of the PCIe link in advance, and indicate an error if the link
is down.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Cc: stable@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4293/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Malta: Delete duplicate PCI fixup.</title>
<updated>2012-08-17T08:57:29+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2012-08-17T08:45:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=16cc2cf642eb73978a3ebde66dc94d24d46b4798'/>
<id>16cc2cf642eb73978a3ebde66dc94d24d46b4798</id>
<content type='text'>
2ec8663f9c03a96f2c328c7c483603c31d62ad37 (lmo) rsp.
497e5ff03f58583ada469db8a1aa34eced9dd63e (kernel.org) [MIPS: Malta: Move
PIIX4 PCI fixup to where it belongs.] attempted to move this PCI fixup
but really only added it at it's new location without deleting the old
instance.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
2ec8663f9c03a96f2c328c7c483603c31d62ad37 (lmo) rsp.
497e5ff03f58583ada469db8a1aa34eced9dd63e (kernel.org) [MIPS: Malta: Move
PIIX4 PCI fixup to where it belongs.] attempted to move this PCI fixup
but really only added it at it's new location without deleting the old
instance.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: ath79: don't hardcode the unavailability of the DSP ASE</title>
<updated>2012-08-17T08:57:29+00:00</updated>
<author>
<name>Gabor Juhos</name>
<email>juhosg@openwrt.org</email>
</author>
<published>2012-08-14T19:12:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=00dc5ce2a653a332190aa29b2e1f3bceaa7d5b8d'/>
<id>00dc5ce2a653a332190aa29b2e1f3bceaa7d5b8d</id>
<content type='text'>
The ath79 platform code allows to run a single kernel image on various
SoCs which are based on the 24Kc and 74Kc cores.  The current code
explicitely disables the DSP ASE, but that is available in the 74Kc core.

Remove the override in order to let the kernel to detect the availability
of the DSP ASE at runtime.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4222/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The ath79 platform code allows to run a single kernel image on various
SoCs which are based on the 24Kc and 74Kc cores.  The current code
explicitely disables the DSP ASE, but that is available in the 74Kc core.

Remove the override in order to let the kernel to detect the availability
of the DSP ASE at runtime.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4222/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Synchronize MIPS count one CPU at a time</title>
<updated>2012-08-17T08:57:28+00:00</updated>
<author>
<name>Jayachandran C</name>
<email>jchandra@broadcom.com</email>
</author>
<published>2012-08-14T13:26:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cf9bfe55f24973a8f40e2c922a7e82cf09e486fd'/>
<id>cf9bfe55f24973a8f40e2c922a7e82cf09e486fd</id>
<content type='text'>
The current implementation of synchronise_count_{master,slave} blocks
slave CPUs in early boot until all of them come up. This no longer
works because blocking a CPU with interrupts off after notifying the
CPU to be online causes problems with the current kernel.

Specifically, after the workqueue changes
(commit a08489c569dc1 "Pull workqueue changes from Tejun Heo")
the CPU_ONLINE notification callback workqueue_cpu_up_callback()
will hang on wait_for_completion(&amp;idle_rebind.done), if the slave
CPUs are blocked for synchronize_count_slave().

The changes are to update synchronize_count_{master,slave}() to handle
one CPU at a time and to call synchronise_count_master() in __cpu_up()
so that the CPU_ONLINE notification goes out only after the COP0 COUNT
register is synchronized.

[ralf@linux-mips.org: This matter only to those few platforms which are
using the cp0 counter as their clocksource which are XLP, XLR and MIPS'
CMP solution.]

Signed-off-by: Jayachandran C &lt;jchandra@broadcom.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4216/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The current implementation of synchronise_count_{master,slave} blocks
slave CPUs in early boot until all of them come up. This no longer
works because blocking a CPU with interrupts off after notifying the
CPU to be online causes problems with the current kernel.

Specifically, after the workqueue changes
(commit a08489c569dc1 "Pull workqueue changes from Tejun Heo")
the CPU_ONLINE notification callback workqueue_cpu_up_callback()
will hang on wait_for_completion(&amp;idle_rebind.done), if the slave
CPUs are blocked for synchronize_count_slave().

The changes are to update synchronize_count_{master,slave}() to handle
one CPU at a time and to call synchronise_count_master() in __cpu_up()
so that the CPU_ONLINE notification goes out only after the COP0 COUNT
register is synchronized.

[ralf@linux-mips.org: This matter only to those few platforms which are
using the cp0 counter as their clocksource which are XLP, XLR and MIPS'
CMP solution.]

Signed-off-by: Jayachandran C &lt;jchandra@broadcom.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4216/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: BCM63xx: Fix SPI message control register handling for BCM6338/6348.</title>
<updated>2012-08-17T08:57:28+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>florian@openwrt.org</email>
</author>
<published>2012-06-18T10:07:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5a6704454a68ab6e27e4fc5b82818a8c5733bf29'/>
<id>5a6704454a68ab6e27e4fc5b82818a8c5733bf29</id>
<content type='text'>
BCM6338 and BCM6348 have a message control register width of 8 bits, instead
of 16-bits like what the SPI driver assumes right now. Also the SPI message
type shift value of 14 is actually 6 for these SoCs.
This resulted in transmit FIFO corruption because we were writing 16-bits
to an 8-bits wide register, thus spanning on the first byte of the transmit
FIFO, which had already been filed in bcm63xx_spi_fill_txrx_fifo().

Fix this by passing the message control register width and message type
shift through platform data back to the SPI driver so that it can use
it properly.

Signed-off-by: Florian Fainelli &lt;florian@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Cc: grant.likely@secretlab.ca
Cc: spi-devel-general@lists.sourceforge.net
Cc: jonas.gorski@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/3983/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
BCM6338 and BCM6348 have a message control register width of 8 bits, instead
of 16-bits like what the SPI driver assumes right now. Also the SPI message
type shift value of 14 is actually 6 for these SoCs.
This resulted in transmit FIFO corruption because we were writing 16-bits
to an 8-bits wide register, thus spanning on the first byte of the transmit
FIFO, which had already been filed in bcm63xx_spi_fill_txrx_fifo().

Fix this by passing the message control register width and message type
shift through platform data back to the SPI driver so that it can use
it properly.

Signed-off-by: Florian Fainelli &lt;florian@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Cc: grant.likely@secretlab.ca
Cc: spi-devel-general@lists.sourceforge.net
Cc: jonas.gorski@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/3983/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
