* [PATCH 00/11] drm/vc4: DSI panel support + Raspberry Pi touchscreen
From: Eric Anholt @ 2016-12-14 19:46 UTC (permalink / raw)
To: linux-arm-kernel
After 9 months of development, I finally got the DSI panel to light up
from poweron, and this is the series for enabling it. I've included
the whole thing Cced to all the subsystems, as there are some
interesting choices we have to make (how the analog PHY clocks are
represented in common clocks? and how the touchscreen panel is
represented in DT).
There's one commit left out of the series, which is the fix to allow
bcm2835_dma.c's poll-for-completion from IRQ handlers for the DSI1
register write workaround. However, with the panel's DSI transaction
workaround, we're not triggering our IRQ handler anyway.
Note that patch #11 is not intended to be pushed, it's just a demo.
Eric Anholt (11):
clk: bcm2835: Don't rate change PLLs on behalf of DSI PLL dividers.
clk: bcm2835: Register the DSI0/DSI1 pixel clocks.
clk: bcm2835: Add leaf clock measurement support, disabled by default
drm/vc4: Set up SCALER_DISPCTRL at boot.
drm/vc4: Add support for feeding DSI encoders from the pixel valve.
dt-bindings: Document the VC4 DSI module nodes.
drm/vc4: Add DSI driver
dt-bindings: Document the Raspberry Pi Touchscreen nodes.
drm/panel: Add support for the Raspberry Pi 7" Touchscreen.
ARM: bcm2835: dt: Add the DSI module nodes and clocks.
ARM: bcm2835: Enable the Raspberry Pi touchscreen panel.
.../bindings/clock/brcm,bcm2835-cprman.txt | 15 +-
.../devicetree/bindings/display/brcm,bcm-vc4.txt | 35 +
.../display/panel/raspberrypi,touchscreen.txt | 45 +
arch/arm/boot/dts/bcm2835-rpi.dtsi | 8 +
arch/arm/boot/dts/bcm283x.dtsi | 77 +-
drivers/clk/bcm/clk-bcm2835.c | 302 +++-
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile | 1 +
.../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 509 ++++++
drivers/gpu/drm/vc4/Kconfig | 2 +
drivers/gpu/drm/vc4/Makefile | 1 +
drivers/gpu/drm/vc4/vc4_crtc.c | 33 +-
drivers/gpu/drm/vc4/vc4_debugfs.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.h | 5 +
drivers/gpu/drm/vc4/vc4_dsi.c | 1725 ++++++++++++++++++++
drivers/gpu/drm/vc4/vc4_hvs.c | 14 +
drivers/gpu/drm/vc4/vc4_regs.h | 5 +
include/dt-bindings/clock/bcm2835.h | 2 +
19 files changed, 2722 insertions(+), 67 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/raspberrypi,touchscreen.txt
create mode 100644 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
create mode 100644 drivers/gpu/drm/vc4/vc4_dsi.c
--
2.11.0
^ permalink raw reply
* [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: PrasannaKumar Muralidharan @ 2016-12-14 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214050551.GD9592@gondor.apana.org.au>
>> I have found two solutions:
>
> No we already have algif_rng so let's not confuse things even
> further by making hwrng take PRNGs.
Even if both the solutions could not be adopted I think there must be
a way for applications to use similar API to get true rng or prng.
Given the case that no user complained about prng data when using
/dev/hwrng is it safe to assume that the random data generated is
acceptable for users? If so, the drivers can be left without any
modification.
Should there be a mandate that driver will be accepted only when it
passes 'rngtest'. This will make sure that prng drivers won't get
added in future.
Regards,
PrasannaKumar
^ permalink raw reply
* [PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager
From: Florian Fainelli @ 2016-12-14 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <SN1PR0101MB1565A30EFE8AFEB319B84124D09A0@SN1PR0101MB1565.prod.exchangelabs.com>
On 12/14/2016 10:58 AM, Hartley Sweeten wrote:
> On Wednesday, December 14, 2016 11:55 AM, Florian Fainelli wrote:
>> My understanding is that, yes, this triggers the final write. You are
>> right that ts73xx_fpga_write() can be called multiple times. It sounds
>> like what my write_complete function does right now is just return that
>> we successfully completed the bistream write, but this snippet that you
>> are quoting should actually be moved into write_complete.
>
> Florian,
>
> I'm in the process of getting a TS-7300 board so I can help test this. Hopefully
> I will have it by next week.
Great! I got a few things on my list that have not been submitted yet:
- tmp124 support through drivers/hwmon/lm70.c
- specific memcpy_{from,to}io accessors for ethoc from the FPGA
- serial port support for the UARTs from the FPGA
And some other things that are giving me issues at the moment, like
SPI_3WIRE support for spi-ep93xx so I can configure the tmp124 to send
alarms/have temperature thresholds.
My branch is here:
https://github.com/ffainelli/linux/tree/ts72xx
Cheers
--
Florian
^ permalink raw reply
* [PATCH v4 00/12] mmc: Add support to Marvell Xenon SD Host Controller
From: Marcin Wojtas @ 2016-12-14 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKeE_2gMn12MXraoUmDEJhi307mGuc4BgDYpethKNsMqRQ@mail.gmail.com>
Resend in plain text, sorry for noise.
2016-12-14 20:02 GMT+01:00 Marcin Wojtas <mw@semihalf.com>:
> Hi Gregory,
>
> Checked a3700 and a7k (both interfaces, CP - one after changing to use eMMC
> variant in DT). Everything works fine. You can add:
>
> Tested-by: Marcin Wojtas <mw@semihalf.com>
>
> Best regards,
> Marcin
>
> 2016-12-13 18:48 GMT+01:00 Gregory CLEMENT
> <gregory.clement@free-electrons.com>:
>>
>> Hello,
>>
>> This the forth version of the series adding support for the SDHCI
>> Xenon controller. It can be currently found on the Armada 37xx and the
>> Armada 7K/8K but will be also used in more Marvell SoC (and not only
>> the mvebu ones actually).
>>
>> v3 -> v4:
>> For this version a few change have been done:
>> - fixes 2 bug reported by kbuild-bot
>> - remove extra of_node_put()
>> - convert 0 in false for function returning boolean
>>
>> - add a device tree node for the sdhci controller present on the CP
>> master for A7K/A8K. It also led to rename the sdhci0 node on AP to
>> ap_sdhci0 to make a distinction with the one present on CP master.
>>
>> v2 -> v3
>> I think that now most (if not all) the remarks had been taking into
>> account since the second version. According to Ziji Hu, here are the
>> following changes:
>> " Changes in V3:
>> Adjust and improve Xenon DT bindings. Move some caps setting from driver
>> into
>> DT. Use mmc-card sub-node to represent eMMC type.
>> Remove PHY Sampling Fixed Delay Line scan in lower speed mode.
>> Improve Xenon probe and ->init_card() functions.
>> Export sdhci_enable_sdio_irq() and implement own SDIO IRQ control.
>> Split PHY patch into two smaller patches.
>> Temporarily remove AXI clock before its implementation is improved."
>>
>> Besides this changes I also
>> - Removed the sdhci-xenon-phy.h and moved its content in the
>> shc-xenon-phy.c file.
>> - Fixed the tuning-count usage
>> - Managed the error case for clk_prepare_enable
>>
>> For the record the change from v1 was:
>> " Changes in V2:
>> rebase on v4.9-rc2.
>> Re-write Xenon bindings. Ajust Xenon DT property naming.
>> Add a new DT property to indicate eMMC card type, instead of using
>> variable card_candidate.
>> Clear quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 in Xenon platform data
>> Add support to HS400 retuning."
>>
>> Thanks,
>>
>> Gregory
>>
>> Gregory CLEMENT (3):
>> arm64: dts: marvell: add eMMC support for Armada 37xx
>> arm64: dts: marvell: add sdhci support for Armada 7K/8K
>> arm64: configs: enable SDHCI driver for Xenon
>>
>> Hu Ziji (9):
>> mmc: sdhci: Export sdhci_set_ios() from sdhci.c
>> mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
>> mmc: sdhci: Export sdhci_execute_tuning() in sdhci.c
>> mmc: sdhci: Export sdhci_enable_sdio_irq() from sdhci.c
>> MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers
>> dt: bindings: Add bindings for Marvell Xenon SD Host Controller
>> mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
>> mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC.
>> mmc: sdhci-xenon: Add SOC PHY PAD voltage control
>>
>> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 197 ++-
>> MAINTAINERS | 7 +-
>> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 17 +-
>> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 11 +-
>> arch/arm64/boot/dts/marvell/armada-7040-db.dts | 14 +-
>> arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 9 +-
>> arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 10 +-
>> arch/arm64/configs/defconfig | 1 +-
>> drivers/mmc/host/Kconfig | 9 +-
>> drivers/mmc/host/Makefile | 3 +-
>> drivers/mmc/host/sdhci-xenon-phy.c | 908
>> +++++++-
>> drivers/mmc/host/sdhci-xenon.c | 615
>> +++++-
>> drivers/mmc/host/sdhci-xenon.h | 111 +-
>> drivers/mmc/host/sdhci.c | 14 +-
>> drivers/mmc/host/sdhci.h | 5 +-
>> 15 files changed, 1926 insertions(+), 5 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
>> create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c
>> create mode 100644 drivers/mmc/host/sdhci-xenon.c
>> create mode 100644 drivers/mmc/host/sdhci-xenon.h
>>
>> base-commit: 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
>> --
>> git-series 0.9.1
>
>
^ permalink raw reply
* [PATCH] i2c: designware: add reset interface
From: Andy Shevchenko @ 2016-12-14 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213203457.GB2889@katana>
On Tue, 2016-12-13 at 21:34 +0100, Wolfram Sang wrote:
> On Tue, Nov 22, 2016 at 12:41:40PM +0800, Zhangfei Gao wrote:
> > Some platforms like hi3660 need do reset first to allow accessing
> > registers
> >
> > Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>
> Adding designware maintainers to CC...
>
> > ---
> > ?drivers/i2c/busses/i2c-designware-core.h????| 1 +
> > ?drivers/i2c/busses/i2c-designware-platdrv.c | 5 +++++
> > ?2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/i2c/busses/i2c-designware-core.h
> > b/drivers/i2c/busses/i2c-designware-core.h
> > index 0d44d2a..94b14fa 100644
> > --- a/drivers/i2c/busses/i2c-designware-core.h
> > +++ b/drivers/i2c/busses/i2c-designware-core.h
> > @@ -80,6 +80,7 @@ struct dw_i2c_dev {
> > ? void __iomem *base;
> > ? struct completion cmd_complete;
> > ? struct clk *clk;
> > + struct reset_control *rst;
> > ? u32 (*get_clk_rate_khz) (struct
> > dw_i2c_dev *dev);
> > ? struct dw_pci_controller *controller;
> > ? int cmd_err;
> > diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> > b/drivers/i2c/busses/i2c-designware-platdrv.c
> > index 0b42a12..fd80e58 100644
> > --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> > @@ -38,6 +38,7 @@
> > ?#include <linux/pm_runtime.h>
> > ?#include <linux/property.h>
> > ?#include <linux/io.h>
> > +#include <linux/reset.h>
> > ?#include <linux/slab.h>
> > ?#include <linux/acpi.h>
> > ?#include <linux/platform_data/i2c-designware.h>
> > @@ -176,6 +177,10 @@ static int dw_i2c_plat_probe(struct
> > platform_device *pdev)
> > ? dev->irq = irq;
> > ? platform_set_drvdata(pdev, dev);
> > ?
> > + dev->rst = devm_reset_control_get(&pdev->dev, NULL);
> > + if (!IS_ERR(dev->rst))
> > + reset_control_reset(dev->rst);
Do we care about EPROBE_DEFER?
Perhaps on error path we need to assert it.
And I guess it should be devm_reset_control_get_optional().
> > +
> > ? /* fast mode by default because of legacy reasons */
> > ? dev->clk_freq = 400000;
> > ?
> > --?
> > 2.7.4
> >
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager
From: Hartley Sweeten @ 2016-12-14 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cf772070-73d9-fa07-b2b9-e0038832b7be@gmail.com>
On Wednesday, December 14, 2016 11:55 AM, Florian Fainelli wrote:
> My understanding is that, yes, this triggers the final write. You are
> right that ts73xx_fpga_write() can be called multiple times. It sounds
> like what my write_complete function does right now is just return that
> we successfully completed the bistream write, but this snippet that you
> are quoting should actually be moved into write_complete.
Florian,
I'm in the process of getting a TS-7300 board so I can help test this. Hopefully
I will have it by next week.
Hartley
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Stefan Wahren @ 2016-12-14 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481706204.3994.4.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 14. Dezember 2016 um 10:03 geschrieben:
>
>
> Hi Stefan,
>
> On Wed, 2016-12-07 at 20:23 +0100, Stefan Wahren wrote:
> > Hi J?rg,
> >
> > > J?rg Krause <joerg.krause@embedded.rocks> hat am 7. Dezember 2016
> > > um 08:32
> > > geschrieben:
> > >
> > >
> > > Hit Stefan,
> > >
> > > On Sat, 2016-11-26 at 20:10 +0100, Stefan Wahren wrote:
> > > > Hi J?rg,
> > > >
> > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November
> > > > > 2016
> > > > > um 20:10
> > > > > geschrieben:
> > > > >
> > > > >
> > > > > On Sun, 2016-11-20 at 16:44 +0100, Stefan Wahren wrote:
> > > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20.
> > > > > > > November
> > > > > > > 2016
> > > > > > > um 15:42
> > > > > > > geschrieben:
> > > > > > >
> > > > > > >
> > > > > > > Hi Stefan,
> > > > > > >
> > > > > > > On Sun, 2016-11-20 at 14:28 +0100, Stefan Wahren wrote:
> > > > > > > > Hi J?rg,
> > > > > > > >
> > > > > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20.
> > > > > > > > > November
> > > > > > > > > 2016
> > > > > > > > > um 13:27
> > > > > > > > > geschrieben:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I started the discussion on this mailing list in
> > > > > > > > > another
> > > > > > > > > thread
> > > > > > > > > [1],
> > > > > > > > > but I'd like to move it to a new thread, because it
> > > > > > > > > might
> > > > > > > > > be
> > > > > > > > > mmc
> > > > > > > > > specific.
> > > > > > > > >
> > > > > > > > > The issue is that I am noticed low wifi network
> > > > > > > > > throughput
> > > > > > > > > on
> > > > > > > > > an
> > > > > > > > > i.MX28
> > > > > > > > > board with the mainline kernel (v4.7.10, about 6 Mbps)
> > > > > > > > > compared
> > > > > > > > > to
> > > > > > > > > the
> > > > > > > > > vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The
> > > > > > > > > wifi
> > > > > > > > > chip
> > > > > > > > > is
> > > > > > > > > attached using the SDIO interface.
> > > > > > > > >
> > > > > > > > > I started investigation where the bottleneck in the
> > > > > > > > > mainline
> > > > > > > > > kernel might come from. Therefore I checked that the
> > > > > > > > > configs
> > > > > > > > > and
> > > > > > > > > settings for the interfaces and drivers are the same.
> > > > > > > > > They
> > > > > > > > > are.
> > > > > > > >
> > > > > > > > so you're not using the mxs_defconfig settings anymore?
> > > > > > >
> > > > > > > No, I changed the settings.
> > > > > > >
> > > > > >
> > > > > > What happens to performance to if you change the following
> > > > > > settings
> > > > > > to the same
> > > > > > like in mxs_defconfig?
> > > > > >
> > > > > > CONFIG_PREEMPT_VOLUNTARY=y
> > > > > > CONFIG_DEFAULT_IOSCHED="noop"
> > > > >
> > > > > No much change at all. The time difference between complete()
> > > > > and
> > > > > wait_for_complete() decreases in best case to 110 us, but also
> > > > > varies
> > > > > to above 130 us.
> > > >
> > > > just a weird idea. Did you tried to add MMC_CAP_CMD23 into the
> > > > caps
> > > > [1]?
> > > >
> > > > [1] - http://lxr.free-electrons.com/source/drivers/mmc/host/mxs-m
> > > > mc.c
> > > > ?v=4.8#L642
> > >
> > > I tried, but it did not improved the timing or throughput. However,
> > > many thanks for the input.
> > >
> > > J?rg
> >
> > did you try cyclictest [1]?
>
> Not yet. Not sure what to measure and which values to compare here.
i tought you have the vendor kernel and the mainline kernel available for your platform.
So you could compare the both kernels.
>
> >
> > Beside the time for a request the amount of requests for the complete
> > iperf test
> > would we interesting. Maybe there are retries.
> >
> > I'm still interested in your PIO mode patches for mxs-mmc even
> > without clean up.
>
> Actually, the patch does not implement a PIO mode, but drops DMA and
> uses polling instead. I've attached the patch.
Thanks. I applied it, but unfortunately this breaks SD card support for my Duckbill and the kernel isn't able to mount the rootfs:
[ 2.267073] mxs-mmc 80010000.ssp: initialized
[ 2.272624] mxs-mmc 80010000.ssp: AC command error 0xffffff92
>
> > [1] - https://git.kernel.org/cgit/utils/rt-tests/rt-tests.git/
>
> Best regards
> J?rg
^ permalink raw reply
* [PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager
From: Florian Fainelli @ 2016-12-14 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAtXAHe6q2jRWXt+KUWCFnP5j21E3x=P+4wjZTOaSSB_pX71Eg@mail.gmail.com>
On 12/13/2016 10:07 PM, Moritz Fischer wrote:
> Hi Florian,
>
> On Tue, Dec 13, 2016 at 6:35 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> Add support for loading bitstreams on the Altera Cyclone II FPGA
>> populated on the TS-7300 board. This is done through the configuration
>> and data registers offered through a memory interface between the EP93xx
>> SoC and the FPGA via an intermediate CPLD device.
>>
>> The EP93xx SoC on the TS-7300 does not have direct means of configuring
>> the on-board FPGA other than by using the special memory mapped
>> interface to the CPLD. No other entity on the system can control the
>> FPGA bitstream.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/fpga/Kconfig | 7 ++
>> drivers/fpga/Makefile | 1 +
>> drivers/fpga/ts73xx-fpga.c | 163 +++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 171 insertions(+)
>> create mode 100644 drivers/fpga/ts73xx-fpga.c
>>
>> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
>> index ce861a2853a4..d9cbef60db80 100644
>> --- a/drivers/fpga/Kconfig
>> +++ b/drivers/fpga/Kconfig
>> @@ -33,6 +33,13 @@ config FPGA_MGR_SOCFPGA_A10
>> help
>> FPGA manager driver support for Altera Arria10 SoCFPGA.
>>
>> +config FPGA_MGR_TS73XX
>> + tristate "Technologic Systems TS-73xx SBC FPGA Manager"
>> + depends on ARCH_EP93XX && MACH_TS72XX
>> + help
>> + FPGA manager driver support for the Altera Cyclone II FPGA
>> + present on the TS-73xx SBC boards.
>> +
>> config FPGA_MGR_ZYNQ_FPGA
>> tristate "Xilinx Zynq FPGA"
>> depends on ARCH_ZYNQ || COMPILE_TEST
>> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
>> index 8df07bcf42a6..a1160169e6d9 100644
>> --- a/drivers/fpga/Makefile
>> +++ b/drivers/fpga/Makefile
>> @@ -8,6 +8,7 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o
>> # FPGA Manager Drivers
>> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
>> obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
>> +obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
>> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
>>
>> # FPGA Bridge Drivers
>> diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c
>> new file mode 100644
>> index 000000000000..38d78d8c6b1e
>> --- /dev/null
>> +++ b/drivers/fpga/ts73xx-fpga.c
>> @@ -0,0 +1,163 @@
>> +/*
>> + * Technologic Systems TS-73xx SBC FPGA loader
>> + *
>> + * Copyright (C) 2016 Florian Fainelli <f.fainelli@gmail.com>
>> + *
>> + * FPGA Manager Driver for the on-board Altera Cyclone II FPGA found on
>> + * TS-7300, heavily based on load_fpga.c in their vendor tree.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; version 2 of the License.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/string.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/fpga/fpga-mgr.h>
>> +
>> +#define TS73XX_FPGA_DATA_REG 0
>> +#define TS73XX_FPGA_CONFIG_REG 1
>> +
>> +#define TS73XX_FPGA_WRITE_DONE 0x1
>> +#define TS73XX_FPGA_WRITE_DONE_TIMEOUT 1000 /* us */
>> +#define TS73XX_FPGA_RESET 0x2
>> +#define TS73XX_FPGA_RESET_LOW_DELAY 30 /* us */
>> +#define TS73XX_FPGA_RESET_HIGH_DELAY 80 /* us */
>> +#define TS73XX_FPGA_LOAD_OK 0x4
>> +#define TS73XX_FPGA_CONFIG_LOAD 0x8
>> +
>> +struct ts73xx_fpga_priv {
>> + void __iomem *io_base;
>> + struct device *dev;
>> +};
>> +
>> +static enum fpga_mgr_states ts73xx_fpga_state(struct fpga_manager *mgr)
>> +{
>> + return FPGA_MGR_STATE_UNKNOWN;
>> +}
>> +
>> +static int ts73xx_fpga_write_init(struct fpga_manager *mgr,
>> + struct fpga_image_info *info,
>> + const char *buf, size_t count)
>> +{
>> + struct ts73xx_fpga_priv *priv = mgr->priv;
>> +
>> + /* Reset the FPGA */
>> + writeb(0, priv->io_base + TS73XX_FPGA_CONFIG_REG);
>> + udelay(TS73XX_FPGA_RESET_LOW_DELAY);
>> + writeb(TS73XX_FPGA_RESET, priv->io_base + TS73XX_FPGA_CONFIG_REG);
>> + udelay(TS73XX_FPGA_RESET_HIGH_DELAY);
>> +
>> + return 0;
>> +}
>> +
>> +static int ts73xx_fpga_write(struct fpga_manager *mgr, const char *buf,
>> + size_t count)
>> +{
>> + struct ts73xx_fpga_priv *priv = mgr->priv;
>> + size_t i = 0;
>> + int ret;
>> + u8 reg;
>> +
>> + while (count--) {
>> + ret = readb_poll_timeout(priv->io_base + TS73XX_FPGA_CONFIG_REG,
>> + reg, !(reg & TS73XX_FPGA_WRITE_DONE),
>> + 1, TS73XX_FPGA_WRITE_DONE_TIMEOUT);
>> + if (ret < 0)
>> + return ret;
>> +
>> + writeb(buf[i], priv->io_base + TS73XX_FPGA_DATA_REG);
>> + i++;
>> + }
>> +
>
> <snip>
>> + usleep_range(1000, 2000);
>> + reg = readb(priv->io_base + TS73XX_FPGA_CONFIG_REG);
>> + reg |= TS73XX_FPGA_CONFIG_LOAD;
>> + writeb(reg, priv->io_base + TS73XX_FPGA_CONFIG_REG);
>> + usleep_range(1000, 2000);
>
> </snip>
>
> Just to clarify is this block what triggers the actual write? I'm asking because
> I'm wondering if in the current implementation the ts73xx_fpga_write() function
> can be called multiple times in your implementation before you finally get to
> the write complete callback.
My understanding is that, yes, this triggers the final write. You are
right that ts73xx_fpga_write() can be called multiple times. It sounds
like what my write_complete function does right now is just return that
we successfully completed the bistream write, but this snippet that you
are quoting should actually be moved into write_complete.
Does that sound reasonable?
--
Florian
^ permalink raw reply
* [PATCH v3 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
From: Florian Fainelli @ 2016-12-14 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAtXAHcO4bN2YmrEabiivnBJLXdU56j4rv4A12FL_XKuwc5Dxw@mail.gmail.com>
On 12/13/2016 10:14 PM, Moritz Fischer wrote:
> Hi Florian,
>
> On Tue, Dec 13, 2016 at 6:35 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> Register the TS-7300 FPGA manager device drivers which allows us to load
>> bitstreams into the on-board Altera Cyclone II FPGA.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm/mach-ep93xx/ts72xx.c | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
>> index 3b39ea353d30..acf72ea670ef 100644
>> --- a/arch/arm/mach-ep93xx/ts72xx.c
>> +++ b/arch/arm/mach-ep93xx/ts72xx.c
>> @@ -230,6 +230,28 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data = {
>> .phy_id = 1,
>> };
>>
>> +#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
>> +
>> +/* Relative to EP93XX_CS1_PHYS_BASE */
>> +#define TS73XX_FPGA_LOADER_BASE 0x03c00000
>> +
>> +static struct resource ts73xx_fpga_resources[] = {
>> + {
>> + .start = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE,
>> + .end = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE + 1,
>> + .flags = IORESOURCE_MEM,
>> + },
>> +};
>> +
>> +static struct platform_device ts73xx_fpga_device = {
>> + .name = "ts73xx-fpga-mgr",
>> + .id = -1,
>> + .resource = ts73xx_fpga_resources,
>> + .num_resources = ARRAY_SIZE(ts73xx_fpga_resources),
>> +};
>> +
>> +#endif
>> +
>> static void __init ts72xx_init_machine(void)
>> {
>> ep93xx_init_devices();
>> @@ -238,6 +260,10 @@ static void __init ts72xx_init_machine(void)
>> platform_device_register(&ts72xx_wdt_device);
>>
>> ep93xx_register_eth(&ts72xx_eth_data, 1);
>> +#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
>> + if (board_is_ts7300())
>> + platform_device_register(&ts73xx_fpga_device);
>> +#endif
>> }
>>
>> MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC")
>> --
>> 2.9.3
>>
>
> I think this is backwards, shouldn't this be your [PATCH 2/2]?
> Otherwise you're using
> the driver before you added it.
I can definitively re-order the patches, although I don't think this
really makes a difference, a driver without device does nothing, and
vice versa.
--
Florian
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Krzysztof Kozlowski @ 2016-12-14 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26ffeee4-ff43-b3d3-3267-5fcbc50e2974@osg.samsung.com>
On Tue, Dec 13, 2016 at 04:18:05PM -0300, Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> > cooling maps to account for new OPPs.
> >
> > Since new OPPs are not available on all Exynos5422/5800 boards modify
> > dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> > Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >
> > Tested on Odroid-XU3 and XU3 Lite.
> >
> > Cc: Doug Anderson <dianders@chromium.org>
> > Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> > Cc: Andreas Faerber <afaerber@suse.de>
> > Cc: Thomas Abraham <thomas.ab@samsung.com>
> > Cc: Ben Gamari <ben@smart-cactus.org>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > ---
> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> > arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> > arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> > arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> > 4 files changed, 43 insertions(+), 7 deletions(-)
> >
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> > @@ -118,7 +118,7 @@
> > /*
> > * When reaching cpu_alert3, reduce CPU
> > * by 2 steps. On Exynos5422/5800 that would
> > - * be: 1600 MHz and 1100 MHz.
> > + * (usually) be: 1800 MHz and 1200 MHz.
> > */
> > map3 {
> > trip = <&cpu_alert3>;
> > @@ -131,16 +131,16 @@
> >
> > /*
> > * When reaching cpu_alert4, reduce CPU
> > - * further, down to 600 MHz (11 steps for big,
> > - * 7 steps for LITTLE).
> > + * further, down to 600 MHz (13 steps for big,
> > + * 8 steps for LITTLE).
> > */
> > - map5 {
> > + cooling_map5: map5 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu0 3 7>;
> > + cooling-device = <&cpu0 3 8>;
> > };
> > - map6 {
> > + cooling_map6: map6 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu4 3 11>;
> > + cooling-device = <&cpu4 3 13>;
> > };
> > };
> > };
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> > @@ -21,6 +21,23 @@
> > compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> > };
> >
> > +&cluster_a15_opp_table {
> > + /delete-node/opp at 2000000000;
> > + /delete-node/opp at 1900000000;
> > +};
> > +
> > +&cluster_a7_opp_table {
> > + /delete-node/opp at 1400000000;
> > +};
> > +
>
> I think that a comment in the DTS why these operating points aren't available
> in this board will make more clear why the nodes are being deleted.
>
> > +&cooling_map5 {
> > + cooling-device = <&cpu0 3 7>;
> > +};
> > +
> > +&cooling_map6 {
> > + cooling-device = <&cpu4 3 11>;
> > +};
> > +
> > &pwm {
> > /*
> > * PWM 0 -- fan
> > Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > @@ -146,6 +146,10 @@
> > vdd-supply = <&ldo9_reg>;
> > };
> >
> > +&cluster_a7_opp_table {
> > + /delete-property/opp at 1400000000;
> > +};
> > +
> > &cpu0 {
> > cpu-supply = <&buck2_reg>;
> > };
> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > @@ -24,6 +24,16 @@
> > };
> >
> > &cluster_a15_opp_table {
> > + opp at 2000000000 {
> > + opp-hz = /bits/ 64 <2000000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > + opp at 1900000000 {
> > + opp-hz = /bits/ 64 <1900000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > opp at 1700000000 {
> > opp-microvolt = <1250000>;
> > };
> > @@ -85,6 +95,11 @@
> > };
> >
>
> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> INT rail would need to be scaled up as well since there's a maximum voltage
> difference between the ARM and INT rails before the system becomes unstable:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> https://lkml.org/lkml/2014/5/2/419
The choice of skipping > 1.8 GHz could be also made because of missing
ASV which is important to detect the BIN2 of Exynos5422. The BIN2 is
capped to 1.8/1.3.
Anyway this shouldn't be limiting us now because we have all data
statically coded in DTS - in mainline boards, only Odroid XU3-lite
uses BIN2.
Beside comments from Javier, I would be happy to see high frequencies
Tested-by on Peach Pi/Pit. AFAIR, we did not have these in SRPOL. :)
Best regards,
Krzysztof
^ permalink raw reply
* Linux crashes when trying to online secondary core
From: Mason @ 2016-12-14 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1612141807410.3556@nanos>
On 14/12/2016 18:08, Thomas Gleixner wrote:
> On Wed, 14 Dec 2016, Mason wrote:
>
>> I'm seeing Linux v4.9 crash (dereferencing NULL) when I try to online
>> the secondary core, after putting it offline.
>
> Does the patch below fix the issue?
>
> Thanks,
>
> tglx
>
> 8<---------------
>
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index 22acee76cf4c..2594c287b078 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -101,7 +101,6 @@ enum cpuhp_state {
> CPUHP_AP_ARM_L2X0_STARTING,
> CPUHP_AP_ARM_ARCH_TIMER_STARTING,
> CPUHP_AP_ARM_GLOBAL_TIMER_STARTING,
> - CPUHP_AP_DUMMY_TIMER_STARTING,
> CPUHP_AP_JCORE_TIMER_STARTING,
> CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
> CPUHP_AP_ARM_TWD_STARTING,
> @@ -111,6 +110,7 @@ enum cpuhp_state {
> CPUHP_AP_MARCO_TIMER_STARTING,
> CPUHP_AP_MIPS_GIC_TIMER_STARTING,
> CPUHP_AP_ARC_TIMER_STARTING,
> + CPUHP_AP_DUMMY_TIMER_STARTING,
> CPUHP_AP_KVM_STARTING,
> CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING,
> CPUHP_AP_KVM_ARM_VGIC_STARTING,
$ patch -p1 < tglx.patch
patching file include/linux/cpuhotplug.h
Hunk #1 succeeded at 80 (offset -21 lines).
Hunk #2 succeeded@89 (offset -21 lines).
It does seem to fix the problem:
# echo 0 > /sys/devices/system/cpu/cpu1/online
SMC called with a0=0x00[000001 a1=0x00000121 a2=0x00000005 a3 =0xc01189b4 0x00000121
[1][flow/suspend3.c:39] CPU 1 die: jumping6 to. post-boot WFE
402826] CPU1: shutdown
SMC called with a0=0x00000001 a1=0x00000122 a2=0x00000000 a3=0x00000000 0x00000122
[0][flow/suspend.c:82] Killing core1
armor+++ armor: core 1 booted, entering wfe...
# echo 1 > /sys/devices/system/cpu/cpu1/online
[ 215.692700] tango_boot_secondary from __cpu_up
SMC called with a0=0x80101500 a1=0x00000105 a2=0x00000000 a3=0x00000000 0x00000105
[ 215.704494] tango_set_aux_boot_addr=0
SMC called with a0=0x00000001 a1=0x00000104 a2=0x00000000 a3=0x00000000 0x00000104
[0][flow/smc_handler.c:127] waking up CPU1
[ 215.719308] tango_start_aux_core=0
I reverted your patch, and the kernel blows up again.
So what's the problem, and how does your patch solve it?
Regards.
^ permalink raw reply
* [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot
From: Mark Brown @ 2016-12-14 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66vggNNfFrAiNKKGXY0ayiG1qh5tcRok2NLTRkVHWKFeg@mail.gmail.com>
On Wed, Dec 14, 2016 at 09:52:31PM +0800, Chen-Yu Tsai wrote:
> What this patch does is make sure the registers match, to guarantee
> access, and then reinitialize the regmap cache to get rid of any
> stale data.
So what you're saying is that previous writes may have been ignored?
> > If the chip has been reset then you'd want to reset the cache too. I've
> > no idea if that's needed here or not though, it depends what happens to
> > the global state of the chip when this reconfiguration happens.
> It is not a reset in the general sense. I suppose a better way would
> be to do an explicit write to the register first, then initialize
> the regmap. I'd have to export the write function from the RSB bus
> driver first though.
Surely just doing a write immediately after initializing the regmap
would have the same effect? That'd ensure that the hardware has the
desired value before there are any other writes. But I might be missing
something here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/082576db/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4861151.PfdUkXTZox@amdc3058>
Hello Bartlomiej,
On 12/14/2016 01:10 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>>
>> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> Hi,
>>>
>>> On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>>>>
>>>> Hello Bartlomiej,
>>>>
>>>> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>
>>>>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>>>>>> Hello Bartlomiej,
>>>>>
>>>>> Hi,
>>>>>
>>>>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>>>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>>>>>> cooling maps to account for new OPPs.
>>>>>>>
>>>>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>>>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>>>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>>>>>
>>>>>>> Tested on Odroid-XU3 and XU3 Lite.
>>>>>>>
>>>>>>> Cc: Doug Anderson <dianders@chromium.org>
>>>>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>>>>>> Cc: Andreas Faerber <afaerber@suse.de>
>>>>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>>>>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>>>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>>>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>>>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>>>>>
>>>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>>>>>> @@ -118,7 +118,7 @@
>>>>>>> /*
>>>>>>> * When reaching cpu_alert3, reduce CPU
>>>>>>> * by 2 steps. On Exynos5422/5800 that would
>>>>>>> - * be: 1600 MHz and 1100 MHz.
>>>>>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>>>>>> */
>>>>>>> map3 {
>>>>>>> trip = <&cpu_alert3>;
>>>>>>> @@ -131,16 +131,16 @@
>>>>>>>
>>>>>>> /*
>>>>>>> * When reaching cpu_alert4, reduce CPU
>>>>>>> - * further, down to 600 MHz (11 steps for big,
>>>>>>> - * 7 steps for LITTLE).
>>>>>>> + * further, down to 600 MHz (13 steps for big,
>>>>>>> + * 8 steps for LITTLE).
>>>>>>> */
>>>>>>> - map5 {
>>>>>>> + cooling_map5: map5 {
>>>>>>> trip = <&cpu_alert4>;
>>>>>>> - cooling-device = <&cpu0 3 7>;
>>>>>>> + cooling-device = <&cpu0 3 8>;
>>>>>>> };
>>>>>>> - map6 {
>>>>>>> + cooling_map6: map6 {
>>>>>>> trip = <&cpu_alert4>;
>>>>>>> - cooling-device = <&cpu4 3 11>;
>>>>>>> + cooling-device = <&cpu4 3 13>;
>>>>>>> };
>>>>>>> };
>>>>>>> };
>>>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>>>>>> @@ -21,6 +21,23 @@
>>>>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>>>>>> };
>>>>>>>
>>>>>>> +&cluster_a15_opp_table {
>>>>>>> + /delete-node/opp at 2000000000;
>>>>>>> + /delete-node/opp at 1900000000;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cluster_a7_opp_table {
>>>>>>> + /delete-node/opp at 1400000000;
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> I think that a comment in the DTS why these operating points aren't available
>>>>>> in this board will make more clear why the nodes are being deleted.
>>>>>
>>>>> Ok, I will add these comments in the next patch revision.
>>>>>
>>>>>>> +&cooling_map5 {
>>>>>>> + cooling-device = <&cpu0 3 7>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cooling_map6 {
>>>>>>> + cooling-device = <&cpu4 3 11>;
>>>>>>> +};
>>>>>>> +
>>>>>>> &pwm {
>>>>>>> /*
>>>>>>> * PWM 0 -- fan
>>>>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> @@ -146,6 +146,10 @@
>>>>>>> vdd-supply = <&ldo9_reg>;
>>>>>>> };
>>>>>>>
>>>>>>> +&cluster_a7_opp_table {
>>>>>>> + /delete-property/opp at 1400000000;
>>>>>>> +};
>>>>>>> +
>>>>>>> &cpu0 {
>>>>>>> cpu-supply = <&buck2_reg>;
>>>>>>> };
>>>>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> @@ -24,6 +24,16 @@
>>>>>>> };
>>>>>>>
>>>>>>> &cluster_a15_opp_table {
>>>>>>> + opp at 2000000000 {
>>>>>>> + opp-hz = /bits/ 64 <2000000000>;
>>>>>>> + opp-microvolt = <1250000>;
>>>>>>> + clock-latency-ns = <140000>;
>>>>>>> + };
>>>>>>> + opp at 1900000000 {
>>>>>>> + opp-hz = /bits/ 64 <1900000000>;
>>>>>>> + opp-microvolt = <1250000>;
>>>>>>> + clock-latency-ns = <140000>;
>>>>>>> + };
>>>>>>> opp at 1700000000 {
>>>>>>> opp-microvolt = <1250000>;
>>>>>>> };
>>>>>>> @@ -85,6 +95,11 @@
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>>>>>> INT rail would need to be scaled up as well since there's a maximum voltage
>>>>>> difference between the ARM and INT rails before the system becomes unstable:
>>>>>>
>>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>>>>>> https://lkml.org/lkml/2014/5/2/419
>>>>>>
>>>>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>>>>>> the maximum voltage skew is between a limit. But that never made to mainline:
>>>>>>
>>>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>>>>>> https://lkml.org/lkml/2014/4/29/28
>>>>>>
>>>>>> Did that change and there's infrastructure in mainline now to cope with that?
>>>>>> If that's the case, I think it would be good to mention in the commit message.
>>>>>
>>>>> I was not aware of this limitation and AFAIK mainline has currently
>>>>> no code to handle it. I also cannot find any code to handle this in
>>>>
>>>> Yes, that's what I thought as well but maybe I was missing something.
>>>>
>>>>> Hardkernel's vendor kernel for Odroid-XU3 board.
>>>>>
>>>>> Do you know whether this problem exists also on Exynos5422/5800
>>>>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
>>>>> regulator code also on Exynos5800 SoC based Peach Pi board but was
>>>>> the problem actually present on this board?
>>>>>
>>>>
>>>> My understanding is that this problem is present in 5420/5422/5800
>>>> but I have no way to confirm this. I'm just guessing from the info
>>>> in the ChromiumOS vendor tree.
>>>>
>>>> If you look at the commit that added the regulator-locker driver,
>>>> the test says to be done in a Peach Pi so it seems the problem is
>>>> not restricted to only Exynos5420:
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>>>>
>>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>>> (unfortunately Inderpal's email is no longer working). ]
>>>>>
>>>>
>>>> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
>>>
>>> Abhilash's email is also no longer valid.. :(
>>>
>>
>> Yes, I noticed that as well :(
>>
>>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>>> IOW if the problem exists it is already present in the mainline
>>>>> kernel.
>>>>>
>>>>
>>>> Ah, I only looked at your patch and I didn't compare the voltage levels
>>>> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>>>>
>>>> I wonder if the voltage levels in your patch are correct then, since the
>>>> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>>>>
>>>> /*
>>>> * Default ASV table
>>>> */
>>>> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
>>>> 1362500, /* L0 2100 */
>>>> 1312500, /* L1 2000 */
>>>> 1275000, /* L2 1900 */
>>>> 1225000, /* L3 1800 */
>>>> 1200000, /* L4 1700 */
>>>>
>>>> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
>>>
>>> I think that the above voltages are original ones for Exynos5420
>>> (not for Exynos5422/5800).
>>>
>>
>> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
>> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
>
> This seems suboptimal (or maybe even incorrect as Exynos5422/5800
> SoCs also use different clock divider values for clocks related to
> CPU clock than Exynos5420 SoC).
>
Yes, I know. There's lot of if (soc_is_exynos5420()) and if (soc_is_exynos5422())
checks in the driver though so I guess those differences are taken into account.
I haven't reviewed that driver in detail though so maybe something is missing.
> Anyway, I can drop Peach Pi support from my patch for now if you want.
>
I'm not against adding all the missing operating points btw, I'm just trying to
make sure that's safe to do so in mainline.
>>> The voltages in my patch were taken from Hardkernel's kernel for
>>> Odroid-XU3:
>>>
>>> /*
>>> * ASV group voltage table
>>> */
>>> static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
>>> ...
>>> 1250000, /* L4 2000 */
>>> 1250000, /* L5 1900 */
>>> 1250000, /* L6 1800 */
>>> ...
>>>
>>> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
>>>
>>
>> In general I prefer to use the ChromiumOS tree as a reference instead of the
>> HardKernel one, since the former is in a much better shape IMHO.
>
> I generally agree, OTOH Hardkernel's tree is based on Samsung's
> vendor trees and additionally it contains all low-level hardware
> details for Odroid-XU3 board (not present in ChromiumOS tree).
>
Fair enough.
>> I think is worth to check in a kernel tree in http://opensource.samsung.com/
>> for a product that's Exynos5422/5800 based.
>
> I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
> S5 which is Exynos5422 based) and it uses 50mV lower voltages for
> 1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
> identical to the ones used by HardKernel's tree,
>
Interesting, thanks a lot for checking. So if the voltage levels for 1.9 GHz
and 2.0 GHz are the same than 1.8 GHz, then I agree with you that either is
safe to add these OPPs in mainline or the problem is already present there.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 2/2] xilinx_dma: Add reset support
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481735244.git.roliveir@synopsys.com>
Add a DT property to control an optional external reset line
Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
---
drivers/dma/xilinx/xilinx_dma.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 5c9f11b..b845224 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -46,6 +46,7 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/io-64-nonatomic-lo-hi.h>
+#include <linux/reset.h>
#include "../dmaengine.h"
@@ -409,6 +410,7 @@ struct xilinx_dma_device {
struct clk *rxs_clk;
u32 nr_channels;
u32 chan_id;
+ struct reset_control *rst;
};
/* Macros */
@@ -2543,6 +2545,27 @@ static int xilinx_dma_probe(struct platform_device *pdev)
if (IS_ERR(xdev->regs))
return PTR_ERR(xdev->regs);
+ xdev->rst = devm_reset_control_get_optional(&pdev->dev, "reset");
+ if (IS_ERR(xdev->rst)) {
+ err = PTR_ERR(xdev->rst);
+ switch (err) {
+ case -ENOENT:
+ case -ENOTSUPP:
+ xdev->rst = NULL;
+ break;
+ default:
+ dev_err(xdev->dev, "error getting reset %d\n", err);
+ return err;
+ }
+ } else {
+ err = reset_control_deassert(xdev->rst);
+ if (err) {
+ dev_err(xdev->dev, "failed to deassert reset: %d\n",
+ err);
+ return err;
+ }
+ }
+
/* Retrieve the DMA engine properties from the device tree */
xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] xilinx_dma: Edit device tree bindings documentation
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481735244.git.roliveir@synopsys.com>
Add reset property documentation for Xilinx DMA
Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index a2b8bfa..7ebce72 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -40,6 +40,10 @@ Required properties for VDMA:
Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
+- resets : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+ - reset
Optional properties for AXI DMA:
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
Optional properties for VDMA:
@@ -83,6 +87,8 @@ axi_vdma_0: axivdma at 40030000 {
clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>;
clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
"m_axis_mm2s_aclk", "s_axis_s2mm_aclk";
+ resets = <&rst 2>;
+ reset-names = "reset";
dma-channel at 40030000 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
--
2.10.2
^ permalink raw reply related
* [PATCH 0/2] xilinx_dma: Add external reset control
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for controlling an external reset line. Since
this reset line is optional it won't break compatibility.
Ramiro Oliveira (2):
xilinx_dma: Edit device tree bindings documentation
xilinx_dma: Add reset support
.../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++++++
drivers/dma/xilinx/xilinx_dma.c | 23 ++++++++++++++++++++++
2 files changed, 29 insertions(+)
--
2.10.2
^ permalink raw reply
* Linux crashes when trying to online secondary core
From: Thomas Gleixner @ 2016-12-14 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ef972981-3fb6-74a4-cd83-a6629d2dab2a@free.fr>
On Wed, 14 Dec 2016, Mason wrote:
> Hello,
>
> I'm seeing Linux v4.9 crash (dereferencing NULL) when I try to online
> the secondary core, after putting it offline.
Does the patch below fix the issue?
Thanks,
tglx
8<---------------
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 22acee76cf4c..2594c287b078 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -101,7 +101,6 @@ enum cpuhp_state {
CPUHP_AP_ARM_L2X0_STARTING,
CPUHP_AP_ARM_ARCH_TIMER_STARTING,
CPUHP_AP_ARM_GLOBAL_TIMER_STARTING,
- CPUHP_AP_DUMMY_TIMER_STARTING,
CPUHP_AP_JCORE_TIMER_STARTING,
CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
CPUHP_AP_ARM_TWD_STARTING,
@@ -111,6 +110,7 @@ enum cpuhp_state {
CPUHP_AP_MARCO_TIMER_STARTING,
CPUHP_AP_MIPS_GIC_TIMER_STARTING,
CPUHP_AP_ARC_TIMER_STARTING,
+ CPUHP_AP_DUMMY_TIMER_STARTING,
CPUHP_AP_KVM_STARTING,
CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING,
CPUHP_AP_KVM_ARM_VGIC_STARTING,
^ permalink raw reply related
* [PATCH linux v1 0/4] Seven segment display support
From: Greg KH @ 2016-12-14 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac324946-41da-c090-a0ca-78155611bb7e@baylibre.com>
On Wed, Dec 14, 2016 at 02:12:41PM +0100, Neil Armstrong wrote:
> On 12/14/2016 01:56 PM, Greg KH wrote:
> > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
> >> Natarajan wrote:
> >>
> >>> Documentation for the binding which provides an interface for adding clock,
> >>> data and clear signal GPIO lines to control seven segment display.
> >>>
> >>> The platform device driver provides an API for displaying on two 7-segment
> >>> displays, and implements the required bit-banging. The hardware assumed is
> >>> 74HC164 wired to two 7-segment displays.
> >>>
> >>> The character device driver implements the user-space API for letting a user
> >>> write to two 7-segment displays including any conversion methods necessary
> >>> to map the user input to two 7-segment displays.
> >>>
> >>> Adding clock, data and clear signal GPIO lines in the devicetree to control
> >>> seven segment display on zaius platform.
> >>>
> >>> The platform driver matches on the device tree node; the platform driver also
> >>> initializes the character device.
> >>>
> >>> Tested that the seven segment display works properly by writing to the
> >>> character device file on a EVB AST2500 board which also has 74HC164 wired
> >>> to two 7-segment displays.
> >>
> >> FWIW, I proposed a driver for seven segment displays back in 2013:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
> >>
> >> And the feedback from Greg KH was: we don't need a driver for that, do
> >> it from userspace. See:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
> >>
> >> So: good luck :-)
> >
> > Did anyone ever write a library for this type of thing?
> >
> > Again, I don't want to see one-off drivers for random devices like this
> > that should be able to all be controlled from userspace in a common
> > manner. Much like we did for fingerprint readers a long long time
> > ago...
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
> characters a simple and clean driver could achieve.
Great, then let's make an API that all devices of this type could use,
and not just take individual drivers that all have a custom char or
sysfs interface which requires custom userspace code to be able to drive
all of the different devices in a common way (i.e. a library would have
to be written anyways...)
thanks,
greg k-h
^ permalink raw reply
* [PATCH v3 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
From: Hartley Sweeten @ 2016-12-14 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214023553.9377-2-f.fainelli@gmail.com>
On Tuesday, December 13, 2016 7:36 PM, Florian Fainelli wrote:
>
> Register the TS-7300 FPGA manager device drivers which allows us to load
> bitstreams into the on-board Altera Cyclone II FPGA.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/mach-ep93xx/ts72xx.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
For the ep93xx core change:
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [PATCH 2/2] FPGA: Add TS-7300 FPGA manager
From: Hartley Sweeten @ 2016-12-14 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1612120951520.3310@atull-730U3E-740U3E>
On Monday, December 12, 2016 9:02 AM, Alan Tull wrote:
> On Sun, 11 Dec 2016, Florian Fainelli wrote:
>> Add support for loading bitstreams on the Altera Cyclone II FPGA
>> populated on the TS-7300 board. This is done through the configuration
>> and data registers offered through a memory interface between the EP93xx
>> SoC and the FPGA.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Hi Florain,
>
> Thanks for submitting!
>
> How specific is this to the tx7300 board?
>
> I'm unclear about the programming method here. Are these registers
> exposed by the EP93xx? Is it possible that another cpu could access
> these two registers to configure the cyclone ii? Is this passive
> serial?
Alan,
>From the schematic, it appears that the Cyclone II FPGA is configured for
Fast AS programming. The glue chip (MAXII CLPD) on the board appears to
implement some kind of state machine to handle the FPGA programming
using two registers in the glue chip.
Hartley
^ permalink raw reply
* [PATCH 1/1] arm64: Correcting format specifier for printing 64 bit addresses
From: Paolo Bonzini @ 2016-12-14 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206161116.GD4816@cbox>
On 06/12/2016 17:11, Christoffer Dall wrote:
> + kvm_err("Unsupported guest CP%d access at: %08lx\n",
> + cp, *vcpu_pc(vcpu));
> + else
> + kvm_err("Unsupported guest CP%d access at: %016lx\n",
> + cp, *vcpu_pc(vcpu));
>
> It feels a bit much to me to have an if-statement to differentiate the
> number of leading zeros, so if it's important to always have fixed
> widths then I would just use %016lx in both cases.
Really, this is just a debugging message. Just use "0x%lx" and let's
stop bikeshedding. :)
Paolo
^ permalink raw reply
* [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Chen-Yu Tsai @ 2016-12-14 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-5-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This adds the "x-powers,axp223-usb-power-supply" to the list of
> compatibles for AXP20X VBUS power supply driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
>
> v2:
> - adding small explanation on AXP223 variation compared to the AXP221,
>
> Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> index f1d7bee..ba8d35f 100644
> --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> @@ -3,6 +3,11 @@ AXP20x USB power supply
> Required Properties:
> -compatible: One of: "x-powers,axp202-usb-power-supply"
> "x-powers,axp221-usb-power-supply"
> + "x-powers,axp223-usb-power-supply"
> +
> +The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight
> +variations such as the former being able to set the VBUS power supply max
> +current to 100mA, unlike the latter.
I actually wanted this in the commit log, but this works too.
Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> This node is a subnode of the axp20x PMIC.
>
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ee4321d6-dcc9-4de7-c376-6b169d160322@osg.samsung.com>
Hi,
On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
> >>
> >> Hello Bartlomiej,
> >>
> >> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>
> >>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >>>> Hello Bartlomiej,
> >>>
> >>> Hi,
> >>>
> >>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>>>> cooling maps to account for new OPPs.
> >>>>>
> >>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>>>
> >>>>> Tested on Odroid-XU3 and XU3 Lite.
> >>>>>
> >>>>> Cc: Doug Anderson <dianders@chromium.org>
> >>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >>>>> Cc: Andreas Faerber <afaerber@suse.de>
> >>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
> >>>>> Cc: Ben Gamari <ben@smart-cactus.org>
> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>>>
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -118,7 +118,7 @@
> >>>>> /*
> >>>>> * When reaching cpu_alert3, reduce CPU
> >>>>> * by 2 steps. On Exynos5422/5800 that would
> >>>>> - * be: 1600 MHz and 1100 MHz.
> >>>>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>>>> */
> >>>>> map3 {
> >>>>> trip = <&cpu_alert3>;
> >>>>> @@ -131,16 +131,16 @@
> >>>>>
> >>>>> /*
> >>>>> * When reaching cpu_alert4, reduce CPU
> >>>>> - * further, down to 600 MHz (11 steps for big,
> >>>>> - * 7 steps for LITTLE).
> >>>>> + * further, down to 600 MHz (13 steps for big,
> >>>>> + * 8 steps for LITTLE).
> >>>>> */
> >>>>> - map5 {
> >>>>> + cooling_map5: map5 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu0 3 7>;
> >>>>> + cooling-device = <&cpu0 3 8>;
> >>>>> };
> >>>>> - map6 {
> >>>>> + cooling_map6: map6 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu4 3 11>;
> >>>>> + cooling-device = <&cpu4 3 13>;
> >>>>> };
> >>>>> };
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -21,6 +21,23 @@
> >>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>>>> };
> >>>>>
> >>>>> +&cluster_a15_opp_table {
> >>>>> + /delete-node/opp at 2000000000;
> >>>>> + /delete-node/opp at 1900000000;
> >>>>> +};
> >>>>> +
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-node/opp at 1400000000;
> >>>>> +};
> >>>>> +
> >>>>
> >>>> I think that a comment in the DTS why these operating points aren't available
> >>>> in this board will make more clear why the nodes are being deleted.
> >>>
> >>> Ok, I will add these comments in the next patch revision.
> >>>
> >>>>> +&cooling_map5 {
> >>>>> + cooling-device = <&cpu0 3 7>;
> >>>>> +};
> >>>>> +
> >>>>> +&cooling_map6 {
> >>>>> + cooling-device = <&cpu4 3 11>;
> >>>>> +};
> >>>>> +
> >>>>> &pwm {
> >>>>> /*
> >>>>> * PWM 0 -- fan
> >>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -146,6 +146,10 @@
> >>>>> vdd-supply = <&ldo9_reg>;
> >>>>> };
> >>>>>
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-property/opp at 1400000000;
> >>>>> +};
> >>>>> +
> >>>>> &cpu0 {
> >>>>> cpu-supply = <&buck2_reg>;
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -24,6 +24,16 @@
> >>>>> };
> >>>>>
> >>>>> &cluster_a15_opp_table {
> >>>>> + opp at 2000000000 {
> >>>>> + opp-hz = /bits/ 64 <2000000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> + opp at 1900000000 {
> >>>>> + opp-hz = /bits/ 64 <1900000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> opp at 1700000000 {
> >>>>> opp-microvolt = <1250000>;
> >>>>> };
> >>>>> @@ -85,6 +95,11 @@
> >>>>> };
> >>>>>
> >>>>
> >>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >>>> INT rail would need to be scaled up as well since there's a maximum voltage
> >>>> difference between the ARM and INT rails before the system becomes unstable:
> >>>>
> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >>>> https://lkml.org/lkml/2014/5/2/419
> >>>>
> >>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >>>> the maximum voltage skew is between a limit. But that never made to mainline:
> >>>>
> >>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >>>> https://lkml.org/lkml/2014/4/29/28
> >>>>
> >>>> Did that change and there's infrastructure in mainline now to cope with that?
> >>>> If that's the case, I think it would be good to mention in the commit message.
> >>>
> >>> I was not aware of this limitation and AFAIK mainline has currently
> >>> no code to handle it. I also cannot find any code to handle this in
> >>
> >> Yes, that's what I thought as well but maybe I was missing something.
> >>
> >>> Hardkernel's vendor kernel for Odroid-XU3 board.
> >>>
> >>> Do you know whether this problem exists also on Exynos5422/5800
> >>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> >>> regulator code also on Exynos5800 SoC based Peach Pi board but was
> >>> the problem actually present on this board?
> >>>
> >>
> >> My understanding is that this problem is present in 5420/5422/5800
> >> but I have no way to confirm this. I'm just guessing from the info
> >> in the ChromiumOS vendor tree.
> >>
> >> If you look at the commit that added the regulator-locker driver,
> >> the test says to be done in a Peach Pi so it seems the problem is
> >> not restricted to only Exynos5420:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> >>
> >>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> >>> (unfortunately Inderpal's email is no longer working). ]
> >>>
> >>
> >> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> >
> > Abhilash's email is also no longer valid.. :(
> >
>
> Yes, I noticed that as well :(
>
> >>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> >>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> >>> IOW if the problem exists it is already present in the mainline
> >>> kernel.
> >>>
> >>
> >> Ah, I only looked at your patch and I didn't compare the voltage levels
> >> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
> >>
> >> I wonder if the voltage levels in your patch are correct then, since the
> >> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
> >>
> >> /*
> >> * Default ASV table
> >> */
> >> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> >> 1362500, /* L0 2100 */
> >> 1312500, /* L1 2000 */
> >> 1275000, /* L2 1900 */
> >> 1225000, /* L3 1800 */
> >> 1200000, /* L4 1700 */
> >>
> >> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> >
> > I think that the above voltages are original ones for Exynos5420
> > (not for Exynos5422/5800).
> >
>
> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
This seems suboptimal (or maybe even incorrect as Exynos5422/5800
SoCs also use different clock divider values for clocks related to
CPU clock than Exynos5420 SoC).
Anyway, I can drop Peach Pi support from my patch for now if you want.
> > The voltages in my patch were taken from Hardkernel's kernel for
> > Odroid-XU3:
> >
> > /*
> > * ASV group voltage table
> > */
> > static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> > ...
> > 1250000, /* L4 2000 */
> > 1250000, /* L5 1900 */
> > 1250000, /* L6 1800 */
> > ...
> >
> > https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
> >
>
> In general I prefer to use the ChromiumOS tree as a reference instead of the
> HardKernel one, since the former is in a much better shape IMHO.
I generally agree, OTOH Hardkernel's tree is based on Samsung's
vendor trees and additionally it contains all low-level hardware
details for Odroid-XU3 board (not present in ChromiumOS tree).
> I think is worth to check in a kernel tree in http://opensource.samsung.com/
> for a product that's Exynos5422/5800 based.
I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
S5 which is Exynos5422 based) and it uses 50mV lower voltages for
1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
identical to the ones used by HardKernel's tree,
drivers/cpufreq/exynos5422-eagle-cpufreq.c:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1200000, /* L4 2000 */
1200000, /* L5 1900 */
1200000, /* L6 1800 */
1200000, /* L7 1700 */
1200000, /* L8 1600 */
1100000, /* L9 1500 */
1100000, /* L10 1400 */
1100000, /* L11 1300 */
1000000, /* L12 1200 */
1000000, /* L13 1100 */
1000000, /* L14 1000 */
1000000, /* L15 900 */
900000, /* L16 800 */
900000, /* L17 700 */
900000, /* L18 600 */
900000, /* L19 500 */
900000, /* L20 400 */
900000, /* L22 300 */
900000, /* L22 200 */
};
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Tony Lindgren @ 2016-12-14 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214155208.ocs4vw77expduefr@earth>
* Sebastian Reichel <sre@kernel.org> [161214 07:52]:
> On Wed, Dec 14, 2016 at 07:10:56AM -0800, Tony Lindgren wrote:
> > Maybe send it so we can merge it as a fix during the early -rc
> > cycle?
>
> Sorry if I was not clear enough: mainline does *not* contain
> incorrect DT information. My bluetooth RFC patches did. So
> this can go into the kernel once the driver is there and
> the binding got accepted.
Oh OK good to hear.
> Alternatively I can prepare a patch, which just adds the
> cts/rts pinmux for the bluetooth UART, but it's not very
> useful on its own.
OK sounds like no rush until other pieces are ready.
Regards,
Tony
^ permalink raw reply
* Linux crashes when trying to online secondary core
From: Mason @ 2016-12-14 16:01 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I'm seeing Linux v4.9 crash (dereferencing NULL) when I try to online
the secondary core, after putting it offline.
Perhaps commit 00c1d17aab513d3b8117fb84644eba39434b33e4 is relevant?
You will find below:
1) the full boot log
2) the defconfig I used
Note #1: I added the following patch for debugging purpose:
diff --git a/arch/arm/mach-tango/platsmp.c b/arch/arm/mach-tango/platsmp.c
index 98c62a4a8623..c6865935f21b 100644
--- a/arch/arm/mach-tango/platsmp.c
+++ b/arch/arm/mach-tango/platsmp.c
@@ -5,8 +5,14 @@
static int tango_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
+ int ret;
+ printk("%s from %pf\n", __func__, __builtin_return_address(0));
+ ret =
tango_set_aux_boot_addr(virt_to_phys(secondary_startup));
+ printk("tango_set_aux_boot_addr=%d\n", ret);
+ ret =
tango_start_aux_core(cpu);
+ printk("tango_start_aux_core=%d\n", ret);
return 0;
}
Note #2: Linux runs as untrusted OS (trustzone thing). Trusted OS
is called armor. Sometimes armor and Linux print to the console
at the same time, which explains some hard-to-read output.
## Booting kernel from Legacy Image at 84001000 ...
Image Name: Linux-4.9.0
Created: 2016-12-14 14:31:44 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6903791 Bytes = 6.6 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
SMC called with a0=0x00000000 a1=0x00000000 a2=0x00000000 a3=0x20100000 0x00000102
SMC called with a0=0x00000000 a1=0x00000000 a2=0x00000000 a3=0x00000064 0x00000102
SMC called with a0=0x00000001 a1=0x00000102 a2=0xd0804730 a3=0xc0119380 0x00000102
SMC called with a0=0x80101500 a1=0x00000105 a2=0x00000000 a3=0x00000000 0x00000105
SMC called with a0=0x00000001 a1=0x00000104 a2=0x00000000 a3=0x00000000 0x00000104
[0][flow/smc_handler.c:127] waking up CPU1
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.0 (me at misti.france.sdesigns.com) (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #143 SMP PREEMPT Wed Dec 14 15:31:39 CET 2016
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt:Machine model: Sigma Designs SMP8758 Vantage-1172 Rev E1
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] On node 0 totalpages: 65536
[ 0.000000] free_area_init_node: node 0, pgdat c0b20f00, node_mem_map cfdf9000
[ 0.000000] Normal zone: 512 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 65536 pages, LIFO batch:15
[ 0.000000] percpu: Embedded 14 pages/cpu @cfdd6000 s25728 r8192 d23424 u57344
[ 0.000000] pcpu-alloc: s25728 r8192 d23424 u57344 alloc=14*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
[ 0.000000] Kernel command line: console=ttyS0,115200 mem=256M debug no_console_suspend
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Memory: 249108K/262144K available (4096K kernel code, 134K rwdata, 872K rodata, 5120K init, 231K bss, 13036K reserved, 0K cma-reserved, 0K highmem)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xd0800000 - 0xff800000 ( 752 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0500000 (5088 kB)
[ 0.000000] .init : 0xc0600000 - 0xc0b00000 (5120 kB)
[ 0.000000] .data : 0xc0b00000 - 0xc0b21800 ( 134 kB)
[ 0.000000] .bss : 0xc0b21800 - 0xc0b5b680 ( 232 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Build-time adjustment of leaf fanout to 32.
[ 0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 4 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x72860401
[ 0.000000] clocksource: tango-xtal: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 70787423951 ns
[ 0.000004] sched_clock: 32 bits at 27MHz, resolution 37ns, wraps every 79536431085ns
[ 0.000012] Switching to timer-based delay loop, resolution 37ns
[ 0.000256] Console: colour dummy device 80x30
[ 0.000278] Calibrating delay loop (skipped), value calculated using timer frequency.. 54.25 BogoMIPS (lpj=90000)
[ 0.000289] pid_max: default: 32768 minimum: 301
[ 0.000393] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000400] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000896] CPU: Testing write buffer coherency: ok
[ 0.001133] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.001178] Setting up static identity map for 0x80100000 - 0x80100058
[ 0.056732] tango_boot_secondary from __cpu_up
[ 0.063938] tango_set_aux_boot_addr=0
[ 0.075101] tango_start_aux_core=0
[ 0.075229] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.075319] Brought up 2 CPUs
[ 0.075330] SMP: Total of 2 processors activated (108.50 BogoMIPS).
[ 0.075337] CPU: All CPU(s) started in SVC mode.
[ 0.075951] devtmpfs: initialized
[ 0.077370] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.077819] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns
[ 0.078226] NET: Registered protocol family 16
[ 0.078999] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.080104] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[ 0.080116] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.094156] SCSI subsystem initialized
[ 0.094678] usbcore: registered new interface driver usbfs
[ 0.094788] usbcore: registered new interface driver hub
[ 0.094887] usbcore: registered new device driver usb
[ 0.096948] clocksource: Switched to clocksource tango-xtal
[ 0.110399] NET: Registered protocol family 2
[ 0.110923] TCP established hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.110949] TCP bind hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.110977] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.111051] UDP hash table entries: 256 (order: 1, 8192 bytes)
[ 0.111082] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[ 0.111239] NET: Registered protocol family 1
[ 0.111623] RPC: Registered named UNIX socket transport module.
[ 0.111631] RPC: Registered udp transport module.
[ 0.111636] RPC: Registered tcp transport module.
[ 0.111641] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.310427] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
[ 0.311930] futex hash table entries: 512 (order: 3, 32768 bytes)
[ 0.312759] workingset: timestamp_bits=30 max_order=16 bucket_order=0
[ 0.313862] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 0.313883] io scheduler noop registered
[ 0.313891] io scheduler deadline registered
[ 0.313920] io scheduler cfq registered (default)
[ 0.315331] tangox-dma 290a0.dma: SMP86xx DMA with 2 channels, 1 slaves
[ 0.397789] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
[ 0.399218] console [ttyS0] disabled
[ 0.399291] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[ 0.961466] console [ttyS0] enabled
[ 0.972296] loop: module loaded
[ 0.976476] libphy: Fixed MDIO Bus: probed
[ 0.990487] libphy: nb8800-mii: probed
[ 0.999534] nb8800 26000.ethernet eth0: MAC address 00:16:e8:43:2f:80
[ 1.006218] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.012991] usbcore: registered new interface driver usb-storage
[ 1.072811] ci_hdrc ci_hdrc.0: doesn't support gadget
[ 1.077917] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 1.082851] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[ 1.100296] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[ 1.106586] hub 1-0:1.0: USB hub found
[ 1.110424] hub 1-0:1.0: 1 port detected
[ 1.169474] ci_hdrc ci_hdrc.1: doesn't support gadget
[ 1.174577] ci_hdrc ci_hdrc.1: EHCI Host Controller
[ 1.179510] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
[ 1.196962] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
[ 1.203147] hub 2-0:1.0: USB hub found
[ 1.206980] hub 2-0:1.0: 1 port detected
[ 1.212967] tangox-wdt 1fd00.watchdog: SMP86xx/SMP87xx watchdog registered
[ 1.221059] sdhci: Secure Digital Host Controller Interface driver
[ 1.227316] sdhci: Copyright(c) Pierre Ossman
[ 1.231703] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.237845] usbcore: registered new interface driver usbhid
[ 1.243463] usbhid: USB HID core driver
[ 1.247645] NET: Registered protocol family 17
[ 1.252201] Registering SWP/SWPB emulation handler
[ 1.266305] Freeing unused kernel memory: 5120K (c0600000 - c0b00000)
Starting logging: OK
Initializing random number generator... [ 1.359367] random: dd: uninitialized urandom read (512 bytes read)
done.
Starting network: OK
Starting telnetd: OK
Welcome to Buildroot
buildroot login: root
#
# echo 0 > /sys/devices/system/cpu/cpu1/online
SMC called with a0=[0x00000001 a1=0x00000 121 a2=0x000 00005 a3 =0xc01193b4 70x000000121
[1][flow/suspend.c:39]. CPU 1 die:3 jumping to post-boot WFE4
4187] CPU1: shutdown
SMC called with a0=0x00000001 a1=0x00000122 a2=0x00000000 a3=0x00000000 0x00000122
[0][flow/suspend.c:82] Killing core1
armor+++ armor: core 1 booted, entering wfe...
#
# echo 1 > /sys/devices/system/cpu/cpu1/online
[ 86.924294] tango_boot_secondary from __cpu_up
SMC called with a0=0x80101500 a1=0x00000105 a2=0x00000000 a3=0x00000000 0x00000105
[ 86.936275] tango_set_aux_boot_addr=0
SMC called with a0=0x00000001 a1=0x00000104 a2=0x00000000 a3=0x00000000 0x00000104
[0][flow/smc_handler.c:127] waking up CPU1
[ 86.9[ 8516.92512662]2] U Unnaabbllee tto ho ahnandledle kerkernenell NULL pointer dereference at virtual address 00000000
[ 86.951266] pgd = c0004000
[ 86.951271] [00000000] *pgd=00000000
[ 86.951280] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 86.951285] Modules linked in:
[ 86.951292] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.0 #143
[ 86.951294] Hardware name: Sigma Tango DT
[ 86.951297] task: cf85b140 task.stack: cf85e000
[ 86.951312] PC is at tick_broadcast_setup_oneshot+0x18/0x134
[ 86.951319] LR is at debug_smp_processor_id+0x20/0x24
[ 86.951324] pc : [<c0187394>] lr : [<c030f0a4>] psr: 200001d3
[ 86.951324] sp : cf85fe90 ip : cf85fe80 fp : cf85fecc
[ 86.951326] r10: 00000000 r9 : c05016d4 r8 : 400001d3
[ 86.951329] r7 : 00000000 r6 : cfde8f80 r5 : 00000000 r4 : 00000001
[ 86.951331] r3 : cf85e000 r2 : 00000002 r1 : c057d620 r0 : 00000001
[ 86.951335] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
[ 86.951338] Control: 10c5387d Table: 8000404a DAC: 00000051
[ 86.951340] Process swapper/1 (pid: 0, stack limit = 0xcf85e210)
[ 86.951344] Stack: (0xcf85fe90 to 0xcf860000)
[ 86.951348] fe80: cf85fedc cf85fea0 c0b482dc 400001d3
[ 86.951354] fea0: cfde8f80 00000001 00000001 cfde8f80 00000000 400001d3 c05016d4 00000000
[ 86.951359] fec0: cf85fef4 cf85fed0 c01875f4 c0187388 cfde8f80 cfde78f0 00000001 00000000
[ 86.951364] fee0: 00000001 c05016d4 cf85ff2c cf85fef8 c0186318 c01874bc cf85ff14 cf85ff08
[ 86.951369] ff00: c0b0c150 cfde78f0 cfde8f80 00000001 00000000 a00001d3 00000001 00000000
[ 86.951374] ff20: cf85ff4c cf85ff30 c0186544 c01862bc c0b0c150 c0b0c150 c0b0c168 cfde8f80
[ 86.951379] ff40: cf85ff74 cf85ff50 c01852ec c018648c cfde4244 00000060 c0b07cf8 00000001
[ 86.951385] ff60: 0f3a5000 00000001 cf85ff84 cf85ff78 c03fcf10 c0185294 cf85ffb4 cf85ff88
[ 86.951390] ff80: c011c588 c03fceb4 00000000 cfde4244 00000060 00000001 c0a3f244 0f3a5000
[ 86.951395] ffa0: 413fc090 00000000 cf85ffdc cf85ffb8 c011e10c c011c53c c0b0d198 00000001
[ 86.951400] ffc0: 10c0387d c0b21ae8 8000406a 413fc090 cf85fff4 cf85ffe0 c010dd6c c011e0bc
[ 86.951405] ffe0: 8f84006a 00000051 00000000 cf85fff8 8010158c c010dc88 8f34eea9 0607fa8b
[ 86.951408] Backtrace:
[ 86.951417] [<c018737c>] (tick_broadcast_setup_oneshot) from [<c01875f4>] (tick_device_uses_broadcast+0x144/0x1a8)
[ 86.951423] r10:00000000 r9:c05016d4 r8:400001d3 r7:00000000 r6:cfde8f80 r5:00000001
[ 86.951425] r4:00000001
[ 86.951431] [<c01874b0>] (tick_device_uses_broadcast) from [<c0186318>] (tick_setup_device+0x68/0x110)
[ 86.951437] r9:c05016d4 r8:00000001 r7:00000000 r6:00000001 r5:cfde78f0 r4:cfde8f80
[ 86.951443] [<c01862b0>] (tick_setup_device) from [<c0186544>] (tick_check_new_device+0xc4/0xe8)
[ 86.951448] r10:00000000 r9:00000001 r8:a00001d3 r7:00000000 r6:00000001 r5:cfde8f80
[ 86.951450] r4:cfde78f0
[ 86.951457] [<c0186480>] (tick_check_new_device) from [<c01852ec>] (clockevents_register_device+0x64/0x11c)
[ 86.951461] r7:cfde8f80 r6:c0b0c168 r5:c0b0c150 r4:c0b0c150
[ 86.951472] [<c0185288>] (clockevents_register_device) from [<c03fcf10>] (dummy_timer_starting_cpu+0x68/0x70)
[ 86.951478] r9:00000001 r8:0f3a5000 r7:00000001 r6:c0b07cf8 r5:00000060 r4:cfde4244
[ 86.951490] [<c03fcea8>] (dummy_timer_starting_cpu) from [<c011c588>] (cpuhp_invoke_callback+0x58/0x120)
[ 86.951497] [<c011c530>] (cpuhp_invoke_callback) from [<c011e10c>] (notify_cpu_starting+0x5c/0x6c)
[ 86.951503] r10:00000000 r9:413fc090 r8:0f3a5000 r7:c0a3f244 r6:00000001 r5:00000060
[ 86.951505] r4:cfde4244 r3:00000000
[ 86.951511] [<c011e0b0>] (notify_cpu_starting) from [<c010dd6c>] (secondary_start_kernel+0xf0/0x164)
[ 86.951516] r9:413fc090 r8:8000406a r7:c0b21ae8 r6:10c0387d r5:00000001 r4:c0b0d198
[ 86.951524] [<c010dc7c>] (secondary_start_kernel) from [<8010158c>] (0x8010158c)
[ 86.951526] r5:00000051 r4:8f84006a
[ 86.951532] Code: e24cb004 e24dd014 e1a05000 eb061f3b (e5952000)
[ 86.951537] ---[ end trace b9e15a7104bf60a3 ]---
[ 86.951543] Kernel panic - not syncing: Attempted to kill the idle task!
[ 86.962632] CPU0: stopping
[ 86.962638] CPU: 0 PID: 928 Comm: sh Tainted: G D 4.9.0 #143
[ 86.962640] Hardware name: Sigma Tango DT
[ 86.962643] Backtrace:
[ 86.962659] [<c010b9c4>] (dump_backtrace) from [<c010bc80>] (show_stack+0x18/0x1c)
[ 86.962664] r7:60000193 r6:c0b10914 r5:00000000 r4:c0b10914
[ 86.962674] [<c010bc68>] (show_stack) from [<c02f574c>] (dump_stack+0x80/0x94)
[ 86.962680] [<c02f56cc>] (dump_stack) from [<c010e1f4>] (handle_IPI+0x1a0/0x1b4)
[ 86.962685] r7:00000000 r6:00000004 r5:00000000 r4:c0a42ec4
[ 86.962690] [<c010e054>] (handle_IPI) from [<c01014ec>] (gic_handle_irq+0x90/0x94)
[ 86.962695] r9:d0803100 r8:d0802100 r7:cfbb7bb8 r6:d080210c r5:c0b03348 r4:c0b10b70
[ 86.962700] [<c010145c>] (gic_handle_irq) from [<c010c7cc>] (__irq_svc+0x6c/0xa8)
[ 86.962703] Exception stack(0xcfbb7bb8 to 0xcfbb7c00)
[ 86.962706] 7ba0: 00000000 60000093
[ 86.962711] 7bc0: 00000000 60000013 c0b26880 c0b43ca0 00000000 00000026 00000000 00000073
[ 86.962717] 7be0: 00002248 cfbb7c74 cfbb7b40 cfbb7c08 c04dc3d0 c0163780 60000013 ffffffff
[ 86.962722] r9:cfbb6000 r8:00000000 r7:cfbb7bec r6:ffffffff r5:60000013 r4:c0163780
[ 86.962732] [<c0163490>] (console_unlock) from [<c0163d40>] (vprintk_emit+0x2ac/0x4a8)
[ 86.962738] r10:00000000 r9:c0b23d20 r8:c0b0b03c r7:00000004 r6:00000002 r5:00000000
[ 86.962740] r4:00000016
[ 86.962746] [<c0163a94>] (vprintk_emit) from [<c01640dc>] (vprintk_default+0x28/0x30)
[ 86.962751] r10:00000000 r9:00000001 r8:c0b21ae8 r7:cf85b140 r6:c05a7a54 r5:c01640b4
[ 86.962753] r4:cfbb7d14
[ 86.962764] [<c01640b4>] (vprintk_default) from [<c01a7df8>] (printk+0x74/0x7c)
[ 86.962772] [<c01a7d88>] (printk) from [<c011949c>] (tango_boot_secondary+0x68/0x70)
[ 86.962776] r3:60000500 r2:00000003 r1:00000000 r0:c057376c
[ 86.962779] r5:00000001 r4:00000001
[ 86.962784] [<c0119434>] (tango_boot_secondary) from [<c010d9bc>] (__cpu_up+0xb0/0x144)
[ 86.962787] r5:00000001 r4:c0b21af8
[ 86.962792] [<c010d90c>] (__cpu_up) from [<c011d128>] (bringup_cpu+0x28/0xa8)
[ 86.962797] r9:00000001 r8:00000030 r7:00000001 r6:c0b086a8 r5:00000001 r4:cf85b140
[ 86.962804] [<c011d100>] (bringup_cpu) from [<c011c588>] (cpuhp_invoke_callback+0x58/0x120)
[ 86.962806] r5:00000001 r4:cfde4244
[ 86.962813] [<c011c530>] (cpuhp_invoke_callback) from [<c011c784>] (cpuhp_up_callbacks+0x2c/0xdc)
[ 86.962819] r10:00000000 r9:cfde4244 r8:00000030 r7:00000000 r6:00000000 r5:00000001
[ 86.962821] r4:cfde4244 r3:00000000
[ 86.962827] [<c011c758>] (cpuhp_up_callbacks) from [<c011dd38>] (_cpu_up+0xb0/0x10c)
[ 86.962832] r9:cfde4244 r8:0f3a5000 r7:00000097 r6:00000000 r5:00000001 r4:c0a3f244
[ 86.962837] [<c011dc88>] (_cpu_up) from [<c011de0c>] (do_cpu_up+0x78/0xa0)
[ 86.962842] r9:00000000 r8:00000000 r7:cec32540 r6:cfde4044 r5:00000097 r4:00000001
[ 86.962847] [<c011dd94>] (do_cpu_up) from [<c011de48>] (cpu_up+0x14/0x18)
[ 86.962849] r5:cfde4010 r4:c036154c
[ 86.962862] [<c011de34>] (cpu_up) from [<c0361560>] (cpu_subsys_online+0x14/0x18)
[ 86.962869] [<c036154c>] (cpu_subsys_online) from [<c035cb14>] (device_online+0x6c/0x90)
[ 86.962874] [<c035caa8>] (device_online) from [<c035cba8>] (online_store+0x70/0x7c)
[ 86.962878] r7:cec32540 r6:cfbb7f80 r5:00000002 r4:cfde4010
[ 86.962883] [<c035cb38>] (online_store) from [<c035a3d4>] (dev_attr_store+0x20/0x2c)
[ 86.962886] r5:00000002 r4:c035cb38
[ 86.962894] [<c035a3b4>] (dev_attr_store) from [<c024ac2c>] (sysfs_kf_write+0x48/0x4c)
[ 86.962897] r5:00000002 r4:c035a3b4
[ 86.962903] [<c024abe4>] (sysfs_kf_write) from [<c024a3e8>] (kernfs_fop_write+0xf8/0x1f8)
[ 86.962905] r5:00000002 r4:cf9d2b80
[ 86.962916] [<c024a2f0>] (kernfs_fop_write) from [<c01e3bd4>] (__vfs_write+0x34/0x120)
[ 86.962922] r10:00000000 r9:cfbb6000 r8:c0107d64 r7:00000002 r6:cfbb7f80 r5:c024a2f0
[ 86.962924] r4:cf9cd780
[ 86.962930] [<c01e3ba0>] (__vfs_write) from [<c01e4a68>] (vfs_write+0xac/0x170)
[ 86.962936] r9:cfbb6000 r8:c0107d64 r7:cfbb7f80 r6:00e0a408 r5:cf9cd780 r4:00000002
[ 86.962942] [<c01e49bc>] (vfs_write) from [<c01e5868>] (SyS_write+0x4c/0xa8)
[ 86.962947] r9:cfbb6000 r8:c0107d64 r7:00000002 r6:00e0a408 r5:cf9cd780 r4:cf9cd780
[ 86.962955] [<c01e581c>] (SyS_write) from [<c0107ba0>] (ret_fast_syscall+0x0/0x3c)
[ 86.962959] r7:00000004 r6:b6effd60 r5:00e0a408 r4:00000002
[ 87.718648] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
CONFIG_CROSS_COMPILE="arm-linux-gnueabihf-"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_NO_HZ_IDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_ARCH_TANGO=y
# CONFIG_ARM_ERRATA_643719 is not set
CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_HZ_300=y
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
# CONFIG_COMPACTION is not set
# CONFIG_ATAGS is not set
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_CMDLINE="console=ttyS0,115200 mem=256M"
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPUFREQ_DT=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_IPV6 is not set
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_MTD=y
CONFIG_MTD_TESTS=m
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_TANGO=m
CONFIG_MTD_UBI=m
CONFIG_BLK_DEV_LOOP=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_NETDEVICES=y
CONFIG_NET_VENDOR_AURORA=y
CONFIG_AURORA_NB8800=y
CONFIG_AT803X_PHY=y
# CONFIG_USB_NET_DRIVERS is not set
# CONFIG_WLAN is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=1
CONFIG_SERIAL_8250_RUNTIME_UARTS=1
CONFIG_SERIAL_8250_RT288X=y
CONFIG_SERIAL_OF_PLATFORM=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_XLR=y
CONFIG_GPIOLIB=y
CONFIG_THERMAL=y
CONFIG_CPU_THERMAL=y
CONFIG_TANGO_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_TANGOX_WATCHDOG=y
CONFIG_FB=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_STORAGE=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_OF_ARASAN=y
CONFIG_DMADEVICES=y
CONFIG_TANGO_DMA=y
CONFIG_PHY_TANGO_USB=y
CONFIG_EXT4_FS=y
CONFIG_FUSE_FS=m
CONFIG_VFAT_FS=m
CONFIG_TMPFS=y
CONFIG_UBIFS_FS=m
CONFIG_NFS_FS=y
# CONFIG_NFS_V2 is not set
CONFIG_ROOT_NFS=y
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_UTF8=m
CONFIG_PRINTK_TIME=y
# CONFIG_FTRACE is not set
# CONFIG_ARM_UNWIND is not set
# CONFIG_CRYPTO_ECHAINIV is not set
Regards.
^ permalink raw reply related
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