CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
Both PREEMPT and PREEMPT_RT require the same functionality which today
depends on CONFIG_PREEMPT.
Switch the Kconfig dependency to CONFIG_PREEMPTION.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The request API documentation introduced a new section which should have
been a subsection. Fix this.
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Alexandre Courbot <gnurou@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Pass the v4l2-ctl configuration for the imx6q-sabreauto PAL
example for completeness and consistency.
Suggested-by: Steve Longerbeam <slongerbeam@gmail.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Steve Longerbeam <slongerbeam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The i.MX6DL sabreauto has different numbering on the I2C bus and
I2C muxes compared to the i.MX6Q as shown in the kernel log below:
[ 5.159423] imx-media: ipu1_csi0_mux:5 -> ipu1_csi0:0
[ 5.164618] imx-media: ipu1_csi1_mux:5 -> ipu1_csi1:0
[ 5.169953] imx-media: adv7180 4-0021:0 -> ipu1_csi0_mux:4
To avoid confusion, add an entry that shows how to setup the links and
configure the pads that are specific to the i.MX6DL sabreauto.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Steve Longerbeam <slongerbeam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
In the i.MX6Q sabreauto pipeline example, it is better to provide
a real example for the output format, so do it just like in the
previous lines for consistency.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Steve Longerbeam <slongerbeam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Improve the documentation by specifying that the instructions
are related to the i.MX6Q sabreauto variant.
This avoids confusion if someone follows these steps on a i.MX6DL
sabreauto, which has different numbering on the I2C bus and
I2C muxes.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Steve Longerbeam <slongerbeam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Don't populate the array 'cri' on the stack but instead make it
static and const. Makes the object code smaller by 165 bytes.
Turn the 2nd parameter of 'log_infoframe()' const accordingly.
Before:
text data bss dec hex filename
98533 20024 256 118813 1d01d drivers/media/i2c/adv7842.o
After:
text data bss dec hex filename
98304 20088 256 118648 1cf78 drivers/media/i2c/adv7842.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The variable ret is being initialized with a value that
is never read and is being re-assigned a little later on. The
assignment is redundant and hence can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
There appears to be a copy-paste error on the access of
csc_coeffs.y2r.r601.full.coeff, I believe csc_coeffs.2yr.r601.full.coeff
should be used instead. This is a moot point as the code is never
reached, but at least use the correct structure element.
Addresses-Coverity: ("Copy-paste error")
Fixes: 3ff3a712a9 ("media: ti-vpe: vpe: don't rely on colorspace member for conversion")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Currently the "chip found" message is shown even in the case where the
I2C address is wrongly passed in the device tree, or also in the case of
probe failure, which is misleading.
To avoid such problem, move this message after real I2C transactions
have been successfully made and we are certain that the adv7180 is
really present and probed.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
In af9005_identify_state when returning -EIO the allocated buffer should
be released. Replace the "return -EIO" with assignment into ret and move
deb_info() under a check.
Fixes: af4e067e1d ("V4L/DVB (5625): Add support for the AF9005 demodulator from Afatech")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Drivers that use the CEC pin framework have no way of processing messages
themselves by providing the 'received' callback. This is present in
cec_ops, but not in cec_pin_ops.
Add support for this callback.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Sometimes it detects a weird resolution such as 1024x287 when the
actual resolution is 1024x768. To resolve such an issue, this
commit adds clearing for hsync and vsync polarity register bits
at the beginning of the first mode detection. This is recommended
in the datasheet.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To prevent inaccurate detections of resolution, this commit enables
clearing of hsync/vsync polarity bits based on probed sync state.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Fix __cpuidle_set_driver() to check if any of the CPUs in the mask has
a driver different from drv already and, if so, return -EBUSY before
updating any cpuidle_drivers per-CPU pointers.
Fixes: 82467a5a88 ("cpuidle: simplify multiple driver support")
Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
[ rjw: Subject & changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This introduces support for HEVC/H.265 to the Cedrus VPU driver, with
both uni-directional and bi-directional prediction modes supported.
Field-coded (interlaced) pictures, custom quantization matrices and
10-bit output are not supported at this point.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Document the current state of the HEVC slice pixel format.
The format will need to evolve in the future, which is why it is
not part of the public API.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
This introduces the required definitions for HEVC decoding support with
stateless VPUs. The controls associated to the HEVC slice format provide
the required meta-data for decoding slices extracted from the bitstream.
They are not exported to the public V4L2 API since reworking this API
will likely be needed for covering various use-cases and new hardware.
Multi-slice decoding is exposed as a valid decoding mode to match current
H.264 support but it is not yet implemented.
The interface comes with the following limitations:
* No custom quantization matrices (scaling lists);
* Support for a single temporal layer only;
* No slice entry point offsets support;
* No conformance window support;
* No VUI parameters support;
* No support for SPS extensions: range, multilayer, 3d, scc, 4 bits;
* No support for PPS extensions: range, multilayer, 3d, scc, 4 bits.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
[hverkuil-cisco@xs4all.nl: use 1ULL in flags defines in hevc-ctrls.h]
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
DIV_ROUND_UP's first argument doesn't need to be wrapped in parenthesis
since that is already being taken care of in the macro's definition.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
We need to shift and mask values at different occasions to fill up
cedrus registers. This was done using macros that don't explicitly
treat arguments as unsigned, leading to possibly undefined behavior.
Introduce the SHIFT_AND_MASK_BITS macro and use it where possible.
In cases where it doesn't apply as-is, explicitly cast to unsigned
instead.
This macro should be moved to include/linux/bits.h eventually.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
This series of changes continues dropping legacy platform data for
omaps. With the proper device tree configuration in place in the dts
files for ti-sysc interconnect target module driver, we can drop the
related platform data and legacy ti,hwmods custom property.
Most of the patches in this series drop platform data and custom dts
property one device class and one SoC at time. This way we can easily
revert one patch at a time in case of unexpected issues if the fix is
not trivial.
For am335x musb, we need to first update the device tree to probe with
ti-sysc interconnect target module driver. And then the following
patches drop the legacy platform data.
Note that this series depends on earlier ti-sysc related driver changes
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAl2x0l4RHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXOp8RAAsH06SXYuMUukfhFP9qHfqeGP7XYOkFyB
mWuEtAwmW6A2HrB1+a/PbhYlYn2wR/0QKOLQ3/jPs072WASQGS+c8Z0zPISoCOjp
bROnnzWcVQqKQoQAxQnR221chyF1ODPjV6gywyYnDOoSaRTQTmgcBfHLyopD/PV3
yNM315tr4IGe3vT0CNgPBrtKxd3KHR7d5jVNWceyxj0b/arrSx6K176hY1cG9zHD
TIEBWr2GoJlrhqz/u+Bu+updOrBoFg1w6r6ACyhjBx2+42NFQ8Z0mSUHdUfevKpF
jhipeIuIXHymF9eBs7erl38AfFxplAJSbwKagnVWNzT+IyLGpIoKGvK3YKg/1aSu
VuTKT2i47zVEpqi9Goe+yxLeuO4VZE7fKJQIZ4PtkUeCD9FjN79pOC895mZPan/K
uvs6eJCL+z1XmpK6OVQ37zTAnsmT0EdGfUerncOJeFy+xpclkDRq+Y4BBwsuckOE
0bxK4R73ryI68RoezFKmdiaaCND9Yl2pLtXxu8AMhoSVL4jWdsiSGRK8wgIUNnJk
dAuoHXqdlwxo7DqdnEDtmuDLRO+TNPdxBnIF8jFF5C0sJ3WexC0jNqqC678DEOyF
OnEoo5xKL6XrlSfUId1uts+KmB8qzGqtJ39znqq8A/eDKzwlM9dTiOgvrEa407+e
bg3hHeLj5iM=
=FUNk
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v5.5/ti-sysc-drop-pdata-v2-signed-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/dt
Drop legacy platform data for omaps for v5.5
This series of changes continues dropping legacy platform data for
omaps. With the proper device tree configuration in place in the dts
files for ti-sysc interconnect target module driver, we can drop the
related platform data and legacy ti,hwmods custom property.
Most of the patches in this series drop platform data and custom dts
property one device class and one SoC at time. This way we can easily
revert one patch at a time in case of unexpected issues if the fix is
not trivial.
For am335x musb, we need to first update the device tree to probe with
ti-sysc interconnect target module driver. And then the following
patches drop the legacy platform data.
Note that this series depends on earlier ti-sysc related driver changes
* tag 'omap-for-v5.5/ti-sysc-drop-pdata-v2-signed-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (40 commits)
ARM: OMAP2+: Drop legacy platform data for am335x musb
ARM: dts: Drop pointless status changing for am3 musb
ARM: dts: Probe am335x musb with ti-sysc
ARM: OMAP2+: Drop legacy platform data for musb on omap4
ARM: OMAP2+: Drop legacy platform data for omap4 mcasp
ARM: OMAP2+: Drop legacy platform data for am3 and am4 mcasp
ARM: OMAP2+: Drop legacy platform data for dra7 rng
ARM: OMAP2+: Drop legacy platform data for am3 and am4 rng
ARM: OMAP2+: Drop legacy platform data for omap4 hdq1w
ARM: OMAP2+: Drop legacy platform data for dra7 hdq1w
ARM: OMAP2+: Drop legacy platform data for am4 hdq1w
ARM: OMAP2+: Drop legacy platform data for omap5 mcbsp
ARM: OMAP2+: Drop legacy platform data for omap4 mcbsp
ARM: OMAP2+: Drop legacy platform data for omap5 wdt
ARM: OMAP2+: Drop legacy platform data for dra7 wdt
ARM: OMAP2+: Drop legacy platform data for am3 and am4 wdt
ARM: dts: Drop custom hwmod property for omap5 mmc
ARM: dts: Drop custom hwmod property for am4 mmc
ARM: dts: Drop custom hwmod property for am3 mmc
ARM: dts: Drop custom hwmod property for omap5 i2c
...
Link: https://lore.kernel.org/r/pull-1571934890-285615@atomide.com-3
Signed-off-by: Olof Johansson <olof@lixom.net>
This series of changes adds support for few new boards, moves
remaining ti wilink bluetooth users to use the serdev driver,
and improves support for existing devices:
- Add support for NetCAN Plus devices
- Configure wilink bluetooth for logicpd-torpedo and omap3-igep
- Switch to using generic LCD panel for logicpd-torpedo and
increase camera pixel clock
- Configure droid4 for 300mA USB host mode and move to a common file
to start adding support for droid bionic
- Rename ocmcram node to sram
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAl2xz34RHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXP7UBAA07dGQrlE9JroNSOsdEK5I3vpd27QQ08+
ESvErr5INTt0ePAPsqN7agxc66eDhyElm0BYouS9MOWOax/obCNo2WSVqXrf0Msi
+Ge7mzHNoI1M6j+z8zbMwLuAaLSfvkdEspxAXkK8SQUjZcvg7gIsH/s2MNB5bvYO
kr+SGel2n1Mx+tP+UQvu94q4MT1zMlDApPpBFzBVZg5uNKYBanlMqnS0c/FPVzR6
BU56WfV6toX7AjcIIHn0Okmlnh3c0DDursrpFswWhH7+AM9XUgy9ygdsVYSbTRfg
BSCE3vV9aL8c8eyZ7GGuNMw5kGLc1q2VUh0rJnVYFzJy4nl8AufDw4ABVPgJGQ3l
UCrUQm8ZPaHwngQCgRax9iJuymEwVCLIPB96+Wfb/VTC5BlwMcUl68atcRgyMeGG
V6zPOPfRivV98r9znOhAjN+eW2vzSCwixWoqZna5yp7wvBUPqP3u6C9hQZxOzn+i
cu9dMpeYLSf0GDQo/SXHGW/gMf0bzWg2giFMC/WgEeUtdrasbRjYvUzIV5dZZAvY
a+LkhsoSeT4VFm+OGKRNozfhEb6kMqkV6tOHPtBljxWpRswWdCKrq2eenI+kyU4K
tNO5jIqaVIqBDTXT4J6J9m5W2j/lViYr1doFu0hJ3mbKy9j1M1LCCacCAcwYoAU8
LSH/xj0EVyc=
=Gllx
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v5.5/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/dt
Device tree changes for omaps for v5.5
This series of changes adds support for few new boards, moves
remaining ti wilink bluetooth users to use the serdev driver,
and improves support for existing devices:
- Add support for NetCAN Plus devices
- Configure wilink bluetooth for logicpd-torpedo and omap3-igep
- Switch to using generic LCD panel for logicpd-torpedo and
increase camera pixel clock
- Configure droid4 for 300mA USB host mode and move to a common file
to start adding support for droid bionic
- Rename ocmcram node to sram
* tag 'omap-for-v5.5/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: add DTS for NetCom Plus 4xx and 8xx device series
ARM: dts: add DTS for NetCom Plus 1xx and 2xx device series
ARM: dts: add DTS for NetCAN Plus devices
ARM: dts: omap: Rename "ocmcram" node to "sram"
ARM: dts: logicpd-torpedo-37xx-devkit: Increase camera pixel clock
ARM: dts: am: Rename "ocmcram" node to "sram"
ARM: dts: logicpd-torpedo: Disable Bluetooth Serial DMA
ARM: dts: IGEP: Add WiLink UART node
ARM: dts: LogicPD Torpedo: Add WiLink UART node
ARM: dts: logicpd-torpedo-37xx-devkit-28: Reference new DRM panel
ARM: dts: logicpd-torpedo-baseboard: Reduce video regulator chatter
ARM: dts: Add minimal support for Droid Bionic xt875
ARM: dts: omap4-droid4: Allow 300mA current for USB peripherals
ARM: dts: Use level interrupt for omap4 & 5 wlcore
Link: https://lore.kernel.org/r/pull-1571934890-285615@atomide.com-2
Signed-off-by: Olof Johansson <olof@lixom.net>
This series of changes contains SoC related clean-up, and some PM
improvments:
- SoC clean-up to drop unused enable_wakeup and disable_wakeup,
simplify clkdm_clock_enable and disable, and few sparse fixes
- Drop pdata-quirks for TI bluetooth, this is now handled by a serdev
driver
- A series of PM changes to re-enable core oswr (open switch retention)
for omap4 that got disabled earlier because of various gpio-omap issues
that have been fixed earlier this year. We want to do this in small
steps for the pwrdm_set_logic_retst() changes so we can identify the
domain in case of unexpected issues
- A series of PM changes to configure voltage controller for droid4.
Eventually the voltage controller configuration should use device tree,
but we want to get things working first. These changes bring down
down the idle power consumption for droid4 with LCD blanked, WLAN
connected, USB disabled, and modem disabled to about 32 to 35mW from
about 39 to 45 mW
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAl2xzA0RHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXOKgRAAwN1GcY/QGIJyPJFzMpMIiHGnwpF31jDi
nPVYOrz5JdkH5qB0PNagSNeYI8OmSBSBnwVjq9hMBksbSTdCuXZ9oLAVPvewqDlL
UPFodfNHFSWVl/N7VGFYb4AFg4kKITsgmFfbj9QhJJFeMLjgTvo6Oon2APyj7nw7
JbDSySZxbow8b90OWoa6nWrpzWFY/gRn41V+olZMtAy+smAZ4DRqCoOVf5bmjWYw
M2iTGNHvVIAGGdPw8XiiAfjmr9WTK2k1ap1S6C2pAXpuPX52M72Um3BxSimnZcvi
Qp04HDNoQyXfHJsOAPSrG7oQubR6bguTb6wwhnAXEu7FqVzFWjsE2zDfpYcnZtK8
748wZd5e48UQvVG1xmjFxlzt67DZJ8BM93zVPwGeHIZf1vvAqtPggvxLp7qzI58P
OUZSAB3/WPniRlJkJz3zsBaFGj/ryUknyLoKg/ErDM3KoTx2KPOAM5rNCbukyxRi
zDTENjc0yRY55atSBp3dlD76dMwGAvrwKSnKsXmKOaqLb6IcrEznCCrvWuL3KB3Q
5KeU/mKeJZN0Y8EuFPyutA/DQmhS8wvku5J8ZPoMfqNfDONDknkysSN8ssQQ7QDx
fN6MEnMxqK3W3rtlxs6ImstsMSruPttLksHzbUeIHwDOuz2ghpTgCdcSZD3woWCk
nC1e+xfAelo=
=+lr8
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v5.5/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/soc
SoC changes for omaps for v5.5
This series of changes contains SoC related clean-up, and some PM
improvments:
- SoC clean-up to drop unused enable_wakeup and disable_wakeup,
simplify clkdm_clock_enable and disable, and few sparse fixes
- Drop pdata-quirks for TI bluetooth, this is now handled by a serdev
driver
- A series of PM changes to re-enable core oswr (open switch retention)
for omap4 that got disabled earlier because of various gpio-omap issues
that have been fixed earlier this year. We want to do this in small
steps for the pwrdm_set_logic_retst() changes so we can identify the
domain in case of unexpected issues
- A series of PM changes to configure voltage controller for droid4.
Eventually the voltage controller configuration should use device tree,
but we want to get things working first. These changes bring down
down the idle power consumption for droid4 with LCD blanked, WLAN
connected, USB disabled, and modem disabled to about 32 to 35mW from
about 39 to 45 mW
* tag 'omap-for-v5.5/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (24 commits)
ARM: OMAP2+: Remove duplicated include from pmic-cpcap.c
ARM: OMAP2+: pdata-quirks: drop TI_ST/KIM support
ARM: OMAP2+: make omap44xx_sha0_hwmod and omap44xx_l3_main_2__des static
ARM: OMAP2+: prm44xx: make prm_{save,restore}_context static
ARM: OMAP2+: make dra7xx_sha0_hwmod static
ARM: OMAP2+: do not export am43xx_control functions
ARM: OMAP2+: Configure voltage controller for cpcap to low-speed
ARM: OMAP2+: Configure voltage controller for retention
ARM: OMAP2+: Make some functions static
ARM: OMAP2+: Simplify code for clkdm_clock_enable and disable
ARM: OMAP2+: Drop unused enable_wakeup and disable_wakeup
ARM: OMAP2+: Initialize voltage controller for omap4
ARM: OMAP2+: Allow core oswr for omap4
ARM: OMAP2+: Allow per oswr for omap4
ARM: OMAP2+: Configure voltage controller for cpcap
ARM: OMAP2+: Update 4430 voltage controller operating points
ARM: OMAP2+: Remove bogus warnings for machines without twl PMIC
ARM: OMAP2+: Drop bogus wkup domain oswr setting
ARM: OMAP2+: Remove unused wakeup_cpu
ARM: dts: Use level interrupt for omap4 & 5 wlcore
...
Link: https://lore.kernel.org/r/pull-1571934890-285615@atomide.com
Signed-off-by: Olof Johansson <olof@lixom.net>
'Link CRC error' will now have same error level as
other PSR2 errors like 'RFB storage error' and
'VSC SDP uncorrectable error'.
Signed-off-by: Ap Kamal <kamal.ap@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1571819128-3264-1-git-send-email-kamal.ap@intel.com
Fix locking issue in the error code path of a function that belongs
to the sysfs interface exposed by the ACPI NFIT handling code (Dan
Carpenter).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAl2x27oSHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxcSUP/06Ab4EWxo6Uriby3wQcPhYVFKiiS1jk
5C5Zf59AXlCI137jjhZuY8plJF3g9Db6D1Dlyhiz2rqQ+XevZfGOl502VSnulvFE
L42qjW22Llw2b8pGcQIpLYp/O+WONSHF1fDynS6dTQCvB945eHHaApNNg9RrCs2H
AQ3Ae/yBChAuYKOM1RE2w8h3cufPHuSj7dBRoPSBenZ+IxXdLjPA6Z2fTLpbCzFO
fZwydZ9b9E3C/Z0U77LyBeyKRr21lRjqiXkiAXnBYtuGQwzKjpfCQRG4fbYvywN3
c6C/cEMSatgQehzjXEuyvxqVkyPnJGq27NpTvoQCrDSdB5UGTS+oPDg6JKVlR6Nl
EXGh+/7GuSBUD+AtpDZ5AdFangypVY1JLkqRtLXtZThir45uuAcq49Rr//Fn+r6E
4Zsoz/WNoEAUjLQBKzRhxJ5+aYv4umXtV/1rYtZ7GtDHC0puysxbwe3mARXsze8R
vf46UqMvbMlHJCnxhakmgnya9WjA+5GHrTXG7/bKeUvW1KtAKL1w4ovviQK984Ff
hBBDbrNBQUFkHQWo6NXUNoesEWWK2TuAxQ74huteYvjcpImML3JUCTdldzFt+6lM
PTVDOQL+QhltxvZb3brW2cXkWmCzSehg3ikkDcS5IYkm5GTeWzW4yhUVHzbyiqUQ
gGZdqVwgCGgQ
=OPUO
-----END PGP SIGNATURE-----
Merge tag 'acpi-5.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"Fix locking issue in the error code path of a function that belongs to
the sysfs interface exposed by the ACPI NFIT handling code (Dan
Carpenter)"
* tag 'acpi-5.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: NFIT: Fix unlock on error in scrub_show()
- Using device PM QoS of CPU devices for managing frequency limits
in cpufreq does not work, so introduce frequency QoS (based on the
original low-level PM QoS) for this purpose, switch cpufreq and
related code over to using it and fix a race involving deferred
updates of frequency limits on top of that (Rafael Wysocki, Sudeep
Holla).
- Avoid calling regulator_enable()/disable() from the OPP framework
to avoid side-effects on boot-enabled regulators that may change their
initial voltage due to performing initial voltage balancing without
all restrictions from the consumers (Marek Szyprowski).
- Avoid a kref management issue in the OPP library code and drop an
incorrectly added lockdep_assert_held() from it (Viresh Kumar).
- Make the recently added haltpoll cpuidle driver take the 'idle='
override into account as appropriate (Zhenzhong Duan).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAl2x2nUSHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxB+wP/iwugVCQKNGaOiPRLz3SlL/hchZ7Nhye
qqetgC5dP/ZUkLrvJnt31wTgpF3VA9AQzuydtSEc76sf/hwaVhmyKhUC8TqqYYx1
Vhu6EE2tEtFyBNNl0ZPJS8+q7AjhSrDSV8JyFBafOfxRJV2za2Q+Fl0P4Y6gzcez
mYC1Ol7Of9c8L9J2p33ViNh31AQR8LnqV8YhIZRG5F4+jklJIlEt8QL0C25VQYAX
9TLhLrXktPRPJytX2eOU8vHOmVAz5qKvU3S6mAPhVPpnEcZL9E56H1sc3xCpX0ww
V8pnteMOxa3RUySTlGwnzKRwZQ7eSQjsJO9s/YWT+EGzt58Gr0q2WnEiZ8Vm38Hg
/eOWsyxZiS0JYGc9+Gg/Hh2XFmMxX5QEaKlyIyuJbXvwGGm8gg02MNziXa1FmUd+
nuklYhN8MJjH1iV84V3c0M8sdrut7LOlOotzyDniZWj7L57Ht+MWNSbpDoebPdGb
mhOYv/wjXcek0m8mHtlT6w/5o3qDYEkAsosacH6Eko/11tHCfnCGT/no/3ILf3f+
bBCVxXhkNFdSGC6RcozO1TrMbG3PN9nCzq+od+BDUOmqfsjR8vJbSwbHUQaWn0DU
jIBASI2FXlN6Hi3SMFA4m7Scnz1fwL9vUVT4EIJ6U5dsVx+T0qDIbgZ3nzyvp5Tn
vt6X4VzAZ5d/
=yitK
-----END PGP SIGNATURE-----
Merge tag 'pm-5.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These fix problems related to frequency limits management in cpufreq
that were introduced during the 5.3 cycle (when PM QoS had started to
be used for that), fix a few issues in the OPP (operating performance
points) library code and fix up the recently added haltpoll cpuidle
driver.
The cpufreq changes are somewhat bigger that I would like them to be
at this stage of the cycle, but the problems fixed by them include
crashes on boot and shutdown in some cases (among other things) and in
my view it is better to address the root of the issue right away.
Specifics:
- Using device PM QoS of CPU devices for managing frequency limits in
cpufreq does not work, so introduce frequency QoS (based on the
original low-level PM QoS) for this purpose, switch cpufreq and
related code over to using it and fix a race involving deferred
updates of frequency limits on top of that (Rafael Wysocki, Sudeep
Holla).
- Avoid calling regulator_enable()/disable() from the OPP framework
to avoid side-effects on boot-enabled regulators that may change
their initial voltage due to performing initial voltage balancing
without all restrictions from the consumers (Marek Szyprowski).
- Avoid a kref management issue in the OPP library code and drop an
incorrectly added lockdep_assert_held() from it (Viresh Kumar).
- Make the recently added haltpoll cpuidle driver take the 'idle='
override into account as appropriate (Zhenzhong Duan)"
* tag 'pm-5.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
opp: Reinitialize the list_kref before adding the static OPPs again
cpufreq: Cancel policy update work scheduled before freeing
cpuidle: haltpoll: Take 'idle=' override into account
opp: core: Revert "add regulators enable and disable"
PM: QoS: Drop frequency QoS types from device PM QoS
cpufreq: Use per-policy frequency QoS
PM: QoS: Introduce frequency QoS
opp: of: drop incorrect lockdep_assert_held()
The DSI PHY regulator supports two regulator modes: LDO and DCDC.
This mode can be selected using the "qcom,dsi-phy-regulator-ldo-mode"
device tree property.
However, at the moment only the 20nm PHY driver actually implements
that option. Add a check in the 28nm PHY driver to program the
registers correctly for LDO mode.
Tested-by: Nikita Travkin <nikitos.tr@gmail.com> # l8150
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191023165617.28738-1-stephan@gerhold.net
Because pids->limit can be changed concurrently (but we don't want to
take a lock because it would be needlessly expensive), use atomic64_ts
instead.
Fixes: commit 49b786ea14 ("cgroup: implement the PIDs subsystem")
Cc: stable@vger.kernel.org # v4.3+
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Remove the following warning:
drivers/i2c/busses/i2c-stm32f7.c:315:
warning: cannot understand function prototype:
'struct stm32f7_i2c_spec i2c_specs[] =
Replace a comment starting with /** by simply /* to avoid having
it interpreted as a kernel-doc comment.
Fixes: aeb068c572 ("i2c: i2c-stm32f7: add driver")
Signed-off-by: Alain Volmat <alain.volmat@st.com>
Reviewed-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
When in slave mode, an arbitration loss (ARLO) may be detected before the
slave had a chance to detect the stop condition (STOPF in ISR).
This is seen when two master + slave adapters switch their roles. It
provokes the i2c bus to be stuck, busy as SCL line is stretched.
- the I2C_SLAVE_STOP event is never generated due to STOPF flag is set but
don't generate an irq (race with ARLO irq, STOPIE is masked). STOPF flag
remains set until next master xfer (e.g. when STOPIE irq get unmasked).
In this case, completion is generated too early: immediately upon new
transfer request (then it doesn't send all data).
- Some data get stuck in TXDR register. As a consequence, the controller
stretches the SCL line: the bus gets busy until a future master transfer
triggers the bus busy / recovery mechanism (this can take time... and
may never happen at all)
So choice is to let the STOPF being detected by the slave isr handler,
to properly handle this stop condition. E.g. don't mask IRQs in error
handler, when the slave is running.
Fixes: 60d609f30d ("i2c: i2c-stm32f7: Add slave support")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The slave-interface documentation [1] states "the bus driver should
transmit the first byte" upon I2C_SLAVE_READ_REQUESTED slave event:
- 'val': backend returns first byte to be sent
The driver currently ignores the 1st byte to send on this event.
[1] https://www.kernel.org/doc/Documentation/i2c/slave-interface
Fixes: 60d609f30d ("i2c: i2c-stm32f7: Add slave support")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Since commit abf4923e97 ("i2c: mediatek: disable zero-length transfers
for mt8183"), there is a NULL pointer dereference for all the SoCs
that don't have any quirk. mtk_i2c_functionality is not checking that
the quirks pointer is not NULL before starting to use it.
This commit add a call to i2c_check_quirks which will check whether
the quirks pointer is set, and if so will check if the IP has the
NO_ZERO_LEN quirk.
Fixes: abf4923e97 ("i2c: mediatek: disable zero-length transfers for mt8183")
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Cengiz Can <cengiz@kernel.wtf>
Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org>
Tested-by: Ulrich Hecht <uli@fpond.eu>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
For very subtle mistakes with topology refs, it can be rather difficult
to trace them down with the debugging info that we already have. I had
one such issue recently while trying to implement suspend/resume
reprobing for MST, and ended up coming up with this.
Inspired by Chris Wilson's wakeref tracking for i915, this adds a very
similar feature to the DP MST helpers, which allows for partial tracking
of topology refs for both ports and branch devices. This is a lot less
advanced then wakeref tracking: we merely keep a count of all of the
spots where a topology ref has been grabbed or dropped, then dump out
that history in chronological order when a port or branch device's
topology refcount reaches 0. So far, I've found this incredibly useful
for debugging topology refcount errors.
Since this has the potential to be somewhat slow and loud, we add an
expert kernel config option to enable or disable this feature,
CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS.
Changes since v1:
* Don't forget to destroy topology_ref_history_lock
Changes since v4:
* Correct order of kref_put()/topology_ref_history_unlock - we can't
unlock the history after kref_put() since the memory might have been
freed by that point
* Don't print message on allocation error failures, the kernel already
does this for us
Changes since v5:
* Get rid of some leftover usages of %px
* Remove a leftover empty return; statement
Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-15-lyude@redhat.com
Add support for another Intel Comet Lake variant.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The counter resource should return -EAGAIN if it was requested for a
different port, this is similar to how QP works if the users provides a
port filter.
Otherwise port filtering in netlink will return broken counter nests.
Fixes: c4ffee7c9b ("RDMA/netlink: Implement counter dumpit calback")
Link: https://lore.kernel.org/r/20191020062800.8065-1-leon@kernel.org
Signed-off-by: Mark Zhang <markz@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Add support for SMBus controller on Intel Jasper Lake PCH-N.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Finally! For a very long time, our MST helpers have had one very
annoying issue: They don't know how to reprobe the topology state when
coming out of suspend. This means that if a user has a machine connected
to an MST topology and decides to suspend their machine, we lose all
topology changes that happened during that period. That can be a big
problem if the machine was connected to a different topology on the same
port before resuming, as we won't bother reprobing any of the ports and
likely cause the user's monitors not to come back up as expected.
So, we start fixing this by teaching our MST helpers how to reprobe the
link addresses of each connected topology when resuming. As it turns
out, the behavior that we want here is identical to the behavior we want
when initially probing a newly connected MST topology, with a couple of
important differences:
- We need to be more careful about handling the potential races between
events from the MST hub that could change the topology state as we're
performing the link address reprobe
- We need to be more careful about handling unlikely state changes on
ports - such as an input port turning into an output port, something
that would be far more likely to happen in situations like the MST hub
we're connected to being changed while we're suspend
Both of which have been solved by previous commits. That leaves one
requirement:
- We need to prune any MST ports in our in-memory topology state that
were present when suspending, but have not appeared in the post-resume
link address response from their parent branch device
Which we can now handle in this commit by modifying
drm_dp_send_link_address(). We then introduce suspend/resume reprobing
by introducing drm_dp_mst_topology_mgr_invalidate_mstb(), which we call
in drm_dp_mst_topology_mgr_suspend() to traverse the in-memory topology
state to indicate that each mstb needs it's link address resent and PBN
resources reprobed.
On resume, we start back up &mgr->work and have it reprobe the topology
in the same way we would on a hotplug, removing any leftover ports that
no longer appear in the topology state.
Changes since v4:
* Split indenting changes in drm_dp_mst_topology_mgr_resume() into a
separate patch
* Only fire hotplugs when something has actually changed after a link
address probe
* Don't try to change port->connector at all on ports, just throw out
ports that need their connectors removed to make things easier.
Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-14-lyude@redhat.com
Since we're going to be reprobing the entire topology state on resume
now using sideband transactions, we need to ensure that we actually have
short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
So, do that.
Changes since v3:
* Fix typo in comments
Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-13-lyude@redhat.com
Currently, every single piece of code in amdgpu that loops through
connectors does it incorrectly and doesn't use the proper list iteration
helpers, drm_connector_list_iter_begin() and
drm_connector_list_iter_end(). Yeesh.
So, do that.
Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-12-lyude@redhat.com
Currently, we enable hotplug detection only after we re-enable the
display. However, this is too late if we're planning on sending sideband
messages during the resume process - which we'll need to do in order to
reprobe the topology on resume.
So, enable hotplug events before reinitializing the display.
Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-11-lyude@redhat.com
In order for suspend/resume reprobing to work, we need to be able to
perform sideband communications during suspend/resume, along with
runtime PM suspend/resume. In order to do so, we also need to make sure
that nouveau doesn't bother grabbing a runtime PM reference to do so,
since otherwise we'll start deadlocking runtime PM again.
Note that we weren't able to do this before, because of the DP MST
helpers processing UP requests from topologies in the same context as
drm_dp_mst_hpd_irq() which would have caused us to open ourselves up to
receiving hotplug events and deadlocking with runtime suspend/resume.
Now that those requests are handled asynchronously, this change should
be completely safe.
Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-10-lyude@redhat.com
Does what it says on the tin.
Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-9-lyude@redhat.com
This probably hasn't caused any problems up until now since it's
probably nearly impossible to encounter this in the wild, however if we
were to receive a connection status notification from the MST hub after
resume while we're in the middle of reprobing the link addresses for a
topology then there's a much larger chance that a port could have
changed from being an output port to input port (or vice versa). If we
forget to update this bit of information, we'll potentially ignore a
valid PDT change on a downstream port because we think it's an input
port.
So, make sure we read the input_port field in connection status
notifications in drm_dp_mst_handle_conn_stat() to prevent this from
happening once we've implemented suspend/resume reprobing.
Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-8-lyude@redhat.com
This is a complicated one. Essentially, there's currently a problem in the MST
core that hasn't really caused any issues that we're aware of (emphasis on "that
we're aware of"): locking.
When we go through and probe the link addresses and path resources in a
topology, we hold no locks when updating ports with said information. The
members I'm referring to in particular are:
- ldps
- ddps
- mcs
- pdt
- dpcd_rev
- num_sdp_streams
- num_sdp_stream_sinks
- available_pbn
- input
- connector
Now that we're handling UP requests asynchronously and will be using some of
the struct members mentioned above in atomic modesetting in the future for
features such as PBN validation, this is going to become a lot more important.
As well, the next few commits that prepare us for and introduce suspend/resume
reprobing will also need clear locking in order to prevent from additional
racing hilarities that we never could have hit in the past.
So, let's solve this issue by using &mgr->base.lock, the modesetting
lock which currently only protects &mgr->base.state. This works
perfectly because it allows us to avoid blocking connection_mutex
unnecessarily, and we can grab this in connector detection paths since
it's a ww mutex. We start by having drm_dp_mst_handle_up_req() hold this
when updating ports. For drm_dp_mst_handle_link_address_port() things
are a bit more complicated. As I've learned the hard way, we can grab
&mgr->lock.base for everything except for port->connector. See, our
normal driver probing paths end up generating this rather obvious
lockdep chain:
&drm->mode_config.mutex
-> crtc_ww_class_mutex/crtc_ww_class_acquire
-> &connector->mutex
However, sysfs grabs &drm->mode_config.mutex in order to protect itself
from connector state changing under it. Because this entails grabbing
kn->count, e.g. the lock that the kernel provides for protecting sysfs
contexts, we end up grabbing kn->count followed by
&drm->mode_config.mutex. This ends up creating an extremely rude chain:
&kn->count
-> &drm->mode_config.mutex
-> crtc_ww_class_mutex/crtc_ww_class_acquire
-> &connector->mutex
I mean, look at that thing! It's just evil!!! This gross thing ends up
making any calls to drm_connector_register()/drm_connector_unregister()
impossible when holding any kind of modesetting lock. This is annoying
because ideally, we always want to ensure that
drm_dp_mst_port->connector never changes when doing an atomic commit or
check that would affect the atomic topology state so that it can
reliably and easily be used from future DRM DP MST helpers to assist
with tasks such as scanning through the current VCPI allocations and
adding connectors which need to have their allocations updated in
response to a bandwidth change or the like.
Being able to hold &mgr->base.lock throughout the entire link probe
process would have been _great_, since we could prevent userspace from
ever seeing any states in-between individual port changes and as a
result likely end up with a much faster probe and more consistent
results from said probes. But without some rework of how we handle
connector probing in sysfs it's not at all currently possible. In the
future, maybe we can try using the sysfs locks to protect updates to
connector probing state and fix this mess.
So for now, to protect everything other than port->connector under
&mgr->base.lock and ensure that we still have the guarantee that atomic
check/commit contexts will never see port->connector change we use a
silly trick. See: port->connector only needs to change in order to
ensure that input ports (see the MST spec) never have a ghost connector
associated with them. But, there's nothing stopping us from simply
throwing the entire port out and creating a new one in order to maintain
that requirement while still keeping port->connector consistent across
the lifetime of the port in atomic check/commit contexts. For all
intended purposes this works fine, as we validate ports in any contexts
we care about before using them and as such will end up reporting the
connector as disconnected until it's port's destruction finalizes. So,
we just do that in cases where we detect port->input has transitioned
from true->false. We don't need to worry about the other direction,
since a port without a connector isn't visible to userspace and as such
doesn't need to be protected by &mgr->base.lock until we finish
registering a connector for it.
For updating members of drm_dp_mst_port other than port->connector, we
simply grab &mgr->base.lock in drm_dp_mst_link_probe_work() for already
registered ports, update said members and drop the lock before
potentially registering a connector and probing the link address of it's
children.
Finally, we modify drm_dp_mst_detect_port() to take a modesetting lock
acquisition context in order to acquire &mgr->base.lock under
&connection_mutex and convert all it's users over to using the
.detect_ctx probe hooks.
With that, we finally have well defined locking.
Changes since v4:
* Get rid of port->mutex, stop using connection_mutex and just use our own
modesetting lock - mgr->base.lock. Also, add a probe_lock that comes
before this patch.
* Just throw out ports that get changed from an output to an input, and
replace them with new ports. This lets us ensure that modesetting
contexts never see port->connector go from having a connector to being
NULL.
* Write an extremely detailed explanation of what problems this is
trying to fix, since there's a _lot_ of context here and I honestly
forgot some of it myself a couple times.
* Don't grab mgr->lock when reading port->mstb in
drm_dp_mst_handle_link_address_port(). It's not needed.
Cc: Juston Li <juston.li@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-7-lyude@redhat.com
Add support for analog filtering for i2c lines.
The sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Reviewed-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Add new platform data support for advanced digital filtering for i2c.
The sama5d2 and sam9x60 support this feature.
This digital filter allows the user to configure the maximum
width of the spikes that can be filtered.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Reviewed-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Add new platform data support for digital filtering for i2c.
The sama5d4, sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Reviewed-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
