* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Mark Brown @ 2018-05-17 4:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c23cdde58b9f724f51787c6c38478df983be6efa.camel@microchip.com>
On Tue, May 15, 2018 at 12:22:24PM +0300, Radu Pirea wrote:
> On Mon, 2018-05-14 at 20:38 +0300, Andy Shevchenko wrote:
> > So, what is not going as expected in "SPI core takes care of CSs"
> > case?
> > Did you use oscilloscope for that?
> Yes, I used and CSs was not asserted. Anyway, I will will try again.
If the core chip select handling is not working properly for some reason
then the core chip select handling should be fixed rather than just open
coding in your driver - probably it's also broken for other users.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/795c8270/attachment-0001.sig>
^ permalink raw reply
* [GIT PULL] ARM: mediatek: soc driver updates for v4.18
From: Mark Brown @ 2018-05-17 4:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd033549-4998-e376-eb92-16111ec71a07@gmail.com>
On Mon, May 14, 2018 at 01:32:49PM +0200, Matthias Brugger wrote:
> ----------------------------------------------------------------
> Matthias Brugger (1):
> Merge commit 'f15cd6d99198e9c15229aefec639a34a6e8174c6' into
> v.4.17-next/soc-test
There is a signed tag for this - please don't ever pull anything from me
without a signed tag, while I try to avoid rewriting history it does
sometimes happen but if I've made a signed tag part of that is me saying
I know other people might've merged the commit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/8f7bd0fc/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] pinctrl: pinctrl-single: Add functions to save and restore pinctrl context
From: Keerthy @ 2018-05-17 4:40 UTC (permalink / raw)
To: linux-arm-kernel
This adds a pair of context save/restore functions to save/restore the
state of a set of pinctrl registers. The context is lost during rtc only
suspend with ddr in self-refresh on am43xx. Currently the save/restore
is being done unconditionally. This will be optimized later with a
pdata-quirk function which will allow is to save/restore only when doing
the rtc only mode with ddr in self refresh.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
Changes in v2:
* As this is needed only the in the suspend/resume path
removed the cpu_pm notifier and added the save/restore in
the suspend/resume calls.
* Saving/Restoring unconditionally at the moment. This will
be optimized later with the help of a pdata-quirk function.
drivers/pinctrl/pinctrl-single.c | 72 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index a7c5eb3..9c3c005 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -144,6 +144,7 @@ struct pcs_soc_data {
* struct pcs_device - pinctrl device instance
* @res: resources
* @base: virtual address of the controller
+ * @saved_vals: saved values for the controller
* @size: size of the ioremapped area
* @dev: device entry
* @np: device tree node
@@ -172,11 +173,13 @@ struct pcs_soc_data {
struct pcs_device {
struct resource *res;
void __iomem *base;
+ void *saved_vals;
unsigned size;
struct device *dev;
struct device_node *np;
struct pinctrl_dev *pctl;
unsigned flags;
+#define PCS_CONTEXT_LOSS_OFF (1 << 3)
#define PCS_QUIRK_SHARED_IRQ (1 << 2)
#define PCS_FEAT_IRQ (1 << 1)
#define PCS_FEAT_PINCONF (1 << 0)
@@ -1576,6 +1579,67 @@ static int pcs_irq_init_chained_handler(struct pcs_device *pcs,
}
#ifdef CONFIG_PM
+static int pcs_save_context(struct pcs_device *pcs)
+{
+ int i, mux_bytes;
+ u64 *regsl;
+ u32 *regsw;
+ u16 *regshw;
+
+ mux_bytes = pcs->width / BITS_PER_BYTE;
+
+ if (!pcs->saved_vals)
+ pcs->saved_vals = devm_kzalloc(pcs->dev, pcs->size, GFP_ATOMIC);
+
+ switch (pcs->width) {
+ case 64:
+ regsl = (u64 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ regsl[i] = pcs->read(pcs->base + i * mux_bytes);
+ break;
+ case 32:
+ regsw = (u32 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ regsw[i] = pcs->read(pcs->base + i * mux_bytes);
+ break;
+ case 16:
+ regshw = (u16 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ regshw[i] = pcs->read(pcs->base + i * mux_bytes);
+ break;
+ }
+
+ return 0;
+}
+
+static void pcs_restore_context(struct pcs_device *pcs)
+{
+ int i, mux_bytes;
+ u64 *regsl;
+ u32 *regsw;
+ u16 *regshw;
+
+ mux_bytes = pcs->width / BITS_PER_BYTE;
+
+ switch (pcs->width) {
+ case 64:
+ regsl = (u64 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ pcs->write(regsl[i], pcs->base + i * mux_bytes);
+ break;
+ case 32:
+ regsw = (u32 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ pcs->write(regsw[i], pcs->base + i * mux_bytes);
+ break;
+ case 16:
+ regshw = (u16 *)pcs->saved_vals;
+ for (i = 0; i < pcs->size / mux_bytes; i++)
+ pcs->write(regshw[i], pcs->base + i * mux_bytes);
+ break;
+ }
+}
+
static int pinctrl_single_suspend(struct platform_device *pdev,
pm_message_t state)
{
@@ -1585,6 +1649,9 @@ static int pinctrl_single_suspend(struct platform_device *pdev,
if (!pcs)
return -EINVAL;
+ if (pcs->flags & PCS_CONTEXT_LOSS_OFF)
+ pcs_save_context(pcs);
+
return pinctrl_force_sleep(pcs->pctl);
}
@@ -1596,6 +1663,9 @@ static int pinctrl_single_resume(struct platform_device *pdev)
if (!pcs)
return -EINVAL;
+ if (pcs->flags & PCS_CONTEXT_LOSS_OFF)
+ pcs_restore_context(pcs);
+
return pinctrl_force_default(pcs->pctl);
}
#endif
@@ -1824,7 +1894,7 @@ static int pcs_remove(struct platform_device *pdev)
};
static const struct pcs_soc_data pinctrl_single_am437x = {
- .flags = PCS_QUIRK_SHARED_IRQ,
+ .flags = PCS_QUIRK_SHARED_IRQ | PCS_CONTEXT_LOSS_OFF,
.irq_enable_mask = (1 << 29), /* OMAP_WAKEUP_EN */
.irq_status_mask = (1 << 30), /* OMAP_WAKEUP_EVENT */
};
--
1.9.1
^ permalink raw reply related
* [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order
From: Viresh Kumar @ 2018-05-17 4:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <71309e94-90d4-2b58-729b-9ab488c6d554@gmail.com>
On 16-05-18, 12:24, Florian Fainelli wrote:
> On 05/15/2018 09:32 PM, Viresh Kumar wrote:
> > On 15-05-18, 20:49, Markus Mayer wrote:
> >> From: Markus Mayer <mmayer@broadcom.com>
> >>
> >> Most CPUfreq drivers (at least on ARM) seem to be sorting the available
> >> frequencies from lowest to highest. To match this behaviour, we reverse
> >> the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to
> >> highest.
> >
> > The reasoning isn't correct. Just because everyone else is doing it
> > doesn't make it right and so you shouldn't change just because of
> > that.
> >
> > What you must written instead in the commit log is that the cpufreq
> > core performs better if the table is sorted (in any order), and so we
> > must sort it as well.
>
> Is there a reason why set_freq_table_sorted() tries an ascending or
> descending sort, but does not enforce one versus another for all drivers?
set_freq_table_sorted() doesn't sort the frequency table but checks if
the table is already sorted in a particular order. And then
cpufreq_frequency_table_target() is optimized based on this flag. We
don't have to enforce any particular ordering here.
> > But I feel the table is already sorted for your platform, isn't it?
> > And I don't see a clear advantage of merging this patch.
>
> The patch changes the order to have the lowest to highest, whereas the
> current implementation has them from highest to lowest. From what you
> are saying, it sounds like this is unnecessary, since the sorting is
> already making things efficient enough, so this is just a cosmetic thing?
Right. It shouldn't make any performance improvements.
--
viresh
^ permalink raw reply
* [PATCH v3 08/14] media: v4l: Add definitions for MPEG2 frame format and header metadata
From: kbuild test robot @ 2018-05-17 4:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507124500.20434-9-paul.kocialkowski@bootlin.com>
Hi Florent,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.17-rc5 next-20180516]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Paul-Kocialkowski/Sunxi-Cedrus-driver-for-the-Allwinner-Video-Engine-using-media-requests/20180508-004955
base: git://linuxtv.org/media_tree.git master
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
>> ./usr/include/linux/v4l2-controls.h:1082: found __[us]{8,16,32,64} type without #include <linux/types.h>
---
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: 30376 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/fa20e902/attachment-0001.gz>
^ permalink raw reply
* [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list
From: Baoquan He @ 2018-05-17 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517021024.GI24627@MiWiFi-R3L-srv>
On 05/17/18 at 10:10am, Baoquan He wrote:
> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
> > James,
> >
> > On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> > > Hi Akashi,
> > >
> > > On 25/04/18 07:26, AKASHI Takahiro wrote:
> > > > We need to prevent firmware-reserved memory regions, particularly EFI
> > > > memory map as well as ACPI tables, from being corrupted by loading
> > > > kernel/initrd (or other kexec buffers). We also want to support memory
> > > > allocation in top-down manner in addition to default bottom-up.
> > > > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > > > for available memory ranges in usable memblock list,
> > > > i.e. !NOMAP & !reserved,
> > >
> > > > instead of system resource tree.
> > >
> > > Didn't we try to fix the system-resource-tree in order to fix regular-kexec to
> > > be safe in the EFI-memory-map/ACPI-tables case?
> > >
> > > It would be good to avoid having two ways of doing this, and I would like to
> > > avoid having extra arch code...
> >
> > I know what you mean.
> > /proc/iomem or system resource is, in my opinion, not the best place to
> > describe memory usage of kernel but rather to describe *physical* hardware
> > layout. As we are still discussing about "reserved" memory, I don't want
> > to depend on it.
> > Along with memblock list, we will have more accurate control over memory
> > usage.
>
> In kexec-tools, we see any usable memory as candidate which can be used
Here I said 'any', it's not accurate. Those memory which need be passed
to 2nd kernel for use need be excluded, just as we have done in
kexec-tools.
> to load kexec kernel image/initrd etc. However kexec loading is a
> preparation work, it just books those position for later kexec kernel
> jumping after "kexec -e", that is why we need kexec_buf to remember
> them and do the real content copy of kernel/initrd. Here you use
> memblock to search available memory, isn't it deviating too far away
> from the original design in kexec-tools. Assume kexec loading and
> kexec_file loading should be consistent on loading even though they are
> done in different space, kernel space and user space.
>
> I didn't follow the earlier post, may miss something.
>
> Thanks
> Baoquan
>
> >
> > >
> > > > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> > > > new file mode 100644
> > > > index 000000000000..f9ebf54ca247
> > > > --- /dev/null
> > > > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > > > @@ -0,0 +1,57 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * kexec_file for arm64
> > > > + *
> > > > + * Copyright (C) 2018 Linaro Limited
> > > > + * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > + *
> > >
> > > > + * Most code is derived from arm64 port of kexec-tools
> > >
> > > How does kexec-tools walk memblock?
> >
> > Will remove this comment from this patch.
> > Obviously, this comment is for the rest of the code which will be
> > added to succeeding patches (patch #5 and #7).
> >
> >
> > >
> > > > + */
> > > > +
> > > > +#define pr_fmt(fmt) "kexec_file: " fmt
> > > > +
> > > > +#include <linux/ioport.h>
> > > > +#include <linux/kernel.h>
> > > > +#include <linux/kexec.h>
> > > > +#include <linux/memblock.h>
> > > > +
> > > > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > > > + int (*func)(struct resource *, void *))
> > > > +{
> > > > + phys_addr_t start, end;
> > > > + struct resource res;
> > > > + u64 i;
> > > > + int ret = 0;
> > > > +
> > > > + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > > > + return func(&crashk_res, kbuf);
> > > > +
> > > > + if (kbuf->top_down)
> > > > + for_each_mem_range_rev(i, &memblock.memory, &memblock.reserved,
> > > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > > + &start, &end, NULL) {
> > >
> > > for_each_free_mem_range_reverse() is a more readable version of this helper.
> >
> > OK. I used to use my own limited list of reserved memory instead of
> > memblock.reserved here to exclude verbose ranges.
> >
> >
> > > > + if (!memblock_is_map_memory(start))
> > > > + continue;
> > >
> > > Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP memory.
> >
> > Sure, I confirmed it.
> >
> > >
> > > > + res.start = start;
> > > > + res.end = end;
> > > > + ret = func(&res, kbuf);
> > > > + if (ret)
> > > > + break;
> > > > + }
> > > > + else
> > > > + for_each_mem_range(i, &memblock.memory, &memblock.reserved,
> > > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > > + &start, &end, NULL) {
> > >
> > > for_each_free_mem_range()?
> >
> > OK.
> >
> > > > + if (!memblock_is_map_memory(start))
> > > > + continue;
> > > > +
> > > > + res.start = start;
> > > > + res.end = end;
> > > > + ret = func(&res, kbuf);
> > > > + if (ret)
> > > > + break;
> > > > + }
> > > > +
> > > > + return ret;
> > > > +}
> > > >
> > >
> > > With these changes, what we have is almost:
> > > arch/powerpc/kernel/machine_kexec_file_64.c::arch_kexec_walk_mem() !
> > > (the difference being powerpc doesn't yet support crash-kernels here)
> > >
> > > If the argument is walking memblock gives a better answer than the stringy
> > > walk_system_ram_res() thing, is there any mileage in moving this code into
> > > kexec_file.c, and using it if !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)?
> > >
> > > This would save arm64/powerpc having near-identical implementations.
> > > 32bit arm keeps memblock if it has kexec, so it may be useful there too if
> > > kexec_file_load() support is added.
> >
> > Thanks. I've forgot ppc.
> >
> > -Takahiro AKASHI
> >
> >
> > >
> > > Thanks,
> > >
> > > James
> >
> > _______________________________________________
> > kexec mailing list
> > kexec at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list
From: Baoquan He @ 2018-05-17 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507055906.GE11326@linaro.org>
On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
> James,
>
> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> > Hi Akashi,
> >
> > On 25/04/18 07:26, AKASHI Takahiro wrote:
> > > We need to prevent firmware-reserved memory regions, particularly EFI
> > > memory map as well as ACPI tables, from being corrupted by loading
> > > kernel/initrd (or other kexec buffers). We also want to support memory
> > > allocation in top-down manner in addition to default bottom-up.
> > > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > > for available memory ranges in usable memblock list,
> > > i.e. !NOMAP & !reserved,
> >
> > > instead of system resource tree.
> >
> > Didn't we try to fix the system-resource-tree in order to fix regular-kexec to
> > be safe in the EFI-memory-map/ACPI-tables case?
> >
> > It would be good to avoid having two ways of doing this, and I would like to
> > avoid having extra arch code...
>
> I know what you mean.
> /proc/iomem or system resource is, in my opinion, not the best place to
> describe memory usage of kernel but rather to describe *physical* hardware
> layout. As we are still discussing about "reserved" memory, I don't want
> to depend on it.
> Along with memblock list, we will have more accurate control over memory
> usage.
In kexec-tools, we see any usable memory as candidate which can be used
to load kexec kernel image/initrd etc. However kexec loading is a
preparation work, it just books those position for later kexec kernel
jumping after "kexec -e", that is why we need kexec_buf to remember
them and do the real content copy of kernel/initrd. Here you use
memblock to search available memory, isn't it deviating too far away
from the original design in kexec-tools. Assume kexec loading and
kexec_file loading should be consistent on loading even though they are
done in different space, kernel space and user space.
I didn't follow the earlier post, may miss something.
Thanks
Baoquan
>
> >
> > > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> > > new file mode 100644
> > > index 000000000000..f9ebf54ca247
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > > @@ -0,0 +1,57 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * kexec_file for arm64
> > > + *
> > > + * Copyright (C) 2018 Linaro Limited
> > > + * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > + *
> >
> > > + * Most code is derived from arm64 port of kexec-tools
> >
> > How does kexec-tools walk memblock?
>
> Will remove this comment from this patch.
> Obviously, this comment is for the rest of the code which will be
> added to succeeding patches (patch #5 and #7).
>
>
> >
> > > + */
> > > +
> > > +#define pr_fmt(fmt) "kexec_file: " fmt
> > > +
> > > +#include <linux/ioport.h>
> > > +#include <linux/kernel.h>
> > > +#include <linux/kexec.h>
> > > +#include <linux/memblock.h>
> > > +
> > > +int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > > + int (*func)(struct resource *, void *))
> > > +{
> > > + phys_addr_t start, end;
> > > + struct resource res;
> > > + u64 i;
> > > + int ret = 0;
> > > +
> > > + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> > > + return func(&crashk_res, kbuf);
> > > +
> > > + if (kbuf->top_down)
> > > + for_each_mem_range_rev(i, &memblock.memory, &memblock.reserved,
> > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > + &start, &end, NULL) {
> >
> > for_each_free_mem_range_reverse() is a more readable version of this helper.
>
> OK. I used to use my own limited list of reserved memory instead of
> memblock.reserved here to exclude verbose ranges.
>
>
> > > + if (!memblock_is_map_memory(start))
> > > + continue;
> >
> > Passing MEMBLOCK_NONE means this walk will never find MEMBLOCK_NOMAP memory.
>
> Sure, I confirmed it.
>
> >
> > > + res.start = start;
> > > + res.end = end;
> > > + ret = func(&res, kbuf);
> > > + if (ret)
> > > + break;
> > > + }
> > > + else
> > > + for_each_mem_range(i, &memblock.memory, &memblock.reserved,
> > > + NUMA_NO_NODE, MEMBLOCK_NONE,
> > > + &start, &end, NULL) {
> >
> > for_each_free_mem_range()?
>
> OK.
>
> > > + if (!memblock_is_map_memory(start))
> > > + continue;
> > > +
> > > + res.start = start;
> > > + res.end = end;
> > > + ret = func(&res, kbuf);
> > > + if (ret)
> > > + break;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > >
> >
> > With these changes, what we have is almost:
> > arch/powerpc/kernel/machine_kexec_file_64.c::arch_kexec_walk_mem() !
> > (the difference being powerpc doesn't yet support crash-kernels here)
> >
> > If the argument is walking memblock gives a better answer than the stringy
> > walk_system_ram_res() thing, is there any mileage in moving this code into
> > kexec_file.c, and using it if !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)?
> >
> > This would save arm64/powerpc having near-identical implementations.
> > 32bit arm keeps memblock if it has kexec, so it may be useful there too if
> > kexec_file_load() support is added.
>
> Thanks. I've forgot ppc.
>
> -Takahiro AKASHI
>
>
> >
> > Thanks,
> >
> > James
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH 0/3] coresight: Don't use contextID with PID namespaces
From: Eric W. Biederman @ 2018-05-17 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526404417-32507-1-git-send-email-mathieu.poirier@linaro.org>
Mathieu Poirier <mathieu.poirier@linaro.org> writes:
> Since the in-kernel value of a PID differs from what is seen from
> PID namespaces, using contextID tracing with PID namespaces makes the
> feature confusing to use and potentially subject to leaking out internal
> kernel information.
>
> This set returns an error if contextID and PID namespaces are used in
> conjunction and gets rid of the vpid-to-pid translation function as it
> is no longer needed.
I looked the file can only be written by root. So limiting things to
the initial pid namespace seems like the right solutions. Especially as
the trace stream will include the global pid and be available to the
tracer.
This sounds like a simple code with a minimal chance of breaking
userspace.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
^ permalink raw reply
* [PATCH v2] media: helene: add I2C device probe function
From: Katsuhiro Suzuki @ 2018-05-17 1:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK3bHNVH1476vtJOTR0oFpFC8bvwLecYmgJEQCGp0Y+E4=LSsA@mail.gmail.com>
Hello Abylay,
> -----Original Message-----
> From: Abylay Ospan <aospan@netup.ru>
> Sent: Wednesday, May 16, 2018 7:54 PM
> To: Suzuki, Katsuhiro/?? ?? <suzuki.katsuhiro@socionext.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>; linux-media
> <linux-media@vger.kernel.org>; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v2] media: helene: add I2C device probe function
>
> Hi Katsuhiro,
>
> Thanks for patch.
>
> What is the purpose to rework helene_set_params(_t|_s) ?
> other part of this patch looks ok for me, but not tested due to lack of spare time ;(
>
I'm using Socionext SC1501A (or MN88443x) ISDB-S/ISDB-T demodulator with this
tuner. This demodulator has 1 port, and can use ISDB-S or ISDB-T exclusively.
So I think I cannot use ISDB-S features of this tuner if I use helene_attach(),
and I cannot use ISDB-T if I use helene_attach_s() too.
Regards,
--
Katsuhiro Suzuki
>
> 2018-05-16 4:37 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com
> <mailto:suzuki.katsuhiro@socionext.com> >:
>
>
> This patch adds I2C probe function to use dvb_module_probe()
> with this driver.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com
> <mailto:suzuki.katsuhiro@socionext.com> >
>
> ---
>
> Changes since v1:
> - Add documents for dvb_frontend member of helene_config
> ---
> drivers/media/dvb-frontends/helene.c | 88 ++++++++++++++++++++++++++--
> drivers/media/dvb-frontends/helene.h | 3 +
> 2 files changed, 87 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/helene.c
> b/drivers/media/dvb-frontends/helene.c
> index a0d0b53c91d7..04033f0c278b 100644
> --- a/drivers/media/dvb-frontends/helene.c
> +++ b/drivers/media/dvb-frontends/helene.c
> @@ -666,7 +666,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
> return 0;
> }
>
> -static int helene_set_params(struct dvb_frontend *fe)
> +static int helene_set_params_t(struct dvb_frontend *fe)
> {
> u8 data[MAX_WRITE_REGSIZE];
> u32 frequency;
> @@ -835,6 +835,19 @@ static int helene_set_params(struct dvb_frontend *fe)
> return 0;
> }
>
> +static int helene_set_params(struct dvb_frontend *fe)
> +{
> + struct dtv_frontend_properties *p = &fe->dtv_property_cache;
> +
> + if (p->delivery_system == SYS_DVBT ||
> + p->delivery_system == SYS_DVBT2 ||
> + p->delivery_system == SYS_ISDBT ||
> + p->delivery_system == SYS_DVBC_ANNEX_A)
> + return helene_set_params_t(fe);
> +
> + return helene_set_params_s(fe);
> +}
> +
> static int helene_get_frequency(struct dvb_frontend *fe, u32 *frequency)
> {
> struct helene_priv *priv = fe->tuner_priv;
> @@ -843,7 +856,7 @@ static int helene_get_frequency(struct dvb_frontend *fe,
> u32 *frequency)
> return 0;
> }
>
> -static const struct dvb_tuner_ops helene_tuner_ops = {
> +static const struct dvb_tuner_ops helene_tuner_ops_t = {
> .info = {
> .name = "Sony HELENE Ter tuner",
> .frequency_min = 1000000,
> @@ -853,7 +866,7 @@ static const struct dvb_tuner_ops helene_tuner_ops = {
> .init = helene_init,
> .release = helene_release,
> .sleep = helene_sleep,
> - .set_params = helene_set_params,
> + .set_params = helene_set_params_t,
> .get_frequency = helene_get_frequency,
> };
>
> @@ -871,6 +884,20 @@ static const struct dvb_tuner_ops helene_tuner_ops_s
> = {
> .get_frequency = helene_get_frequency,
> };
>
> +static const struct dvb_tuner_ops helene_tuner_ops = {
> + .info = {
> + .name = "Sony HELENE Sat/Ter tuner",
> + .frequency_min = 500000,
> + .frequency_max = 1200000000,
> + .frequency_step = 1000,
> + },
> + .init = helene_init,
> + .release = helene_release,
> + .sleep = helene_sleep,
> + .set_params = helene_set_params,
> + .get_frequency = helene_get_frequency,
> +};
> +
> /* power-on tuner
> * call once after reset
> */
> @@ -1032,7 +1059,7 @@ struct dvb_frontend *helene_attach(struct
> dvb_frontend *fe,
> if (fe->ops.i2c_gate_ctrl)
> fe->ops.i2c_gate_ctrl(fe, 0);
>
> - memcpy(&fe->ops.tuner_ops, &helene_tuner_ops,
> + memcpy(&fe->ops.tuner_ops, &helene_tuner_ops_t,
> sizeof(struct dvb_tuner_ops));
> fe->tuner_priv = priv;
> dev_info(&priv->i2c->dev,
> @@ -1042,6 +1069,59 @@ struct dvb_frontend *helene_attach(struct
> dvb_frontend *fe,
> }
> EXPORT_SYMBOL(helene_attach);
>
> +static int helene_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct helene_config *config = client->dev.platform_data;
> + struct dvb_frontend *fe = config->fe;
> + struct device *dev = &client->dev;
> + struct helene_priv *priv;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->i2c_address = client->addr;
> + priv->i2c = client->adapter;
> + priv->set_tuner_data = config->set_tuner_priv;
> + priv->set_tuner = config->set_tuner_callback;
> + priv->xtal = config->xtal;
> +
> + if (fe->ops.i2c_gate_ctrl)
> + fe->ops.i2c_gate_ctrl(fe, 1);
> +
> + if (helene_x_pon(priv) != 0)
> + return -EINVAL;
> +
> + if (fe->ops.i2c_gate_ctrl)
> + fe->ops.i2c_gate_ctrl(fe, 0);
> +
> + memcpy(&fe->ops.tuner_ops, &helene_tuner_ops,
> + sizeof(struct dvb_tuner_ops));
> + fe->tuner_priv = priv;
> + i2c_set_clientdata(client, priv);
> +
> + dev_info(dev, "Sony HELENE attached on addr=%x at I2C adapter %p\n",
> + priv->i2c_address, priv->i2c);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id helene_id[] = {
> + { "helene", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, helene_id);
> +
> +static struct i2c_driver helene_driver = {
> + .driver = {
> + .name = "helene",
> + },
> + .probe = helene_probe,
> + .id_table = helene_id,
> +};
> +module_i2c_driver(helene_driver);
> +
> MODULE_DESCRIPTION("Sony HELENE Sat/Ter tuner driver");
> MODULE_AUTHOR("Abylay Ospan <aospan at netup.ru <mailto:aospan@netup.ru>
> >");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/media/dvb-frontends/helene.h
> b/drivers/media/dvb-frontends/helene.h
> index c9fc81c7e4e7..8562d01bc93e 100644
> --- a/drivers/media/dvb-frontends/helene.h
> +++ b/drivers/media/dvb-frontends/helene.h
> @@ -39,6 +39,7 @@ enum helene_xtal {
> * @set_tuner_callback: Callback function that notifies the parent
> driver
> * which tuner is active now
> * @xtal: Cristal frequency as described by &enum helene_xtal
> + * @fe: Frontend for which connects this tuner
> */
> struct helene_config {
> u8 i2c_address;
> @@ -46,6 +47,8 @@ struct helene_config {
> void *set_tuner_priv;
> int (*set_tuner_callback)(void *, int);
> enum helene_xtal xtal;
> +
> + struct dvb_frontend *fe;
> };
>
> #if IS_REACHABLE(CONFIG_DVB_HELENE)
> --
> 2.17.0
>
>
>
>
>
>
> --
>
> Abylay Ospan,
> NetUP Inc.
> http://www.netup.tv <http://www.netup.tv/>
^ permalink raw reply
* [PATCH] media: helene: fix tuning frequency of satellite
From: Katsuhiro Suzuki @ 2018-05-17 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK3bHNUVqd2GODY3k4fzWwtZkZZKMH5Qxs+oiWCODcU9gdYK0A@mail.gmail.com>
Hello Abylay,
> -----Original Message-----
> From: Abylay Ospan <aospan@netup.ru>
> Sent: Wednesday, May 16, 2018 7:56 PM
> To: Suzuki, Katsuhiro/?? ?? <suzuki.katsuhiro@socionext.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>; linux-media
> <linux-media@vger.kernel.org>; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH] media: helene: fix tuning frequency of satellite
>
> True.
> I'm curious but how did it worked before ...
> Which hardware (dvb adapter) are you using ?
>
I'm using evaluation boards of my company. So it's not exist in market...
Tuner module is SONY SUT-PJ series for ISDB-S/ISDB-T (not for DVB).
Regards,
--
Katsuhiro Suzuki
> 2018-05-16 4:41 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com
> <mailto:suzuki.katsuhiro@socionext.com> >:
>
>
> This patch fixes tuning frequency of satellite to kHz. That as same
> as terrestrial one.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com
> <mailto:suzuki.katsuhiro@socionext.com> >
> ---
> drivers/media/dvb-frontends/helene.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/helene.c
> b/drivers/media/dvb-frontends/helene.c
> index 04033f0c278b..0a4f312c4368 100644
> --- a/drivers/media/dvb-frontends/helene.c
> +++ b/drivers/media/dvb-frontends/helene.c
> @@ -523,7 +523,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
> enum helene_tv_system_t tv_system;
> struct dtv_frontend_properties *p = &fe->dtv_property_cache;
> struct helene_priv *priv = fe->tuner_priv;
> - int frequencykHz = p->frequency;
> + int frequencykHz = p->frequency / 1000;
> uint32_t frequency4kHz = 0;
> u32 symbol_rate = p->symbol_rate/1000;
>
> --
> 2.17.0
>
>
>
>
>
>
> --
>
> Abylay Ospan,
> NetUP Inc.
> http://www.netup.tv <http://www.netup.tv/>
^ permalink raw reply
* 答复: 答复: [PATCH v9 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
From: liwei (CM) @ 2018-05-17 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLf_r=NHHP2ZNEJOoLORXztF1KnU+tq-+COt4CPMLAsiA@mail.gmail.com>
Hi, Rob
-----????-----
???: Rob Herring [mailto:robh at kernel.org]
????: 2018?5?16? 21:16
???: liwei (CM)
??: mark.rutland at arm.com; catalin.marinas at arm.com; will.deacon at arm.com; vinholikatti at gmail.com; jejb at linux.vnet.ibm.com; martin.petersen at oracle.com; khilman at baylibre.com; arnd at arndb.de; gregory.clement at free-electrons.com; thomas.petazzoni at free-electrons.com; yamada.masahiro at socionext.com; riku.voipio at linaro.org; treding at nvidia.com; krzk at kernel.org; devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-scsi at vger.kernel.org; zangleigang; Gengjianfeng; guodong.xu at linaro.org
??: Re: ??: [PATCH v9 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
On Tue, Apr 24, 2018 at 8:54 AM, liwei (CM) <liwei213@huawei.com> wrote:
> Hi, Rob
>
> Thanks for your patience.
>
> Hi, Arnd
>
> From Rob's suggestion, we have to list the properties node in ufs-hisi.txt bingings even if documented in the common binding.
>
> -----????-----
> ???: Rob Herring [mailto:robh at kernel.org]
> ????: 2018?4?24? 20:58
> ???: liwei (CM)
> ??: mark.rutland at arm.com; catalin.marinas at arm.com; will.deacon at arm.com; vinholikatti at gmail.com; jejb at linux.vnet.ibm.com; martin.petersen at oracle.com; khilman at baylibre.com; arnd at arndb.de; gregory.clement at free-electrons.com; thomas.petazzoni at free-electrons.com; yamada.masahiro at socionext.com; riku.voipio at linaro.org; treding at nvidia.com; krzk at kernel.org; devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-scsi at vger.kernel.org; zangleigang; Gengjianfeng; guodong.xu at linaro.org
> ??: Re: [PATCH v9 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
>
> On Tue, Apr 17, 2018 at 10:08:11PM +0800, Li Wei wrote:
>> add ufs node document for Hisilicon.
>>
>> Signed-off-by: Li Wei <liwei213@huawei.com>
>> ---
>> Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 29 ++++++++++++++++++++++
>> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 10 +++++---
>> 2 files changed, 36 insertions(+), 3 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>> new file mode 100644
>> index 000000000000..d49ab7d8f31d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>> @@ -0,0 +1,29 @@
>> +* Hisilicon Universal Flash Storage (UFS) Host Controller
>> +
>> +UFS nodes are defined to describe on-chip UFS hardware macro.
>> +Each UFS Host Controller should have its own node.
>> +
>> +Required properties:
>> +- compatible : compatible list, contains one of the following -
>> + "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs
>> + host controller present on Hi36xx chipset.
>> +- reg : should contain UFS register address space & UFS SYS CTRL register address,
>> +- interrupt-parent : interrupt device
>> +- interrupts : interrupt number
>> +- resets : reset node register, the "arst" corresponds to reset the APB/AXI bus.
>
> arst belongs in reset-names.
>
> OK, I will fix it in next patch;
>
>> +- reset-names : describe reset node register
>
> What happened to clocks? You still have to list which ones apply even if
> documented in the common binding.
>
> OK, I will fix it in next patch;
>
>> +
>> +Example:
>> +
>> + ufs: ufs at ff3b0000 {
>> + compatible = "hisilicon,hi3660-ufs", "jedec,ufs-1.1";
>> + /* 0: HCI standard */
>> + /* 1: UFS SYS CTRL */
>> + reg = <0x0 0xff3b0000 0x0 0x1000>,
>> + <0x0 0xff3b1000 0x0 0x1000>;
>> + interrupt-parent = <&gic>;
>> + interrupts = <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>;
>> + /* offset: 0x84; bit: 7 */
>> + resets = <&crg_rst 0x84 7>;
>> + reset-names = "arst";
>> + };
>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> index c39dfef76a18..adcfb79f63f5 100644
>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> @@ -41,6 +41,8 @@ Optional properties:
>> -lanes-per-direction : number of lanes available per direction - either 1 or 2.
>> Note that it is assume same number of lanes is used both
>> directions at once. If not specified, default is 2 lanes per direction.
>> +- resets : reset node register, the "rst" corresponds to reset the whole UFS IP.
>> +- reset-names : describe reset node register
>
> Does your controller have 1 or 2 resets? There's no point in adding this
> here if it doesn't apply to your controller.
>
> There are 2 reset in our soc init, the "rst" corresponds to reset the whole UFS IP, and " arst " only reset the APB/AXI bus.
> Discussed with our soc colleagues that "arst" is assert by default and needs to deassert,but it done in bootloader,so will remove 'arst' in next patch.
>
> About the 'reset' property?it seems that Arnd Bergmann has different suggestion?he suggested that add 'rst' to ufshcd-pltfrm because it seems common.
> But it looks like only our soc init needs it. What's your opinion? Does it still needs add to common bindings?
For a single reset, then I'm fine with it being in the common
bindings. If there are multiple then it should be in the specific
bindings as the reset names are likely different.
OK, I will remove the 'arst' and keep only 'rst' in tne common bingings.
Rob
^ permalink raw reply
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: Adam Ford @ 2018-05-17 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509172606.29387-1-david@lechnology.com>
On Wed, May 9, 2018 at 12:25 PM, David Lechner <david@lechnology.com> wrote:
> This series converts mach-davinci to use the common clock framework.
>
> The series works like this, the first 3 patches fix some issues with the clock
> drivers that have already been accepted into the mainline kernel.
>
> Then, starting with "ARM: davinci: pass clock as parameter to
> davinci_timer_init()", we get the mach code ready for the switch by adding the
> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
> around the legacy clocks so that we can switch easily between the old and the
> new.
>
> "ARM: davinci: switch to common clock framework" actually flips the switch
> to start using the new clock drivers. Then the next 8 patches remove all
> of the old clock code.
>
> The final four patches add device tree clock support to the one SoC that
> supports it.
>
> This series has been tested on TI OMAP-L138 LCDK (both device tree and legacy
> board file).
>
I am find. I don't know what I did wrong, but it's working fine. If
you want to add my 'tested-by' go ahead.
Tested-by: Adam Ford <aford173@gmail.com> #da850-evm, ethernet, spi
flash, SD, UART
>
> Changes:
>
> v10 changes (also see individual patches for details):
> - Reworked device tree bindings for DaVinci timer.
> - Dropped helper functions to conditionally call devm_* versions of functions
> - Fix some typos
> - Fix some rebasing issues introduced in v9
>
> v9 changes (also see individual patches for details):
> - Rebased on linux-davnci/master (f5e3203bb775)
> - Dropped drivers/clk patches that landed in v4.17
> - New drivers/clk patches for early boot special case
> - New patch for ti,davinci-timer device tree bindings
> - Updated mach/davinci patches to register clocks in early boot when needed
>
> v8 changes (also see individual patches for details):
> - Rebased on linux-davinci/master
> - Dropped use of __init and __initconst attributes in clk drivers
> - Add clkdev lookups for PLL SYSCLKs
> - Fix genpd clock reference counting issue
> - Fix PSC clock driver loading order issue
> - Fix typo in device tree and add more power-domains properties
>
> v7 changes (also see individual patches for details):
> - Rebased on linux-davinci/master (v4.16-rc)
> - Convert clock drivers to platform devices
> - New patch "ARM: davinci: pass clock as parameter to davinci_timer_init()"
> - Fix issues with lcdk and aemif clock lookups and power domains
> - Fixed other minor issues brought up in v6 review
>
> v6 changes (also see individual patches for details):
> - All of the device tree bindings are changed
> - All of the clock drivers are changed significantly
> - Fixed issues brought up during review of v5
> - "ARM: davinci: move davinci_clk_init() to init_time" is removed from this
> series and submitted separately
>
> v5 changes:
> - Basically, this is an entirely new series
> - Patches are broken up into bite-sized pieces
> - Converted PSC clock driver to use regmap
> - Restored "force" flag for certain DA850 clocks
> - Added device tree bindings
> - Moved more of the clock init to drivers/clk
> - Fixed frequency scaling (maybe*)
>
> * I have frequency scaling using cpufreq-dt, so I know the clocks are doing
> what they need to do to make this work, but I haven't figured out how to
> test davinci-cpufreq driver yet. (Patches to make cpufreq-dt work will be
> sent separately after this series has landed.)
>
>
> Dependencies:
>
> There are still some outstanding fixes to get everything working correctly.
> These are all just runtime dependencies and only needed for certain platforms.
>
> - "drm/tilcdc: Fix setting clock divider for omap-l138"[1]
> - "clk: davinci: pll-dm355: fix SYSCLKn parent names"[2]
> - "remoteproc/davinci: common clock framework related fixes"[3]
>
> [1]: https://patchwork.freedesktop.org/patch/210696/
> [2]: https://lkml.org/lkml/2018/5/9/626
> [3]: https://lkml.org/lkml/2018/5/2/201
>
> You can find a working branch with everything included (plus a few extras, like
> cpufreq-dt) in the "common-clk-v10" branch of https://github.com/dlech/ev3dev-kernel.git.
>
>
> Testing/debugging for the uninitiated:
>
> I only have one device to test with, which is based on da850, so I will
> have to rely on others to do some testing here. Since we are dealing with
> clocks, if something isn't working, you most likely won't see output on
> the serial port. To figure out what is going on, you need to enable...
>
> CONFIG_DEBUG_LL=y
> CONFIG_EARLY_PRINTK=y
>
> and add "earlyprintk clk_ignore_unused" to the kernel command line options.
> You may need to select a different UART for this depending on your board. I
> think UART1 is the default in the kernel configuration.
>
> On da850 devices comment out the lines:
>
> /* pll1_sysclk2 is not affected by CPU scaling, so use it for async3 */
> parent = clk_hw_get_parent_by_index(&mux->hw, 1);
> if (parent)
> clk_set_parent(mux->hw.clk, parent->clk);
> else
> dev_warn(dev, "Failed to find async3 parent clock\n");
>
> in da8xx-cfgchip.c or, if using device tree, comment out the lines:
>
> assigned-clocks = <&async3_clk>;
> assigned-clock-parents = <&pll1_sysclk 2>;
>
> in da850.dtsi when doing earlyprintk, otherwise the UART1 and UART2 clock
> source will change during boot and cause garbled output after a point.
>
>
> David Lechner (27):
> clk: davinci: pll: allow dev == NULL
> clk: davinci: da850-pll: change PLL0 to CLK_OF_DECLARE
> clk: davinci: psc: allow for dev == NULL
> ARM: davinci: pass clock as parameter to davinci_timer_init()
> ARM: davinci: da830: add new clock init using common clock framework
> ARM: davinci: da850: add new clock init using common clock framework
> ARM: davinci: dm355: add new clock init using common clock framework
> ARM: davinci: dm365: add new clock init using common clock framework
> ARM: davinci: dm644x: add new clock init using common clock framework
> ARM: davinci: dm646x: add new clock init using common clock framework
> ARM: davinci: da8xx: add new USB PHY clock init using common clock
> framework
> ARM: davinci: da8xx: add new sata_refclk init using common clock
> framework
> ARM: davinci: remove CONFIG_DAVINCI_RESET_CLOCKS
> ARM: davinci_all_defconfig: remove CONFIG_DAVINCI_RESET_CLOCKS
> ARM: davinci: switch to common clock framework
> ARM: davinci: da830: Remove legacy clock init
> ARM: davinci: da850: Remove legacy clock init
> ARM: davinci: dm355: Remove legacy clock init
> ARM: davinci: dm365: Remove legacy clock init
> ARM: davinci: dm644x: Remove legacy clock init
> ARM: davinci: dm646x: Remove legacy clock init
> ARM: davinci: da8xx: Remove legacy USB and SATA clock init
> ARM: davinci: remove legacy clocks
> dt-bindings: timer: new bindings for TI DaVinci timer
> ARM: davinci: add device tree support to timer
> ARM: davinci: da8xx-dt: switch to device tree clocks
> ARM: dts: da850: Add clocks
>
> .../bindings/timer/ti,davinci-timer.txt | 37 +
> arch/arm/Kconfig | 5 +-
> arch/arm/boot/dts/da850-enbw-cmc.dts | 4 +
> arch/arm/boot/dts/da850-evm.dts | 4 +
> arch/arm/boot/dts/da850-lcdk.dts | 9 +
> arch/arm/boot/dts/da850-lego-ev3.dts | 4 +
> arch/arm/boot/dts/da850.dtsi | 168 ++++
> arch/arm/configs/davinci_all_defconfig | 1 -
> arch/arm/mach-davinci/Kconfig | 13 +-
> arch/arm/mach-davinci/Makefile | 4 +-
> arch/arm/mach-davinci/board-da830-evm.c | 12 +-
> arch/arm/mach-davinci/board-da850-evm.c | 2 +
> arch/arm/mach-davinci/board-dm355-evm.c | 2 +
> arch/arm/mach-davinci/board-dm355-leopard.c | 2 +
> arch/arm/mach-davinci/board-dm365-evm.c | 2 +
> arch/arm/mach-davinci/board-dm644x-evm.c | 2 +
> arch/arm/mach-davinci/board-dm646x-evm.c | 2 +
> arch/arm/mach-davinci/board-mityomapl138.c | 2 +
> arch/arm/mach-davinci/board-neuros-osd2.c | 2 +
> arch/arm/mach-davinci/board-omapl138-hawk.c | 11 +-
> arch/arm/mach-davinci/board-sffsdr.c | 2 +
> arch/arm/mach-davinci/clock.c | 745 -----------------
> arch/arm/mach-davinci/clock.h | 76 --
> arch/arm/mach-davinci/common.c | 3 -
> arch/arm/mach-davinci/da830.c | 462 ++---------
> arch/arm/mach-davinci/da850.c | 778 +++---------------
> arch/arm/mach-davinci/da8xx-dt.c | 66 --
> arch/arm/mach-davinci/davinci.h | 8 +
> arch/arm/mach-davinci/devices-da8xx.c | 43 +-
> arch/arm/mach-davinci/devices.c | 1 -
> arch/arm/mach-davinci/dm355.c | 406 ++-------
> arch/arm/mach-davinci/dm365.c | 485 +----------
> arch/arm/mach-davinci/dm644x.c | 344 +-------
> arch/arm/mach-davinci/dm646x.c | 372 +--------
> arch/arm/mach-davinci/include/mach/clock.h | 3 -
> arch/arm/mach-davinci/include/mach/common.h | 11 +-
> arch/arm/mach-davinci/include/mach/da8xx.h | 6 +-
> arch/arm/mach-davinci/pm_domain.c | 5 +
> arch/arm/mach-davinci/psc.c | 137 ---
> arch/arm/mach-davinci/psc.h | 12 -
> arch/arm/mach-davinci/time.c | 39 +-
> arch/arm/mach-davinci/usb-da8xx.c | 242 +-----
> drivers/clk/davinci/pll-da830.c | 4 +-
> drivers/clk/davinci/pll-da850.c | 36 +-
> drivers/clk/davinci/pll-dm355.c | 8 +-
> drivers/clk/davinci/pll-dm365.c | 8 +-
> drivers/clk/davinci/pll-dm644x.c | 8 +-
> drivers/clk/davinci/pll-dm646x.c | 8 +-
> drivers/clk/davinci/pll.c | 110 +--
> drivers/clk/davinci/pll.h | 30 +-
> drivers/clk/davinci/psc-dm355.c | 2 +-
> drivers/clk/davinci/psc-dm365.c | 2 +-
> drivers/clk/davinci/psc-dm644x.c | 2 +-
> drivers/clk/davinci/psc-dm646x.c | 2 +-
> drivers/clk/davinci/psc.c | 27 +-
> include/linux/clk/davinci.h | 29 +
> 56 files changed, 860 insertions(+), 3950 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/timer/ti,davinci-timer.txt
> delete mode 100644 arch/arm/mach-davinci/clock.c
> delete mode 100644 arch/arm/mach-davinci/psc.c
> create mode 100644 include/linux/clk/davinci.h
>
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH] drivers/perf: arm-ccn: stop spamming dmesg in event_init
From: Kim Phillips @ 2018-05-17 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cee9c043-3d64-56b9-4f23-e8c8370387dd@gmail.com>
[adding acme, LKML, linux-perf-users, and other potentially interested]
On Wed, 9 May 2018 17:22:42 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 05/09/2018 04:41 PM, Kim Phillips wrote:
> > On Wed, 9 May 2018 17:06:43 +0100
> > Pawel Moll <pawel.moll@arm.com> wrote:
> >
> >> On Wed, 2018-05-09 at 00:40 +0100, Kim Phillips wrote:
> >>> On Fri, 4 May 2018 11:41:17 +0100 Mark Rutland <mark.rutland@arm.com> wrote:
> >>>
> >>> [adding Pawel, arm-ccn driver author]
> >>
> >> We had this discussion way too many times for my liking. As I said
> >> before - *I* will be fine with the debug messages in the CCN driver.
> >> Now, if there ever turns out to be other user of this thing and gets
> >
> > Sure, this isn't just about Pawel using the driver he wrote - we know
> > you know how to use it because you wrote it. No, it's about all the
> > other potential users out there, esp. first time users, as I once was.
> >
> >> into problems with event configuration, I'd hope that he/she can count
> >> on support from the knowledgable people here... (just checked and both
> >
> > I abhor having to suggest our users email this list in order to find out
> > how to use the PMU drivers. First time users are going to tend to
> > steer completely away if they don't have the patience to debug a silent
> > PMU, rather than email this mailing list - sorry, but that's just
> > adding a huge usage barrier - for what - fuzzer runner's convenience?
> >
> >> RHEL 7.5 and Ubuntu 16.04.3 kernels on AArch64 come with
> >> CONFIG_DYNAMIC_DEBUG=y, so it's a matter of explaining what has to be
> >> enabled where; sadly this information did not find its way into the
> >> commit description)
> >
> > I can't think of a more difficult to find, more far-away, alien
> > place for end users to find help with perf, sorry.
> >
> >>>> The ARM CCN PMU driver uses dev_warn() to complain about parameters
> >>> in
> >>>> the user-provided perf_event_attr. This means that under normal
> >>>> operation (e.g. a single invocation of the perf tool), dmesg may be
> >>>> spammed with multiple messages.
> >>
> >> Surely Mark, in his role as maintainer of drivers/perf/ (and a few
> >> other locations), meant to use much more technical and emotion-free
> >> subject, along the lines of "reduce a number of dmesg warnings at event
> >> init".
> >
> > 'reduce a number' is the wrong word: warnings are completely
> > eliminated. Debug-level messages occur at exactly the same
> > frequency/amount.
> >
> > But I still object to the rationale overall - it seems this is about
> > running fuzzers? I even offered an alternative for fuzzer runners: is
> > modifying the loglevel prior to fuzzing somehow unacceptable?
>
> I don't have any dog in this, but maybe if providing information to the
> users is so essential to having a pleasant user experience, then
> rethinking the whole way these messages are funneled is necessary
> because the kernel log + dmesg is by no means appropriate. Take a look
> at what the networking maintainers recently did with netlink extended
> ack. You used to just get an "unsupported" error, and now you know
> exactly what is wrong when extack is available. It seems to me like
> something like this is what you might want here since you want to have
> perf be as user friendly as possible.
Thanks, Florian.
Acme & other perf people, do you foresee a problem adding netlink
extended ack support to the perf subsystem for extended error message
communication?
If not, is struct perf_event_attr amenable to having error reporting
bit(s) added? Recall my last attempt failed because it couldn't
discriminate between the perf core and the PMU driver returning the
-Evalue:
https://patchwork.kernel.org/patch/10025555/
Thanks,
Kim
^ permalink raw reply
* [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware
From: Brian Norris @ 2018-05-16 23:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526354560-23135-4-git-send-email-hl@rock-chips.com>
+ Kishon
Hi,
On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
>
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow Sean suggest
>
> drivers/gpu/drm/rockchip/Makefile | 3 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 ++++++++++++++++++++++++
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> 6 files changed, 505 insertions(+), 13 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
...
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 0000000..7efd070
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> @@ -0,0 +1,420 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong <zyw@rock-chips.com>
> + */
> +
> +#include <linux/device.h>
> +#include <linux/delay.h>
> +#include <linux/phy/phy.h>
> +#include <soc/rockchip/rockchip_phy_typec.h>
> +
> +#include "cdn-dp-core.h"
> +#include "cdn-dp-reg.h"
> +
> +static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
> +{
> + struct cdn_dp_port *port = dp->port[dp->active_port];
> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
This is still antithetical to the PHY framework; you're assuming that
this is a particular type of PHY here.
> +
> + int rate = drm_dp_bw_code_to_link_rate(dp->link.rate);
> + u8 swing = (dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) >>
> + DP_TRAIN_VOLTAGE_SWING_SHIFT;
> + u8 pre_emphasis = (dp->train_set[0] & DP_TRAIN_PRE_EMPHASIS_MASK)
> + >> DP_TRAIN_PRE_EMPHASIS_SHIFT;
> +
> + tcphy->typec_phy_config(port->phy, rate, dp->link.num_lanes,
> + swing, pre_emphasis);
Is this something generic that could be added as a new PHY API instead?
> +}
Brian
^ permalink raw reply
* [PATCH v6 1/2] dt-bindings: Documentation for qcom, llcc
From: rishabhb at codeaurora.org @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152649413707.210890.2655572242392552759@swboyd.mtv.corp.google.com>
On 2018-05-16 11:08, Stephen Boyd wrote:
> Quoting rishabhb at codeaurora.org (2018-05-16 10:33:14)
>> On 2018-05-16 10:03, Stephen Boyd wrote:
>> > Quoting Rishabh Bhatnagar (2018-05-08 13:22:00)
>>
>> >> +
>> >> +- max-slices:
>> >> + usage: required
>> >> + Value Type: <u32>
>> >> + Definition: Number of cache slices supported by hardware
>> >> +
>> >> +Example:
>> >> +
>> >> + llcc: qcom,llcc at 1100000 {
>> >
>> > cache-controller at 1100000 ?
>> >
>> We have tried to use consistent naming convention as in llcc_*
>> everywhere.
>> Using cache-controller will mix and match the naming convention. Also
>> in
>> the documentation it is explained what llcc is and its full form.
>>
>
> DT prefers standard node names as opposed to vendor specific node
> names.
> Isn't it a cache controller? I fail to see why this can't be done.
Hi Stephen,
The driver is vendor specific and also for uniformity purposes we
preferred
to go with this name.
^ permalink raw reply
* [PATCH v3 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces
From: Toshi Kani @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516233207.1580-1-toshi.kani@hpe.com>
ioremap() calls pud_free_pmd_page() / pmd_free_pte_page() when it creates
a pud / pmd map. The following preconditions are met at their entry.
- All pte entries for a target pud/pmd address range have been cleared.
- System-wide TLB purges have been peformed for a target pud/pmd address
range.
The preconditions assure that there is no stale TLB entry for the range.
Speculation may not cache TLB entries since it requires all levels of page
entries, including ptes, to have P & A-bits set for an associated address.
However, speculation may cache pud/pmd entries (paging-structure caches)
when they have P-bit set.
Add a system-wide TLB purge (INVLPG) to a single page after clearing
pud/pmd entry's P-bit.
SDM 4.10.4.1, Operation that Invalidate TLBs and Paging-Structure Caches,
states that:
INVLPG invalidates all paging-structure caches associated with the
current PCID regardless of the liner addresses to which they correspond.
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: <stable@vger.kernel.org>
---
arch/x86/mm/pgtable.c | 34 ++++++++++++++++++++++++++++------
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index f60fdf411103..7e96594c7e97 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -721,24 +721,42 @@ int pmd_clear_huge(pmd_t *pmd)
* @pud: Pointer to a PUD.
* @addr: Virtual address associated with pud.
*
- * Context: The pud range has been unmaped and TLB purged.
+ * Context: The pud range has been unmapped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
- pmd_t *pmd;
+ pmd_t *pmd, *pmd_sv;
+ pte_t *pte;
int i;
if (pud_none(*pud))
return 1;
pmd = (pmd_t *)pud_page_vaddr(*pud);
+ pmd_sv = (pmd_t *)__get_free_page(GFP_KERNEL);
+ if (!pmd_sv)
+ return 0;
- for (i = 0; i < PTRS_PER_PMD; i++)
- if (!pmd_free_pte_page(&pmd[i], addr + (i * PMD_SIZE)))
- return 0;
+ for (i = 0; i < PTRS_PER_PMD; i++) {
+ pmd_sv[i] = pmd[i];
+ if (!pmd_none(pmd[i]))
+ pmd_clear(&pmd[i]);
+ }
pud_clear(pud);
+
+ /* INVLPG to clear all paging-structure caches */
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1);
+
+ for (i = 0; i < PTRS_PER_PMD; i++) {
+ if (!pmd_none(pmd_sv[i])) {
+ pte = (pte_t *)pmd_page_vaddr(pmd_sv[i]);
+ free_page((unsigned long)pte);
+ }
+ }
+
+ free_page((unsigned long)pmd_sv);
free_page((unsigned long)pmd);
return 1;
@@ -749,7 +767,7 @@ int pud_free_pmd_page(pud_t *pud, unsigned long addr)
* @pmd: Pointer to a PMD.
* @addr: Virtual address associated with pmd.
*
- * Context: The pmd range has been unmaped and TLB purged.
+ * Context: The pmd range has been unmapped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
@@ -761,6 +779,10 @@ int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
pte = (pte_t *)pmd_page_vaddr(*pmd);
pmd_clear(pmd);
+
+ /* INVLPG to clear all paging-structure caches */
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1);
+
free_page((unsigned long)pte);
return 1;
^ permalink raw reply related
* [PATCH v3 2/3] ioremap: Update pgtable free interfaces with addr
From: Toshi Kani @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516233207.1580-1-toshi.kani@hpe.com>
From: Chintan Pandya <cpandya@codeaurora.org>
This patch ("mm/vmalloc: Add interfaces to free unmapped
page table") adds following 2 interfaces to free the page
table in case we implement huge mapping.
pud_free_pmd_page() and pmd_free_pte_page()
Some architectures (like arm64) needs to do proper TLB
maintanance after updating pagetable entry even in map.
Why ? Read this,
https://patchwork.kernel.org/patch/10134581/
Pass 'addr' in these interfaces so that proper TLB ops
can be performed.
[toshi at hpe.com: merge changes]
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: <stable@vger.kernel.org>
---
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 12 +++++++-----
include/asm-generic/pgtable.h | 8 ++++----
lib/ioremap.c | 4 ++--
4 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..da98828609a1 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -973,12 +973,12 @@ int pmd_clear_huge(pmd_t *pmdp)
return 1;
}
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return pud_none(*pud);
}
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return pmd_none(*pmd);
}
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 3f7180bc5f52..f60fdf411103 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -719,11 +719,12 @@ int pmd_clear_huge(pmd_t *pmd)
/**
* pud_free_pmd_page - Clear pud entry and free pmd page.
* @pud: Pointer to a PUD.
+ * @addr: Virtual address associated with pud.
*
* Context: The pud range has been unmaped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
pmd_t *pmd;
int i;
@@ -734,7 +735,7 @@ int pud_free_pmd_page(pud_t *pud)
pmd = (pmd_t *)pud_page_vaddr(*pud);
for (i = 0; i < PTRS_PER_PMD; i++)
- if (!pmd_free_pte_page(&pmd[i]))
+ if (!pmd_free_pte_page(&pmd[i], addr + (i * PMD_SIZE)))
return 0;
pud_clear(pud);
@@ -746,11 +747,12 @@ int pud_free_pmd_page(pud_t *pud)
/**
* pmd_free_pte_page - Clear pmd entry and free pte page.
* @pmd: Pointer to a PMD.
+ * @addr: Virtual address associated with pmd.
*
* Context: The pmd range has been unmaped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
pte_t *pte;
@@ -766,7 +768,7 @@ int pmd_free_pte_page(pmd_t *pmd)
#else /* !CONFIG_X86_64 */
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return pud_none(*pud);
}
@@ -775,7 +777,7 @@ int pud_free_pmd_page(pud_t *pud)
* Disable free page handling on x86-PAE. This assures that ioremap()
* does not update sync'd pmd entries. See vmalloc_sync_one().
*/
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return pmd_none(*pmd);
}
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index f59639afaa39..b081794ba135 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1019,8 +1019,8 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot);
int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
int pud_clear_huge(pud_t *pud);
int pmd_clear_huge(pmd_t *pmd);
-int pud_free_pmd_page(pud_t *pud);
-int pmd_free_pte_page(pmd_t *pmd);
+int pud_free_pmd_page(pud_t *pud, unsigned long addr);
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr);
#else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot)
{
@@ -1046,11 +1046,11 @@ static inline int pmd_clear_huge(pmd_t *pmd)
{
return 0;
}
-static inline int pud_free_pmd_page(pud_t *pud)
+static inline int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return 0;
}
-static inline int pmd_free_pte_page(pmd_t *pmd)
+static inline int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return 0;
}
diff --git a/lib/ioremap.c b/lib/ioremap.c
index 54e5bbaa3200..517f5853ffed 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -92,7 +92,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long addr,
if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
- pmd_free_pte_page(pmd)) {
+ pmd_free_pte_page(pmd, addr)) {
if (pmd_set_huge(pmd, phys_addr + addr, prot))
continue;
}
@@ -119,7 +119,7 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned long addr,
if (ioremap_pud_enabled() &&
((next - addr) == PUD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PUD_SIZE) &&
- pud_free_pmd_page(pud)) {
+ pud_free_pmd_page(pud, addr)) {
if (pud_set_huge(pud, phys_addr + addr, prot))
continue;
}
^ permalink raw reply related
* [PATCH v3 1/3] x86/mm: disable ioremap free page handling on x86-PAE
From: Toshi Kani @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516233207.1580-1-toshi.kani@hpe.com>
ioremap() supports pmd mappings on x86-PAE. However, kernel's pmd
tables are not shared among processes on x86-PAE. Therefore, any
update to sync'd pmd entries need re-syncing. Freeing a pte page
also leads to a vmalloc fault and hits the BUG_ON in vmalloc_sync_one().
Disable free page handling on x86-PAE. pud_free_pmd_page() and
pmd_free_pte_page() simply return 0 if a given pud/pmd entry is present.
This assures that ioremap() does not update sync'd pmd entries at the
cost of falling back to pte mappings.
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Reported-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: <stable@vger.kernel.org>
---
arch/x86/mm/pgtable.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index ffc8c13c50e4..3f7180bc5f52 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -715,6 +715,7 @@ int pmd_clear_huge(pmd_t *pmd)
return 0;
}
+#ifdef CONFIG_X86_64
/**
* pud_free_pmd_page - Clear pud entry and free pmd page.
* @pud: Pointer to a PUD.
@@ -762,4 +763,22 @@ int pmd_free_pte_page(pmd_t *pmd)
return 1;
}
+
+#else /* !CONFIG_X86_64 */
+
+int pud_free_pmd_page(pud_t *pud)
+{
+ return pud_none(*pud);
+}
+
+/*
+ * Disable free page handling on x86-PAE. This assures that ioremap()
+ * does not update sync'd pmd entries. See vmalloc_sync_one().
+ */
+int pmd_free_pte_page(pmd_t *pmd)
+{
+ return pmd_none(*pmd);
+}
+
+#endif /* CONFIG_X86_64 */
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
^ permalink raw reply related
* [PATCH v3 0/3] fix free pmd/pte page handlings on x86
From: Toshi Kani @ 2018-05-16 23:32 UTC (permalink / raw)
To: linux-arm-kernel
This series fixes two issues in the x86 ioremap free page handlings
for pud/pmd mappings.
Patch 01 fixes BUG_ON on x86-PAE reported by Joerg. It disables
the free page handling on x86-PAE.
Patch 02-03 fixes a possible issue with speculation which can cause
stale page-directory cache.
- Patch 02 is from Chintan's v9 01/04 patch [1], which adds a new arg
'addr', with my merge change to patch 01.
- Patch 03 adds a TLB purge (INVLPG) to purge page-structure caches
that may be cached by speculation. See the patch descriptions for
more detal.
[1] https://patchwork.kernel.org/patch/10371015/
v3:
- Fixed a build error in v2.
v2:
- Reordered patch-set, so that patch 01 can be applied independently.
- Added a NULL pointer check for the page alloc in patch 03.
---
Toshi Kani (2):
1/3 x86/mm: disable ioremap free page handling on x86-PAE
3/3 x86/mm: add TLB purge to free pmd/pte page interfaces
Chintan Pandya (1):
2/3 ioremap: Update pgtable free interfaces with addr
---
arch/arm64/mm/mmu.c | 4 +--
arch/x86/mm/pgtable.c | 59 +++++++++++++++++++++++++++++++++++++------
include/asm-generic/pgtable.h | 8 +++---
lib/ioremap.c | 4 +--
4 files changed, 59 insertions(+), 16 deletions(-)
^ permalink raw reply
* [PATCH v2 03/40] iommu/sva: Manage process address spaces
From: Jacob Pan @ 2018-05-16 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511190641.23008-4-jean-philippe.brucker@arm.com>
On Fri, 11 May 2018 20:06:04 +0100
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> wrote:
> Allocate IOMMU mm structures and binding them to devices. Four
> operations are added to IOMMU drivers:
>
> * mm_alloc(): to create an io_mm structure and perform architecture-
> specific operations required to grab the process (for instance on
> ARM, pin down the CPU ASID so that the process doesn't get assigned a
> new ASID on rollover).
>
> There is a single valid io_mm structure per Linux mm. Future
> extensions may also use io_mm for kernel-managed address spaces,
> populated with map()/unmap() calls instead of bound to process
> address spaces. This patch focuses on "shared" io_mm.
>
> * mm_attach(): attach an mm to a device. The IOMMU driver checks that
> the device is capable of sharing an address space, and writes the
> PASID table entry to install the pgd.
>
> Some IOMMU drivers will have a single PASID table per domain, for
> convenience. Other can implement it differently but to help these
> drivers, mm_attach and mm_detach take 'attach_domain' and
> 'detach_domain' parameters, that tell whether they need to set and
> clear the PASID entry or only send the required TLB invalidations.
>
> * mm_detach(): detach an mm from a device. The IOMMU driver removes
> the PASID table entry and invalidates the IOTLBs.
>
> * mm_free(): free a structure allocated by mm_alloc(), and let arch
> release the process.
>
> mm_attach and mm_detach operations are serialized with a spinlock.
> When trying to optimize this code, we should at least prevent
> concurrent attach()/detach() on the same domain (so multi-level PASID
> table code can allocate tables lazily). mm_alloc() can sleep, but
> mm_free must not (because we'll have to call it from call_srcu later
> on).
>
> At the moment we use an IDR for allocating PASIDs and retrieving
> contexts. We also use a single spinlock. These can be refined and
> optimized later (a custom allocator will be needed for top-down PASID
> allocation).
>
> Keeping track of address spaces requires the use of MMU notifiers.
> Handling process exit with regard to unbind() is tricky, so it is
> left for another patch and we explicitly fail mm_alloc() for the
> moment.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
>
> ---
> v1->v2: sanity-check of flags
> ---
> drivers/iommu/iommu-sva.c | 380
> +++++++++++++++++++++++++++++++++++++- drivers/iommu/iommu.c |
> 1 + include/linux/iommu.h | 28 +++
> 3 files changed, 406 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> index 8d98f9c09864..6ac679c48f3c 100644
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@ -5,8 +5,298 @@
> * Copyright (C) 2018 ARM Ltd.
> */
>
> +#include <linux/idr.h>
> #include <linux/iommu.h>
> +#include <linux/sched/mm.h>
> #include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +/**
> + * DOC: io_mm model
> + *
> + * The io_mm keeps track of process address spaces shared between
> CPU and IOMMU.
> + * The following example illustrates the relation between structures
> + * iommu_domain, io_mm and iommu_bond. An iommu_bond is a link
> between io_mm and
> + * device. A device can have multiple io_mm and an io_mm may be
> bound to
> + * multiple devices.
> + * ___________________________
> + * | IOMMU domain A |
> + * | ________________ |
> + * | | IOMMU group | +------- io_pgtables
> + * | | | |
> + * | | dev 00:00.0 ----+------- bond --- io_mm X
> + * | |________________| \ |
> + * | '----- bond ---.
> + * |___________________________| \
> + * ___________________________ \
> + * | IOMMU domain B | io_mm Y
> + * | ________________ | / /
> + * | | IOMMU group | | / /
> + * | | | | / /
> + * | | dev 00:01.0 ------------ bond -' /
> + * | | dev 00:01.1 ------------ bond --'
> + * | |________________| |
> + * | +------- io_pgtables
> + * |___________________________|
> + *
> + * In this example, device 00:00.0 is in domain A, devices 00:01.*
> are in domain
> + * B. All devices within the same domain access the same address
> spaces. Device
> + * 00:00.0 accesses address spaces X and Y, each corresponding to an
> mm_struct.
> + * Devices 00:01.* only access address space Y. In addition each
> + * IOMMU_DOMAIN_DMA domain has a private address space, io_pgtable,
> that is
> + * managed with iommu_map()/iommu_unmap(), and isn't shared with the
> CPU MMU.
> + *
> + * To obtain the above configuration, users would for instance issue
> the
> + * following calls:
> + *
> + * iommu_sva_bind_device(dev 00:00.0, mm X, ...) -> PASID 1
> + * iommu_sva_bind_device(dev 00:00.0, mm Y, ...) -> PASID 2
> + * iommu_sva_bind_device(dev 00:01.0, mm Y, ...) -> PASID 2
> + * iommu_sva_bind_device(dev 00:01.1, mm Y, ...) -> PASID 2
> + *
> + * A single Process Address Space ID (PASID) is allocated for each
> mm. In the
> + * example, devices use PASID 1 to read/write into address space X
> and PASID 2
> + * to read/write into address space Y.
> + *
> + * Hardware tables describing this configuration in the IOMMU would
> typically
> + * look like this:
> + *
> + * PASID tables
> + * of domain A
> + * .->+--------+
> + * / 0 | |-------> io_pgtable
> + * / +--------+
> + * Device tables / 1 | |-------> pgd X
> + * +--------+ / +--------+
> + * 00:00.0 | A |-' 2 | |--.
> + * +--------+ +--------+ \
> + * : : 3 | | \
> + * +--------+ +--------+ --> pgd Y
> + * 00:01.0 | B |--. /
> + * +--------+ \ |
> + * 00:01.1 | B |----+ PASID tables |
> + * +--------+ \ of domain B |
> + * '->+--------+ |
> + * 0 | |-- | --> io_pgtable
> + * +--------+ |
> + * 1 | | |
> + * +--------+ |
> + * 2 | |---'
> + * +--------+
> + * 3 | |
> + * +--------+
> + *
I am a little confused about domain vs. pasid relationship. If
each domain represents a address space, should there be a domain for
each pasid?
> + * With this model, a single call binds all devices in a given
> domain to an
> + * address space. Other devices in the domain will get the same bond
> implicitly.
> + * However, users must issue one bind() for each device, because
> IOMMUs may
> + * implement SVA differently. Furthermore, mandating one bind() per
> device
> + * allows the driver to perform sanity-checks on device capabilities.
> + *
> + * On Arm and AMD IOMMUs, entry 0 of the PASID table can be used to
> hold
> + * non-PASID translations. In this case PASID 0 is reserved and
> entry 0 points
> + * to the io_pgtable base. On Intel IOMMU, the io_pgtable base would
> be held in
> + * the device table and PASID 0 would be available to the allocator.
> + */
> +
> +struct iommu_bond {
> + struct io_mm *io_mm;
> + struct device *dev;
> + struct iommu_domain *domain;
> +
> + struct list_head mm_head;
> + struct list_head dev_head;
> + struct list_head domain_head;
> +
> + void *drvdata;
> +};
> +
> +/*
> + * Because we're using an IDR, PASIDs are limited to 31 bits (the
> sign bit is
> + * used for returning errors). In practice implementations will use
> at most 20
> + * bits, which is the PCI limit.
> + */
> +static DEFINE_IDR(iommu_pasid_idr);
> +
> +/*
> + * For the moment this is an all-purpose lock. It serializes
> + * access/modifications to bonds, access/modifications to the PASID
> IDR, and
> + * changes to io_mm refcount as well.
> + */
> +static DEFINE_SPINLOCK(iommu_sva_lock);
> +
> +static struct io_mm *
> +io_mm_alloc(struct iommu_domain *domain, struct device *dev,
> + struct mm_struct *mm, unsigned long flags)
> +{
> + int ret;
> + int pasid;
> + struct io_mm *io_mm;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + if (!domain->ops->mm_alloc || !domain->ops->mm_free)
> + return ERR_PTR(-ENODEV);
> +
> + io_mm = domain->ops->mm_alloc(domain, mm, flags);
> + if (IS_ERR(io_mm))
> + return io_mm;
> + if (!io_mm)
> + return ERR_PTR(-ENOMEM);
> +
> + /*
> + * The mm must not be freed until after the driver frees the
> io_mm
> + * (which may involve unpinning the CPU ASID for instance,
> requiring a
> + * valid mm struct.)
> + */
> + mmgrab(mm);
> +
> + io_mm->flags = flags;
> + io_mm->mm = mm;
> + io_mm->release = domain->ops->mm_free;
> + INIT_LIST_HEAD(&io_mm->devices);
> +
> + idr_preload(GFP_KERNEL);
> + spin_lock(&iommu_sva_lock);
> + pasid = idr_alloc(&iommu_pasid_idr, io_mm, param->min_pasid,
> + param->max_pasid + 1, GFP_ATOMIC);
> + io_mm->pasid = pasid;
> + spin_unlock(&iommu_sva_lock);
> + idr_preload_end();
> +
> + if (pasid < 0) {
> + ret = pasid;
> + goto err_free_mm;
> + }
> +
> + /* TODO: keep track of mm. For the moment, abort. */
> + ret = -ENOSYS;
> + spin_lock(&iommu_sva_lock);
> + idr_remove(&iommu_pasid_idr, io_mm->pasid);
> + spin_unlock(&iommu_sva_lock);
> +
> +err_free_mm:
> + domain->ops->mm_free(io_mm);
> + mmdrop(mm);
> +
> + return ERR_PTR(ret);
> +}
> +
> +static void io_mm_free(struct io_mm *io_mm)
> +{
> + struct mm_struct *mm = io_mm->mm;
> +
> + io_mm->release(io_mm);
> + mmdrop(mm);
> +}
> +
> +static void io_mm_release(struct kref *kref)
> +{
> + struct io_mm *io_mm;
> +
> + io_mm = container_of(kref, struct io_mm, kref);
> + WARN_ON(!list_empty(&io_mm->devices));
> +
> + idr_remove(&iommu_pasid_idr, io_mm->pasid);
> +
> + io_mm_free(io_mm);
> +}
> +
> +/*
> + * Returns non-zero if a reference to the io_mm was successfully
> taken.
> + * Returns zero if the io_mm is being freed and should not be used.
> + */
> +static int io_mm_get_locked(struct io_mm *io_mm)
> +{
> + if (io_mm)
> + return kref_get_unless_zero(&io_mm->kref);
> +
> + return 0;
> +}
> +
> +static void io_mm_put_locked(struct io_mm *io_mm)
> +{
> + kref_put(&io_mm->kref, io_mm_release);
> +}
> +
> +static void io_mm_put(struct io_mm *io_mm)
> +{
> + spin_lock(&iommu_sva_lock);
> + io_mm_put_locked(io_mm);
> + spin_unlock(&iommu_sva_lock);
> +}
> +
> +static int io_mm_attach(struct iommu_domain *domain, struct device
> *dev,
> + struct io_mm *io_mm, void *drvdata)
> +{
> + int ret;
> + bool attach_domain = true;
> + int pasid = io_mm->pasid;
> + struct iommu_bond *bond, *tmp;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + if (!domain->ops->mm_attach || !domain->ops->mm_detach)
> + return -ENODEV;
> +
> + if (pasid > param->max_pasid || pasid < param->min_pasid)
> + return -ERANGE;
> +
> + bond = kzalloc(sizeof(*bond), GFP_KERNEL);
> + if (!bond)
> + return -ENOMEM;
> +
> + bond->domain = domain;
> + bond->io_mm = io_mm;
> + bond->dev = dev;
> + bond->drvdata = drvdata;
> +
> + spin_lock(&iommu_sva_lock);
> + /*
> + * Check if this io_mm is already bound to the domain. In
> which case the
> + * IOMMU driver doesn't have to install the PASID table
> entry.
> + */
> + list_for_each_entry(tmp, &domain->mm_list, domain_head) {
> + if (tmp->io_mm == io_mm) {
> + attach_domain = false;
> + break;
> + }
> + }
> +
> + ret = domain->ops->mm_attach(domain, dev, io_mm,
> attach_domain);
> + if (ret) {
> + kfree(bond);
> + spin_unlock(&iommu_sva_lock);
> + return ret;
> + }
> +
> + list_add(&bond->mm_head, &io_mm->devices);
> + list_add(&bond->domain_head, &domain->mm_list);
> + list_add(&bond->dev_head, ¶m->mm_list);
> + spin_unlock(&iommu_sva_lock);
> +
> + return 0;
> +}
> +
> +static void io_mm_detach_locked(struct iommu_bond *bond)
> +{
> + struct iommu_bond *tmp;
> + bool detach_domain = true;
> + struct iommu_domain *domain = bond->domain;
> +
> + list_for_each_entry(tmp, &domain->mm_list, domain_head) {
> + if (tmp->io_mm == bond->io_mm && tmp->dev !=
> bond->dev) {
> + detach_domain = false;
> + break;
> + }
> + }
> +
> + domain->ops->mm_detach(domain, bond->dev, bond->io_mm,
> detach_domain); +
> + list_del(&bond->mm_head);
> + list_del(&bond->domain_head);
> + list_del(&bond->dev_head);
> + io_mm_put_locked(bond->io_mm);
> +
> + kfree(bond);
> +}
>
> /**
> * iommu_sva_device_init() - Initialize Shared Virtual Addressing
> for a device @@ -47,6 +337,7 @@ int iommu_sva_device_init(struct
> device *dev, unsigned long features,
> param->features = features;
> param->max_pasid = max_pasid;
> + INIT_LIST_HEAD(¶m->mm_list);
>
> /*
> * IOMMU driver updates the limits depending on the IOMMU
> and device @@ -114,13 +405,87 @@
> EXPORT_SYMBOL_GPL(iommu_sva_device_shutdown); int
> __iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, int
> *pasid, unsigned long flags, void *drvdata) {
> - return -ENOSYS; /* TODO */
> + int i, ret = 0;
> + struct io_mm *io_mm = NULL;
> + struct iommu_domain *domain;
> + struct iommu_bond *bond = NULL, *tmp;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + domain = iommu_get_domain_for_dev(dev);
> + if (!domain)
> + return -EINVAL;
> +
> + /*
> + * The device driver does not call sva_device_init/shutdown
> and
> + * bind/unbind concurrently, so no need to take the param
> lock.
> + */
> + if (WARN_ON_ONCE(!param) || (flags & ~param->features))
> + return -EINVAL;
> +
> + /* If an io_mm already exists, use it */
> + spin_lock(&iommu_sva_lock);
> + idr_for_each_entry(&iommu_pasid_idr, io_mm, i) {
> + if (io_mm->mm == mm && io_mm_get_locked(io_mm)) {
> + /* ... Unless it's already bound to this
> device */
> + list_for_each_entry(tmp, &io_mm->devices,
> mm_head) {
> + if (tmp->dev == dev) {
> + bond = tmp;
> + io_mm_put_locked(io_mm);
> + break;
> + }
> + }
> + break;
> + }
> + }
> + spin_unlock(&iommu_sva_lock);
> +
> + if (bond)
> + return -EEXIST;
> +
> + /* Require identical features within an io_mm for now */
> + if (io_mm && (flags != io_mm->flags)) {
> + io_mm_put(io_mm);
> + return -EDOM;
> + }
> +
> + if (!io_mm) {
> + io_mm = io_mm_alloc(domain, dev, mm, flags);
> + if (IS_ERR(io_mm))
> + return PTR_ERR(io_mm);
> + }
> +
> + ret = io_mm_attach(domain, dev, io_mm, drvdata);
> + if (ret)
> + io_mm_put(io_mm);
> + else
> + *pasid = io_mm->pasid;
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(__iommu_sva_bind_device);
>
> int __iommu_sva_unbind_device(struct device *dev, int pasid)
> {
> - return -ENOSYS; /* TODO */
> + int ret = -ESRCH;
> + struct iommu_domain *domain;
> + struct iommu_bond *bond = NULL;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + domain = iommu_get_domain_for_dev(dev);
> + if (!param || WARN_ON(!domain))
> + return -EINVAL;
> +
> + spin_lock(&iommu_sva_lock);
> + list_for_each_entry(bond, ¶m->mm_list, dev_head) {
> + if (bond->io_mm->pasid == pasid) {
> + io_mm_detach_locked(bond);
> + ret = 0;
> + break;
> + }
> + }
> + spin_unlock(&iommu_sva_lock);
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(__iommu_sva_unbind_device);
>
> @@ -132,6 +497,15 @@ EXPORT_SYMBOL_GPL(__iommu_sva_unbind_device);
> */
> void __iommu_sva_unbind_dev_all(struct device *dev)
> {
> - /* TODO */
> + struct iommu_sva_param *param;
> + struct iommu_bond *bond, *next;
> +
> + param = dev->iommu_param->sva_param;
> + if (param) {
> + spin_lock(&iommu_sva_lock);
> + list_for_each_entry_safe(bond, next,
> ¶m->mm_list, dev_head)
> + io_mm_detach_locked(bond);
> + spin_unlock(&iommu_sva_lock);
> + }
> }
> EXPORT_SYMBOL_GPL(__iommu_sva_unbind_dev_all);
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index bd2819deae5b..333801e1519c 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1463,6 +1463,7 @@ static struct iommu_domain
> *__iommu_domain_alloc(struct bus_type *bus, domain->type = type;
> /* Assume all sizes by default; the driver may override this
> later */ domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap;
> + INIT_LIST_HEAD(&domain->mm_list);
>
> return domain;
> }
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index da59c20c4f12..d5f21719a5a0 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -100,6 +100,20 @@ struct iommu_domain {
> void *handler_token;
> struct iommu_domain_geometry geometry;
> void *iova_cookie;
> +
> + struct list_head mm_list;
> +};
> +
> +struct io_mm {
> + int pasid;
> + /* IOMMU_SVA_FEAT_* */
> + unsigned long flags;
> + struct list_head devices;
> + struct kref kref;
> + struct mm_struct *mm;
> +
> + /* Release callback for this mm */
> + void (*release)(struct io_mm *io_mm);
> };
>
> enum iommu_cap {
> @@ -216,6 +230,7 @@ struct iommu_sva_param {
> unsigned long features;
> unsigned int min_pasid;
> unsigned int max_pasid;
> + struct list_head mm_list;
> };
>
> /**
> @@ -227,6 +242,11 @@ struct iommu_sva_param {
> * @detach_dev: detach device from an iommu domain
> * @sva_device_init: initialize Shared Virtual Adressing for a device
> * @sva_device_shutdown: shutdown Shared Virtual Adressing for a
> device
> + * @mm_alloc: allocate io_mm
> + * @mm_free: free io_mm
> + * @mm_attach: attach io_mm to a device. Install PASID entry if
> necessary
> + * @mm_detach: detach io_mm from a device. Remove PASID entry and
> + * flush associated TLB entries.
> * @map: map a physically contiguous memory region to an iommu domain
> * @unmap: unmap a physically contiguous memory region from an iommu
> domain
> * @map_sg: map a scatter-gather list of physically contiguous
> memory chunks @@ -268,6 +288,14 @@ struct iommu_ops {
> struct iommu_sva_param *param);
> void (*sva_device_shutdown)(struct device *dev,
> struct iommu_sva_param *param);
> + struct io_mm *(*mm_alloc)(struct iommu_domain *domain,
> + struct mm_struct *mm,
> + unsigned long flags);
> + void (*mm_free)(struct io_mm *io_mm);
> + int (*mm_attach)(struct iommu_domain *domain, struct device
> *dev,
> + struct io_mm *io_mm, bool attach_domain);
> + void (*mm_detach)(struct iommu_domain *domain, struct device
> *dev,
> + struct io_mm *io_mm, bool detach_domain);
> int (*map)(struct iommu_domain *domain, unsigned long iova,
> phys_addr_t paddr, size_t size, int prot);
> size_t (*unmap)(struct iommu_domain *domain, unsigned long
> iova,
[Jacob Pan]
^ permalink raw reply
* [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware
From: Brian Norris @ 2018-05-16 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526354560-23135-4-git-send-email-hl@rock-chips.com>
On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
>
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow Sean suggest
>
> drivers/gpu/drm/rockchip/Makefile | 3 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 ++++++++++++++++++++++++
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> 6 files changed, 505 insertions(+), 13 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
Please rerun checkpatch next time. You've got a bunch of whitespace
issues in cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link().
Brian
^ permalink raw reply
* linux-next: manual merge of the renesas tree with the mvebu tree
From: Stephen Rothwell @ 2018-05-16 22:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the renesas tree got a conflict in:
arch/arm/configs/multi_v7_defconfig
between commit:
873edb2930ef ("ARM: multi_v7_defconfig: Update with current configuration")
from the mvebu tree and commits:
57eec170e954 ("ARM: multi_v7_defconfig: Disable CONFIG_FB_SH_MOBILE_MERAM")
eedd7902366b ("ARM: multi_v7_defconfig: Enable RENESAS_WDT")
from the renesas tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/configs/multi_v7_defconfig
index 8bcf3be58047,374a40945b0f..000000000000
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@@ -463,23 -489,20 +464,24 @@@ CONFIG_XILINX_WATCHDOG=
CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_AT91SAM9X_WATCHDOG=y
CONFIG_SAMA5D4_WATCHDOG=y
+CONFIG_DW_WATCHDOG=y
+CONFIG_DAVINCI_WATCHDOG=m
CONFIG_ORION_WATCHDOG=y
CONFIG_RN5T618_WATCHDOG=y
-CONFIG_ST_LPC_WATCHDOG=y
CONFIG_SUNXI_WATCHDOG=y
CONFIG_IMX2_WDT=y
+CONFIG_ST_LPC_WATCHDOG=y
CONFIG_TEGRA_WATCHDOG=m
CONFIG_MESON_WATCHDOG=y
-CONFIG_DW_WATCHDOG=y
CONFIG_DIGICOLOR_WATCHDOG=y
+ CONFIG_RENESAS_WDT=m
-CONFIG_BCM2835_WDT=y
CONFIG_BCM47XX_WDT=y
-CONFIG_BCM7038_WDT=m
+CONFIG_BCM2835_WDT=y
CONFIG_BCM_KONA_WDT=y
+CONFIG_BCM7038_WDT=m
+CONFIG_BCMA_HOST_SOC=y
+CONFIG_BCMA_DRIVER_GMAC_CMN=y
+CONFIG_BCMA_DRIVER_GPIO=y
CONFIG_MFD_ACT8945A=y
CONFIG_MFD_AS3711=y
CONFIG_MFD_AS3722=y
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/3abedbbc/attachment.sig>
^ permalink raw reply
* linux-next: manual merge of the mvebu tree with the arm-soc tree
From: Stephen Rothwell @ 2018-05-16 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the mvebu tree got a conflict in:
arch/arm/configs/multi_v7_defconfig
between various commits from the arm-soc tree and commit:
873edb2930ef ("ARM: multi_v7_defconfig: Update with current configuration")
from the mvebu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/configs/multi_v7_defconfig
index 0c7abc87f01a,2b008248fb52..000000000000
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@@ -169,26 -153,14 +153,16 @@@ CONFIG_IPV6_MIP6=
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_NET_DSA=m
- CONFIG_NET_SWITCHDEV=y
CONFIG_CAN=y
- CONFIG_CAN_RAW=y
- CONFIG_CAN_BCM=y
- CONFIG_CAN_DEV=y
CONFIG_CAN_AT91=m
CONFIG_CAN_FLEXCAN=m
- CONFIG_CAN_RCAR=m
+ CONFIG_CAN_SUN4I=y
CONFIG_CAN_XILINXCAN=y
+ CONFIG_CAN_RCAR=m
CONFIG_CAN_MCP251X=y
- CONFIG_NET_DSA_BCM_SF2=m
- CONFIG_B53=m
- CONFIG_B53_SPI_DRIVER=m
- CONFIG_B53_MDIO_DRIVER=m
- CONFIG_B53_MMAP_DRIVER=m
- CONFIG_B53_SRAB_DRIVER=m
- CONFIG_CAN_SUN4I=y
CONFIG_BT=m
+CONFIG_BT_HCIUART=m
+CONFIG_BT_HCIUART_BCM=y
CONFIG_BT_MRVL=m
CONFIG_BT_MRVL_SDIO=m
CONFIG_CFG80211=m
@@@ -272,17 -247,15 +249,16 @@@ CONFIG_DWMAC_DWC_QOS_ETH=
CONFIG_TI_CPSW=y
CONFIG_XILINX_EMACLITE=y
CONFIG_AT803X_PHY=y
- CONFIG_MARVELL_PHY=y
- CONFIG_SMSC_PHY=y
CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
- CONFIG_REALTEK_PHY=y
+ CONFIG_MARVELL_PHY=y
CONFIG_MICREL_PHY=y
- CONFIG_FIXED_PHY=y
+ CONFIG_REALTEK_PHY=y
CONFIG_ROCKCHIP_PHY=y
+ CONFIG_SMSC_PHY=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_RTL8152=m
+CONFIG_USB_LAN78XX=m
CONFIG_USB_USBNET=y
CONFIG_USB_NET_SMSC75XX=y
CONFIG_USB_NET_SMSC95XX=y
@@@ -363,13 -334,10 +337,11 @@@ CONFIG_SERIAL_ST_ASC=
CONFIG_SERIAL_ST_ASC_CONSOLE=y
CONFIG_SERIAL_STM32=y
CONFIG_SERIAL_STM32_CONSOLE=y
+CONFIG_SERIAL_DEV_BUS=y
- CONFIG_HVC_DRIVER=y
CONFIG_VIRTIO_CONSOLE=y
+ CONFIG_HW_RANDOM=y
+ CONFIG_HW_RANDOM_ST=y
CONFIG_I2C_CHARDEV=y
- CONFIG_I2C_DAVINCI=y
- CONFIG_I2C_MESON=y
- CONFIG_I2C_MUX=y
CONFIG_I2C_ARB_GPIO_CHALLENGE=m
CONFIG_I2C_MUX_PCA954x=y
CONFIG_I2C_MUX_PINCTRL=y
@@@ -381,8 -350,7 +354,8 @@@ CONFIG_I2C_DESIGNWARE_PLATFORM=
CONFIG_I2C_DIGICOLOR=m
CONFIG_I2C_EMEV2=m
CONFIG_I2C_GPIO=m
- CONFIG_I2C_EXYNOS5=y
CONFIG_I2C_IMX=y
++CONFIG_I2C_MESON=y
CONFIG_I2C_MV64XXX=y
CONFIG_I2C_RIIC=y
CONFIG_I2C_RK3X=y
@@@ -643,13 -602,17 +608,18 @@@ CONFIG_DRM_RCAR_LVDS=
CONFIG_DRM_SUN4I=m
CONFIG_DRM_FSL_DCU=m
CONFIG_DRM_TEGRA=y
+ CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_PANEL_SAMSUNG_LD9040=m
+CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03=m
CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
- CONFIG_DRM_PANEL_SIMPLE=y
+ CONFIG_DRM_DUMB_VGA_DAC=m
+ CONFIG_DRM_NXP_PTN3460=m
+ CONFIG_DRM_PARADE_PS8622=m
CONFIG_DRM_SII9234=m
+ CONFIG_DRM_I2C_ADV7511=m
+ CONFIG_DRM_I2C_ADV7511_AUDIO=y
CONFIG_DRM_STI=m
- CONFIG_DRM_VC4=y
+ CONFIG_DRM_VC4=m
CONFIG_DRM_ETNAVIV=m
CONFIG_DRM_MXSFB=m
CONFIG_FB_ARMCLCD=y
@@@ -953,8 -901,9 +908,10 @@@ CONFIG_PWM=
CONFIG_PWM_ATMEL=m
CONFIG_PWM_ATMEL_HLCDC_PWM=m
CONFIG_PWM_ATMEL_TCB=m
+ CONFIG_PWM_BCM2835=y
+ CONFIG_PWM_BRCMSTB=m
CONFIG_PWM_FSL_FTM=m
+CONFIG_PWM_MESON=m
CONFIG_PWM_RCAR=m
CONFIG_PWM_RENESAS_TPU=y
CONFIG_PWM_ROCKCHIP=m
@@@ -962,31 -912,25 +920,26 @@@ CONFIG_PWM_STI=
CONFIG_PWM_SUN4I=y
CONFIG_PWM_TEGRA=y
CONFIG_PWM_VT8500=y
+ CONFIG_KEYSTONE_IRQ=y
++CONFIG_PHY_STM32_USBPHYC=y
+ CONFIG_PHY_SUN4I_USB=y
+ CONFIG_PHY_SUN9I_USB=y
CONFIG_PHY_HIX5HD2_SATA=y
- CONFIG_E1000E=y
- CONFIG_PWM_STI=y
- CONFIG_PWM_BCM2835=y
- CONFIG_PWM_BRCMSTB=m
- CONFIG_PHY_DM816X_USB=m
- CONFIG_OMAP_USB2=y
- CONFIG_TI_PIPE3=y
- CONFIG_TWL4030_USB=m
+ CONFIG_PHY_BERLIN_SATA=y
CONFIG_PHY_BERLIN_USB=y
CONFIG_PHY_CPCAP_USB=m
- CONFIG_PHY_BERLIN_SATA=y
+ CONFIG_PHY_QCOM_APQ8064_SATA=m
+ CONFIG_PHY_RCAR_GEN2=m
CONFIG_PHY_ROCKCHIP_DP=m
CONFIG_PHY_ROCKCHIP_USB=y
- CONFIG_PHY_QCOM_APQ8064_SATA=m
+ CONFIG_PHY_SAMSUNG_USB2=m
CONFIG_PHY_MIPHY28LP=y
- CONFIG_PHY_RCAR_GEN2=m
CONFIG_PHY_STIH407_USB=y
- CONFIG_PHY_STM32_USBPHYC=y
- CONFIG_PHY_SUN4I_USB=y
- CONFIG_PHY_SUN9I_USB=y
- CONFIG_PHY_SAMSUNG_USB2=m
CONFIG_PHY_TEGRA_XUSB=y
- CONFIG_PHY_BRCM_SATA=y
- CONFIG_NVMEM=y
+ CONFIG_PHY_DM816X_USB=m
+ CONFIG_OMAP_USB2=y
+ CONFIG_TI_PIPE3=y
+ CONFIG_TWL4030_USB=m
CONFIG_NVMEM_IMX_OCOTP=y
CONFIG_NVMEM_SUNXI_SID=y
CONFIG_NVMEM_VF610_OCOTP=y
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/98b2243d/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Niklas Söderlund @ 2018-05-16 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526478129-16465-4-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your patch.
On 2018-05-16 15:42:09 +0200, Jacopo Mondi wrote:
> Describe HDMI input connector and ADV7612 HDMI decoder installed on
> R-Car Gen3 Draak board.
>
> The video signal routing to the HDMI decoder to the video input interface
> VIN4 is multiplexed with CVBS input path, and enabled/disabled through
> on-board switches SW-49, SW-50, SW-51 and SW-52.
>
> As the default board switches configuration connects CVBS input to VIN4,
> leave the HDMI decoder unconnected in DTS.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
I'm not sure we have a policy about describing hardware which can't be
used without flipping switches. I have no opinion on if we should do
that or not I leave that to others, but for the change itself.
Reviewed-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
I think it's good we describe it as it's part of the Draak board itself
and not an expansion board which we have seen a lot of :-) Maybe even
add a commented out line in the adv7612 port at 2 which hints which VIN
this is connected to if the switches are flipped?
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 38 ++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index 9aba28f..ea99dc9 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -59,6 +59,17 @@
> };
> };
>
> + hdmi-in {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&adv7612_in>;
> + };
> + };
> + };
> +
> memory at 48000000 {
> device_type = "memory";
> /* first 128MB is reserved for secure area. */
> @@ -170,6 +181,33 @@
> };
> };
> };
> +
> + hdmi-decoder at 4c {
> + compatible = "adi,adv7612";
> + reg = <0x4c>;
> + default-input = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + adv7612_in: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> + };
> +
> + port at 2 {
> + reg = <2>;
> + adv7612_out: endpoint {
> + pclk-sample = <0>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + };
> + };
> + };
> + };
> };
>
> &i2c1 {
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH v2 2/3] arm64: dts: renesas: draak: Describe CVBS input
From: Niklas Söderlund @ 2018-05-16 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526478129-16465-3-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your patch.
On 2018-05-16 15:42:08 +0200, Jacopo Mondi wrote:
> Describe CVBS video input through analog video decoder ADV7180
> connected to video input interface VIN4.
>
> The video input signal path is shared with HDMI video input, and
> selected by on-board switches SW-53 and SW-54 with CVBS input selected
> by the default switches configuration.
You are missing your SoB line :-)
Reviewed-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 36 ++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index d03f194..9aba28f 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -142,6 +142,11 @@
> groups = "usb0";
> function = "usb0";
> };
> +
> + vin4_pins_cvbs: vin4 {
> + groups = "vin4_data8", "vin4_sync", "vin4_clk";
> + function = "vin4";
> + };
> };
>
> &i2c0 {
> @@ -154,6 +159,17 @@
> reg = <0x50>;
> pagesize = <8>;
> };
> +
> + analog-video at 20 {
> + compatible = "adi,adv7180";
> + reg = <0x20>;
> +
> + port {
> + adv7180_out: endpoint {
> + remote-endpoint = <&vin4_in>;
> + };
> + };
> + };
> };
>
> &i2c1 {
> @@ -246,3 +262,23 @@
> timeout-sec = <60>;
> status = "okay";
> };
> +
> +&vin4 {
> + pinctrl-0 = <&vin4_pins_cvbs>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> +
> + vin4_in: endpoint {
> + remote-endpoint = <&adv7180_out>;
> + };
> + };
> + };
> +};
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ 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