{"push_id":1672628572,"size":27,"distinct_size":1,"ref":"refs/heads/topic/motu-v1","head":"59db5a5a855ac9e07620fb34f56822aa6878d6af","before":"a861e78adaef2acad1132b18723afd27ba58ee77","commits":[{"sha":"cd3b1ef7bcd5e50a793f1a407f7576bcf963dded","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"update README","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/cd3b1ef7bcd5e50a793f1a407f7576bcf963dded"},{"sha":"ec4ed6e22a60f441e1346dc05525f96a9017ada9","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add skeleton for RME Fireface series\n\nThis commit adds a new driver for RME Fireface series. This commit just\ncreates/removes card instance according to IEEE 1394 bus event. More\nfunctions will be added in following commits.\n\nThree types of firmware have released by RME GmbH; for Fireface 400, for\nFireface 800 and for UCX/802/UFX. It's reasonable that these models use\ndifferent protocol for communication. Currently, I've investigated\nFireface 400 and nothing others.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/ec4ed6e22a60f441e1346dc05525f96a9017ada9"},{"sha":"e7970cb111135c8565a941cdf1e26bcfdae062fd","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: postpone sound card registration\n\nJust after appearing on IEEE 1394 bus, this unit generates several bus\nresets. This is due to loading firmware from on-board flash memory and\ninitialize hardware. It's better to postpone sound card registration.\n\nThis commit schedules workqueue to process actual probe processing\n2 seconds after the last bus-reset. The card instance is kept at unit\nprobe callback and released at card free callback. Therefore, when the\nactual probe processing fails, the memory block is wasted. This is due to\nsimplify driver implementation.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/e7970cb111135c8565a941cdf1e26bcfdae062fd"},{"sha":"6f69c1fa807f54667cd8a531a23bd572a0b8cf8f","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add model specific structure\n\nRME Fireface series has several models and their specifications are\ndifferent. Currently, we find no way to retrieve the specifications\nfrom actual devices and need to implement them in this driver.\n\nThis commit adds a structure to describe model specific data. This\nstructure has an identical name for each unit, and maximum number of\ndata channels in each mode. I'll describe about the mode in following\ncommits.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/6f69c1fa807f54667cd8a531a23bd572a0b8cf8f"},{"sha":"5b83a785b87e0996259e5a6b44179109cd1ab672","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add an abstraction layer for model-specific protocols\n\nAs of 2016, RME discontinued its Fireface series, thus it's OK for us\nto focus on released firmwares to drive known units.\n\nAs long as investigating Fireface 400 with Windows driver and comparing\nthe result to FFADO implementation, I can see these firmwares have\ndifferent register assignments. On the other hand, according to manuals\nof each models, features relevant to packet streaming seem to be common,\nbecause GUIs for these models have the same options. It's reasonable to\nassume an abstraction layer of protocols to communicate to each models.\n\nThis commit adds the abstraction layer for the protocols. This layer\nincludes some functions to operate common features of models in this\nseries.\n\nIn IEC 61883-1/6, the sequence of packet can transfer timing information\nto synchronize receivers to transmitters. Units of each node on IEEE 1394\nbus can generate transmitter's timing clock by handling value of SYT field\nin CIP header with high-precision clock. For audio and music units on\nIEEE 1394 bus, this recovered clock is designed to used for sampling clock\nto capture/generate PCM frames on DSP/ADC/DAC. (Actually, in this world,\nthere's no units to implement this specification as is, as long as I\nknow).\n\nFireface series doesn't use this mechanism. Besides, It doesn't use\nisochronous packet with CIP header. It uses internal crystal unit as its\ninitial sampling clock. When detecting input signals which can be\navailable for sampling clock (e.g. ADAT input), drivers can configure\nunits to use the signals as source of sampling clock. When something goes\nwrong, e.g. frequency mismatching between the signal and configured value,\nunits fallback to the other detected signals alternatively. When detecting\nno alternatives, internal crystal unit is used as source of sampling\nclock. On manual of Fireface 400, this mechanism is described as\n'Autosync'.\n\nOn the units, packet streaming is controlled by write transactions to\ncertain registers. Format of the packet, e.g. the number of data channels\nin a data block, is also configured by the same manner. For this purpose,\n.begin_session and .finish_session is added.\n\nThe remarkable point of this protocol is to allow drivers to configure\narbitrary sampling transmission frequency; e.g. 12.345 Hz. As long as I\nknow, there's no actual DAC/ADC chips which support this kind of\ncapability. I think a pair of packet streaming layer and data block\nprocessing layer is isolated from sampling data processing layer in a\npoint of governed clock. In short, between these parts, resampling layer\nexists. Actually, for Fireface 400, write transactions to\n0x'0000'8010'051c has an effect to change sampling clock frequency with\nbase frequencies (32.0/44.1/48.0 kHz) and its multipliers (x2/x4),\nregardless of sampling transmission frequency.\n\nFor this reason, the abstraction layer doesn't handle parameters for\nsampling clock. Instead, each implementation of .begin_session is\nexpected to configure sampling transmission frequency.\n\nFor packet streaming layer, it's enough to get current selection of\nsource signals for the sampling clock and its frequency. In the\nabstraction layer, when internal crystal is selected, drivers can sets\narbitrary sampling frequency, else they should follow configured\nfrequency. For this purpose, .get_clock is added.\n\nDrivers are allows to bank up data fetching from a pair of packet\nstreaming/data block processing layer and sampling data processing layer.\nThis feature seems to suppress noises at starting/stopping packet\nstreaming. For this purpose, .switch_fetching_mode is added.\n\nAs I described in the above, units have remarkable mechanism to manage\nsampling clock and process sampling data. For debugging purpose,\n.dump_sync_status and .dump_clock_config are added. I don't have a need\nto common interface to represent the status and configuration,\ndevelopers can add actual implementation of the abstraction layer as they\nlike.\n\nUnlike PCM frames, MIDI messages are transferred by asynchronous\ncommunication over IEEE 1394 bus, thus target addresses are important for\nthis feature. The .midi_high_addr_reg, .midi_rx_port_0_reg and\n.midi_rx_port_1_reg are for this purpose. I'll describe them in following\ncommit.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/5b83a785b87e0996259e5a6b44179109cd1ab672"},{"sha":"f0f407e9cd4f7fb4ab0fccc566387a754962f06b","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add transaction support\n\nAs long as investigating Fireface 400, MIDI messages are transferred by\nasynchronous communication over IEEE 1394 bus.\n\nFireface 400 receives MIDI messages by write transactions to two addresses;\n0x'0000'0801'8000 and 0x'0000'0801'9000. Each of two seems to correspond to\nMIDI port 1 and 2.\n\nFireface 400 transfers MIDI messages by write transactions to certain\naddresses which configured by drivers. The drivers can decide upper 4 byte\nof the addresses by write transactions to 0x'0000'0801'03f4. For the rest\npart of the address, drivers can select from below options:\n * 0x'0000'0000\n * 0x'0000'0080\n * 0x'0000'0100\n * 0x'0000'0180\n\nSelected options are represented in register 0x'0000'0801'051c as bit\nflags. Due to this mechanism, drivers are restricted to use addresses on\n'Memory space' of IEEE 1222, even if transactions to the address have\nsome side effects.\n\nThis commit adds transaction support for MIDI messaging, based on my\nassumption that the similar mechanism is used on the other protocols. To\nreceive asynchronous transactions, the driver allocates a range of address\nin 'Memory space'. I apply a strategy to use 0x'0000'0000 as lower 4 byte\nof the address. When getting failure from Linux FireWire subsystem, this\ndriver retries to allocate addresses.\n\nUnfortunately, read transaction to address 0x'0000'0801'051c returns zero\nalways, however write transactions have effects to the other features such\nas status of sampling clock. For this reason, this commit delegates a task\nto configure this register to user space applications. The applications\nshould set 3rd bit in LSB in little endian order.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/f0f407e9cd4f7fb4ab0fccc566387a754962f06b"},{"sha":"84523df2e3c6555362eab7b00d6a9e4df7b95651","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add support for MIDI functionality\n\nIn previous commit, fireface driver supports unique transaction mechanism\nfor MIDI feature. This commit adds MIDI functionality for userspace\napplications.\n\nAs I wrote in a followed commit, user space applications get some\nrequirement from this driver. It should not touch a register to which\nunits transmit MIDI messages. It should configure a register in which\nMIDI transmission is controlled.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/84523df2e3c6555362eab7b00d6a9e4df7b95651"},{"sha":"43e8b490f55264587fbd5f7ac8a2c37f3d6e7c97","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add proc node to help debugging\n\nDrivers can retrieve the state and configuration of clock by read\ntransactions.\n\nThis commit allows protocol abstraction layer to to dump the\ninformation for debugging, via proc interface.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/43e8b490f55264587fbd5f7ac8a2c37f3d6e7c97"},{"sha":"aa4a1c1df3dacdfb9f60c1a6a47304f7f4aaf04f","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: firewire-lib: use the same prototype for functions to handle packet\n\nAudio and music units of RME Fireface series use its own protocol for\nisochronous packets to transfer data. This protocol requires ALSA IEC\n61883-1/6 engine to have alternative functions.\n\nThis commit is a preparation for the protocol.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/aa4a1c1df3dacdfb9f60c1a6a47304f7f4aaf04f"},{"sha":"246c4af048c856b881d524bc7baeb49eee6256e3","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: firewire-lib: add no-header packet processing\n\nAs long as investigating Fireface 400, IEC 61883-1/6 is not applied to\nits packet streaming protocol. Remarks of the specific protocol are:\n * Each packet doesn't include CIP headers.\n * 64,0 and 128,0 kHz are supported.\n * The device doesn't necessarily transmit 8,000 packets per second.\n * 0, 1, 2, 3 are used as tag for rx isochronous packets, however 0 is\n   used for tx isochronous packets.\n\nOn the other hand, there's a common feature. The number of data blocks\ntransferred in a second is the same as sampling transmission frequency.\nCurrent ALSA IEC 61883-1/6 engine already has a method to calculate it and\nthis driver can utilize it for rx packets, as well as tx packets.\n\nThis commit adds support for the transferring protocol. CIP_NO_HEADERS\nflag is newly added. When this flag is set:\n * Both of 0 (without CIP header) and 1 (with CIP header) are used as tag\n   to handle incoming isochronous packet.\n * 0 (without CIP header) is used as tag to transfer outgoing isochronous\n   packet.\n * Skip CIP header evaluation.\n * Use unique way to calculate the quadlets of isochronous packet payload.\n\nIn ALSA PCM interface, 128.0 kHz is not supported, and the ALSA\nIEC 61883-1/6 engine doesn't support 64.0 kHz. These modes are dropped.\n\nThe sequence of rx packet has a remarkable quirk about tag. This will be\ndescribed in later commits.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/246c4af048c856b881d524bc7baeb49eee6256e3"},{"sha":"28253af58e61efcd2a5ecede37bbe08a3a577a1c","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add unique data processing layer\n\nAs long as investigating Fireface 400, format of payload of each\nisochronous packet is not IEC 61883-1/6, thus its format of data block\nis not AM824. The remarkable points of the format are:\n * The payload just consists of some data channels of quadlet size without\n   CIP header.\n * Each data channels includes data aligned to little endian order.\n * One data channel consists of two parts; 8 bit ancillary field and 24 bit\n   PCM frame.\n\nDue to lack of CIP headers, rx/tx packets include no CIP headers and\ndifferent way to check packet discontinuity. For tx packet, the ancillary\nfield is used for counter. However, the way of counting is different\ndepending on positions of data channels. At 44.1 kHz, ancillary field in:\n * 1st/6th/9th/10th/14th/17th data channels: not used for this purpose.\n * 2nd/18th data channels: incremented every data block (0x00-0xff).\n * 3rd/4th/5th/11th/12th/13th data channels: incremented every 256 data\n   blocks (0x00-0x07).\n * 7th/8th/15th/16th data channels: incremented per the number of data\n   blocks in a packet. The increment can occur per packet (0x00-0xff).\n\nFor tx packet, tag of each isochronous packet is used for this purpose.\nThe value of tag cyclically changes between 0, 1, 2 and 3 in this order.\nThe interval is different depending on sampling transmission frequency.\nAt 44.1/48.0 kHz, it's 256 data blocks. At 88.2 kHz, it's 96 data blocks.\n\nThe number of data blocks in tx packet is exactly the same as\nSYT_INTERVAL. There's no empty packet or no-data packet, thus the\nthroughput is not 8,000 packets per sec. On the other hand, the one in\nrx packet is 8,000 packets per sec, thus the number of data blocks is\ndifferent between each packet, depending on sampling transmission\nfrequency:\n * 44.1 kHz: 5 or 6\n * 48.0 kHz: 5 or 6 or 7\n * 88.2 kHz: 10 or 11 or 12\n\nThis commit adds data processing layer to satisfy the above specification\nin a policy of 'best effort'. Although PCM frames are handled for\nintermediate buffer to user space, the ancillary data is not handled at all\nto reduce CPU usage, thus counter is not checked. 0 is always used for tag\nof isochronous packet. Furthermore, the packet streaming layer is\nresponsible for calculation of the number of data blocks for each packet,\nthus it's not exactly the same sequence from the above observation.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/28253af58e61efcd2a5ecede37bbe08a3a577a1c"},{"sha":"d52600f0dbbd7994e9efc82dc965991a9b2d4e60","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add stream management functionality\n\nThis commit adds management functionality for packet streaming.\n\nAs long as investigating Fireface 400, there're three modes depending\non sampling transmission frequency. The number of data channels in each\ndata block is different depending on the mode. The set of available\ndata channels for each mode might be different for each protocol and\nmodel.\n\nThe length of registers for the number of isochronous channel is just\nthree bits, therefore 0-7ch are available.\n\nWhen bus reset occurs on IEEE 1394 bus, the device discontinues to\ntransmit packets. This commit aborts PCM substreams at bus reset handler.\n\nAs I described in followed commits, The device manages its sampling clock\nindependently of sampling transmission frequency against IEC 61883-6.\nThus, it's a lower cost to change the sampling transmission frequency,\nwhile data fetch between streaming layer and DSP require larger buffer\nfor resampling. As a result, device latency might tend to be larger than\nASICs for IEC 61883-1/6 such as DM1000/DM1100/DM1500 (BeBoB),\nDiceII/TCD2210/TCD2220/TCD3070 and OXFW970/971.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/d52600f0dbbd7994e9efc82dc965991a9b2d4e60"},{"sha":"f5db7e6387739ba14ba20108b7bf61cb35b99347","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add support for PCM functionality\n\nThis commit adds PCM functionality to transmit/receive PCM frames on\nisochronous packet streaming. This commit enables userspace applications\nto start/stop packet streaming via ALSA PCM interface.\n\nSampling rate requested by applications is used as sampling transmission\nfrequency of IEC 61883-1/6packet streaming. As I described in followed\ncommits, units in this series manages sampling clock frequency\nindependently of sampling transmission frequency, and they supports\nresampling between their packet streaming/data block processing layer and\nsampling data processing layer. This commit take this driver to utilize\nthese features for usability.\n\nWhen internal clock is selected as source signal of sampling clock, this\ndriver allows user space applications to start PCM substreams at any rate\nwhich packet streaming engine supports as sampling transmission frequency.\nIn this case, this driver expects units to perform resampling PCM frames\nfor rx/tx packets when sampling clock frequency and sampling transmission\nfrequency are mismatched. This is for daily use cases.\n\nWhen any external clock is selected as the source signal, this driver\ngets configured sampling rate from units, then restricts available\nsampling rate to the rate for PCM applications. This is for studio use\ncases.\n\nModels in this series supports 64.0/128.0 kHz of sampling rate, however\nthese frequencies are not supported by IEC 61883-6 as sampling transmission\nfrequency. Therefore, packet streaming engine of ALSA firewire stack can't\nhandle them. When units are configured to use any external clock as source\nsignal of sampling clock and one of these unsupported rate is configured\nas rate of the sampling clock, this driver returns EIO to user space\napplications.\n\nAnyway, this driver doesn't voluntarily configure parameters of sampling\nclock. It's better for users to work with appropriate user space\nimplementations to configure the parameters in advance of usage.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/f5db7e6387739ba14ba20108b7bf61cb35b99347"},{"sha":"69443a4c50cf7e8e740ee6586d4a611a3ec9a627","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add hwdep interface\n\nThis commit adds hwdep interface so as the other drivers for audio and\nmusic units on IEEE 1394 have.\n\nThis interface is designed for mixer/control applications. By using this\ninterface, an application can get information about firewire node, can\nlock/unlock kernel streaming and can get notification at starting/stopping\nkernel streaming.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/69443a4c50cf7e8e740ee6586d4a611a3ec9a627"},{"sha":"4a47fe7540dcd356521ce3cd829ad5eab5041065","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: fireface: add support for Fireface 400\n\nFireface 400 is a second model of RME Fireface series, released in 2006.\nThis commit adds support for this model.\n\nThis model supports 8 analog channels, 2 S/PDIF channels and 8 ADAT\nchannels in both of tx/rx packet. The number of ADAT channels differs\ndepending on each mode of sampling transmission frequency.\n\n$ python2 linux-firewire-utils/src/crpp < /sys/bus/firewire/devices/fw1/config_rom\n               ROM header and bus information block\n               -----------------------------------------------------------------\n400  04107768  bus_info_length 4, crc_length 16, crc 30568 (should be 61311)\n404  31333934  bus_name \"1394\"\n408  20009002  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 9 (1024)\n40c  000a3501  company_id 000a35     |\n410  1bd0862a  device_id 011bd0862a  | EUI-64 000a35011bd0862a\n\n               root directory\n               -----------------------------------------------------------------\n414  000485ec  directory_length 4, crc 34284\n418  03000a35  vendor\n41c  0c0083c0  node capabilities per IEEE 1394\n420  8d000006  --> eui-64 leaf at 438\n424  d1000001  --> unit directory at 428\n\n               unit directory at 428\n               -----------------------------------------------------------------\n428  000314c4  directory_length 3, crc 5316\n42c  12000a35  specifier id\n430  13000002  version\n434  17101800  model\n\n               eui-64 leaf at 438\n               -----------------------------------------------------------------\n438  000261a8  leaf_length 2, crc 25000\n43c  000a3501  company_id 000a35     |\n440  1bd0862a  device_id 011bd0862a  | EUI-64 000a35011bd0862a\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/4a47fe7540dcd356521ce3cd829ad5eab5041065"},{"sha":"ba0062335c8c4b95f48dfed147085ec03e295449","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: firewire-digi00x: add support for console models of Digi00x series\n\nDigi00x series includes two types of unit; rack and console. As long as\nreading information on config rom of Digi 002 console, 'MODEL_ID' field\nhas a different value from the one on Digi 002 rack.\n\nWe've already got a test report from users with Digi 003 rack. We can\nassume that console type and rack type has different value in the field.\n\nThis commit adds a device entry for console type. For following commits,\nthis commit also adds a member to 'struct snd_digi00x' to identify console\ntype.\n\n$ cd linux-firewire-utils/src\n$ python2 ./crpp < /sys/bus/firewire/devices/fw1/config_rom\n               ROM header and bus information block\n               -----------------------------------------------------------------\n400  0404f9d0  bus_info_length 4, crc_length 4, crc 63952\n404  31333934  bus_name \"1394\"\n408  60647002  irmc 0, cmc 1, isc 1, bmc 0, cyc_clk_acc 100, max_rec 7 (256)\n40c  00a07e00  company_id 00a07e     |\n410  00a30000  device_id 0000a30000  | EUI-64 00a07e0000a30000\n\n               root directory\n               -----------------------------------------------------------------\n414  00058a39  directory_length 5, crc 35385\n418  0c0043a0  node capabilities\n41c  04000001  hardware version\n420  0300a07e  vendor\n424  81000007  --> descriptor leaf at 440\n428  d1000001  --> unit directory at 42c\n\n               unit directory at 42c\n               -----------------------------------------------------------------\n42c  00046674  directory_length 4, crc 26228\n430  120000a3  specifier id\n434  13000001  version\n438  17000001  model\n43c  81000007  --> descriptor leaf at 458\n\n               descriptor leaf at 440\n               -----------------------------------------------------------------\n440  00055913  leaf_length 5, crc 22803\n444  000050f2  descriptor_type 00, specifier_ID 50f2\n448  80000000\n44c  44696769\n450  64657369\n454  676e0000\n\n               descriptor leaf at 458\n               -----------------------------------------------------------------\n458  0004a6fd  leaf_length 4, crc 42749\n45c  00000000  textual descriptor\n460  00000000  minimal ASCII\n464  44696769  \"Digi\"\n468  20303032  \" 002\"\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/ba0062335c8c4b95f48dfed147085ec03e295449"},{"sha":"693e669857ddc9d34b98bbd18aa98e4b1091bd04","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: firewire-digi00x: handle all MIDI messages on streaming packets\n\nAt a commit 9dc5d31cdceb (\"ALSA: firewire-digi00x: handle MIDI messages in\nisochronous packets\"), a functionality to handle MIDI messages on\nisochronous packet was supported. But this includes some of my\nmisunderstanding. This commit is to fix them.\n\nFor digi00x series, first data channel of data blocks in rx/tx packet\nincludes MIDI messages. The data channel has 0x80 in 8 bit of its MSB,\nhowever it's against IEC 61883-6. Unique data format is applied:\n - Upper 4 bits of LSB represent port number.\n  - 0x0: port 1.\n  - 0x2: port 2.\n  - 0xe: console port.\n - Lower 4 bits of LSB represent the number of included MIDI message bytes;\n   0x0/0x1/0x2.\n - Two bytes of middle of this data channel have MIDI bytes.\n\nEspecially, MIDI messages from/to console surface are also transferred by\nisochronous packets, as well as physical MIDI ports.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/693e669857ddc9d34b98bbd18aa98e4b1091bd04"},{"sha":"dc928847f38dbf3586aea3153ac4248b8a747bc0","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: firewire-digi00x: allow user space applications to read/write MIDI messages for all ports\n\nAt a commit c5fcee0373b3 (\"ALSA: firewire-digi00x: add MIDI operations for\nMIDI control port\"), I described that MIDI messages for control surface is\ntransferred by a different way from the messages for physical ports.\nHowever, this is wrong. MIDI messages to/from all of MIDI ports are\ntransferred by isochronous packets.\n\nThis commit removes codes to transfer MIDI messages via asynchronous\ntransaction, from MIDI handling layer.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/dc928847f38dbf3586aea3153ac4248b8a747bc0"},{"sha":"87a7440e4218c53421d0400b604cb260fb5b8300","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: firewire-digi00x: remove transaction handler for unknown purpose\n\nFor digi00x series, asynchronous transaction is not used to transfer MIDI\nmessages to/from control surface. One of transction handlers in my previous\nwork loses its practical meaning.\n\nThis commit removes the handler. I note that unit of console type\ntransfers 0x00001000 to registered address of host space when switching\nto 'standalone' mode. Then the unit generates bus reset.\n\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/87a7440e4218c53421d0400b604cb260fb5b8300"},{"sha":"012c739a33bac8f3404c583e58e65c21d4e9e50c","author":{"name":"Takashi Sakamoto","email":"df5cd14c20ca9e9623cd2ae7eba41070ac8353e1@sakamocchi.jp"},"message":"ALSA: firewire-motu: remove invalid bitshift for register value\n\nIn protocol version 3, drivers can read current sampling clock status from\nregister 0x'ffff'f000'0b14. 8 bits of LSB of this register represents type\nof signal as source of clock.\n\nCurrent driver code includes invalid bitshift to handle the parameter. This\ncommit fixes the bug.\n\nReported-by: Dan Carpenter <dan.carpenter@oracle.com>\nFixes: 5992e30034c4 (\"ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with protocol version 3\")\nSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","distinct":false,"url":"https://api.github.com/repos/takaswie/snd-firewire-improve/commits/012c739a33bac8f3404c583e58e65c21d4e9e50c"}]}
{"actor":{"display_login":"takaswie"}}