* [PATCH] arm64: Re-enable PAN on uaccess_enable
From: Marc Zyngier @ 2016-12-12 13:50 UTC (permalink / raw)
To: linux-arm-kernel
Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
functionality based on TTBR0_EL1") added conditional PAN
enable/disable. Unfortunately, a typo prevents PAN from being
re-enabled once it has been disabled.
Restore the PAN functionnality by adding the missing '!'.
Fixes: b65a5db3627 ("arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1")
Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
Christoffer, any chance you could give this a go and let me know
if that fixes your issues?
arch/arm64/include/asm/uaccess.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 6986f56..d26750c 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -188,7 +188,7 @@ do { \
#define __uaccess_enable(alt) \
do { \
- if (uaccess_ttbr0_enable()) \
+ if (!uaccess_ttbr0_enable()) \
asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
CONFIG_ARM64_PAN)); \
} while (0)
--
2.1.4
^ permalink raw reply related
* EXT: imx-sdma UART series failed for i.MX51
From: Han, Nandor (GE Healthcare) @ 2016-12-12 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481538186.727700380@f399.i.mail.ru>
Hi Alexander,
Thanks for info. I have already posted a patch that probably will
fix this issue.
https://lkml.org/lkml/2016/10/11/319
It was already tested on imx6 and imx53. Let me know how it works.
Reference:
http://lists-archives.com/linux-kernel/28679793-ext-pre-4-9-rc-dma-regression-imx6-sound-etc.html
On 12/12/2016 12:23, Alexander Shiyan wrote:
> Hello all.
>
> Upgrading the kernel from version 4.7 (to latest) has resulted in inoperable for i.MX51 DMA.
> It appears on sound playback (fsl_ssi with DMA). The sound is intermittent and a feeling that
> the each sound channel eats a part of buffer from another channel.
> Git-bisect found a first bad commit "first bad commit: [5881826ded79cf3c3314ee2d84c3bfa94e111b42]
> dmaengine: imx-sdma - update the residue calculation for cyclic channels" and after revert this commit,
> the problem has gone.
>
> Additionally, I had to disable DMA for the UART, because the revert the patch above led to the
> inoperability of the UART receiving part, although even before the series of all UART-SDMA
> patches still functioned normally (with imx6q check commented out).
>
> Any ideas?
>
> Thanks.
>
> shc at shc /home/ARM/linux $ git bisect log
> git bisect start
> # good: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
> git bisect good c8d2bc9bc39ebea8437fd974fdbc21847bb897a3
> # bad: [2e972325da7a2984b9045844d4185f4406e7a4b0] Revert "USB debug"
> git bisect bad 2e972325da7a2984b9045844d4185f4406e7a4b0
> # bad: [41844e36206be90cd4d962ea49b0abc3612a99d0] Merge tag 'staging-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
<snip>
--
Regards,
Nandi
^ permalink raw reply
* [PATCH renesas/devel 13/13] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-14-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
> DT for r8a7794 SoC.
iic etc...
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7794 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 12/13] ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-13-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
> DT for r8a7793 SoC.
iic etc...
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7793 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 11/13] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-12-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
> DT for r8a7791 SoC.
iic etc...
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7791 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/7] ARM: EXYNOS: Constify list of retention registers
From: Bartlomiej Zolnierkiewicz @ 2016-12-12 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481377658-22603-1-git-send-email-krzk@kernel.org>
Hi,
On Saturday, December 10, 2016 03:47:32 PM Krzysztof Kozlowski wrote:
> The list of retention registers (release_ret_regs field of struct
> exynos_pm_data and arrays with values) are not modified and can be made
> const to improve the const safeness.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
for patches #1-7
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH renesas/devel 09/13] arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-10-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 3 fallback binding for i2c nodes in
> DT for r8a7796 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7796 and the
> fallback binding for R-Car Gen 3.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 08/13] arm64: dts: r8a7795: Use R-Car Gen 3 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-9-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 3 fallback binding for i2c nodes in
> DT for r8a7795 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7795 and the
> fallback binding for R-Car Gen 3.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 07/13] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-8-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7794 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7794 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ASoC: samsung: Remove tests of member address
From: Bartlomiej Zolnierkiewicz @ 2016-12-12 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481363471-21364-1-git-send-email-krzk@kernel.org>
Hi,
On Saturday, December 10, 2016 11:51:11 AM Krzysztof Kozlowski wrote:
> The driver was checking for non-NULL address of struct's members:
> - s3c_audio_pdata->type (union),
> - s3c_audio_pdata->type.i2s (embedded struct).
>
> This is pointless as these will be always non-NULL. The 's3c_audio_pdata'
> is always initialized in static memory so it will be zeroed.
> Additionally the 'type' member was an union with only one member.
>
> It is safe to reorganize the structures to get rid of useless union and
> checks for addresses to fix the coccinelle warning:
> >> sound/soc/samsung/i2s.c:1270:2-4: ERROR: test of a variable/field address
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH renesas/devel 05/13] ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-6-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7792 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7792 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 04/13] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-5-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7791 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7791 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v7 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings
From: Juri Lelli @ 2016-12-12 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212124005.GA19177@red-moon>
On 12/12/16 12:40, Lorenzo Pieralisi wrote:
> On Mon, Sep 05, 2016 at 03:22:45PM +0100, Juri Lelli wrote:
>
> [...]
>
> > +===========================================
> > +5 - References
> > +===========================================
> > +
> > +[1] ARM Linux Kernel documentation - CPUs bindings
> > + Documentation/devicetree/bindings/arm/cpus.txt
> > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> > index e6782d50cbcd..c1dcf4cade2e 100644
> > --- a/Documentation/devicetree/bindings/arm/cpus.txt
> > +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> > @@ -241,6 +241,14 @@ nodes to be present and contain the properties described below.
> > # List of phandles to idle state nodes supported
> > by this cpu [3].
> >
> > + - capacity-dmips-mhz
> > + Usage: Optional
> > + Value type: <u32>
> > + Definition:
> > + # u32 value representing CPU capacity [3] in
> > + DMIPS/MHz, relative to highest capacity-dmips-mhz
> > + in the system.
> > +
> > - rockchip,pmu
> > Usage: optional for systems that have an "enable-method"
> > property value of "rockchip,rk3066-smp"
> > @@ -464,3 +472,5 @@ cpus {
> > [2] arm/msm/qcom,kpss-acc.txt
> > [3] ARM Linux kernel documentation - idle states bindings
> > Documentation/devicetree/bindings/arm/idle-states.txt
> > +[3] ARM Linux kernel documentation - cpu capacity bindings
> > + Documentation/devicetree/bindings/arm/cpu-capacity.txt
>
> Trivia: bumped into this while reviewing something else, too many
> threes, you will have to fix the added reference up.
Argh! Fixed locally, thanks for catching it.
Best,
- Juri
^ permalink raw reply
* [PATCH renesas/devel 03/13] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-4-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7790 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7790 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 02/13] ARM: dts: r8a7778: Use R-Car Gen 1 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-3-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 1 fallback binding for i2c nodes in
> DT for r8a7778 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7778 and the
> fallback binding for R-Car Gen 1.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 01/13] ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-2-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 1 fallback binding for i2c nodes in
> DT for r8a7779 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7779 and the
> fallback binding for R-Car Gen 1.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Vladimir Murzin @ 2016-12-12 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209202901.GQ14217@n2100.armlinux.org.uk>
On 09/12/16 20:29, Russell King - ARM Linux wrote:
> On Wed, Dec 07, 2016 at 02:33:53PM +0000, Vladimir Murzin wrote:
>> Hi Linus,
>>
>> On 07/12/16 14:11, Linus Walleij wrote:
>>> Another target I had in mind was the Integrator which
>>> incidentally supports a bunch of the old noMMU core
>>> tiles where we can swap in an ARM946, which I guess
>>> could work with this?
>>
>> Do you mind trying my "Allow NOMMU for MULTIPLATFORM" series [1]? Greg just
>> reported it did a trick for Versatile, there is a good chance it would work
>> for Integrator too ;)
>
> My views on gluing multiplatform and nommu together have already been
> stated several times, and remain unchanged.
>
Should I treat this as the whole series is discarded or there is something you
can pick up?
Cheers
Vladimir
> Greg's patch looks almost sane, but what I'd like to see is instead of
> directly doing this:
>
> config ARCH_VERSATILE
> bool "ARM Ltd. Versatile family"
> - depends on ARCH_MULTI_V5
> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
>
> we could do:
>
> config ARCH_VERSATILE
> bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
> - depends on ARCH_MULTI_V5
> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
> default y if ARM_SINGLE_ARCH_VERSATILE
>
> adding the versatile entry in the upper level choice (where it always used
> to be) but with "ARM_SINGLE_ARCH_VERSATILE" instead.
>
> This would have the effect of allowing the multiplatform-converted stuff
> to start being used on nommu (again) but without running into the problems
> I've highlighted.
>
^ permalink raw reply
* [PATCH v6 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1] http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3f51e59..ba5bf80 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -452,6 +452,7 @@
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
+ max-pixelclock = <37500>;
status = "disabled";
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v6 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>
Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 67 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..e003111 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -51,6 +51,51 @@
system-clock-frequency = <24576000>;
};
};
+
+ vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ reg = <0>;
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ ddc-i2c-bus = <&i2c0>;
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
};
&pmx_core {
@@ -236,3 +281,25 @@
&memctrl {
status = "okay";
};
+
+&lcdc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lcdc_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ lcdc_out_vga: endpoint {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v6 3/5] drm: bridge: add support for TI ths8135
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>
THS8135 is a configurable video DAC, but no configuration is actually
necessary to make it work.
For now use the dumb-vga-dac driver to support it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232..498fa75 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
static const struct of_device_id dumb_vga_match[] = {
{ .compatible = "dumb-vga-dac" },
+ { .compatible = "ti,ths8135" },
{},
};
MODULE_DEVICE_TABLE(of, dumb_vga_match);
--
2.9.3
^ permalink raw reply related
* [PATCH v6 2/5] drm: bridge: add DT bindings for TI ths8135
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
.../bindings/display/bridge/ti,ths8135.txt | 52 ++++++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
new file mode 100644
index 0000000..87aff90
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
@@ -0,0 +1,52 @@
+THS8135 Video DAC
+-----------------
+
+This is the binding for Texas Instruments THS8135 Video DAC bridge.
+
+Required properties:
+
+- compatible: Must be "ti,ths8135"
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+Example
+-------
+
+vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ reg = <0>;
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v6 1/5] ARM: dts: da850: rename the display node label
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>
The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
The label is also 'display', but change it to 'lcdc' to make it clear
what the underlying hardware is.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index ffc6e1a..3f51e59 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -448,7 +448,7 @@
dma-names = "tx", "rx";
};
- display: display at 213000 {
+ lcdc: display at 213000 {
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 0/5] ARM: dts: da850: tilcdc related DT changes
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
v2 -> v3:
- make the commit message in patch [2/2] more detailed
- move the max-pixelclock property to da850.dtsi as the limit
affects all da850-based boards
v3 -> v4:
- remove the input port from the display node
- move the display ports node to da850-lcdk.dts
- rename the vga_bridge node to vga-bridge
- move the LCDC pins to the LCDC node (from the vga bridge node)
v4 -> v5:
- rename the display label to lcdc
- instead of using the 'dumb-vga-dac' compatible, add bindings for
ti,ths8135 and use it as the vga-bridge node compatible
v5 -> v6:
- drop the endpoint numbers for nodes with single endpoints
- split patch 2/4 from v5 into two separate patches: one adding DT
bindings and one adding actual support for ths8135
Bartosz Golaszewski (5):
ARM: dts: da850: rename the display node label
drm: bridge: add DT bindings for TI ths8135
drm: bridge: add support for TI ths8135
ARM: dts: da850-lcdk: add the vga-bridge node
ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
.../bindings/display/bridge/ti,ths8135.txt | 52 +++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 67 ++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 3 +-
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
4 files changed, 122 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
--
2.9.3
^ permalink raw reply
* [PATCH 1/1] arm/module: maximum utilization of module area.
From: Russell King - ARM Linux @ 2016-12-12 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212112230epcms5p6af05aef34f72eab15061a166d18cff00@epcms5p6>
On Mon, Dec 12, 2016 at 11:22:30AM +0000, Vaneet Narang wrote:
> Hi,
>
> >A PC24 relocation has a range of +/-32MB. This means that where-ever
> >the module is placed, it must be capable of reaching any function
> >within the kernel text, which may itself be quite large (eg, 8MB, or
> >possibly larger). The module area exists to allow modules to be
> >located in an area where PC24 relocations are able to reach all of the
> >kernel text on sensibly configured kernels, thereby allowing for
> >optimal performance.
> >
> >If you wish to load large modules, then enable ARM_MODULE_PLTS, which
> >will use the less efficient PLT method (which is basically an indirect
> >function call) for relocations that PC24 can't handle, and will allow
> >the module to be loaded into the vmalloc area.
> >
> >Growing the module area so that smaller modules also get penalised by
> >the PLT indirection is not sane.
>
> This is exactly what i am saying. These changes are useful to accomdate
> 22MB modules without enabling ARM_MODULE_PLTS.
Obviously I wasn't clear enough.
No, I do not like your change for the reasons given above. I'm not going
to accept it.
If you want to use 22MB modules, enable ARM_MODULE_PLTS.
Thank you.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-12-12 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <578CEB74.2080002@ti.com>
Hi,
On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote:
> On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote:
> > Arnd Bergmann <arnd@arndb.de> writes:
> >
> >> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> >>>
> >>> On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> >>>> On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> >>>>> This patch disables deprecated IDE subsystem in assabet_defconfig
> >>>>> (no IDE host drivers are selected in this config so there is no
> >>>>> valid reason to enable IDE subsystem itself).
> >>>>>
> >>>>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>>>
> >>>> I think the series makes a lot of sense. I have checked your assertions
> >>>> in the changelogs and found no flaws in your logic, so I think we should
> >>>> take them all through arm-soc unless there are other concerns.
> >>>
> >>> Thank you.
> >>>
> >>> Should I resend everything or just patches that were not reposted yet
> >>> (the ones that were marked as RFT initially and got no feedback)?
> >>
> >> I'd be fine with just getting a pull request with all the patches that
> >> had no negative feedback and that were not already applied (if any).
> >>
> >>>> Do you have a list of ARM defconfigs that keep using CONFIG_IDE and
> >>>> how you determined that they need it?
> >>>
> >>> The only such defconfig is davinci_all_defconfig which uses
> >>> palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710).
> >>>
> >>>> I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that
> >>>> have no libata replacement, are there any others like that, or are
> >>>> they all platforms that should in theory work with libata but need
> >>>> testing?
> >>>
> >>> All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work
> >>> with libata.
> >>
> >> Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks
> >> fairly straightforward (meaning someone has to do a few day's work)
> >> to convert into a libata driver.
> >>
> >> As this is on on-chip controller that is part of a dm644x and dm646x,
> >> it should also not be hard to test (as long as someone can find
> >> a hard drive to plug in).
> >
> > I have a hard drive, but don't have any dm64xx hardware anymore to test
> > this. My last working dm644x board died last year.
>
> I have a working DM6446 EVM. I was able to connect a hard drive to it
> and do some basic tests with v4.6 kernel.
>
> I will look into converting the driver to libata. Might take some time
> because this is unfamiliar territory for me.
Do you need some help with it?
I can provide you with draft driver patch if you want.
I'm also on #kernel IRC channel in case you have some questions..
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ 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