* Crash seen on ARM Juno r1 with 4.8-rc8 when Coresight is enabled
From: Rabin Vincent @ 2016-09-29 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkypz383Smuqv3B5K3i9mzGxMdc1OJdc_tWQZ5qHWQCeJw@mail.gmail.com>
On Wed, Sep 28, 2016 at 11:41:41AM -0600, Mathieu Poirier wrote:
> On 28 September 2016 at 10:35, Venkatesh Vivekanandan
> <venkatesh.vivekanandan@broadcom.com> wrote:
> > [ 5.479353] Unable to handle kernel NULL pointer dereference at
> > virtual address 00000000
> > [ 5.487372] pgd = ffff000008db1000
> > [ 5.490739] [00000000] *pgd=00000009ffffe003,
> > *pud=00000009ffffd003, *pmd=0000000000000000
> > [ 5.498940] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > [ 5.504451] Modules linked in:
> > [ 5.507474] CPU: 0 PID: 449 Comm: kworker/0:1 Not tainted 4.8.0-rc8-dirty #1
> > [ 5.514447] Hardware name: ARM Juno development board (r1) (DT)
> > [ 5.520310] Workqueue: events amba_deferred_retry_func
> > [ 5.525394] task: ffff800976bfd780 task.stack: ffff8009760bc000
> > [ 5.531253] PC is at strcmp+0x1c/0x160
> > [ 5.534962] LR is at coresight_orphan_match+0x78/0xc8
> > [ 5.539957] pc : [<ffff00000835f14c>] lr : [<ffff00000870231c>]
> > pstate: 40000145
> > [ 5.547272] sp : ffff8009760bfa00
> > [ 5.550547] x29: ffff8009760bfa00 x28: ffff8009762c7f00
> > [ 5.555807] x27: ffff000008d66e46 x26: 0000000000000000
> > [ 5.561066] x25: 0000000000000001 x24: ffff000008702048
> > [ 5.566325] x23: 0000000000000000 x22: ffff800973ce5000
> > [ 5.571584] x21: ffff800973ce0800 x20: 0000000000000000
> > [ 5.576843] x19: ffff800976b08600 x18: 0000000000000000
> > [ 5.582101] x17: 0000000000000000 x16: ffff000008e52fff
> > [ 5.587360] x15: ffff000008e52fff x14: ffffffffffffffff
> > [ 5.592619] x13: ffff000008ca5000 x12: 0000000000000008
> > [ 5.597878] x11: 0000000000000020 x10: 0101010101010101
> > [ 5.603137] x9 : 0000000000000000 x8 : 7fff7f7f7f7f7f7f
> > [ 5.608396] x7 : 0000000000000000 x6 : 000000008008cb22
> > [ 5.613655] x5 : 22cb080000000000 x4 : ffff800973ce0828
> > [ 5.618914] x3 : 0000000000000000 x2 : 3030303031303032
> > [ 5.624173] x1 : 0000000000000000 x0 : ffff8009760f1d08
> > [ 5.629432]
>
> Thanks you for reporting this Vankatesh,
>
> Sudeep and Suzuki, can you guys help me with this - I don't have an R1
> to test with.
I've seen this too, on other platforms. This should fix it:
8<-----------
>From a9da7d7b47e67dd6ffcafddadb50e6f97503f296 Mon Sep 17 00:00:00 2001
From: Rabin Vincent <rabinv@axis.com>
Date: Tue, 30 Aug 2016 08:54:21 +0200
Subject: [PATCH] coresight: check for NULL child_name
Connection child names associated to ports can sometimes be NULL, which
is the case when booting a system on QEMU or when the Coresight power
domain isn't switched on. fadf3a44e974 ("coresight: checking for NULL
string in coresight_name_match()") fixed one place to handle this but
the same check is needed in coresight_orphan_match() to prevent a crash
there.
Signed-off-by: Rabin Vincent <rabinv@axis.com>
---
drivers/hwtracing/coresight/coresight.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index d08d1ab..ceeaaea 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -725,7 +725,8 @@ static int coresight_orphan_match(struct device *dev, void *data)
/* We have found at least one orphan connection */
if (conn->child_dev == NULL) {
/* Does it match this newly added device? */
- if (!strcmp(dev_name(&csdev->dev), conn->child_name)) {
+ if (conn->child_name &&
+ !strcmp(dev_name(&csdev->dev), conn->child_name)) {
conn->child_dev = csdev;
} else {
/* This component still has an orphan */
--
2.1.4
^ permalink raw reply related
* [PATCH] drm/mediatek: fix a typo
From: Matthias Brugger @ 2016-09-29 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475121682.18843.2.camel@mtksdaap41>
On 29/09/16 06:01, CK Hu wrote:
> Acked-by: CK Hu <ck.hu@mediatek.com>
>
> On Thu, 2016-09-29 at 11:22 +0800, Bibby Hsieh wrote:
>> Fix the typo: OD_RELAYMODE->OD_CFG
>>
Although it is quite clear what the patch does, could you write one
sentence to explain what it does. Maybe explain even which effect it
has, which error get fixed etc.
As we are getting public available boards now, we should take more care
about fixes. If you have a fix for a commit introduced in an earlier
version of linux and it should be fixed for this version as well (e.g.
v4.6 does have the feature but it does not work correctly) then please
add these two lines before your Signed-off-by:
Fixes: <commit-hash> ("<commit subject line>")
Cc: stable at vger.kernel.org # v4.6+
Where v4.6+ stands for the oldest version where this should get fixed.
Thanks a lot,
Matthias
>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>> ---
>> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>> index df33b3c..aa5f20f 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>> @@ -123,7 +123,7 @@ static void mtk_od_config(struct mtk_ddp_comp *comp, unsigned int w,
>> unsigned int bpc)
>> {
>> writel(w << 16 | h, comp->regs + DISP_OD_SIZE);
>> - writel(OD_RELAYMODE, comp->regs + OD_RELAYMODE);
>> + writel(OD_RELAYMODE, comp->regs + OD_CFG);
>> mtk_dither_set(comp, bpc, DISP_OD_CFG);
>> }
>>
>
>
^ permalink raw reply
* [PATCH v12 0/8] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: wangxiongfeng (C) @ 2016-09-29 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473763144-5653-1-git-send-email-fu.wei@linaro.org>
for sbsa watchdog part, Tested-by: wangxiongfeng2 at huawei.com on D05 board.
On 2016/9/13 18:38, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> This patchset:
> (1)Preparation for adding GTDT support in arm_arch_timer:
> 1. Move some enums and marcos to header file;
> 2. Add a new enum for spi type;
> 3. Improve printk relevant code.
>
> (2)Introduce ACPI GTDT parser: drivers/acpi/arm64/acpi_gtdt.c
> Parse all kinds of timer in GTDT table of ACPI:arch timer,
> memory-mapped timer and SBSA Generic Watchdog timer.
> This driver can help to simplify all the relevant timer drivers,
> and separate all the ACPI GTDT knowledge from them.
>
> (3)Simplify ACPI code for arm_arch_timer
>
> (4)Add GTDT support for ARM memory-mapped timer
>
> This patchset depends on the following patchset:
> [UPDATE PATCH V11 1/8] ACPI: I/O Remapping Table (IORT) initial support
> https://lkml.org/lkml/2016/9/12/949
>
> This patchset has been tested on the following platforms:
> (1)ARM Foundation v8 model
>
> Changelog:
> v12: https://lkml.org/lkml/2016/9/13/
> Rebase to latest Linux 4.8-rc6
> Delete the confusing "skipping" in the error message.
>
> V11: https://lkml.org/lkml/2016/9/6/354
> Rebase to latest Linux 4.8-rc5
> Delete typedef (suggested by checkpatch.pl)
>
> V10: https://lkml.org/lkml/2016/7/26/215
> Drop the "readq" patch.
> Rebase to latest Linux 4.7.
>
> V9: https://lkml.org/lkml/2016/7/25/345
> Improve pr_err message in acpi gtdt driver.
> Update Commit message for 7/9
> shorten the irq mapping function name
> Improve GTDT driver for memory-mapped timer
>
> v8: https://lkml.org/lkml/2016/7/19/660
> Improve "pr_fmt(fmt)" definition: add "ACPI" in front of "GTDT",
> and also improve printk message.
> Simplify is_timer_block and is_watchdog.
> Merge acpi_gtdt_desc_init and gtdt_arch_timer_init into acpi_gtdt_init();
> Delete __init in include/linux/acpi.h for GTDT API
> Make ARM64 select GTDT.
> Delete "#include <linux/module.h>" from acpi_gtdt.c
> Simplify GT block parse code.
>
> v7: https://lkml.org/lkml/2016/7/13/769
> Move the GTDT driver to drivers/acpi/arm64
> Add add the ARM64-specific ACPI Support maintainers in MAINTAINERS
> Merge 3 patches of GTDT parser driver.
> Fix the for_each_platform_timer bug.
>
> v6: https://lkml.org/lkml/2016/6/29/580
> split the GTDT driver to 4 parts: basic, arch_timer, memory-mapped timer,
> and SBSA Generic Watchdog timer
> Improve driver by suggestions and example code from Daniel Lezcano
>
> v5: https://lkml.org/lkml/2016/5/24/356
> Sorting out all patches, simplify the API of GTDT driver:
> GTDT driver just fills the data struct for arm_arch_timer driver.
>
> v4: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006667.html
> Delete the kvm relevant patches
> Separate two patches for sorting out the code for arm_arch_timer.
> Improve irq info export code to allow missing irq info in GTDT table.
>
> v3: https://lkml.org/lkml/2016/2/1/658
> Improve GTDT driver code:
> (1)improve pr_* by defining pr_fmt(fmt)
> (2)simplify gtdt_sbsa_gwdt_init
> (3)improve gtdt_arch_timer_data_init, if table is NULL, it will try
> to get GTDT table.
> Move enum ppi_nr to arm_arch_timer.h, and add enum spi_nr.
> Add arm_arch_timer get ppi from DT and GTDT support for kvm.
>
> v2: https://lkml.org/lkml/2015/12/2/10
> Rebase to latest kernel version(4.4-rc3).
> Fix the bug about the config problem,
> use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c
>
> v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553
>
> Fu Wei (8):
> clocksource/drivers/arm_arch_timer: Move enums and defines to header
> file
> clocksource/drivers/arm_arch_timer: Add a new enum for spi type
> clocksource/drivers/arm_arch_timer: Improve printk relevant code
> acpi/arm64: Add GTDT table parse driver
> clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
> acpi/arm64: Add memory-mapped timer support in GTDT driver
> clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped
> timer
> acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver
>
> arch/arm64/Kconfig | 1 +
> drivers/acpi/arm64/Kconfig | 3 +
> drivers/acpi/arm64/Makefile | 1 +
> drivers/acpi/arm64/gtdt.c | 309 +++++++++++++++++++++++++++++++++++
> drivers/clocksource/Kconfig | 2 +-
> drivers/clocksource/arm_arch_timer.c | 225 +++++++++++++++++--------
> drivers/watchdog/Kconfig | 1 +
> include/clocksource/arm_arch_timer.h | 32 ++++
> include/linux/acpi.h | 7 +
> 9 files changed, 510 insertions(+), 71 deletions(-)
> create mode 100644 drivers/acpi/arm64/gtdt.c
>
^ permalink raw reply
* [RFC PATCH 00/11] pci: support for configurable PCI endpoint
From: Kishon Vijay Abraham I @ 2016-09-29 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E8BB69.4020804@ti.com>
Hi Arnd,
On Monday 26 September 2016 11:38 AM, Kishon Vijay Abraham I wrote:
> Hi Arnd,
>
> On Thursday 22 September 2016 07:04 PM, Arnd Bergmann wrote:
>> On Thursday, September 15, 2016 2:03:05 PM CEST Kishon Vijay Abraham I wrote:
>>> On Wednesday 14 September 2016 06:55 PM, Arnd Bergmann wrote:
>>>> On Wednesday, September 14, 2016 10:41:56 AM CEST Kishon Vijay Abraham I wrote:
>>>> I've added the drivers/ntb maintainers to Cc, given that there is
>>>> a certain degree of overlap between your work and the existing
>>>> code, I think they should be part of the discussion.
>>>>
>>>>> Known Limitation:
>>>>> *) Does not support multi-function devices
>>>>
>>>> If I understand it right, this was a problem for USB and adding
>>>> it later made it somewhat inconsistent. Maybe we can at least
>>>> try to come up with an idea of how multi-function devices
>>>> could be handled even if we don't implement it until someone
>>>> actually needs it.
>>>
>>> Actually IMO multi-function device in PCI should be much simpler than it is for
>>> USB. In the case of USB, all the functions in a multi-function device will
>>> share the same *usb configuration* . (USB device can have multiple
>>> configuration but only one can be enabled at a time). A multi-function USB
>>> device will still have a single vendor-id/product-id/class... So I think a
>>> separate library (composite.c) in USB makes sense.
>>
>> Ok, makes sense.
>>
>>> But in the case of PCI, every function can be treated independently since all
>>> the functions have it's own 4KB configuration space. Each function can be
>>> configured independently. Each can have it's own vendor-id/product-id/class..
>>> I'm not sure if we'll need a separate library for PCI like we have for USB.
>>
>> I think it depends on whether we want to add the software multi-function
>> support you mention.
>>
>>> Now the restriction for not allowing multi-function device is because of the
>>> following structure definition.
>>>
>>> struct pci_epc {
>>> ..
>>> struct pci_epf *epf;
>>> ..
>>> };
>>>
>>> EPC has a single reference to EPF and it is used *only* to notify the function
>>> driver when the link is up. (If this can be changed to use notification
>>> mechanism, multi-function devices can be supported here)
>>>
>>> One more place where this restriction arises is in designware driver
>>>
>>> struct dw_pcie_ep {
>>> ..
>>> u8 bar_to_atu[6];
>>> ..
>>> };
>>>
>>> We use single ATU window to configure a BAR (in BAR). If there are multiple
>>> functions, then this should also be modified since each function has 6 BARs.
>>>
>>> This can be fixed without much effort unless some other issue props up.
>>
>> Ok.
>>
>>>>
>>>> Is your hardware able to make the PCIe endpoint look like
>>>> a device with multiple PCI functions, or would one have to
>>>> do this in software inside of a single PCI function if we
>>>> ever need it?
>>>
>>> The hardware I have doesn't support multiple PCI functions (like having a
>>> separate configuration space for each function). It has a dedicated space for
>>> configuration space supporting only one function. [Section 24.9.7.3.2
>>> PCIe_SS_EP_CFG_DBICS Register Description in [1]].
>>>
>>> yeah, it has to be done in software (but that won't be multi-function device in
>>> PCI terms).
>>>
>>> [1] -> http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf
>>
>> Ok, so in theory there can be other hardware (and quite likely is)
>> that supports multiple functions, and we can extend the framework
>> to support them without major obstacles, but your hardware doesn't,
>> so you kept it simple with one hardcoded function, right?
>
> right, PCIe can have upto 8 functions. So the issues with the current framework
> has to be fixed. I don't expect major obstacles with this as of now.
>>
>> Seems completely reasonable to me.
>>
>>>>> TODO:
>>>>> *) access buffers in RC
>>>>> *) raise MSI interrupts
>>>>> *) Enable user space control for the RC side PCI driver
>>>>
>>>> The user space control would end up just being one of several
>>>> gadget drivers, right? E.g. gadget drivers for standard hardware
>>>> (8250 uart, ATA, NVMe, some ethernet) could be done as kernel
>>>> drivers while a user space driver can be used for things that
>>>> are more unusual and that don't need to interface to another
>>>> part of the kernel?
>>>
>>> Actually I didn't mean that. It was more with respect to the host side PCI test
>>> driver (drivers/misc/pci_endpoint_test.c). Right now it validates BAR, irq
>>> itself. I wanted to change this so that the user controls which tests to run.
>>> (Like for USB gadget zero tests, testusb.c invokes ioctls to perform various
>>> tests). Similarly I want to have a userspace program invoke pci_endpoint_test
>>> to perform various PCI tests.
>>
>> Ok, I see. So what I described above would be yet another function
>> driver that can be implemented, but so far, you have not planned
>> to do that because there was not need, right?
>
> right. I felt pci_endpoint_test is the generic function that would be of
> interest to all the vendors. Any new function can be added by taking
> pci_endpoint_test as a reference.
>
> The simple usecase I plan to work on after completing the framework is to have
> a camera sensor in one board and display in another board (the boards connected
> using PCIe) and the display showing the the camera capture.
>>
>>>>
>>>>> *) Adapt all other users of designware to use the new design (only
>>>>> dra7xx has been adapted)
>>>>
>>>> I don't fully understand this part. Does every designware based
>>>> driver need modifications, or are the changes to the
>>>> generic parts of the designware driver enough to make it
>>>> work for the simpler platforms?
>>>
>>> I have changed the core designware driver structures (like previously the
>>> platform drivers will only use pcie_port, but now I introduced struct dw_pcie
>>> to support both host and endpoint). This will break (compilation failure) all
>>> the designware based drivers (except dra7xx). All these drivers should be
>>> adapted to the new change (even if they work only in host mode these has to be
>>> adapted).
>>
>> Ah, so we have to do two separate modifications to each designware driver:
>>
>> a) make it work with your patch (mandatory)
>> b) make it support endpoint mode (optional)
>
> yes.
>>
>>>>> HOW TO:
>>>>>
>>>>> ON THE EP SIDE:
>>>>> ***************
>>>>>
>>>>> /* EP function is configured using configfs */
>>>>> # mount -t configfs none /sys/kernel/config
>>>>>
>>>>> /* PCI EP core layer creates "pci_ep" entry in configfs */
>>>>> # cd /sys/kernel/config/pci_ep/
>>>>>
>>>>> /*
>>>>> * This is the 1st step in creating an endpoint function. This
>>>>> * creates the endpoint function device *instance*. The string
>>>>> * before the .<num> suffix will identify the driver this
>>>>> * EP function will bind to.
>>>>> * Just pci_epf_test is also valid. The .<num> suffix is used
>>>>> * if there are multiple PCI controllers and all of them wants
>>>>> * to use the same function.
>>>>> */
>>>>> # mkdir pci_epf_test.0
>>>>
>>>> I haven't used USB gadgets, but I assume this is modeled around
>>>> the same interface. If there are notable differences, please mention
>>>> what they are. Otherwise the general concept seems rather nice to me.
>>>
>>> Yeah, both USB gadget and PCI endpoint use configfs interface but the semantics
>>> are quite different.
>>>
>>> Every directory in *usb_gadget* corresponds to a gadget device, and the gadget
>>> device has a functions sub-directory which has the USB functions. And these
>>> directories have fields or attributes specific to USB.
>>>
>>> But in the case of PCI, every directory in *pci_ep* corresponds to a PCI
>>> function and it has fields or attributes specific to PCI function.
>>
>> Ok, I see.
>>
>>> The main reason for using configfs for PCI endpoint is to give the users to
>>> control "which function has to be bound to which controller". The same concept
>>> is used for USB gadget as well but there it is "which gadget device has to be
>>> bound to which controller".
>>
>> We should still find out whether it's important that you can have
>> a single PCI function with a software multi-function support of some
>> sort. We'd still be limited to six BARs in total, and would also need
>> something to identify those sub-functions, so implementing that might
>> get quite hairy.
Thought a bit on how to implement this and felt we should have the following
entities:-
* Function (or main function)
* sub-Function
* device
Function: a single PCI function (as defined in the PCI specification with a
separate configuration space). It will have control over the PCI header, manage
BAR's and interrupts. It may or may not have sub-functions (sub-functions can
be one or many).
Managing BAR's: The sub-functions will not have information
about BAR's. It will just request the number of
address space it requires to the main *function*. The
main function will allocate one BAR for each such
request based on the BAR availability.
Managing interrupts:
FOR MSI: Say each main function is capable of supporting 32 MSI
interrupts. Each sub-function can request 'n' number
of interrupts. (The sub-function will not be aware of
the MSI number allocated to it). For each
sub-function the interrupts will be numbered from
'1..n'. The main function will map the sub-function
interrupt to MSI interrupt number.
For legacy: No management is required, since one interrupt
line will be shared by all sub-functions. The host
driver will check the interrupt status register.
Is there any thing else that has to be managed by the main Function?
Here the framework should be modified to add a new interface between the
sub-function and main Function. A *simple* main Function should also be added
to manage only the BARs and interrupts. For any special use case, new main
Function has to be created.
The host side driver for this main function will be bound to it using the
existing PCI host side mechanism. (using device id/vendor id/class code etc..).
sub-Function: Not defined in PCI specification. It will be *part* of the main
function. There can be one or more sub-function within a main function. Each
sub-function within a main function will be independent of each other.
It will request the number of local address space required and the number of
MSI interrupts from the main function.
Each sub-function should have a separate host side driver. But how do we bind
the host side driver with the sub-function? Here the existing host side PCI
framework won't work.
Some options for binding sub-function to it's host side driver:
Have a separate vendor-id/product id for each sub function. (But the *pci_dev*
for the sub-function will not be created by host side PCI framework. The PCI
framework shouldn't also have to do it because this is not standard).
The main *function* driver will scan the list of it's sub-functions (We can
make the 1st BAR to be used by main *Function* and have these informations
there.) and for each function it creates a new *pci_dev* allocating the memory
resources. This way the sub-function host side driver can be created just like
a regular PCI driver. I'm not sure if creating a pci_dev from a pci driver will
have any adverse effects.
The other option is to define a new type of device (say pci_func_dev) and make
the main *function* driver create these devices when it is getting probed. For
binding, we can maybe just use a compatible string populated by the
sub-function driver when it registers with the main function driver. Since this
doesn't use an existing data structure, this should not be very difficult to
implement.
With either options, lspci won't list any sub-functions.
device: one or more function (main function) will constitute a device. This
shouldn't be too difficult to implement.
I think most of the complexity lies in the design of sub-function. Please let
me know your thoughts and other ideas.
Thanks
Kishon
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Jisheng Zhang @ 2016-09-29 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929081818.GE28107@nuc-i3427.alporthouse.com>
On Thu, 29 Sep 2016 09:18:18 +0100 Chris Wilson wrote:
> On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
> > On Marvell berlin arm64 platforms, I see the preemptoff tracer report
> > a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
> > awfully bad for STB. And the ftrace log also shows __free_vmap_area
> > contributes most latency now. I noticed that Joel mentioned the same
> > issue[1] on x86 platform and gave two solutions, but it seems no patch
> > is sent out for this purpose.
> >
> > This patch adopts Joel's first solution, but I use 16MB per core
> > rather than 8MB per core for the number of lazy_max_pages. After this
> > patch, the preemptoff tracer reports a max 6455us latency, reduced to
> > 1/4 of original result.
>
> My understanding is that
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 91f44e78c516..3f7c6d6969ac 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
> static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> int sync, int force_flush)
> {
> - static DEFINE_SPINLOCK(purge_lock);
> struct llist_node *valist;
> struct vmap_area *va;
> struct vmap_area *n_va;
> @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> * should not expect such behaviour. This just simplifies locking for
> * the case that isn't actually used at the moment anyway.
> */
> - if (!sync && !force_flush) {
> - if (!spin_trylock(&purge_lock))
> - return;
> - } else
> - spin_lock(&purge_lock);
> -
> if (sync)
> purge_fragmented_blocks_allcpus();
>
> @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> __free_vmap_area(va);
> spin_unlock(&vmap_area_lock);
Hi Chris,
Per my test, the bottleneck now is __free_vmap_area() over the valist, the
iteration is protected with spinlock vmap_area_lock. So the larger lazy max
pages, the longer valist, the bigger the latency.
So besides above patch, we still need to remove vmap_are_lock or replace with
mutex.
Thanks,
Jisheng
> }
> - spin_unlock(&purge_lock);
> }
>
> /*
>
>
> should now be safe. That should significantly reduce the preempt-disabled
> section, I think.
> -Chris
>
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Chris Wilson @ 2016-09-29 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929073411.3154-1-jszhang@marvell.com>
On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
> On Marvell berlin arm64 platforms, I see the preemptoff tracer report
> a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
> awfully bad for STB. And the ftrace log also shows __free_vmap_area
> contributes most latency now. I noticed that Joel mentioned the same
> issue[1] on x86 platform and gave two solutions, but it seems no patch
> is sent out for this purpose.
>
> This patch adopts Joel's first solution, but I use 16MB per core
> rather than 8MB per core for the number of lazy_max_pages. After this
> patch, the preemptoff tracer reports a max 6455us latency, reduced to
> 1/4 of original result.
My understanding is that
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 91f44e78c516..3f7c6d6969ac 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
int sync, int force_flush)
{
- static DEFINE_SPINLOCK(purge_lock);
struct llist_node *valist;
struct vmap_area *va;
struct vmap_area *n_va;
@@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
* should not expect such behaviour. This just simplifies locking for
* the case that isn't actually used at the moment anyway.
*/
- if (!sync && !force_flush) {
- if (!spin_trylock(&purge_lock))
- return;
- } else
- spin_lock(&purge_lock);
-
if (sync)
purge_fragmented_blocks_allcpus();
@@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
__free_vmap_area(va);
spin_unlock(&vmap_area_lock);
}
- spin_unlock(&purge_lock);
}
/*
should now be safe. That should significantly reduce the preempt-disabled
section, I think.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply related
* [PATCH] arm64: set path to Image.gz in the mkspec to avoid rpm build issue
From: Vadim Lomovtsev @ 2016-09-29 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9900a5d1-d133-12dc-0ff1-9370e6dab7a7@suse.com>
On Thu, Sep 29, 2016 at 09:23:51AM +0200, Michal Marek wrote:
> On 2016-09-28 11:49, Will Deacon wrote:
> > [Adding Michal Marek]
> >
> > On Tue, Sep 27, 2016 at 08:53:47AM -0700, Vadim Lomovtsev wrote:
> >> In addition to http://www.spinics.net/lists/arm-kernel/msg527466.html
> >>
> >> While building rpm-pkg target it fails to copy kernel image
> >> from default location to rpm buildroot directory.
> >>
> >> Since we have arch variable set to aarch64 while Image.gz
> >> is located at arch/arm64/boot it's necessary to specify
> >> correct path to cp command as it implemeted for ppc64 build.
>
> The variable should point to the actual file. ppc64 should be fixed as well.
>
> Michal
Understood. Thanks for feed-back.
Vadim
^ permalink raw reply
* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Greg Kroah-Hartman @ 2016-09-29 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3dc3a39b-5cae-1ad1-df44-bed4703121c3@atmel.com>
On Thu, Sep 29, 2016 at 09:37:46AM +0200, Nicolas Ferre wrote:
> Le 29/09/2016 ? 08:31, Greg Kroah-Hartman a ?crit :
> > On Wed, Sep 28, 2016 at 05:47:35PM +0200, Nicolas Ferre wrote:
> >> Change maintainer for the serial driver found on most of the
> >> Microchip / Atmel MPUs and take advantage of the move to rename
> >> and reorder the entry.
> >> I'm happy that Richard is taking over the maintenance of this
> >> driver.
> >>
> >> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> >> Acked-by: Richard Genoud <richard.genoud@gmail.com>
> >> ---
> >> MAINTAINERS | 11 ++++++-----
> >> 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > This doesn't apply to my tty-next tree at all, what did you make it
> > against?
>
> Yesterdays' linux-next (next-20160928 tag). I thought it would be the
> best for easy pick-up by anybody, particularly on a highly shared file
> like MAINTAINERS.
>
> Tell me if you want me to collect all tags, rebase on tty-next and re-send.
It's ok, I've fixed it up by hand, it's a tough file to handle at times
with lots of different trees touching it like you mention.
greg k-h
^ permalink raw reply
* [PATCH v3 7/7] i2c: bcm2835: Add support for dynamic clock
From: Martin Sperl @ 2016-09-29 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r383g1kb.fsf@eliezer.anholt.net>
On 28.09.2016 23:24, Eric Anholt wrote:
> Noralf Tr?nnes <noralf@tronnes.org> writes:
>
>> Support a dynamic clock by reading the frequency and setting the
>> divisor in the transfer function instead of during probe.
> Is this fixing some particular case you could note in the commit
> message? As is, it makes me think that we should be using a notifier
> for when the parent clock (that's the one I assume you're talking about
> being dynamic) changes. But maybe you're working around a variable VPU
> clock being set by the firmware, because we don't have a notifier for
> it?
>
> I'm a bit worried because I think this is going to be pretty expensive
> to be doing per transfer.
Well, the clocks are all configured without CLK_GET_RATE_NOCACHE et. al.,
so the value is read from cache, which is not (very) expensive
(see clk_core_get_rate).
This also means that any clock change of the VPU done by the firmware
does not propagate to the linux kernel anyway and the unchanged
cached value is returned.
To make this work it would require a notification mechanism from the
firmware to trigger a re-validation of all the caches. (or some sort of
watchdog
process).
Adding a notifier to each driver (I2C, SPI) instead is - imo - a lot of
unnecessary
code complexity, as any currently running transfer would still be impacted,
because changing the clock-divider in flight is a asking for trouble.
But then changing the vpu-clock speed while a I2s/SPI/... transfer is
running is
also asking for trouble....
The only place where - IMO - a notifier would make sense is with the
auxiliar
UART driver(8250_bcm2835aux.c), as there we only read the clock rates
when setting/changing the baud rate. But - again - this would require some
notification by the firmware in the first place and any reception in the
window of change would go wrong because of unexpected effective baud
rate changes.
So as far as I can tell the change to read the current clock rate in the
transfer function is a reasonable approach and the clock framework should
handle the communication with the firmware about such changes.
(And I remember having had some discussions around this subject
with Phil Elwell or popcornmix some time ago on github where it boiled
down to: what is the "right" interface? - I can not find the reference
right now)
Reviewed-by: Martin Sperl <kernel@martin.sperl.org>
Thanks, Martin
^ permalink raw reply
* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Andrew Jeffery @ 2016-09-29 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8Xc7y3GtcJCVYYs-JKTqBZvqVeZaz5MUk=UX151SX1xEFw@mail.gmail.com>
On Thu, 2016-09-29 at 16:15 +0930, Joel Stanley wrote:
> On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > The System Control Unit IP in the Aspeed SoCs is typically where the
> > pinmux configuration is found.
> >
> > But not always.
> >
> > On the AST2400 and AST2500 a number of pins depend on state in one of
> > the SIO, LPC or GFX IP blocks, so add support to at least capture what
> > that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
> > inspect or modify the state of the off-SCU IP blocks. Instead, it logs
> > the state requirement with the expectation that the platform
> > designer/maintainer arranges for the appropriate configuration to be
> > applied through the associated drivers.
> This is unfortunate.
>
> This patch kicks the can down the road, but doesn't solve the problem
> for a user who wants to configure some functionality that depends on
> the non-SCU bits. Because of this I'm not sure if we want to put it in
> the tree.
I agree that there's not much functionality from a user's perspective,
but the "kicking the can down the road" assessment might be a little
harsh. Given the lack of user functionality it becomes more difficult
to argue for the patch's inclusion given the additional complexity, but
it does mean that the g4/g5 drivers can completely specify their
dependencies and not have the aspeed pinctrl core do the wrong thing
when it encounters the non-SCU IP offsets. It gets us half-way to
having the pinctrl driver actually configure the state (knowing what it
needs to configure), which I feel is more than a kick-the-can-down-the-
road boondoggle.
>
> However, I'm not sure what a proper solution would look like.
So if we accept that a proper solution includes specifying the off-SCU
dependencies, the remaining question is how do we tastefully apply the
desired state on register-spaces the pinctrl driver doesn't own.
> Perhaps
> Linus can point out another SoC that has a similar problem?
Or failing that, an approach that is acceptable...
Cheers,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160929/31192dfd/attachment-0001.sig>
^ permalink raw reply
* drm/mediatek: fixed the calc method of data rate per lane
From: CK Hu @ 2016-09-29 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472191831-7150-1-git-send-email-jitao.shi@mediatek.com>
Hi, Jitao:
Sorry for late reply.
Some comments inline.
On Fri, 2016-08-26 at 14:10 +0800, Jitao Shi wrote:
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> signal will cause h-time larger than normal and reduce FPS.
> Need to multiply a coefficient to offset the extra signal's effect.
> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
> Ths_exit)/(htotal*bpp/lane_number))
>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 111 ++++++++++++++++++++++--------------
> 1 file changed, 67 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 28b2044..506aa22 100644
[snip...]
>
> -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> +static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
> + u32 phy_timing1, u32 phy_timing2,
> + u32 phy_timing3)
> {
> - u32 timcon0, timcon1, timcon2, timcon3;
> - unsigned int ui, cycle_time;
> - unsigned int lpx;
> -
> - ui = 1000 / dsi->data_rate + 0x01;
> - cycle_time = 8000 / dsi->data_rate + 0x01;
> - lpx = 5;
> -
> - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> - (4 * lpx);
> - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> - NS_TO_CYCLE(0x40, cycle_time);
> -
> - writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> - writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> - writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
> - writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
> + writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
> + writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
> + writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
> + writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
> }
>
> static void mtk_dsi_enable(struct mtk_dsi *dsi)
> @@ -202,19 +186,57 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> {
> struct device *dev = dsi->dev;
> int ret;
> + u64 bit_clock, total_bits;
> + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> + u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
>
> if (++dsi->refcount != 1)
> return 0;
>
> + phy_timing0 = LPX(5) | HS_PRPR(6) | HS_ZERO(10) | HS_TRAIL(8);
> + phy_timing1 = TA_GO(20) | TA_SURE(7) | TA_GET(25) | DA_HS_EXIT(7);
> + phy_timing2 = CLK_ZERO(38) | CLK_TRAIL(22);
> + phy_timing3 = CLK_HS_PRPR(8) | CLK_HS_POST(21) | CLK_HS_EXIT(10);
The original phy_timing2 and phy_timing3 is defined as
timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
(NS_TO_CYCLE(0x150, cycle_time) << 16);
timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8
|
NS_TO_CYCLE(0x40, cycle_time);
They are varied by cycle_time. I think you should not use a fixed value
for them.
> +
> + switch (dsi->format) {
> + case MIPI_DSI_FMT_RGB565:
> + bit_per_pixel = 16;
> + break;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + bit_per_pixel = 18;
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB888:
> + default:
> + bit_per_pixel = 24;
> + break;
> + }
> /**
> - * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> - * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> - * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> - * we set mipi_ratio is 1.05.
> + * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
> + * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
> + * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
> + * + Thstrail + Ths_exit + Ths_zero) /
> + * (htotal * byte_per_pixel /lane_number)
> */
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
> + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> + dsi->vm.hsync_len;
> + htotal_bits = htotal * bit_per_pixel;
> +
> + /**
> + * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> + */
> + overhead_cycles = (phy_timing0 & 0xff) + (phy_timing0 >> 8 & 0xff) +
> + (phy_timing0 >> 16 & 0xff) +
> + (phy_timing0 >> 24 & 0xff) +
> + (phy_timing1 >> 24 & 0xff);
I think phy_timing0 and phy_timing1 is defined as
phy_timing0 = LPX(a) | HS_PRPR(b) | HS_ZERO(c) | HS_TRAIL(d);
phy_timing1 = TA_GO(e) | TA_SURE(f) | TA_GET(g) | DA_HS_EXIT(h);
So, it could be a more simple way to assign overhead_cycles like this
overhead_cycles = a + b + c + d + h;
Because these variable are constant, maybe you can define them as
symbols.
> + overhead_bits = overhead_cycles * dsi->lanes * 8;
> + total_bits = htotal_bits + overhead_bits;
> +
> + dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
> + htotal_bits * dsi->lanes);
>
> - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> if (ret < 0) {
> dev_err(dev, "Failed to set data rate: %d\n", ret);
> goto err_refcount;
> @@ -236,7 +258,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>
> mtk_dsi_enable(dsi);
> mtk_dsi_reset(dsi);
> - dsi_phy_timconfig(dsi);
> + dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
> + phy_timing3);
>
> return 0;
>
Regards,
CK
^ permalink raw reply
* [PATCH v6 0/3] arm64 kexec-tools patches
From: Simon Horman @ 2016-09-29 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923085840.GA22928@localhost.localdomain>
On Wed, Sep 28, 2016 at 06:05:14PM +0200, Matthias Brugger wrote:
>
>
> On 21/09/16 20:14, Geoff Levand wrote:
> >This series adds the core support for kexec re-boot on ARM64.
> >
>
> I also tested on seattle.
>
> Tested-By: Matthias Brugger <mbrugger@suse.com>
On Fri, Sep 23, 2016 at 02:28:40PM +0530, Pratyush Anand wrote:
> Hi Geoff,
>
> On 21/09/2016:06:14:25 PM, Geoff Levand wrote:
> > This series adds the core support for kexec re-boot on ARM64.
>
> I tested this series with mustang and seattle and they work.
>
> So you can use my "Tested-By: Pratyush Anand <panand@redhat.com>".
>
> Just one Nitpick: In patch 2/3 arm64_header_check_msb(),
> arm64_header_page_size() and arm64_header_placement() have been defined but they
> have not been used anywhere. So, may be they can be removed.
Thanks everyone, I have queued this up with the above tags.
Please consider a follow-up patch to remove the functions mentioned above.
FWIW I tested v5 of this patchset on Renesas Gen3 R-Car H3 and M3-W and
it seems to work fine.
^ permalink raw reply
* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Nicolas Ferre @ 2016-09-29 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929063148.GA418@kroah.com>
Le 29/09/2016 ? 08:31, Greg Kroah-Hartman a ?crit :
> On Wed, Sep 28, 2016 at 05:47:35PM +0200, Nicolas Ferre wrote:
>> Change maintainer for the serial driver found on most of the
>> Microchip / Atmel MPUs and take advantage of the move to rename
>> and reorder the entry.
>> I'm happy that Richard is taking over the maintenance of this
>> driver.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> Acked-by: Richard Genoud <richard.genoud@gmail.com>
>> ---
>> MAINTAINERS | 11 ++++++-----
>> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> This doesn't apply to my tty-next tree at all, what did you make it
> against?
Yesterdays' linux-next (next-20160928 tag). I thought it would be the
best for easy pick-up by anybody, particularly on a highly shared file
like MAINTAINERS.
Tell me if you want me to collect all tags, rebase on tty-next and re-send.
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Jisheng Zhang @ 2016-09-29 7:34 UTC (permalink / raw)
To: linux-arm-kernel
On Marvell berlin arm64 platforms, I see the preemptoff tracer report
a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
awfully bad for STB. And the ftrace log also shows __free_vmap_area
contributes most latency now. I noticed that Joel mentioned the same
issue[1] on x86 platform and gave two solutions, but it seems no patch
is sent out for this purpose.
This patch adopts Joel's first solution, but I use 16MB per core
rather than 8MB per core for the number of lazy_max_pages. After this
patch, the preemptoff tracer reports a max 6455us latency, reduced to
1/4 of original result.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1603.2/04803.html
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 91f44e7..66f377a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -596,7 +596,7 @@ static unsigned long lazy_max_pages(void)
log = fls(num_online_cpus());
- return log * (32UL * 1024 * 1024 / PAGE_SIZE);
+ return log * (16UL * 1024 * 1024 / PAGE_SIZE);
}
static atomic_t vmap_lazy_nr = ATOMIC_INIT(0);
--
2.9.3
^ permalink raw reply related
* [PATCH] arm64: set path to Image.gz in the mkspec to avoid rpm build issue
From: Michal Marek @ 2016-09-29 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160928094913.GD24658@arm.com>
On 2016-09-28 11:49, Will Deacon wrote:
> [Adding Michal Marek]
>
> On Tue, Sep 27, 2016 at 08:53:47AM -0700, Vadim Lomovtsev wrote:
>> In addition to http://www.spinics.net/lists/arm-kernel/msg527466.html
>>
>> While building rpm-pkg target it fails to copy kernel image
>> from default location to rpm buildroot directory.
>>
>> Since we have arch variable set to aarch64 while Image.gz
>> is located at arch/arm64/boot it's necessary to specify
>> correct path to cp command as it implemeted for ppc64 build.
The variable should point to the actual file. ppc64 should be fixed as well.
Michal
^ permalink raw reply
* [PATCH] MAINTAINERS: add myself as Marvell berlin SoC co-maintainers
From: Jisheng Zhang @ 2016-09-29 6:55 UTC (permalink / raw)
To: linux-arm-kernel
I would like to help maintaining Marvell berlin SoCs.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b003d0c..b1e5243 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1411,6 +1411,7 @@ F: arch/arm/configs/mvebu_*_defconfig
ARM/Marvell Berlin SoC support
M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+M: Jisheng Zhang <jszhang@marvell.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-berlin/
--
2.9.3
^ permalink raw reply related
* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Joel Stanley @ 2016-09-29 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a266046d34009e6e92c4c76699c550c2ba44bd5c.1474986045.git-series.andrew@aj.id.au>
On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> The System Control Unit IP in the Aspeed SoCs is typically where the
> pinmux configuration is found.
>
> But not always.
>
> On the AST2400 and AST2500 a number of pins depend on state in one of
> the SIO, LPC or GFX IP blocks, so add support to at least capture what
> that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
> inspect or modify the state of the off-SCU IP blocks. Instead, it logs
> the state requirement with the expectation that the platform
> designer/maintainer arranges for the appropriate configuration to be
> applied through the associated drivers.
This is unfortunate.
This patch kicks the can down the road, but doesn't solve the problem
for a user who wants to configure some functionality that depends on
the non-SCU bits. Because of this I'm not sure if we want to put it in
the tree.
However, I'm not sure what a proper solution would look like. Perhaps
Linus can point out another SoC that has a similar problem?
Cheers,
Joel
>
> The IP block of interest is encoded in the reg member of struct
> aspeed_sig_desc. For compatibility with the existing code, the SCU is
> defined to have an IP value of 0.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> drivers/pinctrl/aspeed/pinctrl-aspeed.c | 53 +++++++++++++++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed.h | 16 +++++++-
> 2 files changed, 61 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> index 49aeba912531..21ef195d586f 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> @@ -14,6 +14,8 @@
> #include "../core.h"
> #include "pinctrl-aspeed.h"
>
> +const char *const aspeed_pinmux_ips[] = { "SCU", "SIO", "GFX", "LPC" };
> +
> int aspeed_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
> {
> struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
> @@ -78,7 +80,9 @@ int aspeed_pinmux_get_fn_groups(struct pinctrl_dev *pctldev,
> static inline void aspeed_sig_desc_print_val(
> const struct aspeed_sig_desc *desc, bool enable, u32 rv)
> {
> - pr_debug("SCU%x[0x%08x]=0x%x, got 0x%x from 0x%08x\n", desc->reg,
> + pr_debug("Want %s%lX[0x%08X]=0x%X, got 0x%X from 0x%08X\n",
> + aspeed_pinmux_ips[SIG_DESC_IP_FROM_REG(desc->reg)],
> + SIG_DESC_OFFSET_FROM_REG(desc->reg),
> desc->mask, enable ? desc->enable : desc->disable,
> (rv & desc->mask) >> __ffs(desc->mask), rv);
> }
> @@ -105,6 +109,8 @@ static bool aspeed_sig_desc_eval(const struct aspeed_sig_desc *desc,
> unsigned int raw;
> u32 want;
>
> + WARN_ON(SIG_DESC_IP_FROM_REG(desc->reg) != ASPEED_IP_SCU);
> +
> if (regmap_read(map, desc->reg, &raw) < 0)
> return false;
>
> @@ -142,9 +148,19 @@ static bool aspeed_sig_expr_eval(const struct aspeed_sig_expr *expr,
>
> for (i = 0; i < expr->ndescs; i++) {
> const struct aspeed_sig_desc *desc = &expr->descs[i];
> + size_t ip = SIG_DESC_IP_FROM_REG(desc->reg);
> +
> + if (ip == ASPEED_IP_SCU) {
> + if (!aspeed_sig_desc_eval(desc, enabled, map))
> + return false;
> + } else {
> + size_t offset = SIG_DESC_OFFSET_FROM_REG(desc->reg);
> + const char *ip_name = aspeed_pinmux_ips[ip];
> +
> + pr_debug("Ignoring configuration of field %s%X[0x%08X]\n",
> + ip_name, offset, desc->mask);
> + }
>
> - if (!aspeed_sig_desc_eval(desc, enabled, map))
> - return false;
> }
>
> return true;
> @@ -170,7 +186,14 @@ static bool aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
> for (i = 0; i < expr->ndescs; i++) {
> bool ret;
> const struct aspeed_sig_desc *desc = &expr->descs[i];
> +
> + size_t offset = SIG_DESC_OFFSET_FROM_REG(desc->reg);
> + size_t ip = SIG_DESC_IP_FROM_REG(desc->reg);
> + bool is_scu = (ip == ASPEED_IP_SCU);
> + const char *ip_name = aspeed_pinmux_ips[ip];
> +
> u32 pattern = enable ? desc->enable : desc->disable;
> + u32 val = (pattern << __ffs(desc->mask));
>
> /*
> * Strap registers are configured in hardware or by early-boot
> @@ -179,11 +202,27 @@ static bool aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
> * deconfigured and is the reason we re-evaluate after writing
> * all descriptor bits.
> */
> - if (desc->reg == HW_STRAP1 || desc->reg == HW_STRAP2)
> + if (is_scu && (offset == HW_STRAP1 || offset == HW_STRAP2))
> continue;
>
> - ret = regmap_update_bits(map, desc->reg, desc->mask,
> - pattern << __ffs(desc->mask)) == 0;
> + /*
> + * Sometimes we need help from IP outside the SCU to activate a
> + * mux request. Report that we need its cooperation.
> + */
> + if (enable && !is_scu) {
> + pr_debug("Pinmux request for %s requires cooperation of %s IP: Need (%s%X[0x%08X] = 0x%08X\n",
> + expr->function, ip_name, ip_name, offset,
> + desc->mask, val);
> + }
> +
> + /* And only read/write SCU registers */
> + if (!is_scu) {
> + pr_debug("Skipping configuration of field %s%X[0x%08X]\n",
> + ip_name, offset, desc->mask);
> + continue;
> + }
> +
> + ret = regmap_update_bits(map, desc->reg, desc->mask, val) == 0;
>
> if (!ret)
> return ret;
> @@ -343,6 +382,8 @@ int aspeed_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned int function,
> const struct aspeed_sig_expr **funcs;
> const struct aspeed_sig_expr ***prios;
>
> + pr_debug("Muxing pin %d for %s\n", pin, pfunc->name);
> +
> if (!pdesc)
> return -EINVAL;
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.h b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> index 3e72ef8c54bf..4384407d77fb 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> @@ -232,6 +232,15 @@
> * group.
> */
>
> +#define ASPEED_IP_SCU 0
> +#define ASPEED_IP_SIO 1
> +#define ASPEED_IP_GFX 2
> +#define ASPEED_IP_LPC 3
> +
> +#define SIG_DESC_TO_REG(ip, offset) (((ip) << 24) | (offset))
> +#define SIG_DESC_IP_FROM_REG(reg) (((reg) >> 24) & GENMASK(7, 0))
> +#define SIG_DESC_OFFSET_FROM_REG(reg) ((reg) & GENMASK(11, 0))
> +
> /*
> * The "Multi-function Pins Mapping and Control" table in the SoC datasheet
> * references registers by the device/offset mnemonic. The register macros
> @@ -261,7 +270,10 @@
> * A signal descriptor, which describes the register, bits and the
> * enable/disable values that should be compared or written.
> *
> - * @reg: The register offset from base in bytes
> + * @reg: Split into three fields:
> + * 31:24: IP selector
> + * 23:12: Reserved
> + * 11:0: Register offset
> * @mask: The mask to apply to the register. The lowest set bit of the mask is
> * used to derive the shift value.
> * @enable: The value that enables the function. Value should be in the LSBs,
> @@ -270,7 +282,7 @@
> * LSBs, not at the position of the mask.
> */
> struct aspeed_sig_desc {
> - unsigned int reg;
> + u32 reg;
> u32 mask;
> u32 enable;
> u32 disable;
> --
> git-series 0.8.10
^ permalink raw reply
* [PATCH RFC 6/8] ARM: dts: r8a7743: add SYS-DMAC support
From: Geert Uytterhoeven @ 2016-09-29 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be7575a5-e9a0-05a6-5b2d-803632c7edac@cogentembedded.com>
Hi Sergei,
On Wed, Sep 28, 2016 at 10:09 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 09/19/2016 11:19 AM, Geert Uytterhoeven wrote:
>>> --- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
>>> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
>>> @@ -90,6 +90,70 @@
>>> #power-domain-cells = <1>;
>>> };
>>>
>>> + dmac0: dma-controller at e6700000 {
>>> + compatible = "renesas,dmac-r8a7743",
>>
>>
>> To be documented.
>
> The R-Car DMAC binding has "renesas,dmac-<soctype>" documented.
> I can add the mention of RZ/G and new examples though...
Just adding a line for RZ/G1M should be sufficient. Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Greg Kroah-Hartman @ 2016-09-29 6:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160928154735.25265-1-nicolas.ferre@atmel.com>
On Wed, Sep 28, 2016 at 05:47:35PM +0200, Nicolas Ferre wrote:
> Change maintainer for the serial driver found on most of the
> Microchip / Atmel MPUs and take advantage of the move to rename
> and reorder the entry.
> I'm happy that Richard is taking over the maintenance of this
> driver.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Acked-by: Richard Genoud <richard.genoud@gmail.com>
> ---
> MAINTAINERS | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
This doesn't apply to my tty-next tree at all, what did you make it
against?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] MAINTAINERS: update entry for atmel_serial driver
From: Richard Genoud @ 2016-09-29 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475078653.2685.1.camel@perches.com>
2016-09-28 18:04 GMT+02:00 Joe Perches <joe@perches.com>:
> On Wed, 2016-09-28 at 17:47 +0200, Nicolas Ferre wrote:
>> Change maintainer for the serial driver found on most of the
>> Microchip / Atmel MPUs and take advantage of the move to rename
>> and reorder the entry.
> []
>> diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> +MICROCHIP / ATMEL AT91 / AT32 SERIAL DRIVER
>> +M: Richard Genoud <richard.genoud@gmail.com>
>> +S: Maintained
>> +F: drivers/tty/serial/atmel_serial.c
>> +F: include/linux/atmel_serial.h
>
> Thanks Richard.
>
> include/linux is pretty cluttered with random files.
>
> atmel_serial.h is #include exactly once.
>
> Please move it out of include/linux and into
> drivers/tty/serial/ one day.
No problem, I'll add that to my TBD list !
Richard.
^ permalink raw reply
* [PATCH 0/3] [v2] Add basic ACPI support to the Qualcomm Technologies EMAC driver
From: David Miller @ 2016-09-29 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475081924-12362-1-git-send-email-timur@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Wed, 28 Sep 2016 11:58:41 -0500
> This patch series adds support to the EMAC driver for extracting addresses,
> interrupts, and some _DSDs (properties) from ACPI. The first two patches
> clean up the code, and the third patch adds ACPI-specific functionality.
>
> The first patch fixes a bug with handling the platform_device for the
> internal PHY. This phy is treated as a separate device in both DT and
> ACPI, but since the platform is not released automatically when the
> driver unloads, managed functions like devm_ioremap_resource cannot be
> used.
>
> The second patch replaces of_get_mac_address with its platform-independent
> equivalent device_get_mac_address.
>
> The third patch parses the ACPI tables to obtain the platform_device for
> the primary EMAC node ("QCOM8070") and the internal phy node ("QCOM8071").
Series applied, thanks.
^ permalink raw reply
* [PATCH 2/2] drm/mediatek: clear IRQ status before enable OVL interrupt
From: CK Hu @ 2016-09-29 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475119789-64619-3-git-send-email-bibby.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
On Thu, 2016-09-29 at 11:29 +0800, Bibby Hsieh wrote:
> To make sure that the first vblank IRQ after enabling
> vblank isn't too short or immediate, we have to clear
> the IRQ status before enable OVL interrupt.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 019b7ca..f75c5b5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -80,6 +80,7 @@ static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
> ddp_comp);
>
> priv->crtc = crtc;
> + writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
> writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
> }
>
^ permalink raw reply
* [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts
From: Stefan Wahren @ 2016-09-29 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d93a0590-1783-b913-9362-007628cb17d6@tronnes.org>
> Noralf Tr?nnes <noralf@tronnes.org> hat am 29. September 2016 um 00:22
> geschrieben:
>
>
>
> Den 29.09.2016 00:00, skrev Eric Anholt:
> > Noralf Tr?nnes <noralf@tronnes.org> writes:
> >
> >> If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0),
> >> the driver has no way to fill/drain the FIFO to stop the interrupts.
> >> In this case the controller has to be disabled and the transfer
> >> completed to avoid hang.
> >>
> >> (CLKT | ERR) and DONE interrupts are completed in their own paths, and
> >> the controller is disabled in the transfer function after completion.
> >> Unite the code paths and do disabling inside the interrupt routine.
> >>
> >> Clear interrupt status bits in the united completion path instead of
> >> trying to do it on every interrupt which isn't necessary.
> >> Only CLKT, ERR and DONE can be cleared that way.
> >>
> >> Add the status value to the error value in case of TXW/RXR errors to
> >> distinguish them from the other S_LEN error.
> > I was surprised that not writing the TXW/RXR bits on handling their
> > interrupts was OK, given that we were doing so before, but it's a level
> > interrupt and those bits are basically ignored on write.
> >
> > This patch and 3, 4, and 6 are:
> >
> > Reviewed-by: Eric Anholt <eric@anholt.net>
> >
> > Patch 5 is:
> >
> > Acked-by: Eric Anholt <eric@anholt.net>
> >
> > Note for future debug: The I2C_C_CLEAR on errors will take some time to
> > resolve -- if you were in non-idle state and I2C_C_READ, it sets an
> > abort_rx flag and runs through the state machine to send a NACK and a
> > STOP, I think. Since we're setting CLEAR without I2CEN, that NACK will
> > be hanging around queued up for next time we start the engine.
>
> Maybe you're able to explain the issues I had with reset:
> https://github.com/raspberrypi/linux/issues/1653
>
> Should we put your note into the commit message?
> It will most likely be lost if it just stays in this email.
I prefer to have this kind of information as a code comment.
>
> Noralf.
>
>
> _______________________________________________
> 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 1/2] drm/mediatek: set vblank_disable_allowed to true
From: CK Hu @ 2016-09-29 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475119789-64619-2-git-send-email-bibby.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
On Thu, 2016-09-29 at 11:29 +0800, Bibby Hsieh wrote:
> MTK DRM driver didn't set the vblank_disable_allowed to
> true, it cause that the irq_handler is called every
> 16.6 ms (every vblank) when the display didn't be updated.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index eebb7d8..941ec5f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -200,6 +200,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> if (ret < 0)
> goto err_component_unbind;
>
> + drm->vblank_disable_allowed = true;
> drm_kms_helper_poll_init(drm);
> drm_mode_config_reset(drm);
>
^ permalink raw reply
* [PATCH v19 05/12] fpga-mgr: add fpga image information struct
From: Alan Tull @ 2016-09-29 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAtXAHcdSsVUE4hQ6isCp7_35ZKb60EAKAgtGwBR41apwPpe=g@mail.gmail.com>
On Wed, Sep 28, 2016 at 6:41 PM, Moritz Fischer
<moritz.fischer@ettus.com> wrote:
Hi Moritz,
> Hi Alan,
>
> generally ok with the change.
Cool!
>
> On Wed, Sep 28, 2016 at 11:21 AM, Alan Tull <atull@opensource.altera.com> wrote:
>
>> -int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
>> - size_t count)
>> +int fpga_mgr_buf_load(struct fpga_manager *mgr, struct fpga_image_info *info,
>> + const char *buf, size_t count)
>
> Doesn't this break the both socfpga and zynq if [6/12] and [7/12] are
> not part of this commit?
> i.e shouldn't 5,6 and 7 be a single commit?
Yeah, squashing those would improve bisectability.
Alan
aka atull
>
> Cheers,
> Moritz
^ 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