net: ieee8021541: bcfserial: Increase the number of retries for hdlc #277
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Confine the memory map changes into a separate rtos-memory-map.dts which describes the common memory map for all RTOS remoteprocs. vision-apps.dtbo uses this and also disables capture and display related peripherals from Linux so that it can be used by RTOS. edgeai-apps.dtbo expects these devices to be owned by linux, so it uses the rtos-memory-map customization only. Signed-off-by: Nikhil Devshatwar <[email protected]>
Signed-off-by: Keerthy <[email protected]>
…ffers while joing v4l2 job_abort. This patch does the fulsh operation by releasing all the locked up buffers in the driver. It throws the v4l2 harmless traces while trying to re-release the released buffers. Signed-off-by: Prashanth Kumar Amai <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
sfjro/aufs-standalone@2c2dfeb Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
statropy/wpanusb@251f016 Signed-off-by: Robert Nelson <[email protected]>
statropy/bcfserial@aded884 Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
cifsd-team/ksmbd@133175a Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Reference: v5.10.157 Signed-off-by: Robert Nelson <[email protected]>
Reference: v5.15.81 Signed-off-by: Robert Nelson <[email protected]>
Reference: v6.0.11 Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Reference: v5.11.22 Signed-off-by: Robert Nelson <[email protected]>
Reference: v5.11.22 Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Add a runtime interface to using configfs for generic device tree overlay usage. With it its possible to use device tree overlays without having to use a per-platform overlay manager. Please see Documentation/devicetree/configfs-overlays.txt for more info. Changes since v6: - Default groups properties API changed. Changes since v5: - New style configfs. Changes since v4: - Loading fix for multiple overlays as found out by Geert Uytterhoeven <[email protected]> Changes since v3: - Fixed compilation on SPARC & Xtensa Changes since v2: - Removed ifdef CONFIG_OF_OVERLAY (since for now it's required) - Created a documentation entry - Slight rewording in Kconfig Changes since v1: - of_resolve() -> of_resolve_phandles(). Signed-off-by: Pantelis Antoniou <[email protected]> [geert: Use %zu to format size_t] [geert: Rebase to v4.15-rc1] [geert: Make cfs_overlay_item_dtbo_{read,write}() and of_cfs_overlay_group static] [geert: Let OF_CONFIGFS select OF_FLATTREE to fix sparc all*config] [geert: Spelling/grammar s/rationalle of/rationale for/] [geert: Rebase on top of commit 39a751a ("of: change overlay apply input data from unflattened to FDT") Signed-off-by: Geert Uytterhoeven <[email protected]>
We are going to need the overlays to appear on sysfs with runtime global properties (like master enable) so turn them into kobjects. They have to be in sysfs so that people can have information about the overlays applied in the system, i.e. where their targets are and whether removal is possible. In a future more attributes can be added in a backwards compatible manner. Signed-off-by: Pantelis Antoniou <[email protected]> [geert: Rebase to v4.15-rc1] [Fengguang Wu: Make overlay_changeset_release() static] [geert: Rebase on top of commit 39a751a ("of: change overlay apply input data from unflattened to FDT") Signed-off-by: Geert Uytterhoeven <[email protected]>
A throw once master enable switch to protect against any further overlay applications if the administrator desires so. A kernel command line option is provided as well. Signed-off-by: Pantelis Antoniou <[email protected]>
Documentation ABI entry for overlays sysfs entries. Signed-off-by: Pantelis Antoniou <[email protected]>
This takes a leaf from drivers/gpu/drm/rockchip/rockchip_rgb.c This is a bit of a chicken or hen issue at this point. when the call chain looks like this: tidss_atomic_check drm_atomic_check_only drm_atomic_commit drm_client_modeset_commit_atomic drm_client_modeset_commit_locked drm_client_modeset_commit drm_fb_helper_set_par fbcon_init visual_init The bridge_attach is invoked, but bridge_enable is NOT invoked yet, at this stage, we cannot really confirm the display format. So, it begs the question - what do others do? why do they work? Signed-off-by: Nishanth Menon <[email protected]>
Hotplug events reported by bridge drivers over drm_bridge_hpd_notify() get ignored unless somebody calls drm_bridge_hpd_enable(). When the connector for the bridge is bridge_connector, such a call is done from drm_bridge_connector_enable_hpd(). However drm_bridge_connector_enable_hpd() is never called on init paths, documentation suggests that it is intended for suspend/resume paths. In result, once encoders are switched to bridge_connector, bridge-detected HPD stops working. This patch adds a call to that API on init path. This fixes HDMI HPD with rcar-du + adv7513 case when adv7513 reports HPD events via interrupts. Fixes: c24110a ("drm: rcar-du: Use drm_bridge_connector_init() helper") Signed-off-by: Nikita Yushchenko <[email protected]> Signed-off-by: Paul Cercueil <[email protected]> Tested-by: Kieran Bingham <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Hardcode LED configuration for LED2 signal to be link status and LED0 signal to be rx/tx Signed-off-by: Nishanth Menon <[email protected]>
current_link_freq field in ov5640_dev structure is link frequency, not link frequency array index, so correct it. Fixes: 3c28588 ("media: ov5640: Update pixel_rate and link_freq") Signed-off-by: Guoniu.zhou <[email protected]> Acked-by: Jacopo Mondi <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> (cherry picked from commit d7b4119) Signed-off-by: Nishanth Menon <[email protected]>
In commit 3145efc ("media: ov5640: Rework timings programming"), it defines max_fps field in ov5640_mode_info structure to store maximum frame rate supported by each mode. But in ov5640_try_frame_interval(), it assumes the maximum frame rate supported by all modes is 60. But actually, only VGA support it. For others, the maximum frame rate supported is 30. So correct it by taking the maximum frame rate supported by each mode as the initialization value of the local variable maxfps. Signed-off-by: Guoniu.zhou <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> (cherry picked from commit f33b56d) Signed-off-by: Nishanth Menon <[email protected]>
OV5640 Datasheet[1] Figures 2-3 and 2-4 indicate the timing sequences that is expected during various initialization steps. Note the t4 >= 20ms, delay from RESETB pull high to SCCB initialization As indicated in section 2.8, the RESETB assertion can either be via external pin control OR via the register 0x3008 bit 7. The initialization sequence asserts bit7, but on deassert, we do not wait for the reset delay. [1] https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf Fixes: 19a81c1 ("[media] add Omnivision OV5640 sensor driver") Signed-off-by: Nishanth Menon <[email protected]>
OV5640 Datasheet[1] Figures 2-3 and 2-4 indicate the timing sequences that is expected during various initialization steps. Note the power on time includes t0 + t1 + t2 >= 5ms, delay for poweron. As indicated in section 2.8, the RESETB assertion can either be via external pin control OR via the register 0x3008 bit 6 (see table 7-1 in [1]) [1] https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf Fixes: 19a81c1 ("[media] add Omnivision OV5640 sensor driver") Signed-off-by: Nishanth Menon <[email protected]>
Some RPi-compatible module manufacturers [1] don't expose the RESETB gpio of the sensor directly through the connector. Instead wiring ~PWDN as a proxy reset with appropriate delays. In such cases, reset_gpio will not be available to the driver, but it will still be toggled when the sensor is powered on, and thus we should still honor the wait time of >= 5ms + 1ms + 20ms [2] before attempting any i/o operations over SCCB. [1] https://digilent.com/reference/_media/reference/add-ons/pcam-5c/pcam_5c_sch.pdf [2] https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf Signed-off-by: Jai Luthra <[email protected]>
Reference: v6.0.11 Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
5.10.153-ti-arm64-r82 bb.org_defconfig 5.10 TI Delta: RobertCNelson/ti-linux-kernel@8b51d20...3eee621 AUFS: sfjro/aufs-standalone@2c2dfeb BBDTBS: https://git.beagleboard.org/beagleboard/BeagleBoard-DeviceTrees/-/commit/96c2eeb3f529435e79b845525e00dee5216a7d0c RT: patch-5.10.153-rt76.patch.xz WPANUSB: statropy/wpanusb@251f016 BCFSERIAL: statropy/bcfserial@aded884 WIRELESS_REGDB: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=fe05cc94e070c71486047002fc2edf68f5f2a07a KSMBD: cifsd-team/ksmbd@133175a Signed-off-by: Robert Nelson <[email protected]>
During initialization the CC1352 FW will be in a loop looking for HDLC ACK and FW response is very slow, but currently bcfserial driver expects the CC1352 to respond within 5 ms, but the CC1352 takes few 100 ms to complete this operation, thus keep the retry count to a high value so that the probe failure does not happen due to failling the bcfserial_get_device_capabilities() call.This is a one-time setup delay during probe() and does not affect performance. Signed-off-by: Vaishnav Achath <[email protected]>
RobertCNelson
added a commit
to RobertCNelson/ti-linux-kernel-dev
that referenced
this pull request
Dec 17, 2022
…r hdlc fixes: beagleboard/linux#277 Signed-off-by: Robert Nelson <[email protected]>
RobertCNelson
force-pushed
the
5.10-arm64
branch
2 times, most recently
from
532deb0 to
73b7baf
Compare
RobertCNelson
force-pushed
the
5.10-arm64
branch
2 times, most recently
from
d4ab3f1 to
11ebcc0
Compare
RobertCNelson
force-pushed
the
5.10-arm64
branch
8 times, most recently
from
eb98542 to
6362564
Compare
RobertCNelson
force-pushed
the
5.10-arm64
branch
2 times, most recently
from
7436779 to
5a62bb1
Compare
RobertCNelson
force-pushed
the
5.10-arm64
branch
from
5a62bb1 to
043bc40
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
During initialization the CC1352 FW will be in a loop looking for HDLC ACK and FW response is very slow, but currently bcfserial driver expects the CC1352 to respond within 50 ms, but the CC1352 takes few 100 ms to complete this operation, thus keep the retry count to a high value so that the probe failure does not happen due to failling the bcfserial_get_device_capabilities() call.This is a one-time setup delay during probe() and does not affect performance.
Signed-off-by: Vaishnav Achath [email protected]