- 19 Oct, 2019 3 commits
-
-
Takashi Sakamoto authored
An isoc context for AMDTP stream is flushed to queue packet by a call of pcm.ack. This commit extends this for AMDTP domain. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191018061911.24909-4-o-takashi@sakamocchi.jpSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
An isoc context for AMDTP stream is flushed to queue packet by a call of pcm.pointer. This commit extends this for AMDTP domain. Signed-off-by:
-
Takashi Sakamoto authored
This commit is a preparation to handle several IR/IT contexts in the same domain by tasklet context for one of the IT context. Such IT context is stored to AMDTP domain structure as 'irq_target'. Signed-off-by:
-
- 18 Oct, 2019 12 commits
-
-
Takashi Sakamoto authored
In IEC 61883-1/6, one isoc packet can transfer events up to the value of syt interval. This comes from the interval of isoc cycle. As 1394 OHCI controller can generate hardware IRQ per isoc packet, the interval is calculated as 125 usec. In IEC 61883-1/6, two ways of transmission is described; blocking and non-blocking methods. In blocking method, the sequence of packet includes 'empty' or 'NODATA' packets which include no events. In non-blocking method, the number of events per packet is variable up to the syt interval. This commit uses double of the value of syt interval as minimum available size of PCM period due to the above protocol design. Signed-off-by:
-
Takashi Sakamoto authored
Linux driver for 1394 OHCI controller voluntarily flushes isoc context when total size of accumulated context header reached PAGE_SIZE. This kicks tasklet for the isoc context. This is inconvenient to process runtime of PCM substream. This commit adds a restriction of the maximum size of PCM period to avoid this behaviour. Signed-off-by:
-
Takashi Sakamoto authored
ALSA IEC 61883-1/6 packet streaming engine controls 1394 OHCI controller to generate hardware IRQ for fixed number of isochronous packets (=16) since its first commit. This commit allow the engine to generate it for variable period according to the number of event to handle. For outgoing stream, internal calculator is used to check the accumulated events. For incoming stream, the number of data block in the packet of stream is used to check the accumulated events. When it's unavailable, fixed number of packet roughly calculated in advance is used instead of event counting. Signed-off-by:
-
Takashi Sakamoto authored
This commit allows ALSA fireface driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by:
-
Takashi Sakamoto authored
This commit allows ALSA firewire-motu driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by:
-
Takashi Sakamoto authored
This commit allows ALSA firewire-tascam driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by:
-
Takashi Sakamoto authored
This commit allows ALSA firewire-digi00x driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by:
-
Takashi Sakamoto authored
This commit allows ALSA dice driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by:
-
Takashi Sakamoto authored
This commit allows ALSA oxfw driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by:
-
Takashi Sakamoto authored
This commit allows ALSA fireworks driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by:
-
Takashi Sakamoto authored
This commit allows ALSA bebob driver to share PCM buffer size for both capture and playback PCM substream. When AMDTP domain starts for one of the PCM substream, buffer size of the PCM substream is stores to AMDTP domain structure. Some AMDTP streams have already run with the buffer size when another PCM substream starts, therefore the PCM substream has a constraint to its buffer size. Signed-off-by:
-
Takashi Sakamoto authored
The number of packets in packet buffer has been fixed number (=48) since first commit of ALSA IEC 61883-1/6 packet streaming engine. This commit allows the engine to use variable number of packets in the buffer. The size is calculated by a parameter in AMDTP domain structure surely to store the number of events in the packets of buffer. Although the value of parameter is expected to come from 'period size' parameter of PCM substream, at present 48 is still used. Signed-off-by:
-
- 17 Oct, 2019 17 commits
-
-
Takashi Sakamoto authored
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This commit replaces the check with the substream count and the value for the size of PCM period. Unlike the other drivers in ALSA firewire stack, no MIDI substream is multiplexed into AMDTP stream. I note that Fireface AMDTP protocol has a quirk that tx stream includes blank isochronous cycle. The packet for blank cycle is equivalent to empty or NODATA packet in IEC 61883-6, thus the protocol is similar to blocking transmission method of IEC 61883-6. On the other hand, rx stream adopts non-blocking transmission method. Although the difference of transmission method between tx/rx streams precisely brings different timing for a certain amount of events due to their different calculation for data blocks per packet, it's possible to approximate enough amount of events mostly has the same timing. Actually current ALSA IEC 61883-1/6 engine uses large amount of data blocks for each hardware IRQ (=16 packets). Signed-off-by:
-
Takashi Sakamoto authored
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by:
-
Takashi Sakamoto authored
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This commit replaces the check with the substream count and the value for the size of PCM period. Unlike the other drivers in ALSA firewire stack, no MIDI substream is multiplexed into AMDTP stream. Signed-off-by:
-
Takashi Sakamoto authored
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. I note that DOT AMDTP protocol has a quirk to use different transmission method of IEC 61883-6 for tx/rx streams; non-blocking in tx stream and blocking in rx stream. Although the difference of transmission method between tx/rx streams precisely brings different timing for a certain amount of events due to their different calculation for data blocks per packet, it's possible to approximate enough amount of events mostly has the same timing. Actually current ALSA IEC 61883-1/6 engine uses large amount of data blocks for each hardware IRQ (=16 packets). Signed-off-by:
-
Takashi Sakamoto authored
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Dice hardware has a quirk called as 'Dual Wire'. For a case of higher sampling transmission frequency, this commit performs calculations between the number of PCM frames and the number of events in AMDTP stream. Signed-off-by:
-
Takashi Sakamoto authored
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by:
-
Takashi Sakamoto authored
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by:
-
Takashi Sakamoto authored
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by:
-
Takashi Sakamoto authored
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by:
-
Takashi Sakamoto authored
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by:
-
Takashi Sakamoto authored
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by:
-
Takashi Sakamoto authored
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by:
-
Takashi Sakamoto authored
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by:
-
Takashi Sakamoto authored
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by:
-
Takashi Sakamoto authored
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by:
-
Takashi Sakamoto authored
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by:
-
Takashi Sakamoto authored
In IEC 61883-6, it's called as 'event' what has presentation time represented by timestamp in CIP header. Although the ratio of the number of event against the number of data block is different depending on event data type represented by the specific field in CIP header, it's just one in the most cases supported by ALSA IEC 61883-1/6 engine. In 1394 OHCI specification, applications can schedule hardware IRQ by configuring descriptor with IRQ flag for packet against each isochronous cycle. For future commit, I use the hardware IRQ for isoc IT context to acknowledge the elapse of PCM period for both playback/capture directions on AMDTP streams in the same domain. This commit is a preparation for the above idea. This commit adds a member into AMDTP domain structure to record the number of PCM frames. Signed-off-by:
-
- 07 Oct, 2019 1 commit
-
-
Krzysztof Kozlowski authored
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by:Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20191004144931.3851-1-krzk@kernel.orgSigned-off-by:
-
- 06 Oct, 2019 4 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
In commit 4ed28639 ("fs, elf: drop MAP_FIXED usage from elf_map") we changed elf to use MAP_FIXED_NOREPLACE instead of MAP_FIXED for the executable mappings. Then, people reported that it broke some binaries that had overlapping segments from the same file, and commit ad55eac7 ("elf: enforce MAP_FIXED on overlaying elf segments") re-instated MAP_FIXED for some overlaying elf segment cases. But only some - despite the summary line of that commit, it only did it when it also does a temporary brk vma for one obvious overlapping case. Now Russell King reports another overlapping case with old 32-bit x86 binaries, which doesn't trigger that limited case. End result: we had better just drop MAP_FIXED_NOREPLACE entirely, and go back to MAP_FIXED. Yes, it's a sign of old binaries generated with old tool-chains, but we do pride ourselves on not breaking existing setups. This still leaves MAP_FIXED_NOREPLACE in place for the load_elf_interp() and the old load_elf_library() use-cases, because nobody has reported breakage for those. Yet. Note that in all the cases seen so far, the overlapping elf sections seem to be just re-mapping of the same executable with different section attributes. We could possibly introduce a new MAP_FIXED_NOFILECHANGE flag or similar, which acts like NOREPLACE, but allows just remapping the same executable file using different protection flags. It's not clear that would make a huge difference to anything, but if people really hate that "elf remaps over previous maps" behavior, maybe at least a more limited form of remapping would alleviate some concerns. Alternatively, we should take a look at our elf_map() logic to see if we end up not mapping things properly the first time. In the meantime, this is the minimal "don't do that then" patch while people hopefully think about it more. Reported-by:
Russell King <linux@armlinux.org.uk> Fixes: 4ed28639 ("fs, elf: drop MAP_FIXED usage from elf_map") Fixes: ad55eac7 ("elf: enforce MAP_FIXED on overlaying elf segments") Cc: Michal Hocko <mhocko@suse.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.infradead.org/users/hch/dma-mappingLinus Torvalds authored
Pull dma-mapping regression fix from Christoph Hellwig: "Revert an incorret hunk from a patch that caused problems on various arm boards (Andrey Smirnov)" * tag 'dma-mapping-5.4-1' of git://git.infradead.org/users/hch/dma-mapping: dma-mapping: fix false positive warnings in dma_common_free_remap()
-
git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "A few fixes this time around: - Fixup of some clock specifications for DRA7 (device-tree fix) - Removal of some dead/legacy CPU OPP/PM code for OMAP that throws warnings at boot - A few more minor fixups for OMAPs, most around display - Enable STM32 QSPI as =y since their rootfs sometimes comes from there - Switch CONFIG_REMOTEPROC to =y since it went from tristate to bool - Fix of thermal zone definition for ux500 (5.4 regression)" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: multi_v7_defconfig: Fix SPI_STM32_QSPI support ARM: dts: ux500: Fix up the CPU thermal zone arm64/ARM: configs: Change CONFIG_REMOTEPROC from m to y ARM: dts: am4372: Set memory bandwidth limit for DISPC ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage() ARM: OMAP2+: Add missing LCDC midlemode for am335x ARM: OMAP2+: Fix missing reset done flag for am3 and am43 ARM: dts: Fix gpio0 flags for am335x-icev2 ARM: omap2plus_defconfig: Enable more droid4 devices as loadable modules ARM: omap2plus_defconfig: Enable DRM_TI_TFP410 DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again ARM: dts: Fix wrong clocks for dra7 mcasp clk: ti: dra7: Fix mcasp8 clock bits
-
- 05 Oct, 2019 3 commits
-
-
Linus Torvalds authored
Merge tag 'kbuild-fixes-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - remove unneeded ar-option and KBUILD_ARFLAGS - remove long-deprecated SUBDIRS - fix modpost to suppress false-positive warnings for UML builds - fix namespace.pl to handle relative paths to ${objtree}, ${srctree} - make setlocalversion work for /bin/sh - make header archive reproducible - fix some Makefiles and documents * tag 'kbuild-fixes-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kheaders: make headers archive reproducible kbuild: update compile-test header list for v5.4-rc2 kbuild: two minor updates for Documentation/kbuild/modules.rst scripts/setlocalversion: clear local variable to make it work for sh namespace: fix namespace.pl script to support relative paths video/logo: do not generate unneeded logo C files video/logo: remove unneeded *.o pattern from clean-files integrity: remove pointless subdir-$(CONFIG_...) integrity: remove unneeded, broken attempt to add -fshort-wchar modpost: fix static EXPORT_SYMBOL warnings for UML build kbuild: correct formatting of header in kbuild module docs kbuild: remove SUBDIRS support kbuild: remove ar-option and KBUILD_ARFLAGS
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Twelve patches mostly small but obvious fixes or cosmetic but small updates" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: qla2xxx: Fix Nport ID display value scsi: qla2xxx: Fix N2N link up fail scsi: qla2xxx: Fix N2N link reset scsi: qla2xxx: Optimize NPIV tear down process scsi: qla2xxx: Fix stale mem access on driver unload scsi: qla2xxx: Fix unbound sleep in fcport delete path. scsi: qla2xxx: Silence fwdump template message scsi: hisi_sas: Make three functions static scsi: megaraid: disable device when probe failed after enabled device scsi: storvsc: setup 1:1 mapping between hardware queue and CPU queue scsi: qedf: Remove always false 'tmp_prio < 0' statement scsi: ufs: skip shutdown if hba is not powered scsi: bnx2fc: Handle scope bits when array returns BUSY or TSF
-
Linus Torvalds authored
This makes getdents() and getdents64() do sanity checking on the pathname that it gives to user space. And to mitigate the performance impact of that, it first cleans up the way it does the user copying, so that the code avoids doing the SMAP/PAN updates between each part of the dirent structure write. I really wanted to do this during the merge window, but didn't have time. The conversion of filldir to unsafe_put_user() is something I've had around for years now in a private branch, but the extra pathname checking finally made me clean it up to the point where it is mergable. It's worth noting that the filename validity checking really should be a bit smarter: it would be much better to delay the error reporting until the end of the readdir, so that non-corrupted filenames are still returned. But that involves bigger changes, so let's see if anybody actually hits the corrupt directory entry case before worrying about it further. * branch 'readdir': Make filldir[64]() verify the directory entry filename is valid Convert filldir[64]() from __put_user() to unsafe_put_user()
-
