* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Frank Rowand @ 2016-11-22 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <800171a8-2e2c-2afb-f96d-800a17eaa17a@ti.com>
On 11/21/16 22:25, Sekhar Nori wrote:
> Hi Frank,
>
> On Tuesday 22 November 2016 07:13 AM, Frank Rowand wrote:
>> On 11/21/16 08:33, Sekhar Nori wrote:
>>> On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
>>>> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
>>>> +{
>>>> + const struct da8xx_ddrctl_config_knob *knob;
>>>> + const struct da8xx_ddrctl_setting *setting;
>>>> + struct device_node *node;
>>>> + struct resource *res;
>>>> + void __iomem *ddrctl;
>>>> + struct device *dev;
>>>> + u32 reg;
>>>> +
>>>> + dev = &pdev->dev;
>>>> + node = dev->of_node;
>>>> +
>>>> + setting = da8xx_ddrctl_get_board_settings();
>>>> + if (!setting) {
>>>> + dev_err(dev, "no settings for board '%s'\n",
>>>> + of_flat_dt_get_machine_name());
>>>> + return -EINVAL;
>>>> + }
>>>
>>> This causes a section mismatch because of_flat_dt_get_machine_name()
>>> has an __init annotation. I did not notice that before, sorry.
>>>
>>> It can be fixed with a patch like below:
>>>
>>> ---8<---
>>> diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
>>> index a20e7bbbcbe0..9ca5aab3ac54 100644
>>> --- a/drivers/memory/da8xx-ddrctl.c
>>> +++ b/drivers/memory/da8xx-ddrctl.c
>>> @@ -102,6 +102,18 @@ static const struct da8xx_ddrctl_setting *da8xx_ddrctl_get_board_settings(void)
>>> return NULL;
>>> }
>>>
>>> +static const char* da8xx_ddrctl_get_machine_name(void)
>>> +{
>>> + const char *str;
>>> + int ret;
>>> +
>>> + ret = of_property_read_string(of_root, "model", &str);
>>> + if (ret)
>>> + ret = of_property_read_string(of_root, "compatible", &str);
>>> +
>>> + return str;
>>> +}
>>> +
>>> static int da8xx_ddrctl_probe(struct platform_device *pdev)
>>> {
>>> const struct da8xx_ddrctl_config_knob *knob;
>>> @@ -118,7 +130,7 @@ static int da8xx_ddrctl_probe(struct platform_device *pdev)
>>> setting = da8xx_ddrctl_get_board_settings();
>>> if (!setting) {
>>> dev_err(dev, "no settings for board '%s'\n",
>>> - of_flat_dt_get_machine_name());
>>
>> da8xx_ddrctl_get_board_settings() tries to match based on the "compatible"
>> property in the root node. The "model" property in the root node has
>> nothing to do with the failure to match. So creating and then using
>> da8xx_ddrctl_get_machine_name() to potentially report model is not useful.
>>
>> It should be sufficient to simply report that no compatible matched.
>
> I agree with you on this. Even if model name is printed, you will have
> to go back and check the compatible anyway. But I think it will be
> useful to print the compatible instead of just reporting that nothing
> matched.
>
> Bartosz, if you agree too, could you send a fix patch just printing the
> compatible?
Please note that the compatible property might contain several strings, not just
a single string.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 0/9] AC97 device/driver model revamp
From: Mark Brown @ 2016-11-22 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-1-git-send-email-robert.jarzmik@free.fr>
On Wed, Oct 26, 2016 at 09:41:38PM +0200, Robert Jarzmik wrote:
> The driving ideas are still the same, and I put them in [1] for memory. This is
> the first post RFC submission. In order to make a full demonstration of the
> framework, wm97xx was converted to an MFD, see [2] for the "why".
This all looks nice to me, I did spot a few things but I don't think I
had anything that wasn't already raised by someone else so didn't repeat
them. Thanks for stepping up and doing this work!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161122/7e4a6ad6/attachment.sig>
^ permalink raw reply
* [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus
From: Mark Brown @ 2016-11-22 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b97a129-bd10-b9be-616d-a3ea3b91b103@metafoo.de>
On Thu, Nov 10, 2016 at 12:38:40PM +0100, Lars-Peter Clausen wrote:
> On 11/09/2016 10:27 PM, Robert Jarzmik wrote:
> > here, ie. that the rescan is a bug, or if it's more an "Occam's razor"
> > discussion ?
> Maybe we can just leave the rescanning out for now and think about how to
> best handle it when the need arises.
Yes, I think that's best - I suspect it'd be something that'd need to be
triggered by a driver for an AC'97 CODEC doing power management but I
imagine that if we were going to have such a system we'd have run into
it already anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161122/3891c7e3/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] PCI: iproc: avoid maybe-uninitialized warning
From: Ray Jui @ 2016-11-22 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122141844.1655574-2-arnd@arndb.de>
Hi Arnd,
On 11/22/2016 6:17 AM, Arnd Bergmann wrote:
> gcc notices that calling iproc_pcie_setup_ib with ib->nr_regions==0
> would result in an uninitialized return value:
>
> drivers/pci/host/pcie-iproc.c: In function 'iproc_pcie_setup_ib':
> drivers/pci/host/pcie-iproc.c:894:6: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This can't really happen, but the correct behavior of the function
> is probably to return -EINVAL if it ever did.
>
> Fixes: 4213e15c364e ("PCI: iproc: Make outbound mapping code more generic")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/pci/host/pcie-iproc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index 857ff5198317..0359569c8d78 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -936,6 +936,7 @@ static int iproc_pcie_setup_ib(struct iproc_pcie *pcie,
>
> }
> }
> + ret = -EINVAL;
> err_ib:
> dev_err(dev, "unable to configure inbound mapping\n");
> dev_err(dev, "axi %pap, pci %pap, res size %pap\n",
>
This change is good, but in my opinion, a further improvement for
clarity would be to initialize 'ret' to -EINVAL in the beginning of this
function when 'ret' is declared. What do you think?
Thanks,
Ray
^ permalink raw reply
* [PATCH 1/2] PCI: iproc: fix 32-bit build
From: Ray Jui @ 2016-11-22 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122141844.1655574-1-arnd@arndb.de>
On 11/22/2016 6:17 AM, Arnd Bergmann wrote:
> The newly added code to setup the inbound ranges causes a link error
> on 32-bit machines from a 32-bit division:
>
> drivers/pci/host/pcie-iproc.o: In function `iproc_pcie_setup_ib':
> pcie-iproc.c:(.text.iproc_pcie_setup_ib+0x14c): undefined reference to `__aeabi_uldivmod'
>
> As both sides of the division are always power-of-two numbers and
> we already rely on that, we can use a shift instead.
>
> Fixes: 87c240b19bba ("PCI: iproc: Add inbound DMA mapping support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/pci/host/pcie-iproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index d10e6aa32e0d..857ff5198317 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -865,7 +865,7 @@ static int iproc_pcie_ib_write(struct iproc_pcie *pcie, int region_idx,
> * Now program the IMAP registers. Each IARR region may have one or
> * more IMAP windows.
> */
> - size /= nr_windows;
> + size >>= ilog2(nr_windows);
> for (window_idx = 0; window_idx < nr_windows; window_idx++) {
> val = readl(pcie->base + imap_offset);
> val |= lower_32_bits(axi_addr) | IMAP_VALID;
>
Hmmm, somehow we've never seen this link error for the ARM32 based
platforms that we build for. Does it behave differently between
different versions of compilers?
Nevertheless, this is a good change to take, thanks!
Acked-by: Ray Jui <ray.jui@broadcom.com>
^ permalink raw reply
* Applied "spi: spi-fsl-dspi: Fix incorrect freeing of DMA allocated buffers" to the spi tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fd3b1fa5d9fb2a0c2d1f6ded314acf20f5081a89.1479796821.git.maitysanchayan@gmail.com>
The patch
spi: spi-fsl-dspi: Fix incorrect freeing of DMA allocated buffers
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.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 27d21e9f988e527982a7516fcf411994f498787d Mon Sep 17 00:00:00 2001
From: Sanchayan Maity <maitysanchayan@gmail.com>
Date: Tue, 22 Nov 2016 12:31:32 +0530
Subject: [PATCH] spi: spi-fsl-dspi: Fix incorrect freeing of DMA allocated
buffers
Buffers allocated with a call to dma_alloc_coherent should be
freed with dma_free_coherent instead of the currently used
devm_kfree.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-fsl-dspi.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index b1ee1f521ba0..22f7ce1279bd 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -427,9 +427,11 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr)
return 0;
err_slave_config:
- devm_kfree(dev, dma->rx_dma_buf);
+ dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
+ dma->rx_dma_buf, dma->rx_dma_phys);
err_rx_dma_buf:
- devm_kfree(dev, dma->tx_dma_buf);
+ dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
+ dma->tx_dma_buf, dma->tx_dma_phys);
err_tx_dma_buf:
dma_release_channel(dma->chan_tx);
err_tx_channel:
--
2.10.2
^ permalink raw reply related
* Applied "spi: spi-fsl-dspi: Fix incorrect DMA setup" to the spi tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a36bac5f2499d1002693a7dbf95982bab186e51f.1479706671.git.maitysanchayan@gmail.com>
The patch
spi: spi-fsl-dspi: Fix incorrect DMA setup
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.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 1eaccf210c59e04eb6e9b5469a60d6609c95ac61 Mon Sep 17 00:00:00 2001
From: Sanchayan Maity <maitysanchayan@gmail.com>
Date: Tue, 22 Nov 2016 12:31:30 +0530
Subject: [PATCH] spi: spi-fsl-dspi: Fix incorrect DMA setup
Currently dmaengine_prep_slave_single was being called with length
set to the complete DMA buffer size. This resulted in unwanted bytes
being transferred to the SPI register leading to clock and MOSI lines
having unwanted data even after chip select got deasserted and the
required bytes having been transferred.
While at it also clean up the use of curr_xfer_len which is central
to the DMA setup, from bytes to DMA transfers for every use.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-fsl-dspi.c | 35 ++++++++++++++++++-----------------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 22f7ce1279bd..cb41c327bd77 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -151,6 +151,7 @@ static const struct fsl_dspi_devtype_data ls2085a_data = {
};
struct fsl_dspi_dma {
+ /* Length of transfer in words of DSPI_FIFO_SIZE */
u32 curr_xfer_len;
u32 *tx_dma_buf;
@@ -217,15 +218,13 @@ static void dspi_rx_dma_callback(void *arg)
struct fsl_dspi *dspi = arg;
struct fsl_dspi_dma *dma = dspi->dma;
int rx_word;
- int i, len;
+ int i;
u16 d;
rx_word = is_double_byte_mode(dspi);
- len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
- for (i = 0; i < len; i++) {
+ for (i = 0; i < dma->curr_xfer_len; i++) {
d = dspi->dma->rx_dma_buf[i];
rx_word ? (*(u16 *)dspi->rx = d) :
(*(u8 *)dspi->rx = d);
@@ -242,14 +241,12 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
struct device *dev = &dspi->pdev->dev;
int time_left;
int tx_word;
- int i, len;
+ int i;
u16 val;
tx_word = is_double_byte_mode(dspi);
- len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
- for (i = 0; i < len - 1; i++) {
+ for (i = 0; i < dma->curr_xfer_len - 1; i++) {
val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] =
SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
@@ -265,7 +262,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->tx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -281,7 +280,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
dma->rx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->rx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -328,17 +329,17 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
struct device *dev = &dspi->pdev->dev;
int curr_remaining_bytes;
int bytes_per_buffer;
- int tx_word;
+ int word = 1;
int ret = 0;
- tx_word = is_double_byte_mode(dspi);
+ if (is_double_byte_mode(dspi))
+ word = 2;
curr_remaining_bytes = dspi->len;
+ bytes_per_buffer = DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE;
while (curr_remaining_bytes) {
/* Check if current transfer fits the DMA buffer */
- dma->curr_xfer_len = curr_remaining_bytes;
- bytes_per_buffer = DSPI_DMA_BUFSIZE /
- (DSPI_FIFO_SIZE / (tx_word ? 2 : 1));
- if (curr_remaining_bytes > bytes_per_buffer)
+ dma->curr_xfer_len = curr_remaining_bytes / word;
+ if (dma->curr_xfer_len > bytes_per_buffer)
dma->curr_xfer_len = bytes_per_buffer;
ret = dspi_next_xfer_dma_submit(dspi);
@@ -347,7 +348,7 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
goto exit;
} else {
- curr_remaining_bytes -= dma->curr_xfer_len;
+ curr_remaining_bytes -= dma->curr_xfer_len * word;
if (curr_remaining_bytes < 0)
curr_remaining_bytes = 0;
dspi->len = curr_remaining_bytes;
--
2.10.2
^ permalink raw reply related
* Applied "spi: spi-fsl-dspi: Fix continuous selection format" to the spi tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fd5dac77580ba02edb38319d04345e23a34b2d9d.1479796821.git.maitysanchayan@gmail.com>
The patch
spi: spi-fsl-dspi: Fix continuous selection format
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.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 ccf7d8ee3d6eb600338a184e9a192ec1d5aee924 Mon Sep 17 00:00:00 2001
From: Sanchayan Maity <maitysanchayan@gmail.com>
Date: Tue, 22 Nov 2016 12:31:31 +0530
Subject: [PATCH] spi: spi-fsl-dspi: Fix continuous selection format
Current DMA implementation was not handling the continuous selection
format viz. SPI chip select would be deasserted even between sequential
serial transfers.
Use existing dspi_data_to_pushr function to restructure the transmit
code path and set or reset the CONT bit on same lines as code path
in EOQ mode does. This correctly implements continuous selection format
while also correcting and cleaning up the transmit code path.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-fsl-dspi.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index cb41c327bd77..7ada112bfd85 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -196,6 +196,8 @@ struct fsl_dspi {
struct fsl_dspi_dma *dma;
};
+static u32 dspi_data_to_pushr(struct fsl_dspi *dspi, int tx_word);
+
static inline int is_double_byte_mode(struct fsl_dspi *dspi)
{
unsigned int val;
@@ -242,24 +244,15 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
int time_left;
int tx_word;
int i;
- u16 val;
tx_word = is_double_byte_mode(dspi);
- for (i = 0; i < dma->curr_xfer_len - 1; i++) {
- val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
- dspi->dma->tx_dma_buf[i] =
- SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
- SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
- dspi->tx += tx_word + 1;
+ for (i = 0; i < dma->curr_xfer_len; i++) {
+ dspi->dma->tx_dma_buf[i] = dspi_data_to_pushr(dspi, tx_word);
+ if ((dspi->cs_change) && (!dspi->len))
+ dspi->dma->tx_dma_buf[i] &= ~SPI_PUSHR_CONT;
}
- val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
- dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
- SPI_PUSHR_PCS(dspi->cs) |
- SPI_PUSHR_CTAS(0);
- dspi->tx += tx_word + 1;
-
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
dma->curr_xfer_len *
@@ -351,7 +344,6 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
curr_remaining_bytes -= dma->curr_xfer_len * word;
if (curr_remaining_bytes < 0)
curr_remaining_bytes = 0;
- dspi->len = curr_remaining_bytes;
}
}
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: samsung: Remove non-existing MACH dependencies" to the asoc tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479566911-5580-2-git-send-email-krzk@kernel.org>
The patch
ASoC: samsung: Remove non-existing MACH dependencies
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 f8cbab42d98298ab9c4878dc9105d350b0b902ff Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Sun, 20 Nov 2016 21:24:51 +0200
Subject: [PATCH] ASoC: samsung: Remove non-existing MACH dependencies
MACH_SMDKC100 was removed in commit b8529ec1c1b0 ("ARM: S5PC100: no more
support S5PC100 SoC"). MACH_SMDKV210 and MACH_SMDKC110 in commit
28c8331d386 ("ARM: S5PV210: Remove support for board files").
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 79ae6a7c93ff..ea0fa9971a0c 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -49,7 +49,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750
config SND_SOC_SAMSUNG_SMDK_WM8580
tristate "SoC I2S Audio support for WM8580 on SMDK"
- depends on MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110
+ depends on MACH_SMDK6410
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_I2S
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage" to the asoc tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479669895-19124-3-git-send-email-krzk@kernel.org>
The patch
ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage
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 cd9e2b62768c21c051c585f9d4935b4fa6e9603e Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Sun, 20 Nov 2016 21:24:52 +0200
Subject: [PATCH] ASoC: samsung: smdk_wm8580: Remove old platforms and drop
mach-types usage
MACH_SMDKC100, MACH_SMDKV210 and MACH_SMDKC110 are no longer supported
so we can drop the dead code. After this the driver no longer
differentiates between machines (S3C24xx machines are not supported by
it) so there is no need to override I2S device id in cpu_dai_name and
SEC_PLAYBACK dai_link can be removed as well.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/smdk_wm8580.c | 30 +++---------------------------
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/sound/soc/samsung/smdk_wm8580.c b/sound/soc/samsung/smdk_wm8580.c
index 548bfd993788..de724ce7b955 100644
--- a/sound/soc/samsung/smdk_wm8580.c
+++ b/sound/soc/samsung/smdk_wm8580.c
@@ -14,8 +14,6 @@
#include <sound/soc.h>
#include <sound/pcm_params.h>
-#include <asm/mach-types.h>
-
#include "../codecs/wm8580.h"
#include "i2s.h"
@@ -147,7 +145,6 @@ static int smdk_wm8580_init_paiftx(struct snd_soc_pcm_runtime *rtd)
enum {
PRI_PLAYBACK = 0,
PRI_CAPTURE,
- SEC_PLAYBACK,
};
#define SMDK_DAI_FMT (SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | \
@@ -157,7 +154,7 @@ static struct snd_soc_dai_link smdk_dai[] = {
[PRI_PLAYBACK] = { /* Primary Playback i/f */
.name = "WM8580 PAIF RX",
.stream_name = "Playback",
- .cpu_dai_name = "samsung-i2s.0",
+ .cpu_dai_name = "samsung-i2s.2",
.codec_dai_name = "wm8580-hifi-playback",
.platform_name = "samsung-i2s.0",
.codec_name = "wm8580.0-001b",
@@ -167,7 +164,7 @@ static struct snd_soc_dai_link smdk_dai[] = {
[PRI_CAPTURE] = { /* Primary Capture i/f */
.name = "WM8580 PAIF TX",
.stream_name = "Capture",
- .cpu_dai_name = "samsung-i2s.0",
+ .cpu_dai_name = "samsung-i2s.2",
.codec_dai_name = "wm8580-hifi-capture",
.platform_name = "samsung-i2s.0",
.codec_name = "wm8580.0-001b",
@@ -175,23 +172,13 @@ static struct snd_soc_dai_link smdk_dai[] = {
.init = smdk_wm8580_init_paiftx,
.ops = &smdk_ops,
},
- [SEC_PLAYBACK] = { /* Sec_Fifo Playback i/f */
- .name = "Sec_FIFO TX",
- .stream_name = "Playback",
- .cpu_dai_name = "samsung-i2s-sec",
- .codec_dai_name = "wm8580-hifi-playback",
- .platform_name = "samsung-i2s-sec",
- .codec_name = "wm8580.0-001b",
- .dai_fmt = SMDK_DAI_FMT,
- .ops = &smdk_ops,
- },
};
static struct snd_soc_card smdk = {
.name = "SMDK-I2S",
.owner = THIS_MODULE,
.dai_link = smdk_dai,
- .num_links = 2,
+ .num_links = ARRAY_SIZE(smdk_dai),
.dapm_widgets = smdk_wm8580_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(smdk_wm8580_dapm_widgets),
@@ -204,17 +191,6 @@ static struct platform_device *smdk_snd_device;
static int __init smdk_audio_init(void)
{
int ret;
- char *str;
-
- if (machine_is_smdkc100()
- || machine_is_smdkv210() || machine_is_smdkc110()) {
- smdk.num_links = 3;
- } else if (machine_is_smdk6410()) {
- str = (char *)smdk_dai[PRI_PLAYBACK].cpu_dai_name;
- str[strlen(str) - 1] = '2';
- str = (char *)smdk_dai[PRI_CAPTURE].cpu_dai_name;
- str[strlen(str) - 1] = '2';
- }
smdk_snd_device = platform_device_alloc("soc-audio", -1);
if (!smdk_snd_device)
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: samsung: Enable COMPILE_TEST for entire Samsung ASoc" to the asoc tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479566911-5580-6-git-send-email-krzk@kernel.org>
The patch
ASoC: samsung: Enable COMPILE_TEST for entire Samsung ASoc
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 a41dcdeee5d87cf3852b857cc3a8507832ec8b42 Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Sun, 20 Nov 2016 21:24:54 +0200
Subject: [PATCH] ASoC: samsung: Enable COMPILE_TEST for entire Samsung ASoc
Instead of build time, Samsung ASoC drivers have rather runtime
dependency on Exynos or other Samsung platforms. For building they
require Common Clock Framework. If it is provided they could be compile
tested to increase build coverage.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index ea0fa9971a0c..48dcd3dd9ec7 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -1,6 +1,7 @@
menuconfig SND_SOC_SAMSUNG
tristate "ASoC support for Samsung"
- depends on (PLAT_SAMSUNG || ARCH_EXYNOS)
+ depends on PLAT_SAMSUNG || ARCH_EXYNOS || COMPILE_TEST
+ depends on COMMON_CLK
select SND_SOC_GENERIC_DMAENGINE_PCM
---help---
Say Y or M if you want to add support for codecs attached to
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: samsung: Enable COMPILE_TEST for SmartQ and WM8580" to the asoc tree
From: Mark Brown @ 2016-11-22 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479566911-5580-5-git-send-email-krzk@kernel.org>
The patch
ASoC: samsung: Enable COMPILE_TEST for SmartQ and WM8580
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 95f5609d223d661419061bd6231da01a317c30d9 Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Sun, 20 Nov 2016 21:24:53 +0200
Subject: [PATCH] ASoC: samsung: Enable COMPILE_TEST for SmartQ and WM8580
The I2S sound drivers for SmartQ board and WM8580 codec can be compile
tested to increase build coverage.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 48dcd3dd9ec7..a6cc6ca93fa7 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -50,7 +50,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750
config SND_SOC_SAMSUNG_SMDK_WM8580
tristate "SoC I2S Audio support for WM8580 on SMDK"
- depends on MACH_SMDK6410
+ depends on MACH_SMDK6410 || COMPILE_TEST
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_I2S
@@ -110,7 +110,8 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380
config SND_SOC_SMARTQ
tristate "SoC I2S Audio support for SmartQ board"
- depends on MACH_SMARTQ && I2C
+ depends on MACH_SMARTQ || COMPILE_TEST
+ depends on I2C
select SND_SAMSUNG_I2S
select SND_SOC_WM8750
--
2.10.2
^ permalink raw reply related
* [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Gregory CLEMENT @ 2016-11-22 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15b06a12-ed69-03a7-ccc7-0c133ce1ac1e@marvell.com>
Hi Rob,
On jeu., nov. 10 2016, Ziji Hu <huziji@marvell.com> wrote:
[...]
>>> +
>>> +- reg:
>>> + * For "marvell,xenon-sdhci", one register area for Xenon IP.
>>> +
>>> + * For "marvell,armada-3700-sdhci", two register areas.
>>> + The first one for Xenon IP register. The second one for the Armada 3700 SOC
>>> + PHY PAD Voltage Control register.
>>> + Please follow the examples with compatible "marvell,armada-3700-sdhci"
>>> + in below.
>>> + Please also check property marvell,pad-type in below.
>>> +
>>> +Optional Properties:
>>> +- marvell,xenon-slotno:
>>
>> Multiple slots should be represented as child nodes IMO. I think some
>> other bindings already do this.
>>
>
> All the slots are entirely independent.
> I prefer to consider it as multiple independent SDHCs placed in
> a single IP, instead of that a IP contains multiple child slots.
It was indeed what I tried to show in my answer for the 1st version:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461860.html
Maybe you missed it.
You also mentioned other bindings using child nodes, but for this one
we have one controller with only one set of register with multiple slots
(Atmel is an example). Here each slot have it own set of register.
Actually giving the fact that each slot is controlled by a different set
of register I wonder why the hardware can't also deduce the slot number
from the address register. For me it looks like an hardware bug but we
have to deal with it.
Do you still think we needchild node here?
>
> It is unlike the implementation which put multiple slots behind PCIe EP interface. sdhci-pci.c will handle each slot init one by one.
> If Xenon SDHC slots are represented as child nodes, there should also be a main entry in Xenon driver to init each child node one by one.
> In my very own opinion, it is inconvenient and unnecessary.
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 5/7] add bindings for stm32 IIO timer drivers
From: Lee Jones @ 2016-11-22 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks6ZoOND4VobU65OntEYU-f_XoNCV4wNZZ0_dYoOxy73+w@mail.gmail.com>
On Tue, 22 Nov 2016, Benjamin Gaignard wrote:
> [snip]
> >> + "st,stm32-iio-timer5"
> >> + "st,stm32-iio-timer6"
> >> + "st,stm32-iio-timer7"
> >> + "st,stm32-iio-timer8"
> >> + "st,stm32-iio-timer9"
> >> + "st,stm32-iio-timer10"
> >> + "st,stm32-iio-timer11"
> >> + "st,stm32-iio-timer12"
> >> + "st,stm32-iio-timer13"
> >> + "st,stm32-iio-timer14"
> >
> > We can't do this. This is a binding for a driver, not for the hardware.
> >
>
> Unfortunately each instance for the hardware IP have little
> differences like which triggers they could accept or size of the
> counter register,
> and I doesn't have value inside the hardware to distinguish them so
> the only way I found is to use compatible.
Can't you represent these as properties?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/2] serial: imx: make DSR irq handling conditional
From: Christoph Fritz @ 2016-11-22 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479834851-32442-1-git-send-email-chf.fritz@googlemail.com>
This patch makes use of device-tree property disable-dsr. Disabling
DSR can be necessary on i.MX6SX to quirk buggy hardware, for more
info see commit 276b891e3879 ("ARM: dts: imx6sx: document SION
necessity of ENET1_REF_CLK1").
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
---
drivers/tty/serial/imx.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 0df2b1c..bd85a69a4 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -207,6 +207,7 @@ struct imx_port {
unsigned int dte_mode:1;
unsigned int irda_inv_rx:1;
unsigned int irda_inv_tx:1;
+ unsigned int dsr:1;
unsigned short trcv_delay; /* transceiver delay */
struct clk *clk_ipg;
struct clk *clk_per;
@@ -1219,7 +1220,8 @@ static int imx_startup(struct uart_port *port)
/*
* Finally, clear and enable interrupts
*/
- writel(USR1_RTSD | USR1_DTRD, sport->port.membase + USR1);
+ temp = USR1_RTSD | (sport->dsr ? USR1_DTRD : 0);
+ writel(temp, sport->port.membase + USR1);
writel(USR2_ORE, sport->port.membase + USR2);
if (sport->dma_is_inited && !sport->dma_is_enabled)
@@ -1259,7 +1261,7 @@ static int imx_startup(struct uart_port *port)
* now, too.
*/
temp |= IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP |
- UCR3_DTRDEN | UCR3_RI | UCR3_DCD;
+ (sport->dsr ? UCR3_DTRDEN : 0) | UCR3_RI | UCR3_DCD;
if (sport->dte_mode)
temp &= ~(UCR3_RI | UCR3_DCD);
@@ -1987,6 +1989,9 @@ static int serial_imx_probe_dt(struct imx_port *sport,
if (of_get_property(np, "fsl,dte-mode", NULL))
sport->dte_mode = 1;
+ if (!of_property_read_bool(np, "disable-dsr"))
+ sport->dsr = 1;
+
return 0;
}
#else
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] doc: DT: add generic serial property to disable DSR
From: Christoph Fritz @ 2016-11-22 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479834851-32442-1-git-send-email-chf.fritz@googlemail.com>
Introduce a generic serial property to disable DSR events which
can be necessary for buggy hardware.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
---
Documentation/devicetree/bindings/serial/serial.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/serial.txt b/Documentation/devicetree/bindings/serial/serial.txt
index fd970f7..26e274e 100644
--- a/Documentation/devicetree/bindings/serial/serial.txt
+++ b/Documentation/devicetree/bindings/serial/serial.txt
@@ -25,6 +25,8 @@ Optional properties:
Note that this property is mutually-exclusive with "cts-gpios" and
"rts-gpios" above.
+ - disable-dsr: The presence of this property disables DSR events reporting.
+
Examples:
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2] serial: introduce DSR handling property
From: Christoph Fritz @ 2016-11-22 17:14 UTC (permalink / raw)
To: linux-arm-kernel
This patchset introduces device-tree property "disable-dsr" including
documentation and usage.
Christoph Fritz (2):
doc: DT: add generic serial property to disable DSR
serial: imx: make DSR irq handling conditional
Documentation/devicetree/bindings/serial/serial.txt | 2 ++
drivers/tty/serial/imx.c | 9 +++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH V5 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64
From: Baicar, Tyler @ 2016-11-22 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d5e199f2-c23e-9599-7ed7-e54475311a39@huawei.com>
Thank you John! Let me know how it goes and if you have any questions :)
Tyler
On 11/22/2016 4:11 AM, John Garry wrote:
> +
>
> We'll try and test this on our platform.
>
> Cheers,
> John
>
> On 21/11/2016 22:35, Tyler Baicar wrote:
>> When a memory error, CPU error, PCIe error, or other type of hardware
>> error
>> that's covered by RAS occurs, firmware should populate the shared
>> GHES memory
>> location with the proper GHES structures to notify the OS of the error.
>> For example, platforms that implement firmware first handling may
>> implement
>> separate GHES sources for corrected errors and uncorrected errors. If
>> the
>> error is an uncorrectable error, then the firmware will notify the OS
>> immediately since the error needs to be handled ASAP. The OS will
>> then be able
>> to take the appropriate action needed such as offlining a page. If
>> the error
>> is a corrected error, then the firmware will not interrupt the OS
>> immediately.
>> Instead, the OS will see and report the error the next time it's GHES
>> timer
>> expires. The kernel will first parse the GHES structures and report
>> the errors
>> through the kernel logs and then notify the user space through RAS trace
>> events. This allows user space applications such as RAS Daemon to see
>> the
>> errors and report them however the user desires. This patchset
>> extends the
>> kernel functionality for RAS errors based on updates in the UEFI 2.6 and
>> ACPI 6.1 specifications.
>>
>> An example flow from firmware to user space could be:
>>
>> +---------------+
>> +-------->| |
>> | | GHES polling |--+
>> +-------------+ | source | | +---------------+ +------------+
>> | | +---------------+ | | Kernel GHES | | |
>> | Firmware | +-->| CPER AER and |-->| RAS
>> trace |
>> | | +---------------+ | | EDAC drivers | | event |
>> +-------------+ | | | +---------------+ +------------+
>> | | GHES sci |--+
>> +-------->| source |
>> +---------------+
>>
>> Add support for Generic Hardware Error Source (GHES) v2, which
>> introduces the
>> capability for the OS to acknowledge the consumption of the error record
>> generated by the Reliability, Availability and Serviceability (RAS)
>> controller.
>> This eliminates potential race conditions between the OS and the RAS
>> controller.
>>
>> Add support for the timestamp field added to the Generic Error Data
>> Entry v3,
>> allowing the OS to log the time that the error is generated by the
>> firmware,
>> rather than the time the error is consumed. This improves the
>> correctness of
>> event sequences when analyzing error logs. The timestamp is added in
>> ACPI 6.1, reference Table 18-343 Generic Error Data Entry.
>>
>> Add support for ARMv8 Common Platform Error Record (CPER) per UEFI 2.6
>> specification. ARMv8 specific processor error information is reported
>> as part of
>> the CPER records. This provides more detail on for processor error
>> logs. This
>> can help describe ARMv8 cache, tlb, and bus errors.
>>
>> Synchronous External Abort (SEA) represents a specific processor
>> error condition
>> in ARM systems. A handler is added to recognize SEA errors, and a
>> notifier is
>> added to parse and report the errors before the process is killed.
>> Refer to
>> section N.2.1.1 in the Common Platform Error Record appendix of the
>> UEFI 2.6
>> specification.
>>
>> Currently the kernel ignores CPER records that are unrecognized.
>> On the other hand, UEFI spec allows for non-standard (eg. vendor
>> proprietary) error section type in CPER (Common Platform Error Record),
>> as defined in section N2.3 of UEFI version 2.5. Therefore, user
>> is not able to see hardware error data of non-standard section.
>>
>> If section Type field of Generic Error Data Entry is unrecognized,
>> prints out the raw data in dmesg buffer, and also adds a tracepoint
>> for reporting such hardware errors.
>>
>> Currently even if an error status block's severity is fatal, the kernel
>> does not honor the severity level and panic. With the firmware first
>> model, the platform could inform the OS about a fatal hardware error
>> through the non-NMI GHES notification type. The OS should panic when a
>> hardware error record is received with this severity.
>>
>> Add support to handle SEAs that occur while a KVM guest kernel is
>> running. Currently these are unsupported by the guest abort handling.
>>
>> Depends on: [PATCH v14] acpi, apei, arm64: APEI initial support for
>> aarch64.
>> https://lkml.org/lkml/2016/8/10/231
>>
>> V5: Fix GHES goto logic for error conditions
>> Change ghes_do_read_ack to ghes_ack_error
>> Make sure data version check is >= 3
>> Use CPER helper functions in print functions
>> Make handle_guest_sea() dummy function static for arm
>> Add arm to subject line for KVM patch
>>
>> V4: Add bit offset left shift to read_ack_write value
>> Make HEST generic and generic_v2 structures a union in the ghes
>> structure
>> Move gdata v3 helper functions into ghes.h to avoid duplication
>> Reorder the timestamp print and avoid memcpy
>> Add helper functions for gdata size checking
>> Rename the SEA functions
>> Add helper function for GHES panics
>> Set fru_id to NULL UUID at variable declaration
>> Limit ARM trace event parameters to the needed structures
>> Reorder the ARM trace event variables to save space
>> Add comment for why we don't pass SEAs to the guest when it aborts
>> Move ARM trace event call into GHES driver instead of CPER
>>
>> V3: Fix unmapped address to the read_ack_register in ghes.c
>> Add helper function to get the proper payload based on generic
>> data entry
>> version
>> Move timestamp print to avoid changing function calls in cper.c
>> Remove patch "arm64: exception: handle instruction abort at
>> current EL"
>> since the el1_ia handler is already added in 4.8
>> Add EFI and ARM64 dependencies for HAVE_ACPI_APEI_SEA
>> Add a new trace event for ARM type errors
>> Add support to handle KVM guest SEAs
>>
>> V2: Add PSCI state print for the ARMv8 error type.
>> Separate timestamp year into year and century using BCD format.
>> Rebase on top of ACPICA 20160318 release and remove header file
>> changes
>> in include/acpi/actbl1.h.
>> Add panic OS with fatal error status block patch.
>> Add processing of unrecognized CPER error section patches with
>> updates
>> from previous comments. Original patches:
>> https://lkml.org/lkml/2015/9/8/646
>>
>> V1: https://lkml.org/lkml/2016/2/5/544
>>
>> Jonathan (Zhixiong) Zhang (1):
>> acpi: apei: panic OS with fatal error status block
>>
>> Tyler Baicar (9):
>> acpi: apei: read ack upon ghes record consumption
>> ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
>> efi: parse ARMv8 processor error
>> arm64: exception: handle Synchronous External Abort
>> acpi: apei: handle SEA notification type for ARMv8
>> efi: print unrecognized CPER section
>> ras: acpi / apei: generate trace event for unrecognized CPER section
>> trace, ras: add ARM processor error trace event
>> arm/arm64: KVM: add guest SEA support
>>
>> arch/arm/include/asm/kvm_arm.h | 1 +
>> arch/arm/include/asm/system_misc.h | 5 +
>> arch/arm/kvm/mmu.c | 18 ++-
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/kvm_arm.h | 1 +
>> arch/arm64/include/asm/system_misc.h | 15 +++
>> arch/arm64/mm/fault.c | 71 ++++++++++--
>> drivers/acpi/apei/Kconfig | 14 +++
>> drivers/acpi/apei/ghes.c | 188
>> ++++++++++++++++++++++++++++---
>> drivers/acpi/apei/hest.c | 7 +-
>> drivers/firmware/efi/cper.c | 210
>> ++++++++++++++++++++++++++++++++---
>> drivers/ras/ras.c | 2 +
>> include/acpi/ghes.h | 15 ++-
>> include/linux/cper.h | 84 ++++++++++++++
>> include/ras/ras_event.h | 100 +++++++++++++++++
>> 15 files changed, 688 insertions(+), 44 deletions(-)
>>
>
>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Emmanuel Vadot @ 2016-11-22 17:06 UTC (permalink / raw)
To: linux-arm-kernel
The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
others three only have 1.
Add the num-cs property to each node.
Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 94cf5a1..ed21982 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -871,6 +871,7 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = 4;
};
spi1: spi at 01c06000 {
@@ -885,6 +886,7 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = 1;
};
emac: ethernet at 01c0b000 {
@@ -1037,6 +1039,7 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = 1;
};
ahci: sata at 01c18000 {
@@ -1079,6 +1082,7 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+ num-cs = 1;
};
pio: pinctrl at 01c20800 {
--
2.9.2
^ permalink raw reply related
* [RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros
From: Vladimir Murzin @ 2016-11-22 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122115456.GX1041@n2100.armlinux.org.uk>
On 22/11/16 11:54, Russell King - ARM Linux wrote:
> On Tue, Nov 22, 2016 at 11:50:57AM +0000, Vladimir Murzin wrote:
>> On 22/11/16 10:07, Russell King - ARM Linux wrote:
>>> On Tue, Nov 22, 2016 at 09:26:06AM +0000, Vladimir Murzin wrote:
>>>> Pickup defines from pgtable-2level.h to make NOMMU build happy.
>>>
>>> This needs more detail.
>>>
>>
>> It comes from
>>
>> CC arch/arm/kernel/setup.o
>> arch/arm/kernel/setup.c: In function 'reserve_crashkernel':
>> arch/arm/kernel/setup.c:1001:25: error: 'SECTION_SIZE' undeclared (first use in this function)
>> crash_size, SECTION_SIZE);
>> ^
>> arch/arm/kernel/setup.c:1001:25: note: each undeclared identifier is reported only once for each function it appears in
>> make[1]: *** [arch/arm/kernel/setup.o] Error 1
>> make: *** [arch/arm/kernel] Error 2
>
> Hmm, I decided not to use CRASH_ALIGN there because I didn't want to
> break anyone's existing setup unnecessarily, however arguably it
> should be CRASH_ALIGN to ensure that the new kernel is properly
> positioned.
>
> I wonder if we can get away with changing that, rather than
> unnecessarily introducing these otherwise meaningless definitions
> for R-class.
>
CRASH_ALIGN works fine but it seems not only user of SECTION_SIZE
In file included from ./include/linux/cache.h:4:0,
from ./include/linux/printk.h:8,
from ./include/linux/kernel.h:13,
from arch/arm/mach-omap2/omap-secure.c:15:
arch/arm/mach-omap2/omap-secure.c: In function 'omap_secure_ram_reserve_memblock':
arch/arm/mach-omap2/omap-secure.c:65:21: error: 'SECTION_SIZE' undeclared (first use in this function)
size = ALIGN(size, SECTION_SIZE);
^
./include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK'
#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
^
./include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
#define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
^
arch/arm/mach-omap2/omap-secure.c:65:9: note: in expansion of macro 'ALIGN'
size = ALIGN(size, SECTION_SIZE);
^
arch/arm/mach-omap2/omap-secure.c:65:21: note: each undeclared identifier is reported only once for each function it appears in
size = ALIGN(size, SECTION_SIZE);
^
./include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK'
#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
^
./include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
#define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
^
arch/arm/mach-omap2/omap-secure.c:65:9: note: in expansion of macro 'ALIGN'
size = ALIGN(size, SECTION_SIZE);
^
make[1]: *** [arch/arm/mach-omap2/omap-secure.o] Error 1
Cheers
Vladimir
^ permalink raw reply
* [PATCH 5/7] add bindings for stm32 IIO timer drivers
From: Lars-Peter Clausen @ 2016-11-22 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks6ZoOND4VobU65OntEYU-f_XoNCV4wNZZ0_dYoOxy73+w@mail.gmail.com>
On 11/22/2016 06:01 PM, Benjamin Gaignard wrote:
> [snip]
>>> + "st,stm32-iio-timer5"
>>> + "st,stm32-iio-timer6"
>>> + "st,stm32-iio-timer7"
>>> + "st,stm32-iio-timer8"
>>> + "st,stm32-iio-timer9"
>>> + "st,stm32-iio-timer10"
>>> + "st,stm32-iio-timer11"
>>> + "st,stm32-iio-timer12"
>>> + "st,stm32-iio-timer13"
>>> + "st,stm32-iio-timer14"
>>
>> We can't do this. This is a binding for a driver, not for the hardware.
>>
>
> Unfortunately each instance for the hardware IP have little
> differences like which triggers they could accept or size of the
> counter register,
> and I doesn't have value inside the hardware to distinguish them so
> the only way I found is to use compatible.
But IIO is not a piece of hardware, its a software framework in the Linux
kernel.
^ permalink raw reply
* [PATCH 5/7] add bindings for stm32 IIO timer drivers
From: Benjamin Gaignard @ 2016-11-22 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b9a82ce7-745a-1c25-f97f-68aaf0551f3b@metafoo.de>
[snip]
>> + "st,stm32-iio-timer5"
>> + "st,stm32-iio-timer6"
>> + "st,stm32-iio-timer7"
>> + "st,stm32-iio-timer8"
>> + "st,stm32-iio-timer9"
>> + "st,stm32-iio-timer10"
>> + "st,stm32-iio-timer11"
>> + "st,stm32-iio-timer12"
>> + "st,stm32-iio-timer13"
>> + "st,stm32-iio-timer14"
>
> We can't do this. This is a binding for a driver, not for the hardware.
>
Unfortunately each instance for the hardware IP have little
differences like which triggers they could accept or size of the
counter register,
and I doesn't have value inside the hardware to distinguish them so
the only way I found is to use compatible.
^ permalink raw reply
* [PATCH 7/7] add stm32 multi-functions timer driver in DT
From: Alexandre Torgue @ 2016-11-22 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479831207-32699-8-git-send-email-benjamin.gaignard@st.com>
Hi Benjamin,
On 11/22/2016 05:13 PM, Benjamin Gaignard wrote:
> Add timers MFD and childs into DT for stm32f4.
> Define and enable pwm1 and pwm3 for stm32f469 discovery board
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
If you have to send a v2 for this series please change commit header by:
"ARM: dts: stm32: ..." (if not I will do it by myself)
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 246 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 29 ++++
> 2 files changed, 275 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index bca491d..28a0fe9 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -355,6 +355,21 @@
> slew-rate = <2>;
> };
> };
> +
> + pwm1_pins: pwm at 1 {
> + pins {
> + pinmux = <STM32F429_PA8_FUNC_TIM1_CH1>,
> + <STM32F429_PB13_FUNC_TIM1_CH1N>,
> + <STM32F429_PB12_FUNC_TIM1_BKIN>;
> + };
> + };
> +
> + pwm3_pins: pwm at 3 {
> + pins {
> + pinmux = <STM32F429_PB4_FUNC_TIM3_CH1>,
> + <STM32F429_PB5_FUNC_TIM3_CH2>;
> + };
> + };
> };
>
> rcc: rcc at 40023810 {
> @@ -426,6 +441,237 @@
> interrupts = <80>;
> clocks = <&rcc 0 38>;
> };
> +
> + mfd_timer1: mfdtimer1 at 40010000 {
> + compatible = "st,stm32-mfd-timer1";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <27>;
> + status = "disabled";
> +
> + pwm1: pwm1 at 40010000 {
> + compatible = "st,stm32-pwm1";
> + status = "disabled";
> + };
> +
> + iiotimer1: iiotimer1 at 40010000 {
> + compatible = "st,stm32-iio-timer1";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer2: mfdtimer2 at 40000000 {
> + compatible = "st,stm32-mfd-timer2";
> + reg = <0x40000000 0x400>;
> + clocks = <&rcc 0 128>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <28>;
> + status = "disabled";
> +
> + pwm2: pwm2 at 40000000 {
> + compatible = "st,stm32-pwm2";
> + status = "disabled";
> + };
> + iiotimer2: iiotimer2 at 40000000 {
> + compatible = "st,stm32-iio-timer2";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer3: mfdtimer3 at 40000400 {
> + compatible = "st,stm32-mfd-timer3";
> + reg = <0x40000400 0x400>;
> + clocks = <&rcc 0 129>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <29>;
> + status = "disabled";
> +
> + pwm3: pwm3 at 40000400 {
> + compatible = "st,stm32-pwm3";
> + status = "disabled";
> + };
> + iiotimer3: iiotimer3 at 40000400 {
> + compatible = "st,stm32-iio-timer3";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer4: mfdtimer4 at 40000800 {
> + compatible = "st,stm32-mfd-timer4";
> + reg = <0x40000800 0x400>;
> + clocks = <&rcc 0 130>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <30>;
> + status = "disabled";
> +
> + pwm4: pwm4 at 40000800 {
> + compatible = "st,stm32-pwm4";
> + status = "disabled";
> + };
> + iiotimer4: iiotimer4 at 40000800 {
> + compatible = "st,stm32-iio-timer4";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer5: mfdtimer5 at 40000C00 {
> + compatible = "st,stm32-mfd-timer5";
> + reg = <0x40000C00 0x400>;
> + clocks = <&rcc 0 131>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <50>;
> + status = "disabled";
> +
> + pwm5: pwm5 at 40000C00 {
> + compatible = "st,stm32-pwm5";
> + status = "disabled";
> + };
> + iiotimer5: iiotimer5 at 40000800 {
> + compatible = "st,stm32-iio-timer5";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer6: mfdtimer6 at 40001000 {
> + compatible = "st,stm32-mfd-timer6";
> + reg = <0x40001000 0x400>;
> + clocks = <&rcc 0 132>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <54>;
> + status = "disabled";
> +
> + iiotimer6: iiotimer6 at 40001000 {
> + compatible = "st,stm32-iio-timer6";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer7: mfdtimer7 at 40001400 {
> + compatible = "st,stm32-mfd-timer7";
> + reg = <0x40001400 0x400>;
> + clocks = <&rcc 0 133>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <55>;
> + status = "disabled";
> +
> + iiotimer7: iiotimer7 at 40001400 {
> + compatible = "st,stm32-iio-timer7";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer8: mfdtimer8 at 40010400 {
> + compatible = "st,stm32-mfd-timer8";
> + reg = <0x40010400 0x400>;
> + clocks = <&rcc 0 161>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <46>;
> + status = "disabled";
> +
> + pwm8: pwm8 at 40010400 {
> + compatible = "st,stm32-pwm8";
> + status = "disabled";
> + };
> +
> + iiotimer8: iiotimer7 at 40010400 {
> + compatible = "st,stm32-iio-timer8";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer9: mfdtimer9 at 40014000 {
> + compatible = "st,stm32-mfd-timer9";
> + reg = <0x40014000 0x400>;
> + clocks = <&rcc 0 176>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <24>;
> + status = "disabled";
> +
> + pwm9: pwm9 at 40014000 {
> + compatible = "st,stm32-pwm9";
> + status = "disabled";
> + };
> +
> + iiotimer9: iiotimer9 at 40014000 {
> + compatible = "st,stm32-iio-timer9";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer10: mfdtimer10 at 40014400 {
> + compatible = "st,stm32-mfd-timer10";
> + reg = <0x40014400 0x400>;
> + clocks = <&rcc 0 177>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <25>;
> + status = "disabled";
> +
> + pwm10: pwm10 at 40014400 {
> + compatible = "st,stm32-pwm10";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer11: mfdtimer11 at 40014800 {
> + compatible = "st,stm32-mfd-timer11";
> + reg = <0x40014800 0x400>;
> + clocks = <&rcc 0 178>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <26>;
> + status = "disabled";
> +
> + pwm11: pwm11 at 40014800 {
> + compatible = "st,stm32-pwm11";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer12: mfdtimer12 at 40001800 {
> + compatible = "st,stm32-mfd-timer12";
> + reg = <0x40001800 0x400>;
> + clocks = <&rcc 0 134>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <43>;
> + status = "disabled";
> +
> + pwm12: pwm12 at 40001800 {
> + compatible = "st,stm32-pwm12";
> + status = "disabled";
> + };
> + iiotimer12: iiotimer12 at 40001800 {
> + compatible = "st,stm32-iio-timer12";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer13: mfdtimer13 at 40001C00 {
> + compatible = "st,stm32-mfd-timer13";
> + reg = <0x40001C00 0x400>;
> + clocks = <&rcc 0 135>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <44>;
> + status = "disabled";
> +
> + pwm13: pwm13 at 40001C00 {
> + compatible = "st,stm32-pwm13";
> + status = "disabled";
> + };
> + };
> +
> + mfd_timer14: mfdtimer14 at 40002000 {
> + compatible = "st,stm32-mfd-timer14";
> + reg = <0x40002000 0x400>;
> + clocks = <&rcc 0 136>;
> + clock-names = "mfd_timer_clk";
> + interrupts = <45>;
> + status = "disabled";
> +
> + pwm14: pwm14 at 40002000 {
> + compatible = "st,stm32-pwm14";
> + status = "disabled";
> + };
> + };
> };
> };
>
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index 8a163d7..a8f1788 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -81,3 +81,32 @@
> &usart3 {
> status = "okay";
> };
> +
> +&mfd_timer1 {
> + status = "okay";
> +};
> +
> +&pwm1 {
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + st,breakinput-polarity = <0>;
> + status = "okay";
> +};
> +
> +&iiotimer1 {
> + status = "okay";
> +};
> +
> +&mfd_timer3 {
> + status = "okay";
> +};
> +
> +&pwm3 {
> + pinctrl-0 = <&pwm3_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
> +
> +&iiotimer3 {
> + status = "okay";
> +};
>
^ permalink raw reply
* [RFC PATCH 2/2] arm64: dts: enable the MUSB controller of Pine64 in host-only mode
From: Icenowy Zheng @ 2016-11-22 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122165902.62543-1-icenowy@aosc.xyz>
A64 has a MUSB controller wired to the USB PHY 0, which is connected
to the upper USB Type-A port of Pine64.
As the port is a Type-A female port, enable it in host-only mode in the
device tree, which makes devices with USB Type-A male port can work on
this port (which is originally designed by Pine64 team).
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Peripheral mode is also proven to work, with dr_mode changed to "peripheral"
and using a Type-A to Type-A cable.
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index f9a11e6..cf91051 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -81,6 +81,11 @@
status = "okay";
};
+&usb_otg {
+ dr_mode = "host";
+ status = "okay";
+};
+
&usbphy {
status = "okay";
};
--
2.10.2
^ permalink raw reply related
* [RFC PATCH 1/2] arm64: dts: add MUSB node to Allwinner A64 dtsi
From: Icenowy Zheng @ 2016-11-22 16:59 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner A64 SoC has a MUSB controller like the one in A33, so add
a node for it, just use the compatible of A33 MUSB.
Host mode is tested to work properly on Pine64 and will be added into
the device tree of Pine64 in next patch.
Peripheral mode is also tested on Pine64, by changing dr_mode property
of usb_otg node and use a non-standard USB Type-A to Type-A cable.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
This patchset depends on my patch which adds usbphy to A64 dtsi.
( http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/469561.html )
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 2572dd6..261324a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -122,6 +122,19 @@
#size-cells = <1>;
ranges;
+ usb_otg: usb at 01c19000 {
+ compatible = "allwinner,sun8i-a33-musb";
+ reg = <0x01c19000 0x0400>;
+ clocks = <&ccu CLK_BUS_OTG>;
+ resets = <&ccu RST_BUS_OTG>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mc";
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ extcon = <&usbphy 0>;
+ status = "disabled";
+ };
+
usbphy: phy at 01c19400 {
compatible = "allwinner,sun50i-a64-usb-phy";
reg = <0x01c19400 0x14>,
--
2.10.2
^ 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