* [PATCH v6 8/8] x86/kernel: jump_table: use relative references
From: Steven Rostedt @ 2017-12-28 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9Gza=RN_v_H-G7m7-qKg9B4Xf4GFvd_H-Gut-V3eabmA@mail.gmail.com>
On Thu, 28 Dec 2017 16:26:07 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 28 December 2017 at 16:19, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Wed, 27 Dec 2017 08:50:33 +0000
> > Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >
> >> static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
> >> {
> >> - return entry->code;
> >> + return (jump_label_t)&entry->code + entry->code;
> >
> > I'm paranoid about doing arithmetic on abstract types. What happens in
> > the future if jump_label_t becomes a pointer? You will get a different
> > result.
> >
>
> In general, I share your concern. In this case, however, jump_label_t
> is typedef'd three lines up and is never used anywhere else.
I would agree if this was in a .c file, but it's in a header file,
which causes me to be more paranoid.
>
> > Could we switch these calculations to something like:
> >
> > return (jump_label_t)((long)&entrty->code + entry->code);
> >
>
> jump_label_t is local to this .h file, so it can be defined as u32 or
> u64 depending on the word size. I don't mind adding the extra cast,
> but I am not sure if your paranoia is justified in this particular
> case. Perhaps we should just use 'unsigned long' throughout?
Actually, that may be better. Have the return value be jump_label_t,
but the cast be "unsigned long". That way it should always work.
static inline jump_label_t jump_entry_code(...)
{
return (unsigned long)&entry->code + entry->code;
}
-- Steve
^ permalink raw reply
* [PATCH v2 0/2] sun8i-a83t: Add touchscreen support on TBS A711
From: Mylene JOSSERAND @ 2017-12-28 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228163336.28131-1-mylene.josserand@free-electrons.com>
Hello,
Le Thu, 28 Dec 2017 17:33:34 +0100,
Myl?ne Josserand <mylene.josserand@free-electrons.com> a ?crit :
> Hello everyone,
>
> This is a V2 of the patch series that adds touchscreen support
> (FocalTech EDT-FT5x06 Polytouch) for TBS A711 (Allwinner sun8i-a83t SoC).
> Based on last linux-next (next-20171222).
>
> Changes since v1:
> - Remove patches 01 and 02 as Chen-Yu Tsai sent a similar patch:
> https://patchwork.kernel.org/patch/10111431/
> and it is merged on last next-20171222.
> (See commit f066f46ce5a5 "ARM: dts: sun8i: a83t: Add I2C device nodes and pinmux settings")
> - Update regulator according to Dmitry Torokhov's review: remove "optional"
> suffix while retrieving the regulator, rename it into "vcc" instead of
> "power" and add bindings documentation.
I notice that I forgot the second review of Dmitry about reset/wake
gpios so I will send a V3 with the modifications.
Thanks,
Myl?ne
> - Update device tree according to Maxime Ripard's review: remove the
> label and rename the node.
> - Squash patch 03 with patch 05 to add I2C0 and touchscreen's node
> in one patch (see patch 02).
>
> Patch 01: Add support for regulator in the FocalTech touchscreen driver
> because A711 tablet is using a regulator to power-up the touchscreen.
> Patch 02: Add i2c0 and touchscreen's node for A711 TBS tablet.
>
> Thank you in advance for any review.
> Best regards,
> Myl?ne
>
> Myl?ne Josserand (2):
> Input: edt-ft5x06 - Add support for regulator
> arm: dts: sun8i: a83t: a711: Add touchscreen node
>
> .../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
> arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 16 +++++++++++
> drivers/input/touchscreen/edt-ft5x06.c | 33 ++++++++++++++++++++++
> 3 files changed, 50 insertions(+)
>
^ permalink raw reply
* [PATCH 0/2] Perf-ARM SPE: Adjustments for two function implementations
From: SF Markus Elfring @ 2017-12-28 17:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 28 Dec 2017 17:56:54 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation
in arm_spe_pmu_device_dt_probe()
Delete an unnecessary return statement in __arm_spe_pmu_dev_probe()
drivers/perf/arm_spe_pmu.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH 1/2] perf: arm_spe: Delete an error message for a failed memory allocation in arm_spe_pmu_device_dt_probe()
From: SF Markus Elfring @ 2017-12-28 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a92bb8f-4295-6912-19a4-9103226a3c62@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 28 Dec 2017 17:27:23 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/perf/arm_spe_pmu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index 8ce262fc2561..27fac8907d1d 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -1166,9 +1166,7 @@ static int arm_spe_pmu_device_dt_probe(struct platform_device *pdev)
spe_pmu = devm_kzalloc(dev, sizeof(*spe_pmu), GFP_KERNEL);
- if (!spe_pmu) {
- dev_err(dev, "failed to allocate spe_pmu\n");
+ if (!spe_pmu)
return -ENOMEM;
- }
spe_pmu->handle = alloc_percpu(typeof(*spe_pmu->handle));
if (!spe_pmu->handle)
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2] perf: arm_spe: Delete an unnecessary return statement in __arm_spe_pmu_dev_probe()
From: SF Markus Elfring @ 2017-12-28 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a92bb8f-4295-6912-19a4-9103226a3c62@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 28 Dec 2017 17:34:54 +0100
The script "checkpatch.pl" pointed information out like the following.
WARNING: void function return statements are not generally useful
Thus remove such a statement in the affected function.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/perf/arm_spe_pmu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index 27fac8907d1d..b30654f75a8c 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -1033,7 +1033,6 @@ static void __arm_spe_pmu_dev_probe(void *info)
spe_pmu->max_record_sz, spe_pmu->align, spe_pmu->features);
spe_pmu->features |= SPE_PMU_FEAT_DEV_PROBED;
- return;
}
static void __arm_spe_pmu_reset_local(void)
--
2.15.1
^ permalink raw reply related
* [PATCH net-next v9 0/2] add UniPhier AVE ethernet support
From: David Miller @ 2017-12-28 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514444292-20643-1-git-send-email-hayashi.kunihiko@socionext.com>
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date: Thu, 28 Dec 2017 15:58:10 +0900
> This series adds support for Socionext AVE ethernet controller implemented
> on UniPhier SoCs. This driver supports RGMII/RMII modes.
Series applied.
^ permalink raw reply
* [PATCH net-next 1/6] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2017-12-28 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <91838ce5-a1a8-c41a-36e8-bef7adaf82fd@gmail.com>
Hi Florian,
On Thu, Dec 28, 2017 at 06:16:51AM -0800, Florian Fainelli wrote:
>
> And since you are respinning, please make sure you update phy_modes() in
> the same header file as well as
> Documentation/devicetree/bindings/net/ethernet.txt with the newly added
> PHY interface mode.
You're right. Thanks for pointing this out!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Antoine Tenart @ 2017-12-28 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <462da70b-ba7d-6299-3e21-b619d3c4c7e6@gmail.com>
Hi Florian,
On Thu, Dec 28, 2017 at 07:02:09AM -0800, Florian Fainelli wrote:
> On 12/28/2017 02:05 AM, Antoine Tenart wrote:
> > On Thu, Dec 28, 2017 at 08:46:23AM +0100, Andrew Lunn wrote:
> >> On Wed, Dec 27, 2017 at 10:24:01PM +0000, Russell King - ARM Linux wrote:
> >>> On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> >>>>
> >>>> +&cps_eth2 {
> >>>> + /* CPS Lane 5 */
> >>>> + status = "okay";
> >>>> + phy-mode = "2500base-x";
> >>>> + /* Generic PHY, providing serdes lanes */
> >>>> + phys = <&cps_comphy5 2>;
> >>>> +};
> >>>> +
> >>>
> >>> This is wrong. This lane is connected to a SFP cage which can support
> >>> more than just 2500base-X. Tying it in this way to 2500base-X means
> >>> that this port does not support conenctions at 1000base-X, despite
> >>> that's one of the most popular and more standardised speeds.
> >>>
> >>
> >> I agree with Russell here. SFP modules are hot pluggable, and support
> >> a range of interface modes. You need to query what the SFP module is
> >> in order to know how to configure the SERDES interface. The phylink
> >> infrastructure does that for you.
> >
> > Sure, I understand. We'll be able to support such interfaces only when
> > the phylink PPv2 support lands in.
>
> Should we expect PHYLINK support to make it as the first patch in your
> v2 of this patch series, or is someone else doing that?
No, the phylink patch conflicts with Marcin's ACPI series and we agreed
to let him get his series merged first. And I will probably work on a
few other topics before having the chance to work on it. So it'll
probably be me doing that, but not right now.
This isn't an issue regarding the PPv2 and PHY patches of this series,
but yes we probably won't get the fourth network interface supported on
the mcbin during this release.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH -next] clk: meson-axg: make local symbol axg_gp0_params_table static
From: Stephen Boyd @ 2017-12-28 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514431110-98277-1-git-send-email-weiyongjun1@huawei.com>
On 12/28, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/clk/meson/axg.c:260:25: warning:
> symbol 'axg_gp0_params_table' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH -next] clk: meson-axg: fix return value check in axg_clkc_probe()
From: Stephen Boyd @ 2017-12-28 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514428849-61681-1-git-send-email-weiyongjun1@huawei.com>
On 12/28, Wei Yongjun wrote:
> In case of error, the function devm_ioremap() returns NULL pointer
> not ERR_PTR(). The IS_ERR() test in the return value check should be
> replaced with NULL test.
>
> Fixes: 78b4af312f91 ("clk: meson-axg: add clock controller drivers")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: pxa: unbreak lookup of CLK_POUT
From: Stephen Boyd @ 2017-12-28 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226133036.11432-1-grinberg@compulab.co.il>
On 12/26, Igor Grinberg wrote:
> Since switching to clk drivers, the CLK_POUT cannot be searched for by
> clk_get() API and thus it returns with ENOENT.
> Register it with the clk_lookup and thus unbreak the users of it.
>
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Russell King - ARM Linux @ 2017-12-28 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228182739.GH2626@kwain>
On Thu, Dec 28, 2017 at 07:27:39PM +0100, Antoine Tenart wrote:
> Hi Florian,
>
> On Thu, Dec 28, 2017 at 07:02:09AM -0800, Florian Fainelli wrote:
> > On 12/28/2017 02:05 AM, Antoine Tenart wrote:
> > > On Thu, Dec 28, 2017 at 08:46:23AM +0100, Andrew Lunn wrote:
> > >> On Wed, Dec 27, 2017 at 10:24:01PM +0000, Russell King - ARM Linux wrote:
> > >>> On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> > >>>>
> > >>>> +&cps_eth2 {
> > >>>> + /* CPS Lane 5 */
> > >>>> + status = "okay";
> > >>>> + phy-mode = "2500base-x";
> > >>>> + /* Generic PHY, providing serdes lanes */
> > >>>> + phys = <&cps_comphy5 2>;
> > >>>> +};
> > >>>> +
> > >>>
> > >>> This is wrong. This lane is connected to a SFP cage which can support
> > >>> more than just 2500base-X. Tying it in this way to 2500base-X means
> > >>> that this port does not support conenctions at 1000base-X, despite
> > >>> that's one of the most popular and more standardised speeds.
> > >>>
> > >>
> > >> I agree with Russell here. SFP modules are hot pluggable, and support
> > >> a range of interface modes. You need to query what the SFP module is
> > >> in order to know how to configure the SERDES interface. The phylink
> > >> infrastructure does that for you.
> > >
> > > Sure, I understand. We'll be able to support such interfaces only when
> > > the phylink PPv2 support lands in.
> >
> > Should we expect PHYLINK support to make it as the first patch in your
> > v2 of this patch series, or is someone else doing that?
>
> No, the phylink patch conflicts with Marcin's ACPI series and we agreed
> to let him get his series merged first. And I will probably work on a
> few other topics before having the chance to work on it. So it'll
> probably be me doing that, but not right now.
ACPI is going to be a problem with phylink for a while. There's patches
queued in net-next which convert phylink and SFP mostly to the fwnode
and property based systems, but phylib and i2c do not seem to have the
necessary bits to be able to deal with those.
Specifically, in DT we have "of_find_i2c_adapter_by_node()" but afaics
there is no equivalent in ACPI - which means in an ACPI based system
we have no way to determine the I2C bus associated with a SFP socket,
which is a rather fundamental issue for SFP modules.
For phylib side, there's "of_phy_attach()" but again there is no
equivalent in ACPI. This should not be that much of a problem, because
network drivers using the DT phylib calls (eg, "of_phy_connect()") are
already restricted by this. That may have been solved by Marcin's
series, but I've not seen it to know.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.16
From: Stephen Boyd @ 2017-12-28 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228082524.GA13649@wens.csie.org>
On 12/28, Chen-Yu Tsai wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.16
>
> for you to fetch changes up to e952ca3c6b2ffdfbf9618e4bd3e9aad1ff3f5eb4:
>
> clk: sunxi-ng: sun8i: a83t: Use sigma-delta modulation for audio PLL (2017-12-08 10:08:32 +0100)
>
Thanks. Pulled.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [RFC PATCH clk] clk: si5351: _si5351_clkout_reset_pll() can be static
From: Stephen Boyd @ 2017-12-28 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227042513.GA56372@ivb42>
On 12/27, kbuild test robot wrote:
>
> Fixes: b26ff127c52c ("clk: si5351: Apply PLL soft reset before enabling the outputs")
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Russell King - ARM Linux @ 2017-12-28 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228100416.GD2626@kwain>
On Thu, Dec 28, 2017 at 11:04:16AM +0100, Antoine Tenart wrote:
> Hi Russell,
>
> On Wed, Dec 27, 2017 at 11:20:00PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Dec 27, 2017 at 11:42:52PM +0100, Antoine Tenart wrote:
> > >
> > > What do you suggest to describe this in the dt, to enable a port using
> > > the current PPv2 driver?
> >
> > I don't - I'm merely pointing out that you're bodging support for the
> > SFP cage rather than productively discussing phylink for mvpp2.
> >
> > As far as I remember, the discussion stalled at this point:
> >
> > - You think there's modes that mvpp2 supports that are not supportable
> > if you use phylink.
> >
> > - I've described what phylink supports, and I've asked you for details
> > about what you can't support.
>
> That's not what I remembered. You had some valid points, and others
> related to PHY modes the driver wasn't supporting before the phylink
> transition. My understanding of this was that you wanted a full
> featured support while I only wanted to convert the already supported
> modes.
You are mistaken - you can get a full refresher on where things were
at via https://patchwork.kernel.org/patch/9963971/
There are two points in that thread where discussion stopped awaiting
input:
1. I asked for details about what mvpp2.c supports that phylink does
not (as you indicated that there were certain things that mvpp2
supports that phylink does not.) I'm still awaiting a response.
2. 25th Sept, you indicated that you would get someone to test
an issue related to in-band AN. No results of that testing have
been forthcoming.
Consequently, the ball is in your court on both these issues.
I am not after a full featured support, what I'm after is ensuring
that phylink is (a) used correctly and (b) implementations using it
are correct. Part of that is ensuring that users don't introduce
unexpected failure conditions.
So, when you do this in the validate() callback:
+ phylink_set(mask, 1000baseX_Full);
and then do this in the mac_config() callback:
+ if (!phy_interface_mode_is_rgmii(port->phy_interface) &&
+ port->phy_interface != PHY_INTERFACE_MODE_SGMII)
+ return;
and this in the link_state() callback:
+ if (!phy_interface_mode_is_rgmii(port->phy_interface) &&
+ port->phy_interface != PHY_INTERFACE_MODE_SGMII)
+ return 0;
the result is that phylink thinks that you support 1000base-X modes,
and it will call mac_config() asking for 1000base-X, but you silently
ignore that, leaving the hardware configured in whatever state it was.
That leads to a silent failure as far as the user is concerned.
So, if you do not intend to support 1000base-X initially, don't
allow it in the validate callback until you do.
It gets worse, because the return in link_state() means that phylink
thinks that the link is up if it has requested 1000base-X, which it
won't be unless you've properly configured it.
It's this kind of unreliability that I was concerned about in your
patch. I'm not demanding "full featured implementation" but I do
want you to use it correctly.
> You're probably right about not wanting this dt patch. The non-dt
> patches still are relevant regardless of phylink being supported in the
> PPv2 driver. I'll send a v2 without the dt parts.
Thanks.
> > What I'm most concerned about, given the bindings for comphy that
> > have been merged, is that Free Electrons is pushing forward seemingly
> > with no regard to the requirement that the serdes lanes are dynamically
> > reconfigurable, and that's a basic requirement for SFP, and for the
> > 88x3310 PHYs on the Macchiatobin platform.
>
> The main idea behind the comphy driver is to provide a way to
> reconfigure the serdes lanes at runtime. Could you develop what are
> blocking points to properly support SFP, regarding the current comphy
> support?
If it supports serdes lane mode reconfiguration (iow, switching between
1000base-X, 2500base-X, SGMII, 10G-KR), then that's all that's required.
Note that you need comphy to switch between SGMII / 10G-KR to support
the 88x3310 fully too.
Having looked deeper at this, it seems it does have the capability of
doing what's required, sorry for the noise.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 2/2] media: don't include drivers/media/i2c at cflags
From: Mauro Carvalho Chehab @ 2017-12-28 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fada1935590f66dc6784981e0d557ca09013c847.1514488526.git.mchehab@s-opensource.com>
Most of the I2C headers got moved a long time ago to
include/media/i2c. Stop including them at the patch.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/i2c/cx25840/Makefile | 2 --
drivers/media/pci/bt8xx/Makefile | 1 -
drivers/media/pci/cx23885/Makefile | 1 -
drivers/media/pci/cx25821/Makefile | 2 --
drivers/media/pci/cx88/Makefile | 2 --
drivers/media/pci/ivtv/Makefile | 1 -
drivers/media/pci/saa7134/Makefile | 1 -
drivers/media/pci/saa7164/Makefile | 3 ---
drivers/media/platform/Makefile | 2 --
drivers/media/platform/sti/c8sectpfe/Makefile | 1 -
drivers/media/usb/cx231xx/Makefile | 1 -
drivers/media/usb/em28xx/Makefile | 1 -
drivers/media/usb/hdpvr/Makefile | 4 ----
drivers/media/usb/pvrusb2/Makefile | 1 -
drivers/media/usb/stk1160/Makefile | 2 --
drivers/media/usb/tm6000/Makefile | 1 -
drivers/media/usb/usbvision/Makefile | 1 -
17 files changed, 27 deletions(-)
diff --git a/drivers/media/i2c/cx25840/Makefile b/drivers/media/i2c/cx25840/Makefile
index 898eb13340ae..ac545812fc6a 100644
--- a/drivers/media/i2c/cx25840/Makefile
+++ b/drivers/media/i2c/cx25840/Makefile
@@ -2,5 +2,3 @@ cx25840-objs := cx25840-core.o cx25840-audio.o cx25840-firmware.o \
cx25840-vbi.o cx25840-ir.o
obj-$(CONFIG_VIDEO_CX25840) += cx25840.o
-
-ccflags-y += -Idrivers/media/i2c
diff --git a/drivers/media/pci/bt8xx/Makefile b/drivers/media/pci/bt8xx/Makefile
index ab0ea64d3910..7f1c3beb1bbc 100644
--- a/drivers/media/pci/bt8xx/Makefile
+++ b/drivers/media/pci/bt8xx/Makefile
@@ -7,6 +7,5 @@ obj-$(CONFIG_VIDEO_BT848) += bttv.o
obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o
ccflags-y += -Idrivers/media/dvb-frontends
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/common
ccflags-y += -Idrivers/media/tuners
diff --git a/drivers/media/pci/cx23885/Makefile b/drivers/media/pci/cx23885/Makefile
index 3f37dcadbaaf..130f0aa29ac6 100644
--- a/drivers/media/pci/cx23885/Makefile
+++ b/drivers/media/pci/cx23885/Makefile
@@ -8,7 +8,6 @@ cx23885-objs := cx23885-cards.o cx23885-video.o cx23885-vbi.o \
obj-$(CONFIG_VIDEO_CX23885) += cx23885.o
obj-$(CONFIG_MEDIA_ALTERA_CI) += altera-ci.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/pci/cx25821/Makefile b/drivers/media/pci/cx25821/Makefile
index d14d65b1b042..94633d02ac7f 100644
--- a/drivers/media/pci/cx25821/Makefile
+++ b/drivers/media/pci/cx25821/Makefile
@@ -5,5 +5,3 @@ cx25821-y := cx25821-core.o cx25821-cards.o cx25821-i2c.o \
obj-$(CONFIG_VIDEO_CX25821) += cx25821.o
obj-$(CONFIG_VIDEO_CX25821_ALSA) += cx25821-alsa.o
-
-ccflags-y += -Idrivers/media/i2c
diff --git a/drivers/media/pci/cx88/Makefile b/drivers/media/pci/cx88/Makefile
index dea0e7ac32e8..d0f45d652d6e 100644
--- a/drivers/media/pci/cx88/Makefile
+++ b/drivers/media/pci/cx88/Makefile
@@ -10,7 +10,5 @@ obj-$(CONFIG_VIDEO_CX88_ALSA) += cx88-alsa.o
obj-$(CONFIG_VIDEO_CX88_BLACKBIRD) += cx88-blackbird.o
obj-$(CONFIG_VIDEO_CX88_DVB) += cx88-dvb.o
obj-$(CONFIG_VIDEO_CX88_VP3054) += cx88-vp3054-i2c.o
-
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/pci/ivtv/Makefile b/drivers/media/pci/ivtv/Makefile
index 08987a5d55fc..5de95dbe3256 100644
--- a/drivers/media/pci/ivtv/Makefile
+++ b/drivers/media/pci/ivtv/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv.o
obj-$(CONFIG_VIDEO_IVTV_ALSA) += ivtv-alsa.o
obj-$(CONFIG_VIDEO_FB_IVTV) += ivtvfb.o
-ccflags-y += -I$(srctree)/drivers/media/i2c
ccflags-y += -I$(srctree)/drivers/media/tuners
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/pci/saa7134/Makefile b/drivers/media/pci/saa7134/Makefile
index 959f2766b093..82ac7f31221b 100644
--- a/drivers/media/pci/saa7134/Makefile
+++ b/drivers/media/pci/saa7134/Makefile
@@ -12,7 +12,6 @@ obj-$(CONFIG_VIDEO_SAA7134_ALSA) += saa7134-alsa.o
obj-$(CONFIG_VIDEO_SAA7134_DVB) += saa7134-dvb.o
-ccflags-y += -I$(srctree)/drivers/media/i2c
ccflags-y += -I$(srctree)/drivers/media/tuners
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
ccflags-y += -I$(srctree)/drivers/media/usb/go7007
diff --git a/drivers/media/pci/saa7164/Makefile b/drivers/media/pci/saa7164/Makefile
index 54840d659a5d..dea076744ec9 100644
--- a/drivers/media/pci/saa7164/Makefile
+++ b/drivers/media/pci/saa7164/Makefile
@@ -5,8 +5,5 @@ saa7164-objs := saa7164-cards.o saa7164-core.o saa7164-i2c.o saa7164-dvb.o \
obj-$(CONFIG_VIDEO_SAA7164) += saa7164.o
-ccflags-y += -I$(srctree)/drivers/media/i2c
ccflags-y += -I$(srctree)/drivers/media/tuners
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
-
-ccflags-y += $(extra-cflags-y) $(extra-cflags-m)
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 003b0bb2cddf..347fba8177b5 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -82,8 +82,6 @@ obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel/
obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32/
-ccflags-y += -I$(srctree)/drivers/media/i2c
-
obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/
obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec/
diff --git a/drivers/media/platform/sti/c8sectpfe/Makefile b/drivers/media/platform/sti/c8sectpfe/Makefile
index 927dd930c943..34d69472b6f0 100644
--- a/drivers/media/platform/sti/c8sectpfe/Makefile
+++ b/drivers/media/platform/sti/c8sectpfe/Makefile
@@ -4,7 +4,6 @@ c8sectpfe-y += c8sectpfe-core.o c8sectpfe-common.o c8sectpfe-dvb.o \
obj-$(CONFIG_DVB_C8SECTPFE) += c8sectpfe.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/common
ccflags-y += -Idrivers/media/dvb-frontends/
ccflags-y += -Idrivers/media/tuners/
diff --git a/drivers/media/usb/cx231xx/Makefile b/drivers/media/usb/cx231xx/Makefile
index 79cf46eb151a..c023d97407de 100644
--- a/drivers/media/usb/cx231xx/Makefile
+++ b/drivers/media/usb/cx231xx/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx.o
obj-$(CONFIG_VIDEO_CX231XX_ALSA) += cx231xx-alsa.o
obj-$(CONFIG_VIDEO_CX231XX_DVB) += cx231xx-dvb.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
ccflags-y += -Idrivers/media/usb/dvb-usb
diff --git a/drivers/media/usb/em28xx/Makefile b/drivers/media/usb/em28xx/Makefile
index c3d3570584e1..8a224007d755 100644
--- a/drivers/media/usb/em28xx/Makefile
+++ b/drivers/media/usb/em28xx/Makefile
@@ -11,6 +11,5 @@ obj-$(CONFIG_VIDEO_EM28XX_ALSA) += em28xx-alsa.o
obj-$(CONFIG_VIDEO_EM28XX_DVB) += em28xx-dvb.o
obj-$(CONFIG_VIDEO_EM28XX_RC) += em28xx-rc.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/usb/hdpvr/Makefile b/drivers/media/usb/hdpvr/Makefile
index 9b8d1463c526..644dd99ffce3 100644
--- a/drivers/media/usb/hdpvr/Makefile
+++ b/drivers/media/usb/hdpvr/Makefile
@@ -1,7 +1,3 @@
hdpvr-objs := hdpvr-control.o hdpvr-core.o hdpvr-video.o hdpvr-i2c.o
obj-$(CONFIG_VIDEO_HDPVR) += hdpvr.o
-
-ccflags-y += -Idrivers/media/i2c
-
-ccflags-y += $(extra-cflags-y) $(extra-cflags-m)
diff --git a/drivers/media/usb/pvrusb2/Makefile b/drivers/media/usb/pvrusb2/Makefile
index 552e4f12c496..9facf6873404 100644
--- a/drivers/media/usb/pvrusb2/Makefile
+++ b/drivers/media/usb/pvrusb2/Makefile
@@ -17,6 +17,5 @@ pvrusb2-objs := pvrusb2-i2c-core.o \
obj-$(CONFIG_VIDEO_PVRUSB2) += pvrusb2.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/usb/stk1160/Makefile b/drivers/media/usb/stk1160/Makefile
index 613471528749..8e6c22fb1803 100644
--- a/drivers/media/usb/stk1160/Makefile
+++ b/drivers/media/usb/stk1160/Makefile
@@ -6,5 +6,3 @@ stk1160-y := stk1160-core.o \
stk1160-ac97.o
obj-$(CONFIG_VIDEO_STK1160) += stk1160.o
-
-ccflags-y += -Idrivers/media/i2c
diff --git a/drivers/media/usb/tm6000/Makefile b/drivers/media/usb/tm6000/Makefile
index 62f8528daef2..744c039e621a 100644
--- a/drivers/media/usb/tm6000/Makefile
+++ b/drivers/media/usb/tm6000/Makefile
@@ -10,6 +10,5 @@ obj-$(CONFIG_VIDEO_TM6000) += tm6000.o
obj-$(CONFIG_VIDEO_TM6000_ALSA) += tm6000-alsa.o
obj-$(CONFIG_VIDEO_TM6000_DVB) += tm6000-dvb.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/usb/usbvision/Makefile b/drivers/media/usb/usbvision/Makefile
index 9b3a5581df42..494d030b4979 100644
--- a/drivers/media/usb/usbvision/Makefile
+++ b/drivers/media/usb/usbvision/Makefile
@@ -2,5 +2,4 @@ usbvision-objs := usbvision-core.o usbvision-video.o usbvision-i2c.o usbvision-
obj-$(CONFIG_VIDEO_USBVISION) += usbvision.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
--
2.14.3
^ permalink raw reply related
* [BUG] sun8i-a83t-bananapi-m3: Ethernet unstable since d7c5f6863550 ("ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813 regulator nodes")
From: Corentin Labbe @ 2017-12-28 20:20 UTC (permalink / raw)
To: linux-arm-kernel
Hello
Since d7c5f6863550 ("ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813 regulator nodes"), my BPIM3 does not have stable ethernet.
from 50% to 100% packet loss.
According to the logs (below), vcc-ephy is disabled during boot
With the following hack, https://paste.pound-python.org/show/6BlmwcE60z0o4GrbAMUU/ (which is a badly d7c5f6863550 revert)
the situation is better (ping with 0% loss), but the bandwitch is unstable low.
So the problem is clearly that the PHY is badly powered.
Regards
[ 4.840336] sunxi-rsb 1f03400.rsb: RSB running at 3000000 Hz
[ 4.847252] axp20x-rsb sunxi-rsb-3a3: AXP20x variant AXP813 found
[ 4.856307] axp20x-rsb sunxi-rsb-3a3: Looking up vin1-supply from device tree
[ 4.856331] axp20x-rsb sunxi-rsb-3a3: Looking up vin1-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.856351] dcdc1: supplied by regulator-dummy
[ 4.860802] regulator-dummy: could not add device link regulator.1 err -2
[ 4.861006] vcc-3v3: 3300 mV
[ 4.861264] axp20x-rsb sunxi-rsb-3a3: Looking up vin2-supply from device tree
[ 4.861281] axp20x-rsb sunxi-rsb-3a3: Looking up vin2-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.861291] dcdc2: supplied by regulator-dummy
[ 4.865854] regulator-dummy: could not add device link regulator.2 err -2
[ 4.866041] vdd-cpua: 700 <--> 1100 mV at 900 mV
[ 4.866251] axp20x-rsb sunxi-rsb-3a3: Looking up vin3-supply from device tree
[ 4.866264] axp20x-rsb sunxi-rsb-3a3: Looking up vin3-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.866274] dcdc3: supplied by regulator-dummy
[ 4.870717] regulator-dummy: could not add device link regulator.3 err -2
[ 4.870814] vdd-cpub: 700 <--> 1100 mV at 900 mV
[ 4.871017] axp20x-rsb sunxi-rsb-3a3: Looking up vin4-supply from device tree
[ 4.871029] axp20x-rsb sunxi-rsb-3a3: Looking up vin4-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.871040] dcdc4: supplied by regulator-dummy
[ 4.875524] regulator-dummy: could not add device link regulator.4 err -2
[ 4.875633] vdd-gpu: 700 <--> 1100 mV at 900 mV
[ 4.875832] axp20x-rsb sunxi-rsb-3a3: Looking up vin5-supply from device tree
[ 4.875845] axp20x-rsb sunxi-rsb-3a3: Looking up vin5-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.875857] dcdc5: supplied by regulator-dummy
[ 4.880299] regulator-dummy: could not add device link regulator.5 err -2
[ 4.880413] vcc-dram: Bringing 1180000uV into 1200000-1200000uV
[ 4.886402] vcc-dram: ramp_delay not set
[ 4.886418] vcc-dram: 1200 mV
[ 4.886643] axp20x-rsb sunxi-rsb-3a3: Looking up vin6-supply from device tree
[ 4.886655] axp20x-rsb sunxi-rsb-3a3: Looking up vin6-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.886669] dcdc6: supplied by regulator-dummy
[ 4.891110] regulator-dummy: could not add device link regulator.6 err -2
[ 4.891216] vdd-sys: 900 mV
[ 4.891495] axp20x-rsb sunxi-rsb-3a3: Looking up vin7-supply from device tree
[ 4.891508] axp20x-rsb sunxi-rsb-3a3: Looking up vin7-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.891521] dcdc7: supplied by regulator-dummy
[ 4.895995] regulator-dummy: could not add device link regulator.7 err -2
[ 4.896102] dcdc7: at 1000 mV
[ 4.896324] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply from device tree
[ 4.896336] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.896348] aldo1: supplied by regulator-dummy
[ 4.900790] regulator-dummy: could not add device link regulator.8 err -2
[ 4.900936] vcc-1v8: 1800 mV
[ 4.901142] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply from device tree
[ 4.901155] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.901169] aldo2: supplied by regulator-dummy
[ 4.905638] regulator-dummy: could not add device link regulator.9 err -2
[ 4.905734] dram-pll: 1800 mV
[ 4.905959] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply from device tree
[ 4.905972] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.905986] aldo3: supplied by regulator-dummy
[ 4.910428] regulator-dummy: could not add device link regulator.10 err -2
[ 4.910536] avcc: 3000 mV
[ 4.910813] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply from device tree
[ 4.910827] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.910842] dldo1: supplied by regulator-dummy
[ 4.915313] regulator-dummy: could not add device link regulator.11 err -2
[ 4.915448] vcc-wifi: Bringing 2900000uV into 3300000-3300000uV
[ 4.921405] vcc-wifi: ramp_delay not set
[ 4.921414] vcc-wifi: 3300 mV
[ 4.921627] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply from device tree
[ 4.921640] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.921654] dldo2: supplied by regulator-dummy
[ 4.926118] regulator-dummy: could not add device link regulator.12 err -2
[ 4.926208] dldo2: at 2900 mV
[ 4.926422] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply from device tree
[ 4.926435] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.926451] dldo3: supplied by regulator-dummy
[ 4.930892] regulator-dummy: could not add device link regulator.13 err -2
[ 4.930983] vcc-pd: Bringing 2900000uV into 2500000-2500000uV
[ 4.936787] vcc-pd: ramp_delay not set
[ 4.936801] vcc-pd: 2500 mV
[ 4.937018] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply from device tree
[ 4.937030] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.937045] dldo4: supplied by regulator-dummy
[ 4.941486] regulator-dummy: could not add device link regulator.14 err -2
[ 4.941579] dldo4: at 3300 mV
[ 4.941785] axp20x-rsb sunxi-rsb-3a3: Looking up eldoin-supply from device tree
[ 4.941822] eldo1: supplied by vcc-3v3
[ 4.945598] vcc-3v3: could not add device link regulator.15 err -2
[ 4.945763] eldo1: at 700 mV
[ 4.945994] axp20x-rsb sunxi-rsb-3a3: Looking up eldoin-supply from device tree
[ 4.946013] eldo2: supplied by vcc-3v3
[ 4.949763] vcc-3v3: could not add device link regulator.16 err -2
[ 4.949849] eldo2: at 700 mV
[ 4.950067] axp20x-rsb sunxi-rsb-3a3: Looking up eldoin-supply from device tree
[ 4.950083] eldo3: supplied by vcc-3v3
[ 4.953866] vcc-3v3: could not add device link regulator.17 err -2
[ 4.953964] eldo3: at 1600 mV
[ 4.954190] axp20x-rsb sunxi-rsb-3a3: Looking up fldoin-supply from device tree
[ 4.954208] fldo1: supplied by vcc-dram
[ 4.958043] vcc-dram: could not add device link regulator.18 err -2
[ 4.958143] vdd12-hsic: override min_uV, 1080000 -> 1100000
[ 4.958149] vdd12-hsic: override max_uV, 1320000 -> 1300000
[ 4.958159] vdd12-hsic: 1100 <--> 1300 mV at 1250 mV
[ 4.958419] axp20x-rsb sunxi-rsb-3a3: Looking up fldoin-supply from device tree
[ 4.958440] fldo2: supplied by vcc-dram
[ 4.962275] vcc-dram: could not add device link regulator.19 err -2
[ 4.962447] vdd-cpus: 700 <--> 1100 mV at 900 mV
[ 4.962686] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply from device tree
[ 4.962700] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.962721] rtc-ldo: supplied by regulator-dummy
[ 4.967375] regulator-dummy: could not add device link regulator.20 err -2
[ 4.967425] vcc-rtc: 1800 mV
[ 4.967626] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply from device tree
[ 4.967638] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.967658] ldo-io0: supplied by regulator-dummy
[ 4.972273] regulator-dummy: could not add device link regulator.21 err -2
[ 4.972404] ldo-io0: at 3300 mV
[ 4.972622] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply from device tree
[ 4.972635] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.972656] ldo-io1: supplied by regulator-dummy
[ 4.977297] regulator-dummy: could not add device link regulator.22 err -2
[ 4.977435] ldo-io1: at 3300 mV
[ 4.977659] axp20x-rsb sunxi-rsb-3a3: Looking up swin-supply from device tree
[ 4.977679] sw: supplied by vcc-3v3
[ 4.981167] vcc-3v3: could not add device link regulator.23 err -2
[ 4.981295] vcc-ephy: at 3300 mV
[ 4.981576] axp20x-rsb sunxi-rsb-3a3: Looking up drivevbus-supply from device tree
[ 4.981590] axp20x-rsb sunxi-rsb-3a3: Looking up drivevbus-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.981614] drivevbus: supplied by regulator-dummy
[ 4.986436] regulator-dummy: could not add device link regulator.24 err -2
[ 4.986539] usb0-vbus: no parameters
[ 4.987174] axp20x-rsb sunxi-rsb-3a3: AXP20X driver loaded
[ 4.996209] ac100-rtc ac100-rtc: registered as rtc0
[ 5.001098] ac100-rtc ac100-rtc: RTC enabled
[ 5.006016] sun4i-usb-phy 1c19400.phy: Looking up usb0_vbus-supply from device tree
[ 5.006033] sun4i-usb-phy 1c19400.phy: Looking up usb0_vbus-supply property in node /soc/phy at 1c19400 failed
[ 5.006142] phy phy-1c19400.phy.0: Looking up phy-supply from device tree
[ 5.006153] phy phy-1c19400.phy.0: Looking up phy-supply property in node /soc/phy at 1c19400 failed
[ 5.006270] sun4i-usb-phy 1c19400.phy: Looking up usb1_vbus-supply from device tree
[ 5.006312] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb1_vbus... Deferring probe
[ 5.020051] sun8i-a83t-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver
[ 5.028283] console [ttyS0] disabled
[ 5.052157] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 42, base_baud = 1500000) is a U6_16550A
[ 5.061250] console [ttyS0] enabled
[ 5.068271] bootconsole [earlycon0] disabled
[ 5.078429] sunxi-mmc 1c0f000.mmc: Looking up vmmc-supply from device tree
[ 5.078551] sunxi-mmc 1c0f000.mmc: Looking up vqmmc-supply from device tree
[ 5.078565] sunxi-mmc 1c0f000.mmc: Looking up vqmmc-supply property in node /soc/mmc at 1c0f000 failed
[ 5.079422] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[ 5.109476] sunxi-mmc 1c0f000.mmc: base:0x(ptrval) irq:24
[ 5.115503] sunxi-mmc 1c10000.mmc: Looking up vmmc-supply from device tree
[ 5.115609] sunxi-mmc 1c10000.mmc: Looking up vqmmc-supply from device tree
[ 5.116352] sunxi-mmc 1c10000.mmc: allocated mmc-pwrseq
[ 5.144835] sunxi-mmc 1c10000.mmc: base:0x(ptrval) irq:25
[ 5.150842] sunxi-mmc 1c11000.mmc: Looking up vmmc-supply from device tree
[ 5.150976] sunxi-mmc 1c11000.mmc: Looking up vqmmc-supply from device tree
[ 5.157776] mmc0: host does not support reading read-only switch, assuming write-enable
[ 5.168115] mmc0: new high speed SDHC card at address 59b4
[ 5.175753] mmcblk0: mmc0:59b4 00000 14.9 GiB
[ 5.180362] sunxi-mmc 1c11000.mmc: base:0x(ptrval) irq:26
[ 5.180849] usb1-vbus: 5000 mV
[ 5.181218] reg-fixed-voltage reg-usb1-vbus: usb1-vbus supplying 5000000uV
[ 5.181674] sun4i-usb-phy 1c19400.phy: Looking up usb0_vbus-supply from device tree
[ 5.181689] sun4i-usb-phy 1c19400.phy: Looking up usb0_vbus-supply property in node /soc/phy at 1c19400 failed
[ 5.181825] phy phy-1c19400.phy.0: Looking up phy-supply from device tree
[ 5.181834] phy phy-1c19400.phy.0: Looking up phy-supply property in node /soc/phy at 1c19400 failed
[ 5.181941] sun4i-usb-phy 1c19400.phy: Looking up usb1_vbus-supply from device tree
[ 5.182203] phy phy-1c19400.phy.1: Looking up phy-supply from device tree
[ 5.182215] phy phy-1c19400.phy.1: Looking up phy-supply property in node /soc/phy at 1c19400 failed
[ 5.182320] sun4i-usb-phy 1c19400.phy: Looking up usb2_vbus-supply from device tree
[ 5.182330] sun4i-usb-phy 1c19400.phy: Looking up usb2_vbus-supply property in node /soc/phy at 1c19400 failed
[ 5.182418] phy phy-1c19400.phy.2: Looking up phy-supply from device tree
[ 5.182427] phy phy-1c19400.phy.2: Looking up phy-supply property in node /soc/phy at 1c19400 failed
[ 5.183355] ehci-platform 1c1a000.usb: EHCI Host Controller
[ 5.189212] ehci-platform 1c1a000.usb: new USB bus registered, assigned bus number 1
[ 5.189548] ehci-platform 1c1a000.usb: irq 28, io mem 0x01c1a000
[ 5.212983] ehci-platform 1c1a000.usb: USB 2.0 started, EHCI 1.00
[ 5.219425] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 5.226470] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 5.233887] mmcblk0: p1
[ 5.238179] usb usb1: Product: EHCI Host Controller
[ 5.243188] usb usb1: Manufacturer: Linux 4.15.0-rc4-next-20171222+ ehci_hcd
[ 5.250260] usb usb1: SerialNumber: 1c1a000.usb
[ 5.255686] hub 1-0:1.0: USB hub found
[ 5.259513] hub 1-0:1.0: 1 port detected
[ 5.263822] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 5.269572] console [netcon0] enabled
[ 5.273325] netconsole: network logging started
[ 5.278597] ac100-rtc ac100-rtc: setting system clock to 2017-12-28 20:39:02 UTC (1514493542)
[ 5.287486] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 5.293314] vdd-gpu: disabling
[ 5.296485] vcc-ephy: disabling
[ 5.301896] EXT4-fs (mmcblk0p1): couldn't mount as ext3 due to feature incompatibilities
[ 5.311055] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 5.321221] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 5.343195] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[ 5.351451] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.
[ 5.367566] devtmpfs: mounted
[ 5.372472] Freeing unused kernel memory: 1024K
[ 5.377759] mmc2: new DDR MMC card at address 0001
[ 5.379726] mmcblk2: mmc2:0001 8WPD3R 7.28 GiB
[ 5.381258] mmcblk2boot0: mmc2:0001 8WPD3R partition 1 4.00 MiB
[ 5.382822] mmcblk2boot1: mmc2:0001 8WPD3R partition 2 4.00 MiB
[ 5.470371] mmc1: new high speed SDIO card at address 0001
[ 5.633004] usb 1-1: new high-speed USB device number 2 using ehci-platform
[ 5.834539] usb 1-1: New USB device found, idVendor=1a40, idProduct=0101
[ 5.841615] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 5.849030] usb 1-1: Product: USB 2.0 Hub
[ 5.854281] hub 1-1:1.0: USB hub found
[ 5.858757] hub 1-1:1.0: 4 ports detected
[ 6.183024] usb 1-1.1: new high-speed USB device number 3 using ehci-platform
[ 6.356172] usb 1-1.1: New USB device found, idVendor=05e3, idProduct=0718
[ 6.363586] usb 1-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[ 6.371011] usb 1-1.1: Product: USB Storage
[ 6.375406] usb 1-1.1: SerialNumber: 000000000033
[ 6.381855] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[ 6.401248] scsi host0: usb-storage 1-1.1:1.0
[ 7.466681] scsi 0:0:0:0: Direct-Access USB TO I DE/SATA Device 0016 PQ: 0 ANSI: 4
[ 7.484140] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 7.490789] sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B)
[ 7.503041] sd 0:0:0:0: [sda] 0-byte physical blocks
[ 7.513103] sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled
[ 7.526422] sd 0:0:0:0: [sda] Asking for cache data failed
[ 7.531936] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 7.559074] sd 0:0:0:0: [sda] Attached SCSI disk
[ 14.564013] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 14.695046] axp20x-gpio axp20x-gpio: AXP209 pinctrl and GPIO driver loaded
[ 14.781019] dwmac-sun8i 1c30000.ethernet: PTP uses main clock
[ 14.781082] dwmac-sun8i 1c30000.ethernet: Looking up phy-supply from device tree
[ 14.913317] dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 1ce6 (expect 0)
[ 14.913365] dwmac-sun8i 1c30000.ethernet: Chain mode enabled
[ 14.913373] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported
[ 14.913381] dwmac-sun8i 1c30000.ethernet: Normal descriptors
[ 14.913388] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported
[ 14.913395] dwmac-sun8i 1c30000.ethernet: COE Type 2
[ 14.913402] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported
[ 14.913726] libphy: stmmac: probed
[ 15.838616] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 15.838978] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 15.838993] cfg80211: failed to load regulatory.db
[ 15.971608] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430a0-sdio.bin for chip 0x00a9a6(43430) rev 0x000000
[ 15.972039] usbcore: registered new interface driver brcmfmac
[ 15.972147] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430a0-sdio.bin failed with error -2
[ 16.983325] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[ 17.642892] EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)
[ 17.993291] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[ 25.292693] RTL8211E Gigabit Ethernet stmmac-0:01: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:01, irq=POLL)
[ 25.297646] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available
[ 25.297669] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW
[ 30.503958] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 39.675382] random: crng init done
^ permalink raw reply
* v4.15: camera problems on n900
From: Pavel Machek @ 2017-12-28 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227211718.favif66afztygfje@kekkonen.localdomain>
On Wed 2017-12-27 23:17:19, Sakari Ailus wrote:
> On Wed, Dec 27, 2017 at 10:05:43PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > In v4.14, back camera on N900 works. On v4.15-rc1.. it works for few
> > seconds, but then I get repeated oopses.
> >
> > On v4.15-rc0.5 (commit ed30b147e1f6e396e70a52dbb6c7d66befedd786),
> > camera does not start.
> >
> > Any ideas what might be wrong there?
>
> What kind of oopses do you get?
Hmm. bisect pointed to commit that can't be responsible.... Ideas
welcome.
Pavel
# bad: [fb3f95c11904adf26c2bd86fe1b1613c921710b5] Config for v4.15-rc0.5
# good: [c213cf57c2f15ee226c14dd7157caa334c3ef7c8] Make config similar to n950 case. Still works on n900.
git bisect start 'mini-v4.15' 'mini-v4.14'
# good: [06410bdec961a55e78e01d4fda199f709a84e17f] Merge /data/l/clean-cg into mini-v4.14
git bisect good 06410bdec961a55e78e01d4fda199f709a84e17f
# bad: [fc35c1966e1372a21a88f6655279361e2f92713f] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
git bisect bad fc35c1966e1372a21a88f6655279361e2f92713f
# good: [bebc6082da0a9f5d47a1ea2edc099bf671058bd4] Linux 4.14
git bisect good bebc6082da0a9f5d47a1ea2edc099bf671058bd4
# good: [5bbcc0f595fadb4cac0eddc4401035ec0bd95b09] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect good 5bbcc0f595fadb4cac0eddc4401035ec0bd95b09
# bad: [5b0e2cb020085efe202123162502e0b551e49a0e] Merge tag 'powerpc-4.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
git bisect bad 5b0e2cb020085efe202123162502e0b551e49a0e
# good: [f150891fd9878ef0d9197c4e8451ce67c3bdd014] Merge tag 'exynos-drm-next-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
git bisect good f150891fd9878ef0d9197c4e8451ce67c3bdd014
# good: [93ea0eb7d77afab34657715630d692a78b8cea6a] Merge tag 'leaks-4.15-rc1' of git://github.com/tcharding/linux
git bisect good 93ea0eb7d77afab34657715630d692a78b8cea6a
# bad: [2bf16b7a73caf3435f782e4170cfe563675e10f9] Merge tag 'char-misc-4.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect bad 2bf16b7a73caf3435f782e4170cfe563675e10f9
# good: [ef674997e49760137ca9a90aac41a9922ac399b2] media: staging: atomisp: Convert timers to use timer_setup()
git bisect good ef674997e49760137ca9a90aac41a9922ac399b2
# good: [b1cb7372fa822af6c06c8045963571d13ad6348b] dvb_frontend: don't use-after-free the frontend struct
git bisect good b1cb7372fa822af6c06c8045963571d13ad6348b
# good: [c9fe0f8fa4136c2451dcc012e48fbf4470d6b592] hyper-v: trace vmbus_on_msg_dpc()
git bisect good c9fe0f8fa4136c2451dcc012e48fbf4470d6b592
# good: [e20d2b291ba2f5441fd4aacd746c21e60d48b559] nvmem: imx-ocotp: Pass parameters via a struct
git bisect good e20d2b291ba2f5441fd4aacd746c21e60d48b559
# good: [0ff26c662d5f3b26674d5205c8899d901f766acb] driver core: Fix device link deferred probe
git bisect good 0ff26c662d5f3b26674d5205c8899d901f766acb
# good: [d4035a8c1ff7288af9e47d6d05384f14c9308ea1] MAINTAINERS: Update VME subsystem tree.
git bisect good d4035a8c1ff7288af9e47d6d05384f14c9308ea1
# bad: [e60e1ee60630cafef5e430c2ae364877e061d980] Merge tag 'drm-for-v4.15' of git://people.freedesktop.org/~airlied/linux
git bisect bad e60e1ee60630cafef5e430c2ae364877e061d980
# bad: [5d352e69c60e54b5f04d6e337a1d2bf0dbf3d94a] Merge tag 'media/v4.15-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect bad 5d352e69c60e54b5f04d6e337a1d2bf0dbf3d94a
# good: [f2ecc3d0787e05d9145722feed01d4a11ab6bec1] Merge tag 'staging-4.15-rc1' into v4l_for_linus
git bisect good f2ecc3d0787e05d9145722feed01d4a11ab6bec1
# first bad commit: [5d352e69c60e54b5f04d6e337a1d2bf0dbf3d94a] Merge tag 'media/v4.15-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171228/c05ac7f1/attachment.sig>
^ permalink raw reply
* [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Corentin Labbe @ 2017-12-28 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227160729.4509bec5@dell-desktop.home>
On Wed, Dec 27, 2017 at 04:07:29PM +0100, Mylene JOSSERAND wrote:
> Hello Corentin,
>
> Le Fri, 15 Dec 2017 07:10:46 +0100,
> Corentin Labbe <clabbe.montjoie@gmail.com> a ?crit :
> > On Tue, Dec 12, 2017 at 09:24:25AM +0100, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Mon, Dec 11, 2017 at 08:35:34PM +0100, Corentin Labbe wrote:
> > > > On Mon, Dec 11, 2017 at 08:49:57AM +0100, Myl?ne Josserand wrote:
> > > > > This series adds SMP support for Allwinner Sun8i-a83t
> > > > > with MCPM (Multi-Cluster Power Management).
> > > > > Series information:
> > > > > - Based on last linux-next (next-20171211)
> > > > > - Had dependencies on Chen Yu's patch that add MCPM
> > > > > support:
> > > > > https://patchwork.kernel.org/patch/6402801/
> > > > >
> > > > > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > > > > to use it for A83T. This SoC has a bit flip that needs to be handled.
> > > > > Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg) needed
> > > > > for MCPM.
> > > > > Patch 03: Add CCI-400 node for a83t.
> > > > > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > > > > case of SMP support.
> > > >
> > > > As we discussed in private, Chen Yu's patch should be added in your series.
> > >
> > > Not really, she mentionned the dependency in the cover letter, and
> > > it's a good way to do things too. Sure, you can do it your way, but
> > > there's no preference.
> > >
> >
> > If the goal of this series is to be applied, the dependency must be applied also.
> > And since the dependency is 2 years old (and part of a serie which does not apply now), I think cherry picking the patch and send it for review is better.
> >
> > > > Furthermore, MCPM is not automaticaly selected via imply.
> > >
> > > Well, yes, is that an issue?
> > >
> >
> > After reading the imply documentation, no.
> >
> > > > With all patchs I hit a bug:
> > > > [ 0.898668] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
> > >
> > > I guess this is with CONFIG_PROVE_LOCKING enabled?
> > >
> >
> > No, the BUG() printed is enabled by default
> >
> > > > [ 0.911162] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
> > > > [ 0.917776] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
> > >
> > > What are the changes you've made?
> > >
> >
> > Just adding wens's patch and this series.
>
> I tried to reproduce your issue without success (even with
> CONFIG_PROVE_LOCKING enabled, just in case).
> Can you give me more details about your tests? which defconfig and
> additional configurations?
>
> >
> > > > [ 0.925418] Hardware name: Allwinner sun8i Family
> > > > [ 0.930118] Backtrace:
> > > > [ 0.932596] [<c010cc50>] (dump_backtrace) from [<c010cf0c>] (show_stack+0x18/0x1c)
> > > > [ 0.940158] r7:c0b261e4 r6:60000013 r5:00000000 r4:c0b51958
> > > > [ 0.945820] [<c010cef4>] (show_stack) from [<c06baccc>] (dump_stack+0x8c/0xa0)
> > > > [ 0.953045] [<c06bac40>] (dump_stack) from [<c0149d40>] (___might_sleep+0x150/0x170)
> > > > [ 0.960779] r7:c0b261e4 r6:00000000 r5:000000ee r4:ee844000
> > > > [ 0.966437] [<c0149bf0>] (___might_sleep) from [<c0149dc8>] (__might_sleep+0x68/0xa0)
> > > > [ 0.974253] r4:c0861690
> > > > [ 0.976796] [<c0149d60>] (__might_sleep) from [<c06d2918>] (mutex_lock+0x24/0x68)
> > > > [ 0.984269] r6:c0892f6c r5:ffffffff r4:c0b1bb24
> > > > [ 0.988891] [<c06d28f4>] (mutex_lock) from [<c01ccb6c>] (perf_pmu_register+0x24/0x3e4)
> > > > [ 0.996795] r5:ffffffff r4:ee98b014
> > > > [ 1.000375] [<c01ccb48>] (perf_pmu_register) from [<c03efabc>] (cci_pmu_probe+0x340/0x484)
> > > > [ 1.008631] r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4 r6:c0b26240 r5:eea19000
> > > > [ 1.016447] r4:ee98b010
> > > > [ 1.018989] [<c03ef77c>] (cci_pmu_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> > > > [ 1.027158] r10:00000000 r9:c0b2610c r8:00000000 r7:fffffdfb r6:c0b2610c r5:ffffffed
> > > > [ 1.034974] r4:eea19010
> > > > [ 1.037511] [<c045e1c4>] (platform_drv_probe) from [<c045c984>] (driver_probe_device+0x254/0x330)
> > > > [ 1.046371] r7:00000000 r6:c0bff498 r5:c0bff494 r4:eea19010
> > > > [ 1.052026] [<c045c730>] (driver_probe_device) from [<c045cbc4>] (__device_attach_driver+0xa0/0xd4)
> > > > [ 1.061062] r10:00000000 r9:c0bff470 r8:00000000 r7:00000001 r6:eea19010 r5:ee845ac0
> > > > [ 1.068879] r4:c0b2610c r3:00000000
> > > > [ 1.072454] [<c045cb24>] (__device_attach_driver) from [<c045ad68>] (bus_for_each_drv+0x68/0x9c)
> > > > [ 1.081228] r7:00000001 r6:c045cb24 r5:ee845ac0 r4:00000000
> > > > [ 1.086883] [<c045ad00>] (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> > > > [ 1.095135] r6:c0b3e848 r5:eea19044 r4:eea19010
> > > > [ 1.099750] [<c045c554>] (__device_attach) from [<c045cc44>] (device_initial_probe+0x14/0x18)
> > > > [ 1.108263] r7:c0b0a4c8 r6:c0b3e848 r5:eea19010 r4:eea19018
> > > > [ 1.113919] [<c045cc30>] (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> > > > [ 1.122523] [<c045bacc>] (bus_probe_device) from [<c0459db8>] (device_add+0x40c/0x5a0)
> > > > [ 1.130429] r7:c0b0a4c8 r6:eea19010 r5:eea18a10 r4:eea19018
> > > > [ 1.136089] [<c04599ac>] (device_add) from [<c0582a58>] (of_device_add+0x3c/0x44)
> > > > [ 1.143564] r10:00000000 r9:00000000 r8:00000000 r7:eedf21a4 r6:eea18a10 r5:00000000
> > > > [ 1.151380] r4:eea19000
> > > > [ 1.153915] [<c0582a1c>] (of_device_add) from [<c0582f80>] (of_platform_device_create_pdata+0x7c/0xac)
> > > > [ 1.163210] [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>] (of_platform_bus_create+0xf4/0x1f0)
> > > > [ 1.173372] r9:00000000 r8:00000000 r7:00000001 r6:00000000 r5:eedf2154 r4:00000000
> > > > [ 1.181107] [<c058300c>] (of_platform_bus_create) from [<c0583374>] (of_platform_populate+0x74/0xd4)
> > > > [ 1.190229] r10:00000001 r9:eea18a10 r8:00000000 r7:00000000 r6:00000000 r5:eedf1d04
> > > > [ 1.198045] r4:eedf2154
> > > > [ 1.200580] [<c0583300>] (of_platform_populate) from [<c03ef2a8>] (cci_platform_probe+0x3c/0x54)
> > > > [ 1.209356] r10:00000000 r9:c0b26168 r8:00000000 r7:fffffdfb r6:c0b26168 r5:ffffffed
> > > > [ 1.217172] r4:eea18a00
> > > > [ 1.219708] [<c03ef26c>] (cci_platform_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> > > > [ 1.228306] r5:ffffffed r4:eea18a10
> > > > [ 1.231881] [<c045e1c4>] (platform_drv_probe) from [<c045c984>] (driver_probe_device+0x254/0x330)
> > > > [ 1.240742] r7:00000000 r6:c0bff498 r5:c0bff494 r4:eea18a10
> > > > [ 1.246397] [<c045c730>] (driver_probe_device) from [<c045cbc4>] (__device_attach_driver+0xa0/0xd4)
> > > > [ 1.255433] r10:00000000 r9:c0bff470 r8:00000000 r7:00000001 r6:eea18a10 r5:ee845ce8
> > > > [ 1.263250] r4:c0b26168 r3:00000000
> > > > [ 1.266825] [<c045cb24>] (__device_attach_driver) from [<c045ad68>] (bus_for_each_drv+0x68/0x9c)
> > > > [ 1.275598] r7:00000001 r6:c045cb24 r5:ee845ce8 r4:00000000
> > > > [ 1.281253] [<c045ad00>] (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> > > > [ 1.289506] r6:c0b3e848 r5:eea18a44 r4:eea18a10
> > > > [ 1.294120] [<c045c554>] (__device_attach) from [<c045cc44>] (device_initial_probe+0x14/0x18)
> > > > [ 1.302633] r7:c0b0a4c8 r6:c0b3e848 r5:eea18a10 r4:eea18a18
> > > > [ 1.308288] [<c045cc30>] (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> > > > [ 1.316890] [<c045bacc>] (bus_probe_device) from [<c0459db8>] (device_add+0x40c/0x5a0)
> > > > [ 1.324796] r7:c0b0a4c8 r6:eea18a10 r5:ee993810 r4:eea18a18
> > > > [ 1.330450] [<c04599ac>] (device_add) from [<c0582a58>] (of_device_add+0x3c/0x44)
> > > > [ 1.337926] r10:00000000 r9:c07759d8 r8:00000000 r7:eedf1d54 r6:ee993810 r5:00000000
> > > > [ 1.345743] r4:eea18a00
> > > > [ 1.348277] [<c0582a1c>] (of_device_add) from [<c0582f80>] (of_platform_device_create_pdata+0x7c/0xac)
> > > > [ 1.357572] [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>] (of_platform_bus_create+0xf4/0x1f0)
> > > > [ 1.367734] r9:c07759d8 r8:00000000 r7:00000001 r6:00000000 r5:eedf1d04 r4:00000000
> > > > [ 1.375469] [<c058300c>] (of_platform_bus_create) from [<c058315c>] (of_platform_bus_create+0x150/0x1f0)
> > > > [ 1.384938] r10:ee993810 r9:c07759d8 r8:00000000 r7:00000001 r6:00000000 r5:eedefe1c
> > > > [ 1.392754] r4:eedf1d04
> > > > [ 1.395289] [<c058300c>] (of_platform_bus_create) from [<c0583374>] (of_platform_populate+0x74/0xd4)
> > > > [ 1.404411] r10:00000001 r9:00000000 r8:00000000 r7:c07759d8 r6:00000000 r5:eedee844
> > > > [ 1.412228] r4:eedefe1c
> > > > [ 1.414769] [<c0583300>] (of_platform_populate) from [<c0a25ee8>] (of_platform_default_populate_init+0x80/0x94)
> > > > [ 1.424844] r10:c0a37848 r9:00000000 r8:c0b59680 r7:c0a37834 r6:ffffe000 r5:c0775ce8
> > > > [ 1.432661] r4:00000000
> > > > [ 1.435200] [<c0a25e68>] (of_platform_default_populate_init) from [<c0102794>] (do_one_initcall+0x5c/0x194)
> > > > [ 1.444925] r5:c0a25e68 r4:c0b0a4c8
> > > > [ 1.448506] [<c0102738>] (do_one_initcall) from [<c0a00f88>] (kernel_init_freeable+0x1d4/0x268)
> > > > [ 1.457195] r9:00000004 r8:c0b59680 r7:c0a37834 r6:c0b59680 r5:c0a47308 r4:c090cfb8
> > > > [ 1.464932] [<c0a00db4>] (kernel_init_freeable) from [<c06cf3b0>] (kernel_init+0x10/0x118)
> > > > [ 1.473187] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c06cf3a0
> > > > [ 1.481004] r4:00000000
> > > > [ 1.483540] [<c06cf3a0>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> > > > [ 1.491098] Exception stack(0xee845fb0 to 0xee845ff8)
> > > > [ 1.496146] 5fa0: 00000000 00000000 00000000 00000000
> > > > [ 1.504313] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > > > [ 1.512480] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > > > [ 1.519084] r5:c06cf3a0 r4:00000000
> > > > [ 1.522737] ARM CCI_400_r1 PMU driver probed
> > > >
> > > > And only CPU 0 show up.
> > >
> > > This looks more like a bug in the CCI code, and not in this serie
> > > itself. Can you share your whole boot logs?
> > >
> >
> > This week end I will retry and send it.
>
> By any chance, did you try it again? Can you reproduce it on your side?
>
Hello
With the .config that you give me in private, everything seems to work.
But with mine, the stacktrace still happen.
After some research, this is due to the following code:
cpumask_set_cpu(get_cpu(), &cci_pmu->cpus);
which disable preemption (via get_cpu())
So it is unrelated with your patch, I will send a bug report tomorow.
Furthermore, you can add:
Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Thanks
Regards
^ permalink raw reply
* [PATCH v2] arm64: dts: Hi3660: Fix up psci state id
From: Wei Xu @ 2017-12-28 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A3CD23C.3080307@hisilicon.com>
Hi Leo,
On 2017/12/22 9:37, Wei Xu wrote:
> Hi Leo,
>
> On 2017/12/12 9:12, Leo Yan wrote:
>> Thanks a lot for Vincent Guittot careful work to find bug for 'CPU_NAP'
>> idle state. From ftrace log we can observe CA73 CPUs can be easily
>> waken up from 'CPU_NAP' state but the 'waken up' CPUs doesn't handle
>> anything and sleep again; so there have tons of trace events for CA73
>> CPUs entering and exiting idle state.
>>
>> On Hi3660 CA73 has retention state 'CPU_NAP' for CPU idle, this state we
>> set its psci parameter as '0x0000001' and from this parameter it can
>> calculate state id is 1. Unfortunately ARM trusted firmware (ARM-TF)
>> takes 1 as a invalid value for state id, so the CPU cannot enter idle
>> state and directly bail out to kernel.
>>
>> We want to create good practice for psci parameters platform definition,
>> so review the psci specification. The spec "ARM Power State Coordination
>> Interface - Platform Design Document (ARM DEN 0022D)" recommends state
>> ID in chapter "6.5 Recommended StateID Encoding". The recommended power
>> state IDs can be presented by below listed values; and it divides into
>> three fields, every field can use 4 bits to present power states
>> corresponding to core level, cluster level and system level:
>> 0: Run
>> 1: Standby
>> 2: Retention
>> 3: Powerdown
>>
>> This commit changes psci parameter to compliance with the suggested
>> state ID in the doc. Except we change 'CPU_NAP' state psci parameter
>> to '0x0000002', this commit also changes 'CPU_SLEEP' and 'CLUSTER_SLEEP'
>> state parameters to '0x0010003' and '0x1010033' respectively.
>>
>> Credits to Daniel, Sudeep and Soby for suggestion and consolidation.
>>
>> Cc: Vincent Guittot <vincent.guittot@linaro.org>
>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Soby Mathew <Soby.Mathew@arm.com>
>> Signed-off-by: Leo Yan <leo.yan@linaro.org>
>> ---
>
> Applied into hisilicon dt tree.
> Thanks!
Sorry, since this patch is still under discussion,
I will drop it firstly.
Thanks!
Best Regards,
Wei
>
> Best Regards,
> Wei
>
>> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>> index ab0b95b..99d5a46 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>> @@ -147,7 +147,7 @@
>>
>> CPU_NAP: cpu-nap {
>> compatible = "arm,idle-state";
>> - arm,psci-suspend-param = <0x0000001>;
>> + arm,psci-suspend-param = <0x0000002>;
>> entry-latency-us = <7>;
>> exit-latency-us = <2>;
>> min-residency-us = <15>;
>> @@ -156,7 +156,7 @@
>> CPU_SLEEP: cpu-sleep {
>> compatible = "arm,idle-state";
>> local-timer-stop;
>> - arm,psci-suspend-param = <0x0010000>;
>> + arm,psci-suspend-param = <0x0010003>;
>> entry-latency-us = <40>;
>> exit-latency-us = <70>;
>> min-residency-us = <3000>;
>> @@ -165,7 +165,7 @@
>> CLUSTER_SLEEP_0: cluster-sleep-0 {
>> compatible = "arm,idle-state";
>> local-timer-stop;
>> - arm,psci-suspend-param = <0x1010000>;
>> + arm,psci-suspend-param = <0x1010033>;
>> entry-latency-us = <500>;
>> exit-latency-us = <5000>;
>> min-residency-us = <20000>;
>> @@ -174,7 +174,7 @@
>> CLUSTER_SLEEP_1: cluster-sleep-1 {
>> compatible = "arm,idle-state";
>> local-timer-stop;
>> - arm,psci-suspend-param = <0x1010000>;
>> + arm,psci-suspend-param = <0x1010033>;
>> entry-latency-us = <1000>;
>> exit-latency-us = <5000>;
>> min-residency-us = <20000>;
>>
^ permalink raw reply
* [GIT PULL] arm64: dts: hisilicon dts updates for v4.16
From: Wei Xu @ 2017-12-28 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A3CD3EE.7030505@hisilicon.com>
Hi Arnd, Hi Olof, Hi Kevin,
On 2017/12/22 9:44, Wei Xu wrote:
> Hi Arnd, Hi Olof, Hi Kevin,
>
> Please help to pull the following changes.
> Thanks!
Sorry!
Please ignore this pull because the PSCI patch is still under discussion.
I will drop that patch and send v2.
Thanks!
Best Regards,
Wei
>
> Best Regards,
> Wei
>
> ---
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-4.16
>
> for you to fetch changes up to 2b49083a2d93b1adb755f057ed569d1ae6a934c7:
>
> arm64: dts: Hi3660: Fix up psci state id (2017-12-22 09:11:43 +0000)
>
> ----------------------------------------------------------------
> ARM64: DT: Hisilicon SoC DT updates for 4.15
>
> - Add SD card support for hi3798cv200-poplar board
> - Replace the PMU node with exact match on hi3660 SoC
> - Add cpu capacity-dmips-mhz information on hi3660 SoC
> - Fix up the PSCI state ID on hi3660 SoC
>
> ----------------------------------------------------------------
> Leo Yan (1):
> arm64: dts: Hi3660: Fix up psci state id
>
> Shawn Guo (1):
> arm64: dts: hi3798cv200: add SD card support
>
> Valentin Schneider (1):
> arm64: dts: hisilicon: Add hi3660 cpu capacity-dmips-mhz information
>
> Xu YiPing (1):
> arm64: dts: hi3660: improve pmu description
>
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 38 ++++++++++++++--------
> .../boot/dts/hisilicon/hi3798cv200-poplar.dts | 6 ++++
> arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 12 +++++++
> 3 files changed, 43 insertions(+), 13 deletions(-)
>
^ permalink raw reply
* [GIT PULL v2] arm64: dts: hisilicon dts updates for v4.16
From: Wei Xu @ 2017-12-28 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A3CD3EE.7030505@hisilicon.com>
Hi Arnd, Hi Olof, Hi Kevin,
Please help to pull the following changes.
Thanks!
Best Regards,
Wei
---
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-4.16-v2
for you to fetch changes up to 9a9760dede5c71e04b17b2ede594ee7148fd36e2:
arm64: dts: hisilicon: Add hi3660 cpu capacity-dmips-mhz information (2017-12-22 09:11:42 +0000)
----------------------------------------------------------------
ARM64: DT: Hisilicon SoC DT updates for 4.16
- Add SD card support for the hi3798cv200-poplar board
- Replace the PMU node with exact match for the hi3660 SoC
- Add cpu capacity-dmips-mhz information for the hi3660 SoC
----------------------------------------------------------------
Shawn Guo (1):
arm64: dts: hi3798cv200: add SD card support
Valentin Schneider (1):
arm64: dts: hisilicon: Add hi3660 cpu capacity-dmips-mhz information
Xu YiPing (1):
arm64: dts: hi3660: improve pmu description
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 30 +++++++++++++++-------
.../boot/dts/hisilicon/hi3798cv200-poplar.dts | 6 +++++
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 12 +++++++++
3 files changed, 39 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH v1 1/4] clk: iproc: Allow iproc pll to runtime calculate vco parameters
From: Stephen Boyd @ 2017-12-28 22:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1502737241-2040-2-git-send-email-lori.hikichi@broadcom.com>
On 08/14, Lori Hikichi wrote:
> Add the ability for the iproc pll to calculate the pll parameters at
> runtime instead of only using predefined tables. This ability allows
> the clock users to select from the full range of vco frequencies.
> The old method of table based programming is retained so that existing
> users will retain expected behavior. The flag IPROC_CLK_PLL_CALC_PARAM
> will need to be set to enable the new runtime calculation method.
> Currently, this is only being enabled for the audio pll.
>
> This feature also revealed a problem with the driver using the
> round_rate api. The round_rate api does not allow for frequencies larger
> than 2^31 to be returned. Those large frequencies are interpreted as an
> error code. Therefore, we are moving to the determine_rate api which
> solves this problem.
>
> Signed-off-by: Simran Rai <ssimran@broadcom.com>
> Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v1 2/4] clk: iproc: Fix error in the pll post divider rate calculation
From: Stephen Boyd @ 2017-12-28 22:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1502737241-2040-3-git-send-email-lori.hikichi@broadcom.com>
On 08/14, Lori Hikichi wrote:
> The pll post divider code was using DIV_ROUND_UP when determining the
> divider value best suited to produce the target frequency.
> Using DIV_ROUND_CLOSEST will give us better divider values when
> the division results in a small remainder.
> Also, change the post divider clock over to the determine_rate api
> instead of round_rate.
>
> Signed-off-by: Simran Rai <ssimran@broadcom.com>
> Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v1 3/4] clk: iproc: Allow plls to do minor rate changes without reset
From: Stephen Boyd @ 2017-12-28 22:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1502737241-2040-4-git-send-email-lori.hikichi@broadcom.com>
On 08/14, Lori Hikichi wrote:
> From: Lori Hikichi <lhikichi@broadcom.com>
>
> The iproc plls are capable of doing small rate changes without the
> need for a full reset and re-lock procedure. This feature will
> allow for small tweaks to the PLL rate to occur smoothly.
>
> Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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