* [PATCH 4/4] serial: 8250_uniphier: avoid locking for FCR register write
From: Masahiro Yamada @ 2016-10-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477296030-7517-1-git-send-email-yamada.masahiro@socionext.com>
The hardware book says, the FCR is combined with a register called
CHAR (it will trigger interrupt when a specific character is
received). At first, I used lock/read/modify/write/unlock dance for
the FCR to not affect the upper bits, but the CHAR is actually never
used. It should not hurt to always clear the CHAR and to handle the
FCR as a normal case. It can save the costly locking.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Denys Vlasenko <dvlasenk@redhat.com>
---
drivers/tty/serial/8250/8250_uniphier.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index 92e7bb7..746680e 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -101,7 +101,7 @@ static unsigned int uniphier_serial_in(struct uart_port *p, int offset)
static void uniphier_serial_out(struct uart_port *p, int offset, int value)
{
unsigned int valshift = 0;
- bool normal = false;
+ bool normal = true;
switch (offset) {
case UART_FCR:
@@ -114,9 +114,9 @@ static void uniphier_serial_out(struct uart_port *p, int offset, int value)
/* fall through */
case UART_MCR:
offset = UNIPHIER_UART_LCR_MCR;
+ normal = false;
break;
default:
- normal = true;
offset <<= UNIPHIER_UART_REGSHIFT;
break;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] serial: 8250_uniphier: hardcode regshift to avoid unneeded memory read
From: Masahiro Yamada @ 2016-10-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477296030-7517-1-git-send-email-yamada.masahiro@socionext.com>
For this driver, uart_port::regshift is always 2. Hardcode the
shift value instead of reading ->regshift to get an already known
value. (pointed out by Denys Vlasenko)
Furthermore, I am using register macros that are already shifted,
which will save code a bit.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/tty/serial/8250/8250_uniphier.c | 42 +++++++++++++++++++--------------
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index 417d9e7..92e7bb7 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -24,10 +24,22 @@
/* Most (but not all) of UniPhier UART devices have 64-depth FIFO. */
#define UNIPHIER_UART_DEFAULT_FIFO_SIZE 64
-#define UNIPHIER_UART_CHAR_FCR 3 /* Character / FIFO Control Register */
-#define UNIPHIER_UART_LCR_MCR 4 /* Line/Modem Control Register */
-#define UNIPHIER_UART_LCR_SHIFT 8
-#define UNIPHIER_UART_DLR 9 /* Divisor Latch Register */
+/*
+ * This hardware is similar to 8250, but its register map is a bit different:
+ * - MMIO32 (regshift = 2)
+ * - FCR is not at 2, but 3
+ * - LCR and MCR are not at 3 and 4, they share 4
+ * - Divisor latch at 9, no divisor latch access bit
+ */
+
+#define UNIPHIER_UART_REGSHIFT 2
+
+/* bit[15:8] = CHAR (not used), bit[7:0] = FCR */
+#define UNIPHIER_UART_CHAR_FCR (3 << (UNIPHIER_UART_REGSHIFT))
+/* bit[15:8] = LCR, bit[7:0] = MCR */
+#define UNIPHIER_UART_LCR_MCR (4 << (UNIPHIER_UART_REGSHIFT))
+/* Divisor Latch Register */
+#define UNIPHIER_UART_DLR (9 << (UNIPHIER_UART_REGSHIFT))
struct uniphier8250_priv {
int line;
@@ -44,7 +56,7 @@ static int __init uniphier_early_console_setup(struct earlycon_device *device,
/* This hardware always expects MMIO32 register interface. */
device->port.iotype = UPIO_MEM32;
- device->port.regshift = 2;
+ device->port.regshift = UNIPHIER_UART_REGSHIFT;
/*
* Do not touch the divisor register in early_serial8250_setup();
@@ -68,17 +80,16 @@ static unsigned int uniphier_serial_in(struct uart_port *p, int offset)
switch (offset) {
case UART_LCR:
- valshift = UNIPHIER_UART_LCR_SHIFT;
+ valshift = 8;
/* fall through */
case UART_MCR:
offset = UNIPHIER_UART_LCR_MCR;
break;
default:
+ offset <<= UNIPHIER_UART_REGSHIFT;
break;
}
- offset <<= p->regshift;
-
/*
* The return value must be masked with 0xff because LCR and MCR reside
* in the same register that must be accessed by 32-bit write/read.
@@ -97,7 +108,7 @@ static void uniphier_serial_out(struct uart_port *p, int offset, int value)
offset = UNIPHIER_UART_CHAR_FCR;
break;
case UART_LCR:
- valshift = UNIPHIER_UART_LCR_SHIFT;
+ valshift = 8;
/* Divisor latch access bit does not exist. */
value &= ~UART_LCR_DLAB;
/* fall through */
@@ -106,11 +117,10 @@ static void uniphier_serial_out(struct uart_port *p, int offset, int value)
break;
default:
normal = true;
+ offset <<= UNIPHIER_UART_REGSHIFT;
break;
}
- offset <<= p->regshift;
-
if (normal) {
writel(value, p->membase + offset);
} else {
@@ -139,16 +149,12 @@ static void uniphier_serial_out(struct uart_port *p, int offset, int value)
*/
static int uniphier_serial_dl_read(struct uart_8250_port *up)
{
- int offset = UNIPHIER_UART_DLR << up->port.regshift;
-
- return readl(up->port.membase + offset);
+ return readl(up->port.membase + UNIPHIER_UART_DLR);
}
static void uniphier_serial_dl_write(struct uart_8250_port *up, int value)
{
- int offset = UNIPHIER_UART_DLR << up->port.regshift;
-
- writel(value, up->port.membase + offset);
+ writel(value, up->port.membase + UNIPHIER_UART_DLR);
}
static int uniphier_of_serial_setup(struct device *dev, struct uart_port *port,
@@ -234,7 +240,7 @@ static int uniphier_uart_probe(struct platform_device *pdev)
up.port.type = PORT_16550A;
up.port.iotype = UPIO_MEM32;
- up.port.regshift = 2;
+ up.port.regshift = UNIPHIER_UART_REGSHIFT;
up.port.flags = UPF_FIXED_PORT | UPF_FIXED_TYPE;
up.capabilities = UART_CAP_FIFO;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] serial: 8250_uniphier: fix clearing divisor latch access bit
From: Masahiro Yamada @ 2016-10-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477296030-7517-1-git-send-email-yamada.masahiro@socionext.com>
At this point, 'value' is always a byte, then this code is clearing
bit 15, which is already clear. I meant to clear bit 7.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Denys Vlasenko <dvlasenk@redhat.com>
---
drivers/tty/serial/8250/8250_uniphier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index a8babb0..417d9e7 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -99,7 +99,7 @@ static void uniphier_serial_out(struct uart_port *p, int offset, int value)
case UART_LCR:
valshift = UNIPHIER_UART_LCR_SHIFT;
/* Divisor latch access bit does not exist. */
- value &= ~(UART_LCR_DLAB << valshift);
+ value &= ~UART_LCR_DLAB;
/* fall through */
case UART_MCR:
offset = UNIPHIER_UART_LCR_MCR;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] serial: 8250_uniphier: fix more unterminated string
From: Masahiro Yamada @ 2016-10-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477296030-7517-1-git-send-email-yamada.masahiro@socionext.com>
From: Denys Vlasenko <dvlasenk@redhat.com>
Commit 1681d2116c96 ("serial: 8250_uniphier: add "\n" at the end of
error log") missed this.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
[masahiro: add commit log]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/tty/serial/8250/8250_uniphier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index b8d9c8c..a8babb0 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -199,7 +199,7 @@ static int uniphier_uart_probe(struct platform_device *pdev)
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!regs) {
- dev_err(dev, "failed to get memory resource");
+ dev_err(dev, "failed to get memory resource\n");
return -EINVAL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 0/4] serial: 8250_uniphier: some fixes and optimization
From: Masahiro Yamada @ 2016-10-24 8:00 UTC (permalink / raw)
To: linux-arm-kernel
This series is mostly based on excellent observant comments
from Denys Vlasenko.
- Add '\n' to a printk message
- Fix a minor bug
- Memory access optimization
- Locking optimization
Denys Vlasenko (1):
serial: 8250_uniphier: fix more unterminated string
Masahiro Yamada (3):
serial: 8250_uniphier: fix clearing divisor latch access bit
serial: 8250_uniphier: hardcode regshift to avoid unneeded memory read
serial: 8250_uniphier: avoid locking for FCR register write
drivers/tty/serial/8250/8250_uniphier.c | 50 ++++++++++++++++++---------------
1 file changed, 28 insertions(+), 22 deletions(-)
--
1.9.1
^ permalink raw reply
* [BUG] LPC32xx gpio driver broken by commit 762c2e46 in 4.9-rc1
From: Masahiro Yamada @ 2016-10-24 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZiG8B4K2Hf0mEcuOcq45=Q4n1yD4TDVJgJ+T7K1PMKAg@mail.gmail.com>
Hi.
2016-10-24 9:46 GMT+09:00 Linus Walleij <linus.walleij@linaro.org>:
> On Tue, Oct 18, 2016 at 6:23 PM, Sylvain Lemieux
> <slemieux.tyco@gmail.com> wrote:
>
>> the current LPC32xx GPIO driver is broken by commit 762c2e46
>> (gpio: of: remove of_gpiochip_and_xlate() and struct gg_data).
>>
>> A call to "of_get_named_gpio" to retrieve the GPIO will
>> always return -EINVAL, except for the first GPIO bank.
>>
>> Prior to this commit, the driver was working properly
>> because of the side-effect of the match function called by
>> "gpiochip_find" inside "of_get_named_gpiod_flags" function.
> (...)
>> Is there any short-term solution that can be done with
>> the existing driver to keep the LPC32xx platform working
>> properly in the 4.9 mainline kernel?
>
> Masahiro, what do you think is the best course to proceed here?
> Can we
> - Restore the behaviour prior to the patches or
> - Fix up all users or
> - Do we have to revert these two patches?
>
> I would prefer not to revert, because I liked the cleanup a lot ...
>
Personally, I do not want to revert, either.
I guess, this discussion comes down to
"is it justified to register multiple chips
associated to a single DT node?"
I feel like, DT properties such as
"gpio-hog", "gpio-ranges" assume one gpio_chip for one node.
We can register multi gpio_chip if we like, but
it looks odd to parse the same DT properties over and over again
looping gpio_chips.
If we move forward to single gpio_chip solution,
please check my RFC
"gpio: of: fix GPIO drivers with multiple gpio_chip for a single node"
as a long-term (but not too long) solution.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v3 0/2] clk: imx: fix AV PLL rate setting
From: Shawn Guo @ 2016-10-24 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476267249.git.emil@limesaudio.com>
On Wed, Oct 12, 2016 at 12:31:39PM +0200, Emil Lundmark wrote:
> Emil Lundmark (2):
> clk: imx: fix integer overflow in AV PLL round rate
> clk: imx: improve precision of AV PLL to 1 Hz
For both,
Acked-by: Shawn Guo <shawnguo@kernel.org>
^ permalink raw reply
* [PATCH 0/4] STM32F429: Add Ethernet fixes
From: Alexandre Torgue @ 2016-10-24 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020.144140.1794871934594140769.davem@davemloft.net>
Hi David,
On 10/20/2016 08:41 PM, David Miller wrote:
> From: Alexandre TORGUE <alexandre.torgue@st.com>
> Date: Thu, 20 Oct 2016 17:21:22 +0200
>
>> This series adds several fixes for Ethernet for stm32f429 MCU.
>> First 2 patches have already been reviewed some months ago when
>> stm32 Ethernet glue has been pushed (I added in this series to keep
>> history). Fixes are:
>> -Change DT to be compliant to stm32 ethernet glue binding
>> -Add phy-handle to correctly use mdio subnode
>> -Remove WoL support
>
> I'm assuming this will be merged via the ARM tree.
Yes, I will take it in my next pull request (if no issues).
^ permalink raw reply
* [PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts
From: Andy Shevchenko @ 2016-10-24 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <36163853-ac4a-e146-0c1b-eaf42e8b234d@codeaurora.org>
On Mon, Oct 24, 2016 at 5:55 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 10/21/2016 12:11 PM, Andy Shevchenko wrote:
>>> +static void hidma_free_msis(struct hidma_dev *dmadev)
>>> > +{
>>> > +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
>> Perhaps one #ifdef and two definitions of functions?
>
> I don't think it will make a difference. I'll have to move
> #ifdef around the caller of hidma_free_msis instead which
> I think is uglier.
>
> The hidma_write_msi_msg function gets called only when
> CONFIG_GENERIC_MSI_IRQ_DOMAIN is defined. If I don't put
> this around the function definition, I get unused function
> warning from the compiler. This is the reason why preprocessor
> definition is outside of the function definition.
I am talking about something like below:
#ifdef UGLY_DEFINE
myfunc_a()
{
}
myfunc_b()
{
}
#else
static inline myfunc_a() {}
static inline myfunc_b() {}
#endif
There is another way as well, namely use of IS_ENABLED(), IS_BUILTIN()
macros (I don't remember how exactly second one is spelt).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v1 1/2] ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid
From: Shawn Guo @ 2016-10-24 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <63fc108e2df00d2297a9b7014955f203bc802f34.1475498805.git.maitysanchayan@gmail.com>
On Mon, Oct 03, 2016 at 06:20:37PM +0530, Sanchayan Maity wrote:
> Enable DMA for DSPI on Vybrid.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
This is a hardware description which looks correct, regardless of the
DSPI driver readiness. So I applied it.
Shawn
^ permalink raw reply
* [PATCH v3 1/2] ARM: imx: gpc: Initialize all power domains
From: Shawn Guo @ 2016-10-24 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477138856-31696-1-git-send-email-festevam@gmail.com>
On Sat, Oct 22, 2016 at 10:20:55AM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Since commit 0159ec670763dd ("PM / Domains: Verify the PM domain is present
> when adding a provider") the following regression is observed on imx6:
>
> imx-gpc: probe of 20dc000.gpc failed with error -22
>
> The gpc probe fails because of_genpd_add_provider_onecell() now checks
> if all the domains are initialized via pm_genpd_present() function
> and it fails because not all the power domains are initialized.
>
> In order to fix this error, initialize all the power domains from
> imx_gpc_domains[], not only the imx6q_pu_domain.base one.
>
> Reported-by: Olof's autobooter <build@lixom.net>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied both, thanks.
^ permalink raw reply
* [PATCH 0/5] ARM: dts: renesas: Remove skeleton.dtsi inclusion
From: Simon Horman @ 2016-10-24 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021095319.GC15372@leverpostej>
On Fri, Oct 21, 2016 at 10:53:19AM +0100, Mark Rutland wrote:
> On Fri, Oct 21, 2016 at 11:16:05AM +0200, Geert Uytterhoeven wrote:
> > Hi Simon, Magnus,
> >
> > As of commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark skeleton.dtsi
> > as deprecated"), including skeleton.dtsi is deprecated.
> > Hence this series removes its use for all Renesas 32-bit ARM SoCs.
>
> Thanks for doing this! FWIW, for the series:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks, I have queued these up.
^ permalink raw reply
* [PATCH 1/4] ARM: dts: mxs: Add new M28EVK manufacturer compat
From: Shawn Guo @ 2016-10-24 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3ec3e368-c8f1-3bee-7b7b-6de5cef72325@denx.de>
On Sun, Oct 23, 2016 at 03:30:32PM +0200, Marek Vasut wrote:
> On 10/23/2016 03:01 PM, Shawn Guo wrote:
> > On Mon, Sep 19, 2016 at 11:40:41PM +0200, Marek Vasut wrote:
> >> The board is now manufactured by Aries Embedded GmbH, update compat string.
> >>
> >> Signed-off-by: Marek Vasut <marex@denx.de>
> >> Cc: Shawn Guo <shawnguo@kernel.org>
> >> ---
> >> arch/arm/boot/dts/imx28-m28.dtsi | 4 ++--
> >> arch/arm/boot/dts/imx28-m28evk.dts | 4 ++--
> >> 2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/imx28-m28.dtsi b/arch/arm/boot/dts/imx28-m28.dtsi
> >> index 214bb15..a69856e 100644
> >> --- a/arch/arm/boot/dts/imx28-m28.dtsi
> >> +++ b/arch/arm/boot/dts/imx28-m28.dtsi
> >> @@ -12,8 +12,8 @@
> >> #include "imx28.dtsi"
> >>
> >> / {
> >> - model = "DENX M28";
> >> - compatible = "denx,m28", "fsl,imx28";
> >> + model = "Aries/DENX M28";
> >> + compatible = "aries,m28", "denx,m28", "fsl,imx28";
> >
> > Do we have an entry for Aries Embedded GmbH in vendor-prefixes.txt?
>
> The patch was submitted, not yet applied though:
> http://www.spinics.net/lists/arm-kernel/msg533000.html
Okay. Ping me when it gets applied.
Shawn
^ permalink raw reply
* [linux-sunxi] [PATCH 1/3] phy: sun4i: check PHY id when poking unknown bit of pmu
From: Ondřej Jirman @ 2016-10-24 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024035930.20274-1-icenowy@aosc.xyz>
Dne 24.10.2016 v 05:59 Icenowy Zheng napsal(a):
> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
> The code that poke some unknown bit of PMU for H3/A64 didn't check
> the PHY, and will cause kernel oops when PHY 0 is used.
>
> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> drivers/phy/phy-sun4i-usb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index b9342a2..ff8e9dd 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -264,7 +264,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
> return ret;
> }
>
> - if (data->cfg->enable_pmu_unk1) {
> + if (phy->index != 0 && data->cfg->enable_pmu_unk1) {
It might be better to check for phy->pmu directly.
regards,
o.
> val = readl(phy->pmu + REG_PMU_UNK1);
> writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> }
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 821 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/d6dd79ef/attachment.sig>
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Marek Szyprowski @ 2016-10-24 6:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000601d22451$5eb46fc0$1c1d4f40$@codeaurora.org>
Hi Sricharan,
On 2016-10-12 08:24, Sricharan wrote:
> On 2016-10-04 19:03, Sricharan R wrote:
>>> Initial post from Laurent Pinchart[1]. This is
>>> series calls the dma ops configuration for the devices
>>> at a generic place so that it works for all busses.
>>> The dma_configure_ops for a device is now called during
>>> the device_attach callback just before the probe of the
>>> bus/driver is called. Similarly dma_deconfigure is called during
>>> device/driver_detach path.
>>>
>>>
>>> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
>>> | |
>>> pci_bus_add_device (device_add/driver_register)
>>> | |
>>> device_attach device_initial_probe
>>> | |
>>> __device_attach_driver __device_attach_driver
>>> |
>>> driver_probe_device
>>> |
>>> really_probe
>>> |
>>> dma_configure
>>>
>>> Similarly on the device/driver_unregister path __device_release_driver is
>>> called which inturn calls dma_deconfigure.
>>>
>>> If the ACPI bus code follows the same, we can add acpi_dma_configure
>>> at the same place as of_dma_configure.
>>>
>>> This series is based on the recently merged Generic DT bindings for
>>> PCI IOMMUs and ARM SMMU from Robin Murphy robin.murphy at arm.com [2]
>>>
>>> This time tested this with platform and pci device for probe deferral
>>> and reprobe on arm64 based platform. There is an issue on the cleanup
>>> path for arm64 though, where there is WARN_ON if the dma_ops is reset while
>>> device is attached to an domain in arch_teardown_dma_ops.
>>> But with iommu_groups created from the iommu driver, the device is always
>>> attached to a domain/default_domain. So so the WARN has to be removed/handled
>>> probably.
>> Thanks for continuing work on this feature! Your can add my:
>>
>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
> Thanks for testing this. So the for the below fix, the remove_device callback
> gets called on the dma_ops cleanup path, so would it be easy to remove the
> data for the device there ?
I assumed that IOMMU driver cannot be removed reliably, so all
structures that it
creates are permanent. I didn't use device_add()/device_remove()
callbacks, because
in current implementation device_add() is called too late (after
dma-mapping glue
triggers device_attach_iommu()).
Maybe once your patchset is merged, I will move creation and management
of the all
IOMMU related structures to device_add/remove callbacks.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Mugunthan V N @ 2016-10-24 6:02 UTC (permalink / raw)
To: linux-arm-kernel
Increase ADC reference clock from 3MHz to 24MHz so that the
sampling rates goes up from 100K samples per second to 800K
samples per second on AM335x and AM437x SoC.
Also increase opendelay for touchscreen configuration to
equalize the increase in ADC reference clock frequency,
which results in the same amount touch events reported via
evtest on AM335x GP EVM.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
This patch depends on ADC DMA patch series [1]
Without DMA support, when ADC ref clock is set at 24MHz, I am
seeing fifo overflow as CPU is not able to pull the ADC samples.
This answers that DMA support is must for ADC to consume the
samples generated at 24MHz with no open, step delay or
averaging with patch [2].
Measured the performance with the iio_generic_buffer with the
patch [3] applied
[1] - http://www.spinics.net/lists/devicetree/msg145045.html
[2] - http://pastebin.ubuntu.com/23357935/
[3] - http://pastebin.ubuntu.com/23357939/
---
include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
index b9a53e0..96c4207 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -90,7 +90,7 @@
/* Delay register */
#define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
#define STEPDELAY_OPEN(val) ((val) << 0)
-#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
+#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x500)
#define STEPDELAY_SAMPLE_MASK (0xFF << 24)
#define STEPDELAY_SAMPLE(val) ((val) << 24)
#define STEPCONFIG_SAMPLEDLY STEPDELAY_SAMPLE(0)
@@ -137,7 +137,7 @@
#define SEQ_STATUS BIT(5)
#define CHARGE_STEP 0x11
-#define ADC_CLK 3000000
+#define ADC_CLK 24000000
#define TOTAL_STEPS 16
#define TOTAL_CHANNELS 8
#define FIFO1_THRESHOLD 19
--
2.10.1.502.g6598894
^ permalink raw reply related
* [PATCH 1/3] arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
From: Ding Tianhong @ 2016-10-24 5:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023120423.GO30578@tiger>
On 2016/10/23 20:04, Shawn Guo wrote:
> On Sun, Oct 23, 2016 at 11:21:10AM +0800, Ding Tianhong wrote:
>> This erratum describes a bug in logic outside the core, so MIDR can't be
>> used to identify its presence, and reading an SoC-specific revision
>> register from common arch timer code would be awkward. So, describe it
>> in the device tree.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>> Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
>> index ef5fbe9..26bc837 100644
>> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
>> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
>> @@ -31,6 +31,12 @@ to deliver its interrupts via SPIs.
>> This also affects writes to the tval register, due to the implicit
>> counter read.
>>
>> +- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of
>> + QorIQ erratum 161201, which says that reading the counter is
>
> QorIQ is a Freescale/NXP specific name, and shouldn't be there.
>
> Shawn
>
Got it, will wait other feedback and fix them together, thanks.
Ding
>> + unreliable unless the small range of value is returned by back-to-back reads.
>> + This also affects writes to the tval register, due to the implicit
>> + counter read.
>> +
>> ** Optional properties:
>>
>> - arm,cpu-registers-not-fw-configured : Firmware does not initialize
>> --
>> 1.9.0
>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> .
>
^ permalink raw reply
* [PATCH V5 3/3] ACPI: pci_link: Include PIRQ_PENALTY_PCI_USING for ISA IRQs
From: Jonathan Liu @ 2016-10-24 4:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477283492-26657-4-git-send-email-okaya@codeaurora.org>
On 24 October 2016 at 15:31, Sinan Kaya <okaya@codeaurora.org> wrote:
> Commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> replaced the addition of PIRQ_PENALTY_PCI_USING in acpi_pci_link_allocate()
> with an addition in acpi_irq_pci_sharing_penalty(), but f7eca374f000
> ("ACPI,PCI,IRQ: separate ISA penalty calculation") removed the use
> of acpi_irq_pci_sharing_penalty() for ISA IRQs.
>
> Therefore, PIRQ_PENALTY_PCI_USING is missing from ISA IRQs used by
> interrupt links. Include that penalty by adding it in the
> acpi_pci_link_allocate() path.
>
> Fixes: f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty calculation")
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/acpi/pci_link.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 74bf96e..bc3d914 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -608,6 +608,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link)
> acpi_device_bid(link->device));
> return -ENODEV;
> } else {
> + if (link->irq.active < ACPI_MAX_ISA_IRQS)
> + acpi_isa_irq_penalty[link->irq.active] +=
> + PIRQ_PENALTY_PCI_USING;
> +
> printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
> acpi_device_name(link->device),
> acpi_device_bid(link->device), link->irq.active);
> --
> 1.9.1
>
This series fixes one or more network adapters not working in Linux
32-bit x86 guest running inside VirtualBox if I have 4 network
adapters enabled.
The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [PATCH V5 2/3] ACPI: pci_link: penalize SCI correctly
From: Jonathan Liu @ 2016-10-24 4:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477283492-26657-3-git-send-email-okaya@codeaurora.org>
On 24 October 2016 at 15:31, Sinan Kaya <okaya@codeaurora.org> wrote:
> Ondrej reported that IRQs stopped working in v4.7 on several
> platforms. A typical scenario, from Ondrej's VT82C694X/694X, is:
>
> ACPI: Using PIC for interrupt routing
> ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
> ACPI: No IRQ available for PCI Interrupt Link [LNKA]
> 8139too 0000:00:0f.0: PCI INT A: no GSI
>
> We're using PIC routing, so acpi_irq_balance == 0, and LNKA is already
> active at IRQ 11. In that case, acpi_pci_link_allocate() only tries
> to use the active IRQ (IRQ 11) which also happens to be the SCI.
>
> We should penalize the SCI by PIRQ_PENALTY_PCI_USING, but
> irq_get_trigger_type(11) returns something other than
> IRQ_TYPE_LEVEL_LOW, so we penalize it by PIRQ_PENALTY_ISA_ALWAYS
> instead, which makes acpi_pci_link_allocate() assume the IRQ isn't
> available and give up.
>
> Add acpi_penalize_sci_irq() so platforms can tell us the SCI IRQ,
> trigger, and polarity directly and we don't have to depend on
> irq_get_trigger_type().
>
> Link: http://lkml.kernel.org/r/201609251512.05657.linux at rainbow-software.org
> Reported-by: Ondrej Zary <linux@rainbow-software.org>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 30 +++++++++++++++---------------
> include/linux/acpi.h | 1 +
> 3 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..0ffd26e 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
> polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
>
> mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> + acpi_penalize_sci_irq(bus_irq, trigger, polarity);
>
> /*
> * stash over-ride to indicate we've been here
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 6229b02..74bf96e 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -87,6 +87,7 @@ struct acpi_pci_link {
>
> static LIST_HEAD(acpi_link_list);
> static DEFINE_MUTEX(acpi_link_lock);
> +static int sci_irq = -1, sci_penalty;
>
> /* --------------------------------------------------------------------------
> PCI Link Device Management
> @@ -496,25 +497,13 @@ static int acpi_irq_get_penalty(int irq)
> {
> int penalty = 0;
>
> - /*
> - * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> - * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> - * use for PCI IRQs.
> - */
> - if (irq == acpi_gbl_FADT.sci_interrupt) {
> - u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> -
> - if (type != IRQ_TYPE_LEVEL_LOW)
> - penalty += PIRQ_PENALTY_ISA_ALWAYS;
> - else
> - penalty += PIRQ_PENALTY_PCI_USING;
> - }
> + if (irq == sci_irq)
> + penalty += sci_penalty;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> return penalty + acpi_isa_irq_penalty[irq];
>
> - penalty += acpi_irq_pci_sharing_penalty(irq);
> - return penalty;
> + return penalty + acpi_irq_pci_sharing_penalty(irq);
> }
>
> int __init acpi_irq_penalty_init(void)
> @@ -881,6 +870,17 @@ bool acpi_isa_irq_available(int irq)
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
> }
>
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
> +{
> + sci_irq = irq;
> +
> + if (trigger == ACPI_MADT_TRIGGER_LEVEL &&
> + polarity == ACPI_MADT_POLARITY_ACTIVE_LOW)
> + sci_penalty = PIRQ_PENALTY_PCI_USING;
> + else
> + sci_penalty = PIRQ_PENALTY_ISA_ALWAYS;
> +}
> +
> /*
> * Over-ride default table to reserve additional IRQs for use by ISA
> * e.g. acpi_irq_isa=5
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index c5eaf2f..67d1d3e 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -318,6 +318,7 @@ struct pci_dev;
> int acpi_pci_irq_enable (struct pci_dev *dev);
> void acpi_penalize_isa_irq(int irq, int active);
> bool acpi_isa_irq_available(int irq);
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
> void acpi_pci_irq_disable (struct pci_dev *dev);
>
> extern int ec_read(u8 addr, u8 *val);
> --
> 1.9.1
>
This series fixes one or more network adapters not working in Linux
32-bit x86 guest running inside VirtualBox if I have 4 network
adapters enabled.
The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [PATCH V5 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
From: Jonathan Liu @ 2016-10-24 4:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477283492-26657-2-git-send-email-okaya@codeaurora.org>
On 24 October 2016 at 15:31, Sinan Kaya <okaya@codeaurora.org> wrote:
> We do not want to store the SCI penalty in the acpi_isa_irq_penalty[]
> table because acpi_isa_irq_penalty[] only holds ISA IRQ penalties and
> there's no guarantee that the SCI is an ISA IRQ. We add in the SCI
> penalty as a special case in acpi_irq_get_penalty().
>
> But if we called acpi_penalize_isa_irq() or acpi_irq_penalty_update()
> for an SCI that happened to be an ISA IRQ, they stored the SCI
> penalty (part of the acpi_irq_get_penalty() return value) in
> acpi_isa_irq_penalty[]. Subsequent calls to acpi_irq_get_penalty()
> returned a penalty that included *two* SCI penalties.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/acpi/pci_link.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..6229b02 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -849,7 +849,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> continue;
>
> if (used)
> - new_penalty = acpi_irq_get_penalty(irq) +
> + new_penalty = acpi_isa_irq_penalty[irq] +
> PIRQ_PENALTY_ISA_USED;
> else
> new_penalty = 0;
> @@ -871,7 +871,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> void acpi_penalize_isa_irq(int irq, int active)
> {
> if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
> - acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> + acpi_isa_irq_penalty[irq] +=
> (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> }
>
> --
> 1.9.1
>
This series fixes one or more network adapters not working in Linux
32-bit x86 guest running inside VirtualBox if I have 4 network
adapters enabled.
The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [PATCH V5 3/3] ACPI: pci_link: Include PIRQ_PENALTY_PCI_USING for ISA IRQs
From: Sinan Kaya @ 2016-10-24 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477283492-26657-1-git-send-email-okaya@codeaurora.org>
Commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
replaced the addition of PIRQ_PENALTY_PCI_USING in acpi_pci_link_allocate()
with an addition in acpi_irq_pci_sharing_penalty(), but f7eca374f000
("ACPI,PCI,IRQ: separate ISA penalty calculation") removed the use
of acpi_irq_pci_sharing_penalty() for ISA IRQs.
Therefore, PIRQ_PENALTY_PCI_USING is missing from ISA IRQs used by
interrupt links. Include that penalty by adding it in the
acpi_pci_link_allocate() path.
Fixes: f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty calculation")
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/acpi/pci_link.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index 74bf96e..bc3d914 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -608,6 +608,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link)
acpi_device_bid(link->device));
return -ENODEV;
} else {
+ if (link->irq.active < ACPI_MAX_ISA_IRQS)
+ acpi_isa_irq_penalty[link->irq.active] +=
+ PIRQ_PENALTY_PCI_USING;
+
printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
acpi_device_name(link->device),
acpi_device_bid(link->device), link->irq.active);
--
1.9.1
^ permalink raw reply related
* [PATCH V5 2/3] ACPI: pci_link: penalize SCI correctly
From: Sinan Kaya @ 2016-10-24 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477283492-26657-1-git-send-email-okaya@codeaurora.org>
Ondrej reported that IRQs stopped working in v4.7 on several
platforms. A typical scenario, from Ondrej's VT82C694X/694X, is:
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: No IRQ available for PCI Interrupt Link [LNKA]
8139too 0000:00:0f.0: PCI INT A: no GSI
We're using PIC routing, so acpi_irq_balance == 0, and LNKA is already
active at IRQ 11. In that case, acpi_pci_link_allocate() only tries
to use the active IRQ (IRQ 11) which also happens to be the SCI.
We should penalize the SCI by PIRQ_PENALTY_PCI_USING, but
irq_get_trigger_type(11) returns something other than
IRQ_TYPE_LEVEL_LOW, so we penalize it by PIRQ_PENALTY_ISA_ALWAYS
instead, which makes acpi_pci_link_allocate() assume the IRQ isn't
available and give up.
Add acpi_penalize_sci_irq() so platforms can tell us the SCI IRQ,
trigger, and polarity directly and we don't have to depend on
irq_get_trigger_type().
Link: http://lkml.kernel.org/r/201609251512.05657.linux at rainbow-software.org
Reported-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
arch/x86/kernel/acpi/boot.c | 1 +
drivers/acpi/pci_link.c | 30 +++++++++++++++---------------
include/linux/acpi.h | 1 +
3 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 90d84c3..0ffd26e 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ acpi_penalize_sci_irq(bus_irq, trigger, polarity);
/*
* stash over-ride to indicate we've been here
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index 6229b02..74bf96e 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -87,6 +87,7 @@ struct acpi_pci_link {
static LIST_HEAD(acpi_link_list);
static DEFINE_MUTEX(acpi_link_lock);
+static int sci_irq = -1, sci_penalty;
/* --------------------------------------------------------------------------
PCI Link Device Management
@@ -496,25 +497,13 @@ static int acpi_irq_get_penalty(int irq)
{
int penalty = 0;
- /*
- * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
- * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
- * use for PCI IRQs.
- */
- if (irq == acpi_gbl_FADT.sci_interrupt) {
- u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
-
- if (type != IRQ_TYPE_LEVEL_LOW)
- penalty += PIRQ_PENALTY_ISA_ALWAYS;
- else
- penalty += PIRQ_PENALTY_PCI_USING;
- }
+ if (irq == sci_irq)
+ penalty += sci_penalty;
if (irq < ACPI_MAX_ISA_IRQS)
return penalty + acpi_isa_irq_penalty[irq];
- penalty += acpi_irq_pci_sharing_penalty(irq);
- return penalty;
+ return penalty + acpi_irq_pci_sharing_penalty(irq);
}
int __init acpi_irq_penalty_init(void)
@@ -881,6 +870,17 @@ bool acpi_isa_irq_available(int irq)
acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
}
+void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
+{
+ sci_irq = irq;
+
+ if (trigger == ACPI_MADT_TRIGGER_LEVEL &&
+ polarity == ACPI_MADT_POLARITY_ACTIVE_LOW)
+ sci_penalty = PIRQ_PENALTY_PCI_USING;
+ else
+ sci_penalty = PIRQ_PENALTY_ISA_ALWAYS;
+}
+
/*
* Over-ride default table to reserve additional IRQs for use by ISA
* e.g. acpi_irq_isa=5
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index c5eaf2f..67d1d3e 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -318,6 +318,7 @@ struct pci_dev;
int acpi_pci_irq_enable (struct pci_dev *dev);
void acpi_penalize_isa_irq(int irq, int active);
bool acpi_isa_irq_available(int irq);
+void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
void acpi_pci_irq_disable (struct pci_dev *dev);
extern int ec_read(u8 addr, u8 *val);
--
1.9.1
^ permalink raw reply related
* [PATCH V5 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
From: Sinan Kaya @ 2016-10-24 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477283492-26657-1-git-send-email-okaya@codeaurora.org>
We do not want to store the SCI penalty in the acpi_isa_irq_penalty[]
table because acpi_isa_irq_penalty[] only holds ISA IRQ penalties and
there's no guarantee that the SCI is an ISA IRQ. We add in the SCI
penalty as a special case in acpi_irq_get_penalty().
But if we called acpi_penalize_isa_irq() or acpi_irq_penalty_update()
for an SCI that happened to be an ISA IRQ, they stored the SCI
penalty (part of the acpi_irq_get_penalty() return value) in
acpi_isa_irq_penalty[]. Subsequent calls to acpi_irq_get_penalty()
returned a penalty that included *two* SCI penalties.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/acpi/pci_link.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index c983bf7..6229b02 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -849,7 +849,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
continue;
if (used)
- new_penalty = acpi_irq_get_penalty(irq) +
+ new_penalty = acpi_isa_irq_penalty[irq] +
PIRQ_PENALTY_ISA_USED;
else
new_penalty = 0;
@@ -871,7 +871,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
void acpi_penalize_isa_irq(int irq, int active)
{
if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
- acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
+ acpi_isa_irq_penalty[irq] +=
(active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
}
--
1.9.1
^ permalink raw reply related
* [PATCH V5 0/3] ACPI, PCI, IRQ: revert penalty calculation for ISA and SCI interrupts
From: Sinan Kaya @ 2016-10-24 4:31 UTC (permalink / raw)
To: linux-arm-kernel
By the time ACPI gets initialized, this code tries to determine an
IRQ number based on penalty values in this array. It will try to locate
the IRQ with the least penalty assignment so that interrupt sharing is
avoided if possible.
A couple of notes about the external APIs:
1. These API can be called before the ACPI is started. Therefore, one
cannot assume that the PCI link objects are initialized for calculating
penalties.
2. The polarity and trigger information passed via the
acpi_penalize_sci_irq from the BIOS may not match what the IRQ subsystem
is reporting as the call might have been placed before the IRQ is
registered by the interrupt subsystem.
The reverted changes were in the direction to remove these external API and
try to calculate the penalties at runtime for the ISA, SCI as well as PCI
IRQS.
This didn't work out well with the existing platforms.
V5:
* clean up the commit message for 1/3 and 2/3
* drop 3/3
* bring back ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts as 3/3
V4:
https://www.spinics.net/lists/arm-kernel/msg537158.html
* Drop ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
* A new patch to isolate early boot ISA penalty calculations from dynamic
penalty calculation by directly modifying the array members in
("ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages")
* Now that we isolated both SCI and ISA interrupts, revert commit ("Revert
"ACPI,PCI,IRQ: separate ISA penalty calculation"") and commit
("487cf917ed0d
(Revert "ACPI, PCI, IRQ: remove redundant code in acpi_irq_penalty_init()")
to share code between ISA and PCI penalties as originally intended.
V3:
http://www.spinics.net/lists/arm-kernel/msg536208.html
* drop patch #1 as discussed with Bjorn
* add patch #3 to track SCI irq and penalty separately
V2: https://lkml.org/lkml/2016/10/1/106
* Commit message updates
V1:
http://lists-archives.com/linux-kernel/28673954-revert-acpi-pci-irq-reduce-static-irq-array-size-to-16.html
* initial implementation
Sinan Kaya (3):
ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
ACPI: pci_link: penalize SCI correctly
ACPI: pci_link: Include PIRQ_PENALTY_PCI_USING for ISA IRQs
arch/x86/kernel/acpi/boot.c | 1 +
drivers/acpi/pci_link.c | 38 +++++++++++++++++++++-----------------
include/linux/acpi.h | 1 +
3 files changed, 23 insertions(+), 17 deletions(-)
--
1.9.1
^ permalink raw reply
* [V4, 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
From: Jonathan Liu @ 2016-10-24 4:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fae460e4-d838-22c0-8984-52d6d2b6c099@codeaurora.org>
On 24 October 2016 at 15:17, Sinan Kaya <okaya@codeaurora.org> wrote:
> Thanks,
>
> On 10/22/2016 11:48 PM, Jonathan Liu wrote:
>> This series fixes one or more network adapters not working in Linux
>> 32-bit x86 guest running inside VirtualBox if I have 4 network
>> adapters enabled. The following message no longer appears in the
>> kernel log:
>> ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
>>
>> Tested-by: Jonathan Liu <net147@gmail.com>
>
> I'm hoping that you can retest V5 so that Rafael can pull in your tested-by into
> the commit message.
>
> --
> Sinan Kaya
> 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.
Sure. Please CC me when you submit V5.
Regards,
Jonathan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox