* recommended action for bootloaders regarding modifying device-tree nodes
From: Jason Cooper @ 2014-01-30 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU366GiY4k_rnh1Jf0kra+PU99w4tDdM2sNioUAJCiZqOA@mail.gmail.com>
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. :)
> 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?
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 v5 00/20] Armada 370/XP watchdog support
From: Jason Cooper @ 2014-01-30 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129181949.GB27143@localhost>
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?
Also, the MMIO patch hit mainline last night.
thx,
Jason.
^ permalink raw reply
* [PATCH v2 2/5] ASoC: tda998x: add a codec driver for TDA998x
From: Mark Brown @ 2014-01-30 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c638b6622f4e059987f075091716a2305217ee49.1391081934.git.moinejf@free.fr>
On Sun, Jan 26, 2014 at 07:45:36PM +0100, Jean-Francois Moine wrote:
> +static void tda_get_encoder(struct tda_priv *priv)
> +{
> + struct snd_soc_codec *codec = priv->codec;
> + struct device_node *np;
> + struct i2c_client *i2c_client;
> + static const struct of_device_id tda_dt[] = {
> + { .compatible = "nxp,tda998x" },
> + { },
> + };
> +
> + /* search the tda998x device */
> + np = of_find_matching_node_and_match(NULL, tda_dt, NULL);
> + if (!np || !of_device_is_available(np)) {
> + dev_err(codec->dev, "No tda998x in DT\n");
> + return;
> + }
> + i2c_client = of_find_i2c_device_by_node(np);
Like I said last time I'd really expect this to look like a MFD (or
generally a proper CODEC driver) so we don't get this weird probe
ordering stuff. If you don't think that's sensible for some reason it'd
be helpful to understand why.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140130/875438f4/attachment.sig>
^ permalink raw reply
* [PATCHv3] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Laura Abbott @ 2014-01-30 21:05 UTC (permalink / raw)
To: linux-arm-kernel
arm64 currently lacks support for -fstack-protector. Add
similar functionality to arm to detect stack corruption.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
---
I realized today that the patch I gave before was not going to work for recent
trees because of changes to CC_STACKPROTECTOR that were not in my working tree
before. This should be the patch to actually work against recent kernels.
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/stackprotector.h | 38 +++++++++++++++++++++++++++++++
arch/arm64/kernel/process.c | 6 +++++
3 files changed, 45 insertions(+), 0 deletions(-)
create mode 100644 arch/arm64/include/asm/stackprotector.h
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index dd4327f..2ebf522 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -27,6 +27,7 @@ config ARM64
select HARDIRQS_SW_RESEND
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_TRACEHOOK
+ select HAVE_CC_STACKPROTECTOR
select HAVE_DEBUG_BUGVERBOSE
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_API_DEBUG
diff --git a/arch/arm64/include/asm/stackprotector.h b/arch/arm64/include/asm/stackprotector.h
new file mode 100644
index 0000000..fe5e287
--- /dev/null
+++ b/arch/arm64/include/asm/stackprotector.h
@@ -0,0 +1,38 @@
+/*
+ * GCC stack protector support.
+ *
+ * Stack protector works by putting predefined pattern at the start of
+ * the stack frame and verifying that it hasn't been overwritten when
+ * returning from the function. The pattern is called stack canary
+ * and gcc expects it to be defined by a global variable called
+ * "__stack_chk_guard" on ARM. This unfortunately means that on SMP
+ * we cannot have a different canary value per task.
+ */
+
+#ifndef __ASM_STACKPROTECTOR_H
+#define __ASM_STACKPROTECTOR_H
+
+#include <linux/random.h>
+#include <linux/version.h>
+
+extern unsigned long __stack_chk_guard;
+
+/*
+ * Initialize the stackprotector canary value.
+ *
+ * NOTE: this must only be called from functions that never return,
+ * and it must always be inlined.
+ */
+static __always_inline void boot_init_stack_canary(void)
+{
+ unsigned long canary;
+
+ /* Try to get a semi random initial value. */
+ get_random_bytes(&canary, sizeof(canary));
+ canary ^= LINUX_VERSION_CODE;
+
+ current->stack_canary = canary;
+ __stack_chk_guard = current->stack_canary;
+}
+
+#endif /* _ASM_STACKPROTECTOR_H */
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 1e5a178..89c301d 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -50,6 +50,12 @@
#include <asm/processor.h>
#include <asm/stacktrace.h>
+#ifdef CONFIG_CC_STACKPROTECTOR
+#include <linux/stackprotector.h>
+unsigned long __stack_chk_guard __read_mostly;
+EXPORT_SYMBOL(__stack_chk_guard);
+#endif
+
static void setup_restart(void)
{
/*
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 7/7] ARM: mvebu: enable audio options in mvebu_defconfig
From: Jason Cooper @ 2014-01-30 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-8-git-send-email-thomas.petazzoni@free-electrons.com>
On Thu, Jan 30, 2014 at 06:14:11PM +0100, Thomas Petazzoni wrote:
> Since at least the Armada 370 SoC has audio support, it makes sense to
> enable the corresponding kernel configuration options in
> mvebu_defconfig.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/arm/configs/mvebu_defconfig | 5 +++++
> 1 file changed, 5 insertions(+)
Please, let's also get in the habit of updating multi_v7_defconfig as
well.
thx,
Jason.
> diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
> index 594d706..e481f01 100644
> --- a/arch/arm/configs/mvebu_defconfig
> +++ b/arch/arm/configs/mvebu_defconfig
> @@ -60,6 +60,11 @@ CONFIG_GPIOLIB=y
> CONFIG_GPIO_SYSFS=y
> CONFIG_THERMAL=y
> CONFIG_ARMADA_THERMAL=y
> +CONFIG_SOUND=y
> +CONFIG_SND=y
> +CONFIG_SND_SOC=y
> +CONFIG_SND_KIRKWOOD_SOC=y
> +CONFIG_SND_KIRKWOOD_SOC_ARMADA370_DB=y
> CONFIG_USB_SUPPORT=y
> CONFIG_USB=y
> CONFIG_USB_EHCI_HCD=y
> --
> 1.8.3.2
>
^ permalink raw reply
* recommended action for bootloaders regarding modifying device-tree nodes
From: Jason Gunthorpe @ 2014-01-30 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130204558.GC29184@titan.lakedaemon.net>
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
^ permalink raw reply
* [PATCH] ARM: msm_defconfig: Change CONFIG_CC_STACKPROTECTOR
From: Laura Abbott @ 2014-01-30 21:23 UTC (permalink / raw)
To: linux-arm-kernel
CONFIG_CC_STACKPROTECTOR is no longer the option to select.
Switch to CONFIG_CC_STACKPROTECTOR_REGULAR.
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
---
arch/arm/configs/msm_defconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
index 0219c65..d61d5bb 100644
--- a/arch/arm/configs/msm_defconfig
+++ b/arch/arm/configs/msm_defconfig
@@ -12,6 +12,7 @@ CONFIG_EMBEDDED=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_KPROBES=y
+CONFIG_CC_STACKPROTECTOR_REGULAR=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
@@ -27,7 +28,6 @@ CONFIG_AEABI=y
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
CONFIG_CLEANCACHE=y
-CONFIG_CC_STACKPROTECTOR=y
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_VFP=y
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V2] arm64: add DSB after icache flush in __flush_icache_all()
From: Nicolas Pitre @ 2014-01-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130180706.GO7575@mudshark.cambridge.arm.com>
On Thu, 30 Jan 2014, Will Deacon wrote:
> On Thu, Jan 30, 2014 at 06:04:43AM +0000, Vinayak Kale wrote:
> > On Tue, Jan 28, 2014 at 9:44 PM, Will Deacon <will.deacon@arm.com> wrote:
> > > On Tue, Jan 28, 2014 at 07:06:53AM +0000, Vinayak Kale wrote:
> > >> V2: - Add more desciption in the commit message as suggested by Catalin & Will
> > >> - Use 'memory' clobber for flush instruction as suggested by Will
> > >
> > > Please can you check and fix other occurrences of this bug too, as I asked
> > > in v1? For example, a 2 second grep shows problems with data-cache
> > > maintenance in kvm. I can also see the same problem for system register
> > > writes followed up with isb.
> > 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.
Nicolas
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with Linus' tree
From: Mike Turquette @ 2014-01-30 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGa+x85md++qtw5n7c_4L-MvaK8nB3c8GpFf+OLb4p--8N=+og@mail.gmail.com>
On Wed, Jan 29, 2014 at 9:33 PM, Kevin Hilman <khilman@linaro.org> wrote:
> On Wed, Jan 29, 2014 at 4:19 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> Today's linux-next merge of the arm-soc tree got a conflict in
>> drivers/clk/Makefile between commit fd3fdaf09f26 ("clk: sort Makefile")
>> from Linus' tree and commit 7ee2c5117483 ("clk: bcm281xx: add initial
>> clock framework support") from the arm-soc tree.
>
> Ugh. Looks like some last minute cleanup stuff went into clk-next
> that didn't spend time in linux-next, and now causes conflicts with
> some clk stuff we still have queued in arm-soc (ack'd by Mike.)
>
> Now, based on the Hulk's response to Mike's pull request, if we submit
> this, introducing yet more conflicts in the Makefile, it will surely
> be Hulk angry, Hulk smash.
Well this is clearly my fault. Please place appropriate blame on me
for sneaking in that Makefile cleanup.
/me prepares to be smashed.
Regards,
Mike
>
> Kevin
^ permalink raw reply
* [PATCH 0/3] RFC/RFT: Powering on MMC Wifi/BT modules in MMC core
From: Russell King - ARM Linux @ 2014-01-30 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390190215-22700-1-git-send-email-olof@lixom.net>
On Sun, Jan 19, 2014 at 07:56:52PM -0800, Olof Johansson wrote:
> This is a small series enhancing the MMC core code to power on modules
> before the host in cases where needed, and the corresponding DT bindings
> changes.
>
> I've got some other issues to debug on the Chromebook, i.e. the interface
> doens't actually work. So far it seems unrelated to this patch set so
> it's worth posting this and get things going since others need the same
> functionality (i.e Cubox-i).
>
> As mentioned in the patch in the series, I haven't implemented power-down
> yet, I wanted to make sure that the power-on side will be adequate for
> those who are looking to use it right away.
>
> Comments/test reports/etc welcome.
So, I thought I'd give this a go on the Cubox-i4, and... it doesn't work
there. It's not your patches, it's down to sdhci-esdhc-imx.c not using
mmc_of_parse() at all, so those new properties have no way to be used
there.
It doesn't look like it could in its current form use mmc_of_parse(),
as the imx code manually parses some of the generic properties to hand
them into the sdhci layer. This looks icky, and it looks like something
that should be fixed - why should drivers be parsing the core attributes
themselves?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ 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
* [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: 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: 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 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 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 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
* 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] 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
* [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
* 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 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
* [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 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
* [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
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