* [PATCH] ARM: integrator: restore static map on the CP
From: Kevin Hilman @ 2014-01-31 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390568668-32270-1-git-send-email-linus.walleij@linaro.org>
Linus Walleij <linus.walleij@linaro.org> writes:
> Commit 78d1632183454dba46ca8295484a5e7603acdc18 deleted the
> static mappings of the core modules, but this static map is
> still needed on the Integrator/CP (not the Integrator/AP).
>
> Restore the static map on the Integrator/CP.
>
> Reported-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ARM SoC folks: please apply this fix directly to ARM SoC
> if you're OK with it.
Queuing for fixes.
Kevin
^ permalink raw reply
* [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Kevin Hilman @ 2014-01-31 5:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131022954.GB8163@saruman.home>
On Thu, Jan 30, 2014 at 6:29 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Thu, Jan 30, 2014 at 03:52:16PM -0800, Kevin Hilman wrote:
>> On Wed, Jan 29, 2014 at 5:32 AM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > On Wed, Jan 29, 2014 at 12:25:20PM +0000, Mark Brown wrote:
>> >> On Wed, Jan 29, 2014 at 12:10:48PM +0100, Maxime Ripard wrote:
>> >>
>> >> > +config SPI_SUN6I
>> >> > + tristate "Allwinner A31 SPI controller"
>> >> > + depends on ARCH_SUNXI || COMPILE_TEST
>> >> > + select PM_RUNTIME
>> >> > + help
>> >> > + This enables using the SPI controller on the Allwinner A31 SoCs.
>> >> > +
>> >>
>> >> A select of PM_RUNTIME is both surprising and odd - why is that there?
>> >> The usual idiom is that the device starts out powered up (flagged using
>> >> pm_runtime_set_active()) and then runtime PM then suspends it when it's
>> >> compiled in. That way if for some reason people want to avoid runtime
>> >> PM they can still use the device.
>> >
>> > Since pm_runtime_set_active and all the pm_runtime* callbacks in
>> > general are defined to pretty much empty functions, how the
>> > suspend/resume callbacks are called then? Obviously, we need them to
>> > be run, hence why I added the select here, but now I'm seeing a
>> > construct like what's following acceptable then?
>>
>> Even with your 'select', The runtime PM callbacks will never be called
>> in the current driver. pm_runtime_enable() doesn't do any runtime PM
>> transitions. It just allows transitions to happen when they're
>> triggered by _get()/_put()/etc.
>>
>> > pm_runtime_enable(&pdev->dev);
>> > if (!pm_runtime_enabled(&pdev->dev))
>> > sun6i_spi_runtime_resume(&pdev->dev);
>>
>> Similarily here, it's not the pm_runtime_enable that will fail when
>> runtime PM is disabled (or not built-in), it's a pm_runtime_get_sync()
>> that will fail.
>>
>> What you want is something like this in ->probe()
>>
>> sun6i_spi_runtime_resume();
>> /* now, device is always activated whether or not runtime PM is enabled */
>> pm_runtime_enable();
>> pm_runtime_set_active(); /* tells runtime PM core device is
>> already active */
>
> shouldn't this be done before pm_runtime_enable() ?
hmm, possibly yes. I was doing this from the top of my head without
looking to closely at the code.
>> pm_runtime_get_sync();
>>
>> This 'get' will increase the usecount, but not actually call the
>> callbacks because we told the RPM core that the device was already
>> activated with _set_active().
>>
>> And then, in ->remove(), you'll want
>>
>> pm_runtime_put();
>
> in ->remove() you actually want a put_sync() right ? You don't want to
> schedule anything since you're just about to disable pm_runtime.
Yes, you're correct.
Thanks for the corrections.
Kevin
^ permalink raw reply
* recommended action for bootloaders regarding modifying device-tree nodes
From: Tim Harvey @ 2014-01-31 4:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130211512.GD13372@obsidianresearch.com>
On Thu, Jan 30, 2014 at 1:15 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
>
> On Thu, Jan 30, 2014 at 03:45:58PM -0500, Jason Cooper wrote:
>
> > This is more of a process question: Is there any information captured
> > in your EEPROM that can't be represented in the dtb? iow, at the point
> > when you write the EEPROM, why not write the dtb to it as configured?
>
> I can share what we do here.. In our systems the serial EEPROM is only
> 256 bytes, so storing things in DT format would be challenging.
>
> What we do is have a master DTB that has the union of all our
> configurations. The boot process has a very simple bit of code that
> runs down the DTB in binary format and replaces entire
> OF_DT_BEGIN_NODE->OF_DT_END_NODE regions with OF_DT_NOP.
>
> The NOP approach is very simple, no other changes (eg offset
> recalculation) needs to be done to the DT, so we can do this process
> with a very small code footprint and without libfdt.
>
> Choosing which sections to drop is done with some combination of
> hardwired code and searching for specific property patterns. There are
> also a few places where placeholder sections are directly fixed up, eg
> a mac address is written into a placeholder of 0s, etc.
>
> So an example might be
>
> optional_peripheral at 10000 {
> orc,board-style = <1>;
> [..]
> }
>
> Eg The board-style number comes from the EEPROM and if board-style !=
> 1 then the entire stanza is replaced with NOP.
>
> Jason
Jason,
Sounds pretty much like what we are doing. I am using u-boot and my
current code looks like this:
/*
* Peripheral Config:
* remove nodes by alias path if EEPROM config tells us the
* peripheral is not loaded on the board.
*/
if (!test_bit(EECONFIG_ETH0, info->config))
fdt_del_node_and_alias(blob, "ethernet0");
if (!test_bit(EECONFIG_ETH1, info->config))
fdt_del_node_and_alias(blob, "ethernet1");
if (!test_bit(EECONFIG_HDMI_OUT, info->config))
fdt_del_node_and_alias(blob, "hdmi_out");
if (!test_bit(EECONFIG_SATA, info->config))
fdt_del_node_and_alias(blob, "ahci0");
if (!test_bit(EECONFIG_PCIE, info->config))
fdt_del_node_and_alias(blob, "pcie");
if (!test_bit(EECONFIG_SSI0, info->config))
fdt_del_node_and_alias(blob, "ssi0");
if (!test_bit(EECONFIG_SSI1, info->config))
fdt_del_node_and_alias(blob, "ssi1");
...
I've submitted my code to u-boot and have been asked if its more
appropriate to remove nodes as I'm doing above or to mark them as
'disabled'. From what I can tell there really isn't a rule or
recommendation for this so I think I'll keep doing what I'm doing
above.
Thanks!
Tim
^ permalink raw reply
* recommended action for bootloaders regarding modifying device-tree nodes
From: Tim Harvey @ 2014-01-31 4:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130204558.GC29184@titan.lakedaemon.net>
On Thu, Jan 30, 2014 at 12:45 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> Hi Tim,
>
> On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote:
>> My approach has been to define a per-baseboard device-tree in Linux
>> for a 'fully loaded' board, then remove nodes which the EEPROM claims
>> are not present in the bootloader before it passes the DTB to the
>> kernel. I do this by defining aliases in the device-tree for the
>> peripherals that are 'optional' so that the bootloader itself does not
>> need to know the details about how the device is connected.
>
> This is more of a process question: Is there any information captured
> in your EEPROM that can't be represented in the dtb? iow, at the point
> when you write the EEPROM, why not write the dtb to it as configured?
>
> You could have pre-configured dtsi fragments for each config option, and
> then dynamically create the board dts from the order.
>
> I only ask because it would solve the problem below. However, there's a
> lot more to changing a manufacturing process than meets the eye. :)
>
our eeprom config section is only 40 bytes. It contains a SKU string,
mac addrs, and some bitwise fields for the various optional components
that we can subload.
>> Is it more appropriate for the bootloader to 'remove' nodes for
>> devices that are not physically present or should I be setting their
>> status property to 'disabled' instead? I'm not clear if either option
>> really has any pros or cons.
>
> That depends on how you have it structured. Is it a valid dtb?
> Meaning, do you have four nodes all at the same register address?
> Perhaps you could provide an example dts?
yes its a valid dtb - it is just the superset of everything the
baseboard (ie schematic design) can support.
A good example is a custom SKU of a baseboard with ethernet subloaded.
If the EEPROM says there is no ethernet mac or phy, I would want to
remove or disable the ethernet node from the devicetree.
Another example would be a node for 'gpio-pps' (GPIO based
pulse-per-second) support. A baseboard design that has a GPS with its
PPS signal tied to a GPIO would define this in the device-tree, but if
the EEPROM says the GPS isn't loaded, I would want to remove or
disable the gps-pps node.
Tim
>
> thx,
>
> Jason.
>
>> Tim Harvey - Principal Software Engineer
>> Gateworks Corporation
>
> btw - one of my first embedded projects was on one of your boards. An
> ixp425 with 4 mini-pci slots.
>
^ permalink raw reply
* [PATCH V3 6/8] SPEAr13xx: Fixup: Move SPEAr1340 SATA platform code to phy driver
From: Pratyush Anand @ 2014-01-31 4:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401301421.00990.arnd@arndb.de>
On Thu, Jan 30, 2014 at 09:21:00PM +0800, Arnd Bergmann wrote:
> On Thursday 30 January 2014, Mohit Kumar wrote:
> >
> > diff --git a/Documentation/devicetree/bindings/phy/spear13xx-miphy.txt b/Documentation/devicetree/bindings/phy/spear13xx-miphy.txt
> > new file mode 100644
> > index 0000000..208b37d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/spear13xx-miphy.txt
> > @@ -0,0 +1,8 @@
> > +Required properties:
> > +- compatible : should be "st,spear1340-sata-pcie-phy".
>
> Just for confirmation: This phy is by design only capable of driving
> sata or pcie, but nothing else if reused in a different SoC, right?
>
> If the phy is actually more generic than that, I'd suggest changing
> the name, otherwise it's ok.
OK, we will give a generic name as it can be used for sata/pcie/usb3.0.
Although, phy register definition may vary from version to version,
but that can be managed,as and when support of new soc is added.
>
> > +- reg : offset and length of the PHY register set.
> > +- misc: phandle for the syscon node to access misc registers
> > +- #phy-cells : from the generic PHY bindings, must be 2.
> > + - 1st arg: phandle to the phy node.
> > + - 2nd arg: 0 if phy (in 1st arg) is to be used for sata else 1.
> > + - 3rd arg: Instance id of the phy (in 1st arg).
>
> I would count "arg" differently: There are three cells, and the first
> cell is the phandle, while the second and third cells contain the first
> and second argument.
Ok..will modify accordingly.
>
> The third cell seems redundant, more on that below.
>
> > + ahci0: ahci at b1000000 {
> > compatible = "snps,spear-ahci";
> > reg = <0xb1000000 0x10000>;
> > interrupts = <0 68 0x4>;
> > + phys = <&miphy0 0 0>;
> > + phy-names = "ahci-phy";
> > status = "disabled";
> > };
> >
> > - ahci at b1800000 {
> > + ahci1: ahci at b1800000 {
> > compatible = "snps,spear-ahci";
> > reg = <0xb1800000 0x10000>;
> > interrupts = <0 69 0x4>;
> > + phys = <&miphy1 0 1>;
> > + phy-names = "ahci-phy";
> > status = "disabled";
> > };
> >
> > - ahci at b4000000 {
> > + ahci2: ahci at b4000000 {
> > compatible = "snps,spear-ahci";
> > reg = <0xb4000000 0x10000>;
> > interrupts = <0 70 0x4>;
> > + phys = <&miphy2 0 2>;
> > + phy-names = "ahci-phy";
> > status = "disabled";
> > };
>
> In each case, the number of the phy 'miphyX' is identical to the
> third cell, and I suspect this is by design. In the driver, the
> 'id' field is set in the xlate function, but I could not find any
> place where it actually gets used, so unless you know that it's
> needed, I'd suggest simply removing it.
It has not been used in this patch, as SATA support is currently only
for SPEAr1340, where we have only one instance.
Will be using it in PCIe for SPEAr1310 where 3 instances are present.
>
> Even if you need it, it may be better to have the instance encoded
> in the phy node itself, since it's a property of the phy hardware
> (e.g. if you have to pass the number into a generic register that
> is global to all phys.
Ok..ll do that.
>
> Alternatively, you could have a different representation, where you
> have a single DT device node representing all three PHYs, with
> "reg = <0xeb800000 0xc000>;" In that case, all sata devices would
> point to the same phy node and pass the instance id so the phy
> driver can operated the correct register set.
Instance ID is mainly needed to manipulate wrapper register present
within SPEAr13xx misc space. We have a single register in misc space
having bit fields controlling all 3 phys, and there we need this id.
>
> > +static int spear1340_sata_miphy_init(struct spear13xx_phy_priv *phypriv)
> > +{
> > + regmap_update_bits(phypriv->misc, SPEAR1340_PCIE_SATA_CFG,
> > + SPEAR1340_PCIE_SATA_CFG_MASK, SPEAR1340_SATA_CFG_VAL);
> > + regmap_update_bits(phypriv->misc, SPEAR1340_PCIE_MIPHY_CFG,
> > + SPEAR1340_PCIE_MIPHY_CFG_MASK,
> > + SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA_25M_CRYSTAL_CLK);
> > + /* Switch on sata power domain */
> > + regmap_update_bits(phypriv->misc, SPEAR1340_PCM_CFG,
> > + SPEAR1340_PCM_CFG_SATA_POWER_EN,
> > + SPEAR1340_PCM_CFG_SATA_POWER_EN);
> > + msleep(20);
> > + /* Disable PCIE SATA Controller reset */
> > + regmap_update_bits(phypriv->misc, SPEAR1340_PERIP1_SW_RST,
> > + SPEAR1340_PERIP1_SW_RST_SATA, 0);
> > + msleep(20);
> > +
> > + return 0;
> > +}
>
> I guess some of the parts above can eventually get moved into other
> drivers (reset controller, power domains) that get called directly
> by the SATA driver (e.g. though reset_device()). Since that won't
> impact the PHY binding, it seems fine to leave it here for now.
thanks :)
Regards
Pratyush
>
> Arnd
^ permalink raw reply
* [PATCH 03/03] ARM: shmobile: Lager USB0 cable detection workaround
From: Magnus Damm @ 2014-01-31 3:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1682649.H5bjffAvcD@avalon>
Hi Laurent,
[CC Morimoto-san, the author of the USBHS driver]
On Fri, Jan 31, 2014 at 10:14 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Magnus,
>
> Thank you for the patch.
>
> On Thursday 30 January 2014 08:10:29 Magnus Damm wrote:
>> From: Magnus Damm <damm@opensource.se>
>>
>> Add Lager board code to check the PWEN GPIO signal and refuse to
>> allow probe of the USBHS driver in case of DIP misconfiguration.
>>
>> For correct operation Lager DIP switches SW5 and SW6 shall be
>> configured in 2-3 position to enable USB Function support.
>>
>> If the DIP switch is configured incorrectly then the user can
>> simply adjust the hardware and either reboot or use the bind interface
>> to try to probe again:
>>
>> # echo renesas_usbhs > /sys/bus/platform/drivers/renesas_usbhs/bind
>
> Our of curiosity, and I know you will love the question, have you thought
> about how to implement this on multiplatform kernels without a board file ?
> :-)
Thanks for asking. =)
Actually I've been giving this some thought already. And it happens to
be that the sister board "Koelsch" has similar but slightly improved
hardware.
In the Lager case we can only support USB Function properly and
safely, and to avoid shooting ourselves in the foot we need a check
like this patch implements. So on Lager RCAR_GP_PIN(5, 18) needs to be
high for proper USB Function operation. If not we give up.
In case of Koelsch a MAX3355E chip is hooked up to handle dual
function or OTG. So on that platform we can use either Function or
Host. To figure out which cable is hooked up we can check the ID pin
of the USB connector through the MAX3355E ID_OUT signal.
In general with a USB connector (and the MAX3355E chip) there are
standard signal levels for ID pin detection. The ID signal for the USB
micro-AB connector will be High in case of Function cable (pull-up,
left open), and Low in case of Host (tied to GND).
So, to answer your question about how to support this without
board-specific code written in C, I believe we need to add
abstractions to support the MAX3355E chip and/or external ID pin
somehow. Perhaps there is almost nothing to abstract there?
Regarding how to support Lager then I think we can use the same code
as Koelsch because the ID pin signal is following the same signal
level. So perhaps it is enough to add support for the USBHS driver to
handle the ID pin as GPIO? If so, then we can use the same style for
both Lager and Koelsch, but on Lager we also somehow need to tell the
the USBHS driver that only Function is OK.
> This might be one of the valid cases where we won't be able to do without a
> board file. The callback functions in platform data, however, probably need to
> go.
I think it is possible to get rid of the board file. And especially if
we can reuse the code for multiple boards or SoC then this starts
making sense - even to me! =)
Thanks,
/ magnus
^ permalink raw reply
* [PATCH 02/03] pinctrl: sh-pfc: r8a7790: Break out USB0 OVC/VBUS
From: Magnus Damm @ 2014-01-31 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1397857.qyLQY9XTlp@avalon>
Hi Laurent,
On Fri, Jan 31, 2014 at 10:17 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Magnus,
>
> Thank you for the patch.
>
> On Thursday 30 January 2014 08:10:19 Magnus Damm wrote:
>> From: Magnus Damm <damm@opensource.se>
>>
>> Create a new group for the USB0 OVC/VBUS pin by itself. This
>> allows us to monitor PWEN as GPIO on the Lager board.
>>
>> Signed-off-by: Magnus Damm <damm@opensource.se>
>> ---
>>
>> drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> --- 0001/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
>> +++ work/drivers/pinctrl/sh-pfc/pfc-r8a7790.c 2014-01-24
> 10:23:32.000000000
>> +0900 @@ -3231,6 +3231,13 @@ static const unsigned int usb0_pins[] =
>> static const unsigned int usb0_mux[] = {
>> USB0_PWEN_MARK, USB0_OVC_VBUS_MARK,
>> };
>> +static const unsigned int usb0_ovc_vbus_pins[] = {
>> + /* OVC/VBUS */
>> + RCAR_GP_PIN(5, 19),
>> +};
>> +static const unsigned int usb0_ovc_vbus_mux[] = {
>> + USB0_OVC_VBUS_MARK,
>> +};
>
> Another option would have been to split the existing usb0 group in usb0_pwen
> and usb0_ovc. I'm not sure which is better though, I'd just like to know if
> you had given it a thought.
I actually did just that in my first local attempt, but I decided not
to since it will only cause potential breakage.
> Regardless, what about naming the new group usb0_ovc instead of usb0_ovc_bus
> to keep names short ?
Is there any particular reason why you want shorter names?
>From my side, I prefer to keep the names in sync with the data sheet.
In this particular case it is a shared pin so OVC is used for Host
while VBUS is used for gadget, so if you're proposing to ditch VBUS
then this feels somewhat inconsistent with the current gadget use
case. =)
Thanks,
/ magnus
^ permalink raw reply
* [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Felipe Balbi @ 2014-01-31 2:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGa+x854huSmiWmEv2EgOPUgZKcp3iitNaBvKXt8DiEj8msSVg@mail.gmail.com>
Hi,
On Thu, Jan 30, 2014 at 03:52:16PM -0800, Kevin Hilman wrote:
> On Wed, Jan 29, 2014 at 5:32 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Wed, Jan 29, 2014 at 12:25:20PM +0000, Mark Brown wrote:
> >> On Wed, Jan 29, 2014 at 12:10:48PM +0100, Maxime Ripard wrote:
> >>
> >> > +config SPI_SUN6I
> >> > + tristate "Allwinner A31 SPI controller"
> >> > + depends on ARCH_SUNXI || COMPILE_TEST
> >> > + select PM_RUNTIME
> >> > + help
> >> > + This enables using the SPI controller on the Allwinner A31 SoCs.
> >> > +
> >>
> >> A select of PM_RUNTIME is both surprising and odd - why is that there?
> >> The usual idiom is that the device starts out powered up (flagged using
> >> pm_runtime_set_active()) and then runtime PM then suspends it when it's
> >> compiled in. That way if for some reason people want to avoid runtime
> >> PM they can still use the device.
> >
> > Since pm_runtime_set_active and all the pm_runtime* callbacks in
> > general are defined to pretty much empty functions, how the
> > suspend/resume callbacks are called then? Obviously, we need them to
> > be run, hence why I added the select here, but now I'm seeing a
> > construct like what's following acceptable then?
>
> Even with your 'select', The runtime PM callbacks will never be called
> in the current driver. pm_runtime_enable() doesn't do any runtime PM
> transitions. It just allows transitions to happen when they're
> triggered by _get()/_put()/etc.
>
> > pm_runtime_enable(&pdev->dev);
> > if (!pm_runtime_enabled(&pdev->dev))
> > sun6i_spi_runtime_resume(&pdev->dev);
>
> Similarily here, it's not the pm_runtime_enable that will fail when
> runtime PM is disabled (or not built-in), it's a pm_runtime_get_sync()
> that will fail.
>
> What you want is something like this in ->probe()
>
> sun6i_spi_runtime_resume();
> /* now, device is always activated whether or not runtime PM is enabled */
> pm_runtime_enable();
> pm_runtime_set_active(); /* tells runtime PM core device is
> already active */
shouldn't this be done before pm_runtime_enable() ?
> pm_runtime_get_sync();
>
> This 'get' will increase the usecount, but not actually call the
> callbacks because we told the RPM core that the device was already
> activated with _set_active().
>
> And then, in ->remove(), you'll want
>
> pm_runtime_put();
in ->remove() you actually want a put_sync() right ? You don't want to
schedule anything since you're just about to disable pm_runtime.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140130/eee0da03/attachment-0001.sig>
^ permalink raw reply
* [PATCH V2] arm64: add DSB after icache flush in __flush_icache_all()
From: Nicolas Pitre @ 2014-01-31 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131001647.GA5525@mudshark.cambridge.arm.com>
On Fri, 31 Jan 2014, Will Deacon wrote:
> Hi Nico,
>
> On Thu, Jan 30, 2014 at 09:42:29PM +0000, Nicolas Pitre wrote:
> > On Thu, 30 Jan 2014, Will Deacon wrote:
> > > On Thu, Jan 30, 2014 at 06:04:43AM +0000, Vinayak Kale wrote:
> > > > Can you please elaborate whether you are referring to lack of memory
> > > > clobber or missing barriers?
> > >
> > > The clobbers. For example:
> > >
> > > arch/arm64/kvm/sys_regs.c:
> > >
> > > /* Make sure noone else changes CSSELR during this! */
> > > local_irq_disable();
> > > /* Put value into CSSELR */
> > > asm volatile("msr csselr_el1, %x0" : : "r" (csselr));
> > > isb();
> > > /* Read result out of CCSIDR */
> > > asm volatile("mrs %0, ccsidr_el1" : "=r" (ccsidr));
> > > local_irq_enable();
> > >
> > > Just about everything can be re-ordered in that block, because the asm
> > > volatile statements don't have "memory" clobbers.
> >
> > I don't think they would be reordered at all with the
> > volatile qualifiers.
>
> Whilst that may be the case in current compilers (i.e. I've not actually
> seen the above sequence get re-ordered), the GCC documentation states that:
>
> Similarly, you can't expect a sequence of volatile asm instructions to remain
> perfectly consecutive. If you want consecutive output, use a single asm. Also,
> GCC performs some optimizations across a volatile asm instruction; GCC does not
> `forget everything' when it encounters a volatile asm instruction the way some
> other compilers do.
>
> so I really think that the "memory" clobbers are needed to ensure strict
> ordering. This matches my understanding from discussions with the compiler
> engineers at ARM.
Well, the key sentence above is: "you can't expect a sequence of
volatile asm instructions to remain perfectly consecutive." That
doesn't mean the "ordering" won't be respected.
If you need a certain ordering, then a volatile is all that you need.
If nothing else should happen in between, then just use a single asm
statement as suggested.
Only if you need ordering with regards to other memory accesses as well
then yes you need a memory clobber in that case.
Nicolas
^ permalink raw reply
* [PATCH v2 00/21] pinctrl: mvebu: restructure and remove hardcoded addresses from Dove pinctrl
From: Sebastian Hesselbarth @ 2014-01-31 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130202500.GN10864@lunn.ch>
On 01/30/2014 09:25 PM, Andrew Lunn wrote:
> On Thu, Jan 30, 2014 at 07:50:34PM +0100, Sebastian Hesselbarth wrote:
>> On 01/30/2014 07:29 PM, Andrew Lunn wrote:
>>> On Tue, Jan 28, 2014 at 01:39:12AM +0100, Sebastian Hesselbarth wrote:
>>>> This patch set is one required step for Dove to hop into mach-mvebu.
>>>> Until now, pinctrl-dove was hardcoding some registers that do not
>>>> directly belong to MPP core registers. This is not compatible with
>>>> what we want for mach-mvebu.
>>>
>>> I think there might be something wrong here....
>>
>> There _is_ something wrong. I'll have a look at it. For the record,
>> what SoC are you testing with? From the base address, I guess it is
>> Kirkwood?
>
> Yes, Kirkwood. Sorry for not saying.
This time I push a branch before sending out the patches. Also, I
think I'll postpone removal of hardcoded addresses until this is
sorted out. The patch set was growing way to quick and I have to
do this step-by-step for me and everybody else to actually understand ;)
So, at least the MVEBU guys should test the following branch on
their SoCs. Again, I have tested Dove and now confirmed that settings
are still correct. The others are compile-tested.
https://github.com/shesselba/linux-dove.git unstable/mvebu-pinctrl-v3.14_v3
@Thomas, Gregory: Do you think that the above branch will be
restructured enough allow support for orion5x and mv78xx0? I had a
quick look at mach-{orion5x,mv78xx0}/mpp.h and didn't see anything
weird.
Sebastian
^ permalink raw reply
* [PATCH 02/03] pinctrl: sh-pfc: r8a7790: Break out USB0 OVC/VBUS
From: Laurent Pinchart @ 2014-01-31 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129231019.22655.41456.sendpatchset@w520>
Hi Magnus,
Thank you for the patch.
On Thursday 30 January 2014 08:10:19 Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
>
> Create a new group for the USB0 OVC/VBUS pin by itself. This
> allows us to monitor PWEN as GPIO on the Lager board.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
>
> drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> --- 0001/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
> +++ work/drivers/pinctrl/sh-pfc/pfc-r8a7790.c 2014-01-24
10:23:32.000000000
> +0900 @@ -3231,6 +3231,13 @@ static const unsigned int usb0_pins[] =
> static const unsigned int usb0_mux[] = {
> USB0_PWEN_MARK, USB0_OVC_VBUS_MARK,
> };
> +static const unsigned int usb0_ovc_vbus_pins[] = {
> + /* OVC/VBUS */
> + RCAR_GP_PIN(5, 19),
> +};
> +static const unsigned int usb0_ovc_vbus_mux[] = {
> + USB0_OVC_VBUS_MARK,
> +};
Another option would have been to split the existing usb0 group in usb0_pwen
and usb0_ovc. I'm not sure which is better though, I'd just like to know if
you had given it a thought.
Regardless, what about naming the new group usb0_ovc instead of usb0_ovc_bus
to keep names short ?
> /* - USB1
> ------------------------------------------------------------------- */
> static const unsigned int usb1_pins[] = {
> /* PWEN, OVC */
> @@ -3789,6 +3796,7 @@ static const struct sh_pfc_pin_group pin
> SH_PFC_PIN_GROUP(tpu0_to2),
> SH_PFC_PIN_GROUP(tpu0_to3),
> SH_PFC_PIN_GROUP(usb0),
> + SH_PFC_PIN_GROUP(usb0_ovc_vbus),
> SH_PFC_PIN_GROUP(usb1),
> SH_PFC_PIN_GROUP(usb2),
> VIN_DATA_PIN_GROUP(vin0_data, 24),
> @@ -4134,6 +4142,7 @@ static const char * const tpu0_groups[]
>
> static const char * const usb0_groups[] = {
> "usb0",
> + "usb0_ovc_vbus",
> };
>
> static const char * const usb1_groups[] = {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 03/03] ARM: shmobile: Lager USB0 cable detection workaround
From: Laurent Pinchart @ 2014-01-31 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129231029.22655.58864.sendpatchset@w520>
Hi Magnus,
Thank you for the patch.
On Thursday 30 January 2014 08:10:29 Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
>
> Add Lager board code to check the PWEN GPIO signal and refuse to
> allow probe of the USBHS driver in case of DIP misconfiguration.
>
> For correct operation Lager DIP switches SW5 and SW6 shall be
> configured in 2-3 position to enable USB Function support.
>
> If the DIP switch is configured incorrectly then the user can
> simply adjust the hardware and either reboot or use the bind interface
> to try to probe again:
>
> # echo renesas_usbhs > /sys/bus/platform/drivers/renesas_usbhs/bind
Our of curiosity, and I know you will love the question, have you thought
about how to implement this on multiplatform kernels without a board file ?
:-)
This might be one of the valid cases where we won't be able to do without a
board file. The callback functions in platform data, however, probably need to
go.
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
>
> Depends on "[PATCH 02/03] pinctrl: sh-pfc: r8a7790: Break out USB0
> OVC/VBUS"
>
> arch/arm/mach-shmobile/board-lager.c | 25 ++++++++++++++++++++++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> --- 0004/arch/arm/mach-shmobile/board-lager.c
> +++ work/arch/arm/mach-shmobile/board-lager.c 2014-01-24
10:17:20.000000000
> +0900 @@ -406,13 +406,30 @@ static int usbhs_hardware_init(struct pl
> {
> struct usbhs_private *priv = usbhs_get_priv(pdev);
> struct usb_phy *phy;
> + int ret;
> +
> + /* USB0 Function - use PWEN as GPIO input to detect DIP Switch SW5
> + * setting to avoid VBUS short circuit due to wrong cable.
> + * PWEN should be pulled up high if USB Function is selected by SW5
> + */
> + gpio_request_one(RCAR_GP_PIN(5, 18), GPIOF_IN, NULL); /* USB0_PWEN */
> + if (!gpio_get_value(RCAR_GP_PIN(5, 18))) {
> + pr_warn("Error: USB Function not selected - check SW5 + SW6\n");
> + ret = -ENOTSUPP;
> + goto error;
> + }
>
> phy = usb_get_phy_dev(&pdev->dev, 0);
> - if (IS_ERR(phy))
> - return PTR_ERR(phy);
> + if (IS_ERR(phy)) {
> + ret = PTR_ERR(phy);
> + goto error;
> + }
>
> priv->phy = phy;
> return 0;
> + error:
> + gpio_free(RCAR_GP_PIN(5, 18));
> + return ret;
> }
>
> static int usbhs_hardware_exit(struct platform_device *pdev)
> @@ -424,6 +441,8 @@ static int usbhs_hardware_exit(struct pl
>
> usb_put_phy(priv->phy);
> priv->phy = NULL;
> +
> + gpio_free(RCAR_GP_PIN(5, 18));
> return 0;
> }
>
> @@ -534,7 +553,7 @@ static const struct pinctrl_map lager_pi
> "vin1_clk", "vin1"),
> /* USB0 */
> PIN_MAP_MUX_GROUP_DEFAULT("renesas_usbhs", "pfc-r8a7790",
> - "usb0", "usb0"),
> + "usb0_ovc_vbus", "usb0"),
> };
>
> static void __init lager_add_standard_devices(void)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [GIT PULL] ARM: SoC late DT changes for v3.14
From: Kevin Hilman @ 2014-01-31 0:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
These are a few changes that arrived a little late but were considered
self-contained enough to still go in for v3.14.
They are all device tree updtes this time around, and mainly for
Broadcom SoCs.
There is one trivial add/add conflict in one of the device tree files.
Please pull,
Kevin
----------------------------------------------------------------
The following changes since commit 53d8ab29f8f6d67e37857b68189b38fa3d87dd8e:
Merge branch 'for-3.14/drivers' of git://git.kernel.dk/linux-block
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/late-dt-for-linus
for you to fetch changes up to 929267cb3525daf72f730f4d4c4e1e9e2b135e61:
ARM: moxart: move fixed rate clock child node to board level dts
----------------------------------------------------------------
Alex Elder (1):
clk: bcm281xx: define kona clock binding
Jonas Jensen (1):
ARM: moxart: move fixed rate clock child node to board level dts
Kevin Hilman (1):
Merge tag 'bcm-for-3.14-dt' of git://github.com/broadcom/bcm11351 into next/dt
Matt Porter (1):
ARM: dts: add usb udc support to bcm281xx
Tim Kryger (8):
ARM: dts: bcm28155-ap: Enable all the i2c busses
ARM: dts: Declare clocks as fixed on bcm11351
ARM: dts: bcm281xx: Add i2c busses
ARM: dts: Specify clocks for UARTs on bcm11351
Documentation: dt: kona-sdhci: Add clocks property
ARM: dts: Specify clocks for SDHCIs on bcm11351
Documentation: dt: kona-timer: Add clocks property
ARM: dts: Specify clocks for timer on bcm11351
.../devicetree/bindings/arm/bcm/kona-timer.txt | 7 +-
.../bindings/clock/bcm-kona-clock.txt | 93 ++++++++++
.../devicetree/bindings/mmc/kona-sdhci.txt | 4 +
arch/arm/boot/dts/bcm11351-brt.dts | 6 +
arch/arm/boot/dts/bcm11351.dtsi | 169 ++++++++++++++++++-
arch/arm/boot/dts/bcm28155-ap.dts | 28 +++
arch/arm/boot/dts/moxart-uc7112lx.dts | 8 +
arch/arm/boot/dts/moxart.dtsi | 6 -
8 files changed, 309 insertions(+), 12 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
^ permalink raw reply
* [PATCH 00/03] ARM: shmobile: Lager USBHS update
From: Simon Horman @ 2014-01-31 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129230959.22655.55645.sendpatchset@w520>
On Thu, Jan 30, 2014 at 08:09:59AM +0900, Magnus Damm wrote:
> ARM: shmobile: Lager USBHS update
>
> [PATCH 01/03] ARM: shmobile: Remove Lager USBHS UDC ifdefs
Thanks, I will queue this one up.
> [PATCH 02/03] pinctrl: sh-pfc: r8a7790: Break out USB0 OVC/VBUS
I believe that this one is for Laurent.
> [PATCH 03/03] ARM: shmobile: Lager USB0 cable detection workaround
I will hold off on this one as it depends on the previous patch.
> Update the Lager USB0 code to let the USBHS device always be present
> and check for DIP switch configuration. To be able to check the DIP
> switch configuration the r8a7790 PINCTRL bits need to be updated too.
>
> With this series USB0 on Lager will be fixed to USB Function via the
> USBHS driver. In theory the SoC can also use USB Host on this port
> either via USBHS or PCI USB, but since cable detection is missing
> it is possible for the user to misconfigure USB Host and drive VBUS
> with the wrong cable. Because of that USB0 will be forced to stick
> to Function-only in the Lager board code.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
>
> Written against renesas.git tag renesas-devel-v3.13-20140127
>
> arch/arm/mach-shmobile/board-lager.c | 29 ++++++++++++++++++++++-------
> drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 9 +++++++++
> 2 files changed, 31 insertions(+), 7 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Extending OPP bindings
From: Nishanth Menon @ 2014-01-31 0:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA570A.8040501@arm.com>
Hi Sudeep,
On 01/30/2014 07:43 AM, Sudeep Holla wrote:
>
> I am looking into a couple shortcomings in the current OPP bindings and
> how to address them. Feel free to add to the list if you think of any more
> issues that needs to be addressed or if and how any problem mentioned below
> can be handled with the existing bindings.
>
> 1. indexing: currently there are no indices in the operating-points.
indexing is based on frequency which is why the accessors use
frequency to pull out the OPP data.
indexing is a horrible idea - on platforms where OPP may be disabled
or enabled for various reasons(see arch/arm/mach-imx/mach-imx6q.c,
arch/arm/mach-omap2/board-omap3beagle.c etc) - the indexing you see in
dts is just a myth that may not exist once the nodes are loaded and
operated upon depending on SoC variations (example efuse describing
which OPPs can be used and which not).
That said, the original OPP[1][2] series discussion started by trying
to kill indexing precisely for the same reason.. once you have it - it
becomes just crazy to deal with.
> It's assumed that the list is either in ascending or descending
> order of frequency but not explicit in the binding document.
> There are arch/arm/boot/dts/* files with opps in both styles.
it should not matter -> opp library should do an insertion sort and
organize it in ascending order once all the data is inserted. (line
449ish in opp.c)
if you see issues with the insertion sort not functioning, it is a bug
and should be easy to track down and fix.
> Few other bindings like thermal defines bindings like
> cooling-{min,max}-state assuming some order which is broken IMO.
Now that you bring it up, I missed it :(.. yeah, I might have
preferred it to be min frequency and max_frequency - I agree it is
probably broken. I'd let Eduardo comment more about it.
>
> One such use-case that came up recently[0] is the c-state latencies
> which could be different for each OPP. It would be good if the
> latencies are specified with the indices to OPP table to avoid
> inconsistency between the bindings.
You can define C states based on frequencies as well - which really
makes sense - since that sounds really like our constraint (say
valid-at-frequency "xyz"
>
> It's mainly to avoid issues due to inconsistency and duplication
> on data(frequency) in multiple bindings requiring it.
>
> Once we have indices to each on the OPP entries, then other binding
> using it can refer to OPP with phandle and OPP index/specifier pairs
> very similar to clock provider and consumer.
Having used indexing in OMAP platforms, indexing is a problem waiting
to happen unfortunately :(
>
> 2. sharing opps: I have tried to address this issue previously[1] but unable
> to conclude yet on this.
yes - more details in [3] - which is a more interesting discussion
there - lets revive it in that context.
It is a valid concern and IMHO a great idea - yeah we already have a
thread started.
>
> 3. latencies(*): currently the latency that the CPU/memory access is unavailable
> during an OPP transition is generic i.e. same from any OPP to any
> other OPP. Does it make sense to have this per-OPP entry ?
Why modify OPP when you are describing something else? you are
describing "latency at a frequency" - just because an OPP definition
as it stands right now is {frequency, voltage} tuple, makes it a very
attractive target to keep extending it -> believe me, we have done
that in the past ->arch/arm/mach-omap2/opp4xxx_data.c efuse register
describing AVS per frequency is tempting..
why not have memory-latency-per-opp = <frequency latency>?
that allows OPP definitions to change in the future, but the
definition remain constant.
That said -> consider the following usecase: AM335x, OMAP3,4... (i
will use omap4 as an example)
MPU at 300MHz and bus (on which LPDDR2 memory is) at 100MHz
AND
MPU at 300MHz and bus (on which LPDDR2 memory is) at 200MHz
are both valid with different memory access latencies. tying it down
to OPP for MPU is just plain wrong - as it ignores other factors.
>
> 4. power(*): A measure of maximum power dissipation in an OPP state.
> This might be useful measure for power aware scheduling ?
Umm.. this is a hard nut to crack -> I had considered that previously
as well -> In reality the leakage characteristics of the SoC
distribution varies dramatically depending on which end of the
distribution you look for a specific process node. in my company, we
typically use cold, hot,nominal devices, this is some form or other
(example - Samsung calls it "SoC's ASV group" [4]) - and every SoC
company comes up with some strategy or other to control it optimally
-> TI uses ABB[5], AVS[6] - etc... - not an unique problem -> so what
will "power" mean? we cannot create dts per SoC part.
>
> (*) these are already part of P-state in ACPI(refer struct acpi_processor_px
> in include/acpi/processor.h)
Hmm.. what do we do with legacy processors that dont support ACPI or
what ever our latest ARM term is for the equivalent?
>
> Apart from these I have seen on-going discussion for Samsung Exynos CPUFreq[2]
> which might have some feedback for OPP bindings.
>
> It would be good to consolidate the shortcomings found so far, that could
> help in extending the current OPP bindings.
I hope this discussion helps. open to more views as well.
> [0] http://www.spinics.net/lists/arm-kernel/msg301971.html
> [1] http://www.spinics.net/lists/cpufreq/msg07911.html
> [2] http://www.spinics.net/lists/cpufreq/msg09169.html
[1] http://marc.info/?t=125546601600001&r=1&w=2
[2] http://marc.info/?l=linux-omap&m=125474840119392&w=2
[3] http://marc.info/?t=138063448000008&r=1&w=2
[4] http://marc.info/?l=linux-pm&m=138451581304412&w=2
[5]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/ti-abb-regulator.c
[6]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/power/avs/smartreflex.c
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Will Deacon @ 2014-01-31 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EAD7EF.3040305@amd.com>
On Thu, Jan 30, 2014 at 10:53:35PM +0000, Suravee Suthikulanit wrote:
> On 1/29/2014 12:03 PM, Will Deacon wrote:
> > Interesting... how does that work for PCI? Do you force all devices behind a
> > given RC into the same address space?
> >
>
> For PCI devices, we are using the bus, device, and function id to make
> up the 15-bit SID for devices behind a particular PCI root complex.
Very good!
> I also notice that we are currently not supporting the streamID mask in
> the SMR. Is this something planed for the future?
Andreas and I are curently working on this -- that's what I was referring to
above. Any feedback from you would be welcomed.
Will
^ permalink raw reply
* [PATCH V2] arm64: add DSB after icache flush in __flush_icache_all()
From: Will Deacon @ 2014-01-31 0:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401301640500.1652@knanqh.ubzr>
Hi Nico,
On Thu, Jan 30, 2014 at 09:42:29PM +0000, Nicolas Pitre wrote:
> On Thu, 30 Jan 2014, Will Deacon wrote:
> > On Thu, Jan 30, 2014 at 06:04:43AM +0000, Vinayak Kale wrote:
> > > Can you please elaborate whether you are referring to lack of memory
> > > clobber or missing barriers?
> >
> > The clobbers. For example:
> >
> > arch/arm64/kvm/sys_regs.c:
> >
> > /* Make sure noone else changes CSSELR during this! */
> > local_irq_disable();
> > /* Put value into CSSELR */
> > asm volatile("msr csselr_el1, %x0" : : "r" (csselr));
> > isb();
> > /* Read result out of CCSIDR */
> > asm volatile("mrs %0, ccsidr_el1" : "=r" (ccsidr));
> > local_irq_enable();
> >
> > Just about everything can be re-ordered in that block, because the asm
> > volatile statements don't have "memory" clobbers.
>
> I don't think they would be reordered at all with the
> volatile qualifiers.
Whilst that may be the case in current compilers (i.e. I've not actually
seen the above sequence get re-ordered), the GCC documentation states that:
Similarly, you can't expect a sequence of volatile asm instructions to remain
perfectly consecutive. If you want consecutive output, use a single asm. Also,
GCC performs some optimizations across a volatile asm instruction; GCC does not
`forget everything' when it encounters a volatile asm instruction the way some
other compilers do.
so I really think that the "memory" clobbers are needed to ensure strict
ordering. This matches my understanding from discussions with the compiler
engineers at ARM.
Will
^ permalink raw reply
* iommu/arm-smmu: Regression (sleeping function called from invalid context)
From: Andreas Herrmann @ 2014-01-30 23:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Will,
Seems that commit a44a9791e778d9ccda50d5534028ed4057a9a45b
(iommu/arm-smmu: use mutex instead of spinlock for locking page tables)
introduced a regression.
At least I've hit
BUG: scheduling while atomic: ksoftirqd/0/3/0x00000100
and after turning on CONFIG_DEBUG_ATOMIC_SLEEP I get
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:96
in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper/0
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-00013-gd414667 #411
[<c0014740>] (unwind_backtrace+0x0/0xf8) from [<c00115b0>] (show_stack+0x10/0x14)
[<c00115b0>] (show_stack+0x10/0x14) from [<c057f12c>] (dump_stack+0x74/0xa8)
[<c057f12c>] (dump_stack+0x74/0xa8) from [<c0583460>] (mutex_lock+0x18/0x64)
[<c0583460>] (mutex_lock+0x18/0x64) from [<c042a5fc>] (arm_smmu_handle_mapping+0xfc/0x644)
[<c042a5fc>] (arm_smmu_handle_mapping+0xfc/0x644) from [<c0429674>] (iommu_map+0xf0/0x148)
[<c0429674>] (iommu_map+0xf0/0x148) from [<c00199c8>] (__map_sg_chunk+0x208/0x414)
[<c00199c8>] (__map_sg_chunk+0x208/0x414) from [<c0019d50>] (__iommu_map_sg+0x17c/0x208)
[<c0019d50>] (__iommu_map_sg+0x17c/0x208) from [<c0019df8>] (arm_iommu_map_sg+0x1c/0x24)
[<c0019df8>] (arm_iommu_map_sg+0x1c/0x24) from [<c031edb4>] (ata_qc_issue+0x258/0x370)
[<c031edb4>] (ata_qc_issue+0x258/0x370) from [<c0323b68>] (ata_scsi_translate+0x90/0x150)
[<c0323b68>] (ata_scsi_translate+0x90/0x150) from [<c0327368>] (ata_scsi_queuecmd+0x84/0x248)
[<c0327368>] (ata_scsi_queuecmd+0x84/0x248) from [<c0301ed8>] (scsi_dispatch_cmd+0x94/0x134)
[<c0301ed8>] (scsi_dispatch_cmd+0x94/0x134) from [<c0307ecc>] (scsi_request_fn+0x3dc/0x5dc)
[<c0307ecc>] (scsi_request_fn+0x3dc/0x5dc) from [<c0250034>] (__blk_run_queue+0x34/0x44)
[<c0250034>] (__blk_run_queue+0x34/0x44) from [<c02539e0>] (blk_queue_bio+0x178/0x26c)
[<c02539e0>] (blk_queue_bio+0x178/0x26c) from [<c02512a0>] (generic_make_request+0xa8/0xc8)
[<c02512a0>] (generic_make_request+0xa8/0xc8) from [<c0251348>] (submit_bio+0x88/0x134)
[<c0251348>] (submit_bio+0x88/0x134) from [<c0113938>] (_submit_bh+0x1a4/0x254)
[<c0113938>] (_submit_bh+0x1a4/0x254) from [<c0114210>] (ll_rw_block+0x94/0xec)
[<c0114210>] (ll_rw_block+0x94/0xec) from [<c0116078>] (__breadahead+0x30/0x48)
[<c0116078>] (__breadahead+0x30/0x48) from [<c0171ca4>] (__ext4_get_inode_loc+0x3c4/0x450)
[<c0171ca4>] (__ext4_get_inode_loc+0x3c4/0x450) from [<c017409c>] (ext4_iget+0x60/0x96c)
[<c017409c>] (ext4_iget+0x60/0x96c) from [<c017cdc0>] (ext4_lookup+0x74/0x164)
[<c017cdc0>] (ext4_lookup+0x74/0x164) from [<c00f14a4>] (lookup_real+0x20/0x50)
[<c00f14a4>] (lookup_real+0x20/0x50) from [<c00f235c>] (__lookup_hash+0x34/0x44)
[<c00f235c>] (__lookup_hash+0x34/0x44) from [<c00f23a4>] (lookup_slow+0x38/0x9c)
[<c00f23a4>] (lookup_slow+0x38/0x9c) from [<c00f30d4>] (link_path_walk+0x308/0x7f0)
[<c00f30d4>] (link_path_walk+0x308/0x7f0) from [<c00f6384>] (path_openat+0x8c/0x63c)
[<c00f6384>] (path_openat+0x8c/0x63c) from [<c00f6c34>] (do_filp_open+0x2c/0x80)
[<c00f6c34>] (do_filp_open+0x2c/0x80) from [<c00edce0>] (open_exec+0x2c/0xf8)
[<c00edce0>] (open_exec+0x2c/0xf8) from [<c00eee98>] (do_execve+0x1a4/0x5a4)
[<c00eee98>] (do_execve+0x1a4/0x5a4) from [<c000873c>] (try_to_run_init_process+0x1c/0x50)
[<c000873c>] (try_to_run_init_process+0x1c/0x50) from [<c057b7a0>] (kernel_init+0xa8/0x110)
[<c057b7a0>] (kernel_init+0xa8/0x110) from [<c000e378>] (ret_from_fork+0x14/0x3c)
After reverting commit a44a9791e778d9ccda50d5534028ed4057a9a45b I have
fewer warnings/errors but still I've seen:
BUG: sleeping function called from invalid context at mm/page_alloc.c:2679
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-00016-g6e90346 #413
[<c0014740>] (unwind_backtrace+0x0/0xf8) from [<c00115b0>] (show_stack+0x10/0x14)
[<c00115b0>] (show_stack+0x10/0x14) from [<c057ea24>] (dump_stack+0x74/0xa8)
[<c057ea24>] (dump_stack+0x74/0xa8) from [<c00acc1c>] (__alloc_pages_nodemask+0x174/0x930)
[<c00acc1c>] (__alloc_pages_nodemask+0x174/0x930) from [<c042a250>] (arm_smmu_handle_mapping+0x470/0x66c)
[<c042a250>] (arm_smmu_handle_mapping+0x470/0x66c) from [<c0428e74>] (iommu_map+0xf0/0x148)
[<c0428e74>] (iommu_map+0xf0/0x148) from [<c001935c>] (__map_sg_chunk+0x198/0x2d4)
[<c001935c>] (__map_sg_chunk+0x198/0x2d4) from [<c0019614>] (__iommu_map_sg+0x17c/0x208)
[<c0019614>] (__iommu_map_sg+0x17c/0x208) from [<c00196bc>] (arm_iommu_map_sg+0x1c/0x24)
[<c00196bc>] (arm_iommu_map_sg+0x1c/0x24) from [<c031e5b4>] (ata_qc_issue+0x258/0x370)
[<c031e5b4>] (ata_qc_issue+0x258/0x370) from [<c0323368>] (ata_scsi_translate+0x90/0x150)
[<c0323368>] (ata_scsi_translate+0x90/0x150) from [<c0326b68>] (ata_scsi_queuecmd+0x84/0x248)
[<c0326b68>] (ata_scsi_queuecmd+0x84/0x248) from [<c03016d8>] (scsi_dispatch_cmd+0x94/0x134)
[<c03016d8>] (scsi_dispatch_cmd+0x94/0x134) from [<c03076cc>] (scsi_request_fn+0x3dc/0x5dc)
[<c03076cc>] (scsi_request_fn+0x3dc/0x5dc) from [<c024f834>] (__blk_run_queue+0x34/0x44)
[<c024f834>] (__blk_run_queue+0x34/0x44) from [<c024fabc>] (blk_run_queue+0x1c/0x2c)
[<c024fabc>] (blk_run_queue+0x1c/0x2c) from [<c030638c>] (scsi_run_queue+0xc4/0x240)
[<c030638c>] (scsi_run_queue+0xc4/0x240) from [<c0307f0c>] (scsi_next_command+0x2c/0x38)
[<c0307f0c>] (scsi_next_command+0x2c/0x38) from [<c030815c>] (scsi_io_completion+0x1fc/0x630)
[<c030815c>] (scsi_io_completion+0x1fc/0x630) from [<c0257a94>] (blk_done_softirq+0x74/0x8c)
[<c0257a94>] (blk_done_softirq+0x74/0x8c) from [<c002856c>] (__do_softirq+0xe4/0x210)
[<c002856c>] (__do_softirq+0xe4/0x210) from [<c00289c4>] (irq_exit+0xa0/0xec)
[<c00289c4>] (irq_exit+0xa0/0xec) from [<c000eb98>] (handle_IRQ+0x3c/0x90)
[<c000eb98>] (handle_IRQ+0x3c/0x90) from [<c0008538>] (gic_handle_irq+0x28/0x5c)
[<c0008538>] (gic_handle_irq+0x28/0x5c) from [<c0012040>] (__irq_svc+0x40/0x50)
Maybe that was the reason why the offending commit was introduced(?).
I think with the current code "atomic allocations" should be used when
IO page tables are created. With below patch I've not triggered above
errors.
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 429c95e..0418d69 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1398,7 +1398,7 @@ static int arm_smmu_alloc_init_pte(struct arm_smmu_device *smmu, pmd_t *pmd,
if (pmd_none(*pmd)) {
/* Allocate a new set of tables */
- pgtable_t table = alloc_page(PGALLOC_GFP);
+ pgtable_t table = alloc_page(GFP_ATOMIC);
if (!table)
return -ENOMEM;
@@ -1503,7 +1503,7 @@ static int arm_smmu_alloc_init_pmd(struct arm_smmu_device *smmu, pud_t *pud,
#ifndef __PAGETABLE_PMD_FOLDED
if (pud_none(*pud)) {
- pmd = pmd_alloc_one(NULL, addr);
+ pmd = (pmd_t *) get_zeroed_page(GFP_ATOMIC);
if (!pmd)
return -ENOMEM;
} else
@@ -1532,7 +1532,7 @@ static int arm_smmu_alloc_init_pud(struct arm_smmu_device *smmu, pgd_t *pgd,
#ifndef __PAGETABLE_PUD_FOLDED
if (pgd_none(*pgd)) {
- pud = pud_alloc_one(NULL, addr);
+ pud = (pud_t *) get_zeroed_page(GFP_ATOMIC);
if (!pud)
return -ENOMEM;
} else
^ permalink raw reply related
* [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Kevin Hilman @ 2014-01-30 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129133227.GQ3867@lukather>
On Wed, Jan 29, 2014 at 5:32 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Wed, Jan 29, 2014 at 12:25:20PM +0000, Mark Brown wrote:
>> On Wed, Jan 29, 2014 at 12:10:48PM +0100, Maxime Ripard wrote:
>>
>> > +config SPI_SUN6I
>> > + tristate "Allwinner A31 SPI controller"
>> > + depends on ARCH_SUNXI || COMPILE_TEST
>> > + select PM_RUNTIME
>> > + help
>> > + This enables using the SPI controller on the Allwinner A31 SoCs.
>> > +
>>
>> A select of PM_RUNTIME is both surprising and odd - why is that there?
>> The usual idiom is that the device starts out powered up (flagged using
>> pm_runtime_set_active()) and then runtime PM then suspends it when it's
>> compiled in. That way if for some reason people want to avoid runtime
>> PM they can still use the device.
>
> Since pm_runtime_set_active and all the pm_runtime* callbacks in
> general are defined to pretty much empty functions, how the
> suspend/resume callbacks are called then? Obviously, we need them to
> be run, hence why I added the select here, but now I'm seeing a
> construct like what's following acceptable then?
Even with your 'select', The runtime PM callbacks will never be called
in the current driver. pm_runtime_enable() doesn't do any runtime PM
transitions. It just allows transitions to happen when they're
triggered by _get()/_put()/etc.
> pm_runtime_enable(&pdev->dev);
> if (!pm_runtime_enabled(&pdev->dev))
> sun6i_spi_runtime_resume(&pdev->dev);
Similarily here, it's not the pm_runtime_enable that will fail when
runtime PM is disabled (or not built-in), it's a pm_runtime_get_sync()
that will fail.
What you want is something like this in ->probe()
sun6i_spi_runtime_resume();
/* now, device is always activated whether or not runtime PM is enabled */
pm_runtime_enable();
pm_runtime_set_active(); /* tells runtime PM core device is
already active */
pm_runtime_get_sync();
This 'get' will increase the usecount, but not actually call the
callbacks because we told the RPM core that the device was already
activated with _set_active().
And then, in ->remove(), you'll want
pm_runtime_put();
pm_runtime_disable();
And if runtime PM is not enabled in the kernel, then the device will
be left on (which is kinda what you want if you didn't build runtime
PM into the kernel.)
Kevin
^ permalink raw reply
* [PATCH v3 0/2] Qualcomm Universal Peripheral (QUP) I2C controller
From: Bjorn Andersson @ 2014-01-30 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391095811.3275.17.camel@iivanov-dev>
On Thu, Jan 30, 2014 at 7:30 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote:
>
> Hi Bjorn,
>
> On Wed, 2014-01-29 at 08:32 -0800, Bjorn Andersson wrote:
>> On Wed, Jan 29, 2014 at 12:14 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote:
>> >
>> > Hi Bjorn,
>> >
>> > On Fri, 2014-01-17 at 15:03 -0800, Bjorn Andersson wrote:
>> >> Continuing on Ivans i2c-qup series.
>> >>
>> >
>> > Do you plan to send v4 of this driver? I would like to address
>> > the remaining errors and suggestions and send a new version.
>> >
>> Hi Ivan,
>>
>> Yes I'm planning to send out a new revision of the patch set.
>>
>> I've incorporated fixes from the review comments here and my colleague
>> concluded through some testing that block read did not work, so we've
>> fixed that as well.
>
> Busted. I have not test it.
No worries, I'm glad you did the major cleanup from codeaurora!
>
>>
>> What have been holding me from submitting a new patchset is the 3
>> functions that does polling of state and status updates;
>> * qup_i2c_poll_state() reads the state register up to 1000 times,
>> hoping we reach the expected state, will delay 100uS and then continue
>> with 1000 more retries.
>> According to the data sheet a state transition is supposed to take
>> up to 2 bus cycles. Only time I can see that this would take longer
>> time are all error states, but the data sheet is not very clear
>> regarding this.
>>
>> * qup_i2c_wait_idle() reads the status register up to 1000 times,
>> hoping the fifo gets drained and the bus go idle, if that fails it
>> sleeps for the time we expect it to take to drain a full fifo and then
>> loops another 1000 times. This waits for the fifo to have drained and
>> the bus to go idle. On a read we get to this state if we issue the
>> write and then hit the error state, so we would reset the entire
>> block. On write we will only wait for the buffer not to be full before
>> returning.
>>
>> * qup_i2c_wait_clock_ready() waits up to 300 bus-clocks for the i2c
>> bus to go idle or forced low, I don't know why it retries 300 times.
>> This is called at the end of a write, possibly to wait for the fifo to
>> drain.
>>
>>
>> All three loops are in line with how it's been in codeaurora since the
>> beginning of time, but I at least need to figure out some good names
>> for those "magic numbers".
>
>
> Sure. I have keep them this way, just because I don't have information
> for internal trickery of the block.
I'll continue to talk to the Qualcomm guys to see if we can figure out
anything regarding the expected timings of those operations and I'll
send out a new version when we have something saner.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Suravee Suthikulanit @ 2014-01-30 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129180350.GS26622@mudshark.cambridge.arm.com>
On 1/29/2014 12:03 PM, Will Deacon wrote:
> On Wed, Jan 29, 2014 at 05:57:16PM +0000, Suravee Suthikulanit wrote:
>> On 1/29/2014 11:29 AM, Will Deacon wrote:
>>> On Wed, Jan 29, 2014 at 05:26:35PM +0000, Suravee Suthikulanit wrote:
>>>> On 1/29/2014 11:16 AM, Andreas Herrmann wrote:
>>>>> On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
>>>>>> Actually, we are using 32 on the AMD system. So, do you think we can set
>>>>>> this to 32 instead?
>>>>>
>>>>> I think that's ok.
>>>>>
>>>>> But are we really talking about number of SMRs or number of StreamIDs
>>>>> per master device here? Ie. are you just having 32 SMRs for an SMMU on
>>>>> your AMD system or do you have master devices which have 32 StreamIDs?
>>>>>
>>>>> If it's just number of SMRs we don't need to modify this macro.
>>>>>
>>>>
>>>> I am referring to the case where each mmu-master can have upto 32 streamID.
>>>
>>> Crikey, how many SMRs do you have? Andreas and I have been struggling to
>>> write a decent allocator for those, so if you have any algorithms that don't
>>> require a quantum computer, we'd love to hear from you :)!
>>>
>>> Will
>>>
>>
>> Are you talking about the __arm_smmu_alloc_bitmap()?
>>
>> Currently, we have configured the each SMMU to have 32 SMRs and using
>> 15-bit streamID. However, we mostly have upto 32 streamID for each
>> master, and most of the SMMU only have one master. So it looks like the
>> current logic should be ok.
>
> Interesting... how does that work for PCI? Do you force all devices behind a
> given RC into the same address space?
>
> Will
>
For PCI devices, we are using the bus, device, and function id to make
up the 15-bit SID for devices behind a particular PCI root complex.
I also notice that we are currently not supporting the streamID mask in
the SMR. Is this something planed for the future?
Suravee
^ permalink raw reply
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Ezequiel Garcia @ 2014-01-30 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EACB92.2080700@gmail.com>
On Thu, Jan 30, 2014 at 11:00:50PM +0100, Sebastian Hesselbarth wrote:
> On 01/30/2014 10:50 PM, Ezequiel Garcia wrote:
> > On Thu, Jan 30, 2014 at 03:53:15PM -0500, Jason Cooper wrote:
> >> Ezequiel,
> >>
> >> On Wed, Jan 29, 2014 at 03:19:50PM -0300, Ezequiel Garcia wrote:
> >>> On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> >>>> A new round, mostly fixing some minor nitpicks.
> >>>>
> >>>
> >>> If anyone wants to give this a test, here's a public branch:
> >>>
> >>> https://github.com/MISL-EBU-System-SW/mainline-public/tree/wdt_for_v3.14_v5
> >>
> >> I just took a quick glance at this (commit oneliners/tags) and there
> >> doesn't appear to be any dependence on Sebastian's series. Did I miss
> >> something?
> >>
> >
> > True, I've completely missed that. I pushed the branch in a rush!
> >
> > Let me prepare a v6, fixing the remaining issue pointed out by Russell,
> > and push again (together with Sebastian's irqchip fixes).
>
> Umm, no. Just directly name irqchip-orion fixes. Jason will send a PR
> for irqchip-fixes _with-in_ v3.14 while watchdog will go into v3.15.
>
That sounds good.
> Or are there any plans to get watchdog in *now*?
>
Not on my side, I'm aiming at v3.15.
> In any way, do not include my patches into your set.
>
Hm, maybe I've misexpressed myself. I wasn't intending to include
the patches on a submission, but just in a branch on the github repo.
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Jason Cooper @ 2014-01-30 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EACB92.2080700@gmail.com>
On Thu, Jan 30, 2014 at 11:00:50PM +0100, Sebastian Hesselbarth wrote:
> On 01/30/2014 10:50 PM, Ezequiel Garcia wrote:
> >On Thu, Jan 30, 2014 at 03:53:15PM -0500, Jason Cooper wrote:
> >>Ezequiel,
> >>
> >>On Wed, Jan 29, 2014 at 03:19:50PM -0300, Ezequiel Garcia wrote:
> >>>On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> >>>>A new round, mostly fixing some minor nitpicks.
> >>>>
> >>>
> >>>If anyone wants to give this a test, here's a public branch:
> >>>
> >>>https://github.com/MISL-EBU-System-SW/mainline-public/tree/wdt_for_v3.14_v5
> >>
> >>I just took a quick glance at this (commit oneliners/tags) and there
> >>doesn't appear to be any dependence on Sebastian's series. Did I miss
> >>something?
> >>
> >
> >True, I've completely missed that. I pushed the branch in a rush!
> >
> >Let me prepare a v6, fixing the remaining issue pointed out by Russell,
> >and push again (together with Sebastian's irqchip fixes).
>
> Umm, no. Just directly name irqchip-orion fixes. Jason will send a PR
> for irqchip-fixes _with-in_ v3.14 while watchdog will go into v3.15.
Yes, but I'd like to do a topic branch for that irqchip PR. That way,
we don't have to wait for them to land in an -rc. We can push the
watchdog changes when they are ready, and they can be based on v3.14-rc1
with irqchip/orion-fixes (or whatever) pulled in.
> In any way, do not include my patches into your set.
Agreed. I wasn't really keen on including the MMIO patch in the series
since it was already in rmk's patch tracker. Listing the deps in the
coverletter is enough.
> Jason: Ezequiel's watchdog patches install an irq handler that will
> panic(TM) on a watchdog irq. irqchip-orion does not properly clear
> stale bridge irqs which could signal a watchdog irq left by bootloader
> (or watchdog triggering between bootloader and driver probe).
Ok. I'll look things over and get some branches setup this weekend.
thx,
Jason.
^ permalink raw reply
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Sebastian Hesselbarth @ 2014-01-30 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130215056.GA1063@localhost>
On 01/30/2014 10:50 PM, Ezequiel Garcia wrote:
> On Thu, Jan 30, 2014 at 03:53:15PM -0500, Jason Cooper wrote:
>> Ezequiel,
>>
>> On Wed, Jan 29, 2014 at 03:19:50PM -0300, Ezequiel Garcia wrote:
>>> On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
>>>> A new round, mostly fixing some minor nitpicks.
>>>>
>>>
>>> If anyone wants to give this a test, here's a public branch:
>>>
>>> https://github.com/MISL-EBU-System-SW/mainline-public/tree/wdt_for_v3.14_v5
>>
>> I just took a quick glance at this (commit oneliners/tags) and there
>> doesn't appear to be any dependence on Sebastian's series. Did I miss
>> something?
>>
>
> True, I've completely missed that. I pushed the branch in a rush!
>
> Let me prepare a v6, fixing the remaining issue pointed out by Russell,
> and push again (together with Sebastian's irqchip fixes).
Umm, no. Just directly name irqchip-orion fixes. Jason will send a PR
for irqchip-fixes _with-in_ v3.14 while watchdog will go into v3.15.
Or are there any plans to get watchdog in *now*?
In any way, do not include my patches into your set.
Jason: Ezequiel's watchdog patches install an irq handler that will
panic(TM) on a watchdog irq. irqchip-orion does not properly clear
stale bridge irqs which could signal a watchdog irq left by bootloader
(or watchdog triggering between bootloader and driver probe).
Sebastian
^ permalink raw reply
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Ezequiel Garcia @ 2014-01-30 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130205315.GD29184@titan.lakedaemon.net>
On Thu, Jan 30, 2014 at 03:53:15PM -0500, Jason Cooper wrote:
> Ezequiel,
>
> On Wed, Jan 29, 2014 at 03:19:50PM -0300, Ezequiel Garcia wrote:
> > On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> > > A new round, mostly fixing some minor nitpicks.
> > >
> >
> > If anyone wants to give this a test, here's a public branch:
> >
> > https://github.com/MISL-EBU-System-SW/mainline-public/tree/wdt_for_v3.14_v5
>
> I just took a quick glance at this (commit oneliners/tags) and there
> doesn't appear to be any dependence on Sebastian's series. Did I miss
> something?
>
True, I've completely missed that. I pushed the branch in a rush!
Let me prepare a v6, fixing the remaining issue pointed out by Russell,
and push again (together with Sebastian's irqchip fixes).
> Also, the MMIO patch hit mainline last night.
>
Yup, I saw it. Thanks for the notice!
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ 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