* [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 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] 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 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
* [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 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
* [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 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 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 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 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 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
* [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 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
* [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 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 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 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 v1] char: hw_random: atmel-rng: disable TRNG during suspend
From: Wenyou Yang @ 2016-10-24 8:03 UTC (permalink / raw)
To: linux-arm-kernel
To fix the over consumption on the VDDCore due to the TRNG enabled,
disable the TRNG during suspend, not only disable the user interface
clock (which is controlled by PMC). Because the user interface clock
is independent from any clock that may be used in the entropy source
logic circuitry.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
drivers/char/hw_random/atmel-rng.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
index 0fcc9e6..2e2d09a 100644
--- a/drivers/char/hw_random/atmel-rng.c
+++ b/drivers/char/hw_random/atmel-rng.c
@@ -48,6 +48,16 @@ static int atmel_trng_read(struct hwrng *rng, void *buf, size_t max,
return 0;
}
+static void atmel_trng_enable(struct atmel_trng *trng)
+{
+ writel(TRNG_KEY | 1, trng->base + TRNG_CR);
+}
+
+static void atmel_trng_disable(struct atmel_trng *trng)
+{
+ writel(TRNG_KEY, trng->base + TRNG_CR);
+}
+
static int atmel_trng_probe(struct platform_device *pdev)
{
struct atmel_trng *trng;
@@ -71,7 +81,7 @@ static int atmel_trng_probe(struct platform_device *pdev)
if (ret)
return ret;
- writel(TRNG_KEY | 1, trng->base + TRNG_CR);
+ atmel_trng_enable(trng);
trng->rng.name = pdev->name;
trng->rng.read = atmel_trng_read;
@@ -94,7 +104,7 @@ static int atmel_trng_remove(struct platform_device *pdev)
hwrng_unregister(&trng->rng);
- writel(TRNG_KEY, trng->base + TRNG_CR);
+ atmel_trng_disable(trng);
clk_disable_unprepare(trng->clk);
return 0;
@@ -105,6 +115,7 @@ static int atmel_trng_suspend(struct device *dev)
{
struct atmel_trng *trng = dev_get_drvdata(dev);
+ atmel_trng_disable(trng);
clk_disable_unprepare(trng->clk);
return 0;
@@ -114,6 +125,7 @@ static int atmel_trng_resume(struct device *dev)
{
struct atmel_trng *trng = dev_get_drvdata(dev);
+ atmel_trng_enable(trng);
return clk_prepare_enable(trng->clk);
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2] drivers: psci: PSCI checker module
From: Geert Uytterhoeven @ 2016-10-24 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e2dedf4-192f-8657-10b1-24b426af5f00@arm.com>
On Thu, Oct 20, 2016 at 4:21 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 20/10/16 14:38, Kevin Brodsky wrote:
>
> [...]
>
>>
>> Thanks for the heads-up! I'll rebase on 4.9-rc1 and see what needs to be
>> done.
>>
>
> Just be aware that v4.9-rc1 doesn't have commit 9cfb38a7ba5a
> ("sched/fair: Fix sched domains NULL dereference in
> select_idle_sibling()") which fixes the cpuhotplug issue you would
> observe.
Good to know. I saw that issue during resume from s2ram on r8a7795/Salvator-X
once, but couldn't reproduce it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Map the BSS at HYP
From: Christoffer Dall @ 2016-10-24 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476968441-29003-1-git-send-email-marc.zyngier@arm.com>
On Thu, Oct 20, 2016 at 02:00:41PM +0100, Marc Zyngier wrote:
> When used with a compiler that doesn't implement "asm goto"
> (such as the AArch64 port of GCC 4.8), jump labels generate a
> memory access to find out about the value of the key (instead
> of just patching the code). The key itself is likely to be
> stored in the BSS.
>
> This is perfectly fine, except that we don't map the BSS at HYP,
> leading to an exploding kernel at the first access. The obvious
> fix is simply to map the BSS there (which should have been done
> a long while ago, but hey...).
>
> Reported-by: Eric Auger <eric.auger@redhat.com>
> Tested-by: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
^ permalink raw reply
* Disabling an interrupt in the handler locks the system up
From: Marc Zyngier @ 2016-10-24 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580BF1D4.2030509@free.fr>
On 23/10/16 00:10, Mason wrote:
> On 22/10/2016 13:37, Marc Zyngier wrote:
>
>> Mason wrote:
>>
>>> In my mental picture of interrupts (which is obviously so
>>> incomplete as to be wrong) interrupts are a way for hardware
>>> to tell the CPU that they urgently need the CPU's attention.
>>
>> That's how the CPU interprets it, but this is even more basic than
>> that, see below.
>>
>>> Obviously, the hardware being idle (line high) is not an urgent
>>> matter which interests the CPU. Likewise, I'm not sure the CPU
>>> cares that the hardware is busy (line low). It seems to me the
>>> interesting event from the CPU's perspective is when the
>>> hardware completes a "task" (transition from low to high).
>>
>> There is no such thing as "busy" when it comes to interrupts. An
>> interrupt signals the CPU that some device-specific condition has been
>> satisfied. It could be "I've received a packet" or "Battery is about to
>> explode", depending if the device is a network controller or a
>> temperature sensor. The interrupt doesn't describe the process that
>> leads to that condition (packet being received or temperature rising),
>> but the condition itself.
>>
>> In your cases, as the device seems to do some form of processing
>> (you're talking about task completion), then the interrupt seems to
>> describe exactly this ("I'm done").
>
> The device is a graphics engine, which can be programmed to perform
> some operation on one or several frame buffers stored in memory.
> It outputs its state (idle vs busy) on interrupt line 23.
>
>>> So I had originally configured the interrupt as IRQ_TYPE_EDGE_RISING.
>>> (There is an edge detection block in the irqchip, but the HW designer
>>> warned me that at low frequencies, it is possible to "miss" some edges,
>>> and we should prefer level triggers if possible.)
>>
>> Level and edge are not interchangeable. They do describe very different
>> thing:
>>
>> - Level indicates a persistent state, which implies that the device
>> needs to be serviced so that this condition can be cleared (the UART
>> has received a character, and won't be able to received another until
>> it has been read by the CPU). Once the device has been serviced and
>> that condition cleared, it will lower its interrupt line.
>
> With this graphics engine, there is nothing the CPU can do to
> change what the engine outputs on the interrupt line:
>
> When the graphics engine is idle, the line remains high, forever.
> When the graphics engine is busy, the line remains low, until
> all operations have been performed (engine idle).
>
> All the CPU can do is mask the interrupt line at the interrupt
> controller, as far as I understand.
Then this is unambiguously a rising edge interrupt.
>
>> - Edge is indicative of an event having occurred ("I'm done") that
>> doesn't require any action from the CPU. Because the device can
>> continue its life without being poked by the CPU, it can continue
>> delivering interrupts even if the first one hasn't been serviced.
>> Being edge triggered, the signals get coalesced into a single
>> interrupt. For example, the temperature sensor will say "Temperature
>> rising" multiple times before the battery explodes, and it is the
>> CPU's job to go and read the sensor to find out by how much it has
>> risen.
>>
>> If your device only sends a pulse, then it is edge triggered, and it
>> should be treated as such, no matter what your HW guy is saying. This
>> usually involves looking at the device to find out how many times the
>> interrupt has been generated (assuming the device is some kind of
>> processing element). Of course, this is racy (interrupts can still be
>> generated whilst you're processing them), and you should design your
>> interrupt handler to take care of the possible race.
>
> It is clear that the block does not send a pulse on the
> interrupt line.
>
> For reasons I don't understand, Linux didn't hang when I set
> the IRQ type to IRQ_TYPE_EDGE_RISING, so it seemed better
> than locking up the system.
Because that's exactly what that is.
>
> I'm also fuzzy on what purpose the edge detector is supposed
> to serve... I had the impression is what supposed to "capture"
> an edge, to turn it into a level?
If you care to read the explanation I've given above, you'll realize
that you cannot turn an edge into a level, because they don't represent
the same thing (state vs event). The interrupt controller will latch on
a rising edge (for example), and present that information to the CPU, no
matter what the line does after that.
>> So, to make it short: find out how your device works, and configure
>> your interrupt controller in a similar way. Write your device driver
>> with the interrupt policy in mind (state vs event). Keep it simple.
>
> Thomas said "We describe the level which is raising the interrupt".
> But I'm not sure I want the state "engine is busy" to raise an
> interrupt. "engine is idle" makes more sense. But you said it's
> stupid to set IRQ_TYPE_LEVEL_HIGH... /me confused
Because you insist on considering as a level something that is an edge.
Once you try to understand the nature of the signal the device is
providing, then you may stop getting confused.
You definitely don't want to generate an interrupt when the device is
idle, because that's a state on which you cannot act (apart from
constantly generating job for your graphics engine). What you want to
detect is the *transition* from busy to idle (event). Nothing else matters.
> Maybe the fact that disable_irq locks the system up is an orthogonal
> issue that needs to be fixed anyway.
Indeed.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/3] phy: sun4i: check PHY id when poking unknown bit of pmu
From: Maxime Ripard @ 2016-10-24 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024035930.20274-1-icenowy@aosc.xyz>
On Mon, Oct 24, 2016 at 11:59:30AM +0800, Icenowy Zheng wrote:
> 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>
Cc'ing stable would be nice.
Apart from that, Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/a0929938/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: hip01: Remove skeleton.dtsi inclusion
From: Kefeng Wang @ 2016-10-24 8:31 UTC (permalink / raw)
To: linux-arm-kernel
Since commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark skeleton.dtsi
as deprecated"), remove deprecated skeleton.dtsi.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/arm/boot/dts/hip01.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/hip01.dtsi b/arch/arm/boot/dts/hip01.dtsi
index 4e9562f..9d5fd5c 100644
--- a/arch/arm/boot/dts/hip01.dtsi
+++ b/arch/arm/boot/dts/hip01.dtsi
@@ -11,8 +11,6 @@
* published by the Free Software Foundation.
*/
-#include "skeleton.dtsi"
-
/ {
interrupt-parent = <&gic>;
#address-cells = <1>;
--
1.7.12.4
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: hi3620: Remove skeleton.dtsi inclusion
From: Kefeng Wang @ 2016-10-24 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477297890-34899-1-git-send-email-wangkefeng.wang@huawei.com>
Since commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark skeleton.dtsi
as deprecated"), remove deprecated skeleton.dtsi.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/arm/boot/dts/hi3620.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
index c85d07e..d18a915 100644
--- a/arch/arm/boot/dts/hi3620.dtsi
+++ b/arch/arm/boot/dts/hi3620.dtsi
@@ -11,10 +11,12 @@
* publishhed by the Free Software Foundation.
*/
-#include "skeleton.dtsi"
#include <dt-bindings/clock/hi3620-clock.h>
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
aliases {
serial0 = &uart0;
serial1 = &uart1;
--
1.7.12.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox