* [PATCH resend] arm64: dts: r8a7796: salvator-x: Update memory node to 4 GiB map
From: Geert Uytterhoeven @ 2016-12-15 15:31 UTC (permalink / raw)
To: linux-arm-kernel
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
This patch updates memory region:
- After changes, the new map of the Salvator-X board on R8A7796 SoC
Bank0: 2GiB RAM : 0x000048000000 -> 0x000bfffffff
Bank1: 2GiB RAM : 0x000600000000 -> 0x0067fffffff
- Before changes, the old map looked like this:
Bank0: 2GiB RAM : 0x000048000000 -> 0x000bfffffff
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Correct size of old map]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Simon, please apply!
U-Boot already adds the second memory region to the "reg" property of
the first memory node in DT, so this patch is actually a no-op.
IMHO it doesn't make much sense to keep on pretending we don't have
enabled memory outside the 32-bit address space.
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index f35e96ca7d6050b7..38bde9de3250ecbb 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -31,6 +31,11 @@
reg = <0x0 0x48000000 0x0 0x78000000>;
};
+ memory at 600000000 {
+ device_type = "memory";
+ reg = <0x6 0x00000000 0x0 0x80000000>;
+ };
+
reg_1p8v: regulator0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ARM: hyp-stub: improve ABI
From: Marc Zyngier @ 2016-12-15 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215151548.GL14217@n2100.armlinux.org.uk>
On 15/12/16 15:15, Russell King - ARM Linux wrote:
> On Thu, Dec 15, 2016 at 11:46:41AM +0000, Marc Zyngier wrote:
>> On 15/12/16 11:35, Russell King - ARM Linux wrote:
>>> On Thu, Dec 15, 2016 at 11:18:48AM +0000, Marc Zyngier wrote:
>>>> On 14/12/16 10:46, Russell King wrote:
>>>>> @@ -231,10 +244,14 @@ ENDPROC(__hyp_stub_do_trap)
>>>>> * initialisation entry point.
>>>>> */
>>>>> ENTRY(__hyp_get_vectors)
>>>>> - mov r0, #-1
>>>>> + mov r0, #HVC_GET_VECTORS
>>>>
>>>> This breaks the KVM implementation of __hyp_get_vectors, easily fixed
>>>> with the following patchlet:
>>>
>>> Right, so what Mark said is wrong:
>>>
>>> "The hyp-stub is part of the kernel image, and the API is private to
>>> that particular image, so we can change things -- there's no ABI to
>>> worry about."
>>
>> I think Mark is right. The API *is* private to the kernel, and KVM being
>> the only in-kernel hypervisor on ARM, this is not an ABI.
>
> Again, that's wrong.
>
> We have two hypervisors in the kernel. One is KVM, the other is the
> stub. Sure, the stub isn't a full implementation of a hypervisor, but
> it is nevertheless, for the purposes of _this_ discussion, a hypervisor
> of sorts.
>
> The reason that both are included is because they both appear to share
> a common interface (although that's totally not documented anywhere.)
And this interface exists for the sole purpose of enabling KVM. Call it
a hypervisor if you wish, but its usefulness is doubtful on its own.
>>> So no, I'm going with my original patch (which TI has tested) which is
>>> the minimal change, and if we _then_ want to rework the HYP mode
>>> interfaces, that's the time to do the other changes when more people
>>> (such as KVM folk) are paying attention and we can come to a cross-
>>> hypervisor agreement on what the interface should be.
>>
>> Given that there is a single in-kernel hypervisor, I can't really see
>> who we're going to agree anything with...
>
> As far as I can see, the hyp-stub falls under ARM arch maintanence.
> KVM falls under KVM people. Two different groups, we need agreement
> between them what a sane API for both "hypervisors" should be.
Well, I though we had the right level of discussion by reviewing your
patches and coming up with improvements. If you're after something else,
please let me know.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA
From: Robert Richter @ 2016-12-15 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481706707-6211-3-git-send-email-ard.biesheuvel@linaro.org>
I was going to do some measurements but my kernel crashes now with a
page fault in efi_rtc_probe():
[ 21.663393] Unable to handle kernel paging request at virtual address 20251000
[ 21.663396] pgd = ffff000009090000
[ 21.663401] [20251000] *pgd=0000010ffff90003
[ 21.663402] , *pud=0000010ffff90003
[ 21.663404] , *pmd=0000000fdc030003
[ 21.663405] , *pte=00e8832000250707
The sparsemem config requires the whole section to be initialized.
Your patches do not address this.
On 14.12.16 09:11:47, Ard Biesheuvel wrote:
> +config HOLES_IN_ZONE
> + def_bool y
> + depends on NUMA
This enables pfn_valid_within() for arm64 and causes the check for
each page of a section. The arm64 implementation of pfn_valid() is
already expensive (traversing memblock areas). Now, this is increased
by a factor of 2^18 for 4k page size (16384 for 64k). We need to
initialize the whole section to avoid that.
-Robert
[ 21.663393] Unable to handle kernel paging request at virtual address 20251000
[ 21.663396] pgd = ffff000009090000
[ 21.663401] [20251000] *pgd=0000010ffff90003
[ 21.663402] , *pud=0000010ffff90003
[ 21.663404] , *pmd=0000000fdc030003
[ 21.663405] , *pte=00e8832000250707
[ 21.663405]
[ 21.663411] Internal error: Oops: 96000047 [#1] SMP
[ 21.663416] Modules linked in:
[ 21.663425] CPU: 49 PID: 1 Comm: swapper/0 Tainted: G W 4.9.0.0.vanilla10-00002-g429605e9ab0a #1
[ 21.663426] Hardware name: www.cavium.com ThunderX CRB-2S/ThunderX CRB-2S, BIOS 0.3 Sep 13 2016
[ 21.663429] task: ffff800feee6bc00 task.stack: ffff800fec050000
[ 21.663433] PC is at 0x201ff820
[ 21.663434] LR is at 0x201fdfc0
[ 21.663435] pc : [<00000000201ff820>] lr : [<00000000201fdfc0>] pstate: 20000045
[ 21.663437] sp : ffff800fec053b70
[ 21.663440] x29: ffff800fec053bc0 x28: 0000000000000000
[ 21.663443] x27: ffff000008ce3e08 x26: ffff000008c52568
[ 21.663445] x25: ffff000008bf045c x24: ffff000008bdb828
[ 21.663448] x23: 0000000000000000 x22: 0000000000000040
[ 21.663451] x21: ffff800fec053bb8 x20: 0000000020251000
[ 21.663453] x19: ffff800fec053c20 x18: 0000000000000000
[ 21.663456] x17: 0000000000000000 x16: 00000000bbb67a65
[ 21.663459] x15: ffffffffffffffff x14: ffff810016ea291c
[ 21.663461] x13: ffff810016ea2181 x12: 0000000000000030
[ 21.663464] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[ 21.663467] x9 : feff716475687163 x8 : ffffffffffffffff
[ 21.663469] x7 : 83f0680000000000 x6 : 0000000000000000
[ 21.663472] x5 : ffff800fc187aab9 x4 : 0002000000000000
[ 21.663474] x3 : ffff800fec053bb8 x2 : 0000000000000000
[ 21.663477] x1 : 83f0680000000000 x0 : 0000000020251000
[ 21.663478]
[ 21.663479] Process swapper/0 (pid: 1, stack limit = 0xffff800fec050020)
...
[ 21.663605] [<00000000201ff820>] 0x201ff820
[ 21.663617] [<ffff000008c3eef4>] efi_rtc_probe+0x24/0x78
[ 21.663625] [<ffff000008586c88>] platform_drv_probe+0x60/0xc8
[ 21.663636] [<ffff0000085845d4>] driver_probe_device+0x26c/0x420
[ 21.663639] [<ffff0000085848ac>] __driver_attach+0x124/0x128
[ 21.663642] [<ffff000008581e08>] bus_for_each_dev+0x70/0xb0
[ 21.663644] [<ffff000008583c30>] driver_attach+0x30/0x40
[ 21.663647] [<ffff000008583668>] bus_add_driver+0x200/0x2b8
[ 21.663650] [<ffff000008585430>] driver_register+0x68/0x100
[ 21.663652] [<ffff000008586e3c>] __platform_driver_probe+0x84/0x128
[ 21.663654] [<ffff000008c3eec8>] efi_rtc_driver_init+0x20/0x28
[ 21.663658] [<ffff000008082d94>] do_one_initcall+0x44/0x138
[ 21.663665] [<ffff000008bf0d0c>] kernel_init_freeable+0x1ac/0x24c
[ 21.663673] [<ffff00000885e7a0>] kernel_init+0x18/0x110
[ 21.663675] [<ffff000008082b30>] ret_from_fork+0x10/0x20
[ 21.663679] Code: f9400000 d5033d9f d65f03c0 d5033e9f (f9000001)
[ 21.663688] ---[ end trace e420ef9636e3c9b2 ]---
[ 21.663711] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 21.663711]
[ 21.663713] SMP: stopping secondary CPUs
[ 21.670234] Kernel Offset: disabled
[ 21.670235] Memory Limit: none
[ 22.681333] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
^ permalink raw reply
* [PATCH v2] i2c: designware: add reset interface
From: Jarkko Nikula @ 2016-12-15 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <66e86b18-c6d5-4290-5e93-dcae50596da6@electromag.com.au>
On 12/15/2016 04:11 PM, Phil Reid wrote:
> On 15/12/2016 20:33, Andy Shevchenko wrote:
>> On Thu, 2016-12-15 at 16:59 +0800, Zhangfei Gao wrote:
>>> Some platforms like hi3660 need do reset first to allow accessing
>>> registers
>>
>> Patch itself looks good, but would be nice to have it tested.
>>
>> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>>
>>>
>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>>> ---
>>> drivers/i2c/busses/i2c-designware-core.h | 1 +
>>> drivers/i2c/busses/i2c-designware-platdrv.c | 28
>>> ++++++++++++++++++++++++----
>>> 2 files changed, 25 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-designware-core.h
>>> b/drivers/i2c/busses/i2c-designware-core.h
>>> index 0d44d2a..94b14fa 100644
>>> --- a/drivers/i2c/busses/i2c-designware-core.h
>>> +++ b/drivers/i2c/busses/i2c-designware-core.h
>>> @@ -80,6 +80,7 @@ struct dw_i2c_dev {
>>> void __iomem *base;
>>> struct completion cmd_complete;
>>> struct clk *clk;
>>> + struct reset_control *rst;
>>> u32 (*get_clk_rate_khz) (struct
>>> dw_i2c_dev *dev);
>>> struct dw_pci_controller *controller;
>>> int cmd_err;
>>> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
>>> b/drivers/i2c/busses/i2c-designware-platdrv.c
>>> index 0b42a12..e9016ae 100644
>>> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
>>> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
>>> @@ -38,6 +38,7 @@
>>> #include <linux/pm_runtime.h>
>>> #include <linux/property.h>
>>> #include <linux/io.h>
>>> +#include <linux/reset.h>
>>> #include <linux/slab.h>
>>> #include <linux/acpi.h>
>>> #include <linux/platform_data/i2c-designware.h>
>>> @@ -176,6 +177,14 @@ static int dw_i2c_plat_probe(struct
>>> platform_device *pdev)
>>> dev->irq = irq;
>>> platform_set_drvdata(pdev, dev);
>>>
>>> + dev->rst = devm_reset_control_get_optional(&pdev->dev, NULL);
>>> + if (IS_ERR(dev->rst)) {
>>> + if (PTR_ERR(dev->rst) == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>> + } else {
>>> + reset_control_deassert(dev->rst);
>>> + }
>>> +
> More for my education. But some drivers seem to handle the error codes a
> little more explicitly.
> Whats the best approach?
>
> eg: From usb/dwc2 driver it continues only if ENOENT / ENOTSUPP errors
> are return
> and ENOMEM / EINVAL etc is a fatal error.
>
> hsotg->reset = devm_reset_control_get_optional(hsotg->dev, "dwc2");
> if (IS_ERR(hsotg->reset)) {
> ret = PTR_ERR(hsotg->reset);
> switch (ret) {
> case -ENOENT:
> case -ENOTSUPP:
> hsotg->reset = NULL;
> break;
> default:
> dev_err(hsotg->dev, "error getting reset control %d\n",
> ret);
> return ret;
> }
This looks a bit extreme. At least we shouldn't spam log on machines
that don't need reset control. I kind of think it's good enough to do
like the patch does. I.e. handle only EPROBE_DEFER and let all other
errors fall through and keep the controller in reset and let the
dev->rst carry an error code.
I guess EINVAL is likely seen by developer only. ENOMEM is so fatal that
things are already falling apart somewhere else too and I don't think it
needs special handling here.
--
Jarkko
^ permalink raw reply
* [PATCH 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Jose Abreu @ 2016-12-15 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481814682-31780-2-git-send-email-appanad@xilinx.com>
Hi Kedar,
On 15-12-2016 15:11, Kedareswara rao Appana wrote:
> Add channel idle state to ensure that dma descriptor is not
> submitted when VDMA engine is in progress.
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 8288fe4..736c2a3 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -321,6 +321,7 @@ struct xilinx_dma_tx_descriptor {
> * @cyclic: Check for cyclic transfers.
> * @genlock: Support genlock mode
> * @err: Channel has errors
> + * @idle: Check for channel idle
> * @tasklet: Cleanup work after irq
> * @config: Device configuration info
> * @flush_on_fsync: Flush on Frame sync
> @@ -351,6 +352,7 @@ struct xilinx_dma_chan {
> bool cyclic;
> bool genlock;
> bool err;
> + bool idle;
> struct tasklet_struct tasklet;
> struct xilinx_vdma_config config;
> bool flush_on_fsync;
> @@ -966,6 +968,7 @@ static void xilinx_dma_halt(struct xilinx_dma_chan *chan)
> chan, dma_ctrl_read(chan, XILINX_DMA_REG_DMASR));
> chan->err = true;
> }
> + chan->idle = true;
> }
>
> /**
> @@ -1007,6 +1010,9 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
> if (chan->err)
> return;
>
> + if (!chan->idle)
> + return;
> +
> if (list_empty(&chan->pending_list))
> return;
>
> @@ -1110,6 +1116,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
> vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);
> }
>
> + chan->idle = false;
> if (!chan->has_sg) {
> list_del(&desc->node);
> list_add_tail(&desc->node, &chan->active_list);
> @@ -1447,6 +1454,7 @@ static irqreturn_t xilinx_dma_irq_handler(int irq, void *data)
> if (status & XILINX_DMA_DMASR_FRM_CNT_IRQ) {
> spin_lock(&chan->lock);
> xilinx_dma_complete_descriptor(chan);
> + chan->idle = true;
> chan->start_transfer(chan);
> spin_unlock(&chan->lock);
> }
> @@ -2327,6 +2335,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->has_sg = xdev->has_sg;
> chan->desc_pendingcount = 0x0;
> chan->ext_addr = xdev->ext_addr;
> + chan->idle = true;
>
> spin_lock_init(&chan->lock);
> INIT_LIST_HEAD(&chan->pending_list);
I think there is missing a set to true in idle when a channel
reset is performed.
Otherwise: Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Best regards,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH] arm64: mm: Fix NOMAP page initialization
From: Robert Richter @ 2016-12-15 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4bc9df75-1b67-2428-184e-ce52b5f95528@huawei.com>
On 15.12.16 11:01:04, Yisheng Xie wrote:
> > I sent a V2 patch that uses pfn_present(). This only initilizes
> > sections with memory.
> hmm? maybe I do not quite catch what your mean, but I do not think
> pfn_present is right for this case.
>
> IMO, The valid_section() means the section with mem_map, not section with memory.
Right, the section may be uninitialized with the present flag only.
valid_section() is better, this is also the pfn_valid() default
implementation.
Will rework. Thanks.
-Robert
^ permalink raw reply
* [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA
From: Ard Biesheuvel @ 2016-12-15 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161215153930.GA8111@rric.localdomain>
On 15 December 2016 at 15:39, Robert Richter <robert.richter@cavium.com> wrote:
> I was going to do some measurements but my kernel crashes now with a
> page fault in efi_rtc_probe():
>
> [ 21.663393] Unable to handle kernel paging request at virtual address 20251000
> [ 21.663396] pgd = ffff000009090000
> [ 21.663401] [20251000] *pgd=0000010ffff90003
> [ 21.663402] , *pud=0000010ffff90003
> [ 21.663404] , *pmd=0000000fdc030003
> [ 21.663405] , *pte=00e8832000250707
>
> The sparsemem config requires the whole section to be initialized.
> Your patches do not address this.
>
96000047 is a third level translation fault, and the PTE address has
RES0 bits set. I don't see how this is related to sparsemem, could you
explain?
> On 14.12.16 09:11:47, Ard Biesheuvel wrote:
>> +config HOLES_IN_ZONE
>> + def_bool y
>> + depends on NUMA
>
> This enables pfn_valid_within() for arm64 and causes the check for
> each page of a section. The arm64 implementation of pfn_valid() is
> already expensive (traversing memblock areas). Now, this is increased
> by a factor of 2^18 for 4k page size (16384 for 64k). We need to
> initialize the whole section to avoid that.
>
I know that. But if you want something for -stable, we should have
something that is correct first, and only then care about the
performance hit (if there is one)
^ permalink raw reply
* [PATCH 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Jose Abreu @ 2016-12-15 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481814682-31780-3-git-send-email-appanad@xilinx.com>
Hi Kedar,
On 15-12-2016 15:11, Kedareswara rao Appana wrote:
> When VDMA is configured for more than one frame in the h/w
> for example h/w is configured for n number of frames and user
> Submits n number of frames and triggered the DMA using issue_pending API.
> In the current driver flow we are submitting one frame at a time
> but we should submit all the n number of frames at one time as the h/w
> Is configured for n number of frames.
>
> This patch fixes this issue.
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 43 +++++++++++++++++++++++++----------------
> 1 file changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 736c2a3..4f3fa94 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1087,23 +1087,33 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
> tail_segment->phys);
> } else {
> struct xilinx_vdma_tx_segment *segment, *last = NULL;
> - int i = 0;
> + int i = 0, j = 0;
>
> if (chan->desc_submitcount < chan->num_frms)
> i = chan->desc_submitcount;
>
> - list_for_each_entry(segment, &desc->segments, node) {
> - if (chan->ext_addr)
> - vdma_desc_write_64(chan,
> - XILINX_VDMA_REG_START_ADDRESS_64(i++),
> - segment->hw.buf_addr,
> - segment->hw.buf_addr_msb);
> - else
> - vdma_desc_write(chan,
> - XILINX_VDMA_REG_START_ADDRESS(i++),
> - segment->hw.buf_addr);
> -
> - last = segment;
> + for (j = 0; j < chan->num_frms; ) {
> + list_for_each_entry(segment, &desc->segments, node) {
> + if (chan->ext_addr)
> + vdma_desc_write_64(chan,
> + XILINX_VDMA_REG_START_ADDRESS_64(i++),
> + segment->hw.buf_addr,
> + segment->hw.buf_addr_msb);
> + else
> + vdma_desc_write(chan,
> + XILINX_VDMA_REG_START_ADDRESS(i++),
> + segment->hw.buf_addr);
> +
> + last = segment;
Hmm, is it possible to submit more than one segment? If so, then
i and j will get out of sync.
> + }
> + list_del(&desc->node);
> + list_add_tail(&desc->node, &chan->active_list);
> + j++;
But if i is non zero and pending_list has more than num_frms then
i will not wrap-around as it should and will write to invalid
framebuffer location, right?
> + if (list_empty(&chan->pending_list))
> + break;
> + desc = list_first_entry(&chan->pending_list,
> + struct xilinx_dma_tx_descriptor,
> + node);
> }
>
> if (!last)
> @@ -1114,14 +1124,13 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
> vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
> last->hw.stride);
> vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);
Maybe a check that all framebuffers contain valid addresses
should be done before programming vsize so that VDMA does not try
to write to invalid addresses.
> +
> + chan->desc_submitcount += j;
> + chan->desc_pendingcount -= j;
> }
>
> chan->idle = false;
> if (!chan->has_sg) {
> - list_del(&desc->node);
> - list_add_tail(&desc->node, &chan->active_list);
> - chan->desc_submitcount++;
> - chan->desc_pendingcount--;
> if (chan->desc_submitcount == chan->num_frms)
> chan->desc_submitcount = 0;
"desc_submitcount >= chan->num_frms would be safer here.
> } else {
Best regards,
Jose Miguel Abreu
^ permalink raw reply
* arm64: mm: bug around swiotlb_dma_ops
From: Nikita Yushchenko @ 2016-12-15 16:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi.
Per Documentation/DMA-API-HOWTO.txt, driver of device capable of 64-bit
DMA addressing, should call dma_set_mask_and_coherent(dev,
DMA_BIT_MASK(64)) and if that succeeds, assume that 64-bit DMA
addressing is available.
This behaves incorrectly on arm64 system (Renesas r8a7795-h3ulcb) here.
- Device (NVME SSD) has it's dev->archdata.dma_ops set to swiotlb_dma_ops.
- swiotlb_dma_ops.dma_supported is set to swiotlb_dma_supported():
int swiotlb_dma_supported(struct device *hwdev, u64 mask)
{
return phys_to_dma(hwdev, io_tlb_end - 1) <= mask;
}
this definitely returns true for mask=DMA_BIT_MASK(64) since that is
maximum possible 64-bit value.
- Thus device dma_mask is unconditionally updated, and
dma_set_mask_and_coherent() succeeds.
- Later, __swiotlb_map_page() / __swiotlb_map_sg_attr() will consult
this updated mask, and return high addresses as valid DMA addresses.
Thus recommended dma_set_mask_and_coherent() call, instead of checking
if platform supports 64-bit DMA addressing, unconditionally enables
64-bit DMA addressing. In case of device actually can't do DMA to 64-bit
addresses (e.g. because of limitations in PCIe controller), this breaks
things. This is exactly what happens here.
Not sure what is proper fix for this though.
Nikita
^ permalink raw reply
* [PATCH v2 0/2] arm64: dts: r8a7796: salvator-x: Enable EthernetAVB
From: Geert Uytterhoeven @ 2016-12-15 16:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
This patch series enables networking on r8a7796/salvator-x.
Network performance is currently limited to 100 Mbps by the ravb driver.
Performance figures with nuttcp are ca. 94 Mbps for both receive and
transmit, at 12% vs. 4% CPU load. For receive, this is comparable to
sh_eth on Koelsch; for transmit, it's ca. 20% faster.
With "ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W" applied,
network throughput is higher, but has a high variance:
- receive: 245-426 Mbps, at 100% CPU load (ksoftirqd + nuttcp),
- transmit: 426 Mbps, at 95% CPU load (nuttcp).
When limiting memory to 1 GiB, and thus avoiding swiotlb bounce buffers,
network throughput increases (CPU load is similar though) to 546 resp.
625 Mbps.
The 50% performance penalty of swiotlb is expected to be mitigated when
IOMMU support will become available.
Note that at high receive speeds, the driver sometimes prints:
ravb e6800000.ethernet eth0: Receive Descriptor Empty
This may even cause nuttcp to fail with:
nuttcp-t: v6.1.2: Error: server not ACKing data
NFS root survives fine, though.
I'm wondering if this is also seen on the R-Car Gen2 boards where
EthernetAVB is available?
Changes compared to v1, as sent by Laurent before:
- Add pinctrl. Drive strength is not yet included, like on current
r8a7795/salvator-x.
This series is based on renesas-devel-20161212-v4.9. To actually work,
you need to merge my sh-pfc-for-v4.10 branch, which is upstream and will
be in v4.10-rc1. As this is a pure runtime dependency, and does not
imply a regression, this series can be applied now.
Thanks for applying!
Laurent Pinchart (2):
arm64: dts: renesas: r8a7796: Add EthernetAVB instance
arm64: dts: r8a7796: salvator-x: Enable EthernetAVB
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 32 ++++++++++++++++
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 43 ++++++++++++++++++++++
2 files changed, 75 insertions(+)
--
1.9.1
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 v2 1/2] arm64: dts: r8a7796: Add EthernetAVB instance
From: Geert Uytterhoeven @ 2016-12-15 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481819044-19605-1-git-send-email-geert+renesas@glider.be>
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Rebased.
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 43 ++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 7bf0f2f6c2243cfc..d9d8dc53b408c36e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -421,6 +421,49 @@
};
};
+ avb: ethernet at e6800000 {
+ compatible = "renesas,etheravb-r8a7796",
+ "renesas,etheravb-rcar-gen3";
+ reg = <0 0xe6800000 0 0x800>, <0 0xe6a00000 0 0x10000>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14", "ch15",
+ "ch16", "ch17", "ch18", "ch19",
+ "ch20", "ch21", "ch22", "ch23",
+ "ch24";
+ clocks = <&cpg CPG_MOD 812>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ phy-mode = "rgmii-id";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
scif2: serial at e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: r8a7796: salvator-x: Enable EthernetAVB
From: Geert Uytterhoeven @ 2016-12-15 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481819044-19605-1-git-send-email-geert+renesas@glider.be>
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
[geert: Add pinctrl]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Add pinctrl.
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index 38bde9de3250ecbb..c7f40f8f3169f36b 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -18,6 +18,7 @@
aliases {
serial0 = &scif2;
+ ethernet0 = &avb;
};
chosen {
@@ -107,6 +108,11 @@
pinctrl-0 = <&scif_clk_pins>;
pinctrl-names = "default";
+ avb_pins: avb {
+ groups = "avb_mdc";
+ function = "avb";
+ };
+
scif2_pins: scif2 {
groups = "scif2_data_a";
function = "scif2";
@@ -158,6 +164,32 @@
};
};
+&avb {
+ pinctrl-0 = <&avb_pins>;
+ pinctrl-names = "default";
+ renesas,no-ether-link;
+ phy-handle = <&phy0>;
+ status = "okay";
+
+ phy0: ethernet-phy at 0 {
+ rxc-skew-ps = <900>;
+ rxdv-skew-ps = <0>;
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ txc-skew-ps = <900>;
+ txen-skew-ps = <0>;
+ txd0-skew-ps = <0>;
+ txd1-skew-ps = <0>;
+ txd2-skew-ps = <0>;
+ txd3-skew-ps = <0>;
+ reg = <0>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
--
1.9.1
^ permalink raw reply related
* [stericsson:ab8500-gpadc 1/1] drivers/hwmon/ab8500.c:20:43: fatal error: linux/mfd/abx500/ab8500-gpadc.h: No such file or directory
From: kbuild test robot @ 2016-12-15 16:31 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git ab8500-gpadc
head: 4e7f2be1ec1f1ebfd4912f7f4575e0bfb233e784
commit: 4e7f2be1ec1f1ebfd4912f7f4575e0bfb233e784 [1/1] AB8500 GPADC IIO
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4e7f2be1ec1f1ebfd4912f7f4575e0bfb233e784
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> drivers/hwmon/ab8500.c:20:43: fatal error: linux/mfd/abx500/ab8500-gpadc.h: No such file or directory
#include <linux/mfd/abx500/ab8500-gpadc.h>
^
compilation terminated.
--
>> drivers/power/supply/ab8500_charger.c:32:43: fatal error: linux/mfd/abx500/ab8500-gpadc.h: No such file or directory
#include <linux/mfd/abx500/ab8500-gpadc.h>
^
compilation terminated.
--
>> drivers/power/supply/ab8500_fg.c:35:43: fatal error: linux/mfd/abx500/ab8500-gpadc.h: No such file or directory
#include <linux/mfd/abx500/ab8500-gpadc.h>
^
compilation terminated.
--
>> drivers/power/supply/ab8500_btemp.c:29:43: fatal error: linux/mfd/abx500/ab8500-gpadc.h: No such file or directory
#include <linux/mfd/abx500/ab8500-gpadc.h>
^
compilation terminated.
vim +20 drivers/hwmon/ab8500.c
0bbb06ed Hongbo Zhang 2013-04-03 4 * Hongbo Zhang <hongbo.zhang@linaro.org>
0bbb06ed Hongbo Zhang 2013-04-03 5 * License Terms: GNU General Public License v2
0bbb06ed Hongbo Zhang 2013-04-03 6 *
0bbb06ed Hongbo Zhang 2013-04-03 7 * When the AB8500 thermal warning temperature is reached (threshold cannot
0bbb06ed Hongbo Zhang 2013-04-03 8 * be changed by SW), an interrupt is set, and if no further action is taken
3afb57fa Guenter Roeck 2014-09-29 9 * within a certain time frame, kernel_power_off will be called.
0bbb06ed Hongbo Zhang 2013-04-03 10 *
0bbb06ed Hongbo Zhang 2013-04-03 11 * When AB8500 thermal shutdown temperature is reached a hardware shutdown of
0bbb06ed Hongbo Zhang 2013-04-03 12 * the AB8500 will occur.
0bbb06ed Hongbo Zhang 2013-04-03 13 */
0bbb06ed Hongbo Zhang 2013-04-03 14
0bbb06ed Hongbo Zhang 2013-04-03 15 #include <linux/err.h>
0bbb06ed Hongbo Zhang 2013-04-03 16 #include <linux/hwmon.h>
0bbb06ed Hongbo Zhang 2013-04-03 17 #include <linux/hwmon-sysfs.h>
0bbb06ed Hongbo Zhang 2013-04-03 18 #include <linux/mfd/abx500.h>
0bbb06ed Hongbo Zhang 2013-04-03 19 #include <linux/mfd/abx500/ab8500-bm.h>
0bbb06ed Hongbo Zhang 2013-04-03 @20 #include <linux/mfd/abx500/ab8500-gpadc.h>
0bbb06ed Hongbo Zhang 2013-04-03 21 #include <linux/module.h>
0bbb06ed Hongbo Zhang 2013-04-03 22 #include <linux/platform_device.h>
0bbb06ed Hongbo Zhang 2013-04-03 23 #include <linux/power/ab8500.h>
3afb57fa Guenter Roeck 2014-09-29 24 #include <linux/reboot.h>
0bbb06ed Hongbo Zhang 2013-04-03 25 #include <linux/slab.h>
0bbb06ed Hongbo Zhang 2013-04-03 26 #include <linux/sysfs.h>
0bbb06ed Hongbo Zhang 2013-04-03 27 #include "abx500.h"
0bbb06ed Hongbo Zhang 2013-04-03 28
:::::: The code at line 20 was first introduced by commit
:::::: 0bbb06ed564d211d10eae12bdb423fce6178468f hwmon: Add ST-Ericsson ABX500 hwmon driver
:::::: TO: Hongbo Zhang <hongbo.zhang@linaro.org>
:::::: CC: Anton Vorontsov <anton@enomsg.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 60059 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161216/315ba469/attachment-0001.gz>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Doug Anderson @ 2016-12-15 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <991221a4-3962-1bcb-7863-72f5553eba40@rock-chips.com>
Hi,
On Wed, Dec 14, 2016 at 10:41 PM, Frank Wang <frank.wang@rock-chips.com> wrote:
> Hi Brain, Doug and Heiko,
>
> I would like to summarize why this story was constructed.
>
> The ehci/ohci-platform suspend process are blocked due to UTMI clock which
> directly output from usb-phy has been disabled, and why the UTMI clock was
> disabled?
>
> UTMI clock and 480m clock all output from the same internal PLL of usb-phy,
> and there is only one bit can use to control this PLL on or off, which we
> named "otg_commononn"(GRF, offset 0x0e450/0x0e460 bit4 ) in RK3399 TRM.
>
> When system boot up, ehci/ohci-platform probe function invoke
> phy_power_on(), further invoke rockchip_usb2phy_power_on() to enable 480m
> clock, actually, it sets the otg_commononn bit on, and then usb-phy will go
> to (auto)suspend if there is no devices plug-in after 1 minute, the
> rockchip_usb2phy_power_off() will be invoked and the 480m clock may be
> disabled in the (auto)suspend process. As a result, the otg_commononn bit
> may be turned off, and all output clock of usb-phy will be disabled.
> However, ehci/ohci-platform PM suspend operation (read/write controller
> register) are based on the UTMI clock.
>
> So we introduced "clk_usbphy0_480m_src"/"clk_usbphy1_480m_src" as one input
> clock for ehci/ohci-platform, in this way, the otg_commononn bit is not
> turned off until ehci/ohci-platform go to PM suspend.
I still need to digest all of the things that were added to this
thread overnight, but nothing I've seen so far indicates that you need
the post-gated clock. AKA I still think you need to redo your patch
to replace:
clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
<&cru SCLK_USBPHY0_480M_SRC>;
with:
clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
<&u2phy0>;
Can you please comment on that?
-Doug
^ permalink raw reply
* [PATCH v11 7/7] arm: pmu: Add PMU definitions for cores not initially online
From: Will Deacon @ 2016-12-15 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <457894f4-67f8-9d32-ee8b-5a34e9a21488@arm.com>
On Tue, Dec 06, 2016 at 11:56:56AM -0600, Jeremy Linton wrote:
> Hi,
>
> On 12/06/2016 09:21 AM, Will Deacon wrote:
> >On Fri, Dec 02, 2016 at 12:56:01PM -0600, Jeremy Linton wrote:
> >>ACPI CPUs aren't associated with a PMU until they have been put
> >>online. This means that we potentially have to update a PMU
> >>definition the first time a CPU is hot added to the machine.
> >>
> >>Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> >>---
> >> drivers/perf/arm_pmu.c | 38 ++++++++++++++++++++++++++++++++++++--
> >> include/linux/perf/arm_pmu.h | 4 ++++
> >> 2 files changed, 40 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> >>index fa40294..4abb2fe 100644
> >>--- a/drivers/perf/arm_pmu.c
> >>+++ b/drivers/perf/arm_pmu.c
> >>@@ -711,6 +711,30 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, irq_handler_t handler)
> >> return 0;
> >> }
> >>
> >>+static DEFINE_SPINLOCK(arm_pmu_resource_lock);
> >
> >Why do you need this spinlock? The hotplug notifiers are serialised afaik,
> >and you don't take it anywhere else.
>
> Well, I assumed they were serialized, but then I went looking for a
> guarantee and couldn't find one specific to the notifiers, even though the
> previous lock was removed.
They should be serialised either by virtue of them all running off the back
of a single CPU (because the hotplug thread hasn't yet been created), or
by the st->done completion for the hotplug work threads.
Will
^ permalink raw reply
* [PATCH 01/37] ARM: dts: imx6dl-aristainetos2: Correct license text
From: Rask Ingemann Lambertsen @ 2016-12-15 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214235746.7108-2-alexandre.belloni@free-electrons.com>
On Thu, Dec 15, 2016 at 12:57:10AM +0100, Alexandre Belloni wrote:
> The license test has been mangled at some point then copy pasted across
s/test/text/
--
Rask Ingemann Lambertsen
^ permalink raw reply
* [PATCH 5/8] linux: drop __bitwise__ everywhere
From: Krzysztof Kozlowski @ 2016-12-15 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481778865-27667-6-git-send-email-mst@redhat.com>
On Thu, Dec 15, 2016 at 07:15:20AM +0200, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
> drivers/md/dm-cache-block-types.h | 6 +++---
> drivers/net/ethernet/sun/sunhme.h | 2 +-
> drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
> include/linux/mmzone.h | 2 +-
> include/linux/serial_core.h | 4 ++--
> include/linux/types.h | 4 ++--
> include/scsi/iscsi_proto.h | 2 +-
> include/target/target_core_base.h | 2 +-
> include/uapi/linux/virtio_types.h | 6 +++---
> net/ieee802154/6lowpan/6lowpan_i.h | 2 +-
> net/mac80211/ieee80211_i.h | 4 ++--
> 12 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/include/plat/gpio-cfg.h b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> index 21391fa..e55d1f5 100644
> --- a/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> +++ b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> @@ -26,7 +26,7 @@
>
> #include <linux/types.h>
>
> -typedef unsigned int __bitwise__ samsung_gpio_pull_t;
> +typedef unsigned int __bitwise samsung_gpio_pull_t;
>
> /* forward declaration if gpio-core.h hasn't been included */
> struct samsung_gpio_chip;
For plat-samsung:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Heiko Stuebner @ 2016-12-15 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=XKQaqRS4jUM7NpN2KEV8USj_cVWbh7q4274n3jBtwORg@mail.gmail.com>
Am Donnerstag, 15. Dezember 2016, 08:34:09 CET schrieb Doug Anderson:
> Hi,
>
> On Wed, Dec 14, 2016 at 10:41 PM, Frank Wang <frank.wang@rock-chips.com>
wrote:
> > Hi Brain, Doug and Heiko,
> >
> > I would like to summarize why this story was constructed.
> >
> > The ehci/ohci-platform suspend process are blocked due to UTMI clock which
> > directly output from usb-phy has been disabled, and why the UTMI clock was
> > disabled?
> >
> > UTMI clock and 480m clock all output from the same internal PLL of
> > usb-phy,
> > and there is only one bit can use to control this PLL on or off, which we
> > named "otg_commononn"(GRF, offset 0x0e450/0x0e460 bit4 ) in RK3399 TRM.
> >
> > When system boot up, ehci/ohci-platform probe function invoke
> > phy_power_on(), further invoke rockchip_usb2phy_power_on() to enable 480m
> > clock, actually, it sets the otg_commononn bit on, and then usb-phy will
> > go
> > to (auto)suspend if there is no devices plug-in after 1 minute, the
> > rockchip_usb2phy_power_off() will be invoked and the 480m clock may be
> > disabled in the (auto)suspend process. As a result, the otg_commononn bit
> > may be turned off, and all output clock of usb-phy will be disabled.
> > However, ehci/ohci-platform PM suspend operation (read/write controller
> > register) are based on the UTMI clock.
> >
> > So we introduced "clk_usbphy0_480m_src"/"clk_usbphy1_480m_src" as one
> > input
> > clock for ehci/ohci-platform, in this way, the otg_commononn bit is not
> > turned off until ehci/ohci-platform go to PM suspend.
>
> I still need to digest all of the things that were added to this
> thread overnight, but nothing I've seen so far indicates that you need
> the post-gated clock. AKA I still think you need to redo your patch
> to replace:
>
> clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
> <&cru SCLK_USBPHY0_480M_SRC>;
>
> with:
>
> clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
> <&u2phy0>;
>
> Can you please comment on that?
Also, with the change, the ehci will keep the clock (and thus the phy) always
on. Does the phy-autosuspend even save anything now?
In any case, could we make the clock-names entry sound nicer than usbphy0_480m
please? bindings/usb/atmel-usb.txt calls its UTMI clock simply "usb_clk", but
something like "utmi" should also work.
While at it you could also fix up the other clock names to something like
"host" and "arbiter" or so?.
Heiko
^ permalink raw reply
* [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Icenowy Zheng @ 2016-12-15 18:27 UTC (permalink / raw)
To: linux-arm-kernel
An operating point table is needed for the cpu frequency adjusting to
work.
The operating point table is converted from the common value in
extracted script.fex from many A33 board/tablets.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Changes since v1:
- Fix format problem (blank lines).
- Removed the 1.344GHz operating point, as it's overvoltage and overclocked.
This patch depends on the following patchset:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473962.html
It's the v2 of the [PATCH 4/6] in this patchset.
I think this operating point table may also apply to A23, as there's no
difference except the points over 1.2GHz between A23 and A33's stock dvfs table.
But as A23 CCU may not have the necessary fixes, I won't add the table to A23
now.
Chen-Yu, could you test the CCU fixes I described in the patchset above on A23,
then test this operating points table?
If it's necessary, you can send out the CCU fixes and add one more patch that
moves this opp-v2 table to sun8i-a23-a33.dtsi .
arch/arm/boot/dts/sun8i-a33.dtsi | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 504996cbee29..0f5b2af72981 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -46,7 +46,42 @@
#include <dt-bindings/dma/sun4i-a10.h>
/ {
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 648000000 {
+ opp-hz = /bits/ 64 <648000000>;
+ opp-microvolt = <1040000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp at 816000000 {
+ opp-hz = /bits/ 64 <816000000>;
+ opp-microvolt = <1100000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp at 1008000000 {
+ opp-hz = /bits/ 64 <1008000000>;
+ opp-microvolt = <1200000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+
+ opp at 1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <1320000>;
+ clock-latency-ns = <244144>; /* 8 32k periods */
+ };
+ };
+
cpus {
+ cpu0: cpu at 0 {
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
+ operating-points-v2 = <&cpu0_opp_table>;
+ };
+
cpu at 2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
--
2.11.0
^ permalink raw reply related
* [RFC PATCH] Memory hotplug support for arm64 platform
From: Andrea Reale @ 2016-12-15 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58523AC5.10800@huawei.com>
Hi Xishi Qiu,
thanks for your comments.
The short anwser to your question is the following. As you hinted,
it is related to the way pfn_valid() is implemented in arm64 when
CONFIG_HAVE_ARCH_PFN_VALID is true (default), i.e., just a check for
the NOMAP flags on the corresponding memblocks.
Since arch_add_memory->__add_pages() expects pfn_valid() to return false
when it is first called, we mark corresponding memory blocks with NOMAP;
however, arch_add_memory->__add_pages()->__add_section()->__add_zone()
expects pfn_valid() to return true when, at the end of its body,
it cycles through pages to call SetPageReserved(). Since blocks are
marked with NOMAP, pages will not be reserved there, henceforth we
need to reserve them after we clear the NOMAP flag inside the body of
arch_add_memory. Having pages reserved at the end of arch_add_memory
is a preconditions for the upcoming onlining of memory blocks (see
memory_block_change_state()).
> It's because that in memmap_init_zone() -> early_pfn_valid(), the new page is still
> invalid, so we need to init it after memblock_clear_nomap()
>
> So why not use __init_single_page() and set_pageblock_migratetype()?
About your comment on memmap_init_zone()->early_pfn_valid(), I think
that that particular check is never executed in the context of memory
hotplug; in fact, just before the call to early_pfn_valid(), the code
will jump to the `not_early` label, because the context == MEMMAP_HOPTLUG.
Now, the question would be: why there's no need for this hack in
implementation for memory hotplug for other architectures (e.g.,
x86)? The answer we have found lies in the following: as said above,
when CONFIG_HAVE_ARCH_PFN_VALID is true (default), the implementation
of pfn_valid for arm64 just checks the NOMAP flag on the memmblocks,
and returns true if corresponding memblock_add_node() has succeeded (it
seems it does not consider the sparse memory model structures created
by arm64_memory_present() and sparse_init()).
On the contrary, the implementation of pfn_valid() for other
architectures is defined in include/linux/mmzone.h. This
implemenation, among other things, checks for the
SECTION_HAS_MEM_MAP flag on section->section_mem_map. Now,
when we go to memory hotplug, this flag is actually set inside
__add_section()->sparse_add_one_section()->sparse_init_one_section(). This
happens before the call to __add_zone(), so that, when it is eventually
invoked, pfn_valid() would return true and pages would be correctly
reserved. On the contrary, on arm64, it will keep returning false
because of the different implementation of pfn_valid().
Given the above, we believed it was cleaner to go for this little and
well-confined hack rather then possibly changing the logic of pfn_valid.
However, we are very open for discussion and suggestions for improvement.
In particular, any advices on how to effectively modify pfn_valid()
without breaking existing functionalities are very welcome.
Thanks,
Andrea
^ permalink raw reply
* [PATCH 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2016-12-15 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5f667b4f-b1f3-df34-ec0d-b62061328642@synopsys.com>
Hi Jose Miguel Abreu,
Thanks for the review...
> > + chan->idle = true;
> >
> > spin_lock_init(&chan->lock);
> > INIT_LIST_HEAD(&chan->pending_list);
>
> I think there is missing a set to true in idle when a channel reset is performed.
> Otherwise: Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Sure will fix in v2...
Regards,
Kedar.
>
> Best regards,
> Jose Miguel Abreu
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Stefan Wahren @ 2016-12-15 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481809814.29241.2.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Dezember 2016 um 14:50 geschrieben:
>
>
> Hi Stefan,
>
> On Wed, 2016-12-14 at 19:57 +0100, Stefan Wahren wrote:
> > Hi J?rg,
> >
>
> [snip]
>
> > > >
> > > > did you try cyclictest [1]?
> > >
> > > Not yet. Not sure what to measure and which values to compare here.
> >
> > i tought you have the vendor kernel and the mainline kernel available
> > for your platform.
> >
> > So you could compare the both kernels.
>
> Yes, that's right. I will have a look at this tool.
>
> > >
> > > >
> > > > Beside the time for a request the amount of requests for the
> > > > complete
> > > > iperf test
> > > > would we interesting. Maybe there are retries.
> > > >
> > > > I'm still interested in your PIO mode patches for mxs-mmc even
> > > > without clean up.
> > >
> > > Actually, the patch does not implement a PIO mode, but drops DMA
> > > and
> > > uses polling instead. I've attached the patch.
> >
> > Thanks. I applied it, but unfortunately this breaks SD card support
> > for my Duckbill and the kernel isn't able to mount the rootfs:
> >
> > [ 2.267073] mxs-mmc 80010000.ssp: initialized
> > [ 2.272624] mxs-mmc 80010000.ssp: AC command error 0xffffff92
>
> Sorry, I messed up the branches. I attached the correct patch which is
> working for me on Linux v4.9.
i tested the second version but there isn't any performance gain with the patch.
Duckbill with class 10 SD card
Linux 4.8 without patch
dd if=/dev/zero of=test bs=1k count=10000
10000+0 records in
10000+0 records out
10240000 bytes (10 MB) copied, 2.68934 s, 3.8 MB/s
dd if=/dev/zero of=test bs=8k count=10000
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 8.24305 s, 9.9 MB/s
Duckbill with class 10 SD card
Linux 4.8 with patch
dd if=/dev/zero of=test bs=1k count=10000
10000+0 records in
10000+0 records out
10240000 bytes (10 MB) copied, 3.41193 s, 3.0 MB/s
dd if=/dev/zero of=test bs=8k count=10000
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 14.4564 s, 5.7 MB/s
Additionally i get these warning during boot:
[ 2.278445] mxs-mmc 80010000.ssp: initialized
[ 2.283996] mxs-mmc 80010000.ssp: AC command error -110
[ 2.305158] mxs-mmc 80010000.ssp: AC command error -110
[ 2.322975] mxs-mmc 80010000.ssp: AC command error -110
[ 2.338660] mxs-mmc 80010000.ssp: AC command error -110
[ 2.344289] mxs-mmc 80010000.ssp: AC command error -110
[ 2.365653] mxs-mmc 80010000.ssp: AC command error -110
Regards
Stefan
>
> J?rg
^ permalink raw reply
* [PATCH 1/2] ARM: hyp-stub: improve ABI
From: Russell King - ARM Linux @ 2016-12-15 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c21d6514-44a2-ba88-0fe5-d14d5897cc48@arm.com>
On Thu, Dec 15, 2016 at 03:37:15PM +0000, Marc Zyngier wrote:
> On 15/12/16 15:15, Russell King - ARM Linux wrote:
> > On Thu, Dec 15, 2016 at 11:46:41AM +0000, Marc Zyngier wrote:
> >> On 15/12/16 11:35, Russell King - ARM Linux wrote:
> >>> On Thu, Dec 15, 2016 at 11:18:48AM +0000, Marc Zyngier wrote:
> >>>> On 14/12/16 10:46, Russell King wrote:
> >>>>> @@ -231,10 +244,14 @@ ENDPROC(__hyp_stub_do_trap)
> >>>>> * initialisation entry point.
> >>>>> */
> >>>>> ENTRY(__hyp_get_vectors)
> >>>>> - mov r0, #-1
> >>>>> + mov r0, #HVC_GET_VECTORS
> >>>>
> >>>> This breaks the KVM implementation of __hyp_get_vectors, easily fixed
> >>>> with the following patchlet:
> >>>
> >>> Right, so what Mark said is wrong:
> >>>
> >>> "The hyp-stub is part of the kernel image, and the API is private to
> >>> that particular image, so we can change things -- there's no ABI to
> >>> worry about."
> >>
> >> I think Mark is right. The API *is* private to the kernel, and KVM being
> >> the only in-kernel hypervisor on ARM, this is not an ABI.
> >
> > Again, that's wrong.
> >
> > We have two hypervisors in the kernel. One is KVM, the other is the
> > stub. Sure, the stub isn't a full implementation of a hypervisor, but
> > it is nevertheless, for the purposes of _this_ discussion, a hypervisor
> > of sorts.
> >
> > The reason that both are included is because they both appear to share
> > a common interface (although that's totally not documented anywhere.)
>
> And this interface exists for the sole purpose of enabling KVM. Call it
> a hypervisor if you wish, but its usefulness is doubtful on its own.
>
> >>> So no, I'm going with my original patch (which TI has tested) which is
> >>> the minimal change, and if we _then_ want to rework the HYP mode
> >>> interfaces, that's the time to do the other changes when more people
> >>> (such as KVM folk) are paying attention and we can come to a cross-
> >>> hypervisor agreement on what the interface should be.
> >>
> >> Given that there is a single in-kernel hypervisor, I can't really see
> >> who we're going to agree anything with...
> >
> > As far as I can see, the hyp-stub falls under ARM arch maintanence.
> > KVM falls under KVM people. Two different groups, we need agreement
> > between them what a sane API for both "hypervisors" should be.
>
> Well, I though we had the right level of discussion by reviewing your
> patches and coming up with improvements. If you're after something else,
> please let me know.
What I'm after is a meaningful discussion between ARM arch maintainers
and KVM maintainers - so far all I see are people on the ARM side of
things.
I've also yet to have any response on some of the KVM questions I raised
earlier in this thread - again, silence from KVM people.
What's also coming clear is that there's very few people who understand
all the interactions here, and the whole thing seems to be an undocumented
mess. Something needs to change there - people need to stop shovelling
half baked crap into the kernel. KVM have the privilege of being able to
push ARM stuff directly, I now see that was a very big mistake.
So, I want KVM further changes to come through my tree once this merge
window is over - and I want to see some documentation about how things
hang together, because hardly anyone understands it right now, and that's
_really_ bad.
Let's start with some documentation on the KVM hypervisor interfaces on
32-bit ARM. Documentation/virtual/kvm/hypercalls.txt already contains
some for x86, s390 and PPC, so that would be a good place to document
the ARM side. Arguably, that should have already been done.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* arm64: mm: bug around swiotlb_dma_ops
From: Arnd Bergmann @ 2016-12-15 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8862fe21-0a82-a09a-c1cb-aa79d46179ec@cogentembedded.com>
On Thursday, December 15, 2016 7:20:11 PM CET Nikita Yushchenko wrote:
> Hi.
>
> Per Documentation/DMA-API-HOWTO.txt, driver of device capable of 64-bit
> DMA addressing, should call dma_set_mask_and_coherent(dev,
> DMA_BIT_MASK(64)) and if that succeeds, assume that 64-bit DMA
> addressing is available.
>
> This behaves incorrectly on arm64 system (Renesas r8a7795-h3ulcb) here.
>
> - Device (NVME SSD) has it's dev->archdata.dma_ops set to swiotlb_dma_ops.
>
> - swiotlb_dma_ops.dma_supported is set to swiotlb_dma_supported():
>
> int swiotlb_dma_supported(struct device *hwdev, u64 mask)
> {
> return phys_to_dma(hwdev, io_tlb_end - 1) <= mask;
> }
>
> this definitely returns true for mask=DMA_BIT_MASK(64) since that is
> maximum possible 64-bit value.
>
> - Thus device dma_mask is unconditionally updated, and
> dma_set_mask_and_coherent() succeeds.
>
> - Later, __swiotlb_map_page() / __swiotlb_map_sg_attr() will consult
> this updated mask, and return high addresses as valid DMA addresses.
>
>
> Thus recommended dma_set_mask_and_coherent() call, instead of checking
> if platform supports 64-bit DMA addressing, unconditionally enables
> 64-bit DMA addressing. In case of device actually can't do DMA to 64-bit
> addresses (e.g. because of limitations in PCIe controller), this breaks
> things. This is exactly what happens here.
>
>
> Not sure what is proper fix for this though.
I had prototyped something for this a long time ago. It's probably
wrong or incomplete, but maybe it helps you get closer to a solution.
Arnd
commit 76c3f31874b0791b4be72cdd64791a64495c3a4a
Author: Arnd Bergmann <arnd@arndb.de>
Date: Tue Nov 17 14:06:55 2015 +0100
[EXPERIMENTAL] ARM64: check implement dma_set_mask
Needs work for coherent mask
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 243ef256b8c9..a57e7bb10e71 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -22,6 +22,7 @@ struct dev_archdata {
void *iommu; /* private IOMMU data */
#endif
bool dma_coherent;
+ u64 parent_dma_mask;
};
struct pdev_archdata {
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f3351f..aa65875c611b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -352,6 +352,31 @@ static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
return 1;
}
+static int __swiotlb_set_dma_mask(struct device *dev, u64 mask)
+{
+ /* device is not DMA capable */
+ if (!dev->dma_mask)
+ return -EIO;
+
+ /* mask is below swiotlb bounce buffer, so fail */
+ if (!swiotlb_dma_supported(dev, mask))
+ return -EIO;
+
+ /*
+ * because of the swiotlb, we can return success for
+ * larger masks, but need to ensure that bounce buffers
+ * are used above parent_dma_mask, so set that as
+ * the effective mask.
+ */
+ if (mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+
+ *dev->dma_mask = mask;
+
+ return 0;
+}
+
static struct dma_map_ops swiotlb_dma_ops = {
.alloc = __dma_alloc,
.free = __dma_free,
@@ -367,6 +392,7 @@ static struct dma_map_ops swiotlb_dma_ops = {
.sync_sg_for_device = __swiotlb_sync_sg_for_device,
.dma_supported = __swiotlb_dma_supported,
.mapping_error = swiotlb_dma_mapping_error,
+ .set_dma_mask = __swiotlb_set_dma_mask,
};
static int __init atomic_pool_init(void)
@@ -957,6 +983,18 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
if (!dev->archdata.dma_ops)
dev->archdata.dma_ops = &swiotlb_dma_ops;
+ /*
+ * we don't yet support buses that have a non-zero mapping.
+ * Let's hope we won't need it
+ */
+ WARN_ON(dma_base != 0);
+
+ /*
+ * Whatever the parent bus can set. A device must not set
+ * a DMA mask larger than this.
+ */
+ dev->archdata.parent_dma_mask = size;
+
dev->archdata.dma_coherent = coherent;
__iommu_setup_dma_ops(dev, dma_base, size, iommu);
}
^ permalink raw reply related
* [PATCH 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Appana Durga Kedareswara Rao @ 2016-12-15 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d92984b-e04a-cd29-e933-d8ea4d610c94@synopsys.com>
Hi Jose Miguel Abreu,
Thanks for the review....
> > - last = segment;
> > + for (j = 0; j < chan->num_frms; ) {
> > + list_for_each_entry(segment, &desc->segments, node)
> {
> > + if (chan->ext_addr)
> > + vdma_desc_write_64(chan,
> > +
> XILINX_VDMA_REG_START_ADDRESS_64(i++),
> > + segment->hw.buf_addr,
> > + segment->hw.buf_addr_msb);
> > + else
> > + vdma_desc_write(chan,
> > +
> XILINX_VDMA_REG_START_ADDRESS(i++),
> > + segment->hw.buf_addr);
> > +
> > + last = segment;
>
> Hmm, is it possible to submit more than one segment? If so, then i and j will get
> out of sync.
If h/w is configured for more than 1 frame buffer and user submits more than one frame buffer
We can submit more than one frame/ segment to hw right??
>
> > + }
> > + list_del(&desc->node);
> > + list_add_tail(&desc->node, &chan->active_list);
> > + j++;
>
> But if i is non zero and pending_list has more than num_frms then i will not
> wrap-around as it should and will write to invalid framebuffer location, right?
Yep will fix in v2...
If (if (list_empty(&chan->pending_list)) || (i == chan->num_frms)
break;
Above condition is sufficient right???
>
> > + if (list_empty(&chan->pending_list))
> > + break;
> > + desc = list_first_entry(&chan->pending_list,
> > + struct
> xilinx_dma_tx_descriptor,
> > + node);
> > }
> >
> > if (!last)
> > @@ -1114,14 +1124,13 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_dma_chan *chan)
> > vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
> > last->hw.stride);
> > vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last-
> >hw.vsize);
>
> Maybe a check that all framebuffers contain valid addresses should be done
> before programming vsize so that VDMA does not try to write to invalid
> addresses.
Do we really need to check for valid address???
I didn't get you what to do you mean by invalid address could you please explain???
In the driver we are reading form the pending_list which will be updated by pep_interleaved_dma
Call so we are under assumption that user sends the proper address right???
>
> > +
> > + chan->desc_submitcount += j;
> > + chan->desc_pendingcount -= j;
> > }
> >
> > chan->idle = false;
> > if (!chan->has_sg) {
> > - list_del(&desc->node);
> > - list_add_tail(&desc->node, &chan->active_list);
> > - chan->desc_submitcount++;
> > - chan->desc_pendingcount--;
> > if (chan->desc_submitcount == chan->num_frms)
> > chan->desc_submitcount = 0;
>
> "desc_submitcount >= chan->num_frms would be safer here.
Sure will fix in v2...
Regards,
Kedar.
>
> > } else {
>
> Best regards,
> Jose Miguel Abreu
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" 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
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