* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Catalin Marinas @ 2014-01-27 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E69121.8050500@arm.com>
On Mon, Jan 27, 2014 at 05:02:25PM +0000, Marc Zyngier wrote:
> On 27/01/14 16:57, Catalin Marinas wrote:
> > On Mon, Jan 27, 2014 at 11:16:57AM +0000, Marc Zyngier wrote:
> >> On 24/01/14 23:37, Christoffer Dall wrote:
> >>> On Sat, Jan 04, 2014 at 08:27:23AM -0800, Christoffer Dall wrote:
> >>>> --- a/arch/arm/include/asm/pgtable-3level.h
> >>>> +++ b/arch/arm/include/asm/pgtable-3level.h
> >>>> @@ -120,13 +120,19 @@
> >>>> /*
> >>>> * 2nd stage PTE definitions for LPAE.
> >>>> */
> >>>> -#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
> >>>> -#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
> >>>> -
> >>>> -#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
> >>>> +#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
> >>>> +#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
> >>>> +#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >>>> +#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
> >>>> +#define L_PTE_S2_MT_DEV_NONSHARED (_AT(pteval_t, 0x1) << 2) /* device */
> >>>> +#define L_PTE_S2_MT_DEV_WC (_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
> >>>> +#define L_PTE_S2_MT_DEV_CACHED (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >>>> +#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
> >>>> +
> >>>> +#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
> >>>> +#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
> >>>> +
> >>>> +#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
> >>>>
> >>>> /*
> >>>> * Hyp-mode PL2 PTE definitions for LPAE.
> >>
> >> The change makes sense to me. arm64 uses a slightly different approach,
> >> by using a PTE_S2_MEMATTR macro, but I'm not sure that would work for ARM.
> >>
> >> Russell, Catalin: could you please have a look at this?
> >
> > Do we actually need more than Normal Cacheable and Device for stage 2?
>
> Not so far. As long as these two memory types are enforced as a minimum,
> we're quite happy to let the guest use whatever it decides.
>
> I suppose Christoffer introduces them all here as a matter of
> completeness, but I don't see them as being useful anytime soon.
That would be useful on arm if you want cachepolicy= argument to force
the cacheability of guest Normal memory type.
On arm64, the stage 1 memory type is decided via MAIR and that's how we
handle cachepolicy for Normal memory. But for stage 2 this won't work,
the type is explicitly set in the MemAttr encoding. But I don't think we
need host cachepolicy enforced onto guest.
--
Catalin
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Russell King - ARM Linux @ 2014-01-27 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E69395.9020004@linaro.org>
On Mon, Jan 27, 2014 at 06:12:53PM +0100, Daniel Lezcano wrote:
> On 01/27/2014 05:07 PM, Russell King - ARM Linux wrote:
>> On Mon, Jan 27, 2014 at 09:22:55AM +0100, Daniel Lezcano wrote:
>>> On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
>>>> ARM and ARM64 are the only two architectures implementing
>>>> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>>>>
>>>> We have secondary_start_kernel() already calling local_fiq_enable() and
>>>> this is done a second time in arch_cpu_idle_prepare() in that case. And
>>>> enabling FIQs has nothing to do with idling the CPU to start with.
>>>>
>>>> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
>>>> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
>>>> at late_initcall time but this shouldn't make a difference in practice
>>>> i.e. when FIQs are actually used.
>>>>
>>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>>
>>> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>
>> What kind of review did you do when giving that attributation?
>
> I did the review to the best of my knowledge and with good will.
>
> I read your comment on this patch and I learnt one more thing.
>
> Today, I am smarter than yesterday and dumber than tomorrow :)
Just be aware that putting a comment along with the reviewed-by tag
is always a good idea. I know that's a little more work, but this has
been raised a number of times by various people over the years.
A reviewed-by tag on its own doesn't mean much, as it could mean that
you've just glanced over the code and decided "yea, it looks okay", or
it could mean that you've spent all day verifying that the code change
is indeed correct.
Consequently, some will ignore emails which just contain a reviewed-by
attributation.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Daniel Lezcano @ 2014-01-27 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127160736.GP15937@n2100.arm.linux.org.uk>
On 01/27/2014 05:07 PM, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 09:22:55AM +0100, Daniel Lezcano wrote:
>> On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
>>> ARM and ARM64 are the only two architectures implementing
>>> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>>>
>>> We have secondary_start_kernel() already calling local_fiq_enable() and
>>> this is done a second time in arch_cpu_idle_prepare() in that case. And
>>> enabling FIQs has nothing to do with idling the CPU to start with.
>>>
>>> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
>>> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
>>> at late_initcall time but this shouldn't make a difference in practice
>>> i.e. when FIQs are actually used.
>>>
>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>
>> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> What kind of review did you do when giving that attributation?
I did the review to the best of my knowledge and with good will.
I read your comment on this patch and I learnt one more thing.
Today, I am smarter than yesterday and dumber than tomorrow :)
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Russell King - ARM Linux @ 2014-01-27 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1401271549280.23931@axis700.grange>
On Mon, Jan 27, 2014 at 04:13:56PM +0100, Guennadi Liakhovetski wrote:
> I'm working on an MMC driver with a DMA capability. All has been working
> well, until at some point I've got a bus error, when the mmc driver had
> been handed in a buffer at 0x3000 physical RAM address. The reason is,
> that on Zynq arch bus masters cannot access RAM below 0x80000. Therefore
> my question: how shall I configure this in software?
You're going to run into all sorts of problems here. Normally, the
DMA-able memory is limited to the first N bytes of memory, not "you must
avoid the first N bytes of memory".
Linux has it hard-coded into the memory subsystems that the DMA zone
is from the start of memory to N, the normal zone is from N to H, and
high memory is from H upwards - and allocations for high can fall back
to normal, which can fall back to DMA but not the other way around.
Short of permanently reserving the first 0x80000 bytes of memory, I'm
not sure that there's much which can be done. You may wish to talk to
the MM gurus to see whether there's a modern alternative.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Marc Zyngier @ 2014-01-27 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127165730.GC8358@arm.com>
On 27/01/14 16:57, Catalin Marinas wrote:
> On Mon, Jan 27, 2014 at 11:16:57AM +0000, Marc Zyngier wrote:
>> On 24/01/14 23:37, Christoffer Dall wrote:
>>> On Sat, Jan 04, 2014 at 08:27:23AM -0800, Christoffer Dall wrote:
>>>> --- a/arch/arm/include/asm/pgtable-3level.h
>>>> +++ b/arch/arm/include/asm/pgtable-3level.h
>>>> @@ -120,13 +120,19 @@
>>>> /*
>>>> * 2nd stage PTE definitions for LPAE.
>>>> */
>>>> -#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
>>>> -#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
>>>> -#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
>>>> -#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
>>>> -#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
>>>> -
>>>> -#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
>>>> +#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
>>>> +#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
>>>> +#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
>>>> +#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
>>>> +#define L_PTE_S2_MT_DEV_NONSHARED (_AT(pteval_t, 0x1) << 2) /* device */
>>>> +#define L_PTE_S2_MT_DEV_WC (_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
>>>> +#define L_PTE_S2_MT_DEV_CACHED (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
>>>> +#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
>>>> +
>>>> +#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
>>>> +#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
>>>> +
>>>> +#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
>>>>
>>>> /*
>>>> * Hyp-mode PL2 PTE definitions for LPAE.
>>
>> The change makes sense to me. arm64 uses a slightly different approach,
>> by using a PTE_S2_MEMATTR macro, but I'm not sure that would work for ARM.
>>
>> Russell, Catalin: could you please have a look at this?
>
> Do we actually need more than Normal Cacheable and Device for stage 2?
Not so far. As long as these two memory types are enforced as a minimum,
we're quite happy to let the guest use whatever it decides.
I suppose Christoffer introduces them all here as a matter of
completeness, but I don't see them as being useful anytime soon.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Catalin Marinas @ 2014-01-27 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E64029.6000201@arm.com>
On Mon, Jan 27, 2014 at 11:16:57AM +0000, Marc Zyngier wrote:
> On 24/01/14 23:37, Christoffer Dall wrote:
> > On Sat, Jan 04, 2014 at 08:27:23AM -0800, Christoffer Dall wrote:
> >> --- a/arch/arm/include/asm/pgtable-3level.h
> >> +++ b/arch/arm/include/asm/pgtable-3level.h
> >> @@ -120,13 +120,19 @@
> >> /*
> >> * 2nd stage PTE definitions for LPAE.
> >> */
> >> -#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
> >> -#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
> >> -#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
> >> -#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
> >> -#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
> >> -
> >> -#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
> >> +#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
> >> +#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
> >> +#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >> +#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
> >> +#define L_PTE_S2_MT_DEV_NONSHARED (_AT(pteval_t, 0x1) << 2) /* device */
> >> +#define L_PTE_S2_MT_DEV_WC (_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
> >> +#define L_PTE_S2_MT_DEV_CACHED (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >> +#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
> >> +
> >> +#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
> >> +#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
> >> +
> >> +#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
> >>
> >> /*
> >> * Hyp-mode PL2 PTE definitions for LPAE.
>
> The change makes sense to me. arm64 uses a slightly different approach,
> by using a PTE_S2_MEMATTR macro, but I'm not sure that would work for ARM.
>
> Russell, Catalin: could you please have a look at this?
Do we actually need more than Normal Cacheable and Device for stage 2?
--
Catalin
^ permalink raw reply
* [Q] L1_CACHE_BYTES on flush_pfn_alias function.
From: Catalin Marinas @ 2014-01-27 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <003c01cf1a55$623979f0$26ac6dd0$@samsung.com>
Please do not top-post.
On Sun, Jan 26, 2014 at 05:13:43AM +0000, Jungseung Lee wrote:
> Not to flush some more bytes. In the scenario, they can *omit* to flush last 32 bytes.
>
> L1_CACHE_BYTES = 64 (ARM v7, CA9)
>
> asm( "mcrr p15, 0, %1, %0, c14\n"
> " mcr p15, 0, %2, c7, c10, 4"
> :
> : "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
> : "cc");
Ah, I got it now. I think this should be (to + PAGE_SIZE - 1). My
reading of the ARM ARM is that the bottom bits of the address are
ignored by mcrr.
--
Catalin
^ permalink raw reply
* imx6: usbhc2/3 and HSIC
From: Christian Gmeiner @ 2014-01-27 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390815772.4847.9.camel@weser.hi.pengutronix.de>
Hi Lucas
2014-01-27 Lucas Stach <l.stach@pengutronix.de>:
> Hi Christian,
>
> Am Montag, den 27.01.2014, 10:22 +0100 schrieb Christian Gmeiner:
>> Hi all...
>>
>> does anyone used the usbhc2 or usbhc3 in HSIC mode? I am trying my
>> luck but I do not
>> get it to work. Is there anything special I need to take care of?
>>
> I remember we had this working on a board back in the 3.10 days. The
> only thing I remember which is specific to HSIC is in the attached
> patch. This isn't really clean and should be done in a better way for
> mainline, but maybe it provides some pointers for you.
>
Thanks for the small patch... I got it almost working - the HSIC
device seems to have some problems.
I hope to find some time soon to get this stuff into mainline.
greets
--
Christian Gmeiner, MSc
^ permalink raw reply
* [BUG] reproducable ubifs reboot assert and corruption
From: Andrew Ruder @ 2014-01-27 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFLxGvwmzftdQKSjjjwpFLS8g3EJqMrQ2gU2scBsh2MvG7Wyyw@mail.gmail.com>
On Sat, Jan 25, 2014 at 04:02:15PM +0100, Richard Weinberger wrote:
> So ubifs_bgt0_0 stops and the fun begins.
> Can you trigger the issue also by unmounting /mnt?
> I.e umount -l /mnt
> The background thread should only stop after all io is done...
Did some experiments last week to see if I could trigger the bug with
full debug messages enabled. Biggest problem is that I don't have
non-volatile memory available, serial logging slows it down too much to
trigger the bug, and the reboot tends to shut down any attempt to
offload the log to capture the relevant messages.
That being said, I was able to trigger the bug with the following:
[root at buildroot ~]# (sleep 5 ; while ! mount -o remount,ro /mnt ; do true ; done ; echo remount > /dev/kmsg ; sleep 5 ; echo reboot > /dev/kmsg ; reboot ) &
[2] 564
[root at buildroot ~]# fsstress -p 10 -n 10 -X -d /mnt/fsstress -l 0
In my log I can see the "remount" message and 100ms later I can see the
first ubifs assert. I've attached the relevant portion of the logs
below from the first time I see LEB 44 mentioned through the asserts.
I've put the logs on the web due to concerns of flooding the mailing
list with 100's of kB in attachments.
https://gist.github.com/aeruder/8651928
ubi_corruption.txt is the kernel log
afterwards.txt is the console log with the ensuing issue with ubifs
I also have logs of the recovery process in the Linux kernel later on,
(still takes 2 mounts), an image of the MTD device, and would be happy
to try anything or enable any additional debug messages.
> Can you also please find out whether fssstress is still running when
> reboot takes action?
Thanks for taking a look. I'm reading everything I can find about ubifs
to see if I can make some headway into understanding what is going on
but filesytems are definitely not my forte :).
Cheers,
Andrew Ruder
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Lars-Peter Clausen @ 2014-01-27 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E686B2.9060806@ti.com>
On 01/27/2014 05:17 PM, Jyri Sarha wrote:
> On 01/27/2014 05:51 PM, Lars-Peter Clausen wrote:
>> Hi,
>>
>> I think you should try to get this in sync with the work Jean-Francois is
>> currently doing[1]. Having the HDMI transmitter register a CODEC device is
>> definitely the right approach, compared to the rather 'interesting'
>> constraints stuff you do in patch 4.
>>
>
> Oh, Jean-Francois's patches are now out. I'll take those into use, but I am
> afraid it still does not save me from the constraint stuff.
>
> The most complex piece of code comes from limited sample-rate availability,
> which is coming Beaglebone-Black desing (available i2s master clock), not
> from the HDMI encoder itself. It does not help with the stereo only
> limitation either, because it comes from the one wire only audio data
> connection on BBB.
>
> Support for S16_LE could maybe be added if the tda998x specific codec would
> fiddle with CTS_N predivider-setting (K select) according to the used sample
> width. But it appears Cobox plays all the sample formats fine without this
> change, so the question is if playing around with CTS_N predivider would
> break already working support there (something to be tested).
The ASoC core will set the constraints for the audio format/rate to the
intersection of what is supported by the CODEC and the CPU DAI. So if the
limitation comes from the CPU DAI the constraints should be applied there
and not in the machine driver. Similar if the tda998x only supports 32 bit
samples it should advertise this and the compound card will only support 32
bit samples.
- Lars
^ permalink raw reply
* [PATCH 0/2] Replace /include/ (dtc) with #include
From: Catalin Marinas @ 2014-01-27 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E63DD8.9070909@samsung.com>
On Mon, Jan 27, 2014 at 11:07:04AM +0000, Pankaj Dubey wrote:
> On 01/10/2014 07:16 PM, Pankaj Dubey wrote:
> > Replace /include/ (dtc) with #include (C pre-processor) for all ARM64
> > based SoC dts files.
> >
> > Pankaj Dubey (2):
> > arm64: dts: use #include for all AppliedMicro device tree files
> > arm64: dts: use #include for all ARM fast model device tree file
> >
> > arch/arm64/boot/dts/apm-mustang.dts | 2 +-
> > arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> Gentle ping.
It would be good to include some rationale behind this change and I'm
waiting for the DT guys to ack it.
--
Catalin
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Jyri Sarha @ 2014-01-27 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E6806A.2090109@metafoo.de>
On 01/27/2014 05:51 PM, Lars-Peter Clausen wrote:
> Hi,
>
> I think you should try to get this in sync with the work Jean-Francois is
> currently doing[1]. Having the HDMI transmitter register a CODEC device is
> definitely the right approach, compared to the rather 'interesting'
> constraints stuff you do in patch 4.
>
Oh, Jean-Francois's patches are now out. I'll take those into use, but I
am afraid it still does not save me from the constraint stuff.
The most complex piece of code comes from limited sample-rate
availability, which is coming Beaglebone-Black desing (available i2s
master clock), not from the HDMI encoder itself. It does not help with
the stereo only limitation either, because it comes from the one wire
only audio data connection on BBB.
Support for S16_LE could maybe be added if the tda998x specific codec
would fiddle with CTS_N predivider-setting (K select) according to the
used sample width. But it appears Cobox plays all the sample formats
fine without this change, so the question is if playing around with
CTS_N predivider would break already working support there (something to
be tested).
Best regards,
Jyri
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Russell King - ARM Linux @ 2014-01-27 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E6175F.1050401@linaro.org>
On Mon, Jan 27, 2014 at 09:22:55AM +0100, Daniel Lezcano wrote:
> On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
>> ARM and ARM64 are the only two architectures implementing
>> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>>
>> We have secondary_start_kernel() already calling local_fiq_enable() and
>> this is done a second time in arch_cpu_idle_prepare() in that case. And
>> enabling FIQs has nothing to do with idling the CPU to start with.
>>
>> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
>> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
>> at late_initcall time but this shouldn't make a difference in practice
>> i.e. when FIQs are actually used.
>>
>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
What kind of review did you do when giving that attributation?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Russell King - ARM Linux @ 2014-01-27 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401271004060.1652@knanqh.ubzr>
On Mon, Jan 27, 2014 at 10:45:59AM -0500, Nicolas Pitre wrote:
> On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
>
> > On Mon, Jan 27, 2014 at 01:08:16AM -0500, Nicolas Pitre wrote:
> > > ARM and ARM64 are the only two architectures implementing
> > > arch_cpu_idle_prepare() simply to call local_fiq_enable().
> > >
> > > We have secondary_start_kernel() already calling local_fiq_enable() and
> > > this is done a second time in arch_cpu_idle_prepare() in that case. And
> > > enabling FIQs has nothing to do with idling the CPU to start with.
> > >
> > > So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> > > CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> > > at late_initcall time but this shouldn't make a difference in practice
> > > i.e. when FIQs are actually used.
> > >
> > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > > ---
> > > arch/arm/kernel/process.c | 5 -----
> > > arch/arm/kernel/setup.c | 7 +++++++
> > > 2 files changed, 7 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> > > index 92f7b15dd2..725b8c95e0 100644
> > > --- a/arch/arm/kernel/process.c
> > > +++ b/arch/arm/kernel/process.c
> > > @@ -142,11 +142,6 @@ static void default_idle(void)
> > > local_irq_enable();
> > > }
> > >
> > > -void arch_cpu_idle_prepare(void)
> > > -{
> > > - local_fiq_enable();
> > > -}
> > > -
> > > void arch_cpu_idle_enter(void)
> > > {
> > > ledtrig_cpu(CPU_LED_IDLE_START);
> > > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > > index 987a7f5bce..d027b1a6fe 100644
> > > --- a/arch/arm/kernel/setup.c
> > > +++ b/arch/arm/kernel/setup.c
> > > @@ -789,6 +789,13 @@ static int __init init_machine_late(void)
> > > }
> > > late_initcall(init_machine_late);
> > >
> > > +static int __init init_fiq_boot_cpu(void)
> > > +{
> > > + local_fiq_enable();
> > > + return 0;
> > > +}
> > > +late_initcall(init_fiq_boot_cpu);
> >
> > arch_cpu_idle_prepare() gets called from the swapper thread, and changes
> > the swapper thread's CPSR. init_fiq_boot_cpu() gets called from PID1, the
> > init thread, and changes the init thread's CPSR, which will already have
> > FIQs enabled by way of how kernel threads are created.
> >
> > Hence, the above code fragment has no effect what so ever, and those
> > platforms using FIQs will not have FIQs delivered if they're idle
> > (because the swapper will have FIQs masked at the CPU.)
>
> You're right.
>
> What about moving local_fiq_enable() to trap_init() then?
That's potentially unsafe, as we haven't touched any of the IRQ
controllers at that point - we can't guarantee what state they'd be
in. Given that the default FIQ is to just return, a FIQ being raised
at that point will end up with an infinite loop re-entering the FIQ
handler.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
From: Felipe Balbi @ 2014-01-27 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127150855.GA17928@xps8300>
Hi,
On Mon, Jan 27, 2014 at 05:08:55PM +0200, Heikki Krogerus wrote:
> > > Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs),
> > > do not return from probe if the USB PHY library returns -ENODEV as that
> >
> > this isn't correct, they all have PHYs, some of them might not be
> > controllable.
> >
> > > indicates the platform does not have PHY.
> >
> > not really, that indicates the current platform tried to grab a PHY and
> > the PHY doesn't exist. If there's anybody with a non-controllable PHY
> > and someone gives me a really good reason for not using the generic
> > no-op PHY, then we should add a flag and we could:
> >
> > if (!likely(dwc->flags & DWC3_USB2PHY_DRIVER_NOT_NEEDED))
> > dwc3_grab_phys(dwc);
>
> Why would you need to know if the PHY drivers are needed or not
> explicitly in your controller driver?
because, one way or another, they all do need it. Except for quirky ones
like AM437x where a USB3 IP was hardwired into USB2-only mode, so it
really lacks a USB3 PHY.
> > But I really want to see the argument against using no-op. As far as I
> > could see, everybody needs a PHY driver one way or another, some
> > platforms just haven't sent any PHY driver upstream and have their own
> > hacked up solution to avoid using the PHY layer.
>
> Not true in our case. Platforms using Intel's SoCs and chip sets may
> or may not have controllable USB PHY. Quite often they don't. The
> Baytrails have usually ULPI PHY for USB2, but that does not mean they
> provide any vendor specific functions or any need for a driver in any
> case.
that's different from what I heard.
> Are we talking about the old USB PHY library or the new PHY framework
> with the no-op PHY driver?
>
> Well, in any case, I don't understand what is the purpose of the no-op
> PHY driver. What are you drying to achieve with that?
I'm trying to avoid supporting 500 different combinations for a single
driver. We already support old USB PHY layer and generic PHY layer, now
they both need to be made optional. The old USB PHY layer also provides
a no-op, now called phy-generic, which is actually pretty useful.
On top of all that, I'm sure you'll subscribe to the idea of preventing
dwc3 from becoming another MUSB which supports several different
configurations and none work correctly. I much prefer to take baby steps
which are well thought-out and very well exercised, so I'll be very
pedantic about proof of testing.
An invasive change such as $subject needs to be very well-tested in
different architectures with different Kconfig choices before I'd feel
comfortable applying it.
Also, the assumptions made in $subject are just plain wrong, which
gets me really iffy about applying it or not.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/afb7097a/attachment.sig>
^ permalink raw reply
* [PATCH 2/9] ARM64: get rid of arch_cpu_idle_prepare()
From: Catalin Marinas @ 2014-01-27 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401271047240.1652@knanqh.ubzr>
On Mon, Jan 27, 2014 at 03:51:02PM +0000, Nicolas Pitre wrote:
> On Mon, 27 Jan 2014, Catalin Marinas wrote:
>
> > On Mon, Jan 27, 2014 at 06:08:17AM +0000, Nicolas Pitre wrote:
> > > ARM and ARM64 are the only two architectures implementing
> > > arch_cpu_idle_prepare() simply to call local_fiq_enable().
> > >
> > > We have secondary_start_kernel() already calling local_fiq_enable() and
> > > this is done a second time in arch_cpu_idle_prepare() in that case. And
> > > enabling FIQs has nothing to do with idling the CPU to start with.
> > >
> > > So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> > > CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> > > at late_initcall time but this shouldn't make a difference in practice
> > > given that FIQs are not currently used on ARM64.
> > >
> > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> >
> > For arm64, we could simply remove any reference to FIQs. I'm not aware
> > of anyone using them.
>
> OK. What if I sumply remove arch_cpu_idle_prepare() and let you do the
> remove the rest?
>
> IMHO I'd simply remove local_fiq_{enable/disable}() from
> arm64/kernel/smp.c and leave the infrastructure in place in case someone
> needs it eventually. In which case I could include that into my patch
> as well.
Sounds good. We can keep the local_fiq_*() functions but remove about 4
calling sites (process.c and smp.c) until needed.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v2 3/4] Update bcm_defconfig with new pinctrl CONFIG
From: Christian Daudt @ 2014-01-27 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390509887-19278-4-git-send-email-syin@broadcom.com>
On Thu, Jan 23, 2014 at 12:44 PM, Sherman Yin <syin@broadcom.com> wrote:
> To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
> driver and its related CONFIG option are renamed to bcm281xx.
>
> This commit updates the defconfig that enables the pinctrl driver.
>
> Signed-off-by: Sherman Yin <syin@broadcom.com>
> Reviewed-by: Matt Porter <mporter@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/configs/bcm_defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
> index bede511..53d6d47 100644
> --- a/arch/arm/configs/bcm_defconfig
> +++ b/arch/arm/configs/bcm_defconfig
> @@ -126,4 +126,4 @@ CONFIG_CRC_ITU_T=y
> CONFIG_CRC7=y
> CONFIG_XZ_DEC=y
> CONFIG_AVERAGE=y
> -CONFIG_PINCTRL_CAPRI=y
> +CONFIG_PINCTRL_BCM281XX=y
> --
> 1.7.9.5
>
Acked-by: Christian Daudt <bcm@fixthebug.org>
Olof,
Can you apply this patch directly or do you want me to send a pull
request with it ?
Thanks,
csd
^ permalink raw reply
* [PATCH] sunxi: dts: add a note that memory size is adjusted by boot loader.
From: Ian Campbell @ 2014-01-27 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127145714.GL3867@lukather>
On Mon, 2014-01-27 at 15:57 +0100, Maxime Ripard wrote:
> Hi Ian, Hans,
>
> On Sat, Jan 25, 2014 at 12:03:16PM +0100, Hans de Goede wrote:
> > Hmm, I've no idea what the default / preferred way of handling this is,
> > I assume Maxime knows, so lets wait for his input on this.
>
> I got the habit of setting the memory node to the max size the RAM
> controller can handle from previous work on imx,
I suppose this has the advantage of being static for a given SoC, so
there is no question of what the smallest possible value is, even if it
has the disadvantage of not working as a default on many platforms
(perhaps I'm overestimating the utility of that?).
> but I don't really
> have a preferrence here.
>
> If that confuses people, we can just remove it from the DTSI
> altogether. It will be patched by u-boot anyway, and we won't have to
> create DTS variants this way.
I've occasionally seen issues with u-boot not expanding the fdt itself,
so the placeholder serves the purpose of letting it update without
expanding. That was in my more complex Xen boot script which use "fdt
set" a lot -- probably doesn't apply to properly integrated
functionality like updating the memory node? (Or if it does that's a
u-boot bug).
> Just don't do it for the A31 for the moment, since we don't have
> DT-enabled u-boot for now.
Ack!
Ian.
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Lars-Peter Clausen @ 2014-01-27 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
Hi,
I think you should try to get this in sync with the work Jean-Francois is
currently doing[1]. Having the HDMI transmitter register a CODEC device is
definitely the right approach, compared to the rather 'interesting'
constraints stuff you do in patch 4.
- Lars
[1] http://lkml.org/lkml/2014/1/27/85
On 01/27/2014 04:37 PM, Jyri Sarha wrote:
> Changes since RFC v2 version of the patches:
> - Dropped out already applied:
> ASoC: hdmi-codec: Add devicetree binding with documentation
> - Addresses Mark's comments here:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/070605.html
> - ASoC: davinci-evm: Add named clock reference to DT bindings
> - Get rid of unnecessary castings
> - Add mclk NULL checks
> - Use devm_clk_get()
> - Change clock name from "ti,codec-clock" to "mclk"
> - Address Mark's comments here:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/070606.html - ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
> - Get rid of unnecessary castings
> - Update commit message
> - Add: ASoC: davinci-mcasp: Set BCLK divider if McASP is BCLK master
> - Use snd_soc_params_to_bclk()
>
> Changes since the first RFC version of the patches:
> - Drop out already applied:
> ASoC: hdmi-codec: Add SNDRV_PCM_FMTBIT_32_LE playback format
> - Change sound node's compatible property
> form: "ti,am33xx-beaglebone-black" to "ti,am33xx-beaglebone-black-audio"
> - Some minor style issue fixes from TI internal review
>
> Jyri Sarha (8):
> clk: add gpio controlled clock
> ASoC: davinci-evm: Add named clock reference to DT bindings
> ASoC: davinci-mcasp: Set BCLK divider if McASP is BCLK master
> ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S
> bus
> ASoC: davinci: HDMI audio build for AM33XX and TDA998x
> drm/tilcdc: Add I2C HDMI audio config for tda998x
> ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI
> support
> ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio
> support
>
> .../devicetree/bindings/clock/gpio-clock.txt | 21 ++
> .../bindings/sound/davinci-evm-audio.txt | 13 +-
> arch/arm/configs/omap2plus_defconfig | 5 +
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-gpio.c | 210 +++++++++++++++++++
> drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++-
> include/linux/clk-provider.h | 25 +++
> sound/soc/davinci/Kconfig | 12 ++
> sound/soc/davinci/Makefile | 1 +
> sound/soc/davinci/davinci-evm.c | 211 +++++++++++++++++++-
> sound/soc/davinci/davinci-mcasp.c | 20 ++
> 11 files changed, 534 insertions(+), 9 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt
> create mode 100644 drivers/clk/clk-gpio.c
>
^ permalink raw reply
* [PATCH 2/9] ARM64: get rid of arch_cpu_idle_prepare()
From: Nicolas Pitre @ 2014-01-27 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127154315.GG32608@arm.com>
On Mon, 27 Jan 2014, Catalin Marinas wrote:
> On Mon, Jan 27, 2014 at 06:08:17AM +0000, Nicolas Pitre wrote:
> > ARM and ARM64 are the only two architectures implementing
> > arch_cpu_idle_prepare() simply to call local_fiq_enable().
> >
> > We have secondary_start_kernel() already calling local_fiq_enable() and
> > this is done a second time in arch_cpu_idle_prepare() in that case. And
> > enabling FIQs has nothing to do with idling the CPU to start with.
> >
> > So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> > CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> > at late_initcall time but this shouldn't make a difference in practice
> > given that FIQs are not currently used on ARM64.
> >
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> For arm64, we could simply remove any reference to FIQs. I'm not aware
> of anyone using them.
OK. What if I sumply remove arch_cpu_idle_prepare() and let you do the
remove the rest?
IMHO I'd simply remove local_fiq_{enable/disable}() from
arm64/kernel/smp.c and leave the infrastructure in place in case someone
needs it eventually. In which case I could include that into my patch
as well.
Nicolas
^ permalink raw reply
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Jason Cooper @ 2014-01-27 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> A new round, mostly fixing some minor nitpicks.
>
> This entire series depends on latest irqchip-orion fixes by Sebastian.
> Namely, this one: https://lkml.org/lkml/2014/1/23/594.
>
> How should we handle this dependency?
Sorry, I'm short on time atm. Which specific patches now depend on his
changes?
I'll be doing a topic branch for tglx for that, so it shouldn't be
rocket surgery. The big unknown is the MMIO patch currently in
Russell's patch tracker.
We may end up waiting for MMIO and Sebastian's changes to land, then
applying this during the next cycle.
thx,
Jason.
> Changes from v4 are:
>
> * Provided better commit subject and commit log for patch 7:
> "watchdog: orion: Handle the interrupt so it's properly acked".
>
> * Corrected the misnamed fuction try_rstout_ioremap().
>
> * A bunch of s/interruption/interrupt fixes
>
> * Dropped the '0' as a valid IRQ in the platform_get_irq() check, given
> it should return a positive virq-space number.
>
> Changes from v3 are:
>
> * It wasn't nice to break DT compatibility by adding a second resource
> requirement, so we provided a fallback to use the RSTOUT address.
> All in all, the solution doesn't look too bad.
>
> * Added a full watchdog stop at driver probe time, *before* the call
> to request_irq().
>
> Notice that currently the request_irq() doesn't seem to clear the
> pending interrupt. This means the BRIDGE_CAUSE clear removal is
> still not safe.
>
> This should be fixed sooner than later and, of course, before this
> gets merged.
>
> * Rework the interrupt request, to use devm_request_irq() and
> avoid dealing with IRQ releasing.
>
> * Added proper clock error handling and fixed the probe() error path.
>
> * Typos and minor issues got fixed
>
> Changes from v2:
>
> * Add proper error checking on clk_prepare_enable() and return
> PTR_ERR instead of ENODEV. Suggested by Fabio Estevam.
>
> * After the usage of the atomic I/O and considering the watchdog core
> does its own serialization, the driver's spinlock was completely
> redundant and was removed. Also suggested by Fabio.
>
> * Instead of making the driver dependent on PLAT_ORION, added a dependency
> to ARCH_MVEBU. This was proposed by Sebastian and Andrew, given
> we're working on PLAT_ORION removal.
>
> Changes from v1:
>
> * Watchdog RSTOUT enable.
> While v1 enabled the RSTOUT at each machine initialization, Jason Gunthorpe
> later pointed out [2] that such enabling might lead to a spurious watchdog
> trigger, in the event of the watchdog expired event not being cleared.
>
> Therefore, the current patchset adds RSTOUT as a second address resource
> (or 'reg' entry in devicetree words) to allow different platforms specify
> the corresponding address of the register. This change allows to build the
> driver on multiplatforms builds as helps remove a mach-specific header.
>
> The drawback of this is that the DT backwards compatibility gets broken;
> this was timely discussed but no better solution was achieved or proposed.
>
> * BRIDGE CAUSE clear removal
> The watchdog cause clear should be done by the bridge irqchip driver, so
> it's fine to remove it from the watchdog driver and instead request the
> interrupt.
>
> However, there are still a few platforms (orion5x, and legacy
> kirkwood/dove) that doesn't have this bridge irqchip support enabled.
> On these platforms the bridge cause clear is simply *not* done.
>
> If we are paranoid about this, maybe we can simply add the clear on each
> mach-xxx/irq.c, together with the other irq is initialization.
>
> Once again, thanks to everyone who helped reviewing this.
>
> Ezequiel Garcia (20):
> ARM: Introduce atomic MMIO modify
> clocksource: orion: Use atomic access for shared registers
> watchdog: orion: Add clock error handling
> watchdog: orion: Use atomic access for shared registers
> watchdog: orion: Remove unused macros
> watchdog: orion: Make sure the watchdog is initially stopped
> watchdog: orion: Handle the interrupt so it's properly acked
> watchdog: orion: Make RSTOUT register a separate resource
> watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
> watchdog: orion: Introduce an orion_watchdog device structure
> watchdog: orion: Introduce per-compatible of_device_id data
> watchdog: orion: Add per-compatible clock initialization
> watchdog: orion: Add per-compatible watchdog start implementation
> watchdog: orion: Add support for Armada 370 and Armada XP SoC
> ARM: mvebu: Enable Armada 370/XP watchdog in the devicetree
> ARM: kirkwood: Add RSTOUT 'reg' entry to devicetree
> ARM: dove: Enable Dove watchdog in the devicetree
> watchdog: orion: Enable the build on ARCH_MVEBU
> ARM: mvebu: Enable watchdog support in defconfig
> ARM: dove: Enable watchdog support in the defconfig
>
> .../devicetree/bindings/watchdog/marvel.txt | 8 +-
> arch/arm/boot/dts/armada-370-xp.dtsi | 4 +
> arch/arm/boot/dts/armada-370.dtsi | 5 +
> arch/arm/boot/dts/armada-xp.dtsi | 6 +
> arch/arm/boot/dts/dove.dtsi | 8 +
> arch/arm/boot/dts/kirkwood.dtsi | 2 +-
> arch/arm/configs/dove_defconfig | 2 +
> arch/arm/configs/mvebu_defconfig | 2 +
> arch/arm/include/asm/io.h | 6 +
> arch/arm/kernel/io.c | 35 ++
> arch/arm/mach-dove/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-mv78xx0/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-orion5x/include/mach/bridge-regs.h | 1 +
> arch/arm/plat-orion/common.c | 10 +-
> drivers/clocksource/time-orion.c | 28 +-
> drivers/watchdog/Kconfig | 2 +-
> drivers/watchdog/orion_wdt.c | 369 ++++++++++++++++-----
> 18 files changed, 383 insertions(+), 108 deletions(-)
>
> --
> 1.8.1.5
>
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Nicolas Pitre @ 2014-01-27 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127124511.GK15937@n2100.arm.linux.org.uk>
On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 01:08:16AM -0500, Nicolas Pitre wrote:
> > ARM and ARM64 are the only two architectures implementing
> > arch_cpu_idle_prepare() simply to call local_fiq_enable().
> >
> > We have secondary_start_kernel() already calling local_fiq_enable() and
> > this is done a second time in arch_cpu_idle_prepare() in that case. And
> > enabling FIQs has nothing to do with idling the CPU to start with.
> >
> > So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> > CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> > at late_initcall time but this shouldn't make a difference in practice
> > i.e. when FIQs are actually used.
> >
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > ---
> > arch/arm/kernel/process.c | 5 -----
> > arch/arm/kernel/setup.c | 7 +++++++
> > 2 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> > index 92f7b15dd2..725b8c95e0 100644
> > --- a/arch/arm/kernel/process.c
> > +++ b/arch/arm/kernel/process.c
> > @@ -142,11 +142,6 @@ static void default_idle(void)
> > local_irq_enable();
> > }
> >
> > -void arch_cpu_idle_prepare(void)
> > -{
> > - local_fiq_enable();
> > -}
> > -
> > void arch_cpu_idle_enter(void)
> > {
> > ledtrig_cpu(CPU_LED_IDLE_START);
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 987a7f5bce..d027b1a6fe 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -789,6 +789,13 @@ static int __init init_machine_late(void)
> > }
> > late_initcall(init_machine_late);
> >
> > +static int __init init_fiq_boot_cpu(void)
> > +{
> > + local_fiq_enable();
> > + return 0;
> > +}
> > +late_initcall(init_fiq_boot_cpu);
>
> arch_cpu_idle_prepare() gets called from the swapper thread, and changes
> the swapper thread's CPSR. init_fiq_boot_cpu() gets called from PID1, the
> init thread, and changes the init thread's CPSR, which will already have
> FIQs enabled by way of how kernel threads are created.
>
> Hence, the above code fragment has no effect what so ever, and those
> platforms using FIQs will not have FIQs delivered if they're idle
> (because the swapper will have FIQs masked at the CPU.)
You're right.
What about moving local_fiq_enable() to trap_init() then?
Nicolas
^ permalink raw reply
* [PATCH 2/9] ARM64: get rid of arch_cpu_idle_prepare()
From: Catalin Marinas @ 2014-01-27 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390802904-28399-3-git-send-email-nicolas.pitre@linaro.org>
On Mon, Jan 27, 2014 at 06:08:17AM +0000, Nicolas Pitre wrote:
> ARM and ARM64 are the only two architectures implementing
> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>
> We have secondary_start_kernel() already calling local_fiq_enable() and
> this is done a second time in arch_cpu_idle_prepare() in that case. And
> enabling FIQs has nothing to do with idling the CPU to start with.
>
> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> at late_initcall time but this shouldn't make a difference in practice
> given that FIQs are not currently used on ARM64.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
For arm64, we could simply remove any reference to FIQs. I'm not aware
of anyone using them.
--
Catalin
^ permalink raw reply
* [PATCH RFC v3 8/8] ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
Select following:
CONFIG_SND_DAVINCI_SOC=m
CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: tony at atomide.com
---
arch/arm/configs/omap2plus_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 9288172..62c4f51 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -214,6 +214,8 @@ CONFIG_SND_OMAP_SOC=m
CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
+CONFIG_SND_DAVINCI_SOC=m
+CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC v3 7/8] ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
This enables HDMI video support on Beaglebone-Black.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: tony at atomide.com
---
arch/arm/configs/omap2plus_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index bfa80a1..9288172 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -180,6 +180,9 @@ CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TPS65217=y
CONFIG_REGULATOR_TPS65910=y
CONFIG_REGULATOR_TWL4030=y
+CONFIG_DRM=m
+CONFIG_DRM_I2C_NXP_TDA998X=m
+CONFIG_DRM_TILCDC=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
--
1.7.9.5
^ permalink raw reply related
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