* [PATCH] ARM: dts: sun8i: fix the pinmux for UART1
From: Icenowy Zheng @ 2016-10-24 17:08 UTC (permalink / raw)
To: linux-arm-kernel
When the patch is applied, the allwinner,driver and allwinner,pull
properties are removed.
Although they're described to be optional in the devicetree binding,
without them, the pinmux cannot be initialized, and the uart cannot
be used.
Add them back to fix the problem, and makes the bluetooth on iNet D978
Rev2 board work.
Fixes: 82eec384249f (ARM: dts: sun8i: add pinmux for UART1 at PG)
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
This patch is targeted on 4.9.
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 48fc24f..300a1bd 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -282,11 +282,15 @@
uart1_pins_a: uart1 at 0 {
allwinner,pins = "PG6", "PG7";
allwinner,function = "uart1";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
uart1_pins_cts_rts_a: uart1-cts-rts at 0 {
allwinner,pins = "PG8", "PG9";
allwinner,function = "uart1";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
mmc0_pins_a: mmc0 at 0 {
--
2.10.1
^ permalink raw reply related
* [PATCH V4 09/10] trace, ras: add ARM processor error trace event
From: Baicar, Tyler @ 2016-10-24 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021163410.0a827eab@gandalf.local.home>
On 10/21/2016 2:34 PM, Steven Rostedt wrote:
> On Fri, 21 Oct 2016 11:30:12 -0600
> Tyler Baicar <tbaicar@codeaurora.org> wrote:
>
>> Currently there are trace events for the various RAS
>> errors with the exception of ARM processor type errors.
>> Add a new trace event for such errors so that the user
>> will know when they occur. These trace events are
>> consistent with the ARM processor error section type
>> defined in UEFI 2.6 spec section N.2.4.4.
>>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Tracing part looks fine to me.
>
> Acked-by: Steven Rostedt <rostedt@goodmis.org>
>
> -- Steve
Thank you Steve!
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* Question about arm64 earlycon
From: Duc Dang @ 2016-10-24 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024110904.GF15620@leverpostej>
On Mon, Oct 24, 2016 at 4:09 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Mon, Oct 24, 2016 at 11:17:36AM +0100, Marc Zyngier wrote:
> > On 24/10/16 11:06, Arnd Bergmann wrote:
> > > On Sunday, October 23, 2016 12:26:59 AM CEST Duc Dang wrote:
> > >> Hi Catalin, Marc, Mark, Arnd,
> > >>
> > >> I am testing with 3.12 kernel with earlyprintk enabled and I see some
> > >> garbage characters in the console log right before the message
> > >> indicating that the real console device is initialized:
>
> What exactly are you passing on the command line?
This is what I have:
earlyprintk=uart8250-32bit,0x1c020000
I should be more specific: the early console prints characters just
fine (I see all the early boot log). Only at the moment before
switching to the real console, I occasionally see some garbage
characters.
>
> > >> <some garbage characters here>01c020000.serial: ttyS0 at MMIO
> > >> 0x1c020000 (irq = 108, base_baud = 3125000) is a U6_16550A
> > >> console [ttyS0] enabled, bootconsole disabled
>
> Was the UART already configured by FW? Had the firmware output anything
> at this point?
Yes, UART was already configured by FW (U-Boot) and at this point,
U-Boot is already gone.
>
> Did the firmware's UART rate match that of the kernel? If not, the issue
> might just be that the rate doesn't match; earlycon/earlyprintk won't
> configure that, while the real console will.
The baud-rate does not change between U-Boot and kernel.
>
> Or perhaps we race with some clock configuration...
>
> > >> I looked through early_prink.c file and printk.c file and it looks
> > >> like there is case that some early boot code can touch the UART
> > >> hardware via ealy console driver while the 'real' console driver is
> > >> setting up the same UART port? Please let me know if I missed some
> > >> important piece of code that can prevent this.
> > >
> > > I don't think we every supported earlyprintk on arm64, and
> > > earlycon support may have been added later.
> >
> > We did support some form of earlyprintk for a while (though not in the
> > same way as 32bit ARM does), until Rob introduced earlycon.
>
> Our earlyprintk up until that point was effectively a less general
> earlycon (coming up at a similar time). In fact, in v3.12 we were
> already using earlycon structures in arch/arm64/kernel/early_printk.c.
Yes, early_printk.c for arm64 is supported until Rob removed it and
replaced by earlycon at kernel v3.16
>
> Thanks,
> Mark.
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH v3 3/8] PM / Domains: Allow domain power states to be read from DT
From: Sudeep Holla @ 2016-10-24 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024164846.GE72940@linaro.org>
On 24/10/16 17:48, Lina Iyer wrote:
> Hi Sudeep,
>
> On Mon, Oct 24 2016 at 07:39 -0600, Sudeep Holla wrote:
>>
>>
>> On 14/10/16 18:47, Lina Iyer wrote:
>>> This patch allows domains to define idle states in the DT. SoC's can
>>> define domain idle states in DT using the "domain-idle-states" property
>>> of the domain provider. Add API to read the idle states from DT that can
>>> be set in the genpd object.
>>>
>>> This patch is based on the original patch by Marc Titinger.
>>>
>>> Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>> ---
>>> drivers/base/power/domain.c | 94
>>> +++++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/pm_domain.h | 8 ++++
>>> 2 files changed, 102 insertions(+)
>>>
>>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>>> index 37ab7f1..9af75ba 100644
>>> --- a/drivers/base/power/domain.c
>>> +++ b/drivers/base/power/domain.c
>>> @@ -1916,6 +1916,100 @@ out:
>>> return ret ? -EPROBE_DEFER : 0;
>>> }
>>> EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>>> +
>>> +static const struct of_device_id idle_state_match[] = {
>>> + { .compatible = "arm,idle-state", },
>>> + { }
>>> +};
>>> +
>>
>> I still think it's better to have another compatible to serve this
>> purpose. We don't want to end up creating genpd domains just because
>> they are "arm,idle-state" compatible IMO ?
>>
>> I agree you can prevent it checking for OSC mode support in the
>> firmware. But I want to understand if you have any strong reasons for
>> avoiding that approach.
>>
> Why are you still held up with OSI/PC PSCI modes?
I am just pointing that out to make sure you are not defining these
DT bindings with just QCOM platform and OSC in consideration.
I am thinking about how can it be used/extended in other use-cases.
> I repeat again this
> series is not about any of that, it is just about PM domains.
I completely understand that, no argument on that. What I worry is that
if a system(in future) represents this power domains and domain idles
states and doesn't want to create a genpd, do we have to handle it
differently or even the way your CPUidle series would do or can we say
those states need to specify that they are compatible with the new
feature(the one being added in this series) with a new compatible.
I prefer the latter than the former to avoid all possible workarounds
in future.
> PM domains
> have idle states and the idle-state description is similar in definition
> to arm,idle-state and therefore uses the same compatible. There is no
> point re-defining something that already exists in the kernel.
>
Yes I understand that but "arm,idle-states" were not defined with this
feature in mind and hence I am bit worried if it could cause any issue
especially if deprecate cpu-idle-states and move to this model
completely. I really don't like this mix and hence I am raising the
concern here. I am trying to ease that migration.
> I was able to find the original thread, where we discussed this [1].
>
> I suggest, you read about PM domains and its idle states and understand
> this series in the context of PM domains.
>
Sure, will do that. Thanks for pointing that out. But the concern I am
raising is entirely different. I am asking if this re-use will cause any
issue in future as pointed out above.
I re-iterate that I understand this series is independent of the CPUIdle
and hence asking why not make it completely independent by just adding
the new compatible.
I am *not asking to redefine something completely*. What I am saying is
*just* to add new compatible that may(for cpu devices)/may not(for
other/non-CPU devices) be used along with "arm,idle-state".
I may be too paranoid here but I think that's safer. It helps to skip
creating of genpd if required for some domains as I had explained before.
--
Regards,
Sudeep
^ permalink raw reply
* Question about arm64 earlycon
From: Duc Dang @ 2016-10-24 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f1eeb4a-925a-9fac-d442-fbee503deb0a@arm.com>
On Mon, Oct 24, 2016 at 3:17 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 24/10/16 11:06, Arnd Bergmann wrote:
>> On Sunday, October 23, 2016 12:26:59 AM CEST Duc Dang wrote:
>>> Hi Catalin, Marc, Mark, Arnd,
>>>
>>> I am testing with 3.12 kernel with earlyprintk enabled and I see some
>>> garbage characters in the console log right before the message
>>> indicating that the real console device is initialized:
>>>
>>> <some garbage characters here>01c020000.serial: ttyS0 at MMIO
>>> 0x1c020000 (irq = 108, base_baud = 3125000) is a U6_16550A
>>> console [ttyS0] enabled, bootconsole disabled
>
> Well, you get two independent, unsynchronized bits of code writing to
> the same peripheral. Things are bound to go badly. Unless you're trying
> to debug things, do not use earlyprintk in production.
This is what I am testing for now: not passing earlyprintk parameter,
and I don't see any weird character.
Is it also true about earlycon? We should not use either earlyprintk
(already gone long time ago) or earlycon for production?
>
>>>
>>> I looked through early_prink.c file and printk.c file and it looks
>>> like there is case that some early boot code can touch the UART
>>> hardware via ealy console driver while the 'real' console driver is
>>> setting up the same UART port? Please let me know if I missed some
>>> important piece of code that can prevent this.
>>
>> I don't think we every supported earlyprintk on arm64, and
>> earlycon support may have been added later.
>
> We did support some form of earlyprintk for a while (though not in the
> same way as 32bit ARM does), until Rob introduced earlycon.
>
>> If you can't use a modern kernel, try backporting all the
>> relevant earlycon changes.
>
> Agreed. That's the most sensible course of action.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
Regards,
Duc Dang.
^ permalink raw reply
* [RFC] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-10-24 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024170035.GO15620@leverpostej>
Hi Mark,
Mark Rutland <mark.rutland@arm.com> writes:
> On Mon, Oct 24, 2016 at 06:46:36PM +0200, Bartosz Golaszewski wrote:
>> Create a new driver for the da8xx DDR2/mDDR controller and implement
>> support for writing to the Peripheral Bus Burst Priority Register.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> .../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++
>> drivers/memory/Kconfig | 8 +
>> drivers/memory/Makefile | 1 +
>> drivers/memory/da8xx-ddrctl.c | 187 +++++++++++++++++++++
>> 4 files changed, 216 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> create mode 100644 drivers/memory/da8xx-ddrctl.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> new file mode 100644
>> index 0000000..f0eda59
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> @@ -0,0 +1,20 @@
>> +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
>> +
>> +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs memory
>> +maps a set of registers which allow to tweak the controller's behavior.
>
> This is a description of the *driver*. The device itself doesn't map
> some registers, it features them. Please descrive the *device*.
>
>> +
>> +Documentation:
>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> +
>> +Required properties:
>> +
>> +- compatible: "ti,da850-ddrctl" - for da850 SoC based boards
>
> Perhaps:
>
> "ti,da850-ddr-controller"
>
>> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
>> +{
>> + const struct da8xx_ddrctl_config_knob *knob;
>> + const struct da8xx_ddrctl_setting *setting;
>> + u32 regprop[2], base, memsize, reg;
>> + struct device_node *node, *parent;
>> + void __iomem *ddrctl;
>> + const char *board;
>> + struct device *dev;
>> + int ret;
>> +
>> + dev = &pdev->dev;
>> + node = dev->of_node;
>> +
>> + /* Find the board name. */
>> + for (parent = node;
>> + !of_node_is_root(parent);
>> + parent = of_get_parent(parent));
>> +
>> + ret = of_property_read_string(parent, "compatible", &board);
>> + if (ret) {
>> + dev_err(dev, "unable to read the soc model\n");
>> + return ret;
>> + }
>
> I can see that you want to expose sysfs knobs for this, but is it really
> necessary to match boards like this? It's very fragile, and commits us
> to maintaining a database of board data (i.e. a board file).
>
> I am very much not keen on that.
The original proposal[1] was to create DT properties reflecting the
various knobs in the DDR Controller, but that was frowned upon since
that was more HW configuration than hardware description.
That resulted in this approach which keeps the HW configuration values
in the driver, and selectable based on DT compatible.
IMO, neither aproach is pretty. From a DT maintainer perspective, can
you comment on your preference?
Thanks,
Kevin
[1] https://marc.info/?l=linux-arm-kernel&m=147672200715076&w=2
^ permalink raw reply
* [PATCH 00/10] arm64: move thread_info off of the task stack
From: Laura Abbott @ 2016-10-24 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476904234-9511-1-git-send-email-mark.rutland@arm.com>
On 10/19/2016 12:10 PM, Mark Rutland wrote:
> Hi all,
>
> Building atop of Andy's work on x86 and generic code, these patches move
> arm64's thread_info off of the stack and into task_struct. This protects
> thread_info from corruption in the face of stack overflow, and serves as
> a step towards fully robust stack overflow handling, which will be
> addressed by subsequent patches.
>
> These patches are based atop of a preparatory series [1] (itself based
> on v4.9-rc1) that's also necessary for s390. I've placed those patches
> in a branch [2] on my kernel.org repo, along with this series [3]. I'm
> hoping that the prep work will be able to become a stable branch/tag
> soon.
>
> I've given the series some light testing on a couple of SMP arm64
> platforms, but this has yet to see a thorough beating; please do try to
> make this fall over!
>
> Since RFC [4]:
> * Rely on prior patches to make thread_info arch-specific
> * Make smp_processor_id() use a per-cpu variable
> * Split out current_stack_pointer
> * Make SMP actually work
>
> [1] http://lkml.kernel.org/r/1476901693-8492-1-git-send-email-mark.rutland at arm.com
> [2] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=core/ti-stack-split
> [3] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=arm64/ti-stack-split
> [4] http://lkml.kernel.org/r/1473947349-14521-1-git-send-email-mark.rutland at arm.com
>
> Thanks,
> Mark.
>
> Mark Rutland (10):
> arm64: thread_info remove stale items
> arm64: asm-offsets: remove unused definitions
> arm64: factor out current_stack_pointer
> arm64: traps: simplify die() and __die()
> arm64: prep stack walkers for THREAD_INFO_IN_TASK
> arm64: move sp_el0 and tpidr_el1 into cpu_suspend_ctx
> arm64: smp: prepare for smp_processor_id() rework
> arm64: make cpu number a percpu variable
> arm64: assembler: introduce ldr_this_cpu
> arm64: split thread_info from task stack
>
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/Kbuild | 1 -
> arch/arm64/include/asm/assembler.h | 19 +++++++++++++++----
> arch/arm64/include/asm/current.h | 22 ++++++++++++++++++++++
> arch/arm64/include/asm/percpu.h | 2 ++
> arch/arm64/include/asm/perf_event.h | 2 ++
> arch/arm64/include/asm/smp.h | 7 ++++++-
> arch/arm64/include/asm/stack_pointer.h | 9 +++++++++
> arch/arm64/include/asm/suspend.h | 2 +-
> arch/arm64/include/asm/thread_info.h | 32 +-------------------------------
> arch/arm64/kernel/asm-offsets.c | 3 +--
> arch/arm64/kernel/entry.S | 6 +++---
> arch/arm64/kernel/head.S | 11 ++++++-----
> arch/arm64/kernel/process.c | 33 +++++++++++++++++++++++++++------
> arch/arm64/kernel/return_address.c | 1 +
> arch/arm64/kernel/sleep.S | 3 ---
> arch/arm64/kernel/smp.c | 14 +++++++++++---
> arch/arm64/kernel/stacktrace.c | 6 ++++++
> arch/arm64/kernel/suspend.c | 6 ------
> arch/arm64/kernel/traps.c | 14 +++++++-------
> arch/arm64/mm/proc.S | 6 ++++++
> 21 files changed, 127 insertions(+), 73 deletions(-)
> create mode 100644 arch/arm64/include/asm/current.h
> create mode 100644 arch/arm64/include/asm/stack_pointer.h
>
I pulled the arm64/ti-stack-split branch on top of a Fedora
tree and ran back-to-back kernel RPM builds for a long weekend.
It's still going as of this morning so you can take that as a
Tested-by: Laura Abbott <labbott@redhat.com>
Thanks,
Laura
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Mark Rutland @ 2016-10-24 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161014075337.10452-1-hdegoede@redhat.com>
On Fri, Oct 14, 2016 at 09:53:31AM +0200, Hans de Goede wrote:
> Hi Rob, Mark, et al.,
Hi Hans,
Apologies for the delay in replying to this.
I'd like to be clear that I do understand that there is a problem that
needs to be addressed here. However, I do not believe that the *current*
in-kernel approach is correct. More on that below.
> Mark, I know that we discussed this at ELCE and you clearly indicated
> that according to you this does not belong in the kernel. I was a bit
> surprised by this part of the discussion.
>
> I had posted a RFC earlier and Rob had indicated that given that the q8
> tablets are a special case, as my code uses actual probing rather then some
> pre-arranged id mechanism with say an eeprom, that doing this in a
> non-generic manner would be ok for my special case.
To some extent, Rob and I may have differing views here; I'm not
entirely sure what Rob's view is, and I cannot talk on his behalf. I
certainly must apologise for having not commented on said RFC, however.
> So on to why I believe that the kernel is the best place to do this, at least
> for my special use-case:
>
> 1. Configurability
>
> Since the q8 tablets do not have any id mechanism I'm probing i2c busses to
> generate i2c client dt nodes with the right address and compatible.
> Some info in these nodes (e.g. touchscreen firmware-name) is not probable at
> all and gets set by heuristics. This heuristics may get things wrong.
> So my current implementation offers kernel cmdline options to override this.
As I mentioned at ELCE, one major concern I have with this approach is
this probing, which in part relies on a collection of heuristics.
I'm worried that this is very fragile, and sets us up for having to
maintain a much larger collection of heuristics and/or a database of
particular boards in future. This is fragile, defeats much of the gain
from DT.
Worse, this could be completely incompatible with some arbitrary board
that comes by in future, because the kernel assumed something that was
not true, which it would not have done if things were explicitly
described to the kernel.
As I mentioned at ELCE, I'm not opposed to the concept of the kernel
applying overlays or fixups based on a well-defined set of criteria;
having some of that embedded in the DT itself would be remarkably
helpful. However, I am very much not keen on loosely defined criteria as
with here, as it couples the DT and kernel, and creates problems longer
term, as described above.
> Although having to specify kernel cmdline options is not the plug and play
> experience I want to give end-users most distros do have documentation on
> how to do this and doing this is relatively easy for end-users. Moving this
> to the bootloader means moving to some bootloader specific config mechanism
> which is going to be quite hard (and possibly dangerous) for users to use.
I have to ask, why is it more dangerous?
Perhaps more difficult, but that can be solved, if the manual
corrections are simply a set of options to be passed to the kernel, I
don't see why the bootloader cannot pick this up.
> 2. Upgradability
>
> Most users treat the bootloader like they treat an x86 machine BIOS/EFI,
> they will never upgrade it unless they really have to. This means that it
> will be very difficult to get users to actual benefit from bug-fixes /
> improvements done to the probing code. Where as the kernel on boards running
> e.g. Debian or Fedora gets regular updates together with the rest of the
> system.
Given that DTBs are supposed to remain supported, users should find
themselves with a system that continues to work, but may not have all
the bells and whistles it could, much like elsewhere.
While it's true that we have issues in this area, I don't think that's
an argument for putting things into the kernel for this specific set of
boards.
> 3. Infrastructure
>
> The kernel simply has better infrastructure for doing these kind of things.
At least on the DT front, a lot of work has gone into improving the
infrastructure, e.g. the work that Free Electrons have done [1]. I
appreciate that the infrastructure for things like poking SPI may not be
as advanced.
Which bits of infrastructure do you find lacking today?
> Yes we could improve the bootloader, but the kernel is also improving
> and likely at a faster rate. Besides that the purpose of the
> bootloader is mostly to be simple and small, load the kernel and get
> out of the way, not to be a general purpose os kernel. So it will
> simply always have less infrastructure and that is a good thing,
> otherwise we will be writing another general purpose os which is a
> waste of effort.
I think this conflates a number of details. Yes, we'd like firmware and
bootloaders to be small, and yes, their infrastructure and feature
support will be smaller than a general purpose OS.
That doesn't imply that they cannot have features necessary to boostrap
an OS.
It's also not strictly necessary that the firmware or bootloader have
the capability to do all this probing, as that could be contained in
another part (e.g. a U-Boot application which is run once to detect the
board details, logging this into a file).
It's also possible to ship an intermediary stage (e.g. like the
impedance matcher) which can be upgradeable independently of the kernel.
> 4. This is not a new board file
>
> Mark, at ELCE I got the feeling that your biggest worry / objection is
> that this will bring back board files, but that is not the case, if you
> look at the actual code it is nothing like a board-file at all. Where a
> board file was instantiating device after device after device from c-code,
> with maybe a few if-s in there to deal with board revisions. This code is
> all about figuring out which accelerometer and touchscreen there are,
> to then add nodes to the dt for this 2 devices, almost all the code is
> probing, the actual dt modifying code is tiny and no direct device
> instantiation is done at all.
Sorry, but I must disagree. This code:
(a) identifies a set of boards based on a top-level compatible string.
i.e. it's sole purpose is to handle those boards.
(b) assumes non-general properties of those boards (e.g. that poking
certain SPI endpoints is safe).
(c) applies arbitrary properties to the DT, applying in-built knowledge
of those boards (in addition to deep structural knowledge of the
DTB in question).
To me, given the implicit knowledge, that qualifies as a "board file".
As I mentioned at ELCE, if this had no knowledge of the boards in
question, I would be less concerned. e.g. if there was a well-defined
identification mechanism, describe in the DT, with fixups also defined
in the DT.
> 5. This is an exception, not the rule
>
> Yes this is introducing board (family of boards) specific c-code into the
> kernel, so in a way it is reminiscent of board files. But sometimes this is
> necessary, just look at all the vendor / platform specific code in the kernel
> in drivers/platform/x86, or all the places where DMI strings are used to
> uniquely identify a x86 board and adjust behavior.
>
> But this really is the exception, not the rule. I've written/upstreamed a
> number of drivers for q8 tablets hardware and if you look at e.g. the
> silead touchscreen driver then in linux-next this is already used for 5
> ARM dts files where no board specific C-code is involved at all.
>
> So this again is very different from the board file era, where C-code
> had to be used to fill device specific platform-data structs, here all
> necessary info is contained in the dt-binding and there are many users
> who do not need any board specific C-code in the kernel at all.
>
> So dt is working as it should and is avoiding board specific C-code for
> the majority of the cases. But sometimes hardware is not as we ideally
> would like it to be; and for those *exceptions* we are sometimes going
> to need C-code in the kernel, just like there is "board" specific C-code
> in the x86 code.
Your talk convinced me that we're both going to see more variation
within this family of boards, and that we'll see more families of boards
following a similar patter. Given that, I think that we need a more
general solution, as I commented on the RFC.
That doesn't necessarily mean that this can't happen in the kernel, but
it certainly needs to be more strictly defined, e.g. with match criteria
and fixups explicit in the DTB.
Thanks,
Mark.
[1] http://free-electrons.com/blog/dt-overlay-uboot-libfdt/
[2] https://github.com/zonque/pxa-impedance-matcher
^ permalink raw reply
* [PATCH v3 3/8] PM / Domains: Allow domain power states to be read from DT
From: Sudeep Holla @ 2016-10-24 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024164846.GE72940@linaro.org>
On 24/10/16 17:48, Lina Iyer wrote:
> Hi Sudeep,
[..]
>
> I was able to find the original thread, where we discussed this [1].
>
> [1]. http://www.serverphorums.com/read.php?12,1303996
>
I went through the discussion and that's valid discussion and I agree.
But what am looking for is backward compatibility and not exactly same
as the discussion and I agree that can be solved in different way.
I just feel that's one easily way to solve such issues. I am open to
suggestions.
--
Regards,
Sudeep
^ permalink raw reply
* [RFC] ARM: memory: da8xx-ddrctl: new driver
From: Mark Rutland @ 2016-10-24 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hd1ipzm3h.fsf@baylibre.com>
On Mon, Oct 24, 2016 at 10:35:30AM -0700, Kevin Hilman wrote:
> Hi Mark,
>
> Mark Rutland <mark.rutland@arm.com> writes:
> > On Mon, Oct 24, 2016 at 06:46:36PM +0200, Bartosz Golaszewski wrote:
> >> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
> >> +{
> >> + const struct da8xx_ddrctl_config_knob *knob;
> >> + const struct da8xx_ddrctl_setting *setting;
> >> + u32 regprop[2], base, memsize, reg;
> >> + struct device_node *node, *parent;
> >> + void __iomem *ddrctl;
> >> + const char *board;
> >> + struct device *dev;
> >> + int ret;
> >> +
> >> + dev = &pdev->dev;
> >> + node = dev->of_node;
> >> +
> >> + /* Find the board name. */
> >> + for (parent = node;
> >> + !of_node_is_root(parent);
> >> + parent = of_get_parent(parent));
> >> +
> >> + ret = of_property_read_string(parent, "compatible", &board);
> >> + if (ret) {
> >> + dev_err(dev, "unable to read the soc model\n");
> >> + return ret;
> >> + }
> >
> > I can see that you want to expose sysfs knobs for this, but is it really
> > necessary to match boards like this? It's very fragile, and commits us
> > to maintaining a database of board data (i.e. a board file).
> >
> > I am very much not keen on that.
>
> The original proposal[1] was to create DT properties reflecting the
> various knobs in the DDR Controller, but that was frowned upon since
> that was more HW configuration than hardware description.
>
> That resulted in this approach which keeps the HW configuration values
> in the driver, and selectable based on DT compatible.
>
> IMO, neither aproach is pretty. From a DT maintainer perspective, can
> you comment on your preference?
>From my PoV, it really depends on *why* we need this. What does the
tuning gain us, and is it specific to a given use-case?
Thanks,
Mark.
^ permalink raw reply
* [PATCH/RFT v2 09/17] regulator: fixed: Add over current event
From: Mark Brown @ 2016-10-24 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-10-ahaslam@baylibre.com>
On Mon, Oct 24, 2016 at 06:46:26PM +0200, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> Some regulator supplies have an over-current pin that is
> activated when the hw detects an over current condition.
> When this happens, the hardware enters a current limited
> mode.
Please don't mix random enhancements like this into bigger system
specific RFC serieses, send them separately so they're easier to spot
and there's no confusion with dependencies and then reference them from
the system specific series when you post that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/3b2c6d6b/attachment.sig>
^ permalink raw reply
* [GIT PULL] Broadcom ARM64 Device Tree fixes for 4.9
From: Florian Fainelli @ 2016-10-24 17:43 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.9/devicetree-arm64-fixes
for you to fetch changes up to 963d790468a2f581abf039b45edac79af5e16e55:
arm64: dts: Updated NAND DT properties for NS2 SVK (2016-10-23 14:50:20 -0700)
----------------------------------------------------------------
This pull request contains a single fix for Broadcom ARM64-based SoCs:
- Ray adds the required bus width and OOB sector size properties to the
Northstar 2 SVK reference board in order for the NAND controller to work
properly
----------------------------------------------------------------
Ray Jui (1):
arm64: dts: Updated NAND DT properties for NS2 SVK
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 2 ++
1 file changed, 2 insertions(+)
^ permalink raw reply
* [PATCH 00/10] arm64: move thread_info off of the task stack
From: Mark Rutland @ 2016-10-24 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10401f46-cabc-23ec-a448-c377dbce7911@redhat.com>
On Mon, Oct 24, 2016 at 10:38:59AM -0700, Laura Abbott wrote:
> On 10/19/2016 12:10 PM, Mark Rutland wrote:
> >Hi all,
> >
> >Building atop of Andy's work on x86 and generic code, these patches move
> >arm64's thread_info off of the stack and into task_struct. This protects
> >thread_info from corruption in the face of stack overflow, and serves as
> >a step towards fully robust stack overflow handling, which will be
> >addressed by subsequent patches.
> >
> >These patches are based atop of a preparatory series [1] (itself based
> >on v4.9-rc1) that's also necessary for s390. I've placed those patches
> >in a branch [2] on my kernel.org repo, along with this series [3]. I'm
> >hoping that the prep work will be able to become a stable branch/tag
> >soon.
> >
> >I've given the series some light testing on a couple of SMP arm64
> >platforms, but this has yet to see a thorough beating; please do try to
> >make this fall over!
> >
> >Since RFC [4]:
> >* Rely on prior patches to make thread_info arch-specific
> >* Make smp_processor_id() use a per-cpu variable
> >* Split out current_stack_pointer
> >* Make SMP actually work
> >
> >[1] http://lkml.kernel.org/r/1476901693-8492-1-git-send-email-mark.rutland at arm.com
> >[2] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=core/ti-stack-split
> >[3] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=arm64/ti-stack-split
> >[4] http://lkml.kernel.org/r/1473947349-14521-1-git-send-email-mark.rutland at arm.com
> I pulled the arm64/ti-stack-split branch on top of a Fedora
> tree and ran back-to-back kernel RPM builds for a long weekend.
> It's still going as of this morning so you can take that as a
>
> Tested-by: Laura Abbott <labbott@redhat.com>
Thanks! That's much appreciated!
Just to check, did you grab the version with entry.S fixes rolled in
(where the head is 657f54256c427fec)?
Thanks,
Mark.
^ permalink raw reply
* [PATCH/RFT v2 09/17] regulator: fixed: Add over current event
From: Mark Brown @ 2016-10-24 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-10-ahaslam@baylibre.com>
On Mon, Oct 24, 2016 at 06:46:26PM +0200, ahaslam at baylibre.com wrote:
> + if (ret) {
> + pr_err("Failed to request irq: %d\n", ret);
dev_err()
> +++ b/include/linux/regulator/consumer.h
> @@ -74,6 +74,10 @@
> * the most noisy and may not be able to handle fast load
> * switching.
> *
> + * OVERCURRENT Regulator has detected an overcurrent condition, and
> + * may be limiting the supply output.
> + *
> + *
> * NOTE: Most regulators will only support a subset of these modes. Some
> * will only just support NORMAL.
> *
> @@ -84,6 +88,7 @@
> #define REGULATOR_MODE_NORMAL 0x2
> #define REGULATOR_MODE_IDLE 0x4
> #define REGULATOR_MODE_STANDBY 0x8
> +#define REGULATOR_MODE_OVERCURRENT 0x10
This is adding a new core feature with a new mode and should have been
split out of the driver specific change with a spearate changelog. Why
does it make sense to report this as a mode, we don't report other error
conditions as modes but instead use REGULATOR_STATUS_ with the
get_status() operation?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/f2f48bdd/attachment.sig>
^ permalink raw reply
* [PATCH/RFT v2 09/17] regulator: fixed: Add over current event
From: Axel Haslam @ 2016-10-24 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024174322.GN17252@sirena.org.uk>
Hi Mark,
On Mon, Oct 24, 2016 at 7:43 PM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Oct 24, 2016 at 06:46:26PM +0200, ahaslam at baylibre.com wrote:
>> From: Axel Haslam <ahaslam@baylibre.com>
>>
>> Some regulator supplies have an over-current pin that is
>> activated when the hw detects an over current condition.
>> When this happens, the hardware enters a current limited
>> mode.
>
> Please don't mix random enhancements like this into bigger system
> specific RFC serieses, send them separately so they're easier to spot
> and there's no confusion with dependencies and then reference them from
> the system specific series when you post that.
Ok, sorry i had mixed feelings on how to post all of it.
there are several dependencies on the series and i kept
all together to give the context. Do you want me to repost the regulator
changes seperatly? I can do that, but if you don't agree with regulator
handling overcurrent, i will have to move the over current
gpio into the driver, and there is no point on re-posting that seperatly.
Regards
Axel
^ permalink raw reply
* [PATCH 00/10] arm64: move thread_info off of the task stack
From: Laura Abbott @ 2016-10-24 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024174840.GR15620@leverpostej>
On 10/24/2016 10:48 AM, Mark Rutland wrote:
> On Mon, Oct 24, 2016 at 10:38:59AM -0700, Laura Abbott wrote:
>> On 10/19/2016 12:10 PM, Mark Rutland wrote:
>>> Hi all,
>>>
>>> Building atop of Andy's work on x86 and generic code, these patches move
>>> arm64's thread_info off of the stack and into task_struct. This protects
>>> thread_info from corruption in the face of stack overflow, and serves as
>>> a step towards fully robust stack overflow handling, which will be
>>> addressed by subsequent patches.
>>>
>>> These patches are based atop of a preparatory series [1] (itself based
>>> on v4.9-rc1) that's also necessary for s390. I've placed those patches
>>> in a branch [2] on my kernel.org repo, along with this series [3]. I'm
>>> hoping that the prep work will be able to become a stable branch/tag
>>> soon.
>>>
>>> I've given the series some light testing on a couple of SMP arm64
>>> platforms, but this has yet to see a thorough beating; please do try to
>>> make this fall over!
>>>
>>> Since RFC [4]:
>>> * Rely on prior patches to make thread_info arch-specific
>>> * Make smp_processor_id() use a per-cpu variable
>>> * Split out current_stack_pointer
>>> * Make SMP actually work
>>>
>>> [1] http://lkml.kernel.org/r/1476901693-8492-1-git-send-email-mark.rutland at arm.com
>>> [2] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=core/ti-stack-split
>>> [3] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=arm64/ti-stack-split
>>> [4] http://lkml.kernel.org/r/1473947349-14521-1-git-send-email-mark.rutland at arm.com
>
>> I pulled the arm64/ti-stack-split branch on top of a Fedora
>> tree and ran back-to-back kernel RPM builds for a long weekend.
>> It's still going as of this morning so you can take that as a
>>
>> Tested-by: Laura Abbott <labbott@redhat.com>
>
> Thanks! That's much appreciated!
>
> Just to check, did you grab the version with entry.S fixes rolled in
> (where the head is 657f54256c427fec)?
Ah I did not. That came in after I started the test. I'll start
another run with the new version.
>
> Thanks,
> Mark.
>
Thanks,
Laura
^ permalink raw reply
* Applied "ASoC: rockchip: constify snd_soc_ops structures" to the asoc tree
From: Mark Brown @ 2016-10-24 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476543351-17858-4-git-send-email-Julia.Lawall@lip6.fr>
The patch
ASoC: rockchip: constify snd_soc_ops structures
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 705e9994a437bbdaf655612f3526e3567db56bdd Mon Sep 17 00:00:00 2001
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Sat, 15 Oct 2016 16:55:47 +0200
Subject: [PATCH] ASoC: rockchip: constify snd_soc_ops structures
Check for snd_soc_ops structures that are only stored in the ops field of a
snd_soc_dai_link structure. This field is declared const, so snd_soc_ops
structures that have this property can be declared as const also.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_soc_ops i at p = { ... };
@ok1@
identifier r.i;
struct snd_soc_dai_link e;
position p;
@@
e.ops = &i at p;
@ok2@
identifier r.i, e;
position p;
@@
struct snd_soc_dai_link e[] = { ..., { .ops = &i at p, }, ..., };
@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_soc_ops e;
@@
e at i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct snd_soc_ops i = { ... };
// </smpl>
The effect on the layout of the .o files is shown by the following output
of the size command, first before then after the transformation:
text data bss dec hex filename
5027 2488 416 7931 1efb sound/soc/rockchip/rk3399_gru_sound.o
5219 2312 416 7947 1f0b sound/soc/rockchip/rk3399_gru_sound.o
text data bss dec hex filename
3499 1648 384 5531 159b sound/soc/rockchip/rockchip_max98090.o
3563 1584 384 5531 159b sound/soc/rockchip/rockchip_max98090.o
text data bss dec hex filename
3455 1536 384 5375 14ff sound/soc/rockchip/rockchip_rt5645.o
3519 1480 384 5383 1507 sound/soc/rockchip/rockchip_rt5645.o
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/rockchip/rk3399_gru_sound.c | 6 +++---
sound/soc/rockchip/rockchip_max98090.c | 2 +-
sound/soc/rockchip/rockchip_rt5645.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
index 0cbd23555ba4..3475c61a5fa0 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -228,15 +228,15 @@ static int rockchip_sound_da7219_init(struct snd_soc_pcm_runtime *rtd)
return 0;
}
-static struct snd_soc_ops rockchip_sound_max98357a_ops = {
+static const struct snd_soc_ops rockchip_sound_max98357a_ops = {
.hw_params = rockchip_sound_max98357a_hw_params,
};
-static struct snd_soc_ops rockchip_sound_rt5514_ops = {
+static const struct snd_soc_ops rockchip_sound_rt5514_ops = {
.hw_params = rockchip_sound_rt5514_hw_params,
};
-static struct snd_soc_ops rockchip_sound_da7219_ops = {
+static const struct snd_soc_ops rockchip_sound_da7219_ops = {
.hw_params = rockchip_sound_da7219_hw_params,
};
diff --git a/sound/soc/rockchip/rockchip_max98090.c b/sound/soc/rockchip/rockchip_max98090.c
index e70ffad07184..789d6f1e2b5f 100644
--- a/sound/soc/rockchip/rockchip_max98090.c
+++ b/sound/soc/rockchip/rockchip_max98090.c
@@ -119,7 +119,7 @@ static int rk_aif1_hw_params(struct snd_pcm_substream *substream,
return ret;
}
-static struct snd_soc_ops rk_aif1_ops = {
+static const struct snd_soc_ops rk_aif1_ops = {
.hw_params = rk_aif1_hw_params,
};
diff --git a/sound/soc/rockchip/rockchip_rt5645.c b/sound/soc/rockchip/rockchip_rt5645.c
index 440a8026346a..9e0c17805807 100644
--- a/sound/soc/rockchip/rockchip_rt5645.c
+++ b/sound/soc/rockchip/rockchip_rt5645.c
@@ -135,7 +135,7 @@ static int rk_init(struct snd_soc_pcm_runtime *runtime)
&headset_jack);
}
-static struct snd_soc_ops rk_aif1_ops = {
+static const struct snd_soc_ops rk_aif1_ops = {
.hw_params = rk_aif1_hw_params,
};
--
2.8.1
^ permalink raw reply related
* Applied "ASoC: PXA: Brownstone needs I2C" to the asoc tree
From: Mark Brown @ 2016-10-24 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018151912.2742738-1-arnd@arndb.de>
The patch
ASoC: PXA: Brownstone needs I2C
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 5229f1f4a4585f503a0683575bf38d9a1d2c1982 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 18 Oct 2016 17:18:58 +0200
Subject: [PATCH] ASoC: PXA: Brownstone needs I2C
I rand into a new build error with SND_MMP_SOC_BROWNSTONE:
warning: (SND_MMP_SOC_BROWNSTONE && SND_SOC_SAMSUNG_SMDK_WM8994 && SND_SOC_SMDK_WM8994_PCM && SND_SOC_LITTLEMILL) selects MFD_WM8994 which has unmet direct dependencies (HAS_IOMEM && I2C)
drivers/mfd/wm8994-core.c:688:1: error: data definition has no type or storage class [-Werror]
drivers/mfd/wm8994-core.c:688:1: error: type defaults to 'int' in declaration of 'module_i2c_driver' [-Werror=implicit-int]
I don't see why this never showed up before, as the dependency seems to
have been missing since the symbol was first introduced several years
ago. This adds a dependency like the other drivers have.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/pxa/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index f2bf8661dd21..823b5a236d8d 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -208,7 +208,7 @@ config SND_PXA2XX_SOC_IMOTE2
config SND_MMP_SOC_BROWNSTONE
tristate "SoC Audio support for Marvell Brownstone"
- depends on SND_MMP_SOC && MACH_BROWNSTONE
+ depends on SND_MMP_SOC && MACH_BROWNSTONE && I2C
select SND_MMP_SOC_SSPA
select MFD_WM8994
select SND_SOC_WM8994
--
2.8.1
^ permalink raw reply related
* Applied "ASoC: rk3399_gru_sound: Fix non static symbol warning" to the asoc tree
From: Mark Brown @ 2016-10-24 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476717318-12684-1-git-send-email-weiyj.lk@gmail.com>
The patch
ASoC: rk3399_gru_sound: Fix non static symbol warning
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 818f76831992198121c8949789c71a1adb02e329 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Mon, 17 Oct 2016 15:15:18 +0000
Subject: [PATCH] ASoC: rk3399_gru_sound: Fix non static symbol warning
Fixes the following sparse warning:
sound/soc/rockchip/rk3399_gru_sound.c:41:14: warning:
symbol 'rt5514_dmic_delay' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/rockchip/rk3399_gru_sound.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
index 9ed735a6cf49..0cbd23555ba4 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -38,7 +38,7 @@
#define SOUND_FS 256
-unsigned int rt5514_dmic_delay;
+static unsigned int rt5514_dmic_delay;
static struct snd_soc_jack rockchip_sound_jack;
--
2.8.1
^ permalink raw reply related
* Question about arm64 earlycon
From: Mark Rutland @ 2016-10-24 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDk2pYMXQ-EYVw_vM23rsazFAHe_5qcjTajii13tRMD5Ew@mail.gmail.com>
On Mon, Oct 24, 2016 at 10:24:19AM -0700, Duc Dang wrote:
> On Mon, Oct 24, 2016 at 4:09 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Mon, Oct 24, 2016 at 11:17:36AM +0100, Marc Zyngier wrote:
> > > On 24/10/16 11:06, Arnd Bergmann wrote:
> > > > On Sunday, October 23, 2016 12:26:59 AM CEST Duc Dang wrote:
> > > >> Hi Catalin, Marc, Mark, Arnd,
> > > >>
> > > >> I am testing with 3.12 kernel with earlyprintk enabled and I see some
> > > >> garbage characters in the console log right before the message
> > > >> indicating that the real console device is initialized:
> >
> > What exactly are you passing on the command line?
>
> This is what I have:
> earlyprintk=uart8250-32bit,0x1c020000
>
> I should be more specific: the early console prints characters just
> fine (I see all the early boot log). Only at the moment before
> switching to the real console, I occasionally see some garbage
> characters.
Sorry, I managed to miss that previously. Sorry for the noise.
As Marc said, it sounds like the problem is the lack of synchronisation
between the drivers at hand-over time. Perhaps there's a FIFO still
draining, or the "real" driver doesn't put the UART in a quiescent state
before reinitialising it.
Generally earlycon/earlyprintk is there to debug early boot issues, and
is not there just to get UART output earlier. If you don't need to debug
an issue, turning it off will avoid problems.
If there's a simple change to the "real" driver init sequence to avoid
the temporary glitching, that would be great, but not many people are
going to care. We'd rather keep the earlycon code simple so as to ensure
we can use it to debug early boot failures.
Thanks,
Mark.
^ permalink raw reply
* Applied "ASoC: davinci-mcbsp: DT fix s/interrupts-names/interrupt-names/" to the asoc tree
From: Mark Brown @ 2016-10-24 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477039877-20227-5-git-send-email-geert+renesas@glider.be>
The patch
ASoC: davinci-mcbsp: DT fix s/interrupts-names/interrupt-names/
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a545f5d859c7988ab61850395a4565bfe507dc0a Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Fri, 21 Oct 2016 10:51:15 +0200
Subject: [PATCH] ASoC: davinci-mcbsp: DT fix
s/interrupts-names/interrupt-names/
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/devicetree/bindings/sound/davinci-mcbsp.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt b/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt
index 55b53e1fd72c..e0b6165c9cfc 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt
@@ -43,7 +43,7 @@ mcbsp0: mcbsp at 1d10000 {
<0x00310000 0x1000>;
reg-names = "mpu", "dat";
interrupts = <97 98>;
- interrupts-names = "rx", "tx";
+ interrupt-names = "rx", "tx";
dmas = <&edma0 3 1
&edma0 2 1>;
dma-names = "tx", "rx";
--
2.8.1
^ permalink raw reply related
* [PATCH 00/10] arm64: move thread_info off of the task stack
From: Mark Rutland @ 2016-10-24 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb8c8a44-36c8-9bbb-5cbb-9b42fd815d8d@redhat.com>
On Mon, Oct 24, 2016 at 10:58:10AM -0700, Laura Abbott wrote:
> On 10/24/2016 10:48 AM, Mark Rutland wrote:
> >On Mon, Oct 24, 2016 at 10:38:59AM -0700, Laura Abbott wrote:
> >>On 10/19/2016 12:10 PM, Mark Rutland wrote:
> >>>[3] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=arm64/ti-stack-split
> >
> >>I pulled the arm64/ti-stack-split branch on top of a Fedora
> >>tree and ran back-to-back kernel RPM builds for a long weekend.
> >>It's still going as of this morning so you can take that as a
> >>
> >>Tested-by: Laura Abbott <labbott@redhat.com>
> >
> >Thanks! That's much appreciated!
> >
> >Just to check, did you grab the version with entry.S fixes rolled in
> >(where the head is 657f54256c427fec)?
>
> Ah I did not. That came in after I started the test. I'll start
> another run with the new version.
Sorry about that; thanks for respinning!
It's really crazy how broken a kernel can be yet still "work"; clearly
we better tests are needed. :/
Thanks,
Mark.
^ permalink raw reply
* [PATCH/RFT v2 09/17] regulator: fixed: Add over current event
From: Axel Haslam @ 2016-10-24 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024175320.GO17252@sirena.org.uk>
On Mon, Oct 24, 2016 at 7:53 PM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Oct 24, 2016 at 06:46:26PM +0200, ahaslam at baylibre.com wrote:
>
>> + if (ret) {
>> + pr_err("Failed to request irq: %d\n", ret);
>
> dev_err()
>
>> +++ b/include/linux/regulator/consumer.h
>> @@ -74,6 +74,10 @@
>> * the most noisy and may not be able to handle fast load
>> * switching.
>> *
>> + * OVERCURRENT Regulator has detected an overcurrent condition, and
>> + * may be limiting the supply output.
>> + *
>> + *
>> * NOTE: Most regulators will only support a subset of these modes. Some
>> * will only just support NORMAL.
>> *
>> @@ -84,6 +88,7 @@
>> #define REGULATOR_MODE_NORMAL 0x2
>> #define REGULATOR_MODE_IDLE 0x4
>> #define REGULATOR_MODE_STANDBY 0x8
>> +#define REGULATOR_MODE_OVERCURRENT 0x10
>
> This is adding a new core feature with a new mode and should have been
> split out of the driver specific change with a spearate changelog. Why
Ok, will do.
> does it make sense to report this as a mode, we don't report other error
> conditions as modes but instead use REGULATOR_STATUS_ with the
> get_status() operation?
I used mode, because when the regulator toggles the overcurrent
line, it means that it has entered a current limited mode, at least the
regulator im looking at. ill change to STATUS
Regards
Axel
^ permalink raw reply
* [PATCH 00/10] arm64: move thread_info off of the task stack
From: Mark Rutland @ 2016-10-24 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024180941.GT15620@leverpostej>
On Mon, Oct 24, 2016 at 07:09:42PM +0100, Mark Rutland wrote:
> It's really crazy how broken a kernel can be yet still "work"; clearly
> we better tests are needed. :/
Clearly we better grammar need too. :(
Mark.
^ permalink raw reply
* [PATCH 00/10] arm64: move thread_info off of the task stack
From: Kees Cook @ 2016-10-24 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024181548.GA8275@leverpostej>
On Mon, Oct 24, 2016 at 11:15 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Oct 24, 2016 at 07:09:42PM +0100, Mark Rutland wrote:
>> It's really crazy how broken a kernel can be yet still "work"; clearly
>> we better tests are needed. :/
>
> Clearly we better grammar need too. :(
Out of curiosity, what workflow would have tripped over the entry.S bug?
-Kees
--
Kees Cook
Nexus Security
^ 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