* Re: [PATCH] power: reset: make reboot-mode user selectable
From: Sebastian Reichel @ 2019-09-03 0:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bartosz Golaszewski, Linux PM list, linux-kernel@vger.kernel.org,
Linux ARM, Nandor Han
In-Reply-To: <CAK8P3a3uNPepYweCN9+_cQNQyiSGdidwNGL0+xhti2vm8g9O_g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 604 bytes --]
Hi,
On Mon, Sep 02, 2019 at 11:16:27PM +0200, Arnd Bergmann wrote:
> On Mon, Sep 2, 2019 at 10:39 PM Sebastian Reichel <sre@kernel.org> wrote:
> > This patch does not look good to me. Better patch would be to
> > allow compiling CONFIG_REBOOT_MODE without CONFIG_OF. Obviously
> > the configuration would not be useful for anything except compile
> > testing, but that is also true for this patch.
>
> Ok, I'd suggest we leave it with the bugfix you already applied then.
> [caa2b55784, power: reset: nvmem-reboot-mode: add CONFIG_OF dependency]
That's also fine with me.
-- Sebastian
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clocksource: atmel-st: Variable sr in at91rm9200_timer_interrupt() could be uninitialized
From: Alexandre Belloni @ 2019-09-02 22:36 UTC (permalink / raw)
To: Yizhuo
Cc: csong, Daniel Lezcano, zhiyunq, linux-kernel, Ludovic Desroches,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190902222946.20548-1-yzhai003@ucr.edu>
On 02/09/2019 15:29:46-0700, Yizhuo wrote:
> Inside function at91rm9200_timer_interrupt(), variable sr could
> be uninitialized if regmap_read() fails. However, sr is used
Could you elaborate on how this could fail?
> to decide the control flow later in the if statement, which is
> potentially unsafe. We could check the return value of
> regmap_read() and print an error here.
>
> Signed-off-by: Yizhuo <yzhai003@ucr.edu>
> ---
> drivers/clocksource/timer-atmel-st.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/timer-atmel-st.c b/drivers/clocksource/timer-atmel-st.c
> index ab0aabfae5f0..061a3f27847e 100644
> --- a/drivers/clocksource/timer-atmel-st.c
> +++ b/drivers/clocksource/timer-atmel-st.c
> @@ -48,8 +48,14 @@ static inline unsigned long read_CRTR(void)
> static irqreturn_t at91rm9200_timer_interrupt(int irq, void *dev_id)
> {
> u32 sr;
> + int ret;
> +
> + ret = regmap_read(regmap_st, AT91_ST_SR, &sr);
> + if (ret) {
> + pr_err("Fail to read AT91_ST_SR.\n");
> + return ret;
> + }
>
> - regmap_read(regmap_st, AT91_ST_SR, &sr);
> sr &= irqmask;
>
> /*
> --
> 2.17.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] clocksource: atmel-st: Variable sr in at91rm9200_timer_interrupt() could be uninitialized
From: Yizhuo @ 2019-09-02 22:29 UTC (permalink / raw)
Cc: csong, Alexandre Belloni, Daniel Lezcano, zhiyunq, linux-kernel,
Yizhuo, Ludovic Desroches, Thomas Gleixner, linux-arm-kernel
Inside function at91rm9200_timer_interrupt(), variable sr could
be uninitialized if regmap_read() fails. However, sr is used
to decide the control flow later in the if statement, which is
potentially unsafe. We could check the return value of
regmap_read() and print an error here.
Signed-off-by: Yizhuo <yzhai003@ucr.edu>
---
drivers/clocksource/timer-atmel-st.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-atmel-st.c b/drivers/clocksource/timer-atmel-st.c
index ab0aabfae5f0..061a3f27847e 100644
--- a/drivers/clocksource/timer-atmel-st.c
+++ b/drivers/clocksource/timer-atmel-st.c
@@ -48,8 +48,14 @@ static inline unsigned long read_CRTR(void)
static irqreturn_t at91rm9200_timer_interrupt(int irq, void *dev_id)
{
u32 sr;
+ int ret;
+
+ ret = regmap_read(regmap_st, AT91_ST_SR, &sr);
+ if (ret) {
+ pr_err("Fail to read AT91_ST_SR.\n");
+ return ret;
+ }
- regmap_read(regmap_st, AT91_ST_SR, &sr);
sr &= irqmask;
/*
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] PCI: Move ATS declarations to linux/pci.h
From: Bjorn Helgaas @ 2019-09-02 21:38 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Krzysztof Wilczynski, linux-pci, Joerg Roedel, linux-kernel,
iommu, Kelsey Skunberg, Will Deacon, David Woodhouse,
linux-arm-kernel, Robin Murphy
In-Reply-To: <20190902211100.GH7013@google.com>
[+cc Kelsey]
On Mon, Sep 02, 2019 at 04:11:00PM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 30, 2019 at 09:18:40AM -0700, Christoph Hellwig wrote:
> > On Fri, Aug 30, 2019 at 05:07:56PM +0200, Krzysztof Wilczynski wrote:
> > > Move ATS function prototypes from include/linux/pci-ats.h to
> > > include/linux/pci.h so users only need to include <linux/pci.h>:
> >
> > Why is that so important? Very few PCI(e) device drivers use ATS,
> > so keeping it out of everyones include hell doesn't seem all bad.
>
> This was my idea, and it wasn't a good one, sorry.
>
> The ATS, PRI, and PASID interfaces are all sort of related and are
> used only by the IOMMU drivers, so it probably makes sense to put them
> all together. Right now the ATS stuff is in linux/pci.h and PRI/PASID
> stuff is in linux/pci-ats.h. Maybe the right thing would be to move
> the ATS stuff to pci-ats.h.
>
> I previously moved it from pci-ats.h to pci.h with ff9bee895c4d ("PCI:
> Move ATS declarations to linux/pci.h so they're all together") with
> the excuse of putting the external ATS interfaces next to
> pci_ats_init(). But that really looks like it was a mistake because
> pci_ats_init() is a PCI-internal thing and its declaration should
> probably be in drivers/pci/pci.h instead.
Never mind the pci_ats_init() part; Kelsey has already moved that:
https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?id=b92b512a435d
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 15/22] media: imx7-media-csi: Create media links in bound notifier
From: Steve Longerbeam @ 2019-09-02 21:37 UTC (permalink / raw)
To: Rui Miguel Silva
Cc: open list:STAGING SUBSYSTEM, Fabio Estevam,
Pengutronix Kernel Team, Greg Kroah-Hartman, Sascha Hauer,
open list, NXP Linux Team, Philipp Zabel, Mauro Carvalho Chehab,
Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-media
In-Reply-To: <m3blw35970.fsf@gmail.com>
Hi Rui,
On 9/2/19 2:38 AM, Rui Miguel Silva wrote:
> Hi Steve,
> On Tue 06 Aug 2019 at 00:34, Steve Longerbeam wrote:
>> Implement a notifier bound op to register media links from the remote
>> sub-device's source pad(s) to the CSI sink pad.
>>
>> Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com>
>> ---
>> drivers/staging/media/imx/imx7-media-csi.c | 24 ++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/drivers/staging/media/imx/imx7-media-csi.c b/drivers/staging/media/imx/imx7-media-csi.c
>> index a1c96c52a606..f71ac485f780 100644
>> --- a/drivers/staging/media/imx/imx7-media-csi.c
>> +++ b/drivers/staging/media/imx/imx7-media-csi.c
>> @@ -196,6 +196,11 @@ struct imx7_csi {
>> struct completion last_eof_completion;
>> };
>>
>> +static inline struct imx7_csi *notifier_to_dev(struct v4l2_async_notifier *n)
>>
> As the other one add the namespace for the function name:
> imx7_csi_notifier_to_dev
>
> other than this, looks good to me.
Thanks for the review. I will make those changes in next rev.
Steve
>
>
>> +{
>> + return container_of(n, struct imx7_csi, notifier);
>> +}
>> +
>> static u32 imx7_csi_reg_read(struct imx7_csi *csi, unsigned int offset)
>> {
>> return readl(csi->regbase + offset);
>> @@ -1173,6 +1178,23 @@ static int imx7_csi_parse_endpoint(struct device *dev,
>> return fwnode_device_is_available(asd->match.fwnode) ? 0 : -EINVAL;
>> }
>>
>> +static int imx7_csi_notify_bound(struct v4l2_async_notifier *notifier,
>> + struct v4l2_subdev *sd,
>> + struct v4l2_async_subdev *asd)
>> +{
>> + struct imx7_csi *csi = notifier_to_dev(notifier);
>> + struct media_pad *sink = &csi->sd.entity.pads[IMX7_CSI_PAD_SINK];
>> +
>> + return media_create_fwnode_pad_links(sink,
>> + dev_fwnode(csi->sd.dev),
>> + &sd->entity,
>> + dev_fwnode(sd->dev), 0);
>> +}
>> +
>> +static const struct v4l2_async_notifier_operations imx7_csi_notify_ops = {
>> + .bound = imx7_csi_notify_bound,
>> +};
>> +
>> static int imx7_csi_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> @@ -1253,6 +1275,8 @@ static int imx7_csi_probe(struct platform_device *pdev)
>>
>> v4l2_async_notifier_init(&csi->notifier);
>>
>> + csi->notifier.ops = &imx7_csi_notify_ops;
>> +
>> ret = v4l2_async_register_fwnode_subdev(&csi->sd, &csi->notifier,
>> sizeof(struct v4l2_async_subdev),
>> NULL, 0,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] ACPI: Support Generic Initiator only domains
From: Rafael J. Wysocki @ 2019-09-02 21:26 UTC (permalink / raw)
To: Jonathan Cameron, Dan Williams, Keith Busch
Cc: ACPI Devel Maling List, Rafael J . Wysocki,
Linux Kernel Mailing List, Linuxarm, Linux Memory Management List,
Jerome Glisse, Andrew Morton, Linux ARM
In-Reply-To: <20190821145242.2330-2-Jonathan.Cameron@huawei.com>
On Wed, Aug 21, 2019 at 4:53 PM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> Generic Initiators are a new ACPI concept that allows for the
> description of proximity domains that contain a device which
> performs memory access (such as a network card) but neither
> host CPU nor Memory.
>
> This patch has the parsing code and provides the infrastructure
> for an architecture to associate these new domains with their
> nearest memory processing node.
>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Dan, Keith, any comments?
AFAICS this clashes with the series from Dan that rearranges the ACPI
NUMA related code.
> ---
> drivers/acpi/numa.c | 62 +++++++++++++++++++++++++++++++++-
> drivers/base/node.c | 3 ++
> include/asm-generic/topology.h | 3 ++
> include/linux/nodemask.h | 1 +
> include/linux/topology.h | 7 ++++
> 5 files changed, 75 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> index eadbf90e65d1..fe34315a9234 100644
> --- a/drivers/acpi/numa.c
> +++ b/drivers/acpi/numa.c
> @@ -170,6 +170,38 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
> }
> break;
>
> + case ACPI_SRAT_TYPE_GENERIC_AFFINITY:
> + {
> + struct acpi_srat_generic_affinity *p =
> + (struct acpi_srat_generic_affinity *)header;
> + char name[9] = {};
> +
> + if (p->device_handle_type == 0) {
> + /*
> + * For pci devices this may be the only place they
> + * are assigned a proximity domain
> + */
> + pr_debug("SRAT Generic Initiator(Seg:%u BDF:%u) in proximity domain %d %s\n",
> + *(u16 *)(&p->device_handle[0]),
> + *(u16 *)(&p->device_handle[2]),
> + p->proximity_domain,
> + (p->flags & ACPI_SRAT_GENERIC_AFFINITY_ENABLED) ?
> + "enabled" : "disabled");
> + } else {
> + /*
> + * In this case we can rely on the device having a
> + * proximity domain reference
> + */
> + memcpy(name, p->device_handle, 8);
> + pr_info("SRAT Generic Initiator(HID=%.8s UID=%.4s) in proximity domain %d %s\n",
> + (char *)(&p->device_handle[0]),
> + (char *)(&p->device_handle[8]),
> + p->proximity_domain,
> + (p->flags & ACPI_SRAT_GENERIC_AFFINITY_ENABLED) ?
> + "enabled" : "disabled");
> + }
> + }
> + break;
> default:
> pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
> header->type);
> @@ -378,6 +410,32 @@ acpi_parse_gicc_affinity(union acpi_subtable_headers *header,
> return 0;
> }
>
> +static int __init
> +acpi_parse_gi_affinity(union acpi_subtable_headers *header,
> + const unsigned long end)
> +{
> + struct acpi_srat_generic_affinity *gi_affinity;
> + int node;
> +
> + gi_affinity = (struct acpi_srat_generic_affinity *)header;
> + if (!gi_affinity)
> + return -EINVAL;
> + acpi_table_print_srat_entry(&header->common);
> +
> + if (!(gi_affinity->flags & ACPI_SRAT_GENERIC_AFFINITY_ENABLED))
> + return -EINVAL;
> +
> + node = acpi_map_pxm_to_node(gi_affinity->proximity_domain);
> + if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
> + pr_err("SRAT: Too many proximity domains.\n");
> + return -EINVAL;
> + }
> + node_set(node, numa_nodes_parsed);
> + node_set_state(node, N_GENERIC_INITIATOR);
> +
> + return 0;
> +}
> +
> static int __initdata parsed_numa_memblks;
>
> static int __init
> @@ -433,7 +491,7 @@ int __init acpi_numa_init(void)
>
> /* SRAT: System Resource Affinity Table */
> if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
> - struct acpi_subtable_proc srat_proc[3];
> + struct acpi_subtable_proc srat_proc[4];
>
> memset(srat_proc, 0, sizeof(srat_proc));
> srat_proc[0].id = ACPI_SRAT_TYPE_CPU_AFFINITY;
> @@ -442,6 +500,8 @@ int __init acpi_numa_init(void)
> srat_proc[1].handler = acpi_parse_x2apic_affinity;
> srat_proc[2].id = ACPI_SRAT_TYPE_GICC_AFFINITY;
> srat_proc[2].handler = acpi_parse_gicc_affinity;
> + srat_proc[3].id = ACPI_SRAT_TYPE_GENERIC_AFFINITY;
> + srat_proc[3].handler = acpi_parse_gi_affinity;
>
> acpi_table_parse_entries_array(ACPI_SIG_SRAT,
> sizeof(struct acpi_table_srat),
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index 75b7e6f6535b..6f60689af5f8 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -980,6 +980,8 @@ static struct node_attr node_state_attr[] = {
> #endif
> [N_MEMORY] = _NODE_ATTR(has_memory, N_MEMORY),
> [N_CPU] = _NODE_ATTR(has_cpu, N_CPU),
> + [N_GENERIC_INITIATOR] = _NODE_ATTR(has_generic_initiator,
> + N_GENERIC_INITIATOR),
> };
>
> static struct attribute *node_state_attrs[] = {
> @@ -991,6 +993,7 @@ static struct attribute *node_state_attrs[] = {
> #endif
> &node_state_attr[N_MEMORY].attr.attr,
> &node_state_attr[N_CPU].attr.attr,
> + &node_state_attr[N_GENERIC_INITIATOR].attr.attr,
> NULL
> };
>
> diff --git a/include/asm-generic/topology.h b/include/asm-generic/topology.h
> index 238873739550..54d0b4176a45 100644
> --- a/include/asm-generic/topology.h
> +++ b/include/asm-generic/topology.h
> @@ -71,6 +71,9 @@
> #ifndef set_cpu_numa_mem
> #define set_cpu_numa_mem(cpu, node)
> #endif
> +#ifndef set_gi_numa_mem
> +#define set_gi_numa_mem(gi, node)
> +#endif
>
> #endif /* !CONFIG_NUMA || !CONFIG_HAVE_MEMORYLESS_NODES */
>
> diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
> index 27e7fa36f707..1aebf766fb52 100644
> --- a/include/linux/nodemask.h
> +++ b/include/linux/nodemask.h
> @@ -399,6 +399,7 @@ enum node_states {
> #endif
> N_MEMORY, /* The node has memory(regular, high, movable) */
> N_CPU, /* The node has one or more cpus */
> + N_GENERIC_INITIATOR, /* The node is a GI only node */
> NR_NODE_STATES
> };
>
> diff --git a/include/linux/topology.h b/include/linux/topology.h
> index 47a3e3c08036..2f97754e0508 100644
> --- a/include/linux/topology.h
> +++ b/include/linux/topology.h
> @@ -125,6 +125,13 @@ static inline void set_numa_mem(int node)
> }
> #endif
>
> +#ifndef set_gi_numa_mem
> +static inline void set_gi_numa_mem(int gi, int node)
> +{
> + _node_numa_mem_[gi] = node;
> +}
> +#endif
> +
> #ifndef node_to_mem_node
> static inline int node_to_mem_node(int node)
> {
> --
> 2.20.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] power: reset: make reboot-mode user selectable
From: Arnd Bergmann @ 2019-09-02 21:16 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Bartosz Golaszewski, Linux PM list, linux-kernel@vger.kernel.org,
Linux ARM, Nandor Han
In-Reply-To: <20190902203857.zusvlv3yv5arel6y@earth.universe>
On Mon, Sep 2, 2019 at 10:39 PM Sebastian Reichel <sre@kernel.org> wrote:
>
> This patch does not look good to me. Better patch would be to
> allow compiling CONFIG_REBOOT_MODE without CONFIG_OF. Obviously
> the configuration would not be useful for anything except compile
> testing, but that is also true for this patch.
Ok, I'd suggest we leave it with the bugfix you already applied then.
[caa2b55784, power: reset: nvmem-reboot-mode: add CONFIG_OF dependency]
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ACPI: support for NXP i2c controller
From: Andy Shevchenko @ 2019-09-02 21:16 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Wolfram Sang, Sascha Hauer, Udit Kumar, Rafael J. Wysocki,
Linux Kernel Mailing List, Leo Li, ACPI Devel Maling List,
Meenakshi Aggarwal, linux-i2c, Chuanhua Han, Shawn Guo, Linux ARM,
Len Brown
In-Reply-To: <CAJZ5v0hY2sL+XfN_4v07_hjvoxgCAt+Q89+wNg5Pky6XKP-mqA@mail.gmail.com>
On Mon, Sep 2, 2019 at 11:58 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Jul 11, 2019 at 12:35 PM Chuanhua Han <chuanhua.han@nxp.com> wrote:
> >
> > Enable NXP i2c controller to boot with ACPI
> >
> > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> > Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> > Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
>
> Wolfram, any objections to this from the i2c side?
May I propose amendment(s)?
> > @@ -44,6 +44,7 @@
> > #include <linux/pm_runtime.h>
> > #include <linux/sched.h>
> > #include <linux/slab.h>
> > +#include <linux/acpi.h>
If it's kept in order, better to go with it. (Yes, it is as I have checked)
However, property.h should be included instead, see below.
> > const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
> > &pdev->dev);
> > + const struct acpi_device_id *acpi_id =
> > + acpi_match_device(i2c_imx_acpi_ids,
> > + &pdev->dev);
> > if (of_id)
> > i2c_imx->hwdata = of_id->data;
> > + else if (acpi_id)
> > + i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> > + acpi_id->driver_data;
The above altogher may be replaced with
const struct imx_i2c_hwdata *match;
...
match = device_get_match_data(&pdev->dev);
if (match)
i2c_imx->hwdata = match;
else
...
> > + .acpi_match_table = ACPI_PTR(i2c_imx_acpi_ids),
Since there is no #ifdef guard no need to use ACPI_PTR().
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PCI: Move ATS declarations to linux/pci.h
From: Bjorn Helgaas @ 2019-09-02 21:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Krzysztof Wilczynski, linux-pci, Joerg Roedel, linux-kernel,
iommu, Will Deacon, David Woodhouse, linux-arm-kernel,
Robin Murphy
In-Reply-To: <20190830161840.GA9733@infradead.org>
On Fri, Aug 30, 2019 at 09:18:40AM -0700, Christoph Hellwig wrote:
> On Fri, Aug 30, 2019 at 05:07:56PM +0200, Krzysztof Wilczynski wrote:
> > Move ATS function prototypes from include/linux/pci-ats.h to
> > include/linux/pci.h so users only need to include <linux/pci.h>:
>
> Why is that so important? Very few PCI(e) device drivers use ATS,
> so keeping it out of everyones include hell doesn't seem all bad.
This was my idea, and it wasn't a good one, sorry.
The ATS, PRI, and PASID interfaces are all sort of related and are
used only by the IOMMU drivers, so it probably makes sense to put them
all together. Right now the ATS stuff is in linux/pci.h and PRI/PASID
stuff is in linux/pci-ats.h. Maybe the right thing would be to move
the ATS stuff to pci-ats.h.
I previously moved it from pci-ats.h to pci.h with ff9bee895c4d ("PCI:
Move ATS declarations to linux/pci.h so they're all together") with
the excuse of putting the external ATS interfaces next to
pci_ats_init(). But that really looks like it was a mistake because
pci_ats_init() is a PCI-internal thing and its declaration should
probably be in drivers/pci/pci.h instead.
There's also a useless "struct pci_ats" forward declaration in
linux/pci.h that I should have removed with d544d75ac96a ("PCI: Embed
ATS info directly into struct pci_dev").
Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ACPI: support for NXP i2c controller
From: Wolfram Sang @ 2019-09-02 21:02 UTC (permalink / raw)
To: Rafael J. Wysocki, Oleksij Rempel
Cc: Udit Kumar, Sascha Hauer, Rafael J. Wysocki,
Linux Kernel Mailing List, Leo Li, ACPI Devel Maling List,
Meenakshi Aggarwal, linux-i2c, Chuanhua Han, Shawn Guo, Linux ARM,
Len Brown
In-Reply-To: <CAJZ5v0hY2sL+XfN_4v07_hjvoxgCAt+Q89+wNg5Pky6XKP-mqA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4426 bytes --]
On Mon, Sep 02, 2019 at 10:56:22PM +0200, Rafael J. Wysocki wrote:
> On Thu, Jul 11, 2019 at 12:35 PM Chuanhua Han <chuanhua.han@nxp.com> wrote:
> >
> > Enable NXP i2c controller to boot with ACPI
> >
> > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> > Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> > Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
>
> Wolfram, any objections to this from the i2c side?
CCing the new maintainer of this driver...
>
> > ---
> > drivers/acpi/acpi_apd.c | 6 ++++++
> > drivers/i2c/busses/i2c-imx.c | 15 +++++++++++++++
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
> > index ff47317..cf8566c 100644
> > --- a/drivers/acpi/acpi_apd.c
> > +++ b/drivers/acpi/acpi_apd.c
> > @@ -165,6 +165,11 @@ static const struct apd_device_desc thunderx2_i2c_desc = {
> > .fixed_clk_rate = 125000000,
> > };
> >
> > +static const struct apd_device_desc nxp_i2c_desc = {
> > + .setup = acpi_apd_setup,
> > + .fixed_clk_rate = 350000000,
> > +};
> > +
> > static const struct apd_device_desc hip08_spi_desc = {
> > .setup = acpi_apd_setup,
> > .fixed_clk_rate = 250000000,
> > @@ -238,6 +243,7 @@ static const struct acpi_device_id acpi_apd_device_ids[] = {
> > { "HISI02A1", APD_ADDR(hip07_i2c_desc) },
> > { "HISI02A2", APD_ADDR(hip08_i2c_desc) },
> > { "HISI0173", APD_ADDR(hip08_spi_desc) },
> > + { "NXP0001", APD_ADDR(nxp_i2c_desc) },
> > #endif
> > { }
> > };
> > diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> > index b1b8b93..99f9b96 100644
> > --- a/drivers/i2c/busses/i2c-imx.c
> > +++ b/drivers/i2c/busses/i2c-imx.c
> > @@ -44,6 +44,7 @@
> > #include <linux/pm_runtime.h>
> > #include <linux/sched.h>
> > #include <linux/slab.h>
> > +#include <linux/acpi.h>
> >
> > /* This will be the driver name the kernel reports */
> > #define DRIVER_NAME "imx-i2c"
> > @@ -255,6 +256,12 @@ static const struct of_device_id i2c_imx_dt_ids[] = {
> > };
> > MODULE_DEVICE_TABLE(of, i2c_imx_dt_ids);
> >
> > +static const struct acpi_device_id i2c_imx_acpi_ids[] = {
> > + {"NXP0001", .driver_data = (kernel_ulong_t)&vf610_i2c_hwdata},
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(acpi, i2c_imx_acpi_ids);
> > +
> > static inline int is_imx1_i2c(struct imx_i2c_struct *i2c_imx)
> > {
> > return i2c_imx->hwdata->devtype == IMX1_I2C;
> > @@ -1052,6 +1059,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
> > {
> > const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
> > &pdev->dev);
> > + const struct acpi_device_id *acpi_id =
> > + acpi_match_device(i2c_imx_acpi_ids,
> > + &pdev->dev);
> > struct imx_i2c_struct *i2c_imx;
> > struct resource *res;
> > struct imxi2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
> > @@ -1079,6 +1089,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
> >
> > if (of_id)
> > i2c_imx->hwdata = of_id->data;
> > + else if (acpi_id)
> > + i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> > + acpi_id->driver_data;
> > else
> > i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> > platform_get_device_id(pdev)->driver_data;
> > @@ -1091,6 +1104,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
> > i2c_imx->adapter.nr = pdev->id;
> > i2c_imx->adapter.dev.of_node = pdev->dev.of_node;
> > i2c_imx->base = base;
> > + ACPI_COMPANION_SET(&i2c_imx->adapter.dev, ACPI_COMPANION(&pdev->dev));
> >
> > /* Get I2C clock */
> > i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
> > @@ -1253,6 +1267,7 @@ static struct platform_driver i2c_imx_driver = {
> > .name = DRIVER_NAME,
> > .pm = &i2c_imx_pm_ops,
> > .of_match_table = i2c_imx_dt_ids,
> > + .acpi_match_table = ACPI_PTR(i2c_imx_acpi_ids),
> > },
> > .id_table = imx_i2c_devtype,
> > };
> > --
> > 2.9.5
> >
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ACPI: support for NXP i2c controller
From: Rafael J. Wysocki @ 2019-09-02 20:56 UTC (permalink / raw)
To: Chuanhua Han, Wolfram Sang
Cc: Udit Kumar, Sascha Hauer, Rafael J. Wysocki,
Linux Kernel Mailing List, Leo Li, ACPI Devel Maling List,
Meenakshi Aggarwal, linux-i2c, Shawn Guo, Linux ARM, Len Brown
In-Reply-To: <20190711102601.20582-1-chuanhua.han@nxp.com>
On Thu, Jul 11, 2019 at 12:35 PM Chuanhua Han <chuanhua.han@nxp.com> wrote:
>
> Enable NXP i2c controller to boot with ACPI
>
> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
Wolfram, any objections to this from the i2c side?
> ---
> drivers/acpi/acpi_apd.c | 6 ++++++
> drivers/i2c/busses/i2c-imx.c | 15 +++++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
> index ff47317..cf8566c 100644
> --- a/drivers/acpi/acpi_apd.c
> +++ b/drivers/acpi/acpi_apd.c
> @@ -165,6 +165,11 @@ static const struct apd_device_desc thunderx2_i2c_desc = {
> .fixed_clk_rate = 125000000,
> };
>
> +static const struct apd_device_desc nxp_i2c_desc = {
> + .setup = acpi_apd_setup,
> + .fixed_clk_rate = 350000000,
> +};
> +
> static const struct apd_device_desc hip08_spi_desc = {
> .setup = acpi_apd_setup,
> .fixed_clk_rate = 250000000,
> @@ -238,6 +243,7 @@ static const struct acpi_device_id acpi_apd_device_ids[] = {
> { "HISI02A1", APD_ADDR(hip07_i2c_desc) },
> { "HISI02A2", APD_ADDR(hip08_i2c_desc) },
> { "HISI0173", APD_ADDR(hip08_spi_desc) },
> + { "NXP0001", APD_ADDR(nxp_i2c_desc) },
> #endif
> { }
> };
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index b1b8b93..99f9b96 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -44,6 +44,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> +#include <linux/acpi.h>
>
> /* This will be the driver name the kernel reports */
> #define DRIVER_NAME "imx-i2c"
> @@ -255,6 +256,12 @@ static const struct of_device_id i2c_imx_dt_ids[] = {
> };
> MODULE_DEVICE_TABLE(of, i2c_imx_dt_ids);
>
> +static const struct acpi_device_id i2c_imx_acpi_ids[] = {
> + {"NXP0001", .driver_data = (kernel_ulong_t)&vf610_i2c_hwdata},
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, i2c_imx_acpi_ids);
> +
> static inline int is_imx1_i2c(struct imx_i2c_struct *i2c_imx)
> {
> return i2c_imx->hwdata->devtype == IMX1_I2C;
> @@ -1052,6 +1059,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
> {
> const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
> &pdev->dev);
> + const struct acpi_device_id *acpi_id =
> + acpi_match_device(i2c_imx_acpi_ids,
> + &pdev->dev);
> struct imx_i2c_struct *i2c_imx;
> struct resource *res;
> struct imxi2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
> @@ -1079,6 +1089,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
>
> if (of_id)
> i2c_imx->hwdata = of_id->data;
> + else if (acpi_id)
> + i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> + acpi_id->driver_data;
> else
> i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> platform_get_device_id(pdev)->driver_data;
> @@ -1091,6 +1104,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
> i2c_imx->adapter.nr = pdev->id;
> i2c_imx->adapter.dev.of_node = pdev->dev.of_node;
> i2c_imx->base = base;
> + ACPI_COMPANION_SET(&i2c_imx->adapter.dev, ACPI_COMPANION(&pdev->dev));
>
> /* Get I2C clock */
> i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
> @@ -1253,6 +1267,7 @@ static struct platform_driver i2c_imx_driver = {
> .name = DRIVER_NAME,
> .pm = &i2c_imx_pm_ops,
> .of_match_table = i2c_imx_dt_ids,
> + .acpi_match_table = ACPI_PTR(i2c_imx_acpi_ids),
> },
> .id_table = imx_i2c_devtype,
> };
> --
> 2.9.5
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] iio: adc: meson_saradc: Fix memory allocation order
From: Elie Roudninski @ 2019-09-02 20:40 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Lars-Peter Clausen, Neil Armstrong, linux-iio, Kevin Hilman,
linux-kernel, Remi Pommarel, linux-arm-kernel,
Peter Meerwald-Stadler, Hartmut Knaack, linux-amlogic,
Jonathan Cameron
In-Reply-To: <CAFBinCD96nJBPnyNgWA6CgwE2kZrkXB3-cgbV9aQLB=JtbrN2w@mail.gmail.com>
On Sun, Sep 1, 2019 at 12:29 PM Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> On Sun, Sep 1, 2019 at 12:45 PM Remi Pommarel <repk@triplefau.lt> wrote:
> >
> > meson_saradc's irq handler uses priv->regmap so make sure that it is
> > allocated before the irq get enabled.
> >
> > This also fixes crash when CONFIG_DEBUG_SHIRQ is enabled, as device
> > managed resources are freed in the inverted order they had been
> > allocated, priv->regmap was freed before the spurious fake irq that
> > CONFIG_DEBUG_SHIRQ adds called the handler.
> >
>
> Fixes: 3af109131b7eb8 ("iio: adc: meson-saradc: switch from polling to
> interrupt mode")
> > Reported-by: Elie Roudninski <xademax@gmail.com>
> > Signed-off-by: Remi Pommarel <repk@triplefau.lt>
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> thank you for fixing this!
The patch fixed the kernel panic I had, i can now successfully boot my
meson-gxl-s905x-libretech-cc boad using patched linux 5.2.11
Tested-by: Elie ROUDNINSKI <xademax@gmail.com>
Elie
>
>
> Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] power: reset: make reboot-mode user selectable
From: Sebastian Reichel @ 2019-09-02 20:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bartosz Golaszewski, linux-pm, linux-kernel, linux-arm-kernel,
Nandor Han
In-Reply-To: <20190805075812.1056069-1-arnd@arndb.de>
[-- Attachment #1.1: Type: text/plain, Size: 5988 bytes --]
Hi Arnd and Nandor,
On Mon, Aug 05, 2019 at 09:57:15AM +0200, Arnd Bergmann wrote:
> Nandor Han points out that there might be drivers that can use
> the reboot-mode interfaces but might also be usable on configurations
> without device tree.
>
> Move the 'depends on OF' dependency into CONFIG_REBOOT_MODE since
> that is the only thing that truely has a compile-time dependency
> on CONFIG_OF, and make it user visible to make it possible to
> disable it.
>
> The drivers that used to 'select REBOOT_MODE' of course now have to
> use 'depends on REBOOT_MODE instead'. With this, we can soften the
> dependency and allow compile-testing the three front-end drivers
> on non-OF platforms.
>
> Note: anyone who was using a reboot mode driver in their kernel
> configuration now has to enable CONFIG_REBOOT_MODE as well.
>
> Suggested-by: Nandor Han <nandor.han@vaisala.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Nandor, this is so far untested, could you make sure this
> works in all configurations and forward it along with the
> bugfix?
>
> Sebastian, I'm not convinced this is a good idea, just sending
> it as Nandor requested. Please decide for yourself.
> ---
(Sorry for late reply)
This patch does not look good to me. Better patch would be to
allow compiling CONFIG_REBOOT_MODE without CONFIG_OF. Obviously
the configuration would not be useful for anything except compile
testing, but that is also true for this patch.
Making the small OF dependent section in reboot_mode_register()
would be a smaller patch with bigger test coverage, without
breakng existing configurations.
-- Sebastian
> arch/arm/configs/davinci_all_defconfig | 1 +
> arch/arm64/configs/defconfig | 1 +
> drivers/power/reset/Kconfig | 22 +++++++++++++---------
> include/linux/reboot-mode.h | 20 ++++++++++++++++++++
> 4 files changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
> index b34970ce6b31..ebf506c01899 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -139,6 +139,7 @@ CONFIG_GPIO_PCA953X_IRQ=y
> CONFIG_RESET_CONTROLLER=y
> CONFIG_POWER_RESET=y
> CONFIG_POWER_RESET_GPIO=y
> +CONFIG_REBOOT_MODE=m
> CONFIG_SYSCON_REBOOT_MODE=m
> CONFIG_BATTERY_LEGO_EV3=m
> CONFIG_WATCHDOG=y
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 0e58ef02880c..bb7d7bec1413 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -419,6 +419,7 @@ CONFIG_ROCKCHIP_IODOMAIN=y
> CONFIG_POWER_RESET_MSM=y
> CONFIG_POWER_RESET_XGENE=y
> CONFIG_POWER_RESET_SYSCON=y
> +CONFIG_REBOOT_MODE=y
> CONFIG_SYSCON_REBOOT_MODE=y
> CONFIG_BATTERY_SBS=m
> CONFIG_BATTERY_BQ27XXX=y
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index a564237278ff..997323d443f5 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -9,6 +9,13 @@ menuconfig POWER_RESET
>
> if POWER_RESET
>
> +config REBOOT_MODE
> + tristate "Pass reboot-mode to firmware"
> + depends on OF
> + help
> + Some drivers allow setting the reboot mode through a platform
> + interface that the boot firmware can read.
> +
> config POWER_RESET_AS3722
> bool "ams AS3722 power-off driver"
> depends on MFD_AS3722
> @@ -107,9 +114,9 @@ config POWER_RESET_MSM
>
> config POWER_RESET_QCOM_PON
> tristate "Qualcomm power-on driver"
> - depends on ARCH_QCOM
> + depends on ARCH_QCOM || COMPILE_TEST
> depends on MFD_SPMI_PMIC
> - select REBOOT_MODE
> + depends on REBOOT_MODE || !REBOOT_MODE
> help
> Power On support for Qualcomm boards.
> If you have a Qualcomm platform and need support for
> @@ -223,14 +230,11 @@ config POWER_RESET_ZX
> help
> Reboot support for ZTE SoCs.
>
> -config REBOOT_MODE
> - tristate
> -
> config SYSCON_REBOOT_MODE
> tristate "Generic SYSCON regmap reboot mode driver"
> - depends on OF
> + depends on OF || COMPILE_TEST
> depends on MFD_SYSCON
> - select REBOOT_MODE
> + depends on REBOOT_MODE || !REBOOT_MODE
> help
> Say y here will enable reboot mode driver. This will
> get reboot mode arguments and store it in SYSCON mapped
> @@ -248,8 +252,8 @@ config POWER_RESET_SC27XX
>
> config NVMEM_REBOOT_MODE
> tristate "Generic NVMEM reboot mode driver"
> - depends on OF
> - select REBOOT_MODE
> + depends on OF || COMPILE_TEST
> + depends on REBOOT_MODE || !REBOOT_MODE
> help
> Say y here will enable reboot mode driver. This will
> get reboot mode arguments and store it in a NVMEM cell,
> diff --git a/include/linux/reboot-mode.h b/include/linux/reboot-mode.h
> index 4a2abb38d1d6..bd002060e3d0 100644
> --- a/include/linux/reboot-mode.h
> +++ b/include/linux/reboot-mode.h
> @@ -9,11 +9,31 @@ struct reboot_mode_driver {
> struct notifier_block reboot_notifier;
> };
>
> +#if IS_ENABLED(CONFIG_REBOOT_MODE)
> int reboot_mode_register(struct reboot_mode_driver *reboot);
> int reboot_mode_unregister(struct reboot_mode_driver *reboot);
> int devm_reboot_mode_register(struct device *dev,
> struct reboot_mode_driver *reboot);
> void devm_reboot_mode_unregister(struct device *dev,
> struct reboot_mode_driver *reboot);
> +#else
> +static inline int reboot_mode_register(struct reboot_mode_driver *reboot)
> +{
> + return 0;
> +}
> +static inline int reboot_mode_unregister(struct reboot_mode_driver *reboot)
> +{
> + return 0;
> +}
> +static inline int devm_reboot_mode_register(struct device *dev,
> + struct reboot_mode_driver *reboot)
> +{
> + return 0;
> +}
> +static inline void devm_reboot_mode_unregister(struct device *dev,
> + struct reboot_mode_driver *reboot)
> +{
> +}
> +#endif
>
> #endif
> --
> 2.20.0
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mn-ddr4-evk: Enable GPIO LED
From: Pavel Machek @ 2019-09-02 20:31 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, shawnguo, s.hauer, linux-kernel,
robh+dt, Linux-imx, kernel, festevam, linux-arm-kernel
In-Reply-To: <1567457138-3002-1-git-send-email-Anson.Huang@nxp.com>
On Mon 2019-09-02 16:45:38, Anson Huang wrote:
> i.MX8MN DDR4 EVK board has a GPIO LED to indicate status,
> add support for it.
LED maintainers want to be on the cc list...
> @@ -15,6 +15,18 @@
> stdout-path = &uart2;
> };
>
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_led>;
> +
> + status {
> + label = "status";
> + gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
And we should really standardize labels for user-controlled status LEDs. Mentioning
color would be nice, for a start.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] ASoC: xlnx: add Xilinx logicPD-I2S FPGA IP support
From: Miquel Raynal @ 2019-09-02 20:21 UTC (permalink / raw)
To: Michal Simek
Cc: Mark Rutland, devicetree, alsa-devel,
Maruthi Srinivas Bayyavarapu, Takashi Iwai, Rob Herring,
Liam Girdwood, Mark Brown, Thomas Petazzoni, praveenv,
Jaroslav Kysela, alexandre, linux-arm-kernel
In-Reply-To: <df36fc2d-ed62-2556-513d-158a7707d5cd@xilinx.com>
Hi Michal,
Michal Simek <michal.simek@xilinx.com> wrote on Mon, 2 Sep 2019
09:39:11 +0200:
> Hi Miquel
>
> On 30. 08. 19 23:06, Miquel Raynal wrote:
> > This IP is very simple so this driver manage both the DAI and the PCM
> > streams, hence the presence of both components in this driver.
> >
> > There are plenty available interruptions when capturing or playing
> > back audio that can be triggered but the only one that fits the ALSA
> > sound system is the XFER_DONE which is used to bound sound
> > periods. Other interrupts are masked. Please note that capture and
> > playback are not possible at the same time though.
> >
> > Capture seems to work (at least it creates a file with something
> > inside) but I have no capture mechanism on the board to actually test
> > that it works correctly.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> >
> > Hello,
> >
> > This is my first contribution in the sound subsystem, I hope I've
> > understood the core but I might be entirely wrong as well, so please
> > do not hesitate to be critical on my choices.
> >
> > Thanks,
> > Miquèl
> >
> > sound/soc/xilinx/Kconfig | 7 +
> > sound/soc/xilinx/Makefile | 2 +
> > sound/soc/xilinx/xlnx-logicpd-i2s.c | 468 ++++++++++++++++++++++++++++
>
> What IP is this?
> https://www.xilinx.com/products/intellectual-property/audio-i2s.html
>
> https://github.com/Xilinx/linux-xlnx/blob/master/sound/soc/xilinx/xlnx_i2s.c
>
> Anyway I am adding Praveen and Maruthi to take a look.
Actually I have been tricked by a datasheet with the wrong title: this
is a LogicPD IP, it is not from Xilinx. I will resubmit with a new
driver name/compatible and add the relevant people.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 6/6] pwm: atmel: implement .get_state()
From: Uwe Kleine-König @ 2019-09-02 20:06 UTC (permalink / raw)
To: Claudiu.Beznea
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, thierry.reding,
linux-arm-kernel
In-Reply-To: <8da4ef26-872f-beaf-b5cb-9d8cb93a2ce9@microchip.com>
Hello Claudiu,
On Wed, Aug 28, 2019 at 10:26:18AM +0000, Claudiu.Beznea@microchip.com wrote:
> On 24.08.2019 03:10, Uwe Kleine-König wrote:
> > External E-Mail
> > This function reads back the configured parameters from the hardware. As
> > .apply rounds down (mostly) I'm rounding up in .get_state() to achieve
> > that applying a state just read from hardware is a no-op.
>
> Since this read is only at probing, at least for the moment, and, as far as
Yes, up to now .get_state() is only called at probing time. There is a
patch series (by me) on the list that changes that. (Though I'm not
entirely sure this is a good idea. Will comment my doubts in that thread
later.)
> I remember, the idea w/ .get_state was to reflect in Linux the states of
> PWMs that were setup before Linux takes control (e.g. PWMs setup in
> bootloaders) I think it would no problem if it would be no-ops in this
> scenario.
IMHO it should be a no-op.
> In case of run-time state retrieval, pwm_get_state() should be
> enough. If one would get the state previously saved w/ this .get_state API
> he/she would change it, then it would apply the changes to the hardware. No
> changes of PWM state would be anyway skipped from the beginning, in
> pwm_apply_state() by this code:
>
> if (state->period == pwm->state.period &&
> state->duty_cycle == pwm->state.duty_cycle &&
> state->polarity == pwm->state.polarity &&
> state->enabled == pwm->state.enabled)
> return 0;
>
> But maybe I'm missing something.
There is a problem I want to solve generally, not only for the atmel driver.
For example I consider it "expected" that
s1 = pwm_get_state(pwm)
pwm_apply_state(pwm, s2)
pwm_apply_state(pwm, s1)
ends in the same configuration as it started. For that it is necessary
(even for the atmel driver with the guard you pointed out above) to
round up in .get_state if .apply rounds down.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] net: stmmac: dwmac-sun8i: Variable "val" in function sun8i_dwmac_set_syscon() could be uninitialized
From: David Miller @ 2019-09-02 18:48 UTC (permalink / raw)
To: yzhai003
Cc: csong, alexandre.torgue, netdev, zhiyunq, linux-kernel, mripard,
wens, joabreu, mcoquelin.stm32, peppe.cavallaro, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190831020049.6516-1-yzhai003@ucr.edu>
From: Yizhuo <yzhai003@ucr.edu>
Date: Fri, 30 Aug 2019 19:00:48 -0700
> In function sun8i_dwmac_set_syscon(), local variable "val" could
> be uninitialized if function regmap_field_read() returns -EINVAL.
> However, it will be used directly in the if statement, which
> is potentially unsafe.
>
> Signed-off-by: Yizhuo <yzhai003@ucr.edu>
Applied, thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm: fix page faults in do_alignment
From: Eric W. Biederman @ 2019-09-02 17:36 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: kstewart, gustavo, gregkh, linux-kernel, Jing Xiangfeng, linux-mm,
sakari.ailus, bhelgaas, tglx, linux-arm-kernel
In-Reply-To: <20190830222906.GH13294@shell.armlinux.org.uk>
Russell King - ARM Linux admin <linux@armlinux.org.uk> writes:
> On Fri, Aug 30, 2019 at 04:02:48PM -0500, Eric W. Biederman wrote:
>> Russell King - ARM Linux admin <linux@armlinux.org.uk> writes:
>>
>> > On Fri, Aug 30, 2019 at 02:45:36PM -0500, Eric W. Biederman wrote:
>> >> Russell King - ARM Linux admin <linux@armlinux.org.uk> writes:
>> >>
>> >> > On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
>> >> >> The function do_alignment can handle misaligned address for user and
>> >> >> kernel space. If it is a userspace access, do_alignment may fail on
>> >> >> a low-memory situation, because page faults are disabled in
>> >> >> probe_kernel_address.
>> >> >>
>> >> >> Fix this by using __copy_from_user stead of probe_kernel_address.
>> >> >>
>> >> >> Fixes: b255188 ("ARM: fix scheduling while atomic warning in alignment handling code")
>> >> >> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
>> >> >
>> >> > NAK.
>> >> >
>> >> > The "scheduling while atomic warning in alignment handling code" is
>> >> > caused by fixing up the page fault while trying to handle the
>> >> > mis-alignment fault generated from an instruction in atomic context.
>> >> >
>> >> > Your patch re-introduces that bug.
>> >>
>> >> And the patch that fixed scheduling while atomic apparently introduced a
>> >> regression. Admittedly a regression that took 6 years to track down but
>> >> still.
>> >
>> > Right, and given the number of years, we are trading one regression for
>> > a different regression. If we revert to the original code where we
>> > fix up, we will end up with people complaining about a "new" regression
>> > caused by reverting the previous fix. Follow this policy and we just
>> > end up constantly reverting the previous revert.
>> >
>> > The window is very small - the page in question will have had to have
>> > instructions read from it immediately prior to the handler being entered,
>> > and would have had to be made "old" before subsequently being unmapped.
>>
>> > Rather than excessively complicating the code and making it even more
>> > inefficient (as in your patch), we could instead retry executing the
>> > instruction when we discover that the page is unavailable, which should
>> > cause the page to be paged back in.
>>
>> My patch does not introduce any inefficiencies. It onlys moves the
>> check for user_mode up a bit. My patch did duplicate the code.
>>
>> > If the page really is unavailable, the prefetch abort should cause a
>> > SEGV to be raised, otherwise the re-execution should replace the page.
>> >
>> > The danger to that approach is we page it back in, and it gets paged
>> > back out before we're able to read the instruction indefinitely.
>>
>> I would think either a little code duplication or a function that looks
>> at user_mode(regs) and picks the appropriate kind of copy to do would be
>> the best way to go. Because what needs to happen in the two cases for
>> reading the instruction are almost completely different.
>
> That is what I mean. I'd prefer to avoid that with the large chunk of
> code. How about instead adding a local replacement for
> probe_kernel_address() that just sorts out the reading, rather than
> duplicating all the code to deal with thumb fixup.
So something like this should be fine?
Jing Xiangfeng can you test this please? I think this fixes your issue
but I don't currently have an arm development box where I could test this.
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 04b36436cbc0..b07d17ca0ae5 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -767,6 +767,23 @@ do_alignment_t32_to_handler(unsigned long *pinstr, struct pt_regs *regs,
return NULL;
}
+static inline unsigned long
+copy_instr(bool umode, void *dst, unsigned long instrptr, size_t size)
+{
+ unsigned long result;
+ if (umode) {
+ void __user *src = (void *)instrptr;
+ result = copy_from_user(dst, src, size);
+ } else {
+ void *src = (void *)instrptr;
+ result = probe_kernel_read(dst, src, size);
+ }
+ /* Convert short reads into -EFAULT */
+ if ((result >= 0) && (result < size))
+ result = -EFAULT;
+ return result;
+}
+
static int
do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
{
@@ -778,22 +795,24 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
u16 tinstr = 0;
int isize = 4;
int thumb2_32b = 0;
+ bool umode;
if (interrupts_enabled(regs))
local_irq_enable();
instrptr = instruction_pointer(regs);
+ umode = user_mode(regs);
if (thumb_mode(regs)) {
- u16 *ptr = (u16 *)(instrptr & ~1);
- fault = probe_kernel_address(ptr, tinstr);
+ unsigned long tinstrptr = instrptr & ~1;
+ fault = copy_instr(umode, &tinstr, tinstrptr, 2);
tinstr = __mem_to_opcode_thumb16(tinstr);
if (!fault) {
if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
IS_T32(tinstr)) {
/* Thumb-2 32-bit */
u16 tinst2 = 0;
- fault = probe_kernel_address(ptr + 1, tinst2);
+ fault = copy_instr(umode, &tinst2, tinstrptr + 2, 2);
tinst2 = __mem_to_opcode_thumb16(tinst2);
instr = __opcode_thumb32_compose(tinstr, tinst2);
thumb2_32b = 1;
@@ -803,7 +822,7 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
}
}
} else {
- fault = probe_kernel_address((void *)instrptr, instr);
+ fault = copy_instr(umode, &instr, instrptr, 4);
instr = __mem_to_opcode_arm(instr);
}
@@ -812,7 +831,7 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
goto bad_or_fault;
}
- if (user_mode(regs))
+ if (umode)
goto user;
ai_sys += 1;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arch: arm: reuse addr variable in pfn_valid
From: Clemens Gruber @ 2019-09-02 16:46 UTC (permalink / raw)
To: linux-arm-kernel
Cc: zhaoyang, Clemens Gruber, Mike Rapoport, linux-kernel,
Russell King
Avoid calling __pfn_to_phys twice.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: zhaoyang <huangzhaoyang@gmail.com>
Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
---
arch/arm/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 98e17388a563..a5fe2bdc76de 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -179,7 +179,7 @@ int pfn_valid(unsigned long pfn)
if (__phys_to_pfn(addr) != pfn)
return 0;
- return memblock_is_map_memory(__pfn_to_phys(pfn));
+ return memblock_is_map_memory(addr);
}
EXPORT_SYMBOL(pfn_valid);
#endif
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 0/4] ARM: multi_v7_defconfig: add audio support for stm32mp157a-dk1
From: Arnd Bergmann @ 2019-09-02 16:42 UTC (permalink / raw)
To: Olivier Moysan
Cc: Alexandre Torgue, Tony Lindgren, linux-kernel@vger.kernel.org,
Krzysztof Kozlowski, Yannick Fertre, Enric Balletbo i Serra,
Olof Johansson, Simon Horman, Fabrice Gasnier, linux-stm32,
Linux ARM, Marek Szyprowski
In-Reply-To: <1567440041-19220-1-git-send-email-olivier.moysan@st.com>
On Mon, Sep 2, 2019 at 6:01 PM Olivier Moysan <olivier.moysan@st.com> wrote:
>
> This patchset adds audio support for stm32mp157a-dk1 board.
>
> Olivier Moysan (4):
> ARM: multi_v7_defconfig: enable stm32 sai support
> ARM: multi_v7_defconfig: enable stm32 i2s support
> ARM: multi_v7_defconfig: enable cs42l51 codec support
> ARM: multi_v7_defconfig: enable audio graph card support
The changes are ok, and I expect Alexandre will pick them up and forward
to the soc tree.
However, I would prefer these to just be a single patch, as there is little
use in splitting the intended change up into one line per patch.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 01/11] PCI: designware-ep: Add multiple PFs support for DWC
From: Andrew Murray @ 2019-09-02 16:26 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, roy.zang, lorenzo.pieralisi, arnd, devicetree,
jingoohan1, zhiqiang.hou, linuxppc-dev, linux-pci, linux-kernel,
kishon, minghuan.Lian, robh+dt, gregkh, linux-arm-kernel,
gustavo.pimentel, leoyang.li, shawnguo, mingkai.hu
In-Reply-To: <20190902031716.43195-2-xiaowei.bao@nxp.com>
On Mon, Sep 02, 2019 at 11:17:06AM +0800, Xiaowei Bao wrote:
> Add multiple PFs support for DWC, different PF have different config space
> we use pf-offset property which get from the DTS to access the different pF
This needs to be updated as this no longer comes from the DT.
> config space.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
We're assuming:
- The offset address (func_offset) between PF's in the memory map can be
different between different DWC implementations. And also that it's
possible for DWC implementations to address PFs without using an offset.
- The current approach is preferable to adding DWC EP driver callbacks
for writing to the EP config space (e.g. a variant of dw_pcie_writew_dbi
that takes a func number).
I'm keen to hear feedback from Jingoo/Gustavo on this.
Thanks,
Andrew Murray
> ---
> v2:
> - Remove duplicate redundant code.
> - Reimplement the PF config space access way.
> v3:
> - Integrate duplicate code for func_select.
> - Move PCIE_ATU_FUNC_NUM(pf) (pf << 20) to ((pf) << 20).
> - Add the comments for func_conf_select function.
>
> drivers/pci/controller/dwc/pcie-designware-ep.c | 123 ++++++++++++++++--------
> drivers/pci/controller/dwc/pcie-designware.c | 59 ++++++++----
> drivers/pci/controller/dwc/pcie-designware.h | 18 +++-
> 3 files changed, 142 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index 65f4792..eb851c2 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -19,12 +19,26 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> pci_epc_linkup(epc);
> }
>
> -static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar,
> - int flags)
> +static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8 func_no)
> +{
> + unsigned int func_offset = 0;
> +
> + if (ep->ops->func_conf_select)
> + func_offset = ep->ops->func_conf_select(ep, func_no);
> +
> + return func_offset;
> +}
> +
> +static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8 func_no,
> + enum pci_barno bar, int flags)
> {
> u32 reg;
> + unsigned int func_offset = 0;
> + struct dw_pcie_ep *ep = &pci->ep;
> +
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
>
> - reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> + reg = func_offset + PCI_BASE_ADDRESS_0 + (4 * bar);
> dw_pcie_dbi_ro_wr_en(pci);
> dw_pcie_writel_dbi2(pci, reg, 0x0);
> dw_pcie_writel_dbi(pci, reg, 0x0);
> @@ -37,7 +51,12 @@ static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar,
>
> void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
> {
> - __dw_pcie_ep_reset_bar(pci, bar, 0);
> + u8 func_no, funcs;
> +
> + funcs = pci->ep.epc->max_functions;
> +
> + for (func_no = 0; func_no < funcs; func_no++)
> + __dw_pcie_ep_reset_bar(pci, func_no, bar, 0);
> }
>
> static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
> @@ -45,28 +64,31 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
> {
> struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + unsigned int func_offset = 0;
> +
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
>
> dw_pcie_dbi_ro_wr_en(pci);
> - dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid);
> - dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid);
> - dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid);
> - dw_pcie_writeb_dbi(pci, PCI_CLASS_PROG, hdr->progif_code);
> - dw_pcie_writew_dbi(pci, PCI_CLASS_DEVICE,
> + dw_pcie_writew_dbi(pci, func_offset + PCI_VENDOR_ID, hdr->vendorid);
> + dw_pcie_writew_dbi(pci, func_offset + PCI_DEVICE_ID, hdr->deviceid);
> + dw_pcie_writeb_dbi(pci, func_offset + PCI_REVISION_ID, hdr->revid);
> + dw_pcie_writeb_dbi(pci, func_offset + PCI_CLASS_PROG, hdr->progif_code);
> + dw_pcie_writew_dbi(pci, func_offset + PCI_CLASS_DEVICE,
> hdr->subclass_code | hdr->baseclass_code << 8);
> - dw_pcie_writeb_dbi(pci, PCI_CACHE_LINE_SIZE,
> + dw_pcie_writeb_dbi(pci, func_offset + PCI_CACHE_LINE_SIZE,
> hdr->cache_line_size);
> - dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_VENDOR_ID,
> + dw_pcie_writew_dbi(pci, func_offset + PCI_SUBSYSTEM_VENDOR_ID,
> hdr->subsys_vendor_id);
> - dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id);
> - dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN,
> + dw_pcie_writew_dbi(pci, func_offset + PCI_SUBSYSTEM_ID, hdr->subsys_id);
> + dw_pcie_writeb_dbi(pci, func_offset + PCI_INTERRUPT_PIN,
> hdr->interrupt_pin);
> dw_pcie_dbi_ro_wr_dis(pci);
>
> return 0;
> }
>
> -static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum pci_barno bar,
> - dma_addr_t cpu_addr,
> +static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, u8 func_no,
> + enum pci_barno bar, dma_addr_t cpu_addr,
> enum dw_pcie_as_type as_type)
> {
> int ret;
> @@ -79,7 +101,7 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum pci_barno bar,
> return -EINVAL;
> }
>
> - ret = dw_pcie_prog_inbound_atu(pci, free_win, bar, cpu_addr,
> + ret = dw_pcie_prog_inbound_atu(pci, func_no, free_win, bar, cpu_addr,
> as_type);
> if (ret < 0) {
> dev_err(pci->dev, "Failed to program IB window\n");
> @@ -92,7 +114,8 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum pci_barno bar,
> return 0;
> }
>
> -static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, phys_addr_t phys_addr,
> +static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, u8 func_no,
> + phys_addr_t phys_addr,
> u64 pci_addr, size_t size)
> {
> u32 free_win;
> @@ -104,8 +127,8 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, phys_addr_t phys_addr,
> return -EINVAL;
> }
>
> - dw_pcie_prog_outbound_atu(pci, free_win, PCIE_ATU_TYPE_MEM,
> - phys_addr, pci_addr, size);
> + dw_pcie_prog_ep_outbound_atu(pci, func_no, free_win, PCIE_ATU_TYPE_MEM,
> + phys_addr, pci_addr, size);
>
> set_bit(free_win, ep->ob_window_map);
> ep->outbound_addr[free_win] = phys_addr;
> @@ -121,7 +144,7 @@ static void dw_pcie_ep_clear_bar(struct pci_epc *epc, u8 func_no,
> enum pci_barno bar = epf_bar->barno;
> u32 atu_index = ep->bar_to_atu[bar];
>
> - __dw_pcie_ep_reset_bar(pci, bar, epf_bar->flags);
> + __dw_pcie_ep_reset_bar(pci, func_no, bar, epf_bar->flags);
>
> dw_pcie_disable_atu(pci, atu_index, DW_PCIE_REGION_INBOUND);
> clear_bit(atu_index, ep->ib_window_map);
> @@ -137,14 +160,20 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no,
> size_t size = epf_bar->size;
> int flags = epf_bar->flags;
> enum dw_pcie_as_type as_type;
> - u32 reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> + u32 reg;
> + unsigned int func_offset = 0;
> +
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
> +
> + reg = PCI_BASE_ADDRESS_0 + (4 * bar) + func_offset;
>
> if (!(flags & PCI_BASE_ADDRESS_SPACE))
> as_type = DW_PCIE_AS_MEM;
> else
> as_type = DW_PCIE_AS_IO;
>
> - ret = dw_pcie_ep_inbound_atu(ep, bar, epf_bar->phys_addr, as_type);
> + ret = dw_pcie_ep_inbound_atu(ep, func_no, bar,
> + epf_bar->phys_addr, as_type);
> if (ret)
> return ret;
>
> @@ -202,7 +231,7 @@ static int dw_pcie_ep_map_addr(struct pci_epc *epc, u8 func_no,
> struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>
> - ret = dw_pcie_ep_outbound_atu(ep, addr, pci_addr, size);
> + ret = dw_pcie_ep_outbound_atu(ep, func_no, addr, pci_addr, size);
> if (ret) {
> dev_err(pci->dev, "Failed to enable address\n");
> return ret;
> @@ -216,11 +245,14 @@ static int dw_pcie_ep_get_msi(struct pci_epc *epc, u8 func_no)
> struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> u32 val, reg;
> + unsigned int func_offset = 0;
>
> if (!ep->msi_cap)
> return -EINVAL;
>
> - reg = ep->msi_cap + PCI_MSI_FLAGS;
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
> +
> + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> val = dw_pcie_readw_dbi(pci, reg);
> if (!(val & PCI_MSI_FLAGS_ENABLE))
> return -EINVAL;
> @@ -235,11 +267,14 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 func_no, u8 interrupts)
> struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> u32 val, reg;
> + unsigned int func_offset = 0;
>
> if (!ep->msi_cap)
> return -EINVAL;
>
> - reg = ep->msi_cap + PCI_MSI_FLAGS;
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
> +
> + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> val = dw_pcie_readw_dbi(pci, reg);
> val &= ~PCI_MSI_FLAGS_QMASK;
> val |= (interrupts << 1) & PCI_MSI_FLAGS_QMASK;
> @@ -255,11 +290,14 @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
> struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> u32 val, reg;
> + unsigned int func_offset = 0;
>
> if (!ep->msix_cap)
> return -EINVAL;
>
> - reg = ep->msix_cap + PCI_MSIX_FLAGS;
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
> +
> + reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> val = dw_pcie_readw_dbi(pci, reg);
> if (!(val & PCI_MSIX_FLAGS_ENABLE))
> return -EINVAL;
> @@ -274,11 +312,14 @@ static int dw_pcie_ep_set_msix(struct pci_epc *epc, u8 func_no, u16 interrupts)
> struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> u32 val, reg;
> + unsigned int func_offset = 0;
>
> if (!ep->msix_cap)
> return -EINVAL;
>
> - reg = ep->msix_cap + PCI_MSIX_FLAGS;
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
> +
> + reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> val = dw_pcie_readw_dbi(pci, reg);
> val &= ~PCI_MSIX_FLAGS_QSIZE;
> val |= interrupts;
> @@ -365,6 +406,7 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> struct pci_epc *epc = ep->epc;
> unsigned int aligned_offset;
> + unsigned int func_offset = 0;
> u16 msg_ctrl, msg_data;
> u32 msg_addr_lower, msg_addr_upper, reg;
> u64 msg_addr;
> @@ -374,20 +416,22 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
> if (!ep->msi_cap)
> return -EINVAL;
>
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
> +
> /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> - reg = ep->msi_cap + PCI_MSI_FLAGS;
> + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> msg_ctrl = dw_pcie_readw_dbi(pci, reg);
> has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> - reg = ep->msi_cap + PCI_MSI_ADDRESS_LO;
> + reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_LO;
> msg_addr_lower = dw_pcie_readl_dbi(pci, reg);
> if (has_upper) {
> - reg = ep->msi_cap + PCI_MSI_ADDRESS_HI;
> + reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_HI;
> msg_addr_upper = dw_pcie_readl_dbi(pci, reg);
> - reg = ep->msi_cap + PCI_MSI_DATA_64;
> + reg = ep->msi_cap + func_offset + PCI_MSI_DATA_64;
> msg_data = dw_pcie_readw_dbi(pci, reg);
> } else {
> msg_addr_upper = 0;
> - reg = ep->msi_cap + PCI_MSI_DATA_32;
> + reg = ep->msi_cap + func_offset + PCI_MSI_DATA_32;
> msg_data = dw_pcie_readw_dbi(pci, reg);
> }
> aligned_offset = msg_addr_lower & (epc->mem->page_size - 1);
> @@ -406,11 +450,12 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
> }
>
> int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> - u16 interrupt_num)
> + u16 interrupt_num)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> struct pci_epc *epc = ep->epc;
> u16 tbl_offset, bir;
> + unsigned int func_offset = 0;
> u32 bar_addr_upper, bar_addr_lower;
> u32 msg_addr_upper, msg_addr_lower;
> u32 reg, msg_data, vec_ctrl;
> @@ -418,12 +463,14 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> void __iomem *msix_tbl;
> int ret;
>
> - reg = ep->msix_cap + PCI_MSIX_TABLE;
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
> +
> + reg = ep->msix_cap + func_offset + PCI_MSIX_TABLE;
> tbl_offset = dw_pcie_readl_dbi(pci, reg);
> bir = (tbl_offset & PCI_MSIX_TABLE_BIR);
> tbl_offset &= PCI_MSIX_TABLE_OFFSET;
>
> - reg = PCI_BASE_ADDRESS_0 + (4 * bir);
> + reg = PCI_BASE_ADDRESS_0 + func_offset + (4 * bir);
> bar_addr_upper = 0;
> bar_addr_lower = dw_pcie_readl_dbi(pci, reg);
> reg_u64 = (bar_addr_lower & PCI_BASE_ADDRESS_MEM_TYPE_MASK);
> @@ -559,13 +606,13 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> ep->epc = epc;
> epc_set_drvdata(epc, ep);
>
> - if (ep->ops->ep_init)
> - ep->ops->ep_init(ep);
> -
> ret = of_property_read_u8(np, "max-functions", &epc->max_functions);
> if (ret < 0)
> epc->max_functions = 1;
>
> + if (ep->ops->ep_init)
> + ep->ops->ep_init(ep);
> +
> ret = __pci_epc_mem_init(epc, ep->phys_base, ep->addr_size,
> ep->page_size);
> if (ret < 0) {
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> index 143cb6c..ede2e75 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -238,9 +238,10 @@ static void dw_pcie_writel_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg,
> dw_pcie_writel_atu(pci, offset + reg, val);
> }
>
> -static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> - int type, u64 cpu_addr,
> - u64 pci_addr, u32 size)
> +static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, u8 func_no,
> + int index, int type,
> + u64 cpu_addr, u64 pci_addr,
> + u32 size)
> {
> u32 retries, val;
>
> @@ -255,7 +256,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
> upper_32_bits(pci_addr));
> dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> - type);
> + type | PCIE_ATU_FUNC_NUM(func_no));
> dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> PCIE_ATU_ENABLE);
>
> @@ -274,8 +275,9 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> dev_err(pci->dev, "Outbound iATU is not being enabled\n");
> }
>
> -void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> - u64 cpu_addr, u64 pci_addr, u32 size)
> +static void __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8 func_no,
> + int index, int type, u64 cpu_addr,
> + u64 pci_addr, u32 size)
> {
> u32 retries, val;
>
> @@ -283,8 +285,8 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr);
>
> if (pci->iatu_unroll_enabled) {
> - dw_pcie_prog_outbound_atu_unroll(pci, index, type, cpu_addr,
> - pci_addr, size);
> + dw_pcie_prog_outbound_atu_unroll(pci, func_no, index, type,
> + cpu_addr, pci_addr, size);
> return;
> }
>
> @@ -300,7 +302,8 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> lower_32_bits(pci_addr));
> dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET,
> upper_32_bits(pci_addr));
> - dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type);
> + dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type |
> + PCIE_ATU_FUNC_NUM(func_no));
> dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
>
> /*
> @@ -317,6 +320,21 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> dev_err(pci->dev, "Outbound iATU is not being enabled\n");
> }
>
> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> + u64 cpu_addr, u64 pci_addr, u32 size)
> +{
> + __dw_pcie_prog_outbound_atu(pci, 0, index, type,
> + cpu_addr, pci_addr, size);
> +}
> +
> +void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> + int type, u64 cpu_addr, u64 pci_addr,
> + u32 size)
> +{
> + __dw_pcie_prog_outbound_atu(pci, func_no, index, type,
> + cpu_addr, pci_addr, size);
> +}
> +
> static u32 dw_pcie_readl_ib_unroll(struct dw_pcie *pci, u32 index, u32 reg)
> {
> u32 offset = PCIE_GET_ATU_INB_UNR_REG_OFFSET(index);
> @@ -332,8 +350,8 @@ static void dw_pcie_writel_ib_unroll(struct dw_pcie *pci, u32 index, u32 reg,
> dw_pcie_writel_atu(pci, offset + reg, val);
> }
>
> -static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index,
> - int bar, u64 cpu_addr,
> +static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, u8 func_no,
> + int index, int bar, u64 cpu_addr,
> enum dw_pcie_as_type as_type)
> {
> int type;
> @@ -355,8 +373,10 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index,
> return -EINVAL;
> }
>
> - dw_pcie_writel_ib_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1, type);
> + dw_pcie_writel_ib_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1, type |
> + PCIE_ATU_FUNC_NUM(func_no));
> dw_pcie_writel_ib_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> + PCIE_ATU_FUNC_NUM_MATCH_EN |
> PCIE_ATU_ENABLE |
> PCIE_ATU_BAR_MODE_ENABLE | (bar << 8));
>
> @@ -377,14 +397,15 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index,
> return -EBUSY;
> }
>
> -int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
> - u64 cpu_addr, enum dw_pcie_as_type as_type)
> +int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> + int bar, u64 cpu_addr,
> + enum dw_pcie_as_type as_type)
> {
> int type;
> u32 retries, val;
>
> if (pci->iatu_unroll_enabled)
> - return dw_pcie_prog_inbound_atu_unroll(pci, index, bar,
> + return dw_pcie_prog_inbound_atu_unroll(pci, func_no, index, bar,
> cpu_addr, as_type);
>
> dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT, PCIE_ATU_REGION_INBOUND |
> @@ -403,9 +424,11 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
> return -EINVAL;
> }
>
> - dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type);
> - dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE
> - | PCIE_ATU_BAR_MODE_ENABLE | (bar << 8));
> + dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type |
> + PCIE_ATU_FUNC_NUM(func_no));
> + dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE |
> + PCIE_ATU_FUNC_NUM_MATCH_EN |
> + PCIE_ATU_BAR_MODE_ENABLE | (bar << 8));
>
> /*
> * Make sure ATU enable takes effect before any subsequent config
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index 5a18e94..6aca0bb 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -71,9 +71,11 @@
> #define PCIE_ATU_TYPE_IO 0x2
> #define PCIE_ATU_TYPE_CFG0 0x4
> #define PCIE_ATU_TYPE_CFG1 0x5
> +#define PCIE_ATU_FUNC_NUM(pf) ((pf) << 20)
> #define PCIE_ATU_CR2 0x908
> #define PCIE_ATU_ENABLE BIT(31)
> #define PCIE_ATU_BAR_MODE_ENABLE BIT(30)
> +#define PCIE_ATU_FUNC_NUM_MATCH_EN BIT(19)
> #define PCIE_ATU_LOWER_BASE 0x90C
> #define PCIE_ATU_UPPER_BASE 0x910
> #define PCIE_ATU_LIMIT 0x914
> @@ -206,6 +208,14 @@ struct dw_pcie_ep_ops {
> int (*raise_irq)(struct dw_pcie_ep *ep, u8 func_no,
> enum pci_epc_irq_type type, u16 interrupt_num);
> const struct pci_epc_features* (*get_features)(struct dw_pcie_ep *ep);
> + /*
> + * Provide a method to implement the different func config space
> + * access for different platform, if different func have different
> + * offset, return the offset of func. if use write a register way
> + * return a 0, and implement code in callback function of platform
> + * driver.
> + */
> + unsigned int (*func_conf_select)(struct dw_pcie_ep *ep, u8 func_no);
> };
>
> struct dw_pcie_ep {
> @@ -277,8 +287,12 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci);
> void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> int type, u64 cpu_addr, u64 pci_addr,
> u32 size);
> -int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
> - u64 cpu_addr, enum dw_pcie_as_type as_type);
> +void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> + int type, u64 cpu_addr, u64 pci_addr,
> + u32 size);
> +int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> + int bar, u64 cpu_addr,
> + enum dw_pcie_as_type as_type);
> void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
> enum dw_pcie_region_type type);
> void dw_pcie_setup(struct dw_pcie *pci);
> --
> 2.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/4] ARM: multi_v7_defconfig: enable audio graph card support
From: Olivier Moysan @ 2019-09-02 16:00 UTC (permalink / raw)
To: alexandre.torgue, olof, horms+renesas, arnd, krzk, yannick.fertre,
tony, m.szyprowski, fabrice.gasnier, enric.balletbo,
linux-arm-kernel, linux-kernel, linux-stm32
Cc: olivier.moysan
In-Reply-To: <1567440041-19220-1-git-send-email-olivier.moysan@st.com>
Enable audio graph card support for stm32mp157a-dk1 board.
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 03a4d93df8c4..c7104a1c1687 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -719,6 +719,7 @@ CONFIG_SND_SOC_SGTL5000=m
CONFIG_SND_SOC_SPDIF=m
CONFIG_SND_SOC_STI_SAS=m
CONFIG_SND_SOC_WM8978=m
+CONFIG_SND_AUDIO_GRAPH_CARD=m
CONFIG_USB=y
CONFIG_USB_OTG=y
CONFIG_USB_XHCI_HCD=y
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/4] ARM: multi_v7_defconfig: add audio support for stm32mp157a-dk1
From: Olivier Moysan @ 2019-09-02 16:00 UTC (permalink / raw)
To: alexandre.torgue, olof, horms+renesas, arnd, krzk, yannick.fertre,
tony, m.szyprowski, fabrice.gasnier, enric.balletbo,
linux-arm-kernel, linux-kernel, linux-stm32
Cc: olivier.moysan
This patchset adds audio support for stm32mp157a-dk1 board.
Olivier Moysan (4):
ARM: multi_v7_defconfig: enable stm32 sai support
ARM: multi_v7_defconfig: enable stm32 i2s support
ARM: multi_v7_defconfig: enable cs42l51 codec support
ARM: multi_v7_defconfig: enable audio graph card support
arch/arm/configs/multi_v7_defconfig | 4 ++++
1 file changed, 4 insertions(+)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/4] ARM: multi_v7_defconfig: enable cs42l51 codec support
From: Olivier Moysan @ 2019-09-02 16:00 UTC (permalink / raw)
To: alexandre.torgue, olof, horms+renesas, arnd, krzk, yannick.fertre,
tony, m.szyprowski, fabrice.gasnier, enric.balletbo,
linux-arm-kernel, linux-kernel, linux-stm32
Cc: olivier.moysan
In-Reply-To: <1567440041-19220-1-git-send-email-olivier.moysan@st.com>
Enable Cirrus CS42L51 audio codec for stm32mp157a-dk1 board.
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 02265e195e50..03a4d93df8c4 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -714,6 +714,7 @@ CONFIG_SND_SOC_TEGRA_ALC5632=m
CONFIG_SND_SOC_TEGRA_MAX98090=m
CONFIG_SND_SOC_AK4642=m
CONFIG_SND_SOC_CPCAP=m
+CONFIG_SND_SOC_CS42L51_I2C=m
CONFIG_SND_SOC_SGTL5000=m
CONFIG_SND_SOC_SPDIF=m
CONFIG_SND_SOC_STI_SAS=m
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] ARM: multi_v7_defconfig: enable stm32 i2s support
From: Olivier Moysan @ 2019-09-02 16:00 UTC (permalink / raw)
To: alexandre.torgue, olof, horms+renesas, arnd, krzk, yannick.fertre,
tony, m.szyprowski, fabrice.gasnier, enric.balletbo,
linux-arm-kernel, linux-kernel, linux-stm32
Cc: olivier.moysan
In-Reply-To: <1567440041-19220-1-git-send-email-olivier.moysan@st.com>
Enable support for I2S on STM32MP1.
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 929d13842171..02265e195e50 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -700,6 +700,7 @@ CONFIG_SND_SOC_SH4_FSI=m
CONFIG_SND_SOC_RCAR=m
CONFIG_SND_SOC_STI=m
CONFIG_SND_SOC_STM32_SAI=m
+CONFIG_SND_SOC_STM32_I2S=m
CONFIG_SND_SUN4I_CODEC=m
CONFIG_SND_SOC_TEGRA=m
CONFIG_SND_SOC_TEGRA20_I2S=m
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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