* Re: [PATCH v8 07/13] slimbus: Add support for 'clock-pause' feature
From: Greg Kroah-Hartman @ 2017-12-01 9:51 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Srini Kandagatla, Mark, ALSA, Sagar Dharia, bp, poeschel, treding,
andreas.noever, alan, mathieu.poirier, daniel, jkosina,
sharon.dvir1, Joe Perches, David S. Miller, james.hogan,
michael.opdenacker, Rob Herring, pawel.moll, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
linux-arm-msm, Vinod Koul
In-Reply-To: <CAOFm3uE+ehT+WGHO2tYz4W8h35wBgge+BO5fS=yuxemq28TERg@mail.gmail.com>
On Thu, Nov 30, 2017 at 08:25:26PM +0100, Philippe Ombredanne wrote:
> On Thu, Nov 30, 2017 at 6:41 PM, <srinivas.kandagatla@linaro.org> wrote:
> []
> > diff --git a/drivers/slimbus/sched.c b/drivers/slimbus/sched.c
> > new file mode 100644
> > index 000000000000..74300f1a6898
> > --- /dev/null
> > +++ b/drivers/slimbus/sched.c
> > @@ -0,0 +1,128 @@
> > +/* Copyright (c) 2011-2016, The Linux Foundation. All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
>
> Could it make sense to use the new SPDX ids here? e.g.
>
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (c) 2011-2016, The Linux Foundation
>
> This neat and cleaner, is it?
> See tglx doc posted as patches and Linus comments for a rationale on
> the comment styles.
Yes please, otherwise I'll just have to write add-on patches to do just
this :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v8 07/13] slimbus: Add support for 'clock-pause' feature
From: Srinivas Kandagatla @ 2017-12-01 9:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, Philippe Ombredanne
Cc: Mark, ALSA, Sagar Dharia, bp, poeschel, treding, andreas.noever,
alan, mathieu.poirier, daniel, jkosina, sharon.dvir1, Joe Perches,
David S. Miller, james.hogan, michael.opdenacker, Rob Herring,
pawel.moll, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
linux-arm-msm, Vinod Koul, Arnd Bergmann
In-Reply-To: <20171201095131.GF9353@kroah.com>
On 01/12/17 09:51, Greg Kroah-Hartman wrote:
> On Thu, Nov 30, 2017 at 08:25:26PM +0100, Philippe Ombredanne wrote:
>> On Thu, Nov 30, 2017 at 6:41 PM,<srinivas.kandagatla@linaro.org> wrote:
>> []
>>> diff --git a/drivers/slimbus/sched.c b/drivers/slimbus/sched.c
>>> new file mode 100644
>>> index 000000000000..74300f1a6898
>>> --- /dev/null
>>> +++ b/drivers/slimbus/sched.c
>>> @@ -0,0 +1,128 @@
>>> +/* Copyright (c) 2011-2016, The Linux Foundation. All rights reserved.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 and
>>> + * only version 2 as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>> Could it make sense to use the new SPDX ids here? e.g.
>>
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +// Copyright (c) 2011-2016, The Linux Foundation
>> This neat and cleaner, is it?
>> See tglx doc posted as patches and Linus comments for a rationale on
>> the comment styles.
> Yes please, otherwise I'll just have to write add-on patches to do just
> this:)
>
Yep, I will take care of this before sending another version.
Thanks,
srini
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
From: Linus Walleij @ 2017-12-01 9:56 UTC (permalink / raw)
To: Andre Przywara
Cc: Thierry Reding, Maxime Ripard, Chen-Yu Tsai,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Arnd Bergmann, Icenowy Zheng,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <0c8051e6-5d8c-32d6-97e4-11c2283da5b4-5wv7dgnIgG8@public.gmane.org>
On Fri, Nov 24, 2017 at 6:19 PM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> Conceptually I consider the DT being
> part of the firmware,
As it is a subset of open firmware it is obviously firmware.
> so one trust level above the kernel.
We are several kernel developers who don't trust firmware one
bit. Several disasters in ACPI has made me ever more convinced
that firmware should be trusted less than kernel code.
But this is all very academic.
>> Also, device tree bindings are not documentation for how to write a
>> driver. They are not a replacement for hardware documentation. Nobody
>> should be expected to be able to write an OS driver solely based on a
>> device tree binding. Device tree bindings are more of a configuration
>> interface specification for OS drivers.
>
> Yes, but together with the hardware docs you should be able to write a
> driver. And here you can't, because you are missing the strings. So a
> BSD developer has to look at Linux code.
This is a fair point. It appears in several drivers.
BSD or even Windows (would they use DT) would have to sit in the
back seat just like Linux has been doing for years when it comes
to the hopeless Windowsisms in the x86 BIOSes. I suspect some
Windows on ARM is already experiencing this, but in the ACPI world,
where, incidentally, the servers were being deployed for Linux first
and Windows had to follow their example. I bet they have been
swearing a lot in Redmond about that.
In general it's one of these areas where we can not be utopian about the
hardware descriptions, just fail gracefully in different ways.
I usually try to keep the IETF motto "rough consensus and running
code" in mind. I don't know if it helps in this discussion though.
>> So that's about 40% of the kernel image. Code really is no good without
>> data to process.
>
> But how much of this is SoC specific configuration data? How much is it
> in x86? Yes, historically we had and have a lot of configuration data in
> ARM kernels. But that doesn't mean that we have to continue with this or
> even increase the share.
What people have been doing is trying to have better Kconfig setups
and compile it out by doing kernel modules. It is a bit hopeless with
pin controllers: almost all of them have to be built in. And if they come
with a lot of data, yeah there you have a real good point.
It would be sad if the ARMv7 multiboot or Aarch64 kernel just grows
so that we can't use it but have to go back to shipping board-specific
kernels with a huge bunch of stuff compiled out.
I was hoping Moore's law would save us here :/
An option that has been discussed is better used of __initdata
and similar tags, especially with built-in drivers. Sadly, this is
hurt by another snag: the compiler or linker file or whatever it is,
is preventing us from discarding any strings from the kernel.
And pin controllers tend to stack up a lot of these.
This is really sucky and something we should solve in general.
I'm not smart enough to tackle any of these problems myself, just
to see them and "Oh that's bad. Very bad."
>> The majority of the improvements over the years have been achieved by
>> moving drivers out of arch/arm and moving board files to DT. The goal
>> was never to get rid of all data.
>
> Sure, not all data. But if we have the relatively easy opportunity to
> avoid further addition of data, we should do it, I believe.
> This significantly reduces the amount of kernel code we need to add to
> support new SoCs.
This is the core of your argument as I perceive it: get rid of data
from the kernel, because it is growing wild. It is a valid cause. Just
has to be weighed with other stuff, like maintainability, debuggability,
maintainers viewpoint. ...
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string
From: Tomi Valkeinen @ 2017-12-01 10:01 UTC (permalink / raw)
To: H. Nikolaus Schaller, Tony Lindgren
Cc: Mark Rutland, DTML, linux-fbdev,
Discussions about the Letux Kernel, Bartlomiej Zolnierkiewicz,
David Airlie, Linux Kernel Mailing List, dri-devel,
Sebastian Reichel, Rob Herring, Russell King, Julia Lawall,
Thierry Reding, Laurent Pinchart, Benoît Cousson, kernel,
linux-omap, Linux ARM
In-Reply-To: <0324FA0E-F06A-41F1-84AD-5BC72F6B6BFF@goldelico.com>
On 01/12/17 11:48, H. Nikolaus Schaller wrote:
> Just a note: there is no toppoly->tpo change for *this* panel and
> Pandora board. Just omapdss removal.
>
> The GTA04 needs a toppoly->tpo change but no omapdss, removal.
>
> So they solve different problems and are independent of each other.
>
> GTA04: change vendor string
> Pandora: remove omapdss, prefix
Oh, right, I totally missed that. I thought they were changes to the
same file...
In that case, Tony, can you pick this one as a fix? I'll pick the
toppoly->tpo patch and merge via drm tree, if you give the ack.
For this:
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v8 01/13] Documentation: Add SLIMbus summary
From: Jonathan Neuschäfer @ 2017-12-01 10:27 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: gregkh, broonie, alsa-devel, sdharia, bp, poeschel, treding,
andreas.noever, alan, mathieu.poirier, daniel, jkosina,
sharon.dvir1, joe, davem, james.hogan, michael.opdenacker,
robh+dt, pawel.moll, mark.rutland, devicetree, linux-kernel,
linux-arm-msm, vinod.koul, arnd
In-Reply-To: <20171130174200.6684-2-srinivas.kandagatla@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 5663 bytes --]
Hi, some small nits below.
On Thu, Nov 30, 2017 at 05:41:48PM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Sagar Dharia <sdharia@codeaurora.org>
>
> SLIMbus (Serial Low Power Interchip Media Bus) is a specification
> developed by MIPI (Mobile Industry Processor Interface) alliance.
> SLIMbus is a 2-wire implementation, which is used to communicate with
> peripheral components like audio-codec.
>
> The summary of SLIMbus and API is documented in the 'summary' file.
>
> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> Documentation/driver-api/slimbus/index.rst | 15 ++++
> Documentation/driver-api/slimbus/summary.rst | 108 +++++++++++++++++++++++++++
> 2 files changed, 123 insertions(+)
> create mode 100644 Documentation/driver-api/slimbus/index.rst
> create mode 100644 Documentation/driver-api/slimbus/summary.rst
It would probably make sense to Cc the documentation maintainers/mailing
list on this patch (AFAICS, you didn't do that).
When do you plan to add slimbus to Documentation/driver-api/index.rst?
> diff --git a/Documentation/driver-api/slimbus/index.rst b/Documentation/driver-api/slimbus/index.rst
> new file mode 100644
> index 000000000000..586f979659e6
> --- /dev/null
> +++ b/Documentation/driver-api/slimbus/index.rst
> @@ -0,0 +1,15 @@
> +=====================
> +SLIMbus Documentation
> +=====================
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + summary
> +
> +.. only:: subproject
> +
> + Indices
> + =======
> +
> + * :ref:`genindex`
> diff --git a/Documentation/driver-api/slimbus/summary.rst b/Documentation/driver-api/slimbus/summary.rst
> new file mode 100644
> index 000000000000..ba165611725a
> --- /dev/null
> +++ b/Documentation/driver-api/slimbus/summary.rst
> @@ -0,0 +1,108 @@
> +============================
> +Linux kernel SLIMbus support
> +============================
> +
> +Overview
> +========
> +
> +What is SLIMbus?
> +----------------
> +SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by
> +MIPI (Mobile Industry Processor Interface) alliance. The bus uses master/slave
> +configuration, and is a 2-wire multi-drop implementation (clock, and data).
> +
> +Currently, SLIMbus is used to interface between application processors of SoCs
> +(System-on-Chip) and peripheral components (typically codec).SLIMbus uses
> +Time-Division-Multiplexing to accommodate multiple data channels, and
> +a control channel.
> +
> +The control channel is used for various control functions such as bus
> +management, configuration and status updates.These messages can be unicast (e.g.
^^ space after period, please
> +reading/writing device specific values), or multicast (e.g. data channel
> +reconfiguration sequence is a broadcast message announced to all devices)
> +
> +A data channel is used for data-transfer between 2 SLIMbus devices. Data
> +channel uses dedicated ports on the device.
> +
[...]
> +
> +Device notifications to the driver:
> +-----------------------------------
> +Since SLIMbus devices have mechanisms for reporting their presence, the
> +framework allows drivers to bind when corresponding devices report their
> +presence on the bus.
> +However, it is possible that the driver needs to be probed
> +first so that it can enable corresponding SLIMbus device (e.g. power it up and/or
> +take it out of reset). To support that behavior, the framework allows drivers
> +to probe first as well (e.g. using standard DeviceTree compatbility field).
Typo: s/compatbility/compatibility/
> +This creates the necessity for the driver to know when the device is functional
> +(i.e. reported present). device_up callback is used for that reason when the
> +device reports present and is assigned a logical address by the controller.
> +
> +Similarly, SLIMbus devices 'report absent' when they go down. A 'device_down'
> +callback notifies the driver when the device reports absent and its logical
> +address assignment is invalidated by the controller.
> +
> +Another notification "boot_device" is used to notify the slim_driver when
> +controller resets the bus. This notification allows the driver to take necessary
> +steps to boot the device so that it's functional after the bus has been reset.
> +
> +Clock-pause:
> +------------
> +SLIMbus mandates that a reconfiguration sequence (known as clock-pause) be
> +broadcast to all active devices on the bus before the bus can enter low-power
> +mode. Controller uses this sequence when it decides to enter low-power mode so
> +that corresponding clocks and/or power-rails can be turned off to save power.
> +Clock-pause is exited by waking up framer device (if controller driver initiates
> +exiting low power mode), or by toggling the data line (if a slave device wants
> +to initiate it).
> +
> +Messaging APIs:
> +---------------
> +The framework supports APIs to exchange control-information with a SLIMbus
> +device. APIs can be synchronous or asynchronous.
> +From controller's perspective, multiple buffers can be queued to/from
> +hardware for sending/receiving data using slim_ctrl_buf circular buffer.
> +The header file <linux/slimbus.h> has more documentation about messaging APIs.
Once the kerneldoc documentation (i.e. the /** ... */ comments in the
source) is included somewhere, I think it would make sense to make
slim_ctrl_buf a clickable link to the struct's documentation.
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] PCI: cadence: Add host driver for Cadence PCIe controller
From: Cyrille Pitchen @ 2017-12-01 10:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, kishon-l0cyMroinI0,
lorenzo.pieralisi-5wv7dgnIgG8, linux-pci-u79uwXL29TY76Z2rM5mHXA,
adouglas-vna1KIf7WgpBDgjK7y7TUQ, stelford-vna1KIf7WgpBDgjK7y7TUQ,
dgary-vna1KIf7WgpBDgjK7y7TUQ, kgopi-vna1KIf7WgpBDgjK7y7TUQ,
eandrews-vna1KIf7WgpBDgjK7y7TUQ,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
sureshp-vna1KIf7WgpBDgjK7y7TUQ, nsekhar-l0cyMroinI0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171128204114.GE11228-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
Hi Bjorn,
Le 28/11/2017 à 21:41, Bjorn Helgaas a écrit :
> On Thu, Nov 23, 2017 at 04:01:48PM +0100, Cyrille Pitchen wrote:
>> This patch adds support to the Cadence PCIe controller in host mode.
>>
>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> ---
>> drivers/Makefile | 1 +
>> drivers/pci/Kconfig | 1 +
>> drivers/pci/cadence/Kconfig | 24 ++
>> drivers/pci/cadence/Makefile | 2 +
>> drivers/pci/cadence/pcie-cadence-host.c | 425 ++++++++++++++++++++++++++++++++
>> drivers/pci/cadence/pcie-cadence.c | 110 +++++++++
>> drivers/pci/cadence/pcie-cadence.h | 325 ++++++++++++++++++++++++
>> 7 files changed, 888 insertions(+)
>> create mode 100644 drivers/pci/cadence/Kconfig
>> create mode 100644 drivers/pci/cadence/Makefile
>> create mode 100644 drivers/pci/cadence/pcie-cadence-host.c
>> create mode 100644 drivers/pci/cadence/pcie-cadence.c
>> create mode 100644 drivers/pci/cadence/pcie-cadence.h
>
> I prefer a single file per driver. I assume you're anticipating
> something like dwc, where the DesignWare core is incorporated into
> several devices in slightly different ways. But it doesn't look like
> that's here yet, and personally, I'd rather split out the required
> things when they actually become required, not ahead of time.
>
The source code in pcie-cadence.c is shared between pcie-cadence-host.c
(Root Complex mode) and pcie-cadence-ep.c (Endpoint mode), the second
driver of this series.
Taking other comments into accounts, I will move endpoint only related
stuff in the pcie-cadence.{c,h} files from this patch to the endpoint
patch.
Otherwise your right, I expect this Cadence PCIe core to be embedded inside
several vendor SoCs but I thought I could handle this as much as possible
using mainly DT properties and/or the 'struct cdns_pcie_*_data' associated
to the DT 'compatible' strings. We will have to wait for those SoCs to be
released to know whether these two solutions are enough or if we will need
dedicated files anyway.
>> diff --git a/drivers/Makefile b/drivers/Makefile
>> index 1d034b680431..27bdd98784d9 100644
>> --- a/drivers/Makefile
>> +++ b/drivers/Makefile
>> @@ -18,6 +18,7 @@ obj-y += pwm/
>>
>> obj-$(CONFIG_PCI) += pci/
>> obj-$(CONFIG_PCI_ENDPOINT) += pci/endpoint/
>> +obj-$(CONFIG_PCI_CADENCE) += pci/cadence/
>
> I can't remember why we added CONFIG_PCI_ENDPOINT here instead of in
> drivers/pci/Makefile. Is there any way to move both CONFIG_PCI_ENDPOINT
> and CONFIG_PCI_CADENCE into drivers/pci/Makefile so this is better
> encapsulated?
>
I will work on the solution I have proposed in another reply since it seems
to be OK for you :)
>> # PCI dwc controller drivers
>> obj-y += pci/dwc/
>> ...
>
>> + * struct cdns_pcie_rc_data - hardware specific data
>
> "cdns" is a weird abbreviation for "Cadence", since "Cadence" doesn't
> contain an "s".
>
>> ...
>> +static int cdns_pcie_parse_request_of_pci_ranges(struct device *dev,
>> + struct list_head *resources,
>> + struct resource **bus_range)
>> +{
>> + int err, res_valid = 0;
>> + struct device_node *np = dev->of_node;
>> + resource_size_t iobase;
>> + struct resource_entry *win, *tmp;
>> +
>> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, resources, &iobase);
>> + if (err)
>> + return err;
>> +
>> + err = devm_request_pci_bus_resources(dev, resources);
>> + if (err)
>> + return err;
>> +
>> + resource_list_for_each_entry_safe(win, tmp, resources) {
>> + struct resource *res = win->res;
>> +
>> + switch (resource_type(res)) {
>> + case IORESOURCE_IO:
>> + err = pci_remap_iospace(res, iobase);
>> + if (err) {
>> + dev_warn(dev, "error %d: failed to map resource %pR\n",
>> + err, res);
>> + resource_list_destroy_entry(win);
>> + }
>> + break;
>> + case IORESOURCE_MEM:
>> + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
>> + break;
>> + case IORESOURCE_BUS:
>> + *bus_range = res;
>> + break;
>> + }
>> + }
>> +
>> + if (res_valid)
>> + return 0;
>> +
>> + dev_err(dev, "non-prefetchable memory resource required\n");
>> + return -EINVAL;
>> +}
>
> The code above is starting to look awfully familiar. I wonder if it's
> time to think about some PCI-internal interface that can encapsulate
> this. In this case, there's really nothing Cadence-specific here.
> There are other callers where there *is* vendor-specific code, but
> possibly that could be handled by returning pointers to bus number,
> I/O port, and MMIO resources so the caller could do the
> vendor-specific stuff?
>
> Bjorn
>
I am listing:
- gen_pci_parse_request_of_pci_ranges() [1]
- cdns_pcie_parse_request_of_pci_ranges() - same as [1]
- advk_pcie_parse_request_of_pci_ranges()
- altera_pcie_parse_request_of_pci_ranges()
- versatile_pci_parse_request_of_pci_ranges()
- rcar_pcie_parse_request_of_pci_ranges()
Then what about doing something like that:
---8<--------------------------------------------------------------------------
diff --git a/drivers/pci/host/pci-host-common.c b/drivers/pci/host/pci-host-common.c
index 44a47d4f0b8f..2413c5d83cbd 100644
--- a/drivers/pci/host/pci-host-common.c
+++ b/drivers/pci/host/pci-host-common.c
@@ -24,10 +24,19 @@
#include <linux/pci-ecam.h>
#include <linux/platform_device.h>
-static int gen_pci_parse_request_of_pci_ranges(struct device *dev,
- struct list_head *resources, struct resource **bus_range)
+struct pci_host_resource_parser {
+ int (*get_resource)(void *userdata, struct resource_entry *win,
+ resource_size_t iobase);
+ int (*finalize)(void *userdata);
+ void (*abort)(void *userdata);
+};
+
+int pci_host_parse_request_of_pci_ranges(struct device *dev,
+ struct list_head *resources,
+ const struct pci_host_resource_parser *parser,
+ void *userdata)
{
- int err, res_valid = 0;
+ int err;
struct device_node *np = dev->of_node;
resource_size_t iobase;
struct resource_entry *win, *tmp;
@@ -40,34 +49,94 @@ static int gen_pci_parse_request_of_pci_ranges(struct device *dev,
if (err)
return err;
- resource_list_for_each_entry_safe(win, tmp, resources) {
- struct resource *res = win->res;
-
- switch (resource_type(res)) {
- case IORESOURCE_IO:
- err = pci_remap_iospace(res, iobase);
- if (err) {
- dev_warn(dev, "error %d: failed to map resource %pR\n",
- err, res);
- resource_list_destroy_entry(win);
- }
- break;
- case IORESOURCE_MEM:
- res_valid |= !(res->flags & IORESOURCE_PREFETCH);
- break;
- case IORESOURCE_BUS:
- *bus_range = res;
- break;
+ if (parser && parser->get_resource) {
+ resource_list_for_each_entry_safe(win, tmp, resources) {
+ err = parser->get_resource(userdata, win, iobase);
+ if (err)
+ goto do_abort;
+ }
+ }
+
+ if (parser && parser->finalize)
+ return parser->finalize(userdata);
+
+ return 0;
+
+ do_abort:
+ if (parser && parser->abort)
+ parser->abort(userdata);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(pci_host_parse_request_of_pci_ranges);
+
+
+struct gen_pci_parser_context {
+ struct device *dev;
+ struct resource **bus_range;
+ int res_valid;
+};
+
+static int gen_pci_resource_parser_get_resource(void *userdata,
+ struct resource_entry *win,
+ resource_size_t iobase)
+{
+ struct gen_pci_parser_context *ctx = userdata;
+ struct device *dev = ctx->dev;
+ struct resource *res = win->res;
+ int err;
+
+ switch (resource_type(res)) {
+ case IORESOURCE_IO:
+ err = pci_remap_iospace(res, iobase);
+ if (err) {
+ dev_warn(dev, "error %d: failed to map resource %pR\n",
+ err, res);
+ resource_list_destroy_entry(win);
}
+ break;
+ case IORESOURCE_MEM:
+ ctx->res_valid |= !(res->flags & IORESOURCE_PREFETCH);
+ break;
+ case IORESOURCE_BUS:
+ *ctx->bus_range = res;
+ break;
}
- if (res_valid)
+ return 0;
+}
+
+static int gen_pci_resource_parser_finalize(void *userdata)
+{
+ struct gen_pci_parser_context *ctx = userdata;
+ struct device *dev = ctx->dev;
+
+ if (ctx->res_valid)
return 0;
dev_err(dev, "non-prefetchable memory resource required\n");
return -EINVAL;
}
+static const struct pci_host_resource_parser gen_pci_resource_parser = {
+ .get_resource = gen_pci_resource_parser_get_resource,
+ .finalize = gen_pci_resource_parser_finalize,
+};
+
+static int gen_pci_parse_request_of_pci_ranges(struct device *dev,
+ struct list_head *resources, struct resource **bus_range)
+{
+ struct gen_pci_parser_context ctx;
+
+ ctx.dev = dev;
+ ctx.bus_range = bus_range;
+ ctx.res_valid = 0;
+
+ return pci_host_parse_request_of_pci_ranges(dev, resources,
+ &gen_pci_resource_parser,
+ &ctx);
+}
+
static void gen_pci_unmap_cfg(void *ptr)
{
pci_ecam_free((struct pci_config_window *)ptr);
---8<--------------------------------------------------------------------------
Best regards,
Cyrille
--
Cyrille Pitchen, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 0/4] ARM: dts: renesas: Convert to named i2c-gpio bindings
From: Wolfram Sang @ 2017-12-01 11:09 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Magnus Damm, Wolfram Sang, Linus Walleij,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171201081850.4tqbnlvxdax7phfs-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]
On Fri, Dec 01, 2017 at 09:18:55AM +0100, Simon Horman wrote:
> On Thu, Nov 30, 2017 at 01:57:22PM +0100, Geert Uytterhoeven wrote:
> > Hi Simon, Magnus,
> >
> > Commits 7d29f509d2cfd807 ("dt-bindings: i2c: i2c-gpio: Add support for
> > named gpios") and 05c74778858d7d99 ("i2c: gpio: Add support for named
> > gpios in DT") introduced named i2c-gpio DT bindings, and deprecated the
> > more error-prone unnamed variant.
> >
> > This patch series switches all Renesas boards to the new bindings, and
> > adds the missing GPIO_OPEN_DRAIN I/O flags, which were implicitly
> > assumed before. The latter gets rid of messages like:
> >
> > gpio-208 (?): enforced open drain please flag it properly in DT/ACPI DSDT/board file
> > gpio-91 (?): enforced open drain please flag it properly in DT/ACPI DSDT/board file
> >
> > Patch 1 was extracted from series "[PATCH/RFC 0/3] i2c: gpio: Add
> > support for named gpios in DT", hence the v2. All other patches are
> > new.
> >
> > Note that after this series is applied, the i2c-gpio buses are no longer
> > detected when booting new DTBs on old (v4.14 and older) kernels, which
> > should not be an issue. Booting old DTBs on new kernels is not
> > affected.
> >
> > Thanks for applying!
>
> Thanks, applied.
Phew, you guys are fast. For the record:
Reviewed-by: Wolfram Sang <wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [patch v12 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver
From: Oleksandr Shamray @ 2017-12-01 11:11 UTC (permalink / raw)
To: 'Kun Yi'
Cc: gregkh@linuxfoundation.org, arnd@arndb.de, system-sw-low-level,
devicetree@vger.kernel.org, jiri@resnulli.us, Vadim Pasternak,
linux-api@vger.kernel.org, OpenBMC Maillist,
linux-kernel@vger.kernel.org,
openocd-devel-owner@lists.sourceforge.net, mec@shout.net,
Jiri Pirko, robh+dt@kernel.org, linux-serial@vger.kernel.org,
tklauser@distanz.ch, mchehab
In-Reply-To: <CAGMNF6XRwU5QEJhkg-mVwE5zpPigtcGJtRUupZHtcWRdedcsxg@mail.gmail.com>
> -----Original Message-----
> From: Kun Yi [mailto:kunyi@google.com]
> Sent: Thursday, November 30, 2017 12:51 AM
> To: Oleksandr Shamray <oleksandrs@mellanox.com>
> Cc: gregkh@linuxfoundation.org; arnd@arndb.de; system-sw-low-level
> <system-sw-low-level@mellanox.com>; devicetree@vger.kernel.org;
> jiri@resnulli.us; Vadim Pasternak <vadimp@mellanox.com>; linux-
> api@vger.kernel.org; OpenBMC Maillist <openbmc@lists.ozlabs.org>; linux-
> kernel@vger.kernel.org; openocd-devel-owner@lists.sourceforge.net;
> mec@shout.net; Jiri Pirko <jiri@mellanox.com>; robh+dt@kernel.org; linux-
> serial@vger.kernel.org; tklauser@distanz.ch; mchehab@kernel.org;
> davem@davemloft.net; linux-arm-kernel@lists.infradead.org
> Subject: Re: [patch v12 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx
> families JTAG master driver
>
> Thanks for working on the driver, Oleksandr. I gave this a try on a board with
> Aspeed 2520. One question below:
>
> On Tue, Nov 14, 2017 at 8:11 AM, Oleksandr Shamray
> <oleksandrs@mellanox.com> wrote:
> > Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.
> >
> > Driver implements the following jtag ops:
> > - freq_get;
> > - freq_set;
> > - status_get;
> > - idle;
> > - xfer;
> >
[..]
> > +
> > +static const struct jtag_ops aspeed_jtag_ops = {
> > + .freq_get = aspeed_jtag_freq_get,
> > + .freq_set = aspeed_jtag_freq_set,
> > + .status_get = aspeed_jtag_status_get,
> > + .idle = aspeed_jtag_idle,
> > + .xfer = aspeed_jtag_xfer,
> > + .mode_set = aspeed_jtag_mode_set };
> > +
> > +static int aspeed_jtag_probe(struct platform_device *pdev) {
> > + struct aspeed_jtag *aspeed_jtag;
> > + struct jtag *jtag;
> > + int err;
> > +
> > + if (!of_device_is_compatible(pdev->dev.of_node,
> > + "aspeed,aspeed-jtag"))
>
> Should this be "aspeed,ast2400-jtag"/"aspeed,ast2500-jtag" as specified in the
> compatible string below?
>
Yes
> > + return -ENOMEM;
> > +
> > + jtag = jtag_alloc(sizeof(*aspeed_jtag), &aspeed_jtag_ops);
> > + if (!jtag)
> > + return -ENODEV;
> > +
> > + platform_set_drvdata(pdev, jtag);
> > + aspeed_jtag = jtag_priv(jtag);
> > + aspeed_jtag->dev = &pdev->dev;
> > +
[..]
> > +
> > +MODULE_AUTHOR("Oleksandr Shamray <oleksandrs@mellanox.com>");
> > +MODULE_DESCRIPTION("ASPEED JTAG driver"); MODULE_LICENSE("GPL
> v2");
> > --
> > 1.7.1
> >
> --
> Regards,
> Kun
Thanks.
BR
Oleksandr Shamray
^ permalink raw reply
* [PATCH 0/6] Add CPU Frequency scaling support on Armada 37xx
From: Gregory CLEMENT @ 2017-12-01 11:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, linux-pm-u79uwXL29TY76Z2rM5mHXA
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Antoine Tenart,
Miquèl Raynal, Nadav Haklai, Victor Gu, Marcin Wojtas,
Wilson Ding, Hua Jing, Neta Zur Hershkovits, Evan Wang
Hi,
This series adds the CPU Frequency support on Armada 37xx using
DVFS. It is based on the initial work of Evan Wang and Victor Gu.
DVFS control is done by a set of registers from the North Bridge Power
Management block. The binding for this block is documented in patch 1.
While adding a new cpufreq driver I found that the Kconfig and
Makefile were no more in order, so it is fixed by patch 2 and 3.
The 4th patch is just about updating the MAINTAINERS file with the new
driver.
The next patch is the real purpose of the series. The main goal of
this driver is to setup the CPU load level in the hardware to
associate them to CPU frequencies and register a standard cpufreq
driver. Note that the hardware also capable of doing AVS (Adaptive
Voltage Scaling), by associating a voltage on each level beside the
CPU frequency. However, this support is not yet ready, so it is not
part of this series.
Finally, the last patch is for arm-soc the arm-soc subsystem through
mvebu and update the device tree to support the CPU frequency scaling.
An update on the CPU clock driver is needed in order to take into
account the DVFS setting. It's the purpose of an other series already
sent, but is no dependencies between the series (for building or at
runtime).
Thanks,
Gregory
Gregory CLEMENT (6):
dt-bindings: marvell: Add documentation for the North Bridge PM on
Armada 37xx
cpufreq: ARM: sort the Kconfig menu
cpufreq: sort the drivers in ARM part
MAINTAINERS: add new entries for Armada 37xx cpufreq driver
cpufreq: Add DVFS support for Armada 37xx
arm64: dts: marvell: armada-37xx: add nodes allowing cpufreq support
.../bindings/arm/marvell/armada-37xx.txt | 19 ++
MAINTAINERS | 1 +
arch/arm64/boot/dts/marvell/armada-372x.dtsi | 1 +
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +
drivers/cpufreq/Kconfig.arm | 89 ++++----
drivers/cpufreq/Makefile | 9 +-
drivers/cpufreq/armada-37xx-cpufreq.c | 241 +++++++++++++++++++++
7 files changed, 322 insertions(+), 45 deletions(-)
create mode 100644 drivers/cpufreq/armada-37xx-cpufreq.c
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/6] dt-bindings: marvell: Add documentation for the North Bridge PM on Armada 37xx
From: Gregory CLEMENT @ 2017-12-01 11:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, linux-pm
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
Rob Herring, devicetree, Thomas Petazzoni, linux-arm-kernel,
Antoine Tenart, Miquèl Raynal, Nadav Haklai, Victor Gu,
Marcin Wojtas, Wilson Ding, Hua Jing, Neta Zur Hershkovits,
Evan Wang
In-Reply-To: <20171201112508.14121-1-gregory.clement@free-electrons.com>
Extend the documentation of the Armada 37xx SoC with the the North
Bridge Power Management component.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../devicetree/bindings/arm/marvell/armada-37xx.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
index 51336e5fc761..7ad9830d9177 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
@@ -14,3 +14,22 @@ following property before the previous one:
Example:
compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
+
+
+Power management
+----------------
+
+For power management (particularly DVFS and AVS), the North Bridge
+Power Management component is needed:
+
+Required properties:
+- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
+- reg : the register start and length for the North Bridge
+ Power Management
+
+Example:
+
+nb_pm: nb_pm@14000 {
+ compatible = "marvell,armada-3700-nb-pm", "syscon";
+ reg = <0x14000 0x60>;
+}
--
2.15.0
^ permalink raw reply related
* [PATCH 2/6] cpufreq: ARM: sort the Kconfig menu
From: Gregory CLEMENT @ 2017-12-01 11:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, linux-pm
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
Rob Herring, devicetree, Thomas Petazzoni, linux-arm-kernel,
Antoine Tenart, Miquèl Raynal, Nadav Haklai, Victor Gu,
Marcin Wojtas, Wilson Ding, Hua Jing, Neta Zur Hershkovits,
Evan Wang
In-Reply-To: <20171201112508.14121-1-gregory.clement@free-electrons.com>
Group all the related big LITTLE configuration together and sort the
other entries in alphabetic order.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/cpufreq/Kconfig.arm | 82 ++++++++++++++++++++++-----------------------
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index bdce4488ded1..17625115c67f 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -2,6 +2,23 @@
# ARM CPU Frequency scaling drivers
#
+config ACPI_CPPC_CPUFREQ
+ tristate "CPUFreq driver based on the ACPI CPPC spec"
+ depends on ACPI_PROCESSOR
+ select ACPI_CPPC_LIB
+ default n
+ help
+ This adds a CPUFreq driver which uses CPPC methods
+ as described in the ACPIv5.1 spec. CPPC stands for
+ Collaborative Processor Performance Controls. It
+ is based on an abstract continuous scale of CPU
+ performance values which allows the remote power
+ processor to flexibly optimize for power and
+ performance. CPPC relies on power management firmware
+ support for its operation.
+
+ If in doubt, say N.
+
# big LITTLE core layer and glue drivers
config ARM_BIG_LITTLE_CPUFREQ
tristate "Generic ARM big LITTLE CPUfreq driver"
@@ -12,6 +29,30 @@ config ARM_BIG_LITTLE_CPUFREQ
help
This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
+config ARM_DT_BL_CPUFREQ
+ tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
+ depends on ARM_BIG_LITTLE_CPUFREQ && OF
+ help
+ This enables probing via DT for Generic CPUfreq driver for ARM
+ big.LITTLE platform. This gets frequency tables from DT.
+
+config ARM_VEXPRESS_SPC_CPUFREQ
+ tristate "Versatile Express SPC based CPUfreq driver"
+ depends on ARM_BIG_LITTLE_CPUFREQ && ARCH_VEXPRESS_SPC
+ help
+ This add the CPUfreq driver support for Versatile Express
+ big.LITTLE platforms using SPC for power management.
+
+config ARM_SCPI_CPUFREQ
+ tristate "SCPI based CPUfreq driver"
+ depends on ARM_BIG_LITTLE_CPUFREQ && ARM_SCPI_PROTOCOL && COMMON_CLK_SCPI
+ help
+ This adds the CPUfreq driver support for ARM big.LITTLE platforms
+ using SCPI protocol for CPU power management.
+
+ This driver uses SCPI Message Protocol driver to interact with the
+ firmware providing the CPU DVFS functionality.
+
config ARM_BRCMSTB_AVS_CPUFREQ
tristate "Broadcom STB AVS CPUfreq driver"
depends on ARCH_BRCMSTB || COMPILE_TEST
@@ -33,20 +74,6 @@ config ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
If in doubt, say N.
-config ARM_DT_BL_CPUFREQ
- tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
- depends on ARM_BIG_LITTLE_CPUFREQ && OF
- help
- This enables probing via DT for Generic CPUfreq driver for ARM
- big.LITTLE platform. This gets frequency tables from DT.
-
-config ARM_VEXPRESS_SPC_CPUFREQ
- tristate "Versatile Express SPC based CPUfreq driver"
- depends on ARM_BIG_LITTLE_CPUFREQ && ARCH_VEXPRESS_SPC
- help
- This add the CPUfreq driver support for Versatile Express
- big.LITTLE platforms using SPC for power management.
-
config ARM_EXYNOS5440_CPUFREQ
tristate "SAMSUNG EXYNOS5440"
depends on SOC_EXYNOS5440
@@ -205,16 +232,6 @@ config ARM_SA1100_CPUFREQ
config ARM_SA1110_CPUFREQ
bool
-config ARM_SCPI_CPUFREQ
- tristate "SCPI based CPUfreq driver"
- depends on ARM_BIG_LITTLE_CPUFREQ && ARM_SCPI_PROTOCOL && COMMON_CLK_SCPI
- help
- This adds the CPUfreq driver support for ARM big.LITTLE platforms
- using SCPI protocol for CPU power management.
-
- This driver uses SCPI Message Protocol driver to interact with the
- firmware providing the CPU DVFS functionality.
-
config ARM_SPEAR_CPUFREQ
bool "SPEAr CPUFreq support"
depends on PLAT_SPEAR
@@ -275,20 +292,3 @@ config ARM_PXA2xx_CPUFREQ
This add the CPUFreq driver support for Intel PXA2xx SOCs.
If in doubt, say N.
-
-config ACPI_CPPC_CPUFREQ
- tristate "CPUFreq driver based on the ACPI CPPC spec"
- depends on ACPI_PROCESSOR
- select ACPI_CPPC_LIB
- default n
- help
- This adds a CPUFreq driver which uses CPPC methods
- as described in the ACPIv5.1 spec. CPPC stands for
- Collaborative Processor Performance Controls. It
- is based on an abstract continuous scale of CPU
- performance values which allows the remote power
- processor to flexibly optimize for power and
- performance. CPPC relies on power management firmware
- support for its operation.
-
- If in doubt, say N.
--
2.15.0
^ permalink raw reply related
* [PATCH 3/6] cpufreq: sort the drivers in ARM part
From: Gregory CLEMENT @ 2017-12-01 11:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, linux-pm
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
Rob Herring, devicetree, Thomas Petazzoni, linux-arm-kernel,
Antoine Tenart, Miquèl Raynal, Nadav Haklai, Victor Gu,
Marcin Wojtas, Wilson Ding, Hua Jing, Neta Zur Hershkovits,
Evan Wang
In-Reply-To: <20171201112508.14121-1-gregory.clement@free-electrons.com>
Keep the driver files alphabetically sorted.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/cpufreq/Makefile | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 812f9e0d01a3..d762e76887e7 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -53,22 +53,24 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ) += arm_big_little.o
obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o
obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o
+obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o
+obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
-obj-$(CONFIG_ARM_S3C24XX_CPUFREQ) += s3c24xx-cpufreq.o
-obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
obj-$(CONFIG_ARM_S3C2440_CPUFREQ) += s3c2440-cpufreq.o
obj-$(CONFIG_ARM_S3C64XX_CPUFREQ) += s3c64xx-cpufreq.o
+obj-$(CONFIG_ARM_S3C24XX_CPUFREQ) += s3c24xx-cpufreq.o
+obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
obj-$(CONFIG_ARM_S5PV210_CPUFREQ) += s5pv210-cpufreq.o
obj-$(CONFIG_ARM_SA1100_CPUFREQ) += sa1100-cpufreq.o
obj-$(CONFIG_ARM_SA1110_CPUFREQ) += sa1110-cpufreq.o
@@ -81,8 +83,6 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o
obj-$(CONFIG_ARM_TEGRA186_CPUFREQ) += tegra186-cpufreq.o
obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o
obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
-obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
-obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
##################################################################################
--
2.15.0
^ permalink raw reply related
* [PATCH 4/6] MAINTAINERS: add new entries for Armada 37xx cpufreq driver
From: Gregory CLEMENT @ 2017-12-01 11:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, linux-pm-u79uwXL29TY76Z2rM5mHXA
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Antoine Tenart,
Miquèl Raynal, Nadav Haklai, Victor Gu, Marcin Wojtas,
Wilson Ding, Hua Jing, Neta Zur Hershkovits, Evan Wang
In-Reply-To: <20171201112508.14121-1-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
This new driver belongs to the mvebu family, update the MAINTAINER file
to document it.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..98dcee849481 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1582,6 +1582,7 @@ F: arch/arm/boot/dts/kirkwood*
F: arch/arm/configs/mvebu_*_defconfig
F: arch/arm/mach-mvebu/
F: arch/arm64/boot/dts/marvell/armada*
+F: drivers/cpufreq/armada-37xx-cpufreq.c
F: drivers/cpufreq/mvebu-cpufreq.c
F: drivers/irqchip/irq-armada-370-xp.c
F: drivers/irqchip/irq-mvebu-*
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 5/6] cpufreq: Add DVFS support for Armada 37xx
From: Gregory CLEMENT @ 2017-12-01 11:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, linux-pm
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
Rob Herring, devicetree, Thomas Petazzoni, linux-arm-kernel,
Antoine Tenart, Miquèl Raynal, Nadav Haklai, Victor Gu,
Marcin Wojtas, Wilson Ding, Hua Jing, Neta Zur Hershkovits,
Evan Wang
In-Reply-To: <20171201112508.14121-1-gregory.clement@free-electrons.com>
This patch adds DVFS support for the Armada 37xx SoCs
There are up to four CPU frequency loads for Armada 37xx controlled by
the hardware.
This driver associates the CPU load level to a frequency, then the
hardware will switch while selecting a load level.
The hardware also can associate a voltage for each level (AVS support)
but it is not yet supported
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/cpufreq/Kconfig.arm | 7 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/armada-37xx-cpufreq.c | 241 ++++++++++++++++++++++++++++++++++
3 files changed, 249 insertions(+)
create mode 100644 drivers/cpufreq/armada-37xx-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 17625115c67f..3018ff0d068f 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -19,6 +19,13 @@ config ACPI_CPPC_CPUFREQ
If in doubt, say N.
+config ARM_ARMADA_37XX_CPUFREQ
+ tristate "Armada 37xx CPUFreq support"
+ depends on ARCH_MVEBU
+ help
+ This adds the CPUFreq driver support for Marvell Armada 37xx SoCs.
+ The Armada 37xx PMU supports 4 frequency and VDD levels.
+
# big LITTLE core layer and glue drivers
config ARM_BIG_LITTLE_CPUFREQ
tristate "Generic ARM big LITTLE CPUfreq driver"
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index d762e76887e7..e07715ce8844 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ) += arm_big_little.o
# LITTLE drivers, so that it is probed last.
obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o
+obj-$(CONFIG_ARM_ARMADA_37XX_CPUFREQ) += armada-37xx-cpufreq.o
obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o
obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c
new file mode 100644
index 000000000000..40c9a744cc6e
--- /dev/null
+++ b/drivers/cpufreq/armada-37xx-cpufreq.c
@@ -0,0 +1,241 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CPU frequency scaling support for Armada 37xx platform.
+ *
+ * Copyright (C) 2017 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/cpu.h>
+#include <linux/cpufreq.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+/* Power management in North Bridge register set */
+#define ARMADA_37XX_NB_L0L1 0x18
+#define ARMADA_37XX_NB_L2L3 0x1C
+#define ARMADA_37XX_NB_TBG_DIV_OFF 13
+#define ARMADA_37XX_NB_TBG_DIV_MASK 0x7
+#define ARMADA_37XX_NB_CLK_SEL_OFF 11
+#define ARMADA_37XX_NB_CLK_SEL_MASK 0x1
+#define ARMADA_37XX_NB_CLK_SEL_TBG 0x1
+#define ARMADA_37XX_NB_TBG_SEL_OFF 9
+#define ARMADA_37XX_NB_TBG_SEL_MASK 0x3
+#define ARMADA_37XX_NB_VDD_SEL_OFF 6
+#define ARMADA_37XX_NB_VDD_SEL_MASK 0x3
+#define ARMADA_37XX_NB_CONFIG_SHIFT 16
+#define ARMADA_37XX_NB_DYN_MOD 0x24
+#define ARMADA_37XX_NB_CLK_SEL_EN BIT(26)
+#define ARMADA_37XX_NB_TBG_EN BIT(28)
+#define ARMADA_37XX_NB_DIV_EN BIT(29)
+#define ARMADA_37XX_NB_VDD_EN BIT(30)
+#define ARMADA_37XX_NB_DFS_EN BIT(31)
+#define ARMADA_37XX_NB_CPU_LOAD 0x30
+#define ARMADA_37XX_NB_CPU_LOAD_MASK 0x3
+#define ARMADA_37XX_DVFS_LOAD_0 0
+#define ARMADA_37XX_DVFS_LOAD_1 1
+#define ARMADA_37XX_DVFS_LOAD_2 2
+#define ARMADA_37XX_DVFS_LOAD_3 3
+
+/*
+ * On Armada 37xx the Power management manages 4 level of CPU load,
+ * each level can be associated with a CPU clock source, a CPU
+ * divider, a VDD level, etc...
+ */
+#define LOAD_LEVEL_NR 4
+
+struct armada_37xx_dvfs {
+ u32 cpu_freq_max;
+ u8 divider[LOAD_LEVEL_NR];
+};
+
+static struct armada_37xx_dvfs armada_37xx_dvfs[] = {
+ {.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} },
+ {.cpu_freq_max = 1000*1000*1000, .divider = {1, 2, 4, 5} },
+ {.cpu_freq_max = 800*1000*1000, .divider = {1, 2, 3, 4} },
+ {.cpu_freq_max = 600*1000*1000, .divider = {2, 4, 5, 6} },
+};
+
+static struct armada_37xx_dvfs *armada_37xx_cpu_freq_info_get(u32 freq)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(armada_37xx_dvfs); i++) {
+ if (freq == armada_37xx_dvfs[i].cpu_freq_max)
+ return &armada_37xx_dvfs[i];
+ }
+
+ pr_err("Unsupported CPU frequency %d MHz\n", freq/1000000);
+ return NULL;
+}
+
+/*
+ * Setup the four level managed by the hardware. Once the four level
+ * will be configured then the DVFS will be enabled.
+ */
+static void __init armada37xx_cpufreq_dvfs_setup(struct regmap *base,
+ struct clk *clk, u8 *divider)
+{
+ int load_level;
+ struct clk *parent;
+
+ for (load_level = 0; load_level < LOAD_LEVEL_NR; load_level++) {
+ unsigned int reg, mask, val, offset = 0;
+
+ if (load_level <= ARMADA_37XX_DVFS_LOAD_1)
+ reg = ARMADA_37XX_NB_L0L1;
+ else
+ reg = ARMADA_37XX_NB_L2L3;
+
+ if (load_level == ARMADA_37XX_DVFS_LOAD_0 ||
+ load_level == ARMADA_37XX_DVFS_LOAD_2)
+ offset += ARMADA_37XX_NB_CONFIG_SHIFT;
+
+ /* Set cpu clock source, for all the level we use TBG */
+ val = ARMADA_37XX_NB_CLK_SEL_TBG << ARMADA_37XX_NB_CLK_SEL_OFF;
+ mask = (ARMADA_37XX_NB_CLK_SEL_MASK
+ << ARMADA_37XX_NB_CLK_SEL_OFF);
+
+ /*
+ * Set cpu divider based on the pre-computed array in
+ * order to have balanced step.
+ */
+ val |= divider[load_level] << ARMADA_37XX_NB_TBG_DIV_OFF;
+ mask |= (ARMADA_37XX_NB_TBG_DIV_MASK
+ << ARMADA_37XX_NB_TBG_DIV_OFF);
+
+ /* Set VDD divider which is actually the load level. */
+ val |= load_level << ARMADA_37XX_NB_VDD_SEL_OFF;
+ mask |= (ARMADA_37XX_NB_VDD_SEL_MASK
+ << ARMADA_37XX_NB_VDD_SEL_OFF);
+
+ val <<= offset;
+ mask <<= offset;
+
+ regmap_update_bits(base, reg, mask, val);
+ }
+
+ /*
+ * Set cpu clock source, for all the level we keep the same
+ * clock source that the one already configured. For this one
+ * we need to use the clock framework
+ */
+ parent = clk_get_parent(clk);
+ clk_set_parent(clk, parent);
+}
+
+static void __init armada37xx_cpufreq_disable_dvfs(struct regmap *base)
+{
+ unsigned int reg = ARMADA_37XX_NB_DYN_MOD,
+ mask = ARMADA_37XX_NB_DFS_EN;
+
+ regmap_update_bits(base, reg, mask, 0);
+}
+
+static void __init armada37xx_cpufreq_enable_dvfs(struct regmap *base)
+{
+ unsigned int val, reg = ARMADA_37XX_NB_CPU_LOAD,
+ mask = ARMADA_37XX_NB_CPU_LOAD_MASK;
+
+ /* Start with the highest load (0) */
+ val = ARMADA_37XX_DVFS_LOAD_0;
+ regmap_update_bits(base, reg, mask, val);
+
+ /* Now enable DVFS for the CPUs */
+ reg = ARMADA_37XX_NB_DYN_MOD;
+ mask = ARMADA_37XX_NB_CLK_SEL_EN | ARMADA_37XX_NB_TBG_EN |
+ ARMADA_37XX_NB_DIV_EN | ARMADA_37XX_NB_VDD_EN |
+ ARMADA_37XX_NB_DFS_EN;
+
+ regmap_update_bits(base, reg, mask, mask);
+}
+
+static int __init armada37xx_cpufreq_driver_init(void)
+{
+ struct armada_37xx_dvfs *dvfs;
+ struct platform_device *pdev;
+ unsigned int cur_frequency;
+ struct regmap *nb_pm_base;
+ struct device *cpu_dev;
+ int load_level, ret;
+ struct clk *clk;
+
+ nb_pm_base =
+ syscon_regmap_lookup_by_compatible("marvell,armada-3700-nb-pm");
+
+ if (IS_ERR(nb_pm_base))
+ return -ENODEV;
+
+ /* Before doing any configuration on the DVFS first, disable it */
+ armada37xx_cpufreq_disable_dvfs(nb_pm_base);
+
+ /*
+ * On CPU 0 register the operating points supported (which are
+ * the nominal CPU frequency and full integer divisions of
+ * it).
+ */
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev) {
+ dev_err(cpu_dev, "Cannot get CPU\n");
+ return -ENODEV;
+ }
+
+ clk = clk_get(cpu_dev, 0);
+ if (IS_ERR(clk)) {
+ dev_err(cpu_dev, "Cannot get clock for CPU0\n");
+ return PTR_ERR(clk);
+ }
+
+ /* Get nominal (current) CPU frequency */
+ cur_frequency = clk_get_rate(clk);
+ if (!cur_frequency) {
+ dev_err(cpu_dev, "Failed to get clock rate for CPU\n");
+ return -EINVAL;
+ }
+
+ dvfs = armada_37xx_cpu_freq_info_get(cur_frequency);
+ if (!dvfs)
+ return -EINVAL;
+
+ armada37xx_cpufreq_dvfs_setup(nb_pm_base, clk, dvfs->divider);
+
+ /*
+ * In case of a failure of dev_pm_opp_add(), we don't bother
+ * with cleaning up the registered OPP (there's no function to
+ * do so), and simply cancel the registration of the cpufreq
+ * device.
+ */
+ for (load_level = ARMADA_37XX_DVFS_LOAD_0; load_level < LOAD_LEVEL_NR;
+ load_level++) {
+ unsigned long freq = dvfs->divider[load_level];
+
+ ret = dev_pm_opp_add(cpu_dev, freq, 0);
+ if (ret)
+ return ret;
+ }
+
+ /* Now that everything is setup, enable the DVFS at hardware level */
+ armada37xx_cpufreq_enable_dvfs(nb_pm_base);
+
+ pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+
+ return PTR_ERR_OR_ZERO(pdev);
+}
+/* late_initcall, to guarantee the driver is loaded after A37xx clock driver */
+late_initcall(armada37xx_cpufreq_driver_init);
+
+MODULE_AUTHOR("Gregory CLEMENT <gregory.clement@free-electrons.com>");
+MODULE_DESCRIPTION("Armada 37xx cpufreq driver");
+MODULE_LICENSE("GPL");
--
2.15.0
^ permalink raw reply related
* [PATCH 6/6] arm64: dts: marvell: armada-37xx: add nodes allowing cpufreq support
From: Gregory CLEMENT @ 2017-12-01 11:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, linux-pm
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
Rob Herring, devicetree, Thomas Petazzoni, linux-arm-kernel,
Antoine Tenart, Miquèl Raynal, Nadav Haklai, Victor Gu,
Marcin Wojtas, Wilson Ding, Hua Jing, Neta Zur Hershkovits,
Evan Wang
In-Reply-To: <20171201112508.14121-1-gregory.clement@free-electrons.com>
In order to be able to use cpu freq, we need to associate a clock to each
CPU and to expose the power management registers.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-372x.dtsi | 1 +
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
index 59d7557d3b1b..2554e0baea6b 100644
--- a/arch/arm64/boot/dts/marvell/armada-372x.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
@@ -56,6 +56,7 @@
device_type = "cpu";
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x1>;
+ clocks = <&nb_periph_clk 16>;
enable-method = "psci";
};
};
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 90c26d616a54..6e51ed54d75c 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -65,6 +65,7 @@
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0>;
+ clocks = <&nb_periph_clk 16>;
enable-method = "psci";
};
};
@@ -234,6 +235,12 @@
};
};
+ nb_pm: nb_pm@14000 {
+ compatible = "marvell,armada-3700-nb-pm",
+ "syscon";
+ reg = <0x14000 0x60>;
+ };
+
pinctrl_sb: pinctrl@18800 {
compatible = "marvell,armada3710-sb-pinctrl",
"syscon", "simple-mfd";
--
2.15.0
^ permalink raw reply related
* [PATCH] arm64: dts: exynos: increase bus frequency for MHL chip
From: Andrzej Hajda @ 2017-12-01 11:33 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <CGME20171201113426eucas1p247ef5f5113c466409f0a001297aaf9b6@eucas1p2.samsung.com>
sii8620 supports 1MHz clock, it allows faster transmissions and according
to extensive tests allows to mitigate some obscure bugs in I2C client
logic of the chip.
Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 39b1ca0ef4cd..a4b1d9ba7e4b 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -778,6 +778,7 @@
&hsi2c_7 {
status = "okay";
+ clock-frequency = <1000000>;
sii8620@39 {
reg = <0x39>;
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 3/3] arm: dts: mt7623: fix card detection issue on bananapi-r2
From: Matthias Brugger @ 2017-12-01 11:42 UTC (permalink / raw)
To: sean.wang, robh+dt, mark.rutland, devicetree, linux-mediatek
Cc: linux-arm-kernel, linux-kernel
In-Reply-To: <88269ed11bdf881087f7b0de331a60d8acfdc977.1511949769.git.sean.wang@mediatek.com>
On 11/29/2017 11:10 AM, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Fix that bananapi-r2 booting from SD-card would fail since incorrect
> polarity is applied to the previous setup with GPIO_ACTIVE_HIGH.
>
> Cc: stable@vger.kernel.org # v4.14+
> Fixes: 0eed8d097612 ("arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2")
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
Tested-by: Matthias Brugger <matthias.bgg@gmail.com>
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> index 688a863..7bf5aa2 100644
> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> @@ -204,7 +204,7 @@
> bus-width = <4>;
> max-frequency = <50000000>;
> cap-sd-highspeed;
> - cd-gpios = <&pio 261 0>;
> + cd-gpios = <&pio 261 GPIO_ACTIVE_LOW>;
> vmmc-supply = <&mt6323_vmch_reg>;
> vqmmc-supply = <&mt6323_vio18_reg>;
> };
>
^ permalink raw reply
* Re: [PATCH v3 0/3] drm/omap: Support for dispc memory bandwidth limit
From: Tomi Valkeinen @ 2017-12-01 11:54 UTC (permalink / raw)
To: Peter Ujfalusi, laurent.pinchart; +Cc: airlied, devicetree, jsarha, dri-devel
In-Reply-To: <20171130121237.30431-1-peter.ujfalusi@ti.com>
On 30/11/17 14:12, Peter Ujfalusi wrote:
> Hi,
>
> Changes since v2:
> - Rebased on drm-next (v2 was based on drm-next and my
> 'drm/omap: Module parameter for display order configuration' series, thus it
> was not applying cleanly.
> - Added Acked-by from Rob to the dt-binding changes
>
> Changes since v1:
> - Use the crtc->mode_valid and not connector->mode_valid as the limit is really
> posed by the 'crtc' (DISPC)
> - Bandwidth calculation changed: do the calculation in place + extended comment
> - looked for better place to document the max-memory-bandwidth, but
> can not find any suitable document. Creating a new txt file for only one
> property did not seemed feasable.
>
> This series will add simple memory bandwidth limit support to reject modes
> which, if used with one plane in full size would fail the limit.
>
> Regards,
> Peter
> ---
> Peter Ujfalusi (3):
> dt-bindings: display/ti: Add optional property to set memory bandwidth
> limit
> drm/omap: dss: Add support for reporting memory bandwidth limitation
> drm/omap: Filter displays mode based on bandwidth limit
>
> .../devicetree/bindings/display/ti/ti,dra7-dss.txt | 5 +++
> .../bindings/display/ti/ti,omap2-dss.txt | 4 +++
> .../bindings/display/ti/ti,omap3-dss.txt | 4 +++
> .../bindings/display/ti/ti,omap4-dss.txt | 4 +++
> .../bindings/display/ti/ti,omap5-dss.txt | 4 +++
> drivers/gpu/drm/omapdrm/dss/dispc.c | 13 ++++++++
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 ++
> drivers/gpu/drm/omapdrm/omap_crtc.c | 37 ++++++++++++++++++++++
> drivers/gpu/drm/omapdrm/omap_drv.c | 5 +++
> drivers/gpu/drm/omapdrm/omap_drv.h | 3 ++
> 10 files changed, 81 insertions(+)
>
Thanks, I have applied this series.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation
From: Matthias Brugger @ 2017-12-01 12:07 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux
Cc: devicetree, sean.wang, sboyd, linux-kernel, linux-mediatek,
matthias.bgg, chen.zhong, linux-arm-kernel
The ethsys registers a reset controller, so we need to specify a
reset cell. This patch fixes the documentation.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
index 7aa3fa167668..6cc7840ff37a 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
@@ -20,4 +20,5 @@ ethsys: clock-controller@1b000000 {
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
--
2.12.3
^ permalink raw reply related
* [PATCH 2/3] arm: dts: mt7623: Update ethsys binding
From: Matthias Brugger @ 2017-12-01 12:07 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux
Cc: matthias.bgg, sboyd, sean.wang, chen.zhong, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20171201120708.30129-1-matthias.bgg@gmail.com>
The ethsys binding misses the reset-cells, this patch
adds this property.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
arch/arm/boot/dts/mt7623.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 343d3b1a4448..b750da5362f7 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -758,6 +758,7 @@
"syscon";
reg = <0 0x1b000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
eth: ethernet@1b100000 {
--
2.12.3
^ permalink raw reply related
* [PATCH 3/3] arm: dts: mt2701: Add reset-cells
From: Matthias Brugger @ 2017-12-01 12:07 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux
Cc: matthias.bgg, sboyd, sean.wang, chen.zhong, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20171201120708.30129-1-matthias.bgg@gmail.com>
The hifsys and ethsys needs the definition of the reset-cells
property. Fix this.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
---
arch/arm/boot/dts/mt2701.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 965ddfbc9953..05557fce0f1d 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -604,6 +604,7 @@
compatible = "mediatek,mt2701-hifsys", "syscon";
reg = <0 0x1a000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
usb0: usb@1a1c0000 {
@@ -688,6 +689,7 @@
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
eth: ethernet@1b100000 {
--
2.12.3
^ permalink raw reply related
* Re: [PATCH v2 35/35] dt-bindings: timer: Add andestech atcpit100 timer binding doc
From: Linus Walleij @ 2017-12-01 12:19 UTC (permalink / raw)
To: Greentime Hu
Cc: greentime, linux-kernel@vger.kernel.org, Arnd Bergmann,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, netdev, deanbo422,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Al Viro, David Howells, Will Deacon, Daniel Lezcano, linux-serial,
Rick Chen
In-Reply-To: <60f23e7fcff11f16b0bca4753a39d098849eeac3.1511785528.git.green.hu@gmail.com>
On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
> From: Rick Chen <rickchen36@gmail.com>
>
> Add a document to describe Andestech atcpit100 timer and
> binding information.
>
> Signed-off-by: Rick Chen <rickchen36@gmail.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Greentime Hu <green.hu@gmail.com>
Thanks for submitting this interesting architecture!
(...)
> +Required properties:
> +- compatible : Should be "andestech,atcpit100"
> +- reg : Address and length of the register set
> +- interrupts : Reference to the timer interrupt
> +- clocks : a clock to provide the tick rate for "andestech,atcpit100"
> +- clock-names : should be "PCLK" for the external tick timer.
This text seem wrong. PCLK is the internal timer, right? "PCLK" is
"peripheral clock" (I hope) and that comes from the bus.
Consider also adding an optional "EXTCLK" already now, since it is
evident from the driver that this is also supported.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 5/5] PCI: cadence: add EndPoint Controller driver for Cadence PCIe controller
From: Lorenzo Pieralisi @ 2017-12-01 12:20 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: bhelgaas, kishon, linux-pci, adouglas, stelford, dgary, kgopi,
eandrews, thomas.petazzoni, sureshp, nsekhar, linux-kernel, robh,
devicetree
In-Reply-To: <297fa17e12cf0f2fb223c05eeb18570707ff5bf1.1511439189.git.cyrille.pitchen@free-electrons.com>
On Thu, Nov 23, 2017 at 04:01:50PM +0100, Cyrille Pitchen wrote:
> This patch adds support to the Cadence PCIe controller in endpoint mode.
Please add a brief description to the log to describe the most salient
features.
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@free-electrons.com>
> ---
> drivers/pci/cadence/Kconfig | 9 +
> drivers/pci/cadence/Makefile | 1 +
> drivers/pci/cadence/pcie-cadence-ep.c | 553 ++++++++++++++++++++++++++++++++++
> 3 files changed, 563 insertions(+)
> create mode 100644 drivers/pci/cadence/pcie-cadence-ep.c
>
> diff --git a/drivers/pci/cadence/Kconfig b/drivers/pci/cadence/Kconfig
> index 120306cae2aa..b2e6af71f39e 100644
> --- a/drivers/pci/cadence/Kconfig
> +++ b/drivers/pci/cadence/Kconfig
> @@ -21,4 +21,13 @@ config PCIE_CADENCE_HOST
> mode. This PCIe controller may be embedded into many different vendors
> SoCs.
>
> +config PCIE_CADENCE_EP
> + bool "Cadence PCIe endpoint controller"
> + depends on PCI_ENDPOINT
> + select PCIE_CADENCE
> + help
> + Say Y here if you want to support the Cadence PCIe controller in
> + endpoint mode. This PCIe controller may be embedded into many
> + different vendors SoCs.
> +
> endif # PCI_CADENCE
> diff --git a/drivers/pci/cadence/Makefile b/drivers/pci/cadence/Makefile
> index d57d192d2595..61e9c8d6839d 100644
> --- a/drivers/pci/cadence/Makefile
> +++ b/drivers/pci/cadence/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_PCIE_CADENCE) += pcie-cadence.o
> obj-$(CONFIG_PCIE_CADENCE_HOST) += pcie-cadence-host.o
> +obj-$(CONFIG_PCIE_CADENCE_EP) += pcie-cadence-ep.o
> diff --git a/drivers/pci/cadence/pcie-cadence-ep.c b/drivers/pci/cadence/pcie-cadence-ep.c
> new file mode 100644
> index 000000000000..a1d761101a9c
> --- /dev/null
> +++ b/drivers/pci/cadence/pcie-cadence-ep.c
> @@ -0,0 +1,553 @@
> +/*
> + * Cadence PCIe host controller driver.
You should update this comment.
> + *
> + * Copyright (c) 2017 Cadence
> + *
> + * Author: Cyrille Pitchen <cyrille.pitchen@free-electrons.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/pci-epc.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/sizes.h>
> +#include <linux/delay.h>
Nit: alphabetical order.
> +#include "pcie-cadence.h"
> +
> +#define CDNS_PCIE_EP_MIN_APERTURE 128 /* 128 bytes */
> +#define CDNS_PCIE_EP_IRQ_PCI_ADDR_NONE 0x1
> +#define CDNS_PCIE_EP_IRQ_PCI_ADDR_LEGACY 0x3
> +
> +/**
> + * struct cdns_pcie_ep_data - hardware specific data
> + * @max_regions: maximum nmuber of regions supported by hardware
s/nmuber/number
> + */
> +struct cdns_pcie_ep_data {
> + size_t max_regions;
> +};
> +
> +/**
> + * struct cdns_pcie_ep - private data for this PCIe endpoint controller driver
> + * @pcie: Cadence PCIe controller
> + * @data: pointer to a 'struct cdns_pcie_data'
> + */
> +struct cdns_pcie_ep {
> + struct cdns_pcie pcie;
> + const struct cdns_pcie_ep_data *data;
> + struct pci_epc *epc;
> + unsigned long ob_region_map;
> + phys_addr_t *ob_addr;
> + phys_addr_t irq_phys_addr;
> + void __iomem *irq_cpu_addr;
> + u64 irq_pci_addr;
> + u8 irq_pending;
> +};
> +
> +static int cdns_pcie_ep_write_header(struct pci_epc *epc,
> + struct pci_epf_header *hdr)
> +{
> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> + struct cdns_pcie *pcie = &ep->pcie;
> + u8 fn = 0;
> +
> + if (fn == 0) {
I think there is some code to retrieve fn missing here.
> + u32 id = CDNS_PCIE_LM_ID_VENDOR(hdr->vendorid) |
> + CDNS_PCIE_LM_ID_SUBSYS(hdr->subsys_vendor_id);
> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_ID, id);
> + }
> + cdns_pcie_ep_fn_writew(pcie, fn, PCI_DEVICE_ID, hdr->deviceid);
> + cdns_pcie_ep_fn_writeb(pcie, fn, PCI_REVISION_ID, hdr->revid);
> + cdns_pcie_ep_fn_writeb(pcie, fn, PCI_CLASS_PROG, hdr->progif_code);
> + cdns_pcie_ep_fn_writew(pcie, fn, PCI_CLASS_DEVICE,
> + hdr->subclass_code | hdr->baseclass_code << 8);
> + cdns_pcie_ep_fn_writeb(pcie, fn, PCI_CACHE_LINE_SIZE,
> + hdr->cache_line_size);
> + cdns_pcie_ep_fn_writew(pcie, fn, PCI_SUBSYSTEM_ID, hdr->subsys_id);
> + cdns_pcie_ep_fn_writeb(pcie, fn, PCI_INTERRUPT_PIN, hdr->interrupt_pin);
> +
> + return 0;
> +}
> +
> +static int cdns_pcie_ep_set_bar(struct pci_epc *epc, enum pci_barno bar,
> + dma_addr_t bar_phys, size_t size, int flags)
> +{
> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> + struct cdns_pcie *pcie = &ep->pcie;
> + u32 addr0, addr1, reg, cfg, b, aperture, ctrl;
> + u8 fn = 0;
> + u64 sz;
> +
> + /* BAR size is 2^(aperture + 7) */
> + sz = max_t(size_t, size, CDNS_PCIE_EP_MIN_APERTURE);
> + sz = 1ULL << fls64(sz - 1);
> + aperture = ilog2(sz) - 7; /* 128B -> 0, 256B -> 1, 512B -> 2, ... */
> +
> + if ((flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_IO_32BITS;
> + } else {
> + bool is_prefetch = !!(flags & PCI_BASE_ADDRESS_MEM_PREFETCH);
> + bool is_64bits = sz > SZ_2G;
> +
> + if (is_64bits && (bar & 1))
> + return -EINVAL;
> +
> + switch (is_64bits << 1 | is_prefetch) {
I would not mind implementing this as a nested if-else, I am not a big
fan of using bool this way.
> + case 0:
> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_32BITS;
> + break;
> +
> + case 1:
> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_32BITS;
> + break;
> +
> + case 2:
> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_64BITS;
> + break;
> +
> + case 3:
> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_64BITS;
> + break;
> + }
> + }
> +
> + addr0 = lower_32_bits(bar_phys);
> + addr1 = upper_32_bits(bar_phys);
> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR0(fn, bar),
> + addr0);
> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR1(fn, bar),
> + addr1);
Is fn always 0 ?
> + if (bar < BAR_4) {
> + reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG0(fn);
> + b = bar;
> + } else {
> + reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG1(fn);
> + b = bar - BAR_4;
> + }
> +
> + cfg = cdns_pcie_readl(pcie, reg);
> + cfg &= ~(CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE_MASK(b) |
> + CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL_MASK(b));
> + cfg |= (CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE(b, aperture) |
> + CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL(b, ctrl));
> + cdns_pcie_writel(pcie, reg, cfg);
> +
> + return 0;
> +}
> +
> +static void cdns_pcie_ep_clear_bar(struct pci_epc *epc, enum pci_barno bar)
> +{
> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> + struct cdns_pcie *pcie = &ep->pcie;
> + u32 reg, cfg, b, ctrl;
> + u8 fn = 0;
> +
> + if (bar < BAR_4) {
> + reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG0(fn);
> + b = bar;
> + } else {
> + reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG1(fn);
> + b = bar - BAR_4;
> + }
> +
> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_DISABLED;
> + cfg = cdns_pcie_readl(pcie, reg);
> + cfg &= ~(CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE_MASK(b) |
> + CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL_MASK(b));
> + cfg |= CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL_MASK(ctrl);
> + cdns_pcie_writel(pcie, reg, cfg);
> +
> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR0(fn, bar), 0);
> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR1(fn, bar), 0);
> +}
> +
> +static int cdns_pcie_ep_map_addr(struct pci_epc *epc, phys_addr_t addr,
> + u64 pci_addr, size_t size)
> +{
> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> + struct cdns_pcie *pcie = &ep->pcie;
> + u32 r;
> +
> + r = find_first_zero_bit(&ep->ob_region_map, sizeof(ep->ob_region_map));
Second argument must be in bits not bytes.
https://marc.info/?l=linux-pci&m=151179781225513&w=2
> + if (r >= ep->data->max_regions - 1) {
> + dev_err(&epc->dev, "no free outbound region\n");
> + return -EINVAL;
> + }
> +
> + cdns_pcie_set_outbound_region(pcie, r, false, addr, pci_addr, size);
> +
> + set_bit(r, &ep->ob_region_map);
> + ep->ob_addr[r] = addr;
> +
> + return 0;
> +}
> +
> +static void cdns_pcie_ep_unmap_addr(struct pci_epc *epc, phys_addr_t addr)
> +{
> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> + struct cdns_pcie *pcie = &ep->pcie;
> + u32 r;
> +
> + for (r = 0; r < ep->data->max_regions - 1; r++)
> + if (ep->ob_addr[r] == addr)
> + break;
> +
> + if (r >= ep->data->max_regions - 1)
== ?
> + return;
> +
> + cdns_pcie_reset_outbound_region(pcie, r);
> +
> + ep->ob_addr[r] = 0;
> + clear_bit(r, &ep->ob_region_map);
> +}
> +
> +static int cdns_pcie_ep_set_msi(struct pci_epc *epc, u8 mmc)
> +{
> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> + struct cdns_pcie *pcie = &ep->pcie;
> + u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
> + u16 flags;
> + u8 fn = 0;
> +
> + /* Validate the ID of the MSI Capability structure. */
> + if (cdns_pcie_ep_fn_readb(pcie, fn, cap) != PCI_CAP_ID_MSI)
> + return -EINVAL;
> +
> + /*
> + * Set the Multiple Message Capable bitfield into the Message Control
> + * register.
> + */
> + flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
> + flags = (flags & ~PCI_MSI_FLAGS_QMASK) | (mmc << 1);
> + flags |= PCI_MSI_FLAGS_64BIT;
> + flags &= ~PCI_MSI_FLAGS_MASKBIT;
> + cdns_pcie_ep_fn_writew(pcie, fn, cap + PCI_MSI_FLAGS, flags);
> +
> + return 0;
> +}
> +
> +static int cdns_pcie_ep_get_msi(struct pci_epc *epc)
> +{
> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> + struct cdns_pcie *pcie = &ep->pcie;
> + u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
> + u16 flags, mmc, mme;
> + u8 fn = 0;
> +
> + /* Validate the ID of the MSI Capability structure. */
> + if (cdns_pcie_ep_fn_readb(pcie, fn, cap) != PCI_CAP_ID_MSI)
> + return -EINVAL;
> +
> + /* Validate that the MSI feature is actually enabled. */
> + flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
> + if (!(flags & PCI_MSI_FLAGS_ENABLE))
> + return -EINVAL;
> +
> + /*
> + * Get the Multiple Message Enable bitfield from the Message Control
> + * register.
> + */
> + mmc = (flags & PCI_MSI_FLAGS_QMASK) >> 1;
> + mme = (flags & PCI_MSI_FLAGS_QSIZE) >> 4;
> + if (mme > mmc)
> + mme = mmc;
> + if (mme > 5)
> + mme = 5;
You should comment on what this 5 means and why it is fine to cap mme.
> +
> + return mme;
> +}
> +
> +static void cdns_pcie_ep_assert_intx(struct cdns_pcie_ep *ep, u8 fn,
> + u8 intx, bool is_asserted)
> +{
> + struct cdns_pcie *pcie = &ep->pcie;
> + u32 r = ep->data->max_regions - 1;
> + u32 offset;
> + u16 status;
> + u8 msg_code;
> +
> + intx &= 3;
> +
> + /* Set the outbound region if needed. */
> + if (unlikely(ep->irq_pci_addr != CDNS_PCIE_EP_IRQ_PCI_ADDR_LEGACY)) {
> + /* Last region was reserved for IRQ writes. */
> + cdns_pcie_set_outbound_region_for_normal_msg(pcie, r,
> + ep->irq_phys_addr);
> + ep->irq_pci_addr = CDNS_PCIE_EP_IRQ_PCI_ADDR_LEGACY;
> + }
> +
> + if (is_asserted) {
> + ep->irq_pending |= BIT(intx);
> + msg_code = MSG_CODE_ASSERT_INTA + intx;
> + } else {
> + ep->irq_pending &= ~BIT(intx);
> + msg_code = MSG_CODE_DEASSERT_INTA + intx;
> + }
> +
> + status = cdns_pcie_ep_fn_readw(pcie, fn, PCI_STATUS);
> + if (((status & PCI_STATUS_INTERRUPT) != 0) ^ (ep->irq_pending != 0)) {
> + status ^= PCI_STATUS_INTERRUPT;
> + cdns_pcie_ep_fn_writew(pcie, fn, PCI_STATUS, status);
> + }
> +
> + offset = CDNS_PCIE_NORMAL_MSG_ROUTING(MSG_ROUTING_LOCAL) |
> + CDNS_PCIE_NORMAL_MSG_CODE(msg_code) |
> + CDNS_PCIE_MSG_NO_DATA;
> + writel(0, ep->irq_cpu_addr + offset);
> +}
> +
> +static int cdns_pcie_ep_send_legacy_irq(struct cdns_pcie_ep *ep, u8 fn, u8 intx)
> +{
> + u16 cmd;
> +
> + cmd = cdns_pcie_ep_fn_readw(&ep->pcie, fn, PCI_COMMAND);
> + if (cmd & PCI_COMMAND_INTX_DISABLE)
> + return -EINVAL;
> +
> + cdns_pcie_ep_assert_intx(ep, fn, intx, true);
> + mdelay(1);
Add a comment please to explain the mdelay value.
> + cdns_pcie_ep_assert_intx(ep, fn, intx, false);
> + return 0;
> +}
> +
> +static int cdns_pcie_ep_raise_irq(struct pci_epc *epc,
> + enum pci_epc_irq_type type, u8 interrupt_num)
> +{
> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> + struct cdns_pcie *pcie = &ep->pcie;
> + u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
> + u16 flags, mmc, mme, data, data_mask;
> + u8 msi_count;
> + u64 pci_addr, pci_addr_mask = 0xff;
> + u8 fn = 0;
> +
> + /* Handle legacy IRQ. */
> + if (type == PCI_EPC_IRQ_LEGACY)
> + return cdns_pcie_ep_send_legacy_irq(ep, fn, 0);
> +
> + /* Otherwise MSI. */
> + if (type != PCI_EPC_IRQ_MSI)
> + return -EINVAL;
> +
> + /* Check whether the MSI feature has been enabled by the PCI host. */
> + flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
> + if (!(flags & PCI_MSI_FLAGS_ENABLE))
> + return -EINVAL;
> +
> + /* Get the number of enabled MSIs */
> + mmc = (flags & PCI_MSI_FLAGS_QMASK) >> 1;
> + mme = (flags & PCI_MSI_FLAGS_QSIZE) >> 4;
> + if (mme > mmc)
> + mme = mmc;
> + if (mme > 5)
> + mme = 5;
Same comment as above.
> + msi_count = 1 << mme;
> + if (!interrupt_num || interrupt_num > msi_count)
> + return -EINVAL;
> +
> + /* Compute the data value to be written. */
> + data_mask = msi_count - 1;
> + data = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_DATA_64);
> + data = (data & ~data_mask) | ((interrupt_num - 1) & data_mask);
> +
> + /* Get the PCI address where to write the data into. */
> + pci_addr = cdns_pcie_ep_fn_readl(pcie, fn, cap + PCI_MSI_ADDRESS_HI);
> + pci_addr <<= 32;
> + pci_addr |= cdns_pcie_ep_fn_readl(pcie, fn, cap + PCI_MSI_ADDRESS_LO);
> + pci_addr &= GENMASK_ULL(63, 2);
> +
> + /* Set the outbound region if needed. */
> + if (unlikely(ep->irq_pci_addr != pci_addr)) {
> + /* Last region was reserved for IRQ writes. */
> + cdns_pcie_set_outbound_region(pcie, ep->data->max_regions - 1,
> + false,
> + ep->irq_phys_addr,
> + pci_addr & ~pci_addr_mask,
> + pci_addr_mask + 1);
> + ep->irq_pci_addr = pci_addr;
> + }
> + writew(data, ep->irq_cpu_addr + (pci_addr & pci_addr_mask));
> +
> + return 0;
> +}
> +
> +static int cdns_pcie_ep_start(struct pci_epc *epc)
> +{
> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> + struct cdns_pcie *pcie = &ep->pcie;
> + struct pci_epf *epf;
> + u32 cfg;
> + u8 fn = 0;
> +
> + /* Enable this endpoint function. */
> + cfg = cdns_pcie_readl(pcie, CDNS_PCIE_LM_EP_FUNC_CFG);
> + cfg |= BIT(fn);
> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_EP_FUNC_CFG, cfg);
> +
> + /*
> + * Already linked-up: don't call directly pci_epc_linkup() because we've
> + * already locked the epc->lock.
> + */
> + list_for_each_entry(epf, &epc->pci_epf, list)
> + pci_epf_linkup(epf);
> +
> + return 0;
> +}
> +
> +static void cdns_pcie_ep_stop(struct pci_epc *epc)
> +{
> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> + struct cdns_pcie *pcie = &ep->pcie;
> + u32 cfg;
> + u8 fn = 0;
> +
> + /* Disable this endpoint function (function 0 can't be disabled). */
I do not understand this comment and how it applies to the code,
in other words fn is always 0 here (so it can't be disabled)
I do not understand what this code is there for.
> + cfg = cdns_pcie_readl(pcie, CDNS_PCIE_LM_EP_FUNC_CFG);
> + cfg &= ~BIT(fn);
> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_EP_FUNC_CFG, cfg);
> +}
> +
> +static const struct pci_epc_ops cdns_pcie_epc_ops = {
> + .write_header = cdns_pcie_ep_write_header,
> + .set_bar = cdns_pcie_ep_set_bar,
> + .clear_bar = cdns_pcie_ep_clear_bar,
> + .map_addr = cdns_pcie_ep_map_addr,
> + .unmap_addr = cdns_pcie_ep_unmap_addr,
> + .set_msi = cdns_pcie_ep_set_msi,
> + .get_msi = cdns_pcie_ep_get_msi,
> + .raise_irq = cdns_pcie_ep_raise_irq,
> + .start = cdns_pcie_ep_start,
> + .stop = cdns_pcie_ep_stop,
> +};
> +
> +static const struct cdns_pcie_ep_data cdns_pcie_ep_data = {
> + .max_regions = 16,
> +};
As I mentioned in patch 3, should this be set-up with DT ?
Thanks,
Lorenzo
> +
> +static const struct of_device_id cdns_pcie_ep_of_match[] = {
> + { .compatible = "cdns,cdns-pcie-ep",
> + .data = &cdns_pcie_ep_data },
> +
> + { },
> +};
> +
> +static int cdns_pcie_ep_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + const struct of_device_id *of_id;
> + struct cdns_pcie_ep *ep;
> + struct cdns_pcie *pcie;
> + struct pci_epc *epc;
> + struct resource *res;
> + size_t max_regions;
> + int ret;
> +
> + ep = devm_kzalloc(dev, sizeof(*ep), GFP_KERNEL);
> + if (!ep)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, ep);
> +
> + pcie = &ep->pcie;
> + pcie->is_rc = false;
> +
> + of_id = of_match_node(cdns_pcie_ep_of_match, np);
> + ep->data = (const struct cdns_pcie_ep_data *)of_id->data;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "reg");
> + pcie->reg_base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(pcie->reg_base)) {
> + dev_err(dev, "missing \"reg\"\n");
> + return PTR_ERR(pcie->reg_base);
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mem");
> + if (!res) {
> + dev_err(dev, "missing \"mem\"\n");
> + return -EINVAL;
> + }
> + pcie->mem_res = res;
> +
> + max_regions = ep->data->max_regions;
> + ep->ob_addr = devm_kzalloc(dev, max_regions * sizeof(*ep->ob_addr),
> + GFP_KERNEL);
> + if (!ep->ob_addr)
> + return -ENOMEM;
> +
> + pm_runtime_enable(dev);
> + ret = pm_runtime_get_sync(dev);
> + if (ret < 0) {
> + dev_err(dev, "pm_runtime_get_sync() failed\n");
> + goto err_get_sync;
> + }
> +
> + /* Disable all but function 0 (anyway BIT(0) is hardwired to 1). */
> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_EP_FUNC_CFG, BIT(0));
> +
> + epc = devm_pci_epc_create(dev, &cdns_pcie_epc_ops);
> + if (IS_ERR(epc)) {
> + dev_err(dev, "failed to create epc device\n");
> + ret = PTR_ERR(epc);
> + goto err_init;
> + }
> +
> + ep->epc = epc;
> + epc_set_drvdata(epc, ep);
> +
> + ret = of_property_read_u8(np, "max-functions", &epc->max_functions);
> + if (ret < 0)
> + epc->max_functions = 1;
> +
> + ret = pci_epc_mem_init(epc, pcie->mem_res->start,
> + resource_size(pcie->mem_res));
> + if (ret < 0) {
> + dev_err(dev, "failed to initialize the memory space\n");
> + goto err_init;
> + }
> +
> + ep->irq_cpu_addr = pci_epc_mem_alloc_addr(epc, &ep->irq_phys_addr,
> + SZ_128K);
> + if (!ep->irq_cpu_addr) {
> + dev_err(dev, "failed to reserve memory space for MSI\n");
> + ret = -ENOMEM;
> + goto free_epc_mem;
> + }
> + ep->irq_pci_addr = CDNS_PCIE_EP_IRQ_PCI_ADDR_NONE;
> +
> + return 0;
> +
> + free_epc_mem:
> + pci_epc_mem_exit(epc);
> +
> + err_init:
> + pm_runtime_put_sync(dev);
> +
> + err_get_sync:
> + pm_runtime_disable(dev);
> +
> + return ret;
> +}
> +
> +static struct platform_driver cdns_pcie_ep_driver = {
> + .driver = {
> + .name = "cdns-pcie-ep",
> + .of_match_table = cdns_pcie_ep_of_match,
> + },
> + .probe = cdns_pcie_ep_probe,
> +};
> +builtin_platform_driver(cdns_pcie_ep_driver);
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v6 01/10] arm64: dts: rockchip: Enable edp disaplay on kevin
From: Enric Balletbo Serra @ 2017-12-01 12:28 UTC (permalink / raw)
To: Jeffy Chen
Cc: linux-kernel, Brian Norris, Sean Paul, Doug Anderson,
Heiko Stübner, tfiga-F7+t8E8rja9g9hUCZPvPmw,
Matthias Kaehlcke, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Yao,
open list:ARM/Rockchip SoC..., Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Will Deacon, Mark Rutland, Caesar Wang, Catalin Marinas
In-Reply-To: <20171019034812.13768-2-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi all,
2017-10-19 5:48 GMT+02:00 Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>:
> Add edp panel and enable related nodes on kevin.
>
> Signed-off-by: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Reviewed-by: Mark Yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> ---
>
> Changes in v6: None
> Changes in v5: None
>
> arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 29 +++++++++++++++++++++++
> arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 16 +++++++++++++
> 2 files changed, 45 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> index a3d3cea7dc4f..bc67b19f0af5 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> @@ -93,6 +93,18 @@
> pwm-delay-us = <10000>;
> };
>
> + edp_panel: edp-panel {
> + compatible = "sharp,lq123p1jx31", "simple-panel";
> + backlight = <&backlight>;
> + power-supply = <&pp3300_disp>;
> +
> + ports {
> + panel_in_edp: endpoint {
> + remote-endpoint = <&edp_out_panel>;
> + };
> + };
> + };
> +
> thermistor_ppvar_bigcpu: thermistor-ppvar-bigcpu {
> compatible = "murata,ncp15wb473";
> pullup-uv = <1800000>;
> @@ -264,6 +276,23 @@ ap_i2c_dig: &i2c2 {
> };
> };
>
> +&edp {
> + status = "okay";
> +
> + ports {
> + edp_out: port@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + edp_out_panel: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&panel_in_edp>;
> + };
> + };
> + };
> +};
> +
> &ppvar_bigcpu_pwm {
> regulator-min-microvolt = <798674>;
> regulator-max-microvolt = <1302172>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> index 5772c52fbfd3..470105d651c2 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> @@ -927,6 +927,22 @@ ap_i2c_audio: &i2c8 {
> dr_mode = "host";
> };
>
> +&vopb {
> + status = "okay";
> +};
> +
> +&vopb_mmu {
> + status = "okay";
> +};
> +
> +&vopl {
> + status = "okay";
> +};
> +
> +&vopl_mmu {
> + status = "okay";
> +};
> +
> #include <arm/cros-ec-keyboard.dtsi>
> #include <arm/cros-ec-sbs.dtsi>
>
> --
> 2.11.0
>
>
I just tested this patch on top of current mainline (4.15-rc1+) and works so,
Tested-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 33/35] clocksource/drivers/atcpit100: Add andestech atcpit100 timer
From: Linus Walleij @ 2017-12-01 12:30 UTC (permalink / raw)
To: Greentime Hu
Cc: greentime, linux-kernel@vger.kernel.org, Arnd Bergmann,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, netdev, deanbo422,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Al Viro, David Howells, Will Deacon, Daniel Lezcano, linux-serial,
Rick Chen
In-Reply-To: <672e0b3843953d1ab69bc19baf1a0f217ec1b1fa.1511785528.git.green.hu@gmail.com>
On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@gmail.com> wrote:
> From: Rick Chen <rickchen36@gmail.com>
>
> ATCPIT100 is often used on the Andes architecture,
> This timer provide 4 PIT channels. Each PIT channel is a
> multi-function timer, can be configured as 32,16,8 bit timers
> or PWM as well.
>
> For system timer it will set channel 1 32-bit timer0 as clock
> source and count downwards until underflow and restart again.
>
> It also set channel 0 32-bit timer0 as clock event and count
> downwards until condition match. It will generate an interrupt
> for handling periodically.
>
> Signed-off-by: Rick Chen <rickchen36@gmail.com>
> Signed-off-by: Greentime Hu <green.hu@gmail.com>
The driver looks nice overall.
> +static struct timer_of to = {
> + .flags = TIMER_OF_IRQ | TIMER_OF_CLOCK | TIMER_OF_BASE,
> +
> + .clkevt = {
> + .name = "atcpit100_tick",
> + .rating = 300,
> + .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
> + .set_state_shutdown = atcpit100_clkevt_shutdown,
> + .set_state_periodic = atcpit100_clkevt_set_periodic,
> + .set_state_oneshot = atcpit100_clkevt_set_oneshot,
> + .tick_resume = atcpit100_clkevt_shutdown,
> + .set_next_event = atcpit100_clkevt_next_event,
> + .cpumask = cpu_all_mask,
> + },
> +
> + .of_irq = {
> + .handler = atcpit100_timer_interrupt,
> + .flags = IRQF_TIMER | IRQF_IRQPOLL,
> + },
I would add:
.of_clk = {
.name = "PCLK",
};
To be explicit on what we use.
(I hope I understand this OF timer right.)
Otherwise it looks good!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox