* [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Joel Stanley @ 2016-11-17 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4751029.AudB7s5avo@wuerfel>
On Thu, Nov 17, 2016 at 7:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 17, 2016 4:36:33 PM CET Andrew Jeffery wrote:
>> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>> ---
>>
>> I'd like to start a discussion about how to handle the LPC register space in
>> the Aspeed SoC. There are a number of issues, largely concerned with the layout
>> of the registers but also with the fact that LPC register state is used by the
>> pinmux to determine some pin functionality.
> ...
>>
>> What is the recommended approach to managing such hardware?
>
> Can you clarify which side of the LPC bus this is? We are currently having
> a discussion for how to integrate the LPC master on an ARM64 server that
> uses LPC to access an Aspeed LPC slave. For this one we want to use the
> traditional ISA DT binding.
This is from the perspective of the BMC.
On the machines we are talking to, most (all?) access is performed
through the system firmware (skiboot).
> I'm guessing that you are interesting in the other side here, for mapping
> the registers of the LPC slave on the Aspeed BMC, but that's not clear from
> your email, as I'm assuming that the same chip has both master and slave
> interfaces.
Yep, we come from the "other side".
The BMC itself can operate the bus in Master or Slave mode. We are
interested in the slave case, for when the host is requesting access
to its system firmware at boot time. This happens by mapping a region
of the BMC's AHB memory space into the LPC address space. After we
deal with pinmux, Andrew or I will be hacking on a driver to configure
that space, as the BMC needs to configure the window before the host
can boot. It's a pile of bits spread out over different parts of the
chip, and doesn't map nicely into any existing driver model we have in
the kernel.
Other functions include IPMI communication between the BMC and the
host via the LPC bus via the iBT interface. We have a driver for that
staged for 4.10. Then there's a mailbox, some "scratch" registers that
can be used by the firmware for whatever they see fit, and all kinds
of crazy legacy x86 stuff like POST code registers.
Cheers,
Joel
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-17 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgTjG8G0U+A1p7hOKND9rjY4BzZfPgyWWHAEryYkHj_UOw@mail.gmail.com>
On Wed, 2016-11-16 at 22:36 +0530, Anand Moon wrote:
> ?Hi Jerome.
>
> On 15 November 2016 at 19:59, Jerome Brunet <jbrunet@baylibre.com>
> wrote:
> >
> > On some platforms, energy efficient ethernet with rtl8211 devices
> > is
> > causing issue, like throughput drop or broken link.
> >
> > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the
> > issue root
> > cause is not fully understood yet, disabling EEE advertisement
> > prevent auto
> > negotiation from enabling EEE.
> >
> > This patch provides options to disable 1000T and 100TX EEE
> > advertisement
> > individually for the realtek phys supporting this feature.
> >
> > Reported-by: Martin Blumenstingl <martin.blumenstingl@googlemail.co
> > m>
> > Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> > Cc: Alexandre TORGUE <alexandre.torgue@st.com>
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > Tested-by: Andre Roth <neolynx@gmail.com>
> > ---
> > ?drivers/net/phy/realtek.c | 65
> > ++++++++++++++++++++++++++++++++++++++++++++++-
> > ?1 file changed, 64 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> > index aadd6e9f54ad..77235fd5faaf 100644
> > --- a/drivers/net/phy/realtek.c
> > +++ b/drivers/net/phy/realtek.c
> > @@ -15,6 +15,12 @@
> > ? */
> > ?#include <linux/phy.h>
> > ?#include <linux/module.h>
> > +#include <linux/of.h>
> > +
> > +struct rtl8211x_phy_priv {
> > +???????bool eee_1000t_disable;
> > +???????bool eee_100tx_disable;
> > +};
> >
> > ?#define RTL821x_PHYSR??????????0x11
> > ?#define RTL821x_PHYSR_DUPLEX???0x2000
> > @@ -93,12 +99,44 @@ static int rtl8211f_config_intr(struct
> > phy_device *phydev)
> > ????????return err;
> > ?}
> >
> > +static void rtl8211x_clear_eee_adv(struct phy_device *phydev)
> > +{
> > +???????struct rtl8211x_phy_priv *priv = phydev->priv;
> > +???????u16 val;
> > +
> > +???????if (priv->eee_1000t_disable || priv->eee_100tx_disable) {
> > +???????????????val = phy_read_mmd_indirect(phydev,
> > MDIO_AN_EEE_ADV,
> > +???????????????????????????????????????????MDIO_MMD_AN);
> > +
> > +???????????????if (priv->eee_1000t_disable)
> > +???????????????????????val &= ~MDIO_AN_EEE_ADV_1000T;
> > +???????????????if (priv->eee_100tx_disable)
> > +???????????????????????val &= ~MDIO_AN_EEE_ADV_100TX;
> > +
> > +???????????????phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
> > +??????????????????????????????????????MDIO_MMD_AN, val);
> > +???????}
> > +}
> > +
> > +static int rtl8211x_config_init(struct phy_device *phydev)
> > +{
> > +???????int ret;
> > +
> > +???????ret = genphy_config_init(phydev);
> > +???????if (ret < 0)
> > +???????????????return ret;
> > +
> > +???????rtl8211x_clear_eee_adv(phydev);
> > +
> > +???????return 0;
> > +}
> > +
> > ?static int rtl8211f_config_init(struct phy_device *phydev)
> > ?{
> > ????????int ret;
> > ????????u16 reg;
> >
> > -???????ret = genphy_config_init(phydev);
> > +???????ret = rtl8211x_config_init(phydev);
> > ????????if (ret < 0)
> > ????????????????return ret;
> >
> > @@ -115,6 +153,26 @@ static int rtl8211f_config_init(struct
> > phy_device *phydev)
> > ????????return 0;
> > ?}
> >
> > +static int rtl8211x_phy_probe(struct phy_device *phydev)
> > +{
> > +???????struct device *dev = &phydev->mdio.dev;
> > +???????struct device_node *of_node = dev->of_node;
> > +???????struct rtl8211x_phy_priv *priv;
> > +
> > +???????priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > +???????if (!priv)
> > +???????????????return -ENOMEM;
> > +
> > +???????priv->eee_1000t_disable =
> > +???????????????of_property_read_bool(of_node, "realtek,disable-
> > eee-1000t");
> > +???????priv->eee_100tx_disable =
> > +???????????????of_property_read_bool(of_node, "realtek,disable-
> > eee-100tx");
> > +
> > +???????phydev->priv = priv;
> > +
> > +???????return 0;
> > +}
> > +
> > ?static struct phy_driver realtek_drvs[] = {
> > ????????{
> > ????????????????.phy_id?????????= 0x00008201,
> > @@ -140,7 +198,9 @@ static struct phy_driver realtek_drvs[] = {
> > ????????????????.phy_id_mask????= 0x001fffff,
> > ????????????????.features???????= PHY_GBIT_FEATURES,
> > ????????????????.flags??????????= PHY_HAS_INTERRUPT,
> > +???????????????.probe??????????= &rtl8211x_phy_probe,
> > ????????????????.config_aneg????= genphy_config_aneg,
> > +???????????????.config_init????= &rtl8211x_config_init,
> > ????????????????.read_status????= genphy_read_status,
> > ????????????????.ack_interrupt??= rtl821x_ack_interrupt,
> > ????????????????.config_intr????= rtl8211e_config_intr,
> > @@ -152,7 +212,9 @@ static struct phy_driver realtek_drvs[] = {
> > ????????????????.phy_id_mask????= 0x001fffff,
> > ????????????????.features???????= PHY_GBIT_FEATURES,
> > ????????????????.flags??????????= PHY_HAS_INTERRUPT,
> > +???????????????.probe??????????= &rtl8211x_phy_probe,
> > ????????????????.config_aneg????= &genphy_config_aneg,
> > +???????????????.config_init????= &rtl8211x_config_init,
> > ????????????????.read_status????= &genphy_read_status,
> > ????????????????.ack_interrupt??= &rtl821x_ack_interrupt,
> > ????????????????.config_intr????= &rtl8211e_config_intr,
> > @@ -164,6 +226,7 @@ static struct phy_driver realtek_drvs[] = {
> > ????????????????.phy_id_mask????= 0x001fffff,
> > ????????????????.features???????= PHY_GBIT_FEATURES,
> > ????????????????.flags??????????= PHY_HAS_INTERRUPT,
> > +???????????????.probe??????????= &rtl8211x_phy_probe,
> > ????????????????.config_aneg????= &genphy_config_aneg,
> > ????????????????.config_init????= &rtl8211f_config_init,
> > ????????????????.read_status????= &genphy_read_status,
> > --
> > 2.7.4
> >
>
> How about adding callback functionality for .soft_reset to handle
> BMCR
> where we update the Auto-Negotiation for the phy,
> as per the datasheet of the rtl8211f.
I'm not sure I understand how this would help with our issue (and EEE).
Am I missing something or is it something unrelated that you would like
to see happening on this driver ??
>
> -Best Regard
> Anand Moon
>
> >
> >
> > _______________________________________________
> > linux-amlogic mailing list
> > linux-amlogic at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Vinod Koul @ 2016-11-17 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b33d23d-b7c5-6e6d-454f-755c86ddd5eb@samsung.com>
On Wed, Nov 16, 2016 at 06:31:13PM +0100, Sylwester Nawrocki wrote:
> On 11/16/2016 06:03 PM, Krzysztof Kozlowski wrote:
> > As I understood, everything won't be applied because ASoC tree already
> > contains some work around this?
>
> Yes, sorry, I didn't coordinate this work very well, there are some patches
> for the pcm and the i2s driver already in the ASoC tree which would conflict
> with this series. I'd suggest to ignore patches 5/8...8/8 for now.
Okay, applied 1 thru 4 now after fixing subsystem name on 1st.
Anyone wants to pull can fetch topic/s3c64xx
Thanks
--
~Vinod
^ permalink raw reply
* [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Joel Stanley @ 2016-11-17 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdazPEbU2gmDyke=GTYtjVp8aeauS+PVkp-zuiVoVz7kbw@mail.gmail.com>
Hey Linus,
On Thu, Nov 17, 2016 at 8:00 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Nov 17, 2016 at 7:06 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>
>> +* Device tree bindings for the Aspeed LPC Controller
>
> We are going overboard with the lingo sometimes, to the point that we do not
> understand how terse things become.
>
> LPC = Low Pin Count, right?
> Explain that right here: it is a slow external bus, right?
Yep. 33MHz bus that generally connects a host CPU to other devices on
the same motherboard, such as management controllers.
https://en.wikipedia.org/wiki/Low_Pin_Count
Systems with Aspeed BMCs use the LPC to load the firmware from the BMC
into the host at boot, and send IPMI messages between the host and the
BMC.
BMC stands for Baseboard Management Controller. Back in the day it was
simple keyboard controller microcontroller, these days we use a 800MHz
ARM11 with half a gigabyte of RAM. It provides access to the boot
firmware for the host CPU, monitors the health of the system (fans,
temperature, error logging), and provides remote access for power
cycling and installation.
https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller
Andrew and I work on an open source project that is creating a new BMC
software stack called OpenBMC. You've been merging the wonderful
Aspeed pinmux patches that Andrew wrote recently, which was a major
bit of kernel work required for that project.
>> +The Aspeed LPC controller contains registers for a variety of functions. Not
>> +all registers for a function are contiguous, and some registers are referenced
>> +by functions outside the LPC controller.
>> +
>> +Note that this is separate from the H8S/2168 compatible register set occupying
>> +the start of the LPC controller address space.
>> +
>> +Some significant functions in the LPC controller:
>> +
>> +* LPC Host Controller
>> +* Host Interface Controller
>
> Host interface to what?
Host in this case is the CPU on the motherboard to do the heavy
lifting. x86, ARM64, PowerPC. So this is the BMC's interface to the
host.
>
>> +* iBT Controller
>
> What is iBT?
IPMI Byte Transfer? Something like that. It's the transport that the
host uses to send IPMI messages to the BMC and back.
The host side has been upstream for a while. The BMC side has a driver
staged for v4.10:
https://patchwork.ozlabs.org/patch/674973/
If you're really bored you can read up on IPMI from the specificaiton:
http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html
tl;dr is it's a protocol for communication to the BMC. There is
in-band IPMI, which is between the host and the BMC over the eg. the
BT interface. Or out of band IPMI, which is where you use ipmitool
from your laptop to talk to the BMC over the network.
>
>> +* SuperIO Scratch registers
>
> Again more context please.
The SuperIO name is legacy x86 terminology. These are a few bytes
worth of data that can be set from one side and read by the other in
order to convey firmware-specific information. In OpenPower systems,
we use them to tell the host where to send it's console output when it
is booting.
> With standards documents, either explain everything or provide
> pointers for the information.
If only we could give you the pleasure of reading the Aspeed reference
manual. It's only available from Aspeed under NDA at this point in
time though. If you want further details on anything else then Andrew,
Ben or myself can explain.
Cheers,
Joel
^ permalink raw reply
* [PATCH 4.8 65/92] Revert "clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init"
From: Greg Kroah-Hartman @ 2016-11-17 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117103224.218007793@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen-Yu Tsai <wens@csie.org>
commit 593876838826914a7e4e05fbbcb728be6fbc4d89 upstream.
struct clocksource is also used by the clk notifier callback, to
unregister and re-register the clocksource with a different clock rate.
clocksource_mmio_init does not pass back a pointer to the struct used,
and the clk notifier callback assumes that the struct clocksource in
struct sun5i_timer_clksrc is valid. This results in a kernel NULL
pointer dereference when the hstimer clock is changed:
Unable to handle kernel NULL pointer dereference at virtual address 00000004
[<c03a4678>] (clocksource_unbind) from [<c03a46d4>] (clocksource_unregister+0x2c/0x44)
[<c03a46d4>] (clocksource_unregister) from [<c0a6f350>] (sun5i_rate_cb_clksrc+0x34/0x3c)
[<c0a6f350>] (sun5i_rate_cb_clksrc) from [<c035ea50>] (notifier_call_chain+0x44/0x84)
[<c035ea50>] (notifier_call_chain) from [<c035edc0>] (__srcu_notifier_call_chain+0x44/0x60)
[<c035edc0>] (__srcu_notifier_call_chain) from [<c035edf4>] (srcu_notifier_call_chain+0x18/0x20)
[<c035edf4>] (srcu_notifier_call_chain) from [<c0670174>] (__clk_notify+0x70/0x7c)
[<c0670174>] (__clk_notify) from [<c06702c0>] (clk_propagate_rate_change+0xa4/0xc4)
[<c06702c0>] (clk_propagate_rate_change) from [<c0670288>] (clk_propagate_rate_change+0x6c/0xc4)
Revert the commit for now. clocksource_mmio_init can be made to pass back
a pointer, but the code churn and usage of an inner struct might not be
worth it.
Fixes: 157dfadef832 ("clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init")
Reported-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Cc: linux-sunxi at googlegroups.com
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/20161018054918.26855-1-wens at csie.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clocksource/timer-sun5i.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -152,6 +152,13 @@ static irqreturn_t sun5i_timer_interrupt
return IRQ_HANDLED;
}
+static cycle_t sun5i_clksrc_read(struct clocksource *clksrc)
+{
+ struct sun5i_timer_clksrc *cs = to_sun5i_timer_clksrc(clksrc);
+
+ return ~readl(cs->timer.base + TIMER_CNTVAL_LO_REG(1));
+}
+
static int sun5i_rate_cb_clksrc(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -210,8 +217,13 @@ static int __init sun5i_setup_clocksourc
writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
base + TIMER_CTL_REG(1));
- ret = clocksource_mmio_init(base + TIMER_CNTVAL_LO_REG(1), node->name,
- rate, 340, 32, clocksource_mmio_readl_down);
+ cs->clksrc.name = node->name;
+ cs->clksrc.rating = 340;
+ cs->clksrc.read = sun5i_clksrc_read;
+ cs->clksrc.mask = CLOCKSOURCE_MASK(32);
+ cs->clksrc.flags = CLOCK_SOURCE_IS_CONTINUOUS;
+
+ ret = clocksource_register_hz(&cs->clksrc, rate);
if (ret) {
pr_err("Couldn't register clock source.\n");
goto err_remove_notifier;
^ permalink raw reply
* [PATCH] Replacement for Arm initrd memblock reserve and free inconsistency.
From: william.helsby at stfc.ac.uk @ 2016-11-17 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116234741.GE1041@n2100.armlinux.org.uk>
My understanding of your proposed patch is that it rounds the area to be reserved for the initrd image to page
boundaries. It then checks that this rounding does not grow the initrd to overlap other areas.
If it does not overlap, all is well. The kernel will not kmalloc anything within the partial pages
at the beginning and end of the initrd image. When the initrd image is freed, complete pages are
released and there is no wasted memory.
However, if it does overlap other regions, it disables the initrd image and the kernel panics with no root file system.
My patch rounds the area to be reserved for the initrd image to page boundaries.
It then checks that this rounding does not grow the initrd to overlap other areas.
If it does not overlap the system initialised the ramdisk from the initrd image and then frees the initrd area
with no wasted memory. All is good.
If it does overlap, my code tried to determine the cause of the overlap and fell back to, in the worst case,
just reserving the space actually occupied by the initrd image. In this case the kernel would start,
initialise the ramdisk and try to free the initrd image. At worst 2 partial pages at the beginning and end of
the initrd image would not be freed, wasting up to 8kBytes.
To me this is a more acceptable fallback than deleting the root file system.
Also not that in the current code free_initrd_mem checks:
if (end == initrd_end)
end = round_up(end, PAGE_SIZE);
So only rounds up the end if the whole initrd image is being freed.
If free_initrd_mem is called with end != initrd_end (because the crash kernel area overlaps),
then the end is not rounded up.
However:
poison_init_mem((void *)start, PAGE_ALIGN(end) - start);
will still page align the end address and could potentially overwrite the crash kernel area.
I don't know anything about if and when the crash kernel area is used, but in principle this may be a bad thing.
William.
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at armlinux.org.uk]
Sent: 16 November 2016 23:48
To: Helsby, William (STFC,DL,TECH)
Cc: linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH] Replacement for Arm initrd memblock reserve and free inconsistency.
On Tue, Nov 15, 2016 at 03:45:55PM +0000, william.helsby at stfc.ac.uk wrote:
> The option of moving the initrd code later (after
> early_init_fdt_reserve_self();
> early_init_fdt_scan_reserved_mem() ) was tested.
Moving stuff around tends to break...
I'd prefer to do it this way, as it's much more readable (and we prize readability... see Documentation/CodingStyle.)
arch/arm/mm/init.c | 71 +++++++++++++++++++++++++++++++++---------------------
1 file changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 370581aeb871..ffae20b25929 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -227,6 +227,48 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t align)
return phys;
}
+static void __init arm_initrd_init(void) { #ifdef CONFIG_BLK_DEV_INITRD
+ unsigned long size;
+ phys_addr_t start;
+
+ /* FDT scan will populate initrd_start */
+ if (initrd_start && !phys_initrd_size) {
+ phys_initrd_start = __virt_to_phys(initrd_start);
+ phys_initrd_size = initrd_end - initrd_start;
+ }
+
+ initrd_start = initrd_end = 0;
+
+ if (!phys_initrd_size)
+ return;
+
+ start = phys_initrd_start & PAGE_MASK;
+ size = PAGE_ALIGN(phys_initrd_size + phys_initrd_start - start);
+
+ if (!memblock_is_region_memory(start, size)) {
+ pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling initrd\n",
+ (u64)start, size);
+ phys_initrd_start = phys_initrd_size = 0;
+ return;
+ }
+
+ if (memblock_is_region_reserved(start, size)) {
+ pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory region - disabling initrd\n",
+ (u64)start, size);
+ phys_initrd_start = phys_initrd_size = 0;
+ return;
+ }
+
+ memblock_reserve(start, size);
+
+ /* Now convert initrd to virtual addresses */
+ initrd_start = __phys_to_virt(phys_initrd_start);
+ initrd_end = initrd_start + phys_initrd_size; #endif }
+
void __init arm_memblock_init(const struct machine_desc *mdesc) {
/* Register the kernel text, kernel data and initrd with memblock. */ @@ -235,34 +277,7 @@ void __init arm_memblock_init(const struct machine_desc *mdesc) #else
memblock_reserve(__pa(_stext), _end - _stext); #endif -#ifdef CONFIG_BLK_DEV_INITRD
- /* FDT scan will populate initrd_start */
- if (initrd_start && !phys_initrd_size) {
- phys_initrd_start = __virt_to_phys(initrd_start);
- phys_initrd_size = initrd_end - initrd_start;
- }
- initrd_start = initrd_end = 0;
- if (phys_initrd_size &&
- !memblock_is_region_memory(phys_initrd_start, phys_initrd_size)) {
- pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling initrd\n",
- (u64)phys_initrd_start, phys_initrd_size);
- phys_initrd_start = phys_initrd_size = 0;
- }
- if (phys_initrd_size &&
- memblock_is_region_reserved(phys_initrd_start, phys_initrd_size)) {
- pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory region - disabling initrd\n",
- (u64)phys_initrd_start, phys_initrd_size);
- phys_initrd_start = phys_initrd_size = 0;
- }
- if (phys_initrd_size) {
- memblock_reserve(phys_initrd_start, phys_initrd_size);
-
- /* Now convert initrd to virtual addresses */
- initrd_start = __phys_to_virt(phys_initrd_start);
- initrd_end = initrd_start + phys_initrd_size;
- }
-#endif
-
+ arm_initrd_init();
arm_mm_memblock_reserve();
/* reserve any platform specific memblock areas */
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
^ permalink raw reply
* Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'
From: Mark Rutland @ 2016-11-17 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116224024.GA11821@roeck-us.net>
On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
> On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> > Hi Guenter,
> >
> > On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > Anyway, I guess the problem is that the "official" dtb files no longer provide
> > > the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> > > expect that they are provided. Is that correct ?
> >
> > imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
>
> Yes, but not the 'device_type' property, which the kernel seems to expect.
Memory nodes require this property per ePAPR and the devicetree.org
spec, so the bug is that we didn't add those when removing the
skeleton.dtsi include.
> The qemu patch below fixes the problem for sabrelite, I just don't know
> if that is really the way to go. You tell me; I'll be happy to submit
> the necessary patch(es) into qemu.
As above, I don't think the below patch is necessary. The dt should have
this property to begin with.
> The same is true for 'chosen'. Right now qemu expects this node to exist.
> It does exist for sabrelite, but apparently not for imx25-pdk.
Having QEMU create a /chosen node if one does not exist already sounds
sensible to me.
Thanks,
Mark.
> Guenter
>
> ---
> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
> index 1b913a4..080d1e5 100644
> --- a/hw/arm/boot.c
> +++ b/hw/arm/boot.c
> @@ -486,6 +486,12 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
> g_free(nodename);
> }
> } else {
> + Error *err = NULL;
> +
> + if (!qemu_fdt_getprop(fdt, "/memory", "device_type", NULL, &err)) {
> + qemu_fdt_setprop_string(fdt, "/memory", "device_type", "memory");
> + }
> +
> rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg",
> acells, binfo->loader_start,
> scells, binfo->ram_size);
^ permalink raw reply
* [PATCH v16 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Fu Wei @ 2016-11-17 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d8b5ca3f-d756-ae2e-012c-3cabc38dd39a@huawei.com>
Hi Xiongfeng
On 17 November 2016 at 17:25, Xiongfeng Wang <wangxiongfeng2@huawei.com> wrote:
>
> Sorry for not describing specifically in the last mail.
> I have applied all the patches of this patchset on Linux 4.9, and tested
> the per-cpu timer and sbsa watchdog part, which function well on D05 board.
Thanks for your testing,
So I will apply your Tested-by in 1~8, 11, 12, 15 in my next patchset.
>
> On 2016/11/17 11:34, Xiongfeng Wang wrote:
>> Tested-by: wangxiongfeng2 at huawei.com on D05 board.
>>
>>
>> On 2016/11/16 21:48, fu.wei at linaro.org wrote:
>>> From: Fu Wei <fu.wei@linaro.org>
>>>
>>> This patchset:
>>> (1)Preparation for adding GTDT support in arm_arch_timer:
>>> 1. Move some enums and marcos to header file;
>>> 2. Add a new enum for spi type;
>>> 3. Improve printk relevant code.
>>> 4. rename some enums and defines, and some cleanups.
>>> 5. separate out arch_timer_uses_ppi init code and fix a potential bug
>>> 6. Refactor arch_timer_detect_rate to keep dt code only in *_of_init
>>> 7. Refactor arch_timer_needs_probing, and call it only if acpi disabled.
>>> 8. Introduce some new structs and refactor the timer init code
>>>
>>> (2)Introduce ACPI GTDT parser: drivers/acpi/arm64/acpi_gtdt.c
>>> Parse all kinds of timer in GTDT table of ACPI:arch timer,
>>> memory-mapped timer and SBSA Generic Watchdog timer.
>>> This driver can help to simplify all the relevant timer drivers,
>>> and separate all the ACPI GTDT knowledge from them.
>>>
>>> (3)Simplify ACPI code for arm_arch_timer
>>>
>>> (4)Add GTDT support for ARM memory-mapped timer, also refactor
>>> original memory-mapped timer dt support for reusing some common
>>> code.
>>>
>>> This patchset has been tested on the following platforms with ACPI enabled:
>>> (1)ARM Foundation v8 model
>>>
>>> Changelog:
>>> v16: https://lkml.org/lkml/2016/
>>> Fix patchset problem about static enum ppi_nr of 01/13 in v15.
>>> Refactor arch_timer_detect_rate.
>>> Refactor arch_timer_needs_probing.
>>>
>>> v15: https://lkml.org/lkml/2016/11/15/366
>>> Re-order patches
>>> Add arm_arch_timer refactoring patches to prepare for GTDT:
>>> 1. rename some enums and defines, and some cleanups
>>> 2. separate out arch_timer_uses_ppi init code and fix a potential bug
>>> 3. Improve some new structs, refactor the timer init code.
>>> Since the some structs have been changed, GTDT parser for memory-mapped
>>> timer and SBSA Generic Watchdog timer have been update.
>>>
>>> v14: https://lkml.org/lkml/2016/9/28/573
>>> Separate memory-mapped timer GTDT support into two patches
>>> 1. Refactor the timer init code to prepare for GTDT
>>> 2. Add GTDT support for memory-mapped timer
>>>
>>> v13: http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1231717.html
>>> Improve arm_arch_timer code for memory-mapped
>>> timer GTDT support, refactor original memory-mapped timer
>>> dt support for reusing some common code.
>>>
>>> v12: https://lkml.org/lkml/2016/9/13/250
>>> Rebase to latest Linux 4.8-rc6
>>> Delete the confusing "skipping" in the error message.
>>>
>>> V11: https://lkml.org/lkml/2016/9/6/354
>>> Rebase to latest Linux 4.8-rc5
>>> Delete typedef (suggested by checkpatch.pl)
>>>
>>> V10: https://lkml.org/lkml/2016/7/26/215
>>> Drop the "readq" patch.
>>> Rebase to latest Linux 4.7.
>>>
>>> V9: https://lkml.org/lkml/2016/7/25/345
>>> Improve pr_err message in acpi gtdt driver.
>>> Update Commit message for 7/9
>>> shorten the irq mapping function name
>>> Improve GTDT driver for memory-mapped timer
>>>
>>> v8: https://lkml.org/lkml/2016/7/19/660
>>> Improve "pr_fmt(fmt)" definition: add "ACPI" in front of "GTDT",
>>> and also improve printk message.
>>> Simplify is_timer_block and is_watchdog.
>>> Merge acpi_gtdt_desc_init and gtdt_arch_timer_init into acpi_gtdt_init();
>>> Delete __init in include/linux/acpi.h for GTDT API
>>> Make ARM64 select GTDT.
>>> Delete "#include <linux/module.h>" from acpi_gtdt.c
>>> Simplify GT block parse code.
>>>
>>> v7: https://lkml.org/lkml/2016/7/13/769
>>> Move the GTDT driver to drivers/acpi/arm64
>>> Add add the ARM64-specific ACPI Support maintainers in MAINTAINERS
>>> Merge 3 patches of GTDT parser driver.
>>> Fix the for_each_platform_timer bug.
>>>
>>> v6: https://lkml.org/lkml/2016/6/29/580
>>> split the GTDT driver to 4 parts: basic, arch_timer, memory-mapped timer,
>>> and SBSA Generic Watchdog timer
>>> Improve driver by suggestions and example code from Daniel Lezcano
>>>
>>> v5: https://lkml.org/lkml/2016/5/24/356
>>> Sorting out all patches, simplify the API of GTDT driver:
>>> GTDT driver just fills the data struct for arm_arch_timer driver.
>>>
>>> v4: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006667.html
>>> Delete the kvm relevant patches
>>> Separate two patches for sorting out the code for arm_arch_timer.
>>> Improve irq info export code to allow missing irq info in GTDT table.
>>>
>>> v3: https://lkml.org/lkml/2016/2/1/658
>>> Improve GTDT driver code:
>>> (1)improve pr_* by defining pr_fmt(fmt)
>>> (2)simplify gtdt_sbsa_gwdt_init
>>> (3)improve gtdt_arch_timer_data_init, if table is NULL, it will try
>>> to get GTDT table.
>>> Move enum ppi_nr to arm_arch_timer.h, and add enum spi_nr.
>>> Add arm_arch_timer get ppi from DT and GTDT support for kvm.
>>>
>>> v2: https://lkml.org/lkml/2015/12/2/10
>>> Rebase to latest kernel version(4.4-rc3).
>>> Fix the bug about the config problem,
>>> use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c
>>>
>>> v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553
>>>
>>> Fu Wei (15):
>>> clocksource/drivers/arm_arch_timer: Move enums and defines to header
>>> file
>>> clocksource/drivers/arm_arch_timer: Add a new enum for spi type
>>> clocksource/drivers/arm_arch_timer: Improve printk relevant code
>>> clocksource/drivers/arm_arch_timer: rename some enums and defines, and
>>> some cleanups.
>>> clocksource/drivers/arm_arch_timer: fix a bug in arch_timer_register
>>> about arch_timer_uses_ppi
>>> clocksource/drivers/arm_arch_timer: separate out arch_timer_uses_ppi
>>> init code to prepare for GTDT.
>>> clocksource/drivers/arm_arch_timer: Refactor arch_timer_detect_rate to
>>> keep dt code in *_of_init
>>> clocksource/drivers/arm_arch_timer: Refactor arch_timer_needs_probing,
>>> and call it only if acpi disabled.
>>> clocksource/drivers/arm_arch_timer: Introduce some new structs to
>>> prepare for GTDT
>>> clocksource/drivers/arm_arch_timer: Refactor the timer init code to
>>> prepare for GTDT
>>> acpi/arm64: Add GTDT table parse driver
>>> clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
>>> acpi/arm64: Add memory-mapped timer support in GTDT driver
>>> clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped
>>> timer
>>> acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver
>>>
>>> arch/arm64/Kconfig | 1 +
>>> drivers/acpi/arm64/Kconfig | 3 +
>>> drivers/acpi/arm64/Makefile | 1 +
>>> drivers/acpi/arm64/gtdt.c | 411 +++++++++++++++++++++++++++++
>>> drivers/clocksource/arm_arch_timer.c | 484 ++++++++++++++++++++---------------
>>> drivers/watchdog/Kconfig | 1 +
>>> include/clocksource/arm_arch_timer.h | 61 ++++-
>>> include/linux/acpi.h | 8 +
>>> virt/kvm/arm/hyp/timer-sr.c | 6 +-
>>> 9 files changed, 759 insertions(+), 217 deletions(-)
>>> create mode 100644 drivers/acpi/arm64/gtdt.c
>>>
>>
>>
>> .
>>
>
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: Will Deacon @ 2016-11-17 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117022023.GA5704@linaro.org>
Hi Akashi,
On Thu, Nov 17, 2016 at 02:34:24PM +0900, AKASHI Takahiro wrote:
> On Wed, Nov 16, 2016 at 04:30:15PM +0000, Will Deacon wrote:
> > I thought limit was just a physical address, and then
>
> No, it's not.
Quite right, it's a size. Sorry about that.
> > memblock_mem_limit_remove_map operated on the end of the nearest memblock?
>
> No, but "max_addr" returned by __find_max_addr() is a physical address
> and the end address of memory of "limit" size in total.
>
> > You could leave the __find_max_addr call in memblock_mem_limit_remove_map,
> > given that I don't think you need/want it for memblock_cap_memory_range.
> >
> > > So I added an extra argument, exact, to a common function to specify
> > > distinct behaviors. Confusing? Please see the patch below.
> >
> > Oh yikes, this certainly wasn't what I had in mind! My observation was
> > just that memblock_mem_limit_remove_map(limit) does:
> >
> >
> > 1. memblock_isolate_range(limit - limit+ULLONG_MAX)
> > 2. memblock_remove_region(all non-nomap regions in the isolated region)
> > 3. truncate reserved regions to limit
> >
> > and your memblock_cap_memory_range(base, size) does:
> >
> > 1. memblock_isolate_range(base - base+size)
> > 2, memblock_remove_region(all non-nomap regions above and below the
> > isolated region)
> > 3. truncate reserved regions around the isolated region
> >
> > so, assuming we can invert the isolation in one of the cases, then they
> > could share the same underlying implementation.
>
> Please see my simplified patch below which would explain what I meant.
> (Note that the size is calculated by 'max_addr - 0'.)
>
> > I'm probably just missing something here, because the patch you've ended
> > up with is far more involved than I anticipated...
>
> I hope that it will meet almost your anticipation.
It looks much better, thanks! Just one question below.
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 7608bc3..fea1688 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> (phys_addr_t)ULLONG_MAX);
> }
>
> +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> +{
> + int start_rgn, end_rgn;
> + int i, ret;
> +
> + if (!size)
> + return;
> +
> + ret = memblock_isolate_range(&memblock.memory, base, size,
> + &start_rgn, &end_rgn);
> + if (ret)
> + return;
> +
> + /* remove all the MAP regions */
> + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> + memblock_remove_region(&memblock.memory, i);
In the case that we have only one, giant memblock that covers base all
of base + size, can't we end up with start_rgn = end_rgn = 0? In which
case, we'd end up accidentally removing the map regions here.
The existing code:
> - /* remove all the MAP regions above the limit */
> - for (i = end_rgn - 1; i >= start_rgn; i--) {
> - if (!memblock_is_nomap(&type->regions[i]))
> - memblock_remove_region(type, i);
> - }
seems to handle this.
Will
^ permalink raw reply
* [PATCH] arm: dma-mapping: Reset the device's dma_ops
From: Sricharan R @ 2016-11-17 11:20 UTC (permalink / raw)
To: linux-arm-kernel
arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
,dma_ops should be cleared in the teardown path. Otherwise
this causes problem when the probe of device is retried after
being deferred. The device's iommu structures are cleared
after EPROBEDEFER error, but on the next try dma_ops will still
be set to old value, which is not right.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm/mm/dma-mapping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab4f745..a40f03e 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2358,6 +2358,7 @@ static void arm_teardown_iommu_dma_ops(struct device *dev)
__arm_iommu_detach_device(dev);
arm_iommu_release_mapping(mapping);
+ set_dma_ops(dev, NULL);
}
#else
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v8 1/7] arm/arm64: vgic: Implement support for userspace access
From: Vijay Kilari @ 2016-11-17 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116185215.GC3811@cbox>
On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Fri, Nov 04, 2016 at 04:43:27PM +0530, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>
>> Read and write of some registers like ISPENDR and ICPENDR
>> from userspace requires special handling when compared to
>> guest access for these registers.
>>
>> Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> for handling of ISPENDR, ICPENDR registers handling.
>>
>> Add infrastructure to support guest and userspace read
>> and write for the required registers
>> Also moved vgic_uaccess from vgic-mmio-v2.c to vgic-mmio.c
>>
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> ---
>> virt/kvm/arm/vgic/vgic-mmio-v2.c | 25 ----------
>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 98 ++++++++++++++++++++++++++++++++--------
>> virt/kvm/arm/vgic/vgic-mmio.c | 78 ++++++++++++++++++++++++++++----
>> virt/kvm/arm/vgic/vgic-mmio.h | 19 ++++++++
>> 4 files changed, 169 insertions(+), 51 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> index b44b359..0b32f40 100644
>> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> @@ -406,31 +406,6 @@ int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
>> return -ENXIO;
>> }
>>
>> -/*
>> - * When userland tries to access the VGIC register handlers, we need to
>> - * create a usable struct vgic_io_device to be passed to the handlers and we
>> - * have to set up a buffer similar to what would have happened if a guest MMIO
>> - * access occurred, including doing endian conversions on BE systems.
>> - */
>> -static int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
>> - bool is_write, int offset, u32 *val)
>> -{
>> - unsigned int len = 4;
>> - u8 buf[4];
>> - int ret;
>> -
>> - if (is_write) {
>> - vgic_data_host_to_mmio_bus(buf, len, *val);
>> - ret = kvm_io_gic_ops.write(vcpu, &dev->dev, offset, len, buf);
>> - } else {
>> - ret = kvm_io_gic_ops.read(vcpu, &dev->dev, offset, len, buf);
>> - if (!ret)
>> - *val = vgic_data_mmio_bus_to_host(buf, len);
>> - }
>> -
>> - return ret;
>> -}
>> -
>> int vgic_v2_cpuif_uaccess(struct kvm_vcpu *vcpu, bool is_write,
>> int offset, u32 *val)
>> {
>> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> index 0d3c76a..ce2708d 100644
>> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> @@ -209,6 +209,62 @@ static unsigned long vgic_mmio_read_v3_idregs(struct kvm_vcpu *vcpu,
>> return 0;
>> }
>>
>> +static unsigned long vgic_v3_uaccess_read_pending(struct kvm_vcpu *vcpu,
>> + gpa_t addr, unsigned int len)
>> +{
>> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
>> + u32 value = 0;
>> + int i;
>> +
>> + /*
>> + * A level triggerred interrupt pending state is latched in both
>> + * "soft_pending" and "line_level" variables. Userspace will save
>> + * and restore soft_pending and line_level separately.
>> + * Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> + * handling of ISPENDR and ICPENDR.
>> + */
>> + for (i = 0; i < len * 8; i++) {
>> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
>> +
>> + if (irq->config == VGIC_CONFIG_LEVEL && irq->soft_pending)
>> + value |= (1U << i);
>> + if (irq->config == VGIC_CONFIG_EDGE && irq->pending)
>> + value |= (1U << i);
>> +
>> + vgic_put_irq(vcpu->kvm, irq);
>> + }
>> +
>> + return value;
>> +}
>> +
>> +static void vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
>> + gpa_t addr, unsigned int len,
>> + unsigned long val)
>> +{
>> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
>> + int i;
>> +
>> + for (i = 0; i < len * 8; i++) {
>> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
>> +
>> + spin_lock(&irq->irq_lock);
>> + if (test_bit(i, &val)) {
>> + irq->pending = true;
>> + irq->soft_pending = true;
>
> In the vgic_mmio_write_spending function we only set the soft_pending
> state to true if the interrupt is a level-triggered interrupt.
>
> Should we check if that's the case here as well before setting the
> soft_pending state?
Yes, can be done. But it puts hard requirement that irq config should
be restored
before updating pending state.
In any case, the soft_pending is used only if interrupt is level-triggered.
>
> Otherwise, this patch looks good.
>
> Thanks,
> -Christoffer
>
^ permalink raw reply
* [PATCH fpga 1/9] fpga zynq: Add missing \n to messages
From: Matthias Brugger @ 2016-11-17 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115180813.GB1852@obsidianresearch.com>
On 15/11/16 19:08, Jason Gunthorpe wrote:
>
> On Tue, Nov 15, 2016 at 12:05:15PM +0100, Matthias Brugger wrote:
>> On 09/11/16 23:58, Jason Gunthorpe wrote:
>>> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>>
>> Please add a commit message, although it is cristal clear what this patch
>> does :)
>
> As you say, it is crystal clear already, and this is an acceptable commit
> message.. Please suggest a text if you want to see something
> different.
>
"Function dev_err doesn't add a newline at the end of the string. This
will lead to a hard to read kernel log. This patch fixes this."
With this (or something similar added):
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Regards,
Matthias
^ permalink raw reply
* [PATCH] ARM64: dma-mapping: preallocate DMA-debug hash tables in core_initcall
From: Marek Szyprowski @ 2016-11-17 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116123918.qzaqczaqri2hab43@localhost>
Hi Catalin,
On 2016-11-16 13:39, Catalin Marinas wrote:
> On Wed, Nov 16, 2016 at 10:20:13AM +0100, Marek Szyprowski wrote:
>> fs_initcall is definitely too late to initialize DMA-debug hash tables,
>> because some drivers might get probed and use DMA mapping framework
>> already in core_initcall. Late initialization of DMA-debug results in
>> false warning about accessing memory, that was not allocated. This issue
>> has been observed on ARM 32bit, but the same driver can be used also on
>> ARM64.
>>
>> This patch moves initialization of DMA-debug to core_initcall. This is
>> safe from the initialization perspective. dma_debug_do_init() internally
>> calls debugfs functions and debugfs also gets initialised at
>> core_initcall(), and that is earlier than arch code in the link order,
>> so it will get initialized just before the DMA-debug.
> Do we really want to rely on the link order within an initcall level?
> What guarantees this?
There are many places in the kernel which rely on link order and I'm
convinced
that calling initcalls in link order is guaranteed.
> I hope someone sorts out the deferred probe or some other dependency
> detection mechanism to address this issue. But in the meantime I
> wouldn't merge a patch which relies on just the link order.
This has nothing to deferred probe. This patch is related to initialization
of dma-debug framework. In my initial submission for ARM arch I proposed
pure_initcall to have this infrastructure available as early as possible,
but Russell pointed that dma-debug depends on debugfs initialization, so
it should be initialized after it. He also pointed that core_initcall will
be fine for this.
Please also note that dt devices are also populated from core_initcall and
drivers can then bind to them and try to use dma-mapping api, what results
in false warnings about using uninitialized memory as dma-debug framework
is unable to track allocations done before its initialization.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v8 1/7] arm/arm64: vgic: Implement support for userspace access
From: Christoffer Dall @ 2016-11-17 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6vbFj3aoSiqc4n_92rZgONeQVhp-GtTkEhW3=pt9P1hGQ@mail.gmail.com>
On Thu, Nov 17, 2016 at 04:56:53PM +0530, Vijay Kilari wrote:
> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Fri, Nov 04, 2016 at 04:43:27PM +0530, vijay.kilari at gmail.com wrote:
> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >>
> >> Read and write of some registers like ISPENDR and ICPENDR
> >> from userspace requires special handling when compared to
> >> guest access for these registers.
> >>
> >> Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> >> for handling of ISPENDR, ICPENDR registers handling.
> >>
> >> Add infrastructure to support guest and userspace read
> >> and write for the required registers
> >> Also moved vgic_uaccess from vgic-mmio-v2.c to vgic-mmio.c
> >>
> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> ---
> >> virt/kvm/arm/vgic/vgic-mmio-v2.c | 25 ----------
> >> virt/kvm/arm/vgic/vgic-mmio-v3.c | 98 ++++++++++++++++++++++++++++++++--------
> >> virt/kvm/arm/vgic/vgic-mmio.c | 78 ++++++++++++++++++++++++++++----
> >> virt/kvm/arm/vgic/vgic-mmio.h | 19 ++++++++
> >> 4 files changed, 169 insertions(+), 51 deletions(-)
> >>
> >> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >> index b44b359..0b32f40 100644
> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >> @@ -406,31 +406,6 @@ int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
> >> return -ENXIO;
> >> }
> >>
> >> -/*
> >> - * When userland tries to access the VGIC register handlers, we need to
> >> - * create a usable struct vgic_io_device to be passed to the handlers and we
> >> - * have to set up a buffer similar to what would have happened if a guest MMIO
> >> - * access occurred, including doing endian conversions on BE systems.
> >> - */
> >> -static int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> >> - bool is_write, int offset, u32 *val)
> >> -{
> >> - unsigned int len = 4;
> >> - u8 buf[4];
> >> - int ret;
> >> -
> >> - if (is_write) {
> >> - vgic_data_host_to_mmio_bus(buf, len, *val);
> >> - ret = kvm_io_gic_ops.write(vcpu, &dev->dev, offset, len, buf);
> >> - } else {
> >> - ret = kvm_io_gic_ops.read(vcpu, &dev->dev, offset, len, buf);
> >> - if (!ret)
> >> - *val = vgic_data_mmio_bus_to_host(buf, len);
> >> - }
> >> -
> >> - return ret;
> >> -}
> >> -
> >> int vgic_v2_cpuif_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> >> int offset, u32 *val)
> >> {
> >> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> index 0d3c76a..ce2708d 100644
> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> @@ -209,6 +209,62 @@ static unsigned long vgic_mmio_read_v3_idregs(struct kvm_vcpu *vcpu,
> >> return 0;
> >> }
> >>
> >> +static unsigned long vgic_v3_uaccess_read_pending(struct kvm_vcpu *vcpu,
> >> + gpa_t addr, unsigned int len)
> >> +{
> >> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> >> + u32 value = 0;
> >> + int i;
> >> +
> >> + /*
> >> + * A level triggerred interrupt pending state is latched in both
> >> + * "soft_pending" and "line_level" variables. Userspace will save
> >> + * and restore soft_pending and line_level separately.
> >> + * Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> >> + * handling of ISPENDR and ICPENDR.
> >> + */
> >> + for (i = 0; i < len * 8; i++) {
> >> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> >> +
> >> + if (irq->config == VGIC_CONFIG_LEVEL && irq->soft_pending)
> >> + value |= (1U << i);
> >> + if (irq->config == VGIC_CONFIG_EDGE && irq->pending)
> >> + value |= (1U << i);
> >> +
> >> + vgic_put_irq(vcpu->kvm, irq);
> >> + }
> >> +
> >> + return value;
> >> +}
> >> +
> >> +static void vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
> >> + gpa_t addr, unsigned int len,
> >> + unsigned long val)
> >> +{
> >> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> >> + int i;
> >> +
> >> + for (i = 0; i < len * 8; i++) {
> >> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> >> +
> >> + spin_lock(&irq->irq_lock);
> >> + if (test_bit(i, &val)) {
> >> + irq->pending = true;
> >> + irq->soft_pending = true;
> >
> > In the vgic_mmio_write_spending function we only set the soft_pending
> > state to true if the interrupt is a level-triggered interrupt.
> >
> > Should we check if that's the case here as well before setting the
> > soft_pending state?
>
> Yes, can be done. But it puts hard requirement that irq config should
> be restored
> before updating pending state.
Ah, I see.
ok, I think you should keep it the way it is then, but please add a
comment to that effect.
> In any case, the soft_pending is used only if interrupt is level-triggered.
>
Yes, indeed.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v8 0/7] arm/arm64: vgic: Implement API for vGICv3 live migration
From: Christoffer Dall @ 2016-11-17 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258013-6669-1-git-send-email-vijay.kilari@gmail.com>
Hi Vijaya,
On Fri, Nov 04, 2016 at 04:43:26PM +0530, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> This patchset adds API for saving and restoring
> of VGICv3 registers to support live migration with new vgic feature.
> This API definition is as per version of VGICv3 specification
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>
> The patch 3 & 4 are picked from the Pavel's previous implementation.
> http://www.spinics.net/lists/kvm/msg122040.html
>
> v7 => v8:
> - Rebased to 4.9-rc3
I noticed when looking at this series that there are quite a few
conflicts when applying to kvmarm/queue, so if you could rebase the next
verson on kvmarm/queue, then you'll make Marc's life a bit easier.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 0/3] thermal: Fix module autoload for drivers
From: Javier Martinez Canillas @ 2016-11-17 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476455702-21748-1-git-send-email-javier@osg.samsung.com>
Hello Eduardo,
On Fri, Oct 14, 2016 at 11:34 AM, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> Hello,
>
> This small series contains trivial fixes to allow modules to be autoloaded
> when its correspoinding thermal device is registered.
>
> Best regards,
> Javier
>
>
> Javier Martinez Canillas (3):
> thermal: max77620: Fix module autoload
> thermal: tango: Fix module autoload
> thermal: db8500: Fix module autoload
>
Any comments about these patches?
Best regards,
Javier
^ permalink raw reply
* [RFC PATCH] of: base: add support to get machine model name
From: Sudeep Holla @ 2016-11-17 11:50 UTC (permalink / raw)
To: linux-arm-kernel
Currently platforms/drivers needing to get the machine model name are
replicating the same snippet of code. In some case, the OF reference
counting is either missing or incorrect.
This patch adds support to read the machine model name either using
the "model" or the "compatible" property in the device tree root node.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm/mach-imx/cpu.c | 4 +---
arch/arm/mach-mxs/mach-mxs.c | 3 +--
arch/mips/cavium-octeon/setup.c | 12 ++----------
arch/mips/generic/proc.c | 15 +++------------
arch/sh/boards/of-generic.c | 6 +-----
drivers/of/base.c | 34 ++++++++++++++++++++++++++++++++++
drivers/soc/fsl/guts.c | 3 +--
drivers/soc/renesas/renesas-soc.c | 4 +---
include/linux/of.h | 6 ++++++
9 files changed, 50 insertions(+), 37 deletions(-)
Hi,
While trying to fix a simple build warning(as below) in -next for fsl/guts.c,
I came across this code duplication in multiple places.
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
With CONFIG_DEBUG_SECTION_MISMATCH enabled, the details are reported:
WARNING: vmlinux.o(.text+0x55d014): Section mismatch in reference from the
function fsl_guts_probe() to the function
.init.text:of_flat_dt_get_machine_name()
The function fsl_guts_probe() references
the function __init of_flat_dt_get_machine_name().
This is often because fsl_guts_probe lacks a __init
annotation or the annotation of of_flat_dt_get_machine_name is wrong.
I can split the patch if needed if people are OK with the idea.
Regards,
Sudeep
diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
index b3347d32349f..846f40008752 100644
--- a/arch/arm/mach-imx/cpu.c
+++ b/arch/arm/mach-imx/cpu.c
@@ -85,9 +85,7 @@ struct device * __init imx_soc_device_init(void)
soc_dev_attr->family = "Freescale i.MX";
- root = of_find_node_by_path("/");
- ret = of_property_read_string(root, "model", &soc_dev_attr->machine);
- of_node_put(root);
+ ret = of_machine_get_model_name(&soc_dev_attr->machine);
if (ret)
goto free_soc;
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index e4f21086b42b..ed9af3a894f0 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -391,8 +391,7 @@ static void __init mxs_machine_init(void)
if (!soc_dev_attr)
return;
- root = of_find_node_by_path("/");
- ret = of_property_read_string(root, "model", &soc_dev_attr->machine);
+ ret = of_machine_get_model_name(&soc_dev_attr->machine);
if (ret)
return;
diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index 9a2db1c013d9..2e2b1b5befa4 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -498,16 +498,8 @@ static void __init init_octeon_system_type(void)
char const *board_type;
board_type = cvmx_board_type_to_string(octeon_bootinfo->board_type);
- if (board_type == NULL) {
- struct device_node *root;
- int ret;
-
- root = of_find_node_by_path("/");
- ret = of_property_read_string(root, "model", &board_type);
- of_node_put(root);
- if (ret)
- board_type = "Unsupported Board";
- }
+ if (!board_type && of_machine_get_model_name(&board_type))
+ board_type = "Unsupported Board";
snprintf(octeon_system_type, sizeof(octeon_system_type), "%s (%s)",
board_type, octeon_model_get_string(read_c0_prid()));
diff --git a/arch/mips/generic/proc.c b/arch/mips/generic/proc.c
index 42b33250a4a2..f7fc067bf908 100644
--- a/arch/mips/generic/proc.c
+++ b/arch/mips/generic/proc.c
@@ -10,20 +10,11 @@
#include <linux/of.h>
-#include <asm/bootinfo.h>
-
const char *get_system_type(void)
{
const char *str;
- int err;
-
- err = of_property_read_string(of_root, "model", &str);
- if (!err)
- return str;
-
- err = of_property_read_string_index(of_root, "compatible", 0, &str);
- if (!err)
- return str;
- return "Unknown";
+ if (of_machine_get_model_name(&str))
+ return "Unknown";
+ return str;
}
diff --git a/arch/sh/boards/of-generic.c b/arch/sh/boards/of-generic.c
index 1fb6d5714bae..938a14499298 100644
--- a/arch/sh/boards/of-generic.c
+++ b/arch/sh/boards/of-generic.c
@@ -135,11 +135,7 @@ static void __init sh_of_setup(char **cmdline_p)
board_time_init = sh_of_time_init;
sh_mv.mv_name = "Unknown SH model";
- root = of_find_node_by_path("/");
- if (root) {
- of_property_read_string(root, "model", &sh_mv.mv_name);
- of_node_put(root);
- }
+ of_machine_get_model_name(&sh_mv.mv_name);
sh_of_smp_probe();
}
diff --git a/drivers/of/base.c b/drivers/of/base.c
index a0bccb54a9bd..752cb8eefd6e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -546,6 +546,40 @@ int of_machine_is_compatible(const char *compat)
EXPORT_SYMBOL(of_machine_is_compatible);
/**
+ * of_machine_get_model_name - Find and read the model name or the compatible
+ * value for the machine.
+ * @model: pointer to null terminated return string, modified only if
+ * return value is 0.
+ *
+ * Returns a string containing either the model name or the compatible value
+ * of the machine if found, else return error.
+ *
+ * Search for a machine model name or the compatible if model name is missing
+ * in a device tree node and retrieve a null terminated string value (pointer
+ * to data, not a copy). Returns 0 on success, -EINVAL if root of the device
+ * tree is not found and other error returned by of_property_read_string on
+ * failure.
+ */
+int of_machine_get_model_name(const char **model)
+{
+ int error;
+ struct device_node *root;
+
+ root = of_find_node_by_path("/");
+ if (!root)
+ return -EINVAL;
+
+ error = of_property_read_string(root, "model", model);
+ if (error)
+ error = of_property_read_string_index(root, "compatible",
+ 0, model);
+ of_node_put(root);
+
+ return error;
+}
+EXPORT_SYMBOL(of_machine_get_model_name);
+
+/**
* __of_device_is_available - check if a device is available for use
*
* @device: Node to check for availability, with locks already held
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 0ac88263c2d7..94aef0465451 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -152,8 +152,7 @@ static int fsl_guts_probe(struct platform_device *pdev)
return PTR_ERR(guts->regs);
/* Register soc device */
- machine = of_flat_dt_get_machine_name();
- if (machine)
+ if (!of_machine_get_model_name(&machine))
soc_dev_attr.machine = devm_kstrdup(dev, machine, GFP_KERNEL);
svr = fsl_guts_get_svr();
diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
index 330960312296..d9a119073de5 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -228,9 +228,7 @@ static int __init renesas_soc_init(void)
if (!soc_dev_attr)
return -ENOMEM;
- np = of_find_node_by_path("/");
- of_property_read_string(np, "model", &soc_dev_attr->machine);
- of_node_put(np);
+ of_machine_get_model_name(&soc_dev_attr->machine);
soc_dev_attr->family = kstrdup_const(family->name, GFP_KERNEL);
soc_dev_attr->soc_id = kstrdup_const(strchr(match->compatible, ',') + 1,
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..13fc66531f1b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -367,6 +367,7 @@ extern int of_alias_get_id(struct device_node *np, const char *stem);
extern int of_alias_get_highest_id(const char *stem);
extern int of_machine_is_compatible(const char *compat);
+extern int of_machine_get_model_name(const char **model);
extern int of_add_property(struct device_node *np, struct property *prop);
extern int of_remove_property(struct device_node *np, struct property *prop);
@@ -788,6 +789,11 @@ static inline int of_machine_is_compatible(const char *compat)
return 0;
}
+static inline int of_machine_get_model_name(const char **model)
+{
+ return -EINVAL;
+}
+
static inline bool of_console_check(const struct device_node *dn, const char *name, int index)
{
return false;
--
2.7.4
^ permalink raw reply related
* [PATCH] arm: dma-mapping: Reset the device's dma_ops
From: Marek Szyprowski @ 2016-11-17 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479381645-3230-1-git-send-email-sricharan@codeaurora.org>
Hi Sricharan,
On 2016-11-17 12:20, Sricharan R wrote:
> arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
> ,dma_ops should be cleared in the teardown path. Otherwise
> this causes problem when the probe of device is retried after
> being deferred. The device's iommu structures are cleared
> after EPROBEDEFER error, but on the next try dma_ops will still
> be set to old value, which is not right.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mm/dma-mapping.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index ab4f745..a40f03e 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -2358,6 +2358,7 @@ static void arm_teardown_iommu_dma_ops(struct device *dev)
>
> __arm_iommu_detach_device(dev);
> arm_iommu_release_mapping(mapping);
> + set_dma_ops(dev, NULL);
> }
>
> #else
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 0/4] Fixes for Vybrid SPI DMA implementation
From: Sanchayan Maity @ 2016-11-17 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111122036.fubv7b4jc5vkdxhc@sirena.org.uk>
Hello,
The following set of patches have fixes for Vybrid SPI DMA
implementation along with some minor clean ups requested
at time when v3 version of SPI DMA support patch was accepted.
This series of patches is based on top of branch topic/fsl-dspi.
http://git.kernel.org/cgit/linux/kernel/git/broonie/spi.git/log/?h=topic/fsl-dspi
The patches have been tested on a Toradex Colibri Vybrid VF61 module.
Thanks & Regards,
Sanchayan.
Sanchayan Maity (4):
spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
spi: spi-fsl-dspi: Fix incorrect DMA setup
spi: spi-fsl-dspi: Fix continuous selection format
spi: spi-fsl-dspi: Minor code cleanup and error path fixes
drivers/spi/spi-fsl-dspi.c | 69 ++++++++++++++++++++++++++++++++++------------
1 file changed, 51 insertions(+), 18 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
From: Sanchayan Maity @ 2016-11-17 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479384571.git.maitysanchayan@gmail.com>
Current DMA implementation had a bug where the DMA transfer would
exit the loop in dspi_transfer_one_message after the completion of
a single transfer. This results in a multi message transfer submitted
with SPI_IOC_MESSAGE to terminate incorrectly without an error.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index bc64700..b1ee1f5 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -714,7 +714,7 @@ static int dspi_transfer_one_message(struct spi_master *master,
SPI_RSER_TFFFE | SPI_RSER_TFFFD |
SPI_RSER_RFDFE | SPI_RSER_RFDFD);
status = dspi_dma_xfer(dspi);
- goto out;
+ break;
default:
dev_err(&dspi->pdev->dev, "unsupported trans_mode %u\n",
trans_mode);
@@ -722,9 +722,13 @@ static int dspi_transfer_one_message(struct spi_master *master,
goto out;
}
- if (wait_event_interruptible(dspi->waitq, dspi->waitflags))
- dev_err(&dspi->pdev->dev, "wait transfer complete fail!\n");
- dspi->waitflags = 0;
+ if (trans_mode != DSPI_DMA_MODE) {
+ if (wait_event_interruptible(dspi->waitq,
+ dspi->waitflags))
+ dev_err(&dspi->pdev->dev,
+ "wait transfer complete fail!\n");
+ dspi->waitflags = 0;
+ }
if (transfer->delay_usecs)
udelay(transfer->delay_usecs);
--
2.10.2
^ permalink raw reply related
* [PATCH 2/4] spi: spi-fsl-dspi: Fix incorrect DMA setup
From: Sanchayan Maity @ 2016-11-17 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479384571.git.maitysanchayan@gmail.com>
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.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index b1ee1f5..aee8c88 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -265,7 +265,10 @@ 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 /
+ (tx_word ? 2 : 1),
+ 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 +284,10 @@ 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 /
+ (tx_word ? 2 : 1),
+ 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");
--
2.10.2
^ permalink raw reply related
* [PATCH 3/4] spi: spi-fsl-dspi: Fix continuous selection format
From: Sanchayan Maity @ 2016-11-17 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479384571.git.maitysanchayan@gmail.com>
Current DMA implementation was not handling the continuous selection
format viz. SPI chip select would be deasserted even between sequential
serial transfers. Use the cs_change variable and correctly set or
reset the CONT bit accordingly for case where peripherals require
the chip select to be asserted between sequential transfers.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index aee8c88..164e2e1 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -258,9 +258,16 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
}
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);
+ if (dspi->cs_change) {
+ dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
+ SPI_PUSHR_PCS(dspi->cs) |
+ SPI_PUSHR_CTAS(0);
+ } else {
+ 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;
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
--
2.10.2
^ permalink raw reply related
* [PATCH 4/4] spi: spi-fsl-dspi: Minor code cleanup and error path fixes
From: Sanchayan Maity @ 2016-11-17 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479384571.git.maitysanchayan@gmail.com>
Code cleanup for improving code readability and error path fixes
and cleanup removing use of devm_kfree.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
drivers/spi/spi-fsl-dspi.c | 34 +++++++++++++++++++++++++---------
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 164e2e1..382a7f9 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -222,13 +222,18 @@ static void dspi_rx_dma_callback(void *arg)
rx_word = is_double_byte_mode(dspi);
- len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
+ if (rx_word)
+ len = dma->curr_xfer_len / 2;
+ else
+ len = dma->curr_xfer_len;
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
for (i = 0; i < len; i++) {
d = dspi->dma->rx_dma_buf[i];
- rx_word ? (*(u16 *)dspi->rx = d) :
- (*(u8 *)dspi->rx = d);
+ if (rx_word)
+ *(u16 *)dspi->rx = d;
+ else
+ *(u8 *)dspi->rx = d;
dspi->rx += rx_word + 1;
}
}
@@ -247,17 +252,27 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
tx_word = is_double_byte_mode(dspi);
- len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
+ if (tx_word)
+ len = dma->curr_xfer_len / 2;
+ else
+ len = dma->curr_xfer_len;
for (i = 0; i < len - 1; i++) {
- val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
+ if (tx_word)
+ val = *(u16 *) dspi->tx;
+ else
+ val = *(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;
}
- val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
+ if (tx_word)
+ val = *(u16 *) dspi->tx;
+ else
+ val = *(u8 *) dspi->tx;
+
if (dspi->cs_change) {
dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
SPI_PUSHR_PCS(dspi->cs) |
@@ -440,15 +455,16 @@ 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:
dma_release_channel(dma->chan_rx);
- devm_kfree(dev, dma);
dspi->dma = NULL;
return ret;
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] drm/i2c: tda998x: allow interrupt to be shared
From: Brian Starkey @ 2016-11-17 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1c6xls-0006wf-Jg@rmk-PC.armlinux.org.uk>
Hi Russell,
On Wed, Nov 16, 2016 at 10:48:52AM +0000, Russell King wrote:
>The TDA998x contains two different I2C devices - there is the HDMI
>encoder, and the TDA9950 CEC engine. These two share the same interrupt
>signal.
>
>In order to allow a driver for the CEC engine to work, we need to be
>able to share the interrupt with the CEC driver, so convert the handler
>and registration to allow this to happen.
>
>Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>---
>This patch follows on from:
> "drm/i2c: tda998x: power down pre-filter and color conversion"
>which is now part of my drm-tda998x-devel branch, a branch which will
>shortly be part of linux-next. This patch and the following patch are
>not part of that branch yet.
>
>I don't believe I received any testing for the power-down patch above
>either, so if I can have some tested-bys/reviewed-bys for it and these
>two patches, that'd be great. Thanks.
I tested these two and the power-down one on mali-dp and hdlcd. The
output, hotplugging and EDID continued to work; so you can have my
tested-by and reviewed-by for all 3.
Cheers,
Brian
>
>As my Juno has now been fixed, I've been able to test these two patches
>on the HDLCD on Juno and Dove Cubox.
>
> drivers/gpu/drm/i2c/tda998x_drv.c | 52 ++++++++++++++++++++-------------------
> 1 file changed, 27 insertions(+), 25 deletions(-)
>
>diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
>index bf5eec0c1b4f..74fb59a35269 100644
>--- a/drivers/gpu/drm/i2c/tda998x_drv.c
>+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>@@ -634,28 +634,30 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
> bool handled = false;
>
> sta = cec_read(priv, REG_CEC_INTSTATUS);
>- cec = cec_read(priv, REG_CEC_RXSHPDINT);
>- lvl = cec_read(priv, REG_CEC_RXSHPDLEV);
>- flag0 = reg_read(priv, REG_INT_FLAGS_0);
>- flag1 = reg_read(priv, REG_INT_FLAGS_1);
>- flag2 = reg_read(priv, REG_INT_FLAGS_2);
>- DRM_DEBUG_DRIVER(
>- "tda irq sta %02x cec %02x lvl %02x f0 %02x f1 %02x f2 %02x\n",
>- sta, cec, lvl, flag0, flag1, flag2);
>-
>- if (cec & CEC_RXSHPDINT_HPD) {
>- if (lvl & CEC_RXSHPDLEV_HPD)
>- tda998x_edid_delay_start(priv);
>- else
>- schedule_work(&priv->detect_work);
>-
>- handled = true;
>- }
>+ if (sta & CEC_INTSTATUS_HDMI) {
>+ cec = cec_read(priv, REG_CEC_RXSHPDINT);
>+ lvl = cec_read(priv, REG_CEC_RXSHPDLEV);
>+ flag0 = reg_read(priv, REG_INT_FLAGS_0);
>+ flag1 = reg_read(priv, REG_INT_FLAGS_1);
>+ flag2 = reg_read(priv, REG_INT_FLAGS_2);
>+ DRM_DEBUG_DRIVER(
>+ "tda irq sta %02x cec %02x lvl %02x f0 %02x f1 %02x f2 %02x\n",
>+ sta, cec, lvl, flag0, flag1, flag2);
>+
>+ if (cec & CEC_RXSHPDINT_HPD) {
>+ if (lvl & CEC_RXSHPDLEV_HPD)
>+ tda998x_edid_delay_start(priv);
>+ else
>+ schedule_work(&priv->detect_work);
>+
>+ handled = true;
>+ }
>
>- if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
>- priv->wq_edid_wait = 0;
>- wake_up(&priv->wq_edid);
>- handled = true;
>+ if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
>+ priv->wq_edid_wait = 0;
>+ wake_up(&priv->wq_edid);
>+ handled = true;
>+ }
> }
>
> return IRQ_RETVAL(handled);
>@@ -1542,7 +1544,7 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
>
> /* initialize the optional IRQ */
> if (client->irq) {
>- int irqf_trigger;
>+ unsigned long irq_flags;
>
> /* init read EDID waitqueue and HDP work */
> init_waitqueue_head(&priv->wq_edid);
>@@ -1552,11 +1554,11 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
> reg_read(priv, REG_INT_FLAGS_1);
> reg_read(priv, REG_INT_FLAGS_2);
>
>- irqf_trigger =
>+ irq_flags =
> irqd_get_trigger_type(irq_get_irq_data(client->irq));
>+ irq_flags |= IRQF_SHARED | IRQF_ONESHOT;
> ret = request_threaded_irq(client->irq, NULL,
>- tda998x_irq_thread,
>- irqf_trigger | IRQF_ONESHOT,
>+ tda998x_irq_thread, irq_flags,
> "tda998x", priv);
> if (ret) {
> dev_err(&client->dev,
>--
>2.7.4
>
^ permalink raw reply
* [RESEND][PATCH 6/6] arm64: Add DTS support for FSL's LS2088A SoC
From: Abhimanyu Saini @ 2016-11-17 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114063346.GH3310@dragon>
> > Following levels of DTSI/DTS files have been created for the LS2088A
> > SoC family:
> >
> > - fsl-ls2088a.dtsi:
> > DTS-Include file for FSL LS2088A SoC.
> >
> > - fsl-ls2088a-qds.dts:
> > DTS file for FSL LS2088A QDS board.
> >
> > - fsl-ls2088a-rdb.dts:
> > DTS file for FSL LS2088A RDB board.
>
> I compared the following files.
>
> fsl-ls2088a.dtsi vs. fsl-ls2080a.dtsi
> fsl-ls2088a-qds.dtsi vs. fsl-ls2080a-qds.dtsi fsl-ls2088a-rdb.dtsi vs.
> fsl-ls2080a-rdb.dtsi
>
> They are basically identical except a couple of small changes. Can we do
> something to have these SoCs share the dts files at some level to avoid
> maintaining duplicated files?
Hi Shawn,
Yes, we could reorganize DTSI and DTS file.
I can create fsl-ls2080a-ls2088a.dtsi and move all the common nodes to this file,
Then fsl-ls2080a.dtsi and fsl-ls2088a.dtsi which will include
the common file and add ls2080a and ls2088a specific nodes respectively.
Same hierarchy can be created for fsl-ls2080a-qds.dts, fsl-ls2080a-rdb,
fsl-ls2088a-qds.dts and fsl-ls2088a-rdb, wherein the common nodes will lie in
fsl-ls2080a-ls2088a-qds.dts and fsl-ls2080a-ls2088a-rdb.dts
What do you think?
Abhimanyu
^ 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