Home
last modified time | relevance | path

Searched hist:"8 f3d9f354286745c751374f5f1fcafee6b3f3136" (Results 1 – 5 of 5) sorted by relevance

/openbmc/linux/include/linux/regulator/
H A Dcoupler.hc1f615e4f463b1620fff51d1c08a5e83c1683d6b Fri May 29 08:36:03 CDT 2020 Mark Brown <broonie@kernel.org> Merge series "Fix regulators coupling for Exynos5800" from Marek Szyprowski <m.szyprowski@samsung.com>:

Hi!

This patchset is another attempt to fix the regulator coupling on
Exynos5800/5422 SoCs. Here are links to the previous attempts:

https://lore.kernel.org/linux-samsung-soc/20191008101709.qVNy8eijBi0LynOteWFMnTg4GUwKG599n6OyYoX1Abs@z/
https://lore.kernel.org/lkml/20191017102758.8104-1-m.szyprowski@samsung.com/
https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.kumar@linaro.org/
https://lore.kernel.org/linux-pm/20200528131130.17984-1-m.szyprowski@samsung.com/

The problem is with "vdd_int" regulator coupled with "vdd_arm" on Odroid
XU3/XU4 boards family. "vdd_arm" is handled by CPUfreq. "vdd_int" is
handled by devfreq. CPUfreq initialized quite early during boot and it
starts changing OPPs and "vdd_arm" value. Sometimes CPU activity during
boot goes down and some low-frequency OPPs are selected, what in turn
causes lowering "vdd_arm". This happens before devfreq applies its
requirements on "vdd_int". Regulator balancing code reduces "vdd_arm"
voltage value, what in turn causes lowering "vdd_int" value to the lowest
possible value. This is much below the operation point of the wcore bus,
which still runs at the highest frequency.

The issue was hard to notice because in the most cases the board managed
to boot properly, even when the regulator was set to lowest value allowed
by the regulator constraints. However, it caused some random issues,
which can be observed as "Unhandled prefetch abort" or low USB stability.

Adding more and more special cases to the generic code has been rejected,
so the only way to ensure the desired behavior on Exynos5800-based SoCs
is to make a custom regulator coupler driver.

Best regards,
Marek Szyprowski

Patch summary:

Marek Szyprowski (2):
regulator: extract voltage balancing code to separate function
soc: samsung: Add simple voltage coupler for Exynos5800

arch/arm/mach-exynos/Kconfig | 1 +
drivers/regulator/core.c | 49 ++++++++-------
drivers/soc/samsung/Kconfig | 3 +
drivers/soc/samsung/Makefile | 1 +
.../soc/samsung/exynos-regulator-coupler.c | 59 +++++++++++++++++++
include/linux/regulator/coupler.h | 8 +++
6 files changed, 101 insertions(+), 20 deletions(-)
create mode 100644 drivers/soc/samsung/exynos-regulator-coupler.c

--
2.17.1

base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136
/openbmc/linux/include/linux/
H A Dregmap.h93b929922dba3a42b0439ef13144c6032b7733c8 Fri May 29 08:00:44 CDT 2020 Mark Brown <broonie@kernel.org> Merge series "regmap: provide simple bitops and use them in a driver" from Bartosz Golaszewski <brgl@bgdev.pl>
Bartosz Golaszewski <bgolaszewski@baylibre.com>:

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

I noticed that oftentimes I use regmap_update_bits() for simple bit
setting or clearing. In this case the fourth argument is superfluous as
it's always 0 or equal to the mask argument.

This series proposes to add simple bit operations for setting, clearing
and testing specific bits with regmap.

The second patch uses all three in a driver that got recently picked into
the net-next tree.

The patches obviously target different trees so - if you're ok with
the change itself - I propose you pick the first one into your regmap
tree for v5.8 and then I'll resend the second patch to add the first
user for these macros for v5.9.

v1 -> v2:
- convert the new macros to static inline functions

v2 -> v3:
- drop unneeded ternary operator

Bartosz Golaszewski (2):
regmap: provide helpers for simple bit operations
net: ethernet: mtk-star-emac: use regmap bitops

drivers/base/regmap/regmap.c | 22 +++++
drivers/net/ethernet/mediatek/mtk_star_emac.c | 80 ++++++++-----------
include/linux/regmap.h | 36 +++++++++
3 files changed, 93 insertions(+), 45 deletions(-)

base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136

--
2.26.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
626ceee334f94852a1864b54d376290298cf9e4c Fri May 29 08:00:43 CDT 2020 Mark Brown <broonie@kernel.org> Merge series "New DSA driver for VSC9953 Seville switch" from Vladimir Oltean <olteanv@gmail.com>:

Looking at the Felix and Ocelot drivers, Maxim asked if it would be
possible to use them as a base for a new driver for the switch inside
NXP T1040. Turns out, it is! The result is a driver eerily similar to
Felix.

The biggest challenge seems to be getting register read/write API
generic enough to cover such wild bitfield variations between hardware
generations. There is a patch on the regmap core which I would like to
get in through the networking subsystem, if possible (and if Mark is
ok), since it's a trivial addition.

Maxim Kochetkov (4):
soc/mscc: ocelot: add MII registers description
net: mscc: ocelot: convert SYS_PAUSE_CFG register access to regfield
net: mscc: ocelot: extend watermark encoding function
net: dsa: ocelot: introduce driver for Seville VSC9953 switch

Vladimir Oltean (7):
regmap: add helper for per-port regfield initialization
net: mscc: ocelot: unexport ocelot_probe_port
net: mscc: ocelot: convert port registers to regmap
net: mscc: ocelot: convert QSYS_SWITCH_PORT_MODE and SYS_PORT_MODE to
regfields
net: dsa: ocelot: create a template for the DSA tags on xmit
net: mscc: ocelot: split writes to pause frame enable bit and to
thresholds
net: mscc: ocelot: disable flow control on NPI interface

drivers/net/dsa/ocelot/Kconfig | 12 +
drivers/net/dsa/ocelot/Makefile | 6 +
drivers/net/dsa/ocelot/felix.c | 49 +-
drivers/net/dsa/ocelot/felix_vsc9959.c | 72 +-
drivers/net/dsa/ocelot/seville.c | 742 +++++++++++++++
drivers/net/dsa/ocelot/seville.h | 50 +
drivers/net/dsa/ocelot/seville_vsc9953.c | 1064 ++++++++++++++++++++++
drivers/net/ethernet/mscc/ocelot.c | 87 +-
drivers/net/ethernet/mscc/ocelot.h | 9 +-
drivers/net/ethernet/mscc/ocelot_board.c | 21 +-
drivers/net/ethernet/mscc/ocelot_io.c | 18 +-
drivers/net/ethernet/mscc/ocelot_regs.c | 57 ++
include/linux/regmap.h | 8 +
include/soc/mscc/ocelot.h | 68 +-
include/soc/mscc/ocelot_dev.h | 78 --
include/soc/mscc/ocelot_qsys.h | 13 -
include/soc/mscc/ocelot_sys.h | 23 -
net/dsa/tag_ocelot.c | 21 +-
18 files changed, 2196 insertions(+), 202 deletions(-)
create mode 100644 drivers/net/dsa/ocelot/seville.c
create mode 100644 drivers/net/dsa/ocelot/seville.h
create mode 100644 drivers/net/dsa/ocelot/seville_vsc9953.c

base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136

--
2.25.1
/openbmc/linux/drivers/base/regmap/
H A Dregmap.c93b929922dba3a42b0439ef13144c6032b7733c8 Fri May 29 08:00:44 CDT 2020 Mark Brown <broonie@kernel.org> Merge series "regmap: provide simple bitops and use them in a driver" from Bartosz Golaszewski <brgl@bgdev.pl>
Bartosz Golaszewski <bgolaszewski@baylibre.com>:

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

I noticed that oftentimes I use regmap_update_bits() for simple bit
setting or clearing. In this case the fourth argument is superfluous as
it's always 0 or equal to the mask argument.

This series proposes to add simple bit operations for setting, clearing
and testing specific bits with regmap.

The second patch uses all three in a driver that got recently picked into
the net-next tree.

The patches obviously target different trees so - if you're ok with
the change itself - I propose you pick the first one into your regmap
tree for v5.8 and then I'll resend the second patch to add the first
user for these macros for v5.9.

v1 -> v2:
- convert the new macros to static inline functions

v2 -> v3:
- drop unneeded ternary operator

Bartosz Golaszewski (2):
regmap: provide helpers for simple bit operations
net: ethernet: mtk-star-emac: use regmap bitops

drivers/base/regmap/regmap.c | 22 +++++
drivers/net/ethernet/mediatek/mtk_star_emac.c | 80 ++++++++-----------
include/linux/regmap.h | 36 +++++++++
3 files changed, 93 insertions(+), 45 deletions(-)

base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136

--
2.26.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
/openbmc/linux/drivers/regulator/
H A Dcore.cc1f615e4f463b1620fff51d1c08a5e83c1683d6b Fri May 29 08:36:03 CDT 2020 Mark Brown <broonie@kernel.org> Merge series "Fix regulators coupling for Exynos5800" from Marek Szyprowski <m.szyprowski@samsung.com>:

Hi!

This patchset is another attempt to fix the regulator coupling on
Exynos5800/5422 SoCs. Here are links to the previous attempts:

https://lore.kernel.org/linux-samsung-soc/20191008101709.qVNy8eijBi0LynOteWFMnTg4GUwKG599n6OyYoX1Abs@z/
https://lore.kernel.org/lkml/20191017102758.8104-1-m.szyprowski@samsung.com/
https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.kumar@linaro.org/
https://lore.kernel.org/linux-pm/20200528131130.17984-1-m.szyprowski@samsung.com/

The problem is with "vdd_int" regulator coupled with "vdd_arm" on Odroid
XU3/XU4 boards family. "vdd_arm" is handled by CPUfreq. "vdd_int" is
handled by devfreq. CPUfreq initialized quite early during boot and it
starts changing OPPs and "vdd_arm" value. Sometimes CPU activity during
boot goes down and some low-frequency OPPs are selected, what in turn
causes lowering "vdd_arm". This happens before devfreq applies its
requirements on "vdd_int". Regulator balancing code reduces "vdd_arm"
voltage value, what in turn causes lowering "vdd_int" value to the lowest
possible value. This is much below the operation point of the wcore bus,
which still runs at the highest frequency.

The issue was hard to notice because in the most cases the board managed
to boot properly, even when the regulator was set to lowest value allowed
by the regulator constraints. However, it caused some random issues,
which can be observed as "Unhandled prefetch abort" or low USB stability.

Adding more and more special cases to the generic code has been rejected,
so the only way to ensure the desired behavior on Exynos5800-based SoCs
is to make a custom regulator coupler driver.

Best regards,
Marek Szyprowski

Patch summary:

Marek Szyprowski (2):
regulator: extract voltage balancing code to separate function
soc: samsung: Add simple voltage coupler for Exynos5800

arch/arm/mach-exynos/Kconfig | 1 +
drivers/regulator/core.c | 49 ++++++++-------
drivers/soc/samsung/Kconfig | 3 +
drivers/soc/samsung/Makefile | 1 +
.../soc/samsung/exynos-regulator-coupler.c | 59 +++++++++++++++++++
include/linux/regulator/coupler.h | 8 +++
6 files changed, 101 insertions(+), 20 deletions(-)
create mode 100644 drivers/soc/samsung/exynos-regulator-coupler.c

--
2.17.1

base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136
/openbmc/linux/
H A DMakefile8f3d9f354286745c751374f5f1fcafee6b3f3136 Sun Apr 12 14:35:55 CDT 2020 Linus Torvalds <torvalds@linux-foundation.org> Linux 5.7-rc1