* [PATCH v2 0/4] iio: imu: bmi160: added regulator and mount-matrix support
From: Jonathan Albrieux @ 2020-05-19 7:50 UTC (permalink / raw)
To: linux-kernel
Cc: Jonathan Albrieux,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hartmut Knaack, Lars-Peter Clausen,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler
v2: fixed missing description for iio: imu: bmi160: added regulator
support
Convert txt format documentation to yaml.
Add documentation about vdd-supply, vddio-supply and mount-matrix.
Add vdd-supply and vddio-supply support. Without this support, vdd and
vddio should be set to always-on in device tree.
Add mount-matrix binding support. As chip could have different
orientations a mount matrix support is needed to correctly translate
these differences
Jonathan Albrieux (4):
dt-bindings: iio: imu: bmi160: convert txt format to yaml
dt-bindings: iio: imu: bmi160: add regulators and mount-matrix
iio: imu: bmi160: added regulator support
iio: imu: bmi160: added mount-matrix support
.../devicetree/bindings/iio/imu/bmi160.txt | 37 ------
.../devicetree/bindings/iio/imu/bmi160.yaml | 105 ++++++++++++++++++
drivers/iio/imu/bmi160/bmi160.h | 3 +
drivers/iio/imu/bmi160/bmi160_core.c | 47 +++++++-
4 files changed, 154 insertions(+), 38 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/imu/bmi160.txt
create mode 100644 Documentation/devicetree/bindings/iio/imu/bmi160.yaml
--
2.17.1
^ permalink raw reply
* [PATCH] dt-bindings: rtc: rtc-sh: Add missing power-domains property
From: Geert Uytterhoeven @ 2020-05-19 7:49 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring
Cc: Simon Horman, linux-rtc, devicetree, linux-renesas-soc,
Geert Uytterhoeven
make dtbs_check:
arch/arm/boot/dts/r7s72100-rskrza1.dt.yaml: rtc@fcff1000: 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+'
Fix this by documenting the missing power-domains property.
Update the example to match reality.
Fixes: 7f464532b05dadc8 ("dt-bindings: Add missing 'additionalProperties: false'")
Fixes: 7ae8b2f5dfb357f0 ("dt-bindings: rtc: rtc-sh: convert bindings to json-schema")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/rtc/renesas,sh-rtc.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/renesas,sh-rtc.yaml b/Documentation/devicetree/bindings/rtc/renesas,sh-rtc.yaml
index b95cb017f469613e..eff9df4b856ac8c2 100644
--- a/Documentation/devicetree/bindings/rtc/renesas,sh-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/renesas,sh-rtc.yaml
@@ -43,6 +43,9 @@ properties:
items:
enum: [ fck, rtc_x1, rtc_x3, extal ]
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -50,6 +53,7 @@ required:
- interrupt-names
- clocks
- clock-names
+ - power-domains
additionalProperties: false
@@ -68,5 +72,6 @@ examples:
interrupt-names = "alarm", "period", "carry";
clocks = <&mstp6_clks R7S72100_CLK_RTC>, <&rtc_x1_clk>,
<&rtc_x3_clk>, <&extal_clk>;
+ power-domains = <&cpg_clocks>;
clock-names = "fck", "rtc_x1", "rtc_x3", "extal";
};
--
2.17.1
^ permalink raw reply related
* [PATCH] dt-bindings: media: Add missing clock domain description
From: Geert Uytterhoeven @ 2020-05-19 7:42 UTC (permalink / raw)
To: Jacopo Mondi, Mauro Carvalho Chehab, Rob Herring
Cc: linux-media, linux-renesas-soc, devicetree, Geert Uytterhoeven
make dtbs_check:
arch/arm/boot/dts/r7s72100-genmai.dt.yaml: camera@e8210000: 'clocks', 'power-domains' do not match any of the regexes: 'pinctrl-[0-9]+'
Fix this by documenting the missing properties.
Update the example to match reality.
Fixes: 7f464532b05dadc8 ("dt-bindings: Add missing 'additionalProperties: false'")
Fixes: 58361eaa11d561f3 ("dt-bindings: media: renesas,ceu: Convert to yaml")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
.../devicetree/bindings/media/renesas,ceu.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.yaml b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
index f2393458814ee08f..c7e1e4fe67e6696b 100644
--- a/Documentation/devicetree/bindings/media/renesas,ceu.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
@@ -27,6 +27,12 @@ properties:
interrupts:
maxItems: 1
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
port:
type: object
additionalProperties: false
@@ -57,6 +63,8 @@ required:
- compatible
- reg
- interrupts
+ - clocks
+ - power-domains
- port
additionalProperties: false
@@ -64,11 +72,14 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/r7s72100-clock.h>
ceu: ceu@e8210000 {
reg = <0xe8210000 0x209c>;
compatible = "renesas,r7s72100-ceu";
interrupts = <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp6_clks R7S72100_CLK_CEU>;
+ power-domains = <&cpg_clocks>;
port {
ceu_in: endpoint {
--
2.17.1
^ permalink raw reply related
* RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller
From: Jun Li @ 2020-05-19 7:39 UTC (permalink / raw)
To: Thinh Nguyen, Felipe Balbi, Jun Li
Cc: John Stultz, lkml, Yu Chen, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, ShuFan Lee, Heikki Krogerus, Suzuki K Poulose,
Chunfeng Yun, Hans de Goede, Andy Shevchenko, Valentin Schneider,
Jack Pham, Linux USB List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Peter Chen
In-Reply-To: <e3b0ff51-70ab-7d16-2c7e-cacac7d97043@synopsys.com>
Hi
> -----Original Message-----
> From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
> Sent: 2020年5月19日 14:46
> To: Jun Li <jun.li@nxp.com>; Felipe Balbi <balbi@kernel.org>; Jun Li
> <lijun.kernel@gmail.com>
> Cc: John Stultz <john.stultz@linaro.org>; lkml <linux-kernel@vger.kernel.org>; Yu
> Chen <chenyu56@huawei.com>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; ShuFan Lee
> <shufan_lee@richtek.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Suzuki K Poulose <suzuki.poulose@arm.com>; Chunfeng Yun
> <chunfeng.yun@mediatek.com>; Hans de Goede <hdegoede@redhat.com>; Andy Shevchenko
> <andy.shevchenko@gmail.com>; Valentin Schneider <valentin.schneider@arm.com>;
> Jack Pham <jackp@codeaurora.org>; Linux USB List <linux-usb@vger.kernel.org>; open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>;
> Peter Chen <peter.chen@nxp.com>
> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device
> controller
>
> Thinh Nguyen wrote:
> > Jun Li wrote:
> >>> -----Original Message-----
> >>> From: Felipe Balbi <balbif@gmail.com> On Behalf Of Felipe Balbi
> >>> Sent: 2020年5月16日 19:57
> >>> To: Jun Li <jun.li@nxp.com>; Thinh Nguyen
> >>> <Thinh.Nguyen@synopsys.com>; Jun Li <lijun.kernel@gmail.com>
> >>> Cc: John Stultz <john.stultz@linaro.org>; lkml
> >>> <linux-kernel@vger.kernel.org>; Yu Chen <chenyu56@huawei.com>; Greg
> >>> Kroah-Hartman <gregkh@linuxfoundation.org>; Rob Herring
> >>> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; ShuFan
> >>> Lee <shufan_lee@richtek.com>; Heikki Krogerus
> >>> <heikki.krogerus@linux.intel.com>;
> >>> Suzuki K Poulose <suzuki.poulose@arm.com>; Chunfeng Yun
> >>> <chunfeng.yun@mediatek.com>; Hans de Goede <hdegoede@redhat.com>;
> >>> Andy Shevchenko <andy.shevchenko@gmail.com>; Valentin Schneider
> >>> <valentin.schneider@arm.com>; Jack Pham <jackp@codeaurora.org>;
> >>> Linux USB List <linux-usb@vger.kernel.org>; open list:OPEN FIRMWARE
> >>> AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>;
> >>> Peter Chen <peter.chen@nxp.com>; Thinh Nguyen
> >>> <Thinh.Nguyen@synopsys.com>
> >>> Subject: RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct
> >>> cleared by device controller
> >>>
> >>>
> >>> Hi,
> >>>
> >>> Jun Li <jun.li@nxp.com> writes:
> >>>>>>> Hi Thinh, could you comment this?
> >>>>>> You only need to wake up the usb2 phy when issuing the command
> >>>>>> while running in highspeed or below. If you're running in SS or
> >>>>>> higher, internally the controller does it for you for usb3 phy.
> >>>>>> In Jun's case, it seems like it takes longer for his phy to wake up.
> >>>>>>
> >>>>>> IMO, in this case, I think it's fine to increase the command timeout.
> >>>>> Is there an upper limit to this? Is 32k clock the slowest that can
> >>>>> be fed to the PHY as a suspend clock?
> >>>> Yes, 32K clock is the slowest, Per DWC3 document on Power Down
> >>>> Scale (bits 31:19 of GCTL):
> >>>>
> >>>> "Power Down Scale (PwrDnScale)
> >>>> The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock source
> >>>> to a small part of the USB3 controller that operates when the SS
> >>>> PHY is in its lowest power (P3) state, and therefore does not provide a clock.
> >>>> The Power Down Scale field specifies how many suspend_clk periods
> >>>> fit into a 16 kHz clock period. When performing the division, round
> >>>> up the remainder.
> >>>> For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz
> >>>> Suspend clock, Power Down Scale = 25000 kHz/16 kHz = 13'd1563
> >>>> (rounder up)
> >>>> Note:
> >>>> - Minimum Suspend clock frequency is 32 kHz
> >>>> - Maximum Suspend clock frequency is 125 MHz"
> >>> Cool, now do we have an upper bound for how many clock cycles it
> >>> takes to wake up the PHY?
> >> My understanding is this ep command does not wake up the SS PHY, the
> >> SS PHY still stays at P3 when execute this ep command. The time
> >> required here is to wait controller complete something for this ep
> >> command with 32K clock.
> > Sorry I made a mistake. You're right. Just checked with one of the RTL
> > engineers, and it doesn't need to wake up the phy. However, if it is
> > eSS speed, it may take longer time as the command may be completing
> > with the suspend clock.
> >
>
> What's the value for GCTL[7:6]?
2'b00
Thanks
Li Jun
>
> BR,
> Thinh
^ permalink raw reply
* Re: [PATCH v3 01/20] dt-bindings: arm: gic: Allow combining arm,gic-400 compatible strings
From: Geert Uytterhoeven @ 2020-05-19 7:39 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Liviu Dudau, Sudeep Holla, Lorenzo Pieralisi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Mark Rutland, Marc Zyngier
In-Reply-To: <20200513103016.130417-2-andre.przywara@arm.com>
Hi Andre,
On Wed, May 13, 2020 at 12:31 PM Andre Przywara <andre.przywara@arm.com> wrote:
> The arm,gic-400 compatible is probably the best matching string for the
> GIC in most modern SoCs, but was only introduced later into the kernel.
> For historic reasons and to keep compatibility, some SoC DTs were thus
> using a combination of this name and one of the older strings, which
> currently the binding denies.
>
> Add a stanza to the DT binding to allow "arm,gic-400", followed by
> either "arm,cortex-a15-gic" or "arm,cortex-a7-gic". This fixes binding
> compliance for quite some SoC .dtsi files in the kernel tree.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Thanks for your patch, I was just looking into this issue ;-)
> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
> @@ -39,6 +39,12 @@ properties:
> - qcom,msm-8660-qgic
> - qcom,msm-qgic2
>
> + - items:
> + - const: arm,gic-400
> + - enum:
> + - arm,cortex-a15-gic
> + - arm,cortex-a7-gic
> +
> - items:
> - const: arm,arm1176jzf-devchip-gic
> - const: arm,arm11mp-gic
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/r9a06g032.dtsi#n177
has them in the other order.
What do you think is the preferred solution: reverting the order, or dropping
one or the other?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] dt-bindings: spi: ti_qspi.txt: fix unit address
From: Kangmin Park @ 2020-05-19 7:32 UTC (permalink / raw)
To: Mark Brown; +Cc: Rob Herring, linux-spi, devicetree, linux-kernel
Fix unit address to match the first address specified in the reg
property of the node in example.
Signed-off-by: Kangmin Park <l4stpr0gr4m@gmail.com>
---
Documentation/devicetree/bindings/spi/ti_qspi.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index e65fde4..47b184b 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -29,7 +29,7 @@ modification to bootloader.
Example:
For am4372:
-qspi: qspi@4b300000 {
+qspi: qspi@47900000 {
compatible = "ti,am4372-qspi";
reg = <0x47900000 0x100>, <0x30000000 0x4000000>;
reg-names = "qspi_base", "qspi_mmap";
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: ti: k3-am654-main: Update otap-del-sel values
From: Faiz Abbas @ 2020-05-19 7:30 UTC (permalink / raw)
To: Tero Kristo, linux-kernel, devicetree, linux-arm-kernel; +Cc: robh+dt, nm
In-Reply-To: <c59653d0-2e24-8917-f5b9-8c1044786bc9@ti.com>
Hi Tero,
On 15/05/20 3:44 pm, Tero Kristo wrote:
> On 07/05/2020 21:15, Faiz Abbas wrote:
>> According to the latest AM65x Data Manual[1], a different output tap
>> delay value is optimum for a given speed mode. Update these values.
>>
>> [1] http://www.ti.com/lit/gpn/am6526
>>
>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>> ---
>> v2: Rebased to the latest mainline kernel
>>
>> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> index 11887c72f23a..6cd9701e4ead 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> @@ -244,7 +244,17 @@
>> interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
>> mmc-ddr-1_8v;
>> mmc-hs200-1_8v;
>> - ti,otap-del-sel = <0x2>;
>> + ti,otap-del-sel-legacy = <0x0>;
>> + ti,otap-del-sel-mmc-hs = <0x0>;
>> + ti,otap-del-sel-sd-hs = <0x0>;
>> + ti,otap-del-sel-sdr12 = <0x0>;
>> + ti,otap-del-sel-sdr25 = <0x0>;
>> + ti,otap-del-sel-sdr50 = <0x8>;
>> + ti,otap-del-sel-sdr104 = <0x5>;
>
> Isn't this wrong? Doc claims the value for sdr104 should be 0x7?
>
Yes. There seems to be an update to the document since I last updated the value.
Thanks for catching. I will post another version soon.
Thanks,
Faiz
^ permalink raw reply
* [PATCH v15 2/2] i2c: core: support bus regulator controlling in adapter
From: Bibby Hsieh @ 2020-05-19 7:27 UTC (permalink / raw)
To: Wolfram Sang, Bartosz Golaszewski, linux-i2c
Cc: tfiga, drinkcat, srv_heupstream, robh+dt, mark.rutland,
devicetree, Rafael J . Wysocki, Bibby Hsieh
In-Reply-To: <20200519072729.7268-1-bibby.hsieh@mediatek.com>
Although in the most platforms, the bus power of i2c
are alway on, some platforms disable the i2c bus power
in order to meet low power request.
We get and enable bulk regulator in i2c adapter device.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
drivers/i2c/i2c-core-base.c | 84 +++++++++++++++++++++++++++++++++++++
include/linux/i2c.h | 2 +
2 files changed, 86 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 5cc0b0ec5570..e1cc8d46bc51 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -313,12 +313,14 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
static int i2c_device_probe(struct device *dev)
{
struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_adapter *adap;
struct i2c_driver *driver;
int status;
if (!client)
return 0;
+ adap = client->adapter;
driver = to_i2c_driver(dev->driver);
client->irq = client->init_irq;
@@ -378,6 +380,12 @@ static int i2c_device_probe(struct device *dev)
dev_dbg(dev, "probe\n");
+ status = regulator_enable(adap->bus_regulator);
+ if (status < 0) {
+ dev_err(&adap->dev, "Failed to enable power regulator\n");
+ goto err_clear_wakeup_irq;
+ }
+
status = of_clk_set_defaults(dev->of_node, false);
if (status < 0)
goto err_clear_wakeup_irq;
@@ -414,12 +422,14 @@ static int i2c_device_probe(struct device *dev)
static int i2c_device_remove(struct device *dev)
{
struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_adapter *adap;
struct i2c_driver *driver;
int status = 0;
if (!client || !dev->driver)
return 0;
+ adap = client->adapter;
driver = to_i2c_driver(dev->driver);
if (driver->remove) {
dev_dbg(dev, "remove\n");
@@ -427,6 +437,8 @@ static int i2c_device_remove(struct device *dev)
}
dev_pm_domain_detach(&client->dev, true);
+ if (!pm_runtime_status_suspended(&client->dev))
+ regulator_disable(adap->bus_regulator);
dev_pm_clear_wake_irq(&client->dev);
device_init_wakeup(&client->dev, false);
@@ -438,6 +450,72 @@ static int i2c_device_remove(struct device *dev)
return status;
}
+#ifdef CONFIG_PM_SLEEP
+static int i2c_resume_early(struct device *dev)
+{
+ struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_adapter *adap = client->adapter;
+ int err;
+
+ if (!pm_runtime_status_suspended(&client->dev)) {
+ err = regulator_enable(adap->bus_regulator);
+ if (err)
+ return err;
+ }
+
+ return pm_generic_resume_early(&client->dev);
+}
+
+static int i2c_suspend_late(struct device *dev)
+{
+ struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_adapter *adap = client->adapter;
+ int err;
+
+ err = pm_generic_suspend_late(&client->dev);
+ if (err)
+ return err;
+
+ if (!pm_runtime_status_suspended(&client->dev))
+ return regulator_disable(adap->bus_regulator);
+
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_PM
+static int i2c_runtime_resume(struct device *dev)
+{
+ struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_adapter *adap = client->adapter;
+ int err;
+
+ err = regulator_enable(adap->bus_regulator);
+ if (err)
+ return err;
+
+ return pm_generic_runtime_resume(&client->dev);
+}
+
+static int i2c_runtime_suspend(struct device *dev)
+{
+ struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_adapter *adap = client->adapter;
+ int err;
+
+ err = pm_generic_runtime_suspend(&client->dev);
+ if (err)
+ return err;
+
+ return regulator_disable(adap->bus_regulator);
+}
+#endif
+
+static const struct dev_pm_ops i2c_device_pm = {
+ SET_LATE_SYSTEM_SLEEP_PM_OPS(i2c_suspend_late, i2c_resume_early)
+ SET_RUNTIME_PM_OPS(i2c_runtime_suspend, i2c_runtime_resume, NULL)
+};
+
static void i2c_device_shutdown(struct device *dev)
{
struct i2c_client *client = i2c_verify_client(dev);
@@ -495,6 +573,7 @@ struct bus_type i2c_bus_type = {
.probe = i2c_device_probe,
.remove = i2c_device_remove,
.shutdown = i2c_device_shutdown,
+ .pm = &i2c_device_pm,
};
EXPORT_SYMBOL_GPL(i2c_bus_type);
@@ -1333,6 +1412,11 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
if (res)
goto out_reg;
+ adap->bus_regulator = devm_regulator_get(&adap->dev, "bus");
+ if (IS_ERR(adap->bus_regulator)) {
+ res = PTR_ERR(adap->bus_regulator);
+ goto out_reg;
+ }
dev_dbg(&adap->dev, "adapter [%s] registered\n", adap->name);
pm_runtime_no_callbacks(&adap->dev);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 456fc17ecb1c..bc83af0d38d1 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -15,6 +15,7 @@
#include <linux/device.h> /* for struct device */
#include <linux/sched.h> /* for completion */
#include <linux/mutex.h>
+#include <linux/regulator/consumer.h>
#include <linux/rtmutex.h>
#include <linux/irqdomain.h> /* for Host Notify IRQ */
#include <linux/of.h> /* for struct device_node */
@@ -721,6 +722,7 @@ struct i2c_adapter {
const struct i2c_adapter_quirks *quirks;
struct irq_domain *host_notify_domain;
+ struct regulator *bus_regulator;
};
#define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
--
2.18.0
^ permalink raw reply related
* [PATCH v15 0/2] add power control in i2c
From: Bibby Hsieh @ 2020-05-19 7:27 UTC (permalink / raw)
To: Wolfram Sang, Bartosz Golaszewski, linux-i2c
Cc: tfiga, drinkcat, srv_heupstream, robh+dt, mark.rutland,
devicetree, Rafael J . Wysocki, Bibby Hsieh
Although in the most platforms, the power of eeprom
and i2c are alway on, some platforms disable the
eeprom and i2c power in order to meet low power request.
This patch add the pm_runtime ops to control power to
support all platforms.
Changes since v14:
- change the return value in normal condition
- access the variable after NULL pointer checking
- add ack tag
Changes since v13:
- fixup some logic error
Changes since v12:
- rebase onto v5.7-rc1
- change the property description in binding
Changes since v11:
- use suspend_late/resume_early instead of suspend/resume
- rebase onto v5.6-rc1
Changes since v10:
- fixup some worng codes
Changes since v9:
- fixup build error
- remove redundant code
Changes since v8:
- fixup some wrong code
- remove redundant message
[... snip ...]
Bibby Hsieh (2):
dt-binding: i2c: add bus-supply property
i2c: core: support bus regulator controlling in adapter
Documentation/devicetree/bindings/i2c/i2c.txt | 3 +
drivers/i2c/i2c-core-base.c | 84 +++++++++++++++++++
include/linux/i2c.h | 2 +
3 files changed, 89 insertions(+)
--
2.18.0
^ permalink raw reply
* [PATCH v15 1/2] dt-binding: i2c: add bus-supply property
From: Bibby Hsieh @ 2020-05-19 7:27 UTC (permalink / raw)
To: Wolfram Sang, Bartosz Golaszewski, linux-i2c
Cc: tfiga, drinkcat, srv_heupstream, robh+dt, mark.rutland,
devicetree, Rafael J . Wysocki, Bibby Hsieh
In-Reply-To: <20200519072729.7268-1-bibby.hsieh@mediatek.com>
In some platforms, they disable the power-supply of i2c due
to power consumption reduction. This patch add bus-supply property.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/i2c/i2c.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
index 9a53df4243c6..e6b5aafc5dc9 100644
--- a/Documentation/devicetree/bindings/i2c/i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c.txt
@@ -98,6 +98,9 @@ wants to support one of the below features, it should adapt the bindings below.
Names of map programmable addresses.
It can contain any map needing another address than default one.
+- bus-supply
+ phandle to the regulator that provides power to SCL/SDA.
+
Binding may contain optional "interrupts" property, describing interrupts
used by the device. I2C core will assign "irq" interrupt (or the very first
interrupt if not using interrupt names) as primary interrupt for the slave.
--
2.18.0
^ permalink raw reply related
* Re: [PATCH v14 2/2] i2c: core: support bus regulator controlling in adapter
From: Bibby Hsieh @ 2020-05-19 7:26 UTC (permalink / raw)
To: Wolfram Sang
Cc: Bartosz Golaszewski, linux-i2c, tfiga, drinkcat, srv_heupstream,
robh+dt, mark.rutland, devicetree, Rafael J . Wysocki
In-Reply-To: <20200519065937.GD1094@ninjato>
Hi, Wolfram,
Thanks for the reviewing, I will sent next version for fixing up them.
Bibby
On Tue, 2020-05-19 at 08:59 +0200, Wolfram Sang wrote:
> On Tue, Apr 28, 2020 at 02:18:13PM +0800, Bibby Hsieh wrote:
> > Although in the most platforms, the bus power of i2c
> > are alway on, some platforms disable the i2c bus power
> > in order to meet low power request.
> >
> > We get and enable bulk regulator in i2c adapter device.
> >
> > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> > ---
> > drivers/i2c/i2c-core-base.c | 82 +++++++++++++++++++++++++++++++++++++
> > include/linux/i2c.h | 2 +
> > 2 files changed, 84 insertions(+)
> >
> > diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> > index 5cc0b0ec5570..f81b42a4ed07 100644
> > --- a/drivers/i2c/i2c-core-base.c
> > +++ b/drivers/i2c/i2c-core-base.c
> > @@ -313,6 +313,7 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
> > static int i2c_device_probe(struct device *dev)
> > {
> > struct i2c_client *client = i2c_verify_client(dev);
> > + struct i2c_adapter *adap = client->adapter;
>
> You are accessing client before the NULL pointer check.
>
>
> > @@ -414,6 +421,7 @@ static int i2c_device_probe(struct device *dev)
> > static int i2c_device_remove(struct device *dev)
> > {
> > struct i2c_client *client = i2c_verify_client(dev);
> > + struct i2c_adapter *adap = client->adapter;
>
> Same here.
>
> > +static int i2c_suspend_late(struct device *dev)
> > +{
> > + struct i2c_client *client = i2c_verify_client(dev);
> > + struct i2c_adapter *adap = client->adapter;
> > + int err;
> > +
> > + err = pm_generic_suspend_late(&client->dev);
> > + if (err)
> > + return err;
> > +
> > + if (!pm_runtime_status_suspended(&client->dev))
> > + return regulator_disable(adap->bus_regulator);
> > +
> > + return err;
>
> Can be 'return 0'.
>
^ permalink raw reply
* Re: [PATCH v9 10/10] arm64: dts: Add node for ufs exynos7
From: Krzysztof Kozlowski @ 2020-05-19 7:16 UTC (permalink / raw)
To: Alim Akhtar
Cc: robh, devicetree, linux-scsi, avri.altman, martin.petersen,
kwmad.kim, stanley.chu, cang, linux-samsung-soc, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200514003914.26052-11-alim.akhtar@samsung.com>
On Thu, May 14, 2020 at 06:09:14AM +0530, Alim Akhtar wrote:
> Adding dt node foe UFS and UFS-PHY for exynos7 SoC.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> Tested-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> ---
> .../boot/dts/exynos/exynos7-espresso.dts | 4 ++
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 43 ++++++++++++++++++-
> 2 files changed, 45 insertions(+), 2 deletions(-)
I will pick it up after all bindings get Rob's ack (or are picked up as
well). The second bindings patch are still pending on that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] i2c: mediatek: Add i2c ac-timing adjust support
From: Geert Uytterhoeven @ 2020-05-19 7:14 UTC (permalink / raw)
To: Qii Wang
Cc: Joe Perches,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
srv_heupstream, Wolfram Sang, leilk.liu,
Linux Kernel Mailing List, linux-mediatek, Linux I2C, Linux ARM
In-Reply-To: <1589857073.25512.34.camel@mhfsdcap03>
Hi Qii,
On Tue, May 19, 2020 at 4:59 AM Qii Wang <qii.wang@mediatek.com> wrote:
> On Mon, 2020-05-18 at 17:44 +0200, Geert Uytterhoeven wrote:
> > On Thu, May 14, 2020 at 3:13 PM Qii Wang <qii.wang@mediatek.com> wrote:
> > > This patch adds a algorithm to calculate some ac-timing parameters
> > > which can fully meet I2C Spec.
> > >
> > > Signed-off-by: Qii Wang <qii.wang@mediatek.com>
> > > ---
> > > drivers/i2c/busses/i2c-mt65xx.c | 328 +++++++++++++++++++++++++++++++++-------
> > > 1 file changed, 277 insertions(+), 51 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> > > index 0ca6c38a..7020618 100644
> > > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> >
> > > +/*
> > > + * Check and Calculate i2c ac-timing
> > > + *
> > > + * Hardware design:
> > > + * sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src
> > > + * xxx_cnt_div = spec->min_xxx_ns / sample_ns
> > > + *
> > > + * Sample_ns is rounded down for xxx_cnt_div would be greater
> > > + * than the smallest spec.
> > > + * The sda_timing is chosen as the middle value between
> > > + * the largest and smallest.
> > > + */
> > > +static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
> > > + unsigned int clk_src,
> > > + unsigned int check_speed,
> > > + unsigned int step_cnt,
> > > + unsigned int sample_cnt)
> > > +{
> > > + const struct i2c_spec_values *spec;
> > > + unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
> > > + unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
> > > + long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
> >
> > So sample_ns is a 64-bit value. Is that really needed?
> >
>
> (1000000000 * (sample_cnt + 1)) / clk_src value is a 32-bit, (1000000000
> * (sample_cnt + 1)) will over 32-bit if sample_cnt is 7.
The intermediate value will indeed not fit in 32-bit.
But that doesn't mean the end result won't fit in 32-bit.
As you divide spec->min_low_ns and spec->min_su_dat_ns (which I assume
are small numbers) by sample_ns below, sample_ns cannot be very large,
or the quotient will be zero anyway.
So just doing the multiplication in 64-bit, followed by a 64-by-32
division is probably fine:
unsigned int sample_ns = div_u64(1000000000ULL * (sample_cnt + 1), clk_src);
You may want to take precautions for the case where the passed value of
clk_src is a small number (can that happen?).
BTW, clk_get_rate() returns "unsigned long", while mtk_i2c_set_speed()
takes an "unsigned int" parent_clk, which may cause future issues.
You may want to change that to "unsigned long", along the whole
propagation path, and use div64_ul() instead of div_u64() above.
> I think 1000000000 and clk_src is too big, maybe I can reduce then with
> be divided all by 1000.
> example:
>
> unsigned int sample_ns;
> unsigned int clk_src_khz = clk_src / 1000;
That may cause too much loss of precision.
>
> if(clk_src_khz)
> sample_ns = (1000000 * (sample_cnt + 1)) / clk_src_khz;
> else
> return -EINVAL;
>
> > > + if (!i2c->dev_comp->timing_adjust)
> > > + return 0;
> > > +
> > > + if (i2c->dev_comp->ltiming_adjust)
> > > + max_sta_cnt = 0x100;
> > > +
> > > + spec = mtk_i2c_get_spec(check_speed);
> > > +
> > > + if (i2c->dev_comp->ltiming_adjust)
> > > + clk_ns = 1000000000 / clk_src;
> > > + else
> > > + clk_ns = sample_ns / 2;
> > > +
> > > + su_sta_cnt = DIV_ROUND_UP(spec->min_su_sta_ns, clk_ns);
> > > + if (su_sta_cnt > max_sta_cnt)
> > > + return -1;
> > > +
> > > + low_cnt = DIV_ROUND_UP(spec->min_low_ns, sample_ns);
> >
> > So this is a 32-bit by 64-bit division (indeed, not 64-by-32!)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v1 4/4] of: platform: Batch fwnode parsing when adding all top level devices
From: Marek Szyprowski @ 2020-05-19 7:11 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring, Frank Rowand,
Len Brown, Android Kernel Team, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
ACPI Devel Maling List, Ji Luo, Linux Samsung SOC
In-Reply-To: <CAGETcx_FOGgHdaNY8Dd-4rgT28U7_OHYeLsazbUE-1hyuatRSg@mail.gmail.com>
Hi Saravana,
On 19.05.2020 08:48, Saravana Kannan wrote:
> On Mon, May 18, 2020 at 11:25 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 15.05.2020 07:35, Saravana Kannan wrote:
>>> The fw_devlink_pause() and fw_devlink_resume() APIs allow batching the
>>> parsing of the device tree nodes when a lot of devices are added. This
>>> will significantly cut down parsing time (as much a 1 second on some
>>> systems). So, use them when adding devices for all the top level device
>>> tree nodes in a system.
>>>
>>> Signed-off-by: Saravana Kannan <saravanak@google.com>
>> This patch recently landed in linux-next 20200518. Sadly, it causes
>> regression on Samsung Exynos5433-based TM2e board:
>>
>> s3c64xx-spi 14d30000.spi: Failed to get RX DMA channel
>> s3c64xx-spi 14d50000.spi: Failed to get RX DMA channel
>> s3c64xx-spi 14d30000.spi: Failed to get RX DMA channel
>> s3c64xx-spi 14d50000.spi: Failed to get RX DMA channel
>> s3c64xx-spi 14d30000.spi: Failed to get RX DMA channel
>>
>> Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
>> Modules linked in:
>> CPU: 0 PID: 50 Comm: kworker/0:1 Not tainted 5.7.0-rc5+ #701
>> Hardware name: Samsung TM2E board (DT)
>> Workqueue: events deferred_probe_work_func
>> pstate: 60000005 (nZCv daif -PAN -UAO)
>> pc : samsung_i2s_probe+0x768/0x8f0
>> lr : samsung_i2s_probe+0x688/0x8f0
>> ...
>> Call trace:
>> samsung_i2s_probe+0x768/0x8f0
>> platform_drv_probe+0x50/0xa8
>> really_probe+0x108/0x370
>> driver_probe_device+0x54/0xb8
>> __device_attach_driver+0x90/0xc0
>> bus_for_each_drv+0x70/0xc8
>> __device_attach+0xdc/0x140
>> device_initial_probe+0x10/0x18
>> bus_probe_device+0x94/0xa0
>> deferred_probe_work_func+0x70/0xa8
>> process_one_work+0x2a8/0x718
>> worker_thread+0x48/0x470
>> kthread+0x134/0x160
>> ret_from_fork+0x10/0x1c
>> Code: 17ffffaf d503201f f94086c0 91003000 (88dffc00)
>> ---[ end trace ccf721c9400ddbd6 ]---
>> Kernel panic - not syncing: Fatal exception
>> SMP: stopping secondary CPUs
>> Kernel Offset: disabled
>> CPU features: 0x090002,24006087
>> Memory Limit: none
>>
>> ---[ end Kernel panic - not syncing: Fatal exception ]---
>>
>> Both issues, the lack of DMA for SPI device and Synchronous abort in I2S
>> probe are new after applying this patch. I'm trying to investigate which
>> resources are missing and why. The latter issue means typically that the
>> registers for the given device has been accessed without enabling the
>> needed clocks or power domains.
> Did you try this copy-pasta fix that I sent later?
> https://lore.kernel.org/lkml/20200517173453.157703-1-saravanak@google.com/
>
> Not every system would need it (my test setup didn't), but it helps some cases.
>
> If that fix doesn't help, then some tips for debugging the failing drivers.
> What this pause/resume patch effectively (not explicitly) does is:
> 1. Doesn't immediately probe the devices as they are added in
> of_platform_default_populate_init()
> 2. Adds them in order to the deferred probe list.
> 3. Then kicks off deferred probe on them in the order they were added.
>
> These drivers are just not handling -EPROBE_DEFER correctly or
> assuming probe order and that's causing these issues.
>
> So, we can either fix that or you can try adding some code to flush
> the deferred probe workqueue at the end of fw_devlink_resume().
>
> Let me know how it goes.
So far it looks that your patch revealed a hidden issue in exynos5433
clocks configuration, because adding clk_ignore_unused parameter to
kernel command line fixes the boot. I'm still investigating it, so
probable you can ignore my regression report. I will let you know asap I
finish checking it.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v14 1/2] dt-binding: i2c: add bus-supply property
From: Wolfram Sang @ 2020-05-19 7:00 UTC (permalink / raw)
To: Bibby Hsieh
Cc: Bartosz Golaszewski, linux-i2c, tfiga, drinkcat, srv_heupstream,
robh+dt, mark.rutland, devicetree, Rafael J . Wysocki
In-Reply-To: <20200519065323.GC1094@ninjato>
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]
On Tue, May 19, 2020 at 08:53:23AM +0200, Wolfram Sang wrote:
> On Tue, Apr 28, 2020 at 02:18:12PM +0800, Bibby Hsieh wrote:
> > In some platforms, they disable the power-supply of i2c due
> > to power consumption reduction. This patch add bus-supply property.
> >
> > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>
> Applied to for-next, thanks! +1 for the comments Rob made, please add
> given tags if you didn't make further changes.
Waiting for v15 because I found issues in patch 2, so remoeved again.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v14 2/2] i2c: core: support bus regulator controlling in adapter
From: Wolfram Sang @ 2020-05-19 6:59 UTC (permalink / raw)
To: Bibby Hsieh
Cc: Bartosz Golaszewski, linux-i2c, tfiga, drinkcat, srv_heupstream,
robh+dt, mark.rutland, devicetree, Rafael J . Wysocki
In-Reply-To: <20200428061813.27072-3-bibby.hsieh@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]
On Tue, Apr 28, 2020 at 02:18:13PM +0800, Bibby Hsieh wrote:
> Although in the most platforms, the bus power of i2c
> are alway on, some platforms disable the i2c bus power
> in order to meet low power request.
>
> We get and enable bulk regulator in i2c adapter device.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/i2c/i2c-core-base.c | 82 +++++++++++++++++++++++++++++++++++++
> include/linux/i2c.h | 2 +
> 2 files changed, 84 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 5cc0b0ec5570..f81b42a4ed07 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -313,6 +313,7 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
> static int i2c_device_probe(struct device *dev)
> {
> struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap = client->adapter;
You are accessing client before the NULL pointer check.
> @@ -414,6 +421,7 @@ static int i2c_device_probe(struct device *dev)
> static int i2c_device_remove(struct device *dev)
> {
> struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap = client->adapter;
Same here.
> +static int i2c_suspend_late(struct device *dev)
> +{
> + struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap = client->adapter;
> + int err;
> +
> + err = pm_generic_suspend_late(&client->dev);
> + if (err)
> + return err;
> +
> + if (!pm_runtime_status_suspended(&client->dev))
> + return regulator_disable(adap->bus_regulator);
> +
> + return err;
Can be 'return 0'.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2 3/3] iio: magnetometer: ak8975: Add gpio reset support
From: Jonathan Albrieux @ 2020-05-19 6:57 UTC (permalink / raw)
To: linux-kernel
Cc: Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jonathan Cameron,
Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Thomas Gleixner, Jonathan Cameron, Jilayne Lovejoy
In-Reply-To: <20200519065749.4624-1-jonathan.albrieux@gmail.com>
According to AK09911 datasheet, if reset gpio is provided then
deassert reset on ak8975_power_on and assert reset on ak8975_power_off.
Without reset's deassertion during ak8975_power_on, driver's probe fails on
ak8975_who_i_am while checking for device identity for AK09911 chip
AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheed says that, if not used, reset pin should be connected
to VID. This patch emulates this situation
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
---
drivers/iio/magnetometer/ak8975.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
index 3c881541ae72..84dea520db02 100644
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@ -358,6 +358,7 @@ struct ak8975_data {
u8 asa[3];
long raw_to_gauss[3];
struct gpio_desc *eoc_gpiod;
+ struct gpio_desc *reset_gpiod;
int eoc_irq;
wait_queue_head_t data_ready_queue;
unsigned long flags;
@@ -384,10 +385,13 @@ static int ak8975_power_on(const struct ak8975_data *data)
"Failed to enable specified Vid supply\n");
return ret;
}
+
+ gpiod_set_value_cansleep(data->reset_gpiod, 0);
+
/*
- * According to the datasheet the power supply rise time i 200us
+ * According to the datasheet the power supply rise time is 200us
* and the minimum wait time before mode setting is 100us, in
- * total 300 us. Add some margin and say minimum 500us here.
+ * total 300us. Add some margin and say minimum 500us here.
*/
usleep_range(500, 1000);
return 0;
@@ -396,6 +400,8 @@ static int ak8975_power_on(const struct ak8975_data *data)
/* Disable attached power regulator if any. */
static void ak8975_power_off(const struct ak8975_data *data)
{
+ gpiod_set_value_cansleep(data->reset_gpiod, 1);
+
regulator_disable(data->vid);
regulator_disable(data->vdd);
}
@@ -839,6 +845,7 @@ static int ak8975_probe(struct i2c_client *client,
struct ak8975_data *data;
struct iio_dev *indio_dev;
struct gpio_desc *eoc_gpiod;
+ struct gpio_desc *reset_gpiod;
const void *match;
unsigned int i;
int err;
@@ -856,6 +863,16 @@ static int ak8975_probe(struct i2c_client *client,
if (eoc_gpiod)
gpiod_set_consumer_name(eoc_gpiod, "ak_8975");
+ /*
+ * According to AK09911 datasheet, if reset gpio is provided then
+ * deassert reset on ak8975_power_on and assert reset on
+ * ak8975_power_off.
+ */
+ reset_gpiod = devm_gpiod_get_optional(&client->dev,
+ "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(reset_gpiod))
+ return PTR_ERR(reset_gpiod);
+
/* Register with IIO */
indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
if (indio_dev == NULL)
@@ -866,6 +883,7 @@ static int ak8975_probe(struct i2c_client *client,
data->client = client;
data->eoc_gpiod = eoc_gpiod;
+ data->reset_gpiod = reset_gpiod;
data->eoc_irq = 0;
err = iio_read_mount_matrix(&client->dev, "mount-matrix", &data->orientation);
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Jonathan Albrieux @ 2020-05-19 6:57 UTC (permalink / raw)
To: linux-kernel
Cc: Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jonathan Cameron,
Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Thomas Gleixner, Jonathan Cameron, Rob Herring
In-Reply-To: <20200519065749.4624-1-jonathan.albrieux@gmail.com>
Add reset-gpio support.
Without reset's deassertion during ak8975_power_on, driver's probe fails on
ak8975_who_i_am while checking for device identity for AK09911 chip
AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheed says that, if not used, reset pin should be connected
to VID. This patch emulates this situation
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
---
.../devicetree/bindings/iio/magnetometer/ak8975.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
index 86e3efa693a8..a82c0ff5d098 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
@@ -37,6 +37,9 @@ properties:
mount-matrix:
description: an optional 3x3 mounting rotation matrix
+ reset-gpio:
+ description: an optional pin needed for AK09911 to set the reset state
+
required:
- compatible
- reg
@@ -53,6 +56,7 @@ examples:
reg = <0x0c>;
gpios = <&gpj0 7 0>;
vdd-supply = <&ldo_3v3_gnss>;
+ reset-gpio = <&msmgpio 111 1>;
mount-matrix = "-0.984807753012208", /* x0 */
"0", /* y0 */
"-0.173648177666930", /* z0 */
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: iio: magnetometer: ak8975: convert txt format to yaml
From: Jonathan Albrieux @ 2020-05-19 6:57 UTC (permalink / raw)
To: linux-kernel
Cc: Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jonathan Cameron,
Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Thomas Gleixner, Jonathan Cameron, Rob Herring
In-Reply-To: <20200519065749.4624-1-jonathan.albrieux@gmail.com>
Converts documentation from txt format to yaml
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
---
.../bindings/iio/magnetometer/ak8975.txt | 30 ---------
.../bindings/iio/magnetometer/ak8975.yaml | 66 +++++++++++++++++++
2 files changed, 66 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
deleted file mode 100644
index aa67ceb0d4e0..000000000000
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* AsahiKASEI AK8975 magnetometer sensor
-
-Required properties:
-
- - compatible : should be "asahi-kasei,ak8975"
- - reg : the I2C address of the magnetometer
-
-Optional properties:
-
- - gpios : should be device tree identifier of the magnetometer DRDY pin
- - vdd-supply: an optional regulator that needs to be on to provide VDD
- - mount-matrix: an optional 3x3 mounting rotation matrix
-
-Example:
-
-ak8975@c {
- compatible = "asahi-kasei,ak8975";
- reg = <0x0c>;
- gpios = <&gpj0 7 0>;
- vdd-supply = <&ldo_3v3_gnss>;
- mount-matrix = "-0.984807753012208", /* x0 */
- "0", /* y0 */
- "-0.173648177666930", /* z0 */
- "0", /* x1 */
- "-1", /* y1 */
- "0", /* z1 */
- "-0.173648177666930", /* x2 */
- "0", /* y2 */
- "0.984807753012208"; /* z2 */
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
new file mode 100644
index 000000000000..86e3efa693a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/ak8975.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AsahiKASEI AK8975 magnetometer sensor
+
+maintainers:
+ - can't find a mantainer, author is Laxman Dewangan <ldewangan@nvidia.com>
+
+properties:
+ compatible:
+ enum:
+ - "asahi-kasei,ak8975"
+ - "ak8975"
+ - "asahi-kasei,ak8963"
+ - "ak8963"
+ - "asahi-kasei,ak09911"
+ - "ak09911"
+ - "asahi-kasei,ak09912"
+ - "ak09912"
+
+ reg:
+ maxItems: 1
+ description: the I2C address of the magnetometer
+
+ gpios:
+ description: should be device tree identifier of the magnetometer DRDY pin
+
+ vdd-supply:
+ maxItems: 1
+ description: |
+ an optional regulator that needs to be on to provide VDD power to
+ the sensor.
+
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c@78b7000 {
+ reg = <0x78b6000 0x600>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ak8975@c {
+ compatible = "asahi-kasei,ak8975";
+ reg = <0x0c>;
+ gpios = <&gpj0 7 0>;
+ vdd-supply = <&ldo_3v3_gnss>;
+ mount-matrix = "-0.984807753012208", /* x0 */
+ "0", /* y0 */
+ "-0.173648177666930", /* z0 */
+ "0", /* x1 */
+ "-1", /* y1 */
+ "0", /* z1 */
+ "-0.173648177666930", /* x2 */
+ "0", /* y2 */
+ "0.984807753012208"; /* z2 */
+ };
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/3] iio: magnetometer: ak8975: Add gpio reset support
From: Jonathan Albrieux @ 2020-05-19 6:57 UTC (permalink / raw)
To: linux-kernel
Cc: Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jonathan Cameron,
Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Thomas Gleixner
Convert documentation from txt format to yaml. Add documentation about
reset-gpio.
Deassert reset on ak8975_power_on, assert reset on ak8975_power_off.
Without reset's deassertion during ak8975_power_on, driver's probe fails
on ak8975_who_i_am while checking for device identity for AK09911 chip
AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheed says that, if not used, reset pin should be connected
to VID. This patch emulates this situation
Jonathan Albrieux (3):
dt-bindings: iio: magnetometer: ak8975: convert txt format to yaml
dt-bindings: iio: magnetometer: ak8975: add gpio reset support
iio: magnetometer: ak8975: Add gpio reset support
.../bindings/iio/magnetometer/ak8975.txt | 30 --------
.../bindings/iio/magnetometer/ak8975.yaml | 70 +++++++++++++++++++
drivers/iio/magnetometer/ak8975.c | 22 +++++-
3 files changed, 90 insertions(+), 32 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
--
2.17.1
^ permalink raw reply
* Re: [PATCH v14 1/2] dt-binding: i2c: add bus-supply property
From: Wolfram Sang @ 2020-05-19 6:53 UTC (permalink / raw)
To: Bibby Hsieh
Cc: Bartosz Golaszewski, linux-i2c, tfiga, drinkcat, srv_heupstream,
robh+dt, mark.rutland, devicetree, Rafael J . Wysocki
In-Reply-To: <20200428061813.27072-2-bibby.hsieh@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
On Tue, Apr 28, 2020 at 02:18:12PM +0800, Bibby Hsieh wrote:
> In some platforms, they disable the power-supply of i2c due
> to power consumption reduction. This patch add bus-supply property.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Applied to for-next, thanks! +1 for the comments Rob made, please add
given tags if you didn't make further changes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1 4/4] of: platform: Batch fwnode parsing when adding all top level devices
From: Saravana Kannan @ 2020-05-19 6:48 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring, Frank Rowand,
Len Brown, Android Kernel Team, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
ACPI Devel Maling List, Ji Luo, Linux Samsung SOC
In-Reply-To: <e0f9211d-9cf6-a12d-eb63-df06910920ed@samsung.com>
On Mon, May 18, 2020 at 11:25 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> Hi Saravana,
>
> On 15.05.2020 07:35, Saravana Kannan wrote:
> > The fw_devlink_pause() and fw_devlink_resume() APIs allow batching the
> > parsing of the device tree nodes when a lot of devices are added. This
> > will significantly cut down parsing time (as much a 1 second on some
> > systems). So, use them when adding devices for all the top level device
> > tree nodes in a system.
> >
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
>
> This patch recently landed in linux-next 20200518. Sadly, it causes
> regression on Samsung Exynos5433-based TM2e board:
>
> s3c64xx-spi 14d30000.spi: Failed to get RX DMA channel
> s3c64xx-spi 14d50000.spi: Failed to get RX DMA channel
> s3c64xx-spi 14d30000.spi: Failed to get RX DMA channel
> s3c64xx-spi 14d50000.spi: Failed to get RX DMA channel
> s3c64xx-spi 14d30000.spi: Failed to get RX DMA channel
>
> Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 50 Comm: kworker/0:1 Not tainted 5.7.0-rc5+ #701
> Hardware name: Samsung TM2E board (DT)
> Workqueue: events deferred_probe_work_func
> pstate: 60000005 (nZCv daif -PAN -UAO)
> pc : samsung_i2s_probe+0x768/0x8f0
> lr : samsung_i2s_probe+0x688/0x8f0
> ...
> Call trace:
> samsung_i2s_probe+0x768/0x8f0
> platform_drv_probe+0x50/0xa8
> really_probe+0x108/0x370
> driver_probe_device+0x54/0xb8
> __device_attach_driver+0x90/0xc0
> bus_for_each_drv+0x70/0xc8
> __device_attach+0xdc/0x140
> device_initial_probe+0x10/0x18
> bus_probe_device+0x94/0xa0
> deferred_probe_work_func+0x70/0xa8
> process_one_work+0x2a8/0x718
> worker_thread+0x48/0x470
> kthread+0x134/0x160
> ret_from_fork+0x10/0x1c
> Code: 17ffffaf d503201f f94086c0 91003000 (88dffc00)
> ---[ end trace ccf721c9400ddbd6 ]---
> Kernel panic - not syncing: Fatal exception
> SMP: stopping secondary CPUs
> Kernel Offset: disabled
> CPU features: 0x090002,24006087
> Memory Limit: none
>
> ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Both issues, the lack of DMA for SPI device and Synchronous abort in I2S
> probe are new after applying this patch. I'm trying to investigate which
> resources are missing and why. The latter issue means typically that the
> registers for the given device has been accessed without enabling the
> needed clocks or power domains.
Did you try this copy-pasta fix that I sent later?
https://lore.kernel.org/lkml/20200517173453.157703-1-saravanak@google.com/
Not every system would need it (my test setup didn't), but it helps some cases.
If that fix doesn't help, then some tips for debugging the failing drivers.
What this pause/resume patch effectively (not explicitly) does is:
1. Doesn't immediately probe the devices as they are added in
of_platform_default_populate_init()
2. Adds them in order to the deferred probe list.
3. Then kicks off deferred probe on them in the order they were added.
These drivers are just not handling -EPROBE_DEFER correctly or
assuming probe order and that's causing these issues.
So, we can either fix that or you can try adding some code to flush
the deferred probe workqueue at the end of fw_devlink_resume().
Let me know how it goes.
Thanks,
Saravana
^ permalink raw reply
* Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller
From: Thinh Nguyen @ 2020-05-19 6:46 UTC (permalink / raw)
To: Jun Li, Felipe Balbi, Jun Li
Cc: John Stultz, lkml, Yu Chen, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, ShuFan Lee, Heikki Krogerus, Suzuki K Poulose,
Chunfeng Yun, Hans de Goede, Andy Shevchenko, Valentin Schneider,
Jack Pham, Linux USB List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Peter Chen
In-Reply-To: <db7447c2-a39d-361f-8b35-a1d5c2705c89@synopsys.com>
Thinh Nguyen wrote:
> Jun Li wrote:
>>> -----Original Message-----
>>> From: Felipe Balbi <balbif@gmail.com> On Behalf Of Felipe Balbi
>>> Sent: 2020年5月16日 19:57
>>> To: Jun Li <jun.li@nxp.com>; Thinh Nguyen <Thinh.Nguyen@synopsys.com>; Jun Li
>>> <lijun.kernel@gmail.com>
>>> Cc: John Stultz <john.stultz@linaro.org>; lkml <linux-kernel@vger.kernel.org>; Yu
>>> Chen <chenyu56@huawei.com>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Rob
>>> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; ShuFan Lee
>>> <shufan_lee@richtek.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
>>> Suzuki K Poulose <suzuki.poulose@arm.com>; Chunfeng Yun
>>> <chunfeng.yun@mediatek.com>; Hans de Goede <hdegoede@redhat.com>; Andy Shevchenko
>>> <andy.shevchenko@gmail.com>; Valentin Schneider <valentin.schneider@arm.com>;
>>> Jack Pham <jackp@codeaurora.org>; Linux USB List <linux-usb@vger.kernel.org>; open
>>> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>;
>>> Peter Chen <peter.chen@nxp.com>; Thinh Nguyen <Thinh.Nguyen@synopsys.com>
>>> Subject: RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device
>>> controller
>>>
>>>
>>> Hi,
>>>
>>> Jun Li <jun.li@nxp.com> writes:
>>>>>>> Hi Thinh, could you comment this?
>>>>>> You only need to wake up the usb2 phy when issuing the command
>>>>>> while running in highspeed or below. If you're running in SS or
>>>>>> higher, internally the controller does it for you for usb3 phy. In
>>>>>> Jun's case, it seems like it takes longer for his phy to wake up.
>>>>>>
>>>>>> IMO, in this case, I think it's fine to increase the command timeout.
>>>>> Is there an upper limit to this? Is 32k clock the slowest that can be
>>>>> fed to the PHY as a suspend clock?
>>>> Yes, 32K clock is the slowest, Per DWC3 document on Power Down Scale
>>>> (bits 31:19 of GCTL):
>>>>
>>>> "Power Down Scale (PwrDnScale)
>>>> The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock source to
>>>> a small part of the USB3 controller that operates when the SS PHY is
>>>> in its lowest power (P3) state, and therefore does not provide a clock.
>>>> The Power Down Scale field specifies how many suspend_clk periods fit
>>>> into a 16 kHz clock period. When performing the division, round up the
>>>> remainder.
>>>> For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz Suspend
>>>> clock, Power Down Scale = 25000 kHz/16 kHz = 13'd1563 (rounder up)
>>>> Note:
>>>> - Minimum Suspend clock frequency is 32 kHz
>>>> - Maximum Suspend clock frequency is 125 MHz"
>>> Cool, now do we have an upper bound for how many clock cycles it takes to wake up
>>> the PHY?
>> My understanding is this ep command does not wake up the SS PHY,
>> the SS PHY still stays at P3 when execute this ep command. The time
>> required here is to wait controller complete something for this ep
>> command with 32K clock.
> Sorry I made a mistake. You're right. Just checked with one of the RTL
> engineers, and it doesn't need to wake up the phy. However, if it is eSS
> speed, it may take longer time as the command may be completing with the
> suspend clock.
>
What's the value for GCTL[7:6]?
BR,
Thinh
^ permalink raw reply
* Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller
From: Thinh Nguyen @ 2020-05-19 6:28 UTC (permalink / raw)
To: Jun Li, Felipe Balbi, Thinh Nguyen, Jun Li
Cc: John Stultz, lkml, Yu Chen, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, ShuFan Lee, Heikki Krogerus, Suzuki K Poulose,
Chunfeng Yun, Hans de Goede, Andy Shevchenko, Valentin Schneider,
Jack Pham, Linux USB List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Peter Chen
In-Reply-To: <VE1PR04MB6528A50EA40BF40E4B09793789B90@VE1PR04MB6528.eurprd04.prod.outlook.com>
Jun Li wrote:
>> -----Original Message-----
>> From: Felipe Balbi <balbif@gmail.com> On Behalf Of Felipe Balbi
>> Sent: 2020年5月16日 19:57
>> To: Jun Li <jun.li@nxp.com>; Thinh Nguyen <Thinh.Nguyen@synopsys.com>; Jun Li
>> <lijun.kernel@gmail.com>
>> Cc: John Stultz <john.stultz@linaro.org>; lkml <linux-kernel@vger.kernel.org>; Yu
>> Chen <chenyu56@huawei.com>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Rob
>> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; ShuFan Lee
>> <shufan_lee@richtek.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
>> Suzuki K Poulose <suzuki.poulose@arm.com>; Chunfeng Yun
>> <chunfeng.yun@mediatek.com>; Hans de Goede <hdegoede@redhat.com>; Andy Shevchenko
>> <andy.shevchenko@gmail.com>; Valentin Schneider <valentin.schneider@arm.com>;
>> Jack Pham <jackp@codeaurora.org>; Linux USB List <linux-usb@vger.kernel.org>; open
>> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>;
>> Peter Chen <peter.chen@nxp.com>; Thinh Nguyen <Thinh.Nguyen@synopsys.com>
>> Subject: RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device
>> controller
>>
>>
>> Hi,
>>
>> Jun Li <jun.li@nxp.com> writes:
>>>>>> Hi Thinh, could you comment this?
>>>>> You only need to wake up the usb2 phy when issuing the command
>>>>> while running in highspeed or below. If you're running in SS or
>>>>> higher, internally the controller does it for you for usb3 phy. In
>>>>> Jun's case, it seems like it takes longer for his phy to wake up.
>>>>>
>>>>> IMO, in this case, I think it's fine to increase the command timeout.
>>>> Is there an upper limit to this? Is 32k clock the slowest that can be
>>>> fed to the PHY as a suspend clock?
>>> Yes, 32K clock is the slowest, Per DWC3 document on Power Down Scale
>>> (bits 31:19 of GCTL):
>>>
>>> "Power Down Scale (PwrDnScale)
>>> The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock source to
>>> a small part of the USB3 controller that operates when the SS PHY is
>>> in its lowest power (P3) state, and therefore does not provide a clock.
>>> The Power Down Scale field specifies how many suspend_clk periods fit
>>> into a 16 kHz clock period. When performing the division, round up the
>>> remainder.
>>> For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz Suspend
>>> clock, Power Down Scale = 25000 kHz/16 kHz = 13'd1563 (rounder up)
>>> Note:
>>> - Minimum Suspend clock frequency is 32 kHz
>>> - Maximum Suspend clock frequency is 125 MHz"
>> Cool, now do we have an upper bound for how many clock cycles it takes to wake up
>> the PHY?
> My understanding is this ep command does not wake up the SS PHY,
> the SS PHY still stays at P3 when execute this ep command. The time
> required here is to wait controller complete something for this ep
> command with 32K clock.
Sorry I made a mistake. You're right. Just checked with one of the RTL
engineers, and it doesn't need to wake up the phy. However, if it is eSS
speed, it may take longer time as the command may be completing with the
suspend clock.
BR,
Thinh
>
>> Then we can just set the time to that upper bound.
> Per my test with trace, the time is about 400us(~13 cycles).
>
> Thanks
> Li Jun
>> --
>> balbi
^ permalink raw reply
* Re: [PATCH v1 4/4] of: platform: Batch fwnode parsing when adding all top level devices
From: Marek Szyprowski @ 2020-05-19 6:25 UTC (permalink / raw)
To: Saravana Kannan, Greg Kroah-Hartman, Rafael J. Wysocki,
Rob Herring, Frank Rowand, Len Brown
Cc: kernel-team, linux-kernel, devicetree, linux-acpi, Ji Luo,
'Linux Samsung SOC'
In-Reply-To: <20200515053500.215929-5-saravanak@google.com>
Hi Saravana,
On 15.05.2020 07:35, Saravana Kannan wrote:
> The fw_devlink_pause() and fw_devlink_resume() APIs allow batching the
> parsing of the device tree nodes when a lot of devices are added. This
> will significantly cut down parsing time (as much a 1 second on some
> systems). So, use them when adding devices for all the top level device
> tree nodes in a system.
>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
This patch recently landed in linux-next 20200518. Sadly, it causes
regression on Samsung Exynos5433-based TM2e board:
s3c64xx-spi 14d30000.spi: Failed to get RX DMA channel
s3c64xx-spi 14d50000.spi: Failed to get RX DMA channel
s3c64xx-spi 14d30000.spi: Failed to get RX DMA channel
s3c64xx-spi 14d50000.spi: Failed to get RX DMA channel
s3c64xx-spi 14d30000.spi: Failed to get RX DMA channel
Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 50 Comm: kworker/0:1 Not tainted 5.7.0-rc5+ #701
Hardware name: Samsung TM2E board (DT)
Workqueue: events deferred_probe_work_func
pstate: 60000005 (nZCv daif -PAN -UAO)
pc : samsung_i2s_probe+0x768/0x8f0
lr : samsung_i2s_probe+0x688/0x8f0
...
Call trace:
samsung_i2s_probe+0x768/0x8f0
platform_drv_probe+0x50/0xa8
really_probe+0x108/0x370
driver_probe_device+0x54/0xb8
__device_attach_driver+0x90/0xc0
bus_for_each_drv+0x70/0xc8
__device_attach+0xdc/0x140
device_initial_probe+0x10/0x18
bus_probe_device+0x94/0xa0
deferred_probe_work_func+0x70/0xa8
process_one_work+0x2a8/0x718
worker_thread+0x48/0x470
kthread+0x134/0x160
ret_from_fork+0x10/0x1c
Code: 17ffffaf d503201f f94086c0 91003000 (88dffc00)
---[ end trace ccf721c9400ddbd6 ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x090002,24006087
Memory Limit: none
---[ end Kernel panic - not syncing: Fatal exception ]---
Both issues, the lack of DMA for SPI device and Synchronous abort in I2S
probe are new after applying this patch. I'm trying to investigate which
resources are missing and why. The latter issue means typically that the
registers for the given device has been accessed without enabling the
needed clocks or power domains.
> ---
> drivers/of/platform.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 3371e4a06248..55d719347810 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -538,7 +538,9 @@ static int __init of_platform_default_populate_init(void)
> }
>
> /* Populate everything else. */
> + fw_devlink_pause();
> of_platform_default_populate(NULL, NULL, NULL);
> + fw_devlink_resume();
>
> return 0;
> }
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox