On 2019-10-23 9:29 AM, Viorel Suman wrote:
> On Mi, 2019-08-21 at 20:39 +0000, Leonard Crestez wrote:
>> The audio PLLs should run below 650 mHz so please use 393216000 and
>> 361267200 instead of 786432000 and 722534400. For the 8mm equivalent see
>> commit 053a4ffe2988 (&
On 11.10.2019 16:02, Joel Colledge wrote:
> On Fri, Oct 11, 2019 at 2:47 PM Leonard Crestez
> wrote:
>> This struct printk_log is quite small, I wonder if it's possible to do a
>> single read for each log entry? This might make lx-dmesg faster because
>> of fewer roundtri
On 11.10.2019 15:25, Joel Colledge wrote:
> When CONFIG_PRINTK_CALLER is set, struct printk_log contains an
> additional member caller_id. This affects the offset of the log text.
> Account for this by using the type information from gdb to determine all
> the offsets instead of using hardcoded
On 10.10.2019 18:14, Jan Kiszka wrote:
> On 25.09.19 17:03, Joel Colledge wrote:
>> When CONFIG_PRINTK_CALLER is set, struct printk_log contains an
>> additional member caller_id. As a result, the offset of the log text is
>> different.
>>
>> This fixes the following error:
>>
>>(gdb) lx-dmesg
On 2019-09-27 4:20 AM, Anson Huang wrote:
>> On 2019-09-26 1:06 PM, Marco Felsch wrote:
>>> On 19-09-26 08:03, Anson Huang wrote:
> On 19-09-25 18:07, Anson Huang wrote:
>> The SCU firmware does NOT always have return value stored in
>> message header's function element even the API
On 27.09.2019 12:06, Marco Felsch wrote:
> Hi Anson, Leonard,
>
> On 19-09-27 01:20, Anson Huang wrote:
>> Hi, Leonard
>>
>>> On 2019-09-26 1:06 PM, Marco Felsch wrote:
On 19-09-26 08:03, Anson Huang wrote:
>> On 19-09-25 18:07, Anson Huang wrote:
>>> The SCU firmware does NOT always
On 27.09.2019 04:20, Anson Huang wrote:
>> On 2019-09-26 1:06 PM, Marco Felsch wrote:
>>> On 19-09-26 08:03, Anson Huang wrote:
> On 19-09-25 18:07, Anson Huang wrote:
>> The SCU firmware does NOT always have return value stored in
>> message header's function element even the API has
On 2019-09-26 1:06 PM, Marco Felsch wrote:
> On 19-09-26 08:03, Anson Huang wrote:
>>> On 19-09-25 18:07, Anson Huang wrote:
The SCU firmware does NOT always have return value stored in message
header's function element even the API has response data, those
special APIs are defined
On 25.09.2019 13:09, Anson Huang wrote:
> The SCU firmware does NOT always have return value stored in message
> header's function element even the API has response data, those special
> APIs are defined as void function in SCU firmware, so they should be
> treated as return success always.
>
>
On 22.09.2019 21:56, Sasha Levin wrote:
> From: Leonard Crestez
>
> [ Upstream commit 0ef7c7cce43f6ecc2b96d447e69b2900a9655f7c ]
This will introduce an "unused variable warning" unless you also
cherry-pick commit 0465814831a9 ("PM / devfreq: passive: fix compiler
w
On 04.09.2019 05:35, Andrey Smirnov wrote:
> Returning -EBUSY from platform device's .remove() callback won't stop
> the removal process, so the code in caam_jr_remove() is not going to
> have the desired effect of preventing JR from being removed.
>
> In order to be able to deal with removal of
On 2019-09-12 5:57 AM, Anson Huang wrote:
> Add "opp-suspend" property for i.MX7D to make sure system
> suspend with max available opp.
>
> Signed-off-by: Anson Huang
Reviewed-by: Leonard Crestez
11 1200
>
> Signed-off-by: Anson Huang
Reviewed-by: Leonard Crestez
Are you going to add the 500mhz OPP as well?
LL clock structure for every
> module which uses same type of PLL, e.g., audio/video/dram use
> 1443X PLL, arm/gpu/vpu/sys use 1416X PLL, define 2 PLL clock
> structure for each group is enough. >
> Signed-off-by: Anson Huang
For both:
Reviewed-by: Leonard Crestez
On 05.09.2019 12:59, Anson Huang wrote:
> Many i.MX8M SoCs use same 1443X/1416X PLL, such as i.MX8MM,
> i.MX8MN and later i.MX8M SoCs, moving these PLL definitions
> to common place can save a lot of duplicated code on each
> platform.
There are lots of similarities between imx8m clocks, do you
On 2019-09-04 10:14 AM, Anson Huang wrote:
> The SCU firmware API for getting UID should have response,
> otherwise, the message stored in function stack could be
> released and then the response data received from SCU will be
> stored into that released stack and cause kernel NULL pointer
> dump.
On 27.08.2019 04:51, Anson Huang wrote:
>> In an earlier series the CLK_IS_CRITICAL flags was removed from the TMU
>> clock so if the thermal driver doesn't explicitly enable it the system will
>> hang
>> on probe. This is what happens in linux-next right now!
>
> The thermal driver should be
On 7/30/2019 5:31 AM, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> Some platforms like i.MX8MQ has clock control for this module,
> need to add clock operations to make sure the driver is working
> properly.
>
> Signed-off-by: Anson Huang
> Reviewed-by: Guido Günther
This series looks
On 26.08.2019 14:50, Stephen Rothwell wrote:
> Hi all,
>
> After merging the devfreq tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/devfreq/governor_passive.c: In function
> 'devfreq_passive_event_handler':
> drivers/devfreq/governor_passive.c:152:17:
On 22.08.2019 23:06, Andrey Smirnov wrote:
>> On 31.07.2019 21:01, Andrey Smirnov wrote:
>>> With commit b5bbe2235361 ("usb: phy: mxs: Disable external charger
>>> detect in mxs_phy_hw_init()") in tree all of the necessary charger
>>> setup is done by the USB PHY driver which covers all of the
On 31.07.2019 21:01, Andrey Smirnov wrote:
> With commit b5bbe2235361 ("usb: phy: mxs: Disable external charger
> detect in mxs_phy_hw_init()") in tree all of the necessary charger
> setup is done by the USB PHY driver which covers all of the affected
> i.MX6 SoCs.
>
> NOTE: Imx_anatop_init() was
On 22.08.2019 12:18, Peng Fan wrote:
>> Subject: Re: [PATCH] clk: imx: pll14xx: avoid glitch when set rate
>>
>> On 20.08.2019 05:17, Peng Fan wrote:
>>> According to PLL1443XA and PLL1416X spec, "When BYPASS is 0 and RESETB
>>> is changed from 0 to 1, FOUT starts to output unstable clock until
On 20.08.2019 05:17, Peng Fan wrote:
> According to PLL1443XA and PLL1416X spec,
> "When BYPASS is 0 and RESETB is changed from 0 to 1, FOUT starts to
> output unstable clock until lock time passes. PLL1416X/PLL1443XA may
> generate a glitch at FOUT."
>
> So set BYPASS when RESETB is changed from
On 28.07.2019 18:20, Daniel Baluta wrote:
> From: Abel Vesa
>
> Add the initial configuration for clocks that need default parent and rate
> setting. This is based on the vendor tree clock provider parents and rates
> configuration except this is doing the setup in dts rather then using clock
>
On 15.08.2019 14:18, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> Enable i2c1 on i.MX8MN DDR4 EVK board.
>
> Signed-off-by: Anson Huang
Didn't see a cover letter but all 6 patches look good:
Reviewed-by: Leonard Crestez
Commit-ID: 4ce54af8b33d3e21ca935fc1b89b58cbba956051
Gitweb: https://git.kernel.org/tip/4ce54af8b33d3e21ca935fc1b89b58cbba956051
Author: Leonard Crestez
AuthorDate: Wed, 24 Jul 2019 15:53:24 +0300
Committer: Ingo Molnar
CommitDate: Thu, 25 Jul 2019 15:41:31 +0200
perf/core: Fix
pen
Signed-off-by: Leonard Crestez
---
I don't understand why PMUs outside the core are bound to a CPU anyway,
all this patch does is attempt to satisfy the assumptions made by
__perf_install_in_context and ctx_sched_out at init time so that lockdep
no longer complains.
ctx_sched_out asserts
Add initial support for frequency switching on pieces of the imx
interconnect fabric.
Uses clk_set_min_rate so that other subsytems can also impose minimum
rate requests.
Signed-off-by: Leonard Crestez
---
drivers/devfreq/Kconfig | 10 +++
drivers/devfreq/Makefile | 1 +
drivers
and sum them.
Signed-off-by: Leonard Crestez
---
drivers/devfreq/imx-devfreq.c | 135 ++
1 file changed, 135 insertions(+)
diff --git a/drivers/devfreq/imx-devfreq.c b/drivers/devfreq/imx-devfreq.c
index 3ee2d37883c6..fd4c8ffb8b4a 100644
--- a/drivers/devfreq/imx
ta-schemas/core.yaml#
+
+title: Generic i.MX bus frequency device
+
+maintainers:
+ - Leonard Crestez
+
+description: |
+ The i.MX SoC family has multiple buses for which clock frequency (and
sometimes
+ voltage) can be adjusted.
+
+ Some of those buses expose register areas mentioned in the m
.org/patch/11049429/
That part might not be accepted in clk and it might have to be moved to
devfreq also.
Leonard Crestez (3):
dt-bindings: devfreq: Add initial bindings for i.MX
PM / devfreq: Add imx driver
PM / devfreq: Add imx perf event support
.../devicetree/bindings/devfreq/imx.yaml
On 18.07.2019 21:24, Daniel Baluta wrote:
> On Thu, Jul 18, 2019 at 7:41 PM Rob Herring wrote:
>>
>> On Thu, Jul 18, 2019 at 9:13 AM Daniel Baluta wrote:
>>>
>>> This describes the DSP device tree node.
>>>
>>> Signed-off-by: Daniel Baluta
>>> + power-domains:
>>> +description:
>>> +
On 7/8/2019 10:55 AM, anson.hu...@nxp.com wrote:
> To reduce the suspend/resume latency, CPU's max supported frequency
> should be used during low level suspend/resume phase, "opp-suspend"
> property is NOT feasible since OPP defined in DT could be NOT supported
> according to speed garding and
On 7/4/2019 9:23 AM, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> Assign highest OPP as suspend OPP to reduce suspend/resume
> latency on i.MX8MM.
>
> Signed-off-by: Anson Huang
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
gly.
> > Fixes: f403a26c865b (arm64: dts: imx8mm: Add cpu speed grading and
all OPPs)
> Signed-off-by: Anson Huang
For both:
Reviewed-by: Leonard Crestez
The vendor tree goes through a lot of testing so switching to the exact
speed grading interpretation from there does make sense.
On 6/28/2019 9:16 AM, Anson Huang wrote:
>> From: Leonard Crestez
>>> From: Anson Huang
>>>
>>> According to latest datasheet (Rev.1, 10/2018) from below links, in
>>> the consumer datasheet, 1.5GHz is mentioned as highest opp but depends
>>> on
On 28.06.2019 06:37, anson.hu...@nxp.com wrote:
> According to latest datasheet (Rev.0.2, 04/2019) from below links,
> 1.8GHz is ONLY available for consumer part, so the market segment
> bits for 1.8GHz opp should ONLY available for consumer part accordingly.
>
> opp-hz =
On 28.06.2019 06:37, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> According to latest datasheet (Rev.1, 10/2018) from below links,
> in the consumer datasheet, 1.5GHz is mentioned as highest opp but
> depends on speed grading fuse, and in the industrial datasheet,
> 1.3GHz is mentioned as
This is like /sys/kernel/debug/pm/pm_genpd_summary except it's
accessible through a debugger.
This can be useful if the target crashes or hangs because power domains
were not properly enabled.
Signed-off-by: Leonard Crestez
---
scripts/gdb/linux/genpd.py | 83
al generic "lx-device-list" functions are included to enumerate
devices by bus and class:
(gdb) lx-device-list-bus usb
(gdb) lx-device-list-class
(gdb) lx-device-list-tree _bus
Similar information is available in /sys but pointer values are
deliberately hidden.
Signed-off-by: Leonard Cre
On 25.06.2019 15:51, Abel Vesa wrote:
> Add the initial configuration for clocks that need default parent and rate
> setting. This is based on the vendor tree clock provider parents and rates
> configuration except this is doing the setup in dts rather then using clock
> consumer API in a clock
On 6/17/2019 7:04 PM, Andrey Smirnov wrote:
> Simplify clock initialization code by converting it to use clk-bulk,
> devres and soc_device_match() match table. No functional change
> intended.
Subject is misspelled.
> +struct clk_bulk_caam {
> + const struct clk_bulk_data *clks;
> + int
On 3/13/2019 9:36 PM, Alexandre Bailon wrote:
>
> This adds support of i.MX SoC to interconnect framework.
> This is based on busfreq, from NXP's tree.
> This is is generic enough to be used to add support of interconnect
> framework to any i.MX SoC, and, even, this could used for some other
>
On 6/10/2019 5:08 PM, Marc Zyngier wrote:
> On 10/06/2019 14:55, Abel Vesa wrote:
>> On 19-06-10 14:39:02, Marc Zyngier wrote:
>>> On 10/06/2019 14:29, Abel Vesa wrote:
On 19-06-10 14:19:21, Mark Rutland wrote:
> On Mon, Jun 10, 2019 at 03:13:44PM +0300, Abel Vesa wrote:
>>
On 6/10/2019 3:15 PM, Abel Vesa wrote:
> i.MX8MQ is missing the wake_request signals from GIC to GPCv2. This indirectly
> breaks cpuidle support due to inability to wake target cores on IPIs.
>
> Now, in order to fix this, we can trigger IRQ 32 (hwirq 0) to all the cores by
> setting 12th bit in
On 6/4/2019 11:44 AM, Anson Huang wrote:
> As exemple, this series implements busfreq for i.MX8MM whose
> upstreaming is in progress. Because this relies on ATF to do the
> frequency scaling, it won't be hard make it work.
>
> I have similar question as previous reviewer, is there any
On 6/3/2019 4:33 AM, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> This patch adds i.MX8MN clock driver support.
> +#include "clk.h"
> +
> +#define PLL_1416X_RATE(_rate, _m, _p, _s)\
> + { \
> + .rate =
issue.
>
> Fixes: 43967d9b5a7c ("ARM: dts: imx7d-sdb: Assign corresponding power supply
> for LDOs")
> Reported-by: Leonard Crestez
> Signed-off-by: Anson Huang
Reviewed-by: Leonard Crestez
Other boards don't seem to be affected by the original series.
On 12.05.2019 12:57, Anson Huang wrote:
> On i.MX7D SDB board, sw2 supplies 1p0d/1p2 LDO, this patch assigns
> corresponding power supply for 1p0d/1p2 LDO to avoid confusion by
> below log:
>
> vdd1p0d: supplied by regulator-dummy
> vdd1p2: supplied by regulator-dummy
>
> With this patch, the
On 22.05.2019 16:40, Lucas Stach wrote:
> Am Mittwoch, den 22.05.2019, 13:30 + schrieb Leonard Crestez:
>> On 22.05.2019 16:13, Guido Günther wrote:
>>> Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions
>>> On Wed, May 08, 2019 at 02:40:18PM
On 5/24/2019 1:46 AM, Stephen Boyd wrote:
> Quoting Fabiano Rosas (2019-05-23 12:53:11)
>> diff --git a/scripts/gdb/linux/constants.py.in
>> b/scripts/gdb/linux/constants.py.in
>> index 1d73083da6cb..2efbec6b6b8d 100644
>> --- a/scripts/gdb/linux/constants.py.in
>> +++
On 22.05.2019 16:13, Guido Günther wrote:
> Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions
Fixed subject
> On Wed, May 08, 2019 at 02:40:18PM +0200, Guido Günther wrote:
>> Thanks for your comments. Let's try s.th. different then: identify by
>> bootrom, ocotop and
On 5/17/2019 8:49 AM, Anson Huang wrote:
> + root = of_find_node_by_path("/");
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,imx-scu");
It's possibly not very important for root or FW communication nodes but
you should probably of_node_put those back.
;
> Signed-off-by: Anson Huang
For both:
Reviewed-by: Leonard Crestez
I was thinking that maybe you could of_node_put as soon as you were done
with it but the model is read straight into soc_dev_attr so just freeing
everything at the end makes more sense.
On 20.05.2019 06:06, Peng Fan wrote:
> Introduce fusable-node property for i.MX OCOTP driver.
> The property will only be used by Firmware(eg. U-Boot) to
> runtime disable the nodes.
>
> Take i.MX6ULL for example, there are several parts that only
> have limited modules enabled controlled by
On 16.05.2019 06:24, Anson Huang wrote:
> Add i.MX SCU SoC info driver to support i.MX8QXP SoC, introduce
> driver dependency into Kconfig as CONFIG_IMX_SCU must be
> selected to support i.MX SCU SoC driver, also need to use
> platform driver model to make sure IMX_SCU driver is probed
> before
On 15.05.2019 04:09, Anson Huang wrote:
> Add macro for the SNVS clock of the i.MX8MQ.
>
> Signed-off-by: Anson Huang
For series (couldn't find a cover letter):
Reviewed-by: Leonard Crestez
/patch/10940303/
The conflict is easy to resolve but I don't mind resending if your
patches get accepted first. If should probably resend anyway to also add
gic clk to 8mq.
For series:
Reviewed-by: Leonard Crestez
On 15.05.2019 11:32, Anson Huang wrote:
> Add i.MX SCU SoC info driver to support i.MX8QXP SoC, introduce
> driver dependency into Kconfig as CONFIG_IMX_SCU must be
> selected to support i.MX SCU SoC driver, also need to use
> platform driver model to make sure IMX_SCU driver is probed
> before
On 15.03.2019 18:55, Alexandre Bailon wrote:
>> On Wed, Mar 13, 2019 at 12:33 PM Alexandre Bailon
>> wrote:
>>> As exemple, this series implements busfreq for i.MX8MM whose
>>> upstreaming is in progress. Because this relies on ATF to
>>> do the frequency scaling, it won't be hard make it work.
R_PTR error
>net: dsa: support of_get_mac_address new ERR_PTR error
>staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check
>net: usb: smsc: fix warning reported by kbuild test robot
> drivers/net/ethernet/freescale/fec_main.c | 2 +-
This f
On 03.05.2019 16:53, Guido Günther wrote:
> This is similar to what the BSP does and needed to e.g. determine
> necessary quirks for MIPI DSI.
>
> Signed-off-by: Guido Günther
>
> From the list discussion and changelog it's not clear to me why a
> different method was chosen for the B1 silicon
The clk rate is always stored in clk_core but might be out of date and
require calls to update from hardware.
Deal with that case by printing a (c) suffix.
Signed-off-by: Leonard Crestez
---
scripts/gdb/linux/clk.py | 21 ++---
scripts/gdb/linux/constants.py.in | 4
something else.
Applies to both list and hlist
Signed-off-by: Leonard Crestez
---
scripts/gdb/linux/lists.py | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/scripts/gdb/linux/lists.py b/scripts/gdb/linux/lists.py
index 55356b66f8ea..c487ddf09d38 100644
lternative workarounds would be
hacking away UL suffixes with sed or redefining BIT but relying on
gdb evaluation is easier and much more flexible.
Leonard Crestez (2):
scripts/gdb: Cleanup error handling in list helpers
scripts/gdb: Print cached rate in lx-clk-summary
scripts/gdb/linux/clk.py
gister'
>
> while CONFIG_SOC_BUS is not set, the building failed like this. This patch
> selects SOC_BUS to fix it.
>
> Reported-by: Hulk Robot
> Fixes: a7e26f356ca1 ("soc: imx: Add generic i.MX8 SoC driver")
> Suggested-by: Leonard Crestez
> Signed-off-by: YueHaibing
Reviewed-by: Leonard Crestez
On 4/24/2019 11:00 AM, Yue Haibing wrote:
> From: YueHaibing
>
> During randconfig builds, I occasionally run into an invalid configuration
>
> drivers/soc/imx/soc-imx8.o: In function `imx8_soc_init':
> soc-imx8.c:(.init.text+0x144): undefined reference to `soc_device_register'
>
> while
On 4/22/2019 11:18 PM, Stephen Boyd wrote:
> Quoting Leonard Crestez (2019-04-22 01:26:57)
>> diff --git a/scripts/gdb/linux/clk.py b/scripts/gdb/linux/clk.py
>> +class LxClkCoreLookup(gdb.Function):
>> +"""Find struct clk_core by name"""
On 4/22/2019 11:41 PM, Stephen Boyd wrote:
> Quoting Leonard Crestez (2019-04-22 01:26:56)
>> This allows easily examining kernel hlists in python.
>>
>> Signed-off-by: Leonard Crestez
>
>> +def hlist_for_each_entry(head, gdbtype, member):
>>
On 4/22/2019 9:46 AM, Anson Huang wrote:
>> -Original Message-
>> From: Anson Huang
>>> From: Shawn Guo [mailto:shawn...@kernel.org]
>>> On Sun, Apr 21, 2019 at 03:40:00PM +0800, Shawn Guo wrote:
On Thu, Apr 11, 2019 at 06:49:12AM +, Anson Huang wrote:
> i.MX8QXP is an ARMv8
Finding an individual clk_core requires walking the tree which can be
quite complicated so add a helper for easy access.
(gdb) print *(struct clk_scu*)$lx_clk_core_lookup("uart0_clk")->hw
Signed-off-by: Leonard Crestez
---
scripts/gdb/linux/clk.py | 23 +++
1
Add an lx-clk-summary command which prints a subset of
/sys/kernel/debug/clk/clk_summary.
This can be used to examine hangs caused by clk not being enabled.
Signed-off-by: Leonard Crestez
---
scripts/gdb/linux/clk.py | 46 ++
scripts/gdb/vmlinux-gdb.py
This allows easily examining kernel hlists in python.
Signed-off-by: Leonard Crestez
---
scripts/gdb/linux/lists.py | 23 +++
1 file changed, 23 insertions(+)
diff --git a/scripts/gdb/linux/lists.py b/scripts/gdb/linux/lists.py
index 1987d756b36b..55356b66f8ea 100644
Tested with openocd on imx but should be useful everywhere. It is common
for clk issues to lockup the system and make /sys inaccesible.
Not sure where to send this; there doesn't appear to be any list more
specific than LKML.
Leonard Crestez (3):
scripts/gdb: Add hlist utilities
scripts/gdb
On 3/28/2019 6:43 PM, Leonard Crestez wrote:
> On Fri, 2019-03-22 at 16:49 +, Abel Vesa wrote:
>> Add generic i.MX8 SoC driver along with the i.MX8MQ SoC specific code.
>> For now, only i.MX8MQ revision B1 is supported. For any other, i.MX8MQ
>> revision it will print 'unk
On Fri, 2019-04-12 at 07:04 -0600, Angus Ainslie (Purism) wrote:
> + {
> + clock-frequency = <40>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c1>;
> + status = "okay";
> +
> + pmic: pmic@4b {
> + reg = <0x4b>;
> + compatible =
On Fri, 2019-03-22 at 16:49 +, Abel Vesa wrote:
> Add generic i.MX8 SoC driver along with the i.MX8MQ SoC specific code.
> For now, only i.MX8MQ revision B1 is supported. For any other, i.MX8MQ
> revision it will print 'unknown'.
> +#define REV_B1 0x21
> +
>
On Wed, 2019-03-27 at 17:45 +, Marc Zyngier wrote:
> On 27/03/2019 16:06, Lucas Stach wrote:
> > Am Mittwoch, den 27.03.2019, 15:57 + schrieb Marc Zyngier:
> > > On 27/03/2019 15:44, Lucas Stach wrote:
> > > > Am Mittwoch, den 27.03.2019, 13:21 + schrieb Abel Vesa:
> > > > > This work
On Wed, 2019-03-27 at 17:06 +0100, Lucas Stach wrote:
> Am Mittwoch, den 27.03.2019, 15:57 + schrieb Marc Zyngier:
> > On 27/03/2019 15:44, Lucas Stach wrote:
> > > Am Mittwoch, den 27.03.2019, 13:21 + schrieb Abel Vesa:
> > > > This work is a workaround I'm looking into (more as a
On 3/15/19 11:31 AM, Alexandre Bailon wrote:
>>> This series is sent as RFC mostly because the current support of i.MX SoC
>>> won't
>>> benefit of busfreq framework, because the clocks' driver don't support
>>> interconnect / dram frequency scaling.
>>> As exemple, this series implements busfreq
On Wed, 2019-02-27 at 08:41 +, Abel Vesa wrote:
> On 19-02-26 13:34:52, Leonard Crestez wrote:
> > On Tue, 2019-02-26 at 10:53 +, Abel Vesa wrote:
> > > Add generic i.MX8 SoC driver along with the i.MX8MQ SoC specific code.
> > > For now, only i.MX8MQ revisi
On Tue, 2019-02-26 at 10:53 +, Abel Vesa wrote:
> Add generic i.MX8 SoC driver along with the i.MX8MQ SoC specific code.
> For now, only i.MX8MQ revision B1 is supported. For any other, i.MX8MQ
> revision it will print 'unknown'.
>
> + np = of_find_compatible_node(NULL, NULL,
> + return;
> +
> + /* Make sure we only quirk devices associated with this driver */
> + if (bus->dev.parent->parent->driver != _pcie_driver.driver)
> + return;
This looks like it would be enough to prevent interfering with other
dwc-based pci drivers.
Reviewed-by: Leonard Crestez
On Mon, 2019-02-25 at 17:02 +0100, Stefan Agner wrote:
> Define the length of the DBI registers and limit config space to its
> length. This makes sure that the kernel does not access registers
> beyond that point, avoiding the following abort on a i.MX 6Quad:
>
> +static void
On Mon, 2019-02-25 at 15:25 +0100, Stefan Agner wrote:
> Define the length of the DBI registers and limit config space to its
> length. This makes sure that the kernel does not access registers
> beyond that point, avoiding the following abort on a i.MX 6Quad:
> # cat
g all gpio interrupts at probe time until they are
explicitly requested by drivers.
Signed-off-by: Leonard Crestez
---
It's strange that nobody else has run into this problem, AMD hardware is
relatively common. Maybe firmware generally disables GPIO interrupts
itself?
This patch fixes boot but this s
On Wed, 2019-02-13 at 13:32 +, Anson Huang wrote:
> On NXP's i.MX SoCs with system controller inside, CPU frequency
> scaling can ONLY be done by system controller firmware, and it
> can ONLY be requested from secure mode, so Linux kernel has to
> call ARM SMC to trap to ARM-Trusted-Firmware
On Fri, 2019-01-25 at 01:03 +0900, Masahiro Yamada wrote:
> On Tue, Jan 22, 2019 at 1:17 AM Leonard Crestez
> wrote:
> >
> > On 1/7/2019 9:31 PM, Leonard Crestez wrote:
> > > The dts makefiles go through a lot of pointless churn when boards are
> > > adde
On 1/7/2019 9:31 PM, Leonard Crestez wrote:
> The dts makefiles go through a lot of pointless churn when boards are
> added. Many SOCs (such as imx) have very simple naming conventions for
> all boards using a certain chip and board listings can be easily
> collapsed using wildcar
On 1/14/19 2:56 AM, Shawn Guo wrote:
> On Fri, Jan 11, 2019 at 05:57:30AM +, Anson Huang wrote:
> > This patch adds cpuidle support for i.MX7ULP, 3 cpuidle
> > states supported as below:
> >
> > 1. WFI, just ARM wfi;
> > 2. WAIT mode, mapped to SoC's partial stop mode #3;
> > 3. STOP mode,
Use the wilddt function instead of listing dts files. This shrinks the
makefile and avoids needing future changes when boards are added.
Signed-off-by: Leonard Crestez
---
arch/arm64/boot/dts/freescale/Makefile | 25 -
1 file changed, 4 insertions(+), 21 deletions
$(dtstree)
* Also use wilddt in arm64/boot/dts/freescale
Series is against next-20190107, conflicts are to be expected as board
list keeps changing.
Leonard Crestez (3):
kbuild: Add wilddt function
ARM: dts: imx: Use wilddt function
arm64: dts: freescale: Use wilddt function
arch/arm/boot/dt
Use the wilddt function instead of listing imx6/7 dts files. This
shrinks the makefile and avoids needing future changes when boards are
added.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/Makefile | 201 ++---
1 file changed, 11 insertions(+), 190
-by: Leonard Crestez
---
scripts/Kbuild.include | 6 ++
1 file changed, 6 insertions(+)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 46bf1a073f5d..6b8c0cca07c1 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -197,10 +197,16 @@ clean := -f $(srctree
pplied by internal regulator."
The current pd_pcie is actually only for PCIE_PHY, the PCIE ip block is
actually inside the DISPLAY domain. Handle this by adding the pcie node
in both power domains.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6sx.dtsi | 19 ++-
1 file
Hello,
My Acer Nitro 5 AN515-42 laptop with a Ryzen 2700U hangs on boot with
recent kernel on an interrupt storm from pinctrl-amd.
Older kernels work but this seems to be because this module was disabled
by default. I tried to copy over old driver from 4.9 but it still
experiences same issue.
On 12/20/2018 3:22 AM, Trent Piepho wrote:
> On Wed, 2018-12-19 at 16:47 -0800, Andrey Smirnov wrote:
This series initially added explicit offsets but I suggested a single
"controller-id" because:
* There are multiple bit and byte offsets
* Other imx8 SOCs also have 2x
On 12/18/2018 5:15 PM, Rob Herring wrote:
> On Mon, Dec 17, 2018 at 08:07:02PM -0800, Andrey Smirnov wrote:
>> Add code needed to support i.MX8MQ variant.
>>
>> Signed-off-by: Andrey Smirnov
>> Reviewed-by: Lucas Stach
>> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> +++
On Mon, 2018-12-17 at 20:07 -0800, Andrey Smirnov wrote:
> Add code needed to support i.MX8MQ variant.
> static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
> {
> +
> +
Remove empty lines?
> + unsigned int mask, val, offset;
> +
> + mask = IMX6Q_GPR12_DEVICE_TYPE;
> + val
On 12/17/2018 1:09 AM, Andrey Smirnov wrote:
> In order to avoid having potentially ever growing list of variants
> that don't support methods implemented in imx6_pcie_reset_phy() and
> imx6_setup_phy_mpll(), change logical checks in the to check for SoC's
> that _do_ support what they implement.
1 - 100 of 648 matches
Mail list logo
