* [PATCH 9/9] Input: wm97xx: add new AC97 bus support
From: Charles Keepax @ 2016-10-27 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-10-git-send-email-robert.jarzmik@free.fr>
On Wed, Oct 26, 2016 at 09:41:47PM +0200, Robert Jarzmik wrote:
> This adds support for the new AC97 bus code, which discovers the devices
> rather than uses platform data.
>
> As part of this discovery, it enables a multi-function device wm97xx,
> which supports touchscreen, battery, ADC and an audio codec. This patch
> adds the code to bind the touchscreen "cell" as the touchscreen driver.
>
> This was tested on the pxa architecture with a pxa270 + wm9713 + the
> mioa701 touchscreen.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Thanks,
Charles
^ permalink raw reply
* [PATCH v3] drivers: psci: PSCI checker module
From: Lorenzo Pieralisi @ 2016-10-27 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026181148.GW3716@linux.vnet.ibm.com>
On Wed, Oct 26, 2016 at 11:11:48AM -0700, Paul E. McKenney wrote:
> On Wed, Oct 26, 2016 at 06:35:34PM +0100, Lorenzo Pieralisi wrote:
> > On Wed, Oct 26, 2016 at 10:22:52AM -0700, Paul E. McKenney wrote:
> > > On Wed, Oct 26, 2016 at 06:10:06PM +0100, Lorenzo Pieralisi wrote:
>
> [ . . . ]
>
> > > > Thanks a lot for your feedback, thoughts appreciated.
> > >
> > > Let me ask the question more directly.
> > >
> > > Why on earth are we trying to run these tests concurrently?
> >
> > We must prevent that, no question about that, that's why I started
> > this discussion. It is not fine to enable this checker and the
> > RCU/LOCK torture hotplug tests at the same time.
> >
> > > After all, if we just run one at a time in isolation, there is no
> > > problem.
> >
> > Fine by me, it was to understand if the current assumptions we made
> > are correct and they are definitely not. If we enable the PSCI checker
> > we must disable the torture rcu/lock hotplug tests either statically or
> > dynamically.
>
> What rcutorture, locktorture, and rcuperf do is to invoke
> torture_init_begin(), which returns false if one of these tests
> is already running.
>
> Perhaps we should extract this torture-test-exclusion and require
> than conflicting torture tests invoke it?
Yes if it can be extracted as a check (but it should also prevent the
torture tests from running and vice versa), either that or Kconfig
dependency (which we could do as a first step, waiting to add the
required interface to the torture test code ?).
Thanks !
Lorenzo
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Hans de Goede @ 2016-10-27 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ-oXjQbOkrkNToEXYmPUZOgYBGbxQREZ4NL4bMcZmG=KP2vQQ@mail.gmail.com>
Hi,
On 27-10-16 01:45, Pierre-Hugues Husson wrote:
> Hi,
>
> 2016-10-26 13:46 GMT+02:00 Hans de Goede <hdegoede at redhat.com <mailto:hdegoede@redhat.com>>:
>
>> And as I tried to explain before, for this specific use-case describing
>> all this board specific knowledge in a generic manner in dt is simply
>> impossible, unless we add a turing complete language to dt aka aml.
>
>
> You keep saying this is a "specific use-case", but I don't agree.
> Most of cheap phone and tablets SoC manufacturer's Linux variant that I know of have (rather stupid) auto-detection methods.
True.
> Not every phone manufacturer use it, because some have proper and constant supply chain, but still, that's not always the case.
> For instance you might look at this dts: https://github.com/Dee-UK/RK3288_Lollipop_Kernel/commit/9e056a10b0a773d285e8d2ae819e7c2451816492#diff-b25e1abc92522c85e9ef28704bf9284aR410
> This DTS is meant, like what you do, to be compatible with as many devices as possible at once.
> So it declares 4 different PMICs (and no they will never all be there at the same time), and two different accelerometers, 3 audio codecs, and two touchscreens.
> Or you can look at CodeAurora (Qualcomm public opensource tree) DTSs and see that a standard DTS support at least three different panels ( see https://github.com/omnirom/android_kernel_oppo_msm8974/blob/27080b724f4cf281d598e7830abc5fc1292b5803/arch/arm/boot/dts/msm8974-mtp.dtsi#L15 )
> And that's the fairly clean examples. Some SoC kernels are still using good old platform_data detection methods.
>
> Thus I believe that having a board-specific driver is not a good thing, because we would get many of those.
In my experience with these cheap boards, there is a mix of auto-probing +
device / revision specific os-image modifications. I keep coming back to
the touchscreen controller firmware (but also the orientation), for the
gsl1680 controller I need at least 2 different firmware files (per gsl1680
revision) to make all q8 tablets I have working. This is simply not solved
by the vendor android code, they just shove the right firmware into the
os-image. Likewise for the touchscreen orientation (x-mirored, y-mirored,
etc) too is just a hard-coded setting in the os-image.
Thinking more about this, we may be able to come up with a generic way to
deal with i2c device detection, just like many vendor os-images are doing.
The kernel actually already has a detect() method in struct i2c_driver,
we could use that (we would need to implement it in drivers which do not
have it yet). Note on second thought it seems it may be better to use
probe() for this, see below.
Then we could have something like this in dt:
&i2c0 {
touchscreen1: gsl1680 at 40 {
reg = <0x40>;
compatible = "silead,gsl1680";
enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
status = "disabled";
};
touchscreen2: ektf2127 at 15 {
reg = <0x15>;
compatible = "elan,ektf2127";
enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
status = "disabled";
};
i2c-probe-stop-at-first-match = <&touchscreen1>, <&touchscreen2>;
}
Which would make the i2c subsys call detect (*) on each device, until
a device is found. Likewise we could have a "i2c-probe-all" property
which also walks a list of phandles but does not stop on the first
match.
Mark would something like this scheme work for you ?
Note that things are not this simple though, there are multiple challenges
with this approach:
1) pinctrl, even the detect() method of the driver may need to use
e.g. some gpios so we would need to activate pinctrl as normally the
kernel device core would do this before calling probe(). This is solvable,
but I wonder if we need to mention anything about this in the bindings
docs ? Note this would be solved by just instantiating the client / device
and then try probe().
2) Note the enable-gpios, those will need to be handled in the detect()
method, but this requires a device to be instantiated to call devm_get_...
on, likewise for other resources.
Alternatively the probe code could know about this (as part of the
i2c-probe-stop-at-first-match binding) and enable it before probing ?
3) Optional regulators, I've one q8 tablet where the touchscreen is
powered by a separate regulator, currently my hardware-mgr simply
first tries to probe all possible models with the regulator disabled
(and stops at -ETIMEDOUT which means the i2c bus is stuck and further
probing without enabling the regulator is useless).
How do we deal with this? This is a tricky one do we do this in
the code which walks over the i2c-probe-stop-at-first-match list,
or do we punt this to the driver?
Sofar I've only seen this with one type of touchscreen so an easy cop-out
would be to add an "optional-vddio-supply" to the the bindings for the
specific touchscreen use and put all the necessary logic in the driver.
This does require propagating the learned need for the regulator
from the drivers detect() callback to probe() or alternatively I'm
thinking we should just use probe() instead of detect()to begin with,
that will save a lot of duplication with things
like code for enable gpio-s and regulators.
So assuming we go for the cop-out option for 3. (I'm ok with that),
this would be a pretty clean solution adding just the 2 new:
i2c-probe-stop-at-first-match and i2c-probe-all properties to
the i2c-bus bindings. One problem here is that we may want to have
multiple i2c-probe-stop-at-first-match phandle lists on a single bus
(e.g. try 3 touchscreens + 6 accelerometers on the same bus, stop at
first touchscreen / first accelerometer), anyone have any ideas for
that?
*) Yes this sounds Linux specific, but it really is just "execute to-be-probed
device compatible specific detection method"
> When it comes to detection, I've witnessed various things.
> It can be kernel-side or bootloader-side "global setting" reading (like an ADC/resistor value, or an OTP), it can be bootloader doing the "brute-force", or it can be the kernel doing all the probes.
>
> For instance, as of today, on a Spreadtrum ODM tree, the bootloader will detect the screen by testing all knowns screens, the screen-drivers declare a get_id function, and the bootloader probes until the get_id matches the id declared by the screen driver.
> And then the bootloader tells the kernel, via cmdline, which screen is actually there (but auto-detection is also coded in kernel).
> Finally all possible sensors/touchscreen/camera are declared in DTS, and probe will filter-out N/C ones in the kernel.
>
> Now the big difference between my experience and what Hans is trying to do, is that I've always worked with devices with "safely" queriable IDs, either on i2c or dsi. I've never encountered SPI. This makes probing inherently more dangerous, but I believe the question roughly remains the same.
I'm dealing with i2c too, Mark mistakenly used SPI in his reply,
which I think is what got you thinking I've SPI.
> I understand Mark's will of taking care of this "earlier" (either bootloader or a later kernel-loader (pxa-impedance-matcher)), but I feel like this is only giving the problem to someone else.
Big ack to this, moving this to the bootloader is not solving the
problem, it just moves the problem elsewhere.
> I think that those auto-detection methods should be declared in a device-tree, though as Hans noted, this might end to be a turing-complete language.
See above, I think that we can make this work by delegating the actual
detection to the driver (so each compatible can have a different detect method / code).
So with this we can remove a big part of drivers/misc/q8-hardwaremgr.c, but not all
of it. We still need board specific code somewhere to deal with things like picking
the right touchscreen firmware and touchscreen orientation. This is all somewhat
gsl1680 specific.
I actually have the same problem on x86 where the ACPI description of the device
basically says: "There is a gsl1680 at this bus at this address" and does not say
anything about firmware / orientation (again this is simply hardcoded
in the os-image these devices ship with).
For x86 my plan is to have an array of configs in the driver and select the right
one based on DMI strings, which is in essence putting board specific info in the
driver.
I can imagine mirroring this for ARM, and have an array of configs in the driver
there too (for cases where cannot simply hardcode everything in dt only) and have
some board specific code (activated by of_machine_is_compatible()) to select the
right config.
> In my experience, I have never encountered a device requiring more than ordered probes, but backward compatibility was expected. (i.e. if IDs couldn't help distinguish two devices, the manufacturer would add another way to identify)
>
> As to whether this is bootloader's job or kernel's job, I don't have a really strong opinion.
> On one side, the kernel has all the drivers and probe functions, this would need little work to make this work.
> On the other side, if the "rules" are something like "read bus XXX, address YYY, expect ZZZ", the bootloader can handle it as well. But I don't think it is a good idea to have the bootloader know all the gsensor/screen/camera/... drivers (even if they are partial drivers dedicated to detection only)
Ack I to really believe this belongs in the kernel. Thank you for your reply,
it has made me realized that there are 2 problems here:
1) auto-detect of i2c-devices from a fixed list of i2c devices the board may
have, for this we really need 2 bits: a) generic mechanism to describe this,
call the driver detect methods b) hardware (compatible) specific detection
routines. b) really belongs in the driver, and since things like sensor
drivers (another good example btw) do not belong in the bootloader we
really need this bit in the kernel.
If we can get some consensus on this I'm willing to work on this
(as time allows, this is a spare time project). At least up to feature parity
with my current hard-coded q8-hardwaremgr.c, which in hind-sight indeed is
ugly as the detect code really belongs in the driver (I've been copy and
pasting about 10 - 30 lines from each driver into q8-hardwaremgr.c).
2) miscellaneous extra config on top of figuring out which ICs are connected,
basically the kind of stuff many vendors simply hard-code in their device
specific os-image. This one is much more difficult to deal with and I think
we need to figure this out on a case by case basis. This will require board
specific code (just like the kernel has tons of DMI string activated board
specific code on x86) and what is the best code for this place to live will
be a case by case thing too.
Regards,
Hans
^ permalink raw reply
* [PATCH 1/5] net: phy: broadcom: Add BCM54810 phy entry
From: Andrew Lunn @ 2016-10-27 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-2-git-send-email-jon.mason@broadcom.com>
On Wed, Oct 26, 2016 at 03:35:57PM -0400, Jon Mason wrote:
> From: Vikas Soni <vsoni@broadcom.com>
>
> Add BCM54810 phy entry
Hi Jon, Vikis
The subject line is a bit misleading. It does more than add a PHY ID
entry.
> Signed-off-by: Vikas Soni <vsoni@broadcom.com>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> drivers/net/phy/Kconfig | 2 +-
> drivers/net/phy/broadcom.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/brcmphy.h | 7 +++++
> 3 files changed, 73 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 45f68ea..31967ca 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -217,7 +217,7 @@ config BROADCOM_PHY
> select BCM_NET_PHYLIB
> ---help---
> Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
> - BCM5481 and BCM5482 PHYs.
> + BCM5481, BCM54810 and BCM5482 PHYs.
>
> config CICADA_PHY
> tristate "Cicada PHYs"
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> index 870327e..cdce761 100644
> --- a/drivers/net/phy/broadcom.c
> +++ b/drivers/net/phy/broadcom.c
> @@ -35,6 +35,35 @@ static int bcm54xx_auxctl_write(struct phy_device *phydev, u16 regnum, u16 val)
> return phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum | val);
> }
>
> +static int bcm54810_config(struct phy_device *phydev)
> +{
> + int rc;
> +
> + /* Disable BroadR-Reach */
> + rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL, 0);
> + if (rc < 0)
> + return rc;
> +
> + /* SKEW DISABLE */
> + rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
> + 0xF0E0);
> + if (rc < 0)
> + return rc;
> +
> + /* DELAY DISABLE */
> + rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
> + 0x7000);
This driver mostly uses symbolic names, not #defines. Please can you
use #defines here and else were in this patch.
> + if (rc < 0)
> + return rc;
> +
> + /* DELAY DISABLE */
> + rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, 0);
> + if (rc < 0)
> + return rc;
Twice the same comment?
> +
> + return 0;
> +}
> +
> /* Needs SMDSP clock enabled via bcm54xx_phydsp_config() */
> static int bcm50610_a0_workaround(struct phy_device *phydev)
> {
> @@ -207,6 +236,20 @@ static int bcm54xx_config_init(struct phy_device *phydev)
> (phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
> bcm54xx_adjust_rxrefclk(phydev);
>
> + if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
> + err = bcm54810_config(phydev);
> + if (err)
> + return err;
> +
> + reg = phy_read(phydev, MII_BMCR);
> + if (reg < 0)
> + return reg;
> +
> + err = phy_write(phydev, MII_BMCR, reg & ~BMCR_PDOWN);
> + if (err)
> + return err;
This seems a bit odd. I would expect the PHY core correctly handles
the PHY being powered down. Can you explain this a bit more, why it is
needed.
Thanks
Andrew
^ permalink raw reply
* [PATCH 2/5] Documentation: devicetree: net: add NS2 bindings to amac
From: Andrew Lunn @ 2016-10-27 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-3-git-send-email-jon.mason@broadcom.com>
On Wed, Oct 26, 2016 at 03:35:58PM -0400, Jon Mason wrote:
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> Documentation/devicetree/bindings/net/brcm,amac.txt | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
> index ba5ecc1..f92caee 100644
> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
> @@ -2,15 +2,18 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
> -------------------------------------------------------------
>
> Required properties:
> - - compatible: "brcm,amac" or "brcm,nsp-amac"
> + - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
> - reg: Address and length of the GMAC registers,
> Address and length of the GMAC IDM registers
> + Address and length of the NIC Port Manager registers (optional)
> - reg-names: Names of the registers. Must have both "amac_base" and
> - "idm_base"
> + "idm_base". "nicpm_base" is optional (required for NS2)
> - interrupts: Interrupt number
>
> Optional properties:
> - mac-address: See ethernet.txt file in the same directory
> +- brcm,enet-phy-lane-swap:
> + boolean; Swap the PHY lanes (needed on some SKUs of NS2)
Maybe i'm missing something here, but the patch to the PHY swapped the
lanes. This seems to be a PHY property, not a MAC property. And it
swapped them unconditionally....
Andrew
^ permalink raw reply
* [RFC PATCH 5/5] of: overlay-mgr: add a detector for headers stored on a ds2431 eeprom over w1
From: Matthias Brugger @ 2016-10-27 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026145756.21689-6-antoine.tenart@free-electrons.com>
On 10/26/2016 04:57 PM, Antoine Tenart wrote:
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
Please provide a commit message.
> drivers/of/overlay-manager/Kconfig | 10 ++++++++++
> drivers/w1/slaves/w1_ds2431.c | 39 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 49 insertions(+)
>
> diff --git a/drivers/of/overlay-manager/Kconfig b/drivers/of/overlay-manager/Kconfig
> index 1a36613c0c53..ad0a5b8e9e5e 100644
> --- a/drivers/of/overlay-manager/Kconfig
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -16,4 +16,14 @@ config OF_OVERLAY_MGR_FORMAT_CHIP
>
> endmenu
>
> +menu "Overlay Manager detectors"
> +
> +config OF_OVERLAY_MGR_DETECTOR_DS2431
> + bool "Dip header on a DS2431 EEPROM"
> + depends on W1_SLAVE_DS2431
> + help
> + Enable dip header DS2431 EEPROM support.
> +
> +endmenu
> +
> endif
> diff --git a/drivers/w1/slaves/w1_ds2431.c b/drivers/w1/slaves/w1_ds2431.c
> index 80572cb63ba8..760325f9a2bd 100644
> --- a/drivers/w1/slaves/w1_ds2431.c
> +++ b/drivers/w1/slaves/w1_ds2431.c
> @@ -15,6 +15,9 @@
> #include <linux/device.h>
> #include <linux/types.h>
> #include <linux/delay.h>
> +#include <linux/slab.h>
> +
> +#include <linux/overlay-manager.h>
>
> #include "../w1.h"
> #include "../w1_int.h"
> @@ -280,7 +283,43 @@ static const struct attribute_group *w1_f2d_groups[] = {
> NULL,
> };
>
> +#if IS_ENABLED(CONFIG_OF_OVERLAY_MGR_DETECTOR_DS2431)
> +static int chip_dip_callback(struct w1_slave *sl)
> +{
> + char **candidates = NULL;
> + int i, n, err = 0;
> + u8 *data;
> +
> + data = kzalloc(OVERLAY_MGR_DIP_MAX_SZ, GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + /* sizeof(struct chip_header) is a mulitple of 8 */
> + for (i = 0; i < OVERLAY_MGR_DIP_MAX_SZ; i += 8) {
> + if (w1_f2d_readblock(sl, i, 8, &data[i])) {
> + err = -EIO;
> + goto end;
> + }
> + }
> +
> + overlay_mgr_parse(&sl->dev, data, &candidates, &n);
> + if (!n) {
> + err = -EINVAL;
> + goto end;
> + }
> +
> + err = overlay_mgr_apply(&sl->dev, candidates, n);
> +
> +end:
> + kfree(data);
> + return err;
> +}
> +#endif
> +
> static struct w1_family_ops w1_f2d_fops = {
> +#if IS_ENABLED(CONFIG_OF_OVERLAY_MGR_DETECTOR_DS2431)
> + .callback = chip_dip_callback,
> +#endif
> .groups = w1_f2d_groups,
> };
>
>
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Christoffer Dall @ 2016-10-27 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477323088-18768-1-git-send-email-marc.zyngier@arm.com>
On Mon, Oct 24, 2016 at 04:31:28PM +0100, Marc Zyngier wrote:
> Architecturally, TLBs are private to the (physical) CPU they're
> associated with. But when multiple vcpus from the same VM are
> being multiplexed on the same CPU, the TLBs are not private
> to the vcpus (and are actually shared across the VMID).
>
> Let's consider the following scenario:
>
> - vcpu-0 maps PA to VA
> - vcpu-1 maps PA' to VA
>
> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
> by vcpu-0 accesses, and access the wrong physical page.
>
> The solution to this is to keep a per-VM map of which vcpu ran last
> on each given physical CPU, and invalidate local TLBs when switching
> to a different vcpu from the same VM.
Just making sure I understand this: The reason you cannot rely on the
guest doing the necessary distinction with ASIDs or invalidating the TLB
is that a guest (which assumes it's running on hardware) can validly
defer any neccessary invalidation until it starts running on other
physical CPUs, but we do this transparently in KVM?
Thanks,
-Christoffer
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/include/asm/kvm_host.h | 5 +++++
> arch/arm/include/asm/kvm_hyp.h | 1 +
> arch/arm/kvm/arm.c | 35 ++++++++++++++++++++++++++++++++++-
> arch/arm/kvm/hyp/switch.c | 9 +++++++++
> arch/arm64/include/asm/kvm_host.h | 6 +++++-
> arch/arm64/kvm/hyp/switch.c | 8 ++++++++
> 6 files changed, 62 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 2d19e02..035e744 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -57,6 +57,8 @@ struct kvm_arch {
> /* VTTBR value associated with below pgd and vmid */
> u64 vttbr;
>
> + int __percpu *last_vcpu_ran;
> +
> /* Timer */
> struct arch_timer_kvm timer;
>
> @@ -174,6 +176,9 @@ struct kvm_vcpu_arch {
> /* vcpu power-off state */
> bool power_off;
>
> + /* TLBI required */
> + bool requires_tlbi;
> +
> /* Don't run the guest (internal implementation need) */
> bool pause;
>
> diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
> index 343135e..5850890 100644
> --- a/arch/arm/include/asm/kvm_hyp.h
> +++ b/arch/arm/include/asm/kvm_hyp.h
> @@ -71,6 +71,7 @@
> #define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0)
> #define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0)
> #define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0)
> +#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0)
> #define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4)
> #define PRRR __ACCESS_CP15(c10, 0, c2, 0)
> #define NMRR __ACCESS_CP15(c10, 0, c2, 1)
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 03e9273..09942f0 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -114,11 +114,18 @@ void kvm_arch_check_processor_compat(void *rtn)
> */
> int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> {
> - int ret = 0;
> + int ret, cpu;
>
> if (type)
> return -EINVAL;
>
> + kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
> + if (!kvm->arch.last_vcpu_ran)
> + return -ENOMEM;
> +
> + for_each_possible_cpu(cpu)
> + *per_cpu_ptr(kvm->arch.last_vcpu_ran, cpu) = -1;
> +
> ret = kvm_alloc_stage2_pgd(kvm);
> if (ret)
> goto out_fail_alloc;
> @@ -141,6 +148,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> out_free_stage2_pgd:
> kvm_free_stage2_pgd(kvm);
> out_fail_alloc:
> + free_percpu(kvm->arch.last_vcpu_ran);
> + kvm->arch.last_vcpu_ran = NULL;
> return ret;
> }
>
> @@ -168,6 +177,9 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> {
> int i;
>
> + free_percpu(kvm->arch.last_vcpu_ran);
> + kvm->arch.last_vcpu_ran = NULL;
> +
> for (i = 0; i < KVM_MAX_VCPUS; ++i) {
> if (kvm->vcpus[i]) {
> kvm_arch_vcpu_free(kvm->vcpus[i]);
> @@ -310,6 +322,27 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> +void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu)
> +{
> + int *last_ran;
> +
> + last_ran = per_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran, cpu);
> +
> + /*
> + * If we're very unlucky and get preempted before having ran
> + * this vcpu for real, we'll end-up in a situation where any
> + * vcpu that gets scheduled will perform an invalidation (this
> + * vcpu explicitely requires it, and all the others will have
> + * a different vcpu_id).
> + */
> + if (*last_ran != vcpu->vcpu_id) {
> + if (*last_ran != -1)
> + vcpu->arch.requires_tlbi = true;
> +
> + *last_ran = vcpu->vcpu_id;
> + }
> +}
> +
> void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> {
> vcpu->cpu = cpu;
> diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
> index 92678b7..ab8ee3b 100644
> --- a/arch/arm/kvm/hyp/switch.c
> +++ b/arch/arm/kvm/hyp/switch.c
> @@ -75,6 +75,15 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> {
> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> write_sysreg(kvm->arch.vttbr, VTTBR);
> + if (vcpu->arch.requires_tlbi) {
> + /* Force vttbr to be written */
> + isb();
> + /* Local invalidate only for this VMID */
> + write_sysreg(0, TLBIALL);
> + dsb(nsh);
> + vcpu->arch.requires_tlbi = false;
> + }
> +
> write_sysreg(vcpu->arch.midr, VPIDR);
> }
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index bd94e67..5b42010 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -62,6 +62,8 @@ struct kvm_arch {
> /* VTTBR value associated with above pgd and vmid */
> u64 vttbr;
>
> + int __percpu *last_vcpu_ran;
> +
> /* The maximum number of vCPUs depends on the used GIC model */
> int max_vcpus;
>
> @@ -252,6 +254,9 @@ struct kvm_vcpu_arch {
> /* vcpu power-off state */
> bool power_off;
>
> + /* TLBI required */
> + bool requires_tlbi;
> +
> /* Don't run the guest (internal implementation need) */
> bool pause;
>
> @@ -368,7 +373,6 @@ static inline void __cpu_reset_hyp_mode(unsigned long vector_ptr,
> static inline void kvm_arch_hardware_unsetup(void) {}
> static inline void kvm_arch_sync_events(struct kvm *kvm) {}
> static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> -static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
> static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
>
> void kvm_arm_init_debug(void);
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 83037cd..8d9c3eb 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -131,6 +131,14 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> {
> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> write_sysreg(kvm->arch.vttbr, vttbr_el2);
> + if (vcpu->arch.requires_tlbi) {
> + /* Force vttbr_el2 to be written */
> + isb();
> + /* Local invalidate only for this VMID */
> + asm volatile("tlbi vmalle1" : : );
> + dsb(nsh);
> + vcpu->arch.requires_tlbi = false;
> + }
> }
>
> static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
> --
> 2.1.4
>
^ permalink raw reply
* [RFC PATCH 5/5] of: overlay-mgr: add a detector for headers stored on a ds2431 eeprom over w1
From: Matthias Brugger @ 2016-10-27 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026145756.21689-6-antoine.tenart@free-electrons.com>
On 10/26/2016 04:57 PM, Antoine Tenart wrote:
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
Please provide a commit message.
Thanks,
Matthias
^ permalink raw reply
* [PATCH 01/18] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option
From: Yury Norov @ 2016-10-27 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22426495.JIjM4XpfGo@wuerfel>
On Tue, Oct 25, 2016 at 12:22:47AM +0200, Arnd Bergmann wrote:
> On Monday, October 24, 2016 12:30:47 PM CEST Chris Metcalf wrote:
> > On 10/21/2016 4:33 PM, Yury Norov wrote:
> > > All new 32-bit architectures should have 64-bit off_t type, but existing
> > > architectures has 32-bit ones.
> > >
> > > [...]
> > > For syscalls sys_openat() and sys_open_by_handle_at() force_o_largefile()
> > > is called, to set O_LARGEFILE flag, and this is the only difference
> > > comparing to compat versions. All compat ABIs are already turned to use
> > > 64-bit off_t, except tile. So, compat versions for this syscalls are not
> > > needed anymore. Tile is handled explicitly.
> > >
> > > [...]
> > > --- a/arch/tile/kernel/compat.c
> > > +++ b/arch/tile/kernel/compat.c
> > > @@ -103,6 +103,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned int, offset_high,
> > > #define compat_sys_readahead sys32_readahead
> > > #define sys_llseek compat_sys_llseek
> > >
> > > +#define sys_openat compat_sys_openat
> > > +#define sys_open_by_handle_at compat_sys_open_by_handle_at
> > > +
> > > /* Call the assembly trampolines where necessary. */
> > > #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
> > > #define sys_clone _sys_clone
> >
> > This patch accomplishes two goals that could be completely separated.
> > It's confusing to have them mixed in the same patch without any
> > discussion of why they are in the same patch.
> >
> > First, you want to modify the default <asm/unistd.h> behavior for
> > compat syscalls so that the default is sys_openat (etc) rather than
> > the existing compat_sys_openat, and then use that new behavior for
> > arm64 ILP32. This lets you force O_LARGEFILE for arm64 ILP32 to
> > support having a 64-bit off_t at all times. To do that, you fix the
> > asm-generic header, and then make tile have a special override.
> > This seems reasonable enough.
> >
> > Second, you introduce ARCH_32BIT_OFF_T basically as a synonym for
> > "BITS_PER_WORD == 32", so that new 32-bit architectures can choose not
> > to enable it. This is fine in the abstract, but I'm a bit troubled by
> > the fact that you are not actually introducing a new 32-bit
> > architecture here (just a new 32-bit mode for the arm 64-bit kernel).
> > Shouldn't this part of the change wait until someone actually has a
> > new 32-bit kernel to drive this forward?
>
> I asked for this specifically because we identified the problem
> during the review of the aarch64 ilp32 code, and it might not
> be noticed in the next architecture submission.
>
> The most important aspect from my perspective is that the new
> ilp32 ABI on aarch64 behaves the same way that any native 32-bit
> architecture does, and when we change the default, it should
> be done for both compat mode and native mode at the same time.
>
> > If you want to push forward the ARCH_32BIT_OFF_T change in the absence
> > of an architecture that supports it, I would think it would be a lot
> > less confusing to have these two in separate patches, and make it
> > clear that the ARCH_32BIT_OFF_T change is just laying groundwork
> > for some hypothetical future architecture.
> >
> > The existing commit language itself is also confusing. You write "All
> > compat ABIs are already turned to use 64-bit off_t, except tile."
> > First, I'm not sure what you mean by "turned" here. And, tile is just
> > one of many compat ABIs that allow O_LARGEFILE not to be part of the
> > open call: see arm64's AArch32 ABI, MIPS o32, s390 31-bit emulation,
> > sparc64's 32-bit mode, and of course x86's 32-bit compat mode.
> > Presumably your point here is that tile is the only pre-existing
> > architecture that #includes <asm/unistd.h> to create its compat
> > syscall table, and so I think "all except tile" here is particularly
> > confusing, since there are no architectures except tile that use the
> > __SYSCALL_COMPAT functionality in the current tree.
>
> Agreed, this could be made clearer, and splitting the patch up
> in two also seems reasonable, though I didn't see it as important.
>
> Arnd
In the past it was a separated series of 2 patches, and it was even
acked by Arnd, but not submitted.
http://lists-archives.com/linux-kernel/28471253-32-bit-abi-introduce-arch_32bit_off_t-config-option.html
I can restore that small series in aarch64/ilp32 for next iteration, or resend
it separately if you think to submit it before aarch64/ilp32 (which is
better, for me).
Yury
^ permalink raw reply
* [GIT PULL] ARM: keystone: add TI SCI protocol support for v4.10
From: Tero Kristo @ 2016-10-27 9:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof, Kevin,
This pull introduces the TI SCI protocol support for keystone family of
devices, targeted for v4.10 merge window. We discussed with Santosh
(keystone maintainer) that it would probably be better that I'll be
sending the pull requests for this directly, avoiding one extra step of
merges.
-Tero
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/t-kristo/linux-pm.git for-4.10-ti-sci-base
for you to fetch changes up to 912cffb4ed8612dc99ee0251cc0c9785855162cd:
firmware: ti_sci: Add support for reboot core service (2016-10-27
12:09:12 +0300)
----------------------------------------------------------------
Nishanth Menon (5):
Documentation: Add support for TI System Control Interface
(TI-SCI) protocol
firmware: Add basic support for TI System Control Interface
(TI-SCI) protocol
firmware: ti_sci: Add support for Device control
firmware: ti_sci: Add support for Clock control
firmware: ti_sci: Add support for reboot core service
.../devicetree/bindings/arm/keystone/ti,sci.txt | 81 +
MAINTAINERS | 10 +
drivers/firmware/Kconfig | 15 +
drivers/firmware/Makefile | 1 +
drivers/firmware/ti_sci.c | 1991
++++++++++++++++++++
drivers/firmware/ti_sci.h | 492 +++++
include/linux/soc/ti/ti_sci_protocol.h | 249 +++
7 files changed, 2839 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
create mode 100644 drivers/firmware/ti_sci.c
create mode 100644 drivers/firmware/ti_sci.h
create mode 100644 include/linux/soc/ti/ti_sci_protocol.h
^ permalink raw reply
* [PATCH V4 2/3] ARM64 LPC: Add missing range exception for special ISA
From: zhichang.yuan @ 2016-10-27 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026222542.g4etrqesqb7febid@rob-hp-laptop>
Hi, Rob,
Thanks for your comments!
Please check the response blow.
BTW, Are there any comments from other maintainers/hackers??
Thanks in advance!
On 2016/10/27 6:25, Rob Herring wrote:
> On Thu, Oct 20, 2016 at 05:15:39PM +0800, zhichang.yuan wrote:
>> Currently if the range property is not specified of_translate_one
>> returns an error. There are some special devices that work on a
>> range of I/O ports where it's is not correct to specify a range
>> property as the cpu addresses are used by special accessors.
>> Here we add a new exception in of_translate_one to return
>> the cpu address if the range property is not there. The exception
>> checks if the parent bus is ISA and if the special accessors are
>> defined.
>>
>> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
>> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
>> ---
>> arch/arm64/include/asm/io.h | 7 +++++++
>> arch/arm64/kernel/extio.c | 24 +++++++++++++++++++++++
>> drivers/of/address.c | 47 +++++++++++++++++++++++++++++++++++++++++++--
>> drivers/pci/pci.c | 6 +++---
>> include/linux/of_address.h | 17 ++++++++++++++++
>> 5 files changed, 96 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 136735d..e480199 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -175,6 +175,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>> #define outsl outsl
>>
>> DECLARE_EXTIO(l, u32)
>> +
>> +
>> +#define indirect_io_ison indirect_io_ison
>> +extern int indirect_io_ison(void);
>> +
>> +#define chk_indirect_range chk_indirect_range
>> +extern int chk_indirect_range(u64 taddr);
>> #endif
>>
>>
>> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
>> index 80cafd5..55df8dc 100644
>> --- a/arch/arm64/kernel/extio.c
>> +++ b/arch/arm64/kernel/extio.c
>> @@ -19,6 +19,30 @@
>>
>> struct extio_ops *arm64_extio_ops;
>>
>> +/**
>> + * indirect_io_ison - check whether indirectIO can work well. This function only call
>> + * before the target I/O address was obtained.
>> + *
>> + * Returns 1 when indirectIO can work.
>> + */
>> +int indirect_io_ison()
>> +{
>> + return arm64_extio_ops ? 1 : 0;
>> +}
>> +
>> +/**
>> + * check_indirect_io - check whether the input taddr is for indirectIO.
>> + * @taddr: the io address to be checked.
>> + *
>> + * Returns 1 when taddr is in the range; otherwise return 0.
>> + */
>> +int chk_indirect_range(u64 taddr)
>> +{
>> + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end < taddr)
>> + return 0;
>> +
>> + return 1;
>> +}
>>
>> BUILD_EXTIO(b, u8)
>>
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 02b2903..0bee822 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -479,6 +479,39 @@ static int of_empty_ranges_quirk(struct device_node *np)
>> return false;
>> }
>>
>> +
>> +/*
>> + * Check whether the current device being translating use indirectIO.
>> + *
>> + * return 1 if the check is past, or 0 represents fail checking.
>> + */
>> +static int of_isa_indirect_io(struct device_node *parent,
>
> Make the return bool.
ok. will update it.
>
>> + struct of_bus *bus, __be32 *addr,
>> + int na, u64 *presult)
>> +{
>> + unsigned int flags;
>> + unsigned int rlen;
>> +
>> + /* whether support indirectIO */
>> + if (!indirect_io_ison())
>
> indirect_io_is_enabled() would be a bit more readable.
Ok.
>
>> + return 0;
>> +
>> + if (!of_bus_isa_match(parent))
>> + return 0;
>> +
>> + flags = bus->get_flags(addr);
>> + if (!(flags & IORESOURCE_IO))
>> + return 0;
>> +
>> + /* there is ranges property, apply the normal translation directly. */
>> + if (of_get_property(parent, "ranges", &rlen))
>> + return 0;
>> +
>> + *presult = of_read_number(addr + 1, na - 1);
>> +
>> + return chk_indirect_range(*presult);
>> +}
>> +
>> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>> struct of_bus *pbus, __be32 *addr,
>> int na, int ns, int pna, const char *rprop)
>> @@ -532,7 +565,7 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>> }
>> memcpy(addr, ranges + na, 4 * pna);
>>
>> - finish:
>> +finish:
>
> This hunk is unrelated. Drop it.
Yes. Will drop this change.
>
>> of_dump_addr("parent translation for:", addr, pna);
>> pr_debug("with offset: %llx\n", (unsigned long long)offset);
>>
>> @@ -595,6 +628,15 @@ static u64 __of_translate_address(struct device_node *dev,
>> result = of_read_number(addr, na);
>> break;
>> }
>> + /*
>> + * For indirectIO device which has no ranges property, get
>> + * the address from reg directly.
>> + */
>> + if (of_isa_indirect_io(dev, bus, addr, na, &result)) {
>> + pr_info("isa indirectIO matched(%s)..addr = 0x%llx\n",
>> + of_node_full_name(dev), result);
>
> This should be debugging.
ok. will replace with pr_debug.
thanks!
Zhichang
>
>> + break;
>> + }
>>
>> /* Get new parent bus and counts */
>> pbus = of_match_bus(parent);
>> @@ -688,8 +730,9 @@ static int __of_address_to_resource(struct device_node *dev,
>> if (taddr == OF_BAD_ADDR)
>> return -EINVAL;
>> memset(r, 0, sizeof(struct resource));
>> - if (flags & IORESOURCE_IO) {
>> + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
>> unsigned long port;
>> +
>> port = pci_address_to_pio(taddr);
>> if (port == (unsigned long)-1)
>> return -EINVAL;
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index ba34907..1a08511 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
>>
>> #ifdef PCI_IOBASE
>> struct io_range *range;
>> - resource_size_t allocated_size = 0;
>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>
>> /* check if the range hasn't been previously recorded */
>> spin_lock(&io_range_lock);
>> @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>>
>> #ifdef PCI_IOBASE
>> struct io_range *range;
>> - resource_size_t allocated_size = 0;
>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>
>> if (pio > IO_SPACE_LIMIT)
>> return address;
>> @@ -3335,7 +3335,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
>> {
>> #ifdef PCI_IOBASE
>> struct io_range *res;
>> - resource_size_t offset = 0;
>> + resource_size_t offset = PCIBIOS_MIN_IO;
>> unsigned long addr = -1;
>>
>> spin_lock(&io_range_lock);
>> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>> index 3786473..0ba7e21 100644
>> --- a/include/linux/of_address.h
>> +++ b/include/linux/of_address.h
>> @@ -24,6 +24,23 @@ struct of_pci_range {
>> #define for_each_of_pci_range(parser, range) \
>> for (; of_pci_range_parser_one(parser, range);)
>>
>> +
>> +#ifndef indirect_io_ison
>> +#define indirect_io_ison indirect_io_ison
>> +static inline int indirect_io_ison(void)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> +#ifndef chk_indirect_range
>> +#define chk_indirect_range chk_indirect_range
>> +static inline int chk_indirect_range(u64 taddr)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> /* Translate a DMA address from device space to CPU space */
>> extern u64 of_translate_dma_address(struct device_node *dev,
>> const __be32 *in_addr);
>> --
>> 1.9.1
>>
>
> .
>
^ permalink raw reply
* [PATCH v2 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller
From: Mark Rutland @ 2016-10-27 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026214234.4q6wmecehqh6q32o@rob-hp-laptop>
On Wed, Oct 26, 2016 at 04:42:35PM -0500, Rob Herring wrote:
> On Wed, Oct 19, 2016 at 05:21:13PM +0200, Jerome Brunet wrote:
> >
> > This commit adds the device tree bindings description for Amlogic's GPIO
> > interrupt controller available on the meson8, meson8b and gxbb SoC families
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > ---
> > Rob, I did not include the Ack you gave for the RFC as bindings have slightly
> > changed. Only the interrupt property has be removed following a discussion I
> > had with Marc
>
> As Mark R already said, you should keep the interrupts property.
To be clear, the interrupt routing should be described *somehow*, though
I don't think the generic interrupts property is correct, as this is an
interrupt *router*, i.e. this device doesn't own the interrupt, it just
joins two parts of the line together (and so flags are meaningless).
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 0/4] Add DT support for DA8xx
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
Changes in v2:
* Remove unrelated changes in patch 3
* Rename the device node in patch 4
Changes in v3:
* Fix few mistakes in DT binding sample
* Only build the device table if DT is enabled
Alexandre Bailon (1):
ARM: dts: da850: Add the usb otg device node
Petr Kulhavy (3):
dt/bindings: Add binding for the DA8xx MUSB driver
usb: musb: core: added helper function for parsing DT
usb: musb: da8xx: Add DT support for the DA8xx driver
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++
arch/arm/boot/dts/da850.dtsi | 15 +++++++
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++
drivers/usb/musb/musb_core.c | 19 +++++++++
drivers/usb/musb/musb_core.h | 5 +++
6 files changed, 136 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
--
2.7.3
^ permalink raw reply
* [PATCH v3 1/4] dt/bindings: Add binding for the DA8xx MUSB driver
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477560847-8929-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
new file mode 100644
index 0000000..ccb844a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -0,0 +1,43 @@
+TI DA8xx MUSB
+~~~~~~~~~~~~~
+For DA8xx/OMAP-L1x/AM17xx/AM18xx platforms.
+
+Required properties:
+~~~~~~~~~~~~~~~~~~~~
+ - compatible : Should be set to "ti,da830-musb".
+
+ - reg: Offset and length of the USB controller register set.
+
+ - interrupts: The USB interrupt number.
+
+ - interrupt-names: Should be set to "mc".
+
+ - dr_mode: The USB operation mode. Should be one of "host", "peripheral" or "otg".
+
+ - phys: Phandle for the PHY device
+
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+~~~~~~~~~~~~~~~~~~~~
+ - vbus-supply: Phandle to a regulator providing the USB bus power.
+
+Example:
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <0>;
+ status = "okay";
+ };
+ usb0: usb at 200000 {
+ compatible = "ti,da830-musb";
+ reg = <0x00200000 0x10000>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+
+ dr_mode = "host";
+ vbus-supply = <&usb_vbus>;
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+
+ status = "okay";
+ };
--
2.7.3
^ permalink raw reply related
* [PATCH v3 2/4] usb: musb: core: added helper function for parsing DT
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477560847-8929-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
This adds the function musb_get_mode() to get the DT property "dr_mode"
Signed-off-by: Petr Kulhavy <petr@barix.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Tested-by: David Lechner <david@lechnology.com>
---
drivers/usb/musb/musb_core.c | 19 +++++++++++++++++++
drivers/usb/musb/musb_core.h | 5 +++++
2 files changed, 24 insertions(+)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..bba07e7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include <linux/io.h>
#include <linux/dma-mapping.h>
#include <linux/usb.h>
+#include <linux/usb/of.h>
#include "musb_core.h"
#include "musb_trace.h"
@@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
}
+enum musb_mode musb_get_mode(struct device *dev)
+{
+ enum usb_dr_mode mode;
+
+ mode = usb_get_dr_mode(dev);
+ switch (mode) {
+ case USB_DR_MODE_HOST:
+ return MUSB_HOST;
+ case USB_DR_MODE_PERIPHERAL:
+ return MUSB_PERIPHERAL;
+ case USB_DR_MODE_OTG:
+ case USB_DR_MODE_UNKNOWN:
+ default:
+ return MUSB_OTG;
+ }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
/*-------------------------------------------------------------------------*/
#ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a49..a406468 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -617,4 +617,9 @@ static inline void musb_platform_post_root_reset_end(struct musb *musb)
musb->ops->post_root_reset_end(musb);
}
+/* gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
#endif /* __MUSB_CORE_H__ */
--
2.7.3
^ permalink raw reply related
* [PATCH v3 3/4] usb: musb: da8xx: Add DT support for the DA8xx driver
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477560847-8929-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Tested-by: David Lechner <david@lechnology.com>
---
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 210b7e4..51ae3b6 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
* Based on the DaVinci "glue layer" code.
* Copyright (C) 2005-2006 by Texas Instruments
*
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy <petr@barix.com>
+ *
* This file is part of the Inventra Controller Driver for Linux.
*
* The Inventra Controller Driver for Linux is free software; you
@@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
return 0;
}
+static inline u8 get_vbus_power(struct device *dev)
+{
+ struct regulator *vbus_supply;
+ int current_uA;
+
+ vbus_supply = regulator_get_optional(dev, "vbus");
+ if (IS_ERR(vbus_supply))
+ return 255;
+ current_uA = regulator_get_current_limit(vbus_supply);
+ regulator_put(vbus_supply);
+ if (current_uA <= 0 || current_uA > 510000)
+ return 255;
+ return current_uA / 1000 / 2;
+}
+
static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
.init = da8xx_musb_init,
@@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask = DMA_BIT_MASK(32),
};
+static const struct musb_hdrc_config da8xx_config = {
+ .ram_bits = 10,
+ .num_eps = 5,
+ .multipoint = 1,
+};
+
static int da8xx_probe(struct platform_device *pdev)
{
struct resource musb_resources[2];
@@ -465,6 +489,7 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue *glue;
struct platform_device_info pinfo;
struct clk *clk;
+ struct device_node *np = pdev->dev.of_node;
int ret;
glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
@@ -486,6 +511,16 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev = &pdev->dev;
glue->clk = clk;
+ if (IS_ENABLED(CONFIG_OF) && np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->config = &da8xx_config;
+ pdata->mode = musb_get_mode(&pdev->dev);
+ pdata->power = get_vbus_power(&pdev->dev);
+ }
+
pdata->platform_ops = &da8xx_ops;
glue->usb_phy = usb_phy_generic_register();
@@ -536,11 +571,22 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id da8xx_id_table[] = {
+ {
+ .compatible = "ti,da830-musb",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_id_table);
+#endif
+
static struct platform_driver da8xx_driver = {
.probe = da8xx_probe,
.remove = da8xx_remove,
.driver = {
.name = "musb-da8xx",
+ .of_match_table = of_match_ptr(da8xx_id_table),
},
};
--
2.7.3
^ permalink raw reply related
* [PATCH v3 4/4] ARM: dts: da850: Add the usb otg device node
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477560847-8929-1-git-send-email-abailon@baylibre.com>
This adds the device tree node for the usb otg
controller present in the da850 family of SoC's.
This also enables the otg usb controller for the lcdk board.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..9f5040c 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -158,6 +158,14 @@
rx-num-evt = <32>;
};
+&usb_phy {
+ status = "okay";
+ };
+
+&usb0 {
+ status = "okay";
+};
+
&aemif {
pinctrl-names = "default";
pinctrl-0 = <&nand_pins>;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..322a31a 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -372,6 +372,21 @@
>;
status = "disabled";
};
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+ usb0: usb at 200000 {
+ compatible = "ti,da830-musb";
+ reg = <0x200000 0x10000>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+ status = "disabled";
+ };
gpio: gpio at 226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
2.7.3
^ permalink raw reply related
* [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64
From: Yury Norov @ 2016-10-27 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com>
Hi Chris,
Thank you for comments
On Mon, Oct 24, 2016 at 12:36:27PM -0400, Chris Metcalf wrote:
> On 10/21/2016 4:33 PM, Yury Norov wrote:
> >Based on Andrew Pinski's patch-series.
> >
> >Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> >---
> > Documentation/arm64/ilp32.txt | 46 +++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 46 insertions(+)
> > create mode 100644 Documentation/arm64/ilp32.txt
> >
> >diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt
> >new file mode 100644
> >index 0000000..b96c18f
> >--- /dev/null
> >+++ b/Documentation/arm64/ilp32.txt
> >@@ -0,0 +1,46 @@
> >+ILP32 AARCH64 SYSCALL ABI
> >+=========================
> >+
> >+This document describes the ILP32 syscall ABI and where it differs
> >+from the generic compat linux syscall interface.
> >+
> >+AARCH64/ILP32 userspace can potentially access top halves of registers that
> >+are passed as syscall arguments, so such registers (w0-w7) are deloused.
>
> I'm not sure what "potentially access" here means: I think what you want to say
> is that userspace can pass garbage in the top half, but you should be clearer about
> what you mean here.
Yes. Will change.
> Also, you shouldn't use "deloused" here, since it's not a term
> that's defined elsewhere in the kernel, even though it's been used colloquially on LKML.
> Provide an actual implementation definition, like "have their top 32 bits zeroed".
Agree.
In fact 'delouse' is used in the name of corresponding macro in
include/linux/compat.h:
29 #ifndef __SC_DELOUSE
30 #define __SC_DELOUSE(t,v) ((t)(unsigned long)(v))
31 #endif
But it's not for documentation.
>
> >+AARCH64/ILP32 provides next types turned to 64-bit (comparing to AARCH32):
>
> What does "turned" mean here? And I "next types" isn't standard English; you want
> to say something like "the following types". Likewise later with "next syscalls".
Thanks, will change.
Yury
^ permalink raw reply
* [PATCH v2 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller
From: Jerome Brunet @ 2016-10-27 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027093205.GA27135@leverpostej>
On Thu, 2016-10-27 at 10:32 +0100, Mark Rutland wrote:
> On Wed, Oct 26, 2016 at 04:42:35PM -0500, Rob Herring wrote:
> >
> > On Wed, Oct 19, 2016 at 05:21:13PM +0200, Jerome Brunet wrote:
> > >
> > >
> > > This commit adds the device tree bindings description for
> > > Amlogic's GPIO
> > > interrupt controller available on the meson8, meson8b and gxbb
> > > SoC families
> > >
> > > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > > ---
> > > Rob, I did not include the Ack you gave for the RFC as bindings
> > > have slightly
> > > changed. Only the interrupt property has be removed following a
> > > discussion I
> > > had with Marc
> >
> > As Mark R already said, you should keep the interrupts property.
>
> To be clear, the interrupt routing should be described *somehow*,
> though
> I don't think the generic interrupts property is correct, as this is
> an
> interrupt *router*, i.e. this device doesn't own the interrupt, it
> just
> joins two parts of the line together (and so flags are meaningless).
>
> Thanks,
> Mark.
Indeed Mark,
I already rewritten the driver taking Marc's comment into account.
There will be 2 properties added to the DT:
?-?meson,upstream-interrupts : an array with the 8 gic interrupt used
as output of the controller
- ?meson,num-input-mux : the number of inputs (pads) available to the
muxes
I'm looking for solution to the "create mapping" issue we have in
pinctrl (patch 4) before posting a v3.
If you think these properties should be different, feel free to tell me
now.
Thx
Jerome
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Marc Zyngier @ 2016-10-27 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027091906.GA14734@cbox>
Hi Christoffer,
On 27/10/16 10:19, Christoffer Dall wrote:
> On Mon, Oct 24, 2016 at 04:31:28PM +0100, Marc Zyngier wrote:
>> Architecturally, TLBs are private to the (physical) CPU they're
>> associated with. But when multiple vcpus from the same VM are
>> being multiplexed on the same CPU, the TLBs are not private
>> to the vcpus (and are actually shared across the VMID).
>>
>> Let's consider the following scenario:
>>
>> - vcpu-0 maps PA to VA
>> - vcpu-1 maps PA' to VA
>>
>> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
>> by vcpu-0 accesses, and access the wrong physical page.
>>
>> The solution to this is to keep a per-VM map of which vcpu ran last
>> on each given physical CPU, and invalidate local TLBs when switching
>> to a different vcpu from the same VM.
>
> Just making sure I understand this: The reason you cannot rely on the
> guest doing the necessary distinction with ASIDs or invalidating the TLB
> is that a guest (which assumes it's running on hardware) can validly
> defer any neccessary invalidation until it starts running on other
> physical CPUs, but we do this transparently in KVM?
The guest wouldn't have to do any invalidation at all on real HW,
because the TLBs are strictly private to a physical CPU (only the
invalidation can be broadcast to the Inner Shareable domain). But when
we multiplex two vcpus on the same physical CPU, we break the private
semantics, and a vcpu could hit in the TLB entries populated by the
another one.
As we cannot segregate the TLB entries per vcpu (but only per VMID), the
workaround is to nuke all the TLBs for this VMID (locally only - no
broadcast) each time we find that two vcpus are sharing the same
physical CPU.
Is that clearer?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Christoffer Dall @ 2016-10-27 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7541af85-05c4-25f9-2fa8-2eb7a0afbe84@arm.com>
On Thu, Oct 27, 2016 at 10:49:00AM +0100, Marc Zyngier wrote:
> Hi Christoffer,
>
> On 27/10/16 10:19, Christoffer Dall wrote:
> > On Mon, Oct 24, 2016 at 04:31:28PM +0100, Marc Zyngier wrote:
> >> Architecturally, TLBs are private to the (physical) CPU they're
> >> associated with. But when multiple vcpus from the same VM are
> >> being multiplexed on the same CPU, the TLBs are not private
> >> to the vcpus (and are actually shared across the VMID).
> >>
> >> Let's consider the following scenario:
> >>
> >> - vcpu-0 maps PA to VA
> >> - vcpu-1 maps PA' to VA
> >>
> >> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
> >> by vcpu-0 accesses, and access the wrong physical page.
> >>
> >> The solution to this is to keep a per-VM map of which vcpu ran last
> >> on each given physical CPU, and invalidate local TLBs when switching
> >> to a different vcpu from the same VM.
> >
> > Just making sure I understand this: The reason you cannot rely on the
> > guest doing the necessary distinction with ASIDs or invalidating the TLB
> > is that a guest (which assumes it's running on hardware) can validly
> > defer any neccessary invalidation until it starts running on other
> > physical CPUs, but we do this transparently in KVM?
>
> The guest wouldn't have to do any invalidation at all on real HW,
> because the TLBs are strictly private to a physical CPU (only the
> invalidation can be broadcast to the Inner Shareable domain). But when
> we multiplex two vcpus on the same physical CPU, we break the private
> semantics, and a vcpu could hit in the TLB entries populated by the
> another one.
Such a guest would be using a mapping of the same VA with the same ASID
on two separate CPUs, each pointing to a separate PA. If it ever were
to, say, migrate a task, it would have to do invalidations then. Right?
Does Linux or other guests actually do this?
I would suspect Linux has to eventually invalidate those mappins if it
wants the scheduler to be allowed to freely move things around.
>
> As we cannot segregate the TLB entries per vcpu (but only per VMID), the
> workaround is to nuke all the TLBs for this VMID (locally only - no
> broadcast) each time we find that two vcpus are sharing the same
> physical CPU.
>
> Is that clearer?
Yes, the fix is clear, just want to make sure I understand that it's a
valid circumstance where this actually happens. But in either case, we
probably have to fix this to emulate the hardware correctly.
Another fix would be to allocate a VMID per VCPU I suppose, just to
introduce a terrible TLB hit ratio :)
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: Sekhar Nori @ 2016-10-27 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1593441f-d147-4c91-8aab-8622dd8ced19@lechnology.com>
On Monday 24 October 2016 09:20 PM, David Lechner wrote:
> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>
>> Thanks for the patch!
>>
>>>
>>> What is working:
>>>
>>> * Pin muxing
>>> * MicroSD card reader
>>> * UART on input port 1
>>>
>>> What is partially working:
>>>
>>> * Buttons - working after GPIO fix
>>> * LEDs - working after GPIO fix
>>> * Poweroff/reset - working after GPIO fix
>>
>> Is the GPIO fix something that will go in v4.9-rc cycle ?
>
> Not sure. This is still being discussed.
>
> http://www.gossamer-threads.com/lists/linux/kernel/2550178
>
>>
>>> * Flash memory - driver loads but can't read the block devices - this is
>>> probably due to the fact that we are not able to configure the SPI to
>>> use DMA via device tree
>>
>> Hmm, I would not have expected PIO mode to be so inefficient that you
>> are unable to even read the block device.
>
> I am getting a -EIO error. I haven't been able to trace down exactly
> what is causing it yet though.
Okay. Seems unrelated to DMA though. Will check the status of SPI on my
DA850 EVM once I get the chance.
>
>>
> ...
>>> +/ {
>>> + compatible = "lego,ev3", "ti,da850";
>>> + model = "LEGO MINDSTORMS EV3";
>>> +
>>> + soc at 1c00000 {
>>> + /*
>>> + * (ab)using pinctrl-single to disable all internal pullups/
>>> + * pulldowns on I/O.
>>> + */
>>> + pinmux at 22c00c {
>>> + compatible = "pinctrl-single";
>>> + reg = <0x22c00c 0x4>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + pinctrl-single,bit-per-mux;
>>> + pinctrl-single,register-width = <32>;
>>> + pinctrl-single,function-mask = <0xf>;
>>> + /*
>>> + * There is a bug in pinctrl-single that prevents us
>>> + * from setting function-mask to 1, so doing things
>>> + * in groups of 4. Doesn't really matter since we are
>>> + * disabling all at once anyway.
>>> + */
>>> +
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pupu_disable>;
>>> +
>>> + pupu_disable: pinmux_all_pins {
>>> + pinctrl-single,bits = <
>>> + 0x0 0x00000000 0xffffffff
>>> + >;
>>> + };
>>
>> Sigh. This is quite an abuse :)
>>
>> I know we don't have a good way to configure this in kernel today. And I
>> am surprised we never had to care about disabling pullups so far. Can
>> you clarify why you need it? I assume there is some contention you want
>> to avoid, but on which interface?
>
> The EV3 was designed with external pullup/pulldown everywhere. I know
> for certain that it breaks one of the buttons if you do not disable the
> internal ones. I imagine that it would have subtle effects elsewhere if
> they are not disabled.
>
> I have not gone through each pullup/pulldown bank individually, but it
> would not surprise me at all if there was at least one thing on most of
> them that would be adversely affected.
>
>>
>> I dont think this can be done this way using pinctrl-single. A small
>> driver to handle pullup/down control for da850 may have to be added to
>> drivers/pinctrl. It will be better to check with Linus Walleij on his
>> thoughts using a new thread ccing the pinctrl subsystem list as well.
>
> I will be glad to try to make a driver, but when I ran into this problem
> I could not find much information on how to handle banks of
> pullup/pulldown. Most of what I saw was for ones that can be
> individually controlled. If anyone knows something like this already
> that I could look at, it would be helpful to me.
pinctrl-single supports a different compatible "pinconf-single" which
supports the pinconf interface that can be used to set pullup and
pulldown bias.
Unfortunately, in case of AM18x, there are two registers to touch:
PUPD_ENA and PUPD_SEL. So I believe the pinctrl-single driver cannot be
used.
There are pinconf operations pin_config_group_{set|get}(). Based on
documentation these are meant to act on a group of pins. There are quite
a few drivers implementing this interface. Perhaps they can be used as
an example.
Also, this needs to be done in a way that can be used by other boards
too, so please move the common properties to da850.dtsi. Only the board
specific pullup/down configuration should be in this file.
>
>
>> [...]
>>
>>> + in1_pins: pinmux_in1_pins {
>>> + pinctrl-single,bits = <
>>> + /* GP0[15] */
>>> + 0x0 0x00000008 0x0000000f
>>> + /* GP0[2] */
>>> + 0x4 0x00800000 0x00f00000
>>> + /* GP2[2] */
>>> + 0x18 0x00800000 0x00f00000
>>> + /* GP8[10], GP8[11] */
>>> + 0x48 0x88000000 0xff000000
>>> + >;
>>> + };
>>
>> I see that this is not really used. Can you add these when you actually
>> use them. Looks like that applies to some other definitions like this
>> below.
>
> It will be possible to uses these gpios via sysfs (until a proper driver
> for input and output ports is merged). So how about I attach these to
> the gpio node for now?
pins are usually attached to the node that consumes the GPIO pins, not
to the gpio node itself.
If the pins are not connected to anything and can be used via gpio
sysfs, then "pinctrl hog" or "board level pinmux" is to be used.
Something like below:
+&pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <&in1_pins>;
+
+ in1_pins: pinmux_in1_pins {
+ pinctrl-single,bits = <
+ 0x0 0x00000008 0x0000000f
+ ...
+ >;
+ };
+};
That said, device tree is supposed to describe hardware and not change
depend on current driver support. So I would wait for the driver to get
merged before merging the pins that are used by it. It looks like you
wont be able to use the support in a meaningful way till then anyway.
>
>>
>>> +&ehrpwm1 {
>>> + status = "disabled";
>>
>> Hmm, disabled? Can you add this node when you actually use it?
>
> Not sure why I have this disabled. Like the gpios, the pwms can be used
> via sysfs, so I would like to leave them.
Okay, then please keep the node enabled.
>
>>
>>> + pinctrl-names = "default";
>>> + /* MBPWM, MAPWM */
>>> + pinctrl-0 = <&ehrpwm1a_pins>, <&ehrpwm1b_pins>;
>>> +};
>>> +
>>> +&ecap1 {
>>> + status = "disabled";
>>
>> same here and other places below.
>>
>>> + pinctrl-names = "default";
>>> + /* MDPWM */
>>> + pinctrl-0 = <&ecap1_pins>;
>>> +};
>>> +
>>> +&spi0 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>>> + dmas = <&edma0 14 0>, <&edma0 15 0>;
>>> + dma-names = "rx", "tx";
>>> +
>>> + spi-flash at 0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "n25q128a13", "jedec,spi-nor";
>>> + reg = <0>;
>>> + spi-max-frequency = <50000000>;
>>> + ti,spi-wdelay = <8>;
>>> +
>>> + partition at 0 {
>>> + label = "U-Boot";
>>> + reg = <0 0x40000>;
>>
>> Thats 256KB for U-Boot and MLO (I assume in concatenated AIS image). Is
>> that sufficient for future too? Moving partitions later is tough ask
>> because that means users will lose data when they upgrade the kernel
>> because of partitions moving around. Just a suggestion to keep future
>> U-Boot bloat in mind and not use a "just fits" number.
>
> The MLO is on an EEPROM in the EV3, so the U-Boot partition is just
> U-boot. The SoC boots from I2C, which then runs whatever is as 0x0 on
> the flash memory.
okay.
> This partition table matches the partition scheme used on the official
> LEGO firmware that ships with the devices. Most people running their own
> kernel will probably be loading it from a microSD card, leaving the
> official firmware intact and therefore will always have this partition
> table.
>
> My thinking is that if someone does want to use a different partitioning
> scheme, they can build their own U-Boot and configure it to modify the
> device tree with a new partition table.
>
> The way the LEGO firmware flashing utility works, it wipes out the
> entire flash memory each time you flash the firmware. So, data loss is
> not a concern - you will loose your data anyway.
Alright, thanks for the detailed explanation.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
From: Simon Horman @ 2016-10-27 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoTizLGYSgY-EV_DwC+yeqeuAsuBKPwXXW6zqwqpHM3MfA@mail.gmail.com>
On Thu, Oct 27, 2016 at 04:37:53PM +0900, Magnus Damm wrote:
> Hi Simon,
>
> On Thu, Oct 27, 2016 at 4:15 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Oct 27, 2016 at 09:08:01AM +0200, Simon Horman wrote:
> >> On Wed, Oct 26, 2016 at 02:24:22PM +0900, Magnus Damm wrote:
> >> > From: Magnus Damm <damm+renesas@opensource.se>
> >> >
> >> > Extend the ARM64 defconfig to enable the DU DRM device as module
> >> > together with required dependencies of V4L2 FCP and VSP modules.
> >> >
> >> > This enables VGA output on the r8a7795 Salvator-X board.
> >> >
> >> > Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> >>
> >> Thanks, I have queued this up.
> >
> > Given discussion elsewhere on enabling DU I am holding off on this for a
> > little; it is not queued up for now.
>
> Sure, thanks for holding off the DT integration patches for r8a7796.
> Please note that as of mainline v4.9-rc2 the r8a7795 Salvator-X board
> has thanks to DU, FCP and VSP a working VGA port. So enabling those
> devices in the defconfig from now on makes sense to me.
Understood, I will queue up this patch.
^ permalink raw reply
* [PATCH v6 00/16] ACPI IORT ARM SMMU support
From: Rafael J. Wysocki @ 2016-10-27 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026110459.GA15276@red-moon>
On Wed, Oct 26, 2016 at 1:04 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> Rafael, Joerg (and anyone else CC'ed),
>
> On Tue, Oct 18, 2016 at 05:03:58PM +0100, Lorenzo Pieralisi wrote:
>> This patch series is v6 of a previous posting:
>>
>> https://lkml.org/lkml/2016/9/9/418
>>
>> v5 -> v6
>> - Rebased against v4.9-rc1
>> - Changed FWNODE_IOMMU to FWNODE_ACPI_STATIC
>> - Moved platform devices creation into IORT code
>> - Updated fwnode handling
>> - Added default dma masks initialization
>
> Any comments on v6 ? Patches touching generic ACPI code
> are {1, 2, 7}, patch 4 updates the IOMMU of_iommu_{set/get}_ops()
> API to make it work on ACPI systems too, by replacing the
> device_node with a fwnode_handle pointer as look-up token;
> the remainder of patches are ARM specific and creates the
> infrastructure to probe ARM SMMU devices through ACPI,
> ARM IORT table in particular. Given the generic bits changes
> above I would not leave it to late -rc to reach an agreement
> please, thank you.
I'll do my best to look at these in the next few days, but please also
note what I wrote before:
http://marc.info/?l=linux-acpi&m=147744344531599&w=2
Thanks,
Rafael
^ permalink raw reply
* [PATCH v2 2/4] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Marc Zyngier @ 2016-10-27 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477553651-13428-2-git-send-email-dingtianhong@huawei.com>
On 27/10/16 08:34, Ding Tianhong wrote:
> The workaround for hisilicon,161601 will check the return value of the system counter
> by different way, in order to distinguish with the fsl-a008585 workaround, introduce
> a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
>
> v2: Introducing a new generic erratum handling mechanism for fsl erratum a008585.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> arch/arm64/include/asm/arch_timer.h | 20 +++++++++-----
> drivers/clocksource/arm_arch_timer.c | 51 +++++++++++++++++++++---------------
> 2 files changed, 43 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index eaa5bbe..118719d8 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -31,15 +31,21 @@
>
> #if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
> extern struct static_key_false arch_timer_read_ool_enabled;
> -#define needs_fsl_a008585_workaround() \
> +#define needs_timer_erratum_workaround() \
> static_branch_unlikely(&arch_timer_read_ool_enabled)
This is too generic a name. Please make it more specific.
> #else
> -#define needs_fsl_a008585_workaround() false
> +#define needs_timer_erratum_workaround() false
> #endif
>
> -u32 __fsl_a008585_read_cntp_tval_el0(void);
> -u32 __fsl_a008585_read_cntv_tval_el0(void);
> -u64 __fsl_a008585_read_cntvct_el0(void);
> +
> +struct arch_timer_erratum_workaround {
> + int erratum;
What is the use of this field?
> + u32 (*read_cntp_tval_el0)(void);
> + u32 (*read_cntv_tval_el0)(void);
> + u64 (*read_cntvct_el0)(void);
> +};
> +
> +extern struct arch_timer_erratum_workaround *erratum_workaround;
This is a very generic name for something that has a global visibility.
Please choose a more specific variable name.
>
> /*
> * The number of retries is an arbitrary value well beyond the highest number
> @@ -62,8 +68,8 @@ u64 __fsl_a008585_read_cntvct_el0(void);
> #define arch_timer_reg_read_stable(reg) \
> ({ \
> u64 _val; \
> - if (needs_fsl_a008585_workaround()) \
> - _val = __fsl_a008585_read_##reg(); \
> + if (needs_timer_erratum_workaround()) \
> + _val = erratum_workaround->read_##reg(); \
As mentioned in my initial review, you've now broken modular access to
any of the registers. Please fix it.
> else \
> _val = read_sysreg(reg); \
> _val; \
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 73c487d..e4f7fa1 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -95,10 +95,32 @@ early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg);
> */
>
> #ifdef CONFIG_FSL_ERRATUM_A008585
> +struct arch_timer_erratum_workaround *erratum_workaround = NULL;
> +
> DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
> EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
>
> -static int fsl_a008585_enable = -1;
> +
> +static u32 fsl_a008585_read_cntp_tval_el0(void)
> +{
> + return __fsl_a008585_read_reg(cntp_tval_el0);
> +}
> +
> +static u32 fsl_a008585_read_cntv_tval_el0(void)
> +{
> + return __fsl_a008585_read_reg(cntv_tval_el0);
> +}
> +
> +static u64 fsl_a008585_read_cntvct_el0(void)
> +{
> + return __fsl_a008585_read_reg(cntvct_el0);
> +}
So now that you've indirected all calls through a set of pointers, why
do you keep the __fsl_a008585_read_reg() macro inside the include file?
I don't think it has any purpose in being globally visible now.
> +
> +static struct arch_timer_erratum_workaround arch_timer_fsl_a008585 = {
And here's the proof that the erratum field is useless.
> + .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
> + .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
> + .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
> +};
>
> static int __init early_fsl_a008585_cfg(char *buf)
> {
> @@ -109,26 +131,12 @@ static int __init early_fsl_a008585_cfg(char *buf)
> if (ret)
> return ret;
>
> - fsl_a008585_enable = val;
> + if (val)
> + erratum_workaround = &arch_timer_fsl_a008585;
> +
> return 0;
> }
> early_param("clocksource.arm_arch_timer.fsl-a008585", early_fsl_a008585_cfg);
> -
> -u32 __fsl_a008585_read_cntp_tval_el0(void)
> -{
> - return __fsl_a008585_read_reg(cntp_tval_el0);
> -}
> -
> -u32 __fsl_a008585_read_cntv_tval_el0(void)
> -{
> - return __fsl_a008585_read_reg(cntv_tval_el0);
> -}
> -
> -u64 __fsl_a008585_read_cntvct_el0(void)
> -{
> - return __fsl_a008585_read_reg(cntvct_el0);
> -}
> -EXPORT_SYMBOL(__fsl_a008585_read_cntvct_el0);
> #endif /* CONFIG_FSL_ERRATUM_A008585 */
>
> static __always_inline
> @@ -891,9 +899,10 @@ static int __init arch_timer_of_init(struct device_node *np)
> arch_timer_c3stop = !of_property_read_bool(np, "always-on");
>
> #ifdef CONFIG_FSL_ERRATUM_A008585
> - if (fsl_a008585_enable < 0)
> - fsl_a008585_enable = of_property_read_bool(np, "fsl,erratum-a008585");
> - if (fsl_a008585_enable) {
> + if (!erratum_workaround && of_property_read_bool(np, "fsl,erratum-a008585"))
> + erratum_workaround = &arch_timer_fsl_a008585;
It used to be possible to disable the erratum workaround on the command
line, and you've just removed that feature. Please restore it.
> +
> + if (erratum_workaround) {
> static_branch_enable(&arch_timer_read_ool_enabled);
> pr_info("Enabling workaround for FSL erratum A-008585\n");
> }
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ 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