* [PATCH v2] ARM: avoid Cortex-A9 livelock on tight dmb loops
From: Tony Lindgren @ 2018-06-01 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601155502.GB6920@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [180601 15:57]:
> On Fri, Jun 01, 2018 at 08:35:12AM -0700, Tony Lindgren wrote:
> > CONFIG_KERNEL_LZMA fails:
> >
> > Try gzip decompression.
> > Try LZMA decompression.
> > lzma_decompress_file: read on /boot/zImage of 65536 bytes failed
> > kernel: 0xb6abb010 kernel_size: 0x43d0f0
> > MEMORY RANGES
> > 0000000080000000-00000000bfdfffff (0)
> > zImage header: 0x016f2818 0x00000000 0x0043d0f0
> > zImage size 0x43d0f0, file size 0x43d0f0
> > Reserved memory ranges
>
> This looks like an old kexec binary as it's missing the output from:
>
> dbgprintf("zImage requires 0x%08llx bytes\n", (unsigned long long)len);
>
> Please can you test with the current version - the official
> repository should now be up to date with my version. Thanks.
OK great. After updating kexec-tools to latest git veresion LZMA
crashkernel now also boots for me :)
Regards,
Tony
^ permalink raw reply
* [RFC PATCH 1/8] dts: binding: coresight: Document graph bindings
From: Mathieu Poirier @ 2018-06-01 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527858967-16047-2-git-send-email-suzuki.poulose@arm.com>
On Fri, Jun 01, 2018 at 02:16:00PM +0100, Suzuki K Poulose wrote:
> Before we updat the bindings, document the current graph bindings
s/updat/update
> and usage of additional properties.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> .../devicetree/bindings/arm/coresight.txt | 28 ++++++++++++++++++----
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
> index 15ac8e8..bd36e40 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -52,9 +52,7 @@ its hardware characteristcs.
> clocks the core of that coresight component. The latter clock
> is optional.
>
> - * port or ports: The representation of the component's port
> - layout using the generic DT graph presentation found in
> - "bindings/graph.txt".
> + * port or ports: see "Graph bindings for Coresight" below
>
> * Additional required properties for System Trace Macrocells (STM):
> * reg: along with the physical base address and length of the register
> @@ -71,7 +69,7 @@ its hardware characteristcs.
> AMBA markee):
> - "arm,coresight-replicator"
>
> - * port or ports: same as above.
> + * port or ports: see "Graph bindings for Coresight" below.
>
> * Optional properties for ETM/PTMs:
>
> @@ -86,6 +84,28 @@ its hardware characteristcs.
> * arm,buffer-size: size of contiguous buffer space for TMC ETR
> (embedded trace router)
>
> +Graph bindings for Coresight
> +-------------------------------
> +
> +Coresight components are interconnected to create a data path for the flow of
> +trace data generated from the "sources" to their collection points "sink". Each
Over 80 characters.
> +coresight component must describe the "input" and "output" connections.
> +The connections must be described via generic DT graph bindings as described
> +by the "bindings/graph.txt", where each "port" along with an "endpoint" component
Same here.
> +represents a hardware port and the connection.
> +
> +Since it is possible to have multiple connections for any coresight component with
And here.
> +a specific direction of data flow, each connection must define the following
> +properties to uniquely identify the connection details.
> +
> + * Direction of the data flow w.r.t the component :
> + Each input port must have the following property defined at the "endpoint"
> + for the port.
> + "slave-mode"
> +
> + * Hardware Port number at the component:
> + - The hardware port number is assumed to be the address of the "port" component.
And here.
Moveover this patches doesn't apply to my next tree.
> +
>
> Example:
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Chen-Yu Tsai @ 2018-06-01 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601152949.tmw7aitfoo536nxs@flea>
On Fri, Jun 1, 2018 at 8:29 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Thu, May 31, 2018 at 07:54:08PM +0200, Jernej ?krabec wrote:
>> Dne ?etrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
>> > On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
>> > > >> > > + if (tcon->quirks->needs_tcon_top) {
>> > > >> > > + struct device_node *np;
>> > > >> > > +
>> > > >> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top",
>> > > >> > > 0);
>> > > >> > > + if (np) {
>> > > >> > > + struct platform_device *pdev;
>> > > >> > > +
>> > > >> > > + pdev = of_find_device_by_node(np);
>> > > >> > > + if (pdev)
>> > > >> > > + tcon->tcon_top =
>> > > >> > > platform_get_drvdata(pdev);
>> > > >> > > + of_node_put(np);
>> > > >> > > +
>> > > >> > > + if (!tcon->tcon_top)
>> > > >> > > + return -EPROBE_DEFER;
>> > > >> > > + }
>> > > >> > > + }
>> > > >> > > +
>> > > >> >
>> > > >> > I might have missed it, but I've not seen the bindings additions for
>> > > >> > that property. This shouldn't really be done that way anyway, instead
>> > > >> > of using a direct phandle, you should be using the of-graph, with the
>> > > >> > TCON-top sitting where it belongs in the flow of data.
>> > > >>
>> > > >> Just to answer to the first question, it did describe it in "[PATCH
>> > > >> 07/15] dt- bindings: display: sun4i-drm: Add R40 HDMI pipeline".
>> > > >>
>> > > >> As why I designed it that way - HW representation could be described
>> > > >> that way> >>
>> > > >> (ASCII art makes sense when fixed width font is used to view it):
>> > > >> / LCD0/LVDS0
>> > > >>
>> > > >> / TCON-LCD0
>> > > >>
>> > > >> | \ MIPI DSI
>> > > >>
>> > > >> mixer0 |
>> > > >>
>> > > >> \ / TCON-LCD1 - LCD1/LVDS1
>> > > >>
>> > > >> TCON-TOP
>> > > >>
>> > > >> / \ TCON-TV0 - TVE0/RGB
>> > > >>
>> > > >> mixer1 | \
>> > > >>
>> > > >> | TCON-TOP - HDMI
>> > > >> |
>> > > >> | /
>> > > >>
>> > > >> \ TCON-TV1 - TVE1/RGB
>> > > >>
>> > > >> This is a bit simplified, since there is also TVE-TOP, which is
>> > > >> responsible
>> > > >> for sharing 4 DACs between both TVE encoders. You can have two TV outs
>> > > >> (PAL/ NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even
>> > > >> seems that you can arbitrarly choose which DAC is responsible for
>> > > >> which signal, so there is a ton of possible end combinations, but I'm
>> > > >> not 100% sure.
>> > > >>
>> > > >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
>> > > >> suggest more possibilities, although some of them seem wrong, like RGB
>> > > >> feeding from LCD TCON. That is confirmed to be wrong when checking BSP
>> > > >> code.
>> > > >>
>> > > >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and
>> > > >> LCD1 for pin muxing, although I'm not sure why is that needed at all,
>> > > >> since according to R40 datasheet, TVE0 and TVE1 pins are dedicated and
>> > > >> not on PORT D and PORT H, respectively, as TCON-TOP documentation
>> > > >> suggest. However, HSYNC and PSYNC lines might be shared between TVE
>> > > >> (when it works in RGB mode) and LCD. But that is just my guess since
>> > > >> I'm not really familiar with RGB and LCD interfaces.
>> > > >>
>> > > >> I'm really not sure what would be the best representation in OF-graph.
>> > > >> Can you suggest one?
>> > > >
>> > > > Rob might disagree on this one, but I don't see anything wrong with
>> > > > having loops in the graph. If the TCON-TOP can be both the input and
>> > > > output of the TCONs, then so be it, and have it described that way in
>> > > > the graph.
>> > > >
>> > > > The code is already able to filter out nodes that have already been
>> > > > added to the list of devices we need to wait for in the component
>> > > > framework, so that should work as well.
>> > > >
>> > > > And we'd need to describe TVE-TOP as well, even though we don't have a
>> > > > driver for it yet. That will simplify the backward compatibility later
>> > > > on.
>> > >
>> > > I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer that
>> > > binds everything together, and provides signal routing, kind of like
>> > > DE-TOP on A64. So the signal mux controls that were originally found
>> > > in TCON0 and TVE0 were moved out.
>> > >
>> > > The driver needs to know about that, but the graph about doesn't make
>> > > much sense directly. Without looking at the manual, I understand it to
>> > > likely be one mux between the mixers and TCONs, and one between the
>> > > TCON-TVs and HDMI. Would it make more sense to just have the graph
>> > > connections between the muxed components, and remove TCON-TOP from
>> > > it, like we had in the past? A phandle could be used to reference
>> > > the TCON-TOP for mux controls, in addition to the clocks and resets.
>> > >
>> > > For TVE, we would need something to represent each of the output pins,
>> > > so the device tree can actually describe what kind of signal, be it
>> > > each component of RGB/YUV or composite video, is wanted on each pin,
>> > > if any. This is also needed on the A20 for the Cubietruck, so we can
>> > > describe which pins are tied to the VGA connector, and which one does
>> > > R, G, or B.
>> >
>> > I guess we'll see how the DT maintainers feel about this, but my
>> > impression is that the OF graph should model the flow of data between
>> > the devices. If there's a mux somewhere, then the data is definitely
>> > going through it, and as such it should be part of the graph.
>>
>> I concur, but I spent few days thinking how to represent this sanely in graph,
>> but I didn't find any good solution. I'll represent here my idea and please
>> tell your opinion before I start implementing it.
>>
>> First, let me be clear that mixer0 and mixer1 don't have same capabilities
>> (different number of planes, mixer0 supports writeback, mixer1 does not,
>> etc.). Thus, it does matter which mixer is connected to which TCON/encoder.
>> mixer0 is meant to be connected to main display and mixer1 to auxiliary. That
>> obviously depends on end system.
>>
>> So, TCON TOP has 3 muxes, which have to be represented in graph. Two of them
>> are for mixer/TCON relationship (each of them 1 input and 4 possible outputs)
>> and one for TV TCON/HDMI pair selection (2 possible inputs, 1 output).
>>
>> According to current practice in sun4i-drm driver, graph has to have port 0,
>> representing input and port 1, representing output. This would mean that graph
>> looks something like that:
>>
>> tcon_top: tcon-top at 1c70000 {
>> compatible = "allwinner,sun8i-r40-tcon-top";
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> tcon_top_in: port at 0 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <0>;
>>
>> tcon_top_in_mixer0: endpoint at 0 {
>> reg = <0>;
>> remote-endpoint = <&mixer0_out_tcon_top>;
>> };
>>
>> tcon_top_in_mixer1: endpoint at 1 {
>> reg = <1>;
>> remote-endpoint = <&mixer1_out_tcon_top>;
>> };
>>
>> tcon_top_in_tcon_tv: endpoint at 2 {
>> reg = <2>;
>> // here is HDMI input connection, part of board DTS
>> remote-endpoint = <board specific phandle to TV TCON output>;
>> };
>> };
>>
>> tcon_top_out: port at 1 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <1>;
>>
>> tcon_top_out_tcon0: endpoint at 0 {
>> reg = <0>;
>> // here is mixer0 output connection, part of board DTS
>> remote-endpoint = <board specific phandle to TCON>;
>> };
>>
>> tcon_top_out_tcon1: endpoint at 1 {
>> reg = <1>;
>> // here is mixer1 output connection, part of board DTS
>> remote-endpoint = <board specific phandle to TCON>;
>> };
>>
>> tcon_top_out_hdmi: endpoint at 2 {
>> reg = <2>;
>> remote-endpoint = <&hdmi_in_tcon_top>;
>> };
>> };
>> };
>> };
>
> IIRC, each port is supposed to be one route for the data, so we would
> have multiple ports, one for the mixers in input and for the tcon in
> output, and one for the TCON in input and for the HDMI/TV in
> output. Rob might correct me here.
>
>> tcon_tv0: lcd-controller at 1c73000 {
>> compatible = "allwinner,sun8i-r40-tcon-tv-0";
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> tcon_tv0_in: port at 0 {
>> reg = <0>;
>>
>> tcon_tv0_in_tcon_top: endpoint {
>> // endpoint depends on board, part of board DTS
>> remote-endpoint = <phandle to one of tcon_top_out_tcon>;
>
> Just curious, what would be there?
>
>> };
>> };
>>
>> tcon_tv0_out: port at 1 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <1>;
>>
>> // endpoints to TV TOP and TCON TOP HDMI input
>> ...
>> };
>> };
>> };
>>
>> tcon_tv1: lcd-controller at 1c74000 {
>> compatible = "allwinner,sun8i-r40-tcon-tv-1";
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> tcon_tv1_in: port at 0 {
>> reg = <0>;
>>
>> tcon_tv1_in_tcon_top: endpoint {
>> // endpoint depends on board, part of board DTS
>> remote-endpoint = <phandle to one of tcon_top_out_tcon>;
>> };
>> };
>>
>> tcon_tv1_out: port at 1 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <1>;
>>
>> // endpoints to TV TOP and TCON TOP HDMI input
>> ...
>> };
>> };
>> };
>>
>> tcon_lcd0 and tcon_lcd1 would have similar connections, except that for
>> outputs would be LCD or LVDS panels or MIPI DSI encoder.
>>
>> Please note that each TCON (there are 4 of them) would need to have unique
>> compatible and have HW index stored in quirks data. It would be used by TCON
>> TOP driver for configuring muxes.
>
> Can't we use the port/endpoint ID instead? If the mux is the only
> thing that changes, the compatible has no reason to. It's the same IP,
> and the only thing that changes is something that is not part of that
> IP.
I agree. Endpoint IDs should provide that information. I'm still not
sure How to encode multiple in/out mux groups in a device node though.
ChenYu
^ permalink raw reply
* [PATCH 1/4] clk: renesas: cpg-mssr: Stop using printk format %pCr
From: Stephen Boyd @ 2018-06-01 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527845302-12159-2-git-send-email-geert+renesas@glider.be>
Quoting Geert Uytterhoeven (2018-06-01 02:28:19)
> Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
> called in atomic context.
>
> Replace it by open-coding the operation. This is safe here, as the code
> runs in task context.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
^ permalink raw reply
* [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Rob Herring @ 2018-06-01 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0d08ba26-77f2-6c42-8fb1-214aaf6085e9@t-chip.com.cn>
On Thu, May 31, 2018 at 9:05 PM, Levin <djw@t-chip.com.cn> wrote:
> Hi Rob,
>
>
> On 2018-05-31 10:45 PM, Rob Herring wrote:
>>
>> On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
>>>
>>> From: Levin Du <djw@t-chip.com.cn>
>>>
>>> In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
>>> mute control, can also be used for general purpose. It is manipulated by
>>> the GRF_SOC_CON10 register.
>>>
>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>
>>> ---
>>>
>>> Changes in v3:
>>> - Change from general gpio-syscon to specific rk3328-gpio-mute
>>>
>>> Changes in v2:
>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>
>>> Changes in v1:
>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>> - Add doc rockchip,gpio-syscon.txt
>>>
>>> .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28
>>> +++++++++++++++++++
>>> drivers/gpio/gpio-syscon.c | 31
>>> ++++++++++++++++++++++
>>> 2 files changed, 59 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>> new file mode 100644
>>> index 0000000..10bc632
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>> @@ -0,0 +1,28 @@
>>> +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE pin.
>>> +
>>> +In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
>>> mute
>>> +control, can also be used for general purpose. It is manipulated by the
>>> +GRF_SOC_CON10 register.
>>> +
>>> +Required properties:
>>> +- compatible: Should contain "rockchip,rk3328-gpio-mute".
>>> +- gpio-controller: Marks the device node as a gpio controller.
>>> +- #gpio-cells: Should be 2. The first cell is the pin number and
>>> + the second cell is used to specify the gpio polarity:
>>> + 0 = Active high,
>>> + 1 = Active low.
>>> +
>>> +Example:
>>> +
>>> + grf: syscon at ff100000 {
>>> + compatible = "rockchip,rk3328-grf", "syscon",
>>> "simple-mfd";
>>> +
>>> + gpio_mute: gpio-mute {
>>
>> Node names should be generic:
>>
>> gpio {
>>
>> This also means you can't add another GPIO node in the future and
>> you'll have to live with "rockchip,rk3328-gpio-mute" covering more
>> than 1 GPIO if you do need to add more GPIOs.
>
>
> As the first line describes, this GPIO controller is dedicated for the
> GPIO_MUTE pin.
> There's only one GPIO pin in the GRF_SOC_CON10 register. Therefore the
> gpio_mute
> name is proper IMHO.
It's how many GPIOs in the GRF, not this register. What I'm saying is
when you come along later to add another GPIO in the GRF, you had
better just add it to this same node. I'm not going to accept another
GPIO controller node within the GRF. You have the cells to support
more than 1, so it would only be a driver change. The compatible
string would then not be ideally named at that point. But compatible
strings are just unique identifiers, so it doesn't really matter what
the string is.
I'm being told both "this is the only GPIO" and "the GRF has too many
different functions for us to tell you what they all are". So which is
it?
Rob
^ permalink raw reply
* [PATCH 1/6] staging: vc04_services: no need to check debugfs return values
From: Eric Anholt @ 2018-06-01 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601111004.1670-1-gregkh@linuxfoundation.org>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Clean up the vchiq_arm code by not caring about the value of debugfs
> calls. This ends up removing a number of lines of code that are not
> needed.
This series is:
Reviewed-by: Eric Anholt <eric@anholt.net>
Thanks for the cleanups!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180601/d86564ed/attachment.sig>
^ permalink raw reply
* [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions
From: Stephen Boyd @ 2018-06-01 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9ca51832-6095-c8a5-1347-f57abf99e8f9@codeaurora.org>
Quoting Sricharan R (2018-06-01 06:20:37)
> Hi Stephen,
>
> On 5/31/2018 1:11 PM, Stephen Boyd wrote:
> >
> > Ok. One general comment is that it would be nice if the bindings for all
> > the nodes that are introduced included 'clocks' properties and also
> > maybe 'clock-names' properties for the clocks that are consumed by each
> > node. Right now, we hide those details from DT and rely on the string
> > names to hook the clk tree up for us. That sort of prevents us from
> > moving away from string easily, so I would just throw the clocks into
> > the binding right now and always have them there just in case we want to
> > use the binding to figure out the hierarchy in the future.
> >
>
> ok, understand that mostly. So will try to revamp those patches with
> the 'clocks' property in the binding added, reading them in the driver
> from DT.
Yeah. You don't even have to actually use the clocks property right now
from the drivers. Just add the properties in the binding.
^ permalink raw reply
* [GIT PULL] KVM/ARM updates for 4.18
From: Paolo Bonzini @ 2018-06-01 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601152747.23613-1-marc.zyngier@arm.com>
On 01/06/2018 17:27, Marc Zyngier wrote:
> Paolo, Radim,
>
> This is the set of updates for KVM/ARM for v4.18. This time, lazy
> context switching of the floating point registers for arm64, and the
> ability to deal with multiple redistributor ranges (which allows for
> larger numbers of vcpu).
>
> Note that some additional KVM/ARM updates will come via the arm64 tree
> with the SSBD patches. This will generate three conflicts that are
> pretty simple to resolve (-next has a good example of the resolution).
>
> Please pull,
>
> M.
>
> The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb:
>
> Linux 4.17-rc4 (2018-05-06 16:57:38 -1000)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-for-v4.18
>
> for you to fetch changes up to e25028c8ded011d19f9a11164807507c94febc01:
>
> KVM: arm/arm64: Bump VGIC_V3_MAX_CPUS to 512 (2018-05-25 12:29:27 +0100)
>
> ----------------------------------------------------------------
> KVM/ARM updates for 4.18
>
> - Lazy context-switching of FPSIMD registers on arm64
> - Allow virtual redistributors to be part of two or more MMIO ranges
Pulled, thanks.
Paolo
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Stephen Boyd @ 2018-06-01 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521115947.wqrnv2hczate65lz@flea>
Quoting Maxime Ripard (2018-05-21 04:59:47)
> Hi Mike, Stephen,
>
> Please merge the following changes for the next merge window, thanks!
>
Thanks. Pulled into clk-next.
^ permalink raw reply
* [PATCH 1/3] arm64: allwinner: a64: add R_I2C controller
From: Vasily Khoruzhick @ 2018-06-01 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601091631.wqctilk55fcmggwv@flea>
On Fri, Jun 1, 2018 at 2:16 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> Hi,
>
> On Thu, May 31, 2018 at 11:28:59PM -0700, Vasily Khoruzhick wrote:
>> From: Icenowy Zheng <icenowy@aosc.io>
>>
>> Allwinner A64 has a I2C controller, which is in the R_ MMIO zone and has
>> two groups of pinmuxes on PL bank, so it's called R_I2C.
>>
>> Add support for this I2C controller and the pinmux which doesn't conflict
>> with RSB.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>
> You should have your SoB there.
OK, will do.
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index 1b2ef28c42bd..b5e903ccf0ec 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -46,6 +46,7 @@
>> #include <dt-bindings/clock/sun8i-r-ccu.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> #include <dt-bindings/reset/sun50i-a64-ccu.h>
>> +#include <dt-bindings/reset/sun8i-r-ccu.h>
>>
>> / {
>> interrupt-parent = <&gic>;
>> @@ -655,6 +656,17 @@
>> #reset-cells = <1>;
>> };
>>
>> + r_i2c: i2c at 1f02400 {
>> + compatible = "allwinner,sun6i-a31-i2c";
>
> You should add an a64 compatible here
We don't have it for regular i2c, why should I add it here?
>> + reg = <0x01f02400 0x400>;
>> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&r_ccu CLK_APB0_I2C>;
>> + resets = <&r_ccu RST_APB0_I2C>;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> +
>> r_pio: pinctrl at 1f02c00 {
>> compatible = "allwinner,sun50i-a64-r-pinctrl";
>> reg = <0x01f02c00 0x400>;
>> @@ -670,6 +682,11 @@
>> pins = "PL0", "PL1";
>> function = "s_rsb";
>> };
>> +
>> + r_i2c_pins_a: i2c-a {
>> + pins = "PL8", "PL9";
>> + function = "s_i2c";
>> + };
>
> This should be ordered by alphabetical order
OK
> If this is the only muxing option, you can also add it to the i2c DT
> node.
It's not the only option, but other option conflicts with rsb. Should
I still add it to i2c DT node?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* [PATCH 2/3] dts: sunxi: A64: Add PWM controllers
From: Vasily Khoruzhick @ 2018-06-01 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601091816.klmc3nfzynxprcso@flea>
On Fri, Jun 1, 2018 at 2:18 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Thu, May 31, 2018 at 11:29:00PM -0700, Vasily Khoruzhick wrote:
>> From: Andre Przywara <andre.przywara@arm.com>
>>
>> The Allwinner A64 SoC features two PWM controllers, which are fully
>> compatible to the one used in the A13 and H3 chips.
>>
>> Add the nodes for the devices (one for the "normal" PWM, the other for
>> the one in the CPUS domain) and the pins their outputs are connected to.
>>
>> On the A64 the "normal" PWM is muxed together with one of the MDIO pins
>> used to communicate with the Ethernet PHY, so it won't be usable on many
>> boards. But the Pinebook laptop uses this pin for controlling the LCD
>> backlight.
>>
>> On Pine64 the CPUS PWM pin however is routed to the "RPi2" header,
>> at the same location as the PWM pin on the RaspberryPi.
>>
>> [vasily: fixed comment message as requested by Stefan Bruens]
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> on Pinebook (only the "normal" PWM)
>> Tested-by: Harald Geyer <harald@ccbib.org> on Teres-I (only the "normal" PWM)
>
> Same thing, you should have your SoB there. And I'm not sure the
> Tested-by format is valid. This information would be better in the
> commit log itself.
OK
>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 28 +++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index b5e903ccf0ec..e94bfa8477f6 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -365,6 +365,11 @@
>> bias-pull-up;
>> };
>>
>> + pwm_pin: pwm_pin {
>> + pins = "PD22";
>> + function = "pwm";
>> + };
>> +
>
> Is there multiple options for that muxing? If not, add it to the PWM
> node by default.
OK
>
>> rmii_pins: rmii_pins {
>> pins = "PD10", "PD11", "PD13", "PD14", "PD17",
>> "PD18", "PD19", "PD20", "PD22", "PD23";
>> @@ -630,6 +635,15 @@
>> #interrupt-cells = <3>;
>> };
>>
>> + pwm: pwm at 1c21400 {
>> + compatible = "allwinner,sun50i-a64-pwm",
>> + "allwinner,sun5i-a13-pwm";
>> + reg = <0x01c21400 0x400>;
>> + clocks = <&osc24M>;
>> + #pwm-cells = <3>;
>> + status = "disabled";
>> + };
>> +
>> rtc: rtc at 1f00000 {
>> compatible = "allwinner,sun6i-a31-rtc";
>> reg = <0x01f00000 0x54>;
>> @@ -667,6 +681,15 @@
>> #size-cells = <0>;
>> };
>>
>> + r_pwm: pwm at 1f03800 {
>> + compatible = "allwinner,sun50i-a64-pwm",
>> + "allwinner,sun5i-a13-pwm";
>> + reg = <0x01f03800 0x400>;
>> + clocks = <&osc24M>;
>> + #pwm-cells = <3>;
>> + status = "disabled";
>> + };
>> +
>> r_pio: pinctrl at 1f02c00 {
>> compatible = "allwinner,sun50i-a64-r-pinctrl";
>> reg = <0x01f02c00 0x400>;
>> @@ -687,6 +710,11 @@
>> pins = "PL8", "PL9";
>> function = "s_i2c";
>> };
>> +
>> + r_pwm_pin: pwm {
>> + pins = "PL10";
>> + function = "s_pwm";
>> + };
>
> Ditto.
OK
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* [PATCH v3 1/2] arm64: allwinner: a64: Add RTC clock to phandle 32kHz external oscillator
From: Jagan Teki @ 2018-06-01 17:35 UTC (permalink / raw)
To: linux-arm-kernel
Outside of SOC few chips need external clock source
through RTC example Wifi chip. So RTC clock nodes to
phandle 32kHz external oscillator.
prefix rtc- with clock-output-names defined in
dt-binding to avoid confusion with existing osc32k name.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v3:
- squash of previous v2 patch
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..82516aec4153 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -634,6 +634,9 @@
reg = <0x01f00000 0x54>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
+ clocks = <&osc32k>;
+ #clock-cells = <1>;
};
r_intc: interrupt-controller at 1f00c00 {
--
2.14.3
^ permalink raw reply related
* [PATCH v3 2/2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Jagan Teki @ 2018-06-01 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601173527.18051-1-jagan@amarulasolutions.com>
Enable AP6330 WiFi/BT combo chip on Amarula A64-Relic board:
- WiFi SDIO interface is connected to MMC1
- WiFi WL-PMU-EN pin connected to gpio PL2: attach to mmc-pwrseq
- WiFi WL-WAKE-AP pin connected to gpio PL3
- 32kHz external oscillator gate clock from RTC
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v3:
- move dtsi change in separate patch
Changes for v2:
- Move external rtc clock nodes into main rtc node definition
of sun50i-a64.dtsi
.../dts/allwinner/sun50i-a64-amarula-relic.dts | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index ce4a256ff086..eac4793c8502 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -21,12 +21,43 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rtc 1>;
+ clock-names = "ext_clock";
+ reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
+ };
};
&ehci0 {
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_dcdc1>;
+ /*
+ * Schematic shows both dldo4 and eldo1 connected for vcc-io-wifi, but
+ * dldo4 connection shows DNP(Do Not Populate) and eldo1 connected with
+ * 0Ohm register to vcc-io-wifi so eldo1 is used.
+ */
+ vqmmc-supply = <®_eldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ brcmf: wifi at 1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&r_pio>;
+ interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
+ interrupt-names = "host-wake";
+ };
+};
+
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins>;
--
2.14.3
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: allwinner: add support for Pinebook
From: Vasily Khoruzhick @ 2018-06-01 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601092346.g2iixqupumn7xo7r@flea>
On Fri, Jun 1, 2018 at 2:23 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Thu, May 31, 2018 at 11:29:01PM -0700, Vasily Khoruzhick wrote:
>> From: Icenowy Zheng <icenowy@aosc.xyz>
>>
>> Pinebook is a A64-based laptop produced by Pine64, with the following
>> peripherals:
>>
>> USB:
>> - Two external USB ports (one is directly connected to A64's OTG
>> controller, the other is under a internal hub connected to the host-only
>> controller.)
>> - USB HID keyboard and touchpad connected to the internal hub.
>> - USB UVC camera connected to the internal hub.
>>
>> Power-related:
>> - A DC IN jack connected to AXP803's DCIN pin.
>> - A Li-Polymer battery connected to AXP803's battery pins.
>>
>> Storage:
>> - An eMMC by Foresee on the main board (in the product revision of the
>> main board it's designed to be switchable).
>> - An external MicroSD card slot.
>>
>> Display:
>> - An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
>> - A mini HDMI port.
>>
>> Misc:
>> - A Hall sensor designed to detect the status of lid, connected to GPIO PL12.
>> - A headphone jack connected to the SoC's internal codec.
>> - A debug UART port muxed with headphone jack.
>>
>> This commit adds basical support for it.
>>
>> [vasily: squashed several commits into one, added simplefb node, added usbphy
>> to ehci0 and ohci0 nodes]
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>> ---
>> arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> .../dts/allwinner/sun50i-a64-pinebook.dts | 285 ++++++++++++++++++
>> 2 files changed, 286 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
>> index 8bebe7da5ed9..a8c6d0c6f2c5 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> new file mode 100644
>> index 000000000000..d952db217702
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> @@ -0,0 +1,285 @@
>> +/*
>> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.xyz>
>> + * Copyright (C) 2018 Vasily Khoruzhick <anarsoul@gmail.com>
>> + *
>> + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
>
> The SPDX tag should be the first one.
OK, but it's not in number of other dts files, e.g.
sun50i-a64-teres-i.dts or sun50i-h5-orangepi-zero-plus.dts
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-a64.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pwm/pwm.h>
>> +
>> +/ {
>> + model = "Pinebook";
>> + compatible = "pine64,pinebook", "allwinner,sun50i-a64";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + ethernet0 = &rtl8723cs;
>> + };
>> +
>> + backlight: backlight {
>> + compatible = "pwm-backlight";
>> + pwms = <&pwm 0 50000 0>;
>> + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
>
> The perceived brightness should be increasing linearly. This usually
> means that you need an function close to a power of two sequence.
OK, I'll try, but no one complained so far.
>> + default-brightness-level = <2>;
>> + enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> +
>> + framebuffer-lcd {
>> + panel-supply = <®_dc1sw>;
>> + dvdd25-supply = <®_dldo2>;
>> + dvdd12-supply = <®_fldo1>;
>> + };
>> + };
>> +
>> + gpio_keys {
>> + compatible = "gpio-keys";
>> +
>> + lid_switch {
>> + label = "Lid Switch";
>> + gpios = <&r_pio 0 12 GPIO_ACTIVE_LOW>; /* PL12 */
>> + linux,input-type = <EV_SW>;
>> + linux,code = <SW_LID>;
>> + linux,can-disable;
>> + };
>> + };
>> +
>> + reg_vcc3v3: vcc3v3 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vcc3v3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + };
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>> + };
>> +};
>> +
>> +&ehci0 {
>> + phys = <&usbphy 0>;
>> + phy-names = "usb";
>> + status = "okay";
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins>;
>> + vmmc-supply = <®_dcdc1>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>> + cd-inverted;
>> + disable-wp;
>> + bus-width = <4>;
>> + status = "okay";
>> +};
>> +
>> +&mmc1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc1_pins>;
>> + vmmc-supply = <®_dldo4>;
>> + vqmmc-supply = <®_eldo1>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> + bus-width = <4>;
>> + non-removable;
>> + status = "okay";
>> +
>> + rtl8723cs: wifi at 1 {
>> + reg = <1>;
>> + };
>> +};
>> +
>> +&mmc2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc2_pins>;
>> + vmmc-supply = <®_dcdc1>;
>> + vqmmc-supply = <®_eldo1>;
>> + bus-width = <8>;
>> + non-removable;
>> + cap-mmc-hw-reset;
>> + mmc-hs200-1_8v;
>> + status = "okay";
>> +};
>> +
>> +&ohci0 {
>> + phys = <&usbphy 0>;
>> + phy-names = "usb";
>> + status = "okay";
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&pwm {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pwm_pin>;
>> + status = "okay";
>> +};
>> +
>> +&r_rsb {
>> + status = "okay";
>> +
>> + axp803: pmic at 3a3 {
>> + compatible = "x-powers,axp803";
>> + reg = <0x3a3>;
>> + interrupt-parent = <&r_intc>;
>> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> + };
>> +};
>> +
>> +/* The ANX6345 eDP-bridge is on r_i2c. There is no linux (mainline)
>> + * driver for this chip at the moment, the bootloader initializes it.
>> + * However it can be accessed with the i2c-dev driver from user space.
>> + */
>
> The comment format is wrong, and the part after r_i2c, about i2c-dev
> and the mainline support is not really relevant. The DT describes the
> hardware, and is used by several different projects that might or
> might not have i2c-dev, an interface similar, or might have or not a
> driver for the bridge.
Comment is identical to sun50i-a64-teres-i.dts (which was merged few
months ago).
I'll remove everything but first sentence.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* [PATCH 5/7] iommu/dma: add support for non-strict mode
From: kbuild test robot @ 2018-06-01 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527752569-18020-6-git-send-email-thunder.leizhen@huawei.com>
Hi Zhen,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc7 next-20180601]
[cannot apply to iommu/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Zhen-Lei/add-non-strict-mode-support-for-arm-smmu-v3/20180602-000418
config: x86_64-randconfig-x008-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers//iommu/amd_iommu.c: In function 'amd_iommu_capable':
>> drivers//iommu/amd_iommu.c:3053:2: warning: enumeration value 'IOMMU_CAP_NON_STRICT' not handled in switch [-Wswitch]
switch (cap) {
^~~~~~
vim +/IOMMU_CAP_NON_STRICT +3053 drivers//iommu/amd_iommu.c
645c4c8d arch/x86/kernel/amd_iommu.c Joerg Roedel 2008-12-02 3050
ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3051 static bool amd_iommu_capable(enum iommu_cap cap)
dbb9fd86 arch/x86/kernel/amd_iommu.c Sheng Yang 2009-03-18 3052 {
80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 @3053 switch (cap) {
80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 3054 case IOMMU_CAP_CACHE_COHERENCY:
ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3055 return true;
bdddadcb drivers/iommu/amd_iommu.c Joerg Roedel 2012-07-02 3056 case IOMMU_CAP_INTR_REMAP:
ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3057 return (irq_remapping_enabled == 1);
cfdeec22 drivers/iommu/amd_iommu.c Will Deacon 2014-10-27 3058 case IOMMU_CAP_NOEXEC:
cfdeec22 drivers/iommu/amd_iommu.c Will Deacon 2014-10-27 3059 return false;
80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 3060 }
80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 3061
ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3062 return false;
dbb9fd86 arch/x86/kernel/amd_iommu.c Sheng Yang 2009-03-18 3063 }
dbb9fd86 arch/x86/kernel/amd_iommu.c Sheng Yang 2009-03-18 3064
:::::: The code at line 3053 was first introduced by commit
:::::: 80a506b8fdcfa868bb53eb740f928217d0966fc1 x86/amd-iommu: Export cache-coherency capability
:::::: TO: Joerg Roedel <joerg.roedel@amd.com>
:::::: CC: Joerg Roedel <joerg.roedel@amd.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 28596 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180602/14d67fbb/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2 1/2] ARM: debug: Add Iproc UART3 debug addresses
From: Ray Jui @ 2018-06-01 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61a35071-4304-a25f-8c99-fe504b2c2346@gmail.com>
Sorry Florian, I had a couple issues with my email client yesterday and
I'm not sure if you have received my reply.
Please see my reply inline.
On 5/31/2018 3:16 PM, Florian Fainelli wrote:
>
>
> On 05/31/2018 10:24 AM, Ray Jui wrote:
>>
>>
>> On 5/31/2018 1:22 AM, Cl?ment P?ron wrote:
>>> Hi Rai,
>>>
>>> On Wed, 30 May 2018 at 19:25, Ray Jui <ray.jui@broadcom.com> wrote:
>>>>
>>>> Hi Cl?ment,
>>>>
>>>> Correct me if I'm wrong, but I thought the trend is to move to use
>>>> earlycon that can be activated from kernel command line for early print
>>>> before the serial driver is loaded.
>>>>
>>>> Have you tried earlcon?
>>> No, only tested this method.
>>>
>>> Thanks,
>>> Clement
>>>
>>
>> If I remember it correctly, I think the trend is to use earlycon. There
>> are obvious shortcomings by making this configuration compile time based.
>
> This is true, though on ARM 32-bit kernels DEBUG_LL gets used by the
> kernel self-decompressor and also before earlycon has a chance to run,
> this is useful to debugging memory issues where your memory
> configuration is incorrect typically.
>
This is true.
> Either way is fine with me (accepting or dropping) the patch, though
> there is probably minimal impact in just accepting such a change.
>
Will leave the decision to you then.
Thanks,
Ray
^ permalink raw reply
* [PATCH] arm: sun4i: Add support for Pengpod 1000 tablet
From: Bob Ham @ 2018-06-01 17:55 UTC (permalink / raw)
To: linux-arm-kernel
This is initial support for the Pengpod 1000 tablet. The display is
not currently working but the UART, SD card and USB all work fine.
Signed-off-by: Bob Ham <rah@settrans.net>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts | 232 +++++++++++++++++++++++++++
2 files changed, 233 insertions(+)
create mode 100644 arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ade7a38543dc..e6e93e7ffc8b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -893,6 +893,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb \
sun4i-a10-pcduino2.dtb \
+ sun4i-a10-pengpod-1000.dtb \
sun4i-a10-pov-protab2-ips9.dtb
dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-auxtek-t003.dtb \
diff --git a/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
new file mode 100644
index 000000000000..94560400114d
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
@@ -0,0 +1,232 @@
+/*
+ * Copyright 2015 Hans de Goede <hdegoede@redhat.com>
+ * Copyright 2017 Robert Ham <rah@settrans.net>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun4i-a10.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+ model = "PengPod 1000";
+ compatible = "pengpod,1000", "allwinner,sun4i-a10";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bl_en_pin_pengpod1000>;
+ pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&codec {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ axp209: pmic at 34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupts = <0>;
+ };
+};
+
+#include "axp209.dtsi"
+
+&i2c1 {
+ status = "okay";
+
+ mma7660: accelerometer at 4c {
+ compatible = "fsl,mma7660";
+ reg = <0x4c>;
+ };
+};
+
+&i2c2 {
+ status = "okay";
+
+ ft5406ee8: touchscreen at 38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ interrupt-parent = <&pio>;
+ interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&touchscreen_pins>;
+ reset-gpios = <&pio 1 13 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <1024>;
+ touchscreen-size-y = <600>;
+ touchscreen-swapped-x-y;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
+ cd-inverted;
+ status = "okay";
+};
+
+&pio {
+ bl_en_pin_pengpod1000: bl_en_pin at 0 {
+ pins = "PH7";
+ function = "gpio_out";
+ };
+
+ touchscreen_pins: touchscreen_pins at 0 {
+ pins = "PB13";
+ function = "gpio_out";
+ };
+
+ usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+ pins = "PH4";
+ function = "gpio_in";
+ bias-pull-up;
+ };
+
+ usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
+ pins = "PH5";
+ function = "gpio_in";
+ bias-pull-down;
+ };
+};
+
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ status = "okay";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1250000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+®_usb0_vbus {
+ status = "okay";
+};
+
+®_usb1_vbus {
+ status = "okay";
+};
+
+®_usb2_vbus {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+ usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+ usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_usb1_vbus>;
+ usb2_vbus-supply = <®_usb2_vbus>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] clk: bcm: Update and add tingray clock entries
From: Ray Jui @ 2018-06-01 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531162556.GA955@rob-hp-laptop>
Hi Rob,
On 5/31/2018 9:25 AM, Rob Herring wrote:
> On Fri, May 25, 2018 at 09:45:16AM -0700, Ray Jui wrote:
>> Update and add Stingray clock definitions and tables so they match the
>> binding document and the latest ASIC datasheet
>>
>> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>> ---
>> drivers/clk/bcm/clk-sr.c | 135 ++++++++++++++++++++++++++++++++-----
>> include/dt-bindings/clock/bcm-sr.h | 24 +++++--
>
> This goes in the 1st patch.
Please help to confirm. You want 1st patch and 2nd patch to be combined
into a single patch?
Thanks.
>
>> 2 files changed, 137 insertions(+), 22 deletions(-)
^ permalink raw reply
* [PATCH v2] clk: imx: Set CLK_SET_RATE_GATE for gate and divider clocks
From: Stephen Boyd @ 2018-06-01 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180418023214.GN25429@dragon>
Quoting Shawn Guo (2018-04-17 19:32:16)
> On Wed, Apr 11, 2018 at 05:03:29PM +0300, Abel Vesa wrote:
> > From: Shawn Guo <shawnguo@kernel.org>
> >
> > Add flag CLK_SET_RATE_GATE for i.MX gate and divider clocks on which the
> > client drivers usually make clk_set_rate() call, so that the call will fail
> > when clock is still on instead of standing the risk of running into glitch
> > issue. Rate cannot be changed when the clock is enabled due to the glitchy
> > multiplexers.
> >
> > Signed-off-by: Shawn Guo <shawnguo@kernel.org>
> > [initial patch from imx internal repo]
> > Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> > [carried over from 3.14 and also applied the flag to newer functions]
> > ---
> >
> > Changes since v1:
> > - changed ownership as per initial patch
>
> IIRC, the patch was created on vendor kernel long time ago to work
> around a specific glitchy multiplexer issue seen on particular SoC.
> I'm not sure it's good for the upstream kernel today.
>
I'm taking this as a Nak. Resend or restart this discussion if you want
me to apply this.
^ permalink raw reply
* [linux-sunxi] [PATCH] arm: sun4i: Add support for Pengpod 1000 tablet
From: Jagan Teki @ 2018-06-01 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601175538.16716-1-rah@settrans.net>
On 06/01/2018 11:25 PM, Bob Ham wrote:
> This is initial support for the Pengpod 1000 tablet. The display is
> not currently working but the UART, SD card and USB all work fine.
>
> Signed-off-by: Bob Ham <rah@settrans.net>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts | 232 +++++++++++++++++++++++++++
> 2 files changed, 233 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ade7a38543dc..e6e93e7ffc8b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -893,6 +893,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-olinuxino-lime.dtb \
> sun4i-a10-pcduino.dtb \
> sun4i-a10-pcduino2.dtb \
> + sun4i-a10-pengpod-1000.dtb \
> sun4i-a10-pov-protab2-ips9.dtb
> dtb-$(CONFIG_MACH_SUN5I) += \
> sun5i-a10s-auxtek-t003.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
> new file mode 100644
> index 000000000000..94560400114d
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
> @@ -0,0 +1,232 @@
> +/*
> + * Copyright 2015 Hans de Goede <hdegoede@redhat.com>
> + * Copyright 2017 Robert Ham <rah@settrans.net>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
We need to use SPDX-License for new dts files.
^ permalink raw reply
* [PATCH linux-next v5 00/13] PECI device driver introduction
From: Jae Hyun Yoo @ 2018-06-01 18:20 UTC (permalink / raw)
To: linux-arm-kernel
Introduction of the Platform Environment Control Interface (PECI) bus
device driver. PECI is a one-wire bus interface that provides a
communication channel between an Intel processor and chipset components to
external monitoring or control devices. PECI is designed to support the
following sideband functions:
* Processor and DRAM thermal management
- Processor fan speed control is managed by comparing Digital Thermal
Sensor (DTS) thermal readings acquired via PECI against the
processor-specific fan speed control reference point, or TCONTROL. Both
TCONTROL and DTS thermal readings are accessible via the processor PECI
client. These variables are referenced to a common temperature, the TCC
activation point, and are both defined as negative offsets from that
reference.
- PECI based access to the processor package configuration space provides
a means for Baseboard Management Controllers (BMC) or other platform
management devices to actively manage the processor and memory power
and thermal features.
* Platform Manageability
- Platform manageability functions including thermal, power, and error
monitoring. Note that platform 'power' management includes monitoring
and control for both the processor and DRAM subsystem to assist with
data center power limiting.
- PECI allows read access to certain error registers in the processor MSR
space and status monitoring registers in the PCI configuration space
within the processor and downstream devices.
- PECI permits writes to certain registers in the processor PCI
configuration space.
* Processor Interface Tuning and Diagnostics
- Processor interface tuning and diagnostics capabilities
(Intel Interconnect BIST). The processors Intel Interconnect Built In
Self Test (Intel IBIST) allows for infield diagnostic capabilities in
the Intel UPI and memory controller interfaces. PECI provides a port to
execute these diagnostics via its PCI Configuration read and write
capabilities.
* Failure Analysis
- Output the state of the processor after a failure for analysis via
Crashdump.
PECI uses a single wire for self-clocking and data transfer. The bus
requires no additional control lines. The physical layer is a self-clocked
one-wire bus that begins each bit with a driven, rising edge from an idle
level near zero volts. The duration of the signal driven high depends on
whether the bit value is a logic '0' or logic '1'. PECI also includes
variable data transfer rate established with every message. In this way, it
is highly flexible even though underlying logic is simple.
The interface design was optimized for interfacing between an Intel
processor and chipset components in both single processor and multiple
processor environments. The single wire interface provides low board
routing overhead for the multiple load connections in the congested routing
area near the processor and chipset components. Bus speed, error checking,
and low protocol overhead provides adequate link bandwidth and reliability
to transfer critical device operating conditions and configuration
information.
This implementation provides the basic framework to add PECI extensions to
the Linux bus and device models. A hardware specific 'Adapter' driver can
be attached to the PECI bus to provide sideband functions described above.
It is also possible to access all devices on an adapter from userspace
through the /dev interface. A device specific 'Client' driver also can be
attached to the PECI bus so each processor client's features can be
supported by the 'Client' driver through an adapter connection in the bus.
This patch set includes Aspeed 24xx/25xx PECI driver and PECI
cputemp/dimmtemp drivers as the first implementation for both adapter and
client drivers on the PECI bus framework.
Please review.
Thanks,
-Jae
Changes since v4:
* Fixed an incorrect endianness handling in peci-aspeed.
* Added a comment to explain about the asm/intel-family.h inclusion.
* Added an MFD module to support multi-function PECI client devices.
Changes since v3:
* Made code more simple and compact.
* Removed unused header file inclusion.
* Fixed incorrect error return values and messages.
* Removed DTS margin temperature from the peci-cputemp.
* Made some magic numbers use defines.
* Moved peci_get_cpu_id() into peci-core as a common function.
* Replaced the cancel_delayed_work() call with a cancel_delayed_work_sync().
* Replaced AST and Aspeed uses with ASPEED.
* Simplified peci command timeout checking logic using
regmap_read_poll_timeout().
* Simplified endian swap codes using endian handling macros.
* Dropped regmap read/write error checking except for the first access.
* Added a PECI reset setting in the device tree node.
* Removed unnecessary sleep from the probe context.
* Removed IRQF_SHARED flag from irq request code in the ASPEED PECI driver.
* Fixed typos in documents.
* Combined peci-bus.txt, peci-adapter.txt and peci-client.txt into peci.txt.
* Fixed and swept documents to drop some incorrect or unnecessary
descriptions.
* Fixed device tree to make unit-address format use reg contents.
* Simplified bit manipulations using <linux/bitfield.h>.
* Made client CPU model checking use <asm/intel-family.h> if available.
* Modified adapter heap allocation method to use kobject reference count
based.
* Added the low-level PECI xfer IOCTL again to support the Redfish
requirement.
* Added PM domain attach/detach code.
* Added logic for device instantiation through sysfs.
* Fix a bug of interrupt status checking code in peci-aspeed driver.
Changes since v2:
* Divided peci-hwmon driver into two drivers, peci-cputemp and
peci-dimmtemp.
* Added generic dt binding documents for PECI bus, adapter and client.
* Removed in_atomic() call from the PECI core driver.
* Improved PECI commands masking logic.
* Added permission check logic for PECI ioctls.
* Removed unnecessary type casts.
* Fixed some invalid error return codes.
* Added the mark_updated() function to improve update interval checking
logic.
* Fixed a bug in populated DIMM checking function.
* Fixed some typo, grammar and style issues in documents.
* Rewrote hwmon drivers to use devm_hwmon_device_register_with_info API.
* Made peci_match_id() function as a static.
* Replaced a deprecated create_singlethread_workqueue() call with an
alloc_ordered_workqueue() call.
* Reordered local variable definitions in reversed xmas tree notation.
* Listed up client CPUs that can be supported by peci-cputemp and
peci-dimmtemp hwmon drivers.
* Added CPU generation detection logic which checks CPUID signature through
PECI connection.
* Improved interrupt handling logic in the Aspeed PECI adapter driver.
* Fixed SPDX license identifier style in header files.
* Changed some macros in peci.h to static inline functions.
* Dropped sleepable context checking code in peci-core.
* Adjusted rt_mutex protection scope in peci-core.
* Moved adapter->xfer() checking code into peci_register_adapter().
* Improved PECI command retry checking logic.
* Changed ioctl base from 'P' to 0xb6 to avoid confiliction and updated
ioctl-number.txt to reflect the ioctl number of PECI subsystem.
* Added a comment to describe PECI retry action.
* Simplified return code handling of peci_ioctl_ping().
* Changed type of peci_ioctl_fn[] to static const.
* Fixed range checking code for valid PECI commands.
* Fixed the error return code on invalid PECI commands.
* Fixed incorrect definitions of PECI ioctl and its handling logic.
Changes since v1:
* Additionally implemented a core driver to support PECI linux bus driver
model.
* Modified Aspeed PECI driver to make that to be an adapter driver in PECI
bus.
* Modified PECI hwmon driver to make that to be a client driver in PECI
bus.
* Simplified hwmon driver attribute labels and removed redundant strings.
* Removed core_nums from device tree setting of hwmon driver and modified
core number detection logic to check the resolved_core register in client
CPU's local PCI configuration area.
* Removed dimm_nums from device tree setting of hwmon driver and added
populated DIMM detection logic to support dynamic creation.
* Removed indexing gap on core temperature and DIMM temperature attributes.
* Improved hwmon registration and dynamic attribute creation logic.
* Fixed structure definitions in PECI uapi header to make that use __u8,
__u16 and etc.
* Modified wait_for_completion_interruptible_timeout error handling logic
in Aspeed PECI driver to deliver errors correctly.
* Removed low-level xfer command from ioctl and kept only high-level PECI
command suite as ioctls.
* Fixed I/O timeout logic in Aspeed PECI driver using ktime.
* Added a function into hwmon driver to simplify update delay checking.
* Added a function into hwmon driver to convert 10.6 to millidegree.
* Dropped non-standard attributes in hwmon driver.
* Fixed OF table for hwmon to make it indicate as a PECI client of Intel
CPU target.
* Added a maintainer of PECI subsystem into MAINTAINERS document.
Jae Hyun Yoo (13):
dt-bindings: Add a document of PECI subsystem
Documentation: ioctl: Add ioctl numbers for PECI subsystem
drivers/peci: Add support for PECI bus driver core
dt-bindings: Add a document of PECI adapter driver for ASPEED
AST24xx/25xx SoCs
ARM: dts: aspeed: peci: Add PECI node
drivers/peci: Add a PECI adapter driver for Aspeed AST24xx/AST25xx
dt-bindings: mfd: Add a document for PECI client mfd
drivers/mfd: Add PECI client mfd driver
dt-bindings: hwmon: Add documents for PECI hwmon client drivers
Documentation: hwmon: Add documents for PECI hwmon client drivers
drivers/hwmon: Add PECI cputemp driver
drivers/hwmon: Add PECI dimmtemp driver
Add maintainers for the PECI subsystem
.../bindings/hwmon/peci-cputemp.txt | 11 +
.../bindings/hwmon/peci-dimmtemp.txt | 13 +
.../devicetree/bindings/mfd/peci-client.txt | 23 +
.../devicetree/bindings/peci/peci-aspeed.txt | 57 +
.../devicetree/bindings/peci/peci.txt | 59 +
Documentation/hwmon/peci-cputemp | 78 +
Documentation/hwmon/peci-dimmtemp | 50 +
Documentation/ioctl/ioctl-number.txt | 2 +
MAINTAINERS | 12 +
arch/arm/boot/dts/aspeed-g4.dtsi | 26 +
arch/arm/boot/dts/aspeed-g5.dtsi | 26 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/hwmon/Kconfig | 28 +
drivers/hwmon/Makefile | 2 +
drivers/hwmon/peci-cputemp.c | 401 +++++
drivers/hwmon/peci-dimmtemp.c | 295 ++++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/peci-client.c | 205 +++
drivers/peci/Kconfig | 40 +
drivers/peci/Makefile | 9 +
drivers/peci/peci-aspeed.c | 498 ++++++
drivers/peci/peci-core.c | 1439 +++++++++++++++++
include/linux/mfd/peci-client.h | 60 +
include/linux/peci.h | 104 ++
include/uapi/linux/peci-ioctl.h | 265 +++
27 files changed, 3718 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
create mode 100644 Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
create mode 100644 Documentation/devicetree/bindings/mfd/peci-client.txt
create mode 100644 Documentation/devicetree/bindings/peci/peci-aspeed.txt
create mode 100644 Documentation/devicetree/bindings/peci/peci.txt
create mode 100644 Documentation/hwmon/peci-cputemp
create mode 100644 Documentation/hwmon/peci-dimmtemp
create mode 100644 drivers/hwmon/peci-cputemp.c
create mode 100644 drivers/hwmon/peci-dimmtemp.c
create mode 100644 drivers/mfd/peci-client.c
create mode 100644 drivers/peci/Kconfig
create mode 100644 drivers/peci/Makefile
create mode 100644 drivers/peci/peci-aspeed.c
create mode 100644 drivers/peci/peci-core.c
create mode 100644 include/linux/mfd/peci-client.h
create mode 100644 include/linux/peci.h
create mode 100644 include/uapi/linux/peci-ioctl.h
--
2.17.0
^ permalink raw reply
* [PATCH linux-next v5 04/13] dt-bindings: Add a document of PECI adapter driver for ASPEED AST24xx/25xx SoCs
From: Jae Hyun Yoo @ 2018-06-01 18:21 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds a dt-bindings document of PECI adapter driver for ASPEED
AST24xx/25xx SoCs.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Milton Miller II <miltonm@us.ibm.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Ryan Chen <ryan_chen@aspeedtech.com>
---
.../devicetree/bindings/peci/peci-aspeed.txt | 57 +++++++++++++++++++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/peci/peci-aspeed.txt
diff --git a/Documentation/devicetree/bindings/peci/peci-aspeed.txt b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
new file mode 100644
index 000000000000..8c35f905589d
--- /dev/null
+++ b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
@@ -0,0 +1,57 @@
+Device tree configuration for PECI buses on the AST24XX and AST25XX SoCs.
+
+Required properties:
+- compatible : Should be "aspeed,ast2400-peci" or "aspeed,ast2500-peci"
+ - aspeed,ast2400-peci: ASPEED AST2400 family PECI
+ controller
+ - aspeed,ast2500-peci: ASPEED AST2500 family PECI
+ controller
+- reg : Should contain PECI controller registers location and
+ length.
+- #address-cells : Should be <1> required to define a client address.
+- #size-cells : Should be <0> required to define a client address.
+- interrupts : Should contain PECI controller interrupt.
+- clocks : Should contain clock source for PECI controller. Should
+ reference the external oscillator clock in the second
+ cell.
+- resets : Should contain phandle to reset controller with the reset
+ number in the second cell.
+- clock-frequency : Should contain the operation frequency of PECI controller
+ in units of Hz.
+ 187500 ~ 24000000
+
+Optional properties:
+- msg-timing : Message timing negotiation period. This value will
+ determine the period of message timing negotiation to be
+ issued by PECI controller. The unit of the programmed
+ value is four times of PECI clock period.
+ 0 ~ 255 (default: 1)
+- addr-timing : Address timing negotiation period. This value will
+ determine the period of address timing negotiation to be
+ issued by PECI controller. The unit of the programmed
+ value is four times of PECI clock period.
+ 0 ~ 255 (default: 1)
+- rd-sampling-point : Read sampling point selection. The whole period of a bit
+ time will be divided into 16 time frames. This value will
+ determine the time frame in which the controller will
+ sample PECI signal for data read back. Usually in the
+ middle of a bit time is the best.
+ 0 ~ 15 (default: 8)
+- cmd-timeout-ms : Command timeout in units of ms.
+ 1 ~ 60000 (default: 1000)
+
+Example:
+ peci0: peci-bus at 0 {
+ compatible = "aspeed,ast2500-peci";
+ reg = <0x0 0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <15>;
+ clocks = <&syscon ASPEED_CLK_GATE_REFCLK>;
+ resets = <&syscon ASPEED_RESET_PECI>;
+ clock-frequency = <24000000>;
+ msg-timing = <1>;
+ addr-timing = <1>;
+ rd-sampling-point = <8>;
+ cmd-timeout-ms = <1000>;
+ };
--
2.17.0
^ permalink raw reply related
* [PATCH linux-next v5 05/13] ARM: dts: aspeed: peci: Add PECI node
From: Jae Hyun Yoo @ 2018-06-01 18:21 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds PECI bus/adapter node of AST24xx/AST25xx into
aspeed-g4 and aspeed-g5.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Ryan Chen <ryan_chen@aspeedtech.com>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 26 ++++++++++++++++++++++++++
arch/arm/boot/dts/aspeed-g5.dtsi | 26 ++++++++++++++++++++++++++
2 files changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 5e947ed496c2..5702f0cfd5f8 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -29,6 +29,7 @@
serial3 = &uart4;
serial4 = &uart5;
serial5 = &vuart;
+ peci0 = &peci0;
};
cpus {
@@ -295,6 +296,13 @@
};
};
+ peci: peci at 1e78b000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x1e78b000 0x60>;
+ };
+
uart2: serial at 1e78d000 {
compatible = "ns16550a";
reg = <0x1e78d000 0x20>;
@@ -338,6 +346,24 @@
};
};
+&peci {
+ peci0: peci-bus at 0 {
+ compatible = "aspeed,ast2400-peci";
+ reg = <0x0 0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <15>;
+ clocks = <&syscon ASPEED_CLK_GATE_REFCLK>;
+ resets = <&syscon ASPEED_RESET_PECI>;
+ clock-frequency = <24000000>;
+ msg-timing = <1>;
+ addr-timing = <1>;
+ rd-sampling-point = <8>;
+ cmd-timeout-ms = <1000>;
+ status = "disabled";
+ };
+};
+
&i2c {
i2c_ic: interrupt-controller at 0 {
#interrupt-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 24eec00c4a95..5741b841fddb 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -29,6 +29,7 @@
serial3 = &uart4;
serial4 = &uart5;
serial5 = &vuart;
+ peci0 = &peci0;
};
cpus {
@@ -352,6 +353,13 @@
};
};
+ peci: peci at 1e78b000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x1e78b000 0x60>;
+ };
+
uart2: serial at 1e78d000 {
compatible = "ns16550a";
reg = <0x1e78d000 0x20>;
@@ -395,6 +403,24 @@
};
};
+&peci {
+ peci0: peci-bus at 0 {
+ compatible = "aspeed,ast2500-peci";
+ reg = <0x0 0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <15>;
+ clocks = <&syscon ASPEED_CLK_GATE_REFCLK>;
+ resets = <&syscon ASPEED_RESET_PECI>;
+ clock-frequency = <24000000>;
+ msg-timing = <1>;
+ addr-timing = <1>;
+ rd-sampling-point = <8>;
+ cmd-timeout-ms = <1000>;
+ status = "disabled";
+ };
+};
+
&i2c {
i2c_ic: interrupt-controller at 0 {
#interrupt-cells = <1>;
--
2.17.0
^ permalink raw reply related
* [PATCH linux-next v5 06/13] drivers/peci: Add a PECI adapter driver for Aspeed AST24xx/AST25xx
From: Jae Hyun Yoo @ 2018-06-01 18:21 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds PECI adapter driver implementation for Aspeed
AST24xx/AST25xx SoCs.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Ryan Chen <ryan_chen@aspeedtech.com>
---
drivers/peci/Kconfig | 27 ++
drivers/peci/Makefile | 3 +
drivers/peci/peci-aspeed.c | 498 +++++++++++++++++++++++++++++++++++++
3 files changed, 528 insertions(+)
create mode 100644 drivers/peci/peci-aspeed.c
diff --git a/drivers/peci/Kconfig b/drivers/peci/Kconfig
index c39f7730d081..273a10eab1ce 100644
--- a/drivers/peci/Kconfig
+++ b/drivers/peci/Kconfig
@@ -11,3 +11,30 @@ config PECI
interface that provides a communication channel between Intel
processors and chipset components to external monitoring or control
devices.
+
+ If you want PECI support, you should say Y here and also to the
+ specific driver for your bus adapter(s) below.
+
+if PECI
+
+#
+# PECI hardware bus configuration
+#
+
+menu "PECI Hardware Bus support"
+
+config PECI_ASPEED
+ tristate "ASPEED PECI support"
+ select REGMAP_MMIO
+ depends on OF
+ depends on ARCH_ASPEED || COMPILE_TEST
+ help
+ Say Y here if you want support for the Platform Environment Control
+ Interface (PECI) bus adapter driver on the ASPEED SoCs.
+
+ This support is also available as a module. If so, the module
+ will be called peci-aspeed.
+
+endmenu
+
+endif # PECI
diff --git a/drivers/peci/Makefile b/drivers/peci/Makefile
index 9e8615e0d3ff..886285e69765 100644
--- a/drivers/peci/Makefile
+++ b/drivers/peci/Makefile
@@ -4,3 +4,6 @@
# Core functionality
obj-$(CONFIG_PECI) += peci-core.o
+
+# Hardware specific bus drivers
+obj-$(CONFIG_PECI_ASPEED) += peci-aspeed.o
diff --git a/drivers/peci/peci-aspeed.c b/drivers/peci/peci-aspeed.c
new file mode 100644
index 000000000000..8070ec18d484
--- /dev/null
+++ b/drivers/peci/peci-aspeed.c
@@ -0,0 +1,498 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2012-2017 ASPEED Technology Inc.
+// Copyright (c) 2018 Intel Corporation
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/interrupt.h>
+#include <linux/jiffies.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/peci.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+
+/* ASPEED PECI Registers */
+#define ASPEED_PECI_CTRL 0x00
+#define ASPEED_PECI_TIMING 0x04
+#define ASPEED_PECI_CMD 0x08
+#define ASPEED_PECI_CMD_CTRL 0x0c
+#define ASPEED_PECI_EXP_FCS 0x10
+#define ASPEED_PECI_CAP_FCS 0x14
+#define ASPEED_PECI_INT_CTRL 0x18
+#define ASPEED_PECI_INT_STS 0x1c
+#define ASPEED_PECI_W_DATA0 0x20
+#define ASPEED_PECI_W_DATA1 0x24
+#define ASPEED_PECI_W_DATA2 0x28
+#define ASPEED_PECI_W_DATA3 0x2c
+#define ASPEED_PECI_R_DATA0 0x30
+#define ASPEED_PECI_R_DATA1 0x34
+#define ASPEED_PECI_R_DATA2 0x38
+#define ASPEED_PECI_R_DATA3 0x3c
+#define ASPEED_PECI_W_DATA4 0x40
+#define ASPEED_PECI_W_DATA5 0x44
+#define ASPEED_PECI_W_DATA6 0x48
+#define ASPEED_PECI_W_DATA7 0x4c
+#define ASPEED_PECI_R_DATA4 0x50
+#define ASPEED_PECI_R_DATA5 0x54
+#define ASPEED_PECI_R_DATA6 0x58
+#define ASPEED_PECI_R_DATA7 0x5c
+
+/* ASPEED_PECI_CTRL - 0x00 : Control Register */
+#define PECI_CTRL_SAMPLING_MASK GENMASK(19, 16)
+#define PECI_CTRL_READ_MODE_MASK GENMASK(13, 12)
+#define PECI_CTRL_READ_MODE_COUNT BIT(12)
+#define PECI_CTRL_READ_MODE_DBG BIT(13)
+#define PECI_CTRL_CLK_SOURCE_MASK BIT(11)
+#define PECI_CTRL_CLK_DIV_MASK GENMASK(10, 8)
+#define PECI_CTRL_INVERT_OUT BIT(7)
+#define PECI_CTRL_INVERT_IN BIT(6)
+#define PECI_CTRL_BUS_CONTENT_EN BIT(5)
+#define PECI_CTRL_PECI_EN BIT(4)
+#define PECI_CTRL_PECI_CLK_EN BIT(0)
+
+/* ASPEED_PECI_TIMING - 0x04 : Timing Negotiation Register */
+#define PECI_TIMING_MESSAGE_MASK GENMASK(15, 8)
+#define PECI_TIMING_ADDRESS_MASK GENMASK(7, 0)
+
+/* ASPEED_PECI_CMD - 0x08 : Command Register */
+#define PECI_CMD_PIN_MON BIT(31)
+#define PECI_CMD_STS_MASK GENMASK(27, 24)
+#define PECI_CMD_IDLE_MASK (PECI_CMD_STS_MASK | PECI_CMD_PIN_MON)
+#define PECI_CMD_FIRE BIT(0)
+
+/* ASPEED_PECI_LEN - 0x0C : Read/Write Length Register */
+#define PECI_AW_FCS_EN BIT(31)
+#define PECI_READ_LEN_MASK GENMASK(23, 16)
+#define PECI_WRITE_LEN_MASK GENMASK(15, 8)
+#define PECI_TAGET_ADDR_MASK GENMASK(7, 0)
+
+/* ASPEED_PECI_EXP_FCS - 0x10 : Expected FCS Data Register */
+#define PECI_EXPECT_READ_FCS_MASK GENMASK(23, 16)
+#define PECI_EXPECT_AW_FCS_AUTO_MASK GENMASK(15, 8)
+#define PECI_EXPECT_WRITE_FCS_MASK GENMASK(7, 0)
+
+/* ASPEED_PECI_CAP_FCS - 0x14 : Captured FCS Data Register */
+#define PECI_CAPTURE_READ_FCS_MASK GENMASK(23, 16)
+#define PECI_CAPTURE_WRITE_FCS_MASK GENMASK(7, 0)
+
+/* ASPEED_PECI_INT_CTRL/STS - 0x18/0x1c : Interrupt Register */
+#define PECI_INT_TIMING_RESULT_MASK GENMASK(31, 30)
+#define PECI_INT_TIMEOUT BIT(4)
+#define PECI_INT_CONNECT BIT(3)
+#define PECI_INT_W_FCS_BAD BIT(2)
+#define PECI_INT_W_FCS_ABORT BIT(1)
+#define PECI_INT_CMD_DONE BIT(0)
+
+#define PECI_INT_MASK (PECI_INT_TIMEOUT | PECI_INT_CONNECT | \
+ PECI_INT_W_FCS_BAD | PECI_INT_W_FCS_ABORT | \
+ PECI_INT_CMD_DONE)
+
+#define PECI_IDLE_CHECK_TIMEOUT_USEC 50000
+#define PECI_IDLE_CHECK_INTERVAL_USEC 10000
+
+#define PECI_RD_SAMPLING_POINT_DEFAULT 8
+#define PECI_RD_SAMPLING_POINT_MAX 15
+#define PECI_CLK_DIV_DEFAULT 0
+#define PECI_CLK_DIV_MAX 7
+#define PECI_MSG_TIMING_DEFAULT 1
+#define PECI_MSG_TIMING_MAX 255
+#define PECI_ADDR_TIMING_DEFAULT 1
+#define PECI_ADDR_TIMING_MAX 255
+#define PECI_CMD_TIMEOUT_MS_DEFAULT 1000
+#define PECI_CMD_TIMEOUT_MS_MAX 60000
+
+struct aspeed_peci {
+ struct peci_adapter *adapter;
+ struct device *dev;
+ struct regmap *regmap;
+ struct reset_control *rst;
+ int irq;
+ spinlock_t lock; /* to sync completion status handling */
+ struct completion xfer_complete;
+ u32 status;
+ u32 cmd_timeout_ms;
+};
+
+static int aspeed_peci_xfer_native(struct aspeed_peci *priv,
+ struct peci_xfer_msg *msg)
+{
+ long err, timeout = msecs_to_jiffies(priv->cmd_timeout_ms);
+ u32 peci_head, peci_state, rx_data, cmd_sts;
+ unsigned long flags;
+ int i, rc;
+ uint reg;
+
+ /* Check command sts and bus idle state */
+ rc = regmap_read_poll_timeout(priv->regmap, ASPEED_PECI_CMD, cmd_sts,
+ !(cmd_sts & PECI_CMD_IDLE_MASK),
+ PECI_IDLE_CHECK_INTERVAL_USEC,
+ PECI_IDLE_CHECK_TIMEOUT_USEC);
+ if (rc)
+ return rc; /* -ETIMEDOUT */
+
+ spin_lock_irqsave(&priv->lock, flags);
+ reinit_completion(&priv->xfer_complete);
+
+ peci_head = FIELD_PREP(PECI_TAGET_ADDR_MASK, msg->addr) |
+ FIELD_PREP(PECI_WRITE_LEN_MASK, msg->tx_len) |
+ FIELD_PREP(PECI_READ_LEN_MASK, msg->rx_len);
+
+ regmap_write(priv->regmap, ASPEED_PECI_CMD_CTRL, peci_head);
+
+ for (i = 0; i < msg->tx_len; i += 4) {
+ reg = i < 16 ? ASPEED_PECI_W_DATA0 + i % 16 :
+ ASPEED_PECI_W_DATA4 + i % 16;
+ regmap_write(priv->regmap, reg,
+ le32_to_cpup((__le32 *)&msg->tx_buf[i]));
+ }
+
+ dev_dbg(priv->dev, "HEAD : 0x%08x\n", peci_head);
+ print_hex_dump_debug("TX : ", DUMP_PREFIX_NONE, 16, 1,
+ msg->tx_buf, msg->tx_len, true);
+
+ priv->status = 0;
+ regmap_write(priv->regmap, ASPEED_PECI_CMD, PECI_CMD_FIRE);
+ spin_unlock_irqrestore(&priv->lock, flags);
+
+ err = wait_for_completion_interruptible_timeout(&priv->xfer_complete,
+ timeout);
+
+ spin_lock_irqsave(&priv->lock, flags);
+ dev_dbg(priv->dev, "INT_STS : 0x%08x\n", priv->status);
+ regmap_read(priv->regmap, ASPEED_PECI_CMD, &peci_state);
+ dev_dbg(priv->dev, "PECI_STATE : 0x%lx\n",
+ FIELD_GET(PECI_CMD_STS_MASK, peci_state));
+
+ regmap_write(priv->regmap, ASPEED_PECI_CMD, 0);
+
+ if (err <= 0 || priv->status != PECI_INT_CMD_DONE) {
+ if (err < 0) { /* -ERESTARTSYS */
+ rc = (int)err;
+ goto err_irqrestore;
+ } else if (err == 0) {
+ dev_dbg(priv->dev, "Timeout waiting for a response!\n");
+ rc = -ETIMEDOUT;
+ goto err_irqrestore;
+ }
+
+ dev_dbg(priv->dev, "No valid response!\n");
+ rc = -EIO;
+ goto err_irqrestore;
+ }
+
+ /**
+ * Note that rx_len and rx_buf size can be an odd number.
+ * Byte handling is more efficient.
+ */
+ for (i = 0; i < msg->rx_len; i++) {
+ u8 byte_offset = i % 4;
+
+ if (byte_offset == 0) {
+ reg = i < 16 ? ASPEED_PECI_R_DATA0 + i % 16 :
+ ASPEED_PECI_R_DATA4 + i % 16;
+ regmap_read(priv->regmap, reg, &rx_data);
+ }
+
+ msg->rx_buf[i] = (u8)(rx_data >> (byte_offset << 3));
+ }
+
+ print_hex_dump_debug("RX : ", DUMP_PREFIX_NONE, 16, 1,
+ msg->rx_buf, msg->rx_len, true);
+
+ regmap_read(priv->regmap, ASPEED_PECI_CMD, &peci_state);
+ dev_dbg(priv->dev, "PECI_STATE : 0x%lx\n",
+ FIELD_GET(PECI_CMD_STS_MASK, peci_state));
+ dev_dbg(priv->dev, "------------------------\n");
+
+err_irqrestore:
+ spin_unlock_irqrestore(&priv->lock, flags);
+ return rc;
+}
+
+static irqreturn_t aspeed_peci_irq_handler(int irq, void *arg)
+{
+ struct aspeed_peci *priv = arg;
+ u32 status_ack = 0;
+ u32 status;
+
+ spin_lock(&priv->lock);
+ regmap_read(priv->regmap, ASPEED_PECI_INT_STS, &status);
+ priv->status |= (status & PECI_INT_MASK);
+
+ /**
+ * In most cases, interrupt bits will be set one by one but also note
+ * that multiple interrupt bits could be set at the same time.
+ */
+ if (status & PECI_INT_TIMEOUT) {
+ dev_dbg(priv->dev, "PECI_INT_TIMEOUT\n");
+ status_ack |= PECI_INT_TIMEOUT;
+ }
+
+ if (status & PECI_INT_CONNECT) {
+ dev_dbg(priv->dev, "PECI_INT_CONNECT\n");
+ status_ack |= PECI_INT_CONNECT;
+ }
+
+ if (status & PECI_INT_W_FCS_BAD) {
+ dev_dbg(priv->dev, "PECI_INT_W_FCS_BAD\n");
+ status_ack |= PECI_INT_W_FCS_BAD;
+ }
+
+ if (status & PECI_INT_W_FCS_ABORT) {
+ dev_dbg(priv->dev, "PECI_INT_W_FCS_ABORT\n");
+ status_ack |= PECI_INT_W_FCS_ABORT;
+ }
+
+ /**
+ * All commands should be ended up with a PECI_INT_CMD_DONE bit set
+ * even in an error case.
+ */
+ if (status & PECI_INT_CMD_DONE) {
+ dev_dbg(priv->dev, "PECI_INT_CMD_DONE\n");
+ status_ack |= PECI_INT_CMD_DONE;
+ complete(&priv->xfer_complete);
+ }
+
+ regmap_write(priv->regmap, ASPEED_PECI_INT_STS, status_ack);
+ spin_unlock(&priv->lock);
+ return IRQ_HANDLED;
+}
+
+static int aspeed_peci_init_ctrl(struct aspeed_peci *priv)
+{
+ u32 msg_timing, addr_timing, rd_sampling_point;
+ u32 clk_freq, clk_divisor, clk_div_val = 0;
+ struct clk *clkin;
+ int ret;
+
+ clkin = devm_clk_get(priv->dev, NULL);
+ if (IS_ERR(clkin)) {
+ dev_err(priv->dev, "Failed to get clk source.\n");
+ return PTR_ERR(clkin);
+ }
+
+ ret = of_property_read_u32(priv->dev->of_node, "clock-frequency",
+ &clk_freq);
+ if (ret) {
+ dev_err(priv->dev,
+ "Could not read clock-frequency property.\n");
+ return ret;
+ }
+
+ clk_divisor = clk_get_rate(clkin) / clk_freq;
+ devm_clk_put(priv->dev, clkin);
+
+ while ((clk_divisor >> 1) && (clk_div_val < PECI_CLK_DIV_MAX))
+ clk_div_val++;
+
+ ret = of_property_read_u32(priv->dev->of_node, "msg-timing",
+ &msg_timing);
+ if (ret || msg_timing > PECI_MSG_TIMING_MAX) {
+ if (!ret)
+ dev_warn(priv->dev,
+ "Invalid msg-timing : %u, Use default : %u\n",
+ msg_timing, PECI_MSG_TIMING_DEFAULT);
+ msg_timing = PECI_MSG_TIMING_DEFAULT;
+ }
+
+ ret = of_property_read_u32(priv->dev->of_node, "addr-timing",
+ &addr_timing);
+ if (ret || addr_timing > PECI_ADDR_TIMING_MAX) {
+ if (!ret)
+ dev_warn(priv->dev,
+ "Invalid addr-timing : %u, Use default : %u\n",
+ addr_timing, PECI_ADDR_TIMING_DEFAULT);
+ addr_timing = PECI_ADDR_TIMING_DEFAULT;
+ }
+
+ ret = of_property_read_u32(priv->dev->of_node, "rd-sampling-point",
+ &rd_sampling_point);
+ if (ret || rd_sampling_point > PECI_RD_SAMPLING_POINT_MAX) {
+ if (!ret)
+ dev_warn(priv->dev,
+ "Invalid rd-sampling-point : %u. Use default : %u\n",
+ rd_sampling_point,
+ PECI_RD_SAMPLING_POINT_DEFAULT);
+ rd_sampling_point = PECI_RD_SAMPLING_POINT_DEFAULT;
+ }
+
+ ret = of_property_read_u32(priv->dev->of_node, "cmd-timeout-ms",
+ &priv->cmd_timeout_ms);
+ if (ret || priv->cmd_timeout_ms > PECI_CMD_TIMEOUT_MS_MAX ||
+ priv->cmd_timeout_ms == 0) {
+ if (!ret)
+ dev_warn(priv->dev,
+ "Invalid cmd-timeout-ms : %u. Use default : %u\n",
+ priv->cmd_timeout_ms,
+ PECI_CMD_TIMEOUT_MS_DEFAULT);
+ priv->cmd_timeout_ms = PECI_CMD_TIMEOUT_MS_DEFAULT;
+ }
+
+ regmap_write(priv->regmap, ASPEED_PECI_CTRL,
+ FIELD_PREP(PECI_CTRL_CLK_DIV_MASK, PECI_CLK_DIV_DEFAULT) |
+ PECI_CTRL_PECI_CLK_EN);
+
+ /**
+ * Timing negotiation period setting.
+ * The unit of the programmed value is 4 times of PECI clock period.
+ */
+ regmap_write(priv->regmap, ASPEED_PECI_TIMING,
+ FIELD_PREP(PECI_TIMING_MESSAGE_MASK, msg_timing) |
+ FIELD_PREP(PECI_TIMING_ADDRESS_MASK, addr_timing));
+
+ /* Clear interrupts */
+ regmap_write(priv->regmap, ASPEED_PECI_INT_STS, PECI_INT_MASK);
+
+ /* Enable interrupts */
+ regmap_write(priv->regmap, ASPEED_PECI_INT_CTRL, PECI_INT_MASK);
+
+ /* Read sampling point and clock speed setting */
+ regmap_write(priv->regmap, ASPEED_PECI_CTRL,
+ FIELD_PREP(PECI_CTRL_SAMPLING_MASK, rd_sampling_point) |
+ FIELD_PREP(PECI_CTRL_CLK_DIV_MASK, clk_div_val) |
+ PECI_CTRL_PECI_EN | PECI_CTRL_PECI_CLK_EN);
+
+ return 0;
+}
+
+static const struct regmap_config aspeed_peci_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = ASPEED_PECI_R_DATA7,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+ .fast_io = true,
+};
+
+static int aspeed_peci_xfer(struct peci_adapter *adapter,
+ struct peci_xfer_msg *msg)
+{
+ struct aspeed_peci *priv = peci_get_adapdata(adapter);
+
+ return aspeed_peci_xfer_native(priv, msg);
+}
+
+static int aspeed_peci_probe(struct platform_device *pdev)
+{
+ struct peci_adapter *adapter;
+ struct aspeed_peci *priv;
+ struct resource *res;
+ void __iomem *base;
+ u32 cmd_sts;
+ int ret;
+
+ adapter = peci_alloc_adapter(&pdev->dev, sizeof(*priv));
+ if (!adapter)
+ return -ENOMEM;
+
+ priv = peci_get_adapdata(adapter);
+ priv->adapter = adapter;
+ priv->dev = &pdev->dev;
+ dev_set_drvdata(&pdev->dev, priv);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base)) {
+ ret = PTR_ERR(base);
+ goto err_put_adapter_dev;
+ }
+
+ priv->regmap = devm_regmap_init_mmio(&pdev->dev, base,
+ &aspeed_peci_regmap_config);
+ if (IS_ERR(priv->regmap)) {
+ ret = PTR_ERR(priv->regmap);
+ goto err_put_adapter_dev;
+ }
+
+ /**
+ * We check that the regmap works on this very first access,
+ * but as this is an MMIO-backed regmap, subsequent regmap
+ * access is not going to fail and we skip error checks from
+ * this point.
+ */
+ ret = regmap_read(priv->regmap, ASPEED_PECI_CMD, &cmd_sts);
+ if (ret) {
+ ret = -EIO;
+ goto err_put_adapter_dev;
+ }
+
+ priv->irq = platform_get_irq(pdev, 0);
+ if (!priv->irq) {
+ ret = -ENODEV;
+ goto err_put_adapter_dev;
+ }
+
+ ret = devm_request_irq(&pdev->dev, priv->irq, aspeed_peci_irq_handler,
+ 0, "peci-aspeed-irq", priv);
+ if (ret)
+ goto err_put_adapter_dev;
+
+ init_completion(&priv->xfer_complete);
+ spin_lock_init(&priv->lock);
+
+ priv->adapter->owner = THIS_MODULE;
+ priv->adapter->dev.of_node = of_node_get(dev_of_node(priv->dev));
+ strlcpy(priv->adapter->name, pdev->name, sizeof(priv->adapter->name));
+ priv->adapter->xfer = aspeed_peci_xfer;
+
+ priv->rst = devm_reset_control_get(&pdev->dev, NULL);
+ if (IS_ERR(priv->rst)) {
+ dev_err(&pdev->dev,
+ "missing or invalid reset controller entry");
+ ret = PTR_ERR(priv->rst);
+ goto err_put_adapter_dev;
+ }
+ reset_control_deassert(priv->rst);
+
+ ret = aspeed_peci_init_ctrl(priv);
+ if (ret)
+ goto err_put_adapter_dev;
+
+ ret = peci_add_adapter(priv->adapter);
+ if (ret)
+ goto err_put_adapter_dev;
+
+ dev_info(&pdev->dev, "peci bus %d registered, irq %d\n",
+ priv->adapter->nr, priv->irq);
+
+ return 0;
+
+err_put_adapter_dev:
+ put_device(&adapter->dev);
+ return ret;
+}
+
+static int aspeed_peci_remove(struct platform_device *pdev)
+{
+ struct aspeed_peci *priv = dev_get_drvdata(&pdev->dev);
+
+ reset_control_assert(priv->rst);
+ peci_del_adapter(priv->adapter);
+ of_node_put(priv->adapter->dev.of_node);
+
+ return 0;
+}
+
+static const struct of_device_id aspeed_peci_of_table[] = {
+ { .compatible = "aspeed,ast2400-peci", },
+ { .compatible = "aspeed,ast2500-peci", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, aspeed_peci_of_table);
+
+static struct platform_driver aspeed_peci_driver = {
+ .probe = aspeed_peci_probe,
+ .remove = aspeed_peci_remove,
+ .driver = {
+ .name = "peci-aspeed",
+ .of_match_table = of_match_ptr(aspeed_peci_of_table),
+ },
+};
+module_platform_driver(aspeed_peci_driver);
+
+MODULE_AUTHOR("Ryan Chen <ryan_chen@aspeedtech.com>");
+MODULE_AUTHOR("Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>");
+MODULE_DESCRIPTION("ASPEED PECI driver");
+MODULE_LICENSE("GPL v2");
--
2.17.0
^ permalink raw reply related
* [PATCH V2] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-06-01 18:47 UTC (permalink / raw)
To: linux-arm-kernel
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 5 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 ---
arch/x86/pci/early.c | 44 -------------------------
drivers/pci/pci.c | 5 +++
drivers/pci/pci.h | 1 +
drivers/pci/probe.c | 21 ++++++++++++
8 files changed, 28 insertions(+), 59 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index e490902..e64f1d8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2995,7 +2995,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h b/arch/x86/include/asm/pci-direct.h
index e1084f7..e5e2129 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -14,9 +14,4 @@ extern void write_pci_config(u8 bus, u8 slot, u8 func, u8 offset, u32 val);
extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
-extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..f5fc953 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -57,47 +57,3 @@ int early_pci_allowed(void)
PCI_PROBE_CONF1;
}
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci 0000:%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256, false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0xffffffff)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
- if (func == 0) {
- type = read_pci_config_byte(bus, slot,
- func,
- PCI_HEADER_TYPE);
- if (!(type & 0x80))
- break;
- }
- }
- }
- }
-}
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 97acba7..04052dc 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+/* If set, the PCI config space of each device is printed during boot. */
+bool pci_early_dump;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5805,6 +5808,8 @@ static int __init pci_setup(char *str)
pcie_ats_disabled = true;
} else if (!strcmp(str, "noaer")) {
pci_no_aer();
+ } else if (!strcmp(str, "earlydump")) {
+ pci_early_dump = true;
} else if (!strncmp(str, "realloc=", 8)) {
pci_realloc_get_opt(str + 8);
} else if (!strncmp(str, "realloc", 7)) {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..c33265e 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -7,6 +7,7 @@
#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
extern const unsigned char pcie_link_speed[];
+extern bool pci_early_dump;
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 56771f3..7490f78fa 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1545,6 +1545,25 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
return 0;
}
+static void early_dump_pci_device(struct pci_dev *pdev)
+{
+ u32 value[256 / 4];
+ int i;
+
+ if (!pci_early_dump)
+ return;
+
+ pci_info(pdev, "pci 0000:%02x:%02x.%d config space:\n",
+ pdev->bus->number, PCI_SLOT(pdev->devfn),
+ PCI_FUNC(pdev->devfn));
+
+ for (i = 0; i < 256; i += 4)
+ pci_read_config_dword(pdev, i, &value[i / 4]);
+
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
+ 256, false);
+}
+
/**
* pci_setup_device - Fill in class and map information of a device
* @dev: the device structure to fill
@@ -1594,6 +1613,8 @@ int pci_setup_device(struct pci_dev *dev)
pci_printk(KERN_DEBUG, dev, "[%04x:%04x] type %02x class %#08x\n",
dev->vendor, dev->device, dev->hdr_type, dev->class);
+ early_dump_pci_device(dev);
+
/* Need to have dev->class ready */
dev->cfg_size = pci_cfg_space_size(dev);
--
2.7.4
^ 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