[GIT PULL] Staging/IIO driver patches for 5.8-rc1
The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145:
Linux 5.7-rc7 (2020-05-24 15:32:54 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-5.8-rc1
for you to fetch changes up to 77f55d1305c11fb729b88f2c3f7881ba0831fa6f:
staging: rtl8723bs: Use common packet header constants (2020-05-29 12:36:00
+0200)
Staging/IIO driver patches for 5.8-rc1
Here is the large set of staging and IIO driver changes for 5.8-rc1
Nothing major, but a lot of new IIO drivers are included in here, along
with other core iio cleanups and changes.
On the staging driver front, again, nothing noticable. No new deletions
or additions, just a ton of tiny cleanups all over the tree done by a
lot of different people. Most coding style, but many actual real fixes
and cleanups that are nice to see.
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman
Aiman Najjar (5):
staging: rtl8712: fix checkpatch long-line warning
staging: rtl8712: fix long-line checkpatch warning
staging: rtl8712: fix checkpatch warnings
staging: rtl8712: code improvements to make_wlanhdr
staging: rtl8712: fix multiline derefernce warnings
Aishwarya Ramakrishnan (3):
iio: adc: sun4i-gpadc-iio: Use devm_platform_ioremap_resource
iio: adc: at91-adc: Use devm_platform_ioremap_resource
iio: adc: fsl-imx25-gcq: Use devm_platform_ioremap_resource
Alexandru Ardelean (32):
iio: adc: ad7780: define/use own IIO channel macros
iio: adc: ad7791: define/use own IIO channel macros
iio: adc: ad7793: define/use own IIO channel macros
iio: ad_sigma_delta: remove unused IIO channel macros
iio: buffer: re-introduce bitmap_zalloc() for trialmask
iio: adc: ad7793: use read_avail iio hook for scale available
iio: buffer: drop left-over 'stufftoread' field
include: fpga: adi-axi-common.h: fixup whitespace tab -> space
include: fpga: adi-axi-common.h: add version helper macros
iio: buffer-dmaengine: use %zu specifier for sprintf(align)
iio: buffer-dmaengine: add dev-managed calls for buffer alloc
dt-bindings: iio: adc: add bindings doc for AXI ADC driver
dt-bindings: iio: adc: add bindings doc for AD9467 ADC
iio: buffer: remove 'scan_el_attrs' attribute group from buffer struct
iio: move 'indio_dev->info' null check first in __iio_device_register()
iio: core: drop devm_iio_device_unregister() API call
iio: core: drop devm_iio_triggered_buffer_cleanup() API call
iio: core: drop devm_iio_device_free() API call
iio: core: drop devm_iio_trigger_unregister() API call
iio: core: drop devm_iio_trigger_free() API call
iio: inkern: drop devm_iio_channel_release{_all} API calls
iio: buffer: drop devm_iio_hw_consumer_free() API call
iio: buffer: drop devm_iio_kfifo_free() API call
iio: light: isl29125: fix iio_triggered_buffer_{predisable,postenable}
positions
iio: at91-sama5d2_adc: split at91_adc_current_chan_is_touch() helper
iio: at91-sama5d2_adc: adjust
iio_triggered_buffer_{predisable,postenable} positions
iio: buffer: extend short-hand use for 'indio_dev->buffer'
iio: imu: adis16xxx: use helper to access iio core debugfs dir
iio: hid-sensors: move triggered buffer setup into
hid_sensor_setup_trigger
staging: iio: ad5933: attach life-cycle of kfifo buffer to parent device
and use managed calls throughout
iio: buffer: remove attrcount_orig var from sysfs creation
iio: proximity: ping: pass reference to IIO device as param to ping_read()
Alexandru Lazar (2):
dt-bindings: iio: adc: Add MAX1241 bindings
iio: adc: Add MAX1241 driver
Andreas Klinger (1):
iio: bmp280: fix compensation of humidity
Andy Shevchenko (30):
iio: light: st_uvis25: Drop unneeded casting when print error code
iio: st_sensors: Use dev_get_platdata() to get platform_data
iio: st_sensors: Drop unneeded explicit castings
iio: st_sensors: Drop unneeded casting when print error code
iio: st_sensors: Join string literals back
iio: humidity: hts221: Use dev_get_platdata() to get platform_data
iio: humidity: hts221: Make use of device properties
iio: humidity: hts221: Drop unneeded casting when print error code
iio: adc: intel_mrfld_adc: Use be16_to_cpu() instead of
get_unaligned_be16()
iio: pressure: bmp280: Tolerate IRQ before registering
iio: pressure: bmp280: Convert to use ->read_avail()
iio: pressure: bmp280: Explicitly mark GPIO optional
iio: pressure: bmp280: Drop unneeded explicit castings
iio: pressure: bmp280: Join string literals back
iio: adc: ad_sigma_delta: Use {get,put}_unali
Re: [PATCH v4 08/12] device core: Introduce multiple dma pfn offsets
On Fri, Jun 05, 2020 at 05:26:48PM -0400, Jim Quinlan wrote: > The new field in struct device 'dma_pfn_offset_map' is used to facilitate > the use of single or multiple pfn offsets between cpu addrs and dma addrs. > It subsumes the role of dev->dma_pfn_offset -- a uniform offset. > > The function of_dma_get_range() has been modified to take two additional > arguments: the "map", which is an array that holds the information > regarding the pfn offset regions, and map_size, which is the size in bytes > of the map array. > > of_dma_configure() is the typical manner to set pfn offsets but there are a > number of ad hoc assignments to dev->dma_pfn_offset in the kernel driver > code. These cases now invoke the function > dma_attach_uniform_pfn_offset(dev, pfn_offset). ... > + int ret = dma_attach_uniform_pfn_offset > + (dev, keystone_dma_pfn_offset); It's strange indentation. Have you configured your editor correctly? Seems to me as fit on one line. > + dev_err(dev, "set dma_pfn_offset%08lx%s\n", > + dev->dma_pfn_offset, ret ? " failed" : ""); ... > + *map_size = (num_ranges + 1) * sizeof(**map); > + r = kzalloc(*map_size, GFP_KERNEL); kcalloc() > + if (!r) > + return -ENOMEM; ... > + r->pfn_offset = PFN_DOWN(range.cpu_addr) > + - PFN_DOWN(range.bus_addr); Ditto (indentation). ... > + unsigned long dma_pfn_offset > + = dma_pfn_offset_from_phys_addr(dev, paddr); Ditto. ... > + unsigned long dma_pfn_offset > + = dma_pfn_offset_from_dma_addr(dev, dev_addr); Ditto. Check entire your series for a such, please! -- With Best Regards, Andy Shevchenko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging/IIO driver patches for 5.8-rc1
The pull request you sent on Sun, 7 Jun 2020 15:27:47 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > tags/staging-5.8-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/80ef846e9909f22ccdc2a4a6d931266cecce8b2c Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/3] media: uapi: cedrus: Fix decoding interlaced H264 content
Le samedi 06 juin 2020 à 09:46 -0300, Ezequiel Garcia a écrit : > Hi Jernej, > > On Thu, 4 Jun 2020 at 15:55, Jernej Skrabec wrote: > > Currently H264 interlaced content it's not properly decoded on Cedrus. > > There are two reasons for this: > > 1. slice parameters control doesn't provide enough information > > 2. bug in frame list construction in Cedrus driver > > > > As described in commit message in patch 1, references stored in > > reference lists should tell if reference targets top or bottom field. > > However, this information is currently not provided. Patch 1 adds > > it in form of flags which are set for each reference. Patch 2 then > > uses those flags in Cedrus driver. > > > > Frame list construction is fixed in patch 3. > > > > This solution was extensively tested using Kodi on LibreELEC with A64, > > H3, H5 and H6 SoCs in slightly different form (flags were transmitted > > in MSB bits in index). > > > > So, if I understand correctly the field needs to be passed per-reference, > and the current per-DPB entry is not good? For interlaced content we reference fields separately. That's the reason there is 32 entries in l0/l1. Though, as we decode both fields in the same buffer (interleaved), the DPB indice is not sufficient to inform the decoder what we are referencing. Understand that a top field can be used to decode the next bottom field. This even make sense as they are closer on the capture timeline. This covers slice based decoders. The flags to indicate presence of top/bottom fields in DPB array seems only useful to frame base decoders. This is so that decoder can avoid using lost fields when constructing it's own l0/l1 internally. > > If you could point at the userspace code for this, it would be interesting > to take a look. > > > Note: I'm not 100% sure if flags for both, top and bottom fields are > > needed. Any input here would be welcome. > > > > Given enum v4l2_field is already part of the uAPI, perhaps it makes > sense to just reuse that for the field type? Maybe it's an overkill, > but it would make sense to reuse the concepts and types that > already exist. > > We can still add a reserved field to make this new reference type > extensive. I think it's fine to create new flag for this, as your solution would require extending a reference to 24bit (this patch extend to 16bits). Though indeed, we could combine frame and TOP and reserve more bits for future use. > > Thanks, > Ezequiel > > > > Please take a look. > > > > Best regards, > > Jernej > > > > Jernej Skrabec (3): > > media: uapi: h264: update reference lists > > media: cedrus: h264: Properly configure reference field > > media: cedrus: h264: Fix frame list construction > > > > .../media/v4l/ext-ctrls-codec.rst | 40 ++- > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 27 +++-- > > include/media/h264-ctrls.h| 12 +- > > 3 files changed, 62 insertions(+), 17 deletions(-) > > > > -- > > 2.27.0 > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/3] media: uapi: cedrus: Fix decoding interlaced H264 content
Le dimanche 07 juin 2020 à 16:21 -0400, Nicolas Dufresne a écrit : > Le samedi 06 juin 2020 à 09:46 -0300, Ezequiel Garcia a écrit : > > Hi Jernej, > > > > On Thu, 4 Jun 2020 at 15:55, Jernej Skrabec wrote: > > > Currently H264 interlaced content it's not properly decoded on Cedrus. > > > There are two reasons for this: > > > 1. slice parameters control doesn't provide enough information > > > 2. bug in frame list construction in Cedrus driver > > > > > > As described in commit message in patch 1, references stored in > > > reference lists should tell if reference targets top or bottom field. > > > However, this information is currently not provided. Patch 1 adds > > > it in form of flags which are set for each reference. Patch 2 then > > > uses those flags in Cedrus driver. > > > > > > Frame list construction is fixed in patch 3. > > > > > > This solution was extensively tested using Kodi on LibreELEC with A64, > > > H3, H5 and H6 SoCs in slightly different form (flags were transmitted > > > in MSB bits in index). > > > > > > > So, if I understand correctly the field needs to be passed per-reference, > > and the current per-DPB entry is not good? > > For interlaced content we reference fields separately. That's the > reason there is 32 entries in l0/l1. Though, as we decode both fields > in the same buffer (interleaved), the DPB indice is not sufficient to > inform the decoder what we are referencing. Understand that a top field > can be used to decode the next bottom field. This even make sense as > they are closer on the capture timeline. This covers slice based > decoders. > > The flags to indicate presence of top/bottom fields in DPB array seems > only useful to frame base decoders. This is so that decoder can avoid > using lost fields when constructing it's own l0/l1 internally. > > > If you could point at the userspace code for this, it would be interesting > > to take a look. > > > > > Note: I'm not 100% sure if flags for both, top and bottom fields are > > > needed. Any input here would be welcome. > > > > > > > Given enum v4l2_field is already part of the uAPI, perhaps it makes > > sense to just reuse that for the field type? Maybe it's an overkill, > > but it would make sense to reuse the concepts and types that > > already exist. > > > > We can still add a reserved field to make this new reference type > > extensive. > > I think it's fine to create new flag for this, as your solution would > require extending a reference to 24bit (this patch extend to 16bits). > Though indeed, we could combine frame and TOP and reserve more bits for > future use. Sorry for the oversight, the flags is 16bits, so we already use 24bits. But looking at "enum v4l2_field", which is not a flag, seems like a miss-fit. It would create such a confusion, as V4L2_FIELD_SEQ_TB/BT can still be used with this interface, even though we still need to say if we reference TOP or BOTTOM. Only V4L2_FIELD_ALTERNATE is not supported. But as you can see, "enum v4l2_fiel" is really meant to describe the layout of the interleaved frame rather then signalling a field directly. > > > Thanks, > > Ezequiel > > > > > > > Please take a look. > > > > > > Best regards, > > > Jernej > > > > > > Jernej Skrabec (3): > > > media: uapi: h264: update reference lists > > > media: cedrus: h264: Properly configure reference field > > > media: cedrus: h264: Fix frame list construction > > > > > > .../media/v4l/ext-ctrls-codec.rst | 40 ++- > > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 27 +++-- > > > include/media/h264-ctrls.h| 12 +- > > > 3 files changed, 62 insertions(+), 17 deletions(-) > > > > > > -- > > > 2.27.0 > > > > > > > > > ___ > > > linux-arm-kernel mailing list > > > linux-arm-ker...@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
