{"push_id":947449657,"size":1,"distinct_size":1,"ref":"refs/heads/m","head":"4cde244985e464060af6d75f34fd1b1bb5d313c1","before":"e439419d33a17f0f55aa368ff1c83469f203ca86","commits":[{"sha":"4cde244985e464060af6d75f34fd1b1bb5d313c1","author":{"email":"fbd796546fc801b34e01e453c6fd30283e012038@s5r6.in-berlin.de","name":"Stefan Richter"},"message":"firewire: ohci: fix JMicron JMB38x IT context discovery\n\ncommit 100ceb66d5c40cc0c7018e06a9474302470be73c upstream.\n\nReported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo\ncontrollers:  Often or even most of the time, the controller is\ninitialized with the message \"added OHCI v1.10 device as card 0, 4 IR +\n0 IT contexts, quirks 0x10\".  With 0 isochronous transmit DMA contexts\n(IT contexts), applications like audio output are impossible.\n\nHowever, OHCI-1394 demands that at least 4 IT contexts are implemented\nby the link layer controller, and indeed JMicron JMB38x do implement\nfour of them.  Only their IsoXmitIntMask register is unreliable at early\naccess.\n\nWith my own JMB381 single function controller I found:\n  - I can reproduce the problem with a lower probability than Craig's.\n  - If I put a loop around the section which clears and reads\n    IsoXmitIntMask, then either the first or the second attempt will\n    return the correct initial mask of 0x0000000f.  I never encountered\n    a case of needing more than a second attempt.\n  - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)\n    before the first write, the subsequent read will return the correct\n    result.\n  - If I merely ignore a wrong read result and force the known real\n    result, later isochronous transmit DMA usage works just fine.\n\nSo let's just fix this chip bug up by the latter method.  Tested with\nJMB381 on kernel 3.13 and 4.3.\n\nSince OHCI-1394 generally requires 4 IT contexts at a minium, this\nworkaround is simply applied whenever the initial read of IsoXmitIntMask\nreturns 0, regardless whether it's a JMicron chip or not.  I never heard\nof this issue together with any other chip though.\n\nI am not 100% sure that this fix works on the OHCI-1394 part of JMB380\nand JMB388 combo controllers exactly the same as on the JMB381 single-\nfunction controller, but so far I haven't had a chance to let an owner\nof a combo chip run a patched kernel.\n\nStrangely enough, IsoRecvIntMask is always reported correctly, even\nthough it is probed right before IsoXmitIntMask.\n\nChange-Id: Iffbe491cad53253329d544122754618785e05f13\nReported-by: Clifford Dunn\nReported-by: Craig Moore <craig.moore@qenos.com>\nSigned-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/DirtyUnicorns/android_kernel_moto_shamu/commits/4cde244985e464060af6d75f34fd1b1bb5d313c1"}]}