* [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
From: Miquel RAYNAL @ 2018-01-11 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87efmwb8bj.fsf@belgarion.home>
Hi Robert,
On Thu, 11 Jan 2018 18:42:56 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
>
> Hi Boris and Miquel,
>
> > So, here is the plan: since the driver has been tested on various
> > mvebu platforms and is known to work fine on these platforms, I'd
> > like to queue the driver and the patch modifying mvebu defconfigs
> > (patches 1 to 4) for 4.16.
> That's all right.
>
> > I'll leave other patches for 4.17, which means I'd like remaining
> > bugs to be fixed during the 4.16 release cycle so that we can
> > eventually get rid of the old driver. That's really important to me
> > that we don't keep both drivers around for too long, because my
> > previous experience showed that, when you have 2 drivers for the
> > same HW, people don't switch to the new one until they're forced to
> > do it.
> >
> > Robert, are you fine with this approach? What about the tests you
> > were doing? Did you make any progress? Did you find other issues?
> So far, with the latest branch from Miquel of tip commit 12b9e62c851c
> ("ARM64: dts: marvell: use reworked NAND controller driver on Armada
> 8K"), the bad blocks issue is still there, ie :
> - the old pxa3xx driver doesn't see any bad block and mounts the
> ext2/ubifs correctly
> - barebox doesn't see any bad block
> - marvell_nand sees all (or most all) blocks as bad with
> "flash_bbt=0" in platform data, which is very surprising
>
> I'm really surprised that in your tests on the cm_x300, in a
> platform_data setup (ie. not device-tree setup), you're not seeing
> these errors ...
I have no problems with the cm_x300 board (using platform data) but
there is one big difference: the bootloader. You are using Barebox
while I am using U-Boot.
Please pull this branch which is for testing purpose [1].
There are two "HACK"s:
1/ Dump the timing registers: this is to see how Barebox does
initialize these registers. I will put these values back into my setup
and see how the board reacts.
2/ Dump the OOB area while reading. This is to see why the driver
declares all blocks as bad.
Can you please run this branch first?
Then, can you please:
- boot the old driver
- dump both NDTR[0|1] registers that should be well initialized
- boot the new driver with the values previously retrieved (you can
assign these values where exactly HACK 1/ adds the printk's).
Thank you,
Miqu?l
[1]
https://github.com/miquelraynal/linux/commits/marvell/nand-next/nfc-pxa-bug
^ permalink raw reply
* [PATCH v3 1/7] dt-bindings: mtd: document new nand-rb property
From: Rob Herring @ 2018-01-11 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109103637.23798-2-miquel.raynal@free-electrons.com>
On Tue, Jan 09, 2018 at 11:36:31AM +0100, Miquel Raynal wrote:
> There are already an atmel,rb and an allwinner,rb properties, let's not
> make other ones and instead use a generic term: nand-rb to define NAND
> chips Ready/Busy lines.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> Documentation/devicetree/bindings/mtd/nand.txt | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Andrew Lunn @ 2018-01-11 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111214035.GA14748@roeck-us.net>
> > >>+static const struct of_device_id peci_of_table[] = {
> > >>+ { .compatible = "peci-hwmon", },
> > >
> > >This does not look like a reference to some piece of hardware.
> > >
> >
> > This driver provides generic PECI hwmon function to which controller has
> > PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
> > specific hardware. Should I remove this or any suggestion?
PECI seems to be an Intel thing. So at least it should be
{ .compatible = "intel,peci-hwmon", }
assuming it is actually compatible with the Intel specification.
Andrew
^ permalink raw reply
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Mathieu Poirier @ 2018-01-11 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111154942.37120115a94cc77d8f336368@arm.com>
On 11 January 2018 at 14:49, Kim Phillips <kim.phillips@arm.com> wrote:
> On Thu, 11 Jan 2018 14:11:00 -0700
> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>
>> On 11 January 2018 at 10:28, Kim Phillips <kim.phillips@arm.com> wrote:
>> > On Thu, 11 Jan 2018 08:45:21 -0700
>> > Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>> >
>> >> On 11 January 2018 at 05:23, Mark Brown <broonie@kernel.org> wrote:
>> >> > On Wed, Jan 10, 2018 at 06:08:21PM -0600, Kim Phillips wrote:
>> >> >> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>> >> >
>> >> >> > Instructions on how to build and install the openCSD library are provided
>> >> >> > in the HOWTO.md of the project repository.
>> >> >
>> >> >> Usually when a perf builder sees something they need "on," they - or,
>> >> >> at least I - start querying the host's package manager for something
>> >> >> that provides it (e.g., apt search/install libopencsd), but since no
>> >> >> distro provides libopencsd, this is bad because it misleads the user.
>> >> >
>> >> > It's on the radar to push this at distros fairly soon.
>> >
>> > Adding packages to distros takes years, this patchset is being
>> > submitted for inclusion *now*. So until then, it would greatly
>> > facilitate users if the relevant libopencsd source files were
>> > self-contained within perf from the get go.
>>
>> I do not agree with you on the front that it takes years. On the flip
>> side it would take a significant amount of time and effort to refactor
>> the openCSD library so that it can be added to the kernel tree. This
>
> The dtc wasn't refactored before it was added to the kernel tree.
>
>> patchset is available now with a solution that follows what has
>> already been done for dozens of other external library. There is no
>> point in delaying the inclusion of the functionality when an
>> end-to-end solution exists.
>
> See above: I'm not necessarily suggesting the code get refactored.
>
>> >> > Part of the
>> >> > discussion was wanting to get things to the point where the tools using
>> >> > the library were far enough along that we could be reasonably sure that
>> >
>> > Curious, what other tools are there?
>>
>> Ask around at ARM.
>
> I'm asking the person that claimed it.
>
>> >> > there weren't any problems that were going to require ABI breaks to fix
>> >> > before pushing the library at distros since ABI churn isn't nice for
>> >> > packagers to deal with.
>> >
>> > Why make perf the guinea pig? Whatever, this doesn't preclude
>> > adding the code into the tree; it can be removed years from now when
>> > libopencsd becomes ubiquitous among distros.
>>
>> The same can be said about proceeding the other way around - the
>> openCSD library can be added to the kernel tree later if it is deemed
>> necessary. Until then I really don't see why we'd prevent people from
>> accessing the functionality.
>
> Again, I'm not suggesting the code be refactored...
>
>> >> > There's also a bit of a chicken and egg problem
>> >> > in that it's a lot easier to get distros to package libraries that have
>> >> > users available (some are not really bothered about this of course but
>> >> > it still helps).
>> >>
>> >> Moreover including in the kernel tree every library that can
>> >> potentially be used by the perf tools simply doesn't scale.
>> >
>> > This is a trace decoder library we're talking about: there are no
>> > others in perf's system features autodetection list. And why wouldn't
>> > adding such libraries scale?
>>
>> I don't see why a decoder library and say, libelf, need to be treated
>> differently.
>
> libelf is a mature library based on an industry-wide standard, not to
> mention already packaged by most (all?) distros.
>
>> >> The perf
>> >> tools project has come up with a very cleaver way to deal with
>> >> external dependencies and I don't see why the OpenCSD library should
>> >> be different.
>> >
>> > Again, the opencsd library is a decoder library: this patchseries adds
>> > it as a package dependency (when it isn't even a package in any
>> > distro), and it's different in that it's the first decoder library to
>> > be submitted as an external dependency (i.e., not fully built-in, like
>> > Intel's, or even the Arm SPE's pending submission).
>>
>> I don't see why we absolutely need to do exactly the same as Intel.
>> The library is public and this patchset neatly integrates it with the
>> perf tools.
>
> We don't, but it'd be more efficient, upstream-acceptance-wise, but as
> you brought up above, we wouldn't be able to since we'd have to rewrite
> libopencsd to conform to upstream codingstyle, etc., so I'm suggesting
> we might look at a better enablement strategy like how the dtc works.
>
> It'd be nice if the upstream maintainers would comment on what would be
> acceptable instead of us going back and forth between each other.
Agreed.
>
>> >> >> Keeping the library external will also inevitably introduce more
>> >> >> source level synchronization problems because the perf sources being
>> >> >> built may not be compatible with their version of the library, whether
>> >> >> due to new features like new trace hardware support, or API changes.
>> >> >
>> >> > Perf users installing from source rather than from a package (who do
>> >> > tend to the more technical side even for kernel developers) already have
>> >> > to cope with potentially installing at least dwarf, gtk2, libaudit,
>> >> > libbfd, libelf, libnuma, libperl, libpython, libslang, libcrypto,
>> >> > libunwind, libdw-dwarf-unwind, zlib, lzma, bpf and OpenJDK depending on
>> >> > which features they want. I'm not sure that adding one more library is
>> >> > going to be the end of the world here, especially once the packaging
>> >> > starts to filter through distros. Until that happens at least people
>> >> > are no worse off for not having the feature.
>> >>
>> >> I completely agree. Just like any other package, people that want the
>> >> very latest code need to install from source.
>> >
>> > A fully-integrated solution would work better for people, e.g., how are
>> > people supposed to know what 'latest' is when there are separate,
>> > unsynchronized git repos?
>>
>> The same applies to any of the other libraries perf is working with.
>
> The packaged libraries? They are stable: they don't come in the form
> of cloning a git repo and building from scratch.
>
> The decoder libraries? They are self-contained within perf.
>
>> >> >> As Mark Brown (cc'd) mentioned on the Coresight mailing list, this may
>> >> >> be able to be done the same way the dtc is incorporated into the
>> >> >> kernel, where only its relevant sources are included and updated as
>> >> >> needed: see linux/scripts/dtc/update-dtc-source.sh.
>> >> >
>> >> > Bear in mind that we need dtc for essentially all kernel development on
>> >> > ARM and when it was introduced it was a new requirement for existing
>> >> > systems, it's a bit of a different case here where it's an optional
>> >> > feature in an optional tool.
>> >
>> > That argument applies to Intel-PT, yet its decoder is self-contained
>> > within perf: all non-x86 perf binaries are capable of decoding PT.
>> > We'd want that for Arm Coresight where perf gets statically built to
>> > run on much more constrained systems like Android.
>>
>> Traces can't be decoded properly without the support of external
>> libraries, whether we are talking about PT or CS.
>
> Not true; perf has PT decoding self-contained.
>
> Thanks,
>
> Kim
^ permalink raw reply
* [PATCH V4 2/2] ARM: dts: imx7s: add snvs rtc clock
From: Rob Herring @ 2018-01-11 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515491526-14060-2-git-send-email-Anson.Huang@nxp.com>
On Tue, Jan 09, 2018 at 05:52:06PM +0800, Anson Huang wrote:
> Add i.MX7 SNVS RTC clock.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> change since v3:
> add optional for clocks in binding doc statement.
> Documentation/devicetree/bindings/crypto/fsl-sec4.txt | 17 +++++++++++++++++
> arch/arm/boot/dts/imx7s.dtsi | 2 ++
> 2 files changed, 19 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH V4 1/2] clk: imx: imx7d: add the snvs clock
From: Rob Herring @ 2018-01-11 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515491526-14060-1-git-send-email-Anson.Huang@nxp.com>
On Tue, Jan 09, 2018 at 05:52:05PM +0800, Anson Huang wrote:
> According to the i.MX7D Reference Manual,
> SNVS block has a clock gate, accessing SNVS block
> would need this clock gate to be enabled, add it
> into clock tree so that SNVS module driver can
> operate this clock gate.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> drivers/clk/imx/clk-imx7d.c | 1 +
> include/dt-bindings/clock/imx7d-clock.h | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 07/16] dt-bindings: iio: adc: axp20x_adc: add AXP813 variant
From: Rob Herring @ 2018-01-11 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <64b538aadf075ba07e567d9a9db865b64c97fbfc.1515486346.git-series.quentin.schulz@free-electrons.com>
On Tue, Jan 09, 2018 at 10:33:38AM +0100, Quentin Schulz wrote:
> AXP813 is now supported so add documentation for this compatible.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt | 9 +++++++++-
> 1 file changed, 9 insertions(+)
You can just squash this into the patch #2.
Either way,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 02/16] dt-bindings: iio: adc: add binding for X-Powers AXP PMICs ADC
From: Rob Herring @ 2018-01-11 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bef3ba5e4a2c47f13fa9ba8e6fb0267b7bb15026.1515486346.git-series.quentin.schulz@free-electrons.com>
On Tue, Jan 09, 2018 at 10:33:33AM +0100, Quentin Schulz wrote:
> X-Powers PMICs have several ADC channels that can be used for different
> purposes, e.g. PMIC internal temperature, battery voltage or AC current.
>
> This is the documentation for AXP209, AXP221/223 ADC bindings.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt | 39 +++++++++-
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
> new file mode 100644
> index 0000000..ed6d04e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
> @@ -0,0 +1,39 @@
> +* X-Powers AXP ADC bindings
> +
> +Required properties:
> + - compatible: should be one of:
> + - "x-powers,axp20x-adc",
> + - "x-powers,axp22x-adc",
> + - #io-channel-cells: should be 1,
> +
> +Example:
> +
> +&axp22x {
> + axp_adc: axp-adc {
adc {
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
> + compatible = "x-powers,axp22x-adc";
> + #io-channel-cells = <1>;
> + };
> +};
> +
> +ADC channels and their indexes per variant:
> +
> +AXP209
> +------
> + 0 | acin_v
> + 1 | acin_i
> + 2 | vbus_v
> + 3 | vbus_i
> + 4 | pmic_temp
> + 5 | gpio0_v
> + 6 | gpio1_v
> + 7 | ipsout_v
> + 8 | batt_v
> + 9 | batt_chrg_i
> +10 | batt_dischrg_i
> +
> +AXP22x
> +------
> + 0 | pmic_temp
> + 1 | batt_v
> + 2 | batt_chrg_i
> + 3 | batt_dischrg_i
> --
> git-series 0.9.1
^ permalink raw reply
* [PATCH 2/2] kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
From: Andrey Ryabinin @ 2018-01-11 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff221eca3db7a1f208c30c625b7d209fba33abb9.1515684162.git.andreyknvl@google.com>
On 01/11/2018 06:29 PM, Andrey Konovalov wrote:
> diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
> index e266f80e45b7..811643fe7640 100644
> --- a/arch/arm64/include/asm/kasan.h
> +++ b/arch/arm64/include/asm/kasan.h
> @@ -27,7 +27,8 @@
> * should satisfy the following equation:
> * KASAN_SHADOW_OFFSET = KASAN_SHADOW_END - (1ULL << 61)
Care to update comments as well?
> */
> -#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << (64 - 3)))
> +#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << \
> + (64 - KASAN_SHADOW_SCALE_SHIFT)))
>
> void kasan_init(void);
> void kasan_copy_shadow(pgd_t *pgdir);
^ permalink raw reply
* [PATCH 5/6] arm64: tegra: Add Tegra194 chip device tree
From: Rob Herring @ 2018-01-11 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515387278-29777-6-git-send-email-mperttunen@nvidia.com>
On Mon, Jan 08, 2018 at 06:54:37AM +0200, Mikko Perttunen wrote:
> Add the chip-level device tree, including binding headers, for the
> NVIDIA Tegra194 "Xavier" system-on-chip. Only a small subset of devices
> are initially available, enough to boot to UART console.
>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 334 +++++++++++++++++++++++++++++
> include/dt-bindings/clock/tegra194-clock.h | 59 +++++
> include/dt-bindings/gpio/tegra194-gpio.h | 59 +++++
> include/dt-bindings/reset/tegra194-reset.h | 40 ++++
> 4 files changed, 492 insertions(+)
> create mode 100644 arch/arm64/boot/dts/nvidia/tegra194.dtsi
> create mode 100644 include/dt-bindings/clock/tegra194-clock.h
> create mode 100644 include/dt-bindings/gpio/tegra194-gpio.h
> create mode 100644 include/dt-bindings/reset/tegra194-reset.h
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> new file mode 100644
> index 000000000000..51eff420816d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -0,0 +1,334 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <dt-bindings/clock/tegra194-clock.h>
> +#include <dt-bindings/gpio/tegra194-gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/mailbox/tegra186-hsp.h>
> +#include <dt-bindings/reset/tegra194-reset.h>
> +
> +/ {
> + compatible = "nvidia,tegra194";
Documented?
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + uarta: serial at 3100000 {
These should all be under a bus node. Tegra failed to do this at the
start and we're still copy-n-pasting this mistake.
Then you probably don't need 2 address and size cells for all the
peripherals.
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03100000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTA>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTA>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + uartb: serial at 3110000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03110000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTB>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTB>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + uartd: serial at 3130000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03130000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTD>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTD>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + uarte: serial at 3140000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03140000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTE>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTE>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + uartf: serial at 3150000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03150000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTF>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTF>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + gen1_i2c: i2c at 3160000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x03160000 0x0 0x10000>;
> + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C1>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C1>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + uarth: serial at 3170000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x03170000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTH>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTH>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + cam_i2c: i2c at 3180000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x03180000 0x0 0x10000>;
> + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C3>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C3>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + /* shares pads with dpaux1 */
> + dp_aux_ch1_i2c: i2c at 3190000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x03190000 0x0 0x10000>;
> + interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C4>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C4>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + /* shares pads with dpaux0 */
> + dp_aux_ch0_i2c: i2c at 31b0000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x031b0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C6>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C6>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + gen7_i2c: i2c at 31c0000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x031c0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C7>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C7>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + gen9_i2c: i2c at 31e0000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x031e0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C9>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C9>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + sdmmc1: sdhci at 3400000 {
> + compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci";
> + reg = <0x0 0x03400000 0x0 0x10000>;
> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_SDMMC1>;
> + clock-names = "sdhci";
> + resets = <&bpmp TEGRA194_RESET_SDMMC1>;
> + reset-names = "sdhci";
> + status = "disabled";
> + };
> +
> + sdmmc3: sdhci at 3440000 {
> + compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci";
> + reg = <0x0 0x03440000 0x0 0x10000>;
> + interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_SDMMC3>;
> + clock-names = "sdhci";
> + resets = <&bpmp TEGRA194_RESET_SDMMC3>;
> + reset-names = "sdhci";
> + status = "disabled";
> + };
> +
> + sdmmc4: sdhci at 3460000 {
> + compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci";
> + reg = <0x0 0x03460000 0x0 0x10000>;
> + interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_SDMMC4>;
> + clock-names = "sdhci";
> + resets = <&bpmp TEGRA194_RESET_SDMMC4>;
> + reset-names = "sdhci";
> + status = "disabled";
> + };
> +
> + gic: interrupt-controller at 3881000 {
> + compatible = "arm,gic-400";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x0 0x03881000 0x0 0x1000>,
> + <0x0 0x03882000 0x0 0x2000>;
> + interrupts = <GIC_PPI 9
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-parent = <&gic>;
> + };
> +
> + hsp_top0: hsp at 3c00000 {
> + compatible = "nvidia,tegra186-hsp";
> + reg = <0x0 0x03c00000 0x0 0xa0000>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "doorbell";
> + #mbox-cells = <2>;
> + };
> +
> + gen2_i2c: i2c at c240000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x0c240000 0x0 0x10000>;
> + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C2>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C2>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + gen8_i2c: i2c at c250000 {
> + compatible = "nvidia,tegra194-i2c", "nvidia,tegra114-i2c";
> + reg = <0x0 0x0c250000 0x0 0x10000>;
> + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&bpmp TEGRA194_CLK_I2C8>;
> + clock-names = "div-clk";
> + resets = <&bpmp TEGRA194_RESET_I2C8>;
> + reset-names = "i2c";
> + status = "disabled";
> + };
> +
> + uartc: serial at c280000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x0c280000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTC>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTC>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + uartg: serial at c290000 {
> + compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
> + reg = <0x0 0x0c290000 0x0 0x40>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA194_CLK_UARTG>;
> + clock-names = "serial";
> + resets = <&bpmp TEGRA194_RESET_UARTG>;
> + reset-names = "serial";
> + status = "disabled";
> + };
> +
> + pmc at c360000 {
> + compatible = "nvidia,tegra194-pmc";
> + reg = <0 0x0c360000 0 0x10000>,
> + <0 0x0c370000 0 0x10000>,
> + <0 0x0c380000 0 0x10000>,
> + <0 0x0c390000 0 0x10000>,
> + <0 0x0c3a0000 0 0x10000>;
> + reg-names = "pmc", "wake", "aotag", "scratch", "misc";
> + };
> +
> + sysram at 40000000 {
> + compatible = "nvidia,tegra194-sysram", "mmio-sram";
> + reg = <0x0 0x40000000 0x0 0x50000>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0 0x0 0x0 0x40000000 0x0 0x50000>;
> +
> + cpu_bpmp_tx: shmem at 4e000 {
> + compatible = "nvidia,tegra194-bpmp-shmem";
> + reg = <0x0 0x4e000 0x0 0x1000>;
> + label = "cpu-bpmp-tx";
> + pool;
> + };
> +
> + cpu_bpmp_rx: shmem at 4f000 {
> + compatible = "nvidia,tegra194-bpmp-shmem";
> + reg = <0x0 0x4f000 0x0 0x1000>;
> + label = "cpu-bpmp-rx";
> + pool;
> + };
> + };
> +
> + bpmp: bpmp {
> + compatible = "nvidia,tegra186-bpmp";
> + mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB
> + TEGRA_HSP_DB_MASTER_BPMP>;
> + shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> +
> + bpmp_i2c: i2c {
> + compatible = "nvidia,tegra186-bpmp-i2c";
> + nvidia,bpmp-bus-id = <5>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + bpmp_thermal: thermal {
> + compatible = "nvidia,tegra186-bpmp-thermal";
> + #thermal-sensor-cells = <1>;
> + };
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> + interrupt-parent = <&gic>;
> + };
> +};
> diff --git a/include/dt-bindings/clock/tegra194-clock.h b/include/dt-bindings/clock/tegra194-clock.h
> new file mode 100644
> index 000000000000..7eba4763e375
> --- /dev/null
> +++ b/include/dt-bindings/clock/tegra194-clock.h
> @@ -0,0 +1,59 @@
> +/*
> + * Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
Seems you missed using SPDX tag on this one.
> + */
> +
> +#ifndef __ABI_MACH_T194_CLOCK_H
> +#define __ABI_MACH_T194_CLOCK_H
> +
> +/** @clkdesc{i2c_clks, out, mux, CLK_RST_CONTROLLER_CLK_SOURCE_I2C1} */
> +#define TEGRA194_CLK_I2C1 48
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C2 */
> +#define TEGRA194_CLK_I2C2 49
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C3 */
> +#define TEGRA194_CLK_I2C3 50
> +/** output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C4 */
> +#define TEGRA194_CLK_I2C4 51
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C6 */
> +#define TEGRA194_CLK_I2C6 52
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C7 */
> +#define TEGRA194_CLK_I2C7 53
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C8 */
> +#define TEGRA194_CLK_I2C8 54
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C9 */
> +#define TEGRA194_CLK_I2C9 55
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_SDMMC1 */
> +#define TEGRA194_CLK_SDMMC1 120
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_SDMMC3 */
> +#define TEGRA194_CLK_SDMMC3 122
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_SDMMC4 */
> +#define TEGRA194_CLK_SDMMC4 123
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTA */
> +#define TEGRA194_CLK_UARTA 155
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTB */
> +#define TEGRA194_CLK_UARTB 156
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTC */
> +#define TEGRA194_CLK_UARTC 157
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTD */
> +#define TEGRA194_CLK_UARTD 158
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTE */
> +#define TEGRA194_CLK_UARTE 159
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTF */
> +#define TEGRA194_CLK_UARTF 160
> +/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_UARTG */
> +#define TEGRA194_CLK_UARTG 161
> +/** @brief CLK_RST_CONTROLLER_CLK_SOURCE_UARTH switch divider output */
> +#define TEGRA194_CLK_UARTH 190
> +
> +#endif
> diff --git a/include/dt-bindings/gpio/tegra194-gpio.h b/include/dt-bindings/gpio/tegra194-gpio.h
> new file mode 100644
> index 000000000000..86435a73ef9e
> --- /dev/null
> +++ b/include/dt-bindings/gpio/tegra194-gpio.h
> @@ -0,0 +1,59 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * This header provides constants for binding nvidia,tegra194-gpio*.
> + *
> + * The first cell in Tegra's GPIO specifier is the GPIO ID. The macros below
> + * provide names for this.
> + *
> + * The second cell contains standard flag values specified in gpio.h.
> + */
> +
> +#ifndef _DT_BINDINGS_GPIO_TEGRA194_GPIO_H
> +#define _DT_BINDINGS_GPIO_TEGRA194_GPIO_H
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/* GPIOs implemented by main GPIO controller */
> +#define TEGRA194_MAIN_GPIO_PORT_A 0
> +#define TEGRA194_MAIN_GPIO_PORT_B 1
> +#define TEGRA194_MAIN_GPIO_PORT_C 2
> +#define TEGRA194_MAIN_GPIO_PORT_D 3
> +#define TEGRA194_MAIN_GPIO_PORT_E 4
> +#define TEGRA194_MAIN_GPIO_PORT_F 5
> +#define TEGRA194_MAIN_GPIO_PORT_G 6
> +#define TEGRA194_MAIN_GPIO_PORT_H 7
> +#define TEGRA194_MAIN_GPIO_PORT_I 8
> +#define TEGRA194_MAIN_GPIO_PORT_J 9
> +#define TEGRA194_MAIN_GPIO_PORT_K 10
> +#define TEGRA194_MAIN_GPIO_PORT_L 11
> +#define TEGRA194_MAIN_GPIO_PORT_M 12
> +#define TEGRA194_MAIN_GPIO_PORT_N 13
> +#define TEGRA194_MAIN_GPIO_PORT_O 14
> +#define TEGRA194_MAIN_GPIO_PORT_P 15
> +#define TEGRA194_MAIN_GPIO_PORT_Q 16
> +#define TEGRA194_MAIN_GPIO_PORT_R 17
> +#define TEGRA194_MAIN_GPIO_PORT_S 18
> +#define TEGRA194_MAIN_GPIO_PORT_T 19
> +#define TEGRA194_MAIN_GPIO_PORT_U 20
> +#define TEGRA194_MAIN_GPIO_PORT_V 21
> +#define TEGRA194_MAIN_GPIO_PORT_W 22
> +#define TEGRA194_MAIN_GPIO_PORT_X 23
> +#define TEGRA194_MAIN_GPIO_PORT_Y 24
> +#define TEGRA194_MAIN_GPIO_PORT_Z 25
> +#define TEGRA194_MAIN_GPIO_PORT_FF 26
> +#define TEGRA194_MAIN_GPIO_PORT_GG 27
> +
> +#define TEGRA194_MAIN_GPIO(port, offset) \
> + ((TEGRA194_MAIN_GPIO_PORT_##port * 8) + offset)
> +
> +/* GPIOs implemented by AON GPIO controller */
> +#define TEGRA194_AON_GPIO_PORT_AA 0
> +#define TEGRA194_AON_GPIO_PORT_BB 1
> +#define TEGRA194_AON_GPIO_PORT_CC 2
> +#define TEGRA194_AON_GPIO_PORT_DD 3
> +#define TEGRA194_AON_GPIO_PORT_EE 4
> +
> +#define TEGRA194_AON_GPIO(port, offset) \
> + ((TEGRA194_AON_GPIO_PORT_##port * 8) + offset)
> +
> +#endif
> diff --git a/include/dt-bindings/reset/tegra194-reset.h b/include/dt-bindings/reset/tegra194-reset.h
> new file mode 100644
> index 000000000000..7c6afac99c4a
> --- /dev/null
> +++ b/include/dt-bindings/reset/tegra194-reset.h
> @@ -0,0 +1,40 @@
> +/*
> + * Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
SPDX
> + */
> +
> +#ifndef __ABI_MACH_T194_RESET_H
> +#define __ABI_MACH_T194_RESET_H
> +
> +#define TEGRA194_RESET_I2C1 24
> +#define TEGRA194_RESET_I2C2 29
> +#define TEGRA194_RESET_I2C3 30
> +#define TEGRA194_RESET_I2C4 31
> +#define TEGRA194_RESET_I2C6 32
> +#define TEGRA194_RESET_I2C7 33
> +#define TEGRA194_RESET_I2C8 34
> +#define TEGRA194_RESET_I2C9 35
> +#define TEGRA194_RESET_SDMMC1 82
> +#define TEGRA194_RESET_SDMMC3 84
> +#define TEGRA194_RESET_SDMMC4 85
> +#define TEGRA194_RESET_UARTA 100
> +#define TEGRA194_RESET_UARTB 101
> +#define TEGRA194_RESET_UARTC 102
> +#define TEGRA194_RESET_UARTD 103
> +#define TEGRA194_RESET_UARTE 104
> +#define TEGRA194_RESET_UARTF 105
> +#define TEGRA194_RESET_UARTG 106
> +#define TEGRA194_RESET_UARTH 107
> +
> +#endif
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: acivate SPI on Orange Pi R1
From: Hauke Mehrtens @ 2018-01-11 21:53 UTC (permalink / raw)
To: linux-arm-kernel
This board has a SPI flash, activate it also in device tree by default.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
index 112f09c67d67..3356f4210d45 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-r1.dts
@@ -68,6 +68,14 @@
};
};
+&spi0 {
+ status = "okay";
+
+ flash at 0 {
+ compatible = "mxicy,mx25l12805d", "jedec,spi-nor";
+ };
+};
+
&ohci1 {
/*
* RTL8152B USB-Ethernet adapter is connected to USB1,
--
2.11.0
^ permalink raw reply related
* [PATCH v5 17/44] dt-bindings: clock: Add bindings for DA8XX CFGCHIP gate clocks
From: David Lechner @ 2018-01-11 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111214516.quplp3kwwfrzocfp@rob-hp-laptop>
On 01/11/2018 03:45 PM, Rob Herring wrote:
> On Sun, Jan 07, 2018 at 08:17:16PM -0600, David Lechner wrote:
>> This adds a new binding for the gate clocks present in the CFGCHIP syscon
>> registers in TI DA8XX SoCs. There are actually other gate clocks in this
>> block that could be added in the future, but TBCLK is currently the only
>> one being used.
>
> Like how many? 2 more?, then fine. 20 more, then perhaps cfgchip should
> be the clock provider.
Like, one more. Same goes for the mux clock. The USB PHY clocks are also
part of the CFGCHIP.
All of these clocks are randomly spread out, so I didn't really see a logical
way to make a single clock provider with #clock-cells = <1>.
>
> In any case, I'd prefer to see all the cfgchip clocks documented in one
> doc.
I will do that.
^ permalink raw reply
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Kim Phillips @ 2018-01-11 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkyW2oH=6TjPRoDyAqtHKVQbAYesNA5O5QmLBSnjCie8dw@mail.gmail.com>
On Thu, 11 Jan 2018 14:11:00 -0700
Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On 11 January 2018 at 10:28, Kim Phillips <kim.phillips@arm.com> wrote:
> > On Thu, 11 Jan 2018 08:45:21 -0700
> > Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >
> >> On 11 January 2018 at 05:23, Mark Brown <broonie@kernel.org> wrote:
> >> > On Wed, Jan 10, 2018 at 06:08:21PM -0600, Kim Phillips wrote:
> >> >> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >> >
> >> >> > Instructions on how to build and install the openCSD library are provided
> >> >> > in the HOWTO.md of the project repository.
> >> >
> >> >> Usually when a perf builder sees something they need "on," they - or,
> >> >> at least I - start querying the host's package manager for something
> >> >> that provides it (e.g., apt search/install libopencsd), but since no
> >> >> distro provides libopencsd, this is bad because it misleads the user.
> >> >
> >> > It's on the radar to push this at distros fairly soon.
> >
> > Adding packages to distros takes years, this patchset is being
> > submitted for inclusion *now*. So until then, it would greatly
> > facilitate users if the relevant libopencsd source files were
> > self-contained within perf from the get go.
>
> I do not agree with you on the front that it takes years. On the flip
> side it would take a significant amount of time and effort to refactor
> the openCSD library so that it can be added to the kernel tree. This
The dtc wasn't refactored before it was added to the kernel tree.
> patchset is available now with a solution that follows what has
> already been done for dozens of other external library. There is no
> point in delaying the inclusion of the functionality when an
> end-to-end solution exists.
See above: I'm not necessarily suggesting the code get refactored.
> >> > Part of the
> >> > discussion was wanting to get things to the point where the tools using
> >> > the library were far enough along that we could be reasonably sure that
> >
> > Curious, what other tools are there?
>
> Ask around at ARM.
I'm asking the person that claimed it.
> >> > there weren't any problems that were going to require ABI breaks to fix
> >> > before pushing the library at distros since ABI churn isn't nice for
> >> > packagers to deal with.
> >
> > Why make perf the guinea pig? Whatever, this doesn't preclude
> > adding the code into the tree; it can be removed years from now when
> > libopencsd becomes ubiquitous among distros.
>
> The same can be said about proceeding the other way around - the
> openCSD library can be added to the kernel tree later if it is deemed
> necessary. Until then I really don't see why we'd prevent people from
> accessing the functionality.
Again, I'm not suggesting the code be refactored...
> >> > There's also a bit of a chicken and egg problem
> >> > in that it's a lot easier to get distros to package libraries that have
> >> > users available (some are not really bothered about this of course but
> >> > it still helps).
> >>
> >> Moreover including in the kernel tree every library that can
> >> potentially be used by the perf tools simply doesn't scale.
> >
> > This is a trace decoder library we're talking about: there are no
> > others in perf's system features autodetection list. And why wouldn't
> > adding such libraries scale?
>
> I don't see why a decoder library and say, libelf, need to be treated
> differently.
libelf is a mature library based on an industry-wide standard, not to
mention already packaged by most (all?) distros.
> >> The perf
> >> tools project has come up with a very cleaver way to deal with
> >> external dependencies and I don't see why the OpenCSD library should
> >> be different.
> >
> > Again, the opencsd library is a decoder library: this patchseries adds
> > it as a package dependency (when it isn't even a package in any
> > distro), and it's different in that it's the first decoder library to
> > be submitted as an external dependency (i.e., not fully built-in, like
> > Intel's, or even the Arm SPE's pending submission).
>
> I don't see why we absolutely need to do exactly the same as Intel.
> The library is public and this patchset neatly integrates it with the
> perf tools.
We don't, but it'd be more efficient, upstream-acceptance-wise, but as
you brought up above, we wouldn't be able to since we'd have to rewrite
libopencsd to conform to upstream codingstyle, etc., so I'm suggesting
we might look at a better enablement strategy like how the dtc works.
It'd be nice if the upstream maintainers would comment on what would be
acceptable instead of us going back and forth between each other.
> >> >> Keeping the library external will also inevitably introduce more
> >> >> source level synchronization problems because the perf sources being
> >> >> built may not be compatible with their version of the library, whether
> >> >> due to new features like new trace hardware support, or API changes.
> >> >
> >> > Perf users installing from source rather than from a package (who do
> >> > tend to the more technical side even for kernel developers) already have
> >> > to cope with potentially installing at least dwarf, gtk2, libaudit,
> >> > libbfd, libelf, libnuma, libperl, libpython, libslang, libcrypto,
> >> > libunwind, libdw-dwarf-unwind, zlib, lzma, bpf and OpenJDK depending on
> >> > which features they want. I'm not sure that adding one more library is
> >> > going to be the end of the world here, especially once the packaging
> >> > starts to filter through distros. Until that happens at least people
> >> > are no worse off for not having the feature.
> >>
> >> I completely agree. Just like any other package, people that want the
> >> very latest code need to install from source.
> >
> > A fully-integrated solution would work better for people, e.g., how are
> > people supposed to know what 'latest' is when there are separate,
> > unsynchronized git repos?
>
> The same applies to any of the other libraries perf is working with.
The packaged libraries? They are stable: they don't come in the form
of cloning a git repo and building from scratch.
The decoder libraries? They are self-contained within perf.
> >> >> As Mark Brown (cc'd) mentioned on the Coresight mailing list, this may
> >> >> be able to be done the same way the dtc is incorporated into the
> >> >> kernel, where only its relevant sources are included and updated as
> >> >> needed: see linux/scripts/dtc/update-dtc-source.sh.
> >> >
> >> > Bear in mind that we need dtc for essentially all kernel development on
> >> > ARM and when it was introduced it was a new requirement for existing
> >> > systems, it's a bit of a different case here where it's an optional
> >> > feature in an optional tool.
> >
> > That argument applies to Intel-PT, yet its decoder is self-contained
> > within perf: all non-x86 perf binaries are capable of decoding PT.
> > We'd want that for Arm Coresight where perf gets statically built to
> > run on much more constrained systems like Android.
>
> Traces can't be decoded properly without the support of external
> libraries, whether we are talking about PT or CS.
Not true; perf has PT decoding self-contained.
Thanks,
Kim
^ permalink raw reply
* [PATCH 4/6] dt-bindings: tegra: Add documentation for nvidia,tegra194-pmc
From: Rob Herring @ 2018-01-11 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515387278-29777-5-git-send-email-mperttunen@nvidia.com>
On Mon, Jan 08, 2018 at 06:54:36AM +0200, Mikko Perttunen wrote:
> The Tegra194 power management controller has one additional register
> aperture to be specified in the device tree node.
>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: David Lechner @ 2018-01-11 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xKV+Rwep3WiY2aS49iLu+oiZmjtUN2QK+E=hVkqdSPwhw@mail.gmail.com>
On 01/11/2018 03:34 PM, Adam Ford wrote:
> On Thu, Jan 11, 2018 at 3:04 PM, David Lechner <david@lechnology.com> wrote:
>> On 01/11/2018 02:58 PM, Adam Ford wrote:
>>>
>>> On Thu, Jan 11, 2018 at 2:04 PM, David Lechner <david@lechnology.com>
>>> wrote:
>>>>
>>>> On 01/11/2018 12:50 PM, Adam Ford wrote:
>>>>>
>>>>>
>>>>> On Thu, Jan 11, 2018 at 12:29 PM, David Lechner <david@lechnology.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> If removing the "clk_ignore_unused" option causes the board to not
>>>>>> boot,
>>>>>> then we still have problems that need to be fixed, so please also test
>>>>>> without this option.
>>>>>
>>>>>
>>>>>
>>>>> Without this option, it still does not boot. Without device tree it
>>>>> hangs after:
>>>>>
>>>>> [snip]
>>>>>
>>>>> NET: Registered protocol family 17
>>>>> Loading compiled-in X.509 certificates
>>>>> console [netcon0] enabled
>>>>> netconsole: network logging started
>>>>> davinci_emac davinci_emac.1: using random MAC addr: 5e:38:1a:1f:4f:77
>>>>> mmc0: host does not support reading read-only switch, assuming
>>>>> write-enable
>>>>> hctosys: unable to open rtc device (rtc0)
>>>>> mmc0: new high speed SDHC card at address b368
>>>>>
>>>>>
>>>>> With device tree it hangs after:
>>>>>
>>>>> [snip]
>>>>> mmc0: host does not support reading read-only switch, assuming
>>>>> write-enable
>>>>> mmc0: new high speed SDHC card at address b368
>>>>> mmcblk0: mmc0:b368 00000 3.75 GiB
>>>>> mmcblk0: p1 p2
>>>>> pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
>>>>> pca953x 0-0020: failed reading register
>>>>> pca953x: probe of 0-0020 failed with error -121
>>>>> console [netcon0] enabled
>>>>> netconsole: network logging started
>>>>> davinci_emac 1e20000.ethernet: incompatible machine/device type for
>>>>> reading mac address
>>>>> hctosys: unable to open rtc device (rtc0)
>>>>>
>>>>>
>>>>
>>>> Please try this change:
>>>>
>>>> diff --git a/drivers/clk/davinci/psc-da850.c
>>>> b/drivers/clk/davinci/psc-da850.c
>>>> index 3fd6b49..a526cc2 100644
>>>> --- a/drivers/clk/davinci/psc-da850.c
>>>> +++ b/drivers/clk/davinci/psc-da850.c
>>>> @@ -17,7 +17,7 @@ static const struct davinci_psc_clk_info
>>>> da850_psc0_info[]
>>>> __initconst = {
>>>> LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>>> LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>>> LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>>> - LPSC(3, 0, aemif, pll0_sysclk3, 0),
>>>> + LPSC(3, 0, aemif, pll0_sysclk3, LPSC_ALWAYS_ENABLED),
>>>> LPSC(4, 0, spi0, pll0_sysclk2, 0),
>>>> LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
>>>> LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
>>>>
>>>>
>>>>
>>>> If that does not work, try adding LPSC_ALWAYS_ENABLED to all of the
>>>> clocks
>>>> in this file and then eliminate them one by one until you find which one
>>>> is
>>>> preventing boot.
>>>>
>>> Unfortunately, that didn't work. I switch all the entries in both
>>> tables that had a 0 to LPSC_ALWAYS_ENABLED, but no luck booting.
>>>
>>>> If it still does not boot, there is a similar DIVCLK_ALWAYS_ENABLED flag
>>>> in
>>>> drivers/clk/davinci/pll-da850.c that you can repeat the exercise with.
>>>> Add
>>>> DIVCLK_ALWAYS_ENABLED to all of the clocks there and then eliminate it
>>>> one
>>>> by one until you find the clock that is causing the problem.
>>>
>>>
>>> Still no good news. I switched all the entries with a 0 to
>>> DIVCLK_ALWAYS_ENABLED and it still didn't finish booting.
>>>
>>> I wonder if Sekhar Nori might have some suggestions. I didn't look at
>>> the code or try to understand it. I just changed the settings.
>>>>
>>>>
>>
>> Even if a clock had another flag besides zero, you will need to add
>> LPSC_ALWAYS_ENABLED by or-ing it with the other flag.
>>
>
> [snip]
>
>
> Thanks for clarifying. I was able to make it work with the following patch:
>
> diff --git a/drivers/clk/davinci/psc-da850.c b/drivers/clk/davinci/psc-da850.c
> index 3b4583d..a76b8682 100644
> --- a/drivers/clk/davinci/psc-da850.c
> +++ b/drivers/clk/davinci/psc-da850.c
> @@ -25,7 +25,7 @@ static const struct davinci_psc_clk_info
> da850_psc0_info[] __initconst = {
> LPSC(9, 0, uart0, pll0_sysclk2, 0),
> LPSC(13, 0, pruss, pll0_sysclk2, 0),
> LPSC(14, 0, arm, pll0_sysclk6, LPSC_ALWAYS_ENABLED),
> - LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET),
> + LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET |
> LPSC_ALWAYS_ENABLED),
> { }
> };
>
>
> If you have an updated patch series with those two fixes, I add my
> name to the tested-by list.
>
>
>>
>>
> [snip]
>>
Great! Thanks again for testing.
Sekhar, have you had a chance to look at the rest of the patches in the
series?
I'll wait a bit before I send a v6 to see if any other comments come.
^ permalink raw reply
* [PATCH v5 17/44] dt-bindings: clock: Add bindings for DA8XX CFGCHIP gate clocks
From: Rob Herring @ 2018-01-11 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515377863-20358-18-git-send-email-david@lechnology.com>
On Sun, Jan 07, 2018 at 08:17:16PM -0600, David Lechner wrote:
> This adds a new binding for the gate clocks present in the CFGCHIP syscon
> registers in TI DA8XX SoCs. There are actually other gate clocks in this
> block that could be added in the future, but TBCLK is currently the only
> one being used.
Like how many? 2 more?, then fine. 20 more, then perhaps cfgchip should
be the clock provider.
In any case, I'd prefer to see all the cfgchip clocks documented in one
doc.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> .../clock/ti/davinci/da8xx-cfgchip-gate.txt | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-gate.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-gate.txt b/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-gate.txt
> new file mode 100644
> index 0000000..55821b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti/davinci/da8xx-cfgchip-gate.txt
> @@ -0,0 +1,38 @@
> +Binding for TI DA8XX/OMAP-L13X/AM17XX/AM18XX CFGCHIP gate clocks
> +
> +TI DA8XX/OMAP-L13X/AM17XX/AM18XX SoCs contain a general purpose set of
> +registers call CFGCHIPn. Some of these registers function as clock
> +gates. This document describes the bindings for those clocks.
> +
> +Required properties:
> +- compatible: shall be "ti,da830-tbclk".
> +- #clock-cells: from common clock binding; shall be set to 0.
> +- clocks: phandle to the parent clock
> +
> +Optional properties:
> +- clock-output-names: from common clock binding.
> +
> +Parent:
> +This node must be a child of a "ti,da830-cfgchip" node.
> +
> +Assignment:
> +The assigned-clocks and assigned-clock-parents from the common clock bindings
> +can be used to indicate which parent clock should be used.
> +
> +Examples:
> +
> + cfgchip: syscon at 1417c {
> + compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
> + reg = <0x1417c 0x14>;
> +
> + ehrpwm_tbclk: tbclk {
> + compatible = "ti,da830-tbclk";
> + #clock-cells = <0>;
> + clocks = <&psc1 17>;
> + clock-output-names = "ehrpwm_tbclk";
> + };
> + };
> +
> +Also see:
> +- Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> --
> 2.7.4
>
^ permalink raw reply
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Guenter Roeck @ 2018-01-11 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <261ac28e-813c-a058-c81f-ad4e718d0233@linux.intel.com>
On Thu, Jan 11, 2018 at 11:47:01AM -0800, Jae Hyun Yoo wrote:
> On 1/10/2018 1:47 PM, Guenter Roeck wrote:
> >On Tue, Jan 09, 2018 at 02:31:26PM -0800, Jae Hyun Yoo wrote:
> >>This commit adds driver implementation for a generic PECI hwmon.
> >>
> >>Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
[ ... ]
> >>+
> >>+ if (priv->temp.tcontrol.valid &&
> >>+ time_before(jiffies, priv->temp.tcontrol.last_updated +
> >>+ UPDATE_INTERVAL_MIN))
> >>+ return 0;
> >>+
> >
> >Is the delay necessary ? Otherwise I would suggest to drop it.
> >It adds a lot of complexity to the driver. Also, if the user polls
> >values more often, that is presumably on purpose.
> >
>
> I was intended to reduce traffic on PECI bus because it's low speed single
> wired bus, and temperature values don't change frequently because the value
> is sampled and averaged in CPU itself. I'll keep this.
>
Then please try to move the common code into a single function.
[ ... ]
> >>+
> >>+ rc = of_property_read_u32(np, "cpu-id", &priv->cpu_id);
> >
> >What entity determines cpu-id ?
> >
>
> CPU ID numbering is determined by hardware SOCKET_ID strap pins. In this
> driver implementation, cpu-id is being used as CPU client indexing.
>
Seems to me the necessary information to identify a given CPU should
be provided by the PECI core. Also, there are already "cpu" nodes
in devicetree which, if I recall correctly, may include information
such as CPU Ids.
> >>+ if (rc || priv->cpu_id >= CPU_ID_MAX) {
> >>+ dev_err(dev, "Invalid cpu-id configuration\n");
> >>+ return rc;
> >>+ }
> >>+
> >>+ rc = of_property_read_u32(np, "dimm-nums", &priv->dimm_nums);
> >
> >This is an odd devicetree attribute. Normally the number of DIMMs
> >is dynamic. Isn't there a means to get all that information dynamically
> >instead of having to set it through devicetree ? What if someone adds
> >or removes a DIMM ? Who updates the devicetree ?
> >
>
> It means the number of DIMM slots each CPU has, doesn't mean the number of
> currently installed DIMM components. If a DIMM is inserted a slot, CPU
> reports its actual temperature but on empty slot, CPU reports 0 instead of
> reporting an error so it is the reason why this driver enumerates all DIMM
> slots' attribute.
>
And there is no other means to get the number of DIMM slots per CPU ?
It just seems to be that this is the wrong location to provide such
information.
[ ... ]
> >>+
> >>+static const struct of_device_id peci_of_table[] = {
> >>+ { .compatible = "peci-hwmon", },
> >
> >This does not look like a reference to some piece of hardware.
> >
>
> This driver provides generic PECI hwmon function to which controller has
> PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
> specific hardware. Should I remove this or any suggestion?
>
I don't really know enough about the system to make a recommendation.
It seems to me that the PECI core should identify which functionality
it supports and instantiate the necessary driver(s). Maybe there should
be sub-nodes to the peci node with relevant information. Those sub-nodes
should specify the supported functionality in more detail, though -
such as indicating the supported CPU and/or DIMM sensors.
Guenter
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Adam Ford @ 2018-01-11 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5832fd62-16aa-e167-7e52-2ce493e33cdc@lechnology.com>
On Thu, Jan 11, 2018 at 3:04 PM, David Lechner <david@lechnology.com> wrote:
> On 01/11/2018 02:58 PM, Adam Ford wrote:
>>
>> On Thu, Jan 11, 2018 at 2:04 PM, David Lechner <david@lechnology.com>
>> wrote:
>>>
>>> On 01/11/2018 12:50 PM, Adam Ford wrote:
>>>>
>>>>
>>>> On Thu, Jan 11, 2018 at 12:29 PM, David Lechner <david@lechnology.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> If removing the "clk_ignore_unused" option causes the board to not
>>>>> boot,
>>>>> then we still have problems that need to be fixed, so please also test
>>>>> without this option.
>>>>
>>>>
>>>>
>>>> Without this option, it still does not boot. Without device tree it
>>>> hangs after:
>>>>
>>>> [snip]
>>>>
>>>> NET: Registered protocol family 17
>>>> Loading compiled-in X.509 certificates
>>>> console [netcon0] enabled
>>>> netconsole: network logging started
>>>> davinci_emac davinci_emac.1: using random MAC addr: 5e:38:1a:1f:4f:77
>>>> mmc0: host does not support reading read-only switch, assuming
>>>> write-enable
>>>> hctosys: unable to open rtc device (rtc0)
>>>> mmc0: new high speed SDHC card at address b368
>>>>
>>>>
>>>> With device tree it hangs after:
>>>>
>>>> [snip]
>>>> mmc0: host does not support reading read-only switch, assuming
>>>> write-enable
>>>> mmc0: new high speed SDHC card at address b368
>>>> mmcblk0: mmc0:b368 00000 3.75 GiB
>>>> mmcblk0: p1 p2
>>>> pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
>>>> pca953x 0-0020: failed reading register
>>>> pca953x: probe of 0-0020 failed with error -121
>>>> console [netcon0] enabled
>>>> netconsole: network logging started
>>>> davinci_emac 1e20000.ethernet: incompatible machine/device type for
>>>> reading mac address
>>>> hctosys: unable to open rtc device (rtc0)
>>>>
>>>>
>>>
>>> Please try this change:
>>>
>>> diff --git a/drivers/clk/davinci/psc-da850.c
>>> b/drivers/clk/davinci/psc-da850.c
>>> index 3fd6b49..a526cc2 100644
>>> --- a/drivers/clk/davinci/psc-da850.c
>>> +++ b/drivers/clk/davinci/psc-da850.c
>>> @@ -17,7 +17,7 @@ static const struct davinci_psc_clk_info
>>> da850_psc0_info[]
>>> __initconst = {
>>> LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>> LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>> LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>>> - LPSC(3, 0, aemif, pll0_sysclk3, 0),
>>> + LPSC(3, 0, aemif, pll0_sysclk3, LPSC_ALWAYS_ENABLED),
>>> LPSC(4, 0, spi0, pll0_sysclk2, 0),
>>> LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
>>> LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
>>>
>>>
>>>
>>> If that does not work, try adding LPSC_ALWAYS_ENABLED to all of the
>>> clocks
>>> in this file and then eliminate them one by one until you find which one
>>> is
>>> preventing boot.
>>>
>> Unfortunately, that didn't work. I switch all the entries in both
>> tables that had a 0 to LPSC_ALWAYS_ENABLED, but no luck booting.
>>
>>> If it still does not boot, there is a similar DIVCLK_ALWAYS_ENABLED flag
>>> in
>>> drivers/clk/davinci/pll-da850.c that you can repeat the exercise with.
>>> Add
>>> DIVCLK_ALWAYS_ENABLED to all of the clocks there and then eliminate it
>>> one
>>> by one until you find the clock that is causing the problem.
>>
>>
>> Still no good news. I switched all the entries with a 0 to
>> DIVCLK_ALWAYS_ENABLED and it still didn't finish booting.
>>
>> I wonder if Sekhar Nori might have some suggestions. I didn't look at
>> the code or try to understand it. I just changed the settings.
>>>
>>>
>
> Even if a clock had another flag besides zero, you will need to add
> LPSC_ALWAYS_ENABLED by or-ing it with the other flag.
>
[snip]
Thanks for clarifying. I was able to make it work with the following patch:
diff --git a/drivers/clk/davinci/psc-da850.c b/drivers/clk/davinci/psc-da850.c
index 3b4583d..a76b8682 100644
--- a/drivers/clk/davinci/psc-da850.c
+++ b/drivers/clk/davinci/psc-da850.c
@@ -25,7 +25,7 @@ static const struct davinci_psc_clk_info
da850_psc0_info[] __initconst = {
LPSC(9, 0, uart0, pll0_sysclk2, 0),
LPSC(13, 0, pruss, pll0_sysclk2, 0),
LPSC(14, 0, arm, pll0_sysclk6, LPSC_ALWAYS_ENABLED),
- LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET),
+ LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET |
LPSC_ALWAYS_ENABLED),
{ }
};
If you have an updated patch series with those two fixes, I add my
name to the tested-by list.
>
>
[snip]
>
^ permalink raw reply related
* [PATCH -next] IIO: ADC: fix return value check in stm32_dfsdm_adc_probe()
From: Dan Carpenter @ 2018-01-11 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515669161-125426-1-git-send-email-weiyongjun1@huawei.com>
On Thu, Jan 11, 2018 at 11:12:41AM +0000, Wei Yongjun wrote:
> In case of error, the function devm_iio_device_alloc() returns NULL
> pointer not ERR_PTR(). The IS_ERR() test in the return value check
> should be replaced with NULL test.
>
> Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/iio/adc/stm32-dfsdm-adc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
> index e628d04..5e87140 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -1100,9 +1100,9 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
> dev_data = (const struct stm32_dfsdm_dev_data *)of_id->data;
>
> iio = devm_iio_device_alloc(dev, sizeof(*adc));
> - if (IS_ERR(iio)) {
> + if (!iio) {
> dev_err(dev, "%s: Failed to allocate IIO\n", __func__);
> - return PTR_ERR(iio);
> + return -ENOMEM;
> }
>
> adc = iio_priv(iio);
^^^^^^^^^^^^^^^^^^
This one doesn't return an error pointer either. The check causes a
static check warning for me. (It can't actually fail, though so maybe
it will return an error pointer in the future?)
regards,
dan carpenter
^ permalink raw reply
* [PATCH v5 09/44] dt-bindings: clock: New bindings for TI Davinci PSC
From: Rob Herring @ 2018-01-11 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515377863-20358-10-git-send-email-david@lechnology.com>
On Sun, Jan 07, 2018 at 08:17:08PM -0600, David Lechner wrote:
> This adds a new binding for the Power Sleep Controller (PSC) for the
> mach-davinci family of processors.
>
> Note: Although TI Keystone has a very similar PSC, we are not using the
> existing bindings. Keystone is using a legacy one-node-per-clock binding
> (actually two nodes if you count the separate reset binding for the same
> IP block). Also, some davinci LPSCs have quirks that aren't handled by
> the keystone bindings, so we would be adding one compatible string per
> clock with quirks instead of just a new compatible string for each
> controller.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> .../devicetree/bindings/clock/ti/davinci/psc.txt | 47 ++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/ti/davinci/psc.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Mathieu Poirier @ 2018-01-11 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111112835.1511702c2e6ba0077af4112e@arm.com>
On 11 January 2018 at 10:28, Kim Phillips <kim.phillips@arm.com> wrote:
> On Thu, 11 Jan 2018 08:45:21 -0700
> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>
>> On 11 January 2018 at 05:23, Mark Brown <broonie@kernel.org> wrote:
>> > On Wed, Jan 10, 2018 at 06:08:21PM -0600, Kim Phillips wrote:
>> >> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>> >
>> >> > Instructions on how to build and install the openCSD library are provided
>> >> > in the HOWTO.md of the project repository.
>> >
>> >> Usually when a perf builder sees something they need "on," they - or,
>> >> at least I - start querying the host's package manager for something
>> >> that provides it (e.g., apt search/install libopencsd), but since no
>> >> distro provides libopencsd, this is bad because it misleads the user.
>> >
>> > It's on the radar to push this at distros fairly soon.
>
> Adding packages to distros takes years, this patchset is being
> submitted for inclusion *now*. So until then, it would greatly
> facilitate users if the relevant libopencsd source files were
> self-contained within perf from the get go.
I do not agree with you on the front that it takes years. On the flip
side it would take a significant amount of time and effort to refactor
the openCSD library so that it can be added to the kernel tree. This
patchset is available now with a solution that follows what has
already been done for dozens of other external library. There is no
point in delaying the inclusion of the functionality when an
end-to-end solution exists.
>
>> > Part of the
>> > discussion was wanting to get things to the point where the tools using
>> > the library were far enough along that we could be reasonably sure that
>
> Curious, what other tools are there?
Ask around at ARM.
>
>> > there weren't any problems that were going to require ABI breaks to fix
>> > before pushing the library at distros since ABI churn isn't nice for
>> > packagers to deal with.
>
> Why make perf the guinea pig? Whatever, this doesn't preclude
> adding the code into the tree; it can be removed years from now when
> libopencsd becomes ubiquitous among distros.
The same can be said about proceeding the other way around - the
openCSD library can be added to the kernel tree later if it is deemed
necessary. Until then I really don't see why we'd prevent people from
accessing the functionality.
>
>> > There's also a bit of a chicken and egg problem
>> > in that it's a lot easier to get distros to package libraries that have
>> > users available (some are not really bothered about this of course but
>> > it still helps).
>>
>> Moreover including in the kernel tree every library that can
>> potentially be used by the perf tools simply doesn't scale.
>
> This is a trace decoder library we're talking about: there are no
> others in perf's system features autodetection list. And why wouldn't
> adding such libraries scale?
I don't see why a decoder library and say, libelf, need to be treated
differently.
>
>> The perf
>> tools project has come up with a very cleaver way to deal with
>> external dependencies and I don't see why the OpenCSD library should
>> be different.
>
> Again, the opencsd library is a decoder library: this patchseries adds
> it as a package dependency (when it isn't even a package in any
> distro), and it's different in that it's the first decoder library to
> be submitted as an external dependency (i.e., not fully built-in, like
> Intel's, or even the Arm SPE's pending submission).
I don't see why we absolutely need to do exactly the same as Intel.
The library is public and this patchset neatly integrates it with the
perf tools.
>
>> >> Keeping the library external will also inevitably introduce more
>> >> source level synchronization problems because the perf sources being
>> >> built may not be compatible with their version of the library, whether
>> >> due to new features like new trace hardware support, or API changes.
>> >
>> > Perf users installing from source rather than from a package (who do
>> > tend to the more technical side even for kernel developers) already have
>> > to cope with potentially installing at least dwarf, gtk2, libaudit,
>> > libbfd, libelf, libnuma, libperl, libpython, libslang, libcrypto,
>> > libunwind, libdw-dwarf-unwind, zlib, lzma, bpf and OpenJDK depending on
>> > which features they want. I'm not sure that adding one more library is
>> > going to be the end of the world here, especially once the packaging
>> > starts to filter through distros. Until that happens at least people
>> > are no worse off for not having the feature.
>>
>> I completely agree. Just like any other package, people that want the
>> very latest code need to install from source.
>
> A fully-integrated solution would work better for people, e.g., how are
> people supposed to know what 'latest' is when there are separate,
> unsynchronized git repos?
The same applies to any of the other libraries perf is working with.
>
>> >> As Mark Brown (cc'd) mentioned on the Coresight mailing list, this may
>> >> be able to be done the same way the dtc is incorporated into the
>> >> kernel, where only its relevant sources are included and updated as
>> >> needed: see linux/scripts/dtc/update-dtc-source.sh.
>> >
>> > Bear in mind that we need dtc for essentially all kernel development on
>> > ARM and when it was introduced it was a new requirement for existing
>> > systems, it's a bit of a different case here where it's an optional
>> > feature in an optional tool.
>
> That argument applies to Intel-PT, yet its decoder is self-contained
> within perf: all non-x86 perf binaries are capable of decoding PT.
> We'd want that for Arm Coresight where perf gets statically built to
> run on much more constrained systems like Android.
Traces can't be decoded properly without the support of external
libraries, whether we are talking about PT or CS.
>
> Or are you referring to the higher level linux/scripts/ location of the
> dtc? That's not my point: the libopencsd sources can live under
> somewhere like linux/tools/.
>
> Kim
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: David Lechner @ 2018-01-11 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7x+EtQs6NHAYbVga7vU1U+qQLqOxdf+1MW6HewaT+ZF_Xg@mail.gmail.com>
On 01/11/2018 02:58 PM, Adam Ford wrote:
> On Thu, Jan 11, 2018 at 2:04 PM, David Lechner <david@lechnology.com> wrote:
>> On 01/11/2018 12:50 PM, Adam Ford wrote:
>>>
>>> On Thu, Jan 11, 2018 at 12:29 PM, David Lechner <david@lechnology.com>
>>> wrote:
>>>>
>>>> If removing the "clk_ignore_unused" option causes the board to not boot,
>>>> then we still have problems that need to be fixed, so please also test
>>>> without this option.
>>>
>>>
>>> Without this option, it still does not boot. Without device tree it
>>> hangs after:
>>>
>>> [snip]
>>>
>>> NET: Registered protocol family 17
>>> Loading compiled-in X.509 certificates
>>> console [netcon0] enabled
>>> netconsole: network logging started
>>> davinci_emac davinci_emac.1: using random MAC addr: 5e:38:1a:1f:4f:77
>>> mmc0: host does not support reading read-only switch, assuming
>>> write-enable
>>> hctosys: unable to open rtc device (rtc0)
>>> mmc0: new high speed SDHC card at address b368
>>>
>>>
>>> With device tree it hangs after:
>>>
>>> [snip]
>>> mmc0: host does not support reading read-only switch, assuming
>>> write-enable
>>> mmc0: new high speed SDHC card at address b368
>>> mmcblk0: mmc0:b368 00000 3.75 GiB
>>> mmcblk0: p1 p2
>>> pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
>>> pca953x 0-0020: failed reading register
>>> pca953x: probe of 0-0020 failed with error -121
>>> console [netcon0] enabled
>>> netconsole: network logging started
>>> davinci_emac 1e20000.ethernet: incompatible machine/device type for
>>> reading mac address
>>> hctosys: unable to open rtc device (rtc0)
>>>
>>>
>>
>> Please try this change:
>>
>> diff --git a/drivers/clk/davinci/psc-da850.c
>> b/drivers/clk/davinci/psc-da850.c
>> index 3fd6b49..a526cc2 100644
>> --- a/drivers/clk/davinci/psc-da850.c
>> +++ b/drivers/clk/davinci/psc-da850.c
>> @@ -17,7 +17,7 @@ static const struct davinci_psc_clk_info da850_psc0_info[]
>> __initconst = {
>> LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
>> - LPSC(3, 0, aemif, pll0_sysclk3, 0),
>> + LPSC(3, 0, aemif, pll0_sysclk3, LPSC_ALWAYS_ENABLED),
>> LPSC(4, 0, spi0, pll0_sysclk2, 0),
>> LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
>> LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
>>
>>
>>
>> If that does not work, try adding LPSC_ALWAYS_ENABLED to all of the clocks
>> in this file and then eliminate them one by one until you find which one is
>> preventing boot.
>>
> Unfortunately, that didn't work. I switch all the entries in both
> tables that had a 0 to LPSC_ALWAYS_ENABLED, but no luck booting.
>
>> If it still does not boot, there is a similar DIVCLK_ALWAYS_ENABLED flag in
>> drivers/clk/davinci/pll-da850.c that you can repeat the exercise with. Add
>> DIVCLK_ALWAYS_ENABLED to all of the clocks there and then eliminate it one
>> by one until you find the clock that is causing the problem.
>
> Still no good news. I switched all the entries with a 0 to
> DIVCLK_ALWAYS_ENABLED and it still didn't finish booting.
>
> I wonder if Sekhar Nori might have some suggestions. I didn't look at
> the code or try to understand it. I just changed the settings.
>>
Even if a clock had another flag besides zero, you will need to add
LPSC_ALWAYS_ENABLED by or-ing it with the other flag.
diff --git a/drivers/clk/davinci/psc-da850.c b/drivers/clk/davinci/psc-da850.c
index 3fd6b49..3375df6a1 100644
--- a/drivers/clk/davinci/psc-da850.c
+++ b/drivers/clk/davinci/psc-da850.c
@@ -17,38 +17,38 @@ static const struct davinci_psc_clk_info da850_psc0_info[] __initconst = {
LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
- LPSC(3, 0, aemif, pll0_sysclk3, 0),
- LPSC(4, 0, spi0, pll0_sysclk2, 0),
- LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
+ LPSC(3, 0, aemif, pll0_sysclk3, LPSC_ALWAYS_ENABLED),
+ LPSC(4, 0, spi0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(5, 0, mmcsd0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
LPSC(7, 0, arm_rom, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
- LPSC(9, 0, uart0, pll0_sysclk2, 0),
- LPSC(13, 0, pruss, pll0_sysclk2, 0),
+ LPSC(9, 0, uart0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(13, 0, pruss, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
LPSC(14, 0, arm, pll0_sysclk6, LPSC_ALWAYS_ENABLED),
- LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET),
+ LPSC(15, 1, dsp, pll0_sysclk1, LPSC_FORCE | LPSC_LOCAL_RESET | LPSC_ALWAYS_ENABLED),
{ }
};
static const struct davinci_psc_clk_info da850_psc1_info[] __initconst = {
LPSC(0, 0, tpcc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
- LPSC(1, 0, usb0, pll0_sysclk2, 0),
- LPSC(2, 0, usb1, pll0_sysclk4, 0),
- LPSC(3, 0, gpio, pll0_sysclk4, 0),
- LPSC(5, 0, emac, pll0_sysclk4, 0),
+ LPSC(1, 0, usb0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(2, 0, usb1, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
+ LPSC(3, 0, gpio, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
+ LPSC(5, 0, emac, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
LPSC(6, 0, emif3, pll0_sysclk5, LPSC_ALWAYS_ENABLED),
- LPSC(7, 0, mcasp0, async3, 0),
- LPSC(8, 0, sata, pll0_sysclk2, LPSC_FORCE),
- LPSC(9, 0, vpif, pll0_sysclk2, 0),
- LPSC(10, 0, spi1, async3, 0),
- LPSC(11, 0, i2c1, pll0_sysclk4, 0),
- LPSC(12, 0, uart1, async3, 0),
- LPSC(13, 0, uart2, async3, 0),
- LPSC(14, 0, mcbsp0, async3, 0),
- LPSC(15, 0, mcbsp1, async3, 0),
- LPSC(16, 0, lcdc, pll0_sysclk2, 0),
- LPSC(17, 0, ehrpwm, async3, 0),
- LPSC(18, 0, mmcsd1, pll0_sysclk2, 0),
- LPSC(20, 0, ecap, async3, 0),
+ LPSC(7, 0, mcasp0, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(8, 0, sata, pll0_sysclk2, LPSC_FORCE | LPSC_ALWAYS_ENABLED),
+ LPSC(9, 0, vpif, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(10, 0, spi1, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(11, 0, i2c1, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
+ LPSC(12, 0, uart1, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(13, 0, uart2, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(14, 0, mcbsp0, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(15, 0, mcbsp1, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(16, 0, lcdc, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(17, 0, ehrpwm, async3, LPSC_ALWAYS_ENABLED),
+ LPSC(18, 0, mmcsd1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
+ LPSC(20, 0, ecap, async3, LPSC_ALWAYS_ENABLED),
LPSC(21, 0, tptc2, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
{ }
};
diff --git a/drivers/clk/davinci/pll-da850.c b/drivers/clk/davinci/pll-da850.c
index 77a7223..f334e69 100644
--- a/drivers/clk/davinci/pll-da850.c
+++ b/drivers/clk/davinci/pll-da850.c
@@ -22,21 +22,21 @@
static const struct davinci_pll_divclk_info
da850_pll0_divclk_info[] __initconst = {
- DIVCLK(1, pll0_sysclk1, pll0, DIVCLK_FIXED_DIV),
- DIVCLK(2, pll0_sysclk2, pll0, DIVCLK_FIXED_DIV),
- DIVCLK(3, pll0_sysclk3, pll0, 0),
- DIVCLK(4, pll0_sysclk4, pll0, DIVCLK_FIXED_DIV),
- DIVCLK(5, pll0_sysclk5, pll0, 0),
- DIVCLK(6, pll0_sysclk6, pll0, DIVCLK_ARM_RATE | DIVCLK_FIXED_DIV),
- DIVCLK(7, pll0_sysclk7, pll0, 0),
+ DIVCLK(1, pll0_sysclk1, pll0, DIVCLK_FIXED_DIV | DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(2, pll0_sysclk2, pll0, DIVCLK_FIXED_DIV | DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(3, pll0_sysclk3, pll0, DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(4, pll0_sysclk4, pll0, DIVCLK_FIXED_DIV | DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(5, pll0_sysclk5, pll0, DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(6, pll0_sysclk6, pll0, DIVCLK_ARM_RATE | DIVCLK_FIXED_DIV| DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(7, pll0_sysclk7, pll0, DIVCLK_ALWAYS_ENABLED),
{ }
};
static const struct davinci_pll_divclk_info
da850_pll1_divclk_info[] __initconst = {
DIVCLK(1, pll1_sysclk1, pll1, DIVCLK_ALWAYS_ENABLED),
- DIVCLK(2, pll1_sysclk2, pll1, 0),
- DIVCLK(3, pll1_sysclk3, pll1, 0),
+ DIVCLK(2, pll1_sysclk2, pll1, DIVCLK_ALWAYS_ENABLED),
+ DIVCLK(3, pll1_sysclk3, pll1, DIVCLK_ALWAYS_ENABLED),
{ }
};
^ permalink raw reply related
* [PATCH] ARM: dts: iwg22m: Enable cmt0
From: Fabrizio Castro @ 2018-01-11 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515704379-29154-1-git-send-email-fabrizio.castro@bp.renesas.com>
This patch enables cmt0 support from within the iwg22m SoM dtsi.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7745-iwg22m.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
index ed9a8cf..8d0a392b 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
+++ b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
@@ -29,6 +29,10 @@
};
};
+&cmt0 {
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <20000000>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: iwg20m: Enable cmt0
From: Fabrizio Castro @ 2018-01-11 20:59 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables cmt0 support from within the iwg20m SoM dtsi.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
index 75a8ca5..1d3e950 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
@@ -34,6 +34,10 @@
};
};
+&cmt0 {
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <20000000>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Adam Ford @ 2018-01-11 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a79184c5-3e28-bbac-0783-992615d49fae@lechnology.com>
On Thu, Jan 11, 2018 at 2:04 PM, David Lechner <david@lechnology.com> wrote:
> On 01/11/2018 12:50 PM, Adam Ford wrote:
>>
>> On Thu, Jan 11, 2018 at 12:29 PM, David Lechner <david@lechnology.com>
>> wrote:
>>>
>>> If removing the "clk_ignore_unused" option causes the board to not boot,
>>> then we still have problems that need to be fixed, so please also test
>>> without this option.
>>
>>
>> Without this option, it still does not boot. Without device tree it
>> hangs after:
>>
>> [snip]
>>
>> NET: Registered protocol family 17
>> Loading compiled-in X.509 certificates
>> console [netcon0] enabled
>> netconsole: network logging started
>> davinci_emac davinci_emac.1: using random MAC addr: 5e:38:1a:1f:4f:77
>> mmc0: host does not support reading read-only switch, assuming
>> write-enable
>> hctosys: unable to open rtc device (rtc0)
>> mmc0: new high speed SDHC card at address b368
>>
>>
>> With device tree it hangs after:
>>
>> [snip]
>> mmc0: host does not support reading read-only switch, assuming
>> write-enable
>> mmc0: new high speed SDHC card at address b368
>> mmcblk0: mmc0:b368 00000 3.75 GiB
>> mmcblk0: p1 p2
>> pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
>> pca953x 0-0020: failed reading register
>> pca953x: probe of 0-0020 failed with error -121
>> console [netcon0] enabled
>> netconsole: network logging started
>> davinci_emac 1e20000.ethernet: incompatible machine/device type for
>> reading mac address
>> hctosys: unable to open rtc device (rtc0)
>>
>>
>
> Please try this change:
>
> diff --git a/drivers/clk/davinci/psc-da850.c
> b/drivers/clk/davinci/psc-da850.c
> index 3fd6b49..a526cc2 100644
> --- a/drivers/clk/davinci/psc-da850.c
> +++ b/drivers/clk/davinci/psc-da850.c
> @@ -17,7 +17,7 @@ static const struct davinci_psc_clk_info da850_psc0_info[]
> __initconst = {
> LPSC(0, 0, tpcc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
> LPSC(1, 0, tptc0, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
> LPSC(2, 0, tptc1, pll0_sysclk2, LPSC_ALWAYS_ENABLED),
> - LPSC(3, 0, aemif, pll0_sysclk3, 0),
> + LPSC(3, 0, aemif, pll0_sysclk3, LPSC_ALWAYS_ENABLED),
> LPSC(4, 0, spi0, pll0_sysclk2, 0),
> LPSC(5, 0, mmcsd0, pll0_sysclk2, 0),
> LPSC(6, 0, aintc, pll0_sysclk4, LPSC_ALWAYS_ENABLED),
>
>
>
> If that does not work, try adding LPSC_ALWAYS_ENABLED to all of the clocks
> in this file and then eliminate them one by one until you find which one is
> preventing boot.
>
Unfortunately, that didn't work. I switch all the entries in both
tables that had a 0 to LPSC_ALWAYS_ENABLED, but no luck booting.
> If it still does not boot, there is a similar DIVCLK_ALWAYS_ENABLED flag in
> drivers/clk/davinci/pll-da850.c that you can repeat the exercise with. Add
> DIVCLK_ALWAYS_ENABLED to all of the clocks there and then eliminate it one
> by one until you find the clock that is causing the problem.
Still no good news. I switched all the entries with a 0 to
DIVCLK_ALWAYS_ENABLED and it still didn't finish booting.
I wonder if Sekhar Nori might have some suggestions. I didn't look at
the code or try to understand it. I just changed the settings.
>
adam
^ 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