| Message ID | 20240904090016.2841572-1-wenst@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | platform/chrome: Introduce DT hardware prober | expand |
On Wed, 04 Sep 2024 17:00:02 +0800, Chen-Yu Tsai wrote: > This is v6 of my "of: Introduce hardware prober driver" [1] series. > v6 mainly addresses comments from Andy. > > v2 continued Doug's "of: device: Support 2nd sources of probeable but > undiscoverable devices" [2] series, but follows the scheme suggested by > Rob, marking all second source component device nodes as "fail-needs-probe", > and having a hardware prober driver enable the one of them. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [03/12] regulator: Move OF-specific regulator lookup code to of_regulator.c commit: b8c3255457147162cd713a319a8e2274335449b9 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Hi, this series gets quite some review from people I trust. This is awesome. So, I will keep to some high level questions: > undiscoverable devices" [2] series, but follows the scheme suggested by > Rob, marking all second source component device nodes as "fail-needs-probe", > and having a hardware prober driver enable the one of them. Where is this "fail-needs-probe" documented? I neither see it here nor in the dt-schema repo. > The other case, selecting a display panel to use based on the SKU ID > from the firmware, hit a bit of an issue with fixing the OF graph. > It has been left out since v3. Does it make sense then to add touchscreens only? Will the panels be worked on once this is upstream? Or what is the way forward? > Wolfram, would you be able to handle the late PR? Assuming you get a > chance to look at the patches that is. Yes, I can do this, but... > drivers/i2c/Makefile | 7 +- > drivers/i2c/i2c-core-of-prober.c | 437 ++++++++++++++++++ ... this is quite some code. Would you be willing to maintain it (i.e. please add a MAINTAINERS entry then). Kudos for not touching other parts of the I2C core! All the best, Wolfram
On Sun, Sep 8, 2024 at 12:58 AM Wolfram Sang <wsa+renesas@sang-engineering.com> wrote: > > Hi, > > this series gets quite some review from people I trust. This is awesome. > So, I will keep to some high level questions: > > > undiscoverable devices" [2] series, but follows the scheme suggested by > > Rob, marking all second source component device nodes as "fail-needs-probe", > > and having a hardware prober driver enable the one of them. > > Where is this "fail-needs-probe" documented? I neither see it here nor > in the dt-schema repo. You are correct that it has not been documented yet. I will send a patch to the dt-schema repo. > > The other case, selecting a display panel to use based on the SKU ID > > from the firmware, hit a bit of an issue with fixing the OF graph. > > It has been left out since v3. > > Does it make sense then to add touchscreens only? Will the panels be > worked on once this is upstream? Or what is the way forward? The devices this patch series targets all use eDP panels, which are more or less directly probe-able. The panels mentioned for the second phase are MIPI panels, which require specific power and command sequences and thus are not probe-able. This will be worked on once this part is done. For the panels it is entirely handled in the chrome platform device tree prober. See the following patch for an earlier version of it: https://lore.kernel.org/all/20231109100606.1245545-6-wenst@chromium.org/ > > Wolfram, would you be able to handle the late PR? Assuming you get a > > chance to look at the patches that is. > > Yes, I can do this, but... > > > drivers/i2c/Makefile | 7 +- > > drivers/i2c/i2c-core-of-prober.c | 437 ++++++++++++++++++ > > ... this is quite some code. Would you be willing to maintain it (i.e. > please add a MAINTAINERS entry then). Kudos for not touching other parts > of the I2C core! Sure! > All the best, > > Wolfram Thanks. There are still some comments to address, in particular making the prober more of a pluggable framework and exposing more code as helpers. ChenYu
Hi everyone, This is v6 of my "of: Introduce hardware prober driver" [1] series. v6 mainly addresses comments from Andy. v2 continued Doug's "of: device: Support 2nd sources of probeable but undiscoverable devices" [2] series, but follows the scheme suggested by Rob, marking all second source component device nodes as "fail-needs-probe", and having a hardware prober driver enable the one of them. Changes since v5: - Link to v5: https://lore.kernel.org/all/20240822092006.3134096-1-wenst@chromium.org/ - Patch 1 "of: dynamic: Add of_changeset_update_prop_string" - Collected Rob's reviewed-by - Patch 2 "of: base: Add for_each_child_of_node_with_prefix_scoped()" - New patch - Patch 3 "regulator: Move OF-specific regulator lookup code to of_regulator.c" - Fix kerneldoc format of of_regulator_dev_lookup() - Fix stub compile error for !CONFIG_OF in drivers/regulator/internal.h - Patch 4 "regulator: Split up _regulator_get()" - Fixed kerneldoc "Return" section format for _regulator_get_common() - Slightly reworded return value description - Patch 5 "regulator: Do pure DT regulator lookup in of_regulator_bulk_get_all()" - Used "dev_of_node(dev)" instead of "dev->of_node" - Replaced "dev_printk" with "dev_printk()" in kerneldoc mentions - Fixed kerneldoc "Return" section format for of_regulator_get_optional() - Fix @np parameter name in of_regulator_dev_lookup() kerneldoc - Patch 6 "gpiolib: Add gpio_property_name_length()" - Changed function name to "gpio_get_property_name_length()" - Changed argument name to "propname" - Clarified return value for "*-<GPIO suffix>" case - Reworked according to Andy's suggestion - Added stub function - Patch 7 "i2c: core: Remove extra space in Makefile" - New patch - Patch 8 "i2c: Introduce OF component probe function" - Fixed indent in Makefile - Split regulator and GPIO TODO items - Reversed final conditional in i2c_of_probe_enable_node() - Patch 9 "i2c: of-prober: Add regulator support" - Split of_regulator_bulk_get_all() return value check and explain "ret == 0" case - Switched to of_get_next_child_with_prefix_scoped() where applicable - Used krealloc_array() instead of directly calculating size - copy whole regulator array in one memcpy() call - Drop "0" from struct zeroing initializer - Split out regulator helper from i2c_of_probe_enable_res() to keep code cleaner when combined with the next patch - Added options for customizing power sequencing delay - Rename i2c_of_probe_get_regulator() to i2c_of_probe_get_regulators() - Add i2c_of_probe_free_regulator() helper - Patch 10 "i2c: of-prober: Add GPIO support" - Renamed "con" to "propname" in i2c_of_probe_get_gpiod() - Copy string first and check return value of strscpy() for overflow in i2c_of_probe_get_gpiod() - Add parenthesis around "enable" and "reset" GPIO names in comments - Split resource count debug message into two separate lines - Split out GPIO helper from i2c_of_probe_enable_res() to keep code cleaner following the previous patch - Adopted options for customizing power sequencing delay following previous patch - Patch 11 "platform/chrome: Introduce device tree hardware prober" - Adapt to new i2c_of_probe_component() parameters - Patch 12 "arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail" - None See v5 cover letter for previous change logs. For the I2C component (touchscreens and trackpads) case from the original series, the hardware prober driver finds the particular class of device in the device tree, gets its parent I2C adapter, and tries to initiate a simple I2C read for each device under that I2C bus. When it finds one that responds, it considers that one present, marks it as "okay", and returns, letting the driver core actually probe the device. This works fine in most cases since these components are connected via a ribbon cable and always have the same resources. The prober will also grab these resources and enable them. The other case, selecting a display panel to use based on the SKU ID from the firmware, hit a bit of an issue with fixing the OF graph. It has been left out since v3. Patch 1 adds of_changeset_update_prop_string(), as requested by Rob. Patch 2 adds for_each_child_of_node_with_prefix_scoped(), as suggested by Andy. Patches 3 through 5 reorganize the OF-specific regulator core code and reworks the existing of_regulator_bulk_get_all() function to look up regulator supplies solely using device tree nodes. Patch 6 adds a function to the GPIO library that checks whether a given string (property name) matches the GPIO property pattern, and if it does, returns the length of the GPIO name. Patch 7 cleans up some extra spaces in the i2c core Makefile Patch 8 implements probing the I2C bus for presence of components as a helper function in the I2C core. Patch 9 implements regulator supply support for the I2C component prober. Patch 10 implements GPIO support for the I2C component prober. Patch 11 adds a ChromeOS specific DT hardware prober. This initial version targets the Hana Chromebooks, probing its I2C trackpads and touchscreens. Patch 12 modifies the Hana device tree and marks the touchscreens and trackpads as "fail-needs-probe", ready for the driver to probe. The patch and build time dependencies for this series is now quite complicated: of_regulator.c cleanups [1] -> regulator patches here ---- | v gpio patch in -next [2] -> gpiolib patch here -----> i2c of-prober -- | platform/chrome device tree hardware prober <----- The regulator patches in this series depend on other cleanup patches [1] I sent earlier. The gpiolib patch depends on a commit in -next [2] changing the GPIO suffixes array. Patches 7 through 10 introducting i2c of-prober depend on the first 5 patches. Patch 11, The chrome prober, depends on patches 7 through 10. I think it might be easier if the respective maintainers take the first six patches for -rc1. Patches 7 through 11 can go through either the i2c or chrome trees either very late in the merge window or right after it. Patch 12 can go in only after everything else is in. This should be better than having an immutable branch on top of some commit in -next for three other trees to consume. Wolfram, would you be able to handle the late PR? Assuming you get a chance to look at the patches that is. Thanks ChenYu [1] https://lore.kernel.org/all/20240822072047.3097740-1-wenst@chromium.org/ [2] commit 4b91188dced8 ("gpiolib: Replace gpio_suffix_count with NULL-terminated array") Chen-Yu Tsai (12): of: dynamic: Add of_changeset_update_prop_string of: base: Add for_each_child_of_node_with_prefix_scoped() regulator: Move OF-specific regulator lookup code to of_regulator.c regulator: Split up _regulator_get() regulator: Do pure DT regulator lookup in of_regulator_bulk_get_all() gpiolib: Add gpio_get_property_name_length() i2c: core: Remove extra space in Makefile i2c: Introduce OF component probe function i2c: of-prober: Add regulator support i2c: of-prober: Add GPIO support platform/chrome: Introduce device tree hardware prober arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail .../boot/dts/mediatek/mt8173-elm-hana.dtsi | 13 + arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 +- drivers/gpio/gpiolib.c | 25 + drivers/i2c/Makefile | 7 +- drivers/i2c/i2c-core-of-prober.c | 437 ++++++++++++++++++ drivers/of/base.c | 35 ++ drivers/of/dynamic.c | 44 ++ drivers/platform/chrome/Kconfig | 11 + drivers/platform/chrome/Makefile | 1 + .../platform/chrome/chromeos_of_hw_prober.c | 104 +++++ drivers/regulator/core.c | 143 ++---- drivers/regulator/internal.h | 15 +- drivers/regulator/of_regulator.c | 150 +++++- include/linux/gpio/consumer.h | 7 + include/linux/i2c.h | 14 + include/linux/of.h | 13 + 16 files changed, 918 insertions(+), 105 deletions(-) create mode 100644 drivers/i2c/i2c-core-of-prober.c create mode 100644 drivers/platform/chrome/chromeos_of_hw_prober.c