* [PATCH] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Will Deacon @ 2016-11-11 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478872273-16382-1-git-send-email-ard.biesheuvel@linaro.org>
On Fri, Nov 11, 2016 at 09:51:13PM +0800, Ard Biesheuvel wrote:
> This integrates both the accelerated scalar and the NEON implementations
> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>
> Relative performance compared to the respective generic C versions:
>
> | SHA256-scalar | SHA256-NEON* | SHA512 |
> ------------+-----------------+--------------+----------+
> Cortex-A53 | 1.63x | 1.63x | 2.34x |
> Cortex-A57 | 1.43x | 1.59x | 1.95x |
> Cortex-A73 | 1.26x | 1.56x | ? |
>
> The core crypto code was authored by Andy Polyakov of the OpenSSL
> project, in collaboration with whom the upstream code was adapted so
> that this module can be built from the same version of sha512-armv8.pl.
>
> The version in this patch was taken from OpenSSL commit
>
> 866e505e0d66 sha/asm/sha512-armv8.pl: add NEON version of SHA256.
>
> * The core SHA algorithm is fundamentally sequential, but there is a
> secondary transformation involved, called the schedule update, which
> can be performed independently. The NEON version of SHA-224/SHA-256
> only implements this part of the algorithm using NEON instructions,
> the sequential part is always done using scalar instructions.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> This supersedes the SHA-256-NEON-only patch I sent out about 6 weeks ago.
>
> Will, Catalin: note that this pulls in a .pl script, and adds a build rule
> locally in arch/arm64/crypto to generate .S files on the fly from Perl
> scripts. I will leave it to you to decide whether you are ok with this as
> is, or whether you prefer .S_shipped files, in which case the Perl script
> is only included as a reference (this is how we did it for arch/arm in the
> past, but given that it adds about 3000 lines of generated code to the patch,
> I think we may want to simply keep it as below)
I think we should include the shipped files too. 3000 lines isn't that much
in the grand scheme of things, and there will be people who complain about
the unconditional perl dependency.
Will
^ permalink raw reply
* [PATCH v2 1/2] pinctrl: single: check for any error when getting rows
From: Linus Walleij @ 2016-11-11 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109145401.25327-2-ahaslam@baylibre.com>
On Wed, Nov 9, 2016 at 3:54 PM, Axel Haslam <ahaslam@baylibre.com> wrote:
> pinctrl_count_index_with_args returns -ENOENT not
> -EINVAL. The return check would pass, and we would
> try to kzalloc with a negative error size throwing
> a warning.
>
> Instead of checking for -EINVAL specifically, lets
> check for any error and avoid negative size allocations.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Patch applied with Tony's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/2] pinctrl: single: search for the bits property when parsing bits
From: Linus Walleij @ 2016-11-11 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109145401.25327-3-ahaslam@baylibre.com>
On Wed, Nov 9, 2016 at 3:54 PM, Axel Haslam <ahaslam@baylibre.com> wrote:
> The pcs_parse_bits_in_pinctrl_entry function should search
> for the "pinctrl-single,bits" and not "pinctrl-single,pins"
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Patch applied with Tony's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] clk: sunxi-ng: sun8i-h3: Set CLK_SET_RATE_PARENT for audio module clocks
From: Maxime Ripard @ 2016-11-11 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111100558.14629-2-wens@csie.org>
On Fri, Nov 11, 2016 at 06:05:58PM +0800, Chen-Yu Tsai wrote:
> The audio module clocks are supposed to be set according to the sample
> rate of the audio stream. The audio PLL provides the clock signal for
> thees module clocks, and only it is freely tunable.
>
> Set CLK_SET_RATE_PARENT for the audio module clocks so their users can
> properly tune the clock rate.
>
> Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Fixed the typo and applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/506088d1/attachment.sig>
^ permalink raw reply
* [PATCH] PCI: enable extended tags support for PCIe endpoints
From: Bjorn Helgaas @ 2016-11-11 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <420a9a23-79f8-41d8-c44f-b53f5000c957@codeaurora.org>
On Thu, Nov 10, 2016 at 01:35:41PM -0500, Sinan Kaya wrote:
> On 9/24/2016 10:10 PM, Sinan Kaya wrote:
> > Each PCIe device can issue up to 32 transactions at a time by default.
> > Each transaction is tracked by a tag number on the bus. 32 outstanding
> > transactions is not enough for some performance critical applications
> > especially when a lot of small sized frames are transmitted.
> >
> > Extended tags support increases this number to 256. Devices not
> > supporting extended tags tie-off this field to 0. According to ECN, it
> > is safe to enable this feature for all PCIe endpoints.
> >
> > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> > ---
> > drivers/pci/probe.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 93f280d..2424f38 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -1505,12 +1505,19 @@ static void program_hpp_type2(struct pci_dev *dev, struct hpp_type2 *hpp)
> > */
> > }
> >
> > +static int pci_configure_extended_tags(struct pci_dev *dev)
> > +{
>
> I should have checked the capability here before trying to enable it.
> I'll post a follow up patch on this.
>
> Is there any other feedback?
If this were completely safe to enable for every device that supported
it, why would there be an enable bit in Device Control?
I don't know anything about extended tags, but it worries me a little
when there's a "go-fast" switch and no explanation about when and why
we might need to go slow.
> > + return pcie_capability_set_word(dev, PCI_EXP_DEVCTL,
> > + PCI_EXP_DEVCTL_EXT_TAG);
> > +}
> > +
> > static void pci_configure_device(struct pci_dev *dev)
> > {
> > struct hotplug_params hpp;
> > int ret;
> >
> > pci_configure_mps(dev);
> > + pci_configure_extended_tags(dev);
> >
> > memset(&hpp, 0, sizeof(hpp));
> > ret = pci_get_hp_params(dev, &hpp);
> >
>
>
> --
> Sinan Kaya
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL 1/2] SoCFPGA DTS updates for v4.10
From: Dinh Nguyen @ 2016-11-11 20:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, and Olof:
Please pull in part 2 of these DTS updates for v4.10.
Thanks,
Dinh
The following changes since commit c96f5919e6b0d132aa9afe9f1adc872fc107d5bb:
ARM: dts: socfpga: socrates: enable qspi (2016-10-18 22:18:14 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_dts_for_v4.10_part_2
for you to fetch changes up to d837a80d19505d74ee5941eebf9dd53fed6f36a6:
ARM: dts: socfpga: add nand controller nodes (2016-11-09 12:40:52 -0600)
----------------------------------------------------------------
SoCFPGA DTS update for v4.10, part 2
- Add specific compatible strings for variants of Cyclone5 boards
- Add QSPI node on Arria10
- Enable QSPI on Arria5 and Arria10 devkit, and Cyclone5 SoCKit
- Add NAND controller node on Cyclone5
----------------------------------------------------------------
Dinh Nguyen (6):
ARM: dts: socfpga: add specific compatible strings for boards
ARM: dts: socfpga: enable qspi on the Cyclone5 devkit
ARM: dts: socfpga: Add QSPI node for the Arria10
ARM: dts: socfpga: Enable QSPI in Arria10 devkit
ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
ARM: dts: socfpga: Enable QSPI on the Arria5 devkit
Steffen Trumtrar (1):
ARM: dts: socfpga: add nand controller nodes
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/socfpga.dtsi | 13 ++++++
arch/arm/boot/dts/socfpga_arria10.dtsi | 14 +++++++
arch/arm/boot/dts/socfpga_arria10_socdk_qspi.dts | 49 ++++++++++++++++++++++
arch/arm/boot/dts/socfpga_arria5_socdk.dts | 33 +++++++++++++++
arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 35 +++++++++++++++-
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 23 +++++++++-
arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 2 +-
11 files changed, 170 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/boot/dts/socfpga_arria10_socdk_qspi.dts
^ permalink raw reply
* [GIT PULL 2/2] SoCFPGA defconfig updates for v4.10
From: Dinh Nguyen @ 2016-11-11 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111205915.22173-1-dinguyen@kernel.org>
Hi Arnd, Kevin, and Olof:
Please pull these defconfig updates for v4.10.
Thanks,
Dinh
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_defconfig_updates_for_v4.10
for you to fetch changes up to cab004fa972f06b236ba6b592bbb0512d5c6c158:
ARM: socfpga_defconfig: enable FS configs to support Angstrom filesystem (2016-11-09 08:11:31 -0600)
----------------------------------------------------------------
SoCFPGA defconfig updates for v4.10
- enable QSPI, HIGHMEM, FPGA bridge and device-tree overlays
- enable AUTOFS4 and NFS file system support
----------------------------------------------------------------
Alan Tull (1):
ARM: socfpga: updates for socfpga_defconfig
Dinh Nguyen (2):
ARM: socfpga_defconfig: Enable HIGHMEM
ARM: socfpga_defconfig: enable FS configs to support Angstrom filesystem
Steffen Trumtrar (1):
ARM: socfpga: defconfig: enable qspi
arch/arm/configs/socfpga_defconfig | 15 +++++++++++++++
1 file changed, 15 insertions(+)
^ permalink raw reply
* [PATCH -next] PCI: layerscape: Remove redundant dev_err call in ls_pcie_probe()
From: Bjorn Helgaas @ 2016-11-11 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476716140-30608-1-git-send-email-weiyj.lk@gmail.com>
On Mon, Oct 17, 2016 at 02:55:40PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied to pci/host-layerscape for v4.10, thanks!
> ---
> drivers/pci/host/pci-layerscape.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
> index 2cb7315..bbd3d23 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -251,10 +251,8 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
>
> dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> pcie->pp.dbi_base = devm_ioremap_resource(dev, dbi_base);
> - if (IS_ERR(pcie->pp.dbi_base)) {
> - dev_err(dev, "missing *regs* space\n");
> + if (IS_ERR(pcie->pp.dbi_base))
> return PTR_ERR(pcie->pp.dbi_base);
> - }
>
> pcie->drvdata = match->data;
> pcie->lut = pcie->pp.dbi_base + pcie->drvdata->lut_offset;
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH -next] PCI: rockchip: Add missing of_node_put() in rockchip_pcie_init_irq_domain()
From: Bjorn Helgaas @ 2016-11-11 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476716242-31684-1-git-send-email-weiyj.lk@gmail.com>
On Mon, Oct 17, 2016 at 02:57:22PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> This node pointer is returned by of_get_next_child() with refcount
> incremented in this function. of_node_put() on it before exitting
> this function on error.
>
> This is detected by Coccinelle semantic patch.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied with Shawn's ack to pci/host-rockchip for v4.10, thanks!
> ---
> drivers/pci/host/pcie-rockchip.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index e0b22da..ab88859 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -949,6 +949,7 @@ static int rockchip_pcie_init_irq_domain(struct rockchip_pcie *rockchip)
> &intx_domain_ops, rockchip);
> if (!rockchip->irq_domain) {
> dev_err(dev, "failed to get a INTx IRQ domain\n");
> + of_node_put(intc);
> return -EINVAL;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH -next] PCI: xilinx: Add missing of_node_put() in xilinx_pcie_init_irq_domain()
From: Bjorn Helgaas @ 2016-11-11 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476716344-1050-1-git-send-email-weiyj.lk@gmail.com>
On Mon, Oct 17, 2016 at 02:59:04PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> This node pointer is returned by of_get_next_child() with refcount
> incremented in this function. of_node_put() on it before exitting
> this function on error.
>
> This is detected by Coccinelle semantic patch.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied to pci/host-xilinx for v4.10, thanks!
See below for another possible issue.
> ---
> drivers/pci/host/pcie-xilinx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
> index c8616fa..7100ee5 100644
> --- a/drivers/pci/host/pcie-xilinx.c
> +++ b/drivers/pci/host/pcie-xilinx.c
> @@ -529,6 +529,7 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
> port);
> if (!port->leg_domain) {
> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> + of_node_put(pcie_intc_node);
> return -ENODEV;
> }
>
> @@ -540,6 +541,7 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
> &xilinx_pcie_msi_chip);
> if (!port->msi_domain) {
> dev_err(dev, "Failed to get a MSI IRQ domain\n");
> + of_node_put(pcie_intc_node);
We also leak port->leg_domain here, don't we?
> return -ENODEV;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH -next] PCI: xilinx-nwl: Add missing of_node_put() in nwl_pcie_init_irq_domain()
From: Bjorn Helgaas @ 2016-11-11 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476716297-31808-1-git-send-email-weiyj.lk@gmail.com>
On Mon, Oct 17, 2016 at 02:58:17PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> This node pointer is returned by of_get_next_child() with refcount
> incremented in this function. of_node_put() on it before exitting
> this function on error.
>
> This is detected by Coccinelle semantic patch.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied to pci/host-xilinx for v.10, thanks!
> ---
> drivers/pci/host/pcie-xilinx-nwl.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/host/pcie-xilinx-nwl.c b/drivers/pci/host/pcie-xilinx-nwl.c
> index 43eaa4a..c16b26c 100644
> --- a/drivers/pci/host/pcie-xilinx-nwl.c
> +++ b/drivers/pci/host/pcie-xilinx-nwl.c
> @@ -535,6 +535,7 @@ static int nwl_pcie_init_irq_domain(struct nwl_pcie *pcie)
>
> if (!pcie->legacy_irq_domain) {
> dev_err(dev, "failed to create IRQ domain\n");
> + of_node_put(legacy_intc_node);
> return -ENOMEM;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v7] soc: qcom: add l2 cache perf events driver
From: Leeder, Neil @ 2016-11-11 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109181652.GK17771@arm.com>
Hi Will,
On 11/9/2016 1:16 PM, Will Deacon wrote:
> On Wed, Nov 09, 2016 at 05:54:13PM +0000, Mark Rutland wrote:
>> On Fri, Oct 28, 2016 at 04:50:13PM -0400, Neil Leeder wrote:
>>> + struct perf_event *events[MAX_L2_CTRS];
>>> + struct l2cache_pmu *l2cache_pmu;
>>> + DECLARE_BITMAP(used_counters, MAX_L2_CTRS);
>>> + DECLARE_BITMAP(used_groups, L2_EVT_GROUP_MAX + 1);
>>> + int group_to_counter[L2_EVT_GROUP_MAX + 1];
>>> + int irq;
>>> + /* The CPU that is used for collecting events on this cluster */
>>> + int on_cpu;
>>> + /* All the CPUs associated with this cluster */
>>> + cpumask_t cluster_cpus;
>>
>> I'm still uncertain about aggregating all cluster PMUs into a larger
>> PMU, given the cluster PMUs are logically independent (at least in terms
>> of the programming model).
>>
>> However, from what I understand the x86 uncore PMU drivers aggregate
>> symmetric instances of uncore PMUs (and also aggregate across packages
>> to the same logical PMU).
>>
>> Whatever we do, it would be nice for the uncore drivers to align on a
>> common behaviour (and I think we're currently going the oppposite route
>> with Cavium's uncore PMU). Will, thoughts?
>
> I'm not a big fan of aggregating this stuff. Ultimately, the user in the
> driving seat of perf is going to need some knowledge about the toplogy of
> the system in order to perform sensible profiling using an uncore PMU.
> If the kernel tries to present a single, unified PMU then we paint ourselves
> into a corner when the hardware isn't as symmetric as we want it to be
> (big/little on the CPU side is the extreme example of this). If we want
> to be consistent, then exposing each uncore unit as a separate PMU is
> the way to go. That doesn't mean we can't aggregate the components of a
> distributed PMU (e.g. the CCN or the SMMU), but we don't want to aggregate
> at the programming interface/IP block level.
>
> We could consider exposing some topology information in sysfs if that's
> seen as an issue with the non-aggregated case.
>
> Will
So is there a use-case for individual uncore PMUs when they can't be
used in task mode or per-cpu?
The main (only?) use will be in system mode, in which case surely it
makes sense to provide a single aggregated count?
With individual PMUs exposed there will be potentially dozens of nodes
for userspace to collect from which would make perf command-line usage
unwieldy at best.
Neil
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Pavel Machek @ 2016-11-11 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f7c9b2be-0003-f342-a4c7-802532faa424@gmail.com>
Hi!
> >Hmm. So userland can read the LED state, and it can get _some_ value
> >back, but it can not know if it is current state or not.
> >
> >I don't think that's a good interface. I see it is from 2008... is
> >someone using it? Maybe it is too late for revert.
>
> I can imagine it being used in flash LED use case. E.g. one
> could use oneshot trigger to trigger flash strobe, and then
> he could periodically read brightness file to check, for whatever
> reason, whether the flash is strobing.
I'm pretty sure nobody does that for flah strobe.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/e6116c19/attachment.sig>
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Pavel Machek @ 2016-11-11 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7ddbbb0-b99c-14a3-f462-3534b5ec67e6@redhat.com>
Hi!
Reason #1:
> >>Hmm. So userland can read the LED state, and it can get _some_ value
> >>back, but it can not know if it is current state or not.
> Why a dedicated file? Are we going to mirror brightness here
> wrt r/w (show/store) behavior ? If not userspace now needs
> 2 open fds which is not really nice. If we are and we are
> not going to use poll for something else on brightness itself
> then why not just poll directly on brightness ?
Reason #1 is above.
Reason #2 is "if userspace sees brightness file, it can not know if
the notifications on change actually work or not".
Reason #3 is that you broke Tony's system. Polling does not make sense
when trigger such as "CPU in use" is active.
Reason #4 is that there are really two brightnesses:
1) maximum brightness trigger is going to use
2) current brightness
Currently writing to "brightness" file changes 1), but reading returns
2) when available.
So, feel free to propose better interface. One that solves #1..#4
above.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/f0be8d93/attachment.sig>
^ permalink raw reply
* [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid
From: Fabio Estevam @ 2016-11-11 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478709850-9361-1-git-send-email-andrew.smirnov@gmail.com>
On Wed, Nov 9, 2016 at 2:44 PM, Andrey Smirnov <andrew.smirnov@gmail.com> wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
From: Fabio Estevam @ 2016-11-11 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110114505.17618-1-maitysanchayan@gmail.com>
On Thu, Nov 10, 2016 at 9:45 AM, Sanchayan Maity
<maitysanchayan@gmail.com> wrote:
> Enable DMA for DSPI2 and DSPI3 on Vybrid.
You missed your Signed-off-by line.
^ permalink raw reply
* [PATCH] pci: layerscape: add LS1046a support
From: Bjorn Helgaas @ 2016-11-11 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477399016-22826-1-git-send-email-Minghuan.Lian@nxp.com>
On Tue, Oct 25, 2016 at 08:36:56PM +0800, Minghuan Lian wrote:
> From: "mingkai.hu at nxp.com" <mingkai.hu@nxp.com>
>
> 1. LS1046a PCIe controller has a different LUT_DBG offset.
> Available "lut_dbg" is added to ls_pcie_drvdata to describe
> this difference.
> 2. Match LS1046 PCIe compatible
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
Applied to pci/host-layerscape for v4.10, thanks!
I removed the now-unused PCIE_LUT_DBG definition for you.
> ---
> Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
> drivers/pci/host/pci-layerscape.c | 13 ++++++++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> index 41e9f55..ee1c72d5 100644
> --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> @@ -15,6 +15,7 @@ Required properties:
> - compatible: should contain the platform identifier such as:
> "fsl,ls1021a-pcie", "snps,dw-pcie"
> "fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
> + "fsl,ls1046a-pcie"
> - reg: base addresses and lengths of the PCIe controller
> - interrupts: A list of interrupt outputs of the controller. Must contain an
> entry for each entry in the interrupt-names property.
> diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
> index 958187f..8cebf9a 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -41,6 +41,7 @@
> struct ls_pcie_drvdata {
> u32 lut_offset;
> u32 ltssm_shift;
> + u32 lut_dbg;
> struct pcie_host_ops *ops;
> };
>
> @@ -134,7 +135,7 @@ static int ls_pcie_link_up(struct pcie_port *pp)
> struct ls_pcie *pcie = to_ls_pcie(pp);
> u32 state;
>
> - state = (ioread32(pcie->lut + PCIE_LUT_DBG) >>
> + state = (ioread32(pcie->lut + pcie->drvdata->lut_dbg) >>
> pcie->drvdata->ltssm_shift) &
> LTSSM_STATE_MASK;
>
> @@ -196,18 +197,28 @@ static int ls_pcie_msi_host_init(struct pcie_port *pp,
> static struct ls_pcie_drvdata ls1043_drvdata = {
> .lut_offset = 0x10000,
> .ltssm_shift = 24,
> + .lut_dbg = 0x7fc,
> + .ops = &ls_pcie_host_ops,
> +};
> +
> +static struct ls_pcie_drvdata ls1046_drvdata = {
> + .lut_offset = 0x80000,
> + .ltssm_shift = 24,
> + .lut_dbg = 0x407fc,
> .ops = &ls_pcie_host_ops,
> };
>
> static struct ls_pcie_drvdata ls2080_drvdata = {
> .lut_offset = 0x80000,
> .ltssm_shift = 0,
> + .lut_dbg = 0x7fc,
> .ops = &ls_pcie_host_ops,
> };
>
> static const struct of_device_id ls_pcie_of_match[] = {
> { .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
> { .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
> + { .compatible = "fsl,ls1046a-pcie", .data = &ls1046_drvdata },
> { .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
> { .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
> { },
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH RFC] mm: Add debug_virt_to_phys()
From: Florian Fainelli @ 2016-11-12 0:44 UTC (permalink / raw)
To: linux-arm-kernel
When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
debug_virt_to_phys() which helps catch vmalloc space addresses being
passed. This is helpful in debugging bogus drivers that just assume
linear mappings all over the place.
For ARM, ARM64, Unicore32 and Microblaze, the architectures define
__virt_to_phys() as being the functional implementation of the address
translation, so we special case the debug stub to call into
__virt_to_phys directly.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/include/asm/memory.h | 4 ++++
arch/arm64/include/asm/memory.h | 4 ++++
include/asm-generic/memory_model.h | 4 ++++
mm/debug.c | 15 +++++++++++++++
4 files changed, 27 insertions(+)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 76cbd9c674df..448dec9b8b00 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
* translation for translating DMA addresses. Use the driver
* DMA support - see dma-mapping.h.
*/
+#ifndef CONFIG_DEBUG_VM
#define virt_to_phys virt_to_phys
static inline phys_addr_t virt_to_phys(const volatile void *x)
{
return __virt_to_phys((unsigned long)(x));
}
+#else
+#define virt_to_phys debug_virt_to_phys
+#endif
#define phys_to_virt phys_to_virt
static inline void *phys_to_virt(phys_addr_t x)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index b71086d25195..c9e436b28523 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -186,11 +186,15 @@ extern u64 kimage_voffset;
* translation for translating DMA addresses. Use the driver
* DMA support - see dma-mapping.h.
*/
+#ifndef CONFIG_DEBUG_VM
#define virt_to_phys virt_to_phys
static inline phys_addr_t virt_to_phys(const volatile void *x)
{
return __virt_to_phys((unsigned long)(x));
}
+#else
+#define virt_to_phys debug_virt_to_phys
+#endif
#define phys_to_virt phys_to_virt
static inline void *phys_to_virt(phys_addr_t x)
diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
index 5148150cc80b..426085757258 100644
--- a/include/asm-generic/memory_model.h
+++ b/include/asm-generic/memory_model.h
@@ -80,6 +80,10 @@
#define page_to_pfn __page_to_pfn
#define pfn_to_page __pfn_to_page
+#ifdef CONFIG_DEBUG_VM
+unsigned long debug_virt_to_phys(volatile void *address);
+#endif /* CONFIG_DEBUG_VM */
+
#endif /* __ASSEMBLY__ */
#endif
diff --git a/mm/debug.c b/mm/debug.c
index 9feb699c5d25..72b2ca9b11f4 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -161,4 +161,19 @@ void dump_mm(const struct mm_struct *mm)
);
}
+#include <asm/memory.h>
+#include <linux/mm.h>
+
+unsigned long debug_virt_to_phys(volatile void *address)
+{
+ BUG_ON(is_vmalloc_addr((const void *)address));
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32) || \
+ defined(CONFIG_MICROBLAZE)
+ return __virt_to_phys(address);
+#else
+ return virt_to_phys(address);
+#endif
+}
+EXPORT_SYMBOL(debug_virt_to_phys);
+
#endif /* CONFIG_DEBUG_VM */
--
2.9.3
^ permalink raw reply related
* [PATCH] PCI: enable extended tags support for PCIe endpoints
From: Sinan Kaya @ 2016-11-12 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111205801.GC9868@bhelgaas-glaptop.roam.corp.google.com>
On 11/11/2016 3:58 PM, Bjorn Helgaas wrote:
>> I should have checked the capability here before trying to enable it.
>> > I'll post a follow up patch on this.
>> >
>> > Is there any other feedback?
> If this were completely safe to enable for every device that supported
> it, why would there be an enable bit in Device Control?
reading from the ECN here.
https://pcisig.com/sites/default/files/specification_documents/ECN_Extended_Tag_Enable_Default_05Sept2008_final.pdf
The initial value is implementation specific and functions are allowed
to set it to 1 by default.
>
> I don't know anything about extended tags, but it worries me a little
> when there's a "go-fast" switch and no explanation about when and why
> we might need to go slo
Based on my observation, extended tags increase the number of reads that
can be queued up back to back downstream. Otherwise, the requests will not
make progress until 1 tag out of 32 gets available.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH RFC] mm: Add debug_virt_to_phys()
From: Nicolas Pitre @ 2016-11-12 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112004449.30566-1-f.fainelli@gmail.com>
On Fri, 11 Nov 2016, Florian Fainelli wrote:
> When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
> debug_virt_to_phys() which helps catch vmalloc space addresses being
> passed. This is helpful in debugging bogus drivers that just assume
> linear mappings all over the place.
>
> For ARM, ARM64, Unicore32 and Microblaze, the architectures define
> __virt_to_phys() as being the functional implementation of the address
> translation, so we special case the debug stub to call into
> __virt_to_phys directly.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/include/asm/memory.h | 4 ++++
> arch/arm64/include/asm/memory.h | 4 ++++
> include/asm-generic/memory_model.h | 4 ++++
> mm/debug.c | 15 +++++++++++++++
> 4 files changed, 27 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 76cbd9c674df..448dec9b8b00 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
> * translation for translating DMA addresses. Use the driver
> * DMA support - see dma-mapping.h.
> */
> +#ifndef CONFIG_DEBUG_VM
> #define virt_to_phys virt_to_phys
> static inline phys_addr_t virt_to_phys(const volatile void *x)
> {
> return __virt_to_phys((unsigned long)(x));
> }
> +#else
> +#define virt_to_phys debug_virt_to_phys
> +#endif
[...]
Why don't you do something more like:
static inline phys_addr_t virt_to_phys(const volatile void *x)
{
+ debug_virt_to_phys(x);
return __virt_to_phys((unsigned long)(x));
}
[...]
static inline void debug_virt_to_phys(const void *address)
{
#ifdef CONFIG_DEBUG_VM
BUG_ON(is_vmalloc_addr(address));
#endif
}
?
Nicolas
^ permalink raw reply
* [RFC 00/17] clk: Add per-controller locks to fix deadlocks
From: Stephen Boyd @ 2016-11-12 2:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7933d51e-92a8-ca6d-84f0-70b22fe17568@samsung.com>
On 11/04, Marek Szyprowski wrote:
> Hi Stephen,
>
> Krzysztof has left Samsung, but we would like to continue this task, because
> the ABBA dead-locks related to global prepare lock becomes more and more
> problematic for us to workaround.
Hmm. Ok. Thanks for the info.
>
> On 2016-09-09 02:24, Stephen Boyd wrote:
>
> >So I'm not very fond of this design because the locking scheme is
> >pretty much out of the hands of the framework and can be easily
> >broken.
>
> Well, switching from a single global lock to more granular locking
> is always a good approach. Please note that the global lock sooner
> or later became a serious bottleneck if one wants to make somehow
> more aggressive power management and clock gating.
I'm not so sure switching from a global lock to a more granular
lock is _always_ a great idea. Sometimes simpler code is better,
even if it doesn't scale to a million clk nodes. The largest
systems I've seen only have clocks in the hundreds, and a
majority of those aren't rate changing in parallel, so it's not
like we're suffering from VFS type scalability problems here with
tens of thousands of inodes.
That isn't to say I don't agree there's a scalability problem
here, but I'd like to actually see numbers to prove that there's
some sort of scalability problem before making drastic changes.
>
> > I'm biased of course, because I'd prefer we go with my
> >wwmutex design of per-clk locks[1]. Taking locks in any order
> >works fine there, and we resolve quite a few long standing
> >locking problems that we have while improving scalability. The
> >problem there is that we don't get the recursive mutex design
> >(maybe that's a benefit!).
>
> Do you have any plan to continue working on your approach? per-clk
> wwmutex looks like an overkill on the first glance, but that's probably
> the only working solution if you want to get rid of recursive locks.
> I'm still not really convinced that we really need wwmutex here,
> especially if it is possible to guarantee the same order of locking
> operations inside the clock core. This requires a bit of cooperation
> from clock providers (with proper documentation and a list of
> DO/DON'T it shouldn't be that hard).
So far I haven't gotten around to resurrecting the wwmutex stuff.
If you have interest in doing it that's great. Having a locking
scheme with rules of DO/DON'T sounds brittle to me, unless it can
be automated to find problems. I know that I'm not going to spend
time policing that.
>
> >Once a clk_op reenters the framework
> >with consumer APIs and tries to grab the same lock we deadlock.
> >This is why I've been slowly splitting consumers from providers
> >so we can easily identify these cases. If we had something like
> >coordinated clk rate switching, we could get rid of clk_ops
> >reentering the framework and avoid this problem (and we really do
> >need to do that).
>
> I'm not sure that this makes really sense split consumers and
> providers. You will get recursive calls to clk core anyway with
> consumers calls if you are implementing i2c clock, for which an i2c
> bus driver does it's own clock gating (i2c controller uses
> consumer clk api).
>
>
I suppose this is a different topic. Regardless of the recursive
call or not, we can easily see that a clk consumer is also a clk
provider and just knowing that is useful. Once we know that, we
can look to see if they're calling clk consumer APIs from their
provider callbacks which is not desired because it makes it
impossible to get rid of the recursive lock design. If the lock
is per-clock, then recursion doesn't happen when the provider is
also a consumer. If it does, that's bad and lockdep should tell
us.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: agustinv at codeaurora.org @ 2016-11-12 3:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5825C8A2.3040302@linaro.org>
Hey Lorenzo, Hanjun,
On 2016-11-11 08:33, Hanjun Guo wrote:
> Hi Lorenzo,
>
> On 11/11/2016 01:58 AM, Lorenzo Pieralisi wrote:
>> On Thu, Nov 10, 2016 at 10:02:35AM -0500, agustinv at codeaurora.org
>> wrote:
>>> Hey Hanjun,
>>>
>>> On 2016-11-09 21:36, Hanjun Guo wrote:
>>>> Hi Marc, Rafael, Lorenzo,
>>>>
>>>> Since we agreed to add a probe deferral if we failed to get irq
>>>> resources which mirroring the DT does (patch 1 in this patch set),
>>>> I think the last blocker to make things work both for Agustin and
>>>> me [1] is this patch, which makes the interrupt producer and
>>>> consumer
>>>> work in ACPI, we have two different solution for one thing, we'd
>>>> happy
>>>> to work together for one solution, could you give some suggestions
>>>> please?
>>>>
>>>> [1]:
>>>> https://mail-archive.com/linux-kernel at vger.kernel.org/msg1257419.html
>>>>
>>>> Agustin, I have some comments below.
>>>>
>>>> On 2016/10/29 4:48, Agustin Vega-Frias wrote:
>>>>> This allows irqchip drivers to associate an ACPI DSDT device to
>>>>> an IRQ domain and provides support for using the ResourceSource
>>>>> in Extended IRQ Resources to find the domain and map the IRQs
>>>>> specified on that domain.
>>>>>
>>>>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>>>>> ---
>>>>> drivers/acpi/Makefile | 1 +
>>>>> drivers/acpi/irqdomain.c | 119
>>>>> +++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>> Could we just reuse the gsi.c and not introduce a new
>>>> file, probably we can change the gsi.c to irqdomain.c
>>>> or something similar, then reuse the code in gsi.c.
>>>
>>> I was thinking just that after we chatted off-list.
>>
>> Yes, that's a fair point.
>>
>>> I might revisit and see what I come up with given that we already
>>> have
>>> a device argument and we could pass the IRQ source there.
>>
>> I agree with the approach taken by this patch, I do not like much
>> passing around struct acpi_resource_source *source (in particular
>> the dummy struct) I do not think it is needed, I will comment on
>> the code.
>
> thanks for your time to have a look:)
>
>>
>> Hopefully there is not any buggy FW out there that does use the
>> resource source inappropriately otherwise we will notice on x86/ia64
>> (ie you can't blame FW if it breaks the kernel) but I suspect the
>> only way to find out is by trying, the patch has to go through
>> Rafael's
>> review anyway before getting there so it is fine.
>
> I think we can avoid that by not touching the logic that x86/ia64
> already used, but only adding interrupt producer/consumer function.
I looked at this more today and implemented a new patch that I plan to
test over the weekend, but I wanted to let you know the approach I am
pursuing.
On the new patch use of ResourceSource when parsing ACPI Extended IRQ
Resources is conditional on CONFIG_ACPI_GENERIC_GSI. The reason for this
is two fold:
1. Since we wanted to reduce duplication and place the new APIs on the
same source file as acpi_register_gsi, which is already under that
config flag.
2. So the patch does not have effect on platforms not using the generic
GSI support, including x86/ia64.
If support for this is needed outside platforms using the generic GSI
implementation, we can move these APIs out to their own source file
and eliminate the CONFIG_ACPI_GENERIC_GSI conditionality.
I'll send the new patch, hopefully some time tomorrow, but please let
me know if you have concerns with this approach.
Thanks,
Agustin
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH RFC] mm: Add debug_virt_to_phys()
From: Florian Fainelli @ 2016-11-12 3:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.20.1611112034520.1618@knanqh.ubzr>
Le 11/11/2016 ? 17:49, Nicolas Pitre a ?crit :
> On Fri, 11 Nov 2016, Florian Fainelli wrote:
>
>> When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
>> debug_virt_to_phys() which helps catch vmalloc space addresses being
>> passed. This is helpful in debugging bogus drivers that just assume
>> linear mappings all over the place.
>>
>> For ARM, ARM64, Unicore32 and Microblaze, the architectures define
>> __virt_to_phys() as being the functional implementation of the address
>> translation, so we special case the debug stub to call into
>> __virt_to_phys directly.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm/include/asm/memory.h | 4 ++++
>> arch/arm64/include/asm/memory.h | 4 ++++
>> include/asm-generic/memory_model.h | 4 ++++
>> mm/debug.c | 15 +++++++++++++++
>> 4 files changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>> index 76cbd9c674df..448dec9b8b00 100644
>> --- a/arch/arm/include/asm/memory.h
>> +++ b/arch/arm/include/asm/memory.h
>> @@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
> [...]
>
> Why don't you do something more like:
>
> static inline phys_addr_t virt_to_phys(const volatile void *x)
> {
> + debug_virt_to_phys(x);
> return __virt_to_phys((unsigned long)(x));
> }
>
> [...]
>
> static inline void debug_virt_to_phys(const void *address)
> {
> #ifdef CONFIG_DEBUG_VM
> BUG_ON(is_vmalloc_addr(address));
> #endif
> }
>
> ?
This is how I started doing it initially, but to get the
is_vmalloc_addr() definition, we need to include linux/mm.h and then
everything falls apart because of the include and dependencies chain. We
could open code the is_vmalloc_addr() check because that's simple
enough, but we still need VMALLOC_START and VMALLOC_END and to get there
we need to include pgtable.h, and there are still some inclusion
problems in doing so.
The other reason was to avoid putting the same checks in architecture
specific code, except for those like ARM/ARM64/Unicore32/Microblaze
where I could not find a simple way to undefined virt_to_phys and
redefine it to debug_virt_to_phys.
Do you see an other way around this? Thanks!
--
Florian
^ permalink raw reply
* [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Shawn Lin @ 2016-11-12 4:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-2-git-send-email-wxt@rock-chips.com>
On 2016/11/9 21:21, Caesar Wang wrote:
> From: Ziyuan Xu <xzy.xu@rock-chips.com>
>
> Control power domain for eMMC via genpd to reduce power consumption.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
It was verified on my rk3399 evb with kernel4.4, so
free feel to add my tag,
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
BTW, it seems my reply is bounced form Yakir's address, so please
remove him from CC list if he changed his mail address.
> ---
>
> Changes in v2:
> - Reviewed-on: https://chromium-review.googlesource.com/376558
> - Verified on ChromeOS kernel4.4
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index cbb7f8b..b401176 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -269,6 +269,7 @@
> #clock-cells = <0>;
> phys = <&emmc_phy>;
> phy-names = "phy_arasan";
> + power-domains = <&power RK3399_PD_EMMC>;
> status = "disabled";
> };
>
> @@ -690,6 +691,11 @@
> status = "disabled";
> };
>
> + qos_emmc: qos at ffa58000 {
> + compatible = "syscon";
> + reg = <0x0 0xffa58000 0x0 0x20>;
> + };
> +
> qos_gmac: qos at ffa5c000 {
> compatible = "syscon";
> reg = <0x0 0xffa5c000 0x0 0x20>;
> @@ -823,6 +829,11 @@
> };
>
> /* These power domains are grouped by VD_LOGIC */
> + pd_emmc at RK3399_PD_EMMC {
> + reg = <RK3399_PD_EMMC>;
> + clocks = <&cru ACLK_EMMC>;
> + pm_qos = <&qos_emmc>;
> + };
> pd_gmac at RK3399_PD_GMAC {
> reg = <RK3399_PD_GMAC>;
> clocks = <&cru ACLK_GMAC>;
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Shawn Lin @ 2016-11-12 4:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-3-git-send-email-wxt@rock-chips.com>
Hi Caesar,
On 2016/11/9 21:21, Caesar Wang wrote:
> From: zhangqing <zhangqing@rock-chips.com>
>
> 1.add pd node for RK3399 Soc
> 2.create power domain tree
> 3.add qos node for domain
> 4.add the pd_sd consumers node
I'm no sure if it is worth spliting out a seperated
patch as it looks to me that you was doing 4 things within
one patch, but anyway
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
>
> Changes in v2:
> - v1 on https://patchwork.kernel.org/patch/9322553/
> - Reviewed-on: https://chromium-review.googlesource.com/386483
> - Verified on ChromeOS kernel4.4
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index b401176..e5b5b3d 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -253,6 +253,7 @@
> <&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
> clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> fifo-depth = <0x100>;
> + power-domains = <&power RK3399_PD_SD>;
> status = "disabled";
> };
>
> @@ -691,6 +692,11 @@
> status = "disabled";
> };
>
> + qos_sd: qos at ffa74000 {
> + compatible = "syscon";
> + reg = <0x0 0xffa74000 0x0 0x20>;
> + };
> +
> qos_emmc: qos at ffa58000 {
> compatible = "syscon";
> reg = <0x0 0xffa58000 0x0 0x20>;
> @@ -839,6 +845,12 @@
> clocks = <&cru ACLK_GMAC>;
> pm_qos = <&qos_gmac>;
> };
> + pd_sd at RK3399_PD_SD {
> + reg = <RK3399_PD_SD>;
> + clocks = <&cru HCLK_SDMMC>,
> + <&cru SCLK_SDMMC>;
> + pm_qos = <&qos_sd>;
> + };
> pd_vio at RK3399_PD_VIO {
> reg = <RK3399_PD_VIO>;
> #address-cells = <1>;
>
--
Best Regards
Shawn Lin
^ 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