* [GIT PULL 10/10] arm64: tegra: Default configuration updates for v4.10-rc1
From: Thierry Reding @ 2016-11-30 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6706502.us21ohNYZA@wuerfel>
On Wed, Nov 30, 2016 at 05:10:43PM +0100, Arnd Bergmann wrote:
> On Friday, November 18, 2016 5:17:19 PM CET Thierry Reding wrote:
> > arm64: tegra: Default configuration updates for v4.10-rc1
> >
> > Enable Tegra186 support.
> >
>
> This was already in next/arm64 (but I didn't see a notification),
> and with the arm64-dt branch now merged as well, we should have
> everything you sent.
I had also sent a couple of individual patches that seemed to not have
it made into v4.9 and v4.8 for some reason (they were part of the pull
requests, as far as I can tell). Do you think you could pull those in
as well?
Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/b14ea724/attachment.sig>
^ permalink raw reply
* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Robin Murphy @ 2016-11-30 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130161723.GA9042@red-moon>
On 30/11/16 16:17, Lorenzo Pieralisi wrote:
> Sricharan, Robin,
>
> I gave this series a go on ACPI and apart from an SMMU v3 fix-up
> it seems to work, more thorough testing required though.
>
> A key question below.
>
> On Wed, Nov 30, 2016 at 05:52:16AM +0530, Sricharan R wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> IOMMU configuration represents unchanging properties of the hardware,
>> and as such should only need happen once in a device's lifetime, but
>> the necessary interaction with the IOMMU device and driver complicates
>> exactly when that point should be.
>>
>> Since the only reasonable tool available for handling the inter-device
>> dependency is probe deferral, we need to prepare of_iommu_configure()
>> to run later than it is currently called (i.e. at driver probe rather
>> than device creation), to handle being retried, and to tell whether a
>> not-yet present IOMMU should be waited for or skipped (by virtue of
>> having declared a built-in driver or not).
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/of_iommu.c | 30 +++++++++++++++++++++++++++++-
>> 1 file changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index ee49081..349bd1d 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -104,12 +104,20 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
>> int err;
>>
>> ops = iommu_get_instance(fwnode);
>> - if (!ops || !ops->of_xlate)
>> + if ((ops && !ops->of_xlate) ||
>> + (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
>
> IIUC of_match_node() here is there to check there is a driver compiled
> in for this device_node (aka compatible string in OF world), correct ?
Yes - specifically, it's checking the magic table for a matching
IOMMU_OF_DECLARE entry.
> If that's the case (and I think that's what Sricharan was referring to
> in his ACPI query) I need to cook-up something on the ACPI side to
> emulate the OF linker table behaviour (or anyway to detect a driver is
> actually in the kernel), it is not that difficult but it is key to know,
> I will give it some thought to make it as clean as possible.
I didn't think this would be a concern for ACPI, since IORT works much
the same way the current of_iommu_init_fn/of_platform_device_create()
bodges in drivers so for DT. If you can only discover SMMUs from IORT,
then iort_init_platform_devices() will have already created every SMMU
that's going to exist before discovering other devices from wherever
they come from, thus you could never get into the situation of probing a
device without its SMMU being ready (if it's ever going to be). Is that
not right?
Robin.
>
> Thanks,
> Lorenzo
>
>> return NULL;
>>
>> err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
>> if (err)
>> return ERR_PTR(err);
>> + /*
>> + * The otherwise-empty fwspec handily serves to indicate the specific
>> + * IOMMU device we're waiting for, which will be useful if we ever get
>> + * a proper probe-ordering dependency mechanism in future.
>> + */
>> + if (!ops)
>> + return ERR_PTR(-EPROBE_DEFER);
>>
>> err = ops->of_xlate(dev, iommu_spec);
>> if (err)
>> @@ -186,14 +194,34 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>> struct device_node *master_np)
>> {
>> const struct iommu_ops *ops;
>> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
>>
>> if (!master_np)
>> return NULL;
>>
>> + if (fwspec) {
>> + if (fwspec->ops)
>> + return fwspec->ops;
>> +
>> + /* In the deferred case, start again from scratch */
>> + iommu_fwspec_free(dev);
>> + }
>> +
>> if (dev_is_pci(dev))
>> ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>> else
>> ops = of_platform_iommu_init(dev, master_np);
>> + /*
>> + * If we have reason to believe the IOMMU driver missed the initial
>> + * add_device callback for dev, replay it to get things in order.
>> + */
>> + if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
>> + dev->bus && !dev->iommu_group) {
>> + int err = ops->add_device(dev);
>> +
>> + if (err)
>> + ops = ERR_PTR(err);
>> + }
>>
>> return IS_ERR(ops) ? NULL : ops;
>> }
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>>
^ permalink raw reply
* [GIT PULL] ARM: keystone: add TI SCI protocol support for v4.10
From: Arnd Bergmann @ 2016-11-30 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d685444b-4275-e6e6-aae6-214a41776a28@ti.com>
On Monday, November 28, 2016 6:42:41 PM CET Tero Kristo wrote:
> Gentle ping on this, is anybody going to pull this one?
>
> -Tero
>
> On 27/10/16 12:30, Tero Kristo wrote:
> > Hi Arnd, Olof, Kevin,
> >
> > This pull introduces the TI SCI protocol support for keystone family of
> > devices, targeted for v4.10 merge window. We discussed with Santosh
> > (keystone maintainer) that it would probably be better that I'll be
> > sending the pull requests for this directly, avoiding one extra step of
> > merges.
>
Sorry for the delay. I just saw this pull request in the backlog
and had to take a closer look first. I probably would have commented
on a few details in a proper review, but overall this seems harmless
enough, so I've merged it into next/drivers in the end.
There was no branch description in
https://github.com/t-kristo/linux-pm.git for-4.10-ti-sci-base
and I ended up taking something from the wiki. This is now the
commit I ended up with:
commit ba9cb7b9ffa4a4056158bc8570f1a851e4a6a8ae
Merge: e7541f9 912cffb
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed Nov 30 17:13:13 2016 +0100
Merge branch 'for-4.10-ti-sci-base' of https://github.com/t-kristo/linux-pm into next/drivers
Merge "ARM: keystone: add TI SCI protocol support for v4.10" from
Tero Kristo:
[description taken from http://processors.wiki.ti.com/index.php/TISCI
Texas Instruments' Keystone generation System on Chips (SoC) starting
with 66AK2G02, now include a dedicated SoC System Control entity called
PMMC(Power Management Micro Controller) in line with ARM architecture
recommendations. The function of this module is to integrate all system
operations in a centralized location. Communication with the SoC System
Control entity from various processing units like ARM/DSP occurs over
Message Manager hardware block.
...
Texas Instruments' System Control Interface defines the communication
protocol between various processing entities to the System Control Entity
on TI SoCs. This is a set of message formats and sequence of operations
required to communicate and get system services processed from System
Control entity in the SoC.]
* 'for-4.10-ti-sci-base' of https://github.com/t-kristo/linux-pm:
firmware: ti_sci: Add support for reboot core service
firmware: ti_sci: Add support for Clock control
firmware: ti_sci: Add support for Device control
firmware: Add basic support for TI System Control Interface (TI-SCI) protocol
Documentation: Add support for TI System Control Interface (TI-SCI) protocol
Arnd
^ permalink raw reply
* [GIT PULL 1/6] Broadcom soc changes for 4.10
From: Arnd Bergmann @ 2016-11-30 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-1-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:19 PM CET Florian Fainelli wrote:
> This pull request contains Broadcom ARM-based SoC changes for 4.10, please pull
> the following:
>
> - Rafal adds back the abort handler hook on BCM5301x which is required to silence
> errors forwared from the PCIe controller that cannot be silenced at the PCIe RC level
>
Pulled into next/soc.
It's unclear to me whether we want this to be backported to stable kernels,
can you clarify?
Thanks,
Arnd
^ permalink raw reply
* [PATCH v2] soc: ti: qmss: fix the case when !SMP
From: Grygorii Strashko @ 2016-11-30 16:53 UTC (permalink / raw)
To: linux-arm-kernel
The irq_set_affinity_hint() will always fail when !SMP and
Networking will fail on Keystone 2 devices in this case.
Hence, fix by ignoring IRQ affinity settings when !SMP.
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/soc/ti/knav_qmss_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index b73e353..eacad57 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1228,7 +1228,7 @@ static int knav_setup_queue_range(struct knav_device *kdev,
range->num_irqs++;
- if (oirq.args_count == 3)
+ if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3)
range->irqs[i].cpu_map =
(oirq.args[2] & 0x0000ff00) >> 8;
}
--
2.10.1
^ permalink raw reply related
* [GIT PULL 2/6] Broadcom devicetree changes for 4.10
From: Arnd Bergmann @ 2016-11-30 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-2-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:20 PM CET Florian Fainelli wrote:
> This pull request contains Broadcom ARM-based SoC Device Tree changes for 4.10,
> please pull the following:
>
> - Rafal adds support for the Netgear R8500 routers, adds basic support
> for the Tenda AC9 router which uses the new BCM53573 SoC (single core Cortex
> A7). He also enables the UART on the Netgear R8000 and restructures the
> include files a bit for the BCM47094 SoC, finally he adds USB 3.0 PHY nodes
> which enables USB 3.0 on BCM5301X devices that support it. Finally he adds
> support for the TP-LINK Archer C9 V1 router.
>
> - Kamal adds support for the QSPI controller on the Northstar Plus SoCs and updates
> the bcm958625k reference board to have it enabled
>
> - Dan adds support for the Luxul XAP-1510 (using a BCM4708) and XWR-3100 (using
> a BCM47094)
>
> - Scott fixes the pinctrl names in the Cygnus DTS files
>
> - Jonathan enables the Broadcom iProc mailbox controller for Broadcom Cygnus/iProc
> SoCs, he adds interrupt support for the GPIO CRMU hardware block and finally adds
> the node for the OTP controller found on Cygnus SoCs
>
> - Dhananjay enables the GPIO B controller on Norstarh Plus SoCs
>
> - Eric defines standard pinctrl groups in the BCM2835 GPIO node
>
> - Gerd adds definitions for the pinctrl groups and updates the PWM, I2C and SDHCI nodes
> to use their appropriate pinctrl functions
>
> - Linus adds names for the Raspberry Pi GPIO lines based on the datasheet
>
> - Martin adds the DT binding and nodes for the Raspberry Pi firmware thermal block
>
> - Stefan fixes a few typos with respect to the BCM2835 mailbox binding example and
> Device Tree nodes he also fixes the Raspberry Pi GPIO lines names and finally
> adds names for the Raspberry Zero GPIO lines
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 3/6] Broadcom devicetree-arm64 changes for 4.10
From: Arnd Bergmann @ 2016-11-30 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-3-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:21 PM CET Florian Fainelli wrote:
> This pull request contains Broadcom ARM64 based SoC Device Tree changes for
> 4.10, please pull the following:
>
> - Robin updates the Northstart 2 DTS to use the generic IOMMU binding
>
> - Scott renames the Broadcom Northstar 2 binding document to use a standard name
> including the brcm vendor prefix
>
> - Kamal adds the QSPI Device Tree node to the Northstar 2 SoC and updates the
> Northstar 2 SVK reference board DTS file with it enabled.
>
> - Rob adds the Device Tree node for the Broadcom PDC (mailbox) hardware to the
> Northstar 2 SoC
>
> - Jon enables the SDIO1 block and adds proper PCIe PHYs Device Tree nodes to the
> Northstar 2 SoC
>
> - Ray adds required properties NAND controller properties to make NAND work on
> the Northstar 2 SVK board, this was submitted as a 4.9 fixes and is included
> here to resolve DTS file merges
>
> - Andrea removes an incorrect power LED from the Raspberry Pi 3 DTS
>
> - Andreas fixes the compatible string for the BCM2837 (Raspberry Pi 3)
>
> - Eric defines standard pinctrl groups in the BCM2835 GPIO node
>
> - Gerd adds definitions for the pinctrl groups and updates the PWM, I2C and SDHCI nodes
> to use their appropriate pinctrl functions
>
> - Linus adds names for the Raspberry Pi GPIO lines based on the datasheet
>
> - Martin adds the DT binding and nodes for the Raspberry Pi firmware thermal block
>
> - Stefan fixes a few typos with respect to the BCM2835 mailbox binding example and
> Device Tree nodes he also uses the proper DTSI file to define the USB host mode
> for the USB Device Tree nodes
>
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Santosh Shilimkar @ 2016-11-30 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5501170.dgvo5UdPBX@wuerfel>
Hi Grygorii,
On 11/30/2016 3:37 AM, Arnd Bergmann wrote:
> On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
>> range->num_irqs++;
>>
>> - if (oirq.args_count == 3)
>> + if (IS_ENABLED(SMP) && oirq.args_count == 3)
>> range->irqs[i].cpu_map =
>> (oirq.args[2] & 0x0000ff00) >> 8;
>>
>
> I think you mean CONFIG_SMP, not SMP. With the change above, the
> code will never be executed.
>
Is that the full patch ? Can you post updated patch wit above fixed
and copy me. I will pick it up.
Regards,
Santosh
^ permalink raw reply
* [PATCH v3 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2016-11-30 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130162353.GC1441@katana>
Hi,
2016-11-30 17:23 GMT+01:00 Wolfram Sang <wsa-dev@sang-engineering.com>:
> Hi,
>
>> I was too busy in another project but now I am ready to complete the
>> upstream of the STM32F4 I2C driver.
>
> Nice.
>
>> >> +static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
>> >> +{
>> >> + u32 clk_rate, cr2, freq;
>> >> +
>> >> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
>> >> + cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
>> >> +
>> >> + clk_rate = clk_get_rate(i2c_dev->clk);
>> >> + freq = clk_rate / MHZ_TO_HZ;
>> >> +
>> >> + if (freq > STM32F4_I2C_MAX_FREQ)
>> >> + freq = STM32F4_I2C_MAX_FREQ;
>> >> + if (freq < STM32F4_I2C_MIN_FREQ)
>> >> + freq = STM32F4_I2C_MIN_FREQ;
>> >
>> > clamp() to enforce the range?
>> Sorry but what do you mean by "clamp()" ?
>
> The kernel has a clamp() function which would fit this purpose, I think.
Ok I got it. I will fix it in the V4.
Thanks
>
> Regards,
>
> Wolfram
>
^ permalink raw reply
* question about irq_enter()/irq_exit() calling policy
From: Grygorii Strashko @ 2016-11-30 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130102134.GB14217@n2100.armlinux.org.uk>
Hi Russell,
On 11/30/2016 04:21 AM, Russell King - ARM Linux wrote:
> On Tue, Nov 29, 2016 at 05:47:12PM -0600, Grygorii Strashko wrote:
>> 2) Should these function be called for each processed irq?
>>
>>
>> HW IRQ:
>> switch (IRQ mode)
>> ...
>> while (irq = get_pending_irq()) {
>> ...
>> irq_enter()
>> handle(irq) - execute hw_irq_hadler
>> irq_exit()
>> }
>> ...
>> switch
>
> We tend to do (2) as a general rule, which isn't much different from what
> other architectures do - even if they have a method to directly enter
> through vectors (eg, x86) the effect of two pending interrupts is that one
> will run after each other, and there will be an intervening exit -> entry.
>
> In the case of ARM CPUs, if the interrupt signal is active, you vector
> back to the interrupt handler as soon as you exit back to the parent
> context without executing any parent context instructions.
>
> So, we have the choice of going through all the IRQ entry code, processing
> one interrupt, and returning only to then re-vector back through the IRQ
> entry code, or we can process all the pending IRQs that we can see at that
> time.
>
> The former method wastes all the CPU cycles getting from the parent context
> to the IRQ context for each and every interrupt.
>
Thanks a lot for your detailed explanation.
When I've asked this question my intention was to understand possibility of calling
irq_enter()/irq_exit() only once for the case (2), like:
HW IRQ:
switch (IRQ mode)
...
irq_enter()
while (irq = get_pending_irq()) {
...
handle(irq) - execute hw_irq_hadler
}
irq_exit()
...
switch
--
regards,
-grygorii
^ permalink raw reply
* [PATCH v2] soc: ti: qmss: fix the case when !SMP
From: Grygorii Strashko @ 2016-11-30 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130165351.1154-1-grygorii.strashko@ti.com>
+ Santosh Shilimkar <santosh.shilimkar@oracle.com>
On 11/30/2016 10:53 AM, Grygorii Strashko wrote:
> The irq_set_affinity_hint() will always fail when !SMP and
> Networking will fail on Keystone 2 devices in this case.
> Hence, fix by ignoring IRQ affinity settings when !SMP.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> drivers/soc/ti/knav_qmss_queue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
> index b73e353..eacad57 100644
> --- a/drivers/soc/ti/knav_qmss_queue.c
> +++ b/drivers/soc/ti/knav_qmss_queue.c
> @@ -1228,7 +1228,7 @@ static int knav_setup_queue_range(struct knav_device *kdev,
>
> range->num_irqs++;
>
> - if (oirq.args_count == 3)
> + if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3)
> range->irqs[i].cpu_map =
> (oirq.args[2] & 0x0000ff00) >> 8;
> }
>
--
regards,
-grygorii
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Grygorii Strashko @ 2016-11-30 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2531f769-dd28-dfbd-0ed7-b209ef6ae98d@oracle.com>
Hi Santosh,
On 11/30/2016 11:01 AM, Santosh Shilimkar wrote:
> Hi Grygorii,
>
> On 11/30/2016 3:37 AM, Arnd Bergmann wrote:
>> On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
>>> range->num_irqs++;
>>>
>>> - if (oirq.args_count == 3)
>>> + if (IS_ENABLED(SMP) && oirq.args_count == 3)
>>> range->irqs[i].cpu_map =
>>> (oirq.args[2] & 0x0000ff00) >> 8;
>>>
>>
>> I think you mean CONFIG_SMP, not SMP. With the change above, the
>> code will never be executed.
>>
> Is that the full patch ? Can you post updated patch wit above fixed
> and copy me. I will pick it up.
>
I've sent v2.
For some reason you e-email is not working - delivery failure
ssantosh at kernel.org
--
regards,
-grygorii
^ permalink raw reply
* [PATCH v2] soc: ti: qmss: fix the case when !SMP
From: Santosh Shilimkar @ 2016-11-30 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d26f37e6-657f-ff42-2d9d-343fa47c2e5d@ti.com>
Hi Anrd,
Can you apply this to your non critical fixes queue ?
On 11/30/2016 9:09 AM, Grygorii Strashko wrote:
> + Santosh Shilimkar <santosh.shilimkar@oracle.com>
>
> On 11/30/2016 10:53 AM, Grygorii Strashko wrote:
>> The irq_set_affinity_hint() will always fail when !SMP and
>> Networking will fail on Keystone 2 devices in this case.
>> Hence, fix by ignoring IRQ affinity settings when !SMP.
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
>> drivers/soc/ti/knav_qmss_queue.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/ti/knav_qmss_queue.c
>> b/drivers/soc/ti/knav_qmss_queue.c
>> index b73e353..eacad57 100644
>> --- a/drivers/soc/ti/knav_qmss_queue.c
>> +++ b/drivers/soc/ti/knav_qmss_queue.c
>> @@ -1228,7 +1228,7 @@ static int knav_setup_queue_range(struct
>> knav_device *kdev,
>>
>> range->num_irqs++;
>>
>> - if (oirq.args_count == 3)
>> + if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3)
>> range->irqs[i].cpu_map =
>> (oirq.args[2] & 0x0000ff00) >> 8;
>> }
>>
>
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Santosh Shilimkar @ 2016-11-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0a2d9284-d1e3-c848-42a4-66b06babba80@ti.com>
On 11/30/2016 9:10 AM, Grygorii Strashko wrote:
>
> Hi Santosh,
>
> On 11/30/2016 11:01 AM, Santosh Shilimkar wrote:
>> Hi Grygorii,
>>
>> On 11/30/2016 3:37 AM, Arnd Bergmann wrote:
>>> On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
>>>> range->num_irqs++;
>>>>
>>>> - if (oirq.args_count == 3)
>>>> + if (IS_ENABLED(SMP) && oirq.args_count == 3)
>>>> range->irqs[i].cpu_map =
>>>> (oirq.args[2] & 0x0000ff00) >> 8;
>>>>
>>>
>>> I think you mean CONFIG_SMP, not SMP. With the change above, the
>>> code will never be executed.
>>>
>> Is that the full patch ? Can you post updated patch wit above fixed
>> and copy me. I will pick it up.
>>
>
> I've sent v2.
>
> For some reason you e-email is not working - delivery failure
> ssantosh at kernel.org
>
Weird. I was getting all the emails. Thanks for bouncing the thread.
I will check.
^ permalink raw reply
* [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols
From: Catalin Marinas @ 2016-11-30 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-6-git-send-email-labbott@redhat.com>
On Tue, Nov 29, 2016 at 10:55:24AM -0800, Laura Abbott wrote:
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -205,6 +205,8 @@ static inline void *phys_to_virt(phys_addr_t x)
> #define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
> #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
> #define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
> +#define sym_to_pfn(x) __phys_to_pfn(__pa_symbol(x))
> +#define lm_alias(x) __va(__pa_symbol(x))
[...]
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -76,6 +76,10 @@ extern int mmap_rnd_compat_bits __read_mostly;
> #define page_to_virt(x) __va(PFN_PHYS(page_to_pfn(x)))
> #endif
>
> +#ifndef lm_alias
> +#define lm_alias(x) __va(__pa_symbol(x))
> +#endif
You can drop the arm64-specific lm_alias macro as it's the same as the
generic one you introduced in the same patch.
--
Catalin
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Icenowy Zheng @ 2016-11-30 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130102757.9eec1f7f3377d0f4787e3829@free.fr>
30.11.2016, 17:28, "Jean-Francois Moine" <moinejf@free.fr>:
> On Wed, 30 Nov 2016 10:20:21 +0200
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>
>> ?> Well, I don't see what this connector can be.
>> ?> May you give me a DT example?
>>
>> ?Sure.
>>
>> ?arch/arm/boot/dts/r8a7791-koelsch.dts
>>
>> ?????????/* HDMI encoder */
>>
>> ?????????hdmi at 39 {
>> ?????????????????compatible = "adi,adv7511w";
>> ?????????????????reg = <0x39>;
>> ?????????????????interrupt-parent = <&gpio3>;
>> ?????????????????interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
>>
>> ?????????????????adi,input-depth = <8>;
>> ?????????????????adi,input-colorspace = "rgb";
>> ?????????????????adi,input-clock = "1x";
>> ?????????????????adi,input-style = <1>;
>> ?????????????????adi,input-justification = "evenly";
>>
>> ?????????????????ports {
>> ?????????????????????????#address-cells = <1>;
>> ?????????????????????????#size-cells = <0>;
>>
>> ?????????????????????????port at 0 {
>> ?????????????????????????????????reg = <0>;
>> ?????????????????????????????????adv7511_in: endpoint {
>> ?????????????????????????????????????????remote-endpoint = <&du_out_rgb>;
>> ?????????????????????????????????};
>> ?????????????????????????};
>>
>> ?????????????????????????port at 1 {
>> ?????????????????????????????????reg = <1>;
>> ?????????????????????????????????adv7511_out: endpoint {
>> ?????????????????????????????????????????remote-endpoint = <&hdmi_con>;
>> ?????????????????????????????????};
>> ?????????????????????????};
>> ?????????????????};
>> ?????????};
>>
>> ?????????/* HDMI connector */
>>
>> ?????????hdmi-out {
>> ?????????????????compatible = "hdmi-connector";
>> ?????????????????type = "a";
>>
>> ?????????????????port {
>> ?????????????????????????hdmi_con: endpoint {
>> ?????????????????????????????????remote-endpoint = <&adv7511_out>;
>> ?????????????????????????};
>> ?????????????????};
>> ?????????};
>
> Hi Laurent,
>
> Sorry for I don't see the interest:
> - it is obvious that the HDMI connector is a 'hdmi-connector'!
Yes, it means the wire between the HDMI pins on the SoC and the connector ;-)
> - the physical connector type may be changed on any board by a soldering
> ??iron or a connector to connector cable.
I can always alter the devices on a board ;-)
But I should also alter the dt after altering the board.
> - what does the software do with the connector type?
> - why not to put the connector information in the HDMI device?
>
> And, if I follow you, the graph of ports could also be used to describe
> the way the various parts of the SoCs are powered, to describe the pin
> connections, to describe the USB connectors, to describe the board
> internal hubs and bridges...
>
> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Icenowy Zheng @ 2016-11-30 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130114415.2280151e2965280733a629e5@free.fr>
30.11.2016, 18:44, "Jean-Francois Moine" <moinejf@free.fr>:
> On Wed, 30 Nov 2016 11:52:25 +0200
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>
>> ?Hi Jean-Fran?ois,
>>
>> ?On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote:
>> ?> On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote:
>> ?> >> Well, I don't see what this connector can be.
>> ?> >> May you give me a DT example?
>> ?> >
>> ?> > Sure.
>> ?> >
>> ?> > arch/arm/boot/dts/r8a7791-koelsch.dts
>> ?> >
>> ?> > /* HDMI encoder */
>
> ????????[snip]
>> ?> > /* HDMI connector */
>> ?> >
>> ?> > hdmi-out {
>> ?> > compatible = "hdmi-connector";
>> ?> > type = "a";
>> ?> >
>> ?> > port {
>> ?> > hdmi_con: endpoint {
>> ?> > remote-endpoint = <&adv7511_out>;
>> ?> > };
>> ?> > };
>> ?> > };
>
> ????????[snip]
>> ?> - what does the software do with the connector type?
>>
>> ?That's up to the software to decide, the DT bindings should describe the
>> ?hardware in the most accurate and usable way for the OS as possible. One of my
>> ?longer term goals is to add connector drivers to handle DDC and HPD when
>> ?they're not handled by the encoder (they are in the above example).
>>
>> ?If the DDC was connected to a general-purpose I2C bus of the SoC, and the HPD
>> ?to a GPIO, we would have
>>
>> ?????????hdmi-out {
>> ?????????????????compatible = "hdmi-connector";
>> ?????????????????type = "a";
>> ?????????????????/* I2C bus and GPIO references are made up for the example */
>> ?????????????????ddc-i2c-bus = <&i2c4>;
>> ?????????????????hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
>>
>> ?????????????????port {
>> ?????????????????????????hdmi_con: endpoint {
>> ?????????????????????????????????remote-endpoint = <&adv7511_out>;
>> ?????????????????????????};
>> ?????????????????};
>> ?????????};
>>
>> ?and both HPD and EDID reading should be handled by the connector driver.
>
> ????????[snip]
>
> Hi Laurent,
>
> OK. I understand. This connector complexity should be added in all DTs,
> and the same code would be used.
>
> Actually, for component binding, I use drm_of_component_probe():
>
> - from the DRM master, loop on the "ports" phandle array and bind the
> ??CRTCs,
>
> - for each CRTC, loop on the first remote port level and bind the
> ??encoders/connectors
>
> Now, this should be:
>
> - from the DRM master, loop on the first remote ports level and bind
> ??the CRTCs,
>
> - for each CRTC, loop on the second remote port level and bind the
> ??encoders (and bridges?),
>
> - for each encoder, loop on the third remote port level and bind the
> ??connectors.
>
> Then, it would be nice to have a generic function for doing this job.
>
> Otherwise, from your description:
>
>> ?????????hdmi-out {
>> ?????????????????compatible = "hdmi-connector";
>> ?????????????????type = "a";
>> ?????????????????/* I2C bus and GPIO references are made up for the example */
>> ?????????????????ddc-i2c-bus = <&i2c4>;
>> ?????????????????hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
>
> the "hdmi-connector" is a big piece of software. It must handle a lot
> of more and more exotic connectors.
> So, I hope that you have written a "simple-hdmi-connector" which does
> nothing but setting the connector type.
> Where is it?
I suddenly thought about something...
If a DVI connector instead of a HDMI connector is soldered, how should such a
device tree be written?
How about solder a HDMI-to-VGA bridge on the board? (Maybe there should be
"dumb-hdmi-dvi-bridge" and "dumb-hdmi-vga-bridge" drivers?)
>
> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH 1/2] ARM: dts: at91: sama5d4: change DMA allocation for secure peripherals
From: Nicolas Ferre @ 2016-11-30 17:36 UTC (permalink / raw)
To: linux-arm-kernel
Some peripherals are "Programmable Secure" but left as "Secure" by default.
If tried to be connected to Non-Secure DMA controller, the possibility to
leak secure data is prevented so using these peripherals with DMA1 is not
possible with this default configuration (MATRIX_SPSELR registers setup by
bootloader).
Move them to DMA0 which is an "Always-Secure" DMA controller.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/sama5d4.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 4f60c1b7b137..d3889c9d25a9 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -854,10 +854,10 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xf8004000 0x100>;
interrupts = <27 IRQ_TYPE_LEVEL_HIGH 5>;
- dmas = <&dma1
+ dmas = <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(22))>,
- <&dma1
+ <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(23))>;
dma-names = "tx", "rx";
@@ -938,10 +938,10 @@
compatible = "atmel,sama5d4-i2c";
reg = <0xf8018000 0x4000>;
interrupts = <33 IRQ_TYPE_LEVEL_HIGH 6>;
- dmas = <&dma1
+ dmas = <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(4))>,
- <&dma1
+ <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(5))>;
dma-names = "tx", "rx";
@@ -1055,10 +1055,10 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xfc004000 0x100>;
interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
- dmas = <&dma1
+ dmas = <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(24))>,
- <&dma1
+ <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(25))>;
dma-names = "tx", "rx";
@@ -1167,10 +1167,10 @@
compatible = "atmel,at91rm9200-spi";
reg = <0xfc01c000 0x100>;
interrupts = <39 IRQ_TYPE_LEVEL_HIGH 3>;
- dmas = <&dma1
+ dmas = <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(14))>,
- <&dma1
+ <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(15))>;
dma-names = "tx", "rx";
--
2.9.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: at91: sama5d4 Xplained: enable UART1 node with DMA
From: Nicolas Ferre @ 2016-11-30 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130173630.11944-1-nicolas.ferre@atmel.com>
Enable UART1 and use DMA configuration with it.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
index ed7fce297738..91cf69e26aa1 100644
--- a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -69,6 +69,12 @@
ahb {
apb {
+ uart0: serial at f8004000 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "okay";
+ };
+
spi0: spi at f8010000 {
cs-gpios = <&pioC 3 0>, <0>, <0>, <0>;
status = "okay";
--
2.9.0
^ permalink raw reply related
* [PATCH v3 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: atull @ 2016-11-30 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e193572d7746e6f6b8666da7ac0f54031fed5214.1480467185.git.stillcompiling@gmail.com>
On Wed, 30 Nov 2016, Joshua Clayton wrote:
Hi Clayton,
I just have a few minor one line changes below. Only one
is operational, I should have caught that earlier.
> cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial"
> interface on Altera Cyclone FPGAS.
>
> This is one of the simpler ways to set up an FPGA at runtime.
> The signal interface is close to unidirectional spi with lsb first.
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
> ---
> drivers/fpga/Kconfig | 7 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/cyclone-ps-spi.c | 176 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 184 insertions(+)
> create mode 100644 drivers/fpga/cyclone-ps-spi.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index cd84934..2462707 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -13,6 +13,13 @@ config FPGA
>
> if FPGA
>
> +config FPGA_MGR_CYCLONE_PS_SPI
> + tristate "Altera Cyclone FPGA Passive Serial over SPI"
> + depends on SPI
> + help
> + FPGA manager driver support for Altera Cyclone using the
> + passive serial interface over SPI
> +
> config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8d83fc6..8f93930 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -6,5 +6,6 @@
> obj-$(CONFIG_FPGA) += fpga-mgr.o
>
> # FPGA Manager Drivers
> +obj-$(CONFIG_FPGA_MGR_CYCLONE_PS_SPI) += cyclone-ps-spi.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> diff --git a/drivers/fpga/cyclone-ps-spi.c b/drivers/fpga/cyclone-ps-spi.c
> new file mode 100644
> index 0000000..57a520d
> --- /dev/null
> +++ b/drivers/fpga/cyclone-ps-spi.c
> @@ -0,0 +1,176 @@
> +/**
> + * Copyright (c) 2015 United Western Technologies, Corporation
> + *
> + * Joshua Clayton <stillcompiling@gmail.com>
> + *
> + * Manage Altera fpga firmware that is loaded over spi.
> + * Firmware must be in binary "rbf" format.
> + * Works on Cyclone V. Should work on cyclone series.
> + * May work on other Altera fpgas.
> + *
> + */
> +
> +#include <linux/bitrev.h>
> +#include <linux/delay.h>
> +#include <linux/fpga/fpga-mgr.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of_gpio.h>
> +#include <linux/spi/spi.h>
> +#include <linux/sizes.h>
> +
> +#define FPGA_RESET_TIME 50 /* time in usecs to trigger FPGA config */
> +#define FPGA_MIN_DELAY 50 /* min usecs to wait for config status */
> +#define FPGA_MAX_DELAY 1000 /* max usecs to wait for config status */
> +
> +struct cyclonespi_conf {
> + struct gpio_desc *config;
> + struct gpio_desc *status;
> + struct spi_device *spi;
> +};
> +
> +static const struct of_device_id of_ef_match[] = {
> + { .compatible = "altr,cyclone-ps-spi-fpga-mgr", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, of_ef_match);
> +
> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
> +{
> + return mgr->state;
> +}
This function gets called once to initialize mgr->state in
fpga_mgr_register(). So it should at least return the state the FPGA
is at then. If it is unknown, it can just return
FPGA_MGR_STATE_UNKNOWN.
> +
> +static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
Minor, but please fix the indentation of 'const' to match that of
'struct' above. checkpatch.pl is probably issuing warnings
about that.
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> + int i;
> +
> + if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
> + dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
> + return -EINVAL;
> + }
> +
> + gpiod_set_value(conf->config, 0);
> + usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
> + if (gpiod_get_value(conf->status) == 1) {
> + dev_err(&mgr->dev, "Status pin should be low.\n");
> + return -EIO;
> + }
> +
> + gpiod_set_value(conf->config, 1);
> + for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
> + usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
> + if (gpiod_get_value(conf->status))
> + return 0;
> + }
> +
> + dev_err(&mgr->dev, "Status pin not ready.\n");
> + return -EIO;
> +}
> +
> +static void rev_buf(void *buf, size_t len)
> +{
> + u32 *fw32 = (u32 *)buf;
> + const u32 *fw_end = (u32 *)(buf + len);
> +
> + /* set buffer to lsb first */
> + while (fw32 < fw_end) {
> + *fw32 = bitrev8x4(*fw32);
> + fw32++;
> + }
> +}
> +
> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
> + size_t count)
Please fix alignment here also.
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> + const char *fw_data = buf;
> + const char *fw_data_end = fw_data + count;
> +
> + while (fw_data < fw_data_end) {
> + int ret;
> + size_t stride = min(fw_data_end - fw_data, SZ_4K);
> +
> + rev_buf((void *)fw_data, stride);
> + ret = spi_write(conf->spi, fw_data, stride);
> + if (ret) {
> + dev_err(&mgr->dev, "spi error in firmware write: %d\n",
> + ret);
> + return ret;
> + }
> + fw_data += stride;
> + }
> +
> + return 0;
> +}
> +
> +static int cyclonespi_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> +
> + if (gpiod_get_value(conf->status) == 0) {
> + dev_err(&mgr->dev, "Error during configuration.\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static const struct fpga_manager_ops cyclonespi_ops = {
> + .state = cyclonespi_state,
> + .write_init = cyclonespi_write_init,
> + .write = cyclonespi_write,
> + .write_complete = cyclonespi_write_complete,
> +};
> +
> +static int cyclonespi_probe(struct spi_device *spi)
> +{
> + struct cyclonespi_conf *conf = devm_kzalloc(&spi->dev, sizeof(*conf),
> + GFP_KERNEL);
> +
> + if (!conf)
> + return -ENOMEM;
> +
> + conf->spi = spi;
> + conf->config = devm_gpiod_get(&spi->dev, "config", GPIOD_OUT_LOW);
> + if (IS_ERR(conf->config)) {
> + dev_err(&spi->dev, "Failed to get config gpio: %ld\n",
> + PTR_ERR(conf->config));
> + return PTR_ERR(conf->config);
> + }
> +
> + conf->status = devm_gpiod_get(&spi->dev, "status", GPIOD_IN);
> + if (IS_ERR(conf->status)) {
> + dev_err(&spi->dev, "Failed to get status gpio: %ld\n",
> + PTR_ERR(conf->status));
> + return PTR_ERR(conf->status);
> + }
> +
> + return fpga_mgr_register(&spi->dev,
> + "Altera Cyclone PS SPI FPGA Manager",
> + &cyclonespi_ops, conf);
> +}
> +
> +static int cyclonespi_remove(struct spi_device *spi)
> +{
> + fpga_mgr_unregister(&spi->dev);
> +
> + return 0;
> +}
> +
> +static struct spi_driver cyclonespi_driver = {
> + .driver = {
> + .name = "cyclone-ps-spi",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(of_ef_match),
> + },
> + .probe = cyclonespi_probe,
> + .remove = cyclonespi_remove,
> +};
> +
> +module_spi_driver(cyclonespi_driver)
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Joshua Clayton <stillcompiling@gmail.com>");
> +MODULE_DESCRIPTION("Module to load Altera FPGA firmware over spi");
> --
> 2.9.3
>
>
Thanks,
Alan
^ permalink raw reply
* [GIT PULL] ARM: keystone: add TI SCI protocol support for v4.10
From: Tero Kristo @ 2016-11-30 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9563335.412haHXOPG@wuerfel>
On 30/11/16 18:43, Arnd Bergmann wrote:
> On Monday, November 28, 2016 6:42:41 PM CET Tero Kristo wrote:
>> Gentle ping on this, is anybody going to pull this one?
>>
>> -Tero
>>
>> On 27/10/16 12:30, Tero Kristo wrote:
>>> Hi Arnd, Olof, Kevin,
>>>
>>> This pull introduces the TI SCI protocol support for keystone family of
>>> devices, targeted for v4.10 merge window. We discussed with Santosh
>>> (keystone maintainer) that it would probably be better that I'll be
>>> sending the pull requests for this directly, avoiding one extra step of
>>> merges.
>>
>
> Sorry for the delay. I just saw this pull request in the backlog
> and had to take a closer look first. I probably would have commented
> on a few details in a proper review, but overall this seems harmless
> enough, so I've merged it into next/drivers in the end.
>
> There was no branch description in
> https://github.com/t-kristo/linux-pm.git for-4.10-ti-sci-base
> and I ended up taking something from the wiki. This is now the
> commit I ended up with:
Thanks Arnd, that looks good to me.
I'll figure out how to add branch description next time when I am going
to be sending a pull-request directly to you guys.
-Tero
>
> commit ba9cb7b9ffa4a4056158bc8570f1a851e4a6a8ae
> Merge: e7541f9 912cffb
> Author: Arnd Bergmann <arnd@arndb.de>
> Date: Wed Nov 30 17:13:13 2016 +0100
>
> Merge branch 'for-4.10-ti-sci-base' of https://github.com/t-kristo/linux-pm into next/drivers
>
> Merge "ARM: keystone: add TI SCI protocol support for v4.10" from
> Tero Kristo:
>
> [description taken from http://processors.wiki.ti.com/index.php/TISCI
>
> Texas Instruments' Keystone generation System on Chips (SoC) starting
> with 66AK2G02, now include a dedicated SoC System Control entity called
> PMMC(Power Management Micro Controller) in line with ARM architecture
> recommendations. The function of this module is to integrate all system
> operations in a centralized location. Communication with the SoC System
> Control entity from various processing units like ARM/DSP occurs over
> Message Manager hardware block.
>
> ...
>
> Texas Instruments' System Control Interface defines the communication
> protocol between various processing entities to the System Control Entity
> on TI SoCs. This is a set of message formats and sequence of operations
> required to communicate and get system services processed from System
> Control entity in the SoC.]
>
> * 'for-4.10-ti-sci-base' of https://github.com/t-kristo/linux-pm:
> firmware: ti_sci: Add support for reboot core service
> firmware: ti_sci: Add support for Clock control
> firmware: ti_sci: Add support for Device control
> firmware: Add basic support for TI System Control Interface (TI-SCI) protocol
> Documentation: Add support for TI System Control Interface (TI-SCI) protocol
>
> Arnd
>
^ permalink raw reply
* [PATCH v3 0/3] Altera Cyclone Passive Serial SPI FPGA Manager
From: atull @ 2016-11-30 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1480467185.git.stillcompiling@gmail.com>
On Wed, 30 Nov 2016, Joshua Clayton wrote:
Hi Joshua,
The DT bindings will need Rob Herring's ack. The bitrev.h
changes will need Russell King's ack.
I've made some comments on patch 3/3 but it looks good to me
besides that.
Once we have those other acks, please submit your v4 including fixes
for my comments and whatever else comes up. I'm hoping it will be
minor and with that done, v4 can go in.
When you send in v4, please also cc our new mailing list that Moritz
made: linux-fpga at vger.kernel.org
Alan
> This series adds an FPGA manager for Altera cyclone FPGAs
> that can program them using an spi port and a couple of gpios, using
> Alteras passive serial protocol.
>
> Changes from v2:
>
> - Merged patch 3 and 4 as suggested in review by Moritz Fischer
> - Changed FPGA_MIN_DELAY from 250 to 50 ms is the time advertized by
> Altera. This now works, as we don't assume it is done
>
> Changes from v1:
> - Changed the name from cyclone-spi-fpga-mgr to cyclone-ps-spi-fpga-mgr
> This name change was requested by Alan Tull, to be specific about which
> programming method is being employed on the fpga.
> - Changed the name of the reset-gpio to config-gpio to closer match the
> way the pins are described in the Altera manual
> - Moved MODULE_LICENCE, _AUTHOR, and _DESCRIPTION to the bottom
>
> - Added a bitrev8x4() function to the bitrev headers and implemented ARM
> const, runtime, and ARM specific faster versions (This may end up
> needing to be a standalone patch)
>
> - Moved the bitswapping into cyclonespi_write(), as requested.
> This falls short of my desired generic lsb first spi support, but is a step
> in that direction.
>
> - Fixed whitespace problems introduced during refactoring
>
> - Replaced magic number for initial delay with a descriptive macro
> - Poll the fpga to see when it is ready rather than a fixed 1 ms sleep
>
> Joshua Clayton (3):
> lib: add bitrev8x4()
> doc: dt: add cyclone-spi binding document
> fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
>
> .../bindings/fpga/cyclone-ps-spi-fpga-mgr.txt | 23 +++
> arch/arm/include/asm/bitrev.h | 5 +
> drivers/fpga/Kconfig | 7 +
> drivers/fpga/Makefile | 1 +
> drivers/fpga/cyclone-ps-spi.c | 176 +++++++++++++++++++++
> include/linux/bitrev.h | 26 +++
> 6 files changed, 238 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
> create mode 100644 drivers/fpga/cyclone-ps-spi.c
>
> --
> 2.9.3
>
>
^ permalink raw reply
* Applied "ASoC: sun4i-codec: Add support for H3 codec" to the asoc tree
From: Mark Brown @ 2016-11-30 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-9-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for H3 codec
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 4a15b24a65f13778f7616ad0a65be78d8ec0b45a Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Fri, 25 Nov 2016 20:34:40 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for H3 codec
The codec on the H3 is similar to the one found on the A31. One key
difference is the analog path controls are routed through the PRCM
block. This is supported by the sun8i-codec-analog driver, and tied
into this codec driver with the audio card's aux_dev.
In addition, the H3 has no HP (headphone) and HBIAS support, and no
MIC3 input. The FIFO related registers are slightly rearranged.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 3 +
sound/soc/sunxi/sun4i-codec.c | 71 ++++++++++++++++++++++
2 files changed, 74 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index f7a548b604fc..3033bd8aab0f 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -6,6 +6,7 @@ Required properties:
- "allwinner,sun6i-a31-codec"
- "allwinner,sun7i-a20-codec"
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- reg: must contain the registers location and length
- interrupts: must contain the codec interrupt
- dmas: DMA channels for tx and rx dma. See the DMA client binding,
@@ -23,6 +24,7 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- resets: phandle to the reset control for this device
- allwinner,audio-routing: A list of the connections between audio components.
Each entry is a pair of strings, the first being the
@@ -52,6 +54,7 @@ Required properties for the following compatibles:
Required properties for the following compatibles:
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- allwinner,codec-analog-controls: A phandle to the codec analog controls
block in the PRCM.
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index ada5fa055950..848af01692a0 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -217,6 +217,13 @@
#define SUN8I_A23_CODEC_DAC_TXCNT (0x1c)
#define SUN8I_A23_CODEC_ADC_RXCNT (0x20)
+/* TX FIFO moved on H3 */
+#define SUN8I_H3_CODEC_DAC_TXDATA (0x20)
+#define SUN8I_H3_CODEC_DAC_DBG (0x48)
+#define SUN8I_H3_CODEC_ADC_DBG (0x4c)
+
+/* TODO H3 DAP (Digital Audio Processing) bits */
+
struct sun4i_codec {
struct device *dev;
struct regmap *regmap;
@@ -1293,6 +1300,44 @@ static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
return card;
};
+static struct snd_soc_card *sun8i_h3_codec_create_card(struct device *dev)
+{
+ struct snd_soc_card *card;
+ int ret;
+
+ card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
+ if (!card)
+ return ERR_PTR(-ENOMEM);
+
+ aux_dev.codec_of_node = of_parse_phandle(dev->of_node,
+ "allwinner,codec-analog-controls",
+ 0);
+ if (!aux_dev.codec_of_node) {
+ dev_err(dev, "Can't find analog controls for codec.\n");
+ return ERR_PTR(-EINVAL);
+ };
+
+ card->dai_link = sun4i_codec_create_link(dev, &card->num_links);
+ if (!card->dai_link)
+ return ERR_PTR(-ENOMEM);
+
+ card->dev = dev;
+ card->name = "H3 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->dapm_routes = sun8i_codec_card_routes;
+ card->num_dapm_routes = ARRAY_SIZE(sun8i_codec_card_routes);
+ card->aux_dev = &aux_dev;
+ card->num_aux_devs = 1;
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
+
+ return card;
+};
+
static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -1321,6 +1366,13 @@ static const struct regmap_config sun8i_a23_codec_regmap_config = {
.max_register = SUN8I_A23_CODEC_ADC_RXCNT,
};
+static const struct regmap_config sun8i_h3_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = SUN8I_H3_CODEC_ADC_DBG,
+};
+
struct sun4i_codec_quirks {
const struct regmap_config *regmap_config;
const struct snd_soc_codec_driver *codec;
@@ -1369,6 +1421,21 @@ static const struct sun4i_codec_quirks sun8i_a23_codec_quirks = {
.has_reset = true,
};
+static const struct sun4i_codec_quirks sun8i_h3_codec_quirks = {
+ .regmap_config = &sun8i_h3_codec_regmap_config,
+ /*
+ * TODO Share the codec structure with A23 for now.
+ * This should be split out when adding digital audio
+ * processing support for the H3.
+ */
+ .codec = &sun8i_a23_codec_codec,
+ .create_card = sun8i_h3_codec_create_card,
+ .reg_adc_fifoc = REG_FIELD(SUN6I_CODEC_ADC_FIFOC, 0, 31),
+ .reg_dac_txdata = SUN8I_H3_CODEC_DAC_TXDATA,
+ .reg_adc_rxdata = SUN6I_CODEC_ADC_RXDATA,
+ .has_reset = true,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
{
.compatible = "allwinner,sun4i-a10-codec",
@@ -1386,6 +1453,10 @@ static const struct of_device_id sun4i_codec_of_match[] = {
.compatible = "allwinner,sun8i-a23-codec",
.data = &sun8i_a23_codec_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-h3-codec",
+ .data = &sun8i_h3_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A23 codec" to the asoc tree
From: Mark Brown @ 2016-11-30 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-5-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A23 codec
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From dac5f86bc9e60eae87a28512f025362d1e2574e3 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Fri, 25 Nov 2016 20:34:36 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A23 codec
The codec in the A23 is similar to the one found on the A31. One key
difference is the analog path controls are routed through the PRCM
block. This is supported by the sun8i-codec-analog driver, and tied
into this codec driver with the audio card's aux_dev.
In addition, the A23 does not have LINEOUT, and it does not support
headset jack detection or buttons.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 11 ++-
sound/soc/sunxi/sun4i-codec.c | 108 +++++++++++++++++++++
2 files changed, 117 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index d91a95377f49..f7a548b604fc 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -5,6 +5,7 @@ Required properties:
- "allwinner,sun4i-a10-codec"
- "allwinner,sun6i-a31-codec"
- "allwinner,sun7i-a20-codec"
+ - "allwinner,sun8i-a23-codec"
- reg: must contain the registers location and length
- interrupts: must contain the codec interrupt
- dmas: DMA channels for tx and rx dma. See the DMA client binding,
@@ -21,6 +22,7 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
+ - "allwinner,sun8i-a23-codec"
- resets: phandle to the reset control for this device
- allwinner,audio-routing: A list of the connections between audio components.
Each entry is a pair of strings, the first being the
@@ -31,10 +33,10 @@ Required properties for the following compatibles:
"HP"
"HPCOM"
"LINEIN"
- "LINEOUT"
+ "LINEOUT" (not on sun8i-a23)
"MIC1"
"MIC2"
- "MIC3"
+ "MIC3" (sun6i-a31 only)
Microphone biases from the SoC:
"HBIAS"
@@ -48,6 +50,11 @@ Required properties for the following compatibles:
"Mic"
"Speaker"
+Required properties for the following compatibles:
+ - "allwinner,sun8i-a23-codec"
+- allwinner,codec-analog-controls: A phandle to the codec analog controls
+ block in the PRCM.
+
Example:
codec: codec at 01c22c00 {
#sound-dai-cells = <0>;
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 092fdcf6de95..ada5fa055950 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -213,6 +213,10 @@
/* TODO sun6i DAP (Digital Audio Processing) bits */
+/* FIFO counters moved on A23 */
+#define SUN8I_A23_CODEC_DAC_TXCNT (0x1c)
+#define SUN8I_A23_CODEC_ADC_RXCNT (0x20)
+
struct sun4i_codec {
struct device *dev;
struct regmap *regmap;
@@ -1067,6 +1071,32 @@ static struct snd_soc_codec_driver sun6i_codec_codec = {
},
};
+/* sun8i A23 codec */
+static const struct snd_kcontrol_new sun8i_a23_codec_codec_controls[] = {
+ SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
+ SUN4I_CODEC_DAC_DPC_DVOL, 0x3f, 1,
+ sun6i_codec_dvol_scale),
+};
+
+static const struct snd_soc_dapm_widget sun8i_a23_codec_codec_widgets[] = {
+ /* Digital parts of the ADCs */
+ SND_SOC_DAPM_SUPPLY("ADC Enable", SUN6I_CODEC_ADC_FIFOC,
+ SUN6I_CODEC_ADC_FIFOC_EN_AD, 0, NULL, 0),
+ /* Digital parts of the DACs */
+ SND_SOC_DAPM_SUPPLY("DAC Enable", SUN4I_CODEC_DAC_DPC,
+ SUN4I_CODEC_DAC_DPC_EN_DA, 0, NULL, 0),
+
+};
+
+static struct snd_soc_codec_driver sun8i_a23_codec_codec = {
+ .component_driver = {
+ .controls = sun8i_a23_codec_codec_controls,
+ .num_controls = ARRAY_SIZE(sun8i_a23_codec_codec_controls),
+ .dapm_widgets = sun8i_a23_codec_codec_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(sun8i_a23_codec_codec_widgets),
+ },
+};
+
static const struct snd_soc_component_driver sun4i_codec_component = {
.name = "sun4i-codec",
};
@@ -1206,6 +1236,63 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
return card;
};
+/* Connect digital side enables to analog side widgets */
+static const struct snd_soc_dapm_route sun8i_codec_card_routes[] = {
+ /* ADC Routes */
+ { "Left ADC", NULL, "ADC Enable" },
+ { "Right ADC", NULL, "ADC Enable" },
+ { "Codec Capture", NULL, "Left ADC" },
+ { "Codec Capture", NULL, "Right ADC" },
+
+ /* DAC Routes */
+ { "Left DAC", NULL, "DAC Enable" },
+ { "Right DAC", NULL, "DAC Enable" },
+ { "Left DAC", NULL, "Codec Playback" },
+ { "Right DAC", NULL, "Codec Playback" },
+};
+
+static struct snd_soc_aux_dev aux_dev = {
+ .name = "Codec Analog Controls",
+};
+
+static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
+{
+ struct snd_soc_card *card;
+ int ret;
+
+ card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
+ if (!card)
+ return ERR_PTR(-ENOMEM);
+
+ aux_dev.codec_of_node = of_parse_phandle(dev->of_node,
+ "allwinner,codec-analog-controls",
+ 0);
+ if (!aux_dev.codec_of_node) {
+ dev_err(dev, "Can't find analog controls for codec.\n");
+ return ERR_PTR(-EINVAL);
+ };
+
+ card->dai_link = sun4i_codec_create_link(dev, &card->num_links);
+ if (!card->dai_link)
+ return ERR_PTR(-ENOMEM);
+
+ card->dev = dev;
+ card->name = "A23 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->dapm_routes = sun8i_codec_card_routes;
+ card->num_dapm_routes = ARRAY_SIZE(sun8i_codec_card_routes);
+ card->aux_dev = &aux_dev;
+ card->num_aux_devs = 1;
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
+
+ return card;
+};
+
static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -1227,6 +1314,13 @@ static const struct regmap_config sun7i_codec_regmap_config = {
.max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
+static const struct regmap_config sun8i_a23_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = SUN8I_A23_CODEC_ADC_RXCNT,
+};
+
struct sun4i_codec_quirks {
const struct regmap_config *regmap_config;
const struct snd_soc_codec_driver *codec;
@@ -1265,6 +1359,16 @@ static const struct sun4i_codec_quirks sun7i_codec_quirks = {
.reg_adc_rxdata = SUN4I_CODEC_ADC_RXDATA,
};
+static const struct sun4i_codec_quirks sun8i_a23_codec_quirks = {
+ .regmap_config = &sun8i_a23_codec_regmap_config,
+ .codec = &sun8i_a23_codec_codec,
+ .create_card = sun8i_a23_codec_create_card,
+ .reg_adc_fifoc = REG_FIELD(SUN6I_CODEC_ADC_FIFOC, 0, 31),
+ .reg_dac_txdata = SUN4I_CODEC_DAC_TXDATA,
+ .reg_adc_rxdata = SUN6I_CODEC_ADC_RXDATA,
+ .has_reset = true,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
{
.compatible = "allwinner,sun4i-a10-codec",
@@ -1278,6 +1382,10 @@ static const struct of_device_id sun4i_codec_of_match[] = {
.compatible = "allwinner,sun7i-a20-codec",
.data = &sun7i_codec_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-a23-codec",
+ .data = &sun8i_a23_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
--
2.10.2
^ permalink raw reply related
* [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-11-30 18:21 UTC (permalink / raw)
To: linux-arm-kernel
On ThunderX systems with certain memory configurations we see the
following BUG_ON():
kernel BUG at mm/page_alloc.c:1848!
This happens for some configs with 64k page size enabled. The BUG_ON()
checks if start and end page of a memmap range belongs to the same
zone.
The BUG_ON() check fails if a memory zone contains NOMAP regions. In
this case the node information of those pages is not initialized. This
causes an inconsistency of the page links with wrong zone and node
information for that pages. NOMAP pages from node 1 still point to the
mem zone from node 0 and have the wrong nid assigned.
The reason for the mis-configuration is a change in pfn_valid() which
reports pages marked NOMAP as invalid:
68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping
This causes pages marked as nomap being no long reassigned to the new
zone in memmap_init_zone() by calling __init_single_pfn().
Fixing this by restoring the old behavior of pfn_valid() to use
memblock_is_memory(). Also changing users of pfn_valid() in arm64 code
to use memblock_is_map_memory() where necessary. This only affects
code in ioremap.c. The code in mmu.c still can use the new version of
pfn_valid().
As a consequence, pfn_valid() can not be used to check if a physical
page is RAM. It just checks if there is an underlying memmap with a
valid struct page. Moreover, for performance reasons the whole memmap
(with pageblock_nr_pages number of pages) has valid pfns (SPARSEMEM
config). The memory range is extended to fit the alignment of the
memmap. Thus, pfn_valid() may return true for pfns that do not map to
physical memory. Those pages are simply not reported to the mm, they
are not marked reserved nor added to the list of free pages. Other
functions such a page_is_ram() or memblock_is_map_ memory() must be
used to check for memory and if the page can be mapped with the linear
mapping.
Since NOMAP mem ranges may need to be mapped with different mem
attributes (e.g. read-only or non-caching) we can not use linear
mapping here. The use of memblock_is_memory() in pfn_valid() may not
break this behaviour. Since commit:
e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
NOMAP mem resources are no longer marked as system RAM (IORESOURCE_
SYSTEM_RAM). Now page_is_ram() and region_intersects() (see
memremap()) do not detect NOMAP mem as system ram and NOMAP mem is not
added to the linear mapping as system RAM is.
v2:
* Added Ack
* updated description to reflect the discussion
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 2 +-
arch/arm64/mm/ioremap.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 212c4d1e2f26..166911f4a2e6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -147,7 +147,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
- return memblock_is_map_memory(pfn << PAGE_SHIFT);
+ return memblock_is_memory(pfn << PAGE_SHIFT);
}
EXPORT_SYMBOL(pfn_valid);
#endif
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index 01e88c8bcab0..c17c220b0c48 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -21,6 +21,7 @@
*/
#include <linux/export.h>
+#include <linux/memblock.h>
#include <linux/mm.h>
#include <linux/vmalloc.h>
#include <linux/io.h>
@@ -55,7 +56,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
/*
* Don't allow RAM to be mapped.
*/
- if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
+ if (WARN_ON(memblock_is_map_memory(phys_addr)))
return NULL;
area = get_vm_area_caller(size, VM_IOREMAP, caller);
@@ -96,7 +97,7 @@ EXPORT_SYMBOL(__iounmap);
void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
{
/* For normal memory we already have a cacheable mapping. */
- if (pfn_valid(__phys_to_pfn(phys_addr)))
+ if (memblock_is_map_memory(phys_addr))
return (void __iomem *)__phys_to_virt(phys_addr);
return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
--
2.1.4
^ 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