* [PATCH v1 0/3] Add support for Broadcom OTP controller
From: Jonathan Richardson @ 2016-10-24 19:12 UTC (permalink / raw)
To: linux-arm-kernel
This patch set adds support for Broadcom's OTP controller found on chips such
as Cygnus and Stingray. A node has been added to the Cygnus dts.
Jonathan Richardson (3):
dt-bindings: Document Broadcom OTP controller driver
nvmem: Add the Broadcom OTP controller driver
ARM: dts: Add node for Broadcom OTP controller driver
.../devicetree/bindings/nvmem/brcm,ocotp.txt | 17 ++
arch/arm/boot/dts/bcm-cygnus.dtsi | 7 +
drivers/nvmem/Kconfig | 12 +
drivers/nvmem/Makefile | 2 +
drivers/nvmem/bcm-ocotp.c | 335 +++++++++++++++++++++
5 files changed, 373 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
create mode 100644 drivers/nvmem/bcm-ocotp.c
--
1.9.1
^ permalink raw reply
* [PATCH] ahci: use pci_alloc_irq_vectors
From: David Daney @ 2016-10-24 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161022141123.GA25500@lst.de>
Hi Christoph,
I can answer these...
On 10/22/2016 07:11 AM, Christoph Hellwig wrote:
> Hi Robert,
>
> is this a controller that's using MSI-X?
Yes. This is a ThunderX SoC with on-chip AHCI that use MSI-X
>
> If so can you try the patch below?
I applied it to v4.9-rc1 (really commit
6f33d6458e35d6ba53c2635ee4b8a3177cbd912d), and this didn't seem to make
it work.
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index ba5f11c..5fe852d 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1617,7 +1617,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> /* legacy intx interrupts */
> pci_intx(pdev, 1);
> }
> - hpriv->irq = pdev->irq;
> + hpriv->irq = pci_irq_vector(pdev, 0);
>
> if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
> host->flags |= ATA_HOST_PARALLEL_SCAN;
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [RFC] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-10-24 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hfunly4hn.fsf@baylibre.com>
On Mon, Oct 24, 2016 at 11:41 AM, Kevin Hilman <khilman@baylibre.com> wrote:
> Mark Rutland <mark.rutland@arm.com> writes:
>
>> 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?
>
> This is essentially a bus controller which allows you to set relative
> priorities of the various bus masters (CPU data, CPU instructions, DMA
> channels, ethernet MAC, SATA, display controller, etc. etc.)
Scratch that... I got this one confused with a different drivers/bus
driver Bartosz is also working on. :(
This one is just for the mechanism that controls how long old
(low-priority) xfers in the DDR command FIFO are allowed to sit around
before they will be flushed.
The use-case is the same though. The display controller doesn't work
at higher resolutions without tweaking this setting.
The question remains though: as a system-wide setting, should this be
configured via DT (either by a DT property, or based on a compatible
string in the driver) or should the driver provide an API to tweak it.
Kevin
^ permalink raw reply
* [PATCH v3 3/3] mtd: s3c2410: parse the device configuration from OF node
From: Boris Brezillon @ 2016-10-24 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024184738.GA26671@sprado-desktop>
On Mon, 24 Oct 2016 16:47:38 -0200
Sergio Prado <sergio.prado@e-labworks.com> wrote:
> On Mon, Oct 24, 2016 at 03:02:01PM +0200, Boris Brezillon wrote:
> > > +static int s3c2410_nand_setup_data_interface(struct mtd_info *mtd,
> > > + const struct nand_data_interface *conf,
> > > + bool check_only)
> > > +{
> > > + struct s3c2410_nand_info *info = s3c2410_nand_mtd_toinfo(mtd);
> > > + struct s3c2410_platform_nand *pdata = info->platform;
> > > + const struct nand_sdr_timings *timings;
> > > + int tacls;
> > > +
> > > + timings = nand_get_sdr_timings(conf);
> > > + if (IS_ERR(timings))
> > > + return -ENOTSUPP;
> > > +
> > > + tacls = timings->tCLS_min - timings->tWP_min;
> > > + if (tacls < 0)
> > > + tacls = 0;
> > > +
> > > + pdata->tacls = DIV_ROUND_UP(tacls, 1000);
> > > + pdata->twrph0 = DIV_ROUND_UP(timings->tWP_min, 1000);
> > > + pdata->twrph1 = DIV_ROUND_UP(timings->tCLH_min, 1000);
> >
> > You seem to only apply the timings in s3c2410_nand_setrate(), which is
> > only called at probe time or on a cpufreq even, but the core can change
> > timings at runtime (this is what happens each time you reset the chip).
> >
> > To support that you have 2 options:
> > - apply the timings in ->select_chip()
> > - apply the timings here
>
> Right. As far as I understood, ->setup_data_interface() will be called
> when MTD core change timings at runtime, so it is enough to apply the
> timings in the end of ->setup_data_interface()?
If your controller does not support interfacing with multiple chips,
then yes, it should work.
^ permalink raw reply
* [PATCH v3 3/3] mtd: s3c2410: parse the device configuration from OF node
From: Sergio Prado @ 2016-10-24 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024150201.01952f67@bbrezillon>
On Mon, Oct 24, 2016 at 03:02:01PM +0200, Boris Brezillon wrote:
> > +static int s3c2410_nand_setup_data_interface(struct mtd_info *mtd,
> > + const struct nand_data_interface *conf,
> > + bool check_only)
> > +{
> > + struct s3c2410_nand_info *info = s3c2410_nand_mtd_toinfo(mtd);
> > + struct s3c2410_platform_nand *pdata = info->platform;
> > + const struct nand_sdr_timings *timings;
> > + int tacls;
> > +
> > + timings = nand_get_sdr_timings(conf);
> > + if (IS_ERR(timings))
> > + return -ENOTSUPP;
> > +
> > + tacls = timings->tCLS_min - timings->tWP_min;
> > + if (tacls < 0)
> > + tacls = 0;
> > +
> > + pdata->tacls = DIV_ROUND_UP(tacls, 1000);
> > + pdata->twrph0 = DIV_ROUND_UP(timings->tWP_min, 1000);
> > + pdata->twrph1 = DIV_ROUND_UP(timings->tCLH_min, 1000);
>
> You seem to only apply the timings in s3c2410_nand_setrate(), which is
> only called at probe time or on a cpufreq even, but the core can change
> timings at runtime (this is what happens each time you reset the chip).
>
> To support that you have 2 options:
> - apply the timings in ->select_chip()
> - apply the timings here
Right. As far as I understood, ->setup_data_interface() will be called
when MTD core change timings at runtime, so it is enough to apply the
timings in the end of ->setup_data_interface()?
Thanks,
Sergio Prado
^ permalink raw reply
* [RFC] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-10-24 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024174249.GQ15620@leverpostej>
Mark Rutland <mark.rutland@arm.com> writes:
> 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?
This is essentially a bus controller which allows you to set relative
priorities of the various bus masters (CPU data, CPU instructions, DMA
channels, ethernet MAC, SATA, display controller, etc. etc.)
The reason behind this work in the first place is a specific
use-case. Namely, a display controller on this SoC needs its bus
priority to be adjusted in order to work reliably at certain
resolutions
The vendor BSPs for this chip just setup hard-coded values in the board
files (davinci, still hasn't fully migrated to DT) but we're trying to
figure out a better way.
The first approach was exposing DT knobs for all the priorities. The
second approach was the other extermem allowing SoC or board-specific
hard-coded values.
Another possible approach would be getting rid of the hard-coded values
and exporting an API from the driver to set the priorities of the
available masters at run-time. I'm not awarye any current need of
changing things at run-time, but it seems potentially useful as well.
Based on all this discussion, I'm starting to lean towards the runtime
API approach, but am hoping for some suggestions.
Kevin
^ permalink raw reply
* [PATCH] i2c: rk3x: Give the tuning value 0 during rk3x_i2c_v0_calc_timings
From: Doug Anderson @ 2016-10-24 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
Hi,
On Sat, Oct 22, 2016 at 1:43 AM, David Wu <david.wu@rock-chips.com> wrote:
> We found a bug that i2c transfer sometimes failed on 3066a board with
> stabel-4.8, the con register would be updated by uninitialized tuning
> value, it made the i2c transfer failed.
>
> So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
>
> Signed-off-by: David Wu <david.wu@rock-chips.com>
> ---
> drivers/i2c/busses/i2c-rk3x.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [PATCH V7 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Stefan Wahren @ 2016-10-24 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87eg35snvg.fsf@eliezer.anholt.net>
> Eric Anholt <eric@anholt.net> hat am 24. Oktober 2016 um 18:38 geschrieben:
>
>
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
> > Hi Martin,
> >
> > Am 28.09.2016 um 23:10 schrieb Eric Anholt:
> >> kernel at martin.sperl.org writes:
> >>
> >>> From: Martin Sperl <kernel@martin.sperl.org>
> >>>
> >>> Add basic thermal driver for bcm2835 SOC.
> >>>
> >>> This driver currently relies on the firmware setting up the
> >>> tsense HW block and does not set it up itself.
> >>>
> >>> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
> >>> Acked-by: Eric Anholt <eric@anholt.net>
> >>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> >> What's the status of merging this one? I'd like to merge the other
> >> patches.
> >
> > i think it's necessary to rebase the whole series. Maybe we could get it
> > into 4.10.
>
> Why would it need to be rebased? The status, as far as I know, is that
> we're still waiting for the subsystem maintainer to respond.
Since at least this patch won't apply anymore, but feedback from maintainer is
still good :-)
Sorry for this impatience, but i'm afraid that we possibly miss 4.10.
^ permalink raw reply
* [PATCH/RFT v2 09/17] regulator: fixed: Add over current event
From: Mark Brown @ 2016-10-24 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKXjFTNZhWTZSXtLZo8EieBtAPn_J-MM+-g8yCRJiV6UBspB9Q@mail.gmail.com>
On Mon, Oct 24, 2016 at 08:11:40PM +0200, Axel Haslam wrote:
> On Mon, Oct 24, 2016 at 7:53 PM, Mark Brown <broonie@kernel.org> wrote:
> > 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
That's not what regulator modes are - please look at the documentation
for the defines here. They're about the quality of regulation.
-------------- 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/e50d7f07/attachment.sig>
^ 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
* [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/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: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
* 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
* 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: 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
* 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: 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
* [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
* [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/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 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
* [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/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
* [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
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